Flatten bind9 vendor work area

193 files changed, 202479 insertions, 0 deletions

diff --git a/doc/Makefile.in b/doc/Makefile.in
new file mode 100644
index 0000000..f307f41
--- /dev/null
+++ b/doc/Makefile.in
@@ -0,0 +1,29 @@
+# Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+# Copyright (C) 2000, 2001  Internet Software Consortium.
+#
+# Permission to use, copy, modify, and distribute this software for any
+# purpose with or without fee is hereby granted, provided that the above
+# copyright notice and this permission notice appear in all copies.
+#
+# THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
+# REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
+# AND FITNESS.  IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
+# INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
+# LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
+# OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
+# PERFORMANCE OF THIS SOFTWARE.
+
+# $Id: Makefile.in,v 1.5.18.2 2005/07/23 04:35:12 marka Exp $
+
+# This Makefile is a placeholder.  It exists merely to make
+# sure that its directory gets created in the object directory
+# tree when doing a build using separate object directories.
+
+srcdir =	@srcdir@
+VPATH =		@srcdir@
+top_srcdir =	@top_srcdir@
+
+SUBDIRS = arm misc xsl
+TARGETS =
+
+@BIND9_MAKE_RULES@
diff --git a/doc/arm/Bv9ARM-book.xml b/doc/arm/Bv9ARM-book.xml
new file mode 100644
index 0000000..e30ca3f
--- /dev/null
+++ b/doc/arm/Bv9ARM-book.xml
@@ -0,0 +1,12326 @@
+<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
+               "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+	       [<!ENTITY mdash "&#8212;">]>
+<!--
+ - Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2000-2003  Internet Software Consortium.
+ -
+ - Permission to use, copy, modify, and/or distribute this software for any
+ - purpose with or without fee is hereby granted, provided that the above
+ - copyright notice and this permission notice appear in all copies.
+ -
+ - THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
+ - REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
+ - AND FITNESS.  IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
+ - INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
+ - LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
+ - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
+ - PERFORMANCE OF THIS SOFTWARE.
+-->
+
+<!-- File: $Id: Bv9ARM-book.xml,v 1.241.18.82 2007/09/26 03:28:27 marka Exp $ -->
+<book xmlns:xi="http://www.w3.org/2001/XInclude">
+  <title>BIND 9 Administrator Reference Manual</title>
+
+  <bookinfo>
+    <copyright>
+      <year>2004</year>
+      <year>2005</year>
+      <year>2006</year>
+      <year>2007</year>
+      <holder>Internet Systems Consortium, Inc. ("ISC")</holder>
+    </copyright>
+    <copyright>
+      <year>2000</year>
+      <year>2001</year>
+      <year>2002</year>
+      <year>2003</year>
+      <holder>Internet Software Consortium.</holder>
+    </copyright>
+  </bookinfo>
+
+  <chapter id="Bv9ARM.ch01">
+    <title>Introduction</title>
+    <para>
+      The Internet Domain Name System (<acronym>DNS</acronym>)
+      consists of the syntax
+      to specify the names of entities in the Internet in a hierarchical
+      manner, the rules used for delegating authority over names, and the
+      system implementation that actually maps names to Internet
+      addresses.  <acronym>DNS</acronym> data is maintained in a
+      group of distributed
+      hierarchical databases.
+    </para>
+
+    <sect1>
+      <title>Scope of Document</title>
+
+      <para>
+        The Berkeley Internet Name Domain
+        (<acronym>BIND</acronym>) implements a
+        domain name server for a number of operating systems. This
+        document provides basic information about the installation and
+        care of the Internet Systems Consortium (<acronym>ISC</acronym>)
+        <acronym>BIND</acronym> version 9 software package for
+        system administrators.
+      </para>
+
+      <para>
+        This version of the manual corresponds to BIND version 9.4.
+      </para>
+
+    </sect1>
+    <sect1>
+      <title>Organization of This Document</title>
+      <para>
+        In this document, <emphasis>Section 1</emphasis> introduces
+        the basic <acronym>DNS</acronym> and <acronym>BIND</acronym> concepts. <emphasis>Section 2</emphasis>
+        describes resource requirements for running <acronym>BIND</acronym> in various
+        environments. Information in <emphasis>Section 3</emphasis> is
+        <emphasis>task-oriented</emphasis> in its presentation and is
+        organized functionally, to aid in the process of installing the
+        <acronym>BIND</acronym> 9 software. The task-oriented
+        section is followed by
+        <emphasis>Section 4</emphasis>, which contains more advanced
+        concepts that the system administrator may need for implementing
+        certain options. <emphasis>Section 5</emphasis>
+        describes the <acronym>BIND</acronym> 9 lightweight
+        resolver.  The contents of <emphasis>Section 6</emphasis> are
+        organized as in a reference manual to aid in the ongoing
+        maintenance of the software. <emphasis>Section 7</emphasis> addresses
+        security considerations, and
+        <emphasis>Section 8</emphasis> contains troubleshooting help. The
+        main body of the document is followed by several
+        <emphasis>appendices</emphasis> which contain useful reference
+        information, such as a <emphasis>bibliography</emphasis> and
+        historic information related to <acronym>BIND</acronym>
+        and the Domain Name
+        System.
+      </para>
+    </sect1>
+    <sect1>
+      <title>Conventions Used in This Document</title>
+
+      <para>
+        In this document, we use the following general typographic
+        conventions:
+      </para>
+
+      <informaltable>
+        <tgroup cols="2">
+          <colspec colname="1" colnum="1" colwidth="3.000in"/>
+          <colspec colname="2" colnum="2" colwidth="2.625in"/>
+          <tbody>
+            <row>
+              <entry colname="1">
+                <para>
+                  <emphasis>To describe:</emphasis>
+                </para>
+              </entry>
+              <entry colname="2">
+                <para>
+                  <emphasis>We use the style:</emphasis>
+                </para>
+              </entry>
+            </row>
+            <row>
+              <entry colname="1">
+                <para>
+                  a pathname, filename, URL, hostname,
+                  mailing list name, or new term or concept
+                </para>
+              </entry>
+              <entry colname="2">
+                <para>
+                  <filename>Fixed width</filename>
+                </para>
+              </entry>
+            </row>
+            <row>
+              <entry colname="1">
+                <para>
+                  literal user
+                  input
+                </para>
+              </entry>
+              <entry colname="2">
+                <para>
+                  <userinput>Fixed Width Bold</userinput>
+                </para>
+              </entry>
+            </row>
+            <row>
+              <entry colname="1">
+                <para>
+                  program output
+                </para>
+              </entry>
+              <entry colname="2">
+                <para>
+                  <computeroutput>Fixed Width</computeroutput>
+                </para>
+              </entry>
+            </row>
+          </tbody>
+        </tgroup>
+      </informaltable>
+
+      <para>
+        The following conventions are used in descriptions of the
+        <acronym>BIND</acronym> configuration file:<informaltable colsep="0" frame="all" rowsep="0">
+                  <tgroup cols="2" colsep="0" rowsep="0" tgroupstyle="2Level-table">
+                      <colspec colname="1" colnum="1" colsep="0" colwidth="3.000in"/>
+            <colspec colname="2" colnum="2" colsep="0" colwidth="2.625in"/>
+            <tbody>
+              <row rowsep="0">
+                <entry colname="1" colsep="1" rowsep="1">
+                  <para>
+                    <emphasis>To describe:</emphasis>
+                  </para>
+                </entry>
+                <entry colname="2" rowsep="1">
+                  <para>
+                    <emphasis>We use the style:</emphasis>
+                  </para>
+                </entry>
+              </row>
+              <row rowsep="0">
+                <entry colname="1" colsep="1" rowsep="1">
+                  <para>
+                    keywords
+                  </para>
+                </entry>
+                <entry colname="2" rowsep="1">
+                  <para>
+                    <literal>Fixed Width</literal>
+                  </para>
+                </entry>
+              </row>
+              <row rowsep="0">
+                <entry colname="1" colsep="1" rowsep="1">
+                  <para>
+                    variables
+                  </para>
+                </entry>
+                <entry colname="2" rowsep="1">
+                  <para>
+                    <varname>Fixed Width</varname>
+                  </para>
+                </entry>
+              </row>
+              <row rowsep="0">
+                <entry colname="1" colsep="1">
+                  <para>
+                    Optional input
+                  </para>
+                </entry>
+                <entry colname="2">
+                  <para>
+                    <optional>Text is enclosed in square brackets</optional>
+                  </para>
+                </entry>
+              </row>
+            </tbody>
+          </tgroup>
+        </informaltable>
+      </para>
+    </sect1>
+    <sect1>
+      <title>The Domain Name System (<acronym>DNS</acronym>)</title>
+      <para>
+        The purpose of this document is to explain the installation
+        and upkeep of the <acronym>BIND</acronym> (Berkeley Internet
+	Name Domain) software package, and we
+        begin by reviewing the fundamentals of the Domain Name System
+        (<acronym>DNS</acronym>) as they relate to <acronym>BIND</acronym>.
+      </para>
+
+      <sect2>
+        <title>DNS Fundamentals</title>
+
+        <para>
+          The Domain Name System (DNS) is a hierarchical, distributed
+          database.  It stores information for mapping Internet host names to
+          IP
+          addresses and vice versa, mail routing information, and other data
+          used by Internet applications.
+        </para>
+
+        <para>
+          Clients look up information in the DNS by calling a
+          <emphasis>resolver</emphasis> library, which sends queries to one or
+          more <emphasis>name servers</emphasis> and interprets the responses.
+          The <acronym>BIND</acronym> 9 software distribution
+          contains a
+          name server, <command>named</command>, and two resolver
+          libraries, <command>liblwres</command> and <command>libbind</command>.
+        </para>
+
+        </sect2><sect2>
+        <title>Domains and Domain Names</title>
+
+        <para>
+          The data stored in the DNS is identified by <emphasis>domain names</emphasis> that are organized as a tree according to
+          organizational or administrative boundaries. Each node of the tree,
+          called a <emphasis>domain</emphasis>, is given a label. The domain
+          name of the
+          node is the concatenation of all the labels on the path from the
+          node to the <emphasis>root</emphasis> node.  This is represented
+          in written form as a string of labels listed from right to left and
+          separated by dots. A label need only be unique within its parent
+          domain.
+        </para>
+
+        <para>
+          For example, a domain name for a host at the
+          company <emphasis>Example, Inc.</emphasis> could be
+          <literal>ourhost.example.com</literal>,
+          where <literal>com</literal> is the
+          top level domain to which
+          <literal>ourhost.example.com</literal> belongs,
+          <literal>example</literal> is
+          a subdomain of <literal>com</literal>, and
+          <literal>ourhost</literal> is the
+          name of the host.
+        </para>
+
+        <para>
+          For administrative purposes, the name space is partitioned into
+          areas called <emphasis>zones</emphasis>, each starting at a node and
+          extending down to the leaf nodes or to nodes where other zones
+          start.
+          The data for each zone is stored in a <emphasis>name server</emphasis>, which answers queries about the zone using the
+          <emphasis>DNS protocol</emphasis>.
+        </para>
+
+        <para>
+          The data associated with each domain name is stored in the
+          form of <emphasis>resource records</emphasis> (<acronym>RR</acronym>s).
+          Some of the supported resource record types are described in
+          <xref linkend="types_of_resource_records_and_when_to_use_them"/>.
+        </para>
+
+        <para>
+          For more detailed information about the design of the DNS and
+          the DNS protocol, please refer to the standards documents listed in
+          <xref linkend="rfcs"/>.
+        </para>
+      </sect2>
+
+      <sect2>
+        <title>Zones</title>
+        <para>
+          To properly operate a name server, it is important to understand
+          the difference between a <emphasis>zone</emphasis>
+          and a <emphasis>domain</emphasis>.
+        </para>
+
+        <para>
+          As stated previously, a zone is a point of delegation in
+          the <acronym>DNS</acronym> tree. A zone consists of
+          those contiguous parts of the domain
+          tree for which a name server has complete information and over which
+          it has authority. It contains all domain names from a certain point
+          downward in the domain tree except those which are delegated to
+          other zones. A delegation point is marked by one or more
+          <emphasis>NS records</emphasis> in the
+          parent zone, which should be matched by equivalent NS records at
+          the root of the delegated zone.
+        </para>
+
+        <para>
+          For instance, consider the <literal>example.com</literal>
+          domain which includes names
+          such as <literal>host.aaa.example.com</literal> and
+          <literal>host.bbb.example.com</literal> even though
+          the <literal>example.com</literal> zone includes
+          only delegations for the <literal>aaa.example.com</literal> and
+          <literal>bbb.example.com</literal> zones.  A zone can
+          map
+          exactly to a single domain, but could also include only part of a
+          domain, the rest of which could be delegated to other
+          name servers. Every name in the <acronym>DNS</acronym>
+          tree is a
+          <emphasis>domain</emphasis>, even if it is
+          <emphasis>terminal</emphasis>, that is, has no
+          <emphasis>subdomains</emphasis>.  Every subdomain is a domain and
+          every domain except the root is also a subdomain. The terminology is
+          not intuitive and we suggest that you read RFCs 1033, 1034 and 1035
+          to
+          gain a complete understanding of this difficult and subtle
+          topic.
+        </para>
+
+        <para>
+          Though <acronym>BIND</acronym> is called a "domain name
+          server",
+          it deals primarily in terms of zones. The master and slave
+          declarations in the <filename>named.conf</filename> file
+          specify
+          zones, not domains. When you ask some other site if it is willing to
+          be a slave server for your <emphasis>domain</emphasis>, you are
+          actually asking for slave service for some collection of zones.
+        </para>
+      </sect2>
+
+      <sect2>
+        <title>Authoritative Name Servers</title>
+
+        <para>
+          Each zone is served by at least
+          one <emphasis>authoritative name server</emphasis>,
+          which contains the complete data for the zone.
+          To make the DNS tolerant of server and network failures,
+          most zones have two or more authoritative servers, on
+          different networks.
+        </para>
+
+        <para>
+          Responses from authoritative servers have the "authoritative
+          answer" (AA) bit set in the response packets.  This makes them
+          easy to identify when debugging DNS configurations using tools like
+          <command>dig</command> (<xref linkend="diagnostic_tools"/>).
+        </para>
+
+        <sect3>
+          <title>The Primary Master</title>
+
+          <para>
+            The authoritative server where the master copy of the zone
+            data is maintained is called the
+	    <emphasis>primary master</emphasis> server, or simply the
+            <emphasis>primary</emphasis>.  Typically it loads the zone
+            contents from some local file edited by humans or perhaps
+            generated mechanically from some other local file which is
+            edited by humans.  This file is called the
+	    <emphasis>zone file</emphasis> or
+	    <emphasis>master file</emphasis>.
+          </para>
+
+	  <para>
+	    In some cases, however, the master file may not be edited
+	    by humans at all, but may instead be the result of
+	    <emphasis>dynamic update</emphasis> operations.
+	  </para>
+        </sect3>
+
+        <sect3>
+          <title>Slave Servers</title>
+          <para>
+            The other authoritative servers, the <emphasis>slave</emphasis>
+            servers (also known as <emphasis>secondary</emphasis> servers)
+            load
+            the zone contents from another server using a replication process
+            known as a <emphasis>zone transfer</emphasis>.  Typically the data
+            are
+            transferred directly from the primary master, but it is also
+            possible
+            to transfer it from another slave.  In other words, a slave server
+            may itself act as a master to a subordinate slave server.
+          </para>
+        </sect3>
+
+        <sect3>
+          <title>Stealth Servers</title>
+
+          <para>
+            Usually all of the zone's authoritative servers are listed in
+            NS records in the parent zone.  These NS records constitute
+            a <emphasis>delegation</emphasis> of the zone from the parent.
+            The authoritative servers are also listed in the zone file itself,
+            at the <emphasis>top level</emphasis> or <emphasis>apex</emphasis>
+            of the zone.  You can list servers in the zone's top-level NS
+            records that are not in the parent's NS delegation, but you cannot
+            list servers in the parent's delegation that are not present at
+            the zone's top level.
+          </para>
+
+          <para>
+            A <emphasis>stealth server</emphasis> is a server that is
+            authoritative for a zone but is not listed in that zone's NS
+            records.  Stealth servers can be used for keeping a local copy of
+            a
+            zone to speed up access to the zone's records or to make sure that
+            the
+            zone is available even if all the "official" servers for the zone
+            are
+            inaccessible.
+          </para>
+
+          <para>
+            A configuration where the primary master server itself is a
+            stealth server is often referred to as a "hidden primary"
+            configuration.  One use for this configuration is when the primary
+            master
+            is behind a firewall and therefore unable to communicate directly
+            with the outside world.
+          </para>
+
+        </sect3>
+
+      </sect2>
+      <sect2>
+
+        <title>Caching Name Servers</title>
+
+	<!--
+	  - Terminology here is inconsistent.  Probably ought to
+	  - convert to using "recursive name server" everywhere
+	  - with just a note about "caching" terminology.
+	  -->
+
+        <para>
+          The resolver libraries provided by most operating systems are
+          <emphasis>stub resolvers</emphasis>, meaning that they are not
+          capable of
+          performing the full DNS resolution process by themselves by talking
+          directly to the authoritative servers.  Instead, they rely on a
+          local
+          name server to perform the resolution on their behalf.  Such a
+          server
+          is called a <emphasis>recursive</emphasis> name server; it performs
+          <emphasis>recursive lookups</emphasis> for local clients.
+        </para>
+
+        <para>
+          To improve performance, recursive servers cache the results of
+          the lookups they perform.  Since the processes of recursion and
+          caching are intimately connected, the terms
+          <emphasis>recursive server</emphasis> and
+          <emphasis>caching server</emphasis> are often used synonymously.
+        </para>
+
+        <para>
+          The length of time for which a record may be retained in
+          the cache of a caching name server is controlled by the
+          Time To Live (TTL) field associated with each resource record.
+        </para>
+
+        <sect3>
+          <title>Forwarding</title>
+
+          <para>
+            Even a caching name server does not necessarily perform
+            the complete recursive lookup itself.  Instead, it can
+            <emphasis>forward</emphasis> some or all of the queries
+            that it cannot satisfy from its cache to another caching name
+            server,
+            commonly referred to as a <emphasis>forwarder</emphasis>.
+          </para>
+
+          <para>
+            There may be one or more forwarders,
+            and they are queried in turn until the list is exhausted or an
+            answer
+            is found. Forwarders are typically used when you do not
+            wish all the servers at a given site to interact directly with the
+            rest of
+            the Internet servers. A typical scenario would involve a number
+            of internal <acronym>DNS</acronym> servers and an
+            Internet firewall. Servers unable
+            to pass packets through the firewall would forward to the server
+            that can do it, and that server would query the Internet <acronym>DNS</acronym> servers
+            on the internal server's behalf.
+          </para>
+        </sect3>
+
+      </sect2>
+
+      <sect2>
+        <title>Name Servers in Multiple Roles</title>
+
+        <para>
+          The <acronym>BIND</acronym> name server can
+          simultaneously act as
+          a master for some zones, a slave for other zones, and as a caching
+          (recursive) server for a set of local clients.
+        </para>
+
+        <para>
+          However, since the functions of authoritative name service
+          and caching/recursive name service are logically separate, it is
+          often advantageous to run them on separate server machines.
+
+          A server that only provides authoritative name service
+          (an <emphasis>authoritative-only</emphasis> server) can run with
+          recursion disabled, improving reliability and security.
+
+          A server that is not authoritative for any zones and only provides
+          recursive service to local
+          clients (a <emphasis>caching-only</emphasis> server)
+          does not need to be reachable from the Internet at large and can
+          be placed inside a firewall.
+        </para>
+
+      </sect2>
+    </sect1>
+
+  </chapter>
+
+  <chapter id="Bv9ARM.ch02">
+    <title><acronym>BIND</acronym> Resource Requirements</title>
+
+    <sect1>
+      <title>Hardware requirements</title>
+
+      <para>
+        <acronym>DNS</acronym> hardware requirements have
+        traditionally been quite modest.
+        For many installations, servers that have been pensioned off from
+        active duty have performed admirably as <acronym>DNS</acronym> servers.
+      </para>
+      <para>
+        The DNSSEC features of <acronym>BIND</acronym> 9
+        may prove to be quite
+        CPU intensive however, so organizations that make heavy use of these
+        features may wish to consider larger systems for these applications.
+        <acronym>BIND</acronym> 9 is fully multithreaded, allowing
+        full utilization of
+        multiprocessor systems for installations that need it.
+      </para>
+    </sect1>
+    <sect1>
+      <title>CPU Requirements</title>
+      <para>
+        CPU requirements for <acronym>BIND</acronym> 9 range from
+        i486-class machines
+        for serving of static zones without caching, to enterprise-class
+        machines if you intend to process many dynamic updates and DNSSEC
+        signed zones, serving many thousands of queries per second.
+      </para>
+    </sect1>
+
+    <sect1>
+      <title>Memory Requirements</title>
+      <para>
+        The memory of the server has to be large enough to fit the
+        cache and zones loaded off disk.  The <command>max-cache-size</command>
+        option can be used to limit the amount of memory used by the cache,
+        at the expense of reducing cache hit rates and causing more <acronym>DNS</acronym>
+        traffic.
+        Additionally, if additional section caching
+        (<xref linkend="acache"/>) is enabled,
+        the <command>max-acache-size</command> option can be used to
+        limit the amount
+        of memory used by the mechanism.
+        It is still good practice to have enough memory to load
+        all zone and cache data into memory &mdash; unfortunately, the best
+        way
+        to determine this for a given installation is to watch the name server
+        in operation. After a few weeks the server process should reach
+        a relatively stable size where entries are expiring from the cache as
+        fast as they are being inserted.
+      </para>
+      <!--
+        - Add something here about leaving overhead for attacks?
+	- How much overhead?  Percentage?
+        -->
+    </sect1>
+
+    <sect1>
+      <title>Name Server Intensive Environment Issues</title>
+      <para>
+        For name server intensive environments, there are two alternative
+        configurations that may be used. The first is where clients and
+        any second-level internal name servers query a main name server, which
+        has enough memory to build a large cache. This approach minimizes
+        the bandwidth used by external name lookups. The second alternative
+        is to set up second-level internal name servers to make queries
+        independently.
+        In this configuration, none of the individual machines needs to
+        have as much memory or CPU power as in the first alternative, but
+        this has the disadvantage of making many more external queries,
+        as none of the name servers share their cached data.
+      </para>
+    </sect1>
+
+    <sect1>
+      <title>Supported Operating Systems</title>
+      <para>
+        ISC <acronym>BIND</acronym> 9 compiles and runs on a large
+        number
+        of Unix-like operating system and on NT-derived versions of
+        Microsoft Windows such as Windows 2000 and Windows XP.  For an
+        up-to-date
+        list of supported systems, see the README file in the top level
+        directory
+        of the BIND 9 source distribution.
+      </para>
+    </sect1>
+  </chapter>
+
+  <chapter id="Bv9ARM.ch03">
+    <title>Name Server Configuration</title>
+    <para>
+      In this section we provide some suggested configurations along
+      with guidelines for their use.  We suggest reasonable values for
+      certain option settings.
+    </para>
+
+    <sect1 id="sample_configuration">
+      <title>Sample Configurations</title>
+      <sect2>
+        <title>A Caching-only Name Server</title>
+        <para>
+          The following sample configuration is appropriate for a caching-only
+          name server for use by clients internal to a corporation.  All
+          queries
+          from outside clients are refused using the <command>allow-query</command>
+          option.  Alternatively, the same effect could be achieved using
+          suitable
+          firewall rules.
+        </para>
+
+<programlisting>
+// Two corporate subnets we wish to allow queries from.
+acl corpnets { 192.168.4.0/24; 192.168.7.0/24; };
+options {
+     directory "/etc/namedb";           // Working directory
+     allow-query { corpnets; };
+};
+// Provide a reverse mapping for the loopback address 127.0.0.1
+zone "0.0.127.in-addr.arpa" {
+     type master;
+     file "localhost.rev";
+     notify no;
+};
+</programlisting>
+
+      </sect2>
+
+      <sect2>
+        <title>An Authoritative-only Name Server</title>
+        <para>
+          This sample configuration is for an authoritative-only server
+          that is the master server for "<filename>example.com</filename>"
+          and a slave for the subdomain "<filename>eng.example.com</filename>".
+        </para>
+
+<programlisting>
+options {
+     directory "/etc/namedb";           // Working directory
+     allow-query-cache { none; };       // Do not allow access to cache
+     allow-query { any; };              // This is the default
+     recursion no;                      // Do not provide recursive service
+};
+
+// Provide a reverse mapping for the loopback address 127.0.0.1
+zone "0.0.127.in-addr.arpa" {
+     type master;
+     file "localhost.rev";
+     notify no;
+};
+// We are the master server for example.com
+zone "example.com" {
+     type master;
+     file "example.com.db";
+     // IP addresses of slave servers allowed to transfer example.com
+     allow-transfer {
+          192.168.4.14;
+          192.168.5.53;
+     };
+};
+// We are a slave server for eng.example.com
+zone "eng.example.com" {
+     type slave;
+     file "eng.example.com.bk";
+     // IP address of eng.example.com master server
+     masters { 192.168.4.12; };
+};
+</programlisting>
+
+      </sect2>
+    </sect1>
+
+    <sect1>
+      <title>Load Balancing</title>
+      <!--
+        - Add explanation of why load balancing is fragile at best
+	- and completely pointless in the general case.
+        -->
+
+      <para>
+        A primitive form of load balancing can be achieved in
+        the <acronym>DNS</acronym> by using multiple records
+	(such as multiple A records) for one name.
+      </para>
+
+      <para>
+        For example, if you have three WWW servers with network addresses
+        of 10.0.0.1, 10.0.0.2 and 10.0.0.3, a set of records such as the
+        following means that clients will connect to each machine one third
+        of the time:
+      </para>
+
+      <informaltable colsep="0" rowsep="0">
+        <tgroup cols="5" colsep="0" rowsep="0" tgroupstyle="2Level-table">
+          <colspec colname="1" colnum="1" colsep="0" colwidth="0.875in"/>
+          <colspec colname="2" colnum="2" colsep="0" colwidth="0.500in"/>
+          <colspec colname="3" colnum="3" colsep="0" colwidth="0.750in"/>
+          <colspec colname="4" colnum="4" colsep="0" colwidth="0.750in"/>
+          <colspec colname="5" colnum="5" colsep="0" colwidth="2.028in"/>
+          <tbody>
+            <row rowsep="0">
+              <entry colname="1">
+                <para>
+                  Name
+                </para>
+              </entry>
+              <entry colname="2">
+                <para>
+                  TTL
+                </para>
+              </entry>
+              <entry colname="3">
+                <para>
+                  CLASS
+                </para>
+              </entry>
+              <entry colname="4">
+                <para>
+                  TYPE
+                </para>
+              </entry>
+              <entry colname="5">
+                <para>
+                  Resource Record (RR) Data
+                </para>
+              </entry>
+            </row>
+            <row rowsep="0">
+              <entry colname="1">
+                <para>
+                  <literal>www</literal>
+                </para>
+              </entry>
+              <entry colname="2">
+                <para>
+                  <literal>600</literal>
+                </para>
+              </entry>
+              <entry colname="3">
+                <para>
+                  <literal>IN</literal>
+                </para>
+              </entry>
+              <entry colname="4">
+                <para>
+                  <literal>A</literal>
+                </para>
+              </entry>
+              <entry colname="5">
+                <para>
+                  <literal>10.0.0.1</literal>
+                </para>
+              </entry>
+            </row>
+            <row rowsep="0">
+              <entry colname="1">
+                <para/>
+              </entry>
+              <entry colname="2">
+                <para>
+                  <literal>600</literal>
+                </para>
+              </entry>
+              <entry colname="3">
+                <para>
+                  <literal>IN</literal>
+                </para>
+              </entry>
+              <entry colname="4">
+                <para>
+                  <literal>A</literal>
+                </para>
+              </entry>
+              <entry colname="5">
+                <para>
+                  <literal>10.0.0.2</literal>
+                </para>
+              </entry>
+            </row>
+            <row rowsep="0">
+              <entry colname="1">
+                <para/>
+              </entry>
+              <entry colname="2">
+                <para>
+                  <literal>600</literal>
+                </para>
+              </entry>
+              <entry colname="3">
+                <para>
+                  <literal>IN</literal>
+                </para>
+              </entry>
+              <entry colname="4">
+                <para>
+                  <literal>A</literal>
+                </para>
+              </entry>
+              <entry colname="5">
+                <para>
+                  <literal>10.0.0.3</literal>
+                </para>
+              </entry>
+            </row>
+          </tbody>
+        </tgroup>
+      </informaltable>
+      <para>
+        When a resolver queries for these records, <acronym>BIND</acronym> will rotate
+        them and respond to the query with the records in a different
+        order.  In the example above, clients will randomly receive
+        records in the order 1, 2, 3; 2, 3, 1; and 3, 1, 2. Most clients
+        will use the first record returned and discard the rest.
+      </para>
+      <para>
+        For more detail on ordering responses, check the
+        <command>rrset-order</command> substatement in the
+        <command>options</command> statement, see
+        <xref endterm="rrset_ordering_title" linkend="rrset_ordering"/>.
+      </para>
+
+    </sect1>
+
+    <sect1>
+      <title>Name Server Operations</title>
+
+      <sect2>
+        <title>Tools for Use With the Name Server Daemon</title>
+        <para>
+          This section describes several indispensable diagnostic,
+          administrative and monitoring tools available to the system
+          administrator for controlling and debugging the name server
+          daemon.
+        </para>
+        <sect3 id="diagnostic_tools">
+          <title>Diagnostic Tools</title>
+          <para>
+            The <command>dig</command>, <command>host</command>, and
+            <command>nslookup</command> programs are all command
+            line tools
+            for manually querying name servers.  They differ in style and
+            output format.
+          </para>
+
+          <variablelist>
+            <varlistentry>
+              <term id="dig"><command>dig</command></term>
+              <listitem>
+                <para>
+                  The domain information groper (<command>dig</command>)
+                  is the most versatile and complete of these lookup tools.
+                  It has two modes: simple interactive
+                  mode for a single query, and batch mode which executes a
+                  query for
+                  each in a list of several query lines. All query options are
+                  accessible
+                  from the command line.
+                </para>
+                <cmdsynopsis label="Usage">
+                  <command>dig</command>
+                  <arg>@<replaceable>server</replaceable></arg>
+                  <arg choice="plain"><replaceable>domain</replaceable></arg>
+                  <arg><replaceable>query-type</replaceable></arg>
+                  <arg><replaceable>query-class</replaceable></arg>
+                  <arg>+<replaceable>query-option</replaceable></arg>
+                  <arg>-<replaceable>dig-option</replaceable></arg>
+                  <arg>%<replaceable>comment</replaceable></arg>
+                </cmdsynopsis>
+                <para>
+                  The usual simple use of dig will take the form
+                </para>
+                <simpara>
+                  <command>dig @server domain query-type query-class</command>
+                </simpara>
+                <para>
+                  For more information and a list of available commands and
+                  options, see the <command>dig</command> man
+                  page.
+                </para>
+              </listitem>
+            </varlistentry>
+
+            <varlistentry>
+              <term><command>host</command></term>
+              <listitem>
+                <para>
+                  The <command>host</command> utility emphasizes
+                  simplicity
+                  and ease of use.  By default, it converts
+                  between host names and Internet addresses, but its
+                  functionality
+                  can be extended with the use of options.
+                </para>
+                <cmdsynopsis label="Usage">
+                  <command>host</command>
+                  <arg>-aCdlnrsTwv</arg>
+                  <arg>-c <replaceable>class</replaceable></arg>
+                  <arg>-N <replaceable>ndots</replaceable></arg>
+                  <arg>-t <replaceable>type</replaceable></arg>
+                  <arg>-W <replaceable>timeout</replaceable></arg>
+                  <arg>-R <replaceable>retries</replaceable></arg>
+                  <arg>-m <replaceable>flag</replaceable></arg>
+		  <arg>-4</arg>
+		  <arg>-6</arg>
+                  <arg choice="plain"><replaceable>hostname</replaceable></arg>
+                  <arg><replaceable>server</replaceable></arg>
+                </cmdsynopsis>
+                <para>
+                  For more information and a list of available commands and
+                  options, see the <command>host</command> man
+                  page.
+                </para>
+              </listitem>
+            </varlistentry>
+
+            <varlistentry>
+              <term><command>nslookup</command></term>
+              <listitem>
+                <para><command>nslookup</command>
+		  has two modes: interactive and
+                  non-interactive. Interactive mode allows the user to
+                  query name servers for information about various
+                  hosts and domains or to print a list of hosts in a
+                  domain. Non-interactive mode is used to print just
+                  the name and requested information for a host or
+                  domain.
+                </para>
+                <cmdsynopsis label="Usage">
+                  <command>nslookup</command>
+                  <arg rep="repeat">-option</arg>
+                  <group>
+                    <arg><replaceable>host-to-find</replaceable></arg>
+                    <arg>- <arg>server</arg></arg>
+                  </group>
+                </cmdsynopsis>
+                <para>
+                  Interactive mode is entered when no arguments are given (the
+                  default name server will be used) or when the first argument
+                  is a
+                  hyphen (`-') and the second argument is the host name or
+                  Internet address
+                  of a name server.
+                </para>
+                <para>
+                  Non-interactive mode is used when the name or Internet
+                  address
+                  of the host to be looked up is given as the first argument.
+                  The
+                  optional second argument specifies the host name or address
+                  of a name server.
+                </para>
+                <para>
+                  Due to its arcane user interface and frequently inconsistent
+                  behavior, we do not recommend the use of <command>nslookup</command>.
+                  Use <command>dig</command> instead.
+                </para>
+              </listitem>
+
+            </varlistentry>
+          </variablelist>
+        </sect3>
+
+        <sect3 id="admin_tools">
+          <title>Administrative Tools</title>
+          <para>
+            Administrative tools play an integral part in the management
+            of a server.
+          </para>
+          <variablelist>
+            <varlistentry id="named-checkconf" xreflabel="Named Configuration Checking application">
+
+              <term><command>named-checkconf</command></term>
+              <listitem>
+                <para>
+                  The <command>named-checkconf</command> program
+                  checks the syntax of a <filename>named.conf</filename> file.
+                </para>
+                <cmdsynopsis label="Usage">
+                  <command>named-checkconf</command>
+                  <arg>-jvz</arg>
+                  <arg>-t <replaceable>directory</replaceable></arg>
+                  <arg><replaceable>filename</replaceable></arg>
+                </cmdsynopsis>
+              </listitem>
+            </varlistentry>
+            <varlistentry id="named-checkzone" xreflabel="Zone Checking application">
+
+              <term><command>named-checkzone</command></term>
+              <listitem>
+                <para>
+                  The <command>named-checkzone</command> program
+                  checks a master file for
+                  syntax and consistency.
+                </para>
+                <cmdsynopsis label="Usage">
+                  <command>named-checkzone</command>
+                  <arg>-djqvD</arg>
+                  <arg>-c <replaceable>class</replaceable></arg>
+                  <arg>-o <replaceable>output</replaceable></arg>
+                  <arg>-t <replaceable>directory</replaceable></arg>
+                  <arg>-w <replaceable>directory</replaceable></arg>
+                  <arg>-k <replaceable>(ignore|warn|fail)</replaceable></arg>
+                  <arg>-n <replaceable>(ignore|warn|fail)</replaceable></arg>
+                  <arg>-W <replaceable>(ignore|warn)</replaceable></arg>
+                  <arg choice="plain"><replaceable>zone</replaceable></arg>
+                  <arg><replaceable>filename</replaceable></arg>
+                </cmdsynopsis>
+              </listitem>
+            </varlistentry>
+	    <varlistentry id="named-compilezone" xreflabel="Zone Compilation aplication">
+	      <term><command>named-compilezone</command></term>
+	      <listitem>
+		<para>
+		  Similar to <command>named-checkzone,</command> but
+		  it always dumps the zone content to a specified file
+		  (typically in a different format).
+		</para>
+	      </listitem>
+	    </varlistentry>
+            <varlistentry id="rndc" xreflabel="Remote Name Daemon Control application">
+
+              <term><command>rndc</command></term>
+              <listitem>
+                <para>
+                  The remote name daemon control
+                  (<command>rndc</command>) program allows the
+                  system
+                  administrator to control the operation of a name server.
+                  Since <acronym>BIND</acronym> 9.2, <command>rndc</command>
+                  supports all the commands of the BIND 8 <command>ndc</command>
+                  utility except <command>ndc start</command> and
+                  <command>ndc restart</command>, which were also
+                  not supported in <command>ndc</command>'s
+                  channel mode.
+                  If you run <command>rndc</command> without any
+                  options
+                  it will display a usage message as follows:
+                </para>
+                <cmdsynopsis label="Usage">
+                  <command>rndc</command>
+                  <arg>-c <replaceable>config</replaceable></arg>
+                  <arg>-s <replaceable>server</replaceable></arg>
+                  <arg>-p <replaceable>port</replaceable></arg>
+                  <arg>-y <replaceable>key</replaceable></arg>
+                  <arg choice="plain"><replaceable>command</replaceable></arg>
+                  <arg rep="repeat"><replaceable>command</replaceable></arg>
+                </cmdsynopsis>
+                <para>The <command>command</command>
+		  is one of the following:
+                </para>
+
+                <variablelist>
+
+                  <varlistentry>
+                    <term><userinput>reload</userinput></term>
+                    <listitem>
+                      <para>
+                        Reload configuration file and zones.
+                      </para>
+                    </listitem>
+                  </varlistentry>
+
+                  <varlistentry>
+                    <term><userinput>reload <replaceable>zone</replaceable>
+                        <optional><replaceable>class</replaceable>
+           <optional><replaceable>view</replaceable></optional></optional></userinput></term>
+                    <listitem>
+                      <para>
+                        Reload the given zone.
+                      </para>
+                    </listitem>
+                  </varlistentry>
+
+                  <varlistentry>
+                    <term><userinput>refresh <replaceable>zone</replaceable>
+                        <optional><replaceable>class</replaceable>
+           <optional><replaceable>view</replaceable></optional></optional></userinput></term>
+                    <listitem>
+                      <para>
+                        Schedule zone maintenance for the given zone.
+                      </para>
+                    </listitem>
+                  </varlistentry>
+
+                  <varlistentry>
+                    <term><userinput>retransfer <replaceable>zone</replaceable>
+
+                        <optional><replaceable>class</replaceable>
+           <optional><replaceable>view</replaceable></optional></optional></userinput></term>
+                    <listitem>
+                      <para>
+                        Retransfer the given zone from the master.
+                      </para>
+                    </listitem>
+                  </varlistentry>
+
+                  <varlistentry>
+
+                    <term><userinput>freeze
+                        <optional><replaceable>zone</replaceable>
+       <optional><replaceable>class</replaceable>
+           <optional><replaceable>view</replaceable></optional></optional></optional></userinput></term>
+                    <listitem>
+                      <para>
+                        Suspend updates to a dynamic zone.  If no zone is
+                        specified,
+                        then all zones are suspended.  This allows manual
+                        edits to be made to a zone normally updated by dynamic
+                        update.  It
+                        also causes changes in the journal file to be synced
+                        into the master
+                        and the journal file to be removed.  All dynamic
+                        update attempts will
+                        be refused while the zone is frozen.
+                      </para>
+                    </listitem>
+                  </varlistentry>
+
+                  <varlistentry>
+                    <term><userinput>thaw
+                        <optional><replaceable>zone</replaceable>
+       <optional><replaceable>class</replaceable>
+           <optional><replaceable>view</replaceable></optional></optional></optional></userinput></term>
+                    <listitem>
+                      <para>
+                        Enable updates to a frozen dynamic zone.  If no zone
+                        is
+                        specified, then all frozen zones are enabled.  This
+                        causes
+                        the server to reload the zone from disk, and
+                        re-enables dynamic updates
+                        after the load has completed.  After a zone is thawed,
+                        dynamic updates
+                        will no longer be refused.
+                      </para>
+                    </listitem>
+                  </varlistentry>
+
+                  <varlistentry>
+                    <term><userinput>notify <replaceable>zone</replaceable>
+                        <optional><replaceable>class</replaceable>
+           <optional><replaceable>view</replaceable></optional></optional></userinput></term>
+                    <listitem>
+                      <para>
+                        Resend NOTIFY messages for the zone.
+                      </para>
+                    </listitem>
+                  </varlistentry>
+
+                  <varlistentry>
+                    <term><userinput>reconfig</userinput></term>
+                    <listitem>
+                      <para>
+                        Reload the configuration file and load new zones,
+                        but do not reload existing zone files even if they
+                        have changed.
+                        This is faster than a full <command>reload</command> when there
+                        is a large number of zones because it avoids the need
+                        to examine the
+                        modification times of the zones files.
+                      </para>
+                    </listitem>
+                  </varlistentry>
+
+                  <varlistentry>
+                    <term><userinput>stats</userinput></term>
+                    <listitem>
+                      <para>
+                        Write server statistics to the statistics file.
+                      </para>
+                    </listitem>
+                  </varlistentry>
+
+                  <varlistentry>
+                    <term><userinput>querylog</userinput></term>
+                    <listitem>
+                      <para>
+                        Toggle query logging. Query logging can also be enabled
+                        by explicitly directing the <command>queries</command>
+                        <command>category</command> to a
+		        <command>channel</command> in the
+                        <command>logging</command> section of
+                        <filename>named.conf</filename> or by specifying
+			<command>querylog yes;</command> in the
+			<command>options</command> section of
+			<filename>named.conf</filename>.
+                      </para>
+                    </listitem>
+                  </varlistentry>
+
+                  <varlistentry>
+                    <term><userinput>dumpdb
+                        <optional>-all|-cache|-zone</optional>
+                        <optional><replaceable>view ...</replaceable></optional></userinput></term>
+                    <listitem>
+                      <para>
+                        Dump the server's caches (default) and/or zones to
+                        the
+                        dump file for the specified views.  If no view is
+                        specified, all
+                        views are dumped.
+                      </para>
+                    </listitem>
+                  </varlistentry>
+
+                  <varlistentry>
+                    <term><userinput>stop <optional>-p</optional></userinput></term>
+                    <listitem>
+                      <para>
+                        Stop the server, making sure any recent changes
+                        made through dynamic update or IXFR are first saved to
+                        the master files of the updated zones.
+			If -p is specified named's process id is returned.
+			This allows an external process to determine when named
+			had completed stopping.
+                      </para>
+                    </listitem>
+                  </varlistentry>
+
+                  <varlistentry>
+                    <term><userinput>halt <optional>-p</optional></userinput></term>
+                    <listitem>
+                      <para>
+                        Stop the server immediately.  Recent changes
+                        made through dynamic update or IXFR are not saved to
+                        the master files, but will be rolled forward from the
+			journal files when the server is restarted.
+			If -p is specified named's process id is returned.
+			This allows an external process to determine when named
+			had completed halting.
+                      </para>
+                    </listitem>
+                  </varlistentry>
+
+                  <varlistentry>
+                    <term><userinput>trace</userinput></term>
+                    <listitem>
+                      <para>
+                        Increment the servers debugging level by one.
+                      </para>
+                    </listitem>
+                  </varlistentry>
+
+                  <varlistentry>
+                    <term><userinput>trace <replaceable>level</replaceable></userinput></term>
+                    <listitem>
+                      <para>
+                        Sets the server's debugging level to an explicit
+                        value.
+                      </para>
+                    </listitem>
+                  </varlistentry>
+
+                  <varlistentry>
+                    <term><userinput>notrace</userinput></term>
+                    <listitem>
+                      <para>
+                        Sets the server's debugging level to 0.
+                      </para>
+                    </listitem>
+                  </varlistentry>
+
+                  <varlistentry>
+                    <term><userinput>flush</userinput></term>
+                    <listitem>
+                      <para>
+                        Flushes the server's cache.
+                      </para>
+                    </listitem>
+                  </varlistentry>
+
+                  <varlistentry>
+                    <term><userinput>flushname</userinput> <replaceable>name</replaceable></term>
+                    <listitem>
+                      <para>
+                        Flushes the given name from the server's cache.
+                      </para>
+                    </listitem>
+                  </varlistentry>
+
+                  <varlistentry>
+                    <term><userinput>status</userinput></term>
+                    <listitem>
+                      <para>
+                        Display status of the server.
+                        Note that the number of zones includes the internal <command>bind/CH</command> zone
+                        and the default <command>./IN</command>
+                        hint zone if there is not an
+                        explicit root zone configured.
+                      </para>
+                    </listitem>
+                  </varlistentry>
+
+                  <varlistentry>
+                    <term><userinput>recursing</userinput></term>
+                    <listitem>
+                      <para>
+                        Dump the list of queries named is currently recursing
+                        on.
+                      </para>
+                    </listitem>
+                  </varlistentry>
+
+                </variablelist>
+
+                <para>
+                  A configuration file is required, since all
+                  communication with the server is authenticated with
+                  digital signatures that rely on a shared secret, and
+                  there is no way to provide that secret other than with a
+                  configuration file.  The default location for the
+                  <command>rndc</command> configuration file is
+                  <filename>/etc/rndc.conf</filename>, but an
+                  alternate
+                  location can be specified with the <option>-c</option>
+                  option.  If the configuration file is not found,
+                  <command>rndc</command> will also look in
+                  <filename>/etc/rndc.key</filename> (or whatever
+                  <varname>sysconfdir</varname> was defined when
+                  the <acronym>BIND</acronym> build was
+                  configured).
+                  The <filename>rndc.key</filename> file is
+                  generated by
+                  running <command>rndc-confgen -a</command> as
+                  described in
+                  <xref linkend="controls_statement_definition_and_usage"/>.
+                </para>
+
+                <para>
+                  The format of the configuration file is similar to
+                  that of <filename>named.conf</filename>, but
+                  limited to
+                  only four statements, the <command>options</command>,
+                  <command>key</command>, <command>server</command> and
+                  <command>include</command>
+                  statements.  These statements are what associate the
+                  secret keys to the servers with which they are meant to
+                  be shared.  The order of statements is not
+                  significant.
+                </para>
+
+                <para>
+                  The <command>options</command> statement has
+                  three clauses:
+                  <command>default-server</command>, <command>default-key</command>,
+                  and <command>default-port</command>.
+                  <command>default-server</command> takes a
+                  host name or address argument  and represents the server
+                  that will
+                  be contacted if no <option>-s</option>
+                  option is provided on the command line.
+                  <command>default-key</command> takes
+                  the name of a key as its argument, as defined by a <command>key</command> statement.
+                  <command>default-port</command> specifies the
+                  port to which
+                  <command>rndc</command> should connect if no
+                  port is given on the command line or in a
+                  <command>server</command> statement.
+                </para>
+
+                <para>
+                  The <command>key</command> statement defines a
+                  key to be used
+                  by <command>rndc</command> when authenticating
+                  with
+                  <command>named</command>.  Its syntax is
+                  identical to the
+                  <command>key</command> statement in named.conf.
+                  The keyword <userinput>key</userinput> is
+                  followed by a key name, which must be a valid
+                  domain name, though it need not actually be hierarchical;
+                  thus,
+                  a string like "<userinput>rndc_key</userinput>" is a valid
+                  name.
+                  The <command>key</command> statement has two
+                  clauses:
+                  <command>algorithm</command> and <command>secret</command>.
+                  While the configuration parser will accept any string as the
+                  argument
+                  to algorithm, currently only the string "<userinput>hmac-md5</userinput>"
+                  has any meaning.  The secret is a base-64 encoded string
+		  as specified in RFC 3548.
+                </para>
+
+                <para>
+                  The <command>server</command> statement
+                  associates a key
+                  defined using the <command>key</command>
+                  statement with a server.
+                  The keyword <userinput>server</userinput> is followed by a
+                  host name or address.  The <command>server</command> statement
+                  has two clauses: <command>key</command> and <command>port</command>.
+                  The <command>key</command> clause specifies the
+                  name of the key
+                  to be used when communicating with this server, and the
+                  <command>port</command> clause can be used to
+                  specify the port <command>rndc</command> should
+                  connect
+                  to on the server.
+                </para>
+
+                <para>
+                  A sample minimal configuration file is as follows:
+                </para>
+
+<programlisting>
+key rndc_key {
+     algorithm "hmac-md5";
+     secret "c3Ryb25nIGVub3VnaCBmb3IgYSBtYW4gYnV0IG1hZGUgZm9yIGEgd29tYW4K";
+};
+options {
+     default-server 127.0.0.1;
+     default-key    rndc_key;
+};
+</programlisting>
+
+                <para>
+                  This file, if installed as <filename>/etc/rndc.conf</filename>,
+                  would allow the command:
+                </para>
+
+                <para>
+                  <prompt>$ </prompt><userinput>rndc reload</userinput>
+                </para>
+
+                <para>
+                  to connect to 127.0.0.1 port 953 and cause the name server
+                  to reload, if a name server on the local machine were
+                  running with
+                  following controls statements:
+                </para>
+
+<programlisting>
+controls {
+        inet 127.0.0.1 allow { localhost; } keys { rndc_key; };
+};
+</programlisting>
+
+                <para>
+                  and it had an identical key statement for
+                  <literal>rndc_key</literal>.
+                </para>
+
+                <para>
+                  Running the <command>rndc-confgen</command>
+                  program will
+                  conveniently create a <filename>rndc.conf</filename>
+                  file for you, and also display the
+                  corresponding <command>controls</command>
+                  statement that you need to
+                  add to <filename>named.conf</filename>.
+                  Alternatively,
+                  you can run <command>rndc-confgen -a</command>
+                  to set up
+                  a <filename>rndc.key</filename> file and not
+                  modify
+                  <filename>named.conf</filename> at all.
+                </para>
+
+              </listitem>
+            </varlistentry>
+          </variablelist>
+
+        </sect3>
+      </sect2>
+      <sect2>
+
+        <title>Signals</title>
+        <para>
+          Certain UNIX signals cause the name server to take specific
+          actions, as described in the following table.  These signals can
+          be sent using the <command>kill</command> command.
+        </para>
+        <informaltable frame="all">
+          <tgroup cols="2">
+            <colspec colname="1" colnum="1" colsep="0" colwidth="1.125in"/>
+            <colspec colname="2" colnum="2" colsep="0" colwidth="4.000in"/>
+            <tbody>
+              <row rowsep="0">
+                <entry colname="1">
+                  <para><command>SIGHUP</command></para>
+                </entry>
+                <entry colname="2">
+                  <para>
+                    Causes the server to read <filename>named.conf</filename> and
+                    reload the database.
+                  </para>
+                </entry>
+              </row>
+              <row rowsep="0">
+                <entry colname="1">
+                  <para><command>SIGTERM</command></para>
+                </entry>
+                <entry colname="2">
+                  <para>
+                    Causes the server to clean up and exit.
+                  </para>
+                </entry>
+              </row>
+              <row rowsep="0">
+                <entry colname="1">
+                  <para><command>SIGINT</command></para>
+                </entry>
+                <entry colname="2">
+                  <para>
+                    Causes the server to clean up and exit.
+                  </para>
+                </entry>
+              </row>
+            </tbody>
+          </tgroup>
+        </informaltable>
+      </sect2>
+    </sect1>
+  </chapter>
+
+  <chapter id="Bv9ARM.ch04">
+    <title>Advanced DNS Features</title>
+
+    <sect1 id="notify">
+
+      <title>Notify</title>
+      <para>
+        <acronym>DNS</acronym> NOTIFY is a mechanism that allows master
+        servers to notify their slave servers of changes to a zone's data. In
+        response to a <command>NOTIFY</command> from a master server, the
+        slave will check to see that its version of the zone is the
+        current version and, if not, initiate a zone transfer.
+      </para>
+
+      <para>
+        For more information about <acronym>DNS</acronym>
+        <command>NOTIFY</command>, see the description of the
+        <command>notify</command> option in <xref linkend="boolean_options"/> and
+        the description of the zone option <command>also-notify</command> in
+        <xref linkend="zone_transfers"/>.  The <command>NOTIFY</command>
+        protocol is specified in RFC 1996.
+      </para>
+
+      <note>
+	As a slave zone can also be a master to other slaves, named,
+        by default, sends <command>NOTIFY</command> messages for every zone
+	it loads.  Specifying <command>notify master-only;</command> will
+	cause named to only send <command>NOTIFY</command> for master
+	zones that it loads.
+      </note>
+
+    </sect1>
+
+    <sect1 id="dynamic_update">
+      <title>Dynamic Update</title>
+
+      <para>
+        Dynamic Update is a method for adding, replacing or deleting
+        records in a master server by sending it a special form of DNS
+        messages.  The format and meaning of these messages is specified
+        in RFC 2136.
+      </para>
+
+      <para>
+        Dynamic update is enabled by
+        including an <command>allow-update</command> or
+        <command>update-policy</command> clause in the
+        <command>zone</command> statement.
+      </para>
+
+      <para>
+        Updating of secure zones (zones using DNSSEC) follows
+        RFC 3007: RRSIG and NSEC records affected by updates are automatically
+            regenerated by the server using an online zone key.
+        Update authorization is based
+        on transaction signatures and an explicit server policy.
+      </para>
+
+      <sect2 id="journal">
+        <title>The journal file</title>
+
+        <para>
+          All changes made to a zone using dynamic update are stored
+          in the zone's journal file.  This file is automatically created
+          by the server when the first dynamic update takes place.
+          The name of the journal file is formed by appending the extension
+          <filename>.jnl</filename> to the name of the
+          corresponding zone
+          file unless specifically overridden.  The journal file is in a
+          binary format and should not be edited manually.
+        </para>
+
+        <para>
+          The server will also occasionally write ("dump")
+          the complete contents of the updated zone to its zone file.
+          This is not done immediately after
+          each dynamic update, because that would be too slow when a large
+          zone is updated frequently.  Instead, the dump is delayed by
+          up to 15 minutes, allowing additional updates to take place.
+        </para>
+
+        <para>
+          When a server is restarted after a shutdown or crash, it will replay
+              the journal file to incorporate into the zone any updates that
+          took
+          place after the last zone dump.
+        </para>
+
+        <para>
+          Changes that result from incoming incremental zone transfers are
+          also
+          journalled in a similar way.
+        </para>
+
+        <para>
+          The zone files of dynamic zones cannot normally be edited by
+          hand because they are not guaranteed to contain the most recent
+          dynamic changes &mdash; those are only in the journal file.
+          The only way to ensure that the zone file of a dynamic zone
+          is up to date is to run <command>rndc stop</command>.
+        </para>
+
+        <para>
+          If you have to make changes to a dynamic zone
+          manually, the following procedure will work: Disable dynamic updates
+              to the zone using
+          <command>rndc freeze <replaceable>zone</replaceable></command>.
+          This will also remove the zone's <filename>.jnl</filename> file
+          and update the master file.  Edit the zone file.  Run
+          <command>rndc thaw <replaceable>zone</replaceable></command>
+          to reload the changed zone and re-enable dynamic updates.
+        </para>
+
+      </sect2>
+
+    </sect1>
+
+    <sect1 id="incremental_zone_transfers">
+      <title>Incremental Zone Transfers (IXFR)</title>
+
+      <para>
+        The incremental zone transfer (IXFR) protocol is a way for
+        slave servers to transfer only changed data, instead of having to
+        transfer the entire zone. The IXFR protocol is specified in RFC
+        1995. See <xref linkend="proposed_standards"/>.
+      </para>
+
+      <para>
+        When acting as a master, <acronym>BIND</acronym> 9
+        supports IXFR for those zones
+        where the necessary change history information is available. These
+        include master zones maintained by dynamic update and slave zones
+        whose data was obtained by IXFR.  For manually maintained master
+        zones, and for slave zones obtained by performing a full zone
+        transfer (AXFR), IXFR is supported only if the option
+        <command>ixfr-from-differences</command> is set
+        to <userinput>yes</userinput>.
+      </para>
+
+      <para>
+        When acting as a slave, <acronym>BIND</acronym> 9 will
+        attempt to use IXFR unless
+        it is explicitly disabled. For more information about disabling
+        IXFR, see the description of the <command>request-ixfr</command> clause
+        of the <command>server</command> statement.
+      </para>
+    </sect1>
+
+    <sect1>
+      <title>Split DNS</title>
+      <para>
+        Setting up different views, or visibility, of the DNS space to
+        internal and external resolvers is usually referred to as a
+	<emphasis>Split DNS</emphasis> setup. There are several
+        reasons an organization would want to set up its DNS this way.
+      </para>
+      <para>
+        One common reason for setting up a DNS system this way is
+        to hide "internal" DNS information from "external" clients on the
+        Internet. There is some debate as to whether or not this is actually
+        useful.
+        Internal DNS information leaks out in many ways (via email headers,
+        for example) and most savvy "attackers" can find the information
+        they need using other means.
+	However, since listing addresses of internal servers that
+        external clients cannot possibly reach can result in
+        connection delays and other annoyances, an organization may
+        choose to use a Split DNS to present a consistent view of itself
+        to the outside world.
+      </para>
+      <para>
+        Another common reason for setting up a Split DNS system is
+        to allow internal networks that are behind filters or in RFC 1918
+        space (reserved IP space, as documented in RFC 1918) to resolve DNS
+        on the Internet. Split DNS can also be used to allow mail from outside
+        back in to the internal network.
+      </para>
+     <sect2>
+      <title>Example split DNS setup</title>
+      <para>
+        Let's say a company named <emphasis>Example, Inc.</emphasis>
+        (<literal>example.com</literal>)
+        has several corporate sites that have an internal network with
+        reserved
+        Internet Protocol (IP) space and an external demilitarized zone (DMZ),
+        or "outside" section of a network, that is available to the public.
+      </para>
+      <para>
+        <emphasis>Example, Inc.</emphasis> wants its internal clients
+        to be able to resolve external hostnames and to exchange mail with
+        people on the outside. The company also wants its internal resolvers
+        to have access to certain internal-only zones that are not available
+        at all outside of the internal network.
+      </para>
+      <para>
+        In order to accomplish this, the company will set up two sets
+        of name servers. One set will be on the inside network (in the
+        reserved
+        IP space) and the other set will be on bastion hosts, which are
+        "proxy"
+        hosts that can talk to both sides of its network, in the DMZ.
+      </para>
+      <para>
+        The internal servers will be configured to forward all queries,
+        except queries for <filename>site1.internal</filename>, <filename>site2.internal</filename>, <filename>site1.example.com</filename>,
+        and <filename>site2.example.com</filename>, to the servers
+        in the
+        DMZ. These internal servers will have complete sets of information
+        for <filename>site1.example.com</filename>, <filename>site2.example.com</filename>,<emphasis/> <filename>site1.internal</filename>,
+        and <filename>site2.internal</filename>.
+      </para>
+      <para>
+        To protect the <filename>site1.internal</filename> and <filename>site2.internal</filename> domains,
+        the internal name servers must be configured to disallow all queries
+        to these domains from any external hosts, including the bastion
+        hosts.
+      </para>
+      <para>
+        The external servers, which are on the bastion hosts, will
+        be configured to serve the "public" version of the <filename>site1</filename> and <filename>site2.example.com</filename> zones.
+        This could include things such as the host records for public servers
+        (<filename>www.example.com</filename> and <filename>ftp.example.com</filename>),
+        and mail exchange (MX)  records (<filename>a.mx.example.com</filename> and <filename>b.mx.example.com</filename>).
+      </para>
+      <para>
+        In addition, the public <filename>site1</filename> and <filename>site2.example.com</filename> zones
+        should have special MX records that contain wildcard (`*') records
+        pointing to the bastion hosts. This is needed because external mail
+        servers do not have any other way of looking up how to deliver mail
+        to those internal hosts. With the wildcard records, the mail will
+        be delivered to the bastion host, which can then forward it on to
+        internal hosts.
+      </para>
+      <para>
+        Here's an example of a wildcard MX record:
+      </para>
+      <programlisting>*   IN MX 10 external1.example.com.</programlisting>
+      <para>
+        Now that they accept mail on behalf of anything in the internal
+        network, the bastion hosts will need to know how to deliver mail
+        to internal hosts. In order for this to work properly, the resolvers
+        on
+        the bastion hosts will need to be configured to point to the internal
+        name servers for DNS resolution.
+      </para>
+      <para>
+        Queries for internal hostnames will be answered by the internal
+        servers, and queries for external hostnames will be forwarded back
+        out to the DNS servers on the bastion hosts.
+      </para>
+      <para>
+        In order for all this to work properly, internal clients will
+        need to be configured to query <emphasis>only</emphasis> the internal
+        name servers for DNS queries. This could also be enforced via
+        selective
+        filtering on the network.
+      </para>
+      <para>
+        If everything has been set properly, <emphasis>Example, Inc.</emphasis>'s
+        internal clients will now be able to:
+      </para>
+      <itemizedlist>
+        <listitem>
+          <simpara>
+            Look up any hostnames in the <literal>site1</literal>
+            and
+            <literal>site2.example.com</literal> zones.
+          </simpara>
+        </listitem>
+        <listitem>
+          <simpara>
+            Look up any hostnames in the <literal>site1.internal</literal> and
+            <literal>site2.internal</literal> domains.
+          </simpara>
+        </listitem>
+        <listitem>
+          <simpara>Look up any hostnames on the Internet.</simpara>
+        </listitem>
+        <listitem>
+          <simpara>Exchange mail with both internal and external people.</simpara>
+        </listitem>
+      </itemizedlist>
+      <para>
+        Hosts on the Internet will be able to:
+      </para>
+      <itemizedlist>
+        <listitem>
+          <simpara>
+            Look up any hostnames in the <literal>site1</literal>
+            and
+            <literal>site2.example.com</literal> zones.
+          </simpara>
+        </listitem>
+        <listitem>
+          <simpara>
+            Exchange mail with anyone in the <literal>site1</literal> and
+            <literal>site2.example.com</literal> zones.
+          </simpara>
+        </listitem>
+      </itemizedlist>
+
+      <para>
+        Here is an example configuration for the setup we just
+        described above. Note that this is only configuration information;
+        for information on how to configure your zone files, see <xref linkend="sample_configuration"/>.
+      </para>
+
+      <para>
+        Internal DNS server config:
+      </para>
+
+<programlisting>
+
+acl internals { 172.16.72.0/24; 192.168.1.0/24; };
+
+acl externals { <varname>bastion-ips-go-here</varname>; };
+
+options {
+    ...
+    ...
+    forward only;
+    forwarders {                                // forward to external servers
+        <varname>bastion-ips-go-here</varname>;
+    };
+    allow-transfer { none; };                   // sample allow-transfer (no one)
+    allow-query { internals; externals; };      // restrict query access
+    allow-recursion { internals; };             // restrict recursion
+    ...
+    ...
+};
+
+zone "site1.example.com" {                      // sample master zone
+  type master;
+  file "m/site1.example.com";
+  forwarders { };                               // do normal iterative
+                                                // resolution (do not forward)
+  allow-query { internals; externals; };
+  allow-transfer { internals; };
+};
+
+zone "site2.example.com" {                      // sample slave zone
+  type slave;
+  file "s/site2.example.com";
+  masters { 172.16.72.3; };
+  forwarders { };
+  allow-query { internals; externals; };
+  allow-transfer { internals; };
+};
+
+zone "site1.internal" {
+  type master;
+  file "m/site1.internal";
+  forwarders { };
+  allow-query { internals; };
+  allow-transfer { internals; }
+};
+
+zone "site2.internal" {
+  type slave;
+  file "s/site2.internal";
+  masters { 172.16.72.3; };
+  forwarders { };
+  allow-query { internals };
+  allow-transfer { internals; }
+};
+</programlisting>
+
+      <para>
+        External (bastion host) DNS server config:
+      </para>
+
+<programlisting>
+acl internals { 172.16.72.0/24; 192.168.1.0/24; };
+
+acl externals { bastion-ips-go-here; };
+
+options {
+  ...
+  ...
+  allow-transfer { none; };                     // sample allow-transfer (no one)
+  allow-query { any; };                         // default query access
+  allow-query-cache { internals; externals; };  // restrict cache access
+  allow-recursion { internals; externals; };    // restrict recursion
+  ...
+  ...
+};
+
+zone "site1.example.com" {                      // sample slave zone
+  type master;
+  file "m/site1.foo.com";
+  allow-transfer { internals; externals; };
+};
+
+zone "site2.example.com" {
+  type slave;
+  file "s/site2.foo.com";
+  masters { another_bastion_host_maybe; };
+  allow-transfer { internals; externals; }
+};
+</programlisting>
+
+      <para>
+        In the <filename>resolv.conf</filename> (or equivalent) on
+        the bastion host(s):
+      </para>
+
+<programlisting>
+search ...
+nameserver 172.16.72.2
+nameserver 172.16.72.3
+nameserver 172.16.72.4
+</programlisting>
+
+     </sect2>
+    </sect1>
+    <sect1 id="tsig">
+      <title>TSIG</title>
+      <para>
+        This is a short guide to setting up Transaction SIGnatures
+        (TSIG) based transaction security in <acronym>BIND</acronym>. It describes changes
+        to the configuration file as well as what changes are required for
+        different features, including the process of creating transaction
+        keys and using transaction signatures with <acronym>BIND</acronym>.
+      </para>
+      <para>
+        <acronym>BIND</acronym> primarily supports TSIG for server
+        to server communication.
+        This includes zone transfer, notify, and recursive query messages.
+        Resolvers based on newer versions of <acronym>BIND</acronym> 8 have limited support
+        for TSIG.
+      </para>
+
+      <para>
+        TSIG can also be useful for dynamic update. A primary
+        server for a dynamic zone should control access to the dynamic
+        update service, but IP-based access control is insufficient.
+        The cryptographic access control provided by TSIG
+        is far superior. The <command>nsupdate</command>
+        program supports TSIG via the <option>-k</option> and
+        <option>-y</option> command line options or inline by use
+	of the <command>key</command>.
+      </para>
+
+      <sect2>
+        <title>Generate Shared Keys for Each Pair of Hosts</title>
+        <para>
+          A shared secret is generated to be shared between <emphasis>host1</emphasis> and <emphasis>host2</emphasis>.
+          An arbitrary key name is chosen: "host1-host2.". The key name must
+          be the same on both hosts.
+        </para>
+        <sect3>
+          <title>Automatic Generation</title>
+          <para>
+            The following command will generate a 128-bit (16 byte) HMAC-MD5
+            key as described above. Longer keys are better, but shorter keys
+            are easier to read. Note that the maximum key length is 512 bits;
+            keys longer than that will be digested with MD5 to produce a
+            128-bit key.
+          </para>
+          <para>
+            <userinput>dnssec-keygen -a hmac-md5 -b 128 -n HOST host1-host2.</userinput>
+          </para>
+          <para>
+            The key is in the file <filename>Khost1-host2.+157+00000.private</filename>.
+            Nothing directly uses this file, but the base-64 encoded string
+            following "<literal>Key:</literal>"
+            can be extracted from the file and used as a shared secret:
+          </para>
+          <programlisting>Key: La/E5CjG9O+os1jq0a2jdA==</programlisting>
+          <para>
+            The string "<literal>La/E5CjG9O+os1jq0a2jdA==</literal>" can
+            be used as the shared secret.
+          </para>
+        </sect3>
+        <sect3>
+          <title>Manual Generation</title>
+          <para>
+            The shared secret is simply a random sequence of bits, encoded
+            in base-64. Most ASCII strings are valid base-64 strings (assuming
+            the length is a multiple of 4 and only valid characters are used),
+            so the shared secret can be manually generated.
+          </para>
+          <para>
+            Also, a known string can be run through <command>mmencode</command> or
+            a similar program to generate base-64 encoded data.
+          </para>
+        </sect3>
+      </sect2>
+      <sect2>
+        <title>Copying the Shared Secret to Both Machines</title>
+        <para>
+          This is beyond the scope of DNS. A secure transport mechanism
+          should be used. This could be secure FTP, ssh, telephone, etc.
+        </para>
+      </sect2>
+      <sect2>
+        <title>Informing the Servers of the Key's Existence</title>
+        <para>
+          Imagine <emphasis>host1</emphasis> and <emphasis>host 2</emphasis>
+          are
+          both servers. The following is added to each server's <filename>named.conf</filename> file:
+        </para>
+
+<programlisting>
+key host1-host2. {
+  algorithm hmac-md5;
+  secret "La/E5CjG9O+os1jq0a2jdA==";
+};
+</programlisting>
+
+        <para>
+          The algorithm, hmac-md5, is the only one supported by <acronym>BIND</acronym>.
+          The secret is the one generated above. Since this is a secret, it
+          is recommended that either <filename>named.conf</filename> be non-world
+          readable, or the key directive be added to a non-world readable
+          file that is included by
+          <filename>named.conf</filename>.
+        </para>
+        <para>
+          At this point, the key is recognized. This means that if the
+          server receives a message signed by this key, it can verify the
+          signature. If the signature is successfully verified, the
+          response is signed by the same key.
+        </para>
+      </sect2>
+
+      <sect2>
+        <title>Instructing the Server to Use the Key</title>
+        <para>
+          Since keys are shared between two hosts only, the server must
+          be told when keys are to be used. The following is added to the <filename>named.conf</filename> file
+          for <emphasis>host1</emphasis>, if the IP address of <emphasis>host2</emphasis> is
+          10.1.2.3:
+        </para>
+
+<programlisting>
+server 10.1.2.3 {
+  keys { host1-host2. ;};
+};
+</programlisting>
+
+        <para>
+          Multiple keys may be present, but only the first is used.
+          This directive does not contain any secrets, so it may be in a
+          world-readable
+          file.
+        </para>
+        <para>
+          If <emphasis>host1</emphasis> sends a message that is a request
+          to that address, the message will be signed with the specified key. <emphasis>host1</emphasis> will
+          expect any responses to signed messages to be signed with the same
+          key.
+        </para>
+        <para>
+          A similar statement must be present in <emphasis>host2</emphasis>'s
+          configuration file (with <emphasis>host1</emphasis>'s address) for <emphasis>host2</emphasis> to
+          sign request messages to <emphasis>host1</emphasis>.
+        </para>
+      </sect2>
+      <sect2>
+        <title>TSIG Key Based Access Control</title>
+        <para>
+          <acronym>BIND</acronym> allows IP addresses and ranges
+          to be specified in ACL
+          definitions and
+          <command>allow-{ query | transfer | update }</command>
+          directives.
+          This has been extended to allow TSIG keys also. The above key would
+          be denoted <command>key host1-host2.</command>
+        </para>
+        <para>
+          An example of an allow-update directive would be:
+        </para>
+
+<programlisting>
+allow-update { key host1-host2. ;};
+</programlisting>
+
+        <para>
+          This allows dynamic updates to succeed only if the request
+          was signed by a key named
+          "<command>host1-host2.</command>".
+        </para>
+	<para>
+          You may want to read about the more
+          powerful <command>update-policy</command> statement in <xref linkend="dynamic_update_policies"/>.
+        </para>
+
+      </sect2>
+      <sect2>
+        <title>Errors</title>
+
+        <para>
+          The processing of TSIG signed messages can result in
+          several errors. If a signed message is sent to a non-TSIG aware
+          server, a FORMERR (format error) will be returned, since the server will not
+          understand the record. This is a result of misconfiguration,
+          since the server must be explicitly configured to send a TSIG
+          signed message to a specific server.
+        </para>
+
+        <para>
+          If a TSIG aware server receives a message signed by an
+          unknown key, the response will be unsigned with the TSIG
+          extended error code set to BADKEY. If a TSIG aware server
+          receives a message with a signature that does not validate, the
+          response will be unsigned with the TSIG extended error code set
+          to BADSIG. If a TSIG aware server receives a message with a time
+          outside of the allowed range, the response will be signed with
+          the TSIG extended error code set to BADTIME, and the time values
+          will be adjusted so that the response can be successfully
+          verified. In any of these cases, the message's rcode (response code) is set to
+          NOTAUTH (not authenticated).
+        </para>
+
+      </sect2>
+    </sect1>
+    <sect1>
+      <title>TKEY</title>
+
+      <para><command>TKEY</command>
+        is a mechanism for automatically generating a shared secret
+        between two hosts.  There are several "modes" of
+        <command>TKEY</command> that specify how the key is generated
+        or assigned.  <acronym>BIND</acronym> 9 implements only one of
+        these modes, the Diffie-Hellman key exchange.  Both hosts are
+        required to have a Diffie-Hellman KEY record (although this
+        record is not required to be present in a zone).  The
+        <command>TKEY</command> process must use signed messages,
+        signed either by TSIG or SIG(0).  The result of
+        <command>TKEY</command> is a shared secret that can be used to
+        sign messages with TSIG.  <command>TKEY</command> can also be
+        used to delete shared secrets that it had previously
+        generated.
+      </para>
+
+      <para>
+        The <command>TKEY</command> process is initiated by a
+        client
+        or server by sending a signed <command>TKEY</command>
+        query
+        (including any appropriate KEYs) to a TKEY-aware server.  The
+        server response, if it indicates success, will contain a
+        <command>TKEY</command> record and any appropriate keys.
+        After
+        this exchange, both participants have enough information to
+        determine the shared secret; the exact process depends on the
+        <command>TKEY</command> mode.  When using the
+        Diffie-Hellman
+        <command>TKEY</command> mode, Diffie-Hellman keys are
+        exchanged,
+        and the shared secret is derived by both participants.
+      </para>
+
+    </sect1>
+    <sect1>
+      <title>SIG(0)</title>
+
+      <para>
+        <acronym>BIND</acronym> 9 partially supports DNSSEC SIG(0)
+            transaction signatures as specified in RFC 2535 and RFC2931.
+        SIG(0)
+        uses public/private keys to authenticate messages.  Access control
+        is performed in the same manner as TSIG keys; privileges can be
+        granted or denied based on the key name.
+      </para>
+
+      <para>
+        When a SIG(0) signed message is received, it will only be
+        verified if the key is known and trusted by the server; the server
+        will not attempt to locate and/or validate the key.
+      </para>
+
+      <para>
+        SIG(0) signing of multiple-message TCP streams is not
+        supported.
+      </para>
+
+      <para>
+        The only tool shipped with <acronym>BIND</acronym> 9 that
+        generates SIG(0) signed messages is <command>nsupdate</command>.
+      </para>
+
+    </sect1>
+    <sect1 id="DNSSEC">
+      <title>DNSSEC</title>
+
+      <para>
+        Cryptographic authentication of DNS information is possible
+        through the DNS Security (<emphasis>DNSSEC-bis</emphasis>) extensions,
+        defined in RFC 4033, RFC 4034, and RFC 4035.
+	This section describes the creation and use of DNSSEC signed zones.
+      </para>
+
+      <para>
+        In order to set up a DNSSEC secure zone, there are a series
+        of steps which must be followed.  <acronym>BIND</acronym>
+        9 ships
+        with several tools
+        that are used in this process, which are explained in more detail
+        below.  In all cases, the <option>-h</option> option prints a
+        full list of parameters.  Note that the DNSSEC tools require the
+        keyset files to be in the working directory or the
+        directory specified by the <option>-d</option> option, and
+        that the tools shipped with BIND 9.2.x and earlier are not compatible
+        with the current ones.
+      </para>
+
+      <para>
+        There must also be communication with the administrators of
+        the parent and/or child zone to transmit keys.  A zone's security
+        status must be indicated by the parent zone for a DNSSEC capable
+        resolver to trust its data.  This is done through the presence
+        or absence of a <literal>DS</literal> record at the
+        delegation
+        point.
+      </para>
+
+      <para>
+        For other servers to trust data in this zone, they must
+        either be statically configured with this zone's zone key or the
+        zone key of another zone above this one in the DNS tree.
+      </para>
+
+      <sect2>
+        <title>Generating Keys</title>
+
+        <para>
+          The <command>dnssec-keygen</command> program is used to
+          generate keys.
+        </para>
+
+        <para>
+          A secure zone must contain one or more zone keys.  The
+          zone keys will sign all other records in the zone, as well as
+          the zone keys of any secure delegated zones.  Zone keys must
+          have the same name as the zone, a name type of
+          <command>ZONE</command>, and must be usable for
+          authentication.
+          It is recommended that zone keys use a cryptographic algorithm
+          designated as "mandatory to implement" by the IETF; currently
+          the only one is RSASHA1.
+        </para>
+
+        <para>
+          The following command will generate a 768-bit RSASHA1 key for
+          the <filename>child.example</filename> zone:
+        </para>
+
+        <para>
+          <userinput>dnssec-keygen -a RSASHA1 -b 768 -n ZONE child.example.</userinput>
+        </para>
+
+        <para>
+          Two output files will be produced:
+          <filename>Kchild.example.+005+12345.key</filename> and
+          <filename>Kchild.example.+005+12345.private</filename>
+          (where
+          12345 is an example of a key tag).  The key filenames contain
+          the key name (<filename>child.example.</filename>),
+          algorithm (3
+          is DSA, 1 is RSAMD5, 5 is RSASHA1, etc.), and the key tag (12345 in
+          this case).
+          The private key (in the <filename>.private</filename>
+          file) is
+          used to generate signatures, and the public key (in the
+          <filename>.key</filename> file) is used for signature
+          verification.
+        </para>
+
+        <para>
+          To generate another key with the same properties (but with
+          a different key tag), repeat the above command.
+        </para>
+
+        <para>
+          The public keys should be inserted into the zone file by
+          including the <filename>.key</filename> files using
+          <command>$INCLUDE</command> statements.
+        </para>
+
+      </sect2>
+      <sect2>
+        <title>Signing the Zone</title>
+
+        <para>
+          The <command>dnssec-signzone</command> program is used
+          to
+          sign a zone.
+        </para>
+
+        <para>
+          Any <filename>keyset</filename> files corresponding
+          to secure subzones should be present.  The zone signer will
+          generate <literal>NSEC</literal> and <literal>RRSIG</literal>
+          records for the zone, as well as <literal>DS</literal>
+          for
+          the child zones if <literal>'-d'</literal> is specified.
+                If <literal>'-d'</literal> is not specified, then
+          DS RRsets for
+          the secure child zones need to be added manually.
+        </para>
+
+        <para>
+          The following command signs the zone, assuming it is in a
+          file called <filename>zone.child.example</filename>.  By
+                default, all zone keys which have an available private key are
+                used to generate signatures.
+        </para>
+
+        <para>
+          <userinput>dnssec-signzone -o child.example zone.child.example</userinput>
+        </para>
+
+        <para>
+          One output file is produced:
+          <filename>zone.child.example.signed</filename>.  This
+          file
+          should be referenced by <filename>named.conf</filename>
+          as the
+          input file for the zone.
+        </para>
+
+        <para><command>dnssec-signzone</command>
+	  will also produce a keyset and dsset files and optionally a
+          dlvset file.  These are used to provide the parent zone
+          administrators with the <literal>DNSKEYs</literal> (or their
+          corresponding <literal>DS</literal> records) that are the
+          secure entry point to the zone.
+        </para>
+
+      </sect2>
+
+      <sect2>
+        <title>Configuring Servers</title>
+
+	<para>
+	  To enable <command>named</command> to respond appropriately
+	  to DNS requests from DNSSEC aware clients,
+	  <command>dnssec-enable</command> must be set to yes.
+        </para>
+
+	<para>
+	  To enable <command>named</command> to validate answers from
+	  other servers both <command>dnssec-enable</command> and
+	  <command>dnssec-validation</command> must be set and some
+	  <command>trusted-keys</command> must be configured
+	  into <filename>named.conf</filename>.
+        </para>
+	  
+	<para>
+	  <command>trusted-keys</command> are copies of DNSKEY RRs
+	  for zones that are used to form the first link in the
+	  cryptographic chain of trust.  All keys listed in
+	  <command>trusted-keys</command> (and corresponding zones)
+	  are deemed to exist and only the listed keys will be used
+	  to validated the DNSKEY RRset that they are from.
+	</para>
+
+	<para>
+	  <command>trusted-keys</command> are described in more detail
+	  later in this document.
+	</para>
+
+	<para>
+	  Unlike <acronym>BIND</acronym> 8, <acronym>BIND</acronym>
+	  9 does not verify signatures on load, so zone keys for
+	  authoritative zones do not need to be specified in the
+	  configuration file.
+	</para>
+
+	<para>
+	  After DNSSEC gets established, a typical DNSSEC configuration
+	  will look something like the following.  It has a one or
+	  more public keys for the root.  This allows answers from
+	  outside the organization to be validated.  It will also
+	  have several keys for parts of the namespace the organization
+	  controls.  These are here to ensure that named is immune
+	  to compromises in the DNSSEC components of the security
+	  of parent zones.
+	</para>
+
+<programlisting>
+trusted-keys {
+
+	/* Root Key */
+"." 257 3 3 "BNY4wrWM1nCfJ+CXd0rVXyYmobt7sEEfK3clRbGaTwSJxrGkxJWoZu6I7PzJu/
+	     E9gx4UC1zGAHlXKdE4zYIpRhaBKnvcC2U9mZhkdUpd1Vso/HAdjNe8LmMlnzY3
+	     zy2Xy4klWOADTPzSv9eamj8V18PHGjBLaVtYvk/ln5ZApjYghf+6fElrmLkdaz
+	     MQ2OCnACR817DF4BBa7UR/beDHyp5iWTXWSi6XmoJLbG9Scqc7l70KDqlvXR3M
+	     /lUUVRbkeg1IPJSidmK3ZyCllh4XSKbje/45SKucHgnwU5jefMtq66gKodQj+M
+	     iA21AfUVe7u99WzTLzY3qlxDhxYQQ20FQ97S+LKUTpQcq27R7AT3/V5hRQxScI
+	     Nqwcz4jYqZD2fQdgxbcDTClU0CRBdiieyLMNzXG3";
+
+/* Key for our organization's forward zone */
+example.com. 257 3 5 "AwEAAaxPMcR2x0HbQV4WeZB6oEDX+r0QM65KbhTjrW1ZaARmPhEZZe
+                      3Y9ifgEuq7vZ/zGZUdEGNWy+JZzus0lUptwgjGwhUS1558Hb4JKUbb
+	              OTcM8pwXlj0EiX3oDFVmjHO444gLkBO UKUf/mC7HvfwYH/Be22GnC
+		      lrinKJp1Og4ywzO9WglMk7jbfW33gUKvirTHr25GL7STQUzBb5Usxt
+		      8lgnyTUHs1t3JwCY5hKZ6CqFxmAVZP20igTixin/1LcrgX/KMEGd/b
+		      iuvF4qJCyduieHukuY3H4XMAcR+xia2 nIUPvm/oyWR8BW/hWdzOvn
+		      SCThlHf3xiYleDbt/o1OTQ09A0=";
+
+/* Key for our reverse zone. */
+2.0.192.IN-ADDRPA.NET. 257 3 5 "AQOnS4xn/IgOUpBPJ3bogzwcxOdNax071L18QqZnQQQA
+                                VVr+iLhGTnNGp3HoWQLUIzKrJVZ3zggy3WwNT6kZo6c0
+				tszYqbtvchmgQC8CzKojM/W16i6MG/ea fGU3siaOdS0
+				yOI6BgPsw+YZdzlYMaIJGf4M4dyoKIhzdZyQ2bYQrjyQ
+				4LB0lC7aOnsMyYKHHYeRv PxjIQXmdqgOJGq+vsevG06
+			        zW+1xgYJh9rCIfnm1GX/KMgxLPG2vXTD/RnLX+D3T3UL
+				7HJYHJhAZD5L59VvjSPsZJHeDCUyWYrvPZesZDIRvhDD
+				52SKvbheeTJUm6EhkzytNN2SN96QRk8j/iI8ib";
+};
+
+options {
+	...
+	dnssec-enable yes;
+	dnssec-validation yes;
+};
+</programlisting>
+
+	<note>
+	  None of the keys listed in this example are valid.  In particular,
+	  the root key is not valid.
+	</note>
+
+      </sect2>
+
+    </sect1>
+    <sect1>
+      <title>IPv6 Support in <acronym>BIND</acronym> 9</title>
+
+      <para>
+        <acronym>BIND</acronym> 9 fully supports all currently
+        defined forms of IPv6
+        name to address and address to name lookups.  It will also use
+        IPv6 addresses to make queries when running on an IPv6 capable
+        system.
+      </para>
+
+      <para>
+        For forward lookups, <acronym>BIND</acronym> 9 supports
+        only AAAA records.  RFC 3363 deprecated the use of A6 records,
+        and client-side support for A6 records was accordingly removed
+        from <acronym>BIND</acronym> 9.
+        However, authoritative <acronym>BIND</acronym> 9 name servers still
+        load zone files containing A6 records correctly, answer queries
+        for A6 records, and accept zone transfer for a zone containing A6
+        records.
+      </para>
+
+      <para>
+        For IPv6 reverse lookups, <acronym>BIND</acronym> 9 supports
+        the traditional "nibble" format used in the
+        <emphasis>ip6.arpa</emphasis> domain, as well as the older, deprecated
+        <emphasis>ip6.int</emphasis> domain.
+        Older versions of <acronym>BIND</acronym> 9 
+        supported the "binary label" (also known as "bitstring") format,
+        but support of binary labels has been completely removed per
+        RFC 3363.
+        Many applications in <acronym>BIND</acronym> 9 do not understand
+        the binary label format at all any more, and will return an
+        error if given.
+	In particular, an authoritative <acronym>BIND</acronym> 9
+        name server will not load a zone file containing binary labels.
+      </para>
+
+      <para>
+        For an overview of the format and structure of IPv6 addresses,
+        see <xref linkend="ipv6addresses"/>.
+      </para>
+
+      <sect2>
+        <title>Address Lookups Using AAAA Records</title>
+
+        <para>
+          The IPv6 AAAA record is a parallel to the IPv4 A record,
+          and, unlike the deprecated A6 record, specifies the entire
+          IPv6 address in a single record.  For example,
+        </para>
+
+<programlisting>
+$ORIGIN example.com.
+host            3600    IN      AAAA    2001:db8::1
+</programlisting>
+
+        <para>
+          Use of IPv4-in-IPv6 mapped addresses is not recommended.
+	  If a host has an IPv4 address, use an A record, not
+          a AAAA, with <literal>::ffff:192.168.42.1</literal> as
+          the address.
+        </para>
+      </sect2>
+      <sect2>
+        <title>Address to Name Lookups Using Nibble Format</title>
+
+        <para>
+          When looking up an address in nibble format, the address
+          components are simply reversed, just as in IPv4, and
+          <literal>ip6.arpa.</literal> is appended to the
+          resulting name.
+          For example, the following would provide reverse name lookup for
+          a host with address
+          <literal>2001:db8::1</literal>.
+        </para>
+
+<programlisting>
+$ORIGIN 0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa.
+1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0   14400 IN      PTR     host.example.com.
+</programlisting>
+
+      </sect2>
+    </sect1>
+  </chapter>
+
+  <chapter id="Bv9ARM.ch05">
+    <title>The <acronym>BIND</acronym> 9 Lightweight Resolver</title>
+    <sect1>
+      <title>The Lightweight Resolver Library</title>
+      <para>
+        Traditionally applications have been linked with a stub resolver
+        library that sends recursive DNS queries to a local caching name
+        server.
+      </para>
+      <para>
+        IPv6 once introduced new complexity into the resolution process,
+        such as following A6 chains and DNAME records, and simultaneous
+        lookup of IPv4 and IPv6 addresses.  Though most of the complexity was
+        then removed, these are hard or impossible
+        to implement in a traditional stub resolver.
+      </para>
+      <para>
+        <acronym>BIND</acronym> 9 therefore can also provide resolution
+        services to local clients
+        using a combination of a lightweight resolver library and a resolver
+        daemon process running on the local host.  These communicate using
+        a simple UDP-based protocol, the "lightweight resolver protocol"
+        that is distinct from and simpler than the full DNS protocol.
+      </para>
+    </sect1>
+    <sect1 id="lwresd">
+      <title>Running a Resolver Daemon</title>
+
+      <para>
+        To use the lightweight resolver interface, the system must
+        run the resolver daemon <command>lwresd</command> or a
+        local
+        name server configured with a <command>lwres</command>
+        statement.
+      </para>
+
+      <para>
+        By default, applications using the lightweight resolver library will
+        make
+        UDP requests to the IPv4 loopback address (127.0.0.1) on port 921.
+        The
+        address can be overridden by <command>lwserver</command>
+        lines in
+        <filename>/etc/resolv.conf</filename>.
+      </para>
+
+      <para>
+        The daemon currently only looks in the DNS, but in the future
+        it may use other sources such as <filename>/etc/hosts</filename>,
+        NIS, etc.
+      </para>
+
+      <para>
+        The <command>lwresd</command> daemon is essentially a
+        caching-only name server that responds to requests using the
+        lightweight
+        resolver protocol rather than the DNS protocol.  Because it needs
+        to run on each host, it is designed to require no or minimal
+        configuration.
+        Unless configured otherwise, it uses the name servers listed on
+        <command>nameserver</command> lines in <filename>/etc/resolv.conf</filename>
+        as forwarders, but is also capable of doing the resolution
+        autonomously if
+        none are specified.
+      </para>
+      <para>
+        The <command>lwresd</command> daemon may also be
+        configured with a
+        <filename>named.conf</filename> style configuration file,
+        in
+        <filename>/etc/lwresd.conf</filename> by default.  A name
+        server may also
+        be configured to act as a lightweight resolver daemon using the
+        <command>lwres</command> statement in <filename>named.conf</filename>.
+      </para>
+
+    </sect1>
+  </chapter>
+
+  <chapter id="Bv9ARM.ch06">
+    <title><acronym>BIND</acronym> 9 Configuration Reference</title>
+
+    <para>
+      <acronym>BIND</acronym> 9 configuration is broadly similar
+      to <acronym>BIND</acronym> 8; however, there are a few new
+      areas
+      of configuration, such as views. <acronym>BIND</acronym>
+      8 configuration files should work with few alterations in <acronym>BIND</acronym>
+      9, although more complex configurations should be reviewed to check
+      if they can be more efficiently implemented using the new features
+      found in <acronym>BIND</acronym> 9.
+    </para>
+
+    <para>
+      <acronym>BIND</acronym> 4 configuration files can be
+      converted to the new format
+      using the shell script
+      <filename>contrib/named-bootconf/named-bootconf.sh</filename>.
+    </para>
+    <sect1 id="configuration_file_elements">
+      <title>Configuration File Elements</title>
+      <para>
+        Following is a list of elements used throughout the <acronym>BIND</acronym> configuration
+        file documentation:
+      </para>
+      <informaltable colsep="0" rowsep="0">
+        <tgroup cols="2" colsep="0" rowsep="0" tgroupstyle="2Level-table">
+          <colspec colname="1" colnum="1" colsep="0" colwidth="1.855in"/>
+          <colspec colname="2" colnum="2" colsep="0" colwidth="3.770in"/>
+          <tbody>
+            <row rowsep="0">
+              <entry colname="1">
+                <para>
+                  <varname>acl_name</varname>
+                </para>
+              </entry>
+              <entry colname="2">
+                <para>
+                  The name of an <varname>address_match_list</varname> as
+                  defined by the <command>acl</command> statement.
+                </para>
+              </entry>
+            </row>
+            <row rowsep="0">
+              <entry colname="1">
+                <para>
+                  <varname>address_match_list</varname>
+                </para>
+              </entry>
+              <entry colname="2">
+                <para>
+                  A list of one or more
+                  <varname>ip_addr</varname>,
+                  <varname>ip_prefix</varname>, <varname>key_id</varname>,
+                  or <varname>acl_name</varname> elements, see
+                  <xref linkend="address_match_lists"/>.
+                </para>
+              </entry>
+            </row>
+            <row rowsep="0">
+              <entry colname="1">
+                <para>
+                  <varname>masters_list</varname>
+                </para>
+              </entry>
+              <entry colname="2">
+                <para>
+                  A named list of one or more <varname>ip_addr</varname>
+		  with optional <varname>key_id</varname> and/or
+		  <varname>ip_port</varname>.
+		  A <varname>masters_list</varname> may include other
+		  <varname>masters_lists</varname>.
+                </para>
+              </entry>
+            </row>
+            <row rowsep="0">
+              <entry colname="1">
+                <para>
+                  <varname>domain_name</varname>
+                </para>
+              </entry>
+              <entry colname="2">
+                <para>
+                  A quoted string which will be used as
+                  a DNS name, for example "<literal>my.test.domain</literal>".
+                </para>
+              </entry>
+            </row>
+            <row rowsep="0">
+              <entry colname="1">
+                <para>
+                  <varname>dotted_decimal</varname>
+                </para>
+              </entry>
+              <entry colname="2">
+                <para>
+                  One to four integers valued 0 through
+                  255 separated by dots (`.'), such as <command>123</command>,
+                  <command>45.67</command> or <command>89.123.45.67</command>.
+                </para>
+              </entry>
+            </row>
+            <row rowsep="0">
+              <entry colname="1">
+                <para>
+                  <varname>ip4_addr</varname>
+                </para>
+              </entry>
+              <entry colname="2">
+                <para>
+                  An IPv4 address with exactly four elements
+                  in <varname>dotted_decimal</varname> notation.
+                </para>
+              </entry>
+            </row>
+            <row rowsep="0">
+              <entry colname="1">
+                <para>
+                  <varname>ip6_addr</varname>
+                </para>
+              </entry>
+              <entry colname="2">
+                <para>
+                  An IPv6 address, such as <command>2001:db8::1234</command>.
+                  IPv6 scoped addresses that have ambiguity on their scope
+                  zones must be
+                  disambiguated by an appropriate zone ID with the percent
+                  character
+                  (`%') as delimiter.
+                  It is strongly recommended to use string zone names rather
+                  than
+                  numeric identifiers, in order to be robust against system
+                  configuration changes.
+                  However, since there is no standard mapping for such names
+                  and
+                  identifier values, currently only interface names as link
+                  identifiers
+                  are supported, assuming one-to-one mapping between
+                  interfaces and links.
+                  For example, a link-local address <command>fe80::1</command> on the
+                  link attached to the interface <command>ne0</command>
+                  can be specified as <command>fe80::1%ne0</command>.
+                  Note that on most systems link-local addresses always have
+                  the
+                  ambiguity, and need to be disambiguated.
+                </para>
+              </entry>
+            </row>
+            <row rowsep="0">
+              <entry colname="1">
+                <para>
+                  <varname>ip_addr</varname>
+                </para>
+              </entry>
+              <entry colname="2">
+                <para>
+                  An <varname>ip4_addr</varname> or <varname>ip6_addr</varname>.
+                </para>
+              </entry>
+            </row>
+            <row rowsep="0">
+              <entry colname="1">
+                <para>
+                  <varname>ip_port</varname>
+                </para>
+              </entry>
+              <entry colname="2">
+                <para>
+                  An IP port <varname>number</varname>.
+                  The <varname>number</varname> is limited to 0
+                  through 65535, with values
+                  below 1024 typically restricted to use by processes running
+                  as root.
+                  In some cases, an asterisk (`*') character can be used as a
+                  placeholder to
+                  select a random high-numbered port.
+                </para>
+              </entry>
+            </row>
+            <row rowsep="0">
+              <entry colname="1">
+                <para>
+                  <varname>ip_prefix</varname>
+                </para>
+              </entry>
+              <entry colname="2">
+                <para>
+                  An IP network specified as an <varname>ip_addr</varname>,
+                  followed by a slash (`/') and then the number of bits in the
+                  netmask.
+                  Trailing zeros in a <varname>ip_addr</varname>
+                  may omitted.
+                  For example, <command>127/8</command> is the
+                  network <command>127.0.0.0</command> with
+                  netmask <command>255.0.0.0</command> and <command>1.2.3.0/28</command> is
+                  network <command>1.2.3.0</command> with netmask <command>255.255.255.240</command>.
+                </para>
+              </entry>
+            </row>
+            <row rowsep="0">
+              <entry colname="1">
+                <para>
+                  <varname>key_id</varname>
+                </para>
+              </entry>
+              <entry colname="2">
+                <para>
+                  A <varname>domain_name</varname> representing
+                  the name of a shared key, to be used for transaction
+                  security.
+                </para>
+              </entry>
+            </row>
+            <row rowsep="0">
+              <entry colname="1">
+                <para>
+                  <varname>key_list</varname>
+                </para>
+              </entry>
+              <entry colname="2">
+                <para>
+                  A list of one or more
+                  <varname>key_id</varname>s,
+                  separated by semicolons and ending with a semicolon.
+                </para>
+              </entry>
+            </row>
+            <row rowsep="0">
+              <entry colname="1">
+                <para>
+                  <varname>number</varname>
+                </para>
+              </entry>
+              <entry colname="2">
+                <para>
+                  A non-negative 32-bit integer
+                  (i.e., a number between 0 and 4294967295, inclusive).
+                  Its acceptable value might further
+                  be limited by the context in which it is used.
+                </para>
+              </entry>
+            </row>
+            <row rowsep="0">
+              <entry colname="1">
+                <para>
+                  <varname>path_name</varname>
+                </para>
+              </entry>
+              <entry colname="2">
+                <para>
+                  A quoted string which will be used as
+                  a pathname, such as <filename>zones/master/my.test.domain</filename>.
+                </para>
+              </entry>
+            </row>
+            <row rowsep="0">
+              <entry colname="1">
+                <para>
+                  <varname>size_spec</varname>
+                </para>
+              </entry>
+              <entry colname="2">
+                <para>
+                  A number, the word <userinput>unlimited</userinput>,
+                  or the word <userinput>default</userinput>.
+                </para>
+		<para>
+                  An <varname>unlimited</varname> <varname>size_spec</varname> requests unlimited
+                  use, or the maximum available amount. A <varname>default size_spec</varname> uses
+                  the limit that was in force when the server was started.
+                </para>
+                <para>
+                  A <varname>number</varname> can optionally be
+		  followed by a scaling factor:
+		  <userinput>K</userinput> or <userinput>k</userinput>
+		  for kilobytes,
+		  <userinput>M</userinput> or <userinput>m</userinput>
+		  for megabytes, and
+		  <userinput>G</userinput> or <userinput>g</userinput> for gigabytes,
+                  which scale by 1024, 1024*1024, and 1024*1024*1024
+                  respectively.
+                </para>
+                <para>
+                  The value must be representable as a 64-bit unsigned integer
+                  (0 to 18446744073709551615, inclusive).
+                  Using <varname>unlimited</varname> is the best
+                  way
+                  to safely set a really large number.
+                </para>
+              </entry>
+            </row>
+            <row rowsep="0">
+              <entry colname="1">
+                <para>
+                  <varname>yes_or_no</varname>
+                </para>
+              </entry>
+              <entry colname="2">
+                <para>
+                  Either <userinput>yes</userinput> or <userinput>no</userinput>.
+                  The words <userinput>true</userinput> and <userinput>false</userinput> are
+                  also accepted, as are the numbers <userinput>1</userinput>
+                  and <userinput>0</userinput>.
+                </para>
+              </entry>
+            </row>
+            <row rowsep="0">
+              <entry colname="1">
+                <para>
+                  <varname>dialup_option</varname>
+                </para>
+              </entry>
+              <entry colname="2">
+                <para>
+                  One of <userinput>yes</userinput>,
+                  <userinput>no</userinput>, <userinput>notify</userinput>,
+                  <userinput>notify-passive</userinput>, <userinput>refresh</userinput> or
+                  <userinput>passive</userinput>.
+                  When used in a zone, <userinput>notify-passive</userinput>,
+                  <userinput>refresh</userinput>, and <userinput>passive</userinput>
+                  are restricted to slave and stub zones.
+                </para>
+              </entry>
+            </row>
+          </tbody>
+        </tgroup>
+      </informaltable>
+      <sect2 id="address_match_lists">
+        <title>Address Match Lists</title>
+        <sect3>
+          <title>Syntax</title>
+
+<programlisting><varname>address_match_list</varname> = address_match_list_element ;
+  <optional> address_match_list_element; ... </optional>
+<varname>address_match_list_element</varname> = <optional> ! </optional> (ip_address <optional>/length</optional> |
+   key key_id | acl_name | { address_match_list } )
+</programlisting>
+
+        </sect3>
+        <sect3>
+          <title>Definition and Usage</title>
+          <para>
+            Address match lists are primarily used to determine access
+            control for various server operations. They are also used in
+            the <command>listen-on</command> and <command>sortlist</command>
+            statements. The elements
+            which constitute an address match list can be any of the
+            following:
+          </para>
+          <itemizedlist>
+            <listitem>
+              <simpara>an IP address (IPv4 or IPv6)</simpara>
+            </listitem>
+            <listitem>
+              <simpara>an IP prefix (in `/' notation)</simpara>
+            </listitem>
+            <listitem>
+              <simpara>
+                a key ID, as defined by the <command>key</command>
+                statement
+              </simpara>
+            </listitem>
+            <listitem>
+              <simpara>the name of an address match list defined with
+                the <command>acl</command> statement
+              </simpara>
+            </listitem>
+            <listitem>
+              <simpara>a nested address match list enclosed in braces</simpara>
+            </listitem>
+          </itemizedlist>
+
+          <para>
+            Elements can be negated with a leading exclamation mark (`!'),
+            and the match list names "any", "none", "localhost", and
+            "localnets"
+            are predefined. More information on those names can be found in
+            the description of the acl statement.
+          </para>
+
+          <para>
+            The addition of the key clause made the name of this syntactic
+            element something of a misnomer, since security keys can be used
+            to validate access without regard to a host or network address.
+            Nonetheless,
+            the term "address match list" is still used throughout the
+            documentation.
+          </para>
+
+          <para>
+            When a given IP address or prefix is compared to an address
+            match list, the list is traversed in order until an element
+            matches.
+            The interpretation of a match depends on whether the list is being
+            used
+            for access control, defining listen-on ports, or in a sortlist,
+            and whether the element was negated.
+          </para>
+
+	  <para>
+	    When used as an access control list, a non-negated match
+	    allows access and a negated match denies access. If
+	    there is no match, access is denied. The clauses
+	    <command>allow-notify</command>,
+	    <command>allow-query</command>,
+	    <command>allow-query-cache</command>,
+	    <command>allow-transfer</command>,
+	    <command>allow-update</command>,
+	    <command>allow-update-forwarding</command>, and
+	    <command>blackhole</command> all use address match
+	    lists.  Similarly, the listen-on option will cause the
+	    server to not accept queries on any of the machine's
+	    addresses which do not match the list.
+	  </para>
+
+          <para>
+            Because of the first-match aspect of the algorithm, an element
+            that defines a subset of another element in the list should come
+            before the broader element, regardless of whether either is
+            negated. For
+            example, in
+            <command>1.2.3/24; ! 1.2.3.13;</command> the 1.2.3.13
+            element is
+            completely useless because the algorithm will match any lookup for
+            1.2.3.13 to the 1.2.3/24 element.
+            Using <command>! 1.2.3.13; 1.2.3/24</command> fixes
+            that problem by having 1.2.3.13 blocked by the negation but all
+            other 1.2.3.* hosts fall through.
+          </para>
+        </sect3>
+      </sect2>
+
+      <sect2>
+        <title>Comment Syntax</title>
+
+        <para>
+          The <acronym>BIND</acronym> 9 comment syntax allows for
+          comments to appear
+          anywhere that whitespace may appear in a <acronym>BIND</acronym> configuration
+          file. To appeal to programmers of all kinds, they can be written
+          in the C, C++, or shell/perl style.
+        </para>
+
+        <sect3>
+          <title>Syntax</title>
+
+          <para>
+            <programlisting>/* This is a <acronym>BIND</acronym> comment as in C */</programlisting>
+            <programlisting>// This is a <acronym>BIND</acronym> comment as in C++</programlisting>
+            <programlisting># This is a <acronym>BIND</acronym> comment as in common UNIX shells and perl</programlisting>
+          </para>
+        </sect3>
+        <sect3>
+          <title>Definition and Usage</title>
+          <para>
+            Comments may appear anywhere that whitespace may appear in
+            a <acronym>BIND</acronym> configuration file.
+          </para>
+          <para>
+            C-style comments start with the two characters /* (slash,
+            star) and end with */ (star, slash). Because they are completely
+            delimited with these characters, they can be used to comment only
+            a portion of a line or to span multiple lines.
+          </para>
+          <para>
+            C-style comments cannot be nested. For example, the following
+            is not valid because the entire comment ends with the first */:
+          </para>
+          <para>
+
+<programlisting>/* This is the start of a comment.
+   This is still part of the comment.
+/* This is an incorrect attempt at nesting a comment. */
+   This is no longer in any comment. */
+</programlisting>
+
+          </para>
+
+          <para>
+            C++-style comments start with the two characters // (slash,
+            slash) and continue to the end of the physical line. They cannot
+            be continued across multiple physical lines; to have one logical
+            comment span multiple lines, each line must use the // pair.
+          </para>
+          <para>
+            For example:
+          </para>
+          <para>
+
+<programlisting>// This is the start of a comment.  The next line
+// is a new comment, even though it is logically
+// part of the previous comment.
+</programlisting>
+
+          </para>
+          <para>
+            Shell-style (or perl-style, if you prefer) comments start
+            with the character <literal>#</literal> (number sign)
+            and continue to the end of the
+            physical line, as in C++ comments.
+          </para>
+          <para>
+            For example:
+          </para>
+
+          <para>
+
+<programlisting># This is the start of a comment.  The next line
+# is a new comment, even though it is logically
+# part of the previous comment.
+</programlisting>
+
+          </para>
+
+          <warning>
+            <para>
+              You cannot use the semicolon (`;') character
+              to start a comment such as you would in a zone file. The
+              semicolon indicates the end of a configuration
+              statement.
+            </para>
+          </warning>
+        </sect3>
+      </sect2>
+    </sect1>
+
+    <sect1 id="Configuration_File_Grammar">
+      <title>Configuration File Grammar</title>
+
+      <para>
+        A <acronym>BIND</acronym> 9 configuration consists of
+        statements and comments.
+        Statements end with a semicolon. Statements and comments are the
+        only elements that can appear without enclosing braces. Many
+        statements contain a block of sub-statements, which are also
+        terminated with a semicolon.
+      </para>
+
+      <para>
+        The following statements are supported:
+      </para>
+
+      <informaltable colsep="0" rowsep="0">
+        <tgroup cols="2" colsep="0" rowsep="0" tgroupstyle="2Level-table">
+          <colspec colname="1" colnum="1" colsep="0" colwidth="1.336in"/>
+          <colspec colname="2" colnum="2" colsep="0" colwidth="3.778in"/>
+          <tbody>
+            <row rowsep="0">
+              <entry colname="1">
+                <para><command>acl</command></para>
+              </entry>
+              <entry colname="2">
+                <para>
+                  defines a named IP address
+                  matching list, for access control and other uses.
+                </para>
+              </entry>
+            </row>
+            <row rowsep="0">
+              <entry colname="1">
+                <para><command>controls</command></para>
+              </entry>
+              <entry colname="2">
+                <para>
+                  declares control channels to be used
+                  by the <command>rndc</command> utility.
+                </para>
+              </entry>
+            </row>
+            <row rowsep="0">
+              <entry colname="1">
+                <para><command>include</command></para>
+              </entry>
+              <entry colname="2">
+                <para>
+                  includes a file.
+                </para>
+              </entry>
+            </row>
+            <row rowsep="0">
+              <entry colname="1">
+                <para><command>key</command></para>
+              </entry>
+              <entry colname="2">
+                <para>
+                  specifies key information for use in
+                  authentication and authorization using TSIG.
+                </para>
+              </entry>
+            </row>
+            <row rowsep="0">
+              <entry colname="1">
+                <para><command>logging</command></para>
+              </entry>
+              <entry colname="2">
+                <para>
+                  specifies what the server logs, and where
+                  the log messages are sent.
+                </para>
+              </entry>
+            </row>
+            <row rowsep="0">
+              <entry colname="1">
+                <para><command>lwres</command></para>
+              </entry>
+              <entry colname="2">
+                <para>
+                  configures <command>named</command> to
+                  also act as a light-weight resolver daemon (<command>lwresd</command>).
+                </para>
+              </entry>
+            </row>
+            <row rowsep="0">
+              <entry colname="1">
+                <para><command>masters</command></para>
+              </entry>
+              <entry colname="2">
+                <para>
+                  defines a named masters list for
+                  inclusion in stub and slave zone masters clauses.
+                </para>
+              </entry>
+            </row>
+            <row rowsep="0">
+              <entry colname="1">
+                <para><command>options</command></para>
+              </entry>
+              <entry colname="2">
+                <para>
+                  controls global server configuration
+                  options and sets defaults for other statements.
+                </para>
+              </entry>
+            </row>
+            <row rowsep="0">
+              <entry colname="1">
+                <para><command>server</command></para>
+              </entry>
+              <entry colname="2">
+                <para>
+                  sets certain configuration options on
+                  a per-server basis.
+                </para>
+              </entry>
+            </row>
+            <row rowsep="0">
+              <entry colname="1">
+                <para><command>trusted-keys</command></para>
+              </entry>
+              <entry colname="2">
+                <para>
+                  defines trusted DNSSEC keys.
+                </para>
+              </entry>
+            </row>
+            <row rowsep="0">
+              <entry colname="1">
+                <para><command>view</command></para>
+              </entry>
+              <entry colname="2">
+                <para>
+                  defines a view.
+                </para>
+              </entry>
+            </row>
+            <row rowsep="0">
+              <entry colname="1">
+                <para><command>zone</command></para>
+              </entry>
+              <entry colname="2">
+                <para>
+                  defines a zone.
+                </para>
+              </entry>
+            </row>
+          </tbody>
+        </tgroup>
+      </informaltable>
+
+      <para>
+        The <command>logging</command> and
+        <command>options</command> statements may only occur once
+        per
+        configuration.
+      </para>
+
+      <sect2>
+        <title><command>acl</command> Statement Grammar</title>
+
+<programlisting><command>acl</command> acl-name {
+    address_match_list
+};
+</programlisting>
+
+      </sect2>
+      <sect2 id="acl">
+        <title><command>acl</command> Statement Definition and
+          Usage</title>
+
+        <para>
+          The <command>acl</command> statement assigns a symbolic
+          name to an address match list. It gets its name from a primary
+          use of address match lists: Access Control Lists (ACLs).
+        </para>
+
+        <para>
+          Note that an address match list's name must be defined
+          with <command>acl</command> before it can be used
+          elsewhere; no
+          forward references are allowed.
+        </para>
+
+        <para>
+          The following ACLs are built-in:
+        </para>
+
+        <informaltable colsep="0" rowsep="0">
+          <tgroup cols="2" colsep="0" rowsep="0" tgroupstyle="3Level-table">
+            <colspec colname="1" colnum="1" colsep="0" colwidth="1.130in"/>
+            <colspec colname="2" colnum="2" colsep="0" colwidth="4.000in"/>
+            <tbody>
+              <row rowsep="0">
+                <entry colname="1">
+                  <para><command>any</command></para>
+                </entry>
+                <entry colname="2">
+                  <para>
+                    Matches all hosts.
+                  </para>
+                </entry>
+              </row>
+              <row rowsep="0">
+                <entry colname="1">
+                  <para><command>none</command></para>
+                </entry>
+                <entry colname="2">
+                  <para>
+                    Matches no hosts.
+                  </para>
+                </entry>
+              </row>
+              <row rowsep="0">
+                <entry colname="1">
+                  <para><command>localhost</command></para>
+                </entry>
+                <entry colname="2">
+                  <para>
+                    Matches the IPv4 and IPv6 addresses of all network
+                    interfaces on the system.
+                  </para>
+                </entry>
+              </row>
+              <row rowsep="0">
+                <entry colname="1">
+                  <para><command>localnets</command></para>
+                </entry>
+                <entry colname="2">
+                  <para>
+                    Matches any host on an IPv4 or IPv6 network
+                    for which the system has an interface.
+                    Some systems do not provide a way to determine the prefix
+                    lengths of
+                    local IPv6 addresses.
+                    In such a case, <command>localnets</command>
+                    only matches the local
+                    IPv6 addresses, just like <command>localhost</command>.
+                  </para>
+                </entry>
+              </row>
+            </tbody>
+          </tgroup>
+        </informaltable>
+
+      </sect2>
+      <sect2>
+        <title><command>controls</command> Statement Grammar</title>
+
+<programlisting><command>controls</command> {
+   [ inet ( ip_addr | * ) [ port ip_port ] allow { <replaceable> address_match_list </replaceable> }
+                keys { <replaceable>key_list</replaceable> }; ]
+   [ inet ...; ]
+   [ unix <replaceable>path</replaceable> perm <replaceable>number</replaceable> owner <replaceable>number</replaceable> group <replaceable>number</replaceable> keys { <replaceable>key_list</replaceable> }; ]
+   [ unix ...; ]
+};
+</programlisting>
+
+      </sect2>
+
+      <sect2 id="controls_statement_definition_and_usage">
+        <title><command>controls</command> Statement Definition and
+          Usage</title>
+
+        <para>
+          The <command>controls</command> statement declares control
+          channels to be used by system administrators to control the
+          operation of the name server. These control channels are
+          used by the <command>rndc</command> utility to send
+          commands to and retrieve non-DNS results from a name server.
+        </para>
+
+        <para>
+          An <command>inet</command> control channel is a TCP socket
+	  listening at the specified <command>ip_port</command> on the
+	  specified <command>ip_addr</command>, which can be an IPv4 or IPv6
+	  address.  An <command>ip_addr</command> of <literal>*</literal> (asterisk) is
+	  interpreted as the IPv4 wildcard address; connections will be
+	  accepted on any of the system's IPv4 addresses.
+	  To listen on the IPv6 wildcard address,
+          use an <command>ip_addr</command> of <literal>::</literal>.
+          If you will only use <command>rndc</command> on the local host,
+          using the loopback address (<literal>127.0.0.1</literal>
+          or <literal>::1</literal>) is recommended for maximum security.
+        </para>
+
+        <para>
+          If no port is specified, port 953 is used. The asterisk
+	  "<literal>*</literal>" cannot be used for <command>ip_port</command>.
+        </para>
+
+        <para>
+          The ability to issue commands over the control channel is
+          restricted by the <command>allow</command> and
+          <command>keys</command> clauses.
+	  Connections to the control channel are permitted based on the
+          <command>address_match_list</command>.  This is for simple
+          IP address based filtering only; any <command>key_id</command>
+          elements of the <command>address_match_list</command>
+          are ignored.
+        </para>
+
+	<para>
+	  A <command>unix</command> control channel is a UNIX domain
+	  socket listening at the specified path in the file system.
+	  Access to the socket is specified by the <command>perm</command>,
+	  <command>owner</command> and <command>group</command> clauses.
+	  Note on some platforms (SunOS and Solaris) the permissions
+	  (<command>perm</command>) are applied to the parent directory
+	  as the permissions on the socket itself are ignored.
+	</para>
+
+        <para>
+          The primary authorization mechanism of the command
+          channel is the <command>key_list</command>, which
+          contains a list of <command>key_id</command>s.
+          Each <command>key_id</command> in the <command>key_list</command>
+	  is authorized to execute commands over the control channel.
+          See <xref linkend="rndc"/> in <xref linkend="admin_tools"/>)
+	  for information about configuring keys in <command>rndc</command>.
+        </para>
+
+        <para>
+          If no <command>controls</command> statement is present,
+          <command>named</command> will set up a default
+          control channel listening on the loopback address 127.0.0.1
+          and its IPv6 counterpart ::1.
+          In this case, and also when the <command>controls</command> statement
+          is present but does not have a <command>keys</command> clause,
+          <command>named</command> will attempt to load the command channel key
+          from the file <filename>rndc.key</filename> in
+          <filename>/etc</filename> (or whatever <varname>sysconfdir</varname>
+          was specified as when <acronym>BIND</acronym> was built).
+          To create a <filename>rndc.key</filename> file, run
+          <userinput>rndc-confgen -a</userinput>.
+        </para>
+
+        <para>
+          The <filename>rndc.key</filename> feature was created to
+          ease the transition of systems from <acronym>BIND</acronym> 8,
+          which did not have digital signatures on its command channel
+          messages and thus did not have a <command>keys</command> clause.
+
+          It makes it possible to use an existing <acronym>BIND</acronym> 8
+          configuration file in <acronym>BIND</acronym> 9 unchanged,
+          and still have <command>rndc</command> work the same way
+          <command>ndc</command> worked in BIND 8, simply by executing the
+          command <userinput>rndc-confgen -a</userinput> after BIND 9 is
+          installed.
+        </para>
+
+        <para>
+          Since the <filename>rndc.key</filename> feature
+          is only intended to allow the backward-compatible usage of
+          <acronym>BIND</acronym> 8 configuration files, this
+          feature does not
+          have a high degree of configurability.  You cannot easily change
+          the key name or the size of the secret, so you should make a
+          <filename>rndc.conf</filename> with your own key if you
+          wish to change
+          those things.  The <filename>rndc.key</filename> file
+          also has its
+          permissions set such that only the owner of the file (the user that
+          <command>named</command> is running as) can access it.
+          If you
+          desire greater flexibility in allowing other users to access
+          <command>rndc</command> commands, then you need to create
+          a
+          <filename>rndc.conf</filename> file and make it group
+          readable by a group
+          that contains the users who should have access.
+        </para>
+
+        <para>
+          To disable the command channel, use an empty
+	  <command>controls</command> statement:
+	  <command>controls { };</command>.
+        </para>
+
+      </sect2>
+      <sect2>
+        <title><command>include</command> Statement Grammar</title>
+        <programlisting>include <replaceable>filename</replaceable>;</programlisting>
+      </sect2>
+      <sect2>
+        <title><command>include</command> Statement Definition and
+          Usage</title>
+
+        <para>
+          The <command>include</command> statement inserts the
+          specified file at the point where the <command>include</command>
+          statement is encountered. The <command>include</command>
+                statement facilitates the administration of configuration
+          files
+          by permitting the reading or writing of some things but not
+          others. For example, the statement could include private keys
+          that are readable only by the name server.
+        </para>
+
+      </sect2>
+      <sect2>
+        <title><command>key</command> Statement Grammar</title>
+
+<programlisting>key <replaceable>key_id</replaceable> {
+    algorithm <replaceable>string</replaceable>;
+    secret <replaceable>string</replaceable>;
+};
+</programlisting>
+
+      </sect2>
+
+      <sect2>
+        <title><command>key</command> Statement Definition and Usage</title>
+
+        <para>
+          The <command>key</command> statement defines a shared
+          secret key for use with TSIG (see <xref linkend="tsig"/>)
+          or the command channel
+          (see <xref linkend="controls_statement_definition_and_usage"/>).
+        </para>
+
+        <para>
+          The <command>key</command> statement can occur at the
+          top level
+          of the configuration file or inside a <command>view</command>
+          statement.  Keys defined in top-level <command>key</command>
+          statements can be used in all views.  Keys intended for use in
+          a <command>controls</command> statement
+          (see <xref linkend="controls_statement_definition_and_usage"/>)
+          must be defined at the top level.
+        </para>
+
+        <para>
+          The <replaceable>key_id</replaceable>, also known as the
+          key name, is a domain name uniquely identifying the key. It can
+          be used in a <command>server</command>
+          statement to cause requests sent to that
+          server to be signed with this key, or in address match lists to
+          verify that incoming requests have been signed with a key
+          matching this name, algorithm, and secret.
+        </para>
+
+	<para>
+	  The <replaceable>algorithm_id</replaceable> is a string
+	  that specifies a security/authentication algorithm.  Named
+	  supports <literal>hmac-md5</literal>,
+	  <literal>hmac-sha1</literal>, <literal>hmac-sha224</literal>,
+	  <literal>hmac-sha256</literal>, <literal>hmac-sha384</literal>
+	  and <literal>hmac-sha512</literal> TSIG authentication.
+	  Truncated hashes are supported by appending the minimum
+	  number of required bits preceded by a dash, e.g.
+	  <literal>hmac-sha1-80</literal>.  The
+	  <replaceable>secret_string</replaceable> is the secret
+	  to be used by the algorithm, and is treated as a base-64
+	  encoded string.
+	</para>
+
+      </sect2>
+      <sect2>
+        <title><command>logging</command> Statement Grammar</title>
+
+<programlisting><command>logging</command> {
+   [ <command>channel</command> <replaceable>channel_name</replaceable> {
+     ( <command>file</command> <replaceable>path name</replaceable>
+         [ <command>versions</command> ( <replaceable>number</replaceable> | <command>unlimited</command> ) ]
+         [ <command>size</command> <replaceable>size spec</replaceable> ]
+       | <command>syslog</command> <replaceable>syslog_facility</replaceable>
+       | <command>stderr</command>
+       | <command>null</command> );
+     [ <command>severity</command> (<option>critical</option> | <option>error</option> | <option>warning</option> | <option>notice</option> |
+                 <option>info</option> | <option>debug</option> [ <replaceable>level</replaceable> ] | <option>dynamic</option> ); ]
+     [ <command>print-category</command> <option>yes</option> or <option>no</option>; ]
+     [ <command>print-severity</command> <option>yes</option> or <option>no</option>; ]
+     [ <command>print-time</command> <option>yes</option> or <option>no</option>; ]
+   }; ]
+   [ <command>category</command> <replaceable>category_name</replaceable> {
+     <replaceable>channel_name</replaceable> ; [ <replaceable>channel_name</replaceable> ; ... ]
+   }; ]
+   ...
+};
+</programlisting>
+
+      </sect2>
+
+      <sect2>
+        <title><command>logging</command> Statement Definition and
+          Usage</title>
+
+        <para>
+          The <command>logging</command> statement configures a
+          wide
+          variety of logging options for the name server. Its <command>channel</command> phrase
+          associates output methods, format options and severity levels with
+          a name that can then be used with the <command>category</command> phrase
+          to select how various classes of messages are logged.
+        </para>
+        <para>
+          Only one <command>logging</command> statement is used to
+          define
+          as many channels and categories as are wanted. If there is no <command>logging</command> statement,
+          the logging configuration will be:
+        </para>
+
+<programlisting>logging {
+     category default { default_syslog; default_debug; };
+     category unmatched { null; };
+};
+</programlisting>
+
+        <para>
+          In <acronym>BIND</acronym> 9, the logging configuration
+          is only established when
+          the entire configuration file has been parsed.  In <acronym>BIND</acronym> 8, it was
+          established as soon as the <command>logging</command>
+          statement
+          was parsed. When the server is starting up, all logging messages
+          regarding syntax errors in the configuration file go to the default
+          channels, or to standard error if the "<option>-g</option>" option
+          was specified.
+        </para>
+
+        <sect3>
+          <title>The <command>channel</command> Phrase</title>
+
+          <para>
+            All log output goes to one or more <emphasis>channels</emphasis>;
+            you can make as many of them as you want.
+          </para>
+
+          <para>
+            Every channel definition must include a destination clause that
+            says whether messages selected for the channel go to a file, to a
+            particular syslog facility, to the standard error stream, or are
+            discarded. It can optionally also limit the message severity level
+            that will be accepted by the channel (the default is
+            <command>info</command>), and whether to include a
+            <command>named</command>-generated time stamp, the
+            category name
+            and/or severity level (the default is not to include any).
+          </para>
+
+          <para>
+            The <command>null</command> destination clause
+            causes all messages sent to the channel to be discarded;
+            in that case, other options for the channel are meaningless.
+          </para>
+
+          <para>
+            The <command>file</command> destination clause directs
+            the channel
+            to a disk file.  It can include limitations
+            both on how large the file is allowed to become, and how many
+            versions
+            of the file will be saved each time the file is opened.
+          </para>
+
+          <para>
+            If you use the <command>versions</command> log file
+            option, then
+            <command>named</command> will retain that many backup
+            versions of the file by
+            renaming them when opening.  For example, if you choose to keep
+            three old versions
+            of the file <filename>lamers.log</filename>, then just
+            before it is opened
+            <filename>lamers.log.1</filename> is renamed to
+            <filename>lamers.log.2</filename>, <filename>lamers.log.0</filename> is renamed
+            to <filename>lamers.log.1</filename>, and <filename>lamers.log</filename> is
+            renamed to <filename>lamers.log.0</filename>.
+            You can say <command>versions unlimited</command> to
+            not limit
+            the number of versions.
+            If a <command>size</command> option is associated with
+            the log file,
+            then renaming is only done when the file being opened exceeds the
+            indicated size.  No backup versions are kept by default; any
+            existing
+            log file is simply appended.
+          </para>
+
+          <para>
+            The <command>size</command> option for files is used
+            to limit log
+            growth. If the file ever exceeds the size, then <command>named</command> will
+            stop writing to the file unless it has a <command>versions</command> option
+            associated with it.  If backup versions are kept, the files are
+            rolled as
+            described above and a new one begun.  If there is no
+            <command>versions</command> option, no more data will
+            be written to the log
+            until some out-of-band mechanism removes or truncates the log to
+            less than the
+            maximum size.  The default behavior is not to limit the size of
+            the
+            file.
+          </para>
+
+          <para>
+            Example usage of the <command>size</command> and
+            <command>versions</command> options:
+          </para>
+
+<programlisting>channel an_example_channel {
+    file "example.log" versions 3 size 20m;
+    print-time yes;
+    print-category yes;
+};
+</programlisting>
+
+          <para>
+            The <command>syslog</command> destination clause
+            directs the
+            channel to the system log.  Its argument is a
+            syslog facility as described in the <command>syslog</command> man
+            page. Known facilities are <command>kern</command>, <command>user</command>,
+            <command>mail</command>, <command>daemon</command>, <command>auth</command>,
+            <command>syslog</command>, <command>lpr</command>, <command>news</command>,
+            <command>uucp</command>, <command>cron</command>, <command>authpriv</command>,
+            <command>ftp</command>, <command>local0</command>, <command>local1</command>,
+            <command>local2</command>, <command>local3</command>, <command>local4</command>,
+            <command>local5</command>, <command>local6</command> and
+            <command>local7</command>, however not all facilities
+            are supported on
+            all operating systems.
+            How <command>syslog</command> will handle messages
+            sent to
+            this facility is described in the <command>syslog.conf</command> man
+            page. If you have a system which uses a very old version of <command>syslog</command> that
+            only uses two arguments to the <command>openlog()</command> function,
+            then this clause is silently ignored.
+          </para>
+          <para>
+            The <command>severity</command> clause works like <command>syslog</command>'s
+            "priorities", except that they can also be used if you are writing
+            straight to a file rather than using <command>syslog</command>.
+            Messages which are not at least of the severity level given will
+            not be selected for the channel; messages of higher severity
+            levels
+            will be accepted.
+          </para>
+          <para>
+            If you are using <command>syslog</command>, then the <command>syslog.conf</command> priorities
+            will also determine what eventually passes through. For example,
+            defining a channel facility and severity as <command>daemon</command> and <command>debug</command> but
+            only logging <command>daemon.warning</command> via <command>syslog.conf</command> will
+            cause messages of severity <command>info</command> and
+            <command>notice</command> to
+            be dropped. If the situation were reversed, with <command>named</command> writing
+            messages of only <command>warning</command> or higher,
+            then <command>syslogd</command> would
+            print all messages it received from the channel.
+          </para>
+
+          <para>
+            The <command>stderr</command> destination clause
+            directs the
+            channel to the server's standard error stream.  This is intended
+            for
+            use when the server is running as a foreground process, for
+            example
+            when debugging a configuration.
+          </para>
+
+          <para>
+            The server can supply extensive debugging information when
+            it is in debugging mode. If the server's global debug level is
+            greater
+            than zero, then debugging mode will be active. The global debug
+            level is set either by starting the <command>named</command> server
+            with the <option>-d</option> flag followed by a positive integer,
+            or by running <command>rndc trace</command>.
+            The global debug level
+            can be set to zero, and debugging mode turned off, by running <command>rndc
+notrace</command>. All debugging messages in the server have a debug
+            level, and higher debug levels give more detailed output. Channels
+            that specify a specific debug severity, for example:
+          </para>
+
+<programlisting>channel specific_debug_level {
+    file "foo";
+    severity debug 3;
+};
+</programlisting>
+
+          <para>
+            will get debugging output of level 3 or less any time the
+            server is in debugging mode, regardless of the global debugging
+            level. Channels with <command>dynamic</command>
+            severity use the
+            server's global debug level to determine what messages to print.
+          </para>
+          <para>
+            If <command>print-time</command> has been turned on,
+            then
+            the date and time will be logged. <command>print-time</command> may
+            be specified for a <command>syslog</command> channel,
+            but is usually
+            pointless since <command>syslog</command> also prints
+            the date and
+            time. If <command>print-category</command> is
+            requested, then the
+            category of the message will be logged as well. Finally, if <command>print-severity</command> is
+            on, then the severity level of the message will be logged. The <command>print-</command> options may
+            be used in any combination, and will always be printed in the
+            following
+            order: time, category, severity. Here is an example where all
+            three <command>print-</command> options
+            are on:
+          </para>
+
+          <para>
+            <computeroutput>28-Feb-2000 15:05:32.863 general: notice: running</computeroutput>
+          </para>
+
+          <para>
+            There are four predefined channels that are used for
+            <command>named</command>'s default logging as follows.
+            How they are
+            used is described in <xref linkend="the_category_phrase"/>.
+          </para>
+
+<programlisting>channel default_syslog {
+    syslog daemon;                      // send to syslog's daemon
+                                        // facility
+    severity info;                      // only send priority info
+                                        // and higher
+};
+
+channel default_debug {
+    file "named.run";                   // write to named.run in
+                                        // the working directory
+                                        // Note: stderr is used instead
+                                        // of "named.run"
+                                        // if the server is started
+                                        // with the '-f' option.
+    severity dynamic;                   // log at the server's
+                                        // current debug level
+};
+
+channel default_stderr {
+    stderr;                             // writes to stderr
+    severity info;                      // only send priority info
+                                        // and higher
+};
+
+channel null {
+   null;                                // toss anything sent to
+                                        // this channel
+};
+</programlisting>
+
+          <para>
+            The <command>default_debug</command> channel has the
+            special
+            property that it only produces output when the server's debug
+            level is
+            nonzero.  It normally writes to a file called <filename>named.run</filename>
+            in the server's working directory.
+          </para>
+
+          <para>
+            For security reasons, when the "<option>-u</option>"
+            command line option is used, the <filename>named.run</filename> file
+            is created only after <command>named</command> has
+            changed to the
+            new UID, and any debug output generated while <command>named</command> is
+            starting up and still running as root is discarded.  If you need
+            to capture this output, you must run the server with the "<option>-g</option>"
+            option and redirect standard error to a file.
+          </para>
+
+          <para>
+            Once a channel is defined, it cannot be redefined. Thus you
+            cannot alter the built-in channels directly, but you can modify
+            the default logging by pointing categories at channels you have
+            defined.
+          </para>
+        </sect3>
+
+        <sect3 id="the_category_phrase">
+          <title>The <command>category</command> Phrase</title>
+
+          <para>
+            There are many categories, so you can send the logs you want
+            to see wherever you want, without seeing logs you don't want. If
+            you don't specify a list of channels for a category, then log
+            messages
+            in that category will be sent to the <command>default</command> category
+            instead. If you don't specify a default category, the following
+            "default default" is used:
+          </para>
+
+<programlisting>category default { default_syslog; default_debug; };
+</programlisting>
+
+          <para>
+            As an example, let's say you want to log security events to
+            a file, but you also want keep the default logging behavior. You'd
+            specify the following:
+          </para>
+
+<programlisting>channel my_security_channel {
+    file "my_security_file";
+    severity info;
+};
+category security {
+    my_security_channel;
+    default_syslog;
+    default_debug;
+};</programlisting>
+
+          <para>
+            To discard all messages in a category, specify the <command>null</command> channel:
+          </para>
+
+<programlisting>category xfer-out { null; };
+category notify { null; };
+</programlisting>
+
+          <para>
+            Following are the available categories and brief descriptions
+            of the types of log information they contain. More
+            categories may be added in future <acronym>BIND</acronym> releases.
+          </para>
+          <informaltable colsep="0" rowsep="0">
+            <tgroup cols="2" colsep="0" rowsep="0" tgroupstyle="4Level-table">
+              <colspec colname="1" colnum="1" colsep="0" colwidth="1.150in"/>
+              <colspec colname="2" colnum="2" colsep="0" colwidth="3.350in"/>
+              <tbody>
+                <row rowsep="0">
+                  <entry colname="1">
+                    <para><command>default</command></para>
+                  </entry>
+                  <entry colname="2">
+                    <para>
+                      The default category defines the logging
+                      options for those categories where no specific
+                      configuration has been
+                      defined.
+                    </para>
+                  </entry>
+                </row>
+                <row rowsep="0">
+                  <entry colname="1">
+                    <para><command>general</command></para>
+                  </entry>
+                  <entry colname="2">
+                    <para>
+                      The catch-all. Many things still aren't
+                      classified into categories, and they all end up here.
+                    </para>
+                  </entry>
+                </row>
+                <row rowsep="0">
+                  <entry colname="1">
+                    <para><command>database</command></para>
+                  </entry>
+                  <entry colname="2">
+                    <para>
+                      Messages relating to the databases used
+                      internally by the name server to store zone and cache
+                      data.
+                    </para>
+                  </entry>
+                </row>
+                <row rowsep="0">
+                  <entry colname="1">
+                    <para><command>security</command></para>
+                  </entry>
+                  <entry colname="2">
+                    <para>
+                      Approval and denial of requests.
+                    </para>
+                  </entry>
+                </row>
+                <row rowsep="0">
+                  <entry colname="1">
+                    <para><command>config</command></para>
+                  </entry>
+                  <entry colname="2">
+                    <para>
+                      Configuration file parsing and processing.
+                    </para>
+                  </entry>
+                </row>
+                <row rowsep="0">
+                  <entry colname="1">
+                    <para><command>resolver</command></para>
+                  </entry>
+                  <entry colname="2">
+                    <para>
+                      DNS resolution, such as the recursive
+                      lookups performed on behalf of clients by a caching name
+                      server.
+                    </para>
+                  </entry>
+                </row>
+                <row rowsep="0">
+                  <entry colname="1">
+                    <para><command>xfer-in</command></para>
+                  </entry>
+                  <entry colname="2">
+                    <para>
+                      Zone transfers the server is receiving.
+                    </para>
+                  </entry>
+                </row>
+                <row rowsep="0">
+                  <entry colname="1">
+                    <para><command>xfer-out</command></para>
+                  </entry>
+                  <entry colname="2">
+                    <para>
+                      Zone transfers the server is sending.
+                    </para>
+                  </entry>
+                </row>
+                <row rowsep="0">
+                  <entry colname="1">
+                    <para><command>notify</command></para>
+                  </entry>
+                  <entry colname="2">
+                    <para>
+                      The NOTIFY protocol.
+                    </para>
+                  </entry>
+                </row>
+                <row rowsep="0">
+                  <entry colname="1">
+                    <para><command>client</command></para>
+                  </entry>
+                  <entry colname="2">
+                    <para>
+                      Processing of client requests.
+                    </para>
+                  </entry>
+                </row>
+                <row rowsep="0">
+                  <entry colname="1">
+                    <para><command>unmatched</command></para>
+                  </entry>
+                  <entry colname="2">
+                    <para>
+                      Messages that named was unable to determine the
+                      class of or for which there was no matching <command>view</command>.
+                      A one line summary is also logged to the <command>client</command> category.
+                      This category is best sent to a file or stderr, by
+                      default it is sent to
+                      the <command>null</command> channel.
+                    </para>
+                  </entry>
+                </row>
+                <row rowsep="0">
+                  <entry colname="1">
+                    <para><command>network</command></para>
+                  </entry>
+                  <entry colname="2">
+                    <para>
+                      Network operations.
+                    </para>
+                  </entry>
+                </row>
+                <row rowsep="0">
+                  <entry colname="1">
+                    <para><command>update</command></para>
+                  </entry>
+                  <entry colname="2">
+                    <para>
+                      Dynamic updates.
+                    </para>
+                  </entry>
+                </row>
+                <row rowsep="0">
+                  <entry colname="1">
+                    <para><command>update-security</command></para>
+                  </entry>
+                  <entry colname="2">
+                    <para>
+                      Approval and denial of update requests.
+                    </para>
+                  </entry>
+                </row>
+                <row rowsep="0">
+                  <entry colname="1">
+                    <para><command>queries</command></para>
+                  </entry>
+                  <entry colname="2">
+                    <para>
+                      Specify where queries should be logged to.
+                    </para>
+                    <para>
+                      At startup, specifying the category <command>queries</command> will also
+                      enable query logging unless <command>querylog</command> option has been
+                      specified.
+                    </para>
+                    <para>
+                      The query log entry reports the client's IP address and
+                      port number, and the
+                      query name, class and type.  It also reports whether the
+                      Recursion Desired
+                      flag was set (+ if set, - if not set), EDNS was in use
+                      (E) or if the
+                      query was signed (S).
+                    </para>
+                    <para>
+                      <computeroutput>client 127.0.0.1#62536: query: www.example.com IN AAAA +SE</computeroutput>
+                    </para>
+                    <para>
+                      <computeroutput>client ::1#62537: query: www.example.net IN AAAA -SE</computeroutput>
+                    </para>
+                  </entry>
+                </row>
+                <row rowsep="0">
+                  <entry colname="1">
+                    <para><command>dispatch</command></para>
+                  </entry>
+                  <entry colname="2">
+                    <para>
+                      Dispatching of incoming packets to the
+                      server modules where they are to be processed.
+                    </para>
+                  </entry>
+                </row>
+                <row rowsep="0">
+                  <entry colname="1">
+                    <para><command>dnssec</command></para>
+                  </entry>
+                  <entry colname="2">
+                    <para>
+                      DNSSEC and TSIG protocol processing.
+                    </para>
+                  </entry>
+                </row>
+                <row rowsep="0">
+                  <entry colname="1">
+                    <para><command>lame-servers</command></para>
+                  </entry>
+                  <entry colname="2">
+                    <para>
+                      Lame servers.  These are misconfigurations
+                      in remote servers, discovered by BIND 9 when trying to
+                      query
+                      those servers during resolution.
+                    </para>
+                  </entry>
+                </row>
+                <row rowsep="0">
+                  <entry colname="1">
+                    <para><command>delegation-only</command></para>
+                  </entry>
+                  <entry colname="2">
+                    <para>
+                      Delegation only.  Logs queries that have have
+                      been forced to NXDOMAIN as the result of a
+                      delegation-only zone or
+                      a <command>delegation-only</command> in a
+                      hint or stub zone declaration.
+                    </para>
+                  </entry>
+                </row>
+              </tbody>
+            </tgroup>
+          </informaltable>
+        </sect3>
+      </sect2>
+
+      <sect2>
+        <title><command>lwres</command> Statement Grammar</title>
+
+        <para>
+           This is the grammar of the <command>lwres</command>
+          statement in the <filename>named.conf</filename> file:
+        </para>
+
+<programlisting><command>lwres</command> {
+    <optional> listen-on { <replaceable>ip_addr</replaceable> <optional>port <replaceable>ip_port</replaceable></optional> ; <optional> <replaceable>ip_addr</replaceable> <optional>port <replaceable>ip_port</replaceable></optional> ; ... </optional> }; </optional>
+    <optional> view <replaceable>view_name</replaceable>; </optional>
+    <optional> search { <replaceable>domain_name</replaceable> ; <optional> <replaceable>domain_name</replaceable> ; ... </optional> }; </optional>
+    <optional> ndots <replaceable>number</replaceable>; </optional>
+};
+</programlisting>
+
+      </sect2>
+      <sect2>
+        <title><command>lwres</command> Statement Definition and Usage</title>
+
+        <para>
+          The <command>lwres</command> statement configures the
+          name
+          server to also act as a lightweight resolver server. (See
+          <xref linkend="lwresd"/>.)  There may be multiple
+          <command>lwres</command> statements configuring
+          lightweight resolver servers with different properties.
+        </para>
+
+        <para>
+          The <command>listen-on</command> statement specifies a
+          list of
+          addresses (and ports) that this instance of a lightweight resolver
+          daemon
+          should accept requests on.  If no port is specified, port 921 is
+          used.
+          If this statement is omitted, requests will be accepted on
+          127.0.0.1,
+          port 921.
+        </para>
+
+        <para>
+          The <command>view</command> statement binds this
+          instance of a
+          lightweight resolver daemon to a view in the DNS namespace, so that
+          the
+          response will be constructed in the same manner as a normal DNS
+          query
+          matching this view.  If this statement is omitted, the default view
+          is
+          used, and if there is no default view, an error is triggered.
+        </para>
+
+        <para>
+          The <command>search</command> statement is equivalent to
+          the
+          <command>search</command> statement in
+          <filename>/etc/resolv.conf</filename>.  It provides a
+          list of domains
+          which are appended to relative names in queries.
+        </para>
+
+        <para>
+          The <command>ndots</command> statement is equivalent to
+          the
+          <command>ndots</command> statement in
+          <filename>/etc/resolv.conf</filename>.  It indicates the
+          minimum
+          number of dots in a relative domain name that should result in an
+          exact match lookup before search path elements are appended.
+        </para>
+      </sect2>
+      <sect2>
+        <title><command>masters</command> Statement Grammar</title>
+
+<programlisting>
+<command>masters</command> <replaceable>name</replaceable> <optional>port <replaceable>ip_port</replaceable></optional> { ( <replaceable>masters_list</replaceable> | <replaceable>ip_addr</replaceable> <optional>port <replaceable>ip_port</replaceable></optional> <optional>key <replaceable>key</replaceable></optional> ) ; <optional>...</optional> };
+</programlisting>
+
+      </sect2>
+
+      <sect2>
+        <title><command>masters</command> Statement Definition and
+          Usage</title>
+        <para><command>masters</command>
+	  lists allow for a common set of masters to be easily used by
+          multiple stub and slave zones.
+        </para>
+      </sect2>
+
+      <sect2>
+        <title><command>options</command> Statement Grammar</title>
+
+        <para>
+          This is the grammar of the <command>options</command>
+          statement in the <filename>named.conf</filename> file:
+        </para>
+
+<programlisting>options {
+    <optional> version <replaceable>version_string</replaceable>; </optional>
+    <optional> hostname <replaceable>hostname_string</replaceable>; </optional>
+    <optional> server-id <replaceable>server_id_string</replaceable>; </optional>
+    <optional> directory <replaceable>path_name</replaceable>; </optional>
+    <optional> key-directory <replaceable>path_name</replaceable>; </optional>
+    <optional> named-xfer <replaceable>path_name</replaceable>; </optional>
+    <optional> tkey-domain <replaceable>domainname</replaceable>; </optional>
+    <optional> tkey-dhkey <replaceable>key_name</replaceable> <replaceable>key_tag</replaceable>; </optional>
+    <optional> cache-file <replaceable>path_name</replaceable>; </optional>
+    <optional> dump-file <replaceable>path_name</replaceable>; </optional>
+    <optional> memstatistics-file <replaceable>path_name</replaceable>; </optional>
+    <optional> pid-file <replaceable>path_name</replaceable>; </optional>
+    <optional> recursing-file <replaceable>path_name</replaceable>; </optional>
+    <optional> statistics-file <replaceable>path_name</replaceable>; </optional>
+    <optional> zone-statistics <replaceable>yes_or_no</replaceable>; </optional>
+    <optional> auth-nxdomain <replaceable>yes_or_no</replaceable>; </optional>
+    <optional> deallocate-on-exit <replaceable>yes_or_no</replaceable>; </optional>
+    <optional> dialup <replaceable>dialup_option</replaceable>; </optional>
+    <optional> fake-iquery <replaceable>yes_or_no</replaceable>; </optional>
+    <optional> fetch-glue <replaceable>yes_or_no</replaceable>; </optional>
+    <optional> flush-zones-on-shutdown <replaceable>yes_or_no</replaceable>; </optional>
+    <optional> has-old-clients <replaceable>yes_or_no</replaceable>; </optional>
+    <optional> host-statistics <replaceable>yes_or_no</replaceable>; </optional>
+    <optional> host-statistics-max <replaceable>number</replaceable>; </optional>
+    <optional> minimal-responses <replaceable>yes_or_no</replaceable>; </optional>
+    <optional> multiple-cnames <replaceable>yes_or_no</replaceable>; </optional>
+    <optional> notify <replaceable>yes_or_no</replaceable> | <replaceable>explicit</replaceable> | <replaceable>master-only</replaceable>; </optional>
+    <optional> recursion <replaceable>yes_or_no</replaceable>; </optional>
+    <optional> rfc2308-type1 <replaceable>yes_or_no</replaceable>; </optional>
+    <optional> use-id-pool <replaceable>yes_or_no</replaceable>; </optional>
+    <optional> maintain-ixfr-base <replaceable>yes_or_no</replaceable>; </optional>
+    <optional> dnssec-enable <replaceable>yes_or_no</replaceable>; </optional>
+    <optional> dnssec-validation <replaceable>yes_or_no</replaceable>; </optional>
+    <optional> dnssec-lookaside <replaceable>domain</replaceable> trust-anchor <replaceable>domain</replaceable>; </optional>
+    <optional> dnssec-must-be-secure <replaceable>domain yes_or_no</replaceable>; </optional>
+    <optional> dnssec-accept-expired <replaceable>yes_or_no</replaceable>; </optional>
+    <optional> forward ( <replaceable>only</replaceable> | <replaceable>first</replaceable> ); </optional>
+    <optional> forwarders { <optional> <replaceable>ip_addr</replaceable> <optional>port <replaceable>ip_port</replaceable></optional> ; ... </optional> }; </optional>
+    <optional> dual-stack-servers <optional>port <replaceable>ip_port</replaceable></optional> {
+        ( <replaceable>domain_name</replaceable> <optional>port <replaceable>ip_port</replaceable></optional> |
+          <replaceable>ip_addr</replaceable> <optional>port <replaceable>ip_port</replaceable></optional> ) ; 
+        ... }; </optional>
+    <optional> check-names ( <replaceable>master</replaceable> | <replaceable>slave</replaceable> | <replaceable>response</replaceable> )
+        ( <replaceable>warn</replaceable> | <replaceable>fail</replaceable> | <replaceable>ignore</replaceable> ); </optional>
+    <optional> check-mx ( <replaceable>warn</replaceable> | <replaceable>fail</replaceable> | <replaceable>ignore</replaceable> ); </optional>
+    <optional> check-wildcard <replaceable>yes_or_no</replaceable>; </optional>
+    <optional> check-integrity <replaceable>yes_or_no</replaceable>; </optional>
+    <optional> check-mx-cname ( <replaceable>warn</replaceable> | <replaceable>fail</replaceable> | <replaceable>ignore</replaceable> ); </optional>
+    <optional> check-srv-cname ( <replaceable>warn</replaceable> | <replaceable>fail</replaceable> | <replaceable>ignore</replaceable> ); </optional>
+    <optional> check-sibling <replaceable>yes_or_no</replaceable>; </optional>
+    <optional> allow-notify { <replaceable>address_match_list</replaceable> }; </optional>
+    <optional> allow-query { <replaceable>address_match_list</replaceable> }; </optional>
+    <optional> allow-query-cache { <replaceable>address_match_list</replaceable> }; </optional>
+    <optional> allow-transfer { <replaceable>address_match_list</replaceable> }; </optional>
+    <optional> allow-recursion { <replaceable>address_match_list</replaceable> }; </optional>
+    <optional> allow-update { <replaceable>address_match_list</replaceable> }; </optional>
+    <optional> allow-update-forwarding { <replaceable>address_match_list</replaceable> }; </optional>
+    <optional> update-check-ksk <replaceable>yes_or_no</replaceable>; </optional>
+    <optional> allow-v6-synthesis { <replaceable>address_match_list</replaceable> }; </optional>
+    <optional> blackhole { <replaceable>address_match_list</replaceable> }; </optional>
+    <optional> avoid-v4-udp-ports { <replaceable>port_list</replaceable> }; </optional>
+    <optional> avoid-v6-udp-ports { <replaceable>port_list</replaceable> }; </optional>
+    <optional> listen-on <optional> port <replaceable>ip_port</replaceable> </optional> { <replaceable>address_match_list</replaceable> }; </optional>
+    <optional> listen-on-v6 <optional> port <replaceable>ip_port</replaceable> </optional> { <replaceable>address_match_list</replaceable> }; </optional>
+    <optional> query-source ( ( <replaceable>ip4_addr</replaceable> | <replaceable>*</replaceable> )
+        <optional> port ( <replaceable>ip_port</replaceable> | <replaceable>*</replaceable> ) </optional> |
+	<optional> address ( <replaceable>ip4_addr</replaceable> | <replaceable>*</replaceable> ) </optional>
+	<optional> port ( <replaceable>ip_port</replaceable> | <replaceable>*</replaceable> ) </optional> ) ; </optional>
+    <optional> query-source-v6 ( ( <replaceable>ip6_addr</replaceable> | <replaceable>*</replaceable> )
+	<optional> port ( <replaceable>ip_port</replaceable> | <replaceable>*</replaceable> ) </optional> | 
+	<optional> address ( <replaceable>ip6_addr</replaceable> | <replaceable>*</replaceable> ) </optional> 
+	<optional> port ( <replaceable>ip_port</replaceable> | <replaceable>*</replaceable> ) </optional> ) ; </optional>
+    <optional> max-transfer-time-in <replaceable>number</replaceable>; </optional>
+    <optional> max-transfer-time-out <replaceable>number</replaceable>; </optional>
+    <optional> max-transfer-idle-in <replaceable>number</replaceable>; </optional>
+    <optional> max-transfer-idle-out <replaceable>number</replaceable>; </optional>
+    <optional> tcp-clients <replaceable>number</replaceable>; </optional>
+    <optional> recursive-clients <replaceable>number</replaceable>; </optional>
+    <optional> serial-query-rate <replaceable>number</replaceable>; </optional>
+    <optional> serial-queries <replaceable>number</replaceable>; </optional>
+    <optional> tcp-listen-queue <replaceable>number</replaceable>; </optional>
+    <optional> transfer-format <replaceable>( one-answer | many-answers )</replaceable>; </optional>
+    <optional> transfers-in  <replaceable>number</replaceable>; </optional>
+    <optional> transfers-out <replaceable>number</replaceable>; </optional>
+    <optional> transfers-per-ns <replaceable>number</replaceable>; </optional>
+    <optional> transfer-source (<replaceable>ip4_addr</replaceable> | <constant>*</constant>) <optional>port <replaceable>ip_port</replaceable></optional> ; </optional>
+    <optional> transfer-source-v6 (<replaceable>ip6_addr</replaceable> | <constant>*</constant>) <optional>port <replaceable>ip_port</replaceable></optional> ; </optional>
+    <optional> alt-transfer-source (<replaceable>ip4_addr</replaceable> | <constant>*</constant>) <optional>port <replaceable>ip_port</replaceable></optional> ; </optional>
+    <optional> alt-transfer-source-v6 (<replaceable>ip6_addr</replaceable> | <constant>*</constant>) <optional>port <replaceable>ip_port</replaceable></optional> ; </optional>
+    <optional> use-alt-transfer-source <replaceable>yes_or_no</replaceable>; </optional>
+    <optional> notify-delay <replaceable>seconds</replaceable> ; </optional>
+    <optional> notify-source (<replaceable>ip4_addr</replaceable> | <constant>*</constant>) <optional>port <replaceable>ip_port</replaceable></optional> ; </optional>
+    <optional> notify-source-v6 (<replaceable>ip6_addr</replaceable> | <constant>*</constant>) <optional>port <replaceable>ip_port</replaceable></optional> ; </optional>
+    <optional> also-notify { <replaceable>ip_addr</replaceable> <optional>port <replaceable>ip_port</replaceable></optional> ; <optional> <replaceable>ip_addr</replaceable> <optional>port <replaceable>ip_port</replaceable></optional> ; ... </optional> }; </optional>
+    <optional> max-ixfr-log-size <replaceable>number</replaceable>; </optional>
+    <optional> max-journal-size <replaceable>size_spec</replaceable>; </optional>
+    <optional> coresize <replaceable>size_spec</replaceable> ; </optional>
+    <optional> datasize <replaceable>size_spec</replaceable> ; </optional>
+    <optional> files <replaceable>size_spec</replaceable> ; </optional>
+    <optional> stacksize <replaceable>size_spec</replaceable> ; </optional>
+    <optional> cleaning-interval <replaceable>number</replaceable>; </optional>
+    <optional> heartbeat-interval <replaceable>number</replaceable>; </optional>
+    <optional> interface-interval <replaceable>number</replaceable>; </optional>
+    <optional> statistics-interval <replaceable>number</replaceable>; </optional>
+    <optional> topology { <replaceable>address_match_list</replaceable> }</optional>;
+    <optional> sortlist { <replaceable>address_match_list</replaceable> }</optional>;
+    <optional> rrset-order { <replaceable>order_spec</replaceable> ; <optional> <replaceable>order_spec</replaceable> ; ... </optional> </optional> };
+    <optional> lame-ttl <replaceable>number</replaceable>; </optional>
+    <optional> max-ncache-ttl <replaceable>number</replaceable>; </optional>
+    <optional> max-cache-ttl <replaceable>number</replaceable>; </optional>
+    <optional> sig-validity-interval <replaceable>number</replaceable> ; </optional>
+    <optional> min-roots <replaceable>number</replaceable>; </optional>
+    <optional> use-ixfr <replaceable>yes_or_no</replaceable> ; </optional>
+    <optional> provide-ixfr <replaceable>yes_or_no</replaceable>; </optional>
+    <optional> request-ixfr <replaceable>yes_or_no</replaceable>; </optional>
+    <optional> treat-cr-as-space <replaceable>yes_or_no</replaceable> ; </optional>
+    <optional> min-refresh-time <replaceable>number</replaceable> ; </optional>
+    <optional> max-refresh-time <replaceable>number</replaceable> ; </optional>
+    <optional> min-retry-time <replaceable>number</replaceable> ; </optional>
+    <optional> max-retry-time <replaceable>number</replaceable> ; </optional>
+    <optional> port <replaceable>ip_port</replaceable>; </optional>
+    <optional> additional-from-auth <replaceable>yes_or_no</replaceable> ; </optional>
+    <optional> additional-from-cache <replaceable>yes_or_no</replaceable> ; </optional>
+    <optional> random-device <replaceable>path_name</replaceable> ; </optional>
+    <optional> max-cache-size <replaceable>size_spec</replaceable> ; </optional>
+    <optional> match-mapped-addresses <replaceable>yes_or_no</replaceable>; </optional>
+    <optional> preferred-glue ( <replaceable>A</replaceable> | <replaceable>AAAA</replaceable> | <replaceable>NONE</replaceable> ); </optional>
+    <optional> edns-udp-size <replaceable>number</replaceable>; </optional>
+    <optional> max-udp-size <replaceable>number</replaceable>; </optional>
+    <optional> root-delegation-only <optional> exclude { <replaceable>namelist</replaceable> } </optional> ; </optional>
+    <optional> querylog <replaceable>yes_or_no</replaceable> ; </optional>
+    <optional> disable-algorithms <replaceable>domain</replaceable> { <replaceable>algorithm</replaceable>; <optional> <replaceable>algorithm</replaceable>; </optional> }; </optional>
+    <optional> acache-enable <replaceable>yes_or_no</replaceable> ; </optional>
+    <optional> acache-cleaning-interval <replaceable>number</replaceable>; </optional>
+    <optional> max-acache-size <replaceable>size_spec</replaceable> ; </optional>
+    <optional> clients-per-query <replaceable>number</replaceable> ; </optional>
+    <optional> max-clients-per-query <replaceable>number</replaceable> ; </optional>
+    <optional> masterfile-format (<constant>text</constant>|<constant>raw</constant>) ; </optional>
+    <optional> empty-server <replaceable>name</replaceable> ; </optional>
+    <optional> empty-contact <replaceable>name</replaceable> ; </optional>
+    <optional> empty-zones-enable <replaceable>yes_or_no</replaceable> ; </optional>
+    <optional> disable-empty-zone <replaceable>zone_name</replaceable> ; </optional>
+    <optional> zero-no-soa-ttl <replaceable>yes_or_no</replaceable> ; </optional>
+    <optional> zero-no-soa-ttl-cache <replaceable>yes_or_no</replaceable> ; </optional>
+};
+</programlisting>
+
+      </sect2>
+
+      <sect2 id="options">
+        <title><command>options</command> Statement Definition and
+          Usage</title>
+
+        <para>
+          The <command>options</command> statement sets up global
+          options
+          to be used by <acronym>BIND</acronym>. This statement
+          may appear only
+          once in a configuration file. If there is no <command>options</command>
+          statement, an options block with each option set to its default will
+          be used.
+        </para>
+
+        <variablelist>
+
+          <varlistentry>
+            <term><command>directory</command></term>
+            <listitem>
+              <para>
+                The working directory of the server.
+                Any non-absolute pathnames in the configuration file will be
+                taken
+                as relative to this directory. The default location for most
+                server
+                output files (e.g. <filename>named.run</filename>)
+                is this directory.
+                If a directory is not specified, the working directory
+                defaults to `<filename>.</filename>', the directory from
+                which the server
+                was started. The directory specified should be an absolute
+                path.
+              </para>
+            </listitem>
+          </varlistentry>
+
+          <varlistentry>
+            <term><command>key-directory</command></term>
+            <listitem>
+              <para>
+                When performing dynamic update of secure zones, the
+                directory where the public and private key files should be
+                found,
+                if different than the current working directory.  The
+                directory specified
+                must be an absolute path.
+              </para>
+            </listitem>
+          </varlistentry>
+
+          <varlistentry>
+            <term><command>named-xfer</command></term>
+            <listitem>
+              <para>
+                <emphasis>This option is obsolete.</emphasis>
+                It was used in <acronym>BIND</acronym> 8 to
+                specify the pathname to the <command>named-xfer</command> program.
+                In <acronym>BIND</acronym> 9, no separate <command>named-xfer</command> program is
+                needed; its functionality is built into the name server.
+              </para>
+
+            </listitem>
+          </varlistentry>
+
+          <varlistentry>
+            <term><command>tkey-domain</command></term>
+            <listitem>
+              <para>
+                The domain appended to the names of all
+                shared keys generated with
+                <command>TKEY</command>. When a client
+                requests a <command>TKEY</command> exchange, it
+                may or may not specify
+                the desired name for the key. If present, the name of the
+                shared
+                key will be "<varname>client specified part</varname>" +
+                "<varname>tkey-domain</varname>".
+                Otherwise, the name of the shared key will be "<varname>random hex
+digits</varname>" + "<varname>tkey-domain</varname>". In most cases,
+                the <command>domainname</command> should be the
+                server's domain
+                name.
+              </para>
+            </listitem>
+          </varlistentry>
+
+          <varlistentry>
+            <term><command>tkey-dhkey</command></term>
+            <listitem>
+              <para>
+                The Diffie-Hellman key used by the server
+                to generate shared keys with clients using the Diffie-Hellman
+                mode
+                of <command>TKEY</command>. The server must be
+                able to load the
+                public and private keys from files in the working directory.
+                In
+                most cases, the keyname should be the server's host name.
+              </para>
+            </listitem>
+          </varlistentry>
+
+          <varlistentry>
+            <term><command>cache-file</command></term>
+            <listitem>
+              <para>
+		This is for testing only.  Do not use.
+              </para>
+            </listitem>
+          </varlistentry>
+
+          <varlistentry>
+            <term><command>dump-file</command></term>
+            <listitem>
+              <para>
+                The pathname of the file the server dumps
+                the database to when instructed to do so with
+                <command>rndc dumpdb</command>.
+                If not specified, the default is <filename>named_dump.db</filename>.
+              </para>
+            </listitem>
+          </varlistentry>
+
+          <varlistentry>
+            <term><command>memstatistics-file</command></term>
+            <listitem>
+              <para>
+                The pathname of the file the server writes memory
+                usage statistics to on exit.  If specified the
+		statistics will be written to the file on exit.
+              </para>
+	      <para>
+		In <acronym>BIND</acronym> 9.5 and later this will
+		default to <filename>named.memstats</filename>.
+		<acronym>BIND</acronym> 9.5 will also introduce
+		<command>memstatistics</command> to control the
+		writing.
+	      </para>
+	    </listitem>
+	  </varlistentry>
+
+          <varlistentry>
+            <term><command>pid-file</command></term>
+            <listitem>
+              <para>
+                The pathname of the file the server writes its process ID
+                in. If not specified, the default is <filename>/var/run/named.pid</filename>.
+                The pid-file is used by programs that want to send signals to
+                the running
+                name server. Specifying <command>pid-file none</command> disables the
+                use of a PID file &mdash; no file will be written and any
+                existing one will be removed.  Note that <command>none</command>
+                is a keyword, not a filename, and therefore is not enclosed
+                in
+                double quotes.
+              </para>
+            </listitem>
+          </varlistentry>
+
+          <varlistentry>
+            <term><command>recursing-file</command></term>
+            <listitem>
+              <para>
+                The pathname of the file the server dumps
+                the queries that are currently recursing when instructed
+                to do so with <command>rndc recursing</command>.
+                If not specified, the default is <filename>named.recursing</filename>.
+              </para>
+            </listitem>
+          </varlistentry>
+
+          <varlistentry>
+            <term><command>statistics-file</command></term>
+            <listitem>
+              <para>
+                The pathname of the file the server appends statistics
+                to when instructed to do so using <command>rndc stats</command>.
+                If not specified, the default is <filename>named.stats</filename> in the
+                server's current directory.  The format of the file is
+                described
+                in <xref linkend="statsfile"/>.
+              </para>
+            </listitem>
+          </varlistentry>
+
+          <varlistentry>
+            <term><command>port</command></term>
+            <listitem>
+              <para>
+                The UDP/TCP port number the server uses for
+                receiving and sending DNS protocol traffic.
+                The default is 53.  This option is mainly intended for server
+                testing;
+                a server using a port other than 53 will not be able to
+                communicate with
+                the global DNS.
+              </para>
+            </listitem>
+          </varlistentry>
+
+          <varlistentry>
+            <term><command>random-device</command></term>
+            <listitem>
+              <para>
+                The source of entropy to be used by the server.  Entropy is
+                primarily needed
+                for DNSSEC operations, such as TKEY transactions and dynamic
+                update of signed
+                zones.  This options specifies the device (or file) from which
+                to read
+                entropy.  If this is a file, operations requiring entropy will
+                fail when the
+                file has been exhausted.  If not specified, the default value
+                is
+                <filename>/dev/random</filename>
+                (or equivalent) when present, and none otherwise.  The
+                <command>random-device</command> option takes
+                effect during
+                the initial configuration load at server startup time and
+                is ignored on subsequent reloads.
+              </para>
+            </listitem>
+          </varlistentry>
+
+          <varlistentry>
+            <term><command>preferred-glue</command></term>
+            <listitem>
+              <para>
+                If specified, the listed type (A or AAAA) will be emitted
+                before other glue
+                in the additional section of a query response.
+                The default is not to prefer any type (NONE).
+              </para>
+            </listitem>
+          </varlistentry>
+
+          <varlistentry>
+            <term><command>root-delegation-only</command></term>
+            <listitem>
+              <para>
+                Turn on enforcement of delegation-only in TLDs (top level domains) and root zones
+                with an optional
+                exclude list.
+              </para>
+              <para>
+                Note some TLDs are not delegation only (e.g. "DE", "LV", "US"
+                and "MUSEUM").
+              </para>
+
+<programlisting>
+options {
+	root-delegation-only exclude { "de"; "lv"; "us"; "museum"; };
+};
+</programlisting>
+
+            </listitem>
+          </varlistentry>
+
+          <varlistentry>
+            <term><command>disable-algorithms</command></term>
+            <listitem>
+              <para>
+                Disable the specified DNSSEC algorithms at and below the
+                specified name.
+                Multiple <command>disable-algorithms</command>
+                statements are allowed.
+                Only the most specific will be applied.
+              </para>
+            </listitem>
+          </varlistentry>
+
+          <varlistentry>
+            <term><command>dnssec-lookaside</command></term>
+            <listitem>
+              <para>
+                When set, <command>dnssec-lookaside</command>
+                provides the
+                validator with an alternate method to validate DNSKEY records
+                at the
+                top of a zone.  When a DNSKEY is at or below a domain
+                specified by the
+                deepest <command>dnssec-lookaside</command>, and
+                the normal dnssec validation
+                has left the key untrusted, the trust-anchor will be append to
+                the key
+                name and a DLV record will be looked up to see if it can
+                validate the
+                key.  If the DLV record validates a DNSKEY (similarly to the
+                way a DS
+                record does) the DNSKEY RRset is deemed to be trusted.
+              </para>
+            </listitem>
+          </varlistentry>
+
+          <varlistentry>
+            <term><command>dnssec-must-be-secure</command></term>
+            <listitem>
+              <para>
+                Specify hierarchies which must be or may not be secure (signed and
+                validated).
+                If <userinput>yes</userinput>, then named will only accept
+                answers if they
+                are secure.
+                If <userinput>no</userinput>, then normal dnssec validation
+                applies
+                allowing for insecure answers to be accepted.
+                The specified domain must be under a <command>trusted-key</command> or
+                <command>dnssec-lookaside</command> must be
+                active.
+              </para>
+            </listitem>
+          </varlistentry>
+
+        </variablelist>
+
+        <sect3 id="boolean_options">
+          <title>Boolean Options</title>
+
+          <variablelist>
+
+            <varlistentry>
+              <term><command>auth-nxdomain</command></term>
+              <listitem>
+                <para>
+                  If <userinput>yes</userinput>, then the <command>AA</command> bit
+                  is always set on NXDOMAIN responses, even if the server is
+                  not actually
+                  authoritative. The default is <userinput>no</userinput>;
+                  this is
+                  a change from <acronym>BIND</acronym> 8. If you
+                  are using very old DNS software, you
+                  may need to set it to <userinput>yes</userinput>.
+                </para>
+              </listitem>
+            </varlistentry>
+
+            <varlistentry>
+              <term><command>deallocate-on-exit</command></term>
+              <listitem>
+                <para>
+                  This option was used in <acronym>BIND</acronym>
+                  8 to enable checking
+                  for memory leaks on exit. <acronym>BIND</acronym> 9 ignores the option and always performs
+                  the checks.
+                </para>
+              </listitem>
+            </varlistentry>
+
+            <varlistentry>
+              <term><command>dialup</command></term>
+              <listitem>
+                <para>
+                  If <userinput>yes</userinput>, then the
+                  server treats all zones as if they are doing zone transfers
+                  across
+                  a dial-on-demand dialup link, which can be brought up by
+                  traffic
+                  originating from this server. This has different effects
+                  according
+                  to zone type and concentrates the zone maintenance so that
+                  it all
+                  happens in a short interval, once every <command>heartbeat-interval</command> and
+                  hopefully during the one call. It also suppresses some of
+                  the normal
+                  zone maintenance traffic. The default is <userinput>no</userinput>.
+                </para>
+                <para>
+                  The <command>dialup</command> option
+                  may also be specified in the <command>view</command> and
+                  <command>zone</command> statements,
+                  in which case it overrides the global <command>dialup</command>
+                  option.
+                </para>
+                <para>
+                  If the zone is a master zone, then the server will send out a
+                  NOTIFY
+                  request to all the slaves (default). This should trigger the
+                  zone serial
+                  number check in the slave (providing it supports NOTIFY)
+                  allowing the slave
+                  to verify the zone while the connection is active.
+                  The set of servers to which NOTIFY is sent can be controlled
+                  by
+                  <command>notify</command> and <command>also-notify</command>.
+                </para>
+                <para>
+                  If the
+                  zone is a slave or stub zone, then the server will suppress
+                  the regular
+                  "zone up to date" (refresh) queries and only perform them
+                  when the
+                  <command>heartbeat-interval</command> expires in
+                  addition to sending
+                  NOTIFY requests.
+                </para>
+                <para>
+                  Finer control can be achieved by using
+                  <userinput>notify</userinput> which only sends NOTIFY
+                  messages,
+                  <userinput>notify-passive</userinput> which sends NOTIFY
+                  messages and
+                  suppresses the normal refresh queries, <userinput>refresh</userinput>
+                  which suppresses normal refresh processing and sends refresh
+                  queries
+                  when the <command>heartbeat-interval</command>
+                  expires, and
+                  <userinput>passive</userinput> which just disables normal
+                  refresh
+                  processing.
+                </para>
+
+                <informaltable colsep="0" rowsep="0">
+                  <tgroup cols="4" colsep="0" rowsep="0" tgroupstyle="4Level-table">
+                    <colspec colname="1" colnum="1" colsep="0" colwidth="1.150in"/>
+                    <colspec colname="2" colnum="2" colsep="0" colwidth="1.150in"/>
+                    <colspec colname="3" colnum="3" colsep="0" colwidth="1.150in"/>
+                    <colspec colname="4" colnum="4" colsep="0" colwidth="1.150in"/>
+                    <tbody>
+                      <row rowsep="0">
+                        <entry colname="1">
+                          <para>
+                            dialup mode
+                          </para>
+                        </entry>
+                        <entry colname="2">
+                          <para>
+                            normal refresh
+                          </para>
+                        </entry>
+                        <entry colname="3">
+                          <para>
+                            heart-beat refresh
+                          </para>
+                        </entry>
+                        <entry colname="4">
+                          <para>
+                            heart-beat notify
+                          </para>
+                        </entry>
+                      </row>
+                      <row rowsep="0">
+                        <entry colname="1">
+                          <para><command>no</command> (default)</para>
+                        </entry>
+                        <entry colname="2">
+                          <para>
+                            yes
+                          </para>
+                        </entry>
+                        <entry colname="3">
+                          <para>
+                            no
+                          </para>
+                        </entry>
+                        <entry colname="4">
+                          <para>
+                            no
+                          </para>
+                        </entry>
+                      </row>
+                      <row rowsep="0">
+                        <entry colname="1">
+                          <para><command>yes</command></para>
+                        </entry>
+                        <entry colname="2">
+                          <para>
+                            no
+                          </para>
+                        </entry>
+                        <entry colname="3">
+                          <para>
+                            yes
+                          </para>
+                        </entry>
+                        <entry colname="4">
+                          <para>
+                            yes
+                          </para>
+                        </entry>
+                      </row>
+                      <row rowsep="0">
+                        <entry colname="1">
+                          <para><command>notify</command></para>
+                        </entry>
+                        <entry colname="2">
+                          <para>
+                            yes
+                          </para>
+                        </entry>
+                        <entry colname="3">
+                          <para>
+                            no
+                          </para>
+                        </entry>
+                        <entry colname="4">
+                          <para>
+                            yes
+                          </para>
+                        </entry>
+                      </row>
+                      <row rowsep="0">
+                        <entry colname="1">
+                          <para><command>refresh</command></para>
+                        </entry>
+                        <entry colname="2">
+                          <para>
+                            no
+                          </para>
+                        </entry>
+                        <entry colname="3">
+                          <para>
+                            yes
+                          </para>
+                        </entry>
+                        <entry colname="4">
+                          <para>
+                            no
+                          </para>
+                        </entry>
+                      </row>
+                      <row rowsep="0">
+                        <entry colname="1">
+                          <para><command>passive</command></para>
+                        </entry>
+                        <entry colname="2">
+                          <para>
+                            no
+                          </para>
+                        </entry>
+                        <entry colname="3">
+                          <para>
+                            no
+                          </para>
+                        </entry>
+                        <entry colname="4">
+                          <para>
+                            no
+                          </para>
+                        </entry>
+                      </row>
+                      <row rowsep="0">
+                        <entry colname="1">
+                          <para><command>notify-passive</command></para>
+                        </entry>
+                        <entry colname="2">
+                          <para>
+                            no
+                          </para>
+                        </entry>
+                        <entry colname="3">
+                          <para>
+                            no
+                          </para>
+                        </entry>
+                        <entry colname="4">
+                          <para>
+                            yes
+                          </para>
+                        </entry>
+                      </row>
+                    </tbody>
+                  </tgroup>
+                </informaltable>
+
+                <para>
+                  Note that normal NOTIFY processing is not affected by
+                  <command>dialup</command>.
+                </para>
+
+              </listitem>
+            </varlistentry>
+
+            <varlistentry>
+              <term><command>fake-iquery</command></term>
+              <listitem>
+                <para>
+                  In <acronym>BIND</acronym> 8, this option
+                  enabled simulating the obsolete DNS query type
+                  IQUERY. <acronym>BIND</acronym> 9 never does
+                  IQUERY simulation.
+                </para>
+              </listitem>
+            </varlistentry>
+
+            <varlistentry>
+              <term><command>fetch-glue</command></term>
+              <listitem>
+                <para>
+                  This option is obsolete.
+                  In BIND 8, <userinput>fetch-glue yes</userinput>
+                  caused the server to attempt to fetch glue resource records
+                  it
+                  didn't have when constructing the additional
+                  data section of a response.  This is now considered a bad
+                  idea
+                  and BIND 9 never does it.
+                </para>
+              </listitem>
+            </varlistentry>
+
+            <varlistentry>
+              <term><command>flush-zones-on-shutdown</command></term>
+              <listitem>
+                <para>
+                  When the nameserver exits due receiving SIGTERM,
+                  flush or do not flush any pending zone writes.  The default
+                  is
+                  <command>flush-zones-on-shutdown</command> <userinput>no</userinput>.
+                </para>
+              </listitem>
+            </varlistentry>
+
+            <varlistentry>
+              <term><command>has-old-clients</command></term>
+              <listitem>
+                <para>
+                  This option was incorrectly implemented
+                  in <acronym>BIND</acronym> 8, and is ignored by <acronym>BIND</acronym> 9.
+                  To achieve the intended effect
+                  of
+                  <command>has-old-clients</command> <userinput>yes</userinput>, specify
+                  the two separate options <command>auth-nxdomain</command> <userinput>yes</userinput>
+                  and <command>rfc2308-type1</command> <userinput>no</userinput> instead.
+                </para>
+              </listitem>
+            </varlistentry>
+
+            <varlistentry>
+              <term><command>host-statistics</command></term>
+              <listitem>
+                <para>
+                  In BIND 8, this enables keeping of
+                  statistics for every host that the name server interacts
+                  with.
+                  Not implemented in BIND 9.
+                </para>
+              </listitem>
+            </varlistentry>
+
+            <varlistentry>
+              <term><command>maintain-ixfr-base</command></term>
+              <listitem>
+                <para>
+                  <emphasis>This option is obsolete</emphasis>.
+                  It was used in <acronym>BIND</acronym> 8 to
+                  determine whether a transaction log was
+                  kept for Incremental Zone Transfer. <acronym>BIND</acronym> 9 maintains a transaction
+                  log whenever possible.  If you need to disable outgoing
+                  incremental zone
+                  transfers, use <command>provide-ixfr</command> <userinput>no</userinput>.
+                </para>
+              </listitem>
+            </varlistentry>
+
+            <varlistentry>
+              <term><command>minimal-responses</command></term>
+              <listitem>
+                <para>
+                  If <userinput>yes</userinput>, then when generating
+                  responses the server will only add records to the authority
+                  and additional data sections when they are required (e.g.
+                  delegations, negative responses).  This may improve the
+		  performance of the server.
+                  The default is <userinput>no</userinput>.
+                </para>
+              </listitem>
+            </varlistentry>
+
+            <varlistentry>
+              <term><command>multiple-cnames</command></term>
+              <listitem>
+                <para>
+                  This option was used in <acronym>BIND</acronym> 8 to allow
+                  a domain name to have multiple CNAME records in violation of
+                  the DNS standards.  <acronym>BIND</acronym> 9.2 onwards
+                  always strictly enforces the CNAME rules both in master
+		  files and dynamic updates.
+                </para>
+              </listitem>
+            </varlistentry>
+
+            <varlistentry>
+              <term><command>notify</command></term>
+              <listitem>
+                <para>
+                  If <userinput>yes</userinput> (the default),
+                  DNS NOTIFY messages are sent when a zone the server is
+                  authoritative for
+                  changes, see <xref linkend="notify"/>.  The messages are
+                  sent to the
+                  servers listed in the zone's NS records (except the master
+                  server identified
+                  in the SOA MNAME field), and to any servers listed in the
+                  <command>also-notify</command> option.
+                </para>
+                <para>
+                  If <userinput>master-only</userinput>, notifies are only
+                  sent
+                  for master zones.
+                  If <userinput>explicit</userinput>, notifies are sent only
+                  to
+                  servers explicitly listed using <command>also-notify</command>.
+                  If <userinput>no</userinput>, no notifies are sent.
+                </para>
+                <para>
+                  The <command>notify</command> option may also be
+                  specified in the <command>zone</command>
+                  statement,
+                  in which case it overrides the <command>options notify</command> statement.
+                  It would only be necessary to turn off this option if it
+                  caused slaves
+                  to crash.
+                </para>
+              </listitem>
+            </varlistentry>
+
+            <varlistentry>
+              <term><command>recursion</command></term>
+              <listitem>
+                <para>
+                  If <userinput>yes</userinput>, and a
+                  DNS query requests recursion, then the server will attempt
+                  to do
+                  all the work required to answer the query. If recursion is
+                  off
+                  and the server does not already know the answer, it will
+                  return a
+                  referral response. The default is
+                  <userinput>yes</userinput>.
+                  Note that setting <command>recursion no</command> does not prevent
+                  clients from getting data from the server's cache; it only
+                  prevents new data from being cached as an effect of client
+                  queries.
+                  Caching may still occur as an effect the server's internal
+                  operation, such as NOTIFY address lookups.
+                  See also <command>fetch-glue</command> above.
+                </para>
+              </listitem>
+            </varlistentry>
+
+            <varlistentry>
+              <term><command>rfc2308-type1</command></term>
+              <listitem>
+                <para>
+                  Setting this to <userinput>yes</userinput> will
+                  cause the server to send NS records along with the SOA
+                  record for negative
+                  answers. The default is <userinput>no</userinput>.
+                </para>
+                <note>
+                  <simpara>
+                    Not yet implemented in <acronym>BIND</acronym>
+                    9.
+                  </simpara>
+                </note>
+              </listitem>
+            </varlistentry>
+
+            <varlistentry>
+              <term><command>use-id-pool</command></term>
+              <listitem>
+                <para>
+                  <emphasis>This option is obsolete</emphasis>.
+                  <acronym>BIND</acronym> 9 always allocates query
+                  IDs from a pool.
+                </para>
+              </listitem>
+            </varlistentry>
+
+            <varlistentry>
+              <term><command>zone-statistics</command></term>
+              <listitem>
+                <para>
+                  If <userinput>yes</userinput>, the server will collect
+                  statistical data on all zones (unless specifically turned
+                  off
+                  on a per-zone basis by specifying <command>zone-statistics no</command>
+                  in the <command>zone</command> statement).
+                  These statistics may be accessed
+                  using <command>rndc stats</command>, which will
+                  dump them to the file listed
+                  in the <command>statistics-file</command>.  See
+                  also <xref linkend="statsfile"/>.
+                </para>
+              </listitem>
+            </varlistentry>
+
+            <varlistentry>
+              <term><command>use-ixfr</command></term>
+              <listitem>
+                <para>
+                  <emphasis>This option is obsolete</emphasis>.
+                  If you need to disable IXFR to a particular server or
+                  servers, see
+                  the information on the <command>provide-ixfr</command> option
+                  in <xref linkend="server_statement_definition_and_usage"/>.
+                  See also
+                  <xref linkend="incremental_zone_transfers"/>.
+                </para>
+              </listitem>
+            </varlistentry>
+
+            <varlistentry>
+              <term><command>provide-ixfr</command></term>
+              <listitem>
+                <para>
+                  See the description of
+                  <command>provide-ixfr</command> in
+                  <xref linkend="server_statement_definition_and_usage"/>.
+                </para>
+              </listitem>
+            </varlistentry>
+
+            <varlistentry>
+              <term><command>request-ixfr</command></term>
+              <listitem>
+                <para>
+                  See the description of
+                  <command>request-ixfr</command> in
+                  <xref linkend="server_statement_definition_and_usage"/>.
+                </para>
+              </listitem>
+            </varlistentry>
+
+            <varlistentry>
+              <term><command>treat-cr-as-space</command></term>
+              <listitem>
+                <para>
+                  This option was used in <acronym>BIND</acronym>
+                  8 to make
+                  the server treat carriage return ("<command>\r</command>") characters the same way
+                  as a space or tab character,
+                  to facilitate loading of zone files on a UNIX system that
+                  were generated
+                  on an NT or DOS machine. In <acronym>BIND</acronym> 9, both UNIX "<command>\n</command>"
+                  and NT/DOS "<command>\r\n</command>" newlines
+                  are always accepted,
+                  and the option is ignored.
+                </para>
+              </listitem>
+            </varlistentry>
+
+            <varlistentry>
+              <term><command>additional-from-auth</command></term>
+              <term><command>additional-from-cache</command></term>
+              <listitem>
+
+                <para>
+                  These options control the behavior of an authoritative
+                  server when
+                  answering queries which have additional data, or when
+                  following CNAME
+                  and DNAME chains.
+                </para>
+
+                <para>
+                  When both of these options are set to <userinput>yes</userinput>
+                  (the default) and a
+                  query is being answered from authoritative data (a zone
+                  configured into the server), the additional data section of
+                  the
+                  reply will be filled in using data from other authoritative
+                  zones
+                  and from the cache.  In some situations this is undesirable,
+                  such
+                  as when there is concern over the correctness of the cache,
+                  or
+                  in servers where slave zones may be added and modified by
+                  untrusted third parties.  Also, avoiding
+                  the search for this additional data will speed up server
+                  operations
+                  at the possible expense of additional queries to resolve
+                  what would
+                  otherwise be provided in the additional section.
+                </para>
+
+                <para>
+                  For example, if a query asks for an MX record for host <literal>foo.example.com</literal>,
+                  and the record found is "<literal>MX 10 mail.example.net</literal>", normally the address
+                  records (A and AAAA) for <literal>mail.example.net</literal> will be provided as well,
+                  if known, even though they are not in the example.com zone.
+                  Setting these options to <command>no</command>
+                  disables this behavior and makes
+                  the server only search for additional data in the zone it
+                  answers from.
+                </para>
+
+                <para>
+                  These options are intended for use in authoritative-only
+                  servers, or in authoritative-only views.  Attempts to set
+                  them to <command>no</command> without also
+                  specifying
+                  <command>recursion no</command> will cause the
+                  server to
+                  ignore the options and log a warning message.
+                </para>
+
+                <para>
+                  Specifying <command>additional-from-cache no</command> actually
+                  disables the use of the cache not only for additional data
+                  lookups
+                  but also when looking up the answer.  This is usually the
+                  desired
+                  behavior in an authoritative-only server where the
+                  correctness of
+                  the cached data is an issue.
+                </para>
+
+                <para>
+                  When a name server is non-recursively queried for a name
+                  that is not
+                  below the apex of any served zone, it normally answers with
+                  an
+                  "upwards referral" to the root servers or the servers of
+                  some other
+                  known parent of the query name.  Since the data in an
+                  upwards referral
+                  comes from the cache, the server will not be able to provide
+                  upwards
+                  referrals when <command>additional-from-cache no</command>
+                  has been specified.  Instead, it will respond to such
+                  queries
+                  with REFUSED.  This should not cause any problems since
+                  upwards referrals are not required for the resolution
+                  process.
+                </para>
+
+              </listitem>
+            </varlistentry>
+
+            <varlistentry>
+              <term><command>match-mapped-addresses</command></term>
+              <listitem>
+                <para>
+                  If <userinput>yes</userinput>, then an
+                  IPv4-mapped IPv6 address will match any address match
+                  list entries that match the corresponding IPv4 address.
+                  Enabling this option is sometimes useful on IPv6-enabled
+                  Linux
+                  systems, to work around a kernel quirk that causes IPv4
+                  TCP connections such as zone transfers to be accepted
+                  on an IPv6 socket using mapped addresses, causing
+                  address match lists designed for IPv4 to fail to match.
+                  The use of this option for any other purpose is discouraged.
+                </para>
+              </listitem>
+            </varlistentry>
+
+            <varlistentry>
+              <term><command>ixfr-from-differences</command></term>
+              <listitem>
+                <para>
+                  When <userinput>yes</userinput> and the server loads a new version of a master
+                  zone from its zone file or receives a new version of a slave
+                  file by a non-incremental zone transfer, it will compare
+                  the new version to the previous one and calculate a set
+                  of differences.  The differences are then logged in the
+                  zone's journal file such that the changes can be transmitted
+                  to downstream slaves as an incremental zone transfer.
+                </para>
+                <para>
+                  By allowing incremental zone transfers to be used for
+                  non-dynamic zones, this option saves bandwidth at the
+                  expense of increased CPU and memory consumption at the
+                  master.
+                  In particular, if the new version of a zone is completely
+                  different from the previous one, the set of differences
+                  will be of a size comparable to the combined size of the
+                  old and new zone version, and the server will need to
+                  temporarily allocate memory to hold this complete
+                  difference set.
+                </para>
+                <para><command>ixfr-from-differences</command>
+		  also accepts <command>master</command> and
+                  <command>slave</command> at the view and options
+                  levels which causes
+                  <command>ixfr-from-differences</command> to apply to
+                  all <command>master</command> or
+                  <command>slave</command> zones respectively.
+                </para>
+              </listitem>
+            </varlistentry>
+
+            <varlistentry>
+              <term><command>multi-master</command></term>
+              <listitem>
+                <para>
+                  This should be set when you have multiple masters for a zone
+                  and the
+                  addresses refer to different machines.  If <userinput>yes</userinput>, named will
+                  not log
+                  when the serial number on the master is less than what named
+                  currently
+                  has.  The default is <userinput>no</userinput>.
+                </para>
+              </listitem>
+            </varlistentry>
+
+            <varlistentry>
+              <term><command>dnssec-enable</command></term>
+              <listitem>
+                <para>
+                  Enable DNSSEC support in named.  Unless set to <userinput>yes</userinput>,
+                  named behaves as if it does not support DNSSEC.
+                  The default is <userinput>yes</userinput>.
+                </para>
+              </listitem>
+            </varlistentry>
+
+            <varlistentry>
+              <term><command>dnssec-validation</command></term>
+              <listitem>
+                <para>
+                  Enable DNSSEC validation in named.
+		  Note <command>dnssec-enable</command> also needs to be
+		  set to <userinput>yes</userinput> to be effective.
+                  The default is <userinput>no</userinput>.
+                </para>
+              </listitem>
+            </varlistentry>
+
+            <varlistentry>
+              <term><command>dnssec-accept-expired</command></term>
+              <listitem>
+                <para>
+		  Accept expired signatures when verifying DNSSEC signatures.
+                  The default is <userinput>no</userinput>.
+		  Setting this option to "yes" leaves named vulnerable to replay attacks.
+                </para>
+              </listitem>
+            </varlistentry>
+
+            <varlistentry>
+              <term><command>querylog</command></term>
+              <listitem>
+                <para>
+                  Specify whether query logging should be started when named
+                  starts.
+                  If <command>querylog</command> is not specified,
+                  then the query logging
+                  is determined by the presence of the logging category <command>queries</command>.
+                </para>
+              </listitem>
+            </varlistentry>
+
+            <varlistentry>
+              <term><command>check-names</command></term>
+              <listitem>
+                <para>
+                  This option is used to restrict the character set and syntax
+                  of
+                  certain domain names in master files and/or DNS responses
+                  received
+                  from the network.  The default varies according to usage
+                  area.  For
+                  <command>master</command> zones the default is <command>fail</command>.
+                  For <command>slave</command> zones the default
+                  is <command>warn</command>.
+                  For answers received from the network (<command>response</command>)
+                  the default is <command>ignore</command>.
+                </para>
+                <para>
+                  The rules for legal hostnames and mail domains are derived
+                  from RFC 952 and RFC 821 as modified by RFC 1123.
+                </para>
+                <para><command>check-names</command>
+		  applies to the owner names of A, AAA and MX records.
+		  It also applies to the domain names in the RDATA of NS, SOA
+		  and MX records.
+		  It also applies to the RDATA of PTR records where the owner
+		  name indicated that it is a reverse lookup of a hostname
+		  (the owner name ends in IN-ADDR.ARPA, IP6.ARPA, or IP6.INT).
+                </para>
+              </listitem>
+            </varlistentry>
+
+	    <varlistentry>
+	      <term><command>check-mx</command></term>
+	      <listitem>
+		<para>
+		  Check whether the MX record appears to refer to a IP address.
+		  The default is to <command>warn</command>.  Other possible
+		  values are <command>fail</command> and
+		  <command>ignore</command>.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+            <varlistentry>
+              <term><command>check-wildcard</command></term>
+              <listitem>
+                <para>
+                  This option is used to check for non-terminal wildcards.
+                  The use of non-terminal wildcards is almost always as a
+                  result of a failure
+                  to understand the wildcard matching algorithm (RFC 1034).
+                  This option
+                  affects master zones.  The default (<command>yes</command>) is to check
+                  for non-terminal wildcards and issue a warning.
+                </para>
+              </listitem>
+            </varlistentry>
+
+	    <varlistentry>
+	      <term><command>check-integrity</command></term>
+	      <listitem>
+		<para>
+		  Perform post load zone integrity checks on master
+		  zones.  This checks that MX and SRV records refer
+		  to address (A or AAAA) records and that glue
+		  address records exist for delegated zones.  For
+		  MX and SRV records only in-zone hostnames are
+		  checked (for out-of-zone hostnames use named-checkzone).
+		  For NS records only names below top of zone are
+		  checked (for out-of-zone names and glue consistency
+		  checks use named-checkzone).  The default is
+		  <command>yes</command>.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>check-mx-cname</command></term>
+	      <listitem>
+		<para>
+		  If <command>check-integrity</command> is set then
+		  fail, warn or ignore MX records that refer
+		  to CNAMES.  The default is to <command>warn</command>.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>check-srv-cname</command></term>
+	      <listitem>
+		<para>
+		  If <command>check-integrity</command> is set then
+		  fail, warn or ignore SRV records that refer
+		  to CNAMES.  The default is to <command>warn</command>.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>check-sibling</command></term>
+	      <listitem>
+		<para>
+		  When performing integrity checks, also check that
+		  sibling glue exists.  The default is <command>yes</command>.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>zero-no-soa-ttl</command></term>
+	      <listitem>
+	        <para>
+		  When returning authoritative negative responses to
+		  SOA queries set the TTL of the SOA recored returned in
+		  the authority section to zero.
+		  The default is <command>yes</command>.
+	        </para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>zero-no-soa-ttl-cache</command></term>
+	      <listitem>
+	        <para>
+		  When caching a negative response to a SOA query
+		  set the TTL to zero.
+		  The default is <command>no</command>.
+	        </para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>update-check-ksk</command></term>
+	      <listitem>
+	        <para>
+		  When regenerating the RRSIGs following a UPDATE
+		  request to a secure zone, check the KSK flag on
+		  the DNSKEY RR to determine if this key should be
+		  used to generate the RRSIG.  This flag is ignored
+		  if there are not DNSKEY RRs both with and without
+		  a KSK.
+		  The default is <command>yes</command>.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+          </variablelist>
+
+        </sect3>
+
+        <sect3>
+          <title>Forwarding</title>
+          <para>
+            The forwarding facility can be used to create a large site-wide
+            cache on a few servers, reducing traffic over links to external
+            name servers. It can also be used to allow queries by servers that
+            do not have direct access to the Internet, but wish to look up
+            exterior
+            names anyway. Forwarding occurs only on those queries for which
+            the server is not authoritative and does not have the answer in
+            its cache.
+          </para>
+
+          <variablelist>
+            <varlistentry>
+              <term><command>forward</command></term>
+              <listitem>
+                <para>
+                  This option is only meaningful if the
+                  forwarders list is not empty. A value of <varname>first</varname>,
+                  the default, causes the server to query the forwarders
+                  first &mdash; and
+                  if that doesn't answer the question, the server will then
+                  look for
+                  the answer itself. If <varname>only</varname> is
+                  specified, the
+                  server will only query the forwarders.
+                </para>
+              </listitem>
+            </varlistentry>
+
+            <varlistentry>
+              <term><command>forwarders</command></term>
+              <listitem>
+                <para>
+                  Specifies the IP addresses to be used
+                  for forwarding. The default is the empty list (no
+                  forwarding).
+                </para>
+              </listitem>
+            </varlistentry>
+
+          </variablelist>
+
+          <para>
+            Forwarding can also be configured on a per-domain basis, allowing
+            for the global forwarding options to be overridden in a variety
+            of ways. You can set particular domains to use different
+            forwarders,
+            or have a different <command>forward only/first</command> behavior,
+            or not forward at all, see <xref linkend="zone_statement_grammar"/>.
+          </para>
+        </sect3>
+
+        <sect3>
+          <title>Dual-stack Servers</title>
+          <para>
+            Dual-stack servers are used as servers of last resort to work
+            around
+            problems in reachability due the lack of support for either IPv4
+            or IPv6
+            on the host machine.
+          </para>
+
+          <variablelist>
+            <varlistentry>
+              <term><command>dual-stack-servers</command></term>
+              <listitem>
+                <para>
+                  Specifies host names or addresses of machines with access to
+                  both IPv4 and IPv6 transports. If a hostname is used, the
+                  server must be able
+                  to resolve the name using only the transport it has.  If the
+                  machine is dual
+                  stacked, then the <command>dual-stack-servers</command> have no effect unless
+                  access to a transport has been disabled on the command line
+                  (e.g. <command>named -4</command>).
+                </para>
+              </listitem>
+            </varlistentry>
+          </variablelist>
+        </sect3>
+
+        <sect3 id="access_control">
+          <title>Access Control</title>
+
+          <para>
+            Access to the server can be restricted based on the IP address
+            of the requesting system. See <xref linkend="address_match_lists"/> for
+            details on how to specify IP address lists.
+          </para>
+
+          <variablelist>
+
+            <varlistentry>
+              <term><command>allow-notify</command></term>
+              <listitem>
+                <para>
+                  Specifies which hosts are allowed to
+                  notify this server, a slave, of zone changes in addition
+                  to the zone masters.
+                  <command>allow-notify</command> may also be
+                  specified in the
+                  <command>zone</command> statement, in which case
+                  it overrides the
+                  <command>options allow-notify</command>
+                  statement.  It is only meaningful
+                  for a slave zone.  If not specified, the default is to
+                  process notify messages
+                  only from a zone's master.
+                </para>
+              </listitem>
+            </varlistentry>
+
+	    <varlistentry>
+	      <term><command>allow-query</command></term>
+	      <listitem>
+		<para>
+		  Specifies which hosts are allowed to ask ordinary
+		  DNS questions. <command>allow-query</command> may
+		  also be specified in the <command>zone</command>
+		  statement, in which case it overrides the
+		  <command>options allow-query</command> statement.
+		  If not specified, the default is to allow queries
+		  from all hosts.
+		</para>
+		<note>
+		  <para>
+		    <command>allow-query-cache</command> is now
+		    used to specify access to the cache.
+		  </para>
+		</note>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>allow-query-cache</command></term>
+	      <listitem>
+		<para>
+		  Specifies which hosts are allowed to get answers
+		  from the cache.  If <command>allow-query-cache</command>
+		  is not set then <command>allow-recursion</command>
+		  is used if set, otherwise <command>allow-query</command>
+		  is used if set, otherwise the default
+		  (<command>localnets;</command>
+		  <command>localhost;</command>) is used.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+            <varlistentry>
+              <term><command>allow-recursion</command></term>
+              <listitem>
+		<para>
+		  Specifies which hosts are allowed to make recursive
+		  queries through this server. If
+		  <command>allow-recursion</command> is not set
+		  then <command>allow-query-cache</command> is
+		  used if set, otherwise <command>allow-query</command>
+		  is used if set, otherwise the default
+		  (<command>localnets;</command>
+		  <command>localhost;</command>) is used.
+		</para>
+              </listitem>
+            </varlistentry>
+
+            <varlistentry>
+              <term><command>allow-update</command></term>
+              <listitem>
+                <para>
+                  Specifies which hosts are allowed to
+                  submit Dynamic DNS updates for master zones. The default is
+                  to deny
+                  updates from all hosts.  Note that allowing updates based
+                  on the requestor's IP address is insecure; see
+                  <xref linkend="dynamic_update_security"/> for details.
+                </para>
+              </listitem>
+            </varlistentry>
+
+            <varlistentry>
+              <term><command>allow-update-forwarding</command></term>
+              <listitem>
+                <para>
+                  Specifies which hosts are allowed to
+                  submit Dynamic DNS updates to slave zones to be forwarded to
+                  the
+                  master.  The default is <userinput>{ none; }</userinput>,
+                  which
+                  means that no update forwarding will be performed.  To
+                  enable
+                  update forwarding, specify
+                  <userinput>allow-update-forwarding { any; };</userinput>.
+                  Specifying values other than <userinput>{ none; }</userinput> or
+                  <userinput>{ any; }</userinput> is usually
+                  counterproductive, since
+                  the responsibility for update access control should rest
+                  with the
+                  master server, not the slaves.
+                </para>
+                <para>
+                  Note that enabling the update forwarding feature on a slave
+                  server
+                  may expose master servers relying on insecure IP address
+                  based
+                  access control to attacks; see <xref linkend="dynamic_update_security"/>
+                  for more details.
+                </para>
+              </listitem>
+            </varlistentry>
+
+            <varlistentry>
+              <term><command>allow-v6-synthesis</command></term>
+              <listitem>
+                <para>
+                  This option was introduced for the smooth transition from
+                  AAAA
+                  to A6 and from "nibble labels" to binary labels.
+                  However, since both A6 and binary labels were then
+                  deprecated,
+                  this option was also deprecated.
+                  It is now ignored with some warning messages.
+                </para>
+              </listitem>
+            </varlistentry>
+
+            <varlistentry>
+              <term><command>allow-transfer</command></term>
+              <listitem>
+                <para>
+                  Specifies which hosts are allowed to
+                  receive zone transfers from the server. <command>allow-transfer</command> may
+                  also be specified in the <command>zone</command>
+                  statement, in which
+                  case it overrides the <command>options allow-transfer</command> statement.
+                  If not specified, the default is to allow transfers to all
+                  hosts.
+                </para>
+              </listitem>
+            </varlistentry>
+
+            <varlistentry>
+              <term><command>blackhole</command></term>
+              <listitem>
+                <para>
+                  Specifies a list of addresses that the
+                  server will not accept queries from or use to resolve a
+                  query. Queries
+                  from these addresses will not be responded to. The default
+                  is <userinput>none</userinput>.
+                </para>
+              </listitem>
+            </varlistentry>
+
+          </variablelist>
+
+        </sect3>
+
+        <sect3>
+          <title>Interfaces</title>
+          <para>
+            The interfaces and ports that the server will answer queries
+            from may be specified using the <command>listen-on</command> option. <command>listen-on</command> takes
+            an optional port, and an <varname>address_match_list</varname>.
+            The server will listen on all interfaces allowed by the address
+            match list. If a port is not specified, port 53 will be used.
+          </para>
+          <para>
+            Multiple <command>listen-on</command> statements are
+            allowed.
+            For example,
+          </para>
+
+<programlisting>listen-on { 5.6.7.8; };
+listen-on port 1234 { !1.2.3.4; 1.2/16; };
+</programlisting>
+
+          <para>
+            will enable the name server on port 53 for the IP address
+            5.6.7.8, and on port 1234 of an address on the machine in net
+            1.2 that is not 1.2.3.4.
+          </para>
+
+          <para>
+            If no <command>listen-on</command> is specified, the
+            server will listen on port 53 on all interfaces.
+          </para>
+
+          <para>
+            The <command>listen-on-v6</command> option is used to
+            specify the interfaces and the ports on which the server will
+            listen
+            for incoming queries sent using IPv6.
+          </para>
+
+          <para>
+            When <programlisting>{ any; }</programlisting> is
+            specified
+            as the <varname>address_match_list</varname> for the
+            <command>listen-on-v6</command> option,
+            the server does not bind a separate socket to each IPv6 interface
+            address as it does for IPv4 if the operating system has enough API
+            support for IPv6 (specifically if it conforms to RFC 3493 and RFC
+            3542).
+            Instead, it listens on the IPv6 wildcard address.
+            If the system only has incomplete API support for IPv6, however,
+            the behavior is the same as that for IPv4.
+          </para>
+
+          <para>
+            A list of particular IPv6 addresses can also be specified, in
+            which case
+            the server listens on a separate socket for each specified
+            address,
+            regardless of whether the desired API is supported by the system.
+          </para>
+
+          <para>
+            Multiple <command>listen-on-v6</command> options can
+            be used.
+            For example,
+          </para>
+
+<programlisting>listen-on-v6 { any; };
+listen-on-v6 port 1234 { !2001:db8::/32; any; };
+</programlisting>
+
+          <para>
+            will enable the name server on port 53 for any IPv6 addresses
+            (with a single wildcard socket),
+            and on port 1234 of IPv6 addresses that is not in the prefix
+            2001:db8::/32 (with separate sockets for each matched address.)
+          </para>
+
+          <para>
+            To make the server not listen on any IPv6 address, use
+          </para>
+
+<programlisting>listen-on-v6 { none; };
+</programlisting>
+
+          <para>
+            If no <command>listen-on-v6</command> option is
+            specified,
+            the server will not listen on any IPv6 address.
+          </para>
+        </sect3>
+
+        <sect3>
+          <title>Query Address</title>
+          <para>
+            If the server doesn't know the answer to a question, it will
+            query other name servers. <command>query-source</command> specifies
+            the address and port used for such queries. For queries sent over
+            IPv6, there is a separate <command>query-source-v6</command> option.
+            If <command>address</command> is <command>*</command> (asterisk) or is omitted,
+            a wildcard IP address (<command>INADDR_ANY</command>)
+            will be used.
+            If <command>port</command> is <command>*</command> or is omitted,
+            a random unprivileged port will be used. The <command>avoid-v4-udp-ports</command>
+            and <command>avoid-v6-udp-ports</command> options can be used
+            to prevent named
+            from selecting certain ports. The defaults are:
+          </para>
+
+<programlisting>query-source address * port *;
+query-source-v6 address * port *;
+</programlisting>
+
+          <note>
+            <para>
+              The address specified in the <command>query-source</command> option
+              is used for both UDP and TCP queries, but the port applies only
+              to
+              UDP queries.  TCP queries always use a random
+              unprivileged port.
+            </para>
+          </note>
+	  <note>
+	    <para>
+	      Solaris 2.5.1 and earlier does not support setting the source
+	      address for TCP sockets.
+	    </para>
+	  </note>
+          <note>
+            <para>
+              See also <command>transfer-source</command> and
+              <command>notify-source</command>.
+            </para>
+          </note>
+        </sect3>
+
+        <sect3 id="zone_transfers">
+          <title>Zone Transfers</title>
+          <para>
+            <acronym>BIND</acronym> has mechanisms in place to
+            facilitate zone transfers
+            and set limits on the amount of load that transfers place on the
+            system. The following options apply to zone transfers.
+          </para>
+
+          <variablelist>
+
+            <varlistentry>
+              <term><command>also-notify</command></term>
+              <listitem>
+                <para>
+                  Defines a global list of IP addresses of name servers
+                  that are also sent NOTIFY messages whenever a fresh copy of
+                  the
+                  zone is loaded, in addition to the servers listed in the
+                  zone's NS records.
+                  This helps to ensure that copies of the zones will
+                  quickly converge on stealth servers. If an <command>also-notify</command> list
+                  is given in a <command>zone</command> statement,
+                  it will override
+                  the <command>options also-notify</command>
+                  statement. When a <command>zone notify</command>
+                  statement
+                  is set to <command>no</command>, the IP
+                  addresses in the global <command>also-notify</command> list will
+                  not be sent NOTIFY messages for that zone. The default is
+                  the empty
+                  list (no global notification list).
+                </para>
+              </listitem>
+            </varlistentry>
+
+            <varlistentry>
+              <term><command>max-transfer-time-in</command></term>
+              <listitem>
+                <para>
+                  Inbound zone transfers running longer than
+                  this many minutes will be terminated. The default is 120
+                  minutes
+                  (2 hours).  The maximum value is 28 days (40320 minutes).
+                </para>
+              </listitem>
+            </varlistentry>
+
+            <varlistentry>
+              <term><command>max-transfer-idle-in</command></term>
+              <listitem>
+                <para>
+                  Inbound zone transfers making no progress
+                  in this many minutes will be terminated. The default is 60
+                  minutes
+                  (1 hour).  The maximum value is 28 days (40320 minutes).
+                </para>
+              </listitem>
+            </varlistentry>
+
+            <varlistentry>
+              <term><command>max-transfer-time-out</command></term>
+              <listitem>
+                <para>
+                  Outbound zone transfers running longer than
+                  this many minutes will be terminated. The default is 120
+                  minutes
+                  (2 hours).  The maximum value is 28 days (40320 minutes).
+                </para>
+              </listitem>
+            </varlistentry>
+
+            <varlistentry>
+              <term><command>max-transfer-idle-out</command></term>
+              <listitem>
+                <para>
+                  Outbound zone transfers making no progress
+                  in this many minutes will be terminated.  The default is 60
+                  minutes (1
+                  hour).  The maximum value is 28 days (40320 minutes).
+                </para>
+              </listitem>
+            </varlistentry>
+
+            <varlistentry>
+              <term><command>serial-query-rate</command></term>
+              <listitem>
+                <para>
+                  Slave servers will periodically query master servers
+                  to find out if zone serial numbers have changed. Each such
+                  query uses
+                  a minute amount of the slave server's network bandwidth.  To
+                  limit the
+                  amount of bandwidth used, BIND 9 limits the rate at which
+                  queries are
+                  sent.  The value of the <command>serial-query-rate</command> option,
+                  an integer, is the maximum number of queries sent per
+                  second.
+                  The default is 20.
+                </para>
+              </listitem>
+            </varlistentry>
+
+            <varlistentry>
+              <term><command>serial-queries</command></term>
+              <listitem>
+                <para>
+                  In BIND 8, the <command>serial-queries</command>
+                  option
+                  set the maximum number of concurrent serial number queries
+                  allowed to be outstanding at any given time.
+                  BIND 9 does not limit the number of outstanding
+                  serial queries and ignores the <command>serial-queries</command> option.
+                  Instead, it limits the rate at which the queries are sent
+                  as defined using the <command>serial-query-rate</command> option.
+                </para>
+              </listitem>
+            </varlistentry>
+
+            <varlistentry>
+              <term><command>transfer-format</command></term>
+              <listitem>
+
+                <para>
+                  Zone transfers can be sent using two different formats,
+                  <command>one-answer</command> and
+		  <command>many-answers</command>.
+                  The <command>transfer-format</command> option is used
+                  on the master server to determine which format it sends.
+                  <command>one-answer</command> uses one DNS message per
+                  resource record transferred.
+                  <command>many-answers</command> packs as many resource
+		  records as possible into a message.
+		  <command>many-answers</command> is more efficient, but is
+		  only supported by relatively new slave servers,
+                  such as <acronym>BIND</acronym> 9, <acronym>BIND</acronym>
+		  8.x and <acronym>BIND</acronym> 4.9.5 onwards.
+	          The <command>many-answers</command> format is also supported by
+		  recent Microsoft Windows nameservers.
+		  The default is <command>many-answers</command>.
+		  <command>transfer-format</command> may be overridden on a
+		  per-server basis by using the <command>server</command>
+		  statement.
+                </para>
+
+              </listitem>
+            </varlistentry>
+
+            <varlistentry>
+              <term><command>transfers-in</command></term>
+              <listitem>
+                <para>
+                  The maximum number of inbound zone transfers
+                  that can be running concurrently. The default value is <literal>10</literal>.
+                  Increasing <command>transfers-in</command> may
+                  speed up the convergence
+                  of slave zones, but it also may increase the load on the
+                  local system.
+                </para>
+              </listitem>
+            </varlistentry>
+
+            <varlistentry>
+              <term><command>transfers-out</command></term>
+              <listitem>
+                <para>
+                  The maximum number of outbound zone transfers
+                  that can be running concurrently. Zone transfer requests in
+                  excess
+                  of the limit will be refused. The default value is <literal>10</literal>.
+                </para>
+              </listitem>
+            </varlistentry>
+
+            <varlistentry>
+              <term><command>transfers-per-ns</command></term>
+              <listitem>
+                <para>
+                  The maximum number of inbound zone transfers
+                  that can be concurrently transferring from a given remote
+                  name server.
+                  The default value is <literal>2</literal>.
+                  Increasing <command>transfers-per-ns</command>
+                  may
+                  speed up the convergence of slave zones, but it also may
+                  increase
+                  the load on the remote name server. <command>transfers-per-ns</command> may
+                  be overridden on a per-server basis by using the <command>transfers</command> phrase
+                  of the <command>server</command> statement.
+                </para>
+              </listitem>
+            </varlistentry>
+
+            <varlistentry>
+              <term><command>transfer-source</command></term>
+              <listitem>
+                <para><command>transfer-source</command>
+		  determines which local address will be bound to IPv4
+                  TCP connections used to fetch zones transferred
+                  inbound by the server.  It also determines the
+                  source IPv4 address, and optionally the UDP port,
+                  used for the refresh queries and forwarded dynamic
+                  updates.  If not set, it defaults to a system
+                  controlled value which will usually be the address
+                  of the interface "closest to" the remote end. This
+                  address must appear in the remote end's
+                  <command>allow-transfer</command> option for the
+                  zone being transferred, if one is specified. This
+                  statement sets the
+                  <command>transfer-source</command> for all zones,
+                  but can be overridden on a per-view or per-zone
+                  basis by including a
+                  <command>transfer-source</command> statement within
+                  the <command>view</command> or
+                  <command>zone</command> block in the configuration
+                  file.
+                </para>
+	        <note>
+	          <para>
+	            Solaris 2.5.1 and earlier does not support setting the
+		    source address for TCP sockets.
+	          </para>
+                </note>
+              </listitem>
+            </varlistentry>
+
+            <varlistentry>
+              <term><command>transfer-source-v6</command></term>
+              <listitem>
+                <para>
+                  The same as <command>transfer-source</command>,
+                  except zone transfers are performed using IPv6.
+                </para>
+              </listitem>
+            </varlistentry>
+
+            <varlistentry>
+              <term><command>alt-transfer-source</command></term>
+              <listitem>
+                <para>
+                  An alternate transfer source if the one listed in
+                  <command>transfer-source</command> fails and
+                  <command>use-alt-transfer-source</command> is
+                  set.
+                </para>
+		<note>
+		  If you do not wish the alternate transfer source
+		  to be used, you should set
+		  <command>use-alt-transfer-source</command>
+		  appropriately and you should not depend upon
+		  getting a answer back to the first refresh
+		  query.
+		</note>
+              </listitem>
+            </varlistentry>
+
+            <varlistentry>
+              <term><command>alt-transfer-source-v6</command></term>
+              <listitem>
+                <para>
+                  An alternate transfer source if the one listed in
+                  <command>transfer-source-v6</command> fails and
+                  <command>use-alt-transfer-source</command> is
+                  set.
+                </para>
+              </listitem>
+            </varlistentry>
+
+            <varlistentry>
+              <term><command>use-alt-transfer-source</command></term>
+              <listitem>
+                <para>
+                  Use the alternate transfer sources or not.  If views are
+                  specified this defaults to <command>no</command>
+                  otherwise it defaults to
+                  <command>yes</command> (for BIND 8
+                  compatibility).
+                </para>
+              </listitem>
+            </varlistentry>
+
+            <varlistentry>
+              <term><command>notify-source</command></term>
+              <listitem>
+                <para><command>notify-source</command>
+		  determines which local source address, and
+                  optionally UDP port, will be used to send NOTIFY
+                  messages.  This address must appear in the slave
+                  server's <command>masters</command> zone clause or
+                  in an <command>allow-notify</command> clause.  This
+                  statement sets the <command>notify-source</command>
+                  for all zones, but can be overridden on a per-zone or
+                  per-view basis by including a
+                  <command>notify-source</command> statement within
+                  the <command>zone</command> or
+                  <command>view</command> block in the configuration
+                  file.
+                </para>
+	        <note>
+	          <para>
+	            Solaris 2.5.1 and earlier does not support setting the
+		    source address for TCP sockets.
+	          </para>
+                </note>
+              </listitem>
+            </varlistentry>
+
+            <varlistentry>
+              <term><command>notify-source-v6</command></term>
+              <listitem>
+                <para>
+                  Like <command>notify-source</command>,
+                  but applies to notify messages sent to IPv6 addresses.
+                </para>
+              </listitem>
+            </varlistentry>
+
+          </variablelist>
+
+        </sect3>
+
+        <sect3>
+          <title>Bad UDP Port Lists</title>
+          <para><command>avoid-v4-udp-ports</command>
+	    and <command>avoid-v6-udp-ports</command> specify a list
+            of IPv4 and IPv6 UDP ports that will not be used as system
+            assigned source ports for UDP sockets.  These lists
+            prevent named from choosing as its random source port a
+            port that is blocked by your firewall.  If a query went
+            out with such a source port, the answer would not get by
+            the firewall and the name server would have to query
+            again.
+          </para>
+        </sect3>
+
+        <sect3>
+          <title>Operating System Resource Limits</title>
+
+          <para>
+            The server's usage of many system resources can be limited.
+            Scaled values are allowed when specifying resource limits.  For
+            example, <command>1G</command> can be used instead of
+            <command>1073741824</command> to specify a limit of
+            one
+            gigabyte. <command>unlimited</command> requests
+            unlimited use, or the
+            maximum available amount. <command>default</command>
+            uses the limit
+            that was in force when the server was started. See the description
+            of <command>size_spec</command> in <xref linkend="configuration_file_elements"/>.
+          </para>
+
+          <para>
+            The following options set operating system resource limits for
+            the name server process.  Some operating systems don't support
+            some or
+            any of the limits. On such systems, a warning will be issued if
+            the
+            unsupported limit is used.
+          </para>
+
+          <variablelist>
+
+            <varlistentry>
+              <term><command>coresize</command></term>
+              <listitem>
+                <para>
+                  The maximum size of a core dump. The default
+                  is <literal>default</literal>.
+                </para>
+              </listitem>
+            </varlistentry>
+
+            <varlistentry>
+              <term><command>datasize</command></term>
+              <listitem>
+                <para>
+                  The maximum amount of data memory the server
+                  may use. The default is <literal>default</literal>.
+                  This is a hard limit on server memory usage.
+                  If the server attempts to allocate memory in excess of this
+                  limit, the allocation will fail, which may in turn leave
+                  the server unable to perform DNS service.  Therefore,
+                  this option is rarely useful as a way of limiting the
+                  amount of memory used by the server, but it can be used
+                  to raise an operating system data size limit that is
+                  too small by default.  If you wish to limit the amount
+                  of memory used by the server, use the
+                  <command>max-cache-size</command> and
+                  <command>recursive-clients</command>
+                  options instead.
+                </para>
+              </listitem>
+            </varlistentry>
+
+            <varlistentry>
+              <term><command>files</command></term>
+              <listitem>
+                <para>
+                  The maximum number of files the server
+                  may have open concurrently. The default is <literal>unlimited</literal>.
+                </para>
+              </listitem>
+            </varlistentry>
+
+            <varlistentry>
+              <term><command>stacksize</command></term>
+              <listitem>
+                <para>
+                  The maximum amount of stack memory the server
+                  may use. The default is <literal>default</literal>.
+                </para>
+              </listitem>
+            </varlistentry>
+
+          </variablelist>
+
+        </sect3>
+
+        <sect3>
+          <title>Server  Resource Limits</title>
+
+          <para>
+            The following options set limits on the server's
+            resource consumption that are enforced internally by the
+            server rather than the operating system.
+          </para>
+
+          <variablelist>
+
+            <varlistentry>
+              <term><command>max-ixfr-log-size</command></term>
+              <listitem>
+                <para>
+                  This option is obsolete; it is accepted
+                  and ignored for BIND 8 compatibility.  The option
+                  <command>max-journal-size</command> performs a
+                  similar function in BIND 9.
+                </para>
+              </listitem>
+            </varlistentry>
+
+            <varlistentry>
+              <term><command>max-journal-size</command></term>
+              <listitem>
+                <para>
+                  Sets a maximum size for each journal file
+                  (see <xref linkend="journal"/>).  When the journal file
+                  approaches
+                  the specified size, some of the oldest transactions in the
+                  journal
+                  will be automatically removed.  The default is
+                  <literal>unlimited</literal>.
+                </para>
+              </listitem>
+            </varlistentry>
+
+            <varlistentry>
+              <term><command>host-statistics-max</command></term>
+              <listitem>
+                <para>
+                  In BIND 8, specifies the maximum number of host statistics
+                  entries to be kept.
+                  Not implemented in BIND 9.
+                </para>
+              </listitem>
+            </varlistentry>
+
+            <varlistentry>
+              <term><command>recursive-clients</command></term>
+              <listitem>
+                <para>
+                  The maximum number of simultaneous recursive lookups
+                  the server will perform on behalf of clients.  The default
+                  is
+                  <literal>1000</literal>.  Because each recursing
+                  client uses a fair
+                  bit of memory, on the order of 20 kilobytes, the value of
+                  the
+                  <command>recursive-clients</command> option may
+                  have to be decreased
+                  on hosts with limited memory.
+                </para>
+              </listitem>
+            </varlistentry>
+
+            <varlistentry>
+              <term><command>tcp-clients</command></term>
+              <listitem>
+                <para>
+                  The maximum number of simultaneous client TCP
+                  connections that the server will accept.
+                  The default is <literal>100</literal>.
+                </para>
+              </listitem>
+            </varlistentry>
+
+            <varlistentry>
+              <term><command>max-cache-size</command></term>
+              <listitem>
+                <para>
+                  The maximum amount of memory to use for the
+                  server's cache, in bytes.  When the amount of data in the
+                  cache
+                  reaches this limit, the server will cause records to expire
+                  prematurely so that the limit is not exceeded.  In a server
+                  with
+                  multiple views, the limit applies separately to the cache of
+                  each
+                  view.  The default is <literal>unlimited</literal>, meaning that
+                  records are purged from the cache only when their TTLs
+                  expire.
+                </para>
+              </listitem>
+            </varlistentry>
+
+            <varlistentry>
+              <term><command>tcp-listen-queue</command></term>
+              <listitem>
+                <para>
+                  The listen queue depth.  The default and minimum is 3.
+                  If the kernel supports the accept filter "dataready" this
+                  also controls how
+                  many TCP connections that will be queued in kernel space
+                  waiting for
+                  some data before being passed to accept.  Values less than 3
+                  will be
+                  silently raised.
+                </para>
+              </listitem>
+            </varlistentry>
+
+          </variablelist>
+
+        </sect3>
+
+        <sect3>
+          <title>Periodic Task Intervals</title>
+
+          <variablelist>
+
+            <varlistentry>
+              <term><command>cleaning-interval</command></term>
+              <listitem>
+                <para>
+                  The server will remove expired resource records
+                  from the cache every <command>cleaning-interval</command> minutes.
+                  The default is 60 minutes.  The maximum value is 28 days
+                  (40320 minutes).
+                  If set to 0, no periodic cleaning will occur.
+                </para>
+              </listitem>
+            </varlistentry>
+
+            <varlistentry>
+              <term><command>heartbeat-interval</command></term>
+              <listitem>
+                <para>
+                  The server will perform zone maintenance tasks
+                  for all zones marked as <command>dialup</command> whenever this
+                  interval expires. The default is 60 minutes. Reasonable
+                  values are up
+                  to 1 day (1440 minutes).  The maximum value is 28 days
+                  (40320 minutes).
+                  If set to 0, no zone maintenance for these zones will occur.
+                </para>
+              </listitem>
+            </varlistentry>
+
+            <varlistentry>
+              <term><command>interface-interval</command></term>
+              <listitem>
+                <para>
+                  The server will scan the network interface list
+                  every <command>interface-interval</command>
+                  minutes. The default
+                  is 60 minutes. The maximum value is 28 days (40320 minutes).
+                  If set to 0, interface scanning will only occur when
+                  the configuration file is  loaded. After the scan, the
+                  server will
+                  begin listening for queries on any newly discovered
+                  interfaces (provided they are allowed by the
+                  <command>listen-on</command> configuration), and
+                  will
+                  stop listening on interfaces that have gone away.
+                </para>
+              </listitem>
+            </varlistentry>
+
+            <varlistentry>
+              <term><command>statistics-interval</command></term>
+              <listitem>
+                <para>
+                  Name server statistics will be logged
+                  every <command>statistics-interval</command>
+                  minutes. The default is
+                  60. The maximum value is 28 days (40320 minutes).
+                  If set to 0, no statistics will be logged.
+                  </para><note>
+                  <simpara>
+                    Not yet implemented in
+                    <acronym>BIND</acronym> 9.
+                  </simpara>
+                </note>
+              </listitem>
+            </varlistentry>
+
+          </variablelist>
+
+        </sect3>
+
+        <sect3 id="topology">
+          <title>Topology</title>
+
+          <para>
+            All other things being equal, when the server chooses a name
+            server
+            to query from a list of name servers, it prefers the one that is
+            topologically closest to itself. The <command>topology</command> statement
+            takes an <command>address_match_list</command> and
+            interprets it
+            in a special way. Each top-level list element is assigned a
+            distance.
+            Non-negated elements get a distance based on their position in the
+            list, where the closer the match is to the start of the list, the
+            shorter the distance is between it and the server. A negated match
+            will be assigned the maximum distance from the server. If there
+            is no match, the address will get a distance which is further than
+            any non-negated list element, and closer than any negated element.
+            For example,
+          </para>
+
+<programlisting>topology {
+    10/8;
+    !1.2.3/24;
+    { 1.2/16; 3/8; };
+};</programlisting>
+
+          <para>
+            will prefer servers on network 10 the most, followed by hosts
+            on network 1.2.0.0 (netmask 255.255.0.0) and network 3, with the
+            exception of hosts on network 1.2.3 (netmask 255.255.255.0), which
+            is preferred least of all.
+          </para>
+          <para>
+            The default topology is
+          </para>
+
+<programlisting>    topology { localhost; localnets; };
+</programlisting>
+
+          <note>
+            <simpara>
+              The <command>topology</command> option
+              is not implemented in <acronym>BIND</acronym> 9.
+            </simpara>
+          </note>
+        </sect3>
+
+        <sect3 id="the_sortlist_statement">
+
+          <title>The <command>sortlist</command> Statement</title>
+
+          <para>
+            The response to a DNS query may consist of multiple resource
+            records (RRs) forming a resource records set (RRset).
+            The name server will normally return the
+            RRs within the RRset in an indeterminate order
+            (but see the <command>rrset-order</command>
+            statement in <xref linkend="rrset_ordering"/>).
+            The client resolver code should rearrange the RRs as appropriate,
+            that is, using any addresses on the local net in preference to
+            other addresses.
+            However, not all resolvers can do this or are correctly
+            configured.
+            When a client is using a local server, the sorting can be performed
+            in the server, based on the client's address. This only requires
+            configuring the name servers, not all the clients.
+          </para>
+
+          <para>
+            The <command>sortlist</command> statement (see below)
+            takes
+            an <command>address_match_list</command> and
+            interprets it even
+            more specifically than the <command>topology</command>
+            statement
+            does (<xref linkend="topology"/>).
+            Each top level statement in the <command>sortlist</command> must
+            itself be an explicit <command>address_match_list</command> with
+            one or two elements. The first element (which may be an IP
+            address,
+            an IP prefix, an ACL name or a nested <command>address_match_list</command>)
+            of each top level list is checked against the source address of
+            the query until a match is found.
+          </para>
+          <para>
+            Once the source address of the query has been matched, if
+            the top level statement contains only one element, the actual
+            primitive
+            element that matched the source address is used to select the
+            address
+            in the response to move to the beginning of the response. If the
+            statement is a list of two elements, then the second element is
+            treated the same as the <command>address_match_list</command> in
+            a <command>topology</command> statement. Each top
+            level element
+            is assigned a distance and the address in the response with the
+            minimum
+            distance is moved to the beginning of the response.
+          </para>
+          <para>
+            In the following example, any queries received from any of
+            the addresses of the host itself will get responses preferring
+            addresses
+            on any of the locally connected networks. Next most preferred are
+            addresses
+            on the 192.168.1/24 network, and after that either the
+            192.168.2/24
+            or
+            192.168.3/24 network with no preference shown between these two
+            networks. Queries received from a host on the 192.168.1/24 network
+            will prefer other addresses on that network to the 192.168.2/24
+            and
+            192.168.3/24 networks. Queries received from a host on the
+            192.168.4/24
+            or the 192.168.5/24 network will only prefer other addresses on
+            their directly connected networks.
+          </para>
+
+<programlisting>sortlist {
+    { localhost;                                   // IF   the local host
+        { localnets;                               // THEN first fit on the
+            192.168.1/24;                          //   following nets
+            { 192.168.2/24; 192.168.3/24; }; }; };
+    { 192.168.1/24;                                // IF   on class C 192.168.1
+        { 192.168.1/24;                            // THEN use .1, or .2 or .3
+            { 192.168.2/24; 192.168.3/24; }; }; };
+    { 192.168.2/24;                                // IF   on class C 192.168.2
+        { 192.168.2/24;                            // THEN use .2, or .1 or .3
+            { 192.168.1/24; 192.168.3/24; }; }; };
+    { 192.168.3/24;                                // IF   on class C 192.168.3
+        { 192.168.3/24;                            // THEN use .3, or .1 or .2
+            { 192.168.1/24; 192.168.2/24; }; }; };
+    { { 192.168.4/24; 192.168.5/24; };             // if .4 or .5, prefer that net
+    };
+};</programlisting>
+
+          <para>
+            The following example will give reasonable behavior for the
+            local host and hosts on directly connected networks. It is similar
+            to the behavior of the address sort in <acronym>BIND</acronym> 4.9.x. Responses sent
+            to queries from the local host will favor any of the directly
+            connected
+            networks. Responses sent to queries from any other hosts on a
+            directly
+            connected network will prefer addresses on that same network.
+            Responses
+            to other queries will not be sorted.
+          </para>
+
+<programlisting>sortlist {
+           { localhost; localnets; };
+           { localnets; };
+};
+</programlisting>
+
+        </sect3>
+        <sect3 id="rrset_ordering">
+          <title id="rrset_ordering_title">RRset Ordering</title>
+          <para>
+            When multiple records are returned in an answer it may be
+            useful to configure the order of the records placed into the
+            response.
+            The <command>rrset-order</command> statement permits
+            configuration
+            of the ordering of the records in a multiple record response.
+            See also the <command>sortlist</command> statement,
+            <xref linkend="the_sortlist_statement"/>.
+          </para>
+
+          <para>
+            An <command>order_spec</command> is defined as
+            follows:
+          </para>
+          <para>
+	    <optional>class <replaceable>class_name</replaceable></optional>
+            <optional>type <replaceable>type_name</replaceable></optional>
+            <optional>name <replaceable>"domain_name"</replaceable></optional>
+	    order <replaceable>ordering</replaceable>
+	  </para>
+          <para>
+            If no class is specified, the default is <command>ANY</command>.
+            If no type is specified, the default is <command>ANY</command>.
+            If no name is specified, the default is "<command>*</command>" (asterisk).
+          </para>
+          <para>
+            The legal values for <command>ordering</command> are:
+          </para>
+          <informaltable colsep="0" rowsep="0">
+            <tgroup cols="2" colsep="0" rowsep="0" tgroupstyle="4Level-table">
+              <colspec colname="1" colnum="1" colsep="0" colwidth="0.750in"/>
+              <colspec colname="2" colnum="2" colsep="0" colwidth="3.750in"/>
+              <tbody>
+                <row rowsep="0">
+                  <entry colname="1">
+                    <para><command>fixed</command></para>
+                  </entry>
+                  <entry colname="2">
+                    <para>
+                      Records are returned in the order they
+                      are defined in the zone file.
+                    </para>
+                  </entry>
+                </row>
+                <row rowsep="0">
+                  <entry colname="1">
+                    <para><command>random</command></para>
+                  </entry>
+                  <entry colname="2">
+                    <para>
+                      Records are returned in some random order.
+                    </para>
+                  </entry>
+                </row>
+                <row rowsep="0">
+                  <entry colname="1">
+                    <para><command>cyclic</command></para>
+                  </entry>
+                  <entry colname="2">
+                    <para>
+                      Records are returned in a round-robin
+                      order.
+                    </para>
+                  </entry>
+                </row>
+              </tbody>
+            </tgroup>
+          </informaltable>
+          <para>
+            For example:
+          </para>
+
+<programlisting>rrset-order {
+   class IN type A name "host.example.com" order random;
+   order cyclic;
+};
+</programlisting>
+
+          <para>
+            will cause any responses for type A records in class IN that
+            have "<literal>host.example.com</literal>" as a
+            suffix, to always be returned
+            in random order. All other records are returned in cyclic order.
+          </para>
+          <para>
+            If multiple <command>rrset-order</command> statements
+            appear,
+            they are not combined &mdash; the last one applies.
+          </para>
+
+          <note>
+            <simpara>
+              The <command>rrset-order</command> statement
+              is not yet fully implemented in <acronym>BIND</acronym> 9.
+              BIND 9 currently does not fully support "fixed" ordering.
+            </simpara>
+          </note>
+        </sect3>
+
+        <sect3 id="tuning">
+          <title>Tuning</title>
+
+          <variablelist>
+
+            <varlistentry>
+              <term><command>lame-ttl</command></term>
+              <listitem>
+                <para>
+                  Sets the number of seconds to cache a
+                  lame server indication. 0 disables caching. (This is
+                  <emphasis role="bold">NOT</emphasis> recommended.)
+                  The default is <literal>600</literal> (10 minutes) and the
+                  maximum value is
+                  <literal>1800</literal> (30 minutes).
+                </para>
+
+              </listitem>
+            </varlistentry>
+
+            <varlistentry>
+              <term><command>max-ncache-ttl</command></term>
+              <listitem>
+                <para>
+                  To reduce network traffic and increase performance,
+                  the server stores negative answers. <command>max-ncache-ttl</command> is
+                  used to set a maximum retention time for these answers in
+                  the server
+                  in seconds. The default
+                  <command>max-ncache-ttl</command> is <literal>10800</literal> seconds (3 hours).
+                  <command>max-ncache-ttl</command> cannot exceed
+                  7 days and will
+                  be silently truncated to 7 days if set to a greater value.
+                </para>
+              </listitem>
+            </varlistentry>
+
+            <varlistentry>
+              <term><command>max-cache-ttl</command></term>
+              <listitem>
+                <para>
+		  Sets the maximum time for which the server will
+                  cache ordinary (positive) answers. The default is
+                  one week (7 days).
+                </para>
+              </listitem>
+            </varlistentry>
+
+            <varlistentry>
+              <term><command>min-roots</command></term>
+              <listitem>
+                <para>
+                  The minimum number of root servers that
+                  is required for a request for the root servers to be
+                  accepted. The default
+                  is <userinput>2</userinput>.
+                </para>
+                <note>
+                  <simpara>
+                    Not implemented in <acronym>BIND</acronym> 9.
+                  </simpara>
+                </note>
+              </listitem>
+            </varlistentry>
+
+            <varlistentry>
+              <term><command>sig-validity-interval</command></term>
+              <listitem>
+                <para>
+                  Specifies the number of days into the
+                  future when DNSSEC signatures automatically generated as a
+                  result
+                  of dynamic updates (<xref linkend="dynamic_update"/>)
+                  will expire. The default is <literal>30</literal> days.
+                  The maximum value is 10 years (3660 days). The signature
+                  inception time is unconditionally set to one hour before the
+                  current time
+                  to allow for a limited amount of clock skew.
+                </para>
+              </listitem>
+            </varlistentry>
+
+            <varlistentry>
+              <term><command>min-refresh-time</command></term>
+              <term><command>max-refresh-time</command></term>
+              <term><command>min-retry-time</command></term>
+              <term><command>max-retry-time</command></term>
+              <listitem>
+                <para>
+                  These options control the server's behavior on refreshing a
+                  zone
+                  (querying for SOA changes) or retrying failed transfers.
+                  Usually the SOA values for the zone are used, but these
+                  values
+                  are set by the master, giving slave server administrators
+                  little
+                  control over their contents.
+                </para>
+                <para>
+                  These options allow the administrator to set a minimum and
+                  maximum
+                  refresh and retry time either per-zone, per-view, or
+                  globally.
+                  These options are valid for slave and stub zones,
+                  and clamp the SOA refresh and retry times to the specified
+                  values.
+                </para>
+              </listitem>
+            </varlistentry>
+
+            <varlistentry>
+              <term><command>edns-udp-size</command></term>
+              <listitem>
+                <para>
+		  Sets the advertised EDNS UDP buffer size in bytes.  Valid
+                  values are 512 to 4096 (values outside this range
+                  will be silently adjusted).  The default value is
+                  4096.  The usual reason for setting edns-udp-size to
+                  a non-default value is to get UDP answers to pass
+                  through broken firewalls that block fragmented
+                  packets and/or block UDP packets that are greater
+                  than 512 bytes.
+                </para>
+              </listitem>
+            </varlistentry>
+
+            <varlistentry>
+              <term><command>max-udp-size</command></term>
+              <listitem>
+                <para>
+		  Sets the maximum EDNS UDP message size named will
+		  send in bytes.  Valid values are 512 to 4096 (values outside
+		  this range will be silently adjusted).  The default
+		  value is 4096.  The usual reason for setting
+		  max-udp-size to a non-default value is to get UDP
+		  answers to pass through broken firewalls that
+		  block fragmented packets and/or block UDP packets
+		  that are greater than 512 bytes.
+		  This is independent of the advertised receive
+		  buffer (<command>edns-udp-size</command>).
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>masterfile-format</command></term>
+	      <listitem>
+	        <para>Specifies
+		  the file format of zone files (see
+	          <xref linkend="zonefile_format"/>).
+	          The default value is <constant>text</constant>, which is the
+		  standard textual representation.  Files in other formats
+		  than <constant>text</constant> are typically expected
+		  to be generated by the <command>named-compilezone</command> tool.
+		  Note that when a zone file in a different format than
+		  <constant>text</constant> is loaded, <command>named</command>
+	          may omit some of the checks which would be performed for a
+		  file in the <constant>text</constant> format.  In particular,
+		  <command>check-names</command> checks do not apply
+		  for the <constant>raw</constant> format.  This means
+		  a zone file in the <constant>raw</constant> format
+		  must be generated with the same check level as that
+		  specified in the <command>named</command> configuration
+		  file.  This statement sets the
+		  <command>masterfile-format</command> for all zones,
+		  but can be overridden on a per-zone or per-view basis
+		  by including a <command>masterfile-format</command>
+		  statement within the <command>zone</command> or
+		  <command>view</command> block in the configuration
+		  file.
+	        </para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>clients-per-query</command></term>
+	      <term><command>max-clients-per-query</command></term>
+              <listitem>
+		<para>These set the
+		  initial value (minimum) and maximum number of recursive
+		  simultanious clients for any given query
+		  (&lt;qname,qtype,qclass&gt;) that the server will accept
+		  before dropping additional clients.  named will attempt to
+		  self tune this value and changes will be logged.  The
+		  default values are 10 and 100.
+		</para>
+		<para>
+	          This value should reflect how many queries come in for
+		  a given name in the time it takes to resolve that name.
+		  If the number of queries exceed this value, named will
+		  assume that it is dealing with a non-responsive zone
+		  and will drop additional queries.  If it gets a response
+		  after dropping queries, it will raise the estimate.  The
+		  estimate will then be lowered in 20 minutes if it has
+		  remained unchanged.
+		</para>
+		<para>
+		  If <command>clients-per-query</command> is set to zero,
+		  then there is no limit on the number of clients per query
+		  and no queries will be dropped.
+		</para>
+		<para>
+		  If <command>max-clients-per-query</command> is set to zero,
+		  then there is no upper bound other than imposed by
+		  <command>recursive-clients</command>.
+		</para>
+              </listitem>
+	    </varlistentry>
+
+            <varlistentry>
+              <term><command>notify-delay</command></term>
+              <listitem>
+                <para>
+                  The delay, in seconds, between sending sets of notify
+                  messages for a zone.  The default is zero.
+                </para>
+              </listitem>
+            </varlistentry>
+	  </variablelist>
+
+        </sect3>
+
+        <sect3 id="builtin">
+          <title>Built-in server information zones</title>
+
+          <para>
+            The server provides some helpful diagnostic information
+            through a number of built-in zones under the
+            pseudo-top-level-domain <literal>bind</literal> in the
+            <command>CHAOS</command> class.  These zones are part
+            of a
+            built-in view (see <xref linkend="view_statement_grammar"/>) of
+            class
+            <command>CHAOS</command> which is separate from the
+            default view of
+            class <command>IN</command>; therefore, any global
+            server options
+            such as <command>allow-query</command> do not apply
+            the these zones.
+            If you feel the need to disable these zones, use the options
+            below, or hide the built-in <command>CHAOS</command>
+            view by
+            defining an explicit view of class <command>CHAOS</command>
+            that matches all clients.
+          </para>
+
+          <variablelist>
+
+            <varlistentry>
+              <term><command>version</command></term>
+              <listitem>
+                <para>
+                  The version the server should report
+                  via a query of the name <literal>version.bind</literal>
+                  with type <command>TXT</command>, class <command>CHAOS</command>.
+                  The default is the real version number of this server.
+                  Specifying <command>version none</command>
+                  disables processing of the queries.
+                </para>
+              </listitem>
+            </varlistentry>
+
+            <varlistentry>
+              <term><command>hostname</command></term>
+              <listitem>
+                <para>
+                  The hostname the server should report via a query of
+                  the name <filename>hostname.bind</filename>
+                  with type <command>TXT</command>, class <command>CHAOS</command>.
+                  This defaults to the hostname of the machine hosting the
+                  name server as
+                  found by the gethostname() function.  The primary purpose of such queries
+                  is to
+                  identify which of a group of anycast servers is actually
+                  answering your queries.  Specifying <command>hostname none;</command>
+                  disables processing of the queries.
+                </para>
+              </listitem>
+            </varlistentry>
+
+            <varlistentry>
+              <term><command>server-id</command></term>
+              <listitem>
+                <para>
+                  The ID of the server should report via a query of
+                  the name <filename>ID.SERVER</filename>
+                  with type <command>TXT</command>, class <command>CHAOS</command>.
+                  The primary purpose of such queries is to
+                  identify which of a group of anycast servers is actually
+                  answering your queries.  Specifying <command>server-id none;</command>
+                  disables processing of the queries.
+                  Specifying <command>server-id hostname;</command> will cause named to
+                  use the hostname as found by the gethostname() function.
+                  The default <command>server-id</command> is <command>none</command>.
+                </para>
+              </listitem>
+            </varlistentry>
+
+          </variablelist>
+
+        </sect3>
+
+        <sect3 id="empty">
+          <title>Built-in Empty Zones</title>
+	  <para>
+	    Named has some built-in empty zones (SOA and NS records only).
+	    These are for zones that should normally be answered locally
+	    and which queries should not be sent to the Internet's root
+	    servers.  The official servers which cover these namespaces
+	    return NXDOMAIN responses to these queries.  In particular,
+	    these cover the reverse namespace for addresses from RFC 1918 and
+	    RFC 3330.  They also include the reverse namespace for IPv6 local
+	    address (locally assigned), IPv6 link local addresses, the IPv6
+	    loopback address and the IPv6 unknown addresss.
+	  </para>
+	  <para>
+	    Named will attempt to determine if a built in zone already exists
+	    or is active (covered by a forward-only forwarding declaration)
+	    and will not not create a empty zone in that case.
+	  </para>
+	  <para>
+	    The current list of empty zones is:
+	    <itemizedlist>
+	      <listitem>10.IN-ADDR.ARPA</listitem>
+	      <listitem>127.IN-ADDR.ARPA</listitem>
+	      <listitem>254.169.IN-ADDR.ARPA</listitem>
+	      <listitem>16.172.IN-ADDR.ARPA</listitem>
+	      <listitem>17.172.IN-ADDR.ARPA</listitem>
+	      <listitem>18.172.IN-ADDR.ARPA</listitem>
+	      <listitem>19.172.IN-ADDR.ARPA</listitem>
+	      <listitem>20.172.IN-ADDR.ARPA</listitem>
+	      <listitem>21.172.IN-ADDR.ARPA</listitem>
+	      <listitem>22.172.IN-ADDR.ARPA</listitem>
+	      <listitem>23.172.IN-ADDR.ARPA</listitem>
+	      <listitem>24.172.IN-ADDR.ARPA</listitem>
+	      <listitem>25.172.IN-ADDR.ARPA</listitem>
+	      <listitem>26.172.IN-ADDR.ARPA</listitem>
+	      <listitem>27.172.IN-ADDR.ARPA</listitem>
+	      <listitem>28.172.IN-ADDR.ARPA</listitem>
+	      <listitem>29.172.IN-ADDR.ARPA</listitem>
+	      <listitem>30.172.IN-ADDR.ARPA</listitem>
+	      <listitem>31.172.IN-ADDR.ARPA</listitem>
+	      <listitem>168.192.IN-ADDR.ARPA</listitem>
+	      <listitem>2.0.192.IN-ADDR.ARPA</listitem>
+	      <listitem>0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA</listitem>
+	      <listitem>1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA</listitem>
+	      <listitem>D.F.IP6.ARPA</listitem>
+	      <listitem>8.E.F.IP6.ARPA</listitem>
+	      <listitem>9.E.F.IP6.ARPA</listitem>
+	      <listitem>A.E.F.IP6.ARPA</listitem>
+	      <listitem>B.E.F.IP6.ARPA</listitem>
+	    </itemizedlist>
+	  </para>
+	  <para>
+	    Empty zones are settable at the view level and only apply to
+	    views of class IN.  Disabled empty zones are only inherited
+	    from options if there are no disabled empty zones specified
+	    at the view level.  To override the options list of disabled
+	    zones, you can disable the root zone at the view level, for example:
+<programlisting>
+	    disable-empty-zone ".";
+</programlisting>
+	  </para>
+	  <para>
+	    If you are using the address ranges covered here, you should
+	    already have reverse zones covering the addresses you use.
+	    In practice this appears to not be the case with many queries
+	    being made to the infrastructure servers for names in these
+	    spaces.  So many in fact that sacrificial servers were needed
+	    to be deployed to channel the query load away from the
+	    infrastructure servers.
+	  </para>
+	  <note>
+	    The real parent servers for these zones should disable all
+	    empty zone under the parent zone they serve.  For the real
+	    root servers, this is all built in empty zones.  This will
+	    enable them to return referrals to deeper in the tree.
+	  </note>
+          <variablelist>
+	    <varlistentry>
+	      <term><command>empty-server</command></term>
+	      <listitem>
+	        <para>
+		  Specify what server name will appear in the returned
+		  SOA record for empty zones.  If none is specified, then
+		  the zone's name will be used.
+	        </para>
+	       </listitem>
+	    </varlistentry>
+	      
+	    <varlistentry>
+	      <term><command>empty-contact</command></term>
+	      <listitem>
+	        <para>
+		  Specify what contact name will appear in the returned
+		  SOA record for empty zones.  If none is specified, then
+		  "." will be used.
+	        </para>
+	      </listitem>
+	    </varlistentry>
+  
+	    <varlistentry>
+	      <term><command>empty-zones-enable</command></term>
+	      <listitem>
+	        <para>
+		  Enable or disable all empty zones.  By default they
+		  are enabled.
+	        </para>
+	      </listitem>
+	    </varlistentry>
+  
+	    <varlistentry>
+	    <term><command>disable-empty-zone</command></term>
+	      <listitem>
+	        <para>
+		  Disable individual empty zones.  By default none are
+		  disabled.  This option can be specified multiple times.
+	        </para>
+	      </listitem>
+	    </varlistentry>
+          </variablelist>
+        </sect3>
+  
+        <sect3 id="statsfile">
+          <title>The Statistics File</title>
+
+          <para>
+            The statistics file generated by <acronym>BIND</acronym> 9
+            is similar, but not identical, to that
+            generated by <acronym>BIND</acronym> 8.
+          </para>
+          <para>
+            The statistics dump begins with a line, like:
+	  </para>
+          <para>
+	    <command>+++ Statistics Dump +++ (973798949)</command>
+	  </para>
+	  <para>
+	    The number in parentheses is a standard
+            Unix-style timestamp, measured as seconds since January 1, 1970.
+            Following
+            that line are a series of lines containing a counter type, the
+            value of the
+            counter, optionally a zone name, and optionally a view name.
+            The lines without view and zone listed are global statistics for
+            the entire server.
+            Lines with a zone and view name for the given view and zone (the
+            view name is
+            omitted for the default view).
+	  </para>
+	  <para>
+	    The statistics dump ends with the line where the
+            number is identical to the number in the beginning line; for example:
+          </para>
+          <para>
+	    <command>--- Statistics Dump --- (973798949)</command>
+          </para>
+          <para>
+            The following statistics counters are maintained:
+          </para>
+          <informaltable colsep="0" rowsep="0">
+            <tgroup cols="2" colsep="0" rowsep="0" tgroupstyle="4Level-table">
+              <colspec colname="1" colnum="1" colsep="0" colwidth="1.150in"/>
+              <colspec colname="2" colnum="2" colsep="0" colwidth="3.350in"/>
+              <tbody>
+                <row rowsep="0">
+                  <entry colname="1">
+                    <para><command>success</command></para>
+                  </entry>
+                  <entry colname="2">
+                    <para>
+                      The number of
+                      successful queries made to the server or zone.  A
+                      successful query
+                      is defined as query which returns a NOERROR response
+                      with at least
+                      one answer RR.
+                    </para>
+                  </entry>
+                </row>
+                <row rowsep="0">
+                  <entry colname="1">
+                    <para><command>referral</command></para>
+                  </entry>
+                  <entry colname="2">
+                    <para>
+                      The number of queries which resulted
+                      in referral responses.
+                    </para>
+                  </entry>
+                </row>
+                <row rowsep="0">
+                  <entry colname="1">
+                    <para><command>nxrrset</command></para>
+                  </entry>
+                  <entry colname="2">
+                    <para>
+                      The number of queries which resulted in
+                      NOERROR responses with no data.
+                    </para>
+                  </entry>
+                </row>
+                <row rowsep="0">
+                  <entry colname="1">
+                    <para><command>nxdomain</command></para>
+                  </entry>
+                  <entry colname="2">
+                    <para>
+                      The number
+                      of queries which resulted in NXDOMAIN responses.
+                    </para>
+                  </entry>
+                </row>
+                <row rowsep="0">
+                  <entry colname="1">
+                    <para><command>failure</command></para>
+                  </entry>
+                  <entry colname="2">
+                    <para>
+                      The number of queries which resulted in a
+                      failure response other than those above.
+                    </para>
+                  </entry>
+                </row>
+                <row rowsep="0">
+                  <entry colname="1">
+                    <para><command>recursion</command></para>
+                  </entry>
+                  <entry colname="2">
+                    <para>
+                      The number of queries which caused the server
+                      to perform recursion in order to find the final answer.
+                    </para>
+                  </entry>
+                </row>
+                <row rowsep="0">
+                  <entry colname="1">
+                    <para><command>duplicate</command></para>
+                  </entry>
+                  <entry colname="2">
+                    <para>
+                      The number of queries which the server attempted to
+		      recurse but discover a existing query with the same
+		      IP address, port, query id, name, type and class
+		      already being processed.
+                    </para>
+                  </entry>
+                </row>
+                <row rowsep="0">
+                  <entry colname="1">
+                    <para><command>dropped</command></para>
+                  </entry>
+                  <entry colname="2">
+                    <para>
+		      The number of queries for which the server
+		      discovered a excessive number of existing
+		      recursive queries for the same name, type and
+		      class and were subsequently dropped.
+		    </para>
+		  </entry>
+		</row>
+              </tbody>
+            </tgroup>
+          </informaltable>
+
+          <para>
+            Each query received by the server will cause exactly one of
+            <command>success</command>,
+            <command>referral</command>,
+            <command>nxrrset</command>,
+            <command>nxdomain</command>, or
+            <command>failure</command>
+            to be incremented, and may additionally cause the
+            <command>recursion</command> counter to be
+            incremented.
+          </para>
+
+        </sect3>
+
+        <sect3 id="acache">
+          <title>Additional Section Caching</title>
+
+          <para>
+            The additional section cache, also called <command>acache</command>,
+            is an internal cache to improve the response performance of BIND 9.
+            When additional section caching is enabled, BIND 9 will
+            cache an internal short-cut to the additional section content for
+            each answer RR.
+            Note that <command>acache</command> is an internal caching
+            mechanism of BIND 9, and is not related to the DNS caching
+            server function.
+          </para>
+
+          <para>
+            Additional section caching does not change the
+            response content (except the RRsets ordering of the additional
+            section, see below), but can improve the response performance
+            significantly.
+            It is particularly effective when BIND 9 acts as an authoritative
+            server for a zone that has many delegations with many glue RRs.
+          </para>
+
+          <para>
+            In order to obtain the maximum performance improvement
+            from additional section caching, setting
+            <command>additional-from-cache</command>
+            to <command>no</command> is recommended, since the current
+            implementation of <command>acache</command>
+            does not short-cut of additional section information from the
+            DNS cache data.
+          </para>
+
+          <para>
+            One obvious disadvantage of <command>acache</command> is
+            that it requires much more
+            memory for the internal cached data.
+            Thus, if the response performance does not matter and memory
+            consumption is much more critical, the
+            <command>acache</command> mechanism can be
+            disabled by setting <command>acache-enable</command> to
+            <command>no</command>.
+            It is also possible to specify the upper limit of memory
+            consumption
+            for acache by using <command>max-acache-size</command>.
+          </para>
+
+          <para>
+            Additional section caching also has a minor effect on the
+            RRset ordering in the additional section.
+            Without <command>acache</command>,
+            <command>cyclic</command> order is effective for the additional
+            section as well as the answer and authority sections.
+            However, additional section caching fixes the ordering when it
+            first caches an RRset for the additional section, and the same
+            ordering will be kept in succeeding responses, regardless of the
+            setting of <command>rrset-order</command>.
+            The effect of this should be minor, however, since an
+            RRset in the additional section
+            typically only contains a small number of RRs (and in many cases
+            it only contains a single RR), in which case the
+            ordering does not matter much.
+          </para>
+
+          <para>
+            The following is a summary of options related to
+            <command>acache</command>.
+          </para>
+
+          <variablelist>
+
+            <varlistentry>
+              <term><command>acache-enable</command></term>
+              <listitem>
+                <para>
+                  If <command>yes</command>, additional section caching is
+		  enabled.  The default value is <command>no</command>.
+                </para>
+              </listitem>
+            </varlistentry>
+
+            <varlistentry>
+              <term><command>acache-cleaning-interval</command></term>
+              <listitem>
+                <para>
+                  The server will remove stale cache entries, based on an LRU
+                  based
+                  algorithm, every <command>acache-cleaning-interval</command> minutes.
+                  The default is 60 minutes.
+                  If set to 0, no periodic cleaning will occur.
+                </para>
+              </listitem>
+            </varlistentry>
+
+            <varlistentry>
+              <term><command>max-acache-size</command></term>
+              <listitem>
+                <para>
+                  The maximum amount of memory in bytes to use for the server's acache.
+                  When the amount of data in the acache reaches this limit,
+                  the server
+                  will clean more aggressively so that the limit is not
+                  exceeded.
+                  In a server with multiple views, the limit applies
+                  separately to the
+                  acache of each view.
+                  The default is <literal>unlimited</literal>,
+                  meaning that
+                  entries are purged from the acache only at the
+                  periodic cleaning time.
+                </para>
+              </listitem>
+            </varlistentry>
+
+          </variablelist>
+
+        </sect3>
+
+      </sect2>
+
+      <sect2 id="server_statement_grammar">
+        <title><command>server</command> Statement Grammar</title>
+
+<programlisting>server <replaceable>ip_addr[/prefixlen]</replaceable> {
+    <optional> bogus <replaceable>yes_or_no</replaceable> ; </optional>
+    <optional> provide-ixfr <replaceable>yes_or_no</replaceable> ; </optional>
+    <optional> request-ixfr <replaceable>yes_or_no</replaceable> ; </optional>
+    <optional> edns <replaceable>yes_or_no</replaceable> ; </optional>
+    <optional> edns-udp-size <replaceable>number</replaceable> ; </optional>
+    <optional> max-udp-size <replaceable>number</replaceable> ; </optional>
+    <optional> transfers <replaceable>number</replaceable> ; </optional>
+    <optional> transfer-format <replaceable>( one-answer | many-answers )</replaceable> ; ]</optional>
+    <optional> keys <replaceable>{ string ; <optional> string ; <optional>...</optional></optional> }</replaceable> ; </optional>
+    <optional> transfer-source (<replaceable>ip4_addr</replaceable> | <constant>*</constant>) <optional>port <replaceable>ip_port</replaceable></optional> ; </optional>
+    <optional> transfer-source-v6 (<replaceable>ip6_addr</replaceable> | <constant>*</constant>) <optional>port <replaceable>ip_port</replaceable></optional> ; </optional>
+    <optional> notify-source (<replaceable>ip4_addr</replaceable> | <constant>*</constant>) <optional>port <replaceable>ip_port</replaceable></optional> ; </optional>
+    <optional> notify-source-v6 (<replaceable>ip6_addr</replaceable> | <constant>*</constant>) <optional>port <replaceable>ip_port</replaceable></optional> ; </optional>
+    <optional> query-source <optional> address ( <replaceable>ip_addr</replaceable> | <replaceable>*</replaceable> ) </optional> <optional> port ( <replaceable>ip_port</replaceable> | <replaceable>*</replaceable> ) </optional>; </optional>
+    <optional> query-source-v6 <optional> address ( <replaceable>ip_addr</replaceable> | <replaceable>*</replaceable> ) </optional> <optional> port ( <replaceable>ip_port</replaceable> | <replaceable>*</replaceable> ) </optional>; </optional>
+};
+</programlisting>
+
+        </sect2>
+
+        <sect2 id="server_statement_definition_and_usage">
+          <title><command>server</command> Statement Definition and
+            Usage</title>
+
+          <para>
+            The <command>server</command> statement defines
+            characteristics
+            to be associated with a remote name server.  If a prefix length is
+            specified, then a range of servers is covered.  Only the most
+            specific
+            server clause applies regardless of the order in
+            <filename>named.conf</filename>.
+          </para>
+
+          <para>
+            The <command>server</command> statement can occur at
+            the top level of the
+            configuration file or inside a <command>view</command>
+            statement.
+            If a <command>view</command> statement contains
+            one or more <command>server</command> statements, only
+            those
+            apply to the view and any top-level ones are ignored.
+            If a view contains no <command>server</command>
+            statements,
+            any top-level <command>server</command> statements are
+            used as
+            defaults.
+          </para>
+
+          <para>
+            If you discover that a remote server is giving out bad data,
+            marking it as bogus will prevent further queries to it. The
+            default
+            value of <command>bogus</command> is <command>no</command>.
+          </para>
+          <para>
+            The <command>provide-ixfr</command> clause determines
+            whether
+            the local server, acting as master, will respond with an
+            incremental
+            zone transfer when the given remote server, a slave, requests it.
+            If set to <command>yes</command>, incremental transfer
+            will be provided
+            whenever possible. If set to <command>no</command>,
+            all transfers
+            to the remote server will be non-incremental. If not set, the
+            value
+            of the <command>provide-ixfr</command> option in the
+            view or
+            global options block is used as a default.
+          </para>
+
+          <para>
+            The <command>request-ixfr</command> clause determines
+            whether
+            the local server, acting as a slave, will request incremental zone
+            transfers from the given remote server, a master. If not set, the
+            value of the <command>request-ixfr</command> option in
+            the view or
+            global options block is used as a default.
+          </para>
+
+          <para>
+            IXFR requests to servers that do not support IXFR will
+            automatically
+            fall back to AXFR.  Therefore, there is no need to manually list
+            which servers support IXFR and which ones do not; the global
+            default
+            of <command>yes</command> should always work.
+            The purpose of the <command>provide-ixfr</command> and
+            <command>request-ixfr</command> clauses is
+            to make it possible to disable the use of IXFR even when both
+            master
+            and slave claim to support it, for example if one of the servers
+            is buggy and crashes or corrupts data when IXFR is used.
+          </para>
+
+          <para>
+            The <command>edns</command> clause determines whether
+            the local server will attempt to use EDNS when communicating
+	    with the remote server.  The default is <command>yes</command>.
+          </para>
+
+          <para>
+            The <command>edns-udp-size</command> option sets the EDNS UDP size
+	    that is advertised by named when querying the remote server.
+	    Valid values are 512 to 4096 bytes (values outside this range will be
+	    silently adjusted).  This option is useful when you wish to
+	    advertises a different value to this server than the value you
+	    advertise globally, for example, when there is a firewall at the
+	    remote site that is blocking large replies.
+          </para>
+
+          <para>
+	    The <command>max-udp-size</command> option sets the
+	    maximum EDNS UDP message size named will send.  Valid
+	    values are 512 to 4096 bytes (values outside this range will
+	    be silently adjusted).  This option is useful when you
+	    know that there is a firewall that is blocking large
+	    replies from named.
+	  </para>
+
+          <para>
+            The server supports two zone transfer methods. The first, <command>one-answer</command>,
+            uses one DNS message per resource record transferred. <command>many-answers</command> packs
+            as many resource records as possible into a message. <command>many-answers</command> is
+            more efficient, but is only known to be understood by <acronym>BIND</acronym> 9, <acronym>BIND</acronym>
+            8.x, and patched versions of <acronym>BIND</acronym>
+            4.9.5. You can specify which method
+            to use for a server with the <command>transfer-format</command> option.
+            If <command>transfer-format</command> is not
+            specified, the <command>transfer-format</command>
+            specified
+            by the <command>options</command> statement will be
+            used.
+          </para>
+
+          <para><command>transfers</command>
+	    is used to limit the number of concurrent inbound zone
+            transfers from the specified server. If no
+            <command>transfers</command> clause is specified, the
+            limit is set according to the
+            <command>transfers-per-ns</command> option.
+          </para>
+
+          <para>
+            The <command>keys</command> clause identifies a
+            <command>key_id</command> defined by the <command>key</command> statement,
+            to be used for transaction security (TSIG, <xref linkend="tsig"/>)
+            when talking to the remote server.
+            When a request is sent to the remote server, a request signature
+            will be generated using the key specified here and appended to the
+            message. A request originating from the remote server is not
+            required
+            to be signed by this key.
+          </para>
+
+          <para>
+            Although the grammar of the <command>keys</command>
+            clause
+            allows for multiple keys, only a single key per server is
+            currently
+            supported.
+          </para>
+
+          <para>
+            The <command>transfer-source</command> and
+            <command>transfer-source-v6</command> clauses specify
+            the IPv4 and IPv6 source
+            address to be used for zone transfer with the remote server,
+            respectively.
+            For an IPv4 remote server, only <command>transfer-source</command> can
+            be specified.
+            Similarly, for an IPv6 remote server, only
+            <command>transfer-source-v6</command> can be
+            specified.
+            For more details, see the description of
+            <command>transfer-source</command> and
+            <command>transfer-source-v6</command> in
+            <xref linkend="zone_transfers"/>.
+          </para>
+
+	  <para>
+	    The <command>notify-source</command> and
+	    <command>notify-source-v6</command> clauses specify the
+	    IPv4 and IPv6 source address to be used for notify
+	    messages sent to remote servers, respectively.  For an
+	    IPv4 remote server, only <command>notify-source</command>
+	    can be specified.  Similarly, for an IPv6 remote server,
+	    only <command>notify-source-v6</command> can be specified.
+	  </para>
+
+	  <para>
+	    The <command>query-source</command> and
+	    <command>query-source-v6</command> clauses specify the
+	    IPv4 and IPv6 source address to be used for queries
+	    sent to remote servers, respectively.  For an IPv4
+	    remote server, only <command>query-source</command> can
+	    be specified.  Similarly, for an IPv6 remote server,
+	    only <command>query-source-v6</command> can be specified.
+	  </para>
+
+        </sect2>
+
+        <sect2>
+          <title><command>trusted-keys</command> Statement Grammar</title>
+
+<programlisting>trusted-keys {
+    <replaceable>string</replaceable> <replaceable>number</replaceable> <replaceable>number</replaceable> <replaceable>number</replaceable> <replaceable>string</replaceable> ;
+    <optional> <replaceable>string</replaceable> <replaceable>number</replaceable> <replaceable>number</replaceable> <replaceable>number</replaceable> <replaceable>string</replaceable> ; <optional>...</optional></optional>
+};
+</programlisting>
+
+        </sect2>
+	<sect2>
+	  <title><command>trusted-keys</command> Statement Definition
+	    and Usage</title>
+	  <para>
+	    The <command>trusted-keys</command> statement defines
+	    DNSSEC security roots. DNSSEC is described in <xref
+	    linkend="DNSSEC"/>. A security root is defined when the
+	    public key for a non-authoritative zone is known, but
+	    cannot be securely obtained through DNS, either because
+	    it is the DNS root zone or because its parent zone is
+	    unsigned.  Once a key has been configured as a trusted
+	    key, it is treated as if it had been validated and
+	    proven secure. The resolver attempts DNSSEC validation
+	    on all DNS data in subdomains of a security root.
+	  </para>
+	  <para>
+	    All keys (and corresponding zones) listed in
+	    <command>trusted-keys</command> are deemed to exist regardless
+	    of what parent zones say.  Similarly for all keys listed in
+	    <command>trusted-keys</command> only those keys are
+	    used to validate the DNSKEY RRset.  The parent's DS RRset
+	    will not be used.
+	  </para>
+	  <para>
+	    The <command>trusted-keys</command> statement can contain
+	    multiple key entries, each consisting of the key's
+	    domain name, flags, protocol, algorithm, and the Base-64
+	    representation of the key data.
+	  </para>
+	</sect2>
+
+        <sect2 id="view_statement_grammar">
+          <title><command>view</command> Statement Grammar</title>
+
+<programlisting>view <replaceable>view_name</replaceable>
+      <optional><replaceable>class</replaceable></optional> {
+      match-clients { <replaceable>address_match_list</replaceable> };
+      match-destinations { <replaceable>address_match_list</replaceable> };
+      match-recursive-only <replaceable>yes_or_no</replaceable> ;
+      <optional> <replaceable>view_option</replaceable>; ...</optional>
+      <optional> <replaceable>zone_statement</replaceable>; ...</optional>
+};
+</programlisting>
+
+        </sect2>
+        <sect2>
+          <title><command>view</command> Statement Definition and Usage</title>
+
+          <para>
+            The <command>view</command> statement is a powerful
+            feature
+            of <acronym>BIND</acronym> 9 that lets a name server
+            answer a DNS query differently
+            depending on who is asking. It is particularly useful for
+            implementing
+            split DNS setups without having to run multiple servers.
+          </para>
+
+          <para>
+            Each <command>view</command> statement defines a view
+            of the
+            DNS namespace that will be seen by a subset of clients.  A client
+            matches
+            a view if its source IP address matches the
+            <varname>address_match_list</varname> of the view's
+            <command>match-clients</command> clause and its
+            destination IP address matches
+            the <varname>address_match_list</varname> of the
+            view's
+            <command>match-destinations</command> clause.  If not
+            specified, both
+            <command>match-clients</command> and <command>match-destinations</command>
+            default to matching all addresses.  In addition to checking IP
+            addresses
+            <command>match-clients</command> and <command>match-destinations</command>
+            can also take <command>keys</command> which provide an
+            mechanism for the
+            client to select the view.  A view can also be specified
+            as <command>match-recursive-only</command>, which
+            means that only recursive
+            requests from matching clients will match that view.
+            The order of the <command>view</command> statements is
+            significant &mdash;
+            a client request will be resolved in the context of the first
+            <command>view</command> that it matches.
+          </para>
+
+          <para>
+            Zones defined within a <command>view</command>
+            statement will
+            be only be accessible to clients that match the <command>view</command>.
+            By defining a zone of the same name in multiple views, different
+            zone data can be given to different clients, for example,
+            "internal"
+            and "external" clients in a split DNS setup.
+          </para>
+
+          <para>
+            Many of the options given in the <command>options</command> statement
+            can also be used within a <command>view</command>
+            statement, and then
+            apply only when resolving queries with that view.  When no
+            view-specific
+            value is given, the value in the <command>options</command> statement
+            is used as a default.  Also, zone options can have default values
+            specified
+            in the <command>view</command> statement; these
+            view-specific defaults
+            take precedence over those in the <command>options</command> statement.
+          </para>
+
+          <para>
+            Views are class specific.  If no class is given, class IN
+            is assumed.  Note that all non-IN views must contain a hint zone,
+            since only the IN class has compiled-in default hints.
+          </para>
+
+          <para>
+            If there are no <command>view</command> statements in
+            the config
+            file, a default view that matches any client is automatically
+            created
+            in class IN. Any <command>zone</command> statements
+            specified on
+            the top level of the configuration file are considered to be part
+            of
+            this default view, and the <command>options</command>
+            statement will
+            apply to the default view. If any explicit <command>view</command>
+            statements are present, all <command>zone</command>
+            statements must
+            occur inside <command>view</command> statements.
+          </para>
+
+          <para>
+            Here is an example of a typical split DNS setup implemented
+            using <command>view</command> statements:
+          </para>
+
+<programlisting>view "internal" {
+      // This should match our internal networks.
+      match-clients { 10.0.0.0/8; };
+
+      // Provide recursive service to internal clients only.
+      recursion yes;
+
+      // Provide a complete view of the example.com zone
+      // including addresses of internal hosts.
+      zone "example.com" {
+            type master;
+            file "example-internal.db";
+      };
+};
+
+view "external" {
+      // Match all clients not matched by the previous view.
+      match-clients { any; };
+
+      // Refuse recursive service to external clients.
+      recursion no;
+
+      // Provide a restricted view of the example.com zone
+      // containing only publicly accessible hosts.
+      zone "example.com" {
+           type master;
+           file "example-external.db";
+      };
+};
+</programlisting>
+
+        </sect2>
+        <sect2 id="zone_statement_grammar">
+          <title><command>zone</command>
+            Statement Grammar</title>
+
+<programlisting>zone <replaceable>zone_name</replaceable> <optional><replaceable>class</replaceable></optional> {
+    type master;
+    <optional> allow-query { <replaceable>address_match_list</replaceable> }; </optional>
+    <optional> allow-transfer { <replaceable>address_match_list</replaceable> }; </optional>
+    <optional> allow-update { <replaceable>address_match_list</replaceable> }; </optional>
+    <optional> update-policy { <replaceable>update_policy_rule</replaceable> <optional>...</optional> }; </optional>
+    <optional> also-notify { <replaceable>ip_addr</replaceable> <optional>port <replaceable>ip_port</replaceable></optional> ; <optional> <replaceable>ip_addr</replaceable> <optional>port <replaceable>ip_port</replaceable></optional> ; ... </optional> }; </optional>
+    <optional> check-names (<constant>warn</constant>|<constant>fail</constant>|<constant>ignore</constant>) ; </optional>
+    <optional> check-mx (<constant>warn</constant>|<constant>fail</constant>|<constant>ignore</constant>) ; </optional>
+    <optional> check-wildcard <replaceable>yes_or_no</replaceable>; </optional>
+    <optional> check-integrity <replaceable>yes_or_no</replaceable> ; </optional>
+    <optional> dialup <replaceable>dialup_option</replaceable> ; </optional>
+    <optional> file <replaceable>string</replaceable> ; </optional>
+    <optional> masterfile-format (<constant>text</constant>|<constant>raw</constant>) ; </optional>
+    <optional> journal <replaceable>string</replaceable> ; </optional>
+    <optional> forward (<constant>only</constant>|<constant>first</constant>) ; </optional>
+    <optional> forwarders { <optional> <replaceable>ip_addr</replaceable> <optional>port <replaceable>ip_port</replaceable></optional> ; ... </optional> }; </optional>
+    <optional> ixfr-base <replaceable>string</replaceable> ; </optional>
+    <optional> ixfr-tmp-file <replaceable>string</replaceable> ; </optional>
+    <optional> maintain-ixfr-base <replaceable>yes_or_no</replaceable> ; </optional>
+    <optional> max-ixfr-log-size <replaceable>number</replaceable> ; </optional>
+    <optional> max-transfer-idle-out <replaceable>number</replaceable> ; </optional>
+    <optional> max-transfer-time-out <replaceable>number</replaceable> ; </optional>
+    <optional> notify <replaceable>yes_or_no</replaceable> | <replaceable>explicit</replaceable> | <replaceable>master-only</replaceable> ; </optional>
+    <optional> notify-delay <replaceable>seconds</replaceable> ; </optional>
+    <optional> pubkey <replaceable>number</replaceable> <replaceable>number</replaceable> <replaceable>number</replaceable> <replaceable>string</replaceable> ; </optional>
+    <optional> notify-source (<replaceable>ip4_addr</replaceable> | <constant>*</constant>) <optional>port <replaceable>ip_port</replaceable></optional> ; </optional>
+    <optional> notify-source-v6 (<replaceable>ip6_addr</replaceable> | <constant>*</constant>) <optional>port <replaceable>ip_port</replaceable></optional> ; </optional>
+    <optional> zone-statistics <replaceable>yes_or_no</replaceable> ; </optional>
+    <optional> sig-validity-interval <replaceable>number</replaceable> ; </optional>
+    <optional> database <replaceable>string</replaceable> ; </optional>
+    <optional> min-refresh-time <replaceable>number</replaceable> ; </optional>
+    <optional> max-refresh-time <replaceable>number</replaceable> ; </optional>
+    <optional> min-retry-time <replaceable>number</replaceable> ; </optional>
+    <optional> max-retry-time <replaceable>number</replaceable> ; </optional>
+    <optional> key-directory <replaceable>path_name</replaceable>; </optional>
+    <optional> zero-no-soa-ttl <replaceable>yes_or_no</replaceable> ; </optional>
+};
+
+zone <replaceable>zone_name</replaceable> <optional><replaceable>class</replaceable></optional> {
+    type slave;
+    <optional> allow-notify { <replaceable>address_match_list</replaceable> }; </optional>
+    <optional> allow-query { <replaceable>address_match_list</replaceable> }; </optional>
+    <optional> allow-transfer { <replaceable>address_match_list</replaceable> }; </optional>
+    <optional> allow-update-forwarding { <replaceable>address_match_list</replaceable> }; </optional>
+    <optional> update-check-ksk <replaceable>yes_or_no</replaceable>; </optional>
+    <optional> also-notify { <replaceable>ip_addr</replaceable> <optional>port <replaceable>ip_port</replaceable></optional> ; <optional> <replaceable>ip_addr</replaceable> <optional>port <replaceable>ip_port</replaceable></optional> ; ... </optional> }; </optional>
+    <optional> check-names (<constant>warn</constant>|<constant>fail</constant>|<constant>ignore</constant>) ; </optional>
+    <optional> dialup <replaceable>dialup_option</replaceable> ; </optional>
+    <optional> file <replaceable>string</replaceable> ; </optional>
+    <optional> masterfile-format (<constant>text</constant>|<constant>raw</constant>) ; </optional>
+    <optional> journal <replaceable>string</replaceable> ; </optional>
+    <optional> forward (<constant>only</constant>|<constant>first</constant>) ; </optional>
+    <optional> forwarders { <optional> <replaceable>ip_addr</replaceable> <optional>port <replaceable>ip_port</replaceable></optional> ; ... </optional> }; </optional>
+    <optional> ixfr-base <replaceable>string</replaceable> ; </optional>
+    <optional> ixfr-tmp-file <replaceable>string</replaceable> ; </optional>
+    <optional> maintain-ixfr-base <replaceable>yes_or_no</replaceable> ; </optional>
+    <optional> masters <optional>port <replaceable>ip_port</replaceable></optional> { ( <replaceable>masters_list</replaceable> | <replaceable>ip_addr</replaceable> <optional>port <replaceable>ip_port</replaceable></optional> <optional>key <replaceable>key</replaceable></optional> ) ; <optional>...</optional> }; </optional>
+    <optional> max-ixfr-log-size <replaceable>number</replaceable> ; </optional>
+    <optional> max-transfer-idle-in <replaceable>number</replaceable> ; </optional>
+    <optional> max-transfer-idle-out <replaceable>number</replaceable> ; </optional>
+    <optional> max-transfer-time-in <replaceable>number</replaceable> ; </optional>
+    <optional> max-transfer-time-out <replaceable>number</replaceable> ; </optional>
+    <optional> notify <replaceable>yes_or_no</replaceable> | <replaceable>explicit</replaceable> | <replaceable>master-only</replaceable> ; </optional>
+    <optional> pubkey <replaceable>number</replaceable> <replaceable>number</replaceable> <replaceable>number</replaceable> <replaceable>string</replaceable> ; </optional>
+    <optional> transfer-source (<replaceable>ip4_addr</replaceable> | <constant>*</constant>) <optional>port <replaceable>ip_port</replaceable></optional> ; </optional>
+    <optional> transfer-source-v6 (<replaceable>ip6_addr</replaceable> | <constant>*</constant>) <optional>port <replaceable>ip_port</replaceable></optional> ; </optional>
+    <optional> alt-transfer-source (<replaceable>ip4_addr</replaceable> | <constant>*</constant>) <optional>port <replaceable>ip_port</replaceable></optional> ; </optional>
+    <optional> alt-transfer-source-v6 (<replaceable>ip6_addr</replaceable> | <constant>*</constant>) <optional>port <replaceable>ip_port</replaceable></optional> ; </optional>
+    <optional> use-alt-transfer-source <replaceable>yes_or_no</replaceable>; </optional>
+    <optional> notify-source (<replaceable>ip4_addr</replaceable> | <constant>*</constant>) <optional>port <replaceable>ip_port</replaceable></optional> ; </optional>
+    <optional> notify-source-v6 (<replaceable>ip6_addr</replaceable> | <constant>*</constant>) <optional>port <replaceable>ip_port</replaceable></optional> ; </optional>
+    <optional> zone-statistics <replaceable>yes_or_no</replaceable> ; </optional>
+    <optional> database <replaceable>string</replaceable> ; </optional>
+    <optional> min-refresh-time <replaceable>number</replaceable> ; </optional>
+    <optional> max-refresh-time <replaceable>number</replaceable> ; </optional>
+    <optional> min-retry-time <replaceable>number</replaceable> ; </optional>
+    <optional> max-retry-time <replaceable>number</replaceable> ; </optional>
+    <optional> multi-master <replaceable>yes_or_no</replaceable> ; </optional>
+    <optional> zero-no-soa-ttl <replaceable>yes_or_no</replaceable> ; </optional>
+};
+
+zone <replaceable>zone_name</replaceable> <optional><replaceable>class</replaceable></optional> {
+    type hint;
+    file <replaceable>string</replaceable> ;
+    <optional> delegation-only <replaceable>yes_or_no</replaceable> ; </optional>
+    <optional> check-names (<constant>warn</constant>|<constant>fail</constant>|<constant>ignore</constant>) ; // Not Implemented. </optional>
+};
+
+zone <replaceable>zone_name</replaceable> <optional><replaceable>class</replaceable></optional> {
+    type stub;
+    <optional> allow-query { <replaceable>address_match_list</replaceable> }; </optional>
+    <optional> check-names (<constant>warn</constant>|<constant>fail</constant>|<constant>ignore</constant>) ; </optional>
+    <optional> dialup <replaceable>dialup_option</replaceable> ; </optional>
+    <optional> delegation-only <replaceable>yes_or_no</replaceable> ; </optional>
+    <optional> file <replaceable>string</replaceable> ; </optional>
+    <optional> masterfile-format (<constant>text</constant>|<constant>raw</constant>) ; </optional>
+    <optional> forward (<constant>only</constant>|<constant>first</constant>) ; </optional>
+    <optional> forwarders { <optional> <replaceable>ip_addr</replaceable> <optional>port <replaceable>ip_port</replaceable></optional> ; ... </optional> }; </optional>
+    <optional> masters <optional>port <replaceable>ip_port</replaceable></optional> { ( <replaceable>masters_list</replaceable> | <replaceable>ip_addr</replaceable> <optional>port <replaceable>ip_port</replaceable></optional> <optional>key <replaceable>key</replaceable></optional> ) ; <optional>...</optional> }; </optional>
+    <optional> max-transfer-idle-in <replaceable>number</replaceable> ; </optional>
+    <optional> max-transfer-time-in <replaceable>number</replaceable> ; </optional>
+    <optional> pubkey <replaceable>number</replaceable> <replaceable>number</replaceable> <replaceable>number</replaceable> <replaceable>string</replaceable> ; </optional>
+    <optional> transfer-source (<replaceable>ip4_addr</replaceable> | <constant>*</constant>) <optional>port <replaceable>ip_port</replaceable></optional> ; </optional>
+    <optional> transfer-source-v6 (<replaceable>ip6_addr</replaceable> | <constant>*</constant>) <optional>port <replaceable>ip_port</replaceable></optional> ; </optional>
+    <optional> alt-transfer-source (<replaceable>ip4_addr</replaceable> | <constant>*</constant>) <optional>port <replaceable>ip_port</replaceable></optional> ; </optional>
+    <optional> alt-transfer-source-v6 (<replaceable>ip6_addr</replaceable> | <constant>*</constant>) <optional>port <replaceable>ip_port</replaceable></optional> ; </optional>
+    <optional> use-alt-transfer-source <replaceable>yes_or_no</replaceable>; </optional>
+    <optional> zone-statistics <replaceable>yes_or_no</replaceable> ; </optional>
+    <optional> database <replaceable>string</replaceable> ; </optional>
+    <optional> min-refresh-time <replaceable>number</replaceable> ; </optional>
+    <optional> max-refresh-time <replaceable>number</replaceable> ; </optional>
+    <optional> min-retry-time <replaceable>number</replaceable> ; </optional>
+    <optional> max-retry-time <replaceable>number</replaceable> ; </optional>
+    <optional> multi-master <replaceable>yes_or_no</replaceable> ; </optional>
+};
+
+zone <replaceable>zone_name</replaceable> <optional><replaceable>class</replaceable></optional> {
+    type forward;
+    <optional> forward (<constant>only</constant>|<constant>first</constant>) ; </optional>
+    <optional> forwarders { <optional> <replaceable>ip_addr</replaceable> <optional>port <replaceable>ip_port</replaceable></optional> ; ... </optional> }; </optional>
+    <optional> delegation-only <replaceable>yes_or_no</replaceable> ; </optional>
+};
+
+zone <replaceable>zone_name</replaceable> <optional><replaceable>class</replaceable></optional> {
+    type delegation-only;
+};
+
+</programlisting>
+
+        </sect2>
+        <sect2>
+          <title><command>zone</command> Statement Definition and Usage</title>
+          <sect3>
+            <title>Zone Types</title>
+            <informaltable colsep="0" rowsep="0">
+              <tgroup cols="2" colsep="0" rowsep="0" tgroupstyle="3Level-table">
+                <!--colspec colname="1" colnum="1" colsep="0" colwidth="1.108in"/-->
+                <!--colspec colname="2" colnum="2" colsep="0" colwidth="4.017in"/-->
+		<colspec colname="1" colnum="1" colsep="0"/>
+                <colspec colname="2" colnum="2" colsep="0" colwidth="4.017in"/>
+                <tbody>
+                  <row rowsep="0">
+                    <entry colname="1">
+                      <para>
+                        <varname>master</varname>
+                      </para>
+                    </entry>
+                    <entry colname="2">
+                      <para>
+                        The server has a master copy of the data
+                        for the zone and will be able to provide authoritative
+                        answers for
+                        it.
+                      </para>
+                    </entry>
+                  </row>
+                  <row rowsep="0">
+                    <entry colname="1">
+                      <para>
+                        <varname>slave</varname>
+                      </para>
+                    </entry>
+                    <entry colname="2">
+                      <para>
+                        A slave zone is a replica of a master
+                        zone. The <command>masters</command> list
+                        specifies one or more IP addresses
+                        of master servers that the slave contacts to update
+                        its copy of the zone.
+                        Masters list elements can also be names of other
+                        masters lists.
+                        By default, transfers are made from port 53 on the
+                        servers; this can
+                        be changed for all servers by specifying a port number
+                        before the
+                        list of IP addresses, or on a per-server basis after
+                        the IP address.
+                        Authentication to the master can also be done with
+                        per-server TSIG keys.
+                        If a file is specified, then the
+                        replica will be written to this file whenever the zone
+                        is changed,
+                        and reloaded from this file on a server restart. Use
+                        of a file is
+                        recommended, since it often speeds server startup and
+                        eliminates
+                        a needless waste of bandwidth. Note that for large
+                        numbers (in the
+                        tens or hundreds of thousands) of zones per server, it
+                        is best to
+                        use a two-level naming scheme for zone filenames. For
+                        example,
+                        a slave server for the zone <literal>example.com</literal> might place
+                        the zone contents into a file called
+                        <filename>ex/example.com</filename> where <filename>ex/</filename> is
+                        just the first two letters of the zone name. (Most
+                        operating systems
+                        behave very slowly if you put 100 000 files into
+                        a single directory.)
+                      </para>
+                    </entry>
+                  </row>
+                  <row rowsep="0">
+                    <entry colname="1">
+                      <para>
+                        <varname>stub</varname>
+                      </para>
+                    </entry>
+                    <entry colname="2">
+                      <para>
+                        A stub zone is similar to a slave zone,
+                        except that it replicates only the NS records of a
+                        master zone instead
+                        of the entire zone. Stub zones are not a standard part
+                        of the DNS;
+                        they are a feature specific to the <acronym>BIND</acronym> implementation.
+                      </para>
+
+                      <para>
+                        Stub zones can be used to eliminate the need for glue
+                        NS record
+                        in a parent zone at the expense of maintaining a stub
+                        zone entry and
+                        a set of name server addresses in <filename>named.conf</filename>.
+                        This usage is not recommended for new configurations,
+                        and BIND 9
+                        supports it only in a limited way.
+                        In <acronym>BIND</acronym> 4/8, zone
+                        transfers of a parent zone
+                        included the NS records from stub children of that
+                        zone. This meant
+                        that, in some cases, users could get away with
+                        configuring child stubs
+                        only in the master server for the parent zone. <acronym>BIND</acronym>
+                        9 never mixes together zone data from different zones
+                        in this
+                        way. Therefore, if a <acronym>BIND</acronym> 9 master serving a parent
+                        zone has child stub zones configured, all the slave
+                        servers for the
+                        parent zone also need to have the same child stub
+                        zones
+                        configured.
+                      </para>
+
+                      <para>
+                        Stub zones can also be used as a way of forcing the
+                        resolution
+                        of a given domain to use a particular set of
+                        authoritative servers.
+                        For example, the caching name servers on a private
+                        network using
+                        RFC1918 addressing may be configured with stub zones
+                        for
+                        <literal>10.in-addr.arpa</literal>
+                        to use a set of internal name servers as the
+                        authoritative
+                        servers for that domain.
+                      </para>
+                    </entry>
+                  </row>
+                  <row rowsep="0">
+                    <entry colname="1">
+                      <para>
+                        <varname>forward</varname>
+                      </para>
+                    </entry>
+                    <entry colname="2">
+                      <para>
+                        A "forward zone" is a way to configure
+                        forwarding on a per-domain basis.  A <command>zone</command> statement
+                        of type <command>forward</command> can
+                        contain a <command>forward</command>
+                        and/or <command>forwarders</command>
+                        statement,
+                        which will apply to queries within the domain given by
+                        the zone
+                        name. If no <command>forwarders</command>
+                        statement is present or
+                        an empty list for <command>forwarders</command> is given, then no
+                        forwarding will be done for the domain, canceling the
+                        effects of
+                        any forwarders in the <command>options</command> statement. Thus
+                        if you want to use this type of zone to change the
+                        behavior of the
+                        global <command>forward</command> option
+                        (that is, "forward first"
+                        to, then "forward only", or vice versa, but want to
+                        use the same
+                        servers as set globally) you need to re-specify the
+                        global forwarders.
+                      </para>
+                    </entry>
+                  </row>
+                  <row rowsep="0">
+                    <entry colname="1">
+                      <para>
+                        <varname>hint</varname>
+                      </para>
+                    </entry>
+                    <entry colname="2">
+                      <para>
+                        The initial set of root name servers is
+                        specified using a "hint zone". When the server starts
+                        up, it uses
+                        the root hints to find a root name server and get the
+                        most recent
+                        list of root name servers. If no hint zone is
+                        specified for class
+                        IN, the server uses a compiled-in default set of root
+                        servers hints.
+                        Classes other than IN have no built-in defaults hints.
+                      </para>
+                    </entry>
+                  </row>
+                  <row rowsep="0">
+                    <entry colname="1">
+                      <para>
+                        <varname>delegation-only</varname>
+                      </para>
+                    </entry>
+                    <entry colname="2">
+                      <para>
+                        This is used to enforce the delegation-only
+                        status of infrastructure zones (e.g. COM, NET, ORG).
+                        Any answer that
+                        is received without an explicit or implicit delegation
+                        in the authority
+                        section will be treated as NXDOMAIN.  This does not
+                        apply to the zone
+                        apex.  This should not be applied to leaf zones.
+                      </para>
+                      <para>
+                        <varname>delegation-only</varname> has no
+                        effect on answers received
+                        from forwarders.
+                      </para>
+                    </entry>
+                  </row>
+                </tbody>
+              </tgroup>
+            </informaltable>
+          </sect3>
+
+          <sect3>
+            <title>Class</title>
+            <para>
+              The zone's name may optionally be followed by a class. If
+              a class is not specified, class <literal>IN</literal> (for <varname>Internet</varname>),
+              is assumed. This is correct for the vast majority of cases.
+            </para>
+            <para>
+              The <literal>hesiod</literal> class is
+              named for an information service from MIT's Project Athena. It
+              is
+              used to share information about various systems databases, such
+              as users, groups, printers and so on. The keyword
+              <literal>HS</literal> is
+              a synonym for hesiod.
+            </para>
+            <para>
+              Another MIT development is Chaosnet, a LAN protocol created
+              in the mid-1970s. Zone data for it can be specified with the <literal>CHAOS</literal> class.
+            </para>
+          </sect3>
+          <sect3>
+
+            <title>Zone Options</title>
+
+            <variablelist>
+
+              <varlistentry>
+                <term><command>allow-notify</command></term>
+                <listitem>
+                  <para>
+                    See the description of
+                    <command>allow-notify</command> in <xref linkend="access_control"/>.
+                  </para>
+                </listitem>
+              </varlistentry>
+
+              <varlistentry>
+                <term><command>allow-query</command></term>
+                <listitem>
+                  <para>
+                    See the description of
+                    <command>allow-query</command> in <xref linkend="access_control"/>.
+                  </para>
+                </listitem>
+              </varlistentry>
+
+              <varlistentry>
+                <term><command>allow-transfer</command></term>
+                <listitem>
+                  <para>
+                    See the description of <command>allow-transfer</command>
+                    in <xref linkend="access_control"/>.
+                  </para>
+                </listitem>
+              </varlistentry>
+
+              <varlistentry>
+                <term><command>allow-update</command></term>
+                <listitem>
+                  <para>
+                    See the description of <command>allow-update</command>
+                    in <xref linkend="access_control"/>.
+                  </para>
+                </listitem>
+              </varlistentry>
+
+              <varlistentry>
+                <term><command>update-policy</command></term>
+                <listitem>
+                  <para>
+                    Specifies a "Simple Secure Update" policy. See
+                    <xref linkend="dynamic_update_policies"/>.
+                  </para>
+                </listitem>
+              </varlistentry>
+
+              <varlistentry>
+                <term><command>allow-update-forwarding</command></term>
+                <listitem>
+                  <para>
+                    See the description of <command>allow-update-forwarding</command>
+                    in <xref linkend="access_control"/>.
+                  </para>
+                </listitem>
+              </varlistentry>
+
+              <varlistentry>
+                <term><command>also-notify</command></term>
+                <listitem>
+                  <para>
+                    Only meaningful if <command>notify</command>
+                    is
+                    active for this zone. The set of machines that will
+                    receive a
+                    <literal>DNS NOTIFY</literal> message
+                    for this zone is made up of all the listed name servers
+                    (other than
+                    the primary master) for the zone plus any IP addresses
+                    specified
+                    with <command>also-notify</command>. A port
+                    may be specified
+                    with each <command>also-notify</command>
+                    address to send the notify
+                    messages to a port other than the default of 53.
+                    <command>also-notify</command> is not
+                    meaningful for stub zones.
+                    The default is the empty list.
+                  </para>
+                </listitem>
+              </varlistentry>
+
+              <varlistentry>
+                <term><command>check-names</command></term>
+                <listitem>
+                  <para>
+                    This option is used to restrict the character set and
+                    syntax of
+                    certain domain names in master files and/or DNS responses
+                    received from the
+                    network.  The default varies according to zone type.  For <command>master</command> zones the default is <command>fail</command>.  For <command>slave</command>
+                    zones the default is <command>warn</command>.
+                  </para>
+                </listitem>
+              </varlistentry>
+
+              <varlistentry>
+                <term><command>check-mx</command></term>
+                <listitem>
+                  <para>
+                    See the description of
+                    <command>check-mx</command> in <xref linkend="boolean_options"/>.
+                  </para>
+                </listitem>
+              </varlistentry>
+
+              <varlistentry>
+                <term><command>check-wildcard</command></term>
+                <listitem>
+                  <para>
+                    See the description of
+                    <command>check-wildcard</command> in <xref linkend="boolean_options"/>.
+                  </para>
+                </listitem>
+              </varlistentry>
+
+              <varlistentry>
+                <term><command>check-integrity</command></term>
+                <listitem>
+                  <para>
+                    See the description of
+                    <command>check-integrity</command> in <xref linkend="boolean_options"/>.
+                  </para>
+                </listitem>
+              </varlistentry>
+
+              <varlistentry>
+                <term><command>check-sibling</command></term>
+                <listitem>
+                  <para>
+                    See the description of
+                    <command>check-sibling</command> in <xref linkend="boolean_options"/>.
+                  </para>
+                </listitem>
+              </varlistentry>
+
+              <varlistentry>
+                <term><command>zero-no-soa-ttl</command></term>
+                <listitem>
+                  <para>
+                    See the description of
+                    <command>zero-no-soa-ttl</command> in <xref linkend="boolean_options"/>.
+                  </para>
+                </listitem>
+              </varlistentry>
+
+	      <varlistentry>
+	        <term><command>update-check-ksk</command></term>
+                <listitem>
+                  <para>
+                    See the description of
+                    <command>update-check-ksk</command> in <xref linkend="boolean_options"/>.
+                  </para>
+                </listitem>
+              </varlistentry>
+
+              <varlistentry>
+                <term><command>database</command></term>
+                <listitem>
+                  <para>
+                    Specify the type of database to be used for storing the
+                    zone data.  The string following the <command>database</command> keyword
+                    is interpreted as a list of whitespace-delimited words.
+                    The first word
+                    identifies the database type, and any subsequent words are
+                    passed
+                    as arguments to the database to be interpreted in a way
+                    specific
+                    to the database type.
+                  </para>
+                  <para>
+                    The default is <userinput>"rbt"</userinput>, BIND 9's
+                    native in-memory
+                    red-black-tree database.  This database does not take
+                    arguments.
+                  </para>
+                  <para>
+                    Other values are possible if additional database drivers
+                    have been linked into the server.  Some sample drivers are
+                    included
+                    with the distribution but none are linked in by default.
+                  </para>
+                </listitem>
+              </varlistentry>
+
+              <varlistentry>
+                <term><command>dialup</command></term>
+                <listitem>
+                  <para>
+                    See the description of
+                    <command>dialup</command> in <xref linkend="boolean_options"/>.
+                  </para>
+                </listitem>
+              </varlistentry>
+
+              <varlistentry>
+                <term><command>delegation-only</command></term>
+                <listitem>
+                  <para>
+                    The flag only applies to hint and stub zones.  If set
+                    to <userinput>yes</userinput>, then the zone will also be
+                    treated as if it
+                    is also a delegation-only type zone.
+                  </para>
+                </listitem>
+              </varlistentry>
+
+              <varlistentry>
+                <term><command>forward</command></term>
+                <listitem>
+                  <para>
+                    Only meaningful if the zone has a forwarders
+                    list. The <command>only</command> value causes
+                    the lookup to fail
+                    after trying the forwarders and getting no answer, while <command>first</command> would
+                    allow a normal lookup to be tried.
+                  </para>
+                </listitem>
+              </varlistentry>
+
+              <varlistentry>
+                <term><command>forwarders</command></term>
+                <listitem>
+                  <para>
+                    Used to override the list of global forwarders.
+                    If it is not specified in a zone of type <command>forward</command>,
+                    no forwarding is done for the zone and the global options are
+                    not used.
+                  </para>
+                </listitem>
+              </varlistentry>
+
+              <varlistentry>
+                <term><command>ixfr-base</command></term>
+                <listitem>
+                  <para>
+                    Was used in <acronym>BIND</acronym> 8 to
+                    specify the name
+                    of the transaction log (journal) file for dynamic update
+                    and IXFR.
+                    <acronym>BIND</acronym> 9 ignores the option
+                    and constructs the name of the journal
+                    file by appending "<filename>.jnl</filename>"
+                    to the name of the
+                    zone file.
+                  </para>
+                </listitem>
+              </varlistentry>
+
+              <varlistentry>
+                <term><command>ixfr-tmp-file</command></term>
+                <listitem>
+                  <para>
+                    Was an undocumented option in <acronym>BIND</acronym> 8.
+                    Ignored in <acronym>BIND</acronym> 9.
+                  </para>
+                </listitem>
+              </varlistentry>
+
+              <varlistentry>
+                <term><command>journal</command></term>
+                <listitem>
+                  <para>
+                    Allow the default journal's filename to be overridden.
+                    The default is the zone's filename with "<filename>.jnl</filename>" appended.
+                    This is applicable to <command>master</command> and <command>slave</command> zones.
+                  </para>
+                </listitem>
+              </varlistentry>
+
+              <varlistentry>
+                <term><command>max-transfer-time-in</command></term>
+                <listitem>
+                  <para>
+                    See the description of
+                    <command>max-transfer-time-in</command> in <xref linkend="zone_transfers"/>.
+                  </para>
+                </listitem>
+              </varlistentry>
+
+              <varlistentry>
+                <term><command>max-transfer-idle-in</command></term>
+                <listitem>
+                  <para>
+                    See the description of
+                    <command>max-transfer-idle-in</command> in <xref linkend="zone_transfers"/>.
+                  </para>
+                </listitem>
+              </varlistentry>
+
+              <varlistentry>
+                <term><command>max-transfer-time-out</command></term>
+                <listitem>
+                  <para>
+                    See the description of
+                    <command>max-transfer-time-out</command> in <xref linkend="zone_transfers"/>.
+                  </para>
+                </listitem>
+              </varlistentry>
+
+              <varlistentry>
+                <term><command>max-transfer-idle-out</command></term>
+                <listitem>
+                  <para>
+                    See the description of
+                    <command>max-transfer-idle-out</command> in <xref linkend="zone_transfers"/>.
+                  </para>
+                </listitem>
+              </varlistentry>
+
+              <varlistentry>
+                <term><command>notify</command></term>
+                <listitem>
+                  <para>
+                    See the description of
+                    <command>notify</command> in <xref linkend="boolean_options"/>.
+                  </para>
+                </listitem>
+              </varlistentry>
+
+              <varlistentry>
+                <term><command>notify-delay</command></term>
+                <listitem>
+                  <para>
+                    See the description of
+                    <command>notify-delay</command> in <xref linkend="tuning"/>.
+                  </para>
+                </listitem>
+              </varlistentry>
+
+              <varlistentry>
+                <term><command>pubkey</command></term>
+                <listitem>
+                  <para>
+                    In <acronym>BIND</acronym> 8, this option was
+                    intended for specifying
+                    a public zone key for verification of signatures in DNSSEC
+                    signed
+                    zones when they are loaded from disk. <acronym>BIND</acronym> 9 does not verify signatures
+                    on load and ignores the option.
+                  </para>
+                </listitem>
+              </varlistentry>
+
+              <varlistentry>
+                <term><command>zone-statistics</command></term>
+                <listitem>
+                  <para>
+                    If <userinput>yes</userinput>, the server will keep
+                    statistical
+                    information for this zone, which can be dumped to the
+                    <command>statistics-file</command> defined in
+                    the server options.
+                  </para>
+                </listitem>
+              </varlistentry>
+
+              <varlistentry>
+                <term><command>sig-validity-interval</command></term>
+                <listitem>
+                  <para>
+                    See the description of
+                    <command>sig-validity-interval</command> in <xref linkend="tuning"/>.
+                  </para>
+                </listitem>
+              </varlistentry>
+
+              <varlistentry>
+                <term><command>transfer-source</command></term>
+                <listitem>
+                  <para>
+                    See the description of
+                    <command>transfer-source</command> in <xref linkend="zone_transfers"/>.
+                  </para>
+                </listitem>
+              </varlistentry>
+
+              <varlistentry>
+                <term><command>transfer-source-v6</command></term>
+                <listitem>
+                  <para>
+                    See the description of
+                    <command>transfer-source-v6</command> in <xref linkend="zone_transfers"/>.
+                  </para>
+                </listitem>
+              </varlistentry>
+
+              <varlistentry>
+                <term><command>alt-transfer-source</command></term>
+                <listitem>
+                  <para>
+                    See the description of
+                    <command>alt-transfer-source</command> in <xref linkend="zone_transfers"/>.
+                  </para>
+                </listitem>
+              </varlistentry>
+
+              <varlistentry>
+                <term><command>alt-transfer-source-v6</command></term>
+                <listitem>
+                  <para>
+                    See the description of
+                    <command>alt-transfer-source-v6</command> in <xref linkend="zone_transfers"/>.
+                  </para>
+                </listitem>
+              </varlistentry>
+
+              <varlistentry>
+                <term><command>use-alt-transfer-source</command></term>
+                <listitem>
+                  <para>
+                    See the description of
+                    <command>use-alt-transfer-source</command> in <xref linkend="zone_transfers"/>.
+                  </para>
+                </listitem>
+              </varlistentry>
+
+
+              <varlistentry>
+                <term><command>notify-source</command></term>
+                <listitem>
+                  <para>
+                    See the description of
+                    <command>notify-source</command> in <xref linkend="zone_transfers"/>.
+                  </para>
+                </listitem>
+              </varlistentry>
+
+              <varlistentry>
+                <term><command>notify-source-v6</command></term>
+                <listitem>
+                  <para>
+                    See the description of
+                    <command>notify-source-v6</command> in <xref linkend="zone_transfers"/>.
+                  </para>
+                </listitem>
+              </varlistentry>
+
+              <varlistentry>
+                <term><command>min-refresh-time</command></term>
+                <term><command>max-refresh-time</command></term>
+                <term><command>min-retry-time</command></term>
+                <term><command>max-retry-time</command></term>
+                <listitem>
+                  <para>
+                    See the description in <xref linkend="tuning"/>.
+                  </para>
+                </listitem>
+              </varlistentry>
+
+              <varlistentry>
+                <term><command>ixfr-from-differences</command></term>
+                <listitem>
+                  <para>
+                    See the description of
+                    <command>ixfr-from-differences</command> in <xref linkend="boolean_options"/>.
+                  </para>
+                </listitem>
+              </varlistentry>
+
+              <varlistentry>
+                <term><command>key-directory</command></term>
+                <listitem>
+                  <para>
+                    See the description of
+                    <command>key-directory</command> in <xref linkend="options"/>.
+                  </para>
+                </listitem>
+              </varlistentry>
+
+              <varlistentry>
+                <term><command>multi-master</command></term>
+                <listitem>
+                  <para>
+                    See the description of <command>multi-master</command> in
+		    <xref linkend="boolean_options"/>.
+                  </para>
+                </listitem>
+              </varlistentry>
+	
+	      <varlistentry>
+		<term><command>masterfile-format</command></term>
+		<listitem>
+		  <para>
+		    See the description of <command>masterfile-format</command>
+		    in <xref linkend="tuning"/>.
+		  </para>
+		</listitem>
+	      </varlistentry>
+
+            </variablelist>
+
+          </sect3>
+          <sect3 id="dynamic_update_policies">
+            <title>Dynamic Update Policies</title>
+            <para>
+              <acronym>BIND</acronym> 9 supports two alternative
+              methods of granting clients
+              the right to perform dynamic updates to a zone,
+              configured by the <command>allow-update</command>
+              and
+              <command>update-policy</command> option,
+              respectively.
+            </para>
+            <para>
+              The <command>allow-update</command> clause works the
+              same
+              way as in previous versions of <acronym>BIND</acronym>. It grants given clients the
+              permission to update any record of any name in the zone.
+            </para>
+            <para>
+              The <command>update-policy</command> clause is new
+              in <acronym>BIND</acronym>
+              9 and allows more fine-grained control over what updates are
+              allowed.
+              A set of rules is specified, where each rule either grants or
+              denies
+              permissions for one or more names to be updated by one or more
+              identities.
+              If the dynamic update request message is signed (that is, it
+              includes
+              either a TSIG or SIG(0) record), the identity of the signer can
+              be determined.
+            </para>
+            <para>
+              Rules are specified in the <command>update-policy</command> zone
+              option, and are only meaningful for master zones.  When the <command>update-policy</command> statement
+              is present, it is a configuration error for the <command>allow-update</command> statement
+              to be present.  The <command>update-policy</command>
+              statement only
+              examines the signer of a message; the source address is not
+              relevant.
+            </para>
+            <para>
+              This is how a rule definition looks:
+            </para>
+
+<programlisting>
+( <command>grant</command> | <command>deny</command> ) <replaceable>identity</replaceable> <replaceable>nametype</replaceable> <replaceable>name</replaceable> <optional> <replaceable>types</replaceable> </optional>
+</programlisting>
+
+            <para>
+              Each rule grants or denies privileges.  Once a message has
+              successfully matched a rule, the operation is immediately
+              granted
+              or denied and no further rules are examined.  A rule is matched
+              when the signer matches the identity field, the name matches the
+              name field in accordance with the nametype field, and the type
+              matches
+              the types specified in the type field.
+            </para>
+
+            <para>
+              The identity field specifies a name or a wildcard name.
+              Normally, this
+              is the name of the TSIG or SIG(0) key used to sign the update
+              request.  When a
+              TKEY exchange has been used to create a shared secret, the
+              identity of the
+              shared secret is the same as the identity of the key used to
+              authenticate the
+              TKEY exchange.  When the <replaceable>identity</replaceable> field specifies a
+              wildcard name, it is subject to DNS wildcard expansion, so the
+              rule will apply
+              to multiple identities.  The <replaceable>identity</replaceable> field must
+              contain a fully-qualified domain name.
+            </para>
+
+            <para>
+              The <replaceable>nametype</replaceable> field has 6
+              values:
+              <varname>name</varname>, <varname>subdomain</varname>,
+              <varname>wildcard</varname>, <varname>self</varname>,
+	       <varname>selfsub</varname>, and <varname>selfwild</varname>.
+            </para>
+            <informaltable>
+              <tgroup cols="2" colsep="0" rowsep="0" tgroupstyle="4Level-table">
+                <colspec colname="1" colnum="1" colsep="0" colwidth="0.819in"/>
+                <colspec colname="2" colnum="2" colsep="0" colwidth="3.681in"/>
+                <tbody>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para>
+			<varname>name</varname>
+		      </para>
+		    </entry> <entry colname="2">
+		      <para>
+			Exact-match semantics.  This rule matches
+			when the name being updated is identical
+			to the contents of the
+			<replaceable>name</replaceable> field.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para>
+			<varname>subdomain</varname>
+		      </para>
+		    </entry> <entry colname="2">
+		      <para>
+			This rule matches when the name being updated
+			is a subdomain of, or identical to, the
+			contents of the <replaceable>name</replaceable>
+			field.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para>
+			<varname>wildcard</varname>
+		      </para>
+		    </entry> <entry colname="2">
+		      <para>
+			The <replaceable>name</replaceable> field
+			is subject to DNS wildcard expansion, and
+			this rule matches when the name being updated
+			name is a valid expansion of the wildcard.
+		      </para>
+		    </entry>
+		  </row>
+                  <row rowsep="0">
+                    <entry colname="1">
+                      <para>
+                        <varname>self</varname>
+                      </para>
+                    </entry>
+                    <entry colname="2">
+		      <para>
+			This rule matches when the name being updated
+			matches the contents of the
+			<replaceable>identity</replaceable> field.
+			The <replaceable>name</replaceable> field
+			is ignored, but should be the same as the
+			<replaceable>identity</replaceable> field.
+			The <varname>self</varname> nametype is
+			most useful when allowing using one key per
+			name to update, where the key has the same
+			name as the name to be updated.  The
+			<replaceable>identity</replaceable> would
+			be specified as <constant>*</constant> (an asterisk) in
+			this case.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para>
+			<varname>selfsub</varname>
+		      </para>
+		    </entry> <entry colname="2">
+		      <para>
+			This rule is similar to <varname>self</varname>
+			except that subdomains of <varname>self</varname>
+			can also be updated.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para>
+			<varname>selfwild</varname>
+		      </para>
+		    </entry> <entry colname="2">
+		      <para>
+			This rule is similar to <varname>self</varname>
+			except that only subdomains of
+			<varname>self</varname> can be updated.
+		      </para>
+		    </entry>
+		  </row>
+                </tbody>
+              </tgroup>
+            </informaltable>
+
+            <para>
+              In all cases, the <replaceable>name</replaceable>
+              field must
+              specify a fully-qualified domain name.
+            </para>
+
+            <para>
+              If no types are explicitly specified, this rule matches all
+              types except
+              RRSIG, NS, SOA, and NSEC. Types may be specified by name, including
+              "ANY" (ANY matches all types except NSEC, which can never be
+              updated).
+              Note that when an attempt is made to delete all records
+              associated with a
+              name, the rules are checked for each existing record type.
+            </para>
+          </sect3>
+        </sect2>
+      </sect1>
+      <sect1>
+        <title>Zone File</title>
+        <sect2 id="types_of_resource_records_and_when_to_use_them">
+          <title>Types of Resource Records and When to Use Them</title>
+          <para>
+            This section, largely borrowed from RFC 1034, describes the
+            concept of a Resource Record (RR) and explains when each is used.
+            Since the publication of RFC 1034, several new RRs have been
+            identified
+            and implemented in the DNS. These are also included.
+          </para>
+          <sect3>
+            <title>Resource Records</title>
+
+            <para>
+              A domain name identifies a node.  Each node has a set of
+              resource information, which may be empty.  The set of resource
+              information associated with a particular name is composed of
+              separate RRs. The order of RRs in a set is not significant and
+              need not be preserved by name servers, resolvers, or other
+              parts of the DNS. However, sorting of multiple RRs is
+              permitted for optimization purposes, for example, to specify
+              that a particular nearby server be tried first. See <xref linkend="the_sortlist_statement"/> and <xref linkend="rrset_ordering"/>.
+            </para>
+
+            <para>
+              The components of a Resource Record are:
+            </para>
+            <informaltable colsep="0" rowsep="0">
+              <tgroup cols="2" colsep="0" rowsep="0" tgroupstyle="4Level-table">
+                <colspec colname="1" colnum="1" colsep="0" colwidth="1.000in"/>
+                <colspec colname="2" colnum="2" colsep="0" colwidth="3.500in"/>
+                <tbody>
+                  <row rowsep="0">
+                    <entry colname="1">
+                      <para>
+                        owner name
+                      </para>
+                    </entry>
+                    <entry colname="2">
+                      <para>
+                        The domain name where the RR is found.
+                      </para>
+                    </entry>
+                  </row>
+                  <row rowsep="0">
+                    <entry colname="1">
+                      <para>
+                        type
+                      </para>
+                    </entry>
+                    <entry colname="2">
+                      <para>
+                        An encoded 16-bit value that specifies
+                        the type of the resource record.
+                      </para>
+                    </entry>
+                  </row>
+                  <row rowsep="0">
+                    <entry colname="1">
+                      <para>
+                        TTL
+                      </para>
+                    </entry>
+                    <entry colname="2">
+                      <para>
+                        The time-to-live of the RR. This field
+                        is a 32-bit integer in units of seconds, and is
+                        primarily used by
+                        resolvers when they cache RRs. The TTL describes how
+                        long a RR can
+                        be cached before it should be discarded.
+                      </para>
+                    </entry>
+                  </row>
+                  <row rowsep="0">
+                    <entry colname="1">
+                      <para>
+                        class
+                      </para>
+                    </entry>
+                    <entry colname="2">
+                      <para>
+                        An encoded 16-bit value that identifies
+                        a protocol family or instance of a protocol.
+                      </para>
+                    </entry>
+                  </row>
+                  <row rowsep="0">
+                    <entry colname="1">
+                      <para>
+                        RDATA
+                      </para>
+                    </entry>
+                    <entry colname="2">
+                      <para>
+                        The resource data.  The format of the
+                        data is type (and sometimes class) specific.
+                      </para>
+                    </entry>
+                  </row>
+                </tbody>
+              </tgroup>
+            </informaltable>
+            <para>
+              The following are <emphasis>types</emphasis> of valid RRs:
+            </para>
+            <informaltable colsep="0" rowsep="0">
+              <tgroup cols="2" colsep="0" rowsep="0" tgroupstyle="4Level-table">
+                <colspec colname="1" colnum="1" colsep="0" colwidth="0.875in"/>
+                <colspec colname="2" colnum="2" colsep="0" colwidth="3.625in"/>
+                <tbody>
+                  <row rowsep="0">
+                    <entry colname="1">
+                      <para>
+                        A
+                      </para>
+                    </entry>
+                    <entry colname="2">
+                      <para>
+                        A host address.  In the IN class, this is a
+                        32-bit IP address.  Described in RFC 1035.
+                      </para>
+                    </entry>
+                  </row>
+                  <row rowsep="0">
+                    <entry colname="1">
+                      <para>
+                        AAAA
+                      </para>
+                    </entry>
+                    <entry colname="2">
+                      <para>
+                        IPv6 address.  Described in RFC 1886.
+                      </para>
+                    </entry>
+                  </row>
+                  <row rowsep="0">
+                    <entry colname="1">
+                      <para>
+                        A6
+                      </para>
+                    </entry>
+                    <entry colname="2">
+                      <para>
+                        IPv6 address.  This can be a partial
+                        address (a suffix) and an indirection to the name
+                        where the rest of the
+                        address (the prefix) can be found.  Experimental.
+                        Described in RFC 2874.
+                      </para>
+                    </entry>
+                  </row>
+                  <row rowsep="0">
+                    <entry colname="1">
+                      <para>
+                        AFSDB
+                      </para>
+                    </entry>
+                    <entry colname="2">
+                      <para>
+                        Location of AFS database servers.
+                        Experimental.  Described in RFC 1183.
+                      </para>
+                    </entry>
+                  </row>
+                  <row rowsep="0">
+                    <entry colname="1">
+                      <para>
+                        APL
+                      </para>
+                    </entry>
+                    <entry colname="2">
+                      <para>
+                        Address prefix list.  Experimental.
+                        Described in RFC 3123.
+                      </para>
+                    </entry>
+                  </row>
+                  <row rowsep="0">
+                    <entry colname="1">
+                      <para>
+                        CERT
+                      </para>
+                    </entry>
+                    <entry colname="2">
+                      <para>
+                        Holds a digital certificate.
+                        Described in RFC 2538.
+                      </para>
+                    </entry>
+                  </row>
+                  <row rowsep="0">
+                    <entry colname="1">
+                      <para>
+                        CNAME
+                      </para>
+                    </entry>
+                    <entry colname="2">
+                      <para>
+                        Identifies the canonical name of an alias.
+                        Described in RFC 1035.
+                      </para>
+                    </entry>
+                  </row>
+                  <row rowsep="0">
+                    <entry colname="1">
+                      <para>
+                        DNAME
+                      </para>
+                    </entry>
+                    <entry colname="2">
+                      <para>
+                        Replaces the domain name specified with
+                        another name to be looked up, effectively aliasing an
+                        entire
+                        subtree of the domain name space rather than a single
+                        record
+                        as in the case of the CNAME RR.
+                        Described in RFC 2672.
+                      </para>
+                    </entry>
+                  </row>
+                  <row rowsep="0">
+                    <entry colname="1">
+                      <para>
+                        DNSKEY
+                      </para>
+                    </entry>
+                    <entry colname="2">
+                      <para>
+                        Stores a public key associated with a signed
+                        DNS zone.  Described in RFC 4034.
+                      </para>
+                    </entry>
+                  </row>
+                  <row rowsep="0">
+                    <entry colname="1">
+                      <para>
+                        DS
+                      </para>
+                    </entry>
+                    <entry colname="2">
+                      <para>
+                        Stores the hash of a public key associated with a
+                        signed DNS zone.  Described in RFC 4034.
+                      </para>
+                    </entry>
+                  </row>
+                  <row rowsep="0">
+                    <entry colname="1">
+                      <para>
+                        GPOS
+                      </para>
+                    </entry>
+                    <entry colname="2">
+                      <para>
+                        Specifies the global position.  Superseded by LOC.
+                      </para>
+                    </entry>
+                  </row>
+                  <row rowsep="0">
+                    <entry colname="1">
+                      <para>
+                        HINFO
+                      </para>
+                    </entry>
+                    <entry colname="2">
+                      <para>
+                        Identifies the CPU and OS used by a host.
+                        Described in RFC 1035.
+                      </para>
+                    </entry>
+                  </row>
+                  <row rowsep="0">
+                    <entry colname="1">
+                      <para>
+                        ISDN
+                      </para>
+                    </entry>
+                    <entry colname="2">
+                      <para>
+                        Representation of ISDN addresses.
+                        Experimental.  Described in RFC 1183.
+                      </para>
+                    </entry>
+                  </row>
+                  <row rowsep="0">
+                    <entry colname="1">
+                      <para>
+                        KEY
+                      </para>
+                    </entry>
+                    <entry colname="2">
+                      <para>
+                        Stores a public key associated with a
+                        DNS name.  Used in original DNSSEC; replaced
+			by DNSKEY in DNSSECbis, but still used with
+			SIG(0).  Described in RFCs 2535 and 2931.
+                      </para>
+                    </entry>
+                  </row>
+                  <row rowsep="0">
+                    <entry colname="1">
+                      <para>
+                        KX
+                      </para>
+                    </entry>
+                    <entry colname="2">
+                      <para>
+                        Identifies a key exchanger for this
+                        DNS name.  Described in RFC 2230.
+                      </para>
+                    </entry>
+                  </row>
+                  <row rowsep="0">
+                    <entry colname="1">
+                      <para>
+                        LOC
+                      </para>
+                    </entry>
+                    <entry colname="2">
+                      <para>
+                        For storing GPS info.  Described in RFC 1876.
+                        Experimental.
+                      </para>
+                    </entry>
+                  </row>
+                  <row rowsep="0">
+                    <entry colname="1">
+                      <para>
+                        MX
+                      </para>
+                    </entry>
+                    <entry colname="2">
+                      <para>
+                        Identifies a mail exchange for the domain with
+                        a 16-bit preference value (lower is better)
+                        followed by the host name of the mail exchange.
+                        Described in RFC 974, RFC 1035.
+                      </para>
+                    </entry>
+                  </row>
+                  <row rowsep="0">
+                    <entry colname="1">
+                      <para>
+                        NAPTR
+                      </para>
+                    </entry>
+                    <entry colname="2">
+                      <para>
+                        Name authority pointer.  Described in RFC 2915.
+                      </para>
+                    </entry>
+                  </row>
+                  <row rowsep="0">
+                    <entry colname="1">
+                      <para>
+                        NSAP
+                      </para>
+                    </entry>
+                    <entry colname="2">
+                      <para>
+                        A network service access point.
+                        Described in RFC 1706.
+                      </para>
+                    </entry>
+                  </row>
+                  <row rowsep="0">
+                    <entry colname="1">
+                      <para>
+                        NS
+                      </para>
+                    </entry>
+                    <entry colname="2">
+                      <para>
+                        The authoritative name server for the
+                        domain.  Described in RFC 1035.
+                      </para>
+                    </entry>
+                  </row>
+                  <row rowsep="0">
+                    <entry colname="1">
+                      <para>
+                        NSEC
+                      </para>
+                    </entry>
+                    <entry colname="2">
+                      <para>
+                        Used in DNSSECbis to securely indicate that
+                        RRs with an owner name in a certain name interval do
+                        not exist in
+                        a zone and indicate what RR types are present for an
+                        existing name.
+                        Described in RFC 4034.
+                      </para>
+                    </entry>
+                  </row>
+                  <row rowsep="0">
+                    <entry colname="1">
+                      <para>
+                        NXT
+                      </para>
+                    </entry>
+                    <entry colname="2">
+                      <para>
+                        Used in DNSSEC to securely indicate that
+                        RRs with an owner name in a certain name interval do
+                        not exist in
+                        a zone and indicate what RR types are present for an
+                        existing name.
+			Used in original DNSSEC; replaced by NSEC in
+			DNSSECbis.
+                        Described in RFC 2535.
+                      </para>
+                    </entry>
+                  </row>
+                  <row rowsep="0">
+                    <entry colname="1">
+                      <para>
+                        PTR
+                      </para>
+                    </entry>
+                    <entry colname="2">
+                      <para>
+                        A pointer to another part of the domain
+                        name space.  Described in RFC 1035.
+                      </para>
+                    </entry>
+                  </row>
+                  <row rowsep="0">
+                    <entry colname="1">
+                      <para>
+                        PX
+                      </para>
+                    </entry>
+                    <entry colname="2">
+                      <para>
+                        Provides mappings between RFC 822 and X.400
+                        addresses.  Described in RFC 2163.
+                      </para>
+                    </entry>
+                  </row>
+                  <row rowsep="0">
+                    <entry colname="1">
+                      <para>
+                        RP
+                      </para>
+                    </entry>
+                    <entry colname="2">
+                      <para>
+                        Information on persons responsible
+                        for the domain.  Experimental.  Described in RFC 1183.
+                      </para>
+                    </entry>
+                  </row>
+                  <row rowsep="0">
+                    <entry colname="1">
+                      <para>
+                        RRSIG
+                      </para>
+                    </entry>
+                    <entry colname="2">
+                      <para>
+                        Contains DNSSECbis signature data.  Described
+			in RFC 4034.
+                      </para>
+                    </entry>
+                  </row>
+                  <row rowsep="0">
+                    <entry colname="1">
+                      <para>
+                        RT
+                      </para>
+                    </entry>
+                    <entry colname="2">
+                      <para>
+                        Route-through binding for hosts that
+                        do not have their own direct wide area network
+                        addresses.
+                        Experimental.  Described in RFC 1183.
+                      </para>
+                    </entry>
+                  </row>
+                  <row rowsep="0">
+                    <entry colname="1">
+                      <para>
+                        SIG
+                      </para>
+                    </entry>
+                    <entry colname="2">
+                      <para>
+                        Contains DNSSEC signature data.  Used in
+			original DNSSEC; replaced by RRSIG in
+			DNSSECbis, but still used for SIG(0).
+			Described in RFCs 2535 and 2931.
+                      </para>
+                    </entry>
+                  </row>
+                  <row rowsep="0">
+                    <entry colname="1">
+                      <para>
+                        SOA
+                      </para>
+                    </entry>
+                    <entry colname="2">
+                      <para>
+                        Identifies the start of a zone of authority.
+                        Described in RFC 1035.
+                      </para>
+                    </entry>
+                  </row>
+                  <row rowsep="0">
+                    <entry colname="1">
+                      <para>
+                        SRV
+                      </para>
+                    </entry>
+                    <entry colname="2">
+                      <para>
+                        Information about well known network
+                        services (replaces WKS).  Described in RFC 2782.
+                      </para>
+                    </entry>
+                  </row>
+                  <row rowsep="0">
+                    <entry colname="1">
+                      <para>
+                        TXT
+                      </para>
+                    </entry>
+                    <entry colname="2">
+                      <para>
+                        Text records.  Described in RFC 1035.
+                      </para>
+                    </entry>
+                  </row>
+                  <row rowsep="0">
+                    <entry colname="1">
+                      <para>
+                        WKS
+                      </para>
+                    </entry>
+                    <entry colname="2">
+                      <para>
+                        Information about which well known
+                        network services, such as SMTP, that a domain
+                        supports. Historical.
+                      </para>
+                    </entry>
+                  </row>
+                  <row rowsep="0">
+                    <entry colname="1">
+                      <para>
+                        X25
+                      </para>
+                    </entry>
+                    <entry colname="2">
+                      <para>
+                        Representation of X.25 network addresses.
+                        Experimental.  Described in RFC 1183.
+                      </para>
+                    </entry>
+                  </row>
+                </tbody>
+              </tgroup>
+            </informaltable>
+            <para>
+              The following <emphasis>classes</emphasis> of resource records
+              are currently valid in the DNS:
+            </para>
+            <informaltable colsep="0" rowsep="0"><tgroup cols="2" colsep="0" rowsep="0" tgroupstyle="4Level-table">
+                <colspec colname="1" colnum="1" colsep="0" colwidth="0.875in"/>
+                <colspec colname="2" colnum="2" colsep="0" colwidth="3.625in"/>
+                <tbody>
+
+                  <row rowsep="0">
+                    <entry colname="1">
+                      <para>
+                        IN
+                      </para>
+                    </entry>
+                    <entry colname="2">
+                      <para>
+                        The Internet.
+                      </para>
+                    </entry>
+                  </row>
+
+                  <row rowsep="0">
+                    <entry colname="1">
+                      <para>
+                        CH
+                      </para>
+                    </entry>
+                    <entry colname="2">
+                      <para>
+                        Chaosnet, a LAN protocol created at MIT in the
+                        mid-1970s.
+                        Rarely used for its historical purpose, but reused for
+                        BIND's
+                        built-in server information zones, e.g.,
+                        <literal>version.bind</literal>.
+                      </para>
+                    </entry>
+                  </row>
+
+                  <row rowsep="0">
+                    <entry colname="1">
+                      <para>
+                        HS
+                      </para>
+                    </entry>
+                    <entry colname="2">
+                      <para>
+                        Hesiod, an information service
+                        developed by MIT's Project Athena. It is used to share
+                        information
+                        about various systems databases, such as users,
+                        groups, printers
+                        and so on.
+                      </para>
+                    </entry>
+                  </row>
+
+                </tbody>
+              </tgroup>
+            </informaltable>
+
+            <para>
+              The owner name is often implicit, rather than forming an
+              integral
+              part of the RR.  For example, many name servers internally form
+              tree
+              or hash structures for the name space, and chain RRs off nodes.
+              The remaining RR parts are the fixed header (type, class, TTL)
+              which is consistent for all RRs, and a variable part (RDATA)
+              that
+              fits the needs of the resource being described.
+            </para>
+            <para>
+              The meaning of the TTL field is a time limit on how long an
+              RR can be kept in a cache.  This limit does not apply to
+              authoritative
+              data in zones; it is also timed out, but by the refreshing
+              policies
+              for the zone.  The TTL is assigned by the administrator for the
+              zone where the data originates.  While short TTLs can be used to
+              minimize caching, and a zero TTL prohibits caching, the
+              realities
+              of Internet performance suggest that these times should be on
+              the
+              order of days for the typical host.  If a change can be
+              anticipated,
+              the TTL can be reduced prior to the change to minimize
+              inconsistency
+              during the change, and then increased back to its former value
+              following
+              the change.
+            </para>
+            <para>
+              The data in the RDATA section of RRs is carried as a combination
+              of binary strings and domain names.  The domain names are
+              frequently
+              used as "pointers" to other data in the DNS.
+            </para>
+          </sect3>
+          <sect3>
+            <title>Textual expression of RRs</title>
+            <para>
+              RRs are represented in binary form in the packets of the DNS
+              protocol, and are usually represented in highly encoded form
+              when
+              stored in a name server or resolver.  In the examples provided
+              in
+              RFC 1034, a style similar to that used in master files was
+              employed
+              in order to show the contents of RRs.  In this format, most RRs
+              are shown on a single line, although continuation lines are
+              possible
+              using parentheses.
+            </para>
+            <para>
+              The start of the line gives the owner of the RR.  If a line
+              begins with a blank, then the owner is assumed to be the same as
+              that of the previous RR.  Blank lines are often included for
+              readability.
+            </para>
+            <para>
+              Following the owner, we list the TTL, type, and class of the
+              RR.  Class and type use the mnemonics defined above, and TTL is
+              an integer before the type field.  In order to avoid ambiguity
+              in
+              parsing, type and class mnemonics are disjoint, TTLs are
+              integers,
+              and the type mnemonic is always last. The IN class and TTL
+              values
+              are often omitted from examples in the interests of clarity.
+            </para>
+            <para>
+              The resource data or RDATA section of the RR are given using
+              knowledge of the typical representation for the data.
+            </para>
+            <para>
+              For example, we might show the RRs carried in a message as:
+            </para>
+            <informaltable colsep="0" rowsep="0"><tgroup cols="3" colsep="0" rowsep="0" tgroupstyle="4Level-table">
+                <colspec colname="1" colnum="1" colsep="0" colwidth="1.381in"/>
+                <colspec colname="2" colnum="2" colsep="0" colwidth="1.020in"/>
+                <colspec colname="3" colnum="3" colsep="0" colwidth="2.099in"/>
+                <tbody>
+                  <row rowsep="0">
+                    <entry colname="1">
+                      <para>
+                        <literal>ISI.EDU.</literal>
+                      </para>
+                    </entry>
+                    <entry colname="2">
+                      <para>
+                        <literal>MX</literal>
+                      </para>
+                    </entry>
+                    <entry colname="3">
+                      <para>
+                        <literal>10 VENERA.ISI.EDU.</literal>
+                      </para>
+                    </entry>
+                  </row>
+                  <row rowsep="0">
+                    <entry colname="1">
+                      <para/>
+                    </entry>
+                    <entry colname="2">
+                      <para>
+                        <literal>MX</literal>
+                      </para>
+                    </entry>
+                    <entry colname="3">
+                      <para>
+                        <literal>10 VAXA.ISI.EDU</literal>
+                      </para>
+                    </entry>
+                  </row>
+                  <row rowsep="0">
+                    <entry colname="1">
+                      <para>
+                        <literal>VENERA.ISI.EDU</literal>
+                      </para>
+                    </entry>
+                    <entry colname="2">
+                      <para>
+                        <literal>A</literal>
+                      </para>
+                    </entry>
+                    <entry colname="3">
+                      <para>
+                        <literal>128.9.0.32</literal>
+                      </para>
+                    </entry>
+                  </row>
+                  <row rowsep="0">
+                    <entry colname="1">
+                      <para/>
+                    </entry>
+                    <entry colname="2">
+                      <para>
+                        <literal>A</literal>
+                      </para>
+                    </entry>
+                    <entry colname="3">
+                      <para>
+                        <literal>10.1.0.52</literal>
+                      </para>
+                    </entry>
+                  </row>
+                  <row rowsep="0">
+                    <entry colname="1">
+                      <para>
+                        <literal>VAXA.ISI.EDU</literal>
+                      </para>
+                    </entry>
+                    <entry colname="2">
+                      <para>
+                        <literal>A</literal>
+                      </para>
+                    </entry>
+                    <entry colname="3">
+                      <para>
+                        <literal>10.2.0.27</literal>
+                      </para>
+                    </entry>
+                  </row>
+                  <row rowsep="0">
+                    <entry colname="1">
+                      <para/>
+                    </entry>
+                    <entry colname="2">
+                      <para>
+                        <literal>A</literal>
+                      </para>
+                    </entry>
+                    <entry colname="3">
+                      <para>
+                        <literal>128.9.0.33</literal>
+                      </para>
+                    </entry>
+                  </row>
+                </tbody>
+              </tgroup>
+            </informaltable>
+            <para>
+              The MX RRs have an RDATA section which consists of a 16-bit
+              number followed by a domain name.  The address RRs use a
+              standard
+              IP address format to contain a 32-bit internet address.
+            </para>
+            <para>
+              The above example shows six RRs, with two RRs at each of three
+              domain names.
+            </para>
+            <para>
+              Similarly we might see:
+            </para>
+            <informaltable colsep="0" rowsep="0"><tgroup cols="3" colsep="0" rowsep="0" tgroupstyle="4Level-table">
+                <colspec colname="1" colnum="1" colsep="0" colwidth="1.491in"/>
+                <colspec colname="2" colnum="2" colsep="0" colwidth="1.067in"/>
+                <colspec colname="3" colnum="3" colsep="0" colwidth="2.067in"/>
+                <tbody>
+                  <row rowsep="0">
+                    <entry colname="1">
+                      <para>
+                        <literal>XX.LCS.MIT.EDU.</literal>
+                      </para>
+                    </entry>
+                    <entry colname="2">
+                      <para>
+                        <literal>IN A</literal>
+                      </para>
+                    </entry>
+                    <entry colname="3">
+                      <para>
+                        <literal>10.0.0.44</literal>
+                      </para>
+                    </entry>
+                  </row>
+                  <row rowsep="0">
+		    <entry colname="1"/>
+                    <entry colname="2">
+                      <para>
+                        <literal>CH A</literal>
+                      </para>
+                    </entry>
+                    <entry colname="3">
+                      <para>
+                        <literal>MIT.EDU. 2420</literal>
+                      </para>
+                    </entry>
+                  </row>
+                </tbody>
+              </tgroup>
+            </informaltable>
+            <para>
+              This example shows two addresses for
+	      <literal>XX.LCS.MIT.EDU</literal>, each of a different class.
+            </para>
+          </sect3>
+        </sect2>
+
+        <sect2>
+          <title>Discussion of MX Records</title>
+
+          <para>
+            As described above, domain servers store information as a
+            series of resource records, each of which contains a particular
+            piece of information about a given domain name (which is usually,
+            but not always, a host). The simplest way to think of a RR is as
+            a typed pair of data, a domain name matched with a relevant datum,
+            and stored with some additional type information to help systems
+            determine when the RR is relevant.
+          </para>
+
+          <para>
+            MX records are used to control delivery of email. The data
+            specified in the record is a priority and a domain name. The
+            priority
+            controls the order in which email delivery is attempted, with the
+            lowest number first. If two priorities are the same, a server is
+            chosen randomly. If no servers at a given priority are responding,
+            the mail transport agent will fall back to the next largest
+            priority.
+            Priority numbers do not have any absolute meaning &mdash; they are
+            relevant
+            only respective to other MX records for that domain name. The
+            domain
+            name given is the machine to which the mail will be delivered.
+	    It <emphasis>must</emphasis> have an associated address record
+	    (A or AAAA) &mdash; CNAME is not sufficient.
+          </para>
+          <para>
+            For a given domain, if there is both a CNAME record and an
+            MX record, the MX record is in error, and will be ignored.
+            Instead,
+            the mail will be delivered to the server specified in the MX
+            record
+            pointed to by the CNAME.
+          </para>
+	  <para>
+            For example:
+          </para>
+          <informaltable colsep="0" rowsep="0">
+            <tgroup cols="5" colsep="0" rowsep="0" tgroupstyle="3Level-table">
+              <colspec colname="1" colnum="1" colsep="0" colwidth="1.708in"/>
+              <colspec colname="2" colnum="2" colsep="0" colwidth="0.444in"/>
+              <colspec colname="3" colnum="3" colsep="0" colwidth="0.444in"/>
+              <colspec colname="4" colnum="4" colsep="0" colwidth="0.976in"/>
+              <colspec colname="5" colnum="5" colsep="0" colwidth="1.553in"/>
+              <tbody>
+                <row rowsep="0">
+                  <entry colname="1">
+                    <para>
+                      <literal>example.com.</literal>
+                    </para>
+                  </entry>
+                  <entry colname="2">
+                    <para>
+                      <literal>IN</literal>
+                    </para>
+                  </entry>
+                  <entry colname="3">
+                    <para>
+                      <literal>MX</literal>
+                    </para>
+                  </entry>
+                  <entry colname="4">
+                    <para>
+                      <literal>10</literal>
+                    </para>
+                  </entry>
+                  <entry colname="5">
+                    <para>
+                      <literal>mail.example.com.</literal>
+                    </para>
+                  </entry>
+                </row>
+                <row rowsep="0">
+                  <entry colname="1">
+                    <para/>
+                  </entry>
+                  <entry colname="2">
+                    <para>
+                      <literal>IN</literal>
+                    </para>
+                  </entry>
+                  <entry colname="3">
+                    <para>
+                      <literal>MX</literal>
+                    </para>
+                  </entry>
+                  <entry colname="4">
+                    <para>
+                      <literal>10</literal>
+                    </para>
+                  </entry>
+                  <entry colname="5">
+                    <para>
+                      <literal>mail2.example.com.</literal>
+                    </para>
+                  </entry>
+                </row>
+                <row rowsep="0">
+                  <entry colname="1">
+                    <para/>
+                  </entry>
+                  <entry colname="2">
+                    <para>
+                      <literal>IN</literal>
+                    </para>
+                  </entry>
+                  <entry colname="3">
+                    <para>
+                      <literal>MX</literal>
+                    </para>
+                  </entry>
+                  <entry colname="4">
+                    <para>
+                      <literal>20</literal>
+                    </para>
+                  </entry>
+                  <entry colname="5">
+                    <para>
+                      <literal>mail.backup.org.</literal>
+                    </para>
+                  </entry>
+                </row>
+                <row rowsep="0">
+                  <entry colname="1">
+                    <para>
+                      <literal>mail.example.com.</literal>
+                    </para>
+                  </entry>
+                  <entry colname="2">
+                    <para>
+                      <literal>IN</literal>
+                    </para>
+                  </entry>
+                  <entry colname="3">
+                    <para>
+                      <literal>A</literal>
+                    </para>
+                  </entry>
+                  <entry colname="4">
+                    <para>
+                      <literal>10.0.0.1</literal>
+                    </para>
+                  </entry>
+                  <entry colname="5">
+                    <para/>
+                  </entry>
+                </row>
+                <row rowsep="0">
+                  <entry colname="1">
+                    <para>
+                      <literal>mail2.example.com.</literal>
+                    </para>
+                  </entry>
+                  <entry colname="2">
+                    <para>
+                      <literal>IN</literal>
+                    </para>
+                  </entry>
+                  <entry colname="3">
+                    <para>
+                      <literal>A</literal>
+                    </para>
+                  </entry>
+                  <entry colname="4">
+                    <para>
+                      <literal>10.0.0.2</literal>
+                    </para>
+                  </entry>
+                  <entry colname="5">
+                    <para/>
+                  </entry>
+                </row>
+              </tbody>
+            </tgroup>
+            </informaltable><para>
+            Mail delivery will be attempted to <literal>mail.example.com</literal> and
+            <literal>mail2.example.com</literal> (in
+            any order), and if neither of those succeed, delivery to <literal>mail.backup.org</literal> will
+            be attempted.
+          </para>
+        </sect2>
+        <sect2 id="Setting_TTLs">
+          <title>Setting TTLs</title>
+          <para>
+            The time-to-live of the RR field is a 32-bit integer represented
+            in units of seconds, and is primarily used by resolvers when they
+            cache RRs. The TTL describes how long a RR can be cached before it
+            should be discarded. The following three types of TTL are
+            currently
+            used in a zone file.
+          </para>
+          <informaltable colsep="0" rowsep="0">
+            <tgroup cols="2" colsep="0" rowsep="0" tgroupstyle="3Level-table">
+              <colspec colname="1" colnum="1" colsep="0" colwidth="0.750in"/>
+              <colspec colname="2" colnum="2" colsep="0" colwidth="4.375in"/>
+              <tbody>
+                <row rowsep="0">
+                  <entry colname="1">
+                    <para>
+                      SOA
+                    </para>
+                  </entry>
+                  <entry colname="2">
+                    <para>
+                      The last field in the SOA is the negative
+                      caching TTL. This controls how long other servers will
+                      cache no-such-domain
+                      (NXDOMAIN) responses from you.
+                    </para>
+                    <para>
+                      The maximum time for
+                      negative caching is 3 hours (3h).
+                    </para>
+                  </entry>
+                </row>
+                <row rowsep="0">
+                  <entry colname="1">
+                    <para>
+                      $TTL
+                    </para>
+                  </entry>
+                  <entry colname="2">
+                    <para>
+                      The $TTL directive at the top of the
+                      zone file (before the SOA) gives a default TTL for every
+                      RR without
+                      a specific TTL set.
+                    </para>
+                  </entry>
+                </row>
+                <row rowsep="0">
+                  <entry colname="1">
+                    <para>
+                      RR TTLs
+                    </para>
+                  </entry>
+                  <entry colname="2">
+                    <para>
+                      Each RR can have a TTL as the second
+                      field in the RR, which will control how long other
+                      servers can cache
+                      the it.
+                    </para>
+                  </entry>
+                </row>
+              </tbody>
+            </tgroup>
+          </informaltable>
+          <para>
+            All of these TTLs default to units of seconds, though units
+            can be explicitly specified, for example, <literal>1h30m</literal>.
+          </para>
+        </sect2>
+        <sect2>
+          <title>Inverse Mapping in IPv4</title>
+          <para>
+            Reverse name resolution (that is, translation from IP address
+            to name) is achieved by means of the <emphasis>in-addr.arpa</emphasis> domain
+            and PTR records. Entries in the in-addr.arpa domain are made in
+            least-to-most significant order, read left to right. This is the
+            opposite order to the way IP addresses are usually written. Thus,
+            a machine with an IP address of 10.1.2.3 would have a
+            corresponding
+            in-addr.arpa name of
+            3.2.1.10.in-addr.arpa. This name should have a PTR resource record
+            whose data field is the name of the machine or, optionally,
+            multiple
+            PTR records if the machine has more than one name. For example,
+            in the <optional>example.com</optional> domain:
+          </para>
+          <informaltable colsep="0" rowsep="0">
+            <tgroup cols="2" colsep="0" rowsep="0" tgroupstyle="3Level-table">
+              <colspec colname="1" colnum="1" colsep="0" colwidth="1.125in"/>
+              <colspec colname="2" colnum="2" colsep="0" colwidth="4.000in"/>
+              <tbody>
+                <row rowsep="0">
+                  <entry colname="1">
+                    <para>
+                      <literal>$ORIGIN</literal>
+                    </para>
+                  </entry>
+                  <entry colname="2">
+                    <para>
+                      <literal>2.1.10.in-addr.arpa</literal>
+                    </para>
+                  </entry>
+                </row>
+                <row rowsep="0">
+                  <entry colname="1">
+                    <para>
+                      <literal>3</literal>
+                    </para>
+                  </entry>
+                  <entry colname="2">
+                    <para>
+                      <literal>IN PTR foo.example.com.</literal>
+                    </para>
+                  </entry>
+                </row>
+              </tbody>
+            </tgroup>
+          </informaltable>
+          <note>
+            <para>
+              The <command>$ORIGIN</command> lines in the examples
+              are for providing context to the examples only &mdash; they do not
+              necessarily
+              appear in the actual usage. They are only used here to indicate
+              that the example is relative to the listed origin.
+            </para>
+          </note>
+        </sect2>
+        <sect2>
+          <title>Other Zone File Directives</title>
+          <para>
+            The Master File Format was initially defined in RFC 1035 and
+            has subsequently been extended. While the Master File Format
+            itself
+            is class independent all records in a Master File must be of the
+            same
+            class.
+          </para>
+          <para>
+            Master File Directives include <command>$ORIGIN</command>, <command>$INCLUDE</command>,
+            and <command>$TTL.</command>
+          </para>
+          <sect3>
+            <title>The <command>$ORIGIN</command> Directive</title>
+            <para>
+              Syntax: <command>$ORIGIN</command>
+	      <replaceable>domain-name</replaceable>
+              <optional><replaceable>comment</replaceable></optional>
+            </para>
+            <para><command>$ORIGIN</command>
+	      sets the domain name that will be appended to any
+              unqualified records. When a zone is first read in there
+              is an implicit <command>$ORIGIN</command>
+              &lt;<varname>zone-name</varname>&gt;<command>.</command>
+              The current <command>$ORIGIN</command> is appended to
+              the domain specified in the <command>$ORIGIN</command>
+              argument if it is not absolute.
+            </para>
+
+<programlisting>
+$ORIGIN example.com.
+WWW     CNAME   MAIN-SERVER
+</programlisting>
+
+            <para>
+              is equivalent to
+            </para>
+
+<programlisting>
+WWW.EXAMPLE.COM. CNAME MAIN-SERVER.EXAMPLE.COM.
+</programlisting>
+
+          </sect3>
+          <sect3>
+            <title>The <command>$INCLUDE</command> Directive</title>
+            <para>
+              Syntax: <command>$INCLUDE</command>
+              <replaceable>filename</replaceable>
+              <optional>
+<replaceable>origin</replaceable> </optional>
+              <optional> <replaceable>comment</replaceable> </optional>
+            </para>
+            <para>
+              Read and process the file <filename>filename</filename> as
+              if it were included into the file at this point.  If <command>origin</command> is
+              specified the file is processed with <command>$ORIGIN</command> set
+              to that value, otherwise the current <command>$ORIGIN</command> is
+              used.
+            </para>
+            <para>
+              The origin and the current domain name
+              revert to the values they had prior to the <command>$INCLUDE</command> once
+              the file has been read.
+            </para>
+            <note>
+              <para>
+                RFC 1035 specifies that the current origin should be restored
+                after
+                an <command>$INCLUDE</command>, but it is silent
+                on whether the current
+                domain name should also be restored.  BIND 9 restores both of
+                them.
+                This could be construed as a deviation from RFC 1035, a
+                feature, or both.
+              </para>
+            </note>
+          </sect3>
+          <sect3>
+            <title>The <command>$TTL</command> Directive</title>
+            <para>
+              Syntax: <command>$TTL</command>
+              <replaceable>default-ttl</replaceable>
+              <optional>
+<replaceable>comment</replaceable> </optional>
+            </para>
+            <para>
+              Set the default Time To Live (TTL) for subsequent records
+              with undefined TTLs. Valid TTLs are of the range 0-2147483647
+              seconds.
+            </para>
+            <para><command>$TTL</command>
+	       is defined in RFC 2308.
+            </para>
+          </sect3>
+        </sect2>
+        <sect2>
+          <title><acronym>BIND</acronym> Master File Extension: the  <command>$GENERATE</command> Directive</title>
+          <para>
+            Syntax: <command>$GENERATE</command>
+	    <replaceable>range</replaceable>
+	    <replaceable>lhs</replaceable>
+            <optional><replaceable>ttl</replaceable></optional>
+            <optional><replaceable>class</replaceable></optional>
+	    <replaceable>type</replaceable>
+	    <replaceable>rhs</replaceable>
+            <optional><replaceable>comment</replaceable></optional>
+          </para>
+          <para><command>$GENERATE</command>
+	    is used to create a series of resource records that only
+            differ from each other by an
+            iterator. <command>$GENERATE</command> can be used to
+            easily generate the sets of records required to support
+            sub /24 reverse delegations described in RFC 2317:
+            Classless IN-ADDR.ARPA delegation.
+          </para>
+
+<programlisting>$ORIGIN 0.0.192.IN-ADDR.ARPA.
+$GENERATE 1-2 0 NS SERVER$.EXAMPLE.
+$GENERATE 1-127 $ CNAME $.0</programlisting>
+
+          <para>
+            is equivalent to
+          </para>
+
+<programlisting>0.0.0.192.IN-ADDR.ARPA NS SERVER1.EXAMPLE.
+0.0.0.192.IN-ADDR.ARPA. NS SERVER2.EXAMPLE.
+1.0.0.192.IN-ADDR.ARPA. CNAME 1.0.0.0.192.IN-ADDR.ARPA.
+2.0.0.192.IN-ADDR.ARPA. CNAME 2.0.0.0.192.IN-ADDR.ARPA.
+...
+127.0.0.192.IN-ADDR.ARPA. CNAME 127.0.0.0.192.IN-ADDR.ARPA.
+</programlisting>
+
+          <informaltable colsep="0" rowsep="0">
+            <tgroup cols="2" colsep="0" rowsep="0" tgroupstyle="3Level-table">
+                        <colspec colname="1" colnum="1" colsep="0" colwidth="0.875in"/>
+              <colspec colname="2" colnum="2" colsep="0" colwidth="4.250in"/>
+              <tbody>
+                <row rowsep="0">
+                  <entry colname="1">
+                    <para><command>range</command></para>
+                  </entry>
+                  <entry colname="2">
+                    <para>
+                      This can be one of two forms: start-stop
+                      or start-stop/step. If the first form is used, then step
+                      is set to
+                      1. All of start, stop and step must be positive.
+                    </para>
+                  </entry>
+                </row>
+                <row rowsep="0">
+                  <entry colname="1">
+                    <para><command>lhs</command></para>
+                  </entry>
+                  <entry colname="2">
+                    <para>This
+		      describes the owner name of the resource records
+                      to be created.  Any single <command>$</command>
+                      (dollar sign)
+                      symbols within the <command>lhs</command> side
+                      are replaced by the iterator value.
+
+                      To get a $ in the output, you need to escape the
+                      <command>$</command> using a backslash
+                      <command>\</command>,
+                      e.g. <command>\$</command>. The
+                      <command>$</command> may optionally be followed
+                      by modifiers which change the offset from the
+                      iterator, field width and base.
+
+                      Modifiers are introduced by a
+                      <command>{</command> (left brace) immediately following the
+                      <command>$</command> as
+                      <command>${offset[,width[,base]]}</command>.
+                      For example, <command>${-20,3,d}</command>
+                      subtracts 20 from the current value, prints the
+                      result as a decimal in a zero-padded field of
+                      width 3.
+
+		      Available output forms are decimal
+                      (<command>d</command>), octal
+                      (<command>o</command>) and hexadecimal
+                      (<command>x</command> or <command>X</command>
+                      for uppercase).  The default modifier is
+                      <command>${0,0,d}</command>.  If the
+                      <command>lhs</command> is not absolute, the
+                      current <command>$ORIGIN</command> is appended
+                      to the name.
+                    </para>
+                    <para>
+                      For compatibility with earlier versions, <command>$$</command> is still
+                      recognized as indicating a literal $ in the output.
+                    </para>
+                  </entry>
+                </row>
+                <row rowsep="0">
+                  <entry colname="1">
+                    <para><command>ttl</command></para>
+                  </entry>
+                  <entry colname="2">
+                    <para>
+		      Specifies the time-to-live of the generated records. If
+                      not specified this will be inherited using the
+                      normal ttl inheritance rules.
+                    </para>
+                    <para><command>class</command>
+		      and <command>ttl</command> can be
+                      entered in either order.
+                    </para>
+                  </entry>
+                </row>
+                <row rowsep="0">
+                  <entry colname="1">
+                    <para><command>class</command></para>
+                  </entry>
+                  <entry colname="2">
+                    <para>
+		      Specifies the class of the generated records.
+                      This must match the zone class if it is
+                      specified.
+                    </para>
+                    <para><command>class</command>
+		      and <command>ttl</command> can be
+                      entered in either order.
+                    </para>
+                  </entry>
+                </row>
+                <row rowsep="0">
+                  <entry colname="1">
+                    <para><command>type</command></para>
+                  </entry>
+                  <entry colname="2">
+                    <para>
+                      At present the only supported types are
+                      PTR, CNAME, DNAME, A, AAAA and NS.
+                    </para>
+                  </entry>
+                </row>
+                <row rowsep="0">
+                  <entry colname="1">
+                    <para><command>rhs</command></para>
+                  </entry>
+                  <entry colname="2">
+                    <para>
+                      <command>rhs</command> is a domain name. It is processed
+                      similarly to lhs.
+                    </para>
+                  </entry>
+                </row>
+              </tbody>
+            </tgroup>
+          </informaltable>
+          <para>
+            The <command>$GENERATE</command> directive is a <acronym>BIND</acronym> extension
+            and not part of the standard zone file format.
+          </para>
+          <para>
+            BIND 8 does not support the optional TTL and CLASS fields.
+          </para>
+        </sect2>
+
+	<sect2 id="zonefile_format">
+	  <title>Additional File Formats</title>
+	  <para>
+	    In addition to the standard textual format, BIND 9
+	    supports the ability to read or dump to zone files in
+	    other formats.  The <constant>raw</constant> format is
+	    currently available as an additional format.  It is a
+	    binary format representing BIND 9's internal data
+	    structure directly, thereby remarkably improving the
+	    loading time.
+	  </para>
+	  <para>
+	    For a primary server, a zone file in the
+	    <constant>raw</constant> format is expected to be
+	    generated from a textual zone file by the
+	    <command>named-compilezone</command> command.  For a
+	    secondary server or for a dynamic zone, it is automatically
+	    generated (if this format is specified by the
+	    <command>masterfile-format</command> option) when
+	    <command>named</command> dumps the zone contents after
+	    zone transfer or when applying prior updates.
+	  </para>
+	  <para>
+	    If a zone file in a binary format needs manual modification,
+	    it first must be converted to a textual form by the
+	    <command>named-compilezone</command> command.  All
+	    necessary modification should go to the text file, which
+	    should then be converted to the binary form by the
+	    <command>named-compilezone</command> command again.
+	  </para>
+    	  <para>
+	     Although the <constant>raw</constant> format uses the
+	     network byte order and avoids architecture-dependent
+	     data alignment so that it is as much portable as
+	     possible, it is primarily expected to be used inside
+	     the same single system.  In order to export a zone
+	     file in the <constant>raw</constant> format or make a
+	     portable backup of the file, it is recommended to
+	     convert the file to the standard textual representation.
+	  </para>
+	</sect2>
+      </sect1>
+    </chapter>
+    <chapter id="Bv9ARM.ch07">
+      <title><acronym>BIND</acronym> 9 Security Considerations</title>
+      <sect1 id="Access_Control_Lists">
+        <title>Access Control Lists</title>
+        <para>
+          Access Control Lists (ACLs), are address match lists that
+          you can set up and nickname for future use in <command>allow-notify</command>,
+          <command>allow-query</command>, <command>allow-recursion</command>,
+          <command>blackhole</command>, <command>allow-transfer</command>,
+          etc.
+        </para>
+        <para>
+          Using ACLs allows you to have finer control over who can access
+          your name server, without cluttering up your config files with huge
+          lists of IP addresses.
+        </para>
+        <para>
+          It is a <emphasis>good idea</emphasis> to use ACLs, and to
+          control access to your server. Limiting access to your server by
+          outside parties can help prevent spoofing and denial of service (DoS) attacks against
+          your server.
+        </para>
+        <para>
+          Here is an example of how to properly apply ACLs:
+        </para>
+
+<programlisting>
+// Set up an ACL named "bogusnets" that will block RFC1918 space
+// and some reserved space, which is commonly used in spoofing attacks.
+acl bogusnets {
+	0.0.0.0/8; 1.0.0.0/8; 2.0.0.0/8; 192.0.2.0/24; 224.0.0.0/3;
+	10.0.0.0/8; 172.16.0.0/12; 192.168.0.0/16;
+};
+
+// Set up an ACL called our-nets. Replace this with the real IP numbers.
+acl our-nets { x.x.x.x/24; x.x.x.x/21; };
+options {
+  ...
+  ...
+  allow-query { our-nets; };
+  allow-recursion { our-nets; };
+  ...
+  blackhole { bogusnets; };
+  ...
+};
+
+zone "example.com" {
+  type master;
+  file "m/example.com";
+  allow-query { any; };
+};
+</programlisting>
+
+        <para>
+          This allows recursive queries of the server from the outside
+          unless recursion has been previously disabled.
+        </para>
+        <para>
+          For more information on how to use ACLs to protect your server,
+          see the <emphasis>AUSCERT</emphasis> advisory at:
+        </para>
+        <para>
+          <ulink url="ftp://ftp.auscert.org.au/pub/auscert/advisory/AL-1999.004.dns_dos"
+	             >ftp://ftp.auscert.org.au/pub/auscert/advisory/AL-1999.004.dns_dos</ulink>
+        </para>
+      </sect1>
+      <sect1>
+        <title><command>Chroot</command> and <command>Setuid</command></title>
+        <para>
+          On UNIX servers, it is possible to run <acronym>BIND</acronym> in a <emphasis>chrooted</emphasis> environment
+          (using the <command>chroot()</command> function) by specifying the "<option>-t</option>"
+          option. This can help improve system security by placing <acronym>BIND</acronym> in
+          a "sandbox", which will limit the damage done if a server is
+          compromised.
+        </para>
+        <para>
+          Another useful feature in the UNIX version of <acronym>BIND</acronym> is the
+          ability to run the daemon as an unprivileged user ( <option>-u</option> <replaceable>user</replaceable> ).
+          We suggest running as an unprivileged user when using the <command>chroot</command> feature.
+        </para>
+        <para>
+          Here is an example command line to load <acronym>BIND</acronym> in a <command>chroot</command> sandbox,
+          <command>/var/named</command>, and to run <command>named</command> <command>setuid</command> to
+          user 202:
+        </para>
+        <para>
+          <userinput>/usr/local/bin/named -u 202 -t /var/named</userinput>
+        </para>
+
+        <sect2>
+          <title>The <command>chroot</command> Environment</title>
+
+          <para>
+            In order for a <command>chroot</command> environment
+            to
+            work properly in a particular directory
+            (for example, <filename>/var/named</filename>),
+            you will need to set up an environment that includes everything
+            <acronym>BIND</acronym> needs to run.
+            From <acronym>BIND</acronym>'s point of view, <filename>/var/named</filename> is
+            the root of the filesystem.  You will need to adjust the values of
+            options like
+            like <command>directory</command> and <command>pid-file</command> to account
+            for this.
+          </para>
+          <para>
+            Unlike with earlier versions of BIND, you typically will
+            <emphasis>not</emphasis> need to compile <command>named</command>
+            statically nor install shared libraries under the new root.
+            However, depending on your operating system, you may need
+            to set up things like
+            <filename>/dev/zero</filename>,
+            <filename>/dev/random</filename>,
+            <filename>/dev/log</filename>, and
+            <filename>/etc/localtime</filename>.
+          </para>
+        </sect2>
+
+        <sect2>
+          <title>Using the <command>setuid</command> Function</title>
+
+          <para>
+            Prior to running the <command>named</command> daemon,
+            use
+            the <command>touch</command> utility (to change file
+            access and
+            modification times) or the <command>chown</command>
+            utility (to
+            set the user id and/or group id) on files
+            to which you want <acronym>BIND</acronym>
+            to write.
+          </para>
+	  <note>
+	    Note that if the <command>named</command> daemon is running as an
+            unprivileged user, it will not be able to bind to new restricted
+            ports if the server is reloaded.
+	  </note>
+        </sect2>
+      </sect1>
+
+      <sect1 id="dynamic_update_security">
+        <title>Dynamic Update Security</title>
+
+        <para>
+          Access to the dynamic
+          update facility should be strictly limited.  In earlier versions of
+          <acronym>BIND</acronym>, the only way to do this was
+          based on the IP
+          address of the host requesting the update, by listing an IP address
+          or
+          network prefix in the <command>allow-update</command>
+          zone option.
+          This method is insecure since the source address of the update UDP
+          packet
+          is easily forged.  Also note that if the IP addresses allowed by the
+          <command>allow-update</command> option include the
+          address of a slave
+          server which performs forwarding of dynamic updates, the master can
+          be
+          trivially attacked by sending the update to the slave, which will
+          forward it to the master with its own source IP address causing the
+          master to approve it without question.
+        </para>
+
+        <para>
+          For these reasons, we strongly recommend that updates be
+          cryptographically authenticated by means of transaction signatures
+          (TSIG).  That is, the <command>allow-update</command>
+          option should
+          list only TSIG key names, not IP addresses or network
+          prefixes. Alternatively, the new <command>update-policy</command>
+          option can be used.
+        </para>
+
+        <para>
+          Some sites choose to keep all dynamically-updated DNS data
+          in a subdomain and delegate that subdomain to a separate zone. This
+          way, the top-level zone containing critical data such as the IP
+          addresses
+          of public web and mail servers need not allow dynamic update at
+          all.
+        </para>
+
+      </sect1>
+    </chapter>
+
+    <chapter id="Bv9ARM.ch08">
+      <title>Troubleshooting</title>
+      <sect1>
+        <title>Common Problems</title>
+        <sect2>
+          <title>It's not working; how can I figure out what's wrong?</title>
+
+          <para>
+            The best solution to solving installation and
+            configuration issues is to take preventative measures by setting
+            up logging files beforehand. The log files provide a
+            source of hints and information that can be used to figure out
+            what went wrong and how to fix the problem.
+          </para>
+
+        </sect2>
+      </sect1>
+      <sect1>
+        <title>Incrementing and Changing the Serial Number</title>
+
+	<para>
+	  Zone serial numbers are just numbers &mdash; they aren't
+	  date related.  A lot of people set them to a number that
+	  represents a date, usually of the form YYYYMMDDRR.
+	  Occasionally they will make a mistake and set them to a
+	  "date in the future" then try to correct them by setting
+	  them to the "current date".  This causes problems because
+	  serial numbers are used to indicate that a zone has been
+	  updated.  If the serial number on the slave server is
+	  lower than the serial number on the master, the slave
+	  server will attempt to update its copy of the zone.
+	</para>
+
+        <para>
+          Setting the serial number to a lower number on the master
+          server than the slave server means that the slave will not perform
+          updates to its copy of the zone.
+        </para>
+
+        <para>
+          The solution to this is to add 2147483647 (2^31-1) to the
+          number, reload the zone and make sure all slaves have updated to
+          the new zone serial number, then reset the number to what you want
+          it to be, and reload the zone again.
+        </para>
+
+      </sect1>
+      <sect1>
+        <title>Where Can I Get Help?</title>
+
+        <para>
+          The Internet Systems Consortium
+          (<acronym>ISC</acronym>) offers a wide range
+          of support and service agreements for <acronym>BIND</acronym> and <acronym>DHCP</acronym> servers. Four
+          levels of premium support are available and each level includes
+          support for all <acronym>ISC</acronym> programs,
+          significant discounts on products
+          and training, and a recognized priority on bug fixes and
+          non-funded feature requests. In addition, <acronym>ISC</acronym> offers a standard
+          support agreement package which includes services ranging from bug
+          fix announcements to remote support. It also includes training in
+          <acronym>BIND</acronym> and <acronym>DHCP</acronym>.
+        </para>
+
+        <para>
+          To discuss arrangements for support, contact
+          <ulink url="mailto:info@isc.org">info@isc.org</ulink> or visit the
+          <acronym>ISC</acronym> web page at
+	  <ulink url="http://www.isc.org/services/support/"
+	             >http://www.isc.org/services/support/</ulink>
+          to read more.
+        </para>
+      </sect1>
+    </chapter>
+    <appendix id="Bv9ARM.ch09">
+      <title>Appendices</title>
+      <sect1>
+        <title>Acknowledgments</title>
+        <sect2 id="historical_dns_information">
+          <title>A Brief History of the <acronym>DNS</acronym> and <acronym>BIND</acronym></title>
+
+          <para>
+            Although the "official" beginning of the Domain Name
+            System occurred in 1984 with the publication of RFC 920, the
+            core of the new system was described in 1983 in RFCs 882 and
+            883. From 1984 to 1987, the ARPAnet (the precursor to today's
+            Internet) became a testbed of experimentation for developing the
+            new naming/addressing scheme in a rapidly expanding,
+            operational network environment.  New RFCs were written and
+            published in 1987 that modified the original documents to
+            incorporate improvements based on the working model. RFC 1034,
+            "Domain Names-Concepts and Facilities", and RFC 1035, "Domain
+            Names-Implementation and Specification" were published and
+            became the standards upon which all <acronym>DNS</acronym> implementations are
+            built.
+          </para>
+
+          <para>
+            The first working domain name server, called "Jeeves", was
+            written in 1983-84 by Paul Mockapetris for operation on DEC
+            Tops-20
+            machines located at the University of Southern California's
+            Information
+            Sciences Institute (USC-ISI) and SRI International's Network
+            Information
+            Center (SRI-NIC). A <acronym>DNS</acronym> server for
+            Unix machines, the Berkeley Internet
+            Name Domain (<acronym>BIND</acronym>) package, was
+            written soon after by a group of
+            graduate students at the University of California at Berkeley
+            under
+            a grant from the US Defense Advanced Research Projects
+            Administration
+            (DARPA).
+          </para>
+          <para>
+	    Versions of <acronym>BIND</acronym> through
+            4.8.3 were maintained by the Computer
+            Systems Research Group (CSRG) at UC Berkeley. Douglas Terry, Mark
+            Painter, David Riggle and Songnian Zhou made up the initial <acronym>BIND</acronym>
+            project team. After that, additional work on the software package
+            was done by Ralph Campbell. Kevin Dunlap, a Digital Equipment
+            Corporation
+            employee on loan to the CSRG, worked on <acronym>BIND</acronym> for 2 years, from 1985
+            to 1987. Many other people also contributed to <acronym>BIND</acronym> development
+            during that time: Doug Kingston, Craig Partridge, Smoot
+            Carl-Mitchell,
+            Mike Muuss, Jim Bloom and Mike Schwartz. <acronym>BIND</acronym> maintenance was subsequently
+            handled by Mike Karels and &#216;ivind Kure.
+          </para>
+          <para>
+            <acronym>BIND</acronym> versions 4.9 and 4.9.1 were
+            released by Digital Equipment
+            Corporation (now Compaq Computer Corporation). Paul Vixie, then
+            a DEC employee, became <acronym>BIND</acronym>'s
+            primary caretaker. He was assisted
+            by Phil Almquist, Robert Elz, Alan Barrett, Paul Albitz, Bryan
+            Beecher, Andrew
+            Partan, Andy Cherenson, Tom Limoncelli, Berthold Paffrath, Fuat
+            Baran, Anant Kumar, Art Harkin, Win Treese, Don Lewis, Christophe
+            Wolfhugel, and others.
+          </para>
+          <para>
+            In 1994, <acronym>BIND</acronym> version 4.9.2 was sponsored by
+            Vixie Enterprises. Paul
+            Vixie became <acronym>BIND</acronym>'s principal
+            architect/programmer.
+          </para>
+          <para>
+            <acronym>BIND</acronym> versions from 4.9.3 onward
+            have been developed and maintained
+            by the Internet Systems Consortium and its predecessor,
+            the Internet Software Consortium,  with support being provided
+            by ISC's sponsors.
+          </para>
+	  <para>
+	    As co-architects/programmers, Bob Halley and
+            Paul Vixie released the first production-ready version of
+	    <acronym>BIND</acronym> version 8 in May 1997.
+          </para>
+	  <para>
+	    BIND version 9 was released in September 2000 and is a
+	    major rewrite of nearly all aspects of the underlying
+	    BIND architecture.
+          </para>
+          <para>
+	    BIND version 4 is officially deprecated and BIND version
+	    8 development is considered maintenance-only in favor
+	    of BIND version 9. No additional development is done
+	    on BIND version 4 or BIND version 8 other than for
+	    security-related patches.
+          </para>
+          <para>
+            <acronym>BIND</acronym> development work is made
+            possible today by the sponsorship
+            of several corporations, and by the tireless work efforts of
+            numerous individuals.
+          </para>
+        </sect2>
+      </sect1>
+      <sect1>
+        <title>General <acronym>DNS</acronym> Reference Information</title>
+        <sect2 id="ipv6addresses">
+          <title>IPv6 addresses (AAAA)</title>
+          <para>
+            IPv6 addresses are 128-bit identifiers for interfaces and
+            sets of interfaces which were introduced in the <acronym>DNS</acronym> to facilitate
+            scalable Internet routing. There are three types of addresses: <emphasis>Unicast</emphasis>,
+            an identifier for a single interface;
+            <emphasis>Anycast</emphasis>,
+            an identifier for a set of interfaces; and <emphasis>Multicast</emphasis>,
+            an identifier for a set of interfaces. Here we describe the global
+            Unicast address scheme. For more information, see RFC 3587,
+	    "Global Unicast Address Format."
+          </para>
+          <para>
+	    IPv6 unicast addresses consist of a
+	    <emphasis>global routing prefix</emphasis>, a
+	    <emphasis>subnet identifier</emphasis>, and an
+	    <emphasis>interface identifier</emphasis>.
+          </para>
+          <para>
+            The global routing prefix is provided by the
+            upstream provider or ISP, and (roughly) corresponds to the
+	    IPv4 <emphasis>network</emphasis> section
+            of the address range.
+
+	    The subnet identifier is for local subnetting, much the
+            same as subnetting an
+            IPv4 /16 network into /24 subnets.
+
+	    The interface identifier is the address of an individual
+            interface on a given network; in IPv6, addresses belong to
+            interfaces rather than to machines.
+          </para>
+          <para>
+            The subnetting capability of IPv6 is much more flexible than
+            that of IPv4: subnetting can be carried out on bit boundaries,
+            in much the same way as Classless InterDomain Routing
+            (CIDR), and the DNS PTR representation ("nibble" format)
+            makes setting up reverse zones easier.
+          </para>
+          <para>
+            The Interface Identifier must be unique on the local link,
+            and is usually generated automatically by the IPv6
+            implementation, although it is usually possible to
+            override the default setting if necessary.  A typical IPv6
+            address might look like:
+	    <command>2001:db8:201:9:a00:20ff:fe81:2b32</command>
+	  </para>
+          <para>
+            IPv6 address specifications often contain long strings
+            of zeros, so the architects have included a shorthand for
+            specifying
+            them. The double colon (`::') indicates the longest possible
+            string
+            of zeros that can fit, and can be used only once in an address.
+          </para>
+        </sect2>
+      </sect1>
+      <sect1 id="bibliography">
+        <title>Bibliography (and Suggested Reading)</title>
+        <sect2 id="rfcs">
+          <title>Request for Comments (RFCs)</title>
+          <para>
+            Specification documents for the Internet protocol suite, including
+            the <acronym>DNS</acronym>, are published as part of
+            the Request for Comments (RFCs)
+            series of technical notes. The standards themselves are defined
+            by the Internet Engineering Task Force (IETF) and the Internet
+            Engineering Steering Group (IESG). RFCs can be obtained online via FTP at:
+	  </para>
+	  <para>
+            <ulink url="ftp://www.isi.edu/in-notes/">
+	      ftp://www.isi.edu/in-notes/RFC<replaceable>xxxx</replaceable>.txt
+	    </ulink>
+	  </para>
+	  <para>
+	    (where <replaceable>xxxx</replaceable> is
+            the number of the RFC). RFCs are also available via the Web at:
+	  </para>
+	  <para>
+            <ulink url="http://www.ietf.org/rfc/"
+	               >http://www.ietf.org/rfc/</ulink>.
+          </para>
+          <bibliography>
+            <bibliodiv>
+              <!-- one of (BIBLIOENTRY BIBLIOMIXED) -->
+              <title>Standards</title>
+              <biblioentry>
+                <abbrev>RFC974</abbrev>
+                <author>
+                  <surname>Partridge</surname>
+                  <firstname>C.</firstname>
+                </author>
+                <title>Mail Routing and the Domain System</title>
+                <pubdate>January 1986</pubdate>
+              </biblioentry>
+              <biblioentry>
+                <abbrev>RFC1034</abbrev>
+                <author>
+                  <surname>Mockapetris</surname>
+                  <firstname>P.V.</firstname>
+                </author>
+                <title>Domain Names &mdash; Concepts and Facilities</title>
+                <pubdate>November 1987</pubdate>
+              </biblioentry>
+              <biblioentry>
+                <abbrev>RFC1035</abbrev>
+                <author>
+                  <surname>Mockapetris</surname>
+                  <firstname>P. V.</firstname>
+                  </author> <title>Domain Names &mdash; Implementation and
+                  Specification</title>
+                <pubdate>November 1987</pubdate>
+              </biblioentry>
+            </bibliodiv>
+            <bibliodiv id="proposed_standards" xreflabel="Proposed Standards">
+
+              <title>Proposed Standards</title>
+              <!-- one of (BIBLIOENTRY BIBLIOMIXED) -->
+              <biblioentry>
+                <abbrev>RFC2181</abbrev>
+                <author>
+                  <surname>Elz</surname>
+                  <firstname>R., R. Bush</firstname>
+                </author>
+                <title>Clarifications to the <acronym>DNS</acronym>
+                  Specification</title>
+                <pubdate>July 1997</pubdate>
+              </biblioentry>
+              <biblioentry>
+                <abbrev>RFC2308</abbrev>
+                <author>
+                  <surname>Andrews</surname>
+                  <firstname>M.</firstname>
+                </author>
+                <title>Negative Caching of <acronym>DNS</acronym>
+                  Queries</title>
+                <pubdate>March 1998</pubdate>
+              </biblioentry>
+              <biblioentry>
+                <abbrev>RFC1995</abbrev>
+                <author>
+                  <surname>Ohta</surname>
+                  <firstname>M.</firstname>
+                </author>
+                <title>Incremental Zone Transfer in <acronym>DNS</acronym></title>
+                <pubdate>August 1996</pubdate>
+              </biblioentry>
+              <biblioentry>
+                <abbrev>RFC1996</abbrev>
+                <author>
+                  <surname>Vixie</surname>
+                  <firstname>P.</firstname>
+                </author>
+                <title>A Mechanism for Prompt Notification of Zone Changes</title>
+                <pubdate>August 1996</pubdate>
+              </biblioentry>
+              <biblioentry>
+                <abbrev>RFC2136</abbrev>
+                <authorgroup>
+                  <author>
+                    <surname>Vixie</surname>
+                    <firstname>P.</firstname>
+                  </author>
+                  <author>
+                    <firstname>S.</firstname>
+                    <surname>Thomson</surname>
+                  </author>
+                  <author>
+                    <firstname>Y.</firstname>
+                    <surname>Rekhter</surname>
+                  </author>
+                  <author>
+                    <firstname>J.</firstname>
+                    <surname>Bound</surname>
+                  </author>
+                </authorgroup>
+                <title>Dynamic Updates in the Domain Name System</title>
+                <pubdate>April 1997</pubdate>
+              </biblioentry>
+	      <biblioentry>
+                <abbrev>RFC2671</abbrev>
+                <authorgroup>
+                  <author>
+                    <firstname>P.</firstname>
+                    <surname>Vixie</surname>
+                  </author>
+                </authorgroup>
+                <title>Extension Mechanisms for DNS (EDNS0)</title>
+                <pubdate>August 1997</pubdate>
+	      </biblioentry>
+	      <biblioentry>
+                <abbrev>RFC2672</abbrev>
+                <authorgroup>
+                  <author>
+                    <firstname>M.</firstname>
+                    <surname>Crawford</surname>
+                  </author>
+                </authorgroup>
+                <title>Non-Terminal DNS Name Redirection</title>
+                <pubdate>August 1999</pubdate>
+	      </biblioentry>
+              <biblioentry>
+                <abbrev>RFC2845</abbrev>
+                <authorgroup>
+                  <author>
+                    <surname>Vixie</surname>
+                    <firstname>P.</firstname>
+                  </author>
+                  <author>
+                    <firstname>O.</firstname>
+                    <surname>Gudmundsson</surname>
+                  </author>
+                  <author>
+                    <firstname>D.</firstname>
+                    <surname>Eastlake</surname>
+                    <lineage>3rd</lineage>
+                  </author>
+                  <author>
+                    <firstname>B.</firstname>
+                    <surname>Wellington</surname>
+                  </author>
+                </authorgroup>
+                <title>Secret Key Transaction Authentication for <acronym>DNS</acronym> (TSIG)</title>
+                <pubdate>May 2000</pubdate>
+              </biblioentry>
+              <biblioentry>
+                <abbrev>RFC2930</abbrev>
+                <authorgroup>
+                  <author>
+                    <firstname>D.</firstname>
+                    <surname>Eastlake</surname>
+                    <lineage>3rd</lineage>
+                  </author>
+                </authorgroup>
+                <title>Secret Key Establishment for DNS (TKEY RR)</title>
+                <pubdate>September 2000</pubdate>
+              </biblioentry>
+              <biblioentry>
+                <abbrev>RFC2931</abbrev>
+                <authorgroup>
+                  <author>
+                    <firstname>D.</firstname>
+                    <surname>Eastlake</surname>
+                    <lineage>3rd</lineage>
+                  </author>
+                </authorgroup>
+                <title>DNS Request and Transaction Signatures (SIG(0)s)</title>
+                <pubdate>September 2000</pubdate>
+              </biblioentry>
+              <biblioentry>
+                <abbrev>RFC3007</abbrev>
+                <authorgroup>
+                  <author>
+                    <firstname>B.</firstname>
+                    <surname>Wellington</surname>
+                  </author>
+                </authorgroup>
+                <title>Secure Domain Name System (DNS) Dynamic Update</title>
+                <pubdate>November 2000</pubdate>
+              </biblioentry>
+              <biblioentry>
+                <abbrev>RFC3645</abbrev>
+                <authorgroup>
+                  <author>
+                    <firstname>S.</firstname>
+                    <surname>Kwan</surname>
+                  </author>
+                  <author>
+                    <firstname>P.</firstname>
+                    <surname>Garg</surname>
+                  </author>
+                  <author>
+                    <firstname>J.</firstname>
+                    <surname>Gilroy</surname>
+                  </author>
+                  <author>
+                    <firstname>L.</firstname>
+                    <surname>Esibov</surname>
+                  </author>
+                  <author>
+                    <firstname>J.</firstname>
+                    <surname>Westhead</surname>
+                  </author>
+                  <author>
+                    <firstname>R.</firstname>
+                    <surname>Hall</surname>
+                  </author>
+                </authorgroup>
+                <title>Generic Security Service Algorithm for Secret
+		       Key Transaction Authentication for DNS
+		       (GSS-TSIG)</title>
+                <pubdate>October 2003</pubdate>
+              </biblioentry>
+            </bibliodiv>
+	    <bibliodiv>
+	      <title><acronym>DNS</acronym> Security Proposed Standards</title>
+	      <biblioentry>
+		<abbrev>RFC3225</abbrev>
+	 	<authorgroup>
+		  <author>
+		    <firstname>D.</firstname>
+		    <surname>Conrad</surname>
+		  </author>
+	 	</authorgroup>
+		<title>Indicating Resolver Support of DNSSEC</title>
+		<pubdate>December 2001</pubdate>
+	      </biblioentry>
+	      <biblioentry>
+	        <abbrev>RFC3833</abbrev>
+	 	<authorgroup>
+		  <author>
+		    <firstname>D.</firstname>
+		    <surname>Atkins</surname>
+		  </author>
+		  <author>
+		    <firstname>R.</firstname>
+		    <surname>Austein</surname>
+		  </author>
+		</authorgroup>
+		<title>Threat Analysis of the Domain Name System (DNS)</title>
+		<pubdate>August 2004</pubdate>
+	      </biblioentry>
+	      <biblioentry>
+	        <abbrev>RFC4033</abbrev>
+	 	<authorgroup>
+		  <author>
+		    <firstname>R.</firstname>
+		    <surname>Arends</surname>
+		  </author>
+		  <author>
+		    <firstname>R.</firstname>
+		    <surname>Austein</surname>
+		  </author>
+		  <author>
+		    <firstname>M.</firstname>
+		    <surname>Larson</surname>
+		  </author>
+		  <author>
+		    <firstname>D.</firstname>
+		    <surname>Massey</surname>
+		  </author>
+		  <author>
+		    <firstname>S.</firstname>
+		    <surname>Rose</surname>
+		  </author>
+		</authorgroup>
+		<title>DNS Security Introduction and Requirements</title>
+		<pubdate>March 2005</pubdate>
+	      </biblioentry>
+	      <biblioentry>
+	        <abbrev>RFC4044</abbrev>
+	 	<authorgroup>
+		  <author>
+		    <firstname>R.</firstname>
+		    <surname>Arends</surname>
+		  </author>
+		  <author>
+		    <firstname>R.</firstname>
+		    <surname>Austein</surname>
+		  </author>
+		  <author>
+		    <firstname>M.</firstname>
+		    <surname>Larson</surname>
+		  </author>
+		  <author>
+		    <firstname>D.</firstname>
+		    <surname>Massey</surname>
+		  </author>
+		  <author>
+		    <firstname>S.</firstname>
+		    <surname>Rose</surname>
+		  </author>
+		</authorgroup>
+		<title>Resource Records for the DNS Security Extensions</title>
+		<pubdate>March 2005</pubdate>
+	      </biblioentry>
+	      <biblioentry>
+	        <abbrev>RFC4035</abbrev>
+	 	<authorgroup>
+		  <author>
+		    <firstname>R.</firstname>
+		    <surname>Arends</surname>
+		  </author>
+		  <author>
+		    <firstname>R.</firstname>
+		    <surname>Austein</surname>
+		  </author>
+		  <author>
+		    <firstname>M.</firstname>
+		    <surname>Larson</surname>
+		  </author>
+		  <author>
+		    <firstname>D.</firstname>
+		    <surname>Massey</surname>
+		  </author>
+		  <author>
+		    <firstname>S.</firstname>
+		    <surname>Rose</surname>
+		  </author>
+		</authorgroup>
+		<title>Protocol Modifications for the DNS
+		       Security Extensions</title>
+		<pubdate>March 2005</pubdate>
+	      </biblioentry>
+            </bibliodiv>
+            <bibliodiv>
+              <title>Other Important RFCs About <acronym>DNS</acronym>
+                Implementation</title>
+              <biblioentry>
+                <abbrev>RFC1535</abbrev>
+                <author>
+                  <surname>Gavron</surname>
+                  <firstname>E.</firstname>
+                </author>
+                <title>A Security Problem and Proposed Correction With Widely
+                  Deployed <acronym>DNS</acronym> Software.</title>
+                <pubdate>October 1993</pubdate>
+              </biblioentry>
+              <biblioentry>
+                <abbrev>RFC1536</abbrev>
+                <authorgroup>
+                  <author>
+                    <surname>Kumar</surname>
+                    <firstname>A.</firstname>
+                  </author>
+                  <author>
+                    <firstname>J.</firstname>
+                    <surname>Postel</surname>
+                  </author>
+                  <author>
+                    <firstname>C.</firstname>
+                    <surname>Neuman</surname>
+                  </author>
+                  <author>
+                    <firstname>P.</firstname>
+                    <surname>Danzig</surname>
+                  </author>
+                  <author>
+                    <firstname>S.</firstname>
+                    <surname>Miller</surname>
+                  </author>
+                </authorgroup>
+                <title>Common <acronym>DNS</acronym> Implementation
+                  Errors and Suggested Fixes</title>
+                <pubdate>October 1993</pubdate>
+              </biblioentry>
+              <biblioentry>
+                <abbrev>RFC1982</abbrev>
+                <authorgroup>
+                  <author>
+                    <surname>Elz</surname>
+                    <firstname>R.</firstname>
+                  </author>
+                  <author>
+                    <firstname>R.</firstname>
+                    <surname>Bush</surname>
+                  </author>
+                </authorgroup>
+                <title>Serial Number Arithmetic</title>
+                <pubdate>August 1996</pubdate>
+              </biblioentry>
+              <biblioentry>
+                <abbrev>RFC4074</abbrev>
+                <authorgroup>
+                  <author>
+                    <surname>Morishita</surname>
+                    <firstname>Y.</firstname>
+                  </author>
+                  <author>
+                    <firstname>T.</firstname>
+                    <surname>Jinmei</surname>
+                  </author>
+                </authorgroup>
+                <title>Common Misbehaviour Against <acronym>DNS</acronym>
+		Queries for IPv6 Addresses</title>
+                <pubdate>May 2005</pubdate>
+              </biblioentry>
+            </bibliodiv>
+            <bibliodiv>
+              <title>Resource Record Types</title>
+              <biblioentry>
+                <abbrev>RFC1183</abbrev>
+                <authorgroup>
+                  <author>
+                    <surname>Everhart</surname>
+                    <firstname>C.F.</firstname>
+                  </author>
+                  <author>
+                    <firstname>L. A.</firstname>
+                    <surname>Mamakos</surname>
+                  </author>
+                  <author>
+                    <firstname>R.</firstname>
+                    <surname>Ullmann</surname>
+                  </author>
+                  <author>
+                    <firstname>P.</firstname>
+                    <surname>Mockapetris</surname>
+                  </author>
+                </authorgroup>
+                <title>New <acronym>DNS</acronym> RR Definitions</title>
+                <pubdate>October 1990</pubdate>
+              </biblioentry>
+              <biblioentry>
+                <abbrev>RFC1706</abbrev>
+                <authorgroup>
+                  <author>
+                    <surname>Manning</surname>
+                    <firstname>B.</firstname>
+                  </author>
+                  <author>
+                    <firstname>R.</firstname>
+                    <surname>Colella</surname>
+                  </author>
+                </authorgroup>
+                <title><acronym>DNS</acronym> NSAP Resource Records</title>
+                <pubdate>October 1994</pubdate>
+              </biblioentry>
+              <biblioentry>
+                <abbrev>RFC2168</abbrev>
+                <authorgroup>
+                  <author>
+                    <surname>Daniel</surname>
+                    <firstname>R.</firstname>
+                  </author>
+                  <author>
+                    <firstname>M.</firstname>
+                    <surname>Mealling</surname>
+                  </author>
+                </authorgroup>
+                <title>Resolution of Uniform Resource Identifiers using
+                  the Domain Name System</title>
+                <pubdate>June 1997</pubdate>
+              </biblioentry>
+              <biblioentry>
+                <abbrev>RFC1876</abbrev>
+                <authorgroup>
+                  <author>
+                    <surname>Davis</surname>
+                    <firstname>C.</firstname>
+                  </author>
+                  <author>
+                    <firstname>P.</firstname>
+                    <surname>Vixie</surname>
+                  </author>
+                  <author>
+                    <firstname>T.</firstname>
+                    <firstname>Goodwin</firstname>
+                  </author>
+                  <author>
+                    <firstname>I.</firstname>
+                    <surname>Dickinson</surname>
+                  </author>
+                </authorgroup>
+                <title>A Means for Expressing Location Information in the
+                  Domain
+                  Name System</title>
+                <pubdate>January 1996</pubdate>
+              </biblioentry>
+              <biblioentry>
+                <abbrev>RFC2052</abbrev>
+                <authorgroup>
+                  <author>
+                    <surname>Gulbrandsen</surname>
+                    <firstname>A.</firstname>
+                  </author>
+                  <author>
+                    <firstname>P.</firstname>
+                    <surname>Vixie</surname>
+                  </author>
+                </authorgroup>
+                <title>A <acronym>DNS</acronym> RR for Specifying the
+                  Location of
+                  Services.</title>
+                <pubdate>October 1996</pubdate>
+              </biblioentry>
+              <biblioentry>
+                <abbrev>RFC2163</abbrev>
+                <author>
+                  <surname>Allocchio</surname>
+                  <firstname>A.</firstname>
+                </author>
+                <title>Using the Internet <acronym>DNS</acronym> to
+                  Distribute MIXER
+                  Conformant Global Address Mapping</title>
+                <pubdate>January 1998</pubdate>
+              </biblioentry>
+              <biblioentry>
+                <abbrev>RFC2230</abbrev>
+                <author>
+                  <surname>Atkinson</surname>
+                  <firstname>R.</firstname>
+                </author>
+                <title>Key Exchange Delegation Record for the <acronym>DNS</acronym></title>
+                <pubdate>October 1997</pubdate>
+              </biblioentry>
+              <biblioentry>
+                <abbrev>RFC2536</abbrev>
+                <author>
+                  <surname>Eastlake</surname>
+                  <firstname>D.</firstname>
+                  <lineage>3rd</lineage>
+                </author>
+                <title>DSA KEYs and SIGs in the Domain Name System (DNS)</title>
+                <pubdate>March 1999</pubdate>
+              </biblioentry>
+              <biblioentry>
+                <abbrev>RFC2537</abbrev>
+                <author>
+                  <surname>Eastlake</surname>
+                  <firstname>D.</firstname>
+                  <lineage>3rd</lineage>
+                </author>
+                <title>RSA/MD5 KEYs and SIGs in the Domain Name System (DNS)</title>
+                <pubdate>March 1999</pubdate>
+              </biblioentry>
+              <biblioentry>
+                <abbrev>RFC2538</abbrev>
+		<authorgroup>
+                  <author>
+                    <surname>Eastlake</surname>
+                    <firstname>D.</firstname>
+                    <lineage>3rd</lineage>
+                  </author>
+		  <author>
+		    <surname>Gudmundsson</surname>
+		    <firstname>O.</firstname>
+		  </author>
+		</authorgroup>
+                <title>Storing Certificates in the Domain Name System (DNS)</title>
+                <pubdate>March 1999</pubdate>
+              </biblioentry>
+              <biblioentry>
+                <abbrev>RFC2539</abbrev>
+		<authorgroup>
+                  <author>
+                    <surname>Eastlake</surname>
+                    <firstname>D.</firstname>
+                    <lineage>3rd</lineage>
+                  </author>
+		</authorgroup>
+                <title>Storage of Diffie-Hellman Keys in the Domain Name System (DNS)</title>
+                <pubdate>March 1999</pubdate>
+              </biblioentry>
+              <biblioentry>
+                <abbrev>RFC2540</abbrev>
+		<authorgroup>
+                  <author>
+                    <surname>Eastlake</surname>
+                    <firstname>D.</firstname>
+                    <lineage>3rd</lineage>
+                  </author>
+		</authorgroup>
+                <title>Detached Domain Name System (DNS) Information</title>
+                <pubdate>March 1999</pubdate>
+              </biblioentry>
+              <biblioentry>
+                <abbrev>RFC2782</abbrev>
+                <author>
+                  <surname>Gulbrandsen</surname>
+                  <firstname>A.</firstname>
+                </author>
+                <author>
+                  <surname>Vixie</surname>
+                  <firstname>P.</firstname>
+                </author>
+                <author>
+                  <surname>Esibov</surname>
+                  <firstname>L.</firstname>
+                </author>
+                <title>A DNS RR for specifying the location of services (DNS SRV)</title>
+                <pubdate>February 2000</pubdate>
+              </biblioentry>
+              <biblioentry>
+                <abbrev>RFC2915</abbrev>
+                <author>
+                  <surname>Mealling</surname>
+                  <firstname>M.</firstname>
+                </author>
+                <author>
+                  <surname>Daniel</surname>
+                  <firstname>R.</firstname>
+                </author>
+                <title>The Naming Authority Pointer (NAPTR) DNS Resource Record</title>
+                <pubdate>September 2000</pubdate>
+              </biblioentry>
+              <biblioentry>
+                <abbrev>RFC3110</abbrev>
+                <author>
+                    <surname>Eastlake</surname>
+                    <firstname>D.</firstname>
+                    <lineage>3rd</lineage>
+                </author>
+                <title>RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS)</title>
+                <pubdate>May 2001</pubdate>
+              </biblioentry>
+              <biblioentry>
+                <abbrev>RFC3123</abbrev>
+                <author>
+                  <surname>Koch</surname>
+                  <firstname>P.</firstname>
+                </author>
+                <title>A DNS RR Type for Lists of Address Prefixes (APL RR)</title>
+                <pubdate>June 2001</pubdate>
+              </biblioentry>
+              <biblioentry>
+                <abbrev>RFC3596</abbrev>
+                <authorgroup>
+                  <author>
+                    <surname>Thomson</surname>
+                    <firstname>S.</firstname>
+                  </author>
+                  <author>
+                    <firstname>C.</firstname>
+                    <surname>Huitema</surname>
+                  </author>
+                  <author>
+                    <firstname>V.</firstname>
+                    <surname>Ksinant</surname>
+                  </author>
+                  <author>
+                    <firstname>M.</firstname>
+                    <surname>Souissi</surname>
+                  </author>
+                </authorgroup>
+                <title><acronym>DNS</acronym> Extensions to support IP
+                  version 6</title>
+                <pubdate>October 2003</pubdate>
+              </biblioentry>
+              <biblioentry>
+                <abbrev>RFC3597</abbrev>
+                <author>
+                  <surname>Gustafsson</surname>
+                  <firstname>A.</firstname>
+                </author>
+                <title>Handling of Unknown DNS Resource Record (RR) Types</title>
+                <pubdate>September 2003</pubdate>
+              </biblioentry>
+            </bibliodiv>
+            <bibliodiv>
+              <title><acronym>DNS</acronym> and the Internet</title>
+              <biblioentry>
+                <abbrev>RFC1101</abbrev>
+                <author>
+                  <surname>Mockapetris</surname>
+                  <firstname>P. V.</firstname>
+                </author>
+                <title><acronym>DNS</acronym> Encoding of Network Names
+                  and Other Types</title>
+                <pubdate>April 1989</pubdate>
+              </biblioentry>
+              <biblioentry>
+                <abbrev>RFC1123</abbrev>
+                <author>
+                  <surname>Braden</surname>
+                  <surname>R.</surname>
+                </author>
+                <title>Requirements for Internet Hosts - Application and
+                  Support</title>
+                <pubdate>October 1989</pubdate>
+              </biblioentry>
+              <biblioentry>
+                <abbrev>RFC1591</abbrev>
+                <author>
+                  <surname>Postel</surname>
+                  <firstname>J.</firstname>
+                </author>
+                <title>Domain Name System Structure and Delegation</title>
+                <pubdate>March 1994</pubdate>
+              </biblioentry>
+              <biblioentry>
+                <abbrev>RFC2317</abbrev>
+                <authorgroup>
+                  <author>
+                    <surname>Eidnes</surname>
+                    <firstname>H.</firstname>
+                  </author>
+                  <author>
+                    <firstname>G.</firstname>
+                    <surname>de Groot</surname>
+                  </author>
+                  <author>
+                    <firstname>P.</firstname>
+                    <surname>Vixie</surname>
+                  </author>
+                </authorgroup>
+                <title>Classless IN-ADDR.ARPA Delegation</title>
+                <pubdate>March 1998</pubdate>
+              </biblioentry>
+              <biblioentry>
+                <abbrev>RFC2826</abbrev>
+                <authorgroup>
+                  <author>
+                    <surname>Internet Architecture Board</surname>
+                  </author>
+                </authorgroup>
+                <title>IAB Technical Comment on the Unique DNS Root</title>
+                <pubdate>May 2000</pubdate>
+              </biblioentry>
+              <biblioentry>
+                <abbrev>RFC2929</abbrev>
+                <authorgroup>
+                  <author>
+                    <surname>Eastlake</surname>
+                    <firstname>D.</firstname>
+                    <lineage>3rd</lineage>
+                  </author>
+                  <author>
+                    <surname>Brunner-Williams</surname>
+                    <firstname>E.</firstname>
+                  </author>
+                  <author>
+                    <surname>Manning</surname>
+                    <firstname>B.</firstname>
+                  </author>
+                </authorgroup>
+                <title>Domain Name System (DNS) IANA Considerations</title>
+                <pubdate>September 2000</pubdate>
+              </biblioentry>
+            </bibliodiv>
+            <bibliodiv>
+              <title><acronym>DNS</acronym> Operations</title>
+              <biblioentry>
+                <abbrev>RFC1033</abbrev>
+                <author>
+                  <surname>Lottor</surname>
+                  <firstname>M.</firstname>
+                </author>
+                <title>Domain administrators operations guide.</title>
+                <pubdate>November 1987</pubdate>
+              </biblioentry>
+              <biblioentry>
+                <abbrev>RFC1537</abbrev>
+                <author>
+                  <surname>Beertema</surname>
+                  <firstname>P.</firstname>
+                </author>
+                <title>Common <acronym>DNS</acronym> Data File
+                  Configuration Errors</title>
+                <pubdate>October 1993</pubdate>
+              </biblioentry>
+              <biblioentry>
+                <abbrev>RFC1912</abbrev>
+                <author>
+                  <surname>Barr</surname>
+                  <firstname>D.</firstname>
+                </author>
+                <title>Common <acronym>DNS</acronym> Operational and
+                  Configuration Errors</title>
+                <pubdate>February 1996</pubdate>
+              </biblioentry>
+              <biblioentry>
+                <abbrev>RFC2010</abbrev>
+                <authorgroup>
+                  <author>
+                    <surname>Manning</surname>
+                    <firstname>B.</firstname>
+                  </author>
+                  <author>
+                    <firstname>P.</firstname>
+                    <surname>Vixie</surname>
+                  </author>
+                </authorgroup>
+                <title>Operational Criteria for Root Name Servers.</title>
+                <pubdate>October 1996</pubdate>
+              </biblioentry>
+              <biblioentry>
+                <abbrev>RFC2219</abbrev>
+                <authorgroup>
+                  <author>
+                    <surname>Hamilton</surname>
+                    <firstname>M.</firstname>
+                  </author>
+                  <author>
+                    <firstname>R.</firstname>
+                    <surname>Wright</surname>
+                  </author>
+                </authorgroup>
+                <title>Use of <acronym>DNS</acronym> Aliases for
+                  Network Services.</title>
+                <pubdate>October 1997</pubdate>
+              </biblioentry>
+            </bibliodiv>
+	    <bibliodiv>
+              <title>Internationalized Domain Names</title>
+              <biblioentry>
+                <abbrev>RFC2825</abbrev>
+		<authorgroup>
+                  <author>
+                    <surname>IAB</surname>
+                  </author>
+                  <author>
+                    <surname>Daigle</surname>
+                    <firstname>R.</firstname>
+                  </author>
+		</authorgroup>
+                <title>A Tangled Web: Issues of I18N, Domain Names,
+		       and the Other Internet protocols</title>
+                <pubdate>May 2000</pubdate>
+              </biblioentry>
+              <biblioentry>
+                <abbrev>RFC3490</abbrev>
+		<authorgroup>
+                  <author>
+                    <surname>Faltstrom</surname>
+                    <firstname>P.</firstname>
+                  </author>
+                  <author>
+                    <surname>Hoffman</surname>
+                    <firstname>P.</firstname>
+                  </author>
+                  <author>
+                    <surname>Costello</surname>
+                    <firstname>A.</firstname>
+                  </author>
+		</authorgroup>
+                <title>Internationalizing Domain Names in Applications (IDNA)</title>
+                <pubdate>March 2003</pubdate>
+              </biblioentry>
+              <biblioentry>
+                <abbrev>RFC3491</abbrev>
+		<authorgroup>
+                  <author>
+                    <surname>Hoffman</surname>
+                    <firstname>P.</firstname>
+                  </author>
+                  <author>
+                    <surname>Blanchet</surname>
+                    <firstname>M.</firstname>
+                  </author>
+		</authorgroup>
+                <title>Nameprep: A Stringprep Profile for Internationalized Domain Names</title>
+                <pubdate>March 2003</pubdate>
+              </biblioentry>
+              <biblioentry>
+                <abbrev>RFC3492</abbrev>
+		<authorgroup>
+                  <author>
+                    <surname>Costello</surname>
+                    <firstname>A.</firstname>
+                  </author>
+		</authorgroup>
+                <title>Punycode: A Bootstring encoding of Unicode
+		       for Internationalized Domain Names in
+		       Applications (IDNA)</title>
+                <pubdate>March 2003</pubdate>
+              </biblioentry>
+	    </bibliodiv>
+            <bibliodiv>
+              <title>Other <acronym>DNS</acronym>-related RFCs</title>
+              <note>
+                <para>
+                  Note: the following list of RFCs, although
+                  <acronym>DNS</acronym>-related, are not
+                  concerned with implementing software.
+                </para>
+              </note>
+              <biblioentry>
+                <abbrev>RFC1464</abbrev>
+                <author>
+                  <surname>Rosenbaum</surname>
+                  <firstname>R.</firstname>
+                </author>
+                <title>Using the Domain Name System To Store Arbitrary String
+                  Attributes</title>
+                <pubdate>May 1993</pubdate>
+              </biblioentry>
+              <biblioentry>
+                <abbrev>RFC1713</abbrev>
+                <author>
+                  <surname>Romao</surname>
+                  <firstname>A.</firstname>
+                </author>
+                <title>Tools for <acronym>DNS</acronym> Debugging</title>
+                <pubdate>November 1994</pubdate>
+              </biblioentry>
+              <biblioentry>
+                <abbrev>RFC1794</abbrev>
+                <author>
+                  <surname>Brisco</surname>
+                  <firstname>T.</firstname>
+                </author>
+                <title><acronym>DNS</acronym> Support for Load
+                  Balancing</title>
+                <pubdate>April 1995</pubdate>
+              </biblioentry>
+              <biblioentry>
+                <abbrev>RFC2240</abbrev>
+                <author>
+                  <surname>Vaughan</surname>
+                  <firstname>O.</firstname>
+                </author>
+                <title>A Legal Basis for Domain Name Allocation</title>
+                <pubdate>November 1997</pubdate>
+              </biblioentry>
+              <biblioentry>
+                <abbrev>RFC2345</abbrev>
+                <authorgroup>
+                  <author>
+                    <surname>Klensin</surname>
+                    <firstname>J.</firstname>
+                  </author>
+                  <author>
+                    <firstname>T.</firstname>
+                    <surname>Wolf</surname>
+                  </author>
+                  <author>
+                    <firstname>G.</firstname>
+                    <surname>Oglesby</surname>
+                  </author>
+                </authorgroup>
+                <title>Domain Names and Company Name Retrieval</title>
+                <pubdate>May 1998</pubdate>
+              </biblioentry>
+              <biblioentry>
+                <abbrev>RFC2352</abbrev>
+                <author>
+                  <surname>Vaughan</surname>
+                  <firstname>O.</firstname>
+                </author>
+                <title>A Convention For Using Legal Names as Domain Names</title>
+                <pubdate>May 1998</pubdate>
+              </biblioentry>
+              <biblioentry>
+                <abbrev>RFC3071</abbrev>
+                <authorgroup>
+                  <author>
+                    <surname>Klensin</surname>
+                    <firstname>J.</firstname>
+                  </author>
+                </authorgroup>
+                <title>Reflections on the DNS, RFC 1591, and Categories of Domains</title>
+                <pubdate>February 2001</pubdate>
+              </biblioentry>
+              <biblioentry>
+                <abbrev>RFC3258</abbrev>
+                <authorgroup>
+                  <author>
+                    <surname>Hardie</surname>
+                    <firstname>T.</firstname>
+                  </author>
+                </authorgroup>
+                <title>Distributing Authoritative Name Servers via
+		       Shared Unicast Addresses</title>
+                <pubdate>April 2002</pubdate>
+              </biblioentry>
+              <biblioentry>
+                <abbrev>RFC3901</abbrev>
+                <authorgroup>
+                  <author>
+                    <surname>Durand</surname>
+                    <firstname>A.</firstname>
+                  </author>
+                  <author>
+                    <firstname>J.</firstname>
+                    <surname>Ihren</surname>
+                  </author>
+                </authorgroup>
+                <title>DNS IPv6 Transport Operational Guidelines</title>
+                <pubdate>September 2004</pubdate>
+              </biblioentry>
+            </bibliodiv>
+            <bibliodiv>
+              <title>Obsolete and Unimplemented Experimental RFC</title>
+              <biblioentry>
+                <abbrev>RFC1712</abbrev>
+                <authorgroup>
+                  <author>
+                    <surname>Farrell</surname>
+                    <firstname>C.</firstname>
+                  </author>
+                  <author>
+                    <firstname>M.</firstname>
+                    <surname>Schulze</surname>
+                  </author>
+                  <author>
+                    <firstname>S.</firstname>
+                    <surname>Pleitner</surname>
+                  </author>
+                  <author>
+                    <firstname>D.</firstname>
+                    <surname>Baldoni</surname>
+                  </author>
+                </authorgroup>
+                <title><acronym>DNS</acronym> Encoding of Geographical
+                  Location</title>
+                <pubdate>November 1994</pubdate>
+              </biblioentry>
+              <biblioentry>
+                <abbrev>RFC2673</abbrev>
+                <authorgroup>
+                  <author>
+                    <surname>Crawford</surname>
+                    <firstname>M.</firstname>
+                  </author>
+                </authorgroup>
+                <title>Binary Labels in the Domain Name System</title>
+                <pubdate>August 1999</pubdate>
+              </biblioentry>
+              <biblioentry>
+                <abbrev>RFC2874</abbrev>
+                <authorgroup>
+                  <author>
+                    <surname>Crawford</surname>
+                    <firstname>M.</firstname>
+                  </author>
+                  <author>
+                    <surname>Huitema</surname>
+                    <firstname>C.</firstname>
+                  </author>
+                </authorgroup>
+                <title>DNS Extensions to Support IPv6 Address Aggregation
+		       and Renumbering</title>
+                <pubdate>July 2000</pubdate>
+              </biblioentry>
+            </bibliodiv>
+            <bibliodiv>
+              <title>Obsoleted DNS Security RFCs</title>
+	      <note>
+		<para>
+		  Most of these have been consolidated into RFC4033,
+		  RFC4034 and RFC4035 which collectively describe DNSSECbis.
+		</para>
+	      </note>
+              <biblioentry>
+                <abbrev>RFC2065</abbrev>
+                <authorgroup>
+                  <author>
+                    <surname>Eastlake</surname>
+                    <lineage>3rd</lineage>
+                    <firstname>D.</firstname>
+                  </author>
+                  <author>
+                    <firstname>C.</firstname>
+                    <surname>Kaufman</surname>
+                  </author>
+                </authorgroup>
+                <title>Domain Name System Security Extensions</title>
+                <pubdate>January 1997</pubdate>
+              </biblioentry>
+              <biblioentry>
+                <abbrev>RFC2137</abbrev>
+                <author>
+                  <surname>Eastlake</surname>
+                  <lineage>3rd</lineage>
+                  <firstname>D.</firstname>
+                </author>
+                <title>Secure Domain Name System Dynamic Update</title>
+                <pubdate>April 1997</pubdate>
+              </biblioentry>
+              <biblioentry>
+                <abbrev>RFC2535</abbrev>
+                <authorgroup>
+                  <author>
+                    <surname>Eastlake</surname>
+                    <lineage>3rd</lineage>
+                    <firstname>D.</firstname>
+                  </author>
+                </authorgroup>
+                <title>Domain Name System Security Extensions</title>
+                <pubdate>March 1999</pubdate>
+              </biblioentry>
+              <biblioentry>
+                <abbrev>RFC3008</abbrev>
+                <authorgroup>
+                  <author>
+                    <surname>Wellington</surname>
+                    <firstname>B.</firstname>
+                  </author>
+                </authorgroup>
+                <title>Domain Name System Security (DNSSEC)
+		       Signing Authority</title>
+                <pubdate>November 2000</pubdate>
+              </biblioentry>
+              <biblioentry>
+                <abbrev>RFC3090</abbrev>
+                <authorgroup>
+                  <author>
+                    <surname>Lewis</surname>
+                    <firstname>E.</firstname>
+                  </author>
+                </authorgroup>
+                <title>DNS Security Extension Clarification on Zone Status</title>
+                <pubdate>March 2001</pubdate>
+              </biblioentry>
+              <biblioentry>
+                <abbrev>RFC3445</abbrev>
+                <authorgroup>
+                  <author>
+                    <surname>Massey</surname>
+                    <firstname>D.</firstname>
+                  </author>
+                  <author>
+                    <surname>Rose</surname>
+                    <firstname>S.</firstname>
+                  </author>
+                </authorgroup>
+                <title>Limiting the Scope of the KEY Resource Record (RR)</title>
+                <pubdate>December 2002</pubdate>
+              </biblioentry>
+              <biblioentry>
+                <abbrev>RFC3655</abbrev>
+                <authorgroup>
+                  <author>
+                    <surname>Wellington</surname>
+                    <firstname>B.</firstname>
+                  </author>
+                  <author>
+                    <surname>Gudmundsson</surname>
+                    <firstname>O.</firstname>
+                  </author>
+                </authorgroup>
+                <title>Redefinition of DNS Authenticated Data (AD) bit</title>
+                <pubdate>November 2003</pubdate>
+              </biblioentry>
+              <biblioentry>
+                <abbrev>RFC3658</abbrev>
+                <authorgroup>
+                  <author>
+                    <surname>Gudmundsson</surname>
+                    <firstname>O.</firstname>
+                  </author>
+                </authorgroup>
+                <title>Delegation Signer (DS) Resource Record (RR)</title>
+                <pubdate>December 2003</pubdate>
+              </biblioentry>
+              <biblioentry>
+                <abbrev>RFC3755</abbrev>
+                <authorgroup>
+                  <author>
+                    <surname>Weiler</surname>
+                    <firstname>S.</firstname>
+                  </author>
+                </authorgroup>
+                <title>Legacy Resolver Compatibility for Delegation Signer (DS)</title>
+                <pubdate>May 2004</pubdate>
+              </biblioentry>
+              <biblioentry>
+                <abbrev>RFC3757</abbrev>
+                <authorgroup>
+                  <author>
+                    <surname>Kolkman</surname>
+                    <firstname>O.</firstname>
+                  </author>
+                  <author>
+                    <surname>Schlyter</surname>
+                    <firstname>J.</firstname>
+                  </author>
+                  <author>
+                    <surname>Lewis</surname>
+                    <firstname>E.</firstname>
+                  </author>
+                </authorgroup>
+                <title>Domain Name System KEY (DNSKEY) Resource Record
+		      (RR) Secure Entry Point (SEP) Flag</title>
+                <pubdate>April 2004</pubdate>
+              </biblioentry>
+              <biblioentry>
+                <abbrev>RFC3845</abbrev>
+                <authorgroup>
+                  <author>
+                    <surname>Schlyter</surname>
+                    <firstname>J.</firstname>
+                  </author>
+                </authorgroup>
+                <title>DNS Security (DNSSEC) NextSECure (NSEC) RDATA Format</title>
+                <pubdate>August 2004</pubdate>
+              </biblioentry>
+            </bibliodiv>
+          </bibliography>
+        </sect2>
+        <sect2 id="internet_drafts">
+          <title>Internet Drafts</title>
+          <para>
+            Internet Drafts (IDs) are rough-draft working documents of
+            the Internet Engineering Task Force. They are, in essence, RFCs
+            in the preliminary stages of development. Implementors are
+            cautioned not
+            to regard IDs as archival, and they should not be quoted or cited
+            in any formal documents unless accompanied by the disclaimer that
+            they are "works in progress." IDs have a lifespan of six months
+            after which they are deleted unless updated by their authors.
+          </para>
+        </sect2>
+        <sect2>
+          <title>Other Documents About <acronym>BIND</acronym></title>
+          <para/>
+          <bibliography>
+            <biblioentry>
+              <authorgroup>
+                <author>
+                  <surname>Albitz</surname>
+                  <firstname>Paul</firstname>
+                </author>
+                <author>
+                  <firstname>Cricket</firstname>
+                  <surname>Liu</surname>
+                </author>
+              </authorgroup>
+              <title><acronym>DNS</acronym> and <acronym>BIND</acronym></title>
+              <copyright>
+                <year>1998</year>
+                <holder>Sebastopol, CA: O'Reilly and Associates</holder>
+              </copyright>
+            </biblioentry>
+          </bibliography>
+        </sect2>
+      </sect1>
+    </appendix>
+
+    <reference id="Bv9ARM.ch10">
+      <title>Manual pages</title>
+      <xi:include href="../../bin/dig/dig.docbook"/>
+      <xi:include href="../../bin/dig/host.docbook"/>
+      <xi:include href="../../bin/dnssec/dnssec-keygen.docbook"/>
+      <xi:include href="../../bin/dnssec/dnssec-signzone.docbook"/>
+      <xi:include href="../../bin/check/named-checkconf.docbook"/>
+      <xi:include href="../../bin/check/named-checkzone.docbook"/>
+      <xi:include href="../../bin/named/named.docbook"/>
+      <!-- named.conf.docbook and others? -->
+      <!-- nsupdate gives db2latex indigestion, markup problems? -->
+      <xi:include href="../../bin/rndc/rndc.docbook"/>
+      <xi:include href="../../bin/rndc/rndc.conf.docbook"/>
+      <xi:include href="../../bin/rndc/rndc-confgen.docbook"/>
+    </reference>
+
+  </book>
+
+<!--
+  - Local variables:
+  - mode: sgml
+  - End:
+ -->
diff --git a/doc/arm/Bv9ARM.ch01.html b/doc/arm/Bv9ARM.ch01.html
new file mode 100644
index 0000000..30e9e0d
--- /dev/null
+++ b/doc/arm/Bv9ARM.ch01.html
@@ -0,0 +1,560 @@
+<!--
+ - Copyright (C) 2004-2007 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2000-2003 Internet Software Consortium.
+ - 
+ - Permission to use, copy, modify, and distribute this software for any
+ - purpose with or without fee is hereby granted, provided that the above
+ - copyright notice and this permission notice appear in all copies.
+ - 
+ - THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
+ - REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
+ - AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
+ - INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
+ - LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
+ - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
+ - PERFORMANCE OF THIS SOFTWARE.
+-->
+<!-- $Id: Bv9ARM.ch01.html,v 1.16.18.21 2007/10/31 01:35:57 marka Exp $ -->
+<html>
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
+<title>Chapter 1. Introduction</title>
+<meta name="generator" content="DocBook XSL Stylesheets V1.71.1">
+<link rel="start" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual">
+<link rel="up" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual">
+<link rel="prev" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual">
+<link rel="next" href="Bv9ARM.ch02.html" title="Chapter 2. BIND Resource Requirements">
+</head>
+<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
+<div class="navheader">
+<table width="100%" summary="Navigation header">
+<tr><th colspan="3" align="center">Chapter 1. Introduction</th></tr>
+<tr>
+<td width="20%" align="left">
+<a accesskey="p" href="Bv9ARM.html">Prev</a> </td>
+<th width="60%" align="center"> </th>
+<td width="20%" align="right"> <a accesskey="n" href="Bv9ARM.ch02.html">Next</a>
+</td>
+</tr>
+</table>
+<hr>
+</div>
+<div class="chapter" lang="en">
+<div class="titlepage"><div><div><h2 class="title">
+<a name="Bv9ARM.ch01"></a>Chapter 1. Introduction</h2></div></div></div>
+<div class="toc">
+<p><b>Table of Contents</b></p>
+<dl>
+<dt><span class="sect1"><a href="Bv9ARM.ch01.html#id2564117">Scope of Document</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch01.html#id2564140">Organization of This Document</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch01.html#id2563474">Conventions Used in This Document</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch01.html#id2564816">The Domain Name System (<acronym class="acronym">DNS</acronym>)</a></span></dt>
+<dd><dl>
+<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2564837">DNS Fundamentals</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2564871">Domains and Domain Names</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2567208">Zones</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2567285">Authoritative Name Servers</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2567526">Caching Name Servers</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2567588">Name Servers in Multiple Roles</a></span></dt>
+</dl></dd>
+</dl>
+</div>
+<p>
+      The Internet Domain Name System (<acronym class="acronym">DNS</acronym>)
+      consists of the syntax
+      to specify the names of entities in the Internet in a hierarchical
+      manner, the rules used for delegating authority over names, and the
+      system implementation that actually maps names to Internet
+      addresses.  <acronym class="acronym">DNS</acronym> data is maintained in a
+      group of distributed
+      hierarchical databases.
+    </p>
+<div class="sect1" lang="en">
+<div class="titlepage"><div><div><h2 class="title" style="clear: both">
+<a name="id2564117"></a>Scope of Document</h2></div></div></div>
+<p>
+        The Berkeley Internet Name Domain
+        (<acronym class="acronym">BIND</acronym>) implements a
+        domain name server for a number of operating systems. This
+        document provides basic information about the installation and
+        care of the Internet Systems Consortium (<acronym class="acronym">ISC</acronym>)
+        <acronym class="acronym">BIND</acronym> version 9 software package for
+        system administrators.
+      </p>
+<p>
+        This version of the manual corresponds to BIND version 9.4.
+      </p>
+</div>
+<div class="sect1" lang="en">
+<div class="titlepage"><div><div><h2 class="title" style="clear: both">
+<a name="id2564140"></a>Organization of This Document</h2></div></div></div>
+<p>
+        In this document, <span class="emphasis"><em>Section 1</em></span> introduces
+        the basic <acronym class="acronym">DNS</acronym> and <acronym class="acronym">BIND</acronym> concepts. <span class="emphasis"><em>Section 2</em></span>
+        describes resource requirements for running <acronym class="acronym">BIND</acronym> in various
+        environments. Information in <span class="emphasis"><em>Section 3</em></span> is
+        <span class="emphasis"><em>task-oriented</em></span> in its presentation and is
+        organized functionally, to aid in the process of installing the
+        <acronym class="acronym">BIND</acronym> 9 software. The task-oriented
+        section is followed by
+        <span class="emphasis"><em>Section 4</em></span>, which contains more advanced
+        concepts that the system administrator may need for implementing
+        certain options. <span class="emphasis"><em>Section 5</em></span>
+        describes the <acronym class="acronym">BIND</acronym> 9 lightweight
+        resolver.  The contents of <span class="emphasis"><em>Section 6</em></span> are
+        organized as in a reference manual to aid in the ongoing
+        maintenance of the software. <span class="emphasis"><em>Section 7</em></span> addresses
+        security considerations, and
+        <span class="emphasis"><em>Section 8</em></span> contains troubleshooting help. The
+        main body of the document is followed by several
+        <span class="emphasis"><em>appendices</em></span> which contain useful reference
+        information, such as a <span class="emphasis"><em>bibliography</em></span> and
+        historic information related to <acronym class="acronym">BIND</acronym>
+        and the Domain Name
+        System.
+      </p>
+</div>
+<div class="sect1" lang="en">
+<div class="titlepage"><div><div><h2 class="title" style="clear: both">
+<a name="id2563474"></a>Conventions Used in This Document</h2></div></div></div>
+<p>
+        In this document, we use the following general typographic
+        conventions:
+      </p>
+<div class="informaltable"><table border="1">
+<colgroup>
+<col>
+<col>
+</colgroup>
+<tbody>
+<tr>
+<td>
+                <p>
+                  <span class="emphasis"><em>To describe:</em></span>
+                </p>
+              </td>
+<td>
+                <p>
+                  <span class="emphasis"><em>We use the style:</em></span>
+                </p>
+              </td>
+</tr>
+<tr>
+<td>
+                <p>
+                  a pathname, filename, URL, hostname,
+                  mailing list name, or new term or concept
+                </p>
+              </td>
+<td>
+                <p>
+                  <code class="filename">Fixed width</code>
+                </p>
+              </td>
+</tr>
+<tr>
+<td>
+                <p>
+                  literal user
+                  input
+                </p>
+              </td>
+<td>
+                <p>
+                  <strong class="userinput"><code>Fixed Width Bold</code></strong>
+                </p>
+              </td>
+</tr>
+<tr>
+<td>
+                <p>
+                  program output
+                </p>
+              </td>
+<td>
+                <p>
+                  <code class="computeroutput">Fixed Width</code>
+                </p>
+              </td>
+</tr>
+</tbody>
+</table></div>
+<p>
+        The following conventions are used in descriptions of the
+        <acronym class="acronym">BIND</acronym> configuration file:</p>
+<div class="informaltable"><table border="1">
+<colgroup>
+<col>
+<col>
+</colgroup>
+<tbody>
+<tr>
+<td>
+                  <p>
+                    <span class="emphasis"><em>To describe:</em></span>
+                  </p>
+                </td>
+<td>
+                  <p>
+                    <span class="emphasis"><em>We use the style:</em></span>
+                  </p>
+                </td>
+</tr>
+<tr>
+<td>
+                  <p>
+                    keywords
+                  </p>
+                </td>
+<td>
+                  <p>
+                    <code class="literal">Fixed Width</code>
+                  </p>
+                </td>
+</tr>
+<tr>
+<td>
+                  <p>
+                    variables
+                  </p>
+                </td>
+<td>
+                  <p>
+                    <code class="varname">Fixed Width</code>
+                  </p>
+                </td>
+</tr>
+<tr>
+<td>
+                  <p>
+                    Optional input
+                  </p>
+                </td>
+<td>
+                  <p>
+                    [<span class="optional">Text is enclosed in square brackets</span>]
+                  </p>
+                </td>
+</tr>
+</tbody>
+</table></div>
+<p>
+      </p>
+</div>
+<div class="sect1" lang="en">
+<div class="titlepage"><div><div><h2 class="title" style="clear: both">
+<a name="id2564816"></a>The Domain Name System (<acronym class="acronym">DNS</acronym>)</h2></div></div></div>
+<p>
+        The purpose of this document is to explain the installation
+        and upkeep of the <acronym class="acronym">BIND</acronym> (Berkeley Internet
+        Name Domain) software package, and we
+        begin by reviewing the fundamentals of the Domain Name System
+        (<acronym class="acronym">DNS</acronym>) as they relate to <acronym class="acronym">BIND</acronym>.
+      </p>
+<div class="sect2" lang="en">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="id2564837"></a>DNS Fundamentals</h3></div></div></div>
+<p>
+          The Domain Name System (DNS) is a hierarchical, distributed
+          database.  It stores information for mapping Internet host names to
+          IP
+          addresses and vice versa, mail routing information, and other data
+          used by Internet applications.
+        </p>
+<p>
+          Clients look up information in the DNS by calling a
+          <span class="emphasis"><em>resolver</em></span> library, which sends queries to one or
+          more <span class="emphasis"><em>name servers</em></span> and interprets the responses.
+          The <acronym class="acronym">BIND</acronym> 9 software distribution
+          contains a
+          name server, <span><strong class="command">named</strong></span>, and two resolver
+          libraries, <span><strong class="command">liblwres</strong></span> and <span><strong class="command">libbind</strong></span>.
+        </p>
+</div>
+<div class="sect2" lang="en">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="id2564871"></a>Domains and Domain Names</h3></div></div></div>
+<p>
+          The data stored in the DNS is identified by <span class="emphasis"><em>domain names</em></span> that are organized as a tree according to
+          organizational or administrative boundaries. Each node of the tree,
+          called a <span class="emphasis"><em>domain</em></span>, is given a label. The domain
+          name of the
+          node is the concatenation of all the labels on the path from the
+          node to the <span class="emphasis"><em>root</em></span> node.  This is represented
+          in written form as a string of labels listed from right to left and
+          separated by dots. A label need only be unique within its parent
+          domain.
+        </p>
+<p>
+          For example, a domain name for a host at the
+          company <span class="emphasis"><em>Example, Inc.</em></span> could be
+          <code class="literal">ourhost.example.com</code>,
+          where <code class="literal">com</code> is the
+          top level domain to which
+          <code class="literal">ourhost.example.com</code> belongs,
+          <code class="literal">example</code> is
+          a subdomain of <code class="literal">com</code>, and
+          <code class="literal">ourhost</code> is the
+          name of the host.
+        </p>
+<p>
+          For administrative purposes, the name space is partitioned into
+          areas called <span class="emphasis"><em>zones</em></span>, each starting at a node and
+          extending down to the leaf nodes or to nodes where other zones
+          start.
+          The data for each zone is stored in a <span class="emphasis"><em>name server</em></span>, which answers queries about the zone using the
+          <span class="emphasis"><em>DNS protocol</em></span>.
+        </p>
+<p>
+          The data associated with each domain name is stored in the
+          form of <span class="emphasis"><em>resource records</em></span> (<acronym class="acronym">RR</acronym>s).
+          Some of the supported resource record types are described in
+          <a href="Bv9ARM.ch06.html#types_of_resource_records_and_when_to_use_them" title="Types of Resource Records and When to Use Them">the section called &#8220;Types of Resource Records and When to Use Them&#8221;</a>.
+        </p>
+<p>
+          For more detailed information about the design of the DNS and
+          the DNS protocol, please refer to the standards documents listed in
+          <a href="Bv9ARM.ch09.html#rfcs" title="Request for Comments (RFCs)">the section called &#8220;Request for Comments (RFCs)&#8221;</a>.
+        </p>
+</div>
+<div class="sect2" lang="en">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="id2567208"></a>Zones</h3></div></div></div>
+<p>
+          To properly operate a name server, it is important to understand
+          the difference between a <span class="emphasis"><em>zone</em></span>
+          and a <span class="emphasis"><em>domain</em></span>.
+        </p>
+<p>
+          As stated previously, a zone is a point of delegation in
+          the <acronym class="acronym">DNS</acronym> tree. A zone consists of
+          those contiguous parts of the domain
+          tree for which a name server has complete information and over which
+          it has authority. It contains all domain names from a certain point
+          downward in the domain tree except those which are delegated to
+          other zones. A delegation point is marked by one or more
+          <span class="emphasis"><em>NS records</em></span> in the
+          parent zone, which should be matched by equivalent NS records at
+          the root of the delegated zone.
+        </p>
+<p>
+          For instance, consider the <code class="literal">example.com</code>
+          domain which includes names
+          such as <code class="literal">host.aaa.example.com</code> and
+          <code class="literal">host.bbb.example.com</code> even though
+          the <code class="literal">example.com</code> zone includes
+          only delegations for the <code class="literal">aaa.example.com</code> and
+          <code class="literal">bbb.example.com</code> zones.  A zone can
+          map
+          exactly to a single domain, but could also include only part of a
+          domain, the rest of which could be delegated to other
+          name servers. Every name in the <acronym class="acronym">DNS</acronym>
+          tree is a
+          <span class="emphasis"><em>domain</em></span>, even if it is
+          <span class="emphasis"><em>terminal</em></span>, that is, has no
+          <span class="emphasis"><em>subdomains</em></span>.  Every subdomain is a domain and
+          every domain except the root is also a subdomain. The terminology is
+          not intuitive and we suggest that you read RFCs 1033, 1034 and 1035
+          to
+          gain a complete understanding of this difficult and subtle
+          topic.
+        </p>
+<p>
+          Though <acronym class="acronym">BIND</acronym> is called a "domain name
+          server",
+          it deals primarily in terms of zones. The master and slave
+          declarations in the <code class="filename">named.conf</code> file
+          specify
+          zones, not domains. When you ask some other site if it is willing to
+          be a slave server for your <span class="emphasis"><em>domain</em></span>, you are
+          actually asking for slave service for some collection of zones.
+        </p>
+</div>
+<div class="sect2" lang="en">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="id2567285"></a>Authoritative Name Servers</h3></div></div></div>
+<p>
+          Each zone is served by at least
+          one <span class="emphasis"><em>authoritative name server</em></span>,
+          which contains the complete data for the zone.
+          To make the DNS tolerant of server and network failures,
+          most zones have two or more authoritative servers, on
+          different networks.
+        </p>
+<p>
+          Responses from authoritative servers have the "authoritative
+          answer" (AA) bit set in the response packets.  This makes them
+          easy to identify when debugging DNS configurations using tools like
+          <span><strong class="command">dig</strong></span> (<a href="Bv9ARM.ch03.html#diagnostic_tools" title="Diagnostic Tools">the section called &#8220;Diagnostic Tools&#8221;</a>).
+        </p>
+<div class="sect3" lang="en">
+<div class="titlepage"><div><div><h4 class="title">
+<a name="id2567308"></a>The Primary Master</h4></div></div></div>
+<p>
+            The authoritative server where the master copy of the zone
+            data is maintained is called the
+            <span class="emphasis"><em>primary master</em></span> server, or simply the
+            <span class="emphasis"><em>primary</em></span>.  Typically it loads the zone
+            contents from some local file edited by humans or perhaps
+            generated mechanically from some other local file which is
+            edited by humans.  This file is called the
+            <span class="emphasis"><em>zone file</em></span> or
+            <span class="emphasis"><em>master file</em></span>.
+          </p>
+<p>
+            In some cases, however, the master file may not be edited
+            by humans at all, but may instead be the result of
+            <span class="emphasis"><em>dynamic update</em></span> operations.
+          </p>
+</div>
+<div class="sect3" lang="en">
+<div class="titlepage"><div><div><h4 class="title">
+<a name="id2567338"></a>Slave Servers</h4></div></div></div>
+<p>
+            The other authoritative servers, the <span class="emphasis"><em>slave</em></span>
+            servers (also known as <span class="emphasis"><em>secondary</em></span> servers)
+            load
+            the zone contents from another server using a replication process
+            known as a <span class="emphasis"><em>zone transfer</em></span>.  Typically the data
+            are
+            transferred directly from the primary master, but it is also
+            possible
+            to transfer it from another slave.  In other words, a slave server
+            may itself act as a master to a subordinate slave server.
+          </p>
+</div>
+<div class="sect3" lang="en">
+<div class="titlepage"><div><div><h4 class="title">
+<a name="id2567360"></a>Stealth Servers</h4></div></div></div>
+<p>
+            Usually all of the zone's authoritative servers are listed in
+            NS records in the parent zone.  These NS records constitute
+            a <span class="emphasis"><em>delegation</em></span> of the zone from the parent.
+            The authoritative servers are also listed in the zone file itself,
+            at the <span class="emphasis"><em>top level</em></span> or <span class="emphasis"><em>apex</em></span>
+            of the zone.  You can list servers in the zone's top-level NS
+            records that are not in the parent's NS delegation, but you cannot
+            list servers in the parent's delegation that are not present at
+            the zone's top level.
+          </p>
+<p>
+            A <span class="emphasis"><em>stealth server</em></span> is a server that is
+            authoritative for a zone but is not listed in that zone's NS
+            records.  Stealth servers can be used for keeping a local copy of
+            a
+            zone to speed up access to the zone's records or to make sure that
+            the
+            zone is available even if all the "official" servers for the zone
+            are
+            inaccessible.
+          </p>
+<p>
+            A configuration where the primary master server itself is a
+            stealth server is often referred to as a "hidden primary"
+            configuration.  One use for this configuration is when the primary
+            master
+            is behind a firewall and therefore unable to communicate directly
+            with the outside world.
+          </p>
+</div>
+</div>
+<div class="sect2" lang="en">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="id2567526"></a>Caching Name Servers</h3></div></div></div>
+<p>
+          The resolver libraries provided by most operating systems are
+          <span class="emphasis"><em>stub resolvers</em></span>, meaning that they are not
+          capable of
+          performing the full DNS resolution process by themselves by talking
+          directly to the authoritative servers.  Instead, they rely on a
+          local
+          name server to perform the resolution on their behalf.  Such a
+          server
+          is called a <span class="emphasis"><em>recursive</em></span> name server; it performs
+          <span class="emphasis"><em>recursive lookups</em></span> for local clients.
+        </p>
+<p>
+          To improve performance, recursive servers cache the results of
+          the lookups they perform.  Since the processes of recursion and
+          caching are intimately connected, the terms
+          <span class="emphasis"><em>recursive server</em></span> and
+          <span class="emphasis"><em>caching server</em></span> are often used synonymously.
+        </p>
+<p>
+          The length of time for which a record may be retained in
+          the cache of a caching name server is controlled by the
+          Time To Live (TTL) field associated with each resource record.
+        </p>
+<div class="sect3" lang="en">
+<div class="titlepage"><div><div><h4 class="title">
+<a name="id2567561"></a>Forwarding</h4></div></div></div>
+<p>
+            Even a caching name server does not necessarily perform
+            the complete recursive lookup itself.  Instead, it can
+            <span class="emphasis"><em>forward</em></span> some or all of the queries
+            that it cannot satisfy from its cache to another caching name
+            server,
+            commonly referred to as a <span class="emphasis"><em>forwarder</em></span>.
+          </p>
+<p>
+            There may be one or more forwarders,
+            and they are queried in turn until the list is exhausted or an
+            answer
+            is found. Forwarders are typically used when you do not
+            wish all the servers at a given site to interact directly with the
+            rest of
+            the Internet servers. A typical scenario would involve a number
+            of internal <acronym class="acronym">DNS</acronym> servers and an
+            Internet firewall. Servers unable
+            to pass packets through the firewall would forward to the server
+            that can do it, and that server would query the Internet <acronym class="acronym">DNS</acronym> servers
+            on the internal server's behalf.
+          </p>
+</div>
+</div>
+<div class="sect2" lang="en">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="id2567588"></a>Name Servers in Multiple Roles</h3></div></div></div>
+<p>
+          The <acronym class="acronym">BIND</acronym> name server can
+          simultaneously act as
+          a master for some zones, a slave for other zones, and as a caching
+          (recursive) server for a set of local clients.
+        </p>
+<p>
+          However, since the functions of authoritative name service
+          and caching/recursive name service are logically separate, it is
+          often advantageous to run them on separate server machines.
+
+          A server that only provides authoritative name service
+          (an <span class="emphasis"><em>authoritative-only</em></span> server) can run with
+          recursion disabled, improving reliability and security.
+
+          A server that is not authoritative for any zones and only provides
+          recursive service to local
+          clients (a <span class="emphasis"><em>caching-only</em></span> server)
+          does not need to be reachable from the Internet at large and can
+          be placed inside a firewall.
+        </p>
+</div>
+</div>
+</div>
+<div class="navfooter">
+<hr>
+<table width="100%" summary="Navigation footer">
+<tr>
+<td width="40%" align="left">
+<a accesskey="p" href="Bv9ARM.html">Prev</a> </td>
+<td width="20%" align="center"> </td>
+<td width="40%" align="right"> <a accesskey="n" href="Bv9ARM.ch02.html">Next</a>
+</td>
+</tr>
+<tr>
+<td width="40%" align="left" valign="top">BIND 9 Administrator Reference Manual </td>
+<td width="20%" align="center"><a accesskey="h" href="Bv9ARM.html">Home</a></td>
+<td width="40%" align="right" valign="top"> Chapter 2. <acronym class="acronym">BIND</acronym> Resource Requirements</td>
+</tr>
+</table>
+</div>
+</body>
+</html>
diff --git a/doc/arm/Bv9ARM.ch02.html b/doc/arm/Bv9ARM.ch02.html
new file mode 100644
index 0000000..cbf6c15
--- /dev/null
+++ b/doc/arm/Bv9ARM.ch02.html
@@ -0,0 +1,158 @@
+<!--
+ - Copyright (C) 2004-2007 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2000-2003 Internet Software Consortium.
+ - 
+ - Permission to use, copy, modify, and distribute this software for any
+ - purpose with or without fee is hereby granted, provided that the above
+ - copyright notice and this permission notice appear in all copies.
+ - 
+ - THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
+ - REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
+ - AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
+ - INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
+ - LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
+ - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
+ - PERFORMANCE OF THIS SOFTWARE.
+-->
+<!-- $Id: Bv9ARM.ch02.html,v 1.13.18.21 2007/10/31 01:35:57 marka Exp $ -->
+<html>
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
+<title>Chapter 2. BIND Resource Requirements</title>
+<meta name="generator" content="DocBook XSL Stylesheets V1.71.1">
+<link rel="start" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual">
+<link rel="up" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual">
+<link rel="prev" href="Bv9ARM.ch01.html" title="Chapter 1. Introduction">
+<link rel="next" href="Bv9ARM.ch03.html" title="Chapter 3. Name Server Configuration">
+</head>
+<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
+<div class="navheader">
+<table width="100%" summary="Navigation header">
+<tr><th colspan="3" align="center">Chapter 2. <acronym class="acronym">BIND</acronym> Resource Requirements</th></tr>
+<tr>
+<td width="20%" align="left">
+<a accesskey="p" href="Bv9ARM.ch01.html">Prev</a> </td>
+<th width="60%" align="center"> </th>
+<td width="20%" align="right"> <a accesskey="n" href="Bv9ARM.ch03.html">Next</a>
+</td>
+</tr>
+</table>
+<hr>
+</div>
+<div class="chapter" lang="en">
+<div class="titlepage"><div><div><h2 class="title">
+<a name="Bv9ARM.ch02"></a>Chapter 2. <acronym class="acronym">BIND</acronym> Resource Requirements</h2></div></div></div>
+<div class="toc">
+<p><b>Table of Contents</b></p>
+<dl>
+<dt><span class="sect1"><a href="Bv9ARM.ch02.html#id2567622">Hardware requirements</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch02.html#id2567649">CPU Requirements</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch02.html#id2567661">Memory Requirements</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch02.html#id2567688">Name Server Intensive Environment Issues</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch02.html#id2567699">Supported Operating Systems</a></span></dt>
+</dl>
+</div>
+<div class="sect1" lang="en">
+<div class="titlepage"><div><div><h2 class="title" style="clear: both">
+<a name="id2567622"></a>Hardware requirements</h2></div></div></div>
+<p>
+        <acronym class="acronym">DNS</acronym> hardware requirements have
+        traditionally been quite modest.
+        For many installations, servers that have been pensioned off from
+        active duty have performed admirably as <acronym class="acronym">DNS</acronym> servers.
+      </p>
+<p>
+        The DNSSEC features of <acronym class="acronym">BIND</acronym> 9
+        may prove to be quite
+        CPU intensive however, so organizations that make heavy use of these
+        features may wish to consider larger systems for these applications.
+        <acronym class="acronym">BIND</acronym> 9 is fully multithreaded, allowing
+        full utilization of
+        multiprocessor systems for installations that need it.
+      </p>
+</div>
+<div class="sect1" lang="en">
+<div class="titlepage"><div><div><h2 class="title" style="clear: both">
+<a name="id2567649"></a>CPU Requirements</h2></div></div></div>
+<p>
+        CPU requirements for <acronym class="acronym">BIND</acronym> 9 range from
+        i486-class machines
+        for serving of static zones without caching, to enterprise-class
+        machines if you intend to process many dynamic updates and DNSSEC
+        signed zones, serving many thousands of queries per second.
+      </p>
+</div>
+<div class="sect1" lang="en">
+<div class="titlepage"><div><div><h2 class="title" style="clear: both">
+<a name="id2567661"></a>Memory Requirements</h2></div></div></div>
+<p>
+        The memory of the server has to be large enough to fit the
+        cache and zones loaded off disk.  The <span><strong class="command">max-cache-size</strong></span>
+        option can be used to limit the amount of memory used by the cache,
+        at the expense of reducing cache hit rates and causing more <acronym class="acronym">DNS</acronym>
+        traffic.
+        Additionally, if additional section caching
+        (<a href="Bv9ARM.ch06.html#acache" title="Additional Section Caching">the section called &#8220;Additional Section Caching&#8221;</a>) is enabled,
+        the <span><strong class="command">max-acache-size</strong></span> option can be used to
+        limit the amount
+        of memory used by the mechanism.
+        It is still good practice to have enough memory to load
+        all zone and cache data into memory &#8212; unfortunately, the best
+        way
+        to determine this for a given installation is to watch the name server
+        in operation. After a few weeks the server process should reach
+        a relatively stable size where entries are expiring from the cache as
+        fast as they are being inserted.
+      </p>
+</div>
+<div class="sect1" lang="en">
+<div class="titlepage"><div><div><h2 class="title" style="clear: both">
+<a name="id2567688"></a>Name Server Intensive Environment Issues</h2></div></div></div>
+<p>
+        For name server intensive environments, there are two alternative
+        configurations that may be used. The first is where clients and
+        any second-level internal name servers query a main name server, which
+        has enough memory to build a large cache. This approach minimizes
+        the bandwidth used by external name lookups. The second alternative
+        is to set up second-level internal name servers to make queries
+        independently.
+        In this configuration, none of the individual machines needs to
+        have as much memory or CPU power as in the first alternative, but
+        this has the disadvantage of making many more external queries,
+        as none of the name servers share their cached data.
+      </p>
+</div>
+<div class="sect1" lang="en">
+<div class="titlepage"><div><div><h2 class="title" style="clear: both">
+<a name="id2567699"></a>Supported Operating Systems</h2></div></div></div>
+<p>
+        ISC <acronym class="acronym">BIND</acronym> 9 compiles and runs on a large
+        number
+        of Unix-like operating system and on NT-derived versions of
+        Microsoft Windows such as Windows 2000 and Windows XP.  For an
+        up-to-date
+        list of supported systems, see the README file in the top level
+        directory
+        of the BIND 9 source distribution.
+      </p>
+</div>
+</div>
+<div class="navfooter">
+<hr>
+<table width="100%" summary="Navigation footer">
+<tr>
+<td width="40%" align="left">
+<a accesskey="p" href="Bv9ARM.ch01.html">Prev</a> </td>
+<td width="20%" align="center"> </td>
+<td width="40%" align="right"> <a accesskey="n" href="Bv9ARM.ch03.html">Next</a>
+</td>
+</tr>
+<tr>
+<td width="40%" align="left" valign="top">Chapter 1. Introduction </td>
+<td width="20%" align="center"><a accesskey="h" href="Bv9ARM.html">Home</a></td>
+<td width="40%" align="right" valign="top"> Chapter 3. Name Server Configuration</td>
+</tr>
+</table>
+</div>
+</body>
+</html>
diff --git a/doc/arm/Bv9ARM.ch03.html b/doc/arm/Bv9ARM.ch03.html
new file mode 100644
index 0000000..18f2711
--- /dev/null
+++ b/doc/arm/Bv9ARM.ch03.html
@@ -0,0 +1,808 @@
+<!--
+ - Copyright (C) 2004-2007 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2000-2003 Internet Software Consortium.
+ - 
+ - Permission to use, copy, modify, and distribute this software for any
+ - purpose with or without fee is hereby granted, provided that the above
+ - copyright notice and this permission notice appear in all copies.
+ - 
+ - THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
+ - REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
+ - AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
+ - INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
+ - LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
+ - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
+ - PERFORMANCE OF THIS SOFTWARE.
+-->
+<!-- $Id: Bv9ARM.ch03.html,v 1.35.18.31 2007/10/31 01:35:57 marka Exp $ -->
+<html>
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
+<title>Chapter 3. Name Server Configuration</title>
+<meta name="generator" content="DocBook XSL Stylesheets V1.71.1">
+<link rel="start" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual">
+<link rel="up" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual">
+<link rel="prev" href="Bv9ARM.ch02.html" title="Chapter 2. BIND Resource Requirements">
+<link rel="next" href="Bv9ARM.ch04.html" title="Chapter 4. Advanced DNS Features">
+</head>
+<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
+<div class="navheader">
+<table width="100%" summary="Navigation header">
+<tr><th colspan="3" align="center">Chapter 3. Name Server Configuration</th></tr>
+<tr>
+<td width="20%" align="left">
+<a accesskey="p" href="Bv9ARM.ch02.html">Prev</a> </td>
+<th width="60%" align="center"> </th>
+<td width="20%" align="right"> <a accesskey="n" href="Bv9ARM.ch04.html">Next</a>
+</td>
+</tr>
+</table>
+<hr>
+</div>
+<div class="chapter" lang="en">
+<div class="titlepage"><div><div><h2 class="title">
+<a name="Bv9ARM.ch03"></a>Chapter 3. Name Server Configuration</h2></div></div></div>
+<div class="toc">
+<p><b>Table of Contents</b></p>
+<dl>
+<dt><span class="sect1"><a href="Bv9ARM.ch03.html#sample_configuration">Sample Configurations</a></span></dt>
+<dd><dl>
+<dt><span class="sect2"><a href="Bv9ARM.ch03.html#id2568004">A Caching-only Name Server</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch03.html#id2568020">An Authoritative-only Name Server</a></span></dt>
+</dl></dd>
+<dt><span class="sect1"><a href="Bv9ARM.ch03.html#id2568042">Load Balancing</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch03.html#id2568465">Name Server Operations</a></span></dt>
+<dd><dl>
+<dt><span class="sect2"><a href="Bv9ARM.ch03.html#id2568470">Tools for Use With the Name Server Daemon</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch03.html#id2570184">Signals</a></span></dt>
+</dl></dd>
+</dl>
+</div>
+<p>
+      In this section we provide some suggested configurations along
+      with guidelines for their use.  We suggest reasonable values for
+      certain option settings.
+    </p>
+<div class="sect1" lang="en">
+<div class="titlepage"><div><div><h2 class="title" style="clear: both">
+<a name="sample_configuration"></a>Sample Configurations</h2></div></div></div>
+<div class="sect2" lang="en">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="id2568004"></a>A Caching-only Name Server</h3></div></div></div>
+<p>
+          The following sample configuration is appropriate for a caching-only
+          name server for use by clients internal to a corporation.  All
+          queries
+          from outside clients are refused using the <span><strong class="command">allow-query</strong></span>
+          option.  Alternatively, the same effect could be achieved using
+          suitable
+          firewall rules.
+        </p>
+<pre class="programlisting">
+// Two corporate subnets we wish to allow queries from.
+acl corpnets { 192.168.4.0/24; 192.168.7.0/24; };
+options {
+     directory "/etc/namedb";           // Working directory
+     allow-query { corpnets; };
+};
+// Provide a reverse mapping for the loopback address 127.0.0.1
+zone "0.0.127.in-addr.arpa" {
+     type master;
+     file "localhost.rev";
+     notify no;
+};
+</pre>
+</div>
+<div class="sect2" lang="en">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="id2568020"></a>An Authoritative-only Name Server</h3></div></div></div>
+<p>
+          This sample configuration is for an authoritative-only server
+          that is the master server for "<code class="filename">example.com</code>"
+          and a slave for the subdomain "<code class="filename">eng.example.com</code>".
+        </p>
+<pre class="programlisting">
+options {
+     directory "/etc/namedb";           // Working directory
+     allow-query-cache { none; };       // Do not allow access to cache
+     allow-query { any; };              // This is the default
+     recursion no;                      // Do not provide recursive service
+};
+
+// Provide a reverse mapping for the loopback address 127.0.0.1
+zone "0.0.127.in-addr.arpa" {
+     type master;
+     file "localhost.rev";
+     notify no;
+};
+// We are the master server for example.com
+zone "example.com" {
+     type master;
+     file "example.com.db";
+     // IP addresses of slave servers allowed to transfer example.com
+     allow-transfer {
+          192.168.4.14;
+          192.168.5.53;
+     };
+};
+// We are a slave server for eng.example.com
+zone "eng.example.com" {
+     type slave;
+     file "eng.example.com.bk";
+     // IP address of eng.example.com master server
+     masters { 192.168.4.12; };
+};
+</pre>
+</div>
+</div>
+<div class="sect1" lang="en">
+<div class="titlepage"><div><div><h2 class="title" style="clear: both">
+<a name="id2568042"></a>Load Balancing</h2></div></div></div>
+<p>
+        A primitive form of load balancing can be achieved in
+        the <acronym class="acronym">DNS</acronym> by using multiple records
+        (such as multiple A records) for one name.
+      </p>
+<p>
+        For example, if you have three WWW servers with network addresses
+        of 10.0.0.1, 10.0.0.2 and 10.0.0.3, a set of records such as the
+        following means that clients will connect to each machine one third
+        of the time:
+      </p>
+<div class="informaltable"><table border="1">
+<colgroup>
+<col>
+<col>
+<col>
+<col>
+<col>
+</colgroup>
+<tbody>
+<tr>
+<td>
+                <p>
+                  Name
+                </p>
+              </td>
+<td>
+                <p>
+                  TTL
+                </p>
+              </td>
+<td>
+                <p>
+                  CLASS
+                </p>
+              </td>
+<td>
+                <p>
+                  TYPE
+                </p>
+              </td>
+<td>
+                <p>
+                  Resource Record (RR) Data
+                </p>
+              </td>
+</tr>
+<tr>
+<td>
+                <p>
+                  <code class="literal">www</code>
+                </p>
+              </td>
+<td>
+                <p>
+                  <code class="literal">600</code>
+                </p>
+              </td>
+<td>
+                <p>
+                  <code class="literal">IN</code>
+                </p>
+              </td>
+<td>
+                <p>
+                  <code class="literal">A</code>
+                </p>
+              </td>
+<td>
+                <p>
+                  <code class="literal">10.0.0.1</code>
+                </p>
+              </td>
+</tr>
+<tr>
+<td>
+                <p></p>
+              </td>
+<td>
+                <p>
+                  <code class="literal">600</code>
+                </p>
+              </td>
+<td>
+                <p>
+                  <code class="literal">IN</code>
+                </p>
+              </td>
+<td>
+                <p>
+                  <code class="literal">A</code>
+                </p>
+              </td>
+<td>
+                <p>
+                  <code class="literal">10.0.0.2</code>
+                </p>
+              </td>
+</tr>
+<tr>
+<td>
+                <p></p>
+              </td>
+<td>
+                <p>
+                  <code class="literal">600</code>
+                </p>
+              </td>
+<td>
+                <p>
+                  <code class="literal">IN</code>
+                </p>
+              </td>
+<td>
+                <p>
+                  <code class="literal">A</code>
+                </p>
+              </td>
+<td>
+                <p>
+                  <code class="literal">10.0.0.3</code>
+                </p>
+              </td>
+</tr>
+</tbody>
+</table></div>
+<p>
+        When a resolver queries for these records, <acronym class="acronym">BIND</acronym> will rotate
+        them and respond to the query with the records in a different
+        order.  In the example above, clients will randomly receive
+        records in the order 1, 2, 3; 2, 3, 1; and 3, 1, 2. Most clients
+        will use the first record returned and discard the rest.
+      </p>
+<p>
+        For more detail on ordering responses, check the
+        <span><strong class="command">rrset-order</strong></span> substatement in the
+        <span><strong class="command">options</strong></span> statement, see
+        <a href="Bv9ARM.ch06.html#rrset_ordering">RRset Ordering</a>.
+      </p>
+</div>
+<div class="sect1" lang="en">
+<div class="titlepage"><div><div><h2 class="title" style="clear: both">
+<a name="id2568465"></a>Name Server Operations</h2></div></div></div>
+<div class="sect2" lang="en">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="id2568470"></a>Tools for Use With the Name Server Daemon</h3></div></div></div>
+<p>
+          This section describes several indispensable diagnostic,
+          administrative and monitoring tools available to the system
+          administrator for controlling and debugging the name server
+          daemon.
+        </p>
+<div class="sect3" lang="en">
+<div class="titlepage"><div><div><h4 class="title">
+<a name="diagnostic_tools"></a>Diagnostic Tools</h4></div></div></div>
+<p>
+            The <span><strong class="command">dig</strong></span>, <span><strong class="command">host</strong></span>, and
+            <span><strong class="command">nslookup</strong></span> programs are all command
+            line tools
+            for manually querying name servers.  They differ in style and
+            output format.
+          </p>
+<div class="variablelist"><dl>
+<dt><span class="term"><a name="dig"></a><span><strong class="command">dig</strong></span></span></dt>
+<dd>
+<p>
+                  The domain information groper (<span><strong class="command">dig</strong></span>)
+                  is the most versatile and complete of these lookup tools.
+                  It has two modes: simple interactive
+                  mode for a single query, and batch mode which executes a
+                  query for
+                  each in a list of several query lines. All query options are
+                  accessible
+                  from the command line.
+                </p>
+<div class="cmdsynopsis"><p><code class="command">dig</code>  [@<em class="replaceable"><code>server</code></em>]  <em class="replaceable"><code>domain</code></em>  [<em class="replaceable"><code>query-type</code></em>] [<em class="replaceable"><code>query-class</code></em>] [+<em class="replaceable"><code>query-option</code></em>] [-<em class="replaceable"><code>dig-option</code></em>] [%<em class="replaceable"><code>comment</code></em>]</p></div>
+<p>
+                  The usual simple use of dig will take the form
+                </p>
+<p>
+                  <span><strong class="command">dig @server domain query-type query-class</strong></span>
+                </p>
+<p>
+                  For more information and a list of available commands and
+                  options, see the <span><strong class="command">dig</strong></span> man
+                  page.
+                </p>
+</dd>
+<dt><span class="term"><span><strong class="command">host</strong></span></span></dt>
+<dd>
+<p>
+                  The <span><strong class="command">host</strong></span> utility emphasizes
+                  simplicity
+                  and ease of use.  By default, it converts
+                  between host names and Internet addresses, but its
+                  functionality
+                  can be extended with the use of options.
+                </p>
+<div class="cmdsynopsis"><p><code class="command">host</code>  [-aCdlnrsTwv] [-c <em class="replaceable"><code>class</code></em>] [-N <em class="replaceable"><code>ndots</code></em>] [-t <em class="replaceable"><code>type</code></em>] [-W <em class="replaceable"><code>timeout</code></em>] [-R <em class="replaceable"><code>retries</code></em>] [-m <em class="replaceable"><code>flag</code></em>] [-4] [-6]  <em class="replaceable"><code>hostname</code></em>  [<em class="replaceable"><code>server</code></em>]</p></div>
+<p>
+                  For more information and a list of available commands and
+                  options, see the <span><strong class="command">host</strong></span> man
+                  page.
+                </p>
+</dd>
+<dt><span class="term"><span><strong class="command">nslookup</strong></span></span></dt>
+<dd>
+<p><span><strong class="command">nslookup</strong></span>
+                  has two modes: interactive and
+                  non-interactive. Interactive mode allows the user to
+                  query name servers for information about various
+                  hosts and domains or to print a list of hosts in a
+                  domain. Non-interactive mode is used to print just
+                  the name and requested information for a host or
+                  domain.
+                </p>
+<div class="cmdsynopsis"><p><code class="command">nslookup</code>  [-option...] [[<em class="replaceable"><code>host-to-find</code></em>] |  [- [server]]]</p></div>
+<p>
+                  Interactive mode is entered when no arguments are given (the
+                  default name server will be used) or when the first argument
+                  is a
+                  hyphen (`-') and the second argument is the host name or
+                  Internet address
+                  of a name server.
+                </p>
+<p>
+                  Non-interactive mode is used when the name or Internet
+                  address
+                  of the host to be looked up is given as the first argument.
+                  The
+                  optional second argument specifies the host name or address
+                  of a name server.
+                </p>
+<p>
+                  Due to its arcane user interface and frequently inconsistent
+                  behavior, we do not recommend the use of <span><strong class="command">nslookup</strong></span>.
+                  Use <span><strong class="command">dig</strong></span> instead.
+                </p>
+</dd>
+</dl></div>
+</div>
+<div class="sect3" lang="en">
+<div class="titlepage"><div><div><h4 class="title">
+<a name="admin_tools"></a>Administrative Tools</h4></div></div></div>
+<p>
+            Administrative tools play an integral part in the management
+            of a server.
+          </p>
+<div class="variablelist"><dl>
+<dt>
+<a name="named-checkconf"></a><span class="term"><span><strong class="command">named-checkconf</strong></span></span>
+</dt>
+<dd>
+<p>
+                  The <span><strong class="command">named-checkconf</strong></span> program
+                  checks the syntax of a <code class="filename">named.conf</code> file.
+                </p>
+<div class="cmdsynopsis"><p><code class="command">named-checkconf</code>  [-jvz] [-t <em class="replaceable"><code>directory</code></em>] [<em class="replaceable"><code>filename</code></em>]</p></div>
+</dd>
+<dt>
+<a name="named-checkzone"></a><span class="term"><span><strong class="command">named-checkzone</strong></span></span>
+</dt>
+<dd>
+<p>
+                  The <span><strong class="command">named-checkzone</strong></span> program
+                  checks a master file for
+                  syntax and consistency.
+                </p>
+<div class="cmdsynopsis"><p><code class="command">named-checkzone</code>  [-djqvD] [-c <em class="replaceable"><code>class</code></em>] [-o <em class="replaceable"><code>output</code></em>] [-t <em class="replaceable"><code>directory</code></em>] [-w <em class="replaceable"><code>directory</code></em>] [-k <em class="replaceable"><code>(ignore|warn|fail)</code></em>] [-n <em class="replaceable"><code>(ignore|warn|fail)</code></em>] [-W <em class="replaceable"><code>(ignore|warn)</code></em>]  <em class="replaceable"><code>zone</code></em>  [<em class="replaceable"><code>filename</code></em>]</p></div>
+</dd>
+<dt>
+<a name="named-compilezone"></a><span class="term"><span><strong class="command">named-compilezone</strong></span></span>
+</dt>
+<dd><p>
+                  Similar to <span><strong class="command">named-checkzone,</strong></span> but
+                  it always dumps the zone content to a specified file
+                  (typically in a different format).
+                </p></dd>
+<dt>
+<a name="rndc"></a><span class="term"><span><strong class="command">rndc</strong></span></span>
+</dt>
+<dd>
+<p>
+                  The remote name daemon control
+                  (<span><strong class="command">rndc</strong></span>) program allows the
+                  system
+                  administrator to control the operation of a name server.
+                  Since <acronym class="acronym">BIND</acronym> 9.2, <span><strong class="command">rndc</strong></span>
+                  supports all the commands of the BIND 8 <span><strong class="command">ndc</strong></span>
+                  utility except <span><strong class="command">ndc start</strong></span> and
+                  <span><strong class="command">ndc restart</strong></span>, which were also
+                  not supported in <span><strong class="command">ndc</strong></span>'s
+                  channel mode.
+                  If you run <span><strong class="command">rndc</strong></span> without any
+                  options
+                  it will display a usage message as follows:
+                </p>
+<div class="cmdsynopsis"><p><code class="command">rndc</code>  [-c <em class="replaceable"><code>config</code></em>] [-s <em class="replaceable"><code>server</code></em>] [-p <em class="replaceable"><code>port</code></em>] [-y <em class="replaceable"><code>key</code></em>]  <em class="replaceable"><code>command</code></em>  [<em class="replaceable"><code>command</code></em>...]</p></div>
+<p>The <span><strong class="command">command</strong></span>
+                  is one of the following:
+                </p>
+<div class="variablelist"><dl>
+<dt><span class="term"><strong class="userinput"><code>reload</code></strong></span></dt>
+<dd><p>
+                        Reload configuration file and zones.
+                      </p></dd>
+<dt><span class="term"><strong class="userinput"><code>reload <em class="replaceable"><code>zone</code></em>
+                        [<span class="optional"><em class="replaceable"><code>class</code></em>
+           [<span class="optional"><em class="replaceable"><code>view</code></em></span>]</span>]</code></strong></span></dt>
+<dd><p>
+                        Reload the given zone.
+                      </p></dd>
+<dt><span class="term"><strong class="userinput"><code>refresh <em class="replaceable"><code>zone</code></em>
+                        [<span class="optional"><em class="replaceable"><code>class</code></em>
+           [<span class="optional"><em class="replaceable"><code>view</code></em></span>]</span>]</code></strong></span></dt>
+<dd><p>
+                        Schedule zone maintenance for the given zone.
+                      </p></dd>
+<dt><span class="term"><strong class="userinput"><code>retransfer <em class="replaceable"><code>zone</code></em>
+
+                        [<span class="optional"><em class="replaceable"><code>class</code></em>
+           [<span class="optional"><em class="replaceable"><code>view</code></em></span>]</span>]</code></strong></span></dt>
+<dd><p>
+                        Retransfer the given zone from the master.
+                      </p></dd>
+<dt><span class="term"><strong class="userinput"><code>freeze
+                        [<span class="optional"><em class="replaceable"><code>zone</code></em>
+       [<span class="optional"><em class="replaceable"><code>class</code></em>
+           [<span class="optional"><em class="replaceable"><code>view</code></em></span>]</span>]</span>]</code></strong></span></dt>
+<dd><p>
+                        Suspend updates to a dynamic zone.  If no zone is
+                        specified,
+                        then all zones are suspended.  This allows manual
+                        edits to be made to a zone normally updated by dynamic
+                        update.  It
+                        also causes changes in the journal file to be synced
+                        into the master
+                        and the journal file to be removed.  All dynamic
+                        update attempts will
+                        be refused while the zone is frozen.
+                      </p></dd>
+<dt><span class="term"><strong class="userinput"><code>thaw
+                        [<span class="optional"><em class="replaceable"><code>zone</code></em>
+       [<span class="optional"><em class="replaceable"><code>class</code></em>
+           [<span class="optional"><em class="replaceable"><code>view</code></em></span>]</span>]</span>]</code></strong></span></dt>
+<dd><p>
+                        Enable updates to a frozen dynamic zone.  If no zone
+                        is
+                        specified, then all frozen zones are enabled.  This
+                        causes
+                        the server to reload the zone from disk, and
+                        re-enables dynamic updates
+                        after the load has completed.  After a zone is thawed,
+                        dynamic updates
+                        will no longer be refused.
+                      </p></dd>
+<dt><span class="term"><strong class="userinput"><code>notify <em class="replaceable"><code>zone</code></em>
+                        [<span class="optional"><em class="replaceable"><code>class</code></em>
+           [<span class="optional"><em class="replaceable"><code>view</code></em></span>]</span>]</code></strong></span></dt>
+<dd><p>
+                        Resend NOTIFY messages for the zone.
+                      </p></dd>
+<dt><span class="term"><strong class="userinput"><code>reconfig</code></strong></span></dt>
+<dd><p>
+                        Reload the configuration file and load new zones,
+                        but do not reload existing zone files even if they
+                        have changed.
+                        This is faster than a full <span><strong class="command">reload</strong></span> when there
+                        is a large number of zones because it avoids the need
+                        to examine the
+                        modification times of the zones files.
+                      </p></dd>
+<dt><span class="term"><strong class="userinput"><code>stats</code></strong></span></dt>
+<dd><p>
+                        Write server statistics to the statistics file.
+                      </p></dd>
+<dt><span class="term"><strong class="userinput"><code>querylog</code></strong></span></dt>
+<dd><p>
+                        Toggle query logging. Query logging can also be enabled
+                        by explicitly directing the <span><strong class="command">queries</strong></span>
+                        <span><strong class="command">category</strong></span> to a
+                        <span><strong class="command">channel</strong></span> in the
+                        <span><strong class="command">logging</strong></span> section of
+                        <code class="filename">named.conf</code> or by specifying
+                        <span><strong class="command">querylog yes;</strong></span> in the
+                        <span><strong class="command">options</strong></span> section of
+                        <code class="filename">named.conf</code>.
+                      </p></dd>
+<dt><span class="term"><strong class="userinput"><code>dumpdb
+                        [<span class="optional">-all|-cache|-zone</span>]
+                        [<span class="optional"><em class="replaceable"><code>view ...</code></em></span>]</code></strong></span></dt>
+<dd><p>
+                        Dump the server's caches (default) and/or zones to
+                        the
+                        dump file for the specified views.  If no view is
+                        specified, all
+                        views are dumped.
+                      </p></dd>
+<dt><span class="term"><strong class="userinput"><code>stop [<span class="optional">-p</span>]</code></strong></span></dt>
+<dd><p>
+                        Stop the server, making sure any recent changes
+                        made through dynamic update or IXFR are first saved to
+                        the master files of the updated zones.
+                        If -p is specified named's process id is returned.
+                        This allows an external process to determine when named
+                        had completed stopping.
+                      </p></dd>
+<dt><span class="term"><strong class="userinput"><code>halt [<span class="optional">-p</span>]</code></strong></span></dt>
+<dd><p>
+                        Stop the server immediately.  Recent changes
+                        made through dynamic update or IXFR are not saved to
+                        the master files, but will be rolled forward from the
+                        journal files when the server is restarted.
+                        If -p is specified named's process id is returned.
+                        This allows an external process to determine when named
+                        had completed halting.
+                      </p></dd>
+<dt><span class="term"><strong class="userinput"><code>trace</code></strong></span></dt>
+<dd><p>
+                        Increment the servers debugging level by one.
+                      </p></dd>
+<dt><span class="term"><strong class="userinput"><code>trace <em class="replaceable"><code>level</code></em></code></strong></span></dt>
+<dd><p>
+                        Sets the server's debugging level to an explicit
+                        value.
+                      </p></dd>
+<dt><span class="term"><strong class="userinput"><code>notrace</code></strong></span></dt>
+<dd><p>
+                        Sets the server's debugging level to 0.
+                      </p></dd>
+<dt><span class="term"><strong class="userinput"><code>flush</code></strong></span></dt>
+<dd><p>
+                        Flushes the server's cache.
+                      </p></dd>
+<dt><span class="term"><strong class="userinput"><code>flushname</code></strong> <em class="replaceable"><code>name</code></em></span></dt>
+<dd><p>
+                        Flushes the given name from the server's cache.
+                      </p></dd>
+<dt><span class="term"><strong class="userinput"><code>status</code></strong></span></dt>
+<dd><p>
+                        Display status of the server.
+                        Note that the number of zones includes the internal <span><strong class="command">bind/CH</strong></span> zone
+                        and the default <span><strong class="command">./IN</strong></span>
+                        hint zone if there is not an
+                        explicit root zone configured.
+                      </p></dd>
+<dt><span class="term"><strong class="userinput"><code>recursing</code></strong></span></dt>
+<dd><p>
+                        Dump the list of queries named is currently recursing
+                        on.
+                      </p></dd>
+</dl></div>
+<p>
+                  A configuration file is required, since all
+                  communication with the server is authenticated with
+                  digital signatures that rely on a shared secret, and
+                  there is no way to provide that secret other than with a
+                  configuration file.  The default location for the
+                  <span><strong class="command">rndc</strong></span> configuration file is
+                  <code class="filename">/etc/rndc.conf</code>, but an
+                  alternate
+                  location can be specified with the <code class="option">-c</code>
+                  option.  If the configuration file is not found,
+                  <span><strong class="command">rndc</strong></span> will also look in
+                  <code class="filename">/etc/rndc.key</code> (or whatever
+                  <code class="varname">sysconfdir</code> was defined when
+                  the <acronym class="acronym">BIND</acronym> build was
+                  configured).
+                  The <code class="filename">rndc.key</code> file is
+                  generated by
+                  running <span><strong class="command">rndc-confgen -a</strong></span> as
+                  described in
+                  <a href="Bv9ARM.ch06.html#controls_statement_definition_and_usage" title="controls Statement Definition and
+          Usage">the section called &#8220;<span><strong class="command">controls</strong></span> Statement Definition and
+          Usage&#8221;</a>.
+                </p>
+<p>
+                  The format of the configuration file is similar to
+                  that of <code class="filename">named.conf</code>, but
+                  limited to
+                  only four statements, the <span><strong class="command">options</strong></span>,
+                  <span><strong class="command">key</strong></span>, <span><strong class="command">server</strong></span> and
+                  <span><strong class="command">include</strong></span>
+                  statements.  These statements are what associate the
+                  secret keys to the servers with which they are meant to
+                  be shared.  The order of statements is not
+                  significant.
+                </p>
+<p>
+                  The <span><strong class="command">options</strong></span> statement has
+                  three clauses:
+                  <span><strong class="command">default-server</strong></span>, <span><strong class="command">default-key</strong></span>,
+                  and <span><strong class="command">default-port</strong></span>.
+                  <span><strong class="command">default-server</strong></span> takes a
+                  host name or address argument  and represents the server
+                  that will
+                  be contacted if no <code class="option">-s</code>
+                  option is provided on the command line.
+                  <span><strong class="command">default-key</strong></span> takes
+                  the name of a key as its argument, as defined by a <span><strong class="command">key</strong></span> statement.
+                  <span><strong class="command">default-port</strong></span> specifies the
+                  port to which
+                  <span><strong class="command">rndc</strong></span> should connect if no
+                  port is given on the command line or in a
+                  <span><strong class="command">server</strong></span> statement.
+                </p>
+<p>
+                  The <span><strong class="command">key</strong></span> statement defines a
+                  key to be used
+                  by <span><strong class="command">rndc</strong></span> when authenticating
+                  with
+                  <span><strong class="command">named</strong></span>.  Its syntax is
+                  identical to the
+                  <span><strong class="command">key</strong></span> statement in named.conf.
+                  The keyword <strong class="userinput"><code>key</code></strong> is
+                  followed by a key name, which must be a valid
+                  domain name, though it need not actually be hierarchical;
+                  thus,
+                  a string like "<strong class="userinput"><code>rndc_key</code></strong>" is a valid
+                  name.
+                  The <span><strong class="command">key</strong></span> statement has two
+                  clauses:
+                  <span><strong class="command">algorithm</strong></span> and <span><strong class="command">secret</strong></span>.
+                  While the configuration parser will accept any string as the
+                  argument
+                  to algorithm, currently only the string "<strong class="userinput"><code>hmac-md5</code></strong>"
+                  has any meaning.  The secret is a base-64 encoded string
+                  as specified in RFC 3548.
+                </p>
+<p>
+                  The <span><strong class="command">server</strong></span> statement
+                  associates a key
+                  defined using the <span><strong class="command">key</strong></span>
+                  statement with a server.
+                  The keyword <strong class="userinput"><code>server</code></strong> is followed by a
+                  host name or address.  The <span><strong class="command">server</strong></span> statement
+                  has two clauses: <span><strong class="command">key</strong></span> and <span><strong class="command">port</strong></span>.
+                  The <span><strong class="command">key</strong></span> clause specifies the
+                  name of the key
+                  to be used when communicating with this server, and the
+                  <span><strong class="command">port</strong></span> clause can be used to
+                  specify the port <span><strong class="command">rndc</strong></span> should
+                  connect
+                  to on the server.
+                </p>
+<p>
+                  A sample minimal configuration file is as follows:
+                </p>
+<pre class="programlisting">
+key rndc_key {
+     algorithm "hmac-md5";
+     secret "c3Ryb25nIGVub3VnaCBmb3IgYSBtYW4gYnV0IG1hZGUgZm9yIGEgd29tYW4K";
+};
+options {
+     default-server 127.0.0.1;
+     default-key    rndc_key;
+};
+</pre>
+<p>
+                  This file, if installed as <code class="filename">/etc/rndc.conf</code>,
+                  would allow the command:
+                </p>
+<p>
+                  <code class="prompt">$ </code><strong class="userinput"><code>rndc reload</code></strong>
+                </p>
+<p>
+                  to connect to 127.0.0.1 port 953 and cause the name server
+                  to reload, if a name server on the local machine were
+                  running with
+                  following controls statements:
+                </p>
+<pre class="programlisting">
+controls {
+        inet 127.0.0.1 allow { localhost; } keys { rndc_key; };
+};
+</pre>
+<p>
+                  and it had an identical key statement for
+                  <code class="literal">rndc_key</code>.
+                </p>
+<p>
+                  Running the <span><strong class="command">rndc-confgen</strong></span>
+                  program will
+                  conveniently create a <code class="filename">rndc.conf</code>
+                  file for you, and also display the
+                  corresponding <span><strong class="command">controls</strong></span>
+                  statement that you need to
+                  add to <code class="filename">named.conf</code>.
+                  Alternatively,
+                  you can run <span><strong class="command">rndc-confgen -a</strong></span>
+                  to set up
+                  a <code class="filename">rndc.key</code> file and not
+                  modify
+                  <code class="filename">named.conf</code> at all.
+                </p>
+</dd>
+</dl></div>
+</div>
+</div>
+<div class="sect2" lang="en">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="id2570184"></a>Signals</h3></div></div></div>
+<p>
+          Certain UNIX signals cause the name server to take specific
+          actions, as described in the following table.  These signals can
+          be sent using the <span><strong class="command">kill</strong></span> command.
+        </p>
+<div class="informaltable"><table border="1">
+<colgroup>
+<col>
+<col>
+</colgroup>
+<tbody>
+<tr>
+<td>
+                  <p><span><strong class="command">SIGHUP</strong></span></p>
+                </td>
+<td>
+                  <p>
+                    Causes the server to read <code class="filename">named.conf</code> and
+                    reload the database.
+                  </p>
+                </td>
+</tr>
+<tr>
+<td>
+                  <p><span><strong class="command">SIGTERM</strong></span></p>
+                </td>
+<td>
+                  <p>
+                    Causes the server to clean up and exit.
+                  </p>
+                </td>
+</tr>
+<tr>
+<td>
+                  <p><span><strong class="command">SIGINT</strong></span></p>
+                </td>
+<td>
+                  <p>
+                    Causes the server to clean up and exit.
+                  </p>
+                </td>
+</tr>
+</tbody>
+</table></div>
+</div>
+</div>
+</div>
+<div class="navfooter">
+<hr>
+<table width="100%" summary="Navigation footer">
+<tr>
+<td width="40%" align="left">
+<a accesskey="p" href="Bv9ARM.ch02.html">Prev</a> </td>
+<td width="20%" align="center"> </td>
+<td width="40%" align="right"> <a accesskey="n" href="Bv9ARM.ch04.html">Next</a>
+</td>
+</tr>
+<tr>
+<td width="40%" align="left" valign="top">Chapter 2. <acronym class="acronym">BIND</acronym> Resource Requirements </td>
+<td width="20%" align="center"><a accesskey="h" href="Bv9ARM.html">Home</a></td>
+<td width="40%" align="right" valign="top"> Chapter 4. Advanced DNS Features</td>
+</tr>
+</table>
+</div>
+</body>
+</html>
diff --git a/doc/arm/Bv9ARM.ch04.html b/doc/arm/Bv9ARM.ch04.html
new file mode 100644
index 0000000..09507fe
--- /dev/null
+++ b/doc/arm/Bv9ARM.ch04.html
@@ -0,0 +1,1028 @@
+<!--
+ - Copyright (C) 2004-2007 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2000-2003 Internet Software Consortium.
+ - 
+ - Permission to use, copy, modify, and distribute this software for any
+ - purpose with or without fee is hereby granted, provided that the above
+ - copyright notice and this permission notice appear in all copies.
+ - 
+ - THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
+ - REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
+ - AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
+ - INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
+ - LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
+ - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
+ - PERFORMANCE OF THIS SOFTWARE.
+-->
+<!-- $Id: Bv9ARM.ch04.html,v 1.40.18.41 2007/10/31 01:35:57 marka Exp $ -->
+<html>
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
+<title>Chapter 4. Advanced DNS Features</title>
+<meta name="generator" content="DocBook XSL Stylesheets V1.71.1">
+<link rel="start" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual">
+<link rel="up" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual">
+<link rel="prev" href="Bv9ARM.ch03.html" title="Chapter 3. Name Server Configuration">
+<link rel="next" href="Bv9ARM.ch05.html" title="Chapter 5. The BIND 9 Lightweight Resolver">
+</head>
+<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
+<div class="navheader">
+<table width="100%" summary="Navigation header">
+<tr><th colspan="3" align="center">Chapter 4. Advanced DNS Features</th></tr>
+<tr>
+<td width="20%" align="left">
+<a accesskey="p" href="Bv9ARM.ch03.html">Prev</a> </td>
+<th width="60%" align="center"> </th>
+<td width="20%" align="right"> <a accesskey="n" href="Bv9ARM.ch05.html">Next</a>
+</td>
+</tr>
+</table>
+<hr>
+</div>
+<div class="chapter" lang="en">
+<div class="titlepage"><div><div><h2 class="title">
+<a name="Bv9ARM.ch04"></a>Chapter 4. Advanced DNS Features</h2></div></div></div>
+<div class="toc">
+<p><b>Table of Contents</b></p>
+<dl>
+<dt><span class="sect1"><a href="Bv9ARM.ch04.html#notify">Notify</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch04.html#dynamic_update">Dynamic Update</a></span></dt>
+<dd><dl><dt><span class="sect2"><a href="Bv9ARM.ch04.html#journal">The journal file</a></span></dt></dl></dd>
+<dt><span class="sect1"><a href="Bv9ARM.ch04.html#incremental_zone_transfers">Incremental Zone Transfers (IXFR)</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch04.html#id2570642">Split DNS</a></span></dt>
+<dd><dl><dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2570660">Example split DNS setup</a></span></dt></dl></dd>
+<dt><span class="sect1"><a href="Bv9ARM.ch04.html#tsig">TSIG</a></span></dt>
+<dd><dl>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571095">Generate Shared Keys for Each Pair of Hosts</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571169">Copying the Shared Secret to Both Machines</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571179">Informing the Servers of the Key's Existence</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571219">Instructing the Server to Use the Key</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571413">TSIG Key Based Access Control</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571458">Errors</a></span></dt>
+</dl></dd>
+<dt><span class="sect1"><a href="Bv9ARM.ch04.html#id2571472">TKEY</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch04.html#id2571521">SIG(0)</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch04.html#DNSSEC">DNSSEC</a></span></dt>
+<dd><dl>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571725">Generating Keys</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571795">Signing the Zone</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571874">Configuring Servers</a></span></dt>
+</dl></dd>
+<dt><span class="sect1"><a href="Bv9ARM.ch04.html#id2572153">IPv6 Support in <acronym class="acronym">BIND</acronym> 9</a></span></dt>
+<dd><dl>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2572215">Address Lookups Using AAAA Records</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2572236">Address to Name Lookups Using Nibble Format</a></span></dt>
+</dl></dd>
+</dl>
+</div>
+<div class="sect1" lang="en">
+<div class="titlepage"><div><div><h2 class="title" style="clear: both">
+<a name="notify"></a>Notify</h2></div></div></div>
+<p>
+        <acronym class="acronym">DNS</acronym> NOTIFY is a mechanism that allows master
+        servers to notify their slave servers of changes to a zone's data. In
+        response to a <span><strong class="command">NOTIFY</strong></span> from a master server, the
+        slave will check to see that its version of the zone is the
+        current version and, if not, initiate a zone transfer.
+      </p>
+<p>
+        For more information about <acronym class="acronym">DNS</acronym>
+        <span><strong class="command">NOTIFY</strong></span>, see the description of the
+        <span><strong class="command">notify</strong></span> option in <a href="Bv9ARM.ch06.html#boolean_options" title="Boolean Options">the section called &#8220;Boolean Options&#8221;</a> and
+        the description of the zone option <span><strong class="command">also-notify</strong></span> in
+        <a href="Bv9ARM.ch06.html#zone_transfers" title="Zone Transfers">the section called &#8220;Zone Transfers&#8221;</a>.  The <span><strong class="command">NOTIFY</strong></span>
+        protocol is specified in RFC 1996.
+      </p>
+<div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
+<h3 class="title">Note</h3>
+        As a slave zone can also be a master to other slaves, named,
+        by default, sends <span><strong class="command">NOTIFY</strong></span> messages for every zone
+        it loads.  Specifying <span><strong class="command">notify master-only;</strong></span> will
+        cause named to only send <span><strong class="command">NOTIFY</strong></span> for master
+        zones that it loads.
+      </div>
+</div>
+<div class="sect1" lang="en">
+<div class="titlepage"><div><div><h2 class="title" style="clear: both">
+<a name="dynamic_update"></a>Dynamic Update</h2></div></div></div>
+<p>
+        Dynamic Update is a method for adding, replacing or deleting
+        records in a master server by sending it a special form of DNS
+        messages.  The format and meaning of these messages is specified
+        in RFC 2136.
+      </p>
+<p>
+        Dynamic update is enabled by
+        including an <span><strong class="command">allow-update</strong></span> or
+        <span><strong class="command">update-policy</strong></span> clause in the
+        <span><strong class="command">zone</strong></span> statement.
+      </p>
+<p>
+        Updating of secure zones (zones using DNSSEC) follows
+        RFC 3007: RRSIG and NSEC records affected by updates are automatically
+            regenerated by the server using an online zone key.
+        Update authorization is based
+        on transaction signatures and an explicit server policy.
+      </p>
+<div class="sect2" lang="en">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="journal"></a>The journal file</h3></div></div></div>
+<p>
+          All changes made to a zone using dynamic update are stored
+          in the zone's journal file.  This file is automatically created
+          by the server when the first dynamic update takes place.
+          The name of the journal file is formed by appending the extension
+          <code class="filename">.jnl</code> to the name of the
+          corresponding zone
+          file unless specifically overridden.  The journal file is in a
+          binary format and should not be edited manually.
+        </p>
+<p>
+          The server will also occasionally write ("dump")
+          the complete contents of the updated zone to its zone file.
+          This is not done immediately after
+          each dynamic update, because that would be too slow when a large
+          zone is updated frequently.  Instead, the dump is delayed by
+          up to 15 minutes, allowing additional updates to take place.
+        </p>
+<p>
+          When a server is restarted after a shutdown or crash, it will replay
+              the journal file to incorporate into the zone any updates that
+          took
+          place after the last zone dump.
+        </p>
+<p>
+          Changes that result from incoming incremental zone transfers are
+          also
+          journalled in a similar way.
+        </p>
+<p>
+          The zone files of dynamic zones cannot normally be edited by
+          hand because they are not guaranteed to contain the most recent
+          dynamic changes &#8212; those are only in the journal file.
+          The only way to ensure that the zone file of a dynamic zone
+          is up to date is to run <span><strong class="command">rndc stop</strong></span>.
+        </p>
+<p>
+          If you have to make changes to a dynamic zone
+          manually, the following procedure will work: Disable dynamic updates
+              to the zone using
+          <span><strong class="command">rndc freeze <em class="replaceable"><code>zone</code></em></strong></span>.
+          This will also remove the zone's <code class="filename">.jnl</code> file
+          and update the master file.  Edit the zone file.  Run
+          <span><strong class="command">rndc thaw <em class="replaceable"><code>zone</code></em></strong></span>
+          to reload the changed zone and re-enable dynamic updates.
+        </p>
+</div>
+</div>
+<div class="sect1" lang="en">
+<div class="titlepage"><div><div><h2 class="title" style="clear: both">
+<a name="incremental_zone_transfers"></a>Incremental Zone Transfers (IXFR)</h2></div></div></div>
+<p>
+        The incremental zone transfer (IXFR) protocol is a way for
+        slave servers to transfer only changed data, instead of having to
+        transfer the entire zone. The IXFR protocol is specified in RFC
+        1995. See <a href="Bv9ARM.ch09.html#proposed_standards">Proposed Standards</a>.
+      </p>
+<p>
+        When acting as a master, <acronym class="acronym">BIND</acronym> 9
+        supports IXFR for those zones
+        where the necessary change history information is available. These
+        include master zones maintained by dynamic update and slave zones
+        whose data was obtained by IXFR.  For manually maintained master
+        zones, and for slave zones obtained by performing a full zone
+        transfer (AXFR), IXFR is supported only if the option
+        <span><strong class="command">ixfr-from-differences</strong></span> is set
+        to <strong class="userinput"><code>yes</code></strong>.
+      </p>
+<p>
+        When acting as a slave, <acronym class="acronym">BIND</acronym> 9 will
+        attempt to use IXFR unless
+        it is explicitly disabled. For more information about disabling
+        IXFR, see the description of the <span><strong class="command">request-ixfr</strong></span> clause
+        of the <span><strong class="command">server</strong></span> statement.
+      </p>
+</div>
+<div class="sect1" lang="en">
+<div class="titlepage"><div><div><h2 class="title" style="clear: both">
+<a name="id2570642"></a>Split DNS</h2></div></div></div>
+<p>
+        Setting up different views, or visibility, of the DNS space to
+        internal and external resolvers is usually referred to as a
+        <span class="emphasis"><em>Split DNS</em></span> setup. There are several
+        reasons an organization would want to set up its DNS this way.
+      </p>
+<p>
+        One common reason for setting up a DNS system this way is
+        to hide "internal" DNS information from "external" clients on the
+        Internet. There is some debate as to whether or not this is actually
+        useful.
+        Internal DNS information leaks out in many ways (via email headers,
+        for example) and most savvy "attackers" can find the information
+        they need using other means.
+        However, since listing addresses of internal servers that
+        external clients cannot possibly reach can result in
+        connection delays and other annoyances, an organization may
+        choose to use a Split DNS to present a consistent view of itself
+        to the outside world.
+      </p>
+<p>
+        Another common reason for setting up a Split DNS system is
+        to allow internal networks that are behind filters or in RFC 1918
+        space (reserved IP space, as documented in RFC 1918) to resolve DNS
+        on the Internet. Split DNS can also be used to allow mail from outside
+        back in to the internal network.
+      </p>
+<div class="sect2" lang="en">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="id2570660"></a>Example split DNS setup</h3></div></div></div>
+<p>
+        Let's say a company named <span class="emphasis"><em>Example, Inc.</em></span>
+        (<code class="literal">example.com</code>)
+        has several corporate sites that have an internal network with
+        reserved
+        Internet Protocol (IP) space and an external demilitarized zone (DMZ),
+        or "outside" section of a network, that is available to the public.
+      </p>
+<p>
+        <span class="emphasis"><em>Example, Inc.</em></span> wants its internal clients
+        to be able to resolve external hostnames and to exchange mail with
+        people on the outside. The company also wants its internal resolvers
+        to have access to certain internal-only zones that are not available
+        at all outside of the internal network.
+      </p>
+<p>
+        In order to accomplish this, the company will set up two sets
+        of name servers. One set will be on the inside network (in the
+        reserved
+        IP space) and the other set will be on bastion hosts, which are
+        "proxy"
+        hosts that can talk to both sides of its network, in the DMZ.
+      </p>
+<p>
+        The internal servers will be configured to forward all queries,
+        except queries for <code class="filename">site1.internal</code>, <code class="filename">site2.internal</code>, <code class="filename">site1.example.com</code>,
+        and <code class="filename">site2.example.com</code>, to the servers
+        in the
+        DMZ. These internal servers will have complete sets of information
+        for <code class="filename">site1.example.com</code>, <code class="filename">site2.example.com</code>,<span class="emphasis"><em></em></span> <code class="filename">site1.internal</code>,
+        and <code class="filename">site2.internal</code>.
+      </p>
+<p>
+        To protect the <code class="filename">site1.internal</code> and <code class="filename">site2.internal</code> domains,
+        the internal name servers must be configured to disallow all queries
+        to these domains from any external hosts, including the bastion
+        hosts.
+      </p>
+<p>
+        The external servers, which are on the bastion hosts, will
+        be configured to serve the "public" version of the <code class="filename">site1</code> and <code class="filename">site2.example.com</code> zones.
+        This could include things such as the host records for public servers
+        (<code class="filename">www.example.com</code> and <code class="filename">ftp.example.com</code>),
+        and mail exchange (MX)  records (<code class="filename">a.mx.example.com</code> and <code class="filename">b.mx.example.com</code>).
+      </p>
+<p>
+        In addition, the public <code class="filename">site1</code> and <code class="filename">site2.example.com</code> zones
+        should have special MX records that contain wildcard (`*') records
+        pointing to the bastion hosts. This is needed because external mail
+        servers do not have any other way of looking up how to deliver mail
+        to those internal hosts. With the wildcard records, the mail will
+        be delivered to the bastion host, which can then forward it on to
+        internal hosts.
+      </p>
+<p>
+        Here's an example of a wildcard MX record:
+      </p>
+<pre class="programlisting">*   IN MX 10 external1.example.com.</pre>
+<p>
+        Now that they accept mail on behalf of anything in the internal
+        network, the bastion hosts will need to know how to deliver mail
+        to internal hosts. In order for this to work properly, the resolvers
+        on
+        the bastion hosts will need to be configured to point to the internal
+        name servers for DNS resolution.
+      </p>
+<p>
+        Queries for internal hostnames will be answered by the internal
+        servers, and queries for external hostnames will be forwarded back
+        out to the DNS servers on the bastion hosts.
+      </p>
+<p>
+        In order for all this to work properly, internal clients will
+        need to be configured to query <span class="emphasis"><em>only</em></span> the internal
+        name servers for DNS queries. This could also be enforced via
+        selective
+        filtering on the network.
+      </p>
+<p>
+        If everything has been set properly, <span class="emphasis"><em>Example, Inc.</em></span>'s
+        internal clients will now be able to:
+      </p>
+<div class="itemizedlist"><ul type="disc">
+<li>
+            Look up any hostnames in the <code class="literal">site1</code>
+            and
+            <code class="literal">site2.example.com</code> zones.
+          </li>
+<li>
+            Look up any hostnames in the <code class="literal">site1.internal</code> and
+            <code class="literal">site2.internal</code> domains.
+          </li>
+<li>Look up any hostnames on the Internet.</li>
+<li>Exchange mail with both internal and external people.</li>
+</ul></div>
+<p>
+        Hosts on the Internet will be able to:
+      </p>
+<div class="itemizedlist"><ul type="disc">
+<li>
+            Look up any hostnames in the <code class="literal">site1</code>
+            and
+            <code class="literal">site2.example.com</code> zones.
+          </li>
+<li>
+            Exchange mail with anyone in the <code class="literal">site1</code> and
+            <code class="literal">site2.example.com</code> zones.
+          </li>
+</ul></div>
+<p>
+        Here is an example configuration for the setup we just
+        described above. Note that this is only configuration information;
+        for information on how to configure your zone files, see <a href="Bv9ARM.ch03.html#sample_configuration" title="Sample Configurations">the section called &#8220;Sample Configurations&#8221;</a>.
+      </p>
+<p>
+        Internal DNS server config:
+      </p>
+<pre class="programlisting">
+
+acl internals { 172.16.72.0/24; 192.168.1.0/24; };
+
+acl externals { <code class="varname">bastion-ips-go-here</code>; };
+
+options {
+    ...
+    ...
+    forward only;
+    forwarders {                                // forward to external servers
+        <code class="varname">bastion-ips-go-here</code>;
+    };
+    allow-transfer { none; };                   // sample allow-transfer (no one)
+    allow-query { internals; externals; };      // restrict query access
+    allow-recursion { internals; };             // restrict recursion
+    ...
+    ...
+};
+
+zone "site1.example.com" {                      // sample master zone
+  type master;
+  file "m/site1.example.com";
+  forwarders { };                               // do normal iterative
+                                                // resolution (do not forward)
+  allow-query { internals; externals; };
+  allow-transfer { internals; };
+};
+
+zone "site2.example.com" {                      // sample slave zone
+  type slave;
+  file "s/site2.example.com";
+  masters { 172.16.72.3; };
+  forwarders { };
+  allow-query { internals; externals; };
+  allow-transfer { internals; };
+};
+
+zone "site1.internal" {
+  type master;
+  file "m/site1.internal";
+  forwarders { };
+  allow-query { internals; };
+  allow-transfer { internals; }
+};
+
+zone "site2.internal" {
+  type slave;
+  file "s/site2.internal";
+  masters { 172.16.72.3; };
+  forwarders { };
+  allow-query { internals };
+  allow-transfer { internals; }
+};
+</pre>
+<p>
+        External (bastion host) DNS server config:
+      </p>
+<pre class="programlisting">
+acl internals { 172.16.72.0/24; 192.168.1.0/24; };
+
+acl externals { bastion-ips-go-here; };
+
+options {
+  ...
+  ...
+  allow-transfer { none; };                     // sample allow-transfer (no one)
+  allow-query { any; };                         // default query access
+  allow-query-cache { internals; externals; };  // restrict cache access
+  allow-recursion { internals; externals; };    // restrict recursion
+  ...
+  ...
+};
+
+zone "site1.example.com" {                      // sample slave zone
+  type master;
+  file "m/site1.foo.com";
+  allow-transfer { internals; externals; };
+};
+
+zone "site2.example.com" {
+  type slave;
+  file "s/site2.foo.com";
+  masters { another_bastion_host_maybe; };
+  allow-transfer { internals; externals; }
+};
+</pre>
+<p>
+        In the <code class="filename">resolv.conf</code> (or equivalent) on
+        the bastion host(s):
+      </p>
+<pre class="programlisting">
+search ...
+nameserver 172.16.72.2
+nameserver 172.16.72.3
+nameserver 172.16.72.4
+</pre>
+</div>
+</div>
+<div class="sect1" lang="en">
+<div class="titlepage"><div><div><h2 class="title" style="clear: both">
+<a name="tsig"></a>TSIG</h2></div></div></div>
+<p>
+        This is a short guide to setting up Transaction SIGnatures
+        (TSIG) based transaction security in <acronym class="acronym">BIND</acronym>. It describes changes
+        to the configuration file as well as what changes are required for
+        different features, including the process of creating transaction
+        keys and using transaction signatures with <acronym class="acronym">BIND</acronym>.
+      </p>
+<p>
+        <acronym class="acronym">BIND</acronym> primarily supports TSIG for server
+        to server communication.
+        This includes zone transfer, notify, and recursive query messages.
+        Resolvers based on newer versions of <acronym class="acronym">BIND</acronym> 8 have limited support
+        for TSIG.
+      </p>
+<p>
+        TSIG can also be useful for dynamic update. A primary
+        server for a dynamic zone should control access to the dynamic
+        update service, but IP-based access control is insufficient.
+        The cryptographic access control provided by TSIG
+        is far superior. The <span><strong class="command">nsupdate</strong></span>
+        program supports TSIG via the <code class="option">-k</code> and
+        <code class="option">-y</code> command line options or inline by use
+        of the <span><strong class="command">key</strong></span>.
+      </p>
+<div class="sect2" lang="en">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="id2571095"></a>Generate Shared Keys for Each Pair of Hosts</h3></div></div></div>
+<p>
+          A shared secret is generated to be shared between <span class="emphasis"><em>host1</em></span> and <span class="emphasis"><em>host2</em></span>.
+          An arbitrary key name is chosen: "host1-host2.". The key name must
+          be the same on both hosts.
+        </p>
+<div class="sect3" lang="en">
+<div class="titlepage"><div><div><h4 class="title">
+<a name="id2571112"></a>Automatic Generation</h4></div></div></div>
+<p>
+            The following command will generate a 128-bit (16 byte) HMAC-MD5
+            key as described above. Longer keys are better, but shorter keys
+            are easier to read. Note that the maximum key length is 512 bits;
+            keys longer than that will be digested with MD5 to produce a
+            128-bit key.
+          </p>
+<p>
+            <strong class="userinput"><code>dnssec-keygen -a hmac-md5 -b 128 -n HOST host1-host2.</code></strong>
+          </p>
+<p>
+            The key is in the file <code class="filename">Khost1-host2.+157+00000.private</code>.
+            Nothing directly uses this file, but the base-64 encoded string
+            following "<code class="literal">Key:</code>"
+            can be extracted from the file and used as a shared secret:
+          </p>
+<pre class="programlisting">Key: La/E5CjG9O+os1jq0a2jdA==</pre>
+<p>
+            The string "<code class="literal">La/E5CjG9O+os1jq0a2jdA==</code>" can
+            be used as the shared secret.
+          </p>
+</div>
+<div class="sect3" lang="en">
+<div class="titlepage"><div><div><h4 class="title">
+<a name="id2571150"></a>Manual Generation</h4></div></div></div>
+<p>
+            The shared secret is simply a random sequence of bits, encoded
+            in base-64. Most ASCII strings are valid base-64 strings (assuming
+            the length is a multiple of 4 and only valid characters are used),
+            so the shared secret can be manually generated.
+          </p>
+<p>
+            Also, a known string can be run through <span><strong class="command">mmencode</strong></span> or
+            a similar program to generate base-64 encoded data.
+          </p>
+</div>
+</div>
+<div class="sect2" lang="en">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="id2571169"></a>Copying the Shared Secret to Both Machines</h3></div></div></div>
+<p>
+          This is beyond the scope of DNS. A secure transport mechanism
+          should be used. This could be secure FTP, ssh, telephone, etc.
+        </p>
+</div>
+<div class="sect2" lang="en">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="id2571179"></a>Informing the Servers of the Key's Existence</h3></div></div></div>
+<p>
+          Imagine <span class="emphasis"><em>host1</em></span> and <span class="emphasis"><em>host 2</em></span>
+          are
+          both servers. The following is added to each server's <code class="filename">named.conf</code> file:
+        </p>
+<pre class="programlisting">
+key host1-host2. {
+  algorithm hmac-md5;
+  secret "La/E5CjG9O+os1jq0a2jdA==";
+};
+</pre>
+<p>
+          The algorithm, hmac-md5, is the only one supported by <acronym class="acronym">BIND</acronym>.
+          The secret is the one generated above. Since this is a secret, it
+          is recommended that either <code class="filename">named.conf</code> be non-world
+          readable, or the key directive be added to a non-world readable
+          file that is included by
+          <code class="filename">named.conf</code>.
+        </p>
+<p>
+          At this point, the key is recognized. This means that if the
+          server receives a message signed by this key, it can verify the
+          signature. If the signature is successfully verified, the
+          response is signed by the same key.
+        </p>
+</div>
+<div class="sect2" lang="en">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="id2571219"></a>Instructing the Server to Use the Key</h3></div></div></div>
+<p>
+          Since keys are shared between two hosts only, the server must
+          be told when keys are to be used. The following is added to the <code class="filename">named.conf</code> file
+          for <span class="emphasis"><em>host1</em></span>, if the IP address of <span class="emphasis"><em>host2</em></span> is
+          10.1.2.3:
+        </p>
+<pre class="programlisting">
+server 10.1.2.3 {
+  keys { host1-host2. ;};
+};
+</pre>
+<p>
+          Multiple keys may be present, but only the first is used.
+          This directive does not contain any secrets, so it may be in a
+          world-readable
+          file.
+        </p>
+<p>
+          If <span class="emphasis"><em>host1</em></span> sends a message that is a request
+          to that address, the message will be signed with the specified key. <span class="emphasis"><em>host1</em></span> will
+          expect any responses to signed messages to be signed with the same
+          key.
+        </p>
+<p>
+          A similar statement must be present in <span class="emphasis"><em>host2</em></span>'s
+          configuration file (with <span class="emphasis"><em>host1</em></span>'s address) for <span class="emphasis"><em>host2</em></span> to
+          sign request messages to <span class="emphasis"><em>host1</em></span>.
+        </p>
+</div>
+<div class="sect2" lang="en">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="id2571413"></a>TSIG Key Based Access Control</h3></div></div></div>
+<p>
+          <acronym class="acronym">BIND</acronym> allows IP addresses and ranges
+          to be specified in ACL
+          definitions and
+          <span><strong class="command">allow-{ query | transfer | update }</strong></span>
+          directives.
+          This has been extended to allow TSIG keys also. The above key would
+          be denoted <span><strong class="command">key host1-host2.</strong></span>
+        </p>
+<p>
+          An example of an allow-update directive would be:
+        </p>
+<pre class="programlisting">
+allow-update { key host1-host2. ;};
+</pre>
+<p>
+          This allows dynamic updates to succeed only if the request
+          was signed by a key named
+          "<span><strong class="command">host1-host2.</strong></span>".
+        </p>
+<p>
+          You may want to read about the more
+          powerful <span><strong class="command">update-policy</strong></span> statement in <a href="Bv9ARM.ch06.html#dynamic_update_policies" title="Dynamic Update Policies">the section called &#8220;Dynamic Update Policies&#8221;</a>.
+        </p>
+</div>
+<div class="sect2" lang="en">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="id2571458"></a>Errors</h3></div></div></div>
+<p>
+          The processing of TSIG signed messages can result in
+          several errors. If a signed message is sent to a non-TSIG aware
+          server, a FORMERR (format error) will be returned, since the server will not
+          understand the record. This is a result of misconfiguration,
+          since the server must be explicitly configured to send a TSIG
+          signed message to a specific server.
+        </p>
+<p>
+          If a TSIG aware server receives a message signed by an
+          unknown key, the response will be unsigned with the TSIG
+          extended error code set to BADKEY. If a TSIG aware server
+          receives a message with a signature that does not validate, the
+          response will be unsigned with the TSIG extended error code set
+          to BADSIG. If a TSIG aware server receives a message with a time
+          outside of the allowed range, the response will be signed with
+          the TSIG extended error code set to BADTIME, and the time values
+          will be adjusted so that the response can be successfully
+          verified. In any of these cases, the message's rcode (response code) is set to
+          NOTAUTH (not authenticated).
+        </p>
+</div>
+</div>
+<div class="sect1" lang="en">
+<div class="titlepage"><div><div><h2 class="title" style="clear: both">
+<a name="id2571472"></a>TKEY</h2></div></div></div>
+<p><span><strong class="command">TKEY</strong></span>
+        is a mechanism for automatically generating a shared secret
+        between two hosts.  There are several "modes" of
+        <span><strong class="command">TKEY</strong></span> that specify how the key is generated
+        or assigned.  <acronym class="acronym">BIND</acronym> 9 implements only one of
+        these modes, the Diffie-Hellman key exchange.  Both hosts are
+        required to have a Diffie-Hellman KEY record (although this
+        record is not required to be present in a zone).  The
+        <span><strong class="command">TKEY</strong></span> process must use signed messages,
+        signed either by TSIG or SIG(0).  The result of
+        <span><strong class="command">TKEY</strong></span> is a shared secret that can be used to
+        sign messages with TSIG.  <span><strong class="command">TKEY</strong></span> can also be
+        used to delete shared secrets that it had previously
+        generated.
+      </p>
+<p>
+        The <span><strong class="command">TKEY</strong></span> process is initiated by a
+        client
+        or server by sending a signed <span><strong class="command">TKEY</strong></span>
+        query
+        (including any appropriate KEYs) to a TKEY-aware server.  The
+        server response, if it indicates success, will contain a
+        <span><strong class="command">TKEY</strong></span> record and any appropriate keys.
+        After
+        this exchange, both participants have enough information to
+        determine the shared secret; the exact process depends on the
+        <span><strong class="command">TKEY</strong></span> mode.  When using the
+        Diffie-Hellman
+        <span><strong class="command">TKEY</strong></span> mode, Diffie-Hellman keys are
+        exchanged,
+        and the shared secret is derived by both participants.
+      </p>
+</div>
+<div class="sect1" lang="en">
+<div class="titlepage"><div><div><h2 class="title" style="clear: both">
+<a name="id2571521"></a>SIG(0)</h2></div></div></div>
+<p>
+        <acronym class="acronym">BIND</acronym> 9 partially supports DNSSEC SIG(0)
+            transaction signatures as specified in RFC 2535 and RFC2931.
+        SIG(0)
+        uses public/private keys to authenticate messages.  Access control
+        is performed in the same manner as TSIG keys; privileges can be
+        granted or denied based on the key name.
+      </p>
+<p>
+        When a SIG(0) signed message is received, it will only be
+        verified if the key is known and trusted by the server; the server
+        will not attempt to locate and/or validate the key.
+      </p>
+<p>
+        SIG(0) signing of multiple-message TCP streams is not
+        supported.
+      </p>
+<p>
+        The only tool shipped with <acronym class="acronym">BIND</acronym> 9 that
+        generates SIG(0) signed messages is <span><strong class="command">nsupdate</strong></span>.
+      </p>
+</div>
+<div class="sect1" lang="en">
+<div class="titlepage"><div><div><h2 class="title" style="clear: both">
+<a name="DNSSEC"></a>DNSSEC</h2></div></div></div>
+<p>
+        Cryptographic authentication of DNS information is possible
+        through the DNS Security (<span class="emphasis"><em>DNSSEC-bis</em></span>) extensions,
+        defined in RFC 4033, RFC 4034, and RFC 4035.
+        This section describes the creation and use of DNSSEC signed zones.
+      </p>
+<p>
+        In order to set up a DNSSEC secure zone, there are a series
+        of steps which must be followed.  <acronym class="acronym">BIND</acronym>
+        9 ships
+        with several tools
+        that are used in this process, which are explained in more detail
+        below.  In all cases, the <code class="option">-h</code> option prints a
+        full list of parameters.  Note that the DNSSEC tools require the
+        keyset files to be in the working directory or the
+        directory specified by the <code class="option">-d</code> option, and
+        that the tools shipped with BIND 9.2.x and earlier are not compatible
+        with the current ones.
+      </p>
+<p>
+        There must also be communication with the administrators of
+        the parent and/or child zone to transmit keys.  A zone's security
+        status must be indicated by the parent zone for a DNSSEC capable
+        resolver to trust its data.  This is done through the presence
+        or absence of a <code class="literal">DS</code> record at the
+        delegation
+        point.
+      </p>
+<p>
+        For other servers to trust data in this zone, they must
+        either be statically configured with this zone's zone key or the
+        zone key of another zone above this one in the DNS tree.
+      </p>
+<div class="sect2" lang="en">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="id2571725"></a>Generating Keys</h3></div></div></div>
+<p>
+          The <span><strong class="command">dnssec-keygen</strong></span> program is used to
+          generate keys.
+        </p>
+<p>
+          A secure zone must contain one or more zone keys.  The
+          zone keys will sign all other records in the zone, as well as
+          the zone keys of any secure delegated zones.  Zone keys must
+          have the same name as the zone, a name type of
+          <span><strong class="command">ZONE</strong></span>, and must be usable for
+          authentication.
+          It is recommended that zone keys use a cryptographic algorithm
+          designated as "mandatory to implement" by the IETF; currently
+          the only one is RSASHA1.
+        </p>
+<p>
+          The following command will generate a 768-bit RSASHA1 key for
+          the <code class="filename">child.example</code> zone:
+        </p>
+<p>
+          <strong class="userinput"><code>dnssec-keygen -a RSASHA1 -b 768 -n ZONE child.example.</code></strong>
+        </p>
+<p>
+          Two output files will be produced:
+          <code class="filename">Kchild.example.+005+12345.key</code> and
+          <code class="filename">Kchild.example.+005+12345.private</code>
+          (where
+          12345 is an example of a key tag).  The key filenames contain
+          the key name (<code class="filename">child.example.</code>),
+          algorithm (3
+          is DSA, 1 is RSAMD5, 5 is RSASHA1, etc.), and the key tag (12345 in
+          this case).
+          The private key (in the <code class="filename">.private</code>
+          file) is
+          used to generate signatures, and the public key (in the
+          <code class="filename">.key</code> file) is used for signature
+          verification.
+        </p>
+<p>
+          To generate another key with the same properties (but with
+          a different key tag), repeat the above command.
+        </p>
+<p>
+          The public keys should be inserted into the zone file by
+          including the <code class="filename">.key</code> files using
+          <span><strong class="command">$INCLUDE</strong></span> statements.
+        </p>
+</div>
+<div class="sect2" lang="en">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="id2571795"></a>Signing the Zone</h3></div></div></div>
+<p>
+          The <span><strong class="command">dnssec-signzone</strong></span> program is used
+          to
+          sign a zone.
+        </p>
+<p>
+          Any <code class="filename">keyset</code> files corresponding
+          to secure subzones should be present.  The zone signer will
+          generate <code class="literal">NSEC</code> and <code class="literal">RRSIG</code>
+          records for the zone, as well as <code class="literal">DS</code>
+          for
+          the child zones if <code class="literal">'-d'</code> is specified.
+                If <code class="literal">'-d'</code> is not specified, then
+          DS RRsets for
+          the secure child zones need to be added manually.
+        </p>
+<p>
+          The following command signs the zone, assuming it is in a
+          file called <code class="filename">zone.child.example</code>.  By
+                default, all zone keys which have an available private key are
+                used to generate signatures.
+        </p>
+<p>
+          <strong class="userinput"><code>dnssec-signzone -o child.example zone.child.example</code></strong>
+        </p>
+<p>
+          One output file is produced:
+          <code class="filename">zone.child.example.signed</code>.  This
+          file
+          should be referenced by <code class="filename">named.conf</code>
+          as the
+          input file for the zone.
+        </p>
+<p><span><strong class="command">dnssec-signzone</strong></span>
+          will also produce a keyset and dsset files and optionally a
+          dlvset file.  These are used to provide the parent zone
+          administrators with the <code class="literal">DNSKEYs</code> (or their
+          corresponding <code class="literal">DS</code> records) that are the
+          secure entry point to the zone.
+        </p>
+</div>
+<div class="sect2" lang="en">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="id2571874"></a>Configuring Servers</h3></div></div></div>
+<p>
+          To enable <span><strong class="command">named</strong></span> to respond appropriately
+          to DNS requests from DNSSEC aware clients,
+          <span><strong class="command">dnssec-enable</strong></span> must be set to yes.
+        </p>
+<p>
+          To enable <span><strong class="command">named</strong></span> to validate answers from
+          other servers both <span><strong class="command">dnssec-enable</strong></span> and
+          <span><strong class="command">dnssec-validation</strong></span> must be set and some
+          <span><strong class="command">trusted-keys</strong></span> must be configured
+          into <code class="filename">named.conf</code>.
+        </p>
+<p>
+          <span><strong class="command">trusted-keys</strong></span> are copies of DNSKEY RRs
+          for zones that are used to form the first link in the
+          cryptographic chain of trust.  All keys listed in
+          <span><strong class="command">trusted-keys</strong></span> (and corresponding zones)
+          are deemed to exist and only the listed keys will be used
+          to validated the DNSKEY RRset that they are from.
+        </p>
+<p>
+          <span><strong class="command">trusted-keys</strong></span> are described in more detail
+          later in this document.
+        </p>
+<p>
+          Unlike <acronym class="acronym">BIND</acronym> 8, <acronym class="acronym">BIND</acronym>
+          9 does not verify signatures on load, so zone keys for
+          authoritative zones do not need to be specified in the
+          configuration file.
+        </p>
+<p>
+          After DNSSEC gets established, a typical DNSSEC configuration
+          will look something like the following.  It has a one or
+          more public keys for the root.  This allows answers from
+          outside the organization to be validated.  It will also
+          have several keys for parts of the namespace the organization
+          controls.  These are here to ensure that named is immune
+          to compromises in the DNSSEC components of the security
+          of parent zones.
+        </p>
+<pre class="programlisting">
+trusted-keys {
+
+        /* Root Key */
+"." 257 3 3 "BNY4wrWM1nCfJ+CXd0rVXyYmobt7sEEfK3clRbGaTwSJxrGkxJWoZu6I7PzJu/
+             E9gx4UC1zGAHlXKdE4zYIpRhaBKnvcC2U9mZhkdUpd1Vso/HAdjNe8LmMlnzY3
+             zy2Xy4klWOADTPzSv9eamj8V18PHGjBLaVtYvk/ln5ZApjYghf+6fElrmLkdaz
+             MQ2OCnACR817DF4BBa7UR/beDHyp5iWTXWSi6XmoJLbG9Scqc7l70KDqlvXR3M
+             /lUUVRbkeg1IPJSidmK3ZyCllh4XSKbje/45SKucHgnwU5jefMtq66gKodQj+M
+             iA21AfUVe7u99WzTLzY3qlxDhxYQQ20FQ97S+LKUTpQcq27R7AT3/V5hRQxScI
+             Nqwcz4jYqZD2fQdgxbcDTClU0CRBdiieyLMNzXG3";
+
+/* Key for our organization's forward zone */
+example.com. 257 3 5 "AwEAAaxPMcR2x0HbQV4WeZB6oEDX+r0QM65KbhTjrW1ZaARmPhEZZe
+                      3Y9ifgEuq7vZ/zGZUdEGNWy+JZzus0lUptwgjGwhUS1558Hb4JKUbb
+                      OTcM8pwXlj0EiX3oDFVmjHO444gLkBO UKUf/mC7HvfwYH/Be22GnC
+                      lrinKJp1Og4ywzO9WglMk7jbfW33gUKvirTHr25GL7STQUzBb5Usxt
+                      8lgnyTUHs1t3JwCY5hKZ6CqFxmAVZP20igTixin/1LcrgX/KMEGd/b
+                      iuvF4qJCyduieHukuY3H4XMAcR+xia2 nIUPvm/oyWR8BW/hWdzOvn
+                      SCThlHf3xiYleDbt/o1OTQ09A0=";
+
+/* Key for our reverse zone. */
+2.0.192.IN-ADDRPA.NET. 257 3 5 "AQOnS4xn/IgOUpBPJ3bogzwcxOdNax071L18QqZnQQQA
+                                VVr+iLhGTnNGp3HoWQLUIzKrJVZ3zggy3WwNT6kZo6c0
+                                tszYqbtvchmgQC8CzKojM/W16i6MG/ea fGU3siaOdS0
+                                yOI6BgPsw+YZdzlYMaIJGf4M4dyoKIhzdZyQ2bYQrjyQ
+                                4LB0lC7aOnsMyYKHHYeRv PxjIQXmdqgOJGq+vsevG06
+                                zW+1xgYJh9rCIfnm1GX/KMgxLPG2vXTD/RnLX+D3T3UL
+                                7HJYHJhAZD5L59VvjSPsZJHeDCUyWYrvPZesZDIRvhDD
+                                52SKvbheeTJUm6EhkzytNN2SN96QRk8j/iI8ib";
+};
+
+options {
+        ...
+        dnssec-enable yes;
+        dnssec-validation yes;
+};
+</pre>
+<div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
+<h3 class="title">Note</h3>
+          None of the keys listed in this example are valid.  In particular,
+          the root key is not valid.
+        </div>
+</div>
+</div>
+<div class="sect1" lang="en">
+<div class="titlepage"><div><div><h2 class="title" style="clear: both">
+<a name="id2572153"></a>IPv6 Support in <acronym class="acronym">BIND</acronym> 9</h2></div></div></div>
+<p>
+        <acronym class="acronym">BIND</acronym> 9 fully supports all currently
+        defined forms of IPv6
+        name to address and address to name lookups.  It will also use
+        IPv6 addresses to make queries when running on an IPv6 capable
+        system.
+      </p>
+<p>
+        For forward lookups, <acronym class="acronym">BIND</acronym> 9 supports
+        only AAAA records.  RFC 3363 deprecated the use of A6 records,
+        and client-side support for A6 records was accordingly removed
+        from <acronym class="acronym">BIND</acronym> 9.
+        However, authoritative <acronym class="acronym">BIND</acronym> 9 name servers still
+        load zone files containing A6 records correctly, answer queries
+        for A6 records, and accept zone transfer for a zone containing A6
+        records.
+      </p>
+<p>
+        For IPv6 reverse lookups, <acronym class="acronym">BIND</acronym> 9 supports
+        the traditional "nibble" format used in the
+        <span class="emphasis"><em>ip6.arpa</em></span> domain, as well as the older, deprecated
+        <span class="emphasis"><em>ip6.int</em></span> domain.
+        Older versions of <acronym class="acronym">BIND</acronym> 9 
+        supported the "binary label" (also known as "bitstring") format,
+        but support of binary labels has been completely removed per
+        RFC 3363.
+        Many applications in <acronym class="acronym">BIND</acronym> 9 do not understand
+        the binary label format at all any more, and will return an
+        error if given.
+        In particular, an authoritative <acronym class="acronym">BIND</acronym> 9
+        name server will not load a zone file containing binary labels.
+      </p>
+<p>
+        For an overview of the format and structure of IPv6 addresses,
+        see <a href="Bv9ARM.ch09.html#ipv6addresses" title="IPv6 addresses (AAAA)">the section called &#8220;IPv6 addresses (AAAA)&#8221;</a>.
+      </p>
+<div class="sect2" lang="en">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="id2572215"></a>Address Lookups Using AAAA Records</h3></div></div></div>
+<p>
+          The IPv6 AAAA record is a parallel to the IPv4 A record,
+          and, unlike the deprecated A6 record, specifies the entire
+          IPv6 address in a single record.  For example,
+        </p>
+<pre class="programlisting">
+$ORIGIN example.com.
+host            3600    IN      AAAA    2001:db8::1
+</pre>
+<p>
+          Use of IPv4-in-IPv6 mapped addresses is not recommended.
+          If a host has an IPv4 address, use an A record, not
+          a AAAA, with <code class="literal">::ffff:192.168.42.1</code> as
+          the address.
+        </p>
+</div>
+<div class="sect2" lang="en">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="id2572236"></a>Address to Name Lookups Using Nibble Format</h3></div></div></div>
+<p>
+          When looking up an address in nibble format, the address
+          components are simply reversed, just as in IPv4, and
+          <code class="literal">ip6.arpa.</code> is appended to the
+          resulting name.
+          For example, the following would provide reverse name lookup for
+          a host with address
+          <code class="literal">2001:db8::1</code>.
+        </p>
+<pre class="programlisting">
+$ORIGIN 0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa.
+1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0   14400 IN      PTR     host.example.com.
+</pre>
+</div>
+</div>
+</div>
+<div class="navfooter">
+<hr>
+<table width="100%" summary="Navigation footer">
+<tr>
+<td width="40%" align="left">
+<a accesskey="p" href="Bv9ARM.ch03.html">Prev</a> </td>
+<td width="20%" align="center"> </td>
+<td width="40%" align="right"> <a accesskey="n" href="Bv9ARM.ch05.html">Next</a>
+</td>
+</tr>
+<tr>
+<td width="40%" align="left" valign="top">Chapter 3. Name Server Configuration </td>
+<td width="20%" align="center"><a accesskey="h" href="Bv9ARM.html">Home</a></td>
+<td width="40%" align="right" valign="top"> Chapter 5. The <acronym class="acronym">BIND</acronym> 9 Lightweight Resolver</td>
+</tr>
+</table>
+</div>
+</body>
+</html>
diff --git a/doc/arm/Bv9ARM.ch05.html b/doc/arm/Bv9ARM.ch05.html
new file mode 100644
index 0000000..80418b9
--- /dev/null
+++ b/doc/arm/Bv9ARM.ch05.html
@@ -0,0 +1,143 @@
+<!--
+ - Copyright (C) 2004-2007 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2000-2003 Internet Software Consortium.
+ - 
+ - Permission to use, copy, modify, and distribute this software for any
+ - purpose with or without fee is hereby granted, provided that the above
+ - copyright notice and this permission notice appear in all copies.
+ - 
+ - THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
+ - REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
+ - AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
+ - INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
+ - LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
+ - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
+ - PERFORMANCE OF THIS SOFTWARE.
+-->
+<!-- $Id: Bv9ARM.ch05.html,v 1.33.18.33 2007/10/31 01:35:58 marka Exp $ -->
+<html>
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
+<title>Chapter 5. The BIND 9 Lightweight Resolver</title>
+<meta name="generator" content="DocBook XSL Stylesheets V1.71.1">
+<link rel="start" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual">
+<link rel="up" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual">
+<link rel="prev" href="Bv9ARM.ch04.html" title="Chapter 4. Advanced DNS Features">
+<link rel="next" href="Bv9ARM.ch06.html" title="Chapter 6. BIND 9 Configuration Reference">
+</head>
+<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
+<div class="navheader">
+<table width="100%" summary="Navigation header">
+<tr><th colspan="3" align="center">Chapter 5. The <acronym class="acronym">BIND</acronym> 9 Lightweight Resolver</th></tr>
+<tr>
+<td width="20%" align="left">
+<a accesskey="p" href="Bv9ARM.ch04.html">Prev</a> </td>
+<th width="60%" align="center"> </th>
+<td width="20%" align="right"> <a accesskey="n" href="Bv9ARM.ch06.html">Next</a>
+</td>
+</tr>
+</table>
+<hr>
+</div>
+<div class="chapter" lang="en">
+<div class="titlepage"><div><div><h2 class="title">
+<a name="Bv9ARM.ch05"></a>Chapter 5. The <acronym class="acronym">BIND</acronym> 9 Lightweight Resolver</h2></div></div></div>
+<div class="toc">
+<p><b>Table of Contents</b></p>
+<dl>
+<dt><span class="sect1"><a href="Bv9ARM.ch05.html#id2572269">The Lightweight Resolver Library</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch05.html#lwresd">Running a Resolver Daemon</a></span></dt>
+</dl>
+</div>
+<div class="sect1" lang="en">
+<div class="titlepage"><div><div><h2 class="title" style="clear: both">
+<a name="id2572269"></a>The Lightweight Resolver Library</h2></div></div></div>
+<p>
+        Traditionally applications have been linked with a stub resolver
+        library that sends recursive DNS queries to a local caching name
+        server.
+      </p>
+<p>
+        IPv6 once introduced new complexity into the resolution process,
+        such as following A6 chains and DNAME records, and simultaneous
+        lookup of IPv4 and IPv6 addresses.  Though most of the complexity was
+        then removed, these are hard or impossible
+        to implement in a traditional stub resolver.
+      </p>
+<p>
+        <acronym class="acronym">BIND</acronym> 9 therefore can also provide resolution
+        services to local clients
+        using a combination of a lightweight resolver library and a resolver
+        daemon process running on the local host.  These communicate using
+        a simple UDP-based protocol, the "lightweight resolver protocol"
+        that is distinct from and simpler than the full DNS protocol.
+      </p>
+</div>
+<div class="sect1" lang="en">
+<div class="titlepage"><div><div><h2 class="title" style="clear: both">
+<a name="lwresd"></a>Running a Resolver Daemon</h2></div></div></div>
+<p>
+        To use the lightweight resolver interface, the system must
+        run the resolver daemon <span><strong class="command">lwresd</strong></span> or a
+        local
+        name server configured with a <span><strong class="command">lwres</strong></span>
+        statement.
+      </p>
+<p>
+        By default, applications using the lightweight resolver library will
+        make
+        UDP requests to the IPv4 loopback address (127.0.0.1) on port 921.
+        The
+        address can be overridden by <span><strong class="command">lwserver</strong></span>
+        lines in
+        <code class="filename">/etc/resolv.conf</code>.
+      </p>
+<p>
+        The daemon currently only looks in the DNS, but in the future
+        it may use other sources such as <code class="filename">/etc/hosts</code>,
+        NIS, etc.
+      </p>
+<p>
+        The <span><strong class="command">lwresd</strong></span> daemon is essentially a
+        caching-only name server that responds to requests using the
+        lightweight
+        resolver protocol rather than the DNS protocol.  Because it needs
+        to run on each host, it is designed to require no or minimal
+        configuration.
+        Unless configured otherwise, it uses the name servers listed on
+        <span><strong class="command">nameserver</strong></span> lines in <code class="filename">/etc/resolv.conf</code>
+        as forwarders, but is also capable of doing the resolution
+        autonomously if
+        none are specified.
+      </p>
+<p>
+        The <span><strong class="command">lwresd</strong></span> daemon may also be
+        configured with a
+        <code class="filename">named.conf</code> style configuration file,
+        in
+        <code class="filename">/etc/lwresd.conf</code> by default.  A name
+        server may also
+        be configured to act as a lightweight resolver daemon using the
+        <span><strong class="command">lwres</strong></span> statement in <code class="filename">named.conf</code>.
+      </p>
+</div>
+</div>
+<div class="navfooter">
+<hr>
+<table width="100%" summary="Navigation footer">
+<tr>
+<td width="40%" align="left">
+<a accesskey="p" href="Bv9ARM.ch04.html">Prev</a> </td>
+<td width="20%" align="center"> </td>
+<td width="40%" align="right"> <a accesskey="n" href="Bv9ARM.ch06.html">Next</a>
+</td>
+</tr>
+<tr>
+<td width="40%" align="left" valign="top">Chapter 4. Advanced DNS Features </td>
+<td width="20%" align="center"><a accesskey="h" href="Bv9ARM.html">Home</a></td>
+<td width="40%" align="right" valign="top"> Chapter 6. <acronym class="acronym">BIND</acronym> 9 Configuration Reference</td>
+</tr>
+</table>
+</div>
+</body>
+</html>
diff --git a/doc/arm/Bv9ARM.ch06.html b/doc/arm/Bv9ARM.ch06.html
new file mode 100644
index 0000000..d829a17
--- /dev/null
+++ b/doc/arm/Bv9ARM.ch06.html
@@ -0,0 +1,7114 @@
+<!--
+ - Copyright (C) 2004-2007 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2000-2003 Internet Software Consortium.
+ - 
+ - Permission to use, copy, modify, and distribute this software for any
+ - purpose with or without fee is hereby granted, provided that the above
+ - copyright notice and this permission notice appear in all copies.
+ - 
+ - THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
+ - REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
+ - AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
+ - INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
+ - LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
+ - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
+ - PERFORMANCE OF THIS SOFTWARE.
+-->
+<!-- $Id: Bv9ARM.ch06.html,v 1.82.18.73 2007/10/31 01:35:58 marka Exp $ -->
+<html>
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
+<title>Chapter 6. BIND 9 Configuration Reference</title>
+<meta name="generator" content="DocBook XSL Stylesheets V1.71.1">
+<link rel="start" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual">
+<link rel="up" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual">
+<link rel="prev" href="Bv9ARM.ch05.html" title="Chapter 5. The BIND 9 Lightweight Resolver">
+<link rel="next" href="Bv9ARM.ch07.html" title="Chapter 7. BIND 9 Security Considerations">
+</head>
+<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
+<div class="navheader">
+<table width="100%" summary="Navigation header">
+<tr><th colspan="3" align="center">Chapter 6. <acronym class="acronym">BIND</acronym> 9 Configuration Reference</th></tr>
+<tr>
+<td width="20%" align="left">
+<a accesskey="p" href="Bv9ARM.ch05.html">Prev</a> </td>
+<th width="60%" align="center"> </th>
+<td width="20%" align="right"> <a accesskey="n" href="Bv9ARM.ch07.html">Next</a>
+</td>
+</tr>
+</table>
+<hr>
+</div>
+<div class="chapter" lang="en">
+<div class="titlepage"><div><div><h2 class="title">
+<a name="Bv9ARM.ch06"></a>Chapter 6. <acronym class="acronym">BIND</acronym> 9 Configuration Reference</h2></div></div></div>
+<div class="toc">
+<p><b>Table of Contents</b></p>
+<dl>
+<dt><span class="sect1"><a href="Bv9ARM.ch06.html#configuration_file_elements">Configuration File Elements</a></span></dt>
+<dd><dl>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#address_match_lists">Address Match Lists</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2573480">Comment Syntax</a></span></dt>
+</dl></dd>
+<dt><span class="sect1"><a href="Bv9ARM.ch06.html#Configuration_File_Grammar">Configuration File Grammar</a></span></dt>
+<dd><dl>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2574092"><span><strong class="command">acl</strong></span> Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#acl"><span><strong class="command">acl</strong></span> Statement Definition and
+          Usage</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2574282"><span><strong class="command">controls</strong></span> Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#controls_statement_definition_and_usage"><span><strong class="command">controls</strong></span> Statement Definition and
+          Usage</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2574711"><span><strong class="command">include</strong></span> Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2574726"><span><strong class="command">include</strong></span> Statement Definition and
+          Usage</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2574749"><span><strong class="command">key</strong></span> Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2574771"><span><strong class="command">key</strong></span> Statement Definition and Usage</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2574930"><span><strong class="command">logging</strong></span> Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2575056"><span><strong class="command">logging</strong></span> Statement Definition and
+          Usage</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2576406"><span><strong class="command">lwres</strong></span> Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2576480"><span><strong class="command">lwres</strong></span> Statement Definition and Usage</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2576544"><span><strong class="command">masters</strong></span> Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2576587"><span><strong class="command">masters</strong></span> Statement Definition and
+          Usage</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2576602"><span><strong class="command">options</strong></span> Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#options"><span><strong class="command">options</strong></span> Statement Definition and
+          Usage</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#server_statement_grammar"><span><strong class="command">server</strong></span> Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#server_statement_definition_and_usage"><span><strong class="command">server</strong></span> Statement Definition and
+            Usage</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2585361"><span><strong class="command">trusted-keys</strong></span> Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2585410"><span><strong class="command">trusted-keys</strong></span> Statement Definition
+            and Usage</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#view_statement_grammar"><span><strong class="command">view</strong></span> Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2585490"><span><strong class="command">view</strong></span> Statement Definition and Usage</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#zone_statement_grammar"><span><strong class="command">zone</strong></span>
+            Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2586798"><span><strong class="command">zone</strong></span> Statement Definition and Usage</a></span></dt>
+</dl></dd>
+<dt><span class="sect1"><a href="Bv9ARM.ch06.html#id2589080">Zone File</a></span></dt>
+<dd><dl>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#types_of_resource_records_and_when_to_use_them">Types of Resource Records and When to Use Them</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2591101">Discussion of MX Records</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#Setting_TTLs">Setting TTLs</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2591653">Inverse Mapping in IPv4</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2591848">Other Zone File Directives</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2592173"><acronym class="acronym">BIND</acronym> Master File Extension: the  <span><strong class="command">$GENERATE</strong></span> Directive</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#zonefile_format">Additional File Formats</a></span></dt>
+</dl></dd>
+</dl>
+</div>
+<p>
+      <acronym class="acronym">BIND</acronym> 9 configuration is broadly similar
+      to <acronym class="acronym">BIND</acronym> 8; however, there are a few new
+      areas
+      of configuration, such as views. <acronym class="acronym">BIND</acronym>
+      8 configuration files should work with few alterations in <acronym class="acronym">BIND</acronym>
+      9, although more complex configurations should be reviewed to check
+      if they can be more efficiently implemented using the new features
+      found in <acronym class="acronym">BIND</acronym> 9.
+    </p>
+<p>
+      <acronym class="acronym">BIND</acronym> 4 configuration files can be
+      converted to the new format
+      using the shell script
+      <code class="filename">contrib/named-bootconf/named-bootconf.sh</code>.
+    </p>
+<div class="sect1" lang="en">
+<div class="titlepage"><div><div><h2 class="title" style="clear: both">
+<a name="configuration_file_elements"></a>Configuration File Elements</h2></div></div></div>
+<p>
+        Following is a list of elements used throughout the <acronym class="acronym">BIND</acronym> configuration
+        file documentation:
+      </p>
+<div class="informaltable"><table border="1">
+<colgroup>
+<col>
+<col>
+</colgroup>
+<tbody>
+<tr>
+<td>
+                <p>
+                  <code class="varname">acl_name</code>
+                </p>
+              </td>
+<td>
+                <p>
+                  The name of an <code class="varname">address_match_list</code> as
+                  defined by the <span><strong class="command">acl</strong></span> statement.
+                </p>
+              </td>
+</tr>
+<tr>
+<td>
+                <p>
+                  <code class="varname">address_match_list</code>
+                </p>
+              </td>
+<td>
+                <p>
+                  A list of one or more
+                  <code class="varname">ip_addr</code>,
+                  <code class="varname">ip_prefix</code>, <code class="varname">key_id</code>,
+                  or <code class="varname">acl_name</code> elements, see
+                  <a href="Bv9ARM.ch06.html#address_match_lists" title="Address Match Lists">the section called &#8220;Address Match Lists&#8221;</a>.
+                </p>
+              </td>
+</tr>
+<tr>
+<td>
+                <p>
+                  <code class="varname">masters_list</code>
+                </p>
+              </td>
+<td>
+                <p>
+                  A named list of one or more <code class="varname">ip_addr</code>
+                  with optional <code class="varname">key_id</code> and/or
+                  <code class="varname">ip_port</code>.
+                  A <code class="varname">masters_list</code> may include other
+                  <code class="varname">masters_lists</code>.
+                </p>
+              </td>
+</tr>
+<tr>
+<td>
+                <p>
+                  <code class="varname">domain_name</code>
+                </p>
+              </td>
+<td>
+                <p>
+                  A quoted string which will be used as
+                  a DNS name, for example "<code class="literal">my.test.domain</code>".
+                </p>
+              </td>
+</tr>
+<tr>
+<td>
+                <p>
+                  <code class="varname">dotted_decimal</code>
+                </p>
+              </td>
+<td>
+                <p>
+                  One to four integers valued 0 through
+                  255 separated by dots (`.'), such as <span><strong class="command">123</strong></span>,
+                  <span><strong class="command">45.67</strong></span> or <span><strong class="command">89.123.45.67</strong></span>.
+                </p>
+              </td>
+</tr>
+<tr>
+<td>
+                <p>
+                  <code class="varname">ip4_addr</code>
+                </p>
+              </td>
+<td>
+                <p>
+                  An IPv4 address with exactly four elements
+                  in <code class="varname">dotted_decimal</code> notation.
+                </p>
+              </td>
+</tr>
+<tr>
+<td>
+                <p>
+                  <code class="varname">ip6_addr</code>
+                </p>
+              </td>
+<td>
+                <p>
+                  An IPv6 address, such as <span><strong class="command">2001:db8::1234</strong></span>.
+                  IPv6 scoped addresses that have ambiguity on their scope
+                  zones must be
+                  disambiguated by an appropriate zone ID with the percent
+                  character
+                  (`%') as delimiter.
+                  It is strongly recommended to use string zone names rather
+                  than
+                  numeric identifiers, in order to be robust against system
+                  configuration changes.
+                  However, since there is no standard mapping for such names
+                  and
+                  identifier values, currently only interface names as link
+                  identifiers
+                  are supported, assuming one-to-one mapping between
+                  interfaces and links.
+                  For example, a link-local address <span><strong class="command">fe80::1</strong></span> on the
+                  link attached to the interface <span><strong class="command">ne0</strong></span>
+                  can be specified as <span><strong class="command">fe80::1%ne0</strong></span>.
+                  Note that on most systems link-local addresses always have
+                  the
+                  ambiguity, and need to be disambiguated.
+                </p>
+              </td>
+</tr>
+<tr>
+<td>
+                <p>
+                  <code class="varname">ip_addr</code>
+                </p>
+              </td>
+<td>
+                <p>
+                  An <code class="varname">ip4_addr</code> or <code class="varname">ip6_addr</code>.
+                </p>
+              </td>
+</tr>
+<tr>
+<td>
+                <p>
+                  <code class="varname">ip_port</code>
+                </p>
+              </td>
+<td>
+                <p>
+                  An IP port <code class="varname">number</code>.
+                  The <code class="varname">number</code> is limited to 0
+                  through 65535, with values
+                  below 1024 typically restricted to use by processes running
+                  as root.
+                  In some cases, an asterisk (`*') character can be used as a
+                  placeholder to
+                  select a random high-numbered port.
+                </p>
+              </td>
+</tr>
+<tr>
+<td>
+                <p>
+                  <code class="varname">ip_prefix</code>
+                </p>
+              </td>
+<td>
+                <p>
+                  An IP network specified as an <code class="varname">ip_addr</code>,
+                  followed by a slash (`/') and then the number of bits in the
+                  netmask.
+                  Trailing zeros in a <code class="varname">ip_addr</code>
+                  may omitted.
+                  For example, <span><strong class="command">127/8</strong></span> is the
+                  network <span><strong class="command">127.0.0.0</strong></span> with
+                  netmask <span><strong class="command">255.0.0.0</strong></span> and <span><strong class="command">1.2.3.0/28</strong></span> is
+                  network <span><strong class="command">1.2.3.0</strong></span> with netmask <span><strong class="command">255.255.255.240</strong></span>.
+                </p>
+              </td>
+</tr>
+<tr>
+<td>
+                <p>
+                  <code class="varname">key_id</code>
+                </p>
+              </td>
+<td>
+                <p>
+                  A <code class="varname">domain_name</code> representing
+                  the name of a shared key, to be used for transaction
+                  security.
+                </p>
+              </td>
+</tr>
+<tr>
+<td>
+                <p>
+                  <code class="varname">key_list</code>
+                </p>
+              </td>
+<td>
+                <p>
+                  A list of one or more
+                  <code class="varname">key_id</code>s,
+                  separated by semicolons and ending with a semicolon.
+                </p>
+              </td>
+</tr>
+<tr>
+<td>
+                <p>
+                  <code class="varname">number</code>
+                </p>
+              </td>
+<td>
+                <p>
+                  A non-negative 32-bit integer
+                  (i.e., a number between 0 and 4294967295, inclusive).
+                  Its acceptable value might further
+                  be limited by the context in which it is used.
+                </p>
+              </td>
+</tr>
+<tr>
+<td>
+                <p>
+                  <code class="varname">path_name</code>
+                </p>
+              </td>
+<td>
+                <p>
+                  A quoted string which will be used as
+                  a pathname, such as <code class="filename">zones/master/my.test.domain</code>.
+                </p>
+              </td>
+</tr>
+<tr>
+<td>
+                <p>
+                  <code class="varname">size_spec</code>
+                </p>
+              </td>
+<td>
+                <p>
+                  A number, the word <strong class="userinput"><code>unlimited</code></strong>,
+                  or the word <strong class="userinput"><code>default</code></strong>.
+                </p>
+                <p>
+                  An <code class="varname">unlimited</code> <code class="varname">size_spec</code> requests unlimited
+                  use, or the maximum available amount. A <code class="varname">default size_spec</code> uses
+                  the limit that was in force when the server was started.
+                </p>
+                <p>
+                  A <code class="varname">number</code> can optionally be
+                  followed by a scaling factor:
+                  <strong class="userinput"><code>K</code></strong> or <strong class="userinput"><code>k</code></strong>
+                  for kilobytes,
+                  <strong class="userinput"><code>M</code></strong> or <strong class="userinput"><code>m</code></strong>
+                  for megabytes, and
+                  <strong class="userinput"><code>G</code></strong> or <strong class="userinput"><code>g</code></strong> for gigabytes,
+                  which scale by 1024, 1024*1024, and 1024*1024*1024
+                  respectively.
+                </p>
+                <p>
+                  The value must be representable as a 64-bit unsigned integer
+                  (0 to 18446744073709551615, inclusive).
+                  Using <code class="varname">unlimited</code> is the best
+                  way
+                  to safely set a really large number.
+                </p>
+              </td>
+</tr>
+<tr>
+<td>
+                <p>
+                  <code class="varname">yes_or_no</code>
+                </p>
+              </td>
+<td>
+                <p>
+                  Either <strong class="userinput"><code>yes</code></strong> or <strong class="userinput"><code>no</code></strong>.
+                  The words <strong class="userinput"><code>true</code></strong> and <strong class="userinput"><code>false</code></strong> are
+                  also accepted, as are the numbers <strong class="userinput"><code>1</code></strong>
+                  and <strong class="userinput"><code>0</code></strong>.
+                </p>
+              </td>
+</tr>
+<tr>
+<td>
+                <p>
+                  <code class="varname">dialup_option</code>
+                </p>
+              </td>
+<td>
+                <p>
+                  One of <strong class="userinput"><code>yes</code></strong>,
+                  <strong class="userinput"><code>no</code></strong>, <strong class="userinput"><code>notify</code></strong>,
+                  <strong class="userinput"><code>notify-passive</code></strong>, <strong class="userinput"><code>refresh</code></strong> or
+                  <strong class="userinput"><code>passive</code></strong>.
+                  When used in a zone, <strong class="userinput"><code>notify-passive</code></strong>,
+                  <strong class="userinput"><code>refresh</code></strong>, and <strong class="userinput"><code>passive</code></strong>
+                  are restricted to slave and stub zones.
+                </p>
+              </td>
+</tr>
+</tbody>
+</table></div>
+<div class="sect2" lang="en">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="address_match_lists"></a>Address Match Lists</h3></div></div></div>
+<div class="sect3" lang="en">
+<div class="titlepage"><div><div><h4 class="title">
+<a name="id2573277"></a>Syntax</h4></div></div></div>
+<pre class="programlisting"><code class="varname">address_match_list</code> = address_match_list_element ;
+  [<span class="optional"> address_match_list_element; ... </span>]
+<code class="varname">address_match_list_element</code> = [<span class="optional"> ! </span>] (ip_address [<span class="optional">/length</span>] |
+   key key_id | acl_name | { address_match_list } )
+</pre>
+</div>
+<div class="sect3" lang="en">
+<div class="titlepage"><div><div><h4 class="title">
+<a name="id2573305"></a>Definition and Usage</h4></div></div></div>
+<p>
+            Address match lists are primarily used to determine access
+            control for various server operations. They are also used in
+            the <span><strong class="command">listen-on</strong></span> and <span><strong class="command">sortlist</strong></span>
+            statements. The elements
+            which constitute an address match list can be any of the
+            following:
+          </p>
+<div class="itemizedlist"><ul type="disc">
+<li>an IP address (IPv4 or IPv6)</li>
+<li>an IP prefix (in `/' notation)</li>
+<li>
+                a key ID, as defined by the <span><strong class="command">key</strong></span>
+                statement
+              </li>
+<li>the name of an address match list defined with
+                the <span><strong class="command">acl</strong></span> statement
+              </li>
+<li>a nested address match list enclosed in braces</li>
+</ul></div>
+<p>
+            Elements can be negated with a leading exclamation mark (`!'),
+            and the match list names "any", "none", "localhost", and
+            "localnets"
+            are predefined. More information on those names can be found in
+            the description of the acl statement.
+          </p>
+<p>
+            The addition of the key clause made the name of this syntactic
+            element something of a misnomer, since security keys can be used
+            to validate access without regard to a host or network address.
+            Nonetheless,
+            the term "address match list" is still used throughout the
+            documentation.
+          </p>
+<p>
+            When a given IP address or prefix is compared to an address
+            match list, the list is traversed in order until an element
+            matches.
+            The interpretation of a match depends on whether the list is being
+            used
+            for access control, defining listen-on ports, or in a sortlist,
+            and whether the element was negated.
+          </p>
+<p>
+            When used as an access control list, a non-negated match
+            allows access and a negated match denies access. If
+            there is no match, access is denied. The clauses
+            <span><strong class="command">allow-notify</strong></span>,
+            <span><strong class="command">allow-query</strong></span>,
+            <span><strong class="command">allow-query-cache</strong></span>,
+            <span><strong class="command">allow-transfer</strong></span>,
+            <span><strong class="command">allow-update</strong></span>,
+            <span><strong class="command">allow-update-forwarding</strong></span>, and
+            <span><strong class="command">blackhole</strong></span> all use address match
+            lists.  Similarly, the listen-on option will cause the
+            server to not accept queries on any of the machine's
+            addresses which do not match the list.
+          </p>
+<p>
+            Because of the first-match aspect of the algorithm, an element
+            that defines a subset of another element in the list should come
+            before the broader element, regardless of whether either is
+            negated. For
+            example, in
+            <span><strong class="command">1.2.3/24; ! 1.2.3.13;</strong></span> the 1.2.3.13
+            element is
+            completely useless because the algorithm will match any lookup for
+            1.2.3.13 to the 1.2.3/24 element.
+            Using <span><strong class="command">! 1.2.3.13; 1.2.3/24</strong></span> fixes
+            that problem by having 1.2.3.13 blocked by the negation but all
+            other 1.2.3.* hosts fall through.
+          </p>
+</div>
+</div>
+<div class="sect2" lang="en">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="id2573480"></a>Comment Syntax</h3></div></div></div>
+<p>
+          The <acronym class="acronym">BIND</acronym> 9 comment syntax allows for
+          comments to appear
+          anywhere that whitespace may appear in a <acronym class="acronym">BIND</acronym> configuration
+          file. To appeal to programmers of all kinds, they can be written
+          in the C, C++, or shell/perl style.
+        </p>
+<div class="sect3" lang="en">
+<div class="titlepage"><div><div><h4 class="title">
+<a name="id2573495"></a>Syntax</h4></div></div></div>
+<p>
+            </p>
+<pre class="programlisting">/* This is a <acronym class="acronym">BIND</acronym> comment as in C */</pre>
+<p>
+            </p>
+<pre class="programlisting">// This is a <acronym class="acronym">BIND</acronym> comment as in C++</pre>
+<p>
+            </p>
+<pre class="programlisting"># This is a <acronym class="acronym">BIND</acronym> comment as in common UNIX shells and perl</pre>
+<p>
+          </p>
+</div>
+<div class="sect3" lang="en">
+<div class="titlepage"><div><div><h4 class="title">
+<a name="id2573525"></a>Definition and Usage</h4></div></div></div>
+<p>
+            Comments may appear anywhere that whitespace may appear in
+            a <acronym class="acronym">BIND</acronym> configuration file.
+          </p>
+<p>
+            C-style comments start with the two characters /* (slash,
+            star) and end with */ (star, slash). Because they are completely
+            delimited with these characters, they can be used to comment only
+            a portion of a line or to span multiple lines.
+          </p>
+<p>
+            C-style comments cannot be nested. For example, the following
+            is not valid because the entire comment ends with the first */:
+          </p>
+<p>
+
+</p>
+<pre class="programlisting">/* This is the start of a comment.
+   This is still part of the comment.
+/* This is an incorrect attempt at nesting a comment. */
+   This is no longer in any comment. */
+</pre>
+<p>
+
+          </p>
+<p>
+            C++-style comments start with the two characters // (slash,
+            slash) and continue to the end of the physical line. They cannot
+            be continued across multiple physical lines; to have one logical
+            comment span multiple lines, each line must use the // pair.
+          </p>
+<p>
+            For example:
+          </p>
+<p>
+
+</p>
+<pre class="programlisting">// This is the start of a comment.  The next line
+// is a new comment, even though it is logically
+// part of the previous comment.
+</pre>
+<p>
+
+          </p>
+<p>
+            Shell-style (or perl-style, if you prefer) comments start
+            with the character <code class="literal">#</code> (number sign)
+            and continue to the end of the
+            physical line, as in C++ comments.
+          </p>
+<p>
+            For example:
+          </p>
+<p>
+
+</p>
+<pre class="programlisting"># This is the start of a comment.  The next line
+# is a new comment, even though it is logically
+# part of the previous comment.
+</pre>
+<p>
+
+          </p>
+<div class="warning" style="margin-left: 0.5in; margin-right: 0.5in;">
+<h3 class="title">Warning</h3>
+<p>
+              You cannot use the semicolon (`;') character
+              to start a comment such as you would in a zone file. The
+              semicolon indicates the end of a configuration
+              statement.
+            </p>
+</div>
+</div>
+</div>
+</div>
+<div class="sect1" lang="en">
+<div class="titlepage"><div><div><h2 class="title" style="clear: both">
+<a name="Configuration_File_Grammar"></a>Configuration File Grammar</h2></div></div></div>
+<p>
+        A <acronym class="acronym">BIND</acronym> 9 configuration consists of
+        statements and comments.
+        Statements end with a semicolon. Statements and comments are the
+        only elements that can appear without enclosing braces. Many
+        statements contain a block of sub-statements, which are also
+        terminated with a semicolon.
+      </p>
+<p>
+        The following statements are supported:
+      </p>
+<div class="informaltable"><table border="1">
+<colgroup>
+<col>
+<col>
+</colgroup>
+<tbody>
+<tr>
+<td>
+                <p><span><strong class="command">acl</strong></span></p>
+              </td>
+<td>
+                <p>
+                  defines a named IP address
+                  matching list, for access control and other uses.
+                </p>
+              </td>
+</tr>
+<tr>
+<td>
+                <p><span><strong class="command">controls</strong></span></p>
+              </td>
+<td>
+                <p>
+                  declares control channels to be used
+                  by the <span><strong class="command">rndc</strong></span> utility.
+                </p>
+              </td>
+</tr>
+<tr>
+<td>
+                <p><span><strong class="command">include</strong></span></p>
+              </td>
+<td>
+                <p>
+                  includes a file.
+                </p>
+              </td>
+</tr>
+<tr>
+<td>
+                <p><span><strong class="command">key</strong></span></p>
+              </td>
+<td>
+                <p>
+                  specifies key information for use in
+                  authentication and authorization using TSIG.
+                </p>
+              </td>
+</tr>
+<tr>
+<td>
+                <p><span><strong class="command">logging</strong></span></p>
+              </td>
+<td>
+                <p>
+                  specifies what the server logs, and where
+                  the log messages are sent.
+                </p>
+              </td>
+</tr>
+<tr>
+<td>
+                <p><span><strong class="command">lwres</strong></span></p>
+              </td>
+<td>
+                <p>
+                  configures <span><strong class="command">named</strong></span> to
+                  also act as a light-weight resolver daemon (<span><strong class="command">lwresd</strong></span>).
+                </p>
+              </td>
+</tr>
+<tr>
+<td>
+                <p><span><strong class="command">masters</strong></span></p>
+              </td>
+<td>
+                <p>
+                  defines a named masters list for
+                  inclusion in stub and slave zone masters clauses.
+                </p>
+              </td>
+</tr>
+<tr>
+<td>
+                <p><span><strong class="command">options</strong></span></p>
+              </td>
+<td>
+                <p>
+                  controls global server configuration
+                  options and sets defaults for other statements.
+                </p>
+              </td>
+</tr>
+<tr>
+<td>
+                <p><span><strong class="command">server</strong></span></p>
+              </td>
+<td>
+                <p>
+                  sets certain configuration options on
+                  a per-server basis.
+                </p>
+              </td>
+</tr>
+<tr>
+<td>
+                <p><span><strong class="command">trusted-keys</strong></span></p>
+              </td>
+<td>
+                <p>
+                  defines trusted DNSSEC keys.
+                </p>
+              </td>
+</tr>
+<tr>
+<td>
+                <p><span><strong class="command">view</strong></span></p>
+              </td>
+<td>
+                <p>
+                  defines a view.
+                </p>
+              </td>
+</tr>
+<tr>
+<td>
+                <p><span><strong class="command">zone</strong></span></p>
+              </td>
+<td>
+                <p>
+                  defines a zone.
+                </p>
+              </td>
+</tr>
+</tbody>
+</table></div>
+<p>
+        The <span><strong class="command">logging</strong></span> and
+        <span><strong class="command">options</strong></span> statements may only occur once
+        per
+        configuration.
+      </p>
+<div class="sect2" lang="en">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="id2574092"></a><span><strong class="command">acl</strong></span> Statement Grammar</h3></div></div></div>
+<pre class="programlisting"><span><strong class="command">acl</strong></span> acl-name {
+    address_match_list
+};
+</pre>
+</div>
+<div class="sect2" lang="en">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="acl"></a><span><strong class="command">acl</strong></span> Statement Definition and
+          Usage</h3></div></div></div>
+<p>
+          The <span><strong class="command">acl</strong></span> statement assigns a symbolic
+          name to an address match list. It gets its name from a primary
+          use of address match lists: Access Control Lists (ACLs).
+        </p>
+<p>
+          Note that an address match list's name must be defined
+          with <span><strong class="command">acl</strong></span> before it can be used
+          elsewhere; no
+          forward references are allowed.
+        </p>
+<p>
+          The following ACLs are built-in:
+        </p>
+<div class="informaltable"><table border="1">
+<colgroup>
+<col>
+<col>
+</colgroup>
+<tbody>
+<tr>
+<td>
+                  <p><span><strong class="command">any</strong></span></p>
+                </td>
+<td>
+                  <p>
+                    Matches all hosts.
+                  </p>
+                </td>
+</tr>
+<tr>
+<td>
+                  <p><span><strong class="command">none</strong></span></p>
+                </td>
+<td>
+                  <p>
+                    Matches no hosts.
+                  </p>
+                </td>
+</tr>
+<tr>
+<td>
+                  <p><span><strong class="command">localhost</strong></span></p>
+                </td>
+<td>
+                  <p>
+                    Matches the IPv4 and IPv6 addresses of all network
+                    interfaces on the system.
+                  </p>
+                </td>
+</tr>
+<tr>
+<td>
+                  <p><span><strong class="command">localnets</strong></span></p>
+                </td>
+<td>
+                  <p>
+                    Matches any host on an IPv4 or IPv6 network
+                    for which the system has an interface.
+                    Some systems do not provide a way to determine the prefix
+                    lengths of
+                    local IPv6 addresses.
+                    In such a case, <span><strong class="command">localnets</strong></span>
+                    only matches the local
+                    IPv6 addresses, just like <span><strong class="command">localhost</strong></span>.
+                  </p>
+                </td>
+</tr>
+</tbody>
+</table></div>
+</div>
+<div class="sect2" lang="en">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="id2574282"></a><span><strong class="command">controls</strong></span> Statement Grammar</h3></div></div></div>
+<pre class="programlisting"><span><strong class="command">controls</strong></span> {
+   [ inet ( ip_addr | * ) [ port ip_port ] allow { <em class="replaceable"><code> address_match_list </code></em> }
+                keys { <em class="replaceable"><code>key_list</code></em> }; ]
+   [ inet ...; ]
+   [ unix <em class="replaceable"><code>path</code></em> perm <em class="replaceable"><code>number</code></em> owner <em class="replaceable"><code>number</code></em> group <em class="replaceable"><code>number</code></em> keys { <em class="replaceable"><code>key_list</code></em> }; ]
+   [ unix ...; ]
+};
+</pre>
+</div>
+<div class="sect2" lang="en">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="controls_statement_definition_and_usage"></a><span><strong class="command">controls</strong></span> Statement Definition and
+          Usage</h3></div></div></div>
+<p>
+          The <span><strong class="command">controls</strong></span> statement declares control
+          channels to be used by system administrators to control the
+          operation of the name server. These control channels are
+          used by the <span><strong class="command">rndc</strong></span> utility to send
+          commands to and retrieve non-DNS results from a name server.
+        </p>
+<p>
+          An <span><strong class="command">inet</strong></span> control channel is a TCP socket
+          listening at the specified <span><strong class="command">ip_port</strong></span> on the
+          specified <span><strong class="command">ip_addr</strong></span>, which can be an IPv4 or IPv6
+          address.  An <span><strong class="command">ip_addr</strong></span> of <code class="literal">*</code> (asterisk) is
+          interpreted as the IPv4 wildcard address; connections will be
+          accepted on any of the system's IPv4 addresses.
+          To listen on the IPv6 wildcard address,
+          use an <span><strong class="command">ip_addr</strong></span> of <code class="literal">::</code>.
+          If you will only use <span><strong class="command">rndc</strong></span> on the local host,
+          using the loopback address (<code class="literal">127.0.0.1</code>
+          or <code class="literal">::1</code>) is recommended for maximum security.
+        </p>
+<p>
+          If no port is specified, port 953 is used. The asterisk
+          "<code class="literal">*</code>" cannot be used for <span><strong class="command">ip_port</strong></span>.
+        </p>
+<p>
+          The ability to issue commands over the control channel is
+          restricted by the <span><strong class="command">allow</strong></span> and
+          <span><strong class="command">keys</strong></span> clauses.
+          Connections to the control channel are permitted based on the
+          <span><strong class="command">address_match_list</strong></span>.  This is for simple
+          IP address based filtering only; any <span><strong class="command">key_id</strong></span>
+          elements of the <span><strong class="command">address_match_list</strong></span>
+          are ignored.
+        </p>
+<p>
+          A <span><strong class="command">unix</strong></span> control channel is a UNIX domain
+          socket listening at the specified path in the file system.
+          Access to the socket is specified by the <span><strong class="command">perm</strong></span>,
+          <span><strong class="command">owner</strong></span> and <span><strong class="command">group</strong></span> clauses.
+          Note on some platforms (SunOS and Solaris) the permissions
+          (<span><strong class="command">perm</strong></span>) are applied to the parent directory
+          as the permissions on the socket itself are ignored.
+        </p>
+<p>
+          The primary authorization mechanism of the command
+          channel is the <span><strong class="command">key_list</strong></span>, which
+          contains a list of <span><strong class="command">key_id</strong></span>s.
+          Each <span><strong class="command">key_id</strong></span> in the <span><strong class="command">key_list</strong></span>
+          is authorized to execute commands over the control channel.
+          See <a href="Bv9ARM.ch03.html#rndc">Remote Name Daemon Control application</a> in <a href="Bv9ARM.ch03.html#admin_tools" title="Administrative Tools">the section called &#8220;Administrative Tools&#8221;</a>)
+          for information about configuring keys in <span><strong class="command">rndc</strong></span>.
+        </p>
+<p>
+          If no <span><strong class="command">controls</strong></span> statement is present,
+          <span><strong class="command">named</strong></span> will set up a default
+          control channel listening on the loopback address 127.0.0.1
+          and its IPv6 counterpart ::1.
+          In this case, and also when the <span><strong class="command">controls</strong></span> statement
+          is present but does not have a <span><strong class="command">keys</strong></span> clause,
+          <span><strong class="command">named</strong></span> will attempt to load the command channel key
+          from the file <code class="filename">rndc.key</code> in
+          <code class="filename">/etc</code> (or whatever <code class="varname">sysconfdir</code>
+          was specified as when <acronym class="acronym">BIND</acronym> was built).
+          To create a <code class="filename">rndc.key</code> file, run
+          <strong class="userinput"><code>rndc-confgen -a</code></strong>.
+        </p>
+<p>
+          The <code class="filename">rndc.key</code> feature was created to
+          ease the transition of systems from <acronym class="acronym">BIND</acronym> 8,
+          which did not have digital signatures on its command channel
+          messages and thus did not have a <span><strong class="command">keys</strong></span> clause.
+
+          It makes it possible to use an existing <acronym class="acronym">BIND</acronym> 8
+          configuration file in <acronym class="acronym">BIND</acronym> 9 unchanged,
+          and still have <span><strong class="command">rndc</strong></span> work the same way
+          <span><strong class="command">ndc</strong></span> worked in BIND 8, simply by executing the
+          command <strong class="userinput"><code>rndc-confgen -a</code></strong> after BIND 9 is
+          installed.
+        </p>
+<p>
+          Since the <code class="filename">rndc.key</code> feature
+          is only intended to allow the backward-compatible usage of
+          <acronym class="acronym">BIND</acronym> 8 configuration files, this
+          feature does not
+          have a high degree of configurability.  You cannot easily change
+          the key name or the size of the secret, so you should make a
+          <code class="filename">rndc.conf</code> with your own key if you
+          wish to change
+          those things.  The <code class="filename">rndc.key</code> file
+          also has its
+          permissions set such that only the owner of the file (the user that
+          <span><strong class="command">named</strong></span> is running as) can access it.
+          If you
+          desire greater flexibility in allowing other users to access
+          <span><strong class="command">rndc</strong></span> commands, then you need to create
+          a
+          <code class="filename">rndc.conf</code> file and make it group
+          readable by a group
+          that contains the users who should have access.
+        </p>
+<p>
+          To disable the command channel, use an empty
+          <span><strong class="command">controls</strong></span> statement:
+          <span><strong class="command">controls { };</strong></span>.
+        </p>
+</div>
+<div class="sect2" lang="en">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="id2574711"></a><span><strong class="command">include</strong></span> Statement Grammar</h3></div></div></div>
+<pre class="programlisting">include <em class="replaceable"><code>filename</code></em>;</pre>
+</div>
+<div class="sect2" lang="en">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="id2574726"></a><span><strong class="command">include</strong></span> Statement Definition and
+          Usage</h3></div></div></div>
+<p>
+          The <span><strong class="command">include</strong></span> statement inserts the
+          specified file at the point where the <span><strong class="command">include</strong></span>
+          statement is encountered. The <span><strong class="command">include</strong></span>
+                statement facilitates the administration of configuration
+          files
+          by permitting the reading or writing of some things but not
+          others. For example, the statement could include private keys
+          that are readable only by the name server.
+        </p>
+</div>
+<div class="sect2" lang="en">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="id2574749"></a><span><strong class="command">key</strong></span> Statement Grammar</h3></div></div></div>
+<pre class="programlisting">key <em class="replaceable"><code>key_id</code></em> {
+    algorithm <em class="replaceable"><code>string</code></em>;
+    secret <em class="replaceable"><code>string</code></em>;
+};
+</pre>
+</div>
+<div class="sect2" lang="en">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="id2574771"></a><span><strong class="command">key</strong></span> Statement Definition and Usage</h3></div></div></div>
+<p>
+          The <span><strong class="command">key</strong></span> statement defines a shared
+          secret key for use with TSIG (see <a href="Bv9ARM.ch04.html#tsig" title="TSIG">the section called &#8220;TSIG&#8221;</a>)
+          or the command channel
+          (see <a href="Bv9ARM.ch06.html#controls_statement_definition_and_usage" title="controls Statement Definition and
+          Usage">the section called &#8220;<span><strong class="command">controls</strong></span> Statement Definition and
+          Usage&#8221;</a>).
+        </p>
+<p>
+          The <span><strong class="command">key</strong></span> statement can occur at the
+          top level
+          of the configuration file or inside a <span><strong class="command">view</strong></span>
+          statement.  Keys defined in top-level <span><strong class="command">key</strong></span>
+          statements can be used in all views.  Keys intended for use in
+          a <span><strong class="command">controls</strong></span> statement
+          (see <a href="Bv9ARM.ch06.html#controls_statement_definition_and_usage" title="controls Statement Definition and
+          Usage">the section called &#8220;<span><strong class="command">controls</strong></span> Statement Definition and
+          Usage&#8221;</a>)
+          must be defined at the top level.
+        </p>
+<p>
+          The <em class="replaceable"><code>key_id</code></em>, also known as the
+          key name, is a domain name uniquely identifying the key. It can
+          be used in a <span><strong class="command">server</strong></span>
+          statement to cause requests sent to that
+          server to be signed with this key, or in address match lists to
+          verify that incoming requests have been signed with a key
+          matching this name, algorithm, and secret.
+        </p>
+<p>
+          The <em class="replaceable"><code>algorithm_id</code></em> is a string
+          that specifies a security/authentication algorithm.  Named
+          supports <code class="literal">hmac-md5</code>,
+          <code class="literal">hmac-sha1</code>, <code class="literal">hmac-sha224</code>,
+          <code class="literal">hmac-sha256</code>, <code class="literal">hmac-sha384</code>
+          and <code class="literal">hmac-sha512</code> TSIG authentication.
+          Truncated hashes are supported by appending the minimum
+          number of required bits preceded by a dash, e.g.
+          <code class="literal">hmac-sha1-80</code>.  The
+          <em class="replaceable"><code>secret_string</code></em> is the secret
+          to be used by the algorithm, and is treated as a base-64
+          encoded string.
+        </p>
+</div>
+<div class="sect2" lang="en">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="id2574930"></a><span><strong class="command">logging</strong></span> Statement Grammar</h3></div></div></div>
+<pre class="programlisting"><span><strong class="command">logging</strong></span> {
+   [ <span><strong class="command">channel</strong></span> <em class="replaceable"><code>channel_name</code></em> {
+     ( <span><strong class="command">file</strong></span> <em class="replaceable"><code>path name</code></em>
+         [ <span><strong class="command">versions</strong></span> ( <em class="replaceable"><code>number</code></em> | <span><strong class="command">unlimited</strong></span> ) ]
+         [ <span><strong class="command">size</strong></span> <em class="replaceable"><code>size spec</code></em> ]
+       | <span><strong class="command">syslog</strong></span> <em class="replaceable"><code>syslog_facility</code></em>
+       | <span><strong class="command">stderr</strong></span>
+       | <span><strong class="command">null</strong></span> );
+     [ <span><strong class="command">severity</strong></span> (<code class="option">critical</code> | <code class="option">error</code> | <code class="option">warning</code> | <code class="option">notice</code> |
+                 <code class="option">info</code> | <code class="option">debug</code> [ <em class="replaceable"><code>level</code></em> ] | <code class="option">dynamic</code> ); ]
+     [ <span><strong class="command">print-category</strong></span> <code class="option">yes</code> or <code class="option">no</code>; ]
+     [ <span><strong class="command">print-severity</strong></span> <code class="option">yes</code> or <code class="option">no</code>; ]
+     [ <span><strong class="command">print-time</strong></span> <code class="option">yes</code> or <code class="option">no</code>; ]
+   }; ]
+   [ <span><strong class="command">category</strong></span> <em class="replaceable"><code>category_name</code></em> {
+     <em class="replaceable"><code>channel_name</code></em> ; [ <em class="replaceable"><code>channel_name</code></em> ; ... ]
+   }; ]
+   ...
+};
+</pre>
+</div>
+<div class="sect2" lang="en">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="id2575056"></a><span><strong class="command">logging</strong></span> Statement Definition and
+          Usage</h3></div></div></div>
+<p>
+          The <span><strong class="command">logging</strong></span> statement configures a
+          wide
+          variety of logging options for the name server. Its <span><strong class="command">channel</strong></span> phrase
+          associates output methods, format options and severity levels with
+          a name that can then be used with the <span><strong class="command">category</strong></span> phrase
+          to select how various classes of messages are logged.
+        </p>
+<p>
+          Only one <span><strong class="command">logging</strong></span> statement is used to
+          define
+          as many channels and categories as are wanted. If there is no <span><strong class="command">logging</strong></span> statement,
+          the logging configuration will be:
+        </p>
+<pre class="programlisting">logging {
+     category default { default_syslog; default_debug; };
+     category unmatched { null; };
+};
+</pre>
+<p>
+          In <acronym class="acronym">BIND</acronym> 9, the logging configuration
+          is only established when
+          the entire configuration file has been parsed.  In <acronym class="acronym">BIND</acronym> 8, it was
+          established as soon as the <span><strong class="command">logging</strong></span>
+          statement
+          was parsed. When the server is starting up, all logging messages
+          regarding syntax errors in the configuration file go to the default
+          channels, or to standard error if the "<code class="option">-g</code>" option
+          was specified.
+        </p>
+<div class="sect3" lang="en">
+<div class="titlepage"><div><div><h4 class="title">
+<a name="id2575108"></a>The <span><strong class="command">channel</strong></span> Phrase</h4></div></div></div>
+<p>
+            All log output goes to one or more <span class="emphasis"><em>channels</em></span>;
+            you can make as many of them as you want.
+          </p>
+<p>
+            Every channel definition must include a destination clause that
+            says whether messages selected for the channel go to a file, to a
+            particular syslog facility, to the standard error stream, or are
+            discarded. It can optionally also limit the message severity level
+            that will be accepted by the channel (the default is
+            <span><strong class="command">info</strong></span>), and whether to include a
+            <span><strong class="command">named</strong></span>-generated time stamp, the
+            category name
+            and/or severity level (the default is not to include any).
+          </p>
+<p>
+            The <span><strong class="command">null</strong></span> destination clause
+            causes all messages sent to the channel to be discarded;
+            in that case, other options for the channel are meaningless.
+          </p>
+<p>
+            The <span><strong class="command">file</strong></span> destination clause directs
+            the channel
+            to a disk file.  It can include limitations
+            both on how large the file is allowed to become, and how many
+            versions
+            of the file will be saved each time the file is opened.
+          </p>
+<p>
+            If you use the <span><strong class="command">versions</strong></span> log file
+            option, then
+            <span><strong class="command">named</strong></span> will retain that many backup
+            versions of the file by
+            renaming them when opening.  For example, if you choose to keep
+            three old versions
+            of the file <code class="filename">lamers.log</code>, then just
+            before it is opened
+            <code class="filename">lamers.log.1</code> is renamed to
+            <code class="filename">lamers.log.2</code>, <code class="filename">lamers.log.0</code> is renamed
+            to <code class="filename">lamers.log.1</code>, and <code class="filename">lamers.log</code> is
+            renamed to <code class="filename">lamers.log.0</code>.
+            You can say <span><strong class="command">versions unlimited</strong></span> to
+            not limit
+            the number of versions.
+            If a <span><strong class="command">size</strong></span> option is associated with
+            the log file,
+            then renaming is only done when the file being opened exceeds the
+            indicated size.  No backup versions are kept by default; any
+            existing
+            log file is simply appended.
+          </p>
+<p>
+            The <span><strong class="command">size</strong></span> option for files is used
+            to limit log
+            growth. If the file ever exceeds the size, then <span><strong class="command">named</strong></span> will
+            stop writing to the file unless it has a <span><strong class="command">versions</strong></span> option
+            associated with it.  If backup versions are kept, the files are
+            rolled as
+            described above and a new one begun.  If there is no
+            <span><strong class="command">versions</strong></span> option, no more data will
+            be written to the log
+            until some out-of-band mechanism removes or truncates the log to
+            less than the
+            maximum size.  The default behavior is not to limit the size of
+            the
+            file.
+          </p>
+<p>
+            Example usage of the <span><strong class="command">size</strong></span> and
+            <span><strong class="command">versions</strong></span> options:
+          </p>
+<pre class="programlisting">channel an_example_channel {
+    file "example.log" versions 3 size 20m;
+    print-time yes;
+    print-category yes;
+};
+</pre>
+<p>
+            The <span><strong class="command">syslog</strong></span> destination clause
+            directs the
+            channel to the system log.  Its argument is a
+            syslog facility as described in the <span><strong class="command">syslog</strong></span> man
+            page. Known facilities are <span><strong class="command">kern</strong></span>, <span><strong class="command">user</strong></span>,
+            <span><strong class="command">mail</strong></span>, <span><strong class="command">daemon</strong></span>, <span><strong class="command">auth</strong></span>,
+            <span><strong class="command">syslog</strong></span>, <span><strong class="command">lpr</strong></span>, <span><strong class="command">news</strong></span>,
+            <span><strong class="command">uucp</strong></span>, <span><strong class="command">cron</strong></span>, <span><strong class="command">authpriv</strong></span>,
+            <span><strong class="command">ftp</strong></span>, <span><strong class="command">local0</strong></span>, <span><strong class="command">local1</strong></span>,
+            <span><strong class="command">local2</strong></span>, <span><strong class="command">local3</strong></span>, <span><strong class="command">local4</strong></span>,
+            <span><strong class="command">local5</strong></span>, <span><strong class="command">local6</strong></span> and
+            <span><strong class="command">local7</strong></span>, however not all facilities
+            are supported on
+            all operating systems.
+            How <span><strong class="command">syslog</strong></span> will handle messages
+            sent to
+            this facility is described in the <span><strong class="command">syslog.conf</strong></span> man
+            page. If you have a system which uses a very old version of <span><strong class="command">syslog</strong></span> that
+            only uses two arguments to the <span><strong class="command">openlog()</strong></span> function,
+            then this clause is silently ignored.
+          </p>
+<p>
+            The <span><strong class="command">severity</strong></span> clause works like <span><strong class="command">syslog</strong></span>'s
+            "priorities", except that they can also be used if you are writing
+            straight to a file rather than using <span><strong class="command">syslog</strong></span>.
+            Messages which are not at least of the severity level given will
+            not be selected for the channel; messages of higher severity
+            levels
+            will be accepted.
+          </p>
+<p>
+            If you are using <span><strong class="command">syslog</strong></span>, then the <span><strong class="command">syslog.conf</strong></span> priorities
+            will also determine what eventually passes through. For example,
+            defining a channel facility and severity as <span><strong class="command">daemon</strong></span> and <span><strong class="command">debug</strong></span> but
+            only logging <span><strong class="command">daemon.warning</strong></span> via <span><strong class="command">syslog.conf</strong></span> will
+            cause messages of severity <span><strong class="command">info</strong></span> and
+            <span><strong class="command">notice</strong></span> to
+            be dropped. If the situation were reversed, with <span><strong class="command">named</strong></span> writing
+            messages of only <span><strong class="command">warning</strong></span> or higher,
+            then <span><strong class="command">syslogd</strong></span> would
+            print all messages it received from the channel.
+          </p>
+<p>
+            The <span><strong class="command">stderr</strong></span> destination clause
+            directs the
+            channel to the server's standard error stream.  This is intended
+            for
+            use when the server is running as a foreground process, for
+            example
+            when debugging a configuration.
+          </p>
+<p>
+            The server can supply extensive debugging information when
+            it is in debugging mode. If the server's global debug level is
+            greater
+            than zero, then debugging mode will be active. The global debug
+            level is set either by starting the <span><strong class="command">named</strong></span> server
+            with the <code class="option">-d</code> flag followed by a positive integer,
+            or by running <span><strong class="command">rndc trace</strong></span>.
+            The global debug level
+            can be set to zero, and debugging mode turned off, by running <span><strong class="command">rndc
+notrace</strong></span>. All debugging messages in the server have a debug
+            level, and higher debug levels give more detailed output. Channels
+            that specify a specific debug severity, for example:
+          </p>
+<pre class="programlisting">channel specific_debug_level {
+    file "foo";
+    severity debug 3;
+};
+</pre>
+<p>
+            will get debugging output of level 3 or less any time the
+            server is in debugging mode, regardless of the global debugging
+            level. Channels with <span><strong class="command">dynamic</strong></span>
+            severity use the
+            server's global debug level to determine what messages to print.
+          </p>
+<p>
+            If <span><strong class="command">print-time</strong></span> has been turned on,
+            then
+            the date and time will be logged. <span><strong class="command">print-time</strong></span> may
+            be specified for a <span><strong class="command">syslog</strong></span> channel,
+            but is usually
+            pointless since <span><strong class="command">syslog</strong></span> also prints
+            the date and
+            time. If <span><strong class="command">print-category</strong></span> is
+            requested, then the
+            category of the message will be logged as well. Finally, if <span><strong class="command">print-severity</strong></span> is
+            on, then the severity level of the message will be logged. The <span><strong class="command">print-</strong></span> options may
+            be used in any combination, and will always be printed in the
+            following
+            order: time, category, severity. Here is an example where all
+            three <span><strong class="command">print-</strong></span> options
+            are on:
+          </p>
+<p>
+            <code class="computeroutput">28-Feb-2000 15:05:32.863 general: notice: running</code>
+          </p>
+<p>
+            There are four predefined channels that are used for
+            <span><strong class="command">named</strong></span>'s default logging as follows.
+            How they are
+            used is described in <a href="Bv9ARM.ch06.html#the_category_phrase" title="The category Phrase">the section called &#8220;The <span><strong class="command">category</strong></span> Phrase&#8221;</a>.
+          </p>
+<pre class="programlisting">channel default_syslog {
+    syslog daemon;                      // send to syslog's daemon
+                                        // facility
+    severity info;                      // only send priority info
+                                        // and higher
+};
+
+channel default_debug {
+    file "named.run";                   // write to named.run in
+                                        // the working directory
+                                        // Note: stderr is used instead
+                                        // of "named.run"
+                                        // if the server is started
+                                        // with the '-f' option.
+    severity dynamic;                   // log at the server's
+                                        // current debug level
+};
+
+channel default_stderr {
+    stderr;                             // writes to stderr
+    severity info;                      // only send priority info
+                                        // and higher
+};
+
+channel null {
+   null;                                // toss anything sent to
+                                        // this channel
+};
+</pre>
+<p>
+            The <span><strong class="command">default_debug</strong></span> channel has the
+            special
+            property that it only produces output when the server's debug
+            level is
+            nonzero.  It normally writes to a file called <code class="filename">named.run</code>
+            in the server's working directory.
+          </p>
+<p>
+            For security reasons, when the "<code class="option">-u</code>"
+            command line option is used, the <code class="filename">named.run</code> file
+            is created only after <span><strong class="command">named</strong></span> has
+            changed to the
+            new UID, and any debug output generated while <span><strong class="command">named</strong></span> is
+            starting up and still running as root is discarded.  If you need
+            to capture this output, you must run the server with the "<code class="option">-g</code>"
+            option and redirect standard error to a file.
+          </p>
+<p>
+            Once a channel is defined, it cannot be redefined. Thus you
+            cannot alter the built-in channels directly, but you can modify
+            the default logging by pointing categories at channels you have
+            defined.
+          </p>
+</div>
+<div class="sect3" lang="en">
+<div class="titlepage"><div><div><h4 class="title">
+<a name="the_category_phrase"></a>The <span><strong class="command">category</strong></span> Phrase</h4></div></div></div>
+<p>
+            There are many categories, so you can send the logs you want
+            to see wherever you want, without seeing logs you don't want. If
+            you don't specify a list of channels for a category, then log
+            messages
+            in that category will be sent to the <span><strong class="command">default</strong></span> category
+            instead. If you don't specify a default category, the following
+            "default default" is used:
+          </p>
+<pre class="programlisting">category default { default_syslog; default_debug; };
+</pre>
+<p>
+            As an example, let's say you want to log security events to
+            a file, but you also want keep the default logging behavior. You'd
+            specify the following:
+          </p>
+<pre class="programlisting">channel my_security_channel {
+    file "my_security_file";
+    severity info;
+};
+category security {
+    my_security_channel;
+    default_syslog;
+    default_debug;
+};</pre>
+<p>
+            To discard all messages in a category, specify the <span><strong class="command">null</strong></span> channel:
+          </p>
+<pre class="programlisting">category xfer-out { null; };
+category notify { null; };
+</pre>
+<p>
+            Following are the available categories and brief descriptions
+            of the types of log information they contain. More
+            categories may be added in future <acronym class="acronym">BIND</acronym> releases.
+          </p>
+<div class="informaltable"><table border="1">
+<colgroup>
+<col>
+<col>
+</colgroup>
+<tbody>
+<tr>
+<td>
+                    <p><span><strong class="command">default</strong></span></p>
+                  </td>
+<td>
+                    <p>
+                      The default category defines the logging
+                      options for those categories where no specific
+                      configuration has been
+                      defined.
+                    </p>
+                  </td>
+</tr>
+<tr>
+<td>
+                    <p><span><strong class="command">general</strong></span></p>
+                  </td>
+<td>
+                    <p>
+                      The catch-all. Many things still aren't
+                      classified into categories, and they all end up here.
+                    </p>
+                  </td>
+</tr>
+<tr>
+<td>
+                    <p><span><strong class="command">database</strong></span></p>
+                  </td>
+<td>
+                    <p>
+                      Messages relating to the databases used
+                      internally by the name server to store zone and cache
+                      data.
+                    </p>
+                  </td>
+</tr>
+<tr>
+<td>
+                    <p><span><strong class="command">security</strong></span></p>
+                  </td>
+<td>
+                    <p>
+                      Approval and denial of requests.
+                    </p>
+                  </td>
+</tr>
+<tr>
+<td>
+                    <p><span><strong class="command">config</strong></span></p>
+                  </td>
+<td>
+                    <p>
+                      Configuration file parsing and processing.
+                    </p>
+                  </td>
+</tr>
+<tr>
+<td>
+                    <p><span><strong class="command">resolver</strong></span></p>
+                  </td>
+<td>
+                    <p>
+                      DNS resolution, such as the recursive
+                      lookups performed on behalf of clients by a caching name
+                      server.
+                    </p>
+                  </td>
+</tr>
+<tr>
+<td>
+                    <p><span><strong class="command">xfer-in</strong></span></p>
+                  </td>
+<td>
+                    <p>
+                      Zone transfers the server is receiving.
+                    </p>
+                  </td>
+</tr>
+<tr>
+<td>
+                    <p><span><strong class="command">xfer-out</strong></span></p>
+                  </td>
+<td>
+                    <p>
+                      Zone transfers the server is sending.
+                    </p>
+                  </td>
+</tr>
+<tr>
+<td>
+                    <p><span><strong class="command">notify</strong></span></p>
+                  </td>
+<td>
+                    <p>
+                      The NOTIFY protocol.
+                    </p>
+                  </td>
+</tr>
+<tr>
+<td>
+                    <p><span><strong class="command">client</strong></span></p>
+                  </td>
+<td>
+                    <p>
+                      Processing of client requests.
+                    </p>
+                  </td>
+</tr>
+<tr>
+<td>
+                    <p><span><strong class="command">unmatched</strong></span></p>
+                  </td>
+<td>
+                    <p>
+                      Messages that named was unable to determine the
+                      class of or for which there was no matching <span><strong class="command">view</strong></span>.
+                      A one line summary is also logged to the <span><strong class="command">client</strong></span> category.
+                      This category is best sent to a file or stderr, by
+                      default it is sent to
+                      the <span><strong class="command">null</strong></span> channel.
+                    </p>
+                  </td>
+</tr>
+<tr>
+<td>
+                    <p><span><strong class="command">network</strong></span></p>
+                  </td>
+<td>
+                    <p>
+                      Network operations.
+                    </p>
+                  </td>
+</tr>
+<tr>
+<td>
+                    <p><span><strong class="command">update</strong></span></p>
+                  </td>
+<td>
+                    <p>
+                      Dynamic updates.
+                    </p>
+                  </td>
+</tr>
+<tr>
+<td>
+                    <p><span><strong class="command">update-security</strong></span></p>
+                  </td>
+<td>
+                    <p>
+                      Approval and denial of update requests.
+                    </p>
+                  </td>
+</tr>
+<tr>
+<td>
+                    <p><span><strong class="command">queries</strong></span></p>
+                  </td>
+<td>
+                    <p>
+                      Specify where queries should be logged to.
+                    </p>
+                    <p>
+                      At startup, specifying the category <span><strong class="command">queries</strong></span> will also
+                      enable query logging unless <span><strong class="command">querylog</strong></span> option has been
+                      specified.
+                    </p>
+                    <p>
+                      The query log entry reports the client's IP address and
+                      port number, and the
+                      query name, class and type.  It also reports whether the
+                      Recursion Desired
+                      flag was set (+ if set, - if not set), EDNS was in use
+                      (E) or if the
+                      query was signed (S).
+                    </p>
+                    <p>
+                      <code class="computeroutput">client 127.0.0.1#62536: query: www.example.com IN AAAA +SE</code>
+                    </p>
+                    <p>
+                      <code class="computeroutput">client ::1#62537: query: www.example.net IN AAAA -SE</code>
+                    </p>
+                  </td>
+</tr>
+<tr>
+<td>
+                    <p><span><strong class="command">dispatch</strong></span></p>
+                  </td>
+<td>
+                    <p>
+                      Dispatching of incoming packets to the
+                      server modules where they are to be processed.
+                    </p>
+                  </td>
+</tr>
+<tr>
+<td>
+                    <p><span><strong class="command">dnssec</strong></span></p>
+                  </td>
+<td>
+                    <p>
+                      DNSSEC and TSIG protocol processing.
+                    </p>
+                  </td>
+</tr>
+<tr>
+<td>
+                    <p><span><strong class="command">lame-servers</strong></span></p>
+                  </td>
+<td>
+                    <p>
+                      Lame servers.  These are misconfigurations
+                      in remote servers, discovered by BIND 9 when trying to
+                      query
+                      those servers during resolution.
+                    </p>
+                  </td>
+</tr>
+<tr>
+<td>
+                    <p><span><strong class="command">delegation-only</strong></span></p>
+                  </td>
+<td>
+                    <p>
+                      Delegation only.  Logs queries that have have
+                      been forced to NXDOMAIN as the result of a
+                      delegation-only zone or
+                      a <span><strong class="command">delegation-only</strong></span> in a
+                      hint or stub zone declaration.
+                    </p>
+                  </td>
+</tr>
+</tbody>
+</table></div>
+</div>
+</div>
+<div class="sect2" lang="en">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="id2576406"></a><span><strong class="command">lwres</strong></span> Statement Grammar</h3></div></div></div>
+<p>
+           This is the grammar of the <span><strong class="command">lwres</strong></span>
+          statement in the <code class="filename">named.conf</code> file:
+        </p>
+<pre class="programlisting"><span><strong class="command">lwres</strong></span> {
+    [<span class="optional"> listen-on { <em class="replaceable"><code>ip_addr</code></em> [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] ; [<span class="optional"> <em class="replaceable"><code>ip_addr</code></em> [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] ; ... </span>] }; </span>]
+    [<span class="optional"> view <em class="replaceable"><code>view_name</code></em>; </span>]
+    [<span class="optional"> search { <em class="replaceable"><code>domain_name</code></em> ; [<span class="optional"> <em class="replaceable"><code>domain_name</code></em> ; ... </span>] }; </span>]
+    [<span class="optional"> ndots <em class="replaceable"><code>number</code></em>; </span>]
+};
+</pre>
+</div>
+<div class="sect2" lang="en">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="id2576480"></a><span><strong class="command">lwres</strong></span> Statement Definition and Usage</h3></div></div></div>
+<p>
+          The <span><strong class="command">lwres</strong></span> statement configures the
+          name
+          server to also act as a lightweight resolver server. (See
+          <a href="Bv9ARM.ch05.html#lwresd" title="Running a Resolver Daemon">the section called &#8220;Running a Resolver Daemon&#8221;</a>.)  There may be multiple
+          <span><strong class="command">lwres</strong></span> statements configuring
+          lightweight resolver servers with different properties.
+        </p>
+<p>
+          The <span><strong class="command">listen-on</strong></span> statement specifies a
+          list of
+          addresses (and ports) that this instance of a lightweight resolver
+          daemon
+          should accept requests on.  If no port is specified, port 921 is
+          used.
+          If this statement is omitted, requests will be accepted on
+          127.0.0.1,
+          port 921.
+        </p>
+<p>
+          The <span><strong class="command">view</strong></span> statement binds this
+          instance of a
+          lightweight resolver daemon to a view in the DNS namespace, so that
+          the
+          response will be constructed in the same manner as a normal DNS
+          query
+          matching this view.  If this statement is omitted, the default view
+          is
+          used, and if there is no default view, an error is triggered.
+        </p>
+<p>
+          The <span><strong class="command">search</strong></span> statement is equivalent to
+          the
+          <span><strong class="command">search</strong></span> statement in
+          <code class="filename">/etc/resolv.conf</code>.  It provides a
+          list of domains
+          which are appended to relative names in queries.
+        </p>
+<p>
+          The <span><strong class="command">ndots</strong></span> statement is equivalent to
+          the
+          <span><strong class="command">ndots</strong></span> statement in
+          <code class="filename">/etc/resolv.conf</code>.  It indicates the
+          minimum
+          number of dots in a relative domain name that should result in an
+          exact match lookup before search path elements are appended.
+        </p>
+</div>
+<div class="sect2" lang="en">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="id2576544"></a><span><strong class="command">masters</strong></span> Statement Grammar</h3></div></div></div>
+<pre class="programlisting">
+<span><strong class="command">masters</strong></span> <em class="replaceable"><code>name</code></em> [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] { ( <em class="replaceable"><code>masters_list</code></em> | <em class="replaceable"><code>ip_addr</code></em> [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] [<span class="optional">key <em class="replaceable"><code>key</code></em></span>] ) ; [<span class="optional">...</span>] };
+</pre>
+</div>
+<div class="sect2" lang="en">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="id2576587"></a><span><strong class="command">masters</strong></span> Statement Definition and
+          Usage</h3></div></div></div>
+<p><span><strong class="command">masters</strong></span>
+          lists allow for a common set of masters to be easily used by
+          multiple stub and slave zones.
+        </p>
+</div>
+<div class="sect2" lang="en">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="id2576602"></a><span><strong class="command">options</strong></span> Statement Grammar</h3></div></div></div>
+<p>
+          This is the grammar of the <span><strong class="command">options</strong></span>
+          statement in the <code class="filename">named.conf</code> file:
+        </p>
+<pre class="programlisting">options {
+    [<span class="optional"> version <em class="replaceable"><code>version_string</code></em>; </span>]
+    [<span class="optional"> hostname <em class="replaceable"><code>hostname_string</code></em>; </span>]
+    [<span class="optional"> server-id <em class="replaceable"><code>server_id_string</code></em>; </span>]
+    [<span class="optional"> directory <em class="replaceable"><code>path_name</code></em>; </span>]
+    [<span class="optional"> key-directory <em class="replaceable"><code>path_name</code></em>; </span>]
+    [<span class="optional"> named-xfer <em class="replaceable"><code>path_name</code></em>; </span>]
+    [<span class="optional"> tkey-domain <em class="replaceable"><code>domainname</code></em>; </span>]
+    [<span class="optional"> tkey-dhkey <em class="replaceable"><code>key_name</code></em> <em class="replaceable"><code>key_tag</code></em>; </span>]
+    [<span class="optional"> cache-file <em class="replaceable"><code>path_name</code></em>; </span>]
+    [<span class="optional"> dump-file <em class="replaceable"><code>path_name</code></em>; </span>]
+    [<span class="optional"> memstatistics-file <em class="replaceable"><code>path_name</code></em>; </span>]
+    [<span class="optional"> pid-file <em class="replaceable"><code>path_name</code></em>; </span>]
+    [<span class="optional"> recursing-file <em class="replaceable"><code>path_name</code></em>; </span>]
+    [<span class="optional"> statistics-file <em class="replaceable"><code>path_name</code></em>; </span>]
+    [<span class="optional"> zone-statistics <em class="replaceable"><code>yes_or_no</code></em>; </span>]
+    [<span class="optional"> auth-nxdomain <em class="replaceable"><code>yes_or_no</code></em>; </span>]
+    [<span class="optional"> deallocate-on-exit <em class="replaceable"><code>yes_or_no</code></em>; </span>]
+    [<span class="optional"> dialup <em class="replaceable"><code>dialup_option</code></em>; </span>]
+    [<span class="optional"> fake-iquery <em class="replaceable"><code>yes_or_no</code></em>; </span>]
+    [<span class="optional"> fetch-glue <em class="replaceable"><code>yes_or_no</code></em>; </span>]
+    [<span class="optional"> flush-zones-on-shutdown <em class="replaceable"><code>yes_or_no</code></em>; </span>]
+    [<span class="optional"> has-old-clients <em class="replaceable"><code>yes_or_no</code></em>; </span>]
+    [<span class="optional"> host-statistics <em class="replaceable"><code>yes_or_no</code></em>; </span>]
+    [<span class="optional"> host-statistics-max <em class="replaceable"><code>number</code></em>; </span>]
+    [<span class="optional"> minimal-responses <em class="replaceable"><code>yes_or_no</code></em>; </span>]
+    [<span class="optional"> multiple-cnames <em class="replaceable"><code>yes_or_no</code></em>; </span>]
+    [<span class="optional"> notify <em class="replaceable"><code>yes_or_no</code></em> | <em class="replaceable"><code>explicit</code></em> | <em class="replaceable"><code>master-only</code></em>; </span>]
+    [<span class="optional"> recursion <em class="replaceable"><code>yes_or_no</code></em>; </span>]
+    [<span class="optional"> rfc2308-type1 <em class="replaceable"><code>yes_or_no</code></em>; </span>]
+    [<span class="optional"> use-id-pool <em class="replaceable"><code>yes_or_no</code></em>; </span>]
+    [<span class="optional"> maintain-ixfr-base <em class="replaceable"><code>yes_or_no</code></em>; </span>]
+    [<span class="optional"> dnssec-enable <em class="replaceable"><code>yes_or_no</code></em>; </span>]
+    [<span class="optional"> dnssec-validation <em class="replaceable"><code>yes_or_no</code></em>; </span>]
+    [<span class="optional"> dnssec-lookaside <em class="replaceable"><code>domain</code></em> trust-anchor <em class="replaceable"><code>domain</code></em>; </span>]
+    [<span class="optional"> dnssec-must-be-secure <em class="replaceable"><code>domain yes_or_no</code></em>; </span>]
+    [<span class="optional"> dnssec-accept-expired <em class="replaceable"><code>yes_or_no</code></em>; </span>]
+    [<span class="optional"> forward ( <em class="replaceable"><code>only</code></em> | <em class="replaceable"><code>first</code></em> ); </span>]
+    [<span class="optional"> forwarders { [<span class="optional"> <em class="replaceable"><code>ip_addr</code></em> [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] ; ... </span>] }; </span>]
+    [<span class="optional"> dual-stack-servers [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] {
+        ( <em class="replaceable"><code>domain_name</code></em> [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] |
+          <em class="replaceable"><code>ip_addr</code></em> [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] ) ; 
+        ... }; </span>]
+    [<span class="optional"> check-names ( <em class="replaceable"><code>master</code></em> | <em class="replaceable"><code>slave</code></em> | <em class="replaceable"><code>response</code></em> )
+        ( <em class="replaceable"><code>warn</code></em> | <em class="replaceable"><code>fail</code></em> | <em class="replaceable"><code>ignore</code></em> ); </span>]
+    [<span class="optional"> check-mx ( <em class="replaceable"><code>warn</code></em> | <em class="replaceable"><code>fail</code></em> | <em class="replaceable"><code>ignore</code></em> ); </span>]
+    [<span class="optional"> check-wildcard <em class="replaceable"><code>yes_or_no</code></em>; </span>]
+    [<span class="optional"> check-integrity <em class="replaceable"><code>yes_or_no</code></em>; </span>]
+    [<span class="optional"> check-mx-cname ( <em class="replaceable"><code>warn</code></em> | <em class="replaceable"><code>fail</code></em> | <em class="replaceable"><code>ignore</code></em> ); </span>]
+    [<span class="optional"> check-srv-cname ( <em class="replaceable"><code>warn</code></em> | <em class="replaceable"><code>fail</code></em> | <em class="replaceable"><code>ignore</code></em> ); </span>]
+    [<span class="optional"> check-sibling <em class="replaceable"><code>yes_or_no</code></em>; </span>]
+    [<span class="optional"> allow-notify { <em class="replaceable"><code>address_match_list</code></em> }; </span>]
+    [<span class="optional"> allow-query { <em class="replaceable"><code>address_match_list</code></em> }; </span>]
+    [<span class="optional"> allow-query-cache { <em class="replaceable"><code>address_match_list</code></em> }; </span>]
+    [<span class="optional"> allow-transfer { <em class="replaceable"><code>address_match_list</code></em> }; </span>]
+    [<span class="optional"> allow-recursion { <em class="replaceable"><code>address_match_list</code></em> }; </span>]
+    [<span class="optional"> allow-update { <em class="replaceable"><code>address_match_list</code></em> }; </span>]
+    [<span class="optional"> allow-update-forwarding { <em class="replaceable"><code>address_match_list</code></em> }; </span>]
+    [<span class="optional"> update-check-ksk <em class="replaceable"><code>yes_or_no</code></em>; </span>]
+    [<span class="optional"> allow-v6-synthesis { <em class="replaceable"><code>address_match_list</code></em> }; </span>]
+    [<span class="optional"> blackhole { <em class="replaceable"><code>address_match_list</code></em> }; </span>]
+    [<span class="optional"> avoid-v4-udp-ports { <em class="replaceable"><code>port_list</code></em> }; </span>]
+    [<span class="optional"> avoid-v6-udp-ports { <em class="replaceable"><code>port_list</code></em> }; </span>]
+    [<span class="optional"> listen-on [<span class="optional"> port <em class="replaceable"><code>ip_port</code></em> </span>] { <em class="replaceable"><code>address_match_list</code></em> }; </span>]
+    [<span class="optional"> listen-on-v6 [<span class="optional"> port <em class="replaceable"><code>ip_port</code></em> </span>] { <em class="replaceable"><code>address_match_list</code></em> }; </span>]
+    [<span class="optional"> query-source ( ( <em class="replaceable"><code>ip4_addr</code></em> | <em class="replaceable"><code>*</code></em> )
+        [<span class="optional"> port ( <em class="replaceable"><code>ip_port</code></em> | <em class="replaceable"><code>*</code></em> ) </span>] |
+        [<span class="optional"> address ( <em class="replaceable"><code>ip4_addr</code></em> | <em class="replaceable"><code>*</code></em> ) </span>]
+        [<span class="optional"> port ( <em class="replaceable"><code>ip_port</code></em> | <em class="replaceable"><code>*</code></em> ) </span>] ) ; </span>]
+    [<span class="optional"> query-source-v6 ( ( <em class="replaceable"><code>ip6_addr</code></em> | <em class="replaceable"><code>*</code></em> )
+        [<span class="optional"> port ( <em class="replaceable"><code>ip_port</code></em> | <em class="replaceable"><code>*</code></em> ) </span>] | 
+        [<span class="optional"> address ( <em class="replaceable"><code>ip6_addr</code></em> | <em class="replaceable"><code>*</code></em> ) </span>] 
+        [<span class="optional"> port ( <em class="replaceable"><code>ip_port</code></em> | <em class="replaceable"><code>*</code></em> ) </span>] ) ; </span>]
+    [<span class="optional"> max-transfer-time-in <em class="replaceable"><code>number</code></em>; </span>]
+    [<span class="optional"> max-transfer-time-out <em class="replaceable"><code>number</code></em>; </span>]
+    [<span class="optional"> max-transfer-idle-in <em class="replaceable"><code>number</code></em>; </span>]
+    [<span class="optional"> max-transfer-idle-out <em class="replaceable"><code>number</code></em>; </span>]
+    [<span class="optional"> tcp-clients <em class="replaceable"><code>number</code></em>; </span>]
+    [<span class="optional"> recursive-clients <em class="replaceable"><code>number</code></em>; </span>]
+    [<span class="optional"> serial-query-rate <em class="replaceable"><code>number</code></em>; </span>]
+    [<span class="optional"> serial-queries <em class="replaceable"><code>number</code></em>; </span>]
+    [<span class="optional"> tcp-listen-queue <em class="replaceable"><code>number</code></em>; </span>]
+    [<span class="optional"> transfer-format <em class="replaceable"><code>( one-answer | many-answers )</code></em>; </span>]
+    [<span class="optional"> transfers-in  <em class="replaceable"><code>number</code></em>; </span>]
+    [<span class="optional"> transfers-out <em class="replaceable"><code>number</code></em>; </span>]
+    [<span class="optional"> transfers-per-ns <em class="replaceable"><code>number</code></em>; </span>]
+    [<span class="optional"> transfer-source (<em class="replaceable"><code>ip4_addr</code></em> | <code class="constant">*</code>) [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] ; </span>]
+    [<span class="optional"> transfer-source-v6 (<em class="replaceable"><code>ip6_addr</code></em> | <code class="constant">*</code>) [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] ; </span>]
+    [<span class="optional"> alt-transfer-source (<em class="replaceable"><code>ip4_addr</code></em> | <code class="constant">*</code>) [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] ; </span>]
+    [<span class="optional"> alt-transfer-source-v6 (<em class="replaceable"><code>ip6_addr</code></em> | <code class="constant">*</code>) [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] ; </span>]
+    [<span class="optional"> use-alt-transfer-source <em class="replaceable"><code>yes_or_no</code></em>; </span>]
+    [<span class="optional"> notify-delay <em class="replaceable"><code>seconds</code></em> ; </span>]
+    [<span class="optional"> notify-source (<em class="replaceable"><code>ip4_addr</code></em> | <code class="constant">*</code>) [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] ; </span>]
+    [<span class="optional"> notify-source-v6 (<em class="replaceable"><code>ip6_addr</code></em> | <code class="constant">*</code>) [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] ; </span>]
+    [<span class="optional"> also-notify { <em class="replaceable"><code>ip_addr</code></em> [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] ; [<span class="optional"> <em class="replaceable"><code>ip_addr</code></em> [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] ; ... </span>] }; </span>]
+    [<span class="optional"> max-ixfr-log-size <em class="replaceable"><code>number</code></em>; </span>]
+    [<span class="optional"> max-journal-size <em class="replaceable"><code>size_spec</code></em>; </span>]
+    [<span class="optional"> coresize <em class="replaceable"><code>size_spec</code></em> ; </span>]
+    [<span class="optional"> datasize <em class="replaceable"><code>size_spec</code></em> ; </span>]
+    [<span class="optional"> files <em class="replaceable"><code>size_spec</code></em> ; </span>]
+    [<span class="optional"> stacksize <em class="replaceable"><code>size_spec</code></em> ; </span>]
+    [<span class="optional"> cleaning-interval <em class="replaceable"><code>number</code></em>; </span>]
+    [<span class="optional"> heartbeat-interval <em class="replaceable"><code>number</code></em>; </span>]
+    [<span class="optional"> interface-interval <em class="replaceable"><code>number</code></em>; </span>]
+    [<span class="optional"> statistics-interval <em class="replaceable"><code>number</code></em>; </span>]
+    [<span class="optional"> topology { <em class="replaceable"><code>address_match_list</code></em> }</span>];
+    [<span class="optional"> sortlist { <em class="replaceable"><code>address_match_list</code></em> }</span>];
+    [<span class="optional"> rrset-order { <em class="replaceable"><code>order_spec</code></em> ; [<span class="optional"> <em class="replaceable"><code>order_spec</code></em> ; ... </span>] </span>] };
+    [<span class="optional"> lame-ttl <em class="replaceable"><code>number</code></em>; </span>]
+    [<span class="optional"> max-ncache-ttl <em class="replaceable"><code>number</code></em>; </span>]
+    [<span class="optional"> max-cache-ttl <em class="replaceable"><code>number</code></em>; </span>]
+    [<span class="optional"> sig-validity-interval <em class="replaceable"><code>number</code></em> ; </span>]
+    [<span class="optional"> min-roots <em class="replaceable"><code>number</code></em>; </span>]
+    [<span class="optional"> use-ixfr <em class="replaceable"><code>yes_or_no</code></em> ; </span>]
+    [<span class="optional"> provide-ixfr <em class="replaceable"><code>yes_or_no</code></em>; </span>]
+    [<span class="optional"> request-ixfr <em class="replaceable"><code>yes_or_no</code></em>; </span>]
+    [<span class="optional"> treat-cr-as-space <em class="replaceable"><code>yes_or_no</code></em> ; </span>]
+    [<span class="optional"> min-refresh-time <em class="replaceable"><code>number</code></em> ; </span>]
+    [<span class="optional"> max-refresh-time <em class="replaceable"><code>number</code></em> ; </span>]
+    [<span class="optional"> min-retry-time <em class="replaceable"><code>number</code></em> ; </span>]
+    [<span class="optional"> max-retry-time <em class="replaceable"><code>number</code></em> ; </span>]
+    [<span class="optional"> port <em class="replaceable"><code>ip_port</code></em>; </span>]
+    [<span class="optional"> additional-from-auth <em class="replaceable"><code>yes_or_no</code></em> ; </span>]
+    [<span class="optional"> additional-from-cache <em class="replaceable"><code>yes_or_no</code></em> ; </span>]
+    [<span class="optional"> random-device <em class="replaceable"><code>path_name</code></em> ; </span>]
+    [<span class="optional"> max-cache-size <em class="replaceable"><code>size_spec</code></em> ; </span>]
+    [<span class="optional"> match-mapped-addresses <em class="replaceable"><code>yes_or_no</code></em>; </span>]
+    [<span class="optional"> preferred-glue ( <em class="replaceable"><code>A</code></em> | <em class="replaceable"><code>AAAA</code></em> | <em class="replaceable"><code>NONE</code></em> ); </span>]
+    [<span class="optional"> edns-udp-size <em class="replaceable"><code>number</code></em>; </span>]
+    [<span class="optional"> max-udp-size <em class="replaceable"><code>number</code></em>; </span>]
+    [<span class="optional"> root-delegation-only [<span class="optional"> exclude { <em class="replaceable"><code>namelist</code></em> } </span>] ; </span>]
+    [<span class="optional"> querylog <em class="replaceable"><code>yes_or_no</code></em> ; </span>]
+    [<span class="optional"> disable-algorithms <em class="replaceable"><code>domain</code></em> { <em class="replaceable"><code>algorithm</code></em>; [<span class="optional"> <em class="replaceable"><code>algorithm</code></em>; </span>] }; </span>]
+    [<span class="optional"> acache-enable <em class="replaceable"><code>yes_or_no</code></em> ; </span>]
+    [<span class="optional"> acache-cleaning-interval <em class="replaceable"><code>number</code></em>; </span>]
+    [<span class="optional"> max-acache-size <em class="replaceable"><code>size_spec</code></em> ; </span>]
+    [<span class="optional"> clients-per-query <em class="replaceable"><code>number</code></em> ; </span>]
+    [<span class="optional"> max-clients-per-query <em class="replaceable"><code>number</code></em> ; </span>]
+    [<span class="optional"> masterfile-format (<code class="constant">text</code>|<code class="constant">raw</code>) ; </span>]
+    [<span class="optional"> empty-server <em class="replaceable"><code>name</code></em> ; </span>]
+    [<span class="optional"> empty-contact <em class="replaceable"><code>name</code></em> ; </span>]
+    [<span class="optional"> empty-zones-enable <em class="replaceable"><code>yes_or_no</code></em> ; </span>]
+    [<span class="optional"> disable-empty-zone <em class="replaceable"><code>zone_name</code></em> ; </span>]
+    [<span class="optional"> zero-no-soa-ttl <em class="replaceable"><code>yes_or_no</code></em> ; </span>]
+    [<span class="optional"> zero-no-soa-ttl-cache <em class="replaceable"><code>yes_or_no</code></em> ; </span>]
+};
+</pre>
+</div>
+<div class="sect2" lang="en">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="options"></a><span><strong class="command">options</strong></span> Statement Definition and
+          Usage</h3></div></div></div>
+<p>
+          The <span><strong class="command">options</strong></span> statement sets up global
+          options
+          to be used by <acronym class="acronym">BIND</acronym>. This statement
+          may appear only
+          once in a configuration file. If there is no <span><strong class="command">options</strong></span>
+          statement, an options block with each option set to its default will
+          be used.
+        </p>
+<div class="variablelist"><dl>
+<dt><span class="term"><span><strong class="command">directory</strong></span></span></dt>
+<dd><p>
+                The working directory of the server.
+                Any non-absolute pathnames in the configuration file will be
+                taken
+                as relative to this directory. The default location for most
+                server
+                output files (e.g. <code class="filename">named.run</code>)
+                is this directory.
+                If a directory is not specified, the working directory
+                defaults to `<code class="filename">.</code>', the directory from
+                which the server
+                was started. The directory specified should be an absolute
+                path.
+              </p></dd>
+<dt><span class="term"><span><strong class="command">key-directory</strong></span></span></dt>
+<dd><p>
+                When performing dynamic update of secure zones, the
+                directory where the public and private key files should be
+                found,
+                if different than the current working directory.  The
+                directory specified
+                must be an absolute path.
+              </p></dd>
+<dt><span class="term"><span><strong class="command">named-xfer</strong></span></span></dt>
+<dd><p>
+                <span class="emphasis"><em>This option is obsolete.</em></span>
+                It was used in <acronym class="acronym">BIND</acronym> 8 to
+                specify the pathname to the <span><strong class="command">named-xfer</strong></span> program.
+                In <acronym class="acronym">BIND</acronym> 9, no separate <span><strong class="command">named-xfer</strong></span> program is
+                needed; its functionality is built into the name server.
+              </p></dd>
+<dt><span class="term"><span><strong class="command">tkey-domain</strong></span></span></dt>
+<dd><p>
+                The domain appended to the names of all
+                shared keys generated with
+                <span><strong class="command">TKEY</strong></span>. When a client
+                requests a <span><strong class="command">TKEY</strong></span> exchange, it
+                may or may not specify
+                the desired name for the key. If present, the name of the
+                shared
+                key will be "<code class="varname">client specified part</code>" +
+                "<code class="varname">tkey-domain</code>".
+                Otherwise, the name of the shared key will be "<code class="varname">random hex
+digits</code>" + "<code class="varname">tkey-domain</code>". In most cases,
+                the <span><strong class="command">domainname</strong></span> should be the
+                server's domain
+                name.
+              </p></dd>
+<dt><span class="term"><span><strong class="command">tkey-dhkey</strong></span></span></dt>
+<dd><p>
+                The Diffie-Hellman key used by the server
+                to generate shared keys with clients using the Diffie-Hellman
+                mode
+                of <span><strong class="command">TKEY</strong></span>. The server must be
+                able to load the
+                public and private keys from files in the working directory.
+                In
+                most cases, the keyname should be the server's host name.
+              </p></dd>
+<dt><span class="term"><span><strong class="command">cache-file</strong></span></span></dt>
+<dd><p>
+                This is for testing only.  Do not use.
+              </p></dd>
+<dt><span class="term"><span><strong class="command">dump-file</strong></span></span></dt>
+<dd><p>
+                The pathname of the file the server dumps
+                the database to when instructed to do so with
+                <span><strong class="command">rndc dumpdb</strong></span>.
+                If not specified, the default is <code class="filename">named_dump.db</code>.
+              </p></dd>
+<dt><span class="term"><span><strong class="command">memstatistics-file</strong></span></span></dt>
+<dd>
+<p>
+                The pathname of the file the server writes memory
+                usage statistics to on exit.  If specified the
+                statistics will be written to the file on exit.
+              </p>
+<p>
+                In <acronym class="acronym">BIND</acronym> 9.5 and later this will
+                default to <code class="filename">named.memstats</code>.
+                <acronym class="acronym">BIND</acronym> 9.5 will also introduce
+                <span><strong class="command">memstatistics</strong></span> to control the
+                writing.
+              </p>
+</dd>
+<dt><span class="term"><span><strong class="command">pid-file</strong></span></span></dt>
+<dd><p>
+                The pathname of the file the server writes its process ID
+                in. If not specified, the default is <code class="filename">/var/run/named.pid</code>.
+                The pid-file is used by programs that want to send signals to
+                the running
+                name server. Specifying <span><strong class="command">pid-file none</strong></span> disables the
+                use of a PID file &#8212; no file will be written and any
+                existing one will be removed.  Note that <span><strong class="command">none</strong></span>
+                is a keyword, not a filename, and therefore is not enclosed
+                in
+                double quotes.
+              </p></dd>
+<dt><span class="term"><span><strong class="command">recursing-file</strong></span></span></dt>
+<dd><p>
+                The pathname of the file the server dumps
+                the queries that are currently recursing when instructed
+                to do so with <span><strong class="command">rndc recursing</strong></span>.
+                If not specified, the default is <code class="filename">named.recursing</code>.
+              </p></dd>
+<dt><span class="term"><span><strong class="command">statistics-file</strong></span></span></dt>
+<dd><p>
+                The pathname of the file the server appends statistics
+                to when instructed to do so using <span><strong class="command">rndc stats</strong></span>.
+                If not specified, the default is <code class="filename">named.stats</code> in the
+                server's current directory.  The format of the file is
+                described
+                in <a href="Bv9ARM.ch06.html#statsfile" title="The Statistics File">the section called &#8220;The Statistics File&#8221;</a>.
+              </p></dd>
+<dt><span class="term"><span><strong class="command">port</strong></span></span></dt>
+<dd><p>
+                The UDP/TCP port number the server uses for
+                receiving and sending DNS protocol traffic.
+                The default is 53.  This option is mainly intended for server
+                testing;
+                a server using a port other than 53 will not be able to
+                communicate with
+                the global DNS.
+              </p></dd>
+<dt><span class="term"><span><strong class="command">random-device</strong></span></span></dt>
+<dd><p>
+                The source of entropy to be used by the server.  Entropy is
+                primarily needed
+                for DNSSEC operations, such as TKEY transactions and dynamic
+                update of signed
+                zones.  This options specifies the device (or file) from which
+                to read
+                entropy.  If this is a file, operations requiring entropy will
+                fail when the
+                file has been exhausted.  If not specified, the default value
+                is
+                <code class="filename">/dev/random</code>
+                (or equivalent) when present, and none otherwise.  The
+                <span><strong class="command">random-device</strong></span> option takes
+                effect during
+                the initial configuration load at server startup time and
+                is ignored on subsequent reloads.
+              </p></dd>
+<dt><span class="term"><span><strong class="command">preferred-glue</strong></span></span></dt>
+<dd><p>
+                If specified, the listed type (A or AAAA) will be emitted
+                before other glue
+                in the additional section of a query response.
+                The default is not to prefer any type (NONE).
+              </p></dd>
+<dt><span class="term"><span><strong class="command">root-delegation-only</strong></span></span></dt>
+<dd>
+<p>
+                Turn on enforcement of delegation-only in TLDs (top level domains) and root zones
+                with an optional
+                exclude list.
+              </p>
+<p>
+                Note some TLDs are not delegation only (e.g. "DE", "LV", "US"
+                and "MUSEUM").
+              </p>
+<pre class="programlisting">
+options {
+        root-delegation-only exclude { "de"; "lv"; "us"; "museum"; };
+};
+</pre>
+</dd>
+<dt><span class="term"><span><strong class="command">disable-algorithms</strong></span></span></dt>
+<dd><p>
+                Disable the specified DNSSEC algorithms at and below the
+                specified name.
+                Multiple <span><strong class="command">disable-algorithms</strong></span>
+                statements are allowed.
+                Only the most specific will be applied.
+              </p></dd>
+<dt><span class="term"><span><strong class="command">dnssec-lookaside</strong></span></span></dt>
+<dd><p>
+                When set, <span><strong class="command">dnssec-lookaside</strong></span>
+                provides the
+                validator with an alternate method to validate DNSKEY records
+                at the
+                top of a zone.  When a DNSKEY is at or below a domain
+                specified by the
+                deepest <span><strong class="command">dnssec-lookaside</strong></span>, and
+                the normal dnssec validation
+                has left the key untrusted, the trust-anchor will be append to
+                the key
+                name and a DLV record will be looked up to see if it can
+                validate the
+                key.  If the DLV record validates a DNSKEY (similarly to the
+                way a DS
+                record does) the DNSKEY RRset is deemed to be trusted.
+              </p></dd>
+<dt><span class="term"><span><strong class="command">dnssec-must-be-secure</strong></span></span></dt>
+<dd><p>
+                Specify hierarchies which must be or may not be secure (signed and
+                validated).
+                If <strong class="userinput"><code>yes</code></strong>, then named will only accept
+                answers if they
+                are secure.
+                If <strong class="userinput"><code>no</code></strong>, then normal dnssec validation
+                applies
+                allowing for insecure answers to be accepted.
+                The specified domain must be under a <span><strong class="command">trusted-key</strong></span> or
+                <span><strong class="command">dnssec-lookaside</strong></span> must be
+                active.
+              </p></dd>
+</dl></div>
+<div class="sect3" lang="en">
+<div class="titlepage"><div><div><h4 class="title">
+<a name="boolean_options"></a>Boolean Options</h4></div></div></div>
+<div class="variablelist"><dl>
+<dt><span class="term"><span><strong class="command">auth-nxdomain</strong></span></span></dt>
+<dd><p>
+                  If <strong class="userinput"><code>yes</code></strong>, then the <span><strong class="command">AA</strong></span> bit
+                  is always set on NXDOMAIN responses, even if the server is
+                  not actually
+                  authoritative. The default is <strong class="userinput"><code>no</code></strong>;
+                  this is
+                  a change from <acronym class="acronym">BIND</acronym> 8. If you
+                  are using very old DNS software, you
+                  may need to set it to <strong class="userinput"><code>yes</code></strong>.
+                </p></dd>
+<dt><span class="term"><span><strong class="command">deallocate-on-exit</strong></span></span></dt>
+<dd><p>
+                  This option was used in <acronym class="acronym">BIND</acronym>
+                  8 to enable checking
+                  for memory leaks on exit. <acronym class="acronym">BIND</acronym> 9 ignores the option and always performs
+                  the checks.
+                </p></dd>
+<dt><span class="term"><span><strong class="command">dialup</strong></span></span></dt>
+<dd>
+<p>
+                  If <strong class="userinput"><code>yes</code></strong>, then the
+                  server treats all zones as if they are doing zone transfers
+                  across
+                  a dial-on-demand dialup link, which can be brought up by
+                  traffic
+                  originating from this server. This has different effects
+                  according
+                  to zone type and concentrates the zone maintenance so that
+                  it all
+                  happens in a short interval, once every <span><strong class="command">heartbeat-interval</strong></span> and
+                  hopefully during the one call. It also suppresses some of
+                  the normal
+                  zone maintenance traffic. The default is <strong class="userinput"><code>no</code></strong>.
+                </p>
+<p>
+                  The <span><strong class="command">dialup</strong></span> option
+                  may also be specified in the <span><strong class="command">view</strong></span> and
+                  <span><strong class="command">zone</strong></span> statements,
+                  in which case it overrides the global <span><strong class="command">dialup</strong></span>
+                  option.
+                </p>
+<p>
+                  If the zone is a master zone, then the server will send out a
+                  NOTIFY
+                  request to all the slaves (default). This should trigger the
+                  zone serial
+                  number check in the slave (providing it supports NOTIFY)
+                  allowing the slave
+                  to verify the zone while the connection is active.
+                  The set of servers to which NOTIFY is sent can be controlled
+                  by
+                  <span><strong class="command">notify</strong></span> and <span><strong class="command">also-notify</strong></span>.
+                </p>
+<p>
+                  If the
+                  zone is a slave or stub zone, then the server will suppress
+                  the regular
+                  "zone up to date" (refresh) queries and only perform them
+                  when the
+                  <span><strong class="command">heartbeat-interval</strong></span> expires in
+                  addition to sending
+                  NOTIFY requests.
+                </p>
+<p>
+                  Finer control can be achieved by using
+                  <strong class="userinput"><code>notify</code></strong> which only sends NOTIFY
+                  messages,
+                  <strong class="userinput"><code>notify-passive</code></strong> which sends NOTIFY
+                  messages and
+                  suppresses the normal refresh queries, <strong class="userinput"><code>refresh</code></strong>
+                  which suppresses normal refresh processing and sends refresh
+                  queries
+                  when the <span><strong class="command">heartbeat-interval</strong></span>
+                  expires, and
+                  <strong class="userinput"><code>passive</code></strong> which just disables normal
+                  refresh
+                  processing.
+                </p>
+<div class="informaltable"><table border="1">
+<colgroup>
+<col>
+<col>
+<col>
+<col>
+</colgroup>
+<tbody>
+<tr>
+<td>
+                          <p>
+                            dialup mode
+                          </p>
+                        </td>
+<td>
+                          <p>
+                            normal refresh
+                          </p>
+                        </td>
+<td>
+                          <p>
+                            heart-beat refresh
+                          </p>
+                        </td>
+<td>
+                          <p>
+                            heart-beat notify
+                          </p>
+                        </td>
+</tr>
+<tr>
+<td>
+                          <p><span><strong class="command">no</strong></span> (default)</p>
+                        </td>
+<td>
+                          <p>
+                            yes
+                          </p>
+                        </td>
+<td>
+                          <p>
+                            no
+                          </p>
+                        </td>
+<td>
+                          <p>
+                            no
+                          </p>
+                        </td>
+</tr>
+<tr>
+<td>
+                          <p><span><strong class="command">yes</strong></span></p>
+                        </td>
+<td>
+                          <p>
+                            no
+                          </p>
+                        </td>
+<td>
+                          <p>
+                            yes
+                          </p>
+                        </td>
+<td>
+                          <p>
+                            yes
+                          </p>
+                        </td>
+</tr>
+<tr>
+<td>
+                          <p><span><strong class="command">notify</strong></span></p>
+                        </td>
+<td>
+                          <p>
+                            yes
+                          </p>
+                        </td>
+<td>
+                          <p>
+                            no
+                          </p>
+                        </td>
+<td>
+                          <p>
+                            yes
+                          </p>
+                        </td>
+</tr>
+<tr>
+<td>
+                          <p><span><strong class="command">refresh</strong></span></p>
+                        </td>
+<td>
+                          <p>
+                            no
+                          </p>
+                        </td>
+<td>
+                          <p>
+                            yes
+                          </p>
+                        </td>
+<td>
+                          <p>
+                            no
+                          </p>
+                        </td>
+</tr>
+<tr>
+<td>
+                          <p><span><strong class="command">passive</strong></span></p>
+                        </td>
+<td>
+                          <p>
+                            no
+                          </p>
+                        </td>
+<td>
+                          <p>
+                            no
+                          </p>
+                        </td>
+<td>
+                          <p>
+                            no
+                          </p>
+                        </td>
+</tr>
+<tr>
+<td>
+                          <p><span><strong class="command">notify-passive</strong></span></p>
+                        </td>
+<td>
+                          <p>
+                            no
+                          </p>
+                        </td>
+<td>
+                          <p>
+                            no
+                          </p>
+                        </td>
+<td>
+                          <p>
+                            yes
+                          </p>
+                        </td>
+</tr>
+</tbody>
+</table></div>
+<p>
+                  Note that normal NOTIFY processing is not affected by
+                  <span><strong class="command">dialup</strong></span>.
+                </p>
+</dd>
+<dt><span class="term"><span><strong class="command">fake-iquery</strong></span></span></dt>
+<dd><p>
+                  In <acronym class="acronym">BIND</acronym> 8, this option
+                  enabled simulating the obsolete DNS query type
+                  IQUERY. <acronym class="acronym">BIND</acronym> 9 never does
+                  IQUERY simulation.
+                </p></dd>
+<dt><span class="term"><span><strong class="command">fetch-glue</strong></span></span></dt>
+<dd><p>
+                  This option is obsolete.
+                  In BIND 8, <strong class="userinput"><code>fetch-glue yes</code></strong>
+                  caused the server to attempt to fetch glue resource records
+                  it
+                  didn't have when constructing the additional
+                  data section of a response.  This is now considered a bad
+                  idea
+                  and BIND 9 never does it.
+                </p></dd>
+<dt><span class="term"><span><strong class="command">flush-zones-on-shutdown</strong></span></span></dt>
+<dd><p>
+                  When the nameserver exits due receiving SIGTERM,
+                  flush or do not flush any pending zone writes.  The default
+                  is
+                  <span><strong class="command">flush-zones-on-shutdown</strong></span> <strong class="userinput"><code>no</code></strong>.
+                </p></dd>
+<dt><span class="term"><span><strong class="command">has-old-clients</strong></span></span></dt>
+<dd><p>
+                  This option was incorrectly implemented
+                  in <acronym class="acronym">BIND</acronym> 8, and is ignored by <acronym class="acronym">BIND</acronym> 9.
+                  To achieve the intended effect
+                  of
+                  <span><strong class="command">has-old-clients</strong></span> <strong class="userinput"><code>yes</code></strong>, specify
+                  the two separate options <span><strong class="command">auth-nxdomain</strong></span> <strong class="userinput"><code>yes</code></strong>
+                  and <span><strong class="command">rfc2308-type1</strong></span> <strong class="userinput"><code>no</code></strong> instead.
+                </p></dd>
+<dt><span class="term"><span><strong class="command">host-statistics</strong></span></span></dt>
+<dd><p>
+                  In BIND 8, this enables keeping of
+                  statistics for every host that the name server interacts
+                  with.
+                  Not implemented in BIND 9.
+                </p></dd>
+<dt><span class="term"><span><strong class="command">maintain-ixfr-base</strong></span></span></dt>
+<dd><p>
+                  <span class="emphasis"><em>This option is obsolete</em></span>.
+                  It was used in <acronym class="acronym">BIND</acronym> 8 to
+                  determine whether a transaction log was
+                  kept for Incremental Zone Transfer. <acronym class="acronym">BIND</acronym> 9 maintains a transaction
+                  log whenever possible.  If you need to disable outgoing
+                  incremental zone
+                  transfers, use <span><strong class="command">provide-ixfr</strong></span> <strong class="userinput"><code>no</code></strong>.
+                </p></dd>
+<dt><span class="term"><span><strong class="command">minimal-responses</strong></span></span></dt>
+<dd><p>
+                  If <strong class="userinput"><code>yes</code></strong>, then when generating
+                  responses the server will only add records to the authority
+                  and additional data sections when they are required (e.g.
+                  delegations, negative responses).  This may improve the
+                  performance of the server.
+                  The default is <strong class="userinput"><code>no</code></strong>.
+                </p></dd>
+<dt><span class="term"><span><strong class="command">multiple-cnames</strong></span></span></dt>
+<dd><p>
+                  This option was used in <acronym class="acronym">BIND</acronym> 8 to allow
+                  a domain name to have multiple CNAME records in violation of
+                  the DNS standards.  <acronym class="acronym">BIND</acronym> 9.2 onwards
+                  always strictly enforces the CNAME rules both in master
+                  files and dynamic updates.
+                </p></dd>
+<dt><span class="term"><span><strong class="command">notify</strong></span></span></dt>
+<dd>
+<p>
+                  If <strong class="userinput"><code>yes</code></strong> (the default),
+                  DNS NOTIFY messages are sent when a zone the server is
+                  authoritative for
+                  changes, see <a href="Bv9ARM.ch04.html#notify" title="Notify">the section called &#8220;Notify&#8221;</a>.  The messages are
+                  sent to the
+                  servers listed in the zone's NS records (except the master
+                  server identified
+                  in the SOA MNAME field), and to any servers listed in the
+                  <span><strong class="command">also-notify</strong></span> option.
+                </p>
+<p>
+                  If <strong class="userinput"><code>master-only</code></strong>, notifies are only
+                  sent
+                  for master zones.
+                  If <strong class="userinput"><code>explicit</code></strong>, notifies are sent only
+                  to
+                  servers explicitly listed using <span><strong class="command">also-notify</strong></span>.
+                  If <strong class="userinput"><code>no</code></strong>, no notifies are sent.
+                </p>
+<p>
+                  The <span><strong class="command">notify</strong></span> option may also be
+                  specified in the <span><strong class="command">zone</strong></span>
+                  statement,
+                  in which case it overrides the <span><strong class="command">options notify</strong></span> statement.
+                  It would only be necessary to turn off this option if it
+                  caused slaves
+                  to crash.
+                </p>
+</dd>
+<dt><span class="term"><span><strong class="command">recursion</strong></span></span></dt>
+<dd><p>
+                  If <strong class="userinput"><code>yes</code></strong>, and a
+                  DNS query requests recursion, then the server will attempt
+                  to do
+                  all the work required to answer the query. If recursion is
+                  off
+                  and the server does not already know the answer, it will
+                  return a
+                  referral response. The default is
+                  <strong class="userinput"><code>yes</code></strong>.
+                  Note that setting <span><strong class="command">recursion no</strong></span> does not prevent
+                  clients from getting data from the server's cache; it only
+                  prevents new data from being cached as an effect of client
+                  queries.
+                  Caching may still occur as an effect the server's internal
+                  operation, such as NOTIFY address lookups.
+                  See also <span><strong class="command">fetch-glue</strong></span> above.
+                </p></dd>
+<dt><span class="term"><span><strong class="command">rfc2308-type1</strong></span></span></dt>
+<dd>
+<p>
+                  Setting this to <strong class="userinput"><code>yes</code></strong> will
+                  cause the server to send NS records along with the SOA
+                  record for negative
+                  answers. The default is <strong class="userinput"><code>no</code></strong>.
+                </p>
+<div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
+<h3 class="title">Note</h3>
+<p>
+                    Not yet implemented in <acronym class="acronym">BIND</acronym>
+                    9.
+                  </p>
+</div>
+</dd>
+<dt><span class="term"><span><strong class="command">use-id-pool</strong></span></span></dt>
+<dd><p>
+                  <span class="emphasis"><em>This option is obsolete</em></span>.
+                  <acronym class="acronym">BIND</acronym> 9 always allocates query
+                  IDs from a pool.
+                </p></dd>
+<dt><span class="term"><span><strong class="command">zone-statistics</strong></span></span></dt>
+<dd><p>
+                  If <strong class="userinput"><code>yes</code></strong>, the server will collect
+                  statistical data on all zones (unless specifically turned
+                  off
+                  on a per-zone basis by specifying <span><strong class="command">zone-statistics no</strong></span>
+                  in the <span><strong class="command">zone</strong></span> statement).
+                  These statistics may be accessed
+                  using <span><strong class="command">rndc stats</strong></span>, which will
+                  dump them to the file listed
+                  in the <span><strong class="command">statistics-file</strong></span>.  See
+                  also <a href="Bv9ARM.ch06.html#statsfile" title="The Statistics File">the section called &#8220;The Statistics File&#8221;</a>.
+                </p></dd>
+<dt><span class="term"><span><strong class="command">use-ixfr</strong></span></span></dt>
+<dd><p>
+                  <span class="emphasis"><em>This option is obsolete</em></span>.
+                  If you need to disable IXFR to a particular server or
+                  servers, see
+                  the information on the <span><strong class="command">provide-ixfr</strong></span> option
+                  in <a href="Bv9ARM.ch06.html#server_statement_definition_and_usage" title="server Statement Definition and
+            Usage">the section called &#8220;<span><strong class="command">server</strong></span> Statement Definition and
+            Usage&#8221;</a>.
+                  See also
+                  <a href="Bv9ARM.ch04.html#incremental_zone_transfers" title="Incremental Zone Transfers (IXFR)">the section called &#8220;Incremental Zone Transfers (IXFR)&#8221;</a>.
+                </p></dd>
+<dt><span class="term"><span><strong class="command">provide-ixfr</strong></span></span></dt>
+<dd><p>
+                  See the description of
+                  <span><strong class="command">provide-ixfr</strong></span> in
+                  <a href="Bv9ARM.ch06.html#server_statement_definition_and_usage" title="server Statement Definition and
+            Usage">the section called &#8220;<span><strong class="command">server</strong></span> Statement Definition and
+            Usage&#8221;</a>.
+                </p></dd>
+<dt><span class="term"><span><strong class="command">request-ixfr</strong></span></span></dt>
+<dd><p>
+                  See the description of
+                  <span><strong class="command">request-ixfr</strong></span> in
+                  <a href="Bv9ARM.ch06.html#server_statement_definition_and_usage" title="server Statement Definition and
+            Usage">the section called &#8220;<span><strong class="command">server</strong></span> Statement Definition and
+            Usage&#8221;</a>.
+                </p></dd>
+<dt><span class="term"><span><strong class="command">treat-cr-as-space</strong></span></span></dt>
+<dd><p>
+                  This option was used in <acronym class="acronym">BIND</acronym>
+                  8 to make
+                  the server treat carriage return ("<span><strong class="command">\r</strong></span>") characters the same way
+                  as a space or tab character,
+                  to facilitate loading of zone files on a UNIX system that
+                  were generated
+                  on an NT or DOS machine. In <acronym class="acronym">BIND</acronym> 9, both UNIX "<span><strong class="command">\n</strong></span>"
+                  and NT/DOS "<span><strong class="command">\r\n</strong></span>" newlines
+                  are always accepted,
+                  and the option is ignored.
+                </p></dd>
+<dt>
+<span class="term"><span><strong class="command">additional-from-auth</strong></span>, </span><span class="term"><span><strong class="command">additional-from-cache</strong></span></span>
+</dt>
+<dd>
+<p>
+                  These options control the behavior of an authoritative
+                  server when
+                  answering queries which have additional data, or when
+                  following CNAME
+                  and DNAME chains.
+                </p>
+<p>
+                  When both of these options are set to <strong class="userinput"><code>yes</code></strong>
+                  (the default) and a
+                  query is being answered from authoritative data (a zone
+                  configured into the server), the additional data section of
+                  the
+                  reply will be filled in using data from other authoritative
+                  zones
+                  and from the cache.  In some situations this is undesirable,
+                  such
+                  as when there is concern over the correctness of the cache,
+                  or
+                  in servers where slave zones may be added and modified by
+                  untrusted third parties.  Also, avoiding
+                  the search for this additional data will speed up server
+                  operations
+                  at the possible expense of additional queries to resolve
+                  what would
+                  otherwise be provided in the additional section.
+                </p>
+<p>
+                  For example, if a query asks for an MX record for host <code class="literal">foo.example.com</code>,
+                  and the record found is "<code class="literal">MX 10 mail.example.net</code>", normally the address
+                  records (A and AAAA) for <code class="literal">mail.example.net</code> will be provided as well,
+                  if known, even though they are not in the example.com zone.
+                  Setting these options to <span><strong class="command">no</strong></span>
+                  disables this behavior and makes
+                  the server only search for additional data in the zone it
+                  answers from.
+                </p>
+<p>
+                  These options are intended for use in authoritative-only
+                  servers, or in authoritative-only views.  Attempts to set
+                  them to <span><strong class="command">no</strong></span> without also
+                  specifying
+                  <span><strong class="command">recursion no</strong></span> will cause the
+                  server to
+                  ignore the options and log a warning message.
+                </p>
+<p>
+                  Specifying <span><strong class="command">additional-from-cache no</strong></span> actually
+                  disables the use of the cache not only for additional data
+                  lookups
+                  but also when looking up the answer.  This is usually the
+                  desired
+                  behavior in an authoritative-only server where the
+                  correctness of
+                  the cached data is an issue.
+                </p>
+<p>
+                  When a name server is non-recursively queried for a name
+                  that is not
+                  below the apex of any served zone, it normally answers with
+                  an
+                  "upwards referral" to the root servers or the servers of
+                  some other
+                  known parent of the query name.  Since the data in an
+                  upwards referral
+                  comes from the cache, the server will not be able to provide
+                  upwards
+                  referrals when <span><strong class="command">additional-from-cache no</strong></span>
+                  has been specified.  Instead, it will respond to such
+                  queries
+                  with REFUSED.  This should not cause any problems since
+                  upwards referrals are not required for the resolution
+                  process.
+                </p>
+</dd>
+<dt><span class="term"><span><strong class="command">match-mapped-addresses</strong></span></span></dt>
+<dd><p>
+                  If <strong class="userinput"><code>yes</code></strong>, then an
+                  IPv4-mapped IPv6 address will match any address match
+                  list entries that match the corresponding IPv4 address.
+                  Enabling this option is sometimes useful on IPv6-enabled
+                  Linux
+                  systems, to work around a kernel quirk that causes IPv4
+                  TCP connections such as zone transfers to be accepted
+                  on an IPv6 socket using mapped addresses, causing
+                  address match lists designed for IPv4 to fail to match.
+                  The use of this option for any other purpose is discouraged.
+                </p></dd>
+<dt><span class="term"><span><strong class="command">ixfr-from-differences</strong></span></span></dt>
+<dd>
+<p>
+                  When <strong class="userinput"><code>yes</code></strong> and the server loads a new version of a master
+                  zone from its zone file or receives a new version of a slave
+                  file by a non-incremental zone transfer, it will compare
+                  the new version to the previous one and calculate a set
+                  of differences.  The differences are then logged in the
+                  zone's journal file such that the changes can be transmitted
+                  to downstream slaves as an incremental zone transfer.
+                </p>
+<p>
+                  By allowing incremental zone transfers to be used for
+                  non-dynamic zones, this option saves bandwidth at the
+                  expense of increased CPU and memory consumption at the
+                  master.
+                  In particular, if the new version of a zone is completely
+                  different from the previous one, the set of differences
+                  will be of a size comparable to the combined size of the
+                  old and new zone version, and the server will need to
+                  temporarily allocate memory to hold this complete
+                  difference set.
+                </p>
+<p><span><strong class="command">ixfr-from-differences</strong></span>
+                  also accepts <span><strong class="command">master</strong></span> and
+                  <span><strong class="command">slave</strong></span> at the view and options
+                  levels which causes
+                  <span><strong class="command">ixfr-from-differences</strong></span> to apply to
+                  all <span><strong class="command">master</strong></span> or
+                  <span><strong class="command">slave</strong></span> zones respectively.
+                </p>
+</dd>
+<dt><span class="term"><span><strong class="command">multi-master</strong></span></span></dt>
+<dd><p>
+                  This should be set when you have multiple masters for a zone
+                  and the
+                  addresses refer to different machines.  If <strong class="userinput"><code>yes</code></strong>, named will
+                  not log
+                  when the serial number on the master is less than what named
+                  currently
+                  has.  The default is <strong class="userinput"><code>no</code></strong>.
+                </p></dd>
+<dt><span class="term"><span><strong class="command">dnssec-enable</strong></span></span></dt>
+<dd><p>
+                  Enable DNSSEC support in named.  Unless set to <strong class="userinput"><code>yes</code></strong>,
+                  named behaves as if it does not support DNSSEC.
+                  The default is <strong class="userinput"><code>yes</code></strong>.
+                </p></dd>
+<dt><span class="term"><span><strong class="command">dnssec-validation</strong></span></span></dt>
+<dd><p>
+                  Enable DNSSEC validation in named.
+                  Note <span><strong class="command">dnssec-enable</strong></span> also needs to be
+                  set to <strong class="userinput"><code>yes</code></strong> to be effective.
+                  The default is <strong class="userinput"><code>no</code></strong>.
+                </p></dd>
+<dt><span class="term"><span><strong class="command">dnssec-accept-expired</strong></span></span></dt>
+<dd><p>
+                  Accept expired signatures when verifying DNSSEC signatures.
+                  The default is <strong class="userinput"><code>no</code></strong>.
+                  Setting this option to "yes" leaves named vulnerable to replay attacks.
+                </p></dd>
+<dt><span class="term"><span><strong class="command">querylog</strong></span></span></dt>
+<dd><p>
+                  Specify whether query logging should be started when named
+                  starts.
+                  If <span><strong class="command">querylog</strong></span> is not specified,
+                  then the query logging
+                  is determined by the presence of the logging category <span><strong class="command">queries</strong></span>.
+                </p></dd>
+<dt><span class="term"><span><strong class="command">check-names</strong></span></span></dt>
+<dd>
+<p>
+                  This option is used to restrict the character set and syntax
+                  of
+                  certain domain names in master files and/or DNS responses
+                  received
+                  from the network.  The default varies according to usage
+                  area.  For
+                  <span><strong class="command">master</strong></span> zones the default is <span><strong class="command">fail</strong></span>.
+                  For <span><strong class="command">slave</strong></span> zones the default
+                  is <span><strong class="command">warn</strong></span>.
+                  For answers received from the network (<span><strong class="command">response</strong></span>)
+                  the default is <span><strong class="command">ignore</strong></span>.
+                </p>
+<p>
+                  The rules for legal hostnames and mail domains are derived
+                  from RFC 952 and RFC 821 as modified by RFC 1123.
+                </p>
+<p><span><strong class="command">check-names</strong></span>
+                  applies to the owner names of A, AAA and MX records.
+                  It also applies to the domain names in the RDATA of NS, SOA
+                  and MX records.
+                  It also applies to the RDATA of PTR records where the owner
+                  name indicated that it is a reverse lookup of a hostname
+                  (the owner name ends in IN-ADDR.ARPA, IP6.ARPA, or IP6.INT).
+                </p>
+</dd>
+<dt><span class="term"><span><strong class="command">check-mx</strong></span></span></dt>
+<dd><p>
+                  Check whether the MX record appears to refer to a IP address.
+                  The default is to <span><strong class="command">warn</strong></span>.  Other possible
+                  values are <span><strong class="command">fail</strong></span> and
+                  <span><strong class="command">ignore</strong></span>.
+                </p></dd>
+<dt><span class="term"><span><strong class="command">check-wildcard</strong></span></span></dt>
+<dd><p>
+                  This option is used to check for non-terminal wildcards.
+                  The use of non-terminal wildcards is almost always as a
+                  result of a failure
+                  to understand the wildcard matching algorithm (RFC 1034).
+                  This option
+                  affects master zones.  The default (<span><strong class="command">yes</strong></span>) is to check
+                  for non-terminal wildcards and issue a warning.
+                </p></dd>
+<dt><span class="term"><span><strong class="command">check-integrity</strong></span></span></dt>
+<dd><p>
+                  Perform post load zone integrity checks on master
+                  zones.  This checks that MX and SRV records refer
+                  to address (A or AAAA) records and that glue
+                  address records exist for delegated zones.  For
+                  MX and SRV records only in-zone hostnames are
+                  checked (for out-of-zone hostnames use named-checkzone).
+                  For NS records only names below top of zone are
+                  checked (for out-of-zone names and glue consistency
+                  checks use named-checkzone).  The default is
+                  <span><strong class="command">yes</strong></span>.
+                </p></dd>
+<dt><span class="term"><span><strong class="command">check-mx-cname</strong></span></span></dt>
+<dd><p>
+                  If <span><strong class="command">check-integrity</strong></span> is set then
+                  fail, warn or ignore MX records that refer
+                  to CNAMES.  The default is to <span><strong class="command">warn</strong></span>.
+                </p></dd>
+<dt><span class="term"><span><strong class="command">check-srv-cname</strong></span></span></dt>
+<dd><p>
+                  If <span><strong class="command">check-integrity</strong></span> is set then
+                  fail, warn or ignore SRV records that refer
+                  to CNAMES.  The default is to <span><strong class="command">warn</strong></span>.
+                </p></dd>
+<dt><span class="term"><span><strong class="command">check-sibling</strong></span></span></dt>
+<dd><p>
+                  When performing integrity checks, also check that
+                  sibling glue exists.  The default is <span><strong class="command">yes</strong></span>.
+                </p></dd>
+<dt><span class="term"><span><strong class="command">zero-no-soa-ttl</strong></span></span></dt>
+<dd><p>
+                  When returning authoritative negative responses to
+                  SOA queries set the TTL of the SOA recored returned in
+                  the authority section to zero.
+                  The default is <span><strong class="command">yes</strong></span>.
+                </p></dd>
+<dt><span class="term"><span><strong class="command">zero-no-soa-ttl-cache</strong></span></span></dt>
+<dd><p>
+                  When caching a negative response to a SOA query
+                  set the TTL to zero.
+                  The default is <span><strong class="command">no</strong></span>.
+                </p></dd>
+<dt><span class="term"><span><strong class="command">update-check-ksk</strong></span></span></dt>
+<dd><p>
+                  When regenerating the RRSIGs following a UPDATE
+                  request to a secure zone, check the KSK flag on
+                  the DNSKEY RR to determine if this key should be
+                  used to generate the RRSIG.  This flag is ignored
+                  if there are not DNSKEY RRs both with and without
+                  a KSK.
+                  The default is <span><strong class="command">yes</strong></span>.
+                </p></dd>
+</dl></div>
+</div>
+<div class="sect3" lang="en">
+<div class="titlepage"><div><div><h4 class="title">
+<a name="id2580536"></a>Forwarding</h4></div></div></div>
+<p>
+            The forwarding facility can be used to create a large site-wide
+            cache on a few servers, reducing traffic over links to external
+            name servers. It can also be used to allow queries by servers that
+            do not have direct access to the Internet, but wish to look up
+            exterior
+            names anyway. Forwarding occurs only on those queries for which
+            the server is not authoritative and does not have the answer in
+            its cache.
+          </p>
+<div class="variablelist"><dl>
+<dt><span class="term"><span><strong class="command">forward</strong></span></span></dt>
+<dd><p>
+                  This option is only meaningful if the
+                  forwarders list is not empty. A value of <code class="varname">first</code>,
+                  the default, causes the server to query the forwarders
+                  first &#8212; and
+                  if that doesn't answer the question, the server will then
+                  look for
+                  the answer itself. If <code class="varname">only</code> is
+                  specified, the
+                  server will only query the forwarders.
+                </p></dd>
+<dt><span class="term"><span><strong class="command">forwarders</strong></span></span></dt>
+<dd><p>
+                  Specifies the IP addresses to be used
+                  for forwarding. The default is the empty list (no
+                  forwarding).
+                </p></dd>
+</dl></div>
+<p>
+            Forwarding can also be configured on a per-domain basis, allowing
+            for the global forwarding options to be overridden in a variety
+            of ways. You can set particular domains to use different
+            forwarders,
+            or have a different <span><strong class="command">forward only/first</strong></span> behavior,
+            or not forward at all, see <a href="Bv9ARM.ch06.html#zone_statement_grammar" title="zone
+            Statement Grammar">the section called &#8220;<span><strong class="command">zone</strong></span>
+            Statement Grammar&#8221;</a>.
+          </p>
+</div>
+<div class="sect3" lang="en">
+<div class="titlepage"><div><div><h4 class="title">
+<a name="id2580595"></a>Dual-stack Servers</h4></div></div></div>
+<p>
+            Dual-stack servers are used as servers of last resort to work
+            around
+            problems in reachability due the lack of support for either IPv4
+            or IPv6
+            on the host machine.
+          </p>
+<div class="variablelist"><dl>
+<dt><span class="term"><span><strong class="command">dual-stack-servers</strong></span></span></dt>
+<dd><p>
+                  Specifies host names or addresses of machines with access to
+                  both IPv4 and IPv6 transports. If a hostname is used, the
+                  server must be able
+                  to resolve the name using only the transport it has.  If the
+                  machine is dual
+                  stacked, then the <span><strong class="command">dual-stack-servers</strong></span> have no effect unless
+                  access to a transport has been disabled on the command line
+                  (e.g. <span><strong class="command">named -4</strong></span>).
+                </p></dd>
+</dl></div>
+</div>
+<div class="sect3" lang="en">
+<div class="titlepage"><div><div><h4 class="title">
+<a name="access_control"></a>Access Control</h4></div></div></div>
+<p>
+            Access to the server can be restricted based on the IP address
+            of the requesting system. See <a href="Bv9ARM.ch06.html#address_match_lists" title="Address Match Lists">the section called &#8220;Address Match Lists&#8221;</a> for
+            details on how to specify IP address lists.
+          </p>
+<div class="variablelist"><dl>
+<dt><span class="term"><span><strong class="command">allow-notify</strong></span></span></dt>
+<dd><p>
+                  Specifies which hosts are allowed to
+                  notify this server, a slave, of zone changes in addition
+                  to the zone masters.
+                  <span><strong class="command">allow-notify</strong></span> may also be
+                  specified in the
+                  <span><strong class="command">zone</strong></span> statement, in which case
+                  it overrides the
+                  <span><strong class="command">options allow-notify</strong></span>
+                  statement.  It is only meaningful
+                  for a slave zone.  If not specified, the default is to
+                  process notify messages
+                  only from a zone's master.
+                </p></dd>
+<dt><span class="term"><span><strong class="command">allow-query</strong></span></span></dt>
+<dd>
+<p>
+                  Specifies which hosts are allowed to ask ordinary
+                  DNS questions. <span><strong class="command">allow-query</strong></span> may
+                  also be specified in the <span><strong class="command">zone</strong></span>
+                  statement, in which case it overrides the
+                  <span><strong class="command">options allow-query</strong></span> statement.
+                  If not specified, the default is to allow queries
+                  from all hosts.
+                </p>
+<div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
+<h3 class="title">Note</h3>
+<p>
+                    <span><strong class="command">allow-query-cache</strong></span> is now
+                    used to specify access to the cache.
+                  </p>
+</div>
+</dd>
+<dt><span class="term"><span><strong class="command">allow-query-cache</strong></span></span></dt>
+<dd><p>
+                  Specifies which hosts are allowed to get answers
+                  from the cache.  If <span><strong class="command">allow-query-cache</strong></span>
+                  is not set then <span><strong class="command">allow-recursion</strong></span>
+                  is used if set, otherwise <span><strong class="command">allow-query</strong></span>
+                  is used if set, otherwise the default
+                  (<span><strong class="command">localnets;</strong></span>
+                  <span><strong class="command">localhost;</strong></span>) is used.
+                </p></dd>
+<dt><span class="term"><span><strong class="command">allow-recursion</strong></span></span></dt>
+<dd><p>
+                  Specifies which hosts are allowed to make recursive
+                  queries through this server. If
+                  <span><strong class="command">allow-recursion</strong></span> is not set
+                  then <span><strong class="command">allow-query-cache</strong></span> is
+                  used if set, otherwise <span><strong class="command">allow-query</strong></span>
+                  is used if set, otherwise the default
+                  (<span><strong class="command">localnets;</strong></span>
+                  <span><strong class="command">localhost;</strong></span>) is used.
+                </p></dd>
+<dt><span class="term"><span><strong class="command">allow-update</strong></span></span></dt>
+<dd><p>
+                  Specifies which hosts are allowed to
+                  submit Dynamic DNS updates for master zones. The default is
+                  to deny
+                  updates from all hosts.  Note that allowing updates based
+                  on the requestor's IP address is insecure; see
+                  <a href="Bv9ARM.ch07.html#dynamic_update_security" title="Dynamic Update Security">the section called &#8220;Dynamic Update Security&#8221;</a> for details.
+                </p></dd>
+<dt><span class="term"><span><strong class="command">allow-update-forwarding</strong></span></span></dt>
+<dd>
+<p>
+                  Specifies which hosts are allowed to
+                  submit Dynamic DNS updates to slave zones to be forwarded to
+                  the
+                  master.  The default is <strong class="userinput"><code>{ none; }</code></strong>,
+                  which
+                  means that no update forwarding will be performed.  To
+                  enable
+                  update forwarding, specify
+                  <strong class="userinput"><code>allow-update-forwarding { any; };</code></strong>.
+                  Specifying values other than <strong class="userinput"><code>{ none; }</code></strong> or
+                  <strong class="userinput"><code>{ any; }</code></strong> is usually
+                  counterproductive, since
+                  the responsibility for update access control should rest
+                  with the
+                  master server, not the slaves.
+                </p>
+<p>
+                  Note that enabling the update forwarding feature on a slave
+                  server
+                  may expose master servers relying on insecure IP address
+                  based
+                  access control to attacks; see <a href="Bv9ARM.ch07.html#dynamic_update_security" title="Dynamic Update Security">the section called &#8220;Dynamic Update Security&#8221;</a>
+                  for more details.
+                </p>
+</dd>
+<dt><span class="term"><span><strong class="command">allow-v6-synthesis</strong></span></span></dt>
+<dd><p>
+                  This option was introduced for the smooth transition from
+                  AAAA
+                  to A6 and from "nibble labels" to binary labels.
+                  However, since both A6 and binary labels were then
+                  deprecated,
+                  this option was also deprecated.
+                  It is now ignored with some warning messages.
+                </p></dd>
+<dt><span class="term"><span><strong class="command">allow-transfer</strong></span></span></dt>
+<dd><p>
+                  Specifies which hosts are allowed to
+                  receive zone transfers from the server. <span><strong class="command">allow-transfer</strong></span> may
+                  also be specified in the <span><strong class="command">zone</strong></span>
+                  statement, in which
+                  case it overrides the <span><strong class="command">options allow-transfer</strong></span> statement.
+                  If not specified, the default is to allow transfers to all
+                  hosts.
+                </p></dd>
+<dt><span class="term"><span><strong class="command">blackhole</strong></span></span></dt>
+<dd><p>
+                  Specifies a list of addresses that the
+                  server will not accept queries from or use to resolve a
+                  query. Queries
+                  from these addresses will not be responded to. The default
+                  is <strong class="userinput"><code>none</code></strong>.
+                </p></dd>
+</dl></div>
+</div>
+<div class="sect3" lang="en">
+<div class="titlepage"><div><div><h4 class="title">
+<a name="id2581153"></a>Interfaces</h4></div></div></div>
+<p>
+            The interfaces and ports that the server will answer queries
+            from may be specified using the <span><strong class="command">listen-on</strong></span> option. <span><strong class="command">listen-on</strong></span> takes
+            an optional port, and an <code class="varname">address_match_list</code>.
+            The server will listen on all interfaces allowed by the address
+            match list. If a port is not specified, port 53 will be used.
+          </p>
+<p>
+            Multiple <span><strong class="command">listen-on</strong></span> statements are
+            allowed.
+            For example,
+          </p>
+<pre class="programlisting">listen-on { 5.6.7.8; };
+listen-on port 1234 { !1.2.3.4; 1.2/16; };
+</pre>
+<p>
+            will enable the name server on port 53 for the IP address
+            5.6.7.8, and on port 1234 of an address on the machine in net
+            1.2 that is not 1.2.3.4.
+          </p>
+<p>
+            If no <span><strong class="command">listen-on</strong></span> is specified, the
+            server will listen on port 53 on all interfaces.
+          </p>
+<p>
+            The <span><strong class="command">listen-on-v6</strong></span> option is used to
+            specify the interfaces and the ports on which the server will
+            listen
+            for incoming queries sent using IPv6.
+          </p>
+<p>
+            When </p>
+<pre class="programlisting">{ any; }</pre>
+<p> is
+            specified
+            as the <code class="varname">address_match_list</code> for the
+            <span><strong class="command">listen-on-v6</strong></span> option,
+            the server does not bind a separate socket to each IPv6 interface
+            address as it does for IPv4 if the operating system has enough API
+            support for IPv6 (specifically if it conforms to RFC 3493 and RFC
+            3542).
+            Instead, it listens on the IPv6 wildcard address.
+            If the system only has incomplete API support for IPv6, however,
+            the behavior is the same as that for IPv4.
+          </p>
+<p>
+            A list of particular IPv6 addresses can also be specified, in
+            which case
+            the server listens on a separate socket for each specified
+            address,
+            regardless of whether the desired API is supported by the system.
+          </p>
+<p>
+            Multiple <span><strong class="command">listen-on-v6</strong></span> options can
+            be used.
+            For example,
+          </p>
+<pre class="programlisting">listen-on-v6 { any; };
+listen-on-v6 port 1234 { !2001:db8::/32; any; };
+</pre>
+<p>
+            will enable the name server on port 53 for any IPv6 addresses
+            (with a single wildcard socket),
+            and on port 1234 of IPv6 addresses that is not in the prefix
+            2001:db8::/32 (with separate sockets for each matched address.)
+          </p>
+<p>
+            To make the server not listen on any IPv6 address, use
+          </p>
+<pre class="programlisting">listen-on-v6 { none; };
+</pre>
+<p>
+            If no <span><strong class="command">listen-on-v6</strong></span> option is
+            specified,
+            the server will not listen on any IPv6 address.
+          </p>
+</div>
+<div class="sect3" lang="en">
+<div class="titlepage"><div><div><h4 class="title">
+<a name="id2581241"></a>Query Address</h4></div></div></div>
+<p>
+            If the server doesn't know the answer to a question, it will
+            query other name servers. <span><strong class="command">query-source</strong></span> specifies
+            the address and port used for such queries. For queries sent over
+            IPv6, there is a separate <span><strong class="command">query-source-v6</strong></span> option.
+            If <span><strong class="command">address</strong></span> is <span><strong class="command">*</strong></span> (asterisk) or is omitted,
+            a wildcard IP address (<span><strong class="command">INADDR_ANY</strong></span>)
+            will be used.
+            If <span><strong class="command">port</strong></span> is <span><strong class="command">*</strong></span> or is omitted,
+            a random unprivileged port will be used. The <span><strong class="command">avoid-v4-udp-ports</strong></span>
+            and <span><strong class="command">avoid-v6-udp-ports</strong></span> options can be used
+            to prevent named
+            from selecting certain ports. The defaults are:
+          </p>
+<pre class="programlisting">query-source address * port *;
+query-source-v6 address * port *;
+</pre>
+<div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
+<h3 class="title">Note</h3>
+<p>
+              The address specified in the <span><strong class="command">query-source</strong></span> option
+              is used for both UDP and TCP queries, but the port applies only
+              to
+              UDP queries.  TCP queries always use a random
+              unprivileged port.
+            </p>
+</div>
+<div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
+<h3 class="title">Note</h3>
+<p>
+              Solaris 2.5.1 and earlier does not support setting the source
+              address for TCP sockets.
+            </p>
+</div>
+<div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
+<h3 class="title">Note</h3>
+<p>
+              See also <span><strong class="command">transfer-source</strong></span> and
+              <span><strong class="command">notify-source</strong></span>.
+            </p>
+</div>
+</div>
+<div class="sect3" lang="en">
+<div class="titlepage"><div><div><h4 class="title">
+<a name="zone_transfers"></a>Zone Transfers</h4></div></div></div>
+<p>
+            <acronym class="acronym">BIND</acronym> has mechanisms in place to
+            facilitate zone transfers
+            and set limits on the amount of load that transfers place on the
+            system. The following options apply to zone transfers.
+          </p>
+<div class="variablelist"><dl>
+<dt><span class="term"><span><strong class="command">also-notify</strong></span></span></dt>
+<dd><p>
+                  Defines a global list of IP addresses of name servers
+                  that are also sent NOTIFY messages whenever a fresh copy of
+                  the
+                  zone is loaded, in addition to the servers listed in the
+                  zone's NS records.
+                  This helps to ensure that copies of the zones will
+                  quickly converge on stealth servers. If an <span><strong class="command">also-notify</strong></span> list
+                  is given in a <span><strong class="command">zone</strong></span> statement,
+                  it will override
+                  the <span><strong class="command">options also-notify</strong></span>
+                  statement. When a <span><strong class="command">zone notify</strong></span>
+                  statement
+                  is set to <span><strong class="command">no</strong></span>, the IP
+                  addresses in the global <span><strong class="command">also-notify</strong></span> list will
+                  not be sent NOTIFY messages for that zone. The default is
+                  the empty
+                  list (no global notification list).
+                </p></dd>
+<dt><span class="term"><span><strong class="command">max-transfer-time-in</strong></span></span></dt>
+<dd><p>
+                  Inbound zone transfers running longer than
+                  this many minutes will be terminated. The default is 120
+                  minutes
+                  (2 hours).  The maximum value is 28 days (40320 minutes).
+                </p></dd>
+<dt><span class="term"><span><strong class="command">max-transfer-idle-in</strong></span></span></dt>
+<dd><p>
+                  Inbound zone transfers making no progress
+                  in this many minutes will be terminated. The default is 60
+                  minutes
+                  (1 hour).  The maximum value is 28 days (40320 minutes).
+                </p></dd>
+<dt><span class="term"><span><strong class="command">max-transfer-time-out</strong></span></span></dt>
+<dd><p>
+                  Outbound zone transfers running longer than
+                  this many minutes will be terminated. The default is 120
+                  minutes
+                  (2 hours).  The maximum value is 28 days (40320 minutes).
+                </p></dd>
+<dt><span class="term"><span><strong class="command">max-transfer-idle-out</strong></span></span></dt>
+<dd><p>
+                  Outbound zone transfers making no progress
+                  in this many minutes will be terminated.  The default is 60
+                  minutes (1
+                  hour).  The maximum value is 28 days (40320 minutes).
+                </p></dd>
+<dt><span class="term"><span><strong class="command">serial-query-rate</strong></span></span></dt>
+<dd><p>
+                  Slave servers will periodically query master servers
+                  to find out if zone serial numbers have changed. Each such
+                  query uses
+                  a minute amount of the slave server's network bandwidth.  To
+                  limit the
+                  amount of bandwidth used, BIND 9 limits the rate at which
+                  queries are
+                  sent.  The value of the <span><strong class="command">serial-query-rate</strong></span> option,
+                  an integer, is the maximum number of queries sent per
+                  second.
+                  The default is 20.
+                </p></dd>
+<dt><span class="term"><span><strong class="command">serial-queries</strong></span></span></dt>
+<dd><p>
+                  In BIND 8, the <span><strong class="command">serial-queries</strong></span>
+                  option
+                  set the maximum number of concurrent serial number queries
+                  allowed to be outstanding at any given time.
+                  BIND 9 does not limit the number of outstanding
+                  serial queries and ignores the <span><strong class="command">serial-queries</strong></span> option.
+                  Instead, it limits the rate at which the queries are sent
+                  as defined using the <span><strong class="command">serial-query-rate</strong></span> option.
+                </p></dd>
+<dt><span class="term"><span><strong class="command">transfer-format</strong></span></span></dt>
+<dd><p>
+                  Zone transfers can be sent using two different formats,
+                  <span><strong class="command">one-answer</strong></span> and
+                  <span><strong class="command">many-answers</strong></span>.
+                  The <span><strong class="command">transfer-format</strong></span> option is used
+                  on the master server to determine which format it sends.
+                  <span><strong class="command">one-answer</strong></span> uses one DNS message per
+                  resource record transferred.
+                  <span><strong class="command">many-answers</strong></span> packs as many resource
+                  records as possible into a message.
+                  <span><strong class="command">many-answers</strong></span> is more efficient, but is
+                  only supported by relatively new slave servers,
+                  such as <acronym class="acronym">BIND</acronym> 9, <acronym class="acronym">BIND</acronym>
+                  8.x and <acronym class="acronym">BIND</acronym> 4.9.5 onwards.
+                  The <span><strong class="command">many-answers</strong></span> format is also supported by
+                  recent Microsoft Windows nameservers.
+                  The default is <span><strong class="command">many-answers</strong></span>.
+                  <span><strong class="command">transfer-format</strong></span> may be overridden on a
+                  per-server basis by using the <span><strong class="command">server</strong></span>
+                  statement.
+                </p></dd>
+<dt><span class="term"><span><strong class="command">transfers-in</strong></span></span></dt>
+<dd><p>
+                  The maximum number of inbound zone transfers
+                  that can be running concurrently. The default value is <code class="literal">10</code>.
+                  Increasing <span><strong class="command">transfers-in</strong></span> may
+                  speed up the convergence
+                  of slave zones, but it also may increase the load on the
+                  local system.
+                </p></dd>
+<dt><span class="term"><span><strong class="command">transfers-out</strong></span></span></dt>
+<dd><p>
+                  The maximum number of outbound zone transfers
+                  that can be running concurrently. Zone transfer requests in
+                  excess
+                  of the limit will be refused. The default value is <code class="literal">10</code>.
+                </p></dd>
+<dt><span class="term"><span><strong class="command">transfers-per-ns</strong></span></span></dt>
+<dd><p>
+                  The maximum number of inbound zone transfers
+                  that can be concurrently transferring from a given remote
+                  name server.
+                  The default value is <code class="literal">2</code>.
+                  Increasing <span><strong class="command">transfers-per-ns</strong></span>
+                  may
+                  speed up the convergence of slave zones, but it also may
+                  increase
+                  the load on the remote name server. <span><strong class="command">transfers-per-ns</strong></span> may
+                  be overridden on a per-server basis by using the <span><strong class="command">transfers</strong></span> phrase
+                  of the <span><strong class="command">server</strong></span> statement.
+                </p></dd>
+<dt><span class="term"><span><strong class="command">transfer-source</strong></span></span></dt>
+<dd>
+<p><span><strong class="command">transfer-source</strong></span>
+                  determines which local address will be bound to IPv4
+                  TCP connections used to fetch zones transferred
+                  inbound by the server.  It also determines the
+                  source IPv4 address, and optionally the UDP port,
+                  used for the refresh queries and forwarded dynamic
+                  updates.  If not set, it defaults to a system
+                  controlled value which will usually be the address
+                  of the interface "closest to" the remote end. This
+                  address must appear in the remote end's
+                  <span><strong class="command">allow-transfer</strong></span> option for the
+                  zone being transferred, if one is specified. This
+                  statement sets the
+                  <span><strong class="command">transfer-source</strong></span> for all zones,
+                  but can be overridden on a per-view or per-zone
+                  basis by including a
+                  <span><strong class="command">transfer-source</strong></span> statement within
+                  the <span><strong class="command">view</strong></span> or
+                  <span><strong class="command">zone</strong></span> block in the configuration
+                  file.
+                </p>
+<div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
+<h3 class="title">Note</h3>
+<p>
+                    Solaris 2.5.1 and earlier does not support setting the
+                    source address for TCP sockets.
+                  </p>
+</div>
+</dd>
+<dt><span class="term"><span><strong class="command">transfer-source-v6</strong></span></span></dt>
+<dd><p>
+                  The same as <span><strong class="command">transfer-source</strong></span>,
+                  except zone transfers are performed using IPv6.
+                </p></dd>
+<dt><span class="term"><span><strong class="command">alt-transfer-source</strong></span></span></dt>
+<dd>
+<p>
+                  An alternate transfer source if the one listed in
+                  <span><strong class="command">transfer-source</strong></span> fails and
+                  <span><strong class="command">use-alt-transfer-source</strong></span> is
+                  set.
+                </p>
+<div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
+<h3 class="title">Note</h3>
+                  If you do not wish the alternate transfer source
+                  to be used, you should set
+                  <span><strong class="command">use-alt-transfer-source</strong></span>
+                  appropriately and you should not depend upon
+                  getting a answer back to the first refresh
+                  query.
+                </div>
+</dd>
+<dt><span class="term"><span><strong class="command">alt-transfer-source-v6</strong></span></span></dt>
+<dd><p>
+                  An alternate transfer source if the one listed in
+                  <span><strong class="command">transfer-source-v6</strong></span> fails and
+                  <span><strong class="command">use-alt-transfer-source</strong></span> is
+                  set.
+                </p></dd>
+<dt><span class="term"><span><strong class="command">use-alt-transfer-source</strong></span></span></dt>
+<dd><p>
+                  Use the alternate transfer sources or not.  If views are
+                  specified this defaults to <span><strong class="command">no</strong></span>
+                  otherwise it defaults to
+                  <span><strong class="command">yes</strong></span> (for BIND 8
+                  compatibility).
+                </p></dd>
+<dt><span class="term"><span><strong class="command">notify-source</strong></span></span></dt>
+<dd>
+<p><span><strong class="command">notify-source</strong></span>
+                  determines which local source address, and
+                  optionally UDP port, will be used to send NOTIFY
+                  messages.  This address must appear in the slave
+                  server's <span><strong class="command">masters</strong></span> zone clause or
+                  in an <span><strong class="command">allow-notify</strong></span> clause.  This
+                  statement sets the <span><strong class="command">notify-source</strong></span>
+                  for all zones, but can be overridden on a per-zone or
+                  per-view basis by including a
+                  <span><strong class="command">notify-source</strong></span> statement within
+                  the <span><strong class="command">zone</strong></span> or
+                  <span><strong class="command">view</strong></span> block in the configuration
+                  file.
+                </p>
+<div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
+<h3 class="title">Note</h3>
+<p>
+                    Solaris 2.5.1 and earlier does not support setting the
+                    source address for TCP sockets.
+                  </p>
+</div>
+</dd>
+<dt><span class="term"><span><strong class="command">notify-source-v6</strong></span></span></dt>
+<dd><p>
+                  Like <span><strong class="command">notify-source</strong></span>,
+                  but applies to notify messages sent to IPv6 addresses.
+                </p></dd>
+</dl></div>
+</div>
+<div class="sect3" lang="en">
+<div class="titlepage"><div><div><h4 class="title">
+<a name="id2581988"></a>Bad UDP Port Lists</h4></div></div></div>
+<p><span><strong class="command">avoid-v4-udp-ports</strong></span>
+            and <span><strong class="command">avoid-v6-udp-ports</strong></span> specify a list
+            of IPv4 and IPv6 UDP ports that will not be used as system
+            assigned source ports for UDP sockets.  These lists
+            prevent named from choosing as its random source port a
+            port that is blocked by your firewall.  If a query went
+            out with such a source port, the answer would not get by
+            the firewall and the name server would have to query
+            again.
+          </p>
+</div>
+<div class="sect3" lang="en">
+<div class="titlepage"><div><div><h4 class="title">
+<a name="id2582003"></a>Operating System Resource Limits</h4></div></div></div>
+<p>
+            The server's usage of many system resources can be limited.
+            Scaled values are allowed when specifying resource limits.  For
+            example, <span><strong class="command">1G</strong></span> can be used instead of
+            <span><strong class="command">1073741824</strong></span> to specify a limit of
+            one
+            gigabyte. <span><strong class="command">unlimited</strong></span> requests
+            unlimited use, or the
+            maximum available amount. <span><strong class="command">default</strong></span>
+            uses the limit
+            that was in force when the server was started. See the description
+            of <span><strong class="command">size_spec</strong></span> in <a href="Bv9ARM.ch06.html#configuration_file_elements" title="Configuration File Elements">the section called &#8220;Configuration File Elements&#8221;</a>.
+          </p>
+<p>
+            The following options set operating system resource limits for
+            the name server process.  Some operating systems don't support
+            some or
+            any of the limits. On such systems, a warning will be issued if
+            the
+            unsupported limit is used.
+          </p>
+<div class="variablelist"><dl>
+<dt><span class="term"><span><strong class="command">coresize</strong></span></span></dt>
+<dd><p>
+                  The maximum size of a core dump. The default
+                  is <code class="literal">default</code>.
+                </p></dd>
+<dt><span class="term"><span><strong class="command">datasize</strong></span></span></dt>
+<dd><p>
+                  The maximum amount of data memory the server
+                  may use. The default is <code class="literal">default</code>.
+                  This is a hard limit on server memory usage.
+                  If the server attempts to allocate memory in excess of this
+                  limit, the allocation will fail, which may in turn leave
+                  the server unable to perform DNS service.  Therefore,
+                  this option is rarely useful as a way of limiting the
+                  amount of memory used by the server, but it can be used
+                  to raise an operating system data size limit that is
+                  too small by default.  If you wish to limit the amount
+                  of memory used by the server, use the
+                  <span><strong class="command">max-cache-size</strong></span> and
+                  <span><strong class="command">recursive-clients</strong></span>
+                  options instead.
+                </p></dd>
+<dt><span class="term"><span><strong class="command">files</strong></span></span></dt>
+<dd><p>
+                  The maximum number of files the server
+                  may have open concurrently. The default is <code class="literal">unlimited</code>.
+                </p></dd>
+<dt><span class="term"><span><strong class="command">stacksize</strong></span></span></dt>
+<dd><p>
+                  The maximum amount of stack memory the server
+                  may use. The default is <code class="literal">default</code>.
+                </p></dd>
+</dl></div>
+</div>
+<div class="sect3" lang="en">
+<div class="titlepage"><div><div><h4 class="title">
+<a name="id2582186"></a>Server  Resource Limits</h4></div></div></div>
+<p>
+            The following options set limits on the server's
+            resource consumption that are enforced internally by the
+            server rather than the operating system.
+          </p>
+<div class="variablelist"><dl>
+<dt><span class="term"><span><strong class="command">max-ixfr-log-size</strong></span></span></dt>
+<dd><p>
+                  This option is obsolete; it is accepted
+                  and ignored for BIND 8 compatibility.  The option
+                  <span><strong class="command">max-journal-size</strong></span> performs a
+                  similar function in BIND 9.
+                </p></dd>
+<dt><span class="term"><span><strong class="command">max-journal-size</strong></span></span></dt>
+<dd><p>
+                  Sets a maximum size for each journal file
+                  (see <a href="Bv9ARM.ch04.html#journal" title="The journal file">the section called &#8220;The journal file&#8221;</a>).  When the journal file
+                  approaches
+                  the specified size, some of the oldest transactions in the
+                  journal
+                  will be automatically removed.  The default is
+                  <code class="literal">unlimited</code>.
+                </p></dd>
+<dt><span class="term"><span><strong class="command">host-statistics-max</strong></span></span></dt>
+<dd><p>
+                  In BIND 8, specifies the maximum number of host statistics
+                  entries to be kept.
+                  Not implemented in BIND 9.
+                </p></dd>
+<dt><span class="term"><span><strong class="command">recursive-clients</strong></span></span></dt>
+<dd><p>
+                  The maximum number of simultaneous recursive lookups
+                  the server will perform on behalf of clients.  The default
+                  is
+                  <code class="literal">1000</code>.  Because each recursing
+                  client uses a fair
+                  bit of memory, on the order of 20 kilobytes, the value of
+                  the
+                  <span><strong class="command">recursive-clients</strong></span> option may
+                  have to be decreased
+                  on hosts with limited memory.
+                </p></dd>
+<dt><span class="term"><span><strong class="command">tcp-clients</strong></span></span></dt>
+<dd><p>
+                  The maximum number of simultaneous client TCP
+                  connections that the server will accept.
+                  The default is <code class="literal">100</code>.
+                </p></dd>
+<dt><span class="term"><span><strong class="command">max-cache-size</strong></span></span></dt>
+<dd><p>
+                  The maximum amount of memory to use for the
+                  server's cache, in bytes.  When the amount of data in the
+                  cache
+                  reaches this limit, the server will cause records to expire
+                  prematurely so that the limit is not exceeded.  In a server
+                  with
+                  multiple views, the limit applies separately to the cache of
+                  each
+                  view.  The default is <code class="literal">unlimited</code>, meaning that
+                  records are purged from the cache only when their TTLs
+                  expire.
+                </p></dd>
+<dt><span class="term"><span><strong class="command">tcp-listen-queue</strong></span></span></dt>
+<dd><p>
+                  The listen queue depth.  The default and minimum is 3.
+                  If the kernel supports the accept filter "dataready" this
+                  also controls how
+                  many TCP connections that will be queued in kernel space
+                  waiting for
+                  some data before being passed to accept.  Values less than 3
+                  will be
+                  silently raised.
+                </p></dd>
+</dl></div>
+</div>
+<div class="sect3" lang="en">
+<div class="titlepage"><div><div><h4 class="title">
+<a name="id2582320"></a>Periodic Task Intervals</h4></div></div></div>
+<div class="variablelist"><dl>
+<dt><span class="term"><span><strong class="command">cleaning-interval</strong></span></span></dt>
+<dd><p>
+                  The server will remove expired resource records
+                  from the cache every <span><strong class="command">cleaning-interval</strong></span> minutes.
+                  The default is 60 minutes.  The maximum value is 28 days
+                  (40320 minutes).
+                  If set to 0, no periodic cleaning will occur.
+                </p></dd>
+<dt><span class="term"><span><strong class="command">heartbeat-interval</strong></span></span></dt>
+<dd><p>
+                  The server will perform zone maintenance tasks
+                  for all zones marked as <span><strong class="command">dialup</strong></span> whenever this
+                  interval expires. The default is 60 minutes. Reasonable
+                  values are up
+                  to 1 day (1440 minutes).  The maximum value is 28 days
+                  (40320 minutes).
+                  If set to 0, no zone maintenance for these zones will occur.
+                </p></dd>
+<dt><span class="term"><span><strong class="command">interface-interval</strong></span></span></dt>
+<dd><p>
+                  The server will scan the network interface list
+                  every <span><strong class="command">interface-interval</strong></span>
+                  minutes. The default
+                  is 60 minutes. The maximum value is 28 days (40320 minutes).
+                  If set to 0, interface scanning will only occur when
+                  the configuration file is  loaded. After the scan, the
+                  server will
+                  begin listening for queries on any newly discovered
+                  interfaces (provided they are allowed by the
+                  <span><strong class="command">listen-on</strong></span> configuration), and
+                  will
+                  stop listening on interfaces that have gone away.
+                </p></dd>
+<dt><span class="term"><span><strong class="command">statistics-interval</strong></span></span></dt>
+<dd>
+<p>
+                  Name server statistics will be logged
+                  every <span><strong class="command">statistics-interval</strong></span>
+                  minutes. The default is
+                  60. The maximum value is 28 days (40320 minutes).
+                  If set to 0, no statistics will be logged.
+                  </p>
+<div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
+<h3 class="title">Note</h3>
+<p>
+                    Not yet implemented in
+                    <acronym class="acronym">BIND</acronym> 9.
+                  </p>
+</div>
+</dd>
+</dl></div>
+</div>
+<div class="sect3" lang="en">
+<div class="titlepage"><div><div><h4 class="title">
+<a name="topology"></a>Topology</h4></div></div></div>
+<p>
+            All other things being equal, when the server chooses a name
+            server
+            to query from a list of name servers, it prefers the one that is
+            topologically closest to itself. The <span><strong class="command">topology</strong></span> statement
+            takes an <span><strong class="command">address_match_list</strong></span> and
+            interprets it
+            in a special way. Each top-level list element is assigned a
+            distance.
+            Non-negated elements get a distance based on their position in the
+            list, where the closer the match is to the start of the list, the
+            shorter the distance is between it and the server. A negated match
+            will be assigned the maximum distance from the server. If there
+            is no match, the address will get a distance which is further than
+            any non-negated list element, and closer than any negated element.
+            For example,
+          </p>
+<pre class="programlisting">topology {
+    10/8;
+    !1.2.3/24;
+    { 1.2/16; 3/8; };
+};</pre>
+<p>
+            will prefer servers on network 10 the most, followed by hosts
+            on network 1.2.0.0 (netmask 255.255.0.0) and network 3, with the
+            exception of hosts on network 1.2.3 (netmask 255.255.255.0), which
+            is preferred least of all.
+          </p>
+<p>
+            The default topology is
+          </p>
+<pre class="programlisting">    topology { localhost; localnets; };
+</pre>
+<div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
+<h3 class="title">Note</h3>
+<p>
+              The <span><strong class="command">topology</strong></span> option
+              is not implemented in <acronym class="acronym">BIND</acronym> 9.
+            </p>
+</div>
+</div>
+<div class="sect3" lang="en">
+<div class="titlepage"><div><div><h4 class="title">
+<a name="the_sortlist_statement"></a>The <span><strong class="command">sortlist</strong></span> Statement</h4></div></div></div>
+<p>
+            The response to a DNS query may consist of multiple resource
+            records (RRs) forming a resource records set (RRset).
+            The name server will normally return the
+            RRs within the RRset in an indeterminate order
+            (but see the <span><strong class="command">rrset-order</strong></span>
+            statement in <a href="Bv9ARM.ch06.html#rrset_ordering" title="RRset Ordering">the section called &#8220;RRset Ordering&#8221;</a>).
+            The client resolver code should rearrange the RRs as appropriate,
+            that is, using any addresses on the local net in preference to
+            other addresses.
+            However, not all resolvers can do this or are correctly
+            configured.
+            When a client is using a local server, the sorting can be performed
+            in the server, based on the client's address. This only requires
+            configuring the name servers, not all the clients.
+          </p>
+<p>
+            The <span><strong class="command">sortlist</strong></span> statement (see below)
+            takes
+            an <span><strong class="command">address_match_list</strong></span> and
+            interprets it even
+            more specifically than the <span><strong class="command">topology</strong></span>
+            statement
+            does (<a href="Bv9ARM.ch06.html#topology" title="Topology">the section called &#8220;Topology&#8221;</a>).
+            Each top level statement in the <span><strong class="command">sortlist</strong></span> must
+            itself be an explicit <span><strong class="command">address_match_list</strong></span> with
+            one or two elements. The first element (which may be an IP
+            address,
+            an IP prefix, an ACL name or a nested <span><strong class="command">address_match_list</strong></span>)
+            of each top level list is checked against the source address of
+            the query until a match is found.
+          </p>
+<p>
+            Once the source address of the query has been matched, if
+            the top level statement contains only one element, the actual
+            primitive
+            element that matched the source address is used to select the
+            address
+            in the response to move to the beginning of the response. If the
+            statement is a list of two elements, then the second element is
+            treated the same as the <span><strong class="command">address_match_list</strong></span> in
+            a <span><strong class="command">topology</strong></span> statement. Each top
+            level element
+            is assigned a distance and the address in the response with the
+            minimum
+            distance is moved to the beginning of the response.
+          </p>
+<p>
+            In the following example, any queries received from any of
+            the addresses of the host itself will get responses preferring
+            addresses
+            on any of the locally connected networks. Next most preferred are
+            addresses
+            on the 192.168.1/24 network, and after that either the
+            192.168.2/24
+            or
+            192.168.3/24 network with no preference shown between these two
+            networks. Queries received from a host on the 192.168.1/24 network
+            will prefer other addresses on that network to the 192.168.2/24
+            and
+            192.168.3/24 networks. Queries received from a host on the
+            192.168.4/24
+            or the 192.168.5/24 network will only prefer other addresses on
+            their directly connected networks.
+          </p>
+<pre class="programlisting">sortlist {
+    { localhost;                                   // IF   the local host
+        { localnets;                               // THEN first fit on the
+            192.168.1/24;                          //   following nets
+            { 192.168.2/24; 192.168.3/24; }; }; };
+    { 192.168.1/24;                                // IF   on class C 192.168.1
+        { 192.168.1/24;                            // THEN use .1, or .2 or .3
+            { 192.168.2/24; 192.168.3/24; }; }; };
+    { 192.168.2/24;                                // IF   on class C 192.168.2
+        { 192.168.2/24;                            // THEN use .2, or .1 or .3
+            { 192.168.1/24; 192.168.3/24; }; }; };
+    { 192.168.3/24;                                // IF   on class C 192.168.3
+        { 192.168.3/24;                            // THEN use .3, or .1 or .2
+            { 192.168.1/24; 192.168.2/24; }; }; };
+    { { 192.168.4/24; 192.168.5/24; };             // if .4 or .5, prefer that net
+    };
+};</pre>
+<p>
+            The following example will give reasonable behavior for the
+            local host and hosts on directly connected networks. It is similar
+            to the behavior of the address sort in <acronym class="acronym">BIND</acronym> 4.9.x. Responses sent
+            to queries from the local host will favor any of the directly
+            connected
+            networks. Responses sent to queries from any other hosts on a
+            directly
+            connected network will prefer addresses on that same network.
+            Responses
+            to other queries will not be sorted.
+          </p>
+<pre class="programlisting">sortlist {
+           { localhost; localnets; };
+           { localnets; };
+};
+</pre>
+</div>
+<div class="sect3" lang="en">
+<div class="titlepage"><div><div><h4 class="title">
+<a name="rrset_ordering"></a>RRset Ordering</h4></div></div></div>
+<p>
+            When multiple records are returned in an answer it may be
+            useful to configure the order of the records placed into the
+            response.
+            The <span><strong class="command">rrset-order</strong></span> statement permits
+            configuration
+            of the ordering of the records in a multiple record response.
+            See also the <span><strong class="command">sortlist</strong></span> statement,
+            <a href="Bv9ARM.ch06.html#the_sortlist_statement" title="The sortlist Statement">the section called &#8220;The <span><strong class="command">sortlist</strong></span> Statement&#8221;</a>.
+          </p>
+<p>
+            An <span><strong class="command">order_spec</strong></span> is defined as
+            follows:
+          </p>
+<p>
+            [<span class="optional">class <em class="replaceable"><code>class_name</code></em></span>]
+            [<span class="optional">type <em class="replaceable"><code>type_name</code></em></span>]
+            [<span class="optional">name <em class="replaceable"><code>"domain_name"</code></em></span>]
+            order <em class="replaceable"><code>ordering</code></em>
+          </p>
+<p>
+            If no class is specified, the default is <span><strong class="command">ANY</strong></span>.
+            If no type is specified, the default is <span><strong class="command">ANY</strong></span>.
+            If no name is specified, the default is "<span><strong class="command">*</strong></span>" (asterisk).
+          </p>
+<p>
+            The legal values for <span><strong class="command">ordering</strong></span> are:
+          </p>
+<div class="informaltable"><table border="1">
+<colgroup>
+<col>
+<col>
+</colgroup>
+<tbody>
+<tr>
+<td>
+                    <p><span><strong class="command">fixed</strong></span></p>
+                  </td>
+<td>
+                    <p>
+                      Records are returned in the order they
+                      are defined in the zone file.
+                    </p>
+                  </td>
+</tr>
+<tr>
+<td>
+                    <p><span><strong class="command">random</strong></span></p>
+                  </td>
+<td>
+                    <p>
+                      Records are returned in some random order.
+                    </p>
+                  </td>
+</tr>
+<tr>
+<td>
+                    <p><span><strong class="command">cyclic</strong></span></p>
+                  </td>
+<td>
+                    <p>
+                      Records are returned in a round-robin
+                      order.
+                    </p>
+                  </td>
+</tr>
+</tbody>
+</table></div>
+<p>
+            For example:
+          </p>
+<pre class="programlisting">rrset-order {
+   class IN type A name "host.example.com" order random;
+   order cyclic;
+};
+</pre>
+<p>
+            will cause any responses for type A records in class IN that
+            have "<code class="literal">host.example.com</code>" as a
+            suffix, to always be returned
+            in random order. All other records are returned in cyclic order.
+          </p>
+<p>
+            If multiple <span><strong class="command">rrset-order</strong></span> statements
+            appear,
+            they are not combined &#8212; the last one applies.
+          </p>
+<div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
+<h3 class="title">Note</h3>
+<p>
+              The <span><strong class="command">rrset-order</strong></span> statement
+              is not yet fully implemented in <acronym class="acronym">BIND</acronym> 9.
+              BIND 9 currently does not fully support "fixed" ordering.
+            </p>
+</div>
+</div>
+<div class="sect3" lang="en">
+<div class="titlepage"><div><div><h4 class="title">
+<a name="tuning"></a>Tuning</h4></div></div></div>
+<div class="variablelist"><dl>
+<dt><span class="term"><span><strong class="command">lame-ttl</strong></span></span></dt>
+<dd><p>
+                  Sets the number of seconds to cache a
+                  lame server indication. 0 disables caching. (This is
+                  <span class="bold"><strong>NOT</strong></span> recommended.)
+                  The default is <code class="literal">600</code> (10 minutes) and the
+                  maximum value is
+                  <code class="literal">1800</code> (30 minutes).
+                </p></dd>
+<dt><span class="term"><span><strong class="command">max-ncache-ttl</strong></span></span></dt>
+<dd><p>
+                  To reduce network traffic and increase performance,
+                  the server stores negative answers. <span><strong class="command">max-ncache-ttl</strong></span> is
+                  used to set a maximum retention time for these answers in
+                  the server
+                  in seconds. The default
+                  <span><strong class="command">max-ncache-ttl</strong></span> is <code class="literal">10800</code> seconds (3 hours).
+                  <span><strong class="command">max-ncache-ttl</strong></span> cannot exceed
+                  7 days and will
+                  be silently truncated to 7 days if set to a greater value.
+                </p></dd>
+<dt><span class="term"><span><strong class="command">max-cache-ttl</strong></span></span></dt>
+<dd><p>
+                  Sets the maximum time for which the server will
+                  cache ordinary (positive) answers. The default is
+                  one week (7 days).
+                </p></dd>
+<dt><span class="term"><span><strong class="command">min-roots</strong></span></span></dt>
+<dd>
+<p>
+                  The minimum number of root servers that
+                  is required for a request for the root servers to be
+                  accepted. The default
+                  is <strong class="userinput"><code>2</code></strong>.
+                </p>
+<div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
+<h3 class="title">Note</h3>
+<p>
+                    Not implemented in <acronym class="acronym">BIND</acronym> 9.
+                  </p>
+</div>
+</dd>
+<dt><span class="term"><span><strong class="command">sig-validity-interval</strong></span></span></dt>
+<dd><p>
+                  Specifies the number of days into the
+                  future when DNSSEC signatures automatically generated as a
+                  result
+                  of dynamic updates (<a href="Bv9ARM.ch04.html#dynamic_update" title="Dynamic Update">the section called &#8220;Dynamic Update&#8221;</a>)
+                  will expire. The default is <code class="literal">30</code> days.
+                  The maximum value is 10 years (3660 days). The signature
+                  inception time is unconditionally set to one hour before the
+                  current time
+                  to allow for a limited amount of clock skew.
+                </p></dd>
+<dt>
+<span class="term"><span><strong class="command">min-refresh-time</strong></span>, </span><span class="term"><span><strong class="command">max-refresh-time</strong></span>, </span><span class="term"><span><strong class="command">min-retry-time</strong></span>, </span><span class="term"><span><strong class="command">max-retry-time</strong></span></span>
+</dt>
+<dd>
+<p>
+                  These options control the server's behavior on refreshing a
+                  zone
+                  (querying for SOA changes) or retrying failed transfers.
+                  Usually the SOA values for the zone are used, but these
+                  values
+                  are set by the master, giving slave server administrators
+                  little
+                  control over their contents.
+                </p>
+<p>
+                  These options allow the administrator to set a minimum and
+                  maximum
+                  refresh and retry time either per-zone, per-view, or
+                  globally.
+                  These options are valid for slave and stub zones,
+                  and clamp the SOA refresh and retry times to the specified
+                  values.
+                </p>
+</dd>
+<dt><span class="term"><span><strong class="command">edns-udp-size</strong></span></span></dt>
+<dd><p>
+                  Sets the advertised EDNS UDP buffer size in bytes.  Valid
+                  values are 512 to 4096 (values outside this range
+                  will be silently adjusted).  The default value is
+                  4096.  The usual reason for setting edns-udp-size to
+                  a non-default value is to get UDP answers to pass
+                  through broken firewalls that block fragmented
+                  packets and/or block UDP packets that are greater
+                  than 512 bytes.
+                </p></dd>
+<dt><span class="term"><span><strong class="command">max-udp-size</strong></span></span></dt>
+<dd><p>
+                  Sets the maximum EDNS UDP message size named will
+                  send in bytes.  Valid values are 512 to 4096 (values outside
+                  this range will be silently adjusted).  The default
+                  value is 4096.  The usual reason for setting
+                  max-udp-size to a non-default value is to get UDP
+                  answers to pass through broken firewalls that
+                  block fragmented packets and/or block UDP packets
+                  that are greater than 512 bytes.
+                  This is independent of the advertised receive
+                  buffer (<span><strong class="command">edns-udp-size</strong></span>).
+                </p></dd>
+<dt><span class="term"><span><strong class="command">masterfile-format</strong></span></span></dt>
+<dd><p>Specifies
+                  the file format of zone files (see
+                  <a href="Bv9ARM.ch06.html#zonefile_format" title="Additional File Formats">the section called &#8220;Additional File Formats&#8221;</a>).
+                  The default value is <code class="constant">text</code>, which is the
+                  standard textual representation.  Files in other formats
+                  than <code class="constant">text</code> are typically expected
+                  to be generated by the <span><strong class="command">named-compilezone</strong></span> tool.
+                  Note that when a zone file in a different format than
+                  <code class="constant">text</code> is loaded, <span><strong class="command">named</strong></span>
+                  may omit some of the checks which would be performed for a
+                  file in the <code class="constant">text</code> format.  In particular,
+                  <span><strong class="command">check-names</strong></span> checks do not apply
+                  for the <code class="constant">raw</code> format.  This means
+                  a zone file in the <code class="constant">raw</code> format
+                  must be generated with the same check level as that
+                  specified in the <span><strong class="command">named</strong></span> configuration
+                  file.  This statement sets the
+                  <span><strong class="command">masterfile-format</strong></span> for all zones,
+                  but can be overridden on a per-zone or per-view basis
+                  by including a <span><strong class="command">masterfile-format</strong></span>
+                  statement within the <span><strong class="command">zone</strong></span> or
+                  <span><strong class="command">view</strong></span> block in the configuration
+                  file.
+                </p></dd>
+<dt>
+<span class="term"><span><strong class="command">clients-per-query</strong></span>, </span><span class="term"><span><strong class="command">max-clients-per-query</strong></span></span>
+</dt>
+<dd>
+<p>These set the
+                  initial value (minimum) and maximum number of recursive
+                  simultanious clients for any given query
+                  (&lt;qname,qtype,qclass&gt;) that the server will accept
+                  before dropping additional clients.  named will attempt to
+                  self tune this value and changes will be logged.  The
+                  default values are 10 and 100.
+                </p>
+<p>
+                  This value should reflect how many queries come in for
+                  a given name in the time it takes to resolve that name.
+                  If the number of queries exceed this value, named will
+                  assume that it is dealing with a non-responsive zone
+                  and will drop additional queries.  If it gets a response
+                  after dropping queries, it will raise the estimate.  The
+                  estimate will then be lowered in 20 minutes if it has
+                  remained unchanged.
+                </p>
+<p>
+                  If <span><strong class="command">clients-per-query</strong></span> is set to zero,
+                  then there is no limit on the number of clients per query
+                  and no queries will be dropped.
+                </p>
+<p>
+                  If <span><strong class="command">max-clients-per-query</strong></span> is set to zero,
+                  then there is no upper bound other than imposed by
+                  <span><strong class="command">recursive-clients</strong></span>.
+                </p>
+</dd>
+<dt><span class="term"><span><strong class="command">notify-delay</strong></span></span></dt>
+<dd><p>
+                  The delay, in seconds, between sending sets of notify
+                  messages for a zone.  The default is zero.
+                </p></dd>
+</dl></div>
+</div>
+<div class="sect3" lang="en">
+<div class="titlepage"><div><div><h4 class="title">
+<a name="builtin"></a>Built-in server information zones</h4></div></div></div>
+<p>
+            The server provides some helpful diagnostic information
+            through a number of built-in zones under the
+            pseudo-top-level-domain <code class="literal">bind</code> in the
+            <span><strong class="command">CHAOS</strong></span> class.  These zones are part
+            of a
+            built-in view (see <a href="Bv9ARM.ch06.html#view_statement_grammar" title="view Statement Grammar">the section called &#8220;<span><strong class="command">view</strong></span> Statement Grammar&#8221;</a>) of
+            class
+            <span><strong class="command">CHAOS</strong></span> which is separate from the
+            default view of
+            class <span><strong class="command">IN</strong></span>; therefore, any global
+            server options
+            such as <span><strong class="command">allow-query</strong></span> do not apply
+            the these zones.
+            If you feel the need to disable these zones, use the options
+            below, or hide the built-in <span><strong class="command">CHAOS</strong></span>
+            view by
+            defining an explicit view of class <span><strong class="command">CHAOS</strong></span>
+            that matches all clients.
+          </p>
+<div class="variablelist"><dl>
+<dt><span class="term"><span><strong class="command">version</strong></span></span></dt>
+<dd><p>
+                  The version the server should report
+                  via a query of the name <code class="literal">version.bind</code>
+                  with type <span><strong class="command">TXT</strong></span>, class <span><strong class="command">CHAOS</strong></span>.
+                  The default is the real version number of this server.
+                  Specifying <span><strong class="command">version none</strong></span>
+                  disables processing of the queries.
+                </p></dd>
+<dt><span class="term"><span><strong class="command">hostname</strong></span></span></dt>
+<dd><p>
+                  The hostname the server should report via a query of
+                  the name <code class="filename">hostname.bind</code>
+                  with type <span><strong class="command">TXT</strong></span>, class <span><strong class="command">CHAOS</strong></span>.
+                  This defaults to the hostname of the machine hosting the
+                  name server as
+                  found by the gethostname() function.  The primary purpose of such queries
+                  is to
+                  identify which of a group of anycast servers is actually
+                  answering your queries.  Specifying <span><strong class="command">hostname none;</strong></span>
+                  disables processing of the queries.
+                </p></dd>
+<dt><span class="term"><span><strong class="command">server-id</strong></span></span></dt>
+<dd><p>
+                  The ID of the server should report via a query of
+                  the name <code class="filename">ID.SERVER</code>
+                  with type <span><strong class="command">TXT</strong></span>, class <span><strong class="command">CHAOS</strong></span>.
+                  The primary purpose of such queries is to
+                  identify which of a group of anycast servers is actually
+                  answering your queries.  Specifying <span><strong class="command">server-id none;</strong></span>
+                  disables processing of the queries.
+                  Specifying <span><strong class="command">server-id hostname;</strong></span> will cause named to
+                  use the hostname as found by the gethostname() function.
+                  The default <span><strong class="command">server-id</strong></span> is <span><strong class="command">none</strong></span>.
+                </p></dd>
+</dl></div>
+</div>
+<div class="sect3" lang="en">
+<div class="titlepage"><div><div><h4 class="title">
+<a name="empty"></a>Built-in Empty Zones</h4></div></div></div>
+<p>
+            Named has some built-in empty zones (SOA and NS records only).
+            These are for zones that should normally be answered locally
+            and which queries should not be sent to the Internet's root
+            servers.  The official servers which cover these namespaces
+            return NXDOMAIN responses to these queries.  In particular,
+            these cover the reverse namespace for addresses from RFC 1918 and
+            RFC 3330.  They also include the reverse namespace for IPv6 local
+            address (locally assigned), IPv6 link local addresses, the IPv6
+            loopback address and the IPv6 unknown addresss.
+          </p>
+<p>
+            Named will attempt to determine if a built in zone already exists
+            or is active (covered by a forward-only forwarding declaration)
+            and will not not create a empty zone in that case.
+          </p>
+<p>
+            The current list of empty zones is:
+            </p>
+<div class="itemizedlist"><ul type="disc">
+<li>10.IN-ADDR.ARPA</li>
+<li>127.IN-ADDR.ARPA</li>
+<li>254.169.IN-ADDR.ARPA</li>
+<li>16.172.IN-ADDR.ARPA</li>
+<li>17.172.IN-ADDR.ARPA</li>
+<li>18.172.IN-ADDR.ARPA</li>
+<li>19.172.IN-ADDR.ARPA</li>
+<li>20.172.IN-ADDR.ARPA</li>
+<li>21.172.IN-ADDR.ARPA</li>
+<li>22.172.IN-ADDR.ARPA</li>
+<li>23.172.IN-ADDR.ARPA</li>
+<li>24.172.IN-ADDR.ARPA</li>
+<li>25.172.IN-ADDR.ARPA</li>
+<li>26.172.IN-ADDR.ARPA</li>
+<li>27.172.IN-ADDR.ARPA</li>
+<li>28.172.IN-ADDR.ARPA</li>
+<li>29.172.IN-ADDR.ARPA</li>
+<li>30.172.IN-ADDR.ARPA</li>
+<li>31.172.IN-ADDR.ARPA</li>
+<li>168.192.IN-ADDR.ARPA</li>
+<li>2.0.192.IN-ADDR.ARPA</li>
+<li>0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA</li>
+<li>1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA</li>
+<li>D.F.IP6.ARPA</li>
+<li>8.E.F.IP6.ARPA</li>
+<li>9.E.F.IP6.ARPA</li>
+<li>A.E.F.IP6.ARPA</li>
+<li>B.E.F.IP6.ARPA</li>
+</ul></div>
+<p>
+          </p>
+<p>
+            Empty zones are settable at the view level and only apply to
+            views of class IN.  Disabled empty zones are only inherited
+            from options if there are no disabled empty zones specified
+            at the view level.  To override the options list of disabled
+            zones, you can disable the root zone at the view level, for example:
+</p>
+<pre class="programlisting">
+            disable-empty-zone ".";
+</pre>
+<p>
+          </p>
+<p>
+            If you are using the address ranges covered here, you should
+            already have reverse zones covering the addresses you use.
+            In practice this appears to not be the case with many queries
+            being made to the infrastructure servers for names in these
+            spaces.  So many in fact that sacrificial servers were needed
+            to be deployed to channel the query load away from the
+            infrastructure servers.
+          </p>
+<div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
+<h3 class="title">Note</h3>
+            The real parent servers for these zones should disable all
+            empty zone under the parent zone they serve.  For the real
+            root servers, this is all built in empty zones.  This will
+            enable them to return referrals to deeper in the tree.
+          </div>
+<div class="variablelist"><dl>
+<dt><span class="term"><span><strong class="command">empty-server</strong></span></span></dt>
+<dd><p>
+                  Specify what server name will appear in the returned
+                  SOA record for empty zones.  If none is specified, then
+                  the zone's name will be used.
+                </p></dd>
+<dt><span class="term"><span><strong class="command">empty-contact</strong></span></span></dt>
+<dd><p>
+                  Specify what contact name will appear in the returned
+                  SOA record for empty zones.  If none is specified, then
+                  "." will be used.
+                </p></dd>
+<dt><span class="term"><span><strong class="command">empty-zones-enable</strong></span></span></dt>
+<dd><p>
+                  Enable or disable all empty zones.  By default they
+                  are enabled.
+                </p></dd>
+<dt><span class="term"><span><strong class="command">disable-empty-zone</strong></span></span></dt>
+<dd><p>
+                  Disable individual empty zones.  By default none are
+                  disabled.  This option can be specified multiple times.
+                </p></dd>
+</dl></div>
+</div>
+<div class="sect3" lang="en">
+<div class="titlepage"><div><div><h4 class="title">
+<a name="statsfile"></a>The Statistics File</h4></div></div></div>
+<p>
+            The statistics file generated by <acronym class="acronym">BIND</acronym> 9
+            is similar, but not identical, to that
+            generated by <acronym class="acronym">BIND</acronym> 8.
+          </p>
+<p>
+            The statistics dump begins with a line, like:
+          </p>
+<p>
+            <span><strong class="command">+++ Statistics Dump +++ (973798949)</strong></span>
+          </p>
+<p>
+            The number in parentheses is a standard
+            Unix-style timestamp, measured as seconds since January 1, 1970.
+            Following
+            that line are a series of lines containing a counter type, the
+            value of the
+            counter, optionally a zone name, and optionally a view name.
+            The lines without view and zone listed are global statistics for
+            the entire server.
+            Lines with a zone and view name for the given view and zone (the
+            view name is
+            omitted for the default view).
+          </p>
+<p>
+            The statistics dump ends with the line where the
+            number is identical to the number in the beginning line; for example:
+          </p>
+<p>
+            <span><strong class="command">--- Statistics Dump --- (973798949)</strong></span>
+          </p>
+<p>
+            The following statistics counters are maintained:
+          </p>
+<div class="informaltable"><table border="1">
+<colgroup>
+<col>
+<col>
+</colgroup>
+<tbody>
+<tr>
+<td>
+                    <p><span><strong class="command">success</strong></span></p>
+                  </td>
+<td>
+                    <p>
+                      The number of
+                      successful queries made to the server or zone.  A
+                      successful query
+                      is defined as query which returns a NOERROR response
+                      with at least
+                      one answer RR.
+                    </p>
+                  </td>
+</tr>
+<tr>
+<td>
+                    <p><span><strong class="command">referral</strong></span></p>
+                  </td>
+<td>
+                    <p>
+                      The number of queries which resulted
+                      in referral responses.
+                    </p>
+                  </td>
+</tr>
+<tr>
+<td>
+                    <p><span><strong class="command">nxrrset</strong></span></p>
+                  </td>
+<td>
+                    <p>
+                      The number of queries which resulted in
+                      NOERROR responses with no data.
+                    </p>
+                  </td>
+</tr>
+<tr>
+<td>
+                    <p><span><strong class="command">nxdomain</strong></span></p>
+                  </td>
+<td>
+                    <p>
+                      The number
+                      of queries which resulted in NXDOMAIN responses.
+                    </p>
+                  </td>
+</tr>
+<tr>
+<td>
+                    <p><span><strong class="command">failure</strong></span></p>
+                  </td>
+<td>
+                    <p>
+                      The number of queries which resulted in a
+                      failure response other than those above.
+                    </p>
+                  </td>
+</tr>
+<tr>
+<td>
+                    <p><span><strong class="command">recursion</strong></span></p>
+                  </td>
+<td>
+                    <p>
+                      The number of queries which caused the server
+                      to perform recursion in order to find the final answer.
+                    </p>
+                  </td>
+</tr>
+<tr>
+<td>
+                    <p><span><strong class="command">duplicate</strong></span></p>
+                  </td>
+<td>
+                    <p>
+                      The number of queries which the server attempted to
+                      recurse but discover a existing query with the same
+                      IP address, port, query id, name, type and class
+                      already being processed.
+                    </p>
+                  </td>
+</tr>
+<tr>
+<td>
+                    <p><span><strong class="command">dropped</strong></span></p>
+                  </td>
+<td>
+                    <p>
+                      The number of queries for which the server
+                      discovered a excessive number of existing
+                      recursive queries for the same name, type and
+                      class and were subsequently dropped.
+                    </p>
+                  </td>
+</tr>
+</tbody>
+</table></div>
+<p>
+            Each query received by the server will cause exactly one of
+            <span><strong class="command">success</strong></span>,
+            <span><strong class="command">referral</strong></span>,
+            <span><strong class="command">nxrrset</strong></span>,
+            <span><strong class="command">nxdomain</strong></span>, or
+            <span><strong class="command">failure</strong></span>
+            to be incremented, and may additionally cause the
+            <span><strong class="command">recursion</strong></span> counter to be
+            incremented.
+          </p>
+</div>
+<div class="sect3" lang="en">
+<div class="titlepage"><div><div><h4 class="title">
+<a name="acache"></a>Additional Section Caching</h4></div></div></div>
+<p>
+            The additional section cache, also called <span><strong class="command">acache</strong></span>,
+            is an internal cache to improve the response performance of BIND 9.
+            When additional section caching is enabled, BIND 9 will
+            cache an internal short-cut to the additional section content for
+            each answer RR.
+            Note that <span><strong class="command">acache</strong></span> is an internal caching
+            mechanism of BIND 9, and is not related to the DNS caching
+            server function.
+          </p>
+<p>
+            Additional section caching does not change the
+            response content (except the RRsets ordering of the additional
+            section, see below), but can improve the response performance
+            significantly.
+            It is particularly effective when BIND 9 acts as an authoritative
+            server for a zone that has many delegations with many glue RRs.
+          </p>
+<p>
+            In order to obtain the maximum performance improvement
+            from additional section caching, setting
+            <span><strong class="command">additional-from-cache</strong></span>
+            to <span><strong class="command">no</strong></span> is recommended, since the current
+            implementation of <span><strong class="command">acache</strong></span>
+            does not short-cut of additional section information from the
+            DNS cache data.
+          </p>
+<p>
+            One obvious disadvantage of <span><strong class="command">acache</strong></span> is
+            that it requires much more
+            memory for the internal cached data.
+            Thus, if the response performance does not matter and memory
+            consumption is much more critical, the
+            <span><strong class="command">acache</strong></span> mechanism can be
+            disabled by setting <span><strong class="command">acache-enable</strong></span> to
+            <span><strong class="command">no</strong></span>.
+            It is also possible to specify the upper limit of memory
+            consumption
+            for acache by using <span><strong class="command">max-acache-size</strong></span>.
+          </p>
+<p>
+            Additional section caching also has a minor effect on the
+            RRset ordering in the additional section.
+            Without <span><strong class="command">acache</strong></span>,
+            <span><strong class="command">cyclic</strong></span> order is effective for the additional
+            section as well as the answer and authority sections.
+            However, additional section caching fixes the ordering when it
+            first caches an RRset for the additional section, and the same
+            ordering will be kept in succeeding responses, regardless of the
+            setting of <span><strong class="command">rrset-order</strong></span>.
+            The effect of this should be minor, however, since an
+            RRset in the additional section
+            typically only contains a small number of RRs (and in many cases
+            it only contains a single RR), in which case the
+            ordering does not matter much.
+          </p>
+<p>
+            The following is a summary of options related to
+            <span><strong class="command">acache</strong></span>.
+          </p>
+<div class="variablelist"><dl>
+<dt><span class="term"><span><strong class="command">acache-enable</strong></span></span></dt>
+<dd><p>
+                  If <span><strong class="command">yes</strong></span>, additional section caching is
+                  enabled.  The default value is <span><strong class="command">no</strong></span>.
+                </p></dd>
+<dt><span class="term"><span><strong class="command">acache-cleaning-interval</strong></span></span></dt>
+<dd><p>
+                  The server will remove stale cache entries, based on an LRU
+                  based
+                  algorithm, every <span><strong class="command">acache-cleaning-interval</strong></span> minutes.
+                  The default is 60 minutes.
+                  If set to 0, no periodic cleaning will occur.
+                </p></dd>
+<dt><span class="term"><span><strong class="command">max-acache-size</strong></span></span></dt>
+<dd><p>
+                  The maximum amount of memory in bytes to use for the server's acache.
+                  When the amount of data in the acache reaches this limit,
+                  the server
+                  will clean more aggressively so that the limit is not
+                  exceeded.
+                  In a server with multiple views, the limit applies
+                  separately to the
+                  acache of each view.
+                  The default is <code class="literal">unlimited</code>,
+                  meaning that
+                  entries are purged from the acache only at the
+                  periodic cleaning time.
+                </p></dd>
+</dl></div>
+</div>
+</div>
+<div class="sect2" lang="en">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="server_statement_grammar"></a><span><strong class="command">server</strong></span> Statement Grammar</h3></div></div></div>
+<pre class="programlisting">server <em class="replaceable"><code>ip_addr[/prefixlen]</code></em> {
+    [<span class="optional"> bogus <em class="replaceable"><code>yes_or_no</code></em> ; </span>]
+    [<span class="optional"> provide-ixfr <em class="replaceable"><code>yes_or_no</code></em> ; </span>]
+    [<span class="optional"> request-ixfr <em class="replaceable"><code>yes_or_no</code></em> ; </span>]
+    [<span class="optional"> edns <em class="replaceable"><code>yes_or_no</code></em> ; </span>]
+    [<span class="optional"> edns-udp-size <em class="replaceable"><code>number</code></em> ; </span>]
+    [<span class="optional"> max-udp-size <em class="replaceable"><code>number</code></em> ; </span>]
+    [<span class="optional"> transfers <em class="replaceable"><code>number</code></em> ; </span>]
+    [<span class="optional"> transfer-format <em class="replaceable"><code>( one-answer | many-answers )</code></em> ; ]</span>]
+    [<span class="optional"> keys <em class="replaceable"><code>{ string ; [<span class="optional"> string ; [<span class="optional">...</span>]</span>] }</code></em> ; </span>]
+    [<span class="optional"> transfer-source (<em class="replaceable"><code>ip4_addr</code></em> | <code class="constant">*</code>) [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] ; </span>]
+    [<span class="optional"> transfer-source-v6 (<em class="replaceable"><code>ip6_addr</code></em> | <code class="constant">*</code>) [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] ; </span>]
+    [<span class="optional"> notify-source (<em class="replaceable"><code>ip4_addr</code></em> | <code class="constant">*</code>) [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] ; </span>]
+    [<span class="optional"> notify-source-v6 (<em class="replaceable"><code>ip6_addr</code></em> | <code class="constant">*</code>) [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] ; </span>]
+    [<span class="optional"> query-source [<span class="optional"> address ( <em class="replaceable"><code>ip_addr</code></em> | <em class="replaceable"><code>*</code></em> ) </span>] [<span class="optional"> port ( <em class="replaceable"><code>ip_port</code></em> | <em class="replaceable"><code>*</code></em> ) </span>]; </span>]
+    [<span class="optional"> query-source-v6 [<span class="optional"> address ( <em class="replaceable"><code>ip_addr</code></em> | <em class="replaceable"><code>*</code></em> ) </span>] [<span class="optional"> port ( <em class="replaceable"><code>ip_port</code></em> | <em class="replaceable"><code>*</code></em> ) </span>]; </span>]
+};
+</pre>
+</div>
+<div class="sect2" lang="en">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="server_statement_definition_and_usage"></a><span><strong class="command">server</strong></span> Statement Definition and
+            Usage</h3></div></div></div>
+<p>
+            The <span><strong class="command">server</strong></span> statement defines
+            characteristics
+            to be associated with a remote name server.  If a prefix length is
+            specified, then a range of servers is covered.  Only the most
+            specific
+            server clause applies regardless of the order in
+            <code class="filename">named.conf</code>.
+          </p>
+<p>
+            The <span><strong class="command">server</strong></span> statement can occur at
+            the top level of the
+            configuration file or inside a <span><strong class="command">view</strong></span>
+            statement.
+            If a <span><strong class="command">view</strong></span> statement contains
+            one or more <span><strong class="command">server</strong></span> statements, only
+            those
+            apply to the view and any top-level ones are ignored.
+            If a view contains no <span><strong class="command">server</strong></span>
+            statements,
+            any top-level <span><strong class="command">server</strong></span> statements are
+            used as
+            defaults.
+          </p>
+<p>
+            If you discover that a remote server is giving out bad data,
+            marking it as bogus will prevent further queries to it. The
+            default
+            value of <span><strong class="command">bogus</strong></span> is <span><strong class="command">no</strong></span>.
+          </p>
+<p>
+            The <span><strong class="command">provide-ixfr</strong></span> clause determines
+            whether
+            the local server, acting as master, will respond with an
+            incremental
+            zone transfer when the given remote server, a slave, requests it.
+            If set to <span><strong class="command">yes</strong></span>, incremental transfer
+            will be provided
+            whenever possible. If set to <span><strong class="command">no</strong></span>,
+            all transfers
+            to the remote server will be non-incremental. If not set, the
+            value
+            of the <span><strong class="command">provide-ixfr</strong></span> option in the
+            view or
+            global options block is used as a default.
+          </p>
+<p>
+            The <span><strong class="command">request-ixfr</strong></span> clause determines
+            whether
+            the local server, acting as a slave, will request incremental zone
+            transfers from the given remote server, a master. If not set, the
+            value of the <span><strong class="command">request-ixfr</strong></span> option in
+            the view or
+            global options block is used as a default.
+          </p>
+<p>
+            IXFR requests to servers that do not support IXFR will
+            automatically
+            fall back to AXFR.  Therefore, there is no need to manually list
+            which servers support IXFR and which ones do not; the global
+            default
+            of <span><strong class="command">yes</strong></span> should always work.
+            The purpose of the <span><strong class="command">provide-ixfr</strong></span> and
+            <span><strong class="command">request-ixfr</strong></span> clauses is
+            to make it possible to disable the use of IXFR even when both
+            master
+            and slave claim to support it, for example if one of the servers
+            is buggy and crashes or corrupts data when IXFR is used.
+          </p>
+<p>
+            The <span><strong class="command">edns</strong></span> clause determines whether
+            the local server will attempt to use EDNS when communicating
+            with the remote server.  The default is <span><strong class="command">yes</strong></span>.
+          </p>
+<p>
+            The <span><strong class="command">edns-udp-size</strong></span> option sets the EDNS UDP size
+            that is advertised by named when querying the remote server.
+            Valid values are 512 to 4096 bytes (values outside this range will be
+            silently adjusted).  This option is useful when you wish to
+            advertises a different value to this server than the value you
+            advertise globally, for example, when there is a firewall at the
+            remote site that is blocking large replies.
+          </p>
+<p>
+            The <span><strong class="command">max-udp-size</strong></span> option sets the
+            maximum EDNS UDP message size named will send.  Valid
+            values are 512 to 4096 bytes (values outside this range will
+            be silently adjusted).  This option is useful when you
+            know that there is a firewall that is blocking large
+            replies from named.
+          </p>
+<p>
+            The server supports two zone transfer methods. The first, <span><strong class="command">one-answer</strong></span>,
+            uses one DNS message per resource record transferred. <span><strong class="command">many-answers</strong></span> packs
+            as many resource records as possible into a message. <span><strong class="command">many-answers</strong></span> is
+            more efficient, but is only known to be understood by <acronym class="acronym">BIND</acronym> 9, <acronym class="acronym">BIND</acronym>
+            8.x, and patched versions of <acronym class="acronym">BIND</acronym>
+            4.9.5. You can specify which method
+            to use for a server with the <span><strong class="command">transfer-format</strong></span> option.
+            If <span><strong class="command">transfer-format</strong></span> is not
+            specified, the <span><strong class="command">transfer-format</strong></span>
+            specified
+            by the <span><strong class="command">options</strong></span> statement will be
+            used.
+          </p>
+<p><span><strong class="command">transfers</strong></span>
+            is used to limit the number of concurrent inbound zone
+            transfers from the specified server. If no
+            <span><strong class="command">transfers</strong></span> clause is specified, the
+            limit is set according to the
+            <span><strong class="command">transfers-per-ns</strong></span> option.
+          </p>
+<p>
+            The <span><strong class="command">keys</strong></span> clause identifies a
+            <span><strong class="command">key_id</strong></span> defined by the <span><strong class="command">key</strong></span> statement,
+            to be used for transaction security (TSIG, <a href="Bv9ARM.ch04.html#tsig" title="TSIG">the section called &#8220;TSIG&#8221;</a>)
+            when talking to the remote server.
+            When a request is sent to the remote server, a request signature
+            will be generated using the key specified here and appended to the
+            message. A request originating from the remote server is not
+            required
+            to be signed by this key.
+          </p>
+<p>
+            Although the grammar of the <span><strong class="command">keys</strong></span>
+            clause
+            allows for multiple keys, only a single key per server is
+            currently
+            supported.
+          </p>
+<p>
+            The <span><strong class="command">transfer-source</strong></span> and
+            <span><strong class="command">transfer-source-v6</strong></span> clauses specify
+            the IPv4 and IPv6 source
+            address to be used for zone transfer with the remote server,
+            respectively.
+            For an IPv4 remote server, only <span><strong class="command">transfer-source</strong></span> can
+            be specified.
+            Similarly, for an IPv6 remote server, only
+            <span><strong class="command">transfer-source-v6</strong></span> can be
+            specified.
+            For more details, see the description of
+            <span><strong class="command">transfer-source</strong></span> and
+            <span><strong class="command">transfer-source-v6</strong></span> in
+            <a href="Bv9ARM.ch06.html#zone_transfers" title="Zone Transfers">the section called &#8220;Zone Transfers&#8221;</a>.
+          </p>
+<p>
+            The <span><strong class="command">notify-source</strong></span> and
+            <span><strong class="command">notify-source-v6</strong></span> clauses specify the
+            IPv4 and IPv6 source address to be used for notify
+            messages sent to remote servers, respectively.  For an
+            IPv4 remote server, only <span><strong class="command">notify-source</strong></span>
+            can be specified.  Similarly, for an IPv6 remote server,
+            only <span><strong class="command">notify-source-v6</strong></span> can be specified.
+          </p>
+<p>
+            The <span><strong class="command">query-source</strong></span> and
+            <span><strong class="command">query-source-v6</strong></span> clauses specify the
+            IPv4 and IPv6 source address to be used for queries
+            sent to remote servers, respectively.  For an IPv4
+            remote server, only <span><strong class="command">query-source</strong></span> can
+            be specified.  Similarly, for an IPv6 remote server,
+            only <span><strong class="command">query-source-v6</strong></span> can be specified.
+          </p>
+</div>
+<div class="sect2" lang="en">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="id2585361"></a><span><strong class="command">trusted-keys</strong></span> Statement Grammar</h3></div></div></div>
+<pre class="programlisting">trusted-keys {
+    <em class="replaceable"><code>string</code></em> <em class="replaceable"><code>number</code></em> <em class="replaceable"><code>number</code></em> <em class="replaceable"><code>number</code></em> <em class="replaceable"><code>string</code></em> ;
+    [<span class="optional"> <em class="replaceable"><code>string</code></em> <em class="replaceable"><code>number</code></em> <em class="replaceable"><code>number</code></em> <em class="replaceable"><code>number</code></em> <em class="replaceable"><code>string</code></em> ; [<span class="optional">...</span>]</span>]
+};
+</pre>
+</div>
+<div class="sect2" lang="en">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="id2585410"></a><span><strong class="command">trusted-keys</strong></span> Statement Definition
+            and Usage</h3></div></div></div>
+<p>
+            The <span><strong class="command">trusted-keys</strong></span> statement defines
+            DNSSEC security roots. DNSSEC is described in <a href="Bv9ARM.ch04.html#DNSSEC" title="DNSSEC">the section called &#8220;DNSSEC&#8221;</a>. A security root is defined when the
+            public key for a non-authoritative zone is known, but
+            cannot be securely obtained through DNS, either because
+            it is the DNS root zone or because its parent zone is
+            unsigned.  Once a key has been configured as a trusted
+            key, it is treated as if it had been validated and
+            proven secure. The resolver attempts DNSSEC validation
+            on all DNS data in subdomains of a security root.
+          </p>
+<p>
+            All keys (and corresponding zones) listed in
+            <span><strong class="command">trusted-keys</strong></span> are deemed to exist regardless
+            of what parent zones say.  Similarly for all keys listed in
+            <span><strong class="command">trusted-keys</strong></span> only those keys are
+            used to validate the DNSKEY RRset.  The parent's DS RRset
+            will not be used.
+          </p>
+<p>
+            The <span><strong class="command">trusted-keys</strong></span> statement can contain
+            multiple key entries, each consisting of the key's
+            domain name, flags, protocol, algorithm, and the Base-64
+            representation of the key data.
+          </p>
+</div>
+<div class="sect2" lang="en">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="view_statement_grammar"></a><span><strong class="command">view</strong></span> Statement Grammar</h3></div></div></div>
+<pre class="programlisting">view <em class="replaceable"><code>view_name</code></em>
+      [<span class="optional"><em class="replaceable"><code>class</code></em></span>] {
+      match-clients { <em class="replaceable"><code>address_match_list</code></em> };
+      match-destinations { <em class="replaceable"><code>address_match_list</code></em> };
+      match-recursive-only <em class="replaceable"><code>yes_or_no</code></em> ;
+      [<span class="optional"> <em class="replaceable"><code>view_option</code></em>; ...</span>]
+      [<span class="optional"> <em class="replaceable"><code>zone_statement</code></em>; ...</span>]
+};
+</pre>
+</div>
+<div class="sect2" lang="en">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="id2585490"></a><span><strong class="command">view</strong></span> Statement Definition and Usage</h3></div></div></div>
+<p>
+            The <span><strong class="command">view</strong></span> statement is a powerful
+            feature
+            of <acronym class="acronym">BIND</acronym> 9 that lets a name server
+            answer a DNS query differently
+            depending on who is asking. It is particularly useful for
+            implementing
+            split DNS setups without having to run multiple servers.
+          </p>
+<p>
+            Each <span><strong class="command">view</strong></span> statement defines a view
+            of the
+            DNS namespace that will be seen by a subset of clients.  A client
+            matches
+            a view if its source IP address matches the
+            <code class="varname">address_match_list</code> of the view's
+            <span><strong class="command">match-clients</strong></span> clause and its
+            destination IP address matches
+            the <code class="varname">address_match_list</code> of the
+            view's
+            <span><strong class="command">match-destinations</strong></span> clause.  If not
+            specified, both
+            <span><strong class="command">match-clients</strong></span> and <span><strong class="command">match-destinations</strong></span>
+            default to matching all addresses.  In addition to checking IP
+            addresses
+            <span><strong class="command">match-clients</strong></span> and <span><strong class="command">match-destinations</strong></span>
+            can also take <span><strong class="command">keys</strong></span> which provide an
+            mechanism for the
+            client to select the view.  A view can also be specified
+            as <span><strong class="command">match-recursive-only</strong></span>, which
+            means that only recursive
+            requests from matching clients will match that view.
+            The order of the <span><strong class="command">view</strong></span> statements is
+            significant &#8212;
+            a client request will be resolved in the context of the first
+            <span><strong class="command">view</strong></span> that it matches.
+          </p>
+<p>
+            Zones defined within a <span><strong class="command">view</strong></span>
+            statement will
+            be only be accessible to clients that match the <span><strong class="command">view</strong></span>.
+            By defining a zone of the same name in multiple views, different
+            zone data can be given to different clients, for example,
+            "internal"
+            and "external" clients in a split DNS setup.
+          </p>
+<p>
+            Many of the options given in the <span><strong class="command">options</strong></span> statement
+            can also be used within a <span><strong class="command">view</strong></span>
+            statement, and then
+            apply only when resolving queries with that view.  When no
+            view-specific
+            value is given, the value in the <span><strong class="command">options</strong></span> statement
+            is used as a default.  Also, zone options can have default values
+            specified
+            in the <span><strong class="command">view</strong></span> statement; these
+            view-specific defaults
+            take precedence over those in the <span><strong class="command">options</strong></span> statement.
+          </p>
+<p>
+            Views are class specific.  If no class is given, class IN
+            is assumed.  Note that all non-IN views must contain a hint zone,
+            since only the IN class has compiled-in default hints.
+          </p>
+<p>
+            If there are no <span><strong class="command">view</strong></span> statements in
+            the config
+            file, a default view that matches any client is automatically
+            created
+            in class IN. Any <span><strong class="command">zone</strong></span> statements
+            specified on
+            the top level of the configuration file are considered to be part
+            of
+            this default view, and the <span><strong class="command">options</strong></span>
+            statement will
+            apply to the default view. If any explicit <span><strong class="command">view</strong></span>
+            statements are present, all <span><strong class="command">zone</strong></span>
+            statements must
+            occur inside <span><strong class="command">view</strong></span> statements.
+          </p>
+<p>
+            Here is an example of a typical split DNS setup implemented
+            using <span><strong class="command">view</strong></span> statements:
+          </p>
+<pre class="programlisting">view "internal" {
+      // This should match our internal networks.
+      match-clients { 10.0.0.0/8; };
+
+      // Provide recursive service to internal clients only.
+      recursion yes;
+
+      // Provide a complete view of the example.com zone
+      // including addresses of internal hosts.
+      zone "example.com" {
+            type master;
+            file "example-internal.db";
+      };
+};
+
+view "external" {
+      // Match all clients not matched by the previous view.
+      match-clients { any; };
+
+      // Refuse recursive service to external clients.
+      recursion no;
+
+      // Provide a restricted view of the example.com zone
+      // containing only publicly accessible hosts.
+      zone "example.com" {
+           type master;
+           file "example-external.db";
+      };
+};
+</pre>
+</div>
+<div class="sect2" lang="en">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="zone_statement_grammar"></a><span><strong class="command">zone</strong></span>
+            Statement Grammar</h3></div></div></div>
+<pre class="programlisting">zone <em class="replaceable"><code>zone_name</code></em> [<span class="optional"><em class="replaceable"><code>class</code></em></span>] {
+    type master;
+    [<span class="optional"> allow-query { <em class="replaceable"><code>address_match_list</code></em> }; </span>]
+    [<span class="optional"> allow-transfer { <em class="replaceable"><code>address_match_list</code></em> }; </span>]
+    [<span class="optional"> allow-update { <em class="replaceable"><code>address_match_list</code></em> }; </span>]
+    [<span class="optional"> update-policy { <em class="replaceable"><code>update_policy_rule</code></em> [<span class="optional">...</span>] }; </span>]
+    [<span class="optional"> also-notify { <em class="replaceable"><code>ip_addr</code></em> [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] ; [<span class="optional"> <em class="replaceable"><code>ip_addr</code></em> [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] ; ... </span>] }; </span>]
+    [<span class="optional"> check-names (<code class="constant">warn</code>|<code class="constant">fail</code>|<code class="constant">ignore</code>) ; </span>]
+    [<span class="optional"> check-mx (<code class="constant">warn</code>|<code class="constant">fail</code>|<code class="constant">ignore</code>) ; </span>]
+    [<span class="optional"> check-wildcard <em class="replaceable"><code>yes_or_no</code></em>; </span>]
+    [<span class="optional"> check-integrity <em class="replaceable"><code>yes_or_no</code></em> ; </span>]
+    [<span class="optional"> dialup <em class="replaceable"><code>dialup_option</code></em> ; </span>]
+    [<span class="optional"> file <em class="replaceable"><code>string</code></em> ; </span>]
+    [<span class="optional"> masterfile-format (<code class="constant">text</code>|<code class="constant">raw</code>) ; </span>]
+    [<span class="optional"> journal <em class="replaceable"><code>string</code></em> ; </span>]
+    [<span class="optional"> forward (<code class="constant">only</code>|<code class="constant">first</code>) ; </span>]
+    [<span class="optional"> forwarders { [<span class="optional"> <em class="replaceable"><code>ip_addr</code></em> [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] ; ... </span>] }; </span>]
+    [<span class="optional"> ixfr-base <em class="replaceable"><code>string</code></em> ; </span>]
+    [<span class="optional"> ixfr-tmp-file <em class="replaceable"><code>string</code></em> ; </span>]
+    [<span class="optional"> maintain-ixfr-base <em class="replaceable"><code>yes_or_no</code></em> ; </span>]
+    [<span class="optional"> max-ixfr-log-size <em class="replaceable"><code>number</code></em> ; </span>]
+    [<span class="optional"> max-transfer-idle-out <em class="replaceable"><code>number</code></em> ; </span>]
+    [<span class="optional"> max-transfer-time-out <em class="replaceable"><code>number</code></em> ; </span>]
+    [<span class="optional"> notify <em class="replaceable"><code>yes_or_no</code></em> | <em class="replaceable"><code>explicit</code></em> | <em class="replaceable"><code>master-only</code></em> ; </span>]
+    [<span class="optional"> notify-delay <em class="replaceable"><code>seconds</code></em> ; </span>]
+    [<span class="optional"> pubkey <em class="replaceable"><code>number</code></em> <em class="replaceable"><code>number</code></em> <em class="replaceable"><code>number</code></em> <em class="replaceable"><code>string</code></em> ; </span>]
+    [<span class="optional"> notify-source (<em class="replaceable"><code>ip4_addr</code></em> | <code class="constant">*</code>) [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] ; </span>]
+    [<span class="optional"> notify-source-v6 (<em class="replaceable"><code>ip6_addr</code></em> | <code class="constant">*</code>) [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] ; </span>]
+    [<span class="optional"> zone-statistics <em class="replaceable"><code>yes_or_no</code></em> ; </span>]
+    [<span class="optional"> sig-validity-interval <em class="replaceable"><code>number</code></em> ; </span>]
+    [<span class="optional"> database <em class="replaceable"><code>string</code></em> ; </span>]
+    [<span class="optional"> min-refresh-time <em class="replaceable"><code>number</code></em> ; </span>]
+    [<span class="optional"> max-refresh-time <em class="replaceable"><code>number</code></em> ; </span>]
+    [<span class="optional"> min-retry-time <em class="replaceable"><code>number</code></em> ; </span>]
+    [<span class="optional"> max-retry-time <em class="replaceable"><code>number</code></em> ; </span>]
+    [<span class="optional"> key-directory <em class="replaceable"><code>path_name</code></em>; </span>]
+    [<span class="optional"> zero-no-soa-ttl <em class="replaceable"><code>yes_or_no</code></em> ; </span>]
+};
+
+zone <em class="replaceable"><code>zone_name</code></em> [<span class="optional"><em class="replaceable"><code>class</code></em></span>] {
+    type slave;
+    [<span class="optional"> allow-notify { <em class="replaceable"><code>address_match_list</code></em> }; </span>]
+    [<span class="optional"> allow-query { <em class="replaceable"><code>address_match_list</code></em> }; </span>]
+    [<span class="optional"> allow-transfer { <em class="replaceable"><code>address_match_list</code></em> }; </span>]
+    [<span class="optional"> allow-update-forwarding { <em class="replaceable"><code>address_match_list</code></em> }; </span>]
+    [<span class="optional"> update-check-ksk <em class="replaceable"><code>yes_or_no</code></em>; </span>]
+    [<span class="optional"> also-notify { <em class="replaceable"><code>ip_addr</code></em> [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] ; [<span class="optional"> <em class="replaceable"><code>ip_addr</code></em> [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] ; ... </span>] }; </span>]
+    [<span class="optional"> check-names (<code class="constant">warn</code>|<code class="constant">fail</code>|<code class="constant">ignore</code>) ; </span>]
+    [<span class="optional"> dialup <em class="replaceable"><code>dialup_option</code></em> ; </span>]
+    [<span class="optional"> file <em class="replaceable"><code>string</code></em> ; </span>]
+    [<span class="optional"> masterfile-format (<code class="constant">text</code>|<code class="constant">raw</code>) ; </span>]
+    [<span class="optional"> journal <em class="replaceable"><code>string</code></em> ; </span>]
+    [<span class="optional"> forward (<code class="constant">only</code>|<code class="constant">first</code>) ; </span>]
+    [<span class="optional"> forwarders { [<span class="optional"> <em class="replaceable"><code>ip_addr</code></em> [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] ; ... </span>] }; </span>]
+    [<span class="optional"> ixfr-base <em class="replaceable"><code>string</code></em> ; </span>]
+    [<span class="optional"> ixfr-tmp-file <em class="replaceable"><code>string</code></em> ; </span>]
+    [<span class="optional"> maintain-ixfr-base <em class="replaceable"><code>yes_or_no</code></em> ; </span>]
+    [<span class="optional"> masters [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] { ( <em class="replaceable"><code>masters_list</code></em> | <em class="replaceable"><code>ip_addr</code></em> [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] [<span class="optional">key <em class="replaceable"><code>key</code></em></span>] ) ; [<span class="optional">...</span>] }; </span>]
+    [<span class="optional"> max-ixfr-log-size <em class="replaceable"><code>number</code></em> ; </span>]
+    [<span class="optional"> max-transfer-idle-in <em class="replaceable"><code>number</code></em> ; </span>]
+    [<span class="optional"> max-transfer-idle-out <em class="replaceable"><code>number</code></em> ; </span>]
+    [<span class="optional"> max-transfer-time-in <em class="replaceable"><code>number</code></em> ; </span>]
+    [<span class="optional"> max-transfer-time-out <em class="replaceable"><code>number</code></em> ; </span>]
+    [<span class="optional"> notify <em class="replaceable"><code>yes_or_no</code></em> | <em class="replaceable"><code>explicit</code></em> | <em class="replaceable"><code>master-only</code></em> ; </span>]
+    [<span class="optional"> pubkey <em class="replaceable"><code>number</code></em> <em class="replaceable"><code>number</code></em> <em class="replaceable"><code>number</code></em> <em class="replaceable"><code>string</code></em> ; </span>]
+    [<span class="optional"> transfer-source (<em class="replaceable"><code>ip4_addr</code></em> | <code class="constant">*</code>) [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] ; </span>]
+    [<span class="optional"> transfer-source-v6 (<em class="replaceable"><code>ip6_addr</code></em> | <code class="constant">*</code>) [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] ; </span>]
+    [<span class="optional"> alt-transfer-source (<em class="replaceable"><code>ip4_addr</code></em> | <code class="constant">*</code>) [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] ; </span>]
+    [<span class="optional"> alt-transfer-source-v6 (<em class="replaceable"><code>ip6_addr</code></em> | <code class="constant">*</code>) [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] ; </span>]
+    [<span class="optional"> use-alt-transfer-source <em class="replaceable"><code>yes_or_no</code></em>; </span>]
+    [<span class="optional"> notify-source (<em class="replaceable"><code>ip4_addr</code></em> | <code class="constant">*</code>) [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] ; </span>]
+    [<span class="optional"> notify-source-v6 (<em class="replaceable"><code>ip6_addr</code></em> | <code class="constant">*</code>) [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] ; </span>]
+    [<span class="optional"> zone-statistics <em class="replaceable"><code>yes_or_no</code></em> ; </span>]
+    [<span class="optional"> database <em class="replaceable"><code>string</code></em> ; </span>]
+    [<span class="optional"> min-refresh-time <em class="replaceable"><code>number</code></em> ; </span>]
+    [<span class="optional"> max-refresh-time <em class="replaceable"><code>number</code></em> ; </span>]
+    [<span class="optional"> min-retry-time <em class="replaceable"><code>number</code></em> ; </span>]
+    [<span class="optional"> max-retry-time <em class="replaceable"><code>number</code></em> ; </span>]
+    [<span class="optional"> multi-master <em class="replaceable"><code>yes_or_no</code></em> ; </span>]
+    [<span class="optional"> zero-no-soa-ttl <em class="replaceable"><code>yes_or_no</code></em> ; </span>]
+};
+
+zone <em class="replaceable"><code>zone_name</code></em> [<span class="optional"><em class="replaceable"><code>class</code></em></span>] {
+    type hint;
+    file <em class="replaceable"><code>string</code></em> ;
+    [<span class="optional"> delegation-only <em class="replaceable"><code>yes_or_no</code></em> ; </span>]
+    [<span class="optional"> check-names (<code class="constant">warn</code>|<code class="constant">fail</code>|<code class="constant">ignore</code>) ; // Not Implemented. </span>]
+};
+
+zone <em class="replaceable"><code>zone_name</code></em> [<span class="optional"><em class="replaceable"><code>class</code></em></span>] {
+    type stub;
+    [<span class="optional"> allow-query { <em class="replaceable"><code>address_match_list</code></em> }; </span>]
+    [<span class="optional"> check-names (<code class="constant">warn</code>|<code class="constant">fail</code>|<code class="constant">ignore</code>) ; </span>]
+    [<span class="optional"> dialup <em class="replaceable"><code>dialup_option</code></em> ; </span>]
+    [<span class="optional"> delegation-only <em class="replaceable"><code>yes_or_no</code></em> ; </span>]
+    [<span class="optional"> file <em class="replaceable"><code>string</code></em> ; </span>]
+    [<span class="optional"> masterfile-format (<code class="constant">text</code>|<code class="constant">raw</code>) ; </span>]
+    [<span class="optional"> forward (<code class="constant">only</code>|<code class="constant">first</code>) ; </span>]
+    [<span class="optional"> forwarders { [<span class="optional"> <em class="replaceable"><code>ip_addr</code></em> [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] ; ... </span>] }; </span>]
+    [<span class="optional"> masters [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] { ( <em class="replaceable"><code>masters_list</code></em> | <em class="replaceable"><code>ip_addr</code></em> [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] [<span class="optional">key <em class="replaceable"><code>key</code></em></span>] ) ; [<span class="optional">...</span>] }; </span>]
+    [<span class="optional"> max-transfer-idle-in <em class="replaceable"><code>number</code></em> ; </span>]
+    [<span class="optional"> max-transfer-time-in <em class="replaceable"><code>number</code></em> ; </span>]
+    [<span class="optional"> pubkey <em class="replaceable"><code>number</code></em> <em class="replaceable"><code>number</code></em> <em class="replaceable"><code>number</code></em> <em class="replaceable"><code>string</code></em> ; </span>]
+    [<span class="optional"> transfer-source (<em class="replaceable"><code>ip4_addr</code></em> | <code class="constant">*</code>) [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] ; </span>]
+    [<span class="optional"> transfer-source-v6 (<em class="replaceable"><code>ip6_addr</code></em> | <code class="constant">*</code>) [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] ; </span>]
+    [<span class="optional"> alt-transfer-source (<em class="replaceable"><code>ip4_addr</code></em> | <code class="constant">*</code>) [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] ; </span>]
+    [<span class="optional"> alt-transfer-source-v6 (<em class="replaceable"><code>ip6_addr</code></em> | <code class="constant">*</code>) [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] ; </span>]
+    [<span class="optional"> use-alt-transfer-source <em class="replaceable"><code>yes_or_no</code></em>; </span>]
+    [<span class="optional"> zone-statistics <em class="replaceable"><code>yes_or_no</code></em> ; </span>]
+    [<span class="optional"> database <em class="replaceable"><code>string</code></em> ; </span>]
+    [<span class="optional"> min-refresh-time <em class="replaceable"><code>number</code></em> ; </span>]
+    [<span class="optional"> max-refresh-time <em class="replaceable"><code>number</code></em> ; </span>]
+    [<span class="optional"> min-retry-time <em class="replaceable"><code>number</code></em> ; </span>]
+    [<span class="optional"> max-retry-time <em class="replaceable"><code>number</code></em> ; </span>]
+    [<span class="optional"> multi-master <em class="replaceable"><code>yes_or_no</code></em> ; </span>]
+};
+
+zone <em class="replaceable"><code>zone_name</code></em> [<span class="optional"><em class="replaceable"><code>class</code></em></span>] {
+    type forward;
+    [<span class="optional"> forward (<code class="constant">only</code>|<code class="constant">first</code>) ; </span>]
+    [<span class="optional"> forwarders { [<span class="optional"> <em class="replaceable"><code>ip_addr</code></em> [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] ; ... </span>] }; </span>]
+    [<span class="optional"> delegation-only <em class="replaceable"><code>yes_or_no</code></em> ; </span>]
+};
+
+zone <em class="replaceable"><code>zone_name</code></em> [<span class="optional"><em class="replaceable"><code>class</code></em></span>] {
+    type delegation-only;
+};
+
+</pre>
+</div>
+<div class="sect2" lang="en">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="id2586798"></a><span><strong class="command">zone</strong></span> Statement Definition and Usage</h3></div></div></div>
+<div class="sect3" lang="en">
+<div class="titlepage"><div><div><h4 class="title">
+<a name="id2586806"></a>Zone Types</h4></div></div></div>
+<div class="informaltable"><table border="1">
+<colgroup>
+<col>
+<col>
+</colgroup>
+<tbody>
+<tr>
+<td>
+                      <p>
+                        <code class="varname">master</code>
+                      </p>
+                    </td>
+<td>
+                      <p>
+                        The server has a master copy of the data
+                        for the zone and will be able to provide authoritative
+                        answers for
+                        it.
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p>
+                        <code class="varname">slave</code>
+                      </p>
+                    </td>
+<td>
+                      <p>
+                        A slave zone is a replica of a master
+                        zone. The <span><strong class="command">masters</strong></span> list
+                        specifies one or more IP addresses
+                        of master servers that the slave contacts to update
+                        its copy of the zone.
+                        Masters list elements can also be names of other
+                        masters lists.
+                        By default, transfers are made from port 53 on the
+                        servers; this can
+                        be changed for all servers by specifying a port number
+                        before the
+                        list of IP addresses, or on a per-server basis after
+                        the IP address.
+                        Authentication to the master can also be done with
+                        per-server TSIG keys.
+                        If a file is specified, then the
+                        replica will be written to this file whenever the zone
+                        is changed,
+                        and reloaded from this file on a server restart. Use
+                        of a file is
+                        recommended, since it often speeds server startup and
+                        eliminates
+                        a needless waste of bandwidth. Note that for large
+                        numbers (in the
+                        tens or hundreds of thousands) of zones per server, it
+                        is best to
+                        use a two-level naming scheme for zone filenames. For
+                        example,
+                        a slave server for the zone <code class="literal">example.com</code> might place
+                        the zone contents into a file called
+                        <code class="filename">ex/example.com</code> where <code class="filename">ex/</code> is
+                        just the first two letters of the zone name. (Most
+                        operating systems
+                        behave very slowly if you put 100 000 files into
+                        a single directory.)
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p>
+                        <code class="varname">stub</code>
+                      </p>
+                    </td>
+<td>
+                      <p>
+                        A stub zone is similar to a slave zone,
+                        except that it replicates only the NS records of a
+                        master zone instead
+                        of the entire zone. Stub zones are not a standard part
+                        of the DNS;
+                        they are a feature specific to the <acronym class="acronym">BIND</acronym> implementation.
+                      </p>
+
+                      <p>
+                        Stub zones can be used to eliminate the need for glue
+                        NS record
+                        in a parent zone at the expense of maintaining a stub
+                        zone entry and
+                        a set of name server addresses in <code class="filename">named.conf</code>.
+                        This usage is not recommended for new configurations,
+                        and BIND 9
+                        supports it only in a limited way.
+                        In <acronym class="acronym">BIND</acronym> 4/8, zone
+                        transfers of a parent zone
+                        included the NS records from stub children of that
+                        zone. This meant
+                        that, in some cases, users could get away with
+                        configuring child stubs
+                        only in the master server for the parent zone. <acronym class="acronym">BIND</acronym>
+                        9 never mixes together zone data from different zones
+                        in this
+                        way. Therefore, if a <acronym class="acronym">BIND</acronym> 9 master serving a parent
+                        zone has child stub zones configured, all the slave
+                        servers for the
+                        parent zone also need to have the same child stub
+                        zones
+                        configured.
+                      </p>
+
+                      <p>
+                        Stub zones can also be used as a way of forcing the
+                        resolution
+                        of a given domain to use a particular set of
+                        authoritative servers.
+                        For example, the caching name servers on a private
+                        network using
+                        RFC1918 addressing may be configured with stub zones
+                        for
+                        <code class="literal">10.in-addr.arpa</code>
+                        to use a set of internal name servers as the
+                        authoritative
+                        servers for that domain.
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p>
+                        <code class="varname">forward</code>
+                      </p>
+                    </td>
+<td>
+                      <p>
+                        A "forward zone" is a way to configure
+                        forwarding on a per-domain basis.  A <span><strong class="command">zone</strong></span> statement
+                        of type <span><strong class="command">forward</strong></span> can
+                        contain a <span><strong class="command">forward</strong></span>
+                        and/or <span><strong class="command">forwarders</strong></span>
+                        statement,
+                        which will apply to queries within the domain given by
+                        the zone
+                        name. If no <span><strong class="command">forwarders</strong></span>
+                        statement is present or
+                        an empty list for <span><strong class="command">forwarders</strong></span> is given, then no
+                        forwarding will be done for the domain, canceling the
+                        effects of
+                        any forwarders in the <span><strong class="command">options</strong></span> statement. Thus
+                        if you want to use this type of zone to change the
+                        behavior of the
+                        global <span><strong class="command">forward</strong></span> option
+                        (that is, "forward first"
+                        to, then "forward only", or vice versa, but want to
+                        use the same
+                        servers as set globally) you need to re-specify the
+                        global forwarders.
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p>
+                        <code class="varname">hint</code>
+                      </p>
+                    </td>
+<td>
+                      <p>
+                        The initial set of root name servers is
+                        specified using a "hint zone". When the server starts
+                        up, it uses
+                        the root hints to find a root name server and get the
+                        most recent
+                        list of root name servers. If no hint zone is
+                        specified for class
+                        IN, the server uses a compiled-in default set of root
+                        servers hints.
+                        Classes other than IN have no built-in defaults hints.
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p>
+                        <code class="varname">delegation-only</code>
+                      </p>
+                    </td>
+<td>
+                      <p>
+                        This is used to enforce the delegation-only
+                        status of infrastructure zones (e.g. COM, NET, ORG).
+                        Any answer that
+                        is received without an explicit or implicit delegation
+                        in the authority
+                        section will be treated as NXDOMAIN.  This does not
+                        apply to the zone
+                        apex.  This should not be applied to leaf zones.
+                      </p>
+                      <p>
+                        <code class="varname">delegation-only</code> has no
+                        effect on answers received
+                        from forwarders.
+                      </p>
+                    </td>
+</tr>
+</tbody>
+</table></div>
+</div>
+<div class="sect3" lang="en">
+<div class="titlepage"><div><div><h4 class="title">
+<a name="id2587362"></a>Class</h4></div></div></div>
+<p>
+              The zone's name may optionally be followed by a class. If
+              a class is not specified, class <code class="literal">IN</code> (for <code class="varname">Internet</code>),
+              is assumed. This is correct for the vast majority of cases.
+            </p>
+<p>
+              The <code class="literal">hesiod</code> class is
+              named for an information service from MIT's Project Athena. It
+              is
+              used to share information about various systems databases, such
+              as users, groups, printers and so on. The keyword
+              <code class="literal">HS</code> is
+              a synonym for hesiod.
+            </p>
+<p>
+              Another MIT development is Chaosnet, a LAN protocol created
+              in the mid-1970s. Zone data for it can be specified with the <code class="literal">CHAOS</code> class.
+            </p>
+</div>
+<div class="sect3" lang="en">
+<div class="titlepage"><div><div><h4 class="title">
+<a name="id2587395"></a>Zone Options</h4></div></div></div>
+<div class="variablelist"><dl>
+<dt><span class="term"><span><strong class="command">allow-notify</strong></span></span></dt>
+<dd><p>
+                    See the description of
+                    <span><strong class="command">allow-notify</strong></span> in <a href="Bv9ARM.ch06.html#access_control" title="Access Control">the section called &#8220;Access Control&#8221;</a>.
+                  </p></dd>
+<dt><span class="term"><span><strong class="command">allow-query</strong></span></span></dt>
+<dd><p>
+                    See the description of
+                    <span><strong class="command">allow-query</strong></span> in <a href="Bv9ARM.ch06.html#access_control" title="Access Control">the section called &#8220;Access Control&#8221;</a>.
+                  </p></dd>
+<dt><span class="term"><span><strong class="command">allow-transfer</strong></span></span></dt>
+<dd><p>
+                    See the description of <span><strong class="command">allow-transfer</strong></span>
+                    in <a href="Bv9ARM.ch06.html#access_control" title="Access Control">the section called &#8220;Access Control&#8221;</a>.
+                  </p></dd>
+<dt><span class="term"><span><strong class="command">allow-update</strong></span></span></dt>
+<dd><p>
+                    See the description of <span><strong class="command">allow-update</strong></span>
+                    in <a href="Bv9ARM.ch06.html#access_control" title="Access Control">the section called &#8220;Access Control&#8221;</a>.
+                  </p></dd>
+<dt><span class="term"><span><strong class="command">update-policy</strong></span></span></dt>
+<dd><p>
+                    Specifies a "Simple Secure Update" policy. See
+                    <a href="Bv9ARM.ch06.html#dynamic_update_policies" title="Dynamic Update Policies">the section called &#8220;Dynamic Update Policies&#8221;</a>.
+                  </p></dd>
+<dt><span class="term"><span><strong class="command">allow-update-forwarding</strong></span></span></dt>
+<dd><p>
+                    See the description of <span><strong class="command">allow-update-forwarding</strong></span>
+                    in <a href="Bv9ARM.ch06.html#access_control" title="Access Control">the section called &#8220;Access Control&#8221;</a>.
+                  </p></dd>
+<dt><span class="term"><span><strong class="command">also-notify</strong></span></span></dt>
+<dd><p>
+                    Only meaningful if <span><strong class="command">notify</strong></span>
+                    is
+                    active for this zone. The set of machines that will
+                    receive a
+                    <code class="literal">DNS NOTIFY</code> message
+                    for this zone is made up of all the listed name servers
+                    (other than
+                    the primary master) for the zone plus any IP addresses
+                    specified
+                    with <span><strong class="command">also-notify</strong></span>. A port
+                    may be specified
+                    with each <span><strong class="command">also-notify</strong></span>
+                    address to send the notify
+                    messages to a port other than the default of 53.
+                    <span><strong class="command">also-notify</strong></span> is not
+                    meaningful for stub zones.
+                    The default is the empty list.
+                  </p></dd>
+<dt><span class="term"><span><strong class="command">check-names</strong></span></span></dt>
+<dd><p>
+                    This option is used to restrict the character set and
+                    syntax of
+                    certain domain names in master files and/or DNS responses
+                    received from the
+                    network.  The default varies according to zone type.  For <span><strong class="command">master</strong></span> zones the default is <span><strong class="command">fail</strong></span>.  For <span><strong class="command">slave</strong></span>
+                    zones the default is <span><strong class="command">warn</strong></span>.
+                  </p></dd>
+<dt><span class="term"><span><strong class="command">check-mx</strong></span></span></dt>
+<dd><p>
+                    See the description of
+                    <span><strong class="command">check-mx</strong></span> in <a href="Bv9ARM.ch06.html#boolean_options" title="Boolean Options">the section called &#8220;Boolean Options&#8221;</a>.
+                  </p></dd>
+<dt><span class="term"><span><strong class="command">check-wildcard</strong></span></span></dt>
+<dd><p>
+                    See the description of
+                    <span><strong class="command">check-wildcard</strong></span> in <a href="Bv9ARM.ch06.html#boolean_options" title="Boolean Options">the section called &#8220;Boolean Options&#8221;</a>.
+                  </p></dd>
+<dt><span class="term"><span><strong class="command">check-integrity</strong></span></span></dt>
+<dd><p>
+                    See the description of
+                    <span><strong class="command">check-integrity</strong></span> in <a href="Bv9ARM.ch06.html#boolean_options" title="Boolean Options">the section called &#8220;Boolean Options&#8221;</a>.
+                  </p></dd>
+<dt><span class="term"><span><strong class="command">check-sibling</strong></span></span></dt>
+<dd><p>
+                    See the description of
+                    <span><strong class="command">check-sibling</strong></span> in <a href="Bv9ARM.ch06.html#boolean_options" title="Boolean Options">the section called &#8220;Boolean Options&#8221;</a>.
+                  </p></dd>
+<dt><span class="term"><span><strong class="command">zero-no-soa-ttl</strong></span></span></dt>
+<dd><p>
+                    See the description of
+                    <span><strong class="command">zero-no-soa-ttl</strong></span> in <a href="Bv9ARM.ch06.html#boolean_options" title="Boolean Options">the section called &#8220;Boolean Options&#8221;</a>.
+                  </p></dd>
+<dt><span class="term"><span><strong class="command">update-check-ksk</strong></span></span></dt>
+<dd><p>
+                    See the description of
+                    <span><strong class="command">update-check-ksk</strong></span> in <a href="Bv9ARM.ch06.html#boolean_options" title="Boolean Options">the section called &#8220;Boolean Options&#8221;</a>.
+                  </p></dd>
+<dt><span class="term"><span><strong class="command">database</strong></span></span></dt>
+<dd>
+<p>
+                    Specify the type of database to be used for storing the
+                    zone data.  The string following the <span><strong class="command">database</strong></span> keyword
+                    is interpreted as a list of whitespace-delimited words.
+                    The first word
+                    identifies the database type, and any subsequent words are
+                    passed
+                    as arguments to the database to be interpreted in a way
+                    specific
+                    to the database type.
+                  </p>
+<p>
+                    The default is <strong class="userinput"><code>"rbt"</code></strong>, BIND 9's
+                    native in-memory
+                    red-black-tree database.  This database does not take
+                    arguments.
+                  </p>
+<p>
+                    Other values are possible if additional database drivers
+                    have been linked into the server.  Some sample drivers are
+                    included
+                    with the distribution but none are linked in by default.
+                  </p>
+</dd>
+<dt><span class="term"><span><strong class="command">dialup</strong></span></span></dt>
+<dd><p>
+                    See the description of
+                    <span><strong class="command">dialup</strong></span> in <a href="Bv9ARM.ch06.html#boolean_options" title="Boolean Options">the section called &#8220;Boolean Options&#8221;</a>.
+                  </p></dd>
+<dt><span class="term"><span><strong class="command">delegation-only</strong></span></span></dt>
+<dd><p>
+                    The flag only applies to hint and stub zones.  If set
+                    to <strong class="userinput"><code>yes</code></strong>, then the zone will also be
+                    treated as if it
+                    is also a delegation-only type zone.
+                  </p></dd>
+<dt><span class="term"><span><strong class="command">forward</strong></span></span></dt>
+<dd><p>
+                    Only meaningful if the zone has a forwarders
+                    list. The <span><strong class="command">only</strong></span> value causes
+                    the lookup to fail
+                    after trying the forwarders and getting no answer, while <span><strong class="command">first</strong></span> would
+                    allow a normal lookup to be tried.
+                  </p></dd>
+<dt><span class="term"><span><strong class="command">forwarders</strong></span></span></dt>
+<dd><p>
+                    Used to override the list of global forwarders.
+                    If it is not specified in a zone of type <span><strong class="command">forward</strong></span>,
+                    no forwarding is done for the zone and the global options are
+                    not used.
+                  </p></dd>
+<dt><span class="term"><span><strong class="command">ixfr-base</strong></span></span></dt>
+<dd><p>
+                    Was used in <acronym class="acronym">BIND</acronym> 8 to
+                    specify the name
+                    of the transaction log (journal) file for dynamic update
+                    and IXFR.
+                    <acronym class="acronym">BIND</acronym> 9 ignores the option
+                    and constructs the name of the journal
+                    file by appending "<code class="filename">.jnl</code>"
+                    to the name of the
+                    zone file.
+                  </p></dd>
+<dt><span class="term"><span><strong class="command">ixfr-tmp-file</strong></span></span></dt>
+<dd><p>
+                    Was an undocumented option in <acronym class="acronym">BIND</acronym> 8.
+                    Ignored in <acronym class="acronym">BIND</acronym> 9.
+                  </p></dd>
+<dt><span class="term"><span><strong class="command">journal</strong></span></span></dt>
+<dd><p>
+                    Allow the default journal's filename to be overridden.
+                    The default is the zone's filename with "<code class="filename">.jnl</code>" appended.
+                    This is applicable to <span><strong class="command">master</strong></span> and <span><strong class="command">slave</strong></span> zones.
+                  </p></dd>
+<dt><span class="term"><span><strong class="command">max-transfer-time-in</strong></span></span></dt>
+<dd><p>
+                    See the description of
+                    <span><strong class="command">max-transfer-time-in</strong></span> in <a href="Bv9ARM.ch06.html#zone_transfers" title="Zone Transfers">the section called &#8220;Zone Transfers&#8221;</a>.
+                  </p></dd>
+<dt><span class="term"><span><strong class="command">max-transfer-idle-in</strong></span></span></dt>
+<dd><p>
+                    See the description of
+                    <span><strong class="command">max-transfer-idle-in</strong></span> in <a href="Bv9ARM.ch06.html#zone_transfers" title="Zone Transfers">the section called &#8220;Zone Transfers&#8221;</a>.
+                  </p></dd>
+<dt><span class="term"><span><strong class="command">max-transfer-time-out</strong></span></span></dt>
+<dd><p>
+                    See the description of
+                    <span><strong class="command">max-transfer-time-out</strong></span> in <a href="Bv9ARM.ch06.html#zone_transfers" title="Zone Transfers">the section called &#8220;Zone Transfers&#8221;</a>.
+                  </p></dd>
+<dt><span class="term"><span><strong class="command">max-transfer-idle-out</strong></span></span></dt>
+<dd><p>
+                    See the description of
+                    <span><strong class="command">max-transfer-idle-out</strong></span> in <a href="Bv9ARM.ch06.html#zone_transfers" title="Zone Transfers">the section called &#8220;Zone Transfers&#8221;</a>.
+                  </p></dd>
+<dt><span class="term"><span><strong class="command">notify</strong></span></span></dt>
+<dd><p>
+                    See the description of
+                    <span><strong class="command">notify</strong></span> in <a href="Bv9ARM.ch06.html#boolean_options" title="Boolean Options">the section called &#8220;Boolean Options&#8221;</a>.
+                  </p></dd>
+<dt><span class="term"><span><strong class="command">notify-delay</strong></span></span></dt>
+<dd><p>
+                    See the description of
+                    <span><strong class="command">notify-delay</strong></span> in <a href="Bv9ARM.ch06.html#tuning" title="Tuning">the section called &#8220;Tuning&#8221;</a>.
+                  </p></dd>
+<dt><span class="term"><span><strong class="command">pubkey</strong></span></span></dt>
+<dd><p>
+                    In <acronym class="acronym">BIND</acronym> 8, this option was
+                    intended for specifying
+                    a public zone key for verification of signatures in DNSSEC
+                    signed
+                    zones when they are loaded from disk. <acronym class="acronym">BIND</acronym> 9 does not verify signatures
+                    on load and ignores the option.
+                  </p></dd>
+<dt><span class="term"><span><strong class="command">zone-statistics</strong></span></span></dt>
+<dd><p>
+                    If <strong class="userinput"><code>yes</code></strong>, the server will keep
+                    statistical
+                    information for this zone, which can be dumped to the
+                    <span><strong class="command">statistics-file</strong></span> defined in
+                    the server options.
+                  </p></dd>
+<dt><span class="term"><span><strong class="command">sig-validity-interval</strong></span></span></dt>
+<dd><p>
+                    See the description of
+                    <span><strong class="command">sig-validity-interval</strong></span> in <a href="Bv9ARM.ch06.html#tuning" title="Tuning">the section called &#8220;Tuning&#8221;</a>.
+                  </p></dd>
+<dt><span class="term"><span><strong class="command">transfer-source</strong></span></span></dt>
+<dd><p>
+                    See the description of
+                    <span><strong class="command">transfer-source</strong></span> in <a href="Bv9ARM.ch06.html#zone_transfers" title="Zone Transfers">the section called &#8220;Zone Transfers&#8221;</a>.
+                  </p></dd>
+<dt><span class="term"><span><strong class="command">transfer-source-v6</strong></span></span></dt>
+<dd><p>
+                    See the description of
+                    <span><strong class="command">transfer-source-v6</strong></span> in <a href="Bv9ARM.ch06.html#zone_transfers" title="Zone Transfers">the section called &#8220;Zone Transfers&#8221;</a>.
+                  </p></dd>
+<dt><span class="term"><span><strong class="command">alt-transfer-source</strong></span></span></dt>
+<dd><p>
+                    See the description of
+                    <span><strong class="command">alt-transfer-source</strong></span> in <a href="Bv9ARM.ch06.html#zone_transfers" title="Zone Transfers">the section called &#8220;Zone Transfers&#8221;</a>.
+                  </p></dd>
+<dt><span class="term"><span><strong class="command">alt-transfer-source-v6</strong></span></span></dt>
+<dd><p>
+                    See the description of
+                    <span><strong class="command">alt-transfer-source-v6</strong></span> in <a href="Bv9ARM.ch06.html#zone_transfers" title="Zone Transfers">the section called &#8220;Zone Transfers&#8221;</a>.
+                  </p></dd>
+<dt><span class="term"><span><strong class="command">use-alt-transfer-source</strong></span></span></dt>
+<dd><p>
+                    See the description of
+                    <span><strong class="command">use-alt-transfer-source</strong></span> in <a href="Bv9ARM.ch06.html#zone_transfers" title="Zone Transfers">the section called &#8220;Zone Transfers&#8221;</a>.
+                  </p></dd>
+<dt><span class="term"><span><strong class="command">notify-source</strong></span></span></dt>
+<dd><p>
+                    See the description of
+                    <span><strong class="command">notify-source</strong></span> in <a href="Bv9ARM.ch06.html#zone_transfers" title="Zone Transfers">the section called &#8220;Zone Transfers&#8221;</a>.
+                  </p></dd>
+<dt><span class="term"><span><strong class="command">notify-source-v6</strong></span></span></dt>
+<dd><p>
+                    See the description of
+                    <span><strong class="command">notify-source-v6</strong></span> in <a href="Bv9ARM.ch06.html#zone_transfers" title="Zone Transfers">the section called &#8220;Zone Transfers&#8221;</a>.
+                  </p></dd>
+<dt>
+<span class="term"><span><strong class="command">min-refresh-time</strong></span>, </span><span class="term"><span><strong class="command">max-refresh-time</strong></span>, </span><span class="term"><span><strong class="command">min-retry-time</strong></span>, </span><span class="term"><span><strong class="command">max-retry-time</strong></span></span>
+</dt>
+<dd><p>
+                    See the description in <a href="Bv9ARM.ch06.html#tuning" title="Tuning">the section called &#8220;Tuning&#8221;</a>.
+                  </p></dd>
+<dt><span class="term"><span><strong class="command">ixfr-from-differences</strong></span></span></dt>
+<dd><p>
+                    See the description of
+                    <span><strong class="command">ixfr-from-differences</strong></span> in <a href="Bv9ARM.ch06.html#boolean_options" title="Boolean Options">the section called &#8220;Boolean Options&#8221;</a>.
+                  </p></dd>
+<dt><span class="term"><span><strong class="command">key-directory</strong></span></span></dt>
+<dd><p>
+                    See the description of
+                    <span><strong class="command">key-directory</strong></span> in <a href="Bv9ARM.ch06.html#options" title="options Statement Definition and
+          Usage">the section called &#8220;<span><strong class="command">options</strong></span> Statement Definition and
+          Usage&#8221;</a>.
+                  </p></dd>
+<dt><span class="term"><span><strong class="command">multi-master</strong></span></span></dt>
+<dd><p>
+                    See the description of <span><strong class="command">multi-master</strong></span> in
+                    <a href="Bv9ARM.ch06.html#boolean_options" title="Boolean Options">the section called &#8220;Boolean Options&#8221;</a>.
+                  </p></dd>
+<dt><span class="term"><span><strong class="command">masterfile-format</strong></span></span></dt>
+<dd><p>
+                    See the description of <span><strong class="command">masterfile-format</strong></span>
+                    in <a href="Bv9ARM.ch06.html#tuning" title="Tuning">the section called &#8220;Tuning&#8221;</a>.
+                  </p></dd>
+</dl></div>
+</div>
+<div class="sect3" lang="en">
+<div class="titlepage"><div><div><h4 class="title">
+<a name="dynamic_update_policies"></a>Dynamic Update Policies</h4></div></div></div>
+<p>
+              <acronym class="acronym">BIND</acronym> 9 supports two alternative
+              methods of granting clients
+              the right to perform dynamic updates to a zone,
+              configured by the <span><strong class="command">allow-update</strong></span>
+              and
+              <span><strong class="command">update-policy</strong></span> option,
+              respectively.
+            </p>
+<p>
+              The <span><strong class="command">allow-update</strong></span> clause works the
+              same
+              way as in previous versions of <acronym class="acronym">BIND</acronym>. It grants given clients the
+              permission to update any record of any name in the zone.
+            </p>
+<p>
+              The <span><strong class="command">update-policy</strong></span> clause is new
+              in <acronym class="acronym">BIND</acronym>
+              9 and allows more fine-grained control over what updates are
+              allowed.
+              A set of rules is specified, where each rule either grants or
+              denies
+              permissions for one or more names to be updated by one or more
+              identities.
+              If the dynamic update request message is signed (that is, it
+              includes
+              either a TSIG or SIG(0) record), the identity of the signer can
+              be determined.
+            </p>
+<p>
+              Rules are specified in the <span><strong class="command">update-policy</strong></span> zone
+              option, and are only meaningful for master zones.  When the <span><strong class="command">update-policy</strong></span> statement
+              is present, it is a configuration error for the <span><strong class="command">allow-update</strong></span> statement
+              to be present.  The <span><strong class="command">update-policy</strong></span>
+              statement only
+              examines the signer of a message; the source address is not
+              relevant.
+            </p>
+<p>
+              This is how a rule definition looks:
+            </p>
+<pre class="programlisting">
+( <span><strong class="command">grant</strong></span> | <span><strong class="command">deny</strong></span> ) <em class="replaceable"><code>identity</code></em> <em class="replaceable"><code>nametype</code></em> <em class="replaceable"><code>name</code></em> [<span class="optional"> <em class="replaceable"><code>types</code></em> </span>]
+</pre>
+<p>
+              Each rule grants or denies privileges.  Once a message has
+              successfully matched a rule, the operation is immediately
+              granted
+              or denied and no further rules are examined.  A rule is matched
+              when the signer matches the identity field, the name matches the
+              name field in accordance with the nametype field, and the type
+              matches
+              the types specified in the type field.
+            </p>
+<p>
+              The identity field specifies a name or a wildcard name.
+              Normally, this
+              is the name of the TSIG or SIG(0) key used to sign the update
+              request.  When a
+              TKEY exchange has been used to create a shared secret, the
+              identity of the
+              shared secret is the same as the identity of the key used to
+              authenticate the
+              TKEY exchange.  When the <em class="replaceable"><code>identity</code></em> field specifies a
+              wildcard name, it is subject to DNS wildcard expansion, so the
+              rule will apply
+              to multiple identities.  The <em class="replaceable"><code>identity</code></em> field must
+              contain a fully-qualified domain name.
+            </p>
+<p>
+              The <em class="replaceable"><code>nametype</code></em> field has 6
+              values:
+              <code class="varname">name</code>, <code class="varname">subdomain</code>,
+              <code class="varname">wildcard</code>, <code class="varname">self</code>,
+               <code class="varname">selfsub</code>, and <code class="varname">selfwild</code>.
+            </p>
+<div class="informaltable"><table border="1">
+<colgroup>
+<col>
+<col>
+</colgroup>
+<tbody>
+<tr>
+<td>
+                      <p>
+                        <code class="varname">name</code>
+                      </p>
+                    </td>
+<td>
+                      <p>
+                        Exact-match semantics.  This rule matches
+                        when the name being updated is identical
+                        to the contents of the
+                        <em class="replaceable"><code>name</code></em> field.
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p>
+                        <code class="varname">subdomain</code>
+                      </p>
+                    </td>
+<td>
+                      <p>
+                        This rule matches when the name being updated
+                        is a subdomain of, or identical to, the
+                        contents of the <em class="replaceable"><code>name</code></em>
+                        field.
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p>
+                        <code class="varname">wildcard</code>
+                      </p>
+                    </td>
+<td>
+                      <p>
+                        The <em class="replaceable"><code>name</code></em> field
+                        is subject to DNS wildcard expansion, and
+                        this rule matches when the name being updated
+                        name is a valid expansion of the wildcard.
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p>
+                        <code class="varname">self</code>
+                      </p>
+                    </td>
+<td>
+                      <p>
+                        This rule matches when the name being updated
+                        matches the contents of the
+                        <em class="replaceable"><code>identity</code></em> field.
+                        The <em class="replaceable"><code>name</code></em> field
+                        is ignored, but should be the same as the
+                        <em class="replaceable"><code>identity</code></em> field.
+                        The <code class="varname">self</code> nametype is
+                        most useful when allowing using one key per
+                        name to update, where the key has the same
+                        name as the name to be updated.  The
+                        <em class="replaceable"><code>identity</code></em> would
+                        be specified as <code class="constant">*</code> (an asterisk) in
+                        this case.
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p>
+                        <code class="varname">selfsub</code>
+                      </p>
+                    </td>
+<td>
+                      <p>
+                        This rule is similar to <code class="varname">self</code>
+                        except that subdomains of <code class="varname">self</code>
+                        can also be updated.
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p>
+                        <code class="varname">selfwild</code>
+                      </p>
+                    </td>
+<td>
+                      <p>
+                        This rule is similar to <code class="varname">self</code>
+                        except that only subdomains of
+                        <code class="varname">self</code> can be updated.
+                      </p>
+                    </td>
+</tr>
+</tbody>
+</table></div>
+<p>
+              In all cases, the <em class="replaceable"><code>name</code></em>
+              field must
+              specify a fully-qualified domain name.
+            </p>
+<p>
+              If no types are explicitly specified, this rule matches all
+              types except
+              RRSIG, NS, SOA, and NSEC. Types may be specified by name, including
+              "ANY" (ANY matches all types except NSEC, which can never be
+              updated).
+              Note that when an attempt is made to delete all records
+              associated with a
+              name, the rules are checked for each existing record type.
+            </p>
+</div>
+</div>
+</div>
+<div class="sect1" lang="en">
+<div class="titlepage"><div><div><h2 class="title" style="clear: both">
+<a name="id2589080"></a>Zone File</h2></div></div></div>
+<div class="sect2" lang="en">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="types_of_resource_records_and_when_to_use_them"></a>Types of Resource Records and When to Use Them</h3></div></div></div>
+<p>
+            This section, largely borrowed from RFC 1034, describes the
+            concept of a Resource Record (RR) and explains when each is used.
+            Since the publication of RFC 1034, several new RRs have been
+            identified
+            and implemented in the DNS. These are also included.
+          </p>
+<div class="sect3" lang="en">
+<div class="titlepage"><div><div><h4 class="title">
+<a name="id2589098"></a>Resource Records</h4></div></div></div>
+<p>
+              A domain name identifies a node.  Each node has a set of
+              resource information, which may be empty.  The set of resource
+              information associated with a particular name is composed of
+              separate RRs. The order of RRs in a set is not significant and
+              need not be preserved by name servers, resolvers, or other
+              parts of the DNS. However, sorting of multiple RRs is
+              permitted for optimization purposes, for example, to specify
+              that a particular nearby server be tried first. See <a href="Bv9ARM.ch06.html#the_sortlist_statement" title="The sortlist Statement">the section called &#8220;The <span><strong class="command">sortlist</strong></span> Statement&#8221;</a> and <a href="Bv9ARM.ch06.html#rrset_ordering" title="RRset Ordering">the section called &#8220;RRset Ordering&#8221;</a>.
+            </p>
+<p>
+              The components of a Resource Record are:
+            </p>
+<div class="informaltable"><table border="1">
+<colgroup>
+<col>
+<col>
+</colgroup>
+<tbody>
+<tr>
+<td>
+                      <p>
+                        owner name
+                      </p>
+                    </td>
+<td>
+                      <p>
+                        The domain name where the RR is found.
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p>
+                        type
+                      </p>
+                    </td>
+<td>
+                      <p>
+                        An encoded 16-bit value that specifies
+                        the type of the resource record.
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p>
+                        TTL
+                      </p>
+                    </td>
+<td>
+                      <p>
+                        The time-to-live of the RR. This field
+                        is a 32-bit integer in units of seconds, and is
+                        primarily used by
+                        resolvers when they cache RRs. The TTL describes how
+                        long a RR can
+                        be cached before it should be discarded.
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p>
+                        class
+                      </p>
+                    </td>
+<td>
+                      <p>
+                        An encoded 16-bit value that identifies
+                        a protocol family or instance of a protocol.
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p>
+                        RDATA
+                      </p>
+                    </td>
+<td>
+                      <p>
+                        The resource data.  The format of the
+                        data is type (and sometimes class) specific.
+                      </p>
+                    </td>
+</tr>
+</tbody>
+</table></div>
+<p>
+              The following are <span class="emphasis"><em>types</em></span> of valid RRs:
+            </p>
+<div class="informaltable"><table border="1">
+<colgroup>
+<col>
+<col>
+</colgroup>
+<tbody>
+<tr>
+<td>
+                      <p>
+                        A
+                      </p>
+                    </td>
+<td>
+                      <p>
+                        A host address.  In the IN class, this is a
+                        32-bit IP address.  Described in RFC 1035.
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p>
+                        AAAA
+                      </p>
+                    </td>
+<td>
+                      <p>
+                        IPv6 address.  Described in RFC 1886.
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p>
+                        A6
+                      </p>
+                    </td>
+<td>
+                      <p>
+                        IPv6 address.  This can be a partial
+                        address (a suffix) and an indirection to the name
+                        where the rest of the
+                        address (the prefix) can be found.  Experimental.
+                        Described in RFC 2874.
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p>
+                        AFSDB
+                      </p>
+                    </td>
+<td>
+                      <p>
+                        Location of AFS database servers.
+                        Experimental.  Described in RFC 1183.
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p>
+                        APL
+                      </p>
+                    </td>
+<td>
+                      <p>
+                        Address prefix list.  Experimental.
+                        Described in RFC 3123.
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p>
+                        CERT
+                      </p>
+                    </td>
+<td>
+                      <p>
+                        Holds a digital certificate.
+                        Described in RFC 2538.
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p>
+                        CNAME
+                      </p>
+                    </td>
+<td>
+                      <p>
+                        Identifies the canonical name of an alias.
+                        Described in RFC 1035.
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p>
+                        DNAME
+                      </p>
+                    </td>
+<td>
+                      <p>
+                        Replaces the domain name specified with
+                        another name to be looked up, effectively aliasing an
+                        entire
+                        subtree of the domain name space rather than a single
+                        record
+                        as in the case of the CNAME RR.
+                        Described in RFC 2672.
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p>
+                        DNSKEY
+                      </p>
+                    </td>
+<td>
+                      <p>
+                        Stores a public key associated with a signed
+                        DNS zone.  Described in RFC 4034.
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p>
+                        DS
+                      </p>
+                    </td>
+<td>
+                      <p>
+                        Stores the hash of a public key associated with a
+                        signed DNS zone.  Described in RFC 4034.
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p>
+                        GPOS
+                      </p>
+                    </td>
+<td>
+                      <p>
+                        Specifies the global position.  Superseded by LOC.
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p>
+                        HINFO
+                      </p>
+                    </td>
+<td>
+                      <p>
+                        Identifies the CPU and OS used by a host.
+                        Described in RFC 1035.
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p>
+                        ISDN
+                      </p>
+                    </td>
+<td>
+                      <p>
+                        Representation of ISDN addresses.
+                        Experimental.  Described in RFC 1183.
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p>
+                        KEY
+                      </p>
+                    </td>
+<td>
+                      <p>
+                        Stores a public key associated with a
+                        DNS name.  Used in original DNSSEC; replaced
+                        by DNSKEY in DNSSECbis, but still used with
+                        SIG(0).  Described in RFCs 2535 and 2931.
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p>
+                        KX
+                      </p>
+                    </td>
+<td>
+                      <p>
+                        Identifies a key exchanger for this
+                        DNS name.  Described in RFC 2230.
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p>
+                        LOC
+                      </p>
+                    </td>
+<td>
+                      <p>
+                        For storing GPS info.  Described in RFC 1876.
+                        Experimental.
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p>
+                        MX
+                      </p>
+                    </td>
+<td>
+                      <p>
+                        Identifies a mail exchange for the domain with
+                        a 16-bit preference value (lower is better)
+                        followed by the host name of the mail exchange.
+                        Described in RFC 974, RFC 1035.
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p>
+                        NAPTR
+                      </p>
+                    </td>
+<td>
+                      <p>
+                        Name authority pointer.  Described in RFC 2915.
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p>
+                        NSAP
+                      </p>
+                    </td>
+<td>
+                      <p>
+                        A network service access point.
+                        Described in RFC 1706.
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p>
+                        NS
+                      </p>
+                    </td>
+<td>
+                      <p>
+                        The authoritative name server for the
+                        domain.  Described in RFC 1035.
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p>
+                        NSEC
+                      </p>
+                    </td>
+<td>
+                      <p>
+                        Used in DNSSECbis to securely indicate that
+                        RRs with an owner name in a certain name interval do
+                        not exist in
+                        a zone and indicate what RR types are present for an
+                        existing name.
+                        Described in RFC 4034.
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p>
+                        NXT
+                      </p>
+                    </td>
+<td>
+                      <p>
+                        Used in DNSSEC to securely indicate that
+                        RRs with an owner name in a certain name interval do
+                        not exist in
+                        a zone and indicate what RR types are present for an
+                        existing name.
+                        Used in original DNSSEC; replaced by NSEC in
+                        DNSSECbis.
+                        Described in RFC 2535.
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p>
+                        PTR
+                      </p>
+                    </td>
+<td>
+                      <p>
+                        A pointer to another part of the domain
+                        name space.  Described in RFC 1035.
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p>
+                        PX
+                      </p>
+                    </td>
+<td>
+                      <p>
+                        Provides mappings between RFC 822 and X.400
+                        addresses.  Described in RFC 2163.
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p>
+                        RP
+                      </p>
+                    </td>
+<td>
+                      <p>
+                        Information on persons responsible
+                        for the domain.  Experimental.  Described in RFC 1183.
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p>
+                        RRSIG
+                      </p>
+                    </td>
+<td>
+                      <p>
+                        Contains DNSSECbis signature data.  Described
+                        in RFC 4034.
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p>
+                        RT
+                      </p>
+                    </td>
+<td>
+                      <p>
+                        Route-through binding for hosts that
+                        do not have their own direct wide area network
+                        addresses.
+                        Experimental.  Described in RFC 1183.
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p>
+                        SIG
+                      </p>
+                    </td>
+<td>
+                      <p>
+                        Contains DNSSEC signature data.  Used in
+                        original DNSSEC; replaced by RRSIG in
+                        DNSSECbis, but still used for SIG(0).
+                        Described in RFCs 2535 and 2931.
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p>
+                        SOA
+                      </p>
+                    </td>
+<td>
+                      <p>
+                        Identifies the start of a zone of authority.
+                        Described in RFC 1035.
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p>
+                        SRV
+                      </p>
+                    </td>
+<td>
+                      <p>
+                        Information about well known network
+                        services (replaces WKS).  Described in RFC 2782.
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p>
+                        TXT
+                      </p>
+                    </td>
+<td>
+                      <p>
+                        Text records.  Described in RFC 1035.
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p>
+                        WKS
+                      </p>
+                    </td>
+<td>
+                      <p>
+                        Information about which well known
+                        network services, such as SMTP, that a domain
+                        supports. Historical.
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p>
+                        X25
+                      </p>
+                    </td>
+<td>
+                      <p>
+                        Representation of X.25 network addresses.
+                        Experimental.  Described in RFC 1183.
+                      </p>
+                    </td>
+</tr>
+</tbody>
+</table></div>
+<p>
+              The following <span class="emphasis"><em>classes</em></span> of resource records
+              are currently valid in the DNS:
+            </p>
+<div class="informaltable"><table border="1">
+<colgroup>
+<col>
+<col>
+</colgroup>
+<tbody>
+<tr>
+<td>
+                      <p>
+                        IN
+                      </p>
+                    </td>
+<td>
+                      <p>
+                        The Internet.
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p>
+                        CH
+                      </p>
+                    </td>
+<td>
+                      <p>
+                        Chaosnet, a LAN protocol created at MIT in the
+                        mid-1970s.
+                        Rarely used for its historical purpose, but reused for
+                        BIND's
+                        built-in server information zones, e.g.,
+                        <code class="literal">version.bind</code>.
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p>
+                        HS
+                      </p>
+                    </td>
+<td>
+                      <p>
+                        Hesiod, an information service
+                        developed by MIT's Project Athena. It is used to share
+                        information
+                        about various systems databases, such as users,
+                        groups, printers
+                        and so on.
+                      </p>
+                    </td>
+</tr>
+</tbody>
+</table></div>
+<p>
+              The owner name is often implicit, rather than forming an
+              integral
+              part of the RR.  For example, many name servers internally form
+              tree
+              or hash structures for the name space, and chain RRs off nodes.
+              The remaining RR parts are the fixed header (type, class, TTL)
+              which is consistent for all RRs, and a variable part (RDATA)
+              that
+              fits the needs of the resource being described.
+            </p>
+<p>
+              The meaning of the TTL field is a time limit on how long an
+              RR can be kept in a cache.  This limit does not apply to
+              authoritative
+              data in zones; it is also timed out, but by the refreshing
+              policies
+              for the zone.  The TTL is assigned by the administrator for the
+              zone where the data originates.  While short TTLs can be used to
+              minimize caching, and a zero TTL prohibits caching, the
+              realities
+              of Internet performance suggest that these times should be on
+              the
+              order of days for the typical host.  If a change can be
+              anticipated,
+              the TTL can be reduced prior to the change to minimize
+              inconsistency
+              during the change, and then increased back to its former value
+              following
+              the change.
+            </p>
+<p>
+              The data in the RDATA section of RRs is carried as a combination
+              of binary strings and domain names.  The domain names are
+              frequently
+              used as "pointers" to other data in the DNS.
+            </p>
+</div>
+<div class="sect3" lang="en">
+<div class="titlepage"><div><div><h4 class="title">
+<a name="id2590513"></a>Textual expression of RRs</h4></div></div></div>
+<p>
+              RRs are represented in binary form in the packets of the DNS
+              protocol, and are usually represented in highly encoded form
+              when
+              stored in a name server or resolver.  In the examples provided
+              in
+              RFC 1034, a style similar to that used in master files was
+              employed
+              in order to show the contents of RRs.  In this format, most RRs
+              are shown on a single line, although continuation lines are
+              possible
+              using parentheses.
+            </p>
+<p>
+              The start of the line gives the owner of the RR.  If a line
+              begins with a blank, then the owner is assumed to be the same as
+              that of the previous RR.  Blank lines are often included for
+              readability.
+            </p>
+<p>
+              Following the owner, we list the TTL, type, and class of the
+              RR.  Class and type use the mnemonics defined above, and TTL is
+              an integer before the type field.  In order to avoid ambiguity
+              in
+              parsing, type and class mnemonics are disjoint, TTLs are
+              integers,
+              and the type mnemonic is always last. The IN class and TTL
+              values
+              are often omitted from examples in the interests of clarity.
+            </p>
+<p>
+              The resource data or RDATA section of the RR are given using
+              knowledge of the typical representation for the data.
+            </p>
+<p>
+              For example, we might show the RRs carried in a message as:
+            </p>
+<div class="informaltable"><table border="1">
+<colgroup>
+<col>
+<col>
+<col>
+</colgroup>
+<tbody>
+<tr>
+<td>
+                      <p>
+                        <code class="literal">ISI.EDU.</code>
+                      </p>
+                    </td>
+<td>
+                      <p>
+                        <code class="literal">MX</code>
+                      </p>
+                    </td>
+<td>
+                      <p>
+                        <code class="literal">10 VENERA.ISI.EDU.</code>
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p></p>
+                    </td>
+<td>
+                      <p>
+                        <code class="literal">MX</code>
+                      </p>
+                    </td>
+<td>
+                      <p>
+                        <code class="literal">10 VAXA.ISI.EDU</code>
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p>
+                        <code class="literal">VENERA.ISI.EDU</code>
+                      </p>
+                    </td>
+<td>
+                      <p>
+                        <code class="literal">A</code>
+                      </p>
+                    </td>
+<td>
+                      <p>
+                        <code class="literal">128.9.0.32</code>
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p></p>
+                    </td>
+<td>
+                      <p>
+                        <code class="literal">A</code>
+                      </p>
+                    </td>
+<td>
+                      <p>
+                        <code class="literal">10.1.0.52</code>
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p>
+                        <code class="literal">VAXA.ISI.EDU</code>
+                      </p>
+                    </td>
+<td>
+                      <p>
+                        <code class="literal">A</code>
+                      </p>
+                    </td>
+<td>
+                      <p>
+                        <code class="literal">10.2.0.27</code>
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p></p>
+                    </td>
+<td>
+                      <p>
+                        <code class="literal">A</code>
+                      </p>
+                    </td>
+<td>
+                      <p>
+                        <code class="literal">128.9.0.33</code>
+                      </p>
+                    </td>
+</tr>
+</tbody>
+</table></div>
+<p>
+              The MX RRs have an RDATA section which consists of a 16-bit
+              number followed by a domain name.  The address RRs use a
+              standard
+              IP address format to contain a 32-bit internet address.
+            </p>
+<p>
+              The above example shows six RRs, with two RRs at each of three
+              domain names.
+            </p>
+<p>
+              Similarly we might see:
+            </p>
+<div class="informaltable"><table border="1">
+<colgroup>
+<col>
+<col>
+<col>
+</colgroup>
+<tbody>
+<tr>
+<td>
+                      <p>
+                        <code class="literal">XX.LCS.MIT.EDU.</code>
+                      </p>
+                    </td>
+<td>
+                      <p>
+                        <code class="literal">IN A</code>
+                      </p>
+                    </td>
+<td>
+                      <p>
+                        <code class="literal">10.0.0.44</code>
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td> </td>
+<td>
+                      <p>
+                        <code class="literal">CH A</code>
+                      </p>
+                    </td>
+<td>
+                      <p>
+                        <code class="literal">MIT.EDU. 2420</code>
+                      </p>
+                    </td>
+</tr>
+</tbody>
+</table></div>
+<p>
+              This example shows two addresses for
+              <code class="literal">XX.LCS.MIT.EDU</code>, each of a different class.
+            </p>
+</div>
+</div>
+<div class="sect2" lang="en">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="id2591101"></a>Discussion of MX Records</h3></div></div></div>
+<p>
+            As described above, domain servers store information as a
+            series of resource records, each of which contains a particular
+            piece of information about a given domain name (which is usually,
+            but not always, a host). The simplest way to think of a RR is as
+            a typed pair of data, a domain name matched with a relevant datum,
+            and stored with some additional type information to help systems
+            determine when the RR is relevant.
+          </p>
+<p>
+            MX records are used to control delivery of email. The data
+            specified in the record is a priority and a domain name. The
+            priority
+            controls the order in which email delivery is attempted, with the
+            lowest number first. If two priorities are the same, a server is
+            chosen randomly. If no servers at a given priority are responding,
+            the mail transport agent will fall back to the next largest
+            priority.
+            Priority numbers do not have any absolute meaning &#8212; they are
+            relevant
+            only respective to other MX records for that domain name. The
+            domain
+            name given is the machine to which the mail will be delivered.
+            It <span class="emphasis"><em>must</em></span> have an associated address record
+            (A or AAAA) &#8212; CNAME is not sufficient.
+          </p>
+<p>
+            For a given domain, if there is both a CNAME record and an
+            MX record, the MX record is in error, and will be ignored.
+            Instead,
+            the mail will be delivered to the server specified in the MX
+            record
+            pointed to by the CNAME.
+          </p>
+<p>
+            For example:
+          </p>
+<div class="informaltable"><table border="1">
+<colgroup>
+<col>
+<col>
+<col>
+<col>
+<col>
+</colgroup>
+<tbody>
+<tr>
+<td>
+                    <p>
+                      <code class="literal">example.com.</code>
+                    </p>
+                  </td>
+<td>
+                    <p>
+                      <code class="literal">IN</code>
+                    </p>
+                  </td>
+<td>
+                    <p>
+                      <code class="literal">MX</code>
+                    </p>
+                  </td>
+<td>
+                    <p>
+                      <code class="literal">10</code>
+                    </p>
+                  </td>
+<td>
+                    <p>
+                      <code class="literal">mail.example.com.</code>
+                    </p>
+                  </td>
+</tr>
+<tr>
+<td>
+                    <p></p>
+                  </td>
+<td>
+                    <p>
+                      <code class="literal">IN</code>
+                    </p>
+                  </td>
+<td>
+                    <p>
+                      <code class="literal">MX</code>
+                    </p>
+                  </td>
+<td>
+                    <p>
+                      <code class="literal">10</code>
+                    </p>
+                  </td>
+<td>
+                    <p>
+                      <code class="literal">mail2.example.com.</code>
+                    </p>
+                  </td>
+</tr>
+<tr>
+<td>
+                    <p></p>
+                  </td>
+<td>
+                    <p>
+                      <code class="literal">IN</code>
+                    </p>
+                  </td>
+<td>
+                    <p>
+                      <code class="literal">MX</code>
+                    </p>
+                  </td>
+<td>
+                    <p>
+                      <code class="literal">20</code>
+                    </p>
+                  </td>
+<td>
+                    <p>
+                      <code class="literal">mail.backup.org.</code>
+                    </p>
+                  </td>
+</tr>
+<tr>
+<td>
+                    <p>
+                      <code class="literal">mail.example.com.</code>
+                    </p>
+                  </td>
+<td>
+                    <p>
+                      <code class="literal">IN</code>
+                    </p>
+                  </td>
+<td>
+                    <p>
+                      <code class="literal">A</code>
+                    </p>
+                  </td>
+<td>
+                    <p>
+                      <code class="literal">10.0.0.1</code>
+                    </p>
+                  </td>
+<td>
+                    <p></p>
+                  </td>
+</tr>
+<tr>
+<td>
+                    <p>
+                      <code class="literal">mail2.example.com.</code>
+                    </p>
+                  </td>
+<td>
+                    <p>
+                      <code class="literal">IN</code>
+                    </p>
+                  </td>
+<td>
+                    <p>
+                      <code class="literal">A</code>
+                    </p>
+                  </td>
+<td>
+                    <p>
+                      <code class="literal">10.0.0.2</code>
+                    </p>
+                  </td>
+<td>
+                    <p></p>
+                  </td>
+</tr>
+</tbody>
+</table></div>
+<p>
+            Mail delivery will be attempted to <code class="literal">mail.example.com</code> and
+            <code class="literal">mail2.example.com</code> (in
+            any order), and if neither of those succeed, delivery to <code class="literal">mail.backup.org</code> will
+            be attempted.
+          </p>
+</div>
+<div class="sect2" lang="en">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="Setting_TTLs"></a>Setting TTLs</h3></div></div></div>
+<p>
+            The time-to-live of the RR field is a 32-bit integer represented
+            in units of seconds, and is primarily used by resolvers when they
+            cache RRs. The TTL describes how long a RR can be cached before it
+            should be discarded. The following three types of TTL are
+            currently
+            used in a zone file.
+          </p>
+<div class="informaltable"><table border="1">
+<colgroup>
+<col>
+<col>
+</colgroup>
+<tbody>
+<tr>
+<td>
+                    <p>
+                      SOA
+                    </p>
+                  </td>
+<td>
+                    <p>
+                      The last field in the SOA is the negative
+                      caching TTL. This controls how long other servers will
+                      cache no-such-domain
+                      (NXDOMAIN) responses from you.
+                    </p>
+                    <p>
+                      The maximum time for
+                      negative caching is 3 hours (3h).
+                    </p>
+                  </td>
+</tr>
+<tr>
+<td>
+                    <p>
+                      $TTL
+                    </p>
+                  </td>
+<td>
+                    <p>
+                      The $TTL directive at the top of the
+                      zone file (before the SOA) gives a default TTL for every
+                      RR without
+                      a specific TTL set.
+                    </p>
+                  </td>
+</tr>
+<tr>
+<td>
+                    <p>
+                      RR TTLs
+                    </p>
+                  </td>
+<td>
+                    <p>
+                      Each RR can have a TTL as the second
+                      field in the RR, which will control how long other
+                      servers can cache
+                      the it.
+                    </p>
+                  </td>
+</tr>
+</tbody>
+</table></div>
+<p>
+            All of these TTLs default to units of seconds, though units
+            can be explicitly specified, for example, <code class="literal">1h30m</code>.
+          </p>
+</div>
+<div class="sect2" lang="en">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="id2591653"></a>Inverse Mapping in IPv4</h3></div></div></div>
+<p>
+            Reverse name resolution (that is, translation from IP address
+            to name) is achieved by means of the <span class="emphasis"><em>in-addr.arpa</em></span> domain
+            and PTR records. Entries in the in-addr.arpa domain are made in
+            least-to-most significant order, read left to right. This is the
+            opposite order to the way IP addresses are usually written. Thus,
+            a machine with an IP address of 10.1.2.3 would have a
+            corresponding
+            in-addr.arpa name of
+            3.2.1.10.in-addr.arpa. This name should have a PTR resource record
+            whose data field is the name of the machine or, optionally,
+            multiple
+            PTR records if the machine has more than one name. For example,
+            in the [<span class="optional">example.com</span>] domain:
+          </p>
+<div class="informaltable"><table border="1">
+<colgroup>
+<col>
+<col>
+</colgroup>
+<tbody>
+<tr>
+<td>
+                    <p>
+                      <code class="literal">$ORIGIN</code>
+                    </p>
+                  </td>
+<td>
+                    <p>
+                      <code class="literal">2.1.10.in-addr.arpa</code>
+                    </p>
+                  </td>
+</tr>
+<tr>
+<td>
+                    <p>
+                      <code class="literal">3</code>
+                    </p>
+                  </td>
+<td>
+                    <p>
+                      <code class="literal">IN PTR foo.example.com.</code>
+                    </p>
+                  </td>
+</tr>
+</tbody>
+</table></div>
+<div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
+<h3 class="title">Note</h3>
+<p>
+              The <span><strong class="command">$ORIGIN</strong></span> lines in the examples
+              are for providing context to the examples only &#8212; they do not
+              necessarily
+              appear in the actual usage. They are only used here to indicate
+              that the example is relative to the listed origin.
+            </p>
+</div>
+</div>
+<div class="sect2" lang="en">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="id2591848"></a>Other Zone File Directives</h3></div></div></div>
+<p>
+            The Master File Format was initially defined in RFC 1035 and
+            has subsequently been extended. While the Master File Format
+            itself
+            is class independent all records in a Master File must be of the
+            same
+            class.
+          </p>
+<p>
+            Master File Directives include <span><strong class="command">$ORIGIN</strong></span>, <span><strong class="command">$INCLUDE</strong></span>,
+            and <span><strong class="command">$TTL.</strong></span>
+          </p>
+<div class="sect3" lang="en">
+<div class="titlepage"><div><div><h4 class="title">
+<a name="id2591870"></a>The <span><strong class="command">$ORIGIN</strong></span> Directive</h4></div></div></div>
+<p>
+              Syntax: <span><strong class="command">$ORIGIN</strong></span>
+              <em class="replaceable"><code>domain-name</code></em>
+              [<span class="optional"><em class="replaceable"><code>comment</code></em></span>]
+            </p>
+<p><span><strong class="command">$ORIGIN</strong></span>
+              sets the domain name that will be appended to any
+              unqualified records. When a zone is first read in there
+              is an implicit <span><strong class="command">$ORIGIN</strong></span>
+              &lt;<code class="varname">zone-name</code>&gt;<span><strong class="command">.</strong></span>
+              The current <span><strong class="command">$ORIGIN</strong></span> is appended to
+              the domain specified in the <span><strong class="command">$ORIGIN</strong></span>
+              argument if it is not absolute.
+            </p>
+<pre class="programlisting">
+$ORIGIN example.com.
+WWW     CNAME   MAIN-SERVER
+</pre>
+<p>
+              is equivalent to
+            </p>
+<pre class="programlisting">
+WWW.EXAMPLE.COM. CNAME MAIN-SERVER.EXAMPLE.COM.
+</pre>
+</div>
+<div class="sect3" lang="en">
+<div class="titlepage"><div><div><h4 class="title">
+<a name="id2592000"></a>The <span><strong class="command">$INCLUDE</strong></span> Directive</h4></div></div></div>
+<p>
+              Syntax: <span><strong class="command">$INCLUDE</strong></span>
+              <em class="replaceable"><code>filename</code></em>
+              [<span class="optional">
+<em class="replaceable"><code>origin</code></em> </span>]
+              [<span class="optional"> <em class="replaceable"><code>comment</code></em> </span>]
+            </p>
+<p>
+              Read and process the file <code class="filename">filename</code> as
+              if it were included into the file at this point.  If <span><strong class="command">origin</strong></span> is
+              specified the file is processed with <span><strong class="command">$ORIGIN</strong></span> set
+              to that value, otherwise the current <span><strong class="command">$ORIGIN</strong></span> is
+              used.
+            </p>
+<p>
+              The origin and the current domain name
+              revert to the values they had prior to the <span><strong class="command">$INCLUDE</strong></span> once
+              the file has been read.
+            </p>
+<div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
+<h3 class="title">Note</h3>
+<p>
+                RFC 1035 specifies that the current origin should be restored
+                after
+                an <span><strong class="command">$INCLUDE</strong></span>, but it is silent
+                on whether the current
+                domain name should also be restored.  BIND 9 restores both of
+                them.
+                This could be construed as a deviation from RFC 1035, a
+                feature, or both.
+              </p>
+</div>
+</div>
+<div class="sect3" lang="en">
+<div class="titlepage"><div><div><h4 class="title">
+<a name="id2592069"></a>The <span><strong class="command">$TTL</strong></span> Directive</h4></div></div></div>
+<p>
+              Syntax: <span><strong class="command">$TTL</strong></span>
+              <em class="replaceable"><code>default-ttl</code></em>
+              [<span class="optional">
+<em class="replaceable"><code>comment</code></em> </span>]
+            </p>
+<p>
+              Set the default Time To Live (TTL) for subsequent records
+              with undefined TTLs. Valid TTLs are of the range 0-2147483647
+              seconds.
+            </p>
+<p><span><strong class="command">$TTL</strong></span>
+               is defined in RFC 2308.
+            </p>
+</div>
+</div>
+<div class="sect2" lang="en">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="id2592173"></a><acronym class="acronym">BIND</acronym> Master File Extension: the  <span><strong class="command">$GENERATE</strong></span> Directive</h3></div></div></div>
+<p>
+            Syntax: <span><strong class="command">$GENERATE</strong></span>
+            <em class="replaceable"><code>range</code></em>
+            <em class="replaceable"><code>lhs</code></em>
+            [<span class="optional"><em class="replaceable"><code>ttl</code></em></span>]
+            [<span class="optional"><em class="replaceable"><code>class</code></em></span>]
+            <em class="replaceable"><code>type</code></em>
+            <em class="replaceable"><code>rhs</code></em>
+            [<span class="optional"><em class="replaceable"><code>comment</code></em></span>]
+          </p>
+<p><span><strong class="command">$GENERATE</strong></span>
+            is used to create a series of resource records that only
+            differ from each other by an
+            iterator. <span><strong class="command">$GENERATE</strong></span> can be used to
+            easily generate the sets of records required to support
+            sub /24 reverse delegations described in RFC 2317:
+            Classless IN-ADDR.ARPA delegation.
+          </p>
+<pre class="programlisting">$ORIGIN 0.0.192.IN-ADDR.ARPA.
+$GENERATE 1-2 0 NS SERVER$.EXAMPLE.
+$GENERATE 1-127 $ CNAME $.0</pre>
+<p>
+            is equivalent to
+          </p>
+<pre class="programlisting">0.0.0.192.IN-ADDR.ARPA NS SERVER1.EXAMPLE.
+0.0.0.192.IN-ADDR.ARPA. NS SERVER2.EXAMPLE.
+1.0.0.192.IN-ADDR.ARPA. CNAME 1.0.0.0.192.IN-ADDR.ARPA.
+2.0.0.192.IN-ADDR.ARPA. CNAME 2.0.0.0.192.IN-ADDR.ARPA.
+...
+127.0.0.192.IN-ADDR.ARPA. CNAME 127.0.0.0.192.IN-ADDR.ARPA.
+</pre>
+<div class="informaltable"><table border="1">
+<colgroup>
+<col>
+<col>
+</colgroup>
+<tbody>
+<tr>
+<td>
+                    <p><span><strong class="command">range</strong></span></p>
+                  </td>
+<td>
+                    <p>
+                      This can be one of two forms: start-stop
+                      or start-stop/step. If the first form is used, then step
+                      is set to
+                      1. All of start, stop and step must be positive.
+                    </p>
+                  </td>
+</tr>
+<tr>
+<td>
+                    <p><span><strong class="command">lhs</strong></span></p>
+                  </td>
+<td>
+                    <p>This
+                      describes the owner name of the resource records
+                      to be created.  Any single <span><strong class="command">$</strong></span>
+                      (dollar sign)
+                      symbols within the <span><strong class="command">lhs</strong></span> side
+                      are replaced by the iterator value.
+
+                      To get a $ in the output, you need to escape the
+                      <span><strong class="command">$</strong></span> using a backslash
+                      <span><strong class="command">\</strong></span>,
+                      e.g. <span><strong class="command">\$</strong></span>. The
+                      <span><strong class="command">$</strong></span> may optionally be followed
+                      by modifiers which change the offset from the
+                      iterator, field width and base.
+
+                      Modifiers are introduced by a
+                      <span><strong class="command">{</strong></span> (left brace) immediately following the
+                      <span><strong class="command">$</strong></span> as
+                      <span><strong class="command">${offset[,width[,base]]}</strong></span>.
+                      For example, <span><strong class="command">${-20,3,d}</strong></span>
+                      subtracts 20 from the current value, prints the
+                      result as a decimal in a zero-padded field of
+                      width 3.
+
+                      Available output forms are decimal
+                      (<span><strong class="command">d</strong></span>), octal
+                      (<span><strong class="command">o</strong></span>) and hexadecimal
+                      (<span><strong class="command">x</strong></span> or <span><strong class="command">X</strong></span>
+                      for uppercase).  The default modifier is
+                      <span><strong class="command">${0,0,d}</strong></span>.  If the
+                      <span><strong class="command">lhs</strong></span> is not absolute, the
+                      current <span><strong class="command">$ORIGIN</strong></span> is appended
+                      to the name.
+                    </p>
+                    <p>
+                      For compatibility with earlier versions, <span><strong class="command">$$</strong></span> is still
+                      recognized as indicating a literal $ in the output.
+                    </p>
+                  </td>
+</tr>
+<tr>
+<td>
+                    <p><span><strong class="command">ttl</strong></span></p>
+                  </td>
+<td>
+                    <p>
+                      Specifies the time-to-live of the generated records. If
+                      not specified this will be inherited using the
+                      normal ttl inheritance rules.
+                    </p>
+                    <p><span><strong class="command">class</strong></span>
+                      and <span><strong class="command">ttl</strong></span> can be
+                      entered in either order.
+                    </p>
+                  </td>
+</tr>
+<tr>
+<td>
+                    <p><span><strong class="command">class</strong></span></p>
+                  </td>
+<td>
+                    <p>
+                      Specifies the class of the generated records.
+                      This must match the zone class if it is
+                      specified.
+                    </p>
+                    <p><span><strong class="command">class</strong></span>
+                      and <span><strong class="command">ttl</strong></span> can be
+                      entered in either order.
+                    </p>
+                  </td>
+</tr>
+<tr>
+<td>
+                    <p><span><strong class="command">type</strong></span></p>
+                  </td>
+<td>
+                    <p>
+                      At present the only supported types are
+                      PTR, CNAME, DNAME, A, AAAA and NS.
+                    </p>
+                  </td>
+</tr>
+<tr>
+<td>
+                    <p><span><strong class="command">rhs</strong></span></p>
+                  </td>
+<td>
+                    <p>
+                      <span><strong class="command">rhs</strong></span> is a domain name. It is processed
+                      similarly to lhs.
+                    </p>
+                  </td>
+</tr>
+</tbody>
+</table></div>
+<p>
+            The <span><strong class="command">$GENERATE</strong></span> directive is a <acronym class="acronym">BIND</acronym> extension
+            and not part of the standard zone file format.
+          </p>
+<p>
+            BIND 8 does not support the optional TTL and CLASS fields.
+          </p>
+</div>
+<div class="sect2" lang="en">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="zonefile_format"></a>Additional File Formats</h3></div></div></div>
+<p>
+            In addition to the standard textual format, BIND 9
+            supports the ability to read or dump to zone files in
+            other formats.  The <code class="constant">raw</code> format is
+            currently available as an additional format.  It is a
+            binary format representing BIND 9's internal data
+            structure directly, thereby remarkably improving the
+            loading time.
+          </p>
+<p>
+            For a primary server, a zone file in the
+            <code class="constant">raw</code> format is expected to be
+            generated from a textual zone file by the
+            <span><strong class="command">named-compilezone</strong></span> command.  For a
+            secondary server or for a dynamic zone, it is automatically
+            generated (if this format is specified by the
+            <span><strong class="command">masterfile-format</strong></span> option) when
+            <span><strong class="command">named</strong></span> dumps the zone contents after
+            zone transfer or when applying prior updates.
+          </p>
+<p>
+            If a zone file in a binary format needs manual modification,
+            it first must be converted to a textual form by the
+            <span><strong class="command">named-compilezone</strong></span> command.  All
+            necessary modification should go to the text file, which
+            should then be converted to the binary form by the
+            <span><strong class="command">named-compilezone</strong></span> command again.
+          </p>
+<p>
+             Although the <code class="constant">raw</code> format uses the
+             network byte order and avoids architecture-dependent
+             data alignment so that it is as much portable as
+             possible, it is primarily expected to be used inside
+             the same single system.  In order to export a zone
+             file in the <code class="constant">raw</code> format or make a
+             portable backup of the file, it is recommended to
+             convert the file to the standard textual representation.
+          </p>
+</div>
+</div>
+</div>
+<div class="navfooter">
+<hr>
+<table width="100%" summary="Navigation footer">
+<tr>
+<td width="40%" align="left">
+<a accesskey="p" href="Bv9ARM.ch05.html">Prev</a> </td>
+<td width="20%" align="center"> </td>
+<td width="40%" align="right"> <a accesskey="n" href="Bv9ARM.ch07.html">Next</a>
+</td>
+</tr>
+<tr>
+<td width="40%" align="left" valign="top">Chapter 5. The <acronym class="acronym">BIND</acronym> 9 Lightweight Resolver </td>
+<td width="20%" align="center"><a accesskey="h" href="Bv9ARM.html">Home</a></td>
+<td width="40%" align="right" valign="top"> Chapter 7. <acronym class="acronym">BIND</acronym> 9 Security Considerations</td>
+</tr>
+</table>
+</div>
+</body>
+</html>
diff --git a/doc/arm/Bv9ARM.ch07.html b/doc/arm/Bv9ARM.ch07.html
new file mode 100644
index 0000000..96acfe6
--- /dev/null
+++ b/doc/arm/Bv9ARM.ch07.html
@@ -0,0 +1,253 @@
+<!--
+ - Copyright (C) 2004-2007 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2000-2003 Internet Software Consortium.
+ - 
+ - Permission to use, copy, modify, and distribute this software for any
+ - purpose with or without fee is hereby granted, provided that the above
+ - copyright notice and this permission notice appear in all copies.
+ - 
+ - THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
+ - REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
+ - AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
+ - INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
+ - LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
+ - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
+ - PERFORMANCE OF THIS SOFTWARE.
+-->
+<!-- $Id: Bv9ARM.ch07.html,v 1.75.18.63 2007/10/31 01:35:59 marka Exp $ -->
+<html>
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
+<title>Chapter 7. BIND 9 Security Considerations</title>
+<meta name="generator" content="DocBook XSL Stylesheets V1.71.1">
+<link rel="start" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual">
+<link rel="up" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual">
+<link rel="prev" href="Bv9ARM.ch06.html" title="Chapter 6. BIND 9 Configuration Reference">
+<link rel="next" href="Bv9ARM.ch08.html" title="Chapter 8. Troubleshooting">
+</head>
+<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
+<div class="navheader">
+<table width="100%" summary="Navigation header">
+<tr><th colspan="3" align="center">Chapter 7. <acronym class="acronym">BIND</acronym> 9 Security Considerations</th></tr>
+<tr>
+<td width="20%" align="left">
+<a accesskey="p" href="Bv9ARM.ch06.html">Prev</a> </td>
+<th width="60%" align="center"> </th>
+<td width="20%" align="right"> <a accesskey="n" href="Bv9ARM.ch08.html">Next</a>
+</td>
+</tr>
+</table>
+<hr>
+</div>
+<div class="chapter" lang="en">
+<div class="titlepage"><div><div><h2 class="title">
+<a name="Bv9ARM.ch07"></a>Chapter 7. <acronym class="acronym">BIND</acronym> 9 Security Considerations</h2></div></div></div>
+<div class="toc">
+<p><b>Table of Contents</b></p>
+<dl>
+<dt><span class="sect1"><a href="Bv9ARM.ch07.html#Access_Control_Lists">Access Control Lists</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch07.html#id2592714"><span><strong class="command">Chroot</strong></span> and <span><strong class="command">Setuid</strong></span></a></span></dt>
+<dd><dl>
+<dt><span class="sect2"><a href="Bv9ARM.ch07.html#id2592791">The <span><strong class="command">chroot</strong></span> Environment</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch07.html#id2592851">Using the <span><strong class="command">setuid</strong></span> Function</a></span></dt>
+</dl></dd>
+<dt><span class="sect1"><a href="Bv9ARM.ch07.html#dynamic_update_security">Dynamic Update Security</a></span></dt>
+</dl>
+</div>
+<div class="sect1" lang="en">
+<div class="titlepage"><div><div><h2 class="title" style="clear: both">
+<a name="Access_Control_Lists"></a>Access Control Lists</h2></div></div></div>
+<p>
+          Access Control Lists (ACLs), are address match lists that
+          you can set up and nickname for future use in <span><strong class="command">allow-notify</strong></span>,
+          <span><strong class="command">allow-query</strong></span>, <span><strong class="command">allow-recursion</strong></span>,
+          <span><strong class="command">blackhole</strong></span>, <span><strong class="command">allow-transfer</strong></span>,
+          etc.
+        </p>
+<p>
+          Using ACLs allows you to have finer control over who can access
+          your name server, without cluttering up your config files with huge
+          lists of IP addresses.
+        </p>
+<p>
+          It is a <span class="emphasis"><em>good idea</em></span> to use ACLs, and to
+          control access to your server. Limiting access to your server by
+          outside parties can help prevent spoofing and denial of service (DoS) attacks against
+          your server.
+        </p>
+<p>
+          Here is an example of how to properly apply ACLs:
+        </p>
+<pre class="programlisting">
+// Set up an ACL named "bogusnets" that will block RFC1918 space
+// and some reserved space, which is commonly used in spoofing attacks.
+acl bogusnets {
+        0.0.0.0/8; 1.0.0.0/8; 2.0.0.0/8; 192.0.2.0/24; 224.0.0.0/3;
+        10.0.0.0/8; 172.16.0.0/12; 192.168.0.0/16;
+};
+
+// Set up an ACL called our-nets. Replace this with the real IP numbers.
+acl our-nets { x.x.x.x/24; x.x.x.x/21; };
+options {
+  ...
+  ...
+  allow-query { our-nets; };
+  allow-recursion { our-nets; };
+  ...
+  blackhole { bogusnets; };
+  ...
+};
+
+zone "example.com" {
+  type master;
+  file "m/example.com";
+  allow-query { any; };
+};
+</pre>
+<p>
+          This allows recursive queries of the server from the outside
+          unless recursion has been previously disabled.
+        </p>
+<p>
+          For more information on how to use ACLs to protect your server,
+          see the <span class="emphasis"><em>AUSCERT</em></span> advisory at:
+        </p>
+<p>
+          <a href="ftp://ftp.auscert.org.au/pub/auscert/advisory/AL-1999.004.dns_dos" target="_top">ftp://ftp.auscert.org.au/pub/auscert/advisory/AL-1999.004.dns_dos</a>
+        </p>
+</div>
+<div class="sect1" lang="en">
+<div class="titlepage"><div><div><h2 class="title" style="clear: both">
+<a name="id2592714"></a><span><strong class="command">Chroot</strong></span> and <span><strong class="command">Setuid</strong></span>
+</h2></div></div></div>
+<p>
+          On UNIX servers, it is possible to run <acronym class="acronym">BIND</acronym> in a <span class="emphasis"><em>chrooted</em></span> environment
+          (using the <span><strong class="command">chroot()</strong></span> function) by specifying the "<code class="option">-t</code>"
+          option. This can help improve system security by placing <acronym class="acronym">BIND</acronym> in
+          a "sandbox", which will limit the damage done if a server is
+          compromised.
+        </p>
+<p>
+          Another useful feature in the UNIX version of <acronym class="acronym">BIND</acronym> is the
+          ability to run the daemon as an unprivileged user ( <code class="option">-u</code> <em class="replaceable"><code>user</code></em> ).
+          We suggest running as an unprivileged user when using the <span><strong class="command">chroot</strong></span> feature.
+        </p>
+<p>
+          Here is an example command line to load <acronym class="acronym">BIND</acronym> in a <span><strong class="command">chroot</strong></span> sandbox,
+          <span><strong class="command">/var/named</strong></span>, and to run <span><strong class="command">named</strong></span> <span><strong class="command">setuid</strong></span> to
+          user 202:
+        </p>
+<p>
+          <strong class="userinput"><code>/usr/local/bin/named -u 202 -t /var/named</code></strong>
+        </p>
+<div class="sect2" lang="en">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="id2592791"></a>The <span><strong class="command">chroot</strong></span> Environment</h3></div></div></div>
+<p>
+            In order for a <span><strong class="command">chroot</strong></span> environment
+            to
+            work properly in a particular directory
+            (for example, <code class="filename">/var/named</code>),
+            you will need to set up an environment that includes everything
+            <acronym class="acronym">BIND</acronym> needs to run.
+            From <acronym class="acronym">BIND</acronym>'s point of view, <code class="filename">/var/named</code> is
+            the root of the filesystem.  You will need to adjust the values of
+            options like
+            like <span><strong class="command">directory</strong></span> and <span><strong class="command">pid-file</strong></span> to account
+            for this.
+          </p>
+<p>
+            Unlike with earlier versions of BIND, you typically will
+            <span class="emphasis"><em>not</em></span> need to compile <span><strong class="command">named</strong></span>
+            statically nor install shared libraries under the new root.
+            However, depending on your operating system, you may need
+            to set up things like
+            <code class="filename">/dev/zero</code>,
+            <code class="filename">/dev/random</code>,
+            <code class="filename">/dev/log</code>, and
+            <code class="filename">/etc/localtime</code>.
+          </p>
+</div>
+<div class="sect2" lang="en">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="id2592851"></a>Using the <span><strong class="command">setuid</strong></span> Function</h3></div></div></div>
+<p>
+            Prior to running the <span><strong class="command">named</strong></span> daemon,
+            use
+            the <span><strong class="command">touch</strong></span> utility (to change file
+            access and
+            modification times) or the <span><strong class="command">chown</strong></span>
+            utility (to
+            set the user id and/or group id) on files
+            to which you want <acronym class="acronym">BIND</acronym>
+            to write.
+          </p>
+<div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
+<h3 class="title">Note</h3>
+            Note that if the <span><strong class="command">named</strong></span> daemon is running as an
+            unprivileged user, it will not be able to bind to new restricted
+            ports if the server is reloaded.
+          </div>
+</div>
+</div>
+<div class="sect1" lang="en">
+<div class="titlepage"><div><div><h2 class="title" style="clear: both">
+<a name="dynamic_update_security"></a>Dynamic Update Security</h2></div></div></div>
+<p>
+          Access to the dynamic
+          update facility should be strictly limited.  In earlier versions of
+          <acronym class="acronym">BIND</acronym>, the only way to do this was
+          based on the IP
+          address of the host requesting the update, by listing an IP address
+          or
+          network prefix in the <span><strong class="command">allow-update</strong></span>
+          zone option.
+          This method is insecure since the source address of the update UDP
+          packet
+          is easily forged.  Also note that if the IP addresses allowed by the
+          <span><strong class="command">allow-update</strong></span> option include the
+          address of a slave
+          server which performs forwarding of dynamic updates, the master can
+          be
+          trivially attacked by sending the update to the slave, which will
+          forward it to the master with its own source IP address causing the
+          master to approve it without question.
+        </p>
+<p>
+          For these reasons, we strongly recommend that updates be
+          cryptographically authenticated by means of transaction signatures
+          (TSIG).  That is, the <span><strong class="command">allow-update</strong></span>
+          option should
+          list only TSIG key names, not IP addresses or network
+          prefixes. Alternatively, the new <span><strong class="command">update-policy</strong></span>
+          option can be used.
+        </p>
+<p>
+          Some sites choose to keep all dynamically-updated DNS data
+          in a subdomain and delegate that subdomain to a separate zone. This
+          way, the top-level zone containing critical data such as the IP
+          addresses
+          of public web and mail servers need not allow dynamic update at
+          all.
+        </p>
+</div>
+</div>
+<div class="navfooter">
+<hr>
+<table width="100%" summary="Navigation footer">
+<tr>
+<td width="40%" align="left">
+<a accesskey="p" href="Bv9ARM.ch06.html">Prev</a> </td>
+<td width="20%" align="center"> </td>
+<td width="40%" align="right"> <a accesskey="n" href="Bv9ARM.ch08.html">Next</a>
+</td>
+</tr>
+<tr>
+<td width="40%" align="left" valign="top">Chapter 6. <acronym class="acronym">BIND</acronym> 9 Configuration Reference </td>
+<td width="20%" align="center"><a accesskey="h" href="Bv9ARM.html">Home</a></td>
+<td width="40%" align="right" valign="top"> Chapter 8. Troubleshooting</td>
+</tr>
+</table>
+</div>
+</body>
+</html>
diff --git a/doc/arm/Bv9ARM.ch08.html b/doc/arm/Bv9ARM.ch08.html
new file mode 100644
index 0000000..a475378
--- /dev/null
+++ b/doc/arm/Bv9ARM.ch08.html
@@ -0,0 +1,139 @@
+<!--
+ - Copyright (C) 2004-2007 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2000-2003 Internet Software Consortium.
+ - 
+ - Permission to use, copy, modify, and distribute this software for any
+ - purpose with or without fee is hereby granted, provided that the above
+ - copyright notice and this permission notice appear in all copies.
+ - 
+ - THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
+ - REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
+ - AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
+ - INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
+ - LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
+ - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
+ - PERFORMANCE OF THIS SOFTWARE.
+-->
+<!-- $Id: Bv9ARM.ch08.html,v 1.75.18.64 2007/10/31 01:35:59 marka Exp $ -->
+<html>
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
+<title>Chapter 8. Troubleshooting</title>
+<meta name="generator" content="DocBook XSL Stylesheets V1.71.1">
+<link rel="start" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual">
+<link rel="up" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual">
+<link rel="prev" href="Bv9ARM.ch07.html" title="Chapter 7. BIND 9 Security Considerations">
+<link rel="next" href="Bv9ARM.ch09.html" title="Appendix A. Appendices">
+</head>
+<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
+<div class="navheader">
+<table width="100%" summary="Navigation header">
+<tr><th colspan="3" align="center">Chapter 8. Troubleshooting</th></tr>
+<tr>
+<td width="20%" align="left">
+<a accesskey="p" href="Bv9ARM.ch07.html">Prev</a> </td>
+<th width="60%" align="center"> </th>
+<td width="20%" align="right"> <a accesskey="n" href="Bv9ARM.ch09.html">Next</a>
+</td>
+</tr>
+</table>
+<hr>
+</div>
+<div class="chapter" lang="en">
+<div class="titlepage"><div><div><h2 class="title">
+<a name="Bv9ARM.ch08"></a>Chapter 8. Troubleshooting</h2></div></div></div>
+<div class="toc">
+<p><b>Table of Contents</b></p>
+<dl>
+<dt><span class="sect1"><a href="Bv9ARM.ch08.html#id2592999">Common Problems</a></span></dt>
+<dd><dl><dt><span class="sect2"><a href="Bv9ARM.ch08.html#id2593004">It's not working; how can I figure out what's wrong?</a></span></dt></dl></dd>
+<dt><span class="sect1"><a href="Bv9ARM.ch08.html#id2593016">Incrementing and Changing the Serial Number</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch08.html#id2593033">Where Can I Get Help?</a></span></dt>
+</dl>
+</div>
+<div class="sect1" lang="en">
+<div class="titlepage"><div><div><h2 class="title" style="clear: both">
+<a name="id2592999"></a>Common Problems</h2></div></div></div>
+<div class="sect2" lang="en">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="id2593004"></a>It's not working; how can I figure out what's wrong?</h3></div></div></div>
+<p>
+            The best solution to solving installation and
+            configuration issues is to take preventative measures by setting
+            up logging files beforehand. The log files provide a
+            source of hints and information that can be used to figure out
+            what went wrong and how to fix the problem.
+          </p>
+</div>
+</div>
+<div class="sect1" lang="en">
+<div class="titlepage"><div><div><h2 class="title" style="clear: both">
+<a name="id2593016"></a>Incrementing and Changing the Serial Number</h2></div></div></div>
+<p>
+          Zone serial numbers are just numbers &#8212; they aren't
+          date related.  A lot of people set them to a number that
+          represents a date, usually of the form YYYYMMDDRR.
+          Occasionally they will make a mistake and set them to a
+          "date in the future" then try to correct them by setting
+          them to the "current date".  This causes problems because
+          serial numbers are used to indicate that a zone has been
+          updated.  If the serial number on the slave server is
+          lower than the serial number on the master, the slave
+          server will attempt to update its copy of the zone.
+        </p>
+<p>
+          Setting the serial number to a lower number on the master
+          server than the slave server means that the slave will not perform
+          updates to its copy of the zone.
+        </p>
+<p>
+          The solution to this is to add 2147483647 (2^31-1) to the
+          number, reload the zone and make sure all slaves have updated to
+          the new zone serial number, then reset the number to what you want
+          it to be, and reload the zone again.
+        </p>
+</div>
+<div class="sect1" lang="en">
+<div class="titlepage"><div><div><h2 class="title" style="clear: both">
+<a name="id2593033"></a>Where Can I Get Help?</h2></div></div></div>
+<p>
+          The Internet Systems Consortium
+          (<acronym class="acronym">ISC</acronym>) offers a wide range
+          of support and service agreements for <acronym class="acronym">BIND</acronym> and <acronym class="acronym">DHCP</acronym> servers. Four
+          levels of premium support are available and each level includes
+          support for all <acronym class="acronym">ISC</acronym> programs,
+          significant discounts on products
+          and training, and a recognized priority on bug fixes and
+          non-funded feature requests. In addition, <acronym class="acronym">ISC</acronym> offers a standard
+          support agreement package which includes services ranging from bug
+          fix announcements to remote support. It also includes training in
+          <acronym class="acronym">BIND</acronym> and <acronym class="acronym">DHCP</acronym>.
+        </p>
+<p>
+          To discuss arrangements for support, contact
+          <a href="mailto:info@isc.org" target="_top">info@isc.org</a> or visit the
+          <acronym class="acronym">ISC</acronym> web page at
+          <a href="http://www.isc.org/services/support/" target="_top">http://www.isc.org/services/support/</a>
+          to read more.
+        </p>
+</div>
+</div>
+<div class="navfooter">
+<hr>
+<table width="100%" summary="Navigation footer">
+<tr>
+<td width="40%" align="left">
+<a accesskey="p" href="Bv9ARM.ch07.html">Prev</a> </td>
+<td width="20%" align="center"> </td>
+<td width="40%" align="right"> <a accesskey="n" href="Bv9ARM.ch09.html">Next</a>
+</td>
+</tr>
+<tr>
+<td width="40%" align="left" valign="top">Chapter 7. <acronym class="acronym">BIND</acronym> 9 Security Considerations </td>
+<td width="20%" align="center"><a accesskey="h" href="Bv9ARM.html">Home</a></td>
+<td width="40%" align="right" valign="top"> Appendix A. Appendices</td>
+</tr>
+</table>
+</div>
+</body>
+</html>
diff --git a/doc/arm/Bv9ARM.ch09.html b/doc/arm/Bv9ARM.ch09.html
new file mode 100644
index 0000000..3c2e779
--- /dev/null
+++ b/doc/arm/Bv9ARM.ch09.html
@@ -0,0 +1,630 @@
+<!--
+ - Copyright (C) 2004-2007 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2000-2003 Internet Software Consortium.
+ - 
+ - Permission to use, copy, modify, and distribute this software for any
+ - purpose with or without fee is hereby granted, provided that the above
+ - copyright notice and this permission notice appear in all copies.
+ - 
+ - THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
+ - REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
+ - AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
+ - INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
+ - LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
+ - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
+ - PERFORMANCE OF THIS SOFTWARE.
+-->
+<!-- $Id: Bv9ARM.ch09.html,v 1.75.18.66 2007/10/31 01:35:59 marka Exp $ -->
+<html>
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
+<title>Appendix A. Appendices</title>
+<meta name="generator" content="DocBook XSL Stylesheets V1.71.1">
+<link rel="start" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual">
+<link rel="up" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual">
+<link rel="prev" href="Bv9ARM.ch08.html" title="Chapter 8. Troubleshooting">
+<link rel="next" href="Bv9ARM.ch10.html" title="Manual pages">
+</head>
+<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
+<div class="navheader">
+<table width="100%" summary="Navigation header">
+<tr><th colspan="3" align="center">Appendix A. Appendices</th></tr>
+<tr>
+<td width="20%" align="left">
+<a accesskey="p" href="Bv9ARM.ch08.html">Prev</a> </td>
+<th width="60%" align="center"> </th>
+<td width="20%" align="right"> <a accesskey="n" href="Bv9ARM.ch10.html">Next</a>
+</td>
+</tr>
+</table>
+<hr>
+</div>
+<div class="appendix" lang="en">
+<div class="titlepage"><div><div><h2 class="title">
+<a name="Bv9ARM.ch09"></a>Appendix A. Appendices</h2></div></div></div>
+<div class="toc">
+<p><b>Table of Contents</b></p>
+<dl>
+<dt><span class="sect1"><a href="Bv9ARM.ch09.html#id2593300">Acknowledgments</a></span></dt>
+<dd><dl><dt><span class="sect2"><a href="Bv9ARM.ch09.html#historical_dns_information">A Brief History of the <acronym class="acronym">DNS</acronym> and <acronym class="acronym">BIND</acronym></a></span></dt></dl></dd>
+<dt><span class="sect1"><a href="Bv9ARM.ch09.html#id2593472">General <acronym class="acronym">DNS</acronym> Reference Information</a></span></dt>
+<dd><dl><dt><span class="sect2"><a href="Bv9ARM.ch09.html#ipv6addresses">IPv6 addresses (AAAA)</a></span></dt></dl></dd>
+<dt><span class="sect1"><a href="Bv9ARM.ch09.html#bibliography">Bibliography (and Suggested Reading)</a></span></dt>
+<dd><dl>
+<dt><span class="sect2"><a href="Bv9ARM.ch09.html#rfcs">Request for Comments (RFCs)</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch09.html#internet_drafts">Internet Drafts</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch09.html#id2596683">Other Documents About <acronym class="acronym">BIND</acronym></a></span></dt>
+</dl></dd>
+</dl>
+</div>
+<div class="sect1" lang="en">
+<div class="titlepage"><div><div><h2 class="title" style="clear: both">
+<a name="id2593300"></a>Acknowledgments</h2></div></div></div>
+<div class="sect2" lang="en">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="historical_dns_information"></a>A Brief History of the <acronym class="acronym">DNS</acronym> and <acronym class="acronym">BIND</acronym>
+</h3></div></div></div>
+<p>
+            Although the "official" beginning of the Domain Name
+            System occurred in 1984 with the publication of RFC 920, the
+            core of the new system was described in 1983 in RFCs 882 and
+            883. From 1984 to 1987, the ARPAnet (the precursor to today's
+            Internet) became a testbed of experimentation for developing the
+            new naming/addressing scheme in a rapidly expanding,
+            operational network environment.  New RFCs were written and
+            published in 1987 that modified the original documents to
+            incorporate improvements based on the working model. RFC 1034,
+            "Domain Names-Concepts and Facilities", and RFC 1035, "Domain
+            Names-Implementation and Specification" were published and
+            became the standards upon which all <acronym class="acronym">DNS</acronym> implementations are
+            built.
+          </p>
+<p>
+            The first working domain name server, called "Jeeves", was
+            written in 1983-84 by Paul Mockapetris for operation on DEC
+            Tops-20
+            machines located at the University of Southern California's
+            Information
+            Sciences Institute (USC-ISI) and SRI International's Network
+            Information
+            Center (SRI-NIC). A <acronym class="acronym">DNS</acronym> server for
+            Unix machines, the Berkeley Internet
+            Name Domain (<acronym class="acronym">BIND</acronym>) package, was
+            written soon after by a group of
+            graduate students at the University of California at Berkeley
+            under
+            a grant from the US Defense Advanced Research Projects
+            Administration
+            (DARPA).
+          </p>
+<p>
+            Versions of <acronym class="acronym">BIND</acronym> through
+            4.8.3 were maintained by the Computer
+            Systems Research Group (CSRG) at UC Berkeley. Douglas Terry, Mark
+            Painter, David Riggle and Songnian Zhou made up the initial <acronym class="acronym">BIND</acronym>
+            project team. After that, additional work on the software package
+            was done by Ralph Campbell. Kevin Dunlap, a Digital Equipment
+            Corporation
+            employee on loan to the CSRG, worked on <acronym class="acronym">BIND</acronym> for 2 years, from 1985
+            to 1987. Many other people also contributed to <acronym class="acronym">BIND</acronym> development
+            during that time: Doug Kingston, Craig Partridge, Smoot
+            Carl-Mitchell,
+            Mike Muuss, Jim Bloom and Mike Schwartz. <acronym class="acronym">BIND</acronym> maintenance was subsequently
+            handled by Mike Karels and Øivind Kure.
+          </p>
+<p>
+            <acronym class="acronym">BIND</acronym> versions 4.9 and 4.9.1 were
+            released by Digital Equipment
+            Corporation (now Compaq Computer Corporation). Paul Vixie, then
+            a DEC employee, became <acronym class="acronym">BIND</acronym>'s
+            primary caretaker. He was assisted
+            by Phil Almquist, Robert Elz, Alan Barrett, Paul Albitz, Bryan
+            Beecher, Andrew
+            Partan, Andy Cherenson, Tom Limoncelli, Berthold Paffrath, Fuat
+            Baran, Anant Kumar, Art Harkin, Win Treese, Don Lewis, Christophe
+            Wolfhugel, and others.
+          </p>
+<p>
+            In 1994, <acronym class="acronym">BIND</acronym> version 4.9.2 was sponsored by
+            Vixie Enterprises. Paul
+            Vixie became <acronym class="acronym">BIND</acronym>'s principal
+            architect/programmer.
+          </p>
+<p>
+            <acronym class="acronym">BIND</acronym> versions from 4.9.3 onward
+            have been developed and maintained
+            by the Internet Systems Consortium and its predecessor,
+            the Internet Software Consortium,  with support being provided
+            by ISC's sponsors.
+          </p>
+<p>
+            As co-architects/programmers, Bob Halley and
+            Paul Vixie released the first production-ready version of
+            <acronym class="acronym">BIND</acronym> version 8 in May 1997.
+          </p>
+<p>
+            BIND version 9 was released in September 2000 and is a
+            major rewrite of nearly all aspects of the underlying
+            BIND architecture.
+          </p>
+<p>
+            BIND version 4 is officially deprecated and BIND version
+            8 development is considered maintenance-only in favor
+            of BIND version 9. No additional development is done
+            on BIND version 4 or BIND version 8 other than for
+            security-related patches.
+          </p>
+<p>
+            <acronym class="acronym">BIND</acronym> development work is made
+            possible today by the sponsorship
+            of several corporations, and by the tireless work efforts of
+            numerous individuals.
+          </p>
+</div>
+</div>
+<div class="sect1" lang="en">
+<div class="titlepage"><div><div><h2 class="title" style="clear: both">
+<a name="id2593472"></a>General <acronym class="acronym">DNS</acronym> Reference Information</h2></div></div></div>
+<div class="sect2" lang="en">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="ipv6addresses"></a>IPv6 addresses (AAAA)</h3></div></div></div>
+<p>
+            IPv6 addresses are 128-bit identifiers for interfaces and
+            sets of interfaces which were introduced in the <acronym class="acronym">DNS</acronym> to facilitate
+            scalable Internet routing. There are three types of addresses: <span class="emphasis"><em>Unicast</em></span>,
+            an identifier for a single interface;
+            <span class="emphasis"><em>Anycast</em></span>,
+            an identifier for a set of interfaces; and <span class="emphasis"><em>Multicast</em></span>,
+            an identifier for a set of interfaces. Here we describe the global
+            Unicast address scheme. For more information, see RFC 3587,
+            "Global Unicast Address Format."
+          </p>
+<p>
+            IPv6 unicast addresses consist of a
+            <span class="emphasis"><em>global routing prefix</em></span>, a
+            <span class="emphasis"><em>subnet identifier</em></span>, and an
+            <span class="emphasis"><em>interface identifier</em></span>.
+          </p>
+<p>
+            The global routing prefix is provided by the
+            upstream provider or ISP, and (roughly) corresponds to the
+            IPv4 <span class="emphasis"><em>network</em></span> section
+            of the address range.
+
+            The subnet identifier is for local subnetting, much the
+            same as subnetting an
+            IPv4 /16 network into /24 subnets.
+
+            The interface identifier is the address of an individual
+            interface on a given network; in IPv6, addresses belong to
+            interfaces rather than to machines.
+          </p>
+<p>
+            The subnetting capability of IPv6 is much more flexible than
+            that of IPv4: subnetting can be carried out on bit boundaries,
+            in much the same way as Classless InterDomain Routing
+            (CIDR), and the DNS PTR representation ("nibble" format)
+            makes setting up reverse zones easier.
+          </p>
+<p>
+            The Interface Identifier must be unique on the local link,
+            and is usually generated automatically by the IPv6
+            implementation, although it is usually possible to
+            override the default setting if necessary.  A typical IPv6
+            address might look like:
+            <span><strong class="command">2001:db8:201:9:a00:20ff:fe81:2b32</strong></span>
+          </p>
+<p>
+            IPv6 address specifications often contain long strings
+            of zeros, so the architects have included a shorthand for
+            specifying
+            them. The double colon (`::') indicates the longest possible
+            string
+            of zeros that can fit, and can be used only once in an address.
+          </p>
+</div>
+</div>
+<div class="sect1" lang="en">
+<div class="titlepage"><div><div><h2 class="title" style="clear: both">
+<a name="bibliography"></a>Bibliography (and Suggested Reading)</h2></div></div></div>
+<div class="sect2" lang="en">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="rfcs"></a>Request for Comments (RFCs)</h3></div></div></div>
+<p>
+            Specification documents for the Internet protocol suite, including
+            the <acronym class="acronym">DNS</acronym>, are published as part of
+            the Request for Comments (RFCs)
+            series of technical notes. The standards themselves are defined
+            by the Internet Engineering Task Force (IETF) and the Internet
+            Engineering Steering Group (IESG). RFCs can be obtained online via FTP at:
+          </p>
+<p>
+            <a href="ftp://www.isi.edu/in-notes/" target="_top">
+              ftp://www.isi.edu/in-notes/RFC<em class="replaceable"><code>xxxx</code></em>.txt
+            </a>
+          </p>
+<p>
+            (where <em class="replaceable"><code>xxxx</code></em> is
+            the number of the RFC). RFCs are also available via the Web at:
+          </p>
+<p>
+            <a href="http://www.ietf.org/rfc/" target="_top">http://www.ietf.org/rfc/</a>.
+          </p>
+<div class="bibliography">
+<div class="titlepage"><div><div><h4 class="title">
+<a name="id2593659"></a>Bibliography</h4></div></div></div>
+<div class="bibliodiv">
+<h3 class="title">Standards</h3>
+<div class="biblioentry">
+<a name="id2593670"></a><p>[<abbr class="abbrev">RFC974</abbr>] <span class="author"><span class="firstname">C.</span> <span class="surname">Partridge</span>. </span><span class="title"><i>Mail Routing and the Domain System</i>. </span><span class="pubdate">January 1986. </span></p>
+</div>
+<div class="biblioentry">
+<a name="id2593693"></a><p>[<abbr class="abbrev">RFC1034</abbr>] <span class="author"><span class="firstname">P.V.</span> <span class="surname">Mockapetris</span>. </span><span class="title"><i>Domain Names &#8212; Concepts and Facilities</i>. </span><span class="pubdate">November 1987. </span></p>
+</div>
+<div class="biblioentry">
+<a name="id2593717"></a><p>[<abbr class="abbrev">RFC1035</abbr>] <span class="author"><span class="firstname">P. V.</span> <span class="surname">Mockapetris</span>. </span><span class="title"><i>Domain Names &#8212; Implementation and
+                  Specification</i>. </span><span class="pubdate">November 1987. </span></p>
+</div>
+</div>
+<div class="bibliodiv">
+<h3 class="title">
+<a name="proposed_standards"></a>Proposed Standards</h3>
+<div class="biblioentry">
+<a name="id2593753"></a><p>[<abbr class="abbrev">RFC2181</abbr>] <span class="author"><span class="firstname">R., R. Bush</span> <span class="surname">Elz</span>. </span><span class="title"><i>Clarifications to the <acronym class="acronym">DNS</acronym>
+                  Specification</i>. </span><span class="pubdate">July 1997. </span></p>
+</div>
+<div class="biblioentry">
+<a name="id2593780"></a><p>[<abbr class="abbrev">RFC2308</abbr>] <span class="author"><span class="firstname">M.</span> <span class="surname">Andrews</span>. </span><span class="title"><i>Negative Caching of <acronym class="acronym">DNS</acronym>
+                  Queries</i>. </span><span class="pubdate">March 1998. </span></p>
+</div>
+<div class="biblioentry">
+<a name="id2593805"></a><p>[<abbr class="abbrev">RFC1995</abbr>] <span class="author"><span class="firstname">M.</span> <span class="surname">Ohta</span>. </span><span class="title"><i>Incremental Zone Transfer in <acronym class="acronym">DNS</acronym></i>. </span><span class="pubdate">August 1996. </span></p>
+</div>
+<div class="biblioentry">
+<a name="id2593830"></a><p>[<abbr class="abbrev">RFC1996</abbr>] <span class="author"><span class="firstname">P.</span> <span class="surname">Vixie</span>. </span><span class="title"><i>A Mechanism for Prompt Notification of Zone Changes</i>. </span><span class="pubdate">August 1996. </span></p>
+</div>
+<div class="biblioentry">
+<a name="id2593853"></a><p>[<abbr class="abbrev">RFC2136</abbr>] <span class="authorgroup"><span class="firstname">P.</span> <span class="surname">Vixie</span>, <span class="firstname">S.</span> <span class="surname">Thomson</span>, <span class="firstname">Y.</span> <span class="surname">Rekhter</span>, and <span class="firstname">J.</span> <span class="surname">Bound</span>. </span><span class="title"><i>Dynamic Updates in the Domain Name System</i>. </span><span class="pubdate">April 1997. </span></p>
+</div>
+<div class="biblioentry">
+<a name="id2593909"></a><p>[<abbr class="abbrev">RFC2671</abbr>] <span class="authorgroup"><span class="firstname">P.</span> <span class="surname">Vixie</span>. </span><span class="title"><i>Extension Mechanisms for DNS (EDNS0)</i>. </span><span class="pubdate">August 1997. </span></p>
+</div>
+<div class="biblioentry">
+<a name="id2593936"></a><p>[<abbr class="abbrev">RFC2672</abbr>] <span class="authorgroup"><span class="firstname">M.</span> <span class="surname">Crawford</span>. </span><span class="title"><i>Non-Terminal DNS Name Redirection</i>. </span><span class="pubdate">August 1999. </span></p>
+</div>
+<div class="biblioentry">
+<a name="id2593962"></a><p>[<abbr class="abbrev">RFC2845</abbr>] <span class="authorgroup"><span class="firstname">P.</span> <span class="surname">Vixie</span>, <span class="firstname">O.</span> <span class="surname">Gudmundsson</span>, <span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span>, and <span class="firstname">B.</span> <span class="surname">Wellington</span>. </span><span class="title"><i>Secret Key Transaction Authentication for <acronym class="acronym">DNS</acronym> (TSIG)</i>. </span><span class="pubdate">May 2000. </span></p>
+</div>
+<div class="biblioentry">
+<a name="id2594024"></a><p>[<abbr class="abbrev">RFC2930</abbr>] <span class="authorgroup"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span>. </span><span class="title"><i>Secret Key Establishment for DNS (TKEY RR)</i>. </span><span class="pubdate">September 2000. </span></p>
+</div>
+<div class="biblioentry">
+<a name="id2594054"></a><p>[<abbr class="abbrev">RFC2931</abbr>] <span class="authorgroup"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span>. </span><span class="title"><i>DNS Request and Transaction Signatures (SIG(0)s)</i>. </span><span class="pubdate">September 2000. </span></p>
+</div>
+<div class="biblioentry">
+<a name="id2594084"></a><p>[<abbr class="abbrev">RFC3007</abbr>] <span class="authorgroup"><span class="firstname">B.</span> <span class="surname">Wellington</span>. </span><span class="title"><i>Secure Domain Name System (DNS) Dynamic Update</i>. </span><span class="pubdate">November 2000. </span></p>
+</div>
+<div class="biblioentry">
+<a name="id2594110"></a><p>[<abbr class="abbrev">RFC3645</abbr>] <span class="authorgroup"><span class="firstname">S.</span> <span class="surname">Kwan</span>, <span class="firstname">P.</span> <span class="surname">Garg</span>, <span class="firstname">J.</span> <span class="surname">Gilroy</span>, <span class="firstname">L.</span> <span class="surname">Esibov</span>, <span class="firstname">J.</span> <span class="surname">Westhead</span>, and <span class="firstname">R.</span> <span class="surname">Hall</span>. </span><span class="title"><i>Generic Security Service Algorithm for Secret
+                       Key Transaction Authentication for DNS
+                       (GSS-TSIG)</i>. </span><span class="pubdate">October 2003. </span></p>
+</div>
+</div>
+<div class="bibliodiv">
+<h3 class="title">
+<acronym class="acronym">DNS</acronym> Security Proposed Standards</h3>
+<div class="biblioentry">
+<a name="id2594193"></a><p>[<abbr class="abbrev">RFC3225</abbr>] <span class="authorgroup"><span class="firstname">D.</span> <span class="surname">Conrad</span>. </span><span class="title"><i>Indicating Resolver Support of DNSSEC</i>. </span><span class="pubdate">December 2001. </span></p>
+</div>
+<div class="biblioentry">
+<a name="id2594288"></a><p>[<abbr class="abbrev">RFC3833</abbr>] <span class="authorgroup"><span class="firstname">D.</span> <span class="surname">Atkins</span> and <span class="firstname">R.</span> <span class="surname">Austein</span>. </span><span class="title"><i>Threat Analysis of the Domain Name System (DNS)</i>. </span><span class="pubdate">August 2004. </span></p>
+</div>
+<div class="biblioentry">
+<a name="id2594324"></a><p>[<abbr class="abbrev">RFC4033</abbr>] <span class="authorgroup"><span class="firstname">R.</span> <span class="surname">Arends</span>, <span class="firstname">R.</span> <span class="surname">Austein</span>, <span class="firstname">M.</span> <span class="surname">Larson</span>, <span class="firstname">D.</span> <span class="surname">Massey</span>, and <span class="firstname">S.</span> <span class="surname">Rose</span>. </span><span class="title"><i>DNS Security Introduction and Requirements</i>. </span><span class="pubdate">March 2005. </span></p>
+</div>
+<div class="biblioentry">
+<a name="id2594389"></a><p>[<abbr class="abbrev">RFC4044</abbr>] <span class="authorgroup"><span class="firstname">R.</span> <span class="surname">Arends</span>, <span class="firstname">R.</span> <span class="surname">Austein</span>, <span class="firstname">M.</span> <span class="surname">Larson</span>, <span class="firstname">D.</span> <span class="surname">Massey</span>, and <span class="firstname">S.</span> <span class="surname">Rose</span>. </span><span class="title"><i>Resource Records for the DNS Security Extensions</i>. </span><span class="pubdate">March 2005. </span></p>
+</div>
+<div class="biblioentry">
+<a name="id2594454"></a><p>[<abbr class="abbrev">RFC4035</abbr>] <span class="authorgroup"><span class="firstname">R.</span> <span class="surname">Arends</span>, <span class="firstname">R.</span> <span class="surname">Austein</span>, <span class="firstname">M.</span> <span class="surname">Larson</span>, <span class="firstname">D.</span> <span class="surname">Massey</span>, and <span class="firstname">S.</span> <span class="surname">Rose</span>. </span><span class="title"><i>Protocol Modifications for the DNS
+                       Security Extensions</i>. </span><span class="pubdate">March 2005. </span></p>
+</div>
+</div>
+<div class="bibliodiv">
+<h3 class="title">Other Important RFCs About <acronym class="acronym">DNS</acronym>
+                Implementation</h3>
+<div class="biblioentry">
+<a name="id2594596"></a><p>[<abbr class="abbrev">RFC1535</abbr>] <span class="author"><span class="firstname">E.</span> <span class="surname">Gavron</span>. </span><span class="title"><i>A Security Problem and Proposed Correction With Widely
+                  Deployed <acronym class="acronym">DNS</acronym> Software.</i>. </span><span class="pubdate">October 1993. </span></p>
+</div>
+<div class="biblioentry">
+<a name="id2594621"></a><p>[<abbr class="abbrev">RFC1536</abbr>] <span class="authorgroup"><span class="firstname">A.</span> <span class="surname">Kumar</span>, <span class="firstname">J.</span> <span class="surname">Postel</span>, <span class="firstname">C.</span> <span class="surname">Neuman</span>, <span class="firstname">P.</span> <span class="surname">Danzig</span>, and <span class="firstname">S.</span> <span class="surname">Miller</span>. </span><span class="title"><i>Common <acronym class="acronym">DNS</acronym> Implementation
+                  Errors and Suggested Fixes</i>. </span><span class="pubdate">October 1993. </span></p>
+</div>
+<div class="biblioentry">
+<a name="id2594690"></a><p>[<abbr class="abbrev">RFC1982</abbr>] <span class="authorgroup"><span class="firstname">R.</span> <span class="surname">Elz</span> and <span class="firstname">R.</span> <span class="surname">Bush</span>. </span><span class="title"><i>Serial Number Arithmetic</i>. </span><span class="pubdate">August 1996. </span></p>
+</div>
+<div class="biblioentry">
+<a name="id2594725"></a><p>[<abbr class="abbrev">RFC4074</abbr>] <span class="authorgroup"><span class="firstname">Y.</span> <span class="surname">Morishita</span> and <span class="firstname">T.</span> <span class="surname">Jinmei</span>. </span><span class="title"><i>Common Misbehaviour Against <acronym class="acronym">DNS</acronym>
+                Queries for IPv6 Addresses</i>. </span><span class="pubdate">May 2005. </span></p>
+</div>
+</div>
+<div class="bibliodiv">
+<h3 class="title">Resource Record Types</h3>
+<div class="biblioentry">
+<a name="id2594771"></a><p>[<abbr class="abbrev">RFC1183</abbr>] <span class="authorgroup"><span class="firstname">C.F.</span> <span class="surname">Everhart</span>, <span class="firstname">L. A.</span> <span class="surname">Mamakos</span>, <span class="firstname">R.</span> <span class="surname">Ullmann</span>, and <span class="firstname">P.</span> <span class="surname">Mockapetris</span>. </span><span class="title"><i>New <acronym class="acronym">DNS</acronym> RR Definitions</i>. </span><span class="pubdate">October 1990. </span></p>
+</div>
+<div class="biblioentry">
+<a name="id2594828"></a><p>[<abbr class="abbrev">RFC1706</abbr>] <span class="authorgroup"><span class="firstname">B.</span> <span class="surname">Manning</span> and <span class="firstname">R.</span> <span class="surname">Colella</span>. </span><span class="title"><i><acronym class="acronym">DNS</acronym> NSAP Resource Records</i>. </span><span class="pubdate">October 1994. </span></p>
+</div>
+<div class="biblioentry">
+<a name="id2594866"></a><p>[<abbr class="abbrev">RFC2168</abbr>] <span class="authorgroup"><span class="firstname">R.</span> <span class="surname">Daniel</span> and <span class="firstname">M.</span> <span class="surname">Mealling</span>. </span><span class="title"><i>Resolution of Uniform Resource Identifiers using
+                  the Domain Name System</i>. </span><span class="pubdate">June 1997. </span></p>
+</div>
+<div class="biblioentry">
+<a name="id2594901"></a><p>[<abbr class="abbrev">RFC1876</abbr>] <span class="authorgroup"><span class="firstname">C.</span> <span class="surname">Davis</span>, <span class="firstname">P.</span> <span class="surname">Vixie</span>, <span class="firstname">T.</span>, and <span class="firstname">I.</span> <span class="surname">Dickinson</span>. </span><span class="title"><i>A Means for Expressing Location Information in the
+                  Domain
+                  Name System</i>. </span><span class="pubdate">January 1996. </span></p>
+</div>
+<div class="biblioentry">
+<a name="id2594955"></a><p>[<abbr class="abbrev">RFC2052</abbr>] <span class="authorgroup"><span class="firstname">A.</span> <span class="surname">Gulbrandsen</span> and <span class="firstname">P.</span> <span class="surname">Vixie</span>. </span><span class="title"><i>A <acronym class="acronym">DNS</acronym> RR for Specifying the
+                  Location of
+                  Services.</i>. </span><span class="pubdate">October 1996. </span></p>
+</div>
+<div class="biblioentry">
+<a name="id2594994"></a><p>[<abbr class="abbrev">RFC2163</abbr>] <span class="author"><span class="firstname">A.</span> <span class="surname">Allocchio</span>. </span><span class="title"><i>Using the Internet <acronym class="acronym">DNS</acronym> to
+                  Distribute MIXER
+                  Conformant Global Address Mapping</i>. </span><span class="pubdate">January 1998. </span></p>
+</div>
+<div class="biblioentry">
+<a name="id2595019"></a><p>[<abbr class="abbrev">RFC2230</abbr>] <span class="author"><span class="firstname">R.</span> <span class="surname">Atkinson</span>. </span><span class="title"><i>Key Exchange Delegation Record for the <acronym class="acronym">DNS</acronym></i>. </span><span class="pubdate">October 1997. </span></p>
+</div>
+<div class="biblioentry">
+<a name="id2595045"></a><p>[<abbr class="abbrev">RFC2536</abbr>] <span class="author"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span>. </span><span class="title"><i>DSA KEYs and SIGs in the Domain Name System (DNS)</i>. </span><span class="pubdate">March 1999. </span></p>
+</div>
+<div class="biblioentry">
+<a name="id2595072"></a><p>[<abbr class="abbrev">RFC2537</abbr>] <span class="author"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span>. </span><span class="title"><i>RSA/MD5 KEYs and SIGs in the Domain Name System (DNS)</i>. </span><span class="pubdate">March 1999. </span></p>
+</div>
+<div class="biblioentry">
+<a name="id2595098"></a><p>[<abbr class="abbrev">RFC2538</abbr>] <span class="authorgroup"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span> and <span class="firstname">O.</span> <span class="surname">Gudmundsson</span>. </span><span class="title"><i>Storing Certificates in the Domain Name System (DNS)</i>. </span><span class="pubdate">March 1999. </span></p>
+</div>
+<div class="biblioentry">
+<a name="id2595138"></a><p>[<abbr class="abbrev">RFC2539</abbr>] <span class="authorgroup"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span>. </span><span class="title"><i>Storage of Diffie-Hellman Keys in the Domain Name System (DNS)</i>. </span><span class="pubdate">March 1999. </span></p>
+</div>
+<div class="biblioentry">
+<a name="id2595168"></a><p>[<abbr class="abbrev">RFC2540</abbr>] <span class="authorgroup"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span>. </span><span class="title"><i>Detached Domain Name System (DNS) Information</i>. </span><span class="pubdate">March 1999. </span></p>
+</div>
+<div class="biblioentry">
+<a name="id2595197"></a><p>[<abbr class="abbrev">RFC2782</abbr>] <span class="author"><span class="firstname">A.</span> <span class="surname">Gulbrandsen</span>. </span><span class="author"><span class="firstname">P.</span> <span class="surname">Vixie</span>. </span><span class="author"><span class="firstname">L.</span> <span class="surname">Esibov</span>. </span><span class="title"><i>A DNS RR for specifying the location of services (DNS SRV)</i>. </span><span class="pubdate">February 2000. </span></p>
+</div>
+<div class="biblioentry">
+<a name="id2595240"></a><p>[<abbr class="abbrev">RFC2915</abbr>] <span class="author"><span class="firstname">M.</span> <span class="surname">Mealling</span>. </span><span class="author"><span class="firstname">R.</span> <span class="surname">Daniel</span>. </span><span class="title"><i>The Naming Authority Pointer (NAPTR) DNS Resource Record</i>. </span><span class="pubdate">September 2000. </span></p>
+</div>
+<div class="biblioentry">
+<a name="id2595273"></a><p>[<abbr class="abbrev">RFC3110</abbr>] <span class="author"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span>. </span><span class="title"><i>RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS)</i>. </span><span class="pubdate">May 2001. </span></p>
+</div>
+<div class="biblioentry">
+<a name="id2595300"></a><p>[<abbr class="abbrev">RFC3123</abbr>] <span class="author"><span class="firstname">P.</span> <span class="surname">Koch</span>. </span><span class="title"><i>A DNS RR Type for Lists of Address Prefixes (APL RR)</i>. </span><span class="pubdate">June 2001. </span></p>
+</div>
+<div class="biblioentry">
+<a name="id2595323"></a><p>[<abbr class="abbrev">RFC3596</abbr>] <span class="authorgroup"><span class="firstname">S.</span> <span class="surname">Thomson</span>, <span class="firstname">C.</span> <span class="surname">Huitema</span>, <span class="firstname">V.</span> <span class="surname">Ksinant</span>, and <span class="firstname">M.</span> <span class="surname">Souissi</span>. </span><span class="title"><i><acronym class="acronym">DNS</acronym> Extensions to support IP
+                  version 6</i>. </span><span class="pubdate">October 2003. </span></p>
+</div>
+<div class="biblioentry">
+<a name="id2595381"></a><p>[<abbr class="abbrev">RFC3597</abbr>] <span class="author"><span class="firstname">A.</span> <span class="surname">Gustafsson</span>. </span><span class="title"><i>Handling of Unknown DNS Resource Record (RR) Types</i>. </span><span class="pubdate">September 2003. </span></p>
+</div>
+</div>
+<div class="bibliodiv">
+<h3 class="title">
+<acronym class="acronym">DNS</acronym> and the Internet</h3>
+<div class="biblioentry">
+<a name="id2595413"></a><p>[<abbr class="abbrev">RFC1101</abbr>] <span class="author"><span class="firstname">P. V.</span> <span class="surname">Mockapetris</span>. </span><span class="title"><i><acronym class="acronym">DNS</acronym> Encoding of Network Names
+                  and Other Types</i>. </span><span class="pubdate">April 1989. </span></p>
+</div>
+<div class="biblioentry">
+<a name="id2595438"></a><p>[<abbr class="abbrev">RFC1123</abbr>] <span class="author"><span class="surname">Braden</span>. </span><span class="title"><i>Requirements for Internet Hosts - Application and
+                  Support</i>. </span><span class="pubdate">October 1989. </span></p>
+</div>
+<div class="biblioentry">
+<a name="id2595461"></a><p>[<abbr class="abbrev">RFC1591</abbr>] <span class="author"><span class="firstname">J.</span> <span class="surname">Postel</span>. </span><span class="title"><i>Domain Name System Structure and Delegation</i>. </span><span class="pubdate">March 1994. </span></p>
+</div>
+<div class="biblioentry">
+<a name="id2595484"></a><p>[<abbr class="abbrev">RFC2317</abbr>] <span class="authorgroup"><span class="firstname">H.</span> <span class="surname">Eidnes</span>, <span class="firstname">G.</span> <span class="surname">de Groot</span>, and <span class="firstname">P.</span> <span class="surname">Vixie</span>. </span><span class="title"><i>Classless IN-ADDR.ARPA Delegation</i>. </span><span class="pubdate">March 1998. </span></p>
+</div>
+<div class="biblioentry">
+<a name="id2595530"></a><p>[<abbr class="abbrev">RFC2826</abbr>] <span class="authorgroup"><span class="surname">Internet Architecture Board</span>. </span><span class="title"><i>IAB Technical Comment on the Unique DNS Root</i>. </span><span class="pubdate">May 2000. </span></p>
+</div>
+<div class="biblioentry">
+<a name="id2595554"></a><p>[<abbr class="abbrev">RFC2929</abbr>] <span class="authorgroup"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span>, <span class="firstname">E.</span> <span class="surname">Brunner-Williams</span>, and <span class="firstname">B.</span> <span class="surname">Manning</span>. </span><span class="title"><i>Domain Name System (DNS) IANA Considerations</i>. </span><span class="pubdate">September 2000. </span></p>
+</div>
+</div>
+<div class="bibliodiv">
+<h3 class="title">
+<acronym class="acronym">DNS</acronym> Operations</h3>
+<div class="biblioentry">
+<a name="id2595611"></a><p>[<abbr class="abbrev">RFC1033</abbr>] <span class="author"><span class="firstname">M.</span> <span class="surname">Lottor</span>. </span><span class="title"><i>Domain administrators operations guide.</i>. </span><span class="pubdate">November 1987. </span></p>
+</div>
+<div class="biblioentry">
+<a name="id2595635"></a><p>[<abbr class="abbrev">RFC1537</abbr>] <span class="author"><span class="firstname">P.</span> <span class="surname">Beertema</span>. </span><span class="title"><i>Common <acronym class="acronym">DNS</acronym> Data File
+                  Configuration Errors</i>. </span><span class="pubdate">October 1993. </span></p>
+</div>
+<div class="biblioentry">
+<a name="id2595661"></a><p>[<abbr class="abbrev">RFC1912</abbr>] <span class="author"><span class="firstname">D.</span> <span class="surname">Barr</span>. </span><span class="title"><i>Common <acronym class="acronym">DNS</acronym> Operational and
+                  Configuration Errors</i>. </span><span class="pubdate">February 1996. </span></p>
+</div>
+<div class="biblioentry">
+<a name="id2595688"></a><p>[<abbr class="abbrev">RFC2010</abbr>] <span class="authorgroup"><span class="firstname">B.</span> <span class="surname">Manning</span> and <span class="firstname">P.</span> <span class="surname">Vixie</span>. </span><span class="title"><i>Operational Criteria for Root Name Servers.</i>. </span><span class="pubdate">October 1996. </span></p>
+</div>
+<div class="biblioentry">
+<a name="id2595724"></a><p>[<abbr class="abbrev">RFC2219</abbr>] <span class="authorgroup"><span class="firstname">M.</span> <span class="surname">Hamilton</span> and <span class="firstname">R.</span> <span class="surname">Wright</span>. </span><span class="title"><i>Use of <acronym class="acronym">DNS</acronym> Aliases for
+                  Network Services.</i>. </span><span class="pubdate">October 1997. </span></p>
+</div>
+</div>
+<div class="bibliodiv">
+<h3 class="title">Internationalized Domain Names</h3>
+<div class="biblioentry">
+<a name="id2595770"></a><p>[<abbr class="abbrev">RFC2825</abbr>] <span class="authorgroup"><span class="surname">IAB</span> and <span class="firstname">R.</span> <span class="surname">Daigle</span>. </span><span class="title"><i>A Tangled Web: Issues of I18N, Domain Names,
+                       and the Other Internet protocols</i>. </span><span class="pubdate">May 2000. </span></p>
+</div>
+<div class="biblioentry">
+<a name="id2595802"></a><p>[<abbr class="abbrev">RFC3490</abbr>] <span class="authorgroup"><span class="firstname">P.</span> <span class="surname">Faltstrom</span>, <span class="firstname">P.</span> <span class="surname">Hoffman</span>, and <span class="firstname">A.</span> <span class="surname">Costello</span>. </span><span class="title"><i>Internationalizing Domain Names in Applications (IDNA)</i>. </span><span class="pubdate">March 2003. </span></p>
+</div>
+<div class="biblioentry">
+<a name="id2595848"></a><p>[<abbr class="abbrev">RFC3491</abbr>] <span class="authorgroup"><span class="firstname">P.</span> <span class="surname">Hoffman</span> and <span class="firstname">M.</span> <span class="surname">Blanchet</span>. </span><span class="title"><i>Nameprep: A Stringprep Profile for Internationalized Domain Names</i>. </span><span class="pubdate">March 2003. </span></p>
+</div>
+<div class="biblioentry">
+<a name="id2595883"></a><p>[<abbr class="abbrev">RFC3492</abbr>] <span class="authorgroup"><span class="firstname">A.</span> <span class="surname">Costello</span>. </span><span class="title"><i>Punycode: A Bootstring encoding of Unicode
+                       for Internationalized Domain Names in
+                       Applications (IDNA)</i>. </span><span class="pubdate">March 2003. </span></p>
+</div>
+</div>
+<div class="bibliodiv">
+<h3 class="title">Other <acronym class="acronym">DNS</acronym>-related RFCs</h3>
+<div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
+<h3 class="title">Note</h3>
+<p>
+                  Note: the following list of RFCs, although
+                  <acronym class="acronym">DNS</acronym>-related, are not
+                  concerned with implementing software.
+                </p>
+</div>
+<div class="biblioentry">
+<a name="id2595928"></a><p>[<abbr class="abbrev">RFC1464</abbr>] <span class="author"><span class="firstname">R.</span> <span class="surname">Rosenbaum</span>. </span><span class="title"><i>Using the Domain Name System To Store Arbitrary String
+                  Attributes</i>. </span><span class="pubdate">May 1993. </span></p>
+</div>
+<div class="biblioentry">
+<a name="id2595950"></a><p>[<abbr class="abbrev">RFC1713</abbr>] <span class="author"><span class="firstname">A.</span> <span class="surname">Romao</span>. </span><span class="title"><i>Tools for <acronym class="acronym">DNS</acronym> Debugging</i>. </span><span class="pubdate">November 1994. </span></p>
+</div>
+<div class="biblioentry">
+<a name="id2595976"></a><p>[<abbr class="abbrev">RFC1794</abbr>] <span class="author"><span class="firstname">T.</span> <span class="surname">Brisco</span>. </span><span class="title"><i><acronym class="acronym">DNS</acronym> Support for Load
+                  Balancing</i>. </span><span class="pubdate">April 1995. </span></p>
+</div>
+<div class="biblioentry">
+<a name="id2596002"></a><p>[<abbr class="abbrev">RFC2240</abbr>] <span class="author"><span class="firstname">O.</span> <span class="surname">Vaughan</span>. </span><span class="title"><i>A Legal Basis for Domain Name Allocation</i>. </span><span class="pubdate">November 1997. </span></p>
+</div>
+<div class="biblioentry">
+<a name="id2596025"></a><p>[<abbr class="abbrev">RFC2345</abbr>] <span class="authorgroup"><span class="firstname">J.</span> <span class="surname">Klensin</span>, <span class="firstname">T.</span> <span class="surname">Wolf</span>, and <span class="firstname">G.</span> <span class="surname">Oglesby</span>. </span><span class="title"><i>Domain Names and Company Name Retrieval</i>. </span><span class="pubdate">May 1998. </span></p>
+</div>
+<div class="biblioentry">
+<a name="id2596071"></a><p>[<abbr class="abbrev">RFC2352</abbr>] <span class="author"><span class="firstname">O.</span> <span class="surname">Vaughan</span>. </span><span class="title"><i>A Convention For Using Legal Names as Domain Names</i>. </span><span class="pubdate">May 1998. </span></p>
+</div>
+<div class="biblioentry">
+<a name="id2596094"></a><p>[<abbr class="abbrev">RFC3071</abbr>] <span class="authorgroup"><span class="firstname">J.</span> <span class="surname">Klensin</span>. </span><span class="title"><i>Reflections on the DNS, RFC 1591, and Categories of Domains</i>. </span><span class="pubdate">February 2001. </span></p>
+</div>
+<div class="biblioentry">
+<a name="id2596121"></a><p>[<abbr class="abbrev">RFC3258</abbr>] <span class="authorgroup"><span class="firstname">T.</span> <span class="surname">Hardie</span>. </span><span class="title"><i>Distributing Authoritative Name Servers via
+                       Shared Unicast Addresses</i>. </span><span class="pubdate">April 2002. </span></p>
+</div>
+<div class="biblioentry">
+<a name="id2596147"></a><p>[<abbr class="abbrev">RFC3901</abbr>] <span class="authorgroup"><span class="firstname">A.</span> <span class="surname">Durand</span> and <span class="firstname">J.</span> <span class="surname">Ihren</span>. </span><span class="title"><i>DNS IPv6 Transport Operational Guidelines</i>. </span><span class="pubdate">September 2004. </span></p>
+</div>
+</div>
+<div class="bibliodiv">
+<h3 class="title">Obsolete and Unimplemented Experimental RFC</h3>
+<div class="biblioentry">
+<a name="id2596190"></a><p>[<abbr class="abbrev">RFC1712</abbr>] <span class="authorgroup"><span class="firstname">C.</span> <span class="surname">Farrell</span>, <span class="firstname">M.</span> <span class="surname">Schulze</span>, <span class="firstname">S.</span> <span class="surname">Pleitner</span>, and <span class="firstname">D.</span> <span class="surname">Baldoni</span>. </span><span class="title"><i><acronym class="acronym">DNS</acronym> Encoding of Geographical
+                  Location</i>. </span><span class="pubdate">November 1994. </span></p>
+</div>
+<div class="biblioentry">
+<a name="id2596248"></a><p>[<abbr class="abbrev">RFC2673</abbr>] <span class="authorgroup"><span class="firstname">M.</span> <span class="surname">Crawford</span>. </span><span class="title"><i>Binary Labels in the Domain Name System</i>. </span><span class="pubdate">August 1999. </span></p>
+</div>
+<div class="biblioentry">
+<a name="id2596275"></a><p>[<abbr class="abbrev">RFC2874</abbr>] <span class="authorgroup"><span class="firstname">M.</span> <span class="surname">Crawford</span> and <span class="firstname">C.</span> <span class="surname">Huitema</span>. </span><span class="title"><i>DNS Extensions to Support IPv6 Address Aggregation
+                       and Renumbering</i>. </span><span class="pubdate">July 2000. </span></p>
+</div>
+</div>
+<div class="bibliodiv">
+<h3 class="title">Obsoleted DNS Security RFCs</h3>
+<div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
+<h3 class="title">Note</h3>
+<p>
+                  Most of these have been consolidated into RFC4033,
+                  RFC4034 and RFC4035 which collectively describe DNSSECbis.
+                </p>
+</div>
+<div class="biblioentry">
+<a name="id2596323"></a><p>[<abbr class="abbrev">RFC2065</abbr>] <span class="authorgroup"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span> and <span class="firstname">C.</span> <span class="surname">Kaufman</span>. </span><span class="title"><i>Domain Name System Security Extensions</i>. </span><span class="pubdate">January 1997. </span></p>
+</div>
+<div class="biblioentry">
+<a name="id2596362"></a><p>[<abbr class="abbrev">RFC2137</abbr>] <span class="author"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span>. </span><span class="title"><i>Secure Domain Name System Dynamic Update</i>. </span><span class="pubdate">April 1997. </span></p>
+</div>
+<div class="biblioentry">
+<a name="id2596389"></a><p>[<abbr class="abbrev">RFC2535</abbr>] <span class="authorgroup"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span>. </span><span class="title"><i>Domain Name System Security Extensions</i>. </span><span class="pubdate">March 1999. </span></p>
+</div>
+<div class="biblioentry">
+<a name="id2596419"></a><p>[<abbr class="abbrev">RFC3008</abbr>] <span class="authorgroup"><span class="firstname">B.</span> <span class="surname">Wellington</span>. </span><span class="title"><i>Domain Name System Security (DNSSEC)
+                       Signing Authority</i>. </span><span class="pubdate">November 2000. </span></p>
+</div>
+<div class="biblioentry">
+<a name="id2596444"></a><p>[<abbr class="abbrev">RFC3090</abbr>] <span class="authorgroup"><span class="firstname">E.</span> <span class="surname">Lewis</span>. </span><span class="title"><i>DNS Security Extension Clarification on Zone Status</i>. </span><span class="pubdate">March 2001. </span></p>
+</div>
+<div class="biblioentry">
+<a name="id2596471"></a><p>[<abbr class="abbrev">RFC3445</abbr>] <span class="authorgroup"><span class="firstname">D.</span> <span class="surname">Massey</span> and <span class="firstname">S.</span> <span class="surname">Rose</span>. </span><span class="title"><i>Limiting the Scope of the KEY Resource Record (RR)</i>. </span><span class="pubdate">December 2002. </span></p>
+</div>
+<div class="biblioentry">
+<a name="id2596507"></a><p>[<abbr class="abbrev">RFC3655</abbr>] <span class="authorgroup"><span class="firstname">B.</span> <span class="surname">Wellington</span> and <span class="firstname">O.</span> <span class="surname">Gudmundsson</span>. </span><span class="title"><i>Redefinition of DNS Authenticated Data (AD) bit</i>. </span><span class="pubdate">November 2003. </span></p>
+</div>
+<div class="biblioentry">
+<a name="id2596544"></a><p>[<abbr class="abbrev">RFC3658</abbr>] <span class="authorgroup"><span class="firstname">O.</span> <span class="surname">Gudmundsson</span>. </span><span class="title"><i>Delegation Signer (DS) Resource Record (RR)</i>. </span><span class="pubdate">December 2003. </span></p>
+</div>
+<div class="biblioentry">
+<a name="id2596570"></a><p>[<abbr class="abbrev">RFC3755</abbr>] <span class="authorgroup"><span class="firstname">S.</span> <span class="surname">Weiler</span>. </span><span class="title"><i>Legacy Resolver Compatibility for Delegation Signer (DS)</i>. </span><span class="pubdate">May 2004. </span></p>
+</div>
+<div class="biblioentry">
+<a name="id2596597"></a><p>[<abbr class="abbrev">RFC3757</abbr>] <span class="authorgroup"><span class="firstname">O.</span> <span class="surname">Kolkman</span>, <span class="firstname">J.</span> <span class="surname">Schlyter</span>, and <span class="firstname">E.</span> <span class="surname">Lewis</span>. </span><span class="title"><i>Domain Name System KEY (DNSKEY) Resource Record
+                      (RR) Secure Entry Point (SEP) Flag</i>. </span><span class="pubdate">April 2004. </span></p>
+</div>
+<div class="biblioentry">
+<a name="id2596642"></a><p>[<abbr class="abbrev">RFC3845</abbr>] <span class="authorgroup"><span class="firstname">J.</span> <span class="surname">Schlyter</span>. </span><span class="title"><i>DNS Security (DNSSEC) NextSECure (NSEC) RDATA Format</i>. </span><span class="pubdate">August 2004. </span></p>
+</div>
+</div>
+</div>
+</div>
+<div class="sect2" lang="en">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="internet_drafts"></a>Internet Drafts</h3></div></div></div>
+<p>
+            Internet Drafts (IDs) are rough-draft working documents of
+            the Internet Engineering Task Force. They are, in essence, RFCs
+            in the preliminary stages of development. Implementors are
+            cautioned not
+            to regard IDs as archival, and they should not be quoted or cited
+            in any formal documents unless accompanied by the disclaimer that
+            they are "works in progress." IDs have a lifespan of six months
+            after which they are deleted unless updated by their authors.
+          </p>
+</div>
+<div class="sect2" lang="en">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="id2596683"></a>Other Documents About <acronym class="acronym">BIND</acronym>
+</h3></div></div></div>
+<p></p>
+<div class="bibliography">
+<div class="titlepage"><div><div><h4 class="title">
+<a name="id2596693"></a>Bibliography</h4></div></div></div>
+<div class="biblioentry">
+<a name="id2596695"></a><p><span class="authorgroup"><span class="firstname">Paul</span> <span class="surname">Albitz</span> and <span class="firstname">Cricket</span> <span class="surname">Liu</span>. </span><span class="title"><i><acronym class="acronym">DNS</acronym> and <acronym class="acronym">BIND</acronym></i>. </span><span class="copyright">Copyright © 1998 Sebastopol, CA: O'Reilly and Associates. </span></p>
+</div>
+</div>
+</div>
+</div>
+</div>
+<div class="navfooter">
+<hr>
+<table width="100%" summary="Navigation footer">
+<tr>
+<td width="40%" align="left">
+<a accesskey="p" href="Bv9ARM.ch08.html">Prev</a> </td>
+<td width="20%" align="center"> </td>
+<td width="40%" align="right"> <a accesskey="n" href="Bv9ARM.ch10.html">Next</a>
+</td>
+</tr>
+<tr>
+<td width="40%" align="left" valign="top">Chapter 8. Troubleshooting </td>
+<td width="20%" align="center"><a accesskey="h" href="Bv9ARM.html">Home</a></td>
+<td width="40%" align="right" valign="top"> Manual pages</td>
+</tr>
+</table>
+</div>
+</body>
+</html>
diff --git a/doc/arm/Bv9ARM.ch10.html b/doc/arm/Bv9ARM.ch10.html
new file mode 100644
index 0000000..03cce5a
--- /dev/null
+++ b/doc/arm/Bv9ARM.ch10.html
@@ -0,0 +1,102 @@
+<!--
+ - Copyright (C) 2004-2007 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2000-2003 Internet Software Consortium.
+ - 
+ - Permission to use, copy, modify, and distribute this software for any
+ - purpose with or without fee is hereby granted, provided that the above
+ - copyright notice and this permission notice appear in all copies.
+ - 
+ - THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
+ - REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
+ - AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
+ - INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
+ - LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
+ - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
+ - PERFORMANCE OF THIS SOFTWARE.
+-->
+<!-- $Id: Bv9ARM.ch10.html,v 1.2.2.6 2007/01/30 00:23:46 marka Exp $ -->
+<html>
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
+<title>Manual pages</title>
+<meta name="generator" content="DocBook XSL Stylesheets V1.71.1">
+<link rel="start" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual">
+<link rel="up" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual">
+<link rel="prev" href="Bv9ARM.ch09.html" title="Appendix A. Appendices">
+<link rel="next" href="man.dig.html" title="dig">
+</head>
+<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
+<div class="navheader">
+<table width="100%" summary="Navigation header">
+<tr><th colspan="3" align="center">Manual pages</th></tr>
+<tr>
+<td width="20%" align="left">
+<a accesskey="p" href="Bv9ARM.ch09.html">Prev</a> </td>
+<th width="60%" align="center"> </th>
+<td width="20%" align="right"> <a accesskey="n" href="man.dig.html">Next</a>
+</td>
+</tr>
+</table>
+<hr>
+</div>
+<div class="reference" lang="en">
+<div class="titlepage">
+<div><div><h1 class="title">
+<a name="Bv9ARM.ch10"></a>Manual pages</h1></div></div>
+<hr>
+</div>
+<div class="toc">
+<p><b>Table of Contents</b></p>
+<dl>
+<dt>
+<span class="refentrytitle"><a href="man.dig.html">dig</a></span><span class="refpurpose"> &#8212; DNS lookup utility</span>
+</dt>
+<dt>
+<span class="refentrytitle"><a href="man.host.html">host</a></span><span class="refpurpose"> &#8212; DNS lookup utility</span>
+</dt>
+<dt>
+<span class="refentrytitle"><a href="man.dnssec-keygen.html"><span class="application">dnssec-keygen</span></a></span><span class="refpurpose"> &#8212; DNSSEC key generation tool</span>
+</dt>
+<dt>
+<span class="refentrytitle"><a href="man.dnssec-signzone.html"><span class="application">dnssec-signzone</span></a></span><span class="refpurpose"> &#8212; DNSSEC zone signing tool</span>
+</dt>
+<dt>
+<span class="refentrytitle"><a href="man.named-checkconf.html"><span class="application">named-checkconf</span></a></span><span class="refpurpose"> &#8212; named configuration file syntax checking tool</span>
+</dt>
+<dt>
+<span class="refentrytitle"><a href="man.named-checkzone.html"><span class="application">named-checkzone</span></a></span><span class="refpurpose"> &#8212; zone file validity checking or converting tool</span>
+</dt>
+<dt>
+<span class="refentrytitle"><a href="man.named.html"><span class="application">named</span></a></span><span class="refpurpose"> &#8212; Internet domain name server</span>
+</dt>
+<dt>
+<span class="refentrytitle"><a href="man.rndc.html"><span class="application">rndc</span></a></span><span class="refpurpose"> &#8212; name server control utility</span>
+</dt>
+<dt>
+<span class="refentrytitle"><a href="man.rndc.conf.html"><code class="filename">rndc.conf</code></a></span><span class="refpurpose"> &#8212; rndc configuration file</span>
+</dt>
+<dt>
+<span class="refentrytitle"><a href="man.rndc-confgen.html"><span class="application">rndc-confgen</span></a></span><span class="refpurpose"> &#8212; rndc key generation tool</span>
+</dt>
+</dl>
+</div>
+</div>
+<div class="navfooter">
+<hr>
+<table width="100%" summary="Navigation footer">
+<tr>
+<td width="40%" align="left">
+<a accesskey="p" href="Bv9ARM.ch09.html">Prev</a> </td>
+<td width="20%" align="center"> </td>
+<td width="40%" align="right"> <a accesskey="n" href="man.dig.html">Next</a>
+</td>
+</tr>
+<tr>
+<td width="40%" align="left" valign="top">Appendix A. Appendices </td>
+<td width="20%" align="center"><a accesskey="h" href="Bv9ARM.html">Home</a></td>
+<td width="40%" align="right" valign="top"> dig</td>
+</tr>
+</table>
+</div>
+</body>
+</html>
diff --git a/doc/arm/Bv9ARM.html b/doc/arm/Bv9ARM.html
new file mode 100644
index 0000000..8a33041
--- /dev/null
+++ b/doc/arm/Bv9ARM.html
@@ -0,0 +1,262 @@
+<!--
+ - Copyright (C) 2004-2007 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2000-2003 Internet Software Consortium.
+ - 
+ - Permission to use, copy, modify, and distribute this software for any
+ - purpose with or without fee is hereby granted, provided that the above
+ - copyright notice and this permission notice appear in all copies.
+ - 
+ - THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
+ - REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
+ - AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
+ - INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
+ - LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
+ - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
+ - PERFORMANCE OF THIS SOFTWARE.
+-->
+<!-- $Id: Bv9ARM.html,v 1.85.18.68 2007/10/31 01:35:59 marka Exp $ -->
+<html>
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
+<title>BIND 9 Administrator Reference Manual</title>
+<meta name="generator" content="DocBook XSL Stylesheets V1.71.1">
+<link rel="start" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual">
+<link rel="next" href="Bv9ARM.ch01.html" title="Chapter 1. Introduction">
+</head>
+<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
+<div class="navheader">
+<table width="100%" summary="Navigation header">
+<tr><th colspan="3" align="center">BIND 9 Administrator Reference Manual</th></tr>
+<tr>
+<td width="20%" align="left"> </td>
+<th width="60%" align="center"> </th>
+<td width="20%" align="right"> <a accesskey="n" href="Bv9ARM.ch01.html">Next</a>
+</td>
+</tr>
+</table>
+<hr>
+</div>
+<div class="book" lang="en">
+<div class="titlepage">
+<div>
+<div><h1 class="title">
+<a name="id2563155"></a>BIND 9 Administrator Reference Manual</h1></div>
+<div><p class="copyright">Copyright © 2004-2007 Internet Systems Consortium, Inc. ("ISC")</p></div>
+<div><p class="copyright">Copyright © 2000-2003 Internet Software Consortium.</p></div>
+</div>
+<hr>
+</div>
+<div class="toc">
+<p><b>Table of Contents</b></p>
+<dl>
+<dt><span class="chapter"><a href="Bv9ARM.ch01.html">1. Introduction</a></span></dt>
+<dd><dl>
+<dt><span class="sect1"><a href="Bv9ARM.ch01.html#id2564117">Scope of Document</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch01.html#id2564140">Organization of This Document</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch01.html#id2563474">Conventions Used in This Document</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch01.html#id2564816">The Domain Name System (<acronym class="acronym">DNS</acronym>)</a></span></dt>
+<dd><dl>
+<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2564837">DNS Fundamentals</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2564871">Domains and Domain Names</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2567208">Zones</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2567285">Authoritative Name Servers</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2567526">Caching Name Servers</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2567588">Name Servers in Multiple Roles</a></span></dt>
+</dl></dd>
+</dl></dd>
+<dt><span class="chapter"><a href="Bv9ARM.ch02.html">2. <acronym class="acronym">BIND</acronym> Resource Requirements</a></span></dt>
+<dd><dl>
+<dt><span class="sect1"><a href="Bv9ARM.ch02.html#id2567622">Hardware requirements</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch02.html#id2567649">CPU Requirements</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch02.html#id2567661">Memory Requirements</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch02.html#id2567688">Name Server Intensive Environment Issues</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch02.html#id2567699">Supported Operating Systems</a></span></dt>
+</dl></dd>
+<dt><span class="chapter"><a href="Bv9ARM.ch03.html">3. Name Server Configuration</a></span></dt>
+<dd><dl>
+<dt><span class="sect1"><a href="Bv9ARM.ch03.html#sample_configuration">Sample Configurations</a></span></dt>
+<dd><dl>
+<dt><span class="sect2"><a href="Bv9ARM.ch03.html#id2568004">A Caching-only Name Server</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch03.html#id2568020">An Authoritative-only Name Server</a></span></dt>
+</dl></dd>
+<dt><span class="sect1"><a href="Bv9ARM.ch03.html#id2568042">Load Balancing</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch03.html#id2568465">Name Server Operations</a></span></dt>
+<dd><dl>
+<dt><span class="sect2"><a href="Bv9ARM.ch03.html#id2568470">Tools for Use With the Name Server Daemon</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch03.html#id2570184">Signals</a></span></dt>
+</dl></dd>
+</dl></dd>
+<dt><span class="chapter"><a href="Bv9ARM.ch04.html">4. Advanced DNS Features</a></span></dt>
+<dd><dl>
+<dt><span class="sect1"><a href="Bv9ARM.ch04.html#notify">Notify</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch04.html#dynamic_update">Dynamic Update</a></span></dt>
+<dd><dl><dt><span class="sect2"><a href="Bv9ARM.ch04.html#journal">The journal file</a></span></dt></dl></dd>
+<dt><span class="sect1"><a href="Bv9ARM.ch04.html#incremental_zone_transfers">Incremental Zone Transfers (IXFR)</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch04.html#id2570642">Split DNS</a></span></dt>
+<dd><dl><dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2570660">Example split DNS setup</a></span></dt></dl></dd>
+<dt><span class="sect1"><a href="Bv9ARM.ch04.html#tsig">TSIG</a></span></dt>
+<dd><dl>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571095">Generate Shared Keys for Each Pair of Hosts</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571169">Copying the Shared Secret to Both Machines</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571179">Informing the Servers of the Key's Existence</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571219">Instructing the Server to Use the Key</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571413">TSIG Key Based Access Control</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571458">Errors</a></span></dt>
+</dl></dd>
+<dt><span class="sect1"><a href="Bv9ARM.ch04.html#id2571472">TKEY</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch04.html#id2571521">SIG(0)</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch04.html#DNSSEC">DNSSEC</a></span></dt>
+<dd><dl>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571725">Generating Keys</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571795">Signing the Zone</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571874">Configuring Servers</a></span></dt>
+</dl></dd>
+<dt><span class="sect1"><a href="Bv9ARM.ch04.html#id2572153">IPv6 Support in <acronym class="acronym">BIND</acronym> 9</a></span></dt>
+<dd><dl>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2572215">Address Lookups Using AAAA Records</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2572236">Address to Name Lookups Using Nibble Format</a></span></dt>
+</dl></dd>
+</dl></dd>
+<dt><span class="chapter"><a href="Bv9ARM.ch05.html">5. The <acronym class="acronym">BIND</acronym> 9 Lightweight Resolver</a></span></dt>
+<dd><dl>
+<dt><span class="sect1"><a href="Bv9ARM.ch05.html#id2572269">The Lightweight Resolver Library</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch05.html#lwresd">Running a Resolver Daemon</a></span></dt>
+</dl></dd>
+<dt><span class="chapter"><a href="Bv9ARM.ch06.html">6. <acronym class="acronym">BIND</acronym> 9 Configuration Reference</a></span></dt>
+<dd><dl>
+<dt><span class="sect1"><a href="Bv9ARM.ch06.html#configuration_file_elements">Configuration File Elements</a></span></dt>
+<dd><dl>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#address_match_lists">Address Match Lists</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2573480">Comment Syntax</a></span></dt>
+</dl></dd>
+<dt><span class="sect1"><a href="Bv9ARM.ch06.html#Configuration_File_Grammar">Configuration File Grammar</a></span></dt>
+<dd><dl>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2574092"><span><strong class="command">acl</strong></span> Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#acl"><span><strong class="command">acl</strong></span> Statement Definition and
+          Usage</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2574282"><span><strong class="command">controls</strong></span> Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#controls_statement_definition_and_usage"><span><strong class="command">controls</strong></span> Statement Definition and
+          Usage</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2574711"><span><strong class="command">include</strong></span> Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2574726"><span><strong class="command">include</strong></span> Statement Definition and
+          Usage</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2574749"><span><strong class="command">key</strong></span> Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2574771"><span><strong class="command">key</strong></span> Statement Definition and Usage</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2574930"><span><strong class="command">logging</strong></span> Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2575056"><span><strong class="command">logging</strong></span> Statement Definition and
+          Usage</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2576406"><span><strong class="command">lwres</strong></span> Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2576480"><span><strong class="command">lwres</strong></span> Statement Definition and Usage</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2576544"><span><strong class="command">masters</strong></span> Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2576587"><span><strong class="command">masters</strong></span> Statement Definition and
+          Usage</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2576602"><span><strong class="command">options</strong></span> Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#options"><span><strong class="command">options</strong></span> Statement Definition and
+          Usage</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#server_statement_grammar"><span><strong class="command">server</strong></span> Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#server_statement_definition_and_usage"><span><strong class="command">server</strong></span> Statement Definition and
+            Usage</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2585361"><span><strong class="command">trusted-keys</strong></span> Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2585410"><span><strong class="command">trusted-keys</strong></span> Statement Definition
+            and Usage</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#view_statement_grammar"><span><strong class="command">view</strong></span> Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2585490"><span><strong class="command">view</strong></span> Statement Definition and Usage</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#zone_statement_grammar"><span><strong class="command">zone</strong></span>
+            Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2586798"><span><strong class="command">zone</strong></span> Statement Definition and Usage</a></span></dt>
+</dl></dd>
+<dt><span class="sect1"><a href="Bv9ARM.ch06.html#id2589080">Zone File</a></span></dt>
+<dd><dl>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#types_of_resource_records_and_when_to_use_them">Types of Resource Records and When to Use Them</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2591101">Discussion of MX Records</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#Setting_TTLs">Setting TTLs</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2591653">Inverse Mapping in IPv4</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2591848">Other Zone File Directives</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2592173"><acronym class="acronym">BIND</acronym> Master File Extension: the  <span><strong class="command">$GENERATE</strong></span> Directive</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#zonefile_format">Additional File Formats</a></span></dt>
+</dl></dd>
+</dl></dd>
+<dt><span class="chapter"><a href="Bv9ARM.ch07.html">7. <acronym class="acronym">BIND</acronym> 9 Security Considerations</a></span></dt>
+<dd><dl>
+<dt><span class="sect1"><a href="Bv9ARM.ch07.html#Access_Control_Lists">Access Control Lists</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch07.html#id2592714"><span><strong class="command">Chroot</strong></span> and <span><strong class="command">Setuid</strong></span></a></span></dt>
+<dd><dl>
+<dt><span class="sect2"><a href="Bv9ARM.ch07.html#id2592791">The <span><strong class="command">chroot</strong></span> Environment</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch07.html#id2592851">Using the <span><strong class="command">setuid</strong></span> Function</a></span></dt>
+</dl></dd>
+<dt><span class="sect1"><a href="Bv9ARM.ch07.html#dynamic_update_security">Dynamic Update Security</a></span></dt>
+</dl></dd>
+<dt><span class="chapter"><a href="Bv9ARM.ch08.html">8. Troubleshooting</a></span></dt>
+<dd><dl>
+<dt><span class="sect1"><a href="Bv9ARM.ch08.html#id2592999">Common Problems</a></span></dt>
+<dd><dl><dt><span class="sect2"><a href="Bv9ARM.ch08.html#id2593004">It's not working; how can I figure out what's wrong?</a></span></dt></dl></dd>
+<dt><span class="sect1"><a href="Bv9ARM.ch08.html#id2593016">Incrementing and Changing the Serial Number</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch08.html#id2593033">Where Can I Get Help?</a></span></dt>
+</dl></dd>
+<dt><span class="appendix"><a href="Bv9ARM.ch09.html">A. Appendices</a></span></dt>
+<dd><dl>
+<dt><span class="sect1"><a href="Bv9ARM.ch09.html#id2593300">Acknowledgments</a></span></dt>
+<dd><dl><dt><span class="sect2"><a href="Bv9ARM.ch09.html#historical_dns_information">A Brief History of the <acronym class="acronym">DNS</acronym> and <acronym class="acronym">BIND</acronym></a></span></dt></dl></dd>
+<dt><span class="sect1"><a href="Bv9ARM.ch09.html#id2593472">General <acronym class="acronym">DNS</acronym> Reference Information</a></span></dt>
+<dd><dl><dt><span class="sect2"><a href="Bv9ARM.ch09.html#ipv6addresses">IPv6 addresses (AAAA)</a></span></dt></dl></dd>
+<dt><span class="sect1"><a href="Bv9ARM.ch09.html#bibliography">Bibliography (and Suggested Reading)</a></span></dt>
+<dd><dl>
+<dt><span class="sect2"><a href="Bv9ARM.ch09.html#rfcs">Request for Comments (RFCs)</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch09.html#internet_drafts">Internet Drafts</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch09.html#id2596683">Other Documents About <acronym class="acronym">BIND</acronym></a></span></dt>
+</dl></dd>
+</dl></dd>
+<dt><span class="reference"><a href="Bv9ARM.ch10.html">I. Manual pages</a></span></dt>
+<dd><dl>
+<dt>
+<span class="refentrytitle"><a href="man.dig.html">dig</a></span><span class="refpurpose"> &#8212; DNS lookup utility</span>
+</dt>
+<dt>
+<span class="refentrytitle"><a href="man.host.html">host</a></span><span class="refpurpose"> &#8212; DNS lookup utility</span>
+</dt>
+<dt>
+<span class="refentrytitle"><a href="man.dnssec-keygen.html"><span class="application">dnssec-keygen</span></a></span><span class="refpurpose"> &#8212; DNSSEC key generation tool</span>
+</dt>
+<dt>
+<span class="refentrytitle"><a href="man.dnssec-signzone.html"><span class="application">dnssec-signzone</span></a></span><span class="refpurpose"> &#8212; DNSSEC zone signing tool</span>
+</dt>
+<dt>
+<span class="refentrytitle"><a href="man.named-checkconf.html"><span class="application">named-checkconf</span></a></span><span class="refpurpose"> &#8212; named configuration file syntax checking tool</span>
+</dt>
+<dt>
+<span class="refentrytitle"><a href="man.named-checkzone.html"><span class="application">named-checkzone</span></a></span><span class="refpurpose"> &#8212; zone file validity checking or converting tool</span>
+</dt>
+<dt>
+<span class="refentrytitle"><a href="man.named.html"><span class="application">named</span></a></span><span class="refpurpose"> &#8212; Internet domain name server</span>
+</dt>
+<dt>
+<span class="refentrytitle"><a href="man.rndc.html"><span class="application">rndc</span></a></span><span class="refpurpose"> &#8212; name server control utility</span>
+</dt>
+<dt>
+<span class="refentrytitle"><a href="man.rndc.conf.html"><code class="filename">rndc.conf</code></a></span><span class="refpurpose"> &#8212; rndc configuration file</span>
+</dt>
+<dt>
+<span class="refentrytitle"><a href="man.rndc-confgen.html"><span class="application">rndc-confgen</span></a></span><span class="refpurpose"> &#8212; rndc key generation tool</span>
+</dt>
+</dl></dd>
+</dl>
+</div>
+</div>
+<div class="navfooter">
+<hr>
+<table width="100%" summary="Navigation footer">
+<tr>
+<td width="40%" align="left"> </td>
+<td width="20%" align="center"> </td>
+<td width="40%" align="right"> <a accesskey="n" href="Bv9ARM.ch01.html">Next</a>
+</td>
+</tr>
+<tr>
+<td width="40%" align="left" valign="top"> </td>
+<td width="20%" align="center"> </td>
+<td width="40%" align="right" valign="top"> Chapter 1. Introduction</td>
+</tr>
+</table>
+</div>
+</body>
+</html>
diff --git a/doc/arm/Bv9ARM.pdf b/doc/arm/Bv9ARM.pdf
new file mode 100755
index 0000000..be27aa1
--- /dev/null
+++ b/doc/arm/Bv9ARM.pdf
@@ -0,0 +1,12885 @@
+%PDF-1.4
+5 0 obj
+<< /S /GoTo /D (chapter.1) >>
+endobj
+8 0 obj
+(1 Introduction)
+endobj
+9 0 obj
+<< /S /GoTo /D (section.1.1) >>
+endobj
+12 0 obj
+(1.1 Scope of Document)
+endobj
+13 0 obj
+<< /S /GoTo /D (section.1.2) >>
+endobj
+16 0 obj
+(1.2 Organization of This Document)
+endobj
+17 0 obj
+<< /S /GoTo /D (section.1.3) >>
+endobj
+20 0 obj
+(1.3 Conventions Used in This Document)
+endobj
+21 0 obj
+<< /S /GoTo /D (section.1.4) >>
+endobj
+24 0 obj
+(1.4 The Domain Name System \(DNS\))
+endobj
+25 0 obj
+<< /S /GoTo /D (subsection.1.4.1) >>
+endobj
+28 0 obj
+(1.4.1 DNS Fundamentals)
+endobj
+29 0 obj
+<< /S /GoTo /D (subsection.1.4.2) >>
+endobj
+32 0 obj
+(1.4.2 Domains and Domain Names)
+endobj
+33 0 obj
+<< /S /GoTo /D (subsection.1.4.3) >>
+endobj
+36 0 obj
+(1.4.3 Zones)
+endobj
+37 0 obj
+<< /S /GoTo /D (subsection.1.4.4) >>
+endobj
+40 0 obj
+(1.4.4 Authoritative Name Servers)
+endobj
+41 0 obj
+<< /S /GoTo /D (subsubsection.1.4.4.1) >>
+endobj
+44 0 obj
+(1.4.4.1 The Primary Master)
+endobj
+45 0 obj
+<< /S /GoTo /D (subsubsection.1.4.4.2) >>
+endobj
+48 0 obj
+(1.4.4.2 Slave Servers)
+endobj
+49 0 obj
+<< /S /GoTo /D (subsubsection.1.4.4.3) >>
+endobj
+52 0 obj
+(1.4.4.3 Stealth Servers)
+endobj
+53 0 obj
+<< /S /GoTo /D (subsection.1.4.5) >>
+endobj
+56 0 obj
+(1.4.5 Caching Name Servers)
+endobj
+57 0 obj
+<< /S /GoTo /D (subsubsection.1.4.5.1) >>
+endobj
+60 0 obj
+(1.4.5.1 Forwarding)
+endobj
+61 0 obj
+<< /S /GoTo /D (subsection.1.4.6) >>
+endobj
+64 0 obj
+(1.4.6 Name Servers in Multiple Roles)
+endobj
+65 0 obj
+<< /S /GoTo /D (chapter.2) >>
+endobj
+68 0 obj
+(2 BIND Resource Requirements)
+endobj
+69 0 obj
+<< /S /GoTo /D (section.2.1) >>
+endobj
+72 0 obj
+(2.1 Hardware requirements)
+endobj
+73 0 obj
+<< /S /GoTo /D (section.2.2) >>
+endobj
+76 0 obj
+(2.2 CPU Requirements)
+endobj
+77 0 obj
+<< /S /GoTo /D (section.2.3) >>
+endobj
+80 0 obj
+(2.3 Memory Requirements)
+endobj
+81 0 obj
+<< /S /GoTo /D (section.2.4) >>
+endobj
+84 0 obj
+(2.4 Name Server Intensive Environment Issues)
+endobj
+85 0 obj
+<< /S /GoTo /D (section.2.5) >>
+endobj
+88 0 obj
+(2.5 Supported Operating Systems)
+endobj
+89 0 obj
+<< /S /GoTo /D (chapter.3) >>
+endobj
+92 0 obj
+(3 Name Server Configuration)
+endobj
+93 0 obj
+<< /S /GoTo /D (section.3.1) >>
+endobj
+96 0 obj
+(3.1 Sample Configurations)
+endobj
+97 0 obj
+<< /S /GoTo /D (subsection.3.1.1) >>
+endobj
+100 0 obj
+(3.1.1 A Caching-only Name Server)
+endobj
+101 0 obj
+<< /S /GoTo /D (subsection.3.1.2) >>
+endobj
+104 0 obj
+(3.1.2 An Authoritative-only Name Server)
+endobj
+105 0 obj
+<< /S /GoTo /D (section.3.2) >>
+endobj
+108 0 obj
+(3.2 Load Balancing)
+endobj
+109 0 obj
+<< /S /GoTo /D (section.3.3) >>
+endobj
+112 0 obj
+(3.3 Name Server Operations)
+endobj
+113 0 obj
+<< /S /GoTo /D (subsection.3.3.1) >>
+endobj
+116 0 obj
+(3.3.1 Tools for Use With the Name Server Daemon)
+endobj
+117 0 obj
+<< /S /GoTo /D (subsubsection.3.3.1.1) >>
+endobj
+120 0 obj
+(3.3.1.1 Diagnostic Tools)
+endobj
+121 0 obj
+<< /S /GoTo /D (subsubsection.3.3.1.2) >>
+endobj
+124 0 obj
+(3.3.1.2 Administrative Tools)
+endobj
+125 0 obj
+<< /S /GoTo /D (subsection.3.3.2) >>
+endobj
+128 0 obj
+(3.3.2 Signals)
+endobj
+129 0 obj
+<< /S /GoTo /D (chapter.4) >>
+endobj
+132 0 obj
+(4 Advanced DNS Features)
+endobj
+133 0 obj
+<< /S /GoTo /D (section.4.1) >>
+endobj
+136 0 obj
+(4.1 Notify)
+endobj
+137 0 obj
+<< /S /GoTo /D (section.4.2) >>
+endobj
+140 0 obj
+(4.2 Dynamic Update)
+endobj
+141 0 obj
+<< /S /GoTo /D (subsection.4.2.1) >>
+endobj
+144 0 obj
+(4.2.1 The journal file)
+endobj
+145 0 obj
+<< /S /GoTo /D (section.4.3) >>
+endobj
+148 0 obj
+(4.3 Incremental Zone Transfers \(IXFR\))
+endobj
+149 0 obj
+<< /S /GoTo /D (section.4.4) >>
+endobj
+152 0 obj
+(4.4 Split DNS)
+endobj
+153 0 obj
+<< /S /GoTo /D (subsection.4.4.1) >>
+endobj
+156 0 obj
+(4.4.1 Example split DNS setup)
+endobj
+157 0 obj
+<< /S /GoTo /D (section.4.5) >>
+endobj
+160 0 obj
+(4.5 TSIG)
+endobj
+161 0 obj
+<< /S /GoTo /D (subsection.4.5.1) >>
+endobj
+164 0 obj
+(4.5.1 Generate Shared Keys for Each Pair of Hosts)
+endobj
+165 0 obj
+<< /S /GoTo /D (subsubsection.4.5.1.1) >>
+endobj
+168 0 obj
+(4.5.1.1 Automatic Generation)
+endobj
+169 0 obj
+<< /S /GoTo /D (subsubsection.4.5.1.2) >>
+endobj
+172 0 obj
+(4.5.1.2 Manual Generation)
+endobj
+173 0 obj
+<< /S /GoTo /D (subsection.4.5.2) >>
+endobj
+176 0 obj
+(4.5.2 Copying the Shared Secret to Both Machines)
+endobj
+177 0 obj
+<< /S /GoTo /D (subsection.4.5.3) >>
+endobj
+180 0 obj
+(4.5.3 Informing the Servers of the Key's Existence)
+endobj
+181 0 obj
+<< /S /GoTo /D (subsection.4.5.4) >>
+endobj
+184 0 obj
+(4.5.4 Instructing the Server to Use the Key)
+endobj
+185 0 obj
+<< /S /GoTo /D (subsection.4.5.5) >>
+endobj
+188 0 obj
+(4.5.5 TSIG Key Based Access Control)
+endobj
+189 0 obj
+<< /S /GoTo /D (subsection.4.5.6) >>
+endobj
+192 0 obj
+(4.5.6 Errors)
+endobj
+193 0 obj
+<< /S /GoTo /D (section.4.6) >>
+endobj
+196 0 obj
+(4.6 TKEY)
+endobj
+197 0 obj
+<< /S /GoTo /D (section.4.7) >>
+endobj
+200 0 obj
+(4.7 SIG\(0\))
+endobj
+201 0 obj
+<< /S /GoTo /D (section.4.8) >>
+endobj
+204 0 obj
+(4.8 DNSSEC)
+endobj
+205 0 obj
+<< /S /GoTo /D (subsection.4.8.1) >>
+endobj
+208 0 obj
+(4.8.1 Generating Keys)
+endobj
+209 0 obj
+<< /S /GoTo /D (subsection.4.8.2) >>
+endobj
+212 0 obj
+(4.8.2 Signing the Zone)
+endobj
+213 0 obj
+<< /S /GoTo /D (subsection.4.8.3) >>
+endobj
+216 0 obj
+(4.8.3 Configuring Servers)
+endobj
+217 0 obj
+<< /S /GoTo /D (section.4.9) >>
+endobj
+220 0 obj
+(4.9 IPv6 Support in BIND 9)
+endobj
+221 0 obj
+<< /S /GoTo /D (subsection.4.9.1) >>
+endobj
+224 0 obj
+(4.9.1 Address Lookups Using AAAA Records)
+endobj
+225 0 obj
+<< /S /GoTo /D (subsection.4.9.2) >>
+endobj
+228 0 obj
+(4.9.2 Address to Name Lookups Using Nibble Format)
+endobj
+229 0 obj
+<< /S /GoTo /D (chapter.5) >>
+endobj
+232 0 obj
+(5 The BIND 9 Lightweight Resolver)
+endobj
+233 0 obj
+<< /S /GoTo /D (section.5.1) >>
+endobj
+236 0 obj
+(5.1 The Lightweight Resolver Library)
+endobj
+237 0 obj
+<< /S /GoTo /D (section.5.2) >>
+endobj
+240 0 obj
+(5.2 Running a Resolver Daemon)
+endobj
+241 0 obj
+<< /S /GoTo /D (chapter.6) >>
+endobj
+244 0 obj
+(6 BIND 9 Configuration Reference)
+endobj
+245 0 obj
+<< /S /GoTo /D (section.6.1) >>
+endobj
+248 0 obj
+(6.1 Configuration File Elements)
+endobj
+249 0 obj
+<< /S /GoTo /D (subsection.6.1.1) >>
+endobj
+252 0 obj
+(6.1.1 Address Match Lists)
+endobj
+253 0 obj
+<< /S /GoTo /D (subsubsection.6.1.1.1) >>
+endobj
+256 0 obj
+(6.1.1.1 Syntax)
+endobj
+257 0 obj
+<< /S /GoTo /D (subsubsection.6.1.1.2) >>
+endobj
+260 0 obj
+(6.1.1.2 Definition and Usage)
+endobj
+261 0 obj
+<< /S /GoTo /D (subsection.6.1.2) >>
+endobj
+264 0 obj
+(6.1.2 Comment Syntax)
+endobj
+265 0 obj
+<< /S /GoTo /D (subsubsection.6.1.2.1) >>
+endobj
+268 0 obj
+(6.1.2.1 Syntax)
+endobj
+269 0 obj
+<< /S /GoTo /D (subsubsection.6.1.2.2) >>
+endobj
+272 0 obj
+(6.1.2.2 Definition and Usage)
+endobj
+273 0 obj
+<< /S /GoTo /D (section.6.2) >>
+endobj
+276 0 obj
+(6.2 Configuration File Grammar)
+endobj
+277 0 obj
+<< /S /GoTo /D (subsection.6.2.1) >>
+endobj
+280 0 obj
+(6.2.1 acl Statement Grammar)
+endobj
+281 0 obj
+<< /S /GoTo /D (subsection.6.2.2) >>
+endobj
+284 0 obj
+(6.2.2 acl Statement Definition and Usage)
+endobj
+285 0 obj
+<< /S /GoTo /D (subsection.6.2.3) >>
+endobj
+288 0 obj
+(6.2.3 controls Statement Grammar)
+endobj
+289 0 obj
+<< /S /GoTo /D (subsection.6.2.4) >>
+endobj
+292 0 obj
+(6.2.4 controls Statement Definition and Usage)
+endobj
+293 0 obj
+<< /S /GoTo /D (subsection.6.2.5) >>
+endobj
+296 0 obj
+(6.2.5 include Statement Grammar)
+endobj
+297 0 obj
+<< /S /GoTo /D (subsection.6.2.6) >>
+endobj
+300 0 obj
+(6.2.6 include Statement Definition and Usage)
+endobj
+301 0 obj
+<< /S /GoTo /D (subsection.6.2.7) >>
+endobj
+304 0 obj
+(6.2.7 key Statement Grammar)
+endobj
+305 0 obj
+<< /S /GoTo /D (subsection.6.2.8) >>
+endobj
+308 0 obj
+(6.2.8 key Statement Definition and Usage)
+endobj
+309 0 obj
+<< /S /GoTo /D (subsection.6.2.9) >>
+endobj
+312 0 obj
+(6.2.9 logging Statement Grammar)
+endobj
+313 0 obj
+<< /S /GoTo /D (subsection.6.2.10) >>
+endobj
+316 0 obj
+(6.2.10 logging Statement Definition and Usage)
+endobj
+317 0 obj
+<< /S /GoTo /D (subsubsection.6.2.10.1) >>
+endobj
+320 0 obj
+(6.2.10.1 The channel Phrase)
+endobj
+321 0 obj
+<< /S /GoTo /D (subsubsection.6.2.10.2) >>
+endobj
+324 0 obj
+(6.2.10.2 The category Phrase)
+endobj
+325 0 obj
+<< /S /GoTo /D (subsection.6.2.11) >>
+endobj
+328 0 obj
+(6.2.11 lwres Statement Grammar)
+endobj
+329 0 obj
+<< /S /GoTo /D (subsection.6.2.12) >>
+endobj
+332 0 obj
+(6.2.12 lwres Statement Definition and Usage)
+endobj
+333 0 obj
+<< /S /GoTo /D (subsection.6.2.13) >>
+endobj
+336 0 obj
+(6.2.13 masters Statement Grammar)
+endobj
+337 0 obj
+<< /S /GoTo /D (subsection.6.2.14) >>
+endobj
+340 0 obj
+(6.2.14 masters Statement Definition and Usage)
+endobj
+341 0 obj
+<< /S /GoTo /D (subsection.6.2.15) >>
+endobj
+344 0 obj
+(6.2.15 options Statement Grammar)
+endobj
+345 0 obj
+<< /S /GoTo /D (subsection.6.2.16) >>
+endobj
+348 0 obj
+(6.2.16 options Statement Definition and Usage)
+endobj
+349 0 obj
+<< /S /GoTo /D (subsubsection.6.2.16.1) >>
+endobj
+352 0 obj
+(6.2.16.1 Boolean Options)
+endobj
+353 0 obj
+<< /S /GoTo /D (subsubsection.6.2.16.2) >>
+endobj
+356 0 obj
+(6.2.16.2 Forwarding)
+endobj
+357 0 obj
+<< /S /GoTo /D (subsubsection.6.2.16.3) >>
+endobj
+360 0 obj
+(6.2.16.3 Dual-stack Servers)
+endobj
+361 0 obj
+<< /S /GoTo /D (subsubsection.6.2.16.4) >>
+endobj
+364 0 obj
+(6.2.16.4 Access Control)
+endobj
+365 0 obj
+<< /S /GoTo /D (subsubsection.6.2.16.5) >>
+endobj
+368 0 obj
+(6.2.16.5 Interfaces)
+endobj
+369 0 obj
+<< /S /GoTo /D (subsubsection.6.2.16.6) >>
+endobj
+372 0 obj
+(6.2.16.6 Query Address)
+endobj
+373 0 obj
+<< /S /GoTo /D (subsubsection.6.2.16.7) >>
+endobj
+376 0 obj
+(6.2.16.7 Zone Transfers)
+endobj
+377 0 obj
+<< /S /GoTo /D (subsubsection.6.2.16.8) >>
+endobj
+380 0 obj
+(6.2.16.8 Bad UDP Port Lists)
+endobj
+381 0 obj
+<< /S /GoTo /D (subsubsection.6.2.16.9) >>
+endobj
+384 0 obj
+(6.2.16.9 Operating System Resource Limits)
+endobj
+385 0 obj
+<< /S /GoTo /D (subsubsection.6.2.16.10) >>
+endobj
+388 0 obj
+(6.2.16.10 Server Resource Limits)
+endobj
+389 0 obj
+<< /S /GoTo /D (subsubsection.6.2.16.11) >>
+endobj
+392 0 obj
+(6.2.16.11 Periodic Task Intervals)
+endobj
+393 0 obj
+<< /S /GoTo /D (subsubsection.6.2.16.12) >>
+endobj
+396 0 obj
+(6.2.16.12 Topology)
+endobj
+397 0 obj
+<< /S /GoTo /D (subsubsection.6.2.16.13) >>
+endobj
+400 0 obj
+(6.2.16.13 The sortlist Statement)
+endobj
+401 0 obj
+<< /S /GoTo /D (subsubsection.6.2.16.14) >>
+endobj
+404 0 obj
+(6.2.16.14 RRset Ordering)
+endobj
+405 0 obj
+<< /S /GoTo /D (subsubsection.6.2.16.15) >>
+endobj
+408 0 obj
+(6.2.16.15 Tuning)
+endobj
+409 0 obj
+<< /S /GoTo /D (subsubsection.6.2.16.16) >>
+endobj
+412 0 obj
+(6.2.16.16 Built-in server information zones)
+endobj
+413 0 obj
+<< /S /GoTo /D (subsubsection.6.2.16.17) >>
+endobj
+416 0 obj
+(6.2.16.17 Built-in Empty Zones)
+endobj
+417 0 obj
+<< /S /GoTo /D (subsubsection.6.2.16.18) >>
+endobj
+420 0 obj
+(6.2.16.18 The Statistics File)
+endobj
+421 0 obj
+<< /S /GoTo /D (subsubsection.6.2.16.19) >>
+endobj
+424 0 obj
+(6.2.16.19 Additional Section Caching)
+endobj
+425 0 obj
+<< /S /GoTo /D (subsection.6.2.17) >>
+endobj
+428 0 obj
+(6.2.17 server Statement Grammar)
+endobj
+429 0 obj
+<< /S /GoTo /D (subsection.6.2.18) >>
+endobj
+432 0 obj
+(6.2.18 server Statement Definition and Usage)
+endobj
+433 0 obj
+<< /S /GoTo /D (subsection.6.2.19) >>
+endobj
+436 0 obj
+(6.2.19 trusted-keys Statement Grammar)
+endobj
+437 0 obj
+<< /S /GoTo /D (subsection.6.2.20) >>
+endobj
+440 0 obj
+(6.2.20 trusted-keys Statement Definition and Usage)
+endobj
+441 0 obj
+<< /S /GoTo /D (subsection.6.2.21) >>
+endobj
+444 0 obj
+(6.2.21 view Statement Grammar)
+endobj
+445 0 obj
+<< /S /GoTo /D (subsection.6.2.22) >>
+endobj
+448 0 obj
+(6.2.22 view Statement Definition and Usage)
+endobj
+449 0 obj
+<< /S /GoTo /D (subsection.6.2.23) >>
+endobj
+452 0 obj
+(6.2.23 zone Statement Grammar)
+endobj
+453 0 obj
+<< /S /GoTo /D (subsection.6.2.24) >>
+endobj
+456 0 obj
+(6.2.24 zone Statement Definition and Usage)
+endobj
+457 0 obj
+<< /S /GoTo /D (subsubsection.6.2.24.1) >>
+endobj
+460 0 obj
+(6.2.24.1 Zone Types)
+endobj
+461 0 obj
+<< /S /GoTo /D (subsubsection.6.2.24.2) >>
+endobj
+464 0 obj
+(6.2.24.2 Class)
+endobj
+465 0 obj
+<< /S /GoTo /D (subsubsection.6.2.24.3) >>
+endobj
+468 0 obj
+(6.2.24.3 Zone Options)
+endobj
+469 0 obj
+<< /S /GoTo /D (subsubsection.6.2.24.4) >>
+endobj
+472 0 obj
+(6.2.24.4 Dynamic Update Policies)
+endobj
+473 0 obj
+<< /S /GoTo /D (section.6.3) >>
+endobj
+476 0 obj
+(6.3 Zone File)
+endobj
+477 0 obj
+<< /S /GoTo /D (subsection.6.3.1) >>
+endobj
+480 0 obj
+(6.3.1 Types of Resource Records and When to Use Them)
+endobj
+481 0 obj
+<< /S /GoTo /D (subsubsection.6.3.1.1) >>
+endobj
+484 0 obj
+(6.3.1.1 Resource Records)
+endobj
+485 0 obj
+<< /S /GoTo /D (subsubsection.6.3.1.2) >>
+endobj
+488 0 obj
+(6.3.1.2 Textual expression of RRs)
+endobj
+489 0 obj
+<< /S /GoTo /D (subsection.6.3.2) >>
+endobj
+492 0 obj
+(6.3.2 Discussion of MX Records)
+endobj
+493 0 obj
+<< /S /GoTo /D (subsection.6.3.3) >>
+endobj
+496 0 obj
+(6.3.3 Setting TTLs)
+endobj
+497 0 obj
+<< /S /GoTo /D (subsection.6.3.4) >>
+endobj
+500 0 obj
+(6.3.4 Inverse Mapping in IPv4)
+endobj
+501 0 obj
+<< /S /GoTo /D (subsection.6.3.5) >>
+endobj
+504 0 obj
+(6.3.5 Other Zone File Directives)
+endobj
+505 0 obj
+<< /S /GoTo /D (subsubsection.6.3.5.1) >>
+endobj
+508 0 obj
+(6.3.5.1 The \044ORIGIN Directive)
+endobj
+509 0 obj
+<< /S /GoTo /D (subsubsection.6.3.5.2) >>
+endobj
+512 0 obj
+(6.3.5.2 The \044INCLUDE Directive)
+endobj
+513 0 obj
+<< /S /GoTo /D (subsubsection.6.3.5.3) >>
+endobj
+516 0 obj
+(6.3.5.3 The \044TTL Directive)
+endobj
+517 0 obj
+<< /S /GoTo /D (subsection.6.3.6) >>
+endobj
+520 0 obj
+(6.3.6 BIND Master File Extension: the \044GENERATE Directive)
+endobj
+521 0 obj
+<< /S /GoTo /D (subsection.6.3.7) >>
+endobj
+524 0 obj
+(6.3.7 Additional File Formats)
+endobj
+525 0 obj
+<< /S /GoTo /D (chapter.7) >>
+endobj
+528 0 obj
+(7 BIND 9 Security Considerations)
+endobj
+529 0 obj
+<< /S /GoTo /D (section.7.1) >>
+endobj
+532 0 obj
+(7.1 Access Control Lists)
+endobj
+533 0 obj
+<< /S /GoTo /D (section.7.2) >>
+endobj
+536 0 obj
+(7.2 Chroot and Setuid)
+endobj
+537 0 obj
+<< /S /GoTo /D (subsection.7.2.1) >>
+endobj
+540 0 obj
+(7.2.1 The chroot Environment)
+endobj
+541 0 obj
+<< /S /GoTo /D (subsection.7.2.2) >>
+endobj
+544 0 obj
+(7.2.2 Using the setuid Function)
+endobj
+545 0 obj
+<< /S /GoTo /D (section.7.3) >>
+endobj
+548 0 obj
+(7.3 Dynamic Update Security)
+endobj
+549 0 obj
+<< /S /GoTo /D (chapter.8) >>
+endobj
+552 0 obj
+(8 Troubleshooting)
+endobj
+553 0 obj
+<< /S /GoTo /D (section.8.1) >>
+endobj
+556 0 obj
+(8.1 Common Problems)
+endobj
+557 0 obj
+<< /S /GoTo /D (subsection.8.1.1) >>
+endobj
+560 0 obj
+(8.1.1 It's not working; how can I figure out what's wrong?)
+endobj
+561 0 obj
+<< /S /GoTo /D (section.8.2) >>
+endobj
+564 0 obj
+(8.2 Incrementing and Changing the Serial Number)
+endobj
+565 0 obj
+<< /S /GoTo /D (section.8.3) >>
+endobj
+568 0 obj
+(8.3 Where Can I Get Help?)
+endobj
+569 0 obj
+<< /S /GoTo /D (appendix.A) >>
+endobj
+572 0 obj
+(A Appendices)
+endobj
+573 0 obj
+<< /S /GoTo /D (section.A.1) >>
+endobj
+576 0 obj
+(A.1 Acknowledgments)
+endobj
+577 0 obj
+<< /S /GoTo /D (subsection.A.1.1) >>
+endobj
+580 0 obj
+(A.1.1 A Brief History of the DNS and BIND)
+endobj
+581 0 obj
+<< /S /GoTo /D (section.A.2) >>
+endobj
+584 0 obj
+(A.2 General DNS Reference Information)
+endobj
+585 0 obj
+<< /S /GoTo /D (subsection.A.2.1) >>
+endobj
+588 0 obj
+(A.2.1 IPv6 addresses \(AAAA\))
+endobj
+589 0 obj
+<< /S /GoTo /D (section.A.3) >>
+endobj
+592 0 obj
+(A.3 Bibliography \(and Suggested Reading\))
+endobj
+593 0 obj
+<< /S /GoTo /D (subsection.A.3.1) >>
+endobj
+596 0 obj
+(A.3.1 Request for Comments \(RFCs\))
+endobj
+597 0 obj
+<< /S /GoTo /D (subsection.A.3.2) >>
+endobj
+600 0 obj
+(A.3.2 Internet Drafts)
+endobj
+601 0 obj
+<< /S /GoTo /D (subsection.A.3.3) >>
+endobj
+604 0 obj
+(A.3.3 Other Documents About BIND)
+endobj
+605 0 obj
+<< /S /GoTo /D (appendix.B) >>
+endobj
+608 0 obj
+(B Manual pages)
+endobj
+609 0 obj
+<< /S /GoTo /D (section.B.1) >>
+endobj
+612 0 obj
+(B.1 dig)
+endobj
+613 0 obj
+<< /S /GoTo /D (section.B.2) >>
+endobj
+616 0 obj
+(B.2 host)
+endobj
+617 0 obj
+<< /S /GoTo /D (section.B.3) >>
+endobj
+620 0 obj
+(B.3 dnssec-keygen)
+endobj
+621 0 obj
+<< /S /GoTo /D (section.B.4) >>
+endobj
+624 0 obj
+(B.4 dnssec-signzone)
+endobj
+625 0 obj
+<< /S /GoTo /D (section.B.5) >>
+endobj
+628 0 obj
+(B.5 named-checkconf)
+endobj
+629 0 obj
+<< /S /GoTo /D (section.B.6) >>
+endobj
+632 0 obj
+(B.6 named-checkzone)
+endobj
+633 0 obj
+<< /S /GoTo /D (section.B.7) >>
+endobj
+636 0 obj
+(B.7 named)
+endobj
+637 0 obj
+<< /S /GoTo /D (section.B.8) >>
+endobj
+640 0 obj
+(B.8 rndc)
+endobj
+641 0 obj
+<< /S /GoTo /D (section.B.9) >>
+endobj
+644 0 obj
+(B.9 rndc.conf)
+endobj
+645 0 obj
+<< /S /GoTo /D (section.B.10) >>
+endobj
+648 0 obj
+(B.10 rndc-confgen)
+endobj
+649 0 obj
+<< /S /GoTo /D [650 0 R  /FitH ] >>
+endobj
+653 0 obj <<
+/Length 236       
+/Filter /FlateDecode
+>>
+stream
+xÚ��ÁJA†ïó9¶‡M'™d2s´T¥‚Beoâai·Rp·t­ïïÔÕ*êArÉÿ‘ü	�/A�}È–ՓºsžŠvíèƒ
¨B)þP+!ÃlQ¡bJÕÂwìNì1úÈP©)&>áóÚÍ®˜€-A½bEM¦pæêÍÃd¾¼[L+V?ÉcºØt»~÷ršã~[÷í¶Ú~ÝNë a¤(±ø˘’å÷9·MÿÚ<Ÿ
+endobj
+650 0 obj <<
+/Type /Page
+/Contents 653 0 R
+/Resources 652 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 659 0 R
+>> endobj
+651 0 obj <<
+/Type /XObject
+/Subtype /Form
+/FormType 1
+/PTEX.FileName (./isc-logo.pdf)
+/PTEX.PageNumber 1
+/PTEX.InfoDict 660 0 R 
+/Matrix [1.00000000 0.00000000 0.00000000 1.00000000 0.00000000 0.00000000]
+/BBox [0.00000000 0.00000000 255.00000000 149.00000000]
+/Resources <<
+/ProcSet [ /PDF /Text ]
+/ColorSpace <<
+/R15 661 0 R
+/R9 662 0 R
+/R11 663 0 R
+/R13 664 0 R
+>>/ExtGState <<
+/R17 665 0 R
+/R8 666 0 R
+>>/Font << /R19 667 0 R >>
+>>
+/Length 668 0 R
+/Filter /FlateDecode
+>>
+stream
+xœu˜;“d9…ýû+®Ùe´�R©—�
lG`XËkz#†10gwÙ~6ßÉ[53}+ˆ}tI%åóäÉT½ßs*{Ö?·¿××í'¿�ûŸ?lï·¼Ÿ#5Û_7}÷n³æ3õùæóýÌ»íwû7\^ûõÃVö×oøÿ_·ÒvþmÕSéœmqöÚ¾æh)ŸÏŽ™,ײ—Zjj•ÅVÊ•ëµÍÔÆn¹§±†Ö5͵[+i6}Ÿk’¨Í–§ºØ±ÖRöÝVIƒe´Ä¶yKfZWTp¾ÜÏç9ùÀ–ÆŒõÒý>R_­êÂJsJƒ¥.ŸËÊiôÝ×\
+û”_g'®Û_6´§ÖØËÍ“[8føƒ”œKj“È4­¹¯5Ã#6ÆJ²4·œª+ÚøاkÇä~¤ž19wR7ñm¦U%s˜,ÃT|
+Û2Æ�‚ŒjUçq¥K"ηbøR<™¬¨™ãŸ¹×²RU|Ñ$ÞÕZ*Š–ŒCõu«|ˆhL$,I˜–¼`¥Y|ÃNżŠLó’#pÕ‹BÖŽj9--	9@‘
€DÌ©….¶áJ{N]Á©¥Z*zÃ3…?´T®²$À“%ÁXF°Zê%.ä’@ŽO­—€!$t\'<Ž¶*W
+èj˵ãB;Žþ"%«ê;¥+ßÚ)Éú¾Œ¤IJ�5yÝGN>³ʧ*=5Dt'ŸtˇÀùiQ{
+˜‚ÚIq%˜3vH­wÁKAįr‹þq n[Uz¯!*â)ôàKG°€ÝgG-dL#¹X0¹Â“@ñ´×£^ëµ½æ
HÕÊ_7S41Ã,ëÀO%ê*\ç/1v¢\¨Î¡¨êG´P:‘Sœ¸1ÀÞ£q‹uc¤,¯J¶”e—	'‚;	F/É&N(AWÖšNfãÀŠq‚ì’htËØ“ªØOàÙ‰GÎ4óHD'ª:SÙ#Oœ™äD4�Ltæª3—=�Ý™p�ÂSè¬F$_)^"åÛ•.ªd­Ôd´ÁJŒÓ¤¨,à}‹F:I
òP<Á:‚é¡û½¶H­JŒŒÀvÎ9±”8G
+%S}8\Ž»Ä{!•pŸjyî8NíÖL-»Ä¼1_yk¦“ˆÔøèus‘#¸W�™˜ÁAŹ{�0º¤Œ4±�à8pª0ŠÚž]#HªiÓºhS”28Ú*7»Å'¤«ÎwMpíD¦9d=‹rêÀ Öd
ðlÎmF1Û\Ój�Í J$¾›ƒlHO†¯,x!Fàqê*i!ߪ‰ž£‘\·î"o6,âM(¨$‡^êP^Å>˜³ÔV¬ˆ¦#Z†ª¼§?Áj¹“LÃ¥R»š¨¦VÅo€Ž
–eõT¥Ø€ùU¢Ù�Ü*
„2ÊNvÊ@ÈËY#E?°+êEn�£±¦h“ÊFØläƒbY3Âc0CEW'ñÖÆ4€»Öm"ŒÙ©˜94A¬#—ª Áõ¢ÙëN)ÅZþÅÖ…µˆ‘ç#µxì‡Ð:Å ÑqYŠ�¢ŽÞ\U¢ÜÆÕ²hb	\´ÑP£’šð¢>�Ô9Ž¨Ñ¸ˆùUm!‰§¢�Zh!ú‹~(Ât~¿ÙA,«×
>*"œD�
0QEuÑ|Îóî`‰ö™%„U™&2WjDó5EŠ)€®ä
+«SÕ0Ý4jÆ0çU6Ñœ5Õ”ê0*ÊBóî"gܲ¥–ÃÄHgæ:2®xļô¨	¤èC�úð¨�˜*#{ëÖâsôÎ
+¯Éæ’×M�¼1ÖQQ½»î0@yP,£§"cf
6‹ÃH%aDšjÑ÷ÄPjëš(²f§ Ø®ì·q,fÙLhgÌŒ#Çd±0xDÉYWíû¾0yš’*á_�àºFî®.˜tƨj²ùKÐõàº5£7¬bi«¸3׽Ŕ
+óÔPĮ́Yu¢e¢�a�5
エ0kÓ,¤×äþ¤V��¡Ò(*�Gãë0[;=‚ÃátçX3pD¦iÜ'ÃëÑ+a�qz JC	"Ê1�ô(Œ
+FÑÞIca­Ç0Ú)	¹A¿+�ÇÀº
�¸|-Tuùa>‚s:½¯•~K
“ÒÞV�׋„OÒAŠI…
�ɪÁr2Q“°Ø¨Á>.z
+ÏÆ狼eÇNdæÌdï"gK2cëÉ—GoOá8GëÏϦ:B
Àht[
+endobj
+660 0 obj
+<<
+/Producer (AFPL Ghostscript 8.51)
+/CreationDate (D:20050606145621)
+/ModDate (D:20050606145621)
+/Title (Alternate-ISC-logo-v2.ai)
+/Creator (Adobe Illustrator\(R\) 11)
+/Author (Douglas E. Appelt)
+>>
+endobj
+661 0 obj
+[/Separation/PANTONE#201805#20C/DeviceCMYK 669 0 R]
+endobj
+662 0 obj
+[/Separation/PANTONE#207506#20C/DeviceCMYK 670 0 R]
+endobj
+663 0 obj
+[/Separation/PANTONE#20301#20C/DeviceCMYK 671 0 R]
+endobj
+664 0 obj
+[/Separation/PANTONE#20871#20C/DeviceCMYK 672 0 R]
+endobj
+665 0 obj
+<<
+/Type /ExtGState
+/SA true
+>>
+endobj
+666 0 obj
+<<
+/Type /ExtGState
+/OPM 1
+>>
+endobj
+667 0 obj
+<<
+/BaseFont /NVXWCK#2BTrajanPro-Bold
+/FontDescriptor 673 0 R
+/Type /Font
+/FirstChar 67
+/LastChar 136
+/Widths [ 800 0 0 0 0 0 452 0 0 0 0 0 0 0 0 0 582 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 841 633 576 686 590 540 923 827 407 760]
+/Encoding 674 0 R
+/Subtype /Type1
+>>
+endobj
+668 0 obj
+2362
+endobj
+669 0 obj
+<<
+/Filter /FlateDecode
+/FunctionType 4
+/Domain [ 0 1]
+/Range [ 0 1 0 1 0 1 0 1]
+/Length 39
+>>
+stream
+xœ«N)-P0PÈ-ÍQH­HÎP
+endobj
+670 0 obj
+<<
+/Filter /FlateDecode
+/FunctionType 4
+/Domain [ 0 1]
+/Range [ 0 1 0 1 0 1 0 1]
+/Length 36
+>>
+stream
+xœ«N)-P0PÈ-ÍQH­HÎP
+endobj
+671 0 obj
+<<
+/Filter /FlateDecode
+/FunctionType 4
+/Domain [ 0 1]
+/Range [ 0 1 0 1 0 1 0 1]
+/Length 40
+>>
+stream
+xœ«N)-P0TÈ-ÍQH­HÎP
+endobj
+672 0 obj
+<<
+/Filter /FlateDecode
+/FunctionType 4
+/Domain [ 0 1]
+/Range [ 0 1 0 1 0 1 0 1]
+/Length 50
+>>
+stream
+xœ«N)-P0Ð365³TÈ-ÍQH­HÎP€Š™X ‹™›#Äô-,ŒÀüZ
+endobj
+673 0 obj
+<<
+/Type /FontDescriptor
+/FontName /NVXWCK#2BTrajanPro-Bold
+/FontBBox [ -45 -17 923 767]
+/Flags 4
+/Ascent 767
+/CapHeight 767
+/Descent -17
+/ItalicAngle 0
+/StemV 138
+/MissingWidth 500
+/CharSet (/Msmall/C/Ysmall/Nsmall/Osmall/Esmall/Rsmall/S/Ssmall/I/Tsmall/Ismall/Usmall)
+/FontFile3 675 0 R
+>>
+endobj
+674 0 obj
+<<
+/Type /Encoding
+/BaseEncoding /WinAnsiEncoding
+/Differences [ 127/Nsmall/Tsmall/Esmall/Rsmall/Ysmall/Ssmall/Msmall/Osmall/Ismall/Usmall]
+>>
+endobj
+675 0 obj
+<<
+/Filter /FlateDecode
+/Subtype /Type1C
+/Length 2657
+>>
+stream
+xœ}VkpUž!!i0dHÈ:=«°î"ŠÏ*QpYWÊD@p• ‘$$�ç$!a2ïžé×éîéǼ’ÌäÍC
Ãû)Á]^º+–B-®k)ZˆËµîÄf‹½´J«¬ýÓÕ÷ÜÛçÜïœï|§Í¦Ì1&³Ù<q™£d]IM‘£ö¾§j«J
ÓŒt�y•óûÙ#ÚØ;M¦7Õ	�“
9™§~•c�Œ†oGÛ&¢ŽIÆÁãjë6:*×V4Úzà�ìóKk_+³/ÝØÐXVÝ`/¬YS먫u”4–•ÞoŸ_Ue_bm°/)k(slÀÆ[¡í•
ö²ÊÆŠ2‡½Äî([[‰?w”•Ú%¥eÕ%ŽõöZcç'ËòÿÉ^YcǾì/ÖT«¥�ØØ`/©)��½ÔŽFYSÛTÓè¨,k¸ßd2MX°´0Dyi ècX“iºéÓL³Í<ÓLšíæ)æ»ÍÓÍ3ÌÓÌ¿1åâ|™^0!óæ13ò2­™h쬞ì=ÄêqóÇ}>þdš…Ãhëôõa3NO?œ
™iv¤è›…$}ت?‰´±èË,Ý®³"cqC;‘µjô=©ãuVú¨ÕxÓ�UîÈçðÈœCæè×éÎþŒt§Óz>Tww$Õ°,'£ÛãŸBœÐ85HqL+kc6zjœ-kŠ_ô?„>M/DãQàZçÕçɽ»Oö|
+_Àź�ŠþúD…PE¸EJ‹ˆZ»`»øâ€8(ÅA…‘}Bµ´>R&+åáE ÿf­YPxïÃôñðÌܤg~ý(qe.Ê®Fw‘›¾ä<8ò§ý“?ßúzñÛW»§Z>CšÓjùè¼9üÆûzÞƒa¸ºú=}•Úî¼ÇN7Â~â�}CØ,ÎÂÖêö–îz¹
+„W
+©š¤õ\o…„
TZ
+ˆõjIt!†CΞ«�y|×ÓhÌ£¤åËýk?^Ø^/ç/õùmþ ÉF'™nH	P¬ÏÅÛøVf1,ƒ&‰î–ÏZ†ö‡rÓ/±©‘Ò”=†&eàÇn+Ì„¹t	[r63
Î˹€ð2,TÙ¹NK½°N³çàpÎÝ1MReZò¹šDÑMV‡ƒ)v33—à�þ˜
hlßµäf9.jBˆ¨"j
+%zÈ2(bPÏIe†§VŠQ
+�'x6FöÐQ§X)®‡ZÐg¹ßÏÆwÌk6'¾¿+ãóËV¦–ªl`Ý\‚@h†¡T.Bn�·¤$tÀnv§á0¡‰Z8¦(J�\¤Kò*x¯Mˆ‰ío¡Oò¤¬­EGíjk´áïú”îÒ¶ú¨3Q�µ®Ýè…ô$¼èF¦ÔÀùi.?Ä1,0@ËL7?È¡Û™ Q<$Q>· :È:�ꥎ=‘îÉcSþH( ‚A·î»Ñ˜§ûÒ5ÞÞP8
+n¨`×rŽ`ëF†â|¼?C3A•‹“pJê�>8Åž0`ÅUI	Ó²ßÛ"à$Ö‡©®ŸÛ
ƒÐF¼›
[¸M‰m;Ðd´jëöÎ^MëŒ$”Žpç]
+rHô“Nx�k�z¨k`(¨ñG¶³a|oð1®@‹§Þ®/ô5»úôlôJë¦`œ‰‚
+ªVŶ° 
+-R¶5ðöU…¢Ëðåq¡�ª±v:#“�TsOÕ¶U(G_¬xâm#¹#—ÙTpÃȤd{ód4åÌMóqŸé¦ižÏ4Õ2€3¿Ú*e%]_Nÿj6a©úâ!4æ®/Eñ@;ªªu’Ñô€pPmïSóc’
+.9,«”à%WÃ:Î-°R,6îâ	ðAZbbñn d7¥¹„‘¹yL–'®�C9‹O–¤~º]ÏC¾˜«Ý›ða2…¼N’º!ðóÙÆÆP¾—m5jA…šÒø8¹SLÃ4ÚÞ­…&bö‡ýn§ »H§âëâÎa„ïº÷§ßßg>ˆ¦¤+ÐÔŒô,·5£»Ð}hZ¡ÛÐDÝ¡wÍЋôú½ßèQ„ܱߪ?~²¡¨eý«ø­Ûk‘¹éô¡•)eúÇ~Ô|À•Tqî¦c1[Ö5ÕÒæï¬Õ2ÇóàYf-ë 1‹Ë_|åç=>–fH|
+&–ê„n>ÚÝ)D6Á
+x¸
\3§gA34–ITž-‹R8õ-ǵÛö2ªWuÉ~Á!"(0Š*FÂ͢ùĨ¸SˆˆoÊQPˆ0¦šåiFäݸVN^_!Ô‚–bž "-Qy$ÑÎsªm¥Ä¡@·âJ=Ŧ¿íÝëL	ÍDËQÆTË?GúÓlRÎ$F*�4’ƒð6–š\`�Œª Ñ“Œô�öd]˜é`û™ü9¸DijeIÛ.q
+ȼLçÇ<;—*X³«¥×ÛGâ_Y1ET�ïƒ4ˆ
Ò-U…_>´üØ¢�æ}õï÷v¼
§ádù�#¹rÛŸå¥@ÔÁ\5l…hð<8Ús·
+»O·Øèv61Bá5*È<6ÞÍ,‡bh‘˜¶ž\Î]Çé#¹#ØÔÍ1Oúñ°Ï¤5oÂ]цÆß4}h˜î0$å,6ü¼”A,¯?/å;Rôcy6Ò½UJ¿§Y½X^é¶�ÙÉŸ‡‹º–�2¸K|o½Ø”/�Ȩ�/ƒ(Â2Ð#žNMKðrˆ
rœÛf9ËyZ¸Ú}$«Ö	õ–©) h`iÎGàAç÷´€H+Šˆ…Õ&*áX$žèìVŽhª”—›¾÷‡A1Ý£¤œÏ0‰÷—Hi éƒw~I(Áö2;à]¸L ™x4[¡OÜ,¾®ÆûÂQQ°”FdQ“ƒ¢�¬„%\î¢Åâ:Ó;ÈÑ”ÌEb1ž�’�¡ˆÿ§=$¸¥?Iš¿CÐõ�3¾C=VÐ'>·¯ôÌÒ+Ü~8	ç#;úÁ_£×á*qň+ô	8®‚ãÆpêŒ_YR”¾d%a	ç¡H\eÄõãDf£Ñ¨­ŽR[�kφG¸ù/WT®ò•A5”H¥ÛVoo8h�nû)¼ÞÃDn…ñ�ëqÌzfåhý&þcQbµXÇß‚çLŽúõ;{²Ðñðué¿ÊÛÙ†-©[SÄ-Û¼ÔyubÜ�ñhüm´œ4^Ë™ ääšLÿQ‹¡endstream
+endobj
+654 0 obj <<
+/D [650 0 R /XYZ 85.0394 794.5015 null]
+>> endobj
+655 0 obj <<
+/D [650 0 R /XYZ 85.0394 769.5949 null]
+>> endobj
+652 0 obj <<
+/Font << /F21 658 0 R >>
+/XObject << /Im1 651 0 R >>
+/ProcSet [ /PDF /Text ]
+>> endobj
+678 0 obj <<
+/Length 994       
+/Filter /FlateDecode
+>>
+stream
+xÚµVË’¢JÝû,5¢­©¯Z҈ʂ83³°»‰hÅ+8ý÷7¡ªDÐÛ›‰.*«ò˜yòd@4?¢&29åšÅud`bh›ý
+Qm]»ÀÒíÏ¡[?NùËk5ú�~ÕŒ,ÌrÀ¦v|™ý*Ô˜"ËäV£ŠÂýí´›•"("6 Š±þ0SצњfkZÂòUv:d•Ø%e•íK±q‹CYœªü¼PØ
�ÁÀÂÀ¿(ÕýÄ­Ø’šÔÀK/‚F‘aš¦féZÏ�ÏÕUèñ5üŽºÌ‚¾Z¼�ú_êÒÿS]ÜêHZ“¶&»«n±«Þק±‡Y_bÔ×ÏĈSÓÖ,Ê€'ŸÉ§Àãkô­z¦�8¶I³.g™�öyYæÅApª
+±žËLÖ³
yG„�¡Üï‹m¾ëœ¬[aló²:åÏçJX½æršÊ›âwÅIýûCÇóéX”ÒýžW¯ÂR¸ú¤8K1w™ÄA‚ºëpß
AÜ0hSÚk&ò=Ëø/§54d+Igñ'ßf[Åv])KF_?²V1eÍöPTù&ëÕßÖ{ìÉÚ��ÙZ•Kÿúí­©ƒpšTß„ëJ wž•Í�ÀàbŽ˜Îêb-ĵH:÷ä˜EÓôiÄéЉ剟ˆuGßý‰7»úæ:‰BÔ;a;áDºÂ˜€8þB‚� †Ì;aê{Òùä§saÅÞ̉'âJÂó•‘nIi­~$ é\Q¼C>tƒÕÄg½äþbøª–{L¢©X^ìÎÁ1²ô¡óè~ú£-´fg"®Û–bGvS?
½$AŠƒXCÉ×ûîA<AxÞ2Rz=Jê�ï<ÒžF±Ê*Ó'KÏõ�àAi{nÃQ=mÛ#Ñ
+½YàϼÐõº™¢&ró°Ðµ	é¶\d<b­’ëœ2²ûÉE‹h•v©D=Ú@-ô®(·WãrWA NkëË—^ópÚz¦ŸÝš›7‰úôbª¿ˆî~x©|ýá5VÙƺ…˜mÓûo"jÃËbRÍ{õ†8Ì9e&½Ãü_®…dµendstream
+endobj
+677 0 obj <<
+/Type /Page
+/Contents 678 0 R
+/Resources 676 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 659 0 R
+>> endobj
+679 0 obj <<
+/D [677 0 R /XYZ 56.6929 794.5015 null]
+>> endobj
+676 0 obj <<
+/Font << /F23 682 0 R /F14 685 0 R >>
+/ProcSet [ /PDF /Text ]
+>> endobj
+688 0 obj <<
+/Length 2891      
+/Filter /FlateDecode
+>>
+stream
+xÚí�MsÛȆïþ¼E:p2ß
+–˜
•U~}Àô )ÚB¼k¯E–¢$6ºÝž™%fÜý³Ô0®2=K2Íf¶X½à³k÷»7/„�6Š­”û&òÛ¹Q)3©Lfs|‘——/þøZŠ™Ô,I1»ü4ø2’I©²ÙåÕ?ŽN«²)Êf}üÏË?uˬ´íûùln%Ó©J»wŠã¹àœ�—M]]mͲ*[«g—!£³\è™M3–h.ÚPú_Ö׳þŇ­ØýûçØ
+W±ïëå*¯úoÞæ®x­]Δܫ�!$j2È�¢
+¤§àâ6¿<™îÏLñ9. u“¹@†X‚‹H¤ó�c™5™B\(à¢)òÛææ–g‡"dm2È�B«B 	ƒB‚t>ÔZ3cÅPC_Cœæ‹›ey=Z=¨Tì]±ùX™2+¹’øDBÀnŽ
#„ì\¿‰�#‰ƒB„ô>ŒJ2måPS˜PS¼®êÿäÝûUÇŠþN0_aB	ÚAö&³�)6¶Ô!؈ÄA±Az†É™²z¨4¬>bë
´“þvsÛ,ïný[>T·íò7Sö™®=‚X�®É0 C
+†-9"qP0ìxLJÇpî­³„%ÊMh­séO³_ž¿{åE.ÖÕ¦^€äÅ¿7˺XÁÙx4]ኟ9åi‘Sî�ëvi£i—#Ò³ë5v¸ ]ž¬Rý .Ã1÷~üôã¨OOÿºMQ÷¢OÓ<U‡Íòþ
+9žzaCâþÚÒ�'é=
+5ž't9*?;^£·w÷O“>?Cßk¾
+ãGyiKnSñSî,Hîä;Rw�"&Eé=l»¨Œ3-¸tBûщç¦ß¼�WåíC|×åÝf{EDÈÙT"°!AÄ–&±8"hïIÊ”û.
�F'~Çm«'€Ãhõlú™ƒ8�žÉâ#CJ|œ~JüH”ø¤w˜H\éΤ𜨰1ðç*÷¥ØËü6/])–Jsè-úR˜ ß“aB†LXO¡ÇaŠÄAÁDz0Í„0P•(r™çkü®2ÑÏç‘œßh‚ÌNÆRØ`å(l"qPØ�Þ‡	HKÆE%‰
+%Éåq&�ªêÖŸ
+¥ï±�D™*ÆÓ¬ŸÚ´ßH<¹ºwkØl»*òfSã=ábOÝBÄÄâV�b¼�_ŽÈÌ®×X±.βLôC¼[ˆïªfùÉ­ïÝ�ºGÏ“|ëeacê=ˆ
‰{pKlŠ°Hi¤÷@šIÝ°®<h°Åðê¡ÌWPØ}¼»Ê7�§‰9@ôCäó<™¡ÁŽB©H´å:”R[–d:
‚†õ!,øþUmjWÀƒÔ\¶§ é�›§qé�2¤ÈÁòQèDâ Ø!½‡ÁGif3뀰'u^.†6
+2¤PÁjÉñ&ÔX*¤÷€ŠoL–BE]*w·Ë—Š©=ÔB¿åp2LfRŒa™)Æ"qPŒ‘Þ‡¹LpæÒ—
da.;ûÞ¯3×þ¬h6wm‰¤öHßd8�!–‡‚#é ‘¥Ls
u4G]^œ¿9ž»7Vb_mS$H1•3lHp¶%µ?ô�ÅApF{ƒ�H-S\
+øƒÿÝÙ/ËuS”탙‰0ß™æ�•Éš#CJsœuJóH”æ¤÷AsiX
+M…­æ:h¾nêãô¨ý�èá·oðÐkƒ
h—#öùlk…lMf
R,`5("qP,�Þ„b‰Ð
ø˜Ž~]í»=Ãמ,Åzž%húg°º
+ÁîGÓäm2ƒÅR…Bb7ŠÊõ
+RDaYåxÏN,Š)Ò;ì]¥3"�ÃÂÖÕ�gk›uÔaëê«m‘‚S)CvdXg‚±Hb¤k ,I˜†–D·œ…Ó™ó7íÉï�å4ψ}µ

™J²#HÃz¤E‚ þåzø”¦¤ð ¥Ð¯òîââìÔ-töã)˜o•OþT¦3)$¬´ÄßxÁPáïþÌeÆÒØ'�·ªïAœ+·üR#M.ŠgÎ×3ÿ¦þ�çñç/àJàí”s®Aendstream
+endobj
+687 0 obj <<
+/Type /Page
+/Contents 688 0 R
+/Resources 686 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 659 0 R
+/Annots [ 691 0 R 692 0 R 693 0 R 694 0 R 695 0 R 696 0 R 697 0 R 698 0 R 699 0 R 700 0 R 701 0 R 702 0 R 703 0 R 704 0 R 705 0 R 706 0 R 707 0 R 708 0 R 709 0 R 710 0 R 711 0 R 712 0 R 713 0 R 714 0 R 715 0 R 716 0 R 717 0 R 718 0 R 719 0 R 720 0 R 721 0 R 722 0 R 723 0 R 724 0 R 725 0 R 726 0 R 727 0 R 728 0 R 729 0 R 730 0 R 731 0 R 732 0 R 733 0 R 734 0 R 735 0 R 736 0 R 737 0 R 738 0 R 739 0 R 740 0 R ]
+>> endobj
+691 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [532.6051 688.709 539.579 697.2967]
+/Subtype /Link
+/A << /S /GoTo /D (chapter.1) >>
+>> endobj
+692 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [532.6051 676.5858 539.579 685.4425]
+/Subtype /Link
+/A << /S /GoTo /D (section.1.1) >>
+>> endobj
+693 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [532.6051 664.4876 539.579 673.3442]
+/Subtype /Link
+/A << /S /GoTo /D (section.1.2) >>
+>> endobj
+694 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [532.6051 652.3894 539.579 661.246]
+/Subtype /Link
+/A << /S /GoTo /D (section.1.3) >>
+>> endobj
+695 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [532.6051 640.1914 539.579 649.1477]
+/Subtype /Link
+/A << /S /GoTo /D (section.1.4) >>
+>> endobj
+696 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [532.6051 628.0932 539.579 637.0495]
+/Subtype /Link
+/A << /S /GoTo /D (subsection.1.4.1) >>
+>> endobj
+697 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [532.6051 615.995 539.579 624.9512]
+/Subtype /Link
+/A << /S /GoTo /D (subsection.1.4.2) >>
+>> endobj
+698 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [532.6051 603.8967 539.579 612.853]
+/Subtype /Link
+/A << /S /GoTo /D (subsection.1.4.3) >>
+>> endobj
+699 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [532.6051 591.7985 539.579 600.7547]
+/Subtype /Link
+/A << /S /GoTo /D (subsection.1.4.4) >>
+>> endobj
+700 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [532.6051 579.7002 539.579 588.6565]
+/Subtype /Link
+/A << /S /GoTo /D (subsubsection.1.4.4.1) >>
+>> endobj
+701 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [532.6051 567.6019 539.579 576.5582]
+/Subtype /Link
+/A << /S /GoTo /D (subsubsection.1.4.4.2) >>
+>> endobj
+702 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [532.6051 555.5037 539.579 564.46]
+/Subtype /Link
+/A << /S /GoTo /D (subsubsection.1.4.4.3) >>
+>> endobj
+703 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [527.6238 543.4055 539.579 552.5112]
+/Subtype /Link
+/A << /S /GoTo /D (subsection.1.4.5) >>
+>> endobj
+704 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [527.6238 531.3072 539.579 540.413]
+/Subtype /Link
+/A << /S /GoTo /D (subsubsection.1.4.5.1) >>
+>> endobj
+705 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [527.6238 519.209 539.579 528.3147]
+/Subtype /Link
+/A << /S /GoTo /D (subsection.1.4.6) >>
+>> endobj
+706 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [527.6238 496.7003 539.579 505.4125]
+/Subtype /Link
+/A << /S /GoTo /D (chapter.2) >>
+>> endobj
+707 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [527.6238 484.5772 539.579 493.5832]
+/Subtype /Link
+/A << /S /GoTo /D (section.2.1) >>
+>> endobj
+708 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [527.6238 472.4789 539.579 481.485]
+/Subtype /Link
+/A << /S /GoTo /D (section.2.2) >>
+>> endobj
+709 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [527.6238 460.3806 539.579 469.3867]
+/Subtype /Link
+/A << /S /GoTo /D (section.2.3) >>
+>> endobj
+710 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [527.6238 448.2824 539.579 457.2885]
+/Subtype /Link
+/A << /S /GoTo /D (section.2.4) >>
+>> endobj
+711 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [527.6238 436.1841 539.579 445.1902]
+/Subtype /Link
+/A << /S /GoTo /D (section.2.5) >>
+>> endobj
+712 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [527.6238 413.4314 539.579 422.288]
+/Subtype /Link
+/A << /S /GoTo /D (chapter.3) >>
+>> endobj
+713 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [527.6238 401.353 539.579 410.4588]
+/Subtype /Link
+/A << /S /GoTo /D (section.3.1) >>
+>> endobj
+714 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [527.6238 389.2548 539.579 398.3605]
+/Subtype /Link
+/A << /S /GoTo /D (subsection.3.1.1) >>
+>> endobj
+715 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [527.6238 377.1565 539.579 386.2623]
+/Subtype /Link
+/A << /S /GoTo /D (subsection.3.1.2) >>
+>> endobj
+716 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [527.6238 365.1579 539.579 374.164]
+/Subtype /Link
+/A << /S /GoTo /D (section.3.2) >>
+>> endobj
+717 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [527.6238 353.0597 539.579 362.0658]
+/Subtype /Link
+/A << /S /GoTo /D (section.3.3) >>
+>> endobj
+718 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [527.6238 340.9614 539.579 349.9675]
+/Subtype /Link
+/A << /S /GoTo /D (subsection.3.3.1) >>
+>> endobj
+719 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [527.6238 328.7635 539.579 337.8693]
+/Subtype /Link
+/A << /S /GoTo /D (subsubsection.3.3.1.1) >>
+>> endobj
+720 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [527.6238 316.6653 539.579 325.771]
+/Subtype /Link
+/A << /S /GoTo /D (subsubsection.3.3.1.2) >>
+>> endobj
+721 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [527.6238 304.567 539.579 313.6728]
+/Subtype /Link
+/A << /S /GoTo /D (subsection.3.3.2) >>
+>> endobj
+722 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [527.6238 281.9139 539.579 290.7706]
+/Subtype /Link
+/A << /S /GoTo /D (chapter.4) >>
+>> endobj
+723 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [527.6238 269.8356 539.579 278.9413]
+/Subtype /Link
+/A << /S /GoTo /D (section.4.1) >>
+>> endobj
+724 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [527.6238 257.7373 539.579 266.8431]
+/Subtype /Link
+/A << /S /GoTo /D (section.4.2) >>
+>> endobj
+725 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [527.6238 245.6391 539.579 254.7448]
+/Subtype /Link
+/A << /S /GoTo /D (subsection.4.2.1) >>
+>> endobj
+726 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [527.6238 233.5408 539.579 242.4971]
+/Subtype /Link
+/A << /S /GoTo /D (section.4.3) >>
+>> endobj
+727 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [527.6238 221.4426 539.579 230.3988]
+/Subtype /Link
+/A << /S /GoTo /D (section.4.4) >>
+>> endobj
+728 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [527.6238 209.3443 539.579 218.3006]
+/Subtype /Link
+/A << /S /GoTo /D (subsection.4.4.1) >>
+>> endobj
+729 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [527.6238 197.2461 539.579 206.2023]
+/Subtype /Link
+/A << /S /GoTo /D (section.4.5) >>
+>> endobj
+730 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [527.6238 185.1478 539.579 194.1041]
+/Subtype /Link
+/A << /S /GoTo /D (subsection.4.5.1) >>
+>> endobj
+731 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [527.6238 173.0496 539.579 182.0058]
+/Subtype /Link
+/A << /S /GoTo /D (subsubsection.4.5.1.1) >>
+>> endobj
+732 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [527.6238 161.051 539.579 170.0571]
+/Subtype /Link
+/A << /S /GoTo /D (subsubsection.4.5.1.2) >>
+>> endobj
+733 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [527.6238 148.9527 539.579 157.9588]
+/Subtype /Link
+/A << /S /GoTo /D (subsection.4.5.2) >>
+>> endobj
+734 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [527.6238 136.8545 539.579 145.8606]
+/Subtype /Link
+/A << /S /GoTo /D (subsection.4.5.3) >>
+>> endobj
+735 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [527.6238 124.7562 539.579 133.7623]
+/Subtype /Link
+/A << /S /GoTo /D (subsection.4.5.4) >>
+>> endobj
+736 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [527.6238 112.658 539.579 121.6641]
+/Subtype /Link
+/A << /S /GoTo /D (subsection.4.5.5) >>
+>> endobj
+737 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [527.6238 100.4601 539.579 109.4163]
+/Subtype /Link
+/A << /S /GoTo /D (subsection.4.5.6) >>
+>> endobj
+738 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [527.6238 88.3618 539.579 97.3181]
+/Subtype /Link
+/A << /S /GoTo /D (section.4.6) >>
+>> endobj
+739 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [527.6238 76.2636 539.579 85.2199]
+/Subtype /Link
+/A << /S /GoTo /D (section.4.7) >>
+>> endobj
+740 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [527.6238 64.1653 539.579 73.1216]
+/Subtype /Link
+/A << /S /GoTo /D (section.4.8) >>
+>> endobj
+689 0 obj <<
+/D [687 0 R /XYZ 85.0394 794.5015 null]
+>> endobj
+690 0 obj <<
+/D [687 0 R /XYZ 85.0394 711.9273 null]
+>> endobj
+686 0 obj <<
+/Font << /F21 658 0 R /F23 682 0 R >>
+/ProcSet [ /PDF /Text ]
+>> endobj
+743 0 obj <<
+/Length 3152      
+/Filter /FlateDecode
+>>
+stream
+xÚí�[wÛÆÇßõ)ø(=p»÷Ë£¯9I[Û±Õ—¦y€)Xæ	I¨$×ýô]ØÝ�¸jÛȵD&'‘la0£ùÿ¸³³X
+
÷ÕÚ?«×{qõsq`¬ Þ+ÒM©Ž¬ðž•óëUeû¹î¾ù{³òߪOÄ Ä„¬1b j1™80bPï�¡ˆÒÖEbDOÌ‹fõJùõí:ró¡^ÿ^¯Û1†‰cEe”‘�ÇbF€!ÆÔ‰›qF2q`Œ Þ
óCŽöå‘ûª&ï!qêyøñÝïº'ãöæ¦Yo»?ÌWÝ×ç?¾yÙ}ç
g�w�ù&
+&ŒŸ{L¡¸ŒrrYÌ	0Ä8�ZaœdâÀ8A½NŒl7`GLÔALæ«ÙâöªÎQ¢‰qìÐdÇ2~Tóä�ábx’ÆÐOŒïˆÍ�‘ƒ¹àh_“´NsýPä_¾õõü?x³FLe1"ÀcJ…A’‰£õ0Q”
:)s“ß꯹©¯/AΊƒ‹ö´ês^Ì0Äx‚šb<eâÀxB½ž„%‚¦QÇ>N‡GEŸ^'R[LM²Ã 
ÂaÌì�!ƒ¹Äpωa	w™Es}Ýî$Ë*ã‡<§­ç(yT»
cŠ‹Ñ
†;PB1~OG.ŒÔ{À‡I¸Ói)�>?÷˜èüvYýa
wÈe1'Àãj…q’‰ãõ¯2IÊ	§Æ
RÚ둶߶¼�¦¾«–aÖ;û\­VunÕÏrR)Ý÷îóºÚx´àÇ5«	é-†bð@ùÄøÍ
¹80xPïá<,´Sí	
+àñÉu³ÎÍt$%Úš;ðHj�ªBÅô–Â
xòI:
+O.Ü{_¡„±„I	*Ôá«U‹/ë:·ÐÇ}}Š°ŒMo¸ÒG|Ý3¦»%`ˆ¡å”ãÛzsq`(¡ÞJZ{z8(aüAP:<Ó‘Ì=¡Ñ'¤µ`ˆ!eÃ�ÉÄ�!ƒzÈ(I¨e<!søJÕ²ÚlÛûãóócéôÁþJWõ
+9.æbü@
åøŽÏ\?¨÷À�ä„J§?ò¡ø¹OåssYÌ	0Ä8�ZaœdâÀ8A½ND;á…ÝÕáKUÍM+õ&ÁÁú³¼TÅŽkjr\Ì0Äø�büdâÀøA½~˜!ÎjP§ôCñsŸVòQ×£�ËbN€!Æ	ÔJŽoýËÅ�q‚zO­8UÄ)	*’ë8Ï›fQW½¨o{:¦J¸#¾ÚÓU0Ä`€rÈñ+¹80Pïîqœ[C¿.óºY©º'¬ìn;—”Ÿn+²³WÊ4Dب£Æ—]rq làÞÖW[Ý>¬eãåmµ˜n¶Õì·;Oßß-Kßb�ˆ©*
b @)Ôxœ‹
õž@ÐŽXåCv <›Íâ­Ð/Ú
víxÑ,Ú¢qºï9%®`ˆa
…Á°ÈÄ�a�zOX(C,7ƒÚ¡:,~\ùöSåÙ¸˜jÊN·/æñ	,Æbx@�Ôx?’‹Ãõžð�Š§ÄCwxü|[·/Ú=Ð
>PAs¢"æ­˜
+`ˆQ
uQã÷©åâÀ¨@½'*„ F»ÓQÑ=…¶…âòÂÑóuµÚ|ÚM*”a',b⊱
+‹/ßuß¼‹�í¹b¹:.B¶ŠY
+‡ëXx{3xÒù‡¯›m½L�B»Ý•’Y|†Þr¾£CªÇµNP,/0Ää…	VãK¹80yQïQ^æÑÚÉÁúõÅ?ö‘‡5L?ñÆ!樔
+endobj
+742 0 obj <<
+/Type /Page
+/Contents 743 0 R
+/Resources 741 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 659 0 R
+/Annots [ 748 0 R 749 0 R 750 0 R 751 0 R 752 0 R 753 0 R 754 0 R 755 0 R 756 0 R 757 0 R 758 0 R 759 0 R 760 0 R 761 0 R 762 0 R 763 0 R 764 0 R 765 0 R 766 0 R 767 0 R 768 0 R 769 0 R 770 0 R 771 0 R 772 0 R 773 0 R 774 0 R 775 0 R 776 0 R 777 0 R 778 0 R 779 0 R 780 0 R 781 0 R 782 0 R 783 0 R 784 0 R 785 0 R 786 0 R 787 0 R 788 0 R 789 0 R 790 0 R 791 0 R 792 0 R 793 0 R 794 0 R 795 0 R 796 0 R 797 0 R 798 0 R 799 0 R 800 0 R 801 0 R 802 0 R 803 0 R 804 0 R ]
+>> endobj
+748 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [499.2773 758.4766 511.2325 767.4329]
+/Subtype /Link
+/A << /S /GoTo /D (subsection.4.8.1) >>
+>> endobj
+749 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [499.2773 746.445 511.2325 755.4012]
+/Subtype /Link
+/A << /S /GoTo /D (subsection.4.8.2) >>
+>> endobj
+750 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [499.2773 734.5129 511.2325 743.3696]
+/Subtype /Link
+/A << /S /GoTo /D (subsection.4.8.3) >>
+>> endobj
+751 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [499.2773 722.3816 511.2325 731.3379]
+/Subtype /Link
+/A << /S /GoTo /D (section.4.9) >>
+>> endobj
+752 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [499.2773 710.3499 511.2325 719.3062]
+/Subtype /Link
+/A << /S /GoTo /D (subsection.4.9.1) >>
+>> endobj
+753 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [499.2773 698.3182 511.2325 707.2745]
+/Subtype /Link
+/A << /S /GoTo /D (subsection.4.9.2) >>
+>> endobj
+754 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [499.2773 675.998 511.2325 684.7301]
+/Subtype /Link
+/A << /S /GoTo /D (chapter.5) >>
+>> endobj
+755 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [499.2773 663.9862 511.2325 672.9425]
+/Subtype /Link
+/A << /S /GoTo /D (section.5.1) >>
+>> endobj
+756 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [499.2773 651.9545 511.2325 660.9108]
+/Subtype /Link
+/A << /S /GoTo /D (section.5.2) >>
+>> endobj
+757 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [499.2773 629.6343 511.2325 638.4909]
+/Subtype /Link
+/A << /S /GoTo /D (chapter.6) >>
+>> endobj
+758 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [499.2773 617.6225 511.2325 626.7282]
+/Subtype /Link
+/A << /S /GoTo /D (section.6.1) >>
+>> endobj
+759 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [499.2773 605.5908 511.2325 614.5471]
+/Subtype /Link
+/A << /S /GoTo /D (subsection.6.1.1) >>
+>> endobj
+760 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [499.2773 593.5591 511.2325 602.5154]
+/Subtype /Link
+/A << /S /GoTo /D (subsubsection.6.1.1.1) >>
+>> endobj
+761 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [499.2773 581.5275 511.2325 590.4837]
+/Subtype /Link
+/A << /S /GoTo /D (subsubsection.6.1.1.2) >>
+>> endobj
+762 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [499.2773 569.4958 511.2325 578.4521]
+/Subtype /Link
+/A << /S /GoTo /D (subsection.6.1.2) >>
+>> endobj
+763 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [499.2773 557.4641 511.2325 566.4204]
+/Subtype /Link
+/A << /S /GoTo /D (subsubsection.6.1.2.1) >>
+>> endobj
+764 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [499.2773 545.4324 511.2325 554.3887]
+/Subtype /Link
+/A << /S /GoTo /D (subsubsection.6.1.2.2) >>
+>> endobj
+765 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [499.2773 533.4007 511.2325 542.5065]
+/Subtype /Link
+/A << /S /GoTo /D (section.6.2) >>
+>> endobj
+766 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [499.2773 521.3691 511.2325 530.3254]
+/Subtype /Link
+/A << /S /GoTo /D (subsection.6.2.1) >>
+>> endobj
+767 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [499.2773 509.3374 511.2325 518.2937]
+/Subtype /Link
+/A << /S /GoTo /D (subsection.6.2.2) >>
+>> endobj
+768 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [499.2773 497.3057 511.2325 506.262]
+/Subtype /Link
+/A << /S /GoTo /D (subsection.6.2.3) >>
+>> endobj
+769 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [499.2773 485.274 511.2325 494.2303]
+/Subtype /Link
+/A << /S /GoTo /D (subsection.6.2.4) >>
+>> endobj
+770 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [499.2773 473.2424 511.2325 482.1986]
+/Subtype /Link
+/A << /S /GoTo /D (subsection.6.2.5) >>
+>> endobj
+771 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [499.2773 461.2107 511.2325 470.167]
+/Subtype /Link
+/A << /S /GoTo /D (subsection.6.2.6) >>
+>> endobj
+772 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [499.2773 449.179 511.2325 458.1353]
+/Subtype /Link
+/A << /S /GoTo /D (subsection.6.2.7) >>
+>> endobj
+773 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [499.2773 437.1473 511.2325 446.1036]
+/Subtype /Link
+/A << /S /GoTo /D (subsection.6.2.8) >>
+>> endobj
+774 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [499.2773 425.1157 511.2325 434.0719]
+/Subtype /Link
+/A << /S /GoTo /D (subsection.6.2.9) >>
+>> endobj
+775 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [499.2773 413.084 511.2325 422.0403]
+/Subtype /Link
+/A << /S /GoTo /D (subsection.6.2.10) >>
+>> endobj
+776 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [499.2773 401.0523 511.2325 410.0086]
+/Subtype /Link
+/A << /S /GoTo /D (subsubsection.6.2.10.1) >>
+>> endobj
+777 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [499.2773 389.0206 511.2325 398.1264]
+/Subtype /Link
+/A << /S /GoTo /D (subsubsection.6.2.10.2) >>
+>> endobj
+778 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [499.2773 377.0886 511.2325 386.0947]
+/Subtype /Link
+/A << /S /GoTo /D (subsection.6.2.11) >>
+>> endobj
+779 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [499.2773 365.0569 511.2325 374.063]
+/Subtype /Link
+/A << /S /GoTo /D (subsection.6.2.12) >>
+>> endobj
+780 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [499.2773 353.0252 511.2325 362.0313]
+/Subtype /Link
+/A << /S /GoTo /D (subsection.6.2.13) >>
+>> endobj
+781 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [499.2773 340.9936 511.2325 349.9997]
+/Subtype /Link
+/A << /S /GoTo /D (subsection.6.2.14) >>
+>> endobj
+782 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [499.2773 328.9619 511.2325 337.968]
+/Subtype /Link
+/A << /S /GoTo /D (subsection.6.2.15) >>
+>> endobj
+783 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [499.2773 316.9302 511.2325 325.9363]
+/Subtype /Link
+/A << /S /GoTo /D (subsection.6.2.16) >>
+>> endobj
+784 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [499.2773 304.7989 511.2325 313.9046]
+/Subtype /Link
+/A << /S /GoTo /D (subsubsection.6.2.16.1) >>
+>> endobj
+785 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [499.2773 292.7672 511.2325 301.7235]
+/Subtype /Link
+/A << /S /GoTo /D (subsubsection.6.2.16.2) >>
+>> endobj
+786 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [499.2773 280.7355 511.2325 289.8413]
+/Subtype /Link
+/A << /S /GoTo /D (subsubsection.6.2.16.3) >>
+>> endobj
+787 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [499.2773 268.7038 511.2325 277.8096]
+/Subtype /Link
+/A << /S /GoTo /D (subsubsection.6.2.16.4) >>
+>> endobj
+788 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [499.2773 256.6722 511.2325 265.6285]
+/Subtype /Link
+/A << /S /GoTo /D (subsubsection.6.2.16.5) >>
+>> endobj
+789 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [499.2773 244.6405 511.2325 253.5968]
+/Subtype /Link
+/A << /S /GoTo /D (subsubsection.6.2.16.6) >>
+>> endobj
+790 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [499.2773 232.6088 511.2325 241.5651]
+/Subtype /Link
+/A << /S /GoTo /D (subsubsection.6.2.16.7) >>
+>> endobj
+791 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [499.2773 220.5771 511.2325 229.5334]
+/Subtype /Link
+/A << /S /GoTo /D (subsubsection.6.2.16.8) >>
+>> endobj
+792 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [499.2773 208.5455 511.2325 217.5017]
+/Subtype /Link
+/A << /S /GoTo /D (subsubsection.6.2.16.9) >>
+>> endobj
+793 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [499.2773 196.5138 511.2325 205.4701]
+/Subtype /Link
+/A << /S /GoTo /D (subsubsection.6.2.16.10) >>
+>> endobj
+794 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [499.2773 184.4821 511.2325 193.4384]
+/Subtype /Link
+/A << /S /GoTo /D (subsubsection.6.2.16.11) >>
+>> endobj
+795 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [499.2773 172.4504 511.2325 181.4067]
+/Subtype /Link
+/A << /S /GoTo /D (subsubsection.6.2.16.12) >>
+>> endobj
+796 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [499.2773 160.4187 511.2325 169.375]
+/Subtype /Link
+/A << /S /GoTo /D (subsubsection.6.2.16.13) >>
+>> endobj
+797 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [499.2773 148.3871 511.2325 157.3433]
+/Subtype /Link
+/A << /S /GoTo /D (subsubsection.6.2.16.14) >>
+>> endobj
+798 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [499.2773 136.3554 511.2325 145.3117]
+/Subtype /Link
+/A << /S /GoTo /D (subsubsection.6.2.16.15) >>
+>> endobj
+799 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [499.2773 124.3237 511.2325 133.4295]
+/Subtype /Link
+/A << /S /GoTo /D (subsubsection.6.2.16.16) >>
+>> endobj
+800 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [499.2773 112.292 511.2325 121.3978]
+/Subtype /Link
+/A << /S /GoTo /D (subsubsection.6.2.16.17) >>
+>> endobj
+801 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [499.2773 100.2604 511.2325 109.2166]
+/Subtype /Link
+/A << /S /GoTo /D (subsubsection.6.2.16.18) >>
+>> endobj
+802 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [499.2773 88.2287 511.2325 97.3344]
+/Subtype /Link
+/A << /S /GoTo /D (subsubsection.6.2.16.19) >>
+>> endobj
+803 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [499.2773 76.197 511.2325 85.3027]
+/Subtype /Link
+/A << /S /GoTo /D (subsection.6.2.17) >>
+>> endobj
+804 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [499.2773 64.1653 511.2325 73.1216]
+/Subtype /Link
+/A << /S /GoTo /D (subsection.6.2.18) >>
+>> endobj
+744 0 obj <<
+/D [742 0 R /XYZ 56.6929 794.5015 null]
+>> endobj
+741 0 obj <<
+/Font << /F37 747 0 R /F23 682 0 R /F21 658 0 R >>
+/ProcSet [ /PDF /Text ]
+>> endobj
+807 0 obj <<
+/Length 3353      
+/Filter /FlateDecode
+>>
+stream
+xÚí�Ks7€ïú<¤j¥ƒ°x€ÝÖ^v”rd¯$W¶6É�&ÇËâPáÃŽ÷×/†`š"¦%8~È�J‘’¦§›Ýß4º
Ì�õ¨û�õŒ"TXÙÓVE™ê
&;´7r{¾Ãü1ûá }xÔáåÎߟ	ݳļè]¾ç2„Ãz—Ã_w�^ž]žœ]^ìý~ùÓÎÉe<)T̨¨ÏøÇί¿ÓÞÐéÿi‡a�ê}p?P¬å½ÉŽT‚()DøÍõÎÅοã	Á_W¢©¢„!Êp�ø$\€OÂ8'Æjg�²¤îoõG)wŠëâgàpÁˆ1T:õa‹Ùr¾(‡ûïÊ�s0<·2ÄrSøƒ/ýE9)«ÅÞ>Wt÷ù¬?™ôg{ûFÒ]²·¯èx‘Ö~ŠÜ­€+nHÁ)k}º¡Ù¨×¼9‡1rûPp3f›ç_Ŭذ#0�²#ÕÞ#5)´f‘N¿(1Çåo”òj¼O«æ7ýjؼy=ï�Êú­x˜œt\˜
Ä
+[|ìtBÜš

Ä Y›î†&a
ª½…†9+ZhÄ�ÐüoZ•ih¨¶ú®dÌcN=wÁÜ�
Ä`Z§é†)aª=ÂTXKŒ*d“ü"0Ý��´b�gØŠnÍ…
+"Ь…MÓNhRv ÐàÚ™’Dkm{…ÑÄR&
+PíqPÖ•”ÊÚH
÷ƒÀñx>X&Âýó	B~Óðë¹öèÃ\B  BÈZŒt÷ôhÊ„\{Kˆ¡DPi"!ÂrQ.ãjäGõË+䶾Ìç'x8› ˆñ#¨m7?	;0~Pí-?…!BÚØËÔí늟Óê}9UáÏý››ÓØçœÓWïÝÁ܈m+½˜ÍÄ�QÂIØ�1‚joQ+ÛVDyF^.®ÊYÃíæwµ¤2nÊ’Ábü¾nW„dOy
+^ÌfbŒÀ(aŒ$ìÀAµÇzUII¤°¼e$¶/®¥L¬Ø®f2,ÆýðòüôùéYbÑNj"‰þ¸5¤öö­b�u[th6.@ÃÌt¯¿¤ìÀpAµ·¸N¤‘àÂsp9=;zñúø$µ™MZˆ.^¸x|y%¸2 ˆ�C…�’°ÕÞ‚Â)q¦X
+"x¬Èt/ñ§ì@ðØÔÎ÷”HíJ}^¯è­¥Û¼\”ƒål¼øØüt4uùaXÎúͺ§ß©�
÷óØ´xó¼+‰n�Óa~ÚКZû”'Z*߉®jüzíó`0(çóè–Å*¯Mýõb<_¬þ&·kžùW]pxöU±«£(aFª=Ò¤(Ñ–úž•¤ö–»ôm™d~Ä<ºšM§‹ÄÀ*$¡’‡Ãê•ÎÄXm‰pEØÿY.–ãaêT†8T�?쉯à
+±!¨ÙÄAŒX�éÞû‘²#ÕÞ–NÀ%²íº|²>TÌqisƒN|ᚇºð¤zßT†ÓªÙ ,
+ñtb'WÁóÙ\
AŒ+YŒ«„W¨ö–«º'5”E®ÂRßëyœyO· ®1–…Ô7ïLkoãgËjÐlu—ú)¶�P·gC1¨`X1¨v`P¡ÚãðÊ$±\ú¥É¸Q­skb[ÞjU<ñÅÁN`‚O³�
‚00f0	;0`6´§º aëù	çªñ]Ðåclw6]¾¹.çWnüªóQ—{âîÛì@
¤ÙY·¬{<âŽM­©ëG7z+?E{�£édö]¼j†iç™I=M 嶵ɾ¢‚—s/( ‡\Ok1D¸Ù4ÃS‡tQXB­¿Óø
}«µõÅß|¯\Mýíg¦³wîºúgóÓÕôCófЋíÍK}�Ú¨ÙèsötÎpÕ�§ýà«ÇÑ¿\*gæ
�·Ñ'ÙÑ‚X¸×|ŽÄ;apT{ÌJ׫ú^zUÁÕ	ã´4«‹ùXÌÅݸGWýj´VãùÁx6S’gËÉ›z†Ú™ñ
+ùè¦l€ ÆÀZv` Ú#Rfü��&Ö\¿Ô;%Ú«öèÖuý¼ôWñ�åõ�»h¥ÜŽ÷B)x;% ˆ¡´M¥„JÚ“Õ„~BüÀerÎwnnÊj8”ÝóÍQìÞ%ÀJ0hŽéÞ`O‡ù`CkòrbŒ&TãƒzÕÚyað®š~¸.‡£:¥Ö{à¹ÝV^ùWOpnöÕ±«#&aFª=–_ÜÖó½Ftjxl}	5™öp6.ý®éÇóÅtöq}+uˆ�Ï.n�ØͺPAÙãA!:+(ˆ °…”
+¸ö�D¸ÑDRÁ<	¼I"Ï˪œ…
++ù¼|ëGê*ÜmsZ½]-¯¦Ë
+û´ÖŸ¢ï²Á
+ Ó=kVÙîûßáé0WlhM\Ì
+¢•lâp¸V…ÝŽG�*i~?7¿Æxä^wP¹îÖâ�@–²�
×a3Œhk™‡�7°]MëNé-m_�6A
+at�ûÒæåö¡`Š¶Ûç¯Îhw‘˜2Ã
Uq+,1þþÌÃÕ`_§¶j>/õ“ÙGõ3y¤T[¦>LÞÝÙ,µrJ ˜Œv?w.a¦;r¤41îŸI®�4�ªÕãoJbËÐ_e(¸:" ˆQCÉhwÝ™2ãUA’ŠX!
+’j@ªú“r¸?¸*ïÓêí^ýP¼-AŸLPðq6A@#Æ�Ñîê”!A¨úH�Äjã;—úÖÊ[ùT¤¶9èÓ	
+>Î&bÁ2Úý
+endobj
+806 0 obj <<
+/Type /Page
+/Contents 807 0 R
+/Resources 805 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 659 0 R
+/Annots [ 809 0 R 810 0 R 811 0 R 812 0 R 813 0 R 814 0 R 815 0 R 816 0 R 817 0 R 818 0 R 819 0 R 820 0 R 821 0 R 822 0 R 823 0 R 824 0 R 825 0 R 826 0 R 827 0 R 828 0 R 829 0 R 830 0 R 831 0 R 832 0 R 833 0 R 834 0 R 835 0 R 836 0 R 837 0 R 838 0 R 839 0 R 840 0 R 841 0 R 842 0 R 843 0 R 844 0 R 845 0 R 846 0 R 847 0 R 848 0 R 849 0 R 850 0 R 851 0 R 852 0 R 853 0 R 854 0 R 855 0 R 856 0 R 857 0 R 858 0 R 859 0 R 860 0 R 864 0 R 865 0 R ]
+>> endobj
+809 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [527.6238 758.4766 539.579 767.4329]
+/Subtype /Link
+/A << /S /GoTo /D (subsection.6.2.19) >>
+>> endobj
+810 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [527.6238 746.5215 539.579 755.4777]
+/Subtype /Link
+/A << /S /GoTo /D (subsection.6.2.20) >>
+>> endobj
+811 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [527.6238 734.5663 539.579 743.5226]
+/Subtype /Link
+/A << /S /GoTo /D (subsection.6.2.21) >>
+>> endobj
+812 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [527.6238 722.6111 539.579 731.5674]
+/Subtype /Link
+/A << /S /GoTo /D (subsection.6.2.22) >>
+>> endobj
+813 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [527.6238 710.656 539.579 719.6122]
+/Subtype /Link
+/A << /S /GoTo /D (subsection.6.2.23) >>
+>> endobj
+814 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [527.6238 698.7008 539.579 707.6571]
+/Subtype /Link
+/A << /S /GoTo /D (subsection.6.2.24) >>
+>> endobj
+815 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [527.6238 686.7456 539.579 695.7019]
+/Subtype /Link
+/A << /S /GoTo /D (subsubsection.6.2.24.1) >>
+>> endobj
+816 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [527.6238 674.8901 539.579 683.8962]
+/Subtype /Link
+/A << /S /GoTo /D (subsubsection.6.2.24.2) >>
+>> endobj
+817 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [527.6238 662.935 539.579 671.7916]
+/Subtype /Link
+/A << /S /GoTo /D (subsubsection.6.2.24.3) >>
+>> endobj
+818 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [527.6238 650.9798 539.579 659.9859]
+/Subtype /Link
+/A << /S /GoTo /D (subsubsection.6.2.24.4) >>
+>> endobj
+819 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [527.6238 638.925 539.579 647.8812]
+/Subtype /Link
+/A << /S /GoTo /D (section.6.3) >>
+>> endobj
+820 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [527.6238 626.9698 539.579 635.9261]
+/Subtype /Link
+/A << /S /GoTo /D (subsection.6.3.1) >>
+>> endobj
+821 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [527.6238 615.0146 539.579 623.9709]
+/Subtype /Link
+/A << /S /GoTo /D (subsubsection.6.3.1.1) >>
+>> endobj
+822 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [527.6238 603.1591 539.579 612.0157]
+/Subtype /Link
+/A << /S /GoTo /D (subsubsection.6.3.1.2) >>
+>> endobj
+823 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [527.6238 591.1043 539.579 600.0606]
+/Subtype /Link
+/A << /S /GoTo /D (subsection.6.3.2) >>
+>> endobj
+824 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [527.6238 579.1491 539.579 588.1054]
+/Subtype /Link
+/A << /S /GoTo /D (subsection.6.3.3) >>
+>> endobj
+825 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [527.6238 567.1939 539.579 576.1502]
+/Subtype /Link
+/A << /S /GoTo /D (subsection.6.3.4) >>
+>> endobj
+826 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [527.6238 555.2388 539.579 564.1951]
+/Subtype /Link
+/A << /S /GoTo /D (subsection.6.3.5) >>
+>> endobj
+827 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [527.6238 543.2836 539.579 552.2399]
+/Subtype /Link
+/A << /S /GoTo /D (subsubsection.6.3.5.1) >>
+>> endobj
+828 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [527.6238 531.3284 539.579 540.2847]
+/Subtype /Link
+/A << /S /GoTo /D (subsubsection.6.3.5.2) >>
+>> endobj
+829 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [527.6238 519.3733 539.579 528.3296]
+/Subtype /Link
+/A << /S /GoTo /D (subsubsection.6.3.5.3) >>
+>> endobj
+830 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [527.6238 507.4181 539.579 516.3744]
+/Subtype /Link
+/A << /S /GoTo /D (subsection.6.3.6) >>
+>> endobj
+831 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [527.6238 495.4629 539.579 504.5687]
+/Subtype /Link
+/A << /S /GoTo /D (subsection.6.3.7) >>
+>> endobj
+832 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [527.6238 473.5253 539.579 482.2574]
+/Subtype /Link
+/A << /S /GoTo /D (chapter.7) >>
+>> endobj
+833 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [527.6238 461.59 539.579 470.5462]
+/Subtype /Link
+/A << /S /GoTo /D (section.7.1) >>
+>> endobj
+834 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [527.6238 449.6348 539.579 458.7405]
+/Subtype /Link
+/A << /S /GoTo /D (section.7.2) >>
+>> endobj
+835 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [527.6238 437.6796 539.579 446.7854]
+/Subtype /Link
+/A << /S /GoTo /D (subsection.7.2.1) >>
+>> endobj
+836 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [527.6238 425.7245 539.579 434.8302]
+/Subtype /Link
+/A << /S /GoTo /D (subsection.7.2.2) >>
+>> endobj
+837 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [527.6238 413.7693 539.579 422.875]
+/Subtype /Link
+/A << /S /GoTo /D (section.7.3) >>
+>> endobj
+838 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [527.6238 391.8316 539.579 400.5637]
+/Subtype /Link
+/A << /S /GoTo /D (chapter.8) >>
+>> endobj
+839 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [527.6238 379.8963 539.579 388.8526]
+/Subtype /Link
+/A << /S /GoTo /D (section.8.1) >>
+>> endobj
+840 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [527.6238 367.9411 539.579 376.8974]
+/Subtype /Link
+/A << /S /GoTo /D (subsection.8.1.1) >>
+>> endobj
+841 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [527.6238 355.986 539.579 364.9423]
+/Subtype /Link
+/A << /S /GoTo /D (section.8.2) >>
+>> endobj
+842 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [527.6238 344.0308 539.579 352.9871]
+/Subtype /Link
+/A << /S /GoTo /D (section.8.3) >>
+>> endobj
+843 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [527.6238 322.0931 539.579 330.8253]
+/Subtype /Link
+/A << /S /GoTo /D (appendix.A) >>
+>> endobj
+844 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [527.6238 310.1578 539.579 319.1141]
+/Subtype /Link
+/A << /S /GoTo /D (section.A.1) >>
+>> endobj
+845 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [527.6238 298.2027 539.579 307.1589]
+/Subtype /Link
+/A << /S /GoTo /D (subsection.A.1.1) >>
+>> endobj
+846 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [527.6238 286.2475 539.579 295.2038]
+/Subtype /Link
+/A << /S /GoTo /D (section.A.2) >>
+>> endobj
+847 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [527.6238 274.2923 539.579 283.2486]
+/Subtype /Link
+/A << /S /GoTo /D (subsection.A.2.1) >>
+>> endobj
+848 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [527.6238 262.3372 539.579 271.2934]
+/Subtype /Link
+/A << /S /GoTo /D (section.A.3) >>
+>> endobj
+849 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [527.6238 250.382 539.579 259.3383]
+/Subtype /Link
+/A << /S /GoTo /D (subsection.A.3.1) >>
+>> endobj
+850 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [527.6238 238.4268 539.579 247.5326]
+/Subtype /Link
+/A << /S /GoTo /D (subsection.A.3.2) >>
+>> endobj
+851 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [527.6238 226.4717 539.579 235.5774]
+/Subtype /Link
+/A << /S /GoTo /D (subsection.A.3.3) >>
+>> endobj
+852 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [527.6238 204.534 539.579 213.2661]
+/Subtype /Link
+/A << /S /GoTo /D (appendix.B) >>
+>> endobj
+853 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [527.6238 192.5987 539.579 201.555]
+/Subtype /Link
+/A << /S /GoTo /D (section.B.1) >>
+>> endobj
+854 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [522.6425 180.6435 539.579 189.7493]
+/Subtype /Link
+/A << /S /GoTo /D (section.B.2) >>
+>> endobj
+855 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [522.6425 168.6883 539.579 177.7941]
+/Subtype /Link
+/A << /S /GoTo /D (section.B.3) >>
+>> endobj
+856 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [522.6425 156.7332 539.579 165.8389]
+/Subtype /Link
+/A << /S /GoTo /D (section.B.4) >>
+>> endobj
+857 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [522.6425 144.778 539.579 153.8838]
+/Subtype /Link
+/A << /S /GoTo /D (section.B.5) >>
+>> endobj
+858 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [522.6425 132.8228 539.579 141.9286]
+/Subtype /Link
+/A << /S /GoTo /D (section.B.6) >>
+>> endobj
+859 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [522.6425 120.8677 539.579 129.9734]
+/Subtype /Link
+/A << /S /GoTo /D (section.B.7) >>
+>> endobj
+860 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [522.6425 108.9125 539.579 118.0182]
+/Subtype /Link
+/A << /S /GoTo /D (section.B.8) >>
+>> endobj
+864 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [522.6425 97.057 539.579 106.0631]
+/Subtype /Link
+/A << /S /GoTo /D (section.B.9) >>
+>> endobj
+865 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [522.6425 85.0022 539.579 94.1079]
+/Subtype /Link
+/A << /S /GoTo /D (section.B.10) >>
+>> endobj
+808 0 obj <<
+/D [806 0 R /XYZ 85.0394 794.5015 null]
+>> endobj
+805 0 obj <<
+/Font << /F37 747 0 R /F23 682 0 R /F21 658 0 R /F39 863 0 R >>
+/ProcSet [ /PDF /Text ]
+>> endobj
+868 0 obj <<
+/Length 69        
+/Filter /FlateDecode
+>>
+stream
+xÚ3T0
+endobj
+867 0 obj <<
+/Type /Page
+/Contents 868 0 R
+/Resources 866 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 659 0 R
+>> endobj
+869 0 obj <<
+/D [867 0 R /XYZ 56.6929 794.5015 null]
+>> endobj
+866 0 obj <<
+/ProcSet [ /PDF ]
+>> endobj
+872 0 obj <<
+/Length 2197      
+/Filter /FlateDecode
+>>
+stream
+xÚÝYÝ�ã¶÷_áG-pfù)‘y¼»¦¸ ¸¢Ý
ò�æA+qmádÉÑÇnœ¿¾C)˶|wé-РX`M�†äpæ7¿ÚlMá�­µ"T¹ÎŒ$Š2µ.ö+ºÞ»¿­XБJ%…€‡…·%4QšgëÍ|‘·«¿|ÏÙšS’¦\­ž¦½ÒL#¤Y?”?'ïvùa°Ý݆+š°»_~Ài’d:cn…-ÉÕ~‡fèÚr,†ªm‚ºXbRžFí悹Nûagai�ºi¶kì€OïÛ}^58þ˜ïƒÎý±ìÇÿ¦Š¾ÿxÌ	²¤h›¾ê‡_·Oø9Äõûc3ä¿ad[TOÇÍö»XÅ6C5T(Í’êŽ%
Ý$8£;cÄ(Å£Âa§‰;ˆà,ÉñqWÙ.ïî˜NŠ]Uä5J÷yÓ€›3™¼
�Ðh�{ÓÝéd¬Ýæn‘±·%ÊŸÚ¥­í6ªfö‡]ÛU˜yDIûlƒ®?\Ø!oÂJa+Nò>;ó'ªö‡ÚîÁ¹�놃¡Ã.wáÊT’Ø×õåûüÐã(ºT¼ÏA4‹³›X–Þ¶ïmOÀ-ˆ*ª–ù�£ZÕÇ•+° jœܳ‡ˆ[·~­v< ¢·›@ÒU�ãàQKñpR·ùcî­Š˜g’™ò€bI	Obž
+ôœA)*ìaˆÔqf§†d
+DÖñ›Öñ 	R
+}å7A,û�+£c”ú…%%”Æ8yÿiU¢¿^OI¢�0SÔƒ©C�>”‚e”<÷á!8|V5T•Ëã­Wóø·áÕÓØøú*ÉsUž›�vð>¯Jœ‹–D‚A G
+OyùœCÖ•“¦Ï@´64* >2óNgÃŒ&ÌõÀçUlN¾.ÝR Ñ#ë›0Hõ§øn*·Ø†�¤°ÝàK­{hîôËŒ�B/-RvÍi¢n0‚b‰ÒHUéŒ�
+êj»^¬ûh‚*"¸‘K4Ñ·õ3v£®tgihM2îc`ˆŠw.°Ëº>,)…¼â`7!]
+>YÉàT&³ëdQ¶®ÂŠ¾QaÁô'ìL,
+¸×S^ÛIÀ“ÿõ÷7¨¹kûa¦	¼VÇêvñÍA
DŠÑ
úþ®ø�}	°ÝþüUè[o#zvÊosÜÑ—žƒ[Ñ¢gžû¾úÍql
+ôûR•Ãî6x_ÍÞ?xc _‘©!RªôKàe‚PÁ#ĆSY
VébÍ;ŒŸÁÏl£WcÄK㡪/ágnü@?y
+š[}¡[Ày5sÿ,¸áî‹®Œ¥î
+ADÆåüg¿«Ÿÿ¸§` Ô
˜¯µ^ü�0þô·Š¸_Ñ# §r”\²+·Ç_O+ÅÝþ-Õ«endstream
+endobj
+871 0 obj <<
+/Type /Page
+/Contents 872 0 R
+/Resources 870 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 886 0 R
+>> endobj
+873 0 obj <<
+/D [871 0 R /XYZ 85.0394 794.5015 null]
+>> endobj
+6 0 obj <<
+/D [871 0 R /XYZ 85.0394 769.5949 null]
+>> endobj
+874 0 obj <<
+/D [871 0 R /XYZ 85.0394 582.8476 null]
+>> endobj
+10 0 obj <<
+/D [871 0 R /XYZ 85.0394 512.9824 null]
+>> endobj
+875 0 obj <<
+/D [871 0 R /XYZ 85.0394 474.7837 null]
+>> endobj
+14 0 obj <<
+/D [871 0 R /XYZ 85.0394 399.5462 null]
+>> endobj
+876 0 obj <<
+/D [871 0 R /XYZ 85.0394 363.8828 null]
+>> endobj
+18 0 obj <<
+/D [871 0 R /XYZ 85.0394 223.0066 null]
+>> endobj
+880 0 obj <<
+/D [871 0 R /XYZ 85.0394 190.9009 null]
+>> endobj
+881 0 obj <<
+/D [871 0 R /XYZ 85.0394 170.4169 null]
+>> endobj
+882 0 obj <<
+/D [871 0 R /XYZ 85.0394 158.4617 null]
+>> endobj
+870 0 obj <<
+/Font << /F21 658 0 R /F23 682 0 R /F47 879 0 R /F39 863 0 R /F48 885 0 R >>
+/ProcSet [ /PDF /Text ]
+>> endobj
+889 0 obj <<
+/Length 3125      
+/Filter /FlateDecode
+>>
+stream
+xÚÍ]“Û¶ñý~…u3‹~öíÛ�3“sb«“i�<P"¤ã˜"’:ùò뻋]P¤„³Ý6�fî�+`
ìö'þä"Šƒ8SÙ"É 2Zl7b±‡¹¿ÝHÆY9¤Õë›õÍ_^ëd‘Y¬âÅz7Ù+
DšÊźø°”AÜÂb¹þîÕíJEbùòíwoî	¾¿û�GßÿãýúÕÿ""ñòþ=|äíJÊ8Ëo¿»ûqýêÍKÞòÍýúÝÛ—ÿvýæíýí¯ëïo^­Gª§œI¡‘äßn>ü*0øý�t–F‹ü�Ì2µ8Ü„‘¢Pk7Rݼ¿ùiÜp2k—z%%E t¬<¢RÚ'ª(b
S(ªõƒ!övMU5§²ÞÓÏmS?šz(›º§�¼»•é’‘�½)*kú¦ßve;YÐìè;¸¾ysÿrÜü!ÔþØå¸ÀÉ_¨ÊüõR¤qÄR
+h�€½t+æ[­O«D« ’ᨯpjÚIdi²Ht¶$bR×­”rÙLe¾
™­dª´^þ|«ÄDEòï‡'�|Ã,	2™á9#-ÿw(G
wñ"0%‚(‚½½î$¦àö…Qh%öÑ<�k»E�¼ƒÿÈ&K”JèDa±_—ŸÐ²c!–?—Åðð¼´ˆ�ìO..
�
+3o­»Ë+ç	Ûã
+Ë~€Ìá8XWèE>䛼7�ãêìa á~ ÐizÚ®¬wMwp¦ð“fy»ò	¿%µbÞìl~ÉåCÓ4^c=�VÔˆú#!åEÁÇ÷…l
+€ÇrkëÑt}nS@FYѨ]؇ñü	íYŸ÷j@û�(ÚÀæ¸3ŽÈ{lØN&ü µm¶ùo0.ƒØŠÔ.û¶*AÿÖÚ¢eÕ4	:¶ô�KÖЗӷÈ\�[¹|"4ZqÊ�Ê­eÍrH…î=�CÙ,ͦ™yìPk/Z2rUB êžlÆù‚Î;�=Ði½©ææ·£éJ« @¡ëWµfº­…À÷À¦ä¡µ¨,‹æ¶S[“×ö°µì!|
+
‘(¶
+ÕVx ›–ÎC™k'HX-hÊ€®V±ŠèÊá$yI„2>zæäpd¼<VW8õÌ
+|	„S»P
+B
×ó9õÅ|›4´£xx qFPB¬ßæ©kɆO’ÉiišÁ#[	%J;…ûS8„J#E9%óhº¦\8ä̾¤rvÞe(GA„š¾§®Ã?0j”óúœ>è£mdØ
+¾•“Â` nç‰p�€rÿ0h…‚ÈfÇ#äbpÓæ`àn›À·h´p(©–w¾|È’@Ž©6®lꊓŠ�ëÞÔ%DU‚O%ìÌÊ�]]Ë7¿æüƒÏ›y¼¶÷2ŸòC[ÙËD.
G‹˜-R÷�[ÃXœ®áÀ@dB0°mm^ûÜœ‚h¡uì®ã«Ùñoêmà‹çI�ÆÚ¹Æms¬
+:fc<	
µ".ÆnŽÒ0Ÿ
Pæ3P©ƒ(	åxûÉ:#ˆ0fÚ:a^xNZæÝ̬T2Rê=@‘:Gƒ.³”D50˜WK#•yD«@ÐéÃ"6„Gi×5	Ò
+Xÿ»üGAfn˜cSï]Z0—.zSá8ä]}I�R™f\æD{Üœý0¸Í4	’0Œæ^
+b5:”ÀyÈ,º¸+¤€$u9@yß7Û’C.üƸH«#™D³dŒf
+Î
+J�}¹¯¹šÛù«Í˜Û2ñLM/ :i
5
+÷&M¾d)#þjºàZK×û^ÙÊ�ÏVøË8–rFÏõÛ‚Ãú×»=ßÆ@Š³8UWmÍmŒ>v/›øª„JÓ£¯mM‡ÅŽ lÛÖZe¶â×cú Å¬Õ+Ö4a“	XQБä5|ÔíC2:Íñ�¢Ü!;­õ–OÞ˜ád°>C$_œEI¾Ò“”×qHHS9kí=³¡­-¡:½Åø—êw½ypv»ï¸)
+S™ýä-ç깇bë¤Â�ˆ;=Ÿµmê®c?Ý*؇ñù	»”åþèmÓ+ô‚¥ÿ±%:W€Ï�$üE‰
+endobj
+888 0 obj <<
+/Type /Page
+/Contents 889 0 R
+/Resources 887 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 886 0 R
+/Annots [ 896 0 R 897 0 R ]
+>> endobj
+896 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [272.8897 210.0781 329.1084 222.1378]
+/Subtype /Link
+/A << /S /GoTo /D (types_of_resource_records_and_when_to_use_them) >>
+>> endobj
+897 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [190.6691 182.1322 249.6573 191.5418]
+/Subtype /Link
+/A << /S /GoTo /D (rfcs) >>
+>> endobj
+890 0 obj <<
+/D [888 0 R /XYZ 56.6929 794.5015 null]
+>> endobj
+891 0 obj <<
+/D [888 0 R /XYZ 56.6929 756.8229 null]
+>> endobj
+892 0 obj <<
+/D [888 0 R /XYZ 56.6929 744.8677 null]
+>> endobj
+22 0 obj <<
+/D [888 0 R /XYZ 56.6929 649.0335 null]
+>> endobj
+893 0 obj <<
+/D [888 0 R /XYZ 56.6929 609.5205 null]
+>> endobj
+26 0 obj <<
+/D [888 0 R /XYZ 56.6929 551.1302 null]
+>> endobj
+894 0 obj <<
+/D [888 0 R /XYZ 56.6929 525.7505 null]
+>> endobj
+30 0 obj <<
+/D [888 0 R /XYZ 56.6929 422.4834 null]
+>> endobj
+895 0 obj <<
+/D [888 0 R /XYZ 56.6929 395.8284 null]
+>> endobj
+34 0 obj <<
+/D [888 0 R /XYZ 56.6929 166.2827 null]
+>> endobj
+898 0 obj <<
+/D [888 0 R /XYZ 56.6929 138.253 null]
+>> endobj
+887 0 obj <<
+/Font << /F37 747 0 R /F23 682 0 R /F47 879 0 R /F39 863 0 R /F21 658 0 R >>
+/ProcSet [ /PDF /Text ]
+>> endobj
+903 0 obj <<
+/Length 3414      
+/Filter /FlateDecode
+>>
+stream
+xÚ¥ZKsã6¾ûWè¹jÍàA
+a²¢´á¦�f²”™ËÕW„\€Ž™ ®¯Ë÷tÎ
+Bƒc34ÏõÈå‰â‘=½ r‚
öÇÇGÒ}0N:
+$¿vG"‘ÂUk"þð}O-ˆÂ´7¤›9½D¸×ð”Q½X4


+Ú½¢¤bü²êÿr…û€º–Èuüç˜â�ÙK
Šy{„°ëÐÆáäÍ0Å#÷—Ì‚² _Xy‡«4Øòǧ�Çšh>½�§Ç*x¶uÕs¿K�Á¶ÑOuÊ-~Çf->øDÄ)Ày•ZNŽ/£øLeð~È¿Qt
œOpÈëj¨¨EçÄ#é˜,¬`ÎÊ9ntáæ‹ëRÍÑO8Xð„òuÇ ‰¢¤tm}¨|Bd®@
*�4‚I îêá¥;<õ¡jÚ#GCè‰c?ÐH¯4nã5ϯôÒQ£ã‰c†é©,é›RM•…#$΃B2Ü?Ô§ù"³Ü'
ýsÝï
ï(áqór·[|+ÎðÊÔÏûRÁ]Cñüâ3ttý�=FÜÞúÊ…ï_úxÉÏÏ
JÓŠqf–³ç–ºöÕê))ªz@¸4ºW@áüù÷1�Ýá•iQ ùÜ
È@}!´úº^‚ã'T�¯:Ø
+n±=*‚«w
zŒÐx¢KìÏñ¸‹¨i{
+˜0¸†¥^!ž¥ð
+ÍÈ)´c‘Â|Fæ�æ¡f63
+O=°& wœWðdcZ*…—™¤µùiÙȸýd‰ƒ6™Ì]Ь.dJÐæ&õÅYs™©MÔ>²�W˜S·ùñMš fHÁWUOA
+fD
+_tÀ€ÌvØüM„ù¹…S &cÃQðføˆ‘€:úMÏ£Î
+4´â9§îåÌüváâ}Ï1[,ò\\ÔG	S=Ÿ^ÌÉ:ÐmZc´“1àp¨­/÷‚ã~¤Fñ_	[€ƒUÁÁÒß.¨rlõØpŸ…Ô8èm¨þ�°�·ì§_Såþpäœþå‘óß-¦ëE*ý�CŸ«g
¶ÌŒÖgeŽÑAè)�èpÅÔ%_*{ Ðå7‚¤§ºÞûÀ(Þb1AÓ!ñG¢·Âñ¦+ܪ³_Ç¥÷uÍ7kÇ=uU+
+¢ü
XÇÃÕXT
�p~ÅCê,x^®¤zç;š›ˆ|¦„§¹`õ\5mµ)"_œâ€´íÙ$X5ìÆ‹¬¦j¹Ž8Bé…D›^¿šr
+¡‚—†HÙ[�‚ÿï”(L‰Xãÿ¿ÿV5þ»,w™.
+•®piQâEpd
+�£¼(
+endobj
+902 0 obj <<
+/Type /Page
+/Contents 903 0 R
+/Resources 901 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 886 0 R
+/Annots [ 906 0 R 907 0 R ]
+>> endobj
+906 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [519.8432 463.1122 539.579 475.1718]
+/Subtype /Link
+/A << /S /GoTo /D (diagnostic_tools) >>
+>> endobj
+907 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [84.0431 451.8246 133.308 463.2167]
+/Subtype /Link
+/A << /S /GoTo /D (diagnostic_tools) >>
+>> endobj
+904 0 obj <<
+/D [902 0 R /XYZ 85.0394 794.5015 null]
+>> endobj
+38 0 obj <<
+/D [902 0 R /XYZ 85.0394 570.5252 null]
+>> endobj
+905 0 obj <<
+/D [902 0 R /XYZ 85.0394 541.3751 null]
+>> endobj
+42 0 obj <<
+/D [902 0 R /XYZ 85.0394 434.1868 null]
+>> endobj
+908 0 obj <<
+/D [902 0 R /XYZ 85.0394 406.5769 null]
+>> endobj
+46 0 obj <<
+/D [902 0 R /XYZ 85.0394 301.1559 null]
+>> endobj
+909 0 obj <<
+/D [902 0 R /XYZ 85.0394 276.6843 null]
+>> endobj
+50 0 obj <<
+/D [902 0 R /XYZ 85.0394 200.1512 null]
+>> endobj
+910 0 obj <<
+/D [902 0 R /XYZ 85.0394 175.6796 null]
+>> endobj
+901 0 obj <<
+/Font << /F37 747 0 R /F23 682 0 R /F47 879 0 R /F39 863 0 R /F21 658 0 R >>
+/ProcSet [ /PDF /Text ]
+>> endobj
+914 0 obj <<
+/Length 2458      
+/Filter /FlateDecode
+>>
+stream
+xڥ˒ã¶ñ>_¡[4Uš
+Yþýî×ßÂU	üù.TžÅ«LÂ@ä¹\5wQ¬‚8RÊCê»ç»Œg«n뢤DH•ÈQIµ$ª8K(ªwp9®‹®ý†òe8j[u-
O{s¼ÙÚÐÔîyp8V�>žiÒèÞš÷æøêÇ•íM½ãqO_ÍhÖèÚîö0^·³†y væHƒ’Yé˜ Û <á¯RFûª,a3(¤zò8–îªÌ6"
z]_ô«âhý¹5´<ô<ØuÈ_ƒ‡·[	H‹1Ê�!$2
+ëÖòT„
+‚>a·£ßÑÉå£-}ùÞý©àÓA"U¾x¬Û\wÝ·á°dý)^Üï¤`êðIxåº2­í6ð0
+¢,‚Ì&Ò W2%ÿ¿Ïåô£’l]5ÞÇ
rϸn&
™òšAÜÕs¨q;
+G·{¦Â
+jÛÓ
+ú.X�êïè÷�/Ž�'·Ÿ+`cÚ¸˜‰F¿r¤rrÙ(œóíl–(ÊG¡ã™¼¡cp€IÕZÈ/–?r鼿3ÎA"Á6�wÕ«€½0UohN`K½UnP*yí"¯Æ“2çâoÒ-ÆAžÇÙ•ãÌó›¯0ÕõÞgúsÛµç¦z�†€â U07'*fÒumÚªERR�aò*Y+Nûª`,M%Ü’`�>…­™#Y]µ†Qª–¾Ö3À–ˆ»èüñ„IP0a×…ÑT1¥\1e¨pKFå‚Ç‚ÍmÏW)}sÇëªgä^8þeôi¬‰7›_¨&&@(Mí£SßwEfW^×
F<òAspƒÂÌ¡^vS)q‘ý!Ï	1«è¡°àZâ§îxÒÇeó?놯d"	ÅÜd&U˜ø€˜ÌBqº.;ç–¸ÞYôV¨2¨HJf9&,Ô««Cm,Ïn¢d„ÆT"c¦�ù”Ñt‡ñY)Ÿn—ªì|ÒhŠ¯(›¥T
+�i�â;.Pw…°s7¨ì@Va$ê÷´DF…Þ˜óY€GZF£éKõê‰÷•]ÌÝÎ\‰)ZˆÂÒì²ÖEC•(_=HyrZ~DŠ­áefkŠ(Å6Ýá’P£0-$æçÔ
—‰µWìDh¢‰‰vh¶d¹×"o�èB­#®bê<‰&dg°¬[Ìx†ÙeÇêÞKÔØá¹}¾#Elr|¨¶uÏ«]|3–ϲ{ŠÃËÞ¡ýQcLÖÇÂ�JÍý
’<_±Z0F~tmŒ0Öºå’ñ+‹áE%\�!¥yNb<[:·;_�6IÁÔ~�Lô¥ÊO½U>Nšš÷ÿþÂÁÌ· ®CO8«Þ6åÔp…õ	êâêàŸ¾tµùÓ]{®x|zO#ßzͺŸ4dq#°jà Ý*à MïD7ÃE­SzHJgoO0¦J
	tžþ ”b„[@X¬õ«¹ÚÀiçfG»XGM	ƒ»µÙ³–K9*œæ�ÞØ�] õõì·FW5ìÇîd¦ÌI蓹õȹäW9œ6´6¬=M�»Ã:·Þ¾ËÆ%ÒŽ�Ûªà	9=lá»~Ý[½µUÌŸR®åXw/c|ÏpÛA¡”Ä‹I¥EÆ©#Í}¥� ]¾êÖê4‚¸@’bÿ–A€aØÞ44êÚË×ëWw/ãbmž»X›…ÎÓ—bgëŸf�NÎF“k
Ï_’IJF³Y®ìB©ü»ÑÅwöB³i–§¾Ês—`3„£ØÍ’QVäº=MnºOX,«C6¦ˆU¤Ì.ãíÔ�SѦÈ/1•ÞVueÏ$SBCÅCL
ÚCaå.§DãZFÎàK)I]Ù/€œ_Ñ1|žóç«£Ig8ºÐÙ‚v¯Ë÷<šé-W”Iòé]	@ì®wz]ª+chft¶ýð[
+ä4	Õ’BánUàhjU
+
e*Ñ�²€Ç,EJ¡¼Mq	9jÕäå/œÆGi²5—Žøy©Ö…¯¿«vzOÖSo9¯ÞøoÒþ!²ðOH8&ºÿû—éï§(
T–Éå¿TðA8Ê€3åRjxùÿƒæ–õÿ÷Å:êendstream
+endobj
+913 0 obj <<
+/Type /Page
+/Contents 914 0 R
+/Resources 912 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 886 0 R
+>> endobj
+915 0 obj <<
+/D [913 0 R /XYZ 56.6929 794.5015 null]
+>> endobj
+54 0 obj <<
+/D [913 0 R /XYZ 56.6929 717.7272 null]
+>> endobj
+916 0 obj <<
+/D [913 0 R /XYZ 56.6929 690.4227 null]
+>> endobj
+58 0 obj <<
+/D [913 0 R /XYZ 56.6929 550.0786 null]
+>> endobj
+917 0 obj <<
+/D [913 0 R /XYZ 56.6929 525.2967 null]
+>> endobj
+62 0 obj <<
+/D [913 0 R /XYZ 56.6929 393.0502 null]
+>> endobj
+918 0 obj <<
+/D [913 0 R /XYZ 56.6929 363.1913 null]
+>> endobj
+912 0 obj <<
+/Font << /F37 747 0 R /F23 682 0 R /F21 658 0 R /F47 879 0 R >>
+/ProcSet [ /PDF /Text ]
+>> endobj
+921 0 obj <<
+/Length 2095      
+/Filter /FlateDecode
+>>
+stream
+xÚ•XÉ’Û6½û+täT�îË1Þ§*®T<9Å9`DHD
…
+wQàgY”îŽÓYYžûYš»‡êoïM-ÎFwû(
¼èßh[âçEâ¶
+JòÚC
2ã ÆÕŸÞ½!ú(…Éš8 ¬ýR¨ UÒ§7"Îtƒ‹3=}yÌFGòÍ¡:ƒ&q[êþ*AÏ»<ñÀÔq˜{š…ôVöItê+¹‚Ïø†ñ[ñd
•yµ—‘£f^¤¯©!r¤ã®¯Œ{3$®J×¼¥§ï
TP¥Xæ5¡'7Ö7mdk¥¤Þ±ÜqÓYâ|nÔ�n‚±S
+fhWü(½¾YhovçåvlŒ25©,*Yݳ÷›¦¿ªîÄqˆ�jØ|SüÍ‚Ø{©uÏ•cq�À]#Xg±¬,ÕI’Êøߨ	´8͸dD\2lL|£ælV‹„JnË`«.hš±š#A&Fªä=¢;I^4¥ŽTRdûC#4‹hÅ¡V�|.ÓÊhMË4`šÑ_ûiÓ\Õ�†+ït¿åab
\
rc8JK§	rgM¢ ÷Ô‘¸·~$Â&TE´´ð¬“a«ì¯n�hQYd�çJÉk„“âªÒZ�¨x
m¯v¿•|“UllÑY6HúQƒX½¾G9(©§²æ
+dXõcsý.Û~¸ý¿ Šç•‰×:%<ä7IE”èÚ–Ø’ª2yÑT
+hZvýxªY/ý‘áÝN6“dy 8xp]Óc~{î0¨”~‚’$¡½„3×|Ó$ý$ÈR¸2Æ/{ë³ý4±ò�Õc¯ÕW¹aµ¤ôó,ÎXT¦JP¶Ø¶ÖVDÙ6
+^AÁ³"r�
+DŽ49œvDü¹„šný~¹� æÒû/å¢õ>ÉÃP©_¬MËZç¹—ù
+ÜѸU‚>Gy%â*哦�tð–RW8
+Ÿ¤IhsÜ]W‰y
+Õmíš™Q‘‚z
+â~ó
¯	fÙ"‡èâ9Lt¨ž¹£j¡	mK(ÈÏbµ
+endobj
+920 0 obj <<
+/Type /Page
+/Contents 921 0 R
+/Resources 919 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 886 0 R
+/Annots [ 927 0 R 928 0 R ]
+>> endobj
+927 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [519.8432 268.1131 539.579 280.1727]
+/Subtype /Link
+/A << /S /GoTo /D (acache) >>
+>> endobj
+928 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [84.0431 256.1579 143.5361 268.2175]
+/Subtype /Link
+/A << /S /GoTo /D (acache) >>
+>> endobj
+922 0 obj <<
+/D [920 0 R /XYZ 85.0394 794.5015 null]
+>> endobj
+66 0 obj <<
+/D [920 0 R /XYZ 85.0394 769.5949 null]
+>> endobj
+923 0 obj <<
+/D [920 0 R /XYZ 85.0394 574.3444 null]
+>> endobj
+70 0 obj <<
+/D [920 0 R /XYZ 85.0394 574.3444 null]
+>> endobj
+924 0 obj <<
+/D [920 0 R /XYZ 85.0394 540.5052 null]
+>> endobj
+74 0 obj <<
+/D [920 0 R /XYZ 85.0394 447.7637 null]
+>> endobj
+925 0 obj <<
+/D [920 0 R /XYZ 85.0394 410.3389 null]
+>> endobj
+78 0 obj <<
+/D [920 0 R /XYZ 85.0394 348.7624 null]
+>> endobj
+926 0 obj <<
+/D [920 0 R /XYZ 85.0394 311.223 null]
+>> endobj
+82 0 obj <<
+/D [920 0 R /XYZ 85.0394 189.9853 null]
+>> endobj
+929 0 obj <<
+/D [920 0 R /XYZ 85.0394 156.0037 null]
+>> endobj
+919 0 obj <<
+/Font << /F21 658 0 R /F23 682 0 R >>
+/ProcSet [ /PDF /Text ]
+>> endobj
+933 0 obj <<
+/Length 611       
+/Filter /FlateDecode
+>>
+stream
+xÚ¥TMs›0½ó+t3EÕtÌI�;ŽÁÓvÒ£$šbp$Í¿¯@Â&Mzêx<ˆ÷vŸvßzM
+ˆ,}Q7c‚}vû ­ƒbÓJP*ݾ-Wfü¦=»DÖ+ýÉ\Kií“ù'çs·?0¦¥ÃUõW`[ïí¡”Ï²´ÇB
>Ém[7¯ŠšæWN¸ênÈÚÊQD·�ºïZ3ô¯åcõóÁª˜¯›æ/æñß*ŒKzܹénÐ8AabD\Q½Í„¾«|Üà÷¥ÿ
¦œ@šendstream
+endobj
+932 0 obj <<
+/Type /Page
+/Contents 933 0 R
+/Resources 931 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 886 0 R
+>> endobj
+934 0 obj <<
+/D [932 0 R /XYZ 56.6929 794.5015 null]
+>> endobj
+86 0 obj <<
+/D [932 0 R /XYZ 56.6929 769.5949 null]
+>> endobj
+935 0 obj <<
+/D [932 0 R /XYZ 56.6929 744.7247 null]
+>> endobj
+931 0 obj <<
+/Font << /F37 747 0 R /F21 658 0 R /F23 682 0 R >>
+/ProcSet [ /PDF /Text ]
+>> endobj
+938 0 obj <<
+/Length 1222      
+/Filter /FlateDecode
+>>
+stream
+xÚÍWI�ãD¾÷¯ˆúäH¸âZ¼©OÍ°‰Hs`8Tìrb�SeìrBƒæ¿ójs6sà
+©Ç¥·†EòS€Š2Of=§&ü¡W.tÀLFXôÚyÉß'1´¦÷fÓ¸<Žn§&=Z|KÁµ½áDnãÖ
[;ÑiteL-dçÞ^z@3Š Ñr0¡sSùØò¶Ð°´@EžQ/ëph‘@#†I¨„ƒÜkg+¡Û“€:cŒ£¯&L0À3LDc‚o`Â=æÕÔÕn¹ó"¦iâ$ü©ÏÍZ™Z}!W‰37µu£VDS' Ðò‡4A¤L\û6è@{{VnZ&ÜvœvR˜ò›ÍÙžÛñàVÚkÙRºåÜX³iuD·°qÅâUwñwñð—{à’ œˆ¡dCØËía~}øée	”®[³M#AJTyy+W·´@Aÿ­äóFèjc†£Þ=æ0Tè½>Ú˜ÍEq)·+\]gR½
=^Œl9¯ËσØÚ»Ç
+ÿ¨2ûù@[ –¤('ðVt„(þ°	F—7¯€ÑK‚sTRRx;Ö›#<鹎{žëøIÜý7¸Pé´«Õqþ›ð™˜1t6Ihb–{â^Ž­(áÏ!½Žm‰CÁe
+5€B=—âÿëÄæ�/n¸GÂä^xÞ`W>¾QAF?°9¯ª™Ù;ëƒû9âãòíÊwÁ®|»�0«ðœIª
Ÿ:½äÊ0
£•0ö1¦ÿ˜SM™^ÿ^r0m%©ßÑ1¡¨Ä	ûOèøéÛíü•¾]hŠÌ—ÐÒwP‰/2î#èñ4ÉPAÊ<2yazïmþ¤zt÷7¯Ì™øendstream
+endobj
+937 0 obj <<
+/Type /Page
+/Contents 938 0 R
+/Resources 936 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 944 0 R
+>> endobj
+939 0 obj <<
+/D [937 0 R /XYZ 85.0394 794.5015 null]
+>> endobj
+90 0 obj <<
+/D [937 0 R /XYZ 85.0394 769.5949 null]
+>> endobj
+940 0 obj <<
+/D [937 0 R /XYZ 85.0394 575.896 null]
+>> endobj
+94 0 obj <<
+/D [937 0 R /XYZ 85.0394 529.2011 null]
+>> endobj
+941 0 obj <<
+/D [937 0 R /XYZ 85.0394 492.9468 null]
+>> endobj
+98 0 obj <<
+/D [937 0 R /XYZ 85.0394 492.9468 null]
+>> endobj
+942 0 obj <<
+/D [937 0 R /XYZ 85.0394 466.0581 null]
+>> endobj
+102 0 obj <<
+/D [937 0 R /XYZ 85.0394 237.1121 null]
+>> endobj
+943 0 obj <<
+/D [937 0 R /XYZ 85.0394 206.4074 null]
+>> endobj
+936 0 obj <<
+/Font << /F21 658 0 R /F23 682 0 R /F39 863 0 R >>
+/ProcSet [ /PDF /Text ]
+>> endobj
+947 0 obj <<
+/Length 1859      
+/Filter /FlateDecode
+>>
+stream
+xÚÍËrÛ6ð®¯àøDÍD0^$ÁæäÄvêL⸲RO'Í�"!‹>’²êvúï]<HQ2e»­gÚá
`±Ø]ì“ÄÁðÇó‘ÒÐ	BŽ<L<'ÎGع…½w#bq&-Ò¤�õf6:>g�¢Ð§¾3[ôh	„… Î,ùâ2ÄÐ(`÷òäãÙxB=ì^ŸMÇžçþƒžº:›žŒîÎ.>]^�'
¹ûöÇ“«Y‹ñ4�·Ÿ.Ï/Þ}ÞÒ�½�Í:)ú’Ì”ßG_¾b'
�ß�0b¡ðœ
L0"aH�|Ä=†<ÎX»’�®G?u{»úè æF”ùtHuá�ê¼ùŒ2­ºßËBŽ'>ÆîFÀ
PZL¢$©PT­¢#³÷‡Ô¡!"€'"…žG5�æ~e	äQÝÈêµFÅ»H‹4koÉÊ8Ê–eÝ JÞía›ç,Ê&]Üü¢4(“ÁËÿ¼íøØœ½±wF•šå«®eu׋Òò·(_eÅe>ÄaOk=Ì—WV�8JæÃÚj¥½¸²ÒÂÛɺ–µ™–+fÝɾÄv?ʲr#« ÒŽUTÔù”2¿šÂd÷È#: !EÄ<„
+Ô"xÈcÏxüçYyÜ2¢JÚ7‹â=¡�¾iìbÿóÐŒŠÐ·Ž]úhþíèQس�]ûØí�ŸÐ7Xu+žz¯L_›¥ïEzïu|N‰C8b„,¸È£ˆ’Іy:ž¤>”QbBò›(‹Š8-níqÖxpš
+ä¡	u'ã	ž»ªÒ<mRõÎj
+o›HiB�™&® yG\O㨰ëöl/Sy'-vjwu”QÀ©Ê3ÿތ뺣•¯³&]e³áʸÔcR›Å_±‡ëu¼´wÕƒªïÈ(eœ˜a�Ð!fCÛ±´�* ˆr‰:Â

+
4ás�*Xëü¯`R7]¨UîÞ—câ®
¼Ô>£p›¥¹Zš�››³Þ5Ù¤ÍÒì²Ù”Õ7³¬ŒR6¡Kí—³ETf‚Üdy°SjωÁ¶ËìÕ`Œ%bŒ4Ðo
ãCÅ+,£t€"½Ò>),,JìÌ+Â4—ôØ,#K;ÎRY4vy“f™].‹BÆGZ5ʨ½*WÆTØkÊh–©aÍðѲ­ø�²IsùÃ~M@Ú0u˜Oó9yVQB ìBì%ÿìTËG/ŽäÀœÃ@Ë‚­t»¤&­LÆCÄqØ<;þ/ÂÜgƒ†ž¯ut	?žpÁˆ;›}PøîÛ'×ÊWy@ÝÙ/WPþqB}w*ër­õ[™v¶bæÊG§Ó­‡�FM´ÿ
+ß×
+ÞƲƒZéÝ÷²ZyQ7$ºMñžÒ
+dŠx¦VØa­ôî{)­l;¬ÿ":RL� 8b ¸À¸AÛê=hùh
+€¬SËþ‘.oBff¾ï¾¹¸<5û6íµ˜e5²#’ÛÛUæîÝ¿*Û�
î–Ÿû–²*ÚÝ�ùAJ§A¨k35FfH Ž�]Õ®(ä¢Q%”E挄ڦR->‚‹Bá^ØÚؚȒœ—wº<Á6õ«
£Ak””yvog†A©KÐÞÂ0ÇÝ¥-s•á•Ö9ô•ý—ñÚŒÝÜŽÄ®›ª©¿aGªd&ØýºYÙÊ+@ëÚ¦Dà΅˜Ví©]™úkͺ*d²ÇF’ÖqÔÇí¨Zãhº*•BÃÑ«RÁrs‘4³D6Qš¸Tzät«>]¼Ñ³ƒŠS‰Ï¡Ä_ªÇ�¿kaº+Ù:%D!â3ÚÞ*¨*'e•˜æhß1ò|Á,n½ž×Êrcrp…~æƒW	h_0åöt¹jR`và检ᖣî
+-”ªzå¡U$äÈ×™ÀìT·Ž
¦C¿æ¶Ø‡C�ÅQ|L§ºÞÖßúÚßã…@ŠczÌ<xΣ<ìSRL ¡¾r�©ï¡~ž!_´ý�hûKS$ê_€ö7€b%«¨ÿ¤Ë*¦Ûd~÷O’Xr³1!Ä-ˬÞëÃ>·Nt3f�k£¾ñóqÉÌz¸á…™g‹Î–©îBB°€Xñm&‰¬ã*�ëðŽì
á(3{i
ž¸’EÍuoªÐÓ趀h�Æ*ÊSÕ©åi‘Ö�ÒÅ�E2±
+endobj
+946 0 obj <<
+/Type /Page
+/Contents 947 0 R
+/Resources 945 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 944 0 R
+/Annots [ 952 0 R ]
+>> endobj
+952 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [55.6967 190.8043 126.3509 202.8639]
+/Subtype /Link
+/A << /S /GoTo /D (rrset_ordering) >>
+>> endobj
+948 0 obj <<
+/D [946 0 R /XYZ 56.6929 794.5015 null]
+>> endobj
+106 0 obj <<
+/D [946 0 R /XYZ 56.6929 480.2651 null]
+>> endobj
+949 0 obj <<
+/D [946 0 R /XYZ 56.6929 441.7923 null]
+>> endobj
+950 0 obj <<
+/D [946 0 R /XYZ 56.6929 373.7178 null]
+>> endobj
+951 0 obj <<
+/D [946 0 R /XYZ 56.6929 361.7627 null]
+>> endobj
+110 0 obj <<
+/D [946 0 R /XYZ 56.6929 167.4388 null]
+>> endobj
+953 0 obj <<
+/D [946 0 R /XYZ 56.6929 126.8733 null]
+>> endobj
+114 0 obj <<
+/D [946 0 R /XYZ 56.6929 126.8733 null]
+>> endobj
+954 0 obj <<
+/D [946 0 R /XYZ 56.6929 98.4089 null]
+>> endobj
+945 0 obj <<
+/Font << /F37 747 0 R /F39 863 0 R /F21 658 0 R /F23 682 0 R >>
+/ProcSet [ /PDF /Text ]
+>> endobj
+958 0 obj <<
+/Length 2706      
+/Filter /FlateDecode
+>>
+stream
+xÚÕZÝsÛ¸÷_¡—NåéÅA°O—Ë%×ÜÌ%×ÄiÒÌ”– ‰w©);Îô�ïÀ$EJÎø©ã
àò·ËÅ~f3
+l¦SBE.gY.IJY:[ì®èl
Ï~ºbž&	DI—ꇛ«¿¾Ù,'¹âjv³ê`iBµf³›å§ùË¿¿øõæÕû넧t.Èu’*:ûâ—W¸ò
¥éüŸ�âå»·¯ßüôñý‹ëLÎoÞ¼{{�d4—ðæåwßýúêñ½ןo~¾zu¿¢û¥Œ
+û	\}úLgKøàŸ¯(¹Ng÷0¡„å9Ÿí®d*H*…+Û«Wÿˆ€�§îÕ1Í¥B“TólDuœ�©.͉\8ÕÙof„]'ŒR:ÿ±,ÖUÝ´å¿öæš16¯ëmc¿ðD�ήHγÜ!ÝlŒ'ê2e9¡)³²Zše¹
b’äRhOóÝŠ$Z$Ø€€c(9*ã%á’Í‹j9Çaw¸–ž´j¶uýûq?‚)SÐ>Ë<áþpÍô¼^Š]ðBÏ·bì$ŸÛ-®.êÝÎ2v“mYµN�ŽtUp
èŽðÞÎþ8šÃCY­qV;�ܘÃ�94ÄJ8KÏ@ëvž1’§)êÀM[–++ÕÊp^VøÛ´[ƒC”õ±Ý[ƒP»¢%'6MaÁÑ”ÎÁ¸r6(éRM›`¤êE—g¯hÁÏóD#<{vAÁ¼”LûL­µ&œfóe½+œ†¨M¡ʺ‡kÜñ½S%ÌÿMS:fäR°6ñ
VH1Ë™·A¢�µo7²›Ò¸]
+Ü5XÛoMëéëUhü’7h7vfq�çjþÆoŠÆÛR
+’S¡ú¶ÔÞ×׉ DYšæo׉d|Þ”–)®—UkÅ¢-ïÌ#!Žœiˆ%ΰçðš³oRÀ=“øEöÉmÑ.6C¨ûMͳ8¶¦ÁYÑ…³ßAûò£{�I›Ât� ÀŸmÙx«wÚ³Þa@ÛÅ'ˆì)+cÕ'�¿Øž>¯÷Ö\�ã��,¦iÊÛàt+4¦Îp»að-<·S„TÇ5xƒTD0H‡#ÞÀ •ÂxÌU¼@Šèbœú'£0–ê‘“ÕæǦX›I™„$"ÕêY2u00ãçc2ªàb‰+ûô=ºZÚu5‘­ÒÔ»FO$ë!E8¸­'û<ŒÊû5†ŠS Ɉ–"
+Üx"âÂ×dU“
+¨€©¾PÕt©¦«šHÕ­R»LmÈ“T©ó\#Õ[1ŒÂ–Å=¾Óe8“ü|ÍÁ�iŒ‡G(<ÊÖU¦éÜìöP3”×lþÕ4¸ä¬¾\D_ñJHºÎ`ɬ€SØJÓùžxiVÅqÛÚÍPµ¸º¨+0ë¶Á·nM{oL…�6XÁ²-‹}õ"¡gR”‡Xƒ
+ˆöÆ)•ñÆY,—hÖMc‚Ñ݆ҷl½u®ŽÕšeá?Ýšo°£[o¡æKkª¥Y·n7g>‰
ÞÔ'{J9¡
+vòI´‹1�Ø#ÕÅÄ.sP.tIÏ‘©‹1�Ø#U4MïIñr¹­ÍÍý]ˆøÉb,�ð{-Cv›Ê�<‡&r˜B’·ˇjY·“x±)�€íEÀ‰ÄßÏ\ï_—ñÊ��>î	IÎC¾�„¼­‰Ê¹ì'îƒi¥ižŽ½»(îj[¬Ç>‚^¦ùOÆ‘+Ðzˆµ×4�‚dyD¿X¡}[ÉØ/xšð¹ÿ¯Éu:;è4ÚûÓ²«ä™=j’ç³k—j:»Fªá™M/Ãr
ýlÆÏsŽTX3H¬LÃNò>=/Ò:çE¶ËNx&°Ÿ¶ƒÐO‹4ë÷Ðö!nªºJ:OmêÔ>�ué±Qvon·õ}àµñ‹�…˜&UN˜à|Ðã;‘2["BVwÝ,Ìü™Œ¼@�s쩳ìÑfá™3[X+nk—JaxËÅ¡¬�þ=kM~è?Pù’Õ¯"®Šíðí¸TàŠwXpNA{�?&,„9º�ðŒ\÷žÍßöÕŠ„^‰@ëÎa`ô¶Ä‘“ž‰`é·cãG>Û‹ 2˽OÌÑÅA³@ÌæƯœ�‡c
+Ø¿±C_ñXgîUú“U„È8äAö¬*¢‹1]EDª‹U„P”¤\=ëÈ¢‹1]EDªž‹úÜ�á�Ù„ñ©†Z
+"U·FNÚ:Y•á¹ßújÂhpôÿ"ŸÄ³C×ù<ž Œ¦*ï%‡¾gë<%ŒœQ¯±$Ϊ–¸p¿q•qN!Zà
+ž=­�¶ámºKj
ðí1&Ú/L|)ŽoÌ:œ9{fغÂÈÕÀ¹+q—îsÄpÑ\£ˆ*VÆ–1å4ë¾ÀH‡.˜;ï…éæa�)ŠüŸäÏþØÔÒ8gë‚7ú‡å%l$·èu$xpŽ¢«Në0b:�Ä 3ãO@£A…™œ“äv�Nâ‘ài8ý„‘Øþb<²#T¨¹�\yfvÉ»Âïc×cg=aÙª‡+·Tãï­b](°¶®dù•£Q7˜–†
þ¢šað¸åöig[\G¨ý�
+<Cug*0‹›9xË?Ý›Ei‘Í��ßUù}�¨.Õ`ç¤ïO-ƒ13~Â>:º�V_Ó…ýuͤ ÜÐ?:Ÿ‘‘ÄnÒªXø7ñ«˜9ªÖ^
+!-h¢�è¾Þ®ÜšMqWÖN"{�ÎõüÞ#-½UíiÏÁ–(†/‡ßÛíZG®Ì4Éd,Ï•@P2©,ôYþàüccƯá4Ð~Ù
­)–d,a"·­­²IŒ(Édç~“ûûÍË]Y�*E¨
+=Ï‚PVx–%�ÿªt*úÿ
+endobj
+957 0 obj <<
+/Type /Page
+/Contents 958 0 R
+/Resources 956 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 944 0 R
+>> endobj
+959 0 obj <<
+/D [957 0 R /XYZ 85.0394 794.5015 null]
+>> endobj
+118 0 obj <<
+/D [957 0 R /XYZ 85.0394 769.5949 null]
+>> endobj
+911 0 obj <<
+/D [957 0 R /XYZ 85.0394 749.3395 null]
+>> endobj
+122 0 obj <<
+/D [957 0 R /XYZ 85.0394 221.8894 null]
+>> endobj
+963 0 obj <<
+/D [957 0 R /XYZ 85.0394 197.4323 null]
+>> endobj
+956 0 obj <<
+/Font << /F37 747 0 R /F21 658 0 R /F23 682 0 R /F39 863 0 R /F53 962 0 R >>
+/ProcSet [ /PDF /Text ]
+>> endobj
+966 0 obj <<
+/Length 3396      
+/Filter /FlateDecode
+>>
+stream
+xÚå[Ý“Û¶¿¿BoáÍX>‚lŸœÄN�™Ú‰ïÒ´ãø�'RwŒ%R©;Ë“?¾»ø"!’’'éL;é܃Àår±X,~Ø]àØ‚Â[È„$Ï*‹‰¤L.VÛ+º¸‡wß^1˳tLË!×W·W_¾j‘‘,áÉâv=�•š¦lq[¼‹ä$Ðèõ󿿸^rI£›o¯¥Œþ
?úùÍ÷/Þ>¿VqtûêÍë›ë¥¢Y}ý·çßß:ŽË2¾~óúå«oìå\¿¿ýîêÅ­Åp¤Œ
+¯WïÞÓE
þ¥rñ”°,ã‹íU,‘±Ž²¹º¹úÁ¼ÕŸNY.–”HËÅRÄ$…þ§¸XB2‘HhO‰P 7K94dFÁEoül`ü”™erá¹Ðøu¾-‹åê¡\}øÔÔåõ2¡4z·,~ùõñ›÷îi…–úò¥iLÁ¼¡F(eµÉÛÖ0]òŒ¤©Ê,——×LÈF/�ÀæÐíÝ„Ä�ÍKì.J,ª}¹êšýqB¨ŒIÂ%;ú4!f	甩Œ1’IɯôUþ™JZÝ×;4¬,°ÆŒ¤±pR™ƉJTlžò}=!…’¡«¦”u^m@+67Õéé ë?á ÇþüÓ¤£ð”(šÆ¡£ü§‡û™ŠN¬_«”áÐkÿ’˜wb$É”JœåªM‰€2!)V$åT

+ —ÅX²PT¥Ôôcy–&�rœMm1–i
+º¡»gqF“êlÿži¬@`XXï4S,Ðà¦ÚV›|‘�Qgñ/Ð;–„RæL}ËÏìÃ~Ò|Á[ôÐR¯ôo囧üØZqØîZCîJC3h�¤USweÝyÝÌçæ±Ý•«êgJyY 
+‹%§1á	eΫ™õjÊ7¥ÙfÑûã®Zå›ÍÑ�ªÚüæ槨Ö×,�ÖåL×@^7ûmÞ¡C“9÷HAÒKî1`šwÇ„ÚïëbuÚ£R„%2;Û£ã÷Ì',V"èñVÏBÊ#c�mÓÙg½z Å¢"rm¨8Cš³ÙÚx‡ŒŽÆ~Q»q�(Ä)A}<ü2#sgz¸ßç[C€ùkžZ£Mçn�mW:†b[ÕUÛísØùI»Ï”Æ(@;«Qmµ!,6»¤T8`Aã¨Y›ßÜü«*¢¶Ü?‚Û@
+uÖ˜HËÌïW_´Füê!¯ërc„o›¢çàõ¯ÖÆg1æK™„ wl¸ö×it˜RI(ˆüRyÁß84…Sû©êšƒEļ¶
+½Ñ
+ÓxÞB®3&r\¡�À	ålöÖgT�È M~7!E»òD]%�®¿Y1nE<VåÓ”.á‚%eö/
+þ}Þ–žklÌpŸÃè"KYhÍáÔ{÷¿¯˺ŸäÙ9Ž3J
+sÏ\Çð6ü½¾
+bXvÞ¨žklÕÐ/ j†¤�‡f½9´»·w!âè°+ò®lÍÖ„)KáOq¬ómµ2–2ᘰiRÝô¯L«²‚tAkiK‚Äâ´aª]˜§f½M×`¤Iýyjd¶–æÓVxh�òe�•	CĨã¼4R$xm}È­¤²¨:K6uÝ•æÕ6/ÊáS�K}ÙZ5–˰Ćc¡ajjl‡†½;â/C£AÎmíφ	µM Õí³I¾±µÊ­6?¶!A¾7LWó�h‹4ú¥9ìë|c\¨†œ�ugÛ#
+€¿±\¶4DÃy°ë{ɹ‹ù¸«CñAŸøàÃChk{
ç�}v¶G=1Øóó�ýÌ{>k˜oó®+·;=7ÜçÙœžÈ\ƒ}¬ZOÕfr­z8sÑ¿…µOe=‹_°0ˆL“ô<~
¹æñËsµò§yô
+å²ÿ+àåbÔ³í#Ù‘I§#ÙÀ¦/êüN;a’öØÅ“Ìx$sóØÏ»!÷^/-–‰$ÑX†ïë¦e(•ŒXæ L¤$NéÉ©d5À2å±L9,S¡.ðì±M
±
kô86�làíÙR�ø�-+W°0ÄÆ0a6Ô2;<SÃm>(ªöó)hÓP
+endobj
+965 0 obj <<
+/Type /Page
+/Contents 966 0 R
+/Resources 964 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 944 0 R
+>> endobj
+967 0 obj <<
+/D [965 0 R /XYZ 56.6929 794.5015 null]
+>> endobj
+964 0 obj <<
+/Font << /F37 747 0 R /F39 863 0 R /F53 962 0 R /F14 685 0 R /F21 658 0 R /F23 682 0 R /F48 885 0 R /F55 970 0 R >>
+/ProcSet [ /PDF /Text ]
+>> endobj
+973 0 obj <<
+/Length 3750      
+/Filter /FlateDecode
+>>
+stream
+xÚ­ksã¶ñ»…¿Už9ñð$ÁöÓå’K.3½¤wîc&Éth’¶Ø£HG¤Îqû绋@R‚$OÓñx‚‹ÝÅbß ¿fðǯ�N˜ÌÕu–«D3®¯Ëí»~€wß^q³ö@ë9ÔW·W¯ßÉì:OòT¤×·÷3\&aÆðëÛê§ÕÛïÞüxûÍÇ›µÐl%“›µNÙêÛ?C3Ÿà•Ö«¿yˆ·?|x÷þÛ¿~|s“©Õíû>ܬ3–+Xyyí?~3­ûtóËí÷Wß܆]ÌwÊ™Ä-üzõÓ/캂
Å™}ý,áy.®·WJËD+)ýL{õéê/
áì­]“œ–&ÑFdÑ	9—<1©4יΓTÂ;”]SݬejVÍ@¿»nVõ¸ßuuÒHS½ºÝø—EÛöO~ÜÑoýÛXﺢŧ|õh×÷e=8°±§ßª°mÓÕôø´©Ýú®ØÖŽ‡MQ–²ß>¶° B
Ã.ל'¹ÖÂr<ŒýãcÓ=$‡ÒçLÁfUv�ñ,‘"Ï£â
+Pë9˜—2sq1«tB†´7E;‚P[ý´~üåˆ�T&™Ròê˜�åy¥&É„>ààìTQÈÕ¸©q VC½ûRïh²Ù‚4›b¬ÛçÎù
+ŽP2¾úX—u7H¹)º‡ú†¯zÞUí1Òéí64Q=Ãé4%‘Ù?V€—^ôŽÜû¼ûhÏŽ
”‹›åQ¤MÀ׫®i0_ì‰ÃÐjW´œØÈ{ÁñÏŒ‰¶^Á“ä«»½[þÔ´-�îÜ"âºm=Öû~÷D¤+BO[GÔûW¿wš;Qs4H=ðB	Éå™ç©5‘;6êa,v£µ¥²Õû{z·~\Â�uÙ Iä_X3øÃ@+B𦊑
+VŠ”ÈJñeq³æ«˜Œס±âo0Öˆ]-‰‚¯ÃÃÁß™éâ#ÉGÎtqhM“éºùv<k«©æ	癸`«s°Ó¶ p?ã®(ë#º2OŒ”ùºê˜îÒD•Jù-¿ïJ:Ÿ-ÙŠrã„Gz3xÁÞí@<ôØÖ_ê–†wÏôÛwõÑ	–dÙ%Á 3b#˜…Ð^¿Óz*5˜7Ì0Eœò•é$Í!ú�ãËÃòµ«aIj˜™3ö©‡¨,!x«Õ.JÔ+sát·þí±mÊÆ�Ï—¢ÝŸ‘´ÎY¢„0d=;-í
+w»«Ëýn@ß~ª�9O;2G´ã…Ì‚ø×ûíãÁQ¶ÍàäÔ;™ÿº¯w�÷³tÓø'ùucû<xؘˢ*R40’å)°n ž”Ê¿�Dß̤›³ÃmQ€‰tM�¶6žÆ¯ûÆ”(ŠËP,k‚(l�K ÞH!�nÆ
�¨
(ïÏpÒ)öðºq©-l
+\5‚sÒ9¼¥i+,˜G–p¶ Çaã*¶Ê¡ª]&;¾Â‰Ô™ŸE8
+Ï‘œ¡7½ÅíÙîb¥
+IPHEŒ«ãÃÒWt¶VPÕ4ëý…]×öeX °n¤�+úü	0—€ït®b×UeÌŸˆÄ°ÔGØ_ÊñEãf �ŽÌš\Pïk�âu=–¯‘XÈî#�„d9åüiº)èt)6[B•Wźl
+`z&
P;š¾óAwQ³Âw0
+[ìCL7YêX[ÇäÅU¢“¤DúxdœQíì�øLÏ&¼
Ò„ñÒ'ÃÄ}¿ïªW‘³DáCEÃò¥!�:T™¨Lx&]‚q�ßÐÓ¨íûÏ4jºˆ$2•è”§GGú¹~Ž�({ð“úg¦*&"«©ÑS“€$•KåµfxP]ªfÁŸ
+pƒÚkÌS1òªFYvÖÙXZ¶#rS0øêý‡¯]»‡ñŠÞìPÁšu]bæ8ÐÁv8¶, c¸�j
i§V&;;!'HŠ@¨Y�“S稑øCÝÕ;òŸ8mËjøÝݘվë\ä;P
.t¢4Ëfô×(Ë›�ÂêuáNXpå3Ú<Št(wÍ�kd®e&“\è|)5Ò˜Eü¤‚éÀÙºŽ^î®iðq‰=üz¾ ‰�ðR!XNVB¢b¥½L_ð-î-Ô%.Ž°ÙüŒD”‚ð¹â>DÛWÖwËÔ:è-†
™RbŠs£yÀ
Ê+P[A€Ü6m±sË{¤x„3ý}Ì•i°`Åù¬rªN9d�£y™à�×°×¾ô-P§€>£Þw‘i‹û�Sp�’§ùa÷ÔKØiv"VAÊ•3¾ðªC„U‰$¡ã
+9dì,Ë^ŠÄ¥:^D×܃a¦±Í<Qyˆ®‰áÅÊÁ$3Œ, ä Pz
+�üôŸÕԲƗO”¤À¨†¾Ä¾:��€M‘Ëeô @eÒeJc2Ü@ol>„¿šÍ‚0ë*Ž6M¹!
+´6ÐÝôûÖI
+”µƒŒ¬ªfÚ©*Xª4\õ�v:æf}�YïÔ'r³ª)h³çàv…¯£z¨íéB7Oƒg_žKÈ�U$§;ßÓKš
Å­ŠD#ƒôXЩ9(P:G
¿1le P_#Ü€¦
+m^p´9÷úçnG‘øÔ¿¡N”‘¡�s¤CYÂD0	jtEÅœçAym•¯Þ�n³Ã3x½ß|¡�‚Tuæ¿è­*b‹Xíîàõ©¦‡áI†Î	öPå¤%Ó‘Xj‘™Rfü¬DH—Õ }r‰	!_v.
+ú'8à‰Jƒyù�Þ÷ø½ŠÍµ5¹$I¾ÏQ�{å«Z�䆧Kçs1aVÛ½
uÂ5E`¦ Ÿ/EkïèaXõÛÂ@n×ðòßUä+ÛЮ®Ý"Ê­_9î‹ÖöçfT6
”±VDåOîOÔË7{[HéùÆ),n›Ïu,�ûY´Â­Ë]?¼^S :0A‘
+ŠR
Õu
+zô¦è�\Ë)î•rt½Æò±W”³¢O~êiæ\¶
+¨RâyÑ>ô;ðÛQ•Aõ
+Í““Ô¡ÄäŽÅE‘&à8ÅäZPß4¾³æ?ƒÁÎ4ùß…JE:séê±Ø
6]S©OÒ`T”eý8ºq÷Lƒ ¶JSF¡|‰¤ÒÔQ¹*
+ßxá ¨ìè:
+endobj
+972 0 obj <<
+/Type /Page
+/Contents 973 0 R
+/Resources 971 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 944 0 R
+/Annots [ 975 0 R ]
+>> endobj
+975 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [120.1376 365.8002 176.3563 375.0156]
+/Subtype /Link
+/A << /S /GoTo /D (controls_statement_definition_and_usage) >>
+>> endobj
+974 0 obj <<
+/D [972 0 R /XYZ 85.0394 794.5015 null]
+>> endobj
+971 0 obj <<
+/Font << /F37 747 0 R /F23 682 0 R /F48 885 0 R /F55 970 0 R /F21 658 0 R /F39 863 0 R >>
+/ProcSet [ /PDF /Text ]
+>> endobj
+979 0 obj <<
+/Length 1632      
+/Filter /FlateDecode
+>>
+stream
+xÚÝXmoÛ6þî_!û`Ãñmý”iêM»ÄÉÖvÅ HŠ-T–2Knýï;Š”,ÛLtÁ6þ`R<ÞŸ{îŽ	0üHÀšê@êqLx�,G8˜ÃÚɈ8™°
+‡RÏf£ƒçLiAE0»èR+E‚Yú~ÌCЀǧ‡¯Ž'!åx|~|6á||	íüõ›ã³Ã‰ŒÆ³éëÓóI(±ŽÆG/ßÌ:‰¯ë8z}ú|zr±Ñ3ù0{9:žõ§ž”`fŽðûèý¤pà—#Œ˜V<¸…	FDk,GgˆGŒuOŠÑùè§^á`µÝêEŽ`D™ >èô
+·£†1Ò¸„[�Y“ïPR•×CB
¬¸3x[­‹ÎHQT·vØ,2;Hªå2.Ó<æC¢€SJpI¤•­Þï¬h¤†©‰´”Â6.ZèWYQÅ©ÇÓÐmpŠ-bM.I.•e–4vÒ=ì£h§7ÕÊ	hÎì
+8PvH¹§H›âà-öa¯1ªÜ¯äTiĈËÆGsÀ}غ¬µç@®žQŽ'r;÷ÎzjÙÚj#ÃW€
+‹¨„¦ͳÒcZ0D¥ê„o,qç«xi-Üæ…	�†—Ÿ²2‡�wv-±é
�²±/DàbèÌ}Eú²ä½Û¶[C&ú­…»j
yÏ°vÌ2F‹º²x1&PD‰ÜÎè4¯oŠØxL¨+
+q†£>ÛÛËÚm'Pû#%†i‰"ÍÈCº	kß3øN?ù¶]�ƒk˽Ø}t¹a‡óNCëÎ2Å
Õ·³-5ERIÅNC1Š,cϧ'/.Þì‚D$!ÁY0Pø÷\ì5îû¸C�ˆIŒ-'�ûë�Ûô†ô¸/A®�¥¾LÔ‚H~C-èêÍæêºãJC:Äu¶G¶®7„èǃ‘i†$–
+endobj
+978 0 obj <<
+/Type /Page
+/Contents 979 0 R
+/Resources 977 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 944 0 R
+>> endobj
+980 0 obj <<
+/D [978 0 R /XYZ 56.6929 794.5015 null]
+>> endobj
+126 0 obj <<
+/D [978 0 R /XYZ 56.6929 466.6686 null]
+>> endobj
+981 0 obj <<
+/D [978 0 R /XYZ 56.6929 439.3642 null]
+>> endobj
+982 0 obj <<
+/D [978 0 R /XYZ 56.6929 409.8468 null]
+>> endobj
+983 0 obj <<
+/D [978 0 R /XYZ 56.6929 397.8916 null]
+>> endobj
+977 0 obj <<
+/Font << /F37 747 0 R /F39 863 0 R /F23 682 0 R /F48 885 0 R /F21 658 0 R >>
+/ProcSet [ /PDF /Text ]
+>> endobj
+987 0 obj <<
+/Length 2297      
+/Filter /FlateDecode
+>>
+stream
+xڥ˒۸ñ>_¡[¨*K<ÉiãÇ–÷0®x&‡Ôz’šáš"µ"egüõéF7(JâØ©ÚR•Ø
+ë2‡‰�+>ÎBØ„¿™o vfÈWt‘—»º<1c…âÕ%KS”œŸð�Xú}Fb(59J“R`cÓ1'
+cß·C¿yQQ`MÖéh&×Ê�ˆ

+GID濯œ	3ßp-“kºgÊÁ«²rò+–
+Ìg]©†q~ÄÄ%d!ÄØ"¹_4Èt6ÏÍÿB�že´=…б/û–nâ¨pØ×eó)MdÈÙ´Í@*28²É¨•d>¾{M€tΊK±LV¦¥�tã?o~û=]U ž_oR¡]‘­¾Â @@­v7F*á\fâL{swó¯‰ D°BË%Â2-Ú—-ãŽsR›ÈÜF›ªŽ,›+dŠâÛ•ÃðR€Ë‚y9×
+ln¯·Ö&MN¾q&
ÈK&s’·«‡Ás1d’p^H”0¨q@܆ԙ„JKÏÄ‚XÍH߶÷U¸øo&er‡®µ}nºÇ~UjPY,Ða!‚6}×"Áç,ÜÂia
+�1�PÞ�몧LŸ—&¥?†
+-/HØÁÎy&å»À®”N¤Vº)ì|O¼…p©ŽEÞ$P¤>ÙG~²­�Y¡Ê †¿3y^¦kWÔÀàÜ•ÿZtÀ8”9ëVÞû—c×yÀ‘ópÖmD4( ×p×b„âžãÍ3è«))êþ{_a
øãdÚd]Üàöáë鳫ǧ>ØBšlƒ’p­ªÀf±è„J’*Å}ëK´ã°ñªº­Çi–K*-+>&¤�ÙqQý
+oQÈ"ú5QÚìû¶)—ª:kE¦òXÕ•-Åä…£¹ ¼>Å‚3eSojÍkâ
+}FÇ>ŒÈ	E?n�gÊ�›Ìº­Eñß`{Ó¤p0ú¡†.�[$.d2ÐèSš¥ßbà2Éq˜öƒÍݽ}
ë’–¶=÷ò¸H¶
+–ýG[¨R¹b»ðŽàK¦`ý4ðÓmpp{ì÷J0	F¦åǺ«~F“‘þÅÉe‘<ßéuô…$ÒtŒ{„"ù\?¯%dCv¿)#Oý¡ùæcq™Å£=ø!zVl”C·ëc©Ž>Ø<vø¤Cní©þï̵a¯Ÿî0Û1q:½	�ªÂ+ca´)b|ž^…¦ˆòG<t1"a8h_
+Õø†¢fðçð,‘ÍÞdT†ÏUMÓ!EÃ×Ó'öûÙ¤
˜¬N9âD¦Iï°a¹ï¯h‘‚”�OöôÖȳ»X¾jPåp]RKœfb<‡ÆµYÒåÜâ¤NJb…­
&x�¸‘ú¤€¿>ÕÝÅ2~F�
+f2€ïFt-˜¢~¶åônwâ-ú¬;]àc×BλÈs¤Hz	ƒúÅå©9Eª;4UUw—iwÉIÎ’iÌ�œæšÎž¿“²‡§þØVÓcïb¢uÕŒ1tì|w|ON~™
ˆI›ÏŠ“<>Ú<¶=
+ö
+endobj
+986 0 obj <<
+/Type /Page
+/Contents 987 0 R
+/Resources 985 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 1001 0 R
+/Annots [ 991 0 R 992 0 R ]
+>> endobj
+984 0 obj <<
+/Type /XObject
+/Subtype /Form
+/FormType 1
+/PTEX.FileName (/usr/local/share/db2latex/xsl/figures/note.pdf)
+/PTEX.PageNumber 1
+/PTEX.InfoDict 1002 0 R 
+/Matrix [1.00000000 0.00000000 0.00000000 1.00000000 0.00000000 0.00000000]
+/BBox [0.00000000 0.00000000 27.00000000 27.00000000]
+/Resources <<
+/ProcSet [ /PDF ]
+/ExtGState <<
+/R4 1003 0 R
+>>>>
+/Length 1004 0 R
+/Filter /FlateDecode
+>>
+stream
+xœeU9²,GôûeË@@Q‡�!é¡%bd(dèúʤ—÷ÿ(žÑ¯
+’$¡T¬)ÿ®ïë¯ãïãÇ_¢ýþÏaíÏc‹®½Ú¿G—=ûÌöÓ1ÄF¬lÖ]töö×ãqu‰Ý¦‹÷5š�”�<8Ç—ý:\;âúãñ‰ü<q¸Í;.\ži2c¶û~ð¶e¸í×qc¸=7Ä+Àg
¯ã�ã×ctéa³ÙL1ca·cu™šmQOƒ½¥ì-¡
{wñ¨¼&kñÄÞ
+¨9xcH
+¤Ï’ÃigÙ¥—ÇáC6uéíÛ&”\ÊGTœ„Méêö–KòlÜ’Fyu|?é%åiÈ¥K”êNÊq{vˆ�*êèJE¢]8hÍò¤p0R±ˆ$Á(+ÁnÖN¬
+q�ª„Ñ«ò�^ÿï>‹«>÷—
.13×…Óƒ!¶3¢SËAÕ”ih¥Å¨Š^…(€<Îm䦽ªšÛÆlLÊâ³ò7Ù
+г2"ïE9~ 
+n*Œ1½÷¨¾x¥Æˆpîâ‹
&Xî
Ãœ§³±è\íD¤ß�ä0}#XŒûž˜‹¸À>#^V°¡|2Îi‰9ÊÎ�r)`˜¢Xh¡Ò& „hb—H°Œe"Ãê
+þrÓGçX5¾ûû8‡´ÕªOª«t–Ô³$Ây°‰—BÒ›ÀÄ5
©/¨�vp�÷o`kA“ôr±ñœÓ4N.4Žæ
+endobj
+1002 0 obj
+<<
+/Producer (AFPL Ghostscript 6.50)
+>>
+endobj
+1003 0 obj
+<<
+/Type /ExtGState
+/Name /R4
+/TR /Identity
+/OPM 1
+/SM 0.02
+/SA true
+>>
+endobj
+1004 0 obj
+1049
+endobj
+991 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [470.3398 482.8902 539.579 494.9499]
+/Subtype /Link
+/A << /S /GoTo /D (boolean_options) >>
+>> endobj
+992 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [316.7164 470.9351 385.3363 482.9947]
+/Subtype /Link
+/A << /S /GoTo /D (zone_transfers) >>
+>> endobj
+988 0 obj <<
+/D [986 0 R /XYZ 85.0394 794.5015 null]
+>> endobj
+130 0 obj <<
+/D [986 0 R /XYZ 85.0394 769.5949 null]
+>> endobj
+989 0 obj <<
+/D [986 0 R /XYZ 85.0394 582.0558 null]
+>> endobj
+134 0 obj <<
+/D [986 0 R /XYZ 85.0394 582.0558 null]
+>> endobj
+990 0 obj <<
+/D [986 0 R /XYZ 85.0394 543.4475 null]
+>> endobj
+138 0 obj <<
+/D [986 0 R /XYZ 85.0394 324.8439 null]
+>> endobj
+999 0 obj <<
+/D [986 0 R /XYZ 85.0394 292.4184 null]
+>> endobj
+142 0 obj <<
+/D [986 0 R /XYZ 85.0394 174.5048 null]
+>> endobj
+1000 0 obj <<
+/D [986 0 R /XYZ 85.0394 146.6189 null]
+>> endobj
+985 0 obj <<
+/Font << /F21 658 0 R /F23 682 0 R /F62 995 0 R /F63 998 0 R /F39 863 0 R >>
+/XObject << /Im2 984 0 R >>
+/ProcSet [ /PDF /Text ]
+>> endobj
+1009 0 obj <<
+/Length 3382      
+/Filter /FlateDecode
+>>
+stream
+xÚ¥ZÝsã6Ï_‘·*3k�$’¢toénöšN›î%¾�Ùn‰ŽÕ•%W’ãõþõ >líõfnüÀ/Aà�rxÀ/¼V±§Qz­Sé« T×ùî*¸~�±¿]…L³rD«)Õ÷ë«¿¼ú:õÓ8Š¯×›	¯Ä’$¼^¿zÒþ
p¼û‡·�w?ß=¬o´ônºYE*ð>þòpGµõãíÃÓû»Ç'j~
+Tpÿï÷�P†7+¡eä½ýáöÃúî‘Æ%s½}÷Ï›0½Û‡·wïhèÝóxw‹k­ÿñx÷tóÛúÇ«»õ°©éÆÃ@àŽþ¸úõ·àº€ýÿxø"MÔõ�¦it½»’JøJ
+ázª«§«¿'£vê¢"ÃÀ�D-h2KšT©BMVY{&Þ‹�ÍE©÷µ©¹VvTöEÖ›‚Klþ8˜º¯NVE 1DÞ}Ýõ&+Þ
+VmeOÒ2e
+*ºrW¢—ØÆ1sV¿°¡5©AD|Ru7ê,Nu¶+󑶣þ<«ë¦§îºiw Ó‰Fž™±
“'1#òè-º“g‡ŽIáLxòdÛÈ·§Þ—CÚé
±hG6’7 W«�4æcNµ·kì1§Î^sÐ>µÇ­
Y>0Œ|Š"MÝý¶±BBç(4šÚn(.­9Y�îH™²Îg³�ÖyRv
è0uwà…f[¤X21sgÆ£
žu:¾Á.&§8�QvΕæØS�cN(ÜH{“x‡EÀ'€)éë8LAb´­^­ë›=ÓO
^F¾AÂäd¢¨
+Æ„‚[£ÌÈg?Töƈ—²šYo‡4ŽðLŽ½[©àN»7-
+›˜Ýt3Ä!Á†yZ¤Á¡½5�ËP)dâë@º�^~¡›ÓjÓ6»U
| 
B™:7ÝB0HÑ�”K6ËŽÝJƾŒ‚³ 3ÃÍ�8Éd–·B–)ætZ\
½
+U,
+JÎt…Gð‹
�œwúÞý@E‹Ó+/ëUJ?ÑQ2vØs>¿£Ÿ]kl ƒÝÐk–dY³®©;¯¦
r —¬.¿:W�Þcs¨
+"<fu?ß
tЋ"ÀgÏLY|TSè'€N3‡ì·îVþ__x~±¯…—7»�HOå§1Š50Ð9+Ã^+�¶I6é9‰NºvÔÉRhÁ)²æø mPc‚P°Ÿ`{Έ°NãÌWœAŒïhx„óÁò&¼„†{OU‚tÔhÀ,kª’}k|ôÅ)|vk5=q-yf×츧0Ï”EhpÍ(%$KýÖ¦'¸—öµ
+©I3S®8!À@bÉîGG‹»d¬ÎÒ)è¨Lö¹£ªÅb"¢rg_H±ÃDÖ_ËŒ2^aW
pUÄ„Ô¥ˆHñ%Ûí+Ã_ ƒ\™Û×4¬uÙëëé[ç±+Ë?g> •âƒ!N¤g*ËN¹¨ÌwH#'¢¯í³öш­6¬ßH`ðT…ö~hŽè­.?N´Sr^£‚|•À¬¬(­ºód�¶aãF"&؇­É�Oº×8èvöH­ÁmÃ=”¸¡
+9ÐìsÉ3ÛásLÜC¶;e/hÕÒç›™E=žÍ?¹êÜKüä8UàŽs’"ºÃ²	žP~(¥Ëý�sÃ;B^~:_ؤÍZ¾‘3JŸF�åO¦ÿÎ^
À3›ûkº}h´ù=˜'	hÃÅ™î’g¹U(@^�ºÇL­@|Ú󄈥¯¤žiU°ðâ+|j—Õs ñs
+õç씯•P#¿�DÞfno.5ÃÆä“"u%½©§Î—h¦µ»Ô¢=~Â"*•ñù�g8J=x&5Že¿¥ÚÜa°Ç)
ì‡ù㚦0|ÿ�_µrˆUp[¡rR4^žv˜ÂgmùÕ-ÆWx[¶ï~þHwö%h䂌٨9	³åBÊåg#Þø›óÏž.ÿ^s¾áû\�¥Ì¬ë•Gë2ù¦u…~¬¥3̧íÝ"¥¼YDÉìž’NRBþZ�å³!R’z:2‡& O
+endobj
+1008 0 obj <<
+/Type /Page
+/Contents 1009 0 R
+/Resources 1007 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 1001 0 R
+/Annots [ 1012 0 R 1013 0 R ]
+>> endobj
+1012 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [464.1993 519.4233 511.2325 531.4829]
+/Subtype /Link
+/A << /S /GoTo /D (proposed_standards) >>
+>> endobj
+1013 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [55.6967 508.4843 105.4 519.5278]
+/Subtype /Link
+/A << /S /GoTo /D (proposed_standards) >>
+>> endobj
+1010 0 obj <<
+/D [1008 0 R /XYZ 56.6929 794.5015 null]
+>> endobj
+146 0 obj <<
+/D [1008 0 R /XYZ 56.6929 584.989 null]
+>> endobj
+1011 0 obj <<
+/D [1008 0 R /XYZ 56.6929 551.635 null]
+>> endobj
+150 0 obj <<
+/D [1008 0 R /XYZ 56.6929 396.4263 null]
+>> endobj
+1014 0 obj <<
+/D [1008 0 R /XYZ 56.6929 360.8629 null]
+>> endobj
+154 0 obj <<
+/D [1008 0 R /XYZ 56.6929 173.1662 null]
+>> endobj
+1015 0 obj <<
+/D [1008 0 R /XYZ 56.6929 145.9427 null]
+>> endobj
+1007 0 obj <<
+/Font << /F37 747 0 R /F23 682 0 R /F21 658 0 R /F55 970 0 R /F39 863 0 R /F48 885 0 R /F47 879 0 R >>
+/ProcSet [ /PDF /Text ]
+>> endobj
+1019 0 obj <<
+/Length 2880      
+/Filter /FlateDecode
+>>
+stream
+xÚå]sÛÆñ]¿‚o¡2æù¾qˆŸÜDi”‰ÇVÛLãÌ"!‘5E($Yéô¿w÷ö8€ )5Ó§NÆÁÝa±·ß_”˜pøOLœa\åz’åš.Ìd~sÂ'×ðîÏ'"ÀÌ"Ð,…úÓÅÉËoU6ÉYn¥�\\%¸ãΉÉÅâ—é×ß½~wqöþt&
Ÿjv:3–O_ó×S!ÄôõۯϾ¡Wß¼ý@‹oÏ^Ÿfzzñ—÷gp"œ6¾‹_~x÷ÃùE÷ůߟœ]´”¦Ü®�ÌßN~ù•OÀÔ÷'œ©Ü™Él8y.'7'Ú(f´Rñd}òáä§aòÖ:&£3Nf#â‘jL<&gVÁ+Ïùæt¦ŸVÛSᦋr[žO›ŠŽ‹ù¼º¹]¯êe8_®ê°”–%�!D±y¤Vë5×eCGw·áÛ‡€ÞÔtT]Ñɦ¸)ãWÛûr[ƒ´µË§?nÊ
²€V—áU8@z@ “™,7FzW›zµ
+BÌò�aΘȄìQZ~.ÀIKž8‚RpÁ¬È[”3�‘ýîâ–Ž�­¥b�OBîØQ]ZZ²
Á¢U:ž¢%omgAX$S™qQj"ZR
 "ç‰-á®E‹²%\-‹û
+¸ K{ñƒ©CºäÜé 0u›)ñE›)qãx6I{)n"•e	 #Ù1UÉýä>/ß]®WsŸ”ý‰ŽdhŸ\�Øc¼…kCµ7ÞS’Ù¼õä½6k3.žÉÁs€…ðÉïÕ¦ôe‡Zª>$[‚|îÖâ€T\Fv@×
¦¾£FL‹ºcÖ¿BáÓÉwÊÎðe¾¬º�.3°s3Rë(¸ÁRn,@ª”<zâÃÃÃ	äx—Í�ÉU˜Ü˜«æöNz°*Âcýè=D‡ˆ7[Ó
+Š–e±¹ö®"<So~§â#ÛϹ0†eÐ7DVØÍçgµ„èkŒî'ØÃ<X¨
+´ÇäåU¼ð/<"lìn�ÙdQ÷
+®“®|Ÿ"Á¤‹:3z°jÝ�GÛ!ŒCõŸRÐ2Jy�GÉ·Ïu)'”L]ŠØ¨—äHH:U+þô¶œ¯(Øñ雟épGïxè«{J	V0è
+_©ƒ©A˜[ÌÛªÃ3šÍ?¾ü"—3.=½­ MQ‡o(GèËuËámˆå�­L˜¦MY.|^ÂÏÊyqç³
+-Âm¹]ŸŠé£ñùÊ[wÓª0á©Ö±Î$žï› í8L=t?/§þ`%ðHiž@ù
+ªºìIú³ÏÎ$ÿ¥þ08Kpó<ŸÞà3hóešf8™Nf8°iìbÂ/­xN¥|Šýï°|Gÿô?�ájQÖóíê’þ,®º¬îK,ú�˜¾­š2¢*š¸ŠDŧïQúÍFÇoE×Ø%?¿4 ½_ŽÓp·Œµrl->Vw
Ñï­�ø^£Œ¿º,‡ö¬…cN+7‘ P…ÿCz¹½žÐâ}bÚ-ü,ý`׶wñ¢ >`¹RLìPc!âä}bv¼+£`ˆ+ùiXA¸4Æ
Íy/_
ºö¾à÷Œµ`Î9*‹ùšÆ|1
Ö´ýWfàœ–ÁÿùK©_…Ãéá¿_E›¢1 î£�é´�>f«Ûzv]Í–å¶ÜƒŽrFu‹à-Žt’Ùk¢cc¾sLÐ40YVô–W |GX
+Ã?�1>øÿÇ×%&
�·srÜŒ·ÌÉ<‹D!/rÇqÚ?ØÛ%ý?mwendstream
+endobj
+1018 0 obj <<
+/Type /Page
+/Contents 1019 0 R
+/Resources 1017 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 1001 0 R
+/Annots [ 1021 0 R ]
+>> endobj
+1021 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [417.8476 228.9788 466.5943 241.0384]
+/Subtype /Link
+/A << /S /GoTo /D (sample_configuration) >>
+>> endobj
+1020 0 obj <<
+/D [1018 0 R /XYZ 85.0394 794.5015 null]
+>> endobj
+1017 0 obj <<
+/Font << /F37 747 0 R /F23 682 0 R /F39 863 0 R /F47 879 0 R /F14 685 0 R >>
+/ProcSet [ /PDF /Text ]
+>> endobj
+1024 0 obj <<
+/Length 837       
+/Filter /FlateDecode
+>>
+stream
+xÚÅWKSÛ0¾ûWx8%+zÙ–Ë)…Жé0”¸½
+g­Vé…³ Œ´QXK`ZyÊÈ
+endobj
+1023 0 obj <<
+/Type /Page
+/Contents 1024 0 R
+/Resources 1022 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 1001 0 R
+>> endobj
+1025 0 obj <<
+/D [1023 0 R /XYZ 56.6929 794.5015 null]
+>> endobj
+1022 0 obj <<
+/Font << /F37 747 0 R /F39 863 0 R /F23 682 0 R >>
+/ProcSet [ /PDF /Text ]
+>> endobj
+1028 0 obj <<
+/Length 2146      
+/Filter /FlateDecode
+>>
+stream
+xÚ¥ÛrÛ¶òÝ_¡É“4	a¼"�>¸‰“¸—4'Ö9/M'‘�ÄT$^ì¨gοŸ],@‰2ݤSkÆ
+ƒÀAv·ÿžìš£S:‰‚”E©H¦”"§”I"0Jùßw(òDÀ$÷Cý³®ô‹}þ¤-:Í™þ¢ÊýN³¬.ŸÐÆL./	Ð;ß©;;5¤ð
+ΙŒ"1óhB6é{‹Wª¶ÓÍÀ�ÃF¤uáè>)/‰Ÿu]^&ñÕnWß{]£ªv­›�]Š
+.©Ô®ýŽÖúËxmÕáM2ûMº“ºú�}Mþö’îøKùI•íHpUÕÝV7W°WÔÕÇmÝvKuXé±äþ˜½¢ÊIMŠM^¾'<ú'\@ðXœ›Š¢Ø&ä‘3‹¨…!n£Ûzw©Ö„㔉0ä÷ƒùuC´õ羸S;]u
+´	²gíW€Ùtn¯8§Ðê¬oŠî`Ù´ÐnÞ¾d4½é¦Ô˜ë6kŠÞðhžmUµqÃŒè6f·®>ø¾Øô�¢‹ˆ��EPöä½ÞíÎ [ÕM\¡HbZÐü—&9A×èÙ8É‹5Â1hq»²ôÖú¨¸gS"U¶ës²ÃiìÍ¡:ÓmkÃdMcFÔTw<3Ò6
+‚!æò&tÏ
+™XDËU7ÚгvW(šL7ÈJ™
+KÖûcâf±$îfˉ&Ägqdd<h< ;‡'ȨÜc>’ᮨl–­÷��L\Ø&¥¨ŽhÊŸzœ†»IEC#Â÷#Ë!$â)IcûIlqر!pRPGÊQŠ
+ð�eÏ¢™˜…¢�“Yéî^ëŠØOŸ–�XøÎèØò	nEȤ/ϽgL	_|qzBHL÷IR9XÞž�ð*bS5«Šæ<\¢}Íû½±üÐ×ÕsêÉô¨>‡îy”>q<ÃÃ5&XHUKטpB7à¬ìÛÎ:§>kÚ
ÉÕöUíê8ÞѲ	ŸÅg@ÀÒ4G¼ìªïêŠpFD¬ÓaëðU‡!b¬ø¨±­¦<	EXÜØ‹álsôgX)¸H=Ð8-°åä1ÍW‡N»ÖSÎßürõÂûåeD+Òiitm¤½S­ê;SÉâdþs
íÞdAµM×âµ;i0"ª*¸cºmê_ÒÇNkÕ…:ŸÔ6*GŽd8[w¹3]©p•'¥úR”}9ÜAxOmŒ™mÁ�ˆ#.,ÃE‡/D!15ñÚ‘¬/©á=¦:×#�x\^@/Ô¹„slÉx¸µ±yŸÙ“Š†£a­“cƒf½3LÇNEÝ9U^µ�q<8
þBo+OѸ-Uæ•yd¡+ûò©Xô7¿Þ.í�“Ø›vçÓ›É�¥I˜UKNÏéÂ&öÑñ°~É
+endobj
+1027 0 obj <<
+/Type /Page
+/Contents 1028 0 R
+/Resources 1026 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 1001 0 R
+>> endobj
+1029 0 obj <<
+/D [1027 0 R /XYZ 85.0394 794.5015 null]
+>> endobj
+158 0 obj <<
+/D [1027 0 R /XYZ 85.0394 479.27 null]
+>> endobj
+1030 0 obj <<
+/D [1027 0 R /XYZ 85.0394 444.0186 null]
+>> endobj
+162 0 obj <<
+/D [1027 0 R /XYZ 85.0394 287.5734 null]
+>> endobj
+1031 0 obj <<
+/D [1027 0 R /XYZ 85.0394 259.9325 null]
+>> endobj
+166 0 obj <<
+/D [1027 0 R /XYZ 85.0394 214.4637 null]
+>> endobj
+1032 0 obj <<
+/D [1027 0 R /XYZ 85.0394 191.8161 null]
+>> endobj
+1026 0 obj <<
+/Font << /F37 747 0 R /F39 863 0 R /F23 682 0 R /F21 658 0 R /F47 879 0 R /F48 885 0 R >>
+/ProcSet [ /PDF /Text ]
+>> endobj
+1035 0 obj <<
+/Length 2336      
+/Filter /FlateDecode
+>>
+stream
+xÚ¥]sÛ6òÝ¿BÓ—HsŠ‚—éƒâ8©{M.W«÷Òö�!‰)E*"G×éï» H›¶“ëxÆ‹Åb¿b¢C&2™DIÀ4z²Þ_ðÉÖÞ\™{¤yëåòâÛ×*š$,	e8Ynz´bÆãXL–Ù/SØÀf@�O—7×ofs)d§—ß/Þ/¯~‚©æ€‚‹Wÿ�	!¦‹w—W¯péÕ»¼¾ZÌ¢`ºüù§«›ÙoË.®–ý;®,s/~ù�O2¸Êœ©$Ö“[˜p&’DNö�VLJyHqqsñŸŽ`oÕm•‰àLªPŽEŠ1¡è„…JªN(‚ÉÙ\pΧoÓ²M¼çSšcÚäUio	´T�Ÿ
+‹UæÉKÄ[¥µ™‡V‡ŠëéÛª¦C7—××D¸9æ嶦ƒ‘5œ|J‹<³7µw‚%Zã݈ªÅŠ‡û嚧uÝî
„Ë�—CaÊm³C`^÷îO÷mÑä‡bp·xJôA/Q<11æ€k�nºṉ&ìþÚÚdÀ‘ 	ÕÕ€¥¸¯šÁ-Ñ9Ší¯Ó+ƒß½3
Ç̶h&c±˜)ŽØ¢¨+ËF$Ü¥Ãhú{YÝ–8DâO��;¾ÇY<m	ÖìGU»Ý‘ö­YÄ’©0‰ál{ä~�&1b«Z² ².ä«#R'ÆÀó"%Ø
ÜÓ=±Pá×_—˜í,&Þ­@Î
‹%†²ÍÒ&eÝ:Ûr^¤B¸?û¢÷ÄËêpB1�´Q‡0¸
:«·cИזã¾/+gtÚzòz——¦~Ìwù®3Ð8DC�5(ãT9;
Àz]ÂœÍÂB"ÃÅÀˆÚÎ$íæ™°n]ªcƒ�½
.ózOvU[dþT„Y;²�ˆ:Öôtíñ¯w؈׾^¾ŸA|Ÿ>GqÔõŽF�)ÌaW•†æ¦Y?®ÙéF‘n®ËMuÜ�hÇ?¡oÂÄ	©¿ú/sz6Ó Hœ^}ÎëÆŸ'£ëõ>Ý‚.1èç9C$¼ì â‰r2`<L4aÙsŸ’H˜Ò‘êQB6å½�i+¢×iÜF‹Î
+êÓ(êܵ>WP	s!ã;•†c$$ÕK
9¼ÊËÆÅv_ûÀ²s[;ðX^áÛ2ÿŸK7
+r¥mÓd-Äô—…½!ª>.Ù14 sÚ˜zRu�nýŽ|[¢”"ç'CÖ-—¶ëx>œÉò
+%Øõæ1$¡#ÂR»^Û¶(Nçc¬òMæBBt&ƒû!¹—õ]*tM;^ÝcT?æÈþö_š�ƒ.CEÙ‚µ?��‡öþsmîçå§S°�2<¶|Ö8JÏL��]\™æÖ˜'Ím…›0h·‹¤¨n°>åwfeÇû¶n�þŠV›ª nwžü,5•g¿¾²‚zÊFä|yvnvfÄÉ…�P�„êÿÍľF8ŽÕ:‚©H$OÕ:‚é(öXTãåwk±ë÷ÝÅÈŠÏUÛý“cˆGJö«,ùd•åE½9´×L�Ö*,Ô:æf¯[
øí�”Â{Oí‘(P^üùw«†·çÖ5JèH�•¦'­hé@R5Šmuß6¸D�-ŒP°ÝêþXÓº|ÉXUú¸˜wsàe•¡eÕ \“ºG
€¦%w.Ü#‚í ª1Èßðž†Ù3/)Ó¥ËùC™òN_Œ
Þõ˜u%,P±zº„W�ô%7È5s—Æ,c5Ðe™¨KY=·ÀrŠSdöckj’”óæÁŽžG8)g5
θ͋G+Zîr›[um@äS0€êƒYS"¡„®XsýhJrq2üªf‡Ø´íÄg`€T‹6ÑÕ9˜Âêa€;§jîo~ÃÛE“.Þ�5.ß¹ÑàrÐa€N÷VÐ3‘uÛݳ„�4PCeÚàs¹eÖ}wC@^Žµx«aðdDÐg]^Zåm[ztÀ.h»±æîö#8X]äöçöìÑ>n!p<A„ÚSñt˜DwŒÓ¥“÷¶$­HÅ´ÖáÐ.‡ž3f#ŽÍp¬¾êÚ£ÅpyÚ ûE�¦"ˆ^´©œÁ· ´öV¹pEŽ/!8«âé’ÇöoV8zD(
+œ>$fN;ëÅ	Á‚ðÍÈ=ù d
+endobj
+1034 0 obj <<
+/Type /Page
+/Contents 1035 0 R
+/Resources 1033 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 1001 0 R
+>> endobj
+1036 0 obj <<
+/D [1034 0 R /XYZ 56.6929 794.5015 null]
+>> endobj
+170 0 obj <<
+/D [1034 0 R /XYZ 56.6929 769.5949 null]
+>> endobj
+1037 0 obj <<
+/D [1034 0 R /XYZ 56.6929 752.2692 null]
+>> endobj
+174 0 obj <<
+/D [1034 0 R /XYZ 56.6929 663.7495 null]
+>> endobj
+1038 0 obj <<
+/D [1034 0 R /XYZ 56.6929 633.2462 null]
+>> endobj
+178 0 obj <<
+/D [1034 0 R /XYZ 56.6929 587.2939 null]
+>> endobj
+1039 0 obj <<
+/D [1034 0 R /XYZ 56.6929 559.4406 null]
+>> endobj
+182 0 obj <<
+/D [1034 0 R /XYZ 56.6929 362.928 null]
+>> endobj
+1040 0 obj <<
+/D [1034 0 R /XYZ 56.6929 335.0747 null]
+>> endobj
+186 0 obj <<
+/D [1034 0 R /XYZ 56.6929 132.2109 null]
+>> endobj
+1041 0 obj <<
+/D [1034 0 R /XYZ 56.6929 104.3577 null]
+>> endobj
+1033 0 obj <<
+/Font << /F37 747 0 R /F21 658 0 R /F23 682 0 R /F47 879 0 R /F39 863 0 R /F14 685 0 R >>
+/ProcSet [ /PDF /Text ]
+>> endobj
+1044 0 obj <<
+/Length 2916      
+/Filter /FlateDecode
+>>
+stream
+xÚ¥YYsÛÈ~ׯà[¨*žÁ`pÄO²%¯½©õndnR[ë}€HHB–h(YI忧¯ÁEÈvUŠUœ»§»§�oz¡à§©
”É¢E’E�UÚ.6û3µ¸ƒ±δÌYùI«á¬×ë³—oM²È‚,ãÅúv@+
TšêÅzûûòÍ»‹_ÖW×ç«Ðªeœ¯l¬–—ÿ8×Z//>¼¹ºä¡Ë¹òöêâ<‰–ë_¯¯°Ge0/
+bY¹þÛÕoç¬<»Zwü
eÐÊ sŸÏ~ÿC-¶ Ê�g*0Yj�ÐP�βp±?‹¬	ldŒïÙ�}<û{Gp0JKçtbMØ4Lf”š9¥Ø,ˆ
¡R.*–µø’ﻂõ-—¹æ»]ý¸:¶y+3¶es®Óe±iËéz¬�»-WoŠ¿¢fàP²Áþj±2a�†)ï<&+µüO\¹¯]«WøÜó꿯˜ðH°	áõ}é|K}ûTåûrÃ
ÞUFÚšKwÜlŠBD¨«Ý×JQF{/‚²äŸ�…kEò\(¹ò®òndyÎ	…àÂOù†‘ˆ£â˜LÊÂA)g¤…Sá-¹
e2’¤Y‹UÙÀÆQ¼
+u6béÄk»Yßbä„2tzFåZ8˜ºŠ”
+²4´xøAñT°� >_iþsÕ4uãæ](Ì‚0V‰¸«N–:ãzS8WVwÜGÑAÇËõÇ÷?pOg÷PßÃÔüŽ|Z
+!0™mÅw-”•,-Š&ßq£hx»Æ�¿‡Yº|Ëù³û5Ç»8¶è!;îWVuµ"·
+aë˜*h^Åå±ú³ª+^…‰

+hÜD)«ûå¬uå„$[	,<!ÙfÆ2Ëöf-$¡"âD-hžøƒþά¹¹©·OsE+$j.__\"*B~î!
B™ó
+¿…iš�¡>Ñ Q¼Z4�^€|N>”<o�Ý*AÑQ�J–Ûš(C9v=ä»3ê9”4‡ý=ÃÑ3ŒÝHO§gêÆhC!"bC×@³*iE³*!ÍΘ9é9²¨g pƒTŤ¤Èú½ 6TqÔ;&Ö'*îW÷*††HY�ʽ
påÖ7n¹dyq:/5yuGj�³¯‡©NÉZy%kÅJÖ=¸âQbLûsÒ�e©l¨b誚¢bí�WsˆÀ”º~ÿÓÕnQdí ÂC
låHzóŒÎˆD
/½nÿA�b´†£ØŠ)bÇÍ8žè
+Ÿ@”ÂYA±ÝBÆ”%yõÄŠá´cÑÓu…Þ¨~{9ø¿¸
7¤¬3ļ7aײj%ñ!T󘸘 Ë?¯1Þ^üº~'0¨q^Ã8}Žª¶Ü€+n‘Ú
+$,‚ªD\†ß¬3	(‰EŠÇæ6¸ëYŸ”±¶&pr*_‘%Š£oŠëÔŸÿ¦ƒrµ]’Gç¿O-ÛbWøª‘"(yEøgÖ¦*)ïýs‡òCY�ê•<¯èÐq¦3º0ÌÛ4Ì­�¿Qe£9“6–&•UÙ–0±Iw‡˜247»’¼ëK¡ìpŸŸN}Õ–òÓ`mï!Söp¥¾‹ÿÌóùX4²úÜwGÙº�°'Ú4°qœ�í*?ˆø‡¦¤×A
+òÃ#÷{Ã÷{,ˆ§,\®†˜—žúûÝÊjÍ9¡z‡e ,œÁL`"zøÃѲ•T¶ágC"À`L&{¼šà�¶Í1ò1{³`dvžw
uQçI”V)#Ô.Œõ°gª7…lÅÏ)ñòⶥ(¦ðI�j>‰½à'”Nb°ð�7
+endobj
+1043 0 obj <<
+/Type /Page
+/Contents 1044 0 R
+/Resources 1042 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 1050 0 R
+/Annots [ 1046 0 R ]
+>> endobj
+1046 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [418.3461 669.297 487.0181 681.3566]
+/Subtype /Link
+/A << /S /GoTo /D (dynamic_update_policies) >>
+>> endobj
+1045 0 obj <<
+/D [1043 0 R /XYZ 85.0394 794.5015 null]
+>> endobj
+190 0 obj <<
+/D [1043 0 R /XYZ 85.0394 648.2128 null]
+>> endobj
+1047 0 obj <<
+/D [1043 0 R /XYZ 85.0394 619.5539 null]
+>> endobj
+194 0 obj <<
+/D [1043 0 R /XYZ 85.0394 444.3683 null]
+>> endobj
+1048 0 obj <<
+/D [1043 0 R /XYZ 85.0394 407.9434 null]
+>> endobj
+198 0 obj <<
+/D [1043 0 R /XYZ 85.0394 220.8457 null]
+>> endobj
+1049 0 obj <<
+/D [1043 0 R /XYZ 85.0394 183.187 null]
+>> endobj
+1042 0 obj <<
+/Font << /F37 747 0 R /F23 682 0 R /F39 863 0 R /F21 658 0 R >>
+/ProcSet [ /PDF /Text ]
+>> endobj
+1054 0 obj <<
+/Length 3094      
+/Filter /FlateDecode
+>>
+stream
+xÚ­Ërã6òî¯Ða«F®Œ<Ìžœ±'™d×Ùµ�=äq DØbE"‘šÏ×o7º
‘�Ij·|P£Ñ
+J$š-RÂUÆÎR‚ŒòóîcïšnÒ½t6¯Ü/B¨ÆU8TpWú½{û
=O…ÖLÊ8…¸”qeS�øIƨXÚÚK
+véÜŠÅ•ëVûzé:’Œ€hå…çÊ#eÜýÐ1
(o'Æ·
+Ž�VÞÕOt€?µ�ë’¸¢HR«ÈÞ5È"(ÛŸY¹=ͼo	ݹž‡!J†ƒˆ4é9¦9<¤¢•À+
gÊã îÔ¹}�ðL<2®w;F}
+Äœæùüëw·×DPŒ…Cñ£[×q׺_æß»}¹ÁA·n7LѯK>lÄ4È¿"Úº	„5/ّͯ\×ñõ#óùx÷q·)놶ÊâVÛvHT¹¾¬™±¥ƒ{^jîojYk°ëf3e«²sÞ®³Â[•w]œ%M•B¬"gY¬'ü	ÂŽ)RÍ$펭13pѺé;‚Kúy<
+¡°ì<Ãw¬¿)`ê¦Âkú0�ègBs¶Õcöùšyô·
+g³y¦ñªm0T=q¯hÎ’ÈÏè¼WÝ”
|ŠÊü
ùj*ŠlŠ&(®a¡ŒéÊeû>ÚH°›8[7'Ä¿§›¸„u
etàÕ—Ã)…Ejcc!¹„þÆ5Pô>úã>߃¯NÔ*Çh,CpŠçlªHd–lSUÓ�k/àâO®™Ø2CI‹P¿r1
Eúvì3T�ø+¶ôûD,Ë
tam’É|l‚p 2Öl8f�ÄAFaøn ihç½N‘®�^ÏÁ
’‹—ÊÄ,Aj_1(*T	**˜€cWô‹å<pÕOx=e•%®�Pñ9¿7@
Ck
`î¤	ÜINHÜ<0˜Ì‚ó{]ðxmUóŸ&öc©´.ß»:(�j"4Éå멲¸Õa)@ýóŽ!jN¬2³I!bKõÓ·7ƨŠD«"„Ã×´å~@K>éÐqÆ°!µ ý¨©ÄŒ' tå•Þž­ŽúÝn]S9>€ëB€X9
+‚Œ—f/Á-�ÉA�jl…ÇÓ¡ñ{�¶3Á�0 )™__ćAïvãw@aÞ¬µOù4vâ‘þ

+a+ÓtlÈ+ð˜~CYˆ|q`õ2¿œ‹ñäL
+üãqÚÑÑ\5áy-ý!Œ(p†÷O'Š›jºg¸Îa¹�lB%¾3“�õv'ã_Œ™)7þ<[eI*äÔå&KÂ¥G÷!tþ="dc‰Ü$ÆdgA2,ÊíPJy1¨Ñs¶Äro�󓢸¢
G¾�Û÷þ™gQ4ËäËþtƒ’Uýˆ«Ý {žÈ±À—%áihçJÞŽ¹°±w
+ScvøÛ»Û7ÿøñzª2„"rU.NÞÓ±£ô•Q÷g;.Å×=˜j¬Zb#÷—Dÿ·¾=âÓô¦yÕÈ_ﻸo9–Q¸=û~·0À¸÷jž§ò²JZ�ˆoC®Ÿ`RÛÄš¢8Ó©€àÛr�ÙíÚ¦ªÁ±¼	ÉÏøòä‰X?,}dzÁ˜³�ƒg—÷L²GÀ›±àO{ÂrÑ#bdõ¯
ç×]`©“ª“s;ýÝJa]“™?¬k@ÂY¡C¸»»÷Í”øT’ËTN¾ïøº?=ö-\ §áqEA<,™ˆûH€ÊnŠ
܈øŒûÒSS)–IøÔð˜
LJwEf€®'ŽÃ�”Ç­^-ªW/
+1ôr5ï7xŸFK97uBf ·õúð–BòR�½FšŽ¯Ã^Gçg‡ºæWœ»;p†n¢¡†=¹ÇY‡ÏÑîÔq—¡û©ª0yààŸÃð›ñË}–.²aŸ…ÃØgá
+endobj
+1053 0 obj <<
+/Type /Page
+/Contents 1054 0 R
+/Resources 1052 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 1050 0 R
+>> endobj
+1055 0 obj <<
+/D [1053 0 R /XYZ 56.6929 794.5015 null]
+>> endobj
+202 0 obj <<
+/D [1053 0 R /XYZ 56.6929 769.5949 null]
+>> endobj
+1056 0 obj <<
+/D [1053 0 R /XYZ 56.6929 747.8139 null]
+>> endobj
+206 0 obj <<
+/D [1053 0 R /XYZ 56.6929 540.916 null]
+>> endobj
+1057 0 obj <<
+/D [1053 0 R /XYZ 56.6929 511.3349 null]
+>> endobj
+210 0 obj <<
+/D [1053 0 R /XYZ 56.6929 239.6059 null]
+>> endobj
+1058 0 obj <<
+/D [1053 0 R /XYZ 56.6929 207.3747 null]
+>> endobj
+1052 0 obj <<
+/Font << /F37 747 0 R /F21 658 0 R /F23 682 0 R /F47 879 0 R /F39 863 0 R /F48 885 0 R >>
+/ProcSet [ /PDF /Text ]
+>> endobj
+1061 0 obj <<
+/Length 2903      
+/Filter /FlateDecode
+>>
+stream
+xÚµYI“«F¾÷¯èx«§Ýˆ¢XÃ1mOûÚl @b‘
+�WýÀ«,0,TøWIá�«῰¯6¢µ_@Æó‘3}<rÕÕ—êw(½*Œ"r⫺{�%3¬,ƒWÕüµÒèÔ&jkööÁ	l…gÞ>‘­Ôš‹7
+lr݈nf„Õ->†�évɆ€™òýæ%[

çGÎB%"ÑøiÆhk�o¬'I¨HdåÊOØQÚøð
+ºˆâ,\ÈüJtâX
 Â?‰œˆl–Ø<¹py+ɈBW™ÄLTKý!A•
+”¢4’°È8³^øÔ<óúTàì_�l”©â×ÈÆ›˜VlDîö3;éÓŸ™ÝÍì÷�…Ñ3sâ¸Lfhœ}Ôl˜"ɾOºj�ç°`	VêÝ>i£“µü3~*Å¬(”`†äPˆ&‚0¡S¨8»»”N⳪žd%&cÊç…º™‰%§SD¢Ç6LÌ|‹æHÎâ�~Nœ0rTn/W–Ƙj†t
+«‘w²‡Ì
+¬¯ñPߣe¸8‘¿‚\DÈg¥¤•žLæçÚ’®YÛQpâCß+¶EÏ"B"A�È�‹
+|ŽÍoÌ7*™$:€O�oõÑš¿FË!»Þ{ce²Ñb•®ýp›Hq«µëCÛmÛºz�÷nQûpë-ÃÍYìJ“{ïL·F×m‰%-à
ê–bßx­
îíZÇ[õÍ_w�3G¯÷ƒ‹Ñà4Åß8S;š`‡ÕNÍÜ�,yà½à¾†eλ§Ü*åÞr\kª“ûü¢Xº¿—@žtÚûú@_$ëË¡ê¦vܯmg÷.îZ^ä¦~/KÜá”7‚Zc&©ù�¯×uI›U·V³“w©®–sW\ùao°m+sãdHžÄö›'ﲚÁa™ŽUOÓ³íÁ²AwÒ›»¦ß‡›´áy¿š÷·{«ÊóþÙèØÁUöÖn˜œDÑî‡ætÿ^*Ñ­q ¶Ó–tV”å] tNÞ­éÜÖÓ)Ç~Ÿ*Òü}Ð×ÔãÔ8qÒLª©°ºœÙô67ºeV�NWãÎïקM“ÛMMû¶5šjÃÓØƬnº®•†£ûª
¿ýR|M¡îý{AŽC›„©pxžóAôY¯~Š.tÅ5éKþ¥ê•ƒ
+þÎÿJbp"dX
+Fd¯ªýa«mVKMtÏ—ïü©×Hͳku·óvøÕ°fÌÞo®ÎQƒ®6¹øÕ0]Îäú²ê,Íûø”™8o¨Ž×ÙÁ›»ö¬æ6©†`¬NY¥Æþ3�÷O§ýß>½wß<¸é
+¹›á�þRÙ—Ð]‹“„g39]æ˜îè£ÖlÎ&5fÔRÿ(Χã`Îß‚j×kÇú¤·¡}¿·±9Òo¬@žž6Át:­QuÀpä;ô£Ã‹èÝ8m5µ�°.§­{ïG½ÅÞm;…ËëH›P4Ø2‡'ñ}}Ú&ÃñíiCnÜûá~X]Ñ‡íª¥g˜¶5»úØœ³enNÇ]±nOâëûzcÞ½õPïöÚ;~È›iØï:ws“N¹ízíÓi™ü Îz
Iñ0]÷;�µ5»Ð�'·}wºòÍ“=îµOïtŽk³biÃZ¾ƒ›½î9JÔèî´q¤Û·Á¤Í]Vj³:«÷&T¡6(3BêôÖ�žSÛ4…� ,.ûù$Þô:V³¡¥Ëut™l¬xÓìÎ.N³Y¶¿ÀÍû—­cYjOóÅ–s¸§ÉhÄÍGŠ8�ä}ÕíÊî¶ûRoþû—\2Mú'ýd_~z\Í0ÌûÇ¢P‡°ìÿ
¶H¦¿ýoÊçHH=(ËÜç%OŸñ—stÎÏ•"$}Õ¼øÛåGÕÿôtúendstream
+endobj
+1060 0 obj <<
+/Type /Page
+/Contents 1061 0 R
+/Resources 1059 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 1050 0 R
+>> endobj
+1062 0 obj <<
+/D [1060 0 R /XYZ 85.0394 794.5015 null]
+>> endobj
+214 0 obj <<
+/D [1060 0 R /XYZ 85.0394 717.5894 null]
+>> endobj
+1063 0 obj <<
+/D [1060 0 R /XYZ 85.0394 690.1986 null]
+>> endobj
+1059 0 obj <<
+/Font << /F37 747 0 R /F21 658 0 R /F23 682 0 R /F39 863 0 R >>
+/ProcSet [ /PDF /Text ]
+>> endobj
+1066 0 obj <<
+/Length 2379      
+/Filter /FlateDecode
+>>
+stream
+xÚ¥YKsã6¾ûWð°ªÊBð"H:'gÆ“8•õxmMö�É�¡1w(RCRÖz«ö¿o7¤(šv¶jì*£
4�~|hÐ"àð+‚È0“Ê4ˆSÍ".¢`½=ãÁ˜ûùLxžeÏ´sý´:û჊ƒ”¥Fš`µÉJO¬ò?BÍR¶
+F‡ê/Ç’Ý¡ nŽ!‰\°?xRˆ8¥3Õ†ŒÓ°Þ`›„Ý£øº�<´øç¹¥©²h;›ÓlQõìEK#v¡xøïl»+-Me�—ô´�Qˆ�¨t^W4¾ËšÅRó°+ÖûhHÀó‰M]w44RÇk൪€c& G›N¡
85I“`ßWÁQj °Ž¹ü}QªZߪ"š)mä8£8àŒuœ€�œ#p>õÀ¹ßíꦣŽsß4�Ñ݇˜T&’€àÄ3ó›Í¾,ÑÜ„-Ioi"+K"Öû¦Yˆ$´UGœq˜ÛÏœËÊʨ›mK2\Â�ר*ÛZ¢ºÚKÎsØúEY•ÏΗ…”uýu¿kÙ\¼\{Ë
+§;PYÙÖDí[ëïšÁš£ÝlKC�çÞf_=û·½mŠ~úðh½Ñ›E¨¾P¿öãY5Ýe�íº±Ó>Cúm�ÊÇ,U2qʨ!“¤ThÍCæËiÀóJ&½a<¥Æ»m!–êÊù	¨Kø!Šº®In‹YÌEx÷áM+eQ¹Ý�$ÏžVÀ0e3dGÜeã÷0³;œŸ:ˆŠ
r´IÃuY@8-Û"·4Б
��3N6´Ù4xÈ<‘­ûp‡;ú°d[?Y¿åÆ�Ô[Dœ!i`Ëeâð—ú`ŸlƒµƒC0fûî±nŠîÒ';o½+rEÒ‡)P­m@Xë;$�e�åDý‡`(Ì¥ÒzÞu]uYáúdÞd0
9'&+HÈÎÚg糋"Ô^)°u{°
->1tȺ3¢ç='GžÃ
+ç3{œÖ/µZ0)¢t¤mQu3ÊJ,ž†Š‰´Å,Šãð£ÛÔí�n
›¶¤Õ&²÷	P)MxŸPQ2R-ÿPTYóL|eö`Kçgslj:˜Ï`)�ù&
+¿Võ¡"’°Âx©]Û5ƒØ�‚XÈÁç„
+ûŽFGÀÑ! ô‰%d$ªæ7x¤�€ÇZ¿÷ºÆ‚ª³MÑš¢pçL‹�g’ÑÙÕ]&ü{V9)2Ìv»²X»:¿¥ŠÅÁÄFöaŸ×Ô­\!ľ/µ�‡ãÞè@&ÉàDcöíÛÒOm)}í¹7y/Ý]Ç3Ç"înßTx¶ÔÝ�ØZB4Lwìj¿
+c˜,/<+”Ÿ}åI�®0zy'øí†È4H¥Ôb#EˆM4nM†
·K
�R„ßs÷ÝîóíÌÛ¾Q
+Œª	•æ©°ßÛxÐ}´Þ’{ÜÔâX£¬Á¾ÎΧk_©‚ÎýZk§·Š8<	˜x$”{<ÓdóÅ?oîF¯Þ�9^пÓÆÀ7•‹¸‡ë¬èkªK&™xñà1¬ƒÂ,þÅÛ{àú-^JC-˜Ç>1~Wº“Å©;"<Âx<|æ¾^¿‹RÊÿF7u>µÇ›�J3 îðÞƒë|¾vÁZЋ`E5XÔ;(�!Bªñ¢É%Jcî……¯(jð¹&0u]fÀ+x±ÉÆOêpVª+.\”yj_•ÅW{"DO¯RÕ¼!¯ÝÙu�ydÛ¹<"ŠÆbγa|ú<ò5Z¾¯ÂOU@dü˜t–Àçä�“O4è�”%	¥éß>Þ]ÿŒŸ®ð+‹_Å
+tÒ“'--$¤ƒ�Þ:Û­…k"wŸÜTx½ñ¨¡ãà:wá¹™ŠZŠ œí†ÐEôz82CT¼~1ŒCÜB—×Ñ¡h±óþ½×=ÎxKoö¡N¹¸ØÀÏ…H
ML´•‰}q7:ñ‹²v‚µ£3ÍÃT’é(–=>˜
ä>ô/Îz:¼�7® õ9	ñÿ2þ鬊Ó#Ò‰ÂÎ~Gmæ'O’
+?Qù=‘ê#Ïg�Ù¥XíÀÕXu¾ŸõùŠ�¶€$y&zT¼çNª	ÿµwQŵ³»Wdî¡!æÁûî¥ë5”ÓÂ}…×ÝlÆ`DB"zÆ^gÈŒ}Ò]„£Ã™ý�÷eç-ª]
™¢c$È6
+£”òåjÎ$PšÀƒ
+endobj
+1065 0 obj <<
+/Type /Page
+/Contents 1066 0 R
+/Resources 1064 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 1050 0 R
+/Annots [ 1069 0 R ]
+>> endobj
+1069 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [349.4919 384.4828 408.4801 395.2672]
+/Subtype /Link
+/A << /S /GoTo /D (ipv6addresses) >>
+>> endobj
+1067 0 obj <<
+/D [1065 0 R /XYZ 56.6929 794.5015 null]
+>> endobj
+218 0 obj <<
+/D [1065 0 R /XYZ 56.6929 594.1106 null]
+>> endobj
+1068 0 obj <<
+/D [1065 0 R /XYZ 56.6929 562.6395 null]
+>> endobj
+222 0 obj <<
+/D [1065 0 R /XYZ 56.6929 370.2937 null]
+>> endobj
+1070 0 obj <<
+/D [1065 0 R /XYZ 56.6929 341.714 null]
+>> endobj
+226 0 obj <<
+/D [1065 0 R /XYZ 56.6929 214.6004 null]
+>> endobj
+1071 0 obj <<
+/D [1065 0 R /XYZ 56.6929 186.0207 null]
+>> endobj
+1064 0 obj <<
+/Font << /F37 747 0 R /F39 863 0 R /F23 682 0 R /F62 995 0 R /F21 658 0 R /F47 879 0 R >>
+/XObject << /Im2 984 0 R >>
+/ProcSet [ /PDF /Text ]
+>> endobj
+1075 0 obj <<
+/Length 1913      
+/Filter /FlateDecode
+>>
+stream
+xÚ�X_�Û8ï§È£h\KòßÇöfoÑÅ]±èÎ>]ïA±•‰P[ÊFöäæÛ)JNœqºE€˜¦(Š"©)³M?¶©‹4M¾©š<-2VlÚá]¶y†±_ß± “"-r!àeet[ˆ:-j^m¶×J>=½ûðOÎ6<KË’›§ý¼VYÕi#òfóÔý'ùÇAGuzØò"KŠ‡ÿ>ýFÓò´ª+†Ó2X¢H«&«ý„§ƒ"áOŸ¿<ÕÐã_úù0žþã«r¶
åQ+ËS‘—<h-EZ•™Q¤ìa˲,»è¿¯.ïNòôt‹M“6%/ƒj^§eÕ2ø¡É’“ìô¨­‘}ÿ
+5e"�Ç^·™Ž8ù¢�ª’�R†x½6ßUGôY�—Äpã´#êôÀêd6�&’y^~<È1LQ¦s×sÚéä4­[&�_þ 	MꤕÃÍávK›¢à~;£¥ýKzô¶•=‘­lÚ<Ó‹‘Cð£S'´ªÊ“tÖWA@Æ ¾Ï¿¿”[
«[Ó*¤ªD›Ñ[g»©ÅÝã¨QglípìÕÿôøJ lid<(bÍî˜Ð½Ä;’ÆV9÷þa霸©=ÐDéHfoûÞžý�ý1Ö¤6.ˆšnÍ+�_>þûØ/¯£_­v¸Üσá*qz˜úQe'Gzk¿OGµ{â�Wr¢æ‰ä(Ï꺰C§\
+veÒÖNϬ—ê¼g�¸rÞÊ.ÎèŒÈ¢h¡Á¾¨îý<æBh%�ÒË�Þ:z³á˜èáh�Ó»>HÅôÑhÇ L8[Ú,²j¼œ—�D>Õ/…T¿—T„
¬ñØ€0š&îm´Ù­4DÈÞY¢Bž¼è.ÈÜ&ò0§5¤RP¦†³à÷öÆ'çSʯ†í°ÓF^b ®Æû+ìY‰Óò¸ó†_Ž;oDHàJz+ÞI©!úê`Dñ:™Œ¡£Q�’â™Þ
R-ÅãT!pº 
+M&PÄqíèÙi7jÓŽ4¾§Y�yŸ"A¦͠ì‚d,"û©ì±‰kkÒ;¥)ÏR^Š:”&JÓ×9*—“²,J�ן©IW؃È!6Š‚O
+endobj
+1074 0 obj <<
+/Type /Page
+/Contents 1075 0 R
+/Resources 1073 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 1050 0 R
+>> endobj
+1076 0 obj <<
+/D [1074 0 R /XYZ 85.0394 794.5015 null]
+>> endobj
+230 0 obj <<
+/D [1074 0 R /XYZ 85.0394 769.5949 null]
+>> endobj
+1077 0 obj <<
+/D [1074 0 R /XYZ 85.0394 576.7004 null]
+>> endobj
+234 0 obj <<
+/D [1074 0 R /XYZ 85.0394 576.7004 null]
+>> endobj
+1078 0 obj <<
+/D [1074 0 R /XYZ 85.0394 544.8207 null]
+>> endobj
+238 0 obj <<
+/D [1074 0 R /XYZ 85.0394 403.9445 null]
+>> endobj
+1079 0 obj <<
+/D [1074 0 R /XYZ 85.0394 368.2811 null]
+>> endobj
+1073 0 obj <<
+/Font << /F21 658 0 R /F23 682 0 R /F39 863 0 R >>
+/ProcSet [ /PDF /Text ]
+>> endobj
+1082 0 obj <<
+/Length 69        
+/Filter /FlateDecode
+>>
+stream
+xÚ3T0
+endobj
+1081 0 obj <<
+/Type /Page
+/Contents 1082 0 R
+/Resources 1080 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 1050 0 R
+>> endobj
+1083 0 obj <<
+/D [1081 0 R /XYZ 56.6929 794.5015 null]
+>> endobj
+1080 0 obj <<
+/ProcSet [ /PDF ]
+>> endobj
+1086 0 obj <<
+/Length 3113      
+/Filter /FlateDecode
+>>
+stream
+xÚÍË’ã¶ñ>_¡K*šªŒ7�ÍiýØd}p{o¶«Â‘8#ÖJ¤,R;ž|}ºÑ
+Waƒš)m%ÂÌ ™æLZEBµL€ap~ƽ¯Wq/¿£ÍïòI:pH^”ïÛÕª}Žòâäv -©YÕ]O½`ùÐV	sø·ëª¨ý’XP»ëÓXu¬,óݤÔ_´ó.>¿Eúï¾û8øoAè…žh!™å^¢óÿíîç_ùd
±âû;Δwfò8
+h\±›f¢š%žfÊÁ¾x燈v œ0“)¥ÌDsͤæEؾr¾:–‘�‚9sÀ/’dÞ9—gv6`œ�QfH„@ê8€Ñ&rf€â
+ñŸ‹S5Ë~ÐhÙx“áÔ1·ÏfNùÔP”yÃííø0^áS#íXð¹ÙV�õïN•� 7Ä£³œªð	ôcV¸}ÅéíXM¯±êa¾Gž£^äânô«‰Í™…z¯ÝfØÅ\mM:ãLÊ!!Þ©ÍÜ:èùjÆŒ³1ÊSÆe
¨-šy»�r@¬ÐƒE¦Dö
å�]U�X¨)˜Ä 7&�>nŸ&Ôùqt61ÀŸÒ|¤hÇx‘žŸªù>#†DRýcõ‚]0¢ôœœ�PW¨8Å6T#ù
+]·
+°Éä¾ešq6ÀBmã%Ħ+
Ö€*È·º¾Ú^¯zÃà: ¼Z÷ž‰YP2îC† œÍÇlLé¿p0$ÒØbü
+�-�\Š_J@…eÏûuåãd~#

ø.
+Hy‰¨Uc
�‹\`e*Y;�
Þ7hfå*óUÌ8ëÏ;xÃ
”èÚÞŠç
ßEž
w¨µzÌsÖµƒëðL;s”=—Í⫬ƒWŽi
}n‹¥÷ñ<¸u­™†šâõn=aœ�Qf¶™CyÇ�´
,„îvÛ_MQØ=Ø#ïrs`X¥<ïŒå+ Ñè$nÅõ€ñ
+׸6VêC®ÏØ?ðÂ
—/P{Ya§u3_íþ)¦m8óÍDváøôFcE9#é1•õ ôq_Ü@
"ÆÙe&º{¨L·_8É#w°QŹÂ��Õò�l"^uŽ+E}ËJ\²¸È 6F›Àó¢]—usÉ”g…·ÅöÕ±,aœ�Q梙„”ÁQyî<ˆ[ÆñÌdˆgRÛéo»{
jNáo×oé¨R›éó²0ü\‡³]çÆ0&u¼|ÐtÅ
Í·?üDãHÆ{Äxˆ�ê÷r=ËùoÒñä/RêŒAIH×`Ç’1¾°¾êz¶ß�#^Áú¬³)6!Îê:R„?îÁ†t 
.õu•0Áj-¢ºö¸±çÔu€½�ºŽQ^P×C*«y½.W×5öï!»¯‹—J Zí¶4R7}õ„ž5Œ.W»�¤Á§ìOÏ	FC_ºjSnËžàm<b+Pv]î6çˆ	ÿb†F¤Â†®áðL¿ËœÊð°Î$¯)¤Ê1ª™×ÊVÆX
+…—×*Y€’ªxToôÙÓÿ
ðv§ÿc”NÿH<“œ�þ¿ƒº†ÄôÃ?>ëØ
3Ã%dG(‰‡.GO=—�áYZèîï§Âß:wwpäÜó~¬‚)!ìDZ•Û¥Â÷K³ž„q6F™Ézäû²‰
첂dT#eµMKwgìa¤i·²‡á¾òËqSÎY„àKæk÷ajf'•‰aÏ[D¼¡EŒP^²ˆ1‰_nJt0‹=3¶píÚ%×¾å\;’é�†ˆQr.Þ.ÜÛ·°”Î�‚CÑQ8±¯£€ÇÑúݼÝ`BªÊtå#H2ŸC‹J„â½¾6ßðn{Ëòs…=7-×õÓ®î_è}hUo©V$àãÙ…˜vôo½ë"º‡*uGØ)pjÁCàÔBàe"µ›
…ÜͶ.ñ¥IEãa¡Ðûð-Í$¯£ã½Vø´¡—4sp4Ù"KÙóðÐÊMŠÉ
+1™0%ÅvQ­êuÝÓ+”7çÓ=}«#d¼�ÌæiõB#$Ûy»?· öÂÈ!�Cº ý�7+p�Ä!Žb
+ÜÑ ¤X*†aج†F›ÝºÚÖs®Àn�~�É€*íÃk¤s¤Yv/Â{+ß*ARth‰¯‡°•ø¿|‚d™þ€²½@)º>~”Þà ùTÑk"7ý[ûœÍÛGO 
+³ÆGZP[ññk(ü[wÔ6-µ]_6zü´ ‘5hÉ�sª\0Á03
+“ã…õ"GÌX€2Á K!§óÝ–(Š¯x¼‡]Ç^ 2Èíc™¨/Öìªn>EXX'»ÃîÅOÃ;"¢Ùmðx¥Z 5=J·[S­  2³¾�ÍAèAøñ¡êŸ«ªÉ²œÈK’dB©
›Êó>”_>u|¶ô&2¶‡œ­Úy¹Š(FiÁ©Ï“�Ã[ã’Ï{¬—=+K�£z©Â�©«Â&±ÂPÙ÷å|qh�
+endobj
+1085 0 obj <<
+/Type /Page
+/Contents 1086 0 R
+/Resources 1084 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 1093 0 R
+/Annots [ 1092 0 R ]
+>> endobj
+1092 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [356.2946 363.7923 412.5133 376.6291]
+/Subtype /Link
+/A << /S /GoTo /D (address_match_lists) >>
+>> endobj
+1087 0 obj <<
+/D [1085 0 R /XYZ 85.0394 794.5015 null]
+>> endobj
+242 0 obj <<
+/D [1085 0 R /XYZ 85.0394 769.5949 null]
+>> endobj
+1088 0 obj <<
+/D [1085 0 R /XYZ 85.0394 576.7004 null]
+>> endobj
+246 0 obj <<
+/D [1085 0 R /XYZ 85.0394 479.565 null]
+>> endobj
+1089 0 obj <<
+/D [1085 0 R /XYZ 85.0394 441.8891 null]
+>> endobj
+1090 0 obj <<
+/D [1085 0 R /XYZ 85.0394 424.9629 null]
+>> endobj
+1091 0 obj <<
+/D [1085 0 R /XYZ 85.0394 413.0077 null]
+>> endobj
+1084 0 obj <<
+/Font << /F21 658 0 R /F23 682 0 R /F39 863 0 R >>
+/ProcSet [ /PDF /Text ]
+>> endobj
+1097 0 obj <<
+/Length 3638      
+/Filter /FlateDecode
+>>
+stream
+xÚÍ[Ýsã¶÷_¡>EÎœ`|$Ó‡KâK/M.iâL’Ì…–h›s”¨ˆÔùœ¶ÿ{w
")Jvje¦s“ÁÅb±ûÛÀlBá›(M´ãnbœ$Š25™/ÏèäÞ}yÆâ˜Y;hÖõÙÕÙÅ+a&Ž8Íõäê¦CËj-›\-~šjÂÈ9P ÓÏ¿}óêõ—?~ÿòÜÈéÕëoߜϸ¢ÓW¯¿¾­Ë¯/¿¹|sõü¢ÂM?ÿÛËï®.¿ït$òÙë7_„¨~ùêòûË7Ÿ_žÿrõÕÙåUZLwÁŒ
+\Éog?ýB'X÷Wg”gÕä~PÂœã“å™T‚()DÛSžýpö�D°óÖ:&@)Ñ\‰ÉÌjÂ�V‡§
SP˜66•#Æ(;˜u¦-ÑŒâžPK8ïl‰ël‰‘ÄY31@D.üŽë¡L¬!J8·ö¡p lí¸Hf-ÁY—â>wŽŇ쭫Mƒ^¼‚ŽÝXÆ¡mN�£^®PKìôõwø4�¯z3HCŒ°:~´Ú.¯óÍq¡ˆÕJÅa jÜééÕ]>B‘ƒÚXù(ACœ€ï°¢̖ŲhòEษB'�?ï6çÌN«íí]è~„z�´'3&1œCƒ§÷T23}Ÿ•Û¼í뼬î±i§Œr:›‡u1ÏÊò!üô3åu³)æ�Ù�îí9›Öyh_ÇñëÀÚ<¯k˜9¢}V6çðájU¬nÏg‚êiVãS…‰ªª
‰J›µ
+¯ëj™‡
ó(¾€6§ÓlÕ~Ü䛢~FüLýõã�àÁÂëù]¶É€ïMü	Ÿõ8
+°s�(3ÝÖ¸@lyž�?×e6Ïïªrá	© 
+üx›6búªÚ„îüC¶\—ù‹Hˆ
Œ¼“�”7vl>M”¡¬ã‘n<,¬Qjb©8¸Öòög/ ’¦I	ÅcŽšÂ¶Ž8ºL•d„¶æ
+u>ßnŠ&?bSm}ž
mJœÒ¦(…äØÏ`5Ó„*µ©vÜélªCñˆMuù+‹ºyŠUA¸$Ã`ßBeBM«U;6Ṭ‚V�˜!n5-�F
^J¹ÓI&Q|D4ý#`_6ãxõ?¬Â'„J�–¯!ÕkB|)c|‰ÝËb^•ÕªýÑó‚	F¸šž9å«E0`0›�ËZ;Š¤ŽØPG;OeCm¹áé$Û/ÙðÄhqÔ„”ãà§!{:Z¹ÀRƒbÒu”Ã�j5[å·YS¼GÝÔt*øâïð¶X5ù­Ï£á†õÉ	n¢5!…ÞÅï8ââº#||AC_»‰ƒÈd&�6Ü)$'5L5/·5p�iÖ…›¾Æ4@p˜k>Ï×Mv]"�\‡ºHxµ„´½	½7Û
 ù&ôG(Tv…ò�Âþ¡1¯`½šð£ˆ�|WÌ£rí«:<Ñ+Xg랧&F+p£V�»?ª`JÃ2¦ÛYs·Ò
;qøl�Žg]Šûü1ʉ´ÐÕãð@4À˜%”ÙŽþk;ým[‚6ÖÍ|¡K›v×±û¾(ËÐòµ'xÆÚ´|•
+±ç‹
,݇(!úWi»Q#Ú%ÿº]µø¶?§Ä8Û)õ å‡>a*Hʸ0m0½Èo²m9IF¬LE7²«(ø¸§ð/GKk •
+
+»ͤâ£;.8d®Å}uÐ=?j)κ$G⠈…´|7ó‘=ç�3ÖÏE~Û‚‰×aiƒ•ÄœûôBQá·	;SY…	ôøÆôå¹Ì>ËíÆRð»ï³¢Óÿ\VÛ–ë
¸æÑ´O:B)uƒýÅ ~TìxòeSE-l­0Ï{¢8ë’Ü»”’X𔆻!ÖÉd í1(;H�ñAå2Ù�ß‹Ö6²ØºÏê~hp¬eÞ�¯nöì©Î7ïóÍàóºÉ6MŒ†N`tk@yÊ.MaI*iØ<‹qXµÆô2œáïp€âB™7Ôx±7¾õQ¸ÂyV_ˆ#!C­6ŸŒ`gñ§E²¿�p™½"Ró�®V›rLNU»‚w#Ô±4�˜O£…•ÓwEY]?4xà´OTQ™¾ùæ
+|+qÆÙ>ï2V¾JãNV¾êR<\¾êñ�£Ë,Â-˜ådü%Š�0È' ¬Çઋ–ÁÍK%Z'sYø$E?Ó"\Ü‹a8
+
w "p	?Œ%ì&yŒ?±.&/Â_Z3©Ô9�¹µ
+ÍGXÿ/Õ/oendstream
+endobj
+1096 0 obj <<
+/Type /Page
+/Contents 1097 0 R
+/Resources 1095 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 1093 0 R
+>> endobj
+1098 0 obj <<
+/D [1096 0 R /XYZ 56.6929 794.5015 null]
+>> endobj
+250 0 obj <<
+/D [1096 0 R /XYZ 56.6929 304.8746 null]
+>> endobj
+1094 0 obj <<
+/D [1096 0 R /XYZ 56.6929 277.1668 null]
+>> endobj
+254 0 obj <<
+/D [1096 0 R /XYZ 56.6929 277.1668 null]
+>> endobj
+1099 0 obj <<
+/D [1096 0 R /XYZ 56.6929 249.2319 null]
+>> endobj
+258 0 obj <<
+/D [1096 0 R /XYZ 56.6929 169.6708 null]
+>> endobj
+1100 0 obj <<
+/D [1096 0 R /XYZ 56.6929 141.5207 null]
+>> endobj
+1095 0 obj <<
+/Font << /F37 747 0 R /F39 863 0 R /F23 682 0 R /F21 658 0 R /F48 885 0 R /F14 685 0 R >>
+/ProcSet [ /PDF /Text ]
+>> endobj
+1103 0 obj <<
+/Length 2809      
+/Filter /FlateDecode
+>>
+stream
+xÚ­]sÛ6òÝ¿B™{¨œX4@ðóúÔ¸NÏ�Öí%ÎÜÍ4�9Š‚$Ž)R%©8þ÷·‹]€¤DÛ¹kG
+ùÆÓauÌF
ã�Ü–ºš Ÿ³²X�´šå9ùZL6_:ú •oÈ>ŽHd4 ©Ñˆ�€m=ÔÆ�´õås9o[°%•Èù-1ȱ„C/¦tîTÛéfG3ã
/Ä2h
ZkEÉÆqp¡¢Û*õaÃӪΨ+cÚ“vô¯­F‹U% üt¾)>[ÈͯqŠ(\`çB×úB+È*®äõnÏ~¸¢´!f�…¾>®áõÁ\T�ÒU,Œæ¢k²Ïº1‚0àÊ1‡ê£›0²C2Ù¤åÊthÎiDLhÔlDìd
+c
¸2d²I\à€�hªV‹°8�.ƒk5¼ò¢ª»b=UP‡ÝqÌÈô"/Œý`Dí�ƒn&‰…ž
+üÿƒÖ‚ê¨ø¼$QÉØÆó,wEéð4¬IÓ(|済ÄjtDŽª]S„8¢AO˜$ÑKôÆìö&ûLPƒŽPªÿ‘;¢¶
+RQ™útàè™&šBÍõ¡ØeÖ”�çRJò�6
+ÊQX‚’¬¶5,=PÚ3•Õ0é`c«›ÏS%es,ÖêŽÈ Gí;¢‘¦å
+G¨I°>¢»‹+*ýÍ´§÷’Э�†…Mß«šƒ^Ý�¤v'ñÂGá�jú·Ú^S¦Ä–o·

+>tÑÏMÚ…±ÂhÊi
+â±?W[ì/Ùn_êÉ6…n{òŽá¥RÚ6Xz¾§.ýà[Ì%éüÕù"ç1POªo'<Z_»ðME�¯Üüò{¡ãU^FŽÀi§ÁÍXRÉþŠ%4›®8ªÎDè“Ü
1lÒCœê‘ü<�=ðŽqp.ëúþ°GKP¦F�I0àÁÆ3¥U¦TN&FÉ—Üí€2“ùǶ|£`&!Wù�
|¯»¥±qGûT°qì%ÒåS¹[GÙ	®kë%pDKæÑ
+¶Ùgª£ä@Ô�CÖò(hF¶±„öô~ê嫯‰\'¸´Õ{f‹üº¯®è°×ô�M
+�µCô
ž“›ãe�V«/¢g
+|EõÏR1¿ªw}½ö
[½/rƒí�GHVƒöê-~Ç…F)åvÍ‘ƒ�–ÈQ‡ÅeÂ׶»bìvØŒA·ßëŒ1Àðú
+Ê`‘žbôè¢Óí>˹3Üe�Ç‚'¢¶(¶ìÃŠJ´†Í¡±:‰c¥Æ>/’ó»óԟ״`(i§áF¶šM“Á�š–€&øà†’±ïh0bÅ&×<Ò25¹°lš\À!;ÍÀ‚Ù!Ë
ÀÕ�oÞRþ|º3h¡--/÷ºqo
+�x�S·BëˆÀ:â�}x’-dh*}Ú(.
PÑÄ1–
^("÷Ú,XñîÌC$¨qÄ1£�ô‚3gOfÕbW4^aŒ–"”g23ø%û«H=_BU4êD./‰îŸæëÍ›©Fço
u\¬yþñöæß43º¶ô°•Á‰Qý3êê¶
á{nûÐä:¾�m¶Ñ/G‡«Þ«MñÃ�Ïy¥!9rkÀ²ÎUR½[?Eà¨GíÿO:ud|paGžPÊÕÂx>øƒx¤ bm»¬éh�O•}òDP÷P$ßfM–wÆçqáò5ÁñÝ´-³Û;9|D%,j7ñå•&Ã3^_ÄP€]ü~fˆ A¤‚ƒ…‰«§+.,D<xñ¸B€ï•.¡2§N>™a^(Z»Ç]ñ‚‹HØŽ<=ˆ
+Š^8r/(8ò¡\«ÀG]Ù³3ð‚_…LZ›ˆh%”äãÇŠŽ‹m0VöîPvžtuv…:ÏiÞiÞW扗ŠwXéÓ[*
•P\Ô•†ðeßS
¼®1ÝñëºO%¦²�	
+endobj
+1102 0 obj <<
+/Type /Page
+/Contents 1103 0 R
+/Resources 1101 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 1093 0 R
+>> endobj
+1104 0 obj <<
+/D [1102 0 R /XYZ 85.0394 794.5015 null]
+>> endobj
+262 0 obj <<
+/D [1102 0 R /XYZ 85.0394 438.8479 null]
+>> endobj
+1105 0 obj <<
+/D [1102 0 R /XYZ 85.0394 409.9891 null]
+>> endobj
+266 0 obj <<
+/D [1102 0 R /XYZ 85.0394 349.7918 null]
+>> endobj
+1106 0 obj <<
+/D [1102 0 R /XYZ 85.0394 323.4555 null]
+>> endobj
+270 0 obj <<
+/D [1102 0 R /XYZ 85.0394 249.9022 null]
+>> endobj
+1107 0 obj <<
+/D [1102 0 R /XYZ 85.0394 222.3206 null]
+>> endobj
+1101 0 obj <<
+/Font << /F37 747 0 R /F14 685 0 R /F23 682 0 R /F21 658 0 R /F39 863 0 R >>
+/ProcSet [ /PDF /Text ]
+>> endobj
+1111 0 obj <<
+/Length 2453      
+/Filter /FlateDecode
+>>
+stream
+xÚÍZëoÛFÿî¿B@?TB¢Í>¹Üö“ë8>—´µ}8ÚGS´E”"U>â:ý;ȕDKN¢+Œ
+©ˆF“›»€WŒp“ÉÍâ×i„(š
<=ûéûˋ]�Î$ŸÞ\þôa6§Oß]þóܶ.®Nß¿?½šÍI,Èôì§?ßœ_Ù©ÈñøáòÃ[;¢ìç	¦WçïίÎ?œ�Ï~¿ùñäü¦—%”—`¦ùóä×ßñd
bÿx‚S±˜<@#¢�¬N¸`HpÆüHqr}òKÏ0˜5KGõG0¢,¢#
+¤lL�B¡ˆÁ”VàÙ«Wó¦},2�Œ«iZ­VYÙ6¶×´IÝÚæCÞ.m«]:Úö¡r‹–I�¤mV»eoÞØïoXà¦HšåkÇN·a�ØnR.ü¦e›—�g[mí“yºênkf½|læÚ ˆ9!H	A�Tyš³9£Ñ´ÈËL[—ÅÓ›eöhÓ¤,«Ö¶o37æ±°Ý$­g$žVMcû«®hóuáˆõÆ›{4ßC;âæôzl™|t´UéEu?¬qŠ¶�f�”cb›ê[g¶ymÛY’.‡QÛZuMk[]ㆬ¦ aLßu’×ú.£~;‰£Òl÷®ª÷¿’lû�&/TÁ%ê—Äf‰æaºÍÛò_³µn¸K¤›Ú€ú›Ø�Ó
˜‡PÃí(³¿Ü#܆bÈƶ~³Ä/|ØàüÚö²�YéUu÷K·¶ÝäáÌS<ŽYÂo¸Þ‘¥—s]góªk¶d3*ÜðC`MŠc©ëëeV¡j·ñ–Xgµ›s>”;x¬:Gaîiv—Õƒgòâþf„Î;blF)âãpd}ÒoF„‰�
+¶Üõw­è9c)ÞT¸‰á
¶Q@XÅoÌÎèýÁ9IÒØo^ºhþê•mxý˾ù›�€†»þ
>@Âý¾ÈÆ’¤`¹z^–$)%øx–„ƒÆI…ùÓ¼ì:¼\Ó¯Ød5 ÎcDU¬ÂdÚ«ÿnQÄ$‰&.B‹È¨èß�‡ˆˆMk„„kc]ätC§Wæ@™^öm:½ØÖì‚%\L.
jt5ù´ çÌ…m#ý 3ðærÅ&o+�qˆéÏCÎFL
+3Ð>÷Èè¢NV«¤~"×Æ(’Šyï£àfçCKÙOºÃ?bz°É“E�Ĥø3ùì
+}›ÕŸTæŒËéõ]æé\ÖKG¡Â•£°¶OêÂ'S±‘ëaØ¢
Ûq9^ßjˆè¦•Y@Ý.“ÖqIJÇ`½Î’Ú¶õI«ÎPèûœU“—÷vî@CfdÅjú>)ÿ@;#Y'þÄgãÄ~n‹*ýc3³7Ýí|`ä’ùÃ2÷�wRwŠÆC…¬^å%,s@a
+LY;fij©uÊ�[h‹»bÌÉ’h‚ÿÔ}AÕìF`	Iž29	õñuÖ¶$’ÉžÏÒ¯xÊhÐ�ì²×hò<#JöîZWEóË¥…s‹Æ#ìAÇv`	0!+Ü´G÷·Y¯_§ôÛÇ
ÝÛmÃc…uAâÁT].Ò‘ÃAÕ¢"æ×µy‘·�3BÈt�
õ|�·mHŽhC)�”ñ
‚H,â�æµ»EvЂŽ®Ùˆ—íÑÙpœc©Ìú?b¬Å‘Œè,’ 7ºø#{<¨¯f�¥¹Ö�QY„Í"Ø
+ô‚Ϊ‡ØÆ =c_e"W�Â7éà–C)œö Æ?Š¹ÉjÔù§
+ë{sšx¹æÂaÐð~k)ŽmN)êìpB	‹$“TvS
‡œEþåÉ¢„]¶ŒøgŽÈ¼Íj0` £Aië†6AG‘ß/ÛùC¦?v¤*ÌýÐ#‹Ä�ôyuƒà±‰Õ½ƒê’wäüT ˜CѵŒ
+
+kJÞãGñŒLG£DKaA"™$ØØ‚Ütí|Óv·Žeé85…~ÞñéOUÿï73è§HöCÈP-/ÖÛ	Té*㶓ÉÈ=Uk�©žåð/j•©xz_T·æM`|–a|·T¿�¡°ÑZéhnj6˜_dwIWl¥Ödwþ½7ÀûCÍ·Çd�6^,ê'œ#*É
Ôv@±�Ò¥%£ìƒé4óqšÕCUŸŽ½ÔæÑ�Íúm3ê¼·±.’&ߧù@¨‹Õ	£PIŠsL …©ÅêmÝAÈXÌ
J~V°3åR=‹§f¹í¿ýp}}~fÛšßeç<®.�y‹)¬�ð�‡h÷âÒ&��yöð¹Jt7Ò,UtO±žçå*
DåXº�š‹¢Aöú2¥é¥{œåX
+{þõÿã]�(‚¸„è’‚ñð§;?Ñ ä�PÇQÁäþ_hD1ŠUÿ,9ö‚@	=z|²b.ªòðQgÆQ^Lô ùéŒÍ"cÒÇÿ­gÑUòèã{á[iÚùÜZ¦ÙïÇ2Å“&„©
+ÐXÓqõvt‡ÒŠ`|çäþ9»Gÿ²Ë÷endstream
+endobj
+1110 0 obj <<
+/Type /Page
+/Contents 1111 0 R
+/Resources 1109 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 1093 0 R
+>> endobj
+1108 0 obj <<
+/Type /XObject
+/Subtype /Form
+/FormType 1
+/PTEX.FileName (/usr/local/share/db2latex/xsl/figures/warning.pdf)
+/PTEX.PageNumber 1
+/Matrix [1.00000000 0.00000000 0.00000000 1.00000000 0.00000000 0.00000000]
+/BBox [0.00000000 0.00000000 31.00000000 31.00000000]
+/Resources <<
+/ProcSet [ /PDF ]
+>>
+/Length 557
+/Filter [/FlateDecode]
+>>
+stream
+xÚm”In1EOPw¨u€$ÅIg0²Êľÿ6¤¤êV5oʯÅésÀó�ή¯�ƒÖ×O²Î Ž¢‘ÿ¨#h8Çùø:„5?ùÆ [ÄIÚL’~”F ØPÈùYÌÀ¹�dˆÐzZ8å±Ýƒ²ÙËò‘–Œ€f¾Å(ÌÀ�E#@x˜oL Û¹[ƒ±ñðù
+ä
+6\>RgÈbÏWÖ¹j[†�›
+WŒÏ¢®{6;»²þFÃÇñ÷ø]š¨)Õ/Ô¬Mu;pk;Ì©Ëdh<åE–ñ¬AÏw³ð¬±±Nê¦ó¡Ä½�t•‹ùD„™Â²]°Ä(�‡;�„ ·åŽ°Š­r²ÂÙÄLûˆ
T¥Í¡誋ŠŽt’¹w_=Î]ˆ‹=¦uSä÷—ä"ï±yl±‡µÃ-ËkHsŠöreOÚ³êvg›<7ºt,‡Ýe—;ãÒèЭ/I…B÷&ê(ýê³ö󻉨YÙ¹Ç,çkRÔšÚ'^
m"	^�˜h±�ÎW9AVªy­Â©/f�ýÆ"•œãûFy-Sng	\Çdª¼˜©Æ¥†Í}B©•µŒÎ$âw1.¶&�Øíþ²C¶O–ÃVç X×9g¹E{îÇ<•ãóP)!ÍZÜÅŸLÞª~ÑÔ'¯UâXLµüc“ÅXsЖõÚ¯½˜Ó’~òBL–§èªÆ¹O¦ºNZ�_[Èü.øšŠû*]3QôçÇñ!Ö-žendstream
+endobj
+1112 0 obj <<
+/D [1110 0 R /XYZ 56.6929 794.5015 null]
+>> endobj
+274 0 obj <<
+/D [1110 0 R /XYZ 56.6929 426.5656 null]
+>> endobj
+1113 0 obj <<
+/D [1110 0 R /XYZ 56.6929 394.7216 null]
+>> endobj
+1114 0 obj <<
+/D [1110 0 R /XYZ 56.6929 335.9523 null]
+>> endobj
+1115 0 obj <<
+/D [1110 0 R /XYZ 56.6929 323.9972 null]
+>> endobj
+1109 0 obj <<
+/Font << /F37 747 0 R /F23 682 0 R /F39 863 0 R /F62 995 0 R /F21 658 0 R >>
+/XObject << /Im3 1108 0 R >>
+/ProcSet [ /PDF /Text ]
+>> endobj
+1118 0 obj <<
+/Length 2937      
+/Filter /FlateDecode
+>>
+stream
+xÚÅZ_sÛ6÷§ÐÛÉ7ÿ	$O®ãäÜiÓ\â>µ�-Ñ6/驸ž»~÷ÛÅ$%Q¶çæFÀb±»Øý-(1áðgW^O2¯™áÂLæ«#>¹†¾·G"Ž™¥A³á¨ï.ŽþöFeϼ•vrq5àåwNL.¿LOÿ~òþâìÃñL>µìxf,Ÿ~wþî5Q<=Nz÷æüíÏNŽ3=½8ÿé‘?œ½9ûpöîôìx&œ0_F&¼9ÿáŒZo?œüøãɇãß.¾?:»èö2ܯà
+7ò¯£_~ã“lûû#Δwfr/œ	ïådu¤�bF+•(Ë£�GÿèzÃÔ1ýå˜q2Q !˜7FniÐxf•TAƒ¸i

+àœOóù’¶÷±ÍÛbUTmÜí:_­ò5îŒâFá“™ÔÌk¡³ÀÀ§Y•¯
+zû7ÎœHÅ<*eÖ‰„3‹uÑ4ŸVy;¿ù´,›6Œ�í&kÿñŠDØÞÈ 3Æ­q݆ä#z]üʹ¬Ê¶¬+¢äÕ‚?7ùu—Q‡wzqSt²ôƒ„gB8ƒ“6ö	ÄUiL3L›iÞ4åuÕÄz4÷«ËzYÎé�´Š­¶ŽÃªøU7u"ÁNƒN©¾­¸›žÇ¥®‹6®S¦FÏû*pªW[‚Ü®Kð‚{zÙ4YJi&�tÛf­¯¢Z·dB’	š(Só„|z2ŸwCN몥å£ñ~À�Ôü•~rúCOÁÂú`‘1¯Àÿqáwu[P
+Ôs“·Ø²AAHÙ;¢0؇Âü%’I
H]mšÈã2Rä9Å‚Èwe{3â2sÌóL<ìœVgqÌeqU“t´Pž'éI‹Š_¥X6ÅÝMA³^
-óÓªŽçB�ÏÄŽY`‰»<Œ�ÞNs¯"�
+Œí–D	/Ëe}W,Fõ�ç ºªqTY]Ó+i„Õå¦\¶³²z¹9…Ð,Ë291V1§´~Jì„`*̲íØùu³’ ¼×ØA	h^±™fl³šu›šAc.ór™ž ¢¼1†éÈòê~Äk¼bJ½æGôàÎhËx`nj80lWņ;¦µÕ“(ŒzþHc-ôÿOt¦`×R‹Çt¦!E
+NîXÕUñç”VÕOÓÙ@˜o¥³”ãžÎ2Í8¬3*B¹Çt¦_3AËzž/qûBq™‚øŠg:“Óó÷_4‘(‰ÉFRsÓÄ�`¹+ª¢½«×Ÿé¥¬Úb}•Ï‹c1Mª.òbY›"Osß@
+}Àt�<OϽé
+clk¿©ÊßãNs¨4¨
ŒZÕfuYDuÖwUjÉ×ëzs»OþS;Ú‰’{¢ín%;Ñè`ñŽhTt^«Ÿâµ_Y¿Üy¼~—pªM–J²N„Ñ(&¹Ú¯á•õ�bæËXô`A™Å½¤Š‡Ìoòª*–±y¤†
+ž±ÂƒžË{¢Ä<hùÒXj�·õº¡þÄa{¡Œb}0‰åÌX¾sTkp¥<êÐf”Ó¬‹	ñ>
+™IS²J>Ÿ·-%<ö†
+5®èÄÂ¥ÂpU›é(dà³SsY§§Ç^bá‡ýÑh­2`J^ì÷:‚Ë˼À«k.Â
­#pÞ²ƒÞ*,„J™™‰Pž�Úg{kÇq6d9r£`=„
¨ºay+6šG¼5ƒS‡¼|9–¥¢"Sí7ÓüìŠÔw_o°ò÷ÉGÓ†[ñkÃÎ<}•ÉGA‚6Î¢82$7‡ÕbŒ4¬X;£†Ü·3²¾½Ì矣µè4‹ÝA½¡øÙWÞÍdI&�À~bDz8Èu_”êõ¸â�5ºSü›„Èù ŒB@R6C ƒ	ðR±HWúët}ð{¹Ú¬†™oÖˆ³„ÆÌœgšk›ÐLXäüjû‚•ª³á¢ƒúbwŒ7j{0"GF‹ºo)ÄÅoCRêõ@Æ‚¢#…Qs0Œæ³ÌN£ÇÀ2Ý8á7Œ¢—¨WÔˆw
+&\÷
h
Häõ�.xø€«Ÿ�
+endobj
+1117 0 obj <<
+/Type /Page
+/Contents 1118 0 R
+/Resources 1116 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 1093 0 R
+>> endobj
+1119 0 obj <<
+/D [1117 0 R /XYZ 85.0394 794.5015 null]
+>> endobj
+278 0 obj <<
+/D [1117 0 R /XYZ 85.0394 769.5949 null]
+>> endobj
+1120 0 obj <<
+/D [1117 0 R /XYZ 85.0394 752.4085 null]
+>> endobj
+282 0 obj <<
+/D [1117 0 R /XYZ 85.0394 683.64 null]
+>> endobj
+1121 0 obj <<
+/D [1117 0 R /XYZ 85.0394 653.5261 null]
+>> endobj
+1122 0 obj <<
+/D [1117 0 R /XYZ 85.0394 576.1881 null]
+>> endobj
+1123 0 obj <<
+/D [1117 0 R /XYZ 85.0394 564.2329 null]
+>> endobj
+286 0 obj <<
+/D [1117 0 R /XYZ 85.0394 417.9499 null]
+>> endobj
+1124 0 obj <<
+/D [1117 0 R /XYZ 85.0394 388.7174 null]
+>> endobj
+290 0 obj <<
+/D [1117 0 R /XYZ 85.0394 267.384 null]
+>> endobj
+976 0 obj <<
+/D [1117 0 R /XYZ 85.0394 235.1866 null]
+>> endobj
+1116 0 obj <<
+/Font << /F37 747 0 R /F21 658 0 R /F39 863 0 R /F23 682 0 R >>
+/ProcSet [ /PDF /Text ]
+>> endobj
+1127 0 obj <<
+/Length 3451      
+/Filter /FlateDecode
+>>
+stream
+xÚ­Z_sã¶÷§Ð#=sB
+jz_ŠÙÞçx	
$|R†<ÖéæXàe‚)ÝÅ9–Y
çÁ�í–jÜŽ¡Ï>ýyðÔQáR½-6”þLšÜä>í™ü�CwE½ïòàÏ$3c?=ÕšA˜’ÙOð^Gõ‚È°%
+5ؤéãH"˜°&¹]5Ÿ�AΔ‘�†„
+`²Ñ �_c>:©ê±à’B0¶Ðëu3-pÖî7m9@™
+Q=–ë51oŠ0 OÿÌé1/ù~Ɔ‘
+ˆQFˆäº"’vU†ÏfyS¼!øÜñÌ×MMt�«¢¢¾3à	ê7‘éW쬂ü º\ÔÛY¿ˆXú8tS®†p²·ßX:©äaóºðåš]èZåŸjåc&Ÿ¼w²—Ø›qžfT cÌÒ Rãö†åžŠ×‚¶AjŸ�R4�|zVa\‹/‡RVù,í¿Z�-n_R(€âYeÖ
-+Ô ^PPDO7„r+zá€pœ8n’>ÀŠ^xE~S´£‘Ò¦„®Øáü8XXÇçXGk4�ÎÞ †“[`�sÊ?Kaõ:ZÜ£¯z€ù°H†Ž8@¶Ž­pö‚}qða_®[ŒÓX°Ãûý¥K“šÆfdŸ9e_
o 7–ÿÌf樰|^ËPšÈN=¸ko¨¤Ú]ÚdÔ®lßÖ`Ù¡8d>Eý,qa ëdš�LdÄ\i†!^ ®æ™1àf,ÖF6öDsó*ÃÉœŠ1w
Ûw•¢µAÙÖõ:§:ýpÐÕÚp�]^5eÈ“ÖQ]ýt¼ö†ÂöBË¢B�Ã*éR$¾Pêy¦¥ =>¨x½ÎR¥Ž\j^.Ë6_ãQLo·0²œêi£`ÍÍÁ©±·sj|Ù@ÄÏ—ñÃŽ¦]íC——»¼tØ �çÉÇ‚”2,SJ¼òãîÇ}ÈC\9àº%æ›ü‰…ëñÚ@®… =TǶnšòÁŸsÉ€µ¥IöMèÈ+z_ OR–„á°)Ðoéq@9Is8@‚2ð‰_R
+û
+5º,渻ґq
+Ö
á¢)7ÛõõùA ¢Ê‡´¯â)Š:œ¢œÆ–2¸€þÇ‚”lB¥qMù¢õUUOL»r¿�úW�{ż§H@†õzü鮬f¤¶£JA!ª»Àó|„‚�Uc
+¹{ÐϺB}J.@.€zóbf¯é	’Ö��<%"¾G:›ƒâ6[0kï$HµGŸ¼ô$á—–:@ÙSR•“Ìà©ÐI^ï;‹ÎÒ ( ö/t%cÄ“.Â(IE0²*—«@],éã‚F|Ä•®ï°åºlŸ. NÀ�%ÿðùr(!ÞÑDå›Ò§¤S»e˜6úúa­=Ü¢–G
:âkh4P臡Å`H
º¹¥õ¾�›DñäeCŠU½_Ï©#µÆR:Ø.¿Òz«B‡3+€V²ƒV�¥¿  YƒðõcE�n�åb ™†ÏšÉØÖÁexÑ =r™N‹~áuÓ5ÁÛñØKb<“ÈñÀJÔWù	Ob
+BȤ†µ‡%ãâCÉåS ^Fçc6Š8’ªðÀÙÒ¤ÖÀ�ÇkàxR`8òh&¡¥:“T�ÏÙnþ
²FyFË€Ÿf Ë3nh2­Ž­Waæàò¯9¨‡^ûã
+K¹Îº{}9œ#L™­÷ó ¹»Þñ^úïrÐöXQËñ �´
u`‚¨jQ®>ß�IÄ£$¦“${…$?hûU¬šü&#øÅ‘Sít"ša!x|ƒËà9J0b	V$jä”OjDzÅÎg£;4†U»ì]¥Ã`ÞQoë2²{Ä ¡ÎÙË08gÒì+%BU8�ëßzN%Þ¶[a‡qá¬"µ|�8]ÏŒˆcM²Èg˜ ¯üw
+­qjˆ>û"»‘zG*À‹ëäP�»’x L$ð«Ã½=öl¡^î‡�¡ôÕ”Óü]ž1É{D‚Ø[|É¡âÁÓ¨å"׃CGŽ¦�¦8Ò9öowågŸqðá�Hš(K¾�7Ü#õ(A€OE ÃIuý
+endobj
+1126 0 obj <<
+/Type /Page
+/Contents 1127 0 R
+/Resources 1125 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 1093 0 R
+/Annots [ 1129 0 R 1130 0 R 1135 0 R 1136 0 R ]
+>> endobj
+1129 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [55.6967 676.8938 256.3816 688.9534]
+/Subtype /Link
+/A << /S /GoTo /D (rndc) >>
+>> endobj
+1130 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [268.5158 676.8938 332.4306 688.9534]
+/Subtype /Link
+/A << /S /GoTo /D (admin_tools) >>
+>> endobj
+1135 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [378.2799 73.4705 428.5017 85.5301]
+/Subtype /Link
+/A << /S /GoTo /D (tsig) >>
+>> endobj
+1136 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [112.234 62.1828 168.4527 73.5749]
+/Subtype /Link
+/A << /S /GoTo /D (controls_statement_definition_and_usage) >>
+>> endobj
+1128 0 obj <<
+/D [1126 0 R /XYZ 56.6929 794.5015 null]
+>> endobj
+294 0 obj <<
+/D [1126 0 R /XYZ 56.6929 403.8784 null]
+>> endobj
+1131 0 obj <<
+/D [1126 0 R /XYZ 56.6929 377.7405 null]
+>> endobj
+298 0 obj <<
+/D [1126 0 R /XYZ 56.6929 339.6466 null]
+>> endobj
+1132 0 obj <<
+/D [1126 0 R /XYZ 56.6929 308.8302 null]
+>> endobj
+302 0 obj <<
+/D [1126 0 R /XYZ 56.6929 236.1221 null]
+>> endobj
+1133 0 obj <<
+/D [1126 0 R /XYZ 56.6929 207.0192 null]
+>> endobj
+306 0 obj <<
+/D [1126 0 R /XYZ 56.6929 125.1654 null]
+>> endobj
+1134 0 obj <<
+/D [1126 0 R /XYZ 56.6929 93.2531 null]
+>> endobj
+1125 0 obj <<
+/Font << /F37 747 0 R /F23 682 0 R /F21 658 0 R /F39 863 0 R /F48 885 0 R /F14 685 0 R >>
+/ProcSet [ /PDF /Text ]
+>> endobj
+1140 0 obj <<
+/Length 2602      
+/Filter /FlateDecode
+>>
+stream
+xÚ­]sÛ6òÝ¿B�ôLˆâƒàÇå)M�œ{WçÎqçÒL†– ‰S‰TEÊ:_¯ÿýv±
+Olxwý÷+½¿}óÓOon/?ßýxqu×Ë2”Wp…‚üvñé3Ÿ-@ì/8SE®gG˜p&ŠBζ‰VL'JyÈæâãÅ?{‚ƒU»5¤?­r¦s™(UH�º`©‚%TàÝÚ €*¨"g™à9ÐGœ_Í£ÃQcœ4Êá´]Ù™­©;ÐO¢yYÓ ™Ï{–n­ƒ#a £®ÙdcÌÆá/GH@©©á\®û²«G!‡Ð8òUÝV+2)®™–™ê¡2Ç€T..ãz*Ø…,tô7óØÒ	ãîY¬ÒŒqÍÁ|…`…ÖÒnDk³
+´{Zܯf4¸8J�7œ;Ê9]d⣙;´¡F²äŒ
¢%€>$æ®=Ös\œQsªÄÂöÐv4²ÿs2;˜–n™\	Öß``��‘Æ3År.Aá’3ÎÁòGQAOíÌ}l£#H	ñ'Mg™°,'/	€’yž‡Ã_ÜSŒ‡$­²Æ¬IÍ’B'§“‘Åjò"gX$Å+4i
žÑ60’YôkÝk–-ý“q
D†AÕåÖØ�2ªRI+‹f[Vn?bÑèPW¿Ìæ‘f¦ê®Z>VõŠ6�BDÖ5etݘ\÷žº¶½>
v(„ûË×.Qi^x÷3û³y)Xƒ��ànãEˆyÙ‡†ý¥È#2¶Ž4Pž¢wëÒAÜ©m†QöU«>p«ní÷V.HyYõç‘R}ˆ[,ˆ—ÖáoËn¾vÁDOeáuEĦ"–óŒXÉóxƒÛq0bFU=o¶te€3Ö×僡µ{cj‚õÂÀØ	ë%
Èš``Yì);Qó¬·²¬k³jö@`ëç5Ý?_|kæÄXÇüòón
i¦¼[÷'�9w
+.
+†“Bù
+›°MK0¿Á@éRu�ß•pPðع«@,Q¯&pÕ,UÑ
ÜÕÂí;ìv;s¹Oc(иàb|këm9�·�(ÉX.yÖ«s’ît_7XJíº
RPIB鬞#•OHI™ˆ¥ˆ«’?Ë—Ôé“ÄôŸ%¦ò g�5Ó¾,u~2!'`˜%zBOù$=	ï>^¿‡Ø,ÀH±/Y ƒ*•�ÃÊÐb0šKÝ]âFÙ
+§`ÿf+¶b
eP%§ç< íL°LùÚô–@n~"j¥�ÇÒ>CAà3Ý4d)‘²
+æT*DEñÍ!ËŒ‡ÏC–Ó…ÈOSµ
(Xg:׃°…š¥›-Ä ¨»…ÆÝ„[wuþànÜV>LÖV%T{ÊÆÜáí¢“ØºÐ�…"�ç�”S%„ÿ®à,[§	MäÅ…G$Y_wôÇ,ѤɸÌèP¬ áy. 9E›fµrÍ£�ƒb_Úûr»-÷
ÃÂä–�#ç¤ÞžH
+·ò
+XVø0Jû‰0æë²®ñÕ9˜|¡Šm@Àí¹6¾FiYmú®ÄäŽ#K÷âÕc t8T-†–f'‚Þoqü_ú;Ô›j[Ù›p¸‚FŸCŽêè·ÕÌÙ2ÝpgÎ�Ú>¶ Ïáø˲œWH‡¡cý®naöû¯ Ô‡Íæ$Çë!ḃÄ`1‡öŠšÃâêf¤$8µ«íXîëÞüé
ì4„g»p3)ž—ÍhÛÂÜ!Ç•ëW�.G¨�pýÕ|(âPã¡ãÉøMc^
+ðÔUÞ'ž£2µ("öÇxËígϹ£ËMg¾ûztYO®3ƾ‘{¤@[C�æ�×O„A�IA&}üqðzÜW§D¶nË•	ä•I€·úð} 2Ÿ|<Á$%UqÞ¶‰•ÊM:z{!Ô¾spñhÛr8z(÷•A›Ä	Ö%ˆÕm�»Žâ"Nl
+6Ÿ!.Ý!‚Ü2K°Jо•ÛPÓÞP›øÒÑýsñ ŒË˜ÎòI¼Þ­÷%½q1	¶Í¼¹[ê4‡nwèhmkºu³h_ћߖn¥—ȶì•©a\Ù�'刯zöR‘¥¸o$(Þ¿¡…o÷Ù:Á�è	-NÝ�‰[»¨k	”U0®}åÜ»dàQÆÜ«´×�v•	V
fcæÎn×Í‘xùÍÁó
hÓ¸	U¨¨Ä-Ùקb˜<Ã,|˪`Y2~Ù~¨ms%I¢¦‰•G‘ô<ÅÊ3¨�’<Ð÷
+9‰s.:ØÞì0-tù×îíèÙtïÏå$¬üÒwŸÆý›T²ôÔËŠW϶ù-!bj7ˆIþ]k»€¶H9&ôMWÁm*ú¤Ãûþù{ïécx–›ç2ümHñ”å²È<S(¢Ê¦œ÷†ÏYÿ�~þØendstream
+endobj
+1139 0 obj <<
+/Type /Page
+/Contents 1140 0 R
+/Resources 1138 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 1145 0 R
+/Annots [ 1142 0 R ]
+>> endobj
+1142 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [103.6195 731.9163 159.8382 743.9759]
+/Subtype /Link
+/A << /S /GoTo /D (controls_statement_definition_and_usage) >>
+>> endobj
+1141 0 obj <<
+/D [1139 0 R /XYZ 85.0394 794.5015 null]
+>> endobj
+310 0 obj <<
+/D [1139 0 R /XYZ 85.0394 589.1911 null]
+>> endobj
+1143 0 obj <<
+/D [1139 0 R /XYZ 85.0394 558.8491 null]
+>> endobj
+314 0 obj <<
+/D [1139 0 R /XYZ 85.0394 294.8462 null]
+>> endobj
+1144 0 obj <<
+/D [1139 0 R /XYZ 85.0394 261.6947 null]
+>> endobj
+1138 0 obj <<
+/Font << /F37 747 0 R /F23 682 0 R /F21 658 0 R /F53 962 0 R /F39 863 0 R >>
+/ProcSet [ /PDF /Text ]
+>> endobj
+1148 0 obj <<
+/Length 4109      
+/Filter /FlateDecode
+>>
+stream
+xÚ­]sã¶ñÝ¿ÂÓ—È3'?zO—Ô—\Ú\Ò«ûÐI2J¢$ö(R)ëœNÿ{w±�”!Ûio<‚X,ö{!y-àO^›$Jr•_§y!Íõrw%®7Ð÷Í•ä1s7h>õÕÝÕ—ouz�Gy¢’ë»õh®,Y&¯ïV?Í’HE70ƒ˜}ýÃû·ï¾ùû‡77i<»{÷Ãû›¹2bööÝ_n©õ͇7ßÿæÃÍ\fFξþöÍ�w·¨+á9¾z÷þOÉéqaÒ·oo?ܾÿúöæ—»ï®nïü^Æû•BãFþuõÓ/âzÛþîJD:ÏÌõ	^D$ó\]ï®b£#kí õÕß®þê'õÚOƒô“"R:Q
*" É£D+í	ßK ‹bv·-i‹ËmÑ4eM/?nEWâfaJ=šR\ÏÌà&{Sóu»¡F{ì÷ÇžÚ›¶ì¨Õ·ÜÛðjí�ž;hÈlÆKÅãã—I*p׸ã×�Ò&&ãq¯iâ‡öÈû*^ªøÈ‹�ƒ4ŒÎšñÜ–»é?Ï©hú¿~Ê#i€!¡eÈ�ßÞ—œ.IG´L’ÙªüYÕT}Õ6Ô½;v=õUͲ>®Jn|×WM1_Öű+©³ß=A»â¡#Øi[Þž»ìºbc鎃ʺ\öå�œ­°ny|a7*e”#ÇT†1™�ó£gÏOD0Kf¸�º|/y<í3³}qè«å±.ôÞ=tÄÐ^˪®ú‡)åììóÞ²!~Ðͪ°L±¢åʃ}kÝŒ=qL±ã)\GÁœd_VU·äYÊ{,Íì]O"GL¶®ìÖÛ=’¼¨k<D
ÇQwˆœÎfuµ«zž
+ò±w§Qª�*òÀ±Ü̵LvÃ<?|zFÆ—"€HI”ņWkŠl< É"ÊsíŸoʦ<–Fv±jÇ+
+-¸ŽÏÞ¬¥½´ +I;;=»âÞ-\Ë-kõ€JÔE´–­Ýƒ2Yùãà¤ãœl½†¢Häœ$‰b¡çøý=æ`ó$IRh
!Îê�Å¥ˆéQBR«ÊšÀz¹‚i´zNwÆQœj§9ˆ”¸ñd_ lj+P(›ØCg„­E±üxÜSÿp^ØÓ®JØîAPÀÏK‰4™²š2�*^ÐÙ$¹WØ:áNmÏ קéì­UÔ
+ô>Vìag«Vû¢ÿœy#x™²Äœs
+öˆGÔ0‡–’½­kbe“Iø„èay¨¼hïùŽ®•

+àÑ”'jÀF%M«@ä7Çõ`n˜©¬ó2¬¬˜Uáû6Ä)ˤ™y‘ãªr%'E
+£ii…];^wUôGà
+ò`ÀG*µéúõƺâ[_ŒøSpðã<~–`*ÿÉÅZ»‚ç܃Äa|+’ÙŸ›öÄPN‡W%GÚŸ2=®b'í%ècyhÂIAq€MÓ‘’Ò!'we»@V“T½t–]QÕa­{t/NâøoU€ªíÈz&*{)2Ålÿ%d^¼¥‹‡«²˜(}é<õ>H_=¹¡yÌ*Ð×™0+¸!…	j!ÍÅS(™Œ€ãÛãq¹Í¢¢$‹³çfqnÃò<,àœ\™—¢‚g*ï>tê9úñKgZ÷ûKtò¥“Ôí²¨CQ´L„ú]óÈÿ}3žG}&|ôgš'þLû2Ÿ	Ÿ$4Vf}Êê¢?'>}k§J_€Ò\%óÛ6b£ÐI`®/ÖSKÎéê-r¢ém‡�7à¥;î÷í�s
rFÆÕŒ	b,�Q†Ã­Á´Ù­gßRŽÿ¼²
æÊäƒëö”}Ïü9ùk€Å^Ռ޸V$}­ˆË
+[@Ŧ?Òõ|ß*NR4p¼:/å,½Cy¼ãfkkòÒU'ãIuÒø^TæÔTØ�ÇEÿxdñ�W0ttÁ¡Ë<ZÈHŠL=-Ńϧ]ˆ…L.†ˆ~q¼Æá¯<,Ž=aG&±†›³ÑÏcp¦„™*“M˜« ÐH³<Ÿl$:‡f>) Á†TìóFU8…¥ã—1S<ŽÏ\FRÓlª‘lb‡-ôÌšLõ›„,NŸ¾j¡y¦=Ë_ôJñŽ«p*¦Z–áRà²éQQ
]0ú+bØýÞ›P�¥Q®³lÊÙ6y,Üý�!
.ƒÀëiÈ)W¶BϦ\½¢ò„M³ö` -�y¾!´wÀ}�
W€á0Äy!Ç0ŽR;F½ÌI˜ÎV>/CÉ`ãT.p¶ÝU~©Àþ8ùÓlYh[¨¢$�ÏÌÅ©=Öll’�õ¶SäSsà2¾œM+«{oVèlwaÛÌû^ö”Œ¯Ëvý
+/X†#©X¥ÁäŸÉGžS~–üK<vùøÎ;&z»ò`«_p_ð—g×?aÐøú'~㯢“ 3Ø$¹“ùÌ?›ÞV
9H§M¨3ÕN6:StÓG�jçjkær“™òèaÛÎ�ae
ë¤ênË[¥#áántp
ðh¯EÁg{z_ÂY¿¢°ÎcPúäü«›7Ã:ô
+endobj
+1147 0 obj <<
+/Type /Page
+/Contents 1148 0 R
+/Resources 1146 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 1145 0 R
+>> endobj
+1149 0 obj <<
+/D [1147 0 R /XYZ 56.6929 794.5015 null]
+>> endobj
+318 0 obj <<
+/D [1147 0 R /XYZ 56.6929 769.5949 null]
+>> endobj
+1150 0 obj <<
+/D [1147 0 R /XYZ 56.6929 752.0323 null]
+>> endobj
+1146 0 obj <<
+/Font << /F37 747 0 R /F21 658 0 R /F23 682 0 R /F47 879 0 R /F39 863 0 R >>
+/ProcSet [ /PDF /Text ]
+>> endobj
+1153 0 obj <<
+/Length 2579      
+/Filter /FlateDecode
+>>
+stream
+xÚÅËrÛFò®¯`ùb¨J„ç�ÇÀ>9Žd+µq²ŠrJR.’¨

+îoúHà»ë›ë»ë�ï®/—\ÅÎ{ÃÜÜþãšVïïÞþøãÛ»Ë?¾y™òË™DFþ¼øí¶(�í.X(3/öðÁBžeb±½ˆbÆ‘”R_ürñÏñÂÉ®9ê“_,U+‘z(¸O€q&RH#À®)d)†./42ÇääX…‰ÈbxñA@R&ÁýFÓ©uÝ>ä5­Ký°[ãRµþ¬-´ÈZ<hÚëõ`_lé÷?º»ä*h¯à3áAÞ”„hî[W͚жmiv]£KZ·+<»2gYðp hw©‚]ÓàYâh*©TELY–Œ
+ú
¶€´®—œóàŠ`«¶£…þw¾}¬õk¹Ì&"g@(ø”¤†Ð‚¨¹\&Ì‘PŸÌ;Ÿ¬
âÎ
¯B†?Õî
+ø$¤«¶}ñÆ`2‡CQf$ÖàY.p)	}é½ù¯7“�›%ãÊàì+´	Ág�^�‹‰ÙÈQø´¶n~-g¸”v§#쌌 ys ÅPmµ]mìÂÙž¨,>äÙóÜ8¨G¦I@V³ÎÍoy|	¨šÉŒ¸§Ç”#„TÑìrØ2|€]¥`G»Â�}5l<ž+Ê.uÁ¨<4ù¶*|AK†œK‹vT^½ë53RèÄ
±þeO{G¢¥Ó7‚�à

+Á‹T�O��9�î¶U£É ÷£›L¢
+cä.Ž¿�úm~˜>2	/Ž
 Ô’(TIÍ•’{ÈI!½&Ž˜þÐá¾@ÏC%™E³AçʦµÝ@éª2JMÁÀvy]øØä+¸×W͘I¦dðR’YýJBòºoé^#Æžž$�
Ðê,v‰@(h“¥߲xÄB¨BÒ™v
+¸gÝv=I¦‰t™$@y4J€&æQ”âÇŸ;ݺDá)î,
¢Q�ÆÁøšùÂ�‡¿ã¶u :d
Àv›�ÖÆÚáw¯kŒ2R%ÁMÕݸ¬£DPùä #*ŒèS9ŒqÄ#‡(L¹šÈ�ˆoì†M
‹÷K.¦¡
+¾\¸�¥	ýœ1G9à‡M#°z°ç€Ë(£jÍã‰2¥H¢�ÞDµìX
+>´{ƒ‰èT>-Ãa+*:)#,¶L£º/ºêa7§-(O±_Ñ"f"dèÞÐÒf·^ÐânÒ=ŽøËé
ê§b8¿	üEht®ÿ)BqJ¤æPbÅ;}á¬�±ž!äü6j¾<Îc )Ñ=ƒÕã'›qŸë¦he®·móì^¢á¿ze»�
WX݈9„–s<FOðš~9�îžU^TµÍ6 �9ªðô%U³jϨi›úpJÄ“v~ÌG�˜Q“»Ã¶Õ´m¦yÂÀ_cE"Œ¾,õI+å:?mÑŒ“†c^ §P­9ÝKz.øÛqú<Ÿ&ƒ˜ëÚî_Ƨ
½U†nK ÓNÇýØ�¬È5�}Õê�|™è€
+(/}IaTÛêŒá§ž®V'Ô»–fJ@?äݠ˧î1m×ü¦—ËÕKK“É/¡×½}2uggŠ£¶‡ê—ýój*v]§›á¬!§ŠÉkœÂkœò‰�0QâS!Á !—é™9ö'�€n|vÂðÿ÷ä¯V³«g3ž†™ÄYäl‚HÈO6åghûÞQt6£¯õ£^m‹-yÊ¿§ÀI{�£kÊPô-#™ÌÕ%ÞÉt4®pÉÿ4õJ]
+p�H�ÅïPâyxå‘UÆÝÌi¹ó0é4D(æ"s%4~[jêࣦ™XÛtBP£:øÅih£VÎC‡ùßÅØ=#óTdÎeG�N^+¬D¨�D’ÐtI°)ô\D󘓯íí$pX Äs�„ãXñÙ,.N�ÿÑÈg7vžcMC�Þä×Ûï¯h5þÄ´ÖfÐsüÇ‹ó0SŸFÜÅèpXGyf,#•¥ßD¾v™¢Âª
+v�V|\	…º¯³#ï;·‰¦ÿ¨1ß4³±ÆÚ¶ÈI*í@%Gè;6Ã
©αÌÞ¡ÝÑ¢ÑÚ¾c¤	¿Eþ8ìÆÖ0•6iàÉËŒiØñŠí®¦ôÙëhÿWk7©öοM,ñ{$5¡2–ë¯u¨˜='fΘõîc¤°‘e
+e$³SÊÇŽž“þ7½6Òóendstream
+endobj
+1152 0 obj <<
+/Type /Page
+/Contents 1153 0 R
+/Resources 1151 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 1145 0 R
+/Annots [ 1155 0 R ]
+>> endobj
+1155 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [173.6261 500.8708 242.2981 510.2804]
+/Subtype /Link
+/A << /S /GoTo /D (the_category_phrase) >>
+>> endobj
+1154 0 obj <<
+/D [1152 0 R /XYZ 85.0394 794.5015 null]
+>> endobj
+1151 0 obj <<
+/Font << /F37 747 0 R /F21 658 0 R /F23 682 0 R /F39 863 0 R >>
+/ProcSet [ /PDF /Text ]
+>> endobj
+1159 0 obj <<
+/Length 2502      
+/Filter /FlateDecode
+>>
+stream
+xÚÍZ_sÛ6÷§Ðô%ÔL„#’ /OnjçÜ9;9W÷Ðk;J„,N(RH»ºN¿ûíbAŠ”)É>;3?˜\,Àoÿƒâ#þø(Y{ñHÆ>\Œæ«3wtcθå™4L“.×÷Ó³¿]
+9ŠYzáhºèÈŠ˜E|4MqBæ±1Hp�÷o.¯>üûö|,}gzõñf<ñ×¹¼úç=}¸=¿¾>¿Oxpçý?Î?M/ni(´2¾¿ºù�(1ý; ôöâòâöâæýÅø·é�gÓö,ÝórWàA~?ûå7w”±<s™ˆ£`ô
+쌚©ƒøq—y"ô
+δR.z¾b
rQnzü­vÈ8Áq@1Á6‰m¥´Nî”Ý3Øzï|d
+æ#¸ëü<Ž=§¬ß¤Ä±ó¿npnu~T’ô×ä1ÔÀjû¹�âsoàO³WO°˜»þž�e¹"¦ïºÓ‘üÝ»!'Õ¾Ø8)+%±MÅÿõn¦¾ÕíÔwp¯´ôÀùÅï›ìkÀCà�<¶ê®M�V­CfzN¹Æê8ÁØeñ.¢ŸÚôœìå8­ãq|óxÀ¤ˆ¤�\E
‹=Þ®ÇY
-lC–ç—ÌEa}ëéê�…ÚL0=uC.ÛÇõ
å�9Ö1	ÇÃÈe'*ºþ.·ã¹Rï“,Of9\–Ò«b�:>Ì€¶ ÇTéù&[WYYX®rÑ,œj»V{c”æà
ýa³Jpz;kkW/‹*É
+6ÐuÙa ÚZ%Û&¢X£IS•öíhQWuWÆ®È'j® jÒl¿”çn˜�„X ƒ'ó�·˜tå^1ÿÿÍj6‚µ äê0ï€æ¹ Ë>63ú¢&í¡ ¼ŒaÍ8Úµ
+½ê
+·“°§
P§Ú ‘-�@·=èí6ˆÉÊ>iµ1]£Q­-5tÕËÿ-µgódÞvü°¥ÃzîøZzn"ÊÓE6Ö³-	ÿ¸š½H°
+GMtlï‘`‡úøæqÊОî>SCW‚ÝE[&èW¥9ç´†<ºu‹8~³îæþÜÕæêÕ*1ßå„�}µ—èžàæ–Ã	Âö,âÐ5&`;~5—”‡<Á“L
+ì§Á;S¼`‡
+fºÌ´ýž"Í…¡8t)„0{‡Ò¿y!Å~XšiꀒÐkS³"ÉèK`'Ÿª�)UÞR{7ÛÒÀî«.bfzø›^ã°M[7x—ËcñÜ‹Þ#ž¿s©—yé×�£žÏžŠ£^„?D 8Z¨ê¡Ü|9é÷7–�"(T»¦C9+;{ù–S÷ Qãá	Èx.Ù`¹NÁ/N·[ˆ‰Ù¼¹DÂ9Çàêìã[†ËuYè†'.¸ë3t¿Z“¯uµ`•ñœ$NG^‹’¤&>	Æ%]]ìÿÇ�,5Ÿúßݯ¢|ÉDyÿéñdZ
+endobj
+1158 0 obj <<
+/Type /Page
+/Contents 1159 0 R
+/Resources 1157 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 1145 0 R
+>> endobj
+1160 0 obj <<
+/D [1158 0 R /XYZ 56.6929 794.5015 null]
+>> endobj
+322 0 obj <<
+/D [1158 0 R /XYZ 56.6929 729.6823 null]
+>> endobj
+1156 0 obj <<
+/D [1158 0 R /XYZ 56.6929 704.9004 null]
+>> endobj
+1161 0 obj <<
+/D [1158 0 R /XYZ 56.6929 387.929 null]
+>> endobj
+1162 0 obj <<
+/D [1158 0 R /XYZ 56.6929 375.9738 null]
+>> endobj
+1157 0 obj <<
+/Font << /F37 747 0 R /F23 682 0 R /F21 658 0 R /F39 863 0 R >>
+/ProcSet [ /PDF /Text ]
+>> endobj
+1165 0 obj <<
+/Length 2770      
+/Filter /FlateDecode
+>>
+stream
+xÚ¥]oÛFòÝ¿BÀ=�žî'ÉôÉ�•œ‹ÄéÙ.p@´´’ˆR¤*Rv}‡ûï7³³K‘eÅqt—»³3»ó=#³QÿØ(Qa$R9ŠSªˆ©Ñtu�°÷áŒ9˜±w¡~º;{ó^Ä£4L5×£»yWFIÂFw³/Á»^ür7¹9s:<+?]]_ÒJJûÏ×ï¯>üzsqËàîêó5-ßLÞOn&×ï&çc–(ç¹ÃpäÀû«�š}¸¹øôéâæüëÝÏg“»ö-Ý÷²HàCþ<ûò5ÍàÙ?ŸE¡H5z„�(diÊG«3©D¨¤~¥8»=ûW‹°³k�ñOF,d\‰¼‚…)‹“ãt‰FtÝ”)JïÓ3‡RÅ Íx¨…—
+g©0)ÂD5ŠUjÁ…ËŸ[³ÉM�ì
xÑ�ÆÄJÆ@án×fšÏŸˆ§�K³9gI`èÓã°õ²Ú3šß;€¢Z,Œ[kª‰
Ú1(Å-þ‹æ|Üê&Û4Ûõ?à+
dD5/´Û,
M¦YcÕæÉÝ»÷N-C®™p?þ@
Ú3îàó¢ ÜYQWöŠcñP®úW5ev_àËⱟ³`óD_øN{WüØ–…©ë¡ò8ä’'�>ÁÉ�‚ÄbÉ\µnòª$ÜË¹'ÀaSÒ]Y…i"W²:ËÀߢˆ›Ù Ûï–†Ù[Ðïb'¦lü‰{]mG¸ñ§EpwËW¿Ð³ÙŒŽÔn#+gCôãùXè8(·«{Ð*°b�½Hµ=aw,)œ¸;
+­ƒ2[7-2$‚
+Pë#øÇþ¦Áê·àÉyD¾ãéí õÇÇÐü•­Ö…	§ÕŠ°\]Óx
ÿÑì‡ÛÉÐé.é·o‰hüQv@´4Í1¢c"Ú
("J¬5u½ð+]»�I( ‚‚'."ùœtB�*IBq"ZèÜ)sì™åõ:k¦Ë“áâÒ
’7<¨æ4æ%ÈÒ­²`�Mÿ0Öð`«©Üh&µÙ<XC„ùªšmrãŠÒ�FpÜ…©¬·\õcÒÚnVSðPÎ7J³Ë¥×q~'L¯p/P÷ÜãÂŒu³„Ÿ¦J€H$f	OŸžåõííä�ãhé¼ÀÝíÕ‡›jZœA?ÃÚÎ�_LJk…
+­ÔPúÇY+£0QüTV¥4ÜA¦Úò¬€ð4&õ=�Z}`[*u
+_cä1ÆæÚm´šŒ«¼žV%õÅv“aR`Ã_d#
+ÊD:ßj
+³°âWeñtÚ.[x�$¤Möc,
+xk	=ÌŽˆ©#
"0”ð®ò¦±¤v%‘¿¹í»Ûu·‹A/õ½9ï Û^›ÃD—¶?³pö]�-é���&ñþz ›IDpŸ—³š¦Ä
+œí¿lFcF(Ä9v:�k}Ä/x‹¸ê! Ot<eGŠz¦0ÁÀP{)!eczÏ:³)¶—¹HÛ'¶
+�ªÍ…oœ
+ß:®×P€
Áíú¸w`àdêfsžÛ)IÊ…Çê€j«p¶ÊÊ’º^TPq²Êj³Êvz,úν=ºk¹9È+,‡Rn#VÄœ®ÊVWe_WEà—wÚ)„Ë�q{fæ™-ð†¸�3
+­ÂÚNêÚó¸×’lÝ—Ù£ìbí­ù¬$³!Gºi©ØU³ÉßãØÓÿäyýg2m3uJ~Hb!¸
_ËeBõ„´†œ?dE»nÕV¦Ç*	À©õ.ïù>Òå@ÂyBÞ˜fúfc-ëX‘*ÜÌÇOP¥ø›Š½»bù̸Wf4P ÁY5'3Å<Ý+”mžì½Û2Ç,û s›­×¦œí~?ìzÇŠìg­º_E¹ÎÇËDÎÛß)õ,àÒ$eCœt¤êÖéâê�§±Ô¯¢|DÞ‰jñ~—Ä!­µWè·f9þöZ»7Q‘ž'¿çº8؃å�ö~ŠÌWÛ “ÚÿÔsêá9¸bû0’rïÉ™@Qih×¥øÒûgœµ™€ì7 pÏŸËó%ÿ°d�'­UõÇvMË÷Æõ¾Ž4SIU½â®³ÆÍLáÍ£
+û£HÚ%ýä°ŸzGm=÷ê?XØý5‡Ä~D÷·ƒž‡ñ}w)|µdõ�HB•ðxàêÿ5‘Cendstream
+endobj
+1164 0 obj <<
+/Type /Page
+/Contents 1165 0 R
+/Resources 1163 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 1145 0 R
+/Annots [ 1169 0 R 1170 0 R ]
+>> endobj
+1169 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [519.8432 252.798 539.579 264.8576]
+/Subtype /Link
+/A << /S /GoTo /D (lwresd) >>
+>> endobj
+1170 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [84.0431 240.8428 117.8035 252.9024]
+/Subtype /Link
+/A << /S /GoTo /D (lwresd) >>
+>> endobj
+1166 0 obj <<
+/D [1164 0 R /XYZ 85.0394 794.5015 null]
+>> endobj
+326 0 obj <<
+/D [1164 0 R /XYZ 85.0394 451.0558 null]
+>> endobj
+1167 0 obj <<
+/D [1164 0 R /XYZ 85.0394 423.9067 null]
+>> endobj
+330 0 obj <<
+/D [1164 0 R /XYZ 85.0394 301.4703 null]
+>> endobj
+1168 0 obj <<
+/D [1164 0 R /XYZ 85.0394 271.3564 null]
+>> endobj
+1163 0 obj <<
+/Font << /F37 747 0 R /F21 658 0 R /F23 682 0 R /F39 863 0 R >>
+/ProcSet [ /PDF /Text ]
+>> endobj
+1173 0 obj <<
+/Length 1216      
+/Filter /FlateDecode
+>>
+stream
+xÚ¥XKsÛ6¾ëWðh€‚o²99Žœ:Ó8­¢œ�"A	c’`ЖÛô¿@Š”Õš’G£Ás?ì~X,°´-$¶å0ˆ�Ø
+cúÈö­¤˜ k-Ç>Nl3´“@Öûùä—7´bN`ͳVQÙÖ<]\Ð�—
]\¹»¹ýømvuzóÛ/w—ÀñÑÅÍíïS]û8»úüùjv	ìÈ·/®»úc>�é¡À`¼¿½û {b]üèlz3�Mﮧ—÷óO“é¼³¥o¯�\eÈ�ÉâY©4ûÓA7Ž|ëI6´ãرŠ‰ç»Ð÷\·íÉ'_'v€½Ñ�èQþl7pŽèØ–mÃØ÷�
ƒ~×q;mW²‚º(0¤æÚʯR�Rþj\¸V&Ë�‰{;ƒ,à†RMï;�@"–¸ º¶¨X-t•VKո׭¿uñùH×À2§ÜüìäpšÖ¯à-ȳ®ÉÊ}nëÚ;3	BhÆþy§m’%�ò"è»N¼§ÉAÓò!§¤‚²R÷à2Õ•o¯I·Ö€?LJ~ä‡þôD·7Q²ìzq Ô<E�Ñ
ç9{ÒՌզO	+ŠVNŒ’,ÓåÀÁt¹"º$˜ÓüY×NŒ+ÓS4¹ UnærѬ¬å9~4£±’pxŒeКÜ
+VfGV	èA«�r»œüz81‚~J–¥
nh{õÍ!”r–ãÂXÅ-Ðm‘œ·Ð3¥£ì|º×XrQÓrmÎÔýµÒv_zøØÇ‚¶õ¿òƒÕ9©åš€¦ýæ’¦ãRZ“D°ÚĆ
+‹ÍRé0ByGÀi⃕w›¶©O—»µY�©a^×G*®¥7ý€¸Üï‚j	<†»'2š“Ó-H›¢/:P¿ …:;2ÎÑ„Ÿ¹|EÓ3%å~7ÒËËõ™Ú¿Yu6ÁEw>¾dõ²d#
+srÆI/9'	 %^ågœ#þˆsšb1–Ác9còÙ™’þeg‘®ŒËdÃêþèxó
+°’!Umô‘ÎÐ'	©„Œ�•|¤gDV?á:=Ì€”Ç<9£u›©TfLüÓÈ]"f²¬Å)™”YF¦JízmÂ4âÖ—!CÆ�ä
è·5Ü?@½!äž½[ËIåÏ\ËË€ q¶÷3F°´j5NŽ}p}¨òø#	<ê¢7.ØKñd^EÎþK@?qpB™ÇDÄ(¥,ñœš·ß^ªþ/#„¹rendstream
+endobj
+1172 0 obj <<
+/Type /Page
+/Contents 1173 0 R
+/Resources 1171 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 1145 0 R
+>> endobj
+1174 0 obj <<
+/D [1172 0 R /XYZ 56.6929 794.5015 null]
+>> endobj
+334 0 obj <<
+/D [1172 0 R /XYZ 56.6929 769.5949 null]
+>> endobj
+1175 0 obj <<
+/D [1172 0 R /XYZ 56.6929 752.2028 null]
+>> endobj
+338 0 obj <<
+/D [1172 0 R /XYZ 56.6929 693.9224 null]
+>> endobj
+1176 0 obj <<
+/D [1172 0 R /XYZ 56.6929 663.1642 null]
+>> endobj
+342 0 obj <<
+/D [1172 0 R /XYZ 56.6929 628.9495 null]
+>> endobj
+1177 0 obj <<
+/D [1172 0 R /XYZ 56.6929 601.0964 null]
+>> endobj
+1171 0 obj <<
+/Font << /F37 747 0 R /F21 658 0 R /F39 863 0 R /F23 682 0 R >>
+/ProcSet [ /PDF /Text ]
+>> endobj
+1180 0 obj <<
+/Length 1186      
+/Filter /FlateDecode
+>>
+stream
+xÚÕYËrÛ6Ýë+¸´:O’˜¬WN�iœVUWªGC“�Ìš"‚’í4ù÷Bâ[¢lR�Ìt¼òž{îÁp
cé?lØ"*˜a	9ÂÜpç=dÌô»=œ}ò�@õ«÷£ÞÏ×Ô2&1�Ñ´‚eCdÛØyã‹«_/
†}@8º0ap]¼¿¹ý%íéÏÕçÛë›
/û»Ý|¾M»‡ƒëÁpp{5èls¬íI†°Çàúæ·AÚú0¼üôérØ¿}ì
FE,Õx1¢ë@¾ôÆwÈðtØ{RasãI? ˆ… ƼÇ8…œQš÷½?{€•·Ó&ý8µ!·‰Õ$ ¨ˆ‘
–aq
MJèFÁq˜]¸Ò}¡3—*íøq”¶æŽJdœ¶¿¥?*pV²ÖKµˆB%c¼ÖÆ Šµ
+¦Q¬SÕ+òébdÈi²>ªÇCueõ&RùêdÁߎûøòtc¿Š|¬Xz°ˆâ¤NvÝÓu€RDótˆë¯eòÌ—@ÙZ´˜”w'“¦p«ƒ9»çZÀéÚ¡¢eìî,ÍeË_°ÉÚK¾.¯ñ°% %×°Ðb”oPJ_e~*/Š­`Ó‚Ô"¬‘NbÕy%òÌ7ÖõŽÅpæ›íóÍJßUݾeL‡œÚœ­©¨­” d6c”¨V'˜	Ȩ0O(H
+e!¶i½kO­š:EÞ6g�¹«™° 1é0‚)#];SýÔ8f?F¬=ÙCZe�ù?Èž®Ó©möÔÆjî<åHü¹Ôemú&\ÎïeÜbíÚ…ˆ–É1¾´£�_‡èN#qÀ
|æ[Xkˬ–ZÉöö5öJƾd5d\”O­ýWì}©;Ûû4ÀRvä^¨®‹3½ùmgzJ ?xÚ:•Î�ð%ëW�N¹;µÉL:EZضJÜl»Ð±†�EÎUÚÞå;îê
+Ë2›£ñN¡r׸"l­Þ¯ñ¬m)¯l!´aÕªRe‡Q%ˆBB-±ç“€N²VÐÎ +AÌùž3Â×7¥%Cl!óLt‰1³I#Ý¥Ò“vŸ¼oœ�jc”ß�'ç%_ªÜ(ôT¥æ‰“!´š6eQÛ(?nÚXR&ÄÛ,ßž4å<äÁC²¹clœ4*jºTÑ€%Ë·�°�Öê•ï-ëÿyƒ š
å•Ôÿè!	õÞXš¯[µ�n›{³HW�»–­³×sçû©äûy+ãzU‘8îã1ÞÝ@:¡Î6—�ñÊ	öéßt¯N9\_†7Ü‚£¢ =úνü‡Ós߶Iq�Nhå:�"ÚDX9©uŒŒn3/.çw©ÿÏ@wJendstream
+endobj
+1179 0 obj <<
+/Type /Page
+/Contents 1180 0 R
+/Resources 1178 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 1182 0 R
+>> endobj
+1181 0 obj <<
+/D [1179 0 R /XYZ 85.0394 794.5015 null]
+>> endobj
+1178 0 obj <<
+/Font << /F37 747 0 R /F39 863 0 R /F23 682 0 R >>
+/ProcSet [ /PDF /Text ]
+>> endobj
+1185 0 obj <<
+/Length 1615      
+/Filter /FlateDecode
+>>
+stream
+xÚ¥]sÓ8ð=¿"oçÎ`!ùÛÃS�–+s”»žJ§§ØJâÁ±Œ¤ôëà¿ßÊ’;1%	ɃV«Õîj?%“1†?‡ŠR/Çi€BLÂq¶áñÖÞ�ˆ¥q["·Kõz2zyîÇ㥑�'³¯á$!ãI~íDÈC'À
;o>^ž_¼û|uzÎäâãå‰ë…Ø9¿øëÌ@ï®N?|8½:qIçÍŸ§OήÌRdy¼¾¸|k0©~ÂôêìüìêìòÍÙÉÍäýèl²>K÷¼ûú ßF×7xœÃ±ß�0òÓ$ßÃ#’¦Þx9
+B…�ï·˜rôiôÏšagµÙ:h?‚‘çGÞ�
ÓŽ
Œ"¬â0E‘ïù�
¯OÜcgÁ¨PSF•[TŠ‰;Z|µZN™xe&7ú¸ Ó%¥aèu4Ûf4cÇ2�ŠªBª"“p ]Š×¼äóG3ûÏ4Ï“òvIU¶¸-A‚Áÿ¸yõœ2\¨
ío±B2år‘3ÑãÖ`neÍ23·¼~v!ÔÚ¡;üxõŒYJºd®R‡úcIÜ*£ÙâØÍìíé+‹¹Î/òB=†BÏ"ÏjQT®à\ɵ_Iˆâ‡™ôÈä-·NnïµàwE>Ècé‚}[1©ŽÜ­„NâL¸Tº²†|<ö�ñØ"~áªbÉŽó
+mˆH‚Ò4��XÓ´ì2ó�“Nv”ó}.ðÒ@«ÚŒó’Ouþkxs,˜(®ÇÀ™2»A²Ü@ÓG3ê7&2àdQØm[—Ôë®H…•ÓÔzeÌx&µÚ^ß3º¨úQäP=Ĥ‚¶í|%¨±®^Ó˜’éÇD˜:3ƒTÈ8’8ÌlÔÊi4Å€a£%iJ~mÙ@œl[öðNC𲑵6¢8-yöÕ€÷…¾1i
+Ájp†ÖÀ೬
¯…’6hq„’0Mû¶ÉÙŒ®Jt÷EY¨qWØÜüs´ó¨'(&$‚0÷	
+Á2Å¡þnINcIò¼ä–h@r×{+Øë‹ÖYãú^èÜsñz›™€BM@
%ŽÖ«Áò™U»ÇÖè8pô÷ˆúÓÊ’Vp7¡SÉË•²´úz©kžv±˜íòÚ�R@š(µþ$û8ê»ÓxÐLÂù
$ ýÊ*ƒ¢ÒŒæ,%ð½k‰¸YQMjhsb}\BHs¤”XiŠ6r4ÐVMX‚¶g€%—Ê@�iÀxv�¯T½²KæP²�„˜¡92‰Óû\³Uõñr$VÕ@Ž…>ŠÓij9fº­niÊKÜžSCƒçô¯©
š€Ñõ˜U\@ßZ
+}–C6{	6ÞÔKëhä
¦mÓØSDS7�öß
Cø‘� µE

+endobj
+1184 0 obj <<
+/Type /Page
+/Contents 1185 0 R
+/Resources 1183 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 1182 0 R
+>> endobj
+1186 0 obj <<
+/D [1184 0 R /XYZ 56.6929 794.5015 null]
+>> endobj
+346 0 obj <<
+/D [1184 0 R /XYZ 56.6929 215.7523 null]
+>> endobj
+1187 0 obj <<
+/D [1184 0 R /XYZ 56.6929 183.9675 null]
+>> endobj
+1183 0 obj <<
+/Font << /F37 747 0 R /F39 863 0 R /F21 658 0 R /F23 682 0 R >>
+/ProcSet [ /PDF /Text ]
+>> endobj
+1190 0 obj <<
+/Length 3744      
+/Filter /FlateDecode
+>>
+stream
+xÚ½]sã¶ñÝ¿Âo¥'�ø"�ÉSrçKœ6—ôΙN'É-Rç$R'Rçs}w±
+¥
[
+
+îæw%Ï2'‚¿�?Áñ3g\A¦eü,Kø«ËtEʵôª31¿	‰\¥…2¢�ºƒc>1g¤Y?ƒxöOM�».À¯8ÿμ …K„D˜ÊÆ‚Ô�5ß3��,s|ž[YæF8F÷�
+u[ÞºþBƒªyDG:#GpŽ9Óf,G öqqŽ&ø�ÉÿZŽP@Œ;.eƒLÃÔ¶ó¹Ì²ìmšÈ�POM4÷Æ„_1b¥>ÃOyžûh哾8e²›È’“¿ôòžÇHàlÄPêx
*r1bÄXç#FÀ:Šz�7›DÉˤ=ÒiqšB‰1m08¸˜7”ÛÔsñC½Ùlmži4yD¡¬A2ø·½\qÒk€ùð@ÐØ,8¹´žF6nXr½§fójn¢°¡.3`#­:ùf oR×­t&ͱîSê?™ô10á‡IjðÝ°n¤F™:@­Ú
¤|ظ‘•	Ìlº²rÿ	_ñØÚÊ
}qƒP'*­(½Ú:÷/Tš>©‹B„
+í;@¨W¬êÏÕ+Xyݹ×ά
+Ϥ:�¶Gš¡=�„r�OˆS–+òQ™årx~Úñ�®
+�¸Š~òRUåh»wô|¢TFMÛû�–”ùFH•{ö‘:“/ Zjƒ;NÛömµtf	\Ug�Êy”$£­®&úµ¦[Õ«ò°‚Ú�&
Ö§0SÄ¥ßtƒ¡”MEVä×R©*„ú3�8ž­õ|n¾¸ˆ?IMʘ;!YÊQr
Íëb:+0@×R° °sV‚>^©—¬$º`%Ë&<õ¶Ê¡
s^öçÌ%—àÅ�¹ÌEÀšacd0`'¹f|ֱ̌ÁhC£}�¡ÍÑ`b`0
+MèzÃBÀÈEk“l Tï	6�W ãÊÄV`àfÆê4OµÙ®µºÔ)Ï\†¯lrì$7s:
+·ËÎs°™&'°m÷ÎÚ©€ÌUä/eà1Öy;
X¶dnªsÖ	ºÀ ]¤°fˆ�+\¨UY>&~?ß4¤hV×1šé¹hV�û–ƒkeºŽÜ²îàî�ïlbÉVØn‚� †…(&
DäÙ‘\Pe×h=Ue™™ÌÝûÜW¾¼ÝQfÒ°û\î_íí+ÒwØ„—‹Yz<s	¸ñÎÙß”KI_«
+Ÿ"ò¿øaŒÃ
+ˆÞzêçËcH&Ñ»´áÒ` |Ï@¶g’I×ãÛvŸAi@ˆKÞuƒ›³{:Ócϲ´(„wEgÇUZpæ‘ì9|²¤;P<!ikÌŒÇN&¸×AS€À™ÁŸv­ºã©—tù ÏSiðˆqÔÎö	]Ý.7]ïà/éªîðà£Ø§ ?ë7y‘C
›¿Ð뎱ÎûÍ€esV<ýÃ:ýœ÷”*…Àž_æ `Í°0=¼b‚ó*òžøËj5<‡–xŒ£ŸPÞ€Õ±‚‡±+FóŸØ;ß7u˜ §¡’Òo%þˆ7Ïrµ5	ˆ@¶ŠðGš��-aRYĹKåž}çSžÙÊ‚e�ôA©äÛ†¡¤5ß˃TZþª
+=Êo.ñ¤Áïå¢x)qçB`‚ñ’bGXÛc�³š³šÍÓ,ƒ�»ÈBÀšáaܛˡ<ÊÕ˜	JÀOD‰
zF{ôî[÷
+7BªÜÓV¸€zèç×{’2Sc'}„Ä'9—ØJ™†Àš˜cGyE¯�·ÅwÇé‰áþCFéI.Îh"HšáˆXÏqµ”€¨áãAKD51mjáÜø~
+�üúæ—W÷¯¡–A¦rØ>�3ð¥C¦#�õ»-2ø §·uóÙåd!ŸÑ6;Ð7ï>Ы.úe·q´öeèÍ/1WÓ2(>;ÌÙØAD‘¤W”°wxè˜áºÇñÂ
+‡‘‹ªþÜ,Oã"ìc"¿L>`ÍÐg|f¥3`µ�̆èîÙÒýFG‰ÏÚ7vÏ@ùâóÁ!Ruh!#|3.а_r;ý*>wûf[î›�Ó
[�Ã
lЇÛ×.åÓ�›M+Ãn‡gd ÌöÒãIX®Ñx@=zzÚs);sjûÒ:V{Hf¼EfÑE½,º¨—ù‹z™-ck‡l/é¡9*ãïP!æÎ}XøûÅœBÛÈ‹X,ÜðÃÀk•
ÆX©Ì:æS€0ú°ì¯§uc˨°Fy<$Ã_ñFúët™K	,ùÆ1⟥g
É~íN胈cŸÍž\Ø„ÎhÉ<¶á6¶l܈Ò%^ø“¼"
+Ë0^ãîáì–µþ².ý`ëVQÐB›\Cq’e¾
Ü£o¼Ïåæà(ͦ9BPQjå»0°?¯Ü%‚™4G§Rú¬Ëíi,S©‘r’Å¡è€>ÈŒö•Kã¥
£ñí„P›¶ê¶£Îß«HéúçýüÅ8Ž¡Žç£K‘ß™,£ÈR®ë„
Ô†ò£­Þ`X»‹žË�~WR‹22ƒ-¬|RŽ7m34Þñ.»wéñ@šE@w¸‹ž}{º®õ~8ìœ7o¶á6g5NäÀN»ãIyÔ¢î=ÞljÝÇ		‰ÎTþ¡Ë™âõæÿnOÿç[ÔÇ+æxoPë3EŽÈòTsSx¦P¨RM9WB§Jób†õŸ¶›‰endstream
+endobj
+1189 0 obj <<
+/Type /Page
+/Contents 1190 0 R
+/Resources 1188 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 1182 0 R
+/Annots [ 1192 0 R ]
+>> endobj
+1192 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [250.9056 208.6872 324.559 218.0968]
+/Subtype /Link
+/A << /S /GoTo /D (statsfile) >>
+>> endobj
+1191 0 obj <<
+/D [1189 0 R /XYZ 85.0394 794.5015 null]
+>> endobj
+1188 0 obj <<
+/Font << /F37 747 0 R /F21 658 0 R /F23 682 0 R /F47 879 0 R /F39 863 0 R >>
+/ProcSet [ /PDF /Text ]
+>> endobj
+1196 0 obj <<
+/Length 3362      
+/Filter /FlateDecode
+>>
+stream
+xÚ¥]sÛÈíÝ¿ÂsOòLÄrÉår9yrbçêëÅnm§íÍÝ=PâJâ„"u"e'×é/°À®H™’“i2c‚K‹Å7@‰óþ‹óD*‹²ó4“AŠä|¾>Ï—ðìÇ3Á8S‡4íc½{<ûˇ8=Ï‚LEêüqÑ£¥ƒPkqþXü:QA\
+Bë¾nA¿…IxIÍ––.á,Z}.«ŠÖgLȬËÎSš™¼'ô„6°Ó±²°‹eÍÛ:^ò¢(§('ÔN�Å)
+@€r:NW6u^‘1µfŽ·tÓ,èšÓå��Ù~%�˜h7MÝ0×X„“G»<+Ì"ßUÝ”-]놺†®"±°üã5“fi
„Òº½»½Fñ/Œ›-He*FŸ6³>Öq3óX(•mÓtÓÂTf™£D¦M]}}alID±ˆOsá±FØ[’‘ˆÔ��Ç‹,œì¶ ’XƒJìU€
ˆIÍÆ07kSw´Ž*C¼CÆíbÉD¾j	EÜ5Z®Ì“©øõf�—uK†‰y]ÐvG
ÙSJÄÞž(þÙÔ†Õþ\v+§_¶©MßÜÌ—yµ+Xßè3VÏ 6ˆ‹W3"xÛtŒÒ6k†è–²÷ˆ¾�íÀûZ)8³2Á’Íö·(’W×ø÷
?ðç‹,šüó`ñÓþu§)ö>~z¸þô!o©�-²žfá<q„R’Ñ€}†“ÿØË4ÐQ˜sÔíK^nDÁ^~(Ìo¬ž<¸k=¸Þµf·v·ÿ}Ë1a¸5‰œŽ9\’bHÒÓ×Ç:îp·,Ê6ŸUfšWËfv³n_¸›Œ©Âä4k„‰�»ÁÁ¥zÈÅq
ÚU’C¨Šû‘žž\Ý><\¿§‡=†í³¼ã«5@˜™ªy~�b�¯m(…rà#„O±Uh	|cS²²�T…
+„„¤žç�´¢D»WÚ.ïl,󬼂C˜‚ÝæλSçâþºiÙ÷üÙæ.
+Tìï3Gl³©J$vÌÈbL·ê•â¡�uÂÈ–•JÝBŠ›VMó9oËâeùË 
3}š�5ÂÂÀÄâxbÈÿVƒ’Ò�m»7#Š”*€RË+r„åC5†�Òšñ)³6O€ÚÒ6ltzò”We‘w¶ö€[ŽÎ
+œŒ‘J6¦’­bV?Ð3�’…iFBL¬ý	ÛಷÙW¸Vžn{ÄlS[™´åº¬ò­-Ù�|sàÏ9?qï?—SÑ*áF¬Ù‡mÇ€m%ï!"
w0òµ)†µ»‹â{û9È!ÁiôZ ïcä«çTk4Ç™™¼Û¾Œæ	Ò@æ4k„�A4W2HÒ42ò€Qc�>¥“Ui¶”5ç
+MöIÎ$¨‚íaØ£¹D9+YÖV+»ÎÀ
+_†žO54áéAhÓµHê~
+�B^K@_ÍX± Rh#ÝRdÿtD–X‡.$EˆJV„òùÜl:†ëöÙl[ºA·Ä+Pr¨î¸"S½ãÔc�²%q ³ÌEкãŸepŒ®»àŠp/¸Z‘FÔ—¡:(ɨ¢AßÎ$ÕJe½Ä»x²°¡–¡£êéÒ":A žõuXœ¹‡Vb¶äJ¥ ñ¥#"ú$0Y¢92»º0Ì@>’«ãÂÖ:ôÃÝK&8ó"„s�T¡"Ð*‘ßU¼$!x½ÀÒ¯ç]ùd‚‘­¦"GÔz—Qf~‡µ0¨/„>ç]ÓTƵŸwÜz	Wqœa¿ÒÜô±Ž‡+�eÍc×­¦õÖÔ‹™|”‰'·÷X#û‹N
öÉ!£^“i,³ïsú8ì4q¨]ÅpXÀBE(SÁ/]^ŽÑÕA¢„C™¹œì+·
+Ã6'áf
j·ÿ¾ºûxysÛÏ|4‹j™AóäªC—ô9�bͽ}2[¿—;"ˆR}Ð~S$ÖZà\ú+ß�*±£‚*9'ËœJˆ¾4ÿ‚çûù—Ö¼Ã�ØDåT'êÛƒÕ['m›–awÍé2_åõÒЖªÿ×ô„§È
+
+É0=½­CÙ¶o
™@zb¸í±¡×Ý'í•H"ô%RÆâCDí"i*·S£ÐŠè�›ãZKK�ñÞÕzýàâØÙÚ–{™q·P%-¸\Ä`Lñ­u¤i�.W˜5Ú…5±$N441ÖÈ4N’IUÖŸ1cèÈ鸊}¡l•@—I;î–«Ž¸÷q$€W`q�(<óÂw C,Ë„­
g–íÖCbQ¦;KP;/>²m<+JK?– °ên¬£3Œ3GEÄÂÖ�Ü°dKL¸’tíŠýÜbÑm.àüM=‡=¶Ü«
+@ßÃ:¦ƒÐ
+ÝC"�op`‰&«fc;Êüp[ì¶ûÜ×5Ës8§�r�b™÷¼j9ˆ¶»
ñ‚zØU™†ª#=h$öŸ8Üç7Äüø`ö›X{š ¶¼g�¯}�i¥T¤©þöâ„[Í(M œŒ#÷í†3Ñè¤:ƒj]g~RíbäÁ6qh™¹ÎÀ‡þLs1�Ñ€$K¶]€ëp°6Çqða%Ñ�@c·ÉSižG8‰’@„:éÙÇè¡tìË«ŸBPè0}1pCjr¼º‘
°?Ï[>™­Ž2íRàùk
”TX*¾ñø·o?˪™yóﳞ…T¦ß �Xé¡>Xù"D](ßÎÈtÂá
+ÿðÀ}Ýñ…�·Þ¬_¬ƒôiÜ%³=Þ>�åºbq_|5uÝÿ]�+N]g?ŒP¾pñ�TÞö[ƒÃÜçüœÂûµöû¸eÅ
f{Þ¨€iªÊUųѴ…Vœ†‘�‹ŠaÄIÂ@(õj¨ˆ“ÔÍH0†M�Ò“Y%Þ7]¬Í`©õð;¹íì”ËM
+}Š ífû·0Ûª„p@Ó9 ÂüaO
óÛÁ´¼ÜU9¿…_Ê÷œa-eñºâ“?´+úÅ˜Žé}Á{®Ø’Uj¥B£Wåf£
+endobj
+1195 0 obj <<
+/Type /Page
+/Contents 1196 0 R
+/Resources 1194 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 1182 0 R
+>> endobj
+1197 0 obj <<
+/D [1195 0 R /XYZ 56.6929 794.5015 null]
+>> endobj
+350 0 obj <<
+/D [1195 0 R /XYZ 56.6929 387.6589 null]
+>> endobj
+1005 0 obj <<
+/D [1195 0 R /XYZ 56.6929 362.5676 null]
+>> endobj
+1194 0 obj <<
+/Font << /F37 747 0 R /F21 658 0 R /F23 682 0 R /F39 863 0 R /F48 885 0 R >>
+/ProcSet [ /PDF /Text ]
+>> endobj
+1200 0 obj <<
+/Length 3390      
+/Filter /FlateDecode
+>>
+stream
+xÚÍ]sã¶ñÝ¿Bo•gŽ>Iàñrñ]�éùŸ3�4ÍO¢,62鈔}î¯ï. H‘’®i:½ñx´\,€Åb¿I1ãð'fÖ0®œžeN3Ã…™-.øìÆÞ]ˆ@“D¢¤OõíÝÅ7oU6sÌ¥2�Ý­zkYÆ­³»åÏó7~ý×»«ÛËD>OÙebR>ÿöúæ;Â8úyóáæíõ»o__fz~wýá†Ð·Wo¯n¯nÞ\]&Â
óeXáÈ„·×¹"èÝíë÷ï_ß^þr÷ýÅÕ]w–þyWx�ß.~þ…Ï–pìï/8SΚÙ3<p&œ“³‡m3Z©ˆÙ\|¼ø¡[°7ê§NÉÏ(ËŒ•Ù„
+ã†îæ÷ÍŠŒð½6å€æqX+€qÆp©¤;T’º”¥ÚsfÒ2™Á:çdœ(õe™ov�$½‡z‰¦eµ9-iÅ…"EJP“ŽP‰Le#ª½Këßx`¦$7³þ	þ;© üµÈôÿFÐV³Ô)µ´˜tj=à‚;�°
+

+«çK§á¶¼äa¬~l˺¢Ñ¢ÂraIMù°Ûä-]<ûÊ©êOM½)ü½ú»›�Ð!=EûòF¯øñêöRÙŸ.…p
~ÌÜ…Y1´ÄA‘XAå¿
uLk˜Þzþ92YWGïVƒ1hËõé»íS¿ÛŽÊßmÑ.ÖÉýfWŒ¯–ÃÔÔžÞ»£šØ|pµÊ€áõO‚»ßÑ
¦vƒi6ïpáŽ@à*U¤€‚ÈNö0 öÔVÅFï€IÊù‘*|e°cäç,ò]ã5ö �
®(•ý]"²¦ß¼m‹‡Ç–"ÒïH*
hf•êñ"�
SSï<°`µÿÅ.
+ñOË
'ó7®”
+Í0YhþPD%Å�âsÙ64´Ü„ºU”O^9pìãõ»»«Û÷¯ˆ œ�†ê°Ò²;`€ëSy%‡‚Rm9låÕK˜Eµì"%Ê� çmÙ
Z¶à ?
jßN—Æ1Ó÷GT·üü…:a¡0ÖbŸ_MTãA«Ï„ZÈe˜æ©;­^}ªãúÕQùÞ\§Ø,“Ŧ,ªv”îApdS�“tTkR8­CȘU–v>áç< ËK1¯À9Mj}·ñ�›â
˜ö�nD„™dÊaÜÖ<½]$‰kÞWuç!ñ	6y9œî@[Rkçw—T“tOgŒLÈûî(tÜ÷-Q`³³Z¡ÁZt)=ƒË›P6HߵË9P±Š=%t¯´žP±Œ9%㚘Êp9o‹VëC–Ûç:¶ƒómÞ4Ýˤuh컊¨¿ù®]'Õçeý�—S
a-'‡â›f[Bå';»ëº¾ÃíDÑ,FÑíj!·	&RbJX²}Ò5ˆßÄ.r	‘­È—Ç�RÂNžñù}ªF©ü½×M›4-dhM[.ÆF©ÁŒlªO3ÐQMp04JtòY6dÁç>Fôâ¢O‚�ˆI0@”ø†ÐøkQ<·+(žÃoïžhUoÃÔ'J{
ÄË¡ð¾ÅGa1a©˜

ì_#ä²°IɸÙÁÛ’²]oˤ�Ëðˆjý�Þ6ä'øêàLFܧ:~ÛrŠ¶ÒÂR~¦Vvò)oÆÙ1˜ºKõi6"ј
�
<‚‚ÜØð“*½Ï�
&œÚ×/¹¬e&㮋aP?‹ùuKó½G d¸¸dX:J
+,ÚÃ'´ð¸„}¶%…n�É&(Ä–rúi·yÕ€
+€ßîXÝÔ÷¤ÂHäHh„çDPUŸADúÀuµ x€Úá“U@þ�’Í1ð9î¸62íÏq%
+V‹!׫	á9È9múaÝöºÉÐqzc0±Bètl[&TW
‘kz^V(7šA¯øõ
ãšèH{Ëå»ð.ßiûî WÑ®kHÊqeHõ©SbX2b)A%£±dl¨|´ˆ‹[„&ø·]¹¯�ßxìÞÛzšMqï;!^õ•
³Âg_çõ@Vø†ŒMÙä¾}È_ºPC�»§®ÓWÄúd»Â^_µˆ–º: —üÌÙre 8ìAq£ÿ€šC€_ÙÓfק:nv•7;8B	‘8Yø
+réSNšÓtT›¦LeÊY7æz�<€)B¸4Æ*@•a(¸z€,‘x]‡Ç|³ñ­é'd¿ž*ä/€�ô±‡b:1å››×ï¯ÈX JÒø.i`,cƒ“Š¸“rþTÖÔÏ#´×(@“F
‚Ú�€�„¬Zæa
o]Š£àuÂÕs>Ø(ß<ç/M\c[R†#EµªC7©9Øu$~x;ßu™ã§º]Ó±‡ïÐ|�‚[v¤]»fù’-!Z=‚�ÀÚþ˜"+É2ÇÏô©ûT'9R
ßxôW
+ÈN”Vÿž†·÷3nû÷é“þ„‰{­‹|}Œ]MäM31jÓ)Žß)Ù
7ã>]¤:ÃÃxµ�€ëÔRÐ@6zÆ{!‡Â…qJ½q¸]wCx;
=l ˆó­ (Ãé:J¼Ú?…Õ½Âp5òV”–—N«Çæòç…ÏÉ¡‰íEÝy
„÷mF�ÝÛª-Ñ/x–ƒ©?¼&à½wAô6˨ޘ�Ta¾?<üúâ~»†ºÃì4N�Ò‚|ÓÔÉѯ" —Èt¨)±
+endobj
+1199 0 obj <<
+/Type /Page
+/Contents 1200 0 R
+/Resources 1198 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 1182 0 R
+/Annots [ 1204 0 R ]
+>> endobj
+1204 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [182.6146 117.0296 231.8861 129.0892]
+/Subtype /Link
+/A << /S /GoTo /D (notify) >>
+>> endobj
+1201 0 obj <<
+/D [1199 0 R /XYZ 85.0394 794.5015 null]
+>> endobj
+1202 0 obj <<
+/D [1199 0 R /XYZ 85.0394 720.9574 null]
+>> endobj
+1203 0 obj <<
+/D [1199 0 R /XYZ 85.0394 709.0022 null]
+>> endobj
+1198 0 obj <<
+/Font << /F37 747 0 R /F23 682 0 R /F48 885 0 R /F21 658 0 R /F47 879 0 R >>
+/ProcSet [ /PDF /Text ]
+>> endobj
+1207 0 obj <<
+/Length 3814      
+/Filter /FlateDecode
+>>
+stream
+xÚ­]sÛ6òÝ¿BoGÏD,@$0÷ä&NÎ�‹sç¸s½iû@K”Í	Eª"Õ÷ëo» H‘’Òiã™
+òÛÕÏ¿ŠÙ–ýÕ•5z¶‡"”ÖF³õU¬U¨c¥üHyõùêßÂÞ¬ûtrÿ¤#•D©Þjkõ,Õ6LLá>¾ä¸
+
²jOˆ*ÁÌ{@$¨rJÓinóÅnÛà*ŽÈZ*¥gÉz˜1ÙþñH‡‘‰dïVtŽ±é
ÚPá•ã6l|Ô2
­ŠÀý «pŸ-t°‘Á»ûÏôû·]îκ[<Àš¶!(áÕ3&ΊàQL]§É· Àôɾ(K¦Ô‚”mZvòƒKn3‚’$ûzû…Ž]£9JÍðà=sup5"&´BÁòš½ã
+S)†´i0Û¡ìV
+ýeíä¦Aëøƒ’PgËWšùRÕû#®˜U0ê°¡‘T¨
¸lá×KÞ…÷12Ì-+üÎúÃ+0Ù
+îë–©´/™#‘ÂFµmQ=O˜1pBo‹¶½c
+&�$HiÊH«#ÛQ
+¿êM¾ÍZ2+‘²A³÷8¡Ž"Ä=÷ŸïÞÿ—úÙrɲΓe]ÙmÜ‚¤>ç9Ãa
+öb^,盺.G†Q@Ø R=ë£F5¦§5„Å…È?RšúÝ¥9¤ë4öÔÔeÞN¹ضX'¦Gɉ@Vî³×Æ÷Ëz
yÿôa;tïÞñX/€À¨Á­9é²â8¼t, 3§Â@>Ožc’Y@±hFæß$2=K½“ú+P³>ùyS:ùGó¦Ä§'º—ãè.ljƒE]–ü ˆ_²‹q`€c;‹¡ µœöh·G
áøEh±«J
+f�/R
+ækº¾™‚>y¡ØƒíJ�°…‹‰E÷Ûð*�9ÄØÖmZF<ŽôQiÁU:td¬t¸ÝÖ	X˜i˜C€öiLµ\Ð×HtJºbƶs]ôjã‹BøËP\îÖƒ}Zs¯¦9G@ù(s,a‘ÄnJ¾CŸ*!E­�¶·´AsÆ7‘|�¿KtßR©.ÂNº{*$‰…EßàüÍmŸÙ»>|˜ˆúð§+ˆ¦‹ƒÙÅz¬„°ÍŒŽVà©Á±õ)Œ-Ž‡ºÀÈÛd`æͧJÁÁ$ZŸ·±}¨ÓF¶ƒê\ßï`ó�‹RÕÈœ'ì�Æ„^Ï&XÚ”CÂäôTz¨ía¿;íôl*Ùwz‰M]MF¼Ö;BPå®8›R�ÛeÑdO(ìøãî§÷Ã錚M¶IÞ•Ù–‚�
çðCw#;Þ`uVJøÅhY_0 
+0œq{ÿH­[´ï>}¦ÎÚ]ñÐ¥ 	îÜ‹PØ7Ô>ÕX&Çs	½Sç/S*@~ãùWS� JN£Þùûå,ýz¾ã%èSl€©´Kh¿U
+‡+éKá_´'¶1�õq™¡Ê÷eQù:^Öïq½o±È7pÒoüÃòÈ)MU‹çªæûñÓ¶œc¢ÕSz
+vj»8×ÈÃû�²¥–˜€MÝ4…++âpþû&¯žrG5b#ê¬ôÄ1xÍåw)uéì)”Ã?¯D­DÁÚMÞ©ÝÕ‘`�bÙÕ
+¿ˆ£·L80zÊ‚ƒèEnøZŸnày;üÅ:u¼õ‘ÀÌþRm°€SÈ•ñÕ÷D
+endobj
+1206 0 obj <<
+/Type /Page
+/Contents 1207 0 R
+/Resources 1205 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 1182 0 R
+/Annots [ 1209 0 R 1210 0 R 1211 0 R 1212 0 R 1213 0 R ]
+>> endobj
+1209 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [80.6033 407.9328 154.2566 417.1482]
+/Subtype /Link
+/A << /S /GoTo /D (statsfile) >>
+>> endobj
+1210 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [265.4578 363.0047 326.6578 375.0643]
+/Subtype /Link
+/A << /S /GoTo /D (server_statement_definition_and_usage) >>
+>> endobj
+1211 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [367.5441 363.0047 416.2908 375.0643]
+/Subtype /Link
+/A << /S /GoTo /D (incremental_zone_transfers) >>
+>> endobj
+1212 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [280.9692 332.6817 342.1692 344.7414]
+/Subtype /Link
+/A << /S /GoTo /D (server_statement_definition_and_usage) >>
+>> endobj
+1213 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [277.6219 302.3588 338.8219 314.4184]
+/Subtype /Link
+/A << /S /GoTo /D (server_statement_definition_and_usage) >>
+>> endobj
+1208 0 obj <<
+/D [1206 0 R /XYZ 56.6929 794.5015 null]
+>> endobj
+1205 0 obj <<
+/Font << /F37 747 0 R /F23 682 0 R /F21 658 0 R /F48 885 0 R /F62 995 0 R /F47 879 0 R /F14 685 0 R /F39 863 0 R >>
+/XObject << /Im2 984 0 R >>
+/ProcSet [ /PDF /Text ]
+>> endobj
+1217 0 obj <<
+/Length 3673      
+/Filter /FlateDecode
+>>
+stream
+xÚ­Ërã6òî¯ðmåª!
ðuœL<Y§’ÉìØS9$9ÐdqM‘
+Ö8_¿ÝèHJ”&³»¥�Fh4ú
…×
üÂë4�Êôu’iat½Ú]×O0öÃUÈ8K‡´c}÷põí;•\g"‹e|ý°­•Š MÃë‡õo‹·ÿ|óááöãÍRFÁ"7Ë(ßݽÿž }ÞþòþÝÝŸ>¾¹Iôâáî—÷þxûîöãíû··7Ë0�B˜/y…3ÞÝýtK­>¾ùùç7oþxøñêöÁŸe|Þ0Px�?¯~û#¸^ñ¼
+„ÊÒèú
+%Ò$Ô^‡Pàyõ¼l݆{³*6¯,¯3»@3á%³ê›XL‹Ìn¥"�‹Ÿ*. ¯rËlÜ’®`^ÊF(žªÚ« ñ�)Eæ%É”‹ƒúX¡YS£¬ŸBŸCÞTxBÛÙ™¶ÍŸÌ¬0Ý_â†NEÆm�ù妩wËU¾²çÒòÌm„‰ã0tÓW]Ÿ—V³`ÆHeµSChË QoŽF&»uŒT¹åH15+&2é¦åcG"KŽ4‘VÅȺú¹ß£EÙâå¡$/Ø:lÑ~â bZ¦"¸ßÐhgXFïV1Vè)Ú!*xõ¾e ÐO\›¶ 
X3ÞlÙÉ•[N©æÔïÜKZdOà,
+#´ª‚¯º
+D„€–ñ,d<‹›¹ˆŽDèúm?/a¿n�ÿÉÉõTùŽ}Š' Eë<PµdªPõ^Œ= üÙ›¦p¾�î 9Ïâ5ѱåÎ…µ¼Ÿói�¦¬Þý1M{ó™Zöà¸bõ:¢n=Çt´ÞhUjÍ·’
lÒìønåȘcí�Ó÷w)u¿?�Á^3zcš&/
¡¡µ8JÒâÐêš·eM+1cÜéè†Vlë�™;TÝ¡˜€¨I
+¨¹g¯RuÔ·«8lj
¼–Wjâ% ìëdq_T+s„éTN²HKâ|§¼
+yèÑÈñHÈú–†˜œ”ïRaDS®ú2¶´�}bG¶Ębje¬~&ëö<
+¯9Tw2rœ3g+ë§'kÎ4Wð´«àéȲñ-
ÿ
ŠMÅ+è¸;Á6›b9ã>¬ «m^=^b•ó�¼¾½œ]ÑuŽk«á»†l¢íˆþ|Çû H´41Ÿ5?>³<‰iýl,Óü3²Ë|‡!%Šb	É™rè�.êåLŽä¬ånMßG¼¦)4Õ
µQ~ׯ�+BÃõ¬#A±¢�UŠM4¶[fÌ~aZÎÝé¡XÛü1€Ô´£/‡ja>ïMe­x@	,ýÙrK&‚Þ~øÄ+TÙ™]mó6hƒwnû�ó§ûhg_¨¶¡ã2	Â
+}¯’a‚Uè™ûäèZ’ÞaÃëv¨î ©€%ýK®4Øp_šŽê
‘4®
+WsB[Y#HUG’°ñ”-“8}°U(ºW®0�ðÚÕ³:1“LÕš¾5¹æ,�h»‚1׈³„£ÊvfÃ(‘Œ\®Ãzqº°RBeq<òù3µfˆdâ^|ÈGÎD±��²&9ãà
Xn§GºÖ,Uˆ¡SšSrû°-¬q‡&Çë§D�-RBBozû_ÍØD¤‰d¢ÝíC¬]	DNÂvDD¬DÙ™,E&c·KÝÌñ8ié/ñ8?-X³=)ì1w±•È0gƒa™H§’är0<Æ:{,Ë�¾ìŠåÀ‡I쫤óizyw�5³ýô]-q„Óý¹ž¶Ã×sbIVaÖ^Bƒ*åØz­{ÂÙÚÀAöûÒõìYÚÉ«e›±Oþ¼©Þ鎒4ùò£ÖÜ*|—ÑáQÙÿȼ å)ت|µs‹Ñ˜Ê²ù"Ø
+„êoT9Ò¡Ê!ÓÄ–E×´—ÚRW“JÝËM’9•Úúm‘»	ýîÑÚ”êg¢‹ÿ±m¯
+¦’¾]�߀±ÕÀòÌŠô°RƤ¢YîÇ#§´ÛÜ2((\µæÚlr¸Xÿ&0SJ•HPò.½Ûñ
ÊyýBö&`V.ë×ë‚~9,+HÓŠ‹&§
+–	¦úòökfÿÉQ#�:H¦ÜV¤éâû÷÷÷·o±�u×=¸ØŽl@@{I‡Éhñ©rל²¦™?�fª�†Qø•â~Å‹oJSVí`—œ·µÿ9€~Ád®k‡�2Î/™àSTMÅn8È�ZPçkÄKk¡Ó8þŠs�•¯0
áˆÃì²|�±ÎË—ÇÉ×K^ë܆ÙÇ2GBÆIv™�5CÃô¸��:SS"œŒáK‡“1l�¨²ý‚¿NÌ¢T-Þ×�™ñ®¶”gŽ±'jtDWœˆ(ž“é…w‚в¥fW�ŸbØ·ðÀéå/áREMMü™"Ö~”>ŠHYÎ{ëæÿ'!MõÿÁÄ…Ó„Äù²Ž°.ˆ ÃÝ
¶KÈ‹†Þ6§u4ü÷C¤.“á±fè˜ÖÑ20:!ä�¥
+vÀ1´§Qj#W0…QƒØ™½Áe´±G9Ïß¹I+,îPG¹�ÏõG!/¾í‚ŒÒ¯ýï†a£:uÀ/}YŸ#óéŒû2wYW×å«çó�RpR…_¨ÐŽ�ΔCÂsÛg_Œ]ŽEò• ˆôÅm=Òé¾Ó¿ó"Kãd²1ÿa…ªH TÒÆ¿~ðK4±F×�¥&³úZ•Z´]Þø:G^Z{öã,Ä°ñN�ú€ðè!ø†NÆ9:ˆÆlP;Up
�ÿÆ¢ñ¡ö&\¬–·‚(jY5~ÈýÆ¿TVGo–îôôg '/ŒN×�b7;WSlñu²
+	×Ù1åþ¢§¤ÿðDÂendstream
+endobj
+1216 0 obj <<
+/Type /Page
+/Contents 1217 0 R
+/Resources 1215 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 1219 0 R
+>> endobj
+1218 0 obj <<
+/D [1216 0 R /XYZ 85.0394 794.5015 null]
+>> endobj
+1215 0 obj <<
+/Font << /F37 747 0 R /F39 863 0 R /F23 682 0 R /F21 658 0 R /F48 885 0 R >>
+/ProcSet [ /PDF /Text ]
+>> endobj
+1222 0 obj <<
+/Length 3453      
+/Filter /FlateDecode
+>>
+stream
+xÚÅZYs#7~÷¯ðÛÊUã/>*3žY'�Wvö¨$m©eu�Ôí¨[vœ_€
+˜âЊÈhÓXY«1+{.´òb�-¾L‹t›UÃ+
+@ßî°Â®é¦#]i˜§6ñ÷뼺€ÉÙIùTçe
eXOÛWÙ’(uI”Ý…J&YUïòEÍ-댚ët—.êlGô*«‰žK*T¯E�þF­åŠ;e»:ÍYì²ÜRÈ"¤M�–�%HD¬ƒ
+û*}„Át,')i“‚ëÉ
+�4%™ì]êÈLVÎœ@Þd�é†h벪9À±Åe¤oÑÁ‰R
ÁQÁ-ÙŽ­
•Žµ�oþá‘a�¸gÁŒÜd&‰V,”ß–Ë|ÚKÅf•Ú¯êÃ+ïNn((¾3bVÙ·É »ŒI›Øûyúô´qÉC+Ê·ZZ^Q ”/¦9¤yË)J£Hš]R}6›Q�&-ŸþMöTÎHøº¶ÑäºföMÅOkÁÚy�×¾—Ë|Ú–ñÄeré(æïi¯Ç?3jsÛ
+™<]Àš¶ºÝI•èP•˜U‰&·÷óQ�c.ò²Î×L|ø%ªY, ¡Aˆ˜Ë|‘ÖÎ¥sZsCMÜu±žR•F~†ÄÃoÊòËþ‰%¬ˆ–RÕ1¿œÖ%+†¢åÃ5C÷¾¾™ÎÞ¿Ÿ‹ÙüöÂjr/$ßFC’‹nnº¾¹Ç\$ ã£HZØÁMrDu¹Žƒ¨†«
³íoCÁÖŠ$”ÉiÁžiDpo—“€
+gbCñ¿}o"ÄZ–î*îQvWÍ@LNéçú–«Ë%cŒ£,§_hêä~C>EÃ&+
+P9@µ‰Eûtð:ŠYT l`lzÂ�^Qg,k_�¢ól¬54õ|ŃK-"Úþ¢“ј­öœTRúÁ´¦>¾R‰DñáÛá:¾ž«
ß¼¨³GXÝ×Ãø…ƒ¹OË÷L#òûñ+…N"ÓWà6Û�m�WIL¸ÎŸà„tI4ô*µZ:§zEM.îá×»¶{ÂUã,
m/åáPݧ=䄦»ùENþÉ!œˆ(‰!<„Vp8VÝ�ÏM˜
È��Žè¼3*Òù^!ì�‘+bÏÑÑ	O¯8–7ûŒzÈ"û-¯¸+¹´ÁÓkÔ�Dsˆ`:U&„guÂ
+¦Háˆqø±‰­�#8�U¬{@>‰hcò»›Ù§«;¾IQ&‚ÃGbú®zÔ™è’gÊÇFÄ‘6_‡ä�8•IPùÞírwª†«]°j÷|Ò«NË÷L#òG|Êô8âS&H¾Æ¥`U×¥¢„]*²Þ¥€ä]*6Þ¥€HwaIߥ [»DcùˆìWM3ùJ,‰|àW¡"çÿ·_è¦;íV-Ó	¯b¦ŽSÁYñöÁJ"”Ôú¤ì†éPxÿ
Å™˜°'ý_´ÞA4y"0F ?ˆ{ˆ+à
¹º¤6¾nƒ’‡ÉA“9€è'ãȼG
ÙáBeص]K`ßp"8F©äkpýñ5”ÐEFol8]®«è¹VÊvå´(§U™Nëzs¦µƒÐœV áÑ ¿”1l$QÜW�×RyøWïá`
Ç.·@M÷õÏqi�?ó}h�à�kjøº„$�Àèî5‘ðë>Û5÷«”6�Í_°Þßÿ@‚AþN8!êPX«Ñ‡N*oÚixŠ¿ßk
+üœõTp¢¤‹
+À…ý7B
+þ@’�Ò]r
+äÝ—ŠŠtµe
Ð�Û»»P¤Òë–X*~iâŸ8�Jfüc-–¸^P¨É²3ºcs—+Xl@‡ëôJÒY
+w¢[±
+�GF|‰”Ç�=¾¡-�†©lçÐV´Ž©Ä_Ò(Úø¢æ

+endobj
+1221 0 obj <<
+/Type /Page
+/Contents 1222 0 R
+/Resources 1220 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 1219 0 R
+>> endobj
+1223 0 obj <<
+/D [1221 0 R /XYZ 56.6929 794.5015 null]
+>> endobj
+354 0 obj <<
+/D [1221 0 R /XYZ 56.6929 183.6365 null]
+>> endobj
+1224 0 obj <<
+/D [1221 0 R /XYZ 56.6929 158.6249 null]
+>> endobj
+1220 0 obj <<
+/Font << /F37 747 0 R /F21 658 0 R /F23 682 0 R /F39 863 0 R >>
+/ProcSet [ /PDF /Text ]
+>> endobj
+1227 0 obj <<
+/Length 3161      
+/Filter /FlateDecode
+>>
+stream
+xÚ¥]sÛ6òÝ¿Bo•g*ß
+ò÷ÅñÙ
+ŽýÛg*ófö/œ‰,“³Í…6Š­T‚TŸ.þÕmØ›
K§äg”gÆK7!@©zÆÚΜɘU0…l8‘7ó¦Ø})v8Öó粪
+Ó[Uuý™f×õ®›¤A¾mž‹K1�ð²mŠj
¢ÔBϯ×($¸Ë¬ÇŠ†9é28
+j@P�8[®ñk’N±m	oh("kçA&0ù˜)†ç£x�“{>Þ’¼Kßè´cÎðä]¢µÑrô?á}îšvÂ/yɬWÍ£H�™ƒPñc\¿£ç¶niÐ;
ò8
W×4E1¶se=:9³”ÔM˜&w3ÜöL¾Ã_ôÛüñ¾Áæ‹%ªO
+¥’I5fHË 37`èÈótX¯°q¼²Á&®j¡ÀC;!ÀšåI™‘Ia™‚ðÍ9Ÿ¿ÛçÕ¢ióåg:ç
š‰¥�ØÂ3Ú¦¿N)KQãDCïtq½�SS
+Œºé¡®	¶‚À*G…�è%ë]K3¨þ®wŸûû×ûíŠÞŸB$EÐ}Ul"4P|Òvùò1¿/«M7[í#{)¦�̾ê„ŒÕmÿôxŠêIƒ¢„
âøúã=Tg€Ød ô$׃Ǻ‰{m€·r[œŒ—Æ8¸÷J¼ìc�Ž—žqÕ]ã¢9Üü nZq>3çyè°&˜DNZk¹r1ˆœJ›(¥í|›o%ŠÏQE¬ A0å<ÃÅÐ|¾\6Aƒ.
쾦Y/-lÔ	&í…8ff„öCÕhw�½¡* o·™Å„m¡œGWª\øGÎ	ˆQ¡h?b‚4Î¥ìç7ûpj€ÞÉA™	¸H²ŒêKšxŒ¸‰Ò
Åóz£LG'ô¼;fxQz>æx8Í]8BbÊ(“˜#~COT%©yЧ˜hò.–‰þH/AÿY†Þ‰ŸÑÈq01Lðl´$ĵ@!d5ð,b$[Ƴì·Þ¸P°x&<ªê F
	ZÇ8_{òA«Í#Ú}QlSälð¦V'ì|Yo6A³ð¥"ÁÁÓ°‚=Lùné¡Úpàåé€xµqùBOˆCæ¼»KÒŽ‚
¿o!zO›ž ÞÖÛvWW¯ƒn�–$<�RP
+m^VÍPƒëç¡E„2rý’"[4“Á]oÚÓµŸ†šÉjãÏDz>ÖéXÖaÆJ`
é#r8Žb`"Ú»W¨wXäQLƒ½X?¢?¬ÿ¤˜??–ËGÊ"´ËŒx¦Ê'Ö‚ðŒGíc×E;Š	³tT �RWàþ"(X
àþ·ÞF�ólCT?I¼±2¨9DËŒ”zèC¼ñ)¼À€¶ÄÑÒ´TÜ�î%ó,ëãû	tU	e"ò&¡Ý©LÄÑ}¤×ë] ¤u‘·c„’ŒkmãÆ�ï‰6‰aÚtHoÀ1@Ƀá”(ÄÄá¼R”xK—�

¢hB·LEbÈA൅@<É&$BÎféø]Šk^YXëƬc&â ™‰|”q³þ!jù\áz_á{l0zôŠDCZÚoM ,ËÂñ…Ãxmåðø£S?ü:ðRŽbì%퇘Ó)?¦Å
+¯ ¸“ILYší»‘\F‡1žIaeßÈä
Èê<ø.ÄDk®yà#\<§}„—°—Î^qÃd6á"¤ç�$^AÔ[zÖ`ýpš

+ç°˜y\q^n c!ı/ˆ2S¨Ç#S½^�-ßj»�3"{e2Ô‘y†–r,w�Ó‚Ô`Gm
×�}Mûu�{ï§ÛÿÛ·–­>½­ã°W¦í‰;›
+R;øJÐ	.Pf¥v�¹�K$}Ó»0cµ 
+Ì(™nú8Y1¿ƒÿr~u$ØTIÈ.¤r,èKÆìø–eŠ°zãpÚƒà§ë�œ½«áL³þ±Ò΋þÖá\vàbÀ³dÊuÐMæœÌ:K¾P_­Äºaþ²XæËK$õSî™[F­³Þ7	¨\·´	½Ä¾w¬tñyÈ5±®NF�”Ôah^Âö:R.�A~¦àHýëû>�P¶Ì8äü‡¯Kߧ¯Ôu÷¡¥n!²ž‰Hpsý!äèó
©Ã9Þ‰ê¨ÅDfz˦[<k‚‡a‹G1ã ?01lñ¨.9ÆaK8ìµ
Å!,)ÅcPÌŠ6Îâ÷³]\wp9øFI+Âqñó¤QÝ7µ�À‡’X[s£)9dÐü¡íÄ8Ž�ó}E×":Z-b¯_ÇžÈ17ܵ5nÀÌ®XîwMLÖGä@ÒÎólDnß•ÏåšÈ
]tìZÍklU>—Ídâ/N|]¼·¡»ÌÿM+¡†2Ù¸±6x°S2Á°
›†t$òPÕ˼Úmós¬BñUëç©’gž[Õë˜Cädê(´b^ÈW*Ø>ÖKMX'n|`§D&_¡Ÿ�&è¬ÔB©Ë1ˆõZ©=@0LVj{Écxé¬ÔÆ6¥Åñsœ&Ôp¢/Ô%aÅcìä?<&@§/Ö"ÖL›ðb”6vôÑò+ŒGƒOÖn”’­b5lÕ‰“¶ªÄú	¿qÊ7xˤÉĈ^Š{’,Ɖd1νb¬Ò%þÕÉ5×æ,é.Çöœ‹a+ 2„XÇЙ,ñ„±
+¨š�úÛ­U~›µBò!•Pç�µ‡tÚVÒAàû§dÜÇedW’¥s¤;¤cÚÃ
+¥å€ø°Æã‡�»®Æãý�÷Ì‘B
+Àf¿	µ
+Œß½lóM¹$ªð
+%ì¸ð8¨‰Í¢ÆbÞWÅö… ’
+ðAN›™Åt\¼Òmî°ôc…ïyô•Ú±£OÔÒræ¥w=>ŽôµÃ9OR%ÀVzÔÇ=fvê`Ê0üÕÖuÞÕZßýã°Ã/ç´#�þÜþÕËÌ%¦ð ætƒþ˜õÿ
ØúÎÆendstream
+endobj
+1226 0 obj <<
+/Type /Page
+/Contents 1227 0 R
+/Resources 1225 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 1219 0 R
+/Annots [ 1229 0 R 1232 0 R 1233 0 R ]
+>> endobj
+1229 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [367.5469 658.7781 428.747 670.6783]
+/Subtype /Link
+/A << /S /GoTo /D (zone_statement_grammar) >>
+>> endobj
+1232 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [483.4431 456.4665 539.579 468.5262]
+/Subtype /Link
+/A << /S /GoTo /D (address_match_lists) >>
+>> endobj
+1233 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [213.0783 62.7905 261.825 73.5749]
+/Subtype /Link
+/A << /S /GoTo /D (dynamic_update_security) >>
+>> endobj
+1228 0 obj <<
+/D [1226 0 R /XYZ 85.0394 794.5015 null]
+>> endobj
+358 0 obj <<
+/D [1226 0 R /XYZ 85.0394 642.7523 null]
+>> endobj
+1230 0 obj <<
+/D [1226 0 R /XYZ 85.0394 619.131 null]
+>> endobj
+362 0 obj <<
+/D [1226 0 R /XYZ 85.0394 502.2708 null]
+>> endobj
+1231 0 obj <<
+/D [1226 0 R /XYZ 85.0394 478.809 null]
+>> endobj
+1225 0 obj <<
+/Font << /F37 747 0 R /F23 682 0 R /F39 863 0 R /F21 658 0 R /F63 998 0 R /F62 995 0 R >>
+/XObject << /Im2 984 0 R >>
+/ProcSet [ /PDF /Text ]
+>> endobj
+1238 0 obj <<
+/Length 3053      
+/Filter /FlateDecode
+>>
+stream
+xÚ­]sã6î=¿Â÷fÏÄ\‘ú Õ}J·I››ëv›ÍÍ=´}�m%ÖÔ–\KN껹ÿ~
+>™§±�F¡DR¤q¬,ÿ®JûIÌŸÄjºÈé�‡|­,3°E(€ºfœmV7ù�
,2”zúèvVùSvØ4ôRÔÈ»»Èt¦T"�©XNþ3›'A0-�¡÷´ü/}ÔÓ2˜ø“ûæšÈ;�"CyVÖÌì:ããKf›4D» Š6'Ý(�
+#Uì”CÎêÄGÛ™«HO_‹ÍW†”�]¾JÛ|…òéôq–ªiE8y™-6Œç�†uG±@ùš�k4”§ã˜žR)d¬Ë|Á¸AÂ
û—̪ÍÊ£Óìû7U‹ÂÎgbËj ƒéK¶9 Áàº3ØÓt]Ž°.Ã\™?vÅÃ¥®i„®Ié>ÙŽxcTA12Hø“‚E8ÔÐç‘^–Õ¡kÞÙ«©V‡%G(A3!Æ«®R›â%¿ÆK'+Ê%Þmê<l€ºÞUe],ŠMÑ	
íÎ"x‹
+hc·>VÈn¶Jž:'ã
+D'iŸ²}8[uõ½Ê›¬Ø�ÑõŠ.
iD¨ Š\¬ºXçë�Õ†Ò—d^K°ÝšÒT¯DˆÀ„¥/óà±F˜è•Q"Œ‰úL<®1)O«ß¬_3LÀ<�¬ñÁ&éäó°¨·Ue
÷�G*™>Ñ÷[Ú½�ÿ¯bHBϬ\
>°Ñ/‰…2QÔ÷¦Ÿ•ŠÊbAé
>Ùd‹|S#”Þ‰¶ž.Š2Û»8˜'M:ý*œ62)ÓQÀ\°,	ó–8ÞÆÒú5÷…ǯó’ðW9…ó|	
iu=º
+ÔÕ’	[œžH)#Õ
Øô6/[ŽJ‚+­a¹Ìj[À‚i7©@QûbeˆóÜh#TlœÆÈÇj'jG}`Ðk%ýzä²úÒ@GC
œ_>9dí(ñšÓôÚ' ß«´Žì“8òÈ Ö€´°†zÞ{Bî¼ì½¬Þë°PôŪŒuµ9)/d EIçòÑkäìžã‰
+Ù9�„¯,7Eý [ÉDÄ3°h°î±OzÊ 9Ò+tö;{ªol_‚!ÅdûÊé°±«övKîÙSåÚé
׬Fûqýê Þð¥s+¶:xÁÍQ?”ÂÆ¡¦ük‹_tÃéí:/çU9"ùÜãö̈BÞh6
=±ùÒQ(ãb]“ýJ=¸=ГÎÈ6ÔÉ¢F±á‹%i™1-Ù0í5èøôÍ6Z.¶5Ã6êÕØHCe}Bc½·æ„J¤Æ˜ñ)áÜSœwIÒµË_¨ 6ihÛ=¥Ê’Ò�ÉXaËþ…L:Šo1	5AÁ­÷˜´
ðmœƒ•��à%ùè:cÇ_tIWŒI‡ò¦RB%íèŠl®çl.‹¹ø²8àI§K¶K<|�S3z •
‹ß³É¶EŽÃaLt¡¢õjtôð=ľb·uÏ@À*ýRÂh_nùzÁ)¨Û‘²¶Xì;׶æ¿g[àâzÄ‘æ&1º2ó­ìعª ‚Z˜Þ,nØ”¾$íá
+Š»¨Gíobs("&oïdriΠûA4‡2Â9é ÞõóJí¦I
+´žÑÀ|ƒE¡ŸoHIó
€€ñ7Åò°ÉöôNzEŒáä6—¶qƒMû«`„ô3}¨´-Tp‡‡qô½�lHÉ“Ù™œ0wöÆ-ƒî(‡×qÓàŒ{vUÁþÙ/BN‡ëî8ã™­hã;ŠŠk£×uN?&puÑ–“at
+06�³-ÞàÆôÿÙ=œ
›Zzäv�‰?
fåX+óåíCªE…¦oj=~º5ÿð—ü³ÝƒÿðR¡‚@~µZ˜¯¾zª÷ã'ŒýÑPüKŸ‘™"üÏÜüé?(jÿÚ*Âq”93œTÚˆÈ
+µ«ÓQ,äé0Q#¬ÿ?-�endstream
+endobj
+1237 0 obj <<
+/Type /Page
+/Contents 1238 0 R
+/Resources 1236 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 1219 0 R
+/Annots [ 1240 0 R ]
+>> endobj
+1240 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [369.8158 645.68 418.5625 657.7397]
+/Subtype /Link
+/A << /S /GoTo /D (dynamic_update_security) >>
+>> endobj
+1239 0 obj <<
+/D [1237 0 R /XYZ 56.6929 794.5015 null]
+>> endobj
+366 0 obj <<
+/D [1237 0 R /XYZ 56.6929 475.2364 null]
+>> endobj
+1241 0 obj <<
+/D [1237 0 R /XYZ 56.6929 451.0522 null]
+>> endobj
+1236 0 obj <<
+/Font << /F37 747 0 R /F21 658 0 R /F23 682 0 R /F48 885 0 R /F39 863 0 R >>
+/ProcSet [ /PDF /Text ]
+>> endobj
+1244 0 obj <<
+/Length 2446      
+/Filter /FlateDecode
+>>
+stream
+xÚÍ]sÛFîÝ¿Bo¥nÂÍ~“›<¹±�sçꤎúÐkû@Kk‹c‰TEɾôæþû
‹%EI´“Žs37š—X,ÀX
+O,¸¸üÇ9�Þ_Ÿþøãéõø÷É'ç“N–¾¼‚+ä�“_磈ýÃ	gÊåfô/œ	çähy¢�bF+ÕB'ŸN~êöfÃÒ!ý•3“Ël@�R
)Ð8fL¡ËÅbœ*n_7�c�l枀U±Œ Æ¯üš uE°U½ÞÄ(‚ÜÖ¥¨>Óàòュ¹b6[�Ežø¦ñ
MþÆ
,7óˆ@À¦¬îZF€½Ù´Ëfq¶žÞû
,¯
+\ÅZè\Þ¶lG\ÑÕ’å`ðüxÇcºÆ²LX‘ëÕ¦l…ÆãZZùi‰Gìg¯žQ yÔUɤ
÷fVp
+ÐŒk—N1h	ËÐŽ9è짭_G§@H
ëP¦7�U+Žê‰£ (ÎjßTßmh⾪p‹ªy$\
+°¹3eLð
+Q -øå~ìšùÛb»ØĘü׿ùrz±w„d¢¦Fn?#�‚5`?ÊìÌkÔnÞ›híw$C?=^Çže¦¿æm
+<Aiwpíäcþ´bÚʸ“>bOŽzûìen`UàÏö½}ªrÑ$™–_Uº@Èq!"E.8‘\1«á˜ž¤Eë8ЊÃvÅAìJDå t)ª¬Ú
+§Sm0íL@i¨­‚{CåAÖ«ž«EŒ,FÉ6–€#
+æ!õÆAÖ�àõåRŽÎj�hÔª%œö)¡àè{.áÄÑpŸ:!H(ôp ÝÙ
¼¨~ŠJ³èrøÜ´
Ëö#�€DÒ‚Þ{I¦‘	çXò¤Í¦ö8²ƒRJ¤Êa»ÈE„ÜŽ�_nj¬~pôóÙGÂŒQ
R.X¥î¾«LÞá-�ë–7Hƒ {‚Ç+Š?7Èä6£XŽ!ò*lù(Á‹Õj’.œ««Åçˆ^$ð‚€Ã=0‚|`˜¢¼xDÄ…ü7ˆåÏa†yH–'Á0gW¾ãD4»{Á�ìÐ!ï€cì»Â˼ýØ8¨}Ò]—áž�!6Wö›Ð‚˜d3iÿ‚¤íŠ§âˆ„‹ØeÆ~!Ž(�Xdß4Ž(Hèd®þq¤Où™8¢¤`R;XþT/Šh€˜5å<
[`‚†TôÀÀGp£5A°,¤Q¨rqÐlW=Ç¿¡@e.ÖV�·rØ¡�^øÒÅ
+|A¯èv4õ]þÿ°aÜô)éŸòËçÿßE³j­¿ i\ñ”‹€I1¶ò�¼ŒeVÉoé"XjYéÄ·w‘>åg\D
+…GC–OÞSP.M=p‹j
ª¶JÙ@�ÑÜb”÷á}þ*…ŠAí*œ.Åß¿¥¡fÈÛ:	¼­¼ýÒý¶ÂU[~=íý~™Ñ|{÷èÛ!�Rv¸ìmÑöïxÌncO,‹=±ÖUìÓMÆBˆ$œ�_EgŒ¾$`»e^ÄöËÒOçEU6ËøŽVè-ŠÔ°‹„m0Q1-Ç‚æ&ôyôg`% u\ì÷— fÒ`QBùgëj¯?èËz[EDìf‡u1£]Bëz xööDmD–û]É]Gós³ñKÌ€À’'-ô¶^,êGªêpUW>bqYVì<nb«ùÏNñÝÎGÖ˜sÆ
ÄÕR	5ü…(â¤=¤§M¡E
+.›’ÏnŒÉ¯túù�;¤ã­÷i˜ÍÌþÞgá{@îI™‡þƒÌ’»E}S,„}a…3„YlJäƒo%=”ØHl�˜>W„µ]×PƘb·`W&—¿Ðx	;w¾‰I8„éôAÿgî+”œÚ�"Vû¾™tZ¯>Óˆ¬Q´¦Ê;“籃)‚¡R[&Ï£ÿ„L ¤BßÈ…zTv²ÚØOŸF»~o¿ïâNWŸ†Rqb}ZS70t"v"BÑñdî«8–O_5ÛV­p}DmãHNå€#ÙêyDC^â\ü,à°ë]N„åÕµyï|$RÑZ±X`½„À®X¥¦ÛPù®̻ËûÅ%w±Ygp5årØ)ܵ¹tY˪ި£Žiûõò˜õÿÔ–F{endstream
+endobj
+1243 0 obj <<
+/Type /Page
+/Contents 1244 0 R
+/Resources 1242 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 1219 0 R
+>> endobj
+1245 0 obj <<
+/D [1243 0 R /XYZ 85.0394 794.5015 null]
+>> endobj
+370 0 obj <<
+/D [1243 0 R /XYZ 85.0394 650.4851 null]
+>> endobj
+1246 0 obj <<
+/D [1243 0 R /XYZ 85.0394 625.2941 null]
+>> endobj
+374 0 obj <<
+/D [1243 0 R /XYZ 85.0394 171.1138 null]
+>> endobj
+1006 0 obj <<
+/D [1243 0 R /XYZ 85.0394 149.3849 null]
+>> endobj
+1242 0 obj <<
+/Font << /F37 747 0 R /F23 682 0 R /F39 863 0 R /F21 658 0 R /F62 995 0 R /F63 998 0 R >>
+/XObject << /Im2 984 0 R >>
+/ProcSet [ /PDF /Text ]
+>> endobj
+1249 0 obj <<
+/Length 3623      
+/Filter /FlateDecode
+>>
+stream
+xÚÝ[Ýsã6Ï_á·sfÖ<~ˆù¸Ýf{é\w÷¶étîÚ>(¶œhjK®eošûë @}YvÒ¹›¹™NL‘	?€
+ã��=ÁƒÊ{=Û^%Ö›{6Wß_ý£�°7^�”Ÿ’B›TOP›ž
+=D»)›È(Õó²Á_5(¿wño>±d¦D–¤)Oóïº*&ÖÒ UŸZ&jù¡ØÕá
Nkçå�V|*7Z¨þRì÷媠§Ãc1¹WpJ<OZïe]5ÌèÅ�;'2'ý˜�¤³…q0¯u ¥„·Vªƒ0¼™‚É„²Æ÷…hÏßÌÒd̽4
+¥¼ºÈGKtÊÈ
+U%C€Á$oe�E…è
+q
+Ó\­b‘h|oÊf4g€ÍÎË==–`ÛKž%TÉ 	¹zhBi”c{j2±‰­vå¹ÜZ§ÂúXF˜Dý®àùt›ßS*Ž»VjŽD‰5„C�'%h‚G‚͇VIçdÄQDf»½Ks@0»–uµ”»ÞÑÎ`ÛÒg­¢rÒ­AHpΩ$༷Ée§Ò§:ïTZª‘xqoc�¢œH_X�i&xmDš€G¬~‹êÑ>‚S»¹Cõs©…´,\žá}´hš�$É
+G g‡–}äõâ®qv=e·}ŽÈêY
+ŒfI:dã_!XPÞö^|\â�€�{']a‹•^zª©±‚èvÂjIicÍ›©³ËdÂù$ž^ÀÇx‚	&
+’	(Ù¶õr°˜)»NzÍ4só|“Faá¨i�‚+Êì`�t[LÃ΃¿l:£Ë1î”°©;ñ±Öñ±–… „zâÛ�ëBB ‹ÁR ¨éwU„Ä´br2Î@ÍüÐBüº\5bª@®P)®§�tu;”ÍY}AP¬ñz†¦¡Ñ„m¡¦¾þð=õp-˜zC€€½ì!9ÁƲè÷.ÉI®è•(z[MíIƒý
ÿÉ+‘áE¢ÚÚ÷._þʼç
­²9ª}§ÙdTJ:å]«lÄ{C�9ÿîê¦)ï7L
+XÍãôÃ2“8ÔÂ9õZÔ;!U{ýQòêÛº‹N³yì8”ÇK¾úÑf~’dŽ_ª«�·@«9îvõR>R	²jt¦?S‚I+mòÇ›�c ÿDƒœ„&e=x¢Î;°?(AÆ0{| i�rsâw&¦ú£ì�%ÂK�uõ”³60Ñ�$cÚÔ�÷à+×1ëŸFü”QL‰ßx!]­Ö.%ßåIºÖéI5 üð—aÔ†Ôß•K*B4õš»~¼¶0´ªŸšªÊ
@$Ï^Èh»àš˜˜Ø=¨3K}òòîÕK»Ï„ÌdÖw¹ãsRØÌÿaŸšx¥Zîø(Þ?ñýäªà[žxÛ“ÓÏŽ§ï*¼š71˸~e¢ÁßÛÝTÒt"�B¥§×«gƒÈš…Éä¹LŸê|ðÑRõ…ÛLÝH8ÛÌWo©&–^m&xwn‡ë
+~ªl
˜Ï<dÓ—o©&ÖâÄ‹,ƒp}À@° Dõ²q|ˆ”h”†}u[àÆ'2!lõLÉÉ„p ˜6oBHzÆ„ø«¡²ttúS’t½zx¢) YkMßçÿ¾õ ÿõXÿ\âƒ&T{.Ÿæ\c(}±B>,jŸZ°±Òì6²z•	ŸA¡òpJe©½ŒÂ>Õy¶TCÆ“¬:-Li'’ĨË\´Tl˜ÑÇ<	d>C>¸ŒÙ¿6€‡®2È¥!%;wŽ\¨VƒË–ðH_‚HÆ"vÝ3å	öïïÙi±:=ÍÖ+!ž‚
+ -r*a1Ž�8äœÄN¸Õp:°1ãç$ãºN83׃�Òg†¢Z0¶A½êÎ�ñ™�ÕåÑÑé€=tN)=:zK*>�¨®FÜô•ˆ¤ÄÀJO‰§2ð^+D8bm/<»hþªÅPì¯ù7§áq
+,óv£aSk"‰__ʱ1R¹†ë|ºÍïz
+
+ÓÁùàÅÎÔåèpÜl#Ð3hFèa“à­csdairxa�Gnq©5ß¡{¹V¡Ø¤M¸lܯó%¿ó³ÖÉrS7‹áîxER<üÊé°ÍËaçÀëÃ@î­Æ;ÖàNµ²„DÛcœ3ßíŠ|O½ámâÜ£`î¿LÖJT*¬J}û�í¦~ê>t™(Çe"‘z\ÆSg¾|7VàçêJ¶ñèýU|÷/I& F8óñƒÎ jtxAALá6lrêâùóùSÖÿ!Å^ßendstream
+endobj
+1248 0 obj <<
+/Type /Page
+/Contents 1249 0 R
+/Resources 1247 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 1219 0 R
+>> endobj
+1250 0 obj <<
+/D [1248 0 R /XYZ 56.6929 794.5015 null]
+>> endobj
+1247 0 obj <<
+/Font << /F37 747 0 R /F23 682 0 R /F21 658 0 R /F39 863 0 R >>
+/ProcSet [ /PDF /Text ]
+>> endobj
+1253 0 obj <<
+/Length 2665      
+/Filter /FlateDecode
+>>
+stream
+xÚÝ]oÛ8ò=¿Âo§
+{vO@"
+Uï~³ÎÛ²«8³(Ò}Sí¬�©TI0¼gت̼ëÉÆm•�
šÔX¡�Ó¢}h�v˜=RÓÈÝ$˜Zclߤ»·B
j²²ã8h>¼$Êèª'Em'ëOµQÔΧ†'7ð¿H.DD¥ÐÙÄÀ;3«>ù2
MRÎIÂêÁþ¶;)ø‰Ÿ.—bò¶†;Mú׊”§}Òþ^`‡=½ÐpÅŒ
૘bÖ3ý{½ÈÁ¤À:¼ñ—ˆT§œÀ¼šPœEY¬if^
¿ª[šÍj…æ©@{ÂLѶd}0ðågɬè„ù|]4�ÒݹdA§ñáûæsóæ#hžÍ`óì\°ä3þ‡¾˜:PCå,8c#'ý‡þ1Ý‘�t}¦» ñcš=.ÅEp¡©qí0Œ³”ù—e2UÚî^v`ñ1BvXG<ÙôѨ¥1 ! Ö?á€�k„‘A4Çh•Üãä&º’&_(oF—6)Ž—'6„¦J{^õâ_³bÕLñÁ{´@°	,Pð¥
DˆkËbNÃMC¡ÀË��æ@ÁèYøD[È$Œs'Þs‰ÖñÇë°ð"ù¢�Àðõàú 'ùˆH#|ß"·ï3`ä5Æck‘¡b]AœÃ¡Ù=Ž_Dæ�KoÔ0ÆD¿dñ€N1feÓ¢�=V5¢‚ƒ�›}o862n¹ËËE˜÷5g!r*:íMSLQÚ!vC²—9©‡ÎçÙi’´]Ü-ƒš�<&µ„-˜{‰0™ÉÔ@ÌýWw“J�/Ì2ñ­0©áÍ8ãöEäutÆÚÿ@˜ì“>&Dg]ëUš±ä	ãN½¡Á¼Æ/&¶eó@©>
+�‡OÕ ø¶á~î6Ù�¡ý× 
+H#¬S†)™•C^00	Ëú�	‡»À„£~`–S…mcq
+ÅŒ€÷yù"¶OúD+0p\üÿ÷zûý?ÝëåÒ–©ÓÙL‡uà¶ÆÊ1°QÁÀoõi&4k„…Aªg@§2ž
yøµü\Œ6ôRÛÅ�oºW­�|ØÍõaÅwlW+ÐÉ]¦ê¿!xz8&±¸©Ú!.ör©]Æ�ùȈ§æ†§Bc'PŠTe d	Íæ&…<–3™mÆ>}Bà#¤Oý
+eÕ\°ƒ2�‚þc]Χ�jº™¯¦˜n�¥!;ƒ]”¯9¤†GÙ²æd»ø……ˆžã>ä:*„i¢¾£�š
+(è"”¡)º8
+�aöTPÕÇý}›@€Tâ‘ôÖª|Ù¹ókõ’fu~"è±ZîÞ»Ÿ#Bù8÷µò¬Ij´’Óg7¤HT­ŠÜô… Ÿ�¢ŸñÍ-ƒ-¤g)ýäíkÑyls…�Û`"©7
À†›Íìa°qȸeˆóîr	(š·E¨
+endobj
+1252 0 obj <<
+/Type /Page
+/Contents 1253 0 R
+/Resources 1251 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 1256 0 R
+>> endobj
+1254 0 obj <<
+/D [1252 0 R /XYZ 85.0394 794.5015 null]
+>> endobj
+378 0 obj <<
+/D [1252 0 R /XYZ 85.0394 141.2512 null]
+>> endobj
+1255 0 obj <<
+/D [1252 0 R /XYZ 85.0394 118.94 null]
+>> endobj
+1251 0 obj <<
+/Font << /F37 747 0 R /F23 682 0 R /F21 658 0 R /F62 995 0 R /F63 998 0 R >>
+/XObject << /Im2 984 0 R >>
+/ProcSet [ /PDF /Text ]
+>> endobj
+1259 0 obj <<
+/Length 3339      
+/Filter /FlateDecode
+>>
+stream
+xÚ­ZÝsã6Ï_á·*3µNü5÷´»Íîm§Ýí%¾¹‡^d[ItkK®%'›þõ >lÙ¹½Þd2‚Hˆ
+J\07��ónÄùpÈS€SÒÅF&¦—ìu£�Ø#)c�˜`á´ä£iX
+óŠàÀ4!xhÊhÀ™=¼ Öã<" ª Í?sz¬ê.#@ <lwŒ’‹	êâz8QÙNf¥öÕØ !†h%˜ï즘ÌÄR§ÙåMr�ß”ŽËk–·ù™MI1Ö\˜&mJª! �Óbfb°)ðBÑ–h¿-YâUdÖb[ï_ˆnÃ÷ø±¸,3/%{9ý¦ÁËä¦)HÀÒ,5ß¼i H� ï^Ýà
+"IR~9�{Ÿ—
wþQL7ƒ˜nƒ¿Å;Ìpm—áZ
+G˜óÖ5óoso&¨Ïõ±ú�nÑÞ'¦ùR€9�[Ù =�iyÍ¡%ÈÅ&o<ÐÖaLÂMhëœ qaþк|9út¼ "EÞže"?†xª²€
+"ʽšO�ÉÝ…Ðöh�w\Q©ÇeQ
+~g�JY
+á¤üzïg=ßÔó)ê¢VZ_V£ãšÐcäbÊA/îHJ}U¦ú$)ã$	Û–M½)Úâ¯X
+Õ>õvç«U±ó§UÿV­¹û¡âLŒ{|!
+QÁk¬Á]áñBû%ÃG‡×øB©$Rd@¹/©
+.+±Ãß�ó÷Ô4]üsÅÄžT*ÎW#Ò)™�ª$ÊŸ·P�§±É_C‚|姲¢uÍ©D†“â¥�ÎCV™qCi‚�µ�ƒë’àõƒÅ=ëí˜XKuÙÙLç}=0ùmZíÎ:9Ä÷4�lö’äŽéTôøÈìbëR3’½eÖAiÞö4Õ„í±‡CKgÆ@/ÞýÂ�uU]4Ϻ`_ÒMG%ݾZL‡¾Š”)Þ©ŒÍù‚¶•x<6½Oý¾"�38M¾­…P±Ðâ•p=亰ë�kºB8Úy	X§!q¾(¿ãšP`4W™Å©tv¬
óµ¦ß}Í;¼×#C¨JC¿÷Eí¨ŠgéáЯO~ñƒM~¦ˆ/©ò
Û<æ
+endobj
+1258 0 obj <<
+/Type /Page
+/Contents 1259 0 R
+/Resources 1257 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 1256 0 R
+/Annots [ 1262 0 R 1264 0 R ]
+>> endobj
+1262 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [361.118 694.3759 409.8647 706.4356]
+/Subtype /Link
+/A << /S /GoTo /D (configuration_file_elements) >>
+>> endobj
+1264 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [347.1258 314.3269 404.2417 326.3865]
+/Subtype /Link
+/A << /S /GoTo /D (journal) >>
+>> endobj
+1260 0 obj <<
+/D [1258 0 R /XYZ 56.6929 794.5015 null]
+>> endobj
+382 0 obj <<
+/D [1258 0 R /XYZ 56.6929 769.5949 null]
+>> endobj
+1261 0 obj <<
+/D [1258 0 R /XYZ 56.6929 749.7681 null]
+>> endobj
+386 0 obj <<
+/D [1258 0 R /XYZ 56.6929 443.842 null]
+>> endobj
+1263 0 obj <<
+/D [1258 0 R /XYZ 56.6929 420.887 null]
+>> endobj
+1257 0 obj <<
+/Font << /F37 747 0 R /F21 658 0 R /F23 682 0 R /F39 863 0 R >>
+/ProcSet [ /PDF /Text ]
+>> endobj
+1267 0 obj <<
+/Length 2860      
+/Filter /FlateDecode
+>>
+stream
+xÚ­]sÛ¸ñÝ¿B}£g"ß'O¾œ“ú¦—¤®Û—ë=ÐeqB‘ŠHÛñÝô¿wP D)餓ñp±X,v�ý„Âgþñ™Õ)“¹še¹J5ãz¶Ø\°Ù̽¿àžfˆæ1ÕOw¯ßÉl–§¹fv·ŠxÙ”YËgwËß’·½útw}{9š%&½œkÃ’Ÿn>üL˜œ>o?~xwóþŸ·W—™Jîn>~ ôíõ»ëÛëo¯/çÜjë…çpbÁ»›¿]ôþöê×_¯n/¿ûåâúnÐ%Ö—3‰Š|¹øíw6[‚Ú¿\°TæVÏžaÀRžçb¶¹PZ¦ZI0õÅ?.þ>0ŒfÝÒ©óSÚ¦Z(3›k‘Zkìô)³”i8µy¦xj¸Ê†S|ꔞr¿ØÎëªëËfþå±|,Õæ:OyÆòYÌûH‚�jB‰À
žÔH†»uy9—*OH‚Iš¹„Y–Û~
×g˜ÝÓ.ËUñX÷4(š%
›ª©6�ZWu„”~íÍŠÆ}àñ¹Ü5eMp÷¸Ý¶»¾£¥H'
ç®RÁŒyšk-œÀÅb
"
¥Í’3&ê¾Üù‘jYôÅî’Û¤,–/ˆ ©~íä
¨¨»– EÛôŽ´­ýܺ}&`S4/ݽý4P7墯ڦ,/ÅsU×Ý£nÖÒù-	W5N´ ÚΓn[,JŸ‹ª¯š¬Ú�'h7~ÕCHÀV8�ŠÒÌ}9¬Û]‡»#Ü·ô¥Sƒ»y–üë2p�eG“uÙy”j’^ §mè…©ê²éë—±Vt7»¢‚�Sœ:°ÿ¹PiÎ8“”©bÜ:zŒܤœC¤`Œ%ŸÊ]Õ.«ƒ»KŽ’wŸixÓÀM?ÁýEï‚FêT
+#ÏûiLuÚO*sQ—EÇ;¯¼GŽjDX+Ï‹0PMÈ0vÔ,U67c!œó)i’D¸ä	Z=é†"sØ´OŽP'å×mE¸eLе�Xx2Â.Èš–‘®È36DÒ‡½Åb¸?•»—‰›–"O™â¨õèìÈ¥¥5©¶{FvŸëÁaÈ#¾öÜ Ä<öe‡1%c>e,ŠG™�<ð5Œ¾'ÖlŠ¯>ZÁà	½a¼\XÏ»xqÑF3Ťó,O½r^Ö‘§càCóíÊž
+^,¯wV½´ÄÜžÀy-|ë¶XbÑ7WÂ&W+WŽ�8¡\ ´d,ÂÓÁÍÙîˇÊïäû¢)uYQB	â\
¨·w•‹dR%(+"©† )Ÿk.«nÑâƾ*BÜ`O�ñj¶Tþ<UK¢R(¹ç±�”8¨ëö9pº÷¾�9LÖ¦BÙPÊxÛf2WÚ‘âW‚Öâk׃�ÃS×·[‚h§¡–pw©ÙHoŠw…¯PÖÅ“|5q‡gþX�ŸŒv
+¡åÜœw1Õéx7P¡Ú]êv}µèÎF<&Í7„¨&¤8ŒzŒgb|(°“QåáàA8Í ÌÜ{êº}xpð©Çs¨ôsÖ	��ctÇÇ¥±²Ò—l_PÄ“*Õ";¬¾½
†’³à£!aûæ¿.aëP##'lÍ6ðþîr8>رeß{)è`�ì‘38"e sPÐFA½õ¯EèoÌZ;ýZñJQÃŒ>Í‹Ö1àåÁ°bÌj¤›K�¯JBÅ&8Ü
+X&\
�’„kÚzŒÌ@Å%dG	|È>B©Ç¡už‘\
džò"­߶`óÙ—’ÊsITì´ÝŸ‚C¼¾ÙˆÙÏ-è4‹Õ
+œç1k§—±¡ƒ!ä–�JAë·ãÔj]õf“—KÁ’ҪͶ.7%8ÀÒ#úú‡H€ò£ÛWy–	=s|¾?vePæ&gзï_Ì ÆV
+HSØøp�mGóÐÚ?$!ºüòXÔà–Js_!qI”CÈźm»Ò³(èÓ¸€‰³{Jz‘BæìBE�
aµðu¡tEÇo¢ î–9O*l…Àø)…—+˜A„ô/�0ãra
+O\:Æj
yý…¦5*Ö‡yOßwe½Â¶J
åaºg`5:Ͻ_ö§/<�É(ò;›÷ûA‘W|.½tE3±˜†2YpÿbéZ>Fèìàñt¹Ã§¾‰€©0+iÓ\èïz_àÆgÍÛqœÇ,�í›s°~7�¹LVô‹õ‘�Š¥Æ2ñ2pü–�
+:%“ó±�Î<�ï’gi&Exü¢§q™Q­å-Ò=s#®sø5h÷8ì¶å¢r}?öE×\g<¹.à`ܘӼ†j¢¦µä,8QÖÁ|�µßªèºê¡)½0~#¨…{l‚ýãUfR(�ìØ^>´Í¼)
+‚A¯ÀùB¤~ÀP�è‚Æ�%!ï‹.,s5¹põµ#Ô¶í*j,p‚àÞI­èÑÒ5'CÉ-X áä™»$�«nªr.,­_
ìAä]O8Œ4ˆòsv�°ˆ~Ýîè7‡˜K¤ºôï0kÀþ¹t¿ª
+Ï!®CW�;Jf¾�iBWôjÊÈŒCKD�7èÃ>*ØÖ)†13ϸïÂûQùµÀæE	Hñ£”Ì]‹¡Ç¹an Ÿÿé”2Íñ§Î‘ꜽ¶o¦Îä/P#¦òµPo¦LþOb4¯¹yC‰œôZ3ŸÜ‘&�+ŠXüпó(çÒØgfz‰s}' ÷�A0àŒ¾þa@$›Öy¾¬ÚÐ\#6×ø]ÁYŽpÐlÒ
+endobj
+1266 0 obj <<
+/Type /Page
+/Contents 1267 0 R
+/Resources 1265 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 1256 0 R
+>> endobj
+1268 0 obj <<
+/D [1266 0 R /XYZ 85.0394 794.5015 null]
+>> endobj
+390 0 obj <<
+/D [1266 0 R /XYZ 85.0394 690.2056 null]
+>> endobj
+1269 0 obj <<
+/D [1266 0 R /XYZ 85.0394 665.1198 null]
+>> endobj
+394 0 obj <<
+/D [1266 0 R /XYZ 85.0394 302.1184 null]
+>> endobj
+1270 0 obj <<
+/D [1266 0 R /XYZ 85.0394 278.2032 null]
+>> endobj
+1265 0 obj <<
+/Font << /F37 747 0 R /F21 658 0 R /F23 682 0 R /F62 995 0 R /F39 863 0 R >>
+/XObject << /Im2 984 0 R >>
+/ProcSet [ /PDF /Text ]
+>> endobj
+1273 0 obj <<
+/Length 2998      
+/Filter /FlateDecode
+>>
+stream
+xÚµ]sÜ6îÝ¿bßNžÉ*â—DMžÒÄIÝi�ÖñÍ=´}�we[“]É‘´u3�þ÷PKiµ±ïœNfBˆA
+BĹ1%”ÊXe"]d‰ŒM–“‰]à]f›TD‰%�s‡ñ
¤"¢+ø_F&
4“Lf‹ÔØXkw™Åç…ˆ�çŠpØ]u/7ñò|+o¸Ð"¸“§»»+�!ìuo�àôÔ€ehÒùÕ]IwJU€*
+ú|{ñ‘¾?ïÊö�Ûâ-®`³Í
Mnw›¾5ŽhvX�fW�×mü-1Éåeƒ ¬›¦ÝVõ-­ÿ=
+´õgS Rô´^un*‹v=+ÜSa`½fV»’é‘›Ì
+ÚF…{Š
+zE‰q¦êüV'ëÍôó®b\¦4H�$žâ\ê¬CFV�IBð"ý@ú ÷QŽØìâ�ˆ��€e”™ŒÜd&)$Þuù(yè㤿¦‡>NA˜EÇêü)~\—›æ�CSÊ+>áÝq¥¨ç8P6¶�
0e”-ÈuÎ?I%åBç"ÖV?)Ï€,ÃZ{$Ë(.C’‡i†´6–03`!—Û¢_ÝMyTàY
Ã~;Š�ð¨@�:Sé˜É#šY¬R%¼¼ë5)§‚T²e×Գªžtþ¦¦™mã½~u÷åªBs^¹HOŽj!¡•›0¸V|S©8nÑtžÍ¦È#î!%„À2k�öºqÏj´ÈøUZnÁ†2(7d®�»Œ¿7ÌÅÝ)ÝqÜÆ|Ü•‡v-As�V‡GÌÄ]ÆzŒ“jAÜUZGg˜-©¡¹'`ÊÝ�Ð&Ò¬¾ª1¡ÁŽò¡XùºëJ{Äí®óôû®ÜÜ�ÕhHâU¢Ó±Õ /W™t9T�Qùçý¦ZUý;©Ž5 ~Ý‹¨Œ…bE§P3dPp>÷…—!ÉÃ*($3Ùþä£nê2¨Á!~;&=ÅǘÌÈÖ¬3yÌ�X(’‡€€Ù;骩KRæ8Ñ?4”T°bÌL3C9 "¢iÑ($¿b’‡»jŤ]5…À5ï$»�ÑùÏdEÂHÈÄõ$çÛGkˆ 
+r
+Ž­†à†-ïœdûÉ5… Øº(ÿì	oëî�(
Ô5#„}¯
?ÖË9Å�™Ml䛺Üü´‘ȱʴ±x)5-1GèªEÊv
ˆÅMO-Vë{ž€[VÜwL쾟êIJ&ÉíÁ`E
+|}8ëŸíN‚êÔ|ç»»æ¡&ðèQÞ¡$rÔ1
+J„ò6FE¿†	øÃìÀ0á« �-LQ×QwÆFÒœ»‰¿®2™·I€‚‹¹oîæ"85yC:Ä%NSL6&ëR
ã#¢™êÃu±ÕLB¥‰—ÏŒ9í¥eò©´Ìèïk–fÖ5Í0cùpºæÓ}�4ƒb¦Ò²¡õ9á¾2caæ,ÌeLß2:ÄzpˆUKàº5±±c¼`ì­†›üÆ?é§îQ¤_÷‘)	•
þmˆµ™þ¥ûqòåKZ9‡8‘°ëp	t"ßÓÖÇió›´¯¾?» è¦j=³7(¢”žáŸ%|HßxúŽç fà<21§f44ßWã)µŸúûp¤&þ˜”d_¥ì¹Ì圄ý…W›#9‚o&ûç„-¾vRjgå½ëX™±xÁÒnyBN¾Õ£ÆóÏËM>SnòÉr“O•›œÊMüßrÿ˜ÜÔ3妞,7õT¹©Çä&Ÿ#7ù<¹MЇ˜ñ
Yx]ì7¸+èÉ•ßù¾¥`A^­è¯4=¿³’8þ‡XÊÄøgc3�údø‹§gÿuÚþ¯`°Ïn­<ÒñÏ@†ˆ0Sȹ±œû?c;dý¿?¿Évendstream
+endobj
+1272 0 obj <<
+/Type /Page
+/Contents 1273 0 R
+/Resources 1271 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 1256 0 R
+/Annots [ 1276 0 R 1277 0 R ]
+>> endobj
+1276 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [213.6732 554.0172 286.8984 566.0768]
+/Subtype /Link
+/A << /S /GoTo /D (rrset_ordering) >>
+>> endobj
+1277 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [209.702 475.7236 283.4678 487.7833]
+/Subtype /Link
+/A << /S /GoTo /D (topology) >>
+>> endobj
+1274 0 obj <<
+/D [1272 0 R /XYZ 56.6929 794.5015 null]
+>> endobj
+398 0 obj <<
+/D [1272 0 R /XYZ 56.6929 622.2509 null]
+>> endobj
+1275 0 obj <<
+/D [1272 0 R /XYZ 56.6929 600.0717 null]
+>> endobj
+1271 0 obj <<
+/Font << /F37 747 0 R /F39 863 0 R /F23 682 0 R /F62 995 0 R /F63 998 0 R /F21 658 0 R >>
+/XObject << /Im2 984 0 R >>
+/ProcSet [ /PDF /Text ]
+>> endobj
+1280 0 obj <<
+/Length 2668      
+/Filter /FlateDecode
+>>
+stream
+xÚÅ]sÛ¸ñÝ¿B“'ºsÂá›@òäË9©ozNë¨Óéäò@K´Ã9ŠTD)Ž›éïP DÙÎ%7Ï °Xì.ö±	…?61ŠPaå$·’(ÊÔd¾<¡“[˜{}ÂÌ4MS¨Ÿf'?¾ùÄ«¹žÌn\†PcØd¶x—½üëÙßgçW§S®h¦ÉéTišýtqù3ŽXl^¾¹|uñúŸWg§¹Ìfo.qøêüÕùÕùåËóÓ)3ŠÁz0YðêâoçØ{}uöë¯gW§ïg¿œœÏz^R~Ž‘�'ïÞÓÉØþå„a�šÜÁ%ÌZ>YžH%ˆ’BÄ‘úäíÉ?z„ɬ_:&?%Q†ç#äbL€Ê-`Ê	pö¡Ž´ÎnÚºnïªæ?ËÏÅrU‡¹»ª®±w[}
+cëSf²²èÚ¦¸Žp×å‡âSÕ®#ÆÐÙÄ=êv^DÚnƒ½¢Yì†:ì¶
¶‹
+·™oê{™·MŸå‰øŸ2F¬RÜ3Ó”›»vý{§(¸É.ÜJg•Ãªò¬«–U]¬qpÓ†Ö§ÄÃW{³7],HK×á@×®7ˆ·jp$ê�Î$±äs âªìVmÓ•qYÙl†|Ü–ëª4ÞøMÚå{ž!l”£ë¢]I“ÝŸn°hî±ãøqm�c(Z7²­ÿL„©r�²áf‘
�±Å¶gÃ}ôlôTøAãm�'n#ú³7φ
+löT
+—ÝÄ’óó²†!܉ƒLŠ
ŽtŲ`æ%ž!LË#ÇÙ
÷�)�4A¯i7ع.±u:T.ˆÃÞÎ&ÆêpçÄ‚yÜ°®ÜQkJ³/~{­H®„ÊôBx
qB}‘|O]øþï‹1¾<<ÝÛ×à$¸6¤^‚·ÉÂ8ÇÊ4a-„WW]$ñf½
+	JhµŒ¾-÷“gܵ͘KVò Î^QSÂw0`'J_J駤[œXcÌx²5í1NS”Èä€8ná¬åncä«r>¢œIU´»*Ä„EéÌý‘ÓÂ0ŒIX÷<ø[¥¥r	ÞÍë¢ëp#5ØHH]Yب‡HLr8'1nç€ñ›%1NS”^bâ˜r·±O×\´‘˜ Ö%ÏÈÈ{”Ì»ÍýªáÜÓ<êIJ™æD´óß�éã#Lsž-!¬ÿq®wÀC®tetÐÏí²¨šOZj•µß�ñã#Œ
h$ 9`üÙç–“Û!ç»Ð9Â='Ü�ú†ñ¹z§žvèp.\.¬ Ãu™«2ÁVüPuʲÐuö\9+-?Àˆ	qÝ-X”7D�°¤u_p'Óy4û³Ë�»meÔ]‚è�8ˆƒôúHZ•ý^~ò(m6¥Í¡-Dò>¤=D›~˜6¯�ÉF p—Â0=Lb†äÆ`a ×}DïøXØáÔ€¦ô6ò—²%p*x4ˆ�*ZtГîwè³�DP‘Õci«ËÛ"dz[öNz=Bœ1€A‰Ç•b`nûä*$ªÏ\µÈ‰Tà1%dÝ\XöãÒ�²î¡ùþ±U‘—…×t”\G
WèÆûÑ"25• ˆhæH|•‚È"&Ribrªð8A�>ãÅO¤ "Ÿ¢H¯—
I“Ë€dû—
˜öù¤Œ:	 iÚŽã÷ˆ†!ía¡ÙÚ¦Ëèݪº$i˜�Û•Ö|’ŠæÛÄínf·ÿÓQÆÇOܶȅ~ì](ÐY_ÍK_q€*•{ŸÍ÷¨h!èÚe„Á�ö"I.³Äžðóm2úsÅžJ2#;g„»™ßÏëjþ§I½H
+$>…<�k©Ó‹ÕÁKPîºÂX’+%®âŠâˆGüª
…§P¶}~¼¢yÙA )*Å@8pY!ArP—ØúLÛ÷ΰÁ\Àõž¹º	”�y»|†ãÉ^hŸ/F‹‚;(TÜP|%¬/>í×�\žê!v¥ëy±íÊXö¹O0»ÚžÎ“ªµçÐõÎŽšt_I
+"r]'"‡)”]e»ˆUó]f38n9¨
+‹Ùþ
+®ý‚�é8Ö6ÝöÆQëC§K½r‹— f†P¸ñÅ_ÔwÅ}7¬R·ýü¬/³œÅÊgR=ãÓ}MpeGüʾŠ_ÜìUˆ³6iáú(Ÿ\ÓÎòö*<‘ƒÕª,<-»÷~„¹¾ç
+>2r'˜ï¥Æ Q
Ôeq“º*;rì݉sín¦Ory’Ad¶JMûr¸½jý5i_\±ç�û>þÒËSÏÖ›3è4%93pcgî‚Lü29	*�
¢�'ñ¼ËfðŸgçû’
œ’¹X
Θ[æ·ž|œ@t”Ö
+Júž×�üÀ�K>ù¹Ž&	Sñ4Å왂`––ŠrWø
+endobj
+1279 0 obj <<
+/Type /Page
+/Contents 1280 0 R
+/Resources 1278 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 1256 0 R
+/Annots [ 1282 0 R ]
+>> endobj
+1282 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [353.6787 560.2827 427.332 572.3423]
+/Subtype /Link
+/A << /S /GoTo /D (the_sortlist_statement) >>
+>> endobj
+1281 0 obj <<
+/D [1279 0 R /XYZ 85.0394 794.5015 null]
+>> endobj
+402 0 obj <<
+/D [1279 0 R /XYZ 85.0394 630.8728 null]
+>> endobj
+955 0 obj <<
+/D [1279 0 R /XYZ 85.0394 603.2815 null]
+>> endobj
+1283 0 obj <<
+/D [1279 0 R /XYZ 85.0394 477.5928 null]
+>> endobj
+1284 0 obj <<
+/D [1279 0 R /XYZ 85.0394 465.6376 null]
+>> endobj
+406 0 obj <<
+/D [1279 0 R /XYZ 85.0394 128.2785 null]
+>> endobj
+1285 0 obj <<
+/D [1279 0 R /XYZ 85.0394 104.5761 null]
+>> endobj
+1278 0 obj <<
+/Font << /F37 747 0 R /F23 682 0 R /F39 863 0 R /F21 658 0 R /F53 962 0 R /F62 995 0 R /F63 998 0 R >>
+/XObject << /Im2 984 0 R >>
+/ProcSet [ /PDF /Text ]
+>> endobj
+1288 0 obj <<
+/Length 3669      
+/Filter /FlateDecode
+>>
+stream
+xÚ¥ZIwã6¾ûWè6ô{‚•
+,îšSÛA�-©×pb©äÿßÊ7E]7=ÎR~Ý”^¹PÖA^ÅsX�³_/`ÁrB�`GÖôTí÷Kw%~»jZß?c­o¯Mv‚…õ8Eó�¯ÆOœ‰fÕ}ÀÛÕ€³ÀÏCpŸÞ‹ý©$3P“kIŒÍÕËx4二G‰+Jú2�”¬ÍÅËÓ'®…ùÇp¢Ö:/àsÙ{‘åÁ? pö=¥¢£


+O»j³õ`ŒkjÌ3¿3,"ìl«ºhŸ‘âLóØtU_]³ì±t–‰
	…Ö‚ïvÞf$Ú°±SF_D¥å7u0Ÿ§²ü‚%7ÙÀH’,*üIq£_Qö€ëeG.¯ìª^·MÓw3ES
+=�¢_š:q-Ì=R4UÄJ­Ç“ø2nQ½6«O‡;ԛɚ{üzM5èÐ6h¶Ã¦~WôXBYۀͿŸªp–ak°ƒîvæ*»~Â,ÈŽf5“Yd¹–À%ÒLÀ£ØlÊ#
+c…bì1jW¦«	3¹ZM’ 
špmøJiE”Ph5ÂP¹d(/hçñLÿñz�3ˆjÖ9ÏfQ¤
h‚FF$eÞ`W¿¯¡ÒZ�Lƒ²ßëYžðí‡_½m`G«á¦ÂÀëáÈ~S9až ¹�`ˆ„Í㦼•i0âÃq_à„ñvë5~Cø%;Ó¶Ì-áÆšÕPžMEdŸ[ˆ²×çàø¯К[bŒ¶ÞY¤Pìe0“–¡„xÌ—3ª‡5šÕ¶êŸ×ˆ°…Úؤ†Ð´3œ`l‘ka#`Sè
+Õ÷Õ¡J
qhNq”&Äø›}³	a^÷¥|r÷닱�äpñЯÂá€ë8Œ\)¶+ïÛ²Û­Ýö¾Á¹ø~‰ì¹ûöyΉ3ÊÉi._ÞBâZØÃȃòœ(1âh·x…f„ë-¦Ã
+˜G�ñÙ	^µ®ã~-³¿u!:3’X3
ÏîÊ]ñXyÕ
+€ã¿h÷
ñvUý€ô? •	‰Ç2ˆ ÛçÀ%ƒ¥
+Ò£'NåSV°:·O)\êÍuZ;=;W–2‘+Ä#OVh�’gûæÎ[%y›3Q nÀ$W9ë*>àÂ"Ú¢b¯ÏÂ]ºC’[T¦Íà&ûâp\ÚV‚l4m(̤åQ¸Þ[ûöùŒëÝØÓˆ]ŠÓ¶ƒŒKw©D×’Û—�zÀt§#“×Û¶îÖ§íqÝU”óô/nšÙçNLóÉÅ$x0pMÍ“-úœl)¶à:}ÕÅœÙ
„šØòóÛŸ�twòyà{t1�ù¥{]qÏ}é±KÐìßÎÞ‚™
+ŽˆŽêJÁ§]qˆ®ž\[ø—?Ä�I´Ê)óyød3®2Â�ÀW/ÅÍST	Û˜¾Oßz[ÁÂËé…/ÅãÃ3†#›4Ý££“¦DÉ;¸6$,&xgAÂôõK¦m`~ñ)�iN,Ó¯¼
¹.[âB`s¡¾Sþ¾\û‡ß~†oB®µ|y‰ka#|“‚
+4úSHU½ÙŸ¶!_í]Ð�ÒpéÌùÿ&
+; Q]Cím¯
+ÛXV€šP©'ùý'—„êdAŒS­2ð&]Þ‹dqœœ§“o�©¨êécÓÌþ|Ü�öwáO®Ëå·išþ!ñ—ÿ
+endobj
+1287 0 obj <<
+/Type /Page
+/Contents 1288 0 R
+/Resources 1286 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 1256 0 R
+/Annots [ 1290 0 R 1291 0 R ]
+>> endobj
+1290 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [297.8955 476.5924 347.2449 488.6521]
+/Subtype /Link
+/A << /S /GoTo /D (dynamic_update) >>
+>> endobj
+1291 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [324.9335 169.1118 381.8296 181.1714]
+/Subtype /Link
+/A << /S /GoTo /D (zonefile_format) >>
+>> endobj
+1289 0 obj <<
+/D [1287 0 R /XYZ 56.6929 794.5015 null]
+>> endobj
+1286 0 obj <<
+/Font << /F37 747 0 R /F21 658 0 R /F23 682 0 R /F39 863 0 R /F48 885 0 R /F62 995 0 R >>
+/XObject << /Im2 984 0 R >>
+/ProcSet [ /PDF /Text ]
+>> endobj
+1295 0 obj <<
+/Length 3537      
+/Filter /FlateDecode
+>>
+stream
+xÚ­Zmoã6þž_áoç
+‹x–‰ÙæJÅ2Š•”žR_}ºúçÀ0hµC§ô§â4Š…Jf©¢4
“Zf‹AkgQ"…´,ø”–}/ÔrQW¦é»ÅÖì®y:_|Ù›Ýá
ib“]L¶ŸêF$:J¥ˆg¡
+ÜœÜ\à$�†¾u»Z™¥â�•¨¥Yæ`T±stT·EC…3G´3[‹†iÓ(�µrN`ååÉ /»u»¯K*×_“¦è‰´nŸ©°!ÓƒÚ[e%áñ¼h7ŽQÕЗl
+9}¼¥rR÷¸3Y
+hp[T«²7Göe`­¶+xÉÞ®ÁNF’HZ
P<›Òä5'4>WýšÈù”™4m³pKÞ¶
àr—Éü÷ÖZ ÔnË�äÄ
+¹"ÑnÒL†�÷¸y:NÉBzÈÃ
l¨Ç£k«Ûg:lp‡°
M
£: ú¾Ç½Fbµt�œtë¼sÂY›¼j€ÏÄrö
ùw9éi X‚Ã0³H0‘:8¼x2ž`(œÎ
Êz+¢3í³%ÂïĦ}ã!–köG¬�ƒÆ�««MåXµÍÈQÔ¤£§’šo}ëpIBvâiÅ	†¡eþÆ&Ðp°¬?£^΢Tå4õbôq¢cÎTèX‰”t¬„¶:FB c¥…7=htŒUÏ iiü~k…¤Çv�úÁbkG¹ñyC]«Í¶íŒëñx˜X%¨1Ž¸Æ8(4Ç�‹(Œ_ôÔq¬¢$… �–�…¨.Œèûôb¬tº*úN„e}µ<,JSçg
 W¸u™|qê¡ÓùÜ£½Tq”AD6šœT
àh§çœÏÑQRIç�Æ °h›²³TvØ?345%!0è!¡d=šiaDÛ˜®ËWÖ®µ?�œÓa�7ÍB�ü	•ªsq,AcغŒ·¾hÊ(„Š2–` ©
+§
˜´ðþBÃ
+‡Ö¶3û²]ôívQ›'S/ÊaŸ–yD`[R€Iiá�USN(IèHhîÝÌŠ³àtç'àL�C\9ëÇOÑòÓ!�¶ñ8¦£€A.­Á	üšezŒíòò]O%«+l¦j 2¨=U晚1‡èŒ¹”Áª,@«Ý�Úv«î§r÷°ÿ¹»žqÅ~‚è“l‘gÖŒ?‡	
#q&0ÃõzEŠsnAÆ2X_‡o�
+�¶ò©Óä•mÄl†åz=¯«bMl)*ÏÀ�`³l�# p]’õo¨ÍÊY€P¡]D„Q—D,�¯›ýönêÀÐÊ[î·ÃÄdN>ÓBŒ‰ËD¡ÃªnsŸ±Åi¤%×cW°&ÃC·¶£J··*È
+ˆCÑ1'Î'eªO¶Â̓—	ç«Bd‚£PžD¡圧¹X¯€°×Ýi0—)2ŸF²ã•Ã%/T*JµÌ^ñ ×^è{¡¬k.½mŽÜ¢.ÉåËûN�lLB꘩“™É	“ä(‚­õž<xaÜ¿
´�¼ÚȺŽI’Á¡hÕò¼ä…)�”N2·õ^ Knh¯ÆNˆ“L;!ØàMi,Çîô‡¼ÆÆ—ã)†9œüÓŽ,éŽóž×�iû¥œ%Ü$S14Çp¢ëª	úÒ‘vñ£“ ÿ‰]$–ñVªÆÞ³¤ô_(mT¡<Š*{÷æEÂÜŸÐc¹ol8lïì|궻j“[sÀÊ~‡74ÂÚ]x¥Òà¾Ei
+7Ýk`#Ä�Ëa�êãRâ3‘8¡-‚+—œm©jç„/„…EÞõT!½àtŒ®El�¢ßÃ}ðý»g�Í¢T!æÚQéxS)²×à
lK¤">±qâƒøöíÔ�§'"ã…±™Œ˜b'ÇÄÿífŠé—Ñ.ìuí†^A��÷\Uyyq$âT¼<ýÐkbþ1è1H[!f	à@OÏo߇¥§`O°—œÀž>�=}{úu؃¨;S‰‡�Û÷ѧ›ûßÜO%IQ¿ú£ ‘ç,ù3‘‡•øby'DæéÉ+×=á£
‘ñ
+–Iðª¸*SOÑû:·Ù¦} +Bk¯7íã‚kt„a
£—‘Ÿ§�À$-�‚kO¨ÝxGCxÆS7Æîö±-žKÀœˆ"qØ…ƒëVw-
­š¢Þ—æâ#€�âDbÀ²Pbh'‰�~ûÓSB$k‚D–AmèXGµ¨ÙU«Æ”è:oèùÜsâóºj>¿ÄÓÞâ<‘½Ä¡ ív1µºÇ¼øì®ÄF†¿WÇJûæsÓ>7g#»É·X‡BBøgy,BƒIKÄÒ€7mlR…ÕjéúÒÇâ
°�$÷;ìS»›’ò@óµêìK”ik…Â&ôS	(ãF�…zðÀ©Ç™íI¶{&ð*oSöôbÿÒ@L·³VÇClPìñU›',n5½Ó}Ns<ÜÒc§»Qþ²Â*]zž‘q„¿
+œï៳�ÿùLJÁ뎎 tÓy‚dI”
+_œPö<{ʉeAÒ¡'Dÿ/ä×}endstream
+endobj
+1294 0 obj <<
+/Type /Page
+/Contents 1295 0 R
+/Resources 1293 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 1303 0 R
+/Annots [ 1301 0 R ]
+>> endobj
+1301 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [84.0431 462.4692 144.9365 474.5288]
+/Subtype /Link
+/A << /S /GoTo /D (view_statement_grammar) >>
+>> endobj
+1296 0 obj <<
+/D [1294 0 R /XYZ 85.0394 794.5015 null]
+>> endobj
+410 0 obj <<
+/D [1294 0 R /XYZ 85.0394 535.1829 null]
+>> endobj
+1300 0 obj <<
+/D [1294 0 R /XYZ 85.0394 508.8634 null]
+>> endobj
+414 0 obj <<
+/D [1294 0 R /XYZ 85.0394 198.9245 null]
+>> endobj
+1302 0 obj <<
+/D [1294 0 R /XYZ 85.0394 172.1168 null]
+>> endobj
+1293 0 obj <<
+/Font << /F37 747 0 R /F21 658 0 R /F23 682 0 R /F11 1299 0 R /F39 863 0 R >>
+/ProcSet [ /PDF /Text ]
+>> endobj
+1307 0 obj <<
+/Length 1767      
+/Filter /FlateDecode
+>>
+stream
+xÚ½š]sÚ8†ïùL¯ÌLQõaÉÖîmH—Î6íRöªí…¦x†Ø“d³¿~e$áƒ#¤x:³“É K¯õžçÈ’ebõG†\ !©&2F>\Þ
ðð‡j{? F3¶¢1T½]Þ\³d(‘TkÐWŠpš’ábõ5ˆ¢‘ê
Gï>Ý\ÏÞÿ=ŸŒ’8ZÌ>݌ƔãèzöçT—ÞÏ'?Næ£1I9‰Þý1ù¼˜Îu“0}¼�Ý\é©?.t:Ÿ^OçÓ›wÓÑ÷ŇÁtqb�¼³äçàëw<\)쌘LùðQ`D¤¤Ã»AÌâ1c¶f;ø2øëÔ!h=žêÌÁˆ2A	¤Ì•@.‘`ª©Iàb“k¦åý~?"i”—]±-jSªÖú3¿ÛžtñߪÌk],êß.¦�)w'�aªcÔ$Q'D+@_MÔß0Iº¦‰ê�¤ÔojEÏMÏR•Ä¥äç¦*ͳ›ñäêjŽ&óÏ#I£ÉEpÚIBà@å
·ª ¸Ï´Á¡)¡ÉËÉ1FœÉÐL*¹UÉ}¦-y×ÔMM)WóXÈÓ‹£4&ÒOU—éOª½×ôDÿÌÔIfJ"	}9¼ ˆÄq€*¼Uá}¦-|×Ô
MIÒ>&(ŽE€*¼Uá}¦-|×Ô
MIÚž”Äêæå‡*¼Uá}¦-|×Ô
M‰ì�)Âœˆ
+”JXV¡êrÆNªPƼ¦§Œ=3ufìÌô
+]7´/#I3wS¨ò�[U�ÜgÚ’wMÝäÐ4EÓ>ìq‚bÉOPåa·ª »Ï´e١©ìÇ®öÛ‰LPåa·ª »Ï´e١é¤;N–2ðì
+²ûL[ö®©›š¾½ÈÞ\FHb!†c"U¢7SóÊ�ðÓ+CG™~Ó¨ëëüpÈn·æ(;hÉac*ŠüQ—¶ùC¾5”+]W•[Ó}¶Ûé¢:·jO­�n­›–Û¬6U³¤WEÝø¯´"wDÌO7¤X!$9×+ 	�ñ¨(7ù¾8{b"ZÏ©îtcµ;UYë¦b­+å)ªºÍ‹j++]¹jÃSµ6<Õ`ÃSµõ._ß0¦Öû˜Fm +L™I£Bg˜G‹füŒOõ�ï÷ŪèçûÁ¾%n)œoˆA¬ö%ñk]~ªîÍ{æ¬<Óꃓ�ÎYuh{Ð¥ìР&ŒÈج«½yWýOv·ÛæÇWÓo®™<ŸN	SA=Nõ�ß3>¦w¬mÆÑ+ôêwÝÅÙäŸ÷¡o³&	RT	‡SÜ�HTå}¤1Íj¥UÇËRUì³òGnÊËfLŽ­+]a/—×Íð%­S½©î·F“mµ&[5׉äÑ&{0fºAõY›
+{	Y¯³ø×:ˆ¶9�ñXÇÐîë\]U‚²hVêšÝ>[Še®�›Âœ¢¦jžíÍA3Y›Ï²ó¦p{Ô›K·©Xfµ)=‡�.Ýeå“.ý¼WaÛ`nó#�V¬rèÀ/1åzŸÕ‡ý(�î—‡ûÓ˜%j¼ò}“,} /-U(³»ÜÔ¥þT]×öœ�èl™×ÍKXô¥Òõ:bxÒZeÇžž™R�-÷lj¼,²­#ˆÇÆWæùêxi4}T®‰{kfË*ßm«';1�d37YY×T8³šŒšŸyl«Ìœ’=f¦,kð¬KiTM†
+endobj
+1306 0 obj <<
+/Type /Page
+/Contents 1307 0 R
+/Resources 1305 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 1303 0 R
+>> endobj
+1308 0 obj <<
+/D [1306 0 R /XYZ 56.6929 794.5015 null]
+>> endobj
+1305 0 obj <<
+/Font << /F37 747 0 R /F23 682 0 R /F14 685 0 R /F39 863 0 R >>
+/ProcSet [ /PDF /Text ]
+>> endobj
+1311 0 obj <<
+/Length 2674      
+/Filter /FlateDecode
+>>
+stream
+xÚÍÙnÛHòÝ_¡·¥�ˆÓ'Ù=ûä$vÖÁÄžu<À“y EÊ&–"‘ò1_¿U}‘”écã0�.VWWW×ÕU-Ó�t¦dL¸³T‹X*gËõ
™]ÁÜÇêhžh1¤zwqðÓ1Og:Ö	Kf«
/¥èì"ÿ=zÿ¯Ã_/ŽÎç&I”Äó…LHôîäôƒÅh;¼?;=>ùøÛùá<ÑÅÉÙ©EŸ��¾?š/¨’Ö3Çá‘Ç'¿Yèãùáçχçó?.>]„³ÏK	ǃ|;øý2ËáØŸH̵’³[ø 1ÕšÍÖBòX
+Î=¦:ørðïÀp0k–Né/Ð,„Š/Ù–²Xk)¦·%``šŠ'xÙux9Я³êÍ›$,N	Λ—ñ¥±–’¡}5‰S
+³)ç1A˜÷lu,A‘Ž’Xr‚Š³ù"¡ÑüÏ¢£}s
+vмOt"ë*´�1ç<ä4¸§!*D¬¨HfC¾vTÛóa§Zêñþ_6Ų\�Cq®£Û묳�ÈÀu¶.ܼq"„²Í¦ÈÜ<šGcrÀKÀÍÀ‡ê"·˜/g‡Ã©ecF7¹j#çÚþ‰n�7xÐÉʸö‚ëXA†‡qmÃî1ãé0¶x¢¯„°"k1 X  ÿ¸ö|¹ 
èÒavm‘?ð\oopµXÊ„=íCªÇ�"PõN±lê.[v½BÇŒ=·} šØäRČ켂)ἂ)y‰Ú©
ÐNm€ón�°MXÒ§F±ç8eÜ¢ŸêÝ'W�c2žn!¨n
îÏ.^ã_1þ÷}n
+úBˆ+-�Ï—.ëʶ+—.Œ�K{ê$–/ä…AeŠQ¿·ö"^u±Í:/ÿ¥óÇ-WÈ åº¬@�ÐG¹r¹sÞ\7(s(*ËeVùÓxwϺîªúJ.�5géÓ'Êwë�OVWeÝúÖ]»ð²CUÖÅ[þ·øyÂ2aGev|óæÍ´	>„ÉW"‰N9ô³Zhø Ó&zp Ul½[_šR`SJÀ¸q^[›¡u“nÌì
+2ËÔ=à¹�(ªÖ�:0}ùÏŠžÆZéK^òô%-3
+ötï�ïûV
žéD
+…Iÿ�g
+×Þû
+n_Út†su{;}Üóó‡FP¸§	t¨C«¾ÎSÐ'9Qjô¾óB–~ÅãÎGHRÒçœê^¢¤M'ÛbUl·öúzÞûeÁûFï”÷Þ†HkY:3AªGO@\ýŒÛÛð°˜Åä=jìÜ>a ÁÉ_§Í¿Ô@Ø'œ«gD5ô&©´Ù¡¾ÛnÛ¢{avPƒ»	`“\ÜÙl ”·‚cûp÷ê‹+|´= Î&ûÕíú�<ë²Çí5TÄ�µ—ø¡ö’,N.›ÓDÅ,ñµÐ]Þàý÷2ƒ1)ƒÁFƒá†Î`Ž
ÆdâËOÿóáìóáÉéTzí	ÃNüw$¦bõèÛVo!b.…6XeeµÛ/$l7À. \Køb±²cK2ä:ÄïÅ’´¹ŽÛž?­
+endobj
+1310 0 obj <<
+/Type /Page
+/Contents 1311 0 R
+/Resources 1309 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 1303 0 R
+>> endobj
+1312 0 obj <<
+/D [1310 0 R /XYZ 85.0394 794.5015 null]
+>> endobj
+418 0 obj <<
+/D [1310 0 R /XYZ 85.0394 494.8753 null]
+>> endobj
+1193 0 obj <<
+/D [1310 0 R /XYZ 85.0394 472.5641 null]
+>> endobj
+1313 0 obj <<
+/D [1310 0 R /XYZ 85.0394 284.6288 null]
+>> endobj
+1314 0 obj <<
+/D [1310 0 R /XYZ 85.0394 272.6736 null]
+>> endobj
+1309 0 obj <<
+/Font << /F37 747 0 R /F23 682 0 R /F62 995 0 R /F21 658 0 R >>
+/XObject << /Im2 984 0 R >>
+/ProcSet [ /PDF /Text ]
+>> endobj
+1317 0 obj <<
+/Length 3317      
+/Filter /FlateDecode
+>>
+stream
+xÚ¥ZYoä6~÷¯è·m#†‡(‰Ø§ÉÄ“8H&»y˜²Zm«££ÃvgÿüV±HmÙžl`À"‹W©Î¯¨b£#i6±	™æBo²êŒonaìû3áæ~R0ŸõíõÙ7ïU¼1ÌD2Ú\ïg{%Œ'‰Ø\ï>m#&Ù9ìÀ·ï~ùðþòû_¯ÞžÇáöúò—ç�Ô|ûþò§j}õöçŸß^�"Ñbûÿº¾¸¢¡Èíñíå‡ïˆbèñ̦Wï/®.>¼»8ÿ|ýãÙÅõø.ó÷\á‹üqöé3ßìàµ<ãL™Do Ã™0Fnª³P+¦C¥<¥<ûxöïqÃÙ¨]º&¿�&¤V À�))^8–Žàp¬k†1K$�ON
7LÀ?ØRÂÌ„ËQ'RÌt"„faobmX¤¤²:ÙµÍá�ïP60]ͦƒTbÆpλ¾ËAœa¼­‡ê&o±m›=Ñþò¶È;êì›–wEvG{¿ºËÛûÜ�ïŠ.k°'’-q
+¯ÀóÝ¢’ÇB£J�Ž²Û}ÑÔiY:ŠS76Ñ0V4+C�ïÔRÌižy{Á¹SÖÀJë¶~™_¶&!Å%ø8N
+–ˆZ
6Wb««E…)
+úG!W¾|Æ=§Ü=ËÙνÜ(‹@DPBħʹ¾:DO
+ŒÐ‘®ÒOr
-½3ÓŠöi%BÐÜ÷T¹Ôˆ£ž$BBé†êàŒ2¢¼i'
T�ñÙËÛû
+@ŒoVÊ*ú´«��_¡¬Hûâk‚
XWºŒ™Ë‚o  ¡ 梖…Ò¦Ü版9KB³d" à¶ÂKÕÕ‹QD°0âúÅ("´ü.ŒÔ&®˜ð±‚‡#åÐt]�üØž…'øN‡<+öGGt	R a:95 ápðP¥,ªâÄÉG»Õ'z·>ݸ…éÌ{oÜì¡[—ªÔPv*y¥¥��“lWü¹&W¨°¹Òñ(z¨ÎtdÔópjB(ÛO
Fœ•Ï¬Š²/ô«¢&ÿgùŸ†h§‘hBLD[&‹2ܹ#~YB$í¹sàä·s
!¿¿Öw3ô«ÊâX%µÔzºàsùü—³²ÈÖöI˜†÷pÓæ�Š
ð<ÁLH²f‚

+LÐX$|>‡½8èvzÈËrI¡õ‚�uˆ´!
+eÇ=]�—–aNÂâ&½TÛš‡Ñ@[D'¹mnHznH0‚HóÑFí
¦œXƒ�£Õñ´²íúiÏÜU‡Ú!G˜ã
HÎÙf‡ “«Ö2rnæ8�l¼ßt¢jv!z³	}jB
+¡ðü�­°e­Û^ƒfYžïü-’æi§sí6¥3ÊÜ_®Ú83ñŽáØ�¾ŠòìíVдh‰+w3	Ô”#(ÃO`tñ!¢…ƒ+S�#01[s
+`Ÿ¡ÜõÆ­¢AÆ¢”ÚÞ-Ì)Þ	*_q‘Ó$6-€±7祵arœu<8;öï²°cÌ«öª’ûµoa!@½£^J�®JÉ£¦Û~»jOOà�X :¯Š‰YxRÝa÷N»ÜÍDSþšƒA¡eîOqÕß|sú¤°bÉxÖ	b<u-�a…»Ç0¶
¨dN^û-÷M	U鸟¿H®ª*õ9ÐçÅæà¯g®	VœÍ…ŠÿZ¸~òí
+>+Vá·ô@ØŸä;ÈC{³‰ä”ŸÒ_œµ7+6¶@ï¾Èl8�9îÅüÈôp(é÷vÃCÚ w�îS�˜NR•Ø>¹ovZ´=ùÜHº¸–><êY$€ŽÏ<Ê,"
+g2”¾JjËïê/AÀTb“¨Y¾TXðS °'8ùCËÅVꤣ¡slï–©ž_ôIo¸fÔÚÁEKí§iî’+d< °Pó,XaÖ.GkU>}GWí!
à~GÕL©§O©±ûŽ:ÿNó±åÑ
µý¥R›"ì[‘ðÉWT¿Gû‡/€7ÚOßÚ|_<–yý™þkßN*fðþuñnŸhÆMs‹šØtó¥i¿`¤Æî?éñyÍbÜâCÛÜ»<(÷í«{¬ýV
+$„?pZ‰–|éßþÕô#³âi’Èõ°ë~¢<SVkáÓTv®"¹Âúÿ
+endobj
+1316 0 obj <<
+/Type /Page
+/Contents 1317 0 R
+/Resources 1315 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 1303 0 R
+>> endobj
+1318 0 obj <<
+/D [1316 0 R /XYZ 56.6929 794.5015 null]
+>> endobj
+422 0 obj <<
+/D [1316 0 R /XYZ 56.6929 644.4755 null]
+>> endobj
+930 0 obj <<
+/D [1316 0 R /XYZ 56.6929 619.6136 null]
+>> endobj
+426 0 obj <<
+/D [1316 0 R /XYZ 56.6929 131.4228 null]
+>> endobj
+1319 0 obj <<
+/D [1316 0 R /XYZ 56.6929 107.0033 null]
+>> endobj
+1315 0 obj <<
+/Font << /F37 747 0 R /F21 658 0 R /F23 682 0 R /F39 863 0 R >>
+/ProcSet [ /PDF /Text ]
+>> endobj
+1322 0 obj <<
+/Length 3405      
+/Filter /FlateDecode
+>>
+stream
+xÚµk“Û¶ñûýŠû¨ëXñ"�É''>§Î4Nê\:í8O¤N¬%R©;_Úü÷îb|ïOG,€ÅîbŸ
+9cäG‘WÍ—¬]óý²)/Tw—Åá!bˆa—}~6‚	í!«šuqh¾hõr]vYKÀ_cS«®Š%L¸	ÿˆ®nÞtKÄxÓ‡˜þTÜòºÿÐ_ÓÊêj„àýý#Q
zßþãùœ6õñ°*zN˽þ˜åyÇ!¢©‹”L
`ŠR­ŒGô?d"—¦Éé
+¥!ö2R1|Ã@{l¤ìÐq¥„#Çðmv] HƼÆߨ44êUN§)»+DÓòžs^IÙbvÙ·Åœ~�3qZ…9¼ó”qr	à`S)'¶K»L%%�
+âÕ¦XS˜F:«‚‚�fÍÓÛùì*5‘]~ö˜‰B¸2*Øs½ç°—U¿Q@!Ørž
+/ €Ð˜ŽUÇ@Dó’ê_ŒöåjCÍ
óvÈ¡ë8tœôÃø`¥ôØÊÃöuû5´tpß0Ô¯²ƒ¬WÏ¥bß>œ3Êe7k$‹fS·H%$¡Ùö&ÛtlßÔ‡Oh9IÂù!ÀöÇÞʞđ�$î>wne¤•2Ovç:•!ID©Í:J£;#zÜâRçF~’ù*ùߟ´O¼?y†¬Ïº=—Ñ»y”=@™6“Ž³(2šjÃéA£óÊò:�‡VAŽÌ*ηpÖeíï•
+ýŒ4;T`¨L<¹OªÀ’îZlüÐyw; É%ÖM"&Ôµñœ,_O"ˆe­_^ýDcôü‰ .Û-iŽe9ˆª-éÊ
+È´l64èÙÒq
Á3çà£@kàt½
9x1JÏ°p0£]<ÐŒ‰#%ÑÝuF iÆÕuä3,��€rüÁÖÁ±y·º-^L}YŸvŒû<¼ž¥áÊnp¨}Ì´ËÐâkèˆ1Ù£¬z[Ò¢«"ÿ<gš‚¥³å�>'˜1SpWª«G:¥*˜©PÁƒbpû\îŽ;ìÈÎ*¶Y/ÿJDëÉ€¡ÌR¨ÎÙbõRù›O7±*¬Š¬TGJÅ3íLMJI¦&%¿ý
+‡Ïrf¬Õ�³"»—@¯±PPuOBГP$bÇ?_–`Œè½5Ô—x/�“i‘¯<
+}¼…
ÿÔˆ
ÿf»¾¥¢þÎÙÛµ}8MC¾
+
é°‘1’`›ˆƒoŸí}—#àw�–á,:KÙ‡ïÂîùbP,ç¾ï‹»ï¾økÂþSK�FÊZÙ}(8y¸H"+]ˆò_B˜)åÝg‡wIÿÝíúendstream
+endobj
+1321 0 obj <<
+/Type /Page
+/Contents 1322 0 R
+/Resources 1320 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 1303 0 R
+>> endobj
+1323 0 obj <<
+/D [1321 0 R /XYZ 85.0394 794.5015 null]
+>> endobj
+430 0 obj <<
+/D [1321 0 R /XYZ 85.0394 575.952 null]
+>> endobj
+1214 0 obj <<
+/D [1321 0 R /XYZ 85.0394 545.1349 null]
+>> endobj
+1320 0 obj <<
+/Font << /F37 747 0 R /F39 863 0 R /F21 658 0 R /F23 682 0 R >>
+/ProcSet [ /PDF /Text ]
+>> endobj
+1326 0 obj <<
+/Length 3013      
+/Filter /FlateDecode
+>>
+stream
+xÚÅZKsÛ8¾ûWè¶r•…Ń
+F�ÇMfAo*
+�P,–6xÅó(Ńyë,C¶w¦ÒCGÄÚºnmÖ�ùŽt±(�Â˼Xùye;ÿpÏRr'Épϳ­wçQ/‹#&#žô¼‘yÏÒ‚ñ$}W¹_pEË`¯oÙãØZqÃÈ�©T”Ló%¸Ù¨¢žt,R‹Ú½Â"C`”Î5�X0€Þ±Uæ%Ð(Yb­ÆY#qÖI¨××?1Æ´+»`YŽXAHfÛcZf¨uá #òÐ
¿ã'l,³J042Gl:€
„ÀX9rëxÃScÀÎ/�Ž“.Ш£Ê ^óSÇGrpAp8íäüÆ5¿¹¾üp6<k™�ûvo˜Å Ò»ÝjB�«ÎE†Ïºã¸‡ë,ìÛÆSð¶áV„2,6F÷örpÕ5£žÙ¡4oAx¸ËÜVÌ´N×ß\c·;üEÀa᦬3ÝïXòé?½ ¢3ãû>«jêp·Ÿ›ZÔO¯çèŠ;�ÑÉZ8Øœ·�¸¦NkBG•¯Š´ÞS?vYº–ÜKç`ð»ÊŠl>¸¤Ç}EfЉßLB?&�½‹:î²V8@Bá»Óí6+–aP�õD&ÓMVUé*óOÏ�r¼ï®=uTË]¾ÊA¡m;×M³»§E€íŒØqGBÚÁß÷95–}·4Z2¼C õ‚0´�bÊ5:p|¾®ïÊýê¨÷›ÄÆj—n6éŽðæ
oÇ®º¼X›g°[3.Œ`7JM×ëò¡¢¶llöë:ß®ý”	
+
ÊŠ¤ï¨Z±öV¬öÛm¹«=	oü.	²á•=FX•ûÝ"»Fáf‘I`
è©£r•ñq¹³{3"ÚÉ7qܳ<zF¤)`nQÕÈx…ÞË_î#êr㻌ŸRRÀ.2?d¹$›U^¦óMx1÷ÒÜ
AFOàªTb
+
+ÞQtƒ(0Õk{Th
+©S,å	EW’
Ùÿu‡ �r!�é¹fUï\2ŠÃB%õ©vwüc9ïçÃq¯—ë~>3ƾ|ñå þÞÉ}~ÿaÌÖ°ŸÈ2kxû]Eò—ù•Êò–ÚÐm�_ñîñŒÆúÑÓŒ#Â:?<¡C‰:aR6Ÿ:UyiySÌ«èñÝÇëë‹·Ô¦"ZýHOTY(ëŠQ"Ü™WAá¹ãØ]8ÅldÕD!Æ#ÃyšS6ãgÝ	cTn(·Ï)a3³»
tM8$]á‡t2ŒznÒˆNº*Ày0é¬0ÉÓwöÆÞ� {Ó“³0üvj¯Rq_®ÃDì ±ÝÏ×ù‚Ú®2ÑfjÊ•/ð§(‹Yº¯ïJX/Eø§nÿCñf½oEùP¸”MOç{¿À«"llî§:gqèI
+Oeý\j´&Ã'ŸÜC«çålÓöÃN^Xi_Pµ‹�
Ô§ÂÝëÚø#Bm�OïÒŠz晫…j÷!	Ïoµojkn¢—Òc½;µSÑôŠi®îíàw8«&YiÝni@˜p—.Ã~NÅ”¶$¦÷é:_v&~Ж¬yŸcZ·ÇíoÚ›~­±*×M…1­
p¶µGÈ7 í×nóæ
+8�Lu¹(×g
0Vx•ÝmÎ,«©Ñ½Iáî5Q£¶>ªA›´W»ëÏ$­=±#ÑÑð(i)¢ðñ>Ïþ(ÿ&HŒ—õmåL¥4°R=°ÔgHV«êK—§.âMZ/îf‹u;iø¼ûÁ¼Ðâ«ñuí
+ØÈŒBÇ?fÕ×r÷µ(GsÑÍœyèß
<åGÆÿDR�Èöµ‰ƒÁœ±ÿ^“ã¿�°DÞøßþϦöß¾¢˜)kå8Ý”
+endobj
+1325 0 obj <<
+/Type /Page
+/Contents 1326 0 R
+/Resources 1324 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 1303 0 R
+/Annots [ 1328 0 R 1329 0 R 1332 0 R ]
+>> endobj
+1328 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [87.6538 683.0228 137.7628 695.0824]
+/Subtype /Link
+/A << /S /GoTo /D (tsig) >>
+>> endobj
+1329 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [370.941 574.3534 439.613 586.4131]
+/Subtype /Link
+/A << /S /GoTo /D (zone_transfers) >>
+>> endobj
+1332 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [432.8521 316.5051 481.8988 328.5648]
+/Subtype /Link
+/A << /S /GoTo /D (DNSSEC) >>
+>> endobj
+1327 0 obj <<
+/D [1325 0 R /XYZ 56.6929 794.5015 null]
+>> endobj
+434 0 obj <<
+/D [1325 0 R /XYZ 56.6929 474.1474 null]
+>> endobj
+1330 0 obj <<
+/D [1325 0 R /XYZ 56.6929 446.055 null]
+>> endobj
+438 0 obj <<
+/D [1325 0 R /XYZ 56.6929 366.5019 null]
+>> endobj
+1331 0 obj <<
+/D [1325 0 R /XYZ 56.6929 335.6 null]
+>> endobj
+442 0 obj <<
+/D [1325 0 R /XYZ 56.6929 180.4336 null]
+>> endobj
+1304 0 obj <<
+/D [1325 0 R /XYZ 56.6929 155.306 null]
+>> endobj
+1324 0 obj <<
+/Font << /F37 747 0 R /F23 682 0 R /F21 658 0 R /F39 863 0 R >>
+/ProcSet [ /PDF /Text ]
+>> endobj
+1335 0 obj <<
+/Length 2914      
+/Filter /FlateDecode
+>>
+stream
+xÚ­ZKsÛ8¾ûW¨rYºÊb@€`sr'㩉'ëxv«vf4Y¬P¤F¤ìx·æ¿o7àC†#e6¥6�¯_ ¢ƒ_4“IÈ„Šg™ŠÃ„EɬXŸ°ÙŒ½?‰ìœ¹›4Ïz}sòò�Èf*T)Og7Ë/2)£ÙÍâ×àÍço.®Oç<aAžÎ“”¯/¯ÞR�¢Ç›Ÿ¯Þ]¾ÿåúü4‹ƒ›ËŸ¯¨ûúâÝÅõÅÕ›‹Óy$“Þç–Ã3/¼»ü邨÷×ç>œ_Ÿþ~óãÉÅM¿—ñ~#&p#œüú;›-`Û?ž°P(™Ì ÁÂH)>[ŸÄ‰“X×S�|:ùGÏp4j^õé/2L$Ï|
+T>&*LF�¾Â=¼|Ç£Y…*I8Ne³y,C%$7“P1œƒ–cÁ}©H	Ÿº¼Ók]wÔ|«cŒ×eW65õäõ‚ˆ_ÚüNÛ…ÄH$X‡'a–ÂAã:7+ÝK3LŠ,®p»8Ç,ÿ”�ÃTJi'µcÉÒ lé™ÓcÓ<èírWa+–:ïN£`·=�d ©¯YÒL‡¤”�”Ý*·<+ÝM¹ÖùÚ¾Ýêí½ÞÚÁº}èiz¼½úDÄ;½}$rQ.qù¥6RÌqƒp"TQ¦fóþd`k°©
+_Êd°Ð]/ÊúŽšFëð|X5D˜mÃ3o?Ã$€¶P"¸ì¦ƒ›|ەŮʷŽí®Õ¤ —ÍÖN_o*£Ñ~¹vS•–íût·ÛXÆe·jv�Ù
+s{ «]å÷Ä Ñ5ôÜžÂÊ7ë]Õ•°µH�mØs’a¬xb8]äÅÊ@ƒPÉ
Ä$!�#bDÄAµ˺Åf„'‡½}¤ 8Ð
bM‡Q
ö ÚM^Ø~ReUÑ”[;Öj]uû8Y§ÝÝ‚&§+U	Ò�æ±J‚s‹´ät!4t'³`�wÅ
+w�
ÄŸ”°€»±ah”K+;;©mÈpؾüh_^,ÈBÚ–Þœ°îœåN<Cq[#|}Ïi
+	¶ËD:K“ŒÇǸM*cî>§9ï9ÎÇ,ŸzD!³0Q0ÚOC1ÍÆö…¤„,ƒ¨óÝ„ì92æQÈR8ä‰�UÙv>P§a–EùÍr8C €ÿÖzBB–2gFÎ	q&‰’>Œµ	„€(“:	Š*w‚–
�0XCb¡[ð'9ì@°™©c°aG6l<6T&ýÊÏ‚M„"|–‚úÓ(ãß
l–ã|ÌÒ¶4éhá¯`-
eœeßOÆžã
cˆµOo"äsXË
+é^ª2=
+_‰”}e¡—9FÚ	†M|>L�áè˜#ÇÆšW&ÕQc³ÒI„HƒËºë37e£²
+ÀèŠÏ6V+Šû||[…ø›IÈ�ÔžcÁøWµÀŒã$ùíI|…÷ž(w­Z»¹.ÿìË7!Md£�M´øY?¶Ï$žIìà÷°*Ážáâ`cTÔÜ—4ˆT(
+þ
+¦nÃ>µTCWÝSV06ªë8%-úcÓú—@SÜ:*Xä]N}äÈ�¸µCwà l—	[ðô²SN½g¾š”*]8ý%ÇZ÷Ì‚bY	6°­ó
+齋
ìûØ\âÖ]†ØjÖ–ÍxaB
ŒÊfo}û!¯Í
�°W™tl(ð™†Ó
�e=Lô
+q’ÿê™ÕÍ0aÞÚÂvæÕNYZææðÎF
+ûóê)`ëQ*€qª/8ŒØs¸*¶bÅî$•É
èI›ˆâ¾cœÎ(FZs…)8•MC�Xå÷z‚f«vî$/1ÒØwýÛ�'êžá$:>²ô»~e/¢ ¨Øöôà ÓŠl­Ú䎆ÚØLE/t]ؾÆÞÿ!×ÆquŽÀ¿ð½PÕÅü(ÃdÑ“tÁÆC!#Ì8â©ùçiÁÜ-H
+(0ˆžÎ-íÓ�—Gñxøòj:
vk½°|¯šÎ®n͉¥¶J1‹Õs÷úý ôzg2”’’ÜoÖÉ‚ß±>!i]y[çC.À†!.¯œï¦= —ÜE³Þ”•^ÌÝðµ‹ùo'�ú¼ÔÃír4R?Œ�j=%²€3fGxÆ8V¾¼ø’¨Î¡@h
�öŽZHÚ ÇIk|¼+Þ_ó÷Ù9ô
W~øE¦hÈ:qU7¸ë˜]pª6Á�+¸=·\�*@t0÷H‘Ø‘ŠÜ1`×åUHÄyýèMÙâ"€S–ñAeA�©ž~°KL¼.ßÔ4`´gˆfC#•¾×õaHMŠzï¶öNGIÓD÷'og·åÂ"cáRë,Ì>ug&«‘ŒB,<ñÊž(ºàCÅË12³!B�Ñ�-KùœŠ2H;˜R¾o-ÀÛ–@¹�+Y¿{éÄ<pQ{K#ÃAµe ¿@ÚT”�·FePè+•yÊ·£c€5ô‘eöŽ½uÙ3.Ê£7ˆ¹P‚ˆ
+k¿®�úr«¿¶Ï¿{.‰a×"d2ÞÛ69»�÷Â%û/¨ý_£,‘@•™ì¼/_Ò”c|Hµ«fW-ˆ¶5’øEÅŽ7µjÝ=4ÛÏ£Ðñ䎥/$HóˆXh~/å+ê O¸æ[*~0dñDº�[{…�íp¡bäÕÛû²°
´Ñ§BN$À°é•ÖòE—‡óu{¼L¹]¨APt¶s8„™oe‡,ï}°ÃܾPn5ûÕŽ>“šõèÀn§ü§Û†¬­Û?>˜7Ae$Éa´€}h‡Œ–zå-BËj�ùÜÉ.n_¼²–ëãÿçƒýqˆ}Ô»öxÔðm2·'`1—î½%hkø¥srœ›­¾/›];œû7ÚĈ£áZ/ͧ¨cíÀ©d²µcÐ_7ß~
+)‡oKÓ¬�AáÂ!L[¡ÌK²}Éû?³<ý="c¢endstream
+endobj
+1334 0 obj <<
+/Type /Page
+/Contents 1335 0 R
+/Resources 1333 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 1338 0 R
+>> endobj
+1336 0 obj <<
+/D [1334 0 R /XYZ 85.0394 794.5015 null]
+>> endobj
+446 0 obj <<
+/D [1334 0 R /XYZ 85.0394 731.1791 null]
+>> endobj
+1337 0 obj <<
+/D [1334 0 R /XYZ 85.0394 700.243 null]
+>> endobj
+1333 0 obj <<
+/Font << /F37 747 0 R /F39 863 0 R /F21 658 0 R /F23 682 0 R >>
+/ProcSet [ /PDF /Text ]
+>> endobj
+1341 0 obj <<
+/Length 1132      
+/Filter /FlateDecode
+>>
+stream
+xÚÍXÝsâ6ç¯ðä	:#Åò·§O¹”¤¹éåZŽ>Ñ£Ø‚¨ñ×I"@Êýï•-ÛØ�’™X+ë§ß®v×»Bš.H³èø†¯¹¾mÙZ÷tm.ç®{¨|T/�æ[ŸÆ½ó+ÓÕ|è;†£�g
,ꞇ´q8é;Ѐ‰ ÷/¿Þ^Ý\ÿ9º¸V|óõv
+d©ôé¶ÔÌTÍLÙ¢r°	„ðîcð$© ³6<ͦ9ï3K™¨åù Ü¡Ü`ò†5’fÅ®³‰ƒ<‚Üã¸ü¥Ûú³d3Ã4ÚÐy’2"e¨µÓ©¯ãÕ»Â-i˜…J¶&|š²i’vV�&‚Ìë
+˜ŸŠ)ú®ëh
ù6fE™b�kBÓ>Ì<9MšÎ.Mφ¦Üýƒhúžáî=«¼Æ\–j²l 
käq:O8¢¡üªßöT%Õ#=]Vø˜dÔ8™E™Ér衈·7Çÿé ÁÖGA ]ÇB´XÈ0!e$iUàfX<Eu‡åÏ„åÅ›tc„ˆ;Ø[�ÿ¨+p5m½w�Ï#üD—ù{ÊÐÓëü“{ô1½ƒñZï
+endobj
+1340 0 obj <<
+/Type /Page
+/Contents 1341 0 R
+/Resources 1339 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 1338 0 R
+>> endobj
+1342 0 obj <<
+/D [1340 0 R /XYZ 56.6929 794.5015 null]
+>> endobj
+450 0 obj <<
+/D [1340 0 R /XYZ 56.6929 672.4064 null]
+>> endobj
+1234 0 obj <<
+/D [1340 0 R /XYZ 56.6929 645.0635 null]
+>> endobj
+1339 0 obj <<
+/Font << /F37 747 0 R /F39 863 0 R /F21 658 0 R /F23 682 0 R >>
+/ProcSet [ /PDF /Text ]
+>> endobj
+1345 0 obj <<
+/Length 1074      
+/Filter /FlateDecode
+>>
+stream
+xÚåX]“Ú6}çWø:#­%Y¶5yÚlÙ-™†´„<Q†ñ‚`Õ›H¢òß+
+vjÀµíê@átRl÷â‰q”u½Ë.ÝÄ`óU€d”â"ÂP„<k)-E4:zà8PšËd8Ærè¬û/›ÚšÏôBϦ�öá¡"ÞßñTFAxCà9�ƒ5ƒ8
+ç‹¡�JâP†Ã¥Êî¿g—ü©˜ô‚Á@æ}“XêUrÓÝø„pù½ôòã	Äl(Ác ÎsH:Z�'à—ŠH›?Ø"2çªË^íÌ,8Ô
©¾¯¶1¬
+•Xœ"}ç+Ÿg-Óè®À7ýß1žÙï“-Mf™a<J¼ä’DÓñ#—'(;Z‘r	ÄÀÌ„öÅS}9%-ƧP:
+–"Ë]ígÒJeVµ>_ǹ˜8…H^¤Èc�`�$è9ÄI�~IQÈ<ϵ
+ýëx>´eü’=3¨Tñ-žà·HÕ}M•y»f‹Ì¨ÒTéyT±M &+•458IÖÚ›pe#J�åzPZŒDží¾M`ìAäø¸4
+¦Šƒ�ò®&âaŸMàã‚Þõ ñ°³Ë;ô"ï �@â0v˜åá�_ÏŸ·˜�Aœf�%~y‰#”´ÙE_�°oØ;tpvV16é€äCÉÕSº¸Ÿ½k�RÂDËù)�S!6M™†Z€lË9×!/\Æ ŠM@ëð0À2”.»4“¾äßX>Nz“ Y‡O/
+–†vúa Ô*õJל2X=Ÿä#žL:ø®L‹]æžä!IeRاOW®ÿÄû_Ab“ZÏZ“²G‹a Â…E±ä¯R¾››ìÚŒóÙOB>æ‘æ¸OgTª³s©ÎhKg¥§�ûÄÂ0~ߦ\Î7çd©âJõLñÕ*$Í?ÞLÉ}3ãòZôJArJýƒ®\ÒþŒeéÏUÌ�[†]­xBÿ‘:äÊ	óv‚¯X‡\;YÞªCÐÿ¸¹*ݲCWBarRZrDjþ¹IÈ®O«Svø>^�µbR8k%¶}̼%©ÄD—m3_�ܾ¦þ/
$þÇendstream
+endobj
+1344 0 obj <<
+/Type /Page
+/Contents 1345 0 R
+/Resources 1343 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 1338 0 R
+>> endobj
+1346 0 obj <<
+/D [1344 0 R /XYZ 85.0394 794.5015 null]
+>> endobj
+1343 0 obj <<
+/Font << /F37 747 0 R /F39 863 0 R /F23 682 0 R >>
+/ProcSet [ /PDF /Text ]
+>> endobj
+1349 0 obj <<
+/Length 1975      
+/Filter /FlateDecode
+>>
+stream
+xÚ­X_sÛ8÷§ð£<S±¤Dý›<¥Ý¤›�mv/õ¾\6Ó¡m:Ö­,yE¹®ïn¿û
)Ë©ÒK¯7~ ‚ ü
+É.’ér;áÓGX{7N&ôBáPêÍ|òú:Φ+Ò(�Î×]9ãy.¦óÕ}�²ˆÍ@Þþr{}óî·»ËY&ƒùÍ/·³0Jxp}óóQïî.ß¿¿¼›…"ODðöÇË_çWw´”:onn NAÃ3Jï®®¯î®nß^Íæ?M®æý]†÷<Æ‹ü9¹àÓ\û§	gq‘'ÓL8EM·™Ä,‘qì9ÕäÃäo½ÂÁªÝ:ê?ÁY§Ñ˜‹�sÎRª²¤`iÅÖ�÷³0å<تª»VÕf­ÛÐ4ûv©iñ¨ÍǦýX74ÀkÃÙ¡¬H’h¨èŸM­CÓ©®4]¹4OÐôjVªSeœ
¦kËúñk›Åpó¶¬ÃV¯[m6aWn�’z¿]èöÅlÕçÿƒkI׿I…øÒŽoUqnžêÊp«Lç7}- a³Bpy®ê¯
+r*Ê‹@Ñܤ—ÍîHT³&¡Î«ÀrOä&ýšƒ
+ê´H
+Þ‰·ÒkÍÊ+Š¾oFÝåÝ[À¬FSM‰¾s3ÐëeQ�Äı¯
+Ί
+ \@.päÆøteعp‚Ë�ªõŠ&T€P¶�Ø)°À]Çgq·>ÚV6–±Ëĉß×!w¡×=ÎpÍŒ#dY!hõ
!>ŒS­•­IV�9m§í¾°¯ä‰ û¶®
+ì¡@õ†àf8@Ó5†‡PUEª4£.#dbÄEB¯dÌ#g[Õ@¦8Î)9pæl
+endobj
+1348 0 obj <<
+/Type /Page
+/Contents 1349 0 R
+/Resources 1347 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 1338 0 R
+>> endobj
+1350 0 obj <<
+/D [1348 0 R /XYZ 56.6929 794.5015 null]
+>> endobj
+454 0 obj <<
+/D [1348 0 R /XYZ 56.6929 493.3884 null]
+>> endobj
+1351 0 obj <<
+/D [1348 0 R /XYZ 56.6929 463.2745 null]
+>> endobj
+458 0 obj <<
+/D [1348 0 R /XYZ 56.6929 463.2745 null]
+>> endobj
+1352 0 obj <<
+/D [1348 0 R /XYZ 56.6929 438.8631 null]
+>> endobj
+1353 0 obj <<
+/D [1348 0 R /XYZ 56.6929 438.8631 null]
+>> endobj
+1354 0 obj <<
+/D [1348 0 R /XYZ 56.6929 426.9079 null]
+>> endobj
+1347 0 obj <<
+/Font << /F37 747 0 R /F39 863 0 R /F21 658 0 R /F23 682 0 R >>
+/ProcSet [ /PDF /Text ]
+>> endobj
+1357 0 obj <<
+/Length 3410      
+/Filter /FlateDecode
+>>
+stream
+xÚ¥ÙnãFòÝ_¡·Ð€Åé“öÉ™x&v<Y�»@’Z¢,&©ˆ”=Ê×o]MQ�Iv`]¬¾ë®j鉂?=É|¬lî&iîb¯´ŸÌÖjò}ï/´Œ™†AÓá¨o.Þ¼³é$�óÄ$“‡Å`­,VY¦'óŸ¢·ß_ÿøps95^EI|9õ‰Š¾½½ûŽ197o?Þ½»}ÿïûëËÔE·ï}óîæþæîíÍåTg^Ã|#+¼2áÝí?ozýáÃõýå/?\Ü<ôwÞW+‹ùýâ§_Ôd×þáBÅ6Ïüä>T¬óÜLÖÎÛØ;kfuñéâ_ý‚ƒ^š:F?g²Ø'9@&Ëc¯�{}_ÞCÁ¾šÄÆJ¡�÷�j­ŸL¦^¹8ÏR}àJ>àŠvyl’®ìó8±Æ[Ún÷ˆ´yó‡ÁI§Îàþ8èHiSPýÑÔ%ãªVúªuµ*¶ÜÝ5Œ,¤oU<—‡‰WæQùyVn:Ñ-�ªŽn/u•›U5+ºRöhêÕÏ
+§‚[ǹ÷†Ž×-aukòèLž5ÔÎ[îlÜYðçºh»rË(¾b«°ÅüxF¿~Yw¯}˜‡rè’è“Ðñôl8�¯tT„©F©¨n:ÁòwÛõœG̹cSl;îÃs †Î�ˆïî>ý£Gí7X½_tQÝnˆo7å¬úY)3;>+«(±
T†÷ñCõ¬Ö›U¹†û]ÕÔñØM‰@îl��fE͸ǒ»¶œ3wCL¹Ñ©�Ë‚^
+P—<ÒG‹f˨§ÕN–aN»N�«Âh’E«¤*M©;F롧
+.Hú{¬ìIg&KE�q±y<kêň®ƒ9HÁ&ÈP�gkmô°¬dý][<ÉI
+�=êU¨Î[™>kv«9ƒO%­v	M¨—ª[†qõtì "¤U&MøVzºjËXæ/Bx0ìdÚ
"Xtštð$yÈHd°c„8Ì8p¿Ÿ Ù.iYĬ«Ï¨‚v
ÜxIûÁf2âçE,qÏ:ÂWüYê��èÞW(º­¼¬FÅ} ÀV¡¶ÊR–ö±&ªPØça#ö œ›žd†Íÿ0áˆP½£DhY´0›FŽ(ò©Üá^~ ó´îÏ©mT¬VÜ/.Îõ1ƒ
+¼lÏÌŽ<:#tÈ¡§XµÍWÙ³�§�·ä͆¾¯û«zAD$ßÉ«þN^�Ýéϼ£Êzï {G
+ƒ†ç2Œ!fŽjÛ;öó	xÞã
t·ˆ
+N0LîÃͧP¾yW<¢	p&çOjŒy¬ŒÊ{ºõÊÅ.ÍOïD1¡q2/¯Ä+;Hø0·3Î�»ìE/²m;ö<8¹kh¸A¥õÆ&b↲8ÐÏÕ¬äY*Wc’ô¸ë¸®Â|CˆÌ–N$ÂÑI¨Ú$·Ô1hÔÛ€”žVHm8“òš1$Håi°
‡Q/H%µÅþŒ�ÄËùäÿµpgD|edrwR
.õïDP2áõPGÁ
+,M¼Û ”ÏÕlDpµn8wx“œhF4ÜâÁ©H¨s>íéºýˆºô§ÂÄ…V
+bê†ÛÇ]µê¦\½=e¡U|ŽìøŠÝhäW)ùÁjd—Äü�ÃŒWí†ÑY¬ûÚÓ”Nb›åÉÄ`j™©Tˆ°*Ÿ¨4<
/?'&DÃÝ�÷&„�´‰BËE„Ø5›¨¬C¹„u�%è9Ý��Sìd1vÙ°x½Øm·½„¨aÖ?¯üùÓzX|KˆŸ(òuÑÛ�®¸ëîæ
Ÿ.¯¸î÷ñþ=:¤˜û®ëð¸S·/\^Ô!Æ"¡¬ô·z†-Jy>Âh½Ùuã‘Çmåg|_£Ê9äŒ!ħžö@é­�¢Á¬Ïû÷Œo!,”ÁY¦Ž=ÜñɪËëÜ�—Ö¹�îþûÝÇ×·w1£™³Í›R†ÐkÍádAä2öÑáJ±8ªüL´×¼Ú˜XrUŽŸç
+dü°þŒ“Žó×°ãiúú¥ˆe¨Ó_g'¦çðxþÅ×x˜ãsüÿM
+Ç€Äänå IåÊSxÃ?{Ë·
+_ØrÌú3ç:=üâ(x?4Ð.�ÓTs
¿
+½ã:X{@ЛÐLä6¾>Ü>|#KþÈ¿²QÄ5æ‚þ2šè¶;>Àù/
+`c¿G‚¡ðWÿúéðÓ0Ð8›eæ`�¤3M9Þ1ÕgþÅf±ÏL:rôÿ
^܉endstream
+endobj
+1356 0 obj <<
+/Type /Page
+/Contents 1357 0 R
+/Resources 1355 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 1338 0 R
+>> endobj
+1358 0 obj <<
+/D [1356 0 R /XYZ 85.0394 794.5015 null]
+>> endobj
+462 0 obj <<
+/D [1356 0 R /XYZ 85.0394 167.2075 null]
+>> endobj
+1359 0 obj <<
+/D [1356 0 R /XYZ 85.0394 139.8789 null]
+>> endobj
+1355 0 obj <<
+/Font << /F37 747 0 R /F39 863 0 R /F23 682 0 R /F21 658 0 R >>
+/ProcSet [ /PDF /Text ]
+>> endobj
+1362 0 obj <<
+/Length 3030      
+/Filter /FlateDecode
+>>
+stream
+xÚµ[Ksã6¾ûW¨ö²rU„àI‚GgâÉ:•ØY�sØMr $x̲D*$5Žóë·Á)‚¤@§â­)—@à#ú�
 Áa
+ÿØBE$Jx²ˆIej±Ù_ÐÅghûî‚9̪­ú¨o.¾þ(âEB’ˆG‹‡Ç^_šP­ÙâaûË2"œ\BtùáîöãÍw?ß_]Ærùpsw{¹âŠ.?Þüp�¥ïî¯~üñêþrÅ´bËÿºúéáú›"×Ç77·ßbM‚?g:½¿þx}}ûáúò·‡ï/®:[úö2*¬!¿_üò]lÁìï/(‰V‹x „%	_ì/¤DI!ÚšÝŧ‹wöZ›W'ýÇ(á"âäbÊ�*!‘€&ëÀ«¼¨ŸL	viµüñæÁärk¾˜]qØ›¼Æ–¬ÂßOiQå¦þ
+±L±ö‡«[|ïP^2½,êbSì°iÓÔ˜´6[×SŽP�Šûl»bIL+Éäò¿EîZ¶i�"ø±pfNŸMš[߃VŒ‘D)ÞX³68@ÕÁl²_)å�T¨xÉê',Y¹ð&�+éù&
7Sm]j»
rÜ}B”çAÁ‰ˆaµÙ¥(�0Öƒ­WDë(Z¬DL„U¹$H)mÍ�îuVäÕˆKŒÄŒE‹(fDqynì´ê£pèÙÄÐw(«PºÛ/+ÿìñu(œ1A˜¤qXz‡šß÷cš0Î}ñŸŒ9�HSØšjSf�7°¢xœðnÊ¥vƒ04bÈyM¡¥gùÐNàá±`ž�ØX~^`á¾gq‡Ÿ±xÜ/š¼9gùÀ""‡*	e	Íg¾CÍ(2îÍ*BÎ’MB ‰ &[ [‹:�ÓïGSNp�*dÞ¡&¤û\~°Høâß“l�C®ÅD¸&�XìÙäšÃÏX<î÷í\“	‰%ãa×w¨Eƽ…¹FXòt<õ*Àµu¦ºLóê–¶!Ý8…à‹dP~‡šPÀ£›
õÑPƒ÷¤[ߎ�ð¬�q–q‚R+™x¦×ágŒ÷ûvÆE1‘BŠ°÷;Ôœ"£Þ‚ŒS1l…ša\užqê4RÇìXÌ8¼Á ÒH†¥w¨	ñ>ß žë8öåÿ=¾%ßNVÙƉ¦’��o°‰¢TúnÅ·?cò¸ß¿°–ÂVWƒÎAßw¨Eƽ…Ù&#¢c®gØÖCØÖ¢¬D¡Õ¡Øe›‰Õ‚0lñÃâ;Ô„|Ÿnfz,|>uÛë
+ýŸâϯœËOÙþ°s$„1:âþŸn·(|v0ÆÀ‹+ÁhCäá
+p•†=\_ÓPkñ3¦�û�¤8`L+8‚Jˆ¼aw¨9EF½…iʼni2G«*@«5œþ+8q½¤å6Ë?�IMápT¤CMhâ,Ž`úfýâÙÀ ‰M£JôùØ&)
+s‰%�c6æ*À§uØÎn7px§rá\DYX|šïqK0"4Tyòßç :¶b <昽<›È… ÃQó4”iñ3F�û};Ób
g!ÂÎïPsŠŒzò�k
JɾõQçùÖ¡N#•åµù\fõøj'Uaù-hB¾O8J¸Ž„¯À{Î3cÈ8F
\VÁ˜D”iÏÔàÕ�ÃÏX=î÷/0Z4aïw¨9EF½…§l~žñÆõP
Ƶ¨ÓPUÙz7•k³ç”ó°ø5!ßß'BµP¾ï¹€öÌ^¢“$	\(�ó,
^8üŒÍã~ßηˆ«™±ïP3ŠŒ{óÍÞ+Âz4÷*À·Õl<MiOª«ªHWu½G8N”T"¬@‡šÐÀg\L”=ã{*¼ã&rNÃñQ°@Œ“0¸òl
Æ8‡Ÿ±zÜï_ˆq”ÄKÂîïPsŠŒzrŽ%’D±šÉôQç9סzV#ž«çéœk¢dFƒ5¡‚G:ɉTt Ãû,¬S–Äk8~EqàR^’
+ÄMúÏÖ5	[¨ŽëÊü~ÄÏf“ž–×]†ÃÃ!­š1n<Àç£ýð¶U£«ãš×f*ÿ6ò:ǤcÿÒþ%}|4»q�²Ì“ä.£×
+M§qì¯!Y/Ÿm>Öoï“Áh{
+ùG¹®ÿ1}¦uwf?=–¢ýVzNþyÉ––óÔ]ªY‰ùjoöEùŠ�è…íj½K!v×øØjê,k.Üb—:æÞ$m`…iå5Ò(iNî‘ïö:}vNòtà-¼b½sB.¿¤»#¦Xʼn*¶áPTvgm°){ÄÚt»ÍlxOwXß(r¹-3wMO6%ÙT¯�ɱ6êϘ––'Öº€%Ý]šýî½I³å§b?àƆ*=}ðÑ	=ÙnZÒmvÇíôçØøjfcÕúxZ° Ü^”äf¢ËÖ€>§×¯^*•œû@_("§oàÏ�äßþxÿô?¤ýüÜ.�Û܇¶¹TÊ:5æãÓ}å?Vý…endstream
+endobj
+1361 0 obj <<
+/Type /Page
+/Contents 1362 0 R
+/Resources 1360 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 1338 0 R
+/Annots [ 1365 0 R 1366 0 R 1367 0 R 1368 0 R 1369 0 R 1370 0 R 1371 0 R 1372 0 R 1373 0 R 1374 0 R 1375 0 R 1376 0 R ]
+>> endobj
+1365 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [284.2769 667.7189 352.9489 679.7785]
+/Subtype /Link
+/A << /S /GoTo /D (access_control) >>
+>> endobj
+1366 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [282.0654 636.5559 350.7374 648.6156]
+/Subtype /Link
+/A << /S /GoTo /D (access_control) >>
+>> endobj
+1367 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [299.7586 605.393 368.4306 617.4526]
+/Subtype /Link
+/A << /S /GoTo /D (access_control) >>
+>> endobj
+1368 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [292.0084 574.23 360.6804 586.2897]
+/Subtype /Link
+/A << /S /GoTo /D (access_control) >>
+>> endobj
+1369 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [330.7921 543.0671 399.4641 555.1267]
+/Subtype /Link
+/A << /S /GoTo /D (dynamic_update_policies) >>
+>> endobj
+1370 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [401.5962 511.9042 470.2682 523.9638]
+/Subtype /Link
+/A << /S /GoTo /D (access_control) >>
+>> endobj
+1371 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [257.6971 346.6843 326.3691 358.744]
+/Subtype /Link
+/A << /S /GoTo /D (boolean_options) >>
+>> endobj
+1372 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [310.7975 315.5214 379.4695 327.581]
+/Subtype /Link
+/A << /S /GoTo /D (boolean_options) >>
+>> endobj
+1373 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [308.6055 284.3584 377.2775 296.4181]
+/Subtype /Link
+/A << /S /GoTo /D (boolean_options) >>
+>> endobj
+1374 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [294.1999 253.1955 362.8719 265.2551]
+/Subtype /Link
+/A << /S /GoTo /D (boolean_options) >>
+>> endobj
+1375 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [303.0862 222.0326 371.7582 234.0922]
+/Subtype /Link
+/A << /S /GoTo /D (boolean_options) >>
+>> endobj
+1376 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [332.9347 190.8696 401.6067 202.9292]
+/Subtype /Link
+/A << /S /GoTo /D (boolean_options) >>
+>> endobj
+1363 0 obj <<
+/D [1361 0 R /XYZ 56.6929 794.5015 null]
+>> endobj
+466 0 obj <<
+/D [1361 0 R /XYZ 56.6929 726.6924 null]
+>> endobj
+1364 0 obj <<
+/D [1361 0 R /XYZ 56.6929 700.1172 null]
+>> endobj
+1360 0 obj <<
+/Font << /F37 747 0 R /F23 682 0 R /F39 863 0 R /F21 658 0 R /F48 885 0 R >>
+/ProcSet [ /PDF /Text ]
+>> endobj
+1379 0 obj <<
+/Length 2951      
+/Filter /FlateDecode
+>>
+stream
+xÚµ[ÙrÜ6}×WôÛ´ªÒìË£ãÈ¥&vFVj¦*ÎÕÍ–SdO/R”¯Ÿbi® <qÊåj8Ä]pp
\Pd�áYh�03|¡G±X?^àÅ=´}A<f@«6êÛÛ‹¿¿cja�‘T.n·­¾4ÂZ“Åíæ—åÛ¼ùéöêærE^Jt¹/¿½~ÿ�«1îçí‡÷﮿ÿùæÍ¥âËÛëï]õÍÕ»«›«÷o¯.WDïSßÃÄï®ÿyåJßß¼ùñÇ77—¿ÞþpqumiÛK0³†ü÷â—_ñbfÿp�3Z,žá
#b]<^pÁ�àŒ…šòâãÅ¿b‡­ÖæÕ1ÿq¡‘ \.V
++½Lɘ—ÊzySdåi×7–ŽQtÑîq 7¢F³–`BÒÖÄŽä�yî~|ð…M~Xï‹Ý±¨+WQo­b=3ŒB˜r*tõï	e1	2¬¨ú&R‰WFuLt�ûû…+Ü´Œ�øc‡ý:c×g³,‰D¤¯£
+af¼Q3Š{³Š 
¯=y†A¢s;ƒüò fxò2¿Ï¬é«º*_<m’Âf(¼Ã1I�Q¸+ý¶a–‘ËO³ìޖŲѣ©Ív»²ÈîáX»ß‡¢::`Vm\Õáxºs¥?ê*?@ á\-¯·¾5÷xè¡¡!×m:0ƒ'ÒóðÄ
¹J2tv˜o.W+;-*¯Z0Êw²ž‹²ôF”¯ù]n»‚€°ÑÚNPd„ M¯Çý%ÑË<;æÇÂìà~‹­ÿ=ú__ï;¶¥0=»cé&ïËÎÏ^«Ü$»¤„A4Œ¤éÕFMó+¢¬YÛzÿœí7bQ‚„"&-8¢F$wƇJ$„êŽè�ËÇ<«Šê~{*í3o\jë›�³7p¶éÁºÝVeîÇéo‡f“ïS‡c³Zñ†ÁÃî†-•'L˜YýHÄ�&ŠxÐÄI¯Í:;r/+ªXÖõg¤NïÚ5n³¢tœ¢† Âér*Ûó=Œ¾ì_À¶L<_¡²oœmt³
+ïóã1¾RÕ®2«ÏÐ%,ÍßØ
+¹|~(Êq$µfÞ:˜àt8Žy¡Y^ƒžëSéågeY?{�\MUï³ÒUw4¶Õ®.L0ª(lS$Î ~‚ùfzŠ¨Û6$ø%èïA-ö[çö'
+{W™ßØYlYß»–OXàßêÓ¾ÊJ(’P‰ié{mÆÝVn^@@±öÊî6°>;vÁžY1¡ºär”�dyýŸw7ÈÁžK²üÎ=÷SÜC,k(qpŽB2ÐÆUÆÞÖ@$Øèåi}ì¿àì·UÍd:7‘¥·Ðá‚u¶áîÅØíòÊÓ?QÊÝäb¦5ŠœR$…	!…Ùåk;+ÎoU9»jĸ‰S÷&�7Æ-¦æ�³dzâÀ©G¨Ù‰ÓB%&N@u&Îñq·òîìOn�’tF‰ˆÑ¢ã6.Q¬§Fœ>.ùPRmêõé1¯âö±n�Ó
+ÿ{>�k '#xy‰¸™‚šIOsÍ�4š§=ÝFM{:¢yâN½Q§í¤àˆ‘Ü
NQ*LWô¿ëÐai
+kß6;•GWëuûÛÁ=:xÞ¶¡´nö"ͯ_v7ye�%Xø3´tzmVûzhµtŸ’ñ\|”1Ý985�á”FÂ~�OTp‰!pHëOT(ìjÕ°æö!¬”ñ0b�jëì®ÌãÌ.ç„+$%Ý?f»=M
˜óªo£àH_° Ì9”ÙS>f�€ ÍÊŸ§Ø³RK&fØÜB%ØPÎÎßWÍR´Í}ü(óÕ0ãA”¶vó´&5¢J‡ÞÀjƒ•îêòç’::ŽÜ´E=5ŒDL)5™æaZ#n4í�HóDüŒùÃ~§Ò<ª¯6ì‚ÎÉqˆ¨E†½%Ó<ëš©¶P	Ô蘛rœ…°k†ýZZ“ˆQ¥ËB{.µÃÐÖåë¤SõYkš`!„›‹k[“d¡ÇϘ?ì÷õ,ä°wfZ¦Ç!¢fö–d!SÙu IÂhšƒ
46êÓqÀAÍ—B&õˆ ¡"]»
ÓÑä/"`Ûž¾Vh"Í4��=žm›Sð´õƒ^_Ï?	-3C0iú=¥™Ça÷FùL"¦�Jp/ ¦£Å(ùlåŒ*5¢K—~I¥zÊüEËpÛ¤~´inÅôãà4%:V'ùçñ3öûýb¤ˆJ�C
+êܾœ•ÉÎJ[Ãp7¦ƒß»-éæ¾Û‘Â
×4‰1¬áffQn�ö �ZŽ0l‡c±ÞÓÁÁ‰Ú£cJz
Åwˆ,줅ֶüëíÈW	pX³aæÿù&!|ô°j®~¡|þásžïÂ'ÞàÌ7ÕÖÞ®zòB…cvóuCq8ÞÐÒöÚwýàj×Y¿oh~7§Ç]¾qtWiŒ{Wpí´ÿÈͱB\ËÜÏ#ÓJ¹÷—8á‰øÆ&·ÀªŸÐŽ,‹®9_ÒMRŽð²Ä3q³�š&]D5f÷«§¬,6Åñee#Òþi$ß­Rh•T#¢FôèžD€tX×Qäë¬×“æó0”‘ÌÃP
+ûô¶)3y˜?cû°ß×/Üö;@p¯H�BDÍh2ì-¹p˜
XÏebÚ¨
Ê}
Ñ:7êÓ~=¼Ì6Ïg”ˆ¨-ºÁìÅ¢§Æס߄1=
FpM�l¥{Säøˇý¾þŒ™½
L�@
+ýžÆ™rrÙûG¤Á.ûÓ?pþã
+®³´qßa‰45*(eW¬¯¹`Ž¾T�¨þ?탄kendstream
+endobj
+1378 0 obj <<
+/Type /Page
+/Contents 1379 0 R
+/Resources 1377 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 1392 0 R
+/Annots [ 1381 0 R 1382 0 R 1383 0 R 1384 0 R 1385 0 R 1386 0 R 1387 0 R 1388 0 R 1389 0 R 1390 0 R 1391 0 R ]
+>> endobj
+1381 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [259.4835 736.902 328.1555 748.9617]
+/Subtype /Link
+/A << /S /GoTo /D (boolean_options) >>
+>> endobj
+1382 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [387.5019 437.0578 456.1739 449.1174]
+/Subtype /Link
+/A << /S /GoTo /D (zone_transfers) >>
+>> endobj
+1383 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [381.9629 406.178 450.6349 418.2377]
+/Subtype /Link
+/A << /S /GoTo /D (zone_transfers) >>
+>> endobj
+1384 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [398.5803 375.2983 467.2523 387.358]
+/Subtype /Link
+/A << /S /GoTo /D (zone_transfers) >>
+>> endobj
+1385 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [393.0412 344.4186 461.7132 356.4782]
+/Subtype /Link
+/A << /S /GoTo /D (zone_transfers) >>
+>> endobj
+1386 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [255.0796 313.5389 323.7516 325.5985]
+/Subtype /Link
+/A << /S /GoTo /D (boolean_options) >>
+>> endobj
+1387 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [311.5276 282.6591 385.1809 294.7188]
+/Subtype /Link
+/A << /S /GoTo /D (tuning) >>
+>> endobj
+1388 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [381.2254 154.1545 454.8788 166.2141]
+/Subtype /Link
+/A << /S /GoTo /D (tuning) >>
+>> endobj
+1389 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [335.4973 123.2747 404.1693 135.3344]
+/Subtype /Link
+/A << /S /GoTo /D (zone_transfers) >>
+>> endobj
+1390 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [363.1733 92.395 431.8453 104.4547]
+/Subtype /Link
+/A << /S /GoTo /D (zone_transfers) >>
+>> endobj
+1391 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [365.365 61.5153 434.037 73.5749]
+/Subtype /Link
+/A << /S /GoTo /D (zone_transfers) >>
+>> endobj
+1380 0 obj <<
+/D [1378 0 R /XYZ 85.0394 794.5015 null]
+>> endobj
+1377 0 obj <<
+/Font << /F37 747 0 R /F21 658 0 R /F23 682 0 R /F48 885 0 R /F39 863 0 R >>
+/ProcSet [ /PDF /Text ]
+>> endobj
+1395 0 obj <<
+/Length 3132      
+/Filter /FlateDecode
+>>
+stream
+xÚµZÝsÛ¸÷_¡Gy&b
 �ö)—8©¯=çêø¦ÓÉå�‘(‹�DêDÊŽnúÇw‚¤H‘î\:™˜ °\ìÇo?@‘Ïüã3‘	Í,62PŒ«ÙrwÅf�°öþŠ;šEM´hSýðpõ§w"ž™ÀDa4{X·xé€iÍg«Oó(ƒkàÀæo>ܽ»}ÿËýëëXÎn?Ü]/BÅæïnÿ~C£÷÷¯úéõýõ‚kÅçoþúú燛{ZŠ�nïÞÒŒ¡Ë¦÷7ïnîoîÞÜ\~øñêæÁëÒÖ—3�Šüvõé3›­@í¯X ŒV³g¸a
7&œí®¤�’BÔ3Û«�Wÿð[«öÑ!ûI¥Ê,š…ÃFæAÌ9ÐÄ’ƒŒ¦1rȇŒ\S¡‘“mµ¨I^®ÓÃ5×óEYËtñ�ëÏA\!á±ö.=Y<Õ€0¢%Å„`º+ÍÇ4%/T7X¥åò�í«¬Èi¢X£`gª™8`¡4 ´Ng‚p‡îÑ,?W[D
+äk
+úÐâáqFƒû–
<ý„
ú|É
+wÌ‹*[Ÿ.a�ƒƒ§v¯‰vïø;„U‹îöß'	ö”8Û;‚zÂaÇKP�
+h%Ǩ‰è
+ã ÆUÏÝÐ�…Ø3Œû»¦š�¤ÏmcÊ
+ô}:ºIµÎÏq G�œÄºŠ�/ý„	ú|/¥<Þ‘Ð@k
+‚NÒ¢Ü#fŸÒíéšsN¸
oBíÔ²´7F„ô
+äaXCÄB½P?ÛŒG¼Ü&Ǽ'X<._KZ�â Lvõjr¢Aâh ÐáÍ÷¤ÄSVÝÊSz(AGw‡Â+"2 ámEW+GöÈiXƒËšAC˜°Htá³Àk—•¥x‹#¸[A“䧶µ—…½®|ìåVceùY
+E Ö+zÌ+_ †/G‰d¡9óK(Ä<+隧Ïnaã0cè‚h¥
bÀ=¶#}3Œž<]€å³<uÔT•¥)¶Ä¸
+äqeM(4øP‡Ý×RmÇê€ÒÐúŠû´˜Øȇ5b1O¿%ˆó’æ):`ÚG¯i.¡[—þÒÎ&øDA½Ô2%²dµrz•D�¹=ò¢rx
+6vñDmÓ§Í1X$3—:êë¦xîä�V&ÇP¶¥*kšùmQ|-ÿL&æ¬õ5�Ö1½¿ÂŒs½ˆ �¶€†ÿ¡ä–�(%á¨I8x‡é¼:íÓæŽFŸè‚K%
?_èÂ[¢ÜP•‚Ðlt‹¢¦2aˆ»8ö•)–*{ʶé#³ÒóùÒ=šÐ¥Éìðè&qÏ•Çå IPÚ
+•“:J
é²¢1%6ä]×ǃ«ðD«
@Ú¦šáØBÈ0²-Ì6v„J º¥%L>câ³#W1M}Ü›!û¤=„Äõ9F·KLÛ°µ­¬y"×(ʸÍįÇ~]×hÚ–˜L–uLȹ°ö5u€Á±Åɉâ'ç>ò¥Ò=gª%l—R‡e[U;p¨ùm˜9!.vÂ=š¶tk/g²„ˆƒYÁLB·ÏÙvµL|×îl�¡ÁÙü_KlÝÑé=WQªA1º^él²>[ríKkÿNû2€ž¯©=ü”dE#¬(BÎÍÐYÊøV
Ç­V
ñ
¶õÚ®%tyøÛÍ¿h”~[n’üÑ=j£·€âMqN7gÀuI{ø-Ûr“ø³³4u„P�/�IÈv–Ä;{¨“¬Yî°•m¶îñÒ=
+Â2’á´I„ŽDϤ°Ýîh�= žgJ`”\`ÎÖÄÅoÇdÛJs`™b—Ø÷Zî�4…ZAÿÛ;á
ž'†µáKßÁù>¬çÊ0WÒñ
&]ž’-䊡æGó@o:›Þú;adžßÅÑ«
620š×˜`YÃäCBèOu8ŪÞË¡p5q C¿”S™n×U“ÿPoHh)¸gä^­8†lî?D–¨æ¤Š½_#8¨ÀŸYh‹„yÉwËBê Æw̓ß-ã§È¿ˆQ ðÞ�×Úðß…ûþLºù†4Z_ú)N R‹p&T
+endobj
+1394 0 obj <<
+/Type /Page
+/Contents 1395 0 R
+/Resources 1393 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 1392 0 R
+/Annots [ 1397 0 R 1398 0 R 1399 0 R 1400 0 R 1401 0 R 1402 0 R 1403 0 R 1404 0 R 1405 0 R ]
+>> endobj
+1397 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [364.6945 737.8938 433.3665 749.9535]
+/Subtype /Link
+/A << /S /GoTo /D (zone_transfers) >>
+>> endobj
+1398 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [374.6372 708.0059 443.3092 720.0656]
+/Subtype /Link
+/A << /S /GoTo /D (zone_transfers) >>
+>> endobj
+1399 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [292.0276 678.118 360.6996 690.1776]
+/Subtype /Link
+/A << /S /GoTo /D (zone_transfers) >>
+>> endobj
+1400 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [319.7036 648.2301 388.3756 660.2897]
+/Subtype /Link
+/A << /S /GoTo /D (zone_transfers) >>
+>> endobj
+1401 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [460.1655 618.3422 533.2211 630.4018]
+/Subtype /Link
+/A << /S /GoTo /D (tuning) >>
+>> endobj
+1402 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [362.144 588.4542 430.816 600.5139]
+/Subtype /Link
+/A << /S /GoTo /D (boolean_options) >>
+>> endobj
+1403 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [293.1435 558.5663 354.3435 570.626]
+/Subtype /Link
+/A << /S /GoTo /D (options) >>
+>> endobj
+1404 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [288.6803 528.6784 357.3523 540.738]
+/Subtype /Link
+/A << /S /GoTo /D (boolean_options) >>
+>> endobj
+1405 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [328.5503 498.7905 402.2036 510.8501]
+/Subtype /Link
+/A << /S /GoTo /D (tuning) >>
+>> endobj
+1396 0 obj <<
+/D [1394 0 R /XYZ 56.6929 794.5015 null]
+>> endobj
+470 0 obj <<
+/D [1394 0 R /XYZ 56.6929 484.6014 null]
+>> endobj
+1051 0 obj <<
+/D [1394 0 R /XYZ 56.6929 459.8194 null]
+>> endobj
+1406 0 obj <<
+/D [1394 0 R /XYZ 56.6929 84.3175 null]
+>> endobj
+1407 0 obj <<
+/D [1394 0 R /XYZ 56.6929 72.3624 null]
+>> endobj
+1393 0 obj <<
+/Font << /F37 747 0 R /F21 658 0 R /F23 682 0 R /F39 863 0 R /F53 962 0 R >>
+/ProcSet [ /PDF /Text ]
+>> endobj
+1410 0 obj <<
+/Length 3082      
+/Filter /FlateDecode
+>>
+stream
+xÚÍZKsãÈ
¾ûWèH§¬^ö‹�Üfg<»³µåIdm¥²�%µ-f)R+Rãq~}€š¢dÉòij•”l¢Ñ/à
+©¬�µYs¼`Ym2‘Æé‰eãÑXi‘ËØœž‹ÆÅ07i„>˜
+$˜
+cST£¶"U2ß©1¨Q-2­í(µR¨TŒz¬‹•C)ó^é
s‹\i\™®?ón¼*ºùòr¬SµnUÔ]9oAkIGÓeÙRÏæ2‹¶•£?ÂqÏÃÒÕØ2Q·äþ°8ÊCJ‘[«üz3WÖ÷„‚ízQtnA/¸ˆ.®^TôÚ5üÄy±1oê8˜»¹Ûuû“ÚáI•Di˜Œ�zB*
+ä2
+Óôð;ƒ‘ß&CàŠ›ºz„dŽÑ(óU!4ÐÍׂ 2K¬ý‚)È“JR+r“ÈsŠµ0Fû£?”Õb^l/
+—›ÎÔóŒñ[žâ>Ïݺ£ºeÑÑì}tÌK7wGV“2Cù©¿ “™÷È©ZN{fn/Uz*ü§%`0Âè\Ÿƒ
+WÎÕ”!2/„ŠŽ‡�YÌÁ<{¨àËq¨@¨o­9•Îz
+¶šºzäE ñ=Ç@3–ʈ<µzß�?ƒÕ>×è!ór 4ðµ€²+°üw¥“×\$ÄE:�lHé|XéyRñ�ÛFd*‡ ÞJ	'æPŽ2y*ÒÌ�J>ôZíüw{õ\	v™i©¾<¤IWÛ¶£–¿¿îyô€ð¡zÿ±…” ¿Ù€ÌY¼o㊂b1p…`-
+Py�V鎮ÇÚ_ѧBÀÒ©aÒ!רÊyÙ!²®S<¿Îí¦q42îŠÐC‚à ,“îÜ-�'“Ûß]ýæöŠˆ·ß0	33Oº¹½~+ˆ6½ÌãÈÏv$
+Y�¡àÀ…½(
+Ö<²?4ûã
3nû*”GJ¬¸a“�öà>¹M¿ß#‘[7F>pÊ£›¦Ã“™<ÜT&•hù‰¡¯è:·Zs·×<WÅÂQËÙ€má*×1�Ž
ÁœâúE˶m3/¹nƒK–Ý’ÇÑ#ˆÓoÌ…™<,ÂŒ®cIÑÒÍ
+ºuW�À0ï-Û®/#îo�mä/ØÐÀC¸Á÷�¥ÅXóÅ)¡?Ò³8Ž£Ÿ}xí‹ÓeåvCöüP‹$•ýP!yðƒ{‰øĵÍv3wá
ö¸`B24þÁe²]©ó§–@P¼:â,°À÷…‘fxía„â Ú�w\ÈÈ’¨"ß;
ǬÙxJóà‹6‹îè}Eý“÷o‰îÞð$×Î7åÌ—6 ‡rà…Ì•ï> úĈ½ÒÁqæ9sO
+B´¡É„Bc?�k.H@¯Ã·§ì“$©H+¹’)L&À]G·`ÀŽ¨´[°ÞÎÀ}�/–`�ß1<éÈÐGVìë‡H¯ÝM1™ðRËâO?saC”›°c9âˆz}—«uåVÀܾ냪ͻ›[Ñ `aç‹÷âCrU|ß{ÀîáDD%ÇQ¯=b�Có,ØÞ ×ÉúÛœÆéP-õÌÒ,êòÇkR©Eù掽uMèu´) –5¸†Uð®Tð©Øé?6fÌ�þïñRJ‰c@›.9¹¦Å¡á7òØâ&.ÎiûÀ#â;yDßC�u±éÊù–BP#ûr_¨`]zµnÚ0AX¿u0²è˜@ˆ…�äôxA‰­Ìmè~ æ^h�ÚÈRed�s˜œƒZ˜Ð–÷µW&\OLò öLÎ-ØIÎy´fy¹Í'Ï#éŠõ¼ŒôTлi¯¨j$\
hMØ·<,rœQœèKcr>*MœÒ÷àéðNMM„·‘L£¶ÙðÕ1¹ÚV]¹®x¸—•b™ aí6«²#‹…Wº‘psë’Š3
+<çvƒ*ly±žÓ}.Ði,øý½
+’
+endobj
+1409 0 obj <<
+/Type /Page
+/Contents 1410 0 R
+/Resources 1408 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 1392 0 R
+/Annots [ 1414 0 R 1415 0 R ]
+>> endobj
+1414 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [341.1654 214.5127 414.8187 226.5723]
+/Subtype /Link
+/A << /S /GoTo /D (the_sortlist_statement) >>
+>> endobj
+1415 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [434.6742 214.5127 508.3275 226.5723]
+/Subtype /Link
+/A << /S /GoTo /D (rrset_ordering) >>
+>> endobj
+1411 0 obj <<
+/D [1409 0 R /XYZ 85.0394 794.5015 null]
+>> endobj
+474 0 obj <<
+/D [1409 0 R /XYZ 85.0394 424.823 null]
+>> endobj
+1412 0 obj <<
+/D [1409 0 R /XYZ 85.0394 392.7174 null]
+>> endobj
+478 0 obj <<
+/D [1409 0 R /XYZ 85.0394 392.7174 null]
+>> endobj
+899 0 obj <<
+/D [1409 0 R /XYZ 85.0394 362.8617 null]
+>> endobj
+482 0 obj <<
+/D [1409 0 R /XYZ 85.0394 306.2038 null]
+>> endobj
+1413 0 obj <<
+/D [1409 0 R /XYZ 85.0394 283.8925 null]
+>> endobj
+1416 0 obj <<
+/D [1409 0 R /XYZ 85.0394 197.5762 null]
+>> endobj
+1417 0 obj <<
+/D [1409 0 R /XYZ 85.0394 185.621 null]
+>> endobj
+1408 0 obj <<
+/Font << /F37 747 0 R /F39 863 0 R /F23 682 0 R /F53 962 0 R /F21 658 0 R >>
+/ProcSet [ /PDF /Text ]
+>> endobj
+1420 0 obj <<
+/Length 2921      
+/Filter /FlateDecode
+>>
+stream
+xÚÍ[[SÛH~çWøQT…ž¾_vŸ�3`�Tewf„-‚*ÆòZ’ýõ{NŸ–-;Ø
+ƒ©!©JŸnµÚÝß¹ŸVÄ€Ã_10–Ù ÃÀÍf0¼ÝáƒÏðìýŽHsöÚI{ÝYo/w~:RnX°Ò.¯;kyƽƒËÑï™eŠíÂ
+<ûÏéÉáîž4<;:þ
+Ÿuu‰aåM,pÜ,f^W³Û¼!ººÆVdÍMç¢ÊšÚæÛ4=ûƒžOFÈš�‡ó#áD‚Ü`]ÝMy[ÔÄÌá8¯kxIP·žÃòÎå�­rWø8o•ç!­´g
+„v°·`pŸÄà;Ž»‰ùkoµ60倃{Ò1î–%í;‰“ÎßàêH¼Pkä£Uši=÷þÈaDúº�«‡rò™º9É‚þÓ‘î*¸Ç-{Øy|9]Ó¬¥„�6ÍB‘ÁUïóq9JZ{^ÿc•¥sI· *F8÷w1€ªQDô6Õ×¢bâonT_ë:�ᕵN[lA£³›ªnˆÊG£¤½5šK²ã	=!µâø„Ú¨Ro€Ö¨³QEa”Z�åÔUrïªLkŸ=ò¨ÀN?¢ÀïŠz8+¯ŠÄ×r’ø{t@@bÖ+o“m)/íî)–·=ÏzÖiǬ‘²‡uF0©<iÖ>ü
ƒ«…@ïmR«%¶)ÁûáóÞn€¯³¯ç�u
°Ë[ósÚ¾±>øQç­ë�O&½² f%ˆþzðX¯²õyî*Ú3�r�Ýi>kÊ|üÝ4)z§äiî®ñúš¯ÿƒ®‹–›¬×€r2*iÝaSV¨†Ò4Uj£:1ÉoõpS$ë
+]±˜‘öÖP/ºÙîK»Ç
Ü=>Å�ñ…Øã–¦4³{€’@"‚íuu7!–<d‡_§Åñ¤ÉÇi¨+›0»Lo“l!=à±^6;Lž -dó¬²ñŽygû¬2WpªÎî]¼{º-=Ï>TÃœ¸A_rtgÐ
+lsšÑò‡"ã³qñpþ–™óiäáZ~-ñõYÌë ²Ýpt«�’V’
kDó”eŽ!zv
+ìÓò¢‹¹W¨W,×çquÕKÓª.1sH¸^ÜMð7³ºµØ^%]üpz°
ÑÎV_q|¤¹gFÃ⛕±–K±çÏÇ'G§
+ÄÁÙG"(YµAFàÀ]‘*"	Orêb
ýFXÎqáIg˜øŒ@©{ÒíÚ§­2¢Df•ï‰”4‡õ<§s_¼;�”‹‡�R²P˜GQl$U-Öiª\*[�
+
ÁÌJÇÖ8ñcs
+Ü=é¶òE²X’î«+g™´!DP¢g¨–=»RѾcÓz¤£WˆÏ:^
ûä:oEoŽÆ~ñ2Îdëvz¹¡VÍ œDGë\ü“:´½]�h$ê$M‹‘´xçÕ«ëÖRùìê®y,2¬›rœ¬iÒu R¤ÔÅñ{¬‘q¬€õz¯zž‹š¥ÚHÖKׂm¯¸Ê
ü¨ìIýäxšk
+ýшPbÕö‚öÇÜß·Á"ðõë²€Ï1%€îu•ˆ&Õg}Š�keJ©å¦l¬E/ßÀ‹Î)_q±K	Éw=¦W	ËtÐ$é€"‚+ÌŽ"¸`/kÐyº¯“
¢�-'×U,ߪ%|aJ”ué–0 ¼³iê²=^og߯ø¶A:aYO)QqÍŒòdHQ‡ê;QG÷…�Ê !ÕÊ:õHÔÛk7|až<Ã`2ERµËK×lH'z½!MJ÷“˜w{�÷§w‰DÃ6®¢Êy¯ópøªhšb–JþЧkÝ(øôµ´Yx�.q(åù@�ÄÔÎCØ„P-?˜§ß<én°ÃÇmYÖH¤5Œ{ÛØJHZ­SdYOöÏ.Ï!°åŠg'„;ú›»æ4ºùÖ¦åX‰n<¡’x/‘m
+Ä
+:ºÌ´JÕQ|-ëfu½Gœ–¥°ro)XG¢s6è=ÐÙ€:?§–>XÒÍ¿qŠã�t–¢ÔÒÒÔÆMí=V/Ÿ5Õ·Ï.“uEc[i O1O1üíë%X
+f¥îñ}Â)ÆU2ÒŸ.c«’üjO�©ö­üÒ
+/¶ËÂK³[Çy‘ÁHEáE‚„©|ƒ)ù;…W¾>á
º^­eâ
Ò•—êfö0ºÈ졳’ÙÃH3¡%k•–yD}çëusó
:ÓÆç	ø‹fâÁAÈ¢u�ÊÅ ¸!Å`ÑXâg€ZÏCÃØ!3¯÷�qF>kˆŠW}:]! Ñæ'H§o’tºÜÃZOPϹ¹Ùì—;GÅ…Q°VžëžÒ¿LiCÙãJðcŸ³¨
+Õ}9ŠÙ£w�,M§ `©ÉÙCQL¨C˜
á¥$‚
+N@|BÛŸÆ–«§ù+L)ì†
+içÈÏCËÅr,/3åèó÷Õ/–ù 7aøÑ/òÿ+
ÜŸò~MÒŸ>‘V˜ âZˆ˜³ßý
Á™TV¶³:[ÿ?
+endobj
+1419 0 obj <<
+/Type /Page
+/Contents 1420 0 R
+/Resources 1418 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 1392 0 R
+>> endobj
+1421 0 obj <<
+/D [1419 0 R /XYZ 56.6929 794.5015 null]
+>> endobj
+1422 0 obj <<
+/D [1419 0 R /XYZ 56.6929 695.8713 null]
+>> endobj
+1423 0 obj <<
+/D [1419 0 R /XYZ 56.6929 683.9162 null]
+>> endobj
+1418 0 obj <<
+/Font << /F37 747 0 R /F23 682 0 R /F47 879 0 R >>
+/ProcSet [ /PDF /Text ]
+>> endobj
+1426 0 obj <<
+/Length 3296      
+/Filter /FlateDecode
+>>
+stream
+xÚÍ]sÛÆñ]¿‚o�f$‡;|\óäÈRÌÔ‘]‰i2Mò
+„/ÂHŽÎ£ÀWB¾•nàVCék¤sûRxéÄWQ‚œWÊt°á|(œJú©”Ñ(‰´K˜CÖß¼?=�CàÚ¸¹kW‹¬«ÚX–„ž{.‹•iCƒÕ©H½Â,
QMë‚�°
éu%còv‘U
HA&‰wùŽÀ}ç(�Q¢|EH¸@ ´dT‹¢é²wˆÀ{]˜Ùªš9	¯jXÒW‘‚ˆwÄ©@žI‡£!>�µR¥¾-�»/)­V¦AxLZ^+š¤us;þáô\E±ô.ZàX…‚Q©ð^_ßÞ^^L+;=SÍ›¬[“¸•g]üA
ŒSÈ`|"ƒ÷ˆˆŒTR=ÃôÁÛ¼ÓáÍÓ8úoäèvdzœ*_
+•c:¼x*DLL?•‰7A3IAÛuWœw¥ål»ž— ‘2ò¦U“WÍ1Û
+Gh)5‡™ÿËßoÙ¢Ð:Ž%Aa’†ÏˆjÀƒ—•£õÓ�t;Š*JS?N¤<"ªH‡~iJ‚&¿NPLà¼&§:ôŠ�1„cbkŸ¹ùÔ\òY�Ò÷yïüE5>ŠÐ{”‹)ܨÔ)p³ö-e�ÂÈ);‚e5+ŒYïÉz�`¯÷¸ÂéýÙa7k<ÎF
Ž·?MÞŸŠP{g4æD	WЃj	‚Íz¹lW�“í›Êtàöf˜¼”à†5_±ËŠ <¤ �cŒ ¸ÕJY^þF˜{D‰wS,9µÃLŽ½V*mxÀç¯>.Ehã§`°›&�ÞÉ' ŸU¡
ßö¥„²©¹�ñ¸'	’�"þÛå±öeBƒëÉvñÿ¤	 ƒØOC�€Ü…„}Ñ
¹»…Ò¤B!»?› 
+œU˜€Ëÿ?I4ø"ñNÅ ¯áÑúS%p�”šŒ¯¡ö”Q¼‘ü¸éŠ˜òaÞóRqë”\J†
+SoŒµJ5Ö ¡ÓIÄt-aLÙ{n»p«à�yWðÀÜ}¶ªÚ5ŸdÍNˆ¬ +°·1ÍL¯bOS> fåfçÜH[:ÄrU¡w3;½ÓÒ´ð ‚
%÷R
+öÕ¤°ê¹OL+ dõ¶øŸM+ðn-ùŒ
.¼äöè:l²#I‘`ò®+F-–u5«:ÛHJ½U
+Èû ‡çE¨U¶/Š‡D
ÏWèq´´m:Ümç[on|®Z>¹ø˜Áµ߹ȚÇ}ÊHt£	’#DeJ#{ïªÉjë©a‰#¨#[(h�õ¶€-3SÆÀ‚Ô[Ï\Ïôðþ’·n^B±�:­%k1 g%•2)öæøxk8òŽM›ÛT\	e%²ÇÓXQÃY	8Ÿ¡e¥!Ô&/S®§
+™€/—h?ˆ³±QÜ}„ðq_Ð
‚ˆ
+Û.÷Y½~ÒêØöátùaÿÆ
›BTÞ¹pˆ­ B(I6åé1Ç\gcuL³lµª¨Œä´6¦~%ε‹).Ÿ"úS»zäk:d¬ÛØðI}«va&aü}ïÛ
+M¸ Œ]N¨ù{™vÚ¢1»š}(:¾ÁÒ¥ÃÍ,¼>­6Ж—öh±M×Ú¬9=L¤%c�”Õ¼´[cí�¹BÖ˜Ó€é‡Øø@&8ì9�« qÅøŒœ³&ƒ¶
`[~º4©Æ°Ÿ>ˆ�Ú¶¤]fnhÄL¸¯òÝK©EœØ/êlŸsDïà÷ÏGü�‘ÁKÕÙŠÖy½ó\hCœM6à¹ÈÀ‹ñzL¼,]8xÈ(€Øöqwß0ôW	Œ#îR&	\%¦¼|š
ðÄä=Ž-hCeö	�ÊmÛø‰¼Eklç'e
z )ðÀû­]’΀±?ÃT]5ÔI‚l¤†ŒŒ~œHkÕ¬�K‚m¸Ô8¸ÄÖ÷».@®
y\œÈ\c­yÎãÊþËu,Ù÷¹_†
€7#zsHÍÎ,מ{wÚb�1ÏdtŽ;QB\œÛ` üPuå`LÖYó
ÙÇ.:¸¹â# ã[/v	ÁÝŽÖU;NÐ�-
\ë¦ByR�°µßSw…¼üý©%ÐÉj׳s)Î1¶^çΩ÷?ÓปgÓªÞü6àÀ¯ eä+úιÛWFGáŸúÉͯDUâË4=ð[›¾‘ÁD!Ë“d—òH¦~”†ÉÒÿ³Ÿk#endstream
+endobj
+1425 0 obj <<
+/Type /Page
+/Contents 1426 0 R
+/Resources 1424 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 1392 0 R
+>> endobj
+1427 0 obj <<
+/D [1425 0 R /XYZ 85.0394 794.5015 null]
+>> endobj
+1428 0 obj <<
+/D [1425 0 R /XYZ 85.0394 492.6335 null]
+>> endobj
+1429 0 obj <<
+/D [1425 0 R /XYZ 85.0394 480.6783 null]
+>> endobj
+486 0 obj <<
+/D [1425 0 R /XYZ 85.0394 173.0867 null]
+>> endobj
+1430 0 obj <<
+/D [1425 0 R /XYZ 85.0394 147.5597 null]
+>> endobj
+1424 0 obj <<
+/Font << /F37 747 0 R /F23 682 0 R /F47 879 0 R /F39 863 0 R /F21 658 0 R >>
+/ProcSet [ /PDF /Text ]
+>> endobj
+1433 0 obj <<
+/Length 2902      
+/Filter /FlateDecode
+>>
+stream
+xÚÍZÝsÛ6÷_¡Gz&Æ$�{s§U§urŠ{“¹¦”D[¼J¤N¤ìø¿¿]ì‚¢$Êq÷.ñLˆ�Åb÷‡Åb±�Åð'GI*R§Ü(sF$±LF³ÕY<ºƒ¾ïÏ$Ó\¢‹>Õw7g{«³‘.Uéèæ¶ÇËŠØZ9º™ÿ¥B‹sàGÿzw}u~¡’8z;þ	JR›DE¯¸|s5¡Ž”I¿_¿¡GŸ×ï®ßŽ¿ÿeryž™èfüîšš'Wo¯&Wׯ¯Î»ùñìꦹ¯–Œ5ÊûŸ³_‹GsÐîdzXhg“ÑTb!�S£Õ™I´HŒÖ¡eyöáìÃ^¯:“Œ…Ò©ÀIé!œ'R
]ˆÓÛz¹¬ÊêîüB§YÔ.
+*ÔU±A­_Aݥѷ/˦= ½¹ùé7=®¦Ï«9µÍ–yÓ0ÏÛƒ‘“‰ ÂëQ7™QiÛWU±ª«rÖà
+R
+—$Ê«4/>űª
+à£`Qói}�R©Ts•J”™zˆ©*ê(«¶¸Í}ã´¸­7çÒFuúù±ƒdÃNU,稇‘ј¹Ð¨yàÓÖÔœß×e�j5-ï¶eûÈbðÀu¾i`1X\?Í€†¤†6
\,î ñÕ¼“*ó²ùw
š![mQù!*V½ñTÙnÒ¤uo2¬%„!r[>ä�\ÁZ%†}Cã“h|Ý—zO/ÙÓ6-îóå¶h¨¼*õm[T\\•m[ðÈ[OT¯¨V|ÎWëe`Pò
+°¨ì4,½	¿]ÓH,Xx¢¾`‰SAÛtß2ÂöÐ'1èq!vׂÿÇQ;]hãà†¦2gû÷“£{
+8a¬G9•"ɾpM�k�H�R»hî,Þcke(dÀ†E~Ï]Âû®ý@»º@+‹r¶ ÒY]5¥�ý°ÃßO�uÊôbZ¶ÔTmWSŒæ±|ë¯L¥ Õô±7HGóz•—,H•¯
+1çÞ„À'ŸÏ9k"!çéE?MÁ1E‚�ߟà
QÛ*ç`Ëß<0°ª!Ì;¨´"ýºH¸*Ú#–Oľ	ß­öâ¾]ŒÇÒ4åçNµ–í‚Å{¨ô‚ùl±‘·’)D¢4–èf0,ýP®Jˆä—�§ÃÑ¢8
+%�…í­ÍÈX°þä¹ûËý©ýåþG¡dÐé¤Vd±Ö§<nÚ%#“)¡¬£ÓïãGñÓëâçñ
”ÊetŸÃ 	6YšHàŸ1Ç0Ç™
 ½¹¿Öº>w
+ÄϤzúX0 ¼ÖÖ°#*›§ÝOçaz>­Ø9J\•Ã
+Ã>̲ÿ%‚’‡ÏÀ'�K²ÑЮWË�ÄîÍoÁË0ãàÃýÜ-éÓy7·C~è5¢“Øv>|]Ws~ÇpŠÕ°&"Б®á€jÓR5¿££ÐâÎ]2ÍmN%¸då³ßy\ÍßÀ²*>3�%	rçvuB³þFÆÑû΄p­SCäózH;rÇàÔ袩”#~¤¦|ÚÔËm[PmUäeä�æ“R5ƒ¤�¼
+üt×Õ’	ˆxk
“zÅ‘
+øm¨èÏ÷ŽUÏI`'åîýü~Y�Ž·×�½òfSŠ7[bv›11Á{'ÝûýNIø•
+8“½Oô­5}ÞÛ'ô{/	‹�¥i˜–v#ùr–iÜRìbúϾÚÃ-…¯Õ¶i"oà:“2'`šœp
+ŽíÜ;ñ8¼8Y‘‹˜ìY 5‘×q<ÞÅ;׋åuï˜ôRT<*ÌæõwVmk|˜íÍ3à‚¦�ïe~•žõw”Ú€xšY;’Ú
+›jù¬Ÿ(ÀÅ,ÉdöÇ.‰Ã£þŠÔFÐéBªT¸8sÃ7÷,��nPõXgã$fõÊ¿“A‡i
­bǹÆØúס,fÇ%ö†ÞêÜêA¾$_§Â(3­^¯9Âå/9ùdCÙ&ØX‘h~2;DÇt´GG=éFý™¿a|b%œ;õ„¶Ã'NEbù	íÕÇG`(³]‹zs÷:½y_ù‚è8	ç¯2Oo68¤SEIÄãÍ7�Ý~³>Yo½Aù<¢<‰Ooæo×x2'b{ê�-ÀcPóóÚÀö�Óï	€ÔI€zs¿@ÏÏ)þÇ…_›€�7Z¨$I‡~	�¾häÏýÝÝî·‡&ÚÚIIN^ª‘Nð"�Ù£Ÿ†_貞ðÿd`®endstream
+endobj
+1432 0 obj <<
+/Type /Page
+/Contents 1433 0 R
+/Resources 1431 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 1392 0 R
+>> endobj
+1434 0 obj <<
+/D [1432 0 R /XYZ 56.6929 794.5015 null]
+>> endobj
+1435 0 obj <<
+/D [1432 0 R /XYZ 56.6929 673.1367 null]
+>> endobj
+1436 0 obj <<
+/D [1432 0 R /XYZ 56.6929 661.1815 null]
+>> endobj
+1437 0 obj <<
+/D [1432 0 R /XYZ 56.6929 493.0122 null]
+>> endobj
+1438 0 obj <<
+/D [1432 0 R /XYZ 56.6929 481.057 null]
+>> endobj
+490 0 obj <<
+/D [1432 0 R /XYZ 56.6929 393.3436 null]
+>> endobj
+1439 0 obj <<
+/D [1432 0 R /XYZ 56.6929 369.004 null]
+>> endobj
+1440 0 obj <<
+/D [1432 0 R /XYZ 56.6929 151.2167 null]
+>> endobj
+1441 0 obj <<
+/D [1432 0 R /XYZ 56.6929 139.2615 null]
+>> endobj
+1431 0 obj <<
+/Font << /F37 747 0 R /F23 682 0 R /F39 863 0 R /F21 658 0 R /F47 879 0 R >>
+/ProcSet [ /PDF /Text ]
+>> endobj
+1444 0 obj <<
+/Length 2798      
+/Filter /FlateDecode
+>>
+stream
+xÚÍZÝsÛ¸÷_¡‡>P3	ö-Û©o;UtÓÎåò@K°Å)E*"'ý뻋HJ¦ì\“Îu2B‹ÅXìÇo
‹	‡bb4ã*‹'i3Í…ž,7g|r}¯Ï„癦Ù�ëçÅÙO—*�d,Kd2YÜ
dÆ�“ÅêCôêo/ß-.æÓ™Ô<JØt¦ý|u}N”Œ>¯n®/¯^ÿ:9MãhqusMäùÅåÅüâúÕÅt&T¬%P^Äo7×ÄtyõæbúqñËÙÅ¢[òp[‚+\麟ùd»ûåŒ3•=y€œ‰,““ÍY¬Ó±R�Rž½?û{'pÐ놎©I*ÁR­&33“€ˆ
Ó#fÅfd–‚RuÆ%U§ThŽ(5,É2í”ú6/Jؼ”ÑÊ–Åg»ûŠ¿DôP”ž~ké›·­Ýl[»¢Ÿm�š‚sËS-@IICáÎì—|³--[Öq°¨,eFóÄÈ«Õ˜ÔŒqØÚ@¨|F*¨ÄH?äw®yQùmT~‡õn*ìz½âÒL˜tš
+P¼
+Á2­¥“SÜ‘�T¶h×vG?jOl×uc©Ùì—KkW/è×@±È6ª·$cZ‰áÙm¾ü×~ËêÝý˜Ú$:zö‡Òoý
+ºÃb~°˜t¹ûJÀL‚¦™€sbÐ%øç<zoÛ¶¨îIÚbñ¦YA1Ëb»á‹µ›<‰Úbcgm=Ãm…t”‚Ž<a>§ïïœK[®èGÑWN?•œÝ­ïªZ{OO"wpvKŸÆVd“Ž‹ì«¢m†3'Qc—uµjÜ‘Ð9¦L¢í®Ø仢üê4–�À-ö'ʯ ©K8׆Hk[Q6éÙ–ùÒmšóyáFÅÆ«	H Uj¬l³Ü·ÖKZ×Ô(kw
+hY¾FŠšu›ši#d@9Î…L)¥'‰””¤Ü¾¿y9�AŠáäâ¨ÌçEjèmÊ+;>©h(RÈ)Tè‰!ÞÝç­wf26oΈ1-ÖaxZë¹.êC“FƒK4YÛ�Sy3×:ªCTÕà¯;ï[à�!¾éΣ YÕ3ˆ³ëÙª†pY
ýõ?ÏoÞ¾¼ºÆ°NTï­Ûºjl3føw´Ú
Û×zÏÆœ¿s…Mþ¥Øì=7»à!»�zuñ¡º¸W-�}À%wM0q8Â5.ú‘™kn˜L9Ä÷š³d…PƒeOâšG"ÈÓv«
3&Íž±[àe±Ì(÷üÅ…‹XEzV��‰¦d
+‘‰ÎpIjÅμ¥oKÜ�[ê-Q0
+~�QØÌ=†}
+Fç%Àa±ôD¤y
+Å%Ož®ƒb ;I�; —xœ*=2‰*G8�$2=$®ìTDÞÍSMp"‰Æ‹
àŒ],ª÷÷ë#fAg�£nýTö˶,–…ÃFHïÂ�«&b°AP°ËW@/Fʉ£Ä%ÖŠ�UI2£ AEĉJÁó<*b_(\UhºÞ<ßæÛmŸë¼_½û?_=Ì­—£2È 9&Ue²iïÛ¢®¨#w»v	
+Ò1øë.¯š2÷|ÐÓ§uuõŽ¨ùjå…6Ôá:pRô3ÊÔŽ²7,mET,
+#•<º€€T¸ŒƒhpâS›#-ÁuÌÓ¥DèØä+{(©´
+}.(É#	«QÞÐíIá½aÅÊåaÞ¨+W‚@ÛR¦ÔB
+ua-عl
VQ{ßä÷·ƒi.¦›ç~6R
+åÅ‘ÌnlY4ô
+
+…u[8ÐF·wÃÓØòîð¶xYæMŠê•ÝâœU¸7O�èã•ñé7û¦=|>ìß4Ëfn¹ÝZúûq@7J†§ä1áçëÛnUËr¿²Ý…à î*°ô4cÁôÀF0˜J¡=ß‹Q
+endobj
+1443 0 obj <<
+/Type /Page
+/Contents 1444 0 R
+/Resources 1442 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 1453 0 R
+>> endobj
+1445 0 obj <<
+/D [1443 0 R /XYZ 85.0394 794.5015 null]
+>> endobj
+494 0 obj <<
+/D [1443 0 R /XYZ 85.0394 711.7496 null]
+>> endobj
+1446 0 obj <<
+/D [1443 0 R /XYZ 85.0394 684.4451 null]
+>> endobj
+1447 0 obj <<
+/D [1443 0 R /XYZ 85.0394 642.9726 null]
+>> endobj
+1448 0 obj <<
+/D [1443 0 R /XYZ 85.0394 631.0174 null]
+>> endobj
+498 0 obj <<
+/D [1443 0 R /XYZ 85.0394 462.3028 null]
+>> endobj
+1449 0 obj <<
+/D [1443 0 R /XYZ 85.0394 432.3134 null]
+>> endobj
+1450 0 obj <<
+/D [1443 0 R /XYZ 85.0394 343.0202 null]
+>> endobj
+1451 0 obj <<
+/D [1443 0 R /XYZ 85.0394 331.065 null]
+>> endobj
+502 0 obj <<
+/D [1443 0 R /XYZ 85.0394 138.4884 null]
+>> endobj
+1452 0 obj <<
+/D [1443 0 R /XYZ 85.0394 114.5262 null]
+>> endobj
+1442 0 obj <<
+/Font << /F37 747 0 R /F23 682 0 R /F39 863 0 R /F21 658 0 R /F47 879 0 R /F62 995 0 R /F63 998 0 R >>
+/XObject << /Im2 984 0 R >>
+/ProcSet [ /PDF /Text ]
+>> endobj
+1456 0 obj <<
+/Length 2275      
+/Filter /FlateDecode
+>>
+stream
+xÚ½YÝo7÷_¡?¬€Šáç~Å
ª-ç\Ør*«ÍáÒ<¬%Ê^@Ú•µ«8¾¿þ†rŵ6‰{¹
Â9;œÎüfH³
…l bg<$™$Š25XlNèàÖÞž0Ç3òL£�ëçùÉ›‘2’Å<ÌW�¬”Ð4eƒùòCA† �Fÿ¾™N†#®htqyRñèìŸãwóÉbÇúóåôg2În¦—o›�‡‰Œæ—7SœžM.&³Éôl2ü8ÿåd2oUÍbT}O>|¤ƒ%X÷Ë	%"KÕà	~P²Œ6'R	¢¤~f}r{òk+0XµŸöº‰QÂEÌ{üÄYŸŸTFbÁEë'E¸…RÍ4Zxz3»|{éÌ=/vzÑŸ´1„Š@(
+>0|^¾åS¡@™Á8w|Ëj“å¨Ì7}›Ç)áR2Çû¡Gš
+
EOÊ0Œ»«ÖíèhTöØ„
+(g‰$ÚÚ𯺮qó“xkÝ.bUI™¾Êe,má#w;Øü‚­m~Á率Õr±Þ#jžÒâF�^v9oübá„o+øÄG—«žÀ
+2õ'ciWé£@f%íJÛ£
+À�”*ºr€£»ŒmM0“.ÌXØ»º*‘çéAÛÞÝN¢€8¸
+_⃳Y?Ô}ý')å¯MŽþc	ÉOÿì•m�×}Á].EY÷¯{'•ÛÇžæyëÜõ(á¼!ÿÿ–—EA3hIJq}|`]|â
+endobj
+1455 0 obj <<
+/Type /Page
+/Contents 1456 0 R
+/Resources 1454 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 1453 0 R
+>> endobj
+1457 0 obj <<
+/D [1455 0 R /XYZ 56.6929 794.5015 null]
+>> endobj
+506 0 obj <<
+/D [1455 0 R /XYZ 56.6929 769.5949 null]
+>> endobj
+1458 0 obj <<
+/D [1455 0 R /XYZ 56.6929 751.4464 null]
+>> endobj
+510 0 obj <<
+/D [1455 0 R /XYZ 56.6929 563.3947 null]
+>> endobj
+1459 0 obj <<
+/D [1455 0 R /XYZ 56.6929 537.1873 null]
+>> endobj
+514 0 obj <<
+/D [1455 0 R /XYZ 56.6929 314.9763 null]
+>> endobj
+1460 0 obj <<
+/D [1455 0 R /XYZ 56.6929 292.5697 null]
+>> endobj
+518 0 obj <<
+/D [1455 0 R /XYZ 56.6929 211.1564 null]
+>> endobj
+1461 0 obj <<
+/D [1455 0 R /XYZ 56.6929 183.865 null]
+>> endobj
+1454 0 obj <<
+/Font << /F37 747 0 R /F21 658 0 R /F23 682 0 R /F53 962 0 R /F11 1299 0 R /F39 863 0 R /F62 995 0 R /F63 998 0 R >>
+/XObject << /Im2 984 0 R >>
+/ProcSet [ /PDF /Text ]
+>> endobj
+1464 0 obj <<
+/Length 3617      
+/Filter /FlateDecode
+>>
+stream
+xÚÝZKsÛ8¾ûWè�ª¥«,^|íM“(YOeœ¬íÝšÚL”HÙ¬P¤V¤ì(¿~»Ñ
+'1‹LnW=ZãQ$&·é'ïõßfoç×çSés/`çS?àÞÏ—Wo¨'¦ÇëWo/ßýãzvjïöòÃu_ÏßίçW¯ççS¡´/�€²$þõájNƒÞ^¾ŸŸ¾ýål~Ûn¹,Áî÷ßgŸ>óI
+§ûåŒ3Gþä~p&âXNÖgÚWÌ×J¹žâìæìï-ÁÞ[3uŒM¾Š˜ÉpŒOñŸü˜J*Ã'Îð_Ä’]^MgoÞ\³ÙõÇÙù4àÜ»º¡çÍüúŸókÁæ¿Í~ýø~ÎðÔ°ôTû¾|‚#$Ÿ$$ž"ôújö뜚4nlä€(iƒ|!Qù2¢´SÆÆ ×ÁŽ<±^_±„аB¨'AèƒB„ÁKTKÅŠ…<<P­ÿn–ÛVù,
+|ÿôhZ¶éfIMÛCM*IÑ*.4;ÅR0¥”?	‚�‰06lÞ&å]†l‚Áª78Ô$vnFÝÞç5˜kyˤ¤Æ"£gUšFèU+êh+j¬ªíºþëùTéÀ«›dÛLë¦ÚØY[zvý?ÕM¶
áª@y—ŽÔ½]äwÎå¶nÆôW�Aqì™-ÂsWgé	àvc\(Û‡ÕYC�¦¢§€Õµx³¢ s"‰›´í€bR¦îµ#½ÞÕ–æ"³ŸMUçMþ�é¥Ï#&ƒ@Núü1­@ýSàÇa nJý4Û)'UM‡ÈÇásª¦ ! �Ç/îëjšÜK³z¹ÍYÝŠ’ú«Ç2ÛR_™¬]çê`Ôö\D^VW;ÓXfôšz—•y¦v!”?>vÐ’F%M–Žz¦Y¹ÇЂÏË»ÂOÿø>°6Šb{¤Wc‡f~à»
¿sŸ§UQ$[G÷®„>�ºÏ½z¿^TEM¯óæ>/éžõxm¡ZÚã<
Óš4¦ÎÓŒÈ'tt¢OíM‘,³”^/ö†S)
+ÀÌD8y*Ó`áÒ“Ÿªg9ØKXº—»-©vÙÐãÀÁ†¤�Þfª^Ì°±vWØ	‰�Ðë4[æ뤠>¼ºwß2ÚÄt.%iJ¡‡wÆ‹?0ƒ§5béKâ3Œ0I^$‹"³£M
+W¨›C¤ïÒˆ»2ÿF0Ç7NŸy™æ.úBâq †çYÂLôED� ë}^ÑÃ8Ê>ƒÈ��NûÙ¦y]îø')´•_òL樅qÌjKS<›9ÞlÀÏÇ€j¨m.hù:›6Õ´€Ô›zL
+r‘9	ßgÛ¼qÎfC£€påôyП—”K;j{y»"«Ùó9Ï’—17"5ã~ìà¦Eć¢
@â‡ÎÕŒ‹b€ÖÊ$*õŽî†<½;´Óò9ÛZE'–g»?¡ï==ú£J%†ºsÎü0z®P¢%¤ÔàퟔÒS
+ï;@æ+;ßôTê½ë«9ô�¨¹]½†Û’Œ\'Íòž:-1é}Ãê߈Ïn7
+
ê>!…Þñ~Œe�ºkÁÿÅeâÄ(~CrÈt$dÿ~òèžRñ€EpÞTAŒP”­ ÕÈ=%¨?–÷B[^ÏÆ=$@Á¶^ýn~5¿6‰ôí|,ÉUŒså
+ι7KÓ¼¿ÈÛÜì­9ؘq9ˆƒ
+!¼‹ÖèÅbïüµN¶_€¶/_[ÿpœÖU’v½y?ñ7vu‰¿Œ©V›ÚãÚ0FÆ�weÛ‡¬­îóv�u
+Ðj�Bl«Žq¯Ú=TŽP
úk£Û	åààk[¤é´Ã¯é™}ô#¼%ak\­¢çÂág¯þ
+²ûompô0¶¬ ™Œ„:¸®@ƀƌ—’°˜¬Û²5étŠõð.ÃF|
XG:/c×à.ñš$#µÙ4–F �@_²w?�lL»²ÏÕÁ”t›È—ô·€º¥lš`mÂß5€.š|i®™¬
+DG†¬Îévttðƒ”yëÛƒþmŒhÅl1�íÝwÃÆk†\~''ñû”
'­FßAVÃÜ­ZÄ"_…Cõ�
œüKÐJœ.�dQ¬ÄsÀ|Ÿ:D@sW›„W¹/[ QfÍcµýB?ûÆvwÕó“n€°ñPå©¥AhoyŸ7Yê§ifªõ¥]‘@�]äw¥-eGš		˜xwOW„Zzuån“Û“»§)Æ*º„ßë�Qh!~´—tZ¶ï7U]çR2­È8��¡)äÚx«m¼Õ6ÞÂsW»7yi¿qÑ®[ªÍ×Cfûí‡<‡‚z¾}�÷QA@Àš>^kYÄö”7cRìK¨ËBZèp
{é—ø„€oa¾ÏjLÀõ‘Æ
+endobj
+1463 0 obj <<
+/Type /Page
+/Contents 1464 0 R
+/Resources 1462 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 1453 0 R
+>> endobj
+1465 0 obj <<
+/D [1463 0 R /XYZ 85.0394 794.5015 null]
+>> endobj
+1466 0 obj <<
+/D [1463 0 R /XYZ 85.0394 687.9013 null]
+>> endobj
+1467 0 obj <<
+/D [1463 0 R /XYZ 85.0394 675.9461 null]
+>> endobj
+522 0 obj <<
+/D [1463 0 R /XYZ 85.0394 283.5376 null]
+>> endobj
+1292 0 obj <<
+/D [1463 0 R /XYZ 85.0394 259.198 null]
+>> endobj
+1462 0 obj <<
+/Font << /F37 747 0 R /F39 863 0 R /F21 658 0 R /F23 682 0 R /F14 685 0 R >>
+/ProcSet [ /PDF /Text ]
+>> endobj
+1470 0 obj <<
+/Length 69        
+/Filter /FlateDecode
+>>
+stream
+xÚ3T0
+endobj
+1469 0 obj <<
+/Type /Page
+/Contents 1470 0 R
+/Resources 1468 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 1453 0 R
+>> endobj
+1471 0 obj <<
+/D [1469 0 R /XYZ 56.6929 794.5015 null]
+>> endobj
+1468 0 obj <<
+/ProcSet [ /PDF ]
+>> endobj
+1474 0 obj <<
+/Length 1368      
+/Filter /FlateDecode
+>>
+stream
+xÚ•]oÛ6ð=¿ÂÈ“Ä)ês}jÓvëPCã>­{ eÚ*‰šD%͆þ÷ñx¤,Ǫ·À0t<ïŽ÷M¶ æÇYL(Ï£EšG$¦,^õ]ìÍÞÏWÌÑD1'qĹYÌì®bž‘8ÓÅjÊäÍúêö}È!%IÆ‹õn”•¤)ÉÒ8_¬·wÑjÙ-WaLƒtùçúW<‘4K£FDB²(Ïì�7~{‹Ô9~îe1t¥~ÂÕ�júr+;¡K�üXDx”„Ž_‘Œå¨@JØrÅ(¥Áë¢�}?²Ñ�ªpñ±ìµgÅ9É“0qœ8%!��Óñ|Œç—,�Gäxؽ/4¦¯ï>öæËn
+Ñ ÐK·5´Žg³E )‹¯�¨�¨�ê�n7èaªÃÐ; lFž\œ1’Çqh/.ªJ=®¥ËÝÓŒ™Œ÷¢(MÍ) ¾™á‘<cÜ ·¿ÙÍ2‹�#Cö2f„Hob†aÊÏXòn*Q|=¨JΰŠLX…ì…Õ�hú�É€s~&LY–U³Á(uA€ÖÄ	£Inœ‘‘<7‚�ìs_6{Cš˜€6A†�å`Œh…߃x�}¡4ll2&,(Ô’Ó(68õ€»4x<¸Ós Ç?Êpt.ÖÔËN§‘½IƒÇRÔ ›jЦ€îp¹g†a<ò5P¡Ðv�+
+ôU”N|æ$LŒ/ÐW{¥¶îÌVŠ¹Pa$ËSÆà	 ¶Y
+ýM#
+endobj
+1473 0 obj <<
+/Type /Page
+/Contents 1474 0 R
+/Resources 1472 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 1453 0 R
+>> endobj
+1475 0 obj <<
+/D [1473 0 R /XYZ 85.0394 794.5015 null]
+>> endobj
+526 0 obj <<
+/D [1473 0 R /XYZ 85.0394 769.5949 null]
+>> endobj
+1476 0 obj <<
+/D [1473 0 R /XYZ 85.0394 574.5824 null]
+>> endobj
+530 0 obj <<
+/D [1473 0 R /XYZ 85.0394 574.5824 null]
+>> endobj
+1477 0 obj <<
+/D [1473 0 R /XYZ 85.0394 544.7049 null]
+>> endobj
+1472 0 obj <<
+/Font << /F21 658 0 R /F23 682 0 R /F47 879 0 R /F39 863 0 R >>
+/ProcSet [ /PDF /Text ]
+>> endobj
+1480 0 obj <<
+/Length 3343      
+/Filter /FlateDecode
+>>
+stream
+xÚ¥Z[oÛV~÷¯ÐÛÒ€Eñ\x+¸�Óº»Hº‰ŒÝ¢íEKÜP¤BRVÕ_¿3gæP”D7
Š æáp8ç2·o†³
+¬$ ƒU‚3åGax‘~_3b™úI§£ˆ…†Kï؀•N8)á¨6h8²Æ
W0Jì1¡ê˜|î¯̾µÉxTÖyµ/LÇÌ�7Žý†²*ܳëƒ8œ±;Ÿ’üÉGÛÓÞ[Nk´s·—³ôŠÂþ†A5M
®•v-`|65
é¥4ŒÍSG8&NRñ5± ‚ÌÆ.n–<aœ
+ð9«
+ìË
]³âû®¿˜ï%«ö¦f³§#"+�îÏì‚°RçPÇ'3];OÛ”‘;°^¶ÜëApŽ“'FÅ	
+€M)_ÄQr
\	ÿtŽf¹®±ðÇŽßréùg
+ñÍ7-?†bBÊS@ÛC	8‘œAQQà‚è¾J%aa‚ÛR¾ÉêµqtA-â£é:®˜l+ˆÛ¦(‘)Ïú¡NCmv®ê‡”`jJ_fŠöOŒ”ªTÕ¦´£¤ŸÊH]í‡ë2ן´B³Î`?·¢5çÁeÁ=	7µo3,‹m\ý4TÞ8�–¹„rê£ümÙS!4Õ.U
+QØ´£³À›ÐÉ^Å‚³É
+€è­=B	Áb+Ë|nD�u•£àÔ±±þ5ûGO:8ÀéãÃ_óαK	‚lƒK�µªŸÀJ­9Ï)ÎroŽ`JeN¡åiWd½qÍjî;~±]}Ï
^	Åý×WÒ+œ|¤îY>ŽŸ³œ/Þu›f_4^ñ« qPvŶ‰Úšƒ«Úš©`ÆN€!`Æ+æѪàY]§pØÁ¶Tq]£½¢áû
US`ï¶7¤UÖQ¤(¾§Ú•RÊ{ü‰YQFíø%*º”ãÔÞ¦¡²I&5Ÿ¡bbX9f£“»cÿâEVåÀª©U÷ÊÔ;¥¬…^ÖSç@†P™Þ
+\Tü·”Ã'ºm¶†É«üØ×qêðÀöæ0gUOÖ¨I2ı?¸ƒœœÚåJ…Ü.GòÖô›¦àe0
Š4N×

+@µÜœÖh¹»†X܃s]àŒ®$�Áý"pó³Š�å$ƒÑâøé
žnˆ-”üáƒdX–ɺÒ20~¦fÐÚ,väï«®áoúa©™ñ|¶ø˜´x¾hÃÓØó¥6lB¦ðªfTª|)høÍÌö‰Ú¦±�$Û1¡Z,ÎOÖÊñ
]º*{aÖáÃ
+ìÍ´phÛŽ0<PyÇEØHêRð†vc¿Œ)qZÒ6ƒz¬�2üœzÚfdN‹�m.A�œõ=궠‡+¦vC5:7ÕÈ44Ã3ç²@°»¾£ñ€ñÔðuE�÷H�è[Ë„(Þ
¿o›!~¼ðl2\½`Ï `›
+.
júl?Qëœ&=aÏl7úReQnï¾�›îù†b:óÄ'ž·�ÍÉÖ|:‹�b}Y±C¦}CL˜õmÿnmóÀÀ‹
|c›ÜVA¨ÁèfÅÒóö¸ë›u›í6®×€�³=¬ ÆöCoXЊçØš¬ž>[4A
+endobj
+1479 0 obj <<
+/Type /Page
+/Contents 1480 0 R
+/Resources 1478 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 1453 0 R
+/Annots [ 1485 0 R ]
+>> endobj
+1485 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[0 1 1]
+/Rect [63.4454 757.0719 452.088 767.2337]
+/Subtype/Link/A<</Type/Action/S/URI/URI(ftp://ftp.auscert.org.au/pub/auscert/advisory/AL-1999.004.dns_dos)>>
+>> endobj
+1481 0 obj <<
+/D [1479 0 R /XYZ 56.6929 794.5015 null]
+>> endobj
+534 0 obj <<
+/D [1479 0 R /XYZ 56.6929 739.5018 null]
+>> endobj
+1486 0 obj <<
+/D [1479 0 R /XYZ 56.6929 704.7645 null]
+>> endobj
+538 0 obj <<
+/D [1479 0 R /XYZ 56.6929 563.5308 null]
+>> endobj
+1487 0 obj <<
+/D [1479 0 R /XYZ 56.6929 535.7626 null]
+>> endobj
+542 0 obj <<
+/D [1479 0 R /XYZ 56.6929 418.2412 null]
+>> endobj
+1488 0 obj <<
+/D [1479 0 R /XYZ 56.6929 389.5504 null]
+>> endobj
+546 0 obj <<
+/D [1479 0 R /XYZ 56.6929 228.1296 null]
+>> endobj
+1235 0 obj <<
+/D [1479 0 R /XYZ 56.6929 194.8993 null]
+>> endobj
+1478 0 obj <<
+/Font << /F37 747 0 R /F67 1484 0 R /F11 1299 0 R /F39 863 0 R /F21 658 0 R /F23 682 0 R /F47 879 0 R /F53 962 0 R /F48 885 0 R /F62 995 0 R /F63 998 0 R >>
+/XObject << /Im2 984 0 R >>
+/ProcSet [ /PDF /Text ]
+>> endobj
+1491 0 obj <<
+/Length 533       
+/Filter /FlateDecode
+>>
+stream
+xÚ¥TM�›0½ó+|©¸6Æ`³IÚ²RÓ4a«ÕxT‚Ó@6Úýõµ3·¶ôTEóÆoÞ|x€"b~	Ž	“1JeŒ9¡•[� µ9ûêQÇ	Ϥð–u—{Ÿ¿°I,“(AùË�–ÀDŠòêÉÍóé"#Nü!Oˆ—Í&à‘ðXNÇ‹,4þ1[f“éb¤±Ÿga,ˆ0ñÌ)Lg£ïÙøó	P§Ôžó{oš_¹m–f»øí==T™žï=‚™
 ˜J¡­s†yÌØÙÓxKïçEðæô:4<Îæ"J¦±¡éq‰fŽìô–z«lO‰ßÕ½êÀ,7ZwÎÝkûäþ/¥và)šŒê­-¶uið[xØUE¯*8˜ØyžE_€U· ã`wXUz[€×H¶.²R�Z!—{Sô7üÐŽÛôRŠ%çÑ©
'ÂTÊä)…��Ú{�2è]·ÊÜ,#‰Ÿoê˜Çâ- ”úŸŒ‰I§Àßë]بWÕ\cÁ*uÛ›|u»vx_÷v
+endobj
+1490 0 obj <<
+/Type /Page
+/Contents 1491 0 R
+/Resources 1489 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 1493 0 R
+>> endobj
+1492 0 obj <<
+/D [1490 0 R /XYZ 85.0394 794.5015 null]
+>> endobj
+1489 0 obj <<
+/Font << /F37 747 0 R /F23 682 0 R >>
+/ProcSet [ /PDF /Text ]
+>> endobj
+1496 0 obj <<
+/Length 69        
+/Filter /FlateDecode
+>>
+stream
+xÚ3T0
+endobj
+1495 0 obj <<
+/Type /Page
+/Contents 1496 0 R
+/Resources 1494 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 1493 0 R
+>> endobj
+1497 0 obj <<
+/D [1495 0 R /XYZ 56.6929 794.5015 null]
+>> endobj
+1494 0 obj <<
+/ProcSet [ /PDF ]
+>> endobj
+1500 0 obj <<
+/Length 1964      
+/Filter /FlateDecode
+>>
+stream
+xÚ¥X[�ë¶~?¿ÂoѱV”D]Ò¢i³§I¶EÒ g�¢íé-imõH¢#Rv7¿¾3œ¡,ÛJS »&çÎá7äˆbÁ¿Ø2Œ’2ÝäeÊHÈMÕ¿‹6{à}óN°L*“P¦I“îV&E(‹8ßl—F¾zy÷øu,6qfY,7/¯³¯,/Â2IËÍKý�àé Ž¶¶±Œ‚âáŸ/"µ4Ì‹\ Z.d˜—Qá^„Á¨§]טƒÖ¶ö³šHÃ$ÍbVË’0Ï"òS„âa+¢(
+žtßë�þ0j0Ó›‹
–Rz	Ÿ‹Â˜M<ÛϤ´¥ÁY�Ÿ šßÐì Ï4¨{{¦Ÿ�Q隣¡™ž¼öA]™=�zØÉ‘%›2,³8ãÀ =e*RJÈ
,%©v�±42º›l‹‹Ä™Õ3õ„Ér“v
+i	·¥Ý3éÀ–yíˆùðŠ&�Â8K<æc�ø¡›‚hïCû™<»úÐŒ­êhüýÔï Æס\@�•‰ó÷w= vV
+ŠØmT¹,(¾ÊÞñ‰}�q´€¨\Â&|&d¾vKÈTÝVŒÐhÆKI›S?s�@Õ+6¸k0mHšŽµÇrRϯÄ'¨
+ýf3GÕ51b‘æi‘diNŒ�‘Œâ�±ˆ±0·"ð0àâÄßZÕ7’\sÂw
"ó‡&0ÍåþF
—?$cRÍZº”í(õåŠ:é�H^�04g¢°û(½ÀÙWáÓ
7�˜¿S,[>°úŒ¹…;î3`ô¦'b�ÕÀ¤Ö^ïöEy˜]¹œ­Þv‹íçÞa¯Úák@n@þzh|ÇütÓOÓ0J¿mºã—¿ÞeÚâš(°ÁiÇEðá
êÍ�âÀz҃ѣm§žæˆ§çOŒ$ 
+­è×ØÚ:‰óÎÐÃBYn?z·XdÌqâd¾©Üä¤ÚNí:ørðï»QÕaáƒL·CÕMucVìâªV.Wª�4 Û8Hü»Uoy)”@»Zìo+B)ˆ×­©ôD9ƒ©;B.ÊõTyåvÂ)Î6™îZds§¡ÁÓÏMí­µ°r=¶ö�ä&vÓž®é^/yr€�¡¶¯ÓP;«y Â1{9B€FãŸà{ËוÂM>p\×-ž‘7>å	èWˆÌ¨W
+¥Ìrcø-Š¼ûãËü
+“¤%œ¡i±Iæ² —â~ÚøÑŸ/¯6³Âv¡ám’rá÷Î.zïá°ú‹EØûÛxà8KQ”×ñܼÍBw1\­ýÎÆð»•s^ÀÍQŠ’säjMkç/Ú,ÜÚmR¡ÈEz�ís³ã¾‡ê
+endobj
+1499 0 obj <<
+/Type /Page
+/Contents 1500 0 R
+/Resources 1498 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 1493 0 R
+/Annots [ 1507 0 R 1508 0 R ]
+>> endobj
+1507 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[0 1 1]
+/Rect [348.3486 128.9523 463.9152 141.0119]
+/Subtype/Link/A<</Type/Action/S/URI/URI(mailto:info@isc.org)>>
+>> endobj
+1508 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[0 1 1]
+/Rect [147.3629 116.9971 364.5484 129.0567]
+/Subtype/Link/A<</Type/Action/S/URI/URI(http://www.isc.org/services/support/)>>
+>> endobj
+1501 0 obj <<
+/D [1499 0 R /XYZ 85.0394 794.5015 null]
+>> endobj
+550 0 obj <<
+/D [1499 0 R /XYZ 85.0394 769.5949 null]
+>> endobj
+1502 0 obj <<
+/D [1499 0 R /XYZ 85.0394 576.7004 null]
+>> endobj
+554 0 obj <<
+/D [1499 0 R /XYZ 85.0394 576.7004 null]
+>> endobj
+1503 0 obj <<
+/D [1499 0 R /XYZ 85.0394 548.3785 null]
+>> endobj
+558 0 obj <<
+/D [1499 0 R /XYZ 85.0394 548.3785 null]
+>> endobj
+1504 0 obj <<
+/D [1499 0 R /XYZ 85.0394 518.5228 null]
+>> endobj
+562 0 obj <<
+/D [1499 0 R /XYZ 85.0394 460.6968 null]
+>> endobj
+1505 0 obj <<
+/D [1499 0 R /XYZ 85.0394 425.0333 null]
+>> endobj
+566 0 obj <<
+/D [1499 0 R /XYZ 85.0394 260.2468 null]
+>> endobj
+1506 0 obj <<
+/D [1499 0 R /XYZ 85.0394 224.698 null]
+>> endobj
+1498 0 obj <<
+/Font << /F21 658 0 R /F23 682 0 R /F11 1299 0 R /F39 863 0 R >>
+/ProcSet [ /PDF /Text ]
+>> endobj
+1511 0 obj <<
+/Length 69        
+/Filter /FlateDecode
+>>
+stream
+xÚ3T0
+endobj
+1510 0 obj <<
+/Type /Page
+/Contents 1511 0 R
+/Resources 1509 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 1493 0 R
+>> endobj
+1512 0 obj <<
+/D [1510 0 R /XYZ 56.6929 794.5015 null]
+>> endobj
+1509 0 obj <<
+/ProcSet [ /PDF ]
+>> endobj
+1515 0 obj <<
+/Length 2543      
+/Filter /FlateDecode
+>>
+stream
+xÚuYYsÛ8~ϯð[誑ÂûØ7[ÎádìrYÎNÕnö
"!	k’`ÒŠæ×O7ºyØéTJ@£hôñuƒö.\øç]¤ÑÚ
²ð"ÉÂuäzÑE^½s/°öù�Ç<a¬£0`²°ºŠ‚t¥~r±šorýôîÃ'ß»ðÝuûÑÅÓ~<+N’µ¥OÅ�«¦‘u¡~]®üÈu®.ÿ÷ô•ÄÂu’&Š¹pD²ã$žKäÒŒÌ^¸ÂØgæ8Z‡A’óÚ»\y®[çϵ>•²8T²îf²Þ:‹¢A6Ö^yƒì$Mú]·JîiøE™N·gšh&vGIƒ›û-
D]°èíý
\dë,öc>Ӈ˹!ë[vGÝŽ d¼~ø~gx©óÃuý\‰)´¶»ôyPu­êQ¬6sñ]	UÓø^TLÝžM'+Éó¾mñ
+�\Ó±8Ø�ãràÔòD3hÄ“0D,¤É[µ³:ÝêdÐ9 QÔ€EÒÔ'{)Áúrø®óɪ¢«q—�µÑ$”ÄêY_ÝÔ'ÿ=>\f¾sUË"'Á_‘k/ƒ“†®
+¦6pkK­é·ç÷'‘s[w²…-@Ø£å�Ì­ßp,XBšÎÞ'h7ü•¿Ù*Œpv
+÷Ãa…|‘¥nl Ø-H±ÈZyá6µ¨€÷ƒ(
+RÜŠ1ÏuL~”6�`l�¿‚~ZѨ¢<ÓCƒÚ̓
+’
r�”OœBç=Á	1j"«¢ºÑpQɧUäzý"GöÄÙ	G,ØÝfS6äÐBdz˜€z²Ó„Q™DÏ
B0q
+�ã”U#7Cã@Q²€.ÿ¾ô
+ÝD‘øñðñ^=:\è±æí
+®o¬ƒñ+ñ'E\2}8Ç’;i%Ò‡ï&ª°Wõ\~jÀaÛÍ{³˜¢GË!zeoA
_�^†NmÞxš^Xð”Ð;’ù‚Ïr{z8Ø'"Hóȃ…×UØNÑô�
+endobj
+1514 0 obj <<
+/Type /Page
+/Contents 1515 0 R
+/Resources 1513 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 1493 0 R
+>> endobj
+1516 0 obj <<
+/D [1514 0 R /XYZ 85.0394 794.5015 null]
+>> endobj
+570 0 obj <<
+/D [1514 0 R /XYZ 85.0394 769.5949 null]
+>> endobj
+1517 0 obj <<
+/D [1514 0 R /XYZ 85.0394 573.5449 null]
+>> endobj
+574 0 obj <<
+/D [1514 0 R /XYZ 85.0394 573.5449 null]
+>> endobj
+1518 0 obj <<
+/D [1514 0 R /XYZ 85.0394 539.0037 null]
+>> endobj
+578 0 obj <<
+/D [1514 0 R /XYZ 85.0394 539.0037 null]
+>> endobj
+1519 0 obj <<
+/D [1514 0 R /XYZ 85.0394 510.2426 null]
+>> endobj
+1513 0 obj <<
+/Font << /F21 658 0 R /F23 682 0 R >>
+/ProcSet [ /PDF /Text ]
+>> endobj
+1522 0 obj <<
+/Length 2893      
+/Filter /FlateDecode
+>>
+stream
+xÚ­ksã¸í{~…¿Õ™‰IÔ3ÛéL.›ls×Ë¥‰;íÌíÍ”–h[]Yò‰r²¹__€
+'é<%Ø«Ô4hνd®J%µÊ‰¢¨ó¬ö­Ú­TCSßu]"�UN ‚yH‚ïäêfÈõµ)ZE¸zMˆJɦ|ãeeÉõ^e-3³”í–—ª\~4
+hfáyN†¾9fùVT²"ŸFÒÐg[Ø>k$ŒÓ­%ya4P’~¯$œø#Ìùp
+"
‡Ï®ëgýFÐ\í‰s&[ÔÂŒjp`‹1ãÄ.}Qe½ß©ª%€Ý)«+]ðq‰§
+~H¿°OQ­4Áæ:“¥$o…Ù=ŠR©–fì-DM¸û"�çËm/Èá¤ÝÒÌNßöæ@1t$ê÷Š,s¸b,Â)PøTE&u;aBá9±èèðV$ÑÜ\{؆,CfáCƒUP9'°ÐßHI"ð掉z�Û›äÄ”‰ïˆDø¼ùuõöž�è‚��"FHÜm,$BŒëàæV4P}#¡ô
+±AiÏK:·úCÛÅÂñCa×R¾_~à‰�-³¤üœö
+É‘
9R �P)�0¦†Œi‚4`(M§6ó'óÃ^S(Wr7dg51™hïŸÏ=¨m/̹?5YŽ¥ÚlË7“ìÌ(Ø… ¾È5o]÷"L¸6xc0¡q²m
+©—´¦5õÃD 	œ$ŒlH„r«å&Âçݳ5º?¾·hdµÁk+ §/-UçI0>
+è¾ÏÝG$”uf,Õ­DC¡Æüx¾;˜t
+(–
"—ÜYi4¹B™º¦qfèY'ÉíŽÑ–�\z
¬nÌ\³&ÊKŸ	‰•v(Äð1“‘㣓Æ|ÒØŠž«�ˈ�p}µ6eè£[SWöj›ŸMñ¢Âú`K@®Ö j]¼©VP%Û
+·KÊÿóWÞþCw;"Iüé¸~œ8
Ô¥V(<AêžHn?ŸŠþ_`Ý2ƒendstream
+endobj
+1521 0 obj <<
+/Type /Page
+/Contents 1522 0 R
+/Resources 1520 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 1493 0 R
+/Annots [ 1526 0 R 1527 0 R ]
+>> endobj
+1526 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[0 1 1]
+/Rect [253.7995 146.8976 417.685 158.9572]
+/Subtype/Link/A<</Type/Action/S/URI/URI(ftp://www.isi.edu/in-notes/)>>
+>> endobj
+1527 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[0 1 1]
+/Rect [63.4454 108.9117 208.8999 119.0735]
+/Subtype/Link/A<</Type/Action/S/URI/URI(http://www.ietf.org/rfc/)>>
+>> endobj
+1523 0 obj <<
+/D [1521 0 R /XYZ 56.6929 794.5015 null]
+>> endobj
+582 0 obj <<
+/D [1521 0 R /XYZ 56.6929 652.1213 null]
+>> endobj
+1524 0 obj <<
+/D [1521 0 R /XYZ 56.6929 614.8935 null]
+>> endobj
+586 0 obj <<
+/D [1521 0 R /XYZ 56.6929 614.8935 null]
+>> endobj
+1072 0 obj <<
+/D [1521 0 R /XYZ 56.6929 584.5024 null]
+>> endobj
+590 0 obj <<
+/D [1521 0 R /XYZ 56.6929 289.5256 null]
+>> endobj
+1525 0 obj <<
+/D [1521 0 R /XYZ 56.6929 251.3901 null]
+>> endobj
+594 0 obj <<
+/D [1521 0 R /XYZ 56.6929 251.3901 null]
+>> endobj
+900 0 obj <<
+/D [1521 0 R /XYZ 56.6929 222.7156 null]
+>> endobj
+1528 0 obj <<
+/D [1521 0 R /XYZ 56.6929 53.7852 null]
+>> endobj
+1529 0 obj <<
+/D [1521 0 R /XYZ 56.6929 53.7852 null]
+>> endobj
+1520 0 obj <<
+/Font << /F37 747 0 R /F23 682 0 R /F21 658 0 R /F47 879 0 R /F53 962 0 R /F11 1299 0 R /F39 863 0 R >>
+/ProcSet [ /PDF /Text ]
+>> endobj
+1532 0 obj <<
+/Length 2825      
+/Filter /FlateDecode
+>>
+stream
+xÚµZ]{£6¾Ï¯ð¥ý<-’ KÇö¤É4™4v·Û�α›g0¸g&ýõ{„>äζûä" ôâóžO	<òà�"†<ÊýQÈ}Ä<ÌFëý•7ÚÂÜíV2×ZèÚ–ºY]ýó
Gñ€£Õgk­yQ„G«ÍÇñôéiñ8¿û÷äš0o<E“kæyzt¶XN®Ã€‹	*¦o|swóã݇Ûçéӿʇ~ó˜7}œË›åÏ··‹åj¡nŸÓùÝã-ˆàɧÕýÕbe^ÛþiØ£â�¿úøÉmàÞ_yˆòˆ�¾Â�‡0çd´¿òȨT�dWË«ŸÌ‚ÖlýhŸª�‹HØ£+‚G#Îi)‹qPBke-«8ßÄÇM9ø[¨�(c—h²¤$4í£IK	ä�Ïïf $ÿS3EÞÝ	m¤Î±}ÛD0c(
+)kƒÏ‹}œæ’ÐÇxŸ”ŠwBBy5+òur¨Ô8èH^¼‹×i–ViRë«ó3qè!„¼ Àø‡|äi‚	£Érì¡X‰IuLK%õX¼&û—ä(ï0�B4ÈÀVüKŒXRF´”Ås0₶éb0bƒ_dänÈ’}’Wq•y‡—å!Y§¿yYËÙsr&@¿ö’#oþ>Š�(½@‘-5L‘‘ÒñÐá3N䆡3è~†ZØqš©Xœª4ßv8¨v‰¼°©\¾•U²ïs1Òç¼ÍÇLiÿ)>‚æ7ÛD�ßÇù)>¾ÕH-ÙŠpׄøˆG Z*~€O꥟ŽÅ¡(m)—^@Eäw–”ƒ;-eÜ‹s‡{9¡-òºØäÙàwùú8ÁÑXz�âñ?E®([M0Æãcœ—Ÿµ�kç�Ë>ú|Œp
+�ªèf1ˆ{²¶À,@^C-·{FæBþ¿9•;yµÈþЉ픽ý&A$¢ä–”ƒ	-e˜ ^ä`Âm1ÑÅ`ÂL¶ ÒWÕâõÎT:è~:%Ç�²›r„I@úSÑ4ßÈÄ÷U×qq=°Þ½GÃz‡¦
CP½ wKÊ¡w-eô„.pA[zïbèÝ_|«’¼4	Æ$§²“�ŒòE?¼€;Ow½g�F¡€ùŸóŽÃô1|‰KÊA�–²( 
+\Ð]ì

+lðÇ"¿–EWrܧ¹®ÈŒÆe‚©£G²I¥¯ÃC$d´ß
fÇø«`VØôëžêÞ^"ˆ|nÝÛRú7RF÷‘洞�Ð�îÏ°ûuß_&ª* lü>y“M¯UýEÐ䄼JMM’ÒEàBÂEVË»Û
!„"/bØâj<nÀCüq:Ácå$”�?¨©ÛÓfé»”E
¡Ñx®fqY]˼o Zy?‹¿h—£-#0}Û�2”_&œŒ“,ƒ\Iœ:XªôD<(›í$QQ~ÁN,)‡�h)c'œz;qA[vÒÅ°¼e' i'"}—Uü’¥åN4S®˜¹z¿P;ŠÏÏC¡3âÈçAgÓh®8ô2¸L•µ#áfÈçˆr‰!KÊÁ�–²r$2'´ÅP{€!Ü(û9ùý”è�f,»ÇŸ…ÚÒmW'ImÙ�%�׫s\9äÆÔ”ðÿ7[#àKlYR¶´”f‹z^è`Ëm±ÕÅ`ËRZ?ß'jò�j¨-ÀqM†|D·kâF¶k½Á#ƃ6IÎ0×ÞÛssƒ)�è7–”ƒ-e¸	œ9ÑmqÓÅàÆ¿Mr¨¯…bÃP•V"Ú…
Ü_Óu"§¦Ù¶€©Ý^ÎÉ°'ib%ÜËX	=>(–éæT{-éÕp!è¿].e~ót^“§<®\Ë�ÏüN9´Tô¿ÿç}õé­ì
+¶º/ÓÃi&·hÞêß¡fÔ_¦/Å«=sß²²~e|–pu?øCœejîú*ló£ýû›<€æ©»¿Ù4ª
mõÖÒwm{RßCKqšµ-5lÖFʘ5!³vB7f}†ÝoÖ-ð»|SÛ˜n+Ÿ“²È^µ¢—§Ã¡8Vgçr1ëËÔ
ƒØ±þØ?+ò£¡zž¬Ûá†
+±ŠSzIï–”CïZÊè=¢Ô¡w´¥÷.ö€ÞmðÕNFƒ”/
]xœ½•i)Źµfk
®ÕÖ\éL ®íLÐð©p’f¯M¬Šxõ%Í´Ü-ƒ‹g=	�P’Š�àã@wFªžV‹¶êi Ó$“pŒ"^Ø#µ¥†É4RšLßs‘é„nÈ<Ãî'³^Ìí¼€y¾U
É|\lN*²‹ÑZÁBX”disæлsùбØÅ”ÕĈç§òYèzº†11ú FŒ�ª;òdw$^æ!.ËDGn¹9ª [œ6LjHp•IÿnÐφé0
+=|a¿Ô–rЯ¥,ú1Ô	mÑßÅ ßWgU±.Ä.øÌC±él FD¥oíÕbD&&áÈMb‚;¹û}nýlŸ3C¯îs;s,“&,Ú63a;²}PâÚ,”G«•[ìëÞ2–Îñò_´¨‚™èÌÝvaI9ìBK5vá;΃�Ж]t±ì¹TÖó¢8„È#ëB”õMm”F*ÊSU׉‹ÆÄ�Ù�ì5,>}ñ­}ʸÞ´#š‰È21ú ÄMŒƒsu\bZFñ÷ÃY
‚©À²¸ ¡£ùÈ

+’Xï*
+endobj
+1531 0 obj <<
+/Type /Page
+/Contents 1532 0 R
+/Resources 1530 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 1589 0 R
+>> endobj
+1533 0 obj <<
+/D [1531 0 R /XYZ 85.0394 794.5015 null]
+>> endobj
+1534 0 obj <<
+/D [1531 0 R /XYZ 85.0394 752.3015 null]
+>> endobj
+1535 0 obj <<
+/D [1531 0 R /XYZ 85.0394 752.3015 null]
+>> endobj
+1536 0 obj <<
+/D [1531 0 R /XYZ 85.0394 752.3015 null]
+>> endobj
+1537 0 obj <<
+/D [1531 0 R /XYZ 85.0394 746.3107 null]
+>> endobj
+1538 0 obj <<
+/D [1531 0 R /XYZ 85.0394 731.5461 null]
+>> endobj
+1539 0 obj <<
+/D [1531 0 R /XYZ 85.0394 728.1497 null]
+>> endobj
+1540 0 obj <<
+/D [1531 0 R /XYZ 85.0394 713.3851 null]
+>> endobj
+1541 0 obj <<
+/D [1531 0 R /XYZ 85.0394 709.9887 null]
+>> endobj
+1542 0 obj <<
+/D [1531 0 R /XYZ 85.0394 651.9592 null]
+>> endobj
+1016 0 obj <<
+/D [1531 0 R /XYZ 85.0394 651.9592 null]
+>> endobj
+1543 0 obj <<
+/D [1531 0 R /XYZ 85.0394 651.9592 null]
+>> endobj
+1544 0 obj <<
+/D [1531 0 R /XYZ 85.0394 648.8377 null]
+>> endobj
+1545 0 obj <<
+/D [1531 0 R /XYZ 85.0394 634.0731 null]
+>> endobj
+1546 0 obj <<
+/D [1531 0 R /XYZ 85.0394 630.6767 null]
+>> endobj
+1547 0 obj <<
+/D [1531 0 R /XYZ 85.0394 615.9121 null]
+>> endobj
+1548 0 obj <<
+/D [1531 0 R /XYZ 85.0394 612.5156 null]
+>> endobj
+1549 0 obj <<
+/D [1531 0 R /XYZ 85.0394 585.7959 null]
+>> endobj
+1550 0 obj <<
+/D [1531 0 R /XYZ 85.0394 582.3994 null]
+>> endobj
+1551 0 obj <<
+/D [1531 0 R /XYZ 85.0394 567.6349 null]
+>> endobj
+1552 0 obj <<
+/D [1531 0 R /XYZ 85.0394 564.2384 null]
+>> endobj
+1553 0 obj <<
+/D [1531 0 R /XYZ 85.0394 549.5337 null]
+>> endobj
+1554 0 obj <<
+/D [1531 0 R /XYZ 85.0394 546.0774 null]
+>> endobj
+1555 0 obj <<
+/D [1531 0 R /XYZ 85.0394 531.3128 null]
+>> endobj
+1556 0 obj <<
+/D [1531 0 R /XYZ 85.0394 527.9163 null]
+>> endobj
+1557 0 obj <<
+/D [1531 0 R /XYZ 85.0394 513.1518 null]
+>> endobj
+1558 0 obj <<
+/D [1531 0 R /XYZ 85.0394 509.7553 null]
+>> endobj
+1559 0 obj <<
+/D [1531 0 R /XYZ 85.0394 483.0356 null]
+>> endobj
+1560 0 obj <<
+/D [1531 0 R /XYZ 85.0394 479.6391 null]
+>> endobj
+1561 0 obj <<
+/D [1531 0 R /XYZ 85.0394 464.8745 null]
+>> endobj
+1562 0 obj <<
+/D [1531 0 R /XYZ 85.0394 461.4781 null]
+>> endobj
+1563 0 obj <<
+/D [1531 0 R /XYZ 85.0394 446.7135 null]
+>> endobj
+1564 0 obj <<
+/D [1531 0 R /XYZ 85.0394 443.3171 null]
+>> endobj
+1565 0 obj <<
+/D [1531 0 R /XYZ 85.0394 428.5525 null]
+>> endobj
+1566 0 obj <<
+/D [1531 0 R /XYZ 85.0394 425.156 null]
+>> endobj
+1567 0 obj <<
+/D [1531 0 R /XYZ 85.0394 355.0758 null]
+>> endobj
+1568 0 obj <<
+/D [1531 0 R /XYZ 85.0394 355.0758 null]
+>> endobj
+1569 0 obj <<
+/D [1531 0 R /XYZ 85.0394 355.0758 null]
+>> endobj
+1570 0 obj <<
+/D [1531 0 R /XYZ 85.0394 352.0499 null]
+>> endobj
+1571 0 obj <<
+/D [1531 0 R /XYZ 85.0394 337.3452 null]
+>> endobj
+1572 0 obj <<
+/D [1531 0 R /XYZ 85.0394 333.8889 null]
+>> endobj
+1573 0 obj <<
+/D [1531 0 R /XYZ 85.0394 309.8192 null]
+>> endobj
+1574 0 obj <<
+/D [1531 0 R /XYZ 85.0394 303.7727 null]
+>> endobj
+1575 0 obj <<
+/D [1531 0 R /XYZ 85.0394 278.3282 null]
+>> endobj
+1576 0 obj <<
+/D [1531 0 R /XYZ 85.0394 273.6565 null]
+>> endobj
+1577 0 obj <<
+/D [1531 0 R /XYZ 85.0394 246.9367 null]
+>> endobj
+1578 0 obj <<
+/D [1531 0 R /XYZ 85.0394 243.5403 null]
+>> endobj
+1579 0 obj <<
+/D [1531 0 R /XYZ 85.0394 173.5556 null]
+>> endobj
+1580 0 obj <<
+/D [1531 0 R /XYZ 85.0394 173.5556 null]
+>> endobj
+1581 0 obj <<
+/D [1531 0 R /XYZ 85.0394 173.5556 null]
+>> endobj
+1582 0 obj <<
+/D [1531 0 R /XYZ 85.0394 170.4341 null]
+>> endobj
+1583 0 obj <<
+/D [1531 0 R /XYZ 85.0394 144.9896 null]
+>> endobj
+1584 0 obj <<
+/D [1531 0 R /XYZ 85.0394 140.3179 null]
+>> endobj
+1585 0 obj <<
+/D [1531 0 R /XYZ 85.0394 113.5982 null]
+>> endobj
+1586 0 obj <<
+/D [1531 0 R /XYZ 85.0394 110.2017 null]
+>> endobj
+1587 0 obj <<
+/D [1531 0 R /XYZ 85.0394 95.4372 null]
+>> endobj
+1588 0 obj <<
+/D [1531 0 R /XYZ 85.0394 92.0407 null]
+>> endobj
+1530 0 obj <<
+/Font << /F37 747 0 R /F21 658 0 R /F23 682 0 R /F47 879 0 R >>
+/ProcSet [ /PDF /Text ]
+>> endobj
+1592 0 obj <<
+/Length 2889      
+/Filter /FlateDecode
+>>
+stream
+xÚµšÝw›:ÀßóWøÑ>§ÑEŸ�$v·‰›µ“·ÄVN0¤·Í¿#ô�À zwÏž<¤AƒõÓŒfFà‰xâùÈ�H4	"yö&Ûý™3ù}WgXÊœ+¡sSêâþì�÷4˜D(ò‰?¹2Æ
+‘†xr¿û2�E3Á™^,/n–Ÿ®ÖñÝõ_³sâ9Ó¿ωWsq³y¸ºZlîòv½ˆçËÕˆàÙyàGÎ4¾»[¬æË?EÌGutëåb3ûzÿálq¯_ÛüiØ¡ü�¿Ÿ}ùêLvð?œ9ˆF¡7ù	7ÂQD&û3×£Ès)U-ÙÙæì_z@£·~´wª°ƒõIÏ\<ÁEžGZ“åEȧ„Ö“µfeq<l™œ¶-;q}?ƒx{eå௤€°4¤ÄKÑ>€JŠ¿Ó—õûKŒCúµ«ÓávÕZêT·k.Lä‘ ­{Å~ÂÏÇt:_mÄÅz-ØߎCò´J‹¼ž“ÎOÁŽÓJ}x	>Ð;xŠ8ÓKô~‘)c,~°Ã‡ÓçäPÕxz#»âú?™Þ&ûä¥(eïZö>dÙ>És9h’ïDóÝ“H
~[l_’WVRxÞfB½Ò¹XÂ>>m«âÞ£¦‹ÎAC„ý(B¡ïŽ6¥†	k)M8püaÂVÕ
áݽ„[ºXøé«M|§–=7¦m½˜Aw‘�ä/�ø�Òü›¸˜øh²÷²ÈX–%ò™.w˜C
+jt¼G¯
~c¬�úqe×õ‚ÐZÂNû{ÞH`dJY¨*)Mû–}ÕªÚ ÚÕÝOÕÔý ,fBò‚‹e^±CÎ*q'€óþB6¤%ìe�ÇJŠß.ÿ\¬Ååe!ì?—Ï^eÅc’‰ëx·SÎC>—¼¾rå=FïFÈÅ.5ð»"ΫÊÎ¥Q+±ìØnŸÓbÀhÃA¼^è"⮯)5ŒWKxÃa¼VÕ
Þݽx[ºùš¥;¦~m|„Ó‡<å Dcg›…–åŽåUÊã*v(EÓQº|ª|9´i_Nµ/§V_NQzÔôå‘Ø„ù`Iž²L!|14Þ"å¿å£-Ô°Ge¼–b}Ì™ƒö¢ADG@RÐJJƒ&Ô±€¶©6@wu÷ƒ6udr�/~mŸ“ü›œˆ9ËØ7µw	±­Ã…àÉ¥W›¾È*ô ‘¡íÀJ…NqÕÚ#»±“…%Èuý1
+†”…‚’Ò`¯·P°©6(tu÷S0uÏ7±øé•�°b³¼’MiÞ�weG<úvÄv¤óc SçÀ=Û%uQømBsIh‘”U–¼0ÙLkCß½Sq±°ûgM,&†af0s�†”…˜’2ˆb6Õ±®î~b¦îõ&þãvîÁÎ(j4À2¢5~Å
ñÿb›E�7
+jõ’¿¡æG(p�ÐØå���n`s¿k°‰`F�ÔÊ'­0ÝÐA>Lº¦)5SK0-»�UuóDw/Ì–îMUê]
+GtzÉbƒà“•¼Í­ò¾š!oPy£`ȯC.1Â�P„!ílòç9Cþ¬izŽ§
+™z…ñ‹ORøê¸Û!¨•Á�¹Å´ñ´ÿÄr]ˆã�؆”¶’2`GØ6Õì®î~ئn;û\(â/‚Øô©ŽZίY]™½°9–¢?•-Òõ††ë�´ë

×�-€ÀE
ÄÒ†ë
¥ë�Züý–ëõñ‰
Ë�þ�	CºÑUCÊBUI5T]KcUmPíêî§jêž³*Ù>³Ý³1Šìݨ@ôà‚Ù¥ÔõþÏ[%…42ÂþSj�–Òh‚ÐR
+5 ‰¥ngÓk�ì(îGi(Ž›t]$ãk}4HøÑ`'¿¿IËJ¦žÂ÷:íbo¸·<xúÅJãPöîFé�= ààö–j¸^È«ŠíóI�Æ
+<¢8²3„†�)!
Ì‹,¥
›ÞXWq/0S±¨¡†þªX^Ö'•°;¢¦
+ÿËãëkq¨„ÐòN4þ`‡R”Í¡Ñï«Ì9~dl„.ñ¦$ž¸.ö"_à­—²õú˜‚­&²õ³.˜C×Ç2Í“¼’]"†fUƒÓÚÚδ8¦e™öÕ€0&Ì‹·ÔClHY+)²¥š`UmPîêîÇl꾆IËô9£2¶‡ü%/~æ]£8ÜllOš\Ë´ËÞòFnu,0–Æwu,«ä©l2ÇÓí�ª3˜Öw	à—¬`Jx �Bãö9­®lé:–>8`ù,ä8Έ6¥†™k©æË3·ªn˜ŸèîeÞÒ­çc‘o‹Ý	ü«~‡—&‡éÖ?Áô~²"âø¡ÅÍ~6oZ_ˆñzH3•¼„ÃÉö"â±j�)e¡¤¤J¶ýÒªÚ ÔÕÝOÉÔ½fß�©Øãö,WÛ¡Þ"›#/~w]è
ó\ÍÝk–n�BzSÖ•ž»Ï,HžÜNáüâ�ìØ@¹Ü…Â�	Ý‘z�)e�¢¤4/²™ŽMµ
¥«»Š©{<½ßT‡ã¶n’ufÞ8ÛèÙ#ù
uÛ“ÿAÇ
+¶}ÎÁ=eês¦=÷qrê6=äé÷#ë#@ wÓ!(ôü 
¶í,c‰ÂÊŽ¥^I§‚ö;•“~f8ö•…!4LK	5eb©TÛô6¬ºŠ{Q™Šµ�sCåã܈û¸¤Õµ›s£N$—ñ*W—�+¤;vH†¾oä%MŸ´Nÿ`Ä:¥†ÇÍ”š�”šwJ¡‹º°•çâ#Èó×Ö–ei²W_,j%­Ø_kç3»Á@ÓRgñÿž¶gò“þÏŸíUñ
+endobj
+1591 0 obj <<
+/Type /Page
+/Contents 1592 0 R
+/Resources 1590 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 1589 0 R
+>> endobj
+1593 0 obj <<
+/D [1591 0 R /XYZ 56.6929 794.5015 null]
+>> endobj
+1594 0 obj <<
+/D [1591 0 R /XYZ 56.6929 748.5056 null]
+>> endobj
+1595 0 obj <<
+/D [1591 0 R /XYZ 56.6929 748.5056 null]
+>> endobj
+1596 0 obj <<
+/D [1591 0 R /XYZ 56.6929 748.5056 null]
+>> endobj
+1597 0 obj <<
+/D [1591 0 R /XYZ 56.6929 743.7078 null]
+>> endobj
+1598 0 obj <<
+/D [1591 0 R /XYZ 56.6929 719.6381 null]
+>> endobj
+1599 0 obj <<
+/D [1591 0 R /XYZ 56.6929 711.8197 null]
+>> endobj
+1600 0 obj <<
+/D [1591 0 R /XYZ 56.6929 697.0552 null]
+>> endobj
+1601 0 obj <<
+/D [1591 0 R /XYZ 56.6929 691.8868 null]
+>> endobj
+1602 0 obj <<
+/D [1591 0 R /XYZ 56.6929 665.1671 null]
+>> endobj
+1603 0 obj <<
+/D [1591 0 R /XYZ 56.6929 659.9987 null]
+>> endobj
+1604 0 obj <<
+/D [1591 0 R /XYZ 56.6929 635.929 null]
+>> endobj
+1605 0 obj <<
+/D [1591 0 R /XYZ 56.6929 628.1106 null]
+>> endobj
+1606 0 obj <<
+/D [1591 0 R /XYZ 56.6929 601.3909 null]
+>> endobj
+1607 0 obj <<
+/D [1591 0 R /XYZ 56.6929 596.2225 null]
+>> endobj
+1608 0 obj <<
+/D [1591 0 R /XYZ 56.6929 569.5028 null]
+>> endobj
+1609 0 obj <<
+/D [1591 0 R /XYZ 56.6929 564.3344 null]
+>> endobj
+1610 0 obj <<
+/D [1591 0 R /XYZ 56.6929 549.6297 null]
+>> endobj
+1611 0 obj <<
+/D [1591 0 R /XYZ 56.6929 544.4015 null]
+>> endobj
+1612 0 obj <<
+/D [1591 0 R /XYZ 56.6929 529.6968 null]
+>> endobj
+1613 0 obj <<
+/D [1591 0 R /XYZ 56.6929 524.4686 null]
+>> endobj
+1614 0 obj <<
+/D [1591 0 R /XYZ 56.6929 500.3989 null]
+>> endobj
+1615 0 obj <<
+/D [1591 0 R /XYZ 56.6929 492.5805 null]
+>> endobj
+1616 0 obj <<
+/D [1591 0 R /XYZ 56.6929 467.136 null]
+>> endobj
+1617 0 obj <<
+/D [1591 0 R /XYZ 56.6929 460.6924 null]
+>> endobj
+1618 0 obj <<
+/D [1591 0 R /XYZ 56.6929 436.6227 null]
+>> endobj
+1619 0 obj <<
+/D [1591 0 R /XYZ 56.6929 428.8043 null]
+>> endobj
+1620 0 obj <<
+/D [1591 0 R /XYZ 56.6929 414.0996 null]
+>> endobj
+1621 0 obj <<
+/D [1591 0 R /XYZ 56.6929 408.8714 null]
+>> endobj
+1622 0 obj <<
+/D [1591 0 R /XYZ 56.6929 382.1516 null]
+>> endobj
+1623 0 obj <<
+/D [1591 0 R /XYZ 56.6929 376.9833 null]
+>> endobj
+1624 0 obj <<
+/D [1591 0 R /XYZ 56.6929 350.2636 null]
+>> endobj
+1625 0 obj <<
+/D [1591 0 R /XYZ 56.6929 345.0952 null]
+>> endobj
+1626 0 obj <<
+/D [1591 0 R /XYZ 56.6929 321.0255 null]
+>> endobj
+1627 0 obj <<
+/D [1591 0 R /XYZ 56.6929 313.2071 null]
+>> endobj
+1628 0 obj <<
+/D [1591 0 R /XYZ 56.6929 298.5024 null]
+>> endobj
+1629 0 obj <<
+/D [1591 0 R /XYZ 56.6929 293.2742 null]
+>> endobj
+1630 0 obj <<
+/D [1591 0 R /XYZ 56.6929 267.8297 null]
+>> endobj
+1631 0 obj <<
+/D [1591 0 R /XYZ 56.6929 261.3861 null]
+>> endobj
+1632 0 obj <<
+/D [1591 0 R /XYZ 56.6929 199.468 null]
+>> endobj
+1633 0 obj <<
+/D [1591 0 R /XYZ 56.6929 199.468 null]
+>> endobj
+1634 0 obj <<
+/D [1591 0 R /XYZ 56.6929 199.468 null]
+>> endobj
+1635 0 obj <<
+/D [1591 0 R /XYZ 56.6929 191.7053 null]
+>> endobj
+1636 0 obj <<
+/D [1591 0 R /XYZ 56.6929 176.9408 null]
+>> endobj
+1637 0 obj <<
+/D [1591 0 R /XYZ 56.6929 171.7724 null]
+>> endobj
+1638 0 obj <<
+/D [1591 0 R /XYZ 56.6929 157.0677 null]
+>> endobj
+1639 0 obj <<
+/D [1591 0 R /XYZ 56.6929 151.8395 null]
+>> endobj
+1640 0 obj <<
+/D [1591 0 R /XYZ 56.6929 137.1348 null]
+>> endobj
+1641 0 obj <<
+/D [1591 0 R /XYZ 56.6929 131.9066 null]
+>> endobj
+1642 0 obj <<
+/D [1591 0 R /XYZ 56.6929 117.2018 null]
+>> endobj
+1643 0 obj <<
+/D [1591 0 R /XYZ 56.6929 111.9736 null]
+>> endobj
+1644 0 obj <<
+/D [1591 0 R /XYZ 56.6929 97.2091 null]
+>> endobj
+1645 0 obj <<
+/D [1591 0 R /XYZ 56.6929 92.0407 null]
+>> endobj
+1590 0 obj <<
+/Font << /F37 747 0 R /F21 658 0 R /F23 682 0 R /F47 879 0 R >>
+/ProcSet [ /PDF /Text ]
+>> endobj
+1648 0 obj <<
+/Length 2544      
+/Filter /FlateDecode
+>>
+stream
+xÚ¥ZKs㸾ûWè(U�€ øÈM¶l�&3¶#y²IÍî�–`™ŠTHʳ³¿>
âA�" É¦|0	4ñýu7º›ÂxS‘$˜DIàQ„éd{¸B“=ÌÝ_a)3WBsSêúùê/w$š$^úáäùÕX+öPãÉóîÛtñôtû°\ýs6÷)š.¼Ùœ"¤Fon7³y&|‚ð©M¯WןW�÷ëÅÓlj‡~E-–âfóõþþvó|+o×·‹åêáDðì·çOW·ÏúµÍ­aDø;ÿçêÛoh²ƒ~ºBIb:ù7ÈÃIâOW
%
Q#ùÕæêïzAc¶}tLU”Ä�ýhDW>ž`ì%”ú=eÑĉOZe-6b[�GV¥MVµuWÃ[\ Kˈ cd	Žþm}wŠ"¿
11E^œÀû;@µÌ50MSêÅ¡&ì²<¤Y!ö�îY‘Õ
l¾¬j1Vvºhï÷§lÇ<þŽƒ-á�zAÆðB|ÝBü‹'þ.Xsjâ¡|g‡V‰;œÄ‘gU6çKr¨Û�r(\Ii•S9Tî‚6”>Ķ¨Ý¿)‡R*^[Þ2mRqu—åL\ݔůùû“àAÞVÕÇSNÓ Ì HŸŠ§ö“©äãš±ªa‡TÎ=n›Ò #!V2ÂúªL);ZJ“‘`ßN†º#ã{œŒø(:¤¹ô�b÷g)ñ1õÂ8öû”,ieúÆ{©fñô”V?4#¡�‘vNQ|�CÊÁˆ’RŒø##.hƒ‘!¶…üLù7UÖ°*“îñZJc]—e##Jz�³aÕ;«êÑ(Åà‚qØçáZòð%-Š¬ØØî9Î?f”N³ß3fñO �0Âhê„,I!M’�I\ƒ£
°…"ùk-Õ]¾g‘giÍê
S¬ù^Vÿî(ʶlœ£0ö"?ÆO’�é!Ëåtš¤µœþ…ûQ•íßA‘‚ì%sŸ$¥�WÌ߃V¸*Àæ
+i‡ÙL‚™‡&7;kž@£Ä‹¾�)˜RvÖµ”¦=ö©�v'tÇûö8ñ=ðì<§Ï3Œ10°Ï[½„(ßGSöò×ÙœþtUקÖ
+`¦µxf…ã‡âR+¦[%òñHQ
+ͳ�pUÉç[BX#îŽ"â6å¶ÌÇ¢.ñ¡Ä<
`µ¸ëj¤uk“¹–ŸÓ†¾L3Ø¢2ÃTÆd!dõuD^FhK!E:	G@vᜀ-”È?1’ÐŽCHGh‡Å�.ŽÇ<ÛêôFx5±Z>,TÉ0<&	`&„ÁC]
+/¦”�O-ÕñIÉ£ºãó{œÏøB÷FßYѵEï”Kɬ`à|*û㽜ÚÑ]9+áU}ŒÖÛtÙî&6Fãà/��ƒ)¤Sz9j8®AÊ
+§ý©n4‰•%ˆtÓ`ÙYPBÝ'©ÈQG»p;†Àã˜ÈÂÉb
§áY…Hvà¾)ù³¸†A•áÊ8åÀ~/öê»~¬¼VY³âÄ-}¼'`(ŠÌ¦Gœºâ>]ݲòÜ”öÜêF}î<eÆï4>�òŸùüÄÓ
+2jëHøÿûYF2òHlë¹B¦žDê¥øæ2|sýË­óWÿ/§÷Áendstream
+endobj
+1647 0 obj <<
+/Type /Page
+/Contents 1648 0 R
+/Resources 1646 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 1589 0 R
+>> endobj
+1649 0 obj <<
+/D [1647 0 R /XYZ 85.0394 794.5015 null]
+>> endobj
+1650 0 obj <<
+/D [1647 0 R /XYZ 85.0394 748.4854 null]
+>> endobj
+1651 0 obj <<
+/D [1647 0 R /XYZ 85.0394 748.4854 null]
+>> endobj
+1652 0 obj <<
+/D [1647 0 R /XYZ 85.0394 748.4854 null]
+>> endobj
+1653 0 obj <<
+/D [1647 0 R /XYZ 85.0394 743.3452 null]
+>> endobj
+1654 0 obj <<
+/D [1647 0 R /XYZ 85.0394 728.6405 null]
+>> endobj
+1655 0 obj <<
+/D [1647 0 R /XYZ 85.0394 723.1655 null]
+>> endobj
+1656 0 obj <<
+/D [1647 0 R /XYZ 85.0394 708.4607 null]
+>> endobj
+1657 0 obj <<
+/D [1647 0 R /XYZ 85.0394 702.9857 null]
+>> endobj
+1658 0 obj <<
+/D [1647 0 R /XYZ 85.0394 688.2211 null]
+>> endobj
+1659 0 obj <<
+/D [1647 0 R /XYZ 85.0394 682.8059 null]
+>> endobj
+1660 0 obj <<
+/D [1647 0 R /XYZ 85.0394 668.0414 null]
+>> endobj
+1661 0 obj <<
+/D [1647 0 R /XYZ 85.0394 662.6262 null]
+>> endobj
+1662 0 obj <<
+/D [1647 0 R /XYZ 85.0394 599.7666 null]
+>> endobj
+1663 0 obj <<
+/D [1647 0 R /XYZ 85.0394 599.7666 null]
+>> endobj
+1664 0 obj <<
+/D [1647 0 R /XYZ 85.0394 599.7666 null]
+>> endobj
+1665 0 obj <<
+/D [1647 0 R /XYZ 85.0394 591.7571 null]
+>> endobj
+1666 0 obj <<
+/D [1647 0 R /XYZ 85.0394 565.0374 null]
+>> endobj
+1667 0 obj <<
+/D [1647 0 R /XYZ 85.0394 559.6222 null]
+>> endobj
+1668 0 obj <<
+/D [1647 0 R /XYZ 85.0394 534.1777 null]
+>> endobj
+1669 0 obj <<
+/D [1647 0 R /XYZ 85.0394 527.4872 null]
+>> endobj
+1670 0 obj <<
+/D [1647 0 R /XYZ 85.0394 502.0427 null]
+>> endobj
+1671 0 obj <<
+/D [1647 0 R /XYZ 85.0394 495.3523 null]
+>> endobj
+1672 0 obj <<
+/D [1647 0 R /XYZ 85.0394 420.5376 null]
+>> endobj
+1673 0 obj <<
+/D [1647 0 R /XYZ 85.0394 420.5376 null]
+>> endobj
+1674 0 obj <<
+/D [1647 0 R /XYZ 85.0394 420.5376 null]
+>> endobj
+1675 0 obj <<
+/D [1647 0 R /XYZ 85.0394 412.5281 null]
+>> endobj
+1676 0 obj <<
+/D [1647 0 R /XYZ 85.0394 388.4584 null]
+>> endobj
+1677 0 obj <<
+/D [1647 0 R /XYZ 85.0394 380.3932 null]
+>> endobj
+1678 0 obj <<
+/D [1647 0 R /XYZ 85.0394 365.6884 null]
+>> endobj
+1679 0 obj <<
+/D [1647 0 R /XYZ 85.0394 360.2134 null]
+>> endobj
+1680 0 obj <<
+/D [1647 0 R /XYZ 85.0394 345.4488 null]
+>> endobj
+1681 0 obj <<
+/D [1647 0 R /XYZ 85.0394 340.0336 null]
+>> endobj
+1682 0 obj <<
+/D [1647 0 R /XYZ 85.0394 325.269 null]
+>> endobj
+1683 0 obj <<
+/D [1647 0 R /XYZ 85.0394 319.8539 null]
+>> endobj
+1684 0 obj <<
+/D [1647 0 R /XYZ 85.0394 295.7842 null]
+>> endobj
+1685 0 obj <<
+/D [1647 0 R /XYZ 85.0394 287.7189 null]
+>> endobj
+1686 0 obj <<
+/D [1647 0 R /XYZ 85.0394 272.9543 null]
+>> endobj
+1687 0 obj <<
+/D [1647 0 R /XYZ 85.0394 267.5392 null]
+>> endobj
+1688 0 obj <<
+/D [1647 0 R /XYZ 85.0394 252.7746 null]
+>> endobj
+1689 0 obj <<
+/D [1647 0 R /XYZ 85.0394 247.3594 null]
+>> endobj
+1690 0 obj <<
+/D [1647 0 R /XYZ 85.0394 223.2897 null]
+>> endobj
+1691 0 obj <<
+/D [1647 0 R /XYZ 85.0394 215.2245 null]
+>> endobj
+1692 0 obj <<
+/D [1647 0 R /XYZ 85.0394 149.4956 null]
+>> endobj
+1693 0 obj <<
+/D [1647 0 R /XYZ 85.0394 149.4956 null]
+>> endobj
+1694 0 obj <<
+/D [1647 0 R /XYZ 85.0394 149.4956 null]
+>> endobj
+1695 0 obj <<
+/D [1647 0 R /XYZ 85.0394 144.3554 null]
+>> endobj
+1696 0 obj <<
+/D [1647 0 R /XYZ 85.0394 120.2857 null]
+>> endobj
+1697 0 obj <<
+/D [1647 0 R /XYZ 85.0394 112.2205 null]
+>> endobj
+1698 0 obj <<
+/D [1647 0 R /XYZ 85.0394 97.4559 null]
+>> endobj
+1699 0 obj <<
+/D [1647 0 R /XYZ 85.0394 92.0407 null]
+>> endobj
+1646 0 obj <<
+/Font << /F37 747 0 R /F21 658 0 R /F23 682 0 R /F47 879 0 R >>
+/ProcSet [ /PDF /Text ]
+>> endobj
+1702 0 obj <<
+/Length 2122      
+/Filter /FlateDecode
+>>
+stream
+xÚ¥YKs㸾ûWèª*Bðà37ÙÒ8žñÚŽå­d33š‚%–)R+RžÑþú4Ð J$µ•”�n ?ôQø±‘ç?âÑ(ˆ\âQæ�’Í­`ìöŠžIÍ4±¹®_®þöI£ˆD>÷G/o–¬�Ð0d£—åWgJƒê\ß]ßß=Þ>OŸþñÛxÂ=ê|£�>Ì°³øõöv¾x™›îó|:»{¸6ž~D�éÓÓüav÷oŸ*©´¡ÞÌãï/Ÿ¯æ/Ͳí­1*Ôš¿úú�Ž–°ÃÏW”ˆ(ôF? C	‹">Ú\¹ž ž+DMÉ®WÿlZ£zj§©%\ø¼ÃVœ�#‘çñ–±¼ˆø‚m¬ÇײÈd%—¸ÇÙÃÂØF&û]ZŒi>Ý”½›.4ht
G‹×&ºp¬¹ÔÒ¾‚VN}ïû©fÆ9XņU7\çº]û1�mݳb§ùxârê<Ä©ZÌYÊJn�z4�™ÿ¬d^¦E®Ít²;R„�ëR²ÿ
+S|á̈™—U¿Ë1Ã×»1�%ê‰sÓ¸1ü_âýÛ&Î�”Ïq¾�w¥¶\+š4°ƒ>8W
éE�º$Ä£:
+‰"ïÀà—Xw“uƒCÔ�ƒ’Hò’Í5€CÍUã (
pRmápª»[w�ƒCƒƒjÕ8èvƒƒ�'!,æ7˜5GºÊÓ|…�é¾Zšÿ'î3HW‘î8w®	Nü×8âŽÌ2�T:Šqá<ró*wÆêù­(Æ)¥ý˜‰ˆP7º„™Å5€YÍuÄ,¢˜
©¶0;ÕÝ�™­»'7.‚Ý›,Þ¥ß(åI\5ÄúûŸ"¯]®Š«}—Sqð°íUsãU÷òGZv;
+p¹™Ll«ežúï…ÔƒÈyx¡Î³¹ú!m¸H}o
+ÌWP%ºQ�…A=-Í@Rà:Mb;4ظýØp�¸`ÂØX\ØÔ\6—¥AÕ6§º»±±u7õ¹[×…ªÕÔçÐÖL5LI}ãE@;ñ"M1^df/B±öåúó¼Ú°ùT¤yuœµ˜?§}ÊâUÎ.»|±
ZÇĆڊ‰µs~)²w¼;«ÞgC]$ëìPµŽ„Ž¾}…�u£<1PÈ/¼t“°¹úOLÃÕœ˜p¨T}<1gº;OLKwOUzzaÐ>ù³BëB®øZ\ϳéØóœå™S$}*v›¸3�ú°ò�»mçÀqº_íËê«Ó‡±‰€�á2ª!áA¹Gýæ‘�'.Î]rsi$Ívñ[ÕULSHÊ.Dæj	֬ЫgA¾»Yi¬
+ë˜èÊÿ€\åºØg†ªµªÆ«ÄïïûßU�Qg5 %©!¹Ú>Zcn„½©SŸ!Ñƺû<3þ$)6“.|¶qžjéŒ:¯ü≀Æ2-“,N7:‡ê�¸jXóñBçç®:s%võrá‹(+d-K¢øp��uüa„ÄøÉÒ7YÂò°§O+|Ëô'66E^­Í\8ïõ¬S¸lvlԬسW�¥´^²“©¶~Ö3¯f*IM=ëÇŒ²38Ðó  LPxuµbá¥ÂÎk±7±âúîav”ëB±ê7r)‰X}y“;åF½Ïì<„RïÂõËæ:O&°lâ(LgÖŸGµóÈ™ÚÎ<ÒÒŠy„zÆ­¨o[Ê^´
5Vć9Oñ>ÃIÓ.\œHº�Sá¤É»ŽпO÷j"s¡âÜvéj­“ˈ!lÀ
Õß+Ô¼ '¸ˆàÇ%L8	üöiñ}£ÌëºpØbXWŸ,ŠB\ÛB¾ÆeUlM ÈÞLÿŽ#�y†‚43OøÜSºN®tM52…kE’ÂY.{‹8¬ê£¼hs¬ÿïÿ¥¬ê% "컊p°¯‚³(µ—È=[yýÖùÒÿš`�£endstream
+endobj
+1701 0 obj <<
+/Type /Page
+/Contents 1702 0 R
+/Resources 1700 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 1589 0 R
+>> endobj
+1703 0 obj <<
+/D [1701 0 R /XYZ 56.6929 794.5015 null]
+>> endobj
+1704 0 obj <<
+/D [1701 0 R /XYZ 56.6929 749.4437 null]
+>> endobj
+1705 0 obj <<
+/D [1701 0 R /XYZ 56.6929 749.4437 null]
+>> endobj
+1706 0 obj <<
+/D [1701 0 R /XYZ 56.6929 749.4437 null]
+>> endobj
+1707 0 obj <<
+/D [1701 0 R /XYZ 56.6929 746.6461 null]
+>> endobj
+1708 0 obj <<
+/D [1701 0 R /XYZ 56.6929 722.5763 null]
+>> endobj
+1709 0 obj <<
+/D [1701 0 R /XYZ 56.6929 716.7581 null]
+>> endobj
+1710 0 obj <<
+/D [1701 0 R /XYZ 56.6929 701.9936 null]
+>> endobj
+1711 0 obj <<
+/D [1701 0 R /XYZ 56.6929 698.8254 null]
+>> endobj
+1712 0 obj <<
+/D [1701 0 R /XYZ 56.6929 684.1207 null]
+>> endobj
+1713 0 obj <<
+/D [1701 0 R /XYZ 56.6929 680.8926 null]
+>> endobj
+1714 0 obj <<
+/D [1701 0 R /XYZ 56.6929 656.8229 null]
+>> endobj
+1715 0 obj <<
+/D [1701 0 R /XYZ 56.6929 651.0047 null]
+>> endobj
+1716 0 obj <<
+/D [1701 0 R /XYZ 56.6929 636.3 null]
+>> endobj
+1717 0 obj <<
+/D [1701 0 R /XYZ 56.6929 633.072 null]
+>> endobj
+1718 0 obj <<
+/D [1701 0 R /XYZ 56.6929 609.0023 null]
+>> endobj
+1719 0 obj <<
+/D [1701 0 R /XYZ 56.6929 603.184 null]
+>> endobj
+1720 0 obj <<
+/D [1701 0 R /XYZ 56.6929 579.1143 null]
+>> endobj
+1721 0 obj <<
+/D [1701 0 R /XYZ 56.6929 573.2961 null]
+>> endobj
+1722 0 obj <<
+/D [1701 0 R /XYZ 56.6929 558.5914 null]
+>> endobj
+1723 0 obj <<
+/D [1701 0 R /XYZ 56.6929 555.3634 null]
+>> endobj
+1724 0 obj <<
+/D [1701 0 R /XYZ 56.6929 540.5988 null]
+>> endobj
+1725 0 obj <<
+/D [1701 0 R /XYZ 56.6929 537.4306 null]
+>> endobj
+1726 0 obj <<
+/D [1701 0 R /XYZ 56.6929 510.7109 null]
+>> endobj
+1727 0 obj <<
+/D [1701 0 R /XYZ 56.6929 507.5427 null]
+>> endobj
+598 0 obj <<
+/D [1701 0 R /XYZ 56.6929 477.5928 null]
+>> endobj
+1728 0 obj <<
+/D [1701 0 R /XYZ 56.6929 453.2532 null]
+>> endobj
+602 0 obj <<
+/D [1701 0 R /XYZ 56.6929 369.7201 null]
+>> endobj
+1729 0 obj <<
+/D [1701 0 R /XYZ 56.6929 345.3805 null]
+>> endobj
+1730 0 obj <<
+/D [1701 0 R /XYZ 56.6929 310.6805 null]
+>> endobj
+1731 0 obj <<
+/D [1701 0 R /XYZ 56.6929 310.6805 null]
+>> endobj
+1732 0 obj <<
+/D [1701 0 R /XYZ 56.6929 310.6805 null]
+>> endobj
+1733 0 obj <<
+/D [1701 0 R /XYZ 56.6929 310.6805 null]
+>> endobj
+1700 0 obj <<
+/Font << /F37 747 0 R /F21 658 0 R /F23 682 0 R /F47 879 0 R /F14 685 0 R >>
+/ProcSet [ /PDF /Text ]
+>> endobj
+1736 0 obj <<
+/Length 1917      
+/Filter /FlateDecode
+>>
+stream
+xÚµX[�Ûº~ϯ0Ð>h�ˆáE¤¤óÔÜÚì
²)š-ú�ìƒÖ¦m!²¤#É»1Šþ÷ÎpHÙòÊÇ(ŠÖäpøq8wJ,8ü‰E¦Wy²Hó„i.ôb¹{ÅXûÛ+áy­˜N”‚ÉÌj¬UÆt&ÓE|
+òîþÕ›¿J±�œ#õâ~=žeÒ”ñ|q¿ú½m[[¯ÊŸ7±Ô<zwópÿ+íJXš¥wq8!eFiãv|.ê}Q[ll?î	S‰‘~�ÑÌp�¹=‰ç<Z•äG•2e‰qWì¬ÇQ‹œåF£SÈŒ\¸Ù�û]Ê”Fî¾Ò jšû–Æû¡¬ÊápL°\ë X"˜Ì]æë¡nÚ¾twxõñ~Ô©áL(Ðh":Wsz §ÔÉ£dœÁíw„p6QùÉ
ƒIF®ñž´õí/½ížl÷à§ñ#ÝIŸ*Ið”éÜh87«Ug{o•ÉYpñ,QÂó�˜ËL¥Yft€\VÅ, ÌY–¥ù9àú*ຬl=š|*dÊ2ÉÓsÌÿÌv3Vèë:Ëñè5°§mºáO—4��ÿvUØ‚JÅrÁÕ9Þpo8´ÿÞÏ«xèDsx	“æ…½Wá¾mwÅò—¼õ/?ìa9ç,ɹ9‡NÆ‘ypy#V€œ+.§öù†Ð�•ÆÎuÃä·½íM;0Æ.E¼J%KRñG"þârÄ�\Óˆ�·—EÓ’™\¥D´ˆß-pMEÛTÍcQÅ-ÆBŽš
j½’s?|üúþ·¿¿ýr7rOR¾ÄÇ”ÿ².(ŠGüÎ5_5»¢¬!ý'<*ëuÓ튡l� òhÓ݈,jZÛ
«ðL=­4ýι²?ËÇÊyhšŠV
+ë.¦‰’vÏnbÅÓèv *�rõÄ�ÛœC‡»Lü™ª°*
"Ö+H,ž}[O¶–ÈEÝ?Ãq�Z~›“ÕóÐxØwµ]Ñòš®²;£[ ‰n�ÊíIm¸|„‡#>ÌÐ
J»‚+k˜}nú!”ùÓk9])# ¿ìʺ¼Q?tÅÐ8á�¼ïíŒK€0ùXg.¸ô@Ê„?48Ð%÷`×~Û4(ºáG1ZZ†Õ]OK�vY n¹YÓo9øÕà%Ô^€\ÑkXÈ@ÅùÂ�õÈЊ3	
RP‰µµC0׸àf÷»Úý€þ#xôlÓ½lrÐC{?´è!D¤ßmñdýìÜh½¯—E5žÖ¬g®0›h�þ¾Â–'*Ô>²s²<×pÇœ¥iJÿ¶¶Í~³�9*ÑÐg*uÍ´2¥çÁÀUJF5ÆxUpæÔ½"ús9l‰¶lv;Ð~\•µ¥5
+‰Í~gë¡GÓi	Æ%î¢êâÚ½'Ñü±–r׬<”³3þBXSªq
+0	¤PžLÝ~L!1ÅŠ’GrbPÈ´�Ô>GCgÇL%+ër‹‰ÞíboMÃ~—î4i<Ñ90ž1U‰C=U‰'9oÂí-^¬æLD·¦Eä7Iô¼µ5�0�¼,òi΄0‰7d¼�÷*�™Ð�
+;‘
+¢ô­]–è„Kš‡²§|Á¸IÈŠ/(yÎàõ!¯)PÂ[Æó<—UåBØCQú
+o§¾÷�P�c
µ·ž­¥>"†ÞÑÒÊ®ŒžÖQ¨™ž 5P~DrÍ›ÏC‰z*‹9?€ww¼àÏÿþôåóÇÿ¼a€×-g3ÅLfähg¨ð*ºß†«Rn>½~6æ|â C¹¨D97ù2"ó„%BžÕ®ç&/ÚòÞ*dT×qñrn˜q²YkÞ»ÆJÍíýR7
+ƒ÷Ÿè—¾¸VsAOÔb±*Zšøš£á*ÜдVÙ'[�º{�ì
Õ'i},©9B:u\þŒ™�
+endobj
+1735 0 obj <<
+/Type /Page
+/Contents 1736 0 R
+/Resources 1734 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 1589 0 R
+>> endobj
+1737 0 obj <<
+/D [1735 0 R /XYZ 85.0394 794.5015 null]
+>> endobj
+606 0 obj <<
+/D [1735 0 R /XYZ 85.0394 769.5949 null]
+>> endobj
+1738 0 obj <<
+/D [1735 0 R /XYZ 85.0394 573.0107 null]
+>> endobj
+610 0 obj <<
+/D [1735 0 R /XYZ 85.0394 573.0107 null]
+>> endobj
+1739 0 obj <<
+/D [1735 0 R /XYZ 85.0394 538.4209 null]
+>> endobj
+1740 0 obj <<
+/D [1735 0 R /XYZ 85.0394 504.6118 null]
+>> endobj
+1741 0 obj <<
+/D [1735 0 R /XYZ 85.0394 432.7569 null]
+>> endobj
+1742 0 obj <<
+/D [1735 0 R /XYZ 85.0394 303.3232 null]
+>> endobj
+1734 0 obj <<
+/Font << /F21 658 0 R /F23 682 0 R /F39 863 0 R /F53 962 0 R >>
+/ProcSet [ /PDF /Text ]
+>> endobj
+1745 0 obj <<
+/Length 3971      
+/Filter /FlateDecode
+>>
+stream
+xÚÍZÝsÛ6÷_á™>T™‰X€
+ç\9æ=5`½Z7õ¼êñ¼j×Ëâ©œ'Ç<uf!úéÌ|ÞS÷G÷ÔqîÑ3½·¨I. |vÑ0èpÑÁÉÙôOçÃE«ö¨èš»½®`�[ߘ
¨32¿ù¾¤ãüM´U
+Æ—K½]6Ø�çtBؽQŸv…ûÑ{TØŸ[t'ìýEÇ…Ý_´ªç€x:o&N*ðR‚–çÆ·¼ÐáIAÍ7+N‚þ´­¨1'êoij°€òêŸSÇ?ßýÌ�ëË7Ü+OÆœœÓ“"8ƒ#
+“mÃ
+[Á6ÄÚé=¨ôœ
>QܼjÃOð`ì™xSÈó×’øEˆL·eÉPÜš÷ýv—"õrO_v¨÷bÑNV±ê
l?TkðI.ØOrñ5¤/	ZÆÅsœêñ %Lší«°T¡Ê5�\
+)¶;)	~cSÔ-î둾Ò:ºC“b<ˆÈ'ÿÿÝbÎN�¾rv¨‡1ý�ÉA+#¯Óîþ;Ì«Œy•‘!p‰†�õ#Æó$@�	À‰S‰<8v¼dÚEm˜ù²£¸rÎòz D)û¨zÇÑ㢢0,#ÅTdWòkOýâòê»
~ ßGžÎód’H{�Þ¨Ýâi\<å•O.ð?ríd[/)‘3é‘Ð"]ùüNiÿ8r\¹=<®Ýº±O+5ÜËuS‘\E™w‚z¼çûç.Û”�:·ç*½^Þù0ƒÑM
~ð15MûˆÑg{ØõD]>
¼£9Ò"“(‘à(P.~þîCB$º~@bX¨ªg´ÖW|ò	�žiß=dϧ[0eVþõv˜kÊ^ÕWèz>V	RIžŠì„†ƒVíÊcã¶ì"z)ˆ`$^RTÜmþq52¬Dd=ã�	o1	ØY,*í‹èʱE蘈.L6[õ}Ù†¬%ä„ý£:ƒ5z³§!´ª�¢ÀU¹WÒ…ÈZ…+Øå3¾ëÄi¾æ(yýãÅñÒïcѹ?�d8ŘDùÞ4””>1;‘þEw°=ø¼é§qûU:Û‡†�Éw«ÃŽõÎݪÝ5Æ1w˜Q@ŽG’¤Cw+L
+œk,]IvfRqé`%ýK»q—Ž8$ÏNW`r
+0+–þ*J÷,ø‚¤/€D)�ïãúµI$‚éAðe_'œÿ^fĪ0ÊĪ&¼)ÓDªŽ©ª§¨XI±Y£Î7K2mÌàæ–a×+ƒë»j-4ÚI±{!p}ïo>!òe]¹»é-g]õP.Ãw"0�
+”Ø¢/Û†H½m„ËH Ž0]um¹¼#"‰*ß+—R‰ÊõÔ¸9.Ã;ÈGtzX†«¡à ±Jôtäj£	�;þ۱ˣ,DŽÅª˜�C¹—)‰�‚ˆ˜:¾—èuÝÐgØŒé9|ûîâåôÝ«l,§ÌÒw"¨#KñÐx¢@u”'jáÑñwÞFÔÐ
ñ`ìA<Å>s"Q2ïC=Lbò
+œÀ4d‹V ½K²Üì]½„Á…s¯I°Måz°“âcÉÝ�‹ÐbKöýãjmÁL­8¥×BªÃ>]ÁãsZVM!äm˜¿§ürK?ŠvÇ€oxóEÉSy¤·‡‡ª­|0ÆØ8È9÷]Wá
+ê­yŽvQ.—_3¤¼Ý5TÉ
+weþ>Kô@yð�Ðd·cá„`
+endobj
+1744 0 obj <<
+/Type /Page
+/Contents 1745 0 R
+/Resources 1743 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 1589 0 R
+>> endobj
+1746 0 obj <<
+/D [1744 0 R /XYZ 56.6929 794.5015 null]
+>> endobj
+1747 0 obj <<
+/D [1744 0 R /XYZ 56.6929 752.2728 null]
+>> endobj
+1748 0 obj <<
+/D [1744 0 R /XYZ 56.6929 504.0748 null]
+>> endobj
+1743 0 obj <<
+/Font << /F37 747 0 R /F21 658 0 R /F23 682 0 R /F39 863 0 R /F48 885 0 R /F53 962 0 R /F11 1299 0 R >>
+/ProcSet [ /PDF /Text ]
+>> endobj
+1751 0 obj <<
+/Length 2762      
+/Filter /FlateDecode
+>>
+stream
+xÚ­ZßoÛ8~Ï_áG»QI‘”Äö!m²EÝ6»I�=´yP,9jKYKNÎÿý
9Cê‡%åpw(PKÃ!gøñãÌ�
+_0ølj
+˜Ðrk(ÆÕbµ;c‹'hûxÆIçÂ)]tµÞߟ½ûUÄè(Œ÷ëÎXIÀ’„/î³oËËÛÛëÏW7�_„Š-ß犱åï—Ÿ¿^~BÙí¹——¯ïà5R,%nÔ"¶¼ºùxþpÿÛÙõ½w¦ë0gÂxò÷Ù·¶ÈÀïßÎX t¢¯ð®u¸Ø�I%%…p’íÙÝÙ~ÀN«í:€I ’0A c(Dšu¾É÷f®zÙlÒÆ<%Ë¢FÉ߇|_ä¾”yžÕØÞT(úQV¯®oŽM?ò#JÒ’ú¥Û§j_4›õ%+Ú[yÌ‹ò	už
¼BDË›[ßß|¾úÙ)꾃YUæ4ÈÑ, rÁy •
+íôž÷ç<YV/EF&Ø2}&áó¾H›Üô x(ÎX ­a03†™*uÑä:`:¤c&;2�„Š�A}:”€¥�¢È©5àÕ./›ý-Jì"t§Kj&©K™î
+ûþµ²Æiù‘³ù*Ï&z<o4x]<‘¹ïL±‘
|’(Ih;ü4¶qÇ.*À0&ï„Z;ñ¤ëa�Ö�.œXÄû,2Ž–ÈWÁà ‘‘ì¯'Âdͨå=q“IØ
+fžLA¤FÁ
+ê<æ@ˆÂìcóf¢–Q±”C³øðõê–¨Žk5Øчr›×nåJü½üë×?)&Sì¾ñ3Éb~¡¡n£zAC¹Ä
�«´¦(žâ�…öTe‰Y¥?0ÖzS4
+EÀB½A£ŽÖ�œ–§ÑËê„E!,wªyÃ^ëÔò€EØ&’¾id‘ô,bÄ"éY$=‹˜c‘ä=1Ç"Ùe‘J ã9°…SÚPiÕŽe“þŸŠ¶ªWÊ$‰/@»m˜’x2ÍI±  )C(.T?jt*<JäkÇ·Çtõã5m—%Éî9mŠÇb[4Çsι	S‚3ÜFã{Ê—•ùßÕ
P!Ôƒ‘­R±oé–Æ-¬™Õ¡hLÛ$ßd¬ƒP†jžo]­i¾y-�&d�jŸŸpN1(š¡n™5îµN­÷9§ú’÷ÍßË®ª…³m³?‡SV¹Jq?‘73ÃHbT3<CÌ·Å93vša;fÙNaFù8Ç<Ô14æ¡6«hÞQL΄îBDg$(êˆR*HÂd˜†ýDL™™ïMvœ	!R¨@*-ÞXÒŽÖÌ’:-»¤YµK‹òSOÛÝ8\W<JX<ï�×:u¡¿®àCÉ»çÂ�)èDäJx¨s„ÇÄc™2¤v*þBnR³Øý~°x[zÆy�Dˆ�C1ª¥;Dv'>ðVB
+™+î`�…†€TãøÅ}«Ÿó•¯¼my•Ž./„Ð�‚’§O†®¯ýÓtÈH»`–Tª6…­®">~ VB pGõwy³z·Ïëjû2u¬Ö°*¦Nh'šÐIÑLàyÜ’½þÊðÎÊPˆ\AŠÆð­}¬¸;z
„ë$€³€ó÷'cÆ?uÜ‚ZQ‹h¬Ò§$žw÷ÕàTNî)
±%†0¿§ºZÓ{Êkù0ÙÎb4LÎoÃä‰õñ0Ù3oS³	I65ƒS³‘`j6Otæн5
¸¢¦%Ë
­K<2:Žö¤>œª0ø%Fã8}ÚšæQÚBN‡g¥ˆDY:ã�®ü�¡°‘Œ·‡Mfø‡Uã‘Ξ½l܃@y:åHuåý£;ÿÛ,0Í2uZÄñ,ëhÍ°Ìiµ,ÛT¯L‹e3ñ†^ëÔƒÁ…—†
+-Ø»ãžή3®o¡ë#ëXÝÿbð楀¹
ØæM^B5<Éa®Â Iâ7Ît]­i{-ÏáÕ<‡g�·>±>ÎážyËa`
Uð€A‰Ãæ	#(<|¸Â_ÃáÕ&_ýÀb
+LCÖ ç©ÐÑš¡‚Ój©°�¼!œ5ÜÞžX¿!왾Â/†SÅ!}P|$ÔŸ.ïîÜ…l^v>Ãù"ÑëRmä?‰L€ÇAGo`ÛQš†Ö)µ7‹
¬ú	¸R	ìˆYÃ^éÄrZ	;8õLÿwÈÞßú?áêJe˜¿æ™óäÿç?iÿ$FÆ�
+endobj
+1750 0 obj <<
+/Type /Page
+/Contents 1751 0 R
+/Resources 1749 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 1754 0 R
+>> endobj
+1752 0 obj <<
+/D [1750 0 R /XYZ 85.0394 794.5015 null]
+>> endobj
+1753 0 obj <<
+/D [1750 0 R /XYZ 85.0394 695.9587 null]
+>> endobj
+1749 0 obj <<
+/Font << /F37 747 0 R /F23 682 0 R /F21 658 0 R /F39 863 0 R /F48 885 0 R /F53 962 0 R >>
+/ProcSet [ /PDF /Text ]
+>> endobj
+1757 0 obj <<
+/Length 2840      
+/Filter /FlateDecode
+>>
+stream
+xÚ¥Z[oܺ~÷¯ØGITR¤(©@$=ÈA{êž8h�ÄòŠ¶…h¥ÍJÃùõrHŠÔmO[ìƒ(qÄÎ|s£–îüè.±(’b—<N	MwûÃÙ=ÂÜ/WÔм±Do|ªw·Wú+ËvE\ˆDìn¼µò˜ä9ÝÝV_¢w1�¯a½ÿøËõ›D¤$‰ÞÞÜ|øíýÇÃ}J€‰þþö·Ïoÿ†Ïn® ûåçë»Û_¯>Ü:a|�)aJ’ïW_îÈ®¹½"1+òt÷7$¦E‘ìW<eqʳOš«OWÿtz³úÕ%ð4�Ó„‹ÝÆãø/«‰Æ¥@”¥E,XÂœšx¾¤&K¥ÔôêKÛÝ�äþ|êåtË4Écž0ï�%îŽjΆ#{ÊXÌIš„üo•¾»ÇÇF^¿a9�†'=H¢^Ã5�êöﻇ€€F¿¿ÇëW’’Ó5Í#½‰ºk‘¾’}��+  H{_8¨Û	»ïgyz¹¦”F
+oν¬â™ßçL€h°ö¶zTh©œú*	\üž«À·ÉÞQÍùO\°ˆ
·y(À¿´õÍÀzâ0B%áØ>Ø¿^€-%EL“,ÝÆmAÓ£y8fÙ¡ÃëWB’¶²‚H
+1‰`ÑñT·†kx¬€7Í¡â«…�²Áû}w8Èv°““źóp<ÛÉ
+èꇷ¶£RðÐÅp\p,!bFT‘¿]Ô¥µ4*©h×á
+28B¡Í{®R78†Óª\€V×`“¥l³ÏÕ®¶×¡ruZ6©xzm·
+ƒCYÉת
¥#]_ÿ”ŽÁzOã€N|l^&^Üswí&:î%T/µmpÿHÊôê¡që«b˜ŸB$ÝD�OµŽ Gåôý4å[äqÊ.°54s®“ª˜Aõœ±�íͨ‘/•Ñ’ŽÉN]wëú²­G=qÍœÐXé]Xý½^_̾rß8Wc�ûhF/Œ>Õ†),Õh
+•Ä”­×Möcp�ñ_®�
+¤YA·ù;ª¹
+ïýEpÌÔ#x®NÍ\Zö<½È×~«Íç/¯}ûŸþàk#¥ü~.›°<û)ñøjÚv-„¥ú}\Ý@µm[q\êܺ“0ý1ÛãF×ÿ‘ÅI&.TÑÆ ‘ôI:6
+endobj
+1756 0 obj <<
+/Type /Page
+/Contents 1757 0 R
+/Resources 1755 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 1754 0 R
+>> endobj
+1758 0 obj <<
+/D [1756 0 R /XYZ 56.6929 794.5015 null]
+>> endobj
+1755 0 obj <<
+/Font << /F37 747 0 R /F48 885 0 R /F23 682 0 R /F21 658 0 R /F53 962 0 R >>
+/ProcSet [ /PDF /Text ]
+>> endobj
+1761 0 obj <<
+/Length 3318      
+/Filter /FlateDecode
+>>
+stream
+xÚ­ZÝsÛ6÷_¡™¾ÐÓ
+!¾HâfòàÔNÎmš¸µÓ»›¶”HÛœJ¤*RNÜ¿þv�DŠ”|Ó^2	
p�]
+×R&“ʦŽÉSá1}]M×¾¾<Ü.—‚eIÌgý5GœÕ˜µ�=Ö\¦,Sü€÷mÙ�Ï¥L£î±t�z·^”[l'QsïÆP>O–Ó„Çü‰ft�{æ›MyΣ|ëºU�zõV÷¥±aI¦ÈŽìë|]:ª�¬"e"I8Áúã…¸`±’Dq9±†aR
+E÷�ªëËœDÚò©Ûª€}ó,*ÚÏ¢mV»®d¸úl.²„	ÁñÈ93Z»ò�=7
gTÞç»Uç:OùjGãUëžtr–ò×8µeÝ][Á©ÕžŒæÕtèÐl»¼+×eMóýÁJÓ?²L1
Ø¢
¿*»å«m	xb°·û©Ò,QÜá7°v¦"{NÀƒ+€N¢ºqg S ‚­΀DF[Qa7$-ŽTôfÃp¼i„iá5è¹R*ú
+ìÓÞ6Šf�Wuë:«ªíü”>åøÖxš±Œ§¦Èqù8qW2cp
^k@Š‰¥8˜
íWrò]É«VQ¹£ZÒI9�Ç‹kÁx"“¿
+.6²äd.“T‚š&Ùi›Ú§:nS•µ©‹Ý}[ýY¾~3²ªJÁ‘rOòTcæC«ªKM¢‡Ü­U^›±ñéòÆ5
+:�Ó¸$h-ó]Kú˜»Þºký±+·Ï´M\­3«Çt�gLHi^еÕ	]óTV×Ê¢n_5R4‘0€¡>Í8P�9„/hßd6d}�¨îíid^Ù²pVYJÔVMMï÷˜Y�c¡¯ü}UÍW—õÐ�x¸˜Ðš
+H=
+D�Š2ðA'�ا:Ä@e÷õKÝü¶† ¬ZUu9Âc’±lëiþ�j,À�`ïÓ81C	n¶Æ=JdtNËÆ>‹Ö
®ªßKײç‰�Û�ØH§'`ø€ÏÜ=àhMK3íNçv«¶ÑÉ:'î.”ÂÖãn�×s‡ºdNb3´oŽo^ä‹.s†×¿¡SH휎‡;hXdlˆAìohë0TæËG78Ü“CuDªÜuѱ9Æ"½@ ª¤	ËÞçK¸M€ÉÖ¦ËÝj§>
+±™”¢ÜmB,Ÿ<
©Ë…,°¯T�âEµ>÷±B°ÚÈwÚÔ¡9+‡ ªQÓÈT·ÝnÑ'ǨØ/¾(!K®
+,˜|A€@5–à@[lb¯‡"\t�¸n0Nœ¥	˜‘ªÝ¬òg´‡

H$:4:ŽÆž4ŒR¸Üºž¿¬„÷|2Rå+4~eañC_ü`§jÉ
+BÈ.3=Ä„w¥T6ÌRB'0 Ÿ\·�Ÿ¶Ç¯P—diú•ö¨N\©§
+W
+®»-—£ëÔ1d"";Í<P�¹¯š4U|Èþ§‚�ïˆCÖÿöê[×9/îÒjûlm1ÀŽ<ûŠ•°c!p¸àÇïiFES�u|ùþç®�ž‘›d?ûãÍÝ”,îΕf™ÈøÐó�²ø¼(ªB— Û˜p4õØ£ô1ò
‚41ƒœü$ö4ÇA@4
mõ°|ÌÛ‰G°V8Áדò^?ä�©0²Ïø[Ëp. ¦ð%æ¬uÞí‚:
+,˜`-u6b†ª­{�îÖ6lØ*°ø¶ÞT+«\!tÁÖür¢¬2Á”‘ª·Ç—ŠÀ\Z–M—€ça½“¢à&€RôäöúÝ·ÿ¼¸½:~ûvƒ[zéþ{T'à©,ºíKLóßËç×_ÁŸ²„%:“§ETc†h0œ%Ò$C!lî…•ÌÒª»ÍTð�C«ÒµÑ¨HÕAw¶çY´sÕ1ìƒü4í/>4s×z‹‡‰‚§TL›P:ûº¯òk{!¨	Ũ¹€e¯l�Š
+.a*£©ƒ#÷5Φo®¯âÀNÙ‰ÃîÙ){;­I;%R4¡ÊÌ@jÜœüÛ–*¬8ï/9VW
¦%å2ÝsþŸ¬•HÀå'æ… ¥OuÜZªà±ºfcg£¨%�8#V§¹ª1û·ÅYªy:äÿ/æ\ØJ~N"7{'/�÷N̵7åÃ?×ÉÝtØÐœJ�Ü–‹ª"ïlÙ®ÇÂ	&�ºb&ƲX§Có×0Ʊ®ƒ7­1}Súïc̯8ï/9�1Tk%ôžócÖv…-Þc.š‚½�6äaàEÜíüðé=¦Gw×7ï¯ÜVütõÓõÕí„mˆ
+‡Â™àø2'éå^úUe¿�¨Ã?Ž[§jWü\¥ýtíx¸â	‹…9Hì@V™?´ß�K¶¢¶>�+F%U"˜öÖx)Rú¯
+ÐZBÀ�+ËĽÆ_cR
˜÷Ο‰�r‚‰8óíRÛ‡}C6ÎŽÐ×Î6ç$OUÕSUìlÚ"EØŽ}åE.Ib‡9*âHûjòŵ‹²]n«}™ó<WŸ¼óEóTâ¯4À¨ÑM‹Ø}A·¹!öì½sü’óÜ”=a£í@ŒÜGTHî_Û»ÁÆþþö?S€aûË
·bã¦/¨�±NI“wšga&üõæ«©=ýÂúó¦<ÀÈr•·‡¸±»›PøÒCQHûØìVÅ0žÈ=Ôûµüý”ƒüò�w«fá.>u*!è‡øHH¼\­&TRp’—Œ~�Ͻdô[	;h£IZ4˜–Z:âû¶q3ü2^™m*hË26ƒ
+’z¢ŠK"K¬@`á×ÆÛÒVš©šX”A»´ud0ºÛ¬hÜY!aAƒ€àÊ]'µñ¶mS÷N	_ô°=ÉX¶;Ÿ,LÓY*E>@{ ú>@Sž
+endobj
+1760 0 obj <<
+/Type /Page
+/Contents 1761 0 R
+/Resources 1759 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 1754 0 R
+>> endobj
+1762 0 obj <<
+/D [1760 0 R /XYZ 85.0394 794.5015 null]
+>> endobj
+1763 0 obj <<
+/D [1760 0 R /XYZ 85.0394 204.5196 null]
+>> endobj
+1759 0 obj <<
+/Font << /F37 747 0 R /F48 885 0 R /F23 682 0 R /F53 962 0 R /F39 863 0 R /F21 658 0 R >>
+/ProcSet [ /PDF /Text ]
+>> endobj
+1766 0 obj <<
+/Length 2180      
+/Filter /FlateDecode
+>>
+stream
+xÚ¥ÛrÛÊíÝ_¡‡Î”š­÷Æ[ßœØÉÑ™Û�”9í$y IÊâ„E¤ì£vúï»4%Ñ£t:| ‹Åb
,.+&>1ñÄ2ž„±f>þ$­.øäæ>\K3sD³!ÕÛåÅå{Nb2˜,W^ãQ$&Ëì‹÷–I6Üûõn±œÎ¤Hî]ÝßßÜ^Ïÿ�c4@Á¹÷ûÕíç«�„»ŸÆÒ»úp³˜~[þvq³ì¥J,¸BQ~\|ùÆ'þÛg*ŽüÉ38q,'Õ…öóµRS^,.þÞ3Ìš¥£œIÈ1Äc*Ð!Â�T��ÓY
+C¦#Xs ºfÓ
˜Gñ¨É?Ø	$âÎ…~u])ÀE/31K6›²È3T¹”^Û¶['݈3G’ùQœWœâ“�ŽÆÞâ™PÔEW˜“ÃÀYñý«$³”d+
+	WÎèTBøõC:(ñ†Ü‚·	ÿ'·	‘ãQÜJk.ÿçÛä4Ö˱™¤f2ÂÈ£|‹XÚùõ-	°ø|÷iêûÞr<¸KŸÉ8hÕjÄ(1ÿóñ\E±39y›¼‡©€À[ÛÁ®(QÇÚ£ukB’˜€úÊ}fË·u‚N˜”Å¿L
+ÔeBž�_Zig±í4òvuûJ¸
r…Û÷ó�Ô[éû(¾^æ]z¹ÍÛ¦|bpÅW½FL„°?Òüåß¿Þý~óŸK¢nÓ1¸Û›,nnH
Wwçcüºi;Œ¶ãèZ‰ñ"Cd4@fuÛæéì{¾ÌëÁ¤ÙA[5@-¦{ý}zÿZ)¬4ˆXè÷tã
+–Duê÷íç‹óGßs±�6Ì>€í	Ó5

•é—r•
€T
�@3¥g
+Tú˜¨Æ{X
+�7tÀâõ¶§z9(6�_fÉ»¬¬·íòùé›C¥c¥§Â&A»Ôš–IÛŽö)ÌICÔ3¼aZŠß¹b�5Ý«üÂø˜á§ówÕC>Ú@LJ-Ž9vg9vûÍX¶‘
+¬Íõ1¿?Îò{NŠîU~ªçG-ZzŽË£/³jd—C�Veò8¶‹f:ŒN´ {(°U2G¥Á·Ñ *Lâ0h\ß,Þ}šß/çw·#ya$,Ž·�JGÃÒ/–4øk‹jƒéHÄQ'Í„©%Øä[€+S¬áØ\gì;$MC®ìëø×°&)KË�CÂzÿ¶<¤�M9z8?¿·rfÅ@ˆä­-tí�,IÕ1”OOEj1|~HL
¦¼?¨Klmk@
+­�;,Z[ymíŸç�ΰ½Çâ)¯ßŒ˜BB”àÚw>óš)$„Jß]nÓå¹]lí¸6e†
wU•˜Pû6¶„,½{<"…„ø¾xÜ1Û'¥>‹¼QF]'IÂ?Ší”Õɽêñ
+endobj
+1765 0 obj <<
+/Type /Page
+/Contents 1766 0 R
+/Resources 1764 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 1754 0 R
+>> endobj
+1767 0 obj <<
+/D [1765 0 R /XYZ 56.6929 794.5015 null]
+>> endobj
+1768 0 obj <<
+/D [1765 0 R /XYZ 56.6929 626.4701 null]
+>> endobj
+1769 0 obj <<
+/D [1765 0 R /XYZ 56.6929 517.4334 null]
+>> endobj
+1770 0 obj <<
+/D [1765 0 R /XYZ 56.6929 438.0429 null]
+>> endobj
+1771 0 obj <<
+/D [1765 0 R /XYZ 56.6929 376.8269 null]
+>> endobj
+614 0 obj <<
+/D [1765 0 R /XYZ 56.6929 339.1376 null]
+>> endobj
+1772 0 obj <<
+/D [1765 0 R /XYZ 56.6929 306.6767 null]
+>> endobj
+1773 0 obj <<
+/D [1765 0 R /XYZ 56.6929 271.6646 null]
+>> endobj
+1774 0 obj <<
+/D [1765 0 R /XYZ 56.6929 207.5268 null]
+>> endobj
+1775 0 obj <<
+/D [1765 0 R /XYZ 56.6929 137.3205 null]
+>> endobj
+1764 0 obj <<
+/Font << /F37 747 0 R /F39 863 0 R /F23 682 0 R /F21 658 0 R /F53 962 0 R /F47 879 0 R >>
+/ProcSet [ /PDF /Text ]
+>> endobj
+1778 0 obj <<
+/Length 4061      
+/Filter /FlateDecode
+>>
+stream
+xÚÍ[[wã¶~÷¯ð[åsV\\ì9}pö’ºMœíÚIÛ“ô�’h‹'©);ίïf
+ìVµWS­²IQãÓNšMW5u±bêöJºÉãn]ÖQž—Õ|I]çeÕ-a&OƒëbÍ­†_Ý|à1?jÙò÷ÍÃÉoyüºèx9r°X½q9¯gÙ´ÝÈ¢§©†�³HUÊ$7F‘�–Ínµ �ø´+·/Ô¬ê¶+¦#{øôìa#0å_n÷i-ýXUðù"EÜè|�¥³Äê<ìÁë²›¿Þ–m³zJæMý0Â?,2K¥æìq9ÕZ%Ú	s9Uа–tÿø<žR®g6HiZŒÌ!Ó$M�ã.¿#ŠÕ
+’—ê5ƒWÅ+-?íª§båµÃ˨	â躪~ì7ÂPÊ*â’¦Og9Úg ¨Y¾Eû+Nt¬N%RKõyµP2qƆ	÷ëâWÞêâH5¢6¼l¸Ïõí¿¯¤”qS`Ì,ÍÝpSþ¹,ÑÀ¤>!�4ƒ�T�‘é›1a€ž[™‡ô†Ï][.^�ˆ$-”–gD¡’Ô¥¡ÓsµZÑ EוëMÇÌ7øT“EÕnVÅK¿"߸ûášdßóÆ?Ì݃wÐø½©YfÈ€L@Å-sà�À›Ö½×ƒŸ¡Y3«�g–1X½€1aíÁêi3‚}j•NŠ]·l¶UWtÕSI¤à~LoÕH&þ¡á‘oáJ0hhí­ÎÓppúšüZ?^:�ܧ™,Ê_„Pu`höfá�nï¨ß¡Pq�bèΈ3¯¸Ô›~<4»`.ÁaEoFkàÁ¾È�ä6hÉt>®§*ÍÕTKïU·Wn²›w¸tMîß�Á!¥ Â[¿hh å]ÉÉýò…ç|U´í˜
+I‘XÜnš|¯ÛP‡òĹèq�‚åVÌÕ¼`†g%=Ñ®†¯šæ×݆h-ÛªY0ƒ[Ò;eMâ¤PÃíy³,š¶.y‹ˆ;ßäxØì|c^îSã†'¨Û‚
_/ʇb·:,øæ›[z¢#¿©»r3£7?ØlÏÙOÞƒ•ÛYÓúÑ
ìºÍ®£6�h'�e]nm5õØ×H€ÆXyÖïæÊEgã�#yÂ9ê$ƒp”n1)ŒÌ‚ÒmǦÔ&;n`ynz	 &$´Õ¼ÀósÃ"ópÏ=´{a’ƒ„/2ûú
Cb”IídY 3R©ô²
Ú†|ÝSµð
+Xí©7
+rrý‘ê_!y%‘G³œÞŽ#.mÍäJ5æajÒ
+€„àí$uó0"ü©é[yà1No‚Ã=•{ud´Šº|,z	¦ô;-¥yu`z‘ù½ÊÚ�y °pm°2Øó3°™Û¦ž²åî »yâøõiw…é.ˆ�-YpקŠ�ævϳÄZ+wÛÚÝ�s“»P'¥	*f§á`œ+pOLï‚øø–¿
+�œñj*Gµþ¾ÃEÞë½ÿØ×…yʶk¿®¾¯mLЦéxE"3ò¨¶g	gúö¨·‰ÔÙùS(‘Åé½µX¬H¢¬•
Ù4�n><¥D
+±	ˆ^&›fë3«N-ÑŸ‡ÅrØ4û?^c°�ÂkÙˆbÇÒhXù×lµI]ðìÓn\NeG°ŽÓGçølD9òŸH!s 6E^ç"«H{Ù”cØ_Ú,6VAý
ëˆð
+_Š‡·=öF`“³TaÆç
˜-µ¼Z¬
¬¹ÿ’»·]±å3ü*‚BÅvÌdñÓ‚¿›…Ïzƒæx‘,
+Œ¯¬ñ¸«¨ã%›bŽïW«æ9T²f/‡•¬ž=‚“Uøp?ÑF¬P&�\Åžr:�ø‹T:5™u#çÄ{5(èä‹'Üjèù\x3×|S=¸&âü$ñhª&{BSwäuVt§1Õ%ÊîqÉÓŒ[¾Q‰Íb3ýç‰ן Œâõ¨Üƃ˜çSÃdÿá5
üûx|561Y´‚/`-:%Xî©£¼LBü‹ùën»Ñi­ƒÓ:¬¾9�eo‘Ø{´€¯Tt7-X]í-Θ|¼¬d4 ­xÆõE£ÒM=Y‘còê@—24à¤}§	G@ê×åkÐOÞÑi‡iK~M×7üá
²ÏÜó-­O:M¢Sí>§$ebðêÀ²{ä”q”·§ok¹Df™=_~T+q|‚ÁË´šªSS¤·Á2]ÀkIÕ°£#^øÝ›*_HeÎF�Øè¡�½Ã¡}£ 7 6`%üMàÒ2ZËüÆxŸŸ‹ ØÁu™�+¶ZÈ
+H?|
+endobj
+1777 0 obj <<
+/Type /Page
+/Contents 1778 0 R
+/Resources 1776 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 1754 0 R
+>> endobj
+1779 0 obj <<
+/D [1777 0 R /XYZ 85.0394 794.5015 null]
+>> endobj
+1776 0 obj <<
+/Font << /F37 747 0 R /F53 962 0 R /F23 682 0 R /F21 658 0 R /F39 863 0 R /F47 879 0 R >>
+/ProcSet [ /PDF /Text ]
+>> endobj
+1782 0 obj <<
+/Length 2136      
+/Filter /FlateDecode
+>>
+stream
+xÚ¥X_sÛ8ϧðÛ)3Ë?¢$î›Û¸­÷Ú4Wygî&ÛE¦MeÉkÉîæ>ý�¥H“tæÆ) àÀlFáÇf2&±âj–¨ˆHÊä¬Ø]ÐÙÞ}¼`Ž'ì™Â1×»ÕÅÛ"™)¢bÏV›‘¬”Ð4e³Õú6xG¹	4¸ºÎ²ÅûðŸ‹ÿ|\\_†L¥Ró››ÅõÕòß—!—˜�•ÒàËüú�ùgÜ»¹T<˜\d—ßW¿_,VƒZcÕF§¿.n¿ÓÙ,øý‚
7Ì~‚¦Ÿí.")ˆŒ„èwª‹ìâ_ƒÀÑ[{Ôë
+F	1÷ø‚³cDIÉ'Î�ŠÄ‚ëŒåÕ5•ýqsóõÛ¥”Áʘ‡ÅÈ‘tò˜¤Œ)<µq<lÄ“’4¢)°Žû¦í<r8#RÖ3å-\Î’àNëÚPipw,«7–Ý=n¢’°õ'•´¬;}¨ó®lê¼*ÿ«×øjÝìòÒ	©ó�V†oÚã~ߺ7°âQP:éEî˜ó¢Ð{·™×½´²ÝWùƒ×Ô¡±e
+ø‰€°Ü
+V̳÷Ë%p&ìQ	 �-ñø‰QJT$^ó'4NÇ”ï÷‡KP¥ÙʼÓÕÞQ4õIºÖ­îóC^€wp©ë¢Y—õWÍƯ"RwzÓØܺյ=j­f\Ê ®œÙ˜F9pÆ*ÀSuÛáFטgj’7Z}8Y�€nÜÓùaÁ·&òöÖBXnÐì�“}¯Q¸“™D
䧈‘öÅCsüÇ™«ò‡«Ïã¡F6ðˆÝL¤*gFek>�~mã§PppQcœ'8w*çmSCŒ	
ÖAôQ^ë9�|û�!rFaÀ¡	—î›»Ïà„Óˆp%Õ,V1(©_
NTš¦~8	‰áX$âæX7NÂÓ(y¼Ù¨xµÌæï>/<ÁIB£ˆ;St}*ñ³Õ;]wè„S‘{Wiƒ§�†«{ç<ësëOçs»([|qb­Ýîw�CáÃ(	PO¿Pâš‘dž­î�øyXãA/
+€ž	ÄÄ�®ÙûoË›Õò뵧0�÷9ÔžAj¬
+¸âÁ±uïÜð
+3ñº±¹—¨€ýfæ.3;åî`�ˆbÔJio¾±½x‚£<À€µ©ˆÈj§4õÛWËÜ(+±ŸÑÍ=Ù|$ ME³§ƒê×zm‡ÑàC\²÷ž›Î
�JBG¼äƒ¿¡ø©(�¿©Ù8v0…we‘WÕÃÙx‚áDø£G-*ò-y3 dP¨^ÁŒ×˜ÑsMšÅ	fÀ
+'8
åÑ£àÉKCàSÿ
åÉݱêJ
+endobj
+1781 0 obj <<
+/Type /Page
+/Contents 1782 0 R
+/Resources 1780 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 1754 0 R
+>> endobj
+1783 0 obj <<
+/D [1781 0 R /XYZ 56.6929 794.5015 null]
+>> endobj
+1784 0 obj <<
+/D [1781 0 R /XYZ 56.6929 751.8114 null]
+>> endobj
+1785 0 obj <<
+/D [1781 0 R /XYZ 56.6929 637.809 null]
+>> endobj
+1786 0 obj <<
+/D [1781 0 R /XYZ 56.6929 571.6272 null]
+>> endobj
+618 0 obj <<
+/D [1781 0 R /XYZ 56.6929 530.4875 null]
+>> endobj
+1787 0 obj <<
+/D [1781 0 R /XYZ 56.6929 492.9536 null]
+>> endobj
+1788 0 obj <<
+/D [1781 0 R /XYZ 56.6929 459.984 null]
+>> endobj
+1789 0 obj <<
+/D [1781 0 R /XYZ 56.6929 390.8804 null]
+>> endobj
+1790 0 obj <<
+/D [1781 0 R /XYZ 56.6929 303.7532 null]
+>> endobj
+1791 0 obj <<
+/D [1781 0 R /XYZ 56.6929 225.6163 null]
+>> endobj
+1780 0 obj <<
+/Font << /F37 747 0 R /F21 658 0 R /F23 682 0 R /F39 863 0 R /F53 962 0 R /F55 970 0 R >>
+/ProcSet [ /PDF /Text ]
+>> endobj
+1794 0 obj <<
+/Length 2915      
+/Filter /FlateDecode
+>>
+stream
+xÚ¥Z[sÛ6~÷¯Ð£<�\y™}rçÒ´v6Rf·Ûö�–(›ŠTEÊÞô×ï98
+Y\!O^ýöŸ¬`?]q¦`µÉ<p&ÒTN6WÚ(f´R~¤¼š_ý³[0˜µ¯‰B›„©£ÉÀšGé°À8ã0‹µ`<¸˜Có(جÂ�¾~gL€‚%©
Î,¤Ê6yû}›KDhÍbc‚‡˜ëPÜ©�¦NY¬¢¸ÏÞ|›/‹ß9—yÇ%Óö)§NýRå;ì¦SË
®�Pßòï×Bˆ)œ°ŠÌtAãéô9+÷‡w¬Tp#EÌDlÄ€Žø6œéTiÜì›––Í`bGýGõ?÷w·4ò;7|]»é—�Ì�™6 '3�jŒ´+’RÔö¯ºÂ•Ra÷e‡p!PØ×
+Rúb‚>Ý;IWffB¥ðR2•èähSGœÈˆ	nú
+5⛿R-Ú£HÓ”lì[·P’%ÉX
+Š±—šê_*û{#oÜ÷{ ñ4yȨ°ƒÑºr¯ÛTæ,ç~–ÛPb&#Åb.Gü4CQ
•¿J±ÔV!¡7vÅ鱸·û‡Ò«òÑGL—ÜŸ$‹ c¡ƒÁÆž15:eKhÌt7Õcì¸÷{üŒ‹2Y4 ¸¼Kþï0ÌNÇ�&'r8s�Z�)’qLá&WǬ¨”Lb8åý6A&Æendstream
+endobj
+1793 0 obj <<
+/Type /Page
+/Contents 1794 0 R
+/Resources 1792 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 1797 0 R
+>> endobj
+1795 0 obj <<
+/D [1793 0 R /XYZ 85.0394 794.5015 null]
+>> endobj
+1796 0 obj <<
+/D [1793 0 R /XYZ 85.0394 181.7045 null]
+>> endobj
+1792 0 obj <<
+/Font << /F37 747 0 R /F21 658 0 R /F55 970 0 R /F23 682 0 R /F39 863 0 R /F14 685 0 R >>
+/ProcSet [ /PDF /Text ]
+>> endobj
+1800 0 obj <<
+/Length 1931      
+/Filter /FlateDecode
+>>
+stream
+xÚ¥XKsã6¾ëWè°¹2D
+©=h„Ô‡—HPXÒh,6J€“G¬D¢(Œb�¯yÐê`˜zòB
C,-ÓWŒÃ\]‹Ñ²*›$+k3Kô_¤Ñ6ó_&¿™ÁîŠÄ#µ¬ÚÿÔКMÒX!IiOÊ
+i¥ì÷eÕÀ"Ð7¤Ø&yV¯µ*Õ.ÉÍÄn“šÙV튬®³ªôâø¾#y€dˆðõ·}4B‚I‡vR¦~‹ÌÅwY„s)zÑ(D|”˜鉰G5ž
+k«wÔ‡¢PÍ.[š©*—»Ã¶�c›Ï:CZ™õ~¹±Ò-å§ÛñµuOÇ' VíÛþÎ@ªžUiFͦگ7nl�±Ý?åZ
=Ö ¢=x;Ñpšew²VìŸ{àÉÁë‘Ň;VÚp#I9kÕ™ü:¾½ÿ4ñ 	Œ`&¥a\èx
+·9¤Ä�wEÚ=��˜¿HÄÁSÖè	DîùØP�š@iAÖsF ¤U
—Äl×èØÞD_Afí¨þ—Û\¡eUx4Eœ:^�.en»æyõ-+×fKQ8aí[µÏSC²ìàä{•þÛ£S
+�âh=×OËîg
+ÈCAbþ[Z“ù€,Áršœ¦GoѶZc¿œ&î4ÆOÊÆ:‡‹…;ƒ
Œ«Õ‰¯�e
+ß‘O¶ýåHIôÆô‡P�/ë;mÓw�
+3wÜw�‹¾|1Ä0
­9ûðzŒCº¿´Q«i/}»£2ºPð:¶@PÄDº uæŒgb lË7ƒ !q—„»
L� ò8ã'1ùdóóñŽPxXte€ïÊSïêÏ'6MŽ?Íï.
+…!O%Î.J¬«$€N5KòóÚ¨A‰_Ý�ê¢thÖÇjw^„9E˜ž6kΕÏB¡ǯ<mÛ�vž½ú7`ULU¤êùÌýÆüàõeÀ›dל»áJ ¨+:©M7z>«´“ŸC7•”ûëÑV_±„l&edkÛ`a¸áN#„½™Z<‰¡é%“›Éüúaz¿˜ÞÍ<õíÛu•''‚MiÈܽԌ:;Ö–öÐþëÏT¹œŒ¦�!¹öÖ2ÎL–„Ó,
+!@¿‹zª"Ü]¢üüúòÐù‹ÆqèYL£h•ÒÇ$˜½RÝ=Ô¾Öýÿ�~·endstream
+endobj
+1799 0 obj <<
+/Type /Page
+/Contents 1800 0 R
+/Resources 1798 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 1797 0 R
+>> endobj
+1801 0 obj <<
+/D [1799 0 R /XYZ 56.6929 794.5015 null]
+>> endobj
+1802 0 obj <<
+/D [1799 0 R /XYZ 56.6929 635.5323 null]
+>> endobj
+1803 0 obj <<
+/D [1799 0 R /XYZ 56.6929 476.3563 null]
+>> endobj
+1804 0 obj <<
+/D [1799 0 R /XYZ 56.6929 407.9215 null]
+>> endobj
+622 0 obj <<
+/D [1799 0 R /XYZ 56.6929 365.2162 null]
+>> endobj
+1805 0 obj <<
+/D [1799 0 R /XYZ 56.6929 326.9947 null]
+>> endobj
+1806 0 obj <<
+/D [1799 0 R /XYZ 56.6929 293.3376 null]
+>> endobj
+1807 0 obj <<
+/D [1799 0 R /XYZ 56.6929 221.9809 null]
+>> endobj
+1808 0 obj <<
+/D [1799 0 R /XYZ 56.6929 108.6903 null]
+>> endobj
+1798 0 obj <<
+/Font << /F37 747 0 R /F23 682 0 R /F39 863 0 R /F21 658 0 R /F48 885 0 R /F47 879 0 R /F53 962 0 R >>
+/ProcSet [ /PDF /Text ]
+>> endobj
+1811 0 obj <<
+/Length 3191      
+/Filter /FlateDecode
+>>
+stream
+xÚ¥Z[wÛ6~÷¯ð#}Z±¸’D÷)mÜ4mâdk·»Ý¦´DÛl$Ò©8Þ_¿3˜
o¢¤œ³öƒÀÁ
+iÏ—›3q~}¯Î$ó,ÓbÈõÝÍÙ7?èôÜÅ.QÉùÍÝ`®,Y&ÏoVD/Þ¿¿¼zùúßeEô]|±°BDo_\ýúâ
ÑÞ_8½xuy}±�Y*S`2È–ˆèåÕõõå÷‹ëׯ®þóîêòâÏ›ŸÎ.o:Á†ÂK¡Qª¿ÏþøSœ¯`?�‰X»Ìž?Áƒˆ¥sê|sf¬Ž­Ñ:PÖg×gÿì&ôú¡sÊ°:‹m¦Òm(y.eì¬U#uX'Zi¯Žwïo^¿»ºÞÛ‰ˆ…�¥JÄN¥jÞÌ´r……g̸pÝE>]ÒéXëL_20Í,©K‚Áµtv¼äoRʨؖwÏdè|½¦Æ}QÛ¼-VôØ”÷UÞî¶2‹Š&>¤›$sq& qT7C®Ãºé¸¼n–¸ä7?X;à”"Vl+<Ër�7ÍT0©l,m–—¬ãšm¨C©Á%��cÙ®‹eùAU4¤¬ö¡ Ä5H6߬ï&Lÿ­«â°BmÃb§:à:¢ÐÀåúqN¡2ΜլÐ�Åóž:¥‰³$µÇåê¸f©S‚
g(ÙÍ…9ZÞ^,´’QÓixEÍ7ò†Gtåýµ¬î'Ü@¬·9¯ž'ý°„ÎïD6¥£›‡’g¯Û²®¨½Éy‰Ûb_8Pdì„ÊP
Œ3°©ÍnÝ–�k6y[nŽ‘´q"�;aó
×›.oóõŒÍ]ÞŸ²ÉWõ&/«=«ƒÛ-’ã’u\3¢�ƒdÓ�e{Åx
+JšS%6zùÏ�߈Ö-QA@bZ­J²RÛš¨WÐðVÅžÂ
+ˆÄŸ/‡–ä±ÕŠ—¸îfG»k‹v/¨�µáûÑ�–?>Õ*˜pC$Ö�mí%Fx•oŠÁO~¾¬ýïê°OØTÁ©'Òã>1ä:ì—÷‰ÕIX•ÛbÙÖÛ}4°"Ná$>*\`šnäÖÆ©4z,Ý›ºþHŠºyAµŒ2€Ç©ëñ
+}Äs�æ†l@ÛD2†ê:@59ûdV-ã<tnû“™m«,äSü‡¡dß9íu¦526J&'L;à:bÚÀåM{?“Od.9±d`šYr’Odi:YrÅxü]Ï:yoP:Êõª?
+C·g®7ôĦõm¶«Ñåç²i=¤Ÿ\ñ©ÉÍí(ú6õ§bu8ò ËÐBÙæp1OàòæiN¦4M›oÛžû¡Sš$=.^Ç5#ß(ø؇n¶Ëk|b(¬BcEæš1ûÊ
w>=Õˆ_�I ÿòT
+ÔÜ7o�°á¡Ÿòu	†Y(gù0FŽe^Va
+îÝKÈèEEÌá†ìÒóRË˧ðxZ•Ĥ=åö™×§Ÿj·¹
¢•<ÿïð÷öíË…ß‘Ÿ'/üñíÛëkô÷4ªê6ÇCïxVÉH	ø³ ©1P³!¨²
+<²‰èw<
bÍ9©†-&&ù'µ.NS›1+{¤Ñ
+S|=R�‰
+’Uc3�®è±G 
PÅ…sÈA×�Æ¿)ס¾œ€¬´/ì®'“�Ã>L0ƒ�¾â4j¸;m$ï;ªúé««˜ÚnØ;n*n&Φ^#c8Šì
+Yw9ÔαK[é§>qA2ä:Œ]—Ç®»Ùb9ÉtÐT½kwíâ®\ï£$T&Môqñ:®ùÆé™��MÓ±€¾LÕ2‰ªÿ!£
4˜†…&þ’M IX"úºç…Xh¡Î¥{`mÃÄx‰â�Dº¥‚\+ífÛƒ·/®XÓ3Ês€–¤±4P9�cF)¥b¨¤åØú,Á¡’Nñ{wYùÍöå–à‡}H¸X›ìÄ…Ë�ëˆ.ïC{ø¸1'–L3KŽ*0Î`'K¾ß–Uˇ~ÎÁC½ee4»Í&ß>¸Œ k®0¸â¢,÷A~¿ÛÝÄ-ÎHÊ8ÀÕ]%U
Àì-ˆ¾3cÃÔĉs#?˜³ŽJ3˜×�ÈN†\‡­Óqy딧®Ã@•Åª�ýä|4¶£²u\3Â�““Ú©K÷¯.ÓÈéç‘N�Oe½kÖÏ‹œØåì[%'�yÓ„Þœi>(ðlj>5ñW›Ø¸-†	­ÄÙ
+ÿLLƒí�2fFo“Í.t»5 óQ ‡ÖqRÝL3ýçå:”a	ÿ”3gÎS€kƒäwtg0©\„g5Méæ‹jaÒ]V£:k_Y¨®²ÈižP×e¬Û¹¦Ï
Qîàû®õar!h„Íf²Û,/ƒ½·LæÑ4b¸7“�ºçV¿OeS»iÊUA#W¼rM¿·¼ª—’®Và©©ëÊOæ<4Ìå.íñ{–Çu¾ä*Ä…PK´ëÏ2	‰Rw¤H§‚�Þ›Û?5ÄÀn¯£¿w�q ñ
q
{ÛnÒ’Ü�·[-™~[´OEÙ€{ôª‹H*T]vˆÍþ2ª�k%
âÞÑrÅ—ûñc- …Ô_�«	<B†?{'Š¸/.jCÈæa¿(ð´¬� ©O[Œür Oc­º´)ÔK
¯5z³îðó–Ëi	…›R“rºV§tK„Í„ëa aªŠLUÑi�sâ	ñ”
˜@‡?�
+…<põ	:*¯-ýjØäJæ_+á°¢¿šr
+endobj
+1810 0 obj <<
+/Type /Page
+/Contents 1811 0 R
+/Resources 1809 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 1797 0 R
+>> endobj
+1812 0 obj <<
+/D [1810 0 R /XYZ 85.0394 794.5015 null]
+>> endobj
+1813 0 obj <<
+/D [1810 0 R /XYZ 85.0394 751.8312 null]
+>> endobj
+1809 0 obj <<
+/Font << /F37 747 0 R /F21 658 0 R /F23 682 0 R /F55 970 0 R /F39 863 0 R >>
+/ProcSet [ /PDF /Text ]
+>> endobj
+1816 0 obj <<
+/Length 2975      
+/Filter /FlateDecode
+>>
+stream
+xÚ¥ZÝsÛ6÷_¡·ÊÓÁI
+3wÅ·<Lö�º¸/Óæx¸f鎵X™˜›„`6†RšÝäD‹üxå›ÇšZõž iV”÷ÔU”kêÛåe“n=®·©ë¢ö}^懔x‚½Õ#ž<ìÇ}3L&I컬Ùå¶Ø䈧_�22Ët[WÔÛøo]\þµ
©}t (šš~?¦Û"K›êPûuÊÌOÏ@¢GÝ=ûÎ
 «:ú•×éšÔÇ�cÈ`wtÇVµ,*œ‚…Š
õlS·î½c™\–ÇÝí
cÕ†:?†kêû²ªü®¡î¾øÔ2mèëô
+ε=Ð(´d‘0vžÈ5BeOÌZ³äÙ'Ø*âzyóñ
+É’H¢Î jl#ïÅÉt?QòømÂhÈQN¸Æ7+ˆ]ðûU]wÛ¼]V¨éGzò4Ž®,øΓ¾ÿ�2ú+Ï÷øs§àÈ-œ�¸û�¹W5hŠW#»DÜ4¼]=”óN[Ć)Ó
+-ÿùªÂ2kÕYõX_ѼL-Ê™…HËO8ÓT
Ú%Œ\ÀÙ€ÜÈŽ*A
+駎fØ–p¦¹’/°­ƒša[@MêK�w
+.œ±É<	-j„†ï@[#ÍmŸˆwÝ�êp̵�uš}þñjk¤÷›‡¢yØA𴮧™«8/’˜ÛAÍ07 ¦®MŸ·¢vÍSТFHèñ–d û4Üäÿ˜£!igt«M˜
OÂdP!�Í÷ÕúaÒQA>Å$0jÞQuQÓŽªE9GU�‡ *Òmjr(î‹òL7X›yÒZÔmý(Ä0¹dŸ¸ÛÀÈo.Ppltĸp˜/ßm¶ã”9e¯†²hc½ ‰æ|uœºõíÂË(­ëãng†0¶]#Ð5!?¸»Œ+#çå×EM˯E9ù}|)Ѐ„cl¦‚ŒÈà‰ç	lQ#ö¤¹7Ü$Ó'ÑIQiîÝ?¶…ŽÚ3D&µƒ·¥I‹²€èÍvµsBÐ�mt$0~
+:N»Ö4u&èÐwsut4�N8oiDã1‡×žÑ(!¶LÛÓDXü�>Mí¡™@C: ´8“ˆè
ë f4, œ†í‡[&	ãV¿°e
+U×ëì$Mé±°!Љ=¾úUSÿ_ùó]Eúžù‘|;¬r©¤S�Áq@ä3
+½\÷øýb,ö…+Q`É3ruZø¬ÒCº¦R-àˆy oëáî=	YµæǼµã¾¤ß;¿»/ìBOQ‚R¤YŸ”fX[¤«ëùîã§6¾r‡LOU¶ãX][ˆ˜Å"žÈK!Ïid…X”Y±N›¼në{>ZëË‘jÄ.p$=TÇmÖ�¶ðÌÓV‡k–Dò…«‹š±:
å¬ÎYÔ”(¦¤¶ó[ÐÈ–]^%†)nUËO‡"$tu÷¿Æ<¬_Ð\W»ý6G¿1ɉ5ÉãyŽtQÓiQŽ#�/&
Ûü1ßžÕ-5–\ä<a
4BX?c��Y@æØ£²¶z™gùÝñþ¾ÍuaÓ,‹ ڲ慂`5ò€r,ûv¦D³V˜ù-hdËžAS+ÑßòÝ}YuVÞß¼o³•zv„ª;ÜEjø0Á1LØÎ&
+ÊÒ A¦y) J¿p!»¨^ƒo@‡
+&Y’h;¿u
+
e nYÝ_Ö“ëT=]èO�bžÁƒ]
+×Ä‘«8½RHiñ±üýõ¿©“HXÓ}tÕ
+¿öˆÖšÑX
9ø*øå�fCbDk7•ùGÅuSž/…ËS
æ4¹öÓ=[®�ZÄ?G€NÖæÏ-Ï7hÁú'¨'LJM_ÿvõë§_®G"8„ì�Ã%�kœà“Òv[=7 þ§º#&Âî_S³	ý‘”;$oŸP
À%³õh´Œ~Þ$
4²Ø¢y Í›@ÔÛ›+j�Q††
§ãóòÈËú
+c­ß!+kÈ_W°L
wáŽÆ&¼–aã}ç$ì{pß
ž‹˜OCN%C7å;Œ�j!K}ö?vǺ!È�‡¢áHæî(wí6
+endobj
+1815 0 obj <<
+/Type /Page
+/Contents 1816 0 R
+/Resources 1814 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 1797 0 R
+>> endobj
+1817 0 obj <<
+/D [1815 0 R /XYZ 56.6929 794.5015 null]
+>> endobj
+1818 0 obj <<
+/D [1815 0 R /XYZ 56.6929 119.3275 null]
+>> endobj
+1814 0 obj <<
+/Font << /F37 747 0 R /F23 682 0 R /F39 863 0 R /F21 658 0 R /F55 970 0 R /F48 885 0 R >>
+/ProcSet [ /PDF /Text ]
+>> endobj
+1821 0 obj <<
+/Length 1544      
+/Filter /FlateDecode
+>>
+stream
+xÚ¥XmsÚ8þίàËÍÀ´VõbÉöGJH›¶!¹@çn¦Í¸5rÎ6´ô×ßÚ’ŒmÍÍMf‚-¯wWÏ>û"“>†?Ò÷9Â,pû^à"Ž	ï/¶=Ü_ów=¢e#ä4¥ÞÎ{o®™×P ¨èÏW
]>¾Oúóå—Áèþ~2½ºù{èPŽoÑÐánGÓÏ£Ojí~ÐÁèÝd6tˆ'˜B¼x0ÝN®œñûÉøãønz=|œèMæµcMç	f¥Wÿô¾<âþöð¡‡|Þÿ
7‘  ýmÏåq—1³’ôf½?k…�§Õ«608ó÷©gC#°¡Á$e
Û_Ê<�N¯å¯TFjÑYëßTýF?Ãís¡EºÕo=¡“µ¯„¹%,à›C
+8§•¡�
Iô
+cöŠxÔõl¢mµ¨t*Z¶‰vß\ÃVŽ»,E|$|�W"7RÅ´ØDå„Oé~HúNÛy­‘†¢ @„ø.(¬|ê
+Wo6™(´FŸfwöúAÂPF›yá[Gò+,ûð�èzᶚ
A.6åâíÍôJ™	´µå6–q^d!G-=4óK-݆r&¶,~™B«·ÙwQàS®ÇJ#åŒ[ô¹Q—“ºhXpshÀ‘xmøFŸçïï~�Û�„”�‘fæì�CuÐiœÊ<ÍŠx·=šus…	—K‘çCå­€Dº0žTuÂYl¢ÅwS,ªØrä	îUÂS9ãZPª<Ö›†U%)õÔUõX'X*ËŠ³ÞAÐâTZêéAáO-\*ŒåZ'iš&/!ãA¦Ï9T¬Î!``Ð
+†ÖÎ
+ÁœâÙÑô�¸¼
-ý¢sµ”Å»9E�늶{ãMUsÓ2>e›=å¥3•/<;ƒ[F¸@ÐI�džj¥›P«�å"Ù-#uslÐñ¾œ+
F¥yKË� \4…§¼®gˆòF�0é"‚N¥Ú"@Ä‘+:3]¨™kâeC°Óìz:´È˜ÇÛ8	³ä`j›ÁÌPT
mg¹I&°`¿áVCê·ŒTÅ­}×dÀ G‰ß˜4B“ÍXÂ)Ñ÷¼ŽÉû,–ÝTÞôW'¦ÉãòéiÅ�S r],šÃî¨8:¶k˜1u€¤Ž@ô3.Î
+endobj
+1820 0 obj <<
+/Type /Page
+/Contents 1821 0 R
+/Resources 1819 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 1797 0 R
+>> endobj
+1822 0 obj <<
+/D [1820 0 R /XYZ 85.0394 794.5015 null]
+>> endobj
+1823 0 obj <<
+/D [1820 0 R /XYZ 85.0394 562.7154 null]
+>> endobj
+1824 0 obj <<
+/D [1820 0 R /XYZ 85.0394 499.03 null]
+>> endobj
+626 0 obj <<
+/D [1820 0 R /XYZ 85.0394 459.6249 null]
+>> endobj
+1825 0 obj <<
+/D [1820 0 R /XYZ 85.0394 426.4105 null]
+>> endobj
+1826 0 obj <<
+/D [1820 0 R /XYZ 85.0394 390.6449 null]
+>> endobj
+1827 0 obj <<
+/D [1820 0 R /XYZ 85.0394 324.0377 null]
+>> endobj
+1828 0 obj <<
+/D [1820 0 R /XYZ 85.0394 263.3171 null]
+>> endobj
+1829 0 obj <<
+/D [1820 0 R /XYZ 85.0394 199.6317 null]
+>> endobj
+1819 0 obj <<
+/Font << /F37 747 0 R /F39 863 0 R /F23 682 0 R /F21 658 0 R /F47 879 0 R /F53 962 0 R /F55 970 0 R >>
+/ProcSet [ /PDF /Text ]
+>> endobj
+1832 0 obj <<
+/Length 1880      
+/Filter /FlateDecode
+>>
+stream
+xÚíY[sÛ¶~ׯÐ#5S!¸’à£b«­{;µ•¶Ó$´Ù<¡HE¤âª¿¾‹ER”�LÜNÏÌϘ °Ü;>`WdŒá�ŒEˆÂ˜Æã(æH`"ÆËõ�ï`í‡q4SO4mS½\Œ^|Ï¢qŒâ�†ãŪÅK",%/ÒwÁK¢	pÀÁåìõü|zöãüì?¿_]Î'S…”³7oæ—ç¿M¦T` bŒƒ×³Ë·³WvîÍ$¦Áì‡ùÍäÃâ§Ñ|Ñ(ÖVž`¦µú4z÷
�S°á§F,–bü
+ŒxÉ \Ù™úÞM,ËB«x·Û&uVvÕ*m	êÒÎÝúîÕò£J!²‹àbeg‹²¶dÕF-3ý½J¿ƒŽƒ¬¶$©Z%»¼®œ¥öä\Ü2ƒqˆ	µõZÿª^¾Ðºƒ4 OY¨ƒ�‚b!¨!V–YÇ'”¡˜`îx!GAÆͧ+¿D’DÀX Œ
åõ|ñöúÒ&ë/Bã`öê­M×^Àñˆ™ýÐh:5þ9¡’¤(¢�§V¥í„È@Õ»mQYiIaŸêã3UuRïܪ	<‰}dîUm
ŸrëÈ”åkßRU«e­R/À
°c	i°}È*5ì¯nÇ=7ó¹ýxöêæjÀÆ!§¼ÇKøG¾³Ÿ¶<õgY¨Ö²áÇÛ8D '#>Ž//.Ï-“Ø©‘®³"«jÈßrk§®ÕÊ9¡X:?¼NŠ]’¨KB‰h†�¦	ƒË®#fo?^]?í�‹¢VÛB¹ˆÞì«Z­]¬ÎÊ¢*·u¶[ÄrÄxHŽ
ÁˆðØ(‹ñ‘ûÌÞ
+Nò,Íê½}3L³âÎ%š‹ì‹Ï
+öóuYæCÇÞÕv‡ßì‹rSeUB
+8‡ö6{ÆÐÞP
xo2
!6ï¦é?úo3úÔŒ>7£¥5\t1+ÖgŸOöežTÕ
+=×gP[¨Ë&oÀ�´ƒ
+ÔZµ'(Ý÷Ný�Zz·Ã-'欇—®ñe[c¾6f8×۹ľ¶šdvÞ«:£(˜¥PFge‘äù~BÑf1k“Í&ÏtzVõ6[Ö;³d\erõYå•�¾ÝÛ§kÁi~TGôGô‚ñ„þJ{Ç÷Ú–•»z£½Êìª,ÏíH÷õ²;µ£¤rÏÂ=—µî»˜±õ²5®!vgú¯o÷)A

)Ä`À0ŠcvèãL¦Á¯
+cØ¡Qø”—â’7ÂQó·ééœh„aª2ˆ»�°+s^7ôÝ5^cAß<zÕo�î¬{"-tšöåA¤p=.ÏÓËk{)‚ë~$»òæEr›7]ÕÛÝÝ@,:e3\!àH|ÜäÍi‹�1øÓ)ƒÖØÛ6dnKØÏ»Ìw,ÍýÇŒ¦ýöô²Y*‡UèÔÏ:L_wØ�’¸I±oþÉçðãÜ}Í¥jÐ`
+‡9|z¥´ÅËã`bDYHtÿÑ®vendstream
+endobj
+1831 0 obj <<
+/Type /Page
+/Contents 1832 0 R
+/Resources 1830 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 1797 0 R
+>> endobj
+1833 0 obj <<
+/D [1831 0 R /XYZ 56.6929 794.5015 null]
+>> endobj
+1834 0 obj <<
+/D [1831 0 R /XYZ 56.6929 687.0104 null]
+>> endobj
+1835 0 obj <<
+/D [1831 0 R /XYZ 56.6929 626.5588 null]
+>> endobj
+1836 0 obj <<
+/D [1831 0 R /XYZ 56.6929 566.1072 null]
+>> endobj
+630 0 obj <<
+/D [1831 0 R /XYZ 56.6929 528.949 null]
+>> endobj
+1837 0 obj <<
+/D [1831 0 R /XYZ 56.6929 496.7215 null]
+>> endobj
+1838 0 obj <<
+/D [1831 0 R /XYZ 56.6929 461.9427 null]
+>> endobj
+1839 0 obj <<
+/D [1831 0 R /XYZ 56.6929 398.5692 null]
+>> endobj
+1840 0 obj <<
+/D [1831 0 R /XYZ 56.6929 263.2909 null]
+>> endobj
+1841 0 obj <<
+/D [1831 0 R /XYZ 56.6929 125.0477 null]
+>> endobj
+1830 0 obj <<
+/Font << /F37 747 0 R /F21 658 0 R /F23 682 0 R /F39 863 0 R /F47 879 0 R /F53 962 0 R >>
+/ProcSet [ /PDF /Text ]
+>> endobj
+1844 0 obj <<
+/Length 2946      
+/Filter /FlateDecode
+>>
+stream
+xÚÝZY“·~ß_ÁGn•ˆà>ײìȉÖr´‰U±ý0KÎ.Ç&9kÎP²òëÓ8çr#U*m•ˆÁô
+ûÔŒŒ±²p¨pPˆ),"|
8 lpÖ¯kÿ.ÛU¥o%;€v°h=îNa”l³ñÌV�hhÐYâî3ºlØØgµÅ€[ViXH=ê¢ÊÝ&ŠèÀú~¦m‹Ýæ¾R\‘gá›ÌâÛküC;Äš‘6À
ÊrŸGÔ¤¤­‘øI~?¾¢N¯§&äѶHìÆÜ#ÉÔ±“?D¾#i³–èÛ
qÔ×EÎs¬žqD5çç¢¢9y~øBeŠ~7E•¹’2¶Ú…ÊXƒè½?Õ¾3Ƙ®ì5?~,ªð�®„ë)²j,®#ÚC†n†qݼÛ¡Ÿ€]î惡CjSr0	–|±¦6ûç—ê�’Kc@Èé¸&]¥Tó÷ÁÿDÅaŒÏ¤P-¢é*¹êa4�’šÅÀÚf1`hý
+ÒOÈRù,[‰hÈW7•HH£:Œ�g²�™éT¶]Z®´É£šbÞ:�IA®ÃqǬëü�z³f<“j*AÃi æ…¬Ú³�S“(DHÑ4N0ƒ=‚œ©æµ©f�©T¾«{ĸbg°B`€³¬%ªÞºhQœ�è2—àÂ4´f	.¶ÓÂÅö…—.
y:Õ¾3Ö¢l«ê
RàZ™x´òÄÓ‚
+µ¹Ì\
Z\p~®ÄË>Ït.ÒÈó
+ѨôÌÑi›jš‘ÊAóðYÁÑ,_):ò5uk²MÆœç½&Kç|í³+‘16R"c49_Kpª!ÉùºjIóP5qçØŒç;(¶ô�/â�²è|;_Ž_`�ÚÕ2úµ—t+d¸øÁÅ—
+ŠÌ3<»0ÿÿQÑ
+I†ÏÜiSM[f¢r–YžOîA£VJëäQpñóÌ%ªî:öÉmÙS«.{?^+¾<õ Ë‹I|¨I»50ӳǯbd
½‰¹¿�nþ„œø.%®ñwêÎêòøiZö1ÿ¹MLë_HÄ$;ã™ÛT3ú�TNÿÕÙK-Uýi—O^j™å¬¹Ô2dmôRK‡·Æ9k2}ƒ;®ÏUÛïleÀù_èXѦ©
+rnW€—÷^5ŽWyʹt“øKO—Áñ,#N;Ó¨ó°™»2í�ä˜ï2[¯ž˜È—b²{É \«èî
+endobj
+1843 0 obj <<
+/Type /Page
+/Contents 1844 0 R
+/Resources 1842 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 1846 0 R
+>> endobj
+1845 0 obj <<
+/D [1843 0 R /XYZ 85.0394 794.5015 null]
+>> endobj
+1842 0 obj <<
+/Font << /F37 747 0 R /F21 658 0 R /F23 682 0 R /F55 970 0 R /F39 863 0 R >>
+/ProcSet [ /PDF /Text ]
+>> endobj
+1849 0 obj <<
+/Length 2037      
+/Filter /FlateDecode
+>>
+stream
+xÚ¥YKsÛ8¾ûW¨j÷ UYž$pt,eÖS‰âµä�­Jr )Jb…
öx~ý6�"%HJÕ–l‚­îF÷×Àd„á�Œ„‡<EÕÈW	LÄ(Loðhß~»!–gÚ2Mû\W7>1¤�ò¨7Zmz²$ÂR’Ñjýmüùhðxq÷e>›L)çÌß=>γ‡ÿ»ÀÀ,�¿Ü-žï>›µÇ‰¢ã»ßæËÉ�Õï7óUgNßd‚™¶åÏ›o?ðh
–ÿ~ƒSRŒÞà#¢¥7\0$8cíJr³¼ùw'°÷µù©Ë\H$(÷À1ß;ã(‚|B€Éçzð%.?Y&í¦i¥·ùá“=F¥?û Zs¬ã"
+«¼x?ö!
+yÄ;ÈsYÖ1�šÆz	…
+ã
$SÞømAîæEg“~†»(ü©I¿	G³Á�B’§q¦#Üü4NÖ¡éëís9^\æ2K‡Î
+‚$ÍËÊVÈ.
Ùe‹�™‡:¤pjÓ#¡¬“ʼçóÌcÄIÝji~˜›g�­£¢¬‚l}$°o¦Y
ô†»8ÛZÁÉ6/âj—š×ïXà§O÷æf*DƒËñc^–1
+BÙµl>A\ÀÔw1›ú\糩ãÒu’ë¬?i¹˜!"%¿¬¹ãr¨&ŒD0óùCÝ«®¹äiЖ»Æ˜†Ê7G=èP'_" f¾�œº0ÏhÜ0i“+žëq]ð\Ëe0Ñví“R#Lïü²ê–É¡zè9øêyþPwç¹_ò–±u`ígÇ	Ž ~Ai`>ÂŒšYèi¾z~Z˜ÿgóÒøîó³9ÿyÒJ /ë÷’3ÝCr8Ú°6=LªVu‘µÉkQýWv,©‚ª.‡{$Ãa8*̈[X¶·¨+Q\QSKÛM…[‘ºJ¿Åå÷´æܳœÏÍ�ï>/¿:öèrŠ® R׎ÛÞn<¥G¢ÞçF÷C2´"•uš©�Ú
˜	‡z়«@.� GÚšóña13ò”ÝÕÚL\Vp€Éí8øm¬O³ÐºõK�ÕЋNÕŠ¨×ÀÜ~…î	µ˜¨¡cïžWÿúútÉ£†ï!ƒ^˜E!Ëw˜’Sûû<+ó¢Šëô bÈ=jåp
+KˆöJ`5Ûp´�J¿ÀX5,›ßƒàAY/Ä6Ù(õ
5´Ò]ãʨx�
+—‹ðæÞ³|_Æåq­aPÁ¤ÇFDR$ˆûÚÚ¿¢BÇûb
ì‹0w*ÊQ;®Þ¾=ðà·)ÿÑR^G…vV
+Š·ÇIûóMl]ÇŽ¸/ɱŽÌ!oÊÀ«„é[‘þTó�p_—.É
+Ié«cÉû«NÙCj¸ä1¤ƒQ'¯ì¨Ê!yè£ñ:Á |âˆúª¹p¼,ÜŽ¥ÞÉî_;꯫ֆ
TÞs�žE¸Û&ÅÈ#À?HÒÙ|yÿôð¸zøºøÅ^éš
6¼»Ñç:¨^z
+hhÝIf‹¥Sõ‚-1>‡V
+endobj
+1848 0 obj <<
+/Type /Page
+/Contents 1849 0 R
+/Resources 1847 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 1846 0 R
+>> endobj
+1850 0 obj <<
+/D [1848 0 R /XYZ 56.6929 794.5015 null]
+>> endobj
+1851 0 obj <<
+/D [1848 0 R /XYZ 56.6929 496.4666 null]
+>> endobj
+1852 0 obj <<
+/D [1848 0 R /XYZ 56.6929 433.6488 null]
+>> endobj
+1853 0 obj <<
+/D [1848 0 R /XYZ 56.6929 370.8311 null]
+>> endobj
+634 0 obj <<
+/D [1848 0 R /XYZ 56.6929 332.0288 null]
+>> endobj
+1854 0 obj <<
+/D [1848 0 R /XYZ 56.6929 299.0792 null]
+>> endobj
+1855 0 obj <<
+/D [1848 0 R /XYZ 56.6929 263.5784 null]
+>> endobj
+1856 0 obj <<
+/D [1848 0 R /XYZ 56.6929 197.8388 null]
+>> endobj
+1857 0 obj <<
+/D [1848 0 R /XYZ 56.6929 126.0307 null]
+>> endobj
+1847 0 obj <<
+/Font << /F37 747 0 R /F21 658 0 R /F55 970 0 R /F23 682 0 R /F39 863 0 R /F47 879 0 R /F53 962 0 R >>
+/ProcSet [ /PDF /Text ]
+>> endobj
+1860 0 obj <<
+/Length 2811      
+/Filter /FlateDecode
+>>
+stream
+xÚÝZÝoÛF÷_!àJáf¿—D8±/pÑ8¾ÆA´} ©•ÄV"‘t’þõ7ûE‘%ù�ôå Z.ggggg~óA“†d–„YÊg*åH`"fùæÏ–ðîÍñ4q ŠûT¯.^þ›©YŠRIåìaÑã• œ$dö0ÿ5ºº¿¿¹»¾ýå2¦G¯Ðe,0ŽÞ^Ý}¸úÑÍÝ_¦4ºzsó9gˆ”!“8º»z{s}ùûÃ7�8}‘	fF–�¿þŽgs�ü‡ŒXšˆÙ'xÀˆ¤)�m.¸`HpÆÂÌúâýÅ:†½·vé”
+K�H¨šÐ
%3BP*(A¤H2ʬÞÝ?ܾ»{pŒ°
+d¢—ôŒô©Ž[AGµ|Ê
+NnÙYÁá–SV0زoòï·þd 5KÙ9+èQ�°‚@eÏ�àBôLj2À2'x^•‹b/
+PñH<"	”³ÓòuTô%%ÂX¨¡„Æhœˆ}ZŠ‘T‰šqÄWæ&€ÃþÀjX*œu�>Ìâß0¦Ëv—5EUº·ff­Ý¸(ëFgsGmìk°|®Y»n^LÙ‘ˆ‹4HùR7ùË2Ûè¹½çYÌ$EI!&v¡‚t‡™8e(5�Íñ‚P˜H=˜(Y]Æœ‰H—ulÌ<7«¬1#¹Ùu•Í‹r^zªƒÓ›Épz³š¢luíúÝ>U»?A¶hônĵֻ§0¹�Ûã†Ä]`4§]eåRå²4*šÚ
w+«y˜î
+Ñ
tsrË@4±å ÍQˆ&‡[þÔ–#Í8tú½\x/Ý·¥wêß°À¯�
åVn¶¬|*äì´øK9®W¸V&å9½ö¨Nè5PY½.'ÒÇ$•g¶D[ŽÒÇD©Ñ–ßH¯Yx‚<ØóÚ[ìº
+^(ö®>J"!£‘]d¨›¹Þí¦œN dOvô’¸JMÕ™KêS¿¤ŽÊ^Òf
+9à H°Xg7I RKÂåiÁ:ª	ɸH¡HNE:
2µ;)9‹lÄä<Ú€MÛsm�-µÎ÷Èh¨ ®²lY›v
+=1‘}ëÄŸË>¡R†ì›³¾|*l̤nêÛAe¾`žPUn\¯ÇL¯ü l7�6äswCkäw3[�)ºlÜ„ö0È÷a×T{ÎA‰žEà\‘£½]¸™Â3-ünméûNœû<
Ô08`ÿ}`ëNÑëX™S¼ð©ˆOo â…¾V¸wǦ'²yW„Ô%‚ûÓÎ�:"³á¢ÅIOìSwÅŽÊúâö¬/n«]sèŠ%\œ–+MÈ5Ì9 TR9ìÇ¢nB“Ñ$vð±Õ»BסéKf/ß8ò
ÈÒ½/î©Î‡¾ÛÅ(8Ö¸�²-¥a—ÓnfG‚¿S	åçî´GuâN•½Óz¢ŒR	¨âä–�hbËQ¥$‘Ã-¾T<Ú¡‹RC3ö©¡Uc“5p­E^ŸÈ×Mi.9ݧëU;uq,�ÄF†
+>Ø‚þ\4
+'–� €• :NŸæYb¿€	ô€Êt(Àh�òrë0ðòC·‚�s† ]Ld-)}µ÷>K¨þ%…Ä0F‚aa~×S��œø–°`4÷w—±$�ÂÇ’F7ª
¦ŒŠª$	’K»ùìãOSæ¨zc{Ú½ìÄËÛ
�]Wp¦YÿX�sÜgmÏ%iÿº¡<KœØ,ŸS¸[q¬œ+©®“gÆnNF›¬ðŸ"”GdxWzk÷íAùìTE¯nï®ÝšÔMÌõ%ÃÑÓ%¦É
+ñÃoãM¼
Á·ÈA´‚,S]á×ͧ¢‡…(•ì{¤æÁֹ𛹟EÛ´;íÆ;½6]ÃõÀ`¹	ÀL¥o_ge,�ùÔ4t÷ŸH¿Îb_(ÅÔÈHø	0r‰Ï¡XGeQ¬™ˆL)‚h¡¦ÚÁ«hJ%c³þ¶‡á)PMH7$r~oâ½vq½²!‚Êé6£IÉ{N÷tÈ»ªÓwé
[—$U¹®k×æ0[Ù؃¼ÚlœáÂÃÚe.` ®’^¶Ȭl–ÂHôØz9õbß&„ç��$Ü”8�Ì»‹wÍs_¬Ðµ>
+¼DrD¡¾	ð¦ñ„§ÿƒK„Ç€Wa¤0 ÐÜ%èêãÝìBí§h¨¿®,àþdÿg!ø¶ÓèÍQ †Œ’¦„{ Æ�žpîÀ·?>Äì÷YŸ
+endobj
+1859 0 obj <<
+/Type /Page
+/Contents 1860 0 R
+/Resources 1858 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 1846 0 R
+>> endobj
+1861 0 obj <<
+/D [1859 0 R /XYZ 85.0394 794.5015 null]
+>> endobj
+1862 0 obj <<
+/D [1859 0 R /XYZ 85.0394 751.3856 null]
+>> endobj
+1858 0 obj <<
+/Font << /F37 747 0 R /F21 658 0 R /F23 682 0 R /F39 863 0 R /F55 970 0 R /F53 962 0 R /F62 995 0 R >>
+/XObject << /Im2 984 0 R /Im3 1108 0 R >>
+/ProcSet [ /PDF /Text ]
+>> endobj
+1865 0 obj <<
+/Length 2226      
+/Filter /FlateDecode
+>>
+stream
+xÚµY_oÛ8ϧÐÛÉ@Íð¿DìSzMr^´n/q±ìîƒbщP[òZR’~û›!)G²e÷½C
+4Ël›=ë¢ùîç»|ÊÊ¢Þà4ÁHsËù®ÚúQ¶^ûÁ®ªšàµÜAªÎkYðÚÉ”©8¸.JÓAã×¥Ý6~î5Ô&~Ó
WCxÓ·¢
+ìRÔ~óÆfeàêS‡Ùq
A!½ÒA"ú"'å,�T[ÌhžgU‚
+ît<Á$	
:8Ýziå
÷
¯“›øåÉ–#^¸"™‘?öZ‘òη‹ÀÒh18xŠyÑ­8°É	',õ¨®­3ÌèÊœe¿>ÂÀ
+DS…žñâ§ÇA‹ÎyaÓƒõó�m²¢tn‹†{^_íàó\Ä@õ
S‡ñGøy‹ð𵟿${m vš¾•<?‡Y€¦$M@P	@¤â|}Ö
raÎ×G{*Vχ–Ñ Iõ™‰ìˆFDöC'AP£"ï,B¾—1qðlwµ^œ”íæÁ{õ‰öµhŽ®±;ºâŒ@Rc?°O�êŒ}:*gŸ×±ú‘’
+Èà[Ëlùd§+ðñCí‡$¯àÖΪ·§ÑO R„0z¨àÇ*ʳ&ó£•+ݪÍHY	7¢©GU?�§AœÖÝ)‹wpgn·V«ƒw¹]eí:Üòsa_°ï8YåIˆ©ù?©ò’ªŒÔü
ív˜“%ž„ûÖ,U?(ñ
+túõS>ú€œ�ÛCõÐË•=§ï’¥À#)ãûšûÙíüêãýH.¡X‡
µ‹#œ¡ý8T–.OµÐ§Z¿°ïK¡*á‚AUòXfXoàËú©j×x<8.>„�èT~äò<—UÙx
k¿Ç''xƒ54Ô€9¿]û8 @Ó„§]Á·+óåXë
53¤Ç@ô¦Ú±FèÃÐgùIô`i°vz½úT§ÑkO.ä_¿}ÜH5Œ�Û�ˆ€å„&зäÞTÎðË
+Ò­†0(òÔÌÌ«—ò¼yàŽ$ �Âï+24	)ÙöÍ]ïQ¸3wmËÜÐqåÕ÷ðÄ„’ë-èPz5®…�¨-sû¥¼´Þɳ„¿„RPùo_ÿ<¿™Ý~½»Bƒ/fŸç?N‹®E\%[3ò=aÀJHB™î:mÈ
+¨écëóv"Æ•µëG¤‡"XkªÊü·´Wÿ¶	‹¹­—»â¡ÛSv«Ðˬý͉@°¦÷H>ÌÙ>—í›"^¸ÄÎ	Whб—aíùs‘w_Њž£¸ãËÁ÷cE¤f]#ä�©�\团,êÌQ…[½³« {ÙEð§¬l³õˆq™N±JÔý>ëðö!Â
8¶1Þ|åz3û8ò:Ä°�«•šŸ�ó‘‹/(JŽã¼#B‘—¶Y^:?!à«ãð†ÆNéä¬ô=Ñ‘øƒð†"]¤ñ‹ÑêøÈ#qÑ{äÉ4Vgà'çÍÓ#:mžŽÈ™ç9Û]îÚ2˜h[äGÒ+yV�=Ñ‘®¥CˆÑWaÜD!ð“Ô´ÈÏ[¨ÃAp{1Ú/Ó½oþôÿ8Þþ‡#!Y¥é	_€$M`³î”ƒ2Æ�/
+.
¾r¬û¿
IË!endstream
+endobj
+1864 0 obj <<
+/Type /Page
+/Contents 1865 0 R
+/Resources 1863 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 1846 0 R
+>> endobj
+1866 0 obj <<
+/D [1864 0 R /XYZ 56.6929 794.5015 null]
+>> endobj
+1867 0 obj <<
+/D [1864 0 R /XYZ 56.6929 361.2723 null]
+>> endobj
+1868 0 obj <<
+/D [1864 0 R /XYZ 56.6929 210.791 null]
+>> endobj
+1869 0 obj <<
+/D [1864 0 R /XYZ 56.6929 130.947 null]
+>> endobj
+1863 0 obj <<
+/Font << /F37 747 0 R /F21 658 0 R /F55 970 0 R /F23 682 0 R /F53 962 0 R /F62 995 0 R /F63 998 0 R /F39 863 0 R /F47 879 0 R /F48 885 0 R >>
+/XObject << /Im2 984 0 R /Im3 1108 0 R >>
+/ProcSet [ /PDF /Text ]
+>> endobj
+1872 0 obj <<
+/Length 2455      
+/Filter /FlateDecode
+>>
+stream
+xÚ­YYoÛH~÷¯ÐÛÊÀ°Ó÷ñè8Nƃ±ã��ÅIŠ²S¤F¤ìõþú­¾(’¢ä
+Á	1¶î3]tX•Q}v,_ý¨�230ž�GÁq%âZ²aêIËÇz&\ƒhÉœ·Ùçï7—ÉÍaW4dþ²*²•ŸÙ5yàIý£YyÚµÝ{žù÷Ö¿ÛxhŸyEä•cå.DZ‚Ç"Fê
+NLr3XE�zAª‰õ^÷ן’¦}-�(=6�£-m`RÅõ>lدö_»¼iƒŒ8ÓñÐKÕ�Âø?šþ÷Íð“[ýa‡e9XhRõÆÃϺ{Wnv
![¥`“Ps®wMàüÃà<Æ–Ÿ¯!&øÇTî‡Ò™1j¬¢?÷G‰I_¤ï6þ
+zº+ésÅû‡Ã¶¤ã²ëv͈èÇIEš`G›‘¾†V—›Ó*v\:ë(ÛQR:Tòk“OÞC
*ʼn–i ü†iû�Ôe=³+uß[xf¹Ÿ°‚|x	œ>–
gø„ô‚g�U�FždÍ
+£D¹rá
Œö¹Žc´ãrͦ0Š¡$GÚÚ
@%A˜rvZ¿ŽkBÁá•�DŒNÔ60¤óÈ•
+xï¡“˜€$b&b¤%ÆiÇ5Yý‹=wbØþóE¾L
d¿Mõ¼NF‘¨å»¼ÍÞÙ`î.ɦÜhpópøm§ÁÐã:
†ÈåÀðôfÀê_F�À9´ê‚ŸV®ãšÐnpºÐ*(L†êE‚QœN^–„B»†¹2=PËgÊB¦
J—)Û½�p.Ocú‰£'B#M�>8úPÈŒtS
+"²Þ_VBiL ^ëÕ¬:K	è0�’ý•|D„ê)‰Ã"ù„`u£IÔù¥°õ%Ê×gð„|»ð#áÙol,Eö{B¢b5ØûÂ�ìkN;.–ûɉd¤CäW}ÝCע΃"UÝF£Ä¥5^ùŠ¦=êpÚØxÈNû[�鸻E&çmÍ›¡wM7ð5F�–ã¤^Ó�bCïa¢Ô@³þíà°ƒPóÎ×üm†‰-œ‰å Œüí„fz7±}ÓÁ
+®K¦Qu3¸ÅéC¯(:rÙÇ #ãì
B; ™Ú;û¸Á½þÇ Õk"m�BÇ~¼dÙ{Õ	‡Á]ñ·ØÜÿnËm]¬�”;sÄ E¥ì~	acÕ»Ÿ@uÿ‚D|Õendstream
+endobj
+1871 0 obj <<
+/Type /Page
+/Contents 1872 0 R
+/Resources 1870 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 1846 0 R
+>> endobj
+1873 0 obj <<
+/D [1871 0 R /XYZ 85.0394 794.5015 null]
+>> endobj
+1874 0 obj <<
+/D [1871 0 R /XYZ 85.0394 752.1052 null]
+>> endobj
+1875 0 obj <<
+/D [1871 0 R /XYZ 85.0394 676.9839 null]
+>> endobj
+638 0 obj <<
+/D [1871 0 R /XYZ 85.0394 637.9396 null]
+>> endobj
+1876 0 obj <<
+/D [1871 0 R /XYZ 85.0394 604.8838 null]
+>> endobj
+1877 0 obj <<
+/D [1871 0 R /XYZ 85.0394 569.2766 null]
+>> endobj
+1878 0 obj <<
+/D [1871 0 R /XYZ 85.0394 503.1887 null]
+>> endobj
+1879 0 obj <<
+/D [1871 0 R /XYZ 85.0394 431.0324 null]
+>> endobj
+1880 0 obj <<
+/D [1871 0 R /XYZ 85.0394 247.0209 null]
+>> endobj
+1870 0 obj <<
+/Font << /F37 747 0 R /F21 658 0 R /F47 879 0 R /F23 682 0 R /F39 863 0 R /F53 962 0 R /F55 970 0 R >>
+/ProcSet [ /PDF /Text ]
+>> endobj
+1883 0 obj <<
+/Length 2194      
+/Filter /FlateDecode
+>>
+stream
+xÚ­ÛrÛ6öÝ_¡·¥ÚÆ�Dß\Ç麓8n¤tv¦é-R§é%){õ÷{p£H
+²§ÓLf"ðàààÜ/0™aøGfB"©¨šÅŠ#�‰˜­wxö{¿\‡³ðH‹!ÖÏ«‹Ë,ž)¤$•³Õf@+A8IÈl•ýýŒšÿ¹úõòƒ`\J�¤‰úéËÝûktýùîƒÅQ¥	²‚:Ô«ûû›»÷·ÿ™/¨À@}¾GŸ®î¾^}´°û¹¢ÑÕ/7KMìâfÕË1”•`¦…øïÅâY"ÿz�S‰˜½ÀFD):Û]pÁ�àŒyHy±¼ø­'8Ø5GCºã"A‚r	Zdˆb‡5LPL Åœ ªDÒk˜’�†=–ÖÈâÉéW0	A‰�[¥=ÕM7Õ†¢ˆ«DΆ7žðå‘|
­©bÄc5ák™W™µÈºÞíÒ*kíWWÛßÕõ½]xî&.B¨B,fr"Ãäj*ÇÄáUÛå©»µÞ8¹½{oWê_Ž…,ߤû²óÜU]3'IT—°M«*/�̽sÇÁ‚'>åÿ!Œ9}ú¬W¬ë±ŒuŸ^)cKÂ^¿Ò#®j/¦(æTŽ¯¼©Ò‡2·2?çÍCݺ�²~|,ªÇ³J�	†�{U	C¬óJ豌ag<æÎôå‡)[‰D"Æñˆ­·ž"•$I8Üžà©#Æ…„Pr,B‘MÙ#˜ AxüºÚz¬€ÞFÑ‚!”$ã[¿ÓIu[·pzšÄšà K,Îë’ÄŒò;êÒèr$dÚ)sª
¨MJú’²±!½›ˆÁþ
cú¸oÒ®¨+Ô�2GÁןWc1J ˜|7Åx‚o(Ì…bE’¿­˜Ý¾í¬ØÞ%ªúÅiâá eT¥»<³ —¢Û•Ôg3'J[‘ %„M-œÑyBDiùX7plç>mQ›¯�UòÎ}w
¤».4‚GµÁÈòÆ‚7µ[L²´ˆvyÛ¦�îÆç´,2oQø¶5nد×yžA—À¨ˆn7ZÕ
S3%‘”ž75ª@µR&(�zþ©­{Š‹!ÉScC
F4!äxóYc/8�š@�æŒcÛ°*ƒF©}Ê×…ö÷<{çN“qPÚ—¬š*[‡J.C\2/EYZÚšl£�K”uý—^0áœD�]§vS+×,Öeº×)J¯µè_«¹Í›ç¼q|wi—ïòÊQ×µ}€‹G¸¹ñ*Mˆ[9¡&ÐMH6öYã]ŠG…öe<Ã|{r6¸Ú ¶üd]¹í7¬«*'©mëV7KÍie�6ÁÂu!£
}ÐkCoÖOÌž´{·žF0<–H3Š4’ŒîêNŸÅÊs„G@§‰vm"캴0ÂN»M­¼™Ý=†²CxÙë­Ýs˜®-à˜¨)ÛjĽÖJW¬A˜l,ŒõÚÓÖ,ØIV.óx7hu¼ݺ¯ÝÖûÒu…p£eoS÷ljµÃݦÏô˜Wy“º‹-nßZ6ö÷²œÃN!Ñ´-r	ÂëâFÀé˜F˜æ��
¸ÔÒ<•¹¡
+ÈÙiç%ù’oœ6«µ;ö)­ö 4«&঄Œ�ê•×ÌÁ;ª€#Lbú†�Xe?è"Uï�	­ÿ=îu(L<ÅŠ	‹ÂïlóòÉ®\AA=G}XAV:�ãÊ3´YÒ
+òñöÓíÊ›ú¿Õíç»e@pi*�`œ¿-ŽÏ©Y�·¿<äÞ™­8Q˲wëP„ø¨ß>CIÈ@:h¾½ÿ„Y%JO÷Þö]QÝaN‰¼÷CªUºZ9÷·‚¯|àÁõTÙ4
+¿ë}ã<¨+d’0ü¾¤Ð9€M¹õs‘">›ÁÎ(=Q5î4àÛæfX¤î…A
¥
+ÅXÈך<®õƒ”xÂøwhò,ÁÅ�¢}Qr¦{AEâäxñkM
„ˆ¼om“¥éõušý
8hƒgºÊ€£c56â2>æÄÜZÎdz‹ŸÖûaŸr¼k–¹³R3�y4<Š°åÍ�=zõqù9 t ¶ˆ¶ù†ðyw,™&S`=[�͵|ô$³V,˜ÏPƒÇí$Shš)
tÌ”SSB“M¸7f8!±R=Q>#�¡ÌëØ×Õ¿?y[S·U—7•O)ËCŽ3Ü54�_Šýîx¯ž¥·'HÞ¿î9ý$C,ðnóaiô"¸ð¸(”++Ç�®è§‘ª¥PˆÆ Zˆ0¿#Ф`üFi쪎NjþÝgû(XÅ‘ƒªú©…\6M$h6!öQ"xðÑò¨¢æ‰îÕç’!‰ÓáŸKz¬3
+?aïo–×_nïuñ:£ïP|…ôÃ$ƒ½¾Í¸!ˆëÏCÊÖ»¾ÝÔ:CŸ$�ƒöùï54Ðço¶Ñ©¯S`»E
臆é+ Þ¶…$Pâ·V.<àœ@Ç耩˜˜"¬ød
+îSÁ?þëÇñÏB<F,IÎ<1S(TpXz¦´Ä„ðÓ7d¬àýÿ&t}Ûendstream
+endobj
+1882 0 obj <<
+/Type /Page
+/Contents 1883 0 R
+/Resources 1881 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 1846 0 R
+>> endobj
+1884 0 obj <<
+/D [1882 0 R /XYZ 56.6929 794.5015 null]
+>> endobj
+1885 0 obj <<
+/D [1882 0 R /XYZ 56.6929 546.7712 null]
+>> endobj
+1886 0 obj <<
+/D [1882 0 R /XYZ 56.6929 448.103 null]
+>> endobj
+1887 0 obj <<
+/D [1882 0 R /XYZ 56.6929 386.1077 null]
+>> endobj
+642 0 obj <<
+/D [1882 0 R /XYZ 56.6929 347.8768 null]
+>> endobj
+1888 0 obj <<
+/D [1882 0 R /XYZ 56.6929 315.1782 null]
+>> endobj
+1889 0 obj <<
+/D [1882 0 R /XYZ 56.6929 279.9283 null]
+>> endobj
+1890 0 obj <<
+/D [1882 0 R /XYZ 56.6929 215.0111 null]
+>> endobj
+1891 0 obj <<
+/D [1882 0 R /XYZ 56.6929 155.9807 null]
+>> endobj
+1881 0 obj <<
+/Font << /F37 747 0 R /F53 962 0 R /F21 658 0 R /F55 970 0 R /F23 682 0 R /F39 863 0 R /F47 879 0 R /F48 885 0 R >>
+/ProcSet [ /PDF /Text ]
+>> endobj
+1894 0 obj <<
+/Length 2682      
+/Filter /FlateDecode
+>>
+stream
+xÚ­YÝsÛ6÷_¡é=”ž‹P| ˜<9‰Ós¦ù¸‹;Ó™^h‰²x¡HU¤ìsnú¿ß.€(šŠÓ¹=\€‹Å~þ3?1³šq•§³,O™æBÏ›3>»…¹Ï„_3‹æÃU/¯Ï~x£²YÎr#Íìz5àe·VÌ®—¿&?^¾}õËù\jž¼dçsÍyòîâýÏ?íãy.“‹/?Á«Ì3‹rvþÛõÛÞh5`¯òœe©F©�ñ?Þ¿~Å^}xÿ—ž]^Gq‡G\¡¬¿ŸýúŸ-ádoÏ8S¹Õ³{xáL乜mÎR­˜N•
+”úìÓÙß#ÃÁ¬ûtJEZY¦­Ì&t$Õ”ŽtÎŒ‚)<ÊÏMõoÒE×?Ôåóó¹<ù‘ú–že³¤A»¢g]5%©Iåƒøl.,Ë…&Þ»f¹`‹¶YÑÒ#a´a2S^ŸUlS›lö‹5Žò¤«6ۺܹ_ÍÄn¹fÊFM±)—'wóeÚú¥àŠçÉõº¤Íþɹ¬KÚkß•Qûõî\ؤô]_ôå¦lúî9}2¹uí¶¯Ú¦­zF“
+3›K!Xª¹ÖÒÉÑ•»;wF§}ÿ!½Aã=>—£uÎMÇÇ#=V”€Ó+ä}¬¥4e9—ÁÉ)ž% Ù¾¨ðœø†*»+ýL] Ö@«©§D0)ãÚhÏ{Y®Š}ÝϽ‹b
Æ›ôËiÚ­ò¬ÚºnïË%½Ý<г_ûeè¤{%4KS>Ò}zWR$ÅrIfî:" ‹»	z8>nˆÄ‰›¥èBZ*8lå?[·]O£ûª®itã¿Ù—~n]6žo‹O~ÄŸ¼
Ç�ëmu>(<©ïNìÛ½·P ZI‘b’ƒccHN¨[r–ÆH³¥ú„!eÆl&íÈŽèž�¹šœq©Í؈ÒúóåC#ÕQæÞˆ@ÊɽU,YÅR8 ý~]aÊò¬– ‘
+tÌ·˜:O.˜ÈLrú R0ÉÓ|sr®TBli™-Sá¡øœc’+ÜX´÷ãÍ!	BÊW‡½«åÄî
+J€Îõ W*“'[gÿö®¯\º“±mèI„m�½iÑn6.« ó7d(()‰§åÓJ‘±Œëì)õžª±��'	kÁÎû°MÕ© ×MÑ/Ö^™`#f�°Ç.[5·S	꼌9•FT:me48z*hÉÉgEðcz!ç²<D²õ‘lc$[*�H)ö kð·°&
+é–„€†tñ½ßÇÁ¿‘êa%e ¯�1c³q©ØBʦ›e'BÓ,ëé(4·í®ŸÐL–bE|›Üø«�¬ñ	V‡kÇ×�zðÀ–†P$šrè-}âœßéSí�»i{Ïʇ9Œ¼Ê\‚uÊÊ°”Ûãðr1ÅOÄ”„B“ª� Nœ^Bà
:ªˆÄ3”—^[0VÄãcH‡Øâ‡Ø’2‰´’*�"¦Ýoõ`(;¨„û°Oåe,hÆ×tü`Å
+ƒ«�w)Í@$’ñËA8tÚ…_<€6eçÃ)ÈvO~Õ"ðFýp.„H&ñåŪ?€ò)㤂e˜¼žÊË–)eÓCU¹o�Ëg
{Ô ò[ÓkÕ,êý²ôÀ»ð}C¿Cw¤ ìÔÆ#òE¸FiÇAx¿ÃDªݑâ,tgRëc¯((ÊJQGéð¡¡ÃÍÀ4|²&4'‡M¾nÛ®«njÿ‘w�çSA€U"��dº.CíÎUÄjϦ
+6Ê—TY|.iD�õª”ð¢&êÝm#Vðk§”i
+Ý�ªËðúÁWüdX]pÉÈG4ÿuäDeçÐK¥ò뽆dœçöñEÊÑ5oÝ
Žï«~�0Ÿ;7A
+5†«W �@Å!L(9H¥ä�#42ˆS(�ižYKy�‰á²;úû6´‰,3éȡõÉcE ز*¸eQ߶;8Íf*È!9ïÑ­/ÖåS‘R2)›Åî!à\˜80u¯«àÌG—"Èdcÿtêò
+ÀÌË«÷¯iqNß‘ÝîŠÍ„«ú‹;pÕã+šQnÄ‹bºÓáA¡nÒ5¯¥d
+¶õÉ4%-àó g{"î …¶û>£WB›Ù
AÇ\n™ä±+Ülœ¯•S±/™´<€è�zü>EÝy	?7í}ãÅë¦öä–¥*
¬6ÕW6UL¨¸é3¯b-×øÄ0lIuÆ#†Øò!…àP>T]Fwݸ<º½
+ãÐS¶åðR¬§½»uµ%‘‹âlî%ß÷áÎÙ2žK9ºÉòa[ÜU]Ä
i`S4á’ÿ

+õå/ï>þtéc¹
<\„9j� Ð8^O„¿nºÑâ°ØA}Qdw{Œ­ZžQÊûNT,è$öG®³Ëó£æ†óä?N3�÷twí‘¢�°¾nE�mÚ‹)l<¼x†ìÀÃ�áý…ou§vú#2ƒŠl¡‰:úÆ·ýŠÔ"â€
ÿ¿­!Q÷Ã÷§ö–©ÿ(î<ª3‡îÀó›:!õ(8ÒJ«4üãÏœÄD2Cm<i÷
IÑäëM±˜o–zò0X)J’”'ß™7ïVÿJÕ‡îKZ?ÜÈôÃU)«/¿äõJÔõÛ­¿|7}18ÃÔ_·àÉøëÄ­<žâþ[÷ð·vš1e­œþÇ-F“B¡äBè±èñàDzÿ1'¹endstream
+endobj
+1893 0 obj <<
+/Type /Page
+/Contents 1894 0 R
+/Resources 1892 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 1897 0 R
+>> endobj
+1895 0 obj <<
+/D [1893 0 R /XYZ 85.0394 794.5015 null]
+>> endobj
+1896 0 obj <<
+/D [1893 0 R /XYZ 85.0394 368.0049 null]
+>> endobj
+1892 0 obj <<
+/Font << /F37 747 0 R /F53 962 0 R /F23 682 0 R /F39 863 0 R /F21 658 0 R >>
+/ProcSet [ /PDF /Text ]
+>> endobj
+1900 0 obj <<
+/Length 1897      
+/Filter /FlateDecode
+>>
+stream
+xÚ¥X_sÛ6÷§ðåeò]ÅŠ¤(ŠÛíÁMÒ6[㶉»Û­íƒ"1±®²äYòÜìÏwHP²l+Kz;?˜A
+'"ä¼¥£ëÑûN`oÕntXÃxĆ|¡z¾PŒ‡cJI‰¾ø¢ï'~ö5ºnºÉ_Æ°1¥D	
rÛ�Ù�wÕ:oKä\,“Ô_fâ»#hyQx­ÓµnÀg!pž\ñ×ñ»èÅÏ[õÛö×íŒÿòÛÏ›÷?þx‚{ýÁãþ±‹Ï_2Þ³Äç‚Ä‘0
+£{Ú
½3
+”º=Æ^;žã<´g^8ÔlãöºcïõåôÔ¿<8KŠ	õº´«#òÆmÝ)‹ó´Hð¢Ì¸*›$/-§Ür“ÔÚ�Bœè2­²¼¼ÃYuû�Búï
@	¢Šª¶	3{‘ðŸU›{0þ}S�“H+ŒAøóHb>ßdkL \?Y!¨ç‹8³(æâ8‰eLâ�»½y�;7¨·ñUœ(B"Cþ8>H)ð
¤ƒ¿K�6î€
+‰;4 ž�N¾ŸoÀºªÖ
..x«)^
+oó
hhߘሑ ÜÔŽ=¯ÎMíªÐùwºÔ�"î*ü[CDUKާ͛cÑ<¬ç#,¿½ëÚ÷UµŒpÌß#G÷ñ�ŠÐœîT�Ÿ"÷ |¦�©P²2ùÖhÜ°W… Q¸‡üÄH-$`ª Ž‘0-gçâLsœ½;7B².‹{$´ÎÎ�±�F†ŒY0(hþ·�ä
Šb«¾x
+�„Tm†8Œ:Œô€„¬Kƒ>ráB¶<sÖUQùB
ôvŒ„Öm·Õz@xè„ÚT3`�=tm#,ŠZVôVìXu`´ZçÆ%.i8‹	åÐ}[Òì
+Á)oÕã˜}F}“�–ÒëTÌ4/Õ�ÌñS’L((}¢Õ�&TÊ»Öú@�ºçanË^»<„C”HÊÇ
ÄA$ƒÉ~ÒkÆz�–M󨻘�áHáß4[æe^7�Ø&éJßj¼÷2uÛ.“r“;pÂnFCGU`ó`jp«Öõ¹ËŒé›ë·�¿‰ó,ˆÍsà™«Î½x¸Ö&©}J ‘¢ÿ"¦ÒÔ2Ö‚âÿóı	4Š
æF]8xÅç!¼ß �ÞŽé‡ùë·W�»å°k]¶àz}_ÃU»Šq
+
�S¾YîÎ
¡	ŠºÛ�„4ê>À›?‚£Î°r	}ŸDÖ™AŸAÅà
*åqwbµùožÝ­á¶]Á牉ͪ*ž€®×÷eµªóúð˃Ñ#Ž¸éq¹dCß	 (+&L­þˆ`^Á�F;
Ç_ºÏÈslµ)ýäs;ºA‹Ä^„€ª"è RP=F��šv½ºNf: ³ýЉ¼Í‹o¹èF_„C-E×ñ€ð²‹†§_=ª¯mö�å1@ðCyë
yð&åD°ðàã	¶òøq;>_?ªn’ek]×O÷@ó¨Èt±®ª&ˇú=xQÑ…K'tó¨PxÙ
Éc!
+endobj
+1899 0 obj <<
+/Type /Page
+/Contents 1900 0 R
+/Resources 1898 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 1897 0 R
+>> endobj
+1901 0 obj <<
+/D [1899 0 R /XYZ 56.6929 794.5015 null]
+>> endobj
+1902 0 obj <<
+/D [1899 0 R /XYZ 56.6929 449.4646 null]
+>> endobj
+1903 0 obj <<
+/D [1899 0 R /XYZ 56.6929 355.3738 null]
+>> endobj
+1904 0 obj <<
+/D [1899 0 R /XYZ 56.6929 285.1933 null]
+>> endobj
+646 0 obj <<
+/D [1899 0 R /XYZ 56.6929 241.275 null]
+>> endobj
+1905 0 obj <<
+/D [1899 0 R /XYZ 56.6929 202.5209 null]
+>> endobj
+1906 0 obj <<
+/D [1899 0 R /XYZ 56.6929 168.3311 null]
+>> endobj
+1907 0 obj <<
+/D [1899 0 R /XYZ 56.6929 95.2288 null]
+>> endobj
+1898 0 obj <<
+/Font << /F37 747 0 R /F39 863 0 R /F23 682 0 R /F21 658 0 R /F48 885 0 R /F47 879 0 R /F53 962 0 R >>
+/ProcSet [ /PDF /Text ]
+>> endobj
+1910 0 obj <<
+/Length 3181      
+/Filter /FlateDecode
+>>
+stream
+xÚ¥ZK�ã6¾÷¯ðÑ
Ä>%{šd&A›™ÙLX ›ƒÚ’»…Ø’cÉÝéüúTñeI¦ì>ˆ¦Jd©ê«'Å~l¡¡ÂÈEn$Q”©ÅzwC�pï‡æiV�h5¤úöþæÝ÷"_b2ž-î7ƒµ4¡Z³Å}ùëòý—/?}¸ûïíŠ+ºü–Ü®¥ËŸÞúåý¿ÝÜ—[×ïøøõvÅŒÌ%1Št]þüéÃw«ï>úþ‡�Ÿn»ÿñæã}dkÈ:£yúãæ×ß袄7øñ†a´Z¼ÀJ˜1|±»‘J%…3Û›¯7ÿ‰îÚGS¢PB¥yž�gƈQŠ�„¡ÉV>~ýîç»/÷wŸíÛØgNò£‹7„K–YâCS®Wë¶Ù<V�§êLN¹„§�hªCÑWÈT›%<ö?Jùãæê¶q“8³
›ö�`�IAr
+’¡‘…ÄÖœ™Oš’<_Þõ~çÂïöP¹ë±«J7*üÖEäñ¹jêªñOÛ¾:4Àï³²oÝõåP÷+däÃs"´Ì«(j`¡n�ÒdËþ©rì
+3`Wb¬Zã;kâÅTFrɵ§tòr+
¾„Qv;³n‡[¦—U·o›YHˆ$Å•1~Aص?´Û.±³0Df¹§ÃÍ‹¢ªù½zM,4 ”@Óõ€ˆ¸s,×MB:#ÚhæiŠ]UΉ'ã$ç4@îáÕ­úì§É$˜Ž4cõ¼?)vûzË[~OJà5/¥ÇŒT30q¸ÕË£Ÿ{©û'7µ;‹Ò„id·*Rb¡$*  Ý{›€Õ-Æ`í®êÝÄqï&Š„¨rMel¤´ª=çSÁòG¸þs[—ž‡'ÿÚMUù)´ÎY6WDåùˆ/.H¦”òg
v)mòŒHʦ<‚Cv<â !npÄý&DS&ΠèWÞöíc/~¸‡Oâ>ºbT)`±•” wî¼âgë=¿žJ¨gøW:Ç<ÑjH|÷y‹T'\
·4‚¡ùå-QbË¡° b
+fÔxËÖÿ�ï9öíÌg�P˜¤ÎÁ^ö×Àç/4Œ
è¿Á�Ý?Õ�ÛníÜZ&™ó×Y€H�RA<Èø›ì"Ë©ò„IwP2bû]Õ¯ÓÐͳ
vµöL¾<
ßÏÕ!±2b-T�B÷Ú¡]”õ!±þJdšhPÆØ‘½`5-»}µ®Qh¯8n¼<A¬¶£oï>}ðsáæñÞöÀ,s{`Õ¦<ËÚxÁû5Ñ¿Úkð\ó\)gWTωdÑóÍxWªÍ0¤ì™s_ë_ìúÐ÷C
¥ð�²äYvî® Ë‚x«õØ]ÍF6“E&£»¢rYVø¯±h¥Ê¢ÕÎnŠã¶wÖín缬!`5ÕÖ݉³`d·l	ê;9L#3Žp»m_ÒQ^0E´4êª&5A]6îxÎŽ
nYy™@8<WäÕi@@–R^Óœ RK1к`u`°m×ÅÖ
ŸÚÎ;huaÔ´îº9¬¿¶Î|ˆåÒ'Î5äÆ�öh´OÜïçcÓ¤å&¸ãè–Fé.l’§Cy	ªÈ˜¬V:Gî,Ž«liÜD현yÕcRAõPY° MO`}ŸÒâ~ïÒšn»_ÕžwgÊûm±Ž	<èÂú€×|©Cb+¡fÊ&g6*æßé`Q&IÑ7sJE[x´–ƒˆh'Ȩþ¬»Þ%×X»yž©ãyê·sà*�r½–G‚?P#[öâyŽŒ�!t·Á}]á
+yeË@”ØrTƬ^'[~9Ô>
¢6‚£ÔŸÚƒ7„î©ùÁ+ ÝL2§²nÚ—°®òñ3+«ÏtøæœçoYïØ°˜W�bࢴ¼¢š
ÕÕ*«šßßâƒ1´Ìúà‹¼�|ð9sI<ânäƒ1—õ:Ê|‰Ëš9=h\Æ‚£©[+`^B\Øö­¸±;ºz$‹©wá.ÏÅÖvÏ`X¶»¢nN�¤vQþ>àjê‹E+”kZË„Õ%‹Î®Â†fÄè+}©
ÑÐx"‹™ýUÌìÑÔ¦€Áì^îS�æœ)1éEBq?æj¯}_Þb!.Ì Ç;–M;zÁ*Óæ÷	‹¦�¼ñL\«x%1"VH[¨bªÆ³bómÇ
+l¾öîÙÙ¸n—ª¸%ŒÆBû�Ç"¹Ô¡#±�B´ãLŽ
™Ì	@w³0â˜=²\]ÆÑ�jH‘Ê"é�@’!™Ñ@qí.™(¨ü‹ÜEª{#H)ˆ"š²1cL)ìŒÃE-»öhõ¶®Ü´Íáê¸u4eÑnÖi¾ú³Å-’8„â²àŸÚCýWè�f\Øúïy"a)<ìtkˆrâkºW@ÝÎyek½fÆ ðîÝÔÞ¡í¹.+7‘ìô3MD<>zWVÏïü{%Â�f±·j«JXNp–®ñûÃõº²µg8x@þ"�d(Q¼i�9\ÝÎMÕuî­™Î0N¨I�ÚEŸþк@íuÝì�=I¼¥Æc×S#Ón|¦+1!óØÂ�
Iç‘ÈÇ
p9‡J,[s+/
Oyp×ÓIˆõ=ßÉ–'ác85àf'æl�†B´ùeF]Ü‚ÿ¾e3u¸(J7íd««	âŠ¯2Ÿ¦Ú.Ѐ>�©>+—*Ëa
+�(Ó}xɲءhJÛ€ô=µH&:„{V‡¾Sc4ÔÑZLPï[	èÇ|°ÅwŸuhL3ìt\Ét‡Tó-RY‡Ö]-rŠ²<x8§Šœ‹¬Å"眵d‘3âmœLñ Ζw_ܲæN—=Å¥¨È ÞQ¨¢®÷�™ÖÙ4*âê®ûŸ:åœ:圎ã¥}f>^B>D¸ÿ,^úÌŒ°éùþlÚ6md·û‡bý»/F´¥vN
+O—%»Žx“ÇO&^êíÖ-¿/€1HÞ⸵�·•7ÿÞß*JÿÙ‰`¬xzPUÖønÎ+°�ýë0`Š™¯Q4¸M�¿í°TŠh®žyXÖ…a?‹¹wm{Ñðß	k> AÚÀˆµô1ÃÍ.9·/Üg¸A½…õ'»nÚ£u8õzŠ„­GFÍr(àTã7ÇcÌ«¾‹cÄÕ*¯Z]ÉŽDóöˆ,Î�W«,ˆq‡¹*ëS±Ê:c*Ye
¹òVke­6“ó�²<WìJ§Ìpf¦VA¾�ñ°¶ƒö¥±‰7“ýÇi¬à�)Ró6Ì觧¼°C<®ÁÔPu·I¼h®ˆ¢±^wÜ¢"€T><›�Å‹mÞrp²ïÏc1¹§flúm³}�DŸá4õôŒõdÃVåÛaOá í¬ ÚxD—H b‰àÇm	pÑø9ÍÿýiäéPi{µ<�SA%¶Ž,S(*Æò)ëñ#ÊsÞÿFðl“endstream
+endobj
+1909 0 obj <<
+/Type /Page
+/Contents 1910 0 R
+/Resources 1908 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 1897 0 R
+>> endobj
+1911 0 obj <<
+/D [1909 0 R /XYZ 85.0394 794.5015 null]
+>> endobj
+1912 0 obj <<
+/D [1909 0 R /XYZ 85.0394 751.0357 null]
+>> endobj
+1913 0 obj <<
+/D [1909 0 R /XYZ 85.0394 641.026 null]
+>> endobj
+1908 0 obj <<
+/Font << /F37 747 0 R /F21 658 0 R /F23 682 0 R /F39 863 0 R /F55 970 0 R >>
+/ProcSet [ /PDF /Text ]
+>> endobj
+1916 0 obj <<
+/Length 733       
+/Filter /FlateDecode
+>>
+stream
+xÚ¥UßO£@~ç¯à’co³ûˆZ=/Z{¶&&êì‘+‹4Æÿþ†(�.MÚaùæ›™of§Ì§ða¾ÒD[nýØJ¢(Sþºô¨¿�wgë1Ñ
+¤ÛmõÒ»°‘‹„*„íRë<j—­'x9Ú„ ¶§|Ìñw×äZ/Eû-×cÊÔíÒ-ÚëÊÝSÊ7»:m‹Ê}ÃÓ:4ÁÎaPiFA#- %Üø‹‰`FÀô´É]iès”N+�^ñ�‚êà¹.\‹fŠ?MZ>osdvÄbpð®
é"O„ƒFH�]‘@‡\†Æºªë�™ ož+—n3Ñ@b˜�=ÄjëjÛLÄ–¨NØ™`“iÕcþä¯<€Ñ*6mÚæeîÚsn{Åûb°™ÛW|*\Ô1ú‘àŒ0©5H>ŒnG–×í0 x5!¯´DÒ!¸KË<ûT_Kb¸=ôËÉaÔ[{8£3è5ºm03BÆ(—³ÆI.–W__¶Žýž*jà‹
#Ó½P£ûbGh¬a¼™ä„5ÌÔÑùü]mŸTV®hZ¸KU�G×ùSŽ3æÖýÕ¼Äë7Ñxm×Ð3¤'SzDö”T\ºè=6¹Yý¸ºþZ�s×æµË[ÌdùÚÀl5øp\¹¦ªÛbW~¶�!`·D'¶'}Kñ¿wõû’Œ‰0†¿¯áƒí+ÎzHª+Ž1ó!õa«Ìý ˳Øendstream
+endobj
+1915 0 obj <<
+/Type /Page
+/Contents 1916 0 R
+/Resources 1914 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 1897 0 R
+>> endobj
+1917 0 obj <<
+/D [1915 0 R /XYZ 56.6929 794.5015 null]
+>> endobj
+1918 0 obj <<
+/D [1915 0 R /XYZ 56.6929 752.4085 null]
+>> endobj
+1919 0 obj <<
+/D [1915 0 R /XYZ 56.6929 626.6031 null]
+>> endobj
+1920 0 obj <<
+/D [1915 0 R /XYZ 56.6929 566.5511 null]
+>> endobj
+1914 0 obj <<
+/Font << /F37 747 0 R /F21 658 0 R /F23 682 0 R /F48 885 0 R /F39 863 0 R /F47 879 0 R >>
+/ProcSet [ /PDF /Text ]
+>> endobj
+1137 0 obj
+[650 0 R /Fit]
+endobj
+1921 0 obj <<
+/Type /Encoding
+/Differences [ 0 /.notdef 1/dotaccent/fi/fl/fraction/hungarumlaut/Lslash/lslash/ogonek/ring 10/.notdef 11/breve/minus 13/.notdef 14/Zcaron/zcaron/caron/dotlessi/dotlessj/ff/ffi/ffl/notequal/infinity/lessequal/greaterequal/partialdiff/summation/product/pi/grave/quotesingle/space/exclam/quotedbl/numbersign/dollar/percent/ampersand/quoteright/parenleft/parenright/asterisk/plus/comma/hyphen/period/slash/zero/one/two/three/four/five/six/seven/eight/nine/colon/semicolon/less/equal/greater/question/at/A/B/C/D/E/F/G/H/I/J/K/L/M/N/O/P/Q/R/S/T/U/V/W/X/Y/Z/bracketleft/backslash/bracketright/asciicircum/underscore/quoteleft/a/b/c/d/e/f/g/h/i/j/k/l/m/n/o/p/q/r/s/t/u/v/w/x/y/z/braceleft/bar/braceright/asciitilde 127/.notdef 128/Euro/integral/quotesinglbase/florin/quotedblbase/ellipsis/dagger/daggerdbl/circumflex/perthousand/Scaron/guilsinglleft/OE/Omega/radical/approxequal 144/.notdef 147/quotedblleft/quotedblright/bullet/endash/emdash/tilde/trademark/scaron/guilsinglright/oe/Delta/lozenge/Ydieresis 160/.notdef 161/exclamdown/cent/sterling/currency/yen/brokenbar/section/dieresis/copyright/ordfeminine/guillemotleft/logicalnot/hyphen/registered/macron/degree/plusminus/twosuperior/threesuperior/acute/mu/paragraph/periodcentered/cedilla/onesuperior/ordmasculine/guillemotright/onequarter/onehalf/threequarters/questiondown/Agrave/Aacute/Acircumflex/Atilde/Adieresis/Aring/AE/Ccedilla/Egrave/Eacute/Ecircumflex/Edieresis/Igrave/Iacute/Icircumflex/Idieresis/Eth/Ntilde/Ograve/Oacute/Ocircumflex/Otilde/Odieresis/multiply/Oslash/Ugrave/Uacute/Ucircumflex/Udieresis/Yacute/Thorn/germandbls/agrave/aacute/acircumflex/atilde/adieresis/aring/ae/ccedilla/egrave/eacute/ecircumflex/edieresis/igrave/iacute/icircumflex/idieresis/eth/ntilde/ograve/oacute/ocircumflex/otilde/odieresis/divide/oslash/ugrave/uacute/ucircumflex/udieresis/yacute/thorn/ydieresis]
+>> endobj
+1483 0 obj <<
+/Length1 1628
+/Length2 8040
+/Length3 532
+/Length 8905      
+/Filter /FlateDecode
+>>
+stream
+xÚíte\Ôí¶6Ò ˆtÃÐÝÝÝÝ¡Ä000Ì ÝÝÝÝ’‚R"‚´t	ÒÈ‹>ïÞûüž³?�³?½¿w¾Ìÿ^×Z׺î7�¶‡Œ5Ü
+¬‡¹rðpr‹t�´�P(ÐWç�…C­
�f
L9g0ЇÉ]Á¢
+Äü{fXE
+0Üú÷äè¹aÖ�ÃöOÃoäæìüØã?ûÿxýœÿŒ=ì	a.ÌÁAb¡ö™9Y®
Ä£ò/z{x�Âœ*Þè—ÖÁ»2#×Dj,ïêÃ8›ÇEµyÍî;Ýoª²n
öA™ºÓÁß‹(üèX>ã.3v±ms™W`gÅúϨ¯"›
+rn­�êèš—ß¡RŽwð9£_²Ò¹Ð_8=óe4%v>oFÀk(Ù?`LÙ½¼`êú4ð±ûåÃ&9[~ƒ˜;26cLà«|r)Sƒj…×Íl(ßÛ
+b¬Å7ÎßÊçÏVð™h9�Žù,¢I‚°RÊ• e®äß·RÆ%=²ìÙ
êt›œ(†Ì%³LÇ�î)®Ž>1Ù¥‘„µ…^Ñ2¼éˆO£Ý	%õ‰>•pjÕr{2–Âw�Í<–g¬™-j—!3cäáakIè,AŒ$ÁLˆÇÆ‹J¯³nöùU»Ïm›Þ‰D3
+~"ÅVöè=”Žòíí`õ§ï3t;k‡–Bf?õ[¼„Y®¤¾ša£„+gl’ft]ÎB‚²w3ë‹,£ªˆôkêyô’­úÅ>¡ï„móW¯µrÅý¼0Ï”dË#»§BŠ¸ÝUJàžuÕñÆIÍôaòÔã·×¸§™	žL¦€Ädô<­cË-8àÒ—£t‰Äº4ú£|©D„¡¹šŒ]¸ãÏßE¯¡>ÓR·9xyôöŽ[Ìï`º~ͲûDœ¨'ˆº5e[-0GMÓ=KÊÊJþ&â&’PøS¤8ëãin,õ	2PU«r`ZÅÄí¢v8Q—ÁèÍ	×ë¯oã»o[�2ÝO2Ó¾Ðm/Ÿß×Y¿üìvV¹"_=5Ó›é�¶è áaÖ™7þv|g	“y×&"YæЖ(¾+ÐMoûÁ|°>›à¦±vZÎI ÏW´Ä%�^‘›üˆ¯­Ú]Ö%½ZÆÁ_Ï@ÄR�dçÒÄ9è©‚†õ‘kã�C¾¥HzõOlnÕž
ÝÍà™>{óbÙ7U^|ä-)G?
+8òÞ¼x“mì¾%ÿjã=!•š[žž;[#ÆŠ™éJ©/A%Ñv–µû`éióöí؜njP~^z•çQ•7˜¿\扯â	ÈÛ.|âùúÁèéá™
+¸È÷»Œq„z`²\F棖ûEœ!~õT¦¾\Ž'4/ýCîe–7,î9tãÒ¾Â1¦’·IM^y/¢˜kIm;˜¨½}O«•oÐHâ•¡Ç6—]í
7ôh`†J­TÂcweófœkÔ­—ÕRÐÓ(9%�Ö¯c
+Ó·_Ü€¡èüêr_7ýGmÔ&œÐ‰lÞÆŽ
+Kê#�TðÖ†§øñÞ¿šûDE&ñžËœ^QH¶!’Þ»¸>àáÉà̹ç$ÚxþF`Š×Í4IŽ@N@ÒÖ>_9²J¾ÃEúOê
+uÿ'¢µ?s_¯Ð‡öÿŠ˜'u
+BêH—‚?ý
+$O�íœàÅ€DÈ
+¶_O®ð-¡;…®u§uªºXÄ[AŒù××¼^L¹ê=_󱑵ħŠfJ—äÌ;7œ1¾,`_q”�¾´9›Œx•±tþ”
+>C{(�©¼Ê°nwð,K
?EÚ7þBq&‚´”jÉ�¸ˆ�·?è¦ú-ŸCØüƒ%¥uXcýøââBïÅ ´;ÁµÜ3höŬ¶÷Ét(‡„šœì :î´cØ¢>:ƒ‚¯úò‚#ÑǤ_VItSÏ$ëŽ`ø~"ÔܲÜr$ŒU–Y7÷“ø?¢ê¹iâ¯ÉqÅõãÏØ�ISª5ñ4Â…èÑb“EÝêÑÑn
›p³ú†-.ä‰ìošå•Hû~B»ÎÂ�î‚T§Z§Ï_)�©OqÓzèß�÷>ë˜Ê;­dpI¡rr1ÛA
+öÝPî2Pw]¶u¢èúä»(£ý/Ž¾ªˆ§þßÜ¿~&æ[1¸Aé-KžÚEО5JÃ÷.føzßwi°h“bLñB³ß6ˆ
+ÃÐÙ²¶©HÈ 9^©�;¢Ìœp»Ãm%{r7E•�€�ÏŒµÂE±…ʨ*o,„óQÞúʭ䦀(ô$íªy{Çgk9©‘�5Â1ª0Û˜F3ŒÛ!s0¸4XàŠú#r¥Æ2á\8nqå°Ãs}䮀„s–è5)q…i¹
C9ad¼¿`u	
^<‰2@´ÄR­×$âƳ—xº>áÈïž¡wdª‡}Té†×ÎÂËõ€Èøt\1Ü~‚9 ÿ½8iaD9©ì"Ð!gÑßqÝùA“ׯøŠ
+»]‚Ä�ÙªAÓ8ﯙÎd@Iî?_ɽŽbÎJÊ8&1ß’bçy·ÌJü®J_ƒ|¡iïÂC®¡L;¡Æ–=x8"ÆÝù\šGd'—®®ðÖ/B¿ÝÞpRÆ'µsñX'MÂÁd;ŸäÕEûtGmý«†g¾ ¿¨öùWí},¾Ï†Ä›tÓk„fªõžÑ »›&�oô/L¿ÇGìü²•âBZmÎOw݉Úñ¼>–¶ü^ÝvšÉŽHk6Œ´­¶DM0¦›}Öda'¨šßo·é˾xWp¼311ïçdϘ9óÅ­Ô§?¯jò>*§¨¦‰Ð:’-+X}7¿$ÏL\œö¦nD™ðì�¡ÉX˜vWŠñ=mç¡|'M}„ç‹çÄ_’øÏ£÷rci%Åës܃ ¨ÄÏ,n±±ˆ" 5Ù½6ìÉ6úQèÒõmŽ¬öó–à+q®Æ�¾ùÃ$ô|Òî]¾öÒñÕäË&�æèñ²€Õ„KfVº”DfƒŒåZóbúä`#öZ·<Ò_Ç÷-¦�ªÏôª
+_˜lg˜¨Î>«ŠTÂ70¡ðW~—ÛC!<ZüòþÅ#(·�3¨bæ:ߨn¢Œè½Ù$ÞÄ‘Îf;®Ì*=ËnÙ†b…ƒ´ÂVE¼Á<öuBgˆÿׯxî×_ò­Ìz—XˆÖ`©Ö4s�iÝÏAí+<¾ŸãÁE.Q˜ÒQqúÖDõ”ÏÓ$`d�lÚ/BŒñY<xŽ%Á„+{æÔ¢´®³N‡­”TøTõ”V3Tj+"}âžÂr}©Xž\L$ÓÇÈš÷ŽEh®Š-x�ù
+>_ŽÎr¦x‰|„ŠúNx‡<7M–/&×gaÅj[²Ë±‹4—À¤ÀÖO–|¾1_JSw{ðÐıDÃP~�ÜFY­Yy³]ˆ:¬aÔ_|žjÓM+ý­‚0@îhÅtÙl¿Êgšê…µAbDå·�Ôw¿þ}û�YÕ×iîBÕ*jòýZö˦ÏN’FéT/H
n±úÁÖ“4ÑOEìØœz~Ÿ
Þ88‡á ‹w|q£ªšîFªãÆÇ
+TT>/5—䬽%‰”dðqÚnCÃ%Î4Ã
XDmeß:#ƒU¹Ø•l1~à4±GL§%ÕëEЈ®ìÒ\;ãÛ8Å+§êJZdº×d¡K©¡ZÅIŽf3zV#W•c[Û¡*_-�߈¯Þ­—¶5k
ª€º—,ìd¿»Ìë÷S/úò¢×Ž Nâ)uóÒY~	]ßjÑ×Ù˜fšuž²K,tÊ�÷“\'gy¿÷5­<TÏ4CUMà£Æ�gÿ3Q£8Nð²Ã‰ËzN5\/MØr®]�SÝé}pæ§VD@™:]¬ÔË7>1ÌÈéC•'ÛEÆŒ!…Ù7aVì:ASQ×µ{|ãÇj9YÈ4Ö|m Î·*_íw4ø!D1 ñX¿Ù¤X•³ç
+t�‡Í=žÝbóÆÃwî6ß"£“˵?�”JËOP2RÐoQo+†â1)©w†¦ÜèådîI½ÈZ¿VÍ�­(e÷åû È
"QÔüFØs(úF�$'‘qL ®/¶!õÔ
¤HvkÖ‰Œh¼È‰¬ê؉á¶o?Ùa:Šÿ±qêcŒ°gã!_QÇ~ÏWê¡1üaœ¯UÝGmã§Yñmn%ìRãr9÷¬ß0qˆ5†/‚E…(êÚ“�†,W‚˜$Ù½ï¶åçLxËÎÔ|ú奕£w†Z|ÂV€ãž÷,éOd
+ÞyŠGÝ
 ŽÎ¨Ý3lÍ4©¿Î\×T2Zª½Ag—.7Ù#ÏPæï™v¼eŦQLÞ»±Oþ¼Ô\’	¬ÿĵJÅñ¾(š3Ç].Å*,MÎ>ÛBx�(ÃSÃó|D³uû‚Þ¡ï†{:Ò‘Á¨2G9¡Cê{É•<|?�ÒK áéá@F)Ø,êw÷ó?�È ¸¢Ëa„Çh%Ù±o^Œñ{‹6™Ý@¥-«ä%
Å~jÉwXjz1�îi´·î¬%uÕ3^¿±g�¸`d+ÎK[ŽDe—„]âò†Yè�ÖýÇ?Ï>£³HjË,èkѸÍhÔ8Š”™v_Å
[ªJÖ®²9m=·�âú?\‹k>¼à¬‡¤*³Ñ³ž,Y
ê<‹ý¹uÓZ/ZV$S·é#ƒmNOš¨5M@¿§rãÝ0Hõ7¬&7[àçŽAØñêOõƧÈêÚ5±pE6~d»Ž^.x¨T1¬µ¤$£Í7¿ÿ4òÆêüj§‹G1¬èípoóÌ3³QýÐZ:œNÍÆéç,0½‹Š‡Zg‹ðâ£à)‹Q©¯³‹X""œÛÆ0�ÏÁ¾äBvFA‚)Y9(ÎYÖý…ì¬S…|¸Ôü¾“qbæÇN.LÔX§…_�ï‚¿œ%�%½¥åŒìé|°
D>W²7}C–Í#—ZR¸
­$º`bÛGο…a¿9gÝS%\”Á/œîñ�hC|�?s§Ø…šg¯ÎÙÈ)ª¬m}ÐvÖËk†Ÿ.bÉ&O
+üõí+uqfº`Îa‡„°£â,I§ã¯½/‘�˜÷�ÇÝ›Á¤'P6ߢH‚
Ú?÷›½šÙ¹˜Žà9¦ŠmHr7:pMRYŸ#£ 'æW¥¿ðKCß|-¡mWÝ躖nᲶË0–«ÞÐ3äÛÙ=j’
¸Ë-,n–³e±€¢üb½iÙ;‘˜Hâ°l<)žL.ßÐYÖÿ°Ú·)�wL=(‚Œ£± L|�)=å'ÀÆ-Å@²öò¾µ<ÃNrä³6îµEôʃ3±d¶kÓ»¬ÿ‹%ôµøü·(kD~ô(¬_yñ‡Í;¯åä²fùOî{&*‰äyÒ¯9Û�B±T¨d>è.<Sâ¢éX3p7«Á~ª"럽Ÿ“lË´ÍÔDQÿfŒ°Ì
+*s"}Y
;Ò‰¢ú{YÌÝÇí]p¶Òݯ€Ž¶Xo³êÙ}
+endobj
+1484 0 obj <<
+/Type /Font
+/Subtype /Type1
+/Encoding 1921 0 R
+/FirstChar 67
+/LastChar 85
+/Widths 1922 0 R
+/BaseFont /NTJURL+URWPalladioL-Bold-Slant_167
+/FontDescriptor 1482 0 R
+>> endobj
+1482 0 obj <<
+/Ascent 708
+/CapHeight 672
+/Descent -266
+/FontName /NTJURL+URWPalladioL-Bold-Slant_167
+/ItalicAngle -9
+/StemV 123
+/XHeight 471
+/FontBBox [-152 -301 1000 935]
+/Flags 4
+/CharSet (/C/D/E/H/I/O/R/S/T/U)
+/FontFile 1483 0 R
+>> endobj
+1922 0 obj
+[722 833 611 0 0 833 389 0 0 0 0 0 833 0 0 722 611 667 778 ]
+endobj
+1298 0 obj <<
+/Length1 771
+/Length2 1151
+/Length3 532
+/Length 1711      
+/Filter /FlateDecode
+>>
+stream
+xÚíRiTSבª¡¬2©¤j=,Œyn4„„1d%æÞ�[’{éå’2ˆ8PIU–EltÉ(*J…UE (µÄ*¼N¤U„,ŸEªVEÀ©¬««ôgûë­wΟ³¿ý�½¿ó�Íp	
g‰a|ˆc$bC"à/“I!. Î\.�Áð'9‰âX€œDD
+=Àj­ðV
+ÑP5r5Ç(BêÙ@¬Vƒu“7ÒÁ:$!2˜Mƒ 
+l@RPŒÆ™Ô$Å”8¼�amÚÛTB¤S¢€Û”L& DÂ8¦ÖQÒ8kqªBiù'dM/¨U«×Ê5“姜úK^®AÕú߸&MK"�á0B`Ó©ÑÈq2FµšéY))W£
+1–¢F
+W‡‹f/ô¸Unï{»c|š›Bd¿Ìèb
+\ŒïvKósJ‚£¥‘£ŽV8(j¨½ƒªé–H}k\‹Æ»P0X–ï�ZßÉó.†Ò÷0Ö%�¿düºdÇÌ'‰ÏŸ÷>{m ·<Pd¹X8Ÿíî¹ß7ÃÍ}˜ÙÎ¥[_ýÌä+W}q—û÷Ú¬2´iþíÛŸÝ<&1ÂëyN7Ž|æjæÑî‰Æ5{Ëÿ%‹sÿºÉ´;A¢³Æ^Ä>ì¯|øóÅÃ~^R |oò™ˆ›î—jÎW8ÖÌL45V-iš�÷øÍwñq\è5×Nœ0
T;ͺuE÷Ug³øã‹Ž‰<t¿ðú¡$ÒÔ8rØcQ®õÐæ©;Ù÷#–gyþbu.¤6YßéY{Âôý¼e{áˆlVØÞÔc5!5Û4úGÂ9{Ž
+ëBVåÙgŸˆ›¾S–E Î-dãÓåÌ6Æú˵�H»¢Ðç•Él"Ö÷LK+F`ƒÇdz2xg>ZÏ÷JHyÕísxÝÁê¬]<º¹rÑöõ4‘MÏ€�ž&ù´$÷õ–Ñž ­�½¤©=ÞŒÝ=j¼ý}*Ø|ö ½ÖÕ;æ«¥>-ôºóÿ[ÆâÙ+#²¸êX÷BËþ	Ü\©©ubÀNƒ—üä)nfg“Ìñ[égÌÔœfØH2½<QUÅÉìYuÒÃ…\3V)—JO©—[̸=sìq‰óàSbÓ�«Á‚†ò�°ï­ŠÐ¸ÑŠ	ï;]Ú<ÇË#…?�^!SÊ^LJïIž¯ÌÔë:çe6u•.°+×ù³Ü¶œþ(ësÞ§�›,æk¥¡ð7–ªömׯGÙj ÍÑBïÙ‘˜Ž|«ws
+WÓéŸ`†¥ucº}uÁ¥ƒ}Gv\ÌŒ|¿ÀtÇ-ʹTRòÊ26ªn¨Ý²,áOäШh¬7ì¾PYlûa”ÚŸ(�ÈW´ÝJÚ¼zXV×p|—Ívè *»¸knAó¬…;6ýèôhYFxÅ—q>çùQgù}¾s¾u]\¤"ᤜCE’ê)w%=ÁÙÏ|¿{~Ç:`tÉãè3Æ‚烪ÞÓžåÅÒáË�â›­»µ]ê¦ê҂ݲ¹5ëß	²;Ô~YtÕÎ{W{q;ÿ“¶qú2òÅ«ø“Ë�¾Ö'A
݆‡A-k2aìp`»¶·Ñ¡Í—�—'.õ뺾sD•ÔÐq­,ï',2¼�>ÑVµo™Çñi›E,Zͺ÷Á•ØO¿I®Œ�—´$^íù|4l‡à…9‘ÃL,bÉÉUÝüyæ
O2CåWÑkû¹sÑþ_ࢀB�È	×ȉTÚoU팯endstream
+endobj
+1299 0 obj <<
+/Type /Font
+/Subtype /Type1
+/Encoding 1923 0 R
+/FirstChar 60
+/LastChar 62
+/Widths 1924 0 R
+/BaseFont /AUHQZV+CMMI10
+/FontDescriptor 1297 0 R
+>> endobj
+1297 0 obj <<
+/Ascent 694
+/CapHeight 683
+/Descent -194
+/FontName /AUHQZV+CMMI10
+/ItalicAngle -14.04
+/StemV 72
+/XHeight 431
+/FontBBox [-32 -250 1048 750]
+/Flags 4
+/CharSet (/less/greater)
+/FontFile 1298 0 R
+>> endobj
+1924 0 obj
+[778 0 778 ]
+endobj
+1923 0 obj <<
+/Type /Encoding
+/Differences [ 0 /.notdef 60/less 61/.notdef 62/greater 63/.notdef]
+>> endobj
+997 0 obj <<
+/Length1 1608
+/Length2 7939
+/Length3 532
+/Length 8790      
+/Filter /FlateDecode
+>>
+stream
+xÚívgPTݶ-HPPÉIhrM‘œirNlèZº›,Q@¢ 9G%#A2HÎ9ƒäŒd� âC¿{ιõ½óëÞóëÕÛU»j¯9çsÌ9æZµY´tyd K¨"Â
ÍäåЀÙ[:£tÁj<²8pk&`a‘CBÁhÂAŒ†>B!
+ ³‚:  
+uû
€¡
+	sDn³jÉ+þÅmFÿÎ�‚ݺ
ëÛHÂÊùwI|·0·^4怠¡nèß¹,¡
+a%ð21%	]F‘Ñ5 ÿ¼­ˆÕè˜÷Iï}¶ïGD³Obð²hÑ‹ëÒ@ÞÊ¡g7uî“;Ž?×U87zZÈálÍñЃ,Z/&ŽÖìG¬
"\þ|æy„I»†áž‡jKØ&Oø
6V´uÌs¯ï>jDâ~çðerÉö%e>w$ò¶J¨ˆ$k|X‰A\–³³Ëóõû9[GowWgó1Në:
Wz$>‹˜6!k˜¯S:�”‰~‘g„e.0¦ãclKP«>»àÂÌ1yÕ’ ÀdÿS¡Õ¬çn9´éçï©|e>·'ëC‹›f§—ЛÙq€úYšµ«„8ë$f
ÚõSëÁ·RÞoÛ@*¾«ʹAÔguG…*|«eB‰;}ƒv©¢]ùßÖÒï6”�‡yÛ}sx/Gj¢T«$Jñ£•H
âQ–®‹B~RlEÛ1w.ì*Çbr|¬½}$nÖ‡·Gs]> Ã?V1ò�x£+w¿³\õ9’e‡Ð†ŠØ¥ÍäÊv””7œœ¸äN­Ñ÷«/ùŠö.‹ú…&Ð)âá0äPùÝÚ…k¥èé¹éÛR§ö
+^8³÷&sݱ­|&éŸî#6cÕ¯‡‹úœ‚œEë=öÚÊÔïƒ.Œ
}(pÚéc8hXÔêëeM±¸ÄÈpefI­|š
+8xÏŽo‚¹
Lœ¸
+R!ß1Âr<;Þâ
$ûg2³£§Ä¯Cǥs‹©Ï¹å‹E#‡„2‰ó9[ª«eÖb	äBñÇ›;qäë4‹¦y,'�X
È.ó¹^Ûû¾çm}l3S@+'éY“W[ZTç¤a�y þR#ÁWeôùì¯w<Ààø!ËêHô‘ªÝ°a2Y'ŸxVc[ЃÖ̺«P‘�|m÷L¨3X´•¢|FSp	õ6!wˆ¥qi­ÍÖ)/)y4ž^ÉdÏ—“¦'»À+Oð+Wë³Ã�/HŽõ°8³:̨%¾0€°nô™¦RºNSX)šÄ©wo¸Vá"n®¡U®�uë.ýe‡°ƒ5­†�âÁ„v0äÓ=Ì­²Ðµ”ž²­ÔÂtwï‡tKy…‰	ö€À›Á²Ãí/hÆnfÔÛYÏß35|\Ã)͹b€½^s$�QÛ<.'DÑ
+(^‹òp߬h7š” ~Ý¢ñí‚…Ë.^,°�‰ðzÈî§D€×û3ÊZú’|JRA.KÞ&[å�/0õî¼2³–ÛOy«ó�CúÒB«e€öžt‹:¹ïäCA2µÅËV‘ÀP½'Ûz”êÅŒ~,ÁÑ’ØAkQè
+
Çö7=s`[šzþáÞ•M�åME÷¿€uG–h‰+÷ÜKI•9º¶Z¶ý3h#`+]¥J¢æ·šõ¬¥¸¦4G‹Æä5ÍɦŸñ
¨/„~
2…°ëIš%ƒR*µÈ¹ï¥‚CSž[çm•&ê�,œ^ˆ®ül™ò‰0¼3F£!âù2°gáȺÝYzñ‚Ä^˜X@°æ¨Í›#díQ�¿¸ ˜ßÈ?'ty…Š,ÿˆbx_¸Âæ••ÌDC«½¬}�F0j|{¯Õ\þ˜ßsžù¬—}8$QŒáinúAµ$o<½öR•eµ#�"Uòe¥rÞ‰KÿñÃ=Û`GS"“H®bʘ#6W?³æ—å‰ÖÎ+ëíø ·¯ô–-ÝI{ˆQe
Y:BøÂb¢÷‘>:_/!€ÐéË@íáÞÑȬýu¢‡3èµ+òLn¯óqŠq`Uúm�ò'ÄaeG-
+óŠW¯C鶰€®ô
+„©ÊìiÝÇ.h™³
6'�¢È6
+VÍŠ2Û71sz8o+VPÚ^­M£õ‚¨‰J®ÆÕe/ýéœGÎ>Î
+òÎqE„¹¯øç*+nû…Æ—²;OeŸöY:«*š“ïgœò'\Ý7"µkûl‡ÉqèËÑÌ'ð9‘Tgeix¿qVV^­ÐÅnOiêlÄ&Àh1ÿ¥n†	Šo-R’È!î±~x“ýè‘·ÞøyoÏõÏ4íÙ{¦Å\4X²‰¤÷•�Ï´±ÝÈ/å�µ½¸N%{’;4u)Ç!‹=íè¡ç"Â3¬¶Ðœ�š®`¬õ<xö¡Øà
+ 1±#-@ëÓóÄ<ì¾âæ©)[‰Ø“9QuC—̨é-ûFæÉ€?›ëþYû|96£àj’òÖåUNºnî…XÓ°‰Ä·ÏGÑÅk'uÁêFd×É>0¼f»åæ6ç-#vƒl|¯göÕšŽù�í:qÄÔyN¿3-y„¨Å–UÇâ${Læ6¬ÆÚRøÉ™¼ó¥?"áZ¾þþË\øQ>È”	§{õîû7l]
+™mÜtW?e‡ÌŠØÇRXÝŸ¶«
qÐNøb%2t)(	æß-Ö§9¢A¸‰�Éš2žŠŸ±;Njf:¯ƒ9NÃïÊœT)š…ùïš=l“'v!V‚»ú7?êÑš\“Äk=ò†º¦ù^š-2~ë‰Uïs‘.»o¨ËªüaMfsÍ%W2b+¯ø¾
+(Ì°?ø6|Kú‘œ™µÁ86<6zlDÌ)®VésF¢¹¦GfôZ¸èøJü
P!Hl�Æ<¼H›8ºîeg©õ/¶D-¾ú‰¤÷ ã›UêYœqáÕ±ÇøË
+*�Ïp›Â¤AwÓ'v•ù7Vš4¶¨ž+jÙÚN9dB<o¬L©oÝÌ#%páÔn³òäAH41ס
tö.	Zm½0ë¼r˜$‰®XrJJ&¼è
¢—Ë™¯`¾eM¹»3µ¤¯û_ê÷ðö�}d½)(A=À_D‰ÔôÛòbN¿Ø}® ÆÿÄ5,¢Ó�c9A7!ô{•K*J^ŸÀ~™j'÷%U­YÜ{ñ•Ý‡å]ä"Lžïxiå2¬Ž/�ï�b…U¸ƒjå×)4§"ò§ªÓ
+?Uôü¬Ë÷
+žä²�5Äõv!.[7$›\ÉÌù ö)%Ü-DÇ9øÓ\¯äͯø7F Oâ×ÏžÅÚÅ8i“£òÅf&\†

+-â×6™…ÈXÓØø,ï¾ÆÇ„Ék}YÆ
ð”êA±<‘‹?qâoYêL�Áoȯü¸"‚˜‰œñµŠýVw$€ÇÞ5-M¶Ãú&š{ŸQ}2Ñ»5ãùáö¶xĽuéBÿ;¤»¥ªïÕ\rþhüæx¿Í?‚^iºÇ&‹	ÕCžËQµ
b\¸THüe%¤¼®QÕ�E²üO¥}¿:y´ÀJ ÛAHù åP¤-´á€[kN�Ô/ˆ<Í©ÁEÁ‹zHÃ('¿8/ÖÈ><ï·NZN,±$�íŽÝ\ë|.ʳ�4
+Úu&IFlµPÈ‹˜<>ê¼çO}ö•>ݧ·ðgžF±;YuQTˆ §ÿ�æ‡	¬ßôtD¤ûfP˜{s“cÞ·+J�	.>xi¾’²È¦{¹3Åš®Þ~—ÛãŒd@ãa‚äÄ·Ž„kï887Kp¥ôRXŠCãóÑ°áTîEQæü^w~@³ßG±¸½Kë3rÎN¡À�K’jùÚ
+}~ÏLcÄçt>í	ÔN$c÷¬¤úœ ú=nÆ©ngþõžåÆIE^ÕÖŠ
+!dÌFæö/¨˜õpŽI^ø©Ý©²‰µ([|«F�v/f»H/>_!üËê¹ocG¥%ÅÉs5“•ŽnÇ5¾Z‚ÏÝŸ¤±ðJ©ýšžÇÝ\UËúö¡
î[Ÿ2Êíß2û²Qx„úûs‘½¯Ø«PU XäxŠnO
+IÇ�äœ÷îÍóÍè	v ó4ýð
CihTðÞ�²° ÇÒf%’2Ž
+Oyâ|g܇;Òðh¬Ù#1|éôë6Ög²›œ·UëáÇ	rk_‹öw€º«¹j!:/œ*¼È_Ô¦¶S+³�(#>û­pKÕs%ìÛø“hj£ê·ßN
+\O–ˆuõ–.½½h8¤Ëµ[%-n&í—o{Ø,OJ‹ä k ƒ$4Œsz!¼¢‡bÃ7Ú‡vçˆemÝÊ5Hcý™’W¤uÊT�ãO³‰³7	�†³Ê;B¥È†“ŸÌõáõý"¡dËUŒtúÀóñ[í¹0!Ã<Ú—(U½›È>ä9íÁ;˜Ö€7¤ÊÞ­:À¤Õ²y£7À­ÔÁT}I”C¶–�‘Qîì¹È\·ÞWõ3›Ã½ZÆ™&ÝhÄlÊÞK\o`~~çt!•†ó(à'¤§tq	Y†¶�bëÑ4r3ÛDZëòa[ö_ó>(ÁÔE7	bO;8�<0�¹8Ô4;Õª>*ËVëu?+«h–H½~šq»x/·}$ãºÊá+¡V8|ýƒ!Ù‘`Ç©³Mò×ÎàåÇøQÝ'ï³eò^JYõžâ7:¯?¾kñs”ÛqWç®fa Š’Œý4>§ ÇZ'úy]Ü;_GdRÁú	È•†bn¥æf§çƒ\Qù²1³7›
+3ú·<Ȉ›h¥=¯`·�C-ãZ*¾•‘Û3ØJ`+>…p˜;w	cÁ¿ù\å�µdf؆:îÉVÂÊ£QÏ
+Ló¶Ú±{iC¤üD8þú�ñ7.4ß=£Nƒ~ØA�·™Y¼ŸíQíì
+;dÕÚÞùYÌú.�ëÅ3¬m
+Œ·Ò'OܧZM•�ÈkÚEä»óÔAøV¿F+áÖØ\7H”ÕÁ¬–ÞÙ‹s±
+A7µ¢¿�ï?å151"yU�F�„I×íòÏfwÊ*Q�;1WG¬ä‡üÖWG9
+dòú“¢Ï¡ã6–±hò¶þ|áç RÖ/?‚jïVÈttf=]«­mîXCh-»E²`?|(“躃Øçw¹©”]“RÉÆè·¸¿½ú‚[O÷^Üä'^m[ñ™4]aÄ‘þÖ9ö5QºÄ”ÔbcÅ‘
n"¾ÿ]½GF&<ç
¤3dRµ°%‘	”Ê.Óµ­ÉÂÆWòQmw)‡GÒDa™e¹ÔÖl�NA|¦Z–ýÒ½‹Lýƒ÷ÛE}b\ÝîL» &épƒ·gr[‹÷šßžz÷ìòdÈÄº‚íüë£-«‡Z‹ÎîpnöŒ´Ð|˨)	2xqô¦S=w¶Æß
jIž6a›�6Ä.OSy]ÆñþS§oa¶Ô«ˆÌ±â£Š51r»%ob2üpȈEÐ&â§ÜÈÕöIòÊp¤ì‚è¯ôV²í­NæçiX¯Ô²»Íæá‡A$­Ñe$D{òD¾Ÿû‡‡';,Ög¦•k\�Ü Gái3¼q¸Qþ¥L�
+Xæ"¢Úbò3¸ý]ub7¾‚夨õù-ÅsÅK>ˆ<–!!’=j‰Á
bê÷](åÏi·t9ù
+KÆ.Ha½+-Ε[å�òÿÑÒñx Ciif|-i�s \‹¦ÿ€|�6±m¦ÍñŠ =“1ä`K^!y9ÊÌßIjX÷žXHO~ûLýì«œÈF7v—")òï@µW™[zb™®ÕÚ4“*ý÷L´ªŽœ0–¯z$¹Š/‚„à{>UiO³ýE©²5êæ÷”t¦=Ä;î
+€¯À4?œt€sTeù›!4J%h¹‰¸—ŽQÏ:µ¿yÓ´(kY¸³½M>X‹–
sôqÀirÐÀ³8!ÂùÕÏS€¤Sì$óÅ­$R÷Ñ•amPÍ$?çÔg•ËŸ˜V�d[ƒ�1ËiÇO°<Ø_¥¶%y�ÐœáZ�.›eˆô¤Xþ*Iò{()õŠ_¼¾êW÷ºÛ£x}kã¾ããVÔ³Ö–I͵'EÜöGi‚õÂV;áåÏ¿Ø×6™+Ý$É�ž	{ýTö"1Ðœä5v-V$ÍlÂÞ¯«ª›
bݦ´³ã)º§ÊoS6”hLGñ…îÇ,v%¹u©I~®]%¾)Ñ}ú‚¸2¸ âoJ°]^¯ÿRÓ HmØ;Âúž
+8>Ô
+²©
+3ã½+ôÞÊ•÷�aˆlª Ïn×–OBw:ëÌDöƒ^ቃ€¸Rn¹šd¢¯ÅÓò;SÓtd®ÌA~zM“èRVt}õÚ+'˜	†4~}µ÷°}³íÚš[T:áµ%|Å’Q"èXê³ÚÎÝ9"áòç0Tw�³È‹d·¿Pô@åÉ@ÅìÓEâòxOæî¹Ã	åÏIXUb_4²üQ
¨:ù©^\õ47ãÇU¸µ&�²ð�c
óŒA«`á0Ôýµ˜—™žÌ‘¥ˆß·%¢y†.Sz¾M²hàž·ãý°óg
#$SÿçÅOÁëÏàBø[yã¦5åž Šq(OÜâƒL
#‘'Þ/ãØ«*ûü©¯ð5X1œæ)ol×Ós[2L&³d´/øÿ—ÁÿøÀ
+#Ñ{0ÒŽàÿ
+endobj
+998 0 obj <<
+/Type /Font
+/Subtype /Type1
+/Encoding 1921 0 R
+/FirstChar 36
+/LastChar 121
+/Widths 1925 0 R
+/BaseFont /MTTJYO+NimbusSanL-Bold
+/FontDescriptor 996 0 R
+>> endobj
+996 0 obj <<
+/Ascent 722
+/CapHeight 722
+/Descent -217
+/FontName /MTTJYO+NimbusSanL-Bold
+/ItalicAngle 0
+/StemV 141
+/XHeight 532
+/FontBBox [-173 -307 1003 949]
+/Flags 4
+/CharSet (/dollar/hyphen/semicolon/C/D/E/F/G/I/L/N/O/R/T/U/Y/a/c/d/e/f/g/h/i/l/m/n/o/p/q/r/s/t/u/w/y)
+/FontFile 997 0 R
+>> endobj
+1925 0 obj
+[556 0 0 0 0 0 0 0 0 333 0 0 0 0 0 0 0 0 0 0 0 0 0 333 0 0 0 0 0 0 0 722 722 667 611 778 0 278 0 0 611 0 722 778 0 0 722 0 611 722 0 0 0 667 0 0 0 0 0 0 0 556 0 556 611 556 333 611 611 278 0 0 278 889 611 611 611 611 389 556 333 611 0 778 0 556 ]
+endobj
+994 0 obj <<
+/Length1 1166
+/Length2 8264
+/Length3 544
+/Length 9079      
+/Filter /FlateDecode
+>>
+stream
+xÚízUX\[Ö-4�Á½p'hpw×*(¤€*Ü!‚»înÁ]ƒ»kÜÝ/çôºoŸîûtßîw«öZcÌ=æœcÍýíz(*r%U&3[ÐG[¨+3� 
+në3Áù
+|ØGè´£ÇÀNâ¨Ð×	éÛb®=R‡äEÚTBbCøª
¶DÞ¤W:›[öŠ¨$dEY%Š[Ót¼/oü¥¬½”ùP'û[Ä�–~�	X2­µc×42:Xµ{—%ÍøFSÓ]¢8œÞ“
’˜•G&$ÚÜ|-C­l7…�à›ò~»,Nv}»Æî,@HíŒÅfMè\ƒ•jLw~˜,r
ÿMüF]_©
+ýÍ8¶öOáÏoëÓ‚úïLîÓ¼¿œ+è¶kÎ6ÙA
Ý$=43Žºoô°Jü¨rOwVsr¶Ê¬ðšz¾Ž~ÿ²ºþëÁ‹êËõ-!蔄Wd=R9‹ò”l:VŽhÔïÀ³¼Lô
Ãaìtþ8QIVæy
U&Á¡û�«ü\žj_E‘{<ó�éYàôDËæúløa½ê£D–Îîç„xô�?¹é$Ì|’"Xûü"rø—Xu[ÊÚ6·èNâ÷�AŒ»®qmƒ½É�ý¢¹Hx7žMxÃ
_Õ[±½z
+¼*K«™Zú¹úÕ°×Wý¢Øø¹.ÔR¯�æESúLkéDÐ?«áäv%.
+šI-b´zŸŒU íÑ—þDÅyMß\…‹ÙCó«ïÓÖSätRR˜…$ùÛˆFy/Áê}äYeOÈZñ¸ÕÏ«¥¬øïc}͹ü<	ÂåŠ^úRX¿T[ÅgÝñF/yo\ky“Wb“Ë·Ú{že”Ã_¥b1‰¯ç(17•®LsT/“ks¸àýÄR–Ê8à׆h0ƒÄcsâð]€¡í"Z°p¬Ì¥`ÓTÚÕ¼��V£ˆ™×Þš¥”¾Îé;»WžÄi%(¶ØÄ5œ™,—»ì>N*�Yƒ?åïyÚóíʈfüλ�»²ɽø7ãáFWqÊZS>M…ùdT„Ǫ;£Qס3˱_‹§ÙL_¥Ÿ€(U}Üh-²CöF;5œ}ó�.T²¶/0žyÖ]±!3f\CÕ1�WR|#¯o‚Ǧ?}Fq?¯Óf�Ï ‰²¾
RŒ2Á	œðäÞ"#
+hŠÚ?åðP‘­�||èuæsSQ2¨•PbHRóŠêÐ8ꎜ¹MS^MýÜÝ´Ó›û¶ÈnØU´]IÜl(óš–ªÉô˜ÔpXò,Î%0Œ1µky„Òæ®qú§°Ä	ßÉ`hˆ	Y›½	goû[rð`jϾªN¸tÇ\®»–ü»bIBj¬÷¯Âµ^‘•H�Ý{”é·ÄÞê
+Ô
+¸'º]÷ñ@f̼ÀÜGgìdô—éËùêÛðFÔ!k£«Ã*.$|™/mßFàŽùyAO&—2Ö…Õªõ¾1Ù«<Žø+vˆý–­Dce�”­µEx`Iµ5úÐçK:™¢¦ïÝO�Ütó‡ž.erƧbÛ,H/«äíuåí™RrŠò–WW“OF3³gÃ)‡¬Då"\ßžâj��èßÓ”võVسïuÔt2C
«Æh]W*é„g̯%ä"‡È@Šr¤Bqf„�•4†Fóó<ÐP+]°¹Ng…8à„q/•ãȼ¹b–Òdù&Ê´ºdVNšùÞÕç6bÎN�é?ï…çPÒZWïn›�vÊ
+bší‘v\aۺΤ:×}¸½ø�Ú"¤#"tl~–ŠÂó5‚ws¬@ö|KéêyÏ’4%Óù|ô}É=ƒ-RK¨Ö{Öˆ“¤‹xwwa@­â©Ûæí‰ûÂŽKˆ0�oýwËŠµºÕ6©M8�³q¡ºïˆoâ³·àßYF¤i{#ØHjî˜/„†HP,9;]D»¢ôc¢bÓ*ÃzøüÆísüe¹ÔÊâ°?»ÔÎTùw}ãΗÊâÜšTÆýjy¡<w¹ï…ʼOŽ  âéMÉwï¿ÆUQ8øx¬È¬¿àñÆ3…}ð^ëaÑÄà|Ý’¯¼~¢Zw�(í
+kA,Èž¼ÃR*(^?�X5ðÙä,|í0&æ)q��¡3�5QýQ�”>1(`ãóŸ©3;çó~•�…jffl¯©È{>ë²SÕ†¬[ZÆ€ñí^m5
+îlúôü4 
}
+¸iÛ¬[
+AEÂiæ·Ü¾^Ápš¡¶²S�‹q”)ä—®}ÀÈ™’X¦‘Ñê	½ž¹I|&åYöd§œçI»Á~hÜ%i}ºZùñf�ǤXÂx,¯ðçÝÀŠÆTÀ;=ÝJi×î^‡É¦Öèz,€h?R9Ìó;@Öÿj—þY) Ƀp9:•Iß­¸ù�G«
+gwoÔЇ¼V}ŽCsg@ˆÑÕ†šÒm
^©‰iÙ;4
+ú‹�®fºÐ61^Ô˜±õƒøåiBž•1•ƒ—ÛÉŽ¸ïõ+üèªicöe	3+âòÖÛ'˜–ÍN¥ê“�7ðÉi˜ì§ï´½~2¤bêó²ãò½õþ•`×Êê¯áÞØC?¹ÕÔÌ=u¤ÛˆU¸…Í"â#øŽ\f�£N2ú
+wŸè’¡µ¸§¶”¬Õ¾Ï®HÁ=ˆÒT“³šÌ6X’>�3¡6º­1•üVŽ mjƒ3/7¯=Íôþ
&!nIy<<QDð"'É[nt”;D[sZæZÿÄŽ¥¾v™•8`±ÝÆfF—ÚsÔ|¯ï7G 9Î+
�?Iæ†]KkÛdìÓ½çÓô+(–¶ÿ5ß(äþCT°‚\ÚŸ§l±npOhÃíÜ@tþ¹�3´6PäUi·�QñGŸð*íwõÌx¿©1)mvj"§f6¦F0±ÎýèªêµÌY™i	õÞK÷òUQNÉ
g_;;C4‹±o­%bTèŠÍ†d^âFG
ÐÛk—W·>`e%aŠ{ƒ#0SÌ=²\:×Ñòz¤ØGàU%˜YM�çËá.žÜ�Ã_bÔõ~¬›Öw�ŸXöçÏ×�{7¨‡¬MÅ6ê£BÊæz‘×´‡ïÝpä÷¹QØì‡G2n2ªDö.×hE#£“	Z½¼Y‘ñ&ÐëE
\(ÃES¥cùlgK„ŽT@â91D±èc™×Àj…¤�Ði�ÞÚDÅëÁ»ÂЯ0Tµµ£bÅ$㪌íéyÑdö¸Ì
„ý�n&¢›\ ‹Hè^¶ÙôX\JÆÇH?!Ê
+F‘PÖçhé!ÍFµù„複ì‚4�ãE¢Q¢ªÈŒêË¿$Æ£}IÅD0I>àÅlPól&ÕFXÞáÅâ‹×Ž^ì÷êÑ!W‹ é·qV`ç¥Óz"!׌_j¯Ñò«E’µeä—QúŸŠGÌå«P•['ïkÈôZðÛ5%K…š�†Â¸ª¾àÛ㼿°è/©äGZ­�Ö¸µ²¤Ë›w� f§þĺ#7^•Ÿ?<Žàa¶Úñ9"	ç*‹æz]à•Öˆ·Ñôv–ý £-ÉTqÿ.åó%‚8Þkeÿ3¿[M£6ò¢@Gò‰ƒXúÞ¥çˆS&2ØŸjF[fzØ.½„ø'eCL`KI
+g.£Êù5õ\Ïc¯ªO]ffå,§m¾¼@+¬—q[¹ ,<¸¡ÎIPŸ©if8§”MIe({—Jœ~À$:­`š‘-éé;±‘¬y~�`²ŸâÑjr+Ö-±˜…>IEƒf�çl±¢ZV­®ô
ÛûUM½5
ßOÇRòˆœ�N@Èd£èF_ó³òÌu³Gö–l0êYiQ¶ˆrœÔÑeY$î9Ù
q+SÊbÁ9+²ÀYƒŒá—)mdA(Å”µˆm;ÞUÓ
ŠÊˆm-Œ/=ŠÉ?ˆ)CHÙrS¶Ô-“×ìª0Kƒk}öW­jõ‰9‡ý@F#iÍKû½D;¦$*µ±¯ˆ:vÍuš
+ ¢6G4ÚWó�÷mq£Mo’¾íü0zt™žà[ΛÙóïÄ3ÕÝZsÆÈP:dVÔ/fyŨV�³Œ§²·ÞŽ%ŸðG5¤ÆA«ÀÞ«§hÏ}Kœ¤=ª4¢a3¨˜– xMPn”ªÇ#qp´ų́çxk lƒ<¶ä¥ùÁãÊ¿�aLÆòË+&ç0q�wl$^dnÜðy(ÙBÓ¶ûo‘#@¹×M±®@S#8±CjQðç}
ékŠ»*lí,¡�µ=êï�Θexí¬„¢h‹®•ëö¥°gЇ™N¬/U
tùM-w*Û¼¿<ý\ɽ~,($ۥDzÁÏ5dèrР®Êº=¸’+•"‹~tó%Ê�"â…,iãä,
+û
+àÑè.šoÏx­g6åëÚ†ÇËVDU±N…;ZÆÒ5oùOhú­—Ð>IîÌ:h^�$¼Ôlz×ÚÁÓT	@ÿ}&YƒHõEŒ(=‹qåö6õÙ¨ôW=wš’xsDs‰¼:ŒëöÊ-¶¿{´1öFi”"}±FêÃLf_ÜÅÅ;FO5æøþ|y~U¦Î ‡ëÄCš�¢Õ„’+ê´Èø–u{Ó&d¹¿*¯’E牊ô‡Mâ‰t/&%Ï©H6ÛÒ¥Š‡¬GJ×:Ìøö•¿ÒÒ•ß:–”eˆº	—ýq«É(LdOÅ"^$·u1§&j¶ÀZ¬
+Ú=;ˆðá:ØÓÏäÁÏ/én¼¡,*¢`\ÜäK}["ÊHTÆÞˆo`ÝÙýz„N¢&j¸'µ2ó‹|K×c6Qén)'	üÖœëv?.ßüê´–®PÌ£§åZ]GOŸIªvIbŒµ³ÉЄH\Ô‡óÉ}vÆé¾°å1ù{'¾ógâ݇ûmœ‡½*œ‰VákÑJÃÙ9ÿ¾�<§µÈ
i¥ßg
CL⦇X
±rX¯=Gó‹Ûìö.BÒÓ	oû~o‡´~8:_ª˜WzåHTº{‚,×d?u-ôR,ýá²ÍþcQk®‰î•üâŒ'ÄݹQì�ª¡³¾§�Æç‰g\&ÚQ„#J©Yð#Õ²á[ƒ�ËEßE(@˵¸x†üœ³/ö®:g]!$…US	](%v¨	åÑÜ팼`‰jî&^Ûœ?-ó@öùàjÙ÷<³ï�lY?XRr$Š™£-ÑTù†~ŠÇ/0‰ÌB¯7Ù×ìYSB{@&A^UEs	$DH@
+٦ϭÓ%"Òð9Ó
+-ý¸Bç
hµ0ÊnnL¿ñE~„éMÇv¡“LYd< gñÕ¾ìQ±í�Å EþoÉ|Ľ„\cvê´
+Y	

É4j"¼ÒÜçÞ»6ð¯ø»(~7qBËb“½L*&=¤ö4P'©ð·@Xáѧ†÷§€R§ ÙiîÌ#k]3§&M<~èêÆŽ¬y×–=¶÷.Ö}ìh�"rr
²Ë«À±æ<³$wt•°CnEÕ@�¸*ùwN.߆Z r™LŽ:øõŒªOâTãPêŽ".!ÉMù?dð<Ÿ½h·Õð¯=B­›B]	oº×dûJèoÛ°Æ°­TFØQêP¢úC@qSÁÅùÖ÷¥7_±�¸Ôˆ²»ÞÌ3å�³_Ž¾«š’ñ #¼Ì‚�
¸~sOsÔ|ùƱ-J?§>8�_@1.æXIg5ßRic¹Rc
+endobj
+995 0 obj <<
+/Type /Font
+/Subtype /Type1
+/Encoding 1921 0 R
+/FirstChar 2
+/LastChar 151
+/Widths 1926 0 R
+/BaseFont /DHCAHC+NimbusSanL-Regu
+/FontDescriptor 993 0 R
+>> endobj
+993 0 obj <<
+/Ascent 712
+/CapHeight 712
+/Descent -213
+/FontName /DHCAHC+NimbusSanL-Regu
+/ItalicAngle 0
+/StemV 85
+/XHeight 523
+/FontBBox [-174 -285 1001 953]
+/Flags 4
+/CharSet (/fi/quoteright/parenleft/parenright/comma/hyphen/period/zero/one/two/three/five/eight/nine/semicolon/A/B/C/D/F/I/L/N/O/P/R/S/T/U/Y/quoteleft/a/b/c/d/e/f/g/h/i/j/k/l/m/n/o/p/q/r/s/t/u/v/w/x/y/z/quotedblright/emdash)
+/FontFile 994 0 R
+>> endobj
+1926 0 obj
+[500 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 222 333 333 0 0 278 333 278 0 556 556 556 556 0 556 0 0 556 556 0 278 0 0 0 0 0 667 667 722 722 0 611 0 0 278 0 0 556 0 722 778 667 0 722 667 611 722 0 0 0 667 0 0 0 0 0 0 222 556 556 500 556 556 278 556 556 222 222 500 222 833 556 556 556 556 333 500 278 556 500 722 500 500 500 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 333 0 0 1000 ]
+endobj
+969 0 obj <<
+/Length1 1624
+/Length2 8351
+/Length3 532
+/Length 9216      
+/Filter /FlateDecode
+>>
+stream
+xÚíweT›ë¶.R´¸;A‹»Cq-î‡ H!P¼x‘Bq)-îîPZ(VÜÝݵ-íº{ï3ÖÝ¿ÎÙ¿î¸#ß;Ÿ9Ÿ©ï_˜è´t9el Ö E(ÎÉËÅ#Ð
+‚l
+°…Â
+qòØ€l1¹5 ðG—
+úhÄÃó7LÏt„ü.¿à_bó÷Øõ'rn
cE…*ìÿn·þÑÔzœ
¸ž—ðܪCmþyøÍ#+õøp
+ñ8ù„E
+â6/ÄN;0|ës2©¶òÄXˆÇ`kmH[Ǽà*õp+?ýä†5€Á#/€ˆñÚǘRóŽ¸
¯� *ÿ€9a÷æúÙ—þ¯½=�g(Ÿ6)Ù³Þa0‰{<ÁfŽ
+pÍ¢”2Ö/õ‰`”TèÄjš 3L¿àƒíá!ŠH»  �s…?VLãT‘¹Jˆ&‰g: ÉÒѧLy‰À¸Šge0å+÷&|ÂýÀê~sóTšù‡²©ttÔRmñIëëd°9:6+¶@›ÿ䧗%«ŠA~ªÎA	ý¨£±bíè0�TóYòs¢1…Ðg{Ü™ü_8X—Áx!Öy4´Ê3æmü,qÕ¡Fôž¸Uœ1”=Ê™gÊ™gÆȲüwâEÉw#A¯�òøJàú•BþS›•¤ònë®”{w‘?ßW#·TæJZ…å˜>}‡Ñ•ÁJJù‹�”ºŠÑäÊj¿¸°[f"­u¬x^Ø( HHŠ}Q¡‚ßaŽRz8Œ¶¦µ“;jÇÐ:šÈƒÏó%^�%QÓ±¬­v˜iŒ¼Æ¤|hÉÊUq”J÷¹ù»Ìã:aẖ²Åà2]½Rô¶°÷\xT;
µ7L4T3FÁ°.ÌkÛ4ä»Ïuä‰qÑÅÓÅŠ ›c´ã¨�ˆ“Ÿ¾Ú:‰Á˃NG!òç»EŽfµ4ƒvZi•M–Þc’þÆXÓ"Ã-­íêÆáP‡³ÕÌ$’_?Nˆyéå…ÓÕ½mÞ+à„_½‘sãÙ’I%pazÏl›€ÿ¶uçU«
�·\Û×Ðbjêìb>U¸)}{QŸNßà—¨ªw%=Ák±ä�fZ%Åêos[1øÉ]·êñZ¬w¹­fsƒ\û¾cx‰¾¾‰ŽµMÌ(}–"Ú\ñ|1wNkõTƒh,.Wèçh7)m|°Íü'gˆ5’S¯ŠJ2ÇM<'s�Ö+±UÇR·¬§ëÁµ&I"AkËðÖíƒÜ�c»Êþª'ºø®¾bÒ^XÛÒV¶ãž‹c&jžüõ«{Aî.5ûÛd
+Ž{âA‚ݧL3bü
J?ÙnÁ›C#ŒGÖ:ÂûSÅŸ†¸XJ½·5^9%4•Õó’‚Ò¨î_Zúäu¼AÁ�Ü݇€,23sËÛZÉzÎgIÞf­35TìQ›Ã_
?Ôn¹)-ödÙ­¤!á-æÔ‡$J›½Àzö‚õ˜»‹Š)Nü‹:¸¶’{ý[}ð|ͯÍ*Úe™à€\‡v,­�:j±ªÖÙH’R<[ݧ¹}I¡ÊíÐRò
´hst4ý¯3¥{Þë—àe¶A¥ÆÈ)f!ÁîÎÈW
n];FuéÅTK&|Õ‹æ¾\c…GîàèE9#½‘lý¤z‡X,¾t8íèëàvO¿šåj›@’ò»²·1Z1–ÈÈWc7Ü^q7÷õÛHm®#Í4š‹9.<�qÆ–7]Ï>é"घ»Ž;ʆW=™PNïÞmMj§%·™Gô(àØ/õ�]-÷'?E4œ¥ºŸê��ЗBáNI�V}f…×–Ÿý•‰ÓBýó®aˈ
+ÝìËI–Ø+¥®kª+…k{p¶MÍÍ$]Lj&”?M(ìzŽh¾ÏöÄÝá�6è g*⪈}Æôš.lÄÕÉ^wïkæXÏ7eKxvù»‡ù5QÁ°Ç•Ê.ܥ˯ŒZKòQóÂsÅhã˜\«l>[êßÝ“Ñ"bÇ
+idguÊ ÛáÜ‚Ñ9¤ëË‘'jM.~×ÿfêKÃÔŸ’ SêkÉ'ë,Fèø.JìíÜÎXѶ%Ænvâš’¤¼ò\¤ëVù¹r>guΆɩ,hè‡ÓbѤÏ_9¶¯Ë`ÔT•#ÅW}gƒ|³f<×­ð8²ÿ5È âõm`cÚ—}çêã[ÿoöþ-ΣÆgLÊôµF&Žzê_Ùºœ['Xæ tqu“G.¢/­bŸºâi$g¿Ð ÿ
+#ÄÎÝSDº“l
¹ügTù®„B'æ|pÙž2SXÁÖ=‹ç~õÎK–DÛ+Ïk¢·­ÀICÇCÜ0SApðäcZ:³ísž÷½Z÷•âKíÀDÙl”osúòÖ'+˜EŒ;�úØÏb]RN;-¿Œº(·]({5ׄX’³øö÷ô~™Ÿ=ÇŒpy¾7�rB>Ý#ÛÁr{Yƒ©3ßrƒlšê¼õ~±Y¬Ø)Õ`qyûT±ŸIJ\^Òº2¶5ù¶…Œ�¨ÆÙ½C+âa¹ÜmyüÊ€=YÙGzm’ÕŸ>ÖÃI)ª~•¢•¾·wZ䥗Q�yyŒRÂf�ff8û“‚
+¸ÜÏ„e) ªÔ5‡Ðz}Í=1¶à‡v‰ÓG<˜'}îpÂ/òʨ^ärÁÍ)¤ƒÇ¼V²YYÍsSsôaÛA ŽPWôÔ/U®øGÎ8G”„X×ö¥ïôgd” ŸŸËÀ¿ÚrsŸc¡W8DN0|’t&sõ™9©~ }Y%ÛZˆÝñ4Ã@hÁwKÇÊ0º7ñ¤‡>–"OhIåà"5àÊtþ]ÛŸe»ÝÁ†UyåÞå¼ë\_¹j†œO"	o‰¾é~iŒµb�âÔwyu«�•¾Ö:
+ÓEWº?Kûß“IœñáÕtÍ{�Be-ë	
Uu£tië9ÙVåøë_onw®YH°íy‚Þ|˯©KâÉ'zÙuLÔ‚™I…¾?Cfà.mQn%¥Ÿ•I\zQ[°³D]Yí7öT¬$&+ázªŠÜ^„§P•àÇ´ômÖSXS„α¿çd±³Á¡Y>RêÑ™½²†ò…*Ÿ~ûzr”4�6:bŒ*Ç´H]ÅúÉêXË—P/f	Îëîw¸ÑV%.Ð-HÙ¤œùÍØÁ°�ù¦µŸÏ™¿Ï³Ú/€V>ÖG—ç™~]I§ÐRúå”ù5ÝÙo<…zÅ•—Ã!rÀÜC)4ÜKÿªdÞÌ5YG¨Ò!ŠU�a	dV¦Ä`ȆՃ¶å|þFĹšÆ�#\XZ­•c…–exÍØ⻫‹
+ðŠâÅI´ÁAM8îe¹åÌ4+Ÿ`,NÍ|
+‘†“u
+jT­C©i–Tu#s¥§Ú'¨jzÇ¢’‡‘]ž>û	�Ó›ã�é4�ý}AB1ö‰pvs!œÀZý¶Ù0¸øÖ5=YÙ‘Õ®¨=×`«²Š©«åU:�¯
+$¨éå,3£¨{Q¾Qê�5¨§6µh¸‰Üüß<ü‡ŸP1[½;džF�oU—%÷UÒÞ�,²Éš5Vo1
+=JƒË¬À<2Í¢îÿ¸£»|µºÂmïÝa²‡kv¼@ˆw÷ÎÖý¢AŸyÆ«ïÌ�vÒDYœ32²
+©òc¦Y+«Æ€�§Qùsýò:ŽrM£ÅÈ*iÀ· Kö �î0ÐÇkø�Ä<æçó|;€^QÞâÝ@�öE<YÍ4Ë.8XÉË@¶ÞIǽL» ïk[¯irWÏE/f؇jÈ)Rà�Xý¯œvb~ƒ�ŸCL?;Yt^8+¾ç/*7í2êì)É=fIï#!½öôžcháîÌÃ{ØV°#ré\šùˆ58»ƒ¬«1Éz—xÝ…È®ÊÖ¡@Ñüâ—¿GÈvÄ­ð*†b>�
+ăڙ~»À?(Ç«Ì_aè3µœÌÀq•Ò·'ZÍMÈòqZ£¹§ËSÅv8à‚¼Ô
[=Ä2
MV*ÇE¸ì¬Ömpx†“‘ò°Œ¢Ç¸
+4a¯ã§À!¾Â2J	’¯Ôc2Ä»îú£	GЙÓØQö(„ªž0ôéÊ ÕZÅÅ`¹‰ÞÍ>QqÜY·TÓlFrÙ9Ä>‚$s™|
+cúÝå�99¯ vµI÷ðJÐ?½›ÉÇÎlâ—2ãÁ¯Ú÷ýŒ€%Í4ïÚ�]zôMy\U¯_éCùÅ‘Oað�áׯ™Im>�jzX <Pû0[:?Ñú"§¤ùñ’¤\H)Ìn®ö£d©ü��N_ºmíDÕã?³íÙÑÎ*–=ï;Ü�RO†vhÁnOxŸŒ={ƒ³{oà¢
;ËùNÅZϧ&ˆœ–#)¶[>P’·ž¿Á©Øô©:Ïûô.)¿¨h^iyˆpdÎ<öL#ÑÆ¥{¨Òܺ¾E¨ózÛ'¦îIÐÔñ`Ï�õ®±G‘
+F¸lqF÷wã!
ïlgVc8Agbf–FLD¿¦x9Š|s ý5þ�i.ñ½5ò.–so–¾¨ìû4§e5<eÑ”7t>CÚ±CŠH›zrŒøòx³÷ÛÅ»+Vˆ-j¼pÎén
J™m–›Ñ�s°pЭ@úEƒsFÚ-V^@6êI]§gIëEJ‚J[eƒÏ%K\ñ¸\%kÕבÊ}½Ï±ª·—´Æs‡2ßwýÕk“Òhý€×U%'ˆW(“ûh?œGØâˆÏlíä7+#ÐÖO'›Þÿ²ºéúÅç78' K*ûTâàÃF\Úÿq$qƒqê¦tMŠ+éM4Îâ§7·!…
û9B²cr˜xÔ©*ÑEö�¬!ü¯¹Š	G_á¹É³Ìkñ¹ïEãA	GþHŸ#ÑÙfÓT¼äû<û˜}!gÆÁ¥�¬…X
Wϲlq*¿ˆé©°MWfüp]ýÕST”i;Çéyù>.¯Gxf�œÕÛ[$«LTmç¨m–fîîe¬¢¦§P*†tÑ5[=ÑTQ3<“)uk¥}²ùbâŽ4¯w
+E,˜µ´´&¾Þ6º„¢ï¨Í$¹°Á�Ü<ÊÅ|˜oÏLŽ8ßx'%ì-ià_~±úáÚuY߉•ü]��<ócÉÞ„Ä�:g}ä­A™l=iÜ’Ù›Añþèuúéצ<Û­O˜àmæ5 ÜT…ò‘êÕkjÕ‹IG	¦X%
-úú\¶qŸt§D	Љ64>–_Ú�Òâ[Nlòí3«KRÁp²–Âb]ÌJ—^»6m4×Ë'rÕÏ"d^D�›y!!o<¥fN�¸È%�PZQ¯÷nœ•7Je( æ%.ÜÆÐFœ—Q� 	Ú›v¢î*ï&Q�_Ç1éÇ»OµMí÷S]Ðê—âO
+,öŠú"Erq‰3×{1NÛZ2ú

©ôeeE?qx
+‡N$ÝE¾ã!Nz(Ý}Xn×ü½aב´˜S€¯q=!ÆUwŽÛ-ÁWá‚}Ø\dæ”�Qf¨ÛÁsZY THƒ-´/â«Î-k×ÖôïÒÉRZ¤™2ûx°.��[ÿªt8HÕ«XE¥2‡U-äbO¶’g×Vs�£I5üŒõ¤JÒ´Ù¼ëâ#LAôfvñͳýn™ÖM6H·Þî�,ÙŒšípŸBIN"±Š…:2 íÀlÇV=+èw9fš ÷˜±ÁÕ"ÙÛ½�ìøù<´ÓÇ™R]Y4B²,LˆéIL׶—=™ùôÜ3BÍ]²'ÿÔ¨ ’]döŽ
+ÝݦDJ)ÙŒáÉ¡fl°«Sa¬c€²cý×Øh}ë
–7‘:©„ÑÅeƒ+"Ï	^Œæ?õl^}âï.<œEÖöþÒë’QzM‚iDÓÂÂLTª¬õºÒk=mùP©ú'·UŒ´/€›0òû
+ä–“Tf0kˆ¯¨éÞ6¡"¸FÂéq$îDY7Ê�ôµíª‡æ¢_Ä+ùXDLI¨#%ò8ß[
”:¨ËA|�’z,¯
+ø¿BówÚ]ŒßxÅ®ªÙÒš›
+r
ÒÛdê9ñb÷Cæ½óG„á·|9]°Qˆí3ˆ¥8ö•'|2
jK¢´”6¾Y¦·ü–ū؆Mì{"¶¶¤~lú…W²ÌÅ£¥ZI¼ýÇCLTb¼Ø¨�ñÉ®-üGOdfEæ—ôk'Ì,³q½Š°ÊšBa›=As_|û¢Õå|šEñ	¦Ùá`uͶ‰:ïp0nÚ”Û+•¥`¯|,_
+Q^	±ëkB˶ÉÝÏW)´XI6°,}¥¬>Ñ­
+ff|óéæîDÈ[(-’°1MXü’µÌǨæ¹Ð1½æÄCÍ`SN¡‡ÒÅ�»ïaÏB±³7,PÄ�_ˆ•Žp�²Ï‰çó×CG®t¹=6Jøwº�‡P×±f×öËÌŸ õò–ÙÍ�·¿)—UôÑþN¶Õ2¤C.®;—ÿÔvcƒ‹&çî¼Ð›íø¡¢ ?’!sÛ	yvØ·�ïœÒÎkYiÌç
hbÏ0¾IDê.¶Y_^¤+<@<«Nk¿±eopô³…+¥ºêhC‹0�Hó³�c�ŒÆÜHf
Õ»uÎTÉ"[1ò™8ÍQ áMBšHiô*ó]ƽ¨Y©ipá8i­Þñó°žÇª<FßèÍNa¼�°ã¹Q[£ðbd
Yfwp“—µ©Â·{äBŽT.‡)çN¨5# Ü\8£
¦oåc—j9^ÐbYHËoùIà3Ò"¾œ½OÒU›7œëí
Ú£xÖ°´ =|MÆË•’ë�é÷\Êã®›½›ÊLs(iï*{–2w}À ‚Sq¤”œz¬4XBc°ˆ/­ù
šNߧ}‹ÆO"¼¸ò^µ¯Å•m¹•÷h„‰rd,ŒÛà½ûJtF ˆÛÑ�W¤\ʯ¡q—�9-1;Š’‡Vû·U¢“Äç

+	a¤)•Y°žeDÿ­ö‡Ú—«~‰ÕofØB8ûzIÅ‹‹—�ç"ç6ZŠõæï?|ÙÊËûêÞVÓjˆóý ª¾$ù…è¾™A_%ãè
+½=7c…ÙG¬èÎ35µmªâÊÉmqZ†\B‘[›¸46ÊÎõÉé1‹äp#T‹ÀY̼†Ü¼²µ8c1@Ìõb$ýZÃ>ËA‡ýÿ Z*9/‹[ qM%ÛZîÔ3Ÿ"Å÷OÙýklT¢HFk�mºYüéA3—¾OpkÄ·\;±©ô‰ãìµêOX.š²ÃÙZ|©9K>�ø��
+[L-‘×_ÎlrÉÁ~Õ?·åSç& ‰Å¬}+ž¾†¸WfÊ5na­¸À®ª|êkS=öê[¢8ˆžºÐ(ú°Oæ*ÔØ…ª\LêÊ°_PÄê:‚܆Ÿ0
+o¶d©W<DÐ?§|)"¶úšzœ8…û>r‘ÓÕ$EŠÚÜÍyÆokjÄÀ”*€Ò¤'ñË']Çåú®8šŸªBžß%[Ž1FôõU~zË7†Ÿ¿Ñ&¤”D·=.Eå°¹úiˆH×
|v`—þ/õ«”WÕw°õ‚I ¾ª@+a®ó(©±ãA5¡=y=£­ñxç>USåD»<çÆÍMU�Ô›€ÙlE—û†wRŽ{ÞÉíkGo-îçDq±¯R®¾…ù ¤í€‹p¼ìoB:04B»Ëß
*pº¤¯O*=¾oFäÉ°�ïCÀIüŠkú$ÛÆ�ò
wLv'
+�OêX¡gŠÛm9#Êó2Ôq
+ÓRLvÏÍŒÆ/Ï7Xy!r8Ë!MÔ4ócKv&½›Ä4á”UO-EyÂTóT­âÑÕì}3Þ5ªV¡H·>”œ³"M*�œjnøÏ3°ï|Ú÷×’4²�{óÝéL¬!àW”¬Pfœ«ÙýFGó¼Õ‰}j™jì»�“íRÜAñÓ5Ý«rà)vw º'-¢ßGrËpnvÙ1AÛõ ·ºó\<užèÃbð‡ÖhQ�jÄcñž­Š:DqŽz,|¸>1sNñ&b®]?Mr)smWÅ€Ñûä
ÌuQØÉ
+�aàùÚîjäßÜš¨SÞ‚{ÈTvø…ùî)x“›”Vˆc†šçùÁüÿÿO
+æˆù_Â:ÐEendstream
+endobj
+970 0 obj <<
+/Type /Font
+/Subtype /Type1
+/Encoding 1921 0 R
+/FirstChar 35
+/LastChar 122
+/Widths 1927 0 R
+/BaseFont /NZFEJI+NimbusMonL-BoldObli
+/FontDescriptor 968 0 R
+>> endobj
+968 0 obj <<
+/Ascent 624
+/CapHeight 552
+/Descent -126
+/FontName /NZFEJI+NimbusMonL-BoldObli
+/ItalicAngle -12
+/StemV 103
+/XHeight 439
+/FontBBox [-61 -278 840 871]
+/Flags 4
+/CharSet (/numbersign/hyphen/period/a/b/c/d/e/f/g/h/i/j/k/l/m/n/o/p/r/s/t/u/v/w/y/z)
+/FontFile 969 0 R
+>> endobj
+1927 0 obj
+[600 0 0 0 0 0 0 0 0 0 600 600 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 0 600 600 600 600 600 600 0 600 600 ]
+endobj
+961 0 obj <<
+/Length1 1630
+/Length2 10420
+/Length3 532
+/Length 11286     
+/Filter /FlateDecode
+>>
+stream
+xÚíteTœí’-î\›à.ÁÝÜ]h ‘Æww—à.!$@ð Á=¸[p· Á!—|ßœ9³Î�_3ç×]·×z{½Oíª]UÏ®·è¨Õ4Ù$-ÍArŽ(;§@ì`îæªìQbÓ
+rrq|ñpxÁ^ÈÔ]¡®.`'(à%«šŒÜßuBm€Ð?¹]Á/0ÀÑêÅÓÒÑÂíOKa/4/(†¸  OèŸ\æ €%ØÕÉèõ’û…ÌÉüWn®`ˆõ?+`¸€¬�.–ö Wךî?·óÏ>
ÿ¥{ ““½×_ÑŽyýg
`¨+ÈÞŠ�‹û%§ô%·5‚ÆñgXä!VŽ
+:€í½þ›ÀuÔý]ìðý+,¾\Š$ÄúE6.nvοÍ`W9°'ÈR
µ°
X
í_îì/»6Ääb†€^´ýëZ_‚89ÿÓ²
[ØAþˆÀû7‚Xþkù/rýU<‡¦–š†”Ë·aÿòT{™¨–—ðit•-ÿóð‡GJÊÑàÃÆÇ`ã~Ãàçç
pqùý7ÿ¢áúçYu
{9Ù99¹
+Ì;ƒ�„öé ÓBr?¦®"ÜUúV~–�`“rÌÌ#ÝXŸ³¥5>N���ïê&e�Hc­o\PÎn˜iÜ‹ñi¯�°ü-Þ×&´áÔÃàÕѧìß\3ô
ô÷uœ#vm“±ä% Ò	»#`ÒÇ:瑉hWúD±lÁ}Ù¡ŠïJÎçâY�ÊÝ¥…ŽeÌ|,PwÐÖºàóoËóÍQä‡/Kk×ØC)3ù•kKКM,y]íÝ»IWàCn‹ÿ³ÑžŸEbg¬BY¶â	EœÞïýoÕÍ%¢_¹
p¿ž²Ÿ¬?BûZ·bŒ“ˆ·d*RˆÈÕÝÆø÷@÷¯¾òðgŸoÒÙÌ2ô!í¤Øô‡~‰±ùÁpÕ}ØK³ç¸ûC׫F%=ʾü+Þxè7§Á½€Ö
+µå7„ùŸ{D/kÅ:NŠº3©1fæÁª®ÖÌ>›ˆ0œÊ-~ýdžR¨X<™6Ú4’ÑzVÆ�„öO”ðµaÕ=åƒd!?Õ–¦.OB)»OÞ8
:eõ4 ±ÎÌYÉzM—I[Øù\ó‰i·Ó¯‡‚¶j×ÍX�‰õ­æ�áBJ÷[ØE¾RS×ß½c&È1Om+bi¬NÈŸ
+"¿¹V6Õ›dJ VOÆýräªÕpê9�£åLV±Bï÷Õ&JÀà»<ëÈdRs΄5Ãc6âš<ZˆÚ½–‘õxc~Œð
+7kXp-ºZc¤ë·8*Ÿ�Ѷ•â–Ÿ÷µÓ÷“hØ4WžL^ñ¶AÞež
"<ÍyÅgWõxÅÇõo)l)ºÍ¨øß*—–£ÉÌ™üÑõ�Ê”ÒtM
+Y4<z€¶TÙ±š�m·àÇ™y„>þ=ó×½Ó#|õ‰2Ìu÷Ñà	7$tD;³Ì/>ä…¦+²Ø˜±%œýD@X;…�1OžK(„ØfAH̦Ê"m…
`²­èF5óRX¯.èÝÀ1_|qãŸ2
+òâ¸ÚqÍ\ó°aTúËî3ìlŸBØ0UmËç:<¢Lµp.«ŒHa>7÷ ¡$é
$aLŽW*æ—ôZÇÝ�ඔ‚ª�Öß.«UŸHeYê¦äñ4’5¡ö|Ž¥�òïm´ÑË­çŠß“Trו?äÖÏä‹wJf�–h÷3»7P¸bF»`œ/[ŸLÏ�>¿¦td#ø5‡ÍPÝ®gÊ|Ô«ÕCY�…#4WÚ*€¿0Z^oÖ,�F±ãƒiôŽ¬÷“Ön4
‘EMI;h!ŸQ5r²©äÂÏ †uVrŒyq ò…f~I�ØA¼þ8«+ö}¤&ØõÃu"ažyº-¡Íß*�Ã
ɹü#Líj)¸|›t¿Wu‹ü4°s!MRmYŒ5 0ÉWýŽƒýÝGiÅGÝD¥å²VŽ>5ºöæw&‚ß3F\Ü~'²Ý»µIËO™ù™õ�¯âÑG÷4•ÌËX¥+© ¬ŠD¾I_åhkˆÀ/ÀŠr2ûHïíæ÷¹Õè9D¾ÏÔK1Íœõ.ÂÖf:¥©_ˆú™4LT™M7(¥o3iså—ò»ºö½_ÚC'¿{drmcN~µG§;ÝÚq´	ÓCLs:l
‚DFLS¤ÁrÚ'»H<uw0¥ÞHÞúµ�ȘlN–D˜•’Æ·+¿Éþ7Tš2|ß=›OG~vu1b4ršTªgŒÌœÊ²ŸŠÀ_|Ž‹lÕ‡—0ûº“8_VÏ»×ö“ý#ò°R—¢“Ë-{z—ú{±Šöý‡�9¦/Ú‹]¨mȨõÖ?2T8¯f
5°Ï9[X©Ûß>íÚG�tH”ÁòaÀÉ©ZʼÎ÷h96åË—¤õÆ3ψ%6Ë�px�¢OÚe.OSåÐœ©<³Œ)˾F‹´®7}Ë”#)_Z¥¢Ê
+7ÂÃD
R	‚¿è±¡~HYÑ+RÝ,=Ä-*Òÿ‚´-°?MVC˜$™œiĵ5˜Ãù–…Z¶a8W‘OYE«Pj5úïNhŸüˆ×K�ÈÜœƒ[—ÝËŒ�ÇÓ]ûʲj
+eÕÔ×Ì:8}L¸Õ÷aÈN˜üŠûÔªÌéjb¾ú©;¯·»ñÐA¨1ÆE“¦{øc”’³l
+¶§£âŠîZ<3ýrãrö, ˜ú¡ü´sÛ£¦üÇçt
™-’,ÊÁš2šv^I4{|ãfg£!Æ-’ßÏ
+l	,vßgª[™GV©SÓÄu rbðW„_±}\7Œ]KöÜÏŸŸ=8RÄC&)Ãù13S³à™ÜˆzÖó&Ü{Òâ®;›{ºw/L=®¹>Î�i%Â+06wIœ¢¸/óÆ1qx≓–^½Û‚ŸVæø
aF©kH£ ¸p”6œB¨EAb¶¼4�ƒ"Ògå#ß–ß]ßÙ¬’ÛžâÀÓÇQ´ÝKçãëA”œ˜jô¾ð‚p?Ѓú'[yõ|#—Qb9rȾÃFNw®Å^™Ý~¹6”Ô™ÓEŠïá�bä߬í#Áæ#ÚWŒ¯*È
•:ëè$4×hÔË×öÂnD¹ïÜšÇS×¢FD¸}¸ÐXë�Ï�I¢U1Øθ3o8ú8J)u£e<Ô…Þóh|¬"=–gfíÎ1`[u˜ÅQAØÇyïóÎp%oZ
’øqa’…aÜýËC5¿‘ˆó^ÐŒ�
+ûôÐÓ]2Žá×ðÂŽk•|½Ç7�X>ëŸ�¾·Ù(´Í¾o÷ŸÔÌJmˆ•oXGUç²7w&¿#
+)FkcøÖ¥Ó‰]Í¥D¢ØM�Ðò÷*Óç”t…f�¼™�¡øÜÏÛÏF�f�ðz•¬ŒÊ�2�Î`®&qTYOý“ê9JÇÎNy…ï´Ûöpì¯lbúÐ8
Á©æf*°©Ç	6Äê••í-Î
�¡€Ñ„š_`-{F”šZ…ü‡
LAîP«Ç. :öIæñhž;³»)ÓZ\ÿ/FÉH£}QôùLÊÏ+w5]D0|ƒÆ&ÄWŽ^„IU5lª	rôÒ>0„“•¶}
+ê(O“ùRtS63ZÞ0CFv߲ͳZ
+|C·r®ÿµ?Øô¼©F¨$	@¯ÍrjB/áH
$�=@"¿ƒ£
+€�ñLœ #Ž|DøÓú$LP÷f(.€RC¿7é@
+ÿ³±Ž“ˆ¸*„e³VtØø®Ï`Áz)£`j|S’»§²×¨?È4·¼-ó5W¾”8˜‰¨WÑ÷ÒhòµÈ~à&JY�È)
0­ê¶D©:Ç4Á¬Ãšž“<Á$ ŽFô!uæýÔK~Smò¡z­2
;zëJŠfÕiu°„j–ó¼ÍÏ�}ÃGL0tW’e³Þ‚å»0\èœCå™xà¶}½©âV<=Xey
s¯”òLV²º3#†–¡ØNs‡Nɶ¢»H*åÀ›õ³?ò
+/RBùðMÍÚËW?Fóm6¡Iyþ%ÓYµšÕ¥oÅ{;sË2¯�Ó†{®G ‹LãžRê
��ú AƒíI+23—(-ãAqpå—Zâãö¥‰u#̸{OÿÌ€;Snú�äë)ªj¶§×o°O'Iª™›ßá蜼“Ñ;ö~Yå�	¦<úhDsÙ˜´\ÎCldS \“2ñœIsd„­|ü0"eq’×dÛÑ
+ÉÈصM"-!J$Th ¸þ`1/ù†ñ\âîô­ÜTQ‡ÐŒÈ[ÖNåÝW…ˆãíñò	Φ·9íïCÆ?öaô|ºé´Ó2gz µÚ|펋0T§ÃL�Òº2ÖËàÃÍÄEßþ:–@A,™Š`k­ûúm«§”G6Š+Š9gÃÀº‚r~I÷�Où­è·DÊ¢[{­‚¯´rÁ\CPÉ#†|m\¶}äh;¢µ…ÿ´fB­Ã0=­7ÍRô‡/œÀÐÀÝÔk¢1fR´^¤ÛºÙCñ®Çäß>0c(¤‚e(Ö.×ÈîJêùô
+Q9!™¨‘™y0‹½zÞ½iº˜^Ì	/D—Ó|e�æèù>JB»!|A¿,S`&ǽï.÷L5�ü±ï÷÷ˆCXæç
ÞŽ¬
å©aÜó‡Û
/}WRèŠ"µ±gÚѾ­ø�ÿ;.¾‹œ2Q‹)3–+À#'[¼„ì×jéXÜö¤ê
áEIkÀò YBUµ<ÀòÝÉÛ‹QË¢Ÿ¹Ù¨ƒ-*
+HŠ‰³ÝÒ¶X´2l‰ÀëRC/ýÕwÆY@}!ù~ƒvÖ³K®×YËE.®\ØÍ,Å»ÕB
j>š…¢«îlô~â†õàØü-³er@ÜYŒÖäž��îj«ýT"ŠÒãÛ¨×KÜð%ì_í[~«¶¬ƒxRåøž&'q.kýØ®ƒ”ÞÑ‘ccšÀs1\ÖEÔõŠbº<&zò¹d£}‘l—¾¢@ ¢¯uR$î-±ÌM
+ñ,(ZÃ
�…G!½½,‹8yKæ;~ã)_Çzá8´‹öÑÊXÐ/â&_5º(Ƀ|s5š)ˆÒá+>úÏ°c²±
lj×ú²ˆ%¯ñQ
eÃü²†‚w¾ÙÁÜUú7|Þ–ýö‹ç4Ï‘³·¾hB²’Œh'à¨]NåD¡·�T±TÎ$nñõ½Cm¼:1
S’•ÄéEÔ¨“¯Q/nHb�ç A(¯öÌ'rÀ/V±¼.p:F‹	Ö“»aûÏÕwïl0yß]Žˆ”.z2“ÖŸ~ÝÊü”— ³z^¢ä&Ÿ›ÚÕ_BXÌ].ùÞ,y4DñÓY=õN[“ou1~KM“éýeülÝQЃ$¾®QJÖ\â3¢¼ÛÚ7²_ÞU2æ°(²89j¢è‘X(ÍàRêôâ
+ïÝåJÂYsD,~ ‹�j%ûÏ.Ÿ(gªbç7ú[(�
[7™>"Ä«1íKIkJ°rÚ(t~¨,{|�†�xáï�Ò…CWá�
§­›ƒpK¾}AµþÖoX4šÝØœÙ5�)köa³Š
Göf�eÌƦ¦»#%ÝÅM'zŠX³¸·®ËÂV‹ïÞ,]0.Ù�ìëî9¡ß‡'¼Ó+}ÅNw§s»çoXçð:
¥r•Çu’Ÿ¨óUºÊ‡˜Bsûî�sŽ1ðô]¸ÑÊágE>èé6±:ËÖªbCÀÙ‘Pý\rËÿñfóªÙL[1Ë@í×õˆL
+Æý¾> X¿ ãŒ0ÛÙêpµ~è~ñnrÆÀ�f·*zW–Wµ8ÁˆåX�“7`i
vXìq|¹*ÚÓÝ;É}…ºÛKå×B@ÅSCÂHØ�jIúœº3NøÎOm‡êuHÎ&¯õHì{�ÃN�Iv-%ó2þb*BÁÁˆµ.Ú¿�ÉË(-0ÆÃ.™
�bÉJßÒú×קínjiF^Aƒ½x”®8¤á-	…Ž!�
`ܯ¥	LÑËëû.íS@&Ÿ$ 1~G„¡é!nó[‡:sHæÏÄzŠê÷ ÜP�ÒõöoaÇ�"Û£]¡{;XÎ	Fb
úzÛçŽw¯ëö
+v{Â~[ Y퉷kë[ÊF.Ëë®R2:|µ&˶ù&~t±³íšá–kAYÆ-Ò’Qíç^Ü—³AÆPR˜R†ŸAÅ%®’+Âã9ÔR´¹«{ Ó’!ŒUW2i÷ø¹ó›
oO7BÁ._«¬ëyŠ
D(aá]k~®u–	®
Ý‘»ÌF%ïýÐ×�ÙÐdf»qÅ£ˆ=#ã j)Š¸)…ào}Ú|(¤»ó$5÷)ê:×eÝ–\KÒ|ý`S';ZU©Ü
+Ÿü._¯	7#° ôcö›ÐB¥×¢fÜÈ=�°ŽÏÚÜÙê?½z��êý0íCÊ‘!´æûtÍç«1žu?K+.®o–/þRi†-zSÇ6ÊüdrhŽtFš(eL³‚/umDðN”Vï}º3,RÖŽXí;
m?´oZ92íã“Á‚?†}æ]*ý|ðÊI¡¯W•’­Ké6¤,È5ßsx˜ ™ßV$$öøu"ÛºîŒw£¸Ô
+endobj
+962 0 obj <<
+/Type /Font
+/Subtype /Type1
+/Encoding 1921 0 R
+/FirstChar 34
+/LastChar 122
+/Widths 1928 0 R
+/BaseFont /STPRBR+NimbusMonL-ReguObli
+/FontDescriptor 960 0 R
+>> endobj
+960 0 obj <<
+/Ascent 625
+/CapHeight 557
+/Descent -147
+/FontName /STPRBR+NimbusMonL-ReguObli
+/ItalicAngle -12
+/StemV 43
+/XHeight 426
+/FontBBox [-61 -237 774 811]
+/Flags 4
+/CharSet (/quotedbl/numbersign/parenleft/parenright/plus/hyphen/period/colon/B/C/D/F/N/O/R/T/bracketleft/bracketright/a/b/c/d/e/f/g/h/i/j/k/l/m/n/o/p/q/r/s/t/u/v/w/x/y/z)
+/FontFile 961 0 R
+>> endobj
+1928 0 obj
+[600 600 0 0 0 0 600 600 0 600 0 600 600 0 0 0 0 0 0 0 0 0 0 0 600 0 0 0 0 0 0 0 600 600 600 0 600 0 0 0 0 0 0 0 600 600 0 0 600 0 600 0 0 0 0 0 0 600 0 600 0 0 0 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 ]
+endobj
+884 0 obj <<
+/Length1 1606
+/Length2 16237
+/Length3 532
+/Length 17113     
+/Filter /FlateDecode
+>>
+stream
+xÚ¬¶ct§_Ó%œ¤cÛøŶmÛ¶mÛ¶�Ží¤£N:¶mÛvòöÿ¾gæ™u¿óiæùp­u�ª:»vÕ®sÖ!%TP¦4±72³·s¡e¤càÈYÚ¹:ËÚÛÉÐ
+ÙÛ˜
+"bÿæébaèòOngË¿n€½ÙßH{c×Jú—ï/Ì_¯‹¡¥�3ÀÅÔÃåŸ\F¦
+IŒ‡1†
+	í:Œ}V
+T§:jâV6ðë>z1ZVª=à
šì™ÓvÓFÑÐ54½ú!§�¶å9A6P0ð®+MG¼bê¢Y‘ßçGa�ƒæ¶ËV­c3çY?â!_¸Ù
þZk
+ÍdÖC÷Á1Ðò“#MH}:²ad†ßêÆ“5½F•çJgbqà&§¾ù4ãèØHûù”ƒyÆ<˜^ÙÎ/ÓnÉçË,³t?P“©†œê!(‡n'¼|HøúøÁ“fQ"Žë3ã²ø½6<‚QÇ?#^vyì„Q!³P¶9aíˆPJM”–Õý´ø5mœ
+�ÄGìÏÌOÍ!ö®p¥æh-	
Ìp	d‘ÕÌê0Å‘N\dǬþsÐòa[” ##ŽW”å$�‘ŒªàãFAžiXã»â�Ï4ÃÂÕüàm÷àÚ(3Ÿ)qŒ_0\¨�pZ
#rûº\ÊF/�¿«·¹Wë08÷nQ±¬,RjU‡"vÈ—7ùB7ôy¯GJfô[ˆì¥/·“ÂC
+†ØŒÌHÜ—�`¢o(8äÉJàÕª££ðèÚ>¡YÒ{§žæ¾òfƒ†/’€môú¤»AËý`˜
+q;w¾æûD"'š0@=÷a#èQÏ÷ç«î³¿k^G6ÊP ó'9TʤŽ!è§ËéסT;éîŠjè¦~C
OÃúHm~Ë.!H!§[8=f÷‹âƒ|ÝtÛ²��È€ú!"L7wðÍV¦Jq˜œT#pÊw„áËàçýÚ@ZRÏÇ&—~¿w
+
bÛŸ=ÆMF"PÆ�‹C×™‰X1±
+AUä]<·õ—™ñÉ*1EQðÎ!A&åÔ@x*aÛ 99¬®
+
8"T¾ «¥Ìˬx"-Ô¦[ð=@%ê⨹µAÇ!øÑ=wàûàÄÔ‹î3ížl4íõ¾s3&ê�š)\l^ÒÌÄšÍQõlëŒoúÞƒ´m9EMé`:Áóñ8ÕÇ7d@8‚f¸Òá`
+ì�Ÿ–
+Z€«¬_Žˆ9¶Nž9l Ú:Î\zäÏYÑ�Ž>}8êÕ:¬ÆJywkPÃíñÖ¸ÛJt�Çlɬº‘;H•"@ë]P•½ƒ¼+æ%0)¨–úKÎ3á¯>KAÍHjú…L’Ÿ[ŸÞKI-?<š	ØQAŸ@éÛ™
+be2d5ÚÜÃ%Ìœ�&Ø9«a7\Ô¦ï†F#Â#ÂìÑò#f¸E庲¨NÈ<ê¤yÈ(¢õ
œjŸZ^á&#Ø
-•¤§q^Ñ+�!d®g¬~3ûužíNO=³“Øý.�E²ª%UâÊ1Ô¬}+lF†�b
~ö°�®–V¥Þ;ç£]£ÕKï o-K�‡_JO«×<G«ºøõªA%ÉÙx¥³ºVšÈÀöáÅoˆ{YæTA”…Áø"ý5TŸnH®om"ˆ–Œ-Ç:Æ#Wj¥G]§îHJ,¨Å14Ü×X2j®éP„
ðÐ0t–›G'3¥PšS/—]†"ÃdC·2|¼ÛC»ú˜8¥ŒêKÂ&ØHHU„.×I²ä’ùZAøý9‘ÍP&FÞù˜•Ü+Œz-«Žèc¬Vd½xP!Öœ-lÌw«5¹6‹yZÄX]½!­_68T�_̧–K*)Ü•\€ þ�gŽï)—°t
�5DBv¿, UÂo·P‡Üô*¢�€\o�z.;~ATyš#^ìs·]ÔUû(\’$D÷¸%ó»LeU™¶†þ�X•ùÈJ£j}kEOž^–d˜°ØÕ¶2"ÿ",£Då“pSì c;ûÏjr[­�Vq?p úB!µ÷픞„�œ{b?eV)”Õç‹Ÿ³âô7Ë÷—*ï„=„ÜBZïH_SHbűõ�“O2æU®‘¿
+ƒ�+”{¾ÊôóóÜ–oã<�j=`Seƒ
+àLÿCîCÒê¸wCŠYøqxþ:Üzø65|Yúö ½uYN²Æp¿ý"SëPy!W8½¤¡ÐWzFµ?¢V¢²ŠËHí’qn1Ux`	º(9žì7¿P…óU@U¦6—z
+xa™ëi†µ'°'cÏæ͆�Ñ’Ãxt }EjR—ᔚöc’ËÎ(ë‡Ñ#ÔI]†kÑ›(‘…,·�:®þ&q{iIÿHR[”ÅO—ÛÒßc,n7!Úhœè”>}yä¥GöÐ
+Â=ŠÚÅ׉_ó/7——1»—¬û¦£K`«¨àrøY±|Gõ`È=ÃÖápDÏŇ`™ Ý’(ÌZ“ Röâ.¨ñ”“¬Ù’ŒZ 	eR:Ž™Ÿñs͉æ„DuaïkÕOSA`«Ñó�uÎÝU'VAŸý^RõÂly�ÄspèÈ^4ô—�Ó$¥?ÝÛõ„$x¼@§å�ËÇÅÛoÔ$Z\—¬O„Z]È\(‚u
+8-y¨u'ö8÷ó\9b€Btï1³‰+/áu?ÌeóBjŸ(³ÂMEAé¬%»…> :þ
+aÍ×#êT/ãÜp·$3x»f'Óc;‚“Zà�Cq‹4:-žørf›B!èè‰<2©ÄP¶¿°wFôŽ.¨S:=<o(vY\×ø]l 6ÃÜX2ÌçJÕºûë:ƒ €˜LôÁ‡×V•GÒËôaq!´ÏU¹"õ‚WÕ§³o®Ç¦ ’êZæf3@¼eŽY{á>ØܹDñF-M0î’s%
+ÑÁQ|®gšnîòøÃ>_adÿæþ©£ñ!Îò¦_ 'Á™Œž$\­	ÌÓÞbHz¹×szrP'ðÌïã];7wÿ]@Ë/c™&ïÑj©ØMËùgº ˆàRŠ*6?á<Q±¿h9“µ›PåÀª;g¼¿W�e�ø§eî¥Åu¸<Å]f†ß½ÒÅ{üÚEG2kI2’‰aªˆûÃ
ׂ^µñ2€Ž¾‚ºeT�R.™ã·”sÉ„5šT“ÃpÏ	ÆJa¦s#
+ª
+ˆ¤ÅúÀÌ^wrËMb�vÖºQv¸”ÀÕM€’û•}«9»\û®­µñ¶hý(t
=�Ð!yØôѼèãL[±I–ºîîfÖ ÷k6«6Ü´‚W·
+ú4.Q¶É;X¸%ÝC³‹£w1¹G[è£ëWc/hl·÷­-Ò
2[Ÿï«+Çë9?èAaOc·t�o1b
+'úrxxÅ¡®bâò¡¶(»�EìæF‘ÚòQ2Ž'™'y•Û%
+]L­÷ú0bK„‡‡sMßTÕw÷ˆž7ÛÄ1�Mˆ2çµZ¶‹h/+׃ùgo•Þ#(úyék)@;4ð•ôò,zfM?H€H€Q,Cw9ø€†¯Æm·;8^vWâ×g×Õg*¶v£2ãˆ~½s
+:ï5€.X¯N¡Cx™kãºÇ6°=T¯6d‰;͇W.‚ìeœ1Gx²MÕkÍÇ~¶]
+ÉѨzJ±[س¡£•ûLç}Ÿ’8QŸ†žèóÇ8ç°ŠÁIZ‡6§¡Ã¾¤ŽÝCkÀ.`ƒ�\oàZÌZkif»?“䀅x`mH;ÐÒSVÅÁ°¸€ÈØ%à’ŒLN•ÿQ»Ž>19½)içíö	q€ú#ó¸adã|-‘³÷ $ç¹%@»µÒó³g�x«
ÖŽ¾—©ý$œ.¹gL<§ÍòÕõñ7bƒS¢£éj%;"Á2k)à"ÿx×9=FY‡ŸwjçJ’�
R�ö‹$›¿a,~LoÇôÚ«Ñäå³8Y}òç¢I6E�ÁÑ«ÿ¨œUX¬ÍÂ\>
HnŠNß–YÁ ðV
+t/˜~ü;™�nCÌ’}8êÂ)(Û8·ñËq]>\=n;‘:NœÞãË2hk]yt5Ï2NŠºœ¹ìI*œšuÚ D.²QQD‹°•6c8r…*Øê	Í
+ÉJ2kç¤%o72mÝIËKèo5š�n$éÒŠY~èp™î/íy\mT§ë4çN²jÆjKSO}Óé†6Ñ
gô]æÉ•\Gu²Ô2%LzI|’µ–ʽ۳:½TÇÔõöãOA©!
·\x,{"ÌF‘Ýwz§ÇY2­Îž•OdçÊúÎ`/â•<Á³Û9ˆÖˆH!‹¾Ó„ˆv�Ž–,ÕõMÄ[ñ«
Ïõ^‘9¹Õ3Nr‘17'rùJÒ¢î•"bPŒÆ(#é˜�ÛSˆËZZƒ•õuÄþà35<¥¥½::ãÞ‡
�®™!‚oš”,~�"‚\Õ
U¿{’áYAäÌ(q«Í€Š�µf­Ágß‘ãÓÅ:%§££ð¨±ræ'ô*"
+Sdü=zÔýKò*<gÙ e
+ä’
+t�mQbà¯mq™‹Ó™Ãþ<}~µ[$ÌE(-$Â÷p¯¦Ãk"†½®"ÂÔÑóM¯r=PUÏ£<z`YOû€Ñ¶¡éœp¡.¼2#ëî=™j'Îgª±Ï†ÕP…êf
+ínø‡ç¨H,d10PP�
ñÌG7¼_dêÜšÃjSX[‡sò9–øî}J·tqü´óįö±jFˆ~å�^xíVî°¶+'žÔ�i¤‰Å>Œäç(–©N'Ù¦7ÍÌu<TF[•÷EÔf±ôÒðÑ¢­äj›Ü!|íó€t_ŸŒ&âɈ%Ðóm“õC#¸\!…øí…§kÃ+襴aÔÁd–ÈÀáFb�Çä‹ù­™7,jûJ<Îy|»£Ên§†“±S¸J[äA
°óc¸`tÈËu*ÉËšÇð)µßŒÒšŠz̤¨ï‘�Yq«@¡ôÒFó¤iIl.¼3� h뉵óØ}ü„qÓ~|lHþèDYYnCè&Ì´çAdúsÀíe*ª¤õ
+-„xUdÛ¨û+õÇñ	Ñhå3MLÐ�Ìg•¼´æ´[Ðånd&N[I�³œ9u»Ž;h‚¦h	Ã&±v¤ðcý‚Æg[ÙÏ©R#*
+ñ¥ØDˆƒ¥™Pþh÷�ioi1ÂÿðïîÅíº”a¬M(añêâiùÃ
êÌ‹þîÜ0Æ«ŠÉ,zÃĵ:ûc
+‡ÓÕà¦^=µ®ãF–:%)Wmq
f`чÃyÜ©˜¯*Ò2|í~ð�µÜæf˜wÔªóŽ6‚ê¶SÖÞ¹†öJya×
+§[ªhÃàz\^-B}‹,�Kþý×nc�]O;EÎ�Ám±dé¹cxá˜g¸=%T]ãë÷�\†ƒ»jïÑÅðdêÅâºì´Z>»M4–‹ÎUìé´wâ; 0eÑ©€©KE*Ѽ—`0‘Êêk6_í„.‹6wVv>OÜ€@w¿‹Ê«ˆüŽnËé(Õä�^…õšjóFkƒ^Ù*® cJ#,ÆÆß“Û§FõçÆÅ¢Ê ôó¶‡aÞx’)ï
B'ƒ=Z°?é�uÊiŽ% 1~fÌ3Aù/A€NÖß
Bl‡wÜB+<{ÔÄŠ	€£iÝìG{K¿/è~¶ïõÄøìϥʰq˜X†bÝ>tÇ^hÜBÆ´½¾[â.1óÿb´$&ÄæEU¢láa/ëÔ tï˜Åpç7�/îEbØ…>	åÅ`YךŸ"3^›r¿ê‰Š;Ú�Q€µScÚï|Ö%Æûêæ%ÎÖ@äR›„L19ÒíQa[ˆb}[�2"¨œIÍžïš‰MÅîùÐÛ	Ïü.ùœ©e‡2yÇœóé(-å5Óü´�õö	´6¬±Ãþ<v‚sÖ£Ù¿1
+(led7)ÒÙsýœ¨p')ú¸ã]ž¾Îã»:N2àp6,Í×ê[®¿HÑÇn€R±PZ“Tª®¼Ø¡!Û$aìºï&Ĭ½oßlfS,åµ¢ÚxµÊ QœK;cå›@¤W?陉é�ÍBËzîrè&
’1i¶üžÅ…‘ŠI3w¨)§tÇœÅþ>Ú
™D;Ùäþºˆ_4×}‘ZQ%“›½™·]+ŒO‹àZâÃì&äÉ›Ã.²]ÝHŠöç˜ÉuÜPè95ÿ	�뢗ÁfDZbŠDl~r’nü%n†MmÂ7áC¢†æ‰‰b Msû¹(ŽãŒ¬--¿ò^Žö垌½ª»1”Ék^-ý•‹Dúft^t,¦£®ud˜'½ã0"©1oQòŠýAÕؽ6$-0,µy±ZdR3cÛ^„OKoÿ(r¯”Šµß‚¢ùe :3ĆԱhº¡³Œº:
+¤öÎ� "¦ýŽ :B;«ø&&c€'I”…Òn|]ãh¥ƒµ•
+%‘åwÕkïvm—wàpÇJ¹¾U	œ÷&“³�oP�1‘\œfr;Š|Y[âéÂn†ö¹ë°¾LTÁ¸Ÿ£d«ãÇ­!5ñ樹õS^¤X#Ûwô¨$c#Õp×RqE.84A•„�#ËPÆ4UÄ«SÚíÉ°ª\bÚô„ÑÑ`“ÇH­0åɹr,_QwæÖB“V
Ÿ4	O=“½´†?â;ežÞ¿(‡½
+7©¨�—.q`~K±
+¯3}â›ÛÉAj¸*óbŽ$k3VgzØOÜæ*PÛ=Idi)~*0vyÊ�î
+9ŽJ $W‚`ú­ýRÂ#Ëí"?æ’²†øo£qErl>í�Ïÿˆ!!(šÐ(ìÍ^÷H®²€Â#½7§”dËO€š>Äá}¿½8$�	4ûÝJ—ó^wÅý$-ZÇ;¯'ÉÔï{œU¡f
+Rs2$Ñ%º‹ë!n�ß%BÛ»C)uv÷'\ó&6Éu¨ë=Ôä:Æ	k‡z½ÌèœýU9S/ƒœþÀϨŠïw1~µ0D6Y+e»ø�ݼF‚z—P÷«údoÀ·
“T”,û«ðrJvº™‡ô¦ä‰_q ¸‰¸Oñ>Ëz0å™ð3ü™&UK&g&¥Ä²è÷˜‘[zÄ KR"áš…�Ê�Ž®è/¶ß~+˜àÔó†pJ§ã•<êw­òöViåhúyufRµÕ–4êåp\W a‚Ó\—B
+':o´ù]9>áÉ¡-Ö™)yãXp<âo_jð½äÂUZ帥þ06_VnO¨nórzcúî×Õ:L“5uþ¨8Ýi÷™¦»‚w®P€RJaa¨êé4
¯a²¿{LÑ™B”³è\@oE…Ð;çA‰
Èø,È+”qË�ájŒÂ¹’dV8G³}cÖÀdâæî‚^.ìÍûÚ�˜ÿà>*Õk …ÇÄx>2øµ•_&9¯!Æx˜ÙG"¼ï*“¹±ÌÝ»á‰V0�D)É¢‚k‹÷ž:å¯P4û
+Œ›?�yUGáõcç’£Ä%³¤™š€î°®÷�š�TYØô
+®V´:cMG	 ÏÌR\Y^( [#¶æÉù´*Ž|J¾¿µ°æêÇߎR/ð÷hïšý®dèÍß!HŨ¦µ—`èH�ÜÙ•õiÒ¥8Ÿ¢—"ƿ첈ïæÇ`é"¹º’ÆSð’ÞÈÏ–<$¸Î�â‰ã
+y#K×2ª®q1g¬›“‘-öæÙú݃ÓIÝFÍ×½Mx°<?ÑgýÆkµB-ÝNlr¥A¤M/šÅƒ¾Iµä;5
÷£,Ø¿W‰`ˆiÈäLJ©x’ ʪѾÓF/Gc à"Ç»_¹�,Ó¯+¢¸&lwsä`“ïS�&®ÖyGpˆ$9>O	cׇK2ºëAÆö¹Ì,b

šO)Ù˜•䪎ۖÜå×ïLlˆ¨¯Ø:
+:^fËër¡ó5‘ª‹�ê(foC;a'¥'Ô'pq84«Åq†‚iµ‡„
+¤¬™·yæN¡ÒÍ=Ñxhwí‡Ð¦-LêÅoR„µ ”3'ÅžŽ7vF£¼êb•r1uºÄ…›Ùaml³§W·áFIöõ»_ìß±#EÂp¯Î\R8ú�rî	,¸©n²o‰¨¡2V;�ëÃrÁÿßþî[gƶé¾ï—OžBË&í)Ü\ù#�ûÌÿ7õ|®æov·E|’ïÙ}…I%\ÜrŸø¥
7K¢ì´v,_Zµ¢e¥ÐŠÒyÛÕíŽ%_ÿœ÷ã�yìÍ2#íO¯Ö8_^{ñšÃÿ9ÊçC'±2]ØÓÔyÕáùÍ)Óç©X÷\�â~¡æô}Ù’—§Ëøb�y³Äó{K9ì™ül“íÙtß9³äí2Ë~ŸÏ�MÖYYzࢄ°TƒÎŸ8ë6‰B9ûdIF†Æ{úáª:OãÊ.,|©–u‰•Énãk“9u³3zX&jîû7WD‹ý î9�“fGÝÏòTNo½ª÷À’Ñž3(È'Pôè§b/©ˆóy§?nIËy¶ÚH©îš©ÖšÖæ-×¾$êMS|á*¹áö±k¬«¼+§Yå–óŸ}˜á·ÓÂ;œ¬ëönüÍ¢°i�òüêÕþ™6íŸLÂ6/èžµý±æc‰][K8–¾‰KQùiš¾ZnrKb]Ÿ:ß˃ü—ü¬²��´o\gl­V“Üèãë]šwó¹KÿM
“?
ÌÉ{EÝf3Ë…¼×Q©‘éÏÙ¼‚ýCÒR¥Èk_g-äM·´ÊQüµõ­öf
+
ר
ÀäœÔÄ¢’üÜÄ¢l.
+endobj
+885 0 obj <<
+/Type /Font
+/Subtype /Type1
+/Encoding 1921 0 R
+/FirstChar 34
+/LastChar 125
+/Widths 1929 0 R
+/BaseFont /NQLZDD+NimbusMonL-Bold
+/FontDescriptor 883 0 R
+>> endobj
+883 0 obj <<
+/Ascent 624
+/CapHeight 552
+/Descent -126
+/FontName /NQLZDD+NimbusMonL-Bold
+/ItalicAngle 0
+/StemV 101
+/XHeight 439
+/FontBBox [-43 -278 681 871]
+/Flags 4
+/CharSet (/quotedbl/numbersign/plus/hyphen/period/slash/zero/one/two/three/five/six/seven/eight/semicolon/equal/A/B/D/E/F/G/H/K/M/N/O/R/S/T/W/Z/bracketleft/bracketright/a/b/c/d/e/f/g/h/i/k/l/m/n/o/p/q/r/s/t/u/v/w/x/y/z/braceleft/bar/braceright)
+/FontFile 884 0 R
+>> endobj
+1929 0 obj
+[600 600 0 0 0 0 0 0 0 600 0 600 600 600 600 600 600 600 0 600 600 600 600 0 0 600 0 600 0 0 0 600 600 0 600 600 600 600 600 0 0 600 0 600 600 600 0 0 600 600 600 0 0 600 0 0 600 600 0 600 0 0 0 600 600 600 600 600 600 600 600 600 0 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 ]
+endobj
+878 0 obj <<
+/Length1 1620
+/Length2 20127
+/Length3 532
+/Length 21036     
+/Filter /FlateDecode
+>>
+stream
+xÚ¬ºct¤]·.Ûv*I§cul'[£b§bÛ¶mÛ¶­Ží¤cwý¼ï·÷>cŸóëœý£jÜk^s^×Zë5FQ’)ª0›Ø
%ìlA,ŒÌ<
+o(:¨Ñ_‚ä¤ñOFuØI)Q’¬¥®‰Í:T\+kÀ2ñ´Ò(ÏË2+­Ô»Ð]é¾çAM�¾×Q­?A"tto¯�$ÏÊAœÇÛwÎB�¼ã¢ü1lþUx�q¨eÝÒäöt¼d"�$ÀÇŒ‡™M ,tEÃ2g§ö“0AC�ª•ƒÇ“IyàbL�żê|c
+)/
úh½0HéZ=`|K›@?ôî3Ob¨cËL<Bß1d÷h•ß$™§”±ù¡î]C¶Y™�GOýú!‰�ëŠ.=÷«Ý¹½.oÇ°,½ƒšt­¯”3sƒÆÖ®·qbé§0ŠÅ°ÈDY~–iÃøu(Ò˾‰ªæ³?ž�
cŠÔbdS7sYð§>ádÍíìÉQûcz‹þú7¾cèü¹$	Æ>2Í%—¹ß°%F
+>@í£dJî'�¾T¨WÝ–
’ÆÑë«úþ®@Zl—,P* ï™7o6x©bäÀ×ZëíùOרc ‰^à°HY¹ê¶]¼„qGÝx-
$v·úyüJŠÑ‹lüwÝ„ze|5lÇ¢‰Û&^^Y†¯d¤å¸=眫Ø'ZðþžQ.,°#p¯ü°Éøù¨~j‡|i¯ÖÍ_)¢é<-ëqHb_Ò»S3‚4~«Ò/²Jú
+ó»kœAUyÑ®
D‰<aº/Q߆W}á{N·râ‹0¢ž¦¸2üuŠþK!Ìe§óç-õœ_…Éæé&·öŽtºö›)×öÜÑiÞÜ=39^TùyÖVÑúA`›Ë¯“Š×1³[´³Cr!F\YÔT¯É$0¹âv¬]1¹â2õ¦2˜÷¨ÏQï<^™2ÄH‘,Fð«­Ѐö

�ÕúSöËö$§f@ÂÝ}7EŠqÂl™ûÑ0†R
+CùV¿�·¬�žg&�>ˆ„’"µpVk_í+t·—$ïÒBh�tçß’¼`ª-�‘C†<l®I4@‚ŠÕÆ6Ã0;˜‚û;>Èù}îÒôƒ¡OQN¢¾hÉlÙ‚¦X©ÍÉÃÚ-ðÝ󜚮Ӳå‰f]D–„]fp`Ý
+‘ו‡ošDƒŒ¾”¹�yÙÚ<1Þö÷Š3
+9àÙ÷:Å„Ÿ\ÉFlý¹ŽNÁçµ±½F¥1¢{1I#�ù�#gÐM!Å&Ð!ùf¸¸<:â‘�[Ç‚êÞ
—dx²U�Ãü9‰Åm³{¦¨F�®Aº/b›ƒÞŸ&ŽiÊù0ÆÊ<É{–3Á—)t;¾
+I…ÆÄ8á J’«2ðÚÁF–û†t÷+àK‘D:rtËSα£³ÒFX°Y¿ƒw0¢ºãÎo‰Õ"Ú-P¼L>Vš˜ñפ2 Ynîë|CVÞZsZú Ó†x9�„ĶU&bNž\@š'üýlNÔÞû1ãWÎèjöE¡¬¨ÿI1©~´Ç)¨¥P#çP&¦B5ãrEò¬é&Ü�ìPÿgÖ©‘ŽrÏ3ä5ë(h“‹£66q¨	JÄ·­ï|à·Ë Ç#·û:[‘úìƒîi0žì­ÎÚoœ*3ö8¡|SgrJ_ˆ·¬»TáZ‡%{ÍbË„pøTþÃiK¢`È$Ñò-ž—
r
+g}%ž�¿<ÿš¦¢§y>ÕdsŸZˆ—ŸäØt‘ùB<*C�uù­
Xò4RWJY¾?Ôse4¿¦öÁGGøË=1nI6ö>â¶�dxøÛzÀÛö§úø÷^`K­™u ÒZ¹$gMÍÍE®Ý§R‰³› |~Π
;âIךÚCXFçÔ[ �"9Û
+%Všy¯Žç½wd`õ\¥
+?>Lîw\_¼__º‚+�úˆ—Ï*×5²,Üâ~‡
+ËGBÐ×4
$<]q…x\6_Ì�I_ϱȸtÓ<< ±ã[ôV(“K—�ê£hAÑLÿ�ž�ƒ«±î�«k”“Á™-H¼~„ÈëRtàÆ;ê¬ԧОSŸ«,Ä>x›ºQmMΠà¸ÀöH|’MÇD-2:s»ÁK¾jÍ)yu$–©Ó:ž•([mq!+G�Œ™SÞz‚PùÒ†�ÞjLñpö«Ys%²Ý¶p¬z.M[›t]Þ§ÀŽKxÀKPų½×ÕêL•ªçLý=à'd{ì-¥?Ö­�#†‚­¢E^+#6#–
ñ/–“õ­ñ¼ÍTñÖ<ínÀZ‰/”Ú8Y2ÓØ/gÓAÓ›øæ±,dx
+v]šÑØ}a(ôÉ:eÝX!±«AÏ�[–Ž×ÊÜ’ÀæƹƣÞ3a‘^£ãxR°šË\ì2ª<2€ÿŒÍmxÕîQžæ‘QáE‚ž�È¿¼=±HF,ÃØðªÊжÌ>Èü]¼¾Ø¨ÍqZ\Q0³“×-|/SS´æ;ª?
 [B�«˜jÜë&BØ’ÆIRòu“$€„ƒƒj°�i&ÝY³$——½å£
+ç
¨÷i
¼%0¸)xëõdïIG•&Ž¿œÃtɳ6†ž7|¸.&õ
+	-ΈŸçf™ÕÈPMC°3p§î¸eÚìq²áBÞæh‡~ò¨,þ�¶¢Æ®¹ÿã
+¥;Kƒ{jPÌ�CÛf¯¨“Ø£_:©Ãb*¬Ž–Ôº°AïhµûÞÈq‚F΃a¹¦Ô9›X´Öò€)t‘ÚQPAng©§âÏíÿ4»š†ü˜©>¹I¡Îúîá
+-5ù\;³½�2>V®±*T#
+
+@0‡cz´ëðcL"¸¶©ˆ1tQ mhž7OyÙK/=mŽ1Ü´iüŒÇŠ··ôŒÄŒ%¥”v=
\lB­×9Ɔ½‰ü‘“WŽÄõÝ©s;Ú¾†øðýa_ 7,Z±jg[À6¾bV¤ÊY—qá=›TLÀTæù4¸©ŒZä¹xæÇ©D
 S7Aof„ûoŽ¦¹¶†d¬Å(?#	Í”¡4÷Ú7©¯;˜Ác%$P„P|¹Ú“k½T˜d
�pR(áæÓþ;	@UÂŽåo.P
+·?å?«ì:º;rº¶;(œåÒHBÐUQ%Wy¯ÇûcEàÝÚóÌãÁÏbמgo@¦
ð­q´ÔDÖèÈ'
)øóÁ�«ÄhåHø*²ï›#™·ZÏYHá(%Òïg!›µß¿ûW{|êõhñGÆq¡ÄL»»o–DTèd·ºãú±‚e6D²]�}~Ç¢jé‰
+S(xÚ#oÓÜõçç‚
+¦cô)E}dðHÓœGNoj<]Sç¬<âu½âyקûU�7Áê­²‹E«¤py÷á8'ËÍibHö� qT?q::جöì(ݽïRgÝý>^ØûûWM€Õ}ýÐ駋–Ê{ÅóZˆÔ(sï[6ìÂO‘zü
+I³ÙêéÇ–T©-˜R§5߇›‡þÚ@ÂÇŒçoT§÷uf‘‚‚Ÿ£;?®IÖB,$ÊqªG¶vÚâ¯PIJ	•£Æ»¨(¡àœ•SÕ`RHáRp�·É/i¼™É6rƳ¬È»ÚôÊvökU;]äW¸é­�ysV†$Zk›o��ÀëãõK„ö Î£
æe�*|LÞ¹*p¼§}¸ò× }an²éÜ¥ºÏ¡öÚò´Ú7dîyˆg9ÏÅõð¤éFOdtã’ý‰,5FYrè¼c}í¤Ná§à:†KÐe
fŸvE#Ÿ?Íю˪̘í‘0S(Ó¿£ME J+dL©¬¼I­ð^>|$½g'IàŠ´?"týy0ïù4=:9W8ùÉÝ1Õ
+6AdQ›¹Í,>N)¥Ò©ðOã’ÛÍ·o}ŠÓ3U¢ªõ3“ÏŠC…}àp)Æó
¿a™FK›ó+	•W1{‘¨íœiNŒZ?¿~Ô<îZÛ
×Áˆô~ô}“IU?û
+^ºö*ÕÊ;â˜<\éæj�B† :æ‹ãk‡o™ùžËýta�A=« ÓÔ'ŸÔÐH•ÄN!z^“«ÿw¢ëKËÌ´«vߪý'ZÎØS³_-Ÿ!¡ÑÐ9†˜­yƒ±<`–ìÜkÚìƒ8˹‚®UF¡èýÒ¿äâôëO‹¦3xª©‡ì†°b$pãÀfN2rI[	÷Ð�`-IêѸ\\AIëÇz£AÅ
;²;»¬·Ó@sûÑ’Ðë"ø	,méG(;vø™�Ùd×"|‘"¦ŠÄ`྅Óé‘«¬óõlýÖ!|t]Œjø0Š–¬¿Ö¾ª0Z
)ˆM&çEî+
É÷ÉœGÌ7kʱ—Ed`X]ŒÚE•ÀQd¸À'D5õüDU°p¯)+7sZz Ce´–
+Ý)k=g<
+ýÀ”å•LâàÛìàwD#XY«yû¸é ‰z�p£^àž¡�°óRÈÒˆþ‰B
˜D²¼¾Ý_v|˜÷ÕìÆ”¡v’S|*B‰ã˜D#ÑŒ¹N7uˆ'ôx’ÎvïNEy-‡UI9̽Ç|iýB[}¥­Ó¨�ÜE>T”;pf4_·Ñ%ÙøN} T…—Äï÷uĘ¿”õ‰¦ûñ,Ri.ï
+„y„ÑŠ<¦ª�òÐYtÍþz`Õ4ŠMÇ>f·ÅH
3¯�ð(±…¼]¨!9‡çߤ–�šà›c�à
+è°ƒXC#Ä1ž7róѧƒ†1÷‹þØ*:½Ý
+¾¬üš"¨�ùᶓ°P
¾¢®tþkºô¡�ßs˜8ÁºÌÈ8õc°ã9­•Qæ3EåŠü±¹ÙΆq«¿tÔöÙËCCY
^"fDzJ 
+ÛnÂ÷Ù'Î{ü®ÒÿŒŒ®AiD–Xg‰¸N
+Ã2k}„‡�Œ°±hd7,
=½åÒp3{9uN4Ò�œ°T—£b؆F–i$ïó‹'p‘}¾Ÿt¥™´ð^ɨ�"3±Ut¢¡zx²ØÆx4D	K¬ZógÜ–z‘xC6‹]äÂØý9&yóï³t6�?ðÌ"%
+‘¼FøCAÌÑð}>€¶6‡¢ÓVÛþ\ý	diB´«Ù�Q¯è.Ç~Þ‚´ÈÌ=ìäm’6yS$ý-Ñ¥ª¶™)P‚�´)keÅÃvM¡Gã¶Ëe·5%¬_ØYûMŠKÒ}ƒ†Œ8îÕŸÃl5wìóµ Ô<öÅ·£„²3Ç��³’œVÉ÷
+žóø.Ñ°\éd¥(š˜>¯–LãPÊ Ôš3,¿Ô16še¤³Û²˜BG»O�åÔÏæ¦_�ƵW‚®e	oÎP×½'”�@ç×ÒKLýº-/ÞJ[ýŒxw]öG8förˆVƒÉcvÄþh;Ìšé£è‡µŸõ!qîL¾ÂmÕBÇïã@håR}ºûür†¢'rû⣖í5qq!Š¥¥¾Üt¿°wô¯µžQ8É@Œ‹«}Hë%‚Õ›E1TâìGäìï¢vF9Õ´�½Öœþó«õ‚y¦
+°YN0Û�æxôÞù¾•
·Z1#‘pÐG�)œïò±ž{+¿ÝªjwÒ±E©áš=P´Þ7±ÙÑ[7û¦“¸NYYÇU¸yd
+¢ˆÉd)$±¶Š¸[a# :‘�ÁÜ.‹ÍÉü�7LÓ„�(èòGÚyö é안øžwb�MŽÓüÇÞN�Ëe?ZÎÂfRc¯PÌeš²ªéQÚ"äI8�
+4Æg÷ÎüôL¬¾¾Ò?Âlœ�á6_±Â؈u‡ëî$àÝÌ;ÇDpBÝu¢Cbî›#13º;Ï
+*‡Kò·¶‡;¼-’"+ܦ˳-ý<ÎÈt_üöYëÎ’áBÁ‚¡$üé©Ò.&�>Ùe¸R¸¡3›Áÿ]u7üaÌõñ.R8‹zAµÓãvnXLûçpYTÓôª['ÒøUÒà=|¹üº*ÚÜO�AŒ/–*CØ
¿?CÞêh67÷
Wáïx,V½ªŽ_RÆò^/H–}èÈ;‡¨=+mä káÕÊuS®ÉẇNbnN’²‹Y)êctž-yá¬JHw‡d`‹£Mó®úí}KÕ4¬�«–!øWù…�sYÚá•MS
|•Ð§DNß"æµdYDé
+Á4õ5’KÄó}†#‘.§­¤‹R�‹«
+õS—¸­oïV‚•¦x{ì—?]Ž{øjA}øé{¶$õ†BÇÃh>/o†"U¹»ý´P‡SkwUçn0þ€8âàB¶ü¾F;u¶pL)#–�à
+}c6!„L¹âP’{ƒá;D¾dçqí¨ˆz`Ë2«f§µ­])ÊFDŠÜ›/˜[öÃð"§Ê^w�HZÁ‘³"¯�oD{�¼_7züä5àb«;ýS@$ú¡W °²ZðDò¢òuÙ
Ù‡W{fMÞ2ó¥I*,~…Ä©¹#xÖÖŠì�z‰KkVß�L™E�›)¹‚¢ÞIXbÄSóùÈ»´[N[lº3íLX¬˜
üçw^@dqór
+G%vA)ÁÃ
G¬³¤f‹o¥¿ñ`Ý­LF™óVõ‹ÔK‰óÔÝwø`ø?qŸàÁ¨Í	tj@®È<a‹÷
÷äIFÞµåüïñõñ
Ú1*Oîc=÷Sï×Rf•«xh¡«>Îê3cçÈ
+ž(—NÑÄåi¾%¦�Še¿€Ù?ó‡Ÿ›o†`ƒbîª0Ø– õÚ MR�¾
+Xá�…<§õ0ØC"ôñŸjè(–ŸÚŠeÂÑ_{Ú#‹p7ƒLìÙ5`:ì¥~Áì4«¼„?ãL®Ý8Qó\‡,OÇ™ÒÀ;ŒmhT Î§µVÄ! ¿h¥¦ž;t*ê¿ôŸçq
!·Ë,·*¤Z…ΟÐWŸ¼T‘*”„6C‰:(ç›ø9ÖɵQçQÈÔGæǦߑ_<Â9ç×YÛ­ÐÚºMîƒ3u"JL	üüÒ¦Q#ÆV
_©©…vYTóVKYðçæÄÞU™gÔ»ð¼òù‘Ïz‘Z(ßC?¢1Ý=�žâD®jŠR8€‘%öøg×Èži2v»n›„¸MM¢t
Qd�Â*l%–¿‡RS7ÌÖgj¿¤‚<ÿWßÊ}#ó9¼ˆ¯†eç
^™êgÞÀ
Ïõ#²z:Ý¢
+�Ha\»¤ÿE�H
Ü„Ôçì¾f•%bA
¯üIÃvÊ¥lPsw‰8º8Ö­æŽÚz1IÝûQgÜûØÍMw­©•—#ŠC$=ꤡ ºí=ŒjâwÔŸD*/ÜÒdêÅÎV
+�ž‘�õ÷¦ÝÔÆ.3±õƒ¤9ù]v\_17OnS{‡71¼ôtÝêÅËCgû!Ìõ’+
Ì\\j·Äž¸,1Èßß62–e€Æ§¥ì¶£þ&kL¿ÜêWÎc½aàJÚQà&AY¸Úãt�¼Å+«8•�õà�ZõÐ
³…V|Òœ½ÅÆú¡/½99t<�g¸`^B?h¸Ç0Àûµ©¢ûOÛâD¥¿¸ÆŽAôÅöŸÐˆ"&üÒÙGZ‘úáMŠ÷1Ó.Ø›ÉÕ
+}É6¡©†þÇÈE…<ÊP&öÌ>sDõbÛ_ÇÜÛWp	vµe�>‡ÿö²fßé(!‡°~i0bkzì¾ÕIä­ÖÙ²¥©@ œæ‰R&ï…Ãi$|i ׶Î
³�ùòR¥ñ-f	—ºŸæžæœby,I꾟pXðØ©»›¦Æ)bF°¡K·b¬H‰ÌçubØ<A¨õ¨Y*ÓIÄ�w7y	èÃokSI‡&úÆΤ Kʱ¯¨/ÞQ�wŽŸž±“&×í1™>JŽ%Yô¶y�X}<¹ƒùÂ3éîe›i0Û~4f$­z6n/¾˜z¤ðvÀÓx$×ÂìÀˆæÑnmeõaàtçTŠEð­*>÷ËMÉCJÁ0Ýg¿WæWk¡
0[(ÃL�(”ÂÁÒ/;í�:1JÛÙÞ¯£ùþŽŠ's
+†‚˜!Y5ª¬h›Âø
+’9„©²Íºi=ÿ¨nuþò©­'h¾N«˜4Õ 
7<±–¹ûIíÓö†�÷Õ=Î)iÇN{À$dQñãTË0¿‡h¹KÝçµÙÚÒ9äó
ÌèÍï@¢ËG¢�$éðfKvHÀÑ:ÓÝ&îûAoà `žŽ“DGO?Ìd¨ö3ìŒÂ̪i¢ì'Y"-°ö-¸™¸O-õÂ5¾4¡Ã­š6rMŸ4Éì’‰üË¢¸U9F4Ò±SÑU-ÚÆ
+¡à£"Ð,‘gÏKîD~^ººÓÜÉ/Zn\Æ$ÿM­Œù–1ÄŒ)Á×�BoÅ�£E[âcQóh¨X*úêÊÒO>0”�ëw+ÇœðaÚ¨F~¶zñyþþ{‡gS(êá9‡&IdÑX2)Fžb¡8ÚËp¤‹PX,Gæ(xõš2œS`º	faj�e‰ªh.,w¤á«7
+cLÇý2 Ža®
+L­ysŽ<q›é;u	%ý¡xCߤi67k]|Õ•ðÓ�*‰I
+Ñœ±îÙª
Zˆ¼¿›7Ã_ÆvN¹—Ks6Ù\£÷ˆ[�wåÝ4
+ÒÝzI6…®uê+¤S9ü$±ì
+³î^x½«nŸN)ýŠ‚Ÿƒ.Îq:¢:+ùá�Ž{ÎúsX~²‚e–yÚÊYTº¾ws!k�œ(IÛÌÀB(ëÊ#’ØMëü««}d˜D2è9 ‰‹â—'Ì¡ø´ïƒšÛE’,6bOöO;fôu-~_Çx�ð¿7¾ØÄ(Òñ÷í/Ú݈9?’WÛïµÈßFgùè`æ}ô}4*¦
+…3©	¤ô1.aõÂ’ AÜÿJ&ªƒ0E|R*�ü(ô¯[\eZ¢¬ ÏÑZõçú½á¸sÅ%¶_,sEjìœÌ.�®Ü¨llüqÒé;¼ô½ë|i*VÖŸ
+¸Kþ­Óp’¹«³>ú±ägWüD³É÷?æKåÖ�ôm#|žZ¡£¢Ieí"b0G`½t¢n¢J¯q¨ÜÜPé¢G08mÜ8Ùªç µÝ¯Ýã¤ßRf§2e±;$D/Æ&.m�È—(Ân¹\çU"S#�Ð!=7±æ
+’Š±à÷+ÐáËú­qJ®lHsIw¹eòªzDëÞªÔ• NÚšO%ÒçÕñr‰�½¯=W¸Ë„TF%��:uÀ䀙2º,~u‘\ıáýú”�oC}xù‘Žq"4{‰
+@ûÅ#\t£¼ó�¿º™/K®Ÿ±UgR¯H€d~È
+a«Ç|…Á|e¿g½¯
}ð”uT©ûa3s+³Ì¥•¿½ã1KÇ×1¼tþ~¸O`Ë’tyQ[ýÈ—M!›ªo®J¿¦½Á'‚K›ð⊿Sî|
ÿ˜û\W�Aƒ#‰Å9Žê2]2Z³lp‰Fûû–†ÜûO¯†O
&¤ ÜDpªV¦8ï…ñ™÷óìº
è™zgØùÝg¢‚5¹’-É}P«�†öž/£y+
¢rC*î‹#&ï]:x"v˜rNµ4¥‹|ÓWíJû`føZ1mü-msFYîÐ:8[Ž–?[¯+v~ôðá²›	ó&pÀs–K‘v£y¨¤}�Üšÿˆ÷[â01%¸.cœY‰]j�˜ª:Ç¿ùö:Qqæ!åµ¾©ÏÁÈégƒ¡¾{£6jÊÑõ({ö;¯`ôô«î½A$äÆä¥=ÿ7<‰†ÐZLLSXëFŠ}Db62×,èÿv;=›#˜‡Ãc�(íˆFrEƒÎUA7Á¾ºñ°¤‘ïμ	Ÿ³ËØ
0
+·‘—Vh/†¸MƒD:•ÄÇNñü°†•:#Þþ>PLÇÒwïÿQ5GbÄñ
Òû¦ªð@`	Ìz(iVþÉOëµ6‘
+³ãÆY§uïèœÙ+�èï°9¤- ˆíRUöMxöOþúíú¡ÅsC¨3‚Džú›„àyEà·£¸q›—Rôd}ŽO±æé[ÞÄ™G`c·§;[�‰^L–çÎ(Ön^v轈î½—’‚IA?‡�Zdߦx¶ë‡0Þê5/„·ï0iñUE°—,¿"7ZE�"Y÷­à ŒçÂëáÂBG¾8˜¯§�µ#êÂ^	êa¹bÙø´­b÷VîæלuHmzæî	
+P�̪è¥Ôqõ D·Š@ÞDzˆ‹òuçöÿäüfN?ag>-šŒÊM©a7šµjª)Ð¥0c1å˜Åêž&¶Á0®ï¸‚«n9¯ÀMæW )õêP&°C˜Ù‹÷¥J@eôOqðȾÿçx˜¡ù3ÜÏú\åušà$å·=„þ’»:0¥äí
¬	{]Û7°PPÎþm1ˆ’=pËvÑ18Zµ±ˆ
ÀºrG»%±6.«ßÌ¢8Î8П«woZKÉ9'çêí#úG—ïj²X+§ÃšP8†»Œݸ¼0J…®D“-ýf¸=_U0óA­ú¤‰Lÿé-àK�‘ú¥Ïã&zŽ^Lqêm²ù›_º´~æ9ö$ |òÔ«*9k+ôûÒ—eL€<•Ëu¼É]ý	v¨Œº�_rœ!¬ß§Ìèèn"X[,#ѬR;Ry\³¥»VXÀƒ±AA+w
+©õŠÊ»üyž+¾û™%’I†2£mÞá­¥\÷¤uçó:µš¥WbÕ‘¹éˆ×h'¢I��µCŒºÛ 
+JÎtŒa½µ~öB¿çn
8b¦”W»VŽn$èÍñ�)4Üê¤÷VûËÌ�Œ;µ•èN ‰R£ËÐŪ§ýÿ×>Y¶5
(QD‰!%ÝH�îfà¨Ñ9º‘n	i’"]Ò-Ý1ºK�Ýݵ÷þ‡÷Û}îù
çÃyžã•�”4|œ"ïñ`Ûý]_€ßÿ¼�ݲí\£$«:ê¯{¶F†Æ»lìÏ3¢?ÑL$G@Öóå×vmôãŠ#Žª×°tή4ËFIñê\é±¹†òã–ÊcLÏBÙðn¶²e™i¤ÿs;<¶ ¼ÿñÏ7JŸ�¨ie/þ5÷“FàEZUuç!í¯îðœJMþ•³ŽôÓ�	}Ëß–~¸
+Âòé€z{JE‰FªM Û„�u–æG0iž³ÍÀ†�^µYkúzþ'ôÍòH¬n“È([ÒKFR}ÿ^÷ôdk
+±5b�$ßì}Cd%#vﱓ*š°ßÉ
‘ú°»­¥8hñÀÜ_Œ»Ð7¥U½2f
+b›oÒm÷ãÅY…½jãnQŒ˜�fýÊm½­�ªm&*þ8”Èç1|ñ˜a¬~– F‘«•¢ûÎòXQ;(_ÆSI0ü+p˜ý&�á¸$BF
+ý1ì_v#ZâÍ,µgªìVØ
+*‹š@i‰úû¿ž8ëäCî3luRŽn£ÒsbX‰É ýÚ�Nã0Lb£?yrK—Søƒ=Õˆ�áÜá@Æ	žÀlþ
 ¦Ã<˜
'•AÅ87gñU˜
+Üxäø›Š•XGŠyº'üá9vµ,Õ½OÓ
à¬KÏýØIC`­”¿¸9Âò§é¸ˆßcZ”Âh.RÕŒI�8¬_$òfIKmÌXró–€àÇêŸ%Ŭg”ÆÂüˆßY'ºVR, ¨B~
ÐÔAQäϲ¯u£s¢€Ý_˜Œ\@øt-ò©Ÿ’>ö‡Q÷FÉÎUŽ«l$Ô.ËW(¦8*³Ÿ{>B7@-7쑘ôy™Ù7º!„³¶QèÌL}*Ÿ$‚WVÉÉ®š±Èñ×´//2ZA$¼�§¥ªb;>~T6EÕ<Õ¿¿Vj3ps[‡Ú[ë�#.JìñåY¯ª0ûì©'™„±ŸµQÖ8}Q¥ÞÒš½.H�Òý¤ñ‘õ$=¨â¯oñöaZ]‹#6ž/¿¦Ðô¹e¸ÞZ‹ÇM{ªh=Hp¿œ¦-Õôš£åežÂúz‚€ÛÆ«ì(Onû�÷söQY²æ‰Ï&¡I(Ja]�U›-fø´Û[ˆÿÞóݦ6vº%š.[Íá§KpyJÖˆàêh2nösjJ,©VŽ&EͯU¨•x�9øW+0éOžÜX‰3„\
+‚¾¡ÉzŒ:s[­+ž:[´‚r7À«_ó熈ÑFÂ2Õ:¨Ù�˜-Aè
+œÆâO­Œ,Eß�÷�;XM«âU†æüìeçÎ&¾¸cë2“.D£T�«h8&Ëe7nV"ÎCøpÁ¨Ö#}&_ot-ç2ÃæX�L¦ºŠ�ðï"’‚Áf&ѭ탔w¤éʼŽE9Ãê¶Y|t\dà=_©Ÿiµª¯9ÅÝU5½<}âoCʬe±É·mQJ_”�–õx-�ºDïä»3¦Ÿëï"‚_
+{8þF�ÑÇæ–éì	é–sE�cø ôc/
¥Xne­£ß	Ip’XÌ,X§x©o�ÞC§C7}yñ8㟑KÓ•F<Ø—¶cÚùc§>É÷"ÊåæÔYxVì#³í³9y«bTjýé‰NÜáù„…ª�jŽ\«WÍX!Ì[Ê뺧b'ÞŒÆ)<$1ôÊÚ[,à§	ƒ@ŽWÃc3/—°WnY"¬Æ4áé[_Šüå–#xÎöf3I�¹[V¦;ñ²è2f’a_ÏãX;q)ö�&Öö4FØ…È÷Ÿ
+=X¤9�ƒ:Ø•ñÒ
+†*Nñ(ßc“À“
+ÎQÓp/6è~�
+ê™ã2ú»‚îY$óµÉ•­ßª2^IÑPYm3ïÜÚ×Juý¼=ÕùÌ~9Äÿ	2©”pmPkDÉ�	Ç¥)DcX¨Ù콘ûk*+ÇMCÆ{Ù´~­Íµ)²è5�¿¯ÅL|yÿ1ª5u‡Êë�ñ÷Òc9„ÍrU¶óBDøò3TyÈ嘙	SzH1ß+`Îð¶+§`½°W5Ó㎎²ÁÑÃiÁ™,÷ò}cýö3!§ïÒƒŒ‘PuaÛ›”Ë tòÍ|T\ÅL,p�ÈBHðì9çÑô)8H-ú�äjj*ê=êOŽ
+Œ†<\a/r¼ˆvÈxµfíÉCvP€ÕóuóföÈy§Åm4ÍÛÆajùlW¤JÕ4pñû
Z¢Aÿ6Ñ®–B�][¢µš×´B©®¦Ö
+å�UÔwUMõ»gÕ"&
+C•Á&ûA×"4ÂÌ]iÅÎ|,›ž(mÍ…pêÖ.‰ý³oRŽÕ]¸kŽ¬¢PÖ¡ZÛZŒŽT2Ê©‚pC¯–dô.Rn®f™7£žØær
ðk®–-!OõŽž1t¿9~‚ó–�‰æ·q¼mxYæó”9gK’}ÃÜÕè×å HéÏAf™\pCÊˬM‚._óBâÚjq
À¶]qL÷‡Âa¯¡n—ˆ›´¢('â¥&Cv­pñf–¿�‡OFÙ2ö
+# ð:øF(‰¥YäsäLèÆùxÂJßÓ%ÌgæÂîˆñe:‡¯#0®ÿëÊ»3¯‡óíLM¤\“wŒgßRkHäŽÅ_KØwÓªÂìni–ŠØ±
¨wŠlNþjsßÑ8v<o¸ÞâÖ²ãU8^ë|Wš�
+ÆúÁÿ%ž†ëÿ	öÿÿsK¨«»³#ÔÕûÿ
+endobj
+879 0 obj <<
+/Type /Font
+/Subtype /Type1
+/Encoding 1921 0 R
+/FirstChar 2
+/LastChar 151
+/Widths 1930 0 R
+/BaseFont /HVVXSU+URWPalladioL-Ital
+/FontDescriptor 877 0 R
+>> endobj
+877 0 obj <<
+/Ascent 722
+/CapHeight 693
+/Descent -261
+/FontName /HVVXSU+URWPalladioL-Ital
+/ItalicAngle -9.5
+/StemV 78
+/XHeight 482
+/FontBBox [-170 -305 1010 941]
+/Flags 4
+/CharSet (/fi/fl/parenleft/parenright/comma/hyphen/period/slash/zero/one/two/three/four/five/six/seven/eight/nine/colon/A/B/C/D/E/F/G/H/I/K/L/M/N/O/P/Q/R/S/T/U/V/W/X/Y/Z/a/b/c/d/e/f/g/h/i/k/l/m/n/o/p/q/r/s/t/u/v/w/x/y/z/emdash)
+/FontFile 878 0 R
+>> endobj
+1930 0 obj
+[528 545 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 333 333 0 0 250 333 250 296 500 500 500 500 500 500 500 500 500 500 250 0 0 0 0 0 0 722 611 667 778 611 556 722 778 333 0 667 556 944 778 778 611 778 667 556 611 778 722 944 722 667 667 0 0 0 0 0 0 444 463 407 500 389 278 500 500 278 0 444 278 778 556 444 500 463 389 389 333 556 500 722 500 500 444 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1000 ]
+endobj
+862 0 obj <<
+/Length1 1612
+/Length2 18760
+/Length3 532
+/Length 19672     
+/Filter /FlateDecode
+>>
+stream
+xÚ¬·ctåßÖ&›£’Û¶mWœT²cÛ¶m§bÛ¶]±*¶­[ÿsºûíqnß/}ß{Œßšxæ3ç3×c“)ªÐ	ÛþŠÛÚ8Ñ1Ñ3räÍ­:;ÊÙÚÈÒ)M�
�lpdd"@C's[QC' 7@h
˜™
L\\\pd
+ŠšRò
+üªm{|ÓÂv¸*Þk‚駹?ÛÜ—Ní>ö¥©F{1­(zR€—ùøÞ$T}¨›ä4
z%ˆégQžW‹²ÛZìŒê»“JÊzÅïPߧ;X`®ž¨üH\
+üÐIí�|ŒRëc1:QA¾Õžž‘'?=RŽ�õÜ@öíãÑäÄÂ’ñ¸@ ’GúÙçà	h©Ux†SA¥7!àÝ´_}jt{êå‘‘â’FX˾*šæ¯Ù´Ë¾'A¦·ð&Ê9H¶îWþÀ¼žŸŽäJœæšËýZw&sÄâmŸ
+ì¿�µ$
œÉ„®'~
+j8+¼="HOló‰à|V”LôIŽÅ_y·1A‘T5dSoEy%|Dm3N†Á‡P¥{ú¼ÞÆÙˆ
+šÔ0ã#¢DËFwˆ(¤ Ù�Ó§~¾f%ž©Y·�˜"<Ø™Él¶‹�ǹÿúä2Ý©²HˆîKöÿ¢Õê’2|Cu˜Äï4‡Ùb
+dÇ$�[ß4˜h3iï*#§†]Y·�6_¡$l¥—\5Š´
+ÖƒGÒgÏt7êz \ÄØSÂèÑÝá	Kz¬Å~»šF£¦s>y{­)ÕCóaÑýû²Ú7×	Ý#ÓF¾o¯Q2v3äòÔן¼xÒ¾#x9�s¬(ÃÇÊÒ÷öUX7Žqb‘ŠŒHö;QºÙö³ˆÊëí:²5p,sÍŠ˜VÚÜýXQý3j�.jWô…¼¬[Ç2#oîä2’«²6¢£�yé0O ÙÓËø8³)Kz¡l„ïzä^骟|‚gOH)àY	îó�¸¢e¾,Ùê›Ì,ðŒ‚þ²Êsźy&Ê⥄ñϤì*“@bKiyäúk@W�Á»¾/ÿë÷îÆ5
Ï##êáù@¹‡ŽRƒ;ÇË6ÈV|¶å9{<)¼ç	QU+ó؉¬@"9ãå·¾9Ì-–†Æ¬»î³ØŽÈ³¼…„e†tY.ž±áW�ËÔÀ;žš¹„PfÙWÐBNûŠ�X÷a|nÓd5ÕR©¡Ûo÷¿]fǧ_$¿å0[^ž‚IpƒVzrEÄsÜó^Á¤ÑÏJó„½Ë®Ïô—qŠž€3«Çþt¿ipôøɼïÆ/ÑøµÑ7d™§©M’°{<1†/ß{€"Ã�g'”Dnnë«J0V�kÜ„},j6ä²6”ª’nå'Ž`gâ[�ö
+õ	Ò””d³3þˆA*ú<ì;»ãçëȈÏÞr‘U�¦Ξƒ	¸R64yEIÝ#ب[@“4ÂS»Ð¯«±÷è(pÖg/ä/ÄX»ÐÖ@­Å»b¾äcŠÅIî n¿¿„îçç3Ã"çU=^ó»\XºwV¯”¡ûB:Ï‘
+[—ÒØ$ ´zEø}:µ`s(éHô‚Å+X—³÷¶*5Â^ÁmøÆÊ$¶ïÉéGH
+>êò:Û†ç-àñw�N‰
+3“7º]Ç }"}x�t¿-i7Ÿè¹½‚•
+üƉ¾ÏÑü
Іž@S&_#‰= ]Œ% eš�PŠ†¼RŽ”oQÈJt{¸œñàº0ê8&ò½A"zXXª‰„^i$º@õÁh0škm}…“u­��@îK/²OÊ\®z��Oóu#«"ùÈR.¯AÇ„ŠòÙôÐJ©�4I°muþ`*?섨0­V2
+p‡÷/ó¢nD(0ÂD
+[Õ%:P+t¦*5Gil@ÐvmY‘ ‚œÁ‰~¦S J�Öjn5£ë—ðys¬Ø0ÒÉð¹¼tOC»¯‰æ÷­™ÄiÐDX¯Ð
+Ù¿®;ªôŠD™r]9@èšÌˆ“Ö�S|æ[Û,
('|f¤~}Ã!Ónëw¦©®n”Š\8ÖgK½Uz:'=*"Ô›%FWHO´­Ú³ÒèÒõÖDÐ_|ÌÎ\ê\Û
+qá‚ú a�¾ýGŸºî“•e
+™âîÑ~)�Ü“U‚™$¹ß“ñA=‡C“ü‘:³œW•Pv Æû§hbÖ¼ð»AàlmoÎUÁùË7…¹í\~3È
+ÂÏå±äÑs‰�TNŸ	+Ã<ˆ•9O¶¥fÈËDˆF§‹ÑÉöY廙l›¸·°6¿33ïáð\1ôb°	a÷	�Á{ó|³m«é*Ê›}½"é?Yš,µÔ¹‹e§úP�h‹ŽŸXEô¸º\©çÜ[ëgøV3C^à ±çSø�¥$š ƒÛáÃ:“É»®’´ð¾ˆïÅ^ƒÑÁ´‹¶ù´ë¬†)à!jáìKøGR~ŽCkCœùŒBΔí!$ÐdÕˆV`¨­\ ©n¿»Gó§æHðnêÚïvœ&ëÌŠ":—íÞÕ^"Æ;bÊz³N¾0UÅÕ–ûÖ1ÃÁ,Ծ㢫|7ßoV};º:Mý³éØc£ôÂà¤=™MhüCÔgaì‘7¨²Âˆ±b®5_¡·¸/ÂH:L«
>�r>Õ²"™y£6o„Aù±�RQ ¼“_;N\�¾�L©µá%7¸àÀ‘¾g$µc [ž Ü80›=~Øü.¥T¿†ñ¥™^šW`�/ž$8¢%S>ô”æý XÞ$'ñ.ά¡¥„2Éÿoƒã;At«!Äò‚´žÖ&\Åžã™dn£˜kjÓ¥³< -YRç˜oiæ
UìÚ�Æ‘ÌY	Kî%?ê5TXrz¶ë[È/¨£=gU0‰Ü„€UShW´1ûºzcw™>ÔXê1§†S\»²3Š‘ÎBaÊ�‰@,ŒëÂ?/ßu3u¤ð;…®MXÛ;Í0¾z“ƒE9–T¨ÕÖ[x,ÐÏsô1Æ÷Ìó–Q£×©VNcÌ…ËrÖs,¨ ³“eeµ‚l€N0j—;î
+??zÜ…¤Ÿ'PìE¶e6¹-Vƒú£�ò>áÂPe†–½Í•Gèf5©{AuÔ¦JÑø^V¡ÌP
+:Ù‰4GÌCe*Z­:?ß"íÖŠS$`ë¾*~=QîFf†£¾�d5 ?Užaú9v¢÷"“T!KÈ
õð;[
ùÛ
+ðþ�¿$vCÎÛš,Ù‡¦_¡ÌÐpvœY4Ô}ay=,”¸Ý
+׌’üïa,ZÆ¢O>c!Ö’&,î—AØ$l‹ˆ4`¿Ì™é„G‘9h{±IK­àôáî·3ÂF£Ýйô±Peûw
+
8ø=ÇC¦ñÙ"ê®ÒL¨ì:0%»¸vÕ´HƒŒ?˜ø¾âù¢õ3™�VF_?Òí)Û÷³qoTŒ²>ô£‚ùvî[±~á+Ó
ñ¢øøhÂ…ª>çV©Ã{‰iÜÁɾ,ÓPhF°1J4‘÷Ò�.’×l"ü<KÑ*ÊûY•eû�Ê]XODÏ^,@+Ý4‘‚èbiœüÙÄÛù§ô¥‘m
J÷e	�g§÷H9×-7,z3’ '‘nKÜ‹)«ZÞu¯,Ú.«9¡²ûÚ3Ö¥$¯Ü šc
+9P“½¥Þ8€Fl‘…RÜ⎩r«'¶&ÍÖr+v¤Ì•³7_¾‡ßm/!ÚûÑ9òÌÀæAVÔ•I°ÃL"ö„O]á²Â�!³�™¦WD§w<·¿
`Ÿœõ[ï¼¡°)!䛽'2Rj:PCø
Äfűbü]–¬L¡ÅpÝ·mñª}pÜf†Ë	ÑSYá‚ë^0Ñx‘Ê·€ýÍEÛÝöEô7N‚)ÕmÑŒªæÀ á7Š•U÷ↇK›—ß²9¯É,‡…ŒŸX¨<™¡ÌÅ…cÆ"ûgÚùÏ=j³é b«*"ìëLZaì{oFðÂ�{¹†âMAÆ	ßQƒ(°Á0ÖkøcÇǦŽtDþ<`N%ìy0ÉB´¨þ•PPˆ�?Ĭ‰…šåxùVày»—.Jª“ÈÌë/vg`ž0zðõà~¬	|ôiÄlTªœXöA¥j–çW¸�Ó·ôµœñø€l/^ôŠ^ÿ‘XÕH6«3d"Èî:¤úá_T`‚¨KÆ÷Xž³¬¦€­À›†ÚÐt
¨bØ×82ºÙ‹°Y
+g–w¸Ò_ÍÑf�4…,lÕF¯tçÜ äÊåšv…è0‚Z„•åIÝX®E˜w²b�!ZhÙ”�áÉTëkS¸¼SÉômз}P¼½ËiGýÖ´b
Â/ÚãzNÓŸylQ]*+ ºÞ"†V!�™s¾Ð›Íáüô¸Hм‘ôCÕ93Š+-q¤Õ01=*ã±ù¬�uŸrÀeÂËÇ
+{ÃbFg#‚˜–lyù>.i¾™?�#E¬4*872lºGÝ›ü”òóÕ�ƒ¹óšAúa§¢+lµh›¹cÿ[ÅU‚·_Q'ï–íMÇ7&U6æØ‹{tÍ3_ŸÔ_óerˆ$q¿E½â>$zr,¾.ÄBËëDÒ‰ú@û‡ÍDü”Ä­wPL+w1xàKDTjã_žKU÷‡Š¿÷ðN€úè±=©C;]‹‰ØÑ\z©r¸úÕ~ÈK*¼Æf:²}䥳ý]°¤Bu›B<+2¦ø¥Ø×Iÿ§½²¿S©ôûü
¨·zM­<ƒïˆn1•ùu›Ó÷^Vú#�:.æ?¿yÙž®ïµá§ðƒ£|`q^Iš©åâ:kÓãZFMd§Í‡ˆ¨><…÷Å4I)'16TØ͆Nß°`‹ð`	[€r	óz‡ÅÜl8±§’¹Ll[@Æh_ëí; Hk¢ÉjLÁf'‘Ö%З&så@µTýb[Ojöß	0®šm-�Z‡µ<"ÂVç­wSp#H¸Í°ÿ,3L\g*±Ý¾–Ýçpg¡’^�uІªH%a€ÃuQlàÎZK‡B£vHÕqe·lA�W`¬úÑ–îxüFÁŽ¸“Õ7º¼Î�IhB($y{³ÓËòMSô~¥ã# Z|Ѻ6Æ×c>ÁB’Y”ï‚*¤ÓµEkèið„ûܲ²ê6ë#¥ÊxNÛµqqŠ®k%:ЂÃÏý0{Â4Û¤8¿ŸJØTá‡ð~UâjçµDg,Vå|ÌÙ)îmÛÁÎ�n$;ùâßÎWûË)6{ô2÷Å1§ßÿ2_Q.4ÓZxWG)ûqŠ·óGŠõ{RÜh¯ºÎW¦ãrzÞõ�ÈÐKËDä]Üw¹Qöº¯G…\å#n—ë{aæÆŸð»Â¯U"¨k;`�aEw}øŽ¦¢´Äætf	µŒu	&ßéæsÜk¶Qk¥pxNšnL’v’Ô(|)²FðcˆÇY£0c…‚Ø0cX{Ò}hƒ¸eÐúƒKŸ:†ohÁhdYÔ}îw¼Vj¾]½¹cû¦wní†PžQY@V)[7ôU5:Ò³û��Ñ

+¢ðBîBZYø ¡QÚ÷¥Ä:_}ÒbeÚ*r³9ò”¯Ô¿åÏ{ݘéËáªÝ]1÷WšeÂ…5âo#”‰Nb… ¨ô>¶ïÓAÎì·¼žíÉzàá]M¸Q»„)ˆ'°&m
á"²‡8øg+Gž‹-¯ðJÁÙ¶(!‚d%šò÷F¨é’‹Íü0ÓK^žŒð§.Úf9Õºi"‚Bœ‘תÂh<MÆOOìu h9ž&ZO{èìxö6"÷rWNÕ6Ù$Çøâ0™…´žUî�Ç>‚0æ£Þ·/Dž¿V™¹6j©Û̇‡o—�
+_0ß9ø™Ü®Á³@3&i¯)BBD��‚Òr8ª¯sÿ’¶þø¶6ù5EåÇÁ�‡›3§ŸÒû�išI©R«‹ª]S¯Ðeÿzý!KþãÑÑÛ7çÙ96@:áO´ˆ�E(Q`¡W¡ÐêgÉCIචœ7·@ªÁ×N~ðOÎÏL ÔšîÑ„6t>æ€ñtFt&QòŒõk©ú¡Ì:	ZBw˜0.•�Ö 
+X˜DöBà矉uƒRá±êëŒãù³"‹‡»½øS,VëUgÈÓÑ×Hë‡
Ö•Ø®ôh3ßõ½@gYa°«¯ÃK}\)Ú�Ö„èoô}7dÔ{Â+ä’רþ‘ǟúiæpC8[bk�%u‘I0: ]¯úíŽI*]¬NꌕԲî<'âÌ€Dq¥1öYßþù4ˆù;4Ù´Ô˜¥^ðžöE›:ãZ”¢‡
ÖãßhSÁÒ"”‘æeGq	¿¸ú‚Ò®ˆ÷ñ
"‰v=}ç¾ÌÅ%ű;>RÕw´ºÊuú)DãPèñåVÂ-{
i�¢87£rC~zIu(a=/åÓ`éÇ
+`JVæ€ÝM?Ë-*\šFì\q¬w÷4³Ç"Ây'LÜi
�æI²úвTxÝCxEåÇ7#Í=䬯šÐ]ÏÂ)9™šj^wpŸi�uØ•°I/9c½šÙ;ˆ†YÂV%íÇ’:ðgEFÙÒ·O(–qS”•=Ž�M.A¥ó¾5Æ·ôŸ·¸PF×/ *ÝXåï·Dê,oö°`ÐO„&ÄÓú1¢ç)ã”au§4‚x­¦"ô£šV�Knþ?af�¿½ðÒâº-©Þ(äM×4jý€‘âª[ Âx06Ä–3±Ê�bV®gG¬$¨ˆ�X”£þÙ]0ML]B@! !k“ö'9iH„%7ØdÇýý³ê«VÂiH€ð‹Lêõº«§ÜTÉMÓ´1�=1TäöÅ¢Õæû�H&LÏ5« "ŒúÞ¶jªÏa1¾5e‘ׯŠ9³dfƒC|—fS}½Á¢^3²Ry€!©ìcÊ^Ù±•CyÞ>æäŸGY›µöLˆ²Í+ðüw…¯‰‡›]E™†ÏIœº#½Á”“W¿ig/€¶0@hçnlÊäª5Áç�®ýF6PI¥pKˆÈKUëqßoÁÎJôƒED=§É*óS½PlBø±a`
+^ñ2Ý9á4GÌMdHä:a,h�&y	að;!Ù$õÖaÖ8|Z2ÃdÞ‹J‰Óc—…6‘Ñ}Äu"å�ÈÄ7)õ)ÚÞ”L#mõ0n—Ü^žÇl¡~c[ø
ïz¡AèÖЕ–êÍ™qùÐEm)P�F½÷¢xŠÔ–ŒisØ€ç³D6
&œ<ÝÍYï’Úl¥ç¬œs·ÚCò£ypKWFsš£jƒ“ÃÉs ÈÚË~
+¸š4?æ·q|CÇÂ[9ËÞnÑŽ¯U…”kCWvܾOøHBÔfGpÊñ¦Ú™uw"£Û¬‘M+<ÂREÍœËâ`Ô
щ) SßêÓk3—�ÌŒÊy‰m:ãs‚êf“BܲþàĨÙþ†¨4ÃJ´§¹=µ¬�l%Ž»Wa*ÂÎK6#º=\{œ˜{áÒBz[òaey�}1i%œ1ˆpÊeD�Ni±`à6^¥
+“V-Á …ê©>Zw>î^’:ðëÖ£,AÎó=a¼PP?N}“­8s3zxC4-áÙ'Ð@¢¯Äa0½ÌåŠ&vù&� Ê«¹jÐ-OB;ó¹bî�Al/­�äÝÈ»÷
#o«²#yÁ?.¶Üè©®Ï²
+sf"7íȘ'z½½Aܬù;˜-Ø�„º5½ŸPoö’RnÃã—§cÄ­d>­Õ‚ëmOévXš}Ý…["�äC»Îµš Ú·ñfº ?jÊ…Šs$!ϧmAb÷yg‘Õ3–ã¾ú©Ÿ™ì‰YÊIÚÓjû[«Òaîë—e·Ù{/ûÀj�Âé‰õÙÊZXÀüì˜�à äa.ð–Ïæ\àß›¶üؼ¾~
ê¶Éþ¶ü5öZ	š‘X’oJQ˜iOÎãÅ[=Z)é!³»&ç–ÃîIëBå\Ý;»"�B7›§ c)Œ—†Þa�%ó‡ŸTÚÅLn_´´i·‘c•udg/U†Å=7
+BÎA>ȨÅt»î„ÞñMt7¡Š:»ùœ=2>ï((Ÿ!{GÅo’8DiåGÍlœ
ÊãVÍÒUŒÖº‘jÜ”Õíë
+ÞÐõ)δ¨ŠP=¥ŠúçÇ ºÚiÓNRŠÓ€„™�m:ô¹¾@1??¡–­”x!MÕT•ÛŸAsË•-&I˜·ö�@ãݪƒêE!F_Õç5²î´ÛT²«ô±.è-ó°{m
”´YÐßžëÈC&ÐöºoÕ¬ìêW5iø·Š ¹Ž–ðûï�~dÏFœöN{uÍUg¿a`BFtCÙ¾VØ-¯Vâe*ï@ì	@uòQµ
ä8L°4§2�Ir©¶Ð“†¤o§¿Ù	§¥ëÁIÆtPÕ'ÆiÎ�âsëŽÉÇTЃF`�Þ
™0Úu­5hJ»½
Ù‡,KíÜкÔP¡f|éO7§�Hf|dÑr^kç
Žß¼¥'@>¢íð@‘…„—Ä”ÄÄJÄÞ¿Ý>3„Œµ¬èZˆ›Ù¡R^XÚ9ÈÍjÕy0”Nš¯s„gA‚îWˆ™[Uú	£™2õÞzבl‡KØ6`ñ
+î†Å×°æËùß'™+¹O?àªH�‡q@…
+�…eȤ½øÛ ]Ûq};—¼¿ý%W[J¨÷¡¼–Þè	aÁþ[Ò-@^�ŸFðGH¿	ìÏÈÜ°<·eÕ@�wô¨‰Îy«(‘«xd;{”«‰U¸otÁªDÕL
+˜ªˆÍ|Îóp—aÜ^§9Lî÷‹¥¨`=1OþL
+^ú”ã�h@RÄfíÁ•6—U
+×qóp&+yPå°1¦àÙÂ¥å Xˆ|¿
ð$�6Uç»’ÄŽ¸%¼ûm'v»!†æ^™í�ç Åä.°¥6q2Œ\õº«CÛ7E.ÄÔ—¨lwBÂ�æ8=÷_so09Fµtéf²ÅoÊRaáÜJýèb;†xŸ)ｫGœþW¤ÈùQw¤ØØV„K˜7µºy$•o5MåÐà,=²æ_³4¥ñ3ž•÷°Ÿ
+áB«¦¨Û$EZk°`ë¥Y
5qÁ[œù¥ëÂF…:ÁƒN„´®jîܨ€›JV[‘
+ü™±8Éb�º¢¾9àѲœ&Â�&9h°¼§!`Z„ù“½M$¨'Ìé·Ç	ˆ‰b|ö]·[EÍ\çtHL”.=MSeî{F"ä(ËfIÜ
+ˆ4ƬÆx»ák&ªˆü•“KѡڪƎ5soõUKæU6Û‹m™³Ó<{WûFgsü2‘“+tëÑɇ¡ˆ§Ç—–Fë¹mù¨ö9¥û�Œí¬ (	Q«¿˜?©Fߧ$‹OÌr?ãZJŠM¿{m9ùœÄ1+É°‡!¨Ú‚§�¨næòY:ŸAÈ‹Wv¿˜iq“~ˆRŠ
+íqÃoØ8\"É�Äø‰m~'8
�£Éùª¤\"~Ķº…puX‚8R±·ù;¤‡,qÞ\;1´L	AÈ›œ>lϴʘ�ƒ�š¶ü¸\UÆækèK¬ôó(29÷ðJ3ôûõrï˜O²âåMçÑñBu”蓼!þ*²‰ñØx“–ãf�ðÔƒªáFb6ä([N£+þe÷#Ìó�,+CðÇUÓ3Mcf‘ÐAñn0Ja¸Þ.H”#ÓJ>U³ÂåbFµî
V?4™;>
+Û Ì_÷cvDMÄȺ„‘)˜3,fÅ·„@sž?X³¡˜ò\ªå$@Š$ÈW;ö=W!za(NGv È(èᇓÃY†CõdQ1”On?S9Ç>Oµ
+dõ›�#.
+óÕu«ðaxÍ'¢T´Æ49¿}
+„¹ƒ°yeàêÙÔSYãæœjî×]…)Å�’ÀY¡vSWòÀ­¢Ò�GÕîUê£	ãþh4×
¯DTÚè¢Ë ¾ŠŒ}dœœ'.ßñ»c)sùÂ4E©”€cr'L’q!2�XdêFÒ±!NMi€âñ¢ÂdÖ |H—^ÉuÞõ“ù¦?aÈísNfBèÈ(û;Ÿ>§[Q-„- ï$àKor§ËûI’;G¸],˜úJâAžXÚ€àvÞ9g•0žh}[ü £Å‹—T€%/WHþî×Dªÿ~Å!¬„ŒµWJQ;dZUüÁˆo	7êU
‰iT†dG�à!y×"?αLÛuº·Ô~¡šŒ{U#[Ö�÷g_SÚ�®s·ßñs=„Ñý}Ž´þ^W@�ƒ¨IÙ9¼£ýè@‡}Ó$0_>)’¤Èz®Ep,—ðóõè¦
+ÈïQš4Zl’€AÍMNÒ1B.NèL·YÏ¥£ÌÊ©“0d›±)š„¢«ëOØF'Í<
I�('Ó.DÁ=Œ”³‡pEd­ùØøõmQÜÛÓ
+~z#ë6 å˜Mmné©^«�ŠÒŽ†y§�×ù{?¤¾ó
ÃN[„!H-Èâ–‘Ôyú�ê³Ból«nsªYòU4M�ö¤
©0lÕÜ´~µÇê½æ�`
+chô„,	3 ‹
ï‘“#•ÃùG�	ÖÑŠ9$5à »l|ëQλM}ž¥’>‚ÈÔ!¦}™n¿°B=…_½' qŠ=ò¼²D½JQ:|4ù	"V&71¢‡»Ê´XGŽÌ˜Û6�¸XÉL�jðD^«Pìˆ,0ª°>«ÇŒzK„Uê• Á;ð#
zJí™ÛGÃLtåk
­' , 2ýòô™Ï�ªÍÑk|Õ[~>'}A–ž­h¦
M$™O¤�{É™™aý|Fo¾á¦›\basmç­‚‹ÝjM߃½€—RÚ·Ž¤`W<Tº;ˆˆ�³�õì&
> 5YC¶]Þ��œ}ËA…	IñFÝi„—¤>4Å1
 <ÏÜïQ»ÔäJ!¼@ïµ/g”Æ
+¹?¯²YÉLµOÿº“oc€ùÃ^vu?ÂYáQbâÔò%hñ£›Þ|ù:µ˜Â�ôʼn	"¶®œ%v ¾õ
+U¨!š»N}
�œ Ñ“;æJ›ªÙCĵ?ûœôý+¼<¹�辌Ðp—³[»õþAN
+ç´hô@ª{âN'H_È9S(rÚ·kEü&ßÏ•tÛª.Ü,çx>A(wYœÐ%
+ ±(ø'E5 Í0Á{'­WÈÐÐlûù
4·Oÿæþk¨ÕÏÙ€œ“æ¬)Tlý¼SM¢ÌºtÙö:ʇOI[|¹,™á
+¸}³i¼<nU·ƒÊ'D†7Òz;
%s}S°l<•’y°4�6Ê–�TZ¹eÛ]�DÕ\Y¹ñ}˜en|(xèn��)<¸ËŒ¢�G/Çê‚«þf�$'„ƒ":è
uë	ìðx/’<€Â?‰CòSÁ064qcZŒz¸ÙÝü�\! ;‰^¼·'PZÖ‰Ev
dŒ
¢bòjGYþ=Ñh/«¹È´®ŸË	$8éÈ'k�ê¼²à
+%gsðùB§*÷Ä•TÝþô¶VÔ½~Þgÿ°s-Ãê¾ù¤‡I3ôÀâʨbŠÅ4ZŨǾdzçÏ—à	Áç‰÷ø׳ŠX]"ïe‰¥?ÂÛjš…<®ÛsÒfÔAgV+¢ÔŸ8ýdÚ¥_ÜÌl:ɶ™q
+L!�
…a¥,C-CŒ}M¾~šÞƒÔCzâë—ò'|;¦DÜ‹	Ž‹¼”ýû·NsŠŠô
c‹Ð9T#qY%%ËGð�	0Ù¥*÷f’
+.³ã׋ÏLH]DÒ.½Å¦œÈçûNcxï*ÿÍRŒõjHG�mwr$Æ›~üzXÉõ½c7G9±fRpÂÔ›õñ`ç¾/ŽFöøÍ¡Sësöe‘Ä¡ûůjrv±K±‚º‹—li¬@bÁ̧òÓµ¬FÁ§”�L¡s¾´_úm\9G�›8+¥£XmK‰^γ³æ&„m©œtðÞì]ª_l„Š@O3º] q—�ÃX;Ü3œåá›
+kƒãåxÄüÁ‡¹C ¥"QPf¦CY_v�ŠÓÑô|‚ŸŽîdœîÃ:
eФÛw‘éûe« VÑê–†P-o‰ã¶*‚½—€:GçMøŸ¥ÀOr¿/CîlMk[6qÉŠP·eÙ0ÿ¸•Ëz
ý?TRÈõó·—Ï(ªå8“j$27BjߺÌèÖ–õ¦òãȹÿäâÌ-:N
^TüÚO`bŒvï	×o(<>yýeþðHó‚Tƒƒ2¸¹ÁíåÞ(å2Çæ¬9½³g¦F³Ùå’Ë?q…ÃN�ßJšPZØcš¹ÔiΑ88›ï…wäD&oô\<朕çÞ‡.'cve‰kÎþšØuôI¡]Èš‡þý+‡¨§Ä ~¸db D:{‹ÛÖq	•¢j+˜ZÖ+·?ÜT±æ­ºŸÀÜÀ!
+û:%é5¾¯åV¾çu™J°5Jòb´â�"2jþä³àí=j¹òüÅÍ·½OÖ±¼×Ñi¥Réqødoeל}½j(áIaR�FT¼‡{°˜Të‰n°‹W÷'½y@,}H5»A¬8ÑLØÑ]��ƒ5ævYÛÐD"ßïŽÊDʺ°z¡Ž »z}ð…ˆÇÄ_@ïO>s0<#gr¹ñ´�»f!bºÛèÊ5ƒ¢Ã–x¦ÐJÚ./°A>x»! jm–²sÞ7v�ÁßC}AœíÁ÷}Žn4XìÅVÄés¡%›†¹¢{Pû< ´éÔ Ì7¹d±·ÝÖ.´?²s1‹�t¯}¼;¯±Ý½’×Gû»{U�Ô.!ó!
T-ºž¸9Çݯ~_’*gûkèŽvª��»¦$û¦ÝU‰ô¥5Sü¼
+
¨ïÃÌ'l¿:¦ðè;{3¦Íäeµ—Ä;»¯McÕÒÚ-ÿXON´Â½²ùr�0‘õC€ƒºÆ…L9ꉱSWËñÛÖþN2¼‹ÆvÃñ’ýÐ È*ö{ä•k^‡jogÊ"oØÊglÂóIüPÚ}tq(½Ÿ
+QCm�6õ
+Ê’¸È˜”m€¿™»_–pÛD�‹KÅ|iVWeeÀÀ«‰
�„lÐÁôÃ�¿ê4èT0Éëë]Ïd‹;PL¹£¥e!D*%)f­­Ð¾ì {ÄùíÐîòs
ÃÕ|0ŠLï-ûÈØÀªY‚èZ`ä<Üu´N!ìÆÂçaæ¨ÞôIJE OÕF
ÚØÙ‚™O¥ì鲟‹„œ*+aB5*êëˆYš0MŽŒ£>ÂãðSΚb¤³(=nìj‘·æÑ4W­ÁÂ-
ÕÏ·­_Ñ�±îíô‡Çº™·`î%âg›«ïW‘iІ
Jmøª º¢Ô††ß‘$1½ÑØ“](snr…„L�¹Rœ±¹UbµVfn3]ú‘ÛÀáˆÿ3�È9ÆTÄk›“¯Bšž«µW¯ôoäˆ9u“lܲ‡vxvèô3Õ ÖÞlQ;,
ÿ®w½ß,Öf9z	ïï‹?ŽJ¬äl*+pË(ÑMÁ™ž eF×gº‡@‰<·5ð˜MêÍ	jmòÏ °ñksŒ]VY:zÅPÆ]•a£¿�u_d„‰ê`”]&6ú‚–2
#³ëb…S–ä|_'UBÉ9ÇØÔ*�+‹©´ËY[–µ²�zŽ’w
+Áë±(�`°1BøÍéÑ÷kL»;B„/ˆ,à G70�“›(Y:¥ö
+ùµi¸ŸÔ§îwX\Ÿy=rû„7"¬ˆiÝe6Õ�Èý`Cõì¥o�Ø?g`ÍF朌‹ÀH‹†ò×ÓÕÏ‘`ñ»
‚ƒT~65Î.96,`³xõµôlë	Ä\θ;&¦!kÇ×å ÆæÁJôV>ÓÛnQ3­‹c…8¤„½aGãÐ$îÉ(»çf†A*"CÛï}„:¾¹Ìl{‹7nN^ÐÊ`„påƒå˘ÌV—Ûyþ2>÷{Ή	=½"ž;ôl`¦GS=)ÅhhR:êbÞ°ã}µ;�íYÏHey~aN'¡¦o¦NQ»ð%`\ô?G°2™9×Á>ìSŠ¬7…¾»Ù6ò_qÛ§ÍȒΊŽ¤¦vغä.Ù#*Íõ¹²G-–à°Ã~3º½øÕNôdàÐH¬|�ò€Ò>I6]ñs˜öüåÛ{ñ7cÌ	a8d?‡ÉNV¦æWíû�ê^ÙŸ\W’é†;ˆwÒ`–v0zA…füA©‰õ§$=›Ò¥˜�ÖÒGVöašMŒs*(±Ó8ü�ì¹äô¶^�d•àŒ1÷·»s®ÛCºDdq
+I¢BŸîÙ¿¿²ÊXãÞLbÁcÔÅã‡Î0¸±hÿŸvæû
+‡

+ïÔ2AÆìöâ©eîÛ›Ó¦;»ŠÞ¹‘°!¸„è`Ò]åU-YñÌëŸò¬ùM5ÁF³·&RGßw´+ùû�è8šŒÁÈfïyFW�
OU£wÀº$¾¿@i¼ù9ºùr¹>ÒHÝÂö§õÆe¢Íw{˜¡Ù
+,ùÌçÖ6ºþ‘ß‘—§ìä*ƒšA>SxÏå’ò§Oœ•Ã�øjäwcâ]o¸‡�´×ç?e•é%IômßÞl)·œ?�Þ4‹™æI¿´—.¦Äì Ê×AÖŒqh}Ä_J¬Qêõu‘¦�ZX´y7³�xÄ,i’¸«^飯\µ1)Ík„ÝÅ	TÅ>¹Þðô3¥Ÿ¦õ1!}KGf³[ZdɦÚ^Ýs>¶ì¨¹…ç›ý˜“]û·çÁ ~V\Yƒ°ÕæÆÐ¥–tQrÿ=<e¢w†|hó$¿åÜ£ëØÁSä<þxØI'è÷¤ïëÚ_tšd¯„§wòÒs_×àdI#ØÙÒ¿˜
+ogÓƒ1GC6E®Í]cdv®l}©µžÆÍE*û‚Xí
øVr,À8è–>7%×5/ÔQz 6@^î$Æ
+Ìkª¸â§hDlU¼v7X}ñÂúZ%fòb+†Î5ƒ;TÅHÿ$IÀÒR.X/+ùeÌö2¸Õ4•õ…6È(z¡ØîõÉìg,Í¢ÛäZ}~û JmÕg(±èe{u›"&Œ›Å?c
+áò¼\¶¿ûë¦
n
+Ý)¥ÀÓ,Ú	€ž–ñ;Þ©x%ŽÇ*:Gï­Ì‘bàÞšÈÚ±ÓÀ'“('
ø·&ᦗ„Bf
s^0©^T
+i¿5xÑ@>,Ïu> w?tiÓ¶0ûôIÏä#%(ù‰ö
+©«ˆ|LO†D¨Å÷¦gîÑå¼Þ8vÉC÷I~®O–ÙÍ>�mŒáõÞ¢‰‘}‚
+^hâŒð·¹ œ£“hZ™Í/øÅ_à7œÀ+P�¸¸&&êåî$+Nȶp®Ô
~I(�–»c¹ÚŸYªÓÅg¶%ø¥p%ö>­’H¾iL¿\ÚõÐß(¦µâ_«8Cƒ—R{‹
+Žµrð¦ëØíû‹0Ê{‡˜ÊQê¸2‰«Zœa‰ƒ†*7Äc¹äJî„I›ÏüìÒ]©æÁ 1=Š¡å©òñS€MX¡¥�GMøªéþP¢‹:*½ÙOT9†ÜD¨*ÀzÞÃ*Úž�“¬ÿ°Ë_hg
+‚œ«ê9ŸjˆŠ"J7Þ®(ðhT(ìâ ª¦¼ÜðÊ™§Ä‹V¬áÝq
+oò]ç}£¯9B‘7õ·	ö�œH{È­�’ëæi`T&éVÇãs"¹‡‡ªÃßÛçVMo¼iá÷׈â{C„^×;¿_g¿`,·÷þ2
Ún“
RÂɫǶ]ÅjÍuib°ƒãÏV!QÏÆ>²¦aO<ö”ñOÁxƒªH²$áófe°§Åû›ê�¥úКxÇÑiêÅà>ò$­–Ìy"-Ú-ŵ ôý‰¤�Ëq�¸ŠÖˆÕ"™[�Ø m¥cA¸¶¹"t8Q+P�K¥ìó÷Ñ”¶ëÛãh_“	®$��+ƒº‡¼S¾ÎúÜþµ$áØ™éezv~7EhÅZÞ‚¥ÓªãHÝ�åûm®Ý‘(ãŸÄ"Þïòwnúê›�»ÉÕ”^«¦
+endobj
+863 0 obj <<
+/Type /Font
+/Subtype /Type1
+/Encoding 1921 0 R
+/FirstChar 33
+/LastChar 125
+/Widths 1931 0 R
+/BaseFont /REOTBO+NimbusMonL-Regu
+/FontDescriptor 861 0 R
+>> endobj
+861 0 obj <<
+/Ascent 625
+/CapHeight 557
+/Descent -147
+/FontName /REOTBO+NimbusMonL-Regu
+/ItalicAngle 0
+/StemV 41
+/XHeight 426
+/FontBBox [-12 -237 650 811]
+/Flags 4
+/CharSet (/exclam/quotedbl/numbersign/dollar/percent/quoteright/parenleft/parenright/asterisk/plus/comma/hyphen/period/slash/zero/one/two/three/four/five/six/seven/eight/nine/colon/semicolon/less/equal/greater/at/A/B/C/D/E/F/G/H/I/J/K/L/M/N/O/P/Q/R/S/T/U/V/W/X/Y/Z/bracketleft/backslash/bracketright/underscore/a/b/c/d/e/f/g/h/i/j/k/l/m/n/o/p/q/r/s/t/u/v/w/x/y/z/braceleft/bar/braceright)
+/FontFile 862 0 R
+>> endobj
+1931 0 obj
+[600 600 600 600 600 0 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 0 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 0 600 0 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 ]
+endobj
+746 0 obj <<
+/Length1 1630
+/Length2 15892
+/Length3 532
+/Length 16775     
+/Filter /FlateDecode
+>>
+stream
+xÚ¬¹cx¥]³-Ûv¯ØfǶm¯$+6:ìض“Žm;éØè°culãëç}ÏÞû\ûœ_çÛ¿Ö=kT�ªY£æ¼îûZ”¤ÊjŒ"æ¦@I{WFV&^€†ª–²‰­­‰9ÈAžQÕÁÎð×̉@I)æ4q9Ø‹›¸y
Z@s€8ÐÀÆ`ýúõ+%@ÌÁÑËdiå
+ ùËAKOÏð_–\
+ø›UY\òßuºZ™¸þ“Ûô8Xüõ4w0sûgKÿÂþÒüE]M@ö.
+`abû·Wÿ²kØ›�mAöÀ¿šþ«�
+™**À)—PHW£B¢ªU³m·W�ÛÔOrí]VÉ• $«ùqyĤ"õÂzŒf<0ëûë£Îðf}/Ÿí¤>bêFè,VØUd‹ÕƒæÔJlNÍo’©+¬O�XÏ1Ï-¼§c-NÂ1ipÝ›í\AÖ
+úêì`uvdé,RHžê$žkK‚>&Y	¤ºÛ”OØ&â„o™kâÆœm§Ù WëÙÉ
+¨œ/û«Ð[BÒó´`Ûtä¯äÍN¿GfáĈHªýmVéDÇÏ“Ÿ�”Ä÷¦Y_kÉóÍ+èü1pÇÒ¨å�Á³ñÂjD•jÊ
+Ga1�Ã8‘¯YÛ«Ÿãн>½l•ê!¾™Ç”œ±Rš¶?àW'‡Ù_NÄå�ƒÆY4!aÔ„ø‰¥–
+/ÓLòFºVÕa¥¹òÞ+sTe˜1‘G·G]<ÖlI¯7E³±+’Ò=‚��,Cš«OÒØor.¹kÕ/�ÁÓŒ’ÍU�±Hi~|ŒÖw�Úkµqš‡~ƒ¸Ö£7ö³"ÄÇYæ…ÅO	�k_ã1fo4,ëIoböm5¹‹²O½k‚uÒ¥2ƒÞ¡úd‹j¨7W})“Þ‹¤ÐϾÑdT¥wÇ„{•ü�¦ÒfË�ç«Ø™#K˜€Nƒh
çuÏÏ%¢>ÞØXñÿàÛñÝ%�rá§_&ωbksà£uÂÑj£«ÓEŸ
+ö:çkØ¥»ãÆðòvÏ5ÅΰÂÜ0p!.ZÍ2§.•`Õé;ûòÒŸ¾´E'ôòL‹~­'"Bδ	•RÛ…ê뚀ÄÌË1�ú€Þ‚`0ýzл»-õ®‰ÑÆöø�$·«|�Â9˜ ühˆô`´6GÞ£h‹º¢:"ÎÙ;¾M¯_­µJ�%îo%ÒÌnck—ý'y¾‘ýαšm¡‹¦ƒ”õí�Þ*{	iwQ[™¤kžçË tîF!cö8äÞŠNßãÇx´
’Ü!Ä’¥¼Ö¢¦¥Š—Î~_ó©àH¶ýÛ±1%Š–±Ú¹ Ͼº¦á¢Õ>ÝMÐAŸdZ˜Ê51Ýb1ܤɬUð/
+‡Ø
+ օݧ�{ÌæßÖRáï›I“¬ïØÃ4†ºéd`ðe'¢ò›KþÈé•ëÀ0xö¯´ØQ¤Î]åhÓJ;ZL½"�7Ò–ñà|êTñÌãço2R°×%‚¬Xs­üòc–>`pȸÔ¢D…Üo½I[«4uÉG ‡äÇ]F?bo÷¦"1I[#–	x�%‡x‹¹žÆɬ²×Á>Эs*´Ïühd&Cîx3Ôà
9‹œkMŒ™"Sà�ÈÕÍŠL€''ƒ™C¦eòœÿ@ËÞÀ4:%½BÔ‡?Ö´OH6c{h¦5/çÕ
+5’Q�Ä„Qƒœqó™0=l­\αç
+¥×$á_~Т:ò›l
+Û…úMÚ„m>ô‹'Á��†ž§MýO³qÎCÄ�]´5CXá*\•MN£dtWî
+BJ!•l!~X‡’Õ É•aó’1Ë"/°E©ø!Jü÷™oó§KDMk§Èéw“F±§Ûˆ{¹g,˜6Q4²«lía¤WÈw©4q’7_úU0"¾B` Ï"ø?(±*ë2­³G€ ¡fÓêQXŽŠJ5úºîÚ ñ%èÐäíb¡Ê¡ÓYÉ_c¸p'vÿЮ/�]·mÐøD‘/³îwòŸÙ|&æ>¡®GSÜ°
¯d9{¶£IóJŠK÷9fã¢éŠ ©þäÁõ@ñ¼9xŒi,P¾*=cùüà‰µNm6O—^E›ªÖž©ÁôЮº
+M2tÉ»bqJCgª`AjI@vr]Ú@Ö *Óä½è¼‰_‰ä”/ú¼�æ�/
+¨á"�R’´‰öÆ$ä	ÚUW=ŽgY·'æýÕ
±M‘‚‡{}•ÜÿöA®ô5±ò½U<b´Iïqç·3Áì\³ù«çsÿ^«Qº×I?^�s2XÉOzG÷6vïáæàæiðŠáãAûÍ6ü‘îav-œ2æ¯Kr�ʃzs_4/“íBào[çç3r„¸)_&x†·¦3‘�ÂÓeX’9iÏiëxêל-9ˆ‡sA\UÛ=$˘¹¦G	ÐñSÅ¿%ÂßR�2õ«&öòôtÈZ¡EÇ£ÚùÌ.êòhnSm»Ä³=£Dý”Çõ6àÆœêk0¼îSF£4pºJÆßú„c¦…QØÉG‹Ìû,\…RXÒ<5µ[�ŽwÂ×óé	‰ªšRš,¯þþ’\™mÄ�T�0쪃ó‚×sõ`ÃO4â„W…¾lï‹Ãë"Z2µ0lÁ¬{¦'(zñ.9_ÄzÎãБ²þãbîÂÑëwS*ú[­FspÛúÛߤ_é~} ‹s\±š“fÿ{ô÷ÁÑ
#ŽÊ‡/°²V L�lQ9áŽ%Ã¥€T… h�(£Œ"Îå
+Þ_#þÍ:ÑdŒ´r@SÓ^É2çQ›¨ô]´à8UY¦�âq¿½Ÿžj_'åm~²˜O±öòÃ
–,®ùé‹‘c^·�Úû…ç C)¾Êt%E—fã$‘P9¼žˆã4yo(¢�‘d9mšjW˜/¢qg
e>KмÎf6ÞÎ'2¦g¯,5ƒŽh­óçü¨6à«ÈÇ
+g!ò)#îLI•eÇO~,EbÛà ¢.ÈÁî=íõÙL(Bćơ=²a~¡Ž LÌjSÈ�¤k²5ž€ŸH½ºFŒ§WiWམXøwÖýï…	\#A†%ñ³‘�Ë2‘j	Ç�´½Û¡õ´„P2’åíC¶²‹’³o K,\QÛ²ÔŽ‹¼Ü
3WÚ	‰SÁ™Û3èF#ëšlËñ°ÁºÌ¬§T{ô?êu5DZ—b!⺂Æ�n9Š#M‘y^Qi$ë\Êo#£
:“�ÐÇÏq`{‹!ˆC%oÝË|°¢’N½`^¾VÄ:z´ßÂØÚ˜Å,Žž”\uyFÌOà�ø6ëÞÀ…?z†t+A×ÜéEî>VµÝ´çröt'ˇÅ<Ë9¶]ÄöýÞCðò�—|fŒK¨ª£µ®ß(­Â‹%SrÜ3ÀðYÙ%ŸT<RÎm�*ˆæ“SÞÑ-ÏaŠC!)wȨÊ;ý&NÀêpêüôÈtöÅ;ÉÈ]¶ÇŒQÉ�Ž_@q²Óa–Û÷Ý n}ù‘Ûü¤ŸZù“íÓúY»hy5}îê]5P×*»a$G(®‹uý"»ÊÏc9‹z›”­
+Qm�®­.
+_Hf³ÚU;ì­^º~ÁÀÝ3µ5é
øÚ¡ºø[\Ù¡&÷Ú;Mo9E*Ûí¬E	Õm¹lê·šÒqd‹¸þýà¡xZ¯ïvô£æQ¤䨟JêÅcFv£1Xc:bv´æQ43ÜËg¡ã6jÄK¸ú¡|R¹š“øÃ÷N7œô±°ÆDL³
ÒYTmN`ÄÔŠÓi
+öYˆ=~åÇk8¨ehúRZ^±V<£‘x–@#”"s•ýÇÚdÔIðP…®÷­•úz8*uÝKœdÕY…®Ùð.Ó©¬á.‚ºuÆTaˆVÇñŸC—nXЫç«j”«žŠçµS¹	Í[džN–üèÇæz	ôÛ¶IµWV€A¶šéÝØNQõÆ6W
+ÿ·^]Ä“†[#"‡6]”�ý¬…Xí=ïóñhé¼ÜmÄ%ýÖF¢WÛþª†Úû—tµdý
+á;¬/¨`>�‘DÉF•X8)RŒ(êe+QBöìøYýú$ø𙨗wš4ÉAÑåFç[/Ìï(=Š|ú11ǹÌYf�Fã–s»Ø'ú[þµwù|¼ŽÇÛ,ë¢39i¯æ¼Žõšm!¸«uEÖê†î	.>Pr˜áËóOªbeå£/Ï”£�à?cÛ^0ô²³Ë«Lâ9}IÍv#VSgzºŽÙÑ‘ðîàê)˜¶©£p.´ÊI*ðwgÚË&)ƒâ²o�UÌäšH€+ßÞÉ¥al‘BéiWŽÎG^ç˜ÀØl8„¬~ÇH/«æ5Àc/ý
+q,‘ô¡ÇúGåKco IÛ³�ø©‚Ž	Nv#j»£)Ÿ—“Ì·‘¶ý¤C±Œmm§
+ÄáÛì‡VJ@ÂyÜ4A“ß(9�,”÷-mZË)é‹�ò8ÕªÇ+“lvÕcÊž|:"Ú�!ý XjñÕ,NÛO¤y|¯aë�ŸÚaƒ™z
+ùΦ�*-Ír»b3‚Ë1<]#°Õ¤pX%'Lèw²ƒIýohZrI ®ìñõQ„è1šØ—×¾˜I×ì
—UHð¢îq‡G[Y(|#8°ˆ¾«ü Ì¡"�@áBÔóѳ{¾¨'™†VæŒþžßˆ)Iª‡ýE«HÞË]~@wt<ª7çqÄEÔË̬´¥!yšj½7§ßÀÛ*«4øÑ?rê9�ðgÅ£ŽÈKj…4HÍD}L
Âà=™òâ1å7Ü4
S¨r/êö,m@ÍH΋pø^T*õg´ ²è‚V
e™'&¯F€™á�myÛvî
ÃQŠ€X¿6~pl“È3ÍeôÆ`âå=õïÒ3(¬•éq7¥s
šçWÐ)¿Ÿ•µ®K¬1¿!qÄI b^B,Ësb¬@¼‰ja¦•0?8ì@?N�©¶�ôÚos¬y¡¸TF3ÎRer�9IÎÊè7?°0x?Dtebv
+"q‚x”Ad€Äœˆ®wÒ4°ÈJÙ¼­Ì8ø¿Wöwm
B\ëê ìáQ�ïÞÌæºÙ2çŠ'=|J¸^Ö{~
%ÒffÞ2*„ÿ¹UU£î[œRnÖûÎçäà/�︊»æÕµ±úøÖ[²@“¬½¡Í—5NCCOQ~Ù/N»ùÞq¾!ê �‚„ÙHÔÚä5Ôû3õíya÷UTE‡3BŒýóGN½Ü‡ÄlXþÔGõ“)Âå§aow;é5’-Vy3Å„§J%™èvsQ¾ó\¥Æ0wW˜jS4ÂÒlêW
bØ9z%ò¶;,_*EéÃŒ¯ïw1wÙ=ò^D%IßïÿèÀ	‘´ÃΉ™ûÆk¸ß‰y(@ÞqH·DêÇ�ÊQsfT+Û©Õ©s>ÁK@BªB¥¦¤¹já»AÙSg(c¯Ì^¹Ÿˆ<H|…vøuMgÌ[¸åßÎe7�wjrò2DüÛ6dlœ
H.)=í:{˜;œ5vrUå(è
+«°;‡5Î9ø%ÏçL¿ôw_†�hÝ¥‰’
6°V…
+�^”ØD>#û|ïzïÔ>Œ_ƈP‰ÌäFY„“ðÉQ[ÜȾo£zsT¸8ŽZv?=�ªÅHAÓB[LÒÒâvl.èÆí“ÚGÆv‹7"E‰†O¥Ojn(`²¯—½Wb°¡vs÷;îù+®{¿ÈýÀX°«§º½[�ŽÓì1˜'½Û6ˆUÊYø“÷dÌe`3ºæç³¼6àHÅ©ÜÁ­ ¾ØÅú(n°ƒù‹"uY»¦·[F’¼3 	J
+ÓdŠ®ÂlÀZ(”ŸRO¹
Œ»“69Û€Ìà†ûŽ�DQäìUJE5ý*rÍ@
+(§[$$Òè,ŠÕ%%yÔ»´Æ”V°ß{Ó(±3·Z„Ö= (0ÜHnƒ«%1œÍBz;�¦ßŽÚsÌ9û=u›UÛþígàÑv±Ú9Ž{â’®0Ý
+�ø%IÆãа¬"£H_|B
+DÈôZ¨K~¡ºy±'§«š—˜Â2ZSŸÄ*_Žs°¬¿áüy­•4á’DˆìG„V!3ÆÓä.¦ŸõÒÀ~Yx²ÚQ3æ0ËÉ*À‚äêJÛnïPýúúx ëW1�1u‚:OwaA” ^†’ÃÆ„fÚÒRW—Ø(˜¾àBß|d9™eŸÇì	x¹|nzç¥üí’�]áÍOúåð�;={É—êž/Ý„x_
?à^ÊÃxVòWû‚¼%uÅºs+§�iTO˜²�ýôˆí^êÓqFÆï;ëá[1IÑÇ@ÑIÍEÃÎXq{tUå½ÊZ$ÊÈ/.·Ë3¨-Î
ï_ßa?›@ñÅPlTÁLþ�Œ?iy1s•ÂyK°€[å>su
ñ-UXr§m;¨:ª•Kó£*gò¤Åú‰áªY&–Ì1Z°ÏÚ¬½ÙQ‘~r"¬JÅÌ`\Š}‰rí&�–¡[@²¦Ú»Eû($:¥ºøeÖÌÈ|�½C¾Ö(ß~™„¡
+ö99'(ÜÛG(#?‚iÎä²q
+[(†ºÍöt
bÚ[·ö-
+HÉU
+’7ø“’ðüÅšŽ,<ëÀ¢
Ò�½è¥;KY±7¨n’7qÍþL3Œ8Œ@×SÿCŠtv‰jáY²Ž¶bb»¸iS
+ÕL;&�ÜÚ社Q²;»UjNN{)òèÈù¥@Ã:è0>nOG"ýya,.�ÉàÙ zi™T�Äë:q!$*nK\Â)÷.¬�’í8>‹	–
Éîu¾J~&Õ†»M[oȳ©žJ´2Ëxy˜3Ÿ�‰“ýÖ.¿”©tü.ó–�5”Ï8A�ž«Z¦´´ò�Ïn‘Kœ'‘[àõ•úV‡54›»Ü,eW~o§5X9mó‹jœkÑ$'<àY�œ@ªùA-G-�_ÚmVó` «ú„£�ù”Ó¹×”Šó“$È�»²™©CÕr1¹"ÄÃ$AŠíŽ)й¦?¤Í0HÝÅŸàcËÉ&<j	©C@×Þ¶ÃtH.‰ŸkèA™ÎÿÎ!á
+u­WfH´‰6çÈPG
+.g4“Mâ'M¦ï(ŠMÑ|éÖˆð…õ²›ÓĘ#5Ç´=È•ò~u¦5Vê£R¯/®£­óH�Ä®f§ŒŠN¿:¿lŒTmoú_ˆ[O»1Â̤§ké&èIN†‹v@‹þH,€tŒt
¦á>Õ'R¥•K.zgóJ˜ë(+Á5¯2ìkÚ Ý϶¨Â[ú3Änè^þ^×ÌæQ¡T d`v+f<�ñ'yжj~›q)ž\k,°ý”škQí—½`µ‰OÒ«cìÔ\,&	šîJ
+íiW‡fÈ“$#Ò±"÷qHÀŠJ\èWxZ'dô•ÿ
+'�î»ìØ•Ë#>¼ºê£Z*¶
?fôÑ1sm%$¥ž
+aþ2rž¯Y"`��¿
+E¢Ì®_Q²HL‰@Zá~fNS^ÿœí^®<+9;ÚyÜúMtéÔtßæN9ïJAñÀئ{½ùMÌJXQ—DÎ+vûÔÕ†|bs”F-Ë•§EJ òó8}]ÕzÙeRéÀd.Ly’ö|ÿDl>Åõ]Ãh­W[®!ûÄT‡�‡ÞuýÝ!"ƒgúˆ.’FHD•‘õÝÖÚšgì$Ð6MN
â�jpx#2ì,y]®“ê™
_ŽwrÀ%�Oqp¶,Ô†´}–úy.Ì0ØÖ³pßãOS*³ã‡�ïwâE†ó0m‘�¨ü…YiEµ‹X‚EiyÂ’“	F/ɪô¶­‚´J´ž—�‡@%aHøèÕ?7ôÝŽ¨Â'’J‡ˆ2LäÍÝDœŒŸh¸Ì¢±·,Žh¶è„CYö]Ñß´­úgmkôfÆ#ÔíÈä�¡J¸Umßý¶ªæö1ãïÕâ•Æ»Å†-eQCÕs�oŸ½Ø‰	Í™ªLlmwÓšÞ—Jš¶9¾!&5#é»~kÃÓ•±�9wX§Mk‘ŠHg¥éÌÐ6ÓÂx̱Ùõr>%Cçñ#ñ“(ž¢Rm|™$×B\µÉ AvV7Áû¯…00À(ä1˵Õ�ÝÝK¦Ü¹Ù~éo»T9
z˜~Yã{òÑ=Mq0ûJA«ø}/£1ÄíÂ�«e—Ѧn/*ómF¿Äxù
q¬äyJS*\€d­-†:¯Ø]yÜÔåTƒ‡¿øƒØE@Í�fvTü
6íÁ2~lW=_xãSeþ<ùBÐÊÒm"¿‹g|£ž�Ž/>¡„ïn‡œ0'OK_5b«F¾ìؽ°`‚ýÔš´ú&¯Ï¸?`;ãõð
æzâŠ×=k-"c	ª)k¡@2×ÜlSÕs'tÜ«f�€p!Ó«‡¢¤H|ö‘¾×Á[ú4ô‹ê9_¹ªÒSGUPâI%¸5–
+¯
+qQ)[‡ŸäW=Òлe~ÙŒB‘»ëó´#âýmω;y»Š%üŽ@D$zfªéA%OÕtØ9ø»«óu 6’RáÞŠxƒ„ï”
+2:RÒ�]š¡¸\•´²DÊ™º´^-;nðÇY~þ0Ÿ1Í»PÒø¤0«¬}¦“?f0­úÙq†cŒ¶[ú¾;¶96�Ø/
+P„é*Ë~fûiöðÐÁ±y;§‹¸Ãà’ßÐpù<3A,
+HG€BÊ!´q<6õûœp—-HM¶�Ýu'¯ýôhË)
+Ûs'&ÞHË¥Á§õŒñ¾QNç—‰Ÿ8[/»'ÚýtÐMs¾Z!Å7ÃFjA¡;Pì;ÎÓ<Ø:ô‹hX[ÇñxWÓ·MéxW�ÕòћӼaç~ݯJürÎÇû®³`ù²ÏÉF™m¨1£áú§U, Å€ÎÌ÷;:Ö�Ç9½èyÄÂ1ž�ìPUºÝS‹QRUib�3íWëA(W×â“ÙÅ€µ†„�äõ6ú¡Q{I–àÆ/Š†#¿I¨
+RW¥Ï
+Òd<—ñ*õ/^›žˆu“ ”Ö†´06f¾Dx>É3ÓÐ6
$cºŽ~{V
+´.ÎlTÖ±ð`­çÐÖátžë¾±ÉŸÜÖR)z’ºª^Å}bû»Îd7
+Á~‡+Ò«‡´¬©Bcá#šUQˆµ»ž2ßÓ5:a]C>+×­7ø×B
+lwÏÍ	¤Á;e£“/~Å©ô6€bDPö€Àì5	ßhàdÓ'±1ãŽ�ÔH®—äI¯Ãz£íFR…R꿧�ù‰´Ôö~ZB‹µü|†šïs>vŽ(B¯)ˆä<µ¢+þ‰>wÓ*>‰v»P°ÈÒÕìn݇�32B‰;¾}0ñ\d3í•©Þlýöu>Ø5
¹¿
å'Všµ«7ŽìòÂn@ÐŒ_÷ u,c!Üy&iÏ6I�¿ÓpǾ
+I3qn»#q.¢+j¨lx¥šÏw$�àmE8L/ëÄŸ4
+i}ü8c©+V\‚ØH}Hȧ¿`$¾³O4Waˆ©þ«ùů�µbâbõê¿Þ™þz[›aó�¬^QÅç¿o¹59ô>Ÿ%{q‡óx§òêÕ/	ìŸ)¨1£7i�-ɉ<ô–Îy×`áÌ~)/B,ÔŒÄ’$¯üÈà‡Š}Ðq�ƒq\­¸Ôä9XÇÊ&Y Ä~ÛÙ?FÑ«âÖ7A�hnzräÍç$"wÅ:XÞ#uq^ß>\xb1Ò»Ïtá6J•ßOõ;‹ŽÉ–a¨Û�ß„f{âe#zP$ü®)И'Â�´³ýyòÓûÕn&såÚd´‘ôòh0×Qš>™ÒsA”>2Ì„8¹º—£q}�ªé·Lm¯‚Ódx¯N›GQðLÚþ‡Yô2�V÷«½	1±ÅµXè*ýõ÷q¦69+ÛÞ¥Ÿá0ë8õ¯Ü§Xî´ÏÚæs>Þ¡v5js+¹¢ˆ´Qaïe÷
+á°âÐÑÄÕ—bJŽãû—"oRc¸°€~:ƃKÚX^ªðTp�—£™#›2¾&�úÑj±7ÊL�åzm-5?ø±�	%;7Ü'GÈav�&³}.uƒîãÑ-ÏAmixûÞ	¢²c
+MIª\ÂuTØjGI-gý�ÂÓ–GâydføæÅxÃÃ,�oÛ.رÌ*�_ùSÕúƒóØCkëÚ™­¨·>]ÙrÿÅ:K¥ÓS%œx
+æ¨5-lçÖwŠ?v¹Í“!‰P£C´é¹2üÇ6$í.ªM¬—¿òÔö�ž8ü¨=Cî<:6¤Ò*À8€Ëi¾‚’¬ˆ§eœxÁ7gSL¥�]ü÷MÁl϶É_LÎ[¯>7‘~KÔ
C¿
bÖ¡ùMÙDSG„l,Ô±ÿ…ô4¨·ÕõvOój˜ývXÚ‹>N]'#èØÌ×!óþÇ7îð*xîG™õñÌþÀ!%aó�Ц_èõ\{¸®qf__ÌjävU“j3ùêEo/ž416ìž-AXðIŸsþã¹ßZI‚–>ÛýNA¸�­s´Kp‹²�ê˜"ÏGx	�™?þ³Kl\jß»¬“aÒۗ샜+€uÊtC—hÇîá•
+¿n$rÝ	Xð�D˜t
ÎõÓ…”2§—n„sÞmOÆ„
 ˆ;²ÃßshuåU9ñÖ�&;y-sõP~K*ªÅz4rnp´�}ª÷œõ)RB—+«å—>¢cI£Ž¹w×	éhz€Ì\mm £MúHþ×<×|Ìï­&‰� Ÿw³s£Üë+\?VË´<=yò‹ØH»M'²ñÑ67Cøoí+A5x5
½·x¯'_Ë
+c!vÜ~óÓ4¶bIpµP]ãH^ŒúÀnkLßYßÙ„æÀ,•‰)tCœrÀ‘Çi†Ï±m$�hýÈn.ÿ¶»öO¿ªWÂ[–{OFChÓ'ž
WùÆ*6L‡1±’g^H]u Ââa3ð¸g@—TÕL_1@d7¾ùÁ“†µ�‹Œ:…‘XF.ÿ§�Òfb1\ÄñSÙ£�Ö®TÁIS ÒŽã{9.´ v´ôPš_$ƒºÃ™.T€Áj”¤RÚ.z�àÂiXÎ^;-”ûkwå0HMKyÃûSc-‘tkâôk'a.*bí	Û¶4ŠdÇ&ž*qÉŸX‡ÒÝÓä"c°4	*+9‚3£
+cáE¢Lg%ãŸïÁó§KíÚï©=ëg‡~Q)œu‘Še7@ô`­¥¡c˜„s2¬ìe/ï´Ã÷
5ØI*·[ÔrH�îD4;"«hntRÉ´c¬¥ŸýÝ„u å{ÿÁØ}hë 
…
+¯41¶{ºQµÚâl·Pãg;‹($@
QQ~:ú4¥ /麞e„¼æª't“Ê>~œÍÆTÂ={š÷ÈcW
ä­ë6Å͆ÇIjË‚¶{Al ¸¸
²œísè¹”Lª £ÈàýÞùqœöÇ=*Y€þK
+endobj
+747 0 obj <<
+/Type /Font
+/Subtype /Type1
+/Encoding 1921 0 R
+/FirstChar 40
+/LastChar 90
+/Widths 1932 0 R
+/BaseFont /SJDLCB+URWPalladioL-Roma-Slant_167
+/FontDescriptor 745 0 R
+>> endobj
+745 0 obj <<
+/Ascent 715
+/CapHeight 680
+/Descent -282
+/FontName /SJDLCB+URWPalladioL-Roma-Slant_167
+/ItalicAngle -9
+/StemV 84
+/XHeight 469
+/FontBBox [-166 -283 1021 943]
+/Flags 4
+/CharSet (/parenleft/parenright/hyphen/period/zero/one/two/three/four/five/six/seven/eight/nine/A/B/C/D/E/F/G/H/I/K/L/M/N/O/P/Q/R/S/T/U/V/X/Y/Z)
+/FontFile 746 0 R
+>> endobj
+1932 0 obj
+[333 333 0 0 0 333 250 0 500 500 500 500 500 500 500 500 500 500 0 0 0 0 0 0 0 778 611 709 774 611 556 763 832 337 0 726 611 946 831 786 604 786 668 525 613 778 722 0 667 667 667 ]
+endobj
+684 0 obj <<
+/Length1 862
+/Length2 1251
+/Length3 532
+/Length 1861      
+/Filter /FlateDecode
+>>
+stream
+xÚíUkTgnõJÀ+Å€€¸
+æ2��%X4©É„’LP�
+A@0¨P¹TZ)­`�åb°¢àY#BAn¬\uÝ
ôØ¥?wíÙ™?ó>Ïó½ß3Ïû�óY˜yúœ9H슈$�Ò
wŸƒ 
+C>"ÚI`:
+—³L	$à³�EÁ €vD²-u‰à‹]ù2˜ãÉ—°y
+Ú$6e`öÂÔ$ìAHAXæð 2ÃPˆ
`îaÛ·ðÒÐßãö¡ï
,`‡Š�˜·ÿ98‘E(
+‹$‹g‹ÿ]Íåc#ƒaÌÆõt!lÇÄ�ܪ¤ò˜/Îßùá#’ÎËÖ
+M�v“_MLŸṡzÎË,XR2R¤ºzB�Uîe;žÒG¯¥{¤}5U¬ñjja™_fµ‘Øíƒ�LH•¯zmc9ÂT„8�ÿ�ʘވ>:ûí–­=S[b[õÎqÔŒCçfºt×[{Ÿ´6ßHë¹ Ýÿá|dÿ“ŽÍ5±¹7¶³ÇoßwczâÅ®©–J®“nÐ4óÀ�P*m¼†�›ï©UG
9skYi�þ²§¦)æÉÏ[|ÊdÓ©1ÆÑ¿Ý
+ÓÆßMM/šþš¥ƒk4e\ï¿£H¼¡"eÄín0u3i}dË{µ±ÕÆCþI0yÀvť᣶�Çû©“ߨµ7–Ƽ(ƒBó«sLw=�
+ÿ¾nûì~|ú1â—U§>+©SèvÕ€ú;îõ¸d¼,Ðñh×J¥¸K¯ÎÈkx'FIø¡1»ö®;»KÅ	?Ð3úîk¯€j\:r}­•Þ<4püzEÇ\ÞI3±üêÀ+æʲÕâb«
ââKq£	ô¾£`åÍŽNð�z,ýpvs‚™j�|-Æ‘ã*­›ÖËk
º«Ïʽz¦Ú}ªÌ(¥™¼BÈçžÑ�ÉHK÷ððòûR+öpSnb
+TÉIs›ò¯7”ï8�Ëlòi~H;¾n¦ñU‚•úÛŒJOó•¦E½óÅ
+endobj
+685 0 obj <<
+/Type /Font
+/Subtype /Type1
+/Encoding 1933 0 R
+/FirstChar 13
+/LastChar 110
+/Widths 1934 0 R
+/BaseFont /JTOBJF+CMSY10
+/FontDescriptor 683 0 R
+>> endobj
+683 0 obj <<
+/Ascent 750
+/CapHeight 683
+/Descent -194
+/FontName /JTOBJF+CMSY10
+/ItalicAngle -14.035
+/StemV 85
+/XHeight 431
+/FontBBox [-29 -960 1116 775]
+/Flags 4
+/CharSet (/circlecopyrt/bullet/braceleft/braceright/bar/backslash)
+/FontFile 684 0 R
+>> endobj
+1934 0 obj
+[1000 0 500 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 500 500 0 0 278 0 0 0 500 ]
+endobj
+1933 0 obj <<
+/Type /Encoding
+/Differences [ 0 /.notdef 13/circlecopyrt 14/.notdef 15/bullet 16/.notdef 102/braceleft/braceright 104/.notdef 106/bar 107/.notdef 110/backslash 111/.notdef]
+>> endobj
+681 0 obj <<
+/Length1 1616
+/Length2 25291
+/Length3 532
+/Length 26183     
+/Filter /FlateDecode
+>>
+stream
+xÚ¬ºc”¤]°%\]èª.uÙȲmÛ¶]YV—mÛ¶mtÙ¶ºlÛÖ×ï{çÎ�ug~Í7?r­çDÄÙ±#ö9±Ö“™$òJ4ƶ†@Q[GZzN€Š¢š¼�••�±¹­4�¢­µ
௙š„DÈhàhnk#làä¨
�
Â@#
+
Ó¿rÐÓÒÿ‡ÑÜAÔÜh,oîhd01°úÛ§í*6Æ@{+sà_=ÿm%€†�žþ¿ù”ÍÌ�,mþi<˸€6Æÿ�û_‰þeN'!§ ¯.Fõ¿ÏÔãäÿjï¨ìf÷—Úÿ(EÆÖø.þA´uxÐ0°²hÙ™þ^9F
+4‚^ùckÄh‘š‘æX‹ž34!¬Õ×Ã
+¥$T³ØÄ^×âs:‰¿�„³Ó�t»©È i+3«0�€Ö~Z¦Ò‹Áº*ã¹®.òzbdÄhn“<£c¿§¯
+ë³ü>Ëä1os´˜™(ÏÂß_�Ø⟣
+Üiv^ëå‚áßcHdð8�âzî‡ù&v'ö@¹v
+Ý}�ÈâJK3�î„ÕžÖõlµüÁçÓDÓRfd‚ICÖFJ$GKó¾¯D˜ü‘·vŽ+À$kPSöc«¶U|R·Æ
‹‡hX'œQýSÁàØœ¸5£
+•LŒ{Œ›h1X+ðaÃ1©GÌ$“ñ¥l&HÝoÿÃ5Ÿ©qΧ©uAÑÇÁÛ9+�.ÅÌAK¯lrD‡2||ÀÞ�W™òqoÅU{´@ÎÜ^ËÜq�øHΧ6U½SN0}� ì Šz,sE¬˜¶a;<Z�t$N}Dzë³õPô:–šÕú.� Nž³¤Ftȥ͜hR=l>eŽE/Í:P–ÒÝH“OïQ\ÉŒm–Õ›ÝèIY湪
F'}P¡Éô”ÆiR¤ÞÑî	•¼Æ-D1dšMZa·ø»ooÄPe0™ù{à3X|ªÕ(Æ5rcˆí“ªCch³Áó€n']íõ%®$Á÷pÙC$äg´ž/qº–Q„¬{kÐÝy¡	»ä(örïZÔ”*"ILÎÑŒè¹ÐbG. /“!C¡U†�RmÊfB,@�²¼NïÊ;�ÉE–•@’O}64jÂ(æcŠ
+M
J9‚®»˜=¾EMì¥Ç§SëøüªæÊgg� æ·g˜èô\ %#B9%´®©b]cA=Ô
+‹“Û,o2ˆC½³Ò=ÙÖk•/ØØK‘ÕœƒjŸQªÊ„·¨Ãy
+@†Ä¿ØÜôH¢ì’×Z²øPAçGÆKX•©Èë7ÿŒQŒ±f´ý1ÜF-Ùw|¤$»\ÃD¿�‰x¼�	�È€Ñ"õ†t?oånŒFÖÙ»s¤‡V@•RÈ2Sx	�p]½ùö]¼¦ÊCRë
".zî¼å§ð©PGŠŠÔƒ H>öé%WÀD|rÀ©ñËE`…zôGfìí¢t•„9—šÏ¶3Í7„ ir6s¼ŸÏ‹¼Á†(»µ›œM•_Ï^–8%ÃÒÌh<TÏø<G‰& žÕsŠŒ�ï}x4ž"Ø`ñ ã?�70„029t3™aŒh ~Áع‹&ì*ÇcGí\¤Šn
<_‰HB÷nV ^?z^
6~pÈ“!Tþ(Q4Î×"‹>§Üs:�	žlwÇjèQ›–óž…-á’æØŽ¬£öI:(i>
·QÄJé|]ˆgZC—º’¢0'¡Üœó7Á¿�†pyfãÎCûâtˆí&ž?¨Ó[åÏè˜�šç>÷bE‰ÌiòK)¿Oµ…µËÃmžÒÃúÔˆÒÒ³ü}'ð–�ixiªûÂcá‰|^"íÆÅ�>p&Äñ�âüGÚ:[>´ŠX>µlºZ‹ÿZ9Ð[:ž}€Àe�‡Fk;èpO©¿=–�õySɱ¤T‰‚í)Üs<ZvkHJÉ=žEFék
Ê[} ´ÇHeˆ"y0OÍÁJzÍ
4M¬˜×Ír|L_hàüKå[ÃÔéê…ë˜Ùc™ØSF¶Ñ�ò]ö™c(Î=©à=�ñÁîEù©y†øÏ$¸«]K¶ç…­ðšµ¯Ô>m%¾äËï¨OZ¥8!'Ú7�6
ÅuþöÍqCS)	(Ág-˜¾"Ÿmå:�ºWV¶õÇ/ã|ÅÂY¿,F}ØÛu/Ÿˤ°�¨570]ç4�eCØ¢Yøí–²	ó—Z
+JëØ
+{Œ¥�«KqHM+~ÏBO¨Ÿ?oiµxÍ+«7g7[*‰F]4HxD½I·È-÷€ðÚѦîº-v€á*hûT°ž½ g$+ªíá?t�"+<äµ +zÒ´ÊßÇKÙ’«fÍ¡Ù”ø…È^fx—wÝ¡×Ú‘Q!·úwxm$,
ãûùyïìC8@„S+®dtóWÚ³æѶ9ÊN-*h³ÞºE¨‹@­åðòuAIÒØždé°&#t›ÿ	xªÅæQ§„
ó
+9µÝ.Ý
0{Z[Cdiî×É!âOø^)kUIÑh�ä�ëºCiµá{¾ç&KÚéçýoû›ÆîZ—‰ÜËlÓîÔù—6lÂKR:¶;y>ñuju¶�	M¯²á3Ú©*cð!¼cpäï ½¿§$+7æ,ÌŸ; o&ÁÈb�ÓZlÑ~ËwÔ»¤¶”Y¶ˆ~ÂÞÉ)X‡[u­çÌSX‰&©ìÈ-D rÄ-‘7Œ¿îV5Û—nþÙÓž­ÍÔÞš£÷âËì›tŽƒ‚õGQbE�ˆD�>¤*꯴Â[@ÁÖ5Ƥö*>›�9%§úýDHÔy	µff3@h?L;¬îFÂ�ð¡Íϸ/;*s ˆ¯cOåU®BÚ½/âAñ�.k�þÚ	sHFC®Ü¨¬J½¯1þFn^×áöƒ¿¢
WW�)ËNV¹ŸQO‘Âömœi}Ü8åÑñ¶;áî=Ÿ8;2{¶†^ÜóJE9£n(tòx~�˜Jþká)5þ–ÞBʨnŽ8Ʋ>>•m‹jS#®YR«—Í´…Á­‰�Ù\ñGkï¬1_d:mN;ªž‚˜"a’žq€‹©°Ê?ÌÐÄ#ìÕãÙ{½=#Ç™‰¢Òò�¢äè{¶Êl¯=¨çPÒDZÒ‹Ýlļ÷Ù-:ñeD8å=ü*$YTÔO½xÑÜúÜ]µ©ÑÚˆ”I5�ãþ±×©_)ºNÈ3¨6«äµõ«‰Nó"äD1¬ù „®ê0ö°7®<4ö(Ìuæ´SˆQÁ“pR/Á®E©`SŒ^ôÈÅÙ@D‚±ñ–§æxÌä}ú”:»º¶¥uÒpp—§QÿКÓ
+ÒÎ&rs¿:Ÿ°ôåÌ�ÄÜÏV
èy.<Ó!f•ÛËiQØg:0ÖáéãÍs_E©3dΑ¹Ÿ:A=Ë�×8‹´dÍAƒʽïêÛRØ-À×SÄÂ'ãBØ\eá~›"›ÙRrD|©}Ýÿd¯qyIÇð1ó6§µ(‹‚hQCÀÛ#÷œ—é[6ED€ó‹%±˜úÍ<ZL9ÉAÒê“sõ“7\wêm’’¹Ù·—¬˜9ðwב0Êpø¢Ày&NߧBm4D”SD"«4*Èwît�£&ˆÞWÄŠWÈžèHÌËKv3†;a�4¥QoÚ®ÓA.óÎ`L›&<v×2•M\ü;C‰ï!Uê›^e_Å Ú*Ù³ä�_ª¤Ø¶�•ð
+¢á`7
z´|„yð•Ý™íýî�kn:ð˜|—
ý
+ã;[Ȳœ]P¿“ؤ¸›äNßñÕ§Ü
ÿH¬Ù|.´=hÄÎdr †E#†UP�QE^}ÿv€ê¡þ˜(#û¢2ôVÌìôü“£
βÄÏcH®çy³>•q‘óýÁµÚi¦týL6OcG!,çj§eD
­=G83˜ø®eÁ鯑´^4ÒršXýŽ2Nä@È“mï†óD¼ <ÔýÙíŠÎ±6øpv\èÚž”%¦3+è¢W,K…�êÙœçEÛhÃï`vÐyù'5‰$ع$rñ‹’ŸÅ[
+Ý(~®$"·jJZ«ö0V;XÁÖ9àL[ö÷ŽÃ=ú\µ$ÔeKE²¦ë•*VÃ%TÚÓì—£ácÒ㢎¯ô­
�1 6`hÒÀ7>œm¸>/ÿge–‰—�sªè²àÔ2Vú¤yîpwí¡úÜkÆƱg¬¯Ð·ˆ½P…ÊÔÆöÐGWð%!ŽlsŒÒe��£•;‹8Ù1Ëk²àÚ>Ø?Fõ$é;wͺn­æœÌ�^Ü”/˜÷RºñTš„ŽzÇWÒU~WW›G0a–
@8§OQvˆk?UJ_xJ”³&ûˆ#p�;'+ÍUv˜á#9¾}¶Qý•þÇ%ë<"w9>O“d°FT´pü;í�&w°nð-gùo…�ÁŸÒ3íâDã»­;ÖC+Ò¸ïÅf@Ô
+Æ°
+á[xœŒ†÷\KQ}Þ£{ânUÃ{¨ƒÁÅð(¸ixJ
+/ÀÅÜÍôx¢Pt|‚£»ŽPûβJÿ´ÌΧ•Í[…†%®§íßW´¦ú‡Ñá´L±ŒZLys)5œb[vb§�¦ÖKÃB¬ÐüŽÛ|Å2Þ>‚µ¡XÉK©o[rHÔ\ñíq˜²?

�ßyæùíoædÏfN/ÊÎMB-£ÁPˆ,÷#”|¬7a•´“YE8n¤
Hõ¥ ¨ùIHÿD}ž†‘#×Àä:>ƒŒlØ)_Æ1}NšLŠýö]ùNp’›±=’“j	†/Gîr¶Ò£1,Â;c|�6Ž4Õ‘a	'ýq*v¥Ú³§ '|iú‚â®ìL5³ÇI"wè{À,•|XÐì¯/û(3Âö-4Ø—•0dT@N&‚†E|ð4þç.ùiÛÑœÈ1àü[Ò	pJÓT
†šžs;ícñU\�ÂKÁ/m¨@‘§M=ò]“’Jí‚%ë_JXñÒ¹Žìhuó{¨øy¬–z­¼ÍAWô{iaz¢˜š–mŽÜ󺳘;¨2¨/ˆþ/»ÄcÆѶˆäó?™Nû¸°Ü F`® ^å±Z§ô�v»ÜÃR�4êI¯d¸'|ß|ºÐzëÔ%†=-ÉjÅÐÕï¡ó-‡Õ´;ÌXåpMž8Ìæ-�<
+QPÓ-áê“&eÃÜÓªŠ^"q\SVÁkøD÷>©Ìp8ð=·[5<‚K‹	“óç/=¨^ï{"~jhõ^Z	×
+TSõ÷Ò‘òÍ?¡n¢‡	Ì�>bO³3ÙØÈ#wÈVßÊ[½6´Éû‰V˜5xy`ï’ÙFC±èëŠY &�³»ïÙXºÜR>Ñí.Žù’Bpe­Œ ¹Ž•®¶ºÁ¼�ž¾ÖM‡çÃ{‰(Lv¹%Û<ÃDì¼Ù ÑÄ@^m„ï�}
(}屩 A?N'´89�}�¡ãÕ°àahg›ò…NyF=Ø,¨E$ª=ˆ
+‡?wÔ]™{†]°á³Í4jÕâŠ”P)ssW;RëË„‘#•m“>®~F�í&û[¾
+�Êçx™>]ù‘³±”íìÕÄõ3OSF}óÞ�n+QýíPR»Š¦½Ý5­¨VÅÅ ç„þªeh—‡�ÇŠû�Fe]mÿ‚e¤e¤RÕƒÓI¤MQÈ›.·�—~#v‰XÇJ€Ë¦ïu»wgß´»Ù²
+^>íª$¡‚ªN³°jQtˆâ¡'§"»BKº-¯”¬ØfOUÎ51½D:e;…"YE­"^gŽLÖIÜ)Éæ#S|^o´¨/‘feý•á€•‰¶	4ê|¶%ýý
.–î´0¶&Û$LèÐÛýÏk¨MLèOöc«¨ðæ[›L3xÒZsýZ�”Óîd42)wàÐ!É5³ ­%aû+|ã=Ê�.ÜÓ¹3ÜÙ8Þ-	pˆh’•™ž^¿W¯ïEvÃhdBdwü¨øPy�>h†L r%@÷CøÆ#œ(|HD‰ñÝ ¾W6ÀG~ùç+¢m+ç®_#É€'[.ÕF­ öÔ9”f÷iõD
+ÇEE‹S9WM3×!ídòÔmAfoç�õÄmî¦Ð[Òd‘F$ØíRUJt·�äýÀ ÷
+0ê
+‚‚DqÓÚ»uJ‡$m¨Ëâ\5%�wËxƒ�ëá¤ÝŠc×Ãäçò‘ ¾¶Ï
·
+:âP ÉÜgú–ÁÏÛç-R^üÀ#¥w…÷n²Q1šû£ö2ü8
+ßU‰òãTç[Fèš�x],Z·Éðšsðð½Š+šž	ÈS&×9hÁôœp
4mYKØ…Ðl]ë³.)µ~g�RšŽ_•Ÿ(ºë÷˜te“c»¼x„Ÿ×ŽÆ¡â]ôî2xÂÂ4–ÙO®°¤ë梨áq.svÞ}µØüDváð -7—s‹fYn‘iÌŽR0Ö˜Áp§¡G~)!×R%e¼k/“‡£%A0Ê|&á8¬
ºàµo�Œ/t!„ÈÏ$»g¤—«â½Ú'x�Æý+ß=Fœ‘è¦y@õST~£Ì½´,Ò~”B”Ê¥¦µ�|ø2H‹%È_Øò'5Y�h
ÂE8i´ÞÅ ï…Ø)uô_ƒ¯	òÉ`XÇ˶b”ëÈó“Ëã$]TÖHõŒn0F’¯h-òðíìaÝ�ÛR�]ÐÉËæ½PÉ$¯	Ðêm<²ètL?Y=àGWr&`Ðñ°êà8Cº+Úš!xr(<:Ž¶Üº�±‚=6ûP.'…ºŸf
zh?9>^.~-죦ª îêê>.	ó¾_þAC鈮ëø:%cý6{L
™n&¾[™˜â¨†énC–rMÌÒ(	¿Zv›ptúˆ c2{d„q¡D|ýü¢ó䊇•©|„¦3Ì‹ÀŒ¶¹S(·’ÖÿÎV‰Ò‡CýîδÐCM*y]?œeàq1œ®=à¨Ì>xÞd?O-G¼®·²µñ¤ç¿�òºáåÞ¿ï¯ý _ŠS߃Ø#”ÍÝÈÞc³7—½û9˜X'!yf¿ÑìfÝ;ˆg3³Œ0¬`ÛemrG¨^²üzë ÓãÓÉ×e��I’ÚuÓV¨™Wk))5ü÷pÝ3`ÜŠŽâf~€)`â¸ÒÉê¦GñF¬&Ðœ�íçM�ÃD@«UJ¾k¶¦»Öê^ŠdÔ«©ÒmÞ~9OºðQ
†4Â>…£”ÈX>®è8#c
+ÿ^÷É
+ ŽM·«*T$à&N_Òò,j5%
+œì_ØË\ŸŽdµíY|ï—ô(®iÙ˜ï÷_<{‚ßnSéÓ7T³®lpá/Å=[ü][Ë6S[ÑM�¹–3$`êMIuÀØR{,ÅWþ¤”µΖg-ÿqjòIý˜=ßôY÷idᜒÑtR˜)¸zéôªóe;ú�Ot+%«Àã†Ù²ÇÙWË7pž>\¦
ÅxÑÍŸ*L³bæüQÄ'QÛ\˜èõžx˜:S,Q@²úIyîÛIÿ�AË)i^í·’�ê#\>¡²ˆ×k¸ôpÀ/ðânoMe�™3²�ÌB¤ÿÆ]Ò§F¿"Ûà5~·±µÐÇVS´Öþ,&Tqx`•GYú®F/Í	â�å=TЉ�¦ê&Ô%³S¬À#¯]âëI–7•„
+öšû�DG¹_×
óæÕõôðªØtx˜†&ÍRueŠÖï:FŸ‚sy.!À\Ùs‡‡k¯EÁ€Ó•sö«x×CíÕ<©t¹KrgÆ/Y4Žö<KSUGYþúÌôJŠ>•V«‹§K¯€Kb1¸Ž†¤”,M1}}A­ÖW2Œ…á¤ÊùÛ8x¼3tã×Ã3Ï<º›©¼U³GüÖ†¤|D‘�‚ZÚD…ûú÷÷>Ìâ’¾ÃÁÊ:º�Ÿ
ømõA‘ÚõØ'º\ÝöH+Ì»tô¤H�¿€áÖN
ÛstàmœŽ'1LÞd˜Í8¿�Ê!©£l�Äö'`•,áO�›>ÖSÃâ<Ú…Ì¢î±D»Lôyº*mpÐœŸUžâ™Jš:‘¢`6Í؈÷+ÒÜ\ñ2¬aÃUÃ?wéöÛ<ÚÊë4'�ž’!lž¾T§brÖœ-1_/&âXcb®�ÓiÇD8ûæþŽu†åfmk7ÔõvüZ­ÏÅ¢ã|$bŒAnÕ·Íê…¸bQ&¢½ÁRîX[ÂÅѸ¶ ¿øE·Ë¬[oÙ¶žÚ[£Ê«ïÌw>w¦{3ÿD)¯Iÿ#Ó)°Ó'×J‡£ÀŒÏF™¡ã×ö£M÷ß4ÙËáZuT»Ø²n“€9DDt”¾ôb5Û1g8õ!2õ¬j<­è+Íy"
$¬ï¡1!‰ùœ«l_.‰‰´—k3q,7’•ˆ³F÷F¹¡ï_z=F¨ïœ:Gß¿q€*F 
yDÓ³–R�3¡ÞPaZ¥~CRœúsF]ñµ«†,
+áŠD(A~«ÌiðÔ–Eó—1+¥^¨„iyÖ¡dõgVs¥Ý_Çë t\û¥[Vƒ‹¢ ãŸž4Ž«EUwS¦€˜”Í�Æ�µßT÷Ün¯
°"@æs�÷‚Ù¡h B^#ÓÞ€Ý~aG&gta­LÉ	uò§p€ºf¦Î
+ë`H“@$ÕflÕ=nUúÕ5îÙù-�2?—+{žj•ð¡Òj�›W	b�>H°ÿØ…9ŠÌïh‹æv =f÷{fÕüVì:Ç1["rù”SêƒoÑõ¾Ç’€šlOÕ‘äÌ]ªãuƒ0êôXPðkµ»9Ð…Ø:ÿÖ‹\þ±Öãà–{áÍÜÒ#ú}B*Q½‘W¢¢´ž�…tZ…xœêÆ/*ÖV’^oá�?Z‘F
‰Ô�7”:ã
øcj¿?‰z�z1ÿÍ^yãývÍð¿\û0Æò±ŒÄ†]dqá=¤¿@‚Öº›3IoÝûÂ"Ãp™çMLò"–Îw»h=y|+Õ(¹2#g‰DÛkœþUhÉ«ýƒ�h+V2™¹,ÈÎ*MYcœ�´ð¬äOæ~‚ gï.ícfÛè�MM““!TêÕ6ƒ8 
.�ƒ)¡
éU¾ïmS‹"Œ§Ô°5”
L4ûöã¾:‘Oìc
³5hFWG8sË›æs-¡ëûç";÷\¬ã2•„ys8‹×ªlºP²XÎL|¹©‰ü4ÍÞ̯v9êNvsr‰…Â+xCü
>c¯Xç§Ë'��­}ֲ߱ß1TÝçu#ß2çÓ
++¦É¿ìÚÖŠ^Ú®/\—sjÇOŒ¤+G4Õ–¬¨9
+,�Ù°U×g­·ù;ŸÐôl"•R’�uEc°VÁ2^ºBRA4MæÀQ‰ç‰¶·#ÂÊ€ó#Šh­5¾;•b‡§XæD””gX]åF¥"yM�…Y@ÅZ�éxaxÕ49ìÍ|ÑÞŒ>‹Šçââ�D’ü2¼C%4öÿ/ô»�ènÙt§ÄŠeýú2nš±t
=_
~ ¼}RÉ~>Ë »a0¬n.¿Î¥µ#M

HöíTiCÕNjŽØÃsûÖ‘ýaç_ÒÈ£�ÑxF‰“Ô
EG^Èn	Ý=†¨Œr&ª‡C0ŒwCÀ�“`>ÒUÜFæœØXîØ}6ø[·ìfÇ·fíŒz¼–ç‡ñVÉSçä‘¿Ôìi€ÐgoLúº¨6Ut�Y–S
ýS´,�ãþXppjIíWÀž8›‘ÊsÇÞwZ„EyB¦È˜Ê}°w9zÌ^Ù®(ÿ÷ô�ÈЩÛ<KäVÕø>Q/ÚÜ#ï×Ø·¢yû!«oø~Aòô­%“#¹ö÷ƒ¼BzÁ˜»ªŒï?_"’	ë‘Úë?w0
ºŠüvˆ_…¡"=%_U[Œˆ|ð<"á6ìZƒ UcèzA²¿¯5`¢\î~ê×Sù©å¡ïÕšPÄëŠó+™ë�
+1·ð€š2åªvÙz¥›Ž³AfW­æ›îs÷óK—i&ê¯Ózy¿ðƒþ#t°ZÚ)þƒÝ6Ö
+kÈä+>x‡ÅôŸåÞ„PÁ
EEo-B1ЦL¥ŠñãÝÖ›²Ö›ï{ƒÎûZq"Cöá±âši¨èbyÇû[&Èïd_†/
+ÁÑ™i-j´ã/¾fXØü€ßÙ(‡.V’+®¿
²
+½JTàÇÊcŒ†úJ$1³Ù«B«“HûS•°
î{ƒ)E˜ï@Ä|èÈö,›G|8fäUÜêg¾dÊÊSðõÀPÒ”¬^Ÿ¢õ±ûJ#„ÉòvÖœ¶2W¡ýâ­Vø~-…3RüzÌýÝ÷
+3Üdc
×›+°É'�©z8údÆÕù�ÛüÌ[Tòw@ÿŽ¦žÍ�…gM/Ù›ƒéFŽ]á,ˆø½Åžlx+d±‹
9²ðä~OêÌKC†«hMŒú%ÎvkøæþÒ(„¼MW{B%8T Ødaè
Ò…`[Ô¥�Ýy¬CCtt?èhîÑâðïä÷`ãß1>ëÕÙu•î$= ›gSg¸W‚Åw‚¾H�.Þ¬¬_ÕLz£x­÷þç…«ˆ9ú¼Q³:�²sðÖ9v®A%ý˲ùïß¡ãë’!CÒ¶è‰)YXP›Äî­é•1*A‹EöRSîŸùÆš¦ÿ8L?#ºOYI(¬c,F‡n¿ô¤@É«ïE6ÊPdw9^Öäv]
ô%cND·y§;£ÙP™äµQFaØ®›qF?Æh¿µÚëè-Å×›ÞË�#ôý<ë)%™<åàiÙFÏ
+{@[s0Ÿ"¥�²ŽÌdbÔǘ–´EVðMh^±i5q×B2¯^JO
^Ìê£oÜ'‹âØL¥ÆdýT<“ø­ê²fjí7Dµ•	1­X}2†7›€¤c½Bbá/?ãÒIxPp�%‡Œ©SíCÖ…“La2ì‹i½I[«E8Ššå
½¸çÌ Þ@Âî\ǸŸ29SQTw*ÑB1ï¼Ð�å+Uïh®¼Ä¡Ê/þ­‘Cå y[üAôŒŸ#2‰oLú*ÇÇUqQ½
+ó|,šZŠK§ -J˜UÀ·~SsÜ1Á¥Ã3ûtâ’”§ ¿�ømƒQDf"x~ˆîd÷ôM”pr�B!�4¥”N½Ëïb«@äÒë³q
§àάAÃêÕµh�Û„Œ°Ç³8vˆti¤E¥ÌU$ÕƒF#ãlˆè‹2Ž�55JÁÆû
+W—‰ÊGo#�Jܤ±ÐLê yNב]IïðÔfñ+ZMv‡ï7{ä¶Ãê‚øíXºžXäó�½Ý‹`*‹Ò‚
jpj÷´?+›
+|B@†-›&±í
ä5‰tkfÏ?B~½b:%Yñóà6uέ£þ˜”£LA®ªˆðÁëX‹ÀÌWÿªïÏ,Ñoðö»¶ƒ1´†Ö®ûM")ûŠ’8H_Q@)­ÃûÌßj”Yã*Fô&ù2ÙüB‘çÇ.Œ%nåÁ\Û†_ØO˜Aê;)çÓjÙ7 ÊíåÛsoÒ쪰1¯3Yjè@á³fæåE#ÚQÔYï”zpÒáš×,£»e‹\nÆnCþÙPÛöXC­ƒ
+Û .]¿1èf‹Þ$‰V™ÇŒ[óN<š?ÜY ætLçN¢“v} «˜&…yncú(Å:ÉZ£Ÿœî,Õ„wJo ØŸq”é»»2ÛÔŒR⩽(Òue†·¦³‰Â€D…%ô¿Á„Ä	a÷uZG“9ì4éÓ¤uy	Ù¡]&PžàfÌeAÔ>X	õ®pøN·¶±R`ÿläC‰ÚHlÐ$ðô²NæPh7»˜ è›LfŒ¨“ah¿Ïy8
¨ã	q˜ác )ÿ_~1iSÕˆC¢aH
”Ó‰k0zÉæ.@ÉÕ—Rû�“µl‚‘¿R
§´ù½Lý¥tû(Iðd˜î |ëm´ØÿSáB÷ÈVG�:ý†®§DÚƒ?s¼Úö˜ ÎTëýô?ÿ?ˆ¹×”-.��ûdÜ7”ˆì¾.îÐ
+q·
+<Š´yçö{e¯(×6鈔I»îbyö„•ZA„I³ªÙÆç`¼ÏÎS¼^™AáRup:ÓäGW@-!�Äø«ƒèÕßèËs=aË‹Ü'vÉRýl+}¦Á_�¾u0
+Öÿ“^)~ƒpàÕ²ô*²ÿ‰sY:ûyé×6Å€$ŒÝº½Å{‡êÑi×rL#¯(T‹PÆvœ·Qr†¤óVJôk�H0¥rÔIV€«´*$ã®/
+ëÙO³!õx
ÉRdíhÜ!]	úãUK+<7Öœjã�«/ªM;�Ë>ú‘ÕÃ}„ý甂ÜZV
+bù‰æ1�²y†#Ö6yéRØÙ`sßUJ öà‚Hø.ß°›GßôýMŒek�½„¾Ûº¦¥CŽšËž…l^§¿\<…‡6ÂK̹çø$‡’vçÏ
%hf¥Ëm°¥sô	|G'Æ[fûý/Ša¥¬3µrž®gS¬Ê~9^éÈŠSìꦘÏéNÐó	á¢M>À]àpÀ
+䀚Œ5åèÓíöRŠÙRÒ
+�Ì‚StRóùa¼âæøïŸm+ŽÞ¾µ¬¼/†m@”«†fDä)”y â­XDl_`p ˜3‰Õé"p£ ùÓ½r§à‡¬i3N€‚_ø+iÝ‚WQô¥ˆlò÷ÅK¯Ë.XÐ:îîÐ0ûvפ¹,aÑ;‰<e8“z Uö¯ùšÒø\j^íÂÖ"œ‰7	s.G쯸‘U,™Ç‘–ÚUõ
ê…¶,?àE	jÏ2
+K¼BPÒÇ�MÆÍ�Ö�ßx)<¨„Ó«à?j¨¨[âs£
+#!ÕŸ­ÝS‰¾¡Ú±á$j',göbõÓËÍÅ!:Ñi¼|ÓÜîÊûJpÙ‘ýéÞÇœ*ðáˆR7¢O�&½¶$nÄP$sn¢ä+ouu*„Û“A–�’
ã†ò/%£¸¾älÛñËÔk|*“š
HîÀ²äk|ß�m: ÕU¥�Õ6ØŸo£;§h™:Á„tè÷!©N|çÊ?÷`~Y`¶V­G?Ãça}4¨äIßž=6Î,ºJ¥ÀV9uÖ”!þÈjY
A‹¯ÏdJõ�æÕ…2–ÎÊ/«âÖV0ÙF­ì­Œù.}3}ä–Ü&q—ó?xúœ¾˜þsóp¿]×U‡|y
#çjr¶24°E_ôaà´�¢u¨‰C¡^¡Óå’&BŒ‹‚•M}ŽÀÙz) Ü…tMJXŧòŽ©:õCbX(—Ârj´¶45õèÚ{,3¶jòWó0_±Žª
+þ®£¥?]ÄýŽ<ꯞ'°á1ÛÃCÃæKtð(Õ‚Ã'%ÔŸ8“ÓM¼æcûÕz&CA3þ×E®rÒÝ,”BªyK¤åNÉ×%‘/);ÐÖS˧‡v!ï]Àÿ_›ÓdðŒ¶6ýCŠŸTÝçÌôûî*®¥e轜Ódv*LáOhfò�ÕúÓ€oMºÜ¸‡_õxB5(Ceõº%-n„ôVDÆ„ç�™6j®Ž\åoÕ”ƒºB¬çýû[ÝÌ›_œÿr¸HÔ�;6é×ÑðÀ¼�!Çrª¬
±£
+éNÀÐq
„Ê•GÄ`“Ïx]SJãõ_�ê»G1ÁmÃðé²]„5½R)%hÃ+Ñ]
+we:‰¢}‡”ëâ.ðUöÉ›±-ÏÒõwKP–ŒxÊÙl×Ê´	Õ®Hi¸®Àð”á6Ãìؼyn¼
+#"±91cÓ…†5BZÌ¡UQ}‚Û’á“ÓiþçáœBpØ÷�=:¸Œ=ĪÈÃýïVƒ®Ì¾‡¡¤ã<Å‘J*=
ó2",^†B;TË}Ç\å€S ´rV„-ã•£‘c?5ä圣9zL�’ž1dpAP³¡Ÿ63—ó[%Ò
MD´j&z\%djÕ2žS)Ü‚í:c�ExòCU}SÄ\ºáz&¶ð,GÂ{k�˳
Ô:•³D"¸
²„?.¤V5’0_‚Üö»Hñ´é¦Èݼ+ÙŽÚñ#ü™ëÊ°øm;•HP^vø+ˆoo|ú²®Ë7¨õ$0‚b…çþç<nhœBmWf¡Áy°+‘›¸Uë«Ð-‘�±ôwhÒýi‰
›õž+æ/Ã={W¬ÎZ�ð|,'‘¿ó#hQlÍüyïírT¶Ô‰ƒ"~1]¹²?::·ç3ÝÛ¨wÎC
+Òð�š¦}dÔF\•È]Œ9@òµñ…¿[¡Ô´]z›»•K½Ÿ³™µŸ Pù
+‚Ï€oD‚¯õ!ä]OZg*µ@D©(ú¢é¯NVÓX.ò_šï�¾Ü@Üú$4Ü"_=‚1«qÓTnÌhž¹ÈuÑRý
+Ç�‰
»•ª nÀC›žFåÔã€ë(RX¦ðròÚ…ïØÈzš¹]3èm8Y)HRï˜*w;6ü-$9Ô7ÈbVu|sÀùñ¯ªã°}¨$\ˆ%¼®ËDq–îÑAÃ÷Ð&8Ýß«ñ¨Âµ”(Æo™­;Z{ŠrA	y¤÷>[€Äß‘yO(³ÿ®™3hwr粂ˆ¢†;D¾J#Hù]øÝ/˜[>@çÆŒt.<‘I×S=RÌZ`Ï3Uó%ÖÑõ,Á>!ßÀÄt$9·žÒ›Q6óâ‚:ÕEðµ$î£?u&ÌIßIUŒûÍÛÜ¡½Àý—#û&y-
+tkR¦� ÍûÀVùŒ 
++Eª0»¹§�“Í3M‡rN?ZeÜÔhSžK½c#B¯š`”Ž+ÞÁ?í@žâM¹ÓØ%qndzF¯ðIÏE8ú£ÖÚ¥dó½ëH’›Tz]¾7]37Ô—ãß?2œœÕ˜`‹Óý5ŒVY7Žâv‡ébŸ
+2ã$5nµD錥öI …5;£·‘³â¥œš½œ¹ÎœI—¼ŠP¶–z¬{çÙÏšÐQÅhÆ-	[/µ/þ%Á4¾Ù^—a‚ªßvè¨1�¡x™6LÚëI –œ©n¾4âzEÍçõ3ù¬�ßÇÖ%r—±(×Ù[!yŒk»¬Fy›˜µ›e5k
WâìŒ(¯(j¶Y9›oæÔjCBçO›ƒ±æä9?}0‹ÀÃÒéstQ Óútƒy QÆä*¥[	~R¨[E†¼Íx#è{¬=�6OKâ#s‚{oq“7�ë­[›¹<nÃœ!é“q’§€
%ã¼ ×$21Ó‚åûˆY£®ƒ;YÕjįb§E»iœs'hœüÓò
+xá¢,FÅ×V¢u=;”ZØn†•îµ"ÊÖÔêvÐ
¡Õ›¶õÝäa®r¿=Ia‰›qììY˜f ‚¤H¸¸ÃซqõÛ#ø¢tÞDײØ)b»„
+•±ÒAëågѪ‡Öö-Ñ©3	…
+iâwˆ]SwC''/ˆŽ‰~ðs
+
+ñ 8þ~|²oßÅ3ôv<*gÅײî_ÈŠZœ�ëÁ
+jf
«ÕIˆ7ÛÑt":¤Ê˜f÷ºá|¥Ýn«8ËiòÙºi=7"*ÆZ÷T…½ƒ Jœ[É©L~
¯ä÷úxô|×ôjƒsm #ƒ�Ymèu#Œì .¨lÝPXUòÑ,‹÷âÐysËÓJàläy¨›Èß¾gVmè|Yɺ™IÎo
ÆÙ¥Ã}xªhx R§ªœØD"áíñmóC/·Û]Ë#ìß’œ|rÝB>ý†›Ýe‚gظ%ÛâÂ�¥FK#¼Ü
+VKëÏ°@öMêhµÕ{í�Ó«k
+ýñWÖÍ�¸uòóɃ�É�‹,In“„È ÷úÏh¬Záßrž×wç3÷¡nã)8FÕ°=ÀËÈS¬�‡5÷*ÎoÕ`!Ú\:âÀÉGà�b¸ØÖ:*™°Wɬ)÷Ðõ�áñµ.Åzxï¶Q+u
+ßo�ÕüŠèg|)¢Ý”+媀B}lzr}/LŸè×Z
+	¸Ä¦~Vyg²åŒ¡°uÆJ°Ê×´fM-€8¥K¬Ÿ«äCËš,J½|šj_6R#/&]ää�æ|e@¸(óã#š'ò{�Ì¿’˜qå »|ð¹L¹¹j
+
+0ís¬¦¬×&0/¾Ét‹ÕŸóëå;”Û9t;ÎÑÛ¶niaóÀvñ~¶"‘_ŒNëÁÚGM]	Ñ#·8-z;aaZJpÙ ½k�š
+²°׳^Kè„…žåÖ#Ö »*0N” u ^8~=“²BÑóCŒüÛr/CÎà-À;0|ûÇ£‡gÊÒMNÄéa`œËßwª@É#—0ñŸ}Åà¦Åÿ“[Ž5^3H¸>x«0Ò"†„TÛp»
+ÓhÙ$ål$zQœ€ì=´ö‚1d–®�ÓÃû"sx(Ú*1¨ø¶z,ˆÒ'݇v!²§ðI1Õ�΃ñ�¦©»g [ÞC¡ç1Q1SÑÄl»Iz_TŸÊé–Éü¢Í«¹>Ð¥Gâ­�È…¬oa¦Ý—ÞëZ¼êɬÿDW•¸¼‹Uô‰ù;VtWí½ªŒä´p€4oUû¤I67Â]¯KÃ%µôN”ph»ÈØO{Viï‡
•ÂÔF�ìË¿ú°È‹!”éH8-“¨š
+:B‡ŒlŽgú‚2ºaÒ"¦¹?|  ÿ¢
t+�ë+ˆùR–~h
,“Ø‚_s
+h<…È™¸gßW ¯@Wç™áÜ;_y"ÙCü	:mM`¢= ã;òtçÊXÈê
~Ô“'–6Ç3mœÄAÛ�÷1­Á¦±ÙMæŽW‰¡Þ®jjÚÔ2ä,Êb¡¦³ÿÊ<)yh+oÕQÑv‘j—3¦‘„å&‰
+ÃGÖÏ:¾åîø§¡û­2M.ˆºD7–c ùWkx6Š„N+§Ls£ÙȶVaŽkŸÓÜ	ø�œy#‡-ôØ¢xofiRTÚ´µlQNí¸ÙÕULÓ‚Mæ&ò“2ç‚‹D‡u£®�#}J¡4×pÚ4e�mØ
+ÖVxæ]"ÊÕ=�¤¿Ëós÷ç~ÿ—41‚ó
�¸%ÊO:F§£43†Y\ô¹³*lT¶Š‚Tò3®�³¡Ž¨Å°¸n«¼AoœsíêrO¼±¶5åd­�1
¢~ìËQ¢¸¾»Æ)56(ù×ÖÂ<ìÖåZ‰G¬LQ„pyC¯gŠ÷�).è1 οy™ëßá�ÖO–‚\7ŒTQ|§uÎC†wv#†ææ¤MÊØrÌ\÷˜›d†À��¡f¤Æ1`ˆ×J8>ùÔ~ÐõÔ&­Ø`Y£Í˜¡cç?›2¡e‰ð D/Ô(–+ÉP×½L-Í�až
+Z¦Ûæûa„Ék6kUqèL£%hp—´rÛ° ÍèE–r:-ÃdÆÊHP:ì‡2;P®…ÓêF{Ư<Q,JšãÁ~	+¡h[ÅRN]~�¾…L„ÁßïüÉíä-—Ù¥ìŸ
+»áY€»}€cù‡Câˤêðq£þ¤ÂeSê]èûgÚò6\LÀž/*X«–Ü>ДÏ@ÏœüO©ªtºG©÷Ž’4Å%ü’Y×ÞöPðüid‘˃8LÖU/p�„h[×ÿ1õ˜åô×îE¥JP(òCˆ¤‚§t¢8ꜧÝÎQ‹‚j%U×¼±†ÙŸJXµ¿LF-.=5†Oí~Ñ
+\jË9gWØÅ."FˆmßÝÔÇ‘ÓßAÌõ|ˆWj
p7MÐ"Kc20ȧåOh]9J°F®×Ò‡õíTNì)mC\Rà‰æ8
èÄ�З|-	µÂ¸ÅæßËlÏB@\�ë®4Ʋó˜•k™_̦CÍö˜T!Ô½\!ƒÂD×$×&miÀ槻ÁLÝ¢»?a�|ÿ¤þë™ú*$÷¼66ÛëðÞºR¨p`N‹8¹Îs©2õóŸÉ×®aLç%¢)K–9CJN
+iÿót:ùÃûxxñÍš6ïÛ÷ÄKZ·ÏlŽ¸ŠŒbd|Oá±–kË¥þÎÏB�™E‹¤»
+èlLäšOnRZ~‡î&I°=w¦}æ‰l§b””Î÷g Å�TÍ‘ûûÁ{Ë1LxméÌ­�?b†‘Ü€±%Öé]¶çÛ'$5ˆç
}~Ü‹{Á47
ŒCS
+endobj
+682 0 obj <<
+/Type /Font
+/Subtype /Type1
+/Encoding 1921 0 R
+/FirstChar 2
+/LastChar 216
+/Widths 1935 0 R
+/BaseFont /IOQPXG+URWPalladioL-Roma
+/FontDescriptor 680 0 R
+>> endobj
+680 0 obj <<
+/Ascent 715
+/CapHeight 680
+/Descent -282
+/FontName /IOQPXG+URWPalladioL-Roma
+/ItalicAngle 0
+/StemV 84
+/XHeight 469
+/FontBBox [-166 -283 1021 943]
+/Flags 4
+/CharSet (/fi/fl/exclam/numbersign/dollar/percent/quoteright/parenleft/parenright/asterisk/plus/comma/hyphen/period/slash/zero/one/two/three/four/five/six/seven/eight/nine/colon/semicolon/equal/question/at/A/B/C/D/E/F/G/H/I/J/K/L/M/N/O/P/Q/R/S/T/U/V/W/X/Y/Z/bracketleft/bracketright/quoteleft/a/b/c/d/e/f/g/h/i/j/k/l/m/n/o/p/q/r/s/t/u/v/w/x/y/z/circumflex/quotedblright/emdash/Oslash)
+/FontFile 681 0 R
+>> endobj
+1935 0 obj
+[605 608 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 278 0 500 500 840 0 278 333 333 389 606 250 333 250 606 500 500 500 500 500 500 500 500 500 500 250 250 0 606 0 444 747 778 611 709 774 611 556 763 832 337 333 726 611 946 831 786 604 786 668 525 613 778 722 1000 667 667 667 333 0 333 0 0 278 500 553 444 611 479 333 556 582 291 234 556 291 883 582 546 601 560 395 424 326 603 565 834 516 556 500 0 0 0 0 0 0 0 0 0 0 0 0 0 333 0 0 0 0 0 0 0 0 0 0 0 500 0 0 1000 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 833 ]
+endobj
+657 0 obj <<
+/Length1 1614
+/Length2 24766
+/Length3 532
+/Length 25647     
+/Filter /FlateDecode
+>>
+stream
+xÚ¬zS�m]³eÙ¶]uʶmÛ¶mÛö)Û¶mÛæ)ó”«ëû¯:n÷S÷}Xkfæ92GÎ{G,RBy%
c;CQ;[gZzNE5ykkc;iA;kc‚3)©�£‰�³…�­°�³	'�š‰1�°‰
##
)���½‡£…™¹3
ùõYþ	!0ôøÏÏN'3[²ŸWk;{[çˆÿç�J&&Îæ&¦Ö&Brò²bäb²*b&¶&ŽÖò.†ÖFÒF&¶N&¦vŽÖÿ¶ 0²³5¶ø§4'Ú,
''{#‹Ÿm&îF&öÿ¸¨	ìMm,œœ~Þ	,œÌ
l�zàlG`akdíbü�»©Ý¿Ù;ÚýDØüø~Àä휜�Œ-ì�	~²Ê‹þOgsçr;Yü¸	ìL"�íŒ\þ)é_¾˜¯³�…­�³‰»ó?¹MŒ-œì­
<~rÿ€Ù;Zü‹†‹“…­Ù1 &p413p4¶6qrú�ùÁþ§;ÿU'ÁÿV½�½½µÇ¿vÛý+ê?9X8;™X›ÒB10þä4rþÉmfaE÷ϨHØšÚ0Ðÿ›ÝØÅþ?|®&Žÿjù?3CñCÂÀØÎÖÚƒÀØÄŠNÖÎù'%
ùÿ›Ê´ÿs"ÿHü?"ðÿˆ¼ÿâþw�þ·Cüÿ{žÿ;´¨‹µµ¬��É¿6üÇC MðÏ%óØXX{üßÂÿ{¤šÉ¿qü¿¡H8ü4BÀÖìGzZú3Z8‰Z¸›Ë[8™˜Xÿté_v[cGk[“5ÿÕHzúÿæS6·0²²ý§í,ÿæ2±5þïÔúq:qU

ªÿóFýWœü�òÎÊö?Ôþ½;ãÿ\üƒ"(hçNàEÃÀÂH@ÃDÏðsà~øp0±øü_2þˆá¿Ö2ÎŽîZ?eÿìü§øþk¥óß`Dl�ìŒÿ™%g[ãŸñúOÃ?n#GÇUÿuâŠþ�õ¿ÝÄÄÝÄj}ÅΈ+Ø2ýw†szîÈ”°Ö@ðHˆ}i£rQ��]¯_zøG¥þGmmÓçW»ÇòûÏ#IÊã±>4ë_½©&×ù8>ÄýˆÛd�lTÇ�tº¥°jÑ^7KÒ» š¬ôªÇûS
+Šº%`¸3�LŽ7)ü‰]üQHžíá|�ÒâP»š
+ÿ\�%�ý}þ54>:2Ü{Ú„M•IÊå
+Kåï�ƒÍ§©R!RÕDzÝžeÌ}øØ"œ³\ʤ!g?5íµ	Îk“T$f}QìŒ}}œ7Ãë–aI­zQ£Ø`�{1®ËÊ›¡9sõ‰ór5úË<#¤=ø…ˆ´±36…è4Ó+òŽÇ¾a‘Ïp:‰é"“|:[5P6“Ó<M`IÍÍÍLÕ‘˜‡‰ŠŒDa_gÁ¡Ãœá½]é–§	9ç8sêÓšÆô e¬bô:miØ*N±«z|+hytHOÛV77Ùa‰
+×Nä&ýâ3­çï²E@\æYzm¾~D9šru]
ƒR¢á×0��u+»Y}Îî+�\·�¤èƒ˜`Ixï|P>½«D¡�;MMM¬:NNIˆ0þŒÞû+âÝzzÜðà\
+Š—€’»qt‰�ÿß)âxô0EBå)¦d4Ôà,Y=2€Ä„ÖÈ=ðK86iÓ·��½µS(ç�óQôx;”ˆwMÒ�Ý\]°Ň„ŒŒÄŽ¸¼'Ž‚ŒHè¬|Ûd@I¹²‘E	
—çê‰xERµÆ[ºª�–ØÞ÷6µt×Ûô”Uâ£ÀíÇÏcí—‡²áŠù¥�t/ëE½Nr…5õƒ‡À}[�ÖvÞbO¿öxî3–^üX³~ݱÚtX”·úbÛ»Ze¦B}Dþ¡¥±{dyÉÞâþÝbæZR4ŠR`s§Ú1w	p˜aºÃVÒ}ŽÔŠ'X7zÉ(S†Å£À¥AKÝÁÆçr&ì椫û\šì‘F­ÆLu×c¶X‡YÈnT<)—l%WªzÈ
+Ì�0Lo”2´“4c×±¢»ò“÷é·%¶œìÔr÷«rOxRæ
@oÑ[#OóÐY„ý‹UՈʼn%?¼H»@yÖÞãLùbùÛ�q÷›c}DNCýŸoìsÑr?áƒÔÝÛóŠJx>æ?¤å‘]ò;ÔHbÓ‘¾tTï¨)Âm"È|Ó\¹¢óCÁ†e`ç'(Ël-zÝÇ.æfì„©ƒ5/Â/‘˜ÅÓSþÃEÞW;mdu‘ýêØ®=)À6li»ÙæüÖEÍX»Æn–ç]6
+Ȇ§yð»Ô™6üÏ2Röv•ŽQvvåôTÂ*¦(?ç)m¶5”OVÀ#8”¦Ú•4áîPñ"!Ýa¶é]\yc™··sãAZPU6gbß+:�*(¥Þ'V­PÜ…¥Û)+#®¦.r�áýô[yÞ]²ÅÕ¦<×µAÅÊ|…ø	Ý&Û¦ÖŒß,`ÄÆ
+\w­wñ0‹²R§ËJ†H®oQSÓâ�(b½,íµ‚9¹/#Ýýo
¹|Êq3d›p+¯º>2£~ìîšzµ´[=1#„ãW*Ža†Æ4õ
+|\4YÍùô\VŽAò¡iÙœÐV
+'Œ†Ý¥ýrˆøœ]E‚ˆó(‚ƒ+c[€Éj‹®¦
Qíä¼_Þâgˆí44U÷“É
;2–×LC
+JOÉÒ4WÑœž:óû\™Ñ™ïÞ!×yÖ\3Ûø=«/Τ€çÞ¸¯æŸ/8ˆÇîc+Š
GI1(yBª5ŠÝ
+ˆÐ÷™êq¥@ûÏ|å�RøíçÒ¨Zqé1#
.²[Â^�%â”(:^ŒD”ÚPØ•/ð
+ÐJºN$†¦ædœÆak¯n¡mk5¼{n
+©.׬nà''2‘î3ˆ2?g‚Ó<ûeZ‘™�a÷­6™'z��OÁt­:ñÕBzÚFÑ£AjÅ6©²}Ôq”‹ðü¬
fŠ™ðaNõRäm€É€e‰aS—š=ø„PD�‹ Å©?Κ-Év“Ü*.ºå„í_óÄpçÂ’EJ-Mn’†´#Îó¿?JýjÌàUàTƒ*
+dªÑ‹ï­M1–7°¤*’±¹+DÞÄZ·íøjâ?å
+”;�çÙß
ëÀÓùÙ—8Ç!‚Kùz.Áøò¯�Xñ€¯ÈHêKŠ\�M(€Á½µBO8 çXE_æsÃYZ·èp6aaLÞ5f(wS;áKéªOÙÓzôx
+Õ§µ÷YÍÛž�—™®Î燸-f: sôqó957ì>\Ç�´¶	¬C½}8$;DPì…eªì¢V¼'­ØíÄ<È“½Ü¾NO(߈]øé¦ÛÅr_[Þ*ʇ¡ÆËÆ<Òx ç˜î®l
+Ä’£×¬÷°zJmp¤0ZgôìuáÜí™ô!F…ªä
Œb“Ð.ƒ‰¢9wØhQÝ+âGùTjx­~wtñ».^jËð‘g&rÖ̹V§
#KÚý®Œ¿çqÑHºö”Å~àlsLÓfH9�áNjn£W4`oÑ£:»Øš^ÀÅK¥ŽÒúƒ
òL9ôlÊ0Û‰B˜ÚÔ#k|yË¢\Ÿ=*XˆÕ<d0 ¢‰úJkáÜ«mµuˆ„‘¯H`Ž6彋EÖùñ�ïùBÅ«�/hüî#Ô^†§ö¬i(]‘×Z]°&�ÈC˜ìö¶ãíöù{Ùj+à€Ú‘ZQ[){Â�¤iZ_Âì“à=Fº(s!:T
KØ;Xž�ZÆ#›DÂ,vÌ4ÐüQD~ô¡²ôå *×BêbŠµÊ´è˜:³�pu þ§þ9rK28]±„»]Êö]– ÌiŽ rÆf§>Ä
 óRi×à¦H~&¸·—ϲSz…€ÕhßÝ0Ö/äH—Ì-Z‘m®Ûû
<€úQ³Õ0zÒבß8r¨tIÏ'Õ`™@*ØÆ®@fÃ&€IѪ¥v%QÏ:®Á:.s&ŸëF­¤ƒQüʸúW	›_!Ò�0sI"A4ªØ¼D×Ä÷¨C!n†Ñðú;+‘Öº{ýŠ÷ÊdÒ”üÝz/1�76ßÆÊê0l®�«ßCヤb£s0 N­÷ä?‰X! ¦œ´Î`ÿ¾‰$ý:Š¾]‘µß«�kw#+‡üåj$P®¶½¬6>žæØñ^70•öKú€ø$ˆ]ïï­�óÝo¸@g\³°G
+9ÅùbW<-—Ô9â�EjRœáÖÚîö©ÝRËâG^ì sJ¬¾bíÇAÂxÙýeØ­ÒæÊ>•¸jÀ ,WÐs
+�ñÝ‹¼I2ˆô|ß{1¦[y#²š‹9ö_ÀSƒæŸ’™fyf+(ý
+K#Îø/÷2ž;¼£§Zç$Êò^Mú½0�)íN(ïó‘µ<‘Š6lþ;9ÅуŸ)Ðæ¦óF}»ºÐ=À¸¶V
Û˜Å/éGŽIÌYW¯µ=·ŒìŶÑ;˜vìbs¯+�YÈý/âwåáNV­&Þ÷¥0óŸ7¯Â$6/	ÈÉa…�Ø藺¢z|£>†²ª
+«Mˆí&/·}�ÎI	Ø%΄%0W¦É·¤¬´{âI\5d§1ÖÙA)£7½¡TDƒÖcÆãM~ÉÛ0l4ÚÔÕÝ„ùäˆ÷)—h7¿d~aùruÖ[l¡F÷è\)ãƒ|<k�z?D	\]ò7ï2¤ÎÐdåÛTª³WdDmI!÷Ï€S‚'#Q~On	)vE6ün¡Öi¢� Ó€(IIŠ?´ëôWÞbÚ¼%­ÂbAP­`6D
+–fçÚïC%ÇÎbl·Å$ûÄÒéæÅÇDÙdÿ
+Ÿýpô¯°0TO@,{i`·Î¶ÍÆ¢ãÚâ×Kܬ	¾�yOàï–<ÀQ–
+ðÕŽ£èÈp¬­°"M¸p‘)š
!
(´Æ[É⯻¹ÑòsŸûùWÅʨBP¨hÙ'“¨¿ÞÞÀOԫøŠ½â{Ë	eÊdëô¹Kx5QªÎ™6!â–­a˦½ë}2 ¨Ýˆð+0ö|3k³Ÿr™eÈ[A˜ýl\ÊŠ}óÃ\&Ñ[Ããóqt“´ú8ûy:µlõUñ®¥"„KЯ¬’Cpeªb•^¶¨¦oÀªs'ª¹þ¯cÙKñ]ùw+VuN|äáù	s.…�¸¦Ÿn ª4—&Ðøš{«î‹½±é
+uW–ÿðžZ—â9«ÞËÛråŠi~Û�0¿<€G<æÀ›3¦?›(íPÒá“~šGÁqFëÝ�ŽíƽHšJ+3"Ê«F…@™'›ñ‡îIŸŒ‰õ‰ZêÀ7Y
+gìзt@Š™+[Ñ3²/*;œ÷Q¿.ønÐDâ]ñê “R£Þ?*ã�]£_×êCék~Á3A¬
+$1üf¡
+‰¾É%|¾Uůx¯¸;%ÒŠƒ}5]åD„¢J›œ)h#?yºâþ-^ø*#G„	Ú”¢‘
üÀÄi;IÑÉ2ç�ŽÌ/~é)Ñu	죯ã3noዯ78]P³]nÃ|¾g
+6ψ6o‘PBšP'̧AFæêdf?P0dGC×´rW›çB¼¼6&³SÊr¥Ü	•¬SS‰ÓòñÞõT9Žú¼K�)Œ\û)°bç¶Õ†3´�$ZÞ#&†×ææjsmÂCf‰àS4XäHFZ”ÔzϘ(Pt
+|ÿÖc2›#á¦$'j‡ß|c›xß3ÃlÞ“”3Bm€Ü9ºš?¨
+LÈJ„5(µ
+S|ØHˆGð—Ã=>ô�ԑʇÞw1®V®Áç€�R=äŽK‚uW—e“	4¤µZ^ öçý†Ï#ÃÎDžâØmwp#ŸT-Œä{Mô§SqêßÑZ!¯È¥û;Åcï¤ág´SƒqÑq/V1aŶõrR€ñùòdfN51©é‹å=túúöp›˜Ùøfqû—
áoœ
+#‘%‘�Ï+0{—¹�Vx³½û³IÏßç@
›A
Öå]d˜± ÜšfÓ
3.ˆ•Lçû^«ªwk
FOpªÍm“é éâKL§.ã¬f0æµ2x‘$âGÈÛ~Í…�†ÙgpèÙzœlŸTêŸß'Ah7‹#m¢(´â'Z	%åÝa
&˜P[&W)íýyÝa
HÄrÇxg+Ešê»ÎÑû ^äŽ(úÖß `–ºr¶jºù7Yþsß›ûPDS"äÊ"pqšQ¦Mê´šsËÚ‰ÉöR' 
)Ú0çöÌzlšºð•`^•¼ßÖ——úq2‹ãqÙ•ÚüŒmÄàðr²ÉEh
+¤á¾}˜D'N+�nš~¯Ðß0’ƒo™¬WOÜs:¡ðwaz;A³cJ©ÚäA çÖûÈ<’+UȯÉCvL¥ºøPô‚Û²sùô*
ze-£Šü;2 «ù«#_š¤£s¾þ vêÄ‹úñe‡Î‡CØ“¨Ï>¼»,æñ’peàùhôm2’ÏÝ°MÍ[®¼¬Ý’‹�÷	€"_o UÅôh£
ÖB57„ý^æÛT'kiWCEÏr§ó•
+©ØWÚ¿\N[Ž”ÀöŒÍ�&nâáµ9vdµÍ¢–£¡!Šã5iAÅ�@ñ/*w.¸Ã(:³›Åå×Î6
îu1Ü3î᪾ûõW¤®48ð“ã‹KÓ^¥3Tòte:ëù`Ë"‰‹º‚p­,»iAX/†HÛ˜?äµÞ)RR«Y?êxjÒ/½)‚P8ñ“—»C>Är–BŒ!†¬gÝ@¯kîÚ“èNü½?DÆF¹U<þ5”I.:´�s¾Ÿj-p“Ã䊰"Ÿ�ªcÂ#Œ:B
�+?/P— wég&åoï�²û×!æ9œa pñ|Š®¥Þ²K5lïøŠÑ9„CF	†ºž/õ¬;¿G@!íxc|ȹD¤.׎n^H$ßÄÛÂÓq]Èõ+É{¸i™’
+“*ÅûÖ€H-eëpg,eƒ|ÍaJtžŒ/d�Œú*Λ¢6ºK2;”‹x'.QŸ[å Ì�ñÚ:ŸÄTß$$¯µ“Í¥¤·4UA
+~:Š0NÇŽŸÂy¨r“Ñ$85¿Aš«`!¨WÄF'*nNÁbt*Ú*¼ëë�Âæ;ŠEôû”ÕaÇòõT~ÔÖ“S4Ÿò3<5×Ø\ÛJ´Æß&æ–“O=P©[¨P$“Óµãñ€èiªš_`Ž.Šó{h/"•"v¥¯CŸ)-FßE¶ÛA<ÝïKF‡�é9	‚'ýøa¢4*$'=ÝèOáequGf0[éÒ´ò¢ïÑÞ7™Ë©4€ÐóØxâ%%Ì:¼ã/º.@ªã#)NˆÈÌaÀSt–k	�’»´jˆ5b;¦¿J;÷Ò±C°7·ä°ƒÂKŒwA¹5S‚é%8.nN`ºê9_Žû�¡ôÓ;Sæüê\g|¢�Häae#§û×çÛu¦�;¯ºÖÈÊXšŠäo+7×m4”°‹ª0Ýë#4åâ8�hù‚˜RË9«�»åì{°S©ã£›�ªˆ¿z� rª“ÊûýÎœ•VØÖi�!z_)�õ¸¨VS[i²sõq£Ë%®µe?åw«ìbØ-…97Á �|Êš
	aü’Þ[
+4%Å5k£½02ƒ�Áw¿b¶8y<•«ápÁÒ*Á–È��p«¯
,”&«‚rÃæG€Tëƒç¦£¤å¿”X{Š”ùH;_
ÕZ ¼ë/i)ï1Èû£.5n仯ðå9
=)ÂéÌW%^}@|Ѧ{P`Áíea°,pS L§Ü”üÚ®Û7CÖÄbÀtÝzÏ3$rX§5Ø¢Pü–„˜jW~\\{	7NìySE¼9
]ºž½"„i5¿ÓúÅXôxBää\„“y”\á¼¼!‡k(MÂÖL]*/öðéžä§�FJ{Y<Á&eš¯lõ‰Ïƒï…Ì‚+üŽŠ<Ù@9vOŽ�’¤ä[RY·ZßUM�Zûp4–DagPcZ‚%V_©Þ\;=MåWÛ¾ÖG
+›¶ƒ¯ñ¦¯<¢—h¸E“;Ukê ñ
+J±&éù
雈‹˜9›âÆæZue)äG$ LË#[|íÕϬ4ÈÝÕbO
+€£AÚ¤x8mw›þÖµÔ�„±ßxèÍ#ºaýªU!˜ù´TßN.ÓÙÇ-É™Q‚«iy@ŒWc²8qá/øç ‹ïåqYw'`:ÓN·ˆ=
+*¥6©!bÆ¥$ž)ÈFå¨3Çx=H3/xRÎWGzÊt¡Dc€Ê'ÒHD´öXM-®Áö
páØîÐÌ’!#ŠÅø*ÒÕ	Íè/<Ô¢8>§Ð†ó÷‰rŠeÀìåtѦ’¾Lñp	m…
U?ˆ+
+�½ŽîÏ>¿ÇrøKKíùƒrÍAfjxy‘	^W_ª^ø‘U
ŠäNGReÈ\®v/ÖVö†¶Rú׌hÉýy3˜Œßc¼b'óÑl«ð‘Ä�›k,¢°§ƒ.ˆkx„Kªý( 9×^ÅÈ
+…d«…œ#£}þÂÀÑÜÂG( ÑhQ/Um+‹|“·^±OI$ѸÙ0ãÆVèþ)ÆJ3ÍLJ_ñ·ÿÑLÖ÷¥Ÿn­Þo”vÒJáØêqmìíçâ%�Á­Ãcœ~ªzVÈ�‘søqÕg%ŽQÌ4³æ`£E�–/T�““?§púyÂå[uïлJ÷ödhºHÐÈÜlM�
+Ås?Òr&Fd¿Ä6ë&>N´.Š ¦¾1:¹
rP1ûØ——k¡f)ØdQmŸèÄI BÐä5Mþ¦1T¿`m[;­z!î_µ±=ñp)ä5^Išõ@ÑðÈ
š¢
žAò'tG<ÞÊÁæa¯š�m-mn(Ø
+‰�|¿"]ˆnŸ†GhS”C£ãžä.%^=‰Â	žš| È%ÿÅ%Ÿ/†5¥n�tntI-¿ÊÍÈ.-ÚŠ
+˜4ƒ¿à†tæ-ws(›¢ü	À.}!Ë•™ª^‘ 805D|~ØfÌWŸ½æ°›ã‰Å9ãqÀy[eN ù~TÒ€J…gD›¼à%HõŽN´W¤VêÜ©&QXS²;^Æ#~o ÄSÙÄòQ¯¹Omº¿k�Ê–»{.�
+àé%.@”ØÀÄZPÑ}ú¥ÄÝØÇ<†,2xˆá+„PÀ:І¢€XH‚9É2¯!I‰¥“–mõ놀)Ó
LvÒÀªÊŠ‘¤®­‰ŠI¾ž´ÀJ€-um~5SµÏ?�¼‘ÞËxXkDZÎS§ꊿʥ�'ÿâA“EÈz©Ltª=ø½¿ˆÀ¯’ëÊ›2{@?ï5ºûšõ¨N…&øºòȨŽ3HKãGš‹6hXle¡ïÿ–kMžÍMxßqhìàV…Ú¤ki1IƒË‹ë°ª¶ƒÊ9UFmwY¥YññW>èYM Ð7u
+Ç:ê
hפ�­ߛ֙C9߇¬o“‚/¶z>‡”8Õ"�¬pÔ"8f@xk©óí…f¸®��söšË‚ý(†'ï»Úƒ½pLjt:1[ɘú‚ËHâûŠK¥Q¹ÞAH)†3W.‡å¬ÉüÖÀU7¹þ"ݨ²_mz$(®$åÔ^ÕìÊÆŸ‡EÄÆvPºÄ¤7/'ìl\du#vتç¾½ììÄ“QP‹qH{Ä$5ƒlíÛóyïd? 2$yá9MLºG%[!/J™Í2an¶ÁœÞOz~ØŠ9@5ꎥ;V7Î
F��FsÕàd—ûãת?siÜ5$�$éD_j(¯Ü‡ËOÒðBO¿šq€îôN»#.Æ/8ZëùkVŒè‚¹ép›ÆjÕGpéÎØz
ÇöÛI9´HÓ®"!ÕJˆá«OY¢Úîµ5¤=.J×ø�2yØPK0úÍ�ÙÃPI¼ ÌIñ$GÈ^˜ÆºÌ‚cý%úE˜òï„cijñ¼•9‹ž9Ñ’l{ˆ‰$0¢w¯¡&jjia>’4�\¸	KDÃ{pÊŒ#?ÓAþ0›9°ñ-D>"ª:c?ܺÚ~†‡^e55¸l
+:kb¾ÉLQÒcèâåSŠ�Û€ …l±Ã{Y14¯ŸË#Y‘·IUHš6‰·'&:,q[ÞÀÑçºËÔg+ñA¼dÖ/LŒn”•ÿRÔ
+ˇ—Õøê�MCEýŒw·òÞPðÃ�]ï-¼5L-§Ô²%\ðd*]®K¬qtmpMó¹{Â6Dm1Ð[�2m¢ºûw*QÝd‹Q“÷\ÒBq¶˜™2<ôÜå`ve¹¿�*9GiÐÍ
+ .ÓÐ']ÒÀ^Od°â®D—üå„,?#ÞWÖ³bRªv×èSž¼˜Î§ÁØ$ôÊ`mñ
2D=ón“þ´ÁžD㔹=õk½IPïÅvƒJ<�¨±ÏÞtݘÍZ´G
U^�W0äõ¬’”¤¡ÌšÙ=JéSQŠT#’åOµŸ>]žAß÷åʇȆ³Z!“Œ®Íïå>÷Ô‹fÜ.å�¾Ó;ö§hgXUãÿ‚yXÛ%…6,˜Ä�™T¸«úÊ*1²ö°Ò”"‚ï3Y¶m"ˆ†s¸µÌ·
Rþ;ÕõµU§é±8fŠ•ì0A¾Ç¤‘oxZ¼ÒÀá¸+ÊNVk�ú÷#$ Ë£6\4ŠtóV·‘D^2'lRw‚fÈ2Ñ[£Ø߇`Ÿk5Ñs kÜË·g¤Ãs©	ÛÂÍÝ�ÍŸ¬B?1|k6*yf¡3ñÚP‘|Büu+ÁËNõ8XÄôÈä‘¡ù EUQÊFÿµð¥¸ËôiÔ2¼ð`Næ}ïT´?AËÒiÎâ ú[¼5�¿«-ŠCLÓÇUY$ÐÀéëh¤®WN�ÉJB-þ¾ÜaìÚvvÚT¤‡dŽò[µ>Æ–ø|sÔrèCd `¦Ÿü^†ÕÁÊãDÃ*ã%­ã»ò�ýÏŸ‚«ˆ›ó�ñÚ àfX¡6øvçŽÒ]©Â�—ñV¤M"BÝèù£=&w>8Kº�ä
*¯+–¡oèKᣵ4æx(
=¾$h%H
+£VâRÑ
+ï82Ö&)°"¶E;Ü´”ŤUYvƒÜìVZ9M*­µjQSJ­)‡Ÿï@LH§Ò5Èþ¥
+½~ÒoÍdW)�(Ö€çÜÀæP»€Zø¦ÂP³¢½OU®æ’mèß´¨§raäÓw@„�&7ìVÛÌyå\çøiÃH47�+ù׉L
+µQu-W€»×4~Q.£ÎÐ)ÅÈLHQ-Û(èÖü¥> ø|kúÜ„X`Ž�×¾®º]	#.ëwx+«;.ñml3ÁѪ۰çµs
+:Ê(׸B®Ó'=êû’ýeÅ9,†`óÙ‡{ß%€ª�
¢0<ý}õ¬YâÁ}‹
+ˆ¬BÙp:©Ñx”Mî§�?ó}¢Ø×4¹„“ùïüGßß�aWGÄð«à
+�«1,u6AS�£áx\|czíR¢€oÀbÐ�.P³¦‹Ý=Öö+<µU
ZäÍ&zÐÑÅReu–
+[5Öð�Æê_ka‘¢Þ÷£ø‘*q¥=¡R4Ð/@™jÂHµ0M’$Ùþz„
+˜É¦p8çˆC¡·š•òÏq0ÞSGD¼ÆS
âT2J¹Ôi­¸É½°½äA�	iÎáDµ9)î“>oâÚà�Ђ,®DOͺ؀¢À¨&¯¬±ßŸ“ãùí„í½OÄ[¢:&ßQC—Ýåy�˜1ŸÜ¨^Nò`ϯȌ)†¬!�îÍÓ¤~»,˜7Õ$á/°Ûº¤zé5"™4¾bø–ˆÛM]üè»o~E®5p‰ñðJÌs¨�{•mo�œäÜ%Ö¡A;›<Ñíô¦óñÜý¦�¦@=®Ð@ZR¸ôGv Ö}¬ÇàƒO³þ›§—ÙA´|:÷©‡ž™Ï	@pmðïÑçñ€RÀw<—a°Ý½7#øSBG�8-(v�>	Ûžq<]ù�ÞÚÖÁPdöÙò@JÞâõ•WÑ2|¥ —Ê„s’¨Ê‘i%
Ìî3² °6“NP&0ž>�>ÀI2åOø®¾Ój¬ŠÛ¯)ÒÀŠÜÚJ8¯Öß*fzU;.ÏZÜ$Úùd
+×D½í¤»a£ªâ*¶‰ÂÀÜÙš*û(Œõ¤qÁÃåäÌ°
[¨.xÔŒHhý� {§ú·–æýy�澡:ÔuÓçg¦�¨÷œ4k	ÜÀ�=ñï�El�D+Ž9Ó{û¤Î=£n„ÉÐE:x�ª»n½†í·ô
+é4NÈŠóv É.Õƒ_Þn$`¬ÓÖ)<ËEŠþê°õ�ç@‘q6I„òÝäŽO¦ù¬R²Ôg-£d–‚îAúô>l¿ 3)VÐñ,ÿ²8Änd2€ø»Ì@צÍ*€]ÉãhsÀž”nä¦(ºÎõ§ÕŸW‘ÉÒî#�ÐósD–&�ôؤžm<[ãXp.7ôâ(5%ö‘ì>B8‘�'ÇÏÉÄ-ŽM%f+ùo0à8}¤{+Ãþ/®ò ¡‹pp… ‚óìô½ÙW¬ÒCF8fÎÞßòä6ŽÓ‘æBVÎÒP,-{DÞBЪðß“úé,¢�îN`:¹ ¾ÔŒ/™t>¯‘¾ÀýÝ«9Ñ>á…‡]`5TæÑ’zûvyWX2FüºþbfO–f§>}al÷¨\ÔMê—´ìù¥ìâVPÇsp¥²oøâÇШ›x¨³N
�O_Ž»N=ð£��³§ND˜ÿ«ýzZ¯@(5Ic{Çv³cÛ¶mÛ¶mÛ¶�ƶm»Ñ™w8wóÍz€ÿ~eŸYçÞ*D+_—‚#ioÛçT¢{?ØÏ|Xž!ÃS)Ëb×ß[ñ_ˆ
+ï%,3”1•äœJñÙwG¯üûñšøoeüªyDhéNÁÁϹݎÓR
þ ~¯›GßB‚\ÌŽ™;؆r•R-ŸEGT±ùø°ãѶ÷�Žz ‡¤/z”Þ‰…3¿µf!KÜt[¢áqQ‰(¤Õþˆg§þ¬EÒudV;~_€dr‡çI;17a£ƒžq”„)b±¿²‡s(…0
+IfLt´&
+¸Õ‰]ª¼ÖÀ·ü´¨ˆúWÓž•N€ÓáÚ îËè ¥·I­Ñ—Øü:k
b-F”ÛÈØyŒÔLúcÙY>#S·ÿý�¢žæãþx5
+ŽsU	? ë{x[òq=4£øŠÉTñ�ñbEK'òmç±v�§9ˆçì‘È�$“CXcþ©\“±>ÊG˜m@>¥¼lX1
©ô¸dwO	�AþŠEÒÖ’±Sc¸I/cK+–5>¶V‘+"zg
+*»åMì•¡p_ÐV—+}¤ªÞ�TžY!�æĹ(K§i�"üÇ(*wOzŒF®¯’«X`Ž¡ÿ­Š�¢É
+™*r[¶Â—n³î+ˆm•€Î
êËÜun2qÄi"P6h£.ü·T”•OdÉ_ùüånµ~ ‡q#$i5’2Íçš�uÛOÖL[˱ÙE¶IkQñßå:¢_é²w«®º!É·Õ7ˬÞýóÌlÒλª>	^ØH•€
þfuĶgŽÍÆm4N}Ò
+žº²Ü�à9UwgÒBkÙãƒËÚž½Gr˜�u)Ôë
+èòÔAé›ðöÖ_ß5Xuïwo%~’KG`4÷B9MXÄ—›Ý*¬â=cÉwú¦¶­r±¼§˜½ïÙÌèÀXmgsÌ{ná>³.ëÀS±¾ü¾ºÈÙ”¦ŠQ®�Ÿ6È4ȤÍzÚ9Ú—¦Å÷K\
ìkCì«›!ê;àú¸èy¢Å
+	
+"¿‘©ÜŒ˜%�(–PL•„�àà�}çô—ìd¸A�4HVs_™c‚Ò„µÜÅ‘nÜŠ¡V�z*-‰To­”�â7*úï	#{y‚íl¤â:n\Æ�>‡áos.ø¨ŠsýE×õ©É¡Ã<äm¶E±¸@ˆ�x²îkrŸËÁ}G=1ôƒNl.&·´Mf‰2À4îۯ0ö€6Ñð
�G¥í¤B§R“Bt•¯º%õĪÜ~ç$`XÞ(ÿ¶ˆphíÒ[,	²�·wÄ.„ˆØeæÒ$HÃù”±åá<€;]vÛàr Öù›–ÞpuU“J¯Ð�œA£½<�ÚÓ¤ïõV1r¿Â¥“e8Õè7Þ)h(²¼Eð¥GðЖ„ñ˜WÒMæ	_Y£õ‡æÒËfcØŠ�¡ÌõCÒ0—£Û²u—§§äùp3¦~ùÌ[yÔ5!Áy˜Ý Ð-¹9¨ÉŠ%�Q-}/DšC¦—jn¦%>HLgùh:âî…¶Bldš½üuô݈°½‹IÖ#o½¿ùði9žìtå‰ò2¯̉ê³æÖ®Ê2VÂ^­.îÔ
+ëÿ8±²
+òo·�ĉè8²{ãqÍED§G×æë±ÆöåÜbùÜß°”\&Ü�‘ù­òÏ2qsÈÆ°Ûy¾�>bò´ÌOX(oÁYÓ‹Þ"4Ù†w�7«~Lé'ƒ]‰v }Oä8ÝMª)Ž�–X’�EÀ,3bQ*ÞWAš0 N5<_8%)FľJVßr”[‰=Wÿ:¯&,o/ÑQƒ�+"%N†êémü‡*VtŸ_-’È°”´sPàkX‹'ÙÊ‘FâbMüzyixû�ŸGG1SÝ(&¦F›Å8'Ç
+mÁR!/¤ïmYz'Úò”¦ÀÀh'¨1I	ÌѨ�õéI¹;b’@\Öq×Ü[¤µ*ý�ôF£½™ÃØ»ÚRqõ¶›0ý×nD%ŒãßÉ€¦]:bĨvÿŽ“U®ïqî{Ĥ
+Èù#†ð÷†(£ÃÐw¾áR¼­ñ¿ø;	h@À‘Ä8~©Lp©™¦¿RÒtª3ª5/0Ò¡S0±nÍ&9=Ó ÷-Áz;¢Ir�H©3©Òpdl²l[‹}B¿p“šÌN2ùòw
Д˜…¥Uh�pO· 
+FÖ—bowÖç'<{†Ëe/>w¤ìºO Óyf4,%[n‹¦ó<ÑȲ’Dø¯7XQ`õì¹;ðkgýÑt{D¯VC|n$è_
+5±)Ä;À†íkPAs~6wD¦l¹Y²˜'À&>)Ž:•„ΊÙtAÊ�˜xñI…Å©Ñ’"Vï�·´—Á}“Ôl—Üœ2Ê?«RÙª¦»�
Ñ2ø¡†LŠ¶Ð*¥ÕùÏ•Õz¢W¯íPO!Zñšâ:¡••3ìv{´3:9¨;8
~†»Gcã–XÇ*ؾƔrõFÉ×<ͤŸ”WSs¤ù€ûñúóRXÙlN|PLò4ŠÒñ£l8¯´Àøî[ë†4 Àñɽ.zšcF­{ý†ÄT¢¸ˆŽ¾�‘Ð
[™(�)ä ‡¦f¾ÆF£ðÝ
´Z"gº…´>Ôæ5âµlÏ
â,¥÷y”¦Ä“1Êe]#¾{Gš!ÓK±¾„OÍ÷¢ü¤ïï!Œ^{ßðÉ‘F'U0BBo÷LÉ7„ob�¨AÏqØ5ƒ£&ÜçîYd5K­ÜeíO%:Ó
6™zD�-߹̫\šM0
+¯'l­Õ_‡2›.vèKâÔ€fïø¯âˆÚ\ŸÙÊ
¡òËà.¶¸iAìU„‹Åss*’ñªÛ
+ó
Ë.ºÞJy'k<¬¾T¨u®rï
p¦±2Äé�yš˜¾Á0^øÓí ›Hv,¥wó!éùž1�ÄVûr#Âp_JI´¿4ŽÎ¸6ú˘ì{2{ã•
<[—)¾Íj°xÔo~y‘S¿mäó¼—¯ùh§NWp¡Q2¬ð‚‰>÷ËgCX ÀõVUé³½æ·ÝbM†Ðñù6 kh*†4¬†	·ÚTã’#­Ò<÷òwHÜ�2ÈAœS¼WR¬v"«¡™Ô1í2•¢¨¡;ŽÞuE@L
±Âà‘Œ”ª^4þÕŒl«áÇü̺-€¾¨“\Z™�Òçtä %p´§”î–©ÚËj�Kûr¦ä¦¥Æ¢[~ÕÇÆ
+eÁ½õiÐGÓ8¿ÙñCÊI´‚¥º]u¯˜Ôjù -JtáBÊk(W
I�)Í’ˆÇ ¨�kFîÈ�Ji…ÕFS„Éãâ…—¹l;£—¬(¯cgHÖ5§ýUj®¦›¤ÞNX*1a"˜…J[å?x¯5Mï@ 7‰íɳ't"
Mrmc
§Õnœ€rÍÖÔ<.ïo°öÝｦk¶åÎM¾×ÅŸ“p40¶Y¤ÉçŠÀ^s ëµ¬d>Rõ~YîZ_Ä둹v0§Gm‡‡N®3çï7G$*›½th•ëù�ý¹¡Òg)ˆ,&ƒM€¶ïÎ3«yÔ&o¹Ù›ïu–ž4«ô,öZÎOkÜ÷ªÔD%«†Déz¡v?ò‡/óÀ;�Š'?§îºËcšý‹Üè
+µ(à\èaª
+E‰7jŨi¥oòƒŒ:½úþ·cêSJo*>»u+Æ#@Ä«áb\[k!s&D “‹Ãd`È<HØò†T¦EÚdò:±CíkE
+j!H·îà3ÁE.
+ ø!{mž/ƒòZú+p%Œ«u–}Fcí¿èýˆ/ì…Ƶ1>§ÌM)ÔÐ	O�%Sýù8½î×Ç
+dˆü�r4îŠ$#œ™/à·Ñw$–+3¸]Ì„5¼T87Å]ý—‰Ø¥–…ZPŽü¢
X¥Ì[šÿ8™XpÉþCi€ó`KpmMƒ*­y¨À&ÕÇ*é\—l¹ïˆü°xr#L?)¨ù¹kvü¯â|V{þ–aÀB$ÇÉÎàj�`ñh›Îëæîõ­QUd�j5Ë$k>7¦|©™¬âÃöõÚ¾¤,ˆÇSÎbÎ=¯	6¢ŽIÛž‚2üúð?÷ò)CÎ|æ¡î0)uktùþîo#‘Æ�$÷s‡³Wgª~„ŸÙñôÀԥ;º�aâlèQÌãæƒhË›ƒÌð`
+Z®§Ñœ8Îeä¾ÏFþ±Ã,ô\5ˆI.èÑaM
4Ž´mÇÕ‹èqWM‘±•î·egcØøí
«\[þT
+¿Á…æËU¨—xÙLDÞsäÓš
+Iö×~pºóE¦f}^!˜tQ°Ù’‹ƒEäì>‰ n|'ÆV²5D9_äå‹7â̬FJvõ˜2È­ÛŒ’ý;Û£K¿>Z&ú‰Àš¤þØɉ,-¯,Yت–=–ÏÞáÆX8?�¸#…m èÓð¥žçßèðž–u¤<5åÑwÒ6¨´Í�Ô™­×#0±q“²Qý‰±ÀåÙëã=¥—;1Â&<
+| fÉg¬,=‘¥vp‘�·xMŒé‰_b¬5
+µœóû¿ µ§öÈ4¿À#è¸?§ß7LíXʳŒ”ñkÌ€Zî»vSLR‡û
4ƒ?&4=cwÓ™7mÿ­8 ‡L¡ž~šËmé0Rƒù]N9ÄO:;e0vÈ(©6‘÷ôŒ÷ÃæÓ=Ô
èÖ‡7œŠ?­)Í'á ž	àÇ38ƬpYBà³Â|ƾC¬D?ÖD‡§-QÊ(6ò˜¤>Œö)€*#£˜ò�DUdùªé³ÓvU
+[`÷QìÿY¨OÖØJæÒ2‹„a¤.‡yMÙB.½T›.¡
+¥í’bWW�ž^¿§M?¼ªßªéë;ëš<™áh ±Kñŵž¢¨ÚÆóV1îcÖOÏ"ž³x4tÅ:l�¼t@i×uÅ«»‡‹Á0“ö�ë]RϺM'Ü>Á™?#ÉABlž=fÌì…
ïé ÚiózõÔ¨¿!…+°2Ô’Ýzôµ¥Îb—B
+y‘üP'càÜ^M#R°·ñÃ4
{LJB«œ»×ën¾HïŸMc–9|þ*S5ïV®ñKãÁ“ü�vÚJ¦‰‡’à°áR‹ÁPKw©ä;ÉͳðåH-ºOÖ²ÉâØÉ*Wü—¼éýšö•p…+èó®a7AÔºº;˜âR·~4ÿÕ|S®‘mƒ®W•~	©Ãâ‡}DL×WF5J‰åéØ|¨i÷>#\2®˜
+šÒ30D”€`Ÿ†§¾ç�4}&1xÒ¤Ö¥	ÎdP•Ý‹$ȾCO‡Ù’jÛvëö?`C&W'aÔCJ•I'sŠFðìM˼k©¡¨»°+X	ŠcAÐÀ«á¥£ùr!<s%!ÈbˆÀNÑ*d3³Ê6�†Ø0´+3ïÍNYÀ8�îj•ÛP³7Þ¨VäÎc=$0€Ž9€òõ
«£…WCÒ¸1å
Ô²9L±ž±~óŸ–äWÚyüInÐäöÀ'¼I3
ú]`+ò7vÃÝ!�’ÔËö—k«Zœ–(&4¨j�„¸`é+àpôxÿÅë«SüWâ$åM7ƒ[IZÒýš®ê~‚VƒÍ:Ø\é«…Œ
€Øy_à£öý
+.ÈëÃ6‹û¯™ÅSßcŽ¾Q&É5	fd
+ön’“,6"”@K;\ÿŸÁüø¯
+endobj
+658 0 obj <<
+/Type /Font
+/Subtype /Type1
+/Encoding 1921 0 R
+/FirstChar 2
+/LastChar 151
+/Widths 1936 0 R
+/BaseFont /HVUUYY+URWPalladioL-Bold
+/FontDescriptor 656 0 R
+>> endobj
+656 0 obj <<
+/Ascent 708
+/CapHeight 672
+/Descent -266
+/FontName /HVUUYY+URWPalladioL-Bold
+/ItalicAngle 0
+/StemV 123
+/XHeight 471
+/FontBBox [-152 -301 1000 935]
+/Flags 4
+/CharSet (/fi/fl/exclam/dollar/percent/quoteright/parenleft/parenright/asterisk/plus/comma/hyphen/period/slash/zero/one/two/three/four/five/six/seven/eight/nine/colon/semicolon/question/at/A/B/C/D/E/F/G/H/I/K/L/M/N/O/P/Q/R/S/T/U/V/W/X/Y/Z/bracketleft/bracketright/a/b/c/d/e/f/g/h/i/j/k/l/m/n/o/p/q/r/s/t/u/v/w/x/y/z/quotedblright/emdash)
+/FontFile 657 0 R
+>> endobj
+1936 0 obj
+[611 611 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 278 0 0 500 889 0 278 333 333 444 606 250 333 250 296 500 500 500 500 500 500 500 500 500 500 250 250 0 0 0 444 747 778 667 722 833 611 556 833 833 389 0 778 611 1000 833 833 611 833 722 611 667 778 778 1000 667 667 667 333 0 333 0 0 0 500 611 444 611 500 389 556 611 333 333 611 333 889 611 556 611 611 389 444 333 611 556 833 500 556 500 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 500 0 0 1000 ]
+endobj
+659 0 obj <<
+/Type /Pages
+/Count 6
+/Parent 1937 0 R
+/Kids [650 0 R 677 0 R 687 0 R 742 0 R 806 0 R 867 0 R]
+>> endobj
+886 0 obj <<
+/Type /Pages
+/Count 6
+/Parent 1937 0 R
+/Kids [871 0 R 888 0 R 902 0 R 913 0 R 920 0 R 932 0 R]
+>> endobj
+944 0 obj <<
+/Type /Pages
+/Count 6
+/Parent 1937 0 R
+/Kids [937 0 R 946 0 R 957 0 R 965 0 R 972 0 R 978 0 R]
+>> endobj
+1001 0 obj <<
+/Type /Pages
+/Count 6
+/Parent 1937 0 R
+/Kids [986 0 R 1008 0 R 1018 0 R 1023 0 R 1027 0 R 1034 0 R]
+>> endobj
+1050 0 obj <<
+/Type /Pages
+/Count 6
+/Parent 1937 0 R
+/Kids [1043 0 R 1053 0 R 1060 0 R 1065 0 R 1074 0 R 1081 0 R]
+>> endobj
+1093 0 obj <<
+/Type /Pages
+/Count 6
+/Parent 1937 0 R
+/Kids [1085 0 R 1096 0 R 1102 0 R 1110 0 R 1117 0 R 1126 0 R]
+>> endobj
+1145 0 obj <<
+/Type /Pages
+/Count 6
+/Parent 1938 0 R
+/Kids [1139 0 R 1147 0 R 1152 0 R 1158 0 R 1164 0 R 1172 0 R]
+>> endobj
+1182 0 obj <<
+/Type /Pages
+/Count 6
+/Parent 1938 0 R
+/Kids [1179 0 R 1184 0 R 1189 0 R 1195 0 R 1199 0 R 1206 0 R]
+>> endobj
+1219 0 obj <<
+/Type /Pages
+/Count 6
+/Parent 1938 0 R
+/Kids [1216 0 R 1221 0 R 1226 0 R 1237 0 R 1243 0 R 1248 0 R]
+>> endobj
+1256 0 obj <<
+/Type /Pages
+/Count 6
+/Parent 1938 0 R
+/Kids [1252 0 R 1258 0 R 1266 0 R 1272 0 R 1279 0 R 1287 0 R]
+>> endobj
+1303 0 obj <<
+/Type /Pages
+/Count 6
+/Parent 1938 0 R
+/Kids [1294 0 R 1306 0 R 1310 0 R 1316 0 R 1321 0 R 1325 0 R]
+>> endobj
+1338 0 obj <<
+/Type /Pages
+/Count 6
+/Parent 1938 0 R
+/Kids [1334 0 R 1340 0 R 1344 0 R 1348 0 R 1356 0 R 1361 0 R]
+>> endobj
+1392 0 obj <<
+/Type /Pages
+/Count 6
+/Parent 1939 0 R
+/Kids [1378 0 R 1394 0 R 1409 0 R 1419 0 R 1425 0 R 1432 0 R]
+>> endobj
+1453 0 obj <<
+/Type /Pages
+/Count 6
+/Parent 1939 0 R
+/Kids [1443 0 R 1455 0 R 1463 0 R 1469 0 R 1473 0 R 1479 0 R]
+>> endobj
+1493 0 obj <<
+/Type /Pages
+/Count 6
+/Parent 1939 0 R
+/Kids [1490 0 R 1495 0 R 1499 0 R 1510 0 R 1514 0 R 1521 0 R]
+>> endobj
+1589 0 obj <<
+/Type /Pages
+/Count 6
+/Parent 1939 0 R
+/Kids [1531 0 R 1591 0 R 1647 0 R 1701 0 R 1735 0 R 1744 0 R]
+>> endobj
+1754 0 obj <<
+/Type /Pages
+/Count 6
+/Parent 1939 0 R
+/Kids [1750 0 R 1756 0 R 1760 0 R 1765 0 R 1777 0 R 1781 0 R]
+>> endobj
+1797 0 obj <<
+/Type /Pages
+/Count 6
+/Parent 1939 0 R
+/Kids [1793 0 R 1799 0 R 1810 0 R 1815 0 R 1820 0 R 1831 0 R]
+>> endobj
+1846 0 obj <<
+/Type /Pages
+/Count 6
+/Parent 1940 0 R
+/Kids [1843 0 R 1848 0 R 1859 0 R 1864 0 R 1871 0 R 1882 0 R]
+>> endobj
+1897 0 obj <<
+/Type /Pages
+/Count 4
+/Parent 1940 0 R
+/Kids [1893 0 R 1899 0 R 1909 0 R 1915 0 R]
+>> endobj
+1937 0 obj <<
+/Type /Pages
+/Count 36
+/Parent 1941 0 R
+/Kids [659 0 R 886 0 R 944 0 R 1001 0 R 1050 0 R 1093 0 R]
+>> endobj
+1938 0 obj <<
+/Type /Pages
+/Count 36
+/Parent 1941 0 R
+/Kids [1145 0 R 1182 0 R 1219 0 R 1256 0 R 1303 0 R 1338 0 R]
+>> endobj
+1939 0 obj <<
+/Type /Pages
+/Count 36
+/Parent 1941 0 R
+/Kids [1392 0 R 1453 0 R 1493 0 R 1589 0 R 1754 0 R 1797 0 R]
+>> endobj
+1940 0 obj <<
+/Type /Pages
+/Count 10
+/Parent 1941 0 R
+/Kids [1846 0 R 1897 0 R]
+>> endobj
+1941 0 obj <<
+/Type /Pages
+/Count 118
+/Kids [1937 0 R 1938 0 R 1939 0 R 1940 0 R]
+>> endobj
+1942 0 obj <<
+/Type /Outlines
+/First 7 0 R
+/Last 607 0 R
+/Count 10
+>> endobj
+647 0 obj <<
+/Title 648 0 R
+/A 645 0 R
+/Parent 607 0 R
+/Prev 643 0 R
+>> endobj
+643 0 obj <<
+/Title 644 0 R
+/A 641 0 R
+/Parent 607 0 R
+/Prev 639 0 R
+/Next 647 0 R
+>> endobj
+639 0 obj <<
+/Title 640 0 R
+/A 637 0 R
+/Parent 607 0 R
+/Prev 635 0 R
+/Next 643 0 R
+>> endobj
+635 0 obj <<
+/Title 636 0 R
+/A 633 0 R
+/Parent 607 0 R
+/Prev 631 0 R
+/Next 639 0 R
+>> endobj
+631 0 obj <<
+/Title 632 0 R
+/A 629 0 R
+/Parent 607 0 R
+/Prev 627 0 R
+/Next 635 0 R
+>> endobj
+627 0 obj <<
+/Title 628 0 R
+/A 625 0 R
+/Parent 607 0 R
+/Prev 623 0 R
+/Next 631 0 R
+>> endobj
+623 0 obj <<
+/Title 624 0 R
+/A 621 0 R
+/Parent 607 0 R
+/Prev 619 0 R
+/Next 627 0 R
+>> endobj
+619 0 obj <<
+/Title 620 0 R
+/A 617 0 R
+/Parent 607 0 R
+/Prev 615 0 R
+/Next 623 0 R
+>> endobj
+615 0 obj <<
+/Title 616 0 R
+/A 613 0 R
+/Parent 607 0 R
+/Prev 611 0 R
+/Next 619 0 R
+>> endobj
+611 0 obj <<
+/Title 612 0 R
+/A 609 0 R
+/Parent 607 0 R
+/Next 615 0 R
+>> endobj
+607 0 obj <<
+/Title 608 0 R
+/A 605 0 R
+/Parent 1942 0 R
+/Prev 571 0 R
+/First 611 0 R
+/Last 647 0 R
+/Count -10
+>> endobj
+603 0 obj <<
+/Title 604 0 R
+/A 601 0 R
+/Parent 591 0 R
+/Prev 599 0 R
+>> endobj
+599 0 obj <<
+/Title 600 0 R
+/A 597 0 R
+/Parent 591 0 R
+/Prev 595 0 R
+/Next 603 0 R
+>> endobj
+595 0 obj <<
+/Title 596 0 R
+/A 593 0 R
+/Parent 591 0 R
+/Next 599 0 R
+>> endobj
+591 0 obj <<
+/Title 592 0 R
+/A 589 0 R
+/Parent 571 0 R
+/Prev 583 0 R
+/First 595 0 R
+/Last 603 0 R
+/Count -3
+>> endobj
+587 0 obj <<
+/Title 588 0 R
+/A 585 0 R
+/Parent 583 0 R
+>> endobj
+583 0 obj <<
+/Title 584 0 R
+/A 581 0 R
+/Parent 571 0 R
+/Prev 575 0 R
+/Next 591 0 R
+/First 587 0 R
+/Last 587 0 R
+/Count -1
+>> endobj
+579 0 obj <<
+/Title 580 0 R
+/A 577 0 R
+/Parent 575 0 R
+>> endobj
+575 0 obj <<
+/Title 576 0 R
+/A 573 0 R
+/Parent 571 0 R
+/Next 583 0 R
+/First 579 0 R
+/Last 579 0 R
+/Count -1
+>> endobj
+571 0 obj <<
+/Title 572 0 R
+/A 569 0 R
+/Parent 1942 0 R
+/Prev 551 0 R
+/Next 607 0 R
+/First 575 0 R
+/Last 591 0 R
+/Count -3
+>> endobj
+567 0 obj <<
+/Title 568 0 R
+/A 565 0 R
+/Parent 551 0 R
+/Prev 563 0 R
+>> endobj
+563 0 obj <<
+/Title 564 0 R
+/A 561 0 R
+/Parent 551 0 R
+/Prev 555 0 R
+/Next 567 0 R
+>> endobj
+559 0 obj <<
+/Title 560 0 R
+/A 557 0 R
+/Parent 555 0 R
+>> endobj
+555 0 obj <<
+/Title 556 0 R
+/A 553 0 R
+/Parent 551 0 R
+/Next 563 0 R
+/First 559 0 R
+/Last 559 0 R
+/Count -1
+>> endobj
+551 0 obj <<
+/Title 552 0 R
+/A 549 0 R
+/Parent 1942 0 R
+/Prev 527 0 R
+/Next 571 0 R
+/First 555 0 R
+/Last 567 0 R
+/Count -3
+>> endobj
+547 0 obj <<
+/Title 548 0 R
+/A 545 0 R
+/Parent 527 0 R
+/Prev 535 0 R
+>> endobj
+543 0 obj <<
+/Title 544 0 R
+/A 541 0 R
+/Parent 535 0 R
+/Prev 539 0 R
+>> endobj
+539 0 obj <<
+/Title 540 0 R
+/A 537 0 R
+/Parent 535 0 R
+/Next 543 0 R
+>> endobj
+535 0 obj <<
+/Title 536 0 R
+/A 533 0 R
+/Parent 527 0 R
+/Prev 531 0 R
+/Next 547 0 R
+/First 539 0 R
+/Last 543 0 R
+/Count -2
+>> endobj
+531 0 obj <<
+/Title 532 0 R
+/A 529 0 R
+/Parent 527 0 R
+/Next 535 0 R
+>> endobj
+527 0 obj <<
+/Title 528 0 R
+/A 525 0 R
+/Parent 1942 0 R
+/Prev 243 0 R
+/Next 551 0 R
+/First 531 0 R
+/Last 547 0 R
+/Count -3
+>> endobj
+523 0 obj <<
+/Title 524 0 R
+/A 521 0 R
+/Parent 475 0 R
+/Prev 519 0 R
+>> endobj
+519 0 obj <<
+/Title 520 0 R
+/A 517 0 R
+/Parent 475 0 R
+/Prev 503 0 R
+/Next 523 0 R
+>> endobj
+515 0 obj <<
+/Title 516 0 R
+/A 513 0 R
+/Parent 503 0 R
+/Prev 511 0 R
+>> endobj
+511 0 obj <<
+/Title 512 0 R
+/A 509 0 R
+/Parent 503 0 R
+/Prev 507 0 R
+/Next 515 0 R
+>> endobj
+507 0 obj <<
+/Title 508 0 R
+/A 505 0 R
+/Parent 503 0 R
+/Next 511 0 R
+>> endobj
+503 0 obj <<
+/Title 504 0 R
+/A 501 0 R
+/Parent 475 0 R
+/Prev 499 0 R
+/Next 519 0 R
+/First 507 0 R
+/Last 515 0 R
+/Count -3
+>> endobj
+499 0 obj <<
+/Title 500 0 R
+/A 497 0 R
+/Parent 475 0 R
+/Prev 495 0 R
+/Next 503 0 R
+>> endobj
+495 0 obj <<
+/Title 496 0 R
+/A 493 0 R
+/Parent 475 0 R
+/Prev 491 0 R
+/Next 499 0 R
+>> endobj
+491 0 obj <<
+/Title 492 0 R
+/A 489 0 R
+/Parent 475 0 R
+/Prev 479 0 R
+/Next 495 0 R
+>> endobj
+487 0 obj <<
+/Title 488 0 R
+/A 485 0 R
+/Parent 479 0 R
+/Prev 483 0 R
+>> endobj
+483 0 obj <<
+/Title 484 0 R
+/A 481 0 R
+/Parent 479 0 R
+/Next 487 0 R
+>> endobj
+479 0 obj <<
+/Title 480 0 R
+/A 477 0 R
+/Parent 475 0 R
+/Next 491 0 R
+/First 483 0 R
+/Last 487 0 R
+/Count -2
+>> endobj
+475 0 obj <<
+/Title 476 0 R
+/A 473 0 R
+/Parent 243 0 R
+/Prev 275 0 R
+/First 479 0 R
+/Last 523 0 R
+/Count -7
+>> endobj
+471 0 obj <<
+/Title 472 0 R
+/A 469 0 R
+/Parent 455 0 R
+/Prev 467 0 R
+>> endobj
+467 0 obj <<
+/Title 468 0 R
+/A 465 0 R
+/Parent 455 0 R
+/Prev 463 0 R
+/Next 471 0 R
+>> endobj
+463 0 obj <<
+/Title 464 0 R
+/A 461 0 R
+/Parent 455 0 R
+/Prev 459 0 R
+/Next 467 0 R
+>> endobj
+459 0 obj <<
+/Title 460 0 R
+/A 457 0 R
+/Parent 455 0 R
+/Next 463 0 R
+>> endobj
+455 0 obj <<
+/Title 456 0 R
+/A 453 0 R
+/Parent 275 0 R
+/Prev 451 0 R
+/First 459 0 R
+/Last 471 0 R
+/Count -4
+>> endobj
+451 0 obj <<
+/Title 452 0 R
+/A 449 0 R
+/Parent 275 0 R
+/Prev 447 0 R
+/Next 455 0 R
+>> endobj
+447 0 obj <<
+/Title 448 0 R
+/A 445 0 R
+/Parent 275 0 R
+/Prev 443 0 R
+/Next 451 0 R
+>> endobj
+443 0 obj <<
+/Title 444 0 R
+/A 441 0 R
+/Parent 275 0 R
+/Prev 439 0 R
+/Next 447 0 R
+>> endobj
+439 0 obj <<
+/Title 440 0 R
+/A 437 0 R
+/Parent 275 0 R
+/Prev 435 0 R
+/Next 443 0 R
+>> endobj
+435 0 obj <<
+/Title 436 0 R
+/A 433 0 R
+/Parent 275 0 R
+/Prev 431 0 R
+/Next 439 0 R
+>> endobj
+431 0 obj <<
+/Title 432 0 R
+/A 429 0 R
+/Parent 275 0 R
+/Prev 427 0 R
+/Next 435 0 R
+>> endobj
+427 0 obj <<
+/Title 428 0 R
+/A 425 0 R
+/Parent 275 0 R
+/Prev 347 0 R
+/Next 431 0 R
+>> endobj
+423 0 obj <<
+/Title 424 0 R
+/A 421 0 R
+/Parent 347 0 R
+/Prev 419 0 R
+>> endobj
+419 0 obj <<
+/Title 420 0 R
+/A 417 0 R
+/Parent 347 0 R
+/Prev 415 0 R
+/Next 423 0 R
+>> endobj
+415 0 obj <<
+/Title 416 0 R
+/A 413 0 R
+/Parent 347 0 R
+/Prev 411 0 R
+/Next 419 0 R
+>> endobj
+411 0 obj <<
+/Title 412 0 R
+/A 409 0 R
+/Parent 347 0 R
+/Prev 407 0 R
+/Next 415 0 R
+>> endobj
+407 0 obj <<
+/Title 408 0 R
+/A 405 0 R
+/Parent 347 0 R
+/Prev 403 0 R
+/Next 411 0 R
+>> endobj
+403 0 obj <<
+/Title 404 0 R
+/A 401 0 R
+/Parent 347 0 R
+/Prev 399 0 R
+/Next 407 0 R
+>> endobj
+399 0 obj <<
+/Title 400 0 R
+/A 397 0 R
+/Parent 347 0 R
+/Prev 395 0 R
+/Next 403 0 R
+>> endobj
+395 0 obj <<
+/Title 396 0 R
+/A 393 0 R
+/Parent 347 0 R
+/Prev 391 0 R
+/Next 399 0 R
+>> endobj
+391 0 obj <<
+/Title 392 0 R
+/A 389 0 R
+/Parent 347 0 R
+/Prev 387 0 R
+/Next 395 0 R
+>> endobj
+387 0 obj <<
+/Title 388 0 R
+/A 385 0 R
+/Parent 347 0 R
+/Prev 383 0 R
+/Next 391 0 R
+>> endobj
+383 0 obj <<
+/Title 384 0 R
+/A 381 0 R
+/Parent 347 0 R
+/Prev 379 0 R
+/Next 387 0 R
+>> endobj
+379 0 obj <<
+/Title 380 0 R
+/A 377 0 R
+/Parent 347 0 R
+/Prev 375 0 R
+/Next 383 0 R
+>> endobj
+375 0 obj <<
+/Title 376 0 R
+/A 373 0 R
+/Parent 347 0 R
+/Prev 371 0 R
+/Next 379 0 R
+>> endobj
+371 0 obj <<
+/Title 372 0 R
+/A 369 0 R
+/Parent 347 0 R
+/Prev 367 0 R
+/Next 375 0 R
+>> endobj
+367 0 obj <<
+/Title 368 0 R
+/A 365 0 R
+/Parent 347 0 R
+/Prev 363 0 R
+/Next 371 0 R
+>> endobj
+363 0 obj <<
+/Title 364 0 R
+/A 361 0 R
+/Parent 347 0 R
+/Prev 359 0 R
+/Next 367 0 R
+>> endobj
+359 0 obj <<
+/Title 360 0 R
+/A 357 0 R
+/Parent 347 0 R
+/Prev 355 0 R
+/Next 363 0 R
+>> endobj
+355 0 obj <<
+/Title 356 0 R
+/A 353 0 R
+/Parent 347 0 R
+/Prev 351 0 R
+/Next 359 0 R
+>> endobj
+351 0 obj <<
+/Title 352 0 R
+/A 349 0 R
+/Parent 347 0 R
+/Next 355 0 R
+>> endobj
+347 0 obj <<
+/Title 348 0 R
+/A 345 0 R
+/Parent 275 0 R
+/Prev 343 0 R
+/Next 427 0 R
+/First 351 0 R
+/Last 423 0 R
+/Count -19
+>> endobj
+343 0 obj <<
+/Title 344 0 R
+/A 341 0 R
+/Parent 275 0 R
+/Prev 339 0 R
+/Next 347 0 R
+>> endobj
+339 0 obj <<
+/Title 340 0 R
+/A 337 0 R
+/Parent 275 0 R
+/Prev 335 0 R
+/Next 343 0 R
+>> endobj
+335 0 obj <<
+/Title 336 0 R
+/A 333 0 R
+/Parent 275 0 R
+/Prev 331 0 R
+/Next 339 0 R
+>> endobj
+331 0 obj <<
+/Title 332 0 R
+/A 329 0 R
+/Parent 275 0 R
+/Prev 327 0 R
+/Next 335 0 R
+>> endobj
+327 0 obj <<
+/Title 328 0 R
+/A 325 0 R
+/Parent 275 0 R
+/Prev 315 0 R
+/Next 331 0 R
+>> endobj
+323 0 obj <<
+/Title 324 0 R
+/A 321 0 R
+/Parent 315 0 R
+/Prev 319 0 R
+>> endobj
+319 0 obj <<
+/Title 320 0 R
+/A 317 0 R
+/Parent 315 0 R
+/Next 323 0 R
+>> endobj
+315 0 obj <<
+/Title 316 0 R
+/A 313 0 R
+/Parent 275 0 R
+/Prev 311 0 R
+/Next 327 0 R
+/First 319 0 R
+/Last 323 0 R
+/Count -2
+>> endobj
+311 0 obj <<
+/Title 312 0 R
+/A 309 0 R
+/Parent 275 0 R
+/Prev 307 0 R
+/Next 315 0 R
+>> endobj
+307 0 obj <<
+/Title 308 0 R
+/A 305 0 R
+/Parent 275 0 R
+/Prev 303 0 R
+/Next 311 0 R
+>> endobj
+303 0 obj <<
+/Title 304 0 R
+/A 301 0 R
+/Parent 275 0 R
+/Prev 299 0 R
+/Next 307 0 R
+>> endobj
+299 0 obj <<
+/Title 300 0 R
+/A 297 0 R
+/Parent 275 0 R
+/Prev 295 0 R
+/Next 303 0 R
+>> endobj
+295 0 obj <<
+/Title 296 0 R
+/A 293 0 R
+/Parent 275 0 R
+/Prev 291 0 R
+/Next 299 0 R
+>> endobj
+291 0 obj <<
+/Title 292 0 R
+/A 289 0 R
+/Parent 275 0 R
+/Prev 287 0 R
+/Next 295 0 R
+>> endobj
+287 0 obj <<
+/Title 288 0 R
+/A 285 0 R
+/Parent 275 0 R
+/Prev 283 0 R
+/Next 291 0 R
+>> endobj
+283 0 obj <<
+/Title 284 0 R
+/A 281 0 R
+/Parent 275 0 R
+/Prev 279 0 R
+/Next 287 0 R
+>> endobj
+279 0 obj <<
+/Title 280 0 R
+/A 277 0 R
+/Parent 275 0 R
+/Next 283 0 R
+>> endobj
+275 0 obj <<
+/Title 276 0 R
+/A 273 0 R
+/Parent 243 0 R
+/Prev 247 0 R
+/Next 475 0 R
+/First 279 0 R
+/Last 455 0 R
+/Count -24
+>> endobj
+271 0 obj <<
+/Title 272 0 R
+/A 269 0 R
+/Parent 263 0 R
+/Prev 267 0 R
+>> endobj
+267 0 obj <<
+/Title 268 0 R
+/A 265 0 R
+/Parent 263 0 R
+/Next 271 0 R
+>> endobj
+263 0 obj <<
+/Title 264 0 R
+/A 261 0 R
+/Parent 247 0 R
+/Prev 251 0 R
+/First 267 0 R
+/Last 271 0 R
+/Count -2
+>> endobj
+259 0 obj <<
+/Title 260 0 R
+/A 257 0 R
+/Parent 251 0 R
+/Prev 255 0 R
+>> endobj
+255 0 obj <<
+/Title 256 0 R
+/A 253 0 R
+/Parent 251 0 R
+/Next 259 0 R
+>> endobj
+251 0 obj <<
+/Title 252 0 R
+/A 249 0 R
+/Parent 247 0 R
+/Next 263 0 R
+/First 255 0 R
+/Last 259 0 R
+/Count -2
+>> endobj
+247 0 obj <<
+/Title 248 0 R
+/A 245 0 R
+/Parent 243 0 R
+/Next 275 0 R
+/First 251 0 R
+/Last 263 0 R
+/Count -2
+>> endobj
+243 0 obj <<
+/Title 244 0 R
+/A 241 0 R
+/Parent 1942 0 R
+/Prev 231 0 R
+/Next 527 0 R
+/First 247 0 R
+/Last 475 0 R
+/Count -3
+>> endobj
+239 0 obj <<
+/Title 240 0 R
+/A 237 0 R
+/Parent 231 0 R
+/Prev 235 0 R
+>> endobj
+235 0 obj <<
+/Title 236 0 R
+/A 233 0 R
+/Parent 231 0 R
+/Next 239 0 R
+>> endobj
+231 0 obj <<
+/Title 232 0 R
+/A 229 0 R
+/Parent 1942 0 R
+/Prev 131 0 R
+/Next 243 0 R
+/First 235 0 R
+/Last 239 0 R
+/Count -2
+>> endobj
+227 0 obj <<
+/Title 228 0 R
+/A 225 0 R
+/Parent 219 0 R
+/Prev 223 0 R
+>> endobj
+223 0 obj <<
+/Title 224 0 R
+/A 221 0 R
+/Parent 219 0 R
+/Next 227 0 R
+>> endobj
+219 0 obj <<
+/Title 220 0 R
+/A 217 0 R
+/Parent 131 0 R
+/Prev 203 0 R
+/First 223 0 R
+/Last 227 0 R
+/Count -2
+>> endobj
+215 0 obj <<
+/Title 216 0 R
+/A 213 0 R
+/Parent 203 0 R
+/Prev 211 0 R
+>> endobj
+211 0 obj <<
+/Title 212 0 R
+/A 209 0 R
+/Parent 203 0 R
+/Prev 207 0 R
+/Next 215 0 R
+>> endobj
+207 0 obj <<
+/Title 208 0 R
+/A 205 0 R
+/Parent 203 0 R
+/Next 211 0 R
+>> endobj
+203 0 obj <<
+/Title 204 0 R
+/A 201 0 R
+/Parent 131 0 R
+/Prev 199 0 R
+/Next 219 0 R
+/First 207 0 R
+/Last 215 0 R
+/Count -3
+>> endobj
+199 0 obj <<
+/Title 200 0 R
+/A 197 0 R
+/Parent 131 0 R
+/Prev 195 0 R
+/Next 203 0 R
+>> endobj
+195 0 obj <<
+/Title 196 0 R
+/A 193 0 R
+/Parent 131 0 R
+/Prev 159 0 R
+/Next 199 0 R
+>> endobj
+191 0 obj <<
+/Title 192 0 R
+/A 189 0 R
+/Parent 159 0 R
+/Prev 187 0 R
+>> endobj
+187 0 obj <<
+/Title 188 0 R
+/A 185 0 R
+/Parent 159 0 R
+/Prev 183 0 R
+/Next 191 0 R
+>> endobj
+183 0 obj <<
+/Title 184 0 R
+/A 181 0 R
+/Parent 159 0 R
+/Prev 179 0 R
+/Next 187 0 R
+>> endobj
+179 0 obj <<
+/Title 180 0 R
+/A 177 0 R
+/Parent 159 0 R
+/Prev 175 0 R
+/Next 183 0 R
+>> endobj
+175 0 obj <<
+/Title 176 0 R
+/A 173 0 R
+/Parent 159 0 R
+/Prev 163 0 R
+/Next 179 0 R
+>> endobj
+171 0 obj <<
+/Title 172 0 R
+/A 169 0 R
+/Parent 163 0 R
+/Prev 167 0 R
+>> endobj
+167 0 obj <<
+/Title 168 0 R
+/A 165 0 R
+/Parent 163 0 R
+/Next 171 0 R
+>> endobj
+163 0 obj <<
+/Title 164 0 R
+/A 161 0 R
+/Parent 159 0 R
+/Next 175 0 R
+/First 167 0 R
+/Last 171 0 R
+/Count -2
+>> endobj
+159 0 obj <<
+/Title 160 0 R
+/A 157 0 R
+/Parent 131 0 R
+/Prev 151 0 R
+/Next 195 0 R
+/First 163 0 R
+/Last 191 0 R
+/Count -6
+>> endobj
+155 0 obj <<
+/Title 156 0 R
+/A 153 0 R
+/Parent 151 0 R
+>> endobj
+151 0 obj <<
+/Title 152 0 R
+/A 149 0 R
+/Parent 131 0 R
+/Prev 147 0 R
+/Next 159 0 R
+/First 155 0 R
+/Last 155 0 R
+/Count -1
+>> endobj
+147 0 obj <<
+/Title 148 0 R
+/A 145 0 R
+/Parent 131 0 R
+/Prev 139 0 R
+/Next 151 0 R
+>> endobj
+143 0 obj <<
+/Title 144 0 R
+/A 141 0 R
+/Parent 139 0 R
+>> endobj
+139 0 obj <<
+/Title 140 0 R
+/A 137 0 R
+/Parent 131 0 R
+/Prev 135 0 R
+/Next 147 0 R
+/First 143 0 R
+/Last 143 0 R
+/Count -1
+>> endobj
+135 0 obj <<
+/Title 136 0 R
+/A 133 0 R
+/Parent 131 0 R
+/Next 139 0 R
+>> endobj
+131 0 obj <<
+/Title 132 0 R
+/A 129 0 R
+/Parent 1942 0 R
+/Prev 91 0 R
+/Next 231 0 R
+/First 135 0 R
+/Last 219 0 R
+/Count -9
+>> endobj
+127 0 obj <<
+/Title 128 0 R
+/A 125 0 R
+/Parent 111 0 R
+/Prev 115 0 R
+>> endobj
+123 0 obj <<
+/Title 124 0 R
+/A 121 0 R
+/Parent 115 0 R
+/Prev 119 0 R
+>> endobj
+119 0 obj <<
+/Title 120 0 R
+/A 117 0 R
+/Parent 115 0 R
+/Next 123 0 R
+>> endobj
+115 0 obj <<
+/Title 116 0 R
+/A 113 0 R
+/Parent 111 0 R
+/Next 127 0 R
+/First 119 0 R
+/Last 123 0 R
+/Count -2
+>> endobj
+111 0 obj <<
+/Title 112 0 R
+/A 109 0 R
+/Parent 91 0 R
+/Prev 107 0 R
+/First 115 0 R
+/Last 127 0 R
+/Count -2
+>> endobj
+107 0 obj <<
+/Title 108 0 R
+/A 105 0 R
+/Parent 91 0 R
+/Prev 95 0 R
+/Next 111 0 R
+>> endobj
+103 0 obj <<
+/Title 104 0 R
+/A 101 0 R
+/Parent 95 0 R
+/Prev 99 0 R
+>> endobj
+99 0 obj <<
+/Title 100 0 R
+/A 97 0 R
+/Parent 95 0 R
+/Next 103 0 R
+>> endobj
+95 0 obj <<
+/Title 96 0 R
+/A 93 0 R
+/Parent 91 0 R
+/Next 107 0 R
+/First 99 0 R
+/Last 103 0 R
+/Count -2
+>> endobj
+91 0 obj <<
+/Title 92 0 R
+/A 89 0 R
+/Parent 1942 0 R
+/Prev 67 0 R
+/Next 131 0 R
+/First 95 0 R
+/Last 111 0 R
+/Count -3
+>> endobj
+87 0 obj <<
+/Title 88 0 R
+/A 85 0 R
+/Parent 67 0 R
+/Prev 83 0 R
+>> endobj
+83 0 obj <<
+/Title 84 0 R
+/A 81 0 R
+/Parent 67 0 R
+/Prev 79 0 R
+/Next 87 0 R
+>> endobj
+79 0 obj <<
+/Title 80 0 R
+/A 77 0 R
+/Parent 67 0 R
+/Prev 75 0 R
+/Next 83 0 R
+>> endobj
+75 0 obj <<
+/Title 76 0 R
+/A 73 0 R
+/Parent 67 0 R
+/Prev 71 0 R
+/Next 79 0 R
+>> endobj
+71 0 obj <<
+/Title 72 0 R
+/A 69 0 R
+/Parent 67 0 R
+/Next 75 0 R
+>> endobj
+67 0 obj <<
+/Title 68 0 R
+/A 65 0 R
+/Parent 1942 0 R
+/Prev 7 0 R
+/Next 91 0 R
+/First 71 0 R
+/Last 87 0 R
+/Count -5
+>> endobj
+63 0 obj <<
+/Title 64 0 R
+/A 61 0 R
+/Parent 23 0 R
+/Prev 55 0 R
+>> endobj
+59 0 obj <<
+/Title 60 0 R
+/A 57 0 R
+/Parent 55 0 R
+>> endobj
+55 0 obj <<
+/Title 56 0 R
+/A 53 0 R
+/Parent 23 0 R
+/Prev 39 0 R
+/Next 63 0 R
+/First 59 0 R
+/Last 59 0 R
+/Count -1
+>> endobj
+51 0 obj <<
+/Title 52 0 R
+/A 49 0 R
+/Parent 39 0 R
+/Prev 47 0 R
+>> endobj
+47 0 obj <<
+/Title 48 0 R
+/A 45 0 R
+/Parent 39 0 R
+/Prev 43 0 R
+/Next 51 0 R
+>> endobj
+43 0 obj <<
+/Title 44 0 R
+/A 41 0 R
+/Parent 39 0 R
+/Next 47 0 R
+>> endobj
+39 0 obj <<
+/Title 40 0 R
+/A 37 0 R
+/Parent 23 0 R
+/Prev 35 0 R
+/Next 55 0 R
+/First 43 0 R
+/Last 51 0 R
+/Count -3
+>> endobj
+35 0 obj <<
+/Title 36 0 R
+/A 33 0 R
+/Parent 23 0 R
+/Prev 31 0 R
+/Next 39 0 R
+>> endobj
+31 0 obj <<
+/Title 32 0 R
+/A 29 0 R
+/Parent 23 0 R
+/Prev 27 0 R
+/Next 35 0 R
+>> endobj
+27 0 obj <<
+/Title 28 0 R
+/A 25 0 R
+/Parent 23 0 R
+/Next 31 0 R
+>> endobj
+23 0 obj <<
+/Title 24 0 R
+/A 21 0 R
+/Parent 7 0 R
+/Prev 19 0 R
+/First 27 0 R
+/Last 63 0 R
+/Count -6
+>> endobj
+19 0 obj <<
+/Title 20 0 R
+/A 17 0 R
+/Parent 7 0 R
+/Prev 15 0 R
+/Next 23 0 R
+>> endobj
+15 0 obj <<
+/Title 16 0 R
+/A 13 0 R
+/Parent 7 0 R
+/Prev 11 0 R
+/Next 19 0 R
+>> endobj
+11 0 obj <<
+/Title 12 0 R
+/A 9 0 R
+/Parent 7 0 R
+/Next 15 0 R
+>> endobj
+7 0 obj <<
+/Title 8 0 R
+/A 5 0 R
+/Parent 1942 0 R
+/Next 67 0 R
+/First 11 0 R
+/Last 23 0 R
+/Count -4
+>> endobj
+1943 0 obj <<
+/Names [(Access_Control_Lists) 1477 0 R (Bv9ARM.ch01) 874 0 R (Bv9ARM.ch02) 923 0 R (Bv9ARM.ch03) 940 0 R (Bv9ARM.ch04) 989 0 R (Bv9ARM.ch05) 1077 0 R (Bv9ARM.ch06) 1088 0 R (Bv9ARM.ch07) 1476 0 R (Bv9ARM.ch08) 1502 0 R (Bv9ARM.ch09) 1517 0 R (Bv9ARM.ch10) 1738 0 R (Configuration_File_Grammar) 1113 0 R (DNSSEC) 1056 0 R (Doc-Start) 655 0 R (Setting_TTLs) 1446 0 R (acache) 930 0 R (access_control) 1231 0 R (acl) 1121 0 R (address_match_lists) 1094 0 R (admin_tools) 963 0 R (appendix.A) 570 0 R (appendix.B) 606 0 R (bibliography) 1525 0 R (boolean_options) 1005 0 R (builtin) 1300 0 R (chapter*.1) 690 0 R (chapter.1) 6 0 R (chapter.2) 66 0 R (chapter.3) 90 0 R (chapter.4) 130 0 R (chapter.5) 230 0 R (chapter.6) 242 0 R (chapter.7) 526 0 R (chapter.8) 550 0 R (cite.RFC1033) 1653 0 R (cite.RFC1034) 1537 0 R (cite.RFC1035) 1539 0 R (cite.RFC1101) 1635 0 R (cite.RFC1123) 1637 0 R (cite.RFC1183) 1597 0 R (cite.RFC1464) 1675 0 R (cite.RFC1535) 1582 0 R (cite.RFC1536) 1584 0 R (cite.RFC1537) 1655 0 R (cite.RFC1591) 1639 0 R (cite.RFC1706) 1599 0 R (cite.RFC1712) 1695 0 R (cite.RFC1713) 1677 0 R (cite.RFC1794) 1679 0 R (cite.RFC1876) 1601 0 R (cite.RFC1912) 1657 0 R (cite.RFC1982) 1586 0 R (cite.RFC1995) 1544 0 R (cite.RFC1996) 1546 0 R (cite.RFC2010) 1659 0 R (cite.RFC2052) 1603 0 R (cite.RFC2065) 1707 0 R (cite.RFC2136) 1548 0 R (cite.RFC2137) 1709 0 R (cite.RFC2163) 1605 0 R (cite.RFC2168) 1607 0 R (cite.RFC2181) 1550 0 R (cite.RFC2219) 1661 0 R (cite.RFC2230) 1609 0 R (cite.RFC2240) 1681 0 R (cite.RFC2308) 1552 0 R (cite.RFC2317) 1641 0 R (cite.RFC2345) 1683 0 R (cite.RFC2352) 1685 0 R (cite.RFC2535) 1711 0 R (cite.RFC2536) 1611 0 R (cite.RFC2537) 1613 0 R (cite.RFC2538) 1615 0 R (cite.RFC2539) 1617 0 R (cite.RFC2540) 1619 0 R (cite.RFC2671) 1554 0 R (cite.RFC2672) 1556 0 R (cite.RFC2673) 1697 0 R (cite.RFC2782) 1621 0 R (cite.RFC2825) 1665 0 R (cite.RFC2826) 1643 0 R (cite.RFC2845) 1558 0 R (cite.RFC2874) 1699 0 R (cite.RFC2915) 1623 0 R (cite.RFC2929) 1645 0 R (cite.RFC2930) 1560 0 R (cite.RFC2931) 1562 0 R (cite.RFC3007) 1564 0 R (cite.RFC3008) 1713 0 R (cite.RFC3071) 1687 0 R (cite.RFC3090) 1715 0 R (cite.RFC3110) 1625 0 R (cite.RFC3123) 1627 0 R (cite.RFC3225) 1570 0 R (cite.RFC3258) 1689 0 R (cite.RFC3445) 1717 0 R (cite.RFC3490) 1667 0 R (cite.RFC3491) 1669 0 R (cite.RFC3492) 1671 0 R (cite.RFC3596) 1629 0 R (cite.RFC3597) 1631 0 R (cite.RFC3645) 1566 0 R (cite.RFC3655) 1719 0 R (cite.RFC3658) 1721 0 R (cite.RFC3755) 1723 0 R (cite.RFC3757) 1725 0 R (cite.RFC3833) 1572 0 R (cite.RFC3845) 1727 0 R (cite.RFC3901) 1691 0 R (cite.RFC4033) 1574 0 R (cite.RFC4035) 1576 0 R (cite.RFC4044) 1578 0 R (cite.RFC4074) 1588 0 R (cite.RFC974) 1541 0 R (cite.id2499701) 1732 0 R (configuration_file_elements) 1089 0 R (controls_statement_definition_and_usage) 976 0 R (diagnostic_tools) 911 0 R (dynamic_update) 999 0 R (dynamic_update_policies) 1051 0 R (dynamic_update_security) 1235 0 R (empty) 1302 0 R (historical_dns_information) 1519 0 R (id2465026) 875 0 R (id2466484) 876 0 R (id2467305) 880 0 R (id2467506) 881 0 R (id2467714) 891 0 R (id2467891) 893 0 R (id2467912) 894 0 R (id2467946) 895 0 R (id2468030) 898 0 R (id2470292) 905 0 R (id2470315) 908 0 R (id2470345) 909 0 R (id2470435) 910 0 R (id2470465) 916 0 R (id2470500) 917 0 R (id2470595) 918 0 R (id2470629) 924 0 R (id2470656) 925 0 R (id2470668) 926 0 R (id2470694) 929 0 R (id2470705) 935 0 R (id2470805) 942 0 R (id2470821) 943 0 R (id2470843) 949 0 R (id2470860) 950 0 R (id2471334) 953 0 R (id2471339) 954 0 R (id2473122) 981 0 R (id2473133) 982 0 R (id2473511) 1014 0 R (id2473529) 1015 0 R (id2473964) 1031 0 R (id2473981) 1032 0 R (id2474020) 1037 0 R (id2474038) 1038 0 R (id2474049) 1039 0 R (id2474156) 1040 0 R (id2474282) 1041 0 R (id2474327) 1047 0 R (id2474341) 1048 0 R (id2474390) 1049 0 R (id2474595) 1057 0 R (id2474732) 1058 0 R (id2474811) 1063 0 R (id2474954) 1068 0 R (id2475084) 1070 0 R (id2475106) 1071 0 R (id2475139) 1078 0 R (id2475354) 1090 0 R (id2476147) 1099 0 R (id2476174) 1100 0 R (id2476281) 1105 0 R (id2476296) 1106 0 R (id2476394) 1107 0 R (id2476477) 1114 0 R (id2476893) 1120 0 R (id2476936) 1122 0 R (id2477152) 1124 0 R (id2477512) 1131 0 R (id2477527) 1132 0 R (id2477550) 1133 0 R (id2477572) 1134 0 R (id2477662) 1143 0 R (id2477857) 1144 0 R (id2477909) 1150 0 R (id2478602) 1161 0 R (id2479412) 1167 0 R (id2479485) 1168 0 R (id2479549) 1175 0 R (id2479593) 1176 0 R (id2479608) 1177 0 R (id2481708) 1202 0 R (id2483474) 1224 0 R (id2483532) 1230 0 R (id2483954) 1241 0 R (id2484042) 1246 0 R (id2484857) 1255 0 R (id2484872) 1261 0 R (id2485056) 1263 0 R (id2485257) 1269 0 R (id2485688) 1283 0 R (id2486990) 1313 0 R (id2488093) 1330 0 R (id2488142) 1331 0 R (id2488222) 1337 0 R (id2489668) 1351 0 R (id2489675) 1352 0 R (id2489681) 1353 0 R (id2490299) 1359 0 R (id2490332) 1364 0 R (id2491624) 1406 0 R (id2491881) 1412 0 R (id2491899) 1413 0 R (id2491920) 1416 0 R (id2492156) 1422 0 R (id2493254) 1428 0 R (id2493382) 1430 0 R (id2493403) 1435 0 R (id2493834) 1437 0 R (id2493971) 1439 0 R (id2494061) 1440 0 R (id2494466) 1447 0 R (id2494590) 1449 0 R (id2494605) 1450 0 R (id2494717) 1452 0 R (id2494876) 1458 0 R (id2494937) 1459 0 R (id2495006) 1460 0 R (id2495043) 1461 0 R (id2495105) 1466 0 R (id2495584) 1486 0 R (id2495729) 1487 0 R (id2495788) 1488 0 R (id2495868) 1503 0 R (id2495874) 1504 0 R (id2495885) 1505 0 R (id2496039) 1506 0 R (id2496101) 1518 0 R (id2496273) 1524 0 R (id2496529) 1529 0 R (id2496531) 1535 0 R (id2496539) 1540 0 R (id2496563) 1536 0 R (id2496586) 1538 0 R (id2496622) 1549 0 R (id2496649) 1551 0 R (id2496675) 1543 0 R (id2496699) 1545 0 R (id2496791) 1547 0 R (id2496846) 1553 0 R (id2496873) 1555 0 R (id2496900) 1557 0 R (id2496962) 1559 0 R (id2496992) 1561 0 R (id2497021) 1563 0 R (id2497048) 1565 0 R (id2497123) 1568 0 R (id2497198) 1569 0 R (id2497225) 1571 0 R (id2497261) 1573 0 R (id2497326) 1577 0 R (id2497392) 1575 0 R (id2497457) 1580 0 R (id2497465) 1581 0 R (id2497559) 1583 0 R (id2497627) 1585 0 R (id2497662) 1587 0 R (id2497703) 1595 0 R (id2497708) 1596 0 R (id2497766) 1598 0 R (id2497803) 1606 0 R (id2497838) 1600 0 R (id2497893) 1602 0 R (id2497931) 1604 0 R (id2497957) 1608 0 R (id2497982) 1610 0 R (id2498009) 1612 0 R (id2498036) 1614 0 R (id2498075) 1616 0 R (id2498105) 1618 0 R (id2498135) 1620 0 R (id2498178) 1622 0 R (id2498211) 1624 0 R (id2498237) 1626 0 R (id2498261) 1628 0 R (id2498318) 1630 0 R (id2498343) 1633 0 R (id2498350) 1634 0 R (id2498376) 1636 0 R (id2498398) 1638 0 R (id2498422) 1640 0 R (id2498468) 1642 0 R (id2498491) 1644 0 R (id2498541) 1651 0 R (id2498549) 1652 0 R (id2498572) 1654 0 R (id2498599) 1656 0 R (id2498626) 1658 0 R (id2498662) 1660 0 R (id2498702) 1663 0 R (id2498708) 1664 0 R (id2498740) 1666 0 R (id2498854) 1668 0 R (id2498889) 1670 0 R (id2498916) 1673 0 R (id2498934) 1674 0 R (id2498956) 1676 0 R (id2498982) 1678 0 R (id2499008) 1680 0 R (id2499031) 1682 0 R (id2499077) 1684 0 R (id2499100) 1686 0 R (id2499127) 1688 0 R (id2499153) 1690 0 R (id2499190) 1693 0 R (id2499196) 1694 0 R (id2499254) 1696 0 R (id2499281) 1698 0 R (id2499317) 1705 0 R (id2499329) 1706 0 R (id2499368) 1708 0 R (id2499395) 1710 0 R (id2499425) 1712 0 R (id2499450) 1714 0 R (id2499477) 1716 0 R (id2499513) 1718 0 R (id2499549) 1720 0 R (id2499576) 1722 0 R (id2499603) 1724 0 R (id2499648) 1726 0 R (id2499689) 1729 0 R (id2499699) 1731 0 R (id2499701) 1733 0 R (incremental_zone_transfers) 1011 0 R (internet_drafts) 1728 0 R (ipv6addresses) 1072 0 R (journal) 1000 0 R (lwresd) 1079 0 R (man.dig) 1739 0 R (man.dnssec-keygen) 1787 0 R (man.dnssec-signzone) 1805 0 R (man.host) 1772 0 R (man.named) 1854 0 R (man.named-checkconf) 1825 0 R (man.named-checkzone) 1837 0 R (man.rndc) 1876 0 R (man.rndc-confgen) 1905 0 R (man.rndc.conf) 1888 0 R (notify) 990 0 R (options) 1187 0 R (page.1) 654 0 R (page.10) 915 0 R (page.100) 1767 0 R (page.101) 1779 0 R (page.102) 1783 0 R (page.103) 1795 0 R (page.104) 1801 0 R (page.105) 1812 0 R (page.106) 1817 0 R (page.107) 1822 0 R (page.108) 1833 0 R (page.109) 1845 0 R (page.11) 922 0 R (page.110) 1850 0 R (page.111) 1861 0 R (page.112) 1866 0 R (page.113) 1873 0 R (page.114) 1884 0 R (page.115) 1895 0 R (page.116) 1901 0 R (page.117) 1911 0 R (page.118) 1917 0 R (page.12) 934 0 R (page.13) 939 0 R (page.14) 948 0 R (page.15) 959 0 R (page.16) 967 0 R (page.17) 974 0 R (page.18) 980 0 R (page.19) 988 0 R (page.2) 679 0 R (page.20) 1010 0 R (page.21) 1020 0 R (page.22) 1025 0 R (page.23) 1029 0 R (page.24) 1036 0 R (page.25) 1045 0 R (page.26) 1055 0 R (page.27) 1062 0 R (page.28) 1067 0 R (page.29) 1076 0 R (page.3) 689 0 R (page.30) 1083 0 R (page.31) 1087 0 R (page.32) 1098 0 R (page.33) 1104 0 R (page.34) 1112 0 R (page.35) 1119 0 R (page.36) 1128 0 R (page.37) 1141 0 R (page.38) 1149 0 R (page.39) 1154 0 R (page.4) 744 0 R (page.40) 1160 0 R (page.41) 1166 0 R (page.42) 1174 0 R (page.43) 1181 0 R (page.44) 1186 0 R (page.45) 1191 0 R (page.46) 1197 0 R (page.47) 1201 0 R (page.48) 1208 0 R (page.49) 1218 0 R (page.5) 808 0 R (page.50) 1223 0 R (page.51) 1228 0 R (page.52) 1239 0 R (page.53) 1245 0 R (page.54) 1250 0 R (page.55) 1254 0 R (page.56) 1260 0 R (page.57) 1268 0 R (page.58) 1274 0 R (page.59) 1281 0 R (page.6) 869 0 R (page.60) 1289 0 R (page.61) 1296 0 R (page.62) 1308 0 R (page.63) 1312 0 R (page.64) 1318 0 R (page.65) 1323 0 R (page.66) 1327 0 R (page.67) 1336 0 R (page.68) 1342 0 R (page.69) 1346 0 R (page.7) 873 0 R (page.70) 1350 0 R (page.71) 1358 0 R (page.72) 1363 0 R (page.73) 1380 0 R (page.74) 1396 0 R (page.75) 1411 0 R (page.76) 1421 0 R (page.77) 1427 0 R (page.78) 1434 0 R (page.79) 1445 0 R (page.8) 890 0 R (page.80) 1457 0 R (page.81) 1465 0 R (page.82) 1471 0 R (page.83) 1475 0 R (page.84) 1481 0 R (page.85) 1492 0 R (page.86) 1497 0 R (page.87) 1501 0 R (page.88) 1512 0 R (page.89) 1516 0 R (page.9) 904 0 R (page.90) 1523 0 R (page.91) 1533 0 R (page.92) 1593 0 R (page.93) 1649 0 R (page.94) 1703 0 R (page.95) 1737 0 R (page.96) 1746 0 R (page.97) 1752 0 R (page.98) 1758 0 R (page.99) 1762 0 R (proposed_standards) 1016 0 R (rfcs) 900 0 R (rndc) 1137 0 R (rrset_ordering) 955 0 R (sample_configuration) 941 0 R (section*.10) 1662 0 R (section*.11) 1672 0 R (section*.12) 1692 0 R (section*.13) 1704 0 R (section*.14) 1730 0 R (section*.15) 1740 0 R (section*.16) 1741 0 R (section*.17) 1742 0 R (section*.18) 1747 0 R (section*.19) 1748 0 R (section*.2) 1528 0 R (section*.20) 1753 0 R (section*.21) 1763 0 R (section*.22) 1768 0 R (section*.23) 1769 0 R (section*.24) 1770 0 R (section*.25) 1771 0 R (section*.26) 1773 0 R (section*.27) 1774 0 R (section*.28) 1775 0 R (section*.29) 1784 0 R (section*.3) 1534 0 R (section*.30) 1785 0 R (section*.31) 1786 0 R (section*.32) 1788 0 R (section*.33) 1789 0 R (section*.34) 1790 0 R (section*.35) 1791 0 R (section*.36) 1796 0 R (section*.37) 1802 0 R (section*.38) 1803 0 R (section*.39) 1804 0 R (section*.4) 1542 0 R (section*.40) 1806 0 R (section*.41) 1807 0 R (section*.42) 1808 0 R (section*.43) 1813 0 R (section*.44) 1818 0 R (section*.45) 1823 0 R (section*.46) 1824 0 R (section*.47) 1826 0 R (section*.48) 1827 0 R (section*.49) 1828 0 R (section*.5) 1567 0 R (section*.50) 1829 0 R (section*.51) 1834 0 R (section*.52) 1835 0 R (section*.53) 1836 0 R (section*.54) 1838 0 R (section*.55) 1839 0 R (section*.56) 1840 0 R (section*.57) 1841 0 R (section*.58) 1851 0 R (section*.59) 1852 0 R (section*.6) 1579 0 R (section*.60) 1853 0 R (section*.61) 1855 0 R (section*.62) 1856 0 R (section*.63) 1857 0 R (section*.64) 1862 0 R (section*.65) 1867 0 R (section*.66) 1868 0 R (section*.67) 1869 0 R (section*.68) 1874 0 R (section*.69) 1875 0 R (section*.7) 1594 0 R (section*.70) 1877 0 R (section*.71) 1878 0 R (section*.72) 1879 0 R (section*.73) 1880 0 R (section*.74) 1885 0 R (section*.75) 1886 0 R (section*.76) 1887 0 R (section*.77) 1889 0 R (section*.78) 1890 0 R (section*.79) 1891 0 R (section*.8) 1632 0 R (section*.80) 1896 0 R (section*.81) 1902 0 R (section*.82) 1903 0 R (section*.83) 1904 0 R (section*.84) 1906 0 R (section*.85) 1907 0 R (section*.86) 1912 0 R (section*.87) 1913 0 R (section*.88) 1918 0 R (section*.89) 1919 0 R (section*.9) 1650 0 R (section*.90) 1920 0 R (section.1.1) 10 0 R (section.1.2) 14 0 R (section.1.3) 18 0 R (section.1.4) 22 0 R (section.2.1) 70 0 R (section.2.2) 74 0 R (section.2.3) 78 0 R (section.2.4) 82 0 R (section.2.5) 86 0 R (section.3.1) 94 0 R (section.3.2) 106 0 R (section.3.3) 110 0 R (section.4.1) 134 0 R (section.4.2) 138 0 R (section.4.3) 146 0 R (section.4.4) 150 0 R (section.4.5) 158 0 R (section.4.6) 194 0 R (section.4.7) 198 0 R (section.4.8) 202 0 R (section.4.9) 218 0 R (section.5.1) 234 0 R (section.5.2) 238 0 R (section.6.1) 246 0 R (section.6.2) 274 0 R (section.6.3) 474 0 R (section.7.1) 530 0 R (section.7.2) 534 0 R (section.7.3) 546 0 R (section.8.1) 554 0 R (section.8.2) 562 0 R (section.8.3) 566 0 R (section.A.1) 574 0 R (section.A.2) 582 0 R (section.A.3) 590 0 R (section.B.1) 610 0 R (section.B.10) 646 0 R (section.B.2) 614 0 R (section.B.3) 618 0 R (section.B.4) 622 0 R (section.B.5) 626 0 R (section.B.6) 630 0 R (section.B.7) 634 0 R (section.B.8) 638 0 R (section.B.9) 642 0 R (server_statement_definition_and_usage) 1214 0 R (server_statement_grammar) 1319 0 R (statsfile) 1193 0 R (subsection.1.4.1) 26 0 R (subsection.1.4.2) 30 0 R (subsection.1.4.3) 34 0 R (subsection.1.4.4) 38 0 R (subsection.1.4.5) 54 0 R (subsection.1.4.6) 62 0 R (subsection.3.1.1) 98 0 R (subsection.3.1.2) 102 0 R (subsection.3.3.1) 114 0 R (subsection.3.3.2) 126 0 R (subsection.4.2.1) 142 0 R (subsection.4.4.1) 154 0 R (subsection.4.5.1) 162 0 R (subsection.4.5.2) 174 0 R (subsection.4.5.3) 178 0 R (subsection.4.5.4) 182 0 R (subsection.4.5.5) 186 0 R (subsection.4.5.6) 190 0 R (subsection.4.8.1) 206 0 R (subsection.4.8.2) 210 0 R (subsection.4.8.3) 214 0 R (subsection.4.9.1) 222 0 R (subsection.4.9.2) 226 0 R (subsection.6.1.1) 250 0 R (subsection.6.1.2) 262 0 R (subsection.6.2.1) 278 0 R (subsection.6.2.10) 314 0 R (subsection.6.2.11) 326 0 R (subsection.6.2.12) 330 0 R (subsection.6.2.13) 334 0 R (subsection.6.2.14) 338 0 R (subsection.6.2.15) 342 0 R (subsection.6.2.16) 346 0 R (subsection.6.2.17) 426 0 R (subsection.6.2.18) 430 0 R (subsection.6.2.19) 434 0 R (subsection.6.2.2) 282 0 R (subsection.6.2.20) 438 0 R (subsection.6.2.21) 442 0 R (subsection.6.2.22) 446 0 R (subsection.6.2.23) 450 0 R (subsection.6.2.24) 454 0 R (subsection.6.2.3) 286 0 R (subsection.6.2.4) 290 0 R (subsection.6.2.5) 294 0 R (subsection.6.2.6) 298 0 R (subsection.6.2.7) 302 0 R (subsection.6.2.8) 306 0 R (subsection.6.2.9) 310 0 R (subsection.6.3.1) 478 0 R (subsection.6.3.2) 490 0 R (subsection.6.3.3) 494 0 R (subsection.6.3.4) 498 0 R (subsection.6.3.5) 502 0 R (subsection.6.3.6) 518 0 R (subsection.6.3.7) 522 0 R (subsection.7.2.1) 538 0 R (subsection.7.2.2) 542 0 R (subsection.8.1.1) 558 0 R (subsection.A.1.1) 578 0 R (subsection.A.2.1) 586 0 R (subsection.A.3.1) 594 0 R (subsection.A.3.2) 598 0 R (subsection.A.3.3) 602 0 R (subsubsection.1.4.4.1) 42 0 R (subsubsection.1.4.4.2) 46 0 R (subsubsection.1.4.4.3) 50 0 R (subsubsection.1.4.5.1) 58 0 R (subsubsection.3.3.1.1) 118 0 R (subsubsection.3.3.1.2) 122 0 R (subsubsection.4.5.1.1) 166 0 R (subsubsection.4.5.1.2) 170 0 R (subsubsection.6.1.1.1) 254 0 R (subsubsection.6.1.1.2) 258 0 R (subsubsection.6.1.2.1) 266 0 R (subsubsection.6.1.2.2) 270 0 R (subsubsection.6.2.10.1) 318 0 R (subsubsection.6.2.10.2) 322 0 R (subsubsection.6.2.16.1) 350 0 R (subsubsection.6.2.16.10) 386 0 R (subsubsection.6.2.16.11) 390 0 R (subsubsection.6.2.16.12) 394 0 R (subsubsection.6.2.16.13) 398 0 R (subsubsection.6.2.16.14) 402 0 R (subsubsection.6.2.16.15) 406 0 R (subsubsection.6.2.16.16) 410 0 R (subsubsection.6.2.16.17) 414 0 R (subsubsection.6.2.16.18) 418 0 R (subsubsection.6.2.16.19) 422 0 R (subsubsection.6.2.16.2) 354 0 R (subsubsection.6.2.16.3) 358 0 R (subsubsection.6.2.16.4) 362 0 R (subsubsection.6.2.16.5) 366 0 R (subsubsection.6.2.16.6) 370 0 R (subsubsection.6.2.16.7) 374 0 R (subsubsection.6.2.16.8) 378 0 R (subsubsection.6.2.16.9) 382 0 R (subsubsection.6.2.24.1) 458 0 R (subsubsection.6.2.24.2) 462 0 R (subsubsection.6.2.24.3) 466 0 R (subsubsection.6.2.24.4) 470 0 R (subsubsection.6.3.1.1) 482 0 R (subsubsection.6.3.1.2) 486 0 R (subsubsection.6.3.5.1) 506 0 R (subsubsection.6.3.5.2) 510 0 R (subsubsection.6.3.5.3) 514 0 R (table.1.1) 882 0 R (table.1.2) 892 0 R (table.3.1) 951 0 R (table.3.2) 983 0 R (table.6.1) 1091 0 R (table.6.10) 1417 0 R (table.6.11) 1423 0 R (table.6.12) 1429 0 R (table.6.13) 1436 0 R (table.6.14) 1438 0 R (table.6.15) 1441 0 R (table.6.16) 1448 0 R (table.6.17) 1451 0 R (table.6.18) 1467 0 R (table.6.2) 1115 0 R (table.6.3) 1123 0 R (table.6.4) 1162 0 R (table.6.5) 1203 0 R (table.6.6) 1284 0 R (table.6.7) 1314 0 R (table.6.8) 1354 0 R (table.6.9) 1407 0 R (the_category_phrase) 1156 0 R (the_sortlist_statement) 1275 0 R (topology) 1270 0 R (tsig) 1030 0 R (tuning) 1285 0 R (types_of_resource_records_and_when_to_use_them) 899 0 R (view_statement_grammar) 1304 0 R (zone_statement_grammar) 1234 0 R (zone_transfers) 1006 0 R (zonefile_format) 1292 0 R]
+/Limits [(Access_Control_Lists) (zonefile_format)]
+>> endobj
+1944 0 obj <<
+/Kids [1943 0 R]
+>> endobj
+1945 0 obj <<
+/Dests 1944 0 R
+>> endobj
+1946 0 obj <<
+/Type /Catalog
+/Pages 1941 0 R
+/Outlines 1942 0 R
+/Names 1945 0 R
+/PageMode /UseOutlines 
+/OpenAction 649 0 R
+>> endobj
+1947 0 obj <<
+/Author()/Title()/Subject()/Creator(LaTeX with hyperref package)/Producer(pdfeTeX-1.21a)/Keywords()
+/CreationDate (D:20071031135044+11'00')
+/PTEX.Fullbanner (This is pdfeTeX, Version 3.141592-1.21a-2.2 (Web2C 7.5.4) kpathsea version 3.5.4)
+>> endobj
+xref
+0 1948
+0000000001 65535 f 
+0000000002 00000 f 
+0000000003 00000 f 
+0000000004 00000 f 
+0000000000 00000 f 
+0000000009 00000 n 
+0000066898 00000 n 
+0000664779 00000 n 
+0000000054 00000 n 
+0000000086 00000 n 
+0000067022 00000 n 
+0000664707 00000 n 
+0000000133 00000 n 
+0000000173 00000 n 
+0000067147 00000 n 
+0000664621 00000 n 
+0000000221 00000 n 
+0000000273 00000 n 
+0000067272 00000 n 
+0000664535 00000 n 
+0000000321 00000 n 
+0000000377 00000 n 
+0000071535 00000 n 
+0000664425 00000 n 
+0000000425 00000 n 
+0000000478 00000 n 
+0000071660 00000 n 
+0000664351 00000 n 
+0000000531 00000 n 
+0000000572 00000 n 
+0000071785 00000 n 
+0000664264 00000 n 
+0000000625 00000 n 
+0000000674 00000 n 
+0000071910 00000 n 
+0000664177 00000 n 
+0000000727 00000 n 
+0000000757 00000 n 
+0000076188 00000 n 
+0000664053 00000 n 
+0000000810 00000 n 
+0000000861 00000 n 
+0000076313 00000 n 
+0000663979 00000 n 
+0000000919 00000 n 
+0000000964 00000 n 
+0000076438 00000 n 
+0000663892 00000 n 
+0000001022 00000 n 
+0000001062 00000 n 
+0000076563 00000 n 
+0000663818 00000 n 
+0000001120 00000 n 
+0000001162 00000 n 
+0000079535 00000 n 
+0000663694 00000 n 
+0000001215 00000 n 
+0000001260 00000 n 
+0000079660 00000 n 
+0000663633 00000 n 
+0000001318 00000 n 
+0000001355 00000 n 
+0000079785 00000 n 
+0000663559 00000 n 
+0000001408 00000 n 
+0000001463 00000 n 
+0000082713 00000 n 
+0000663434 00000 n 
+0000001509 00000 n 
+0000001556 00000 n 
+0000082838 00000 n 
+0000663360 00000 n 
+0000001604 00000 n 
+0000001648 00000 n 
+0000082963 00000 n 
+0000663273 00000 n 
+0000001696 00000 n 
+0000001735 00000 n 
+0000083088 00000 n 
+0000663186 00000 n 
+0000001783 00000 n 
+0000001825 00000 n 
+0000083212 00000 n 
+0000663099 00000 n 
+0000001873 00000 n 
+0000001936 00000 n 
+0000084298 00000 n 
+0000663025 00000 n 
+0000001984 00000 n 
+0000002034 00000 n 
+0000086008 00000 n 
+0000662897 00000 n 
+0000002080 00000 n 
+0000002126 00000 n 
+0000086132 00000 n 
+0000662784 00000 n 
+0000002174 00000 n 
+0000002218 00000 n 
+0000086257 00000 n 
+0000662708 00000 n 
+0000002271 00000 n 
+0000002323 00000 n 
+0000086382 00000 n 
+0000662631 00000 n 
+0000002377 00000 n 
+0000002436 00000 n 
+0000088910 00000 n 
+0000662540 00000 n 
+0000002485 00000 n 
+0000002523 00000 n 
+0000089162 00000 n 
+0000662423 00000 n 
+0000002572 00000 n 
+0000002618 00000 n 
+0000089288 00000 n 
+0000662305 00000 n 
+0000002672 00000 n 
+0000002739 00000 n 
+0000092495 00000 n 
+0000662226 00000 n 
+0000002798 00000 n 
+0000002842 00000 n 
+0000092621 00000 n 
+0000662147 00000 n 
+0000002901 00000 n 
+0000002949 00000 n 
+0000102950 00000 n 
+0000662068 00000 n 
+0000003003 00000 n 
+0000003036 00000 n 
+0000107881 00000 n 
+0000661936 00000 n 
+0000003083 00000 n 
+0000003126 00000 n 
+0000108007 00000 n 
+0000661857 00000 n 
+0000003175 00000 n 
+0000003205 00000 n 
+0000108133 00000 n 
+0000661725 00000 n 
+0000003254 00000 n 
+0000003292 00000 n 
+0000108259 00000 n 
+0000661660 00000 n 
+0000003346 00000 n 
+0000003388 00000 n 
+0000112550 00000 n 
+0000661567 00000 n 
+0000003437 00000 n 
+0000003496 00000 n 
+0000112677 00000 n 
+0000661435 00000 n 
+0000003545 00000 n 
+0000003578 00000 n 
+0000112806 00000 n 
+0000661370 00000 n 
+0000003632 00000 n 
+0000003681 00000 n 
+0000120178 00000 n 
+0000661238 00000 n 
+0000003730 00000 n 
+0000003758 00000 n 
+0000120305 00000 n 
+0000661120 00000 n 
+0000003812 00000 n 
+0000003881 00000 n 
+0000120434 00000 n 
+0000661041 00000 n 
+0000003940 00000 n 
+0000003988 00000 n 
+0000123309 00000 n 
+0000660962 00000 n 
+0000004047 00000 n 
+0000004092 00000 n 
+0000123438 00000 n 
+0000660869 00000 n 
+0000004146 00000 n 
+0000004214 00000 n 
+0000123567 00000 n 
+0000660776 00000 n 
+0000004268 00000 n 
+0000004338 00000 n 
+0000123696 00000 n 
+0000660683 00000 n 
+0000004392 00000 n 
+0000004455 00000 n 
+0000123824 00000 n 
+0000660590 00000 n 
+0000004509 00000 n 
+0000004564 00000 n 
+0000127470 00000 n 
+0000660511 00000 n 
+0000004618 00000 n 
+0000004650 00000 n 
+0000127599 00000 n 
+0000660418 00000 n 
+0000004699 00000 n 
+0000004727 00000 n 
+0000127728 00000 n 
+0000660325 00000 n 
+0000004776 00000 n 
+0000004808 00000 n 
+0000131334 00000 n 
+0000660193 00000 n 
+0000004857 00000 n 
+0000004887 00000 n 
+0000131463 00000 n 
+0000660114 00000 n 
+0000004941 00000 n 
+0000004982 00000 n 
+0000131591 00000 n 
+0000660021 00000 n 
+0000005036 00000 n 
+0000005078 00000 n 
+0000135033 00000 n 
+0000659942 00000 n 
+0000005132 00000 n 
+0000005177 00000 n 
+0000138107 00000 n 
+0000659824 00000 n 
+0000005226 00000 n 
+0000005272 00000 n 
+0000138236 00000 n 
+0000659745 00000 n 
+0000005326 00000 n 
+0000005386 00000 n 
+0000138364 00000 n 
+0000659666 00000 n 
+0000005440 00000 n 
+0000005509 00000 n 
+0000140844 00000 n 
+0000659533 00000 n 
+0000005556 00000 n 
+0000005609 00000 n 
+0000140973 00000 n 
+0000659454 00000 n 
+0000005658 00000 n 
+0000005714 00000 n 
+0000141102 00000 n 
+0000659375 00000 n 
+0000005763 00000 n 
+0000005812 00000 n 
+0000145286 00000 n 
+0000659242 00000 n 
+0000005859 00000 n 
+0000005911 00000 n 
+0000145415 00000 n 
+0000659124 00000 n 
+0000005960 00000 n 
+0000006011 00000 n 
+0000149682 00000 n 
+0000659006 00000 n 
+0000006065 00000 n 
+0000006110 00000 n 
+0000149811 00000 n 
+0000658927 00000 n 
+0000006169 00000 n 
+0000006203 00000 n 
+0000149940 00000 n 
+0000658848 00000 n 
+0000006262 00000 n 
+0000006310 00000 n 
+0000153288 00000 n 
+0000658730 00000 n 
+0000006364 00000 n 
+0000006404 00000 n 
+0000153417 00000 n 
+0000658651 00000 n 
+0000006463 00000 n 
+0000006497 00000 n 
+0000153546 00000 n 
+0000658572 00000 n 
+0000006556 00000 n 
+0000006604 00000 n 
+0000157451 00000 n 
+0000658439 00000 n 
+0000006653 00000 n 
+0000006703 00000 n 
+0000161073 00000 n 
+0000658360 00000 n 
+0000006757 00000 n 
+0000006804 00000 n 
+0000161202 00000 n 
+0000658267 00000 n 
+0000006858 00000 n 
+0000006918 00000 n 
+0000161459 00000 n 
+0000658174 00000 n 
+0000006972 00000 n 
+0000007024 00000 n 
+0000161588 00000 n 
+0000658081 00000 n 
+0000007078 00000 n 
+0000007143 00000 n 
+0000166242 00000 n 
+0000657988 00000 n 
+0000007197 00000 n 
+0000007248 00000 n 
+0000166371 00000 n 
+0000657895 00000 n 
+0000007302 00000 n 
+0000007366 00000 n 
+0000166500 00000 n 
+0000657802 00000 n 
+0000007420 00000 n 
+0000007467 00000 n 
+0000166629 00000 n 
+0000657709 00000 n 
+0000007521 00000 n 
+0000007581 00000 n 
+0000169977 00000 n 
+0000657616 00000 n 
+0000007635 00000 n 
+0000007686 00000 n 
+0000170106 00000 n 
+0000657484 00000 n 
+0000007741 00000 n 
+0000007806 00000 n 
+0000174741 00000 n 
+0000657405 00000 n 
+0000007866 00000 n 
+0000007913 00000 n 
+0000180920 00000 n 
+0000657326 00000 n 
+0000007973 00000 n 
+0000008021 00000 n 
+0000184667 00000 n 
+0000657233 00000 n 
+0000008076 00000 n 
+0000008126 00000 n 
+0000184796 00000 n 
+0000657140 00000 n 
+0000008181 00000 n 
+0000008244 00000 n 
+0000186525 00000 n 
+0000657047 00000 n 
+0000008299 00000 n 
+0000008351 00000 n 
+0000186654 00000 n 
+0000656954 00000 n 
+0000008406 00000 n 
+0000008471 00000 n 
+0000186783 00000 n 
+0000656861 00000 n 
+0000008526 00000 n 
+0000008578 00000 n 
+0000190468 00000 n 
+0000656728 00000 n 
+0000008633 00000 n 
+0000008698 00000 n 
+0000198661 00000 n 
+0000656649 00000 n 
+0000008758 00000 n 
+0000008802 00000 n 
+0000216022 00000 n 
+0000656556 00000 n 
+0000008862 00000 n 
+0000008901 00000 n 
+0000220238 00000 n 
+0000656463 00000 n 
+0000008961 00000 n 
+0000009008 00000 n 
+0000220366 00000 n 
+0000656370 00000 n 
+0000009068 00000 n 
+0000009111 00000 n 
+0000224175 00000 n 
+0000656277 00000 n 
+0000009171 00000 n 
+0000009210 00000 n 
+0000227147 00000 n 
+0000656184 00000 n 
+0000009270 00000 n 
+0000009312 00000 n 
+0000227276 00000 n 
+0000656091 00000 n 
+0000009372 00000 n 
+0000009415 00000 n 
+0000234515 00000 n 
+0000655998 00000 n 
+0000009475 00000 n 
+0000009522 00000 n 
+0000238765 00000 n 
+0000655905 00000 n 
+0000009582 00000 n 
+0000009643 00000 n 
+0000238894 00000 n 
+0000655812 00000 n 
+0000009704 00000 n 
+0000009756 00000 n 
+0000242265 00000 n 
+0000655719 00000 n 
+0000009817 00000 n 
+0000009870 00000 n 
+0000242394 00000 n 
+0000655626 00000 n 
+0000009931 00000 n 
+0000009969 00000 n 
+0000246293 00000 n 
+0000655533 00000 n 
+0000010030 00000 n 
+0000010082 00000 n 
+0000249718 00000 n 
+0000655440 00000 n 
+0000010143 00000 n 
+0000010187 00000 n 
+0000249976 00000 n 
+0000655347 00000 n 
+0000010248 00000 n 
+0000010284 00000 n 
+0000258745 00000 n 
+0000655254 00000 n 
+0000010345 00000 n 
+0000010408 00000 n 
+0000258874 00000 n 
+0000655161 00000 n 
+0000010469 00000 n 
+0000010519 00000 n 
+0000264226 00000 n 
+0000655068 00000 n 
+0000010580 00000 n 
+0000010629 00000 n 
+0000268214 00000 n 
+0000654989 00000 n 
+0000010690 00000 n 
+0000010746 00000 n 
+0000268342 00000 n 
+0000654896 00000 n 
+0000010801 00000 n 
+0000010852 00000 n 
+0000272260 00000 n 
+0000654803 00000 n 
+0000010907 00000 n 
+0000010971 00000 n 
+0000276289 00000 n 
+0000654710 00000 n 
+0000011026 00000 n 
+0000011083 00000 n 
+0000276417 00000 n 
+0000654617 00000 n 
+0000011138 00000 n 
+0000011208 00000 n 
+0000276543 00000 n 
+0000654524 00000 n 
+0000011263 00000 n 
+0000011312 00000 n 
+0000279969 00000 n 
+0000654431 00000 n 
+0000011367 00000 n 
+0000011429 00000 n 
+0000281613 00000 n 
+0000654338 00000 n 
+0000011484 00000 n 
+0000011533 00000 n 
+0000285546 00000 n 
+0000654220 00000 n 
+0000011588 00000 n 
+0000011650 00000 n 
+0000285675 00000 n 
+0000654141 00000 n 
+0000011710 00000 n 
+0000011749 00000 n 
+0000289728 00000 n 
+0000654048 00000 n 
+0000011809 00000 n 
+0000011843 00000 n 
+0000295345 00000 n 
+0000653955 00000 n 
+0000011903 00000 n 
+0000011944 00000 n 
+0000305746 00000 n 
+0000653876 00000 n 
+0000012004 00000 n 
+0000012056 00000 n 
+0000309844 00000 n 
+0000653758 00000 n 
+0000012105 00000 n 
+0000012138 00000 n 
+0000309972 00000 n 
+0000653640 00000 n 
+0000012192 00000 n 
+0000012264 00000 n 
+0000310100 00000 n 
+0000653561 00000 n 
+0000012323 00000 n 
+0000012367 00000 n 
+0000317603 00000 n 
+0000653482 00000 n 
+0000012426 00000 n 
+0000012479 00000 n 
+0000321290 00000 n 
+0000653389 00000 n 
+0000012533 00000 n 
+0000012583 00000 n 
+0000324743 00000 n 
+0000653296 00000 n 
+0000012637 00000 n 
+0000012675 00000 n 
+0000325002 00000 n 
+0000653203 00000 n 
+0000012729 00000 n 
+0000012778 00000 n 
+0000325260 00000 n 
+0000653071 00000 n 
+0000012832 00000 n 
+0000012884 00000 n 
+0000328115 00000 n 
+0000652992 00000 n 
+0000012943 00000 n 
+0000012995 00000 n 
+0000328244 00000 n 
+0000652899 00000 n 
+0000013054 00000 n 
+0000013107 00000 n 
+0000328373 00000 n 
+0000652820 00000 n 
+0000013166 00000 n 
+0000013215 00000 n 
+0000328502 00000 n 
+0000652727 00000 n 
+0000013269 00000 n 
+0000013349 00000 n 
+0000332842 00000 n 
+0000652648 00000 n 
+0000013403 00000 n 
+0000013452 00000 n 
+0000335118 00000 n 
+0000652515 00000 n 
+0000013499 00000 n 
+0000013551 00000 n 
+0000335247 00000 n 
+0000652436 00000 n 
+0000013600 00000 n 
+0000013644 00000 n 
+0000339340 00000 n 
+0000652304 00000 n 
+0000013693 00000 n 
+0000013734 00000 n 
+0000339469 00000 n 
+0000652225 00000 n 
+0000013788 00000 n 
+0000013836 00000 n 
+0000339598 00000 n 
+0000652146 00000 n 
+0000013890 00000 n 
+0000013941 00000 n 
+0000339727 00000 n 
+0000652067 00000 n 
+0000013990 00000 n 
+0000014037 00000 n 
+0000343990 00000 n 
+0000651934 00000 n 
+0000014084 00000 n 
+0000014121 00000 n 
+0000344119 00000 n 
+0000651816 00000 n 
+0000014170 00000 n 
+0000014209 00000 n 
+0000344248 00000 n 
+0000651751 00000 n 
+0000014263 00000 n 
+0000014341 00000 n 
+0000344377 00000 n 
+0000651658 00000 n 
+0000014390 00000 n 
+0000014457 00000 n 
+0000344506 00000 n 
+0000651579 00000 n 
+0000014506 00000 n 
+0000014551 00000 n 
+0000347945 00000 n 
+0000651446 00000 n 
+0000014599 00000 n 
+0000014631 00000 n 
+0000348074 00000 n 
+0000651328 00000 n 
+0000014680 00000 n 
+0000014719 00000 n 
+0000348203 00000 n 
+0000651263 00000 n 
+0000014773 00000 n 
+0000014834 00000 n 
+0000351968 00000 n 
+0000651131 00000 n 
+0000014883 00000 n 
+0000014940 00000 n 
+0000352097 00000 n 
+0000651066 00000 n 
+0000014994 00000 n 
+0000015043 00000 n 
+0000352226 00000 n 
+0000650948 00000 n 
+0000015092 00000 n 
+0000015154 00000 n 
+0000352355 00000 n 
+0000650869 00000 n 
+0000015208 00000 n 
+0000015263 00000 n 
+0000376379 00000 n 
+0000650776 00000 n 
+0000015317 00000 n 
+0000015358 00000 n 
+0000376508 00000 n 
+0000650697 00000 n 
+0000015412 00000 n 
+0000015464 00000 n 
+0000379211 00000 n 
+0000650577 00000 n 
+0000015512 00000 n 
+0000015546 00000 n 
+0000379340 00000 n 
+0000650498 00000 n 
+0000015595 00000 n 
+0000015622 00000 n 
+0000397280 00000 n 
+0000650405 00000 n 
+0000015671 00000 n 
+0000015699 00000 n 
+0000404815 00000 n 
+0000650312 00000 n 
+0000015748 00000 n 
+0000015785 00000 n 
+0000411129 00000 n 
+0000650219 00000 n 
+0000015834 00000 n 
+0000015873 00000 n 
+0000420651 00000 n 
+0000650126 00000 n 
+0000015922 00000 n 
+0000015961 00000 n 
+0000423538 00000 n 
+0000650033 00000 n 
+0000016010 00000 n 
+0000016049 00000 n 
+0000429911 00000 n 
+0000649940 00000 n 
+0000016098 00000 n 
+0000016127 00000 n 
+0000439507 00000 n 
+0000649847 00000 n 
+0000016176 00000 n 
+0000016204 00000 n 
+0000442707 00000 n 
+0000649754 00000 n 
+0000016253 00000 n 
+0000016286 00000 n 
+0000448703 00000 n 
+0000649675 00000 n 
+0000016336 00000 n 
+0000016373 00000 n 
+0000016742 00000 n 
+0000016864 00000 n 
+0000024693 00000 n 
+0000016426 00000 n 
+0000024567 00000 n 
+0000024630 00000 n 
+0000645556 00000 n 
+0000619613 00000 n 
+0000645382 00000 n 
+0000646581 00000 n 
+0000019727 00000 n 
+0000019944 00000 n 
+0000020013 00000 n 
+0000020082 00000 n 
+0000020150 00000 n 
+0000020218 00000 n 
+0000020267 00000 n 
+0000020314 00000 n 
+0000020647 00000 n 
+0000020669 00000 n 
+0000020837 00000 n 
+0000021002 00000 n 
+0000021171 00000 n 
+0000021350 00000 n 
+0000021659 00000 n 
+0000021819 00000 n 
+0000026052 00000 n 
+0000025867 00000 n 
+0000024793 00000 n 
+0000025989 00000 n 
+0000618401 00000 n 
+0000591922 00000 n 
+0000618227 00000 n 
+0000591237 00000 n 
+0000589092 00000 n 
+0000591073 00000 n 
+0000037758 00000 n 
+0000029108 00000 n 
+0000026137 00000 n 
+0000037632 00000 n 
+0000037695 00000 n 
+0000029642 00000 n 
+0000029796 00000 n 
+0000029953 00000 n 
+0000030110 00000 n 
+0000030266 00000 n 
+0000030423 00000 n 
+0000030585 00000 n 
+0000030746 00000 n 
+0000030907 00000 n 
+0000031069 00000 n 
+0000031236 00000 n 
+0000031403 00000 n 
+0000031568 00000 n 
+0000031730 00000 n 
+0000031896 00000 n 
+0000032057 00000 n 
+0000032212 00000 n 
+0000032369 00000 n 
+0000032525 00000 n 
+0000032682 00000 n 
+0000032839 00000 n 
+0000032996 00000 n 
+0000033150 00000 n 
+0000033306 00000 n 
+0000033468 00000 n 
+0000033630 00000 n 
+0000033786 00000 n 
+0000033943 00000 n 
+0000034105 00000 n 
+0000034272 00000 n 
+0000034438 00000 n 
+0000034599 00000 n 
+0000034754 00000 n 
+0000034911 00000 n 
+0000035068 00000 n 
+0000035230 00000 n 
+0000035387 00000 n 
+0000035544 00000 n 
+0000035706 00000 n 
+0000035863 00000 n 
+0000036025 00000 n 
+0000036192 00000 n 
+0000036358 00000 n 
+0000036520 00000 n 
+0000036682 00000 n 
+0000036844 00000 n 
+0000037005 00000 n 
+0000037167 00000 n 
+0000037322 00000 n 
+0000037477 00000 n 
+0000051127 00000 n 
+0000041075 00000 n 
+0000037843 00000 n 
+0000051064 00000 n 
+0000588541 00000 n 
+0000571460 00000 n 
+0000588357 00000 n 
+0000041665 00000 n 
+0000041828 00000 n 
+0000041990 00000 n 
+0000042153 00000 n 
+0000042311 00000 n 
+0000042474 00000 n 
+0000042637 00000 n 
+0000042792 00000 n 
+0000042950 00000 n 
+0000043108 00000 n 
+0000043264 00000 n 
+0000043422 00000 n 
+0000043585 00000 n 
+0000043753 00000 n 
+0000043921 00000 n 
+0000044084 00000 n 
+0000044252 00000 n 
+0000044420 00000 n 
+0000044578 00000 n 
+0000044741 00000 n 
+0000044904 00000 n 
+0000045066 00000 n 
+0000045228 00000 n 
+0000045391 00000 n 
+0000045553 00000 n 
+0000045715 00000 n 
+0000045878 00000 n 
+0000046041 00000 n 
+0000046204 00000 n 
+0000046373 00000 n 
+0000046542 00000 n 
+0000046706 00000 n 
+0000046869 00000 n 
+0000047033 00000 n 
+0000047197 00000 n 
+0000047360 00000 n 
+0000047524 00000 n 
+0000047693 00000 n 
+0000047862 00000 n 
+0000048031 00000 n 
+0000048200 00000 n 
+0000048369 00000 n 
+0000048538 00000 n 
+0000048707 00000 n 
+0000048876 00000 n 
+0000049045 00000 n 
+0000049215 00000 n 
+0000049385 00000 n 
+0000049555 00000 n 
+0000049724 00000 n 
+0000049894 00000 n 
+0000050064 00000 n 
+0000050234 00000 n 
+0000050403 00000 n 
+0000050573 00000 n 
+0000050741 00000 n 
+0000050902 00000 n 
+0000063950 00000 n 
+0000054658 00000 n 
+0000051225 00000 n 
+0000063887 00000 n 
+0000055224 00000 n 
+0000055387 00000 n 
+0000055550 00000 n 
+0000055713 00000 n 
+0000055876 00000 n 
+0000056038 00000 n 
+0000056201 00000 n 
+0000056369 00000 n 
+0000056537 00000 n 
+0000056704 00000 n 
+0000056872 00000 n 
+0000057028 00000 n 
+0000057190 00000 n 
+0000057357 00000 n 
+0000057524 00000 n 
+0000057686 00000 n 
+0000057848 00000 n 
+0000058010 00000 n 
+0000058172 00000 n 
+0000058339 00000 n 
+0000058506 00000 n 
+0000058673 00000 n 
+0000058835 00000 n 
+0000058997 00000 n 
+0000059152 00000 n 
+0000059307 00000 n 
+0000059464 00000 n 
+0000059626 00000 n 
+0000059788 00000 n 
+0000059944 00000 n 
+0000060099 00000 n 
+0000060256 00000 n 
+0000060418 00000 n 
+0000060574 00000 n 
+0000060731 00000 n 
+0000060887 00000 n 
+0000061044 00000 n 
+0000061206 00000 n 
+0000061363 00000 n 
+0000061525 00000 n 
+0000061682 00000 n 
+0000061843 00000 n 
+0000062005 00000 n 
+0000062167 00000 n 
+0000062322 00000 n 
+0000062478 00000 n 
+0000062635 00000 n 
+0000062792 00000 n 
+0000062949 00000 n 
+0000063105 00000 n 
+0000063262 00000 n 
+0000063419 00000 n 
+0000570494 00000 n 
+0000550527 00000 n 
+0000570321 00000 n 
+0000063576 00000 n 
+0000063731 00000 n 
+0000064395 00000 n 
+0000064210 00000 n 
+0000064061 00000 n 
+0000064332 00000 n 
+0000067523 00000 n 
+0000066713 00000 n 
+0000064436 00000 n 
+0000066835 00000 n 
+0000066959 00000 n 
+0000067084 00000 n 
+0000067209 00000 n 
+0000549638 00000 n 
+0000528306 00000 n 
+0000549464 00000 n 
+0000067334 00000 n 
+0000067397 00000 n 
+0000067460 00000 n 
+0000527539 00000 n 
+0000510131 00000 n 
+0000527366 00000 n 
+0000646699 00000 n 
+0000072034 00000 n 
+0000070852 00000 n 
+0000067647 00000 n 
+0000071346 00000 n 
+0000071409 00000 n 
+0000071472 00000 n 
+0000071597 00000 n 
+0000071722 00000 n 
+0000071847 00000 n 
+0000071002 00000 n 
+0000071195 00000 n 
+0000071972 00000 n 
+0000310036 00000 n 
+0000352419 00000 n 
+0000076688 00000 n 
+0000075652 00000 n 
+0000072158 00000 n 
+0000076125 00000 n 
+0000076250 00000 n 
+0000075802 00000 n 
+0000075964 00000 n 
+0000076375 00000 n 
+0000076500 00000 n 
+0000076625 00000 n 
+0000092558 00000 n 
+0000079910 00000 n 
+0000079350 00000 n 
+0000076812 00000 n 
+0000079472 00000 n 
+0000079597 00000 n 
+0000079722 00000 n 
+0000079847 00000 n 
+0000083337 00000 n 
+0000082196 00000 n 
+0000080021 00000 n 
+0000082650 00000 n 
+0000082775 00000 n 
+0000082900 00000 n 
+0000083025 00000 n 
+0000083150 00000 n 
+0000082346 00000 n 
+0000082498 00000 n 
+0000083274 00000 n 
+0000268278 00000 n 
+0000084423 00000 n 
+0000084113 00000 n 
+0000083422 00000 n 
+0000084235 00000 n 
+0000084360 00000 n 
+0000086508 00000 n 
+0000085823 00000 n 
+0000084521 00000 n 
+0000085945 00000 n 
+0000086070 00000 n 
+0000086194 00000 n 
+0000086319 00000 n 
+0000086445 00000 n 
+0000646817 00000 n 
+0000089413 00000 n 
+0000088545 00000 n 
+0000086606 00000 n 
+0000088847 00000 n 
+0000088973 00000 n 
+0000089036 00000 n 
+0000089099 00000 n 
+0000088687 00000 n 
+0000089225 00000 n 
+0000089351 00000 n 
+0000249782 00000 n 
+0000092747 00000 n 
+0000092310 00000 n 
+0000089524 00000 n 
+0000092432 00000 n 
+0000509475 00000 n 
+0000497890 00000 n 
+0000509298 00000 n 
+0000092684 00000 n 
+0000096532 00000 n 
+0000096347 00000 n 
+0000092871 00000 n 
+0000096469 00000 n 
+0000497355 00000 n 
+0000487841 00000 n 
+0000497178 00000 n 
+0000100916 00000 n 
+0000100525 00000 n 
+0000096695 00000 n 
+0000100853 00000 n 
+0000100667 00000 n 
+0000161651 00000 n 
+0000103202 00000 n 
+0000102765 00000 n 
+0000101053 00000 n 
+0000102887 00000 n 
+0000103013 00000 n 
+0000103076 00000 n 
+0000103139 00000 n 
+0000105854 00000 n 
+0000108386 00000 n 
+0000105703 00000 n 
+0000103326 00000 n 
+0000107818 00000 n 
+0000107944 00000 n 
+0000108070 00000 n 
+0000107496 00000 n 
+0000107657 00000 n 
+0000486982 00000 n 
+0000477610 00000 n 
+0000486810 00000 n 
+0000477048 00000 n 
+0000467964 00000 n 
+0000476875 00000 n 
+0000108196 00000 n 
+0000108322 00000 n 
+0000646935 00000 n 
+0000107325 00000 n 
+0000107383 00000 n 
+0000107473 00000 n 
+0000198725 00000 n 
+0000227340 00000 n 
+0000112935 00000 n 
+0000112001 00000 n 
+0000108538 00000 n 
+0000112485 00000 n 
+0000112613 00000 n 
+0000112157 00000 n 
+0000112323 00000 n 
+0000112741 00000 n 
+0000112870 00000 n 
+0000356445 00000 n 
+0000116427 00000 n 
+0000116047 00000 n 
+0000113086 00000 n 
+0000116362 00000 n 
+0000116194 00000 n 
+0000117661 00000 n 
+0000117470 00000 n 
+0000116552 00000 n 
+0000117596 00000 n 
+0000120563 00000 n 
+0000119987 00000 n 
+0000117760 00000 n 
+0000120113 00000 n 
+0000120240 00000 n 
+0000120369 00000 n 
+0000120498 00000 n 
+0000123953 00000 n 
+0000123118 00000 n 
+0000120701 00000 n 
+0000123244 00000 n 
+0000123373 00000 n 
+0000123502 00000 n 
+0000123631 00000 n 
+0000123759 00000 n 
+0000123888 00000 n 
+0000127856 00000 n 
+0000127088 00000 n 
+0000124091 00000 n 
+0000127405 00000 n 
+0000127235 00000 n 
+0000127534 00000 n 
+0000127663 00000 n 
+0000127792 00000 n 
+0000647059 00000 n 
+0000305810 00000 n 
+0000131720 00000 n 
+0000131143 00000 n 
+0000127968 00000 n 
+0000131269 00000 n 
+0000131398 00000 n 
+0000131526 00000 n 
+0000131655 00000 n 
+0000135162 00000 n 
+0000134842 00000 n 
+0000131858 00000 n 
+0000134968 00000 n 
+0000135097 00000 n 
+0000138493 00000 n 
+0000137734 00000 n 
+0000135274 00000 n 
+0000138042 00000 n 
+0000138171 00000 n 
+0000137881 00000 n 
+0000138300 00000 n 
+0000138428 00000 n 
+0000352161 00000 n 
+0000141231 00000 n 
+0000140653 00000 n 
+0000138659 00000 n 
+0000140779 00000 n 
+0000140908 00000 n 
+0000141037 00000 n 
+0000141166 00000 n 
+0000141671 00000 n 
+0000141480 00000 n 
+0000141330 00000 n 
+0000141606 00000 n 
+0000145673 00000 n 
+0000144907 00000 n 
+0000141713 00000 n 
+0000145221 00000 n 
+0000145350 00000 n 
+0000145478 00000 n 
+0000145543 00000 n 
+0000145608 00000 n 
+0000145054 00000 n 
+0000647184 00000 n 
+0000149746 00000 n 
+0000150069 00000 n 
+0000149491 00000 n 
+0000145772 00000 n 
+0000149617 00000 n 
+0000149875 00000 n 
+0000150004 00000 n 
+0000153675 00000 n 
+0000153097 00000 n 
+0000150207 00000 n 
+0000153223 00000 n 
+0000153352 00000 n 
+0000153481 00000 n 
+0000153610 00000 n 
+0000156460 00000 n 
+0000157710 00000 n 
+0000156334 00000 n 
+0000153800 00000 n 
+0000157386 00000 n 
+0000157515 00000 n 
+0000157580 00000 n 
+0000157645 00000 n 
+0000161715 00000 n 
+0000160882 00000 n 
+0000157864 00000 n 
+0000161008 00000 n 
+0000161137 00000 n 
+0000161264 00000 n 
+0000161329 00000 n 
+0000161394 00000 n 
+0000161523 00000 n 
+0000166757 00000 n 
+0000165359 00000 n 
+0000161827 00000 n 
+0000166177 00000 n 
+0000165533 00000 n 
+0000165684 00000 n 
+0000166306 00000 n 
+0000166435 00000 n 
+0000166564 00000 n 
+0000166693 00000 n 
+0000165843 00000 n 
+0000165993 00000 n 
+0000454156 00000 n 
+0000170235 00000 n 
+0000169578 00000 n 
+0000166895 00000 n 
+0000169912 00000 n 
+0000169725 00000 n 
+0000170041 00000 n 
+0000170170 00000 n 
+0000647309 00000 n 
+0000174870 00000 n 
+0000174550 00000 n 
+0000170360 00000 n 
+0000174676 00000 n 
+0000174805 00000 n 
+0000178034 00000 n 
+0000177655 00000 n 
+0000174995 00000 n 
+0000177969 00000 n 
+0000177802 00000 n 
+0000180984 00000 n 
+0000181178 00000 n 
+0000180729 00000 n 
+0000178146 00000 n 
+0000180855 00000 n 
+0000181049 00000 n 
+0000181113 00000 n 
+0000184925 00000 n 
+0000184141 00000 n 
+0000181290 00000 n 
+0000184602 00000 n 
+0000184731 00000 n 
+0000184860 00000 n 
+0000184297 00000 n 
+0000184449 00000 n 
+0000186912 00000 n 
+0000186334 00000 n 
+0000185037 00000 n 
+0000186460 00000 n 
+0000186589 00000 n 
+0000186718 00000 n 
+0000186847 00000 n 
+0000188482 00000 n 
+0000188291 00000 n 
+0000187024 00000 n 
+0000188417 00000 n 
+0000647434 00000 n 
+0000190597 00000 n 
+0000190277 00000 n 
+0000188581 00000 n 
+0000190403 00000 n 
+0000190532 00000 n 
+0000194902 00000 n 
+0000194534 00000 n 
+0000190709 00000 n 
+0000194837 00000 n 
+0000194681 00000 n 
+0000264290 00000 n 
+0000198790 00000 n 
+0000198470 00000 n 
+0000195027 00000 n 
+0000198596 00000 n 
+0000202882 00000 n 
+0000202386 00000 n 
+0000198915 00000 n 
+0000202687 00000 n 
+0000202752 00000 n 
+0000202817 00000 n 
+0000202533 00000 n 
+0000208035 00000 n 
+0000206902 00000 n 
+0000203007 00000 n 
+0000207970 00000 n 
+0000207085 00000 n 
+0000207241 00000 n 
+0000207426 00000 n 
+0000207600 00000 n 
+0000207785 00000 n 
+0000272323 00000 n 
+0000212172 00000 n 
+0000211981 00000 n 
+0000208227 00000 n 
+0000212107 00000 n 
+0000647559 00000 n 
+0000216151 00000 n 
+0000215831 00000 n 
+0000212297 00000 n 
+0000215957 00000 n 
+0000216086 00000 n 
+0000220494 00000 n 
+0000219505 00000 n 
+0000216263 00000 n 
+0000220173 00000 n 
+0000219670 00000 n 
+0000220302 00000 n 
+0000220430 00000 n 
+0000219839 00000 n 
+0000220005 00000 n 
+0000281677 00000 n 
+0000339791 00000 n 
+0000224304 00000 n 
+0000223794 00000 n 
+0000220660 00000 n 
+0000224110 00000 n 
+0000223941 00000 n 
+0000224239 00000 n 
+0000227405 00000 n 
+0000226956 00000 n 
+0000224429 00000 n 
+0000227082 00000 n 
+0000227211 00000 n 
+0000231466 00000 n 
+0000231275 00000 n 
+0000227571 00000 n 
+0000231401 00000 n 
+0000234642 00000 n 
+0000234324 00000 n 
+0000231578 00000 n 
+0000234450 00000 n 
+0000234579 00000 n 
+0000647684 00000 n 
+0000239021 00000 n 
+0000238215 00000 n 
+0000234795 00000 n 
+0000238700 00000 n 
+0000238829 00000 n 
+0000238371 00000 n 
+0000238957 00000 n 
+0000238545 00000 n 
+0000242523 00000 n 
+0000242074 00000 n 
+0000239133 00000 n 
+0000242200 00000 n 
+0000242329 00000 n 
+0000242458 00000 n 
+0000246422 00000 n 
+0000245755 00000 n 
+0000242676 00000 n 
+0000246228 00000 n 
+0000246357 00000 n 
+0000245911 00000 n 
+0000246073 00000 n 
+0000250105 00000 n 
+0000249337 00000 n 
+0000246588 00000 n 
+0000249653 00000 n 
+0000249484 00000 n 
+0000249846 00000 n 
+0000249911 00000 n 
+0000250040 00000 n 
+0000254580 00000 n 
+0000254034 00000 n 
+0000250284 00000 n 
+0000254515 00000 n 
+0000254190 00000 n 
+0000254352 00000 n 
+0000332906 00000 n 
+0000259003 00000 n 
+0000258364 00000 n 
+0000254746 00000 n 
+0000258680 00000 n 
+0000467609 00000 n 
+0000465612 00000 n 
+0000467444 00000 n 
+0000258809 00000 n 
+0000258511 00000 n 
+0000258938 00000 n 
+0000647809 00000 n 
+0000276607 00000 n 
+0000261168 00000 n 
+0000260977 00000 n 
+0000259129 00000 n 
+0000261103 00000 n 
+0000264485 00000 n 
+0000264035 00000 n 
+0000261280 00000 n 
+0000264161 00000 n 
+0000264355 00000 n 
+0000264420 00000 n 
+0000268471 00000 n 
+0000268023 00000 n 
+0000264625 00000 n 
+0000268149 00000 n 
+0000268406 00000 n 
+0000272388 00000 n 
+0000272069 00000 n 
+0000268583 00000 n 
+0000272195 00000 n 
+0000276671 00000 n 
+0000275594 00000 n 
+0000272500 00000 n 
+0000276224 00000 n 
+0000275759 00000 n 
+0000275910 00000 n 
+0000276353 00000 n 
+0000276481 00000 n 
+0000276070 00000 n 
+0000280097 00000 n 
+0000279778 00000 n 
+0000276783 00000 n 
+0000279904 00000 n 
+0000280033 00000 n 
+0000647934 00000 n 
+0000281742 00000 n 
+0000281422 00000 n 
+0000280209 00000 n 
+0000281548 00000 n 
+0000283200 00000 n 
+0000283009 00000 n 
+0000281854 00000 n 
+0000283135 00000 n 
+0000285934 00000 n 
+0000285355 00000 n 
+0000283299 00000 n 
+0000285481 00000 n 
+0000285610 00000 n 
+0000285739 00000 n 
+0000285804 00000 n 
+0000285869 00000 n 
+0000289857 00000 n 
+0000289537 00000 n 
+0000286046 00000 n 
+0000289663 00000 n 
+0000289792 00000 n 
+0000295474 00000 n 
+0000293080 00000 n 
+0000289969 00000 n 
+0000295280 00000 n 
+0000295409 00000 n 
+0000293326 00000 n 
+0000293488 00000 n 
+0000293650 00000 n 
+0000293811 00000 n 
+0000293971 00000 n 
+0000294142 00000 n 
+0000294304 00000 n 
+0000294466 00000 n 
+0000294628 00000 n 
+0000294791 00000 n 
+0000294954 00000 n 
+0000295117 00000 n 
+0000300692 00000 n 
+0000298631 00000 n 
+0000295599 00000 n 
+0000300627 00000 n 
+0000298868 00000 n 
+0000299030 00000 n 
+0000299192 00000 n 
+0000299353 00000 n 
+0000299514 00000 n 
+0000299676 00000 n 
+0000299839 00000 n 
+0000299993 00000 n 
+0000300147 00000 n 
+0000300309 00000 n 
+0000300469 00000 n 
+0000648059 00000 n 
+0000306003 00000 n 
+0000304030 00000 n 
+0000300817 00000 n 
+0000305681 00000 n 
+0000304249 00000 n 
+0000304411 00000 n 
+0000304573 00000 n 
+0000304734 00000 n 
+0000304896 00000 n 
+0000305050 00000 n 
+0000305211 00000 n 
+0000305365 00000 n 
+0000305527 00000 n 
+0000305875 00000 n 
+0000305939 00000 n 
+0000310358 00000 n 
+0000309291 00000 n 
+0000306128 00000 n 
+0000309779 00000 n 
+0000309907 00000 n 
+0000310164 00000 n 
+0000309447 00000 n 
+0000309617 00000 n 
+0000310229 00000 n 
+0000310294 00000 n 
+0000313806 00000 n 
+0000313485 00000 n 
+0000310483 00000 n 
+0000313611 00000 n 
+0000313676 00000 n 
+0000313741 00000 n 
+0000317732 00000 n 
+0000317282 00000 n 
+0000313905 00000 n 
+0000317408 00000 n 
+0000317473 00000 n 
+0000317538 00000 n 
+0000317667 00000 n 
+0000321548 00000 n 
+0000320840 00000 n 
+0000317857 00000 n 
+0000320966 00000 n 
+0000321031 00000 n 
+0000321096 00000 n 
+0000321161 00000 n 
+0000321226 00000 n 
+0000321354 00000 n 
+0000321418 00000 n 
+0000321483 00000 n 
+0000325389 00000 n 
+0000324552 00000 n 
+0000321673 00000 n 
+0000324678 00000 n 
+0000324807 00000 n 
+0000324872 00000 n 
+0000324937 00000 n 
+0000325066 00000 n 
+0000325131 00000 n 
+0000325196 00000 n 
+0000325324 00000 n 
+0000648184 00000 n 
+0000328630 00000 n 
+0000327924 00000 n 
+0000325568 00000 n 
+0000328050 00000 n 
+0000328179 00000 n 
+0000328308 00000 n 
+0000328437 00000 n 
+0000328566 00000 n 
+0000332970 00000 n 
+0000332521 00000 n 
+0000328823 00000 n 
+0000332647 00000 n 
+0000332712 00000 n 
+0000332777 00000 n 
+0000333436 00000 n 
+0000333245 00000 n 
+0000333095 00000 n 
+0000333371 00000 n 
+0000335376 00000 n 
+0000334927 00000 n 
+0000333478 00000 n 
+0000335053 00000 n 
+0000335182 00000 n 
+0000335311 00000 n 
+0000339856 00000 n 
+0000338912 00000 n 
+0000335488 00000 n 
+0000339275 00000 n 
+0000465291 00000 n 
+0000456078 00000 n 
+0000465105 00000 n 
+0000339059 00000 n 
+0000339404 00000 n 
+0000339533 00000 n 
+0000339662 00000 n 
+0000340894 00000 n 
+0000340703 00000 n 
+0000340089 00000 n 
+0000340829 00000 n 
+0000648309 00000 n 
+0000341321 00000 n 
+0000341130 00000 n 
+0000340980 00000 n 
+0000341256 00000 n 
+0000344634 00000 n 
+0000343408 00000 n 
+0000341363 00000 n 
+0000343925 00000 n 
+0000344054 00000 n 
+0000344183 00000 n 
+0000344312 00000 n 
+0000344441 00000 n 
+0000344570 00000 n 
+0000343564 00000 n 
+0000343736 00000 n 
+0000345088 00000 n 
+0000344897 00000 n 
+0000344747 00000 n 
+0000345023 00000 n 
+0000348332 00000 n 
+0000347754 00000 n 
+0000345130 00000 n 
+0000347880 00000 n 
+0000348009 00000 n 
+0000348138 00000 n 
+0000348267 00000 n 
+0000352611 00000 n 
+0000351392 00000 n 
+0000348418 00000 n 
+0000351903 00000 n 
+0000352032 00000 n 
+0000352290 00000 n 
+0000351548 00000 n 
+0000351727 00000 n 
+0000352483 00000 n 
+0000352547 00000 n 
+0000359497 00000 n 
+0000355669 00000 n 
+0000352763 00000 n 
+0000355795 00000 n 
+0000355860 00000 n 
+0000355925 00000 n 
+0000355990 00000 n 
+0000356055 00000 n 
+0000356120 00000 n 
+0000356185 00000 n 
+0000356250 00000 n 
+0000356315 00000 n 
+0000356380 00000 n 
+0000356510 00000 n 
+0000356575 00000 n 
+0000356640 00000 n 
+0000356705 00000 n 
+0000356770 00000 n 
+0000356835 00000 n 
+0000356900 00000 n 
+0000356965 00000 n 
+0000357030 00000 n 
+0000357095 00000 n 
+0000357160 00000 n 
+0000357225 00000 n 
+0000357290 00000 n 
+0000357355 00000 n 
+0000357420 00000 n 
+0000357485 00000 n 
+0000357550 00000 n 
+0000357615 00000 n 
+0000357680 00000 n 
+0000357745 00000 n 
+0000357810 00000 n 
+0000357875 00000 n 
+0000357940 00000 n 
+0000358005 00000 n 
+0000358069 00000 n 
+0000358134 00000 n 
+0000358199 00000 n 
+0000358264 00000 n 
+0000358329 00000 n 
+0000358394 00000 n 
+0000358459 00000 n 
+0000358524 00000 n 
+0000358589 00000 n 
+0000358654 00000 n 
+0000358719 00000 n 
+0000358784 00000 n 
+0000358849 00000 n 
+0000358914 00000 n 
+0000358979 00000 n 
+0000359044 00000 n 
+0000359109 00000 n 
+0000359174 00000 n 
+0000359239 00000 n 
+0000359304 00000 n 
+0000359369 00000 n 
+0000359433 00000 n 
+0000648434 00000 n 
+0000366143 00000 n 
+0000362579 00000 n 
+0000359609 00000 n 
+0000362705 00000 n 
+0000362770 00000 n 
+0000362835 00000 n 
+0000362900 00000 n 
+0000362965 00000 n 
+0000363030 00000 n 
+0000363095 00000 n 
+0000363160 00000 n 
+0000363225 00000 n 
+0000363290 00000 n 
+0000363355 00000 n 
+0000363420 00000 n 
+0000363484 00000 n 
+0000363549 00000 n 
+0000363614 00000 n 
+0000363679 00000 n 
+0000363744 00000 n 
+0000363809 00000 n 
+0000363874 00000 n 
+0000363939 00000 n 
+0000364004 00000 n 
+0000364069 00000 n 
+0000364134 00000 n 
+0000364199 00000 n 
+0000364263 00000 n 
+0000364328 00000 n 
+0000364393 00000 n 
+0000364458 00000 n 
+0000364523 00000 n 
+0000364588 00000 n 
+0000364653 00000 n 
+0000364718 00000 n 
+0000364783 00000 n 
+0000364848 00000 n 
+0000364913 00000 n 
+0000364978 00000 n 
+0000365043 00000 n 
+0000365108 00000 n 
+0000365173 00000 n 
+0000365238 00000 n 
+0000365302 00000 n 
+0000365366 00000 n 
+0000365430 00000 n 
+0000365495 00000 n 
+0000365560 00000 n 
+0000365625 00000 n 
+0000365690 00000 n 
+0000365755 00000 n 
+0000365820 00000 n 
+0000365885 00000 n 
+0000365950 00000 n 
+0000366015 00000 n 
+0000366079 00000 n 
+0000372318 00000 n 
+0000368880 00000 n 
+0000366255 00000 n 
+0000369006 00000 n 
+0000369071 00000 n 
+0000369136 00000 n 
+0000369201 00000 n 
+0000369266 00000 n 
+0000369331 00000 n 
+0000369396 00000 n 
+0000369461 00000 n 
+0000369526 00000 n 
+0000369591 00000 n 
+0000369656 00000 n 
+0000369721 00000 n 
+0000369786 00000 n 
+0000369851 00000 n 
+0000369916 00000 n 
+0000369981 00000 n 
+0000370046 00000 n 
+0000370111 00000 n 
+0000370176 00000 n 
+0000370241 00000 n 
+0000370306 00000 n 
+0000370371 00000 n 
+0000370436 00000 n 
+0000370501 00000 n 
+0000370566 00000 n 
+0000370631 00000 n 
+0000370696 00000 n 
+0000370761 00000 n 
+0000370826 00000 n 
+0000370891 00000 n 
+0000370956 00000 n 
+0000371021 00000 n 
+0000371086 00000 n 
+0000371151 00000 n 
+0000371215 00000 n 
+0000371280 00000 n 
+0000371345 00000 n 
+0000371410 00000 n 
+0000371475 00000 n 
+0000371540 00000 n 
+0000371605 00000 n 
+0000371670 00000 n 
+0000371735 00000 n 
+0000371800 00000 n 
+0000371865 00000 n 
+0000371930 00000 n 
+0000371995 00000 n 
+0000372060 00000 n 
+0000372125 00000 n 
+0000372190 00000 n 
+0000372254 00000 n 
+0000376897 00000 n 
+0000374633 00000 n 
+0000372430 00000 n 
+0000374759 00000 n 
+0000374824 00000 n 
+0000374889 00000 n 
+0000374954 00000 n 
+0000375019 00000 n 
+0000375084 00000 n 
+0000375149 00000 n 
+0000375214 00000 n 
+0000375279 00000 n 
+0000375344 00000 n 
+0000375409 00000 n 
+0000375474 00000 n 
+0000375539 00000 n 
+0000375604 00000 n 
+0000375666 00000 n 
+0000375730 00000 n 
+0000375795 00000 n 
+0000375859 00000 n 
+0000375924 00000 n 
+0000375989 00000 n 
+0000376054 00000 n 
+0000376119 00000 n 
+0000376184 00000 n 
+0000376249 00000 n 
+0000376314 00000 n 
+0000376443 00000 n 
+0000376572 00000 n 
+0000376637 00000 n 
+0000376702 00000 n 
+0000376767 00000 n 
+0000376832 00000 n 
+0000379664 00000 n 
+0000379020 00000 n 
+0000377022 00000 n 
+0000379146 00000 n 
+0000379275 00000 n 
+0000379404 00000 n 
+0000379469 00000 n 
+0000379534 00000 n 
+0000379599 00000 n 
+0000384149 00000 n 
+0000383828 00000 n 
+0000379776 00000 n 
+0000383954 00000 n 
+0000384019 00000 n 
+0000384084 00000 n 
+0000387400 00000 n 
+0000387144 00000 n 
+0000384301 00000 n 
+0000387270 00000 n 
+0000387335 00000 n 
+0000648559 00000 n 
+0000390650 00000 n 
+0000390459 00000 n 
+0000387538 00000 n 
+0000390585 00000 n 
+0000394430 00000 n 
+0000394174 00000 n 
+0000390775 00000 n 
+0000394300 00000 n 
+0000394365 00000 n 
+0000397604 00000 n 
+0000396829 00000 n 
+0000394568 00000 n 
+0000396955 00000 n 
+0000397020 00000 n 
+0000397085 00000 n 
+0000397150 00000 n 
+0000397215 00000 n 
+0000397344 00000 n 
+0000397409 00000 n 
+0000397474 00000 n 
+0000397539 00000 n 
+0000402075 00000 n 
+0000401884 00000 n 
+0000397742 00000 n 
+0000402010 00000 n 
+0000405203 00000 n 
+0000404430 00000 n 
+0000402213 00000 n 
+0000404556 00000 n 
+0000404621 00000 n 
+0000404686 00000 n 
+0000404750 00000 n 
+0000404879 00000 n 
+0000404944 00000 n 
+0000405008 00000 n 
+0000405073 00000 n 
+0000405138 00000 n 
+0000408593 00000 n 
+0000408337 00000 n 
+0000405341 00000 n 
+0000408463 00000 n 
+0000408528 00000 n 
+0000648684 00000 n 
+0000411453 00000 n 
+0000410743 00000 n 
+0000408731 00000 n 
+0000410869 00000 n 
+0000410934 00000 n 
+0000410999 00000 n 
+0000411064 00000 n 
+0000411193 00000 n 
+0000411258 00000 n 
+0000411323 00000 n 
+0000411388 00000 n 
+0000415132 00000 n 
+0000414876 00000 n 
+0000411604 00000 n 
+0000415002 00000 n 
+0000415067 00000 n 
+0000418569 00000 n 
+0000418313 00000 n 
+0000415257 00000 n 
+0000418439 00000 n 
+0000418504 00000 n 
+0000421040 00000 n 
+0000420332 00000 n 
+0000418707 00000 n 
+0000420458 00000 n 
+0000420523 00000 n 
+0000420588 00000 n 
+0000420715 00000 n 
+0000420780 00000 n 
+0000420845 00000 n 
+0000420910 00000 n 
+0000420975 00000 n 
+0000423926 00000 n 
+0000423152 00000 n 
+0000421191 00000 n 
+0000423278 00000 n 
+0000423343 00000 n 
+0000423408 00000 n 
+0000423473 00000 n 
+0000423601 00000 n 
+0000423666 00000 n 
+0000423731 00000 n 
+0000423796 00000 n 
+0000423861 00000 n 
+0000427282 00000 n 
+0000427091 00000 n 
+0000424064 00000 n 
+0000427217 00000 n 
+0000648809 00000 n 
+0000430235 00000 n 
+0000429525 00000 n 
+0000427407 00000 n 
+0000429651 00000 n 
+0000429716 00000 n 
+0000429781 00000 n 
+0000429846 00000 n 
+0000429975 00000 n 
+0000430040 00000 n 
+0000430105 00000 n 
+0000430170 00000 n 
+0000433534 00000 n 
+0000433278 00000 n 
+0000430386 00000 n 
+0000433404 00000 n 
+0000433469 00000 n 
+0000436418 00000 n 
+0000436034 00000 n 
+0000433727 00000 n 
+0000436160 00000 n 
+0000436225 00000 n 
+0000436290 00000 n 
+0000436354 00000 n 
+0000439896 00000 n 
+0000439186 00000 n 
+0000436650 00000 n 
+0000439312 00000 n 
+0000439377 00000 n 
+0000439442 00000 n 
+0000439571 00000 n 
+0000439636 00000 n 
+0000439701 00000 n 
+0000439766 00000 n 
+0000439831 00000 n 
+0000443031 00000 n 
+0000442322 00000 n 
+0000440047 00000 n 
+0000442448 00000 n 
+0000442513 00000 n 
+0000442578 00000 n 
+0000442642 00000 n 
+0000442771 00000 n 
+0000442836 00000 n 
+0000442901 00000 n 
+0000442966 00000 n 
+0000446214 00000 n 
+0000445958 00000 n 
+0000443195 00000 n 
+0000446084 00000 n 
+0000446149 00000 n 
+0000648934 00000 n 
+0000448960 00000 n 
+0000448317 00000 n 
+0000446339 00000 n 
+0000448443 00000 n 
+0000448508 00000 n 
+0000448573 00000 n 
+0000448638 00000 n 
+0000448766 00000 n 
+0000448831 00000 n 
+0000448896 00000 n 
+0000452693 00000 n 
+0000452373 00000 n 
+0000449111 00000 n 
+0000452499 00000 n 
+0000452564 00000 n 
+0000452629 00000 n 
+0000454018 00000 n 
+0000453632 00000 n 
+0000452818 00000 n 
+0000453758 00000 n 
+0000453823 00000 n 
+0000453888 00000 n 
+0000453953 00000 n 
+0000454189 00000 n 
+0000465533 00000 n 
+0000467856 00000 n 
+0000467825 00000 n 
+0000477345 00000 n 
+0000487401 00000 n 
+0000497639 00000 n 
+0000509844 00000 n 
+0000527977 00000 n 
+0000550065 00000 n 
+0000571075 00000 n 
+0000588893 00000 n 
+0000591724 00000 n 
+0000591494 00000 n 
+0000618982 00000 n 
+0000646091 00000 n 
+0000649041 00000 n 
+0000649164 00000 n 
+0000649290 00000 n 
+0000649416 00000 n 
+0000649506 00000 n 
+0000649598 00000 n 
+0000664889 00000 n 
+0000682155 00000 n 
+0000682196 00000 n 
+0000682236 00000 n 
+0000682370 00000 n 
+trailer
+<<
+/Size 1948
+/Root 1946 0 R
+/Info 1947 0 R
+/ID [<FC34A9E475CA4461718A60185182A60D> <FC34A9E475CA4461718A60185182A60D>]
+>>
+startxref
+682634
+%%EOF
diff --git a/doc/arm/Makefile.in b/doc/arm/Makefile.in
new file mode 100644
index 0000000..85f318d
--- /dev/null
+++ b/doc/arm/Makefile.in
@@ -0,0 +1,67 @@
+# Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
+# Copyright (C) 2001, 2002  Internet Software Consortium.
+#
+# Permission to use, copy, modify, and/or distribute this software for any
+# purpose with or without fee is hereby granted, provided that the above
+# copyright notice and this permission notice appear in all copies.
+#
+# THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
+# REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
+# AND FITNESS.  IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
+# INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
+# LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
+# OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
+# PERFORMANCE OF THIS SOFTWARE.
+
+# $Id: Makefile.in,v 1.12.18.8 2007/08/28 07:20:03 tbox Exp $
+
+srcdir =	@srcdir@
+VPATH =		@srcdir@
+top_srcdir =	@top_srcdir@
+
+@BIND9_MAKE_RULES@
+
+@BIND9_VERSION@
+
+MANOBJS = Bv9ARM.html
+
+PDFOBJS = Bv9ARM.pdf
+
+doc man:: ${MANOBJS} ${PDFOBJS}
+
+clean::
+	rm -f Bv9ARM.aux Bv9ARM.brf Bv9ARM.glo Bv9ARM.idx Bv9ARM.toc
+	rm -f Bv9ARM.log Bv9ARM.out Bv9ARM.tex Bv9ARM.tex.tmp
+
+docclean manclean maintainer-clean:: clean
+	rm -f *.html ${PDFOBJS}
+
+docclean manclean maintainer-clean distclean::
+	rm -f releaseinfo.xml
+
+Bv9ARM.html: Bv9ARM-book.xml releaseinfo.xml
+	expand Bv9ARM-book.xml | \
+	${XSLTPROC} --stringparam root.filename Bv9ARM \
+		${top_srcdir}/doc/xsl/isc-docbook-chunk.xsl -
+
+Bv9ARM.tex: Bv9ARM-book.xml releaseinfo.xml
+	expand Bv9ARM-book.xml | \
+	${XSLTPROC} ${top_srcdir}/doc/xsl/pre-latex.xsl - | \
+	${XSLTPROC} ${top_srcdir}/doc/xsl/isc-docbook-latex.xsl - | \
+	@PERL@ latex-fixup.pl >$@.tmp 
+	if test -s $@.tmp; then mv $@.tmp $@; else rm -f $@.tmp; exit 1; fi
+
+Bv9ARM.dvi: Bv9ARM.tex releaseinfo.xml
+	rm -f Bv9ARM-book.aux Bv9ARM-book.dvi Bv9ARM-book.log
+	${LATEX} '\batchmode\input Bv9ARM.tex' || (rm -f $@ ; exit 1)
+	${LATEX} '\batchmode\input Bv9ARM.tex' || (rm -f $@ ; exit 1)
+	${LATEX} '\batchmode\input Bv9ARM.tex' || (rm -f $@ ; exit 1)
+
+Bv9ARM.pdf: Bv9ARM.tex releaseinfo.xml
+	rm -f Bv9ARM-book.aux Bv9ARM-book.pdf Bv9ARM-book.log
+	${PDFLATEX} '\batchmode\input Bv9ARM.tex' || (rm -f $@ ; exit 1)
+	${PDFLATEX} '\batchmode\input Bv9ARM.tex' || (rm -f $@ ; exit 1)
+	${PDFLATEX} '\batchmode\input Bv9ARM.tex' || (rm -f $@ ; exit 1)
+
+releaseinfo.xml:
+	echo >$@ '<releaseinfo>BIND Version ${VERSION}</releaseinfo>'
diff --git a/doc/arm/README-SGML b/doc/arm/README-SGML
new file mode 100644
index 0000000..e33c937
--- /dev/null
+++ b/doc/arm/README-SGML
@@ -0,0 +1,329 @@
+Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+Copyright (C) 2000, 2001  Internet Software Consortium.
+See COPYRIGHT in the source root or http://isc.org/copyright.html for terms.
+
+The BIND v9 ARM master document is now kept in DocBook XML format.
+
+Version: $Id: README-SGML,v 1.17 2004/03/05 05:04:43 marka Exp $
+
+The entire ARM is in the single file:
+
+    Bv9ARM-book.xml
+
+All of the other documents - HTML, PDF, etc - are generated from this
+master source.
+
+This file attempts to describe what tools are necessary for the
+maintenance of this document as well as the generation of the
+alternate formats of this document.
+
+This file will also spend a very little time describing the XML and
+SGML headers so you can understand a bit what you may need to do to be
+able to work with this document in any fashion other than simply
+editing it. 
+
+We will spend almost no time on the actual tags and how to write an
+XML DocBook compliant document. If you are at all familiar with SGML
+or HTML it will be very evident. You only need to know what the tags
+are and how to use them. You can find a good resource either for this
+either online or in printed form:
+
+    DocBook: The Definitive Guide
+    By Norman Walsh and Leonard Muellner
+    ISBN: 156592-580-7
+    1st Edition, October 1999
+    Copyright (C) 1999 by O'Reilly & Associates, Inc. All rights reserved.
+
+The book is available online in HTML format:
+
+    http://docbook.org/
+
+and buried in:
+
+    http://www.nwalsh.com/docbook/defguide/index.html
+
+A lot of useful stuff is at NWalsh's site in general. You may also
+want to look at:
+
+    http://www.xml.com/
+
+The BIND v9 ARM is based on the XML 4.0 DocBook DTD. Every XML and
+SGML document begins with a prefix that tells where to find the file
+that describes the meaning and structure of the tags used in the rest
+of the document.
+
+For our XML DocBook 4.0 based document this prefix looks like this:
+
+    <!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.0//EN"
+		   "/usr/local/share/xml/dtd/docbook/docbookx.dtd">
+
+This "DOCTYPE" statement has three parts, of which we are only using
+two:
+
+o The highest level term that represents this document (in this case
+  it is "book"
+
+o The identifier that tells us which DTD to use. This identifier has
+  two parts, the "Formal Public Identifier" (or FPI) and the system
+  identifier. In SGML you can have either a FPI or a SYSTEM identifier
+  but you have to have at least one of them. In XML you have to have a
+  SYSTEM identifier.
+
+FP & SYSTEM identifiers - These are names/lookups for the actual
+DTD. The FPI is a globally unique name that should, on a properly
+configured system, tell you exactly what DTD to use. The SYSTEM
+identifier gives an absolute location for the DTD. In XML these are
+supposed to be properly formatted URL's.
+
+SGML has these things called "catalogs" that are files that map FPI's
+in to actual files. A "catalog" can also be used to remap a SYSTEM
+identifier so you can say something like: "http://www.oasis.org/foo"
+is actually "/usr/local/share/xml/foo.dtd"
+
+When you use various SGML/XML tools they need to be configured to look
+at the same "catalog" files so that as you move from tool to tool they
+all refer to the same DTD for the same document.
+
+We will be spending most of our configuration time making sure our
+tools use the same "catalog" files and that we have the same DTD's
+installed on our machines. XML's requirement of the SYSTEM identifier
+over the FPI will probably lead to more problems as it does not
+guarantee that everyone is using the same DTD.
+
+I did my initial work with the "sgmltools" the XML 4.0 DocBook DTD and
+"jade" or "openjade."
+
+You can get the 4.0 XML DocBook DTD from:
+
+    http://www.docbook.org/xml/4.0/
+
+(download the .zip file.) NOTE: We will eventually be changing the
+SYSTEM identifier to the recommended value of:
+
+    http://www.oasis-open.org/docbook/xml/4.0/docbookx.dtd
+
+NOTE: Under FreeBSD this is the package: 
+
+    /usr/ports/textproc/docbook-xml
+
+NetBSD instructions are coming soon.
+
+With packages listed below installed under FreeBSD the "catalog" file
+that all the tools refer to at least one is in:
+
+    /usr/local/share/sgml/catalog
+
+In order for our SYSTEM identifier for the XML DocBook dtd to be found
+I create a new catalog file at the top of the XML directory created on
+FreeBSD:
+
+   /usr/local/share/xml/catalog
+
+This file has one line:
+
+   SYSTEM "http://www.oasis-open.org/docbook/xml/4.0/docbookx.dtd" "/usr/local/share/xml/dtd/docbook/docbookx.dtd"
+
+Then in the main "catalog" I have it include this XML catalog:
+
+   CATALOG "/usr/local/share/xml/catalog"
+
+
+On your systems you need to replace "/usr/local/share" with your
+prefix root (probably /usr/pkg under NetBSD.)
+
+NOTE: The URL used above is supposed to the be the proper one for this
+XML DocBook DTD... but there is nothing at that URL so you really do
+need the "SYSTEM" identifier mapping in your catalog (or make the
+SYSTEM identifier in your document refer to the real location of the
+file on your local system.)
+
+HOW TO VALIDATE A DOCUMENT:
+
+I use the sgmltools "nsgmls" document validator. Since we are using
+XML we need to use the XML declarations, which are installed as part
+of the modular DSSL style sheets:
+
+    nsgmls -sv /usr/local/share/sgml/docbook/dsssl/modular/dtds/decls/xml.dcl \
+	   Bv9ARM-book.xml
+
+A convenient shell script "validate.sh" is now generated by configure
+to invoke the above command with the correct system-dependent paths.
+
+The SGML tools can be found at:
+
+    ftp://ftp.us.sgmltools.org/pub/SGMLtools/v2.0/source/ \
+    ftp://ftp.nllgg.nl/pub/SGMLtools/v2.0/source/
+
+FreeBSD package for these is: 
+
+    /usr/ports/textproc/sgmltools
+
+HOW TO RENDER A DOCUMENT AS HTML or TeX:
+
+o Generate html doc with:
+
+    openjade -v -d ./nominum-docbook-html.dsl \
+	 -t sgml \
+	 /usr/local/share/sgml/docbook/dsssl/modular/dtds/decls/xml.dcl \
+	 Bv9ARM-book.xml
+
+A convenient shell script "genhtml.sh" is now generated by configure to
+invoke the above command with the correct system-dependent paths.
+
+On NetBSD there is no port for "openjade" however "jade" does still
+work. However you need to specify the "catalog" file to use for style
+sheets on the command line AND you need to have a default "catalog"
+mapping where to find various DTDs. It seems that "jade" installed out
+of the box on NetBSD does not use a globally defined "catalog" file
+for mapping PUBLIC identifiers in to SYSTEM identifiers.
+
+So you need to have a "catalog" file in your current working directory
+that has in it this: (these are probably more entries than you need!)
+
+     CATALOG "/usr/pkg/share/sgml/iso8879/catalog"
+     CATALOG "/usr/pkg/share/sgml/docbook/2.4.1/catalog"
+     CATALOG "/usr/pkg/share/sgml/docbook/3.0/catalog"
+     CATALOG "/usr/pkg/share/sgml/docbook/3.1/catalog"
+     CATALOG "/usr/pkg/share/sgml/jade/catalog"
+     CATALOG "/usr/local/share/xml/catalog"
+
+(These would all be "/usr/local" on FreeBSD)
+
+So the command for jade on NetBSD will look like this:
+
+jade -v -c /usr/pkg/share/sgml/catalog -t sgml \
+     -d ./nominum-docbook-html.dsl \
+     /usr/pkg/share/sgml/docbook/dsssl/modular/dtds/decls/xml.dcl \
+     ./Bv9ARM-book.xml
+
+Furthermore, since the style sheet subset we define has in it a hard
+coded path to the style sheet is based, it is actually generated by
+configure from a .in file so that it will contain the correct
+system-dependent path: where on FreeBSD the second line reads:
+
+    <!ENTITY dbstyle SYSTEM "/usr/local/share/sgml/docbook/dsssl/modular/html/docbook.dsl" CDATA DSSSL>
+  
+On NetBSD it needs to read:
+
+    <!ENTITY dbstyle SYSTEM "/usr/pkg/share/sgml/docbook/dsssl/modular/html/docbook.dsl" CDATA DSSSL>
+
+NOTE: This is usually solved by having this style sheet modification
+be installed in a system directory and have it reference the style
+sheet it is based on via a relative path.
+
+o Generate TeX documentation:
+
+openjade -d ./nominum-docbook-print.dsl -t tex -v \
+     /usr/local/share/sgml/docbook/dsssl/modular/dtds/decls/xml.dcl \
+     Bv9ARM-book.xml
+
+If you have "jade" installed instead of "openjade" then use that as
+the command. There is little difference, openjade has some bug fixes
+and is in more active development.
+
+To convert the resulting TeX file in to a DVI file you need to do:
+
+    tex "&jadetex" Bv9ARM-book.tex
+
+You can also directly generate the pdf file via:
+
+    pdftex "&pdfjadetex" Bv9ARM-book.tex
+
+The scripts "genpdf.sh" and "gendvi." have been added to simply
+generating the  PDF and DVI output. These substitute the correct paths
+of NetBSD & FreeBSD. You still need to have TeX, jadeTeX, and pdfTeX
+installed and configured properly for these to work.
+
+You will need to up both the "pool_size" and "hash_extra" variables in
+your texmf.cnf file and regenerate them. See below.
+
+You can see that I am using a DSSSL style sheet for DocBook. Actually
+two different ones - one for rendering html, and one for 'print'
+media.
+
+NOTE: For HTML we are using a Nominum DSSSL style instead of the
+default one (all it does is change the chunking to the chapter level
+and makes the files end with ".html" instead of ".htm" so far.) If you
+want to use the plain jane DSSSL style sheet replace the:
+
+    -d ./nominum-docbook-html.dsl
+
+with
+
+    -d /usr/local/share/sgml/docbook/dsssl/modular/html/docbook.dsl
+
+This style sheet will attempt to reference the one above.
+
+I am currently working on fixing these up so that it works the same on
+our various systems. The main trick is knowing which DTD's and DSSSL
+stylesheets you have installed, installing the right ones, and
+configuring a CATALOG that refers to them in the same way. We will
+probably end up putting our CATALOG's in the same place and then we
+should be able to generate and validate our documents with a minimal
+number of command line arguments.
+
+When running these commands you will get a lot of messages about a
+bunch of general entities not being defined and having no default
+entity. You can ignore those for now.
+
+Also with the style sheets we have and jade as it is you will get
+messages about "xref to title" being unsupported. You can ignore these
+for now as well.
+
+=== Getting the various tools installed on FreeBSD
+(NetBSD coming soon..)
+
+o On freebsd you need to install the following packages:
+  o print/teTeX
+  o textproc/openjade
+  o textproc/docbook
+  o textproc/docbook-xml
+  o textproc/dsssl-docbook-modular
+  o textproc/dtd-catalogs
+
+o on freebsd you need to make some entities visible to the docbook xml
+  dtd by making a symlink (can probably be done with a catalog too)
+  ln -s /usr/local/share/xml/entity /usr/local/share/xml/dtd/docbook/ent
+
+o you may need to edit /usr/local/share/sgml/catalog and add the line:
+
+  CATALOG "/usr/local/share/sgml/openjade/catalog"
+
+o add "hugelatex," Enlarge pool sizes, install the jadetex TeX driver
+  file.
+
+  cd /usr/local/share/texmf/web2c/
+  sudo cp texmf.cnf texmf.cnf.bak
+
+  o edit the lines in texmf.cnf with these keys to these values:
+
+                  main_memory = 1100000
+                  hash_extra = 15000
+                  pool_size = 500000
+                  string_vacancies = 45000
+                  max_strings = 55000
+                  pool_free = 47500
+                  nest_size = 500
+                  param_size = 1500
+                  save_size = 5000
+                  stack_size = 1500
+
+  sudo tex -ini -progname=hugelatex -fmt=hugelatex latex.ltx
+  sudo texconfig init
+  sudo texhash
+
+  o For the jadetex macros you will need I recommend you get a more
+    current version than what is packaged with openjade or jade.
+
+    Checkout http://www.tug.org/applications/jadetex/
+    
+    Unzip the file you get from there (should be jadetex-2.20 or
+    newer.) 
+
+    In the directory you unzip: 
+
+      sudo make install
+      sudo texhash
+
+    NOTE: In the most uptodate "ports" for FreeBSD, jadetext is 2.20+
+    so on this platform you should be set as of 2001.01.08.
diff --git a/doc/arm/isc-logo.eps b/doc/arm/isc-logo.eps
new file mode 100644
index 0000000..c6a1d7a
--- /dev/null
+++ b/doc/arm/isc-logo.eps
@@ -0,0 +1,12253 @@
+%!PS-Adobe-3.1 EPSF-3.0
+%%Title: Alternate-ISC-logo-v2.ai
+%%Creator: Adobe Illustrator(R) 11
+%%AI8_CreatorVersion: 11.0.0
+%AI9_PrintingDataBegin
+%%For: Douglas E. Appelt
+%%CreationDate: 10/22/04
+%%BoundingBox: 0 0 255 149
+%%HiResBoundingBox: 0 0 254.8672 148.7520
+%%CropBox: 0 0 254.8672 148.7520
+%%LanguageLevel: 2
+%%DocumentData: Clean7Bit
+%%Pages: 1
+%%DocumentNeededResources:
+%%DocumentSuppliedResources: procset Adobe_AGM_Image (1.0 0)
+%%+ procset Adobe_CoolType_Utility_T42 (1.0 0)
+%%+ procset Adobe_CoolType_Utility_MAKEOCF (1.19 0)
+%%+ procset Adobe_CoolType_Core (2.23 0)
+%%+ procset Adobe_AGM_Core (2.0 0)
+%%+ procset Adobe_AGM_Utils (1.0 0)
+%%DocumentFonts:
+%%DocumentNeededFonts:
+%%DocumentNeededFeatures:
+%%DocumentSuppliedFeatures:
+%%DocumentProcessColors:  Cyan Magenta Yellow Black
+%%DocumentCustomColors: (PANTONE 1805 C)
+%%+ (PANTONE 871 C)
+%%+ (PANTONE 301 C)
+%%+ (PANTONE 7506 C)
+%%CMYKCustomColor: 0 0.9100 1 0.2300 (PANTONE 1805 C)
+%%+ 0.3569 0.3608 0.6353 0.1882 (PANTONE 871 C)
+%%+ 1 0.4500 0 0.1800 (PANTONE 301 C)
+%%+ 0 0.0500 0.1500 0 (PANTONE 7506 C)
+%%RGBCustomColor:
+%ADO_ContainsXMP: MainFirst
+%AI7_Thumbnail: 128 76 8
+%%BeginData: 10692 Hex Bytes
+%0000330000660000990000CC0033000033330033660033990033CC0033FF
+%0066000066330066660066990066CC0066FF009900009933009966009999
+%0099CC0099FF00CC0000CC3300CC6600CC9900CCCC00CCFF00FF3300FF66
+%00FF9900FFCC3300003300333300663300993300CC3300FF333300333333
+%3333663333993333CC3333FF3366003366333366663366993366CC3366FF
+%3399003399333399663399993399CC3399FF33CC0033CC3333CC6633CC99
+%33CCCC33CCFF33FF0033FF3333FF6633FF9933FFCC33FFFF660000660033
+%6600666600996600CC6600FF6633006633336633666633996633CC6633FF
+%6666006666336666666666996666CC6666FF669900669933669966669999
+%6699CC6699FF66CC0066CC3366CC6666CC9966CCCC66CCFF66FF0066FF33
+%66FF6666FF9966FFCC66FFFF9900009900339900669900999900CC9900FF
+%9933009933339933669933999933CC9933FF996600996633996666996699
+%9966CC9966FF9999009999339999669999999999CC9999FF99CC0099CC33
+%99CC6699CC9999CCCC99CCFF99FF0099FF3399FF6699FF9999FFCC99FFFF
+%CC0000CC0033CC0066CC0099CC00CCCC00FFCC3300CC3333CC3366CC3399
+%CC33CCCC33FFCC6600CC6633CC6666CC6699CC66CCCC66FFCC9900CC9933
+%CC9966CC9999CC99CCCC99FFCCCC00CCCC33CCCC66CCCC99CCCCCCCCCCFF
+%CCFF00CCFF33CCFF66CCFF99CCFFCCCCFFFFFF0033FF0066FF0099FF00CC
+%FF3300FF3333FF3366FF3399FF33CCFF33FFFF6600FF6633FF6666FF6699
+%FF66CCFF66FFFF9900FF9933FF9966FF9999FF99CCFF99FFFFCC00FFCC33
+%FFCC66FFCC99FFCCCCFFCCFFFFFF33FFFF66FFFF99FFFFCC110000001100
+%000011111111220000002200000022222222440000004400000044444444
+%550000005500000055555555770000007700000077777777880000008800
+%000088888888AA000000AA000000AAAAAAAABB000000BB000000BBBBBBBB
+%DD000000DD000000DDDDDDDDEE000000EE000000EEEEEEEE0000000000FF
+%00FF0000FFFFFF0000FF00FFFFFF00FFFFFF
+%524C45FD1CF852FD63FFF820272726272727264B27272627272726272727
+%26272727264B20F827FD63FFF827FFFFFFCFFF84365AFFFFFFCFFFFFFFCF
+%FFFFFFCFFD04FFCAF852FD63FFF827CFCFCACFCA2F0607A8CFCACFCACFCA
+%CFCACFCACFCACFCACF7CF827FD63FFF800FFCFFFA8A8070D06A8CFFFCFFF
+%CFFFCFFFCFFFCFFFCFFFCFA7F852FD63FFF800077E2F0D060D060706537D
+%CF7D2FA8CFCACFCACFCACFCAFF7CF827FD63FFF8000D062F070D062F070D
+%062F2F0D062FCACFCFFFCFCFCFFFCFA1F852FD63FFF8050707062E517651
+%522807060706072ECFCACFCACFCACFCAFF7CF827FD63FFF8002F067C757B
+%757C757B512F072F2FFFCFCFCFFFCFFFCFFFCFA1F852FD63FFF805075251
+%75517551755175512F062FCACFCACFCACFCACFCAFF7CF827FD63FFF8F859
+%75765176757C517C757B2E2F07A8CFFFCFCFCFFFCFCFCFA1F852FD63FFF8
+%00517551757CCFCAA751755175060753CFCACFCACFCACFCACF7CF827FD63
+%FFF8F87C75757CFFCFFFCFA7517C752F072F59A8CFCFCFFFCFFFCFA7F852
+%FD04FFA87D527DA8FD5AFFF827757551A1CFCFCAFFA0755175280D060706
+%A8CFCFCACFCAFF7CF827FD05FF27F827FD5BFFF8F87C51767CFFCFFFCFA0
+%517C752F062F060D84FFCFFFCFFFCFA1F852FD05FF7DF87DFD5BFFF80552
+%7551757CC9A7A05175517606072F7E7DCFCACFC9CFCAFF6FF827FD05FF52
+%F852FD27FFA8FD33FFF80059757C7575517C517C517C2E2F06CFCFFFCFCF
+%9293CAFFCF6FF852FD05FF7DF87DFD04FFA8FD05FF7D7DA8FF527D7D7D52
+%7D52A8FFA8527D527DA8FF7D7D527D52FD05FFA8FD05FFA87D7DFFFFA852
+%7D527DA8FF527D7D7D527D52A8FD19FFF805075275755175517551752D0D
+%0653CFFFCFFFA78C6899939344F827FD05FF52F852FFFFFFA8F87DFD04FF
+%7D27FFA87D7DA8F827A87D7DFFA8F827A8527DFFA8F852A827F8A8FFFFFF
+%7DF8FD05FF2752FFFFA8F827A8527DA87D7DA8F827A87D7DFD19FFF8F82F
+%0752517C757B757C2E0D062FA8C999CFCFC28C928C8C8C6EF852FD05FF7D
+%F87DFD04FFF8F87DFFFFFF7D52FD05FFF852FD05FFF87DFD05FFF852FFFF
+%F852FFFFFF7DF8F8FD04FF7D52FFFFFFF87DFD07FFF852FD1CFFF8000607
+%062F2852282E060D0607067D928C9293688C6892688C44F827FD05FF52F8
+%52FFFFFFA85252F852FFFF7D27FD05FFF87DFD04FFA8F852FD05FFF852FF
+%FFF8A8FFFFFF7D5227F8A8FFFF527DFFFFA8F852FD07FFF87DFD1CFFF800
+%852F2F062F070D062F072F062F0D9A8C928C928C928C928C6EF852FD05FF
+%7DF87DFD04FF27FF52F852FF7D52FD05FFF852FD05FFF82752527DFFFFF8
+%52FF527DFD04FF527DFF27F8A8FF7D7DFFFFFFF82752527DFD04FFF852FD
+%1CFFF827CFCF7D2F060D062F2F7EA82F062F938C68928C8C68926E994AF8
+%27FD05FF52F852FFFFFFA827FFFF52F852A852FD05FFF87DFD04FFA8F852
+%FF7DA8FFFFF82752F8A8FD04FF7D52FFA827F8A87D7DFFFFA8F852FF7DA8
+%FD04FFF87DFD1CFFF827FFCFFFA80D062FA8CFCFCA927693928C928C9292
+%75517C7B51F852FD05FF7DF87DFFFFFFA827FFFFFF52F8F87DFD05FFF852
+%FD05FFF87DFD05FFF852FF52F8A8FFFFFF5252FFFFFF27F8277DFFFFFFF8
+%7DFD07FFF852FD1CFFF827CFCFCACF06062ECFCAFF928C688C6892688C6E
+%765175517C26F827FD05FF52F852FFFFFFA827FD04FF52F852FD05FFF852
+%FD04FFA8F852FFFFA8A8FFF87DFFFFF8F8A8FFFF5227FD04FF27F8A8FFFF
+%A8F852FFFFA8A8FFFFFFF852FD1CFFF827FFCFFFCF7E53A8CFFFCFC99292
+%8C928C92757C757C517C7551F852FD04FFA852F852A8FFFFA8F8A8FD04FF
+%527DFD04FF7DF827FD04FFA8F827525252FF7DF827FFFFFF2727A8FF5227
+%A8FD04FF52A8FFFFA8F827525252FFFFFF7DF827FD1CFFF827CFCFCACFCF
+%CFCAFD04CF93688C688C6F7651755175517C4BF827FD05FFA8FFA8FFFFFF
+%A8FFA8FD0BFFA8FFA8FFFFFFA8FFA8A8A8FFFFFFA8FFA8FFFFFFA8FFA8FF
+%A8FD09FFA8FFA8A8A8FD05FFA8FFA8FD1BFFF827FFCFCFCFFFCFCFCFFFCF
+%C38C928C8C6E7C7576517C75767551F852FD63FFF827CFCFCACFCACFCACF
+%92928C8C688C6875517551755175517526F827FD63FFF827FFCFFFCFFFCF
+%FFCA938C928C928C99517C757C517C757C7551F852FD63FFF827CFCFCACF
+%CACFCACFA093688C6892757551755175517551754BF827FD63FFF827FFCF
+%FFCFCFCFFFCFFF998C8C926E7C7576517C7576517CA7A1F852FD06FFA87D
+%527DA8FD58FFF827CFCFCACFCACFCAFFCF996892686F5175517551755175
+%7CFF7CF827FD05FF7D2752A82727A8FD57FFF827FFCFFFCFFFCFFFC2BB8C
+%928C8C6E7C757C517C757C51CFFFA1F852FD05FF2752FFFFFF52FD58FFF8
+%27CFCFCACFCACFCF99688C68928C6F5175517551755175CAFF7CF827FD04
+%FFA8F852FD5CFFF827FFCFCFCFFFCFFFA0998C928C926E7C517C7576517C
+%51CACFA1F852FD04FFA827F87DFFFFFFA8527DFD04FF527DFFFFA87D52A8
+%FF7D527D527D527D7DFF7D7D527D527DFFFFFFA8FD06FFA8FD04FFA87D7D
+%7DFD26FFF827CFCFCACFCACFCACFCF99688C6893517551755175517575FF
+%7CF827FD05FF52F8F852FFFFFF52F8A8FFFF7D27A8FF5252A8A852A852A8
+%7DF827A87D7DFFA8F852A87D52FFFFFFF8A8FD04FF5227FFFFFF7D27A8A8
+%52A8FD25FFF827FFCFFFCFFFCFFFCFFFA08C8C92927C517C757C517C7575
+%7C7CF852FD06FF52F8F852FFFFFF27F8FFFF52A8FFFFF87DFD07FFF87DFD
+%05FFF852FD06FFF827FD04FF2727FFFFFF2752FD29FFF827CFCFCACFCACF
+%CACFA799688C68927575517551755175517526F84BFD07FF52F8F87DFFFF
+%A8F87D7D52FFFFFFF8F87DFD05FFA8F852FD05FFF87DFD05FFA8F8F8A8FF
+%FF7DF8F8A8FFFF52F852A8FD27FFF827FFCFFFCFCFCFFFCF9368928C928C
+%995176517C7576517C7551F852FD08FF7DF8F8FFFFFF52F827FD05FFF8F8
+%27FD05FFF87DFD05FFF8277D527DFFFF7D52F852FFFF277DF8A8FFFFFF52
+%F8F87DFD26FFF827CFCFCACFCACFCAFF938C688C688C6875517551755175
+%517C26F827FD09FF27F8A8FFFFFFF852FD06FF52F827FFFFFFA8F852FD05
+%FFF852A8A87DFFFF527D7DF8FF7D52A8F87DFD04FF7DF8F8A8FD25FFF827
+%FFCFFFCFFFCFFFCFCFCFC98C928C92927C517C757C517C7551F852FD04FF
+%7DFD04FF7DF8FD04FFF852FD07FF7DF8A8FFFFFFF87DFD05FFF852FD05FF
+%52A8FF272752A8FFF87DFD06FFF8A8FD25FFF827CFCFCACFCACFCAFD04CF
+%99688C688C6E7651755175517C4BF827FD04FF5227FFFFA8F852FD04FFF8
+%7DFFFFFF7D7DFFFF7D27FD04FFF852FD05FFF852FFFFA8FFFF27A8FF7DF8
+%52FFFFF852FFA852FFFF7D27A8FD25FFF827FFCFCFCFFFCFCFCFFFCFCF92
+%928C928C926E7C517C75767551F852FD04FF7D272752277DFD04FF7DF827
+%FFFFFF7D27525227FD04FFA8F852A8FFFFFF7D2727525252FFA8F8A8FFFF
+%52FFFFFF2727A8FF275252527DFD26FFF827CFCFCACFCACFCACFCAFF998C
+%688C688C688C68755176517526F827FD07FFA8FD07FFA8FFA8FFFFFFA8A8
+%A8FD05FFA8FFA8FD05FFA8FFA8A8A8FFA8FFA8FD07FFA8FFFFFFA8A8FD28
+%FFF827FFCFFFCFFFCFFFCFFFCFCF92C29A928C928C928C99757C7551F852
+%FD63FFF827CFCFCACFCACFCACFCAFD04CFFF998C68928C8C6892689344F8
+%27FD63FFF827FFCFFFCFCFCFFFCFCFCFFFCFCFCFC98C928C928C928C928C
+%68F852FD63FFF827CFCFCACFCACFCAA8537ECACFCAFF938C6899688C688C
+%689244F827FD63FFF827FFCFFFCFFFCFA8072F07FFCFFFCFCF992F0D5992
+%928C928C68F852FD08FF7D7D527D52A8A8FD54FFF827CFCFCACFCACFA70D
+%060753A87DA8CA5A0607069368929AC244F827FD06FF7DF8527D7D7D52F8
+%27FD54FFF827FFCFCFCFFFCFCF2F2F070D062F072F062F07539993C2FFFF
+%76F852FD05FF7DF87DFD06FF27FD54FFF827CFCFCACFCACF7D0D060D0607
+%060D0607060753FFCACFCAFF76F827FD04FFA8F827FD07FFA8A8FD15FFA8
+%FD3DFFF827FFCFFFCFFF592F062F072F2852282F072F072F7DFFCFFFCFA7
+%F852FD04FF52F87DFD0CFFA87D7D7DFD05FFA8FD05FF7D7DA8FFFFA87D7D
+%7DFFFFFFA87D527D7DFD04FFA8527D527DA8FFFF7D527D527D527D7DFF7D
+%7D7DFFFFA8527DA8FFFFA8527DFFFFFFA8FD06FFA8FFFFF827CF5959CA53
+%07060D066F688C6892684B060D06077DCFCFCF7CF827FD04FF27F8A8FD0A
+%FFA82752A87D52F852FFFFA8F87DFD04FF7D27FFFF7D27A87D52FFFF5227
+%7DA87D27F8A8FFFFA8F827A827F8A8A852A87DF827A87D7DFFA8F852FFFF
+%A8F827FD04FF2727FFFFFFF8A8FD04FF5227FFFFF827A9062F070D062F28
+%928C928C928C928C92282F072F847E5953F852FD04FFF8F8A8FD0AFF2752
+%FD04FF7DF87DFFFFF8F852FFFFFF7D52FFFFF8A8FFFFA8FF7DF8A8FD04FF
+%27F8FFFFFFF87DFFFFF87DFD04FFF87DFD05FFF852FFFFFFF87DFD04FF27
+%52FFFFFFF827FD04FF2727FFFFF8272F07060D060D278C688C68928C8C68
+%8C688C060D0607060D06F827FFFFFFA827F87DFD09FF7DF8FD06FF27F8FF
+%A85252F852FFFF7D27FFFF27F87DFFFFFF2727FD05FF7DF852FFA8F852FF
+%A8F87DFFFFFFA8F852FD05FFF852FFFFA8F852FD04FF5252FFFFA8F8F8A8
+%FFFF7DF827A8FFF827FF2F2F070D06938C928CBCC9CFC9BB8C928C6F070D
+%062F0706F852FD04FF27F852FD09FF52F8FD06FF52F8FFFF27FF52F852FF
+%7D52FFFFA827F827A8FFF852FD06FFF852FFFFF852FF7D7DFD05FFF87DFD
+%05FFF852FFFFFFF87DFD04FF2752FFFF7D52F852FFFF277DF8A8FFF827CF
+%CF2F0D064C689268C2CFFFCFFFCFC2688C682E0607062F52F827FD04FF7D
+%F8F8A8FD08FF52F8A8FD05FF52F8FFA827FFFF52F852A852FD04FF7DF827
+%FF2727FD05FFA8F852FFA8F82752F8A8FD04FFA8F852FD05FFF852FFFFA8
+%F852FD04FF5252FFFF7D7D7DF8FF7D52A8F87DFFF827FFCF59062F6F8C8C
+%99CFFFCFFFCFFFCF938C8C4B2F0759CFA7F852FD05FF52F827FD06FF7DFF
+%A8F852FD05FFF852FFA827FFFFFF52F8F87DFD05FF7DF8FF52F8A8FD04FF
+%A8F8A8FFFFF87DFF52F8FD05FFF87DFD05FFF852FFFFFFF852FD04FF277D
+%FFFF27A8FF272752FFFFF87DFFF827CFCF2F070693688C99FFCACFCACFCA
+%FF998C686F060759CF7CF827FD05FFA852F8F87DFFFFFF5227FFFF52F87D
+%FFFFFF5227A8FFA827FD04FF52F852FF527DFFFF5227FFFFF827A8FFFFFF
+%2752FFFFFFF852FFFF27F8FFFFFFA8F852FD05FFF87DFFFFFF52F8A8FFFF
+%7D27A8FFFF27A8FF7DF852FFFFF827FFF827FFCF53062F6E928CC2FFFFCF
+%FFCFFFCFC28C926F2F077ECFA7F852FD07FFA8FD06277DFFFFFF7D27277D
+%527DFFFFFF7DF8A8FD04FF527DFFA827525252A8FFFFFF5227527D52A8FF
+%FFFFA8F852A8FFA82727A8FFA8F852A8FFFFFF7DF827FD04FF52277D5252
+%A8FFFFA8F8A8FFFF52FFFFFF2727A8F827CFCF2F07066F8C8C92FFCFCFCA
+%CFCFCF8C8C8C4B060D59CF7CF827FD0BFFA8FD09FFA8FD05FFA8FFA8FD09
+%FFA8A8FD07FFA8A8FD05FFA8FFA8FD05FFA8FFA8FFA8FD05FFA8FFA8FD05
+%FFA8FD05FFA8FFA8FD07FFA8FFF827AF2F2F070D4B928C8CA0FFCFFFCFFF
+%998C8C92280D067ECFA1F852FD63FFF8270707060D0607688C688C99C9CA
+%C9938C688C680D0607065A76F827FD63FFF8275A062F070D07528C928C92
+%8C928C928C928C2F070D062F072EF852FD63FFF84B842F597E0607064C8C
+%8C68928C8C688C6828060D0607060D52F827FD63FFF827FFCFCFCF7E060D
+%062F6F928C928C934B2F070D0684A85A59A1F852FD63FFF827CFCFCACFCA
+%590607060D06282728060D0607067ECACFCFCF7CF827FD63FFF827FFCFFF
+%CFFFCF59062F070D072F070D062F2FA8CFFFCFFFCFA7F852FD63FFF827CF
+%CFCACFCACF2F07060D0607060D06070653CFCFCACFCAFF7CF827FD63FFF8
+%27FFCFFFCFCFA82F070D59CFA8A8A859060D07FD04CFFFCFA1F852FD63FF
+%F827CFCFCACFCFA82F0D2FCFCACFCFCFA80D060DA8CFCACFCAFF7CF827FD
+%63FFF827FFCFFFCFFFCFFFA8FFCFFFCFFFCFFF7E7EA8FFCFFFCFFFFFA7F8
+%52FD63FFFD09F820FD07F820FD07F820F8F827FD63FF27F827F820F827F8
+%20F827F820F827F820F827F820F827F820F827F87CFDE2FFFF
+%%EndData
+%%EndComments
+%%BeginDefaults
+%%ViewingOrientation: 1 0 0 1
+%%EndDefaults
+%%BeginProlog
+%%BeginResource: procset Adobe_AGM_Utils 1.0 0
+%%Version: 1.0 0
+%%Copyright: Copyright (C) 2000-2003 Adobe Systems, Inc.  All Rights Reserved.
+systemdict /setpacking known
+{
+	currentpacking
+	true setpacking
+} if
+userdict /Adobe_AGM_Utils 68 dict dup begin put
+/bdf
+{
+	bind def
+} bind def
+/nd{
+	null def
+}bdf
+/xdf
+{
+	exch def
+}bdf
+/ldf
+{
+	load def
+}bdf
+/ddf
+{
+	put
+}bdf	
+/xddf
+{
+	3 -1 roll put
+}bdf	
+/xpt
+{
+	exch put
+}bdf
+/ndf
+{
+	exch dup where{
+		pop pop pop
+	}{
+		xdf
+	}ifelse
+}def
+/cdndf
+{
+	exch dup currentdict exch known{
+		pop pop
+	}{
+		exch def
+	}ifelse
+}def
+/bdict
+{
+	mark
+}bdf
+/edict
+{
+	counttomark 2 idiv dup dict begin {def} repeat pop currentdict end
+}def
+/ps_level
+	/languagelevel where{
+		pop systemdict /languagelevel get exec
+	}{
+		1
+	}ifelse
+def
+/level2
+	ps_level 2 ge
+def
+/level3
+	ps_level 3 ge
+def
+/ps_version
+	{version cvr} stopped {
+		-1
+	}if
+def
+/makereadonlyarray
+{
+	/packedarray where{
+		pop packedarray
+	}{
+		array astore readonly
+	}ifelse
+}bdf
+/map_reserved_ink_name
+{
+	dup type /stringtype eq{
+		dup /Red eq{
+			pop (_Red_)
+		}{
+			dup /Green eq{
+				pop (_Green_)
+			}{
+				dup /Blue eq{
+					pop (_Blue_)
+				}{
+					dup () cvn eq{
+						pop (Process)
+					}if
+				}ifelse
+			}ifelse
+		}ifelse
+	}if
+}bdf
+/AGMUTIL_GSTATE 22 dict def
+/get_gstate
+{
+	AGMUTIL_GSTATE begin
+	/AGMUTIL_GSTATE_clr_spc currentcolorspace def
+	/AGMUTIL_GSTATE_clr_indx 0 def
+	/AGMUTIL_GSTATE_clr_comps 12 array def
+	mark currentcolor counttomark
+		{AGMUTIL_GSTATE_clr_comps AGMUTIL_GSTATE_clr_indx 3 -1 roll put
+		/AGMUTIL_GSTATE_clr_indx AGMUTIL_GSTATE_clr_indx 1 add def} repeat pop
+	/AGMUTIL_GSTATE_fnt rootfont def
+	/AGMUTIL_GSTATE_lw currentlinewidth def
+	/AGMUTIL_GSTATE_lc currentlinecap def
+	/AGMUTIL_GSTATE_lj currentlinejoin def
+	/AGMUTIL_GSTATE_ml currentmiterlimit def
+	currentdash /AGMUTIL_GSTATE_do xdf /AGMUTIL_GSTATE_da xdf
+	/AGMUTIL_GSTATE_sa currentstrokeadjust def
+	/AGMUTIL_GSTATE_clr_rnd currentcolorrendering def
+	/AGMUTIL_GSTATE_op currentoverprint def
+	/AGMUTIL_GSTATE_bg currentblackgeneration cvlit def
+	/AGMUTIL_GSTATE_ucr currentundercolorremoval cvlit def
+	currentcolortransfer cvlit /AGMUTIL_GSTATE_gy_xfer xdf cvlit /AGMUTIL_GSTATE_b_xfer xdf
+		cvlit /AGMUTIL_GSTATE_g_xfer xdf cvlit /AGMUTIL_GSTATE_r_xfer xdf
+	/AGMUTIL_GSTATE_ht currenthalftone def
+	/AGMUTIL_GSTATE_flt currentflat def
+	end
+}def
+/set_gstate
+{
+	AGMUTIL_GSTATE begin
+	AGMUTIL_GSTATE_clr_spc setcolorspace
+	AGMUTIL_GSTATE_clr_indx {AGMUTIL_GSTATE_clr_comps AGMUTIL_GSTATE_clr_indx 1 sub get
+	/AGMUTIL_GSTATE_clr_indx AGMUTIL_GSTATE_clr_indx 1 sub def} repeat setcolor
+	AGMUTIL_GSTATE_fnt setfont
+	AGMUTIL_GSTATE_lw setlinewidth
+	AGMUTIL_GSTATE_lc setlinecap
+	AGMUTIL_GSTATE_lj setlinejoin
+	AGMUTIL_GSTATE_ml setmiterlimit
+	AGMUTIL_GSTATE_da AGMUTIL_GSTATE_do setdash
+	AGMUTIL_GSTATE_sa setstrokeadjust
+	AGMUTIL_GSTATE_clr_rnd setcolorrendering
+	AGMUTIL_GSTATE_op setoverprint
+	AGMUTIL_GSTATE_bg cvx setblackgeneration
+	AGMUTIL_GSTATE_ucr cvx setundercolorremoval
+	AGMUTIL_GSTATE_r_xfer cvx AGMUTIL_GSTATE_g_xfer cvx AGMUTIL_GSTATE_b_xfer cvx
+		AGMUTIL_GSTATE_gy_xfer cvx setcolortransfer
+	AGMUTIL_GSTATE_ht /HalftoneType get dup 9 eq exch 100 eq or
+		{
+		currenthalftone /HalftoneType get AGMUTIL_GSTATE_ht /HalftoneType get ne
+			{
+			  mark AGMUTIL_GSTATE_ht {sethalftone} stopped cleartomark
+			} if
+		}{
+		AGMUTIL_GSTATE_ht sethalftone
+		} ifelse
+	AGMUTIL_GSTATE_flt setflat
+	end
+}def
+/get_gstate_and_matrix
+{
+	AGMUTIL_GSTATE begin
+	/AGMUTIL_GSTATE_ctm matrix currentmatrix def
+	end
+	get_gstate
+}def
+/set_gstate_and_matrix
+{
+	set_gstate
+	AGMUTIL_GSTATE begin
+	AGMUTIL_GSTATE_ctm setmatrix
+	end
+}def
+/AGMUTIL_str256 256 string def
+/AGMUTIL_src256 256 string def
+/AGMUTIL_dst64 64 string def
+/AGMUTIL_srcLen nd
+/AGMUTIL_ndx nd
+/agm_sethalftone
+{
+	dup
+	begin
+		/_Data load
+		/Thresholds xdf
+	end
+	level3
+	{ sethalftone }{
+		dup /HalftoneType get 3 eq {
+			sethalftone
+		} {pop} ifelse
+	}ifelse
+} def
+/rdcmntline
+{
+	currentfile AGMUTIL_str256 readline pop
+	(%) anchorsearch {pop} if
+} bdf
+/filter_cmyk
+{	
+	dup type /filetype ne{
+		exch () /SubFileDecode filter
+	}
+	{
+		exch pop
+	}
+	ifelse
+	[
+	exch
+	{
+		AGMUTIL_src256 readstring pop
+		dup length /AGMUTIL_srcLen exch def
+		/AGMUTIL_ndx 0 def
+		AGMCORE_plate_ndx 4 AGMUTIL_srcLen 1 sub{
+			1 index exch get
+			AGMUTIL_dst64 AGMUTIL_ndx 3 -1 roll put
+			/AGMUTIL_ndx AGMUTIL_ndx 1 add def
+		}for
+		pop
+		AGMUTIL_dst64 0 AGMUTIL_ndx getinterval
+	}
+	bind
+	/exec cvx
+	] cvx
+} bdf
+/filter_indexed_devn
+{
+	cvi Names length mul names_index add Lookup exch get
+} bdf
+/filter_devn
+{	
+	4 dict begin
+	/srcStr xdf
+	/dstStr xdf
+	dup type /filetype ne{
+		0 () /SubFileDecode filter
+	}if
+	[
+	exch
+		[
+			/devicen_colorspace_dict /AGMCORE_gget cvx /begin cvx
+			currentdict /srcStr get /readstring cvx /pop cvx
+			/dup cvx /length cvx 0 /gt cvx [
+				Adobe_AGM_Utils /AGMUTIL_ndx 0 /ddf cvx
+				names_index Names length currentdict /srcStr get length 1 sub {
+					1 /index cvx /exch cvx /get cvx
+					currentdict /dstStr get /AGMUTIL_ndx /load cvx 3 -1 /roll cvx /put cvx
+					Adobe_AGM_Utils /AGMUTIL_ndx /AGMUTIL_ndx /load cvx 1 /add cvx /ddf cvx
+				} for
+				currentdict /dstStr get 0 /AGMUTIL_ndx /load cvx /getinterval cvx
+			] cvx /if cvx
+			/end cvx
+		] cvx
+		bind
+		/exec cvx
+	] cvx
+	end
+} bdf
+/AGMUTIL_imagefile nd
+/read_image_file
+{
+	AGMUTIL_imagefile 0 setfileposition
+	10 dict begin
+	/imageDict xdf
+	/imbufLen Width BitsPerComponent mul 7 add 8 idiv def
+	/imbufIdx 0 def
+	/origDataSource imageDict /DataSource get def
+	/origMultipleDataSources imageDict /MultipleDataSources get def
+	/origDecode imageDict /Decode get def
+	/dstDataStr imageDict /Width get colorSpaceElemCnt mul string def
+	/srcDataStrs [ imageDict begin
+		currentdict /MultipleDataSources known {MultipleDataSources {DataSource length}{1}ifelse}{1} ifelse
+		{
+			Width Decode length 2 div mul cvi string
+		} repeat
+		end ] def
+	imageDict /MultipleDataSources known {MultipleDataSources}{false} ifelse
+	{
+		/imbufCnt imageDict /DataSource get length def
+		/imbufs imbufCnt array def
+		0 1 imbufCnt 1 sub {
+			/imbufIdx xdf
+			imbufs imbufIdx imbufLen string put
+			imageDict /DataSource get imbufIdx [ AGMUTIL_imagefile imbufs imbufIdx get /readstring cvx /pop cvx ] cvx put
+		} for
+		DeviceN_PS2 {
+			imageDict begin
+		 	/DataSource [ DataSource /devn_sep_datasource cvx ] cvx def
+			/MultipleDataSources false def
+			/Decode [0 1] def
+			end
+		} if
+	}{
+		/imbuf imbufLen string def
+		Indexed_DeviceN level3 not and DeviceN_NoneName or {
+			imageDict begin
+		 	/DataSource [AGMUTIL_imagefile Decode BitsPerComponent false 1 /filter_indexed_devn load dstDataStr srcDataStrs devn_alt_datasource /exec cvx] cvx def
+			/Decode [0 1] def
+			end
+		}{
+			imageDict /DataSource {AGMUTIL_imagefile imbuf readstring pop} put
+		} ifelse
+	} ifelse
+	imageDict exch
+	load exec
+	imageDict /DataSource origDataSource put
+	imageDict /MultipleDataSources origMultipleDataSources put
+	imageDict /Decode origDecode put	
+	end
+} bdf
+/write_image_file
+{
+	begin
+	{ (AGMUTIL_imagefile) (w+) file } stopped{
+		false
+	}{
+		Adobe_AGM_Utils/AGMUTIL_imagefile xddf
+		2 dict begin
+		/imbufLen Width BitsPerComponent mul 7 add 8 idiv def
+		MultipleDataSources {DataSource 0 get}{DataSource}ifelse type /filetype eq {
+			/imbuf imbufLen string def
+		}if
+		1 1 Height {
+			pop
+			MultipleDataSources {
+			 	0 1 DataSource length 1 sub {
+					DataSource type dup
+					/arraytype eq {
+						pop DataSource exch get exec
+					}{
+						/filetype eq {
+							DataSource exch get imbuf readstring pop
+						}{
+							DataSource exch get
+						} ifelse
+					} ifelse
+					AGMUTIL_imagefile exch writestring
+				} for
+			}{
+				DataSource type dup
+				/arraytype eq {
+					pop DataSource exec
+				}{
+					/filetype eq {
+						DataSource imbuf readstring pop
+					}{
+						DataSource
+					} ifelse
+				} ifelse
+				AGMUTIL_imagefile exch writestring
+			} ifelse
+		}for
+		end
+		true
+	}ifelse
+	end
+} bdf
+/close_image_file
+{
+	AGMUTIL_imagefile closefile (AGMUTIL_imagefile) deletefile
+}def
+statusdict /product known userdict /AGMP_current_show known not and{
+	/pstr statusdict /product get def
+	pstr (HP LaserJet 2200) eq 	
+	pstr (HP LaserJet 4000 Series) eq or
+	pstr (HP LaserJet 4050 Series ) eq or
+	pstr (HP LaserJet 8000 Series) eq or
+	pstr (HP LaserJet 8100 Series) eq or
+	pstr (HP LaserJet 8150 Series) eq or
+	pstr (HP LaserJet 5000 Series) eq or
+	pstr (HP LaserJet 5100 Series) eq or
+	pstr (HP Color LaserJet 4500) eq or
+	pstr (HP Color LaserJet 4600) eq or
+	pstr (HP LaserJet 5Si) eq or
+	pstr (HP LaserJet 1200 Series) eq or
+	pstr (HP LaserJet 1300 Series) eq or
+	pstr (HP LaserJet 4100 Series) eq or
+	{
+ 		userdict /AGMP_current_show /show load put
+		userdict /show {
+		  currentcolorspace 0 get
+		  /Pattern eq
+		  {false charpath f}
+		  {AGMP_current_show} ifelse
+		} put
+	}if
+	currentdict /pstr undef
+} if
+/consumeimagedata
+{
+	begin
+	currentdict /MultipleDataSources known not
+		{/MultipleDataSources false def} if
+	MultipleDataSources
+		{
+		1 dict begin
+		/flushbuffer Width cvi string def
+		1 1 Height cvi
+			{
+			pop
+			0 1 DataSource length 1 sub
+				{
+				DataSource exch get
+				dup type dup
+				/filetype eq
+					{
+					exch flushbuffer readstring pop pop
+					}if
+				/arraytype eq
+					{
+					exec pop
+					}if
+				}for
+			}for
+		end
+		}
+		{
+		/DataSource load type dup
+		/filetype eq
+			{
+			1 dict begin
+			/flushbuffer Width Decode length 2 div mul cvi string def
+			1 1 Height { pop DataSource flushbuffer readstring pop pop} for
+			end
+			}if
+		/arraytype eq
+			{
+			1 1 Height { pop DataSource pop } for
+			}if
+		}ifelse
+	end
+}bdf
+/addprocs
+{
+	  2{/exec load}repeat
+	  3 1 roll
+	  [ 5 1 roll ] bind cvx
+}def
+/modify_halftone_xfer
+{
+	currenthalftone dup length dict copy begin
+	 currentdict 2 index known{
+	 	1 index load dup length dict copy begin
+		currentdict/TransferFunction known{
+			/TransferFunction load
+		}{
+			currenttransfer
+		}ifelse
+		 addprocs /TransferFunction xdf
+		 currentdict end def
+		currentdict end sethalftone
+	}{
+		currentdict/TransferFunction known{
+			/TransferFunction load
+		}{
+			currenttransfer
+		}ifelse
+		addprocs /TransferFunction xdf
+		currentdict end sethalftone		
+		pop
+	}ifelse
+}def
+/clonearray
+{
+	dup xcheck exch
+	dup length array exch
+	Adobe_AGM_Core/AGMCORE_tmp -1 ddf
+	{
+	Adobe_AGM_Core/AGMCORE_tmp AGMCORE_tmp 1 add ddf
+	dup type /dicttype eq
+		{
+			AGMCORE_tmp
+			exch
+			clonedict
+			Adobe_AGM_Core/AGMCORE_tmp 4 -1 roll ddf
+		} if
+	dup type /arraytype eq
+		{
+			AGMCORE_tmp exch
+			clonearray
+			Adobe_AGM_Core/AGMCORE_tmp 4 -1 roll ddf
+		} if
+	exch dup
+	AGMCORE_tmp 4 -1 roll put
+	}forall
+	exch {cvx} if
+}bdf
+/clonedict
+{
+	dup length dict
+	begin
+		{
+		dup type /dicttype eq
+			{
+				clonedict
+			} if
+		dup type /arraytype eq
+			{
+				clonearray
+			} if
+		def
+		}forall
+	currentdict
+	end
+}bdf
+/DeviceN_PS2
+{
+	/currentcolorspace AGMCORE_gget 0 get /DeviceN eq level3 not and
+} bdf
+/Indexed_DeviceN
+{
+	/indexed_colorspace_dict AGMCORE_gget dup null ne {
+		/CSD known
+	}{
+		pop false
+	} ifelse
+} bdf
+/DeviceN_NoneName
+{	
+	/Names where {
+		pop
+		false Names
+		{
+			(None) eq or
+		} forall
+	}{
+		false
+	}ifelse
+} bdf
+/DeviceN_PS2_inRip_seps
+{
+	/AGMCORE_in_rip_sep where
+	{
+		pop dup type dup /arraytype eq exch /packedarraytype eq or
+		{
+			dup 0 get /DeviceN eq level3 not and AGMCORE_in_rip_sep and
+			{
+				/currentcolorspace exch AGMCORE_gput
+				false
+			}
+			{
+				true
+			}ifelse
+		}
+		{
+			true
+		} ifelse
+	}
+	{
+		true
+	} ifelse
+} bdf
+/base_colorspace_type
+{
+	dup type /arraytype eq {0 get} if
+} bdf
+/doc_setup{
+	Adobe_AGM_Utils begin
+}bdf
+/doc_trailer{
+	currentdict Adobe_AGM_Utils eq{
+		end
+	}if
+}bdf
+systemdict /setpacking known
+{
+	setpacking
+} if
+%%EndResource
+%%BeginResource: procset Adobe_AGM_Core 2.0 0
+%%Version: 2.0 0
+%%Copyright: Copyright (C) 1997-2003 Adobe Systems, Inc.  All Rights Reserved.
+systemdict /setpacking known
+{
+	currentpacking
+	true setpacking
+} if
+userdict /Adobe_AGM_Core 216 dict dup begin put
+/nd{
+	null def
+}bind def
+/Adobe_AGM_Core_Id /Adobe_AGM_Core_2.0_0 def
+/AGMCORE_str256 256 string def
+/AGMCORE_save nd
+/AGMCORE_graphicsave nd
+/AGMCORE_c 0 def
+/AGMCORE_m 0 def
+/AGMCORE_y 0 def
+/AGMCORE_k 0 def
+/AGMCORE_cmykbuf 4 array def
+/AGMCORE_screen [currentscreen] cvx def
+/AGMCORE_tmp 0 def
+/AGMCORE_&setgray nd
+/AGMCORE_&setcolor nd
+/AGMCORE_&setcolorspace nd
+/AGMCORE_&setcmykcolor nd
+/AGMCORE_cyan_plate nd
+/AGMCORE_magenta_plate nd
+/AGMCORE_yellow_plate nd
+/AGMCORE_black_plate nd
+/AGMCORE_plate_ndx nd
+/AGMCORE_get_ink_data nd
+/AGMCORE_is_cmyk_sep nd
+/AGMCORE_host_sep nd
+/AGMCORE_avoid_L2_sep_space nd
+/AGMCORE_distilling nd
+/AGMCORE_composite_job nd
+/AGMCORE_producing_seps nd
+/AGMCORE_ps_level -1 def
+/AGMCORE_ps_version -1 def
+/AGMCORE_environ_ok nd
+/AGMCORE_CSA_cache 0 dict def
+/AGMCORE_CSD_cache 0 dict def
+/AGMCORE_pattern_cache 0 dict def
+/AGMCORE_currentoverprint false def
+/AGMCORE_deltaX nd
+/AGMCORE_deltaY nd
+/AGMCORE_name nd
+/AGMCORE_sep_special nd
+/AGMCORE_err_strings 4 dict def
+/AGMCORE_cur_err nd
+/AGMCORE_ovp nd
+/AGMCORE_current_spot_alias false def
+/AGMCORE_inverting false def
+/AGMCORE_feature_dictCount nd
+/AGMCORE_feature_opCount nd
+/AGMCORE_feature_ctm nd
+/AGMCORE_ConvertToProcess false def
+/AGMCORE_Default_CTM matrix def
+/AGMCORE_Default_PageSize nd
+/AGMCORE_currentbg nd
+/AGMCORE_currentucr nd
+/AGMCORE_gradientcache 32 dict def
+/AGMCORE_in_pattern false def
+/knockout_unitsq nd
+/AGMCORE_CRD_cache where{
+	pop
+}{
+	/AGMCORE_CRD_cache 0 dict def
+}ifelse
+/AGMCORE_key_known
+{
+	where{
+		/Adobe_AGM_Core_Id known
+	}{
+		false
+	}ifelse
+}ndf
+/flushinput
+{
+	save
+	2 dict begin
+	/CompareBuffer 3 -1 roll def
+	/readbuffer 256 string def
+	mark
+	{
+	currentfile readbuffer {readline} stopped
+		{cleartomark mark}
+		{
+		not
+			{pop exit}
+		if
+		CompareBuffer eq
+			{exit}
+		if
+		}ifelse
+	}loop
+	cleartomark
+	end
+	restore
+}bdf
+/getspotfunction
+{
+	AGMCORE_screen exch pop exch pop
+	dup type /dicttype eq{
+		dup /HalftoneType get 1 eq{
+			/SpotFunction get
+		}{
+			dup /HalftoneType get 2 eq{
+				/GraySpotFunction get
+			}{
+				pop
+				{
+					abs exch abs 2 copy add 1 gt{
+						1 sub dup mul exch 1 sub dup mul add 1 sub
+					}{
+						dup mul exch dup mul add 1 exch sub
+					}ifelse
+				}bind
+			}ifelse
+		}ifelse
+	}if
+} def
+/clp_npth
+{
+	clip newpath
+} def
+/eoclp_npth
+{
+	eoclip newpath
+} def
+/npth_clp
+{
+	newpath clip
+} def
+/add_grad
+{
+	AGMCORE_gradientcache 3 1 roll put
+}bdf
+/exec_grad
+{
+	AGMCORE_gradientcache exch get exec
+}bdf
+/graphic_setup
+{
+	/AGMCORE_graphicsave save def
+	concat
+	0 setgray
+	0 setlinecap
+	0 setlinejoin
+	1 setlinewidth
+	[] 0 setdash
+	10 setmiterlimit
+	newpath
+	false setoverprint
+	false setstrokeadjust
+	Adobe_AGM_Core/spot_alias get exec
+	/Adobe_AGM_Image where {
+		pop
+		Adobe_AGM_Image/spot_alias 2 copy known{
+			get exec
+		}{
+			pop pop
+		}ifelse
+	} if
+	100 dict begin
+	/dictstackcount countdictstack def
+	/showpage {} def
+	mark
+} def
+/graphic_cleanup
+{
+	cleartomark
+	dictstackcount 1 countdictstack 1 sub {end}for
+	end
+	AGMCORE_graphicsave restore
+} def
+/compose_error_msg
+{
+	grestoreall initgraphics	
+	/Helvetica findfont 10 scalefont setfont
+	/AGMCORE_deltaY 100 def
+	/AGMCORE_deltaX 310 def
+	clippath pathbbox newpath pop pop 36 add exch 36 add exch moveto
+	0 AGMCORE_deltaY rlineto AGMCORE_deltaX 0 rlineto
+	0 AGMCORE_deltaY neg rlineto AGMCORE_deltaX neg 0 rlineto closepath
+	0 AGMCORE_&setgray
+	gsave 1 AGMCORE_&setgray fill grestore
+	1 setlinewidth gsave stroke grestore
+	currentpoint AGMCORE_deltaY 15 sub add exch 8 add exch moveto
+	/AGMCORE_deltaY 12 def
+	/AGMCORE_tmp 0 def
+	AGMCORE_err_strings exch get
+		{
+		dup 32 eq
+			{
+			pop
+			AGMCORE_str256 0 AGMCORE_tmp getinterval
+			stringwidth pop currentpoint pop add AGMCORE_deltaX 28 add gt
+				{
+				currentpoint AGMCORE_deltaY sub exch pop
+				clippath pathbbox pop pop pop 44 add exch moveto
+				} if
+			AGMCORE_str256 0 AGMCORE_tmp getinterval show ( ) show
+			0 1 AGMCORE_str256 length 1 sub
+				{
+				AGMCORE_str256 exch 0 put
+				}for
+			/AGMCORE_tmp 0 def
+			}
+			{
+				AGMCORE_str256 exch AGMCORE_tmp xpt
+				/AGMCORE_tmp AGMCORE_tmp 1 add def
+			} ifelse
+		} forall
+} bdf
+/doc_setup{
+	Adobe_AGM_Core begin
+	/AGMCORE_ps_version xdf
+	/AGMCORE_ps_level xdf
+	errordict /AGM_handleerror known not{
+		errordict /AGM_handleerror errordict /handleerror get put
+		errordict /handleerror {
+			Adobe_AGM_Core begin
+			$error /newerror get AGMCORE_cur_err null ne and{
+				$error /newerror false put
+				AGMCORE_cur_err compose_error_msg
+			}if
+			$error /newerror true put
+			end
+			errordict /AGM_handleerror get exec
+			} bind put
+		}if
+	/AGMCORE_environ_ok
+		ps_level AGMCORE_ps_level ge
+		ps_version AGMCORE_ps_version ge and
+		AGMCORE_ps_level -1 eq or
+	def
+	AGMCORE_environ_ok not
+		{/AGMCORE_cur_err /AGMCORE_bad_environ def} if
+	/AGMCORE_&setgray systemdict/setgray get def
+	level2{
+		/AGMCORE_&setcolor systemdict/setcolor get def
+		/AGMCORE_&setcolorspace systemdict/setcolorspace get def
+	}if
+	/AGMCORE_currentbg currentblackgeneration def
+	/AGMCORE_currentucr currentundercolorremoval def
+	/AGMCORE_distilling
+		/product where{
+			pop systemdict/setdistillerparams known product (Adobe PostScript Parser) ne and
+		}{
+			false
+		}ifelse
+	def
+	level2 not{
+		/xput{
+			dup load dup length exch maxlength eq{
+				dup dup load dup
+				length dup 0 eq {pop 1} if 2 mul dict copy def
+			}if
+			load begin
+				def
+ 			end
+		}def
+	}{
+		/xput{
+			load 3 1 roll put
+		}def
+	}ifelse
+	/AGMCORE_GSTATE AGMCORE_key_known not{
+		/AGMCORE_GSTATE 21 dict def
+		/AGMCORE_tmpmatrix matrix def
+		/AGMCORE_gstack 32 array def
+		/AGMCORE_gstackptr 0 def
+		/AGMCORE_gstacksaveptr 0 def
+		/AGMCORE_gstackframekeys 10 def
+		/AGMCORE_&gsave /gsave ldf
+		/AGMCORE_&grestore /grestore ldf
+		/AGMCORE_&grestoreall /grestoreall ldf
+		/AGMCORE_&save /save ldf
+		/AGMCORE_gdictcopy {
+			begin
+			{ def } forall
+			end
+		}def
+		/AGMCORE_gput {
+			AGMCORE_gstack AGMCORE_gstackptr get
+			3 1 roll
+			put
+		}def
+		/AGMCORE_gget {
+			AGMCORE_gstack AGMCORE_gstackptr get
+			exch
+			get
+		}def
+		/gsave {
+			AGMCORE_&gsave
+			AGMCORE_gstack AGMCORE_gstackptr get
+			AGMCORE_gstackptr 1 add
+			dup 32 ge {limitcheck} if
+			Adobe_AGM_Core exch
+			/AGMCORE_gstackptr xpt
+			AGMCORE_gstack AGMCORE_gstackptr get
+			AGMCORE_gdictcopy
+		}def
+		/grestore {
+			AGMCORE_&grestore
+			AGMCORE_gstackptr 1 sub
+			dup AGMCORE_gstacksaveptr lt {1 add} if
+			Adobe_AGM_Core exch
+			/AGMCORE_gstackptr xpt
+		}def
+		/grestoreall {
+			AGMCORE_&grestoreall
+			Adobe_AGM_Core
+			/AGMCORE_gstackptr AGMCORE_gstacksaveptr put
+		}def
+		/save {
+			AGMCORE_&save
+			AGMCORE_gstack AGMCORE_gstackptr get
+			AGMCORE_gstackptr 1 add
+			dup 32 ge {limitcheck} if
+			Adobe_AGM_Core begin
+				/AGMCORE_gstackptr exch def
+				/AGMCORE_gstacksaveptr AGMCORE_gstackptr def
+			end
+			AGMCORE_gstack AGMCORE_gstackptr get
+			AGMCORE_gdictcopy
+		}def
+		0 1 AGMCORE_gstack length 1 sub {
+				AGMCORE_gstack exch AGMCORE_gstackframekeys dict put
+		} for
+	}if
+	level3 /AGMCORE_&sysshfill AGMCORE_key_known not and
+	{
+		/AGMCORE_&sysshfill systemdict/shfill get def
+		/AGMCORE_&usrshfill /shfill load def
+		/AGMCORE_&sysmakepattern systemdict/makepattern get def
+		/AGMCORE_&usrmakepattern /makepattern load def
+	}if
+	/currentcmykcolor [0 0 0 0] AGMCORE_gput
+	/currentstrokeadjust false AGMCORE_gput
+	/currentcolorspace [/DeviceGray] AGMCORE_gput
+	/sep_tint 0 AGMCORE_gput
+	/devicen_tints [0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0] AGMCORE_gput
+	/sep_colorspace_dict null AGMCORE_gput
+	/devicen_colorspace_dict null AGMCORE_gput
+	/indexed_colorspace_dict null AGMCORE_gput
+	/currentcolor_intent () AGMCORE_gput
+	/customcolor_tint 1 AGMCORE_gput
+	<<
+	/MaxPatternItem currentsystemparams /MaxPatternCache get
+	>>
+	setuserparams
+	end
+}def
+/page_setup
+{
+	/setcmykcolor where{
+		pop
+		Adobe_AGM_Core/AGMCORE_&setcmykcolor /setcmykcolor load put
+	}if
+	Adobe_AGM_Core begin
+	/setcmykcolor
+	{
+		4 copy AGMCORE_cmykbuf astore /currentcmykcolor exch AGMCORE_gput
+		1 sub 4 1 roll
+		3 {
+			3 index add neg dup 0 lt {
+				pop 0
+			} if
+			3 1 roll
+		} repeat
+		setrgbcolor pop
+	}ndf
+	/currentcmykcolor
+	{
+		/currentcmykcolor AGMCORE_gget aload pop
+	}ndf
+	/setoverprint
+	{
+		pop
+	}ndf
+	/currentoverprint
+	{
+		false
+	}ndf
+	/AGMCORE_deviceDPI 72 0 matrix defaultmatrix dtransform dup mul exch dup mul add sqrt def
+	/AGMCORE_cyan_plate 1 0 0 0 test_cmyk_color_plate def
+	/AGMCORE_magenta_plate 0 1 0 0 test_cmyk_color_plate def
+	/AGMCORE_yellow_plate 0 0 1 0 test_cmyk_color_plate def
+	/AGMCORE_black_plate 0 0 0 1 test_cmyk_color_plate def
+	/AGMCORE_plate_ndx
+		AGMCORE_cyan_plate{
+			0
+		}{
+			AGMCORE_magenta_plate{
+				1
+			}{
+				AGMCORE_yellow_plate{
+					2
+				}{
+					AGMCORE_black_plate{
+						3
+					}{
+						4
+					}ifelse
+				}ifelse
+			}ifelse
+		}ifelse
+		def
+	/AGMCORE_have_reported_unsupported_color_space false def
+	/AGMCORE_report_unsupported_color_space
+	{
+		AGMCORE_have_reported_unsupported_color_space false eq
+		{
+			(Warning: Job contains content that cannot be separated with on-host methods. This content appears on the black plate, and knocks out all other plates.) ==
+			Adobe_AGM_Core /AGMCORE_have_reported_unsupported_color_space true ddf
+		} if
+	}def
+	/AGMCORE_composite_job
+		AGMCORE_cyan_plate AGMCORE_magenta_plate and AGMCORE_yellow_plate and AGMCORE_black_plate and def
+	/AGMCORE_in_rip_sep
+		/AGMCORE_in_rip_sep where{
+			pop AGMCORE_in_rip_sep
+		}{
+			AGMCORE_distilling
+			{
+				false
+			}{
+				userdict/Adobe_AGM_OnHost_Seps known{
+					false
+				}{
+					level2{
+						currentpagedevice/Separations 2 copy known{
+							get
+						}{
+							pop pop false
+						}ifelse
+					}{
+						false
+					}ifelse
+				}ifelse
+			}ifelse
+		}ifelse
+	def
+	/AGMCORE_producing_seps AGMCORE_composite_job not AGMCORE_in_rip_sep or def
+	/AGMCORE_host_sep AGMCORE_producing_seps AGMCORE_in_rip_sep not and def
+	/AGM_preserve_spots
+		/AGM_preserve_spots where{
+			pop AGM_preserve_spots
+		}{
+			AGMCORE_distilling AGMCORE_producing_seps or
+		}ifelse
+	def
+	/AGM_is_distiller_preserving_spotimages
+	{
+		currentdistillerparams/PreserveOverprintSettings known
+		{
+			currentdistillerparams/PreserveOverprintSettings get
+				{
+					currentdistillerparams/ColorConversionStrategy known
+					{
+						currentdistillerparams/ColorConversionStrategy get
+						/LeaveColorUnchanged eq
+					}{
+						true
+					}ifelse
+				}{
+					false
+				}ifelse
+		}{
+			false
+		}ifelse
+	}def
+	/convert_spot_to_process where {pop}{
+		/convert_spot_to_process
+		{
+			dup map_alias {
+				/Name get exch pop
+			} if
+			dup dup (None) eq exch (All) eq or
+				{
+				pop false
+				}{
+				AGMCORE_host_sep
+				{
+					gsave
+					1 0 0 0 setcmykcolor currentgray 1 exch sub
+					0 1 0 0 setcmykcolor currentgray 1 exch sub
+					0 0 1 0 setcmykcolor currentgray 1 exch sub
+					0 0 0 1 setcmykcolor currentgray 1 exch sub
+					add add add 0 eq
+					{
+						pop false
+					}{
+						false setoverprint
+						1 1 1 1 5 -1 roll findcmykcustomcolor 1 setcustomcolor
+						currentgray 0 eq
+					}ifelse
+					grestore
+				}{
+					AGMCORE_distilling
+					{
+						pop AGM_is_distiller_preserving_spotimages not
+					}{
+						Adobe_AGM_Core/AGMCORE_name xddf
+						false
+						Adobe_AGM_Core/AGMCORE_in_pattern known {Adobe_AGM_Core/AGMCORE_in_pattern get}{false} ifelse
+						not currentpagedevice/OverrideSeparations known and
+							{
+							currentpagedevice/OverrideSeparations get
+								{
+								/HqnSpots /ProcSet resourcestatus
+									{
+									pop pop pop true
+									}if
+								}if
+							}if					
+							{
+							AGMCORE_name /HqnSpots /ProcSet findresource /TestSpot get exec not
+							}{
+							gsave
+							[/Separation AGMCORE_name /DeviceGray {}]setcolorspace
+							false
+							currentpagedevice/SeparationColorNames 2 copy known
+							{
+								get
+								{ AGMCORE_name eq or}forall
+							not
+							}{
+								pop pop pop true
+							}ifelse
+							grestore
+						}ifelse
+					}ifelse
+				}ifelse
+			}ifelse
+		}def
+	}ifelse
+	/convert_to_process where {pop}{
+		/convert_to_process
+		{
+			dup length 0 eq
+				{
+				pop false
+				}{
+				AGMCORE_host_sep
+				{
+				dup true exch
+					{
+					dup (Cyan) eq exch
+					dup (Magenta) eq 3 -1 roll or exch
+					dup (Yellow) eq 3 -1 roll or exch
+					dup (Black) eq 3 -1 roll or
+						{pop}
+						{convert_spot_to_process and}ifelse
+					}
+				forall
+					{
+					true exch
+						{
+						dup (Cyan) eq exch
+						dup (Magenta) eq 3 -1 roll or exch
+						dup (Yellow) eq 3 -1 roll or exch
+						(Black) eq or and
+						}forall
+						not
+					}{pop false}ifelse
+				}{
+				false exch
+					{
+					dup (Cyan) eq exch
+					dup (Magenta) eq 3 -1 roll or exch
+					dup (Yellow) eq 3 -1 roll or exch
+					dup (Black) eq 3 -1 roll or
+					{pop}
+					{convert_spot_to_process or}ifelse
+					}
+				forall
+				}ifelse
+			}ifelse
+		}def
+	}ifelse	
+	/AGMCORE_avoid_L2_sep_space
+		version cvr 2012 lt
+		level2 and
+		AGMCORE_producing_seps not and
+	def
+	/AGMCORE_is_cmyk_sep
+		AGMCORE_cyan_plate AGMCORE_magenta_plate or AGMCORE_yellow_plate or AGMCORE_black_plate or
+	def
+	/AGM_avoid_0_cmyk where{
+		pop AGM_avoid_0_cmyk
+	}{
+		AGM_preserve_spots
+		userdict/Adobe_AGM_OnHost_Seps known
+		userdict/Adobe_AGM_InRip_Seps known or
+		not and
+	}ifelse
+	{
+		/setcmykcolor[
+			{
+				4 copy add add add 0 eq currentoverprint and{
+					pop 0.0005
+				}if
+			}/exec cvx
+			/AGMCORE_&setcmykcolor load dup type/operatortype ne{
+				/exec cvx
+			}if
+		]cvx def
+	}if
+	AGMCORE_host_sep{
+		/setcolortransfer
+		{
+			AGMCORE_cyan_plate{
+				pop pop pop
+			}{
+			  	AGMCORE_magenta_plate{
+			  		4 3 roll pop pop pop
+			  	}{
+			  		AGMCORE_yellow_plate{
+			  			4 2 roll pop pop pop
+			  		}{
+			  			4 1 roll pop pop pop
+			  		}ifelse
+			  	}ifelse
+			}ifelse
+			settransfer
+		}	
+		def
+		/AGMCORE_get_ink_data
+			AGMCORE_cyan_plate{
+				{pop pop pop}
+			}{
+			  	AGMCORE_magenta_plate{
+			  		{4 3 roll pop pop pop}
+			  	}{
+			  		AGMCORE_yellow_plate{
+			  			{4 2 roll pop pop pop}
+			  		}{
+			  			{4 1 roll pop pop pop}
+			  		}ifelse
+			  	}ifelse
+			}ifelse
+		def
+		/AGMCORE_RemoveProcessColorNames
+			{
+			1 dict begin
+			/filtername
+				{
+				dup /Cyan eq 1 index (Cyan) eq or
+					{pop (_cyan_)}if
+				dup /Magenta eq 1 index (Magenta) eq or
+					{pop (_magenta_)}if
+				dup /Yellow eq 1 index (Yellow) eq or
+					{pop (_yellow_)}if
+				dup /Black eq 1 index (Black) eq or
+					{pop (_black_)}if
+				}def
+			dup type /arraytype eq
+				{[exch {filtername}forall]}
+				{filtername}ifelse
+			end
+			}def
+		/AGMCORE_IsSeparationAProcessColor
+			{
+			dup (Cyan) eq exch dup (Magenta) eq exch dup (Yellow) eq exch (Black) eq or or or
+			}def
+		level3 {
+			/AGMCORE_IsCurrentColor
+				{
+				gsave
+				false setoverprint
+				1 1 1 1 5 -1 roll findcmykcustomcolor 1 setcustomcolor
+				currentgray 0 eq
+				grestore
+				}def
+			/AGMCORE_filter_functiondatasource
+				{	
+				5 dict begin
+				/data_in xdf
+				data_in type /stringtype eq
+					{
+					/ncomp xdf
+					/comp xdf
+					/string_out data_in length ncomp idiv string def
+					0 ncomp data_in length 1 sub
+						{
+						string_out exch dup ncomp idiv exch data_in exch ncomp getinterval comp get 255 exch sub put
+						}for
+					string_out
+					}{
+					string /string_in xdf
+					/string_out 1 string def
+					/component xdf
+					[
+					data_in string_in /readstring cvx
+						[component /get cvx 255 /exch cvx /sub cvx string_out /exch cvx 0 /exch cvx /put cvx string_out]cvx
+						[/pop cvx ()]cvx /ifelse cvx
+					]cvx /ReusableStreamDecode filter
+				}ifelse
+				end
+				}def
+			/AGMCORE_separateShadingFunction
+				{
+				2 dict begin
+				/paint? xdf
+				/channel xdf
+					begin
+					FunctionType 0 eq
+						{
+						/DataSource channel Range length 2 idiv DataSource AGMCORE_filter_functiondatasource def
+						currentdict /Decode known
+							{/Decode Decode channel 2 mul 2 getinterval def}if
+						paint? not
+							{/Decode [1 1]def}if
+						}if
+					FunctionType 2 eq
+						{
+						paint?
+							{
+							/C0 [C0 channel get 1 exch sub] def
+							/C1 [C1 channel get 1 exch sub] def
+							}{
+							/C0 [1] def
+							/C1 [1] def
+							}ifelse			
+						}if
+					FunctionType 3 eq
+						{
+						/Functions [Functions {channel paint? AGMCORE_separateShadingFunction} forall] def			
+						}if
+					currentdict /Range known
+						{/Range [0 1] def}if
+					currentdict
+					end
+				end
+				}def
+			/AGMCORE_separateShading
+				{
+				3 -1 roll begin
+				currentdict /Function known
+					{
+					currentdict /Background known
+						{[1 index{Background 3 index get 1 exch sub}{1}ifelse]/Background xdf}if
+					Function 3 1 roll AGMCORE_separateShadingFunction /Function xdf
+					/ColorSpace [/DeviceGray] def
+					}{
+					ColorSpace dup type /arraytype eq {0 get}if /DeviceCMYK eq
+						{
+						/ColorSpace [/DeviceN [/_cyan_ /_magenta_ /_yellow_ /_black_] /DeviceCMYK {}] def
+						}{
+						ColorSpace dup 1 get AGMCORE_RemoveProcessColorNames 1 exch put
+						}ifelse
+					ColorSpace 0 get /Separation eq
+						{
+							{
+								[1 /exch cvx /sub cvx]cvx
+							}{
+								[/pop cvx 1]cvx
+							}ifelse
+							ColorSpace 3 3 -1 roll put
+							pop
+						}{
+							{
+								[exch ColorSpace 1 get length 1 sub exch sub /index cvx 1 /exch cvx /sub cvx ColorSpace 1 get length 1 add 1 /roll cvx ColorSpace 1 get length{/pop cvx} repeat]cvx
+							}{
+								pop [ColorSpace 1 get length {/pop cvx} repeat cvx 1]cvx
+							}ifelse
+							ColorSpace 3 3 -1 roll bind put
+						}ifelse
+					ColorSpace 2 /DeviceGray put																		
+					}ifelse
+				end
+				}def
+			/AGMCORE_separateShadingDict
+				{
+				dup /ColorSpace get
+				dup type /arraytype ne
+					{[exch]}if
+				dup 0 get /DeviceCMYK eq
+					{
+					exch begin
+					currentdict
+					AGMCORE_cyan_plate
+						{0 true}if
+					AGMCORE_magenta_plate
+						{1 true}if
+					AGMCORE_yellow_plate
+						{2 true}if
+					AGMCORE_black_plate
+						{3 true}if
+					AGMCORE_plate_ndx 4 eq
+						{0 false}if		
+					dup not currentoverprint and
+						{/AGMCORE_ignoreshade true def}if
+					AGMCORE_separateShading
+					currentdict
+					end exch
+					}if
+				dup 0 get /Separation eq
+					{
+					exch begin
+					ColorSpace 1 get dup /None ne exch /All ne and
+						{
+						ColorSpace 1 get AGMCORE_IsCurrentColor AGMCORE_plate_ndx 4 lt and ColorSpace 1 get AGMCORE_IsSeparationAProcessColor not and
+							{
+							ColorSpace 2 get dup type /arraytype eq {0 get}if /DeviceCMYK eq
+								{
+								/ColorSpace
+									[
+									/Separation
+									ColorSpace 1 get
+									/DeviceGray
+										[
+										ColorSpace 3 get /exec cvx
+										4 AGMCORE_plate_ndx sub -1 /roll cvx
+										4 1 /roll cvx
+										3 [/pop cvx]cvx /repeat cvx
+										1 /exch cvx /sub cvx
+										]cvx									
+									]def
+								}{
+								AGMCORE_report_unsupported_color_space
+								AGMCORE_black_plate not
+									{
+									currentdict 0 false AGMCORE_separateShading
+									}if
+								}ifelse
+							}{
+							currentdict ColorSpace 1 get AGMCORE_IsCurrentColor
+							0 exch
+							dup not currentoverprint and
+								{/AGMCORE_ignoreshade true def}if
+							AGMCORE_separateShading
+							}ifelse	
+						}if			
+					currentdict
+					end exch
+					}if
+				dup 0 get /DeviceN eq
+					{
+					exch begin
+					ColorSpace 1 get convert_to_process
+						{
+						ColorSpace 2 get dup type /arraytype eq {0 get}if /DeviceCMYK eq
+							{
+							/ColorSpace
+								[
+								/DeviceN
+								ColorSpace 1 get
+								/DeviceGray
+									[
+									ColorSpace 3 get /exec cvx
+									4 AGMCORE_plate_ndx sub -1 /roll cvx
+									4 1 /roll cvx
+									3 [/pop cvx]cvx /repeat cvx
+									1 /exch cvx /sub cvx
+									]cvx									
+								]def
+							}{
+							AGMCORE_report_unsupported_color_space
+							AGMCORE_black_plate not
+								{
+								currentdict 0 false AGMCORE_separateShading
+								/ColorSpace [/DeviceGray] def
+								}if
+							}ifelse
+						}{
+						currentdict
+						false -1 ColorSpace 1 get
+							{
+							AGMCORE_IsCurrentColor
+								{
+								1 add
+								exch pop true exch exit
+								}if
+							1 add
+							}forall
+						exch
+						dup not currentoverprint and
+							{/AGMCORE_ignoreshade true def}if
+						AGMCORE_separateShading
+						}ifelse
+					currentdict
+					end exch
+					}if
+				dup 0 get dup /DeviceCMYK eq exch dup /Separation eq exch /DeviceN eq or or not
+					{
+					exch begin
+					ColorSpace dup type /arraytype eq
+						{0 get}if
+					/DeviceGray ne
+						{
+						AGMCORE_report_unsupported_color_space
+						AGMCORE_black_plate not
+							{
+							ColorSpace 0 get /CIEBasedA eq
+								{
+								/ColorSpace [/Separation /_ciebaseda_ /DeviceGray {}] def
+								}if
+							ColorSpace 0 get dup /CIEBasedABC eq exch dup /CIEBasedDEF eq exch /DeviceRGB eq or or
+								{
+								/ColorSpace [/DeviceN [/_red_ /_green_ /_blue_] /DeviceRGB {}] def
+								}if
+							ColorSpace 0 get /CIEBasedDEFG eq
+								{
+								/ColorSpace [/DeviceN [/_cyan_ /_magenta_ /_yellow_ /_black_] /DeviceCMYK {}]
+								}if
+							currentdict 0 false AGMCORE_separateShading
+							}if
+						}if
+					currentdict
+					end exch
+					}if
+				pop
+				dup /AGMCORE_ignoreshade known
+					{
+					begin
+					/ColorSpace [/Separation (None) /DeviceGray {}] def
+					currentdict end
+					}if
+				}def
+			/shfill
+				{
+				clonedict
+				AGMCORE_separateShadingDict
+				dup /AGMCORE_ignoreshade known
+					{pop}
+					{AGMCORE_&sysshfill}ifelse
+				}def
+			/makepattern
+				{
+				exch
+				dup /PatternType get 2 eq
+					{
+					clonedict
+					begin
+					/Shading Shading AGMCORE_separateShadingDict def
+					currentdict end
+					exch AGMCORE_&sysmakepattern
+					}{
+					exch AGMCORE_&usrmakepattern
+					}ifelse
+				}def
+		}if
+	}if
+	AGMCORE_in_rip_sep{
+		/setcustomcolor
+		{
+			exch aload pop
+			dup 7 1 roll inRip_spot_has_ink not	{
+				4 {4 index mul 4 1 roll}
+				repeat
+				/DeviceCMYK setcolorspace
+				6 -2 roll pop pop
+			}{
+				Adobe_AGM_Core begin
+					/AGMCORE_k xdf /AGMCORE_y xdf /AGMCORE_m xdf /AGMCORE_c xdf
+				end
+				[/Separation 4 -1 roll /DeviceCMYK
+				{dup AGMCORE_c mul exch dup AGMCORE_m mul exch dup AGMCORE_y mul exch AGMCORE_k mul}
+				]
+				setcolorspace
+			}ifelse
+			setcolor
+		}ndf
+		/setseparationgray
+		{
+			[/Separation (All) /DeviceGray {}] setcolorspace_opt
+			1 exch sub setcolor
+		}ndf
+	}{
+		/setseparationgray
+		{
+			AGMCORE_&setgray
+		}ndf
+	}ifelse
+	/findcmykcustomcolor
+	{
+		5 makereadonlyarray
+	}ndf
+	/setcustomcolor
+	{
+		exch aload pop pop
+		4 {4 index mul 4 1 roll} repeat
+		setcmykcolor pop
+	}ndf
+	/has_color
+		/colorimage where{
+			AGMCORE_producing_seps{
+				pop true
+			}{
+				systemdict eq
+			}ifelse
+		}{
+			false
+		}ifelse
+	def
+	/map_index
+	{
+		1 index mul exch getinterval {255 div} forall
+	} bdf
+	/map_indexed_devn
+	{
+		Lookup Names length 3 -1 roll cvi map_index
+	} bdf
+	/n_color_components
+	{
+		base_colorspace_type
+		dup /DeviceGray eq{
+			pop 1
+		}{
+			/DeviceCMYK eq{
+				4
+			}{
+				3
+			}ifelse
+		}ifelse
+	}bdf
+	level2{
+		/mo /moveto ldf
+		/li /lineto ldf
+		/cv /curveto ldf
+		/knockout_unitsq
+		{
+			1 setgray
+			0 0 1 1 rectfill
+		}def
+		/level2ScreenFreq{
+			begin
+			60
+			HalftoneType 1 eq{
+				pop Frequency
+			}if
+			HalftoneType 2 eq{
+				pop GrayFrequency
+			}if
+			HalftoneType 5 eq{
+				pop Default level2ScreenFreq
+			}if
+			 end
+		}def
+		/currentScreenFreq{
+			currenthalftone level2ScreenFreq
+		}def
+		level2 /setcolorspace AGMCORE_key_known not and{
+			/AGMCORE_&&&setcolorspace /setcolorspace ldf
+			/AGMCORE_ReplaceMappedColor
+			{
+				dup type dup /arraytype eq exch /packedarraytype eq or
+				{
+					dup 0 get dup /Separation eq
+					{
+						pop
+						dup length array copy
+						dup dup 1 get
+						current_spot_alias
+						{
+							dup map_alias
+							{
+								begin
+								/sep_colorspace_dict currentdict AGMCORE_gput
+								pop pop	pop
+								[
+									/Separation Name
+									CSA map_csa
+									dup /MappedCSA xdf
+									/sep_colorspace_proc load
+								]
+								dup Name
+								end
+							}if
+						}if
+						map_reserved_ink_name 1 xpt
+					}{
+						/DeviceN eq
+						{
+							dup length array copy
+							dup dup 1 get [
+								exch {
+									current_spot_alias{
+										dup map_alias{
+											/Name get exch pop
+										}if
+									}if
+									map_reserved_ink_name
+								} forall
+							] 1 xpt
+						}if
+					}ifelse
+				}if
+			}def
+			/setcolorspace
+			{
+				dup type dup /arraytype eq exch /packedarraytype eq or
+				{
+					dup 0 get /Indexed eq
+					{
+						AGMCORE_distilling
+						{
+							/PhotoshopDuotoneList where
+							{
+								pop false
+							}{
+								true
+							}ifelse
+						}{
+							true
+						}ifelse
+						{
+							aload pop 3 -1 roll
+							AGMCORE_ReplaceMappedColor
+							3 1 roll 4 array astore
+						}if
+					}{
+						AGMCORE_ReplaceMappedColor
+					}ifelse
+				}if
+				DeviceN_PS2_inRip_seps {AGMCORE_&&&setcolorspace} if
+			}def
+		}if	
+	}{
+		/adj
+		{
+			currentstrokeadjust{
+				transform
+				0.25 sub round 0.25 add exch
+				0.25 sub round 0.25 add exch
+				itransform
+			}if
+		}def
+		/mo{
+			adj moveto
+		}def
+		/li{
+			adj lineto
+		}def
+		/cv{
+			6 2 roll adj
+			6 2 roll adj
+			6 2 roll adj curveto
+		}def
+		/knockout_unitsq
+		{
+			1 setgray
+			8 8 1 [8 0 0 8 0 0] {<ffffffffffffffff>} image
+		}def
+		/currentstrokeadjust{
+			/currentstrokeadjust AGMCORE_gget
+		}def
+		/setstrokeadjust{
+			/currentstrokeadjust exch AGMCORE_gput
+		}def
+		/currentScreenFreq{
+			currentscreen pop pop
+		}def
+		/setcolorspace
+		{
+			/currentcolorspace exch AGMCORE_gput
+		} def
+		/currentcolorspace
+		{
+			/currentcolorspace AGMCORE_gget
+		} def
+		/setcolor_devicecolor
+		{
+			base_colorspace_type
+			dup /DeviceGray eq{
+				pop setgray
+			}{
+				/DeviceCMYK eq{
+					setcmykcolor
+				}{
+					setrgbcolor
+				}ifelse
+			}ifelse
+		}def
+		/setcolor
+		{
+			currentcolorspace 0 get
+			dup /DeviceGray ne{
+				dup /DeviceCMYK ne{
+					dup /DeviceRGB ne{
+						dup /Separation eq{
+							pop
+							currentcolorspace 3 get exec
+							currentcolorspace 2 get
+						}{
+							dup /Indexed eq{
+								pop
+								currentcolorspace 3 get dup type /stringtype eq{
+									currentcolorspace 1 get n_color_components
+									3 -1 roll map_index
+								}{
+									exec
+								}ifelse
+								currentcolorspace 1 get
+							}{
+								/AGMCORE_cur_err /AGMCORE_invalid_color_space def
+								AGMCORE_invalid_color_space
+							}ifelse
+						}ifelse
+					}if
+				}if
+			}if
+			setcolor_devicecolor
+		} def
+	}ifelse
+	/sop /setoverprint ldf
+	/lw /setlinewidth ldf
+	/lc /setlinecap ldf
+	/lj /setlinejoin ldf
+	/ml /setmiterlimit ldf
+	/dsh /setdash ldf
+	/sadj /setstrokeadjust ldf
+	/gry /setgray ldf
+	/rgb /setrgbcolor ldf
+	/cmyk /setcmykcolor ldf
+	/sep /setsepcolor ldf
+	/devn /setdevicencolor ldf
+	/idx /setindexedcolor ldf
+	/colr /setcolor ldf
+	/csacrd /set_csa_crd ldf
+	/sepcs /setsepcolorspace ldf
+	/devncs /setdevicencolorspace ldf
+	/idxcs /setindexedcolorspace ldf
+	/cp /closepath ldf
+	/clp /clp_npth ldf
+	/eclp /eoclp_npth ldf
+	/f /fill ldf
+	/ef /eofill ldf
+	/@ /stroke ldf
+	/nclp /npth_clp ldf
+	/gset /graphic_setup ldf
+	/gcln /graphic_cleanup ldf
+	currentdict{
+		dup xcheck 1 index type dup /arraytype eq exch /packedarraytype eq or and {
+			bind
+		}if
+		def
+	}forall
+	/currentpagedevice currentpagedevice def
+/getrampcolor {
+/indx exch def
+0 1 NumComp 1 sub {
+dup
+Samples exch get
+dup type /stringtype eq { indx get } if
+exch
+Scaling exch get aload pop
+3 1 roll
+mul add
+} for
+ColorSpaceFamily /Separation eq
+	{
+	sep
+	}
+	{
+	ColorSpaceFamily /DeviceN eq
+		{
+		devn
+		}
+		{
+		setcolor
+		}ifelse
+	}ifelse
+} bind def
+/sssetbackground { aload pop setcolor } bind def
+/RadialShade {
+40 dict begin
+/ColorSpaceFamily exch def
+/background exch def
+/ext1 exch def
+/ext0 exch def
+/BBox exch def
+/r2 exch def
+/c2y exch def
+/c2x exch def
+/r1 exch def
+/c1y exch def
+/c1x exch def
+/rampdict exch def
+/setinkoverprint where {pop /setinkoverprint{pop}def}if
+gsave
+BBox length 0 gt {
+newpath
+BBox 0 get BBox 1 get moveto
+BBox 2 get BBox 0 get sub 0 rlineto
+0 BBox 3 get BBox 1 get sub rlineto
+BBox 2 get BBox 0 get sub neg 0 rlineto
+closepath
+clip
+newpath
+} if
+c1x c2x eq
+{
+c1y c2y lt {/theta 90 def}{/theta 270 def} ifelse
+}
+{
+/slope c2y c1y sub c2x c1x sub div def
+/theta slope 1 atan def
+c2x c1x lt c2y c1y ge and { /theta theta 180 sub def} if
+c2x c1x lt c2y c1y lt and { /theta theta 180 add def} if
+}
+ifelse
+gsave
+clippath
+c1x c1y translate
+theta rotate
+-90 rotate
+{ pathbbox } stopped
+{ 0 0 0 0 } if
+/yMax exch def
+/xMax exch def
+/yMin exch def
+/xMin exch def
+grestore
+xMax xMin eq yMax yMin eq or
+{
+grestore
+end
+}
+{
+/max { 2 copy gt { pop } {exch pop} ifelse } bind def
+/min { 2 copy lt { pop } {exch pop} ifelse } bind def
+rampdict begin
+40 dict begin
+background length 0 gt { background sssetbackground gsave clippath fill grestore } if
+gsave
+c1x c1y translate
+theta rotate
+-90 rotate
+/c2y c1x c2x sub dup mul c1y c2y sub dup mul add sqrt def
+/c1y 0 def
+/c1x 0 def
+/c2x 0 def
+ext0 {
+0 getrampcolor
+c2y r2 add r1 sub 0.0001 lt
+{
+c1x c1y r1 360 0 arcn
+pathbbox
+/aymax exch def
+/axmax exch def
+/aymin exch def
+/axmin exch def
+/bxMin xMin axmin min def
+/byMin yMin aymin min def
+/bxMax xMax axmax max def
+/byMax yMax aymax max def
+bxMin byMin moveto
+bxMax byMin lineto
+bxMax byMax lineto
+bxMin byMax lineto
+bxMin byMin lineto
+eofill
+}
+{
+c2y r1 add r2 le
+{
+c1x c1y r1 0 360 arc
+fill
+}
+{
+c2x c2y r2 0 360 arc fill
+r1 r2 eq
+{
+/p1x r1 neg def
+/p1y c1y def
+/p2x r1 def
+/p2y c1y def
+p1x p1y moveto p2x p2y lineto p2x yMin lineto p1x yMin lineto
+fill
+}
+{
+/AA r2 r1 sub c2y div def
+/theta AA 1 AA dup mul sub sqrt div 1 atan def
+/SS1 90 theta add dup sin exch cos div def
+/p1x r1 SS1 SS1 mul SS1 SS1 mul 1 add div sqrt mul neg def
+/p1y p1x SS1 div neg def
+/SS2 90 theta sub dup sin exch cos div def
+/p2x r1 SS2 SS2 mul SS2 SS2 mul 1 add div sqrt mul def
+/p2y p2x SS2 div neg def
+r1 r2 gt
+{
+/L1maxX p1x yMin p1y sub SS1 div add def
+/L2maxX p2x yMin p2y sub SS2 div add def
+}
+{
+/L1maxX 0 def
+/L2maxX 0 def
+}ifelse
+p1x p1y moveto p2x p2y lineto L2maxX L2maxX p2x sub SS2 mul p2y add lineto
+L1maxX L1maxX p1x sub SS1 mul p1y add lineto
+fill
+}
+ifelse
+}
+ifelse
+} ifelse
+} if
+c1x c2x sub dup mul
+c1y c2y sub dup mul
+add 0.5 exp
+0 dtransform
+dup mul exch dup mul add 0.5 exp 72 div
+0 72 matrix defaultmatrix dtransform dup mul exch dup mul add sqrt
+72 0 matrix defaultmatrix dtransform dup mul exch dup mul add sqrt
+1 index 1 index lt { exch } if pop
+/hires exch def
+hires mul
+/numpix exch def
+/numsteps NumSamples def
+/rampIndxInc 1 def
+/subsampling false def
+numpix 0 ne
+{
+NumSamples numpix div 0.5 gt
+{
+/numsteps numpix 2 div round cvi dup 1 le { pop 2 } if def
+/rampIndxInc NumSamples 1 sub numsteps div def
+/subsampling true def
+} if
+} if
+/xInc c2x c1x sub numsteps div def
+/yInc c2y c1y sub numsteps div def
+/rInc r2 r1 sub numsteps div def
+/cx c1x def
+/cy c1y def
+/radius r1 def
+newpath
+xInc 0 eq yInc 0 eq rInc 0 eq and and
+{
+0 getrampcolor
+cx cy radius 0 360 arc
+stroke
+NumSamples 1 sub getrampcolor
+cx cy radius 72 hires div add 0 360 arc
+0 setlinewidth
+stroke
+}
+{
+0
+numsteps
+{
+dup
+subsampling { round cvi } if
+getrampcolor
+cx cy radius 0 360 arc
+/cx cx xInc add def
+/cy cy yInc add def
+/radius radius rInc add def
+cx cy radius 360 0 arcn
+eofill
+rampIndxInc add
+}
+repeat
+pop
+} ifelse
+ext1 {
+c2y r2 add r1 lt
+{
+c2x c2y r2 0 360 arc
+fill
+}
+{
+c2y r1 add r2 sub 0.0001 le
+{
+c2x c2y r2 360 0 arcn
+pathbbox
+/aymax exch def
+/axmax exch def
+/aymin exch def
+/axmin exch def
+/bxMin xMin axmin min def
+/byMin yMin aymin min def
+/bxMax xMax axmax max def
+/byMax yMax aymax max def
+bxMin byMin moveto
+bxMax byMin lineto
+bxMax byMax lineto
+bxMin byMax lineto
+bxMin byMin lineto
+eofill
+}
+{
+c2x c2y r2 0 360 arc fill
+r1 r2 eq
+{
+/p1x r2 neg def
+/p1y c2y def
+/p2x r2 def
+/p2y c2y def
+p1x p1y moveto p2x p2y lineto p2x yMax lineto p1x yMax lineto
+fill
+}
+{
+/AA r2 r1 sub c2y div def
+/theta AA 1 AA dup mul sub sqrt div 1 atan def
+/SS1 90 theta add dup sin exch cos div def
+/p1x r2 SS1 SS1 mul SS1 SS1 mul 1 add div sqrt mul neg def
+/p1y c2y p1x SS1 div sub def
+/SS2 90 theta sub dup sin exch cos div def
+/p2x r2 SS2 SS2 mul SS2 SS2 mul 1 add div sqrt mul def
+/p2y c2y p2x SS2 div sub def
+r1 r2 lt
+{
+/L1maxX p1x yMax p1y sub SS1 div add def
+/L2maxX p2x yMax p2y sub SS2 div add def
+}
+{
+/L1maxX 0 def
+/L2maxX 0 def
+}ifelse
+p1x p1y moveto p2x p2y lineto L2maxX L2maxX p2x sub SS2 mul p2y add lineto
+L1maxX L1maxX p1x sub SS1 mul p1y add lineto
+fill
+}
+ifelse
+}
+ifelse
+} ifelse
+} if
+grestore
+grestore
+end
+end
+end
+} ifelse
+} bind def
+/GenStrips {
+40 dict begin
+/ColorSpaceFamily exch def
+/background exch def
+/ext1 exch def
+/ext0 exch def
+/BBox exch def
+/y2 exch def
+/x2 exch def
+/y1 exch def
+/x1 exch def
+/rampdict exch def
+/setinkoverprint where {pop /setinkoverprint{pop}def}if
+gsave
+BBox length 0 gt {
+newpath
+BBox 0 get BBox 1 get moveto
+BBox 2 get BBox 0 get sub 0 rlineto
+0 BBox 3 get BBox 1 get sub rlineto
+BBox 2 get BBox 0 get sub neg 0 rlineto
+closepath
+clip
+newpath
+} if
+x1 x2 eq
+{
+y1 y2 lt {/theta 90 def}{/theta 270 def} ifelse
+}
+{
+/slope y2 y1 sub x2 x1 sub div def
+/theta slope 1 atan def
+x2 x1 lt y2 y1 ge and { /theta theta 180 sub def} if
+x2 x1 lt y2 y1 lt and { /theta theta 180 add def} if
+}
+ifelse
+gsave
+clippath
+x1 y1 translate
+theta rotate
+{ pathbbox } stopped
+{ 0 0 0 0 } if
+/yMax exch def
+/xMax exch def
+/yMin exch def
+/xMin exch def
+grestore
+xMax xMin eq yMax yMin eq or
+{
+grestore
+end
+}
+{
+rampdict begin
+20 dict begin
+background length 0 gt { background sssetbackground gsave clippath fill grestore } if
+gsave
+x1 y1 translate
+theta rotate
+/xStart 0 def
+/xEnd x2 x1 sub dup mul y2 y1 sub dup mul add 0.5 exp def
+/ySpan yMax yMin sub def
+/numsteps NumSamples def
+/rampIndxInc 1 def
+/subsampling false def
+xStart 0 transform
+xEnd 0 transform
+3 -1 roll
+sub dup mul
+3 1 roll
+sub dup mul
+add 0.5 exp 72 div
+0 72 matrix defaultmatrix dtransform dup mul exch dup mul add sqrt
+72 0 matrix defaultmatrix dtransform dup mul exch dup mul add sqrt
+1 index 1 index lt { exch } if pop
+mul
+/numpix exch def
+numpix 0 ne
+{
+NumSamples numpix div 0.5 gt
+{
+/numsteps numpix 2 div round cvi dup 1 le { pop 2 } if def
+/rampIndxInc NumSamples 1 sub numsteps div def
+/subsampling true def
+} if
+} if
+ext0 {
+0 getrampcolor
+xMin xStart lt
+{ xMin yMin xMin neg ySpan rectfill } if
+} if
+/xInc xEnd xStart sub numsteps div def
+/x xStart def
+0
+numsteps
+{
+dup
+subsampling { round cvi } if
+getrampcolor
+x yMin xInc ySpan rectfill
+/x x xInc add def
+rampIndxInc add
+}
+repeat
+pop
+ext1 {
+xMax xEnd gt
+{ xEnd yMin xMax xEnd sub ySpan rectfill } if
+} if
+grestore
+grestore
+end
+end
+end
+} ifelse
+} bind def
+}def
+/page_trailer
+{
+	end
+}def
+/doc_trailer{
+}def
+systemdict /findcolorrendering known{
+	/findcolorrendering systemdict /findcolorrendering get def
+}if
+systemdict /setcolorrendering known{
+	/setcolorrendering systemdict /setcolorrendering get def
+}if
+/test_cmyk_color_plate
+{
+	gsave
+	setcmykcolor currentgray 1 ne
+	grestore
+}def
+/inRip_spot_has_ink
+{
+	dup Adobe_AGM_Core/AGMCORE_name xddf
+	convert_spot_to_process not
+}def
+/map255_to_range
+{
+	1 index sub
+	3 -1 roll 255 div mul add
+}def
+/set_csa_crd
+{
+	/sep_colorspace_dict null AGMCORE_gput
+	begin
+		CSA map_csa setcolorspace_opt
+		set_crd
+	end
+}
+def
+/setsepcolor
+{
+	/sep_colorspace_dict AGMCORE_gget begin
+		dup /sep_tint exch AGMCORE_gput
+		TintProc
+	end
+} def
+/setdevicencolor
+{
+	/devicen_colorspace_dict AGMCORE_gget begin
+		Names length copy
+		Names length 1 sub -1 0
+		{
+			/devicen_tints AGMCORE_gget 3 1 roll xpt
+		} for
+		TintProc
+	end
+} def
+/sep_colorspace_proc
+{
+	Adobe_AGM_Core/AGMCORE_tmp xddf
+	/sep_colorspace_dict AGMCORE_gget begin
+	currentdict/Components known{
+		Components aload pop
+		TintMethod/Lab eq{
+			2 {AGMCORE_tmp mul NComponents 1 roll} repeat
+			LMax sub AGMCORE_tmp mul LMax add  NComponents 1 roll
+		}{
+			TintMethod/Subtractive eq{
+				NComponents{
+					AGMCORE_tmp mul NComponents 1 roll
+				}repeat
+			}{
+				NComponents{
+					1 sub AGMCORE_tmp mul 1 add  NComponents 1 roll
+				} repeat
+			}ifelse
+		}ifelse
+	}{
+		ColorLookup AGMCORE_tmp ColorLookup length 1 sub mul round cvi get
+		aload pop
+	}ifelse
+	end
+} def
+/sep_colorspace_gray_proc
+{
+	Adobe_AGM_Core/AGMCORE_tmp xddf
+	/sep_colorspace_dict AGMCORE_gget begin
+	GrayLookup AGMCORE_tmp GrayLookup length 1 sub mul round cvi get
+	end
+} def
+/sep_proc_name
+{
+	dup 0 get
+	dup /DeviceRGB eq exch /DeviceCMYK eq or level2 not and has_color not and{
+		pop [/DeviceGray]
+		/sep_colorspace_gray_proc
+	}{
+		/sep_colorspace_proc
+	}ifelse
+} def
+/setsepcolorspace
+{
+	current_spot_alias{
+		dup begin
+			Name map_alias{
+				exch pop
+			}if
+		end
+	}if
+	dup /sep_colorspace_dict exch AGMCORE_gput
+	begin
+	/MappedCSA CSA map_csa def
+	Adobe_AGM_Core/AGMCORE_sep_special Name dup () eq exch (All) eq or ddf
+	AGMCORE_avoid_L2_sep_space{
+		[/Indexed MappedCSA sep_proc_name 255 exch
+			{ 255 div } /exec cvx 3 -1 roll [ 4 1 roll load /exec cvx ] cvx
+		] setcolorspace_opt
+		/TintProc {
+			255 mul round cvi setcolor
+		}bdf
+	}{
+		MappedCSA 0 get /DeviceCMYK eq
+		currentdict/Components known and
+		AGMCORE_sep_special not and{
+			/TintProc [
+				Components aload pop Name findcmykcustomcolor
+				/exch cvx /setcustomcolor cvx
+			] cvx bdf
+		}{
+ 			AGMCORE_host_sep Name (All) eq and{
+ 				/TintProc {
+					1 exch sub setseparationgray
+				}bdf
+ 			}{
+				AGMCORE_in_rip_sep MappedCSA 0 get /DeviceCMYK eq and
+				AGMCORE_host_sep or
+				Name () eq and{
+					/TintProc [
+						MappedCSA sep_proc_name exch 0 get /DeviceCMYK eq{
+							cvx /setcmykcolor cvx
+						}{
+							cvx /setgray cvx
+						}ifelse
+					] cvx bdf
+				}{
+					AGMCORE_producing_seps MappedCSA 0 get dup /DeviceCMYK eq exch /DeviceGray eq or and AGMCORE_sep_special not and{
+	 					/TintProc [
+							/dup cvx
+							MappedCSA sep_proc_name cvx exch
+							0 get /DeviceGray eq{
+								1 /exch cvx /sub cvx 0 0 0 4 -1 /roll cvx
+							}if
+							/Name cvx /findcmykcustomcolor cvx /exch cvx
+							AGMCORE_host_sep{
+								AGMCORE_is_cmyk_sep
+								/Name cvx
+								/AGMCORE_IsSeparationAProcessColor load /exec cvx
+								/not cvx /and cvx
+							}{
+								Name inRip_spot_has_ink not
+							}ifelse
+							[
+		 						/pop cvx 1
+							] cvx /if cvx
+							/setcustomcolor cvx
+						] cvx bdf
+ 					}{
+						/TintProc /setcolor ldf
+						[/Separation Name MappedCSA sep_proc_name load ] setcolorspace_opt
+					}ifelse
+				}ifelse
+			}ifelse
+		}ifelse
+	}ifelse
+	set_crd
+	setsepcolor
+	end
+} def
+/additive_blend
+{
+  	3 dict begin
+  	/numarrays xdf
+  	/numcolors xdf
+  	0 1 numcolors 1 sub
+  		{
+  		/c1 xdf
+  		1
+  		0 1 numarrays 1 sub
+  			{
+			1 exch add /index cvx
+  			c1 /get cvx /mul cvx
+  			}for
+ 		numarrays 1 add 1 /roll cvx
+  		}for
+ 	numarrays [/pop cvx] cvx /repeat cvx
+  	end
+}def
+/subtractive_blend
+{
+	3 dict begin
+	/numarrays xdf
+	/numcolors xdf
+	0 1 numcolors 1 sub
+		{
+		/c1 xdf
+		1 1
+		0 1 numarrays 1 sub
+			{
+			1 3 3 -1 roll add /index cvx
+			c1 /get cvx /sub cvx /mul cvx
+			}for
+		/sub cvx
+		numarrays 1 add 1 /roll cvx
+		}for
+	numarrays [/pop cvx] cvx /repeat cvx
+	end
+}def
+/exec_tint_transform
+{
+	/TintProc [
+		/TintTransform cvx /setcolor cvx
+	] cvx bdf
+	MappedCSA setcolorspace_opt
+} bdf
+/devn_makecustomcolor
+{
+	2 dict begin
+	/names_index xdf
+	/Names xdf
+	1 1 1 1 Names names_index get findcmykcustomcolor
+	/devicen_tints AGMCORE_gget names_index get setcustomcolor
+	Names length {pop} repeat
+	end
+} bdf
+/setdevicencolorspace
+{
+	dup /AliasedColorants known {false}{true}ifelse
+	current_spot_alias and {
+		6 dict begin
+		/names_index 0 def
+		dup /names_len exch /Names get length def
+		/new_names names_len array def
+		/new_LookupTables names_len array def
+		/alias_cnt 0 def
+		dup /Names get
+		{
+			dup map_alias {
+				exch pop
+				dup /ColorLookup known {
+					dup begin
+					new_LookupTables names_index ColorLookup put
+					end
+				}{
+					dup /Components known {
+						dup begin
+						new_LookupTables names_index Components put
+						end
+					}{
+						dup begin
+						new_LookupTables names_index [null null null null] put
+						end
+					} ifelse
+				} ifelse
+				new_names names_index 3 -1 roll /Name get put
+				/alias_cnt alias_cnt 1 add def
+			}{
+				/name xdf				
+				new_names names_index name put
+				dup /LookupTables known {
+					dup begin
+					new_LookupTables names_index LookupTables names_index get put
+					end
+				}{
+					dup begin
+					new_LookupTables names_index [null null null null] put
+					end
+				} ifelse
+			} ifelse
+			/names_index names_index 1 add def
+		} forall
+		alias_cnt 0 gt {
+			/AliasedColorants true def
+			0 1 names_len 1 sub {
+				/names_index xdf
+				new_LookupTables names_index get 0 get null eq {
+					dup /Names get names_index get /name xdf
+					name (Cyan) eq name (Magenta) eq name (Yellow) eq name (Black) eq
+					or or or not {
+						/AliasedColorants false def
+						exit
+					} if
+				} if
+			} for
+			AliasedColorants {
+				dup begin
+				/Names new_names def
+				/AliasedColorants true def
+				/LookupTables new_LookupTables def
+				currentdict /TTTablesIdx known not {
+					/TTTablesIdx -1 def
+				} if
+				currentdict /NComponents known not {
+					/NComponents TintMethod /Subtractive eq {4}{3}ifelse def
+				} if
+				end
+			} if
+		}if
+		end
+	} if
+	dup /devicen_colorspace_dict exch AGMCORE_gput
+	begin
+	/MappedCSA CSA map_csa def
+	currentdict /AliasedColorants known {
+		AliasedColorants
+	}{
+		false
+	} ifelse
+	/TintTransform load type /nulltype eq or {
+		/TintTransform [
+			0 1 Names length 1 sub
+				{
+				/TTTablesIdx TTTablesIdx 1 add def
+				dup LookupTables exch get dup 0 get null eq
+					{
+					1 index
+					Names exch get
+					dup (Cyan) eq
+						{
+						pop exch
+						LookupTables length exch sub
+						/index cvx
+						0 0 0
+						}
+						{
+						dup (Magenta) eq
+							{
+							pop exch
+							LookupTables length exch sub
+							/index cvx
+							0 /exch cvx 0 0
+							}
+							{
+							(Yellow) eq
+								{
+								exch
+								LookupTables length exch sub
+								/index cvx
+								0 0 3 -1 /roll cvx 0
+								}
+								{
+								exch
+								LookupTables length exch sub
+								/index cvx
+								0 0 0 4 -1 /roll cvx
+								} ifelse
+							} ifelse
+						} ifelse
+					5 -1 /roll cvx /astore cvx
+					}
+					{
+					dup length 1 sub
+					LookupTables length 4 -1 roll sub 1 add
+					/index cvx /mul cvx /round cvx /cvi cvx /get cvx
+					} ifelse
+					Names length TTTablesIdx add 1 add 1 /roll cvx
+				} for
+			Names length [/pop cvx] cvx /repeat cvx
+			NComponents Names length
+  			TintMethod /Subtractive eq
+  				{
+  				subtractive_blend
+  				}
+  				{
+  				additive_blend
+  				} ifelse
+		] cvx bdf
+	} if
+	AGMCORE_host_sep {
+		Names convert_to_process {
+			exec_tint_transform
+		}
+		{	
+			currentdict /AliasedColorants known {
+				AliasedColorants not
+			}{
+				false
+			} ifelse
+			5 dict begin
+			/AvoidAliasedColorants xdf
+			/painted? false def
+			/names_index 0 def
+			/names_len Names length def
+			Names {
+				AvoidAliasedColorants {
+					/currentspotalias current_spot_alias def
+					false set_spot_alias
+				} if
+				AGMCORE_is_cmyk_sep {
+					dup (Cyan) eq AGMCORE_cyan_plate and exch
+					dup (Magenta) eq AGMCORE_magenta_plate and exch
+					dup (Yellow) eq AGMCORE_yellow_plate and exch
+					(Black) eq AGMCORE_black_plate and or or or {
+						/devicen_colorspace_dict AGMCORE_gget /TintProc [
+							Names names_index /devn_makecustomcolor cvx
+						] cvx ddf
+						/painted? true def
+					} if
+					painted? {exit} if
+				}{
+					0 0 0 0 5 -1 roll findcmykcustomcolor 1 setcustomcolor currentgray 0 eq {
+					/devicen_colorspace_dict AGMCORE_gget /TintProc [
+						Names names_index /devn_makecustomcolor cvx
+					] cvx ddf
+					/painted? true def
+					exit
+					} if
+				} ifelse
+				AvoidAliasedColorants {
+					currentspotalias set_spot_alias
+				} if
+				/names_index names_index 1 add def
+			} forall
+			painted? {
+				/devicen_colorspace_dict AGMCORE_gget /names_index names_index put
+			}{
+				/devicen_colorspace_dict AGMCORE_gget /TintProc [
+					names_len [/pop cvx] cvx /repeat cvx 1 /setseparationgray cvx
+					0 0 0 0 () /findcmykcustomcolor cvx 0 /setcustomcolor cvx
+				] cvx ddf
+			} ifelse
+			end
+		} ifelse
+	}
+	{
+		AGMCORE_in_rip_sep {
+			Names convert_to_process not
+		}{
+			level3
+		} ifelse
+		{
+			[/DeviceN Names MappedCSA /TintTransform load] setcolorspace_opt
+			/TintProc level3 not AGMCORE_in_rip_sep and {
+				[
+					Names /length cvx [/pop cvx] cvx /repeat cvx
+				] cvx bdf
+			}{
+				/setcolor ldf
+			} ifelse
+		}{
+			exec_tint_transform
+		} ifelse
+	} ifelse
+	set_crd
+	/AliasedColorants false def
+	end
+} def
+/setindexedcolorspace
+{
+	dup /indexed_colorspace_dict exch AGMCORE_gput
+	begin
+		currentdict /CSD known {
+			CSD get_csd /Names known {
+				CSD get_csd begin
+				currentdict devncs
+				AGMCORE_host_sep{
+					4 dict begin
+					/devnCompCnt Names length def
+					/NewLookup HiVal 1 add string def
+					0 1 HiVal {
+						/tableIndex xdf
+						Lookup dup type /stringtype eq {
+							devnCompCnt tableIndex map_index
+						}{
+							exec
+						} ifelse
+						setdevicencolor
+						currentgray
+						tableIndex exch
+						HiVal mul cvi
+						NewLookup 3 1 roll put
+					} for
+					[/Indexed currentcolorspace HiVal NewLookup] setcolorspace_opt
+					end
+				}{
+					level3
+					{
+					[/Indexed [/DeviceN Names MappedCSA /TintTransform load] HiVal Lookup] setcolorspace_opt
+					}{
+					[/Indexed MappedCSA HiVal
+						[
+						Lookup dup type /stringtype eq
+							{/exch cvx CSD get_csd /Names get length dup /mul cvx exch /getinterval cvx {255 div} /forall cvx}
+							{/exec cvx}ifelse
+							/TintTransform load /exec cvx
+						]cvx
+					]setcolorspace_opt
+					}ifelse
+				} ifelse
+				end
+			}{
+			} ifelse
+			set_crd
+		}
+		{
+			/MappedCSA CSA map_csa def
+			AGMCORE_host_sep level2 not and{
+				0 0 0 0 setcmykcolor
+			}{
+				[/Indexed MappedCSA
+				level2 not has_color not and{
+					dup 0 get dup /DeviceRGB eq exch /DeviceCMYK eq or{
+						pop [/DeviceGray]
+					}if
+					HiVal GrayLookup
+				}{
+					HiVal
+					currentdict/RangeArray known{
+						{
+							/indexed_colorspace_dict AGMCORE_gget begin
+							Lookup exch
+							dup HiVal gt{
+								pop HiVal
+							}if
+							NComponents mul NComponents getinterval {} forall
+							NComponents 1 sub -1 0{
+								RangeArray exch 2 mul 2 getinterval aload pop map255_to_range
+								NComponents 1 roll
+							}for
+							end
+						} bind
+					}{
+						Lookup
+					}ifelse
+				}ifelse
+				] setcolorspace_opt
+				set_crd
+			}ifelse
+		}ifelse
+	end
+}def
+/setindexedcolor
+{
+	AGMCORE_host_sep {
+		/indexed_colorspace_dict AGMCORE_gget dup /CSD known {
+			begin
+			CSD get_csd begin
+			map_indexed_devn
+			devn
+			end
+			end
+		}{
+			AGMCORE_gget/Lookup get 4 3 -1 roll map_index
+			pop setcmykcolor
+		} ifelse
+	}{
+		level3 not AGMCORE_in_rip_sep and /indexed_colorspace_dict AGMCORE_gget /CSD known and {
+			/indexed_colorspace_dict AGMCORE_gget /CSD get get_csd begin
+			map_indexed_devn
+			devn
+			end
+		}
+		{
+			setcolor
+		} ifelse
+	}ifelse
+} def
+/ignoreimagedata
+{
+	currentoverprint not{
+		gsave
+		dup clonedict begin
+		1 setgray
+		/Decode [0 1] def
+		/DataSource <FF> def
+		/MultipleDataSources false def
+		/BitsPerComponent 8 def
+		currentdict end
+		systemdict /image get exec
+		grestore
+		}if
+	consumeimagedata
+}def
+/add_csa
+{
+	Adobe_AGM_Core begin
+			/AGMCORE_CSA_cache xput
+	end
+}def
+/get_csa_by_name
+{
+	dup type dup /nametype eq exch /stringtype eq or{
+		Adobe_AGM_Core begin
+		1 dict begin
+		/name xdf
+		AGMCORE_CSA_cache
+		{
+			0 get name eq {
+				exit
+			}{
+				pop
+			} ifelse
+		}forall
+		end
+		end
+	}{
+		pop
+	} ifelse
+}def
+/map_csa
+{
+	dup type /nametype eq{
+		Adobe_AGM_Core/AGMCORE_CSA_cache get exch get
+	}if
+}def
+/add_csd
+{
+	Adobe_AGM_Core begin
+		/AGMCORE_CSD_cache xput
+	end
+}def
+/get_csd
+{
+	dup type /nametype eq{
+		Adobe_AGM_Core/AGMCORE_CSD_cache get exch get
+	}if
+}def
+/pattern_buf_init
+{
+	/count get 0 0 put
+} def
+/pattern_buf_next
+{
+	dup /count get dup 0 get
+	dup 3 1 roll
+	1 add 0 xpt
+	get				
+} def
+/cachepattern_compress
+{
+	5 dict begin
+	currentfile exch 0 exch /SubFileDecode filter /ReadFilter exch def
+	/patarray 20 dict def
+	/string_size 16000 def
+	/readbuffer string_size string def
+	currentglobal true setglobal
+	patarray 1 array dup 0 1 put /count xpt
+	setglobal
+	/LZWFilter
+	{
+		exch
+		dup length 0 eq {
+			pop
+		}{
+			patarray dup length 1 sub 3 -1 roll put
+		} ifelse
+		{string_size}{0}ifelse string
+	} /LZWEncode filter def
+	{ 		
+		ReadFilter readbuffer readstring
+		exch LZWFilter exch writestring
+		not {exit} if
+	} loop
+	LZWFilter closefile
+	patarray				
+	end
+}def
+/cachepattern
+{
+	2 dict begin
+	currentfile exch 0 exch /SubFileDecode filter /ReadFilter exch def
+	/patarray 20 dict def
+	currentglobal true setglobal
+	patarray 1 array dup 0 1 put /count xpt
+	setglobal
+	{
+		ReadFilter 16000 string readstring exch
+		patarray dup length 1 sub 3 -1 roll put
+		not {exit} if
+	} loop
+	patarray dup dup length 1 sub () put					
+	end	
+}def
+/add_pattern
+{
+	Adobe_AGM_Core begin
+		/AGMCORE_pattern_cache xput
+	end
+}def
+/get_pattern
+{
+	dup type /nametype eq{
+		Adobe_AGM_Core/AGMCORE_pattern_cache get exch get
+		dup wrap_paintproc
+	}if
+}def
+/wrap_paintproc
+{
+  statusdict /currentfilenameextend known{
+	  begin
+		/OldPaintProc /PaintProc load def
+		/PaintProc
+		{
+		  mark exch
+		  dup /OldPaintProc get stopped
+		  {closefile restore end} if
+		  cleartomark
+		}  def
+	  end
+  } {pop} ifelse
+} def
+/make_pattern
+{
+	dup matrix currentmatrix matrix concatmatrix 0 0 3 2 roll itransform
+	exch 3 index /XStep get 1 index exch 2 copy div cvi mul sub sub
+	exch 3 index /YStep get 1 index exch 2 copy div cvi mul sub sub
+	matrix translate exch matrix concatmatrix
+			  1 index begin
+		BBox 0 get XStep div cvi XStep mul /xshift exch neg def
+		BBox 1 get YStep div cvi YStep mul /yshift exch neg def
+		BBox 0 get xshift add
+		BBox 1 get yshift add
+		BBox 2 get xshift add
+		BBox 3 get yshift add
+		4 array astore
+		/BBox exch def
+		[ xshift yshift /translate load null /exec load ] dup
+		3 /PaintProc load put cvx /PaintProc exch def
+		end
+	gsave 0 setgray
+	makepattern
+	grestore
+}def
+/set_pattern
+{
+	dup /PatternType get 1 eq{
+		dup /PaintType get 1 eq{
+			currentoverprint sop [/DeviceGray] setcolorspace 0 setgray
+		}if
+	}if
+	setpattern
+}def
+/setcolorspace_opt
+{
+	dup currentcolorspace eq{
+		pop
+	}{
+		setcolorspace
+	}ifelse
+}def
+/updatecolorrendering
+{
+	currentcolorrendering/Intent known{
+		currentcolorrendering/Intent get
+	}{
+		null
+	}ifelse
+	Intent ne{
+		false
+		Intent
+		AGMCORE_CRD_cache {
+			exch pop
+			begin
+				dup Intent eq{
+					currentdict setcolorrendering_opt
+					end
+					exch pop true exch	
+					exit
+				}if
+			end
+		} forall
+		pop
+		not{
+			systemdict /findcolorrendering known{
+				Intent findcolorrendering pop
+				/ColorRendering findresource
+				dup length dict copy
+				setcolorrendering_opt
+			}if
+		}if
+	}if
+} def
+/add_crd
+{
+	AGMCORE_CRD_cache 3 1 roll put
+}def
+/set_crd
+{
+	AGMCORE_host_sep not level2 and{
+		currentdict/CRD known{
+			AGMCORE_CRD_cache CRD get dup null ne{
+				setcolorrendering_opt
+			}{
+				pop
+			}ifelse
+		}{
+			currentdict/Intent known{
+				updatecolorrendering
+			}if
+		}ifelse
+		currentcolorspace dup type /arraytype eq
+			{0 get}if
+		/DeviceRGB eq
+			{
+			currentdict/UCR known
+				{/UCR}{/AGMCORE_currentucr}ifelse
+			load setundercolorremoval
+			currentdict/BG known
+				{/BG}{/AGMCORE_currentbg}ifelse
+			load setblackgeneration
+			}if
+	}if
+}def
+/setcolorrendering_opt
+{
+	dup currentcolorrendering eq{
+		pop
+	}{
+		begin
+			/Intent Intent def
+			currentdict
+		end
+		setcolorrendering
+	}ifelse
+}def
+/cpaint_gcomp
+{
+	convert_to_process Adobe_AGM_Core/AGMCORE_ConvertToProcess xddf
+	Adobe_AGM_Core/AGMCORE_ConvertToProcess get not
+	{
+		(%end_cpaint_gcomp) flushinput
+	}if
+}def
+/cpaint_gsep
+{
+	Adobe_AGM_Core/AGMCORE_ConvertToProcess get
+	{	
+		(%end_cpaint_gsep) flushinput
+	}if
+}def
+/cpaint_gend
+{
+	newpath
+}def
+/path_rez
+{
+	dup 0 ne{
+		AGMCORE_deviceDPI exch div
+		dup 1 lt{
+			pop 1
+		}if
+		setflat
+	}{
+		pop
+	}ifelse 	
+}def
+/set_spot_alias_ary
+{
+	/AGMCORE_SpotAliasAry where{
+		pop pop
+	}{
+		Adobe_AGM_Core/AGMCORE_SpotAliasAry xddf
+		true set_spot_alias
+	}ifelse
+}def
+/set_spot_alias
+{
+	/AGMCORE_SpotAliasAry where{
+		/AGMCORE_current_spot_alias 3 -1 roll put
+	}{
+		pop
+	}ifelse
+}def
+/current_spot_alias
+{
+	/AGMCORE_SpotAliasAry where{
+		/AGMCORE_current_spot_alias get
+	}{
+		false
+	}ifelse
+}def
+/map_alias
+{
+	/AGMCORE_SpotAliasAry where{
+		begin
+			/AGMCORE_name xdf
+			false	
+			AGMCORE_SpotAliasAry{
+				dup/Name get AGMCORE_name eq{
+					save exch
+					/Adobe_AGM_Core currentdict def
+					/CSD get get_csd
+					exch restore
+					exch pop true
+					exit
+				}{
+					pop
+				}ifelse
+			}forall
+		end
+	}{
+		pop false
+	}ifelse
+}bdf
+/spot_alias
+{
+	true set_spot_alias
+	/AGMCORE_&setcustomcolor AGMCORE_key_known not {
+		Adobe_AGM_Core/AGMCORE_&setcustomcolor /setcustomcolor load put
+	} if
+	/customcolor_tint 1 AGMCORE_gput
+	Adobe_AGM_Core begin
+	/setcustomcolor
+	{
+		dup /customcolor_tint exch AGMCORE_gput
+		current_spot_alias{
+			1 index 4 get map_alias{
+				mark 3 1 roll
+				setsepcolorspace
+				counttomark 0 ne{
+					setsepcolor
+				}if
+				pop
+				pop
+			}{
+				AGMCORE_&setcustomcolor
+			}ifelse
+		}{
+			AGMCORE_&setcustomcolor
+		}ifelse
+	}bdf
+	end
+}def
+/begin_feature
+{
+	Adobe_AGM_Core/AGMCORE_feature_dictCount countdictstack put
+	count Adobe_AGM_Core/AGMCORE_feature_opCount 3 -1 roll put
+	{Adobe_AGM_Core/AGMCORE_feature_ctm matrix currentmatrix put}if
+}def
+/end_feature
+{
+	2 dict begin
+	/spd /setpagedevice load def
+	/setpagedevice { get_gstate spd set_gstate } def
+	stopped{$error/newerror false put}if
+	end
+	count Adobe_AGM_Core/AGMCORE_feature_opCount get sub dup 0 gt{{pop}repeat}{pop}ifelse
+	countdictstack Adobe_AGM_Core/AGMCORE_feature_dictCount get sub dup 0 gt{{end}repeat}{pop}ifelse
+	{Adobe_AGM_Core/AGMCORE_feature_ctm get setmatrix}if
+}def
+/set_negative
+{
+	Adobe_AGM_Core begin
+	/AGMCORE_inverting exch def
+	level2{
+		currentpagedevice/NegativePrint known{
+			currentpagedevice/NegativePrint get Adobe_AGM_Core/AGMCORE_inverting get ne{
+				true begin_feature true{
+						bdict /NegativePrint Adobe_AGM_Core/AGMCORE_inverting get edict setpagedevice
+				}end_feature
+			}if
+			/AGMCORE_inverting false def
+		}if
+	}if
+	AGMCORE_inverting{
+		[{1 exch sub}/exec load dup currenttransfer exch]cvx bind settransfer
+		gsave newpath clippath 1 /setseparationgray where{pop setseparationgray}{setgray}ifelse
+		/AGMIRS_&fill where {pop AGMIRS_&fill}{fill} ifelse grestore
+	}if
+	end
+}def
+/lw_save_restore_override {
+	/md where {
+		pop
+		md begin
+		initializepage
+		/initializepage{}def
+		/pmSVsetup{} def
+		/endp{}def
+		/pse{}def
+		/psb{}def
+		/orig_showpage where
+			{pop}
+			{/orig_showpage /showpage load def}
+		ifelse
+		/showpage {orig_showpage gR} def
+		end
+	}if
+}def
+/pscript_showpage_override {
+	/NTPSOct95 where
+	{
+		begin
+		showpage
+		save
+		/showpage /restore load def
+		/restore {exch pop}def
+		end
+	}if
+}def
+/driver_media_override
+{
+	/md where {
+		pop
+		md /initializepage known {
+			md /initializepage {} put
+		} if
+		md /rC known {
+			md /rC {4{pop}repeat} put
+		} if
+	}if
+	/mysetup where {
+		/mysetup [1 0 0 1 0 0] put
+	}if
+	Adobe_AGM_Core /AGMCORE_Default_CTM matrix currentmatrix put
+	level2
+		{Adobe_AGM_Core /AGMCORE_Default_PageSize currentpagedevice/PageSize get put}if
+}def
+/driver_check_media_override
+{
+	/PrepsDict where
+		{pop}
+		{
+		Adobe_AGM_Core /AGMCORE_Default_CTM get matrix currentmatrix ne
+		Adobe_AGM_Core /AGMCORE_Default_PageSize get type /arraytype eq
+			{
+			Adobe_AGM_Core /AGMCORE_Default_PageSize get 0 get currentpagedevice/PageSize get 0 get eq and
+			Adobe_AGM_Core /AGMCORE_Default_PageSize get 1 get currentpagedevice/PageSize get 1 get eq and
+			}if
+			{
+			Adobe_AGM_Core /AGMCORE_Default_CTM get setmatrix
+			}if
+		}ifelse
+}def
+AGMCORE_err_strings begin
+	/AGMCORE_bad_environ (Environment not satisfactory for this job. Ensure that the PPD is correct or that the PostScript level requested is supported by this printer. ) def
+	/AGMCORE_color_space_onhost_seps (This job contains colors that will not separate with on-host methods. ) def
+	/AGMCORE_invalid_color_space (This job contains an invalid color space. ) def
+end
+end
+systemdict /setpacking known
+{
+	setpacking
+} if
+%%EndResource
+%%BeginResource: procset Adobe_CoolType_Core 2.23 0
+%%Copyright: Copyright 1997-2003 Adobe Systems Incorporated.  All Rights Reserved.
+%%Version: 2.23 0
+10 dict begin
+/Adobe_CoolType_Passthru currentdict def
+/Adobe_CoolType_Core_Defined userdict /Adobe_CoolType_Core known def
+Adobe_CoolType_Core_Defined
+	{ /Adobe_CoolType_Core userdict /Adobe_CoolType_Core get def }
+if
+userdict /Adobe_CoolType_Core 60 dict dup begin put
+/Adobe_CoolType_Version 2.23 def
+/Level2?
+	systemdict /languagelevel known dup
+		{ pop systemdict /languagelevel get 2 ge }
+	if def
+Level2? not
+	{
+	/currentglobal false def
+	/setglobal /pop load def
+	/gcheck { pop false } bind def
+	/currentpacking false def
+	/setpacking /pop load def
+	/SharedFontDirectory 0 dict def
+	}
+if
+currentpacking
+true setpacking
+/@_SaveStackLevels
+	{
+	Adobe_CoolType_Data
+		begin
+		@opStackCountByLevel @opStackLevel
+		2 copy known not
+			{ 2 copy 3 dict dup /args 7 index 5 add array put put get }
+			{
+			get dup /args get dup length 3 index lt
+				{
+				dup length 5 add array exch
+				1 index exch 0 exch putinterval
+				1 index exch /args exch put
+				}
+				{ pop }
+			ifelse
+			}
+		ifelse
+			begin
+			count 2 sub 1 index lt
+				{ pop count 1 sub }
+			if
+			dup /argCount exch def
+			dup 0 gt
+				{
+				exch 1 index 2 add 1 roll
+				args exch 0 exch getinterval
+			astore pop
+				}
+				{ pop }
+			ifelse
+			count 1 sub /restCount exch def
+			end
+		/@opStackLevel @opStackLevel 1 add def
+		countdictstack 1 sub
+		@dictStackCountByLevel exch @dictStackLevel exch put
+		/@dictStackLevel @dictStackLevel 1 add def
+		end
+	} bind def
+/@_RestoreStackLevels
+	{
+	Adobe_CoolType_Data
+		begin
+		/@opStackLevel @opStackLevel 1 sub def
+		@opStackCountByLevel @opStackLevel get
+			begin
+			count restCount sub dup 0 gt
+				{ { pop } repeat }
+				{ pop }
+			ifelse
+			args 0 argCount getinterval {} forall
+			end
+		/@dictStackLevel @dictStackLevel 1 sub def
+		@dictStackCountByLevel @dictStackLevel get
+		end
+	countdictstack exch sub dup 0 gt
+		{ { end } repeat }
+		{ pop }
+	ifelse
+	} bind def
+/@_PopStackLevels
+	{
+	Adobe_CoolType_Data
+		begin
+		/@opStackLevel @opStackLevel 1 sub def
+		/@dictStackLevel @dictStackLevel 1 sub def
+		end
+	} bind def
+/@Raise
+	{
+	exch cvx exch errordict exch get exec
+	stop
+	} bind def
+/@ReRaise
+	{
+	cvx $error /errorname get errordict exch get exec
+	stop
+	} bind def
+/@Stopped
+	{
+	0 @#Stopped
+	} bind def
+/@#Stopped
+	{
+	@_SaveStackLevels
+	stopped
+		{ @_RestoreStackLevels true }
+		{ @_PopStackLevels false }
+	ifelse
+	} bind def
+/@Arg
+	{
+	Adobe_CoolType_Data
+		begin
+		@opStackCountByLevel @opStackLevel 1 sub get /args get exch get
+		end
+	} bind def
+currentglobal true setglobal
+/CTHasResourceForAllBug
+	Level2?
+		{
+		1 dict dup begin
+		mark
+			{
+				(*) { pop stop } 128 string /Category
+			resourceforall
+			}
+		stopped
+		cleartomark
+		currentdict eq dup
+			{ end }
+		if
+		not
+		}
+		{ false }
+	ifelse
+	def
+/CTHasResourceStatusBug
+	Level2?
+		{
+		mark
+			{ /steveamerige /Category resourcestatus }
+		stopped
+			{ cleartomark true }
+			{ cleartomark currentglobal not }
+		ifelse
+		}
+		{ false }
+	ifelse
+	def
+setglobal
+/CTResourceStatus
+		{
+		mark 3 1 roll
+		/Category findresource
+			begin
+			({ResourceStatus} stopped) 0 () /SubFileDecode filter cvx exec
+				{ cleartomark false }
+				{ { 3 2 roll pop true } { cleartomark false } ifelse }
+			ifelse
+			end
+		} bind def
+/CTWorkAroundBugs
+	{
+	Level2?
+		{
+		/cid_PreLoad /ProcSet resourcestatus
+			{
+			pop pop
+			currentglobal
+			mark
+				{
+				(*)
+					{
+					dup /CMap CTHasResourceStatusBug
+						{ CTResourceStatus }
+						{ resourcestatus }
+					ifelse
+						{
+						pop dup 0 eq exch 1 eq or
+							{
+							dup /CMap findresource gcheck setglobal
+							/CMap undefineresource
+							}
+							{
+							pop CTHasResourceForAllBug
+								{ exit }
+								{ stop }
+							ifelse
+							}
+						ifelse
+						}
+						{ pop }
+					ifelse
+					}
+				128 string /CMap resourceforall
+				}
+			stopped
+				{ cleartomark }
+			stopped pop
+			setglobal
+			}
+		if
+		}
+	if
+	} bind def
+/doc_setup
+	{
+	Adobe_CoolType_Core
+		begin
+		CTWorkAroundBugs
+		/mov /moveto load def
+		/nfnt /newencodedfont load def
+		/mfnt /makefont load def
+		/sfnt /setfont load def
+		/ufnt /undefinefont load def
+		/chp /charpath load def
+		/awsh /awidthshow load def
+		/wsh /widthshow load def
+		/ash /ashow load def
+		/sh /show load def
+		end
+	userdict /Adobe_CoolType_Data 10 dict dup
+		begin
+		/AddWidths? false def
+		/CC 0 def
+		/charcode 2 string def
+		/@opStackCountByLevel 32 dict def
+		/@opStackLevel 0 def
+		/@dictStackCountByLevel 32 dict def
+		/@dictStackLevel 0 def
+		/InVMFontsByCMap 10 dict def
+		/InVMDeepCopiedFonts 10 dict def
+		end put
+	} bind def
+/doc_trailer
+	{
+	currentdict Adobe_CoolType_Core eq
+		{ end }
+	if
+	} bind def
+/page_setup
+	{
+	Adobe_CoolType_Core begin
+	} bind def
+/page_trailer
+	{
+	end
+	} bind def
+/unload
+	{
+	systemdict /languagelevel known
+		{
+		systemdict/languagelevel get 2 ge
+			{
+			userdict/Adobe_CoolType_Core 2 copy known
+				{ undef }
+				{ pop pop }
+			ifelse
+			}
+		if
+		}
+	if
+	} bind def
+/ndf
+	{
+	1 index where
+		{ pop pop pop }
+		{ dup xcheck { bind } if def }
+	ifelse
+	} def
+/findfont systemdict
+	begin
+	userdict
+		begin
+		/globaldict where { /globaldict get begin } if
+			dup where pop exch get
+		/globaldict where { pop end } if
+		end
+	end
+Adobe_CoolType_Core_Defined
+	{ /systemfindfont exch def }
+	{
+	/findfont 1 index def
+	/systemfindfont exch def
+	}
+ifelse
+/undefinefont
+	{ pop } ndf
+/copyfont
+	{
+	currentglobal 3 1 roll
+	1 index gcheck setglobal
+	dup null eq { 0 } { dup length } ifelse
+	2 index length add 1 add dict
+		begin
+		exch
+			{
+			1 index /FID eq
+				{ pop pop }
+				{ def }
+			ifelse
+			}
+		forall
+		dup null eq
+			{ pop }
+			{ { def } forall }
+		ifelse
+		currentdict
+		end
+	exch setglobal
+	} bind def
+/copyarray
+	{
+	currentglobal exch
+	dup gcheck setglobal
+	dup length array copy
+	exch setglobal
+	} bind def
+/newencodedfont
+	{
+	currentglobal
+		{
+		SharedFontDirectory 3 index  known
+			{ SharedFontDirectory 3 index get /FontReferenced known }
+			{ false }
+		ifelse
+		}
+		{
+		FontDirectory 3 index known
+			{ FontDirectory 3 index get /FontReferenced known }
+			{
+			SharedFontDirectory 3 index known
+				{ SharedFontDirectory 3 index get /FontReferenced known }
+				{ false }
+			ifelse
+			}
+		ifelse
+		}
+	ifelse
+	dup
+		{
+		3 index findfont /FontReferenced get
+		2 index dup type /nametype eq
+			{findfont}
+		if ne
+			{ pop false }
+		if
+		}
+	if
+		{
+		pop
+		1 index findfont
+		/Encoding get exch
+		0 1 255
+			{ 2 copy get 3 index 3 1 roll put }
+		for
+		pop pop pop
+		}
+		{
+		dup type /nametype eq
+		  { findfont }
+	  if
+		dup dup maxlength 2 add dict
+			begin
+			exch
+				{
+				1 index /FID ne
+					{def}
+					{pop pop}
+				ifelse
+				}
+			forall
+			/FontReferenced exch def
+			/Encoding exch dup length array copy def
+			/FontName 1 index dup type /stringtype eq { cvn } if def dup
+			currentdict
+			end
+		definefont def
+		}
+	ifelse
+	} bind def
+/SetSubstituteStrategy
+	{
+	$SubstituteFont
+		begin
+		dup type /dicttype ne
+			{ 0 dict }
+		if
+		currentdict /$Strategies known
+			{
+			exch $Strategies exch
+			2 copy known
+				{
+				get
+				2 copy maxlength exch maxlength add dict
+					begin
+					{ def } forall
+					{ def } forall
+					currentdict
+					dup /$Init known
+						{ dup /$Init get exec }
+					if
+					end
+				/$Strategy exch def
+				}
+				{ pop pop pop }
+			ifelse
+			}
+			{ pop pop }
+		ifelse
+		end
+	} bind def
+/scff
+	{
+	$SubstituteFont
+		begin
+		dup type /stringtype eq
+			{ dup length exch }
+			{ null }
+		ifelse
+		/$sname exch def
+		/$slen exch def
+		/$inVMIndex
+			$sname null eq
+				{
+				1 index $str cvs
+				dup length $slen sub $slen getinterval cvn
+				}
+				{ $sname }
+			ifelse def
+		end
+		{ findfont }
+	@Stopped
+		{
+		dup length 8 add string exch
+		1 index 0 (BadFont:) putinterval
+		1 index exch 8 exch dup length string cvs putinterval cvn
+			{ findfont }
+		@Stopped
+			{ pop /Courier findfont }
+		if
+		}
+	if
+	$SubstituteFont
+		begin
+		/$sname null def
+		/$slen 0 def
+		/$inVMIndex null def
+		end
+	} bind def
+/isWidthsOnlyFont
+	{
+	dup /WidthsOnly known
+		{ pop pop true }
+		{
+		dup /FDepVector known
+			{ /FDepVector get { isWidthsOnlyFont dup { exit } if } forall }
+			{
+			dup /FDArray known
+				{ /FDArray get { isWidthsOnlyFont dup { exit } if } forall }
+				{ pop }
+			ifelse
+			}
+		ifelse
+		}
+	ifelse
+	} bind def
+/?str1 256 string def
+/?set
+	{
+	$SubstituteFont
+		begin
+		/$substituteFound false def
+		/$fontname 4 index def
+		/$doSmartSub false def
+		end
+	3 index
+	currentglobal false setglobal exch
+	/CompatibleFonts /ProcSet resourcestatus
+		{
+		pop pop
+		/CompatibleFonts /ProcSet findresource
+			begin
+			dup /CompatibleFont currentexception
+			1 index /CompatibleFont true setexception
+			1 index /Font resourcestatus
+				{
+				pop pop
+				3 2 roll setglobal
+				end
+				exch
+				dup findfont
+				/CompatibleFonts /ProcSet findresource
+					begin
+					3 1 roll exch /CompatibleFont exch setexception
+					end
+				}
+				{
+				3 2 roll setglobal
+				1 index exch /CompatibleFont exch setexception
+				end
+				findfont
+				$SubstituteFont /$substituteFound true put
+				}
+			ifelse
+		}
+		{ exch setglobal findfont }
+	ifelse
+	$SubstituteFont
+		begin
+		$substituteFound
+			{
+		 false
+		 (%%[Using embedded font ) print
+		 5 index ?str1 cvs print
+		 ( to avoid the font substitution problem noted earlier.]%%\n) print
+		 }
+			{
+			dup /FontName known
+				{
+				dup /FontName get $fontname eq
+				1 index /DistillerFauxFont known not and
+				/currentdistillerparams where
+					{ pop false 2 index isWidthsOnlyFont not and }
+				if
+				}
+				{ false }
+			ifelse
+			}
+		ifelse
+		exch pop
+		/$doSmartSub true def
+		end
+		{
+		exch pop exch pop exch
+		2 dict dup /Found 3 index put
+		exch findfont exch
+		}
+		{
+		exch exec
+		exch dup findfont
+		dup /FontType get 3 eq
+	  {
+		  exch ?str1 cvs
+		  dup length 1 sub
+		  -1 0
+		{
+			  exch dup 2 index get 42 eq
+			{
+				 exch 0 exch getinterval cvn 4 1 roll 3 2 roll pop
+				 exit
+			  }
+			  {exch pop} ifelse
+		  }for
+		}
+		{
+		 exch pop
+	  } ifelse
+		2 dict dup /Downloaded 6 5 roll put
+		}
+	ifelse
+	dup /FontName 4 index put copyfont definefont pop
+	} bind def
+/?str2 256 string def
+/?add
+	{
+	1 index type /integertype eq
+		{ exch true 4 2 }
+		{ false 3 1 }
+	ifelse
+	roll
+	1 index findfont
+	dup /Widths known
+		{
+		Adobe_CoolType_Data /AddWidths? true put
+		gsave dup 1000 scalefont setfont
+		}
+	if
+	/Downloaded known
+		{
+		exec
+		exch
+			{
+			exch ?str2 cvs exch
+			findfont /Downloaded get 1 dict begin /Downloaded 1 index def ?str1 cvs length
+			?str1 1 index 1 add 3 index putinterval
+			exch length 1 add 1 index add
+			?str1 2 index (*) putinterval
+			?str1 0 2 index getinterval cvn findfont
+			?str1 3 index (+) putinterval
+			2 dict dup /FontName ?str1 0 6 index getinterval cvn put
+			dup /Downloaded Downloaded put end copyfont
+			dup /FontName get exch definefont pop pop pop
+			}
+			{
+			pop
+			}
+		ifelse
+		}
+		{
+		pop
+		exch
+			{
+			findfont
+			dup /Found get
+			dup length exch ?str1 cvs pop
+			?str1 1 index (+) putinterval
+			?str1 1 index 1 add 4 index ?str2 cvs putinterval
+			?str1 exch 0 exch 5 4 roll ?str2 cvs length 1 add add getinterval cvn
+			1 dict exch 1 index exch /FontName exch put copyfont
+			dup /FontName get exch definefont pop
+			}
+			{
+			pop
+			}
+		ifelse
+		}
+	ifelse
+	Adobe_CoolType_Data /AddWidths? get
+		{ grestore Adobe_CoolType_Data /AddWidths? false put }
+	if
+	} bind def
+/?sh
+	{
+	currentfont /Downloaded known { exch } if pop
+	} bind def
+/?chp
+	{
+	currentfont /Downloaded known { pop } { false chp } ifelse
+	} bind def
+/?mv
+	{
+	currentfont /Downloaded known { moveto pop pop } { pop pop moveto } ifelse
+	} bind def
+setpacking
+userdict /$SubstituteFont 25 dict put
+1 dict
+	begin
+	/SubstituteFont
+		dup $error exch 2 copy known
+			{ get }
+			{ pop pop { pop /Courier } bind }
+		ifelse def
+	/currentdistillerparams where dup
+		{
+		pop pop
+		currentdistillerparams /CannotEmbedFontPolicy 2 copy known
+			{ get /Error eq }
+			{ pop pop false }
+		ifelse
+		}
+	if not
+		{
+		countdictstack array dictstack 0 get
+			begin
+			userdict
+				begin
+				$SubstituteFont
+					begin
+					/$str 128 string def
+					/$fontpat 128 string def
+					/$slen 0 def
+					/$sname null def
+					/$match false def
+					/$fontname null def
+					/$substituteFound false def
+					/$inVMIndex null def
+					/$doSmartSub true def
+					/$depth 0 def
+					/$fontname null def
+					/$italicangle 26.5 def
+					/$dstack null def
+					/$Strategies 10 dict dup
+						begin
+						/$Type3Underprint
+							{
+							currentglobal exch false setglobal
+							11 dict
+								begin
+								/UseFont exch
+									$WMode 0 ne
+										{
+										dup length dict copy
+										dup /WMode $WMode put
+										/UseFont exch definefont
+										}
+									if def
+								/FontName $fontname dup type /stringtype eq { cvn } if def
+								/FontType 3 def
+								/FontMatrix [ .001 0 0 .001 0 0 ] def
+								/Encoding 256 array dup 0 1 255 { /.notdef put dup } for pop def
+								/FontBBox [ 0 0 0 0 ] def
+								/CCInfo 7 dict dup
+									begin
+									/cc null def
+									/x 0 def
+									/y 0 def
+									end def
+								/BuildChar
+									{
+									exch
+										begin
+										CCInfo
+											begin
+											1 string dup 0 3 index put exch pop
+											/cc exch def
+											UseFont 1000 scalefont setfont
+											cc stringwidth /y exch def /x exch def
+											x y setcharwidth
+											$SubstituteFont /$Strategy get /$Underprint get exec
+											0 0 moveto cc show
+											x y moveto
+											end
+										end
+									} bind def
+								currentdict
+								end
+							exch setglobal
+							} bind def
+						/$GetaTint
+							2 dict dup
+								begin
+								/$BuildFont
+									{
+									dup /WMode known
+										{ dup /WMode get }
+										{ 0 }
+									ifelse
+									/$WMode exch def
+									$fontname exch
+									dup /FontName known
+										{
+										dup /FontName get
+										dup type /stringtype eq { cvn } if
+										}
+										{ /unnamedfont }
+									ifelse
+									exch
+									Adobe_CoolType_Data /InVMDeepCopiedFonts get
+									1 index /FontName get known
+										{
+										pop
+										Adobe_CoolType_Data /InVMDeepCopiedFonts get
+										1 index get
+										null copyfont
+										}
+										{ $deepcopyfont }
+									ifelse
+									exch 1 index exch /FontBasedOn exch put
+									dup /FontName $fontname dup type /stringtype eq { cvn } if put
+									definefont
+									Adobe_CoolType_Data /InVMDeepCopiedFonts get
+										begin
+										dup /FontBasedOn get 1 index def
+										end
+									} bind def
+								/$Underprint
+									{
+									gsave
+									x abs y abs gt
+										{ /y 1000 def }
+										{ /x -1000 def 500 120 translate }
+									ifelse
+									Level2?
+										{
+										[ /Separation (All) /DeviceCMYK { 0 0 0 1 pop } ]
+										setcolorspace
+										}
+										{ 0 setgray }
+									ifelse
+									10 setlinewidth
+									x .8 mul
+									[ 7 3 ]
+										{
+										y mul 8 div 120 sub x 10 div exch moveto
+										0 y 4 div neg rlineto
+										dup 0 rlineto
+										0 y 4 div rlineto
+										closepath
+										gsave
+										Level2?
+											{ .2 setcolor }
+											{ .8 setgray }
+										ifelse
+										fill grestore
+										stroke
+										}
+									forall
+									pop
+									grestore
+									} bind def
+								end def
+						/$Oblique
+							1 dict dup
+								begin
+								/$BuildFont
+									{
+									currentglobal exch dup gcheck setglobal
+									null copyfont
+										begin
+										/FontBasedOn
+										currentdict /FontName known
+											{
+											FontName
+											dup type /stringtype eq { cvn } if
+											}
+											{ /unnamedfont }
+										ifelse
+										def
+										/FontName $fontname dup type /stringtype eq { cvn } if def
+										/currentdistillerparams where
+											{ pop }
+											{
+											/FontInfo currentdict /FontInfo known
+												{ FontInfo null copyfont }
+												{ 2 dict }
+											ifelse
+											dup
+												begin
+												/ItalicAngle $italicangle def
+												/FontMatrix FontMatrix
+												[ 1 0 ItalicAngle dup sin exch cos div 1 0 0 ]
+												matrix concatmatrix readonly
+												end
+											4 2 roll def
+											def
+											}
+										ifelse
+										FontName currentdict
+										end
+									definefont
+									exch setglobal
+									} bind def
+								end def
+						/$None
+							1 dict dup
+								begin
+								/$BuildFont {} bind def
+								end def
+						end def
+					/$Oblique SetSubstituteStrategy
+					/$findfontByEnum
+						{
+						dup type /stringtype eq { cvn } if
+						dup /$fontname exch def
+						$sname null eq
+							{ $str cvs dup length $slen sub $slen getinterval }
+							{ pop $sname }
+						ifelse
+						$fontpat dup 0 (fonts/*) putinterval exch 7 exch putinterval
+						/$match false def
+						$SubstituteFont /$dstack countdictstack array dictstack put
+						mark
+							{
+							$fontpat 0 $slen 7 add getinterval
+								{ /$match exch def exit }
+							$str filenameforall
+							}
+						stopped
+							{
+							cleardictstack
+							currentdict
+							true
+							$SubstituteFont /$dstack get
+								{
+								exch
+									{
+									1 index eq
+										{ pop false }
+										{ true }
+									ifelse
+									}
+									{ begin false }
+								ifelse
+								}
+							forall
+							pop
+							}
+						if
+						cleartomark
+						/$slen 0 def
+						$match false ne
+							{ $match (fonts/) anchorsearch pop pop cvn }
+							{ /Courier }
+						ifelse
+						} bind def
+					/$ROS 1 dict dup
+						begin
+						/Adobe 4 dict dup
+							begin
+							/Japan1  [ /Ryumin-Light /HeiseiMin-W3
+										  /GothicBBB-Medium /HeiseiKakuGo-W5
+										  /HeiseiMaruGo-W4 /Jun101-Light ] def
+							/Korea1  [ /HYSMyeongJo-Medium /HYGoThic-Medium ] def
+							/GB1	  [ /STSong-Light /STHeiti-Regular ] def
+							/CNS1	 [ /MKai-Medium /MHei-Medium ] def
+							end def
+						end def
+					/$cmapname null def
+					/$deepcopyfont
+						{
+						dup /FontType get 0 eq
+							{
+							1 dict dup /FontName /copied put copyfont
+								begin
+								/FDepVector FDepVector copyarray
+								0 1 2 index length 1 sub
+									{
+									2 copy get $deepcopyfont
+									dup /FontName /copied put
+									/copied exch definefont
+									3 copy put pop pop
+									}
+								for
+								def
+								currentdict
+								end
+							}
+							{ $Strategies /$Type3Underprint get exec }
+						ifelse
+						} bind def
+					/$buildfontname
+						{
+						dup /CIDFont findresource /CIDSystemInfo get
+							begin
+							Registry length Ordering length Supplement 8 string cvs
+							3 copy length 2 add add add string
+							dup 5 1 roll dup 0 Registry putinterval
+							dup 4 index (-) putinterval
+							dup 4 index 1 add Ordering putinterval
+							4 2 roll add 1 add 2 copy (-) putinterval
+							end
+						1 add 2 copy 0 exch getinterval $cmapname $fontpat cvs exch
+						anchorsearch
+							{ pop pop 3 2 roll putinterval cvn /$cmapname exch def }
+							{ pop pop pop pop pop }
+						ifelse
+						length
+						$str 1 index (-) putinterval 1 add
+						$str 1 index $cmapname $fontpat cvs putinterval
+						$cmapname length add
+						$str exch 0 exch getinterval cvn
+						} bind def
+					/$findfontByROS
+						{
+						/$fontname exch def
+						$ROS Registry 2 copy known
+							{
+							get Ordering 2 copy known
+								{ get }
+								{ pop pop [] }
+							ifelse
+							}
+							{ pop pop [] }
+						ifelse
+						false exch
+							{
+							dup /CIDFont resourcestatus
+								{
+								pop pop
+								save
+								1 index /CIDFont findresource
+								dup /WidthsOnly known
+									{ dup /WidthsOnly get }
+									{ false }
+								ifelse
+								exch pop
+								exch restore
+									{ pop }
+									{ exch pop true exit }
+								ifelse
+								}
+								{ pop }
+							ifelse
+							}
+						forall
+							{ $str cvs $buildfontname }
+							{
+							false (*)
+								{
+								save exch
+								dup /CIDFont findresource
+								dup /WidthsOnly known
+									{ dup /WidthsOnly get not }
+									{ true }
+								ifelse
+								exch /CIDSystemInfo get
+								dup /Registry get Registry eq
+								exch /Ordering get Ordering eq and and
+									{ exch restore exch pop true exit }
+									{ pop restore }
+								ifelse
+								}
+							$str /CIDFont resourceforall
+								{ $buildfontname }
+								{ $fontname $findfontByEnum }
+							ifelse
+							}
+						ifelse
+						} bind def
+					end
+				end
+				currentdict /$error known currentdict /languagelevel known and dup
+					{ pop $error /SubstituteFont known }
+				if
+				dup
+					{ $error }
+					{ Adobe_CoolType_Core }
+				ifelse
+				begin
+					{
+					/SubstituteFont
+					/CMap /Category resourcestatus
+						{
+						pop pop
+						{
+						$SubstituteFont
+							begin
+							/$substituteFound true def
+							dup length $slen gt
+							$sname null ne or
+							$slen 0 gt and
+								{
+								$sname null eq
+									{ dup $str cvs dup length $slen sub $slen getinterval cvn }
+									{ $sname }
+								ifelse
+								Adobe_CoolType_Data /InVMFontsByCMap get
+								1 index 2 copy known
+									{
+									get
+									false exch
+										{
+										pop
+										currentglobal
+											{
+											GlobalFontDirectory 1 index known
+												{ exch pop true exit }
+												{ pop }
+											ifelse
+											}
+											{
+											FontDirectory 1 index known
+												{ exch pop true exit }
+												{
+												GlobalFontDirectory 1 index known
+													{ exch pop true exit }
+													{ pop }
+												ifelse
+												}
+											ifelse
+											}
+										ifelse
+										}
+									forall
+									}
+									{ pop pop false }
+								ifelse
+									{
+									exch pop exch pop
+									}
+									{
+									dup /CMap resourcestatus
+										{
+										pop pop
+										dup /$cmapname exch def
+										/CMap findresource /CIDSystemInfo get { def } forall
+										$findfontByROS
+										}
+										{
+										128 string cvs
+										dup (-) search
+											{
+											3 1 roll search
+												{
+												3 1 roll pop
+													{ dup cvi }
+												stopped
+													{ pop pop pop pop pop $findfontByEnum }
+													{
+													4 2 roll pop pop
+													exch length
+													exch
+													2 index length
+													2 index
+													sub
+													exch 1 sub -1 0
+														{
+														$str cvs dup length
+														4 index
+														0
+														4 index
+														4 3 roll add
+														getinterval
+														exch 1 index exch 3 index exch
+														putinterval
+														dup /CMap resourcestatus
+															{
+															pop pop
+															4 1 roll pop pop pop
+															dup /$cmapname exch def
+															/CMap findresource /CIDSystemInfo get { def } forall
+															$findfontByROS
+															true exit
+															}
+															{ pop }
+														ifelse
+														}
+													for
+													dup type /booleantype eq
+														{ pop }
+														{ pop pop pop $findfontByEnum }
+													ifelse
+													}
+												ifelse
+												}
+												{ pop pop pop $findfontByEnum }
+											ifelse
+											}
+											{ pop pop $findfontByEnum }
+										ifelse
+										}
+									ifelse
+									}
+								ifelse
+								}
+								{ //SubstituteFont exec }
+							ifelse
+							/$slen 0 def
+							end
+						}
+						}
+						{
+						{
+						$SubstituteFont
+							begin
+							/$substituteFound true def
+							dup length $slen gt
+							$sname null ne or
+							$slen 0 gt and
+								{ $findfontByEnum }
+								{ //SubstituteFont exec }
+							ifelse
+							end
+						}
+						}
+					ifelse
+					bind readonly def
+					Adobe_CoolType_Core /scfindfont /systemfindfont load put
+					}
+					{
+					/scfindfont
+						{
+						$SubstituteFont
+							begin
+							dup systemfindfont
+							dup /FontName known
+								{ dup /FontName get dup 3 index ne }
+								{ /noname true }
+							ifelse
+							dup
+								{
+								/$origfontnamefound 2 index def
+								/$origfontname 4 index def /$substituteFound true def
+								}
+							if
+							exch pop
+								{
+								$slen 0 gt
+								$sname null ne
+								3 index length $slen gt or and
+									{
+									pop dup $findfontByEnum findfont
+									dup maxlength 1 add dict
+										begin
+											{ 1 index /FID eq { pop pop } { def } ifelse }
+										forall
+										currentdict
+										end
+									definefont
+									dup /FontName known { dup /FontName get } { null } ifelse
+									$origfontnamefound ne
+										{
+										$origfontname $str cvs print
+										( substitution revised, using ) print
+										dup /FontName known
+											{ dup /FontName get } { (unspecified font) }
+										ifelse
+										$str cvs print (.\n) print
+										}
+									if
+									}
+									{ exch pop }
+								ifelse
+								}
+								{ exch pop }
+							ifelse
+							end
+						} bind def
+					}
+				ifelse
+				end
+			end
+		Adobe_CoolType_Core_Defined not
+			{
+			Adobe_CoolType_Core /findfont
+				{
+				$SubstituteFont
+					begin
+					$depth 0 eq
+						{
+						/$fontname 1 index dup type /stringtype ne { $str cvs } if def
+						/$substituteFound false def
+						}
+					if
+					/$depth $depth 1 add def
+					end
+				scfindfont
+				$SubstituteFont
+					begin
+					/$depth $depth 1 sub def
+					$substituteFound $depth 0 eq and
+						{
+						$inVMIndex null ne
+							{ dup $inVMIndex $AddInVMFont }
+						if
+						$doSmartSub
+							{
+							currentdict /$Strategy known
+								{ $Strategy /$BuildFont get exec }
+							if
+							}
+						if
+						}
+					if
+					end
+				} bind put
+			}
+		if
+		}
+	if
+	end
+/$AddInVMFont
+	{
+	exch /FontName 2 copy known
+		{
+		get
+		1 dict dup begin exch 1 index gcheck def end exch
+		Adobe_CoolType_Data /InVMFontsByCMap get exch
+		$DictAdd
+		}
+		{ pop pop pop }
+	ifelse
+	} bind def
+/$DictAdd
+	{
+	2 copy known not
+		{ 2 copy 4 index length dict put }
+	if
+	Level2? not
+		{
+		2 copy get dup maxlength exch length 4 index length add lt
+		2 copy get dup length 4 index length add exch maxlength 1 index lt
+			{
+			2 mul dict
+				begin
+				2 copy get { forall } def
+				2 copy currentdict put
+				end
+			}
+			{ pop }
+		ifelse
+		}
+	if
+	get
+		begin
+			{ def }
+		forall
+		end
+	} bind def
+end
+end
+%%EndResource
+%%BeginResource: procset Adobe_CoolType_Utility_MAKEOCF 1.19 0
+%%Copyright: Copyright 1987-2003 Adobe Systems Incorporated.
+%%Version: 1.19 0
+systemdict /languagelevel known dup
+	{ currentglobal false setglobal }
+	{ false }
+ifelse
+exch
+userdict /Adobe_CoolType_Utility 2 copy known
+	{ 2 copy get dup maxlength 25 add dict copy }
+	{ 25 dict }
+ifelse put
+Adobe_CoolType_Utility
+	begin
+	/ct_Level2? exch def
+	/ct_Clone? 1183615869 internaldict dup
+			/CCRun known not
+			exch /eCCRun known not
+			ct_Level2? and or def
+ct_Level2?
+	{ globaldict begin currentglobal true setglobal }
+if
+	/ct_AddStdCIDMap
+		ct_Level2?
+			{ {
+			((Hex) 57 StartData
+			0615 1e27 2c39 1c60 d8a8 cc31 fe2b f6e0
+			7aa3 e541 e21c 60d8 a8c9 c3d0 6d9e 1c60
+			d8a8 c9c2 02d7 9a1c 60d8 a849 1c60 d8a8
+			cc36 74f4 1144 b13b 77) 0 () /SubFileDecode filter cvx exec
+			} }
+			{ {
+			<BAB431EA07F209EB8C4348311481D9D3F76E3D15246555577D87BC510ED54E
+		 118C39697FA9F6DB58128E60EB8A12FA24D7CDD2FA94D221FA9EC8DA3E5E6A1C
+			4ACECC8C2D39C54E7C946031DD156C3A6B4A09AD29E1867A> eexec
+			} }
+		ifelse bind def
+userdict /cid_extensions known
+dup { cid_extensions /cid_UpdateDB known and } if
+	 {
+	 cid_extensions
+	 begin
+	 /cid_GetCIDSystemInfo
+		 {
+		 1 index type /stringtype eq
+			 { exch cvn exch }
+		 if
+		 cid_extensions
+			 begin
+			 dup load 2 index known
+				 {
+				 2 copy
+				 cid_GetStatusInfo
+				 dup null ne
+					 {
+					 1 index load
+					 3 index get
+					 dup null eq
+						  { pop pop cid_UpdateDB }
+						  {
+						  exch
+						  1 index /Created get eq
+							  { exch pop exch pop }
+							  { pop cid_UpdateDB }
+						  ifelse
+						  }
+					 ifelse
+					 }
+					 { pop cid_UpdateDB }
+				 ifelse
+				 }
+				 { cid_UpdateDB }
+			 ifelse
+			 end
+		 } bind def
+	 end
+	 }
+if
+ct_Level2?
+	{ end setglobal }
+if
+	/ct_UseNativeCapability?  systemdict /composefont known def
+	/ct_MakeOCF 35 dict def
+	/ct_Vars 25 dict def
+	/ct_GlyphDirProcs 6 dict def
+	/ct_BuildCharDict 15 dict dup
+		begin
+		/charcode 2 string def
+		/dst_string 1500 string def
+		/nullstring () def
+		/usewidths? true def
+		end def
+	ct_Level2? { setglobal } { pop } ifelse
+	ct_GlyphDirProcs
+		begin
+		/GetGlyphDirectory
+			{
+			systemdict /languagelevel known
+				{ pop /CIDFont findresource /GlyphDirectory get }
+				{
+				1 index /CIDFont findresource /GlyphDirectory
+				get dup type /dicttype eq
+					{
+					dup dup maxlength exch length sub 2 index lt
+						{
+						dup length 2 index add dict copy 2 index
+						/CIDFont findresource/GlyphDirectory 2 index put
+						}
+					if
+					}
+				if
+				exch pop exch pop
+				}
+			ifelse
+			+
+			} def
+		/+
+			{
+			systemdict /languagelevel known
+				{
+				currentglobal false setglobal
+				3 dict begin
+					/vm exch def
+				}
+				{ 1 dict begin }
+			ifelse
+			/$ exch def
+			systemdict /languagelevel known
+				{
+				vm setglobal
+				/gvm currentglobal def
+				$ gcheck setglobal
+				}
+			if
+			? { $ begin } if
+			} def
+		/? { $ type /dicttype eq } def
+		/| {
+			userdict /Adobe_CoolType_Data known
+				{
+			Adobe_CoolType_Data /AddWidths? known
+				{
+				 currentdict Adobe_CoolType_Data
+					begin
+					  begin
+						AddWidths?
+								{
+								Adobe_CoolType_Data /CC 3 index put
+								? { def } { $ 3 1 roll put } ifelse
+								CC charcode exch 1 index 0 2 index 256 idiv put
+								1 index exch 1 exch 256 mod put
+								stringwidth 2 array astore
+								currentfont /Widths get exch CC exch put
+								}
+								{ ? { def } { $ 3 1 roll put } ifelse }
+							ifelse
+					end
+				end
+				}
+				{ ? { def } { $ 3 1 roll put } ifelse }	ifelse
+				}
+				{ ? { def } { $ 3 1 roll put } ifelse }
+			ifelse
+			} def
+		/!
+			{
+			? { end } if
+			systemdict /languagelevel known
+				{ gvm setglobal }
+			if
+			end
+			} def
+		/: { string currentfile exch readstring pop } executeonly def
+		end
+	ct_MakeOCF
+		begin
+		/ct_cHexEncoding
+		[/c00/c01/c02/c03/c04/c05/c06/c07/c08/c09/c0A/c0B/c0C/c0D/c0E/c0F/c10/c11/c12
+		 /c13/c14/c15/c16/c17/c18/c19/c1A/c1B/c1C/c1D/c1E/c1F/c20/c21/c22/c23/c24/c25
+		 /c26/c27/c28/c29/c2A/c2B/c2C/c2D/c2E/c2F/c30/c31/c32/c33/c34/c35/c36/c37/c38
+		 /c39/c3A/c3B/c3C/c3D/c3E/c3F/c40/c41/c42/c43/c44/c45/c46/c47/c48/c49/c4A/c4B
+		 /c4C/c4D/c4E/c4F/c50/c51/c52/c53/c54/c55/c56/c57/c58/c59/c5A/c5B/c5C/c5D/c5E
+		 /c5F/c60/c61/c62/c63/c64/c65/c66/c67/c68/c69/c6A/c6B/c6C/c6D/c6E/c6F/c70/c71
+		 /c72/c73/c74/c75/c76/c77/c78/c79/c7A/c7B/c7C/c7D/c7E/c7F/c80/c81/c82/c83/c84
+		 /c85/c86/c87/c88/c89/c8A/c8B/c8C/c8D/c8E/c8F/c90/c91/c92/c93/c94/c95/c96/c97
+		 /c98/c99/c9A/c9B/c9C/c9D/c9E/c9F/cA0/cA1/cA2/cA3/cA4/cA5/cA6/cA7/cA8/cA9/cAA
+		 /cAB/cAC/cAD/cAE/cAF/cB0/cB1/cB2/cB3/cB4/cB5/cB6/cB7/cB8/cB9/cBA/cBB/cBC/cBD
+		 /cBE/cBF/cC0/cC1/cC2/cC3/cC4/cC5/cC6/cC7/cC8/cC9/cCA/cCB/cCC/cCD/cCE/cCF/cD0
+		 /cD1/cD2/cD3/cD4/cD5/cD6/cD7/cD8/cD9/cDA/cDB/cDC/cDD/cDE/cDF/cE0/cE1/cE2/cE3
+		 /cE4/cE5/cE6/cE7/cE8/cE9/cEA/cEB/cEC/cED/cEE/cEF/cF0/cF1/cF2/cF3/cF4/cF5/cF6
+		 /cF7/cF8/cF9/cFA/cFB/cFC/cFD/cFE/cFF] def
+		/ct_CID_STR_SIZE 8000 def
+		/ct_mkocfStr100 100 string def
+		/ct_defaultFontMtx [.001 0 0 .001 0 0] def
+		/ct_1000Mtx [1000 0 0 1000 0 0] def
+		/ct_raise {exch cvx exch errordict exch get exec stop} bind def
+		/ct_reraise
+			{ cvx $error /errorname get (Error: ) print dup (						  ) cvs print
+					errordict exch get exec stop
+			} bind def
+		/ct_cvnsi
+			{
+			1 index add 1 sub 1 exch 0 4 1 roll
+				{
+				2 index exch get
+				exch 8 bitshift
+				add
+				}
+			for
+			exch pop
+			} bind def
+		/ct_GetInterval
+			{
+			Adobe_CoolType_Utility /ct_BuildCharDict get
+				begin
+				/dst_index 0 def
+				dup dst_string length gt
+					{ dup string /dst_string exch def }
+				if
+				1 index ct_CID_STR_SIZE idiv
+				/arrayIndex exch def
+				2 index arrayIndex  get
+				2 index
+				arrayIndex ct_CID_STR_SIZE mul
+				sub
+					{
+					dup 3 index add 2 index length le
+						{
+						2 index getinterval
+						dst_string  dst_index 2 index putinterval
+						length dst_index add /dst_index exch def
+						exit
+						}
+						{
+						1 index length 1 index sub
+						dup 4 1 roll
+						getinterval
+						dst_string  dst_index 2 index putinterval
+						pop dup dst_index add /dst_index exch def
+						sub
+						/arrayIndex arrayIndex 1 add def
+						2 index dup length arrayIndex gt
+							  { arrayIndex get }
+							  {
+							  pop
+							  exit
+							  }
+						ifelse
+						0
+						}
+					ifelse
+					}
+				loop
+				pop pop pop
+				dst_string 0 dst_index getinterval
+				end
+			} bind def
+		ct_Level2?
+			{
+			/ct_resourcestatus
+			currentglobal mark true setglobal
+				{ /unknowninstancename /Category resourcestatus }
+			stopped
+				{ cleartomark setglobal true }
+				{ cleartomark currentglobal not exch setglobal }
+			ifelse
+				{
+					{
+					mark 3 1 roll /Category findresource
+						begin
+						ct_Vars /vm currentglobal put
+						({ResourceStatus} stopped) 0 () /SubFileDecode filter cvx exec
+							{ cleartomark false }
+							{ { 3 2 roll pop true } { cleartomark false } ifelse }
+						ifelse
+						ct_Vars /vm get setglobal
+						end
+					}
+				}
+				{ { resourcestatus } }
+			ifelse bind def
+			/CIDFont /Category ct_resourcestatus
+				{ pop pop }
+				{
+				currentglobal  true setglobal
+				/Generic /Category findresource
+				dup length dict copy
+				dup /InstanceType /dicttype put
+				/CIDFont exch /Category defineresource pop
+				setglobal
+				}
+			ifelse
+			ct_UseNativeCapability?
+				{
+				/CIDInit /ProcSet findresource begin
+				12 dict begin
+				begincmap
+				/CIDSystemInfo 3 dict dup begin
+				  /Registry (Adobe) def
+				  /Ordering (Identity) def
+				  /Supplement 0 def
+				end def
+				/CMapName /Identity-H def
+				/CMapVersion 1.000 def
+				/CMapType 1 def
+				1 begincodespacerange
+				<0000> <FFFF>
+				endcodespacerange
+				1 begincidrange
+				<0000> <FFFF> 0
+				endcidrange
+				endcmap
+				CMapName currentdict /CMap defineresource pop
+				end
+				end
+				}
+			if
+			}
+			{
+			/ct_Category 2 dict begin
+			/CIDFont  10 dict def
+			/ProcSet	2 dict def
+			currentdict
+			end
+			def
+			/defineresource
+				{
+				ct_Category 1 index 2 copy known
+					{
+					get
+					dup dup maxlength exch length eq
+						{
+						dup length 10 add dict copy
+						ct_Category 2 index 2 index put
+						}
+					if
+					3 index 3 index put
+					pop exch pop
+					}
+					{ pop pop /defineresource /undefined ct_raise }
+				ifelse
+				} bind def
+			/findresource
+				{
+				ct_Category 1 index 2 copy known
+					{
+					get
+					2 index 2 copy known
+						{ get 3 1 roll pop pop}
+						{ pop pop /findresource /undefinedresource ct_raise }
+					ifelse
+					}
+					{ pop pop /findresource /undefined ct_raise }
+				ifelse
+				} bind def
+			/resourcestatus
+				{
+				ct_Category 1 index 2 copy known
+					{
+					get
+					2 index known
+					exch pop exch pop
+						{
+						0 -1 true
+						}
+						{
+						false
+						}
+					ifelse
+					}
+					{ pop pop /findresource /undefined ct_raise }
+				ifelse
+				} bind def
+			/ct_resourcestatus /resourcestatus load def
+			}
+		ifelse
+		/ct_CIDInit 2 dict
+			begin
+			/ct_cidfont_stream_init
+				{
+					{
+					dup (Binary) eq
+						{
+						pop
+						null
+						currentfile
+						ct_Level2?
+							{
+								{ cid_BYTE_COUNT () /SubFileDecode filter }
+							stopped
+								{ pop pop pop }
+							if
+							}
+						if
+						/readstring load
+						exit
+						}
+					if
+					dup (Hex) eq
+						{
+						pop
+						currentfile
+						ct_Level2?
+							{
+								{ null exch /ASCIIHexDecode filter /readstring }
+							stopped
+								{ pop exch pop (>) exch /readhexstring }
+							if
+							}
+							{ (>) exch /readhexstring }
+						ifelse
+						load
+						exit
+						}
+					if
+					/StartData /typecheck ct_raise
+					}
+				loop
+				cid_BYTE_COUNT ct_CID_STR_SIZE le
+					{
+					2 copy cid_BYTE_COUNT string exch exec
+					pop
+					1 array dup
+					3 -1 roll
+					0 exch put
+					}
+					{
+					cid_BYTE_COUNT ct_CID_STR_SIZE div ceiling cvi
+					dup array exch 2 sub 0 exch 1 exch
+						{
+						2 copy
+						5 index
+						ct_CID_STR_SIZE
+						string
+						6 index exec
+						pop
+						put
+						pop
+						}
+					for
+					2 index
+					cid_BYTE_COUNT ct_CID_STR_SIZE mod string
+					3 index exec
+					pop
+					1 index exch
+					1 index length 1 sub
+					exch put
+					}
+				ifelse
+				cid_CIDFONT exch /GlyphData exch put
+				2 index null eq
+					{
+					pop pop pop
+					}
+					{
+					pop /readstring load
+					1 string exch
+						{
+						3 copy exec
+						pop
+						dup length 0 eq
+							{
+							pop pop pop pop pop
+							true exit
+							}
+						if
+						4 index
+						eq
+							{
+							pop pop pop pop
+							false exit
+							}
+						if
+						}
+					loop
+					pop
+					}
+				ifelse
+				} bind def
+			/StartData
+				{
+				mark
+					{
+					currentdict
+					dup /FDArray get 0 get /FontMatrix get
+					0 get 0.001 eq
+						{
+						dup /CDevProc known not
+							{
+							/CDevProc 1183615869 internaldict /stdCDevProc 2 copy known
+								{ get }
+								{
+								pop pop
+								{ pop pop pop pop pop 0 -1000 7 index 2 div 880 }
+								}
+							ifelse
+							def
+							}
+						if
+						}
+						{
+						 /CDevProc
+							 {
+							 pop pop pop pop pop
+							 0
+							 1 cid_temp /cid_CIDFONT get
+							 /FDArray get 0 get
+							 /FontMatrix get 0 get div
+							 7 index 2 div
+							 1 index 0.88 mul
+							 } def
+						}
+					ifelse
+					/cid_temp 15 dict def
+					cid_temp
+						begin
+						/cid_CIDFONT exch def
+						3 copy pop
+						dup /cid_BYTE_COUNT exch def 0 gt
+							{
+							ct_cidfont_stream_init
+							FDArray
+								{
+								/Private get
+								dup /SubrMapOffset known
+									{
+									begin
+									/Subrs SubrCount array def
+									Subrs
+									SubrMapOffset
+									SubrCount
+									SDBytes
+									ct_Level2?
+										{
+										currentdict dup /SubrMapOffset undef
+										dup /SubrCount undef
+										/SDBytes undef
+										}
+									if
+									end
+									/cid_SD_BYTES exch def
+									/cid_SUBR_COUNT exch def
+									/cid_SUBR_MAP_OFFSET exch def
+									/cid_SUBRS exch def
+									cid_SUBR_COUNT 0 gt
+										{
+										GlyphData cid_SUBR_MAP_OFFSET cid_SD_BYTES ct_GetInterval
+										0 cid_SD_BYTES ct_cvnsi
+										0 1 cid_SUBR_COUNT 1 sub
+											{
+											exch 1 index
+											1 add
+											cid_SD_BYTES mul cid_SUBR_MAP_OFFSET add
+											GlyphData exch cid_SD_BYTES ct_GetInterval
+											0 cid_SD_BYTES ct_cvnsi
+											cid_SUBRS 4 2 roll
+											GlyphData exch
+											4 index
+											1 index
+											sub
+											ct_GetInterval
+											dup length string copy put
+											}
+										for
+										pop
+										}
+									if
+									}
+									{ pop }
+								ifelse
+								}
+							forall
+							}
+						if
+						cleartomark pop pop
+						end
+					CIDFontName currentdict /CIDFont defineresource pop
+					end end
+					}
+				stopped
+					{ cleartomark /StartData ct_reraise }
+				if
+				} bind def
+			currentdict
+			end def
+		/ct_saveCIDInit
+			{
+			/CIDInit /ProcSet ct_resourcestatus
+				{ true }
+				{ /CIDInitC /ProcSet ct_resourcestatus }
+			ifelse
+				{
+				pop pop
+				/CIDInit /ProcSet findresource
+				ct_UseNativeCapability?
+					{ pop null }
+					{ /CIDInit ct_CIDInit /ProcSet defineresource pop }
+				ifelse
+				}
+				{ /CIDInit ct_CIDInit /ProcSet defineresource pop null }
+			ifelse
+			ct_Vars exch /ct_oldCIDInit exch put
+			} bind def
+		/ct_restoreCIDInit
+			{
+			ct_Vars /ct_oldCIDInit get dup null ne
+				{ /CIDInit exch /ProcSet defineresource pop }
+				{ pop }
+			ifelse
+			} bind def
+		/ct_BuildCharSetUp
+			{
+			1 index
+				begin
+				CIDFont
+					begin
+					Adobe_CoolType_Utility /ct_BuildCharDict get
+						begin
+						/ct_dfCharCode exch def
+						/ct_dfDict exch def
+						CIDFirstByte ct_dfCharCode add
+						dup CIDCount ge
+							{ pop 0 }
+						if
+						/cid exch def
+							{
+							GlyphDirectory cid 2 copy known
+								{ get }
+								{ pop pop nullstring }
+							ifelse
+							dup length FDBytes sub 0 gt
+								{
+								dup
+								FDBytes 0 ne
+									{ 0 FDBytes ct_cvnsi }
+									{ pop 0 }
+								ifelse
+								/fdIndex exch def
+								dup length FDBytes sub FDBytes exch getinterval
+								/charstring exch def
+								exit
+								}
+								{
+								pop
+								cid 0 eq
+									{ /charstring nullstring def exit }
+								if
+								/cid 0 def
+								}
+							ifelse
+							}
+						loop
+			} def
+		/ct_SetCacheDevice
+			{
+			0 0 moveto
+			dup stringwidth
+			3 -1 roll
+			true charpath
+			pathbbox
+			0 -1000
+			7 index 2 div 880
+			setcachedevice2
+			0 0 moveto
+			} def
+		/ct_CloneSetCacheProc
+			{
+			1 eq
+				{
+				stringwidth
+				pop -2 div -880
+				0 -1000 setcharwidth
+				moveto
+				}
+				{
+				usewidths?
+					{
+					currentfont /Widths get cid
+					2 copy known
+						{ get exch pop aload pop }
+						{ pop pop stringwidth }
+					ifelse
+					}
+					{ stringwidth }
+				ifelse
+				setcharwidth
+				0 0 moveto
+				}
+			ifelse
+			} def
+		/ct_Type3ShowCharString
+			{
+			ct_FDDict fdIndex 2 copy known
+				{ get }
+				{
+				currentglobal 3 1 roll
+				1 index gcheck setglobal
+				ct_Type1FontTemplate dup maxlength dict copy
+					begin
+					FDArray fdIndex get
+					dup /FontMatrix 2 copy known
+						{ get }
+						{ pop pop ct_defaultFontMtx }
+					ifelse
+					/FontMatrix exch dup length array copy def
+					/Private get
+					/Private exch def
+					/Widths rootfont /Widths get def
+					/CharStrings 1 dict dup /.notdef
+						<d841272cf18f54fc13> dup length string copy put def
+					currentdict
+					end
+				/ct_Type1Font exch definefont
+				dup 5 1 roll put
+				setglobal
+				}
+			ifelse
+			dup /CharStrings get 1 index /Encoding get
+			ct_dfCharCode get charstring put
+			rootfont /WMode 2 copy known
+				{ get }
+				{ pop pop 0 }
+			ifelse
+			exch
+			1000 scalefont setfont
+			ct_str1 0 ct_dfCharCode put
+			ct_str1 exch ct_dfSetCacheProc
+			ct_SyntheticBold
+				{
+				currentpoint
+				ct_str1 show
+				newpath
+				moveto
+				ct_str1 true charpath
+				ct_StrokeWidth setlinewidth
+				stroke
+				}
+				{ ct_str1 show }
+			ifelse
+			} def
+		/ct_Type4ShowCharString
+			{
+			ct_dfDict ct_dfCharCode charstring
+			FDArray fdIndex get
+			dup /FontMatrix get dup ct_defaultFontMtx ct_matrixeq not
+				{ ct_1000Mtx matrix concatmatrix concat }
+				{ pop }
+			ifelse
+			/Private get
+			Adobe_CoolType_Utility /ct_Level2? get not
+				{
+				ct_dfDict /Private
+				3 -1 roll
+					{ put }
+				1183615869 internaldict /superexec get exec
+				}
+			if
+			1183615869 internaldict
+			Adobe_CoolType_Utility /ct_Level2? get
+				{ 1 index }
+				{ 3 index /Private get mark 6 1 roll }
+			ifelse
+			dup /RunInt known
+				{ /RunInt get }
+				{ pop /CCRun }
+			ifelse
+			get exec
+			Adobe_CoolType_Utility /ct_Level2? get not
+				{ cleartomark }
+			if
+			} bind def
+		/ct_BuildCharIncremental
+			{
+				{
+				Adobe_CoolType_Utility /ct_MakeOCF get begin
+				ct_BuildCharSetUp
+				ct_ShowCharString
+				}
+			stopped
+				{ stop }
+			if
+			end
+			end
+			end
+			end
+			} bind def
+		/BaseFontNameStr (BF00) def
+		/ct_Type1FontTemplate 14 dict
+			begin
+			/FontType 1 def
+			/FontMatrix  [0.001 0 0 0.001 0 0] def
+			/FontBBox  [-250 -250 1250 1250] def
+			/Encoding ct_cHexEncoding def
+			/PaintType 0 def
+			currentdict
+			end def
+		/BaseFontTemplate 11 dict
+			begin
+			/FontMatrix  [0.001 0 0 0.001 0 0] def
+			/FontBBox  [-250 -250 1250 1250] def
+			/Encoding ct_cHexEncoding def
+			/BuildChar /ct_BuildCharIncremental load def
+			ct_Clone?
+				{
+				/FontType 3 def
+				/ct_ShowCharString /ct_Type3ShowCharString load def
+				/ct_dfSetCacheProc /ct_CloneSetCacheProc load def
+				/ct_SyntheticBold false def
+				/ct_StrokeWidth 1 def
+				}
+				{
+				/FontType 4 def
+				/Private 1 dict dup /lenIV 4 put def
+				/CharStrings 1 dict dup /.notdef <d841272cf18f54fc13> put def
+				/PaintType 0 def
+				/ct_ShowCharString /ct_Type4ShowCharString load def
+				}
+			ifelse
+			/ct_str1 1 string def
+			currentdict
+			end def
+		/BaseFontDictSize BaseFontTemplate length 5 add def
+		/ct_matrixeq
+			{
+			true 0 1 5
+				{
+				dup 4 index exch get exch 3 index exch get eq and
+				dup not
+					{ exit }
+				if
+				}
+			for
+			exch pop exch pop
+			} bind def
+		/ct_makeocf
+			{
+			15 dict
+				begin
+				exch /WMode exch def
+				exch /FontName exch def
+				/FontType 0 def
+				/FMapType 2 def
+			dup /FontMatrix known
+				{ dup /FontMatrix get /FontMatrix exch def }
+				{ /FontMatrix matrix def }
+			ifelse
+				/bfCount 1 index /CIDCount get 256 idiv 1 add
+					dup 256 gt { pop 256} if def
+				/Encoding
+					256 array 0 1 bfCount 1 sub { 2 copy dup put pop } for
+					bfCount 1 255 { 2 copy bfCount put pop } for
+					def
+				/FDepVector bfCount dup 256 lt { 1 add } if array def
+				BaseFontTemplate BaseFontDictSize dict copy
+					begin
+					/CIDFont exch def
+					CIDFont /FontBBox known
+						{ CIDFont /FontBBox get /FontBBox exch def }
+					if
+					CIDFont /CDevProc known
+						{ CIDFont /CDevProc get /CDevProc exch def }
+					if
+					currentdict
+					end
+				BaseFontNameStr 3 (0) putinterval
+				0 1 bfCount dup 256 eq { 1 sub } if
+					{
+					FDepVector exch
+					2 index BaseFontDictSize dict copy
+						begin
+						dup /CIDFirstByte exch 256 mul def
+						FontType 3 eq
+							{ /ct_FDDict 2 dict def }
+						if
+						currentdict
+						end
+					1 index  16
+					BaseFontNameStr  2 2 getinterval cvrs pop
+					BaseFontNameStr exch definefont
+					put
+					}
+				for
+				ct_Clone?
+					{ /Widths 1 index /CIDFont get /GlyphDirectory get length dict def }
+				if
+				FontName
+				currentdict
+				end
+			definefont
+			ct_Clone?
+				{
+				gsave
+				dup 1000 scalefont setfont
+				ct_BuildCharDict
+					begin
+					/usewidths? false def
+					currentfont /Widths get
+						begin
+						exch /CIDFont get /GlyphDirectory get
+							{
+							pop
+							dup charcode exch 1 index 0 2 index 256 idiv put
+							1 index exch 1 exch 256 mod put
+							stringwidth 2 array astore def
+							}
+						forall
+						end
+					/usewidths? true def
+					end
+				grestore
+				}
+				{ exch pop }
+			ifelse
+			} bind def
+		/ct_ComposeFont
+			{
+			ct_UseNativeCapability?
+				{
+				2 index /CMap ct_resourcestatus
+					{ pop pop exch pop }
+					{
+					/CIDInit /ProcSet findresource
+						begin
+						12 dict
+							begin
+							begincmap
+							/CMapName 3 index def
+							/CMapVersion 1.000 def
+							/CMapType 1 def
+							exch /WMode exch def
+							/CIDSystemInfo 3 dict dup
+								begin
+								/Registry (Adobe) def
+								/Ordering
+								CMapName ct_mkocfStr100 cvs
+								(Adobe-) search
+									{
+									pop pop
+									(-) search
+										{
+										dup length string copy
+										exch pop exch pop
+										}
+										{ pop (Identity)}
+									ifelse
+									}
+									{ pop  (Identity)  }
+								ifelse
+								def
+								/Supplement 0 def
+								end def
+							1 begincodespacerange
+							<0000> <FFFF>
+							endcodespacerange
+							1 begincidrange
+							<0000> <FFFF> 0
+							endcidrange
+							endcmap
+							CMapName currentdict /CMap defineresource pop
+							end
+						end
+					}
+				ifelse
+				composefont
+				}
+				{
+				3 2 roll pop
+				0 get /CIDFont findresource
+				ct_makeocf
+				}
+			ifelse
+			} bind def
+		/ct_MakeIdentity
+			{
+			ct_UseNativeCapability?
+				{
+				1 index /CMap ct_resourcestatus
+					{ pop pop }
+					{
+					/CIDInit /ProcSet findresource begin
+					12 dict begin
+					begincmap
+					/CMapName 2 index def
+					/CMapVersion 1.000 def
+					/CMapType 1 def
+					/CIDSystemInfo 3 dict dup
+						begin
+						/Registry (Adobe) def
+						/Ordering
+						CMapName ct_mkocfStr100 cvs
+						(Adobe-) search
+							{
+							pop pop
+							(-) search
+								{ dup length string copy exch pop exch pop }
+								{ pop (Identity) }
+							ifelse
+							}
+							{ pop (Identity) }
+						ifelse
+						def
+						/Supplement 0 def
+						end def
+					1 begincodespacerange
+					<0000> <FFFF>
+					endcodespacerange
+					1 begincidrange
+					<0000> <FFFF> 0
+					endcidrange
+					endcmap
+					CMapName currentdict /CMap defineresource pop
+					end
+					end
+					}
+				ifelse
+				composefont
+				}
+				{
+				exch pop
+				0 get /CIDFont findresource
+				ct_makeocf
+				}
+			ifelse
+			} bind def
+		currentdict readonly pop
+		end
+	end
+%%EndResource
+%%BeginResource: procset Adobe_CoolType_Utility_T42 1.0 0
+%%Copyright: Copyright 1987-2003 Adobe Systems Incorporated.
+%%Version: 1.0 0
+userdict /ct_T42Dict 15 dict put
+ct_T42Dict begin
+/Is2015?
+{
+  version
+  cvi
+  2015
+  ge
+} bind def
+/AllocGlyphStorage
+{
+  Is2015?
+  {	
+		pop
+  }
+  {
+		{string} forall
+  } ifelse
+} bind def
+/Type42DictBegin
+{
+	25 dict begin
+  /FontName exch def
+  /CharStrings 256 dict
+	begin
+		  /.notdef 0 def
+		  currentdict
+	end def
+  /Encoding exch def
+  /PaintType 0 def
+  /FontType 42 def
+  /FontMatrix [1 0 0 1 0 0] def
+  4 array  astore cvx /FontBBox exch def
+  /sfnts
+} bind def
+/Type42DictEnd
+{
+	 currentdict dup /FontName get exch definefont end
+	ct_T42Dict exch
+	dup /FontName get exch put
+} bind def
+/RD {string currentfile exch readstring pop} executeonly def
+/PrepFor2015
+{
+	Is2015?
+	{		
+		 /GlyphDirectory
+		 16
+		 dict def
+		 sfnts 0 get
+		 dup
+		 2 index
+		 (glyx)
+		 putinterval
+		 2 index
+		 (locx)
+		 putinterval
+		 pop
+		 pop
+	}
+	{
+		 pop
+		 pop
+	} ifelse			
+} bind def
+/AddT42Char
+{
+	Is2015?
+	{
+		/GlyphDirectory get
+		begin
+		def
+		end
+		pop
+		pop
+	}
+	{
+		/sfnts get
+		4 index
+		get
+		3 index
+	  2 index
+		putinterval
+		pop
+		pop
+		pop
+		pop
+	} ifelse
+} bind def
+end
+%%EndResource
+Adobe_CoolType_Core begin /$Oblique SetSubstituteStrategy end
+%%BeginResource: procset Adobe_AGM_Image 1.0 0
+%%Version: 1.0 0
+%%Copyright: Copyright (C) 2000-2003 Adobe Systems, Inc.  All Rights Reserved.
+systemdict /setpacking known
+{
+	currentpacking
+	true setpacking
+} if
+userdict /Adobe_AGM_Image 75 dict dup begin put
+/Adobe_AGM_Image_Id /Adobe_AGM_Image_1.0_0 def
+/nd{
+	null def
+}bind def
+/AGMIMG_&image nd
+/AGMIMG_&colorimage nd
+/AGMIMG_&imagemask nd
+/AGMIMG_mbuf () def
+/AGMIMG_ybuf () def
+/AGMIMG_kbuf () def
+/AGMIMG_c 0 def
+/AGMIMG_m 0 def
+/AGMIMG_y 0 def
+/AGMIMG_k 0 def
+/AGMIMG_tmp nd
+/AGMIMG_imagestring0 nd
+/AGMIMG_imagestring1 nd
+/AGMIMG_imagestring2 nd
+/AGMIMG_imagestring3 nd
+/AGMIMG_imagestring4 nd
+/AGMIMG_imagestring5 nd
+/AGMIMG_cnt nd
+/AGMIMG_fsave nd
+/AGMIMG_colorAry nd
+/AGMIMG_override nd
+/AGMIMG_name nd
+/AGMIMG_maskSource nd
+/invert_image_samples nd
+/knockout_image_samples	nd
+/img nd
+/sepimg nd
+/devnimg nd
+/idximg nd
+/doc_setup
+{
+	Adobe_AGM_Core begin
+	Adobe_AGM_Image begin
+	/AGMIMG_&image systemdict/image get def
+	/AGMIMG_&imagemask systemdict/imagemask get def
+	/colorimage where{
+		pop
+		/AGMIMG_&colorimage /colorimage ldf
+	}if
+	end
+	end
+}def
+/page_setup
+{
+	Adobe_AGM_Image begin
+	/AGMIMG_ccimage_exists {/customcolorimage where
+		{
+			pop
+			/Adobe_AGM_OnHost_Seps where
+			{
+			pop false
+			}{
+			/Adobe_AGM_InRip_Seps where
+				{
+				pop false
+				}{
+					true
+				 }ifelse
+			 }ifelse
+			}{
+			false
+		}ifelse
+	}bdf
+	level2{
+		/invert_image_samples
+		{
+			Adobe_AGM_Image/AGMIMG_tmp Decode length ddf
+			/Decode [ Decode 1 get Decode 0 get] def
+		}def
+		/knockout_image_samples
+		{
+			Operator/imagemask ne{
+				/Decode [1 1] def
+			}if
+		}def
+	}{	
+		/invert_image_samples
+		{
+			{1 exch sub} currenttransfer addprocs settransfer
+		}def
+		/knockout_image_samples
+		{
+			{ pop 1 } currenttransfer addprocs settransfer
+		}def
+	}ifelse
+	/img /imageormask ldf
+	/sepimg /sep_imageormask ldf
+	/devnimg /devn_imageormask ldf
+	/idximg /indexed_imageormask ldf
+	/_ctype 7 def
+	currentdict{
+		dup xcheck 1 index type dup /arraytype eq exch /packedarraytype eq or and{
+			bind
+		}if
+		def
+	}forall
+}def
+/page_trailer
+{
+	end
+}def
+/doc_trailer
+{
+}def
+/imageormask_sys
+{
+	begin
+		save mark
+		level2{
+			currentdict
+			Operator /imagemask eq{
+				AGMIMG_&imagemask
+			}{
+				use_mask {
+					level3 {process_mask_L3 AGMIMG_&image}{masked_image_simulation}ifelse
+				}{
+					AGMIMG_&image
+				}ifelse
+			}ifelse
+		}{
+			Width Height
+			Operator /imagemask eq{
+				Decode 0 get 1 eq Decode 1 get 0 eq	and
+				ImageMatrix /DataSource load
+				AGMIMG_&imagemask
+			}{
+				BitsPerComponent ImageMatrix /DataSource load
+				AGMIMG_&image
+			}ifelse
+		}ifelse
+		cleartomark restore
+	end
+}def
+/overprint_plate
+{
+	currentoverprint {
+		0 get dup type /nametype eq {
+			dup /DeviceGray eq{
+				pop AGMCORE_black_plate not
+			}{
+				/DeviceCMYK eq{
+					AGMCORE_is_cmyk_sep not
+				}if
+			}ifelse
+		}{
+			false exch
+			{
+				 AGMOHS_sepink eq or
+			} forall
+			not
+		} ifelse
+	}{
+		pop false
+	}ifelse
+}def
+/process_mask_L3
+{
+	dup begin
+	/ImageType 1 def
+	end
+	4 dict begin
+		/DataDict exch def
+		/ImageType 3 def
+		/InterleaveType 3 def
+		/MaskDict 9 dict begin
+			/ImageType 1 def
+			/Width DataDict dup /MaskWidth known {/MaskWidth}{/Width} ifelse get def
+			/Height DataDict dup /MaskHeight known {/MaskHeight}{/Height} ifelse get def
+			/ImageMatrix [Width 0 0 Height neg 0 Height] def
+			/NComponents 1 def
+			/BitsPerComponent 1 def
+			/Decode [0 1] def
+			/DataSource AGMIMG_maskSource def
+		currentdict end def
+	currentdict end
+}def
+/use_mask
+{
+	dup type /dicttype eq
+	{
+		dup /Mask known	{
+			dup /Mask get {
+				level3
+				{true}
+				{
+					dup /MaskWidth known {dup /MaskWidth get 1 index /Width get eq}{true}ifelse exch
+					dup /MaskHeight known {dup /MaskHeight get 1 index /Height get eq}{true}ifelse
+					3 -1 roll and
+				} ifelse
+			}
+			{false} ifelse
+		}
+		{false} ifelse
+	}
+	{false} ifelse
+}def
+/make_line_source
+{
+	begin
+	MultipleDataSources {
+		[
+		Decode length 2 div cvi {Width string} repeat
+		]
+	}{
+		Width Decode length 2 div mul cvi string
+	}ifelse
+	end
+}def
+/datasource_to_str
+{
+	exch dup type
+	dup /filetype eq {
+		pop exch readstring
+	}{
+		/arraytype eq {
+			exec exch copy
+		}{
+			pop
+		}ifelse
+	}ifelse
+	pop
+}def
+/masked_image_simulation
+{
+	3 dict begin
+	dup make_line_source /line_source xdf
+	/mask_source AGMIMG_maskSource /LZWDecode filter def
+	dup /Width get 8 div ceiling cvi string /mask_str xdf
+	begin
+	gsave
+	0 1 translate 1 -1 Height div scale
+	1 1 Height {
+		pop
+		gsave
+		MultipleDataSources {
+			0 1 DataSource length 1 sub {
+				dup DataSource exch get
+				exch line_source exch get
+				datasource_to_str
+			} for
+		}{
+			DataSource line_source datasource_to_str
+		} ifelse
+		<<
+			/PatternType 1
+			/PaintProc [
+				/pop cvx
+				<<
+					/ImageType 1
+					/Width Width
+					/Height 1
+					/ImageMatrix Width 1.0 sub 1 matrix scale 0.5 0 matrix translate matrix concatmatrix
+					/MultipleDataSources MultipleDataSources
+					/DataSource line_source
+					/BitsPerComponent BitsPerComponent
+					/Decode Decode
+				>>
+				/image cvx
+			] cvx
+			/BBox [0 0 Width 1]
+			/XStep Width
+			/YStep 1
+			/PaintType 1
+			/TilingType 2
+		>>
+		matrix makepattern set_pattern
+		<<
+			/ImageType 1
+			/Width Width
+			/Height 1
+			/ImageMatrix Width 1 matrix scale
+			/MultipleDataSources false
+			/DataSource mask_source mask_str readstring pop
+			/BitsPerComponent 1
+			/Decode [0 1]
+		>>
+		imagemask
+		grestore
+		0 1 translate
+	} for
+	grestore
+	end
+	end
+}def
+/imageormask
+{
+	begin
+		SkipImageProc {
+			currentdict consumeimagedata
+		}
+		{
+			save mark
+			level2 AGMCORE_host_sep not and{
+				currentdict
+				Operator /imagemask eq DeviceN_PS2 not and {
+					imagemask
+				}{
+					AGMCORE_in_rip_sep currentoverprint and currentcolorspace 0 get /DeviceGray eq and{
+						[/Separation /Black /DeviceGray {}] setcolorspace
+						/Decode [ Decode 1 get Decode 0 get ] def
+					}if
+					use_mask {
+						level3 {process_mask_L3 image}{masked_image_simulation}ifelse
+					}{
+						DeviceN_NoneName DeviceN_PS2 Indexed_DeviceN level3 not and or or AGMCORE_in_rip_sep and
+						{
+							Names convert_to_process not {
+								2 dict begin
+								/imageDict xdf
+								/names_index 0 def
+								gsave
+								imageDict write_image_file {
+									Names {
+										dup (None) ne {
+											[/Separation 3 -1 roll /DeviceGray {1 exch sub}] setcolorspace
+											Operator imageDict read_image_file
+											names_index 0 eq {true setoverprint} if
+											/names_index names_index 1 add def
+										}{
+											pop
+										} ifelse
+									} forall
+									close_image_file
+								} if
+								grestore
+								end
+							}{
+								Operator /imagemask eq {
+									imagemask
+								}{
+									image
+								} ifelse
+							} ifelse
+						}{
+							Operator /imagemask eq {
+								imagemask
+							}{
+								image
+							} ifelse
+						} ifelse
+					}ifelse
+				}ifelse
+			}{
+				Width Height
+				Operator /imagemask eq{
+					Decode 0 get 1 eq Decode 1 get 0 eq	and
+					ImageMatrix /DataSource load
+					/Adobe_AGM_OnHost_Seps where {
+						pop imagemask
+					}{
+						currentgray 1 ne{
+							currentdict imageormask_sys
+						}{
+							currentoverprint not{
+								1 AGMCORE_&setgray
+								currentdict imageormask_sys
+							}{
+								currentdict ignoreimagedata
+							}ifelse				 		
+						}ifelse
+					}ifelse
+				}{
+					BitsPerComponent ImageMatrix
+					MultipleDataSources{
+						0 1 NComponents 1 sub{
+							DataSource exch get
+						}for
+					}{
+						/DataSource load
+					}ifelse
+					Operator /colorimage eq{
+						AGMCORE_host_sep{
+							MultipleDataSources level2 or NComponents 4 eq and{
+								AGMCORE_is_cmyk_sep{
+									MultipleDataSources{
+										/DataSource [
+											DataSource 0 get /exec cvx
+											DataSource 1 get /exec cvx
+											DataSource 2 get /exec cvx
+											DataSource 3 get /exec cvx
+											/AGMCORE_get_ink_data cvx
+										] cvx def
+									}{
+										/DataSource
+										Width BitsPerComponent mul 7 add 8 idiv Height mul 4 mul
+										/DataSource load
+										filter_cmyk 0 () /SubFileDecode filter def
+									}ifelse
+									/Decode [ Decode 0 get Decode 1 get ] def
+									/MultipleDataSources false def
+									/NComponents 1 def
+									/Operator /image def
+									invert_image_samples
+						 			1 AGMCORE_&setgray
+									currentdict imageormask_sys
+								}{
+									currentoverprint not Operator/imagemask eq and{
+  			 							1 AGMCORE_&setgray
+  			 							currentdict imageormask_sys
+  			 						}{
+  			 							currentdict ignoreimagedata
+  			 						}ifelse
+								}ifelse
+							}{	
+								MultipleDataSources NComponents AGMIMG_&colorimage						
+							}ifelse
+						}{
+							true NComponents colorimage
+						}ifelse
+					}{
+						Operator /image eq{
+							AGMCORE_host_sep{
+								/DoImage true def
+								HostSepColorImage{
+									invert_image_samples
+								}{
+									AGMCORE_black_plate not Operator/imagemask ne and{
+										/DoImage false def
+										currentdict ignoreimagedata
+					 				}if
+								}ifelse
+						 		1 AGMCORE_&setgray
+								DoImage
+									{currentdict imageormask_sys} if
+							}{
+								use_mask {
+									level3 {process_mask_L3 image}{masked_image_simulation}ifelse
+								}{
+									image
+								}ifelse
+							}ifelse
+						}{
+							Operator/knockout eq{
+								pop pop pop pop pop
+								currentcolorspace overprint_plate not{
+									knockout_unitsq
+								}if
+							}if
+						}ifelse
+					}ifelse
+				}ifelse
+			}ifelse
+			cleartomark restore
+		}ifelse
+	end
+}def
+/sep_imageormask
+{
+ 	/sep_colorspace_dict AGMCORE_gget begin
+	/MappedCSA CSA map_csa def
+	begin
+	SkipImageProc {
+		currentdict consumeimagedata
+	}
+	{
+		save mark
+		AGMCORE_avoid_L2_sep_space{
+			/Decode [ Decode 0 get 255 mul Decode 1 get 255 mul ] def
+		}if
+ 		AGMIMG_ccimage_exists
+		MappedCSA 0 get /DeviceCMYK eq and
+		currentdict/Components known and
+		Name () ne and
+		Name (All) ne and
+		Operator /image eq and
+		AGMCORE_producing_seps not and
+		level2 not and
+		{
+			Width Height BitsPerComponent ImageMatrix
+			[
+			/DataSource load /exec cvx
+			{
+				0 1 2 index length 1 sub{
+					1 index exch
+					2 copy get 255 xor put
+				}for
+			} /exec cvx
+			] cvx bind
+			MappedCSA 0 get /DeviceCMYK eq{
+				Components aload pop
+			}{
+				0 0 0 Components aload pop 1 exch sub
+			}ifelse
+			Name findcmykcustomcolor
+			customcolorimage
+		}{
+			AGMCORE_producing_seps not{
+				level2{
+					AGMCORE_avoid_L2_sep_space not currentcolorspace 0 get /Separation ne and{
+						[/Separation Name MappedCSA sep_proc_name exch 0 get exch load ] setcolorspace_opt
+						/sep_tint AGMCORE_gget setcolor
+					}if
+					currentdict imageormask
+				}{
+					currentdict
+					Operator /imagemask eq{
+						imageormask
+					}{
+						sep_imageormask_lev1
+					}ifelse
+				}ifelse
+ 			}{
+				AGMCORE_host_sep{
+					Operator/knockout eq{
+						currentdict/ImageMatrix get concat
+						knockout_unitsq
+					}{
+						currentgray 1 ne{
+ 							AGMCORE_is_cmyk_sep Name (All) ne and{
+ 								level2{
+	 								[ /Separation Name [/DeviceGray]
+	 								{
+	 									sep_colorspace_proc AGMCORE_get_ink_data
+										1 exch sub
+	 								} bind
+									] AGMCORE_&setcolorspace
+									/sep_tint AGMCORE_gget AGMCORE_&setcolor
+ 									currentdict imageormask_sys
+	 							}{
+	 								currentdict
+									Operator /imagemask eq{
+										imageormask_sys
+									}{
+										sep_image_lev1_sep
+									}ifelse
+	 							}ifelse
+ 							}{
+ 								Operator/imagemask ne{
+									invert_image_samples
+ 								}if
+		 						currentdict imageormask_sys
+ 							}ifelse
+ 						}{
+ 							currentoverprint not Name (All) eq or Operator/imagemask eq and{
+								currentdict imageormask_sys
+								}{
+								currentoverprint not
+									{
+ 									gsave
+ 									knockout_unitsq
+ 									grestore
+									}if
+								currentdict consumeimagedata
+		 					}ifelse
+ 						}ifelse
+		 			}ifelse
+ 				}{
+					currentcolorspace 0 get /Separation ne{
+						[/Separation Name MappedCSA sep_proc_name exch 0 get exch load ] setcolorspace_opt
+						/sep_tint AGMCORE_gget setcolor
+					}if
+					currentoverprint
+					MappedCSA 0 get /DeviceCMYK eq and
+					Name inRip_spot_has_ink not and
+					Name (All) ne and {
+						imageormask_l2_overprint
+					}{
+						currentdict imageormask
+ 					}ifelse
+				}ifelse
+			}ifelse
+		}ifelse
+		cleartomark restore
+	}ifelse
+	end
+	end
+}def
+/decode_image_sample
+{
+	4 1 roll exch dup 5 1 roll
+	sub 2 4 -1 roll exp 1 sub div mul add
+} bdf
+/colorSpaceElemCnt
+{
+	currentcolorspace 0 get dup /DeviceCMYK eq {
+		pop 4
+	}
+	{
+		/DeviceRGB eq {
+			pop 3
+		}{
+			1
+		} ifelse
+	} ifelse
+} bdf
+/devn_sep_datasource
+{
+	1 dict begin
+	/dataSource xdf
+	[
+		0 1 dataSource length 1 sub {
+			dup currentdict /dataSource get /exch cvx /get cvx /exec cvx
+			/exch cvx names_index /ne cvx [ /pop cvx ] cvx /if cvx
+		} for
+	] cvx bind
+	end
+} bdf		
+/devn_alt_datasource
+{
+	11 dict begin
+	/srcDataStrs xdf
+	/dstDataStr xdf
+	/convProc xdf
+	/origcolorSpaceElemCnt xdf
+	/origMultipleDataSources xdf
+	/origBitsPerComponent xdf
+	/origDecode xdf
+	/origDataSource xdf
+	/dsCnt origMultipleDataSources {origDataSource length}{1}ifelse def
+	/samplesNeedDecoding
+		0 0 1 origDecode length 1 sub {
+			origDecode exch get add
+		} for
+		origDecode length 2 div div
+		dup 1 eq {
+			/decodeDivisor 2 origBitsPerComponent exp 1 sub def
+		} if
+		2 origBitsPerComponent exp 1 sub ne
+	def
+	[
+		0 1 dsCnt 1 sub [
+			currentdict /origMultipleDataSources get {
+				dup currentdict /origDataSource get exch get dup type
+			}{
+				currentdict /origDataSource get dup type
+			} ifelse
+			dup /filetype eq {
+				pop currentdict /srcDataStrs get 3 -1 /roll cvx /get cvx /readstring cvx /pop cvx
+			}{
+				/stringtype ne {
+					/exec cvx
+				} if
+				currentdict /srcDataStrs get /exch cvx 3 -1 /roll cvx /xpt cvx
+			} ifelse
+		] cvx /for cvx
+		currentdict /srcDataStrs get 0 /get cvx /length cvx 0 /ne cvx [
+			0 1 Width 1 sub [
+				Adobe_AGM_Utils /AGMUTIL_ndx /xddf cvx
+				currentdict /origMultipleDataSources get {
+					0 1 dsCnt 1 sub [
+						Adobe_AGM_Utils /AGMUTIL_ndx1 /xddf cvx
+						currentdict /srcDataStrs get /AGMUTIL_ndx1 /load cvx /get cvx /AGMUTIL_ndx /load cvx /get cvx
+						samplesNeedDecoding {
+							currentdict /decodeDivisor known {
+								currentdict /decodeDivisor get /div cvx
+							}{
+								currentdict /origDecode get /AGMUTIL_ndx1 /load cvx 2 /mul cvx 2 /getinterval cvx /aload cvx /pop cvxs
+								BitsPerComponent /decode_image_sample load /exec cvx
+							} ifelse
+						} if
+					] cvx /for cvx
+				}{
+					Adobe_AGM_Utils /AGMUTIL_ndx1 0 /ddf cvx
+					currentdict /srcDataStrs get 0 /get cvx /AGMUTIL_ndx /load cvx		
+					currentdict /origDecode get length 2 idiv dup 3 1 /roll cvx /mul cvx /exch cvx /getinterval cvx
+					[
+						samplesNeedDecoding {
+							currentdict /decodeDivisor known {
+								currentdict /decodeDivisor get /div cvx
+							}{
+								currentdict /origDecode get /AGMUTIL_ndx1 /load cvx 2 /mul cvx 2 /getinterval cvx /aload cvx /pop cvx
+								BitsPerComponent /decode_image_sample load /exec cvx
+								Adobe_AGM_Utils /AGMUTIL_ndx1 /AGMUTIL_ndx1 /load cvx 1 /add cvx /ddf cvx
+							} ifelse
+						} if
+					] cvx /forall cvx
+				} ifelse
+				currentdict /convProc get /exec cvx
+				currentdict /origcolorSpaceElemCnt get 1 sub -1 0 [
+					currentdict /dstDataStr get 3 1 /roll cvx /AGMUTIL_ndx /load cvx currentdict /origcolorSpaceElemCnt get /mul cvx /add cvx /exch cvx
+					currentdict /convProc get /filter_indexed_devn load ne {
+						255 /mul cvx /cvi cvx
+					} if
+					/put cvx
+				] cvx /for cvx
+			] cvx /for cvx
+			currentdict /dstDataStr get
+		] cvx /if cvx
+	] cvx bind
+	end
+} bdf
+/devn_imageormask
+{
+ 	/devicen_colorspace_dict AGMCORE_gget begin
+	/MappedCSA CSA map_csa def
+	2 dict begin
+	dup dup
+	/dstDataStr exch /Width get colorSpaceElemCnt mul string def
+	/srcDataStrs [ 3 -1 roll begin
+		currentdict /MultipleDataSources known {MultipleDataSources {DataSource length}{1}ifelse}{1} ifelse
+		{
+			Width Decode length 2 div mul cvi string
+		} repeat
+		end ] def
+	begin
+	SkipImageProc {
+		currentdict consumeimagedata
+	}
+	{
+		save mark
+		AGMCORE_producing_seps not {
+			level3 not {
+				Operator /imagemask ne {
+					/DataSource [
+						DataSource Decode BitsPerComponent currentdict /MultipleDataSources known {MultipleDataSources}{false} ifelse
+						colorSpaceElemCnt /devicen_colorspace_dict AGMCORE_gget /TintTransform get
+						dstDataStr srcDataStrs devn_alt_datasource /exec cvx
+						] cvx 0 () /SubFileDecode filter def
+					/MultipleDataSources false def
+					/Decode colorSpaceElemCnt [ exch {0 1} repeat ] def
+				} if
+			}if
+			currentdict imageormask
+ 		}{
+			AGMCORE_host_sep{
+				Names convert_to_process {
+					CSA map_csa 0 get /DeviceCMYK eq {
+						/DataSource
+							Width BitsPerComponent mul 7 add 8 idiv Height mul 4 mul
+							[
+							DataSource Decode BitsPerComponent currentdict /MultipleDataSources known {MultipleDataSources}{false} ifelse
+							4 /devicen_colorspace_dict AGMCORE_gget /TintTransform get
+							dstDataStr srcDataStrs devn_alt_datasource /exec cvx
+							] cvx
+						filter_cmyk 0 () /SubFileDecode filter def
+						/MultipleDataSources false def
+						/Decode [1 0] def
+						/DeviceGray setcolorspace
+			 			currentdict imageormask_sys
+ 					}{
+						AGMCORE_report_unsupported_color_space
+						AGMCORE_black_plate {
+							/DataSource [
+								DataSource Decode BitsPerComponent currentdict /MultipleDataSources known {MultipleDataSources}{false} ifelse
+								CSA map_csa 0 get /DeviceRGB eq{3}{1}ifelse /devicen_colorspace_dict AGMCORE_gget /TintTransform get
+								dstDataStr srcDataStrs devn_alt_datasource /exec cvx
+								] cvx 0 () /SubFileDecode filter def
+							/MultipleDataSources false def
+							/Decode colorSpaceElemCnt [ exch {0 1} repeat ] def
+				 			currentdict imageormask_sys
+				 		}
+						{
+	 						gsave
+	 						knockout_unitsq
+	 						grestore
+							currentdict consumeimagedata
+						} ifelse
+ 					} ifelse
+				}
+				{	
+					/devicen_colorspace_dict AGMCORE_gget /names_index known {
+	 					Operator/imagemask ne{
+	 						MultipleDataSources {
+		 						/DataSource [ DataSource devn_sep_datasource /exec cvx ] cvx def
+								/MultipleDataSources false def
+	 						}{
+								/DataSource /DataSource load dstDataStr srcDataStrs 0 get filter_devn def
+	 						} ifelse
+							invert_image_samples
+	 					} if
+			 			currentdict imageormask_sys
+	 				}{
+	 					currentoverprint not Operator/imagemask eq and{
+							currentdict imageormask_sys
+							}{
+							currentoverprint not
+								{
+	 							gsave
+	 							knockout_unitsq
+	 							grestore
+								}if
+							currentdict consumeimagedata
+			 			}ifelse
+	 				}ifelse
+	 			}ifelse
+ 			}{
+				currentdict imageormask
+			}ifelse
+		}ifelse
+		cleartomark restore
+	}ifelse
+	end
+	end
+	end
+}def
+/imageormask_l2_overprint
+{
+	currentdict
+	currentcmykcolor add add add 0 eq{
+		currentdict consumeimagedata
+	}{
+		level3{ 			
+			currentcmykcolor
+			/AGMIMG_k xdf
+			/AGMIMG_y xdf
+			/AGMIMG_m xdf
+			/AGMIMG_c xdf
+			Operator/imagemask eq{
+				[/DeviceN [
+				AGMIMG_c 0 ne {/Cyan} if
+				AGMIMG_m 0 ne {/Magenta} if
+				AGMIMG_y 0 ne {/Yellow} if
+				AGMIMG_k 0 ne {/Black} if
+				] /DeviceCMYK {}] setcolorspace
+				AGMIMG_c 0 ne {AGMIMG_c} if
+				AGMIMG_m 0 ne {AGMIMG_m} if
+				AGMIMG_y 0 ne {AGMIMG_y} if
+				AGMIMG_k 0 ne {AGMIMG_k} if
+				setcolor			
+			}{	
+				/Decode [ Decode 0 get 255 mul Decode 1 get 255 mul ] def
+				[/Indexed 				
+					[
+						/DeviceN [
+							AGMIMG_c 0 ne {/Cyan} if
+							AGMIMG_m 0 ne {/Magenta} if
+							AGMIMG_y 0 ne {/Yellow} if
+							AGMIMG_k 0 ne {/Black} if
+						]
+						/DeviceCMYK {
+							AGMIMG_k 0 eq {0} if
+							AGMIMG_y 0 eq {0 exch} if
+							AGMIMG_m 0 eq {0 3 1 roll} if
+							AGMIMG_c 0 eq {0 4 1 roll} if						
+						}
+					]
+					255
+					{
+						255 div
+						mark exch
+						dup	dup dup
+						AGMIMG_k 0 ne{
+							/sep_tint AGMCORE_gget mul MappedCSA sep_proc_name exch pop load exec 4 1 roll pop pop pop		
+							counttomark 1 roll
+						}{
+							pop
+						}ifelse
+						AGMIMG_y 0 ne{
+							/sep_tint AGMCORE_gget mul MappedCSA sep_proc_name exch pop load exec 4 2 roll pop pop pop		
+							counttomark 1 roll
+						}{
+							pop
+						}ifelse
+						AGMIMG_m 0 ne{
+							/sep_tint AGMCORE_gget mul MappedCSA sep_proc_name exch pop load exec 4 3 roll pop pop pop		
+							counttomark 1 roll
+						}{
+							pop
+						}ifelse
+						AGMIMG_c 0 ne{
+							/sep_tint AGMCORE_gget mul MappedCSA sep_proc_name exch pop load exec pop pop pop		
+							counttomark 1 roll
+						}{
+							pop
+						}ifelse
+						counttomark 1 add -1 roll pop
+					}
+				] setcolorspace
+			}ifelse
+			imageormask_sys
+		}{
+	write_image_file{
+		currentcmykcolor
+		0 ne{
+			[/Separation /Black /DeviceGray {}] setcolorspace
+			gsave
+			/Black
+			[{1 exch sub /sep_tint AGMCORE_gget mul} /exec cvx MappedCSA sep_proc_name cvx exch pop {4 1 roll pop pop pop 1 exch sub} /exec cvx]
+			cvx modify_halftone_xfer
+			Operator currentdict read_image_file
+			grestore
+		}if
+		0 ne{
+			[/Separation /Yellow /DeviceGray {}] setcolorspace
+			gsave
+			/Yellow
+			[{1 exch sub /sep_tint AGMCORE_gget mul} /exec cvx MappedCSA sep_proc_name cvx exch pop {4 2 roll pop pop pop 1 exch sub} /exec cvx]
+			cvx modify_halftone_xfer
+			Operator currentdict read_image_file
+			grestore
+		}if
+		0 ne{
+			[/Separation /Magenta /DeviceGray {}] setcolorspace
+			gsave
+			/Magenta
+			[{1 exch sub /sep_tint AGMCORE_gget mul} /exec cvx MappedCSA sep_proc_name cvx exch pop {4 3 roll pop pop pop 1 exch sub} /exec cvx]
+			cvx modify_halftone_xfer
+			Operator currentdict read_image_file
+			grestore
+		}if
+		0 ne{
+			[/Separation /Cyan /DeviceGray {}] setcolorspace
+			gsave
+			/Cyan
+			[{1 exch sub /sep_tint AGMCORE_gget mul} /exec cvx MappedCSA sep_proc_name cvx exch pop {pop pop pop 1 exch sub} /exec cvx]
+			cvx modify_halftone_xfer
+			Operator currentdict read_image_file
+			grestore
+		} if
+				close_image_file
+			}{
+				imageormask
+			}ifelse
+		}ifelse
+	}ifelse
+} def
+/indexed_imageormask
+{
+	begin
+		save mark
+ 		currentdict
+ 		AGMCORE_host_sep{
+			Operator/knockout eq{
+				/indexed_colorspace_dict AGMCORE_gget dup /CSA known {
+					/CSA get map_csa
+				}{
+					/CSD get get_csd /Names get
+				} ifelse
+				overprint_plate not{
+					knockout_unitsq
+				}if
+			}{
+				Indexed_DeviceN {
+					/devicen_colorspace_dict AGMCORE_gget /names_index known {
+			 			indexed_image_lev2_sep
+					}{
+						currentoverprint not{
+							knockout_unitsq
+			 			}if
+			 			currentdict consumeimagedata
+					} ifelse
+				}{
+		 			AGMCORE_is_cmyk_sep{
+						Operator /imagemask eq{
+							imageormask_sys
+						}{
+							level2{
+								indexed_image_lev2_sep
+							}{
+								indexed_image_lev1_sep
+							}ifelse
+						}ifelse
+					}{
+						currentoverprint not{
+							knockout_unitsq
+			 			}if
+			 			currentdict consumeimagedata
+					}ifelse
+				}ifelse
+			}ifelse
+ 		}{
+			level2{
+				Indexed_DeviceN {
+					/indexed_colorspace_dict AGMCORE_gget begin
+					CSD get_csd begin
+				}{
+					/indexed_colorspace_dict AGMCORE_gget begin
+					CSA map_csa 0 get /DeviceCMYK eq ps_level 3 ge and ps_version 3015.007 lt and {
+						[/Indexed [/DeviceN [/Cyan /Magenta /Yellow /Black] /DeviceCMYK {}] HiVal Lookup]
+						setcolorspace
+					} if
+					end
+				} ifelse
+				imageormask
+				Indexed_DeviceN {
+					end
+					end
+				} if
+			}{
+				Operator /imagemask eq{
+					imageormask
+				}{
+					indexed_imageormask_lev1
+				}ifelse
+			}ifelse
+ 		}ifelse
+		cleartomark restore
+	end
+}def
+/indexed_image_lev2_sep
+{
+	/indexed_colorspace_dict AGMCORE_gget begin
+	begin
+		Indexed_DeviceN not {
+			currentcolorspace
+			dup 1 /DeviceGray put
+			dup 3
+			currentcolorspace 2 get 1 add string
+			0 1 2 3 AGMCORE_get_ink_data 4 currentcolorspace 3 get length 1 sub
+			{
+			dup 4 idiv exch currentcolorspace 3 get exch get 255 exch sub 2 index 3 1 roll put
+			}for
+			put	setcolorspace
+		} if
+		currentdict
+		Operator /imagemask eq{
+			AGMIMG_&imagemask
+		}{
+			use_mask {
+				level3 {process_mask_L3 AGMIMG_&image}{masked_image_simulation}ifelse
+			}{
+				AGMIMG_&image
+			}ifelse
+		}ifelse
+	end end
+}def
+  /OPIimage
+  {
+  	dup type /dicttype ne{
+  		10 dict begin
+  			/DataSource xdf
+  			/ImageMatrix xdf
+  			/BitsPerComponent xdf
+  			/Height xdf
+  			/Width xdf
+  			/ImageType 1 def
+  			/Decode [0 1 def]
+  			currentdict
+  		end
+  	}if
+  	dup begin
+  		/NComponents 1 cdndf
+  		/MultipleDataSources false cdndf
+  		/SkipImageProc {false} cdndf
+  		/HostSepColorImage false cdndf
+  		/Decode [
+  				0
+  				currentcolorspace 0 get /Indexed eq{
+  					2 BitsPerComponent exp 1 sub
+  				}{
+  					1
+  				}ifelse
+  		] cdndf
+  		/Operator /image cdndf
+  	end
+  	/sep_colorspace_dict AGMCORE_gget null eq{
+  		imageormask
+  	}{
+  		gsave
+  		dup begin invert_image_samples end
+  		sep_imageormask
+  		grestore
+  	}ifelse
+  }def
+/cachemask_level2
+{
+	3 dict begin
+	/LZWEncode filter /WriteFilter xdf
+	/readBuffer 256 string def
+	/ReadFilter
+		currentfile
+		0 (%EndMask) /SubFileDecode filter
+		/ASCII85Decode filter
+		/RunLengthDecode filter
+	def
+	{
+		ReadFilter readBuffer readstring exch
+		WriteFilter exch writestring
+		not {exit} if
+	}loop
+	WriteFilter closefile
+	end
+}def
+/cachemask_level3
+{
+	currentfile
+	<<
+		/Filter [ /SubFileDecode /ASCII85Decode /RunLengthDecode ]
+		/DecodeParms [ << /EODCount 0 /EODString (%EndMask) >> null null ]
+		/Intent 1
+	>>
+	/ReusableStreamDecode filter
+}def
+/spot_alias
+{
+	/mapto_sep_imageormask
+	{
+		dup type /dicttype ne{
+			12 dict begin
+				/ImageType 1 def
+				/DataSource xdf
+				/ImageMatrix xdf
+				/BitsPerComponent xdf
+				/Height xdf
+				/Width xdf
+				/MultipleDataSources false def
+		}{
+			begin
+		}ifelse
+				/Decode [/customcolor_tint AGMCORE_gget 0] def
+				/Operator /image def
+				/HostSepColorImage false def
+				/SkipImageProc {false} def
+				currentdict
+			end
+		sep_imageormask
+	}bdf
+	/customcolorimage
+	{
+		Adobe_AGM_Image/AGMIMG_colorAry xddf
+		/customcolor_tint AGMCORE_gget
+		bdict
+			/Name AGMIMG_colorAry 4 get
+			/CSA [ /DeviceCMYK ]
+			/TintMethod /Subtractive
+			/TintProc null
+			/MappedCSA null
+			/NComponents 4
+			/Components [ AGMIMG_colorAry aload pop pop ]
+		edict
+		setsepcolorspace
+		mapto_sep_imageormask
+	}ndf
+	Adobe_AGM_Image/AGMIMG_&customcolorimage /customcolorimage load put
+	/customcolorimage
+	{
+		Adobe_AGM_Image/AGMIMG_override false put
+		dup 4 get map_alias{
+			/customcolor_tint AGMCORE_gget exch setsepcolorspace
+			pop
+			mapto_sep_imageormask
+		}{
+			AGMIMG_&customcolorimage
+		}ifelse			
+	}bdf
+}def
+/snap_to_device
+{
+	6 dict begin
+	matrix currentmatrix
+	dup 0 get 0 eq 1 index 3 get 0 eq and
+	1 index 1 get 0 eq 2 index 2 get 0 eq and or exch pop
+	{
+		1 1 dtransform 0 gt exch 0 gt /AGMIMG_xSign? exch def /AGMIMG_ySign? exch def
+		0 0 transform
+		AGMIMG_ySign? {floor 0.1 sub}{ceiling 0.1 add} ifelse exch
+		AGMIMG_xSign? {floor 0.1 sub}{ceiling 0.1 add} ifelse exch
+		itransform /AGMIMG_llY exch def /AGMIMG_llX exch def
+		1 1 transform
+		AGMIMG_ySign? {ceiling 0.1 add}{floor 0.1 sub} ifelse exch
+		AGMIMG_xSign? {ceiling 0.1 add}{floor 0.1 sub} ifelse exch
+		itransform /AGMIMG_urY exch def /AGMIMG_urX exch def			
+		[AGMIMG_urX AGMIMG_llX sub 0 0 AGMIMG_urY AGMIMG_llY sub  AGMIMG_llX AGMIMG_llY] concat
+	}{
+	}ifelse
+	end
+} def
+level2 not{
+	/colorbuf
+	{
+		0 1 2 index length 1 sub{
+			dup 2 index exch get
+			255 exch sub
+			2 index
+			3 1 roll
+			put
+		}for
+	}def
+	/tint_image_to_color
+	{
+		begin
+			Width Height BitsPerComponent ImageMatrix
+			/DataSource load
+		end
+		Adobe_AGM_Image begin
+			/AGMIMG_mbuf 0 string def
+			/AGMIMG_ybuf 0 string def
+			/AGMIMG_kbuf 0 string def
+			{
+				colorbuf dup length AGMIMG_mbuf length ne
+					{
+					dup length dup dup
+					/AGMIMG_mbuf exch string def
+					/AGMIMG_ybuf exch string def
+					/AGMIMG_kbuf exch string def
+					} if
+				dup AGMIMG_mbuf copy AGMIMG_ybuf copy AGMIMG_kbuf copy pop
+			}
+			addprocs
+			{AGMIMG_mbuf}{AGMIMG_ybuf}{AGMIMG_kbuf} true 4 colorimage	
+		end
+	} def			
+	/sep_imageormask_lev1
+	{
+		begin
+			MappedCSA 0 get dup /DeviceRGB eq exch /DeviceCMYK eq or has_color not and{
+				{
+					255 mul round cvi GrayLookup exch get
+				} currenttransfer addprocs settransfer
+				currentdict imageormask
+			}{
+				/sep_colorspace_dict AGMCORE_gget/Components known{
+					MappedCSA 0 get /DeviceCMYK eq{
+						Components aload pop
+					}{
+						0 0 0 Components aload pop 1 exch sub
+					}ifelse
+					Adobe_AGM_Image/AGMIMG_k xddf
+					Adobe_AGM_Image/AGMIMG_y xddf
+					Adobe_AGM_Image/AGMIMG_m xddf
+					Adobe_AGM_Image/AGMIMG_c xddf
+					AGMIMG_y 0.0 eq AGMIMG_m 0.0 eq and AGMIMG_c 0.0 eq and{
+						{AGMIMG_k mul 1 exch sub} currenttransfer addprocs settransfer
+						currentdict imageormask
+					}{
+						currentcolortransfer
+						{AGMIMG_k mul 1 exch sub} exch addprocs 4 1 roll
+						{AGMIMG_y mul 1 exch sub} exch addprocs 4 1 roll
+						{AGMIMG_m mul 1 exch sub} exch addprocs 4 1 roll
+						{AGMIMG_c mul 1 exch sub} exch addprocs 4 1 roll
+						setcolortransfer
+						currentdict tint_image_to_color
+					}ifelse
+				}{
+					MappedCSA 0 get /DeviceGray eq {
+						{255 mul round cvi ColorLookup exch get 0 get} currenttransfer addprocs settransfer
+						currentdict imageormask
+					}{
+						MappedCSA 0 get /DeviceCMYK eq {
+							currentcolortransfer
+							{255 mul round cvi ColorLookup exch get 3 get 1 exch sub} exch addprocs 4 1 roll
+							{255 mul round cvi ColorLookup exch get 2 get 1 exch sub} exch addprocs 4 1 roll
+							{255 mul round cvi ColorLookup exch get 1 get 1 exch sub} exch addprocs 4 1 roll
+							{255 mul round cvi ColorLookup exch get 0 get 1 exch sub} exch addprocs 4 1 roll
+							setcolortransfer
+							currentdict tint_image_to_color
+						}{
+							currentcolortransfer
+							{pop 1} exch addprocs 4 1 roll
+							{255 mul round cvi ColorLookup exch get 2 get} exch addprocs 4 1 roll
+							{255 mul round cvi ColorLookup exch get 1 get} exch addprocs 4 1 roll
+							{255 mul round cvi ColorLookup exch get 0 get} exch addprocs 4 1 roll
+							setcolortransfer
+							currentdict tint_image_to_color
+						}ifelse
+					}ifelse
+				}ifelse
+			}ifelse
+		end
+	}def
+	/sep_image_lev1_sep
+	{
+		begin
+			/sep_colorspace_dict AGMCORE_gget/Components known{
+				Components aload pop
+				Adobe_AGM_Image/AGMIMG_k xddf
+				Adobe_AGM_Image/AGMIMG_y xddf
+				Adobe_AGM_Image/AGMIMG_m xddf
+				Adobe_AGM_Image/AGMIMG_c xddf
+				{AGMIMG_c mul 1 exch sub}
+				{AGMIMG_m mul 1 exch sub}
+				{AGMIMG_y mul 1 exch sub}
+				{AGMIMG_k mul 1 exch sub}
+			}{
+				{255 mul round cvi ColorLookup exch get 0 get 1 exch sub}
+				{255 mul round cvi ColorLookup exch get 1 get 1 exch sub}
+				{255 mul round cvi ColorLookup exch get 2 get 1 exch sub}
+				{255 mul round cvi ColorLookup exch get 3 get 1 exch sub}
+			}ifelse
+			AGMCORE_get_ink_data currenttransfer addprocs settransfer
+			currentdict imageormask_sys
+		end
+	}def
+	/indexed_imageormask_lev1
+	{
+		/indexed_colorspace_dict AGMCORE_gget begin
+		begin
+			currentdict
+			MappedCSA 0 get dup /DeviceRGB eq exch /DeviceCMYK eq or has_color not and{
+				{HiVal mul round cvi GrayLookup exch get HiVal div} currenttransfer addprocs settransfer
+				imageormask
+			}{
+				MappedCSA 0 get /DeviceGray eq {
+					{HiVal mul round cvi Lookup exch get HiVal div} currenttransfer addprocs settransfer
+					imageormask
+				}{
+					MappedCSA 0 get /DeviceCMYK eq {
+						currentcolortransfer
+						{4 mul HiVal mul round cvi 3 add Lookup exch get HiVal div 1 exch sub} exch addprocs 4 1 roll
+						{4 mul HiVal mul round cvi 2 add Lookup exch get HiVal div 1 exch sub} exch addprocs 4 1 roll
+						{4 mul HiVal mul round cvi 1 add Lookup exch get HiVal div 1 exch sub} exch addprocs 4 1 roll
+						{4 mul HiVal mul round cvi		 Lookup exch get HiVal div 1 exch sub} exch addprocs 4 1 roll
+						setcolortransfer
+						tint_image_to_color
+					}{
+						currentcolortransfer
+						{pop 1} exch addprocs 4 1 roll
+						{3 mul HiVal mul round cvi 2 add Lookup exch get HiVal div} exch addprocs 4 1 roll
+						{3 mul HiVal mul round cvi 1 add Lookup exch get HiVal div} exch addprocs 4 1 roll
+						{3 mul HiVal mul round cvi 		Lookup exch get HiVal div} exch addprocs 4 1 roll
+						setcolortransfer
+						tint_image_to_color
+					}ifelse
+				}ifelse
+			}ifelse
+		end end
+	}def
+	/indexed_image_lev1_sep
+	{
+		/indexed_colorspace_dict AGMCORE_gget begin
+		begin
+			{4 mul HiVal mul round cvi		 Lookup exch get HiVal div 1 exch sub}
+			{4 mul HiVal mul round cvi 1 add Lookup exch get HiVal div 1 exch sub}
+			{4 mul HiVal mul round cvi 2 add Lookup exch get HiVal div 1 exch sub}
+			{4 mul HiVal mul round cvi 3 add Lookup exch get HiVal div 1 exch sub}
+			AGMCORE_get_ink_data currenttransfer addprocs settransfer
+			currentdict imageormask_sys
+		end end
+	}def
+}if
+end
+systemdict /setpacking known
+{
+	setpacking
+} if
+%%EndResource
+currentdict Adobe_AGM_Utils eq {end} if
+%%EndProlog
+%%BeginSetup
+Adobe_AGM_Utils begin
+2 2010 Adobe_AGM_Core/doc_setup get exec
+Adobe_CoolType_Core/doc_setup get exec
+Adobe_AGM_Image/doc_setup get exec
+currentdict Adobe_AGM_Utils eq {end} if
+%%EndSetup
+%%Page: Alternate-ISC-logo-v2.ai 1
+%%EndPageComments
+%%BeginPageSetup
+/currentdistillerparams where
+{pop currentdistillerparams /CoreDistVersion get 5000 lt} {true} ifelse
+{ userdict /AI11_PDFMark5 /cleartomark load put
+userdict /AI11_ReadMetadata_PDFMark5 {flushfile cleartomark } bind put}
+{ userdict /AI11_PDFMark5 /pdfmark load put
+userdict /AI11_ReadMetadata_PDFMark5 {/PUT pdfmark} bind put } ifelse
+[/NamespacePush AI11_PDFMark5
+[/_objdef {ai_metadata_stream_123} /type /stream /OBJ AI11_PDFMark5
+[{ai_metadata_stream_123}
+currentfile 0 (%  &&end XMP packet marker&&)
+/SubFileDecode filter AI11_ReadMetadata_PDFMark5
+<?xpacket begin='' id='W5M0MpCehiHzreSzNTczkc9d'?><x:xmpmeta xmlns:x='adobe:ns:meta/' x:xmptk='XMP toolkit 3.0-29, framework 1.6'>
+<rdf:RDF xmlns:rdf='http://www.w3.org/1999/02/22-rdf-syntax-ns#' xmlns:iX='http://ns.adobe.com/iX/1.0/'>
+
+ <rdf:Description rdf:about='uuid:8aa76b3d-2474-11d9-a8a3-000393cd9a96'
+  xmlns:pdf='http://ns.adobe.com/pdf/1.3/'>
+  <pdf:Producer>Adobe PDF library 6.66</pdf:Producer>
+ </rdf:Description>
+
+ <rdf:Description rdf:about='uuid:8aa76b3d-2474-11d9-a8a3-000393cd9a96'
+  xmlns:tiff='http://ns.adobe.com/tiff/1.0/'>
+ </rdf:Description>
+
+ <rdf:Description rdf:about='uuid:8aa76b3d-2474-11d9-a8a3-000393cd9a96'
+  xmlns:xap='http://ns.adobe.com/xap/1.0/'
+  xmlns:xapGImg='http://ns.adobe.com/xap/1.0/g/img/'>
+  <xap:CreateDate>2004-10-06T16:15:40-07:00</xap:CreateDate>
+  <xap:ModifyDate>2004-10-22T21:51:43Z</xap:ModifyDate>
+  <xap:CreatorTool>Illustrator</xap:CreatorTool>
+  <xap:MetadataDate>2004-10-06T16:15:40-07:00</xap:MetadataDate>
+  <xap:Thumbnails>
+   <rdf:Alt>
+    <rdf:li rdf:parseType='Resource'>
+     <xapGImg:format>JPEG</xapGImg:format>
+     <xapGImg:width>256</xapGImg:width>
+     <xapGImg:height>152</xapGImg:height>
+     <xapGImg:image>/9j/4AAQSkZJRgABAgEASABIAAD/7QAsUGhvdG9zaG9wIDMuMAA4QklNA+0AAAAAABAASAAAAAEA&#xA;AQBIAAAAAQAB/+4ADkFkb2JlAGTAAAAAAf/bAIQABgQEBAUEBgUFBgkGBQYJCwgGBggLDAoKCwoK&#xA;DBAMDAwMDAwQDA4PEA8ODBMTFBQTExwbGxscHx8fHx8fHx8fHwEHBwcNDA0YEBAYGhURFRofHx8f&#xA;Hx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8f/8AAEQgAmAEAAwER&#xA;AAIRAQMRAf/EAaIAAAAHAQEBAQEAAAAAAAAAAAQFAwIGAQAHCAkKCwEAAgIDAQEBAQEAAAAAAAAA&#xA;AQACAwQFBgcICQoLEAACAQMDAgQCBgcDBAIGAnMBAgMRBAAFIRIxQVEGE2EicYEUMpGhBxWxQiPB&#xA;UtHhMxZi8CRygvElQzRTkqKyY3PCNUQnk6OzNhdUZHTD0uIIJoMJChgZhJRFRqS0VtNVKBry4/PE&#xA;1OT0ZXWFlaW1xdXl9WZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3OEhYaHiImKi4yNjo+Ck5SVlpeYmZ&#xA;qbnJ2en5KjpKWmp6ipqqusra6voRAAICAQIDBQUEBQYECAMDbQEAAhEDBCESMUEFURNhIgZxgZEy&#xA;obHwFMHR4SNCFVJicvEzJDRDghaSUyWiY7LCB3PSNeJEgxdUkwgJChgZJjZFGidkdFU38qOzwygp&#xA;0+PzhJSktMTU5PRldYWVpbXF1eX1RlZmdoaWprbG1ub2R1dnd4eXp7fH1+f3OEhYaHiImKi4yNjo&#xA;+DlJWWl5iZmpucnZ6fkqOkpaanqKmqq6ytrq+v/aAAwDAQACEQMRAD8AiX5AfkB5O/MTydea1rV5&#xA;qNvdW+oyWSJZSQJGY0ghlBIlhmblymPfMfLlMTQbIQBDOPM//OKX5U6B5e1DWZ9R1uSOxhaX0hcW&#xA;il2H2U5G0NOTUFcOCcskxAVuWOaoQMj0Y1+Wf5EflJ56N+kUuvWEtgImZHu7OTmJS4+Glmv2eG+3&#xA;fMvXYJ6etwb8v2uPpNRHNdCqZz/0Jp+WH/V01v8A5H2n/ZLmv/MSczww7/oTT8sP+rprf/I+0/7J&#xA;cfzEl8MO/wChNPyw/wCrprf/ACPtP+yXH8xJfDDAfzv/AOcc/JHkPyHN5g0i+1Oe9juIYVju5bd4&#xA;uMrUYkRwRNXw+LJ48xkaRKAAfT/5V/8AksPKH/bE07/qEjzJaiynFXYq7FXYq7FXYq7FXYq7FXYq&#xA;7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq+BfyU/MTzH5Nhnn0yUPbSzt9ZsZqtBJ8CAMVBFGHZ&#xA;hv8ARtmz0uihnwkS58XPryDrdVqp4sorlXL5st1/z/8AmP5whlgu7p20+b7VnCqwW9AwYL250YD7&#xA;TE5eI6TSncgS+Zccy1OoGwPD8ggfLXmTzl5HvJLzTD9X9YKtwroksUiqSVVjvTc9iDlkp6bVjhsS&#xA;+wsIxz6Y3Vfc9B1b/nJjWZ9Hhh03TYrPVmH+lXTt6sQp/vqM/wA3+UTT365iY+w4CVyNx7v1uTPt&#xA;eRjsKk9s8j+YrjzH5W0/Wbm0aymu4wzwtsCRsXTcng1KrXemaHV4RiyGAN07jT5TkgJEVae5jNzx&#xA;v/nLL/yT91/zG2v/ABM5dg+pjPk9M/Kv/wAlh5Q/7Ymnf9QkeZzjllOKuxV2KuxV2KuxV2KuxV2K&#xA;uxV2KuxV2KuxV2KuxV2KuxV2KuxV2KuxV2KuxV+eX5W6Yl7aztLvBDMSy/zEqtB8tsyJ644NP6fr&#xA;lI18hZcX8oMuf1fTGP6S9h0Ly3rGtzm20q1M7RgF6UVEXtyZiFHTbOa3ke8u52Adr3lvWNEnFtqt&#xA;qYWkUlCSGRx3oykqeu+DeJ7iuxDANasU07UIriJFaF29RYmAK8kILKVPVc7bsjWnUYiJfVHY/oLy&#xA;/aOlGHIDH6S+zNB1K31TRNP1K2UJb3lvFPEg6KsiBgu38taZzGaBhMxPMF6DHMSiCOoR2VM3jf8A&#xA;zll/5J+6/wCY21/4mcuwfUxnyemflX/5LDyh/wBsTTv+oSPM5xyynFXYq7FXYq7FXYq7FXYq7FXY&#xA;q7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq+A/yedP0NepT4xccie5BRR+FMxNfE8ET0uX+9bNP&#xA;IcZHWh+l9K/kxr2kW1neaZcSxwXskwmjaQhfUUqF4qT1Kla098wMUg5Mgq/nNrujzada6XDKk9+s&#xA;4mbgQ3pIEZaMR0Lcht9PhjlIWIeCebnQQ26U+MszA+AAAP31zoPZyJ4pnps6ftqQqI67s3/KGD81&#xA;YPMejRFNVh8ts6tKJ0mFp6HAsOPqDgFYUoVzYdonTGEvp4/hduJoRnE4/VwfY+lCyggEgE9B45yr&#xA;0Lxb/nLe8tYvyoe2kkCz3N7bmCM9W9NqtT5A5bhI4wFlAmBI5B6l+Vf/AJLDyh/2xNO/6hI8z3EL&#xA;y3/nLq+1nQPJem69oWsalpWoyapHZytZX11BG8UltM5BijkVK8oFoaePjir0v8ooJB+W/lq8nu7u&#xA;9vNR0uyvLy5vbme6keaeBZXPKZ34jk52XbFWYYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7F&#xA;XYq7FXYq7FXYq7FX5z/l3fy2Nq88Y5D1mDodgylE2zaafSR1GnMJfztvI0HWanUSw5xIfzf0l6Zb&#xA;a3plwnITrGe6SkIR9+x+jOdz9k6jGa4TId43dti7QwzF8Ve/Zq61zTLdORmWU9kiIcn7th9Jw6fs&#xA;nUZD9PCO+W37Vzdo4YDnfu3S3y5bW3mjzpptlqVwtnZ3U6xO5JoEFTwBAPxP9kH+Y+GdXDCNJpyI&#xA;CyBfvPf+Ojz5ynU5xxbAvozTPzt/L2W4vbT60bO109R6E8qFY5kX4SIVUF9uylakduucN+aiSbfQ&#xA;Z9gamMYkC+LoOnveJeYvzDnP5kTeatBmlMUUoayS7qRxMYSRCgbZHPLYHp4HMKWT18Qet03Zo/Kj&#xA;DkA5b179vixD84/zA8y+btFi/TEsbJaSVt44o1jVTIRy6bn7I6nMzRZJSyi+4un7Y7OxabSS8Mcz&#xA;G32N+Vf/AJLDyh/2xNO/6hI83jwxeUf85q/+Ss0r/tuW/wD1CXeKvVfyn/8AJWeTf+2Hpv8A1CR4&#xA;q8j8x/nX5n8ifnH5nGr28+o/l4tzp9rNKnxtp082nwSckAqQklWYp0Y1K/FUFV7F5gutN1/yJe6h&#xA;pmoSNaT2M1xY6jp1zJC1fRfi6SwMh2PY9+o2xVjP5faLe+ZPyb8tx3WtanDPqNraXmo6jHeXBvpD&#xA;QSMqXLSGSIOwAbifs1HeuKvOfzm0m/8ALHnz8tdI0fzJ5hhsfMmqG01aNta1GQyRC4tI6KzTEp8M&#xA;77rir2bQfIEWia5+kbXWtYurZ7SW2msNQ1G7voS7yROkyC4kk4OgjZajs2KvH9Is9R1n/nJrzd5Q&#xA;utf12Py9p+mRXtnZQavqEQjmaOxJIZZg1K3D7Vpvir2Xy/5JTSdO1PTZdW1PUbS9ujcW8l3fXUlz&#xA;bxmGKMwpcmT1uIkjZx8X7WKvB/8AnH/RPMX5gflhrGqaj5x8wQa/BqE9rYagNWvfTjEdtBLH6kLS&#xA;NG685TyqtaYq9K/5xr86+aPOH5Yw6n5kJlvYbqa1hvWADXMMQUrK3EAVDM0ZPfjirHPzm/M7zt5G&#xA;/M6wvNIt5NV8u22jC78waSrbCD620RuUG5R0LKC4FKfa23Cr1fyr5t8s+ePLcWraHeG5066HFzG7&#xA;RTROAC0UnAq8ci13FfwOKsS/JBbuS183fXNQv9Qaz8y6rp1s97eXFyUtbaVUijX1XYLxA6jfFWA6&#xA;RZ6jrP8Azk15u8oXWv67H5e0/TIr2zsoNX1CIRzNHYkkMswalbh9q03xV6vB+XE8Oi3+ijzJrJs7&#xA;2/S8W5e+uJL6GBI4gbWK8eQzIjSxFiQfssy964q8i/ObSb/yx58/LXSNH8yeYYbHzJqhtNWjbWtR&#xA;kMkQuLSOis0xKfDO+64q9n0DyDFoWvDU7XWtXurdrWW2m0/UdRur+Eu8kTpMq3MknF0EbLUdmxVl&#xA;WKuxV2KuxV2KuxV8tf8AOKPkvyrr35Z6zJq+mQ3k02qy2zTSL+8WJLa3dVRxRk+JyaqQcqnqsmMj&#xA;hkR1T4EJg8QtKPzn/LXS/JV9pzaXNNJaakJisc5VijQlKqGULUfvO4zoezNdLODxAXGnR6/SRwkc&#xA;PIsk/Ln8gtN17QNP17V9RnSO9VpPqMCKhCh2VaysXryVQ32B1+nMXW9ryxzMIgbdf2ORpezIziJS&#xA;PPownzdp3kO384XUWjyXMOkWbMrRg82kkiFCsEjVKhn25PWg+LfZc1uP2mIgRKPFLoeh9/7Ofk9P&#xA;H2GyT4JxkIxl9Q6x93f+hj2oXjXt9cXjIsbXEjStGleILmpArU985ORs2+nYcfhwEbJ4RW/PZG2X&#xA;l+4mAec+ih6LSrn6O2TjiJdNre38WI8MPXL7Pn+Pek/5j6Pa2nliWWMuW9WMfEQep9gM2GhxgZHm&#xA;O0u2cuoxGEhER8v7X2j+Vf8A5LDyh/2xNO/6hI83LzpeUf8AOapH/KrdKWu51yAgd6C0uv64q9V/&#xA;KYg/lZ5Np/1Y9N/6hI8VYb5Q0/SvMf5j/nBpWq2yXNhdzaVbXVq+4ZBp/p12oQTwqCNwehqMVea6&#xA;5Yeb/wAgZ9Tgtlm1r8qtdWWJVrym0+edCq1rQA1NK/ZkHg2Kvevyiiji/KrycqDip0TT2I93tY2Y&#xA;/STiryz/AJyO/wDJp/kv/wBtw/8AUXp+KvoDFXzXp/lvSfMH/OXnney1P6x6CaPbzJ9VurmyfmsG&#xA;nKKyWskLkUY/CWp3psMVe6+U/LmkeW0vdK064llV5hfGK5nluZo1nURqGlneSRlLQNxLH27Yq+XP&#xA;yK8n+e9f/IrzOPKfmS5025fULiJdIRLcQ3LLa2zOPXaP6xE8qNwqkqjYV74q93/Ij8xPLvmnyhBp&#xA;tjaR6Pq2hItnqnl9FMZtnj+CqI3xemxB3O4NQ2+KqFxLDN/zkwllKitGfJMpYPQhxLqiqUKkb7R4&#xA;q8984/l15r/JzzNP+YP5axNd+WZjy8w+WBXikIqzMgFf3a7lSByj90qMVehf8476tZ635O1fXrON&#xA;ooNZ8watqCJJTmFuLkugehI5BKA0xV57p/lvSfMH/OXnney1P6x6CaPbzJ9VurmyfmsGnKKyWskL&#xA;kUY/CWp3psMVe6+U/LmkeW0vdK064llV5hfGK5nluZo1nURqGlneSRlLQNxLH27Yq8e/5yO/8mn+&#xA;S/8A23D/ANRen4q+gMVdirsVdirsVdirsVfOv/OGn/ksNU/7bc//AFCWuYeo+pux8ntWreX9C1hE&#xA;TVtOttQWLl6X1mFJeHOnLhzB41oOmQx5pw+kke5M8UZ/UAUFq3mDyp5P0+zhv7iLTLI0t7KMIxUB&#xA;F+yqxq1AB36ZTlzC7kdy5ek0OTN6cUb4Q+XvzM13S9c866lqGmRJHZO4SOSMcfWKDi0xG28h36dO&#xA;u+arLIGRIfRey9PPDp4xmfV93l8EHoGmqVF5KtTX9yD2p+1/TJ4odXS9vdpkHwYH+t+r9f8AanuZ&#xA;DyTEPzS/5RKX/jNF/wASzJ0f1teb6X2H+Vf/AJLDyh/2xNO/6hI82zhlb51/K3yR52EK+aLGXUYr&#xA;ducMBvLyGJXpx5CKGaNOVO9MVTHy15Q0Ly1p0em6MlxBYQp6UFvJd3VwkaDosYnll4AduOKoTRfy&#xA;68p6Lr1/r2m29xDq2qFG1G4a9vZfXMYIT1ElmeNuAYhart2xVPNS03T9TsJ9P1G3ju7G6QxXFtMo&#xA;eN0bYqynYjFWtK0yx0rTLPS9Pi9CwsII7W0hBZgkMKBI1qxZjxVQNzXFWO+avys8j+a9VstV16xm&#xA;u7/TW9TT5heXkIgcFTyiSGaNENY1NQOoxVlFvAkEKQoXKIKAyO8jfS7lmP0nFWDXn5Gflnd69P5g&#xA;n066Ot3NPW1FNT1KOZqKEHxpcqacVAxVO9F8g+WdFsr6z02K5ij1Fle8le+vZZ3ZAFWlxLM8y0Ap&#xA;RXGKqPkr8s/JfkmGWDyxZSafbzuZZbf63dzRNIVCl/TmlkTlxUCtMVWXX5XeRbjzT/ir9Gm28wkF&#xA;ZNRs7i5s5JAQAfVFtJEslaCvMHFVWb8ufKU3mtfNklvcnzAkRt0vhfXqlYCxcxCMTCMR8mJ4caYq&#xA;yUgEUO4PUYql2g+W9D8v2cllotlHYWck0lw1vCCsYklNXKrWignstBirFLz8jPyzu9en8wT6ddHW&#xA;7mnraimp6lHM1FCD40uVNOKgYqyLyx5N8v8AllLpNHhmjN66y3Ulxc3N5I7KvFayXUkz0A7A0xVL&#xA;vNX5WeR/Neq2Wq69YzXd/prepp8wvLyEQOCp5RJDNGiGsamoHUYqyi3gSCFIULlEFAZHeRvpdyzH&#xA;6TiqpirsVdirsVdirsVfOv8Azhp/5LDVP+23P/1CWuYeo+pux8nvOY7Y8/8Azo8q6Nq/lK61O/eW&#xA;O40aCaayeJqLzYCiupqCGZVB75j6mAMbPR3XYeryYs4hGqmQC+XIYmlmjiX7UjBR82NM1z3+XIIR&#xA;MjyAtmqIqIqIKKoCqPADYZmgU+X5MhnIyPMm12Fghvzc8i6jZ/lNJ5hvHEKS3FsLe1pV2SRtnY1+&#xA;HboMy9JH1W1ZTs+nfyr/APJYeUP+2Jp3/UJHm0cQph5t84eXfKWjSaxr94tnZIwRWILvJI32Y441&#xA;DO7t2Cj8MVYZqX57aRpCQXOs+V/Mel6ZcOkUep3ViiwBpCAgfjM0sfIttzQYq9MxV2KuxV2KuxV2&#xA;KuxV2KuxV2KuxV2KuxV2KuxV2KuxV2KuxV2KuxV2KvnX/nDT/wAlhqn/AG25/wDqEtcw9R9Tdj5P&#xA;ecx2x4p+e3lfzteTXGr2dy7eXLa1Q3NoJ2ChkY839H7J6jf2zC1MJXfR6z2f1eniBCQ/emWxr9Lw&#xA;yw/3utv+Mqf8SGYkeYen1wvBP+pL7mZZmvmTsVZ7/wA5N6hZ6h+Rn12zINtNc2bRhabDkfh27r0O&#xA;bDTm5Boyci9X/Kv/AMlh5Q/7Ymnf9QkeZ7jF43/zl1Lrmk3vkTzVBAbvSNC1Fp7m3IPpfWFeGWES&#xA;0rtIsLqK9PpxV6v5X84+R/zX8mXB06cXFleRGDULJqLc27Ov2ZENeLKd0bcGlQTiqF1P85dE0r8w&#xA;NN8j6ppGp2OpauwXTr6ZLX6lKDWhWVbhm+0OPHhyrTbcYqnfn7z3pvkrRYtWv7S7vo5rmGyhtbBY&#xA;pLiSa4PGNUjlkh5knspJ9sVa1vz9pOg6TZX2t29zY3WozJbWGjlY576a4k+zFHHbPOrN40eg7nFV&#xA;C2/MOI6rHp2p6DqujGaGa5hur2O2Nu0cCeo/7y3nuOLcd+D0b2xVj+t/njDofl6TzFq/kvzJZaPC&#xA;sby3M0OnrxEzrGnKP676gq7qKccVRNp+cf1rSrPWU8meYho97HDPFf8Ao2DRiC4CskzLHePIE4sG&#xA;Y8dh1xVW8+/nFpHknXNH0bUtG1S7u9flNvpDWS2jpPMGjTgPUuYmU8p0HxAdcVR+kfmFNfa7a6Pe&#xA;eV9a0aW9SV7e6v47P6uTCvJkL29zcEMR0FMVTTW/OGiaLrWiaPqEpiu/MEssGnGg4GSGP1CrGu3I&#xA;bLtudsVTvFUj8u+cdD8w3utWelymWTQb06ffNQcfXWNXbgQTUKX4GtPiU/MqobzF5/0XRdZtNBEV&#xA;zqfmC+jae30iwjEs/oKeLTSF2jiij5bcpHUE9MVVPLXnBNb1HUdNl0nUNH1DTEgkuLfUY4V5JcmV&#xA;Y3ikt5biKRawOCVfFWQ4q7FXYq7FXYq7FXYq7FXYq+df+cNP/JYap/225/8AqEtcw9R9Tdj5Pecx&#xA;2x51+eHmy/0HysLa2sUuYdZE1jPPIW4xCSOlAi05MyluPxbU6HMfUzMRXe7zsHRxzZrMqMKlXfu+&#xA;YCHR6EFXU7g7EEZrn0AgEeTMrO5W5to5l/bHxAdj3H35mRlYfNNbpjgyygenL3dFbJOIxj80NQvk&#xA;8i3Fis7izluIXe35HgWVtm49K++ZWj+trzfS+u/yr/8AJYeUP+2Jp3/UJHm1cMpxrekaHr2nXeh6&#xA;vbxX1lcxgXdlLQ1jcnixA+JfiQ8WHcbbjFXx/wCefJXmT/nHvz/p3mzy1cyXHli9mMSo7fEU+1JZ&#xA;XIFA1UFUf2rsVxV9Efnb+XUf5geRuWnEx6/ptNR8vXa1WRZlAb0ww+IeqAB7NxPbFWLfk35j1D83&#xA;LrTPOOsxenY+VIhaW9r+xNrTxA3N5xB+ykLqIlP2S7HFU7/Pv8vvN/mO20LzF5MuBH5o8p3El3YW&#xA;zlQswlCc1Bf4OX7paB/hIqD1xVA/lD+ek/mzXn8necdGOh+drBWlELIyxSlFIdo1kq8T8GJpUgrU&#xA;hqbYqmH/ADlH/wCSJ8zf9GP/AHULfFWVflQA35VeTlYVB0LTQQehH1OPFXkn/OTk89v+Y35Pz29u&#xA;95PFrEjw2kbIjyut1YFY1aRkQFzsCzAeJxV61onm/wAwahr0Ol6n5SvdFR4JrlLy6uLKaP8AcsiF&#xA;V+qzXB5H1h1ptirxr/nJzRvMHmLzXZRaFM8eoeTNDm8ywrGKuXN7DH8BrXmEt3kX4TulO+Ks6i/O&#xA;car+TVj5q0dFk8x6z6el6fp43/3MzH0fTof2Uesu/wDusVxVhn/OMdldeWPP/wCYvkq8uWu5rOe3&#xA;uVuXJ5SGsgkkIPd/UQ4qmv5xeUPzP0Pz/b/mj+XcS6ldrZDT9X0dl9RpIUfn8EYKtIrUWqoeYK1F&#xA;a7Ksv/Jv839H/MewvZVsW0rzDphSDWNOloXQ1fgVchWZOQfZgCpqCO5VejYq7FXYq7FXYq7FXYq7&#xA;FXYq+df+cNP/ACWGqf8Abbn/AOoS1zD1H1N2Pk95zHbGiqkgkAlTUHwNKfxxS+UPzkutEufzA1KT&#xA;SkdOLCO+5rwU3UfwylFNDTYVr1apzV5iOI0+jdiQyR00RP4f1ejGNK1RrOQq9Wgf7Sjsf5hkYTpe&#xA;1ezBqY2Nsg5H9BZRDNFNGJImDoejDMoEF4TNgnilwzFFif5pf8olL/xmi/4lmVo/rcXN9L7D/Kv/&#xA;AMlh5Q/7Ymnf9QkebZwykHm1PzQ0f8w18xeWdIh8w6BeaZBYajpf1uO0uVnt7i4lSaJp6RfZuaHf&#xA;f2oDirH/ADj5I89/mxe6Rp3mfSI/K/k3TLpb+8tXuoru/u5kVkRF+r8ook4uwJ5k71xV7DdzSW1o&#xA;8kFs908Y/d2sJjV27UUytGg+lhirx7/nGDyX5z8keT7/AEHzPo0thcz6lLexTie0miMb28MYH7ma&#xA;R+XKE/s4qzXzNqX5haV5piutG0L/ABB5euLRIrq2huoLa5guY5Xb1Y1uWjidWRwGHMHb23VY/pvk&#xA;zzH5j/NnTvzB1/SU0CDQbGSz0ywaaK4vJpZxIjyTvbs8KIkcrBUDtua1xVGf85AeXvMnmb8r9V8u&#xA;eXtNk1HUtSNuIwstvCiCC6hnYu08kXVYzTjXFU9/LC11iw8haBpGr6bLpt/pWnWllcRyyW8oaS3h&#xA;WJijQSSgiqV3p1xV5z+fXlHz/r/nbyHq/lny9JqsHlO+a/umN1Z26y1mtZljT1plf/j3YElcVZ/p&#xA;3mfz3qGr6fay+TrrRtPeR21HULy70+ZUjWJyqpHbXE0jM8vBelAN8VSnyzpHmVvzd8z+YNU0S4tN&#xA;Jv7KxsNKuZJbSRSluJHnMkcVxI68pHAX4DXvTFWOflr+Q0vlP8ytZ1R5eflS3ma78q6dyDJFc3iB&#xA;LiUx/stCiekh7qcVdZ+TPO2hf85H635ztNElvfK+uWEdrNPBPaKVlWKD4/Rlmhf7dvStD9onFWXX&#xA;ut/mbpHmnWI4/K7+YfLtzJFNpNzZ3tpDNCBbRRywyxXckAoZkd1Kt3xVB/lr5C1ew84eavPWu28O&#xA;nap5nkhWLSbdxKttb26BAZJFCq8spHJ+OwPc1xV6RirsVdirsVdirsVdirsVdir51/5w0/8AJYap&#xA;/wBtuf8A6hLXMPUfU3Y+T3nMdsQGoa9omnT29vf30FrcXTrHbQyyKryO7cVCKTU1O2WwwzkCYgkB&#xA;hLJGJomrQd15K8p3eoXWo3WlW897ex+jczyIGZkC8e+wPHao3zGOKJNkOdDXZoxEYzIjE2Hyf5k0&#xA;uzj81alp2hRTzWkFxLHbRspaXhETy2ArQUPUVp1zWGO5p9G0+c+DGWUgSIHuspTBc3Fu/OFzG3en&#xA;eniO+AGm7Pp8eWNTAkEr896vd3Plp4JuLD1IzzpRtj7Gn4ZsNBMnJReT7d7Jw4cByQsGx12/Hxfb&#xA;v5V/+Sw8of8AbE07/qEjzePFFlOKuxV2KuxV2KuxV2KuxV2KuxV2KuxV2KuxV2KuxV2KuxV2KuxV&#xA;2KuxV2KuxV86/wDOGn/ksNU/7bc//UJa5h6j6m7Hye85jtj5B/OE2S/mVrEun3KTwvKkglicOFkM&#xA;amReQJ3WSvyztuzb8CIkKeW19eMSCzGx/wCcmfMNvaWsM+k29zJDGqTztI6tKyinPYUUnqeuYM+w&#xA;4EkiRDlR7XkALDBvzG8+t5y1tNSXT49NVIkQxxkO7utfjkkCoXO9FqNhmZoezoaeyN5Hr+hp1naW&#xA;TOBAkiEeUb2vvZjpf5M+bNeg8vanNJHLYX8UL3tz6oNwkUjGQu4YDkwjYKtGY9K0zi+1cHFqZcIA&#xA;jfT7ftfRewO2oYNCIzMjkAJF7+4Wln/ORn5QaL5T8irq+k3F1KGvIYJobgo6qrh25hkRKfEoXfxy&#xA;OlwCGQENGt7ZyanBKExEcjt7w+kPyr/8lh5Q/wC2Jp3/AFCR5tnnCxj88Pzoi/LzTrSz061Gpeat&#xA;YPDSrA1KD4gvqyhSGK8moqjdjtUbnFXaF+WHnPUrGO988+dNYfV5xzmsNGuf0bZ25bf0k+rKkknD&#xA;pyL7+GKpJ5+/Lfz15b0afzB5N89a4X04fWbvTNUufr8UluhDS+m8ysyssYLDlyrSm2Kva8VdirsV&#xA;dirsVdirsVdirsVdirsVdirsVdirsVdirsVdirsVdirsVfHH5K/mFceTPyPvZrD021W98wzR2qyg&#xA;soSO0tGlYgUqKUXr+1lul0Yz5al9IH9jRqtUcWOx9RKa+aP+cgPNGu+XW0lLaLTZ5zS7vLV3BeKm&#xA;8aK1SnLueZ22za4Ox8eOfFfF3AutzdpznDhqnmkUApyfv0X+uYHavb/gyOPFRkOZ6D9r1Hs97HnU&#xA;wGbOTHGeURzkO/yH2nyVQqAEBVofYE/ed85qXbOqJvjP2Pcx9l+z4x4fCj9pPzu1jwIw+H4W/A5t&#xA;tB7RzEhHNvH+d1H4/FvOdsew+MxM9L6ZD+AmwfcTuD7yR7no/wCT/wCbcnlK4k0vWZJJNAkDsigF&#xA;3gmAJ+AdeLnYr47+Ob3tHs8ZwJwri+8PBaLWHCTCd19xX/n5+cXlzzh+Xt/pGm29zC8c1vOs1yEQ&#xA;OElClVVWc/t1zUz7MyYQJSI+Ds8WvhlJiL5Poj8q/wDyWHlD/tiad/1CR5BtL5u8+3Bv/wDnMzSL&#xA;bURW1srrTYrMP9mgt0uEpX/l4kP04q+usVaIBFDuD1GKvMPzU/MTW7LzT5d/L3yq6QeZvMzGR9Rk&#xA;QSrZWUfIyTLEdncrE/Hl8PwmuKprc/lSs9sKebPMkeohaDUE1OZfiofiNsKWp3PT0sVYX+Vv5k+d&#xA;NP8AzL1L8qfPk6alqVtGZ9F1xEETXMKp6gEqr8JJiPIECoKsGJ64qk/mP86/M/kT84/M41e3n1H8&#xA;vFudPtZpU+NtOnm0+CTkgFSEkqzFOjGpX4qgqvYvMF1puv8AkS91DTNQka0nsZrix1HTrmSFq+i/&#xA;F0lgZDsex79Rtirz6383eYPLf/OMsHm2ykn1PXhpNvdtPezS3bmacokkzGZnNIw5k49NsVVfI9jo&#xA;/nfybZavoHnbVbvzAkcMt7cDUp1CXNFd4LmwRhBGjMrLQRV4/ZJGKorzz588wal+Zenflf5Uuf0b&#xA;dzW5v9f1wIkstraAEiO3SQMnqybfEynjyFB4Kpxqn5TyT2kh07zd5isNVKn0b46lPOgfqC9rITbs&#xA;teoVF9qYqxj8kvzR806t5j1/8u/PHpyeafLvJhfwKI1urdHWMyFV4gNWRGBUCqsNgQaqsa0qz1HW&#xA;v+cmfN/k+58wa7F5fsNLjvLOzt9Xv4hHM8diSVZZq0rcOaHbfFU5/KrV/PVl+avnj8ur3WLjWtI0&#xA;i2juNN1i9P1ie3kuFjeGKSQ8WkJSY1qesZpSuKqX52eTpvJv5R6vrmkeZ/Mn6Y09bQRXk2tag9TL&#xA;dwwuzR+sI/iSRv2cVT3yT+Xh1n8v/LesnzL5ii1m+0ywv5Lg6zfyRtcSQRzNzheVozGzn4lp02FM&#xA;VY//AM5AX+sad+Zf5X22m6tqVha6/qv1XVra0vrqCKaFbmzjCmOORUX4ZnBKgVrirJv+cj5b3Sfy&#xA;d1fVdK1C+0/UdNFoLS6tby5hkAkvIYW5tHIvqVRyKvXFWUflR6z/AJa+WLu4uLi7u77S7K7urm6n&#xA;luJXmnto3kYvMztuxrQGmKsJsDej/nJi80U6lqLaPF5bXU49Oe/vGtxdC8ii9T0mlKH4CRxI4+2K&#xA;oX8/fzcvPIHm/wAivDK/6PknuZddtkJo9n+6hqyjqV9RnT/KXFXsFzrGmW2kSaxNcoumQ25u3u61&#xA;jECp6hkqP2eG+KvJf+cd/wAz9U8+XnnafUGkQQanHNY2cvW2tJ4jHDEFJ+Ha3JbsWJPc4qwz/nFD&#xA;QdH138oNY0/VrWO7tJNbn5RyDofqlrRlI3Vh2INcx55pY5iUTRZ+HGcakLDyTU7a1j1y9t7RWW0i&#xA;uJlgSQ1YRI7cQxHU8RnU6zUyxaaWT+IR+0/tdN2Xo46jWwxfwyn/ALEbn7GWflb5Oh82+bodPuiR&#xA;Ywo11ehTRmijKjgDsRyZ1Wo7Z5tihxy3fae1dZ+VwcUef0x/Hk+p7Py/oVlYiwtdPt4bMLxMCxIE&#xA;I/yhT4vpzZDHECqfPZ6nJKXFKRMu+3g357/l3pegyWuu6PCLazvZDBdWqCkaTcS6NGP2Q6q1V6Cm&#xA;2YOoxCO45PY+z/aU8wOOZuURYPk8buFHIMB1G/zGdr7O6g5NPwn+A18HgfbbRRw63ijyyR4vjyP3&#xA;X8WX/mR+VFlon5Kx+a57trnUL9rKW3iQcIoormj0Nfid+JG+w9u+U63tE5JnEBUQfudfo9EIR8Qm&#xA;yR976m/Kv/yWHlD/ALYmnf8AUJHmI5heIf8AOUv5ZeY013TfzQ8qxPNeaV6LalHEC0kbWr+pBdKg&#xA;3YL0enQAHpUhV6z+U/5y+VPzE0aGayuY7fW1QfX9HdwJo5AKsUU0Mkfg4+mhxVkHnfzlpXlPQZtT&#xA;vpYxMR6en2jtxe5uX+GKGMAMxLuQDQGg3O2KvEvzwFx5K/PPyX+Z1xE7+XkjGm6jOoLiAsJomYge&#xA;MNyWXxKnFX0LZXtnfWkV5ZTx3NpOokguIWDxujbhlZSQQfbFXhOlab/i7/nKm58z6YPV0XyhYfUr&#xA;m/XeKS9khkiMKMNmZBcNy8OPyqqyDyhp+leY/wAx/wA4NK1W2S5sLubSra6tX3DINP8ATrtQgnhU&#xA;Ebg9DUYq811yw83/AJAz6nBbLNrX5Va6ssSrXlNp886FVrWgBqaV+zIPBsVe0/l3e6Lp/wCVHkSz&#xA;1Dgtvq+l6dZRxygGOSW4sRIY2DbH1OLCncmmKvHPze/Ke0/K7U9L8/8A5cXMumajLqMFmdAVyYrl&#xA;rhifSiqeXF+NGiNVp0pTFUx84T/8q9/5yis/OOsAxeWvNdqti+pN/dQyiFIOLtSi0aCNmr+yxPY4&#xA;q+jY54ZIVnjkV4HUOkqkFSpFQwYbUp3xV4P+VWlN5k/5yB88fmNZrXy6iLpOn3Y/u7meKOCGV4mG&#xA;zov1U7jb4hiqS2Wk6vqn/OXXniDStauNBuk0eCT65bRW87Mog05fTZLqOZOJLBthXbriqffkj5qf&#xA;yz5r1v8ALfzoEg85zXcl7DrT1H6YSUkpJzcmrhBRFFBxHEAFWxVkX/OUf/kifM3/AEY/91C3xVlX&#xA;5T/+Ss8m/wDbD03/AKhI8VeVf85Hf+TT/Jf/ALbh/wCovT8VZv8A85HaVeap+Snmi1s4zLOsENxw&#xA;UEnha3MVxIaDwSJjiqY/kjrFhqv5S+U57KVZUt9LtbObiQSs1rCsEqNToQ6HFWN+Xok1T/nJTzLr&#xA;Fk/rWej6Bb6PeSrui3c1wtx6XIbFkSP4h2OxxVCeavK+n+f/AM1vNXl6+/3ktPKtvp4f7XpXF7dt&#xA;dJMFr9pTbxMNv2cVYD+WeqeavNGi235IazBLDcaBfNH5mujXidFs3V47cPt8U0pWJaf7qFcVZL+W&#xA;PDRP+coPzD0FVEUOo2kOoQqo4oSBDJRen/LU3TwOKsC/5x7/ADR0byR+VF8LqGW71C61m5a0tYxx&#xA;Vgtpagl5SOKip7VPtksWglnnsaiObVm1kcMd9yWBTXZn1Ca6ICGeR3I6hfUJr91c6DXabxNPLGOf&#xA;Dt7xydZ2TrRg1mPMeQnv7jz+xmf5V+cYPKfm+HULsH6jPG1relRVljkKtyA/yXRSfbPNcU+CVvtf&#xA;a2jOpwGMfq5j8e59U2etaPe2Iv7S9gmsqBvrKSKYwD4tWg+nNkJgi7fO54JxlwyiRLup4D+fP5ga&#xA;ZrtxaaJpE4ubSwdpbq4jNYnmI4qEYbMEUt8Q23zB1GUSNDkHs/Z/s6eEHJMVKXIda/a8duGqwUGo&#xA;A3HgTna+zmnMNPxH+M38HgvbbWxzazgibGOPCf63M/oHves/m/5m0DV/+cb7S10y8WebTjpltdQH&#xA;4ZY3iURnkh3oSux6HNbqcE4ZyZD6iSGjTZYSxARPIB75+Vf/AJLDyh/2xNO/6hI8LIspxVg+v/kl&#xA;+VOvXbXupeWrRrx25vc2/O0lZ615F7ZomLe9a4qoaR+Q35S6TqUGp2nl6Nr+2dZbe4uZ7m7ZHQhk&#xA;ZfrMsoBUio8MVZvf6fYajZzWOoW0V3ZXC8J7adFkjdT2ZGBUj54qwy1/JD8s7MsLPS5bWByS9pBf&#xA;X8Vq1a15WyTrCRv0KYqy7StG0nSNOi03SrSKwsIV4xW1sgiRR7BKUPviqT6L+XXlPRdev9e023uI&#xA;dW1Qo2o3DXt7L65jBCeokszxtwDELVdu2Kp5qWm6fqdhPp+o28d3Y3SGK4tplDxujbFWU7EYqk+p&#xA;+QPJ+qeV7XytqGmR3Og2McMVnZOzkRLbJ6cPF+XqAouwblX3xVB6P+VPkTSdSt9TttPkmv7Ov1O4&#xA;vru7v2gqKfufrcs/pmn8tMVT/WtD0bXNOl03WLKHULCYUltrhFkQ+BowO47HqMVYnbfkj+WltEbe&#xA;HS5VsmrXTzfX7WdD1H1VpzBT24YqzOysrKxtYrOyt47W0gUJDbwoscaKOiqigKo+WKsXsvyo8jWX&#xA;mqfzZbWdxH5iul4XOo/X79pJEAUcHDTlWWka7EU2GKovzf8Alz5L84NaP5h0xLyexYPZ3SvLBcRM&#xA;CG/dzwPFKvxAGgbrirfmL8v/ACt5k0BdA1yC4vtJWnK3kvbwF+Lh19WRZhJLxZQRzY0xVHeXPLOj&#xA;+XNMh0vSI5YbC3RYreCW4uLgRxpsqoZ5JSoAPQYqlPmn8rfJHmnVrHV9dsprvUNMcSafMLy8hEDg&#xA;q3KJIZo0U1jU1A6jFWTRW0UVuLccniA40lZpWIP8zSFmb6TirCh+SP5ZJczXNrpD6e9weU8en3l7&#xA;YxOf8qG1mhiP/A4qyjy/5c0Ly7pqaZodjDp9ihLCCBQoLN9p2PVmPdjviqA0nyH5Z0nX77X7GG4T&#xA;VtT9P9IXEl7eTCb0UKRc45ZnjPpqxC/Dt2xVMLPy/otlq+oaxa2ccOp6qIRqN2oo8wt1KRcz/kKa&#xA;DFUmvPyw8k3fm7/GEljKnmQoIjqMF3d27lAnphSsMsaEcRTdcVfOX/OO/wCXGled/wApJ7e+mktm&#xA;svMFzJHPCFL8XsrUOnxVA5UU/Rjj1stPMkC7DDLpY5ogHoU9/M/8hodE0RNU8r/WLtLQMdRgmZZJ&#xA;TH19VOCp9n9oAdN+xzZ6Dtc5J8OShfL9TrtZ2aIR4oWa5vHIphTi/wBDf1zF7V7A8WRyYtpHmO/3&#xA;eb0vs97Yfl4DDqAZYx9MhzA7j3j7R5qoZCvLktPmK/d1znD2Nqga4D9n38nuI+1HZ5jxeLH7b+VW&#xA;sedR9j4j49vxzcdn+zkuISz7D+b+s/qeX7Z9uIcJhpbMj/Gdq9w5376rzZn+Xv5ReYPOkFzeRyCw&#xA;sYgRDdzozLNNX7C0INB+029OmdDq+0MenqNWe4dA8Dp9HPPcifiepQv5oflBrHlD8vdZ1PWJYZJP&#xA;XtLayNuxdGV5eUjnkEYEcFA27nNZrO0o5hGML7zbsdJoZYiZS+D6p/Kv/wAlh5Q/7Ymnf9QkeYbm&#xA;FlOKuxV2KuxV2KuxV2KuxV2KuxV2KuxV2KuxV2KuxV2KuxV2KuxV2KuxV2KuxV86/wDOGn/ksNU/&#xA;7bc//UJa5h6j6m7Hye63Mxht5ZgjSmNGcRoKs3EV4qO5PbKYizTMmg+NNH8sa75q85nSVga31C7u&#xA;He8EiFfQBYtK7qeJASvT6O+dzlzww4uK7iBt5vJwwyy5OHkSfk9Lk/5xf1YT0j16BoN/jaB1f2+A&#xA;Mw/4bNUO3o19Jv3uw/kc/wA77Hk+q6PdeW/M8um6nCJJdOuAs0RFVkRWDAivVZEoR7HNxjyDLj4o&#xA;/wAQdZPGcc6l0L7Wso7SO0hSzRI7RUUW8cahECU+EKoAAFM4ORNm+b18QK25PIf+csv/ACT91/zG&#xA;2v8AxM5Zg+pE+T0z8q//ACWHlD/tiad/1CR5nOOWU4q7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FX&#xA;Yq7FXYq7FXYq7FXYq7FXYq7FXyD5H/Lj/nLDyRpMuk+XLW1tbGedrqSN5dPlJldEjLcpGY/ZiXbK&#xA;5YxI7s4ypkX1b/nNfws/v0vI+BHuZcZUv0Z/zmb9Z+tehYfWuHp+vx0r1OFa8OXXjXemHwhVb0ji&#xA;3vZV+rf85r+Fn9+l4PAj3J4yl0nlT/nLmXVv0vLp2lyaoEWMXjx6S0oVCStGIqKV6jLBYjw2eHut&#xA;rIjxcVC0x+rf85r+Fn9+l5X4Ee5s4ykfnHyH/wA5becdEfRdftrW5055ElaJZNOiPOM1U8oyrYY4&#xA;gDYQZW+m/IelXuj+R/Luk3yhL3TtMs7S6RSGCywW6RuAw2NGU7jLWsp7irsVdirsVdirsVdirsVd&#xA;irsVdirsVdirsVdirsVdirsVdirsVdirsVdirsVf/9k=</xapGImg:image>
+    </rdf:li>
+   </rdf:Alt>
+  </xap:Thumbnails>
+ </rdf:Description>
+
+ <rdf:Description rdf:about='uuid:8aa76b3d-2474-11d9-a8a3-000393cd9a96'
+  xmlns:xapMM='http://ns.adobe.com/xap/1.0/mm/'>
+  <xapMM:DocumentID>uuid:c63b31d6-45fe-11d8-8e7c-000393cd9a96</xapMM:DocumentID>
+ </rdf:Description>
+
+ <rdf:Description rdf:about='uuid:8aa76b3d-2474-11d9-a8a3-000393cd9a96'
+  xmlns:dc='http://purl.org/dc/elements/1.1/'>
+  <dc:format>application/postscript</dc:format>
+ </rdf:Description>
+
+</rdf:RDF>
+</x:xmpmeta>
+                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                <?xpacket end='w'?>
+%  &&end XMP packet marker&&
+[{ai_metadata_stream_123}
+<</Type /Metadata /Subtype /XML>>
+/PUT AI11_PDFMark5
+[/Document
+1 dict begin /Metadata {ai_metadata_stream_123} def
+currentdict end /BDC AI11_PDFMark5
+Adobe_AGM_Utils begin
+Adobe_AGM_Core/page_setup get exec
+Adobe_CoolType_Core/page_setup get exec
+Adobe_AGM_Image/page_setup get exec
+%%EndPageSetup
+Adobe_AGM_Core/AGMCORE_save save ddf
+1 -1 scale 0 -148.752 translate
+[1 0 0 1 0 0 ]  concat
+% page clip
+gsave
+newpath
+gsave % PSGState
+0 0 mo
+0 148.752 li
+254.868 148.752 li
+254.868 0 li
+clp
+[1 0 0 1 0 0 ] concat
+54.9161 147.252 mo
+1.5 147.252 li
+1.5 1.5 li
+54.9161 1.5 li
+54.9161 147.252 li
+false sop
+/0
+<<
+/Name (PANTONE 7506 C)
+/0
+[/DeviceCMYK] add_csa
+/CSA /0
+/TintMethod /Subtractive
+/TintProc null
+/MappedCSA null
+/NComponents 4
+/Components [ 0 0.05 0.15 0 ]
+>>
+add_csd
+1 /0 get_csd
+sepcs
+1 sep
+f
+7.82032 17.3956 mo
+12.9034 12.8946 20.6797 13.3624 25.1856 18.4405 cv
+29.4395 23.2481 29.1768 31.1573 24.5225 35.4014 cv
+19.4395 39.9131 11.2784 39.8477 6.76954 34.7637 cv
+2.26661 29.6758 2.73926 21.9004 7.82032 17.3956 cv
+cp
+11.7549 43.3096 mo
+12.2579 48.5938 li
+16.7979 48.8663 li
+17.9268 43.7178 li
+20.3682 43.4747 22.7608 42.7344 24.8936 41.4756 cv
+28.8946 44.7803 li
+32.2999 41.7657 li
+29.4512 37.3243 li
+30.8975 35.3721 31.9356 33.1631 32.5196 30.8428 cv
+37.9678 30.3233 li
+38.2413 25.7842 li
+33.0137 24.6417 li
+32.794 22.21 32.0909 19.837 30.8458 17.6924 cv
+34.1573 13.6866 li
+31.1416 10.2813 li
+26.8135 13.0518 li
+24.8252 11.46 22.5674 10.3506 20.1846 9.75684 cv
+19.6973 4.61329 li
+15.1592 4.34083 li
+14.0616 9.35645 li
+11.6202 9.62598 9.22754 10.4092 7.04786 11.7168 cv
+3.06153 8.42383 li
+2 9.36426 li
+2 15.0967 li
+2.42969 15.7667 li
+2.27442 15.96 2.14551 16.167 2 16.3663 cv
+2 42.168 li
+5.16114 40.1416 li
+7.12208 41.6631 9.37012 42.7315 11.7549 43.3096 cv
+/1
+<<
+/Name (PANTONE 301 C)
+/CSA /0
+/TintMethod /Subtractive
+/TintProc null
+/MappedCSA null
+/NComponents 4
+/Components [ 1 0.45 0 0.18 ]
+>>
+add_csd
+1 /1 get_csd
+sepcs
+1 sep
+f
+19.8682 23.167 mo
+21.6221 25.1495 21.9336 28.1055 19.6426 30.2452 cv
+17.7315 32.5264 13.9385 32.1124 12.1084 30.046 cv
+10.2051 27.9034 10.4053 24.626 12.5489 22.7256 cv
+14.6924 20.8213 17.9698 21.0293 19.8682 23.167 cv
+cp
+24.5225 35.4014 mo
+29.1768 31.1573 29.4395 23.2481 25.1856 18.4405 cv
+20.6797 13.3624 12.9034 12.8946 7.82032 17.3956 cv
+2.73926 21.9004 2.26661 29.6758 6.76954 34.7637 cv
+11.2784 39.8477 19.4395 39.9131 24.5225 35.4014 cv
+/2
+<<
+/Name (PANTONE 871 C)
+/CSA /0
+/TintMethod /Subtractive
+/TintProc null
+/MappedCSA null
+/NComponents 4
+/Components [ 0.3569 0.3608 0.6353 0.1882 ]
+>>
+add_csd
+1 /2 get_csd
+sepcs
+1 sep
+f
+42.0054 124.904 mo
+38.6949 132.106 29.9537 135.87 22.7505 132.561 cv
+15.5523 129.245 12.4058 120.72 15.7144 113.527 cv
+19.0259 106.334 27.5503 103.179 34.7427 106.488 cv
+41.5435 109.62 44.98 118.187 42.0054 124.904 cv
+cp
+52.1324 108.189 mo
+46.0132 109.425 li
+44.6382 106.935 42.775 104.731 40.4371 103.029 cv
+42.0914 97.1954 li
+37.271 94.9756 li
+33.9527 99.9629 li
+31.0816 99.1973 28.1519 99.0762 25.3277 99.5635 cv
+22.3921 94.2989 li
+17.4175 96.1416 li
+18.6011 102.011 li
+16.1207 103.443 13.9351 105.404 12.2232 107.825 cv
+6.41944 106.179 li
+4.2046 111.001 li
+9.19288 114.318 li
+8.42237 117.192 8.30616 120.126 8.78467 122.94 cv
+3.52295 125.882 li
+5.36475 130.86 li
+11.2349 129.672 li
+12.6656 132.151 14.6226 134.34 17.0562 136.049 cv
+15.4068 141.854 li
+20.23 144.069 li
+23.5582 139.057 li
+26.3648 139.764 29.271 139.844 32.0865 139.344 cv
+35.1089 144.747 li
+40.0816 142.907 li
+38.8687 136.883 li
+41.3609 135.473 43.5679 133.563 45.2554 131.213 cv
+51.0806 132.864 li
+53.2984 128.045 li
+48.1685 124.64 li
+48.7964 121.878 48.8687 119.031 48.4048 116.281 cv
+53.9722 113.169 li
+52.1324 108.189 li
+1 /1 get_csd
+sepcs
+1 sep
+f
+25.3804 126.851 mo
+21.3306 124.99 19.5601 120.199 21.4234 116.152 cv
+23.2847 112.103 28.0757 110.342 32.1226 112.198 cv
+35.8609 113.921 38.1509 117.934 36.23 122.414 cv
+34.9371 126.865 29.2769 128.645 25.3804 126.851 cv
+cp
+34.7427 106.488 mo
+27.5503 103.179 19.0259 106.334 15.7144 113.527 cv
+12.4058 120.72 15.5523 129.245 22.7505 132.561 cv
+29.9537 135.87 38.6949 132.106 42.0054 124.904 cv
+44.98 118.187 41.5435 109.62 34.7427 106.488 cv
+/3
+<<
+/Name (PANTONE 1805 C)
+/CSA /0
+/TintMethod /Subtractive
+/TintProc null
+/MappedCSA null
+/NComponents 4
+/Components [ 0 0.91 1 0.23 ]
+>>
+add_csd
+1 /3 get_csd
+sepcs
+1 sep
+f
+51.919 34.2159 mo
+50.1553 34.3702 48.4336 34.6612 46.7647 35.085 cv
+45.0293 31.7598 li
+41.462 32.9639 li
+42.0958 36.6563 li
+40.4815 37.3428 38.9317 38.1573 37.4639 39.085 cv
+34.7881 36.46 li
+31.7666 38.7081 li
+33.5157 42.0323 li
+32.1993 43.1778 30.9776 44.4268 29.8624 45.7686 cv
+26.5 44.0938 li
+24.3194 47.1651 li
+27.0049 49.7813 li
+26.1094 51.2696 25.3331 52.837 24.6817 54.4659 cv
+20.9756 53.917 li
+19.8526 57.5108 li
+23.2159 59.169 li
+22.8292 60.8477 22.5831 62.5772 22.4659 64.3418 cv
+18.7579 64.9659 li
+18.7999 68.7315 li
+22.5225 69.2696 li
+22.6778 71.0323 22.9639 72.7549 23.3868 74.4249 cv
+20.0635 76.1573 li
+21.2667 79.7266 li
+24.959 79.0928 li
+25.6456 80.709 26.46 82.2569 27.3887 83.7256 cv
+24.7627 86.4004 li
+27.0127 89.4219 li
+30.336 87.6729 li
+31.4795 88.9883 32.7305 90.21 34.0713 91.3243 cv
+32.3975 94.6895 li
+35.4698 96.8663 li
+38.085 94.1827 li
+39.5743 95.0782 41.1387 95.8555 42.7725 96.5069 cv
+42.2208 100.211 li
+45.8155 101.335 li
+47.4737 97.9708 li
+49.1524 98.3584 50.8799 98.6104 52.6456 98.7227 cv
+53.2696 102.43 li
+54.8282 102.401 li
+54.8282 90.2071 li
+50.5508 90.4063 47.168 89.4581 43.1543 87.2188 cv
+31.6788 80.8194 27.5655 66.3292 33.9717 54.8516 cv
+38.3282 47.044 45.9112 42.2872 54.8282 42.667 cv
+54.8282 30.4581 li
+52.4581 30.4971 li
+51.919 34.2159 li
+1 /3 get_csd
+sepcs
+1 sep
+f
+33.9717 54.8516 mo
+27.5655 66.3292 31.6788 80.8194 43.1543 87.2188 cv
+47.168 89.4581 50.5508 90.4063 54.8282 90.2071 cv
+54.8282 73.5127 li
+54.4903 73.5616 55.1485 73.5948 54.7969 73.5948 cv
+50.8213 73.5948 47.5987 70.3731 47.5987 66.3975 cv
+47.5987 62.419 50.8213 59.1944 54.7969 59.1944 cv
+55.1485 59.1944 54.4903 59.2286 54.8282 59.2764 cv
+54.8282 42.667 li
+45.9112 42.2872 38.3282 47.044 33.9717 54.8516 cv
+1 /2 get_csd
+sepcs
+1 sep
+f
+3 lw
+0 lc
+0 lj
+4 ml
+[] 0 dsh
+true sadj
+54.9161 147.252 mo
+1.5 147.252 li
+1.5 1.5 li
+54.9161 1.5 li
+54.9161 147.252 li
+cp
+0.99 0.99 0.99 1 cmyk
+@
+0 0 0 1 cmyk
+%ADOBeginSubsetFont: TrajanPro-Bold Initial
+%ADOt1write: (1.0.21)
+13 dict dup begin
+/FontType 1 def
+/FontName /TrajanPro-Bold def
+/FontInfo 7 dict dup begin
+/Notice (Copyright 2000 Adobe Systems Incorporated. All Rights Reserved.Trajan is either a registered trademark or a trademark of Adobe Systems Incorporated in the United States and/or other countries.) def
+/Weight (Bold) def
+/ItalicAngle 0 def
+/FSType 8 def
+end def
+/PaintType 0 def
+/FontMatrix [0.001 0 0 0.001 0 0] def
+/Encoding 256 array
+0 1 255 {1 index exch /.notdef put} for
+dup 67 /C put
+dup 73 /I put
+dup 83 /S put
+dup 127 /Nsmall put
+dup 128 /Tsmall put
+dup 129 /Esmall put
+dup 130 /Rsmall put
+dup 131 /Ysmall put
+dup 132 /Ssmall put
+dup 133 /Msmall put
+dup 134 /Osmall put
+dup 135 /Ismall put
+dup 136 /Usmall put
+def
+/UniqueID 45714 def
+/FontBBox {-248 -284 1528 985} def
+end
+systemdict begin
+dup /Private
+15 dict dup begin
+/|- {def} def
+/| {put} def
+/BlueValues [-17 0 750 775 638 660] def
+/OtherBlues [301 305 405 408 -261 -256 -222 -209] def
+/FamilyBlues [-17 0 750 767 638 656] def
+/FamilyOtherBlues [301 305 405 408 -273 -255 -214 -209 -252 -239] def
+/StdHW [47] def
+/StdVW [118] def
+/StemSnapH [47 55] def
+/StemSnapV [118 126] def
+/ForceBold true def
+/password 5839 def
+/MinFeature {16 16} def
+/OtherSubrs[{}{}{}{systemdict/internaldict known not{pop 3}{1183615869
+systemdict/internaldict get exec dup/startlock known{/startlock get exec}{dup
+/strtlck known{/strtlck get exec}{pop 3}ifelse}ifelse}ifelse}executeonly]def
+/Subrs 5 array
+dup 0 <1C60D8A8CC31FE2BF6E07AA3E541E2> |
+dup 1 <1C60D8A8C9C3D06D9E> |
+dup 2 <1C60D8A8C9C202D79A> |
+dup 3 <1C60D8A849> |
+dup 4 <1C60D8A8CC3674F41144B13B77> |
+def
+put
+dup /CharStrings
+14 dict dup begin
+/C <1C60D8A8C9B6D5A0DEDEC57B918D61DDFA401F5A49FEA3B89C6864173301
+6BDC674395116B42D2387AF24DF2F1DC60C61A5B6585CC0DA86F050A110B506B
+B65171C092F0636620BAA275DBDEA04B3E655EC58BDFB8B9B535650BF4DE0E82
+1C2ADFD8C9F649E0C395722C228833505318AA21D61F3D55D035246FCF9BC983
+692D83F8C9AF492468B91F4CB872C7D1953185BF38A8E7A5B72C7F51E36572D3
+718D9C26EEF5DDFAB02F3E79248875F4CA6CC06F7C289C017B388B2CFE4B85A5
+1B0090> |-
+/I <1C60D8A8C9B77771C05B04C6A1CDBDED73825D1016AD1A9F739BE3AE28A3
+2F89A16FA0ADB365C478020BF11BB9ADC332932373DC2832A2FD54E961E2B084
+4B0EB81447C317CA2A36F9297140F653C6CF38B651D9BF313FA9254650245A3A
+6E604D8E9EFFEAAF12423E3B4CFD19A9AFAFF5FC58BD3FF4189B6F8AF938C510
+BD91FB49103F7E5C2AE8440096A8B2CFB59E1B448BD934D6C96663C7ECAD3789
+1B4FEEBF9172B6A7CCC0965D9AA12297E39BBF30EB7B8F6243DD70D9185FBD81
+8CFC74B60F41E69C4533165A53D5C2FC5A9B44BA5F12F31CB79A71FA4F70F551
+E84E63E5837361F7B7736F91> |-
+/S <1C60D8A8C9B7F51B95A0DFD92CF0B9552EA2D8DB80CD668D35E3A70F4576
+D4238E8EEA2F046EF8BC16C7785D1607E04A62100A5AFF084F37B544AFC2004C
+0BC4AE1356D2B0EC8700AB99117F620401AEDDDFA69D53F0F4E5314303A9C779
+D85053ADE7DEA169C445735EBAC333F65F31A077498B479248885315A58C9DAE
+7AD6ABA3F9562E1A36EA3EA3274E191D557F04A6CB9FA3B240660C95B31FD1EC
+ACE3874E2F240022DE09CA2256274ED580EE94FBAA5793BD5F9D37682BE7C541
+ACC5EE4D95FB35149493D2CCA9BEA729ABD0DCEC9C95E902EA9DD124CA919CBA
+F3364C7699DDBE268B46D54393CC359D98EA67700B83CEF348489F1F90A16D> |-
+/Nsmall <1C60D8A8C9B6BC88BD85FE8659C453EEEB8E1BD03325A00213B3F3D
+4D450DC128DD37CC24C857B6D60D557A08CD43D812DF35B5BD6760576A63576C
+506A238602F1E6EA5D2CF18DAD28B193AFC0FA899C7F243B47EAB7B8460C0CB0
+4242476B1602C4D8E3342E27EB421C00D297126C6E43889F0137C7A1C441FC72
+2BE08EFEBABED7A59A7395971A284A820995BDAAE7D9478AB8745D9C9402C363
+B7514AFE9E3D0AF6A39663E1D555B5F7BDA2CE94F32DDC1E19216692DC849907
+7A3E6206E838004DD8DB4A986C8F31EDCAB6E6B82F722A0EF26221ADD2189144
+83D5E5F90B6CEB939F64EF523B4531C4C0B4ED4F521923EBA94C1FE7AE3B2648
+AB7B1D48BCD570F1DED35E03DBB412CF55B5989A09E378971DDF42BBC4FD1669
+7B92AE130992922E13408AB712F27D256F7305A6C6B07A0AD7C13FE23EFB63CE
+65111A1A787D3875B8B8D9507C694904CE3BA8114CCE10FF99A55> |-
+/Tsmall <1C60D8A8C9B66C0E1D18F4614EAB544F0CEC538C8C01A016933AA12
+429EBE5390D596C5F67CFF90C2108DEC0E3557EFE47A84AD0A504C83D7E8F287
+5DCBB9233950E37680119C5422B9BA74EB5E3A2AE4E2F090670CEE3CC015972E
+6CE8DF50DCD73A5ECEE824E6627364F3B83B1B73833AA7E396445D318F119C4C
+5EA2429D5B49B0EDBDDF4808A5790BF8CDC63B184CD3A9CE7C22C4D23ACC081C
+FF7BCA42342880880724EDF5A0F6F9059ADD736C441B65FC95D81D78B14BCAE7
+32E0959A4FEDBBA605D7DB559BC1CFFED39160EF11111F189C967E86115A679A
+21BB269B7452490D7C600719A2B02BE0A92DC8D7E101DFFE6011D579AD666FD2
+6352E7C3F88546D427880A3ED55A53668B9B911F227F478005846196CB2A821D
+9436A361DD997E24624546B193AD16A013BF60C83D456FEFAB524A4C3C4DAF51
+640204EE51B9A6B98D186E77DE45F4BD3696405A93E6DE14A3A251AC1EF6440B
+3F074B20C4913F3447DE56969C6BBDB2354148031166D8E9781263F94442062C
+991765ADD918972AAE466DE6B9C6E0991428CD75BCCEE> |-
+/Esmall <1C60D8A8C9B7FBE1B006E95A68A3EFE857D335EDE0BE9AEA4BE7F95
+2FA0109C6CB803A7F2B985E7BDE818880C9FD186C7136A63CCA57CEDB6AF2828
+DE38E8685BB8771E2988A810F73E0345E8908310C31FD0F7C222F54500389519
+240356E338A96366351A20F484B5651422D1A0FDAE927D548045766A19F6150D
+CC390EA0D98D6C0EC5E1C97E0B4512533CA015299550D65A6EA9A741DBD81A7F
+575EC26534A2210CD8BC3335B163A776277B6F29843653C092C384FA226EA0E5
+F40EBE1799B10828B444468B3DA053A6ABB46879088C5CDBC46D899C794B325A
+A3C97D044BB760BC39839995FB64819C682832A40321F78B99C09513B805CEC3
+996F9F6C14C0DA278CFDCC8EE83409A0C9BCAE8289E42BA209582E05976E48A0
+66222F364CA72855AA1A8DD971B9E012D88EC883F11B6B8DD1F7A3A1A193533F
+B42207516FD3B0F5443A7865F511A1795EBD587D37DBDF03F04386AD8496835A
+76A8A2EA2B1821C0A26A3284A32DDD223178AF712B0015CA9C866D881702FB56
+88AFCD83EBB5B8B70C983ADB28C933F563180B2F5D693852DE904FE07D55275B
+BF14C6F4184BD1B4A9AECA29C644CB5A0BE9622ABA21F24CFE079641418F3570
+3415A4A73F296C050FA68AD25A13C7E948BFB4A1F5816B4ED0207AE7F70F6A21
+CEF402873ACC39E699949E03BE7A042549D2AB51127EAC04572696553A61D3AD
+7A50684611A83B8CC45B07DFB59CE66FF4633DDD79F> |-
+/Rsmall <1C60D8A8C9B6232B67C2503515E3E19A361BD6B49811E165A598B41
+3BB79166E3FDF489EB666983D5C7D39CD639562A5B5DFFD54539B03730F39196
+01122BFF4EFD30EC733326ACD5E99E075E6AD0B22300446FDA3039558CE7D82F
+A6C33C70F1D07536B16D4B1DC2398D650AD9DE1FE1EEF9FC8801CF7C62691F3D
+44ABC62967E1B752BCC2F000EEC07286667F57839EF2E6B9C04C2DA9F22FCE01
+4B7A5598EA7A603107AC2DBC5AB39CAF9666BA8BD1E17DD88F1B0183C4C1C3F1
+1214AD45BA4F39EED6AE5D1943AADDA9D1EC079FB2B1E8FDACACF0141DE87287
+5FA936F561AD9761380B6FCDEE2C83C4F292D6BC0EFBBEBA1571BC78DB7E53A3
+C2355971E9941081B36BC438EEEB16D9D4B14BD1644AC5E58981D2AC452FD6A5
+580957C704505040E5A864423A1DEC798AD589C92753FF4E99FE4D12AC55E99D
+5F0AB1E5E4B10AE2F480F509E7AF89EE8CEFA0BA716FB8CEAE96307008D32070
+D365B7F6583B829884DD2FE6EB7D95965527303A93BC3BED5A9AD904DA3DA> |-
+/Ysmall <1C60D8A8C9B7CDD8BD7DBD65E184B9680768C945EF501FFBAF34DB2
+EB89B7C35DCB2E8CDE46F9D37FB471E35DF335DEED86CBC9BD25ACBBBE505717
+85D55C56B45ACC3A263ED736CAA051A570F787892A1CB6821A2FFAD018F8067C
+A681AE9EC8078E3C7AFE94C42C7FD5A558E11749ACDE333C8BDC9884D4FA3DAC
+AE8A34DD32D0843E9B8D09766739B4ABA55282A00532DD1F8B6DE1183006D340
+67C1700BABA7CDD73E0CDB5BE2DDAE32FBEED1C6D7EEEA3B5CEB4C4205571F0D
+CF1A506D8FC5DC8499A45715F34A9B98FE00C59CEE5F28BBF36D76480FA97A6C
+7DA2BD1F5844A8385287554D6A25D036C1B44B3D155C43934FF8AA5F5EFA8691
+C8A756E6E6312D494BA1468BA6D0686CD0C8B3FDB8C0351FA65E6040F976F25D
+799285A835570C29A2FB34B27E1A794353E610FC2C4A30406992C247A28AA7F6
+E944BDFAB0BBA11598F8F567A868E003F8F3944F74A873C0B590A5CBD543024C
+D6E3B83887E8B4201> |-
+/Ssmall <1C60D8A8C9B79FB048C852057885B7FB39D71FC3016435158EC7538
+3A43C835122312509B1BFED76A61F209ED65A42B34BB62984E18488BC60B5218
+01752FF5C2563FA0352A4574582BF27E08DA350B6E25230194888F1FA389A5D9
+3FBF39576DDF170A31E4F9A79349B244BDF70FC82577F5D740926CBB4F2ACA8D
+2425F341518CF5F38A11D5613BD07DDED6A6C9CC2A89D2BA18004761AD9B9FC3
+4EDA3D0BA2574B07F9B17535C3DFBDB872ECFEEFC15F4D3F7BCA04E0B730A15B
+DD0D5BCB061E10476825BE14CC3CD57D1B8CD428D2118BB782F85F1A67B39448
+980A962927A8E8DBBBF65E6278D0AFECB529564B170722C87DEFBDB> |-
+/Msmall <1C60D8A8C9B5BDB4869BB7396C2BCC7E2D035A8DDF69463A769AD1A
+A49DB431BF0660A482C35C477875AA9502C9E16D281765C1FE89158C85EF4F3E
+57125A0E615EF95AE1B7077390D7D5D6DDBA63FCBAB687625D16C58A812887A3
+BF8B333347AF25B78756DD80DFD049480BBC5CC2E60C8AAAAAEC52485278ACB4
+CB64431DB98372ED33A1281E6970D65A9DEE7B405CB6932D27F2DFA40B98C2E6
+9A163099093F74C6495CCB4C78B91CF36A00F110217924E037A2F56731347A29
+95E8AFF22D6698D628918F5A55716FEBDE556231C95D2821D1B0DE3CCFA65E60
+C9DDB56BAFC7C7328AEA86A4824D8004029A0A0834D297E9E2EE5DAE0DFFB8A2
+CC6F17A3EDC65> |-
+/Osmall <1C60D8A8C9B6AE36D8AFC06EF7691CEA7388408CB5711A90AA9C8BB
+7DF107C83E9F4C9D93C2707EED4FFD917928C910BF7966EA41381731C2EDBAD2
+707004603AE29A600E85B2D80CC1F8253013508BECCA2FDAB8779E3B7D43916A
+0E2CE1B80BB3DF3> |-
+/Ismall <1C60D8A8C9B704CCC403F91AADD9CB2F76DB90BC6EC90EF3D45C6A9
+10C33779B027A5893F399469312EDD288FF0EA2B3848F5A530D7C0162C275993
+6728784ECB91933A5B31FC0120544923268E389858466EE39EB2181D57CD3BF7
+07FB3669BB94B89A418CD729CFF5FBF8DC7045D58C25F7CB07F19116123D927E
+59434BBF93B4FE5DBF40C126B117E6B60590BBF45DA98B6DE8B19144213326F9
+87495E510476E3585AE1A21D73828E47A902A177877DAAAB4C0EE1255BEF7F14
+75F7B919B37EA781F4D15EE851B6A63CFE7192BA2E00BB3BF61621837B8C6E3E
+7AB8CE9EC58E9FFE71C29175C76E5> |-
+/Usmall <1C60D8A8C9B6ED055F5BB1EE84E1A93ADDC8E7C125E88D8FF53587C
+17D959293900B8FD46371B21619962E4E05301A5E3EA5963AEEE83B21393A2AB
+3695359695D60CA9917C3B4C055638C566E55787F9201E25FB6F1ED940BE5C4D
+321EC5E70BC368233DBA0CBD12DA827A229D0CC8A349901F7F6297A8D2B5EE1C
+32919F009B7DEC73D0710E8891AA9A0D36238E9E944FAFD91D10D63C6B88D5BD
+C3A7985808BE85B22B832353DB0C8315F69AE576B8073207A5E9FE25F5A1E4F5
+9C748E9F7D4D5B9763098CB580B40B6CD00897D0384713B624EAD8EE1E24E326
+A2BE8083CCA899DE1FAB4FB90AF9AEB63CFCC24D405FB6596CE1D598C7EFABAD
+D016781F1785ACBA6641462356572572D87FF66C89B7A4AFB38B24B24E1E7B07
+44FD561E659DB89FDAA3D90E0980DCB66> |-
+/.notdef <1C60D8A8C9B7A73DC56ED86593A26411A239A9F576A4BB06AD4079
+CBD73625AFEDCD129CE8B573E3C4C05A38ADB9D43C2E751D7FE69FF5F6F4BCAD
+D50244964753D5C819FE275F32A27920BE3EA3D1AFD957ADA922B28CD2CD8E15
+58DDDC89C143A1> |-
+end put
+end
+dup /FontName get exch definefont pop
+end
+%ADOEndSubsetFont
+/FDJFDP+TrajanPro-Bold /TrajanPro-Bold findfont def
+/FDJFDP+TrajanPro-Bold*1
+[
+67{/.notdef}repeat /C 5{/.notdef}repeat /I 9{/.notdef}repeat /S 43{/.notdef}repeat /Nsmall
+/Tsmall /Esmall /Rsmall /Ysmall /Ssmall /Msmall /Osmall /Ismall
+/Usmall 119{/.notdef}repeat
+] FDJFDP+TrajanPro-Bold nfnt
+FDJFDP+TrajanPro-Bold*1  [32 0 -0 -32 0 0 ]mfnt sfnt
+63.709 49.9312 mov
+(I) sh
+FDJFDP+TrajanPro-Bold*1  [26 0 -0 -26 0 0 ]mfnt sfnt
+78.333 49.9312 mov
+0.080658 0 128 0.288605 0 (\177\200\201) awsh
+131.874 49.9312 mov
+-1.83563 0 127 1.73947 0 (\202\177\201) awsh
+188.218 49.9312 mov
+(\200) sh
+FDJFDP+TrajanPro-Bold*1  [32 0 -0 -32 0 0 ]mfnt sfnt
+63.709 85.9316 mov
+(S) sh
+FDJFDP+TrajanPro-Bold*1  [26 0 -0 -26 0 0 ]mfnt sfnt
+81.7983 85.9316 mov
+0.213654 0 132 -0.177307 0 (\203\204\200) awsh
+127.864 85.9316 mov
+-0.0141907 0 133 0.276245 0 (\201\205\204) awsh
+FDJFDP+TrajanPro-Bold*1  [32 0 -0 -32 0 0 ]mfnt sfnt
+63.709 121.932 mov
+(C) sh
+FDJFDP+TrajanPro-Bold*1  [26 0 -0 -26 0 0 ]mfnt sfnt
+88.9883 121.932 mov
+(\206) sh
+109.841 121.932 mov
+(\177) sh
+130.882 121.932 mov
+(\204) sh
+144.271 121.932 mov
+(\206) sh
+165.124 121.932 mov
+(\202) sh
+182.77 121.932 mov
+(\200) sh
+199.487 121.932 mov
+(\207) sh
+210.59 121.932 mov
+(\210) sh
+230.869 121.932 mov
+(\205) sh
+%ADOBeginClientInjection: EndPageContent "AI11EPS"
+userdict /annotatepage 2 copy known {get exec}{pop pop} ifelse
+
+%ADOEndClientInjection: EndPageContent "AI11EPS"
+% page clip
+grestore
+grestore % PSGState
+/FDJFDP+TrajanPro-Bold*1 ufnt
+Adobe_AGM_Core/AGMCORE_save get restore
+%%PageTrailer
+[/EMC AI11_PDFMark5
+[/NamespacePop AI11_PDFMark5
+Adobe_AGM_Image/page_trailer get exec
+Adobe_CoolType_Core/page_trailer get exec
+Adobe_AGM_Core/page_trailer get exec
+currentdict Adobe_AGM_Utils eq {end} if
+%%Trailer
+Adobe_AGM_Image/doc_trailer get exec
+Adobe_CoolType_Core/doc_trailer get exec
+Adobe_AGM_Core/doc_trailer get exec
+%%EOF
+%AI9_PrintingDataEnd
+
+userdict /AI9_read_buffer 256 string put
+userdict begin
+/ai9_skip_data
+{
+	mark
+	{
+		currentfile AI9_read_buffer { readline } stopped
+		{
+		}
+		{
+			not
+			{
+				exit
+			} if
+			(%AI9_PrivateDataEnd) eq
+			{
+				exit
+			} if
+		} ifelse
+	} loop
+	cleartomark
+} def
+end
+userdict /ai9_skip_data get exec
+%AI9_PrivateDataBegin
+%!PS-Adobe-3.0 EPSF-3.0
+%%Creator: Adobe Illustrator(R) 11.0
+%%AI8_CreatorVersion: 11.0.0
+%%For: (Douglas E. Appelt) (Mad Doug Software)
+%%Title: (Alternate-ISC-logo-v2.eps)
+%%CreationDate: 10/22/04 2:51 PM
+%AI9_DataStream
+%Gb"-6CMtIYE[^blnitWj!HrIdV0lorEFGN3p=d2AK:U\*q_!hY[_$iT*gP5UX1]SSqSRQ?_'$)V>TY%qP`SMZ@PZ&5]GQS5IeD7R
+%m`Y!Qle<L>GQ7K.<ATW8Y&.3ff<4tLWP85on#ub1r+t\(\B,1VnRC\d?aFN#k'iiu,P=Jej)_iEpKp\9gP9_8n(o-NJ)9&<gtdJZ
+%c"d.Iea;XG=$QIuY#bRC]XbTMbA)*>p&6?3aPlR\_,pU'rp&CDDZ00VZam^DTYCI"bGS,pf>eC0p"$ku^->l[*"R8fVlPU'FAYD.
+%pH<]YO.ZB_I5g)6.fSi&qjT5\No0V,*'aApjM1[&?VKA;s5+k>*rNhPC\4:.?Tp^0SRbF/qI]^'n%Sf"Iau[8YhK*1=8[PW@95Bj
+%feh2g<p8L3A_Z,@b<N!cr+8s4l3l4F)ZS3.jk%=mrI?bp\bL4Cb1F/eHN2#M)10h-\l(\1c#S;^"2j?\A#s>C0m5p>Dk5X:Z"Oie
+%_>('6rT`ihmf%TV6aJF?pEP/0^\r2;05#YbIeS'\a5_%#</7$:3`Y.podN#Y[0)AgpUKKQL2Ok'].nKiG?6^6&XYr6NSe+CnDck=
+%d?+"\lhda;+2Wq^BXjUsa1jXk?iT6ap8=BiCnj_^n;[HORXgF0o\5ig-[E'j?N,`?LX9Z("VI(0Lot+`kmtfVY!5/+?ThZOh>Z`D
+%M#tCQSj(t84WKTq]6a,<n([nmj8WB5P83V<H.@$R:$^2BE;aO?4\HWk:*fbtIp=)qnf&+kpXckbGFs@1$N0&_4jiKiro)Vts74)f
+%2XP7"/X?=obK]SVO13_+fi[>!Z/=Ac38STd5'sfM!j\oF_"j]3hd,(<E.%/VlgEmCN:f-1\`U)Es5in@lK@1jd58MolVGRUn*^/k
+%p9n\jC8eaE[rSTh\+/\1&lSEE_>Bg28!D:rMsrhk/^7$3khgXInb)kR&(e;*iD*,)s5!YHLWE;hFu@_jloh"cpiZ.#*V<iiGW=Q#
+%LSsUUqshkocaR!-*[$G42:&XBs2p=ngY:Q7_j)mW8(XpCrqN+dc-Hp9ct`U0FmsSpiNI=lGIs-gY(P''K5\@3^?muXp2GP[l)AZU
+%>2om4is<'4&Sd<ci?2tu#BcPh3mRc@e':62kF`Ug#CiGuFpk^d>Bk2#Kl=D(W,jr6[thj\_UF8BI"+-&1Xoq"0D1+W8Dh:JnpT+i
+%?bp*J"_3/!:^b8g,Gjj:7.;#X^kgo%N*@Djcbc(-0AOC"i%MH*E2&Y,7.;#4%A-H(@tJn;2!Os8$cW@"U!DTsAMQKsF+Q,4Oe;i,
+%kt)dRoq)"TIA=8=cXi-4#5pe=(a&[0Q=pJ:eFXd+(jnY%(n]#+6%tnan\JSBK@/*E_dD[hPe^Y)"lk6M1lI#5"BTn6]MWVJH7nt;
+%F%6*QW'`.gS%s_I:;)FS;nqP0e?[:7eW:lO"/?ORK[IWb1huk&`Wq!e(?%32O'k<#_I'5DUT;*AbSJnUaO(q4]*3rn<s79NkCb:;
+%$UPXbVZ_5/*C67Q95oNTbDaNpW:*PUhG13%oCP3E:sXtR$(GYS#r^;M!IkB),IPuVeQ5)>Og5*b&bcUD"n*]8_:'!OK[Sm3$^B[6
+%5`Z&2n8s><oMt`<n"k3lael'-#<mtp2Z2%4oM,7ZT>%6#pdm^#=2R9LnWSF!M=0COrQI(Rca192k+D=8^58KSZe<]Rr1otMX5/e.
+%i[=]kpN.KAl),"U`6Vl[i%N>*h9-geqXLul[N?!kAp]o#p95J:So\,F?=@Y?r9HTE9mTU-eQ5>%g-7NM(++>09[hd@j04R<oEk-3
+%-+gb_TBi9Xe(0#T?,LT-W5j3fcZ0Q2*hUt'rVB#`%hO6g5O3SXf2KA`7qdIri+`$@rEW41%lg\<s*"Dnr_E.MQ-(+04mgrjg*?AU
+%A:9!kHj`mNoJ>P-UK1TF%c8k1lR(l6i1KQ.D>/ZiP77uF=:=.,l*oJ5h?SSg[%2rnj-9S%rs]G0#5Y%NI9>jRd)*Dm_=p:p6Ha4(
+%%s]7ECC]5b_C2&frY,1V!dlA`)%DM2%tN!shJ!Ad=ANrJE#?0-pjfm:H\(YXcc>jYILn%7LGPCXK7=doF?NF3Tq-Amq6356p8p]/
+%6aLY9>CE'2qW-gq0ue!MF2[/GR<gh4r$VJ.CnuOdT@cBS6UD;RUk@LYQY$S.Rs)N"S[@N^<@]lf+m.A)=s,dKjrC8s[,ZTqlJ$Q>
+%ID^&7gH`q9k)StGE/[64elI6>-HA)u?IH9bK3#J6Y3dN$<6>cP#CnF3fQ7'/b18A51>EE4/c=%\dK7XPDtQBgl"Sm!\%$3Y`+g>^
+%phb4CTn#q_5Gi]fcCeRTY4"5qE(gL_B,hStRio_GnkVgFj:;#QGL.SM!pD(QA:T_K#IUb-.^[@YnKl!DO]%%E@$]M0nJRC?TJaO/
+%[/OG4$eMo?o)eM8UH$VVn0^Oaf&iE!L-:Ue^bO'_&jB#SoZSTJ1gB+)*ZLLtcG87`T*)j!Fq4E8\oG`8B]7Fc")p\s#s\DC1H6&Z
+%^V)m<pRSgHbQ.8oc3V[ZH>8VOV"`D@n-.9Ri:D?2".%s#oN+DNk$.ZdGU'mT6QL,4qBY+@H[MF!OkpI7,gZ#I6AsAq1^9,N+OLJ_
+%0Uc_EnIin#3eBHQ$c%8\>ec#;QRRJ25F&?&^'+35b_\N[GM$P^0gZ\=Xp$HD=ZE^Y$$\,Fqge4XF^7(gSot56ST)P"8AU6<-)7,Q
+%UpuHR/l2P/J=dI!&;Q><JFf>Z5h'uT%#cI\]flh6U9K+%qklsH<82S$i^Hu'LXNQmOTH#g)t?H/7.Z$'dRL#8OCRF`K,oY:V.i/9
+%6)H_q\\OhK#AX<J#(!"L_A\h\_$Iht_&o$lkoK:[J2Uh*e2orH-12:iWjJPUNmA$PJl_8dC_*=U_XlN7E$>7.#W%%<d;S#\OOU"J
+%n_GIe2X*0mItVA3*C%6<>uFnAA(PN@jK0cnHeo(4+86'6O_)EI+eS)ToS`:0W?-MjmcVDF>)bc3-+I\o]2!?0a6sf"DnFd0hfJ5)
+%\rN<<b%g\d\Ec?:]9OH#*/jqY<sf')oNIAbi(,VmE"-s&\HEd`e#ur;-HCc+O/L?AWoJX=+t8Qi\JqCc>5l"eD!!=b>g:hX64>lD
+%i`;cm+I."DJKlOj`I80gcMO&DUHLk:Uti3!YmPSWJ0`AeoMEF;oMh?aKV!aA7%S/TP\ARfcOZbDd4]kh[C4_BbZ!$4@E+trFtD[Y
+%JjO)n0TcLpVOTL6d`BmG(5\YKJ(H7+f#5moL'QgDl\XCe\.c9Y7emMN[R1WS&E\YX*rEF$ILt,.D8b;<mf7\QK1OZDH/LojECJ]8
+%@4+0%E`(?d>n1#3d.J)-X@/Vp+ZtJ<>D"11Z@q@ATG6L%WhJZTRLR+L/Zi,iT\cg0.(BXI7/.<q!,4$e\Nu<EF3n4q#"0J0CHYl#
+%K7k$l`A-m6T]B0X!U.Vs>T$`VXDO5J0!,;0gilp_l^?ft$cOeN8]rFHV4KH5c.$C>L'c39Qq9D?s5N.7<b:f"96Sm4Uh-BT!bQ*_
+%)6Jd=AAVcj9?(SD2%"It0+Ba8Au!%A+M(pAg57on`;5,MCJ;&i^[d%`7u7'i:'%*sl]RYmg:/W;<,Z?Wa4ZcS6-aCIfKs?R(W82-
+%+c1W,jA4:hKL<^sUF*@>UUD!7#`V>hS`R7pP.&nB&VgH0O'61pfquQW9(N(dBXOB*5Nth7HqL%'4duc(9>$L^\o$7a=ck_HMh$i#
+%U_*o&d28')d7gtLiXT!2b3)f(:Ab9oS^Y\CrcHUQjV/<9iG$odb.+72JK5HUV@"4Oeu45M\0cX&'5ItAGNeXIXkBQX2E9VG?LM53
+%CKeCbhf\7%kSMSsi+KF>#h5[;'N2HH[]=0C-EtO,g$UPR"maTmgp,MlBbrA4f^kY9;[:sA&NeecGlt/b"Q*&E7Z7Idl#mijK9L`g
+%M[&hpCi6ju>86t'XOXQ4>L@2Mge2HoM:Qa0HfjEu*>RsKA^(RRNqTd2E`(FL#Rgqs3'Y"qfU3"_iutR%qi/B(m>?\$dOp0Rg=9ue
+%1l7Q7BphR9il8ne78KT,**L+Plk=.OQ)n-gb-a"AQ8"Y^VGkjii-D6&3l"rNc+5U@F732Dc=;s!*\q3aT!J>rQ3O1h"^NO:8gGY)
+%:snJ:C;h5G3n>@M^BLRTdVSQ[2EAj;efM-EmQ_a%<prkZBE`?BBc4#:UK55eIM<e:@%LN_%eQl2)tkRSYfJ#ocE1`mMC;)&77XWL
+%0[n02,iX+c8r[(E<iDK>g;"`1_J$=kpM+*KnI7)=&]%"8ViA:^+gp6j'fs3%H4VrOXW9fech-gF2?f+09bSrjX;81`e2)5b>9sNr
+%Sj\lFfNjA\DD.;``k4=5K&ZX*Cun;HO#WaeO(*0e(gW`VPUjmI$^thg\cYj0T;!oOpSlAl)4nO=LN:;O4['aCP"O-AV>@Q0$`*dc
+%n^,a"[3bTF[$M"kk\9_r;ao:Flh`A6P(k/\BA*_pqk9aLN4<(!,Lu*`ZE6PV&hZ[p7s%0J?-E.\)e)pS-epH/\=ti)io;3GAS*e9
+%?n%PAXKAnm/>LfI\tR#eh?/1hlk`mP+ma!'#U?N!`H`4nF,Y9EdX&m`,@t$_OOOi42m2)37!>F5C/LT52P*U_:0/>&4@k+Cc:K]M
+%&/;@6ABkLn]ja:]&ab)FMtV-]ng8FliDD\;5slM]i2Apple@,k#IY>CV4reK?3L8]Db,J]lU[.'TemP=,K72KG!OdQ-<VSiXf#ri
+%j*#F%*-UGqPHdQ.#0K%L2Iflj7k6Fp-G&;FpS$Kg4mWGMbTV>o/QsJFs.$Jb'Q0XfDq'AX5Ds'oGR3d,LaU%1F78@74ZEh)W3pqF
+%F]%_<J8+<)]IGmC*sg7d`SY*[qTPc-RR?_+YW`UB98(bB4[FMUmealX5O'gdT>t66M/\_\F#Yef+'r0JfDs>b>N>8L>oW4@]\cZV
+%U,PR.JR9'*ej4tgqL7/9ITO0H+;@XbU/:n2c#&GbY!;)/;VoThfae;,?)JuAT>%eH4_ps&m;G4>HRJd$]fUe7m:UG:r9""Hk3`KN
+%0)UdfI!^89nu;Iae[`kQs)RjQr-Wqi_p*2_`lfIlYQ!Pf/u4j"&(ejKs39`MotCD%Er5k2iVM^!l>hCIrl`4Lo(N[H2]n'H?V@fl
+%nrMad/#mWDX^,8H^V53tjn/**pn*mSYmrpHKoNj6`fKn*Fa9cQO6Y,&Gk@Gn^SX'DWm5acF,S:EQZlF'Np>K#\p'k9*HgHO<W,6a
+%^Vm/&jd/g<_po8^*:GOFp^S@+Qg[)M00_Z@mr)SJT9&HWZhX+;?Z'bA&!rokmK!B]I_>;KS??`or;"?"koTf*I;9oWhqrkYq&]IT
+%0-BVc4rd@"pHMq]+2[=rDXSW1*'[c4pQo6:^:F+<@hjkbh0f$G]"\+U/'6u#a4ned(L(-Up#P`4rkldODsI2m#lgO"5/7,<"#j-:
+%b*V_Ss8C.21CWilh-Y%QO8o%Tk3@X"HL/4lIs'cn#Z#l]\au#SGN4H3I]AI,]8)m9a+nn0O>u+P>^q?fJ,XQ_rckuNa]L@)n]1Y"
+%%WLM&KC@7MnUr!?a<&:PW8(4=GSeQ&nAFpK>Q]Q\TEU__9DIu9r>!T@rlb6\p(Sr%oGd8'\a&bG[3%)tLO\pW-i]dM%tGc^f9+AX
+%I.d:P3f#`/lGJ[,?TrfNW@ld07JH*I2.=KgFDamIq(7m3<hnu!6`&[<V6?lHf;^tOpX`C)O&Y/#\sYe2=!(hI5(C;\<):t2S?C`+
+%"2<Y7WS5mL,R>T.U?Ln5a"Ond>hslih->ARn8ro!Hi3.!rKVl8qJMANo#!\>s4uikVrM\r^\;)5bQ+rJrU'JD#Vu8$lMEE6a%#k%
+%l-`P@2"esZs1A<')Ya/+RU3*\h#7'Dh9V^ReXr;8@Cfc&;g7KbF8Ybc=#U]IFEr<3dF6.Rc\guf-<S)?c/TP_1>GjRg]6kiid\JP
+%](p=Dn`-Gfg^3!k/jJ1LIJEBiZ\E8QiWCkphu)gn^HNZf\6;ml)_O9$!('jHDS!LWj<+.mmY.,`GK62.X&[pHN4khJrp+h+_f=6#
+%2,q<[q#(*"5G.q&GOtbZI<#l%%=KA/Idc7nNLqI%4/dW.$,2hBs5rI%s6B(@n%O2GmHqs+l;n7ZeMe%PE.@cXXoIS)e`QkSk9!d_
+%h;-obHBhOhYG`32o):r,55PgsGId\)d#6W7??q9W>kn/DWVOF*iB9i[SpfSVk3Dp_gVDS5H1o?uh]jOB]hH0JN>J0GrrtlJld)K]
+%YUYM05DBc!U2E*fr>_9"gXrcTfDd"Jk8W.r5Mk4geC7slrq8R:2g:l.(dj/COfNuC])T.e/G.5Ol3@ibDnfOA*90HESN]?dip,8?
+%Y<G6l<g+rM1C$VrJ+GU3#cF(kRp5RahZ<7n%euODYBIt4Su]'ohM]2L]"@o`AICUpqM.6"WrBc5?h^%=g[FueIi.IEnI*'Kk_ER`
+%LM?6-Y?1EV_fjZAqr'6[@l(Q'2tl8cNh]tNN,Dm]RrLOX`r1/OCS@Wr9>YT3EVF+7k/g?`BesV(S_%*WF$2I2.FQK>4NuhJc1C;7
+%@_M<tPhj!E&$C'bGgO"XNG`dpbIF_1`bhckoj(jIl[D!ua#33S4)d_tDqDVoIXTkuRqC,e\kTpW2WJE'bT"#oD`4*PB"-H3%bl<a
+%Ctig9mC0uVgeP)Po.(Q[V/:E\^T?2?]4T[_\m<&iG2mJobr`C=ml%d0Gd6]Iqg./dgO6R"pVVIP3r$@3qt5EEhsP^crVgc7&'^fM
+%%c*iQ?#=t%_3a%dD;G#gY<?Q=!A`2Hm71<_rO&VQ^\j812sqcCl:ob(X)!$2%:1<=c/`%(gpgs%2=&6mZIq.MVp2r,pXN*PD;3?C
+%4YHcVbC+8:RrdD3OL0JhmB58tcR\X`CS5_"Fa_g5h#O!OIJ*R$hY.jn#QD/N%0sW@I-p^_ijI`\c'RI+jpQU(/,s8C97D3"3kee3
+%)STstq?()O^34Tu*`(bKn?muY0a"[L?ZU7a5O7Ca,hJ?bMZ;?Uf06_TqHDLmeKgKRM$j7Oe]EMNBB0d!,Qnhrogn@f<3VVV<%sSV
+%<NqbXeRNEL.#UV8d$>5E:fiaFd$G?3;:m*.i39sY[JL>4LGZfa`a;q`'C'&YEPa)nh&^48_7>3og>_b7IdX+_oMaW@?/Kt0Y.I'1
+%pO1qB)\2r#c/$l8aDUH$ZE660ep`arpB\D(W4N8;/e$_V4F22md36I"i/rNP!OhNkFe1K<O1'\=Qd4%]`6fQ>E$X:dl<78\cmSt3
+%GK_;HJ%Dd?aqonV6mA2J&8?bbg*)Rg8>Hn3WN1!TJOm7@UjFB8)Mtgi,$cPE*KoY1,uYpa:So1&UPG(HS/jS5Y<DM9*eo1Kq[OsS
+%#*.YHL[+@bGc6ZEp7B\.=]dJDhZ=5f-6/E)'=T?<:E6!O^-epW+Kb*orX['d)Ou#)>0@HrRACLkFpt4%g"=(kbV<4C%$H@]JY8qQ
+%&o34'0rftq'FoQ.@BXstHQI'_6QLE=:<Tp-/HhK-A(<(4g#,>Qg5JQ+gtY-Hikt81cTH9eAgS#(EnD?g\A:Y.=_JYT"#aLfY/.0X
+%pN625*ng%=Qa"<IoHJo$DAIMaT:\aG-fV618m@Cd'?])J=XFB+U%ANa]0dJ&V(g'N)J(Woj0mYaSg(KfJMEm<SnM*EERuV92^k[l
+%=G+,<b;5WDCOg8TDlFk=1n%5i@pgc[R8,8pVad1G8rWm0V,bC[PZg5Q<_TZLY['T!;kR2Y?D1Ifi<>[P(nVJI-+l^I-.E^A,m7;6
+%)qeF)g>,ndS+,/[ESKau]3X@'ou5kdU,nR`WLd*QYBFONh!3Sco36nT(06C<=O"+>j^atM9_2LjJMh3`MC1M?B[NVdcLn:)H1s+%
+%l)BH[s+QL8+.X!,U,_jmcGoGikP<rpFeHRGIck.sGjIJ9T!7f+@cR9<o=ST(S7M,:V=X<-GhbB*#.4!gB]E6Zo8IGTChot3"a,8,
+%)ipEmcgGtJokcf!F.OsYSja-\auVc7NCVcVkH$bkB/cF,3R<7(c]8=WSNBXCNCRcC6)u+B_tW'aED.2jf_`LmIZUthQM,dS><hnj
+%#K#hY0m]Mb*]Pb8eYl.0:j659`Mn/&bpa9Goer7;,ipMPA\<9)ro?XtK^9ro;QsOmR!OA^&OX8&eY1F#eQ:Y#YI+,l>A57m`7S!(
+%$i"<R/fG9#fYh5.I(k4a'a%F'0W3,[FU$BOjXSUYk>C3Hqt@m&i><UgInS*rk*5Wej<<d.7Qn=Z6/F*Qc#hpdHqN70^Vd>%aZ"3i
+%VVKeZm"/5'N!!X<_=+NkI(9#up$GO>s16W;^9p`&"L8U298N5/bVbm5/=UV;iNGlQfl*$hCTa5=m*@u#MEVMmE])uoc./5_O&s<d
+%+FT73R`mXY.p40!\;nE6q>\VUF."[_05&L?rO.$PJh+8J<%pVG4J5=">)Q,J>*FrRfMp7/_qZ[HPG^sqk6T;sjV(RaQg3ZG;kB?@
+%jV(RaQg3ZG;`:IPes8dOckpjhdJr@%"hL?7ME\NV>+oVa]:^8*<<_Bc_\M`WKW>J^cW@><TdD5B,VC!+WLSTU.I-"U.%-fCDM,O2
+%$VDcsT$2bu0Wfp:g&t-W%Jm$eUj^T`76;NBN]Mko$*HrOe5o(O'tn`'[+B0A@7?75M`)M2g,eH*ri0)6'c!'o<V>kBX+/8l4fqnt
+%]#Uu=nLE[9cX544'ae#`m]+Q^]m)..<*@&pVCJ%(CWNb>A$3A8+DC^iYm)Ws%TK>aI\YGnd[0`.4cb\NY&6<tJ*P%5;F<TqY0qA*
+%R,9"cZ?g`-qWQIrn?6aX-nh1$mSI+J0SaM,IQHVt^hJYWc=fCJ1WS=G2s6e.DRA5A<A<3eb_3CG7[n2?<!1nWkpPt\P^fK6`:=Pa
+%;&!B:EqU-69QC;CUQ*PPjPoui8@>fLJf<0)L1I_:P7@>\Z.,hpPQ0*RETcDbQGpA&J(mE^heM0Amsm8am3Yrh^iD-UcUH<+E=MG_
+%9dC[]jT?Xb3_'ifktCp'7Fr5%I&Xu(M!UW.j+j[j]DL.XkG'E3jOUfm$aBk)PVTHW+]B_hH$h)2]OE#[J^tF7VN>O#>%=d_K1D[d
+%-kE9YOXLfNDGj,aF?o,h8e_Z8>%mTG.N)F;8CS)H34-i%eW-/BS7<P_/h3WU'UV@X>o<5[W$mq]<5bM2S*AK;X<ogKANG$][^Iqi
+%H=kU9coPG>mZJVMKDfgK+OiYLFg_u6)A6fC<RB)jh2M"^V37\?=K70+-*.H0UQdF=0_VehMKVIp1m4t<m#@#a(,rljKNEkn8$Y;G
+%__S\2#3[D4RU%U9pU!_S#&2d^RWpX11W'QZdq#$S^:61Ab^9oX<h-dJ_YWUZgj;s_CQ8%@eT2I+C!Tq[SQS6[KpCAUf4qt-Ot>20
+%bPC<lHC"5homX]U59.=$hg*&PnH.Qm5sKXG5Bt$%H)tlnp&<kaJt5sO2Z=l_+.dj)K@_)(heKL$G6e/>SU]P:^Xql8b'.=eS`tR#
+%>2Ql:Hgi'3^"bYRQ-I3"[glJNoC0r*_c>APr,V+B[CFQS6L/T%c,4iL4kW)gPMMF>@;Gbf]s:7IDl9(9D:gBYQnQ]m[ql_$bNp9o
+%>:&%Z7.g:E2j1plFYaEhO9:Z>ib^iT1^@1G+4%7,<A1WJBYK&8b\XLZ]r\?%YA3<[QX6r5(]KN7dd)dRKIY'AU'Zs9<0^"RdMel+
+%Vb696iq?R_cUsS%E%UVJ)N`kKLsi*#YeQOqoSPh=dCW'L\o=2[S@SJGG]H4`Y3<JD?<bfcCQ3_b+n(k^E(RGSOGeBJ<Zs/#A7ol3
+%aOC^$\*T3eD-=8L,Em2MqFnur7TPOqjEY.<6N%4&JdadIA:]).]sbuh2lrNX!\%Z;PVmVPIR\W\LFgmR<2]lLa=@eB0DDCtP4H+K
+%cFIQ[E^gO"Z2Qa+-gd%cG,S"'\tR,\[f\.i463SLepl;mB,td/'PE0l`R_G1^LI'O/aZ+67O]a+0^b,o;(0:8MSghR=X7$?.Rprs
+%Otk,!-llmn1^_;P,/YI:P`nsBZE.$R1<N7PQr.IM4k2%'bpYTIlkJ\%j_'gN,"$ts,ro-4>SAZX(qW2)MEHk229Jm\W_oo?WZYJ6
+%\46!,"Dl_@NA<Eg;i!qtm)+,rr@F6!EK-uEM[am4;,qP>iN>&<l7FpL[7400`J2"UW2d>ZE)62^4l7S9J3g?cZ&<:(_VpN9E:j9.
+%Y7sX%;jJIeF+pC@JT<S3&$EC[bq$cYLWIaU0<Z$q^<F]eO&pnbLli&]D_`rZ9t9sB&$I/b:H5lRn(f5d46,04Ec9pmLQ$G\'Ab=2
+%HUp,?b."-7EJ7H,G0l6L<.L8uhh`*Wm]K'P$9CYrlPi"?o\)=Zr#W%6^(V"41StZ-XLW<BdC8*X0t#/ZimFd?`J-E9Kb;7Tk?&]'
+%E-6U+B/hUmr9'Oe`Q%Zgb=p.oX1)2CC7\P@`A1B``9Jq?R@5N&?g,4`c@d5kmIRb1T6+)U1AN7up%g#$)P#[HWnsbLEeEuLY:;%n
+%qun241b*_j'sHPC<#K&=g`,JaX'NCkXU8ji_t%AdQO818<T_Y-Eb[Yui+-)`.dcc%Y2RT9SY-U>W%.Cq>4RYVp63@qdO.)h51P@b
+%HC\tSDVD'rk?F4@L9&r%<oq>ll?0g@\Oj;W?8u2(o9V!]mM4>PfYj9NSc9A)pA^(nH&W)(RIa(RLtdjr0/2Qj?FI[k,2u0qp$>2o
+%8M#?kO&^Gm71EE2h'ZRJR(Ki@r^So'bJ),8iP56cT@P,&P[:VB.]o;B[u'("X/G6"@Q<B4WHt$NNjsD8hBmt%Y+DZF`GhU]q6f0M
+%<n"'TlUbYFXm3=Q797m;Sen:"\>E9>:#^`&BiQf^4L!n.qj=1/<)7dE5C-!l;k@'UEQ$#UYtEVkq5T<i>PY[Vj9dE<C2qAgQr!.e
+%:K;?l0429R6:UlPEW2hMaX\('k:E'[f/[.,PoI[)K86&4@Jmcl]Y4dfI]e1s)gfrp=4%NOVM;LnRN:aSlsYr.cCVdu,fciBZ;-=(
+%<P=Z?>1BV<XfU!G?<(oTSJLmuH7S<gW)qMR=f94u?.$O`_DU/6#%#djkXl%pfm,#8?_"<SHSfUY#?=438^'5Sj'40NVoEZbs2#ga
+%2$>#n;7CVL(:D&L8Q1['m%Q.[YM2'=Mh4?9YhW63T[[X4JBl]>G+&V$37bF8Tpn&@krCh(h]?]#6W1Q]*'aA49($)^.tjGV?.^0m
+%F`^NKPE"2(kuom/bB@Z?SZ17[-Mkr.N:t)++`+<!Pj?2fS7?(o'i^1(8phId)`;N-MC1d`AWWJ34VLD/BL#Ip_KKYK.W(PfA</S8
+%OG\77m#C_]_a4"1cURIX)nqqQm!bs[HblF^4_Dis$).dY-GM#=ONF\3nLErM`#mDSbI]"Bb255Pb@j6*2D:Aoa\5BNAjVf]i,"eR
+%3A<*R[0T:n_0C)JFh.^X?6;b0/jZPi7oH6Xd-CGKn'6Z6"oVM87BoE]fNt4,iX@".5\IB#8TCadH#[q<S2n+UC1go8mRmsYE5n&Z
+%MJe^jUqB#;E.oA_bH[Qd,nA,WR%/tsQ^:t'[oU8Z]_mRkpatOnGMn2L7U(",_De#lkS\*0QEit[-G`oqi!F<W0e+:(2T[$t<K]P%
+%11%[tY"Ku5$L.Ku10k6l=$l<#ZWoW?G4F>sQ)@h=Cp]Xj="?eBjZ*Y\HWRV:SA:M^(31$5>7Q=5Pm"?<./]OYe&(e8Y^-)VlYZT"
+%A-;Z;%H/#.pP+Fl@BSJ<&3e^r>8k@-qe,7shD<oq]Q]d,PkQm#A)>DAT:r.tlUr*#/auT[7<:XRJr=`N3T[i9jek+/%6W0OBim6?
+%)=)f)kB'dmYJH?R-SO(7j?!"P<-bekY=],2-j'Q!JoGQ/.rEMUO9M=B?Bpi;/`t_)LW6LM<U\45@KXHn"WPBKkHV(pYWl(N=UY+^
+%j7-`hrV6X2F2Q]q/V$l;=l6u2VBnh`nV3Htesi\,dDoaf#SLM8,Y.j3=p:t)3q>Mc.TiNZ6/?b4Mp:NgIUp-lh+=?]"_k(P>$sjr
+%ahC)/CkpEj%@^i<fER^RaXBeo=Ye3aBi^2!EVDQIB.IJdIEY7:D`U%q[mc#D[X-,m>JT[,QYMS-P])nQK-Y,QFt)n^,-=J<GWgWp
+%>GTMe^MX_6cq%EkJ>)]X`\\73jKVQ\_3"Z+UUP^6gZ>(QLfZ7iN!X]S)J<759pRkX/%'4K/]FSAQa3<!_Q/>oi<3+B"6gdr1_)t6
+%eBGUl/AR)O\6=^$=bs]KYa\PK%>We>@N=Oo)i:EHF%-F1&AaJgRuiunKkj`@7#P!S`cG4O8D"083!(AYp!ADge;RAb)R.`WW"\b+
+%et+k"`*H'#(]1Jj[%):i?peKF0)u;[UUpMS?gUaU^87nl/N#GF(K94i<'L!`MTk$\pVV]W5#p?d6)3Q#GJf+R[(_ilA)/1FQnCK]
+%\lEN9>l9nP3c;"c]Pc4n8qf'.@-u?-]$FD-<jCjKC=F>DDm)pV&$$e^a=C.k;;<V"0cef4Xinb4_[:]^Fd='7$aH^adTE6h')4bX
+%0SD`5jIj<T6CaWG*+:ZDJ[oj@9O[f(;s5%XnTG4GfMmP)CE6kIo^^H[((m=DS&d,DWpgNF$OaE7F,i8&AU2JiX,72i+1\t\>ns!%
+%nXOASG?&:i*+*_d`T$.D=+u.*Hf'GRjI+UU4j9N9@J,?]+*2(`=(Z2p/2uTe#"J=)H\3%#dBlldV.'j:>4jd&guJ7=HHB#$k8#Z"
+%o5^,;U.(QCB=57=_@fY1H$%056D=q.FJt?>c-KY6)&Zt/0Q)KbcSf#I^=M8+,D0UB4J\tt*=Y4''i%`^amhi+\0Ope9_ZVoA@6]n
+%YBYt+\e0EMI'(:4k8MV(&l'(M;;cb_8IC4fIN4b8Z[4m56ZJeb=f))nIGqJW/U+2$W)RpLHeAOj0m[&2BbnCm$DH;L)@P.n\-ftE
+%V9jdV_e83]j"b2$e<1>XamV*Rad]<g@9`<F4WA6,)rWOM^mLr?k]HZPjTG]IWD$m0b+)$QP:%M%,aG?F<gcGj&]@WOlRWbO-R4^P
+%"Qtp[m$!YhBf^i+8OkI6Bhk'DV3G+1.1&[GJgt/4^o(hBPbHI+?d9mA"(>6D2"B.["jZNr]]c0.?VXc"mlP+BnPcK!a&nsMF>*qb
+%`j=cgcDkNJ=nMp\K<"9dY]sVWaZh.E_,hr.3BP@!a*p%nOIoSh'C\G_SEQ*a<,-'.W&Z+^92Bm/;`oa;r+HIBBZ4ocoG653RcnjZ
+%DRf2OlbJnI3E<7%3*5JZ:Y&sa(n4[s<]s?EX@_(+?KG\cq[;#"3krjIQ,5O9f'695p,,kl&(H3)#>4qV>*U''\K^1;OK$)_MRf+"
+%9)cM'fO/aS[DLk3I#9+<$_8\hU>RbOpaS*-D'f40Z5YDh.To`-+@8p>KM`]6$,dJYX,q+'P0*./Tn%/%?p"a7@N":Eq1%Ai5M7Qj
+%_O5n+g+f5qUq_0"hgQTlpqu_%eDYlQ?p@_lF8b*dIUYO9ZVJWP,F01OL<SW+dl"=;[cFm8g[0@gC5iUT2B7A'LSI[[$XO<2F`Jl[
+%?F3JE:&,,tEX+cP[H=kfb=ACPHsCEYS9Ui*2psl`_6GD2Qq]\R1U#Hd(Y1R]<f-Qdg$a(*^UWLs>!:k>Hp3@cn5C'Z?Dp<l6K5bA
+%pb*ol$]4mMikLTM0-pN)M>op%^QA4D,lZCAnKd-G=TZ22U?g/Z-Tcu>IYAYGbKe75q<RARY%UUMl<lP+VGL<I2mQR"Mu%Ac9ROY\
+%D"Vs0CLJjhXOb.O;ZfL#I%.BfNh-+"bVQ`\=`qe,G.V?-)@tTg.e66+>ou6jBB#-L-n7L7l\83n,<!`Cn1h8OkF-Vdg'U@,1$=O/
+%nr;/Y4==e5&M)`--E*H^[q@0ZbA;mEL+W#[Nd8!Nl&e!6KH:]>?8Kpai%F=JE:,k#HkdJXS`\D@fV:D'q("AuZL]QPl_Ohn5/"cX
+%8kRjk[A@0`g@J-**UK[5mb<V9mYAaCY-%,$GE4,'BZn!tr56mr.\,oql.9lE7J9\Yh_sfd8t.?:]oot:"Xgd:gg5nO10@=2npH]s
+%(YNsd^9:OYI\dOhi@Yp[',BtV]l9#_O&;uf6o'm0P6C`YB+UC"iKP#"W&V7a`iF+uX&<9(/Cd]7d'?4GFPJXe";[5USHE+LL@XKD
+%;GFi-JKD#oK>V?ecLF(dGN$,VbZ]Fr4uo0#0k?!Y/JEoU3#=G7R:e^/6JY_B&8cD[U,?-fY>7a^f1r"2P\SP6WdB0>W.bGJS(fFe
+%kQ<kogITK'<GrgJ$'C*`Qr4JtBD%Q>"bCr"D\_5j'-\n=#@KGU2\Nf;#^Xl<f!+J5&#kgFWBuk`66'skLD?pte'b6sYA<OJ[ZT*W
+%'pc>n!d@,1/?WrU2=A"TDRI"$V.10_At?QHb2kKu<ES6YGj%=ogW#Lq+2UIeYb#u?fVfd\h9a7`*p6fX5k7UF8+J%(RB"P5HQB0T
+%MQFB^Nq%R)f_AYrITuH)ISspl^T(f5RmiiKl)I_<C!U@hHh+.6ia5Xg#G[V4!B*,2<U+,e='ei(F]L'8HKFg'8-'C]12hb9Thrt-
+%,KFE)ljucYf''b&"oEl'%Q7cXW/Tt+bQ_T;&=^KQC^+t%+s?R\@k4M1<8]2548bP2'M>[@@U]1dEtlc[\;I!t'+0>C?!IPDN^HUb
+%Po&HN;&48l_["I%(j5ZJU@%WA:J\'qA,\W4E@Nh2W11qma6UH7TF=8?1-k&+&1G]ahYQ*$]*_=!FB,lprpj(3o4BXqniq?cSoBCU
+%C:j,EH,?u7YK@Qh-X?8RX%M@bc<Y^_'f%+U-mtAPe?,5\bEZjgE%ffQk5*l]9pLCf3^*^Qa4I."G,=E6,R1_UhWGN)].lM5:5@Y[
+%B\U?_UU*=6V1$eF.m<Q!f14rEOf)tYSNcnK:OIoq;"9\Anbc>QXkoE^%ir]q9u8c>ms5`.0[a>:*Dhkf9a"gHP3d+KUIQh.e_>hj
+%&,YYZ&qSEHZ?j^\%j9)r\'4gOiiIJ%b#4_hrd*_bs#CND_,Sa@:OM7"T@@8CbWb8Bm=]#r&oA@YMI.^b`sDFeoNI:hmht\Ub2sSj
+%d%_kfLq"p4nRG2U'?ocsQ:WrWI(]'pRp3PEa2X[A%t(6;L6hQOE3B:pM.i6&c_:%2W`YLl&VddO*:H8=S:b>2NB2s2+*[mK`*UWT
+%3H1#\ZBs+O<H6saMENKd>Mcg@n;5S/hS=*CTf@&9rlB*VP#%pX3/pAM@JgRgo&BfO^e%T#*7hl7m:$`hiK^0_*=orp?6pb7&f.AI
+%j'%HlN59KH+K%Tf-qKBEl'4e"F]pH#c<k\1o5^p.os,7&QXbHDQ_!WY*:$P:m"FQ`=J+k)a75Zm(LNI!`KR7tT>RP`Wkn^^L%4sC
+%duChn1@!It2SgS[B\eR;p#@7H\Vo;hZcYK'[/(K/6OVh41@s%FASjBV\uA_7HV^_=$h9pG2oCg40A-/t'7(+:[b@dJhc"7^4lsC>
+%A5n<U_/GMs32d#2Ji`qA6D*]]TiuCngVsn&6`S8/-4($DYeVVG/;QsEo'55iY*Ig'8@FC10r1G4I_P;r2A]([$Ph.c[qt*X=.H1n
+%J'&h?<94m$/).mL-S!f3c;o9%%f``m%p,gVc'P1qh=s4A(!K,+1oT7#F@<jgCs]2_9.ie$JQW3_FcG[Te5\Khq!A-k'oc3H&(aQd
+%16Y\a:Wq8caN76.iqZ<Z$fp=3ani$/FE#1IN^cKlZ$PKHLpP,Cj)i$'4Q:bQ;SDK\inWru^$\#BI)/^ojud+2E[jr$:<Pl#*;hkX
+%I`S[aj:5186R>l[ba/j(`*9an#&^_pgSml]ajr&=]qG(jo3jD#$NB]OU[1LHB1CQ4!I@t.5EtknML.ltbcMO-V6ZUm8m'WC)j<i'
+%s.'#S$`Ck,c?Ll>PT?SV/lB<u0f'-VW6R/Xjce11%o:N4RsFj=1Ol7]B(?%:?>uS8=g1j5:c`eSce/Ea98E4'oba;F[-`E#kH;ZI
+%Pc)Kl<HJ-h:KY-,B1*:n)Ge0?Cc34B9&GJ0AMKV1-<t>m!Pt6:<O*8MG9]H:S?O.K2^RJ'7,4:<)\eZtWgJ47P\[:`<lu\MZDjTk
+%Bqf'GW)=rjPP#5&5)VFmnpF3/e4j)7VCM+_.6/fB;X9TKp#H+(kIS=b^'j.deQ_IRJGN3Xjh;,$5Lj!+]7B`V^#cs9W'AgJc>5Lb
+%5SG[WB9,&64,@'Vj^1l:?$%mllTtM.bO`JJ5p'u(UG3tR6HRP2bUVh#4*55LB\5Nmp^g5H0@!PYi21fD\1&kVcI29UI_:+hrkEnJ
+%H1h.a^Ud*VIB11#g%3e.T9?=KRPcS$'.U4>5")c(NE*K!'X$<\\,\8k=)W:f!#^Kkf3!`"7cEVi<oK3=\14$nMQF?U(9CEp96=M)
+%@$!E:a1=sP)8X#mD-)5V`E+u&H_j\'eGk-=^E@M&M'#73k90XG')R:LIt)\>c2I>&_tEC-J+GT+\+LQfmm"WI*I[P(e\f;prmi=m
+%qYk`IqSSXA4Jmm`=&!a5:L1"bPCJ><p[S]af0d7MkF_;<+8inRjpV3pl;t`)rTR\TeH[Z*k<FJj0s.%ObS7ca$gDe=HF>LkIZ*c4
+%r<_BZ2'ib8JVqkerU/Ci:SINboKMY70E"PenrE@]53JcIn7-tip$i+X+rp:gCrFSSh.n#o3k>\p%Pr:+SM+0M4,1%a]'u0P%/6@Y
+%go;AJ`hDd#':_oV\CD@dJ[2kbZ50Kch%4M&\Y8nOmsP`:Om/TWC'W#7DOTK@j4o]rEV9`-^M;`&*oIk9#9,*rl<3;_^,&M#FZ5@X
+%B7_]T\;+\6B__S?J#7!7I+9[1FT^7[ICXiE\8TkQ>W,7ldocK.gr;%DmudMAe2Q_eW5F&VpR\hRGi4#j"Tg[CTa*ic"<^'UiMh89
+%5T<l11^5Lse_NjU%eh25NTUN7]f*s8_>+2Jd`M5Kk1AL7cJq2-%GrB53]cCqauV`pc?H[?(Of(4Y<!Lp1Va#"?A3=e4ahP%_gr-m
+%HniJHp(Opi?h>C0_nCeH..`OT_lT\oWOj#FngM.`JoPoR^.8#T[2s^$Z]`$,Ho3n^T#m\?^o]V=N^^)#__7^75*BGXqu283Y2pS(
+%05]]cPFrd&ecVk=<qQ;D)gn%eHpPCTFlnV8H)2MK^$ri7H5bc!Zfb3TItYKQO-^t2&BF]9E+jt2E*'u_*">h'/YKC<pP^*;OA$cI
+%6Zsd(bfD^jmii-i+oAP`Z6ooK7fWI=mLa7hF^B[C1C./4)[:[#[O9O>&Ki8+#PY=p^P7!ESc=m+@h_N(Vt>SB'6tru"7_h>kJSCI
+%<>StFc`W?'C19LIlqKPE.^h&kjre4tZacC^C&sr*N47kETGWD;$;=PZp*_d'KQ%$+Y07mp'^S[B-(XKaLa>jjd-j"P3=fu%n)N'd
+%0_X'^]94LgYIr`T<q70dle-&g1j7ch="+1'>OW#64^uqAYMR18ojt:B3O`G`"gT+1&#Q)KX."9L$q%Bfl.6Y>dmYhQZ")F>VhCa;
+%.Rp(7H!?HR4P15MmsMGM%0&pqR+'4'b;RWj4$BsW@]Wj1-eUa:+Nc7ZE&l)FEt%aEQj=d<O=PdaJr^!B;!o"lNe*XHqr:<&n:Pkt
+%Y=fRDfoK]?q7IsdB-t#?mg?k:LouatOmURg%6\gf%dV?c"*cBlb"O!j,aQiJ@n+>>/41q<pu<7b[:/`:E_;ge16=,[qV]*ZD,)md
+%1(?oGe&+>K(@[=grq@<_:lHcY#"Z\-qZJ1n\A2<6$h<Km%3Naj$tC.t/nhs.h>9V]h5?-'K*jHBg:)M\JX?YfKdHfjd)UJL!@DA6
+%kW"+iT_!DG2hMSsN'Z?jB;P'Jmc<o]JM,Kt!!$-#XrN@&=Y@eo<\68m6*2Y`'&c_8J=TmWnJ:n\kug_fR&iJFQCBrH"-@sphTsKJ
+%#&s$tiHS_UKQmsQg5'mk^2@=Fld!]:M:IC@"C!-"+Gh+32I6b%"1&,jXb%dr"JJ4Q4P-M[=J.'oD`PYB`tlJcSq(K\T\#7Q#/AY$
+%EZ`GmNmSRic:qlc(4^<N-NfML:-)G)fg*iqTT9KAYe2o*F-7_7=dJW9eEMaBAK>Ii!0*+d+Pb8&merBm,P+<GH<)HVOmaZ!,3Y)n
+%,#_tCUfM2Uq.j$OV$1s*;:3<c#)p*iBnZA$i:#JA*q>'.c-R[e4YdVAcfFs`S]b+b/6#aU9DG5mRjGoj4ZDk\#+='S$M=iZmh,bc
+%HVHiTDmkDE"+p]J"!,aLFTdD9kQ&6,ejC.;I$<k!RpGEJWj#/"&((T')ONe:EBFM"BX=e`fWh!G/7gr00pQFRK+k!dKV1mo/PkA>
+%+>O]TdO!*t!Mfa;@4'9u&b`%K@N]C*Cra_O9::`M6AA?S$h&N\\dCqo?=5[\Bo3*P44QG*4g(X>^&8@akrbMhL=IO/.]BIM[EV\.
+%P'U@U0ggL0Oa805cm+R;.;ig<0)IpO;i)0abf]K3MmsP51ZU2#a>q43=B*lcM`NT25kjb@r<>6SkU)jeTqg5ijhC2(rM9a1']]@q
+%5^i+?Y$Vu#:XrJkiV$A321aN";4h:\Gj]2p8epnB32iPBcsWI+Du6e^JJ*8GaQO7J^ip+p6mCj2psaO<;YQS7coJC_Lbd<pV5c$o
+%<NT<%=;d;X;:`Mu!X*?@+"-?d;C-bA8lad,igXJ!?`+q3lb'"@H*.%!!EoJn!KmXt!pJ'C0GDDdi$luGeDK:a7/2_UmlDdF;,hpG
+%4%(+3h_sN!Z64Fm9%>EuDI@&V>'N?,&#P-8+IH<K'@RqhAT)*h?]^8\P)W76W"d@06C!XsV7.(/6LUTSXtfJ63!U3'pJ$jU0W[%U
+%JVE'2mn.[Q\s0X0M_8QmgsuO5[$#c2L!R7]n7fQ(,,9niJRt0]>Z`?<'0jnR7DnsXZmjtK?r%k-[hT3R;_OWN*ESur$q>Tp,7=e8
+%0!$NF7B?jgT%3mC9-e.PUu@sm-HkDFT.V#^UkfiecCk8N@#"E3/nG6\f.am9"%3=WN=+Z,3`#DM<E]$(fh7_:Bo!XGRa+*o8sql6
+%Pg1*AD9$5-SkO6m^a%qPQ@fn0EDDe)A0BrF8]?ij7W-dFC.tQP1TRHf@.tU[l$s]-i.j(3@hGCiUbbPE^tTLZ0l3i)\PPSE>qG0*
+%(8ASR%4(i9MS+Rl>Z30k881c[fHe(%ZU`*@=jUC^n>qjsn-O61h")Stf*gtB2PUH[\#=\8ZWC2dXr1(+##*$B19[O^Ng9Z!`XWj<
+%J;^ga*9Zn<g3h<E5mIct`sWik:ka8P0.rakMmi:dpPMVuG]l'ml0b;$oA0`?5__>46TNK*6Wp^09sjLO_fm?mFj5A<55T>C['A/.
+%S-P-6@hXg-ZU^)p2\XTK3(9LpM2>sK*<Og8CbeMIqGSI`P+.[[H(i"I.T5IDh"l/KoEi,=$b$=6"$E[,WtqjDYRT4oGe67Kf^Q8;
+%U=lDXH"/^#&W8sZ/G&^4#E?*s+,n6UcYL,u%g+QfZ*e\FFBPu*C1CtoqU,Gd?n'(N"l";iX&&)"$XebH`9orh4\!"sqh1obXho!*
+%Rpg+bdXO@U\'-PsAc_9sbd<aA_JWl8[<CGjD4$EMS5#+21op`3F_EI#)2"*W2jM`B5u!9K"mkr!I%$,sAd?\6cPB5trA5&(.C$3k
+%B=0G`--Mgdgt=Q-HSPD(irU+k\UcYN-7Ef1inBq'4H6WOgo3GEqi6jQ*FWf'fD[)nJF/-ZB43@8V'pWAML3FUQ(cS=(T!kCaH7cG
+%'?$"F=!c.+R;9fg$WJmB*cJkQN-ids.."@nEA(PNME:cCm@l`M[Zqj5$ek/b<FAY)rr@_L.%1Co4js[a;BeJJn:\Uo(n,#^L*[U[
+%VX:c/<GCNfD"8h/NA?#*=Nq&2;?^8%(e5unB1A!P0?`4tYe\=+/JHBb)S-+=Knn;I[t2Vm0Z8JA(-us\ilMWf&X:tnRCQ%#Amnm.
+%PjPt$=Ad)64O<T:nl.4*O$\fZ^_=jEH_:`Ll@jP9VK/jG1fRmOn)d#<J_R>q'0-74TOo6t*:&>Y<RIZn;,quS'31mp;H60ROapPD
+%PVUW7rHnLU:Z5WL>>uKo'h*0Y_d^_P:"1+hB:Qf9NR\tM$B!CDV!?\SHe41)1Z3ilgdT^lZr8c^m*n-tK+t4Em;*Z1nZ9(RJjUVR
+%`)*A3Y[87C!BHQ@^FgFh%g>]ePXSRhmPMZ!]k2%X7Vp>e'5=BN.go,\n+*!EIYGf1YiM;K;6_B@'rh\?8,*eESrfu?Z7$gCAPkXe
+%b6;CCZ!\@Vgl"X@0pGm0q@Xqt`+Fk25d/DbI2UZl!]\!V3CZc9@r"Yi9Mt#LfKm;.MhNHNc&HDf`g5<:=<[7=l1uPQ7,TL$#+J%s
+%UU<W2K;C;:g537o:dPq0log^eS-t;3pT0'.WWLj:7>$hUS<T<X#&Ace!gkiA=9D"n@-9@;K3;A.;SjW?,mA9u78bJ<$G<^`?PDRk
+%E?*Q*huUcDetf+h^t6/&c01WrP6-rZd\J^.S^Sa![n^@/**B%GUa9Vgq/OEV$iHN@4f6phi3V"+ouJ_,1?]Gqbe,j-Kp,\28)@u`
+%D`53F5;MT*W.:[BA#HId]r\FA'OZVh#$E/:F)#6"m']L_b&^\:VoikD^VU[hp0u_$i^bc8[-La,P/;NUdA;$W/7Y-rLXq%,eSAV7
+%m%ZM=@9U;4ATaf.R^uWYp):\Ml^)tLGF/8TNVi1--Yh$l^j:o@D\D)MU@%Et,or1*!XQTD!5R0[^O"r&l-(LO"Ls/RbIUPF8ZAo%
+%c2=,(^UE=&7&I?lX3=#L\kjr<V2S]W>C&q4[L0Ad:Y=^5HXJ/35D*M1]jRnk^6i7LG[==#aA\b'CrP)p#I?Kh_J+r&O3inVWn?ob
+%@#MX1AL@r=?"E7-#C7d!'[%K[WV$tV'+U8"^.G[g//t(_`JXCBm'&P!U@aJ,K<7Jm"_*72#@!%E'8LePMQCjXFrfh_&r-P6WQjcr
+%N(FkEMF3dtDt[F5b2t.'%p]b-?F,Vf`c3ETL;]J#HZU6boL7<H^.KB&$qEC!bD=i^?2u1poaEY$;&H=m'.?+YT0Se\D1In^'>)$'
+%Xk<9`=HqWkju%mXJIrfj-H5C;pR+$a@b29M\XJ6Q,)jX4$K40H-F$k)L;\Q2CUD594cuS4oJBsU_</6k.=8d^qK$1-NZ9mOaKZ04
+%-ko_o1SKceG.7PZapAXI'5VC\.Rr$(A(Zfo]iVuqjh^@G>*_^@J7Cs%":5e4bMloiUDY+W>gI*B%(ue41,N(,b6%(.[(Sa(I`N/>
+%+Wuma%KW%/0He/'%$H-(bcR<4Lb@e^/N`bU<@7KLYc$uF68-bNQ:B7q*r$?p&LNOU,f4tn]L@np_^)#e$'SIVZ4ma"P3.R:E8=>W
+%JQU3PCt0Z94=ASbVW2n6EO'\j<Bj3oag/i3/LSd[D,)V>\1plDNDlNo0W7;LMNg[<&jIu\81!WI`*4_i$3H@q.P;;7Lu8mhcq78p
+%R^Je"T2rE%=X\eP'PNJ2'p>RJm>.o]V^<l/-2/AeZ]d"OY\JtIEA,SqEXnH]YQknV4VG6b9\bd]`%<t_[j5f]gsQ6i>1SnCVS`6M
+%%'^(;5dE0u6FKf?2>GO<40UMn%fim8/9;-@8M$cBk!kJC=cSdKq5i;mWfHFq1Of"iE/4C15Zr1ZOUZ7Y8:jW(Tf<MVK#E9FBuBd-
+%:uTcVL_;1V>mMkc,aJ.,f,bL5FX,iU25#haJ#ETor_2;nTFANE-1\!HeL?.mKn<iG>Sr'RlA5XbN'8_G+.:b6>]\GgUt)`sZ'$F7
+%@Wk)t">9Hhf5o[+P:i(jTULOKN!1[6"(d+Xrn=(.^c2QS%G2*]q>?2I["KQ^Re]:+ii!`uP=UIt7=L&X$8@TM.17E?'c,Sd9;,W,
+%MA_WdD^kG"p9lY%a&F2?)\#XA1og>1@K8nAk3WbYA@pPUWE#m'&1,Mr_L`,cqBQs]mlac5)?Xln9i-1@kXWDr7_Jru%n_baO'9CI
+%_,*RtOgC;co)Ua!hCE:@Mf/[/o(ereg*&k<:k<l)FA8094i^"%#$%I;;fbnIW^u<;m0lsV_("DId<\h#=[Jp:OI@fM29![/fM[hs
+%/X+GhE045rK]sX&VIn('7)[a:Sl^fT&LE9fFRTop%.S:q1lF[`KMIf30B5,3B.AfU"%!CV;N0El#A2^N@I@_5G*(h$[8LOM``4e.
+%;hE=U7qPEZ-R&/I)e@10n.WDn0oMBm)@bn$]!`GR@7G5#-'m$nU(u$06eESdQ\[h8$T[g/]g;/SAC!*Z!*nCbca4=g4<&JtZ8N"N
+%;M>ha,6BjCs"FX)cM(#i+W<Z13s9X3+ET_tn6QN3$&hqp=9@MW2XX!m$sWJ#4bgXs<KQO6Z?n7)WpJT#d*TE!U1$Vm=&?_:X1bne
+%m4F14&oB$"@L8Dh,aP![a"1jh5=fE?(1IE1kR8*@,Xe%g>6r[bi>0;;6G,a,apWHV@88_V_S@a:b#*D;TIJ9h6A/DW4bn8b&3X0C
+%9;9Lb;&mIQ65YLI^C\F_#'E*OfmMm(ZbnQ9/k#k+U:Y!T'pYJO";;+od]dt5oIf\i$-rmi9Y2n[F\/)ddXhY^s/;`H%X/L6+lP$t
+%-7%BCAD5.K8+OogdKYU;DD:o5"3VnEZ"GS).<&(/XW"aKA[>sZ6tJ\/TgY72Xo@4Eo`'$*O4D1Qd3jf^f]a'SQu)GP=:?oJ+r3Q,
+%=TO`3BPh@G-b\Mt/1P.=$hT3(:l+*D'r\Sk:g[+OP)-d[YSlNnff:"dDr)I5pS<<7#`@ZLgaM2ajiGq<!8lHhIQRS(6D3l`2I]+g
+%P+C6gh:*?E1ZN85LiYU9I)(o@-r&]7'soI\Zs)Tn)->#V?H*s@][&"$5X4EOM<?nlloqC(naq%`SMdt9`\42RmHG-#%Bu%tlL_tF
+%T)Pmf`NXO7#)atN%radm"/e65CZ9l3P5RuG4s_IJp-'d5/G)ViQ-J5@4O0X:k'\Zb9p9p@.g]d'6(GP4m&7-o3Y,qT$LFF:Ti_@u
+%B(fV10&cDlHH_/D+GY8)1JuaPq[qS2?bPnMp4htkEI!$Ok<T/sA=b'^8*3^]Wq1%"I"WVp"@#H/FF]#HF_QYC1HBhSKL?,Q(8M`,
+%`E>e,\]m<_Bs7FZ/c%6&#\>hUE#[sMm[AUSh0&&r/)Bk\2%??c1^%BulHG^1D"AFc\2Bg1:fBu+Q6Jt$4'["ukp9.oJ0KOg(2sk"
+%$gtqKP>6uc"DkEs=Mi_7?>%N.\]Jcaa!JODJL`<?E,^?XZF)9na]YZM5,DlN/S:6/LY_hQ>f;2dK7GTb(F]sT3Oe!a4M8@j$p"J_
+%$#mmRO;SXfO?;W.CpE=@q+6el<jq)[a2fYZ_b/]@B=O6L>8@@rh`B-)2/+10@!#!S%_^s0-5[2:\k3*(M9=->(7T3H^t-0IZIU5s
+%buqF4i$B_2*LB<rcn%[Z'aJXXA,o_^Z1)*h&]/uqIVY=US_]5^)9u5kDY_f7WQRfaVf@$es/P,S$H.A4Za_i2gRruR)4XW(A#CrO
+%?HZe/$X+H>=g=2DLo^PI&ZM!$!K-c(\F4G^'dn$q;YDg]"Od:pU*rRbL+!BAekpHTl]V#`dJq,hW9uG^;$,06c]isf!!!b`-MgiC
+%_to`'`YGV1/-.'Z7jOnKr5`,X+*j_qM9HN?(V&51H)bU.OU*>R5bs?Gah\;3.IF]!*LBSG)46'a'l>5I;:R_5(>K"o$Xr1,=S+pR
+%0uRNt$-S.h8jJ.c>m68lAlc=h<n:*e5nLo53!c6<_\NV2QBX)FfVgSNp3BTG2Mbumo7CDa:':G_lOfKk5LD/2-I8Ki+GH%u+a78%
+%>VbWA(,fZQ/)aimUDAVXGg;7I68X@X8r,rVi!).YoG0A=1*^FL"Z<^n;>VW/9[l64-X/Jk5,)9HR'k-H@dPF0>Dhg)l"P,skB'?i
+%[jSTMNWR/AQXq&QEluP0&jIu;>f2^t>T9NH6oG2ad\I59[]kU?-"WfY8Jk?^F$2t(e.As'B(%;D9?R*1l]oho,2lW9@KfHF:bC-R
+%4F(Z1(AK8bYSEaF=`T)hPSdB:]eV&Ze(?]YjdlUr-<9.AP%9C@"9gTL?d#)n""V]_SPM?)q,$Es/N=([3u;15h-NlKTlQ1<gh.!i
+%[f(pGk;EP4e.@TA)tkFqV\JijeI(\7PZ?C"+EtfLI!(@mUKK6JLD.@fRCVBh:-1l\"F+bHS-h-s@a1J`>#k+o0*(8lJ0u9CYrB,+
+%A]K\Pr??=0=S.>S5ec5IL#(%s2S@2s)iJ-Y2Csdl)WJW":&R`V;!N)PD"c`61b@[8TV!EnfmT?+@qTdTAXAU3FjjA/C-rjX9F"U"
+%>ILIWaZJ0F2t0:Zb>*@T@`+W%d4n#!h$grag9SoT5^TI^];,nC=k>.<XFWMS>2G,RfQEm!hpcVKbSX7/Z'Xc!h@8fq15^.*$H3l/
+%9<Zj5dPg/m^F,7c?RWjk$%3gS7A_+:7UL7))"Pa.6NnZ4SO3k0VC"PDNJgLE+Kr(_bN.#f7@:iP'5,DaL3l'%8ZmX,E6<D7LkhBe
+%#!OmEP%uIep_4>KoNk<63@/`2V/V`IS/_1ZOg8;mQI&)SM_Ogi?5?u)'>[`6WQ")2asjsi%!+Ir-WPo!0/\/uhNC?r<WT;pdgh5M
+%Ue[O?+nl;)qg^Hc:lJgPh*d$!9b_d#dmO@p4cK',KF6q22KC.qE6;5gbq(=[:j!)8"3Oi2.$0E7Xc2ntOJa:29B$g*(rN%_F9l)5
+%Ym<W>&JH(!qYW8PD4#GM]u>SZ2<D>,MZS\l.@+L8<-Uj2)lB,#:tUu)A\ZNQ*=8NIkuoj3/Z/W63h54gZr+]I!]F4u?,GfUop.'7
+%P]P+tB4,`1.-KiGFTbBD0Mn^XPOo*+r3bf+k_8[HlX58@&DQ+[nODb*kb'tYS9J$S=Qr3U2]$bGjkgr*0+fS.8T*51GbdIDD.a(%
+%,tNZ+/lFU3Q]![t+rMV/XlM'*B6KQ%nV37^(`[^6U8Ce.)7&9^0s^#:)F0NqPqkGE$qk8mBqefmHje@[E16!61_:]CK\=C9b//^8
+%gd[DW/Jk]tWi44='5&Z#2#1e^Q#*X+P,1<#,:ea;K91dp)9OBqYmdPKPRQTXN3*6EF1Q269BKiD37`.I[?U?sl-QY*m+K&+W%cDd
+%j&-hnhOXgJ)igIhq6*2Yn&Z3rE`c&^hMWrhh1uuuW]g*J%J($UP4WRXDqL6t$q=kO7Pf+eK6Cof855>T5#_F,<Os.65Rd@E-4jSu
+%JoIpE-JaoP^!gP5%OoH)/$L@nIn])6p%r:"0Xt</cm+m;Hl+2NVOJT;A"OTmi*#86J_B;:"#2Jn[Q(f5!HJ=b7UelW6"A'2f[i+t
+%6Wm(1&`&6(BFXq.hEnL6*Gs\RdZE#JmD=3!B,QJn2B8m2!8A4aG&FUWAtuW+X`GmRiY659k9OVn[M$_5ct5B\_f:rU<r)(.Nnu65
+%N?kbl-$b]@J/Q$gcQ@EEXMsBp(<0r0S1Ts5Ms5Ig`fM75d>W03EM>\k&<T\RQ6TE7G)+"K]!3[CTA^5ri-HRWQEnK"D<B><+l<_s
+%\G%W8:uB8sKc\ZVNQeD=*nhd+MHH\ofP]+c4&k[cWAguO>&sY5poFR!6CMI[`X_;[9LUb/S2'+.`c:*ZN!5g54U,rC#n6QsWON"L
+%)_c"4(M;Tara=W.dUgiWgZpW\YjB?7T6t0Z5-f6Yc?>LLA5=CC@$BZe`j(88Q6hMJdqZ#9>LJH<Uh*+N,>[1@CY?n3kM<e:h7sf:
+%:s,^l5%[of_/"\s-.4cN:sF((RrJ+_bq>`3JA:1+>gQ%h5t@c\9Uq)$eDY5VUAKa$8b:Df%k(mF5;=Z&5!SRg.=1V"+2oc>C#Y>F
+%Kcs0<C9T%?&-^5A^r2#+Ml70(d0YC!&9]LlLPnP@QjZNO.k"DkN0Q+k*74DRX'+Z,fdc;eP@=Y]^(AU#lYe5AgP\HHcY_N=g\l?-
+%9SR4G:]aQ"arJpMl%"DXKoo-CQkDkLnO^`hh+W3t]'(UW+0.#([W$LcX0OE>kq[gZJSXKj=[2J+QH"M(2[ep[m5"!t$:<27pBcZX
+%/G5O/bYXZM^_2XL,G5iIXIgc9.h!k*S+n6SFT@+X!_f^af.\%OeNQQe0mm3CGgUd(R_ZM>NBV=LM*%k#pV_[tjX[n)dqInWPs.dC
+%)EA%sQ=IG>#R2p4BOi6[nYl?+q[.*<Um,u:5<^21<J)Lc=ak)\Bo2$D+]U(5-5N@#EU<2?X&aBTN0a:TN)DG$\a#oR/5VYo,aQp?
+%!(e;FTNP*#cKJ<;9.-$,8[n)k$6#RK!:P#t0F>oj$K*nA>?NE]`0M$nV5)6ORbCCjF)&hXapCF(@iIF:W+^9!FL!<-0sZJ>"f>dS
+%;T?.)*Ot<K';kpKIBLLKcCR8:*`7788]j);\aRL1MI#dADsikEIP5#*Yte($s1nl;(Z1N23hH!'pc&D;3HBN.+I;#YS%.-lfU*MV
+%3o6Y=4]>d!kghi7Z;02'nQ^r#ghVgU.$KkB\n'j,@,L8%n[+S![3j$Uhoan]1So/1eNkoEMZ=dR,?)EKpR%A*l9a15\"E5Z$t[p6
+%3b3s=p$ANM\tk@R^g7Q<]I9OY0G<#DH+Rjam=X-+;S/:,0_[#F=SsW,R.u8UACqZBF<!n\@4!\:7Sd>pVhS&a3%Z(NZ-P!,4\;:9
+%4G%heIAUQ4Z`I>]E`rt2&Ai2ZPk\Ds"4FOMS<T`5gGi">p:2UrT>aTa^I8i4Xh;X\>d>%s](OdbWL0V>o9(gmA_:WLe7*A'aX,t.
+%a$]Lc-&3Aj]7ih]'5&]$2#3QEcJ%j[PrANa[N)g-ZeoTBJR,)erAfpFq[UPSZf8G0J^QVr5I,_R`cB@qf@&q5idI%.<hAA-a2fPW
+%[n7VsB<mg.>>"/5Bt!--SXuBaV:@hm.VpL)QK*sNG-^JgOQ7YH<Tflt%2K=e:O0KZoQK:5n$B[3`'<jBgMu=bBBRVA+*J,'nB39O
+%,>1B-H.G=q2J1WIOVR$FdW!YJ_eo4f$JAp^Ai]"R3(Sr1#"]/HFN0ZV1qaZ>(92#O:3G>%/0DN9I[3![B5:)0PU1jA,hag1X;HfX
+%lr#U(H]>,#N$CAFNU.MHQhG,7;RSfNWE:S%Yi[rG>in%H>f(n-BhF6j/!%"bOfVfBnLFcBXH'!7*2:GFCsdr2cA,k?B9Mk[L(J?`
+%a/LIjS`CJ,@\=AVikn$j'D%SLBmoMH\h*^DBs"mQJ=)d)X2&-4E=C;Q0d`ogSGJHp:ORg$iDr[1PR1uljQIKDCh7"Nn?h[;c&$F'
+%['#63pVi2N-A3\9GSr])Th+<@fG+'^'<:\,1_AoVBHTaUR'gj:qffkGDXHYUS\7E_QJ*lI('rL;%2^^O\'KG\;LjSHH2F<kC!c(^
+%-Cb4f/1)-o[:E+?"ug=^itK*o0q.l*02[[o/<A@CBs!_uR7q5I@RC0)pjaOHlkg5fN.J;OB^_H@Bh*1f]2Ugp$]VG01Gr9:K15lN
+%B-Y=*9QoRH_MF@$BbMbTO]WplC&)PaI1%T]%LciQ.Q#;Z<5<`)dH<QUqA@P]["8?fSPpb-YLoqEnk.(ucg]]1OtF`"R/32M8(3^&
+%:Sk=/n?MK+62WHt;(1D!,bsA%$1faQ)U"-rG#dI6G&GOZSK">;CbeK-fEu/;7ZAr04`/Q[Ygb*`3HjtN69F9\QM2qiUDT.mEjcuK
+%\cpDkR\Ls3_r3uA?H$%^lJR4eToG5sf/htrLY\+lYAsKJNkn@0W^Yfrgl'*sR:NaN4*L6kiOBpX)`Xpsi@(hi/bjA1;6d=5:%M-7
+%YAIuKbe+^>,HUouorhI;9+ejR[q&\dgWhM-?$8<2ZjAGW0E`XG*ufA5,j2sLgm5:9&U(LTK[pq3+!D_R`qJ5KD/i@Rm):.EZ.#l-
+%YmaPDn<1Y.6@tT\3J>PuDQDekUpA_^@H_.sa2M#)iX5-6;l7(A43j'>mbLY"@[&j;E6\bO83"n%X6q2Gi3JcWf1MRUCr23Ejd@62
+%.T.TJ.+3k*lh@>5m#/f]KQBo0]iu#&SaL(-icHgb&XK/AVXl,=:I0PVP%K8X75b0Wil&Vco;_5b9`RlY!R>GCkmZq&?u2!"B.EM,
+%"D6&4AE-8`[jDat1_%RN?iZRY;0\J8+PO8QMlcQH-\A2C;iAb;EDlLdO_Bs^o;)jopC8?5`>Lu%Pb?D/Sb4_A8"'_XBoIe2!EuFs
+%X<>]jGd]]!+]KJP1B?-"r.*gTW[.ekER<_/+s$to2mcDUQ].dmc(1P$9tL^KQft'Z4(QDFhB=#(^]P$(M,Ig(W[S0d=U^*'F$?Zu
+%VYX92aM*0J(4ut_.!3@K1)gH':cQ`2.fg@4C?V(7$O9L!R06>W)auU,0[\nE+t<u3VpnNeQu``k5toiZME7\c(td_'63!]FIP&C4
+%5\knD0W9NM:=*ck'bDB@g1&L^/i\8?c3de8ba*MnhHhI&1bUi24Y3j$c32'FQXUCLmZ8n4&B,(m$-!<P,BQS!RG8usW8a'cTZC^m
+%C)?'M\stNWg6#Q('L654SRmLd4Jj@:3:!jQ2E;H'j9gH4c3-$s)b%?F4NR)l1*=sYB4eP*nRihsCnFI&$u$+J[c8irh81Ol?O=`,
+%T3-P@j@PYU=h[penN$!%2oJ/L_>Ph>&BAlt6Ph]"lS`lU#mIt/7=GB5Q8fN,S/Y0:T9*8<lm@ck3;*sm67f&&P13?D09/@D+C@7$
+%AJel$0OK42>k@9+*aT+H_LiiL[=VkOC0%%f^m(E*U6DB,KHo#pqIkg`;Tk"9qPDbLTs3YmBI/+dNo"_*1ECK/*f9KgeT%l<:e1p\
+%A.Y<,0W7gA@U*(c0J/766DFgm&nDI<QR6C1j#H7aG`)+.>k_2_i=M@Y^1kGRVk!\4FYT13%,V+XZ%PX,^3$/?#/gqoV>$4#@sV?!
+%&Ogq0<dQ*Di!fuD_Pro`E_P9;?'XfW-cB!;Q'#B2Q'PF5fQcUI^kUn)n`"lR<)ti(MM.>$af,nq4VUt-+0,r$("beX=\DmeJYs2B
+%:Ip=YcL[uEa9X)7RtKl=Z?`J#%Hap@0(Q&U3%P<0:X+0!''gFtmhpF_0&nK\Z(MrZ</P=gq&E4fBWClucm!$:poEAh,rR@613b@c
+%X9*"t=Fb+NNV:"GPRT#ITh7d77V]nDL;59":1@NT]StedQ;iHrKjY*ogM\ml/5j^cNT1&a#dQ0g88P\i-q:9fIZe]@*'B9MN$Uk5
+%(l;Z(Q;Laj@b1s1/Q#blLaBIk4AEYV>#QWC,+`AuR,_rgWJ^mt=[LCnfKG5b:6&WL:NN%UZG\$7.;iRX>=:%2Mbm*/'IKaIeXY)/
+%rU:R$L;3qcmLYd/e1G"`#pa&62t1)ZBaK/gN)0i<%D2A/(P_=(d2_2nFOj^M^m@C@_&"t/G4;oXOH;+mY<kdIk[1Kg]$2PO/JO'h
+%'OnENXR1s/Aj;b!T?pM-@80W:igN8H#k8+f1dh1pE39b&+e5Smo*+b?#ZM^A2Y7tK(5/uYR);o27B[''?NC-B9TSFVfm?I4fYu2I
+%iI`;^6hoRPYd5c5P?-si2R7_s,r,C$YZY^o#hqOho>'cFPVsUQ(R2,aIdD[(KB>lJYp-8T,$'B)(JH%qR:dcb5sjTe^6*E$1B.Z[
+%LZ^\9R0689:)=3a:*6O+oPJ):k$$)-iNga$0N-%k1T"BN:Pk/GeRDEl$regUdR%=k/HfN+l\o94:UJ9Ko;/9oM#S&9)$5=V8erf;
+%9GEp5-SrGp=_6s$5_g!2,q@;Q<MHIg&nNaiUA4k$1Y<KjkZgZII<?0?(HRom@=dAS[ZiMLP)>ZMiN]We$j2ZP=]VE:`iNiX7AFI,
+%q+M6m"o_>-+bmlKQk4RLM%V+@=$b#5j8^'ia>cc:D_f8?UerD1F+2*&LX55s$??*413)]*SD63]/$#<m_bAD9s6hAfZaaj6Q+0p?
+%AK5?)QUi"7$/GuT-k7&Wbts6DPKcpH+$1g)RGf;'m7O,(jt7+GRFNGp@S$uNjA<6:NCZZ";!"XS+cT%0K+d;`WJ;A#q*5PcTqCL)
+%,"^^1k9apaA_1D'(OSiuAA?db-g,j%*;UlnToPn@h"g<JXs]F--?usF,!qAWh++g$'T`[NLJ-,",q'kXn?OaU0JC\/g&/:Jj/!3,
+%*NA2NM&nE<;TA=kVBcojPB?DA3RVCs]`8NNP9/3;"Y(?F2%4&Nlcc_A14X"Lo$!,#TI<HTQ7,CZbMa\+PK6DlL]U3N\qmg!(Lr@s
+%V^b//8gc/V/iZI6k.AjMB3)JSIHC7r"Gsj5I(I2#!R@(sN#AfYULr@7@[)t06V&p.r6WK#o:1NK7#+PE=pr7,E2Rg%"sudfWNdFR
+%VM-5Pc8chJ1ufu1,=8Jb=dDB*WN7?qERY'A2,(R![k[jeO*siU9s.%iS"sip$jS[^R05E.:@2C4['Pm1VI+.o:3if"Z01ndime>[
+%cT"&m:eA\RJ1:u/2#&%U(4[9a5H7!V<N'lVaE0",c?PE3:R6Kq5]<PJS%`s=m*jl\2l=EJR`<YWYE]?2S$]BC]4EA2:1.4pVl[nD
+%U;`fW*2;2aR!6tiEjchj#7)KqJjL,$H^KR<m!p_,b3mUpN?k/aF9W'H&=oNYVT&g,dJ(RC./I?8RF2s!?qnchTM>&R\_"3db30DE
+%3E=?s#"8h)&m6V+5p@huJR6YL`GI;'X/VcPI(GgsSC95>83p%J.`4.jEe.RHNpXDR&k=5GQ8g'+=2@F<Hrpb/Y*o!%*=T%PimR0@
+%(h,4uJ7N.L9*cDRJ-Rl:$T!?RAnP^SKX"!Zp?Es)p5$-A1pg+Z%.:SO=eQpLVG(:4-`)$UQV.11PY(e-nBrNW=VS7l>Xn>7[Vh)n
+%72,W?+IcNFLQ"1C`b94N`_:*/e08l=d5ckI=K-sm#V.K&90..Ie.rXh?q&;`N4CBh6d8%!P>F'_s%5bAVhDB&8nMrUZ"B2_BuTea
+%p9ZZHF%W;Q>TLYV"@s_D$6mQKWD&6cph>TJ-4DmZR5U>X'([B.#1?Ik5*Rp=b`aGX"ho+;VTn$So6J7*/_eU+T!:W*.Z5K4mC40=
+%C%,'$T1Nja!3ekZ+0-7?W(39G1rJoWI*o7FN3O.3S-D!N;2_0jPm1s-+N'?D-CkN[/'Y;PRt^/g`9Ym&_D&@6kUdIT9QFRQQ6MBI
+%0#nTnK-r<<b51%)9F!MqfUPiURoGP1.VY`ls)6_V1WSU_HZS<PS[h<F\a*ju(O(YYgg5$OaddWskCa\*`WoP`.'tPflA7f.A_/-l
+%.?V/=PQ7:LbG18ZA$SJC#J'13<5uT1IYHV0b'(M)rNU3R8n%F&YZMYm`a(c<o7&%Z/a7?-D"cj$6jmB]6s&04aYn,)%aWRjroejf
+%l;t`,rUW8Ls1\9cB!qVkK*B7Qj+,[sdqi#OHfS00rT9f#\PfmND;X9Gek_q$6(QV-n:Wh?U0eA\Nms!iX``Tf/T/RO@;FYB,(4$I
+%?4gp3^/4[r/h-FOPIS^?4)coF2RK<E*G-s\HYh=n7+ll=n(fYhY)jed(.,7P5atNt0ZR**@U%<FH<2=CFkjq95#BoRm9iF%Q0$25
+%Tl@q:2brEWltWatH;,#]mLcoi7lA)s*]rSB'Q#<@lCQ63"Z2E5h8[ViW"louPL%P-E@l:b0jU1BmZAN@h/;Lt^0A_kP+3c]qqhmr
+%3aI,O:)QhQM2o&l'h'hA$UN^KQe$^3?:b\gHs.O;bhre=64NG;4%0Q(>'LK*']uNZeN9!%*H90f8-U@iGU3q9\e_MKOhaXfRt1VD
+%V#p`p$Io:Z>LM(HqYOpAiRG6,,6&;D(])gjUt1nD(_6IN&0F*V?=A9hn_Y2PUF>&d[4Lf?D34p&e>dRR_ila?"D(Gl0XK]*"Yu_m
+%U+ckqU?YR%;.@&=P6YZM:m;7LFOt8i+F\U9O2KHCpfsdp((1G<%<B9D9Y56f(]s/eP(EX)70>^r9qZ=<7U;nsa=fbB^nmV-q-];7
+%"9]'d-3sl.:G@qR5QC0'M[2a#+q-T-LjY#Cnle@/J>c1Ak0D&(5U@s,'Tj)DjAdI'R_Vhf;No$O[7XCdngIDVCPeh9_*j\/XLo+e
+%&0VSk6R7D`$P=8=/6HLPW[JM!,#+:_*9;jO#SA%C&0a(872-'fNTgI+b9f.n7uTg6Hpc3S\9s`79'4OsNjWVMlBe0g(fEcuV2Yj_
+%n<8m)P6H.d:<Bch;FOcU-LgEf/^VDG%X)9^.s7Yc;Jo""p@=eAXCC*,Q2W1CIVh<X2'+78Hc]uq_btL^pL"A[]$1r4A7JfsOF)86
+%hRo`Z0nBeB1%jdX-C'-SqBBLEs4i>LO4k+kPVpOf5(Nm(5n%kkU%9IKW$*l(:#R.%_0)SJ9K5VSl!l-*p:7>rDBE8['.e-/.1?++
+%j[E96M%Pa*Cc7:b\ioqUJu%RK1SFl)a8qG7UUl4T5"KP,cgYg/]$t-D\R!<?[,pR24G3*l64*^/(G(EI<?gl@pY7_+%":]:ZspXf
+%0CQ=/Z*lW!N_p+Q_[458H;'+BcmLg2ou(:8Y(.;.a`YU[fW);5abeb=h5po=muh'aG!(I>Te<eTFWk!j^IRQ[?_e.qWuY!hq!uI?
+%?[]?]D>4#.p;8gj%hH_X>Ir]3J%35SP2E?i[CuEYJ%b^PiVr]&naiq7F-"rTHu]o:bk@RVV7g46KE(]'I,SF5rT\U-5Q,B2qLI]-
+%r!1)%KK;#F@Del:YJu',rk-5Mi@2t^JfXX,Js`03J"]btam\0CPgtcnmopD=K'NAl:uSuqW&oaF:Bo=0f=/fHa45Cc2[$)?*n*Dt
+%SU>\-?T[gUK22^.Q[Bd65V?pH'MIKjmmp@@QR-3JrE[uTK_<q"0OU?RJ[rXRZCg\G:(+6ToI,2hTg'X:9Hu[tpU%U;1Y-l6_!JtO
+%oajjIiHZp/^`al'=+G$J+r@'Z^(W7h1gR'R/lmU)JX>Zj$B7@)BC6iQTR>'H1`]%UXh7T_n7=Jj(fE@&9rXF8-8-NHa\':5JRBg9
+%I[B]S%7@)g:=\Bk]usUf0B&%M@0YW+E.V,dP>Y35L."R_.TM\pj>@umTj\MQ,Jq@mNc;q'[18,W(/DR3BiE]cgI"&2DFnr6nCfJ.
+%A4qtCaGL=9NXi0/q\kM^C4YJ5r^gLs^(&[OUc3`q$<P\MBZtIX:Z+WP;a3.ufac[!geul?VGLs%mC&du0X!@1iu<=:`,43DD3"57
+%@s6>3Vo+D=kUs(5TE>p*JAB8A.#T>NT`[Nr\JnfS64Z@qh+0fhA#R53%?Dn@+S;&i]bqtN/-DRN"g9!S#ji>`%bl]q2p=PFhuJ.*
+%J:MLc8M18OHp8qJ`_V'`%#O<^#bDL@&AUG.TE(a?h*-BV!.IGmA,^f`KK0VeRuZ6BNY7)aGQ&Vc#%tZAoniN3jrV)lof,Wk:!;sd
+%T[NM3U4YNMN7P6\n1C>Uf20X-?Ak36+U6,>H*h/=)4GFlgUh"G8(:qrCRZ*1;.m*LqYRG`-QE0@04AlKJc^2Eb522U#"lfp%kLf_
+%?Y136635F>P5,G!!9IgEF9=-R\GYlTE%nR((nf/F_k(7o(Jl'sKHW%&f2&c,&2<St&g%92i,[4(NEK'q%/B\($"2C`4!UiN"Ukhd
+%bs<`d[,OK*A1.TEqb__*"ub0rRJDEeDbF?pgW4pDRn&P6RWVDj,ZH8i)&Y0aW.d>80\>M2idlpF@(PQ0T?/`74f1="cKLMPQ]4.u
+%O=)W6E`G%\DsHJ:8%>N,n>+3GLs5M]:#N`$(dG$c&2Q3<=r'4a3/F\\E:+uqP*6Z3[$7gd6W-q,<E4<jH"bQQi8B&D(rh$aH"9d)
+%AU<30/9tO4l%VT*%A7"WmYR\@6W?c7&\)YCl0'Jbk\o5fh^[`fDKt$fc,V2p$HL7a9::`;Sd'ktOq)=3(U^0d7//o/]Op)sZCm\g
+%S,ejL2,+Ac-bP]09"D)TcRUPi@!-/'GW&%WH+63c5]R@ZHHGM$%jgl'M7i<QklCitDbR5,3DW5Qpo.poRK`Wi*4g7(TWJ3,\QPF2
+%GQWI*Sf#'nPuoB*n$p?51AQ<!BMY[.IaGZi;D`Z=-2K$7J!Gre_0:0/jqS69r%+25f(_Ti<[`f#I4"IDgJmd<-pB.E0,;J"9O%3*
+%)G'G+*c*6'?jb5Gapark"m@1)D^(/OjB'MW6%4C>K+Ym4l\'7XSkeP\:Rc*r@1J_YR$BZYe9>?@':P^hj&[q;ND6d-aqMO%95GQr
+%np<(tH%I3:WlLkJ*V_a>"!qJf(6/o%%?H*(AG)/L]gTjBL%lCETKRt9EAp!1)Z(SfJ_frM@Fhn1;8C''2I].ld=s[jNR.ks9YX(3
+%+jdPYC>]REZZR8%UQ"XM*&+VV\HN+#P16E48VP!]kk,L[kOHWCn0H8W%lY_O(bkS#:'cF/)t@4t:a-:S<X#far1j\;:Kij"l'L>\
+%EOegb&_KWE"b(G>Ta$QX=s-@hGLUWAPh-MTKCd?"nebtmAjg^kHndlO5.!GFU!le$9jQN"6#t,k#?2Gc.N_i-3$;8Y!k.]7(6e7o
+%WZpX>0IZuI#^H&;@2?m+Lcs5UfO>>p#!_9Ia.k2aXO7;H<tE=ZWqX;nK'Fe5JLLg?8EhY_"?7doiIj6SjNn)u,eSo+(3EIch2.*V
+%3*tCNp"c6p!0RPpV`KED)]%H8dk(mLJHCF->&R3s1re]Kd\u7BX@Z3$Y"+!DQH]D3#,oS\!RGt2C>$^O"JF7rJ5b;J_qYk8a*n:B
+%\<d8rTPa`dLTnMo6^9,0LsQ.>9#'FI<iLSYqVfWJrN@aIBB>I3/Sqt*1k"E)iYN+gr\KR%ocb>SBE['X!N9Ar:)2,kW5uX+'S],c
+%&ZT`rNNWAh.Zc's$D8j5YM=no!Z59"U"p<@bk3L'St+t0&,M,?'?E?*Gn0BtjL$dj7C4r2F@Wn'rL3Wc30D6hHA:nGPC/a>*Jg05
+%FWc)Nh9Yj;HtFWRCbW[g3JmmX1r*UPCA^4ufKd+a<:\qW(7')@pl9S"](\.f0Pk^ALu-)";GBcL*i@Y%l-KaM#Q$TM2DE`S_q?2`
+%N6ncI[tCP;?8Z,";ZI=hn\_n7,OFjYaqje&7Yo,K_h[eME`p^k9Z)9S6+n<R%4"N]B0[S*k/k'/33AktqZq9KenM>le%r1t!hbRL
+%CC22'Q%l[tk2VuZ'Jg9U5YV:GZ_?Z4.)b(n`+1PX!N^GGUPWJ4!7m\K/$#7FCWIkBMub%ZAc;^"&8[Ke6c499>in'B#j^;ch\/LM
+%I-H&h$m]j4D/7ks*glsa/V=n7LE#0U$']b-ZNNl&_&8o!S'QUC3,?71V?8rdK2k`_#4ct.EYBksIL;<E2\Wje?Il+dl6289(=BtL
+%j$ZuLp^a*n$$S@4n?Hgt;9p1LiP))[492,Y%gm]]B*W)LRWb@!<@ND:*8OT3IT+M*\-[fm9L`IlKW?[):g^[;+>9fWC20W2?oh$d
+%+FjrqdL>CQ)"L/Y66IUZJhoGqTt1:`/^Wcd%Q`l#2'F#nL,_R7bP)DfFS(p*T%A,D^8#M\!218MY8KZ;b4cI949Gb0!1c/9VKn7(
+%`*1Y"%=mRZJ=f)?Uo58`ciBL6i..C">VTX&%f(sfYso"EEJd#]EKr6l6Ik#O`'>Nu#bZ.(:^.QH#(SQ&,9C<L(-<@@:X#aa+[Yo3
+%Uh0bi1m\5a)L?PpgO]DcJ-W6;nY(uEh=)cH`IlES6kDo)4JU?S%DuS(1^Z]e+AIZo!$`0rIUl-G4ddS%TdgmR(aeOU*2"t/Z31m9
+%'9Nsuh6pC&6a1(U1HPTN#"^8jj/usQD3PBLs.1!*?Aj\P*^FtsICO3`Hi&0>Zej0R%3mQWUI%)>(N3fCnF4)&6@06Bp'H*np,Xqt
+%iSfF(9>`,toe`rT%q)\1<<*q,Ekq,EHR=MS"?"7XL(PsUi44:P'6h@,\E+sFd$i_]9FlB8inV"a\7Z?^*I&9<RE$b6rf_]5Qa\59
+%L7t"=7$N*1E8P^hN:TNN1'f;k0Nc!.]MA`&\.hSejG@tHmKknGC0I8B[*dLNN`8<#Pd(]d#XjNCgI^4@0"nD7)`'U4Pf+[G?A7>2
+%95-)0cRlE!%Q&\Jjg!SrHuPJuAUR:MZ>e^J;&^oeRP%.H)1r`Un\EVh]5\i!gph2LeRgo8#!Ogp-<'\!g'n,Y[!e#$s1)Q\Z3@+g
+%NDtJ-V*N54_,rjp3RhUX7(E$4QJ<0tWG4a*!;MA'ei+U8"lgOk1*O_%6>7cBJ5?Ir@M>@7XMTB9?j)(-I7#M5[.)[\>X^RUkRO##
+%HJr3L87!V,)N.#M=j`n<LCO<"BaN]B9M79E"f-I;GS^_bXH=BOLAqo#'mbf>PH-^7!k;1Z%7/cDZm/"Z>VNl-&W,1$h(suo34pB`
+%EMOVu4`3&MKUaXhSMH,DLg_^%C>/9JqRYd2"/`lL<$_j0\f_h(N'P=CQ9"LO=:Lr^bb"<_Gro'g[mPIa$[PWD=rXUi-NOhuj.Y^,
+%[SpS+#aH<)155h/%Hec;fHVU5?4dJ;%&A%bqcLndH(+">cNcm`a><tZ6n?8_#[#&>/Lc3f-Hdk+G?H?=cDj?AmWL!"4YN0gcG6=;
+%5kNYc%L^_$.O]S@XZ-fj-3m#EBMBcI4[9SMDus3$a`jD?G(cfsViAb82n4C,M'nEm!8f#c@#kZ#>"]mg`G3#0n&SC\PQ[C[K[]ZP
+%\WiZn<0Ncjd=D?%XF?ZK:BHQ5L+WQR4F+0Ie]'^Ao+dcH$A"St=;?o%bQcjcmPkeoMEi(oO1lXoZ/ZK&W,ij7#[jRAB;t/^fI2b:
+%,-m2qo+4oQL@0$n;H&m9FKi&ieRNG6C_O5*MAAD'/d-'I@RHf=e<=F(_u.]f/^`TB/"X?c\t"dY.G&36q.%[MD[:8kVZmEJX?!A>
+%%MPT@HsL6I@A"@AMed^]9FY!,LGclr$Z>,KFWrr=bL7#ub2il*QA]J\h9:`g3.anm0;>'^bDD,f8.8n^cmpAZ%m5C$hMgKObBWY4
+%CFHb)?ch=u#<d%n7A:WF8VR[HJR9XK&Bt0DZS+h3jB.^1_7p()0Md('BX"."">jer3<,d,jq/I_Y7Q13+KI;u_Tb#De5UL$dkHsk
+%[K5D.1,'EB.e->>3286/WH^XW`l\D%AuKE@NL#:nV87]nQ.uL@E<L6d\?PeMB/YF$rgZNtE7TnhnZ`237_]AqD6X"b0_5c$O)I8g
+%5J)@k[Jp]+.35lqOWe[f!87b&^^u=eD2;>+#Yl7WJ!,b&2Y(@6RMQ8k#%4,E<E9G&@fSuXTDp5hfX[7ESl8M[?2828?1nS])i>Df
+%[QS86lh>>4N9G+H5*.=Jdfcnf_4goP&fR!hciWRcA`Eu*]d=>rUrHe`GopIP]qg$C#ClLMqj;t(#IM)%RNZ7g>%%b_.LW/k_?OH/
+%gB?%p,ug<lhe'g>c=W4Lalg0&KF#pU?,<$G6Tdm2.eN^&6ss4c[G;]QFI1Tm6U<QbiE.Zi?[VjLcj[9FbV4E:hZSJnq83X)WEm7<
+%+D_2$r*ort@9\:;);%si`0pML:B7ac@6j`[\=d0idtEl<6\Xha:u9?0WL6$K4@f$%^)gG3S-K*F'/mhRmd28U^rI.qZR5r-$_Z2!
+%liJiSVoTKe$<F`'*<^inVP)Z4:t"<4M?.>jPX"Z533]2t&_''G4PZJ(O"D2Xc7[bb7L4=a7q#6HU0-<5:j]SZaVNcDH5/s]X>"ET
+%oK_14KY4d_0PX2-'*RG&Q69N<c:6=<@>R1/ef,Pb+<]7K2n%3:Rl&32A:G#O7dFIg[QJsH0`g4#?=PrQF!KuUl%pN)2k;Gs=@*=$
+%&AB9[**kN)1hMiWjd.^8NL97o7K@t)+!A8reqL,-30;krb#<7![\+_"it4q-:I1Lf$dRi$_M*uDIb&)kci@';k(Y&5$-sSXWK5FU
+%^l5j5-5?b'I<e]:(2R3arT5/j[R_OMq:NPi?!DTW?\\222Z>fuJidBN(W&Fs0[/iW6A6#boggSW]sr^uJM!UA?sD^O1Fue90Eq/"
+%88`CJ%Z?4H.9[+KJsRV2$@^<66SP5-3BS_?69a^rS$@n&^26.PQ!On\Tgh!/183b64T9CmDhHuoKD[q-_mITIHmlcGp#A>J*Rlfc
+%Q]bku7g"8k0ZNft!!,KhU2:)g=Q=ISXfY<K'+T-tX:s*.BoM/kFI48T.7JhM#2Fk#3C)6s0a@Rg)iu"ppGuo&:]nNZr`R89*n/;?
+%Qb4NtD:fAqKIo[HQI&3$iDU=P-)KO=38imWTGYDSESrb.64R!mmce3i`o@0[CD'&KnsVH@e]Mm1+Skpi`b/.GUk.RD3=2<g(T)jp
+%0bsRFbZgbGU\jUm#5OT?]a\^@&)(Z066b,#oHhnX7RSU^"aBC#Xq7E!7,Ys0.@WYoA6j^ZQic4%D+H5O2=M8$e)Y+11'fkV0E%8n
+%[h@LEd1Q!Ja,ShE4]tBAO"<Bl*?k#>+BbT1$sDS:5]6a+8G=k7S)F,7'pdd?#tn5+X"RI;5*d>fQ?&Wr.Uc3G0:ssQo/7j8VEjq]
+%SjAYU:d0X7IHY'0r4$$"Q6<:GG=3>#N_-676AH.TB:FMC)m;)klUD8UL*7Pt011%)T8qnNpLi,HOde+^n8rCjPfhH@if=YfmBhSM
+%cZt3X,H6q$Ysldk+d7@@Tlt<T;/h/<WT5`:iP?W-0W:IDkkToHINk'9^e"uM_fD0+X%l`"Te2^Un5bl)^.39$Km`837r'S&:&&6t
+%-k?8>GUeI;g/q*@`UZ8uF9`mdE5N(d^\<mtVG0?Qp`<%__\@JFlXn+6`g*fm4ENbCN`2@BBKAPRfs!1RG`&F;@EjbkA]hdH)%I`"
+%o#8JKFh>*.&`$.NYn9<"\QNE4-QaD_11'6`q8'a\*_*5)9Kp*Y#R]M$*_ANq/9%_F]k)^X]e:c\<Feh*?X/Fj1f#/W\(se?FE&fj
+%r8c;F*WVK>lrmu?,8T92.OL.PRiT+k*p@Z%D\Ecmj$Z'[XF\0C=jtAUL>.0s[l2:uci9(e5sNOb3.Shbq(o>drH]gU3ia]7VDhk,
+%_ijj/*a,32+l:atC=7&dp`h(F+O\Dnb"'Bs3Pk6P?X?lq`ReRFjn9_M[<tb_!Vd'i(DFM<*VUEQhfC:a""Wo0?#Iu!J#Ak+Hs-$d
+%GI\;JB-FX(V$&c8a]lSY'J:^TMeGl(+e/WgHYj>sbXAX@=m,-%@uVTY?Y;74Q'G."s4LY&/53hslsaP'^OmQ\I,30D=dTE%b>91&
+%P06Z,JD]d)e.JZ[V@5``1i_el*TD+.r%0s\L_>f;$>5<gkGV+'I^^+-dM@b=MR,!>%e]c9`FHN;`@mRZDg`Su2BtF5C%//e%^#IE
+%8m>q#(u1tH9obEVb.&HQ,+asYCM0f)`\h%m0-O;&7DTRN/(IjH%4,?AlV(S*gJT;$hA?,#r!#=br^sErZ`8Q*7oM$Z@.<]$#ZD;a
+%T)#==&Zq5]#fUcU`jb_<9hD+*%%F]U0UaLH(s;!72M4Y4+`"raI-*4*FZ3&#Bu#0Tl>8S29GC?DAq]&fE;19p0NSGZ-_E,/1VfIa
+%0TX[[9qm76!Oq[S_8L;4`=)&3fkHCE4X"P^K?Js+bSr*i,I2!7)!>dhnG(@rn%TFm/kV$X&6rh3N>D_7@q<`L9`eUB<rJ:O#P=hi
+%-(_pQ%5'Rea.0BE#4p0`,HQf^`\&(,<LMAi`Lc6I2I+)/cXqIt2XP?Zrd2p_>!`]R=lq_#P"]X;D=ur79dR//,7OL[Y2DO\B2h@b
+%j)8Ra(?b$o:RM`d.G5nEo<H52ok7;JQfMWhO:o_la*b,4nTg?.;4AiX8r+Vu'X.89/28A^5*us5To.>+Bo=Y75XtS2A,9uK-WGUD
+%B:`6:jF<OJ.P\&02:Cm7F\E#RdNfkk4jCHAYNbgBGK*jhbpj3u;U0q,<ibPP42eVE'U"CGd:3'(Fp8L/Rg5^+RY&`c%\ILaQ#SDZ
+%T0S>f.2W(`R)/SH=S52qTg92>Z?k?d"REY_8Y\u8,r0=YdDl(2Zoald+asFCJMg7#;FZCJdW)A(K#W]T.Ep77&ST7mPD>C/Aft;1
+%gnd]UT6WhfGG@PChSS*O[gDm!q)e0*nAa2)/B)F-,kr$(+fu81jCY8:jrHQ)!atMAA=YEJkPTVqM>8U'S'W,J;J3:ur$qadm%RD\
+%N[_@G&2ulg!Ej4XM>+!jdPpI%>_YiPj\LDRhJ_)X4k"uR"F?!MIUb4UIE&a<*k*<AT9BN!Q:g%dSUr[LP4`41%81J$2\d^c1a8iV
+%!(./O&'Nhlj2W\p?3'2&4GR\=R?>XUa):NUOh0kq#C&_HD#65EO;:?.e$mW#AJug\bco@'Td6#%[N(E?EqJqTfL*W7Xi^aFParo5
+%*!'Q$"-N%51jI4TI$8feF\DQe%6m-G4^=&&$\9$7hr8@/!uIP"+779B?G.k5i=o7f'A+EuVSTN3'Gl"bqjL!=M)VY=rmoo,\*<ZB
+%O\)aHf@(L&CWo;6O8CrtR;#en3[?*<3?MO\#G,B1G*$4_NA?1g^]`b.h7RWe+_GFDF&3T1UPqeUAJ.pp#tg%167[CPGeJ^p)f?M1
+%]Yq<KkmtPdo%#oZJoEhI22nF$3R>1E:67T8_f.5\Tf="1\$Wj(Qo/Z6*$I+mKo"L\j%!Gi=h(OK_1,7uhIbihF=R:(<qfXlp<8=:
+%_.q#?#:Z41R:g'\Xt#3I"uVq+TpumqBGRMML9i(kVVOXhbl.m<I7U)a,oT#epb&s0g0cN(0=_VD_#U/kT7M'-iqfjZSeo>Ae_5/F
+%;tH)T+R/8r`JSU('Vhpq2-FQ]1/ad(!jf&S>c(7Ea"mj<_Zac+1btm0fg4+nJ$J<V6@MPknuj:cMW_u21,![-WiraWnKKn7\Mt\K
+%2amBI$@"a47nmc((O@=^5V2Rj,W`cbBF"M8<'Mgt+V"^p]?M\>@H!H#iK/oE7CIib]&*t/-Se.25uG4G22gau/Ode1fhYk"f<sBO
+%q(Uo<_s:@h8iY:8p6!Iq,GmeOhGhMV(R&0(nT.0fIm7Z?F.o5::cqi+)u1?`ajH32"7jK260K$XhS<t=DhI!l,s@0>f=#Vc&QN?9
+%aFnql(47`\Lng6/EgBVOFDi"%3V.f@,P4gBkGGJS]*Joamg$nDbj.<&UE8d*A&"IRhV[<q]_$!L*b%HHa^UJ`/ki(gE>3(^G?#/f
+%JE%u#AO0/$hV0%.GJi9LjN#J&m>6g\#LgBg&DE@/9M`$6L+59)8s##!>&'5\l)OT$%n0)\$`;'-2Xfg&;R(G>UkE"X:'g"('>k1Z
+%G.M;c0--!n0Q>PVV+I%D`r:Sq&aor\k'c(L4OLJRb4-)q9?*=.BBVFA];K22.nVZuH'u(_Q1aGBbaI&o45AgMq6s;i!l#TG2BtHK
+%f4@&r1O:]e7MHIN+6iYeK";Ye,+]@k(7eN1FL\LY3sdSP`iE7<ik-ORgq9MG#_`!5%RacA7qlTaOMQF1m0(JD8;[VV5"!,sKVHkr
+%M:]ZEbNZUaR5*?k&]%+2bbU!Y?$3r$fuC7tiZVQ5bt]Tko+@*re"qj6[c_ZP@qQ$%33!QTm!>._+1(lM-Lee?@%UL3Oq\P_8)dZb
+%e+/[`N%>_5PY^/+&Q,Q;8"`9TX(pq!dk?Dh91I!eVJWKJg9d'V'D'SAmG8O\@rW0FUPoO7P=I]9::q[OT2_s2.0dYC"#7so%UYAY
+%-BoTI?si#;i>59ORG"$@Vgb60QFqe..5DZ[TbQn60<<s,j1eP3Gk`\?jR&dh5iH)V0L6X,jJR3hja_Y$lo,ZWdnjMU+pFi69R5YB
+%UQ<Ja_5Jt8ZCZ_jB9mfe]#^B$[fua7s3H%ALgorH\r:BI%r]KAa=;IpWC[$5O=E.g/X(hd&jGV&kc/o`<>BikeWRFp\l:)[KN^6.
+%X@.a-nQ=nA%7Kp-ZFAoF^Jm@$'>XVfh[0L^qI/"0c;Du."Tpn]rkX;nAFnI#9=]8>.IW3e+I%8pH,3TUE,b,UCh&sfA.`V]liNfG
+%UiqgJTP5D.j2GqZStCoL;j)t7"YJ`9N2e8Y>L@5@SP-Po+XINh!hpti-.`;F)2C-qOq95eRuYm+;arcLc.f07qg=IYFQ=?_]EC<p
+%.fXW61rZDMTDA0IDo;R@9`@qI"*;#-WGjQZKpU&p\V2Rf,LOsM5]h%U##>'V(m;R69]Ku\j_VAEa<F+/)#%"\juMjf)?c8J6,Ajc
+%N@I''nM4C@]&2t*)tgrkbWe`44H=Zl"l:)K'dl-'a_1jLeJdoAHH:[;]fA9HR,[/E!,h]am6_ptf:\ORqB!$8Z8$$:p15EHfoC]#
+%#B,fj4+4jAD;7A:Up3FWbQ6N%r,E1W$Q5P*XsA1*f&`<;9=rCb"&PF(g8FqlC(7Tp(dE3lc:,H[%!mbAj#LeMqI@kRFHg;E>Uc\k
+%E50eMroNNcaIf(\^GqH97tt\q#@W^87p,)h%s>.[PW[]8#qR,(r%<=Jk_<!D0rmFU<Z/dQ2WsurCq@/a_p2J8RYG\$A,^%KIF(sC
+%VAciuCI,_Jr,((NjB#b\b5-5!o7-XrPP^KCqj,W`41_`d3_=;IL(FfV[4u?]V6c(4dAG/tmW'*[LQ/OGrAna9m4iE(qUeEsg^#LU
+%>9;1UnTb)gW.3*%ZCTb9RJ1TXgrC7p,Ao^$8p`4dIB]<r1kX:J1iI/D2J_TWS$/;a%NmVLE?6E!6utSI^4_`2Tm'P$nC->+B<aH$
+%#Ks:q\;gIMPTfa7,@s(0BkGlU+iZW;XoeC'BpKb`)#JF@l#FOd%bD3b[&(6fWFjW(Z7EmGI31NElhAc(4OY.YRW>]bV_ftG]A*SX
+%q/l\HU&UXP.qSqD0nsQD[s(#o`9bbtSn+k3ETl3NBOoVLhI+`WL+XYPq"MFBcn;G^/%]XSL7VDZGn-B*ruf'aIQ8K9'XeTLq%\QR
+%rAoJ`d!s8k_'`t[^8cE2s7ZHdY:KWm:T*KG(jDP96D\b,GW+"%35Yd_i__q,Q93JhoVZ9*CZ+N?[%)[XAb]cnXE<F!DH^lEm/IJm
+%B)gukDoe`HF&"\Po\1[B*<Z%]=i;W%".PA_(0$TGb?.:I3i^5Keq9n,(P;M7:6It>p_e?cDo?_T7&\,@<=mBJh8\PP-&D8ek`,Ld
+%qqJ?):@)BC0G+?KFIL7.:!LVC"5#BbcEH77j%f$:AVj_._K(CeP-L400A3MP])Vk?lhra0WfZh!i*C&h(q=lWZI:/e>\'Y#X-HM1
+%)8L+Q5A*f3F2WMSmF'nNI4_.##2p#%dTi72[BcZm?t8;BpGbO4V'pu3";P/+VA!6h39/c?kA$(9":jJ%2S&1GK@gs*ANN&RZA+k/
+%^Yf&Lnt/hq,c]*men"@JgIm*o/`M2G=_4(5etarGj04D^W9*(XZ]9^OEaWNYZ\V%Sk^\JO2aK157pa^]rJ,lia,ZuYh.>?k%7X[t
+%?f1lAo)G!j^a;[m:p"JVQ*DQjeO4LE.p#)Zg]p"%Jf[P.`e\DS\KN8CF;df&,HeE.OLmJFT0jra,).Z,#-`L0Ce(Q2o&)6H`7O=i
+%7iW$!oD02J#:=Af%@6_.B4+R3\`oN2[F3L0LFWUa<6B7?;Yid\'ST)eI1?1D?m^o+/b<0D@2FMe(3Be$OZZt?23Ml-+["T*I"Zt<
+%9*#DqLjZG-W9LN\-.<S/omTQWP78L[/M:9_hT(o8iEb<G$9`02^'7Z'M29!q#m+"<\,G&7DttFhkOSAc-(;^D9WIERQ%;=9\FT1U
+%JJa`/9?83DQ(k/\UVd*A>uLNPLq\uOmQFGK*aH8NU!MZf`DoM@BG)4@SK@QP_tOEmTLGeGbA*qEQB_eca%FrX5f-.e<HspN-1o#s
+%OhY]XVB1(AYUU$*M70hSDIX1$S-b7M*QhW,E_X")0k('+`HO9nd*F!E9!ELjnm'BmO17&$NhL&BEV"i.a(F(GNJuN<?4Dl]e,qA4
+%]34\5Xf88h27+X[k<Hh1@tU0l&APm>CX<_=/1a!K>E$XBj#V36SdJR:%6Pa)iit-d]AA&RO;bSSm#,?g7h"GW]VYLB!M;0ZY$C[K
+%F9&hF\Lp>fJ3MhVO*>sV+@72Fk\Luo1D2Z@;P=8l:TsN2Fu&jo(^$:&o_%Qs`^OPK(*GF.?kNU4T[/OBK**((`kM_d<"+_:mA4]@
+%0ipJEnhh2<$_XgPKI:o$NYs\G:_Fq)r"lY\`3sRnO0E^_W3jVPB6U3F+aY$s"/)]+[k!4!-EHt]h@pag&%e4A:?PY4kEiZ*NGU,e
+%(esb@737>!o'#eqZ[l\$aCKoR1-h8jk#ItqVFTlL0FH)kVc\sa^h[o]cFsKq?pkE`r\HUKPmI27a4D^OjR'1adF-R>b(lp/We$>C
+%:[T6&P6^[V?%3=o+o4WRph37?]H0CN,eHB-9sUd(%.5GKHlH;las-E=/-O69]HiQ)HjdK@9]5(oeeo[B6EC2LhtM51%uhLXE$"Fl
+%+##.p-"[Jr-E##.I-(NcK:Xk]o[c2\jO:cu0g*=\d?NK3O)TTnf.[Eop7VdEl+i)X$J551mlrVc=BkqWZ7K%blrH@uoM4'AGP+3L
+%St*lU#<E?_RDq"Fm.WBO-D@+M+/+t+bC%(;k%ddY0iRE$5r,f:Q@t[`EAO4$g0,cFZ:]DtME+Q<72\?qMT^rL/%b2+iBW>T/,9,_
+%?WE/.Uji\,i1SQum?cFP?"-=*?_m1V,LMF?`Lc)J8g.L\k82kYVeSnIk(dY+@sFejaMKs;)W:lI<?jW;U;H]Wk_ekB0fo/r',1L8
+%^Zk`\YKPIm.YfggY*Y@@5_0PBA')BE"<bQ3.p\o[VK2aW4NC$/Z384.c/"mAptUh')PS:jX)-no)I94!(KimJZI$4NK,3bOOtWiM
+%p`6k35EFkhbK4BNmlKMj.UBoOdLdp<<`[R3(8)eT+mPnpiaTQQFe&?\R!A+M%4\>?q4q_U^-U5^\:,L&ppQ2d9Mn_a,hEL#.#_KW
+%;nH$]h1rZjg;1)ZA5$[#Ma+5Mae5geFa9Pa*nfmtXra4iBtDG=IV+O*%dI9ghK46(].SR"M&<R&?aG(gE6'V+jXF<JWp(YX-#plI
+%0AopU$5bu2>h@$;h_od`Y=2Ku'>I@rX0`P>#KT\qe-R)'!m;Y[mAfN/9e2P#VRq\A;W'I!)91Gq9+]V;Sa56*-=_h#W0*;UEJ6Qf
+%FM]/c`T!hb+Kf2jXlT<A+<Cn@@u/<^6&1bF<g]@uM/L@[M=?\nqjm6q!<o9arJ\oJ7"j)$9>)nc(VuGh>*rseddI88(ELb!n3]N=
+%&RrmU")]NZc32NQ!fJFp@.aqEX88Lu[7@T@#@8@na@X7cbb']\;DkL4_n[A#:)Cl_Ic1=5o64K)_2KstV!dhFPe;7_#Y@H<$Z8M@
+%%qbD+_ub'lZBHFi6PqC#)CI,^g<IN9Dl_5R-Pp_D5uH97GU,uGF(Km"K%l%9AUoCGcKJU(/QO:8-8GZP_;To(BG.'f16R18jutie
+%<qo%DT_#ImijDVNDC@uj3MSjdU`O2WbJliP;VCNWa'i@1B>Ps-:!nq`W*mK9:\*EgY=8UM<GqsmnM_cFIm6;,KFLuodQK/SWn_IZ
+%YC0oVCGm#q,OU%mFEpcX;p7BP2t":0TiGL4$<)K;">S73\\E%Or;f0jTZrL><eCG+,ipqgd]UBN#Z^_nVK8QV70bm_%DM$WfYAd>
+%A0[&AggY`PekSgOTVu6#YB*Pg2Q$V*5]F)$1q)-@*i=6f=@Z#!-c6QM6!9T1&6P)dI!i*JSG8"2q4X*Y^jZb==.>bR/L!-+ndPVc
+%9[!ou3.7O?VE0ZeNO^V-QSM'hk`%M"ghKHs!`hj22aQX]0m("=Gd7Gd$4AY2b:jh^Y]UVF/j%aQ`GXG^U]`S0_.Lm[+CBCmU&)Z+
+%YA3i$,R-Z6jVd2LS-K.Z.RkV)QpuU)OFA,GS$Y6Ua:d)^0k(:-IEp9:UAY_S`U'G"#_A(:DNo4d8TJU6""nY^H0lU&,npL5L!DO-
+%.p]k';nakYVYeU&<.c$)Gp/Z<Q\i>?C#>o4SErnc%tH0Ii$BY<*)/@-/@BphN:dr=:inMtUf')\`YTunL,^[`H,Q;Dk/LP="IG*0
+%YJm>JDk!gGX])4I`8h\Ckp]'a6kNo4gE<uD3JNp_M]*l@[.d(.73!djXk[o\J7*-MRT#%Vl%R=%FPhq"^eXb(Mcp#CQR@6O9d=*-
+%/3L<3*0MH38MVYrO9f)?Yen:_Dh/5V:kgZP+Y+4`$/@%Sndr4Q&r9qQm>m5VDTuK+.H'-_(iF%",a;>3]8$opdS:K@FCih7C+kXl
+%$\H&M_n_d;eg<u-!hbrR&<(J<>QFU87R^9$Y>HUuFCr51R@'=d))R"lmqPprheK/;<U!I#@d>:-!l+-p(Aq"*&h<I5&QbN@Y&.GK
+%nM9&^K?NQOWLD*ZL_&`-'>K9#bYXXJ^d)?e;&;f3,dK6`fcnZk085!EOc&7mE`0t)O#%_jft;C53,;AG/cF$L'PCEBA0Oi<YUW%!
+%J6=1H)>TgWEE*$+-8nXb@+GBJSFlQI`d.rt#j=t+S8:mQE5I'3XtIF[Z&4*"cUT1`1!/cPOCpLT,`>sOPnMO2!&1>o6u?A1hn`D<
+%(n+aH?M0t>LiS#XQ5C\`rlYWkfbIs1\4?5JB,A^p9eKNh,LY5=NsD:%E?FPoP"LTf\+T$l[1?/t!_'Y-o9:_P>3miBUUoMTUff+D
+%M:.X'$X!"LES1rNJ=\+^3Rk"q:U?Go.E+'4&jU1u1F53*m^$faJZZX$p=[>H"2U%t.HkOFW@Kisb7G$NT3ksmH;K(A9_8IO*_T/L
+%(?#UoQ"ojLCuEI%V'Cn_IQQ@Q2RM37X7U4dAlt#r>g_F5HOD*uJh?MC.Od!bQDZZ;5pARJA(ZmbY].T)!Td^0aQ;GC5l]lO":!Ea
+%m_'>e+QIF@mq=*$;M^R,8e;*IA?rLSaKpsd7n_@f/PW$>8ntF]ZHK_-<)(@DKK*KtR+''?.K-L@;!M=EArK=B&$@qAU(ha+4tZFC
+%YC`!=p#^-T/jAlk(6`h=a6ctsrC2)V=hIK6G#)ohfo505(c4#TC`tCYpm?3gF0%'NOegk9lL?/.'>=;kpBPQ]_\sob#[[Z:^7YAh
+%rZ<'GAn!NR@VleN+Q,#K>Bk)>Qj6h4H/=P)>Rl=.R%U1=WP0#oY<L2'(*$9'[7uJ&9QC(]M1DW-\a=jR;6]`'1Ml/]!-GL4/0l8U
+%>*-`>I$]2"dEZPr&H,oHR]-%;j;#2)VH@7tD3J74T@Y6\N2DY\B&,X?C^*u#kUu`L\en'cf3@DZ@n<-$8b:GMY4@b9B1[*;.++]Z
+%(g*^?JJ82YWoa4CODJ_K\pPZa>o\k+#=ZV1LQ2<S^/KHE1cY`2'Nqq;LnRuI#"JiWZlVo*fHg0TOXVeq7216=Q,Srl>=/JKU)l#[
+%o-Bu(oI4p<4%To4"ClrHe5@>@b6B1X**e*Bf9:h=Wig,8EmdN4SfUmYGt*@J..M;/Zt!"B%KfF_3f]P/,#e."3MJpm09>RA'Vc,#
+%A[[I4Xbe/B(4M/pWp\r+hOosY=@">;eYF8D&U,$b<^JJlg#n@U[@;`Ka_"!r/ul$Anktno)JJ4*PL*1soCHEUX%ml.R4KW;5YhjV
+%"/iHV\jY@@kfpJM[>U$0rY72kcb[=h010)Y\F1KJ>M+c"/a5>(`D!oAhPTV\<g#3JgUM5X0&_,b2,/nJ.:W2o#,`WP$ibNU@fSL)
+%-"^`^B9k"+odTQLROZMFS6IT#d.RL!I4T5;aP#MV"f9'mojJe*n[Wb[eK-0VA@]q)\DLnV+^$'CVS][Yp+i8F/,LVBq`I8U<Ac:J
+%^pdea`"H3`f54#\7s2GM4e1X9?>YjKKn'GZQGF17[WWY2:uak<Egb=tp0t5Agr_WE2Zm3tZ,O]1RSl_M<a)@MBI!<Gh.g,?"@bsK
+%h/h@i;nnQA>&'=7=*PQ5S(j7jjPo5&D_XLqCbR@7JDH^JWi^nn4*M+g!a)Zl%hJb:nZ`56NM2W\.h*%0`4*^r:X\(n@kb&m(_LNe
+%MGffIcr#B*"e%>L#,=ck%Ftt2!X2Pg$k_M07(?9]q&]:2<,P,d[hBLC:/)7bdgetePjsp+'hFZb>?R"n[#dfl-,Fo:<>\Tj,;3aj
+%:2IA]ZkPk9lu<`K<tTBWg1Z;UQC6`K.5jQ/H6<ZOg'D.Je4Hp>TcfDj+dcfK1Wum,gP@g"4!30)fEPm7`5;?lo%TB[[+2T6;-D0Q
+%>;`a[+qfNuLY-X*+Ghukd6MMW)DDl7co0QFZ$Q5SOH+1s6Xid[&/Y)W!aUY[@VUK0U+Np7_cAnQZDCa1\`C.C&K?As+utY3=tmHI
+%GugCi]fS&sT*'P->/aFa/gnc_Kp<@t<tUugpe4(LW,W<4ZAVTZgK^PnWmf]//O30pMr"2,j=!c)K/JOuD2>bA[,>=SL6`gn$bHH>
+%@QSQW6)t,r]7tb_dRIHPN/'Q05U/XNb>P\#"ZD!R'5,h)ki\Vrk"$q9fH+"8YZ@QU8GH+qE+pQE(:Iu'5*LD]p_OMjFatjm`&kn9
+%Q^tK8k"5a1D3qE2,T<+r>p4&GZH3&4h#]W,aQ]e+e#OeVP\*uTTXeZ/(/Oh1&=[,1((Mtr#?kM6Pa*dOr\EcJa\GB;1(D"K0,2up
+%Zk%;,MY#>d$aZ^q+b+a+JA%>MQ@rncZ"p(.1$(H3LFuL.jLDRA3_eGnb=,M]MU;`D])6@rG`fpg;nndag`4J36TV3&S!iTt[US4i
+%;!QOWXt_[c<(a';%Jb/+&ruT6C8Bb=_HPLp.#9_&&pT$3>0TeE[Us$WKfPJ4,cde*/l!8"<cR-9V8\8lHHX>$9'6Xu0^-5(gSSdg
+%J5`d.29S/j,eK0."=b$]=L5%;8u1GMN5[,IZQa''4AaJF:Z\:AK79;?XO:*:_.2SB=`'(g0\qX#(H2e\,esuD<`D39hOqi)4s]dA
+%4LO-Q#?Rm!77)%Y*`3Jj$I>rfC'kY-gm3>,'a1t>&(W:rDU.mba8cHfZdC'81G5M+l'*$h%d-dW.m3Bo,CZ1KX<Q+^d0jYi>=t/O
+%eBC.8!(ZJ63Z:^:$&MIKG"bPjG9skE;qh_,>)"$Ejj[A:J/OAUA59C/-YX>Hd^%6"/!ben+TUecM>N\Y[L/nu6!'?9;_51BlL3b>
+%i&I3D4Ci(IS>`g9%7*;@kC?ne!3>/k\MD<1;GfEH3t*!&nmO,$1i4[9bTO5tl%5NaARocF-i'Cq(:BjW70pV)<1Y3;M'=)_Gas65
+%53<b"4^`DLLZ1FgM69boR[&SB_ZCKkq?ldVkRJqPgj+7n4/h:DYf?9_`30i"<SSpOKX>bO.:`c^ZpOa,#KSY$'f`mC.3A*=fATFg
+%Pj@"g^kL2Td9l&^^p-9A'&M`V-ZIu%`[;:GVtqXI4?WH$E]>?0i,?K$E.OZCSAZ:>8#f=NmDQKX7j;'m@ZnNDLC#,tU6a<\J7#56
+%5h=T_HS,?W@\D9"79WF5:6m=2:8eqDhuM\138cM+^`#q(2A<M#fN_8NEl2dWVqErk&=S<BL$q>2&T0"Q\HADmGo%d'_>NuZ`DHI8
+%Olpa$2FP<\W*+&MN?\.KQ^0(-/<?tB<V%4$Mp,;u4[[FY@3cPFE;5!0Qcc4aV1+"-Co#%>Y`"PWa"hCF5gI1ni_;Gf@5t]Xj=_l@
+%Ig(C*Q,c/!-`_EG1dNhB_+=4QSP#i52oJVP8L<%:p=es)_JDkU;2fUAFA"3?lC3h8^Wf_D/e"e&$BRN'PQdJQnl":hX/R(<:]Asl
+%a_bsi5ThjLPu2$3LDo?U;cM,U.[L8aIoQ5FirOAX2(+V2S)ZuMB#l8Ta<o[/oK],'-psm;!f@2QMBt\Pr!:YTAEAC)r]L2toui:/
+%61^XC?%Q0a`sq[>ckBj7d<(.V:Y$PKUa*4J8W/!8:P"n71uVcgUBAnE$:>9m(n@o83-S#:`%ur2_pO$%0Fmc)':NZ'^%Rgg+A+]3
+%5c!M"0PosRJes.@%[6El5)?d?h1/%(Nac21k@oIUWN0I\A&u(^E<'S`%c;*&(3c[oVs(Hp\1-[2;gj6a4gN<,o,s'JN&q(db&r*e
+%#"Sf*`7,GV":4`:15`:Ub*_]m2u@(M&lJ!gll")nEl4Uh#oH9:%Tcl<\hMdUdqET!)f.MM@7F*K(p/VXpRK?b%1a,bc!jQI"lSi#
+%D$-8fDUbbV(75Rc(mkqmNc%P6/=-iA:U1FVD)149REM;l:Z2f%_A^-Wm1aOP1u/u2M52U,;oP5l44rAd*K)g(l6IQ<f%CI)`t^ap
+%aPrlU/L\7r#&@I_9OrmV$KU)JZLlCYpoe^@ckZ.>]t:od%7dLCS5HM?0D$KM$+$#:J?b0M_k(0Xe/;IL7sJMmq\R?goW/IVAB;0'
+%*:u8;1J.M"XXePMQ`>Bj)K@U+j[<7Hm]q=D\Jh#u<0t4rHk&XZUZe-bp>^q/]h]$Kc#$=V:X@Dh[,m[a`d%a^'UFA=O.D-CY?Qa'
+%3dGGg!B`3@:4hL4[iHd+&nRsYbe\>)JY9SJjeAW>i&m3fXns)N/-%pZX#LRDVS$tb%LuVOpEnTAdFlEdhr<cM-_-m=KJ6uID4Zoe
+%NCdm1lI,m>P$M&#7+>sZ\a:_,e"Va>Ft9j3l[[V-<Qf02E*#he3R962YL[P=\-Xi.cU:;,2H)JB&Q6!<q=]UlP,KsP$Qq:oq]biM
+%9Aff??cXsD,ZgnT8q@Q@/dOcV2V]nJ:#Sb`:8":nVfT\:']EbV[tucpgj4u@4WBDFf$*^OHVr0/L+I44LT?%F)TM6].tLVnfu).`
+%fGmJC,pFjq_:)(YNcd65,d!GX50ma`jk<ZPXRD)7ZRnI&0jOLtYT1s&hA'RD6Th'5RdAhh#ii+j7p_7k(\^'(.Sg_j9nGZe)./b&
+%HekRZc,>%6hK@u?H$j'gA3&).VKkkUF;,\15-p6.#+&mpoea)%H5.utlcH67_uRs]jaA1ik.48Q#_uR$D*#6i3;L?4dPIpad**ab
+%U[te-[2bhJMW(9']j>>"C=e(X1VZ)ns#))+eQP*0Ys2_6g8t^ba*h$"2u`4r;H1jrFqa!dKG8^T/ilKb:f-u*G9DHrF.l_r3r2^K
+%,_;a0XuT#]T4bIh.NE-mZYE<k[]T6ACdp0<A0k#k>6#bpc)WVJjnRl9^i2aXdK%H&8N#:.W7=")n1m5ZII<csCg+KSPI1kS%[Sm9
+%7Q:CP)4e\WCo`8L,3aXT!oZ(+9n@,Sc`e^a%9+rbIB$0d>2bMg4)$^BGrX^-C5$Is,-pJ[[`R/.O's7Omb-If'OJ&Rj3Cu;3Ha\`
+%5B1J,&oBCo."73TD5N8V$^K$QM[&i(?O*_W3\M&_/;_`9ZlMU\?l(C+q&#)ghlt$'((0=E_bhQe/"CZ7>Mr]>d('J#p"L][*%O_h
+%I#>rb]?S@0DQ6+ACik;rh;G.<$s-(U6"1SW"g:N0FJgj5mUA%;LAs/KL=;gGf]pLn<9'j:ZP<:ZY:V_th'EDq.%Bt/>OMn2!_hA$
+%i%rTjh57B)CDhlq:J\!i@,`PkeB6J\/M.LEH,Xh1rNL"`,16p=TrtAb&`T#dF!`+>qN,KL:/JuJFB!5Aq?Hp;s4\e;Ho3IjZ.(OB
+%].kB0]9(=8W2U3K/("f7g(l$8?J%7*:t-T\KpkoM!s%\b*LES=8iWL2`k:sumoMX2MI5-/E?V\.>/Tj5OT7aJ#u:tJJpkFHokAR^
+%oM"F@6ilT[#7S1>YrB8%*en*):BS7(WcdnF_U7XW\0?1<E(L+c6d?3X)0ZGE(J-<NW\3=>lQRh\q*a;tg?-L7`9,IUf2`\Tl.r+"
+%O"DT%4lKugX=Z7T^tW%ZfiUZLg!H>P5;8hNl"9c\&ouY!#H&$;/NiI[V=:rhV/W&Zs7c.(VM7l?[:\,tK95Gr1g;WUWADC2%'a8V
+%GV%NS9K5DD(7+41_]r.aE$^eZIqNC?c%d"H_e;Y+Nr[R`:PpC?`B"go0EnYfi[J(BQPR&@2anXJ*oZYLX@&I<KAXMO:X;"oqD?"B
+%F;ktM)Ue]>j@mXcqF<.VEgo*g2,4*E*Eus=)-%CuYn1^rSu>85i>Wp+SlN#*Y4UHDLAo'^6-ucNfc"=ADCSnGWb0d?[M9,6otWHh
+%["!2).VmStA51>":C<0J%',p8h58emrgVf2H'siM]"L?qd7l2\#_7.YPaehe0;\o:;-@^WdghKgo3#O*?tR[k!6gB2aTEZZa1YuH
+%``J[(>=m[+^iIO"E0LDKC5`EG(_uP1.GEs%L=Z,nWt&#$a3T9YN&oc)"\m!!m<4-obI!Q6CmK.:NWkc2ZM/Pf^!59)Q@W$E^B>Ya
+%)]-&XBsFXK=TR;0B[$os(Sm0)])AeNaI_[*k6S_&=ntS]O41\2=f=#lI&!X4A=3Q9M3?tN%g($57$19S%<b%Z$LLhA.0=],T5@n@
+%$Looqhr.031.\D`;[J:=`7?4*=q%*3%I\ZR/>t%hi@d:+:$ld*#f*,?_CsCEP,:u@SPA_"S+q%*bcSYo/di:T^M@PH8SYcMFnYhp
+%S]$7Ng38?X,Rj$X'O@F`$OSpJ0&/>7K%8)`]\T\d[o/mO]^.oRB:G6'1O^Z?mm.5Tl!K4'h/Mlpa#0OSJEb)N6I;G]4Jl$Ndn6f!
+%J9V@p*+%G:?\_Z)-)A#Hr/?*Ch,>TDb97BpiVfp%8O*<./(CdeG%AL5+6qOQD(eL:+5$E^@E6>:j;^M/V;$cV&gX$iWfEDtOtMtj
+%XO0M'V"dX4G4@E.cNlTc0!7Y+,Nj%$1i.^s75%*B/HfFh7P+CfLR$_.$+K"X!XEN,ZI',r)ibbg&Q-5,J3pJI'$+oH;:,:0<=+U6
+%4;[o7/;^092[(D-]*,kUlc*#-n\*.T%Q>lM=4D5@I7!@ElY,2We6ML@fH8E()ZTm25/]kg&Nc:T1o[AtTdd"WV:gp<E"OuT?5SQ0
+%,^=<-^sc,`Ef##HZ[mA2=tBZ()Y+kBF[iL91,N`6/6-?%cH$'UoPRE0!oPM[g(+Su&3P")bKA(;).U\>`f7/9AMt<Mr[MEN'g4PW
+%,,-?@9LdIH5fTEc)+P&6+FruPS$jYDB55shjm&m>3>F:*=8F.KH8fRgn`rM;$L*T0XPD8sD\J/crLjpUG9[J0n.=Lf!V;.".83#]
+%Ba/r-:*.?`\3>AnZD?[lZ8*Q?!9>$YA)62jYV)%!kTL5t``J$G)<dD$`X"T?B(0*AgO^uZ73:.I%X8h6lAcbPBA1sr_soP"F`AM^
+%*6sj1ie`F-D9PX/Ki`H1n[>##Y3rAam;Ai2=\1^\,9cB<SF?NuBe%ku?*^PnKG#/=#>F)W&VJLa^M@DDh[u9'paf(k*JAbV!R7*&
+%ra>?;2l["a/MDZg@6&A4#^3^QKLEt8OChkMS&]0rQ<.l"9G1[A(R#I="KlA(O]$RP!qAQk;84[cgNiL\dGnr9\!]n)c*:/344Vb>
+%)5s\GU.GLA!3Hs+ZOK;BbL/[)Z_<W\].?GV#I"jcY[7.<Dpb,1,nE3gC`?`[_WWXg(aD-^:/<FAqB5)l/=m1;M4#([#9`%$B^9\)
+%`6Y7*Q$<^q<W_=bTFku*dc0'uL=b0H_%[30d11Etb=4-`Rs9mV>"uOdS!H8;0OHmB/VAn-Urepe9FteH1X"a_+%dSp*6ZWA+**]^
+%>5&nfC#^_or>&[&))2k\:BCHeQ'iG,65EQNMi3;+D7ig-ZY`>^ZM9j!FY[s]UmV7F<8#aL,QRHJp3aM*[,-mI_Q<kBe'gj+F.h7s
+%j27rf2D1c1W67O.]t6mgJ/c#=,s#0!Rf"eeTtlI(@hsDHF7j^1C##T?3K+naED,1-@LG[\]XB%g9^;I4Kn\?Kj)(Z$Kb9%h8Gl.K
+%<B3)&4$KbXN0nX:fO1K_A(=>6,Mj2XA6:abMBh>!UUQZ>m>Ak2l2pcc5qtroL+BV2H35LMU^5,9;!Gq.N/0%L5(hgE+[p3Bn5^2a
+%@!=OeNSAU<KlQ-'TXpu>2>dJ#@"JDt3@[FgFnnRYq3fP6<D1_.)kUtNqQ]RU-"cgN`IeOt+XS$R:R`a"TO;uV.s4)bF-"4*]O*"3
+%RnUeB4BdWRbA:@T#]Q4V)Z[(nX->=Ii.9O[L_m(&)h<Aa+0Kr2Q<_]&Y*XVPbVBhLQM!2:%UkkhJ8>cijH`N19lLY_m9&PAgP)Qo
+%OpT_8BZ&77NGhM40"!#-<.Nn/Q?,sRSf>f4i`3IaH<C'HoYJ6MoJYAp0l^34R_clE/SF1#$`/hO+-jdY5SG9L^4g4p>t39`2%6r%
+%cq.;q`.hij'S_UN\CGa?EJouZFELen%6cFtI4%bC0_nP-11bj1SLei2^,+i6_M^c9)KoYs-s[,rG"68o8kqCQW/9P0L:nJght+*t
+%@&ZOd&;*\LhumkPr%"+mO@Uo]iDaIl4:iG1]0fLB6K!!][K=(Y+%8<ol%jg/!?feuS&SO08q"4N&>HHe*dOk5%:49h70c+Y[56P#
+%fJF>8D,]l,o,[FUUL.t:_3U#mXSZAYW*-P'&j!]SINg?F@._o;Dc=*"Lqbhp.YDQ).-k'4A&>DKcZd`c@pUNH6h8'dbOM]u/]e6@
+%$\#NN?e7N'PQ.Gu!tlt^;F[i6p*7kpRoIPW]`.mp(Xj^79X);CV_hG"1IEk<8DkEf<S21]"!6CDe1572fQY\A3=;KiJprXBfZ=]5
+%BpWZ;&ZK%&Wu$Air)BbcmNnZ^<'rV<QB!'LF:NJgn&mUpS`c<(@)OmE`?!)uFj&QWK,b4r=(.TdScC^@>:@*%>4fudhe#[+"pG9:
+%[2/0Ba[.C]F7@ct`SAfC.okEp`@GT1+M:(f46Znm*<G^V*&5u^$1SbSnPkq9=:"/VWE+22Ln`M<G99k5D>AsDGgM5&(qnF1I<AWp
+%l"9#U-'@s>l.Z=heb7YN<92I4'f9E*[-*9MXt')G'9SW3'Wm([VE%c28ErVEW2Y<4"<)Ar5,T`!.(b]Pf>Y-`i>.et=]C`n-;.U@
+%lR"EcJUX##$&]__d<&^*BQB43Ih(s//H#)Zl)QA41`.%$@OFLpLNS7a13Urb;oQ)#.>4T')KBEZc"2g8Y99(pMS4`Z,%-rbeus't
+%5\qq-f!U*P5jBTBZQnP*m.Zidi(K,h3LohcSV$Hpi"',B[@8$%3R"sX8;]Xi*6WBCK5$g[Bh_VEK=iOK?.d2t8^4;kiiY%41E"r1
+%)(6B>[$eJ].,cFt^CpI31_@WN\AWe^;i<$oLmO7TF,u=\*177X[)0GW_\B/0%Nrn,eP,]2EP>$iOpI9d(0NYoYRX+Zb2Khp$j2R%
+%-CB4oGRi179h:l#AZ^ob%DNTo8KWb!]Md6B`fV^pN!&+%))DpUIu4.QK)[TdBdghZ"Js^F4=k+^4]j\+]9NoA7f#"Z8D;Rh:(RJ[
+%%[VH`@qUU+;Wj^;@$U!>r*`So2X6/n+K6J.M7a>/`@P:Z@UF*uNd7rC$!iJGS2QNOlfZ$,3AdZ'^5UQ@`]jO5fZ<9]*D*WY"=g[#
+%`]UqAK706:PCR4VT,Q1q@3t<8d(0<@+5;[1TPX0KA0ps0raij$i<K)HV.TnI;A)4M'V22hFjn)PWs+@30+BWB]2c*V+#DGSAPfF[
+%og=?BhDKE$n1_^qoB7e6,(CKtgZ7/;l:%=F0:/**>7++-;HDe'K&[1om4#k"))>Rs[TGR9Dr)8W_[3m<*D"$/;G+$*Z8uTl9NRMB
+%9*HoI.9);gR&Mg&nms,B]8o30rbf,[2L2Q)-pS$;U_Fo'I@4]B[P)BKka@#i(Hh=PFO=o)buRFaYnSuY3hM/)6[>(M#;m'5+]i[W
+%(28J+2iQfPic&i-^6Wa7Qk#TD.OKH`GIbtq*9<HKnm.B[$@dkT;[R[_Ha1)KbEc\Xf3mLubGYSq,VIg><kbY'b!9qBnCM0_M68^7
+%+V]!#Z4\nFItbB$3DYOK%qL]t>(&8>(:5H7o6$b0NfhDpe@fZI?,t9WVR;Pt)ET!03eU1khZ\-'Ca+uL_*lKUq9)=dVS+D(JSGO\
+%3J521_UuQ.5B_rg.[jd=E+s6ElI8Hk,&Z-<[n/T$.H:mj&eDbC_?3;BA6>i"8#bD)Z]'KYE!M,2qMpi2G5/A+IFk7FMl6erRnM``
+%$rO7@7^ErRIC*ok=AmdR,X^M%L7)/<7N4'l%eA:(T&%VXl#`8[NZ^)Q7N<#idS?*=iRb]1UM2&I4-$qUZ278%!R"@IKMOHY]+'&R
+%$m4nL.U0Hr,8l%_%6mP;;9%FEB'CTlI1>me5)P[SS=lR9\BoX<3Kau^8"-C[E?',DAL-iAr8h3VeZrX8&[s?W3)O<mEgGno9Prs&
+%,H=_h3',t<K"Z>57\bs/P)*I'=p!Y&$"-.]pgLR>$u's`ps#C?rV,([DZ^[hfn@*50b:Z^.)<AEY++Ka'E69GbVb(3W6SlodWE?n
+%'GSMLLgc4RUP(ng]$e2I%eCGdf%j/"%gQFO)[@p,q-ff8EotaThJ2>`<a8W+)@Il&/"YOOqDLhHl>#/Vq\!1&((b_$>a99"6-7!M
+%)3Me=kCu'[\ua+c&VQ0eU=M_W?ogkdMcCW>!-mI1<Ah$*2`KM.>EtZsVSb'%b<$g;l$A=2;5Js@!IFcKmsq,N`R[djLu9*M&O)ON
+%&kX7kXMmqhnS:RESI;u,A;C'pk(2bpL^F3=Y+M)t&oW=R\YhIfn,L$&"&AAc"bXI#JOC*7TE%Dc2*1usXi/pr/BDsK2+Y>oUVdm<
+%I2^s=0uVaD6/a8G*/HM("e1D<M8SLeAB@#75EA\YatVbHB``eMF2"m$n[!&r&XG:oU/mV'd?b@:REMMJ*3d<q/3YU71EG+ign5Si
+%1%kQm8qoLRG'"/,CjVY7T0\-/6;Y<-9X2A"QGWC93O;un_o2[r2ld`^L;D-n'JbB:M`G'/jKpcnPRE=>RCYikKED6cBA?1R3@Ddl
+%'%O/%Y[@ss5]u5QF1tfkj(GmcflbsO+G(,(,g&S\mAmW2!+r6rU#\VGW>P,$UfSWJ\g.4+PL9X+_&qN5+o&A1D,,Na*Y&c(i8.4+
+%1E:!KAZlP,;1Gle(f\Ag&_n+Y]BkhTdCHAOK4ATb]Mg.+;hD=1R,:^F^lBo+Y\10o_R"R-*!WMXC6Jdhb$AI0b!4T)D!siF&5-HA
+%D%W*>Mam6i>]JUG$Kd=CLsAr]('0+2/nsR'k9Eo\OY]8<E$8p*VIOc7'<hGNT#)8j!XM5DHVVOs$@b<"G/5ddV+PkR;^\J@b(k!'
+%G'>k.Y@14SB#;)cH$@VHMVSig]%`Inbc1`PiWLLVccR]&;^\K1Q$=Hloe@\ok\ZJ)bTJ%'a:+_S!H@_VN"at)rm?J;^95S.MIGt^
+%X#oj!:'/+T6V3L<oA;,O2BefqlHR4X-taq'Lg0`'-g2To0EDiP&r[%p+4DU^o$AS+9Z8l=rrSn\>+<`>2eB_.1qH"0+?t%R6^,Z0
+%MUF(r7d"Fij\_RCTu7="a!)cMS3hOVnF+8c!o<s'.LH_>U"ee^G-O2V$<[feDA5PfDA?([>Fkc@Nadt\o86SIF8%U/Q-RFG?9HQ-
+%dPsTGNL2NW,p`@fA#BB[,\DI#,$19@X4[=RaFM\Kd+6-mq-Qp-Q2400^!1%FDR9*?::$oL#=lYZ;Y\Yhmnls<:gW3iZD_qKP/qff
+%?'cqu)`_4]!psOs+<3(pV/QJYM\uX+#bo@9$m]%(Q%/ouil7?Q`kmqhm-I(5P[^WiU\S;nLhVi3KW(E0IeECp;1.#O,(G7pbdto`
+%rN!(QS%o7Q38:AU[Od#65o0ru&dTUK=b`G$FI`=pArqNDk+B.dmZVX[^n9#I71mF8F1^U3fcpT%J6SMe!EauOM"Dp&d9Nb"'F)4]
+%Ui\?l#<]pq9p#s)n7q$$juF]iSOm@TT+Y4U<5:-L,\9^\%V$)pLIcllpeO#-/4#A(Q4lM(:e4"FR.P$+p_phfIQ"!9'_$%2@9JSA
+%%'uq5mQrpe1b&I)7cGl<HIG%]AL=W+p#=VmV@Y.<T;Dc!MSM?tbQiYGF]FI1'mq?23W?5r:;RLb4KJ3e9irSAISAPO>W+R>:e+fH
+%lj.h\-6l3D%"&;2SOFn6U,&n8/qZ2K@)J^mfa)N@FG..O!3?1-"-1dMVk8RIPY@:/ak2@_,5u7L2S\7PF;jEPG0]4pfB4Hs\S\0:
+%dcPfc`Ffs3m%p8F%<XZRBZ.0k,:R8JcSpmaF;UaA4&`8@-PAJG!#KF^^d6>"e8lA+KF\LQN=)L&+O(A&U00sd;FjUlE6]>&&0!")
+%R/YHnfRf$!!VV+J/l)%h?aKGa+hq<IgM0"K>PloRS3$AM$eWFbH+*-;=&W2=*N[U=Fe:=R^m:E@f9EL"I&LHn$Ll;bV"bX+fc`da
+%2D\s7hs&i;eR,R4kWddu`$Z@F/Ib>Z1#K%bk@Ybi\Xg'-5O6J*bUA(Oe"WYc^nSPnAraG^2)*C38D,N`.lTW<'_1\i;lsq;%05;n
+%AG<5:'6Jn91\bI]I<Hk3)]mTFXj(@E?5=0pb"Hqs)IuSG*-J-#,]&A>.$Lp"TPCRVob3<]*1.o:+CX+"gld>%9k==0Y=&:)TJLcR
+%D)%'EnY.M-@ILMbQ=Umea5V$rGiU_sd?K,;;*9"5Z]LJ%q*nFL-pGKsW9NY@rN)LE$)d![J!eIudmFC`\i0VL)`lL0[c+C.3B^&b
+%f#;(LeM$:"AL-#`^;N;H^o]NoWb`pPVc`35Z<cVaAqu\5NUJ<B>PfOW?C#B8i^utK]j"&K#;3h\<@C/+"fJ@6A4$\_(Pc$LNb:ed
+%Go?H;X?eKhHp5tYR_sm6\u+b3[$p/<V3TQ3.P0L3A/_hsc2C-GPu2LR2hmP12HWgKR)a5pc=RcN9urrLq7#FT)@Yfmr>$1PZ`[:l
+%;FD>+ebM$2*&d?^7&:*<_Z'bXn8o/7X73HYg/*MJ3'a<[pZn"jQegTiKdfKoV82=U:N$V"fORusVZEXs9UOp&AM_s?=a<@ldjRi\
+%ZjUAZkD=&;W2;IrPc.?gK]2ugmc<0O6CqG6QE[-7+C2-U?rHJqs-2Om#5]k^Q.Z]@0fShkROFH3S,/5^H8SY)@,=+3j1Z?Wi]'0g
+%U;A4+h.2A)N#)!jKHEFJ</OWk13\(DX^V&sku+o.=(mW>3.c/+HB<4^9Q(Mo[/J)N@2i6p@0ipI'ja,%l#"+J7?&\\$ufi%EAeN[
+%l2:TO&bS"iHeDsq,`6Xr\2&l0RL2YATd\&r@o%r\DHZ'4GCQk>K9K%ukd&KCZ$ohL0Q(DH&Wn'$`afeD$pDF[Xe7Sf&@4pq[C?qt
+%5%C^KPAkt_nn-/g:M0.fR7J?,+nUm[_33eKkFs7W^Hf-S)+F$tRsJg1-U-osUl\hk]2R[??\a"E=FI\7rb%j>B&%[Wdb?fcS-ZW6
+%ST_k<@G(Y#8BuHmT<j:X`-(%]5NPp^<n@H()/:2#Httn'qO!W5"fU\!X/aGt2Dp1MmCAK<m*sNAAd#"j[`gt--VZNei[Rb,r%tq'
+%nJR7$]?#>Jf&b(bg8GuDQ:d#<YW/TFKT@sB_6STHdrJ5gUlt54iDhF[GlQ3g_Y>'u/_mnXRi7HG$leQJY-d"?A3[eJaW$FFpG#>@
+%?Jo$nTeqj&&I%2S(rYJ0qD8lt@=q\(<N!HODW!c'`*eHSF,:JDdgY4rGRm_QhSU-?XpZGAQa!m]iF@=I.uoX8`NR5]9.'q#lH03q
+%DN"<CfZ8fX2fgS0_TlthO&M(0B1Y>R-B@[d:0`Ta>*;'9CFuQQ\.=sXb9h0p_ASpq-*P,6Ypj?WFr4#V:/gh&XlJ^3:pVXA5M@65
+%e\jD8a@$W1,rJ\Pc.&jXq-t!@:!72qfV859:08;IB6HlKSGGdVB+sC#_(f4;nX$8D_rGCF:f/=3MN+-`!JP/P:VfYpQ%K7]O1V`s
+%qeQO."Ao4!=#;RXU.Va@$PEcd$E;&k&/RsKJ86IYZQkq*cM@6*J*9B2M39!,@$s;/R]T5LQ*GH&2Z>*aR`PCMY6tJ'BSeGCiPU%%
+%X8c:6+d(HL9Ms=]<i9T8's4nq.B"`K0L4idYO^j1HM5>tVT-W`K8l;&RO"E$E;EFV#CdP:'(!>oiT]AC-]8YBEkr$I:G`Z#A=^LA
+%<4:'XTgY9H\skf2@rsYT;GGI`4LB[U*O>*Q(R\![*!.^0"^3kYTLB8AKgVbnl#%::mo>K^"h1TB&^;=/]t3X$:q0c6!((S*j7mG3
+%X,I\KWKI?r7X%FQTEs%.K#+mOklDYI!XF/>%oKW1#>1`#+oI@"]1%_&:^Y(=2?4=ci4I[R8PA)UC37jrIl`tuAW,+f.r0p[;8U0Q
+%?2@4KJ]Y[+RWUDIB.<$5YhL`0s071'9L?CF;7=%"XDZLf3K!tf-gDW67jer"T>TMcB84-!6^UuID*e1\Q&11snd.%I'l)f?=.A63
+%KJ*?fkhruG&;`N@e:],9AI:/a81K>;.JDiYk"GAt]?usI%$GB%%69#+h.5jaFOBYtX.]-P2?YJAVXj.g];*lB>%\r.],CR^(ECf%
+%#B''#`&8(m`bB)AS,'>JBdX9o<&VYXZOPb>AK'H?'%"^#_#i\V19J\lpiIXP*Qp3-7$6P(JL$/_=Pob4B$H?MO$ngk@/I1<PL3M[
+%S[dF$0XG^W\&4@SB,k2bP(P#A5NX?"IX\@'m_Xoj"tKf*e-m?lm.t;'S#q1A%7#:M>b+MeJ$aDs!4T%GY_<^!?31;p-,D<c%!-XP
+%0)_&>rK&^tXTlg^o"[4+[#HEdF[D[6B\*@!PaHp30%m4C=1jp=Xm8M$8fg^]]mQ6[Ms0>AD[.7Rr$'C072C1eUkf9j^o_"uiMGPX
+%AE.2V7J%5YkJM=YPOm]N@`:uHQ47/borgPF,^5W0$NcG(ou-bg/<6+UI&C,(<=gHa6R_0fT7H9*67_T/_$j/ILa&cCK>Z]fh-\,Z
+%`s7o1O$="#[0-.l]T`^Rfr3uhmG3G8^Y?A!"Psiuc)@3X>$^b[_G@;.jnh^JTjoUJm82%$>Wu(0^r(221ZYZoL'^DhE)8=97/rur
+%AJDSZ/@L(k!@p@ghGrjGr_AYlfuLl2BdB_mb5>SK]L1;u#pP/q&Bc_%Hn==#99nDl.OJctBnpM/(1rO(%6U\Z:?F',DKMDC&e?.m
+%,Dcj5_HKL=gukRbaaKeRVNQRg.,[X(`tqa#E-`b+XRbQSZEm%Tb*`k(HDd4[*gV8Cj9?q,AC?7J`:K`PdMu-8SV%^h+(Hb=mZ0(c
+%`.@b(TN4F)JT>#?iFT8MghWD7>t`kg@e/J$b1L1M9,6HF^E:3Lk;Xo*pn$afa%T<3>HIUI!-4ZQ-!1PN-t=EtO*ju6Qc+;q>W'1?
+%:-Gr$j/E6M,J0eC1*flD)LlJ5<U!6LI`?K&=u1:d4m`))<=SDfU#O%CeWN>JVE>rj:D?iPpV`:Pl&VF-ZHp9E'u@?L&N(7.Fn^/3
+%Y]@.3TGi/F/IG(+-SQs,/(i<,$%pbXW)ed(OpA"A6"jbRFqb.]@Cqt++mD\%j6Iibh$4,c]DLrZfT?U8^ebQiR)6j[9O6]HNjb'^
+%Fhf/l.SPR2V4"*))#8$;)&!%#IF<D<qN%HbVF<'g)8,#<=)'t=VjNmDcbF\+@+1'7ZgP"Iq+\sW2@RHuYWGEZ5F4[q<0B5]!kA0B
+%gKTRi:'U5(FfN5-"!XTjg!&o/*KsXW`*,K2jo5=M;99U*3AL=Bal?,k$9o*Z;n))>-;qdm?&HDA%WcU],mBeM9O-*+],C6X5*up6
+%n;fUF4V)AV)N+/@%_5QOQD&>Pb`>!.7-*t.>t![FZAk-FY>tbs/8W!HV1Z+KMlr>d:7Y"]ZD173Fa8i=P.)]<+Vt5u$:9MJ=7[]Y
+%9@gdY%>SoVWc!ZL,XLr"niB19#"`K"5I0\#8d<PUeB\V\5!fTB!YZrR)&b&oa-QYJ]/AKCD/8Y)/,\EQ/CQ#:eT#=a:O1\/2bW>/
+%-UH0Br^I^_s0T(LeX\qT9',0Z,R`&Ng+^rmd!7s_:0aTX/b;qTP%8DL9t2[R3ab3IJF.Z8R+1O(>CZqM*4'/'k_,cWhV,5aaU\5a
+%<`+N-iJK..hNFTN[nh;TnOsnoH6FO:_2FL=\D-Z5PH9#$bgPg!D]hfJ_TA&]g!o_b+tij3qu@r;nSELGa#CU#3)f1_[Da)eW90h&
+%&,UC'7iU6r3)mHl/@!jdbd@g5M0VcWS]O#pRhC$I<%&<HAdV-Z'$gSQ>*XD'M`74\9$O(NSk5-hpT'>;MtjqK+*iE;\_s\Hh-7-K
+%Hd\;,kY`;:_?Ku1Yl<FE<GuTG+1jDOdTr^%?l2_H7Tn1p*$Ju1bs@=2<TTS'P7c\#j"N-A3Z?^k->=t*d7>EWe_mY#)F$hXqC<`s
+%!L+Q5(g)f-D:<:N;hjU-*r+j/Mtp)n5DJn/s1E*:kgh.P'KE0XgoZUhgj*_"&?*_MrmHk*9NWGFZ1/!.!-!VF,])0dmNi!Y-[?f)
+%IKOk-`3%$1-*c<*CJm:dA5d.g=U(if4GBdkdT3(=+!^!DM#iO\A-2OAHoJD0QoAZT\<=qr81d0^#e:*YeF8]=(Blnl,)%-u=IYcF
+%r`aaRi?]sVs6/'I<'ZRB60/),;7Zm%<'$-*Qtipt_0Z7WR\WcI%?l>$U>udX"rf)&R(uf@G=o>Z5n!k88Q()s$1o5"bre4+PM&6U
+%L0D?X%I5IfZG;SaK:G2L?H</O0%\E!pas3VQ@()"LX%I/:R&/a_NP.m%4I+\dYUH9RZ;C?*J\,.V`;U#RX??D.l!79MPR%a)em?<
+%%,eieTM:]69\XrSnRe9jSr/8#!9rh(7K([%:Goo%%E!jK[E>Q[Z^lmS0I=Gb#4h-c#h1YLh'.no3\-F,;!HaJ%&6m%PN]eF9TiqK
+%ncu+S.Y\U]@gELa--n'f.=HB_=2lA/oQgtc,L8Y^QMD>V0uP9k^$L[T>6?(M5($,0V`W'RT57&8`*"PnY#;-TYFs>E,pV0!Z!=5q
+%G)JJfmBKUdL42E_(V]qaT%F]eA/Z@[ZJ7HN6#[f`a,@FD[\71KK7IfX;PC+FbPX*7Rq[>u&1\)+)'RNCL10oiINoJs2@L0"&.&M*
+%e-?NeIrnYG;O1Zu.^4pe$mV0LV(Q_[n^su?3QXmO3nf0_!(n5q[9k+@JbU#kR;-cLiOBGj;Q)7$qf8#Z$Lf(Q2*f<;C\9F)Rq[<e
+%$?HG2-l2-VCrRNtlOXJ@lYn1I2]G5I2bOah1S#-tr!K02e1L^jNb(_H+kL*X_p-#E4@omC4#Q?rO.ufT's]I5aZr)-ViSdk#b1"b
+%7:g"6LOi),".Y'IY,r$*nJp]94?naT'iiIL!aO%1iPc0p(Y([8l)<lR/M?<eLe*h(eX,1==5\\+*9O6e,2ONaJ:nN/PS!3Lmc]2Q
+%TD!DV+N@fb.b;C<F9E?DO`%!B0RG#b3?^]q@i-m1;Q]G<OMlSXo4FSd28AER#c0HUhmY&t&U:Cp;T@WaNt[uM=dG.qHm;o*jkYms
+%=AB-!]7I6V$E8Y5*35AuoFdU\PV8ZonHhoL/>XO[F=men?0JXUfShQWXsF.9FboY]CQ(4,r$^i1,s?q@."XCIL;?(0oA$(;:;)VO
+%mX9"3Xn\W*f(i'AXhs4/Hr6Gb#AmjLjdL`AN_Y</p+p3F/;C"GCmnUGT?i2aJ?]Y'?ka;BJ#GH.*5_bh-'+oITCFqcb<#ZthdmWA
+%"7^0gN+m-cG!QUKZD#!1Rtn&PqTM%YES&W'\!:+&AT4\t?P:@\MigMK&Mh:7A`R#h`!2Vmlir.585aSG$K7?n+Wr\>,S]9hI1WEd
+%:b[9Uo4FVeQ+Eu6UFgS"#Ue#L?TJp<*sIco$(Sd>E#6$*oR*S#DQnPfB*muVl2WYH2)pG7]hlf\Z#).,W"_"?=+t0'@KWF:lSK4>
+%P&OO2Zl>VT8jgQO.##2W#`sJmh1p83cd.2J;^iZ=_V5q^GciUd+C3L+1p%/Ae.?R;XBbSYJ+kR,RVrOgp4j/4kSmJC0K/1XfW,Xp
+%k;u,r@%1-=YRh`^c,cmo>)FT[P\mEmaP*HC>4-')_?NC`&Jdi>lT*+sR42rUf(F!h3A&Z(+0pPLJou<eD"10Vr1K\AJ%'R!\q<g"
+%kp]hlBo:UZ<-](uJ%UGuoc5m9ll"C5OW;IVMIY223pMfO(,oGtckNMcs%bI=OsDeAr]!52?fV(YF:jhL[kpH:$b;D0Pj>oA(o?BL
+%csm$61=4)J@>gcH<-<b<PWG85:2oE&+e;krEaGQ<<AcF"rX<d8;RF<Z&S<'B'Wt(Ka2i.?W>@9bj_&fo`&L$-$L\Xn7&kf%`d%rq
+%ISA^"B2VPI0T<Y6-:B;Qg+=L%kRjhF<fB6eoM3\>ltXKFM0]$A&gHra.;Ei\#!5;5?2B<>1dJP69["Z!h>WPh22_EA<ViXnQ_`g;
+%(]6e(dPnsQg&"n6!%HeF*nYHbCC_F'qKT\1PeEF_.).M8.lZAE@E2RVmAG=DSEn%BkjWCrS&oXp[fpi,Sc$,'jj\$"HA`<frnXmF
+%C3-bj+,#i7mP'=uf16UkW^K3n*j[&YPo$<dm+uIpYGQ6`.qX?O"I.Hi5$*GJ_=]qopEusd8h-D<rb\au.S#i)IH7YGO-sAc'C[Z*
+%e>c)VWk6E8]jf(=e>_lXTMNf4Wq&b[icM4Gi*k9mFSqN(Wm5CRjqFF5dc2l='k&#c,_3-FFt\aS&$O`+82ddI[Oe-L.ATb'CWZ/h
+%d885-G_f[a<>si;,f-VI$77>)DNZQqaQ]-M>+$*VDa9Gh%re,jkZD^pM_V@ij)4eVlIJI'"f*d&@E*[kiOoLWJ=.AI[>`@-o"(lp
+%i8T]uXX0F*l?3M>nq]i.B"^pZO*NJJKq+Fn.5RiRi&=>";K7Nu/Fp5_gH[ZG9)LP:K,PMp"_*n6"B]W3EM'&Lh,dKOf"m)MRLCf2
+%>P9XH:L=#U&#0qm^(B9L6P4oJZf/cQ^iIj$<tNT5);u\)J<[?<_2P],=q]X:+j5B31`O=$ZE^oC^B3EseJt`2>g9?*Run?2+=dfR
+%&^_0,*6o.?beplu3Vi.>\8$#JE-=5b9mJWB8pQ?*Tna8aoE`HqE%ah;(/8:k0OR8h,%,GWp55$A7G%`="uWQ'<_oSrL]Qm7\O=fp
+%iD$#h'A+.D01ljC:rS0s7OT?!0Uf<4m&Fs]N5*SWMjPJ"c!-H8pJd5KJ/g"Cfp1uC3>FcT$AOR1='k+7i24;PMgscqgd:WqNHt]7
+%r0[MbL2/P>br[6s@Tf";n`j)3=VB?eW+nj)JNLX\6F:Gc)B\K-Xqp;_0!7abiQMqZ"(e!gDQT_<X9oE@$OL['e(9ANW*Dk@O-r:f
+%R2cSciPI,O33a'!mlJ,`OQSi&OMPH8DrT<o"A/0CCkMTtnHD=4eYn/G'2GiIcaC*MVs]Ge8!oHQDU![boemol4m>LpiP@40>MPE.
+%L"0d<K<!oE:2o!:E1=(i@C'O*LM@/Y9!),(90%h[jUkNQVG=Ve[0"7n#uAu@/gSQ3qZPO]*$(i5!5;h++K`1"JY(p#eB#?G(*UZb
+%loNJ5q(!r>poGW/A#!O,9_=tR%Nu/:aQrJp[I=3<.blS^qm`HdGnO0'"nB@XpnD@Bn7gJ.>l9uN`2t^>T,+L^I#FtF$9@Zlm0[6/
+%#o^AhQLc/qps(S<H5!C"24eDh_B)Cui_#$./Y-5oSrutY`VR'ZH*U/M$K6iQ@]2=%lfOou!m)LNYt2B$lnR>Tr4ZUKoqqnA:u'l'
+%XnLf.?sb$KMH*l5<@U7tJ0cG<HKPH]kdGF<D5B:=dRL4)AQ66KGI-.<j2[rFZ-e8L%=<[h*NUbflDO-5A_EV7Ao8)"XNbm&cNa8"
+%RO&K#J(0`ggtkg@5>uEj%,SbO@9#gXZD(!@#VUnVaWSKo-\ET0.6D^`HT8-k)\#nE0rq]0UC/s#cE-"lCpi]eT<Wh6-OHt'H;I?N
+%nYXiG7RBo<QjRHCE@c7cSmF<J(q]hA2!Sp5ISA]EJcHT!&ZRk3A8'^4nWsH7"GQZaS8ta%N=qei!IAQgQ,l=%=]&$E>uj4W7??7*
+%?M6kGJ/'5PT/c-cCp_0,j9[9O#m2iH$`+m,NQh:($_e^;%o\K`86_\mfP]K4^2].>s&7gS^mlY->68nIqaFI#jA)^I`Un/$ck2rB
+%F;f=FPRAb^ib@-$Pl-b+`a+:X#fL&S5*>nKc$VK1S!rtUjT&oQSYr.JSe!,bQXn?\#W#Z=3o>fP6(/b<A)Ro7#j)A:h[[($+I+$:
+%$h.g']!XLl<AW$T9@UE`I&qM,p.dCUBYnE[V[5F<5p]]oYjlOka:DL&/@d@'Nc%.S'\<=@HV:FPL<M?o">WZ41K@SA6kQ%\]qpU8
+%bZ!![P;`sRmD#4Mi3FmpJ>fYJ(^Q=A%bF,9`j*a/FU0Y1e;7/[C=*I*K+V2h?A`bd*R+6Zj1rqqkBJ`K9,@V5Z6AKja)P:^$:+5r
+%m]sSq=r@aS7n93)TAoZC11=t3U;fjl:K==le9=lV1FkAiR)2da*"`"dl,.MDbHC@o$TKqsRG8nFKmDDG2CC`O`pjPKPu(JA*[r:P
+%1Ui1qaC>#VL<i7=-L(;s*YMOSRMf%#_8Yb"UWKcN^l++$-r/9$"V0l)SE7_CXdJr/B=Zq%L*m_g8]lHT(A&@#9LDD,-Y;\5G&LB;
+%5Afm?(u1NoF:5KhUacC8Q/en1JZ7?K#Vm'SQCRcod=<oI/<dmFVZWN5E^%`oRuX,WW%Q5*[G6!bLgJ,<$lr1"=O"r$*_p"FU-R1,
+%K,!%L.Q(.b.biga@sF\@Fi2j,N(pN$MXaQ6dOo3!EBc!87I&Ei6:f,:5iB%Y]hGq@otF3*`6Fj=HmJ]51+#YjP9iC+:Blj_Ql,d;
+%[>;SZZ"%8$V<_]"`*15,B2(-#.<)9p;-]&b^74e4mN6WR45hFros`c.+mb@GS6>i=M\aHOf:cQ!q>kPRk$F,2*;DukSM*'86`g*T
+%NIATOo)%28X>>leqnS+O]#B:u*d).@<VR"_%C%1JcoJ2$n.a3HPsTs\ah]*O-e%hO-1Rl\$qMFm*,qRNqje;#/5nXjEb+kg/khAA
+%:,NP`D21B$1\:/km(_-jkar?Bgj\+.`)NsL"]LP+_1>o&NF##+-H0^``'"]"M$r0Qe-0RabS!bRUNbk`'1K`(]F&Y,([40RO*26l
+%YZUQg9Al@d#cYd:6,1eodH\Al4(XsQr[[ig8SR#oTW9Y+H6/;;)$Vq\lVrIkbtQo/lED6UruafXMoPn"=0J>jiPV\)7+K&nc$e+_
+%8@BS)#uqaG<#DWGA6/bcPio\_VnYN7ZuK1[L(oUA^_A[>%kM9l<nqnN%P@i@'7"o+_4$`oKMXKt:%"#GdR9$.P#ok>+j7Wb:u:EY
+%3?-YrnNmU?m6Bf!Jq_pAKtnpq>CWYB#a9oA&-<sW:UH$O7kl).IctNJ6YJ0YJG?noe+QE!4>l+$,RnQ\!hg%KC0RA],`i`H:[OHg
+%_nP$P^iD"ia7D3g%qZ[@\%6T/[KDG_JFd?pQ6BH9c!9g;W-U_0ZkJ.L#/$lJ*_Qgm"RqeG=[EfjPKYG\""Bic=&,0,FegR(\'baV
+%%?5O=Ub+Y^C"BELmdrXSG[_Nf)UI/S3nfUNj;VRCV]?0i)()k!MWqog&,EhR9F2+@"AhY^=h9m?EbJW"fU=uq[d"TKSjM'D2)H_r
+%fT/R!!#-aK)\`439V&VE6U9<j$_RgV35q<A?%IB`k>_`@,eL"m,>W"m&Ch.'?_gnl1<!(hc]VmKnpOK63h8JK@C\H#^b1?L(W:9K
+%f/D7,*(8&o"DeJ9MQSueTZrL\,N8\!hT#ao^W?UH-heC)Wg$N!6*PWdI?!B+k'64Y8)5%_Fm2_93WPfs$(dWPWaN!&.KMI0N7.<k
+%,[kdSgfd#cW_-;E@bJ2-)t4*#d*]5>g`n4KL`Bf?WV[snLM6aX!Pr,]2?US2W([ULCiRaBCWS`Zo."1L.t@VP)G2;*%?)i+cZFpF
+%2J0LU5)6\)?1?hNO*\l9`.1fT[H=WNfid[+$(,,rR"/!H':)>pN=u5A.+2T,2!_sZ76FDb%ZjAE.9.S=-PjRI1iK^r"ssQ`9Ytsf
+%3/'1D9KRrtV/j*`<`k%qm:,%q7XgCJfF95mi7Cb3fOf[;0p_nP6_W8AW+-EP#DfpPXeQJqDR'io)p&FS_W:o)=CSX!/+OP&g[$0e
+%En$lXTn<@*<)F/+Y;!c0QK6b`34e=06KB@@(%<:6Do3i`'H..C;&7LLdNO381GJN#5Q^[W-fYBnFh1>>%X"2!YU$=r,7r,OXYT>J
+%$t,&#PJ2hD2CiH$9*"ujp^5ULV>N9!Qg%J0Ak>IMVjJj(7W@c#[.Mj5aDQ1E]"-V91b4VW4OJ:uc7X'EOf068#/6Hq/=5*O&N61Z
+%fcUZq\#<mhZ$I(F4N?qI$THUS1!Euu^.\^/\GZsl%qQ(Q\r40g)L5l%S$nLg<\P.]ADG_fk;1)#i\<L[l2ELW,KS.I^oA7VWrb%&
+%M>sf]lBmB(7,K%sGa&jDkam#%*@3BG_T0]9hPS&bn?NVLDYB@(Jd[,)(E'.'I5JNm(8U\Z.R6r$^gHZ8Uh\?]F5I=5VB)!pa)RDY
+%;sHan_NU]bV`$=j_T6VHJ"VF@/AM;.!Xqs,CSf=gaNLgYJ`2(ej__;;.ZZEDW1!Y93Ou[/R*Kp!gi2SV\P#+.9/??)>?HM@7F9%O
+%UETD+EVL&#7^JP#$](>$i\XfDB@BUjidHDC@M>-&kRV;2G1M_3gqB\JK,\(IP<$GRDQ5&!.Y&6_gr!0D9Do_)gP!pMqAT[YZ9PU9
+%G7W.eFB-g\f."-3L81-W#^*/nQ!(Z#Wi9F:\QnG<66YA7$!l]564mms&P4;U4-C)ZE7lL^m'^&Z/cW&%<&mRfmnSW\?+?\<"!:`@
+%Ve@jt"X4o?I2\J*m4nCFBq(f((X<\e+FcI\5Zb6qFM!o<#*?B3jCY3"+dp(biQ@$GFY@T&a93(@D/s*4[BeHJU**0Fdb><^1[WsF
+%'m@VlUtKe[_t`DJs'o+.s2q;.4crTe<V!5%H:0$Y71Ee\/j`FH7oj3H4@7BV8->-:KMD/OSpsPMAC8?4'+;jp#V5tJ($Pm5P_T"t
+%d=asG0#ZMAo&Djai)?["[KjF5*q$TOrc1!;lbJ>ojOC#c;PM8K)nsO+HP4A272Le/5;9reDHiqYQEhel4aj([eQ\7,InZQgoM$s"
+%cN(P0:#oPkj/.%;V8iuS4pD=RMsG?Ai5[,=>qd9F=M?B_2W)qY<#30_bE?P`b4>PKcpo<;O^8<XVpdG%^sU5L<';r6O8G$jG6rX>
+%;1t1EEg^`%a2+osQLGo`LjnGIOQF&HWOXH2Z,ANu4c5SoQEH=7N9S$&0=0I@E>(?9Md=@HU9SOp!\P#m0Mi%-\'Onu,$>KGVJ7F7
+%WT/ciF@Pj^c\_jT,&%qqLrc]l00SR#o6=&'3SJhSc2jtnT030hqp3uKR)NPdDj)_XJ4Iu2D3K?AKi-NhLVF*C#I8$6d^r,T;D?qG
+%/1_Oe_qdsU1#lLKaCH.#\1VGs\&^_8@ISY`:<ALc\O;UpRa3R).A7I's%]hg]5YBY%.kC\gB<G@le*KCZ2qcCd"Ldh9TnI;7Vs5`
+%\4'qHV-eqo*6=tV'4?a!SV1XOqbZj1$>3i:JTA;Z*;*EJW<oIYOCtSZ%?Lm@9Z_Qh;o`Eh].3)u]fSXj^..ZCZdNr[;C<T$"h<q\
+%3.J8-mFem(`(4$!K1BfA>P/U8Hh>d)SN><3L#J&UE@IoDmhlsDf%Q?Z#EAt-ET1%3\SCb0lo3le;tu$>:c/o8&lA<WR(%p;VZ'Z`
+%mZ8@lMcs-3Pa$bk.ia6.-DG-7&NT9?5cg*e7E)PY1fY9=BQkc?O:dn2m(YCbB0rC,--H+Ihoua/!s,s6j=/HG6H(Dk&/[FT#Q>R`
+%X/&@O%u7L)\Tr4o5R5h?PO+LPJXHO,QsHqd:h7`%/acd0e5C0:pm.FmXo/m@C-Ehr@>&+d$$[s*:El/Cr/T91<jnD/9B9AP5,hPU
+%p`@T4PY)T)%nY/flafOeEC$+\9DMF=E*$W?%"'LtXI\.TPbi194[I.;d$7(]3oMOhU6FGJ%:qS[*90L[/Esclf`J\;ZMP+D-7E"?
+%VGjoC+Gn't[dTp&9rCs%V6c5*=b(<_fpM@WPQA9V!)VGXS<.1::0qM<?pUoVRLJc3@1i&9M]/U%)M?QO2[^R;jUlKE@S%qqG9.E.
+%@=08R*#;7V.V`qW%tOBq6[>.oWTn!<k"kq[LEd;hlkK0C'P+D$V;MP+k6RcjBR\;9430(nPUc##+0_.KXU+kQ$P;2&(^s#e=lS()
+%c,pbL.ZE*^W(,>t"";G,`3DbQF;.7G3I-SFAM0h-Z,gN$P6&V(]7S=hJHPT=&D!8F[RibTV)4m5[PFh\0G!m^U],0s;.fVnit%rS
+%oKHe6nr(U%crWC0Wr#oYQ_$bp6JZI\fj+%("*pA(WCfG7Q>]'&Vq@F823TcTg<u=VeDqkRUp2iE)B-.:Q55@IgP[MqWp5Elj1@4M
+%*&RqWP+n)^eONk*'n6b/l$h7R\YUFR5]=kMUtth9mub9-TbMRBc`<D_h1cX'@6Dk')7oCK*f!"R<4Um`11=Z"5s!)1RXS_F2HUK@
+%`M#a)Y*WX1e<aHh9T]jAYM'+b%H9-oAD9:tJg,gk<26K(.d?E,]Zl9I?Z]PN14XW.\+hPW$\`1OE!d#-@_cmU'NoHRS5&)GRQ50c
+%l(BS,\T&`-jm#.m!\AIpM7o:],jDq;>Sc8^V?g'GNaY'Y!TN]MB_40H\+u$C@c^K\MCcQ/22DkfJ*Mi^H6>c5WN8W>\*15#ls#(Y
+%:l:0]/g-f8$<mgT%Zn7*K7%uW)\pm8)IR9Ug&OK1V$nJLPg:?Z<jHOqcmcuYa&r=()<'^R*,gDM.4.VZ;?D!AA5^OFWG/]K@G,W0
+%I:Eh`2$PH7hMN7_9q,8?DPDLcER-mXZmA1H;7\/)E'PQf4A\iq\t&@@*L(psiC0dA23;V7g@rL9cm29N`3%)pC6s\$hC>3R'$AA[
+%k#?JK+Ya.M-H"q4!X8@]0uPc1i@cj\,5WQAF:nBR).UJ$NVG62Ui'EuJ&qVF,1>J3s.kRJ)krhNV<.fS5JTa8.=k90K1(8mEj)2O
+%]d./[3e..*+\FYkU.nJh80PE<S/6Pd#ZQ#_W7ng]389gh^&lVWA1!UW3\>E0OXL+PcSbTfTC0??p1CVC$^@oQ6Ks/_nY%PFS7L&A
+%jPSp6i,(Zm(]TGoa`aD6Vl\sZG#fB*3iNG1@U(2-o_iPs`T&Vr/nn-);8]^;Q3,PcMA.1DLM[*L\%os^9=J$l!0;YDAp78"SdQmr
+%)/=oA2m7C]Sg2.2L,EXh=IP9Uo4k.3*!04nUG-DL6L)am?krKY92ohZC5s^"!Z>H4,5]gd/[o2A@g,UWKLCE4Ijg'W<C2j?RYMU8
+%+.t0Igd]Hsi'BjfFN]f6AtDD!(monh.`&[VI6m>?2uCbgP,W&g;OK^-V<OQu$Ib9X6;$e_*^NN0pf8u5'Kpk:@]1'Y5t=r)+/hG3
+%6J6YYC,+Pd"kDBH50oO(B2%X]mhR5E5?700#4YBYgs^X/9[hYu_$(QMU&mI/6$Fduk_*@'AM_Vp80'1^TS[@qQ"LnTF(-k2mGla(
+%lG`C<eY$45OVQ!82`3E6!ahsS,WD(Q-5#lZ4gH;:M(:@.cU_DPGsNn7G-h;N'<ls9\g>I'dmc`5OY:t_A9NegmU$[kCm6//VqUZu
+%YTcf0MT7j"oH.!JZ[4G;_bi_EoHC4WZMSM;J5p9IdTM5*fXU%<iij+@pkS!BU#]9U7lQoVOF5.9$;]]k?f'_BbcXE4SFKj'`^qpD
+%4?it7*:"(Xp2/dMli]?[n1+7*bacWp<-Uu7`/fJbMi'C^CUo&&Ep(!#ETm=lGZDP`WO[[7m"84n2cJ#f[*WhrAOrS-nR?2DpW(A=
+%8>-=<7o37h)$&a2#+]'I!P`GG:suhlZUlro0er_m45spa&&H;<"c/'`,EQ"[qP%]=:bs]FQS2)E+-ZUX+(q=&MV$$&*.R9V+W:n>
+%q,5S"!.A((N]^@P6DncOJ*GSS5fC&uFhqO"B!9ZU:#O9&(J?Qm)-'De<KrJEh:<*eImR_k>PeGd^2^;W,uZ37K2ZncL:<PUJ^CdQ
+%V'0PZkNN#07m&QO[96cGTMDh@-R@H/l^1n!jm#_k<%_$R""OWrYs5['eO_2g(dQ%l<V<BJ/K5HQ?,b`mc;AXq^s)ul%>P22a-^bS
+%OBgl!$M]OuD<^g=SQ21]U9O)q;.`<T*_Sr8I@Qe.V7a8lpd53;I#4aP@Kn;Li2Q">J<]1&Q`?3[8?\Zg'&FAPY\<^J`K'i&)=&G"
+%4WGiX?Z+\4]*MXPH;r[,CE<1%alXOrloJU`TJ0_A72)2iBF^]hY5&meP-]F2P@K;PYJ\YC:Q;?Db$*B[0TLD`&#5Vgp(E7Lca\su
+%mT;?Kn9q25N,uJ?^7H$D"=Gf;<B&03O!\50ALD0ui(/Cn+bYKZ:F)I1UjJM_b`GU%[68SW_F$2!([@=KARsST_BGSjn5<(:5a`7i
+%bdbbh_\$?\AZ=TR`!f8R7:hA>?t,P@3MkI#&0c^Mb>O05!&jbgDKJ%WcaX2+-A^Oc'PN_]6bJ1VO%-9>T%_X-pKa:IcqKM%5e@I9
+%Itih>5Wfmo$pPj*9f_W7PRJ?_^mU!dJWR]n91cuqpRA-/BKY<Vg:&;T^mHa32_eP+^Qm(b@[CLDO2#S+$S&e^\3USVFgn9r_O0O"
+%!d>:"p_]h2TEIBL,l)?g*ask6\[0.^1N+%H8aCs:Z"o!7$Mfgh'`M(h*JboP];cDbUF:4N`<7PJ0NMd!,Vlm!o0)MG*+Rf$E&?Ql
+%M3P8c#sJQ<Mr\=d7l)[H&2uD@QC.1sSFS]<0FQpZ/P87aZ@Db,T3.^sEMhp.,]@*.l9gO1(ncB2br7<`oYNE\FJ*!#?j2?BlJ;W5
+%S1#(D>!'=N7[?#*$)\cr1h[,8(5AV8&\q-DJr0!@"CJAh&E8q)UbN,d)Of[B!09UE#@;+Y1Qu!YC+R7+#_Z.'*?rC;^Qb!,dlK&,
+%]Xktep^SL:_+3-^mI;up4%rSqRsGY99tp\+**I"1jn1EE7d12+_Gioq7B$g)MpO1N(8"$rCTn-gqBf7&`E5_;2'pteT!u?k.;Z,%
+%<TURkjsqV6<2G'R_FJi\^FY(@,J-OETm=9d5pd'NCDG\c-!Q95A`Xj:.qVP&LKFg]]6QCJ&jo90+<.1`8$";(.R>5=D2-tdQmQ^<
+%St@BBe\5hiMFhOpc_*&J>jQ%/T#H+.SQ.-S[rcSp96HZ&p72B(Eq_?J0#Gb;;ELSh&ncR4FR"M<]Wm8t*J#s.:sH3b)N;26#6eIt
+%Do*f,Q.W-545]c\92?&js7S,+RRB8u\86(\qa6qli3Ma54*7]:a)0V_SW^$1nLgi`/N7WYW:5&@EVFp:aZ^t/==5a7i7p[9+&X#6
+%7E-n'><\9?f8=pE#pLo:$7'9MEpP-%`13,MMYPg>8IhqR2FaJl'>^@6(-\XSCk7'CpG,Zd'FD`X>m8GLTLdlBa0_'a_4HOI5/3.2
+%H9$8,KMn!9Q3jK\Ejk'"+a*&Y_k)_lZB7`r+%;s(i@S&6mUUS>Vi>:WnM=8B_9cQnA0$/kP"n!,d.Ts;oPlc!G;D@.jJ%qdc?FD:
+%X%=Q?;_agd=N*qQG6\h=;>+3e.\`W99_DjBh/KHhA;sOr"iFa?D-/AiP1%csSMq3+UWGXJjPn)\Z&]TK$.,3_i]W3gV#g@@6OW[-
+%s%pjnWE:2DJ!*BEKJeihAUpD#nF*J5Pm0W@jW:-``,dJ6iaD1<)XnRU3=)Zf]g1-Ki9iHi-aTi1IP%spBS]%6\Rg4mX::nsG*[7!
+%07u9[A>plS=1]C>SB4M],WHsHnU?K+mZ'u'6@OKTNM3A%L7?t0ARKg4eqhdu-mE4BbAM/6s7ti]pG.Zs:g%/Fh^T'O'n$p*9BM5u
+%r:<hA%ej&I=UsR9pCVc2AJQ<k'qm"mlL2K8J"mGhTbYDq@m)(gFXh&b*R1#RqVd!pprD-]:3e]Y,ITQaZ5OlkR^,H:7hH:s'9'gS
+%*8'EWpL^ad@(!(PV<Um,b1WHD/kn(%%3i=+e#*(=n\uKqC%rRDOgl[.:0%3HqoZJXMq/$kcr8VoJe]be<=5\/'\@^KGAeoX29htT
+%j-VZIMeOC*SP9p%5oE*:=&sm1:E_nB,((SM67/Otk\gLKqdjesNt=_co]f@CE(&(\-4qMr'MHRg"%%#"R9udZ>p5]YUK-K_P$A-s
+%1aA6P!in6B$=1"',4fHB9GU806J4sj$G))QT;W/3`)\KY056'H6>/9Ri]mf;s7q",f4j@>f*!+:F/'@/dj`/X-j!L<q>eDYK^4Ku
+%Zbn)tW&'pAg=e6kZ'njRUBm-SLo6"+a)<S2iP\/oXXPSAnFOG&kslM/_\F1&fc?/GWd7O3.YOV./u_$<\f]LkY0u:19"S'!Ed:B4
+%TI19(Gr.pG2LO0AA6`*N"q([a>/k<]H$Ze85I@T)"0/B&b.Zi<.'`h3/Sh8I^VID9J@m#dD\)bCZgaA1]JKN%9U[[8c+pa-HQA/K
+%;;Q,20q?`(lnER#Pf"WjSg\5o.Y5?I#$?i%UFJ^\P+LrfAEDL'`)JtpI`gs2JoAh#<08@r[muS$kp\fE0Yu^/7&O3@Aq.2"([M$Y
+%E=oXjXu;J"B''%ipMRU+,[#<C(Xt\!MguZH.bO]o2_)cOO\&AWCQakm#bb*8$)=(3:rA\Fo_45cg#a>q:1g%<64X./;&OO>4P\2i
+%R;L]*mBr0tR?E-=MLr/O>kQ1Q=L3'?+ioL;m$@ul(f:a',SlT>dQ9::+r&h#M+Jkfq%N^WISb(S]n:gi@"fnc:j7qs'3>)p,1j1A
+%gA1TT'ch@)G+Pt\Hd9]LdeSm?L@nU1>Nmkjo'qNt#9<:aSbaqY#$?.%otU;P@\-[F6p:CKm!T+^(5A6Zg'enP*Ru97fTBE(\0arG
+%M6$ht%]F?9*"ofM&Q-AR9q'^HY't2i<,71F-RKDk'MKP=n%1?tpS)F@'h@U1&M=J&*e8>LjGTV`aI^!6g6fJ^<&)J7=+H'eEuuPp
+%E4CI+RoAuQ3VrqAXf`WAd.T'B`*bQch^8!2F&@P9'.pX?67p1m\fX*`NGBi*6."j]J^1j'/a-3^kKSmHAb*`N`K44^kFQ.>G^4J=
+%QHRW=]8`)[BI&NAgbYT35XSClk,FEEUKdFPTZMssV:X/7L`HRT[=)'ukiU9&gXtLp9J%(:i&>Cc_gK<YH0`1(444;&f6?:2%q6_#
+%XBo+P9'a<662+@sYc:mFIkWGYWL3T7,,_HW5;9MaN4Bm#a(@]=`mi%V.=mK;-D2?73#Le:<mD\7].&`aCe#d#._"2sV76d.`Yde[
+%XGC1K5,TpgI^)5AEI+bD4M&%@NVg`YU$kZjgt-`B/.7M?'=f8O!bMNi2)]3+C3cP]L2Ip#B*/XJaq&K.o2gHU?rU`DDhD4@QG%LI
+%[UAPh1o+oa%>XRolDC$j5PM6+%$9#jOs.X2QFp*gb\qFdo>I5i7Mca:.Q'a\B4QdMBAg=O>XKoY-(?4;,@Z92ri'n<EMkc9GK1NE
+%W(ZS9"@Opqkl6g7m]e\:WJH[KgJhdCp'h665g)sgC"7kNUXq`2/"%i^5KrsKXG<=fAug7L_T-e%qQ\D8Yp_#%IrMT8nS'HslXOHZ
+%J+[pj7KSVSB+J5aj3XHLRsb\B8ftNHBV"$W`!YjP>[jU9Z">1X5fF:=#mM4G#X&`h/2L^QTe[g(`[#F>,gLRX&=frR]j=-!_aJ;W
+%*G]2e8I_/l1k/J"=B.1uQ.81R@Q?kR40FL[J0$lKeX>PY"<ccjYVMEagIfNaNh`=JG7b:*2mqDfVItAm3H9F)X-$C08?!]^7AilF
+%ArHGhcRoQ;k,DQ`hQ$iP=R[$>(r/:maS[k0"jKG.rWMj)T;%^k;T(KDfTKHGi]rBB3=)%1]#?3sHjt/jFVnf>3Xi7W'U+W-_\%#2
+%n;`5R_)4[2+@re:CTI@W:,j[EeT8:O95=(UV)L;adu<8P\o./!qf!AY0S&i?`FR;C&j:@o+T9O8c'UF5aQ@5HWt@&KfG(9M@UjUK
+%P:DGag5$LKQm^.T(L=e3I86F0U2;!HgETC[Q(SYBFXXNF9=qK69t0dO=P^M,,f="`Z"E$Y$JeG4+It)>\piqXHfu]5o9jM61;3UJ
+%G`1^"%/rP1gYWU<r#'Ef$VX;q5">2K*7+E%d]V1=hKj"7h>-n6-jV*#I/e6*j)dHYD*WmOHs%64\)3n9hKn&THA%.YD]d.Rq$hIl
+%m&sqX6KX5576@0I\3ZV`r?khGbr4-XORKa"'4rYeJm[Lm(j@N*/>%\6\U&A+D]T5%Eh9^FoorV/?g9525dO3$5QGF^POg@_e8FU[
+%4Sp`?c0iD-L0;ia=ef_f5>PYUm;ALnLq(<#i^E&*!IF!tHb>?bD8pn1AMLEOZT'/LaUj#&HI:Ls'hR<A#0^Go$,L8"i,J3X<(eTe
+%qaA@K.L-0GB7j%)jWTB_2*h8]0P93c(_E:P!f]HJVjHUWEP=9HO,c"S`EIA>.LLnc7Jul0YOc:)&LcKJ)lWTY$([Kj9A4N'WCm)M
+%`gCaqf(]4Z3`EuIP2cD\ro&*VB>Gh]D4#,OSs=3GTf$4?c_5F&:\+QCZQ>#.F0Eo8NG?uE$`TY,.8P*jO?,I]`0,[]_"G1C`R0t*
+%iUD3gmWFBLZE#.Rn7Z@O$_E=H@K;3\,Q$U(N^G64%irRKrK7P2-F4H?)d'6G82=b[9t8DTkm>*?d3lf.kZk@9'gnD\.3L#sZ0PWC
+%fJ)B.&A-(#Icf[Wqi@GK,OdY17tXZ<dQ]oSV\"i<]N\65;4p8R'^m@eJNbUtJOs5+#9AkHGWA2:U5't>*==$#1VlH+UO)=FX)CT-
+%Z1A,AbG&4neT`C5G9>/FPNsJg8;?J;/VdP#T[5,KO_gIXfU-XWrXo:mr?00dHr"7KRi4NQgR+uP#3)Su<9=%LU7`nA`,<@4=[[tV
+%-n\=,D:TOm.3U_>/<JGI3F!%_]_"O4:=@Mi:IQ%VAP@N:'(RRa@^MZS"UDpnO[tK5SiCj<,rMTQS?W&?T<Fl.,"Wr0#U#W`7!;4T
+%F.P=R<(u.4a-kH:.=6BTs5(g7/C1>8NI4kF$7^ujoc'o;@<T"t`N=k8A=%_Yrm7bTIoM1'<#a,,H\E]WSV,hV8'bh!l*hmQq]%u-
+%Csi^D;8SY.Dne6p=5)bn.P:Sj[;rEj2E1&EFt-nAhZ"'+N9@\GW"lG6+6o$7qPK>`';&PL0;dUn,Q*juT<BZWLSD>kWgDX!(eh<K
+%YL")O;m57pilCpP7#kmT[Wrn>BWfh&8C1@raA>[nY305++@-^SJYgeD`.jS`3OiU[oC7KPVOPNq3F1-uokmX>ONTf^'TiYkVhuS5
+%O*H/2(`"*UW!@LNNu!M.RkRsJ7':)brAfJh9G)Mn.$F0)9S9_.EPpNC32tP\E%k8oM9%Z0W1G*sS/=C<G<S!HC:XnJ,)^0N2^\t,
+%pJ<$hm3L$:L1=lLY4I6hMjpjiG>LhZ*K(G-g/>IKFjZ-]p7Xj_Y%!2`=^.V*NA#+a%pn*:?LG")T0N@p?iKuTs+-gAePH5$^\j_i
+%s8K5$r]g?7J,I?:r0r32H[Yl8s5s@ZgV7sUs7#Ver7aI8h;A4n:\rCIktc\c6/Hs)MiTsuPP.TI1&_%%rsq?nlc26iY=IW&rOMn)
+%Dh%cDraYg#5I(0js#pCGfXE<t_DV,a`qQ@+,aeW/p\ad#EsmHm:]J]6N(Q8Z5_)fXUPgN1dKgas67lTJq'7`Vo`<cAO@,1)!Nqje
+%9XGblJ-2;N8Gs*f2As=ZLc'n\M0a)ZF3h04$5Q,<*5Yu\j%Xfn.>AJnHn\-83pZlF#ng:6Lj+ai"bcVc2(8`$fl(@M*EAD.jFn$?
+%iR'G;i6STVAkZ(d#&4eR5#EQ:3>L*Mq6@,3kR-DP<'H`e3B>8_Ml&CO)@45m`CPfs_)rqrHg9u]d?k3U8Jij=<d5DR`8hr7q_Kl&
+%&gU'%G?sm[2'$6G#m"SQ:Jh'f6GT6r?c*FmWXQJR=ag4r")$^G8kC.E\4m#:J.5m!E82igGloGpFdMSBH*0K@[N)h+PmC/c-mM.$
+%nkoE.S6nUI*qor;6\I3tWFBkACcc,eo4")Lj_[E)(s9mFLe;amAXMsKA8hrCKre0k"JQ"(81?'6>cPRf%KNg*-h@cFe-45W^sp6+
+%jSlRJOT98Q<,='6NlU11IY4i7Z5.Z3/e]Gl5T2N<E?[^F$27i\G8IkO2@/I*qc+Ve^`j/HVJ,f4dmq/Lhub,^Od$hh'r9NL(lJ[(
+%W)>1mVP3#,7:ahun[OuYH`<o6bf#Q1Ktb;"$,X*F@74+RDe]ru_"C6[[d9H[b">X8/6'jG-euZ3g!S$,U`hH$Kri_&K,@Zh[Y#<g
+%g$T)4</c!P?DJ3r:Vhc)1Bh?d<O5&LiMJA5QR3qpQB_k?=oqYgQED7GHJR?U&FTAemEa2%QfCJpksm@kV@#uK!h%:U.[s#/75>E0
+%'Q2VFV%%ZMXG5ST:#BAu/Z&MW^*!GL`^MjO3:p+!D[c1VWpH^Q]s*uqacs$TTFoA%3Ptn"%ftf,p?pmbNX:mFq2T,F#GE5)gCA3T
+%0MM'6rm<AIhSCeJW$@j+YAoYG]=:s_qE,_ulIi#]bIX\B)@7hQ=XO[?nuDmo!2Z5MRuj5B?"L31hGZhBOee5hGpGS9.#+dZ8P%>"
+%5Ybt'@35JDK)'YLkT^Jj5d1g[5M][LjuqoXlj!O-1P$+efCt>Tnb/!b#+Xg7\c)ru/Bn/[.llp^9'q`c-H4<B=H3B5=B^/U&-Qq'
+%>QCi1_V^XL#m/ReWdjTN%JoqBNktut;&mp47E"`\m@t^ejBP*&7P';IRbl`&QYu_o`+NaF!F]Hhik_j7AXC=ee*6j0ZDtq014VBQ
+%R`dledQX27n#,c%T:R+kEgeJND=ElMqSuPPJ't!r<6ZJi%<RddL%H]7a@<FG&km(Q<Bd4:"_h/e4fM<j(ka'\^qDUndeVq,=tHPr
+%ID!PgEg1iS(oA6r>/:MMnTr8.kRRK&EH>NA,2FJnmT2!\S0(<[`^je4UojJB?la@_bk'?*iKk/M*Q!(Yj!ns-6]b4Ieh@EN6Q%q4
+%k[ZXDeJH!F#YNS6UlfCOV;R*h'16.D4XcRSfYfQ[Ea3.JO`+>u/%GD',]>lgX^W!bd+Qame7r7]=U2REpdKq^k]<$<1K\)tCJ"s0
+%cr]EtXZF0o/0pk[4m4H[Ae#h!>OboFd<C"fDE:JDf^hPI6ruIli03ZFKcENi@<RX1RV3mq,3_Bbp4^#ck/m:MU>kRE6,g-W4m\0(
+%+/-_+BTg-ee:[b4CBXT1G)8OR!<Njl_OhHt1jXfue(_3%I*cGs[00>[,8o`#j`^G9?fpA`3-d^]'`NH4C-:g4LD&838@&$Agk7@n
+%+]TWq,@FS`E6h=.4^6@^]uk[XQ[S&oo'*7M5fmC#J=J5=+OTIC0m_Cr@HB0gNV%]lS760"=ssdW'D@<8oc=dR(nbN=9VF.leT2`p
+%,WL[#jK_X?7HH#.B43Vc^P/MJ9lM=R(j*A^`"^f*_+gVII_03\Vs/MMYcK6<I9j6$s0s-Jr>BTnHC7oCjL177\#:43?fHu$pF63H
+%K/?sj2V=LeqpER'-=[d].q6sA(&e(\b7dmH%DK<Ag_QHC[4KScO3aj@,!;9ZE1,&DiqHT22fPKlD0p)ukD.>O&'ore]>UMOV$D@u
+%Fch=F\(AF4c(OEGd?\7`m@ne?r+7duRmOp\rpaP=.4gRa(NhNtm*DjR0oi8I24Jon/D!nk%HkIO6gF0([##0\8I_W%EV0TF05\^8
+%pt99ai3]!OYg5KIOSM1h_In/m'[d]S"C#+cQ\>QTdh6Ps?-<DnbE9pYcSDDE(-qilK)c3dhWLqP;"KIKgW_-LI/(%!cYSur<G/a'
+%RYWo5/L4i,X)>6_7)k4>?UpjqeW:nCZuRRaWkAA4Y<Yj7j4-#*O!f&+(]d`$eEnG._K>e4[DZi\$EX0*Z+p*UA)N+t)uT%3l<HQu
+%*MoOoGIA*kGU<*$3MKe]fTh[-o#KYKm(j9V$]qKds48UfZAfi*]aG5%XRGaT^Vk_BJ62ZiH<ZoOj!BLu)=_op'(41"TG2fG$*tHN
+%p%[!I)O@;%4Ed*"h)66?b_j@:A-f\]Ke_:fnE@!=-aVh"p9XFCU"M.l=_K<%'3U\W65n%u(Y7G*o:@9t;E3Z"GApi'cVk5QnTb#"
+%M9W<?gO-udDD06hX'6<hi+_c>J(@92^$B,N6)5j#I^.`dZi&^I,s\5Eb.XubGeEH.N^YQW,O]F,drehK0k/O/Z*(s*@c<0?2qh_P
+%^43"([6K/PXmq)2H%'uc\3E:G(JgBC>C!g*S'Sd'@ZPiH:-0=M'<A5^p:I6G&gt[VICOFb,*(Ys)cp6[^/(A*e`Wqq.(8[Cqo!B%
+%It2JFmY2[p_p`aO0b>>Jo/ImI19\IOV-pH9RNC?U<R&aHhYj!YHi<m8juM7qH8o%%adet$YhRqADscep*YO`3[+l\:Vp"@fVEQLs
+%\<0S=@8SE30pigFNadmaajElLr=/,HEbVmLg\\ZKR9enN'#\(LR9Gsk6%8P+U$R`qHD7!GkVH]AlL31[4Y<oa?RO<Qhi"B9TG7Kt
+%Lr0?tX"dskUPR5#ol2XA2X`KPZu59t7Ig3*gNI_Bd=rE4o(C_smZ/95,Pl:;`::E-IK&IbJ;a3/MsbVDpp3@@.b:S;D`Yh74ETR0
+%=$;Upn^2!fk[GP]H&.D,n-Lnj>U/LJ#nt5JC"sk,YHca"!B7amX%\jmi:@s2Oi.$CLq\?bNnKq4_Cb?ncHkP<*5%p,fs^&;kHcB8
+%BS1:mhuJfo,V*7"\AYX46d.4cN83>q7OMZkH?VfiYBi+RpJsq]K""dk.<[3G<19Z)?C,(JN<EB:.`.7F%D$diE?,Hm`((O9Br6fF
+%TFfQ]V7sPT3P*^X,ei_bEf*bg]+=t'(fk`Y7(Hd]2?HnJasoQSLm-e?&/C.#)EpZ#-\?4!EhG?8()L!ciOZ6]6VA<DMr0P>?X+6f
+%_77Oho#;M(%!0)Z3p@qrK!$>U5o^+9qi3?:BcZ?^02',514)e95Ne<:#5eiS^@T\Ndn`2eK#ZM#L^X-(CU'\/I9>WY!DDM]f25;+
+%c2!&<q_UST;JH4/a^_,/XgLu[q<"'r@<t?n^/O8lk&?QBX"Nh8,^Ws3O-:@;>,SDWGVRU`a<"@u0n,:`1Q%C@]*XZR#!m7r-\[>,
+%$OtK,A9`ou8+![@UJ[(Hg"aV-IaqKCZ?kRTOsJ"GRm(BU>d9hdnAD-PJR>h0W.R<MZfc>=X-*s[IA6T:q)<RT/>\=a^s@:`$`pmb
+%.mEq^&"5N-BERQ3MS5dZ!TZt7BT5C$O(+TlimF>L+c*E:%4J8h+3P0engq]">S8gLM'QR9EPc,VG(P)LJh#OsR3.Qd7g?gqK42]U
+%R&obU*8kF+-pi(ZQL4W[&q3^h_c;8JA<b[El3FH6Qn+A;h,gW:,"p`_.REq;.>&s0%(o"FR'VC!Uu'"VV!HhIW(t.]C.tCFM]%Ob
+%FnQqZ3HpHt^3"?(fFjYZ.(W@YX!+-9SHm*XFCAmi<(7T)"*P0maX`?a>BE-s8]FdZGYehNXu]!;QQh>3*\:OjIL_2[bFd:GQC&;R
+%W$99-H..:t!V6esGB!gL$<T9!-Nu6pRk@4!LunebJKJIRMXd<(73F`j_I/]%&W7s:n@<=,%j0)TZ-k&s&`uH)kj/H-Lf)KqqEG'4
+%">OWQ8%"LHPI1DUc3jIr\RgDb\3Lcrk,Ph]@7_^lI<kc1GX*bN@dO&jEtq&D(fdXLp_.*@Uml<068^>HC]uFlOdm7=J[g0&Lm^+5
+%;sFA,Fr0g+ef`0dXA+rD:0d&i`<HcKn<h`W=t!dk0Zieo<V8dCC/b9In=@X?U%SW;@)RaF<JH(<P4hk"cFgo1=9l9JG4AC8e@_[N
+%?AdZq-s\7DnIUK&SI?do6pJX$&sER9TX)-<kC0KFi-FWkos@9Xp7MjHB?d@@-T$)LBLSaC3XY(?r#Em]9H_b(o:WD*,Wd)V4W%u`
+%9YA*aao35C9$s!!&CF$PJ?,(K]$ULW\QIq=MCH<$1f+fV;HQJ+Fk+EpVGO)==-WcmANMFE%\PQeo;,Whc!A0&7uSJ*?;2#il;Ck$
+%ne>*,EiX7W&:T[Ia]9r\Tf@aT<;61[`\H<UC#Q]Y:EgNf@D]@ZQijI0^EJ(]/TG.;-!rN,Ke_6CN'cGY8=6ZH;dZ@M/qYn4iArj<
+%'p,PnEKfDiN;\30\s?/JYADM>'8DK)MEroa4B7KKkn63SYYu>XW46`Afe#>.cuJc*q%Gj^e.+biG)EcGC8_AB60a7T6J81Z6ie`5
+%cu$>S/.ira(aSe^$TGkJk]kMdAC_&ZbknD^S4U*G3ksZ&OD<\uLjQp]5_]?AK;EpLl0Z"[Eki3pF[=Fs?^WBfVta@OiQ(9-L/%T(
+%^Nt#iIrm.L\3X&EmEHBj-5?-0="oAF_U(Ou-/il0j,KI"<SX9cJq/'Q9Gr$*ALTL0clT@rL@RH`FhFpk`0s!e]8H`-&.D_(n],RJ
+%F`(@S:-N$FPoB"6/MYIWW5CJs%%2h0[Pb42mJMegCcd,a$JuDBj_5h2d3!kO*)*ge5DT0`XkeMVkg'lObF3()LEbqNe^++:P&GB3
+%[Pfl+a_m@tR[+Q!?buuUep7s!<K^Z/b.F*jTG07ZA5l.C;OMQpW^".I;RG'r,*M4^;2C>g/-RC4S&Q8TksRAK+b\Cg8Icq,"6LB2
+%nkY&Q,jLE:q'.03Jse%VgJiT0eV]!W`=!d5Nu6Y3@aIPrW:!b'`aQ\@EJ6S!FWUcQrNm$:_6/H6('N')n%`+_e-(]SUf.Yj_T%>E
+%U)=n,ODRTX/QIB(3$#cVnq=!5o#bg<d>PK\'$:M*p'bb6U?2a_We`-U%uqhfKbT+1M"s5Hk?[&"&$]KDcI3G%7+e;sfV'f%ZLrZY
+%Q+0JUpiM'/cUMQMlWI]uLfMA@&:$I$AI5UgC0OU.JmLmO.CqD_#qtJNUbR^%cF6l":b^?FaD)@!(*>:.P87\l@iC;jQ"u#[/?1t9
+%jK,CM!;VbJ"hG$JAeE(Vi2TT]KfT:n."VEknl"XaZ'6meFafE@+lH8n1h8s>F?&UN=>HJWJ^@E.23*8Cg&eYkKJRVT,p]^^B\Pt.
+%38o*L/_JVf"lu)pU#W]7V)r5>2,:mbNYFgWp]Nj<<qXa[riP+62`LeVlSO^M@1B3;ATjX>;-nPkHKO;W$.0*WF1Ps,K3k9S1o\Xt
+%2g$/XHj[lg*n#YM^oe3O6q@C`^AX8@[pG@HMe@`W;@d7]5RD7"dFW<$82EXu"G%3:Uci=i":OFRm#0X&CD%hS>Br%><,V+RU-sK[
+%cZA/N,&%8VZFLGdD+1+*iiNe]Se`p9.;kX/ZH5.WeJUgF"h7H)Z$hMDQjjKNr@E'(b"iSP,0nYOf-V*2CtTI5D^3Fs'Y(2%6+>EV
+%r$9<L"D\;!\&C)S(l:6s'@"2@Y`:?49L:a2,0tu<l0ZA:5\E1rEL9T<"+c$KTYe]ZBYiO+%)HPA;7q`WTi%G'kl6=r5c7`A8ZF!G
+%V7s&6oFN'TqqO)8olUr0f\X`*E_r`6L0Qa`.d,7X[-fQ<#I^rc>6u5s0sYQkrf1Cu&::=>5S_81dDoM2;&Vlp`$lP&$`V4$]snCk
+%b-GGWJHaOGZ!.8M1Uj__`l$gKC1I.PY`'8Ao%>'p1PIWQRJ!YQa2A;`g>Q^Z2F@KoXcm6MPFBus0,*@RiG1F1Uf"L:0A(m?cnuB\
+%J^^+b8$83R:#2I:/?(]rK*JE$2Q$V7guRZMb>.'`".$$*JaY-Xpm.,'oJT9N/g[^KaGmMPo`BRd"<=jVj7.pfhJU<=N>F2=SV$a/
+%3&o7[f@PE@U-Dfkp$_nO5Q:&RJ,HpNs6tO<di\VKDuRperq*'V78cK($0F&?l+a>m.Thi"9&/n5eFq]ZWF*$ciadRh]G+'<o5655
+%iSWtR_0_B^0bL:6>*>NX%@5tn4$NA9TDtrs)C`*OiR#?qg*#Dh#rYK,^#!O^Dgm/uDJ8o#HlA4rA)i\6WueD6BqS$C3q!GqU*^q&
+%Hl$`8_MrrH/\_)WmG2Xj0_Ck$#g)'hll-HhVn00l6LW[2M)=Pc^af\)Gd#A!rVZA,f)m;@S]<^oL@*l3U/1POL_H=HZeMA'Q3Mnf
+%[k5>kq47E=*e8Qu8Ni^O8K%XQBD<BL0#G)%gJ$cn8DUT*HVO%TcgTZV4FuZ5IZ]3bM\9dFlqZ<F`fBPWokm^=%,pksnV^p-8MnIb
+%4g`VF=QF9XU_8m[1rVC<^N6lFoPBMWkL-KIh:bo@maG/Uo1i53oCG%fqd&5+rRrTnr2Qkh\=.9-BWHOua2!"\GFIN\TAR367j_<F
+%L,:E?9NW<P&9("+@2[s>Msl+DkC+LU@>`_Q4*dS8XG\tJo#856S;3gDn$L&X5JM9SlPY/Uk.:Hs*^c=SBcB"C9,cf6gWF(JYP3rf
+%-ou_.O8jC2KG[$X1?s#=C\'JL^U_rdHFiD`?+9cU[FB?T"BGs'`-ZA"HD'GJIDj^pK7G@9C&W$P$\B<7YV9O,DnXW^Dgm.VYMYma
+%e>4MDk[R_HLYH[IHT/A7k52j#q!R<hme;jOLAX*o=kYjh:lZJJ!qYNqpmnkgmcSf^pYIsVLf2?mGkKh)X^4@r/<'@A>Ip6XbPf^Y
+%hF+27ZMkV#1h,'cGc[8+5nr7H(4Y`CgH0hZA)V(Y0$(fkVqk24FV?_U$qn@af&M%Ime"+\"n*Z,`1?%VB+Re&^lEP"%cf%qC\(Ul
+%^V/Al-5?@cP.H;-1S&n/gAktn;;P0bh\P,Jr6G7)[%qNO$0bPZ/'r-E?LIs!"0_H*>C?2:488Wni_A:QbZNgY^M'AHj7,H,"obAF
+%^A%GoHc>H'oW[qBs89A+nAi:jS8nH;k!6sbd:Fu.fcAR05klQ'o+!gbGPu]#M]6GsGl>29f(f7-GOB_sLjZT+`MXk2B0ZF^T:"tk
+%m.V,8RDI-*\nIHur"dGQT\#U]_j3XEmSiCeg[Un#r'\3=9L<kd%_IKpnM*L<2&OQ1'&$@pBb$8+D[Fe?l!iOY]"jUH%ffPnlB5f7
+%!;_4;]b%mK\>SX,6!TpOR*m$g?Y4b&+a.FJGlceO8CJ(`eEA;CP]D[/&H3HmfsSK3PFeTr\XiBmK3"D&2JFL>[aY&^KM`3*P2spZ
+%EG`RR/gQ#E<\8/G5+O(q+UC[t_MlUYcK$_oM\Hk3%/$gb9\UZ%SJGehq*"S%KSAo%N"^irYU(JeU^fU_\<ek_:l^&=_R#E4ZgkdU
+%[pbG]!"P>NJeL6q2;AtrJ"mdr)g7\B5Upgt96*0h@17-fJM%!I60eGlC76l#%-U.sB(^tJ5o,qpN/2%/9F8>?KF8W*Jqs\/*_;`h
+%D]Y]7\3&aY9/ibXD^).\J?Q!f]UER"FCPp?*7^d,$,OSdK_n8gPhM,";LlJk0uH#A\If6]9ak1KFfm0\MKC_S'>^?=<ip,AXEG`f
+%*_dnTD`JE$o'f3gVISJ?K2lfD\!;RIf@jKdZH0=H[Q"Pc!n)f[)DdmqoDj^rBt1s?]USs)9CU0"1SbR7K\cJ9SNBE"E+A#s8l<FF
+%YB",W,2(l%0tjirI#.EuGLA8Q,6X+Tg-L4YlI%IDdfA_:YSK7GI#fo4PLRX;9Xp%p&_sR6-@!>E)5_Jnj(-G3/i"]"ZY6)0:dB4D
+%<!=rs/&GJ-X]p6"j[Im"F5%iOdBASV^p[]5iAcA7\sRF:VD"/qHn8r]Ad*%oddicP5Z87AFnURaA*tmF,AmYe41QmUc:j!"P*GI3
+%G-1/?o,u0bmA89%9aN96cQp,@_"oJ@:?Wkr3"[_bmES[!TqnFM/VM/A%[i0XTQq'SB].<4apE*)m&Mo=&)'@YQ/@CmEI]E\4=M'2
+%/PXbMWjK/i#ucudK_2\Z-?1E/a>`,46_JSAWiEQ3)PnB.oB`Gs$>ph[JRIA%"R#$R4#EjmU'lnMXGBngdZu'XJm/:45aL:0Q`\Q=
+%1@_]LH:ch%C>#a9?_3+8,bp*9r"A:<O%jXd*jGp[*Z*=I[U_I@5(mLBK5DPuYt5[^]f.[T,iG&caC-(q&N\;m&2$Y/M`<Y`O@.f-
+%,ul4+g#0[-+Z;^n#eKJT\9V:I)$(sPeru`U%53mlY(Us0q%%MT&5(pM"&WC%?m<$4n-c6/G)GJt*^iY!)sgZ=ORYahR4>#?4<$NI
+%>qGk-RF7\gXSZ*;$>*A@r#(jQ]^JLCgl<\(pN8T^]3=J_7o[=gD6Dr_hjD_?H1q/qV49$[><+mMjdF<L/5N<,+!N#!@@`0gmpR<K
+%Q)mh%eAJ,/(XRDcfJ<uZ?1;hJ?#TTfKCZ+?rS0],]-\TaoFR3*?u1fTU@\TZUt7d&]!rrDk]4EjIS_lmkC""8f)#'VR1r?\)TA,4
+%Z%Adg1e8)8#RHDVJ-JRMTT?meJufG^%\)aLO_6\5Hr]+68\SJAM$gu_&ui-(a"sS>UbbYs2]t;;r=):HoKAIZKq'WViX[9G/0FX<
+%Y!X>g"6-D]7Lq9b=`Q4T<(Y1qcKQjLd)QVTUs3+8RDQA5GHF,<rrWuX*o5]3P\q$6SS7:26V<;*p+a)BE?PSE1bsoM^e.=cirBl_
+%]r`Z]rrPtlFcV<S;<l#&#c+;:``e*sFc\1@ckK$V8f`[NWte.RAYkc^W6_5V8!dMTQu[-1pG%YaKGi)(W2eYr0Z=qbH#J"3^WLEU
+%9I&16MnTEgNRGXggi7H"Lk00h4#mSb.IoG1Dil.p(+fO(_!-H7*'gfkftiF=amS\HN!5;@d-)J]h-6WLc'.H#e"5Wm%(T`W3[Cuc
+%jFO$r+Og`q[+,WWR7f\dHDUtV"c)(l3=k3a:H)8!R=iXEIA^g?mR@XP@U(\AqQC&9eJDV;?KKn^VRJbQRC#Ocg,N?BmK=Xg)@I&F
+%2[9UIY>%]P%q!i-NO1Q=Yb#\mHUSi<E/gZA_Z1[IKs>R-Ld[@aOJHa@\qYPSd>VTf7Z(uBT[Sl%52njEIr0gV^D\e"k7^A'-A[Vr
+%%TURS,gK>N*)B9E!?trJC2t17-G6u[Cclq'kpe"FEAZ[7])7R^au.:s\)q-J/;?Q;!km@(*Y%Q!OdH.rVuTf!F?pHXfpDR;hH'cW
+%/V"M(.g`CEgBYT!/<rd,/UO7R,r8727[:]*UK(PM^nTg'C\MpF&UKqn2U_7-bP$MC[HAtQnU,Yi:_#)Yc.GshV%?fRa7\Sc&6TWU
+%2akKEASrYj"L1h(/-GO49Nmp.g]]#6]!4mr>pYo`%3AJI`ePW*SsnX]3Pu0BlL,G:Ap*.3fME45or02t3PGS@FgDD4!<uEDE<C>q
+%ZiubPCi(I<H8\-SPhRP!'Y5i7ADs$_H84R$^cj1.o$CubmK"E'p]q7jZq6o8aN+E;%:<aoeUS0%_(fn1c7CiW1o-U9eM%2*+d]Ot
+%m/RHG!*,kmb"R)4KPad@\sCKKeDoakU^ER##s:sJg1+o8(Ej^jAP.@p2J2W#CqH_Wq;+6qJb9MN1*3J]R7proG_!p41Vtbc-,hf3
+%b3-PpW*6j%cr.b51BlsQ\?i_E_g6YGRl+!9Pb9&"ese'8!2pX"XA-\:T@pO>R(-PQbK,i7rmeaf4gRfgMFf:9dX-%`.$NCV:K7b!
+%I2_tc'R$e'mS4NJa%@Y_883'bKu2?3eabPT7/r6Q;FPPZbhHX]JO'dMkYON>pO)?cI18pC$NCYQRM^t+npLP?-L_<)a^>3>[_.uL
+%Rr6Z[[IMJ")%W,+/m9r40RNnodj.r/F5lhkK,j4<MHd*i^ors^l3,bVGd;_=Dg0r%ggekgSJ#Dh[N$:ARVVl=E6q09#__"VBg_3m
+%ft_`I#-rp4o[j8_BSm)rO3Q&5hG5J^Nj2D2$p1\1V,gH;hb=8nf_mLrYS<>r'nJGX.$@fIS&o/YnEG]tK)/WO=(*=);L(#/BZ&mp
+%O+#BMhto0i-$IBXlfc3@LN+HSJl?13#-p@ooEi\ha!7BcPbqh_Qj$=*H/'/m=?BB6QpSL4=S'_5YT=>M)kPVq;oV@#1m+*AV!$PE
+%TeLWL?qm?a@Zg#A;FZW]TSeH9P[-<fc"[r@[;K-JRfrl&S"sg!GS.''e5;GTrc#Gn-7=]P.NGajl/@K&XC1Ye?B:YDDA('2IGXFK
+%`@RP<Tdrhp9TaDZg*FUm4'-O>Vm@6l5uoop6:88.-lrF2CTN8L+jlQF#'rp/Q@:3omQEniY6s(k.;Ko.EE2:lSu;A@E+:k\O8Y$%
+%+hu_W@mjdmJ<G,]7De,AYqFo%X[:8q'@ii`2/U:+ZmJ\q3AncB-pU+</qp`d\eqa?K2N#N/a67hQ4/'UQGB4US95-/#5G!O"!qd\
+%@4_OPUNDIu=,<#6TWs>s,O,a"+-'R@rXdc`q7EGSPGT,ujok]:<D"f=Ka3#iU@UXlm2l2J*J>s^#9J0$8P75E%$I:i^P1L@<$8;i
+%Ml[P-iYac\&+9V8!d=9X$O%Yn3NOTG)aIXJ=TrqdZ+fh[]?$-/p>!2QbOauQ+h0j\/N2@Pl;Q"1+H+<9oIR:Y,S!!YCM`-3^S\&%
+%;=Zp6l-QHZot<F+[Aruc9ghb.]dpp;17roVP72%pb[Q`7]Sg/YOsT=,f]omu"[=ZfK_pFi42Q3p0&]W7QK!=k7GB+4^KjP55h(rk
+%^KqZG$e='9*F*]R,F-Es$N9E?kA=^Q8Oc9!qp68gQD%At7:s]P/D*YT?dOQXXr]ijI)r[9]&Fu(J]t3o`ngo)hhq%Sg.nn\Fq6=b
+%J7pirNXKK3XW5M6&`n)VF%2#CHsJ7S+QPiGAh./9_(!r7p)[tA+N.+=/OGYuH#s^A#HLW1<5g96Q4`RA-3]P\R0:fHb>,[^d!LG#
+%c9nmN/;or3)(Qo&j]##S3]g%0nYClHSeG+D0:]T9FhF+V3b.Md00eK=/L!fYE86og+tX9;BcI[q6kjEROX$BpFjX'UjNOcM#1X7B
+%]7<.$dZ&"Gb+&[PnH"#*ZELdLYZ\%3;9[H+or[iU4K*ftf`B`1P2`d@ieUPtpbd%,`*neHgQOkrE,9YZ7Q(]E2qTtojDCoDlU@4(
+%(?@;Do:h8;U2ukqYo7bfKo-QY4KBu0:9=.\:&(l9FQsu_J6\[IP2RBF+snm=HC#oL1E6@Ep619iO(?d472ho[5o%A:GDZ=TU:`NY
+%#_Ien"mFZcOf3eCKu-"(L_e$9S=ea.+:Tcb@AYDKkhQ%rl%qqq^WB4r*DSkoSGFZga?,Ne=k06W3b\-mS)be!H>"'+ZTDrgiBtRm
+%d_t7_oO5VeAc@X:W<_B!KY6i^9JnklRb2#cBSqd7T,T.dm._R`.a;iRjec"98[Qe)5*=E,<b2j[.!'END=R2(7R(kc66IZOXH?o0
+%)?;I8\`Gn4[TN3n4*A-)X>nZ`4K9rNqPb-Y[E;DUIB82SHEA9V`:,$L&F,cBrKtS2=:oY-Qe)sFh+;Pu&t+`K-o;GP=<S$*`)i`R
+%&Ca(m))5F,5b&9g^8W>aQTTJl"Q.fR.QSA<Xc/'h_0oeT'uJY)8U-[E#$&>\IhYh)UoVF5GH::0E.U-ErbO1C$/&'+@ndBEK,d(G
+%rYs18*R&X"LBAiJVTpcIf>"kY'nMa.d[FPi(<[6R?=%j]!\-VuMsGh:I$Mc:N7ef"2!*YXmfWZ\+ikPfB@s?uesrVA^G^bHiF?G5
+%%0\>]`YL'c-&]^KmBWf@e#lZfE?F#&>6/4V^6J#qK4LiN-VG=5_\_NFJL>7^86<f07Wsfkird2"?FW"X\W'>FqTI%P8$IZ0Ll1If
+%r@6*$_K&S4Nne):g"_RP"MANKKdqrnZKoEaa#XRfVnh3M=gb-2C2h9V7CF((4M%gk>;9c?d`Ic'UpgDZVNA6P$ilX_o,4L1/h`!e
+%<O_2<@qX;o3B_Xjba]Be@9=*(:?5nmU[T:T0:7';dFU7&lZIU6*qmkE*Cu-To;Y'NN2/.S'qf-r"A9+1k,^eg&_`E,lIqDq\>B#J
+%a7MR7!U.3J!HE'C"LXZ=>HQ`M7iX.gO5Y!RG3"pD47\ab(8S-k6';k<!!>2Io+G?sp1FuCVe1OiE@r1t6Gr<:*j<dE_#4S^ODd$/
+%kCl@2fJj_,8(=e3<12]E?jl2'ZJ>C6i$ih2Ge#611Q$bd#.Z6LJ8bsPIqRr%&QHkN_Je&%6?&bX$-SNki7h1?j:.WG@8+7H>@ftM
+%8N3/2:\K`m2A^XT?$X$6?8CjEE]O")%Zq1K^2>Ve:(g`Pm0Z`)*+r>\3$$1OC^Yc$'Ll>7p'$0mL-3`;f/QPrR1:j>/3mcC_QgJq
+%KNo/u%VB1bD-Ag?UOKeL`3JlU6U6]OX?/A:?:J(9n&LepC/X^e('!jpI97[&K+odeOi\3/O$&U-Iainqkl>;B<R;,-&9**A7=(V@
+%qCn?ae&]ZdQYn.g^kYYsV!-b,TcpI1m^];]9ncmEiAoliaE/U-7"68/@u5u8iY8`<HCG157(eB(jee<>PqIbf3f\Hk<LBO!+[.q>
+%QB42$%!G#i_&ZC-i%hVL!@]6]B.1#:&Qp/D9pQKd1>69(^I21,L0ogg\8c(6FbZ%G5S7:V+/@n@^rmQc9bL:*Th%_Tq"3#=0Ok*1
+%9D_D<,C&k&.b?XmSm4=+bnr75dd&q:1FCOO4XdY74F5r0(g8@T,8+\0?cV+hOCl!UH/D@%)et+LH>Wc:1Y+*u6`oICc*Aa#gOYh_
+%em;2g$Sk3"rnu%gZS+<=B29EB5b-4O<^2BroHlj0!BJV2hRrS=V,S,aSnA`K8jF&\#mEt6J&cqghFZG_Gree+C\DO%!Rid6AHehJ
+%2UIeYeB]7O*_i1Uc8<C6'sj9tBuC0tT1SYlBfrl&&?<mB*J'SD-_qLK#;rGb]KLZS871]Fp-m1@U$Ot7,.;#i6Cc!q>:sKf7(d[n
+%8,,ih('4Y@8dj$MP%2^?X;1hjd]ZJ!i#qi-F9hNKoj=K;M>@<!"D2J#rZHb]7UBU(8:MCS+bon<'8$#)62VHD:(Q9$kktJFV[N"7
+%BBofjLMSEbb^oI<>M82/CWZ2u9&4R<+U$B"Bg;dc2mdiPTO60b_)$2kr%Or+_<<*3=sQ`rb`@ucj!fASl#r,S+R;]5S-YGq=!aDN
+%$"aT/T@[Jm7j7'qlTb?c5Q9Krr8g`E&$Sf&iT"qO`PDOZ.A5biFoV*[WiLQZUMD!SNcW:S?[g(4(B!/R9t)e4X);'J5tqfek5OWF
+%oABO3U-IT6JYAi2rdtenjDuD%rKAdqqZsUSqdJ"npU6(k2E+&u*^>8YI:<pPgR(6GSOHdRi_m8)Fn8ki7.8RK]]V$^ndckpJ%j\8
+%Cg#*ClhDE9hsQie2YDH8j*-(KN9f1u&qN[Fd5LsZG.e+^oUou7mJ>XN?`f`%bI)-5G-1qsb\cN%5jQGep$:FKpN:p#*6S&h:&"[^
+%.3?fT4`<L@]:O6A\pA/HlLuE`Fe9*:ajoO&8'L)eEDo(&CNUS#NDI9:GFc!%I=gC/a6\c(M#6#_L;/)I+&HQfY3Tu;g!n*hpA&I@
+%^\r6WWMJ9O-B"t*1j*bfplcbA!]Jp(B9XYiH*lQ"a'6.pC&6kWq7LiG4OUg/YHGJH$]`JfqfF>;H3j/#j7_<oB=i:<:5Sn.qln##
+%Y1p2U^$(5Wjq-"8ge<4MjQ=_Z7iF$m?B=pUS*?tj>h9R3Upb;"rTsE`S*@ulGTDTMB>(139g>5Ege>JrR1@-deQ\N0/'n:R9V:?k
+%Iu``:Y^bG%5J*!FA,F7sq`HcU9q-RNXPQW89XESLHG;3+q<iD$eYYfb[a/"o^.eRIb<Do9.^;'g=@ZXNg&OGM0m#BC6^X1?/buu*
+%M5DME6CE%N&sM'DAVG+eD8UD`8_cd2D<:"CEKdl0qf+8WjS=24pptlhbC8TJ7#.BP:2;dE9KY)!&9eOSJ`\mq[pSO:gO<m9n(hO7
+%j"8:L=8grPDf6"hPY,c6FWGuQPIiqZD#AClSj,(]DXB:g$u#AsI=5a55QCALV=6TH&X(&o:i-]<:iY*)S&<dBI%A$!2]Hc>eMDTt
+%k&@_NRn/"nZu'loGAaiL>\uc6IlFptlgBCjr6487_V*7?DpKEl]5GsC:>>_1[LM6q*nB(qh9YOEm_A)V,(t(8NTFT]:HNTj5*%lf
+%G+P0a,^ZLUZcTlUFJl>2N9i9TRpIuQHO0WO$(26+Y@c8h`Y-dQXDZ]i6p3l-FqJ\4p3^nYqWr;NP`t\19L<`0$62AV5EToBKH<.]
+%_2&:UA`NBc>5B`dn=gAgL7l7qk)fPA/X$l=^$5pA]0dM<VU<tsVOAeXLi$o0j'G.^p=^J#Sgi/mKa0h!KfTjN8Kh^?,*gpOF!q[$
+%BLCD]EGl!BK'oR^Wu>$7qkX55`c'EXD!aVs&ZuF8>[P-+;N9:]@ou"32@Djp[Wmh/b[`XMg*\O/LaBoT6'r+d"[Mpg?1TjKlV#tp
+%We^D@a&\9WF.)A>`4AbSbM;6Q1r3G>eFGE9W[LF[D/G*qZ<;Po@tK&9*+7-cZt7kGGV-JjH;P[a]R:R9=q7NiVZ2j(Dhe:mW]f)L
+%7i2^h]BNtr6iSTiIV@r-'LZgW8k8pkPN2UQ#d9qO=>]`t@7ARD['u&OJ_6f<9Q*:*Mq^d%SlMYHk5ed'cHBTTA(nF^Dj,F)9almf
+%YQLgdJu%YA9Hdt%:nM8(A68*oE!?prf8XhK>sfa62FUG&:;Z4Vr#F`3FI4VG9hat&YT$[(#Z2E3A-`*M4)"UgZQ8PJMVeH%'0lT1
+%WO8iQ6QhYa+o"5rG'putAVM=[[H*?p:iQpgBda4X3WpXHKh`W))0;boW(E@,li<_[3)d%H6q8DG"1*NP_<Z&HB(5L.O))RJ*%QLI
+%4^sOe.oHZsM;CddPpfl"F:;^NS"jhH=$\D<`U,/l==-tOC8)]"`QuOaA&];7B6",Je!a!7>;9P?+4ADmq+82Xi7:>t*uR%a<FU_\
+%;nc!_9FbD1'G$.@kXk&o+g[kEl/(%=l_?tAdVj$?U.sGVlQp&YDN0BiTVND^5c'qnUE"N21mYp2mg_ISPnZQ//dg,G,_t(\aFVUM
+%Rkp)>dq!i.>[;[3^ap!pkgF*g)U<-^],^(L-r`:@'m))/9C`q;dN$QEP0rs:pAj^`-;ca_PB"@fOs4hC7d"eR3L`TqH^<T0[B[:p
+%nZB=^QREk\@L9JO0Lj77lR!?2,NpfiABANgS#\qkLZ2XP-g7U2%ne6MH>q[i"0--KosbIKUhAIJnA:+:C<d_7#(@g]gG0&TN&F-L
+%1fR@M`nap=])4'446l</&c^k3gI6S2KbS-<htLt+9NH:gOG(Rrp.6GaX></EDiQ-;M<Hl6>JsjT;%khY3l%@O\hd%)%SZi7__1"A
+%,t[]Ver##.">isu!UmiN>uUtAh1cGDk?3kfT#`h.WQk0pK?I_U,bsG%>Mm7TYlR(8ZuMc_l:$gE66(o+kdq!r5M:<M5otYHRj9AO
+%Z'=WK%.Os6ce7WI!C/Js5RS!"!LNsqI%J^QB!JNWeu\BSD/f)$b6\;D9;-K3%6$4M"nO+#>D\N8#=)=u@AK(u;iJR(]hW5>M!G5o
+%,nN-<b,mc&fuss.5X@A>Xbe0iK/&4='.6goDEj3N0oK]5H9i(:n#%1XS-s!\Mt@h>g6Xd[TW<Xsf;BJ&4luj2a_2VkG1_Q@!V6Vr
+%0iE$#r9r"s,O,Q42,Fc*5Fdt+TH4I%JMn<@/h(rl)Y+);#F#XIAN"%Z=];'#bQPu<,9GBM'QIPn;a^%2ipk\Hc>pL0"6D+g^:"&$
+%-@pb;@/"hFP=Q^YK]9Kd(^qLYE;HN!lRi;$GK^DQGT'#\L)@nW,q'JdJH?TNV$Z`bLCHlL_CcBN!(<^k%TRa9GT+kgmLV`=f%6+D
+%8D86o_:&IT!hakq*\pW]aR(2HEXl5cb?#WIlT>%B<S,I.T<;UfIQ+)Sr(Q:0kV(Rh<!bTrEQgO_A[0<`1:5KV<j!_p9mQ!a:&mT]
+%Os]"lYIGtN[7%!_AY*XMfWGkc%A8CpD]:@<Ebu^g#k-5snU^NKDLiE8307)k_\(FE:=p()R$WLR1[ZE^,$?2(bd=SYFtmHEWgpJ/
+%c*BOp3A^MgeRFDhfTlSP1oB2sTb'\M"f0P4GT-,p\rlU.hTJ$o;*<QE0JS/$4n54ja?]lu>.`6r\EuG"LaE"$qsL7;*ic#J3k^[W
+%JMeLf]ZC"eQg\&#0GiX=aB#RMdi5,Fc:S9["(s<JDGr<;'KtP+Fg5N):Y^&?C^Zco&>$_]j+XaL!:E8=n.Ni]I'tc6,!"@*MUuQ<
+%$3Ukk(e!f;@gibcF&101OC_t98FD;nB2s<!jc;0@hT_gTd0Hf^)-cCoU7e27K0)4P.=bL1g<prk.o86NKBtm""8lR4@OU7+A/NRh
+%@2BC&_W)&,6a1G?^UcFu@0:2C)GepA@"glBU&421cX!_UUPc@%eopqqF?HU6%,hfpF9/n,<tV8fMQ2]q]E3GrBrGK&ecXoQ3CY\O
+%h32pt_@+7fH@B!/o$`I]]PFlO'<hj(5%FeDjF6L=3.8ZKa3SjQS>;q#PPXda5-2X!gBM]I.M6ANC>iT!+<].%./kr@]"K0g5B%=S
+%W^5mSV4o?+5p`AYdr=/eNuuC-YuRG5&GX(fAlL&gMp_6$Ha/5(DJ]MAke!s'0mB'2,1Q93%ZdGMQRf;^hlmT("@]ErQpQ';E<aV9
+%>QIY+M^buD7i19YDEC-Fcn>iVpDfDoh%d4Si?Ue*PflJ*?'iiZkBDb0e90A]pr)dRk!"%dNHO+<*q\%\f'>JVq]7,pdoP;N<YKL\
+%C##$"ZVQ!1DLL5e?+GraQOK17?=TrhlIU5q5&FrfC-Q3WnfjT,qVC`oeQsI.Zc]gRcSmN3GdY9sjqZ1nS?dDqgKPTZR-d&EF.)EE
+%a)(JhZ^jnJ).pM;1#)\fftPRJ@$Q/\D"emT]pnS([f)3=hVusBZQ8M%m=*)lpH*!AhjA8-RXS\Rl]'S`Rjm*.T;H[ggV,6MQeAN#
+%Am9362U<6%GKb6D1#(G>\=)`/A%$T&]Zdh!A%)8og"u)\,KoIr]iDaklbM6hBb-gj"!,]g%/ofG=CCW(Z6RA3l!/G?ASlPVAf#G-
+%_@:M"Ba5!fL2e5%,[/,pj*.E\"j!U3[c[&8C_XDb?[(k2qjHp1m1JZt/`.QrQ8DT.i;<34B:d^1MB!1WGMfQES>PE&FkM1h>F)ON
+%Z`hg-cf]cKG+J4f3,[U,i]U%D+alT(oCgW"ADH>P!c#>3ccP-#HKr9/e(ai@37j^FA'O:3T)tGKrk!!Fa<Q97emfU4+9Hk`?)I.&
+%Ormq[BCt?5;gd&X.Fsigd/gdAYFE#0X>bR5G[H4DG^Cs_<XojfqsDoYj16=)'5Y(Sf,m/b?`e=te!nr[`9[/ep$?lRH.X&(QJ=S8
+%rQ.s#XnK'g)"%94NQkLN?0>(<ZZdrWB)!t3HgWhb/:#uba*P/SqlFP1?`phWB(OOXbO9ee`dFr$qX<^uCHScs?)uS_L#2Y?J-5Q'
+%IJ%'W2`P8D)&[U*'>7a3]kZEYSo!tbni^_GN<8VD+t$+*)p4^<92?:'1*V?>*_B3K`+C8KX!6hf9f#/>O-kEXo>kkE9=gLCi\o$<
+%NtYB!2,pdb@,5,M"N;fo[g3d^3nL(nQ*_PD-IBEDJjU2UQ;c?KX,G"a8%])^""J)C&.qT)86[8d$*9f]OR?EIiIpk<)-A](c8TUU
+%Hm4Hff2M.\@h$Qk6t6DFWZ4G0cnifgStr0\235ZuW0f;[)u*YX"<nM#A\SfY!*DXsJM#t2W7m(7MpSpH'Wg-uZl%9OS^j0.JO336
+%isoJ8gF%!+'rIi^*_(A]WQq_*.2mD35&Qt-,Z?I0T5:ocpZ@f/j9S%]Ak=Rt#J_5V<a:R1`DV4`AJ-2ZjS9:Rbaq7HLd`CdJnXrq
+%K.[=e(ne`*A5uPiCIoDr7Of0c/W#sqb/:oOk(e$090-mV2)d$n9jdfr;9TR!?@s`g3D%>/QC)<(8;9.o<MDeLB.TNK]/"&.;HS>b
+%r6WuJ9U'Cn59h(:Y%Z",igM;F"_IgT(r2Y#&HmE-W94]'Eckmu!@V&49tDb8JYRX8']SAd;5a+.Ks?mNV`nt&O;76k#]5bho*fqh
+%gjL?0aFI5qb)RtB\AN*'C`WD-`k5DRR-@uopZo.>MHIUA8P;pi$7XLK8n\Fp(i8IMZac(Q%qCPkML9NSDBhk.\tV#Q*":1;;mjuL
+%"(b`XrQE&r[O#Bb(eqnL`mQ,Gr!MJ7JPomH3T`ELUd/ZkeZE#.3,s8-CX:nZ9m"umV/D7Ke8(0iR"D.A/q@LF7D=f>=JNDoAVG5&
+%>7YOPbti$ZWAJ8HF.2Fk1&Ld,;]NMra%2(b"\2JE%B>#9-t2Z/T((Qek?^tZ70T&G'#+JUU@C&'+':ji)D4Zh@6n(;8h,'$0R?s0
+%k\2k<RYTN#Ce4bu=U.KX:@@%_:1C:e`6VLrW0D3fmpu\@/!FX<nP*5BR)@b"S3j4O:=6"k6D-?<lEE#-74>:*R$3t6-BiM[N'e^p
+%,K5HeJ7l;gi(H\.YqQbieN?1=3%,:VQW2Fqco=G#n=FVj>WafE#q.PfSumt\H"eU#pAsbO!<T]$U_tR<5%rX*3=k1gYXES+:#_<_
+%e6+[X#4"+62]=njhebQO7S7]'J:p67knc/N-@f3)#Pc2fk,"j_DHk^q*OHeud:'fr[T4s%WDmiS9^0uLdrh@D=h5lg&#W<l;4pN"
+%K6%U>%YS><&L*MnR\6dj<8slZ5LS+\hG3JF>I\T"D&_V,\@]Y(8.t1Zn.Q"+9jU)?9BunX+k<hEHqs>C5I#+e8F'LV>DjiHi`ok+
+%9P&rq`8fa[6fSfr)7IU6Wp?+IL/:=LcfD)^PbQOmH:LkMX(7ET86!c?hpC#HGG9g;%i^?"D^G+eqeE*W)U#HFg`>`mA:@Es`8f*O
+%p_G$.U6K`,e1/$?&TNsNU]U[li*3Qsa.UYl<qe?I7,$)E"+[h6r2Z-i`3-\!.V<:$ajIqDa%"-c1>T^Y11qa<-np5"`FPV+oMFdo
+%H.3K_)"7g"\F%B48_/2@Tu`,@)r*(Zr+O!K,2#L7,oaiXPkDg'T/<3d1AQ8gbBq\^dgSs8gcSJlZ%oQF+0Np$BItR7>_?JTKRF3#
+%GmI392[t+%24k7?:NbgKG^^XCPk@E@Ad->qD#&1ocp2dj&!o0$AhV$cQC.96gVe]GXEC4/<0loChB5"7l6b;BWeI'q2QQp]0.9>q
+%[p1R>r5I,Ecj)6+l45,XVJ9]NN"\X2g"tJ4T)%J!r&W":+#1G&eaer2Z:##05!i&g9'>[QnN^1mJs.'"fqr+*W;UOeDK=@W1-WA_
+%OK1;UM]k>O!fEK.8qIs=ShpXW0D&EAW<&'sY2@BP,N1b]6VOuQAMAVS)9eI`eMV>$n2u_KYom*mn8#rFO?8AhF&RFlX`Urc?8Gf[
+%FVJRDTQG<n0cB?n6Vh#VlM-YpfNZi&a(gPbUM?F^aZM?,A74\3"Ms@e20XlkL@;t9^MS<7F+=7hZSF?ZiPX/k4MlcH@jI*tp-cTg
+%XkDO!iqS#u#>G%.4%$]JR/^H'mC3A-TnFrlk6.o_,'*(f:O;N<oQ5nP#a`CScXj`$V'amS&S@PCF-3-3n@qO^#e\FJOT$+F5l!V0
+%(2<l<Hfe-Xmf^R:ckPR"d)BIe\fI:h$&9@YR"D27*q(L;J?p!(1tHmn/;sEc*bqoQ!"Zu]hYF7X[)6q(<*O1hQH)@9PmU[E")C*0
+%V_MaD(iAcM:hW6[K;rc*@nHoV.aK9XPR!p4e6T\6:)&Kd?NSQ0B:+&^JL_l!8:.!c'HX4m6dWL*jT?FJ_Qe4mVlj]a$J4("Z$?jf
+%p0(p@_)=&6^faA(KG5k50)2T%I4W==%\!tKIllPFknRqpD]s0fi/@sZETlNr45s@=+XlTtd5tGj>R27bYYS'jjb).;XZh]"$0"N'
+%"(N2b%b-$,&Bq5749N'ob&]<)[%E%f!;>J;.NY0J"ObeLWU.1**(To4<>fn*L57u8]$Sk3-;kYlD$`Rtmg<V'<HF9A3dQkW[%\iO
+%+]<ufJ8hkKJG`.T9*VrWa#)'p#o,@W9TVdQT;ub*k[YaeJbinq,`)f_HgEco]\NcG8g5,3+LuR8nf<K%66]C#8X"8SP%7QHY?lJ`
+%=W#QFO8\:#/s.Y_%G/RUCU1G%W>#pk/r""+^/km_3@f&VNi3Yl$uffPUrR,=7@-.6?Y+Nj#hb2nX:(a7<*_0Y#<G!!,B'I>L*<a.
+%L*gX]BqJcfVE4>La%&4"*hoNfgt[QAEE^"sjONEXoY+F"XC!UI&D`=X'qT+n5B[QZ/\"m;rBo+S"?uD:d)X2%\G)D)D(^u=Dppe?
+%MGg-IT52ui5h!WW#W#l;%N4l@;sZ*>^&R?-pPGsQ=Zt*3#l>&`."p7eG$h!8F]Ra]a%s\"@;_HWhs#ObOm%0(b+KL`.qtd4!246'
+%DL?YjS79A]88t0'-KQU?VPppJ*G&e`diY:AS0G%]fr)VC/7PQ0ep#=,e9*suB%IdXTO&?,72::]pTsSt:2iY>X4N"ZmJJSjN/+kC
+%oIF%rOT,Ig(h_8FlbRW&H+L8Mib&6O@d3Vs%#.?A@9D363KS?o"BrGc3113o+7$1<HgQS]aY\s&$S_D$^$ZL6c8`W$Ge^3X_H6CY
+%nVQIPQn3:%W5:j(A,$#_CD_JGSAp@E*@c!E+UGg$aldsaU=Z_6;kdQsj.KpWVr8*4nIfEs.\&5A0#K0E8bap1^SriF)9f`-$h+pl
+%CU+*18G`P7QE$<,H&%JmU[#,-Wh\I\`eL`dLcmA?AW)Z?hNctQkiF"X@C!=*%iKo=.#i4^XrTR:mE/!'HGA(d0M%'h<Eas`VREK\
+%#`7qh7$e]OEQN<:XYk.2Bt7TnZ(P0GFNHVAoan,;iJ"B+IBp$u-GkIfE,m5;Aj,Ghm7%FpRsiK.,"&cY3;(&L'S'BA-6$KGAN71c
+%<^gG0miD5OGZhLYnZZr8)8L+0E+jP7OK?SP''GWF+uT0GK^<l,qO)UJnm?k92+`X"DM5eF@puFTc?:"#i>=Q:Z$%blk[3]#n.Dt3
+%6mO?(`l0^-E4WeT)+WSOhDnk12QYAdrm0uUO,VK*HB+p6,cmI"rjY4'eB(2hrpY<d(p6`;qdeq)o-TEA(PAW(rV3Ot2oh5QZ=;eO
+%@`\$-0_fnRpj*A9<2E+TB.bdNBkNB?(o.1;(GT,JZ6K9u!^(pTXimp5h!-fGW!tOHJn,l#j]=MY,s=V^:md4K82AG`,l&i9!&8B5
+%rhoMfr';:?]ssjQ"ij;JV0c2Go>Bm4W\*oAY%dKt`RoMrCN;.CPn7i\_UBbpfq!cm?;+o1U(!XDPHmIK)%q.QFa0UJ"@*n-BL/VV
+%ccA@qa#ifORBd`m,K)A<[mM$,GFF<V4&'#On7A5P4>n)F10CEXS3K]/!Jc%?5#ZgTo;m*F0Rfh!7gs.[:!'fkQFM)]d%sFS$D3"Y
+%@b=j30<n,qTt)j*gd[#mS5Z1@P?rWHaIN**Y=&!U#<OBXO-Se%lZ^!^j^O)E#N6(>@]R<U?SqDV!on4/]E/!>&Il?DYtYNa;H%mH
+%kI)qaPfRa__3%uQ3!G[hJQ`SE`HI+#PpC@ZmS$\:jPKN*da6`H:gjgOU4qqN8Q$OH&Sl_=)$A!HD]AY&As#1+/(UYrgU8nK_Su!`
+%%LiYX,l("o'&ehFdMA/l%"esT8EmC\2+oM4;L;%K_0Tr['G!QUYDP=,Bn3A&r1UV"ST0X6&edIm9F/BgP1Xr:X7jZ:'-U1i=:%fE
+%JIlQ]8T8hrLLjE?>LN)`=M#(Igt,-]ek*WZ9!YNTA9Vi(SV_pj=EanJW!K,-1Aq?'`]ZH:=C$iK<%*74E=/=<e-K)GCA@EGW%,T9
+%/SIsC7@tBoCck2oL&_Xh0;0bM;9N.<i3;2cQa!1T[Kd_n&$/YIng@8G;@TcJ;jC8nrV*LOPG/>Dr;D3Gh1[j.06<X>+#[M==BrI8
+%!4Xm5o\'!)r](T-,i[6;Z\m!;gssuZrM']56NP'l5Socka!5lW+..%u5uS??npmB,_0H[r9p&a]k.,euVoD=2+d@SV7\n\C$n)=P
+%J=*-33U)nm.1WgVT1kV@8HY#;/!aU1aCrCU>?Z#cl@KOt:;@>435S?o5%(?]7jc7-MpE(/$^7jTp%U#S+>(ki9O\5A;)XAo>`c:J
+%/Ns"=_.U<@0>eX%5KkR:I)E0H4DX8g(fS&(X/=?8fNC>Jg3/Zn>Bm*o[`_[iUT8ftq)sZSF!3nngKk:F[S>*_/.Tb'(Y/H@L58"S
+%@GD,"7iOX%SVk`JN3Mf7cQoAhN6`P7Ana"rfH*NHMe@tC<NVb0Z6GsFJmnHb&\,[p'Z2nb+i_H@;.Yt8!/tA`fab?^OSj](cHFaK
+%Eor-+)j7X6rsB:$<@"';U\/sqD\3DVS*u]hp0J(qG9&OU!%0JB"3V$o4;:=GYR_]L"q1=n/JHGJi-C8*Q?8':>coa+f1=eJW&u(W
+%5?#O*!^#LZ@Z\/CDHYO%UVNF)6^G=.E!X-fAThSA..&=(AXnr5B:["%KO>0q=L^fH`aXLR1KfTm]5a9DZ;^%a%22L\.n;`Ba!,<m
+%i%^Tr8X=l9hL^tU9\Pafc/hJVFoO3:BB3r#KD.lpgDWP?ER6-I)5J5@U,7!/4ChMHFsE5R=?j@E/Nb'2Yc\g1DP^T[MIL>9^L7O*
+%!Bc*mSRDdSK0dDZe$PpY_T37%Am:0*e>?JMTt6L^`^chMEEkgYT\/pn!T`%CcS/&VJjD"m:d6^eaZ_m37lVT6T)l54`.f.;aqX90
+%'<<&'UGG*O'ug)"*^[jR9"<d9)8b:g5d`?u"a[oI`3#TM-jlK%C$Sun+^_kj=$[1\[D3dA%d&;(:Z*tR7&#>iG`eo%1SK)#A8-q$
+%oscAI\[<lj_F:GCO8G`.'ATETQNYr_\i<-HI#R+FYVLju@AF-YV&N55KM[ioHV?iU*>B:qGSg`m-r*9A`j!s=-q$),$@dtN4>tN[
+%ficS*Y75Y(90ZY`=Dg"pUNsa_@Np7AO8#M\*J`G:j:MEe_$CR8I3CG48;P<ca5KQi)8-WO+Yi^nna9,3?:%m"I\<a!.&F_k$+!Br
+%`fF\CEh8lcb(osK/m=D%IMMko]i:i]SP;k6]I`n.#IdF(W[*5ZOl-I`J<,<_kL03X8:`c8qOr.D5-tXMGCOJmOGDF?,,5d)\QQ/[
+%W@=qfH7Vgl;J6?f2#&=-IS/+lJJ[qSH63<JTJoYsc$b1q'h4KE;q@!SQ<k@k=O?N0Mc)\<.3@EHoUQ,1m?4<B0Jim)F2)fh.&#NZ
+%Kn]1*Y9[*l%iG35\TDSO*CblF2be47R)9WJdKg\%@<-:)pYj?,ADr8%lCd5c_9gOs-%TX("RR?Q@1RIrG+:OX@3D[$3%,sCW4Q/@
+%bMg<Wn!,M%g@G_]:kVgc<Q%-b)Khf+jtE2$2=b/-+G"+@Z]PZqRA+L7ch.-]5D54/q-7Fbk'kaYM70Q<8l<oBKd,n(*B5U6O[$<Y
+%#:%YqNr#`GF1qC_(C&?Jc^hiW'FLtN66A"rO+U)t$s[g:\Jqsu;lCC+Rh;=2QWO&?k0%P$+FZraAc.PH?&#oZ_MHf?fd?=:-!l^]
+%#5#.04uF?:B$rG1-A20K-Y:i[:1;O1;YO>@.an/%=8S>\j!?(j4GZSKN.r&VWWcs`^K5lNc[bP<iP_M'KtIq0;n3e3!,sta5c35Z
+%(ur&d$tVeG4<SR$9Q_[RF2<#R#G1gHE34K%3%d+qC-BX?04S/+?4sHCcG/=oai;<\dGW`iO=2%K@t&^:>IQk*'.;XgDOL?#+RpE,
+%i`#*t>"It62Pt:7gc-%#-(\Z=?qY`r@4S/M5q6G:Z&bRMRC3"p^5,b8]jiBP[-)mPE$eEA,rR2!aEXB7+s)Wj>8[Z\3LlfKdMW%u
+%GTCThYHR\qV5.5D']C!!``t;pnrVi.*\-9mOh"_=1$%/NFkr\#e'.#,=n#PRd3R_1XW0?[U%f^NI-eS/8:u[ZW^pM%=5HnF$6oma
+%9-a[=#dXgXR"ZkrE-VXFEE<S>hW7s7g:bh!8tT_#AhloVMMV9M/6N>7i,`F<Bs3ad*'=)VD38SFgp_b1+=)O!6+RM:&`*D])ai<s
+%%m_+1@P&uGm0jDukh\JEH\$IHPpSbi"Z#ck0Tc?N)dJ^h7O5<qm0tV+Lh<@PPC,!Gakf(a)P_?A8=pBh%m$)r9D2(V+`X=s*esIF
+%Oeg_uZ/Ur+%&D'SD,$&\;jY.`U2jfbSirFhC\5m!#D<P/Ac,AR>FLNe`jW(Y!dHe;"4>['nn4$f.1%Brom$iOk^F2J^g'rk[@eU=
+%?k0C@\7uQ^T&jSJ?%m^jV4o4W$X@(g;j2jA3VU85P.eI"2-q1\rTU=*6LT!ELoD/GS&@-PVer'Al7'/LJct7;c:-[NHTus9)dAl_
+%*JT7Qd0,OW5d^oIW>tmQD'Z`#TXXfe0q"*[$D^RdBZOc*co(DQ"4o<^<KFuV>>UYhh.#N)Y+G5Ll^fhAO9K/b.FH?!0fkJ"JKb8f
+%HhS>Q2"'1ljWDbl*GRq.$bMl>4"N0or0[V-pYuh#hH*[7S2S8aUp'alY,T0TL.(,'cdYnCVO16MWu5bLF?YV>,$KM%JfPl"fGf)=
+%eO?/kp#lo^B]f/X1.Rsd\r)+`mMpg+bu>B@Ye$'"WSVq/Q"T2MZG8B2CmetA?CBl?:(!5as/\(7!pm*r&Gm@<>9t_E0;_\Q`SQ"t
+%Ad(D#`(e(L%YI/m1JhA70JZeh$Qk!U<X?*5EAs(d/$Bmpj,gD*.BZqH?r/Q%aj-mIL7dcT$75ZVD2O=N6)d,eBp'YPqnbS6k--'s
+%MM]^OWI.WfeG$"uJl]Rm=Z9>F3N)bn>:(Pa>Le'cCG8mn(!lt2#1FQTSUl/I6p+Nk'VfIo3t2li":XT7Vs99s$`MgdPf#V[+=l]R
+%P@V\.?Kj(0[h4-5*Gq)p'mNK^oN\$.pVU>+EceuZQ!SK@i_aSIMT3r]j"QM]l4hkNEZ?f?.!T-A0O8*=fL<7N@&$`OFp][d)'PLn
+%Q,=;nNa,=?n2u60V>sG43BKD@kE["\JIn9i"L0.=1o]I^3<$OU!mS9FV,1>l2'?86%'inl-[DrKW<Ung)*#+)?uG,*1c&,U'lSkX
+%APahZ&q0YQktLWQgpHGMmtPP\bRN^G.Tf<iW?Mt]BKTffCVd7>_O%4X..mqQ1ad@+2oj-Y.M=#_^>ON;"9-3Eo5Z[m4Y7QZf6.bg
+%ZEt67Pj/m)""kJ:mAE!7"_gEY3Ng>I;na"\TtL`r1/I_BoFXfd_`I3S;rF*\o-!f]2h;LQo94eh_lkR_F&<YHdE,#s;sfl[AJhBd
+%.!mRMTkse2TnJ5((*+cDZ&l!A:7G\fJ/.4B'Lu)*(C&Y_!)!h,:L)I"dA;e.PB;2.hnT@+O<COd_q`TN.jk6r$ltlbRUbKBMeTK3
+%@fjk\_ZX'mS=F5*lC6CFrFk+s)3!!]CW/!LCHDh8c2Xe\qKL3#Tb%^A)+1Xs^n#'j>l+Q#-M'?Ie9!Bb3tYr=3Uo,(2T9a8WGe39
+%c4HpbU:n`>7Q+6J$Fm?iEto8K<CTiNlF0V%]p00OTCcL$SRafl2@B:0YeMq^l%ngj#d^PLpdgN<'6*:X!@2o`&.ZV[Mm++i/A/+N
+%mho*HAi7"C&^6X`)Mg@+EcQ\/iA4mXk&!1mE,FeiB46@/ZS0fj&T.^KkA2>%@+%j(a"V2D`Ci-\[AqZk7&j\6H<.'7N#/BA1:bSU
+%ikW!5Mlmjt&Rg)]EF)p3K]X\<hl!qd0>c%@T*'OH$mk$nb4@?pM]IG(>i2jtl9rBh7oM:'Xb/bH\hqQ0`#b(!$Z-o;4QdnV&ljgI
+%m$M5DWQZJ9@HS<+B=JO?U.%M@1?@\=[\X;I>IAV#kd(A)#ip$%Z\_+&>0fTA<.6^TX;"b8^s`E\!F-,p`p\P-N8rRl(Vaj515&C8
+%NN0r^C0Zl7*%H>K1`e''1!`]j;A;]F(I:7rLT.kJ)E%:DKg77,UR8<P]'bT0+/k8F)"gmu"(U37OUkV7e7%oSQ,-`+C_5I=]PiNF
+%j1J&+EXQM\UFS's]2FF/Ma$ir,,@D60=&]C^:8fH\BEjn%2%c5?s/CJ<7-IKmc?"]7(n/dNtM,cGRo19Z\>.-4Kf-<edSq.hLEU5
+%4P8W_ZRSYo!_.P'=m1SdH*s\@^*q,$3j'R^0N^hAb,poW6q(eD66RP)5lo@V/47MaYnb@\&3rV.$%>`kX;])4<GMuj-(^UW<PO;3
+%3aJf;7?in584uW)5I7+XPV-CqDn2<);#nb#[!QU$$uj>$T2A^>/5nib$u_%\'@`bg%B`hc%gRoi8f1%n@7_kL[93b?)S<CW.:ArS
+%N8rW'qR%?<N>C3lqE#s^P9"foJQ5BuI9=W217d&dYVj=Hfog`Z-qNs/[no"`?SOQ$_)6q,"A.d]S$NV!AUo9VRDb7+E`"_!H<eF0
+%bG]7u_XR((J>F-u"8L]dOs4/E8MVPnP?^Zk?7!E4Yjdo.`PskE(<@Yk:nlrTmO(2.b=#tIBf(3*FFNY\cn1.<@FH@H5Z%q9)mj4(
+%fTLl1+oG6h"9WjQLoU5$]ol+&3r*'+I.VHsRL\3NZ%_]\L4&M>F;hhTi:6D&4$-r,\I3)%E%n-EVd]'eAoX;FViF_,ernfKK:MFU
+%]k&sDVfb"ljG)>OTiB:C7?Yapmt(0(Fc?>?#GMS#Eud*7_kL9]2_(%+U@2%pRrrDao;4<Wndr8#FVoB$QRdbLKAJPI-0)3qD'[kV
+%=87ga6-JQHF\7'lp'!ibZ(ZV'bh8#a,dt'.jbE-,l@CpYE*F<OC`A?PpJ'-e<OH<jVdXj&L@hd!Q_fk0h6`m'?XTm<$f)u@J^73g
+%E3.^/1e/ZG:E>C>MCJKD[/:Y"C[;a8F#!HJ8OrNK.8uB'Ku7h/Qj5/iZ`EZ3')Ft`QId:/c[?)1_0k:+`bkuiDSc\ijX)0#9t=so
+%Br]0@B%KP#j9/n2`Jc,i[$/[Q0)#hM%K,u1]h3f?j.VNJV][eW`\=ffR-KbjMtt@qrVA,gXdic6#TSVnpsD%XMpp9+1jXZ_Y?-KN
+%b0W6T#J=u[4Y4.+<X@p;ORFZe1RaO)]Z&(rh>7RWBL<rWVT)unHfA/U*<66fh4Z,G[Si(hM%HNDZ8#p%L<"\ALqt.`'Ys4%qOW53
+%.EMN;Jq5-"pTRJS:=Vn/M3Y;B`"=jmi]YM_nMO4cG0cGD>1$Ni);TBn&?M,n;<iGlr2UP0SZ5#pWBBjD%."IiF,jm1s!((H'drdV
+%dlc;H:pQNlnd)Z`f[:>H.k*A5I^.V=,a;h,IUn06@]74HBo*rW)4O=lP=CQ_Ze(-'`,W+a_0/i.@qdVd[0H`I68@Q^Kt*n*RZU%Q
+%2,BA0E!Urm`"u6)(_:("/"N)^7n*agX!WK=P<KN$+94Whp9Sg<72]Q:4@]lF2&8O>Cu#Oodo"RW8PeS/)V;e'\B<M&X1;Rgi$_FY
+%>,Z`5m*<FcH!_U\\sG]*\HU[V$/EG>F6QYc%,@k-\fmSOi2Kk(.W%NqT1R.umd!_&G\utVo`S!qL<rdkm>!>BAMK%.4:K'%&&A"W
+%$G-.PkX/41;_VH+;a2=H.8T)gjPI3'l!dCsEQI^94cl&]#_*Ds;H7RuMZCiU)bBfnL'1m8H,-P6T"-B8jl,!I!hu#I3FhkiG=Udf
+%`d<;aTrD9.mPqJ6=bk&B]CL_tXIH;l5tO0Gd\]@]?[fRWFf5"4W58o>M=;N_VFoYIWSq9Y."s)L]:4DMhe(dX=cjTFTXOp*[[\oH
+%:EAF<,Lgk?C5#8TO7uaGXXE4XDnIDrPg$Y38J-nr%iCo&jT`%ICWMslP2nPjXJ98*Q%j%_!@pcb_#-bOYZN*0!t:\r_i8f-ZA.T/
+%@/OuolmJmS#P,ZM^i3>/WrP>$*2o/kL-0L;+1PEH=VEt&LA<$cJAI'k^D&OpaHFadUM\VtLF\H\NrjKoams?m#5\kE5%HgoE_m7g
+%RhZ[G,`/.J,=F5%6u[ks[3W[g+B\^M-lAqi8#,ndDSCNtbYJaKXDr'F>D"jpKit\YkW9RF%Qd!2pf"qu'o'ah(!2E]#L:mN%CeBM
+%A7-u1XL`WpPBSBZfD:Nr@*CcOMPCuM"@Mquq<Om;e5uN^!/*#a\Z!G?)oe'#JRcO]FA\[9X&HGCoa+`)IW9'7_8@uUmu87G#".5K
+%JD"&:+l@p`Q:6qeEH0cf%c+?MOhou4-*\7e)C#(EClb'oBd(`F7ZAXR?GU)8nei`#TYG1,2%?UFP*1ZU)2K.X7JO6[]%'IU0-fsp
+%R[PkQ?7qRCh/s"FKaUU67I.7rA^OU2q*q!`-Si'n#U;4M\8[U@,DHMBKA?*:]\ZVX%-%K-JZ3+\QsP;V9il(u_SZOI(q66#&b5'[
+%)GG_@=cIs]43=G42s5=_5#ITN,IpHCNXgPME0fim?Sr/t`b%Lmc/qb;(I;<C?'9XP!F(5Z^Za5gg$EaGW(=dL6KsHJo<JFhQsN9+
+%7dlsUjr**LfL,*=mpR%5&?2AJ%Bp"UB(OI5N]'-NDJ`'PhS:#bF9B!!K!qRr77^m:Icj9d>l'H,PT\/.*Vg0*eP:*l"]%3.;kg;b
+%h?Hea)EHOBMrH]HiL^]0nGaFN1_lV8kBA!.H@^:_X1H]Ak-k)_mkZ%>llZ#p\"Z8(/rON07>J5QCV.'<:d2'M<Y+3#qbmTge=YT7
+%jF[Z5@lpb3"dIYsU[$%O^.2*4a=R70i+I3Mda7i'c=js(PKpP?2F8QQR)LWkqn3FljAR^\*I.lP.J>a1dI[E+,e2Vd0n-qlnd$a2
+%Zd7ICE^.?nC9[d8,(;4Nmap(d1TV1GeI[MOZJf+4lt';-eD7nbg+Y?>h?Bm*,2QLPC'.i]!>9I=N@M#4MTb-8[SJ0U:s_3U$iZk,
+%a3<DR'<7-6JYPV=rYC<Q"MnI&^.i^d?TnD'J,YA@r;!Pr_`LL`1/gs^g4hm.4n7P[c^RZ)<hh,cW@!%5>ZY@5SBj*`7;DhO_VOgt
+%%)"d@7n:nTR&n"XG-7eOrGe_>[T,J'C2,4E"<S?W#$r2K5<`'[Vs>A#-J!`07T4R#qtfpT$pRoa*4EZ""8E@M>!:>Rm%+;r)=T8O
+%ML.B'%iFn`MoLjg]/eY'%B=4-Jh8qIAlY_]H?qrE5Mha#Q\Ts,m:bK]nm)3lqk-?(31%ZSfZ;f"%KsH_GD\[E=hPX/k<<T=;eCP"
+%G-<,p3?$n6l/]&&P5%IoR'.\IK&EG])QSgTO^fR2qW8MVC2\*!cgG^QdsVhlU;0*X_N*_T&tG>]1UK_aT_H".`$PW:j"t._M*2q6
+%&,cA=HLALFr6h4G4qX?3A\#%N;9o(0"s7%mbaM_sE.7Cn^_T5KouVaQYFOUrg8.mcW5<L;.2](c28['HULMQap=fh-AicH`e;^&^
+%IY!>mX)o,_,4T#OkU<`/1&D:15+aMJPLqBJ1oskZIHpEb?'"c(b"jCG-*HIP,,E6l$;-g8`;l9X(:5d7P_OKL\ki,I+5#/\"L2tE
+%:VV%Dl8Fam4\\4.a(*e_=d#"<P-GQ$&ALusPN3hJoLtE^?HuEAEp;[75+:Fr(!8it,MC'.A8+38[q%f+NLMqGJJ3MaeVTm1`@0`^
+%8-G/FM.o<!/GRlhDo@k<f^u^>1m'kd,H"#OpWf*.pP2nE_,N)NGPsrZ_e`X)2Lr\eR8E/0hB-$VYi,\9?2K<mT8r;8D$2Z/$I)Yr
+%AW"mrSF956i(0EGbNF/EPMf+ZLm1V(JX$D4YWS^[)DB(8Sklh^@_Ig5'T?;Ul/8VI11>tJ];oK,l00jkr&^+?0JnQRS33S8M=ZG&
+%)1qKZ_RJ')aaBP-RU2',oFcU8<gL'AXJneq-1TNKW6[[G%u:*)*a5-ra1KM$CX;T[fbo^o6dpQKAPMae.)h?%IM>[9q2@ODBTgU`
+%s8&5R!SY<_>_MuJ'r1<0KEr`VHp$&T)ps:$S>1A#*@^6j/8_)U-JZ_McgdPR;eJHLWHei_pIQLn.3MsoVQFiA7i>q)dMD[je3J)n
+%$>nk<7kl^pQ/..A.8LcS+8om#`N4s#!$mE:O%jDa;Cbs3BDQ.6OI`.D(c"FdVRP6Y,!MgM*t+pVG$a_olIm^IZo`g7$38AU;"j!:
+%U,r6s(*s)&(-UAu&3t+*nu@K2W=b6%al'/c-F(S2I+,n/Qk0(t^\HcqWp"P^HZ^Q\YTf/7WJPZu:Pk&,0LC#O.j$4RFpO3ac$:9]
+%?2e;V@aV4q<a_^G&V/mr.4O^"_U)4cHLDY_&kbeanB<eL0$*V/B6MJs$ga1Zj'g.GpnZE<dh.Wq4M3:qr:T`4J$J#61(eK:8qD4V
+%_g&iLll+0nmrT9hS/.\!8[AM!<8I(>TXoH7/7BXCb#PD+ZCHO'0;0%A$1b%B2XNYucgIk(g/n(_Mkoo$cBLmAD>"j2e)g8qhd,Z-
+%l`r$,D5W.e=%ZSiN`?+UP(6?D]B6Z;0XC4?0<_TS(<htsOg@CD]0ln'gc6ek0Wc'$YQ/RM?/3PXW4@\hq<_:br7[(c?7C[(e;Ho2
+%7OpA+"@jJ]<[XU]1L`pE$ne3eES+$n"?#JdmiD&ZjY4aI,%#B_.tUVd4`j0KaH_:S"%jQ2;qJq-?hZ)TT+I_`*#J4)0a!p"f9gVH
+%ghOaY4FJhKN0/)!8f6%1J$d&9q0CFqYF`.h<4$(FL8)]ToC^/)CU5MUNoMl/=/"YPKYSHOC/s_NoH!O6.1^IYfNc=&!D#,Cr6q)s
+%aM[YODM>bBR<4`@btdEN@5M6r4u.5.%7;UM!=;qSo=9ZO#-aD%<]RO<*WU%GFf+/<SXOQd7[AfugT2l3^4#G4_ps`<<Gg]&!HBs%
+%lLSs-jkF<7?=,cC3qAg^n!ul[3DLA=i2hMOc5J$m,m+XSC^@!,M%iqR!#Vem^!1"fGu9aHkh_U.S]OK$24NAKrW&uhS#'PV@ED.B
+%PF!Zn_<]m/Y?OL/i(N2YdYp:Nl@L_-_cu?re8DjE=h/njldGs)Cqk.75YZ",gjn_Brf"O[>m&s\EV\KcbG,M\&3<(&*n;b;=bspY
+%p43;=jl#ZNRL;s>UuHI<[6eK%WS%.5=-%D?.L:sRQgiYS<G4_3)RlS9L8bp[gCfM@FR,<!NiCHK]%'TR9.-\HXYl,oF/6.JiIKQD
+%R+%).A211rnu,4<p?aSa\D\Ci!d\L4*kk(tE*M9O5g>OFMo3gm3L\_$Q&5QJOjCiEUL0-USX9d@H=.Otg:+)X1R@F]Q$]W#6OK^O
+%/UZ19@t*S\_V'YPmp,hFRBs3l5d%tDVjEOA!N^LulMCCi4<5`ics'0PP#VaE?ch)dSpp>/;m.tdS/n-t`\jD`$$i+V<7QY37Pspo
+%8,:W:>p;iDB#Q-^r?fRQP>rcEEIl%0f^P7AEL.h0SFoih,j5h"]KbT"K9Dr<*eK>"-qRKp&5Eq].VVat39-b*,:(/=\g\D50mo4.
+%P7$6@5<qmDb_>89#e/"b<E<Nu[7p9\?+\/HG!$n*RW/?p]La@MG#FOr8o:n+eTmtd=c4fqDGQsa`1nF>9bH/O4KUN<\.`2=!Q37?
+%+!0=a-<\Fpj`_cfSSoYEe_hCB,0COc[fG:k[M]JRdaBchqkL],NBe0/UE\\/4QbT7n0T#='NHVNb)Ra4&ZV8+bFmRB*#K3mdeN1(
+%,:rGdXq&_1`N*G"<Xn$0\Mq9n[#1=Y3K2',9+YQVU4@72;rTI61Equ(`c36pl*6SJ7^j4mChb1oJp#!ZMs':AP4^f``K1Y.0N>Yr
+%daB\<_9@I!FD9<L7\hiu`,JRrQ)BIUT)8>sV'oOSb[n6R&>]5'WTo_U1#eDRNPI)!YU019=c4m.IPI/0RUUr?&5u8cG-0//:%3BH
+%Eg=ER^u).kWNt>2.XDdUKoTEh1-s#B]V::5CGeBJq*!_;X&sBRgp-3<'bE1$KX2Jg`bK-R.SIAb5Y:i)V@]-nYBimVIhEQm0nkH]
+%,7LqLOt`OPU/hsg2I^*o+dOE:N/phaQfWUhM(DqAR)@iZNq2F75'g6Yl:=BLVUoi'[umi0mTa0G`fmPsY0Oa$/@_&L5.J%=d?c,6
+%(J&^;SJ(CMp\PU%_/uPe$!?cf-s5c9]#glf6Dgd8b>Wd'mLKRDiX.Fl8d>=s,8O0>^"LFG8V]T_r<Z3R@Btur7&]f"UdHAFSXr/2
+%=X"(EVO*d$F<@Lm^iZ8IA=H5)1.d(s0]V\6Mep81i^KN7S)^9d#:<!OcC[fX4\WPO(h\\?q/eqZ*fDUm+B;:[C?+>U^M#HT(u%aD
+%?"ekWL]>b*mlAom=K*%4jXs_:/=V]g=S7fFP(Ig10&URO0tJN)0;cBbF0-t^`><V:=L"!4Q1Y7FJISi!FTm"G$HKbZRpjRI/;847
+%7;s5Wc`qZSo\?tL*#W)=PZ:H'\&1u;r3Gdn\/*T[k$6H$N5oQ2TSV?]1r,uX/J>#br#@54f?nae!N2E.crm$i:\&P3\q&9u<h#/E
+%N$L/dY9QVefj[rnJ;M]ijNDpsglM$;\tTXI?/uImQ@rih)c?j#UIknN+Z52I8o99-Me=e:.a_rZb_Is[hVmgRksR'"%OBmPB99R>
+%:R?>_L!I3McS#h+*agd.(!KZAZ=49l'&@Y1,%m:Y_8*S>"0XXUpk6Q-R7VsN,*Ljb1<;1KCaBZOd/.e.M^GK[a%*fRS`"B<oU!UX
+%2gW(sROjA+GsT1q$nqE466oh9`*okj<uoB]Pf'i*ZE;r%CST\riebWkeX?:[Q,+67MDiE%F9_6rYs,arB$!YD6Hr)e,_7>a'btQB
+%N1n:+q2;]GWK;m;jL+)H0+IUI;UE5>L>6!1bS3rg,bImr$u.k&J0hKXTEtj@6MI7T!BD)"9-gOH7E4B(/ZN6]6N-Mo>gGgrPk;\Z
+%9hnsD]c;kAL]>;VB/P*mq6c\gk=LRH&)2URgcg$"R6"nNYOeSPImg77s-lQC+d($Wb'Hl"rC@C$>*3S4E`PmK@hCs8#+b^)5\sHs
+%YoBQ;QjE'`S*@&PUj"<a<[?CO'!b",OYW>;&VEZ^)O$b#7d>a"IC_n2d''86hkLT4mcX(@SY6t$$<0ahr8-n7"lAJ^3l8Bu+eD';
+%W%D+r`8J'8SN_0*[a7*[oXAHJXq`Gij\tSH>SrX7ZdZi1LJI-OEH^8^#ppshcgVmAG,!,d80mdi8U?>V@96T#gLt&u^I%-4fZj*$
+%*L#%Ni&C#M(T\(?N#X38Z2QILqnM>V>@kDt?rEO2/=bK,mhrc1D[lWiW^pj?]_1bN2Q<\Pod7oS6LMO'c-P\nhbSuIqIl"%j]9hJ
+%XahDZ:\'"?l@A=-i<*Ssf[LU4:oK'k6HX34E-l^B&H&rH8Q^Zj=_]f'HkFE5lRI`aO*d))\5WX79n?B.b]?5ej^q%BN.[o)!hhDD
+%o\[$>?q5aIh^";cqNit?pj1`ua2W.KS-]U'1[c&Q,+N$:U7+JohlipFXt/*?LL(*U7aY#d:$_'l#@&F!'2:-tE8U/N#\6M8?BIoJ
+%.(FNkW!chrX_R@80S#'03ud!Da8u^I?DC*/E\9=q2_[X""eAR*BeXOW^TQ!$a1Y&O2!.FUV:@#%&)g#(QhWQ816aZVTV]JgL>(4\
+%S)+SubJU_1^'>kr,At\35kTHKnN>L9o'PoP>5P=,:&T/SM=i\0]LPOp5A`:>X`=SNV;=lihYI(m(h3!kUbRVNm\gf8ELOpD(CR@'
+%i"4RVE`9!JM+pp?Bn$17&6@=]RM,^0VJ)62\2Ss\+[As+C9t'^h!Xn,BHMB,JBVU?E$g\4S!t7fa\%VDem#GuA'%@aL3tTs)8?%0
+%JqLa=K3a3""i*Q0oO42\GtH0iCN9i7+B^tFW^,.h$rWbmj4=]@G^#tc`f;Od@7!cXSGa).$]`Q,JlAI/)CqtG;!(4FI-:j1Bdpe:
+%+3Ah-T0CTZq*]J!\p.6O8`5G5Ge<8TO06$#\O2PNM?%KoF"H5FreGMQgLQ[GBZY1-'9ucHKF8M&0l4gj:UK*5Lsk:e$<0)dn\O=7
+%<JDVsl$>\IeRT(H:A5gb]no0i]e7_/8<W9Scj1cd6I(9Tp]"glh0(A3Q7K3ni'6_-!NG$ekP\jS8L6OPfPWY%&CH/>#XV*7b<SpZ
+%Hup;*pV"S&&WsWThCOtC,N41._7=UKbY)JW`/#"bPc[Oc>=S'<bdYl\@,T5B;E'pg\ILD68F()[T?GU$e2A-13J)XBR;0t`F,^>^
+%fNGsH_3;-hWVdtg^7C^#!gY[Zj=SJS`-E28F4SsW:<?!1)$'$XP"3VVX(h012llDA:Lu#lb!'`5l'!]K=n>*4)k`+39cLC&Zi'fm
+%35Tg?j@/fg+Y[6o_T7m[Z%8gd12f6Y?A!6'>Q)[iV@&\*/KZ>JnA1l2kTB!J*i>GbN@_"bKVhkOqB[]:->[;t=m-Dkh)%/3jL5gY
+%2fQ0Mr+h]Dm!I#G%KDgkA<Dl;cYAu1q?;+1Z\,B'jG[:!pWEtnY?MdK5PL0Ud`bm4SETJ!XtPG:`t[d3NGJ&:84q&?ZGtm-$l&g/
+%[&>9%iJEm@c&*g<=DX0?)QJd]5u[qOMOLfN8KjkN'G*gc9r9rA\ZVm2_gELH$FS%jL(uH#AU\4K2)=d-Bo+j'_aIPK8k0g6$-W"N
+%OMlGMX4Uuh.piPRqiHBG*bCV81+uWOI7pmH[J>3(U8H79`XLEo^$RbM*UO[\gW4D)`6XSAO6G9*1Vr#$7#kjord&qKV=-R'Qf3L_
+%=/i.\e8jh@Neo$j=YE`h&r>l5V-g@k!-eUe:1dg3no)@U&[0Fo*]P?MYe4_IpsT)DQtCTa0T*@B<eJ7J9-9LMWLcdmohsi__[04C
+%A715Kc[rBnO4i>kG^,W,G*mJ`gL_?Oqc:/\0J*M6;Z,*);)/FJVNtbrPFY.sEo=DMk-LTF^UtZc1M-"ci[)U?A=S9ZY@"1@J=*q$
+%(/Okm@_/ZkV+gk+:<ZVX_3bNAY#N$qiD4^#WfhLo_2$9ni?G9\X&CaSKOaqF]]aH<?Eif'9iEj'">Gu#j`5Zs""Q=RZr.@9/o>.J
+%+M%cH3bBj`$aX].nQ<.3KmZb)f-7[^FkuBa*kGL^AXAM"aXDh.\be7.jRHEFOo7-5+4[etWA.(m3Z0?ap_O$tg3a`O;)K"-7N8>M
+%J@7<?+)a#33@=<IXKki+P>s1d7SY7dGhL3YKVE]Vr"Xp2Mopbmm7\7$aY7_7gY<8EVif_JOI^ru+iZ8p4?>elATP[MO`!)M2!AC-
+%BCiKP^[[M'q'dksZ""W?mP'F9P'mlHob,rjZ"%\CkUlesD07#ie)5KY^ABBh-SR@)LMCs(QX2K"X8iB`'"IkYe&[Bii[gFp:]hE&
+%oB*]B^UO\87a\_P\^*hBer:X`=&TY>T\oaQQ&IM8,7(KpE'YG@X7V)Df$pt%M(G"B#g%k8_U!*E=0kcIaHkE5DfM530p""T;dVmS
+%%(nr*?!:W36hbT-i2$\`=oNu4O"*'0p^Vk@Ac_46V_qjk7Jmn5VJiNl*3T:-ng0MpF+TG\>m(d=<dC1t\*u3`CTi)\!AFrkmgrJ(
+%AO@cdQGK1>,A%?":\FDq>K1e@IQQr/E/..Xk']89m<ERA\I$9%Ir?",1b/6E?^g3.#_]DO>Z[Qdhte2I17O2L`W3Z=P-H\$,JB]E
+%it&.:126FP1(L0mbGo/6Wd+s#WD(\Ln38Zu"fDB]/j<H\IWsXb'i!;DaLY>G<1;UIf$,%H'YEnu6FI<,F_;UC:[f.e(ke8a?UVUV
+%?Pi:BEYD:r9m';=qA"E?:H=a'ER/4&i#A]I/L?BcYn]pfF`Xc:NUuD>Ac<(mA01H,Y;KY#E<?C@ijB`_93f?k=UGs\\>];0/qt!U
+%X10gfO)saHkl1J"esX9qD(3/a%f+^oI#HgZc;5[7,)O=f1l.%"kd:gBj/s/)iNIOp$K2"RN&/Cr[slkNs/*]hl]:8$qpfk@b`(I@
+%D#%0Sr=%\1/mJH:o]oFE+*6-c5-2dp=Jcrr8m7S&3(qHff\nP2Nuqr`I[]H9>o)Z9&Au)K&Bp<=]s9:odVm_`P7@dIBXHs.Go.Mo
+%Mn\\k,+Sid1UQgFHcFe68u9E0,F?<!<2>SY0gc*R::>G0Skb2"(c[V5"1^f<s(ej>L1d'>osM/%o2,/J=k&=ck#IbFq-9e:1d0T.
+%:Xs7EB5(G,Rq]U$IP%M]AbV_rK%@V6rE?;a[=4-rja@SjqRN4fB"gH/Ud(I5icSeSWT',Ee]LrSNK[DDa]+O,.s&J+*E6lXiI\gF
+%TrkJGa\r'1aD*h][qE!ll2m4dIE>Zp>Ub3G?E83a"`LMD>LD!8;ld=@N$Cme?ab#MmhTlmp:EcDQb]^gps_JPlPf>O.+IXQB3_K;
+%U3<Y>9kM.@/).Yei>/oc[IU3r\b`_.T%@8Lef0N+blrUtGhYO..c/N3Z+]]SZ4?f&Bc?2a_*\dKAa3!rS#!cS=it-ml:MBSp&HpI
+%TZo\@pn.>\BCb\9cF?W)bX60_5E_214fO0"XqPR)MM9:7@ES`&-tM/.g(c@'j$&I#$6kf%R+:$r'$=Q2;4gY)S]SlsChQ#QAb.g,
+%lhq.?Z3knB"6/&+QD#Qp[BK=@R\E.ZR8jO0%7C.??`f6.R8q5V\mFSJ>ZV)A=!D&FD#0DQJ(9a.?$oa)++"W+[Qr4W[f1C7Yfs4k
+%R@h'1p3Z_D-5^H6gI:hdm0oAh%i/[^O`dI)A#Q^;fERu>VK\=C6Il`qH0&2aB2&i[gHA+q?e(`L:k%(K<T_34d1C]WVE-5ECQ[Jg
+%h=9>=\L%k0=Wqk-CaHHd*TZg>n$JlSkPJ#L;>5q?@gdG8I,FXb_q:%@rSt8,2J\D^Dd*i<lJV9sGNGkIchciFYTIrT!sAVri,J&N
+%Ztg\Mpr]l:[SNA/<"e!gcu]#]$sj+Y8XPNd%=GLsj6_KnhF><Ln\K"!TBl=^c#r7mH`S5>2.I8/H1"K=a4g5=4eC6Rdn;nd"2I9]
+%P63W`\3A&!Z.t%Qmab];U!@F*D=]kQek4b)btf^-^$jn0b^<sF`I1tP(SBF)2M"Z=9m2#i[kD1S*W+8)c3%@Er!&J8ZS'"D[,_,A
+%96QnjM[7ir6J74c*S9W#f3s*A`iA5p?>k=Ib_1:R<u(8=Z@)G-pADDelJK4f\?:(&DH^_T>aABK<IYocS)8Db5Dm1M?#s<r-0cK@
+%bA[TgWiDd<mM#+JUig):H`b!5[Iu[$HtY)7/2lY^Sicb+E7C102Elliq<r_olRg)cN_>H04)TKDDG@n>msIbq4]"IK3u%ebY'm\A
+%haP;sds%chqU9Yfr8GhC&Ztp-=j5fL('0QsnkipqH2/jXLL*10WH6seTWQ%W/u.f+,%'f4j0+JY1FSbqkOBt2o<-60pY,V%*54)&
+%.&FS8qtJeIY(41ULDI1\DlD8J<NVgT?@6I@AKK-8PM443DrlAcF0YOa<.[0g^7m9#0m=Y!K(>T@<rBC4:/nE)&s/kZVq[ONW?F?O
+%;2sqTYP,9)9Dc;DH#c]/H7l21dq<<_\Xa3PPaT4V40n#^QKkbQX^=$&g>:^LX%6LeI+%8FcSViaRj';Q7QBkSHl#W00`-4CF'J$k
+%V^f+B:Png0='O2][e/-nSUNa&B2NNrdWf)Gp=j@JiN(=D:E>I^7K5H=e3-?-]O0LEH(E.o$fN//$?D*<Y>O[VQiW7II[/`q1sTc?
+%-W(L>dC^7j\nBhXN;rjs]>*Ns=92_qU*V*ohQrF=]CiOND._Dm9eU#Kh3qRUbK!IiCHd[ToSlksh3NoD_/40Caj.nIft-<W`&^Ka
+%b4_BH.@R/QF\BOMro;gAIqH`>:)1QdBVf/sjS3#mG).T7orRBG1&@FShq-d8Vfg!3?]gt[0g=oI`7Wnlq;-B8GHFm=d2gU5pE+Mr
+%leCcoZT_hl@!PA4g7!ERqc0cYS"=ErQP$l$#(3D)`@tc:,-4MQSB5e&"4ee/Y(YPa'qLAnD@"`N4Hl^@#*'h>]\#-&QZI_DZc5fS
+%$`IAI/gr2=N81dX`DE\9cenQ[ISXqVYHN-!)F=+/_u$]"lMKBng63OpmG0PN[.eLpL.CrC[&9/shP+SXd>!*oihe=(G2f#JAG(TS
+%>21c$+8GRPF\:St):-D$jaI!E1d;<37sR-Q>Sc36cdh@Lr\CprlYoKEmJ=80phDQnpk]h<rYfC6h4`@GF*Cm@M!i0(;7gpI-'(^P
+%F\=X+3FAISlZs.GSW\B7j0cWlH[Km?G7F@A<t1ZF?F"E.h"jc]rX)pen#AN,e"aC:X\5OI-K'hWVF8`BM7pXGTGpZN-^287kc)Vm
+%Tm+;%\o0PfD+jOr9$s,b=I1E2]9n]oJ(aM<&CPLc)nh7qPngS*Ao9F(nPCmqQcXh\jOeP:b96f&Y+X$e]Z!dG=^mZ,=fg[Y!)9dD
+%OMtUlW7]:no1$TMba5_BTemq-P0]V_^a5re^(ISlA2Xmt<hGdJ(m%cOBO;3iK_'iq>VcRk^?*dMh^eoqaCtbAI(_)V@J%s?+Xofq
+%O\G<^qd_!4&q3rO:EOr]ZTV_36*6ds3>#Za)17+B6k7+I>H4cX(k[u$P?s(aKklEVR8T<c#"K+BU0`Ir)0Sf@NlZaX7s+b+o=c#>
+%bHW<rR!GRC/oY>E]m20(6#FOP!^b./)4!sl)EB)ViX+r4W!JQYNI[J,%%]Um].`!\6/TZBr,gFh-E@9STjBh#^/>i'`CQBgCTH*(
+%*"uR,S3uW?oB1Oc?:>F*DC9ah"K:tZql7/`RoSIs82,rT)uFDJXoo:e.aSY;.m$s676(<XXMMD1Aflg(e'S7GYI>tlCFeF_CoG?b
+%NY0GSPZ>BMSq<TRn:qhbi#Yj-puU8EJ&cpj,-4Gn/O.k)+H7ZJ1a!5ao%="JptW^PgSboejB6p?#\jiX"DheXILgl<D%o@S"Cs_U
+%$)gP;EI\X9AD8HJ3%@h\4]T7g7KBd1;bUQW5(3I51&:bWZOA`RoC6:Rc0@%4M1\-X5A<ao1hgK46ZV02=]NqDN>e'O->Jj:.tV\k
+%rF7De#a+CWT1.[^N!elO,g1RQWb@c&!s^'dA52s[:jI=2c/MdW/E8Z_J_V>jN<_/;]M\/Mp/dZC<=n0kojsa0j2"?IQ*.)u3#HY(
+%C-7lYOtF![-k,Uo-UV/<CenTbg.1'<j-Q.Y9:N<pGG"f>(bX9^5QQ%?rXpt/7cJ7.T:g$'p+T^Ad*H<MfqlT$g#HCn9$\u_rpk?L
+%Va*-XT"+RuGa#RWfHVRd<&j`oOjLK]=g5Ce/*./-YMD>3a5fH"o>7-PJUW>WrQXD*1D2bqpN81_$!cn#$W9A`r3d6>>\_A/[2c3$
+%,lM6YZ0@>l'ifSU\po>>@7b"am&i[r3b7?;i8k0W(h?TOL[HqZX[+AY8,u&aW\G[p/t%!?5H-24)U&+@];8`Nknk(sW[?JV9m&Hr
+%cF9d+CGH0oIa3(tX<Idh#e8*YAN.8LhFHg$Ht33jbAoVJ.QWc_`F@\cdoL;W<?n)YY3th1o5UoACYNPO`!8"^PB^?j0<Q"V+K+PE
+%M0je9"K494R.r+-XL?bS=2.raG0<$K^)Ofu@0k_2l/Q1]j:V?/:Zm-\V3K1MLG#"N;rGf,QdA#:AtLr*KdIXPAA,YR,BUML+k,DZ
+%.+K[@2T&rn`39;M)[F\^")`-@N)O:GGo`2,0qEJ.bmN"i,$FT=Ms)mTI#:e:qsT2RMs9fpP;2bIXq5f&4=3#-bs3gs;=rk#b<ku0
+%9\i:)?@V2#pb%\]H`RnO!,Gufo`S>2/lf#K*W^7[OUimFM+q7tX*qf;mmm#>Y,>]m(?pK^U)""eq4!raAt;3GfUpCdF!t_-Xml.c
+%Z2;93br%_e/nXY`4[tZk^n=ojMI[*`P_@.r8WGGqG+n^/eCJpB[llIU(=JIX(ZfJ@\W^AoRJ(-%;W"(;rncBhIW..SU,k/<8B'4V
+%^9^'$]j4\t"#'ki#Be=0ibhTtG1T[CSpKE-*Cb.-8:oFeM5b\l[f\hX[,jN28i]UA4h]62(Q)c.![=9X4._<O1@ak1Z1\*S?G?:u
+%B>VD["QZ:,:tss7m<Ye(fW]ujqCSuoX=K`SKKf?ll*^:p`;Qa.]&)X8]KkHdU:Hd[/"VV?U&`b[A+TX8]mTQu0<SlDFU2QPb^-/U
+%N=4Qp9R/gG&^l6DNio4(4f@#@aHQ6B^tO%QEdL#PoN\IcGW#<R]0/r"DHD0W0ndS'TDn@$j+9SmGOu9\m0VQ,>%Hh@33I'&<$,ZN
+%Y-``sQi"HLj6,GdF^Pr\KRLOFj7r8%@V#*O*?!=n8q)q+>3-JXK<&l/.HbD`fm&)*d'9]?^u$*'b.Lc5E<Tej`6,_(fAiNn193[b
+%(c(7sRKoDNhZg^3a7XQ`^2jM]l-I[_Vt+QC`p&3g8Z>KQ@U7/Q1:&"(0[:5o1uI]"?>$u9bGPSRaD3c;d.Mi+:A`O]5'8n(lSZ(K
+%>G7"R@HY,96%9@@dhmK,0dj+k"F@a8&rm)HM<G2kK(!5"U5a,_^XKlqpNUlM><??CG0"iTrU"h:lRmV;$)u$6?,dcV[PUbX_Db"m
+%hJ8cA$^3`q"Qjo/?a\LmN+:/%cWNEgiVgC+DE*0RIEln?/a[j;q8m!P?HgG)AFEIWI)4-!$J?<[q8$uVk4a5I'2QcB7iOn1pA;2]
+%#;U`,S[6__F9j`$-nj'*Y/n<fEIV^V]l!jQ@+#bTRL7sCpGCT%l.7bPJ<_+B/=7fQn.Xp+;/+IE0?a'[>4MUJg(N=INR`;LeQqb=
+%hHmTh/sO./+(niUQJ#QY/B'M1j1ISNmE>EVYIZuFkK(YFl>1c<'h(Ma8/"BTr&^@"r;>':lG7*.CbCjUDTB0@?f($QI7IaGaE(IC
+%=7iP]&LJY3a^Z.pZI1NXVcgWW>J/33CS\)K\Y%m&67%t-SE=^gYdqXCihtCVDfnD]F?pp`Uo0$^%:l0'QO.9FpMJ3[FR$@Hn\dlB
+%(p6DLgknP(.7p/_`o-N]j7`DnD^?#+;%pb;DSp1]GgX[r0(LL2aiJ\V]2ndY+"PY"Ip'`]Mtb=g,*e!b=abSU8$rgkmaU16H%DM%
+%+.19_@Ip5OT%H#iD4^[P*Th_oBqW&dNFAFMpfm^mrT_;/NDJg[$Q1aL5ULrI^7AS9L=HifAfO-"-EQ'mgo=aB5<'b&Z4s5;>N4aM
+%hSjs`\Xm_9,rpB2Ohl8QYTaJCd*F&[Oo7Xf6JXShZDd339EACZ.IF]P,3A[Nl\>i(VPd`s^SOaY+?ke"$sdq;IU55*ZEF_*C(5[c
+%OldHEd>_9V6Z8)$.R!<iNTq3j!C%J`hqJb9jaB58(Ot^f9;9>12LHk2$c_hq8&&[2G2fK(>]cpr=InJl]T7+4m`(*'s5\M)b=MF/
+%(9>4$NAoZ1D"Apo1Wp`NEShrs>=F=(Xs"YSG+M]+`S8#uiW-P=04Z34]0)\_B^JF7(c"e=FeSME-(NBEaR!,LIQ?(^:Y4s,)-;^`
+%&-/X$"%4$@RP.&3(maXRFO7<e)E\u^OF$M>B0>pjn+Y_dA\>D9$B7Cp%VL*UrOHB4k^-!j=XI;H0P7\9SeI?i?.hluQZ@Z,]2_Q*
+%W76Y2]mK#?>lV0O9ng6dX^"f`_l)Sk+ZQai&H'p6M[cS%[:BI`r;00?:o(3UD-29pGW)'qY[3um+m`+-f+\_.o6I)o/]2'KI;jdM
+%ZWgTthP?hhFR><J70t[;b-pWUnJF=(D[C[]+l5ZsoCOK3ac%CgkK*DVMr-k+i8edBbK<IDhX?.Adk$a2[O(S!0'NW=2cT.%\\<4d
+%q"gE99>3T1ZlSWoYc&?G%+0p4naYFS<pu'6)@hD&RinX[_QWX[pltATBT3qZJ!Q*Fj6OAq+4hdbWkUDTHH%e]bBJE!!`:AD<_j3)
+%aDU1/CR88sV%:;`hgH:Pc10T!^-=I=or\5MH`K@'mitO9dK?eGiaAg13r%8WoBDLHe=Q3[\"[)VJ<*uq4F%!M%O8C&$=/baWL4Xr
+%ZRI.q*'20Q'g@>!h34fkTAHLj*p*4Sm?bkghum[BpHc"SU0Ob'/%5E;(JlGb\c'ZCasiYhdZ:#/Ut8JT=)/9f`S&Krgi!5$p9P=0
+%iuo@B<Y`?<WWEPq;>P=&3ne_,8&T>hn\<j+OiID"mF/'pMY$_P7+%$YQLMVJ9-^t5?9+jp\0'b?8h9D%jCA!UHcGY=m'%(2e(]-g
+%lRt<O;E55Gf7&3bfCp<3-ND)@bgunJY:`@1q6!LXPFaLGPbOf!CP%N[:6`*I]rgH2kG\t6mHj=*-#<O]X`k/Mk*(5^)=gT&W,=La
+%:+-(U.tNcrBg)0Iq5E^D,c,n6T:C5,/"j,=N%9e:PDK+G?E]T+IU+H`\V5GIN]qPLBg]&f.i[G0Ffb98JS4F_e@oKLFBSK$SQ+(@
+%lLHr@,M]%Ql[0QTG[Fr0*V2Bc>Fde3nab*=c0siJS8)$^o%o&?A4o/'VhE80<"ZQ"A'!fig",IbN<SR*C6iBI?r-,)3u%UV<Fl2/
+%QsN[/Zh,#tne/JsEec!B&;ouPWH6s4J4tTpolT-/e+fKm`</[UkfJZE+,R@m/90M"!CucIYhN#.U<%$rjp9HAn[i.E*#EZ.#mSK)
+%\B#_F,76Fc`%;GY8c*=r:ZiCT'`lr;<`5Lt?04Re-.sVg4p$Muhl6LnaHtV8QN?Xn-s>VXJ9;M8lg.WYL;@*i9L@_Vfc7W&-=6uC
+%S$eK"N*0"KY@e&+'$N4<\tgfGr>DYZ^j05j@_fU>b!o+K8gj'9H0?/3j?tP\F,"pNjP,<Rdcf\Lj"[%4F'<#-C*:i:-n<9mfi51$
+%)TEM@+F"Y%;.F%U[-b(M>e_g;W4=U0bqp3GU7rXX5]0-m5V4Zl8*IR^,,)S9e+m;195LUmqMPg86@DW_;=QDl=/O3NTO15d!Zs.#
+%fil]MM[9;dTUT(\/fB*Fisu((&'(5i:pa+k%(K1.VDSTsZ>:`)*OL?k2'iuA1;<W'B[=(X<rFlEre<hdI*p)WX[5f?/(-mrHdC[!
+%\2VnZ-BtW@%#nIk[?jKDP.2iJ8rgN`GuFq6(S%4Po?a]a2"#n!Z#324nTFanb,/HFFc^`-[POZk5Dtn--Z;pfVBcGj*EG"tW<VNu
+%WIVf'"2)9BbTk;NTU>OS))\X&9?/Ru*YMR+Wu=QPE6lrnT)=u%p0H1\b=ZN%%h!O!0jOW<)c2hiHr:tWbhh@KO@M6fLOcr%Pm-MV
+%h?ma=\kLIXFXq7NglF!!&hiYC103;^(fh]=0D"IEh<5m\]nWCLlRJ`)Rpm6g]b^^TJRTXCrh=pkOu*oL[j#X</b=N=kq=4Sn]?\g
+%e3(AbX\;V&)'3Z5J[?hNZOJbe26h,*$8M$\,R-#Gm21#k"?DZKIg)LgA8LaW1JIf(Cu)r]Ukt`^JmJn_[:7jZ$7u0c_aT)/;!OGE
+%Qf7hG1>([YC1;paO-fW@^q9^=7EY'U?oRVM>O-C%l?SH,*gr:Oi;`kk_./Hk(SLD]Qq:CUWs2/\[-sL7kZ@<%a:*`[HW_X4N-LQW
+%EW%A9Df?)Zr$!op;$m=aQ`N]h%,.d+p'OQrG_70Z(;^Vqqtl!hk1UTt#-FVU*+FK@/!U.OLRLia3$DYKmsF:-=jrTXn\199%kfdW
+%E.KL2UhD*s$]&(0)AX)/aEX2a,A^2THEdNfAJ2W2<3g9X=ZeeiUH+GgRE]a4_#LG582c+g,[<kb7^38H!<N2@IRR2nZ,=el)AuTm
+%fkAM#i^H,131HHJIToBF&pDse8Im3H%TOrF1d[Xr9*9``('XVGfNHs&_f">SBnX\`j7hNTY*L>2j[6IsR5B!#A/'JnX)%rP6W/0V
+%P<--P2Q'u_WeOUgfXI[TZ\@SQf$K@pE?fMII#;_u*6ot6IiS6B)JqRS^R,V[_>OoA%ZIoRBK(i'1CF#;*EW`@!m2J4UgLk'HS<WH
+%AIE:^_uQ46=QEjC`IaCU"2ZT_i6QS.,PhQj!u>p`ZFl!F6bRWC++u6W/^/+f"E:9ST>)phM@DMdmYa>?ZGK\ObSV9a(n<H0F:r*A
+%&Am_PHc\!go_j\"#9M"^alG"?k2#;1Nf_DW`d.;Ik?'ZE`\)H$dhMC)AC+2XCmCNE1=8WK:8U4&:UR-0J<j'Sk:nc35V6!=K_rQt
+%*fLP;nlWD).9XXB3bu!3/?QgsZ!sTjlP+cj5=!)&>U7`nJmTYpg^6],(26rcV&Ek-cXpZt_c+sf1G$nolJ%_V6Idc4BXeM,F=fJg
+%^qL5OUs@GGjYsZ:[A;j0&'0*W2P<]!-^.PF3:<'N[tiU(+SNoFUkraBi['8h!e3-JId.LBm459:Wb)iR]7<t@((I\IcaIaoBEhB8
+%iu*1QC'q:[4rdm-R0'0o$,/FlWq_iOV'%L_37tGH?s9gQG6nqI4SG.N>dp<fjJ$5aQALVAn8-<6Ur`CIT?'tp1kZE'L5bCUgXYG!
+%ftY&nA$Nf]o)@ao)TDl`g*b@+X/ZujMPqE%aCL*YBa#b9!a(H"J-/ILe#o(8!K6BQZF=4'65saaSL?h(Bh>OH&jE62_5(WX38@i>
+%+KS/bHq?$9;,e8B9*.(Pr4T22m+WtsfLNA#PEeVQ&tp(55C'AOX:i0t94M,i4\3_Rl>U0aj%]eaL7=!`!*RI&lGUG4eT[@E"^0Sl
+%3u`NA;f'BLamr8!ErcA+=o+5W34"cp;JfC_RP2`MTg#eCAgJb1Jmo<b#C3WA%\)O=AO3Wm<e"'T'e$'"n2k6B"lHrHB?YZP64n$,
+%jTA`uZa,Q6\n&F?EK7A*Z,ADJ&VB9J8DYQPY#U'_oiV-9]Yl1c.D8iC1m;WbiQl7[CR*8.ZKO*G>9<77=>*Xof7kD^.N'"@UA4Zt
+%5&GpL>)''"c,V]Sg=J9lF_7T^5CfA<c4=,!jK.F/9Tsi],ChULao!u_/EgU+%1/unk.nEg"Nthh3M4JOQO8X2("omma[P:dbA)9s
+%_f/&4?,q#p.#a\`7)A%qjlBrq32Y"pfk4f-jFs"E2!DKerm6dC,T597OO$t9B5!+L2j(5m3Mk-T=X9H?Cs&0#>uBm@s/cS0%hRqa
+%FC'"X_Lo"$R[)Q?&?35YHA)bR*kR9pYSMS?-/3mR\Y3KJ.&5VM\b[([2g-0ubM]k^:RYA9<PT*]'nmqM3g0QQB*(5&#lk-bgS(CN
+%o$FjW\Cne5+'"Vn3?Xq\;;pYK:*.W#*Ib3OKD8?W-*%;7gj#C8Z@PVD`(PEAk$gdBY\9/0K;ga"B!E1C2d@349h5EIbRTQ5(0,nD
+%c*HN=I^Ttli:]`NZePI3QL9HTLFWG#4m)d=%g%O)gulb]8h?jF9i_Ri.CRc>NV1=GK[gE,50_$$B)XR/]VneiAh1-"WL(6%.m,/>
+%+7q=63i(sZ^t^&J8&SAWN_Ts%@c))&Lo)OP2Nq/q<OUoXgnZFc"6+hs_mlIZanJLN06`d8B'%0<7"&*=gP?Zq,$0h;O),>Ks42$G
+%PeeA/F)ie3ZWM+/Hd,r+P<%@*/ebN_2qKPH3Ep[#i-AEtG61p$^YSU#1SuhC;d?sjgWS)opZ:&MZ'9C*8T=%&TZR%%29n717n('m
+%^XrsXV?DacM5?D\n&:pW^T]/_l`l89A_SYl.E&n%bImG)fR')S?@mFq-f2rsD-0msS9j"7b'#-6.)?:h!u^3'-+--"KF+Ft=j2oR
+%"Bp>X=FHGs72!PE3>b+)[OC"lDS0g_c_AkJq1S,nWY+c%A91[gX42&g\(,.<fJ]aCgBLYk,g0PM'e]7$4UiKr#SnomW"cXN#gO+r
+%V92bajoG*e(P-=8nL4FN"c_'t5E1*[FVacW8E,NY)hERTIc,70c2EOhTk2m)>X]nNk&*>k:hLHme,ZjNW]2dicE"\@YJaM=)>Sf_
+%diKN=_8*.8;,,d%S;b55+VMOlVO"6%B#Oc0<Ss2FNiY(mE1sO:NWLCW8)oCjWe"/:@raf4P\[(5G88J_O%F;tAHj?iC3^P8ahGFP
+%Hde<CaJ>5om.',+Ho3TF!Urhn?FKoA185#4,qcc<3<*fS&Z_C;g<fP*nu!4pO&pao.Gi<S9V0VXF/8BA/DIZ2l*(Om/St9-0ZU"Y
+%#'3g5kfUiuh!]7d:%NWZBRZEHhEf)"5e7/L3U%:NEfcZML4b&]U:>9Qp^I.4!F[4jnZWdF^9$n:YXH#c;R^*:HI_Jon/77F%U%A"
+%F=7fubQ>`)mY+fboFLh/#E+Ij4q*_%8_pHa(N9/q*<AmhA%1HG7t';RRE9HSZ?_[ZG\7,]QXijDC`Ynb/"HOj!^!mt1pUK4#3:3F
+%lD"OWZ7<TR;k^Ch2e`Geq1D-.?[k&f#O]UC4mDN/-8[4TBQtRRa0$S4%=]$3;H2IoR7.<:bd(d&#pn*?K6,RElGY7-5P'"0H8+8:
+%FsoV*hkTYg%c-Ijn$R6?]bU&`@+H1XcXEJ8s-jKM&Y.m+^`<P;:n4`)Og8)-Z-+H"7D1g%[Nbg\Z/?i2oEroP0VISi][2!f%7W3F
+%gH?BB2+lsf,B;CI/grlEaC&1><Xrb16%[H;1gsr!_euliTaftqGo`)e*_h^QXMs)@C]'R%mkU].iq/)BLY_e(D[o7GYW-AT']rCt
+%h6:?n3"E#0(<+YieYn+ZhJN_>&44)^lP]]AQf1l.W,)/hgug6J`6fMn%EP1Tr^=s1CY@bI86TWuL17WihIGhBFRV=8hg:@nj#9:\
+%f0FL[k`uXU@:3I3CpJULYdj\`5VgR1Qh`YW69'tHOOa1]Cl^5:(#n?3=D9h_<('rAARn1bf`K*dL(Ej#,fqh54Hf2k%oKq>5Jqf&
+%<Fs,Q%Ks#8WcD[;EuH".fE*nZa"ZEKl^3(oO^D*C;t#lH6IrW>b>9!CUrt+k_r*9%/0j*A6BR@A"(2MG)Dbn$XX^RLDZF<9=G!UX
+%V?*c-?*OY99<=f'+afr^p]Q])&)%'S7V:8G=<-+s8K2]PV[7&1PC!A"`K9U?0W]EiQ=Q*+]L6&,4QNBp1rc+Vl9f@")'igO@U%t&
+%QNU]^9JJN[nAUYUMip14?K<%K:lT[/<el:S5MJ!4CN+E*l)BVY=3_+Q!eRh.SeZbn_g\(pc7fA4IlAVL\:9)5I]1i3/IVfjJu]<k
+%#2fH!9F<Z)2!5UB,Q(e@]T1-YYKa4*I>KQc+n"RC)%N-N/7j_klC9fj4dPe];lg#$AdhC!Kd_^MT@XFB<[Yaq6UZb#G;X=-r>Y0t
+%`aV6%at[+"&^S<36t#q%Z5EN`I*]7J#BH?m!q5,.)[c,MN66(+cXosDfsqjBjX\:ulX5R4Pl]>Qjb[do[gjB$3m+]E\j/M?DF-7h
+%7FKY'c._BJbfM2qohPj/9@hg`SYT-o5er[*[M'YkGC,A>`R)SJCiR#Jo34_V,E4#+].^"E?Y&i8RY5,SGt,kUOD!?s[cdL$cgqWS
+%pXSk>UV?+385g'r/;J>efuZ5E2+Q`LI+DuTNk%TqfYWAf2nS+/^i.pW9>A6C=Vt>uH@=K]]_CY`HE<k<l[0F1XTXYN[aC!+p%KQq
+%RJ$32;fe0rJbn`_l[:t6m7I$D:#Bgbc9hi"c<0jcT+r^F05+!2HeVTu]lJMEb0s&]Z#@3j`\[NsA'pm>;-oX!o8A$lp%;Y)b)pr6
+%_ok";%f6!85/5sd]j86f`/ZghB`s:b/IRa,oVt'Gqeb@rT6>5%pRV"Q!ShdVkIWVHc?B^l`Notj1S\>e+uRG!E&IF4I8rkK_sG<3
+%c%=Z^%T[']Kq4^G"S$h&AZuET-2F'7:J;]YERpD07fYI@1ck9lrdD6`!j/h<f<6K&_Hb1m+=:S;V@`!D`N!/E<s_KO;\+34DUb/@
+%IV@Pb4EduAXL>SO-=O"de+*W('U:@_VUFLt7BF6QCMe<$=&n77(!K!8(m#=`fEaO\\DUr?AJ+gr"5(gZ3!C!]7Pi['LT2T5%)k1(
+%,hYL1d(TSGDSo$8I)0Ab[nUit\[`s2QA(7<Udj6C&h:%Af".Ss8YAEZ;fV<WdS6Rm'`ubhg&si$\bK8D@)XOq'f54_0mLhk()p'o
+%*4nX0c3?MNo@WI#Hk"2gpK\PeDH=L+N&]I60;J'N%\7EhRDT"U,+`1=Mh]+/?4%,M(BLS6_Vn*O`,pBsfsVD9"l,_h`h=q=`b$*o
+%M`6hPZ:^)uK4R%1TJdWTlXl_Gj8*EUqI8XhLD=7,%:RBb:eAPuFG%k`alF:&"!g*l*eP82H%7ZCi&b0F6X8D"6h/uZGFMBhoo><+
+%MYJ<fnk'#+ifo+Q#hMW`1\hk/W6^-hd*C;QV.CRB[+L]SGOJ<-&b:Wb>R)FkI_ip@A-']DaE%h61P'qdG7P2:QLfcrAaEaI"qRTF
+%,Q<M&AYjoop]@Pd+jO:&)oE>LRi)<`0>m<!!D)?di"GJ<7B[#8#p:H\<3I5o5,!lV%G*M]`54OV9PdN-TUfr`146iXD.A).IDg\l
+%'al?)^aco\.TqL"=5bQ_B&[FNKb&sR'B!(UQOJI>[m2[T["aO(A@T9S/<RG>*!l%/7uG1GD2[c,:S[Gu#l$-O$6kKe,;Guui;d0a
+%EE%Ju+/=S0QW<2\/jJN1cf2k*5V>\YK7=_0dsre+'J++n=p/f@/LsGL,>T]qN"Q/_\4uOt/[AY_Ks"\-blXS\dCYJ-pP(CYW_LOk
+%YaE(9*$Ci)CK@h[r&l5GY.J*i'hj#aUqlL(d=3"#AH_T/h-=(FE:2uKB-;K`H"dsZ"-ELf7CIa9-(m[\G4P3r&kh<>997c>=GMWA
+%6t6YQ@)d8l08*mLZBfB*fSs")]Wk!.<'u)u0k*qFJX--5@G-6\1.OouPaE1W9>gA>J;0sP7.sInUq>M$hdIB^aCY(M>=9GsRmYlC
+%\ZLDh#61*a[gu\p]jfQ:Ms#nq!N-<mj!>p)c8\DpXLcnA'@URqZ1[\3GZ7'QFe8ZV(P-FS..>mqCZ8Pf20N)sq&D,EDBKguJ>VNG
+%+U=Je^aU:3oYC9V-'!##P&4a^YkYDO)IU@K/n$Z#h)U?-dHj>b"ZiDo,'BZQZ8nS)?@0SS3DeJ:prAkldZ!&GmG/"q2^E]OA7I=Z
+%_8h+")cKfp`OWUmS!>Z!c-),-)Pk*&?oTBbh2Qlr!'$==82NLJQ59J>\YES@`#^ZfAn+gX6NHRL)MJBK%4A'l&g0AHaImm,s#n-'
+%!gq.r_M>p0J0p,[#Nsr/.h\2AX>2_;*3MY/QeWe<1()M$T3BOH]_(K17[h4+^qhr1&!fgIRRB9K3<qW(pYF^;DcH9R2F4^("r^UU
+%/1)`-;1o&@kBouq`_k><XZc1qq1'`SnV63/JfnfDf5G#Z.=IiX*SkJm8u";d>5Yg^/=p(sPpgle5(kOAe^(ONg"UDd:N%TGlL!h=
+%IfBRjBtb!HMdOK5Y8F^srM6T^e,<]!;I#j7(hR[V7]@If1Z`ASBI*25b[-bJKER7Y[(lFZ5Mi0&D3f7nqsHVsU[9jY5/ZW2hb1QJ
+%e#\Iu68JS<e)&7Tr8n3"%$H0C&3'3ap)+NOc.9(,de3_#L^ZnJB'(K>;%&+I,9G=XMAFkr(=j_%qYY.qgK(MdMh\MSSgtT;,_ll_
+%['d[g#kFRaDjWu0A=ade0rEpuI=)!^hlW<9=Un!/hX\HlGdJRE[=<")S1=KtiJCi*)R:@[R]GNd2[*P)\%I*j>^GDiiUQ(ta5@f6
+%Q<>-F-?G6=GFj0Wc4BU%11M=90;mOB8d!/>RqLSpJmr,17XJZ,gaOT`+__D=6bnB6TSA:)n>6ca9L'DibaBS-p'-03[8%[nncKs%
+%D)1[:"WUB=raL"+B`;#P(2;;i[CGRp:9m7mhs6%,.,\^+e25O;4eu^mMB!l]\?gH^@;:u?,DWJbP`BK5o_+^'MA9i*PPthWh.<E#
+%qQX2/WRO#c@c[r(PT9?+&#JBrSHt!LG4W['5rX]78X9?5.S;:&Hd0i=@e9PF?^ARDANTGZqZW4$7WJd/&?MAQ1&@Y.@rNSaOMsg^
+%n<1F4Ru=2B*$b5IQGBkT.67fTDQ>H/>51OTPA,6sdRN*]TBRQjp-GUkWD1"WH$%J'[W!/2$c1_q_)K!2LjN"](pE-C(AK#-'e\uu
+%pe+_Y?r,H59]`2HJ%1OO:[,N([YIWP"?^q[i$&Oj;G:^^.10#dT^:.AaL0;IKO>go!G5u(+(!s2=R[\/8s\U\]85[/,.`SZ.WcG;
+%p0MY]\enN60^PApj546\dpI`AJ`HR,m9d^oh<Nit>V1lCq.I#S-D8jVdfP6b=D+IR&N=S%gp@-;bOg7e9iVpq2q\#Rp&o5L/$=Nr
+%XhiV%k\6F]X;j)B_e%Ki2iE_0$chO#]SBmY-iSY:^_[r&k'k*JV2qta%GRW8./CurrL@2G@Hla']G*ejL1pWO<Mnb9!^/8n_=KTa
+%;+WuMKY5-1*K&tppL>X+niHd-8hQo@=7(poTVs=U7L'u,^WL*+@!%89mhQr%<i\X2l=X7Ebk'#D?4?-0pI*G\,"Fr?<mU-aF>DS0
+%ct"F[)m93RBrT,5(h2n&Eb)1n2Ui3!h^smcZcS*,>q$9,>jW_Oc:7`Y$pNg8Gnt0NYE&Jm]?P1I(Qc@n"5b]KDmV,cY.OLnVr?[g
+%""1r@mkb^dUA*Di+J*_/Bd@4OQQKS3j#ae9MAL=$VpKH]aZHkGf5fqZJCt[gN97A)39Mu!lGEF$6j?5^QAXSaTHf:(Nbm-@<6P'R
+%XA8S:Tl;q;OW[tB2t0V?H"n*6m"m$M3`*h]2$B'*K2laJ4<+reS"m6Nf_Mo`jkagC_Ztfs(@>*e>*6QQlp'uuNP?Q)e7*;T!sNEd
+%$QSNS3:8nb6u>Ri7WV.EZt6s.*$dehCs/9u>gi3O,g*K)eU(1Xo'Udt*4Am$Z2LV<8Wo'InX>6MeGg_&R(m*A3N(?Nm@(Pb'YVPr
+%>+T&qk-TY=<SB`&aaiS5bkjh1Uq@blN"f"?#2dHV-6D@mJ?fCnO6GMQ:WX_7iJ>c1"Y$#U!Znt!GF7t(n+ZG9K/;8$n6!EW<'qtt
+%MP=WnEIBaGM5TMn9JoquOC(+%bsSm*l',CaaWpiWEIoC4B31][B%YK*)(0@MVrM"W@msMQI'Es(;=c>7+\e]UF"*bLDX1[?]'Uo;
+%bZW_ZIV:T&_CG`^$ZY/UUd0EHihdZ$#7]E-rnh9*P]u'(g%;XRhX-\5BR4+.eLpMWXH_j$KV`97,A&mqd98GU9(pEM>9(XMTc)q:
+%+,1bDC,7&)8dm><2^I[67;&$*2(a^q1KsS`]]&g*:XH'NHC[IiRM[@o1#u7d8t<m\_Su@40->)DA2.EE$[_^)1"QjX#DOFWW3#;>
+%R:,n@n!2cqSnr`i-chPl[8KlWlt*KP%e8*(S:(*QfiQ#Hd:DcPn4I6?%$)9W+G)Sl/EZJ[bg^Q8_:t@67;M]<P6HZAl1@[K8T#@"
+%E6r=d@Dt#MpQA\5ar4D^qjJu-D-;OJ=_BR$<qbOTag/Nd#uo*[J!u)[N['A`*DVUZ$tI)+0A;B__CP[+rCfAoPTFQ:%VqU1Y;AKM
+%rccs+/83mbe%$pE8\NC,_XRbo[B2(<calYXAstFuQrT2g>)#(UQ(*uVPJYYP<<e*)MrtuVpc*Yu7?/3&53-<d(BNSul&.fC3$BIs
+%67BQZ4F3GHOWj;V_;,h+M.L,@T4R7?c6(^taF2H-C;_2>bH]4OfK(uiaa>3j_!<P!=:-`rIu(_`pR-Cb_,OP7,'5QB14IeeS6:;d
+%k&^@&<!l*=f.lj:p=$F,e3`nh4e<"h<DJ$n@W'MD%.<`,XSRSd-Ta5M4V`p<7EhJbP9njpN=,]5]'u_1bWe=?)RaQjLIE,.;b"XL
+%?2aTLUtaPc@5R4jG5![^P]+iqR9,c[X0nk7H4QVu&,aZ_J,R:"qhtK^rp=(mqY1$Sn,Dg3J,#@;nTW%2J,:>fq:GZ=0E:\1+9(NV
+%J,Jr\`..Rns7fC)hZ)Pis7lWQ^F]78J,(btqZ$R[hThblc*+n]h:I/OqhOn?o,lDAJ+<<kJ,+"Ir9NDCZ1r,Irg3Zapu?jNr6,-;
+%&H0'[gQ2C3O8mi3SUUK`4Stb#ps]q9UGi)Gs8'X2\dR/$:ocFkDboAtJZn=JpdY]6af_99b$P#g5FekGoUZcR4qmZ!%kkl2)*_XH
+%.,:Oe&[XA4&Le5.Xh_su2<dkHQV+QqhEHD?gCO=Lc\j<)s5BZ\X*(-<T5BRKT8^k@*[Yk8V%<O"Of8JW8\FcWr3p>9j1'_\>)&m\
+%]m%rBWh7fA'9O`@"3d>_7#7u9,5GYk5O1D">lJu:L_KXqq1_V&ZdkXQ86Fs=R,r-Nrs7?Vl<+eR-DWb*9UKdpf_6SArF#r\Z`3H@
+%j$+78TdG4na4L^[Jsroq8!H=]!@Hn+M*g`tR+NhHq(.P:$->)^QdNS=@1Q,b?<['*22(3BDP_^3*bVjkefO"6$O;SRVdLU33,`ra
+%7ie_7>h$P1h>kHB-H(o)F*)5sJ]CKo`3[_#Pod!a2[5&p`X$JD/k4HI^5^f)\DU.&D7C3E861UacTVbT'>hctau9T)AO_6-]1r9g
+%Fr2dRa_,7kD]:7;/n*UnUO^Q$AC0iEU?QoY_8m$t&"fsaZ%4NR5<d962hY+7TbM[9a>WQ:Xm-SX:9b!YL4hm"<_`A!(Nf<b=>Fff
+%euAq!&=Kc=S][;Hpjj"=cr.?Q/LQCQMa\j#0qp4(HoO<Eo`5br_`B+\"GF"gD&/9:mn>k9&]lZ#&f/peiRhtT(0I?T7+hhL+f([O
+%ALAN!Cf^%^Z:tV2m5%_J!:Pj5Fne<t"YA]*PB%S37O.i5VM>p"2XFEa:ea-q<F@sT0S,MK'=(cHop&8i4prlOAI2LNRghLBa;Z6<
+%V=\OF5(^dpLu7g8J['q_.:ihOp6d@1G_on0D%ieeIT0r%QBR!4>?<N^?/#t`YglaYaQ`&6Q+Wj@d-tMYl023SNt%%^l`Xt3EHK!6
+%ejlg=-Qg7brIqk-952GUl0`GX+#b,EH^pA=HnNtM]WZZr**:PVfCFQ6V;]9jQ6123WXmbG=^shq:CUDGBTHr2O5f2?UJkZ`e=m%7
+%8;m-U?\!46`ap%_bVjpiqW!dhpg9g--M\u3/m>[0*MC*PB-1V7iBs`VX4>PE8+[!^9[.Cj!RE9MF=QTJ";gDu?DWCJo;/\8?Ye!=
+%SuVHkBJTb.e$=Ji(oMpCLG(>SK908BG)iL&VJ5/A]8g#tn^?@%qeG!<'ej)t^<;n7B[8HAar6A="8#!bR`9aG=\$9_IaTSm'S;@6
+%-7;B9T>Q0;`%UZX[AVanPOV7.*LiDVaq/_h(pklH:n%c<$KY-5QU)U'<1Fc7`YOOBY7;,(C[[.Pf#0.a%0B<V',J)Ofdc%7-EPnF
+%U=NuT^(+?gn-,5W@u7XjiV%=7=bYE!"OeEoJJgA-]F`Wo)6Z_Z9J^c5/6TS^e3RiYH"X2(/aF-q<sLdlV`AN8e8H/9UG#dQ)%PJP
+%lUNA-VV*m[$&GY`Z4a]N#H*JCgM2m/hOFOoktTEBa6M).2-\DD*3lXXLY=p;<@b!dSD1e$NNEC!``0Q[Kr(_^H)Lm&kXLT(<\kms
+%i<o:>Or9LiH-TeSATKg";.fSg#d2S/eS&f'<3mLHPo5Xjkg;6!>FF:]d6o=^)mmWG@+*ld^nXQQKFbD7lM'$#'=h[QS[rW/jF>hQ
+%&HL.1`72'BmA;!K0fK$lT[=$=ACo'%4=tUk'agR]/-]l)Fl^"_<5sit!P!'*T$8uA0X\O=XDdL:9O%,A\Rj<D8\&WMSF&ArhoNCE
+%nZ$11E9FK+C<]PhD.^\HSc-`B"ANlNfec%oR;b*okiFNUEAc2pAWLF"e(n)'ZB&+DbuW(,%sntIReY819ld\SZ2q:K.]]*r9,Y%d
+%.U^7-2DaeN<".?rHj/7>%*QRn<gRic+X@eh<]IK9KMWq:qZfp]L]mtDHXn&3"6'K'Y/XO#ZQKHQcL2OO\J@/<S(<%@MpS%h13q#R
+%L[9+W:kF#o6G[2LQ.bE.O\N-p?_J#PieLO0"hD48C:fpSCs0)Q3o#P8<inI?@&sC+\ba0o]C/ZkYdKWg7'l([K_,<09G.FB4;ir3
+%(+Ec8JIlEl3]`J/UVc2F1O5(O`u]'Mqut8-Pqqbd4$'U&m561BhgO,e@Ad<'_iIY>'B\^`&H-ea'$;>tK!'32!&n7DLq0_QT:s6i
+%a*KT#.LkWEp*QS)\nOSWYg</g$0+dW9HaV2r02%dm9r?HGO$%bnMUEk'FJ_-dk8<JO'M>ea`."d2fk:Sc*_Kn;>=7?HBui<',Fl!
+%PGdu>fJaI8O__=n9]+l:KjYXK?qbDU>VcC%6;YnZSJ<8G]5ggIGZ6W61?7%-Qad?Kfiu_4_C^$e-luls>sZ2!S6Aq)_Zu@V4P^jB
+%UhR\.QC]?JR^Gfb?JSd&X#6TZ%BcT7Vj`]N_!^teZ\`P:,0@DTgP*aU2LQWU1QiS!ju<1Wf5fsX$TV_V,)[4aPsoG)MhK\oU1Sln
+%V5C;:%s%_fpXct+o$fgP;gZ,N4l(CkF*LQTkY5W,eqr#%L0`(?l[HfNn9`gAVMhP/5"93Y3g"M-2s&n%$0.<^Um.kEAbQqL*t80Y
+%igc0Y0Q;G]eR%laZ.g:0X?A>F<3?*?hB+f#YS?"O1*P2>c"+9KlmhFDb11o\G!,HW*funls#tXN!?lPo^E7W0T`\J*r-^$+pp85*
+%_AnIdS+j]nd`2q^[6V,E.@)V=.tu*j;X$&NN[5KBF"(MINce+r1jB&:(?p1gVX^&XX&F(4M*N<n7JIC5EF"2WQo8;*J<RTqP.WP,
+%@#K\q"\EMg2"=Qpb>opPKMOg+1gQhFDAqjb2^MT_[QDl_pt"<tm,Y!4Q&g"KD0JsRZq,2'U4Obbb[%L/HakZ.^n-"^lh7#7dZ'rj
+%/gCe*iksBiWG&\5jN8WVk,Z)F,igi3?cSZd]8ta\G\Q.h*1"bfE2e2gbeujq<]=bh^IC0R:*uZ/hEGi</R5uq\YZaJj7LIIeO!Ch
+%12LOCB=#_(#_&-O=dEC(Q=-l<2U6L8^O>l8ojTX+FBn@!YAS#r]4@aJ)T$!;V8R$.+bQJRXat>rPFpBCV5Ag2E@Y1,1he(+(-d'$
+%!R9uV@A>2^TRE(+2f5IjA=5V.ln\9RVV"Aoahl79nnR,!i*o,'oO0*HrIPL)8)8cEpO;c#Dgq1PgAPrKL]-nLJ,^2lqqWCJGR9Q3
+%>Jk!SEgrUF*$/@7];Zs1hk%asF_!LsDblAjLA5KdnZmZEY<V(is69r\+k)[,1Y>bjl(ZH71jd-5V`T$f/nEmj"X_pJ0Fs^K;d":L
+%mNi+RPIS_3$_a`Bb8;Ht8E+^ua'9o/=K/e6\'0bk$:5B9,EIOYg`f\UX\\R]5JBVUIiPBKBuY147rcp&"N`*MN?*A8%d5c?`3@J=
+%cj7,ghjRgV;=g]rY_EC]!A.4Jfk$aaet$Y!ag2RI`O"nOi5'9F0B!7CiMuD<cShk:`\_:[8k)kY0D`@D)i+[`HBoGGZL,mp5]2MX
+%Ri=?_V$<eh5]aHE>mA-d-[!/@>sc--j;u5"Th$/21]6f/PsV#R4t;K2?,$bE5X4PDDV_mD6UE.Cm^S-,2=llt:nDI"L!1=IG"[ei
+%Ir5Ma]sAfsFa0t3%459DVNBaib\f8K_strYZNK`]3Q1"fDAHUXU3MYt_rOO4DYJRk0,M^m("!4GS/UX#5O8&"]+\aT3Ssi_0(+4N
+%Jk*n^2-lY@"Dl/ek',e?m#o[c<gIMPO6ViY`R:@5BRO6Mb1b\Ch3pEV]"HV^!NLlpG-<bRo@TU@@1`dQ>,uekKh:0TQ1i1HY?5Qr
+%F_&?Dm2k"iK/@kO;n/*[)tQL9A9U@kZ,03hq1P.%l,K0IJ(k^LJ6u+l!8pru4]29?VIpXGJoLM_Y6ZX3J3;Tn/GK&pi8=2H1CZ_.
+%+(n!,(g-Cak#rgn,')>=[^fC`f3tGs%5D)k9IhT*@YGd8/*[j4X'6*826d/45c@=q-V@XLmpJUKoWg*)oiu?'"'OoPVUu\j+.'Xm
+%^e3g<VAidh_Q^3ag;gc"=;JfOE2Qe?oiUe.;O)&%B62!Dn-p(UBSCGcB,-R1*K/`Md&NV5g#gJ(0R&k7ZK$hMOVdG/SU30N@r\D"
+%K8]:0PT`E=,E<JMO%%nTG8^&4Y-tWYj)<o67h_>q(<:=`nsT&[fNF9lN8i.nSgCc.*bN1a1?\k60Y;?/5Vc7faSI91P7%Y;*^]Y#
+%CpXbak1t$m224cZ(Cr+g63_F9*f;i<*FsgSg(D$^&qoaZrG]XFi^3/i&TX<)<LiU'J$.?QZ6alq".A,4Yt8G1p$C_]>YSm\0'g?X
+%<b]HFST%;W(b*b-%(]Q"B\%oe(6Kqt1l=H'BTWsa\JM6'3nGNLj_e]n80_`t'U8+3)M1<%<Wt<f]r!)3<sfEonQLV1VsGXAPbNJG
+%aW(<FlYKkAn("URAM1ZPEH<'!GW#E)d+`Y5:JtT+KN"*]ad\lL*1#$Wfu*%o!-qrsEHLOc3YlJ.RIu"K?PLt+89+<8R4sm(=Yh%X
+%-+pQ]\:0`p9N]P,$m_jDOa*0eIL+$uA&=!if1e5FefegRs/pdSm$)._Oq/`m-SP`f6J7<)CCFqe^MYhIQ&TTS9.GfMTJd1=:R$XK
+%5E%>A!pb5Z[)V*7-l$Rt)T[;3-BBDl.s&?&`1di:(9,=_cGA8H3t>2q)0AE(lWlJ?/ZOTEfBK4bZGtY^=.PMl.hY.<N#kS@hASY.
+%6hZ_qK@$h>99XjUi*;a;PS=uR^T=@`cDFM4/E:q$b^0Z$7O[sH23=[ugEQj@:ji=,A1#")mGMaSn,E#Fr5HGKiNN7Fb9-`JT7?gO
+%J,/Otrm),&T7(25['oOts7d]8cTh?N5Q1G>5Q9>CroIL7q=:^rs78JTiU?:&TE"[N4eDRY*rgRlX8Y_Xor;,1Z@&+E$@?@;Cl%X1
+%'%QB6Ys$pLqj;WaZ7R)oaA`<gHWGBH7;A4dI/-5/AI]"Kb.*P[?j8r03A\!:V@N?:8E^RKi(l3ss8HrtE-tcFgGU5Bn#u-`['HC;
+%g'tpqd[TP7((L(-cWi(kqn:)#U%iWFaAN,#p>^2?ZgNpDjEXnV,AUs+U&fNqZ=1TA1*QoN9\FiH,UY<Tpo,W6YSMZ?e81e<YA([Z
+%_eEVrA6RGW2'62,0fDk0kj3&()APV#84\OA2-KAu/j*0K*FbngWE$O`fn5f"pbE4ar^=)/9@t7Ufked6no?W,D/`YIi7A-d(+t7@
+%?:3@fd^cXL9^iFl"eWh50pbZ=V04,b5$k+,^edVTqn(UHFQo6k!dnLV!GXk*X03+[cDi<i,SK)?liEO;3P_`V"g%uKC52%!D'Y1n
+%7C(PmTg8r-j:$H6"'e:W[V9>0Z#W^nZdN0qn.V]3rZ+qgaXEOJ^:#?R[rh\PnJ]:^m9Zg<.UEC=hN\i'#%=0a+ZeN^Hu]9gHe$&\
+%s.[W+3NEDVEfAK;$_cI7+lpauAO&=*0F/n;90I0%:!X_=#X[N-5?p^..TN9e1TJ1LEFBPf]ci;Gl)VFVbuTS5NS]#Qc:#BUd;Tft
+%^Af$lM.I::7\f83Wg+M.1j,R/dIA3^qeECHk.<1IAmQ0T?IW&61(B<,dR&g>',]hCG;1'E-FCi%KI"huTge:G`8'<:Bm1N>DqpE2
+%2`%duroSfq<ZMEceO%Z*3UFgYQ1aQKKG9rBr*jFIk/eDM2=OM`?)oak7?Hid([Z$sqe=N?Z/+T!KTd;5jpJtE".W5>pE3_k[79q\
+%poH-+;U'<dh:V.3V<G5\IeimJ'e#LGMo(A).%.G'>4W<b1lGrsO2'(d[i?(2AlJJ_[8\,1,\TX_G$Vrb4"$!un4RqAcdetl^8M)'
+%4]nq+/B96*YoW0^SHJpk)i@U[JFAN[51,lE$p.(7UJi#fTN9>Rf;CRb4_hl/E0BmIqpDjN`Ti4hJqY@)M^./dI]oOIF?n\%J4\!j
+%Fpu3BPOKriiC/W`D0M#*,D<Gk%RooLa7>o.+"^8%DY]e-4gN&pc=@*880S)oGW,Bs(Fk>0:Mq<0>4Vr;2g1N.K?Hc$_@01@$6M1S
+%Hm^J+rsPHi3sFp*5b"X%lE(t*mC2SCY/G&!&.A6b'G3)n0T_p-]?(oa)2Od<M6"1&9NFlA<i[/)%lUh`G.k/l>M:[5gjj,U=_q@K
+%5@!0Rb.9]D._qDhO>*q7JLhWTbu;UR.9oc27(Km9KjK.*bt<LOX0#E(pb&V#@8g4_AVR>9VE_*81T"P5#o=.$[TqTl;ln!OYG/*#
+%UDWmY-fHU^]b;,.bCR9a67;t81eCdqg8>9$:8IX8Y),^^$?]jko!\*XQ>jkHjr&24GSpe6IP8_rf:It;[1k7b)BsDg27K/iYa9;m
+%>d6:s0;R!jOI)Un_W0![?t*@RjPUurSQe*7.OjU?E*U`-5agMm>Bq*b#WcUcff`n211jV.n@U\&"M]10D_2LQDK>uQ"?C5iVa)@E
+%0Q#!Qb=l3&c#0Ib',nfE_IZO`5T,=4:f^g\g!q?@@`h^u>0B6DK*/dAo5!;<l5ZkSA&oltp:CLBE6F(T@%.@L-gfl`*G3FoXt-E+
+%&M;?sDqBVR$+s?8Ik!$u7u7g2?$C\jnW1Hb@Jm+aaa]JDbMmMbX7J?3o^,5-q:rsZ@D8DkbKd;@<Ms/$0!jHF%:SW>1t1n6B1]fq
+%'/J?Y6(_R<753^LnCh@1;!am3C6;p2PP^/<!QTl(9ofb!\?lHDi7*\Tm[C@1lP%B[k(,6n%LHcY.02q;4Vl%BoJ_VlXd07-SKY/j
+%6.PE&A*R79c"'A;R6cpPHG1:AR2Rd[BkrWMkr?"m"3Ca*NRfE,r<l:+&`t<2YXW7Qn(4WeL0$?!kdY=-:^@5`6$tV<UW)31A]OGY
+%s5K0\d\]7P8<UiCEW_@nCoCC:4rTfK.+1Zk=n7F5bl[M*(RX\<88OV9>f=Jd.FS$Y^r1#2+"u-kGf"ETG\)ZTpZu5Df!E],/eDt*
+%fBQ<!-lJ<ZN]#g'4E[;QLcXoI%Dpf,e7dO?aJQU5[O'-ob2eJ;%#6<8O3fR68C7Ht:,=p=Dfj*h928%l$8mQXS0"1GWN>:'11eph
+%Frg5KRE3*S`9VH)M/;^ibV#&T4lGaF^(P_uS`")]_u],j_bOpDr\^BghW2`IR!0'W.66PG+\tbq:#]KG7fqd."%19(mBfK/+`!4.
+%Ycb=Pe*7EqD[nd=f9RQYoZGi@qEi7mN2X-4S4L(D)]E`S\IChn%U[O"+GnN:X8B!pQU1Q7iY.=?B(C$/7FJDL:qs[c5CW<@oa"p&
+%d/\/4QE:e\^.Ra*R2)>QiJ$WEG#i0si0M+l^ZLKB*LUJ2;d9A9QNNG-A-6CYkGo,pD/[9@UtmeMQac:[Nq6e),FQgraLuo?4IH\j
+%_=+XR[^8U)CK_ho2q\j_\*Z,4Vq2"@,:!nne/8Gi?@Z1:Gp=S@;HC;f.g*[kem.M9E8/8%-@G`\6`bB.Gs=N`39's$qo[Qt^IgOZ
+%&Y+X3kU(E<es%C_:F=EJ/:kOm&YG]8BI;\Y4Hs7c5NmX$.,]'EYXab*e7-H=@Wl&";fbD4Uc[*ln>GPH&C5*$*7Y_/?J>&g10u?t
+%A_WfiJ"h2@MRpC'8NRKL.\RbMp.iPC:?#loH9lHmY2^/,Yj;mRq%cH3_Mj=5cr[iS#C8VOV[q5]YN!TL^-6eHBSZL9Y0A(gG!i](
+%1L[H@e';`Q<'`7JN5VT*+g_eh5&SJd*H8<8@H5B9#qo`LrL0%$@$_[SkrbXm$X9hZCbqsM\D!LN#e2bP7^h[Gs&fg+-$oBLMc)sl
+%hrQX+WKV-Tjca:j8WE)Pl6k!+N)7I_R_(:d>aMo7fDK0iL&q[X.k3Sl,Wd>G*On1#A?8+@k^i;odq)#[jln[UK(MSlh$<OuAY;(D
+%Jainf"*?Odecl#$5<f2pA#t>GY0K3_EHAYC_sl6q;1+NEc":N#fhK36f8h#^qt[m$:oqg4k3ot/'>CNt@PD5kAU=g>r<1Hk*h>+h
+%':V8Vo[UoB]5j4lqB;@a6$AWN+"<h#C%o>6Ud0&u(*rt%\f_"?qgP(GT.G>\^O@_`Gf[gX7`)EmNpCDU)JTNRJPpT?<Y5>EJ"<X/
+%A6bkOgdi`5NQsfa+C$EB++3p5bpHtC3%Ikh"N;1?jdjY*CQBX=4dQeTlEhDN#J*D'8tPU<j2lZs6!!`-']#s32kJ<lJSq=*>rg4<
+%gn0XsC>l1'U>-dJ]L[XV=1(%O-r9P#ELL^),1#6D0LYAS"1fr!Z]iPZb<o&(,4?\0g+_)k2<(%)=rsF2T\3$Wd:or08Pe&&i`n%l
+%KBY`eJ,rkb*nYWeYP&'#@<=(\fqoUOlL42]1i0-A&_eq7.J1F&fI,X1]4e!4N.421Nr(:?2+0ou+p?.W[h>.kSo7]JWm3_iFg^ei
+%fW6r4_jjiZ@HupZ=0bo@Z@$manTK>l8JZ5#+L;kNRAUURVaen(qQUoR,[L$Vks[XJ^&KfO5-JEq0N--^/&56kaF*5$oal>Fd$aE;
+%R@`XXX1d_U+<#Q3M9*94iX:tOLJ4i<cT9-pkp:&&",,bpgNu%/(j1\5<Ze@JIBjE?ZMd1BBYk`UWcSKbPic?Aq$>3^[R<($*@4MB
+%eeq+Y,$2G#iO'Lc6,rsdRD+/@DN9UZ!&k.4pX=YqH.cF)TBOZTodOZlNn=onC0l--r&8HFU/rZ$k;$I'cnK0fMauSdb*N+t4RJ_6
+%6VgsS/C15!e?OaTjBLl2@PN'`YQEhAjLJjSId-3>_dNV#-'<uWHa(<P85YkX+Q41F@MG4nghFqs_@GY[h2g#=\H-M;3YgGTK'B1%
+%8G0ID[49*PQ"-@LX<eOaXL/fcEE7GojSXHP(k.c(&pMGi_P?TolESXqemZ\-8>o4B6t\(!haLJtA?J^k'8b[AS+i?CHrbRARHjb'
+%Cla\\=Z/Yj"Wg%Y7neX,\VBhK:l?`i)!1+>O^WDLHYa,-iX9OJRkO5S.q;*+DmC?]O(J1@O=VI76;Ntk+9(kq\Xpab3JNj/#7rTS
+%abd"\1AL79G^`\b7^hT1rUIenqff#)RlLdOW6<FKGHoE^,JgZ)6^M:Q?GQg[k&0#q)HDo$MOd]J4?.4i4bh%3@SMJoSF,Qifbkb=
+%&2q#^G07P`?bYG8L@1U=p'q"8F*b\aT`Ate*a=rn[=l!a.,6upmjq=mc-RW`F2k!C.X?tYN7`3dgk%X.4"<Pm<FY\f:34+`q:!K6
+%RLql@Y_H)OPoi5,p0<V@UF7(Y/oJ]UN72jYD3bPpeklfm?PXT2%c]T;NID)kj?ENbDZ2^m6<_52J5A@`3E_D77ll[a1?>(D)U,gL
+%KPC%[0[hN?Df7NuTTea]45T&[b+aU@;.pFdk^i#86f^7d0,"V.Y+Xe,$93K-%s^4R<iuga2:*q9.mWi0[pO_H^#"D%"EH'j4>]=d
+%)@g3H1TFURA=`XmW7kjqk];r?DPj&=4#l$(@;'-^($,KZ/'f%cV`O<?!_0U[GsS#\auB+.RW*A,8KZ6i+k.!^'G9TW@%-9N&8fiR
+%gm"on-.hZ#9Z&)4WHSYO#fIOX5uWb%0_p^D.7MRu:fsN8H$;7!lWFJC/]r^BTpsF'=KI,f=aTVGhHT4(V%((Ro=7Lj3V?'ClE9r+
+%3mUtJ$\W(@nL:$pG72sueA+L]FrGVi!RugDCHi\Pf(;U5JkPI2`"+q22_n-cWRZZ9O\O!/0O[l^TuFp'BEZc(Kl(W_^iF#^H*\0#
+%iUU0KWH/oUjW_*bBA<=l//&rd5CQ*N7VMgt^53E5[/+4,8Fd,)Ubj9$p)qX(7u4-LY7J8Z(DOKZQr&0J/9^.85,o8Io\GP$4,2W7
+%K^h<s1'MVSaoNc)cFd:p3sV`tIGuGV_l1#R?nQGo$@"%m%%bi!S.:aI.Fi9@VqB4kJJpJ,Ca<HJq,p^`l1V_]oA+SR?Sprfa`=V3
+%"$;7l4TI;Mgfm$NLkI45?tMW^A2<Ho50b[4b#kn/#VGr6[0NEQL2gLSJ$,RHb-=0h?NQU7'+6f5MJ7m%+d$6LS(ie=;p&8-1&,V/
+%2%.\Kc"0+]jj1@OI+KD=P0dJ?*DJJZR9oja+LL8pa<ihf*?R=pQjP5+*0.S#(-gh/#l:l<3BAKn`ccqmbuVNUe)L`=!,"OB+d[k@
+%ilK:&JnS,(Ae[#Hlhcn7mooS8)r`otggVp?X'uY$V.7(`P&h(X<=tB=\%V6k#cCI/V>8T3=[0=s0j(WZprF0>!SnQqYs"G-[l-7D
+%[oJ6gI`W=YADJ@Mb$e=<b8UC0]np@Z;'WQ[qM@]2SXP9O<s$_#i=V2MpaWP]e[\e]]/PTDaSe[6%:5L0b?B;dF0dtiQkE=-&%C';
+%<u36F9p]b@K&$>Hg+Fn0YW.VGNL^5mTL-:99J#Za=hi_)mt'i`hE@<kDU3/i??0*AC53&)j-nk2S@7J8P?>&L13qc[^G+oN5U_4p
+%Y"h`%p(B_)YZdTf-IGn)&W6#/r0('I7%!qe?+gf'DNZ5OaCbD$`Oap)f]S`^ARh%Y^T<]!ok`%(KhrZ?`NIa`5CT00nta''A4*+]
+%5([U[E)AQiOSLRl4Z.m)&EL_'XP^MH#_Te7`QAC>2laODpDl4lios4mEWNqd3,]W-)#G4cPB<`qR$KrsJm'9g&QlXL&qt9>DkN'g
+%>Eeeia#'*1RO?$_DciT<>o_*GWBO.$k?OY>F:\pX_*&d#BHVWf\QBF6qSrfYl2&+!5+'642k(s`P*R'*EffCHA-1WQiI!m#,b@<=
+%T5D]"rjZ6H6>DYI%Te_sjhP=Kka\M$G^"96df%[K:(+6t-6K\n3<juOio5C,#N*4Xfo@9`[Gi%'Pc/n34KIZAclZ^hj[f%^pq`jT
+%?XE1?4h4W5A.*@WI$N?:q%?>fF*41bGm^EQ#sWb=ij3;6\p=2JFdeD>E"k6t4t@^%(X$c/"he=.(D7@FMVD\Cin;Ho19'2J=M.D'
+%93D4Ln+Wgm,:J$m^\Fj&PLhm8k^L3"J<!I0_f(">;@Q-+emXZFG&sTK31])nN7f:q^h8[F>ko^krVS.M*0RhtlB=jNp<amGdm@Ag
+%^TL?[oOKkP?\.%n_"p:M^%+3IhY5rMmA4C_R[4](NI,upk8$4601*o?+kX4hD7jZ0GIA_.KWW6W?LF2A^<NMgjVbCr-G.,r(C08N
+%P91l5OgD>U9pO)7rO2!5T@JI)+s2N\#)7elFmQIG00T(M>MpVR4'Xe["]Bl(3@^YM)lL5hfTdua"kA=V$_4c^+dKcYbJD6$#ZV]$
+%Pk5/"oi=E.&O8CRRrqNP,Wh8P,3>HshOQ-P![l$LW^[+n"6<(qa4HP-FR9Ms8-.>Ij^1j&^b=gQoq4=HB>g4*QZF.0Cd\QW>>aNf
+%]E`<[-7cag%;_0#Ai$T+Ak$c&,gULF\3A\3N>+$Fm;$Tu3_qD@4F4f)U:k:K:0=YC'BjuelqeNnn]r2.MR9ZYFDO$qEOQ#foq"XW
+%.HGM+ABp2B?f?=UGNkK^neEl-6u^be(%3;9%U?Q'*u"),I=58kB0/*A.H62Z`-,6KlW&R.3Cd&$:MV_:Xn)l'mXrg>OUsoKc8.a>
+%YIdJ^W%LCD-oVl+&S>MC;S/oImd6V>2qiDbF+<TSG0c<+FC46T(&StZ"'8+]-Ya;-Y/`Df_E-N]TA+L%):36g"=]CA1(l+dE1_Y:
+%^/4#0jYC'09MP7=6l^J?22dekO77&ZW<;"`XElHT/TH.9)WDL_l1SRI:"e+<NkJ?W<0-.I)X(TS2apXg'L0d$jnZUqpRo'<i3FJD
+%ER]e(i'E-iI.YPLIXXF!35M?Uj*.\N6Sgec13$BU'81W-1$^HsSqG.#>>4Br4^4ccZ;05Bo4TcHqj2MP-Yf/(bKd2m+,cnCNr\7a
+%l=*@6MCe+"0@8_J?ll%kAbr'&\)!Q&/6O`Y)fJcH^fZ)VDUHS:P7>JY&M-p&"t@?XG]l'/V?cqDkR+hnEsB>D^pSK[G"aG.A`nXi
+%:4='VS.%h2Tt$'?#Kn\Sj^j#6fc%IQE2p;diQIOp$hnam&L_3&^\B:`0e?/&N;%MD.Rn5A#R*j@Q=fsG)lR(d_niWp^t-i9jEV&Q
+%G%$V'H/C?#&ZB#4ZN<9_2lh^9%!0_^!JrR$#*N?!$Z"6ZMLZ3E7EI#"k*>mU<'^QRo6G8I<:<"+dt:tdA]%e)HP!<:+)SsP^5\e.
+%m<450&%l2u*4J4Q(eKe@5au'p$hWkb.b4;CWptoXF#r(aY:n(KID1r^:*4AGDYITsLBOrY4aufUV>Ofu"PS_?"Po6Mhn7M+LXg]Q
+%kokL7[h=be@`A<"aW!PuRZIiq1JTP8VH2o5EVqgQm'%r;r-eZpNg9:C2I^5$-m=S;>.9Ik]sd;=@8th"*ZKVdH,r,VilfVnE'B34
+%l(c434Y'BF&XaQB9?Y;ll@^AnB$[GqQq]+!LaTfM3a=F=dl)jBU(o%cB*6UeIHeSi(`5TogGaK!J>81'Bl4S6f#B7rjhWu:^enJa
+%*=)P$fY\RqNo,+K.QIK6o;&JK.oG=l"Q":q'Wq#/TPc0/Y:e\G=WJE<16QCI#;d-K/EL>g#QoJWEV4WgDL&JMj`KGkZE_tdfRqt^
+%Op">q4$4$t\(j^KrY*Sgp8^H6?QbYW$1i*A+U7%m^!N5>B`,<Y&k!8VcJmR&h&efJr9l]93<n<!P[U.$+*<2p^_a#hVM_r>?HUD>
+%HY\X,s0s1I(!Lp1\@D@@nm7si_.7<kd.oBZXuG8KmU7#-0+7Jr?bYtn_7pG)+5R-K(LKPra2cPh5iHm<<:S32G1YLa4p#QudcurX
+%Fl58Rc\bGG@e&mRY]tppbS/;lP^GJ>hE`IVOR`u\Qcjjqga[:9kB2BtSu=#P_HNDh4M(^l0V>/F[_9JD+%NYBK=&QMLf?0U^P2pT
+%]n*nl(>3t6Te!kDC,H:ip\?Kr[YLkm_]KnsNa[u250m"B<s^((I]"85g%cb*PiY8!fl@)0a,i6halcIsihpg$3m]o0+>i_,EP#?S
+%)?fN@F&on_M6V7ha6&**4Z.*Zf@,BGE5[3t-i&1Z?0e.cGF%8c=M?PFU*ZT[5=3\S!U/&_lW2MeF-]P5lQk.XpN+Ot',S3=1]1P=
+%?k-h&N994MRB4K.%PY&!6;O3qZ6h3:eZcC%Im.H]Pht$Rn?PGtDaji#Kh4H<LLGIrT,G#?#F/!c+]),_q9aS!"g%3Yr;bWE!!ICE
+%cr[XgaE"1&Ie6iXCS9q7<NGVR.S7Tpa:t=`<d)+]L>)aukEH%tb\b=_Kn5T8k4$3&b:0,,J15b!LXfOcI#ScH$KYS[^;b+ZYB^SF
+%H9$7K7'K]$hVo:&P#Xqd@`ZXTn?.BaD:]TJ_[#SZbXthIK<TU76XOi`mH^FW"B@_HXN2ELh;OAD5@7HL/>[ImrK&'US1-N'/&F@B
+%p1ZNr-JVHL[VRV"F"G@e(AEr>LBM`FBo2DHSkK,m<(*jG0gI_S4sO]n[6"J*35`G>L1kr$Qri"cajQfIN:97FS5S)/O+gC;R5)S;
+%_Pk4qkc<<oZt:<7ArnVj1FM(+Eb^eGB1?30]m6@HIB;\d33&KY"4X+!=7%ErPWii%q/r`XVq<2+?pFr54ZEZhW8k1QY!ft:8aIIe
+%iMGAp3gQ)1A&r'A##()p4_R)rr7El70^Ncb$abL,$npF[E^)ij\6Z5Em4@7'nHGA%qU]VU/,dV5fR^I640gIHCr"5a3f8O]UL*))
+%03<;WNH.\AF0353<P5ZL3:9?:Tb6Mo1[(7&ObP#LhH[^F-<KP*22kk/#2OtS65s"M%pVlMIk[StY6H\uEP6-iOY_7Fm:BkCW$K$W
+%qC+H?h>qOko(s1G)r?,:AWQ<gK8HQe87#/rh4rE]Yk-@ncO0E\m8T]oH!V6^>*98YYE>];;a7NhT[s@;!T)MTY%Uluo<l@;X"`;4
+%'WfV)cEG\["dW"nD#.5%6(KJ2[mG65ouY/,:No]p;s'+".:t7@rLPlblMhJhGoD*i=0HZIe#V!KW5*a"9,+#_2ErF?*YjHMOBn_M
+%DQGkd^\7!]0[;*\T(9G9QnmX2T9ke]?U^D+2jl5+MpFGo?lH#;$!6["=BQ9:+?75Cn2^s*_(rrf^afR^?8h*c-NMo+>($J(^"hkO
+%OjK*MV'JBbcaAb$lqLq8Xnm,WNPa)?QgcrT)+OATMd\`,LEX:l-/Qb9*&3.?*<S'E%NSo"rim06a/[?FnQa&=S/Rc4.h&1$GZ/V*
+%;_:"6.8bH>p,\X!;#OhCs*+;*X?:*;h]NZ0KMblY&SR$_Qg-fcpq9oAQ)p(3jR$9->\f<@pZX@CZ`gKgB6#)kj[2u140XKcC@0TG
+%#$U:XUnIk"c.jbJ\/D]:#o8GQTiKmlNNQhI]IXMW^<)\)B(_NU)HirngL98I&Mn3#moIM.lmM1uQpXQG!ntmmFaMV(0_Oc?B2]uS
+%4PkN@/`rlC>FlXb0d*+%4XrNH!>%r+aEQ+<:DQ.gTXJ7Zj'a#Lnk'j$!>O];MshaZYQMj%^!K@&6E:.4YYlhuaO\SG*<eTJmAT"`
+%0pT/:jiL8BC=/TCd(heVHrf05L6AId/?N:k;A6R(lI"Zd4@[e1bn_s+Hr]Y=.?2rVYlm93)Ul6IlLNAt*dDN&n[;@d5h$_I"-c7,
+%%QIAM$tiuX=AX3VG48rD(E,FSp3Tl0:69(!<Eer2Ddd8F\0=po<P1o9V2)(d]iJ98oOuDC2PJa=BkC+b]5u$`(7GmigV2p8Iqq(k
+%Mu)\'hl3)Rnh^K$:M@rJ!;PE^N1>+)(5Ea%q`5A2Hlpg@jRFS`\j4m%.\3/5j7D@9;pR:^cV6a";40j`XV1@R@6(Idc)jH,Lja?>
+%3V7HtX!50-V/AIW<b'Al>T5F@Me2)H#]*"]"CMoQkWCAN*+VO`aciu]E\PHucDTS/82l_sl[4JnopRe+IfmpZX?fZaO7cU+'AaWR
+%mQa.$LPL1A[9K3,ls]Kf'/tQ:(IYl/eTtf%Om"\ob`i/09%rOH/p&#A>NHmJT"un??e[J/"VTUD!d!Dt*h]`T?DN`?@gsQuYXn-&
+%A35L2.foN4X-V[2Wku8Q,r6(uA]:i^WB#"A;k2DK:,"qV*5K957@La[W*8FDE&HO1DNclT)'c$jcZUsYmsKSoN[EqEnU1eZp?d+n
+%<J-3<#LFLN\0jA]?U!/3qk@XQ4\-B4&0#5&G?P*(*NmSR[AK)UfoqPo"EAQHQ9t?t.H%RW%T,K^JF(-n'&%!fJLL]<*?.(%9K([,
+%o;C]&Xk_JF2GeB5Zi/U7/@4afoW6OM@'uPt276i4gQADd4H"k8Z0AD/%l;#e?6q*J[Wg6f7>^*`/e!o(&]MoV#FEX@i'8Y%^YYZ/
+%PBc=-rL0Tj`MIa#W*3*-s4lpo$`<G@E=Xrp*qc_.WFD.64rKbZ:bnp%S.0!s(.KSGJIj/T25XQSdr+qHR1F9F:<t=RS(h?skV36a
+%Q*O*4=D]*XJDX:ke\)Dh@<oEC>OnOD"kKrE;4D-tGS_1YFqoi<WhY!KoCZrr$D_W/b&[',[6nrOFZUW"c7@!a\p8^Fk6U+a-![4"
+%DQkT5$+DtQg(G\>T&'?V&"N9(<d%]&l(dJ-?;BY7](.8hhGNgPH>,Cj)"n/3EQ"iS-dA,-10?PKV!Y*bmalXih,?e'img.+LLhN#
+%kXJB4l#S)n9.[(($!f^20KJDCbUtRd;4o]?aPpX&S0OZmd)i"C?=_Br^75qpb-g*mf0QE(*;K#T!fe*n#4MK.&<c')Ze_iJZK/%l
+%Qb%Fm6dOAgQDj>03e-g5%m#\b%\GjmjT51J.SB]3b0T,5D3]Y<VKO]lXo?b(V^>ACm'dl3N*Y;kHp907^6aW<HbO.fqo"H+IAThc
+%!Rt0f.cN?]at[<E/TO&QpSu5a6<'OaSDl@tB3h=23`c-*J01c40G-K&2)t(L\MQAe91nVk7$q"p-ku)/baVmlU3=o'9bd-=@^Y5j
+%nWTg9WK[FG]-i.aX+\bZjkd=aZ)p35UkK^,KMU/iS9Akd-(S>+NaBD5>rcogDj9I$=*!Sd16'i;09cee=Css(96XM$\0A6@7l%?@
+%F@^^5GD2J"^bH^LL&]qk*/O8M;/J8OOp*:O04sItA;R&nd&gV50^.n]k@6mC\_ADsQWaR,nWghKNqM<5nXr4+gtX7Q3Eq4cBAXp8
+%aU>/$N$qb7"O99[A&BS`2n@L3g+pc,d$qt&,Kkh[E#n6\rY,r&-pH%iVC3cK:GIB:a?/#0<n?lACZ?>$fn*eUD2X'gh]%sA,=T2k
+%p.B!s[5r"d94ml1AS%F*YSY7i@Qjk?Wkc/.;@m>GLuJ,204VHXZK/p5QE-%AZLT!iVFEqJ[d[GU]Hr[kcY&e#Wp=,r!gjSfVg80F
+%S%H>_'FRHhWC`\q=-[WQmqPQm?I@nYK;fC7<EC?;)3jR5FLTc<H)5=NVl%AGpC,5J6clI*V5bLi<b\8!'`=Jf(LSYB3uPrD<1jUk
+%<.Y_NZ#<+D0&JMbV@^<Rd?pfFUskd!(JMPaS-oJeefYWW;B4NIoi,pr]]6>p#"=5KXrN'UgRW3k2W,l'VA)M3.u"PbPP5rQg7De]
+%PN*5k#_dA-&aDe_\E\2f]+')h?M8K[oa=paZnJAWANZ`>oChj"_:4T)iaUG4*)"pM91N9ZC#3VS?>q-slhA+SS7EX?OFj(4WY4/j
+%f,)ecZj%L)b4/Nd$Q=iIlHuQjpU0)KpIghsG!HhoQjSf,nImab;q\;=o%lYP><g;C_96HS>-F[6jF<un=mj?r]"QlW;Y=r@YMrQA
+%UWCZ:k^69b()oVpIH92TG1Uhf>ZXng6ZO<]?e?M1$S+.HCm/l^;OpjK#3#nZ_'7e\oQ17Da,[cGMW2BU-1P[<+S[6>?b,)Gf&hE#
+%VXLH^!h!SQh<\(8JR^iQ+mMsgK8L)T/O)K1.Pf6"o).Jb<.XLpJ">PBCnKP9@3`G\a1ae>+_;`>s4h%=j4)o?G(k4*ph]-\e`73K
+%?m=F?aW)^mY52]@2n'D_USb*kNLf-&6if3qgH8dILnhECM!B<"H,d2^4$dPuU(@O[Rh_ii%^@JR"U[EaJP[?n[qA4'GlKb1#O1_M
+%\)9\N;=FS&mK\3%ieaE8^b5rM6jqA[nHFlKZ?bT0o?6!(W\&(uLsGNP<+=IFLTl/NG/sPb.$]@N:#%:PM0@As\WR\UUJRJcGkP+W
+%hSE-0M@`%#Y&&NrOso91`X4Xd)7^j,YMIKB1O,hjCY2Js3QUoY5%;AIB$4:*lBs)b/7!(Tj$5HLTbTl7gaOTFg.re<:e@0Lf\6=O
+%Y=X!*muaddh1tN3pbg2FS1)*PG8N-Qn$#lB<a@'YBL)EA^2%+acNQYN-;6aM4iaQ,hLJO-UbIqNI5-R%5VfJ!!"MrW32j*(\Bo$d
+%MGf[&Y7Uq4()2YVF]m8jb!:?O+E4T2VX3R+2=O5:SeuJ10T8C\J)+A$*p8V82W.W<h[m>:HtYMq^<<CCjhl.%7_;uMP`IOq;'mA%
+%[VkVX`2S7C\l&FlUg^ic;5\3`.e4Zb%5T$0(EQV*MV)Jd9\='Fic'?*p.a]0!9oGYS6aGJ[p%[$HhhjOW[rpgO-X?8P*,95GR0g/
+%NoGLQGtP2"3NsCEe!GJ\&ZblZ.6O&`!cN-1IYspDYHbmaE_D^<U+u:MY]$SVB@!SWGi(80\8;q_6E;^6/L2f@N>*\3c>C!Of;[$T
+%G2ZQJ(J"5Jci#TdboIX*jO+QI;gH/mr6V(;!+p;!OSQoIJC+/5bd2u?DD"JL)K@ZfVC-Z.K..LKYAl:!(DsY`L!2O9b5l'XJN[64
+%MW48Sl'*b`o3T=uQnCdKB11W1Pf(;o]dZmO3^kn5HS\^,QT`pS[7Q,e`SC@<'/L[r_aW;@gV*Aq?l)mPf?b5(*j;m%j[6<MXBTTS
+%a6hW<cTmFGh'q9mrk1f785__qPPUhATqaP@A0F%3=k6:V\4rF9FfC)!^!?L(mtFrBJu,B_W\Z1XfflHqBQa"<DIASHkOuW"'![Is
+%+'>6\6=Jp:3ej?epjK8a[ah=\8g5qVYi"Ta0sP`=fm0K@R<#`T)4'\:?B&jFDC4C#@$P5].k8W>k2d((;2*[1Du4F<;#WadD7nD/
+%dH0El1b2>[=DfA9TTWa-r:`rSRKT;P1Q:l=1&[1.CF%a[(*cPG5uNu#b6u1C!gW&[Y^S?(caBF<*5R$Pc=rqRC7I4ZMUO&"W4r_E
+%eh"=r]i_:ICQs_k^Q40f*HDRii\1V.e)WZ[;66k`2BlG2^1/.6IhVdoV\jLF\ViJ!FRP>J;(SrK28>Y@";Tg(hti&%6nWG.$<*8C
+%[N>;s([VXL@=pXq)h^O]>r2#2B$GIr@n]MAOnTcY1C"ct2*F'Pal&4=E3KXjKh0Yt09GAp69#t\P3P)RkTr;O_TT"R@]?EQU=(L5
+%eone1S=:A6,6ES%]sHK_2Ie@$71`&#B"uYh1FHC9Ln7W;%EjVF#p&'Dn7]K7*8!p#DKJKYQG\94YK@pDlEC_F"B8q4rQ>("(ZhZI
+%9?bMNE&)UOPC&^chC_,-GFnLD!7Pc%)96=YCJ5AU:64BJ[n^<O#lh3]:'5@CXr1*@X;@!O)aV8]637C^"Ud[N_*+%N[1&RlO)9pY
+%X"JKX:KB.:rRJ,b"_D<^o5kTRD0+-VY1P`1eC&d#a8<b7jV:%TXKoeUPLiu%r"sOapd4OD_m0?6=O;]g.=aHBM<a^[j7mJ346,T!
+%Yg4\[(nQp;l""TaX8M^^=oQ/&Me]Cg=)&2pn_Co'T]JmD)t?DM&gm8Ae2rJ"S'g-JE96[H2]hX14pWM;8BsjA[W"q8ICLAP@'\J[
+%6#a4*TpfZlRe*[nhn3P'NJ:7CD>b"%hKIM6,s)T`JprLP7f[858!Vu"eh=>r+#_i7+bMTX_%;DL.FEc(!ldS5H@,+g,%>,ShH>%*
+%CEs;mF75PY\Z<$A1=o#aXIJ6k/bT.EP5nPs5%JO-KI'FF03,tiPsP:)ZCpX]4M.qooStFGh.I>6=48^dWh3`j.[V.u>?A1FZ,pQd
+%7%cW2Q_qFOmLEqTQfRdFW$U^d#V0qhY:8%>$9,dMW*JAF`c3Y.Y<i(`9A\jF(q#!Bb>6@5p)P.)UXr=D=1*u%S[tN](@u&GE,@g8
+%-bh)`/>]Bp>tS18LggQ;M+45bMR%I'(c*sc7GRX.egh_eC')u+6F,>YiX/bi;#*g"!B7'MpB#mY`j,0pW[\h5(C21K5cut"k"I7P
+%VtkI3e^'jYh;(i/TPW<;p5iRZdaIlF8<Iu)FCRSlqk>I>_X9>I-A"cuAtm;J4JQUA&F"0$a6aG@`oA[;s%G\QBt*/#>W[MApRG/&
+%[hk>t'[aiSC2::a%E9"6Sg&`?U.+.*1r(Xs1K0/Hnn'M%2DCHdb6.ZMnf^Bt[j7.'=c7Hp'Wh8!<L57f(UCT/1T7TfNBM'M-WE%1
+%[G=m7Br,mi^5i!$'F<8-<Tb>_dl&_C:i@X`d$f7D;fmUUn$^;1'Y2J#@"aJNgU]!f%W$#$->*liDgC9KKkeW*#AEkCI?EerD%QqV
+%6-6p?FN'!5Z_iFLHD,a"^Oo0ETZti4I5CGU/l76ZXr>)^+];Z_La-3H(W+8%BD-/TmW#H/,4WpBBZP,r.+GCMncSgUd[ul&1kd^k
+%?kiD(g';D)V?Ml6m/_b;N80Z+#aJGYpk-+R`m$^eM]HA(9kAY04adTIAHacjKei1j]pr8D4.X8@0lE$&Q+OD)'?)e)`C"C<?6m5Z
+%rC2@I?:5pkli6Xhiu691iZp/#98DC#U..[J[s").8S\YfSE+bor-aH_%_EZV:!D#\`3:JLrDIGFhA&ihUqkrfhH9B_0$)tF9&'G;
+%5jVG3.kg^DXDsV<9K;/YX&j'KF@@B)VSEgQ;6Z:;;BnH=63kGf!ArQUFmAB7PX5KLHj?(nb(/criL4aJ0_6.+_$55!%48r,^(h5C
+%"g5VT6?5um4%3)."B6q2U,&X9GYnh#D#-jo9Jnj`3XuAU"^@Ein2\V9egpC$CnmMIAOS];aV&s6e4%W_?R`pt"95k=7qG*kOGnkB
+%GF@&8?]?+=IJkVe]ul6201FL!QSJM&K4Wl0\aXO[;KE(sEq*AX9:.Z(oNRM6gBDg1D]hk[*ZaM.7#Sgsod`\K'X%mE;Aun46T[7V
+%1UoXc!'9"Oerb*K*%5l$3luX5QALP-[r=S\M@i6U45Y!mqtmJ!rh`dZ,0`^3VbM#EloPP'1U8DFZKs:5jJ1(]AHjiAbTI<JDNu.U
+%BZmp;Z<:abQI4I.3p#U"7P>BpSRiJ(Jj>;V.pe:@F_.E@A9Stbi/)Om1FB*gkFsrl#)G99LPR_9@-pRKLpC)g!^n*t5ac@lFk^JD
+%_B[Gu0WHc--)YpiQ*Nhafk)6onO!p%Kp\rI@IDOKh97[>?4E8"SRqm'1OR>!LQo/IOCa_>;:)rW01$9o3L[B@M-7<W_QZX4V5i"!
+%'-F_J>3',[\[tal/X2M:.+SVN3$Jbc9*p&P!]Ni'^EMcH%E=$cd#,N2$[/N7'm=G^s4<Nf.podN@UW&23kU]%1:]u%d3M\U')AbY
+%I]6l-'jtXaY&#Q3'Ri]cJqeG7%0?W:i@nW%3\OR=*)kcJo*Q78]&bd?jrTtA6X6+m^`E!.ndJ.QF_b6RGM?e?7Q<XJ)TU__XqWHE
+%h(nnRhL*krL51'0FIk!Yf=Z7rXr@p+pOJSUPi#p)9%+STXkE4BEi3)#d4b)SbrBqMq\p3]5EB$Hq4!WI\0Vh<HLEm7@=eStf1#QC
+%IGoGUq^)B)Cs#B?j)r[t&0uG6F+5cFnB.oeTMo(EjS**s?%NM0=3dpR<<kjR1S$:KKfBh=KL::92/<BMhZrCB,$FU>72'fjVt(4M
+%^7RLhc^^+Ef&Os2a:]kl/FY[CVl)ZXgMe'.a`cV21i%$NaJO];M(7SOddLE@Pr`+q6N#V++l3je]X8N4-n/+Cr7ZP?`se[1(>R@h
+%S@NG=aXZ0l&dL(2jgM!@=)QEhEqbePA((2?C2EbFm7Rdt@FkuX^"tu?<sGeL`FAN;1L*$s*:b^QQ1ut8eCdAbf&$k^[b6?uW2^RV
+%$KW%#TODQ;4TSHab-;WC(@o:%0X#)I'5]1+bS:F2SjlZ'A0ukGKu+XDXAK2U13kOZY\P+"TK:\\Q;doURVUEo126V=,F]BWJETO#
+%,#l0s,:[I)kTk6!C3-p_V7+`e0!U:WUThDWXV>6h[jS]'2003mNn\/D62JRS?jZO<>U`"65'HB8\\mZ4(s_f?<)FHW+'/]\_r/8#
+%RKD`=n%`c*roJHaH0(sYS*W2L192Yn@f`(Q3O!mln/'&!Et)jZ$Yf[/`MA;t7LI8]5pR*U/*B_:9<h25g-<E$j1I*+IMo!3@B0>i
+%cuO@Aq1c#t3Rhq&oFq"0d>pR(?umkPDPo4km7,\dmLY0B1^c=6UI06#2[XPPGM\iUgLN^beoW-]`JPnbfYk*qhsGfF\kp-2BCZck
+%jXeOAS8Q"bP[(Q0n)AL\52?-bW;[.3&3#IZ>=33cXjD8A:gWbpbfm^iM0,61r<M_^E9:*.(RR;?jq<cT'KsacaK<LA?0W(T#WQOF
+%<lMVLl:iBs\;%Ysh(0qN7.n?a8+9oi[cI/#rmYFJdf35FWrZ\U*r&ZK_.Cp^(/d]8G`#M]%bQ1!_Qm1>F,mt!MEopuk?Yf>K6gl?
+%(q2W0R.TjL$f\F9>W5W)oiUcfm0Sm7booK]j=[<3D=.=J-_f1b4?^(2-"#L1)f#OLh,UqJ9V864K0._s0J;Ki=sUIkT:ZaV:>p3[
+%n=ZI/oj&M"j/J&1`3pthCQE-f[ntEg2o)GcpK@?=OnZ(cI7ZT&;KC'CgD66#'W9,+Wr&A,Y;'o$7A_ii<h`%-CBTaC]F3k(7aRoO
+%O0.k'/t.,HF;%Xf(_]?(Ae82&QbPlUZgI?o;*]D]+Fu[X2"/N?O!n64.gfECO-3*LS(s$rcj79E&uoORHq6;4'XX?e5l'(n(qW^S
+%%2s:X8&dN'kd:gJ/`q*&>GmFXfp7)cm)Z*[Pt7=gZ#paiA_5j=D4p]TQ`gY8nGkqZKiFedmL3!F*&3Sef9`^!c!<T&LXO[WM>i`<
+%KLk.#fq22Npcg@`]/XKJlP6=dl#09R(R&VhD@.;k4`3M\o<q!pE?K:Z-tf2DW1-\aAa[9c<_&9)RVVT]Q6[Wbf'S\N&rC^lcL,Kq
+%XYF0+194Kp((%F@3EJbVp7d:42]97nW$R!3DBci09+MH0C2c8k.X![5UFXWs!Id,&Ja!O-m?DbCMI&'I[])DkBUa$SmE_9U5dS5P
+%HXE@(;S0[&>oCge`$nGkC:jS4(F^q(#NXYI9^2?VGs<3#ogO'13S27":R0"(jXhL`UAL.dI-RE.e4e.2o"4>e'Doi0%S6FSk:h@"
+%O."K#CdT"WI8!`3;s`l0P$QH],A6[p2EA.;@,u_$a<IF_h(,#U7$sh=1sqZlQf6OK[d@(=,]eX6ds5B^M]<@7hVbk\:Km8%("l77
+%1ogDu9m/QVj&"pJ(8*r4+C7c!'\k^X\OS711NR/<!$2B]%F;2![Q"H/;!3q_[O6k<TSF!?iGC3u[A-&@0%\gh1p1#$mgt*QC7N.F
+%Lr)#b^NLo/qpTKR^A)i=o,;n<)N'ck@D1IsF\(*/j]U^[IGqAVhJXpd=O+Xf37W4C]6QL(6,rZR9l6dpC=4)p(6PBi]mEfE"OESB
+%&\2ttos]f(@99]bV+jrDl_T?n.<t$dMd^,5;FJE#9%!E)A]QuO?*3k`@qdttA(hs[ll#$H"pSrE]hMSp]m3'cI0F:;:\>Y"Fc_i8
+%,7Q?'>D^8A!.Q=[Z?0g4Cth&HCL4Qd4#NP5S/h5.muPb:\0ORScPg>P*#qi)EE&*:MAYMG,oVX-YeL^k\6TGS,GfpI>#r26Km)ee
+%92u,DGK^Z5/HL*[ZHQ;%n972h@>XKFma^$3W@)-^$=^9oG@"H;4*Q^FDYDg.[o-+G@G`SHGDNINU+gK,C6*(Q'qE[7Dl]nBnVQr3
+%5_:M',\`,)?Tjj"#LG6q4(r@06GU#m/DZPR<JS%R%:G($p#u8-`:!A8kL+Q3oiU!)dKOrtDLfeD)k`t7D1*q-adoS*%[Ei"2I/7B
+%\c#WHZ(C4Y:30T"-[4o[8lSY'Rb3:]=ec`-0Ui<!J_#6i=7jnQ'g,)VFXr[X9+=CU*5\mc8fFecZXp%L;%*B20864e)5qSi9<uKQ
+%e^gQ-fagp0jS7-#.l-O!)!)a!-#i/0q=RZ\ECG2qIXe<FJeSC3L^`%N.484(Fm;MRih'+T/%R050oo$L(/g@ko<,f\(V?nmb]j6T
+%:1Rp#-Kle0*V9?di=e/bbU@]=?*gW%Zf5+ae^5=i'%r=gQgLQ#m&j;k-DnpE@9?d#Yar4>Wb'R(U4dqSJT\-Ibr9YBn2nkt25K'!
+%\N9PVis$XYTcC_M[T*%#$/d@^]Kln+\'P'jr]<BGG5l^F6qE%dHrMqO.REa3ME)hB7EhPq[D&h00d4"Z#6Y-.V&%j?#T0HLcRYe=
+%$uF$jh?#&D"#Q9'e$Zee28OIbefh)"6;<;U,7Mp6A>E#r\"UH9g2q<>)9W%WB8IP#O%jDT-WmiCJH:CiOQFWtXb]sd<6^"?eJ<U]
+%JU+a$'UlLJXl:5oMYF!'IL!l`LiLrhfsqcsl!(YSW`8]S%4?#Q;U0AQ*t/D1CVoZm6K0N#]P_t'"5R$QU,r+WHb[fJ@qE'#Z%H`p
+%aXmnZDf<J/6EqDKgr#<5<6K%D@*;keQ))i5,/50gibiV`Kasu"&)nh!:5$k$X1\m0$JsC]p:^(U2Sc/[;H5<Df!#4a+u`obLT^)[
+%$e60Qk#/_>6n9ge5;KMQ8k@?)j^P%^HZ`+k8E+)jl7GThh:_T48R8SS[cMdQ4K8(ZP6o)#9Xh0EK/%_2(9=UN^?Hl8lJ6du264kL
+%3`d-<<['a`58004Bc`qQ`e-]0?nl)*`ia:(M=N@#WUBskj;S?VrARrP)F-I:-\]1gW0h_agaqK5`]5:E?JDb"3u;9]bb`q$U6'*]
+%e9L($IZ$oYmD."M*%qmfmtsn!@I.^?[qd'b^6d!SXf<o0-]d-.d0SQT"c,C0@Ufig@C1d],G^,"a=2*&J*iZW*_KA%]1%k95$c$r
+%NADFkc&K'>cdBIn\5gHTkCu:';&5'V%7Rac:%;VuF8-"?^-_D:mZoU97[c`$T5MSO>Ep+7GDp3.X=5R9M\3BC/)b?.\M#SK>jk7A
+%e#=pAs8"QZrDH)<?M^$5Z7Cmd%XYt?Gq%S=Q**!<m8"<]&!^r=3TqRW91a(!V3(D,eg7bdQnWVb%>?Nj\W<<c!`'V[57EVWbck0l
+%DPZ.R2f$gGg3%0'9Cl,)+p^l'P+tOfQfJI!oVC>0=!pZ.F8tNGld%-WS/JX7n_:a;8?%P"hbuqr]U`Nf!="EAV$9j$H*W8u8m:ss
+%;5Pj7oK<R-ld8Fi0F*`Pr[fTOeVgXp^1O]n)p1tq;&'ZVT;^I<!`S8+1J>Ff*NEH!1&?>O\].<r!3o,gnAtN4U:<cp8!J*!N9PIr
+%EjE2>lO%p>C6`f#O!Ib*,K4Uf2&+';h6afD`_X:e6PUi4fT;sOijLm_W8*>&G'Q1+Ql=7p_T!-2*r?mf-F$bUnPY`7[KP!@\)'LA
+%cE;<,%T[6M\K_;f.J/F9V:$&Y!7Ck/6SKT_X^ZVjbK]'cIN]IKAc@oA=ti4&:jYikp3XAD*U\5TCKp1()PG.-+Vm]e3='i@U^f9X
+%dR!*Ih_Sd*gD&X:)mnht>s=@Zb.G6&eY4,3*<ZV4f+Pjb4&XL:eHh9r3Rd&gfJm8iKGO,X\OA4$6JcE)c=^V2Cf/7-\]intaE?oT
+%k`I6:VO")*o''(dLH]V$ZH*Hfht"Lu1\ImP9"JmGRm(^Y!B'na+,`9+(?bIP2No_QF[&,S_u$!:apt?*mFsMWpjGarBN"L8ab6#p
+%04$,o-2>'`eG6s"%eZPF*TE;,,ch#QXt-[jAClc&<&7-CDoV9VqLI"sqgr$b_gX5;j<mO`^2C*Sp9W'SH&G4>2gsO(\Xp&F=EFO!
+%@8q0UIb1c-MS$PD[4luO&$U16b.OJ?64X(o\,qFI5j?[hFa#LnlA@pdN=`9O]tnB/o]_'pBW`Rk^_MS&^-@PkJSYF47lMOs-`:U3
+%.UK4['o9J8np,$t4@<6%-A<%#gQL:Bm@JuI)(>o.Cf%4b+tp^eKZ$QoQn4:6n0"4<WqJ\U(Gd<5.lFP]^Ms84*F&<5,D@Hc>@>l=
+%oj/XG*U@::SbL^1Gjj37ZgaBpK:3/\7ha)d5PJ)8>OTIf2Esjj%t/[%OL[e=@.j#XpL^Rg%YQRYf\)B`f5ck2\2)X`D91$fDteCJ
+%"`M.bnX*bqgE61GU:NfuJY&W$R[r?pjQnKP)oM&\WVSKa7ON[9WKENF)`GL.L/U6]PaG)Z?$./'.tOc:h8j&@hAiMt`q0/cX4c6t
+%lb7[GQ['m5qB]4jk("kaIK`3GhHHP=`)SJ'<a@Z\B&D-(+PG5LRn*]li7i7gg&9Y,M.doJm&:L"/PIas`/dQVna<)/feu*thc,C_
+%^5*hbA.J5^0H*)XXnIaK1)e/m3Hi#'Ffb;(VeU++GC$lN>@d*lgbsY^UOrFV!L9*3._"WHNs8ZrluHNd1q3h/\+@,eD_$1k)EU#l
+%l9f1;jP7uC*SJrp_f]7Sp;u\JS$H8MV<md:'!-V<Zrhbe>gT&^*oDp^IZ#aOaMm/1L<e_LDOs#)qhT]pg^67+1K<aU>E6S'AnAVF
+%m_Km"UA!D@PNX7$!$-4*34#e(YDBC9g(:7lFX8^5rPis"2>32iO[!LprPcp[>rmKlTL+fT/CAgH6d%b7`/GRsG++7s`q)gF_"IPE
+%*1Ghu);K5q/'*T6'LqoMU;%N,d<Hhn&(P(fF^TXmYjo7Q-g\*<1h$rlNX\6C8r*!FA(b_E\)a5t.H<%A=G*8hIfc07F,0?='$UNp
+%;?W!WHtGoYfDo^f0Rjc1o[=blIG7dB+.<Be!e892:!Js41F"o"]?RBr=K52THZk@&1"EHd"`_cOj/b-*hXEHJ8`+odFTYW)<E(j9
+%h,.08/b3ejfTG!E;<g$iIO9RX$c"TdKmm8-mHL+BYbEju7l!hNmjg*!P]X,W8AYY4G4[u+[tD<BONVK35((_Yc`1DHUlk$XSSS&1
+%IcZk7keLeZ,o9H#mNBrjN9F2c3uY2dQiu"TRrgUh)o3Q\\%]trEKFHEalO5m3n-@D$V7!!Wdi(-e-*%\C7U4pf>B\;iUjmD]P9B;
+%1Su>)lkt<\Rh4T)-`HPh10%aA2=eJ.D,ZI]r(^aZ%_)RdQ:>-ioQ%qe>\`b1#!`[U^;qjqh\A$3)X"\b&'EHq[T9I*o1]b\J\/6T
+%pAPKaY`s;mek9uGb@\5j+CH%31!?\a$t1SO+o1:Ado(cO18&!S'"qDR"3EkHo1BV'/O:CHoPr`l=Q;GKqcb\a[a-6n-hS)<VjL<u
+%.*uXX*I%l(l.;qoODeeAih5Fn>%/$KUgS]f9tW@nJQUrJ0`ZkV+fe1k];/Z2iq?k`=!N'SqWuA<MWYGQZ:HF6_&b,kef8#!X'_hd
+%8C>Jt`f1L0/S!!AphEZ1m'`Y#]dJgsJB3cL->cpa8<3=MJWpieF?N0b[lL\BQ+#c5C+8,Qilio%kZ^37g?`g7p+09crP8N;91r5Y
+%b\S&P]#I@jU26BYG*>n445bnGgaS"Q_?DM:?HTsFlkZ9NF.<OsW*ZdNX0Y751T^gla'^k0S[[fKlK6>Kn>lUjX?*sNPc4@sUq!=9
+%(1uH*eOe];%Xj73>K$W*`C6AG".P\JI_sI,COu8fE5t/)&"83sCn[T\[f1p`\Q,q>L#k8-E4GL$jQa45JI,l;fIWj'2K).t"X\B@
+%4?G$(Wq=mkDG&?^cB'+9JRp_:5k#M_^Sq,0V7`!JnO)H_>8?r=.;4M0`7<-Q$<na&Ne+%&E>>7o?%AtS8aL5I$HS/hAT#Jb:%4c6
+%YHZ:k<^7e;\o-E>W:_KY[Zl&YBD!5,>>Ff;4P5%:;2%G+<m2:d#F/6Sg=:JN+N6Np$KB[fo`uLt[$s54[9Ntf5`#,=JOpXPfrejJ
+%^HU!1#$gfP9&<KNKF(]N3RaYU3SYDHCH[QU]8$VlP"L6U'\V5H68/\YAB(QWmaeFN"ucEYDRU)rOQiVJ2M/BB,2Z:FGcL'F%Cu:4
+%G$:9+*`<Lf_rX)ti:^ibBA-?:^[ID6h-KQ:,3(`6&)e2uf06nC/M@=G.-RJ'+Z*D_mGJd90L*:!R`&u7^"`)p\uCdZRDF3:5e?.`
+%G%#2G2n>o3D>ZX>YoufjltO[IiI8LU>`"(CiG!/;Z]8nuR3i5`#nD'HQl_u0,>*<j8,%h1ehO9dAj2.g[II2\nSUa_d+D7n\f"#K
+%+h4h>*?/6c94S?#NL,l0n&fE<Yg^s*jJRts[;QsS,FY5,7CM$/.RLe9],o4@&"2O!Nk7h_C(\\79COjEktG,]]':HP'uV.W7-r,A
+%cM<H"cGPJ/\LDPf+u_@1apjFLgR<\%oZC2[[-M<<N*ltA'#Hb0HJ3KDMC.$il0m.2d/YZOIBoMr::SG%l?jR"TAge]dCl4uZGa/N
+%Pk=16=*%d>qH`2U,$TM0Wi;GF3DJV8k_'jB0g+k()/a&(^TGj5G3b/(DS3>+XW)S+hSUWphPJ3lgZcJOG[qr?9?Wu5<SBu\M>t-N
+%a^kXJYf#FrZ,nDGGB*6oIk$4#c4ZngmYe$YZ9g,!+>Eo>Q)D66RtanEno;$`Q`X`FiBG&e'-N=[df<;$kYVjD46^\%a<j`bA5Lu3
+%h0oIQ2AE#6pb\a$,IbK1[YsW*$?+bFg)F.WH8EtlC09Xc\rNN7[OTlU+3'78Mgj)3"c9,UArBiii""=o(ehW%?W-i^<(M(`2tb`4
+%X_'I(5^>\aK"=,0l9,6Vo18beia`BPb=E@,*nqls37cGoKu+orkSE]hM%:*@c#/O%jqZFVTm`3F=+A%RLg/9NXQ+;J:A#AJ.Gcs_
+%`hLgdh=XJ7FC2Qn4*QIpSQ>bD0]ni-jSuCamWY=IbuTfsd[Ro5/<XTQUYpRfVLINGYjUA]`#>J<e"SRo?-B%T[9<nPai,`>]j]CV
+%IRbqo\a1Xi_'N,84dUI>eJnOkef.?=)B&)X<4f4S6,K#"doCX]EX%2lX#Gf+$`6/jQB!;GM<bW8A6r/3;(>5[F2dr[+XDaBdaG8S
+%e3.HC2\pK@Jl*.uFZYX7oOBAZ56V:d$Im-M<qZ"SCU`oD=MCmK]i'riDlIObjU3aH,Q"N?L5TMSk@iS3DOAu^;Nmcm.J+,2OgQ1q
+%dMh,)n%l'!g)>ei1;5tdh@W!:ncld<U9Err0'sFDqhi/u2kg45]YASE;%<D?AC+dG^HfTCd%tQn$#[L85?KC[48Fs_Cs[gQpoOOs
+%1WPu>CKRQcom<G:ZIc6#r=J?gI``6I2G7_!8!M?H!bHJ]kd9.AXg#0:%Ga(E1e8&7>#j!?U`inLk4QDO@(e.tW7HYrE<ED!lR/uh
+%o`:K8Ro2/fY.`m'BKrdmBM'r^(4:d?B>9;2)c/C3<@L'L:mG7L?->,Eo/;+@;&I(]N%4-hZ9,_NOI5;^:I/P<XZ8Y<NWHH@hj?(?
+%<_T>Y[C0\[D0?H;!&sp\?eu42VKq8K"^'SL[<iFpIib88CCR&ea;]KTB(Vtg2naaM6Jpb1i`7n;hS)omEK7AIY5pE7R2uFYArIA#
+%W7ki_`]E0Zg5:i3`si5T31`c<;DXB>1G24%hs2'1Gl$h5#EUY<0()lgWJJ*<<3l3ugni"B(Z2mg01.JOs)_a4]-GIRe]`f%!.re+
+%U0$LL4uk?'<<:FJduL4nFt;8#U7F4KDmP7&^NF=n0qu:8I:P^GNd0NRb&SnTeICkfd%c71RKL8o"H6,d[Q&p.\du4m<>ElFi,9PL
+%4!Om4c'uihj5*e6I]>=:YrHo0c8?2QA\'&p*b):l<#BZ=K"+`tkTP)I[GFrXa5Q3`#,kZ1$88H<6D:9+*QhVB[m2ZZp?7OF><".1
+%g7/"^YhdI2^#/[;3:Z#rk"l'hXL]:E=%i0+h,:NTFR`"JgW_ukhE%CdN1nbd`c(&;12+`.n5h)hRNBB[jMq5dK4ZQLe[ll$SasAA
+%A^U]5R"q]N:s@-@649)n9T\6Po(tDKmrq#e,->&lA1j,7X9BfjAW1aFL#1<gP2E&rQCPT>Rc]ZSd1P'[iGZL)4mjM"+pp=2$+DY,
+%Ri$]U2][u^V1"8Sm#B8PTAMVY3+k&<=_U@aeP[VpP$'7"lW[*(AsuO-Xe)J$Y\U!l.AWbsLbarthTT4&4H0=@%\PEC@p:=ZN%k5f
+%#Q#7di.3n`:[^i[5Wh:g`DT3082&&so<[j8Hp<\:2j/AKQ[5]!8dMMG`>2nGLJ-q3[00BZKH6EWmoq>BDi];K@(^2PB>H6M\cDgG
+%YK6%&V&Ji[]DE/)BYV/>#LMc<.bp!Ief)L0VUMc>I4P74[Gu;kcNh_HO?*&.7JTg1[Rr5Q-YH(QE48mt%(Q91`8N;A$/s<VQe9P3
+%#1ssfhJ_b-gbDWTd$S]"mT:aL.qJ<XH?sSsoBun'M[kRY;:RAW`f2pg8?f>1#Q`e4&TkJDoMLg(KD->6*?/"!.8<%7Y?M%4#&u6k
+%9\\)@"d"udHlmun>?^7!&>uC8(QR.b,C%U=h0e!pqL0JR\%Vp\FQ"bJ[F(Vk57OnGL4-n/K_4!51bn!3;oi$<"=n"LEmP`^#MBJR
+%T@h*CBqal-\pK&1(g5:U>%@o(h2'B8!SMo?QCh("[gjCL`VlHTA1c"DWdrV3'3QjOAhG5-l`$HDkHX]A1\s]paD?>SMj_Of'<U%,
+%qZKd`AiXEOXdAIX8C%C^i;`.5T'plrq'bs)-l\b"CM&U:2B(H-A^S.Y6=XECh/-'[5RKe_C*>M!:h8>HV</CTh7t,GZP;rhmEX5U
+%U@2,aDi+IlMd2BWY#1I'oM#KOVlsIB[?j7d2D2W31oso4[t@6dSR>Ksa`5Ytp+Z&oM1N'N=[[6S'Hg*tJFCd<X\.T0M6hc"XsbEL
+%3u<-t,i0133M*a8E13JW=r8@PRmYSs_D)"pLsbNH2F0QCLa1['#%g#ENO\j#0k^-9qIs\'L-k9@-L)ft9Q)dH5*u@)2G&G#Q?s3t
+%,iW[g1cG1Z9$-Y\2`IuV!W'#UWH$>'Ld&f#YIP9*4+mc-^TolY%,C"B'Bmj#7fK&`D0BP'e(S\PF6e@(Z,NCUGN722WpFV(C?6X!
+%"HB51p[mrkq?RB0ErtSSH[BGc,PoCn-%aM"nOE0.c\$V+GIlGEB&5^kUX:H3i"gpJAI;/A0e6V1hRq_ENK7p[E;K/s)AMV4hB\Ol
+%`V89i&T;37`2Y0eogU-Z(\/@]8ed-sRkE'*J2Y#_"MTcMQG6sEYr_"Dq"$T/H?4L/ek%;l7FJZja]0n9CXWX8(l_"/qnI;m5pc%B
+%CXu\=G$+]khX<_=AkYp5\o*=&M@HD-"T4fkFg>k_RX[O3nNG_5;s:Zk/1n!55qLq0UhV@2iR_rNHUVOq+e8KHG>T*fA2YUE"Kb>/
+%mt0p37=kS$g:P9.$A)a;DcPare8=:F!VW>f1pCR$:%4fM(Rn;0,`G@i/ncGXFp`P;9BofPU1JCb!Rhd`_5@P87qRO0:)UiMIOOI1
+%Q$W&AgGB+n6IYFk65IaY6sdZf6$'.(0&CJ2G?/TWllh&U%-:LR2LXc=Hg<*pFn/;8Egt3herFqD&CUs!QB25Ed/p8G<>cJm;M_&@
+%l%&GW_7ngpVD#bOo"Ai&3Vr/K3cE8PltT%HRFtRrAM.b<1Cnm:jCclT0^(bdrReThMg^!L,p0o$F"L[;FcaGh@!r7IoR0uX^(thi
+%!A)D!c%6-0i)F-L^Gqt0Rq3fh"E7e8W#>j)gURReZ-S]*iuMec1-++G6ci_MU@pma"MGn`aKCpikN8_+^CR(5D99rsG1J[O-1MH4
+%^r&\h6RS(!H\02^(7u8%SF>XGoqTp$3`/CSO!O,9'H!:1KIq4)JO(59l@k,:2bcl"Q-P28m+7!Q#uuf=bfI.['C?!%HpOG6pO9`%
+%Nj2-.6m&JHm:\%c(OHZTVUibuoima+^fX8rqeM&V<+]J%(e=qO=A^-sn^GZ`U6F1ErZ.2e&F\;`oU<cF+5W1iXH`MlP:'ufj(0c5
+%*I=&CiB>1kDc7on^pt?Ser*1<@`AgkiruNf"qZ5mX&Frp<%0"'@74*+;kWiH@hLNU:WCs5A$A_iYG'-o)NWVsa#5J%WX6uc$QF_5
+%FDN28B_:'pf!NlYAdqfZdPGD&bJ3qlAn2_1M=e.R4GB-&S<=b2Q=&<&kf),Wo-OPuKJ/$^*m,$0eG%]0Z[uEn5%/h!G5oj+$7@[-
+%-$=(W/3JnX%ZqVDY1OXrH8$/*d/_P#_=h3B\oG15[@*EPZ#6%_]?+7Id%/T1I+JVCi+P/].BFbSQQAe#DW/6X?^gAOcG3nqW&Ood
+%`d'd9Uq]#FK)5E.j7&Rqol2flQEI'PB2`n@GBYAp$uk]e&2dt!/I/Ukge=Z:RjX^g1U81o%$L'Y6VZ?e":aO)2.(n>mV>X```FoG
+%luU)L^K[V^ESG\81r,L]65dB?WYmm>:sl0X7dpA1Y;U?+F%"3R/(@P\\7J"g&_LsVg+S@e@ceQ-7nO0B!7;ra9dJkWg9,Xif)Rs%
+%!@WU(@uU]>K/M<7(`N/r.@"#AG'0_ugL@T&$J85rZNV?-\hQii$c4t'0YEm$CQ"_)1S*+>8Z`$4bFS=W%rU_3b`/i!:g2;WBrYrJ
+%LOV;,Xa>#b6MW/Fn$:[WG`\?bVtS$c[6ffFHK!bY[1?6j;6;ll$8V<tCE$a?8;j@^JV':=+LNP8#U%Dd!G/_O2<iTC#E*?MArPT3
+%nKP-7S#=VVYhL)D_(Y6t6"'eZn?pTlB\]Y258O,*7=Xd$,=(GZr>ba^G1i,3<L1gg0h*m!T[Li9Wps@\dB?Pk4s<CCe9(_qLQhKT
+%\QOGkMK:<>efOMrPGZlr4/ha6-U0jTZ3/\TYaPpB/p'-#hCf78d;R'i@"4rVUGTD1J;.FNhIiWfZo<rh[N*pBV7(.$WQee8n'T88
+%7Ks@[`TX,:qMcq0o7";lqE!`,rD]aH*^fAj$n0fm>_7d#!+1"4g7KHs<?5j[D<aaW^I>*]gMM@sgXXTWd!&.WX(J>qoaO\@[*E\_
+%2STd.4l@o%l1>g<^f%5#+NMr.']=Zh=2S?TO$CtFs.u$PpXu5*&h<!D74,#,rV-&A2aZodpX$E),i;=s/%/kBG=`6i1&Uoo&3ff.
+%p$t@@W,T1C0NekO!:OqS&T,1q-Qp0>'+HT+lb7?=je]-$gT;_m2]lFAJ=l7;J(E4L[:a8sbf/WEc8m?hbsA`X5Ac;g:piCZ5EKB;
+%);m*>NO12Y<K9!&-*2101[sIdbcWOX4d+po3SB#0NGXAh.JLO8Mk'*6,F)Z`<#]*RX'!?.MsqU6MBEE_b<[N^hL/GU758`<J`\@h
+%p+eGJACRb4*9AK8LtSeGQYA94(U?gjB1eSn$@ElSG/+5]TdCU[`5@jCoj1bFMK2d\L7=ZP$Wd'r>RcT`XD<%U\<*W(he/b)5K."\
+%qKuOLYZ+^'eDjY_bI0s>)Rhe?oK1(scba&8&.R'jFtlst#*`&&b%!"o_fN?m2(*3!kZug-%F7$l5[/goM*g7[KWl(.Lqcilc`TMV
+%Y2(&Z$Jaq2UZ1)VQ!78CRk':L(W]%cO)H7!;?YKt5SaXfVL[CJ!8h?/!b3C:J2-m/U\j"a>]'Y8:QVK_M`:>>=Ji_tRbWZ1^s<Q5
+%lZOB5gJ^2=gL@E0N6n.Y1jb?f/ksU-NkaJAp=2_kZnDGA5sAsgoFYQ)Ec3*d0Ec!jHRIg4Fg@nT</VYjf`7?sCFNH`=g*kO4""qK
+%/9MPKJ!iMj_4N5[W1NM.QT0^d]CuQZ'-!uW$&qr\DR:=g771iVRtnN?f+$C)50+fDVdVEnKXUU?L,g@n9M:g+#C)%S.B<WEoH*%_
+%DAp"3R9.<)/c&-o1WU0;1tV$Zgkc<"+)<7Uh2PDee,-BHZ,KqXDEcB]2m<+9L/OpX?q(EU4W47=bG_";=/\s1s4k)nO.YQ;pAr:1
+%0*Y&#QuOUY:aEQ@7](Sh]`4l73P<pmA:-eV9L@X(%gI*e6d'WRbm\KIbP8+5Wf7TJ)$f_^57Xff/8E#aP-a_oB"]?W)ETLp&9bYX
+%<j2if8nO["<kPIK2D39;(rT;uhPFY3FFV%-Gt:n9Gl8]f0UWH?-"*@?%QZ,#;`>>KCq5')b?";'9seJ1eR["$Qa'"iSA(;J="$d]
+%4X2a]W]<RZ2B)YX,9)nV]X9qp]R_!g(&UfG0>.Q#W@Dm>P5nT`X/_q+EbUIJ"70c1K\KLX\a/1No]r]8nj7'ZZ8O@NLr,p2hIUe-
+%#l2aeU<k?^qNeU!O/hOQ5hR7n?*K[\mreX6q-^pP/sd2#kjJmE/#0+TR+VC7Mmd7l64NHA9>%LH'UaQAY">D?MdgG35)Xn9*0f94
+%l@.W/2kW6:;;\hOZ#6bZ-$<qOTfXiI-@1=8#h+tP&oA(Yr*7'*A[g"S2".T5K!!`i,cR,AG(tI\Z++<#JE_3*r;(?.&<IRkG-8XC
+%Dt;)L+`A%#[MY#iL1[%:a[cDXY$:KgYL,Kq!6mX]8*I.eZ#u%`h>dE`[/1Mh%>WT1fFOApRjrs:bG^s'MDVSLfU6)Lkk"\2"$d1X
+%e+#/12(&Ptmromu[&_$/GprpTad7;.>g12u,0X+rOI]J:`dJI\]^[g0IkU3gOOh^U':GB!!9F1uM+45!#:X@@P%$:+a`#c@gmO3A
+%;FmBV3o.W5I;>HFeuc4-RAD$HN4`U#+V]2>\!dp5Tl=e5?]<K(!Z'D42t6lh8nAc4@\V<rmt'.mnRg'&nW.&VlHB%cci3j/^\PVc
+%romef`W&"!h>d&X^]2L7s7?9f+9%>9qnjNTiV1*>nLsq$huD0o5+2H;YC?5X^\de]^]1/1q3UE6^Nf_ODuS4PIt%@ZqBc)\q1&D+
+%5JR3ZIs_.3s78#EVdJ^Bs8+JLpA_jUq0TaIhgG5\k0&VNo?L63hHfY/WA""b[&%,"?Wb'm[Z6<&q"s4t*m?@Yn,2&AobUOP?GF!S
+%;#PlMTt&W%o.RlOhsh%gZN8b!ie(i-/RW`jnM)&goNEkboSaB@[8('(\fhS\h<[[X%++"[4+@U*=T>(+8JF+l%*uc70$rtI?L6<d
+%A%-QI)r1NZ5(L?CJ+<",j^7rb&-)5crV48prQ!goh=(C80E9MEoOf3e^J<0@s5dVeT7?Y75Q1$-s70fPq3QU$j2XB6r1!`]LVL/g
+%s885`nTEg*HMuG;_RniN5$J%ab0@+#B[U^D1Mf\pkAiIu]1ia\A=*h1!HU,,GrP038-W+fd@;XJ)r`LJrTcne?!:Qs!KA[Fd%Bb+
+%:H19[iM@8e7d&:^gE!'Ikf32arckE7]l*K5.?"gUL3_Z3.VK[L"B0#.)YN\2r(5eXVbaPnbjX/1+.(h=_EJeGg54QTqeboi[Ellq
+%P<U"7p#6FAqJJC.F[puQK?CiI)UTTaLH.OoXBg0q]nG0`o.LW=:ZPX8e'n?kQs"Vsh)q\af"2=%D=1DAa+N-4@mK_SBc:TgRQS?j
+%_<45p[K"7-AqfO/qm\*KjnKr\(Ze[.5AA?UOQM7[15tYr\?U.sg6hjE&qk.O=YVj)h=TO?I]HOt;&)nB)A,<Gfk%8@N7@"5fJJ`^
+%gA?4a+$_d9P-gKu]nf8DYo+"X1+#IrMkf!TQ91'0^#XQGs'"4E`-oBNQXt;D/,]9\JH2<-oNAi7<[M_"jcarWd+#4po-(k,)GY'<
+%&G\*-QWoU\c'G;_O^!\\=/n)hMqg!:%E]N*hS9*]^iaU%X82<ki:Q"[R\dj_P9+?[L,HVAMZ`#!gG425WX8I5LAk`,di=6*o_m)M
+%#JG[@-hh4G>/B>1d9\^58%kMlDuESW13DpNh@88"A+n6@fs%iC<SK4kbW=6*no'NJH:?PI/dLLXf=*hU9L_6hA*oUhKQ.sh!147H
+%3Vb@LFp[9i!109XmE5@\bl,h%O(n*'X1?o$lkaRj,N?M(Uh@3JdflIJ&WK4@eZ,JFEh)S_l+?S!Lj:*Nf?GsuR.KW#<#Ao.(WI=O
+%p[E9A'i$it%:J7:ADbUiko&,ZGHXsCR$FU1^sX7a(:T""ipP]!OJk!d^8dO1=R=>R/K2E=<i7tQ'5lnY=`eY"hZpBPgB-bi]"IsF
+%<'r)eLuFhm-*%HHN$Se_.a4`3/fp7Uh,o#akoH>7hR-*oD0l8#qt=Nc@>&X>!9fsH1)<E7_g#b\UmB`.Qg3i>]!bgL)FatS\T,%"
+%B,.60AZdGCn650^aZHa\rRfY7bcU*;104b*/^/:T[:AJ8^:&%#/sI^nPF)+,#&+Q^efDE_5Mg6[q[Q(H>cIqcDS('80]VY-?.TR2
+%=#L5pV`A'BWh7$ujdQ;!"[e<H*Mi.Z3raT@R^P+iciR]mSHGPWkJm%LHF4+-=PV/:C4OoULY('ohjBTO@.`@<HBfkF]TF%\/Bt3:
+%g@+oNI(4eEPN?hfHEK,S>)(@]i/2*UVLFJqdX<"agH&p[7,4-[$QjHq?d$X-04VI2Q]?Shr`&0-]R;QNk_2S<^mEKS"79%R#7#2K
+%3':.!I@<PujjQSU_i:5E`<\mt2gaG#R(]i9)dOWj7aHInd;/)jMrX>5L*tluV6S.-pXknR]Z/2PNWFCc3uQdH'B4\XWRYNq3nQPk
+%^n9A-f$'/4ZXqsb$G?NXQ%dVV1]#j3".1QsVH`e`GBRD(-lD9sp6rS\+F>8q5;oQ(%;'^Z*e)=JoRG,$QW;E._QgX^913(>hBkRD
+%m+AoGp1"D1m%Xo_cFA$O::8i^S;\DRg_M^/FjVdg]uA-ng$onH2kM^N0"tkGI!N6o39Ki$+7Ags<0&i.RC+C/\27EnMKZTG`pNE.
+%1bntnj0Wj51GCiQL_S0#Wo3[W%^53n@c%s;Y:c37(>%GmH!6$E-2XpZD;7&F/Le,R4[Mk9hK-=&,Ru+23dP/Hb_@+UERrNbl")]j
+%o$hBD*G8@E^6:Cf<WQ,.Q'-*(G.+%]/N&E&]7I-^14#F-4BKH"lN<Na&YbIdM>i"8q8UCjG$o')GRNOu=7U&C8_:oP!Cf@*75nTC
+%)Q029NQ.;(iPt,8^]l$1l^56Ba1Z]]=&3hunGTm%]dg)3Tln>4e&d=c>%QJDIbOr2"E?t^f^KP??k,Z_b=lb.6t$BSfuS/N/8V=E
+%,@9Nj0:@9u5J)&u9^X1b#u/79qgt9f%2LB:=33i-B5G"Gs2+SLptH_TNAnXZ2!TYYc/Hb6dc9Dt<XU<u06>#IC27H1b*uE96kUYI
+%oC0asP<?K?Pbg5fU?1"LfD.C3BG`g%;7-4Hpd$5-eo\K:DKHK^"bCbhJSE3co3$kbgfWWH=gGfc>e3]%M=mZL2]\EWpeuHs'$&a\
+%>j=-H@_)[(7!?<1OY5J+7.C"-^0V+Q@.rH\"m0B''b@g;#?F:>Q%S4!RDj-SCELoeGmoG'B(S8.\Cldm)BWP[8r)*A8Z=EETPsh:
+%Z[/-V.?fLQO=\c/>4oiS*`Cc1qA-]jV4@$\PjkpR-q`P3=,<LlDJ[\=b:(U[5;]B,Pujof4@Y`b!qp8Lo:4HP]f5WDDd>GViot'=
+%70RQfo.6Blc,/\%)DK>*\W?lFOZNBCB[)'ISHD,]gl:)lI9r:`=k["1^U3'660k(R\N/MS'bbp_$tmR$Hc)4&#,k0nF",.@T[9R[
+%>HQ&F9gj_J[+"-WQcEk`7X_e!j4tcKlSo,;+QJ_;TAP4ii`90G4S1^WUS!G$R/9fiZ@ILm&cVZb&(J"Toa$hbQi4rWjs66m*ujZV
+%0o."oiN$T52$XeV?jtuXDVc4V+hLUc4`RDSWhQ^?'s@Z!DD0(`@:HB1ogK(.,*b_!Xd9lt2?d>:B%\DR;]VB@QL<kPVSo+<>442&
+%NrA('?(17`P`6OA27%eWCWe$%7W-(<pH#7"r7ZPebh5mSD7]L]9\2O[HgPX>_*5ol",*i^iQkFlj_t00fpYm6:sIXNR8)SkMGb2b
+%MEneZgc2'PB%[:_5bHI^<Cb=tcnjmX??'e_L6>H)llMo'm@@@YldD2d;tr(12W:8LiQ%R&HN&SOn+g<fpbpW)05u_0<LG)aT,e+(
+%D(u(ahGr6h5CG6_huA^\oWQ$fNa,,kleArP>PC26iT,C-3]o4HKMun9.kN*<;32%.Ph1+hUQ]7i<WpY3TUD.o^`T/1Cb@2#C#l73
+%`fcbQ1g.HYN^ok#NYsG(G'C<u-SUK12OgR^7XK28G>)(Z%9M?O;KBo*),QO<VX*M[Ll%<FKjs1AHjahFhRnfd%LG?TgOMnQ)3]qX
+%Am@Ul^Wb8-)b.Ws?D[d;cHAb0DAYHY$'XUbT"):@PtcD1@t&YpfG3h%PB#:/#pW(PDA95_k.WeT*!s*j)=Q1k-USVn8DV`H;/JH"
+%VU*$)juHFq[*b3pX&_0lUO]P*DD"ZG!7iFrgNU-t61Z2)*Yt*7JM1M;)9*(R-TCaBE=&&[cK-[(0+'+_93_4,nReCAE4E9?]<`9'
+%OaZJ+eo'kYSAN1tR8eCbCfK<ic,Sh=h:7m__J5T7gcu%T%G/=gG2'[AAI6%LAQQHMp+j3!GPo.<]DPR!(c,(Jb)M\TTXne_Y=sQr
+%NL=(d`c&X;7i8e>XYD3T;"aO#*Cfci1k=Vcr4rAk`W2?P2r8-!I4"unm,?"Nc1Wmc!-Ct^L1WFe_>4$._KgV+F"R,U?cLgsN&g+!
+%!9.V;r7tJ4]*:FW&;SY7M(d/Z1l%sC5.'B&C>s.T;DFHs'MhOYlo<iRW5fQ2ak+e@YYF`6r1"';UL<CWjEjQ3\Y^8IGQHOC%=sr'
+%_+<2u-MsRJO^X["+h.CMh'"DZ3P[GUB4XfUKSttp_/dNHh*^5MboL581G)60:m>?G6"Cb\b_VM%bNN8s#4N8%S*T'M=eS4cP_Q<q
+%3bVJu)7_%L]0`Zi_811;/(lOkZ5,[n21<rYT.71d!<2e%gNG%b"rNPF!)3XreDag&FTN$1LhJ_/^\cKgiHoR&Gq%O+'3UK9pA=R8
+%ol<A\YFPraCkm,(Y.lT5\$7bkI#/%mY?]lcq)S@TicZ6tJ[Hn%]J?m$p(QAKZZ2,>pZZEcq_>l4B(VLD;&+7iW3[gpq1Zo<N>$)C
+%O^8D?E!*Q,@kT+D$eE-ic3V=AT7J5iYamHF^(!,V2m[rm[H^-O*h52#p^S+s&<%)kFQ56!M$&So[Upr/3..(rC[>I3,Q6YGX,6W9
+%LQKM>"E"C>6B;1@bPMG<aif+]N*6%'0p.s^[,Q=PHR@TD[:!1?T-S0d^'JkO?QeQA:kT;?,^=_;$_BkIFUmi!^<bYpbGCt,$>1@/
+%(nL0&p_B#$Y6`.Kkl+M.**!T94VT,K;`Nel>@J25KXkq\E[kDPLWg$%h#5=HhhnW_AmA>si5nP!;"9_<A0(G3CG3>B\!iZsToZR>
+%oF>5jSD6Hl2b/]ic](AO^m!5d92iF(,.^%Cm;ah]\6"@;@>rs0_WnXu<NMpgbZ2i;dI>GtmO;6^Z!QC+-1#RgiM5Oc6&u??+lN+j
+%\o>e+!Zq:dTX=?sq+K9g9K4HfdY3b=qP>OP7:ohA)>"4G2PV)]%m$T3&Y$-MO4697.e,8@pA&j+Y9$qO[VJ'gLTo\,hP>&=<`0Y*
+%NSJE8?()bfgu>dMGr#^CGkdZ,!FOq?[eL7lroXPV?LHil^RRL$O"ZQ$l/?E,q!O2i`,R_]fQeN]WPa2YYkK14alAD-hL1GHom'=t
+%DuWT\`T^&V+$YOEl?K0hS:AScnp%/uSA<1oqVb[Dq>_meiPD^Bn3N*6b/(E0n:Hg\BkD7'R'*K1BmN)bn(!PtDFD@tf1";Y9_+UV
+%`F$*S]o_.WZZS^SB!.?\9[DMjfouQiQDSot\FCV!l/QsdYk:4#'8H\OiUD+PW")>O_sqq5.Z]AM_ZB[S=MGsD%kbZF>rXk\#9W$>
+%F2![?hgRT"[Z<)&YP>UE*Z!%8NL^jFC"8fAp\?mq#TO=?`^;`V&@rjuS7=hV(d&f@X^anF%,[)=hD$E@L6'A?o,*WSL9JWopD=Sd
+%"6a7!I14<F&c>##In0r0U_&RNL1=]P0o9mDGT9X,a#(pQlI/W`NCg#OEg7T#)Jth`m@Cmps*I<c_q_J?\rJFUbEUS?hJ/B`U)R&/
+%rET?9/a)2h6n`&ek3>EfH<Uq*H@rdErgpDMa<MkQ5$A^+T^N?GHKJXgZBSM%N3/a]#'5&_f/iI(pNdQ:J>MpXUpjX1*%eC5SL%;m
+%2PIj3%CaWs&qe.Ikr+k4R*'H\`[E`p47qM+gF>OLC08(<;NA$k@GH22!liKO,7K=/P2bR.o04#),C@9Xe(@W.)VnR\/il'M"!__?
+%:Le!<T9lejpX@C#huiVmIG8U!$.+[,,'B>Sl?LRAiD_jtH3J`^S?i"s8&1(:6eUMi473<mQWqJt#\IE;L[B?Dh5\/Pfha&_]o42g
+%"?ke8oZc0!._YE[P^IruGuAenP+%>na_M![1iC=n[6pgjcZ;":X\mK-*WlDn2[hi*_`07i-c8(><qTttk+$-e2(IW8#?,@LFBc<n
+%?tqK@1H5gRR@_!U0@B'H'j9*-Ea(2<J=Pu^E5bs/1Ha5B/mst'n4qs.k9]l8M\Q%D-64,8GY&Kt=C]14Sd<@:Hua&D);kD"_eX3U
+%B<fJ'0ij0SRsN`%bj7L7^W2KlC-,0N];pXBF_89.hYfcp"ToTI\aWd9)S4=c+i6d1_AkgQct,uQl]"JN"3cB^B$4EMP$+oTH[/s;
+%?#+%u;&3WN2UKW\1/Afro)"k+NfImfE_HY8lI+;S!XsMZ-5V0(a]ktcK8n?e=qgt+$s-Bc2#5fWMrl\;i?U,7C-.8RHA$nO/9B]j
+%r_Clu)PR["-@R!_Cr1^C69bPSYbpL5[O]EV$n+hrG[_i.FH>itVR[R'A/D`\0L[C:\P?FKZ&;dfJ@i437+"gY=I#6UQ#;Sf2!$5!
+%]jd9"T(u$>@8[]-OA!2bm%,=t[80VRf5)o^DI\;/p:/?"3'\X)ef?,g%LT/Gp&p;CJO<%U;bTm_b[n9g7I$'rEs'RlXuU#';MWf\
+%r4c2>2>iJiOc5l9$=hZiFR^)?E2-Za!!/Mj7-@>l!egH,qapJT?9uKg'[45jWp3&dGS-soh=(KKd3g%O;2EIQRk"FWSVsqVik<7b
+%n>$*=YW@2[0n'P2qQJcmM:0QE70@c]"i&rS]ZJo;<lBs.JP05b#EQ@:/"=s:NY?%_0i>p7&SES@VN#>XH3O"KL0u6?++G_)GM*]t
+%Z+6YGW8F9h4rItL+!>2>62[X2cS^7Ai84nMP:]Qg37E.m0/rL\&L2%)^3^Q9Wb,ijE,K1^lOM<?=:*lj')SM")dS<U88sJ)K4Nn7
+%io\[bG][Q;fsSArn8E:#"Jgk*LkV#<'DY/D5B)G?ME=@*G]4Tfb;RZrd@8h4]eCZE3A'ejcEIsp"f!.sbWdhlR3fQ_q^iLlc'V`%
+%j>[Ii3-40o>^Cs5h9,j24A-`S89JoP>2^N1-8St[i*)&G9.ubP3&fuEKlHD7fYU9Q@h18kB;<`/L'qfWAeNNQ+2s0J/1(.B(Qn0P
+%JSFt8[Gd>cT0TiVSXIJ=\)j+V2\)K'->N\Wf9V"<ZSS)AH#<Ji2jBQ;i=dcf@T.BhF/3b>Kj2]PCt:,r\3bI%UO'Y_l&3##9V!I;
+%a5Z9FFSh@U6k7`/Q,FlRLgk0JVN(>KlM;fXH)l-qMsh*:5UF"YK,C^5lcDGr\D^21!%UEU'<;.;[1$,84eI\Kl&ZV`>l,YO'EZ$o
+%*aW1o&A:mNYYc'ok?DIQJ1gKqClXsb-+qH^?8,kd2Q'aa#tM094Im05$U!L0(`L#+AhA')qQW>n"4D^Bl&u/2G;nS<DQ=97hB>N$
+%,BGDbYLm'*^HKAe:j2/aj[m8%BaT:,VnM<th)H(#UH3&m!t:;mm/a^1Fp#S@*EWLThm(-i8WQKWLTc_9T?L.@,W<BjoL.',!8fKu
+%g.&)N*k@/e!W\>aM[1]-i"b\0iS:6Cq&^C*+H^T+V6F?2AA`C7&1fNLp=`7dENDpc_V,tg'WG#4Z0V*[O:WHI`o\>=@K6#/gQ$*?
+%A.Y^J;:\-J`tWJ?E"mA'...VH!OUhpW9,V]iPn;XQ3CO.WHQTmocZ**5/i]JVM,b#XFl=?F[?r/]e(:\l6#6A.YkOl.`82YgO^&!
+%N+<<`Vk$5'Eu]C9ok1rr"5PQeN8=XW%ZPPUOZt'Z;,cDDT.p=oQ[)$iBIVX"":V)M/[@rOL\ATXo$B:4fKl73kVQ18SZg]0kiNW'
+%@)0NE?7o;2RFciW%SFDd/rf.1lWAtaJ6?oHT\GfQ_q)2TN$;1Jb:Ls5_Z1/?Lp@kTD.]m2,&D.YP;n0O@0!oI10HqoZ0Vl0aAN6K
+%&,e)!H'\O&bo=?*jBKJVnOOO`1f!\ZgKL.Tp]QT66L7Tl#79W(qQNu3!Jt%C6f[blgJVW=X&s#s.k*%R'#0QZ(iT'],j)g+hEeqX
+%]@\i5m$7lF4UTpIOU/DUP:srMG%PL_?5e)dM66Pr*I1LQ3V[4A(/oW_YZkF@s-c<S(TN(/(KQmk5Y/':f>,)dH'`73OR_(p[mZW%
+%=WHpa:9-FN:dMKB51G)K>1D@KV9%\iJEqj`@qb+%?dnpcZ'3Dr(ime7R.M*GX+X.INnH_%IM4LUH]$7PkD?p[\\NorNP$f<A;pK]
+%3KaU+[^6o$f]tI)8o3t++uJbGC2>Wr)n(3Tn/Xt40,M,p0U=o4rq?ZI\e'lC=lX(=5s,Iu8qanPMbj8I;"F\)Wc/mj]*l=6q6`Nk
+%+'6`;URb4GkS%[N)SaZ&(*2s`__,QS@_<C2ZGj;B]toSq]uqOWK%!JDPD3FHM^=Ds\IAX&YZO(44&5OPW.pAIe]n_I`%5MsBb.O,
+%HKcE9;H;RmZZ8m@NP\4?akApmo+6JbGV0ONB\0BIU/.`!m]LL0`mTB9\j.tKPT-U!:9Gj10G[aJ![]]"(gr4fDe:9jbge#SEj)Ot
+%+W#^s53Q-MM<ToA#N_arI)Bg$qWY/+;2VMg;&g!A4*82nIUWCiD7>b40OsO57]B!4(ehD]cJd;+r>97$p5P$4!FF6SPoYfe_[F8^
+%[KVl!j4*!l[LnP5+VmllnE$86#_on3S?=nljI!3q)d&&DbrCuOp%'+)Ui>4ofL`3G13U_#bW$G<*02m2rY?CYWMFu3DQI+s!PJOs
+%Zs#T`pGQ3@</l9BiVmcGg_K!cYmj>dVn.N8H!>uZTp>:gjo?(J"'eDkF<c98"47#%BQoL^0DQ4hY(p!B*+#CWg^j__d^Eb=`MQc<
+%Ido8<:6H7TYL*"9iW[/"-Gdj_(FN&I=D;baH_X:u5`IhnMHlB3(3j$sS=cu+a0/hE#[Y+;_=4$!co-IglNmd?(/s%$,jNA2C,X=&
+%L@u<^4I$J8SZBn\k,PN%Pr_.)5`kl>8U1^6b"K=2-?MFTL?2%M]6/g.QAs"?aV;"Eb8$lAV0]'X]mtdJg)1sP,/D94c'F'K5H=*&
+%YGg`i%6q'2'1n3r-IpY^D@cm@j>BZKJ_ZZ-\Qc(@am6#BgDDtEk64p@2poS2UlWkZ=!di.T+#)TdWQr7Bm`;$@M1if7;[*BI?@+j
+%4ZA;Nn+?^oe/9^TldE(rEfK[/Vma7g.2js--fD(hq=t@&]7Lr^FHe!bZ>]ut4q7=:DHpZ);Rsf+28i;qZM&NHmPnf0$</90?q)hA
+%gtTr?Wp:WsC`2;GS"9m!oeW!+-:e3T7AE\E'$[LmgK-cd#"qR4O`'e,SL%;CU$uk2"sAVV7g.p"$;NLt,^d#!LneZRgPUJ7eP=8s
+%R;8.D;9r\3H0?a5g9baT-JlV*:Zafl^O#jo`Fnr*_UsTLGR::pqS6,P;P=H)Tgo2/8@W]d5mj7HU4WJ&904Xp?D`oXmckLWVg2W.
+%rB7\g3"G7P]nX2E[P_3hi03g:!J59U]h?c,72<lN<t%k.@51=IXg5VneXIJDiBWV:,;Bbl$R\@:=,@+X$BHAj^N):E*PGE[9LMVJ
+%i:=KfV3r5g0)U!PEiLc_^X1ZM67jqfkur8$(V1;..X"Gc!4p(Bkd\JUCOt44<f!=@'O/]KVG37d+^RjBH"Is,fpb\e]8kHlq"l,#
+%O<1XbeaHgiC7W@f>8F[K1'@Ls:qP6l(>Go_&?VqIC:@BHeEuO:#6U7u^LM1hfI@q[<\YU+6u"i`n[Cr`*]I"Ac,qM;(g4p3&s">H
+%9n-NQV+L&R-nLOEYa]!i^8tS4:!'><GE)Dp2hu@AlWqCfV8YocK%U4?C,KLe.sh8td6ECF+:-5LqLq)JIfC:D!K0YjH7:Q19e8MI
+%SJ05hg/Kh>EsJ(p%lGU'b^QkuE12_IB:u$$L9eF&.gk16ODNC8Fn2]&^NX2=48`'en";X%E3H81:\_qY!c',?';*ES)ufgMQI47.
+%JPol\Aeela(UGQoUTYSc+$-$R.;M0r</9o4ZA3'%os1=QCcIEb&nb699ugT(@HjYXZ!8@#[(>R_2D1[M(-*TYBh"EI%$h6VU8'gt
+%q#hpa2JlRE:CFd5]9-jKL.WbLaX'k@;5k&1eJ*6MN!Y^sT>4p<Mq?CtF81QaZ7YG]e0\;Uk0gbB"t5o:QpaS[;#^+fjFJ6s9dgHD
+%m_OR9eL^:fDM]C+C4\1(c7=DB2E54ub7^<+X^5\ig.>[I,-3lQL3W565oG%"e3mt!>/%V:[2-AWe6;cRSno?iiK>+0GbhIL@/(g\
+%NB'6FVAsRb%NmU)6&c-X:5E)%!1.b/S1_Xf`X]d>'$J-LM:CP\PTO7_Q]a_'!t8il@T402&PtbJ\.p/Ap/?kN49j*ZSrj#>KTVPl
+%)umk)^/_Aa;h<gc!-RI2AoW'N+d"W:3f.+tBTVMbU&:587HN8O*1tG/A<ibP,1>.BWLO`2mJ[)K^e28<9+/o5;%p0O96h$GFIbJ1
+%%$V%:5asocJ^/Tp<UU(;+,:Fc0ku:GiNSK'\#E0U.H9jb18%'C*=4aA^pXIT<jHSVN2gr\^jVgp]U%8l#.c'F`;)c?#L60*9K+HT
+%qKGuZ24@*U<YZJb8s;G(h9>X6-V4anQBmdmGMk#:=<=(O?m5[Yo*Sg1F9&U'q]+kECdCN'"p6]5]pbDX3$u0Yf!SA;Tl[g>W)P/6
+%Zl94J88Q-Oa3c=_KJZ\o^`;[bChiWL3r&RbY"K3q?-<<ND.Z7d6rqL.$pf$NgR"R9PI=^1bKNGe\_24l)Qs#g@;MCKFCSo7jO_W>
+%GZ>_%_Dru02d3`ufm7\<b"SA`)F@qG]]&^t3L-'t6bS)b<'lAkE__-@f_L&DT,HH>JC,i54pAndZ0V8uim0AO5qPIEk%?$uOnEqZ
+%#9G9FB/YH30j4`qe>o[b1Od\%4<\2ZIX?TX=WJFB)D_^P0Q-'/q'3]MH-L[+4/WLF%14GO3Sm/.E4VL5o0%BQ2hlZp!H]K0bc"-6
+%#>YFd4X$PZl92HL[Ms?C$*52>Lap,jX4:#\`n';aatR1ff;^CP%-&TXM[aQg#AQ[[B_HVto=d6iRpo)=SH.nm_dJfdG["$J1%W-6
+%/-p;+]T@Ag<gP.:W$;>H]pl1!h%g@gAo&l((p!hFH"Ni[m=3T<+`A!IG'X-hSA?GUa8rC@%tD3Z3.W(QfZB<[(25#q=<4$lJZ\Li
+%R8O$Z+SC]qB,'^_2lsF$"ZWN4J9DnfTk,U>5_E[O_F3m\0SquhYPSe<q\8,=.Z2&01k8%.dXi&a;'I5)_G7cYTID#Mc+bQ10^oYI
+%47o*1W!89i:O-Yt(KVaKQP'RpJ53TUPMhWNr/W)Q;&Ad0f=<b2TJVCf[`l^01_ku1"']Jc/K1goof&>&N'6_`B(U$P:Q*)k)[XKS
+%a?<s^Wm#+JgNg-s3"tEdhHs,T]W\H;@t2hh?<@L./aZOG4$7mLiRc[Vk74m`EH@<+1h(ulIT#YV7:hnD$=85.FJM3#:^%hk^^/.L
+%+bY=pM9p0T.!K$^Y-")m!.,$^Omi?lTEUIFW:NLfehj^CdY1I>[JFCp$d6tM/M]L*khV*sGf94n!.NBq=#^mHqRALfg\p[)E.rMO
+%!e=WN-n%<BYDf0.Tt3PZX3PhaLe-[!g^r7C3/OskdAuXP"*EVS0RtKi`8c"dKt_kT4coKHZQOL8e&ChO`gpQ4'mU$Ph0'$6\6+If
+%=_1gY)o,dEpbO_s*]:Gt+^&ZM+R4a9.T/%L;G!$":XWD<ecXRE#5a4fNSi-n#D2YR$_jda`1a8X![[;5pjWLJ?P6<IUlOWO:ntL%
+%!f,'1dr;e<!OW>AK>;TC"d7_c=uWZV]sd?%aKUUCHtqur6oD<0e+e^HJLCr:)(6:'jeLI;7c8C$@k2)K.0>$AUc&!<989b2o1<_2
+%Pe]7\^ED`]N<3)=&#M^jUg-<(1a?u][Ond;E(.I_@;aJgWJJZ*itCQs'fd.T#HS;<("0@)F9`?Z1k<\f#LjX+bW!(GoPt(Tc`HTG
+%Jo99kBsNC]g)8_D7/=&NBN;]uQg;sJDlSA>C$5s)`&U*82)_Pmg5`DV_fa-o-h%>EnS&?18qDE6mr)Z'BBZ'MeE9[2f&;%&-CohR
+%-BiOQiaca@Ye]J,@VR/pb.SW)%h3Nk`sY`rA`&',#F2b4Z)fDRG2HaGAo+2JGm-*<?iu&8;H@./Iq"I2W&\I0S@ik`MdTf$f28?Y
+%.5I!;HFX6u]W*)o6s0R@W]!u_(7G(I&'q6Xc'9NoL2M_GW&G$Ks/@<jp1sZ=<46l<bJADTG9=:b@+kTZ17)k!fCn8+N9cX.3Wh<T
+%iiG]FRj/1[VJEdV!Big^Z6GIY?D#1(K3lumQqLaA96+%$jFjQN`g/0\l9D:Q7G4GuOJ0\p'[<lNW*cJXg;-^%$ja613!]dq1#5lj
+%Ud"Ju?eNt[.>W6M)2\H,lrt:jCKC4@<$aLEN%AhuSYgd5lc7CcLcg-A7em$:`-+ZQ;Q\mXL_un';P!Ot5[sJrEEY@9p^I>mWo_/u
+%!ml>"WB,I%Aid<BYH<?$r`hVILi\1=+d=Z4hY=oR0e6CZoj\c+LEu5W.tgOfQLnLW8no?.Rai73J/OP4XO6NP'bN"pAXb'D&o1(5
+%ER)e7f57S:2Qe03E.=HjHR*Ls&<neE7l/g6.O5hGCggkikf.Bo3LILL)ol;j[>)[N!(YFN1@I;%.HkaR7;DD@9JQ\6,KhKB=]c,(
+%NE8fac[VoDKmGO\JET]e#+,Zt$GXO)@(8*Rc@i0'CBdM/:^NA;GDIS#U+:_3`^!1b/gK#rhWUDaOAMQ,kEN2Xe(-c9h.EJ/%91I5
+%']:b(pk"H/dR*#ccj?<kM+/$?]7?ISl0T05kKT$T+o5Y;ZAU<"/MVSsi\Y?\$hS-_)H2u;D_@A9gEs9H;R1S)2a0POa,EEqNHs\2
+%mJ[86p5g9U;%ru-W,>r#BD+<V9Uc.Zo3iTiNCu[<NV+QI1o8*19&o*;k&dGSd!\FH9$9J*/":!VHaO5q)bZZ!/@Z7:KM<^o#_p4u
+%I,$h61-mI<L'k+mT[i;B=MC!4:H,8Z?I=t$d-.Zn3+E;<KO3`@71%J[r2.4u"66Xb=:q7OjRNm9%I8ZITLE^kc('kN`sk"6L0gtu
+%R_ChMOS'@SBcnCb'pFi!Ff>%1*RX;KY_0<X)0rrTXLast)(@A3+?cJ#oX"pL7/RmcE?bYb]Qu&fTg_hE_@_oH_03d]iWGj%;5gag
+%E?U;4Gbss_egUg&k@K1824u<e9u8']h<uO*1dUWg,Y4g2('U)-!l2/+&lmC9V!MZ5_/mHMmmFu&;noW3mjuc4.R7r#T5<K]a'X&T
+%W7XHLZtR%\i=\*/H)Fh2\=5&9He[^n$K@3l=g4%@r8TU,$SO,tEWpbOKo9CL'!VRF[A*73&.QV#7[$cV.@m&A>4a+CaKTGePKm_c
+%'H=>SN8Y`qm,('8noTjI5k!5C/qAX,_8,aS$8CtHK2,ui?sdb_5`g17",JPqDoU?'C#qKC'#2EK&>-U0#NmT@G]mV;ip9r@ql*H\
+%;aXfO`P3PWH,KtIE>ZElo%OSgQ#.3pcs4\D1mG#iO%"&Q=LSVZ4YNk2$SuCJOYuo<nt3$_bD:t<\2eK8\eK,gG'5jh;irUaA<hH,
+%Sep7=6kQmQ1%a'#)LEfmpHJdn[EktUh9#o1`F_.J!+Un=m&qUk$["2e@&73iA!:@*pfOkKTNORICk7:,5)b,10PZS@n,.,Zn[7KJ
+%m0kU>-D@o^)l]+Z7l6b+p+;+U`SNu+1Etf0,eL[e:f9;k!U=hX<%uq`"e'@aVAWtmO2rg<6i$UGaIO(7R5J`g(2@G&WXB+0lc..G
+%jlF_>Y<2ihD9U3HA+_=gKf_U;D&FgHITP%mM-R=CJ$(&D;Ig@KF8F_n[RBsBbVW,V#QIb6FmHe!FQ[c$S4<WNnsP7[d[SWV/knMq
+%C!LVVHmEjiZ+Je00*Qd5"Gb$VA.t9e6p+E4%^`h]5OX`WGGP0X$%aN[iK8A0VC4XT)3<:f,>%HW:jF<n*bh&RPg0C.o10OCU6H_`
+%VamKH,H:?$J3?eA+)/,Q$LWJHq`sL2;Lf9Wi<NQVOb.s+.mFT7:F,-K?2BC]IAC9n$/9*5pQ5`1VMq/#j[UNk"(hGLDEecm:R(Z2
+%]DbLBJ"Z-Ml2=+$J:hCJUU\*:Lu9[aE0N:@8g,0C'-7;mc=.20fnQ9?_bgp'X;c.[QoKt#*+UQ@,VG*t(e<PD8!/ci4cZ:Va-4Tb
+%;%VeS3oiS=j<.$7'JDK4S/`hP%ald:+tH/LQBQ@4K?26J*6_8<k"0%E-qA=mY'CSh3==acV/m\gFrhoSNoE2lTq@Mqcq-=_;.f#7
+%8TYY"H5&D$Bd+S9P9,CCNhT59i_9q=:M37tUNk:@d*tpWl6p$4+E_gk`B"?>4c!sGFLdD5?4ULP7q&WSK\1q4fRl$6;8hfenE_Q`
+%G*GjNOBaliZQ4bT*_"rr!c]S:\[1SV=eP12AbRU"GEg01M!7&.mlcL!*T[,>V#QH1JO`#B#P#Wo:>o'sn3R!A.$St><.'d7I$/5,
+%ME2d^+<SNGO0Xp=$-K#Jj\a\$5m6d-R!FqII$!<7OR,)cH_,pVO.r=\H-ljGdKeIRUVQ+c$hYp;H5'IECU"pl>E8ih%q;b5iRj@2
+%lrf;@-sV+b\:'IV4\FlY7<TaUH&E4j(<uGLoQC_%Qc^B-f!%c'io.E-8b7NA@s>_qSHY2)1k*?j5+un%0C$%%-@TEBI*d7OH5npg
+%&,_Q6U<.tIo"\OVi45?q0dlD5O_&UpiuGTk8"S%h&bNj[3YRJ_N2-^PdZNd9j?u0#ViG#_,:i)2_0$rK*Ece]%'gQ"m)VeG@'Deu
+%h2].X'8Q"s[lZD;*a!e;_V^InprFXA0Fj_bM'jA)RIYU`7NQi>OdU@;-,E.V.eL5$/rV/)k`Ib!1UZk+JU1k-*dOlK*7uKCp;!bX
+%@,[[_]16K%!t4mT1&T$CIc)A6E0a;\js(91aHo(GWukHr%ufm#\,/Pq5;L5SeFEh[qN8%3jL.;Bi/aE(1V*M'_gg\4+5-T?-%N=:
+%^enIs6&XYe\)<oun=YMT<),Df/3N,N*46`G.M!&I&.e%<#G$\V9o:=sMPJV==V]tqTQ/K839kN(2*=WK*tQL:B,-Q(hT1=-a[sM5
+%W-@g*NH3NG3=2iNBX8[X>`NPP&'?RR'q(iRb`ag,6,Vi`G4VYkF&^OIkj:KJo,M:g%XL@#g->l`TqgVoK0%CWalo[KoUq7U71VP`
+%nt9TR4Gi@Q#%h@*pl8@Zq>e'[)td4`W!IH@Y`fc6D"1rI,d.70\SOPb6ePb/]+1>04DI8IkXce[ViE6,#<f*mh5d;?eq9RF;0hK+
+%de09sFk$D:<s^tRM4KpPc6?g1H=f\/Z_L.HPG6c.HgRWXG1:UqWkU\F`BC0B*VJS:[-E[_G"2_K#IV3sZJJH2mm4/G,jfg*!.<-$
+%I*`WkWXta9$]jS-B-"psA7?%HI]B7*FQ1!*T[E=oLa2o1W%GQn_+W4>f4\;?)h-AEhW.P'nm03)61=A9)tU/*Gu39YWcK5(4<HCE
+%O8>Ls+jig)d<BlaUQ4T6k35GYoj()\W470)ApmKq4Y"/eeR9PAA=k\kht:]E9"#81[grhV#;+a:h;&<qhP6P.c_A0ED;_1Hn6'c+
+%W(q`)0n*(a5)LR,<Kp::b=?^;UQ4r@k4?d6d4*<6BDHJcMBd:@j7[VL,e8efAFRW!0Sid=c<"M5#nQM4:q<]5K"m?H[<i*c"^5T>
+%@;+iue#/k?(B5baSf,u<*O327at"dDe''cceOOZ-bkY.?6-/N/'fEQ6?ac\*3;+u%>;]S_h:.82=(G4$7]%KU./B:B\_Y!JWRtF-
+%.U\l@;@_Y#l>NoRUsXgrr;e8-24,5M:;^F4::=,5]ErU`MPk7jaN&WS[:fqE[\-7L^l3r"TIDTMS$k-B@&e2N)T$*eG>od#8t;st
+%W"s5:XAud[#f0fjb0F4H<&`sUHgRTQ\-!bG%95P0RFqqp!]NlO]68@43Wua.)3kojTG156A25iC8Sdoq:h91Jj\+jZ0piL5?H1hl
+%WrSkHLE$]Tig7uoR+:)s3878SSViFS;F]UL9N<CO;_nGY*OlE#mZ@(.hG5tsL^%V?Z[GIQ?H*JHJR)N$68#_F+Z,DrFc]p'Dap&L
+%8*pp(iHqhP%VCM)N<FRB74K`9H$1d%[k;1/P;N'_<fZAETJ,9_AX-(sqjP'oCTCfHRB0'*Wej=/I3#SZ?@b7W!C(Euj`MeYrQVC$
+%Lna\_11:r&_M!nFr%MIiiZIU3iRFq;hrG2h"Q=Ks<_4*K`W2qXRub\qCHnX^[CNVMY&lH-=ml+fd:l&_4+^dFf8WR+j5d\(S3klq
+%DrsC1neD-dJ6K)HB"R$i=LPOr,eBbJkWs0=Kaa^i_u(g*QMUo^11f?a"Msb_cfkN;r`h@CjP%R"k7'-I\cSF"7_"[aUjQLbW`"=\
+%T1B0V@mmPLQVp)#Eat3i8:!45]<7->CSgX-'[g+',?I#Bhs8HV>_QIoRZ^$Bh']2`WM@Ir7]#O:V3.^KiZ1aI)Tq`MnO899:K`Cu
+%QKRqTHHth6Q[Dqef.]!=Qn(qmS0RiVD2t"8q"SP_)IIus]V"=9VheuoS!l]j_CLFo;!7.''"DC:`.;IhoRe-HQSI)X6+Io8ABPGm
+%.<#$fq?kSNP9-4E7,"nUEWHpQI8t>k]DF,CdattHM-:XLoZNWQigedp`C7/t('mD4E\W91TYpC:M;oaJ]No,'Hkuc&B')Zo"D45d
+%8H9G\2DuA^.IDDLRkE*bcTPRCpW%I(Si]FDTe^tp4FO8)juSa)pB.$lgJWA`EnT`[n$/:-^:9"RH8/_bpM9ol?mNh%Z2]_3%E)>u
+%(!tL3`CU[_n%C'bpNl58`FbFIBaP4APm&4H8b`s#-R`-ZmOA4F<H*[fR)7>%1a5EOaq-6'8l=nI&-L>\UtWE,>::*II*%L*]7S,P
+%#ROA5ajI(I,cPisQ)tqsnJ(g$q3p9m-%W3g9Xof*e0Gn5#MB*XU"n:qOBmAcM2EAg$Y@pj)mEBB#c*0cVFV])9t:9\.l?,hX_$=Z
+%[19&<BV5rHEQk]RPnhR-D0[_-goM.VMp#-K;-,8Cq0Kq#\k4Oec$%/cBuJ/n]#9X'dVRH>3V6Yn>NuULY_usD8_J/HNnYj;=b9!+
+%/]DC8.Lt1?'MH!tRb'fF)&TOBlWUD`X_%k?CR7Y#F/mSp5!g==I3jm+JbNYUr>G7^"#Ob)p&Jf3b'P%CT]>qC]j,fW)*@oVba,VY
+%LsPYJE(\@I9fM^'<I)9Uhl<?@KVnL7qLaKN00slJ^[ui^c^=;dMi<j]kHa>N?;W(^-3l/776\pmcUi9YT76h)NaEighm&G[#\*"b
+%(Vf"C]0t>""&bAcE*.hHTL,q_XeX`'TXgJo<p>bT6=p=9(^$%Lnd\@Z9i<\6P'MaP!q)?k1c':T<:Y5(lW2'K4mH9(&2q(uV7Qm<
+%5l-pHTHW/A#&&R!ksU7&:\?'U!&gnP)>nd*^J[%sO;d3tY7I'J<RnI)\o_Ks=iaAe(`0^n*MML(+2Enu/-ZXX5:bDg^fY_O5;oKu
+%]&K\G^l3Tq7Fr]9`0/AJN'h^"0cMD_/`RNhG]cDXE'ma_A!_on;nZdR;S^910)bd.WmM*VLN0u=Pj(NH1/cbZitI*_rk=3*'U(DM
+%Vduc_6LE&1nA>G683K8>dPl!2JYDXh]e6$EN/g()Ll9EHcdmihFiZO'pO,VP&*LVD;c'Eq]%';R$Z[^;G#ZpI7B,%'I`T@YQ/ZTq
+%d%rQ!;o@ER@P!'3(ccc0b_9UpMOA!&Vp'SL,%MJATnYqdMR6ILnf8M9O8"q-1;Ja:EPps,.l.R'D0SqI-k-PTk@'J7%O:!@'3>OF
+%QR>H^8[R2IbXgs]6EU;Xj^]/E%N7STi[?ArDQs7,@GoXnEgopEZ:%k?:;P-`huP&7`heO\IS)8,[&Crfp8n/2M%Ln@.P!`r\Ps(!
+%P5K2,D8\sP].,I5&hKM63JSB2k[m<oq-IqGbl@"t?_<Kn$_1eCX"8f&60[:`iF,54+:eY,$<B,moT7ed./TQqS*JYVX-?1%fO`3'
+%K'(gq'Rn5?c/f;29*u>aPrk/QGBapP#V9^$b.\T"n<=q%:K"fg,aGif:m@Z/QX=iO"mf\X&uooMl3Ohg-);%<<^YTh';Ugf.qF(_
+%,'QIB!f&cu:%XP6FXIGd'.nZ-e;=\m9I,O+V)rN8ZX_eqJ@.fLflT)!=3_/0_>QN!H7hjAdgm3YH7Y=_)pKU9!3`mXrg7?Z^H+V@
+%XiX$"L^4EN&I%)r?<SUL@5]kXCg4NI00"Vi2noYq9tr9[NE-&mD,ts2^_4q'ZXTO,IX`/Pjqa&<7FgR%ms`_>`;o@)V^FXWZZbV*
+%BD%q<qOlVi<-^Xm_*2PQ53U33'kr`o[7@(JUF,D]IdVj>mST8D6,E:ilh@=ar1G-Ze/CNN&jIc]5H#SEFcfH<b"'/,ZSM-)MXuJ[
+%o2-HQ91\Ae;lnn:O_p_U,cs.O`sq7:9D+*R9Q._tl%dJbIF\H#FVHWp6u#&!,'RPt;G<K$*mfl8_b=9eN%4^GaoX;be<nUtR6,KO
+%0=_SXUH,?*q[q!%-M[[N,(K3NN4sdOJ/#kd$Xl5XoXKi3FBt(`Gp1:E3XA.TYLg3+EH]<cG.'I$)%cH8I0pMV4I<e:g&NBpKLmW_
+%g7YGPUCujqAQL,--\9Yh!cbisb`#,16+gBeC<BttKFdfV'9&W_lt3'c)l+'W]P(j'eW"O$.`I9&!(@5HW"C8XJ-#K:E@3$`g^%)?
+%6Z%Q7<"jpm?KS!Q\kCcZ/SIWA#L:"M1@V[T79[Q"cM/^N2S66bkJ^,@IfY>6[$j1f7KgP_nkTQg1,b]#YpIt]R^-*[P&8\b_]3g-
+%4fnbiRqYq]R0A)aIiWTAa/mu^#4@ST46H2WF+D;YiBq5IR"`32]Hb$;Tj0mN2Z`feK[[:jXBK'p3.<>S6n"G?kh2upU:Q+E.HFaf
+%-f4"p^f#uDR8LB$9Bs&OX[psLCTCD1M^:G/!WL6n`L>j&BBe\p>_3Andk]f?gC(Ds(n#.qUBHAp16BOmjY<t7Qie'E18t?AP`(Zh
+%6tIG!r@<-m<05g0r#-Rnnj2jMCssZmUj7:*c;?n]`9I=nJlg*0.-7YG,7!M]@/04:D#h_ZRM9Ph*CO*D]9]ff1Qr'*/s2iBh*RuW
+%O)TEj&O5+@7=DDKUXWpDZ2#o7:$\]_%k7[>H]]DL?5Q>o#J->7VCQDi<QPJ%0(=;F(ifgeI>*eooGgbN#)6ZJ5#YW(`fPL'1c_nY
+%eG4f\b(DTD6p"QYO!do?$02to*)<#t1dPP),I(9u/]uq\Mqi.;0%='G<UIP5g^C05TFef>c+-G_Prjk)F9B(&`PIg,$8#U7]N]Q4
+%O-#[uYeGF<6lhR9&_0mcJ&,nHk14F#KRS:">`o9G`ueP(<&Cr`F@fp[&3=/ecgqON43)e@h<56b]_X>tIpM7J>SNZU?\)"piRcla
+%QA[Odl_/KgpXG@;l+7.>cR/atIPY$(p'rdMlRau1F3A$-m0^,2oEjnAb;A4[ocbj2FRqdE@$$TI?']il$^;*.bW%RId)g&n$^u!;
+%[7f,70Pa/;"T3.g)KX;3cWo,$"sf(P1q\3_KT[ie/Nq1t6nhXnYr24:\QeTnT"EeZ<@IDPCSpgP=Yh984>nZI(RPNB1c)2)GtAk$
+%N5Qa*lm\0G.n-%/P@p&X%QrcQLpWn&C!rDT2>uiU]J.&<UG5$`cUBaqOPKs0er<#uWB$$H`sbK?<!gbu0d's3@1`oFZ(5cO@4`"C
+%&/`2!G*\Our?e'f1[]_;KK6V`P6G^Ml^"cd&IUi1XUGqQAEpk:)pGm8jTAf&Zj;o4P`RoGXK!4eUZ`0::cg=/S^6)]\+ER];)5`s
+%S22(qoT5po%UVWRoNeprW6"ltYWo:4bVu1PQZ>W/L,3;YrRE[tm3D\W6-"P1!KpE*C^ub-1o(YnW+lp!T28AuJ5q`P?oY?nRTn32
+%Q`rJDelaQ11&TOcEjn-73<_H`30k-5@/ts?<FmL9JjEMlQJ`^SJ8SO:?4M%T"0;V3^g7gF\Wg@>9,NQRCC+7F@<95jpE.Sqk0Tak
+%T*jRP1o9\W6Yr32ZPb%r<KrpD&1>&HPD*77d*.AKZ?^aUW<OI8rr!fm@.I/FN\BApo+EacQE?E77H-2bP,"7/0>27gef9Q*2<pZl
+%8,2Va5<8uZ:;kQ=34^FIDTpMi3B9T"2sSND3kAo6DVU`!GB=6(8,-.XhG4=OM>/"L+r,R4f*LF"'E+!ALC]=*j3-Ha4"eLE(@=%5
+%g'MaQqfAa^Z#^3+,D+cXT=rU2pFNHO+S`&ScinMi>+^gbH<BiYcM@@8q=3S:1Hp9WDk"X'D%8\(Eki+,&E(Jk36LHQ.s5i^9kJBd
+%UE:@d7*s?3O7;oMLZ`JiGQP(s6JW0@fgVQOZnn.9dbE"$QQ3b?ZG&.m/m;;5YXSrH-)mBJ21:"@@fVh!3olQU+/iYqV^=(I3P]5l
+%0Zk]CE8iQ:\bXUNJ_EgqiPJR?8a<Z#!(3pOgP^(T@Fik@/Zp[_5pc+!5)"KfI@s0_%C$3ZOTL>-Q`oD=Ua7^G^oAV?>FuH2?Q[&h
+%-d]^T^-V\X(>5f0:!Kb#`ak00IYW1ITmi4n8DIV56k.he''_KOWUBWlS0/G_!!PV5@U32`"#7RBo"41iRO1B2A<i!658slZ-8^C=
+%Lu*6\nAdT]dSCF.#<9U%q!\9H39)IEE>Jk9`d`!&]gs[2oNkM+W_.)QK8?N?))WtCiQq+]6)*/,pJ6F1M'3L.9=5jOQ)TV-@"QpW
+%mW'<#8M7i5jJ7tV13;GMYkjVYs03niX<.;e2#5n*oC:qiWB.UtLX#JC2W!I0rHUL)_#X]=93]0;.A^a]o=/ta&>8J))TR6S,8>o@
+%eKbub)(?9X<7sKZE#oPCo5X^(i-q0WGGk@kjoqDDD5#?kWA2J7e4g9j[]L%2/X'lP!(-^o416:iG"+1>Z/'uAKSg*B#3Z-]GkNCB
+%!t?`BG2J:@I4MV*n7g)E%^%.^!LR_BLk0?NU\ba,4N&A_B]UhOH(Sg2:2'>`a,P`K](riMCbfM\YuO/SpiL?Ng(ANk$r7,kc5:(X
+%_e\mD1$=LQqi:$mTFQ>JV?\Vlo*PA;,L]^?JC3ganAgd2hTr<b0>DPI*DaR#ADfP,n;'#NJgLhE>X/0MV.==SYaH(h&D1^ojBgi3
+%V$_4Q>_<Dd7<:2YJG3llLB0;%]#cb7CF/jF@*HO9s*f"'222%&q:It/ct`EN/bMI=lU/#ELW7sW9sd^P[a0B4%kYGTc+]hHJfe0P
+%+.J6S2C:XF0gE*.IqXgjCnlGq\GjjFrRf3ieFNR34hMN:d##tl/pQ9^BbUm@8c$]@Xitfa#qrbc4ElO++7>Eq[tQG2#k7$"M^?+Q
+%"YV[,Y&&cKXM;M&O^AHLZYBcB3auAED)J!5F\,tgG_3A[PX_@Yg0u]\b=$92GQltU\Vt=j!LIn&Hu3k5\U`D`3[@>FbY=^gaH</!
+%DBII_j'@tfp:iPg%fi._d)5$a_XW"XClEH!c2N]Prnb]of^\pi*WCJrG]V=uBP,RL2i!mJ,MS/n?<O1lT*$f<X:mnWQ_GXmD`[M(
+%%"POrL5n@t.8PcC,<F:[NHuI@1]TI2)*1U2aR4-NPN&a[;#\a!)?TN3\<_T>@DWdh/:1?JMqK+Q"2#grR4EKY)$oi:%)ardqM;^H
+%i3ON1gkVQf+oHWoeW*2[Xu6^&&IV3)^9f'CW-i:\+$ch3@J0<F`(H*-VFLsBUKhP'4qG^lasMGC@hE_*mL48MTq_/'lPe'k<JLpI
+%U&Au1\ktD(.n(QA[S)X@g0N\IW6ol`+gKDr'DObJVjVG-8>qI?6*l3d!1>1&Zq&T.WP-C%%t\4OSdIDjFVQ'!g#C*sY?`RA3J:L]
+%".4Lb#,@_tCHnNI3\%*;\b4Fi83*IX?[)rUj0AE7DJ%An&\G(]"3+M9<I:@L;p<O'!0SPg:a9Qo$Af2#9B?(Q/oETR/iu;.d=Z3;
+%buT[d[M5.f_fn^aMaT:@BW>Sp>nZWGn":oh\'._oKJ=%jp9M3o]g'Bu3EIX!2/m_&BU4!H"6&=p'p<6<6Q-3Q?;&R@\Ph30PO?`6
+%%ln?YB]a7i1"9^BZ+$96J9c4s7ITe/.!4LWA%t7FiAlZ<HKZ)j%dns]VEc'#+(&;3>COsf:U@5WYUu-mYsmVAoV!rI-PtD_/J@Vj
+%bp\)7s'tM'Qg6]8F3uA^45c1#S/d1LHhWKar35EFQ!O$Y,0/H;?+X&I#['\(5QOI"b1#f#QZ(*)[<`IP-&IiHWcO?*$r6H[H]Q?/
+%^7i3'dK!ECi"LYTLh\sh+02!mRVY&b6"J0r-Y']WKN.8:R)c$Q>]'f]P7T3t;AZX9;9Lc"R^&>K6o.1VE-YEH/V1KIXor+4&\'EA
+%WhC%gD/uHU-8_V'Xbb4-7DMKrYtIEslQoeKA[*0'\a"a.[@/Q'-e"'U]a[r1<";+J<3!tPp/GG.bjl'JG+C/d\r+ILb,"Z5k*NCn
+%<9RnGMU9k'2Wm[Oq[3@j;Ml5h9qbU]m4HHpOVjn8C4#P[7:F885``rg@BCkp]f4RNm=$@&Y71LCc@XC`fW8IKSh"d/$>Q\Z8rca)
+%oP,,qF0ZUOlDgkmSg8ga\aH,E-)BcIICE3*HVZa[b3>N6ll^,`@gdo4V:\A;K-ar<e:nk_imC>iD!&C'Cp#J4Wp"3.:olD\1SiIG
+%.SC>+?K,MNe)%8,\HE*OE6H$T_UU4aGZ?`<:sDrF<`0$e[e8<W./K\i<rKIWJg8P<h7>2*CI?dUSZSl\X#uSj:/k;u2L0Qoa,X_2
+%A^2hAO0WjaZ[`oe!;KQYqc+"Rj.n[aN(GKS&1Fi`)oT6gRK7l=\dE@`;2gi%rDJh&WEH&?.Gh*+Ca$#uW(_gK^ls[0@'>.bd:bQ$
+%$3VkJ:e#3VeM+J6cn`'\FfoBoW.Ueh]WkML=t36+-&l?&k$3ZA*_F6/'YBctQ"_kbYeQ;jYiT03l'4lID7(fBbBH682bpMV*:"[.
+%Q$YO2`t"6=X/Oc&;+IK!'THX<<^+I#72`QS_>h:ejn$"f!TLZLN)3&cf"20'(Vkf?#u7\`QP-QATH6r$OI_jYcte'ukZksmcBW4!
+%/":^jCZ#O)0>'+4G&Is^mbg7;pQ^Wd2b#FjU5nu*]8@R?9)LplZ;O@ZAX$U_AI9K^=HI?p*b9q^(QF)?5=-D.hr(mp@<Ui![7'co
+%`BBBtC7s6^.YN0:gip;XLJHik6b*L*ZT.TBLcAC:-k'aFW&d(`rNCn]L&m"ai5=1lS])g:+Bc:-GY#n4Ui%*u4:Na5L?)2^6rQHN
+%WYPB1+k>,!'l/LeCIkk@6H_5/n6.4:g*[(D;2D@$NK'pZ"r(Z"A7mF2BL<-7'tUdR2;=52D3aU-9Fa"WO^"NL)q*1EM<r6XG=-tp
+%!L;LKmG81=hiQ'#L%oRW&ic[#*)[:WBaTWKL+D>?.n#4]9#VD>ieXLP8EdQUr\u6^*)]B=fI'0WPs\0e(&#fo;<Es:F+np]8CKRA
+%oNWR>N(2%Bk/,!WFG4<=kt:7DF+%ZHV(1VI/dbHQg70`:\HsOrNeB:+MDc]Dl^\9BJ6T_I@]oZAXK5[Z(sLct.*/38R=(ih[4Et2
+%/@Qg<!/HbTCeVSE=\^4H>O_iSNQX#&<&mcI#cV;D@d;mfGLi;3BMVMu>(foH^mQfYJ.?*E\=tcpL*YB;[L*Ygo4jSP85"tPg<+F^
+%pU7a?9hE=bP&<V3e[RdlG-#5'P#/Kf8a+#roc,-H@]BhCgS@mrC5WW37X9TMJK>8NMCr,`kn[+(SkN:B6KG;bP%C6drZ9@q#gP1\
+%mT#O4V?p+VE67l$L#4Q_*otOOP,kqjAWujlE/.tO:.:(7893Wt:9[InJ"s8L1XJb##rI6%HVUNX]O'"2FtCO]@'O7s!"Hc[L3`u5
+%pSuh:Mb8g;>X:0J0kJ-]6ke675QbsZ7(^M'k>h1?NIs-%'WU%2)\Ahn,#[*>[l<f+Yu=?B77C*"0[8.R4?4N8cTp%G+=u$j8po2:
+%4;b0fi!>X!#-'ihlngFl,DBo0%e>:g5I7BJ'%"i9&gotG<(kRcTu)<E*;`IR>GRnp1$q3q;=KR?j%&oJ^6p<J'?t&30j$(2P(uWm
+%Q*EFg!/g3VKWNa63b^1c6PflqWBq+3LJj[#Fs_eGDa&\/>>5clC1^`0?*\sJMc(VkROuJDV7`ldON\^`%"hlM.CJ$T[M(#Y1b)(t
+%H!UTIDiBklFA2A+FU(U"#_Bte>]`Nn679\u9u>EV&icP?81;Ni(u1_Y/Q$5i9Qi3OO@51L:A+g_.FC^4"K<nR#E&`mRF=C\n("%&
+%(6i9Na[Il'Q+]J)fm4qb,SLZXk7'k%#TTMYVG\5F5F5lIPp&F:'r,;4bn*jMapDcq;?nk^d9>HNE`)qC0``1$H%ishXrIq8RgfR9
+%^rmmdhLc)^cIK9OZ)q-a$ar[^C_:@2.-BX?iB+[(B&6SN06c]>YfJirj/\)>"2Q/i.KYZ@D@84&j+h$II]4K:&qPhdRqfb#%r`sV
+%gu$IMjA=e'/*Q_LT8H;s@.`bck*L?=^slFB_2>?Gcj-:A&Z^tV/g)rP_'2h<LYN5?n"*P8U-^gQ85l(@[Pc;V*H@f6I&g2:XWS&N
+%R"M*4VA%(Q[M@]4=a(h-MJ"/$V(JXbapC[>J_XXR9UOAOEZhiE<sp#D<>1biL?-JF`24"9VCNCZi(\P-GiG_jSWCl!h/WmhL-:An
+%,k#'Hpd;Bp[MD/R_4*bkJS8#lFY;Xiki&7nRhD8E1l29/VcC-?77A.DF"<.*MNTqq-O6[7Gg^qg(_F3<]T>,I#c08qF0%-<%9^>u
+%Hs\DZ@+EW^#b01LNg$1oQmh*=*7$iTO8TSd!\9'.p"qI`*FN&S2hs(!d3($`PX44439,8knP]q*?6(5s,h0%M`t5'-ELohn<Mo9r
+%g+97Jo>Tb_>EHb*UL/aHR3AG>%tF1G\(q$e#07G&MRThHglLf7::_MR*(Q@*ADr^.TE*%!XZG#A%3lleC'6?_706QD>ccD,gRMF:
+%VJoVW')oNLTi$]O5LCMtL%jYrpq[mY',Tj80C__,bLROP0<9P,b[9;Ia!\`=FNL'7#+13&->cbI"]Ae:SO+k%nUp?f(SGA\-,bAa
+%d7Q5hZg(Pt(,#onN?CD6Wh69?bkm:']6Q.Ng^-hLjZ679[umMn=&q,G?T]AR1dYFn5:+QAAsM60"JSjn1*T[Aclpf+d(g^(.%<]/
+%5/^+2K^#i6@cTPQ'$&2(M+K"W<-J7hM3lW0%tIT@f]/C/,SPsSQG(]l6T/5VY,`Kr#n0/t,@73'1TO(n:JECL?i_pZ+?8Rh%9IS(
+%dB)5?1*ge:%&%7[1Td8R(/QNGFu1&O<LJpnJ`MG1OVR53cn71IAeC^LPLG+_Sc+4o"r&L)R%^'WF/\Yg`$TS@71U^iWC[5rQNkOG
+%$YFL@o?+%e'&Y&0?%b"@\dO&/&k&j)eHLr"dVY[o%$P[?P7]*_AYbD,+3aYUUrg,VkgXn)<#aYe6g6qO_`cq[G0A?Hf,_rO+=q-*
+%bY`-]h'&52"noQd&:V+.YWlj;+:]`C\.gI:2I,7,c*4Wr7[n4u*ET[eZs0H%":$.jjk<Ba3cAT_=161h1[T%lI0eihm<&$SauqYo
+%moJkrnLZf7D21'V?gJq1Q=>`pQLD?1Qr,Krn$s[UZY0-GljSq@6'?%/PrjaF'G2rW/he]gT7FSO1SP5Hi)=bc+<?RY]EC%rRpaZq
+%!p:ET2*sIOb`)TtJ1R6n-mq\2]@!F*L>5;MCF!,X3ah#.R]^n*YXE2u4>9-@-:;LGJjJ>qLK<*/X[::hSg6Bn0G;dW:bmJ6<#=qa
+%BL^$Ga\N+^OWB`Q"@]qF'W48QALEiJ^oYD1%a<Q+MB.AMSQ.b=KN]48B#3pk/SLd+m[(]7;Hd7j7aY]L()\,BeX+D>-70`t`Hd2+
+%Yua=?7WI+7;mAtO@9OT)g\atXTF3/Y-Kt.+..J.i''V7Xap^Qn"8L+J<+cBcZO[%>!=Q$fMFRB9'rY#2ZC8mk&=Zo%^/cn"!0eh[
+%22RirJSru;K0]l-1]C-bH8N.A\Q.loC('`Ll<&^t,QWNW+W$#hb%f./)Q,g=ag3mZ!k;c8`>L4'@XZ2R"2*fM0JJS1=@B96aBV=H
+%MjU:U0L8348@l2U/`]kHPdBG4DW#YO@'$KG=]5E#Z^27t$:Cf!9:W8<U(O`Ai5`Xq=QON6@?;+lWQo<7N'pZi9Elk)+^&qo%-UuV
+%l9!NVS#]`3fU87cd(*>"+jF`VjL,fU_1M35Un!aFGE-^u:3a41EWh:3"BSTtB=LTu_!.8.IKF/$dp'#EV*fF*?L_$CR.;4JfnkeH
+%7(<>Ua<[hV9Fjp"3f5C^mW3g&'VN,:f'<-qE7WojFS-B.I]WAVb_2Z]0fD3"L<;[jC5'^"c5A4m'uUCf6E=f)BP1,H+N;pSM[W7@
+%N/Eq&'K?u]65e<I=Y6hO;;.gsHkCBA>"5?7`8jek;edG*ShV'(?3?LLKLdh9aIT2+1:Sa$&55UsK[PB,'e"/JLt!6QM<9-,r/Rbl
+%I,eC*dQg9QnRS%e`&t%F@L^OlX&->MXDS2l[fY,"!;hK^^f@o&XC<AfMQhpLO/#XjFeTAR7519bfLLA.K+g+]j!_eR>8D`Ak67]0
+%pW99V:/H\6=?7YmLEkeh8`\!UD\q"<kO*E\_aQ7KdsIe@/!iN3c`0fAfqe8.D147>2APYqL-W'qa?8QBV$sf5+J)u!b6GbI[WN6s
+%mOU)0K'&n\0$H1tX/Q%ScR[r^nIU>dZN18nN3JkRGY&5Mhb2n*,Gn6C^!2ToZZk\EdmQP:iT0L:>EUpF+q(W8'F[IMaeU[H*>lac
+%H,#_[o?:(R1QC6i"%bMDJe9lmiT<IAhEi\,!G!:+T2r\V;Wp:fDiT$l6pJ8e"RHkM/c$RDOYn/G\KV\$?^-<=D:*tC+H:;??JATu
+%IrO&,A15]5R=9mR(Fts;:l'[d&GaL5!QkR*JP_f')bi7HI_Ob,dq[hpU@=CL28.4l;L/G28>`B),7:FZ,/r"$=&mV*1+D^#e-0!1
+%Y:*hDk!J"?)!\I.!9+CERqVo!o%APlUdjSM19<B"?'4'I:FIh]cb7RFm/V9[<!sH;Lo<?@-'sM_(%ub^ep90GR:$C\6Q]1],[&\3
+%oq:TVR>(<*)OR'(M%OJPMdZMc$A^2@2K4@P0ZdN^8Zko8I#bnH33^ML'DEqtAI1hJ]0g&aI1kFY]gdCMMFRkP.:$'tX;P#H&?].2
+%dNifKBqV-C+c2E>Gst[B'hT1k'k?]+F7qQKY9ec+7*?Rsm@9=G,n*GrfE.hXK;^,?mHR[knmj`U#o)Ys+3H6A!Ac`#H[*aK=\Ckr
+%EbgjMN,_:t,-=2H0$BE!#0K`l$mgMd4".H)qpS??X\Sk#j1MPaCScpak/UiuQcrBrJUQ.?W&-jcRBg#(fjnfW<%H3Qs6?\!X\m:-
+%%7*:9$6K""ds;qkr=1je\c09/nu5h+<+SKo.EAA(X[G`-$Jsk*TbjhO1)#+3b\I@L"(eXs!7>k[o[#CA'PcmlNY>Y\$2ME'L!fOT
+%2H'`Z@E*YsMXepWML\6uJD2D:E/I=l]oqLsipVN%GBKcL$QtNOWtMDc=3UDs6kM@&.#Sh5GbsDR'2%NN6P9i#hFGNsKs^?+3(%M8
+%]MJfO>)@[O6Z(eDZNtV,?]1Cc.S@rB@E<s6V4A5A"3g[`.U88@"6Z#XU&h\>Tsth'Xb9h#D%aoR'fJcbnX?9r0Zb[.'&:f$a/MP"
+%-"[d0Vq*D0h]*>skSHFt6MJ6BMts)e#m)5qUPNYoF[uT;P(Xo.W1(hU^B"<XnBtM9.sRr<5V^`"6!bHVKF*OQL14?IS!@Fl,YR0>
+%<a.Lp;8kD=Q]/W$Te\2)cD?(#l;#c50OK+an52(Y&iRZ&fY^-7^(/kl3f09b;6[>GkU9hm`AP$((E4_IENp`>Jsob^VPjSsYS"t`
+%4Agd=1>G-`[F,@i0I!Pt9HLgI*/[MSfsELW47Rq@p'^X]k2o+^5Vk.*m'Wo=7k-ef8aJAG[a?Ap>@TR4=LVH8P%h&"]'^!A@JZH#
+%Z19iN[-0deB-mr^AHil/!'NfA?lA*464^A-HB[lHYEf).<='b5'Ak<'/q7dNHTn0EDUS_l!`D^uV)TnX1Y%mmK[ZWbZ!=?@a4>Eb
+%-SDH5-I.Vm&70$kEgJ9BSuJ1;?0]aY;.4G=I30CT+><Y>fS258!Q!7h[i([21+Fe;bm["e=)jq^_G9]LY-#]4/2eFKOBKC2G[9Yq
+%E5=D1j/Jca'I9Hi(0^m9CLQs:2NDN.%Pgr1)ur\i#:T)_e^pYA(hqTqJZj4=E)Be1o0&OZBjcXXHU-H$6M*Dd"Wu0JY>C4^d#nnG
+%bf<uO6X'+*JbkIEI7VSr6K(+;HQNm<%k6S[D"@a8qB:Fg3naI^(k5)M^Ikt"T]R>Zpob8.%uUMub6[I"*-eWt&QAaA)-)C425l4t
+%=%#@cpU,!hE.*@jV7!T:ZhLDMUP5gl4.^M2<L?M,-F=p?KO/=EV1%`K/^.P%k!aSP^,/dl?=J0B)uS6>[=jOd"=5>1H#QfKMK,&9
+%$qNj%e/082/pjF.=LO[;+a1!t..E>%;DCEcS[-,8"thm]K:Y)g8;[IN<fi>pcl(&tBK7YZ;OH=sUaD:'HQ,7\6;^"nhA&asKir[l
+%_E=W0?D2Nh9Q8?jiNp[]GG\[q0V3oTfZag:`uCr[#-"9*&\jYBZdfQm)Yc$.d:V3LnhfX((\=iq\uo`J?-d2'DeVmrVo9Tg-$r>E
+%c8NBA?h051huUoDKLT8O0(1dSQQ)W$l3P<-E/.2S]gZBd/2aHJ]ACFG"u,c9Yo=\1iF*eOR#(Q,P:9R%GD<ge(8RZ0pE6Y87f`34
+%'bA+H6eM8s7"0Z`+2I<b#lPJlrrD[U9Fhsc&r[G5<g"-I&fHEQ%kHlV50_P(7M]!cPscHmAZr^f!Y$tm%NE085<VRu3gr8E+.M;_
+%+FOj<mlir54V^qM%Bn&C8m8XdA+5e+Ya;#e[n69kBWb>"5j"c;E-2P1/&/9cS,e3_iW[HJ>pOCl)AjF(q?7go'(tX)&E3'_a[X1T
+%Um2Xk@CjoA0kr"kC*hhRR$om+iu4eBXX/a^'?Pu#B>aAKPuKXF0ek\g-n3)-<KO[,V1p@odNKnraMLLN'f>-U44pIR:#JlgPD'$f
+%Y@^cSWpthi3&45XQ9sbN?Pd7N_;.4FOXmN-Q<7[m="^<f/]^-W3DDh/b0[I4O]>_?Br)J<'j%\9f^MG>[]0kf<G,7o:oZEJk16PM
+%&_:R?_rqpHN`n<d($S51@9oilc\]"GO>e:?nV!Rq)15>b/C',nRdfnrh'&I^b+i:jebibGVSP\niZ+)9Ms>mn6X8sq/gl4,6c*aQ
+%/Hg-j2]'A!"#B%*Etb[ac2RK.PI-YmHDTV0%d>\%FI8IWb[Ol"GMUT(*Tk_/ZY`c!F,)cg_d)*,]\lWsnM&^B,r9g2KmB'M]TO"h
+%gkbdVAD/RG*9!3\r$F;4VhH9b;^KJ5Acn?Hq["\jlJs(<Rj^SUMi.W%#PM`GMWcsfm,HDu//pjZBI(gk"q\r',7t"qE-5bk$pnd.
+%>;0Fkk."lk$)Af_pa"<EZ,egEUc.+oBi?<u,q2J]X(7AqX#j6(:is].WsMfq1AFZ&6#A\k_&`+.Y%AIZ1QhBPQIbYsoH#/PY7Yd;
+%#pn*O.F1?rU'NBF%Vj$@QhjHd)i.<jnjO.714C_:D1+jE%K!\4fc9ZF33\@Yj;DN"p=<W)f+&'2'0-B0S-6#9&aCl&HYGB#?83i1
+%"5!de=/H-tOpG*Ye3KFPXsS`9n](1XB<\Z/&[.e/PI-A7>fY?tMBXA]T%&/I?AW`ek[X^[:H7:/c5^#Q[sHK.oGOWI&UGGaT?.<Q
+%Y4*)8\;Z3Ea6UitUVsuWMW$60dGd24<k'ZnFTK_"T[_fP"X@(#4`L:`MJGY/@]fUL`F\C?2.-]ZN_2l<fSm>,6seW@W_CQC85F$+
+%TU:o*H,0uhC2E6`>,bU\36`Kg-"''qBVhnX#;gk;4Z0%Scub$CLZjWa5aII.kTdV6#h^7&,qbgA50sZ$,dk3Y8)Sc/?j,O46N5Tb
+%"'/;+#"]%M#n"R\L1/fR+@Tb3Xtp/]_6uh\8e_EEGHdgKQ66Jk1;V)=jdef!/#81-qSs>Na<@\HOFV?dK0R<?O+@2H*.VMfmqJXB
+%/rN[fo`MoQ$Xo.%0[+B9c%G4pL!C+p74)URTVKsbgfq]/rcaFRoLd(oW$&B)R!]^%rRhQ_Z3V=;g8qH1i#IoF7IYVE[[AR<Ze@r`
+%9GYj%M-SIuqZlfUE?MhhWLHFgaOtMF,Q.'M<dBL9^'h<0#("=c#:,U7GoD8jZpU'-Vnt9Lj@Ag.;@5g!INU9k9pV.Y1sHm'f97Kb
+%M%qNi(rLHT+Ud\!YBI]u]?b41&=s*Lk*:h?pI?&$A`SfKG=,!7Ub,>]Yp9]Z<2@6:<<9I%<o@aKo(=F>8$Et^.nh_["d)Fj#65(2
+%E)pKsnEeUI-0XSSHg$Q(F9Q>@!+h5<gFGPX+Xh^D+('Sf%q4]i!;d,UI0CHPK[?p<m8<h!Z5SHr0TbLOYlA)INOIO^J*iMYP9kdS
+%6Sm&[',SV:KDhP3a_H3@cIqOB-2gu"3dGguM9%1%ZgZSOe/n.[lt7$/(Nbf9Y7r*#bUl>ddO<`$`CVcCUbHQYf0tc'dFF4O`C3[*
+%0rru=@gD\HIn1t[c(CHcY>,t>3SW/EE0^^^,3^j3K8H)rk71`CY1]#I`8e?6*,cfY&DrS=(:]X,ITSNHOE;,B2E0Q\.td]l%fA0M
+%LD:YYT=ka"WK=mhi`8of;uAo;UNYFoJMPAQkl[4?qck)-PVpr`=&'W+$aP"qr1\X8:A3\6QQAQ)(:,qd4E").\j3[N"?%<)!^h,+
+%"OnuNW[J'iCc_2mc5R[(Ji^9r&B==\[YBRK`$"FS@LUTa"XeXm^,.AJiOk06!U1*t109g3iP@Z.6dd'F@/rEXaQghNW%8(IC/P!C
+%r<=p8P<:Moo48\YWucNZC8ZJHM^Y^3TWmSJI5^hILd3[16'eadTt%mS]S!5"o(n-Q(qiu;,$Y5MXa2\&&;7nr#[4Hl/Jnh5N[Gk>
+%.:Y&P7&u&p1"\BeSS8/(:+LlKk)(9(*[68q@^0HW5P'J)/`d?4O5b=1,#nGZ<hUC/=#0OZ-dZTT-R6:aH&Il'WW3ZNJda@XH/;NU
+%!s0<B(l`$IVh0`R3.aMH1*beknU0CdZ$Gj,3[5?6@/9.:<'%HF4PC@Y2FP*X,2rgj\KT79'pCSlmgYD.X/Nf7JoHN'>fA!!0T8B+
+%itrXo6rB!7Q7LV3+c^W"p`+oR=)as&`9@UiFb"!C@U<.*YsU)0&9YUBclJj+#IrY+N:71GG_eI'Tp1=gjtZRT"XcIO<"IC..nK%N
+%Wd=pL]n-t@ilVK3oG+b0&D97c^^guVVlSaV!D7,2dDbWT,j?ba2Ec-qE1#SA?HLS5VK33p^/bocp63UQBkJq6C;XSj@G9I.MVKnV
+%DO>[XP,($1kSpDuXeZ9+U_N6n*j-b;NY37cWK1h/P/EO,EUMp\Rc]&gk:lRM,u&KK;EDr`>tIs8A[DqG?WYZdLFKXKjP,qfh-j4M
+%+T6L1<HoglGaO#oR]JWQK/0Bm18q@](O"q'3:Ou_js96YMT(a:WNU@a*=3HMk[pFW/ELYXSuQd4k1Ks@`]fa-gf7cP/`.,UX7*(=
+%cm!Hr&&:)kliuRRL9eM4"[lg]:sRk<XoM#<]V#l$I>A]8B;gpNMKpMS!K0JsNfgFB^sNRNAskId<)m<B_j-*`7)]SuGFnF[&%I6Y
+%5eY'\js\Z2?;=PjU5Pcm9R=BM,Ff`_49L3i=`g8%B4WPdL+&?l!Ya#+HJTOV@%;[41kKGl*"oqsmZr,W:r]\>J'0hF_&Eu7T&JbH
+%)\6;a)hq(tW]LV89^(:^<EF&5DP`;p=3Ep*=s>-K-49hT(8c&3p=E&ff'sVsk8rD*,a/X(*fq'!PSW%<a0TF/fW+d"_TZt_XOPAk
+%lj]gO=LaGR8XBm,l)J^$d/"r9RZ_G`ZU3t)PKGW_6MM*X]cgq(h-joj^UGDb/2S;^!l5`P(*c\FJ3#0e)bk9ZA@7dC1]dp3<AO\t
+%&dR>b3"unr#+1X6XRs1T(tD:ep/)S>itVuk>'5jVL.K-''$66'>kbsA6DS"ZLqWB3dQGA<aZ,g[m?*C''sloJ*a5.Q$n)u4/);`@
+%(t]qGBTrg+1j#E+*&t5dQ#phSP>?7FH`Kq;6I]dEZ6c?:`TH!VNjItb<QS&fKM,*LS6RiaVJ?tH%2<Uj+UZUEiIr<_@0Gifa>9NN
+%SAp&I:u:IsP>m<U9UT&uYG,%D)0q`k.C)I+]?)\/$%#MVHT)G'-JS6/[nlS!b-c%t7@IUidOM4hMG1Sf+?%JOfcS$9Pa^qCC($gW
+%77]:X4dk'%A/)2h((MZ7C=#ac:3/&p(snd2?r_U\n:2E'5U95j>+m\/dOAW(HhEJ"o;<?uVdQ4K&'>8Hl++G-JP\t>BL#_aPLY>'
+%ikl[0_*-Hs"9'U2U#"mH)R;E+'0oPCOs/ILN@G*0"k7tIJ[I+S$^J?::YKrfib#`M;0hSuOU3hn#K17G\mh70`6k6u=7H_j*).4u
+%<LCk.Ttk*hE#;tf#tEK7m[Z+VE@*[YbS;Z'Ni_hLK).0bI3n3m1o0tI\R/H@OaE6h7bTuOHH"go'Y2a-OYd1f'9J3P!OUM(0%cEO
+%\-3$aokc"[1']XS8Tn7"CJM:%UJpFY-J:cA5A4).2D/SGlW"LC.!0'\[V\S*2C*no&BDK]T^?gN@Fsr=g'nqhf%KVKb^'@$^6K9%
+%9"90YfO!8,_c&<Q:W&AT324<s]LLJ]7dN(.!8O=W*0I)bS.5Qm%/D,KQmRQh'LN(_&_Fu/0?0AHA&u*`a39)=OKrGT&d^jVRfUd3
+%DCNGjkZ*T9SjjKQSm/T0R0:gqKS+8cjb?mL9LdXZhA%oJ^j;=I"Vk,E>U`$@PnaLh+^<-Of4BX<B#kdp_CRKRTrI/gbJr0q($)&b
+%"(KrD3+2I)b!!V:.h-J.aH;368h6-!6[GUQOjf]hBuCK=UleiSS/TgSNJOZ:8?^+=/soK9ab)Bl`(hT2QAAuaW@@OG%JEV;U_2du
+%r%jKbM3;e3gnU;ZWYa(`>f;r,`ik*@PC_.)+c\pUr#YWT;?&KmPb&l.lMg2i,".lt6C^:Ej[VEXg6;dKPo;+BD!Y1.3VdKe[TRXD
+%c?0A*^'9EOZpNM6:J/WR]?6O!jOY;*E=H$^p9"5*FRgrAILK-#LIpbq7RHuY2tr^NY#P>UR1G%E%N?F3@+a/kYQj/!UVb8;4<5j*
+%4QQ,OY^``"3EK,]._JjTpI`G#=+jbZ"/:m$RO3Y,@AG;I;Cn,?)Iu9,^h9W6>,XGc[9;(Ci2U=g\\UhbZp+27";hPNSnkI@e$p%?
+%TOcPEH)[',<5YG1.g<)1\Yc-te7&>k[:I#Z$LPj`8F-Z2r2Rt\(qisC>U0lU<-8coAeBW`]P-7+P$qOOUisr='B$Yl<E&oZV$e[7
+%A6,JM&88/X=Nt;f4RC&"66n,G!8^AKY$B>+CjCkk&5[U)K).eAl.JlV:i/-n@WE6[#l_OE-=p%XS:55T4WiNB.Ktq,]BJA`_!+Tl
+%T2d4r3IY*J:jBUGr!h9SNo5\k(@4_XCnp<rYf:5<[9N^C5rdOEY4B`>=<WbWFQfh>Y&b)!JP`VS]&.TGB<-j/-+T[cnLYnNi#_Ft
+%6ffPfaU&hs"UR%k6Tkuo-Qfhug'C_8cp//T'uNsl&r?^qB`haKT[Oo91!FflRfHG5Oo\[je^I97A7gPU@Z:k-8=VCYfbb?BXAF,"
+%=?_Im+=kqb6^j,P8s04#aXZ>fLn%npiipJuE"=nNhR3H1_JkDB2WMs"?.n;Vj"NSV`@dc.DPk%Ze_o=H2stXK&!"Qck_rUjG&I++
+%*N,bL-S&Rjf82tia?cN8]eu73&Z*@+HsrSE@8QQ9=<2IZP30"6k-.&4?7jLdlE<t&d]_5/A*/*9TR7MCfPMAR^KD_D#,3i_AV3ZR
+%\"lV5fbO?a^Z2$?HW,Z[ccSV_nu*"i^Qk^;s&g@+^h]#(pg"sk!(1=+W)sI.OFb"6DB3_HeI\SpY4-B`%/8#N?L2Q,fp19t_`G3C
+%MRMR)\'"_(J)@>P/eChM=la[RoTB6gHtnJ_TE.N6'1UN%XgCGpc@i41/@&`\>bD=jF\8ihK$fGgieUDgN\Xb_<Y>3/;h4KGZ3:Am
+%a-iAek/_kb(!BB_'t^G_:hIVW$M$oEW!uUcj$JY*7iW?;Zh4D7V]^,>UHAnAbXS6b3qr)lQhJ%=p"AX"L(ggQBh=+H8<!DfeGqT5
+%F[F[!4Ii".M;4Tm#L_$/WAhgB*@lda6h69M9?8TV#ajeD`K'3Oc23;J%E^gc\G-n'Je$]W.*-G+&SNU_&h8!@j`ISpUu@^\S^67t
+%?9@i?$Y!4/HWY=cISQ-@.dg@f*`dY1e:q>0,JQ^l0Oeu<OZcYdjHop9c;QUW!$]_i;p,MncB)^PKp$)&^1U9KISedJD[,ZW[eBIh
+%Q&7HLQkhT2?4$P.P<f1`>3*VBcqc:n,[Lg<S6i*P#oZeRVoR[*fm_0&_1Z)TA!WHO?in:^:]dgfnj,(`$;J(.\i:q(XJCi+G_F>4
+%driO%20,H($dtCrBt-A34)'shA4T3G,VE4C3Do+%Zf;sa#Z>'CAW(MX'Xbn>2[p3Q"6h2D`@F$jEL3]:<@=ORV:;f=V.HYt['5G<
+%<#60n1aqkeH")"3NB(QNfOoq422"W.RVBpn',E%_?=E_*Yra.'E%+]9[,rFVodIQs%>*;-A#:O,3@l'\9;+u;p(2:I7L.kQfTc%n
+%A@$=dnCa=""@\7cC''KO+4lAbX;:GA>'Z4*-ja$-Cr3$j&G9^/7S0LkC8Rj0)dW'P/$NDF6Y*W-nHl'f6O-_=^ce>.n+?28UJIZt
+%$0jq`9@_0(\al=%?J`AbCmT9o=+/de2cmS/#=Lm'b+TPrU,=Eq+mIA]6.5`U)'5^+P;bIsUXQl%n;!@Kn2f77HJ\VY&Dg,h;re9/
+%K[l?F;%L"-Qn*OK4`j`?\OQ#adkt5,-ml1@Oh/T13b2N%AS<*i\INml7i\d$51q[^lj?Cf?\AO7=X6=PZcu)%,37LcEW)?7kWt6u
+%=$!7$R^8<N:pI70CF*[*X;3[SbY$F$'2=[h1p]b-3AT:42]r^V6,:$":!Fl8,A=cf$DAg6P2.ZWGO4e*"r'A?5GkF[ZnlZ?P'@I*
+%Qo-"f'n`?6Ch\:'o8S?kb#=ER*G'^BYO27``*V+.1!G\=JM5/M=o&,_1(bXSA[;c]`cEV`js;e$UdJ]ZfAs`nV[6R4;a-TF;+q6X
+%1Z\tEVEm)XRK$>&OK:=T-daD4rQpGij;A;-J\F;e%?Y".p&a\Lk,e'++\m4'A2gn_fBM`TauU=/8LPWbdIfnFPb9o*s%SiFr2'-J
+%BLti%:Cdm`ArmbP8]AmWEQUBoHC7S3`h,M-Ci-&?='hB/TJGVs4roimS?DFl%#J;FUbLgi]#0-33tt:B"!b7N+YD.aKp2H58gWJ*
+%c/N/[@qQ@p8H:]TGg&k&Z_B/N!K.[O5cELn,WHJk-gE[H9Ok73_6kK7UO(A+_UC#(W^l``LP;r+MIc>9k6ZT+53$s:PVIlHWk4o$
+%Q]i^qVh.-O`p`/f15?iAo`NRiXL(gJ[Z'sL*A9Cf_-:N"[0E.4bH$?@2h8/00FgMi-j&0=77KqSB(kHP[q``5k?NQ=U)Y:"SdBs*
+%;T/<01NI,^>VQmu"IUkk8('XZ[GEld.n=?3.UC\\`0RIuV%Y2VkB`,&Fri)<+Lq$AYJ@M8>,7bH3W,-'+]`3O!lpEiHq:43Q.uIK
+%:PK\]4WNX;qX7JsMfR"oT+*&e?ncS$,Bn"O/)Lh@]r(r1/e@&-Y#Gsr5<p7Q"-BY^:8;+CkUVo.q5&j?e3>p.ot)BbqtNKLI.NLm
+%h]ui6ZBZhN1W.`PR#Ob9V"@mBE+=pT>"R7E,_!6@WEh)Hk-CcgM%2Uu*e_]1=b$`&#[OBAO97TKWN6(+P"Ljg2))"D>JM4,q1Tke
+%BVG#9PSupl#F6:PTEnssgP!LJjV+I3BWi%(M&8pUciLHI&`oOI);*2m=;g4o.74k)SLcIckIQOeYVcG^"dH]#7`>Q-cP_FW;W:Pf
+%J1+ad+&eiu"TJ[/f<2:9<;44MHQYl\c`L.Y*Rl%a9m^NbIP!p9QqP1l8S(_@AYhT68hHB<h3VQ(R$DDAalZRe"?DIeck15A&B.@s
+%_kZ\NR6%"UMMO_OPmL=S'UYu+'h1aEIJi#0l(omF&'?_g$9G:'Ii9,\)O?Uk.6f[@<Ac=B[8I!?==e5i<bnN7f<AN3Ycu`ZF(!os
+%(qL[kAf\U>`=#Ko=jIEL%j`\NTe^>[]ZBY>d/Z?JW=L9@S&#_D*%HTK#pE)f)IaG51+3o(?ce1J,u`t,rXEKgc6@ttc`mofm&]9g
+%,h*69G#0HGc2d-2,`S<5LslD\$8`C_:AYh#nu.AsKAj,RU1,Y7a+!e]Ac%:L($OhbPg$Ambcj'dEJBTc=l&ks>7]/<U7666pc/J6
+%%cO36d*j.3FU2Zo(G9hk_INZjqfGN_42-,>'qTdA)S6#Ee2hl$5k?"g%NF45W%L10n"4T4Zh4+T0Al@$rpoWdZM`X`i+Kh$fCn;j
+%?bcO3mG$7Mr:0-uRu?$:&cVXdYF!jb`'=:rlg(mXMjGeB4]1`6oL=>\s5u&mobi,"Zf[T;pg<tarj.Ns4%Ug748D,@f:BRMYQ'TQ
+%f!Kaf(t`FEg,t:"/4El3>;,-RgR$jEY.5L$cis&VS7k8e5[sLOIHQFgQ^m=89hiX%s.];KMa7_(qWshp\u."s'K\(EeD?TIYsZ/-
+%#mS+?Z'/E/qF+t<mm<jWCT>$?]1a,7QB1fATBjflJKReH"@:*LQ>@RV<<@Y$e1\qKZ/Fp7g7\.@h^*.tZ.2JVUhDms=o2rEAgHd[
+%0\Q].C]^S6$cZ5nRBZTs;o2pG2BWns8)'82QicqeKo4.5\WpP8L"iW-gk.&r>0oVSFE3`o&o5lZRWO"l:(JpQ7$!URQ+h?8a&^$.
+%_W$ff+-S$ld<;Rl:::EDa$C6->LuL?'4r(aT.T*3VsgO<ZrdL?;C3sYN3`WnG*fO+W?p9@Y1Y/Vq(9f$WOQBRY:5#0MldZ7#A!6W
+%^TRp^2Ip5ffY1X,d8$(hLsANnIrj6"nFnN2P@4\M4Vd3jq"dV%b"tUg99oo:I^1kYIc&O-.E94\0d5r;8T$YOC]^rMo!n30AGc6H
+%<8Fp&e>5[-8d1*L?=Ok@&n',4Bu\:hL-eeC'Q.?I(tcK@oW4-4<qX0\###Yr'_PRI0_:"lbDZ+a`0pa"H/Adp+lLE7-MI7`H\':,
+%6nF:f1:X25>J=_^%YIo?*\/0?pEJAY#`]#-iglR4f\OZnjOUZ?qW`fEn)Ok4j]1BZmA#O,[XfZ22%43nO:?uHhDB5*N0hj8,F++m
+%jj&&bX03CWF>sAIW@9E$e2n9NIhoLsE@YcTS+C/<XI\JBOgsX%'ppoLKh=3eSbA+*H<ZR]^'n.mPktR#Cm*N2ouUag_A1!hNffrt
+%lq,rnrU'^=ARS1B(/"_#OK_#[AFu'tP#PO14`Ga2d&mro[?DrSX92?ME[aa"K-P4d<31=4g@T\cOjH$KN!Y?iMTD[F"?;#)WMehI
+%`],fJ%]#uL%M<IHBB'UKeV;k=)kCI\jrO['=;&lKKQnd&S?tTA&1_o1R._mq-C_jl6s+ie3Nuam&o3@f^B+m["YjlRp6fQp9rJ7b
+%E#4Kj;9KCN<n8Q0<[#t,6.0uHF%m`?%rIaSd-&CBJ"DO7P"C.<0&b0a+JL]C,](@FEX=3/138ChG/j:E;4E+%>tGn6b%oW+-j\Ai
+%E&0(h=i)V@^R(b+Y_cYts5=?5>UiJr7K$R%gX,8>q!]4T-!-dBG&^3#+uhIMKo/7@!O"cjFh?e)d]Sh1;AT,-\%uVD)2Vj[McWB$
+%9S"Qq78%A,*P7)q([%%TJEeS*'K,I9Kqp>9Di:3\BMW:0CBI-1&bt,%`!OJV7LT[P\1*#`KRO4YX<cA%*YN7MNeAIe_N(@i'nd8-
+%/Jpa,"XN_/Rg08p`&-&L-#p5Spp=SV!1P,$r-Z+J'C_>l1"["_X-61+%*=6cK`+9!-EIF:KB0Mi<m\)?']mo3)e34ESP:p/eB-2\
+%:'AUTnksU?H0kb0mdVm;NPi3(.#p^QAo"'l%ag^mXPQTiV#;@-CLeS&<Iqu*aAO,H=CdspkY+8L%DHm8JtI"s9JN2k,+>Dg$YAf$
+%kC0st;pSiHF=_^-=$A#c5.fRV=op#de/];m>7PgX#OBCTcUg?g))*rh$0U#I60t=?:c5i`K#8V9:iR<FM`WSpnE8MUQ6KlZ.\_Ks
+%AP\4)-pgY:=WUZX/)5]a7&]g]+Ah5A`I4l8`scZ*Co&^MZ1)-ZFU@>uJgd"'Z9m0M82#$_3n"@u[r8/IRpup@C"=+!PelLQ`g1_E
+%2T0iF^lrDYUUe.T:sMBb)GFTJO&1GY.Fa'^=LUPJ8arUQRdOE,P=dqoBZ1`#EsNN0?B@K?P7k1DLS<\XUu6pT:[t5/f80>b$Ag00
+%N.*/fXb+beg/i&e1XYEiQ%EcqDCB.pGu`PqgiFkNJ$7r8=LXR<A<Z-Bo+S,?9a1\2XX[F7\@bFOG23=@PPC@t?AF8-0'mM@m>aS$
+%DI>Y83-<)XL8RG_>EBE*=qk?L/e@'[>F;Nk(-AWM/L1,?]%'NNC^p"KkV9p[12(WO"K:`$9IFeP8Kb;#2f^LoWkVL`<_F*c=K))-
+%(ZHD34i`(TSFDgWV0^X^P+ie[`,(o^L+E&[KZ)I0&Xk9(=;+:EclUX)NH5KRL9Zk%H#;Zkb-p'4LkrFm`'s,WLdkO(TBi2L%B+T5
+%Ket$U<b469RI,U%M'FX'!KE'[+Q6U.FI!Aj(Fnj"""FVg&;63RAfS)0@!ad_ZBU0Tf[OHg#BJm2JG*Jh`Y%DKhOItGEG>_n"%n?<
+%m+WYQ$$s3S"IQ&E+>QFG!3L=jHM#KTJ$;@TXj.Fu@kuD]`a@q6:%k8]eJ/gjc&F>&X'&/a"9s*e,nXklM;KAd+(;K/oImdbnXdr.
+%74<sUTsHW:/tNFJKZTo1"sF:h%6/XmL#2>m(L&Sf@673WcIIWN1C%RgPpm"XL>j6]nrf=qX'&?3lTn]@5F0R<NKP>M:X<#/g9Z`L
+%W)6RACfSB@ff;?,eRC=&iTr9,`dli46'Q@``ENF%_G3RP%Ohc7hpm\kg'6&g]rkX,lnGm/D.on^_dJ?JTas3@`<0:[/JiPjWamK7
+%&1@p,No<UhE%Qh,p#((O&E6nrQWfqr34\ct=LOYu8rnjKJoN_*Zkl$Jn,ah?PB7s\ILIO2Tl1mo:?D"OTCaZQ$ssc44')su37U=d
+%SgEMJ1,)/#BJ!@2icgZJ]^Y*`H]<`BFjdX]eFR[p?>,+Xh8N^;p/`_E:a/]K^(JKB)]gp'4)R!k<V8f!h1W8h>G[Ya%U^b8-NL<#
+%DWWfD3jJFfR0uX%F`9@*q3aedf2K-@W8snlQ5$1To_-_I3]qFE5<kbj9sr"?`TDeajs;AN!\/91/^M'#`OHLc%poH>.*>Z=6u\c\
+%akR/Y0B\7l[Nsd'nK"I!njtfn=Z?R5hGf]]_'OoK*+$HWErTm?RSVkBjg`@*HBkcmPP^nM(`nG[cS59klM2Z6Xq7gAnZmG8P[k`U
+%C/B.c.<3-r46B8b,p0DQ%8[/Kiamf17K`VRJuPKc!m_,e(mBhRn]i$YdOH/c`>9eZk#;^U=D1A?7XjUDS$S&9iGO:>/^e??W-%_7
+%1\-?fI57ppllY`4S*;XN)hNaLG>Rfuo[c2$L63dgIYY:[DUNV]fP-Op$%h9KOKb2(D1t,b)LT%V7+_PTE`X7C`0n?%N!7NNV2[\K
+%keO9<=9UT1OIBd18Mn6N/*R&i\sUu^:+p+DF(2II'1s-2MdjsXIOf9;$>aCNa)`#gdN?qT;5&hd]`d\f=edma!H2He)f"ngFe$X9
+%JPM=[.)]SS8qj:o3=LjEiR+[21XY:3D'`Ygg4tFj#<sal1!SCEj/I="1^b^pb,9FVjauSI0&fePnaTKOQfk>6",s%=%ArbJ,kTFr
+%6%@,o?LUk`i]Pg9-q=N7`<e\`%JLHt'<)o-"RD9m0'GS.Qpu3t$<8C(O&""@&IR6.c.P;!@-J5ff1\l4,]l6.ge8hD<9t;nJXoUM
+%lND1Pk6i"oLNp8`W0t.+l=)9d4[8fp1e&_IcH^!EXeT1Ii+u&OQn%c&k0?i5#ITKJV)DIA+%1OGUg2N?cj-Mj1I46^oo=ht#t.1D
+%ju0LK//BId930DK-:'I`9FAr$hU>*5gae.L/YL*(:_bT$b8:O+67#VCJ:!?T52"eFb(Nfg6'YP:bNoJ_@iKA-n<G@fe4SG1(I-Q6
+%^]L.'r87]O3ZDP&("'M9Sg>(UC+.\T`s#$#U3<;^7T?EodR#F`gc%L*&Keu!C[)rG-M>k`$PWp<Bg&^F6Oh9DC++LG&Rd$A&7MjM
+%)iC,*"#pQ(Cr%BgA(W3BjsSNF/gc,6GpF691Rurj@ctkO.W9cTk!0?pr^[L^QVheF"F$mqg9O.)0g7R*g6I)]-1M8f4AV[h]d/X-
+%Q$ZLHWI]pu"?-koGKg@rk.a]DnYRa#m1nXJY`O@@&PO'\<=2Ra"(f1Hd\161)1('L#=e*I@/b^64!:AEMem;`[Oac?RM+W$>ffnh
+%(0qd>^W.6^]/o^cN"r/sW6e1k%l\g0:A*aa,2a,rc\"OZKsno0Du;a7(_lY+gn6<B@]SdAajBp6!Zr<e6!\8":=MOL\9f/%;NP!H
+%"XK(^=+K-r1qar2<c5oKbk,Gj^a*UE2n75e)38s3SWJ_5[4WNu!rh8ln6@e;OS`cVqO%hF=Fn`gO/-3!^u/QhmFnC.Yi0Z=7@8ZS
+%4E_'t-3iT6/V4jccp5"sN5fbG=-BE#9&>4O:6REcB![8(n!8V=<'eg\,dMZkdQ,0D.B`;0`QgU%\X9D,gW&#lo%<qXl(E#EE"W"[
+%r.>07Wl\:%#))NV8>E<,XR<.39gTB_@"hXkf)^:VJmY0:pqMo-d<mZC_<_)o_dR^,3FkgP&.V#1W&Zo#2!D:G;s4=[M97uE"Rp3G
+%OBU$qF3IX;F,1%Z,g+b9^gpW?H)d&9KH)CGkgD4k))c79MlUeDYbP*U#`pGV$>4o4)Gpi6+_`q<[Y\E("^3CfEh!kclMjk'hPWr!
+%0`e]64;;*741)%NEsil5.a"@9T0UUOESs==eH+/'JJ(-8,,4@9+MN0.Q1^g\I7'?8(Db$ML_Hi_1]>"<N>->%_ASXt=0eN<K5'_P
+%J]M"Ns7oC@3`jjZ8;e<EM/bi,-U(LNHd"*kqD-A>:qP&CWN>/$(4@]4O>\j,7V(SO"6,"HOSJ]braK9u"/2QaY?>`,Amh:AW9bP%
+%-/pGM1,KXZc^0UsZ+5"Uq"p?W&HY=KTR?*?k=(udp00QhU,,c6"n5W-0Lk+);/'d'7Bj6h)R+TVIQb)iV.0W7-<,3?1is2lMg/[!
+%CH8.\?5WHrYeQs"Eja>GBndlC#ce9O:8EF5c":Dn'&euUXrAu+_?5!D4'AB4YQ.XBn6=V+$NjL,I\_UOirK[2b_pu].sB?W[R7Vk
+%A.r$iYS[II`DiSdILDT=Ul8mK5j%_^$?[LUk%4ubeN2(L#,og@-,'fr_@H>'g&]2N[A?k=Zfnd%%'"hSAS'VQEu$-cYZD4Z.eb"_
+%=>[?&_^\PP7TR@J(K(dlA.O;p.'Y?$,;!]IAg6\2,W$W-+0-9Z;522d<"(>"Cqk!#%a[t>FA9V3+d0IiTQPf(Ke"IXjeG^B"/;E>
+%UXU]"@pQl^E#VUoC6&IKqSR`l&W.sn,o.g6BO-@Hg<e4IRF14"UEpo.b*p?s7`f^M/Q15o88)*=X(*0p1Ml?-Lu&!5iJr^%9tI9-
+%Ql9X_f'`/1cBTfsnO,?@6e-Ojl79G'kL!.Tm($Uc#gmJM`U44D+.sZS(p>YrUd,Z:>S>?[\u^n7:$HJ.,E.RAWYT.fiW2AJN3(j4
+%%bOTSN1i\hV8MjT!,iPAZ@VgTcbr&/dob/>6WL1^+`8#J'Cs#g_*ZN+=.j-eH),?dZqA]hKOe+0F;)/;,GG_F[gpD*Dke,KSQ,1r
+%S+T6m(P[c3P&(a6TW0qbeun.F$cY<oK;n%_gd&?UE#gQHGpDrnk^!gV"CS)8h$,!+of^T8#bDCQZ4=iO-j!MKp@Tg^=;_j:q<4UE
+%/r;I,Oc1'3KUO3N/4."`?;X4_AG0$%L)LZ-"t]OE&%$-LQQ"9ePGoc6O5ikbhu[':FE@H+9`,s$^pWi=dKc]+JR7TK2Rld^iP2G^
+%?4Fi].<d\rTC(B<#N++DBNKoMT=_./&&2EJfL!*CSU[a\Qp%+eN+!-)esRE8L%E1"B!R3U?@FVH6u>E9FIcgho'X1hna%l?!6#=n
+%D#hVN6j=p,XnCn?D7e9"%YlL9TtiGk$tW2&K2TiWO;AIt!fUe%=0%2Lq[DJaSTaZ2M7D=AA):$AMoiate@K?H-.+J#0X$n=L%Nb"
+%]Uf^<Q3cbXFoc"P8mEpM-CG0o1#+p:c:]ufO)?b\Rp&QHC2huENSs&J-@Rr>K?(k5/[Wl^iN-'17pb?)AJ/#mSK-URDf[=fBR_QY
+%hb8_K:@o*kBn0lfnEL#\I!Q#0J\5`*8W4s0?k,XPH-J`:#<"hR>+>c0UI9ma!,VOK>_,l%eFk/(F^dR2kS>!7i<H6(BXA^WCW[:u
+%^\[G`4e0G'A6?p@Ho+o'A$oF[.?gK9+m7B%7Np"k9_(YE"(d>0/65jQEL8"2GS+\)m^<7uAg<%A+/ROcd,GgXl#,Ege_$Nge:7af
+%gNqPgYZ7t>m+!dY>3aUHDDa+C$/HB?!d^,Hl:1+m6ZnRE.Bk`[/JXW%#aX+qME;DTZg^-$hp[:7;p+p#,-7*K#%p0j!"$+mSY`V_
+%T:U846@,qEjCs1TJJaFp>D!2cKW&f_NJs7,YZS*%AS[,a-X-MG0juidTSHJ%.:^,"A="K.8*ik`^=6hL0ML,9(R<UX,$koLRKXJf
+%94U_M"`XY;+P7[RK&K2j*^a#'_:f"9V1l#PKk3_aQI:i=Gh]6c8kSM((7/,76NY+C/]u1gj)4,A&n*8(\RD=cB$!.AeL2A8-_URj
+%HQaSm.5!J;1]Y$fP_q<gjA`COoNkU2a+>3AC_0ac/7i!m.gq[P'APjCe9E1[LbP=;BU$\pac<X[:T;F1-3I3;MnHj7QTA3cSoYR7
+%Oa8:rPGU.0?d9N&auIE5,DNbk=M+KV>eJip5Fc!oYd.DV-V"P/*YX!-PEo;fVB("0V1goi_g.&Fdc9>pU??N)"\c1p>?VoH.DH5d
+%T*$:>N2W(S%H_o*YPr'[J/i%Jg?6;f<L2IB@a1s3MdT'GQKGS/<%#RG,_4mAYf>Vs#4h$<AhYISSY<fR2S&>P9T)'L\N/)'s/cEZ
+%VInt1l1g-K7WIage<u@/a_1(hor>\=:/)]HD*T3Lm+mMs_P3HS?m;=`bq,KO1PhsPDS?sH@)p*m@sQ>Ci_gBDJSQKU:`Vm=<M@B7
+%%=gml[V/;%e83)r[DSY$T1"7)N4ZFLBNkQCBi4@`/C7F:=:dWTU:Ir_(S<2I%h=FT[r.)%Dq#IRoYSOiaORqs>ol-+I#@&]WY*HJ
+%Ak1H\rB\95Br6@caFL!`VECk1/?2uq4Y>T:=g&KI[T##Y66P5Dg$qj_'hE-f/6C2\bA0!IC^<ZnaIImGQG@2W\%19((32$9QlCQ`
+%`L_7],:rNo8u-256"1n%+?0b&2mSb=>d+/f,7si`:`@XfFum&k[,#P+Zttd1P_1)l6PUs?^^'e#p[EX;DN@8^h<B)"a_?Dn!;iBV
+%Qjq:pLGDDjXT>iCR3W.JZOeaph(5EqO(\M_*!M<ugea7D4lS7u3@nj[ke/mYd?4gi81kGu\t^1JD%DU,j;F9@7mbs5`_KflKq2$l
+%S]!>_"#.imY;j12^]H;&Ajo)tfPY<O\+"Apm4;I:BQ[^;p6Lm"X],H[]@M4NreRqe_7VAbe7MTTbPS\,"S$u1$'/b4Sfu!;J<?k>
+%3d@8+gd$2@A6C;fXWsrlFuef,+i7T=8C$FBk!leqHHc_,MP4E\^ck%'T0YZ`*l7,hK7:rl,VTI<QufaBhM,"/_gn&%62P2J(0<0>
+%E&2iK2UI;D<LCI'[%tRO`)\$+O+f8OfV3r!`Y$@*k(g=D2+q+0W$k`%F3)LY-(bP^eX)S9^UG]\1<j<picm/A][]Rr,IBe.[O%\Z
+%%H'b0D(T+LLaA[o+4`jf/qTp10C*I;@nQ><P\;fSL'4;jkD=aif>+Z!1t@fl:P9c4=JG<Xd+n^e+tMHb+@)<Q^7<oKCS!#IH1N\V
+%`BR-kf!J,Nf/Z.%W"o@ZEQ%IjPOUt&#opOA9273[`Ig=8I2Np:N#hYTqNZkCgfMrFQ,&$jZYPt+=>(f*>G2u#QOD@'Y-CTS1\s8%
+%X(VIqk'l[(N.09,f84>\h5:b>_5=kg/"8JM'>4PopZ/W9G@#^bJ3@E6I5r/6f5QgGk'3rr3-#m$4PZ.k3L5Kt,Lj(EJ#U$;KU7/i
+%;_ii<eem\1F/r,_&RjJ`_/nq2Q;tpfJ?E=2Og?@mkYjsh()J6%qebQ,CGLSk$@.jinh-L.N0\mcihY.WAt#?42%hlm.B-6f9WJ)%
+%TURqo=GnJV-RBMe3^4OB:SrM<M%b$%j@.IJ3\,GH]Jufo?j)ft#5J`Ff$](LP1&::!)[#I[=QuYPPLV?5te)s&8@X=;6uo<:V#0t
+%?iio=B!T^H^tj+L-H(a5ZP7r6Dr)oZ;6(S#+G.5%)U:/k5Y`Sr0K#YA^/1d^hTo)bl0UoN'@[UUP=m4DiBsZM0Bqr17>g0HaqR5q
+%(g/D&C>h]8Q;Ek_)"fX/Tp&`i,1O1p/Kl.B.&Eb^/"%Ke(q2kqXN=Bna9Oe)Vd"gNh6gRo1m"Qp!<&(,'?Zj.Rg^T4AIVnaA0\jr
+%:a2dc^P>6Ukc^Lo!C2iAZp$&^LigWNGoq`p72f9?V$L1Y^<Ch:/-VfE7E>b',kWYT3Z^mOlRPT*0n(_T2iD%A3,>TP4[XKZWX@ee
+%G#>maY:JDL*d%"Z"O7uZeWukYf+#f9qPAdEB9sAcCboQu%lb<CS@h"#H8/GT]&^:VO?SLQB9W:ZFq+p>%M19.0(_sM_"p=8.4X-K
+%Mopm_V%L\!TP&-PbpjoiIOYHTbRPFG&<34'<i6;'8k,\h(^W"8+#=Oe$83Y9QU'"OeY8#EPd)io.m#?R%-`LdGQeWd>e=J-pVI8@
+%8@t2&#,Apl)eV*s5,g(i/JURI[`Bg(MsG=ol;EB3e\@a*e7L>\/oKf@6Zrp(%k0c/!#e8\mfir_1TKZ5[t=dR]M`0H`"#\QQXYE<
+%N@L(/Z_o5uX_$T1W>PjMQks@fAcZ[]^`-A(>cYOB9>d,=RMls&YS#NM(hcs$K>17Iqui<WT0P.dk2ZpgCpKSDZq07$EGDA_7ZGAf
+%I5^3m>D1)S9]dn$E[_mncJW/XR[%S<R>[dd99Mm_PM"JI<7@OmLbWQbp]eE0V.%q$(cD<p?Y;XKXjA8_1Q9WEXj',RAc3dP"fUpq
+%/C6Q17MN\)iTI'JfTa_Wot#N@2-.o+W3RlUK7e1.JD5+&bh>+1[N1S=oke^.Zjf@XeXSOgP_#)OD=/9AD9tp0K--;XO(i8e92uK7
+%L*Xf($_C.Kf")IUoijLlc"JMg5[-[EZ9>)<k,+itU1ukF</Lr[Z:IT[*<6DP"at-N8A74AA[,dU0=<:9#b(o#bmL[,mn;,,88>ba
+%U"B!(3(0j9q[I!s"cC0O\7IcW!#/;H2<@0Kk/jS9WX#sY5C&gDQZ?_+G9tbuJr%9%-]<Cc`)N<\S%8s-Pb\Jo(,BsA.\T!fFLV0N
+%^R_&SW%1RWng;iDoQ&s^G,DR7&PhFOUtuN^R_hLlJXA-q8URO;=X7!'"`V(Nemub!7QNsG$glZ*nL7&2NXM^a>@*?t@%oSen"soH
+%q^pMOA-o*Uha`Sjc7JMP;8E-h*,jJ'G83S8=_.R?8`JpYl\]a+8;)4r.!QcpJsH7`aDVC`+b(Fn%]$hp99*T]WE5PBJpC;'_.6.6
+%qmXarmIZ`O:E8Oei7^J!31C,s)(<U%Vt9AgFso+CD>"@KL)e)^+\33^KZFNP`dYs7m-nhPrbIKb4-T0Whqq]=nb2PMc/nV*:JXF'
+%"P_+Lq!@b4d_C#Ss7F:&s5g_VYBi!srR1]:jI\X5j^3K2iqGAb0D^1tr+d)I_oXRHGgkFBlcIKQIeE!;s4]"$0B29rLQc(m2ZD=C
+%S\9?ms6NO1q6/Cgmf)79n%[t6qrP#!DpQ/TrR$Nf]tOC0mAl02o8B7!Va$gRrVW/.="eJFY5-t)F*[cIo&ff8G.2tL_E7Yfo/HE'
+%_"nmsYWa['lFZ*MnuK6</md">r?&,[`Ah`g?GCp]jrku&`Yd([];,/dm.J>9D_M+eD4g1`mi)[tY&7`'45IV4VX(]mIlMq!p,DjE
+%h#e#=(sTA(GDGbcc/kGdDuOkSlMe%nhgE6^Ddu=^3rY%]IJSkmg["[[e[IK@0AgU:o")KJD]-:!H$amenLq@ahgTWl^5]P1]\_IF
+%Qe-"7ItJORGP5qSDn`op4aV6khp]0N>X.`ik5O4Y'HXq2n%Z2Y[Z)`g];>Q,U%J9O]062^o&Z@KCY!h#h,aBUh7Yn)D_<[BqTZ_-
+%bB=)@rpJQO0CKjrYQ"4<?bQ=0S$OdH2TA$Grl)ZDq"O*t2toN+2dcOH`VH!1hn6XOfg#?+c.Wd+M8s^N"Rj"]IefIkY>7>H)GEB*
+%_=[Ef=]Z_QrVksMp!I=(QH?LrMrt>NR*ml^F0q<p(=S??8foX^UW)l>Vr25C]s%DW/LIcj2Y,?>/Z&t\9`K/,p@[apZg1u5HM^Y=
+%pnKM<LKPO&XnR8XQGu:7-U+`g(s'GRo_QhUhd$*Hnr3SI"0jKHG55"Hp`I6LqXqgU)fNVaieI@1Nar$=*/s8)mJR^gnm3&Q,Nn"H
+%SdP>b?6+,<?2sdH&+17k?C\cYFa!Y6[&2^WTDV:Zj3?]YRhlU^1#L1AEUT2Vm@(5"gK=Bo>>D)A1S*DZT)Rp0cA1d\rVufb#5c:Z
+%Y1NXMro*7uB?+*>#LMMFIs#ZLig&AlVrp"BDJoL=]5Q96P!?KPa5,Vje(`W\cd"2X3'Y$)BH'6$h<jdYE:aV:kJ)LnF+&',!,'8?
+%`jF@dn[P1J>eb`/p4.."CKPYe59@<5-ZgeUC(O0u9Pi'KnEC'(5.X,[lLN1AcRr:;i=G!KIk4I;NSR?*51aGVQZ'UK\p1QH`E8`#
+%j`pc?c+u,)iO1H@lKD!pfCYf^FkuM/4anM7+*D\'lh;IZX`Q]gnh'ap`U.#^MK`n+X7UmZnHHW+h:\6LrUR3*NXpO:\#$c#@.k-0
+%N?86HEuMK=Ed32:G;FYs,"s>#V>l=dA2Z6""(3n!^A-I%X"V1IH[55=[aGOI4?UaSDJm5fk2t4=?gkUQ2Ja1J`4,:L6V/>69>8&d
+%FgdRF_jVTkrsc<"A_=oXh4D<mI![O=c9L&SFu?l.3%akL\<&V#7Xs]W[$CUiM-iUhfgVOq2>!T[$,>2M?Mn>!`\tCmL^`'gDDs?D
+%qZlkEr8[$B:k[^jo"6#"M78^@r7+iNrZ<>FGU$_oJb"UUJu8D>o8"LahJMB%GfkZJOV;c=%rV-hps%pdDdT'+?X-lA^\Q^=[p+5?
+%*dHSF7;4]#hgWqas*c*3B"%_'#35etG9]1^?Wm@,q);s<f,(X)\9N.9rW&_n=5+S5I^aO<A<._]^MRI_qq^+S[3("]hT0#M%1)\Q
+%Sr2\6X8h!Ys6.0Vk@P0^X*=79__E`$@\H!]WS>K;G`nf1Oh'A!/@YfVg'd<Os51rTJ,28,\W(T<<0+ViIU\%^jc?$>?XBirhV[W&
+%q=WjM=8.&L/h[-9,JFuYn(kCZO+,D<^'C6WJ+in<4J\P9n*Jf`S#[&&XsmYig\j&i+,Jg.3kF>c^A")kH!\*cIql1VgHE6VX)dC<
+%]=A^kq=@[Sf,&'=6%7+-hDsKVkARQ\^*@a1E-tr0jITQKH"Sre?XCIWr7enp\\2AmbXR=sS_hgihjiNZO$n<eh:_NA3@rbC*ToAH
+%d(!.Sg;k,<ZgT9HrMto_fh]%5[\Blg`R<D[h!\GcO'u&BLr/]hZRVMaA-kFc(rTIPr^ef"[Z/!C@1XA[KW"\scSlIS3`_ml]ZhDc
+%nK!/l)gsW9o&OZK]RRLXM"?To=.ZG\D0Yg4%trTZp4!D\@OjP'#_Z:tf#IoHfSFfm"@Bcq,ri]MfSFnCa\U_n0&3?QH5i:L*t/G6
+%O$JN'C:"p7]:XJp[rPH>Em-HtpRcaGilH?:"MU_WCu-PAp4k`uRgEAL@e7;_eq1g0$9p*$i;neM>N(9^8e$W:FT%'/@X]h+s/GUI
+%4hnOQp$3'<J<(H?Nf7[:pcJ:;n8EeM9Ks&_bLq\1m"&\-O5H97\UT+HX81jHVW(/2GeB]0(R0oTCh"#\\=b`8'up^IGX3?t6!`:&
+%XEo7XW;C9R>/P^#TDk5oo;FkoYG^FR['f46,<E^HY,@9'`.rY%D&q3sR*bIpYQ9dl:&d1CA%AUHDIcq2-fk5uOLgFRYdG.MO_OVF
+%:WNc9drTkUFgF[jYlU;bLI!WmM>o]J';,1%Fsm6<54AO-s520"5FcP"E&6eMaXfic^]/.n3jqFBoDg'T^D14:".4%6InO$+gDIqm
+%$0U`qG%AHM1?"24?q`P(fAbPCZT#Y0s5(?"IX1JVjn3rmo:LD!XQ,oqV#RL?e=cbr9@c7V@q[[AE#?<=,IYr"q#9G8=5VlI?GE$p
+%J2;V6+oL<d7OfBBR;ut&a5SO>kaRN[m,b!,2#OVi>jjE@n`_+]NFYpM3>HIRGLQX@HrJ2.PL'!VmH'gUXtJRIjf2LBEW4Qn87FKA
+%[P7dIkYBa]:@72Tme=<,L?-ujDC9RKVsF'uj/mDd4Ru3.-DNaN)0L;0kVa+I*Y\tYj5o/O?N'EEg%SikAM-4H7&BjuX[b6\id>s5
+%2tFO2qL"6(rd]4MV\?>rbtKk8i'-&F`]cj@pGAqQ">,Z,3f[([+*fid.-8Q*9)56aa>$;tNHI3M.C[\$:HV8FS'/"MIf'!$"jr8#
+%@2quaS!m-m"T&,WeZ52.56's9`PqN5rFB5^hVYEX^YXA;\'(7B(N2LP]m0AKc0a3WWe9fYZ]/;UG!A,;innS]lX0hZ=O?PN+<:oe
+%UOdMDOPYnHoUF%<P1OVY4FgQ%]dP]RYPKn77&_aWnUW;R]Q7`acfN^3#>bu?N=<c%qa79K4j<&:.4Y<Tk2N-=nD.mKDJBI^-L]^D
+%YP[AZ`C$YQCkN)hDO5R3AXVrK2qNF%Iit,<]jC0l2Z;PrBSeW&TK><N4.$9+?TSJW2?pSDo1,bc?[R3?hR2k-UUT@6osUf;7D(5;
+%H=<_pdG&^6[N)t4HQ2A9D0bTf3I4n)No$(s\)gHoc2BQZX*8[a]j$.[B@2(<D;VP'kd?j-S&qQ((`c),n[J9(^u9l>o?Vpd[OYbs
+%n@3:G9RH^ZO6aWRUlF.Qqu&^srR*:GD%,_QhoeNO[JSA,c'oZn-_I\k9Z_eAL\oW`Rm3KMY.cV4aN<9a;8j3op9k$Ga&N!(jKh&o
+%'n7Iu\>Q.^De7LlOG^f<Y!4fZs!)j52R;kFqNu-c8Uf)L[R!Xbpm,dZC-'ecHm!@\<k<aUQ2(`"AN'7.IMA#%CFAJ^#MP3&1+,Ra
+%R31qd4/Q_1_fj\*F*Mm?O%FHMaSgBLU@TJ@rqc<,-D;Uo3taL-Ilc/i(G@_SY<Ku$r6+tpA8\6`)g-8#lYB\?k.:QdUFl#rgCd`(
+%2'-.)HrTF9fsoZ>C"Ie'c.U:0muBN(5MhcNN4Pc)FL6[\G0kC>?6AR-c"T#,VB+0pdIjEi6!NUMd1/4k5t="MdnB0Om%A]DhG^%r
+%[Z(UK]6j"[HFMAt^[Lmp]??NO8/=j9,Q66^hAsKm(D"TEr4.km)$Kg5M^NiQ2A2T@H3-"g$2E!(gTTJJ]!u'@Va&V3%/8f5kuJio
+%61WRZl\jZW?MsQP^(8edeh&V<I!p?_FY=HtfgaC<V6b@NnE/m4mVdbAS%?1@4PnDZE28!Z6&0HUJ%9q!*pI$\6Md$EJ3;r@)M3))
+%h:(oemFh<)ZWFoV\_KfSS@/-*\+9>a9Sfqmq'#%Hp@Ns-?JcdOp"QN3o\K,Jqn\t1@9$G'GW14rq<%UE5@)"7Ik]J5?gu+j(t+t8
+%5;mP%^6SKjIU^g?Y(NhrGOZM4_Z.74m(`kmRB=^1Omlcu6[1<D_rE]9KD^LCc8Lk^Gk<&+lJBE#78&,OhZuC_*M#[*NA:>R>.XU@
+%eF\aY.6`24rR9.0[r^JgqVk#K0A_1gs(iWQn9DUb<dOa5["[7,rsqD"Ch=4`TIjbeprbP'NMFa?[$a+*S*=F?ChuUuqE_3[NMNcW
+%5Xs3l7WUDTN^hLFBNc@od:bQZ9h1uCBJ^`G1i:1iHSh0LBJ^_Cepe$:irdS'HecTHSV7oFRsmcBrC.3kA&A3,;J/56K_tYmp!(*l
+%dsF=48)glb&dJ:-e]l?eqeF%Cc\@<HY?X*^UJ83RK[FT5rV]_%^SX.>Fk?WWX&irss7Q2ELi0pi42617rBG/=0rr4fGW^GIjt"-A
+%,P)U.k#U*o,P,M2mN-i%C]Vj@['^q_s8S).-$u>N0Rn*r`CEgLHRi5)a1C"hDT""#T'L94Wo2g5Bj,Fi#mP_P,Dq4oj@m7fB"6.[
+%K1fuu@mk[W*[,PF<nDa="1ltA]7YB6Q147Vfh>TI6$:&Zd#**=($dOgCE$L:W*p](//Wk@.u!dRC0;XHP(Gjgc[Yugk5+'<>09>&
+%N;\3da7Y!t?i/YCC+LH\p\LYqRl<9f,6i@E?L(DQE,Ve9qT"R']Dl\cbKG%0#/?^ll;+>_^Ce0K.Fm@c1@&q`lh;IZX`XNHe_lL,
+%fgai(D2mOHce&F:mGh-RR@EFI:YAd[re.1c/$JFUT!GJ?rNT/OYmAqp16]2*M0mD1J%4gK`TR9jLsRBtmmp9\-%_;,=(;nIoqQ1m
+%4uR<!Xi.V2I\)_#3$gfMVj,$M^H:a'h3WW!ft7%E?+p8GDW-*04a?pcYl,n$iVQEhefL$'k6?.grYtUMl2N^=09^3^O;QE@:B&:"
+%Gd'>Hk-+j;L'BCu(EJ>75+n\@LQ.c":H]iT)p/'c\N^,pF<d*n;_mi<2fbi=SV$kR7)!=?F9;HK)1',sT&YfE\k`Z_D=qfFFFdU;
+%LH<%0jVpdSIHiQEhM$*>6L2*Yf'ra*QJXt0V#T]Qm/$D,mt#*>[r8Irs)!\Wo-'^&2eQK7jjb80R^d]oIZSn$S8?-=I&G;OUK-S@
+%l!KH4l$`#rBD'36Ch+drmA4/3pX4EG9E%;kQ@;5%n1X`srpAh77TT8Y1AF$rmt!Hc5Q'oU]n:;iP1R\d>!>sT_%BK<"<?/309mUd
+%c1^o_Q5B-oY?l'U*p1Z=LRjA#iu<Ft2'X/LEb%7[Iq$ff]TrI<;KQG*K/fOfaT&ubH26(HZ`Ulta,2)hT7?R@?i@$L?iKZi9<10A
+%U.g_'It)P<a$(^0J2e;6Y:om$H+j-2c[Pnr[_`"9`V3G@h7W$RI=(\<`U!Ql6iYB$r2TeC?bZF(D?#+bn<nWhU/*0)=n]8qs/5Pi
+%M7)E.s8$O9'E.%irdXjLrZD0n7GjZ3PM_r/TE"4P?;a/jp=X.s;gF[-S5*7-oO"_k>]oStH<\j_83B%N0qOKN5AR55ObK/8$fa&3
+%@O>N1k,4SASnkZ]b)sX<=e4i"6GiN!(29Fc\$pMN+8fu(eg3o%FYO+!Z'oHlI^S7*r`JcG^T>b%%?Z-Vl@7qDBqY)IW;LAu5Y,#r
+%/L>[Z1mT+P(nR#Rb/q2;2W`N)c-u;9pQ9H.q\QrT,jZO"26bFlb>VeWI9(B\IVGH.JnloTI8t%5#$`[Br0WB8-N!_IYGm*(s3/*J
+%Zfk'?<M4Mfp[l-0cU,_WI7SK^(nOGRdM-pZP:Xo8T1un)/b-buS$$>e6`?99[^G@&$B@1`T/iM[J)6\JDMh#7.eOP>RI*3R;fD]^
+%r,&'<l?F,WB=1JH"0U140_d>9""o<N4n*@+,l0]n:eC$NiWT7c4u"A&+uAO4m;;6]#qF.tY0oT$isEGW\8P]',/Se$ZA^>*YP)TJ
+%b7Lq@I$!`>V;`&%>_lD4gqGHHhI$mY7fs4Li3KZn+to?WI?iq!En'NSOQQgO%:3)@c]?:E?\jlOr`CXV(8Bp))7/alP%E\IBh/OT
+%F0T+jHq[7pdmVB+XprlEKsG^qTuE(h'Tu.-haHR:3F=?(l_4j\D%l"n/\ZAR9&IiSXnH$d*T-*ImG#$00>3okO`0LR:4@,uG?.D(
+%ZA*#69gNr:ErDg);V'LTo2R-#Y:C7:B>12d/!312@C(kDaBce9;6sP[I2BH<)lgB9VPl`1>[LiEM4.tJH;Znu^KPUU]$T']Zj0NP
+%p!/S^l#EPs]:7D8o<bH?G'WQCPZl^&&\Zl?)g?RRq?ZqgipWJF5$_$@[60XaH<.qJA`H7NXaYK[*q0-ZYIKeTF?c+7.")V$.EW!a
+%f!jt1MQ8@VR3pdb,RQDeYklil9K]X,Uos2:Ph`n:ol]Km]_3l:XS6T3ae\n#;judh8c=b7htQBV;4jc;[h\pDJ"F;83DH(G?H#73
+%-o]5smuk]XQ=:YB^H-WIas8Pj06c(P^"`5h"C6U3cZe9)rZU+_G@-ZMZ`;4JmOQe:C#U4A^/o_TqRo^KhmUtBM_"Y6o!'NM^M5R]
+%Td7+hr^,"(qT$)$rr3EbeA$+4Z1pg>?0/_\IB#UC=a!`5A9N?^A'b#f>K#]Rhj#T1jAX&=oW95$(/u`UX1A[+s+7CF(:qV/YC.M$
+%Y<$I<<"1lmI;eEcom_J-df)k%.`'r3b/@r=(HF3*EDEZuhQL+hDNU*OSitt<.>N&(dIB5lVbKr^QggWZ-9IULjBMUgV^jV"rSFS;
+%n\"K?8CPL%kVn7qIF4bN7ZVZ<D+!'8TAE8.5b7]56iYIt?-W<`R;s'O^W:/l,0X?CO_G,D?8=[,FL`)G:*KB3,__s'ZhLYr!S?3N
+%q'j%k\-LFUVlFb>F<0rQ;HIs,iXW?P.ot3sc2!<!9S@eMEsHaSNK;krn*c3K+8q:eaIV]WG>07Ec;0YU#-ncL^&!b)oErs\@a8,;
+%NZ?L&O+o02=4:C,W7?@$.qtljX/EhtK^Pp5[MJP@o&E+IcnUfp`I#0,EpnpU)IC;[_T'Y]efWEX<;?e\g*3jL8lb.<7OG`S,l1W)
+%U>f9K[rugm?d^Bep-DWmYFiI;H@\"ieM#d-^3`PT_Sf&[(Y2/10:L0U\%2mlnQZeNmsa$[O2AA5-H/tkOG0dnXo2h\MfL8lWF$`p
+%\k4'@j0b_e$eko.J!T:uA'RN?488WG\175VN0A.^9M\G_bopc8EdpJfGLB?/T'&2ag5;'A2e8O>Cp'Mt]i4%("RJiDnP*r@hGMk%
+%pfaLum5^a[-Q6AWaeA5=jKuE_?(Wg]s1<L_6$;3e$ElbqI4,M<P$Qirec)$'rPgeA\P?.S.$OR.TSl:"6"Sl5]%'tt3#erRd/6=1
+%pLG*7HSq-8ids[j?KmDgkmL+1TWca0.(d"Hf2L>tQ>Efc71m+[&m<it=)`JNQL&3nY&?JR[mQ;D]MGiBEQ.4^^e0#X;r3ppM&oE?
+%)H38GrirH[d&p&>k-ahG?stbD+NP!D(*5V;<SIu]#14L9<`brlm6B)=Pk.=JUYdKTZ$p]e+4R>Q"P+tK<gtIb]Ace$F-*mr$<XPg
+%Ac9'p'"SOcBMBbj:\DPc):$.mr@n+\qcI[\rgqX+1Nn-ZK=:(h+o%VW6$@.68sFJVN@H9cS+nb5AV,K`mrgl8Hp26^T7=:"k0s6;
+%8)-%2o2/6&(`ZlpWX%i9<N=n1oSu(9$VPUBZ;[4).=HPsRe2bQ`BtOqH."46GI?(JFRJ5\mG_Bt!St10N,fcHORG7C3ZQqhD+fAu
+%7GQCem7M`arS8PFNt1f[2XqK)@AGtaB!sXfq;1@;Ib1l_DN7]lWU.N#j/=V=<tXQ^me9%ED5/U(GZ2\ZMSA;`rR'SLl+K]jdncRb
+%JJ;Y#)nkt#K@%)'&M9k1QC3(]"k$k\SoHr\>o7:Ri\W^boe8gTW8pP%QERiu^WWJ2^%,BUVhhSWI:R2Gf!,1/r&on7U>f/)-7<4\
+%PBg8PHlrfNFjD[5?;F)VG=\\/V5b(??(G+FJ1a7CnTgiF^5B5TkTKHbpUdp'HW<#9$Gh.eG:%Sg05X7cj1@q<-\XL6(PPX'TGJd8
+%Zej"GT?k@q-!Kco</u"a1Mn-rLgB5;Ed#F$pQd?I;AVZAgd(S=9tIQ9ao/\EA?andoHLAYP%=sra;d8a\laA/Zs::39n[gg:EaoK
+%Njg`W-IdS4U'Y&4W%UJU'@Ca_a!/84Hm-qfF^\W/;I&:?ENgRsH.(Rq?8,0A"n)Ljk"/pB$aF0eGB(db*p]<%n6:NWs/+'+I8ib&
+%@teLZ$?CXJR`o5SPLnVRM9i8b+e>>:X>R^8b2V]U7'RQ%O-9piZ=>'6a>,H^$FI<'aP-:@[GQg<2aV[ZO1dXjZt1#e\0t^g\B/\]
+%(i!$hg#[fIWj.VKKV=l<HGuh06H"-9!li3r\Uce9&E[Hj/PdD]+KF1u+-n;n;n_5>8=Ak-5$6D!T<$[K`5M,^Xf6Ws47a^6,/(H[
+%[(aQZ4l44kH;*B)jqC?FTfdl'qaksDQFW+SgaDH6[J<5Gm3c0m(9;Jl^.A,!+E%n);f^7@a`#UKGZdGRKm6s,9dk<@$ZiTX9''9C
+%[V)%:p@cf'546%u<LCJ6n._$_S%QI7rQcg1=*65K>k46&@I?$6q251F)0@UiEW(sj.$;s>S_"P#\tBB\bR@SF9d+Mt:!\SF@KLbI
+%)HFKLk[_BK73Tfms(?N'SZ=]DGeUfd\BW)jnD3_BjC%&d"]';62\2s(_\:lKni!GAM)9.kCI>G-j!)/sB&/2`I\3ZuRhIF.i1"KW
+%Ung(RA7/8OfR>,-2sH;+FYj8);7Yfjg1@P4&GNYagPt$jlGl?3I=A\_f^'@AB;(qI?CV.r+87^OqkUuMH6L[hP+BC.";9<s=-?A5
+%1OUhL$%Ps07o?L&;7_i09hEbl`/1t7cOKo-*(G8$cZRB@DS&`(o00S<hH%hLa1co2=1R$26+]m.RbiGSK3RSO%3G41Q=he-@dmXY
+%:XGoYR6I%Hf&eJP/ihWaH6EK4TOE1*-U1(hT%NE.5K*ZC"/&.OKJ@dX7s'ID0P9Lu@YP=pPPUQs33P)jrpQ5+ITqr4i`o9H\A252
+%&lYQ%gr_tlcmp<(h)21T+dh!:f-Q8/8kP_e@T(YT&IDs5,G#6)cfF_SqHD;oaDBP7h^"*JRFEb\4k%'>8T*3Hr]!sq6>dp-"2^=o
+%Du7\'fs05CqRqIB/"Rh<4eJdA/'-2`:PBW>Np[kC7HEKKigY""aGW+9(YO!Q?2R"bU5S=cLd0)1b!\,^]GH!Fhbcn(4==IJ.E_k"
+%p;og#!_n)YW\p0fG=n!l+Ps-t^eWnS?J(VpKVph(EOu$aNO%HK<P@q9`%&,!!Dc/r?*oOg1H:<h)Tm?l0.e.NUlEPZ#U(6PY9q`r
+%m?D0_Zr+nfAjAK/UdObD;HHF)#:G@6''m)X5RoNsok9AdY(jNm8-/($i$9npAdX#B[j=2X-)b/6SbPDn>_uu07-Rl^HM3n$"3qm#
+%<Sg7YHF_,=-kcb>374m2$YRABFY`fq.B"Ok]EE;tii$Z#G$u&,@Nnl_(@PKDkF+4];,g3-`D&q=m;8hV#`C`)4I`IoFY<MG/IoKH
+%6%1@GEPHLo)Bu%ZV]^E4&dWcc%HnHui`N3=ct?OojYasqq;r#6CbU0EOqYuI]eHA:D/P^5gJl*:Vesf5@miXOi7Pn=<Q2*04h_X(
+%$R17K1>GA4P+o53MT+g]hj"P,Y!^efA(EAR:k8"-%Iqg5l8'N$M<_=d:G+u^QITls:lN"?W\k^:Y2o2j^<R%N9U"io2OaVC?\?J"
+%Q-ZqDN(O/-eGWS$`CeD?k,)u`&O6su][-5P7-\HYc-,6EoUa^dWZ2m&C$b<<#pq-8UH5@0ajW7E'H#*kk-KD&%W0)57B1m]@a$-E
+%hBrS?)lI5(@M`Lkdc1tR8n$Z>+GQ_k`HmR>eW4I(`bpC-M5aoCEBWWt84/Z0!'Sl(PtJ>o]j0p"2E3NYlCW;3a?*^2V'D[%LZoQD
+%KcaT8+@PH[Q,Sslm!5A.OndJp4mKdDl-=$$X6m'L2@34%%+%;a9fBi;`(Egn[[Sn%?F&W=n23mAD*'@%nhWfh'ceclbu(!'I5@e"
+%B@(p$Y9qhri8\cs#g$@*:6rWGqn%sN9.sp0;ET[K%Z2NqWd1bZ.bCV3`R-P2_Yu<'eo"ZAmtl^G!9WC2U,G9r**'((6kU7D1dmC?
+%Yi!1K5Y<)!Aq(??Ug$sOs$!($;QG*r]U5sG43RVa@M[,T#:RLNm+9u=O<p)j=G(Dr](;t(@EtS3n+S[m?5M=EMDWN]4\?,]qL&eZ
+%;*6)8@PaZ8HOVZRB`Xc02fo,Nl`bjAog/9L:+Tko3go([*Llo3.:OdqBqN@^J&#oomN6ac;aeNXp5':1Br,d9qH:,gW4ffhNH?2m
+%5sJ$'O?JAW6LF[(`KPNk)IaMiOd\DrUpMG/8.@_%cdbUM`?dm,8FJYWi?Rg'1MLN_I'ReQ&B)@Si0Am2cslHhH-fhQY<fDECjudP
+%./WJ*rVL4lqsp)g\p\W)ch=[us763as7MFkqu8\tTq/@]*tH4N8J;=OStpF_!6d-SLI'/Fl[qH7dcEi(Aj?1`li'*_9BYa06^Vt4
+%%K\@nBat-&8J;?E`iO^r!QX9eK:l`L_#qJ_Z8ea,5SKIF+@m/)E>YV\h)bUmAkbB.MM<H!#"Ff[%t^RMM$!`l[^c2W.:(`H?rGdu
+%5sQm``'MI$C#Yi=2#6tjFIFc)+o&Ei?$:`o=#M3,5bDRe%KSdc$O>V>Uk(mpC=9sdZ"ik&!GF?l``)DBZD%hI*4b2Z$-B.uE]*ka
+%/bT_7Okb0As2X-b\X?i4\+sgYYjD>HF7%H2jkDj`ZH5<NKOs0j%R[Qo'Dm#4OWT6iP9pdTZsi6kNbXan%`5Vn'8Iac\;>jBD;<!:
+%kVbG8#N=EViu`ejP<8[RN19(;:Ihs`9(@"nRlu3r7_7Ofho!%I59,?"PO3Arh@1FlabVm&arZ4]PFjo:onH%"!;@g5H4]XA2V(1H
+%2qXN'T\m\.4:(s69fs*j#?19q$lh3G(^a$,3!]a:"$$Vn#KqT-$b-!DO%7+(=?ccr-_34&&LU9mJr,[o4pVlNCOHaHNgi!:)95Gk
+%KT5"-%RJ-,!sdfF\;A*7Emhll(ccKn0U/(Ya$D[FfiJD%jeR`g@ccZ%4:j*"V@UJc@=SS*k+mid0QVDm4<6;7S*\8,\``Zi++Tl6
+%3r<IS*8IFsT]beq*.XY;DpZrFFD.CJM.)R^h\h0O8Y<][YH)iQr'PtoS,S&SO9CB'aeU88aS)9Ld)lk#f0Kd,!+#mHaoMK(d>&6`
+%fKl:h"50)Zn8t$<2_bBfM4sf3W1C<d:p?L<rD:"pI!l"QDP"WK5jm^^6U5kbUE'?H1\9_m^cS(F"/'itJPQO.a^cFq^Vg%5!.ZG'
+%T7\82E6]I(_@u[o5qoql#O)MQ-i\,s*"Oc`!s!Vp`$(4)]VSC/jWQfA"QnYb%Y3\uc#F:S:RX6GSgQ*0"ON>Z%YEo$Z@3?U%o"#D
+%duu*g!pX2u*!"NqD7:&-KD;Er4W30DO?I=;&C@#UE!U:+B'5#d^%l%H^jGV_LVWY[KnBAQ@fIJPi=da>+:t/%E<(qnB&We5+-+g6
+%TmUh%4;l@u]ljCG:RX6KcmMO-!9o[O%Kc=V>Our=+(jL4@%X"G&\&@HHoenNYK5/nIcaRS3lDQ#SHD-+n>[N0o95RhSDSGZo7&aq
+%bQ%#1ooCW-5Gs`j6m$Vn:41K.Y@!m6roWS%Mj#Y<JGhq:lLY!>rVuo@s4@8eJ*[,Zp?'W=mI_RX^3OjHIIZ']gFp:S4o>6<G4E9E
+%\C'%;1#7A[manZ!?C^r]k4[PJDXNV:.>J=QegW3,UF>F(]u64I.t.<DKdJf18KC#H0)YpCaL=0mE`pJQ/2%62+(@m,0M]]j+u.,F
+%8^)`g&UFr:Og'WK6c.b!5=&qA$jSVN,KJ+,:?2LD_C-32J(lW9W^73bc<j0GR<6t/io"qbI;?A-(I,>YjAqmgL0fg=4-kfJC>DlJ
+%T_ieG<bd+S`&gRXQU*<'1_eUBUPLGcPXCqfdHa%a0:Lfs8.IY8#(hNd=^6$f[rR7eOAT3XV4`W,4k_$FTQUJ]e&<WU,a/&9#6!+3
+%Yo!5(jZ2f5%BB-rnfj8S2mH-"V^nf=TX3jZI:8S-NM%uN5e]*<O!#QIkV_EoaIf2_.Fnre9OoV<\ETT[&]CD/Whu^#MAZYLjOfL2
+%&@r(?+M`a,11>@QXZfnFCK`7cAOP23Qg!"O9_BSBE`>p;Frk`X<A6^jq$K0d<Gju47LLG2J\=m\o[87$N2$]<-M&.YWWX,T$J\jq
+%7:r7^b-g>V"ZjMZ46!K0)N\]F9\'1m+VNk0Lg%\-=CDsC]88UKKp@9-?-#j*;g-l8l7a/hPAu'a+E:jT#CS,V6t8l@Dr<8/0^,Yn
+%AIu.D%*1MdUP"nZ;A5]0Z<;n7KJP2VOX8BZ-Manj-s%HBRkl84Wf0X2bsm;n?n,;QG0;BNZhoj'PKkAo,_ka*<ne>nbIXR,QVW&R
+%<acC0Xb-HZhD=D#.fF*9m0WG!oZ*E=fVPp-D>?!%ST7ufdiqc8?^hIQa=pror6Rp#^dXur.GZ$O^XZ?A[+I/Ylm>E_gIOslT:ig5
+%hNXC)GD4#F71UYU_V:hh?aDZUW\p4JUr?Qhder:E2MkOoE,%r`<P0G3eKgqm`FnsN;]_L1H4mOY`<f1LW)^cfS*2=KPJ:ErWu$bQ
+%TNlg-3!K=VI!cB!mZ!Bb>c`N*NtP_YjbU\CE]l6VBhg\Jc^o6-HD[bmqQ,agM&VfnE[%]B9+2df"h%,Z%(`%!jcrK[9,;Gu=0[r0
+%7!bS\1Dq#iAI.u)FW0k<*#J2C#8O9O'A2r:MUtfD7Ng<r=-Pp>T&oF)AKXCRI3K@RW<ZIe4Zr)?+[!dBqa$NR^j@b-aQ`(B^k*0D
+%-[(XYSqE\-c]q-moMH:j$@0=.Kl0X!l8hZT,XoImgJh.SNe,#ddtI3!#q&#g9c?/[DJ=1ma#Gq%Bs\KiS#Vk7dQkoO;b8tBN]@AS
+%W"YoP<W#rK<KUBq.J7RQ=^?0tj_>6\<kod0Uip,W-&I&/HG_ATe^XLe"&:D*q9GXi&U:B_%Y)t'lMCj;L?PmO$LjhNWUPF'0ci&]
+%kp8b>C2h`V+\<qu4Y=Hf)JUCg02^PIZ!k#R$+PT+M@q<'KmG]2fdIj`2,BajoSd?moMeaV]lB"d3gFs$?961Z85BhOTQ^?''._+h
+%N8(6/"GQ,<a?(jIK@YJaFbRed>9pK3=BOc7I&h]9dOD)o(9a3,];4<CM@1><jN,$\l4tl_G9W_a[>e!X_:rYbOs4md&IktT+O2lf
+%m*KkIN@Um^"<oHok$q7*9qD6mm"f*!\jS\<rJiX;PTq/MDuN'se-l=NE`MKn<eNmi#s'=go!bGT^sbY1!:Nn,WBTT&E*d%Hm&`Sq
+%TNoPbQ;M@LP!C!Qd:!196+D06$lSP?<QR`\#'6RZI4>lRMt/]^OOGIW3%)"p!\_j(6@*I:o\7*8f_0LjBU,.=)^QXN@m[tsn,#qQ
+%a\;0-4:.Oj_Y4Q;n)WW+`!Ns]EgCoM35><Rl6'u[l8@qr9Lp>sG]]Wp]SMt\eN*a5e$1WjF0p.G5]IF5bRq[RM;0'c58:rM3&UJN
+%1S+=MoRSFSjSe$!:BdZ3"ss'GC@U4\mOrO!l?$Q,YiqC!%VZ_-esLP`KbOcK8j[#&1Q`oE)ZQ[5m0\He/chZ8.1.72f`FpE7eW4]
+%lbMJ\U#Iq=59^%rN*hTK)r2^1l);F7f#1,srZ>WgXt*/N.uA^@rkjjOYRY+`jE8ku<r2ku:8!kR-$B=^pFf+,O[dZ%[9KY2[QPKL
+%*^7q2(thuK^c:BBlH=Q%3+EjG$s!9a@m,;=b;2lP:@)s`9AKHhTm9/8^_X*/&E(S]@Xp?@O\F^;oGNS#nFD;$e'5%7':$8[JqJK$
+%37\Gf51j)/Z,iq$nFE,s2^LEi/e2cG0,SCNAcU[tAlo&PSB2PUYG9oQ["C2sHN_/HC]Q6HG)FAg(Uunk@"@h\:P-R[q_>rA8(E%5
+%5^,m,LiE:j[HT6<@Bn;p:M\b1,92`lrMI2=h]ai@bJPO$F2BtWocT2.7r1'nT:qVhk\>`'NX\?`s*jc,@Ri7\#hYiV>$D41$[B2e
+%+><p-mWKeXa`;L)IN$mQ,9$I`cJ]SFA0G4M/I)*tm#mQ+__sp'_;H29oQT"MCk$MIjHobl4a\]1aQt_h!=J:>"MS^7YE+lWM`@jm
+%GH]nD'sfo@OnX16A#Vst6:?.1j*mDa;A%)[?hB:M,+[gQ91&fM)!er?kr1<X-LP=8;Ql?eCp7Mh6?)90aViKU5OVjP\.9F]/0s_>
+%::&aRJef?:1.lXScL,iYRodOXLT/h>-.Xf9:g2(^d4a>*6$LSBEgo5EYn9C2F&E&+&Q'Ft*^k%:3s6@N2'N5+h!PG`hBI`?!nR68
+%(,-p_?b01Sa8)jT"&cnh4Et":"O`^9+sZ["Bntr+?Z.8qRV?L,J3St@5p">\ouRB=B7qP?EGS(4dL3_NYW!SE!1Ns8HY29os0D9:
+%$UHI0aU<mV;P))V@DtW>BDhe&]HIlGf=!mEcb9u0bgZ4_MYHj4<<@e]0+Wbe!YSbU?;Mc0c.=n%Dd2.??16]FXoKE6aQ3UeFt/!U
+%7DOA':V?%N!L1$a!.DhbJt1-YUa:%\B4::R"`g"iJ]G2?Qkj)>&JCl>`96m'"\K:4FIN]Bfuk:P-9\RRH9VY6Q8H1G>JC..b41qS
+%\%n\i^:lO<er<n#7<U>J8f`8/ajJ/%NU6!4$Xo#Yo+KuND+s?drlq=uc0*E??Uo>GE&XB+DL:_X9oQuQi9.ts%o=inUeYYGqY#/.
+%h>l,Z6VY$gh<4/\&-4tDlb12RJ&fFhrA;BZ%*m30"l6rl+'cjkl)@nq.QPKiR"').A7[n/!O^i$\&L*">NI.q5oKkSp\8s#?c&Ae
+%K^KVpG)MRCqpF0XC]+:dO4!Y5bpO@rPO_Xc9-hR*<l75-]5$->jDB*qf9N2M5X2CG@N5OG5Pf$FnhM`ti$da7Ekk^*_$7nZbWt'O
+%rdJr$9-j-%*l*9!"rK/;^GLg*Hcn?Pb#)ukTKA,,]Lfe%2f2&OqK9L[Ql3Q8h+I!_R8qICGi)nB07-L3ICuH$K91YP_AgJaigWX[
+%-W+aJn;Jb\kn_*DiUjQ\A0&T=&EG?hD#7)p`ua:l36B;5p'/RB^\rPeX;MdWSU<]7l5j%,IV/'pVeCk;oq6/B\_eNe"ShrBQ7&5)
+%ZEhZs,P0M\W'sjU;jD<OUBY`ui$K?X97PT4^jVs=VSQ#D1\O)LlDoQpI0iehS(&I;bk2)fT]#1=K)W>dn!noYqt(!cf440"Zn3uP
+%[_O-)g7Q9i4sDPeG:`]5AHbftHg!'Bre"0&(/pOnIG>d=,=@?;!\%.51f`sZO1pW_IoHG+6.(kEUYs`G)7P5K_bMkZ9&6N4N4(TU
+%Nm(r^E/pSq"YK(R>K;A:g;4l_=5t4m)dSA;'m5VuPI*a*niZAVpk[Jk$D6%YT;]&^=@P@G2XX:OPNFdi>B]r"N;26]*ZG,df0NJ!
+%:T2ILW&WefUtE"5b+LYTj)CR+(5H:J$m9u3[RM=JJCU514hs?*@"`fo8oWVqrk6YN&8a"Js-iIq%T'Q(g6Q%q+>bcqJBn;p#N43n
+%fqV9=$sp$Db=#j,Jb-UNV-B!0\)7pf[gfuO$s/"$Q*$/L>@s$]F`=oFK!->f74JJfi?f)),":N>E9KU(dK;\7JV.koAk,T7gB!W=
+%l;OtID+(X=\BLW7;=4^9&,pljbFtm;["Ig#>Dor!/<DO>5^D%GlMBjcTaX5MMZfs)=1`G%NT'gsn$KkG(-,S2d4)-s`bZl#!4."V
+%PF(#pmD]oaoWGEXL=PTtDLcYYc'2gf((n^$>G*>ZT>?H7"uL,XC\nG`XX.$(AC!LZ"gG4B.LMrC3E*dP#,C(3\KN]!^.*?71F.:X
+%6U:/<7L"p/adPNQred>oTOTeQ..3.3EG)FW+)0XbRk);%'YDbB@c2FMgM[Zl&E(-;],5dbNtHR4j[Zq$J3j!o/R<nGApVsl)NHEC
+%oCO_2ks5D7S<^9C\ZcZqH-d,>MUe/C0S4R?TPdkq&+J0s*2$r;r!^.p&-<D]k4$%@aU8g9%16t]g?o$NFP#GZ;;5j)\^:2Wd#2K/
+%d^V>D#JptnU)n>f'%cV7"IoC+a<S;l5*)NTL-=#PfOk=tfh>b^9r;2u?PU<$9L0).j8cd[VEbL`fTsPRReX):El[_tkd+kc)(WHD
+%8\&MaL)8tEccDJ4$U!FNRg&e!6Er]3pfBEIX8/>ON]$iaN%!LFc2*JQULAH))narVG+o)$:d4b(R/\&[,iE)0LR4P##Vq^hVF0"X
+%kpUd?7ehYW90i"h.(EeJhqti4,6fa8@m:['!'3$(bgEj:*I\mr8dMprW\"BR>9pk^?XsI%f\c0V>iBhT[KV94BE\9qTt:A$%#^4S
+%oD[A"7G/mLYrP,6pZnJ47cuef(g"Yt=b?6m<jdhk..\Gem\-$tK9fdP0C*L)%l4j5pQGVh]C?<>+2aV5'DI]=MY'+Y2W)`+?'ZcS
+%SK`?&2`eVY&b51X?6b0[P;.ZJ@bgD0A13OGU]'\)Du9T^7MO=:P`YtR+q!9h\=MuhK#HSf;41oJ'#D$rmM4'04ZG:HK0=Jg)gF&f
+%=@%j8aWBBbKIa)-nN;GKV@E9F#0Z5:IiMBcK&X`?O2H<YP[B4HQ^1]hjNg?nk_)G["Vc2N?s>\<&EJ=0aE*hm7Lk1>e!cnp*+Q6t
+%cc6=/INsd0][LlM5YpQf@c:;?mu2CQ$bBd=r_;@W*B"GF*Ln@M\S[5Ddr7)OTlqp/W<aCffk`m*G4;g4EYEE4V,P2V3%]Hc!)`g*
+%`G8&b//\Kl09'?g?M1uo\`_cFWj2IrOR6j"PBi<&a)oO-#n!R8<'eGo)7Ui0$QoU@c@Ea@p:=Tg>c8Ei(6g'/K1.=AIBWm%2!YEb
+%a9*!Q)ZRI@EDd!Z&m_F>g3Kr.",N1g$AaL\K,9G\p5O)S&02k">X8tkC?p>-mdOd\k<cMfM'iEWl13XTeB#GH@Wpb4WB6H;[s2J?
+%`<KVgRlXX>06hjt=:NmC&<jOV$Um]$JAJ"N0&r?P@i2)eAUMD/S45=;O)@Pu!SbB`ArLkfF/61ilMK[G-:%cGT\%Ma_g+CZ2+C..
+%2C#_<bkm]''1"D<1l,S.&/K0Q#0#-`9c$8&'=<GZM_*<uO66RJ>;lrg!Y"d>)MS<`iTsc):hMZbST$<"6+0=pe^dGc+nl%2L:DOn
+%\AETB@I8@"Kd-lGma',?It?c@WHTu1f/HspqX),5'MpJ731!Q=:#/M$q+;5YTV9V9!,O6ZHQ[rSj>lu3OJa>M^^(u%5Ro!REGX+i
+%CP0.aiLrrSn])c)0+UT]<_OeO=m3`6>]3u9Y@,0nBD%p*\?HC#Utc"3HO]S4T.s')neK:LAROS`PlJ_/_m\SX>Nd`5a95/:WMG)*
+%cQAQY/l9>j&dm9!?_J^3CK\LGb=Eg[?hY;lSi]>W"op(p;MR,2kI$d%NN?@l#.h4P)um;tp8q]57A]BYpTh6n&VN0966e<<c2?@B
+%OmuEUH#9%*F5:;639SRkN/YKGpU52ge/j[G@m!Vc?p<)BhjHWnq&I1#ZGcU%&hN/1nKpNH[#Y5`FXS:Kk*]jcY`N\f(0aORDN=k[
+%Zp'/s_b'Y+"L[MX=8=7)XY#%cN$ue_g[t`Y4Nd?RPnU#t(3W)@k?j8^hI)^d@&cm(,3nOl9gEGk57%$-6LA8>>Cd`lQUMM@j%t%g
+%5@Y&K(-LG\H7]c;Z#1YMq>QFQ0l^!^k4thl]s1=_f)%U&O(JT$a1IY][W@V@2UFgM.:CO&^P9qLIIHdS/V(LDIr&=4M''Ql^Ae[)
+%HfGB89I$YJT;!D8j/&Vj>.>siUTO9g]_)s9CUcak?M;q;RrX.f`.FX0CNmk2Yf[tADt:OnI^T&*/sa.?'E6XmY-ne@CN/DJl]q9U
+%<9\`4.]55..XGgT3U]p^)8aO^Rr6?YCn.&BBK7kYaZ;jOa#j(1#?-9m6gCc`gL]tWL,J/lPq5BRL6FD1'&3/dACq>ga9<W*HYMtu
+%*q*sp:6Z-Vi+OM7BP?,E$hB$(qiWb$W%k#OUS[:!-siYhJ[RJ>:3X[<-Fa,@hl\MI0EQ9;<Z&.[p>0;KhrCAb%Aql75=S]bOk:i8
+%A(:4mq!QJ%i1GYA5=V">&;a`Um12*n&V)ncAMSbP&rn6uf3b?02d,_UZb>,l%=AP\J&7]E+n4?/(J[BiD\kb<NFhj=9>lmD-bL.s
+%]AW[lm_E7g]R_3*p/Lb,p7Y:D$27#E+n)kI*hX!&15!T,R@nuS"EO\6Rlc0I+'m>Y4=j,9./9*i5UY.'jFr#*g1'a)PS4E,1O?lP
+%]Yq/,_"+UmJ-OKroJ+bQh)Rt+*tgPF6qHXQ4_LWnd:X9tQquVpN`K3A?M['q+p.(i9FE4OTJ,r)<e\;Whc(SkT_>Id9OI/K=%us.
+%-eQp`h0]Z,ht65:@be<jomE+0T<_aOaG`.###,nTJ4S*%DpN\SUCFYkkeZR5N3k*T!Z?Pq,^?:I42Lk*g=>XEJFH(.J"s+fRgsAk
+%::]II^Hn5q8,U)26eq6Img=UnEJVZ7Jb2YoE6]DRkoRYW/oE)H8ajRjD/)gb,8-dP:Le2;^U1s_&`C5g3n[.%Y:i\ao!m=q!h$'s
+%Of$f'7)/^MSVmR7$u@'4_"[VX#^^g`,.hAK(l.+(LkkglGe60@_qhCI%@&SO;/6Xf_0fdK/\)F@Sro[R]"j8np2)(fg_!%nhrr=R
+%i5Ta\j;FA*Al]d7BJ(H9L8Dmg4=AYT:]XOD9LFkghWEd3Y`n7)J-]m-5X#P5pX"P^@GI1(\&;""XL9-;+sLCQ9E?EO.I`"Bh#n8t
+%!L_"-'!Tn+\X?erO1tu1gU2#1n#5C8Df@DVQ?puE)n(sHJhoFm<\nd0P2&Wl@R$7-fkgi%D,N[L)mgYOPA8gW,u[.2DICsg9CVg5
+%_FZ#AYmeVW$E'ma?_Z*UZB*Z>p1pquNrSC8b+.PL;],U72,F.A*3*)3A&b7dENPi+kOU%0jCW+u$Ui47`0F]11Xkd76!8/-AJ9E<
+%XR<DEpW0"F607bZ`im%K2QrEh"BQ;U9TW2'0<jUOi7[aB2e5C9$H:7B3j@$gjI9%I5iFSbonY`L2f<tD&3[u'2sOmBO*5@Zg+n(>
+%QN/2B!8?Xll>;CG:ld^Z0RC*=GoIX8SOKhRGias^T^ufTTO03jrhB::dVbH^Ag49bEis>VN$-495Jg1Wgs0-#:>a[MKB+.!pk/VY
+%_Ka/U6ig,4?XWS8#IRLE63u6&P%bHU[WI[:&W(e\qtBboKJ/G%1oUPB<!Ok&n5311P8EFF_:5D#4R_eE#H9o#7c=qtHUdR99Irs*
+%!XAb)>\<gO>a>l*gm6[t\q!GD@LYe-P%Vbse@pOs<Ht&#Cqo1E0c9!!=7or;?>C7bE3S)Lp_=*>^stW/pRO$:"i<gLBgd]V1fG.&
+%PuT.U=[5\K(nN^JpRQDZZq!!8;$%4!(SH9b_%n5&KpsOT,ca6[7VYY)K'fAcFUF([,jq_rS2KG$UTqnZMq4h)c6P)4F@J[7N*o)_
+%]Um=!RYl^%*B_t1rB;oAIW0GfjTef5#lbh27#Y&#TohCl"'0[l6DW9nIdXVGqLrHQEXL=GqeF`Y+Zd&>HMU#_STED3=&pojpU=#5
+%B!`(H0A<X8a#*pg3(,;OC-iAC]DhTj&RF.>#rC(G&'a[*h_U7=EXAu(_\_@K:+8`(TUUJG+![:E6knFl*e2MC3OTWKX#rMnMKDL"
+%C=j0BZt,E^-fa>=b3r)*bc"*0AA]mj/5ZDEmUokqjM5W\GInEjVL`^o$d#Tm."_38HY#7MI;&E<)`[#^1?NVqNu$]BdA9?18-t0d
+%[nuCFaaTHAWb/YY_]r,<A#>fTh%)g[pUl^/j<1)AI\o?].Z)1mcF*b*,G2sX$7In"FdIU_Jnht:)QYbtm+5]&Z\lH>(dMl%B+`gt
+%[M!*'K$c00/QPQ(7^qAI[R+R33F9n8ihS5`^eKHF(D2FF/+#c3aum+%[\No3Ke;_Z_b8_N(4'eUCt9!+G&S\t+2RD9^hXjor,KIO
+%Hh<ZY_@/i7QEjX2a,Q:WO"Y>A`n*6Wd'h&3]9<Ya+9d#6G].qZ8ot&IAS_G+*kWaFh72WC`:%@:]JKC(@JI`6LnQh]l`9BM!P[ui
+%b95a1;<'1JXP$1eUL8M(-D3P5RcqEF>4DPk%Y;nDJDZD"c<$CT-EU2/N:<-@I@[iA5_7U@M8^V6+ANdb%KV'l_:]&.+lIgWhEE(_
+%f.QHX[Zul<D;8XQ.0-1l]Ja?N3].s*k?_0[Vj/AmloB5"mKj&TJDYlp./el#E*eG#<&UBk^iBT8R'p#rA[ed3!?>I?[4MVNDQI4p
+%)L(=qRt(Q]CVRulVe:X2Z$Z_G#K<Je'3%jKF>C>6S=mFMGL/P`-YPXogJ3pN+Pl$FOtk=?P[gA'lZgo&3-h35UI?E;Hik5%s*F>%
+%WD`P+dig%)eD,HsR.HK*#JieeW1sqIIpXn;;ZY'cAd'rp,m/PS*;5i:A(u4jRt.Nq2E6&ai"djeqC$mD"?`u!Cg/$An1Rdnko"7+
+%03pu2YuEeao<T>Ef39juBgX_Zs7'd6'B'P!D8(RM20lpX9heVR2q\.iLTTOf;cPcA4L*pn4jCUr&t8A>ApC@>Pl,0,0^FQfb*7hI
+%@taGgYjtgclZLgEG:0PB6J"D20uLi`e`Y927P@(qiA,<a4l`;QqU(B8VkRO9pfiYId^_%*&(Css!>_-7_f!.U'hYZm*DU"Q]fI2*
+%%Kj,rF2&gqAq^eO&`f3XY$4F5T`>3R*G'cr$"UM1:]:6**Ku6r"`a#Pp/b@+-1V79!=36]*!0dpqZ6=DGiC(8ThjK`IARn'be!+'
+%J1r_,$rl_=dLHGX3Ah&68V4GZMfOFddND^5%-t&j=mZejgLa/\G[HO+T*kp25_9\hD2a7\Nf+%ri)/hBpo%e!efM&i>SE3,fteeR
+%1^1=r"N?t7i-HA301e6m$t1"u/&+W$0Lb1N%;?!p%O?d!n`o2VRd^6INgp6V"\MaUZ"ZtVYRk,K"JBB%%g?@\0R#&0-;6<feHp^a
+%SV0@M[RjR2`V"@-_kCakmRPGkqK%2+@\%:1nsj6M1_]:G2EhH%P.%T;[[1kL8HOg#>#/Ur^;Sq];m.7NOfh$ZR\.A.;#;.Y<!OqB
+%XL7\:ZVeNY[e1!8/J9&3;"7#>),$eAfQo6L1T%R6'hWh7B8\bUD?f)W36*/D>I+/Fkl*"(TK4EPLr2dfeA18`,]IXpo)!IkeNq9)
+%R9%(SpC5`Nl4psuJ+l=ZX(o>FiZH'N!$'o0_,hZ<9EN:!JBO3>9C%5#A9)Jg*!S])o?nV=-l+V='-8CoY09]_q4saL+V6+1[@)WU
+%R0AtW9'n2(nZH3sK.<066]$U1:nn(2]Ygcs>&"6+23mr!Vc$fU:qZjsS.&okf-dDb3d&7I_tcIZZ[qk.W85o:ppVclQX=qd(L6AC
+%H8Uko+2GH+!?A:4X_lm1(lHgHqVCPlH_;/g(3O:kij'-NP24aJ]EP-c5R1.P)8s1El6'[LoNm`J:>T"'"2n(%'h6q5BW4Rg]9Tgi
+%LTt^^(*<^A?\.k1o!&$!H<[D+V"(Dnc:aCR$igo:,@o!#Y*Z(M6Ytk%P.#\V#`i&n;E\QI+t@5AkmG\FS.U9=0*GR(V4-!g-2O)N
+%2K1d>H[Wk_bN=.>XffEoUX<i'NE7!S<gW1qT#Bf%KFa<"W=+kM3(oZS*n%WEM(c2WX:"bV&0>")37V!,gC%QBDpaY'j]XJd#l+&s
+%Ih\%%fMje60"C+o1'jk_WmnTfrR`h:5S1j+f40JpWli5><Si@MCN.g^>G#b*q\6"5h@YK(C9$hFhZWlUkbHKc<hN6m^Y[["+f"^2
+%5Ro$S;$RmRGR[AAEV[2m_4SUK\ekQ\MPDbGVcl.2m=2UdE4=bOU-^.5ruJPi-GWNm,/:169^#J'D\icClb6YNIM[2W)$l$nr"H<$
+%6jjap8:GU-O9jT2ELsOZ#DK/01lrZ`0W?lIP#_5Nba2ErS-G.BJ9/V`?2.qU2'T@AIKCg&@[",K8S0_86%%,C0hGB=!gHnn="A_#
+%B#[.d((I'^<mhi7P%uE:R!]OYD:N?qY_0lC$hoao*paL12Y_3D.B.QL?6)OUZUUd&C1RM]MZ6aU*oI8"C2?U:AC]E1$4RcL3K'"6
+%7@15D$#A,/0VV%ajlHu]@q]*%;T/[e_"<"hg4^en(k^U+^OaVI&Eg09@7bd`*lY_?ql<j=9u%?@0eVu])gL=/at"n1QS;hs/8_/f
+%TOp-MOqQ;=#Y#?--lLLg?<.&L+/E5AN&^<s.@aa26'9=.'62kIlqu<"pn*$9.nQQDW$IYZ(.B$]G%jS`%Na`oAC_e]pn,%PVVE8"
+%iT'6):6)]`:G.9%Zu0_D(9Lg&UBi9OTO7q;Lg9a8G1"%EGu+W_9n9\FL])OXXg8PG)B.g:a]J(6G;sf8H<<54ohfDu/qC<[Z:G/S
+%,#eARc>MaKWrO!;.2jKiFL/'n8,:p+:q9\b-jA+t<k`>%rcGc\Ej=BW-10VRm^:Z]8boAjGQfT<'8p;aEDs5h\2',C7;L(?3.R-m
+%HY(QWZrN4^Esq29kW"f^.@c0gK"PDKW=H5CeZirf"'G"<VfpJ_[2pI);Cj;?jRUG54]"*UlP*$(_Q"Sl$;pjdkh<Ikcp7Bf>I)[Q
+%D%"Q]:BfRSo_fUgQ>JET;Chr>:=r/4cEM[R':-!?jf?0dH)C^Ke,.Zq+4U^^$W2&kf1*5)[5P']?:BUI.D)QlBl^DcFHbVV@r+e.
+%X(Zf'+LOP9b>^"N0rH2$KB3CO`>3nh$7Im%kt3b7'HL&QeSeB$pc0W6L*Qhe>I7:_focCDVN[s01ibFWI'?%&W,7`45Rbt-C+p"1
+%[=rel029J&#H!#*WJ?"uFXp+sYSI'9-K0V3(mO\_KU2F@ILcqn"mk^n(6P4["o&nfOr9t+*C>!P5*Q7Pidu+t+N`RQ^h;dc0__8l
+%Zo'_F#QdFI9Mk[6)TZ!q-(#\t2ab93YUG`W<X9Wgs62QArq05e`COWQH<1$[`j,uQ,Snk4rcsPS/1k+lQ#l\KJ[R*'QX1aeP\^3'
+%07QVC\n57k@2W/?Oc@@qdcPsF5h(6)"Mc@b!ceD.<%#44$<Kij3S,%3ZJ+hXIcY9,a5_km(XPF;,6Wc8ZF;EIF>"*)n@q!g#e-@-
+%"k:?S0q?Q[+7LJEOc_68)Yo<l\HS/rYUFFC"3.XgOsGWq/O@=m%?+s4$8t_0NsS;Fff(U%S"#:-/bVR_"B6<_Rg.R^kmuF_%!nVj
+%0j\pg+EH:`(%$j)+r4:U1DCb!i^4C\<Cjcg\66;(0!<%2]Y:kg_6m=:=nnk@)n2E"D2!/4[N:%WKAoK8!O[-^a)bc`n\W?d=f.?4
+%jYkq/5)-L=&_9t*75DI9@8!K:2GaMfS:agUm(l$&INa?WQWRk5jVmAB@h7/?L.&hs''V9.A=qpa"G7)m.f0H4+sj.r">b>95n`;k
+%mUM'Yg$NjC5]$4Q0:5pu]E,g_gMf`HmqS?!QlV\AB9;-o*D?0#aE;q7rDpqp(7\p).TO:LJV2jt.tE<E9:1C.Jk@bk%^_Z3-T`=4
+%KsE<<M8b)69Bs2)Xd<"L;%U*Wcc6=;Lt7]D2%Z&?[,t)<P9[8;5tF8AV3FBrLC&$oJol0,?W#3aHj/I=,ep>l)Nr.#e;*Sc,[FuL
+%XtQKS1XMO`^6Ec$A\pdL*_M%%#85(8ifEcU^6IW<jJ!e?)$u![Eb!5Mj9GQ\RRSf/R9V,/7A!)jZJM'iD.Y4_CH*?9)sQ,ZnI;NJ
+%.`qSi9VTYK/]tN@Q.[QJh9Grt-:$:N!0PEiVdpbS74\63%j3l=;$M[T$NAZnFo+4ePqkE`073lMX!T13UfCr&\N[E4@Ee1W@+GYO
+%9X"bD`hLi0q,ZjENL7&>-F5V!P!TMZAl200FacPE3*3#0\N3`*Q4$VX@G)!2O@:u9c!inTgEA!`gD6](F,qkK8m81o`/FYAo\De-
+%2QaLL3Y.^([1$NhDu;diTFK.2"PJmuU``NE42@#mOXD9j<nh=1BI2E<=HAo(#,@"<malYBnjia2j@`pkkJ!W#.SoVV1JHb#WU.j6
+%4-*)2WqM`n!-P_[6LLu6_+L,i)3@2V=')3il;2dOmN,)`i@SV?kI7H(;YLKuBmC6G9&;)5?Ph#fqS/*e?iLRJ650a3Dd4@>(Hf=q
+%_-i=P"rPS";t5oNm)uYRP%6Fro1/RueD#Rta.dRW"`7,IX*b>GO`YV_Q6ZL4)<['R!+&buWS@R[HK6mLn/ajUPCJ9d^g+m.O-A"/
+%AXr3>/IhMR4K^dI:$Rb7``>4)>R@r?j'h\2%Vsn#eU+H1DAM,K/l'k%h<A*T(:f8PY%oYW]LS8ZZ^,n.[e/oDas3@m#4umkVO<"6
+%kuJkZ<e\oYaGQ3cFWI9@eA-4!b&Iga[CpVhat'LdJ0rMB_(PY%(Z-4$0/<Fi/t05d<%8b&&;rkinGNWqa`#r;X@[!IcR:r\(p7Ej
+%H@X,bXd;(]IKCt+$*](nY6np3o=`LM]'$t5%R"ap^1tugJde-G0?#rTq6>Q/:g;L67(uB$3RZDli+r&C_].MT63.8]+DCl[jS.5P
+%8;!bJ^B$!B!1@*t]>7HNj%D]2[HNCh`lgI1I]j^QIW@A%ZUVI=m64^M?sm"jE"]4k!H=X.1*:a5:rp>M7#a:Rn!t.YAO#-bQ;aI7
+%V5R$qs6(8+=A%5/cQDSmUK!9ukYb::@BdPGJ@_U"ajV_`s$MAYV$C!\U<Gcd)*#<Pl_W$@*`O#>mOO<frk5JE2tU1eKmr@hkeBWL
+%lu6E3^nV)QO??3C[fhM\""gha_0'9/>LJ<aYAQkC.rNWR'dSO)Bq3]LNKsF];<PX+%Ora.38S:A4^%t"!7%k:D;-SVmF)8:i9Gm,
+%!nK<U?u=R-At(U.Nh)4FHTN7lIPC4\g:$DYqJ0,3NA4P?9AVVM@ba8Y&iL'GPhU'Y_5EuY!X`87.+3$!f)]n#TEe%?R6*`f*Mc:S
+%YFsJI)m>6)^d3%GJtt>@!pWn[Z1WIA+6")\s0?afOg%+4_>T0/g:#fc>qj/C@-_E^*aE[r@,ZHAX+P[4ZF7rq[Wg/1h^OhjrB;H2
+%^/mn1jc#2Q/A2_+^B3R[SO#PJ)EkU5']93aFY(>$\;43WhcDMT]%#i_hn)$#RcY/N9XnS'E_D=84Qr$mn&m.6:Z-;B"8)gc^k(8$
+%R1*ZH^,o]s?F`Yd:?18<[t#qHj4-Q^@A:$Jenn=6o;ooj3Y-E+i/Rf$Xr6#3>dJ7+lQD]eLGS)h_q$BPG,uYJhQVNbW$VL)NF()'
+%]qp0:kq&K-jc6/Q@o.<*D@j&Kr$Dq<MU;Z2I_LWgErl#4Xp'#W3LlSJo6nV>8p`8$!n\"Xp^*ug9FB=Y-GajK9d`Rro7jk/ld]V+
+%$]E`8hYfIFhY@KJ,i3KIp[t)pZI)!#0.T)fTnJ`fV(l?Gpkp/[ERD@L4tFEV+*7OV9!Cg2']r6[jJ'?3Amm_(,)Ed0E6/^=.b1iD
+%d1V9l/bX7bIJ!A8#HC(b=Np7<B2D[M__;D[-0sd9USQ,AS5`DI-kF9=_0Oes>kda9B(XT]G86OE*]V4qjNr^"/B:ruS6VUj5f$o<
+%r@R5<]P2(_iY;H'DM7$L'BgbL$J7KEdN=3bh<"nK$uP7'X#2]&c^I@e^$\Y+(S&qI0\EOf7rl1qJ_B)O?5#'5G#-E5m0:&4J_)_n
+%(+`*bMqRPuo9#/J[Qr%.4J+1D()]Ep;QH`!=1Q0!H=[\Pn=e'=l"h`3fk+]1.*\a+#Kt+:+'71IV_-qSmO#8C$.$(p=9dd]>%1mR
+%6,PFE\@$0WW!ejG]Ujenmd'r!hl?FR+O&dh.+\D?g@AgEeEVVN6Fe+CXJnW%Q&N-WGhneMm?74<Kf3fo.6#&P3=K<VH)4#^h_8NC
+%]a*dgg,t&=YT908*Ab$u$(c)#m<g4bK&%e@K;`hNq@s%.L)pSR3C)k=*'D(:0W'(gLec(/B$\13/lUF#gNN?*\5`i?;ab8!;<,W;
+%7aUZ*7_hJHmUddZS3KHfBUVd8!>`k_S>[;o1gmN3[]bKCbcqWH6k=$Mlp`IRXQ*Bh-u:OoY3mKlk*["kTF68,BZ[MtHWAkH'K*\m
+%/$f)l9%U1&XYcH%II-Q%i*$Erj8tTje\u>o1=Uk:,7G`MlON=1^j2gEm_f[,0i+cS_O!8a`A6nuNfnJ8fe\>lmI9p6Q-ZHV]r#*Y
+%DoLM&^6B)P<Qi=")t!9Ah$j0h-r2LW\&1TQUBO_S`<*T$a1HJ)"V[,eF/_84/Df0GA:3:mU=he8mLR47/DY%fM[e24%^RAI::m`H
+%-IT"S#0'!E@?6hW+?+C^lP<RBDDj10*KR%sW#Rf*DA3J`!*3'r]HW.O+P*'//[L=l*_@4hbi?_tL6(Ga)S`c!I`7_tdBX^dHaX=b
+%K<RjTc]IC\*If.^bhi'9.P@p07GAe`7ZSF3hUVWDMWC10Y9d:r[\`:>[/V2XQ/G@ci.1S"$n>VC8mG[a(nl,*J/tUVeut#G`B82V
+%L/bPuN8@k*(<IY"-c,lD7V;c>rd',A`]u2'^bMWs[07j#`W51\;-4mT?pUH#(Va&H@/]rZJu)^a[[Cm9RAuq6WH]C*Q&^[d9pa/$
+%#Ql_,L<Q=I9N@UsPT\IT'gM$UfHl/^R*=+E"]ikcZO7&,="(OX0[B5RnGG_"?lWK$Fli':<Q$WII64BgLOi-k[=LZp01i)RBJ-<S
+%'kZ8Uo7T'f6<qNn`_Q]g*E?U;]MLep<pI"2C(`t`5l1M_[`EV9hPBRbR6mgZ65q<S$G>N5"@UDXd'c3%$L_El6$iCgW`fnR%c1%7
+%RK+])[>4\\;VN&l'MQ3Y>d2lAVqBZ)j:sj.$Ic*q3ID_f<+*Z]AQBnXDu>!OGF/An21%o%nX<TCms\gq]agsHR$\GQnE1`a>&l>;
+%D4/'`i$q_Kg`pmW;oT_sV@0+^kZ1/*bAoeRcP-B@h;tB.i@N=NC'Mp_."3)YlIlG;2r*%gkAa61p_$9kBbA&CZE@h+'/ohu=BF@7
+%n,"uN&A69WXSVAak8VWS=#O(s/B>ODHiN>$OIM<=S[/h"S5,6GdUJl:0;SpN=^r]GEP+46\%qk[4Rm1!;e1R'T7l17\5Ss*b*/FN
+%k?&K1gup^H+8nu0K>uc?PfA!u!4n:3oDQ4$^[b#_pS9V@cSq5EXYr[W0&0U!fEZUEeilJA%Sgo3GpKO-K]h<sH+1V2EMYmKT;`6%
+%dk)$C.mEf&>6G2cq[:IbK;X20B2m0]LrNA[`gjJ+,?r9IM);a1iRlF)P!Pd3RJu#O'&[r/T;2/=)`\Vpl^4r-4:L5q2u#LU#?`er
+%`&XM\cok.W[CA(sgU!dWb"rXM7'cJa-'"%minpYn[I!YcC8dI_XXnK<K0DE4i#9S%\^@<sF:89@SZ@N`dQ94_\9\XW,mL[gi1>V5
+%"tm<\B"!*#iDDQ4aNQF7cFnAVfet_2o!@1=U,BNI!KXqm#_Lipn&CDH8%Ff<)<+OR/aCPh@;IG75.@*qbDsPaaA?3NVhj_\E5!*2
+%m'pr?F;lS2Cj1UkV->sTlssLYmaldh`CU7gk%sbX<ek*YF2-B;E*746jg;98`j8p"$Y$]nLqMa4UB'T-mldU4!*;<E("p!&luh2c
+%eb%Z\c1iF)41f[^m+P_m+Kcg;M`e^l3(V=G"_E67(Hj#bd`gV?r'/X@h)\1=a7hNSPqn'`$gN5EPje^f?l$F1&2D[MeS?KRP5>\<
+%!bKO/Z,N3WH.qWjDC%gKh\P"`E%B&4J%bA+:\BLmKtX<X>oqaGdhi]1J:$$2*UgA%Xq=\0E=BSC&70@k1a<1EB#21TF]O&^FK\g,
+%]r($.k(^AeDRZ.10ZEGlEK0W)hgOA1ZhDrNmegXP4@0EccOb]k2s8uRgk"]FmPT2)cR3h]Y>R5i4)W_phojuHd'If<-k;\oeYV2r
+%4mk7!"h76O75O8I6C/QA>=Xo\X&+@_P;cFJ@fV9=W7B&$)s4P5XS3%-`6@Ok"7*Ur2>2u2J^c!9H,Qh697D&un!P_MdPJ<"eW?Eb
+%.\EXCR!J2Hd#&e1)Uf`X!eIll8$%=+'WrJJ;*edR!5&id'\*Be*8nET2)$&6WJGbRUr(_Te`%k]QXYe&=>7%(oZ2"_#JaRNXVkt0
+%c`/$Tb3%IM\_"4&igeE*RaU[30__#hVqUOrBfBumnp<kJbWM5t"Ik#@f$\CO>W[.o1k-Trh.G[1^*?+B:@nX>#oRP5Tn9%jRDq6U
+%4CGO\gL6dRs1<`0c=^kgXTRdTj?p`er[6VHF>Wd,:MpjCbp\=r0M>QY-#^j_7\j#>Br^mR#(#F8b')oeC7_)8PFs<fCu7!Wiac`=
+%%P-rD)p#i#46uIchrZupY!(!^93'B2:up4n(?_a!gMGsV-#rLEBfBMK8/hcc%P9Od04*"m**c,:>WcV/UK0(F-Y1?(O_mri?bY>k
+%fs-JJ$t;8IY>Te(0sJLiYQ(0"-\;]7R+L+E&9Milr^bZsJ&4)gV(j2NGF1rQq=2&Iat7cH+,BSRmF,M'pB6'C-?041%1LIL[:XWt
+%,A$Si@bPGgO4qe^*pJ.EQZ@&g.c]ZSW?d1T%q^^9)0U;U-o2=AhsN;`2H2O,<YB"#4.5m]$tKG*Ju$4T)!DY\])EF`_p,Lj[u36R
+%TB_PTi)s(c8k$I0^LCnlX$ikoWQQ>*hf\9OV8:=A7\jeBrK^!Kb)K^#g5++!duCk&qslbjK+b>m@T!jJD!Y+#FeP(R>L-IG>l)>n
+%J-pIg`Ss3T@bI?3S0Rs)P!WP6AODgWi:Tpgc\8rch.Y9uB^euFEn')TiY2]\2;N,%$HQ!JrgY+Klij+TcQ9C]+_=HV1:LSs\@&_b
+%U),Fu<&([pH4PDL,(U(##]=?cCB>2^ke0+&DQ,%GbS';+K.;edHfY(3Z0f(UgZg$IhG+DC6$LFq2WFV4SnRe<&?f:qhAKZ@!YhNl
+%TLuslcLm%]B8E"ZMXXn:[Co[n1<[3Ar!*7*c<\</X*-VsbsHrteD`n^"&\Bh$cpKX&o$fnW&*K6;;C6FE<uDdP/ZanZmO-Q/a!$E
+%MoGXBN9H*)b90;-q#<WQ'`58T#^f-Bhu,1FG#\i]_OYnX$>Pbb+@&mJQ]8M_o^IG["JG1dm,[`A+$`$t."H9--1\8EnkfCZO+1j?
+%;/1YpEaq$/gGW^3lR5acVjZ'QpLoG5**,Z"/tdM`VgV.u+j1olY4,>Re./3J35P((#W$A%8j+-*1*X0-r,kpEjC-J;H^d1F6(B_:
+%8LC!eJR'P!o*n+D>(2q/@4Gd&Im*Y@8*aMLCJ:U4=LT^LH8"MC\'6SK!nnjWhR/IW]rg%K</n1QCHnnrRG<1FI7)s,Gt/<S%YoSe
+%cCU(/AnjgW'a#;.8qR!AC)]$k^pa&VLiVr"h?K1VX+>PF-s2]Q%F,&(X87!Yb3YM<6;CXhO;mE(ASclIC=i7.$DW8qG0N""H$?a/
+%p(>J*bn5X*KE+';jp:D`E/nnb(J*-H/9dTjFPdXK_Cn`2F]n(@ko:',@5r!a]HiDQ<]Q,Yd5H[`!Ld0$G]1U+C<i`/RIdDNkBoGu
+%!G;TA-(1dQaX<LV(h(InoLp<Mk&>\N26l.7:'39Sj%=GhN2s1#+m.uoC&N2Zm+]*g[_LG5BsL":K+-C%nE#Qm[A6"f,<FffZdcS!
+%aHVON74ZQ\s3*[UBu9bb3KrUY92XV9(<#;PkXA=HX'XtH?%I0BUK!.L[&0sHhAiVeD>T[!d8)/Ni<&LYr^?GGUkFb3"4S@Df3&SY
+%X/1ihr.XeUXj[!Yi3G^OcMMV,;bPD<Mk5a\rBPP]>SZ<-e1L\U;Zj4cYbkV0YU@Z:]_-`BO/di_SV+M'J`=SeQ(^_:H6S-K<5RFY
+%<@Rm>BF_%["L^0^FT]Uhmkiu"4Z?tT=AnXSe_6A&05MN.IEn7PGH`!^bY9XZkHOZ?1oK"`N*mFm"XEKm^k4gFpSd736pAn3f7^;>
+%]gCI"h1W!!M[i^&?dH4[:Mr\XXlUIsTPU9*]!LS,aIJ&jMtOVV4>ReLDVi6qB&%u`\KT/GM'.YB#0>..:1Ec6g6q3!(%rA$.#[7<
+%M3A?1[5)kd\M--C.DI(*".%_:cLO:T]ZeRd)@;;V9`.rS0[5Hoo]\Jcb#;al!d[+boKE_sm4Z9!X#e+>nKfa:^5!mO;F'>68lkD6
+%qj,sO+:ujtj;S/F]Uij3F+2*L1qablOhBnriq\?HC.Vud'UR8`q90uq7elra'e1Mb)[X(0O]cUV,P1de_L?1lQYdiiYSs@TKrf?"
+%N;"%[&?@c.N]!M%ODZpZM)4B!p?Jc*I2Ct)-H1+]O>RL+YV\$*p4a?3m)f!AA.7-,0gsF9G*!QY/HR>K$l@P8NAM`6S!f4Rd=hg<
+%9AX9?('AWVN9s,ik$&JP`lA;pIj?epq=Dai>V#%/_Lf<CJj!;#'CD(e*>UKBB4,#.JMZ5'MTO@5o0QC^@YWV(*$k#H'LM'tr>f-N
+%p/%b%aY72?I&%*&g(>J4':+kJ!t,J.T<KkKA\X6*6Z\D5f_>VjKp]lhnEK"#\`;^H^bLt<N:GK>Jbn`Y9?)r9f54.nP^(>C.$VeG
+%3041E7EZN-3CgN]#$J)H>AtB#bpig?AW_Se+hj@4AR*^)JfmjmD&GPCR0t5j3UK'p,:%)Bg'Cd]WU@I[$m;V'S2@VY]OrbXi>P=W
+%K-#usLGK-aarl.[q9XQQ3C=]g4Dq\8C+0Ue\"=as1dR2-Aac$Z0c(R!1@LV)nP0)g*_G17Yl9mqJ48H$P!Vo1MHT6i_%8lCIJ<-Q
+%kJ4aZ5pQe9^c-Q>Or]97O&@pf\M,tkKim[3KJf.(2't1IMVPt$btt6/"SECm)nfbR<?C9_?6Oicdh\>=h>5,:VB^N2r1On0INg14
+%_VJE1q4&mLCUb;lS0BR%;(Q,(+^KOdZ%T#F@E.8=-%Q)-5)L\uHJ65q"G,VS3-0;rr_;s.dLa-9c7'dg-PsFl(Yh^JTkD%E#:4-h
+%@/U!Hp#TEu%K!u7=\hPY8M>I':s<O9_9YW,O6"SK=C'F/MkI?/B?A5b$3RTB3sV8Q!<-9g:1]H#94Z\T<68?n_['j$6qrWk")XO,
+%'\.BMHUARIkc)Q'[p0=G/cAV"7aAl(8]PX).aAJdi*A?Y>kD"UpEYk2<gJ]0@R<?(*lYP%+b8$dcX^YjK>YuTQ)R8gP)<Uu-t'/6
+%m[GMfQjAM2ScLSiAf!7e<Pc0Nmh6@TR&Yk8\M#1UJc/2ua$!no!^s9(B2J!>MQ0XXP9_[gFX'XTDDF>G72<Nm,hDOa9Q:F@)eu'm
+%DB4"H[bP>/SP5U*Nk&V@=r3W=%2RI4oVR#:$8ZCI<CprEJ?8f;<2EtcWpKs]iPcQ2-!p'<>iVS/?ess.(c%BX201/IZ'F^#7WK]@
+%FD&Dh=+of\11HI*pNpMP<YB.\8>.[h%KSR&AD^ZjWE`r6rFup=+@G'+0H4TJGg.PuTcD7G`u6HR8js!IbXu3)'s#VD1YCb9+I@[$
+%ad*B^1+5a%]M/d?LG$S6XMQ>^>"'4Id#=Wi5j"H6?IRh[R"?3@\Rc=WH\G0R/OTR`$sO5l-qf0*:ff)RL37AOZ8Yk5N'9jc]f+RU
+%9K>3jb8$Aifj\DKApBVVlSPC\?r,p?W<-o-RUlj'GnL6%[9Wk]=c-(\`s".KHJtFIg>3^T?Qiq6]iE9ZKpVU-#nRu;]S_).S4A1K
+%9'C-J<Z`,Pf"J*m+n4-'-BfZ&m[@uGW3e&5rR:Y+%Eq7!kD]"7\WS:("?;J.V.q/j1'!`i]:m#NhCNGS4-E5Z@L0;?E^8@gq,eM2
+%7'`Q,+S>O(Of!"^DYq^W2VUug#0SR"ONc9O#[lTdQ(\Jk>+M[+)cFHJaQM+sXMC)_Xu&hkqUfJKb46ZlQ[&+6PENR/[0c4NG?;,=
+%hKpU"Y7h=Eb7KD#MbkH_#Eu3cNS@Hdj*7.,A"V=/q/3HFEpcCLZ6b[`0'q8B@>=0G(!,pgV,Nna.u7L`*pXqEl]oL==,q;o.Oq]5
+%^B'&AnHU+-Y+4]j]KOq*Q.Ssu*bd3lm(c3WT=Aht5"8"Q;Tc;++@#H?T\u?U$L[B94THoR6=JY43UmYKq*["S_]Ineo*P/'q1q0M
+%il(<-#[>8LDpV[H+Aulp?%e,[l4_6kH+(q"6>[;1I@omGB&HHc`UST"jkcCr7h3MX+%RGEofX\OT6n.i%JaK+TURP).1q4%!mBZ1
+%e#;Gip.BEmh=2:@_rrB7Fi7k\3P<.C]h]L\k7Ooc;KHH%!#ZN,_A:HfLKh@G%3J@RoOFts(<j!(S93;pf8Y',kFa)5p`[,DfZILd
+%QL#(>NA`Jke*V+8qNFN;3`u3t>^`jLg?sXPXed52bJ/U98bSgo,r:9rMd%[J.Zsi89[u9]Zf&Al*Z*n.CFp5,/d9lBr?d%OHS&V^
+%Mqej`VtV0g*Mp&0MD&c$[sI-Olg;f=Sf:]Dq_V^?SC8LBa1DSYbY&t>.0!sh50GiZ"/EK_44^IiX:,*X!8Te"42n+Ud9[[`A)TAG
+%,"2B&,>>9uK0U?Yl,,;$;M#@!"d*-l@655tI,/k90D9_sbSGF34=V.?/^aF,T<-1P23g-+/js81M0e`()Z><#k7-8[ODT_=[rIf9
+%hS6(l-X#*Nk7KQtNJF(eM%_]o>$%^R`0.Br5n/s)V<+RLMg/]qp-'K2!)I)<E)%:6[B!s6EfJk$$T5VKF4R"j@+Ha[9)'n<"E$Ei
+%KR^^F.p;G$T%O:O=_$lA+JLWTfrj714#23>baW6*I\tY*Ub$7sVVrr5$Of,Ufelu/D#Dlt).cS\/]&T?n8&'60b$tSrgG'&1:AbM
+%/Ha)Mm(djA76.Xukhj1_,\/&P$Q*+B;KpaVJH_"[^gL+j&cOsoQ<BI]Rp>bbX%*k<UY(XR)StIDKT6:+g+6ru0,q>l`NgU50Ub5D
+%b@e_U],o8akWZ.%<AA>?f3+g1X_^C6;`8T!%UL7)9oD0B9,-"JH28^=QutT:`lM;]"g]V`_"e:7AA3N/cM#_Aq@lu3!q1pHaIRF0
+%&qkJ*CO?8k]Gj-X7te(g[b-sa@BWN)1K]pg.nmM/M^)6Ri,-cO%1?NLkt)N7&m)!YneH#JS0h!po*hO4gJ&!'kE-_dDEBd19^>EH
+%b;S.cndX%0&Sf_ZpIS)F-aLc)>s+6HU$`&IC?k`%nX`1RlIssFRZXT&<KU(AZKud!KBITcO(?Y[5%0JEQcsa9#'9+4f,)>"&gc8>
+%P[t.$pjA$>QIF'hY$-'+lO:'i-[QEu&VK7.'e@eE\%iPYE,-@Cjc>XE)^s"r..q=>-hC\^3@I%Z+42aOpA<@_C2,>_8(k^=4qY90
+%TRu]#VfN_p6a]&>\iA5q!Vh&$n55[km&X1C"#=oH\=s3J_LcJbg_'JE:!%rlHg)Lk[/>=lp!tcCc.D-IMsEYpY91sZ#\D@Y;.C,7
+%,%t]H.dd]6q&&($>0NCS^s^Z>W*\8gi2^)e8$$)'ZWfEoX@C>e#VT+,;S'aHC'*s$Sf)+['sZBgMG%dM`u0oG[Q57X14oKR*\--J
+%CHXZ8p$dR5>[@Z=DYC#LWECVihb<00KEPGKeTB<k(]YPj6>Kf`?7C7*DTP0roph'm93@IO)osMV9n:+&&l_l=IfNaSB4=]M[YJ.e
+%QPH-)/XF$Uhod$P'S(;?(VJYi%q<*<1P:8^ZtQGoOql8/$l>18CCBjm.aN!@:DU_A:!YNMXATP0FSHKHplt5Y.UuG'[FKM7Z'kh;
+%-/VMDFDg[M=ct;_@MIDKjsi]*6P,O7%%]51#KdeUShCD*kZabb2S%Ym"CuK(`i*#&a]]Q6Ks4\F5un@P^"I0Mq5-i/Y=p:NRauR2
+%1.EZ"?.UU.BZmXTN&&fGf?(:`V3&G6%6j3#X_sf3nZRI:Vi9*gH_S=a^Oh[+`)kTb+&*J!_Jk=i'kTiVq+c_?GB9+jBm#qW&%cnH
+%^lCq:-o^'/*PjCj("86'!bF&PK(P$`GF4_%:Z>;6>TLJok&IVAKn2n.2G$s%C;)LDJPH%5;=ZlBmm.`CZkeYBbi%i[I_TI<[QNHM
+%pr>76@#[;Jn)4EMpNNa6oiX5R=1qC2]"\7jr0[?K,8dG-qWA<WY)9V:oUZpnJ1P>^ln8Z6aNa&j4+YGb`3t:r1DVJTPP?QLU!:EX
+%CtQII0q8/5j,SgN_PV[Ad:>3388XQa!_@Z*cqkSGVO-N69..@Sj=S1lFlMt*!qNL2iD*fmZs\[\jp59*QtukPc'0-?5.aP:jK>n_
+%FVsQ^qj,KhV2C%^EQKP1(5o9!,s6e?jDEh`dlVCi6npNA%%q(V$hW]C5<g#t),C3rq9=n0p*FWUQP#9_(i"F$(j9<Y0p3M_T_jB%
+%"a9Z`G)rge(`g]*Z/dr,Np)GJGA"o%!EXqt`&,C[?kB_?/LF##(.mr*:KVEk>V`=`Hs(ZR3seY;O/5pIcf"/C8!)kj#-OBhCB"tA
+%,h"EmZY/+(!9BA%YS:%Ej1a*>/$jE7j/+`2$,6TSU]?d>V/9fcfbq'6^^;uRDh;J$nBTOahh%F_`Z`-B'5lk/'3Npt-K)to'3`4D
+%*^)aP;/annd]h\7DF?Md9H2+Ndn<\)co-d-jQd"0n&tPc"q#Dm2)#7n_*_?49hEGW$0RhlK)=PE-Mp4_"u2iJqD;k>/"J]1bS5"o
+%^q+EqbYAM$Y\1^5J@=3r$tekI9Xh9pm_K%*GB4ha.o8a^KS6if>2\t>U&2&>*5rmDT]HjXX?9=)-]Z08e>7NApblqWNCN%4jS?pT
+%,AY`%7N$c'd%]Y`.<^3*9oC6)iXIN@?Q-QsR;$Z6[*Kf`SWLY;4BF[:'#GRN1"Oi"WQ37$PA0o!."W4Oa7)k/>T:1!!WE,gQuAu]
+%8nMnIn$LQNF`>+5ai3W`-R7S'<LiGM_!t:SBee&8al9P3CCEa<r6tIYF[*4&CT4f<4V_+o=7Af^N9deBM2Ehdk,m`c=8**q6Yutt
+%pg_Bl*gGQ7J30`NPNoUtWqcrq+1kF/adGG>"@Xe+9=C^SVe-q'rkao=?.$m4UnYj9N7U3K5bG_QK<=bP!INU"#id3tQ#nX+PZD?&
+%bAIO[$@Xf8gF'JNdr%9N,F6Nfc&&6q4@5)X/k"JiT\L@m#NV;EAHR4Vb[-m`kNg,Ak`b'n5364)4XV.%%rh5O9:r_WVol33H%@fS
+%P$*nT]nZiEO=fiYP2MBLn/+CH_"Erdhlk*]>P%J*-o,JGMk>VA^Ygb>7.W4s(p_WW2E=c\)n'VL0Fpt!5fYa-AY5&2IX7f!VPI_B
+%1X_LNe(::r13MtW;oebC'V(K4Es'`pa,p%TmXO9K3(XNi7f4SLHEPGe=m=c"(_knGZ7nl&-V:#5L0*'h2Gfh!\0<fV8#e=b%k;n$
+%3jLaIV/R1p6TO>TA0A:*JueO,?B%VhDe@mJ!JP2/-oa.;a,hPM9V^r=B?oW,H0YG+!NJ([PAtBK<8[MA+$_bQF6lQf%S)q7ju(i[
+%MI=4`9i>fN1te+SLB;o)f7P'12CGs.d"'0!B#\RoCN,GWr.;Q5h_r5J:1nlQ8LHobh[\MPerm)E^*d'=`\0Q%H&Jn%*E9M6SXT2V
+%k00T8k[0QY-MC[\%uk]EC\\/BTkMYbgbL`#c_!"^k![-"/7*8[^!YW\G:M%>N-d1G+qN6SCCAmtga-M+Na%6,L^@gn9frZ*m;e"e
+%rfL]rP&Y62S\\KmKd+j%5'JBOmG$F@dg;@,?[+MZJ&+4$8R<lgCqEmuIb64pW(Ur=_dR(g:/EOk\O@ec=ioiu4Lcck'HK:k0mc"B
+%rSd=iN<fE^3bGg)HbiI$qb?7(SO7"72K^Z6(1`q\k,)EZDS-5]3%^#@Y1N7VO"?jjk6[`#G;LBH1Zgut7.5,S^mT)X.pWVH^C/m5
+%GJ2"MhDu-*4hSg2#_3NV]TTRihH^AM0]T!$#/,h<5.=5P4r@R7I=Z\:"M+)gDVAdGYGJtf"t(M1(@g=LqAkLPV"l$J?].`!Rft`H
+%0CEuEMj1mj+FfH6(&LU.YT(K'?Mu*+BG-)Cc`-_@Tr8s=OEPS*[PoW-TtS:)LY\(q1-R".bW/,u'q7P]*o"_pE3-C991>=]T,*br
+%`S@%,*Op/@W-ZY+s!&Ze`@PQt>8d$K1_Xl"-B*`)oI/1F<4#qZ(=^7)aCP-FDBnO71/_5mL#kfn&*Bh^lnCCV-H8;CCdsO8[3-),
+%W1"pQC'sFLQSUNCeBfC/&4nD=:3/*oLObX(7eWlE[W8'hRa^[WTXn<[$#7R1MW2mlQ6c.(&MR'8I5Sb?hFn+6pCa\o2o4rH$`l"K
+%"=L2:%%HFlcU)-lb)Fsd=\Ao'#X-\oQ@!^7_$nOjGYpW:Q=RokU9lV.?<6qN<!4'>dlrF-$gr)QD%`7e)A\k6f,@-eLCie8Z@pgc
+%BAmhbS-p(SMf.WC4D?DnB0%sg3G^U]0`l-HO*<b#^g&uN22[T@@t3(T]g!,:>UXl:IL&Kf9BustWT./e(HBE)co!eC+bsi+;@f1!
+%!nKjAaHa-N($jS:qV6:K1"8u_!^QI0n.F14fLlcF=i#j,iEWuS^?okJ_hl;bqMDa-<&44=,QK[`fK5L!0'!]C_bgi`^.Ope(2JcJ
+%nN'LM6^^heD-1]6lT"bF(lUD,q_r=62\LYuNtFRkDr/9h#0R*Z$jlKh3Y3ulrk!9KFjFI=OoN?e;t&/Bi+BLA=(H@X$gu;5U<FaT
+%(-g^=eZ%joWr<k!'iFk"Vn]FgAu-$Y7>TUMhXHE;pgG$nCD7!%S3o_#>$a&TW@a3Z:IS":D,&1(W!/kllZLNf;<rBa$:d/=#$@s*
+%A<@SG2FJ_YVR_:pa%DHT:!$O*]_gWW:(j;f^gQXiL+=N8Sue7G+:\->UkE&GGY%r!`jabsZ&W)ILmu0&$9l.aiKSFMCZ\ugAo9`$
+%Zs=BEW<7$"RLatsgBb6upJ;++J3@ApW:.'%bE;3Gl0YX?30Jq8E<f,e=a3dMJ%=gh$&sQ,M#9>9&gAh"@'\K3)]%h%YbVXM?rD7u
+%UL96^oR%DJ5Mm`YAXLG&SoW#KfeO$tGQF=30PPqE``+^qNPEM?B\6&g=*m-'5DR3_b1##76'PE/L1Y0`8F#=[%C>P8hc65u3Y5B'
+%]2B3@gfqr^1)M=^VAOXOFuk`X`'E+b!G?RRpH!!9;L@%dn:r&=WT)QaH#':&5+,V%p^CgW#A&JVkb1h+3?9I/BI1KKp:qR?BV7#h
+%9_&hmRNbNA7NAdG%mUgRWFNeP;s@u7aJ'E$KViDP]CR\KQ">^i[Jg):/Ko#P_G15qILd+poR_'E8OAe>2O>LE\P(##7_^s`2c"Ka
+%YF)Zn->.J8<YCkZ[2=/h:6fNg6]j5hR:`oa<FWp%mfSs/,7F2Ge^0iFnC@VfXehE&P,W!oo*?QO80oPr(JD%tbo(q</Y`dVHU%U*
+%Pf0[P5i;3>.O1`@8cfE"WtsH[F4IA2G;QY5M,t*I)5,!$CoH"**e<+`MA@Bgo;G8PCMF#CelOQ>cD!8-K@&g[)EeHd=]s6+3Vek$
+%jTTrG)[2mDl@^Y,nM%1M-r!g07^Z-844=Nm[)_*`Ub/R_+d^+bS`q]K!]_phabMGqgTh0rFK:PN9h6',!jqcJlTsYU,Y:I*%34?Y
+%IeGCE?j8P9p^I6c./-J\i'c$OPCW6-<7"prHioCfYb(goEjSWApF#H1__ihARQ0f"';b<Nc+.eI>>N(o;_1b#^c@0NE2f!l_"QV:
+%1;qf&0\9eh2mi%o#h-0@Nni9M[u?q-mO<bD':ZUeSubi2m@B]r99,G_q"g>,i6D8m;GBI>H7q0i(O27Y+S;:VO(/@6:8hL.Pp>!Y
+%:^gb;<=f:Gf&I5b.NuS8C`b&eF^*t&TGo6Q%0=M_XoH``(UMuH62'5Z?lX*%fr]mRMREZ_r>8rgfDQI)?GYqZoN-8hfl\4j9>Qg.
+%Yl2h.!cR#(%<&XIi@WY&q"%(nYtH0(`7^1>^JRGK7lBe+(P(qs#Q]:JGWUjN=LZmP3u2NlJd2V/4"Lmm&F$_';=Y&Ur8I$cpS<i_
+%W>eHj,fh$+>OU2dO(ced4%:6q`_3C)N3rl/Aq8?YO@mOZ]@!lP.c_bWiLZGPm4;eQ9c+-fF2m&K!i@)mEZu/*m?@k<4L6<emF7ai
+%pu*!W(N-/75gcT^%BOm>%:$7%PmB?hQ#sm+8B\_agIr)KPYf#`UN6MLL&60_^ld/F03/`FOH^>AJ=^TMI#K`d[<8GT<Y*J0Jjg2n
+%dL"V^(,^XXPTK0'H!aGu@)3_6_u2J'=qL6_E!+ARlNGp%3sEprL(;(JWD\d,k2"c9ICXu70L?]!8uhra&-0/=hR5\3>+kLqNKBAW
+%TYN]_9F&W_@n<qU6GS3D1-=f-)]6OLZL%q/+-A_]:"toD=Jh^BmfG]H!-^L.UW@EP^;OonZP`rcZA.m]\7GiYNp[`K`R]i,1QWo8
+%!P\S?g(js/[LQ()UYJmioo*\69"'3Q70'[M';U0J,,F#N2RT:iqMjG/(h#AY#.UN#0-E6i#dO\gQcN\)!l.><+N^+>;DE+@3@Hl&
+%LoYX''c>?#W5>,p#g??.$D)6Mh_U'ki7D$2'.Z0_32((#EWITH8t(,_N\upoO_.#gC+lnijAj1#1Ec"OP$#&AoOKe_p#'=a^/pM%
+%4n*5%"d&NXc6?7p')@:XLc5KI4^%MJ>)%PXg&(7!>`uP:I#jTV`/5UKL;k(L8qbn1mVVD<=>a^dUc3LZ!g&6,O'S*G/XX.sb:Af)
+%f@/Qs2]^??O$W1O*:2&gnRBM1+6pI<7Z&ljqcAM8#^VSiW+"`q+NI,o\88NAR.1h01.To#2WJEQES[Kg`>.ar)=h:gfnHm0HY85W
+%]g_A)++mhYl&0mcCWhZ7Oh4)Uei2[<8A:oBr$QHD9F+6"!EO2PVr\fD%+9;nc`DXiR,IaO"Z)$6Ub388'&X@n-F:`gb[J4Ahi7+2
+%MUV^(#6h;6)F5Fq^j9,gfn2';9A=c[]E5q[``FQjg/;Yf#H8Ck%*]&1./27W09J<0_AoiE]itQ@$m"[9empV+1G#C0p^"I\k@915
+%>%K=HM#Y3P9Ei2_oYJa;=j%jc>?25rhL5U*#c2f17ed*\OZ]^r;;sAtp7Pf(<o$@9E_idM<7l>?'N[D';24\V5^IF.'#&oiB&)2M
+%acik76Fn!0>-9BMM7S3fbbPr'#ZAMa-isaWN'!L@iPX'OF#(l8!;`I"$l%RVGAg@_X<&p\1t^`ID<8Hc0mLDAU9lLKU__U/J2f$,
+%h4,AZD0*G]gC?m(lBCU?M:d%UX'L%/pi5`cgutXE/%<rUOWC+$\.0$BjJ/^@"g:5B?j'Mmk@;JYZMk;"Ko@;E,YutVP0?qu)PIEc
+%nblnUBtkak@EKJh0+dPkgWO3K;jb.X>[=kj3Z'<b[\%Vb0R\TW?60XNKGkO?"5f,I*d/X[QM^KCaq[M]^9lQ$4YR>-DmkC%1I1K,
+%cFAqZ=hA7'o"NVO&X-Z-f>>Dl8iD!bnJ$-m5`4\5>86O:e4bn8PAF*VfJO>P<"'20qd>aXE=9Ao#9A0T/'El%FHF-s=I3l89UHU%
+%kKf:hCm-"^#Hsu>7p2(piPYLqqQJ"%-V2G<@a(ps,&i(*?Ee[/nE?@,o;1^qaM=?Qh_9LslOFb*!!^`tGn6Q?FY]c]7u&`5gA1h$
+%WNqOGN&BKYljd<9m\\QY3L@?p`sUZ/i&0k-%QP$=T5.)Y8ff<7J6_P=r;8\.V60N>=^q!%'d)B"cU5JZ@#5&bSoK5gE#tq^hU?ba
+%4cCLe;Js=,TJ-q1&uB=+UI<Sp0[uO$635Ln'4j`WQAUrN$fKo0Dc[-eh9/EVM:/t8.ahG=L[C3_h7l<`#P<op&NfJFHq4iG++4Y9
+%p"t2G;oC(#?;hSXrgVjf3ks\Fo1,F05Y(0XDVo?"bl64XJgXI.oNI%94\eaWd5ZZ05IS8B.Ga.e^ut1j>$HGW!KA[T^#&r@S6*ic
+%!dEJW#7(9XZmB$;oD2X">c8+^rRT.SNhTT^]9ZqDKtQ,DDqCIHXD&V-pg!N<Gh<?A(9r-5fQpA7BDOo0Ct7h!^l+o`$84^!Ue>D%
+%A&&cUIM4scd:+Yt'L3n,N7Jn:p2LYeU6V@JJL+=@>WL_V4rZd+g'!(#meI^YI9MBa>04-NPH.paA@Te1-_L`An0%Ir%]si]4tXSM
+%r);?9m`-A2s/EJT=9CSHe2#b3d^7`^EXW[m_5NC2#2DT^`YTB%E;Kdi\dY4-N7.9<R'3,LkL'!aTi5Y'a07a3CWd%>f5;LF,%tq6
+%!m3L[H>s&m8/LdeCQ)2poq4S76%Q-C+56!FVUScUBZUbsa1+/dAD,+P'mKkPaR_.'+Qh:PfYH.R'E!:m5`\b,\E]lP4oL>NDI&Z0
+%T9O.^-YpN^UX%eLi>?N$C'*D)r_]\2q4iK2b/q_2jA=?%UWu2o*`pj;k_!!o7ZiQHP?i*"\9I6P3)@An47'[fBPtEX(UI9R>gV.+
+%H:EZ2Lr8j4YTC4:Q;AUFLZK?L$'ZLla0@B;a)V\R.&V'5"h)WVQk$uA&+\Cr?LU!O_8tZco/p-jbq>U#RA'VWeQ[sQ-!*-(6"Pn1
+%YQ:oI"LkjqT2WOKSU_:m)*Kqb_J`c0P@2.n$uJ!YXP0_MXa^!K^M*^iVI&RY"?>Tg]e*m@$oV"#3%(PTChMl'YPiR?ai(FL@\&]-
+%Y62=.\!G[@J&"TFTkHnMWCV<,>ch&lAq/]r$',04+9r&-F'(c2/\s<eG`8<9=,[1lNR9-N8n+(rH3i_R)A)=7.iLgi5D!7^q1F3\
+%Yq8=HjA?iF,7giB+;',HX:_P,,'gMP@$8hai0H7b1bPf8!f<USX<M>B[1TWTi=Q*kS-K3BpTB-T+7AT+d[ar+WAu1)C1,=8WAL-:
+%PhSr$G-%7+Hk^EX`uP!28]DV'?*7S'mX*+lN.urd0OH@dWUg+,7rVl\7>LJC^B$VK5Fu0&1Z-7=,C#M7l8NS-gHKBRNg&lVSR2?)
+%!cf?h=/bp@Y?O)\FK<28L^N<qf<fH=HZ0]SV$\nlmd^"ZG9)L0#.G9BI6Y`n!Cjpi27Bf$n2+l55Qf%\jf5FRXd200^>B'0UY01>
+%b2iYcLG'I"ZrJfVVKU[+J\iU]TZdICF:RI'^W430D$`,""h#J:J1\k.Du6-hH?90@O9NkTdKN1r-K(?&lop$/+3g,HIkH.:'<)4p
+%\7lJXF&B`cAM$0U[8bk&PD9>*f7a9S&Eet*TmGGpZWdUm;;[Ee\$jfDK>(2IhZRoqD%@<,;m(lhjB_150EM_/qu!@q^b=9Q6@nMS
+%grHi4^%FsRG[9$Zjtd9W!]2""Kk158s*`,kqX91mT(u_ljCL##4,a^lSo#!$anb0]66;_87hJ97%u/&J\F;t:<g6K?E*dJ0_dugf
+%&"&>M84tpG(<2epo\)hnY-@$3=arq%C'Q_=lN.Jmi/-N*"1TO>e_upL\-L4X(1N^h]/4:A30@8sBalWsFp@oW`Oa+WNFi'?%MdQ7
+%e*=d9GXd9e]Rn#D(5e`7Y=S^Q7fuPa#9"Rn(57k#6[M+0R5DM[7N(tDIQd;s6o301@Z-co2-B_7<0`3=CkiH(]<uit%6E(2]W2WJ
+%9]F`:Ti'9<rfo=P.-0Hq!/+j/UnS"%7m8^8Fe]0\Z3PteXC@da")N5??1ia..i?`gUX`a+aqdF;KcD=MnX)(N]R^f.DO'iH17qlM
+%KZHE'Z(5hL&4mW"E:Lro:N?M>+r*KFc6U_AaLc103)2"HKSbX/ndG`CXSclUe/c2+'6t_UgC!)-3?ePm^qt#/B#^LalR&ek$CZ5S
+%n.pAek-\]jkWi\5fa..DD+uZ]hh#U`ICM(9qW^\A+h18g(n"_)PkCK8^cWiT6!9?/]*mm@4(DM"]'br91FX_7q@pTUF&;&kjl+$u
+%pgX0e&hHW"$k*BLJp08#/1`[lOq5(e!$3DM"@]JGl[nT7VJ0ds-,\]:6=$?qYZ"`n45K9;fIOF-'.@5m5O=]iK-f=oUtXTO9Yi/9
+%Pg7&.El$RIBf-h5OFV[&_i)R7JkLQn4DBM%5oSD""eX7a$NBcBj(#+%_^cP9(T.9NnUUq^2ZV.VOumqZfi-7u(^F[".Km6n4K!Kf
+%#LF;Pfi-C'Z<\:NE@es`Gj)\FF8S9:AAm]A4^7b]`2o&,.mc/`,YN%<->)co,^!=SK[kZLXs=BZ1(o<-8]hCl@FT+2TV$</O(<s6
+%9)ptiek"P)JER0J/>k(Up_]<F;,T>g)ppK/l=Q('M"s"hVK5-Z9l)a\/(\3al^b+SB-<(?>I8.@Sf=&%TB9L?/_A(W5YYi8$\`&J
+%R$&&G=1B(iEc0!"C./@nOT,mqYLE7]WZmIR9gJBElHr`':s;_qD7Y=?_Yh+[pgOY-i9$6,E5Xu]7+t5O@)S=S#/k!&G,gWQ@l]/O
+%`lPQb=lNRo41)RgbK5jb.iFSm,&:R@5\77^co)'3,(_h[&VdeA(#9VtaXH(4R?oF<NigGK\?.<sn,VT/^qai5"#,t0<Qk)BP7?p%
+%Z4n(>(,Y(T6bk0^B&jd":oY8K:tpZRS9,_T->Tg$#J_"rG)=kAU6%^[,K`.uYEVP(po:Am@/#W(0#PIaAmm"[M)o*pg;M;blKd%A
+%!G9`&6Rf8a8eRgias>:<>MU^cUXUKb\lm;/@FP[qR<S&;i/Wd[fYOP>$?6cqN`@qsMfsq:#(;1,Q'f^Gj?e,H[\ji@fINq8%0ZX;
+%7;[DAEsJZZG\gjQ<*++4fYi`S8hP5Jg&d<gWO9IF%cc.($qu''/Ja"l#:_^a,U>$B/7bPQ(Q>=67<XWUkutPTd#7BVq$(^t9mD&Q
+%ZQ!=f7kkp_-oeR$CFpD=Yd']`#MFa]5>Sa>`.[5pfr_9(.,?ZLMY2A_!T5%'(uI^-VJ3HX#*Y7Y#nRY6QNY&Fs3UHAq"CYk#91<%
+%*d9ZI2mM`k5l@5&!#=UK`QCLfUE\Jd^jXMG@Ga.c,R;e\[;.@WC;$h0%;I5b-"f!fK!hVL5-3(e_g\J5@Y(P#?"g%0D/q-u=&6SS
+%ILdZBi\K5m,tGAIH)VY]Y&U*s]VhMtXHsIaa^8\#dq_")r6cB0TVcel2?L=5"-[6WcLO*kphSt(30kT2>)s*Wk60;$0,2W.I19Lk
+%U[0XAEN4:$ln#bq<BV_Y#I"qE+^3'XM&Kn?@XVRJq(mdX_$#:p`4f3TZPj/%1`\TXXqS4C[l%<j5V<nelgn?--41YqfNSPd4!,p7
+%:M!S2>c&rB;+.L<-k'\maH7R\#)$iaps-Z:4EUqI>V]A3kiu=K3*tQU@5,P!i[S>K&5)[7P7Z`t(U:L$oq]_`b@StnXI"o,K.'ng
+%+tMM)E>u8ElPWdB24:[lQ;9=K#8[]E6GUUeBE==$'3XgHC`0*IT4.YcP"!lDP\F8N,W_s+fk3X5eWe&69Li[RjT.i@,b1Tk!1#dr
+%;[!GlSL);Y`1le+q5(C)9)o63oO/3I![l&D5a>WeWs%U3gr\SbHe]odpI"j;4q2G@'N".3(0J>W%_.%Z0q_\09]Q=.rZ.Ea1:q:P
+%BFS`[9JZ!rL`i_+=LV]SYoKD/g1r\jfDa>:]=HG](/PBiq_dh3Q4_9*hIhT?0+eEi0Ir8I1I@Z;;/";XPqUo]:.]``f"A\:3rheP
+%"m6_/=WkECBZe+#++\9e!`-OhI)QIu6_2i3I;onca`_'HY;CFHA=C-nZ56MY!lM4dg'0=<ZZm#SYY'7ilRL!_^A]*@4ec$`,ZBoW
+%`>'WAD$>9>llH0D\Iq($G(U7gKXE/;a=&/d+U.tk`(91$h?,->)jg,d-M"UZpNj$s$Y1]Y60ID4:cbQ!ZU-b9N"j_Deh@lp1rF_R
+%fB`dCT'hET+$oHM!;qT!Qn10(F-Wk/.$f!W0NWit&GCe)37<s'VC@rG^0V15c.7lKXS3K`49c;^5Ol$c"3@69e)$fDZVh60!EKG5
+%>DIb1]b^"lUj61dfkk-e"Q^btW9NLXd<&p5cik[($h)bd,X9B*QF$m/S0I?f#D>2],J7qs1ae/\$H\a^=L@-ON7l`nb`Rj%8SM8(
+%@^6nL5V9VF3pHi284'iF<8<X1;cjJ$>YZ'PgV:eA%Yrc\C488p^E6ri<;cC\W@7;^,FJ1HnjA:b;CtYl@>_&=9n:lk8iHd?'TJa!
+%=pp'RFPSimEXP0J493-OA(?rBJt#A3Ys%\JCZdT;G8cFCI+Cb&._C0T%t.3!YI_MJ_+ZF&0TO9U@GOg8Q0`su^39F>\OIbC2a97B
+%XLr<.l=_'@k?c^DSpu8\0Qgn0O6I@"7EUl:i1?T)a@ge[Z5$-RU0^.$H5+0`a#LLOJ-.#WEXcJ>f6<OL1<#slgiFA8]N8E^E)WG7
+%5gsA^B0?Z)SIVChHfM^Q!MT\WoiJuX\=aoR=64e0/D!eQW#2IN[7^P[#.#@s"/e!T;J'<N_M8W+QPrrkkUZg^JP$YmHe?2o*mhZZ
+%CWDTS\4^lh2_r_5$?DK_D53YD$ModS\e/U38LWaS^Zc`al8?Zjf:]V6DHJTmcu^rP3X,KOU&^6Nn>(hnN[PYiZ<2HNc9.?N8nLP-
+%B9E0Dgl0t<3#&97n0hr9JR[UK,:m:bEk%,<4-c#TPj7;O;fMu),[b;+o7==mj)f5Ln-Z?4cXe0VB1BHO#k$+sN-.s+-MCin4<p$o
+%qGuj3K%DoATNr\dlV4uHGMoq"@Jb_/8KT+HpXt2edhcmjeIRjb;Y<,FbuBr5E7Z!I8F9"Q=GZt$UlC"S4Oo'po@1MBP-?8R_bnpq
+%"e*iAa8m:R4$*]`WcHVX[dqSAIcj>\3!N4V7]hfG%#cZl1C;k8@0g!-n<aYJ^dY43Q4LeFA*=_cJce,V0a\aTGs.kaT!nP&"bUNs
+%5KqlBO7JSN:_-2"oi_f`#baNaK3!(48DDiC17BZV="3&/.8k"')>2H*+sVb]cA)B6[^_"SeDb!#F$`&##Y>K,-!mY*@VL#VaX%+d
+%Jk9aV!k\ca7u%V@N9Xf2_2<7Q_\d2LDM,hbJmgd=IE-NH^t4p'E'D#/TO<l,lbd$jbILqH\#uZBbV:6&es/6J2?r=OSj);saN.g\
+%@h/p$0>rL@nB%l<`8Q(%!b?HY7[[A]#VK=^><$Yo/-k.ToHW]7nu1.Ac<l>MgX:'g>Y-KQ_HgO"d&C)+%:e^PrL3A^0kGtSEZtOd
+%Xc>*f)gLpYbT5gLhSo)QRu&`>,pT_"a3@P;$eB`m+EsT4ms>rVR%nUHa@DZ!;RSB)CbAo/gs4Pq"Lh$_#2&2'L!FsHbP![+Pu3Ij
+%OuujE`4c:?8aS8La-o_Sq#V'S\H=UgcI+HFL<3RT"\Y@[?;?kFkr#ro6*#9)O=TQ$$:!Qg4[MH@pro/bU%\Rc>uLf:7$jb[eq-)h
+%SbX,tiYKGD#Ee23q-*neBF&SBN-T[!&bhd9*E`EWrdCD)SEd.*"<_NZhuKMR`W/J*^O0)in7lWb#S`f\FTf10Wh=lui^u07edXef
+%GYS)2-GZYEh"WcU_.I)>$hOk!p#M-l/W(\6&SK-&*3AO$YRP!pLSJTB%tE$u(2TmgP/gnX6Cq;LC:S>),!YT%]<fV)DGsetS>b!j
+%TK]tr%[)mW<P]^UMFCLf<F`E>8:We(gG2G)%+Z*`k]KfA56:nclXA0r6E>idFG@?F@1j^,Y1eJsR/*D\&hlD>_buRfqZD(\pF[S8
+%E6T?Vh?[A7Jbt,bI3-KjNH;tHO."g@k](!]*)W3Y6eE4G0Q3a6^7l6/KVc")]YiKXaEIQO\W$hWAHok*UKbNPr;(O@"h[@M5`^%P
+%FpK4OM+,"J!?,<)o?]&!i9#gJp<6nKafB8?BCao4cQIEPmsfsGDm[=6?lF:HLSU^+W^k$1"/k`Q37qd=E##5CN9Ge'M!jH1Q'ffL
+%Bub-[Ya`mUe`iMiO>)</k8P_9#4M]G0gH)uNg3l%$b3\u5j?-@fVe%@lHF:?T(tFlB0T6/UM2rRh?/%+/AuH4!'dAtArEpR`ft18
+%.0-sq"mg#p#]!C.K[_6,0,+P@e7HJ\kN?dW@)&'k$,s]dF>((.ci'sN^:YnF]r`O7-K;EUs)U[%l8$9Md^N/uH(3r%i";cnd(mQA
+%`OuZ#LV74MkL&sf`N)./UM@*%&oeCrN+KY-o/6kV;4Z#HI2T6<iK%h7YX:@KXU!B\C1=L:jtr.Ba<FQ7MfCco[*=QP.<A`4aR995
+%3L)D.f\KS12qn\9mrbej_chRC8cdCe,ATIVC@5W%T8KfO7YmaR_[EH7)Ou'`#u4W#8/Aq=hRTDN1[Ke_I2q%*UTCi'pc,6o8"OT/
+%H09oekbj`=YW[L5g8qLJaif"&,;u+)?p'9PlGl2ImDtLS.Q0$R\kZ>",K;+ofe0tpZ2hn4@K';J?p8P-5VZjk=kr]F_(ZJ>-<49E
+%g^@tc>-:M%IeON6Z[a,_[u'2QYU9MV=?,XY^V`@l5^j3Np;rfGp"h%_2OM6oVf)4J`R@1fa,J`-#0pGYVLVgeniIYV/[@X#cK-fr
+%eIf[,@h8K&bnFKYObG]V3c]]OPBg=i"N(0=Z3Q!^O3r'=<3b.ok6h)j;H?d&Us+n_^nRi+R?VGb(B^7?/DoN]01/`VlWlc,q$%1l
+%SZ*)!Yt<JHX^H&357@8]0\Y7A("D#PYIiWZA!kj>A9b)=!,H(^hs6<F:eB,J[^mF/7WL]88&RjV3D?3RrCbmcLeCD6l-%,,:k=YO
+%+MQF1%1i()@ta*+DBPJl%<T'8"lQa%mto8_E`"K/NF1N?dU3Y`+9O\D=FhJN>*6R7/8Lp,0L^KN&E^Nl\#L4.:tL&R5>[FOS-E#!
+%7d]cJgSUl73V;FSObeUDIVeimXFL:2hs,:)JQX'q2FDUpa^urr?(59AbN-mi&=0IpCHt."rrX+!C1Ri9bg;a./bVFd'7_Oi@/RpT
+%n-8a#O)+B>N_9msQs#[#]SN5%Z#@.u#]j+W9T2Fm>.P[MU$Qb+.#sJrD,Ab9",;?"kG&Q(77<s6hE^L>$20(SOc"FSA6<CB/uS)C
+%>E0i`TV<gp],[(bbKF@UL_.+"oM`R5iQTQRH'2rue'Lo/R#JA-i`jGP/LfV#j>!1,Qo(-U)#q'%qWCo-.]<-\DGoC?U!.9`:I`W8
+%A3I!P`a+W,fWh_:jVB;MHhqTuSZf6/'K&C?=%3_O6KeIZ?5^RMAddAgOscMG`jm%sLkOLB,dLA'B!>k6E@n,`bXnogFnL^Od#G)[
+%55X^J;+D9kFQ5iC=:q@+e>97#`qU@B%RuB'<-amC$=qrVNo<-t7=WL^[n(Me*T]eiTQC@6LpHdK35FF#8%n/ke(p09d&+HDn:r#l
+%7f<9EQZ4.R9g&J@TC9ra5gt?a2*@9l^u,4qkBn%:=6]r=JmVPqFgY7u-9oQkPS2W/U1V#;bKVOd_FcC1iQ.Rc$@CZ#=t+CEN7WS]
+%q"!gtYcn<jBli>;+qujui,U&FJcqnZ,R(FYO:P0CKY/h=1--aBJL,_3IsmQnTRNIM.D9;)YET?";M`KnmD\<m,E1"aR8ai+UGLA+
+%[^>6n(THRLK*Q#6N-ri>L#X[T"/H1d[ur#6nlrL1Sdm!sVLpg$O%no1*fl9/P\cs!h.Qj,n!fBt(iX/a#7S>2bbP_\,+"'V@M/!r
+%s+%>ef-'L"Lc\1<"=FtRWB;qmXk)R=$t(8mO&pS("$3IQXH:"IME<&sRE>/M[-7!pM],^2XVj,pVP$nGT7cJ2nj8^Q(U&@"Hp6mi
+%UFDV)(F(mEnQ3M:`1L2Uj=2CPJOm[]j7YnBb_TNQ\2DOI-Sl*;DV#9Of&B8Gh5MMU_m<dSN7S7#O:s3>\%F6q'R[,;Sq9L(P`XBY
+%"rY3[.?P8.W[""$0tdhG<WjPJ<dV%T*H\[t!?&#?YHS1E6Pltjs.R1/Qk17/2[&ea]#qE7X&B)W$$%JLgWJH4@/t))2I)Z))^&lW
+%&EJCe,<+5;Mpj]%Pj'dm1'*B.CFXC$Gk;E9VP:*%,&_nTOQSZf9Yc%A`<lc0c8eerE2%87l&IiJ;tJCR.i8sI^LR8Ha7QS8I^JlT
+%js0m4QjZV\VU=_sRDV_rh'0SN7l%tn4D8n&OV9lp8C$#3"`Yj-LI]BS=a:,<UQSZk'SjR^UG,PF3ndmKj^lkU93kj9T&fC'7>KIP
+%LiICY.QgSphSH75#%o4P/QloB<8biKF7:H"@_WqHVe78kg>.'F;s"?YqKGqiR:@qCpjLZ'oX6<gp?M"Y6@df(H?pg3nf)QDP1%<6
+%=!ja[2Tu2k+NUbiEs@dCs!/$(L:^o'=!fSk2e**jHQ=U>jSFogcXWZ!9M!/UCuCb#2Y>r)nUDV[otPJf:X]C<_m:3[`&Z/Nc7Nbs
+%bX&N(6t=c4ie#U+CP+Xc3.$*;@O$]%&NRK<XIUnp7f&u.4%X:.%28gHf"RWY%D(k:(e#+Rk`3CCAUK:$O;V5`;ZGq-jgMVVkr%t_
+%kBAUYpO<`NHDJ3j7fG)nc_"RR5Qq"Di3CIU8(^>t/OM6*r6Jl+V75en"05XKVTHa0f;6t=5'`V=.lP%$<FmXO%ht8[9b&srbCE8,
+%YG1=IVeW3`EWTUB1$)Q_GiRaf04e5gA<*'m(<g<(qOM/GPqL]T&Pul@2>f\GFfGE4pt1A,[gCW4@HiiV]B0"GG,:Zi%7iQECfRp'
+%rDPHF>!5=\B;lJm!d:o)_`K9XCKV`pd6JJW`**'K>=o$t-3%5#:,O"2=4bu4E1CTZ?h,7qqrJ41%aYR<f^nZ[fpVP+!8p_i8'j-k
+%-]C(Es"on;'E//\fG,1?0>0rl5YoMeY!.J:pIf95gOABupcs]b`uo3L#-W5S'.C9:8PAe>mKe+YX>qrdbD^nL2<14T2Ol+4Vk:Tp
+%$9'.+;BGT.qUZ!*?rSekaU;?,EO`m,6?m<>VR"e$_8/$F9O%*N(hCnq)NS@IPI8Wp&/_%h\dtZ@,L9gVSMX-Kj^=Z,qph$:rJNY8
+%K=1hOg[;UBK0LFUEI^RKg92)&lDP2VZ;)Il5^!RofWd5)%/5g0Wo]jS$W'>&'AQ]ak.s^LFACRQ?<G"ue,qCp\S7PuDR*Se+MTPE
+%n"BtXe"ik;l/,@$=#Lrc0b*j1+'O8gYfser#'7&VA8&&QA?j=F8-A=-T2T_Q4S.\Xqdp'XHEo7q<FDg<57*aV.O07#Ms?N`WJ&=P
+%h/=0:.`e-ONtHPprf9@aBGXo'/pSc-YHVVPO/QtP$DmbKbET#q(5'UF=JD/amUP!:NboGk7ob^uQ++(qQ^SgkqGe1ln$"_JdH;J-
+%G5V7@mTGUMcD27=URG&7DDs9*('KCQgY3LRJh*XJ8TlEo>ZY0jTn5;<q^^`odFZXT_+,&(b>hJ80@X,#l1^Pu"PEfh4PH+ki'2fr
+%Y>[(odB?o<elX9CB8fd$^K'r,5!]Wn^8cXKC"d?7?uDQ;V9G_F<%N@$4`]-q%0,,C8+=$O3?0LW5mi-WeD#ETfe%`,oADaj2VsM[
+%G"<'4+&Bg9JG1?WS9].^URJ+9-6Xi/YiN`%%0YTrDi-u<cW=<Y^ps\G1;WMQ"JoWNK<9aLCCnm6g^N7dCY^q2McRkkk*P20mJF,(
+%97s0K[L9$Ff@gug;@@S=bAl5XA@h[NjJj4''J'bF0Y:>C\\1<^a56M7#cm#7!%1le>@;VI6$\0sr9N\J!5]p6$=IdFBp<JCbl`Fa
+%2XP:+aAgFeY_1_YRXj+>8k51WWK_3Z!A,(GUsQCl5^Dhq%&e7E!X[DL>6f%<YGTd'*BC<7`lC.M?IRAo(;otWN6AQq(tFfH6bA;A
+%g"\55r-cEE]T*ep#4hQi8*.6u8HPd"]7\tBEBf_s2:?Vi.W$I9C:HO$(@cO]%A+'E&,e/K+Xq7.GbJqll6%GX^V@.X9s8H<ZKX6X
+%s-f7`eGacQXiZYI1V83C"*uIM4gOe_Ms.B)Y+9PVk^g99Na/jB"2_/FHJ@&;Ej8]V%_'dZ'.B`3&n&%VhtlZ=BqYqq9gBa5g/c&V
+%JV*l-hu>>2>.6Js0UZkkg"S%*PhN"`6!BXZ0aEE=QpY#)RY?QMG_ARq*5nTZ>1@2LC(LQW*n6Y[*^T8GJ,3U0gO9;$`BY+3r?d']
+%JIP9tQ\$:T`\3&k7GI)D>OV2!cmFRp32d4$ql;4JC*tODUeHh3K)9<(K2nh?Jg(38.N^N-4EThaq7M?ig!ZVg`.]"nnoG.i1qI_S
+%RW*drjX?L=3=+&6s.QPe?'aUMkDg:I]97afhol=FE$k7d\B=OHY<eD4ibcc+b+_q`qRW"_B@]ai1Q58sXQW?KTFQude]2t4_ohMG
+%pO$1*\P^!ke%^X>]e+^@BH%*Y*+?W)DWkiqY-"^T[4?OUQuQ2b_D2"+UC'@qG*"`>DV;-Uh""Jli!cXb6),d^=/-1Jbo#e<K0N,G
+%Q\,%L$bS;p[H=Ora<dib0%Up&(-PnRa<Q%%\ncF?cG?,NC[h_K)C!a7!QdTiP;HK'WE9A\VdN@l'Vs5(5Np(P.^i$8Vt.)i:\ms2
+%>7:<VVj"&t'f.3uWIReP7ffT'<kt0fO2XKn75KCaoTH&a(OKtsq-P2:F(]cW\kl@bNa+d%cQ2r0cY\kH[t=qk+rCj6i$#Z1=B8-!
+%>DOl)=9Wu"$3sqX[d_lJ$S]Ga`#)=(_&YrA'9*urMt0#?q[a>,K\cgd+eK<r==Lda2NXMg#5Wc>qb=k][]Kc<f(E39XDZIg[j%(h
+%gFLe#e4j+9ep+om`XuW1FFAO(!!:HI)TS@b&Xk&t1(g1F[A&&U\f&SOrs@b]!(IJSOA:bC(A<Mm(hF[<`^Y)l1_b-!L7.YmDmX%C
+%B=]oF_XTFJ<c?0_\Z`h->YW2.,;%k"@Rn7:WIsboJ8/3sV<"CMO&V6Ol3FCFKjBg.NNgUTWcVh%,iTbm!ftR.CiC/QWehl4^;.0d
+%C1>8IX,56"%PsRU\3[LP`<fo6T_D`Eo9FC/%$U6gZK,a1[TBE2+:kNVcp38JZ7ZXmZ/FEH'Qc.rhiG$P1qCbAC`ksQRSb#o)leM(
+%;?-SQ1eFBF?`\hV@VR?-]/SQnZLt=N(t?AQ*2U[_cFZ&dJsoLfA]\bE_idMiSR?_pek,Vp:mG[C3.C2[e5Nr_[&4X]I$p0Jr*7d/
+%%%!ZV'YhuP)QG7$hUE7eEtCVj&IK7qe.j9`C!7.i%4pm<kda\YP%4NbBmo>6eiE(-q]IcVWS/r/_7U=;:m=C`KgQB&C9&5Z;VT^Z
+%&X)[\jbi><_0J[Q0Q2dTat5=_B%>2U4fu_o.P'1)%9c+TY:Xmp7J49rG%n12qs/XAF\$IMJP4O;XkW<="_,U6ec\s]/8G8P!`^1=
+%Mt//%R2"b`qZVmk#)GUG%&9OU^Y4-](?2t&P;!."[:daqjT7&;ePG&PLk;gSCP0T(-RTY`U($'`]6FA;=(H5<5kT;/NAR1FCIE5b
+%,$l)'g%$@uoKrjD&_e.9>9AK)O0Ng;%12/$ONRhNQPcl>&e?@_'S=QJaNmBXa<4q@a:[M*W;VCuA(]ujpo]0Q+TfYO*.K&MHMp]u
+%@H.C^r>8aVj*oW&NidMM3%h1A^o4AB7-5rG*j.(tmP9"ML/j#/AF98Ep>=K=P*Q*gDqE\YaOqd[J!C)jXf]qC[[@g,ld5sAAp`@]
+%[0IS%b*g8sWj]VsqO?"ZPYXGt0n/KV*4[<mc/tZFrD,Yi%M)KDLG^oV7;hK#[Zprt"hRuZlIK*V'eH=biAQVIeg`"/9)S`nM5%+%
+%45`3e<Yo`tL9'/r"r?\(I#RQ?SnuRV5:;A)"+=RV)F7l=6H/+)N6Ek75aHK1=/:@,"+,*8AO_kYK@Jn,7GH<#FX'OB:mXnVQ@4Ud
+%#&?*:kH&lLXii=erKgi[RanZ"F0RbaOB0C+Q@#DAG(!KH8id7D6Po5Z>MQh9?<CCJl8[Q.`;*DW1pMKgYUno,$M#kS76lFcTP8GQ
+%[`!)M\*=L$%abAi^rls+2lWZJf549)iO[9j3a_VQ24VhFZOE`UTLks[.+@Vd;XpoJ/jPjuBZ?-hAbp21GpT;p75n:KX;Y6j1o"-@
+%![k*?;AH'%8XJ_b1>iM*In(tSQ]b[Y5UHBthV4Klnn."@Oci?u4f"*(g"!KI3l@d:(LJ<gA@cZlY%7G/s4"aLXsM82-2%K)*Vtft
+%8p4-5=d<>Pr'NNN#I9CFL?3-U@2K+BLt9YY9bJH:%f#b#Lfc/OZM$JKRbN>3TQkUiG+PY6WiXG>>S1m*24VjMq:(QQXJ4K?G`)d3
+%!@G:#C1l'q]j\97/ma)F/Vi:8I`:3N]<HXtf3,pn9_HOgfX\lu%-+nn8%u\?%rUHpi/s83;)U>9-f)-)(AYrp(_f\Qnl?\;B%\VC
+%bsa`HXlMo#qk*$gf`ErLQ58ihnkoJPBS<!6+#bp,cmNl>G?%N9p[Ca,rR6&jW*!1TFLjNrqo3Y&Cbb7J#O&QM$d,N^6Zg/q=l,[M
+%fk(MP@65eI9&o6\IB4Oa^26c`br_9bc5<$-<8W]PX#dnBaT>79!IjjDYrB3DR'"CS+K7JPGi[PtRC;>DTq!ZD"*Eo[^u]`,DHPZP
+%N6JkW9WK!r^s2nLXR/FVc0@+fBT;ajJ<'HCm:9!RI:rX'J@^S9/l`DGR5Cla+_Gepfk=?V6)`JdY@9%_o$G@Skl5AiP#?ttR.,N)
+%fgEg)FUI7/rV$!aQSDQTUC.8Rm=h)tm=1%?/OQ3<Ep+P1bR@f!^ffEo;.uQ75?-M=I2+'o,8SM2I@fQ_Q00?a)A]Qlf_B9H8J7N/
+%DB)UL9dU1&bqRg"Ynq"RdK1fq$Z9Vca@e*,6;225)k\-=):YkMrX@5Q(q6`"SEl<LaQBbAoAnT%);K+q`uIm>FKmgQddA'PDt5;'
+%)O!-ZZ>/LaA6'%8%:iKtg]O%QSZIBq?Bk*XX;SS2STUS/6jM9/RSKuk,%ENR7J5Hke;uc4k#Zdan&ND^?U-FS,=hj.=,DaX.KK:e
+%WM=T279Eu/'!,K0!C9uUp#YGVI^n4%B-$&iH0fF6l[c84cI,fOoj4Kc-/9g_nC+X<5u!*D^KchiA]8oq\N3VJ/Sk1H@_S.L1sB/,
+%,>`O[_BR)`)0IAu,n*$UCA183jDutaT7Y/bN&W`8^:i=b^sqa^!_*=;2;o'aMlAYLDkop0`hMuq(o>FI_[aT:?SW.4PV?r8r&3D<
+%Q>IuW+I#'lYi_7t0]$pJMXp('N_O75bVaB!gsT*B?s7=HC-\-f\8.qejlp6&pokf(QR;hs;Op=T^jMI6@Ia88HX&^P)(D_[GDATe
+%a*RZ1h+,mLn;`A$(;(/fQKgUP3J1B=5^u;@G6*.#H))c,fF49;-Lu^cj3(!?87XTgat35'b[\=*jslW=VSsDUS8J@%1=oa_5q94R
+%Km^L.">!?7!g[+F"=tom*(en5'r9!:]OK[\["@ePjTPlb'GiONLu^52T_gDuq".Bi'EERg*lUks*BmFQ6<Wf*lh$$gq_<NEff.o[
+%"B._!bJ<?U:5H:#KX2eJ>f&8BC)#]:=l7@=>r1eRe)-<Y#.BM;_f"0LKt>#^ccF"YH1K(8T5W6>EVY`m]8pTnr%dNEKG-PaPb^\C
+%_H;4b)28AXXhsG/b$]OH^9Y$d.o-QPVECsp8'&iTf70lpX3C)Bn6kZW.-]Nlgu9pJVsTV.(&#*RHFUS"dRfk_1\m#WUcH20[mfjK
+%9%5G<_7Ja8NeIiaK/ng]XH@%-L<hL*Uorn-VSB[nE_OeZV%nYeFVhiuao9VZ>L47(*Y]%%Y)7/+XL</7fD0.N[T$[.mF2(Rrg)9O
+%do#m/WW^`Gh#SWA1f&c5A%t$^DRa)!YuN9$"nY']NeQ"bP(\Rf!u#')%OoZ1)S>8TA5g>*<<;lTL`h;!(OUf@2aWD03B_?b+"?+_
+%0hLG\AH<jeX?qp3=_%ef&u:&.r>%NV?!HGl79F\\"s2aL!^&moha0_]!A`g=Z0c[MJ-VN#/`8)VVXBT.1g?$DY99S*"<#s+aEnfJ
+%i:o'[!;@`"dni:lK+p$N!@^-l>BkS,O4>-Gn8]W<1sqltQ=_(m55^^_@\*[%Kn$YXRt1"5/HXoN>m,8q/OK`mJg($4^A?HJqnU=,
+%,ikdj(-idM]80bG$!*490/B0JjqP@-"CE=f>/^:*Fs@L@8IqD@[=Y?2\\K9bN4a%_)&@-$Y`<$Xj:i'$Td+50**IAtCt+/Ep?#Ka
+%Z31RR'!Dk^lCg16db&Ln/mpZH(YEfUU/5P)5ncMF1Z6oMK,.?0>`e@]]%-]$qIibV@Q[%XE%Q!PjYMfW]MqoH@oHrB##kJuf.Z7^
+%cUbSC!-I%3KtRWTc[\jfmK+#H>"gH3pVe^l,Te4/$.E_^6hH8laO*](=^FWr)],\9V-#q.ik5_^hC&-FY0;/Y\B"oCGssC]"r%F.
+%KnA[h16JZ!8h.UfN-s2R6BTXQJJk5NB4.P3%fqaF:dX+U&-CIh=+a'aRfmt=7(s@)EX%nHn951`JG?q5AHXP<YVCd^T+V\Oo,5KR
+%:djpOEhBHAO<TUXh<mp.2tkHQB"--h&(iqt!5Y.7i,SCWSh(%Ej3Gp\qua0+2[tAB06au+)Y7'qa/kqt'FCl-@B&JQdW<fm4`M/B
+%W6G[i6IW<YW"'Heg'%X#O^Ldg\PSb%3d^,Wjeq>H+(DL2*R,DHT[,fSc4MAl!=rF]I++,Jp$lUt3N)G0K5.P(;e'^%3B2T]=B;k5
+%@2X7fjT(jqkdh+H3*A+N!\t2@+p%#nE(QbiC^"r,"^!F\<4=3Ip#/Vf5QY+2hPK^YL#"%$I+SO]62/nE1MXr^5&cUq4?Q6p;bN](
+%nYas^F86/-)>K>8R)kh2cbUo3.)YI4E;s;+R:Hm%eT<^dVoFqZm:GgfAWMRm2RD*)5./qgikD^7U'I(0mVk[l,kDcEZ/OtO5e8Q`
+%)a>;Tb?0'I>THs5O%lbYFR7c,H/T@UParL3bNt?^WP@,1i%a6X-?)s<AJ%e?]_N$ipoO?E\L9fE=TF[rc6-L*SpO!QV<A*f]AOJ'
+%8=&l=5=[sflh1^TY)Y3Z$6hr,OC;o-H'722L*jf&>UPHq+oE5$=SbsZ59`@[@(3p5mC:J&Pe@F^<#5T'kfI^s!0_pA(2rf7DE#f_
+%*&:*#G^gL@4-+NrgN.^BOT(_cogYrLPm/`$/Rp1**[1VpnU?-mk1XWHCBTpN3YmgV,,_!Mn*o3gg#NQjl1!4K0UsnrV,k@FXDSp'
+%H'&[#2>&JUnp=-tojo/U3.$b#^!6V3L7H)T$crRjmA;6M2[b^2XJ]Rm`55_d@4!",a]B-/-[@qn2n,mBGi`XfI/q9U;*Q**`;4NK
+%?FUD.!1+RVHdP'?%+<D*GTG7W'48ZJl16,o=]=iN_^WA3O8IG4pG.NQo<rZHBW>TF@8o!mE+]uu(%`cVeY0(Bb3I>s4$A3FD($K!
+%aj1t[Fg&0o7pRUN>.se)eAo\tApOqP//^5U_+=DokQXZ_K??W_!m#r.'H;st,D5`i*sk<AN,Jpe&a9^Mn2p9S,u?4RC)V\a*`PAV
+%:F$1%"&-Y!=[7j_L5q\]gr1>^4i3Xre=$bIqt:;i,>+igIPUVPQW<kSb4n(Wl.Hs(+S#>'^g\%W:,<MIJJ]Nrhic6aN5?):J%f<p
+%<.NduMD2iQrSV\%WfiX/D9?B#Hn^juEI(d@W_KrEB%\A.NP.Qi//)6*$hdNg0+4^1%9@N9r!8hI3^9[^#3,2MFgDIiC-HE8L-]<$
+%!qs<o'hiNlEEd(d:1Bb'j!5c6C.sODGed_=cM$r5L/b)6rc%4&n9-7LnaHU]@h82>F+Wn(Upfa%qZ4>eb5,Yrl6AO3e-RH>ii<&C
+%=`<2[V5?^$.h%C^$]+e"ku(/-\9R,l[4O&-O?2LI;V,(>^6(WADbQ=\G7rik;Jp]A%/b4Z@GXKjQ?Au^W(EU`1gETo@i!uak;i_F
+%T(<ArJ2Aia$K0/HZ/.+RVCm5c$rTm:/0MA#bFi%<5<b&!2tglMS\a?&^!kjDD_0bINoZYfo'hBtH)u3ibRY:k(%8?]><(d4%kTG9
+%WM4@(_f(+4[J$?\b@MX<F9Gt'XIaLu#uU6s=.K#VP/W`jM\a/MpZB-1A#'(V#W"U#Q+$V'n)#kQ(lHG<GFJBLk2uej(%;6Kf()Lb
+%_COj;D=_e1N!f#g(+XYJ)dr-pVVB1#f'@TG/dX0Qbt"Fi!ktiod!Hc*Ftmn_S<eobb],Pm=.mQ$5N;;N3VEqtk8t$:3*e)24omB>
+%C88kYP:9BOpVf"dFV,<":MQBYQ.mM7%=U=ZGODTg`d5DePV>Xi^,DcYZXpUsaGc&>hAJ`)E!ck1jWk"cQJqXD!dMJ670'79=]N(+
+%*FTSjq*=]b-3:>7V!WKo%r##cNI;-d1Ou_D/_6+g["<7!MVIXQWgd"-6aHI`>q2;U-f8V*'#.ah6u!gVQn&FMDU,3H9ds3(UFbT1
+%k[4QSf4bEg'YoXOn9sJXH.HK>PR;YhD/*Zr'/(M-/8;<q320U/]VnQ[H2Bs\?P<t%\U$OF"4a50+e(MHcD[0go=epe:ugG;[^M7A
+%r`1-:."K"=h2*MPZX;+rd%o7knA7s^,91"n80>s"go0E>Y,*p]be0DQ89`s6&7/t>(UMS5,-^bHbt_%VRiNk?nkhXkNR_lH=s`*g
+%_"A%,<-AX&TQpqLY'XppA's(V*BDCWe:Re"Z'GT;"3oBXi9H)>\LZ=cE&8PJ!Zp4Xan*RVAm5lA_$Sb?,A>rFVG6:NE$l^I!r`MQ
+%gnPA9B<[=(E(=E%"]Y)X!^^d7j[5V*h<KBt"Vn8Q;Ob&k7,fCHg"J'e34eQ5AZb@OaZ;Ia4VQTjc<f*5_3V(L!Zq5d*';Q[Bt;`h
+%*OniqNO<$&&&CP1p-Si`d8p)R*d`r;b2sq7k;A.'Tc+Gr4BO@3d^OL+L\.`1]RHMfFiSC(HjL3s#d!""FmBY>P6Z9@b9<t.c'KBG
+%e>4:.b-]m"DWQkWiT=;8h4*06L!^lHc\)hEdC]FlV>Cn=A*M;AXAV1Qrc!9[grSZFJ4C\3SUli,%mY]TZZE4=TZd/M'3)bncA5ZX
+%)=I!?Yg6QJ@%)WgQ.0<Bo;(D-1o[9>\?/-[L(RkZLe6b9D=Rd*2(@g2!NV6*^K:OLAL;X0C<Ol+_B9QPb&5qe]XXDF+g$Es#J&;a
+%3\5VjlG-"Do*-6rG3oL/`:Bu+ql&XM\'IXpQ5Vp%]1l-T\b0P=B/Mot(\-6%@@[YY>J"&/fdLiUD)Fr&@jje+a5-b0VIB%\R1W&h
+%(*-eg>r%V"q)2V?qODVJBX!t%b7fFZfMfFFj(AOXF$u)kSrS4KoeqHsQPI5NV,kX7Ihenh3bL.cUUg.TdW5_m`<*&lj8KH5\9IS#
+%M`h):Mp1!q+^?S_/URPul\Nh`A4,I`iPq)b5%KM('6BR-j=Zu3)6TW*c!^=R(:eNY,u6(>>3jX0%D^T#ac6,7\!d3!iR^`g43\n>
+%CcDWca.6h(a1?IPT'TAVE;JDpKPN=pjlH&n7?<T)&=YUP:G-D.D59[N*U2D?f5JmF6>"U!E9:jXr,D\+NAGpPCa<h/RHGP#o1rHY
+%,YZ3753K:BJgMW'JNas@@Lk1+i%&DYl"RUt8HMhd,Tc:2jNk'F_^lp]S6#>Z0<d*s%mWb3mc?9XE3VpQB3n$sA3UbnO)K>N.8Jhn
+%X6V?JfOl.;]4kFl(#\E$IB7oiSi42UMjMR]lNR!A,;-ETUG8L*[\J**C%$rtV#;hsKoqnAG%uL6DY:&\F=>)P!ou.^3]95fQEgJo
+%mgh-8jF84E-Yltgjm6d>mK[.ph%p+Wc!K:Z46+d^2C7A^/`r1#S!'(W?cIij%<BG"c[<Pq@UT#ccUP(h=a-rpD,7!',@ed;(jF!$
+%;Iu*Erc;2c4AP[]msOM8=IqP#E:bL]-\7s3+=cr24,1Z#T>3kqcW`dEhI#\)$=kp%8.AC\fXi=-Gb+4,TZ1OkJGR*&0kq_)5s0es
+%.nF11E*o1f?Qg-Nqt`n\G:^K7(o;@9,4T`.)6ukM21bR$kn]kNrBMhuh!BFnl%*K/JZs6qjXiS#pu-BU/TUZ#V@g5m6&dL:@Xobl
+%^!6FeS?/B.1]VHTL&ugKJ/O7P&WB.1h\\lSV,MMoBNSF\bJ[k<2-,I6YWpqpi$kVnluCkXfY$_Pg%p`EB5k1Eo'JVh0`DuW.,P*(
+%QP6RXT>AG"]q61c$4?n64iYP_W*I%lL$oE,^YSgEUi/30kqe</97sX%HF^q&U-FTrK.Du!3%4>p)@'0qQ>[e;jQ*9-!iN"qo1=#G
+%=3B-mh@MJkN_p<hs-cPI*Z5g`-t><3a$457qpN[!2*]>=l8$d7A(p1C3e(:mLEdu-d*`[G;DF=9W^Oen!hN!n:flc=%/c$-0Rk_<
+%0=Nh>C+=`?\.moh7%Cc^5i;^OC?#eq424IK-rU-)Ld#1=7Ie6?PTYs5gE.64Q<8N1""X]B]E2fBJEh,PYg,i]=fP(AS78Dd=UJ94
+%n"A`I$n.LpS]h-/?)J?Z6,fh4@b1ZAZ2QNr$l`Z9DOQ)=Ka6LEJ<G.i-)\k_\:EGS;rD_3<q\S??pq=Ia3Q59$/Ph:@fp7tHN>@_
+%^<"j0Dh*&41/:To"f,qB,AJ:YBrsVTi<!U:R_rB2%*BVsalFFg]3QTge0t#2<(A_JBOFMBND:C:=?k+GR80*#qjIRE.s>L6=MShE
+%br^/eH0&!"b"Y-fDY=>eC[f6WUXcY2gKf>[IBTl$K_.gIApD6Z^h^!A"d*6L+:TmE1Z6Ye'2U8>,6rci5:qrV%X)DE&5\;F9gFFN
+%>tH0U`IGbWZg9ION!2>jGB4@8>T\60Br##c`erfin7's,dmM;c?LDbN>A>5j?qfm*f!"1E#[(e:b4)LBmK0eT4i5P[&28]8!k.K@
+%"F7TZ*sEbuT#'abgo[O@!jt-TK%hWFTWbAN[ganB#p=qqY<eN&4@TZ0gB5bUU3?ZR;+HWjYMeo-hC_+F3HGIL[#&O<M+R-coVU3U
+%/)`3SrHkODZXp`b1S>.->%cpD<WTBOB;lE#FM:)WAjO6=f+-n+g2aFI^gVf6*!"6f7o7gjlIZhF0jK9fV*50+756#cVuW'Rj#2O)
+%=Va"+/RrSH8"4EU_!>N^qbl)&&)0,jV&Q&*'PpCYKVH_]@7%;#D&H)L'OOsH_sji_G8Lqd'gukE^p++1mq^k8;NZCAJ<VO;'8Jc:
+%S-U7A&I"u+JTWNl$Wa6uMBMD3:Kr&R0"9c\&5VAi!n)9(e*<n`3Sf:b@seQjAt(HL;Ll?7mh[dcKFbn1"p+V!S3^\MXHuiSog(h]
+%)rS.HG;(>^a;/3#,0SUI]%#P@\W=@bd<=:JE9sm$BpIJBf96B6]sE5D+se)e9bJE1qo_#9R72%EV^5\<_NF3,W_u>J_R`V)@(Yn"
+%l!+Sbl,e03L3^#",<HAc:D&eQercDHBD5o+fk=LtG`Jb@nTn+Y@VBEpc`scu=$cuM1pb,fH<f6>9@I6$3`%L$Q8=X;,A:+WU:/bU
+%+2^bSW@:_7U.#H*QE(VN%29AXX)S8`HA(U"%_b9F:o!]\#F]].Td&aW7+SWeYAgHNI^tG4)K+,0fnr/<''=Wi"dp/7Qmn^:aCGc^
+%AK?/P!%IZTC&O`!0<.6:oYhRQ312N>FAjO@%aIQhn?@@cMqR_"In)hEqD1h.LDM$<9k?VX[_2NH!]`2iY7DFh6SC\M=mK)CaNBq&
+%a\H'[&r^r!`MSU<CT0'Fg8@rd*0u'eW@eRW(,0A4n=s-UZ+/.=iptDb5*L6'q!3R/NM06oG:FOMD#3hN/Ks:@oab:/%dq1^O:uYZ
+%H&dlK*/XPnqeW*m"@?Od"f_X"Vk>'nGShBm9>0tQY.gWkAe9e_Nu.\@F,K2W6!oJ[4p,--,W14fmJT<NHnam*(9m276NDL^\W>R*
+%[4Ak9Oq/rnPuE[*JE0kUT_atg4H+F'<60b0m.94@>.j+fSB?lMlS4HTE/Qf%h-[Sn_QL@lDIrK9L;,@[1YjoYnE-1_@mfG]o(k9G
+%E6YLp#tD@'`erA@_IJqLL!L;oNqG&^VX1FpbC&9Y`E#H%4RU6WbeBqk+o\!;IB*AJ<ar)6/#>hVArTCP5_-<lrOJP<nM]DMbi.%'
+%eFVMnp;Mk@X-&N`/j-5U*$G"%,X2t<\s=8EqoVXtAFWP5YgeFmO6)Jo#3&XZFG:WhFGBO$jeNk$fj0VXqst52K%fP6^LD"O%uVB4
+%;T[p$V6TQpPLN]6Mgu5B4E:H[q;\p0jID=A=NWIWO[jAKA@X-hjT?(W%Dgf-RPT"oBr$EUG_f!u1>c05ToMo&AMIam1S4$,CXeKE
+%lUT)u4I&T9k'*)I`;CIt<W)i!Zek_)4^'WX>m?k-/q^0)hDD"G!u;u+ih-g9RVWHmbr(V!KQ`OBal6U2^7Qp!h^YZ"SRKcEGNNc6
+%:QFB#*NW`QoI$-EnA]DVA2ZV<M7(YgOd2`hf+j\UQPDb4[e3,[W*e..0>2r3N60$3VqZM(5)\'#;t#UjNmUXT\fgY2eFG87AodLH
+%Ih-.?>"[H@'5?1niep8#U>^Bb]1[)6Y]s)NZEVktTUGI'?!&!a]O:0scFdQQ6#`E7]%l&[[U^Y,EQ:D?FU`hUF3)^>1=<Y`qZLQ2
+%5qM0t%O\@:%!M9\FV<CR25kB0h<d$YSADb!LPL@-&UT3ZC#Kd7DcZ@bKo7MP'o1tt_:ALPW.`%fRV7c#I7r/M`$m>.!.DB+C4-*1
+%e*FY<Nrm`<37_5j<WUKbZq_#D>QSYmRnOJ1DJA:0U)ST4Rg_thT9C3YnT'=&h]Ig56=k*%HnkK@DrC"\Wu#+#G1nuP\$1DF6skb`
+%_V:PmlOLnPFHr2$,/.Al0LCJc0u&DG9FH^C30n!#"\p&&^;JHh/q$tM^<Qi07mR+66E?`mq"tk<!=_%0ksDB$G5C23'4AD=o2asG
+%/RL6mH-=hK]$p_H)>FE&Do&p-<<+r%gi%Ro_8s<ABj)Z[6#O]pG?4g8ecNj>H$d@"H26+j]Ti?k%S!VX+r>)8o?JFG@HflTaBJr&
+%2sq+N(*A;?Ne>s<M&)mrfBK1S^\*\^$hnfed>>K*B^SsH7j;6KM$hsE3+eqlBa02-1n:[Y)Pd0B%b+l)$["*`^dQa=C*C3`j==NO
+%CHWQ-b(>fF1ec10KN^t:VJR[ZZNYIL,D3#hh->en'J4mmGrhon9@MqjjfN$d7AnG[$`N;0'G)s&=/Us.+K#D4p#Q[iMpS($]fGsN
+%K9RSOFBZ?1gF^4;R!N*e2)GSaPLY6PEAo8!pQ*K73I\lb_>\:qWsRSk5;-&9BYd8*DYBDJOm$bL^nb1icCP?%PCB-_T!2@\dN=4^
+%k"_4Qa<[f<7_6j19b%?k@tGpV>:cADQOTNJ0t^E)?i+Bi5Ag+BCsi?Yb5[[?;*+MO&t1Y%;m+jk2+dW)c\>Ra/Dpi7.fnsEJW!G6
+%@Q"M=C`0qR$asfQb65?s]=jrFTV[:%2=OF,P)SbQ#C,ZK@9r@LFI8[/ZPF<nT<(JqYe"%&`jKVGWcc-mbUQl"S%X?aL3WnaAD)EW
+%(jfXJ0Apse4G$e6-g-(=FrTpk!uWXZC_rbhet9c>Q=)YKLca6PR4HAo*S,JMdgRM4UU8eI!m"Rgh!F**"]T,b\LpkkdGj!6g\_)U
+%F/kQ%Fru!I7kC!M>"6VJI:d</(#:1=&+l3#I\)o"\i$:oeA3\s"[8b[Ne++>@;_b'!s-,F^$ELMaX`/XS/p_1P,31?(7[UE72RoV
+%Up/Ci$L^dm/l4XPC#VQOL?\j*"=ZU2[gJH=CW4pb!QKksM(6fAQ,[9BbNGG44E<K";o$h1#@WP#057BfKdEPc_/KUGfEEcgN.BNj
+%UoDi6ACWZN^j;OnRelE4gB:dEdQGftlie0LW7Jn_@W'oc;V1Z8hsL@X0&pF("?+N2:9,f*,k3:in&k5dN!jsF=7"uPen/VrQPS^t
+%ZDXW=]'2f,%n,lLJ4k6B((tQ_!rG7eFW%6aJR*mWo#YRN^cJcu[*nTXdMEi=><q'3V-UJEX,(6dY8:D.5(i1]EIAunKBD^soHf?F
+%Heq'T6kg3:De7@0`cBq?mB)_l8.+:nd^Br&;/GLn#V&%>+!SGG]GJS?8Q'%9@Ks;;1#G=1)I2VmKB3mD^sh[_!SoOU(>+\)!7U1t
+%_8Gk'Q8uI*GRI)."2CLiI&F9CDUIS<b+K+:Enb7^p'5El9%@ksJL&lq/n[ukG0YY;RoW=r/s%>$QH,^R`$8%Zih^"o&DDZ40*gG4
+%bIZ#I0X`3iB,TBnkToOfb?/Y=dgSPF7@h+"W1r2:F]FKMpUo!(o[XG=7C%R>qd5,qF^\:NZ8g::Td<S%?XKh$en!m))$>H`JiPtb
+%h(9"6dEQ^N/o5In2P3)a?b8VUN5(\&eu^S!I:5hV'faM<qDp(Zr>!lKW0hssI$kcVL7@;Df1Sj&jgK1^YUdJ!ej$"-TTYbICU[>+
+%K^N=V``FTq73u2De].jUa1?epln0+72t8j^"%t3V+%h.6m=p.*PXu'oX[oPLqeTb6f4LFC++o>m&q7JL)[eP]c;q_ulpC5MFN5%2
+%k'i?Fm9\P?p65:`]Ss,S!j:'T+"e=:&eHiiY<:,hNSSPiUdZ(EQY17d(e9!Vhtq+pbYFlpq:M`KWOX0A<@cu;CA%h4YcD8<,"Mai
+%=HY9!gKg-1Vr;A6``SUqDlWr&/PeTn1\b@hMT,J]?N.!Ts&X^Kq`k#G5JR6WT7?a-J,&u755hr,oW/#kqSutBnbS%=p\O49ZGuDh
+%GGD25(-e$(kNS[6H\S(JRUGP6aM\$k\t?Kc??,m%9*%'6%VU$JYj+L4Trruqf*4R+?sXB>iR.o&i>s[(Cseqa/qMKQ$&Y+IRE#gB
+%:+I)__/@r8qm88X+_$`H?i#GZm?AU:ZZ@r3oBj,!0%/E0nQ\M]`Qk5JP=49u%l=1R3*L'*HuSDe#8d)V54$Fd<n,<4&@B[\,-nYG
+%-F+GZ-50NW,$0,[Wn_LKb_JbdK'&^,DquE8eS#\U3.r5fgeHUeqAic6E"c*mO(k4!P(U\H2L;Y:C^<h-'!g?g+Z4C!:k\N=e;jo1
+%,qeM/oC(6>YCjOrNhhIuni,de!BmV'i+>8*#\./bTE]AmHuWHW)N"d&+4/D(<A5g/5Q-_5Lo6m;#9Wt_UNgnn[uKK$IMaFj_MJ9U
+%"h*I$5GSZ,K-RL#cpUFkUuMUeUfCbEoLT4%IfNJdLo>a>1=4Sd:u+%[_$)B\.b441Z"isQKSWgY%7ca$Sqf`2[Xj,<!lQJ,"@Yj0
+%PR8\hYlsD4<6`,/QS$8(<cD"e^E>sele,m*@'^]Y*,OX8fF`>,>2ff"D2scIBZd'/#$7=F`rn@uL\0rOV24miY1FTb(0YGS@V;%7
+%[kf:'l0(g+$3b"(")sb1pL]k0gQN)Xe_NYN=$UsQ_R'R"XtS&"a"G_kd/d9`.nC8k@ak/UWUSV-[923na@VJURN\`'K/5\UO_o5)
+%dL-hYCQa"k$V'U&1?4k9@E#(Jod$6\$3pbK6sDAN^Ok'r#=*7cmLlcs,-K=i^m!@.QI,=aG0F57P"t*#g&^]s]j%'sf0_elQq8jR
+%Eq\H.6up+$b>Kd``kmnd=@:'`qlO#8^4I<H+!b/lc9]gl0aS`N(,#A9c1;"k\[.stfI<NG*Fa6YqFD4S(dW<:_9m,PC5^[9.X0m4
+%[iYF+"TCKTd=r3=lW.R!YQ?nnOd'=pEGQ9!e_\phE4cHYMi79!^U%mfU-+)39r#0>:uU,;=")(HBX=8k`3hjp8J+SBBg9Ca-+D8@
+%8&P'FZe.3#SmJaZ@Sm>pNNq+*2EA%a,/d^1AI,5]k7^2;n,feS:.8F"oK3Fd=q9>LRWj>#8J5:dV%/3S95!(<C='8I%k:((Mi[-s
+%T2qcEW`LY/Bs$^MWn8[6ZmJ+KBamM@XT+M1LGD.XmGVM/DDr8b.9gMBW;B/pg0:#!@!Y/q5njr1_UGgN-O%XgMO@2W#GoaBMkk7p
+%eKJBP%2E`-o[b@g=0<"Y/5]-W^n]uFYet^LoQHksob$2(kcSQ>(q@%J2je:hf.I<VEOr\+!PpU-&]$#eLEc@%nWP9bW2ogTURr7<
+%5:r@S.'_q=T,-KP/_tnSk&2G-+9d!^+7MNQ5S6eJ$(b$34J=hj&Kd)Z4Jbob;(fMmLo1@b5=stp/J1[pa8?L0,SKCDpHO$t9(AFc
+%i^S&&,&YmIDbkh,8u1u34idF5&PiZnI[VI6+s%%ZSl1V3dZd#8T-H4=`dVAS<>=qe<95S-aobWO7=7Aenq7),7M\>l:MFC3da-^I
+%C-o^7@[e_Z3"L*k'QH0p[.nMtncS,bY9<Kf!K2-%'Q0LQW_/gION'^$:ob<V=jFVN5T:C]SrsMU\]Y/NR=^M?)2#Sb*;)*/An>mN
+%)%EueiH%%lIg!Ud6kOL0j@Y$I6bpTW4-FOcX:<[%l4Q]5WfIo/$=BBd8F;Ci=^5-s)0,50DZ(]ceoBF9-@&]B,"T=.6)?T*eFY=o
+%5jQH=TGTX3inVWYk[cj#b/"KskP5Lm<ikl#X[e2*(_(%e]qFjdR+(k?qr*KGM7tQiHAt'g"d_X7\+IS+J+1jM1AqE\OT7m,]&_/e
+%H)&SseXo<-W$1j');U`WU)`t6"-M[mTX0fL$)CqRQG*U[mDad3@JsC67-9/QNSj1g>("tsN&r=-;LYGjX)/;Q,teoT,Ia26TB`!n
+%PVIQ)kMT"&-W(sh1d7)kKnpalYM6oSId@P*T<W^%lr!+R^5oU_]'Cbu<-_uSrB]k25E@"CkZFM9@kt!eZg@ohFqj,22"-;Rff#"L
+%I<'nf*@L38elH**n@I)2CO).]:uQt'I,>$M/<0Uka!U^9iT5oTdN5[Rq&EuegcS@B<\MWgY4dMQPTkR>2"W61W,hu;"PGdc=-`Q7
+%$H@DBY=u#<*4b7!d4=JVR/<R"3<h.=^u\bJ1,&?mSg;EVgYj>[iM51C&@PA4N%0C.R`.`[J*%orQk9ek8Gp43;T^KL+!jT:hsgg@
+%'`mKB"R"p?[QC4>I1DcYWVPVcD`l(UJ1#p'7LiTN^V_>X"2]p>$hrH/]idNZR'_pV%Og7f`X#@E.,<N.:rLiF$m2ir\@$\i&Pj<5
+%4DcD7cut!br_/N5gs'<qHU.[.Rq+WuVt&,[K-EKmeFBoBa$]_7MKmi+jCqh\LDD-^ib?;n%pGGbZp?DY:Re5/csGh-'amGmD;=]h
+%`QPA(9SbsJMDUA[iJ]TX;g$="c'rS9AtraY7DsH:%2,g<VdQa.#Qco-=W[9_($oeE,f1V/[D4eJ]lNP3T_HENkfZ=*:V-<`l1aeF
+%2irmkTTdaOSjO%eM(%A9DFRG!*o2,f;2!HuH:+ML%GJ`S4-2S(mgG,L:-)uE'pg,C;^;mGK'dYU+BiH$cRN4*O7L3P*SGd!5c-NH
+%4Zcc`fE.X@1rR!jXh[@om)*n1-DM:,-=n02i`nCJ8jE](*fSF9^3@mjU@BVj4'GHn+?X-HpTlYH^t'@)fDY6i7>ru6,t,nPJ9>@4
+%r@+ZdVjIX;fIXp]^#/t_@K9mRf5'SAp)Wd.#RONPBd?-c&*\Z`lqKi*/(h:.PDH*%OJY$?ri1M#WJ8gA[7qmLGLo/YPTOL%>5I4F
+%iJ572n3"X?cbtbtXKQ"Mfr\6?@="(c3'$c^7ZlX<3f<RfenC0CE#e#,4rO<ae^_Zr5g6T=qcP3<Ai[2Qm@b(g,b[KPRNse#Fn#O!
+%UVPd37W1_qA!kK@q`[G*DKD!&]4pE.JEl7)1uSWEJ`^fHV<&pfB"oT@>AI1=ccq9bL'@):3E]J\qI!1P6kS$D^%M<8^rmuKBpuT4
+%Y<NZOEPYu4dVYKi`A]-M?3`r\A&m`RIYpQlbEKOp"<\jTJ#EUm>*M:g*oJp^\tq&Em)K7R(EA==M!K<F(hqXZA34M:N9)IX/RIXL
+%rZjQf9aMQ=NK/X42eu[6@s2m:'t;TO#C:GMMr,@bWi;!7m7A!bShRCFATaOEPC?Klnk@a(p)P@N'+a^2H:N6Cm,a#)e&;^F5f&X&
+%!%PJm/-F3b^[i"VDB03qUmpR![!SeKI0\h*Gj5FAV\;gCj;bZAPgB]7qi!OfNJTnc.<@7@Hdmh,lU9hFV;l8nreV8E=XJkdG:H`d
+%QAQKq+#J!&c%"AY+6a#\f:mQoXWJ7nf-Ffj%n':0^2.F-CDMBK]<4Y9)1.EWe0hfC.N^)'hOKGB<lG3TeXSEYU$En!P>N&B?q8]0
+%)W*jcCFq^*`We4!I,T>@>6df#2>;>"@62=X-lYAf=NAu*pr,bP,V%Y<<kuDtCp?7!JEO!:6hA^A)^\Ia.T\q.9dl<;#4O%F['It#
+%;sp3`:@gSc2g?b[kWZS.C0JU"it%V*#31E]!lkr%?0mS5_/R*N7raC<r@uoV4W2]6$U:"ZOs^ioDCA46I>]0cSQ=;#YpOhmkgLW%
+%@!O+\nb$a"aU7O1Om<t([5ps9Z*,_r63J9@i=D&f7)/Y=Hi3)sc?1Qq.F]"9E$pI%`KK,d9f0UV;'+Q%G'X1:'jVGE-+F1>f`j]A
+%WXr#SH)QbpnBKE?3>mgrbG&;<`ABQiKcsT9"gZ\)&+EtJT$:r@"MAhhod!f"s(nsLCm&\`m0EZo2mJeWmY)dl$h9+3+,X7poVOU-
+%"kEalgfDI8-b)*u591@7'?,?bM$k@odj&8XbY-et);PP)0*O_BQ8Dh@O;l@s'g+I4]rD+8?mD]gg+Sm#aVHS5U/:2%5A2:t&m1gh
+%mNa6u/CjZ`?Flb3,>&)M/UbT)0bt#U?n)VYj]F%:P')(*$'P+*Jf6(SS9#b8d`9lfBg!4K'Q?]d=FV1TalrO'%.C=sE'=qDc8PcN
+%JA]2Z?AA[Dg%YutPQIH:!2ulM#*P'AEZ*0p/GHu8BRH-6&<RN-ZTUU[XMCA2L8^3\ZtjZUNY:h<VEpA=IJ)"1Ch#[H0q!XjjCmkr
+%,+s[T'N>Sb0A)53=YFIQ$A.raU?.teO;^*;b=.3tXh9T*L885@&"q-CE3%on3j"[>Jn8De)SWJ6[r$b635bs42NVVq=s@>+=nXYU
+%G8C7nKOnt-`e(U-8L[?j=,[mGC^8].$CZ*qYeu@R=L"P>iu%"c"7aWa"?(8^^Uo<s!@?BD(9$.t7tU=]G/iq5TP["j\F,;eTIsLB
+%0C5CP0&)kXa/@24RVq[$Lp6';?up9gNE<oe%'PYGWt5:N+bP@p=g,9'j'nnUp<(+Z5)[Z<==pgN&\9h,\G;+4>C_;Dpe!Js4%/?2
+%gQN_&C,`cP=)1BVTk,Cj<22[ZktfX9D'0$JX37LA)>+CGLcMMahZ-9OAm-mrlFnBD:=s#'[5?!0Z4uH6j?Q%n,iApteT!9F2hGFQ
+%C,Lb29I/8JgXuC.RC<k]`mM1M"'0@8e1\2t()P%BY)oQ^q6@PSV&U*PW8T6EjN.NH([Z+sZTG["0hMX/P!.\E`Q"FIoLT6[7/D!r
+%T+N::T`qdTA-T5hLSa10c%70-,<.XB9H!JNB=Ud^+X=DS1e+@%W#oEkE#"&nb*=WtdS0l"2c[(c\!'$7doh['XN-/dIuJnc@+:<5
+%56T*!4A&gGkW'tS=I$IL7g8*8dOhb5@%YUnc2u\Tlnk[PZhTboKc3lMAkuftYT#/gbBJB6=5[fof1XiJ5nt%\;`"!'TV)nd;YNFm
+%UZjGTYtGFoL\"X=K$2Hgq`$FL.[e#Io:4Dq:r/B<.E[6+>8r"MI*@Oj8k`jTV8H^%IVp`oYaeO\?@c.V.4;$Ea&]1-b[sXl\)9W0
+%5TlO\i.;`mr<VaZ-9r15KDLV%+*CK*J[d=n"FX.kiW,U/P8sscfR;,oM3^%b*<VD0&A<"Ba3jd[#jOMROqKF%l/d]d*J;m;M.?T-
+%]#.P4=E./sKs"O?5SCDR\g]l1ViOl>Z%=[M'\&1;aJ>n%JW$b6,Pe$AFh3#P+MZA/N05aj_)Q)g#K`rp$^H+snH72ukDmb>V<cj;
+%lcIq+AkGYbKWJq2hSlQ"8RH1%k@eKp6T2B))i;r6@Nf3idp4Fh2Mg#(&F0>dqDK8bUsl(A#uV1&5Vg'(7b"*$I'@KHkPT(QZX*iO
+%7^fZ"^%i2Mr<G3QJ_!49OU+_P1iF<]r7'K?kYD,.*\d]?M@e-la:u#R41SHSqkS_#AiQi-GYg>2H4-[>=9bK7\P0,+f>"f2*'.NP
+%Z[sn4@B9cthdHmX4Pljkme5ecf%)E/<r)QmMFFbtaR3]g\n7WJ78iQ5r.#K:H<M`A5]dX?QVhG.m++un,hU`c$!*DP5CD$ih6a8d
+%'l;DA3C)Fg[@EfbkS$@J#EoYKOU?+EVs1&S6\FJPrqWG3C_h#bej[Bt;T^2F/g_=gEdYWI3"d8^rpX'CQZ*^NE(=c'K9X'ER`[;[
+%k!/>gK_Gb]^0B`#N&GY@bH:C#D((\#[tU\UilAJY`HlhTE"<LAQX`FD/YjqUlg+j$i"fHk+.7fQO$f2qokR?Ss2:p_JQc:L0rU@1
+%O!9/g19q<$-)A&(%m<EB1,:)9ee#3MdeBCKCiPc'+6aR%HApnnX51l;NfgT/GR!?IUf"EA7Y42/^bhr[&4rt*Oa+1'[$%;\iL;f@
+%hct>\+k*N;MTnXcC;D2"VTH7gA\=-oPK3pHKl$"BThD1LS;%/WMV(4SiBQ*`ZKNn`8.-M.OL?j+LSV]na]Y':]L1B#W!Gi5KC!/H
+%&1)n,=IP\?$uVX#<lc3i2Eqp2#.J.m1LbBj\)L+-J'hS('_[c#*j(&.o3Lu0:,IIJhNeod7<jQc'Eg/<eT6L!YbJ@3!INKE'=9MB
+%9rtR4%BiC4K$7+?=bAIkVkT-j+5Zo#1b9EN^",bgDM/=2!\sYtPJjXDXDQ/6j(QX[O5o"D!Xd0u_WgL8s&Kt[8'M+BhUohkB=Z$@
+%`N\W&UN\.k"B02sjNrO'\Jr<=B?f,=8m>Fbr7WBXrrP&jK-I*`]5dI2Me*2GB_Y1be347RSpab1gCZHjS(NFVm@<p?Z.^+@:0&g6
+%Vh;uZjWZ6mn+m&B6fRhY#Hi98@.p`[TLtRQb-+!PY\:B(FD1[P_9^?Z,RCO4,WD[ADXf.9#LaSn3GRK_+0^8,SJQ77R`=*>"j99O
+%^AAGk.li^`.j-@/]Hj=F?,Xgjct`1I!>hh!LqDt\6-YpqrRNhu#m80-\s(Z:nkU]J2Ge0f5-q6nS"Z.<Ka;X12l%rB=@S(R`RM*Z
+%$-(4Mas_kuJEquFG'`?[Xe9mU)r`<dY$P$EZ,dt+XVESkc$-*&*%Zo7]jkUDj6@/PDoiN&pX,1KQ_"@I'QUY+aMegJAih/f$1M61
+%V+T^7Kjq`5WK247L!?c[ZaLN;+1a,t:9UNc+RNofb0eJ@Srdo^8JGHR0*="i8l!l5.JGkHaRhRcPLp7[cXZQIA%Pm-!hurP<gV3a
+%5'!o?8"uZ6*^4moRWi[CerB:@1kV)?Co7g#U'DU/>%,C9J-.huWVJ/)Md<\L<dOA(]NMrg^fCb2qMY>\;/5oXSL-F3SaPG#Ea-j&
+%S/QkZ$]fC=;p#/!iVCSPUaW2K?W*_4Z[Dp?J5!HrH,[S54#dNfgV/L5+4)$-_;Z769s_<uIl<3p:Hpsn8VG7r4oH`tT?lSIoIN%K
+%rXi-hn:9\2Cu/>K3Br[u/tB85SCc#hGFH:M#)c+b9ja-bF/Ji].MVa\8ZC.X_6OP=*<th\JCQe#qqRA@XasP2Rm\qCDqGG?ml=K=
+%$@_<1VCk(IC?i2`11qP9P(:qjEJK609WOrl8]s;*DR=9PAe=)/<^)D`K%b0?/.XO]`F6n+88e1aA.".uhKoj%L`ig,3:f^e?_[ld
+%f_&>3c'sI1%jXqBm2*V>9[+B6FjnQ!^]Ik/f[MFM4)'N'[XP"o5,3Z[SHB2ZRU8K?d3*W1J1k3^,B&cHq)eqg0gi3W5RGi,U%g7r
+%3_Q2JO<"mU9.-Bgk)L3;8r^2VPWR>pKH%'S9a=rJ65U7=LaXpBet+NCaW[LX3Ib)8OC?9(X2A>D'=-6__:8iUYPb,+<L]i*[LX&q
+%M9QtT;+$1QD+:mKmO@?nl5Dao^/JU/r(n;;Gd(`_gm]8U40`XokmMc\#oidRNF>$Rh2R6h=MR5C=c1MY%jsN&Vl?O#*Y+dt62+MO
+%BN9O1%C0UQm^k4CWGa1F=8uO#5I?4>041WVMR"sEUD=F/W+^Q&/9PG-LrLkXTfV>A>9m$%^'`)?_!&b1J.iY+hTEZ"e931jJh.g]
+%V;0:EE@<\JqDA4&a^X%!s(m@Dk,H%^s6C3?WT#I']df#"ICo&]FTtJ1bGGPZBP#o)r%L+_S,6#d]g+/F#V[M4b:d\'g7dFaDao\G
+%lk#jjVb+hPn.8eg<QVs6Q05f?,BHQ"2r>"%]Fk6Eq8!>eeBi9"9&m/iN)Ul*bYbMX5:k>SM(2!rkb%Zg#t53P`4dN^^uVWC$R2[>
+%(2_Z(1#5.?I25YS,SYfGH?G>9Q80^n5<D2dA.TCQ:>:?NJ=dH.,=^qV_%fA7_[;utMirROo$O#'kp(i@jg/u6=i!jJ9qW]#3\.[;
+%&7WJ^g_r!TALcJCe"UlMKi3>e^V^0-8p$!h#IYF>j3Z1)"LM[V%m2<EX9<gk$Y\4-U5D>GVu<9'KofuT@q?Dhd('hqQ`DB.[&?mS
+%+!sHuk8)Fu#5)Y@-t(ekgQD//q-d$/CeU`S52!MtUdF7K*ZOiiPk<m4UP!e[OjKgJB'/Snl:Zqh+0O`*31=.%&r9e^=IE8WBlo&#
+%ZntX9"W2+I.)H8ME_A?bXgNRGr",f=O7/K^8+DicE8<s<"kctA2qPmL^;[t/ns$'fgWW_F"LPk:771OM=`AO">X1GpIsa#?p9eqq
+%Z4A,S%;S8cR"C0\YtEHLg4(=edrDGt0A"==nF:D$($6U&NaOlMU^*V_=n9XsK0VJ1<)o90aMj'E9CU(qfS+U(WPh?bPA+`o"h=AC
+%dD?M"OaNY,6HM2$$fg'p/9[r@_br]^"2j^HgBq/#EnPYk*/0-A:%Cs_GV+%n;YRT^Bo#U^NKK^(/g-XW-4k4Ts0X'':3HZ'I.L3g
+%2m5BVj[Kc!YDZD12RER+^5R4,Zo,:N]TjA,@LH6_^U$G(JEA^&XqT["KUT#.@5e]jLsQX(<Y!=U5Xr)>3I.0KH5r/&kRns]=BH1&
+%itE8G5mrL?nokZjQpg%XhG@IX)/fY[RJ4o8Usjr"&dr6Z$rL+W$Y-Z_()H'&f"tO)<^[O*h3_C6$BKmkI7I_IYK[E#!3Jc6.ljW9
+%5]:/jV(8/Bc>DaoNnp^/=2(X)6pSb[X)'V;#e0)h/SX:g>'?JChe4$sGa$u*IVA7>:MiWH;/hHN$XuC5YA"H^`bFC3YT]B`!=lQa
+%8q2_i.#G'#Lf1A,bDl!Cpf@4.$4[GFIo['2!BR;jX[srcs6t,Ple<XD<Y=8Fe]\5@fE%E,2L.Ck's4n\'<JUcP<7-GjB@:pX]O2Y
+%U2]V.'&m'p.?t`^g>S<^muXomHDVbmCmCNL8<Zn7igl$\_87F[-Y`P;@l^DH[&rs4k)iIaUP,s)9%G_"N[A"ni'e3]YY,Bqo+).I
+%%9+RI6&J6qX^IgAR,+,4ZuT+HND8=r],&A-&#07N3H:?[E8_+*#>7O[2*V^QMhqB\/EE'6rS*MXS4EN,j8&j>He?$FY`cF90__Wt
+%HVsu1?i`47aJuh<XRAK=BX^"&.4,7:PMV.u:#8F#+JRZtC9\<=h!+#g&DQR3ZZqH7-./Ec-^n)K?$k24LaAU&<7m[q@"tNG:G4ZW
+%E7EQ<1oDh-#IK$'e_aEOSb7VIZ<Y.h]]h>R4QFYRV@*..O+)=aDu8/aJEnb^B'M&J(-e#c>T1n]-8r834!)ZY-_TRpBVn.MKg`k!
+%ieIu/Uib7t/.ge>34r,\[(rZ&I>F$t,*:;(UT6>:5E'"Q;gs$7l!XpK_b%!:M7J'C>hqAsUB-m8c2]SN!$VWe6+Q"9&/em";Xd(P
+%`I/(J4Y=\;qa&,n@sV=>0i-`9V+f\KbV5L0nqn=p_.9+M\pu3cfV0-WKle)K(gjgZX`G7/6+Tj/S[KkClXdI(53<;C:Fmd@`(E5#
+%QFJGY/c6<i5_1K7E,F>?*M^rkZ^/OS/dsik!_LS9nTOe<<1a:TJ"qVinM\fYVYkWt%)0[kHfYcTpFQ6UTR*;lc?b.(fo]+cgiJ'F
+%:VY?r;8(=e(;!)9K:8lt6h7fdUUFD0K8dM3#0N,iIpHA!Q3>rV`_3r3*M+L[(Fs0%C'$/#[^4#]J>mEm<fl\Y,.m^3h2iXRg%7l%
+%P.Gr/:_K9dlt(<jjU5+<VGD(TIIQ2s@)9W;rrGQOWLLGKLj)Tef)p7-p,u2&Gp;"q#fSUM62%K*5CdW#$B#:?==q([Q2\JUK!()/
+%@j?b6GJ)^KKQejc0'9'=r5GR@r?'Y+m@XCO`<42Zk@ONsEfX=LA9s+4Ia)@C:U/mnnc&CWH8.>(iCc5`*eNi8_;eo5!HWZ7/YI-+
+%gVGrJ'57_#O(oUu58CG!-4s>ir<FbOTe)jKT'^s@4o9e@c2sR;bBa#RA;faYX-qLcNSR%1L=$7;%/a)aajqdO7+Cu5Gd><%LNahX
+%jRr3jG!r0LV8nMH2hmF-^N*tU[\O%ffCf-7;]`nTOi4Jr8,KYu:F+G,I!Ri11rDhueMmNeZl"o&J>FH_V1o@kooCQe61@$*R.G\G
+%blUMW/>)gb\B@!Z,JM,-HUGofS&uW8olMiW+i.o*?<r$,>]Bkr-XcWCked5P-c.<aBdi2!^A/;tf[^CN2F=ZPF6tb\]fXAl]i<>u
+%91C/&7)Wi7Rl3F_?1)PBBnhc5.GT*@2gt9>OI7NpFX)//G&iqD/^FNqibJgu4,=oF&[Yfg]C%l,+\bdKY6IZfjad4$j9P)NA`0D[
+%_!GSojC=p3U%k]/]oc;:]g9RT*eRodDE9JLMf*>l0[Nq.Ge;8AqoE^7JYVh+s'Udo`aamrcc3Wr)7`d4a`oir-q+#rbMH)D_35;'
+%:RFJZ@6IH9Iu>DK'A:8D,dj8Vl.aL?(;8lON0KE>:W!^7M0I;uTjT20r=ad1RGqS&cuWt!oN-P:Rm2;s`F&Z$^3t>-mC2!Op5cua
+%a%ua*5Q&FfIf8NcDu]@ZJ+;d<\OQOAf71"(qpg1ErBnWns6DoIi=E^&rGV]&+91iJ5QBlts5S$Is7a;*rBL5Ef=t,ArVRJbs8INC
+%bs24+T>(9]^\n35qepr^:]L>3+MW1"LMss)Vr,[os5IVeo[h]EJ+]F?rqNdKqWm$Es8KLZJ,ep/?hr%Il!IcXTD$$Kor%,*r(kqZ
+%r4a'?T0Ag<rg-F\kPqr<qF;.e^S-k(q)H;kYADSCDXbZ9IPl@#P^;MahU%;260ibYR:/HbqgsZWfJ5"@#g&nrgrrnc&/_:@@KVq_
+%q:!<K6l]?k)BIEBdR]J:a1M\l^+=Ioq!DY'j!5fi9tFF.0sT?n:\RT[H.uQ0s(DLQe^8$7qR1<eJ1ud*r#l-L`MOVG4'<Mo_Vi'%
+%!H$`aom[*W+_i3=jT3YJqa%.+FnSsZ]TGn*5I0OG+J_ol'A<=Yetk'"P!`o;bn&-Sr:"?f^cd*Yh")TD0e58UXbc.Uk@'q/A+6]T
+%h]@6&7Jpu05COKRp\TeC-G3^[n*]EFqQS[?UV!YR[tc'R>(3pF+.kGMcMqAJb^]52\_cW_J,G@oct1u09A)>?B@Au]n$.N,:+VZK
+%J58<Weal!g$.4"GVNk4.8D;K_$I&B?#-2BmC@0OXa6Z:ig[l8P<<Kf*[9_\]=@\5]_:Dr:LJrMFV6J_/07?n:<N9l.@Q]ZB5$taX
+%4'8P_UpANsZ2p3U9:;;)BW&+6cY3)p62'?cBeC\.@tHe3cmT^pDW)IGXd4k^/\F4<@f=iY-L`iNs43,=hZT%nY8YC=.eTUh!]?&%
+%iLP=S2XS*DAbgi`O]5L^[sQ\l5eR2,KE:IG)EZEe8=Q#4&FZ"e_W"-VV`U_@kf*u]oH,#XB`0bCYLAAMobNG'F*@&R.EBkL,8<5@
+%$VR2<-cCa1petbY\p,^:U,f/A@R3#rF?ceWjVFh<nX[7a(TT5P?<>PArcI=5OehXW;C&j&arnM;6(Pi381%AE`uafC)u%kLL.Qt*
+%3jE;(TR$&"baH@$GtF<HUE$-"EHS<0deTfGc.U?.W"e$;>qeN8gMUTZ-Qr5:TL+O*P%9m3D@_8j]n/U\pua[r(.OIU^c[7"dqlFs
+%j12Af<?qgUbkj1E-c>^r3$ghP/T%4kXBVT`6n,$Z>UM]\\_,"b5c!pED10"3h1<I3M$>M8PG%:G;R`GKHl@?[T#J4)/udog:#IiE
+%1q++569fOsY^=u^OdaOJc`"'=7u;jZ<q.6,4VNYc<a&66-SK*RhY^h1Pr$V#ea]NNCt*FIe"33RU,RK^ghGSnBcXLlF;jsbW7fAg
+%,di*_\:M9RU>50D9NLKtb*q.JMoeB9CEp#hHA3V@do^qNNcj^8<:4giR_V%<$s,)qdcM:ao.roQ.V6#80@Mrm;Sra'VPG]XALO@3
+%VfC`?^9iK+-cp?%W23Png04]@h.Nie^/R!9[".o>ZdgMnA7u+jKRe$aceV5`UlS>bo,oUtE[.EOBL1,+((bLQ94j=7;^B(LSS'0#
+%hr1Sc.*o6/gK:-TWCT'JC2a9uBGd^[N-:jQ<aSLh*VB1J<%!p?Cl>_H!5[a3f*GJZ,!/SnUQMbmJU(SYB04BA;O9]"Af<1HL$`hN
+%Aq8(t'7<t]aWa`VC\7#2$jaSbEZ<"(OiL4li_km:mZ[t`J):TZMi.pYkNkH!gV@[1c'%f1lf?k7D;Vi15?hF<fcV%XZKd5-b?!oL
+%BjP*p3o+BLm0Qa:0Ci6,QXNrE3c5S_X?hOH+KWN"kkJ99-$"<dZ;88%^;FaJgrD=c(Ze)gFI&8qJ=1Upr!i++OCPfYPEiV_Z%ZGq
+%JA#jA@a\d[rHfunh(,J.OWQ#$BNe93m-r6S&:T-3o_Bo_&QgB)+FQfSI;;NjUT.JhCfX2$&V-2&C,8r`qKgZ]?e+lK>M/VtfGZhR
+%8B_(dS^8pRGV@q#jKN0SY?9e]ZccKo^_s3X?3,2:9`")HX,.Y/*YRA7C>CoWD5h7>r+Re92pC[Ce^1_.Tk$H0KL$(u+V.n_#bbBg
+%jqU2spM52b.7ddPemb]=Eh)bDa]DR6S<Zb,%>I'XHBosRPV]*'+A,_+;J.-[VR@;(`mAZ)5$SN&Qtj+#:r.L&+3Gun'?-&B0.,%[
+%%-8k'nBajSOFu/+cn<aIWdn6OX=%7ChaR7;crMu>pn/V/1p$CSn-s@Z[T73h\d)!O*>L8sUh2^m"s8!.)Is?rM&htk-AcB_(hS0r
+%YPMWpdBKR'(jr@Dl][Gp+e/-[W6tBLpO9(io)=O<d"m%fOAlV4Hu@PKYL-57VuYDUa3/nM4K?/R_[b480;_:b^>iYe$2X@)qO+`'
+%;U0Q0CJb#=_fHsnjdRmUVV/\QD$3WfLO#hLgSg!co).m/1%u\kkf'=jh0@MX<d^eKGAbpm[%,4%DqX2GTBd*`ej^A#4<n(hd_Dc@
+%mQ3;P6%WE#qIr5:Vs7_p=1XN(Eul:KqmTGmkMfE<(VS>t3q_BJ>i$L7NLnujek&a(,q+W(p/Ra.Yp"Tie:/J!o+2Pb$LM-@FS/'B
+%63sPf"Y#)Bo+G)F99^1J"%i%]qYYAPpN_j6i&6X,?cG48YNS+:o<;hRI@Z..Rp3SPK9sJ<[L#0VE]T)4ch6",,JU(no6%`=MjB!m
+%dfpnIj:Sg-2MoOm9dH'&;>1/eo#^!t??LB4kR48--(RP:HX'q@TYW6L?u2")Q1nWm\-t=WWM+O%RQ@=/:P@955//)07n:k#W_&@1
+%_WOe??D,'e^er/Qm[tiqS5<L[V3IER7.Ne:[he,son(7cki,AlJfS[X.#dcI'*LLX9NShkR>!.cDTj+El/ZMR,-4Sp"t.N1[,P\>
+%?2G+6iFuffH#^VVd#.h#cbM^cmGR*kY1B:r_kGSqq&rmRC]\\eo06Iu6H>PF2G&nXNV]%sY(:JQ;FX0ArS_Ls<rV[IXV$9-?2NC"
+%dlm]tU\!EcB)^neNW7,^^-Fo-:^"Kq<u^![3:e6"K.e<]&s!k+Jo0W.e+i\oHMdu]]KH.%hELkK*\W:o4J$cSStD$]+!,9[a5E9p
+%O3GYf@31J6kJu?Diu\$Xjlqg%p>PH:Ge&TTn0n,-fQfS8DY)cmF.5Z\N?0a.<ViXMIs\&"^O<%$5:Fre51I+bYJj<!_,0n5UZ0*8
+%YRB=TLUW==NJFQC)NT6-XjMoplg9=!m`>t3jhop@nS2G/jLZG)h`a/;+-5M:cO]QT%o;-(bC01B+iqFrUF.-G"G?KecO:'Kc[T7d
+%aJ+OK&JAOeofIalRLT,b_a=([h[p\\!T+V1iZ,ZW3+P%Sh\@4'4Q2nS+C`4ZcOUVUK^T6\R>C;='<-fV#o&eXmg0_sK^T6`h'VZ5
+%_F=/L^FN]6>?3s9AAgq,*C1n`nQfQJqb"URE5W:cB8;N6@=D#AaJSGii?OQU>lgbUF8.a=,c97B7hCMkMr,+9@RA@a"Hn!Sh[rI9
+%&`4<so$!i#+&8Ocn/VNUAq>D$8BI&pIr8*)1IZeB=NU,N^FQPL22=CT[,h$f5<lYg,/,S?A5D3s!_as#HU:E/49+(Y';+C4%l;m5
+%Hrlt476Cl60ua,RJk],6Fnb]\$iFXaIA8pmkIS?D%c?=AVM(T/qY!GObWTZ)I$]JKZG4:GBd1:78]db+45?&n\],PdMPSpt+0+=7
+%q=B5=SAW[6fC=[mNelNk*sr&Jc0p/\led*dleh[/LL2\`Xc^f<rTE:J$B;U$#`:_/J.#,DO-TF=Rh6Bt'0Y%ATfH\t\6:7SjHD#4
+%dTE/aFJD$=dU&U;IMj.-Ls;ct]apA,CYb-[OF@9n4M9-Hh["IAY9rY\:9ErgC8r-H:4JIP(smFGeaC[5;K[2Je!MJ9$-4#l9<2sr
+%Wb/gKT#&,G<I"W"V;L\JT#QBZrj'D[93[W5h+GRSeC-Om"i_>-V6+>N3]59FIr-=$+'$06o>VffUroPUa%$)&JV_d#5N[T'B(C!/
+%n/?.`Jo'N,L/dPAd]AoNg4m?eTED_V"GlsO@*?+:kh.^NdL61XWe$-m@_hjem/nIR/i@6'FP/)DbC0mQ3,+1b[kOj[m$\t:T\k@&
+%)a%>IXPeA@]\N^J"gF#77m%'dON1B<E;C!_BmWX+>W7^R[8>\p(1?)/QS66hd/>-51K12l[[U&c)Fr^/VRJ7JhsQ;)&1UW]V:6Pa
+%`M[*A[02l++C(pk]4\hp`_'#-d_$X8@_06+-9uF^^3I8lF10=0LZnA8ZST:KSsM4a61:$f%:/`?IBH1dHcB:Ja&Mt[j#%/K.)G%D
+%cRcjr&YW+]/+3uA&Ff0HC9l5?a!]W`rricLN01]e[L/)jDDYt:hK?U0Ci4BjD\kV\GO"2S<8ur@aRkWkb.>=/)VS!4BK$PYD9juJ
+%pM!EHqhi=7_.:0`X!o4XI7)-Hc@0<P2B3ZQ"-oM(<VKq9CEo+l0,_f^G\rHB",0X,+S7?tpp<XX'2Zb!13TPqd),+*(l<E5ZdhP)
+%LWsZ(G=6c(=#6te0&CK@F2!r`Vk&Qh'gcSG*m9aU]:-Y6_qN]OY2WE'4[^r9mJ<[Hi$F2R[#qV#+0Fp6U`M`ODJ"G:oZNDlqGMb!
+%7FsAAn8)hCqHs1,^!Te,<H\W)cT=Mif$d6ioo.Tr4^`Faa]bR1qlgP^1N(ZS,fS0'Uq6ir_bTGX#p-TU+*OkB>?#2-XUnhU*Vkn`
+%kS8eOk!!FTZ4LWT6L(W>(@\/P2Ua\9JAW/%e\M`9HVcV]AZRipKqQ;Y*oL2R5R]8$ckaOS@u\d\#f'P`W`-9ndh?9U-S'D+9<E2`
+%W[:E)"&N,k+e3NkMiS-Dp-OY81h"qO0=u!ITMsg5[I'rdYZCpF:Z$]i/XM>Jn#RU;KLkR*R*BCD1Q0NaKiJeFhE4hX.$Hls>J2p3
+%g1U^-nb^$F'gW/=oV"<?:B`DSg;\Bc&r"qI?=Qk0n@rnjb-/GA;tft:ZU2Q.kG3R<SNDF39c=c:gH)rd@1=I]^clQh-UcO.(I)_)
+%'^OlC`Dp<Cnm9N1n;RKI?M#u>F&buX!h3YD2RKQ.iQ=)2Yb3GlJK7B)2G9>Xhn\PF]k&Pnb(M:k%KXt"&!00gp/XE!pb1oAZ/CmH
+%O!")kO%B#1nC9K;gDloXYF<07I65h\E>-n\det\-kW?(:cCNbTD8Z?qH5Edu]!@jGecMLJVS_X,T;_0X6EY-")^/*J/'&?sn"?.o
+%W[KsI_$qrBjYWPnmBAANa27?q>U3:3M^LVo-V(R>8/6!)n3LqR^qGEPAt1iTHuhf@:XA66Pehc%[h[^dlEI4B4TTC#A=V^IS)Hk&
+%CZnAUEncHDBe9Lg1$6U;a)f)<G=:lHP$(o@bVcLCp5[.a2YLD:`U8Kn!cLP(bQ=<m;OT]%.,s^90N)8!BV6N"33.$$E\c25*Y!3U
+%M7\pRj$OWSL,j#NR;c@8'k]Rk$YiPB/S.0A:iG4kN$ULG"s#C$.;NW;6NScJSV$^seA!O5*`<;g:Q!du,;Wo>)df_dY!C,Z\u9UR
+%eX<`n7U]eWl!K50mRB7<>!m@tYGi_?MphE,fa4c]gTA/`_H:u8oKMp;f`ol886.1.qekpuDs1bOT>kDHh.,58UYFC5J3_q`JdB4\
+%S%X)7<H"tq3TTDR)O7_skmMb/"Du=MP07Y$eSifr%jMWapKZf<\lhg"3DfF%?h0^.WqJak@HK?M/TH\;<r6=,95;U,[Nml8I@Blt
+%o2Ac.!$05_4ieAVDRr?,7V/?k#o<PbloUl7dG2<m<l-R0@Q">/U\NN?D@dFGO5jYhD<RJZ=I8Qi#Y=@YnKH=P:s"5>%JjV+YQu==
+%jn!ST>_ffGZ6e^ak.RaO@ha%7^!*$*S4M4?&*.<`=r,0QaeQUs;00'c"[+42ouK=+A@>"rDhZ+t3@(TUb7`ZUE:J3L06&*NGZAE/
+%U^<P,qP99sc;AKn37%st*W^;;<-O#5$gu2^,\7E1J6]P+abgRD0<XrIkOc\69;1.gjb`;==)X.rpJ=N4K3/"Dn0j2kZO:@&/B;]e
+%of@=Fe5UDbbGK\EW[*h?)4@A$=euj7;`?+9dp6k>Z=U)H"+%d/;=5_(D(FFd*qbp2,@,kh=i`Nf6gumq2t>_lV\_W%*)4'ks20d,
+%Ie[9B0B>'!iQ@=cr\4l>0I^iKH^!uG-i:G5D-]?]!MjA2k_gpY?HU"0T?%S'ls7T9@>g8%B3du0O9Wr84,]bP(2fhp3[Pac/VBn=
+%R[IBe9H9e6*;M!qkX^j@3ftZ.?"pMhXtiAVH9A!/m6Fcg!s/;G/128if@0=lQDZc323kUo\,WjOV`lbSS;XLG-gln"\S0u;P065b
+%@Q?T>-eNC[.Ou,$dt2/[G2pp6J7qDA-1M,s@]&-pc#$uY5SB2o:)[bHJo!H]o.j.EH-fQm+_fABGH0lTWmS2,iM"*.FnGO69_3U1
+%%7k.*9TaS"E]cE(/W-Oj%8saD5Dj;`4'Xbm:.2n6%o8/oMPt?W,X:W7ZVn7nG$<SL;cTrtJUgtNb]K109G-1ne"s]cC(5NT1^h*e
+%-iWlmpNEos(X$2*gt<T$QCIKe51sa'*;dRtoXKZ>g[Aqk:NsjWqrj5,f/!knhT*#kDkg/[Y_GWYQ/e?sTR/b_UV4&#4OFU-Ib<:G
+%nq;Us2psp4E:B,.is+8R;i_"i7'oSp2I0g9:*7m28q+"'d;=,8XU[C8PC""$GgHG\+`aVC/7BC<![q\OVP6-j%U41h.eXJ!M^87s
+%(RP3f^>kPn?cXZF:'XI3Qs0X;kftrR8Q%G^g&]+e`iAbcOJ&NE(VY;@@U,.K+8R_Va#H#!NjN1^IUZY<U%CFJC^YH:O.C--f'foO
+%m887lXmJ,"HT>/;=ho'^Q!?DA-<k7@%%K>#j8.-Y\_0Mh</co0RcU5kM6omV405@Oggf5XTRBo%(u<WPB33VuI+b-agL[hN4L=%=
+%g3_.^6]2dCHg<I>Kg0B]I['f51"T%^V%k7a]Sn[2dL!qcpkT:0\7`$$#u0:@@7*hi3]b`G2^X_b;p`193N[_+koZ^OP'\c&W@IVW
+%T.2bF<1mmhOtGRhb10EJm"rks,+^3-cW.g%(W(Ci?[@rD0DkV#++O7dJ,[\W/Wp#s#2u135SX6r3-*b$a`Y3*^Ak;0s&:mWNP.m&
+%V";nIfOGOkd;AOCKaY]e"*\[GY2&j_/E>Ghk/S;8QI5"sZ<sk=,YdJ^&DgFAn1-(b&Asc?DGK,GVVm'J#4WohZK"%QPDN>K3_bYI
+%dp(>HYHU5aB=ctOhDY&.#KCKtO<63cfflR<NsBM?S5L71*ACD!%I;D4MQMb`WJFX?rpV/_o8T_q(&dQ[fWWu=pQ`HK"L^YCRbiKe
+%49e\uoG.5.[0"bB5GXs0\dN!Hbr[iKrij9c;efd1%,)Ku8(O>UTP<KP^"Z.LBqb`#Mk.KnW9r(A[8VSrS+,1R40TAd)Bq-eN$o74
+%;@eNr6(VjL$IWh+p93u%G3ct*;h')]BIFtm[8_Xo42Bf5B=n?:SkXb#0I)j5p$f=`3@?c"G+,R;b\p+ab583C`ddC7T)4(Xa'#hg
+%En.eV1i7QCMGZ3(Z[J:?/;_MOO<p[4p-7PkXhgBZ]F$2+Ar*D.<W(gGE4Tf"WAEC@NRfYqC2hR#CK1\]%=HhR2<</HnQ0=i+HG!2
+%_Yg`$V&HMeP[<iL/3NNo.se_%#:3Q3$jZPZ6r,lop1(N6QNU2+/CdLg+(7H-N=b$"PRSl?R7BgER@;of03oS]VPhMeK1sGtm"@SI
+%1qjuB"eXj8emrq`H;M/d_4.<GJ=a@c4/H,0(b_bC7&s=Gg4<./I-c[YCpmJq78-`46AKc;q>hd>7lNZS%YB_?APW0'Nt09p%R?$F
+%g@Z<!V<\l@]KCd]SY**(8jf34^(6]3?O3^Zq4[J[_j]Abjm*R9qF>)WfMb`[Km?$S_,VsuSO8HIo)mfo<.2$]Qtj]E9Ug/Ep^q"o
+%2F2/Fj<HOoBY>TM,mST_CJ3%AYP"15j(bI]=]dEdRa_A30-!H8PbV=`6U@S48Ei`0.m/R5AY^1-Z6+:(4sJm/!iC*%ZAZ-..V5K\
+%>+o;oG[/8nIX;O`JURU<DYCRlj]ecj[iM["*C9gsP=2O6MTXIbmi@%a`p=cr7++T,;O'i2"G@-8aY5@L:`;*i\ba'MXSQALKL,nN
+%!O7QSehm=qNnl:!J&5r^k@KXp1gk_A!sa1t$`g4i%!mPZ=jXWXlAA>PFt[0@$)Q=V$@L?LCfS4PqCVEnlEhJ1d",Pcb^4mZ33XS9
+%3Qk-7Z[9&U33)D,lQL*K,oXA]9WiIAp,Q7+n'Td%6M"/OXO%XK!/4:;16kI[U5Wt'9hE<qP!448SCXRB!Z]9/=.MU#KWgbpI3>6t
+%kS",%:IGDI9DS;GZ8r(?4F)fT8!]@6A&"@gm;6RTLo4nr7u_b2_]S=70Ii`QplA+H3\4RX5*<[Impi]H&`)f,Fl'\m$s:PgJ>!0>
+%gt'(08VVHV7cD,:8b+)a!-<GL,`4`?BjnHL/L-=-pI66`U"4-S_6H@_6RJgbqOoEQ/L1H_*A6\>,Iam[q/g8cLK.\bML)]!obG):
+%DZa!pR[3FIYtV</'L9.X<Y1DB&,$BSESf>V?5*M-R*^-/YK#B6*JVN&L>,_+c9t!j>$a=MTUonH"oSqpR]VUENZCeUEX0ded:$5h
+%8[q]GZSGPpHa:VLjM$S4M=B6Ec:ZA-D91dq%mff\1g&1n#*5(jdPTS+i;s0Pdg)R/9In*/'W8KA[X02YZ@G*d&YO4Y2S2gbcrFcL
+%TS"5Ck'[h;Aas#/mkN46lc&hU9#BqI+@sHWWKhb1Hq=Pm)t_O*7D,g,.sJ7//BVju+4e>1SB*&e%G@eaS*se]0'"<[%:;Qj&P\jJ
+%27LD^1S[e'd4b6uB%^]4gVs_jXtXi2A!nF93R_$Gg/W(75nt2e*XTX)*b+lJft/8<[,/d*0a`\5n(+KeQ?N`q-'0`F.T/?6FhY,5
+%g5C3MCEmKdc&`ZHPc%"M0E1)e55j$hs$9?E:VZ[OZ0hSRLL:)D+"nT45Q'?pR`58as7sPUs8/F;Qe_Y2-s6?oGbZqB?eQB5_lmg#
+%Rn$%1$u!"Z0KZ6k.pN%T7E7O8:/BnS_,^q7CNiQ"(O4sh\X2<P-A@g52bNJHW0=)+*.6`:?icqem`4R)\+Q>S;dO;t41[L?Mn8#&
+%*e*k?:dqb^JKqj1\Y=WYbs7M+S<U@V+3<C&??^p+71Iq1)'$7G)`2MHf$a4"[5"c"LqW$Dm`Z':*j":[J>4RpYC&9g\Vs]FDl;H(
+%.28!$l@O/Ne(.gRdT/jBU[D6l1+ET#k?f=^FD;qKnVZ?AMS)sk6I-5YFOI`bnI!ZR'X`V<F[(9J';?@[YUAn)DkNQ\%']?1d0@^r
+%=9JD_!EZ0j3B&45Z\V;c;j`]?b,df/**6dsG-c&e$DOM_JgX4fK>1XKiuEa>:cJffql0iUc,_tcoU4\_#5^JH"1)r9@IR(7$LG-_
+%W+e1,@I[S59g;Xu-t(MT#O5O[4.r$bmHpVDTXhXc'lTeQ`;Mp&4gS/O;/7V[5//qEj4`bOq:g(m=be;<-t@lE"HUf'bC*L%3qL+s
+%DS8"'9hYLb;LBLU/Z*5)mI8%3G`qr,96@[):@%2Di(7ek</<#[P4iX_j=?0jbsTshk`HI&@?h1uo;l>Ld^3&PN_(tNYq^fVn'hTq
+%/9.nZNg:d?&TNQNFdZFX?u:<^SVmjMAnfTr,%@2pAnYZ)pJ3WN0sE8ei<*h4K48nMDcU2D/okW6`=M4t?1tYFd*rt9o3WY^[tQEF
+%AD<N3a#8Im[LoNJL_#;b2@Bm'a4[+b"SnWk[cSs!#]VM>943+0!-:A0$e%jQMS^Mc@,3d&b3QV0'k?"".)aVSk%AhF>S_97SH(6L
+%eH:H\M..4dbl+*fq"isW"le+'%;Mfl"+6p]aNRDU?iYK"oJ$9@_6=ll-ibZ:/S=2G#eaV%dmRRheS<OL5XDFt[bK>UIeDu=L:2(B
+%4O@ZIgBAU.8)'^qp?G>KYbEsoW6nOX$.'1]#_*tDB-*0d>V'EBQU>E@B%E'CW/+;g4MIWoj[lH*mW,&#MK)drLf=i<H7h`Wa[<O.
+%2"Paf\HrPj>A`\)fKXPFI8n??T'e)rHb7nt"bNK'Q45HrFpB)P,&/6I"rLtS6OD!u<bg:NCto?+lDZ`)J.b]V&[-H6'@)6i'o%#A
+%=Y)lRs,E.!FoE>)SF$)nH@S?9U3*9s+RU`PB?Zn!OhrcEmokABlYMKQlZBJHaYnVEYW$Z_2K0_oG6gBV4X?C$=&"h/(sHA,7.YRN
+%aNP\#-o[TK?F_<&<uj@Z,FS[[HpeM3f,):Kn)h'_kXe$U6'b^A$r4kRa4/.<NBKf'f'<07djUlY%sYAgjPq&<8'(nIL1GhbJLF3q
+%NG1U21,Wj>l.4BINM?9>>Wp-gK_Ra,!"'X%J<e'8id37:#oOBfa(*`(a[0$Z'Gq!d,tO3ll+N(s@)7fW;b,l@NMjL@Hf'ncVagpZ
+%!$@,DXr&"<UgR5mZN6VI(>UA5MERp*"$*W](U)5d/8Fg9p"e>dX0&)m!nV?F09#82A,$EO)pFRap[3!U\[W=nknT4E\8;'G&RX"e
+%bMf9,p:.LeD$8C;n!b-2Fp9G)C)Ic(dZ=d,S`%=iCj9<]@6k@(%F^Is2Dc7#g#i>c6oel%*CJiN7SQ`eA++C(C@$N0bTNND#;*l+
+%7:_cOkm/__n*FdDH@Y>uT^YO=`dp'lR%INpe*!tlgg::lf%8JS4Ig&^TiN2-+0F>dBitGdF!DA]*'CjZ?q2tQoj)dgc_kk$;)Mjd
+%@0M_3f8*L;_&ffNf8!nGKt-<cWZB((M,.ilU^4d0eHgCpq!r4,!2$c7[2ZH(ZiQ+hE.C^Nm"N8&bPB3sKW\i6aPJ3M+.d>jemQ`T
+%@<&".,[k,t%9-+jQ])&HXrZr)'U8s/\W'2=#+c<Nl];Q=A/0hN^X5D^798Q\gurKNE2+-n`"@ecHI#.PU7$_=Tnif>BeeLuJaW>5
+%\4shQVm_H12(@^iVWp`i<lMCC;qGV(cLHLnP=^I2NnBoUXmehsIdUr)&)$(L1X;JI]_>:mI5CAdi9=Vg?3:LXW5&S>dqcCeUZr_:
+%8.2KkrDOR$DT,_0N9GZIJ^[G.@u3(E4/$@KQu8lA"[d7L?Ep1JGcW'ug5shHqD'+IJJ'cCB.uKKII]eX@%B;+2;4''S8"Cc\tLTL
+%$VP`;lH#EieQ4m3.(/.PE#o=5Kf-40K6=f1;"e?)Ts=F1mP/L%%^T-k+TRhS6qdj*Qj#E;^tAf@%LsDP-W2E72Brb..+;u,%."J8
+%3F/c68S:9nM"JePab<@q8Q^^!F]lN9*Erag>=K*#S:>]H(nS,4&-_qrCc(h&C@:Y^f)=:7BLo,Z4<mgRBK-g+m2U5Mom&7S!L:D'
+%$()JG/ERZr_h3*^Fq+jES4Qa5<oUC%M%s"/O3YjkXUZrB2&8uXP_i^bp\Mo_lfqh">k;rWQ)XoT%BsH0>;2.\P+<c1$*Oe(>@`NC
+%0)!f-5\@V'-:/XkR`4Kf%(t_\RWnGho;4%(oPURj^!*fa"T;0@,<d3H_X4e))&!4`fA(t9E^uX$1O'B[WtXtZKm[!ejV;d;Yqt.t
+%1pp:`_eHgJ7skn;FNK-'G8@hnr0^DLZo_&L<g`rfYRC5l$nSV2'Xm'(JN&WhgIYos;*1Al"IY0j9qHIjD+nS:_9=[jV97:$`@?:s
+%LS&)YlR/M_pcAtU*X]b:<I^SVq!4a?doFGQ_Doa#bp)*p\Ko`*bkS.5.:28)DP#`C2pSkD;j:$c!KkDKb$g?%Fgh@-fKc=Lb"K*h
+%m](sEr;*hGVI?2UoBW<fHF!4O0(.*uf2KWmMnh/o3go2.6li/75F_1(>t_5Y#+)45C58C[i,LS\L8S%p$-^)_Gl?=`/@#=\,*m`]
+%APWY;5YL_=bcr_\f=c_Z5i]0N$U(WKqF"b5>%k4pM4kRp)KCuMmbsIIW\-1'l:Nf;*1_k3WPnUGq:DW&(P5]QU7gj6FD6KI]@KQG
+%.,Fiel&,mP=AhC6V#m]HArFR:C+f`VkFul18Z%sB%GUk=V=kqM(ufpXnt/%a#!DmSPEP@.?gGETSU!X5j=th1fc6j)PV8.3jJb3C
+%Bg)qP,83GA#.LTXp_P\K-niSA-pR2/MH>Cd<KfEmg)W/`0l`^VH=5*r*f\Q\<BYfLfRf2E&d4n-fnQ6sKc?LkL]dB^W1AmL7]tq0
+%nKtY!FJ>oMVgO2B=.Yf70(Z]Z+UHO.dQSqkhTT6H#IWo6AW4',/-W_kH2!oDc1aWJ"@D1]>L!Bc3Obb;N[_e*DjRg%Eo[:ic39s#
+%;;fIdEe#271R\k8O_!e2**R`$>F7D:/<N85\o"cH0m+dtEfZbTSN#2=9Z<)9/UWSrMC8oJJ%g1`HOA>>S[+6_e4.(1K$+U!gZVBR
+%-Uh<Al`/XHP<"uShf4QJpuu\p&UpfQYE-?=bo>M6%o\O.KO#sf<B4`/][=4(e-%e)>B&L?<^EV=O$D%*fWd6L^FC(0$G4u2YB[UR
+%bhg6-%;1f?CabfQ?+i%\-$g'<>H9HWL86@1;7,?.3?c4mgT-_AQ56i=\6<9L3l`6r$B(ari>!R!>&54aNmXppFaNOIVeoHLARVD9
+%7uWO(<lCG=\.Y:A>7F>L,U^m2:ZcIBS]B7re-UnY_@#acU&TPEf^!&C^lgI6TX+j<]r&Ur\4S5cI!,0II-Ngn:`K%eWIrbmrloU7
+%nMG'Z@S62k1G>%@CiWF+#JS%\C5&]V*IoJ8UG)lqMQON&X?dY.o3c!OnhXqoYmRGb"M1#5#0pbk@uDA+mBZ[^%jU[m3`S@bNgf49
+%FN$&E.pL[PdA,f$VEhlOl,JCi\HdJD#3?Rh"B9Of6pm2u`_/S=!4>8e=g1#_idPgk6,`s1WP\?dTWSh`*E3a1@66@Y?6Rj#)mE,M
+%R'Ula:Si?="g#-/4(O625p]eS.Euc_4<-FrST'Jo7`.Xi">SZrY$]G?kQ$$F'l%ajdf6$1S;hL*MJ;Lg<S''n&P@eI-0KUmXi9D?
+%mlCq2A(=N%kQ<Q)Jtilf6qC^]4EbHI3Wfb^M2b6%3dl&RcI7!2Am:kBXYTg\2&7%F[0=-=peo'dGfM^[RF1:l4e)jF?!$03/On5H
+%)4NOg+$P7NDX]rs*bp9X)NLf5`MnNi#!1(b<%&iP:+WUn9.#Y[0P[<4`eliG[039-8#)&eC+7@4"OlKlpOlRGljX=mB!lpnF'YGH
+%;cB[KrkWA;-;"opU$gO)r06GYs,<InesNe@6-?kJh/-o']L.076(A^`5qgs&k=Z<@0P,RbIBMDsLDX+o4d`%=dg*=F[-W)iQ&6uM
+%5R!]N8CI_#BGnAP#:u=#Xj]PH1V=a@6o>?!L$BfP=>I.0&+\KV?X:.[8ge(6j`WS#=jnMJ*:UW-aP%BR'Z@f31?r2>D0F+q<1".g
+%ob\.=\XrF:+p'<'&@!C(hd@9])et(CK7uZal3f.DUfku+/0C>Gm'.]mAHq6Y83s*J"\?]u/G_^U-F`!`o?t"`_@GQhH4Ug]8./?t
+%U&-N@Q<SsnGg]EJjRLJN+_;mp'5)CPH`"06h;*R9GNd[FK)j9i6$C6_kJ=5eXh-G?4F*rJd[Ys!7:%M;!O[UM@N&B>/D$3,`iV)<
+%kSi$5bpFRdXaICuF:U56$]Bm"4V=?t5SP3^VE*H?gte+$%hBJ.\*pZ"9RCW27cDU>NtZ!6`D^`3g9H4Wj!"Mj",j\"04&&QDU$i7
+%V)+&VM9*'^J@N$R;`mLI]AcJ[nggk8QtPNfbRdu]Q=6d6A1ZD-hH$c/"i)c7Ad_mFh%-j@HhTW`,N6HQg&ai;4iM\,RV$-R^@Eq=
+%Y@j!?05S'CSeo-&_QuSlJg0aEpKa>7[9*S&Q.#r6Cr'.j.?t&?if!sG\.=fUB["b#a\[&OKi7WuOOPJ.I:`^uU!'+(1(;]HL8N].
+%MIJIX]'55?#O#b&Gm;F&HH!`%$b@`n-e%4>#d)$VQ'E:2Bc:s(o<g;m0:EnQgE0NV,Q,F/rF*Sn8,NBkU&Ptd%Akso`JE%'NtmUM
+%@_n'\4K.F?0XdUF\-L?jOF]@bk\6p%J_%sIY[uPrN2d9Ua2;j.0*GOiiaf8_%R'RseH6/^U)ZI<?rerB6uX%eHtP>5%bj@P*(td"
+%o>6W).4>0T-8FjWnfMU*6Zr8KLIKc`pk%#5C*5'G"_W5^cj_h!?apTCQ$`lm[WN20#!a,K.[:<lNc_.<*+ZdlPfOMe;/bb^aUb;>
+%5jnQ5n5`'@0(s61SRM44Mj7hl_Bi9jIi12\$GTRI:LQ'.fY">*is=,pn3"IsEslkTC]_p6ib7bXd.FN*ASY=:Ane68LWJ`Za!57@
+%2F^p3bmmdK'W]h&3%`p8H-h*'H*_e=<$`]uJicViS+ecTRZm-77hAhId\I:XnC.#QS:Zr=RYQC8dV[+u,IR,_?raBDg>c^)R?KV=
+%U^65F(O@pcm-)#kC/XS<@jM<O8fl+KV!BcO$`S%lfb?=*U$_9YXGsq%XcpS'X)Y#;L7ZS#Cro"gd2O%9?$7>'Gd[13T$,RiO8F#`
+%roOpE"'.!:QXIrIf->\'_K%IC1lKch5LtpZ7sdW5Bk<VGRDYE0I@%i,Ca9>1Z:d$.F"eo$M>*b?RPq&$30Q6pQg1A-%XlT"<b5Y7
+%$Ip.g3l2%G)?4VsBu4Z;NN:@KLLu,5%Ti[kYWn4GhVD40!Uu.e(8^d5[i)l]h6n*o,#%s"INYPLXk"N@]ZBXJhdEa)1-9lPNC>n$
+%f^:n&G)L",;Y!;4>bQ9i:[RXVe;_&&\<i>`.=R`.-`ip^MgnQ,5S5[qbu5nRJaT#EdoF3*/?3Y%BSY,)8',0_1KOD2G2;W$ZOB*;
+%fX;o6,OFd)YTm>X1R3&?#59F)Z&e-=,KhB]?dm/t^!J-PT_m9$N[#"+]5Qj$'>E,%!AAPCE,$0W3`W8sQB)%$5m!7qGP@Pc$afI1
+%o8%L57<Rd;k=7pE`c-D+^>m-uI>PLQ2XK$afFd=6SlU"iNa+>H/JCi`PiT"5(.B<9k,&)l*iuC6IMlA\+Wa\/@r>SDfk4_;S&!ZZ
+%/!"=aP;)O40ZdB[0rD"L<&ubcm0O'c(K+lV$_a#%Z?5f`5k^*k_JPgZ_>63H+e[2"d_sG%M]5e^"1;>$&:h>0eV?o>/Jr);N+hN4
+%Jr\B1a]][@aEZjG/j7sP`kdm7h^`nm**$qlIRi39@?6B,_dCUn0;RZM%JVijm@8V-;5T#hBqqjaX<l_kBZeSGRUa6`LiYrWVg#c+
+%Sc<0.mO)u4J^X\r^jLnc>ES*/7Vu#i`f;AM,55,'M.lB!1ARel9!12j$]K:3&Gj@Ka"jXn$F4M%B$e^B\6GEDLNBR*3"L6E<4/S&
+%M[<`\OEHJ2^Vc&bLYi+^K9baQY"tr`[BJ&4ne"pgV[^uSnd:Dp-P5)BQkt]7g5K!Ag'VLCrBt*BT4!58:.AL5oVK0agj86NS8^],
+%SMfS+C6`3W0L(NA,ZT!goO7uH8fdF:C0aI*<Tt\3fD>hD2A/@d'PHSjhZ,Ws#5n\Y8YFG,0qoVJnWbWGW\fEl6/:,@=g8WXA6*>4
+%S5KEV>f6.$`jmmP`/u?2Yi-%cBsrTu#mZ7UX9$?<__.bO33_q*dQiC%i!DjYR))s<&Tob>;Pr)=(@(#jCP-ISeBR%.&/KF8[p=k,
+%bEG3L?[S$uK^V8acDYaAe.EP*B>R=$4YdLfCC=8Omo@[HS&%Yu;E\FEbFo@XDB'+3>k^,*Ct[9kLar,r%%F("g.-t99E@j^R:f-F
+%'\Fp2d2YGn*rU`IRo@p=XS5YG(7[XI`lt!'cX>Z>a(?^6q#D!l=?l/d\/B@!p5E<>)@UCqG7V-?@\u<%Qkc7KOo11Es2c(:.Q7Ao
+%>/&a89IFH=g<?5C-4;'+4'Q8CVe$2#N^m\aKoq%5U./AT$8jUp=7h+[&G^%]SE(=h_JA;>mCRG.$JgoJ$mCWk/%oE[L(LBkOgaQ3
+%[[kW[.\M%gMoNR5Z8u"D7_TCH04G[5EgWaX/HnWh3;F2jn)N>,XR)aT2$jP$XDFd4AB-rI_[=R.P?C&/!BWWhiJa-h^)(SfL#F&c
+%:U*&F"Ua"WPa(CQ_F,L-13HFJ`XWO6d?A_r^%ShGArJm@bK,!@l"sc)rCQ!*"n6p4Xq0e(1IYN4X^e7Vm,j0^#Nd0kSo/r8\Q#<4
+%?#jQV`G^gR<HTsB"3c1>$h)\bkDOr[!8O-^Iku*a4uQ@C$&mWq]qa/ursd.:l#q'aaK?MK:M=*oct&f:aghG[S#"_c>2d\i<UDoj
+%D]WMfY)Grm)u[R`>Ui"#Xo_)<=nb$mBb(:67e^SLG`qpee.cPs)(+co9/*cYe+4/qUp:;_>NjJQ6Jqn@&2u=$7h8U'SZ)Vc%,FLR
+%%SJuR=S?cJ9HDpE4DQc-FTJ.7$!i")$fD/NU`/<d(9b@d%p7dg[\H@bHJ^V,7^+[7J:T=u=s3.6<j6Kb-WR9JRSU_FXXJR;W\!bF
+%XO0nlU1`L[U]g4ECLPM!/Tn>*,AkFukr<5@g8VeCq@.Fb$&W3[I2\*-q3"QB+JG"@.n'fL'HJ"`W:qRX#3n&<LE_F:AM/k(1oc[6
+%0I36U(i1=YA&QH'b^?c%LC0VM$/NdU>T!2#&6^!I&fKPK9Ke@6"I5nBK1AIqq>Zh/HQC@s,Y@>/qAi&!6D,5ErZ_OQ];_)a?lLYR
+%+HdZ+JdSE+H$cFCO2o@hHN=J5"dPZ@Su:R0^C_OLk%<Fu2&tO/o]`[hr^/VanKO=m7=U":U)%:I^0acT.,F(['XA!N]$u>??gS%n
+%G41K.dmpX1eiWGp\)X,b7KUi9VYW3V&.Z(8h*;6tUsIq'iN)fUXscV0npOcBF@8GX`#S'*97eTj(2,5K52hRDUJ\.`rX?Z'pE*T:
+%X(KFj3!7!2T'-pOM+\M-Ve*R:,YthR-t_ts-'-4>NIou>/i:rp]JQWmnjA<.o3n!i"'?LU(Upl2JFq"C6=_C@#jt=R_IX,&@V'Q=
+%Jld-PG[+ZZke#)oS?I%U9s[T*7qu$emp^[1fFcsu[-pT'S#M_HoH[-I5+\Ch`cj.U;D8ljdT&%N=W@/.l?q.BcCgEN^pdTu(0.M:
+%3*%%O6!I3!q]QG]:?W8so<:,i:2&B\.'/XjdIMmUIo.BEN6ogP*RS^T:4Q,ZB]h-K\m--^0Mm#5EohGcYp,%%gjfR<]Z!nXL#O:1
+%]M"FY>TiCLCS%b;[n&tIm;#pi,q`4l_K.a5cc\HpY"OWlc\6`f<nR30k)GW2RVV!3rAMns+8.n4m2+<G.9ba[Jf7XEQ>fdu]AP_o
+%aeE9[)(loLPe/5qP]i7#KSr\q<S5\f\BKZqC7[m2@1Fug07Dt.fe0rj)@B_B>3[+uC[KW6Gc<lcLpMkK[u9O1S5@rdiq7\O4)<@N
+%$LRtQVkY=Q,:D1J$=kjtL1RtkPIJr6b;WmTPIOshX!+^Xc.bJFS3i"eFO'NK<pLfnK`37mH+:kZ9G;H@c1+S7B,S;<hjDtq!17"U
+%GQu#2kNJclh$.og)In+ORo?&&]+rSL+'\k,=7cVbd?1H%)T@tV)<R=0Vf_@IitY,qT)'XbD6(JAl10\bMK[FjN[;u&d;7QsP?Q8;
+%qX?!d`ZlDS;^9Pgjmts&p2d<^R(f1Y8^'?=f/Mb\--G:48UsHg3)K;o/apo@:?jL&bjA8/Bbj#n.I1E9gioDh^CEHfGmhW^i_/>k
+%PjWL(_=,)A-OD(p$GE4SYlk`5,-7cH=?84Cc-Mor];Q_oUk!=6RY+Y_4X:k!fUmKlhJPc#?N3rd,s^0gNj4+I]kA-,U:nfN?A;6`
+%e_I';DHZ,)#9:>hn6O.JD3nnJD>JGMWNXtr6+=%i/=qH(43]b7^@.NFPFM>\!'HZFh1I"rZ'HDZd0@kl5:R6@P+GXsYA?GmQ_Xi!
+%Mjg7cgNT<.p6`.!J"_$;\?H['V4.N<phV%Q.qD.m9?nSPTTXELAWfsE<j-&.R>+a9b&3MGN1aIN!#`)Y"C^g.HP.#k$3J'#oi%4k
+%4WEcCII*JY(U)h5G&NEUD6*SHS7rGKcLN)hd'UjY<Kd:"WG4ak^-[L,NR[=K7Bq7+a[eN6)5Pu8lfF3Qhiq#Y,o)-UU,XOjIB;Di
+%+nP:l00CCN[4`]5be#^=;Vo+A1(un6`L2(=;p];A#DGk%Ng=e2O=XH<GO[b6V/Oeb(h9TAom%qOQIpQZ()sNC"CtJj8o?;`&c<o4
+%j#L7;Gj&t.O<rQl;13bJ0i(I:I2c13mLcYNOCd/nWd./=]nCFEc_ZR_.:K?k4Af;iet0q\,+t^nbdlrTK])L7%K,lt"/os`b?#gg
+%E;(IP\[i5r.O.3ZYA4@TQC^Xh">F$5*uE9r]>7rN6b#d6!*+eO+KJNP6aIn!c_HfU,3L`dZ\(1f.@ps[!In6;#@QKN:#$@KcPJcB
+%XC7kjF=8lBh8ZEp8-cXOmcDVd)o0I0qN)t3"'@o+=bSjYK<!9?WEkuU-$(uShC&"HLPAaa+O6TU83rTSL(ksa"0qSd'6u0:5Oa0e
+%*Z=(&-N_*,Z3[ro:D$EXNle,-<D[20>5Y;JPLtf(A=FN^NQR"]^S#0QqJgX$TA9!M'kp\d7W(i(!F:1-1Qe"mR]7HXh,@7&VV?-4
+%h!*67=B(O[7dfN\j`5Wre(Y,mS9H!S-8#M/.\FZJq83+^l5me@.*jKh.'IkVEob0aY.W`+,(0!IdTXS--6mX'jsK`./Rtnh'AaG4
+%kN:ql?UQg)>C$:<,uSA*It+u;C><UQ(3A7X50?/.&$eAc\`D52S?r!6=jDr`kfHrM!I>N0b&E]amM6JqW's3omjB;1VXX"+++rXf
+%c*(?4nMmRNFXfiu]5u:u^J`OsFnQOeSLN6)!h?Un(3Bp>fs^_^YV4n:DG3%ZY\'+2io;ZEPSE@=E)kU"B[!XDQ@t_eJX?3<*J+L?
+%XH2OJl7tVFc/a;rB<hC'l$'%=AYQ@SS#1OqMU@=KN@(<A=1nsqQ*C;D#r<q(G%K@o=Z0MNT=(#i8''%Jl7@P557('eRP42nbB<]*
+%CggHNe='VZ/ZLMo=E4]f=/#4&rk)c4e'\=XV"VlAqh0IVM?'2/MP%n!osiFg*BD;C8r,FLkbZ&SEEf26nmi!Y'K2,IMuBlAerP$G
+%1gYd*OP)?#*q.K5.b^o;"FSD-I;JEY<mT%mY/#mS\KFbsC@0E3N)!sa!;E+LTIAVXJ:uP`4,@cEUB2D(YZ+SJj62W;AZ)PT945>4
+%hZ/WL3Wnn(f97Uab>,ZVQQ>.Te9g_q57P&AEu++WAM/P6P#]*J)n\id",@bq#u_i`f:_k0i,D>O%S2LqJ^-DQ'>Ql@oH4pBTA":`
+%1GM^.dj-spl#-""Ng9:opLF.&(M60lEQ*de`NIi*/4ho-#4$8%r`hLU]ROb.Ijt&Gp1qhoaub2m.XHD9QK<9Not7bff$L&grSi03
+%7?+5Fq)7NXW2s!+,jhfF8j1iZ!U)%p"lCN#m$D_C/mF,EYAU9S=F6VRp4h)<A["jpTE#*37U=+ALOq%/TY0m^l-0=[r-!rRp8@&s
+%el0os>%0\&\bo=2q7>%4gF"-C7XWZ\@W''1]soaUfW'UI[$TR\>B'.6$o)MJMt@GCCC11XnKY6QC=d4*7DGRm8cm`5[OOP;$<*(T
+%kWrc_R'Wa!G@MXMN1$8(N?X2fDV)#XS&DObI]FXl=>Kepem&FaYqs9&g>GBY,us"#O<.3cl<6Vq*hC-XpL(WPlb1/!4f_:525hQV
+%GlB/bM_AK\Q]o,WCt[Z#F!#sRMN_:MXRC`<CElWhE2is7R'9VShZ\@!?IAq#*Jr5An;eI_>\:1fL8$,QYK&T,>Y]gX=?q.[XM?Cj
+%]0TV:?P3qtn/,Sj8&5P-kd8p)IB/hQ#\Yr5iAIe)=UHO0d&fM0Vk>@cfm;^q+MEMP8P@l/2QohPSEk/b<Gf9Wouqln=k*5O'Q;-j
+%\6F8rCJ".9aP7rUp6E4ClKu#t"B26+ic6*UQ-X<.8j7q\XfLNhp"+*Og,e1AG]*oX`M3pPYjKB\/4QlnooWm[*hAM,(sK<jrO7i[
+%D/,MWdJ81pQS9sHbP)g]^L;+u)VODXcW*7\&,V5MNa*Arp'-6Yc>^O*l=g7B;[s'OgV7aMQT-1n/A$h^0apmEN?od=2eMqsT#nf.
+%GG:`*\6o1?&b_g^,ZaE1]Jgm@cermaiWYJhX;#=%s-uYR<Fl37.2/6+"-$=,@%J6&LYXdZL/]>QBs*$8Fal>*IV=83KP\E^]Nn`J
+%Y05n(g=cR\A1)kim"PDeFrRk+gXgeb?BT;Qg-1(YNXr:Em[$-!P,)%[e],++oY9RTbkA[J0-YL3&8L;0*n^^YJ5MeTio=/oIt*:4
+%^TYr(Ag7S2s'5Qb77lmLp7a$QM\@3mIK&1(I5n9o](]fHZHh_0]u[*l;F`>NcuT$)/IQW59uUM4<m>\AD$80`4mKP5Xpi?5_(b*P
+%Z#`5,PF\M)6J"C'ZPUnU[''YOEK^NWig?9<=lCklr9mol!$5pTQ)#U0]'T7i27%TakrhF;IUIeU0u"MV'Ld9OX(f43"0-q7ZJESS
+%*c[.=2Y,VY%UGHCnVl3M0ig.U,KXP"+XKgW;Vllg@$[lDi6F7HV4DGm4lSs6;L7sNY?]HV5%:d*n*CJlr)&h^m/7q#%S7;Tm"&Yq
+%:#YVlC(ku_rV_8'<YKkKZ2n@$l+%_COF5u9lJ!@p*3Os+s5!#@nD5iHpe/4cro">Rl28<FXY"6q,Wi.q*Qs(%.D)`N),q.&ZB4V*
+%g2>#]$sjg!>1Z%UcWa!4,klsX(V5D!7/k<QqY]g91B!PhTe4`CP6l97$1c^Jq*4m;jh^j:1f+ZSmD'lpnkB#`aaG[r'Xk$j(jT[5
+%p>KdX0$j.Wdc]nMefWEO6KL\4)[e7XotQYT[nHn.JR"da]er=uR87:7M*h#%F*V#"-q&H.!cjk<%Z$TSd8;13Ekb=,m6qIS"+r`o
+%[)@U";(ZiBOh2`1DgT4d>YB\f6D?3!`TZT2PaG\HD2Yj9kbZ@IY&kUTa&]@4-b8$']:q9nU`JPB6Tk=)V4>0H`u]3*Ks4p!@&*ol
+%D9)\sp!&@/_Bg-B?h?_Sgj1gkDsJd(K'T`33?)?m%/hJW^84XifgYb:Qf/W_rCWn!G8L,a*kSQc$/9=2*U>h?VSFd+qNsChkM4(t
+%Xp$Ni790#IY8<bt1Jl);Fl#tkT$_TJUekE/!g-GM=?BOHf2F[les:>HSHZi)X\Xf`*`;FE\m:g@AB>DF0Cuad`g%Rs0$IuH-nR#S
+%^p'7rXhFGMPC.^Vg?*MZJS/aq#6BVIU0'iDQ1Bh![Gl!'6J@Hgr$!!&pM,0gFC+GLm'quan]2(LAVG&XI3Kub6R/u71C5!<lu?Vg
+%KlUL&c#39P'2.>p:"1\HWEHHlVAS*.A2,(uOe^\?AhR6?pia0H6nk+(kGHTF_K*#C+PS)M>gG\l+Ioue&V03m(ebCQ+-df`Np=`8
+%U5k*U"fgK\"S[\H)TeA$CB%QAE:4Lu,cF=[D8nL+F0Z,h`r[oW__c_gAlWL.`9)e]fqe$n>cYt"q>,$OVb`d@o<b+e`hLe;ZdO4(
+%BApbo9oim+ha.SPO=E,R,cG2QPU/$OY``H84#cshj-gGtdZ8nD=;lEZa@5#X6\>*rn_J37.UN""7+UARC8,R`!)'>7I7XWi6CEFr
+%S_X^WBnoUAY:e$,@B7uP8g#.L,+$,+F?/7J`s@l!cu3bHNkDN,BsNT,_pX+#'ZU+>>VZ)mru]>BVuCDZKb!M_+ui#s`ab.a;&cNn
+%9t5,B-h$@Z/%rjh84'F];a*Z>'?;aH9D?$nkX/?HP@oE[njGr,Q/Y5`lp61dMV5eCLBC3:>X4%^)/u5/E=j]YfoeKFbcV`0m<Z]g
+%9B#t/)/#-t*0%'LIj_d=F^4.g9jR0X-\QQC^c-Y+D*?kWj=oLbZP5)(3,X#p@r%YF)bGmh+(E&'2Cu1mbo!f^fHJToNPnOR%`?l@
+%KNP4G)W&@\\:pp?QVKj?[U3Ir(F(@!;("BLVn7]>WN46r^@(#;/Kb@F3BqXDR\+>O45@kg"\QH!^:aU@^bt,LFCjSbd:n%N[oNCr
+%`%fU2SMgq2qmi=+.h1:></AlraYqV'X2o4-r8uh#e6EjDe,n(%QM>ITmXFeG.p/nEVCDUuP(6O##<70BA3Zt@fsh1TO&pZ-N$gK7
+%3bQJDbt(<13f3Mo2(U-fS'>PMggXGu_g\s5`\us$R_u>i^QgKc8O]mN8Dgc@IYOP$?10?/VEL??Gp-(3$7\Ho,#Y`kGl3lQC45Cj
+%B5=B64Z/'CXj]8p80+hPX=Jmh0-*/DIB.F$S[#KH,(_="lEDOU*k[XWhJEQ:X1gaHMhU7:3Nc9[.9G1d_Ue-,jr*T+4l4b4)HP!H
+%QBET,a?4ot>;WI3ZRW)#6D7O1[t7A4N&&/.>o(\kE3Gi$>h.%:iC<?L=ZFD>gW7BgJQ2%]/-b-XUuJ*XReNEnS0`AfF*nAq@-4U)
+%=(@$WY>!Bn"^SZE9HJN//(8*KQ`^fh.Y^@+ZO8m*^I2ZdKfjKb*e&;qp:S=Zmb=4?egVRPkfE;fDC%FP9qZf,rj&*n+(UEPHgI-k
+%\]a+<]X4"D]NK_4>dR!oh9-hQ[p$kYkF=j#Gb$NA-CI)PMq<3^AAhqnO0kd!&q\Z^E=q>SN\u.2D`$U!WZbd/QE3]^C/r6aSUQ)D
+%fb\PG8oD9;E;Kr@EgZ5=\0TK&Wn3"=06Lhq=HcuOE\i>IXNmJ-MsRce-=]Mm>Lq1^-U%.^L24E91BBu7kbl52rp[g&YO?Z144ZKV
+%4RcjFnnpfN'[Q'tR:qRpdjs+b0Ib`pe4Mt<Pkq<3%mIA/g?a.C1oFN#3]?Y*B2FaF]=;GPe=s.GO.B*ni9FE6O8-hi"E4U4h%.1&
+%^&u8PC0VONT8pK_'jMMBR!'!,37m(Nfjg*ajE\Gp6-=<42hE-sG"H13R,;gdr5)#KAb@:"He9/Hg[n9k$,m>"V_^-s_rNid,q,._
+%"suVZ3\5NdfnCCfJoe#Kjo>_u2eK"4?/aldN2j=@&atPi(-S%@a_e&^gQhTOj3GqX,!X<Gqo.S+"cVH^no>,qFomPS_]#cDH]Qt%
+%Id,])NPtFLq?K6T0rYC'`A.u=`7Ft&S?*P:m*'K7ZsQh8/"3Q\3K:-a=ui!qC+DO29CW8Hffjo_,!ORRNOrZBc(]Rsdm,Q1PJn,H
+%>V51B-ji&rEWRjj2[1S&L'3]U<hs0YK"Y58/2FBh8$`jJR?]%m[>SH/[W7WC*G6BA,m(DeIqd9SGP`k%+u(=:]&u`*D5P'ZjCV:M
+%T5!J![*`%/o1TbAqGbHm1dbj/S's&WR_ccP*]YVBjim-J+deHGM7C+]dLW!>+*74=CVqt"/irbVUum!@a?KiYAi=q0m/"m2cn^;*
+%m'rF;NL(D-/BG3fT=l7%TFdt=gmU4H!SfoM#aFl2Y-c'hN3Xcb=[n=(a(,;^:e_5QZA$l4WOEU"Pum%UTYQ^S2XXi(dbN^Ao)7"1
+%/hAi%KL76T=GI?qP/[3p!)MGo&"T[k0[j"sb'rWQIJiKY@6"<#Wh.A^<&]QFaiod^P#`?bh_u325]5mSS40]k!&![JMu<=2FtXXE
+%NnSF'+A;N*P7!JL"[.@i,/Y,)lYH.,/p7i,7*#^96*4LJ/b:%c;cTKHYkjM-=!tg3#$B=Y,8/e9o)GU/QY9.!XV4kOO'>f@`<*OX
+%g@jLZT`e!cjQ393L2IfD$F]=:B)_\[mX@2%QZQ!EYA6d^;l,T=]"qp*,[cXn^H"D3SB`XZI)iOq_?,)jW[\Ygl9FY0g=6/jG1N6g
+%;kp3KmIG!6"c1[tf,J#0G:M4[-C<.PkRa&^E;(D0[*#PFXscPtrK':(al8_SM<\ml%e"P:.?jJ/*s.2Y3Yb_lEko9_>EdmI%[Q(H
+%]m.D18'AOl(1'p>6?'U2a#kk&f&u`,D-NtO]5j;apio46[i5r)\Fsmgl'%B2OKhG0"4P\@Lp]&7<aTWY3U07jO8XmM+I?n7RbGAe
+%OZVsN$]J3(F9HLGpE2n/IT7r&@FVXN#ct$l['."d1C2P5&6IRnCl?Y/cu&RacK8O//7rc__t%s<b*6!Ag4$<2dL\^Y[pVb%@7$N/
+%gK^>@fa-;n.=u-EK"_Cnq\dZ\PY(sR%[keccs;?]HFopi*r?]77*N*h-sF^8'iR#<\:A#^1e"!.8g4[\&map5JO<]V%aGK[ZZK9[
+%`piJ5?ke$bbtP3GMm]_((7S)_"a2,abbGpL808n>eJr(2c^=Jd%/12%Rua5hp-rGP?QA<2#hfnNG5U()>-prU"MgTok/XSeWA<[L
+%]an`s?sPS4GCG6pN3>M#_Z:nmBLQmm(4!I2%UhYfOV4WGpXffg_8^ik>Urp2]8@!QdSBsu-ph["Rtd@UR-c:VS%7BXEq_b!mdj4,
+%,m\D%ne_*iR$F#%F*XRN:Xp=R#7fjo4`n/2#sH/thF/l(-j'W!NJ4,[bgEIDK%;)XG\!2*frSqKB'"["X/T=)TUj=ON*I*+2Lsdl
+%Mp#q>5baj948Rt8E9q/7mZ%0e*_VqKC*Y%M5bBgQMSjW\n@Yo,ej\Ve--W:CD#%L\bRO+a6sXjSLUj!HV=&F?Dk'VI=F"3;95A8V
+%nCCIuga2p(d][ta:s%Y%*4.M"KW@b*Eg;Jhdj6Ot\dXaF(XEIHYYP].cXE)#3HrJTb`fD%Rj6F+ER:_c#gWp[HtXiaIS+YnK!#eo
+%<RK4EQo<>'I#R!qRU:,_e:XM%fCT><`l/ts1pe"(dEmpOlZ)9j+#>jOCMIH8o@i%6oo!d5WGICTE71OG:c'b]qmOsAR&D@!%MIBQ
+%>2)&`0]J87Ofm4DEr/#8UD:<%He>bTY]sY'R/9s<&nJ5>JG$*+4-@`n7.Q+!Ht3S6-p/9YfGf0jFfA.Q\;4D+_5UD13eKb@46l[*
+%V&q''.6*O`_Yu)s5QLe2V-S"ZER/8[6+CRdo2[)H+?fY4;/`YA!jFMM_R#.,8Db26$,R/e!YCUBMe$0Z<6):1qmm<M=[VE>e=c1d
+%,onUb'Xd)AqZ'RoGh#f6!mPqsZ?R"e@M.K':V/mf#!Q`XZcR8u:l]o8CsIOa0gYh>]^/G2W(Ab$Qp@pq<1^l)kTcf0(O+7YM7O7q
+%9`T+/':W]sW:^X)\U!H--$P([K*:7_"Od>\q(NH;P0>6L_>[Q%bkfisMR1iO2[%"<"#sTRd@am8$JtkA^GE<7M&9Z<:7I_^n7&:r
+%lY6/seR&MK.02j0WBfaVq$j]j=%bFC^9*$4Pb7d]j>Var6s0<.?u\g]K&-=cR]7VFB'frT4/QA[g48sSd%fO)-:f*$>p=ZtB0jFK
+%J9<?Y>eQPF2+7lH,G1F1,tJQZ[V+!RUAhu^]25%:(aE\u3Ps>!A?Ip?dI!O6!YNp`KIV6GHYhR7B(-f\1/5`)[8ZDCioXNk]5eOh
+%BW7_M9(Ln09+ektp:e&d;XCUthO,1^5D=T%/T'4KQco7\7jh%IHW=.,8\;d;C"kO=1(ro23B22F)B\\iW1?0JLC$u[WOW0-9cIO_
+%,J3`Q,HXH`-X>b-dO%(M]RD;$ZuEkX]+^^+%2Y5c3/?lSl$R307SjAn]5^O#EY#uqQT6j*>BgWe*Xpb-I*c6:l16]9N6EhiB5K_n
+%S`OWHkoW'F+VL_A^Eo"?/VU6;DoH*UrO6qX/iXBIU@liJ=agYJJtd$cY6(#Xek4I]ABe6d*JqkrhYbmkbZ'M:/kuW&FP@pWHU="j
+%<K1'M:E40=G"K7Cd]rM/Z-rEU;(c>BN/^PP52i4`&Qk`WqfQnYkLJ3BX[.]GC=)8J>u/W,/djMqA48X`9Zk":S^%*I7XG.YAqpAK
+%Ou9Qg,6bsq4^@kNQA\(2RS%N_A"*mY;H5A'a3\DVD=).+2Gn%kOtYTOBc^EeRILL7.o5+WnqtX*/89>0;9Dl1RVDVgFoB*4jguJ9
+%pTfE<dD?&<Hrr\sie1[&fjfT0g>mP7ZQrR?hi!Pn]#p?;+n2R-;&;s20Ntn#pO.I;;kh?DI%n>i9F6H,^n9qWM%[4$8YfqrWO$g6
+%0QMaPlZU"BB;>akg3HSK8:cmef<-_C')_&pqR?B+W(nDG"JSW^;bp6G3+ot1"GtBWGeHd]@r;iV8F>WtSSO6K.II4OX/lD9ZAKhS
+%<m`1Rd:g-b\;LIt?C.Wr[pkDV4_EfPI+gV1B7@/7q)&c+?mViBMd&7GMiL1tAuq"q0f!^1<ku4"';66DXK"i]E2@&6</&94]1h(X
+%Zk^X887YjRDVAjEO3nrkRX)cabf!I3No6[LB]i^EpV:Fr%IPicM2A_<j]Y:7k0r4DnM2L.@<$8gkt5bm%Dd:M"HpuqC[R@j0Z'*'
+%ESr)g[T\r3+]uZAD.u3K@GSi.X2Gn".Z1OT(`.]id)fUIqr;P.(hYP7l2jY=?L9+kk``$mR'ahZ5'5?:T^GuCl,gYEKP#2Y':=)P
+%'"c_YI:cqa`''D7Q4,ZEZ%gTT1b;^62DAQ`gVj1Zo#[Ypn1d\GA72,#oDj=C+[O4'\]aVt>CL4sbFQZR-tEo'AQ&*HdJKp0iH`*=
+%f6B<m_K_qpH9d9FVWJp!H;*Ub?qg'^8m`@5lOc&)\.a:[l$O.1Sa(S_hb4nf0Pm+lCGcFV#+aV@[F>tBL/>Ve5m5sIGtbo>1U-r)
+%S.6lZ&]D9l%7#LuZ&C&-]d0f)a=r37OIR5#N>9n>#PVHHjl$0>6nk^XO6#qp5!NBOV$LS"B%X%)';G95-"MO6hqLGb-6QPuV=F7+
+%&6.?.Shsl:rde?S:o]hsMEQm^$+e6iXEcqsW?)^8Jt1aqjY9m%l1jgk^,?e_pB#[R</@3(@DE!ZXPB>TWZ-F4fFoYG9miE!Lrn/*
+%nEG?[JCUAW(HEgU1-,IY\#e-u9Up%%G)313V/Ye^Sp-crJm$Gm!s3:joO(.WV2q$eZ>NB<`+WORN\#ZE.Zo1_Y$R147NWD<7r[nm
+%HEE-J)XEs)@2OQD*M]MC;qdm5BDViXR^m@O9>jRdHXGcfi2R85?2Kl9++f?Z7p$G[aSKHio&%H$M+3:ZM+=0G)Q.ib?26.8C$j:D
+%OA?AC.re,W:pu+V(!k,,(_s.hWN%tFG5g-TIg/.b:`6=l"Y)kBaY+ssl9Bs-ppns\+6(mJ(O2=6.N'!+]:B>ELRX.i?D'pAGIl",
+%Ol]u/Pru>2>-D^H?Or':'f>5j#8HPU`GY?mK,UudE*_/<IQqRR_^(npS-X!K`^(OCd-Dl1q2dt@UCJ?r1^R%qk]*`Uo%[b@pgKSW
+%[rW5Q'm'Me/csfAr=X_Pna1&>`_$B_e;QR?=r9QI@%9sFSAA)0e/]\L4I3eXYbEq+f)8iI.ui*LqZI2(QAU4I[:bo<M[KrYHmi*$
+%RIM,5BD-c-,VX+0WIKMl+t0OoF+sG2RqQQ.U"u#/+e<\FJnO9GjuN5YM%g_=V:[5F^9A\q',\*DBHuI$O'YH<&amp)89_L!H/V.b
+%jqL<XG6Z8cd*VLJLBrr.(oZcVj%4CW`]&\E?G,Q'0IGRpoZjU-\jSuH2c^JpTq"NrHf"GdoRSMV3[aBm7sdP+=,/iRZpp([p-GIe
+%KNGiEM+Wr08G0QsTp7uQ@q-l(=(?Le_a6$X886$9QZXLh\OS76>J:)UpA#r3%9M^nec/sU/V3r$j([kU??^/tA)Vc._n9j$@qNiW
+%AfJ_Qg&L[!eS$5]n@We60p7@'H&>'Abr\O/k#g_<Z;)R0@'oL=0\T&dRPB_nLN@'!Yd1`PhWm4jP*C=)fo/gll?ClL_4Wf2o"$Ym
+%C%I%L\31J'DGBl57\Z2L&`&:uc^*'M=]r6je=$i?4Q8,BQ-6[DFJG-<p,.%>ka@S?>=krXK_J&RVJT?,9V`9O^*PgTR[*D/T)GLe
+%S]`KNRj(Z,BeWJAh./D6#BgTZ(ja/XrRT7]OSVtV_>lpBT'M1FJ=1E.Q*(Vu6B#]BC8a/$7!Zm^nbgmCe]KYN^$8AEqt]O/[WSfF
+%MToAse+-O?htD"'*kl1V1"TEGPh;9@Hdk19+ZOAo`kagoX^&?EHpMer?S0IKoShBo)3rH<;O8oL]dLib/pGr6bU%eiXNhJY4i%]S
+%C+I+sS6g-.B.C/VcYP,Vd0#K+'+[XEasG1<[94dlpe'.aSq#91S9SWss!HPh&`8p.rN:53S[GdK,8J]7K:'0*.Sq<1\$dL2I[HI+
+%D;F"m&aTpckMjK>6EKVsGhG[@]D@;ED]ah&_O/e.h07e2C#q8UkVBDIf6=&:@^s8qPWdX\D>FK1OiJT%9g\`8,52qa%OXN,m/uUV
+%[dl4J^J]t>Jf"3Om[?MQ)&dM70[`3G1b!)PEn#C-W<"8lMH"9!>2aMmY^S63Tk,1]A[EQ`WhPJ1$S+,f)"+!Qg_VZO>hrXBRoSVt
+%$.!uI/&BRY*XktMf=0@Z[3)q"HArV]&,ts>X?,aOp[RWPRun_2"$/'3@m4K!V&7`7;%P#Ho4'Q`!7'k.Fmm"kSJWop/.9E?r:no8
+%J?W]i^_)pAl/"D<VcLBX$+qn.>p^u.,j10B&m&,;'dSM<8OoO=lZ0KbF(1`kb`+LnFM0(hd5iWlT7HHeN\?TK=q.9kXJ)<&LJDD+
+%T)^0B&N8#qV#t0s.e$m";%CF1OQF^"f1^trjanRN[--tlB(G?#l;.aZ.-2pmjC^cgaW^'7('/1M53mo@?n1$l;\deO+Ge1'<*4f3
+%5Q(^gYD1V_l&B;s9IlGR3".#I9+<)8Ot?;k6?%h3jZ^kh9Hn/KB%^f,;:g`P$Q,(3,_A@,#N#.bjVXj9h'jbJDO)B1^W^CD1^Lso
+%J(!+*Cs_EUD!ZmbRH-G-p_:!DDt1baG3@ZOj&I*(qOmuje-q*T.RD@d\DA>jPK.>NZY(@u"GOBY2OJ,2Zu6*"j]Sh0_?cAY"0j`@
+%TlH&rW:k5ToP2k5k!&dM?K=SAYRi>i0I!%cV)%B?O&98#ZYg_6HJ9Co*dn*nileM(pT=Magl4`VVqdgKb.-Rm8elf&K0du*+u444
+%=B+_P%9Re%E:jAd*`9TYl.HD5&uhPgS_,_,+"O)0'_@oK5/T-(@fFB3f8SZV=Ob32GDR[t75_.3&JP=A;S9^I:X\(C<XU%V<o$k6
+%W'U]#j?lW9+ne7$XJM6+&+$pLWke[]NJ>[c)0F3h&D*(RAM.=/_Q(/RkN@\p92uco),l%t4s`pm_bV7nWO?*-,fOo?DW3(E\[0_H
+%$4FrMpsj%1kZQAkM]FG0"lDnX@Gj^:Ef&<KfN1(V?TAkolXSJC]Q^SLWDUFbe.F?bk(c-!go=]4e-LDd/IA]VT(Ro.26">WObPDk
+%I(pK'gdudVio(sd[j3NAXB.?\]&&m+hp)r->e+L%].t9>ocUl_^&LsO^@0hc*!fPmqU\A`8*aXkbmSY@mEEP)X&SFfQI/WaCOY^.
+%=2m=q*.Q]'LbDA%0X[Ve(9;7`G>(6hcO0_KbC6p4%WfR0?PF1FVYph\fI-KLN?/lAl4PH<F%/i]Zp87"48,5am?puS\;)?o7'P7-
+%2pmZQo25[7m`9#..,u>h[Nfmpq@_k;&RhM"I:Y'SPRs;@@%ho,eXtDo>%$0D<nsk<No+8omE)[I9']\(OQ>3P/(iA%"1[TmVk;l2
+%0;X6tZ2mY`C<)O\S1TR.j2k?/"piIeTl_S*WWpt'&D&gd,X%s%P%[eFfHK>ME9=DsA8G.0!sj2R6aIFF`<[,2Phoi\n*HMSo:e1t
+%BKUGi\&$`,@5VE0OI8t,@*</;5Sd/LcB[ZDGNAMGj9pT-T0tei;UbW)V>u'[c8WSIj_d:`A$+OQ2EOZO9?4*[2t"ubeN\#Y+b+%c
+%4bC"%GWX."PLia#,#Cu'L-%Q1\\+?-e6`ES@jO1idX3q;DoHC`$2&;;O*`gPSO*mZW<a-<-u5s@GH4<WEaHYe%e]%8B^&lm,^[BF
+%o5<4894oV)9iR[PV;XhfJ9[$2=$B4)`RLpG<=c%63<m=k0a#[-;Y60rpeConlGjb=PB<SDi91S0C:9N@6*ZS$;[t1`[k-N$Y&LG:
+%U5:WuICQK3V4QC>cb&W5C-'5S5A#DQl9gih4mciN5C>RXQ&?H8pmc`&"!=X,K@Zuho-IHhM_aq32bPb';R>GG>M[hQo`LZtGH)bQ
+%+j9p$rY04ph9r7&W(W:GcIH<l^'Op4;F!*j+M&#uRA;5[m9_o_9?V"l<[hLZZ;Np1H<me*P9Tn$ZmgbfdIPq:(][=?T_\/+^EaE0
+%W(C=7(e@o6$@d%uc/PmnJ\5!ibf98K.h)IqRW%WdN>7]qV"<B>=e\6>_@H]8[p7n:j%W_BX.^L07"]_iFd2+7>Ge]QP7q0Sr#fp,
+%%)T/Z<E7PD2_`cM;!hXeh=F-A[81YHYANHIlWn\9/!'P9,+)niI+KH0_B6,0MtWD$>$eY\]GibVLrh/qIKM.CYSWW#Z/0Q-XU-2p
+%9=-Kf0ijt1Wqh]'?oui/>EmZF%H0kI9Q+s+3H@"`DY)"n6+Le7<CqSA2W-k_B1ZX3)R;Tbf[]ET+'_22$JJ'lfGfEoT0<?q*d=%n
+%%\g0O(\tP0kDLKcFC^U+S>f)XKZcoA7&WK(pO5>[qiIG-YZ5!uHHbNDY*u;1BI/`+Z"dFKfLTXa4Z4+5i(:#OB%Ot1(H$iB.;r+G
+%oNE==S&!t\#29[_Up9YD6L]et:=!]bKh!g]_$DPI3iT*_DMip!jbsG8KMkdjI1+]f!E+RV!E$iJ_=5"md$#_JM<h\4@K&g)9'fd<
+%+BnH6flkS_!ZE,US=_g":XM5I57)qtbb.sS+#d=m0\c/b1KfBXs'B#gi44Q/f"@Eh`nC+UmP19&`@"L<(7-FYPlVLOhk^$93'dl2
+%<D1?9h_qGoiA8!e>mIr04L\P#TB$Bfqdj(lU1Ul1h1I35Ya/"2o-c0k@ncNQ.E:SDY`a8_XEnmXkrp-1Q9AOrQ?Zs5h2T(2Q?u&%
+%ii<gXqJ)1baj?deLLu+@&)gC'+aW78:PbZEWO/CI6Jt9Y17"<dYW,"U#tNDUYI_WY#ShsEMAtOB[fDVOK.$-=DusT.[`VCca]95G
+%>cHf,TLk.iQcKu4Z*7L/iG<B+7IEp-C(bc,.Y1)&WG^S`if$CM.ICQ#R5/,sKQ7n*#Uu,O!W<m*/_R,An90rN^rl7daY&`DITXM^
+%)))T?-gm5Yf(ug\UmNrV#F@kkK"STeRrWj`N;@LY4n$&>qK]@h1i1j`o6Ziur_Uj'k!Btf!h3/KmI5HpaAS7YP:@(68P-YJJ.d#q
+%E7WbR:?>Dr_J1M&YCpifF1ELX,tD6]4W>cl/C3^r4umHqY.tB&^Y'`<Htn0Y2#<NAJup4c]i[[_+]"s;Cur>nq5YFl[@[>!=X>KL
+%q[pY]V*[!HH%<rAY)p=OZqlE)U3]R)Vqa%[rOKQ7I5:/DqPr&#(gt3_Ou<!GShO2(aY:-TMY7rJ/IS@;QDaJ>"u+C[cg-`<c#?Z"
+%msmJ@+hPO$cT\=Zi#"pFG-tpH4HFmK2h+.;'<OB(T3\sY4B8i0EEA_Wp]97QA3"D=Xt-c^EV&?t4M/k#&U\T)bSZ7)=l/Ki<+FUV
+%PJ:Z%Eu'*IWip(^=(/Jkj\PJf6?MX_`Wt<r5AXJQ"QUu,jlWm*/"OMB'&oi(PNRG;I8LqUEgi\nOaUC=B)R//M_uC@)d+#<i,GZ$
+%Pf"2!7m<GNg!qL`dQN.gD>,ZZ(gfqmkMY4n@U5$ITO(aD9t0/3mO^/]_-Fk[fQ"X32bBbk^[ZGJ<*/PWQbC(3#-Dq8F^#S8X))l^
+%cpt>7P5#"UCNl`e>8%"JOW)Re&nVB@qU_MF8(_D4+E%VmD_UY1r))9UrhP?DKU9AA;C6_B.6I#lG6,=0KV52,eGobE#6QOR(t?/V
+%aq4'0VPtThgUT;MViN]-"erS.^p=P4D9$T"qhfS[eN6KT.i&K.9mp9Q1.7s2^ZSd'L^/BAXEE^(hNKjVmV;2=OWq<LFn_]_WsMV-
+%,gs2^<1<22f[Jd?MNpD\VjAo@^n64$^4J@1n`KFcXE@rhq&2EZ_ct)lZ9t^;h3+_^GXf:?6CiOO!:!/7)5dDTaX2L_0E*d2X61e`
+%%](M_<QD^_XO821J#gq`%GNlNgBE2?7>0hufsE"l:`5H!q4o?NZ_\ViNbT\"53(Na<Z6:QI?_q]KkRDh,Qt,Ar,!9"foP%cSeqL9
+%+&L.0hZsQ[D?Ku&/EMs!RQ%"<DF;*#,LO1gpD\s/g3->;Y9d&6VLr*C6(6h%55Fto1%%g^X4g4uj=UUh.P]kjReFDjIPo+.,1Y8X
+%XX0C67Y,>A0s`5V]F\_ioMTH/@cdEbI77)hBum&?K6/Acl=$FZ>K?G;QGYkF:A"'?"<!0Mao^rmDa)*7?895rO1Y#Hd])=,=DXmj
+%=VaA+L7PKV7YXK,2@@]k1M+,19B2k<pt?Vqoe*rN1$89&D:FPB!NWk8fX"dIrC(.b=&6-YK#/h"<@Y]D,tK/R-7Crg(-j@KX$7AV
+%0)co_.Ek`k3%`;qTl&0S/bG>kQ^(nef)JMTi(:&I4@O"8iF?WC"1Y<kZ4;eS7sKAl>`oO&P-GA,>#uR-_ZN0L`B/2-7,H?77Qn9`
+%poNoELY[JV^pT5pIC%=UW8$%nM2aekp0sh2>7>I%qf+0UH^DNsdDIDgVI@M!@g()$UPMrF^Fkqljh&'D"W526N"MT@AiB6n7_W%N
+%'hfjNU67>Hr>L!J)S*@E$ol^$kspGHL7H6>)..as`F*EJ0PC*^I/S=AhZEu+j/'L(iU)6n$SjU#/lq"n(E`cqoP0uB>XBcY/Hr&9
+%G4SYk+0gKoU0Gi#ESp?%'&;`#*ar,kfO6Oee%,_qDU.Zo6G"l1:A,hZfF5tfQ^DA#+8-k\G7:MU^EJ4k4"[n#j>=*r5?70BZW3u/
+%XB4[df`D^hVX!/SKU),0jCH2iV#XGs^Z2.7O)@+Q_9=G$Sn$VToWf\iJuLVMG<L1.LJI2@m:e*"?A<e0V[W^1$.J2`m-KOWNOi&-
+%@pXG;3-*j:^tgq2[k4ci(3U"UbU*''A:.Gek2c\`&o573>!"aqdjh'tg;4T*JOCIN]*.ElE+d@$LtZr0d/fA)W,DFJg<-uV$^*cS
+%ZKYmG7[7(iHek".+)sr:`P*"5bD6&a1AD3Gj<'6SD4RODp\PQZ/UC[d^1U9jih0Q2ZBAf*0&!tlRH$p2%-m.r\!94N>G_%q(>mR4
+%>PBef:EFk&\tX5dc<djCK6*iNi.UPMj+"0Q2cSD9[)dSjZQcBHm5'jp%*mGGV,pfFQ7?!b!gh\$D`qpO$iDo6>1oPTUiAA=XJ6[?
+%p9@$?j+Off,*K5T,nn'',9[$a`BWr7/oQU,EdUV[r]]$TIQ3N-.(Y4Fl(!nlQB1-QM9`Ni3Cd2jZV<-9_',q\SJ>#gAfcGk2^Nb1
+%&XN"rKB`aNdb=)0DtsZhqtUY8>&#BjI@V=#p-1rap`?:F>"#t3c!3)Mp$qG!fRC)6pJnd2;_*F7O5)G/cITr*VL6OX3eAZG5#_,&
+%KV*+g@LHuXEqPX#L0"*J&i1Rf=4L(D#B5fh*P,VXhEcc\Ds>ElP6eY$eQ/"j/0;u5$ijEiE&6N0!$hZ?5Sho;(N?-!YdWlr-P3*D
+%b2.qTG%$YRe0cZON)a13[]c=Q,;i:@YCll)B.[bL:gP6L0ZM8mc$.(N6rSQ?WfVP:,uCoF8?tjnSCQ4NDh7/8TI9$>h/cMf!l\)r
+%+cqi]5th>lO;Vo(muG_&WrV3o.lCHC_f64.?Z4Nq^H@H*Om(6mC1DXc`'M+M<5FX?Wh7dY>1,Qn?#]R*/&PWFT,@"S&!c,d*8IZN
+%Za2R\95PiX([#$(WLZ>4'TOcTXXdu__Co*k>"^ak**7LArCHhcTKr_H9uQ&i_Or%p_[/,`G"CqmRlsIp$:M:8QlWg?MV])#M!'os
+%+3o"4_(EN%<En'54j#_KrKP^SDr"]])"oPS6_4rigDV&^G$i4lAeb4jDA'(/%C:CPg4`G)NLuIeYC.F[?"].TOK*"cmr,e*<;)pB
+%h*1NjL5e\D[OadSERSo;$#;m->*1l%fKN9"KP69D[6LOARD$Ft2iN=UA3]^L@,4Cpf&Y]>7NO'AF14tmd'p$D3Elh2L=0A4F1HMC
+%+cXf+n*fCYZ5+f(X'0@H^D39>T!lM8T6Qs/VSl2,#OWaaA5Bc_\4i@'58BcNl+cK?.lF1uQ=_5l.JpJ_FP:_QV`/473AF#+>S;RR
+%lmfob5s1M-(/#X87D=)uVI:dTcYOO+9+ecj8\SbY#u[O$p1`,rfG0L'WsauRR8QQo(=O]uP'A6Ul&tFsLGTs?99'rJjQ_3Zb>^6V
+%0WG--(,Sg9X!8GYRD:Qt,SU)<.;!iE(XRlHjfUDC-f_RQ_QJ+<l1.;;(X"]lZ)JdH>@VD>2(>M0K^N;fpN/7r6j%Ad3Z,%+.p:7r
+%(8=<JF0pc68sEY:DC0Hf5.+.e7]9,!j:N/[+DY;h9%LIPkH6YtTNS"MAk@8]603tO)dNWb/D=rs/>dHQ."dIL)jAg_`;;HYLGSjM
+%jWcHGU-%Qg9_^Ng0I%BoC9:C@fO/l]*:nd$fW6].P5SAR/:!O`VB-VL<c9qe`Cq(9bJ5&4AA@cs)9$4!CS[EDE&1V?`%_4rST5kb
+%*aqe*=7R0EA"H.Z265LR"j/Y\E0%QY(FlMYfg?=<@o>W`[M9$(2S5f=fnY3QArGjt@SnlLT9M-m]>1ch:S^&M_$BfO*:+C;V$'c>
+%p3bP]7B-HG+%2GrdsbKnPLsXEja)L]C@Pj\BTLgW5F0NB#]&D,$#n.LW[t8BBU2_^6T*dE[-T<D7:%C2qc]:\.TIe"T6s<aOgN.+
+%p)(9rnQBmJ1U^0I.;Qr\H4'NHkE@r`pp$S:O;Ie^dDL<!SZ_2L=9`^'^W+E)&!;KaXf2EDV`I><bdL_gHmH)HM-!#:D32NCQ&4;&
+%p0/Y9HB54`oYXc?[kY2_X!rGGQP[[\kua"S2'Nl.[&7OT8hf&,pUaf_Nt#@`JN0haB5Jg1*''g-4HY#>K/qsLG2.NeI97Hb6/bh<
+%XtYMJ4(WSt/b+7nacC:SnG/#h=*t=f1$h76U-u*;gdUW1Lq+iRjt<Goi8'_nm-kWO6GS2C$BVlh*mYSF3@Xf`U@$UtIeI`U2I!nn
+%gF_K+%bUcS+rQ7RPU)g/CMP"Vpc8.Ig+$-77X4$WflHLLZkkG\E^+H9"'*cr)UoG#!X&D+6T1=47H=*e7SeOi7H5HTOdmd"SseU$
+%&X3ZF"Cp+s?JO>ajtLjiWSX"FkAd12J=fc0A#/Y@K6GqX#Sq8$Loq+*M<*YpqZ)%15jX`>a.<a.@XNCGCta\-oE[cC^4`-4SuDRC
+%NtddtCeo^hc#Keo&QXf!qO^'b4eY_F\ZMj^LL3)ckUMm,R]gPE%U2frZ)M,IHb_JW&0kA@EGDm:/^[aU2#(i)E\1eC%h>L<USs)d
+%NZA<c5#9GV/FooF(k:YWpo^>QJnoE1,rc&Po[&W"<qk"Dk-g5P4OSAoT`%Z_ihn?<n07HQg?Ac52mgaoJ*_(o>DW9^DDGmAeas0M
+%`_Z2mpT^76Jr*0&Y(*afrU63os*1c,Nq:tQs4@;I?Tp^Sj,a65s8INIO#U2;o7+1HEN?H2jp#*A0.Wd%R`<YK%u"$TM/V;-V4/ZT
+%Hjf\YWu5dZJnAR`R$NW.3ZkEo97\JAj"i@e"F5'iaA74=:"TS*PLT`M*B\W2.NJWZdb[G"BdI*cS?i*5D=aMKh\g!WOWpq09;f_e
+%bRpb-.`0m]iWQj,qR;&*pVN<pg.O\1;aI@1,j$`_3$ut:TTj7*V_"?DZZsV1%O[#H\1'mq/icq>a$?DT\QY+NFT5J38H]67$VRI!
+%)63(;'f0)i_Bktp?:UHUcldQgaL<Ieg@"_0OY:Z^]%'l1PX2l8Wg4hs#b!=Z@FFhc!5eVfkr/tqVs9EfFFp_R^-l5&L;Dq`80"QF
+%6]Q?0OW@POZQ_=)Ms(,ijm[G+LtlBJd$>[h=qqW+@1hm!lSs8CNDeFK3j82\JkS'EDAk^O&SKX)b#J-@2XN>k_N"5&D9g63VB"OJ
+%Gm6?5mbp,j(cbnS-!:N9qj)8Qhnk]<#epAr_g'9mMS"MV_'=jU]!*/nDCn[4S/%*/(L-53"SondMG-)t!\6Ura)6Gp`\>2%=$KC_
+%H4)jNf2npPSsuFQfGZQ9kT,eDFfpLP.gE1bQspQ,H)>F/$`K__/V?b.`=(^[W@fA:X$>YC%SAo`[)r;<c5\;t78R-!o>VcAWC'a6
+%V5ndJYKs7%LV?)=>NnjBD::NdhmL1p!-_O!7buH/ek,hU.HioEs-i^4D\7'!AN0:-PmRW3,G-iNVU)EUC=8+NBbZt-=>a/,LrMP$
+%4e'J@U012<>IS))BRKB$bPu7M<]e`\OKe=RJVFDe1#*F$k3pOI-<!GDn8O/)T$F^4ldt1@.,\Ha!0NgpB1BkW,6N$7<0/<fj@]9f
+%bVT[-WpccAP#O*PLT1&%*@jB%kX>2>,<99&;<2Pd%._c4X\iO;0qVQeH"Ph&&iNeg[1Z<d;0%E>#g_k)g`5o,$&"FF8Lu2"T1:iR
+%C]dKa/\pj[>R6\mCjt\P9(kYT'1eq0g,'u9'4UtnfOWqUWN0c7X1GtZ.5=mOoR@2VM6J=>jG-F$6]m-Hk=SM+GnRQE@!=h&W/,FF
+%Mfh@tBd`k;<mB&CJr_\$CIN6kF^bYJdM@A^pe'B,"3l#Odt9,3+*o$Z+rFb"F2`U'$Ku4-gL@?0$`OC=o8'kNU]sdsqU2'Rp'UGm
+%Xc*k3KERs64G:8qNprH(YHkYZ;+dO$HG#b_V@II`R,1%",5+D!m)Wumm^8ub0J1opI'sD;;oH?Os'&0j%eH9Jhh=D<;\`9fG<a^;
+%&.b)JAs?uM;T(sjH;R3pmZOme>HAF<IK7KBrI1h+EN%6'%>^%(dWAZZF9J_BWbR^N'S8Zl4?:p.e63*'HQTGaQO?(@ggHB=G?10C
+%RQ]ENA'[6U5#_^5%WJ8V>I5nCpfmkTp5D&<.DN)Do;V!3*^_*8Vt3[pYt,/M,_4goTTfC(U,$d!1gS?Zn3jUVO]tLHEJ%ij4g,#X
+%oOa:0*H6J@#2S'_`%nO9<s7oqIKa[8/0Cs3`sS":FN'Wi:6F5OI.gLsM1hu)9\7'CbQ3UTO#e:*aF0\5++J@!Fi'7nQ[uj^`ni4m
+%^LM-LXs7B0rMcS]]Ss)cHC@R>4!>(NH+@`,iJe8h@HMD>N'SVdQ40)Y$9H4k!5S>=Q)UC=m%AcRSI=U^Asp]\Efb6G"$.k^=g!n,
+%H#\'^6S-+>?nR:fKo4kJ\_+T,&F8Z1;$E3^WC5Dpj\OS^KJ$Z4o%Gd@/TUB"nDeEsQhdOhdqfA67eK1\QRLk@[&f(*k;)QMm1qNp
+%2\_m9eU)pIk`R?G4G1JRmJF05I+bHC<B&ZjK<[:hHF*.#Y.+D#'LEAGH<3!a4%LBNqJs-)0Y7DC`tm!UYkKU"(TlA`&KUa*GY9q0
+%*.he6-qtJ"M\eba-+]f.a57kcVSgl;8_OtK(%c)9VMFXP3)%W'=9Bq!a<6OG<(?W;'u;["/*JdfCb^8Y)lZUH^YmY4N`>HO>o<15
+%^67C_<e(hh@>G3[9m6"nn?kI"a9?p:h8ikY?:jO1UN4M*4+aGdg"\Am*EF5n<'W6d01(9-'`@`q_lSa/N_Q5hXE^1X_BS%lFkQRB
+%5_Cb>he'UD1lk7]WA@dqB"$P7G0W^p*=J#j.qO>ANZZpJ+3o7,3Hh]W[j`WZXLMtsXjHC<pW>>+f0OJLS[6%jm>32s@<VjpGQl@$
+%UhF/+QmGmi/T,P7/dDhA(gTZk;/>6pZ)C(_RM#FQ>GT!s#Z:gX.c0@BTD/O1cHZ8=_>bpD&+e,](0_g4SB$2E,i&<nna/<EBT8)D
+%RXS_T^ti_3lR"!:r2J>]kYho&;3@%6[m)$ts*[Acs(C9^!hPl6aU*3d*GK9c"mFtWKuLO=Y5)W\I^GB+l28387jtko:VBo$.)MGK
+%TYB*d>9&Bt;Q;o_c,3R6W<ruK<$'h.%EXg!:[us"EfgaUI"i$LjZlf>i<5gI!O)m1_IhPfPc3HK`/1%%$'ksO-N/A'iY6WLl*k.k
+%"P%c\"1A=:!-+6?.;;WA'RY`>8[Wt];;mjtF9"TdB`D1N(20_lT%c#a'Ro7R-+:ngCt*t4.5,=N;q;Nb*4;^fr:g\RklcRG:JW;`
+%_,8GISp2M4(0&nWi]89"6/aY#Vj_A_%u[uT33qn%n?L]^.uY#9@C=[L%5;=hi8mJGiLmT]PQE&J1f-U5Md4Z&#em3dF=&`TLK>B#
+%1:Z"9$O(a.&WFldkMO!*<TqUgFp2ggle3(DE,@gnR2SjuP<OG)4!!Ni7!g?G`1Z<1J=tY>6BlCu4<.jX8KX!h=P5*S$+@g#k'Zq=
+%<\*:W/nmjZ(^Fp%-0)dX':=;?R;bPg@h1qmEhPd+;_qs`h<pLDJg!e%11G2Q85<.fokm0ZCW]m8`%gsK!aT_Cr_>,>H)37)jS]Y&
+%He?u:grcZCDRR6Vi_u5-rn/(E:@?$?hu7?BR&<To4gX4j=2hP.8'*tP6s2qnF6a1Q\>3*Cih,!R;"qOu4A!8ZZsZ>+L\i^_8W]!'
+%o0bFm&I\pbEE`YXmC^URWQ=&GB/b!^9rfmjX7&.t9ANs2)Yh5^1j#bbg&'DffLp:1]sL>F%FTqX+OR,EMjBVc'NF)n%$u_mc;ZFt
+%D.=M\p!(n8pQr*cJJZD%%\Hr*U<#$61s\+4ifOA=mD??ggj/OPl2H/!n;_3Tal,5QJ\s8Z;2JtQdgR'\r\@AE]Bq$gk"h\H8qZ:M
+%&W&g*KHHerd8r?QY/gBGJU&-fH&*4TIFZ@YI(O:C9A5&]JOOJD@4Q\h4b3tl(AYDKWuODhp[s,3rZ#65[m?!-R+4j]!%K//_.Dg:
+%0,Ic#(W[sDO&ELq#!JhI<-#L7[e1_g+4[R+Y5d1;NQA[l5j3eMqWErpnNS\^B#[VHU&-a*"/C+$%-e-UQ8NpiWlnHomG-$OMQ`.I
+%;\P_K4OLR^XNIc>lu+,]ooZlf2Apcb8DYq'5umBl)ns"Tl$<qsa^2eg]Yt&^#JnbkLeYOQW!FLsOmVbq*KKIl'MRR'Fn!<i$-j[+
+%Fgl`"bH"\AH\i=>"%rMXn^#aZ[;KVH<+rf0JcMAN*9D)KqAISk0<\jhOKEeZ_mD9.nn47mTn2",,;.E'`FNc>dK32UH7[l<Q^me)
+%#.$ooJHTj\Z<NP.7PU:.N5i[Ec0V<IN'%lherOa.]"S9,gjFqTQ%fNr>drk<IR^q1aZa\@@0.62d5_pupduR=^a2[e%'5Dk@G%+-
+%;3BXi0CLg&PFLj9Vogr-Vu619;D0YS,a:=QWaO^gaG;h\Yro09]Oa`:46hUfOU?0#in\[C[IZfo#C.&dGP3s#=Eq*o`F?ZLH',p=
+%@ntpAKq92+,M?5dMa5H<,7CYZg\+X`O&Ut+]\S`2Ye)ta*H_-&bJ<kWp66#6ba(6#HEBN<C-(.\F`UYN&fUIDqi4n$m5%Y0j-jt]
+%W#`b,fB>f]:6P^2mWl<ZgHaiCpjVQjW?+-a&d#u6/QhlC6A,S=1Z%!LTF58*/VqfQ1)uh(Ej/nA<`23nF&ZoE7F8`dOg)0V[Y5iQ
+%$;hOA&HMKFm)#Sj/o[tV51$%m1M/mQrE"fHF;A=e=#?LN!B(mp%=72,KH4k0-?fE9Wh9CL'.sfWaIj\s)fmZs6Tb5+h<b1Mnm^Uk
+%g:?5M,lqXMqZpX%#%DHb(qDFYO.`@q"cWfR,slj&:G;DHr7>+10F4.O04m*h8!gohAB<@nfM9/e$EBPmT[2QEl1<R,.U79l?V7.0
+%/GC40`!EJ^\r/]mfB!J.bE&i;SGPZ%XBYoHEM]"kMdbKoLO<V./LE&Rj"d(,!@@d^c??I*P+PEp<O3mNIXlSRiCItA7Fj7RJn?\Q
+%RXU6!U->]GUSf^TP+8L&aOI(h$YePaTOE+)aM!Tc=Y%7Y+H`RBQB)]h*2&(.+O<<=T^-kT_'p<$Gk6u(ZB-+7p4#.^Ec<qN/r9Qg
+%ps`Bld#JA_EOI6CD!3^-HY=R_ka6X;=odC',nhGJ[0.PG;e%hUGAA%a^R)6LFSbJ8ZM?TQ>B/VZGqK]X]/bd^R+P.*=8082_g,L=
+%#=VFM^h28M_*TamGi#<L7<gD$e5_bCcM?u_4e#aVJl)Fs!R\)@hS0/eh66!@gA6TA:gW3(:3]Dg=0RoFY9in-$C\9Ur=Bf9Z`l_Y
+%G9&0>7'pYRQH+2"p:U8`d*(egC.NY-a&<E7b][r@;`J,)\a/4h(%i9$N(:WFn+W\;MYQGSmT7^n@*n%pT)^VlDRZb6FE7!,g$?bD
+%O.GqX%Zgj]a)/tMNh5n5<!NLJe#Z!<^PCdU>m>A28K\VaZIu62JoG%7),0Gh!4u!t/QGH:nM'>C"pA!nk<BOo;=u]KYj6J!bGi[:
+%5)14r?p]^d`?nr>o5Y4.c'u?pP^u-noL5ue/-5`a9B2Ik)pgGWZY&W]\#X-CBV!/_O0N7/)@+e#Xc_Y,]YOmAlCW)$(/^c:-+f4I
+%&Yjq"8?p.JHJ8>DkN0XP[WXX61ng03rbT'EnK^*JM!nqMS2E5RI40qH\V5;dYgA<p#6SB&;jBc;O2'N=..%?qD#"hhk^J>g(5Xg9
+%1]8MUTI=:"c<_"cnYHd[Ms8PQW2a?hE#C!PIO4^i6G[eD:etl3O!>>6l(/iI4htbAhX(>FIn3OMqTu),)dsQM5UgP^KW6^.RV:<+
+%FgK0F9c$(4>-^>fXtZmqZa"GKDEn6EbPSQBqk_?p)@4mY(UIRD3*=1s5]a!]9nJ%mHS@i.MB?&7`>5q#nAiQ=fkS.u,[#;0R`[8P
+%`tb@1LUZTj.>]0:WSk6DembifWRDgPR`h$Y7bf^^P%JV7OOIPjkXin3:i\P`I^4DoZm(^W&J1`kc!El0_SmU#3?sM?0h0Vg<Ns/-
+%=[MQ=87h7"lV!K@h"H)X`>`_^b`4oIc\VKZfrle`m;\*s,XF4gATSMW'kqd[COkQ/0')slO<\qTQu))=Tp!G4\^Rg06&6N4WfA)R
+%g4(#)e9c8l2&AQ$raJ/K!B$N:p?>(U[tsK6F10U7d<o"uUcX?2YdiU"UHjkj:cuB$b40',UV]nV11SWOhhO/=!$%#,=JX@mq[B`[
+%:(O!,,?V(JR0-+5-E*`+:!eX*7`T5"gCus):a9PS<lfi2g<si^hR7,&%PE<5W,^ng)2uKSTJkSJ$%`W%Hkq(7\d]C]A^]7`XqC8X
+%0gJ;s7[Q1jnA<l7oMgMsa8336Wm>DoZFZ<EA\A.ml=.gKSbm_%=a6"#=\&gBn"M'b"X/b;Oodb\))Qb>ifp']7Fb'K]3<>UKeeXr
+%.jKB^TOD?;me/bn4uo[]_e`QM"0F(`GERuj6r<WU%b`61>#"I1N(mN<V4BiPN6c_Po.a#7Z+l<aart/&<hk6s.H#];C&P$A8hs^\
+%`is3+)`<sc;&L'PhE`B[W^\R;LOQnJ$eA>OO'lu%giH&[,tZSa:3Y5'6l8nh<PH0/+gKX^KDEa3aFUcX@3D2d;Y*[.\1PFHTV5Ju
+%gomb8F<4'Y#>cVLooOT`nA.J`0[JZsm]`=JWsUq3Q3;h[l]lfYWH->nYAsP[a*t.#_IS\n(%t7AoV$PqJP[Y#OBL4RTiH(MjBcI$
+%a+9/"8ced/J9U8gmRm]8_b"#S*U3.s!pL9'lF/?C'M8GG!,?2.+?,u2[G8LU$Q8,]g/AiEmns[<o4GhT&*Ij$gX8:?61Yt`J`uBb
+%r%23?:M#UPQej<2+L^Va3'b_D]P502.`4n\i-jtP*^!ETVl=dO-O_!e*@JY"DcZ_PB`QtAidMC@M(^j`nMgJMc!uMp<0?tYjH\86
+%TWj$Lb=hd<..#HgcJb+l;t+MR*W2_?d=/WB7T]f$SYEepp*lsKA7T`6G:h[]eLrZ.UbhW4j&"u"`.'4/>g#;!%N:(%:&99Sa?MM0
+%ghHL>F!B6njtm(9*@C![!^)gO4(H]`'%GA[`L)-^R_=M8,ET<5Q-/6si=]-=<eEekdfsT91Er`ZpNnoXTVbcoNW3-dlJ&RY1'gFQ
+%q>*A_bF%bu_qFDu))$.hO)Kpc'7`!M71T/=E/jg$:2N[A`EH!U0:2V>&U_7l-4RE]#i]!!.lO!&Js'Yip"obihdcTKfP1B$Fg\qb
+%MGur0WgnG>#$.oqrYeoEY#<k<N1V%uG9_!mYI]8rS,9'oZhFU=V\Y&".Nu^nXl.P&,HgJ!MaZm1)=n<M04;2Ylg)X4.Sm*OCuD!=
+%i=-^L!G]hW4_/(,Ob4c"E"5f<SJLgP#c+iO7HthJ/'74\g4)j@RA`o/#fJfgXPN&_$b'3#S+=*QGGBrIZN`!'MPWVqaO7ciK:"=B
+%cfsP'^=gl"8/q2]X0J[#)GmB"L4@#_s.us_U8)eHT'LCL%J&=^&*ja[<<e;dOI-M/e!>06bMHnJE=luOcaqc\F3\lZHkL"\/6_Y\
+%aoXuXBtf_M+"QS<h>#W%gV$c4IL+89!\8e6)Y6#3n?Qq.b_Fh]MrEc#D&<58=^*E2rT6Z)E,5Z;@9Xsr?2is<Go-?6T]FYAN5De-
+%Wdk-K`TemWU;F7O8-mjTC]R,<h"4[/ISP)']a[i;hXVFQ0RG-Z">^V^If\'-4KV#\n8A(8+M,n'ZAr$U\0m]m=P#^'9*!eh?C7>1
+%YYi<*F/X)[Fr_W*,+la%4Pu#5&7O`1e!mHUI1^$E\%,fpnB/IjVu^O_@KKWCSIpX'9ap_sl.:loQ<Uj9?lHfb#KUUTo4cI>Ef]rZ
+%E=]u(N>.6f%^_Rg;a::]Iu2eGFI;RP_;O!PG;f'UYM_,TM2J[(:ZKb%k<&QhfO-L*E\e9.HBHUWi9XOiK`MuM95N1uSNZf?Ok^;'
+%Hke>cOr>nB`4*?o;ZZ/g=Wp#J9c#ePmukXW3#S5ubjKS3q_m`K!Mfo)^1fL^qtjXO=pVS$G+3L:K'dG$!(?GC-FbQ-il-"8B5S:(
+%3+fEj95WYrSSie85.X7\,r=)(Ag&A"KUDe5A(:bgg:R%to0o+ejS-hG.6Dhu#/@h.X%B#*/7tDOI;JMt=%1kO4u602Iqp\iR5j]]
+%PCOpi)7[&NTghhHBW*^k*(&t1qS[n^rq7,@\l8WOCf?PoA?d^dQVrpa*iEF?0g)UCZU0>MGZ9c:9l(H/n:I""@HH;s?b*:fX:\W(
+%pmIUWmK%(tg/]tmcCN_A<?p<X,3QP@UA'd*%\>DJ--Hab$G3Gt_'/m"#N)V8)%c(Tp\U^A48'ZU^qF%+NC`c_lti(h,GdJMc(jN-
+%n*_SCBPE%67OD*K1oU*R;>5rl_4ul6(O=FRjjJ!Yq^@3`4\,!=U4j<.R+G"l7T"O6RaLI^#1tk:Ht:JQ5<q">pTB/7&KutNAgagk
+%5&N#0Df+]Ea[HRL(W(#A$01nQf/1-;#C"nW?3tENL.8s#@-mBDDsieUH#:4=I);%q$?hosI`RJtBrjFKl&-99rc$L9,m[@ijl=.U
+%($oP#@'d^+R)r7-FubG(:%Wt)`a$?0V&TgBg3$1VWPE7<=Rj3QTqlJ7M!E&<rtTbF_aTc(@4N&nn.hp:mad=m.XT2gVk6?s`B,o7
+%6k_uVo"<;-Y>AHT\"bKj[S-YdZ&^hc<X+>SpTo7LG*7M)\<5qt;:Daa(P=ZsN^<7NTg_9-F[KBULW7Z/^BHVeDQQrsS\)X'Y.d2#
+%n'ik5BUh*-@$6kG:+L>A-au0W@S&.ps%iF!=8)bC=_VN0I=IHG:?)9uV)7-GInZ2L1:0tJCf7(u;tj\)dH1U<UXjXPR9[)P-qsjO
+%`I/#uCaoggIb[E)\`G3ESRf"@5[Yl9-t<u<FV9k7_d^YQpqTjML_W41N-\*il[@Pi2XN#XC",nt?D%t:n/1ef.HkNSUY?pkI/s,h
+%%`:+!rDuCTNS_d"He>OGm<UMFOW(@mf4.=6mF24TeAlDd$uiD?o(gRJo*nOsIgge:<8BMS.@@O2B"?C`WccpXmsT<[<LH1+d@=H'
+%:f/7)dt`r/TF].M7BejaT:)7%AI'qFod&l@)\DgD"RMP)a-Rtb5kQg4ciVZm&U8u#Gm9+5^8)#qkndbAiF]UNpg&+bB``Mlru1N\
+%n@$74n_k*+##MP%,57;!$5)\6pU[usg)J%<AiC1qdb'l@!&h;2J%qp.]I,]ASD2K,cQAKYl_$1Crhs/DDEI?iIM's*=rL_QbWA\_
+%p:c,Ohs3%^Zhh@erSl)]'f`;\;C//O>nhY+k2l.*HOj@6Xgo#1Ra7WPm:E3Zp6&";ha:A*QqW<S)+_K-a-p7e^q!ggfB1QLj7RG?
+%O#cIj)e_IffWUt:J`ut!@j>9$`rUkC)0@c5g%OD7\Cl`s!L%B#61jQCN>+A?(pDjf5/h17l.B]Q>6mA;O=elY3.\kWNVRnU\FVfP
+%q37.ilctVjm\"PBb@J>I9cZ%u+t0BIZZ(D%'LfZ\^oo1(T]@&l&s!25pW0re38:?m3&M"L[8AE1Rt\D35s/aN>HZJclYK>2h)uUZ
+%T4#ee8s&DJPWQWB#YupCmL)IKA2N]N']Q]%mPdnaBV,)%f<tK;XpE"l8=AIEdE$e`pc4cOU<Bc,oX^T`MeVl,/lkYEZ`JTZcMUMc
+%qn<=W!ss/nK=*YGp.f'uH:d)EG=tKTrL>DHA[uQc.rgEVLuliB:IA3AX+<1OitgFA`&6_K6!p(*epMl6p/*"-a)>it+9Un48Di1S
+%Wo(Ms=Z*]f1+RP$=".-U9WOZq^l.%%\KU,%+@>)hA-E@53WFHqK,NF)kB3VOi*Uag#*#aahob6BZ!s3IfX0G<dg*I,RDiL'e8_O)
+%@GP/3=0l+"-J+FgqC]D&P'^fm*>\D&QN-pDC9VDBK6kXBo=DkFK1q[i][8eU>8b'_6snE?";=9L,J1ZHBeAJ"cDT]<^&3fbG;I=9
+%!/?RPdGq6)`QlmJ!*I4.R!'\3Wk!WW^)-4s#L%Dnqjj.JDsL*A!q_poD.'ttIiE@3"*Q#+_V]aaEuG.QG?o&7a"L&m:LJ%+(QRIZ
+%bBCXmAd#["j3udB(REpHobVkS15:X.ci8Gg9sR$LSW#)^EEGLZm!fK`&H^m3#:P1GOs\P4_sdfYLDN5_n*cU#%\VArOO5/oc4XF,
+%Nrm=R+ZeE2?ggbRTuL"6j'M`7W+NYk)g+;MBJ@%8qii[6S?;>*ObKR'H4%n:\L=SlCE2cLK%Bg?;:;2qolY?:l!j"DI-khmHY)OQ
+%9#Rukpd)(;j.;Fsi6NVk'F/KREsmMDm**RB7"ZI\SH.qkiW)X#iCY:maDTgl80R+$hj^s#?<0g.04BCE;\jheWqXuXKO1p+3S0`[
+%/;''rr\h!N/KLg,]C#=ogqT;ZHe`9@kCE!/:j$DFH.a#7G)i<;p/@oLCKN*0CB=Q4=;PY;3P8^3Q6T1X3VPm8JV6KU8d>=?&aSiD
+%%K#MpF\6]4NY=HrIXf$T\:(R-.;-^nN4K;``2q6>gY%Jq:-G6$1dMKrbg*&F7,J'$l5irRfFa?Rc(t*oLEJ,%+meh4LQStlP_9K=
+%:>Yjo1jDo!1/^NnAB/W97;>G8O?k6`>)@Y3rk_DgLRh\`Q@S@@US:4@DnE7$W@*Vok>FC6Pl8E9*"?j+UJ>f)%LBKn=c(>/?)Wl8
+%38H1j;(S>jRLc&Job_h`H3WNgJNg#/>(oIC3i(@Wr&h/W7ChKqU2ELZIsbu2FiqQO-d+=Bimq,7M=5;OmbkZ^kMGkrWOit_a2U6m
+%'8ZdQe8u(@OUTrH>kI:q!i'!]K:rdkQsce02M)/#/G].((WE&0C2JYAP[CAA*oJMMpbdqc:\"l^lG9"cN1?X+QR=K#Za8^ffOcEZ
+%haVVCJbh27Ca01H>M&O9!.Rn.gpIKG\R1#ui2^Inb+rqs_O2E=_A1j1HF]TlGn:t)fP&0Y@^-4ZbOk:((YJ1.n$P5I&^re[[\jA<
+%dh3Se\;jt6cRE:RnDfDHlWBDKF^:'_7tsj/qKe>k"W[s%QLLg:7kqf`&<B+3"apRfHUi>V=J]j87]7=PK%Xtpl`4r1FuTs^fW?`7
+%m_\D6a0(r0SMdrAP?o<ORdtK)]Sp74#;`df5]JCQ0?:Ntp^G@dkUGFl\X`I(%#e21*$CYBn0VA=Y2Dfu)&5YdN^"W?gh"!1U(IBQ
+%'E-%]mi]FRY=f%49"2D&[5(^-L0i)VQ<aou4knbUL_i'[i'V37HscjCDQRnW;Des))M-(jWP/]o#^Z*;K_G;JZhh"td_Llk:@ZPP
+%Z(&P,o+N/)GlKUY_4TMte\"rj?7^D+UuiR0.(-kGFc7u3,7K^*Fg:.7B[!2FI=YQNX\moij/'b.:_F[o*NP-Hh<mMcQ)hQL4p0oa
+%#Zkq1DrXGbWAWA%c[/9DK%pqJlIIABl=3oPQ^Ou#lfq8JI-=.'Wfl)uO/_HaZLJ?Kqe[MOf5Y0(JJqao@'Y\r4ONPZ*HTgSk@$AA
+%_0p[<:Bn4G.VSb='OT5QfUg-XAAk,ajQFKCgfH$'E<e1.@\#_p+ll5?[":IBYOg*-eNJc(`nK6IJZc.\d'I0[A0p9H.+Ifo4-#SX
+%.<HGt<2$C^0UO-P:7AAf/:L)Lh\MDiIMAXUT'5?289-(t"q9T`5skXNr]Su*bj:[KTW7fX9n%32PY\\Ib<a@]ro^-6:,;4DVlXM*
+%g4SAD!e1@us/"qWLnBUHB7,<a>_oTN&'asN&"no0)7"7_ga3g3T?]EcgYh$8o^BpIXkn4R4\\h&$I7F/bCSXND7>0^%r[89(Z?3?
+%lhV'WMJ-f<*c&+G)guQd"-',@4+mT.:IF#)f<-$?;>d#Dpc5gss0)1_?gr%6#C9>K[srk0s4dSEofrKJIsh2j=BEQCIXb9?o!5Iu
+%TDnSg>>YJ-^uTj<@/>ZXE7.1!Va>NAk"CI$?1:dBn`X"AeX6q1Y&SF2l\F,D[k82OQMGb/it"d.]G<Z?Zl;6?`GNL\`_cAEfV3DB
+%mX9RAd7HtSJg_e_\E;j2/,phRSleZH`"5k4J)KY@K#\Zh2\*Z]=:8eblGl`jrl?8BeV[j2q/4T.f6%SeJrAQO)]\8K;[O#=KYlXX
+%8oB!bBM8u1#!ad\h1P=40Qs->C]oY9MWQ-.T7:NjpieCj_/`=gC9<KR;)6q$STj$DRd!ln@]E3dra=FGB(.:%QGRP'@o8=-WdBMU
+%ii\o_cKu<thGbWmi&Pp85!SX9;u^i(K9;Fb2H;)kd7bL9nuqq"D#WA"h'!luK;Z:/g@@<YO:$R/#;]hY`)&-Gm)!`13@*%Mc[6eh
+%io7GSNG5Xj0,X8IYgDLnn[7rsac4oe-dWT:F3&].(Jt=?M#$:>BOlinN0;^4Hq:p+i@%X_ouWuH2$$K;rii2`h3ajDD"l8ll#q3?
+%0`;Y=`,I1IIi-W2)Xp44%,(\5Jt$-I+dpA<FCdW,g#RPYe/p"d%_O$rn?DY(I<ah:dma08^r_8mM_6=46G=0r(P]/=mB\U)BB\qh
+%nk$eB$K$^QjN^pHFQ6a3@HeIl<@p@%HY2B?@L[_[cgq%F@b,%gAI%Z3P&H?l!uAR&l4+/lA'hu1@VQ#Q6WcmUi2u?"iku,OB%V@e
+%9"._?%9qtip.2kN0[A^`L@O2Z\+Ff.k`\Nf*9+8_6Ns2YIg/CmeJ@&^G8JU',DVr(#la=ls.p>>_PtWq*@'(QQt-iu#^,nQb=;XZ
+%@8JpaBQVb(WT'FG?UK2e*]aUcS&]u>YLOaVU]WL!%oPk\mg-NFs5E%dkBI9[5G71&pZonI&lcO'@m7U?C_GkuZYtqH<<U]fEhCB3
+%Y<V5%C@T\7jkRDOO5SXanNI>dp@*JuhP2`BR[P=*'BXE:+kk\jjrY]H`*e4<DLA@Rlm[Xk.7uQk%KWE-pqt9aT^8GKf9BNdF?ieG
+%M1tEYSfSfm-]Gp&gUf^.r<cl7Wq\;FhBLU_8+dFqEE\?+[Op`2a=5,ODdSU)JLTX"..bY+2KqnYqFQNf<!4$hW>P@%+o99+=$BHc
+%nJW*u_#9pX&1WSO^0iar)CTGj&2af#88L0<g%rUdVH'jr']T7FeE7mdp0)#'Q"4gmWZi;+:S7R5>5IoI(B^bfAd3I^;9XY_+0",B
+%1.aB$^5b??K"HBnfN1H&,N9#V((gT-6i^_4BN/C81>UP#n/S(Oi[XB$LDPgB_fXjq-u$UB7cL,N(pWT9p\P3P%5j#&]1J2D*dr\C
+%j)V`C10C<>n/C0XXN0YO=iK8p5g`h"_Fa)nfC6jei6-4Sro+W4K&sLS5C?<L,dkg&3Au/)nU6!pb=a+9%-tsV2)B@V-<-4`/dA#=
+%CZ`26e.c5Dgk^u-H$6f8)*?qA^D?-@BtjT]>JNjp.mi%TkL!a]CjmB)W)qA]c&<h\!]/suq#Q/[`:D!HHpqnLoW#mq1^CQGO4dWI
+%V];Ff2229&q`j]\Ch9Hq.-M]o.6:lSnD&MD7o-?,$XnR`]#j+^-K?\qi`+rR5s$IO`q[G^lJ8SgLb=b+oBn0oF)212De6UImAOOS
+%/PELf-\@hsZs'M^6PQrPi=@egRVD)Di"achC5ZK,R,&of&B5fnPquBA5u)@a]h,@LJuI@NC5Ajp>7;[`4QN@ek1?Mu64@;fJXd;'
+%3I@@:;#=c#Ti3oR56r.!$0gZo6)pMc#g0XO/D.EEIm=O5L=fcN</FH1a'/)CE.bmG+dST,@kSb2cHdL-O@p?nkQ76rr"fb)g53]"
+%Z-q!#&u#go1A2.Qa>3MU7oaHD+&[#_S<L;-\hME]jL$f"0pcPC!:Yh0fDluMHL]BY#&,oN,KIm;[j$m`&<@QeK(&b.2*,-roLZ7e
+%Eb$nN:SK`]2NI&j;KuYlq+:H."PFKH@%XVG,]e=V5>o_?8*q%O!-mco`8l%JF6Jd<,C[DBe$a];'_UNX+P-9qgG/n4#EhD7DH6>q
+%nOlB-"@)YNb>#GX'Fp(G+rB>0UI7ZhYEq;N+RMAoR7<5IjeoaJo9A!X6/b_PFKi0M_F+"C=tV)6LPK:2"b`R^`dpA$co,(5A/SaK
+%;[>h13&<_r8?G@QmVCB&mJWH;6H@Vg:W#FoW&fR(k)kE=o?SC#5A_B"Zlb0T%C3,(E3\(M7]?.A7Jt[#Onkq#3LKfM0g:4sgF0lq
+%aC[VV#^3-KCZ4(J2.Z&ZW\tp04]S%=%+\j;l"`Tbb%HI;.5GNuFhN;\ls"TaJ[Z**.YW4q#/.lEW(h2'HW4LlH#j=qLMn'f2j-;_
+%5d?T7G,V#n!\+]TK??*M8PMS$%8W^pdnWH_72=NDUlJUU+LbB+KH,'\!Oo_M`mKCfUH)4aaUt>'Bf',8NrA]8\cPil/i"&di_2bW
+%%,j<\2.(E2@)r\(I@bn>^a^E8%=of00sMmXQc_VD#",5J`Ub'Yo?(R>j74!FXq?k6Cm^$*+"$NVY!g.Ch?Q9r;$g4Q[(3;)%&L\L
+%)B4*cWkFcq8Q4<ngr+6ODt#ms@pmY<:<@W$mL_n]T]U`I5!i5Wcgu![DL`.UrZDm.5homTq4u&"PM%!Dc[*>.IJMMjPE-!4YT,]+
+%Kl_AZF-RF96Vbfp%P_u0B`jl[<"^"@0#Q/(PuNc'pHFB"b!Xqh/oZA>Z8RXG\4!>mIo70`\FJqXiqnbU[Ut%DrZH&XOPooQ\&$<@
+%FRVS#qNWGFM$mM\gbp?IQ?"Z!Jqrpo*fWI3>&1LHIW%e.hiC:X5D]>X58#\UU>-[5s1T=W8bV9g`%Cbq)t?DnBJNZKob;0rppkP1
+%;HMoU0<(1c1j@J+XBkMG9Y2W5IS1U=,=d8uS<V#gp$>qAH*C0ANJDl\Y[m!G;N.n$X0(#h^^K;PoSPlGNd`a^FlmYSTjAH;^cd;%
+%cVSH9K!;A$%Y9&BcXHQBQ<96QlcD)h"E9aVrTl+l2+@2R\3:ZB,:M`j?#<-J+XBj656uVR=p8.C6(>(('Lf'@S07e2r.BLOoB>BB
+%n,VnW8TYRB8g7i0$=NicGG6YWjLE.>];LqEf'ur1]ABK]j-'ajD<g42>K^g?F+.sPXVO2/Bg>j=h3/+T^p^=ib2$TO.'>T(p!\6M
+%2Ap#M*);NeB$1H4g7k5YWOsYO!,O4`m5g[>*e6q'#qW)u0W<MMJsnOmp\-.LnZ!a%G:"]7,4ohs-Q_I;+[ON0]oI'Sn=8J04G'@@
+%"k2]MRl=I[DNMEuR6qOrM]\1+%aJN?fnE*aU_N&#%H5rGh6W1XGl48]9M%_YbP&GMVV.O(g.`tI2qZAMa8HlCO7,Wn+B$PN+Gtbp
+%#YYkY>m>KZOZV,T4mPd+;gF8>S40Q`bQl8HJ:+^NY"57@/9L1*=WFd4UY@QpUH?Cd;,$0_s314Dg$uXV5)V/$fmoR15P"3IVps>Z
+%PG[s6j2inDf6nC'HXFbdO5&W2a@2EZn,'oNcb.JtLc9-\UG4T:IV98O?IqVaOPGJiAW]j'\3\_Peg%#%6&[MGmA\op.1.oNG#,D3
+%N*VW!+Q`hk!d[!j&n\CmS$oBpBRpuTh6]S3U-Fr3&*W_Y$l4VAnKSHmn*XXd[>:k%T!6g.mY%_@DP\FtL9$;u,BSh__)uc"ap!aD
+%`Y3sY68\CO)#(-^H]3hpZR6U"YWf[2AW>5V0GHfo`Z"18$o[7:BTp.$:@&RiV%Jfjr4ILjHRYAafY946K*TIIq2VU7SEa]^A!mtU
+%XAKu;G91U!EEm)2\ZN.MYaQa)'b8D\]PhT=0:dkai^W:BWh-;_=!M<@XKlYT.occH(I^,Dn<ur]&8^o<X5uiKlrk8m)jh@ls1_oN
+%G>\!#PJgPK9t:'VJ*")J/RWW/qg%Yq2Qcu3gZs_"O!i]Js,hBZC2U1&^8WD?W73uTn&R(1gZ3'E#<$j$*tGBVAC.#3mrS^beLqKq
+%/qpW**A-*$Qk,:kD]1QH?6.\eET8*fI=C=K+>,bB*2ZMY:q7Dm?S+4Fi=@>bIro\oKa2Tb,7JquFf#pO1($I;Mcj6&XcpWm6We#e
+%g)>rG&SjnBn@6SaKL6[rLm@4GM3K8KGFQ8?WY]UZrA=iR98ZZ]'-VH"-A+("Jtu2Of%9kfU#.(*e!<$R?S>Kk*ZE)Y3UT-GU":OU
+%Zuq\2.u4'q/EL=1P)NK%*L8JH(;8%:2N?.b3\bq=+3?(M#WFk:I5e7Z!kDI5W?E2r56VDndgsf2*eClUh)'KF5jXZb*d!T`M#g<m
+%pk)3JZ%K)p9.coAgLM@L?U?Nk6gRkZk+&D&@eYjJSe6Tr=NhAb3tIJIOjS:JD_.I#9F?r>O)%>\eQo$U]?p+2_]<I_\C5;2#H_jN
+%e*A"@DjOY3F"X*Ph(^-km]j<ZrfsreOsEE+Q9Xt7k!5q([N."ED5L@u+R6O/[CO,4HTWt?,Q:N:Aq?9!(10Xe@W%94@eC0cDsoo_
+%_k!jN$pgNC2Dh?Ff`#O/(*6pa/%iR*ngG)(kf/l_Hu`/(1A;rrdV)[oh#,[<f:Q+BI)\\is.<<R4@C];'%BsMat6-^DDmGCd*8GI
+%!jNf`k">5C-X/Jo:*qS%ReSj5[.=jrFm#YN-f9t;is*7+rcnW+b4'\Z,]u^Z)+I)p3U"dVg:$`$VS&\DD>A!C^>mC"ff\bhn(L9W
+%gpo-<nCWT:L%)3.]q0nKIqI>rs*j[3,.#NR2&=g2BP;2H5Y0ei1\a"Pcb.jPk3FUbH=V=^rtG9G&(*J\a7VJ>`g2;o9_EO?;C2DT
+%Uq^gM1l^u0CS!q5=05-poOA1#-/b8@hKQgTYJlt[%Uli@2N(/<?Yd'07.JE4EEb%'S!+ko%R/Q7T['$G2Hkrro.87:1Cd7adL!i\
+%O/&JaD=YNKU"!3%(b:`RCY=U)ak*HW5D8MM5528NkNGr)rL+N:XL;8j]d@'R+\=5+0-\rb*"[2P/88t?`,X!O&H,]Z'#C,sB66a$
+%lQ.k6?YFg\r?1$$ZaCE>+'6-1?M?2i7/sJ/>MVkNE8GCE2r(,?<3tdOe_"BBd<8c`@g(J7)ZOq?On&HKW$%B8Xnabol1hG1Rbj`L
+%F:^Pk;<m3)o.@kTo[oj@3:r!_`!D80B^!:1IS''!Gnpe@o#dSpOeN[DmH>)al#MIZ\AY%E$]5rU4iBBc?\b+2VX+[-Ch]b*Ra%^9
+%F*!;U?ASC?b4IjnqKDd^MHpN]/UNUW=,nMim&=kT7)4aTEuNbir+Z@K_@j!8&XRo-;\&-naE.7$la2D0P7Y3O'MXP;B8MBhZ'%lH
+%LsLH>%t,GX%qO),9@4iX@&P)$\@HgT.c-QW3:1?44(Xj)3%1Q%'V)5h(q+SoF2"29681n]im9,]aeOE!F-ScmO-@Ir*JksXN3Alj
+%]#cT%hg+kLDT=@R--(5:/\l+h]3q&(N9>Mhmr='Hq:OBq2<mgidR)]`>#!WZGb96sp*_AhCH\,e'2+9@?f?,?*E9An&>KTt!"s7S
+%0IXa:7W_(0ebNaNf$%\ehHq&:@Q(@O'(M^$N,;,GqEW'%B^]rMTET?,TprnAg3:)T&t*$);RmK0\3IZh.`fB&.k=d+J*4c&'<Mml
+%#D^98]f/#K:)iFdqp0=b/0s2nIi/%=B>R6('l+"^+,;Y,7(kh:jdpX?h*.\H,'h_pd$0N<S!;1Ib+$QTpH*@^`V,<8erW+Lm@@^G
+%G\feYRt;G":h!GrmBEUZrDNUIlXoDa7-@QEL%2(okT0"g'*?Y'&:[M,=A-W6R;MtCT@adVK;7Er0"X93,2F:G6i1ca,>DJuefAJ+
+%46LC88[8)X:XZf`\:\Y1?K8ZS!)14QLd<4Rr8H_rn#![a[*l^VCYTNW,X+$KNSq(%A$5cEd'o7"H\e+=k$k(o+3;qJ^JY%O_,F^W
+%O8J^NT^r%pfl]ZCX]i77CO+C=aS%ggIBe%VI^'SS'S6.'q"Up`!C#28Hq4J@+YN,Il]8Op#Z<J`4btc^/Y(PV0@WOkJ^*@/$9AWZ
+%-165`;WiO:j[];(+k)d+Lu4OU#);JE=/A[3_#E-dZ'UFf`"Ft<5u#M^E>!Dnkk--Li$+K1<r%*cJC?)]Cm[AqM@8^f7nsnDG#_]s
+%q[!;/V.p8O6Nme*7W:TT28lhu8lR]jL3'KaIk2ueMk8/0X'AgjFcuVs$_ci2nJ#'B7,a*HG9*7Af`*UOn,B@jEa=GL5lq/jqNh<c
+%@_iOl!Y?6l\hj#.a@P6Weg"-H-%V"&1E[N\Gc*ujfQWctp'a)<!lofn,7am:U*,O1a%kPW1hZ9jeuh'kpGGCWi4qRq1<GraF6flJ
+%:7\E`=F70pg6.UK-DXe0V'e#EgM9E7Gupb#P^(3bD4,S:5a%%ZVbP,j3=CG`S[V4?/?[5VOlor'`WD*jC2\:>o:R((YBg%52f?EX
+%/[MZ:RAt?Ffo)Z%"!UCepd_HK.IH@A=e1dO')7&H0:r%Pc(:I=KEPW;Mu\?R[;PYH>N'65SnF5sWM$O,R^CT[lmHUF42S<A<e;[O
+%4CiG^MLk\g&Y3D;TZ<5M,L,=qL$3-ED1l`_kfgst8E4,s.5V,._DWr%@>(:VVSi;0AE+;+'B!;7Aop^u4*fdnCG9uhQI^0HX\>Dd
+%jjfOf>=sid`eta3];Ta4l4tgmS^ugto?;)!H0pJmGSO$p/U=WkD!Sqb0.n!a1C^rblVN!1=M3=+Cod8($u'+,Z7uA36Q-5d.3XGk
+%Mh1NE(3HrRnARrYAi#5JVH$BK9EILc*PUI_7T>pF?!4L<fd6_&Mfd<D*=O/AO=G6u6;:9f8UK?-dJ/>tE.5P`I^3;Dpc1M56l9IJ
+%OG`_!/PTr=`O%:o&W`[6L6f9pg1G=T>1O6cW%+a*>GO([6[.-S8I]CX/'t<^1Lb/Cr5A]A5h&K1aB([tLQtd'2Su_Y(9B%;E/DhK
+%:H3Xt[MDaPad9TrLZTM\FWcSeX*YbcVDK3);Ap&n'8os[g71SYMo(EgcB?\_mojIG3C5HtE[<JJ^j7Hs"&r7J-l;tV$%T0t+,Q[I
+%]s@"TJ_8ORQI0S;XHSCr$OL$GUh$&H,s$9?3eH#rJeA0tFU]`-eD1fL6FNs&OP4S`*?E1b)ER'r$)rM8(>Hp+d5^Ee;*qIR6lF3f
+%$p\7'd;Yq.D\@&%%;$lhWtr]:eGIm[A38_dkhB^8`/;J/WZVg8L-bT"<fE<VPX%k&C&GQ0?krfrLhhRBd=PCDC6KB_,>fSI`jm8Y
+%AT!dYc>+Y?&Vk3M*7hR(<KNChl.RNWX3kVFhhg@K0A"a!?^8D`q*D5g$.Mo%i>=Wco(L;q;G>[gkVDk(GdL=R3Q;!_B92n2/P0E"
+%qBjdj*54JJ$@8+cS5#YtT&]ac@pt7EEta:ck3*b5<W&a*h4u^/!SC#mI2->"`?no%VmOp?Ol6'f4/1$G6jJWj`SG9FACdh4GoiXR
+%AJIcD'eDVPC?=;T>945E?H@/E]l1RNWYeUB^F.mena8F<$kn^>=sIL$'08p26J!qQS;LL\0jE_hD:N#_#JgqJTp>/elt]0_NkAAP
+%9k+6gQQ;aD%cfVZMX)#IHn?/j8L@gP)F\oANo#S!cp5L^A]Pd4'\&:SDUN/Lo]4,0N3"9pq9`W&n=rt?'ZBS_Jt@BF1qGP6qj<^`
+%nVoPI2`+W"WCEXFJgZ%K'h;+X]j<&UZGXVXd1JV<:fdLp>:\BE$Y;pUoieeE3(`WLi+/+rkIqnS<l"])obPeE)@gYT.Ug<QcNAME
+%,OS1_Bh&)@&Z`p?%k2NLA'\p[;[O?\j6<45TTE9=#AB2kE1dJl\V<[F/="^*<9m)M2Z@*[J;-Oc[B].bE0El<Z$$lP!bu0hQkT\=
+%Cb!\5PdihJGt4a6+[=%'1ajF"S3_\,ng&Cs$mQM>1=[uJ]f,%I1ZXMm1?j:lQH]>ZLmr#G`b$JE:YsJlKL:GMY6`o&&43B"O_pVO
+%`A;/>)%-uD;'Kua%;eki+JgJBi9JI)nM74deXNOm3S_J@V/MR32THbJ"s<^Q%^Y=&-oc'ia-ubqV+kDP[E\re_Y@TN[_cfWUH;a&
+%6^@b3R-Vf$J"nKcLE/s#`1HlGi\!?akX;*&.!_3@Y[*k/4(sL"0XRJS7!H6Rf@\(?d3X&eJV'2m@4jV%MqMrG(M</%)EYq2XQ0!C
+%Gt@]7.mP"Y[kf0bE(dHd6NFuB^7'AFahMM#mW!Qa[KWmgTY$CeYYccXES8_Y;:;Mb8bBIbTYU2uAG!1.=+G6F3A[H22=7K-K>,:0
+%c/C@$fE#>NSqI3k8-e!OOD=?qlJ.+R/2LTQ>^MR4h8r8IDSD21AIU]?'#d"/U*jkL]L!?m>hT4XJa?J@YmME"=LId=R0AA66Cf@r
+%+7aK*HF+e4<`>\*mC+C_`E_V+E,*MJRfY>Ifr5N.E1&Ja"MGW]$_pk/fhMHR15eoqXlBRk5)ASL8[&J*,h^&L:YoM>.IDZNOu0&U
+%7Y^CGQkd#KK0r5[.WXl0R/K#<Lh?=^Y%=XDgLT,VgmK2T,M"=tHHhVE*(Fr\<fenZ=]ljf-8UF4p!DBC+,h<de4)3<JCMpaNF$fT
+%+-#P/\9*SO,*8UV2G\CK?J/o\66&Q`eB%Z$VZ@aMJ.3FkYE`J;1uTQ"lq\f`eEE$^9A`U`9m=TpPLm)F4'/j612ja*BA,VYI/n\I
+%2:doT<_'WR+R)GhU3^N)Cb1NiCP6D*@p]BZg4@i/q.g.]+jmi7jKb-dhgF1V?m/)&BnDVG!'2kg3Dfo..(/T`S5Ng6Cc>_VZ>unl
+%0#Jd-L>[g62!qcF\PFe8YKbOB[@l07?aN"cJLc)LVn5d3:-'/CN#;c@o+[aIk2Q8C+0VED>8Zuqn`adWn#Rr-@l]LPTT"UB()"(,
+%3$oU=io0$BIpPn-=UcN,Yf0-*[k-Vk%XU4dIoh^0Ycq+H,@#"abJOl\pT:UrWqDL73m`H@]N7CO$l"\`NN.92h+1s:#':^iNAk'I
+%Ji"6odRN8%SahYJ(Ie["2[YK3V.chOS>.'B*&fZ?,Mk#-:t*+`_b*dZ0PN6'm9oTqBl(+P9AG:&^0=hu,G:CC*#Lu]Q_TOZ:P5@D
+%++4DU^0qaple.BQ3&iPMs4XtTNl(:aiX$JU.=<`KW+:(F$po&)Vm[Wo4l"8@9OAHLn;R.W%Em]"=?n$V;iI0jOSnCsd0RuGSO<g=
+%=4Y(+s4EP)KiE(UF;!B0k[NS#0IA3:-$?t`;HT[^OC_RM!TU1(c&JoKqg\jsDFTV]s.oW"T5[J_5m`OQZ$E)a$+4'?'@h\u`/:F_
+%!+6F\5Hsla,8?7Sc3Xs]Z-F!1=_Y%moY<dj0oCsp9rh^(/7E(XWB0BVd8=Rk09H:1p&O+f0_%We/D8!nC*_=V6>bX_?AEX`C__G^
+%BIn!oOX\Qn3,Y6,H.,nY6`iRd=c3l.ojNYgQ*#UR`mRtR&kc0,gX?jg)O#[j@9%SD>^R`t$[gNbGIlP)b524L6VZ*Z+&uL'PoZ'n
+%/lZ(J@j+ohnlSOjjF\r0e2T]:>:aK>=5H7nS,C.*p0'P.js\6n?reUR&,IKiPK#VVSYskf2$DoMWh)`JW+\i,(Lf:fKsp'm[Vc/h
+%,j/qd^/s*jeg`)jltL?L`=*RR,a7k$l-t50!Qh"/,W^&t2`"%@.<uP\_at+V\0Gmf;2C\pPAg:Vha0=Amb[ilkATeFH2h)'gc`At
+%qWY%656(9CB0pH]p[mb"S^R-L5PXG\*ri(g`]sI`c'oNQ5Q@K3hRrdQo,#19lLf@NqYHDZ?G,-tT--5oL5c(`hu3K%msas%_cJM]
+%miT4;d:])HjdlGBZQK/@kF[.pc"H#'rSp*arVY=bc\)?WJF)nUa$4uB)-)CioY5]qU-T64IrP>'T,p]k^FONc^AHd]_qh4Gb'1oJ
+%&#TQ#8P^J@7Hdk=N.Ipll>n1L=17;M@O.7b5Tr"]D.,@/]UmNeikU91;>loq\6&Ag=/HGf6Cu<l>?'[p,(h8Dodd%N,dRulQ&*/M
+%^4HMsk*#IE[lXV=qj>f/SI>fWn0ZOAb=l=!0?MXY-m24C,mD'm7C(1IG:HD[hS'+e1EXng%U5^h3>a&tT`+k+`QQ7")N5'HU**ih
+%hHnk-bC0BVLVJpVQYYe4m]r#-,Zt'9aZGM)VSSD*aUF@k;q[>m12r&pUj&$o.S+okd$r[b.?TlVc@P^/+U5%&8Y]u]2].`XYR[IG
+%eJEJ_3kBMp%6!^O'(lnGJM=AqS>*68Lf<m&*OR`pK$4BC&nsBPgU`Y@ZX^9\Ho>&&QhQ&B<*^0l:c^:"VP$d(cHQi+BS<a+feSa%
+%K^1%J-'10#gC@5dWo8EF!bHVh;N"6J5bL6?",cZt!M3,ik"1^,W%8NAY0Jt<4W)5nmW%[E/:$L@!:.L7[j&me.%d-?VKQaiIQq9c
+%=r@_*-p'hCUAFa_F8LlH9GpURXWtc3??h>a)=>()2;;EbeTr!d#Lk>@nLKDAd^%20Lm(pA4t-M%4o272=-oug<LB!n)E%&D)(D#I
+%JPnd8igN8XjpC.Z\*')]#<`2&frF1/X%?g.lU;^RY82:K%_+O9GFCc8(/<$V!,eI^iKOWEi@\*2E<XSR031F&0R<`7;l#7u25=\]
+%Qod%7#<N/-[ibR,KOD4Cj2;bk*W$P1+pAaJ<AMb(Mi4Z=9b'g5<)?F$2'&(7!4CI=4n0+R`4rSN_mc4dqYJ1WIWis$Z_'Bd=:p>E
+%TW:EGki40,kiB!?kad]_2,ch)q$sh_c$qq9,Y+]KKVTt2TS_XKp<j>,,Cp+H9SfPGYK`l`dqb(laH!]9-'tW&2Q@9!;^X8VdYuXW
+%KC)hYRqfGe)e>LC;,Gu1PW=i*6Yf[6+JcT',bu!6N)m"@RUqYrZ"C1G>\sma9ics]A#;5`Z9K]84TH5.c_P[5fR*b>'j;p@gDTNS
+%OF`Y96Fq;h#?NSKnb0SCq<Vb@b=1[o7%&dddO%I[[2#:Z*areVe%-B/W&?86F>;.if":2/og4Z]`;rAFKbBc9g!("RXAZK/:-jDr
+%`5_mrA$1')"mq7Gqt$Yb/[G/o-7@32O;';tRdk4U$#fr82Q5S'K]AmM^JBrR.Z*,t6%Xk\_Q+,[;T?]J=Y(8tR"@n=*1ZY-)@,X3
+%a??&_S'O>Lq2@7)Nc:fERd9]>bX?Kb2Lt,ckc*3Bl8IjPBlds?JTOEb/&tb%]UXPiCsZo92u$7BD9_:S;M4"2PFK-alK-=8\>sYW
+%-Nl_nlY?d?$aHkoDmtnV>E&c]Z)'_*$6(gk3nN8uMFW:cI`#_,Z8+>YU?+],:%#t!^)E<[@S)J/4o(lZ>FS=UbOI1qOH1>gJ;LZ-
+%".g883@=#a+)l?,"LQnRi605eB6=CEhq!T2M_Fi#`S57<SF;S^)#/.Keqa?%b:]JF=LT$0k"%M6,mUHN^f$S(M/Eq"Zu<nLAYK#J
+%4B>nn+O=t!hRrrNX/RPK,I%>s0rO;,p@=q<X<!uRj1])'P5?f=dHF*_DHCm<F4s!/H/77=%^[.&fMc8h:p!VI+589cJh/e:e[dCq
+%fr;.Ja^\&0M!]83UU'dlrX0WL2/t`8WZ3D;aBbO'5gf:?@d9tE7:':Z(N/QV=4b\T(JX7,^=6b4^kqoBgNTP>H\C%jokorqm&C4=
+%Z)a=<[PX_c9lP!!?]'9klJa-ff,:sHI!#J%l][;1>VtId<(aeoY>FppMA/>Z6hl35X&JbRm.E!\eA2m!4PI@@C<!*taal<'?tog2
+%Y/KU2<AN.&C#pNUZl3(mncZ0Vjk7R.+HUH"<9m*;Io%"Yf?[99MW.kOi"?hp'au35-\-UAB"XY&dh6qZfTs%S0]/+30^Xja=G3"!
+%IdR-AIFP<!n9FiTd!.iNKJ>WJkOCqd0\sf]ZXJ*U6^:Pl1P5'f,i9Y43CqnYXJWlL/0F@U>5<q3O-\UP0s%qr,#F2aBK#67C$neN
+%ln"c.NcYO1#b&O6d,H6u_7Y\C`Zd4_gE6TQI"3>M=62>hBdPs?^J@:E?9.tpA<[Yknd&4C;uWKq9p<"4C@O[MKD-5uf<2rTI"k[i
+%f9Bl,qa4La.87Qr%rf,8:1q,62B#oIRb%Q):VT:gD3<7Fk[#6)W#@PF@MS*Wd?\Ed<[d>M+<)LE&!_+%l)SU;cu`fWF7DsE_DKi&
+%@]DWj[;KrGWtkMVHQdH/C'Nn.1H*/dhDLX+8augU+,p(IG<PFh"3BG0;B9J"P5)`)=`C-6NBs";pCYQ`Dn3755/94%V#I@IAqT4@
+%&e::Xi[PYYf02Lr@9O>#/ePmqi^1Mg,f;*1=WD[MTfYCM$DQ_U>`2(*l(Vi.e_HeZ0rX@YUj+'&Uo99:"+Z\6mH`_\%tS]q-g6c:
+%59c39*!7@6D`!Ye[(A7`gHm7qC.*VOoF?1r&.U4EdR[m&Y3k[Ll)Hg/@B$QL<"0rg2:K6npe1]_G6@@gq-l1QW:-cemTn8r>3--Q
+%h4)#sBW3gTKhJ;E6+.R+Jk@u^l*?RV"uR@pj`U/gW=$tTX;QR$)?XOjO>YQc)hf#+V4;bWYlhJ38_XfCd`1DSgr4L/Gl)QFn*IKe
+%?;bLYR!pL36[Nm3s3fLJ+jqaF67tnVIfNcBh,;JZ>=,u+OJl@YX<<j'-Vh5*'6Yq/aaAs-"S`Fk\L&eOD%deLpf:<cogUQI:=cXj
+%2J@7KK&l#u![R2UKLnS,`@ll0.2P_poe3a*n=pJXit5At*!.]RjJ`m&0LYu?Cj<`j!hcN%:^T-r;%M5pTEhCRS!rSuB;1bf,$OZ;
+%q""[C;oLX74qu1DqNVS)euB.2%Trf/r4&d>C\#HG(TruqBFIk4!Wl88)(>EY/)rWsX=kgE]QJ_ZK$GraUjc@c2"tNp@C[M.CPu#I
+%[d59`f`$WO^Y/'?EZ*1]Bftq6N:g@KEUVJ)J%YRlfKgkFMRr<[-Q1--RjqVu6.CaT5qi>TL5Mq7SXc^,@FD#^hI47Fi5E*6'5pip
+%T'V2tXW/.u#)El@@@ld6im!AAI//_#PmL8i(SuZ-]/GBPYXr5&RP[Wb+uanL3GTE%-$Jh4ZogW2Ek@ZTO9T.B9-79X8sQqTSt47s
+%ROJNu)*IA%Q[B%KLmW4jj>?pX!Vp$P'hI`f"Lsb\KOYS^d6T2BOj"lZ9EcMO0eF'0!4@GZJR\*YN4I[a(RqbiWuo\^HpY7nhuRa$
+%*+L#)^R*Qs8K!l]5TP^B\A[mX.BCd,d'0!JTbF:@niAYEVq;=qRB1YU&8fCT]rqUn8ZTiYAcm,k(O*SF^".G]aC&uu[aO;oBNX*5
+%_.g:llfflNWT!=@-?"?.O12kZfT?fZRcLTtiqOlZ"63[X+\\.2aP%9oS'hae3fAb8,@5no:m&P9^,L7R\GW14b5m6!MI/PH`mJ<W
+%FY]14)dg`^#3fm7dGnuXc`"p/_5/$pBHp[S<#DMNPjogF%1VjlH:.?aUbl*?4s7hO\O=R'UpX@?reG,f=3LJP1Je9R@:jH;?DA$g
+%_US8BSjHsJVfJUf?=kY5e#oEm+'/%G$&VXD#CO%$H()W!I;RMV=.#;/5_e"'#,ld&`O@-2'a%DJ(uBH=_3:ohpWEf#>9Ge0D'+5B
+%eH<9X\+LoS$;gUXDPX/Ph9%X]h=18$4bNML('@96Rb4K_V@5V8%dV8T42#EX@it'/g[<m9\XQR#2<)$eQ-I:<YF=i-+AgI::AGIX
+%?"g&)J]so0@TK'H1GiMl1f']uRj39d&Z&aN?+D>@8%ZLA9j9d8`lK7^@Rtt=#S71B`)DpgV2B\B>@Dlg@4fMlY4Wi\`:W=f2!g-7
+%&b6(6.sg,t.UN9U,W\m-;iCo%)9gRX>-en['99`[&cFhVS!hbKnDd'.6,p6Q"glZLO+j_^:;VIS<KrG:T].P_K!KLlGDR=7j0Bk?
+%EM$0;e8R`i"[J&#q*B.4Xk^hg.d+'f3jK(Bl&QS*pdnmp+$a$Gb+0(C*X0*==l2ei@ABX"*VJ>XP@-4V]i3_rm-GF]QRn/Hr;,Mq
+%+2;Kt`WWmV-cUqfDDn,J&KFueQD[4FGGYO_/T-PTngm?X>MlShNSBMZ'!V<;&#0G#9J(I,`XI1-DHo]u$79)O]JgeE6:>naHl0)D
+%T$WE,:$@Pe((^76H,JBCU#(er/G9&W"V?3tIEC:hP0M)8ahVbT6Wdjh)6>JnV_^oB<$IJTWgdB,F,@5a[5$`d'?d[YY19Cd9H9>B
+%W,]jTSW'5SfH+T#!quQC[W>?)Sr<\npa.>e4H!>q\H4);YirORX$!+(A:TDg+4[ht@Ip_G55BXfC,6bWCSW\ae1WEE;[(XSMF))(
+%>b2,m`nE>5%5h""!"j*C,gF3\<O#rl3hC5hX"Qcijn8GKSMia9Mo+&Q\I7R?*j"'IG.[r6![!R".#gZ3%YdW**\W*Jjk[4:i=l?b
+%HoD/dieR,'PeUGMp$%5bRMjetc,h(^7cg.oKfF:/V;mN'AqJChBjkCie^%s$44E)i(hBkQk&M%+k_!"nrU:kG@0R7<?[]JG[m0)A
+%DPH7GD%CoDPmcVRJ62r5"l?GENcDt:KR1`pk7R:<.:Yhoo\KWLK/@!6c920#p!=bs)>(%A?@s!<\h:)$RIT#tO$Lm[rV*3cX0:FT
+%>1*Gq3u['r[;FS&*%0)YDfe4pO/:quGLl0f_ch-JEci1>jV%bB<5QU8R_af\%<gm%(Fe+JY@K26<^Mt'ChK9h..kP+$Fun5`><Aq
+%gM5]p3SLLt0331.&&rO=A7k^3O96Mh7ec8modY:#]t!82-FX>^%J"VQfc!`J2*b@AiNo#uejq"g3ubB:BXUBrP(;4`O(n]6g&91R
+%Lr"qMIMd9oC>8#o\?cl+UcUmu2M9s<Ju8;C`jZ7@3-Xs+Thd#JAE?$T,FYcY-9=E:b%?B.ak?`OmZP5)MCh8(bgce)&R<f=(e4'&
+%YgfU*)5/dgigNO]:ii2o#gdOb.%sm-abEkFi"`[rI)X/&]0-?XXh@OQ=)fC0V)m%3,'m-W^c..W6/u_r.a]YC@XKbsoeMVsA1VUU
+%;hT9";^!mi,qc<em''jq"c_!`RE!lg2%hjOHs`+]'H,(^_PZ_@RdXq=CYaATN9NZ6$=aAZeA(-eZWD?/L*Oas-DR?-mskLj5#%K*
+%'2dTfJl#sY+=2u+osef<M$=(oEEJIbFrPTOI9WYm]\/7!AK50,M'"pnfkcWr+lmh;jg1H$BJeIG73@P&r#os/S;!42lmd9b86Is3
+%=U@NX3B8B-K"Aj"l\^t.=W&2Jj=6!(ls$EFL)M`b<a<]?O5_`U`3g';<AbOfCZJ2T@H:(1q,fLpjS>.CZ@][Ql?YG=fNa/.+en>/
+%dArb>p+7@-Qu*"%-=.]'@^<gM$ZatXfq!uGF,&O"S!QK4[cT/+R2I]Bh4']qAd!A.h3?Q]4bnO;C-OR,!^,DTIJN7-A(:Z2Ec!6b
+%CO@l$Ccche2ggeK_Ma$`'\>S(FqXCiZd6H./]m#.(a)0'%mS#6DB=BGN?;@k,:q8TGf!6iAkent(>u<YlXD;/L8C0@\NUY[`aVaG
+%BMV6)&l5nu9Rob,#%gZ<YsnFeIQg'Uan&;j.Um6k_+H49bkb1CpU'qVSo/V+AW6lGOko.,q^4"LUN,mm/MehSobb>[JEKD_eG0*T
+%=gH_I]afR-_R,!G9CsS1.CS.43khH>BG[l?nb*oMH0(8d)oS9;m'3>EI^8OKe+Cg;e]$2Ca(X*@S8dS%08RR`hS=Pgo'4c9D=H#T
+%j)F<"'qe,Jbk%dhARn-H<@.cVb>N7b#Y,!RDMk-gl&8?7#N22j$8J=KjFj*(Ho2\SrDPNB"K+QGEm64C^nkt'B"Y@6h^/"Xk`5(j
+%8iP-^jHh/l\oD+6ULthHB"7*`ag^FJ*T!(u/UX7hSJT_t)AqU.$Ga52rr$5$@MZ^9r>o,'8?5f1c#XZ$QNib=YucfBP>m!5gsaCg
+%\6K5DKpfAGPcP[2Nm_c!OT^;iVMTW:$6mKAh-RTfo7F!DY,*!9!9)A5k>.edmWPe^lJ%q(n.Ed>;^3<pmI,8F:rI?'.JSbJC/-[5
+%DEKM$a'5TrNk"TDg.#=`G;_rRRS]aCmh"k!!0#TBFsL=#\9!qXi8%#Prm&GT+uLi>p4*Rh7gX](bH%InKnoS\lruHH(#[BQ-_Gl_
+%:)6j=^p_T.6X7u6l0>[5dK\5*+`$aX;Q_g1T/bNl:://@QulV!"Aa%bL4sPkgKPrb@?n/NYGAVM4LW*,i"F$X>Ia7r:>CEG`[5LO
+%92":NpjA4pnE6]K#oO'lN`Fd<E"Dg1oj?$1S%2cL@T:JCQ3$U)K"M(UmS4tA:9-q.Da4U[5%F5b7#r.aNilAbXYP3fA83M>V)EmX
+%.`*I<I)WXn'->9I*uGZDba0Md!>bo2T[ibS`^!T]iH.FfPInV;Y=.TrOk*6]&VV99+e<b9g)N8qXPlfY*M@9#(X[!kEb@m^g0Q\G
+%Es;f^E7e<uSP\a:h?ErSE35nG.,>*t8+p..,7.=1Q0G$/B=J/&gtG$?1H8<-[eIiDH7)WOCFt1*8/4@=7sLB.l-oB^NhaR^9gW0M
+%HGp804D((2T#sULVfM.,4Cf]]_F1K`Pk]#SYP]qJmg(SZoOb;6#'s&`1CLY)r-C=1OGbgQS_&O@K'k&n`-8T@,k9,%a=OR=`9=3-
+%l=&@m]!D32G.JgXaik(*Q^5EMikrZ',>k_adQe@G85P;qK@=@nbqJ``JU%#\.^&2SUdS]CUrd.5_UXGAG]Ps.D;l@3kl9c]a+&N2
+%V58Yes8DZNc(B7ZF99Ea2GhbaGJl1;(>/qN[\:11%,d\1R>djde&>_B[W5L1C6i[M\Ri^7V8;Bm;o**%XRb@(AX.Bn+=8.QV"<>6
+%O8`;q<d]_FCTj"DF;:HF&/.[\>(P.I+3KtJPsLkof]Ysq7ZiGH<j14uiXqATj0/0>6h5Ce$8'E&NNnUtf4Z2+ED:aW(IdMmpiC;M
+%:_GVuOt($(Y#K6fc5Is4g-P.DfspUg4jno.7MJ7-3d&n*W[N]RM/J_9!,;+)!eN'l+%mO&Lg+p+R;@;/[!hG?d=X$1iV^8#<-X.M
+%Na@Ku@s-e4?Z.6nh/)_r4oWsAV=cZ*`P_9nUBJr[f8H9?g,>GIK,5<D^6'k"iBoo3:<W;Z+Mi`@1hN=^C-J^P,@Y0*[WS=leDdm`
+%5;$NT^_#7q%0kb1%='E.ZpU<LK/SmeX7R\sU`G(P87t'+d=u;.PY&MCiKe9$k=OS9[?,1;?g(feLR^44r]ulC4.nm3BWJ3U$UG]H
+%b1S0U]Ej@(:Uo-/7Al9^RtW(!TUW-HmoT3Z09Q9#]_e7:]hT8)Wtk34F[UU&^?jt1,L[fsU0mOU)BGc!0]6Q#$:^]P<SCAsrO&nI
+%n*=_3&%J/`m"26oBq1O$iBF@Rds@1T%O@JK[TR?InGb2Z`=&V<JBU_j[Us8,b/]?`7*T'8h@,$HNO99E#Or$qX0_Y&j.sFk\##&)
+%o"NIUMkdUPU:*d@DG!_RZD17qcr`ul8r2mpp/H%nVT5\lE2<8+n+gDX?p1lcjQq]Jp=JZ3[79F`8FX]9B&OJ]l"ai\:0Qqi/I_h,
+%;EnGXX?m>UW\9N8-D*aEJ]4]_=)a4@mg(WB.'DoK.1NDS(hM<rRQ7*g#&M-h0q=A+@*et>csk-G6dL\j<@b%Npr9XBQ-m[#WCTpn
+%gJTnr2RI'3YKq4@U'-##_IE#tM/Q#p#FG's?_t?gl#H,&j8->3M!,VfN#ilEG*U@k)NT@OfBOtC+;C7^(Mc>))Oap1_&O;81ob"U
+%V3&J/<_#)k/:hS(2,Y?.^qht'G!sS>D*0P>1b&A)NR)FdK1$fbRr\D>iSl>&Lm6n<nK?(MWZFl./0:V@=k9Uu_FBWOZ@=(goG=C,
+%.Gki_"09NdfE]'f'P??+Xgj/LCCPQO1%fcPN3aXSUO;gh9:UpfniU0"J@]T?:`5rXn;($SdpniOY^2\J6>%3<6,U:GK(Z7</k./<
+%W&rOt;G/X:HN=A'k@Z;G(/g-FI<OUT(M$mKCkWXNXZ7A=.SIET@HIj8:YM*gT^iS$Y6\$Ap?59RO_X.EJR<OqFR1HIQd)hF[_Cs^
+%"hkp&8Y>9Wj,o@i8@Oi8>7o,ULln4c9U!V`2BhV"9:*g,d'h3\Gf!i\DNLe1OD,p_Ej!C)C6cEWa@>`Wktg?&hLXcKH0VCNPr0Jn
+%Qs.=O(Je#.<pQ&B!\Fp375/RT&Qk>q2C<3-clRT=cr[.m3cqRQ\rfO&^`"GSXd6b#*#^4!)RMV3+;>/[dop6b)$(RU1NTNbGoLVf
+%)d>gBoqN.KYTT(_TS1i6%ocO5j>iVWF/_f[&0M1=gdJAgC%Q9e?rTU$[IAG^f$OaAL8Pk)V036Ro@6cCkATaO+g!f7"2!.(G]bH1
+%n0NZlPN#N""BS;0_Sb`CO?4?t_GoBOL.WY+7QNp>iP@T(QW9@0Q6]i?67$O#G\0bs,)^hRKVLj93siIEWmIR=>9K!KPqbcib!:#J
+%+j:gn^6\[]D&mG1`P6o3Dq\)K9e!>eA##BhFI?><^BB^LOP3.tO?U,q>=/hGTV1=kY7TH&]hqd`W?`:JBkrK3]!TAjPF]btj^eN?
+%kJu*TfuR?4-6&qS"e.k,*J8WYc#Ppk#A?[D/A07H;*m'E%p_4=PEBdf;\KXuZQ^q[(^&6JkL#W7XsELKXaQ,1R9*Xo8uYp;'WOa1
+%5+.R*HX%>-IVBg$.s&*-Dk$V(K:Fb`4"3gK+CII&9Kr/%+d`UmR((_nO2eTV0MJi2p9Ppd-Z*9$kdI8-dE''[]p'j9"H2g=fH7HB
+%R<?EUh5XMFQ/&7T6iVBkA8'%'WGV_=T'k<Cndq597/ls]m9tlab3tRb-e^P))t#u/gWS;,JQ*);bhYCWC-o/"HWa9(e:Ro82u>+h
+%LMF7kHnr)5-[0ZH1BKTDU0*N^7lYZgO4IrE:6:d?]/Hc(.I`nr]`))<`G\N%MV#lSF`Z7aCYHfF#89@*+1@3op1e:<'0%Nu107(G
+%@5B`gW/ZYWf_b'5-A`]b`[[$W'0_S>*bg"cY7Hn2]87\1!sMPVE#`uSMZsAncEhetLhkWb\rgn(IL3XbZ$01FL'i."YrWI05SMjR
+%Z0Xg5glc93%X"<,3pYk#'\40)#HjS0(<<MW`$JP8\:%A"3Ha?TZIBd24\aJ/:_N/9)VqH9S&$8WD`SAQJ5h%6-ojgVLB5cL\5>RE
+%PtpRWN9Mk3[5I)46[0:;R$EG9gVl_o#8r,<e[TeM)!P>U<*[qjJ,s,Sf9j#&:n7XQ&5nBsJZ(=ES<Q.F%Z3=L%_osk+J/uPj;)<?
+%F?O_`4Aht3)BjgONg3Bj47CjBQK(s'<\1.K@!kD2JQM'tGX:[MB``/<b`,HC9H+'SS)%o&0Y4A20]U@*WY0SfNN)GVc*7dfo^gKC
+%X'_Fr#E]JD7[dJK@<oSA!1d+E-4We1C9BDjYKqM5!cNqnM*L,tYJuj"[LSW[/C)bs,&%?4a80tG/lL1m=)r9#&ckYA,Sdc\_-o9<
+%r-EN&OhZkqW>X5-7CXh'HG%-6JH?H^!b<+U7dqN`pE;;6)mKW!c;mSj.kqLDM^=*65S9`>msR,a.ZLGrE.b=oa)NGWW_1GOEQ1aJ
+%PmG<R#t6aXCslEagI^O-H-k3H(<'H5&Yk^U\>B9E,m+aJ'A3K=&2SP"T9MeD(@@oYaiX"`=X;S,j[pege0[4)@jANuFjTMja"W(\
+%61LNs4tQI0Y^;74=s?s<02C=*VbQ`BMb:$d7*DW@H`t[S%_!0l[9a[f?d?W0_D&B=2W_nW8FmO#8+COu&;eWl:k`,c/>#?4I!Ak7
+%LK/-4`\hG!d7:a#enGVD`CE%hm]FDRlPkrJ%fRc0:BX<)>9i&Ug6f[kUl71W[iq7S"mUOpKO<PRN%<PBkI2g_q#t.(oJZS4h4kAl
+%<taA"+SA95QPQCD85Kh_X)fI_U`rHAnEQ)^K,qk7E&7gjY'FMr\d26J1N&Zp=dl:N-:VADnOi5]N^G5M'f7&CR?MK<E_O[I@!m^E
+%7\DEQGd!'+kM=i,qGG"rMA!__T[A2<_rN-rN4c"3=)I(SJELgh]@r2d+O[a03Z(0rb+n7k`^YQK`aG!T,9=^*]$NG*`#VS:CiJ^_
+%8\uq-5Rt`MG!kIWa"<mS?pQ:P)jiR<C1JT+,Y8UOpbBjGc.rQQ!,4_\\#9GL7-2N7DBiA.Ji7A4@uE7BJA"+`"4S\=&f^?u(Z]ma
+%LbLbp_q\'-3q!*#>'Ok^*oQ=fd#AOmglr=L"*OI0FHJ-EV'CpNe0bD0H?R93TL[-r6`rDbk:@?uedA$*(rQSD>6B,O+Kfs9"1\io
+%1_?-O/+d%3Rq!gX`sU3pT2L8lhXPGtUXh<*Ffb/gG'1["+S>>%_D`[*l:aA2a%g%^c#6bj=(QP66g!1Ph9?nL]fgkMDp`#\"P+SM
+%amhTtN_8SF&TrBgp,H<^Bcu0ep,#)`N1K7cJoOG4.S9uRO=ZWVYO\AfVC`-1n<3>nYXX1eZluFqZ%lmZ)m;.K6;s:A/`NM"Ca[t;
+%=csC\,"#9W1!T%fKp\8PNML/;"KKQTg6"p*kN*T1A)sAC@$lf0A7&6dZ9frHR2Yig>(cru#,k$D/$Qi>cp,CIdNfK]#]MrVPfq')
+%V3OQ-Rfc)'3epP>ZfML,8&s5G&L1A-;oW]7'4=r`/rabIU7D)8LG4+,FnB7/MM5*H8>u7KlJMu_aL.iVMLYbZm/58Kj,2Cnia<iI
+%4*bn[KZo*U0rTK-Wm\Ua+iG;2IF\UHN'K3uK7&t?AJ#O%>XGc"bj)_LU!/5AO]UghE:"PK12]O73,l8DP1HQW?Zsn8BhV(:NNEZs
+%Y`XjYdZP*<_U.!T;T/DUQEO+Pj5ZJ5fjmK_`$nfsE/K4[q'J&VLC+r=?.XUj94RL53k.`MEG'tUB>s-?,i5V4o33^8;VH"fX$6F;
+%3phshSP'3n_Saff>K=slCD=,Hi:!Y(KX4ETY'hXoqPOf/NXSq4c=#3,R@ntB)U&Bd@tdI=Wgn1B%m@2KfpH4/a#$uA*CIf,YRsQ$
+%,78\'iq<J=,6?KL4_LkkOEADVJN6#0`\sQJ,^+.@\;Q@FlJtn56QeSPn>1R%D`G0F1]4J"ODpCF`FK8*)C(Y)$2&r_p[dcB8V)k)
+%c5SS8pt6:e<ZVElOBNCsZoZbc"rN,Cm+>CXD9^l4XE[=O]+fHCi\:W'/H`>A/L2[%]5N*_hb!Y(^&]Y%dOl#&V+*O%6fA.a2q0>2
+%\*f_Y"Y-_/bC9H!4+C@n7H2VTqoWnCqpHi$DRU%cF'<:D8<4/89PrQ[2F!P8,6W`[M3nthmtj"`/2X3.m#36OV;\MWlPUL+:#;8m
+%m-=cSMDNF`CfF9PD%`-/QH&e-DPRdF,2R\][rGtlb9n5':4H@<`"nrKKL'gL'Vdtr?h+'DR^'lCGVSMhYldi1k8(#\`W`h-3Xjas
+%iVH;BMjf]h-c),XirXkB*Vd=1rAY7!h$g`pjQLMM#o\AV2D,5/@$W*KBP1t9:ts@S>L5<dNW@2-^n,X4qguQP0;_qZmF2_n&i$[;
+%d(30o"\0hE.qnaWJ`+!\P!MRWSt=@sXGXB5LsENZ6&/aI*e?Zm_Z2;nc>5o6Xjg?ig"a*9mr!t!1"d0?"cB?bHXe]0Io+nB3(Y;(
+%jJUNDOaT1i-^YUL7rl1E-FU2=O[%QN>?<>--=KCU;SNa.Be$GBN/=tD+V_01YtsU'1W)%QA5>/-8cFc5.^#jo@7%nkD6\*sO^&oD
+%%U*,f.7c<E@s>E.6I<[hO'4?LBT.p%U2+L,"al"8kMZu,Lm/COW-h^rS#"Qi`[8R)=H3L0!c78W_B%r&cWo/^]H\FeEAkV`a6TQ9
+%C0K(NS?R$hl+5cFjjhBDHSN&.[$\:;c'W13#D9IF@Bhk,SLbX9di$Z&;J;:O4-!=$mhkeWIIAZ8-lYZN0IPTjI)"lY:@;=Zq1Xf$
+%0O?i@HO>&n:;pL+-/NoY?t0]0+\pM@O2Yk@ja)9rKDW#unC-!mHp'Kjc&md'*$4F.<ql'Y7$0ZF*0Es-)I3='0B%.+Ns!@22)"R^
+%*@A4t*AnF(D/hi&oS^9V,"r&e"E+r1Ep\lXT#kZX`hihu@WrFQJ>*&*2_>O*<!M,35hN's`9`<0$LF[4RaUUB,-a5p>8e#bS;_OO
+%jJmbMabZn4JBPa9*P,/6d<Isa#Y;"AMc3EM>@jY[_=neGm*;II.'`:DTkQp`[#pU>1t,1qfF<n/&a%M6CNE4(D"TcU5sh!!PZ]D>
+%Od0"J`Nf&o4"5ThetH9rQt/720V:1&"&O2tSZMp%D]mOUMb%Z?"W>L$7GD6*U2@(*WHMB!<'!E/j^E;-N1oG$rq<&hlnZ`HK2niu
+%$V%@X;bC9s0.>ptno4BVLP_=#`H<%tN_aNM`M)M7MZ*_A*OXOQ6V%utJhQdV*q>]B%&aY:W^uWt1mYDH3#"jo&6n@'ZCT8T0]k\j
+%2[XD/i1qWe3ul3a*@TH:>\YnGiWd%cKu*?2IN68Cg9IF;-^#fY+I$=9+&k))k@jX^oa-4i5s'%M9QGLQBS+Y0joqVN@VOD=9#ZbJ
+%o`R\NZ?m-=V2u2CSk1)J<T?Y]U#tXgMMI!W9->W?G'*'*b4Z1.(THgKIUbt!%PB/F/0KmEX?$!IOTDaFlFm*H4ADet%Wpt9fp+Ku
+%dQWSZ'4.f)GBG;[.&Ub;,S5s"06PRGNGtuh`dO69BRgObgMDhJ?#80&cHX7'_8B1'--mVAerr`H\XhtI)*L%-8I3kJ_GHh3gd6_D
+%3O=opD05I5jJ+;[CMQEeUH#87XYGmk<u^X!4.;5dHu)]!8Y&uFPt#rT6Wgm+7iE-A*Z?j!<0i$U02eR5qmSDeTdjO0_2ec5%e"=t
+%9*b7<mM;F2!=Bmu%0Ip5g`)@K=+02O;hS*!N7o<)M],.i>H?Mp6<;dT4S[Fq)3sORXJ@M$gtR?O+[>VeB9Q85.c3g#I%Qc-A2n/X
+%lmZjWA=,5on#X$/n4<3cD-+pb1r="*D?juQTNnGu]6^bFQ9NF.Qfl1jo-?8um$hdK"LMN"7gV+,Mntna-`:;lh7r5=e(/sfh>C_K
+%h#@?s9Bk(Z't_pr-OT2lF1ce=M?umFkkGq/+&Be8-ZZNK)W%CNkqr("l(M>(7dj!#<6N[e-'V(_B</(+"-hX`k`Hthc^^$>ch41*
+%9*?oT\0Af0)&pp^+n-WAMBcM`%V;]PDMSa!P4Rh5jrd"JEX2F@l41rB-D2S&&0Vc$9VV3b30(h&@O14X-3Na.fcj%.6KC`hL%p&#
+%r%+QjeKo?,r+5;mOP6/r7)H</Br7'2>/Cn_'@ug>F.Ym:AC=LFa]2/Jkqf_Qa+jU.c'&@<W2+V5$Z*-#*?gNUA!mmtaDlDb6PY$e
+%ii9&r7*mQ0%TFpgE/:`34](Co<L3sJoZ1@lA5H08-lsn6W-YN^=rB&s0jATmV,T6*Ol-]`o]:h1;:lT:H#RP/"'OspTL8fsL[a%&
+%TJS,!=V`E$Q'p1V:E,_YRkZn&AGlQjp<IDN=[]gt_lUDSZ*=nBrAqk(hTBaU(8kNt%#,^PSU.Tu!Q",?F^=at8/qJ;.?d.SlaR6O
+%`ZPC>`i%3-J\1R<_=t(@]G:$3fmR9148a8"0i8l]\H2c(I`-Aab9Z@:7']c3V_jE/kA8/+Un?8o&-7*7Fa$'j9#RBSc]3f5%QJu%
+%YcTNDZr"Ef$FY4]kZ3_LACdj%W#*AUor1(k%!'%6XAKGoW:O!IVu!(';<B0;P&iG)(^\eH=:FHHoFk?RLKVht$TfU<eE?rf5%.3n
+%l:sEseHf,0ehbbt?i%YX7YVt`KX`'DTtoW$$bNP.e_<r-.R@WeHA30'&e-"=7g%e<66I>^UDpn:Z3-:X)gH@&c2_r/88as9poEsT
+%>_uuJI;i!6E>"/?+OWQk8*!S`iooA=8g>_q_YP;"/u<j5eHaal)B,WN".G%H,A4D]U]XkGDegVFDmgCcIMAS8da:#CJ#)GR!'5`Q
+%EeG=j7p36HRaKZ4OuP&fR+W[^i7,8CB,:-#[DOn=eLE7::t1rj/)h*il1.V]Te[ppM;ZAC7b`%AP;o7YiOLqM@Y+'M"99t7J#lX*
+%jqk<j`\blI?!&>=YiO^Ss.3)sb_;gtN0.4rj"mVn2Th[Z:`(J8;D\r?-t4cKG%&q8T'5r&3fZQfDB7:fa(^of$eCT'-rVT'=X5#I
+%nfsT&?/`IW(kT?_d,I4C0C+3M.:.^EKdne!7\8*DN`=F/aslOU[UrHCjZq_W_c94[:$6SQ-4b)pM/eQoOElC`\I'X:FlHW-/M&/^
+%Z;.7HJos:(,5gtW)3_<pL%T8#.9#bMDJ"mVf1q]E&]?q$_&6MnJ:PonA^fF2g+oIhRu!$GMFPS1CIWnH#>f<ude(4BF@khXKQ8!I
+%I.E:sC!X:]lB6>m)@)7Sg+K9a*'N5*8@N1"o-:W&526kG6i$pndk]d=N`l'RH5%j/Ak1TKku4BBLH(Zhg8!M<N/X-X%@AStDDebq
+%3p2i=?u.0,=eFd>;l[0@LuqdfdZJ:<_<7BfedZu*NN&P*TV\W"%UWA610drAT&1c"[4RbUXlF$c"*n&j#Ttd"Q5lZPO4C3W&`[R@
+%o2mLTE!G]K6ED*8E[o6,qB1Pf7fmQ;Oc=rXYAUu61(5NXhNZ[mRop&oW+t:jm4TC0RrU-S0f;'1`1h04OSrl^91eD=PN)(JKBho!
+%I&1thSeA<!!Ie#JNT+82F;!*"W[39(Ku1]KP1VKKN^>rcgUr//)<Hfn"!LWdlBeaqN"eR<DO.A"(9GYb&A+FdKmFuASRiEL-sIu<
+%VC?>[&3/.3Qo1VX=uMsh'(U&Ep?]$Ze<?t6>!hPNDRiV:caT+[HL-)-_pT[Q5\r7Z&"r5<,F!P&(&SoK59_cf]$UnWaQRBH>$De^
+%2&0Y-AQbePXm\^L`<50IAQlB?/KlVhJRV.9Um;U"d-YNV5n/J1<d%p\>SYa-/+l9-gk)CF(\7CSf$TWOp6`P_=p,a%mNUmLg.1D[
+%b\':JZU<)cX2FM%C5gU,bbX#5MZlondDV;u_a[:M^(HQAF6t^KTU)7JEFCk2TpSs">Nqe'\-?h@@90o66H+l:UFX<+?<Q<gIQ2Pe
+%!9t,Y7q5_>e@+$0]OeSVAZN#cNl6t#\gYH=Bq&M05@,-2C16MZ'+kOW<R(uJgpkmXYpGrbG7\d5JoPTs\,lNW:0;lq#lP(O36Nqj
+%CT3W3!gV@LY,<IgapWd[aLV^g4XdMpTk4'QD(K]1-$E$9(rT-/<-$jIi9Z=;p[Pb2;L%d[:E&'0<XSW+eTpY,,0+pF%OW&j70q]U
+%7l^=LJgkP1R(Aqm\+<EZL?R9bM`KS<?,t4"RYbam]&g%U@)D-#:R!4tQo/Z87Upe-`kCT2>Q3&3U=5HHNMI%aph7(T,'n"Mh_r$'
+%Wh-A(cPd4j2C$FPC.^cd4.HFOA=[+nF?b2,\\dc5<f/"snDgpfQqqiaZ<j*+!#Y:/'dZ8JM3=%B2ll^c&HX\gJe6<Zj*2/S'C!6b
+%8FrT+f4,9;>gbp"b,>a9<iW0ZZm(b"X5d.,p_[p[\npJ[oJAf59T4kj*.bahXe2AQQ#T#s32]>-6)5]+CQ6KMGm&\-J]b&fVcS+/
+%GRE^^pZ`q-KWVP,@'Yh'H=/,#a^iasR%"#,>(Wq";G#/Cg4Q5QV?%?rp!@0bMFsb6mUh/MOfI*=SP$q.p4Vn-R,SiB5ZE')"(=.)
+%8p2+50bpe[S>k(QEpl&W\_/@A+_\2\Dht,)'t0LI>f<lEc"2Ya+ZGb$+CJZ9@?E2@(Oa"%m8?A)%O!\@Ct+>Y>`%rD0HT<:)U(J/
+%I#h"t/<"J5p3;2;NKiJbm85:S5hl$ZDR&09nfEdC@Qf+>;UUR7:o0u=VIh(oe_`us%%"!gIdC-gfj!'0fH[36Qo2:h7JBE`N*gZn
+%A;R-dMK;lZE=9KmhQ*J$X_f6s8Lm`W[oC'+Bq[EG*#nll##9e[jjUfO\N68=,7+D([hUJUB'+din$+,WUK(FN-e_;WV9M0nW5QhM
+%%<7LY#a*f;(3F<.]UbMWJ"ClKX&St86C\OMert;Wj!rO\XZCBFWGqQu1`;b)6ai]TdI'\\;jei.]3/acOh?Nj.KgiW-u8:7=<Y$$
+%fqP5[M@9W;J@]'q/e`Gl:j1TN&Z7WZ\q./i5Qa]+Wjc^_U@tf$K='9r>3_%iKWF"C:t`)SmZ^Fq;?N)f\[BhsQ'3`%Ki8qiS&UVh
+%Qc;XgX1^5h^N-S=84P-dfO/PfUT61LX@=+fj@j>`2OXY<h[Gl9#tb8U@Pblr3:3c.'>ukq)CE1YULNlKXkIEG0@OH]j:Tj1P/t%"
+%hBeSQf.5++^l(r6-PcB@M==c?V#Fh;rXoNC"nVS.Z^144Cb/<pHETZ''tFRMFMn'3MUXSs&P\-nQ-#k"S/SgY'#iO+BCA^ZA-R+E
+%itQqp$+@*jr2l)&M^p6uo/Kbs`83>&o\;ZePWRCpW!t#3L<5QELKaLE@3fM4=$BW`gUX>oTiG`&*0gPD`TiORAK?aFAei9Cg;rY`
+%*cf(.41il/;FOIQ1VZ8]8--1dp(!@HUKb$:X<kJs_)U+6#T,^0^mX\t'm4G5HKA<e'_(<ZKCXK5-($_hG:eM`KTETG0XJJ>>G]6a
+%,k?ba]I_-;'@p/QmR`\b@<a9@GE%kPODI;%e)tEg#W9NH%BC5M2K/gKmVAja:uMgFGn"(aUW.%b#t.fj*ig*8W,8UTWrQ_<4kZcF
+%S&d<!QX15pTeYaAk<T[Gq(oY&E/?;,YUJi2+\Fh=%$`U:@I)i'BGJt5NKHbQTF\R'*nk?3.]DSNIe445&kB#tOs]3d)Ok3cn4/DV
+%kA,T504>uZ2dKNTIZ9dnd[7Of2?R&XorsJm08$"SCZ:YcEY=ceQ3M;Q)\+ZdSLIT+^/85g+b;r7*T.M3<4WHL"%-DgkN!j-p,"!c
+%W2l9=Q4u&0.9g,"3;s#=PtQa$jK`7<V!+r1#obnZLrK_1h?I&.2ET\p=Vt+W<K4duCZr3&]cR6K*XQ1PX=>[bH!25F!g4LE9%p')
+%8JSBRBghAYe^>cX%]WXa)`iKmO@Be1NP^*0)C`?rlsq633:LSqe$1OTQUkAiN(?THTHb3&b6)`=9eer:Y;3&.]""_U!.f';G_TH\
+%s,>?/Zbb>AC/W@/Z$%&TDM>7.ge/%`[3p4.$26GFX##Q:_SgU5.6<h%<#8Bpb\8!t]WAEbRr!a96@j$*Q'3`:%Z@_Y?R'ecQiKW(
+%l@S=-J@2#Pm%/\i?QBFn9W0O@?-!"Sb*=+h`eD5P,Qhu0>1WB)bq[q/2Kkui@J9t+&NS.$-k^j4;3M7&'KVf!5d?/+;n@#r\n3(g
+%J]i^`*LSrq?ilG!Rt;$5c&pA?c%)/O\%LZ52&rg-YAkqoQr_@0m4X^uBQZ->b"DJJJA>c<#/+D7)6+)06t9QXK*oai,P_^?o27%t
+%#H!;,G?MWuVq7Ec047;*:-:'2!'K'%aFhCkZ[h;\lY6h,/%bi:7rd3dkW)b?iBbJD83KX]1iCEW'gadJW30V`^/EKK6R1euNcFBX
+%7V^So:b=4HN<CV1f<4LRQ3C^@Z=W?lgXAd0TOp^@X[KEBR62;I[c2SW)j?9r3.eCBW24!l(R8.JDU9A]D]=9hIGKPcf"t9s!9[se
+%jBue\U#6O]6+_5dhQ%\%,J,H%%)l?uX/drD1)4FJOqV88C7O>3G=f#99&LL)H#W"jg%[TrM?>RT@\K^2D=5I1K<Z"Yn6NSJfK:)M
+%i`848\!'m^9VkUGKmNfs[Z1C2mPT&#[Z3bf#9Kn:-?6g6+jrGuRSk`i<A#PpQ,t/Ir`8"j6htZ.T^6+2DYaHs_H;jOV[;$/!$??O
+%2_s6$8m"^"C/S&gZ$`kY\9SeO3`H`98o_5+Ll@1SdQBT[\1fZWkZ1,g@%h3K#cKl/34CL4=,t'+OH<W*EPD%d,;L[^'kfq&G-oSh
+%E4*JdQ=*>#.\+S'l!+HoGMfbI[%kHg='tUY<X7/9Z5]+[CApEjX,D8W'G"Nf'L8`b235bmF+99G-JLIh[S^@1BC_:5a42(6>%9pa
+%7<'iU\b!<]-fS.nYZ,;@)C./Vi!*7D)_L1r!a(?r>Q@k13>SBkB"jju"0AKW)?oM`YrSc>GM#nhW(9pIq=)3^9_:k;UlK>8*,]BK
+%:kbo5qPi//!ZnKjiA=,k8qB2F4UEKmo(AK7psB,Rb,o//jegL>,?#hU!;t3I*kkQ&U1k&=,c3%S8(OX-NF@.nnA[;nWEZL%m?Cg\
+%6"I6q/G1pp_K@&dRUQ6@+]5N]rEb$T'R3S&rGu5/EU"d98FLB\Ls<k&8p,+:XGlK'&Zs4TqWJm[Lt!$j.e?-2YXCfFQ!kl1WE>"8
+%1.d?AobtH%3d<MQYOsW<)&sk9.Q$ADp:Zbip6A/NBnVMLpast=Sni!$&u;?=/g]KS<W:]"mg,+X\ADo;j)+?(pJ"f3;EGDDm)&#g
+%q6ds$$/G=#<B.'\=eUVHf^q$E@p1ZY/(37p`LZ3rWNr,OO4TW?qI)E9h$S#-Hck-O2pd0q]^U0XQDL^,c,=;->(YKN6n5HWA_u];
+%Ks93MA*cEW98+7ln\2%S2(+?k&L*i]9XO_Bd"^i"gb?:1A[E<mJp%Qe8l]?`V/.LS;4EO;?Q(6?\P,`;)!3TEV7,"<4P`]Y`W:EF
+%M6-Ij!glf(5/Nsm+3VG2H-'!Sn<9<b!oVpQ`0:\,_o`Sa[c>;cd$`J(`GmgO'7$*iga8FBoW8s@;Tg]KLGc@=BiG_q2$BtH#?_JB
+%#e%@-NW=SdL;r\3cEoT@b>X@Bcr3'P)d)Lq&`hb"SZA\l4!m\og&,Sq^&,FZ9CS%)PXSd!?Co=WFZ6$1qMl4.Cbp6VIDdEFdP3Z^
+%U^f"L_h@.Vl])=l`V^;"^K*=g-[2(b9Yo@-on*aDRmk1hlUW#887"u(5-0j'kftJtTH$epkfg:4):6AY0p?TkF]Udu6Zf@j:Mucd
+%;M]=`>fFF&Z:[.p>cSR*0Z,qlVm^os(eC/ZO?D5d(l[NG&(1IBXH1+LG@5%^PT,)*OkkXmN:Q[uW`s;]rK9PNB.VZSoUj?:bI`0D
+%"2eIG#&AX`.:3K+SSrE($YuM5\p%=#@OOICGFf)p3L)-j:EP,%nDS4OmIV%um)Sso_uWttFf9c<XQ]cr91S+(+Ed&Cb19FG!"r3`
+%FKQf2=*X_Qh`O]5S,/j3hc[Dpkqk"e<IKAl!j^RafO'Q9G&PBu5B56$=n`&!)4BbJs5`dT\U($k:PH#k)nRD`W>Z@Zii@$E2,UaL
+%iXR&+\"Be`?JM8u;@lMR@fm2lIRrlp%<<<PN>F5!W<5st(%7(e"$%H#@c;qrjpMd<MK;9JifP;QUGd_IpA.7MDl_WH6f^Lq&u?=*
+%*X6E.Qldogj)jJ`DE'.`$k0(Jotthm!I7HimN4:S-BLTcBPhTSgjIa?^<FTb):;uN)5W11f4tR,p[D6Sc.+cqXSC4a]Hro&=rK[M
+%5]]GfFsJo<(Hu[Q#r9Gr?T"#TL`8eO.`d,XgkL*-Z<Kj\.AF'O58kbl)E.Eq$UZ9%P#;1QiN&E099(=H^g_#%YnZF<'hbSA`=L5H
+%=i-'6eR^P<Ba$#B(TlW<DU.s$`79)rG/C7*W!4q\5t9r>:dfA71ol1K\LLd6P=9$t?QJ=l^uGXVc($</Y%Y,to3N#&G7$R(24kjf
+%NHDUH=JY'&+\jU0Z0Yegl4[k:'9OJ(Cr6deoooiL_,#UeH0kC:`on`C6[an""\!8RK^*m2?=kABi?5ZR5l9fr%;H]ICSQT+rn_.G
+%^sIB"^?k-Mjc_""c'[j+eQ"Nu+M]ar.a.m!aT??;D9RF;MN:I?-jfW]-&1hdUP3u9,MTXA*(J\;4WT!be$`e6)n$M>0kW@i8)jRQ
+%hpfsR6gX@Z6H;!+J![3Gp[km/2+SrTS#]]i&pOjS@jG1RR_F$Xl530!AiSjr1%#>bY;)0f(*SlnfMZ,VAn*TX1;+MZ9Le9*9R8PV
+%\"Fr&3p8pG#.H<Z8k67Z4.HY'V#u:LY[n]K*F(ab^,)RRBUVD2?>*?J2)Z*d&QIYb;^r&L-c634YA9,)M`+aeE-"Gj)'Z1Dm09Ep
+%lMt=e<L.q]GT/?e$5._2f[qJE>kLX\df+SiNYVm]28AD\cIg+H.LV[j]fkp!`2hX,W8,Gf<YCL^44:>:hKUU\6EeJ2/rq\fqrIl(
+%IH^@(]>?3X+l"Rr`)&8iBlt*p,-E?,Fs)GT:Q-4?@CRiP5hY)+&LB\'7)KS)*a.qq,5i<0,062IeJ>[C``<A%>dQ*2OfXR>3fHTs
+%gTF_aI][JeCY#=uf33lqrY1%7)?h.4%!h7CN'YLB5cHY#j:^iV.<Mae].,m+LQH^KKG(#'qRL-s43SGRna_,8)bB%`^jDY)FT(8@
+%0tXGGlE=/\b+aWY3]D)B-+cu/h+Jea^a=5AZIrDk[F/t"0gj6k8HbbTj&*uPeqVY+aX&6o2RdQj?.p,UDK?QFA2t[U6F&0FYu]L]
+%Wf#C[Yo90R61cki*XHS/@?3h=W>)q6E'6Trb%bT[TYVj;7aeDfP)+$S-Y>f`h#aWnlp-8&b=..VX@1>QJ[?P)@mC4*Mf=NQHh,1p
+%7cWCVdc@Z!+X`'YCNfjEA,_eUf8rPB?;mcfB*YJo=jI0BO\.HK<_W\:k+;(*f*']M,!E3E<+s\rKD7Y*JjCuq'Q3Y5@F`7SRb"Er
+%.lS:3ohO(@jeR4!Mr[>gMTI,U@jG?8eZlIP06YV0ik!CffELX?.moi/DXagM9$%O9]s3e7j`.HY'<:gHR=b*&Lur73,-7SS3(og3
+%(52gJTV<W>kqsU1dPp.U_Ed?FMlLpK:BNhkh&E@*ocrk<S)N=@Jpm$@M"f$3O,CU$XZX`I%]DE,"Bi*O=,_%7^YS76dF)_'>%rX<
+%=rTT`-YbNi[R,8ilkE)jG2nan/tP(j$]mhL0'kq.C>!34H\qu/1$<;5ZKjr$HUhARWDKu+Z3!^tE7=MCfRCjff#]1j.,Ogb2U<13
+%#;d<od0qmHKT;0OB(@<cOh0kh>uWa_fb?M?TCqkoMQ2YY`u3YA<H-*%Cd0/(L#Fq0%-Ksl<I)PuAr:mi1=Tde73/+>[2FrmLE^^h
+%1$<-1-n86%r_NpK8dKiMnr85S="?WW4@&ktL]^=?Ipj@=PF2uK\Y(0u5ZW%q,M-bN[G?Tf#Yf*i));>>Ai5H,]8hf#7;Bdljt\B(
+%>..;[!2'cYBkP^7G;^)&.^QNL%GC],8_a4.RA1c0F5[!WZ"dLM_IBKK.(gjmhiknXdnFJ;R,fVNH/-s<-)S'hD1LJNn+P"*.J38l
+%kcOV[3`*Os'R0<0mDu>"0EB'!U6f,0g,0S`?E_`;%]WprLkmMH2'(C:l4M2&BOaYNXK-=Md6*e+*I[7`*b''CYC,,[\9[blEDJN6
+%RJt]/HGFa%$[0/6*k`dF%bMF5266?-2Q)Q_+#i!jl*.gcb-9K'^TuN6+tatO6F#c+qB9>([?9#)E18X!j$r&Qri,!kFAGP9PA*4S
+%kRs(&6(mOKN#K!.hAB.La2+du*]>lTVhsMm"'P(HqZAHhH_\QP]Z#IU)VZCr>?op>?CaY##=uEao'r&kGOoDE&n\\A"E!D`/qSu>
+%*48,T$it]H-&dH"5JLcPkU-isq04gG;UdDG<E5]43!kS#^C1;.=.%\[?fquQV4/Bu6G*]7YBZBZ,Sa*;+[`B4RdmPo6PUX`<_"D&
+%N1_=KA:W*A/j?JL<eAV4>b@HYY-SVhmnZ@\2O$>X:nc_4d!Y7+!)OufW[pIGeK$D`,-YZFo*,Y%<V0u_dQdu"h11eh^Zb6^Uc"NE
+%8eYnaqbZE#S3mmWlQdH>(,N!me*6B^ckrd(6(j$,,+ru<F.\.XR]$\0'eSQ>794R,[W5C>4g`+:%*6M'UU+@D`R)WD5cYWi&QXC<
+%P=:D'EuN#67gTN*cr8XVl8o<o9^b5_9ZnUn)Hl[5'a+sr?R]QXYHOtQG2*tWUr0]"B/[)CFaspGY$/IdbUmdM?(3-*,>Sd5dW_NY
+%`![ns7dQ/?iG,M5j\SPDg32(D6[G1f@iiZ/Oo,fh=^7*.%b-%d9U6$j7_Yrl#deSd-Jli'%p,W"_cfT$hC*'Kd3_sclXp9o#$Y;G
+%g)$e2.ekp@A$I6d("bY4eU90.41nW2,<R7J6n%u!ccBJuF0&!8X%i3./Q?B=VUI-5[ZjTcJ34VujiB&thOJU_$dWXGj7@Wc>B@s:
+%2^4TGOI+/m#rr0AfT.201I65rm1-R]c;f#<23(<E\e:MR_,sdKO0%q1oSMs+YC>,qUWMj[&"<4NB0dd4\!D)6P"C!Z'ASJZ7$WFo
+%L/[AlVbK1gCVP>B>?4`O1@_WKec)pu%.?a4B+l/<;SGj^@^jNnH4E4i<CX*ZX7R_`2c=a2@XWP4K77@!qt@UE%qgQ\SWn3HrFqO7
+%=1G#^YSQ']N!OGV0#J8<UJr5t7^iuNi2j*L7KY3+Q414#&%jq[aCuZW47BQ::tqj''4_;/0",7!>+iblmpc30g?@:=NpC\<SQuQa
+%R<GC>p)V)T'=t2Z"h#1#m61(c)k?B&]&2pdSU:Kr_V$u/b?$XhZk!l[_P@FRgptfDB\/9M1\>F)O`_)!_^4<S\-B7E1fEd*D^K<K
+%<L$m\:VYS-A8)Lmerb6Nk+/cX'/-//H-p>"N'(Dbqr0Mj!M\fC4g3Oh]kK+&Cf)YJk!:BC8p7KL5+u$og*7j0gr+sm3GIf$DFLG[
+%WmK;hfj9'e\#nNEP^e,MrRYt:kHi2fT=t+!PLj0trO2.HmsXNn2g=`'s/d.+*a_)/o[ObMIsUjq++Nk1(O&ZY5(2tG]AGZPqHM!i
+%NrT.,h`Um2YDn&0adY4B?@VrE?bC[[g#k#;n($amrq,k2?bL]t?11!1A,kJ25QCAf?TnAWeP#i;#;:Pug#m$ok79fSd?!2?IJ:u6
+%YJ9lagqA48kG+Y6qr7CC5<AdRs7_^ikq3r6Pl9?,?QC/:E;[VGhSm+!hj(flhgOtjiU0Y?bO7PL;a!C'ZPj4je$FB4%hp;P8ler\
+%H`_&O-=*@gF:ldPe^aZ`iA@u&@et<"goN(&I'm@.PLn#pA$;s-R9\)8iRshC[iX.\A$\_]%J>)0h*FcroMb'j3Or-'j)c)8ae.'5
+%29,\8!N1hp#ocVaYDYE%bFs^Q"<VO->41e?Z@(hAb2[9/j-t8]IJ;"PcT_BVh)c^+nG_J.(Jiq6p#ZpuG$A_Omerb!YPpW0Nq75H
+%rVl=Oi@s!RIP/AbN4^b0ci<7bgrE0"Xi8+GB*3"MFZ4,ae9fNM@I;[89M^_I;7B$?5R,l0F^%D<Pd""bg_MZnCJh<5BAg,PY?gn1
+%NI(O3*hRlM6iXSYq!mkWht]@+J,[R=Mbiejo_ObI5C7Bd$8HoA(IY>hqsP&EoLr4t%MN4Loq)2X1W=8<VoK$<c[L*ih%)\op6Ntd
+%U]4SBVD!$13aUb75P"Z"V#S.\Gk'C8NaTZQLUtoIW^EL$43+aP6pRnX)LZK+=0FM/2U99u+s""qClZs#_*Ck`jq!_V9<;g,>B[@Y
+%L\20Z@$SabiQ+r5:V\$>hYgItWu[`WR]9k7N@]FE/lX6Y7\qUqV7P*f7gJ*",_>>Ne%$9Z<3lL0"`#S+'f3Hk?ns&iD2Y&im,g,o
+%;4[/$%sVT2:-_*G@F@k#*'un=ei8)2d67Ffk5HWVFdpL4Z:LPpHA0q+_Au@<DOg@H"GXrtW*p[r%-(1T<*2PIJPn9@D'&ht;IUH)
+%j<YFC,>#M-/L;&)W2K>9P7S&3;;9$3n!0/F)^uT%;AfRr)V*aWcE/MG#!a-E;)p)Rc0/>T@&ksrV`_C2)Q`$-d$G=u<^]>To#M_^
+%nOSS^OX"C;I#(f5.A]uE#h:b\F4k3W$m;s4W5dgR_22T[h)LhP*?15==$C!_K$sM4$<\o-KGppH,*L?5-cm:7?HZTgZ8)MKgh]t3
+%F((2aG9;+BmK\=TNuC<ppqLBeV1Q4c<;]idTi+QQh-]<g"MJHr"l`VPlrpCkN"0JbY$P6f#W>b`&#1Zl+BI5t73h(nfJN`<-aFJg
+%X'jIs,mV(C.@\Ci)kib`P>k8r:8s+24,2rO$j)6=d!fe9V%VlH93q6d?JCXEpD/>_<Lf+D)Ds@]]L*nXP7Hm(X#jK=6tsq%<cm)^
+%`Y2eG5gbd;0[D>u5)>U2K1VP@&g>jICjg/fTBiP#gs0p"2N)j%('_@[R'Z=Ng"j3-Lq*ic/ERuaBOfsD*=`Y6C9<q,1o:T5&boG5
+%VS(`>.M`1ml\]%i3m<E"39Z(eI7.SEgDsGs3=$[`6.ZJk2L04ZI@+r`H6:bLKD/NMgq(_?Z%H1u]fT/#5AiQ9ZZLp[Y1KB&qu_/f
+%$=)\:is6p<Pjfo.Fed%\EsNsW<Sa-9a=)X7"cX4lO![l+NG<fZ#XJXt]I?=lKo215"4`s*99&kOd<FG9e(0_+e_;tQIuQL7Dj&1t
+%D![XkG)"Y"G"g58RUN!=-'P;3S2&`bf##q;8%uJON63!(U'\h4Bp2)c8I/Q/(R*_$\4q(p5f0L1=(b`2M`'sX^VgUleZlm1]9)u7
+%M\s1=MY3EmW.;?tA'PO?_u0eo5%d'9CAFOgkLN<mqKt.Gf['#]iFKTIHa6*;K.F+k(MXp+X$R<7E+92OMX.Y+`:E"8<r+/-)f'[@
+%"aaGC!t_<X[imbqRpXT3D#O"^9q_U#r'KLq])J'cV'jTI07SSuA)ALVh:5$,hGI6B]_1mq,AsW`,jd[Y!6n`XZ*1k.l@%H0CDL]0
+%<TVloHh!o%CknDV[VJYMWEnr^nq3p$o6DI_4,&4R-\n!]bfOp<RJ1<@=.W$H9#MG(?K[XtoM`GCg;sk[hTfc/KC8J4o^.]<XtH&B
+%T?#c"d;GKP(N[m7qSq>s4UWT3P6KX+@D^$QfiV9bmqb*$?E%J7)*H<)UFK.^PFI?u"t0iXCdfd*ClFRs2*nHg1<hWg9f$TEj<Q&h
+%j#ENVQBR4SqbYdMXL.]<QrGgL79"-$V`66),.e_l&g"Ffd0l.=_P8IAYo1?WIba8B<0gp)/2muQnRNs[3AeXmPA*1P%<h8NXJkO'
+%]N>&EVL7S99Wc9jB=C140ptUuc,UCiAsR^c848"MB^t2q87KgNoI_+(\YbC,G)Kn<5gP;tPiQo$20*lLVUkAJ3bO:CK87,sl,?L4
+%]c^Kb:OJ"Fs1pc>1Xoh[\:_lBjGaOW,gR5b\?J/k_2]e^nj[7>jmIik3qk`;4^E@#VN8@b`6*X5ijB"C/&tq=qV/<qN;.Mdb`s9R
+%p1lmAm\uA^1\G_nZ8,'Q8p-*4OqH+8<nNH/UN9r#)OUfd"mlP<s2nNiH`O:uaho)D@RLgD78-*5jEM$(.'_cjk;^Xafo'hjQ'#q$
+%Lgdb0NfZZG_-GA/AWA<#@RIFA+aq!I8^`FiY_Sb2Upe?5HqHF.]!Xu5A4JHkPqDF#KTq1<AQtC8C2tr!@qsGZ)6%-<9c@1%\4,\Y
+%Gq`-OW1F3.6Qm21`W*;"OtC.$(0Urqn;&Z"j5AH'KtOp96(Vtk$nfS<`g*cPON\7afDS4/j`/W<hMHs[S#iYcG!1k#)K#AHX-Q-.
+%*ZZ;C?&.Hd+iV[noBRph26A%sZATCCDTeb6(2b]JnNgd@=#/5@fkMkCPpuO!;!*$DMq><jg94L0W.a4r8)iUjW6t8q$$U*Cqa/<3
+%-R>tX"N;b"Lc!`8XAJN$Y@;nUWXm9IOCW9LB8=Ga,P[cMFr&<>!X/*S1m`'_Me(F5^0P2\eC(V-%m^9]i9At'j/OKpgElQ+n_<AD
+%J#:rq1nqG-^97\:l/IqhV"P#UZnhk+!EuSjoF\SuXFAsX!N)[hbK8,;Yp%N4im(;V07uF[o9$)*+PYJuXdfi%-h@$^q7R6\l:6sU
+%2%&q`3n*s;&X-$:$4_Lj]Q]#,_01W64&sl!c#tet&J`+c(%>pnlkI?U\Il;-oP.PO0M-B=FCDt`JEknoJ@/m[;9f2c;$ZLFabWjB
+%ZP5>[$mq<u9K=UTN&+I%FQ-AhEZ2V"D&WP2T5"GeCig=f'u_sJ@8Nt5f4N4:q'cSqP&n7/g8i]50=+]%=m+RpJ.X=E?BPH'\L`PC
+%^^c]N/bRd[n$>hG]?@79EV%_jd,DO,"U-k\F1uX<eGs+2cU+4.]RFl[T.rd#nOB,I&/Q?[NK@:DToNrrrDT`76dt\NY$5"%&nUZC
+%Cmu,$3uIP=LM;"/>fgo4bjOumZG&,=NF^]#FE_]"3f9of&9,6L74^K\*;m.W&1u(nPOq4842LLH:nWGU5O'Io8>SS69-$WF$n.?W
+%o?S@%ePteS)LKRC_&!)7@oZp!qW6NtVcnJ&,cl=I]G_3Ak+<G\Uaa:"MH->==cuD+MY`PAf+pVlOLBasW<0grQ(pA&66`>1"g9=[
+%cMW3uaA\+(iR4(?/+"Ic4el(>$S^3VI&0PYqstb.^1BtGT@jX=R$n97Zifa0LZRmJRR[u`pZE+^kE(',/c`lKTJg,2'"(Rd]_>5H
+%7IM\3V`%rI=6"lAn&?p&h9i82U$cud_T'O6mLpQ,.L*ND@B?5cOB#<C_Tr!">\0L1@&p_KT1:4;_r[u+SK?s@P^mip(Jf\Bl`4[=
+%@/&nWB@l')ND&<kC).S*5J:t>k>*U\Oo28&`45h]eYR+f?_:">>cd&J1:,`CD]*\i_tGr6ise"uHVTd8J#.b`XF*/-2]YKQ.^NLg
+%;ZHn[EN^2nJYW9lhY7a9fuAH$gQ3c:![V]^@Ek%ojn@gC_L45q'U%%U\HsFM2d&pTDEID]B5UrJb'dT4oIEeM*=FBo\fDnD!IJhA
+%XE<iQ33Bj]G)WOSnAV*!8u/6Y$-=:5IGfpWTY-^u1\9[e]4`M@m'\(;<B-Lb(/8Gf9(QTLLLLTmPJb=fV3&PX_HZKHF5Q0<6^E,+
+%O]G6U_F@]Hpru93\baQ?>+,<s)en722B-?R"u[E7i<q9>eqHTGCts_KfW=$8Ek&?E(F3IrZkmsrZcO$5ibZC`>fLCC0*K=9$PqOX
+%_M;7OONhoO.$E\%/]c%f6actES,9Xe/=WEDJ1h^ViI]0f:?2K+D!pG;hcr.=$`p\FZ4#6i3P>e'FQ"DsaO''G06#>$H7p\pKqlA4
+%9:K/#&5LFK?Z;s%@)9]TXiS?\=`"1q"j+=]="F@'(>N"gY:U0gJ706[P6E2c67`L_k+S/r9tL\cCe1uLjOl5*.ibo>jNbT:%8XH"
+%9cNY@"f338G7J"tLqXVjg9?&W/@H]*:ZU:MXO%&eBE[A,(SL4uk-/[$>=`;.kcir5>Ynpj:KKc.JS0qSqBkcQ/$m_E*?L0pMUIac
+%LQ)1qY81ZjRK\`)+"J4kP[80UYf'?";#5LB,e,@jh7UJ<a*%+mj)9hF<up&F6,c'jOol*531Vq$S@^GuL-W/8htt9,J65]IklQg3
+%\hD9^nFZs,1JD$F-_MiIT*n3Rq*psJDBCaVas8"mG5I@XQ,n=B06K`<YA?bSAtP*:s#8b!h#T;#Q`N]>&R+3#Z24a@+TDU#1j;8U
+%CPi&h>=($2(O,I'pkBT#=!1"u\?TI>jiFkg#X=kJd`H)mPc*-n5j8iZQCLbJXk2a$fR/L/..u8S^2bgc]\t2h<=*.BXt'Prd*3Ng
+%]m?6>::)f),V84Vcdpe/$m'CMT#`VB$ZW5?Bp<:/4.U<02^?F!Q\gHLHhr(EqHQ<kZY=-q%$IYs6hFJP841#$Gn^'VHd'g#-m\.(
+%fhL=3ZA!!!5iMg.0u$g#0tD=K9a04p''mZ$LoA:8"Ik@cS0a^e2'aN+GV0Q7aIC6r@WatS;nLS#=]ak%\<$S87D,^1->JUCRiJ-[
+%Ib\P]cAU+%d6igDUZeoT&Pj`XF=;"?0\LWrD=V_WFr%;`7J4Z''Pb9>A'UTedG8*aaF9K/kb+'hG1ICJX1S_m9qL??[QAf3/*AQ(
+%Q)eXUNm1dr+ASbQ>is!:C)eIZ^E\7b#npk_PZH*?dp>@Y=1>HlU'+g:ErX:kqrAd9Xii.1k_=Tg;*bW<TtSIN+M!atG#.8iK`I5(
+%o#U)2iklp5lA!pn]`8lc3q/S-R=*H\Wkej]o1&Gc'^8AE03Tu$*kYB28FfJ8YUB^/2O;7dV@"fHBdeVYE?,qLj'3RON;UefUoh:_
+%0;fgY%;D4j>Xkkt5IuTG")m&9IZNcc")&nkUnrS_6H3P^V=UZ;i7\D1KG<$kM><Fm<:(W(VUn9I%3q9URR_K(oT9Cf;n;`V`h4MH
+%L(%h=LZgu(H%kSG?#4^5hFJf9:*=DS`*2DMJ>sPVZP#OTVu\HiQQuAc]WkjI'@E7J^=30'i!Pa<$]JoX0sYC6Sre@$^6g)@L-q8&
+%GHp&a)?%/-K-e#r>j[&\q&lTA5o3CZ,Z)Y9M-b![!nYdR3^cOj+u_P@_b[Qr]bFd4[oeh#&G'?dBI!hN7H\O"\rHY();r6A`K#B*
+%1f+:RL&Ih=O(co&H@jteX4,mp5bG]+dYM0l,cNaTrSir_(a5f4IsE"1/Y:pna!,g"NePmS,pc"@KR!CR)cfXZ]i55'0W0UVYgR^j
+%!Q[al..I`N43cYF0?OS2lI5=;\rZ5*2/+lE>@0cRQM0Ru)9U)AQ&@dn=kQ:'NjGF#nlB>L]M@s2)nWltXpj#%F4aRVC%r`+SCIIa
+%(],dVZ$O=EXt%1^hEe:Z*Y=4YRZj69k\,X:e/YC8?W*IYHI9p[4p6*(8XS3LVmoK]o,J%1bN,dt)mT"bD=%#\8Q).m:HlbXKCdN_
+%aOri,<DW80><eVa>cG^B>L"+Pp8StZjD,mDd?Jo5SSFDBqr)B4"alHuW0\Y3)eg!khoL85NVXHqTpC`3m$'T+_'LF<U_QAJ9P3L)
+%'W5$sH)#eD#5%n4+=bC(>aSso^_i.t_o6g7@o1J%h:6B/[s5ngDN"07g/<BV(--5JS_tWJF0ir)Ledj'nK>p7/+n9V>B*knma+JT
+%6!%QGj57mK)ng6AMn:t+iW,DX:<euHW%KB$TL+GDTtlp3XZAbP8ld`U2V_#8=WeAl[_,_4(pfue,)IH%m(4lj%%.e;Tk5C@'Fk`.
+%G]=u*>n3kNd6Co?cc8'IFL,&h-P_ec9[JqN5)EN9$L3)q7];Fo1g[kQ3&AAP+uI]h]t6X/#'6*q%m,ZVe_W<>$T_YMa*s4b@-8kM
+%/PrY[f:&k@@_jOpm^(dsoR1;.2=,k%i8-Jh)nJlo`%1aO9db[TQeI;W4c9]S,Pu;\=$p6JaS@GAYbUM:Q*jkP$=RtROu^6Li!JO`
+%Ks8];[Pn2'e_G[4[R;!87)n;t9Z$s/Bh-u:bB=32)L(sJ?"Y0$h;,`'o0$![#Z8B[O-Hl:cEF"q`f-9n?dRW#Zg3]h@--Xan#%=@
+%(b?o8$f+u8%d&>\RiN$?_r*Hi+P@=BAA5lo0CEf851$,3?Z-Nk^e4^0A[lqF%H\EC^6i@k@rj`=9,Md%`W6f)Mb`#FGp0qUZCc'A
+%3rs6&iNj?i>fZ4!5i0s!hS+?[$Tq](s#)"f/]d@G(U/7\*iRX_CbKZ7aM/?FYs#*U=FA!QSq,RC$.WkXoBWEB!4d6!kB5+[<_\0_
+%Xa@&tPZ><"<q:5g/?j-?<;4muo9s)0'Tu)&#k9beo?PZ4o*SQHXQ+mmYkDS<i_;:7pZ?=_mh*3;"8)la*a>B&r&,MM6]j\+O!eFp
+%P(]>%i^RHa]L>?5Dbsu,)a3RPf>(tYg3"%BIJ!U][Vb'=\;g)CjuSV5<7^P]O!tjg4:L(U-j.<e$mFn%'TphV.+ai0ge'+@34_0g
+%+7DD300i!*5[^2efMsf^=o::PDrYY3OQJ;:'PEgJa4V"!M,(r`XFuO#EU"M*\N8kuQL-#!i6p&r+Rm([;S,Xh=iMuQFfQa,(7iKm
+%2nDIi5jXO252XFUo8q)cAKK.E*.a)9\7+M-P38h?>oJfLT&2nJ<`Fin$aUcq\tni%gNLUE!V!YeKpQ80(-o)oNmWW<pd#/B?erdt
+%=,'h6A`m8;6*V&4ck.^\!9f(uWS7.KT]Su/aG-XI6dW"<DmfX(dekVXas.H+ZJh8FX#j`RY4(E;H06m_#HDA,]5]/'cj1%jlKh<^
+%OpJ0gA#ob!UoAkZ)T]oU05)`!pBf;tj:Ek_gek2!4elgm9)q%bU3"Ge^(Mi\2mM6^b=N/h23u1B7XH-1)@9K9Q#e8k\JB2u[^D=n
+%-pBNj5irtpOedYn$imX(>7n'JnZc^PD-=C'duE]+Bi7?(hPFZ93eqa7gC6!pgS&\gKSfS?jJb\i_le2i8Kp)#Vqk,g'*3tunk_]g
+%*he>uI.t'roQW7FaU5XI!F44jKA.uTHsV1U5n!_Y;I(ZGNmKNtG%&`[G[p#04Z09)[?\0Jo,AQqAR1%9@gK0olhe1e;gX[^=L",Z
+%$*?1m%-[o2TJ_8K.e=.8o&'CtQ)@f'gkNTsUQE0HXXB4(;rM?cf(7[pGL>s=*U8)[U=OXLP@H\gmG\VZo@KRn]@_T06MPH6[^SN[
+%h?oVX7KU8?[@65n^9)%T'm!;+2K2g,Q"W*opH$1(3#Jgej.+po?BnX&Q1tKrA?3G,cS\KT[Mfo&cd.u\W^hd\e$4+ZM;2Mj^P]9`
+%'2nl/**)?udPL)-Ca'm-q>cqoh2C#Ih]jo;(Y43#e(9`;R$$Q<5!2rDBmQC\hEYt8<7?9`8c92&XUmmV29DG(E0O?eV:`KdgOd'N
+%L>&L>OrT@(E?f*M!l,;Q\JEtp(8CNN,joU(@:W>64CQ/rPaV>e)hC=gKR#-``u-&1PdOuTmkItt:6C0s$tQo%Ho8d[D;53?!5:c5
+%H@]aQE$<8+G.cr[3)(#OC-g#&2F<ED_%DH'T:gpa,_W&JX&($gmNZ,K;3S[,/^pg1klbP0\;TYna<=.ILXqIA6nhZrRhb6Kf/sL&
+%R*IC%Ks,\/&KR[D;EH7=:LQt>eTUcA*Xk+4&'S[KHZN8J#bm7Sf[oN-QGKn52];.tjYRi_eqtTBfk.NBi`q8f]-&*]1d[Q^A3J@m
+%9iA1KI:IB+jrhj$]S)O,o!tsmA%Thlr3o0lG,1eO,'HYR7kN$%c4`/h`!dPc7RMK@Nm\Y$d@XV8eOu=k)R$^#90*dZK^Rollo<Aj
+%p3>p'AlJ=#n`s7P0AcX%`>:a#;=fs@2u\tn]HU:31>I8i*<FLm%I::U.-4IAW+!\U-!&L=.9?'0jYIPl<m^^T`mrJ:aW.?)>clD\
+%bG.V]n?>^n)<G(^K)oc40c-$ipI6I=Y,9E<l6f<b'fCB?=dbR4`gj.P6KU=deZ<snd':,.3lAkk0Mt5n@YS&CK1bGl9-Ze1O?Bus
+%>_G3Kr-UUa,JR(je7#Tl;(r3r[/b'<R_-q9SI+e$0RB+<Zm@Jfm5Bak%%KB"#&'/fQ6`u=5,Z]iX9u]aNJVWV#n.`aI7q\>@Z;NI
+%Rbc#lc%:I)#LMW[a`jl"Ca'f__Sg8-@r=#?Dpj>="+YD][;Jo..@n-,3Z0aT5"h]>:oYq[R*M]@I0lG15ZIklK8g69R)f?'"Nnkg
+%p!!c_=LZ$e0IBf*8**LInM!EN)Q-60,98G60#EWfITgb!Tn60/"Wi[t?D<n!?qlXB?@CES77Ck_VZ;PT"\1i58c3!NXpm_epL3/h
+%WU.X<"sq%h(56A5Su1"825A@o*lU.[6;8*4/a!E[hgFmNI]=nM;?>ATT-%b"Ec;%GrQZ+[P%9b?*pT)^/EW%"#Z7n-7DUH.>@dIL
+%A7A/f(R#<t8:p,@f1&C7h&CO8(rE8e]2@Gh&p*lH+b*i;eInhdBek3l_30d/DgFA]@5I32cA\3ZY(ZNPQh3=d7&7Z-7butgpUtQ`
+%%Os7I.*8#G3[;?moU[4f@_WF_f3qZZ/qD=WX7auK^UK:lC\pTp#VL$f#ul`s/V$o5b*N<XV%Ap1!`R-k&N-q)Uk6QWDo<mLEXd;L
+%WMYT^C#B#T?e\Z7i_hCmH/#"IZ?3d9"FRPZ_r%Q\B%k:&ge2Q9Ml7i6po3K8<'MU^9!)0j_>(>6pWj@CNrClnH*L\KXg5RadmPKc
+%X]/$eBItEI)PBP!0u&?ERtkfk4d_[81WCI4qdql@-AMiX6?U-(q(P[ZAsD%Y<]34PG_p<+fH%F-L_Nege[Q-omn`8tFma(4WdrUh
+%gqUeMkVLQ67T_#QQ?59aQ6dC:TWW,8J(\as%%iB6YOYm0p+n#P3g[j+,k4c,^`M46cuCSdj,6p%g[pCSh6R(jg.OqG0ZVbqbJ<OD
+%dptl2LAg_o013Q>^Nh1o+$6fB0HQ9R`GgjpPf#:U(I/I+=Z+7>IAbV'+8k?U^$*<Ts!l`WLS7rf9fMJc"@gPVXr^eb-?&^re$D8!
+%k4?Co\'<=pp4'i(mgid=q9Fo==0FhOVYaT_H/>(4Hf',=aieUPo&fUXInpO'kO3odpMk9Soq/mCrFB1f9b7-odoSb]nUpSN21KR=
+%i4EpAHMQP*lXr-Y<Xd<85.u2kl!NHOP1X+0^VN$]MdcVA[m0]A:\::=h0U6VHM-jsSVPNTs2g0pD1]oF0;S;s2-k_$H_8!!n_<sX
+%[B..7aj1Ior+J-?jLC-*5Q9no,&JK"-bU<F),PB-:*^"'R9Hl6p[@,3p>XJCf[W4c=8PY(:]**MGAR"\NrKJBdr4G,J*3"STD\Cg
+%4I0`3p<g?urR_&Ks!Rj8htfB`lg+JRJ,=$ZXag*&q>,R+f>#%bqs2#efD`IelaQkgGJ<ShHqciun%UsT?iQRDlPk?N>CZMh?dDOH
+%NV>[8hB.gYnE]kK^\2#^r7OkpnGE7-fC<)6IJE*rJ+`Anht\1>l>QU:bCB:OrXWrHS)=&\I]NJ(J+-86r."Nh++4U5ocO4mRt(!q
+%J,)lirce@J?i=o.a+*^ts5K[LPLk<R)o(s9qWeZ1rmuYi0E:Sb^Z`H'TDGs>^]+iEia;[LJ,]2WNhnK1oRH^Ms6p!\O8nkJYPo.5
+%`j`_XZ[_u#s6Ronr(hh(5P8g\I.Z=pq>^C0s60?pq5aOpj)t=ps82ilB4(Z+fC2_Rp>1;r&,s'<j+%(+DuE:X"GYD(p\mDNhE+9/
+%.U<kjlHVP*k1k$jF(V9h`u+u>MB!Ad3M;'kP;>Fr,mPAAZ,th;-0Isa,_J?R&1"8X+AjCf8<tAh+d-mp1>T_DVR?.7)B."EkMA8s
+%%rKn,pY'Ddpoa9Rn+6/g2/Z76?amrQju<(Mf4nk+);23morGgmTDf/spMAO6I0TF^@fECrqAn<G<l6P<\i+lU]7'c2or11T(B7a?
+%>3df3)VVsg]Dgoqci$Z;j"J@jA@?>SigDptr65nE`6Z*m$6*]5.Pu%j\D58QhYH'$e0=ma"nahM;kE\t1hp.'E1XQ<k-n.]Z59X;
+%qQp+oF77\]=6&,Oja$;Zs2u(hlkuQd#tn"ZYE_hc;q]=BAGbiqqBY4t1O<7#;MOHHJ+fnmX]%.Hg%T^jp<Pu'<CZ5qPtSdcH^.F3
+%Cq[i2dU(/`rdXeC++EXErP^<lX[Y`DP4^VLV`/I!Y@N3sT(od-rqrramo<E!)X5f#$ND94p3N!9mFsKNQe-QZgHWIJi\UW.F'_k\
+%B'gLJoXM'nQ]gfMp[6V4EksjZqUZP@GdH=<Djl8ZeZ)QKS=)',B_AqH*BC&sXh6^9ZYpS,]?$UocE#)lIn<1\Th<o"kqg?RWqTQZ
+%kC3G3aU4m3a"i/DCmM,il;b)kZ1d3A?G:O4d$DXL2qi%Ydd'm*+6-p^eB6kBWgM1Cr3D;d2CtDdSc2*Y7pdk*W(#1(IYoNE\6^dj
+%*FADTMP"3i4RS,uLC`iW4fdIeWHuYC.l?R^eZsM8%G#0M<iqQl_+n:EWh[9jGkU.]6XS+&=Zsa,mk:MAp$CSL=fHdtf[Elt3jgJ"
+%WP0jl.Z@JVm+U:M(D!^=db[diHa,I27h*S?REl=NTlP8pep8^Iq7QXH%6r[jc+SIAc]UROT25GLXlIJoj8(UTT+U^3nN%PI/*/e/
+%<Z&77o_mS#h!7I2O)'p6/2,N<20%cC+g"B70gG+V;R9qHj&10P?n>>ubbh]WJp6&IEW*h7jHWZe)"QXuR3OI[k3$$rQ#"bnX,32+
+%n!1q3]o[m8=uWlrJY\q:[U\JQS3<TXhAJ^6ZXNTZ]cXPRX#=\4V;P@a2i`8?\6SUNV7TH)\7jI?N;ONUcW06eI/L4W7J"0ccE+_2
+%i*D]DIF9_CY#cMMq.Rn0)?&m_B7L_73+1J,8R5!Op&"'GQQ3ON]^"@A/Q4H38c&8=%MKU1><&l\V%c'Ll*=NS?*J_5O=GPS??5Ph
+%PP:^W^L,AQH%T(p_4]ISQd$Dq,0r0'>-(.S:]FnAaq*5EH/)V>au:,hY&XL>NgVJ_`^PHYh'OfOFRdje2%&F7pj`08j<*i6T=8h'
+%2_2m+:48!s\C9G)2hKAeH#2#mnk$U1SN2#qVk;6ReLJmOa?(!F9(ZH&j2d?'9*Q[)"BVF^?U5Fh>hV'5:!u0(7cV<,/RPb.poHT=
+%a*nu8ZqC%!^@1^ij4i^>9%@_7CccS(Q/K":Sldp&WA'$@p\f(,WmBikA8qLr;c,n4D8>=i0&=0dm-?+&;S9+/n22S2#Of7th1E(l
+%F%4"?HHfR+B(`GY?*!%#ec!Z5UNT\[rgt:Hp>Gr#,ASVOcTlDZcJ<mtkSZAs[XCt0iO>/RGG"TnL5i7s%t2N%_,J\XHfSPQH7_2q
+%N7Ifl%t$++6/oaX@G%%/n6,K]YNqr2r:Y$Kae*GLB(LnZ*T%/:'DH%PJ,ZX68p!,?hfB[TlM3S9qNjqSX?!mF_Rt6aVp@.45<35t
+%nu[95Cg&rsDKm<%h\*D/IsgLWaG7IaABL4EY\)ZS]mXdRpa.LUD"Ve81NMrT>1G_6]3_R!@,[E(8+pkgebS#T2/2s^oW&.j#$mY5
+%X+%hmD]\pn@[$"(HbIZo4"nB^jZYZ5Gte.Kla3.qiS_fkqcAc8%*[TSm?.BQkfr<0*-CL0d/LR9<t9X:0\WeT8L\\$YO;@f62W)@
+%=MFP%`RB1#ogoN)is%,Bcb*u)p-0f%Xu:I@aZEU'kB>'`)qpec>C?4jq>9fegHVk/)`9N[IXfecj&^/h%7YSQK)b#0/^i*d\jgd,
+%]\R)^!F.L&D]N%DWh,[&MtR)An9'%W0Q6<KgEA>e#!H_qq)`fHn!I-'P1./km?!ocj.51A`5HtufsE?/mp`V.gp<ZC3e=:lG2oR6
+%r3"g:V`)k7'D@r?qg<_R>#*A^*E-]B53ia,lJ`.q[mF4Z@UGAf]DTGZqQM'nNN'psYI0sSj-[$>a#6\,X6--SK2s!##2YX$e'l3^
+%rl8CGp/L%`ra)<gH6k4$_$`/m\FCq_Ym6Whb]!BiWl"4CW)r*C>l.siXR$;Ll,jE=qc!"/f+6)@*9R.1k6q8P3_dE_6AbH*1oftt
+%*T-)QnX`AaW5Veq;,MW"q@e(jGND#uIXKnj!uk.q.6D"VWI*!'^5-s#k;<'qK`0<I7;KAGP>O?gJLUi3/b\T;kBD=+!mUGR^X$CP
+%r3DfiFtO`!JM/N4nuL6U],k500roRZ)a<_fPqWi0m34DlGOF+Z>e&u3DY)89F0O*U?9c*82bjKFgK?V`5KJhrDP,Uk@U)ikhZX1o
+%ou!5,Q,<rUVb2r+DZ'LteLI]4p$CJ0Gh>7'%LcrraR8K<YK!7&iO#5JoWHt2kP'H\k5A[J-pQuIW5G9ZpFY[mW:,&A<o\qbrOAuo
+%?dbBc+5!c<mEijtmJTU`j+,FcZu]8h(h-[ll!)Hg96aP+h=LM.)c?Xc=G;n'dGi9]F(X1.9X3^ZjO\;&[TW8IE?AdMlonrJs)sOr
+%E%>__hTO9`Y9-l:%>4AnqIA+u^QnSsgcK.m0'l^ffI3jbEJK=k=-Hk2]_kfVgTK5SbJu3*YLi&%FR5s?/P:_>>B.SBI/;EVc[-I`
+%KT\J7mCelhM8AZ$2braBXiUj:.W]!_D9=ZhCXq/4manj<aln-Lf<T5tN12N,>?srL^!U9)ri=EFa&WYbl*Oj<`:_/g,eY^q>F#\3
+%<3=d3n#g]Jjb#'R2(ZiE[dH4n:f\iGBT;jOa%W'Y\4ueGa]`u6f?fNGr4%%afpp$ncN!&!mA-(Ss8Ipb<FW?`D3Y]Qn%uf8rHOTM
+%1AZqJ4Wq(9ZnFUEZ,?(Q;oeO/(Rc1ZAM*l[-G4-=@!^GJFbVO+Hi@pB]5AWr4hQ0DjFEN$hW3NR]mY&NeRIK`4i^55h4m`8F`0/*
+%4+?J55qO=nJb3[6?Gc0jGK#Fr*jt">Mhs+!I:DU5ZEZ@B"Qk9ZQ8al-)-%b1J`j%DO.JCPE:^S6`XA%n%A,ao<*&+b&k`bm&<+r.
+%]`se^PTiiBY<$VWU#Y#jZ"@[;=KK[/FYnjXfDQ)h(Nd\-'e@jYjL"/]ZDti'^s0lI5F=LG:]7L1$[5`nr(c[^UFZ2,O<gUS\5`be
+%`P:d5nPo[D>tr^!MkkR4,-Z5q".Y,4(.5"GRa`^6MtDC^c6F]4*8D_nF_30gH7S0uTk3&s1p-S,eV>ct9oHK@IbHTVU;&XWYj&NZ
+%ir6K,5&,it\k&TI;eJlHoR=G!A7tQ7@+(uK<Pj_oo-HWVH>n$,a)*")NnO>_eVC=r?ZtJf_G%JUb$&gV%>cV4(Ni)$nV%lE-dJ/=
+%Ufk>rp0uS=;3T&pBrELYn+Gd<G9:)CrF'eN&*Bl`l],3Xf?E$NHY1dI?`HiUVL$;U6d'gRK9bX_G/i#Tbn?$ZSE<2:9HD\f=V912
+%CqK0ZkOQote`1PR>#*djlt6$qbMQ'p`arA&;EjlqiD4f!.i3%aEpBHO)%#'.Qg,$Mrm=-AHe#Hh*khYX9hqqJNA_kr3tp3)V&^4o
+%'A@j0O*B,u/aGtdWRlIK`:86pC%6Je.eK4DGi!Bo:23S]"uF)\SPp/F$#[ce#HgS3Mf38H^?b(`KiqA@DTflV7s0;7ET^G4cmNVC
+%SC[kte>tH@%5,n,G>G92E*qu!&XtGP(;%.jH7_fJqlW*,T*m.]/a"jljhT82gK-oKR+*%`lJ(-a4s&.RDOi,&Vm!!>E+Aq7pCc?u
+%CV/l=Rdk;9?I4WPTDIqd:4$qtbCgdUCU#c"8+^_kGW>5*qmkIBSN=JtrSfgZ/R6!\`-!X-mA#RqP2Gro)>1.ZV`"r6%NjGDjY<0k
+%n"*cCS7^[AX)o78]Q]RXPHaVq^-$H3f$2C9NugE&jQ'mDE:0@tC/D0g44D2fQS6.'n6,5.Yg;0U=Xs-r&"iTj:FT2Va7/%Nl6g\5
+%?uraI4:M/b[r:-9*R7%(%P5b_mXO+FdpUh.A!+1\rhT]I-hR>po6hG)6e;jmDaWZOhdXCbiEanGG+'/#Y!//a`l"Zla1Ntg^TSG(
+%>GY*GnCbWcNo"dUlLE\7Fre17QLDu!Bf*PrYEh=lr:!IHik#DB<f/1e(RCh7(CeK2Y=?dJmJ@;2s5DB8H[`Pt'6cslSSORph2\::
+%qIUq4mj>lh2_=Qkps0:N.u!5>fBr/72Ct:[IJW;!?``.rkK'VQG>d<7?5L)#5i]IEa"]BI%W,W%Ib(Y0.6e3?n_34PqtKI1GPKgi
+%o2fiV)/dPtn6J#f?`?8/qV2s@S&@Au.L\o)>(#/@FoCUUlSn:fbK9XQa;)&u:-U&1-8/UdZ[_fZd9"$<HM4gnIb*Od_1&3mjI.h"
+%PEhcbl4JLe=(]h%+)X8'O8N=n:TWn!N0B,$(9HE#H?Rp"d8q'!2IlWpqiB#I^K8^W4`d(q_u&IgHhM:N-n>cInP7DALTWj&Mu6q+
+%c[7g`hk\SArp\C!c*KLMFi-hH2OmGrr1<,`F7.sF]8iJtG4jq)&"?(OIBU#Fq<c0!orrgNpMX<MG5Ha6h/h>K`iTnlQUM.^4o4]@
+%F6-['G&!$#]8H@[r9,fd$feCj]4]WN^8obV097K!$@\E/`clLi8)I<maQaih3QM*Blh8`fSYHG-V$I$Hn%*^`h4U]V+`6/[A%u%b
+%k$7[n@cT'F:6WEl[JEA\on//`7h1RHc3sCH8pqcIS.25CL$s>uq1h$ar5)rH>re8GIbZj04"?:pJ)])F*4`P.>W]<%AFAiioYB!a
+%lbacKgblQ.\Gn%G0kJhU?gYaK*a:e)IV@*+oj4rmi\.fl`Ei5`IP\H;7<P3mC;Y%,NrE3fn\KpmbD%n\:Sm],ZaQBOLiN#3fA1M[
+%Q]9)U_Sb8/]g(1qk#Zi]K58Lccg+Y6&)[%P^#@.Yru*Q&J*k17AReoA7Et0CNCPPWH0WC&h",T)?Tbo:adC9T3)JQ\,8P4tn_,YM
+%)t.)n\SqGZ+\dk@3YdS&lT8b>pD8=iEH_*1W<8WU:?YTR81a"O[="mO?g^!ur>5::#C!>B5.G2"Zp*rF9H>9b2'9MBlhBR[4R(U@
+%mbPBtik*I-:@6NC<1Y/M[i4o;E93*%0&1i;\(qQQ_FJcd=>H^kdkVHO3PSap`PC0-^--N1lKt58\t&YAD?N&hh&ASN1TGdkg7o50
+%L!$e@3r=hP#C\dZou?C2p[18eh_<,sE;0'cWu'*RpjVt7cf^>Sf=FSZ]T?gSl](J;qG1>$B'\<k5Fa]YqX"#N=)Qg)Hgee'S<Rs:
+%aa%jocHY9!592hupR=lmQHpH']61O@q2SE&<2OC(@?]h+rF5H2Y;U7r2V:mD4"jjKR!`2LE:3(l+2?_-c),V6Qd)!\G"Bq[<Sr5;
+%Y``)F/mGY^f=lllNYjp.b1pR/ens3LH-=d@gCg]l>ISG*\:3!!3KqGk)pk^0HDOMXkGRU.hrg7Q<OQ.d.d<?a#7Vb4B'd%t.B[Z#
+%a,CopYZo:SQ-,s=r<5MM$5H8c;ndX5MQ*`c(!;jn?./[I#UK5$]c`oRFPEZ(9a\/1jWkNu85k)D<DpljWp&.Ljo#6lZMsUumT'<3
+%DrZ(\+@K;9fdIW+Nh,D]9l_Z4Z;Zt]gIR"#8ks0NZ@2V9D4;muQZ&ALXCGnRqe[lLUP)]IbUg[C5FhQSa`3cLOQ)MK3JEm$%bX'?
+%Ls*5TUrS%rG>]dhH5mZCDAR:5,S5O2Gi21+Q33=[j;j#s*%CHNH"2K)ChC7t/<P2Z_La0^!u"c:FW/"fV#c&\CGu8EO/oNZ,EhcK
+%o4AT\nsD/U[>5R8!NHPOJ43LtCaK;34:qTpKE@%>)ZFb/iD"?KJ-%r.$RlZa?](TU7D?ti)F!4B&Af7Ep-[+Ei)K1SM:+<siJV![
+%KH$jlY2M.p(_]`!"TYD)ch/#'K]lLITh^k'XB0jAM#]XoTZcX])TCJ>9)tsC3LZZ:+-N8B(:k"#Af3VY/;^DZ+5,sH2.2X$]H*\Q
+%#d\ZAEB[P+AD6[DJ\s"43S63b#p]VM#*DBJmii2ek_IqPJO%L+)B>=?=Ga9#!F]Dp>"_t"JUr?-*eHd-e4F:Im%?StUt-So=AUpI
+%6scC:IXoS]1RTpc(R?Bj;UZ*6QO1CRZe\/&'"s3?)GGp^H(jXd&NBjDNMB&L\fr]QM49T?:e]He16p:j.TZ$i.JF*^MaK$e\fJF7
+%T`gDD&m$M<d=@Hk0`$<n68qji&of%uUZdHR;iu/L]ZU<VP&)QuE^BfeM/CmGI(#.jn:90.&QLl$^*G`\bOh1E72XsUOpk4VYX7%_
+%i@Tos&"ram*+l&]((L1?=O)=1l\*;PMb0=R`E<8:5T\<:"/Vb;XLg[@-B>"bGU&&-a&*%LE]?DdH';![=t$]i9H2WA5kF'Zj0nHd
+%"+:SSC_H?$Ja>r^%TqoD#7<9)M+hLQ4S3?]UI5%!_T8[og?6jOQg'IY5Sc[7?*b1k(f2#X771Dg7]Sr<ZLO:_$os`'l*6--3%7qf
+%hdT%3Y\>9.Z$hp$Z&-jI33c.T-P)YJf4?uF,'W#[M(B@VC<]\T(@l=C&k)$neHKXK&pd1t4<nHdi(#&T&L\DnW<b"U63]?H4#gRE
+%-eKcl;37bKZRMh)"'64#D^[L\TZp!4/mqP?rh<F-?sF?L0.p6/f-(J@0R&PS`tokgH6X:qkGZJ8CA!Ft$^m,/DQf^WR[tQZ+8QmH
+%;Y\HN`?au88E=S@3]%t!(3VX63jLn\f`@*O<`$8B();K!F:W`-XV%Hp4miZ8RUq?P$h1Q,UpFGhWr//:?!/'X3"+U\gEi^<E\\sZ
+%6,*[q:14Um4$4jgd=M;<0RNsJ!eQK`2'(BiphEG[IgVuFN<2Ct%dIe_9j$%i[f?t3dU36M2kn;K?/coP1>\OK([f&*FRmJJ,K534
+%W%f0U@p$Ziet@Pq(%CmX4m*E$_iOEmrV)G%3E@i[qub=-r9J8CpPEEOl_CW'%]+OOYt6Cg[)^u`Q`+-N0qYDsZ1VT2Lt<V+\B^l<
+%MI(GG:@FT#2Cn6shSbIFf6m4-OfRWS"V^2dqR4IF[+DC9N?@JC=G&?gRm,[B`HmR0nsK+)BQ1-h_+G6MCA#k)'oW%6@m!Vj;_p6'
+%oV98?UR:U%/ZZm#00Op_iK"S8EKQ"#dpfS6O6FF+7F'^^2J\u)@W1BD*lQ\%&_M3Ek2:u8b!'oXr@Lo\ZWR\*I_J`Bceth]HI7`e
+%\p=Sa\/!2#oT6S1X([=>/`!6^HJdUpgobXgO_$sRLX;u?rMBuH$sEB9SLWgmJ6f4eqT.+&Q7a+KYTgc#f2ek\de(Or_k=/-/,-.6
+%_1*8<dkq`C7otC^IFO@*Ds=M74626#V2h*FQKu5X_dt/C1\oDRqqq'EDpRXu4>D-dXsP6<d#e9D]';n*m\)i0VmkEf9/1W*BK'G4
+%%(UPNn)WV[h`(Hf]gIe?-XnZ>c"kXT[b>sf2tokXn@+kBg8,XGc0'L5MLhgnQX%\X4k`-uXnIhW.>$S8k,k'-M#SNB1cP1(i:+3&
+%+,iiI&_3MeDJ:Kt]CX>F\S&p;^NH&*$c.#V,Ik\5eZ1'!TYIN[^RBN@F+nA10Q$d:2Xnaoj'r?u0AcV@48sTfM;4V>3m'*YlOU/9
+%J,HuFg_8eII(ae\,Gr*>$`\CRs%mjcnVc:HJ\PM#r@KuPFBu6=1O_pl\i[H(53;Y*\a/t&4l,&"f>?S65=%8Ve"tr=T>k;$o<.95
+%gX-'%XL@b1DXJQn8"jn?r;l&BZ6()H\uI(U]Cs6k6*^:5/+u0J]se_dV;@1+0lSQ_]_;j/fHK/8k2r6R"+O?XH6G6AaqAgIRir4,
+%00!56m^mXa,lH'Z9CU86?OiX>droul&4h8`I+VNaFo;e5\Ft3UTQ91d6jM#g[R&oW+*)GkCrXUL;m3\n:oG(gn3P*8F*;.#n(L.=
+%[Cn_r0nZ'IDBZBae[1<&EL!Vb+NOkeF)t,NMm_?]&F%)"A$Pa^n)rj"_QU#sXb4i'`qq@HiUec(<:T"H]*2,]Eb;RYmt80](RG2.
+%`m5Qj.8s=@/fas$hZ"/D(IF[AReBKmb_b8iLV[9hLQ.D0m<0HPJEco;-9ABGlPHV7luMO-mEhcgmPTDd4as-Fi"8\8HCoO.iIT`j
+%[u7ZjqKD;gAMD`d*^<H&mnH"`f,tjp^*D#SH$2K==GO#&EfZ95]39YCIfP*hhs!(H6G6L?"m6L>\@3^HIEgAM]tLU^E*';1$YHg/
+%=4A-IIseA#k,(3HhgOeM?ihdln>Gkb6UR_Hpgg[X7fA0bqS+':\ef;^@DuRPr``U3&VfZKrY+Ko%4BID-o#f9a%m%'Cp*q[gURi)
+%R=".S+(sW4mJcdf38b`ORbU4J]^D^Q5s=tY`],#u];=`J^:ocIfXcIDD],3\RSFc">FnA-3kV%Hn\^GjqH)=K%M#.=HYbp[#A1-!
+%1P[FsI\hK\lGg%e"MJP<X="ePhM/W6CVKsqY-)ORCV9.p6)pipSHf9rFSC3&j+Wo+BirQf52fkhSBB*i](;,fa,V\V&MO[kB,?Q8
+%qZ_V3Vq+bhkBt_oJ#g6mH=tO*#=70g:f#R]*\;Te<tMT3&=qF^NpRala2f?%qp7<ul5_r0kZ8GC-M4=1p8scIpL&d`^$r")&fOH3
+%P8+f,F@%Y&c+/8aC?2#]GB]?#C/8%i[qT[@jhrMZY9.>=N0TpAlc@Xg5<e@`ghTR5!]oE#h0\te^YdqM6:(p)s6/4rg>,alE?p$0
+%m-cB!$pL8t-P#d7-RL*=C`ZCEi<Q0hoDaiP?29.]Hm_^KaQI3smc,t(nTd<l3B915n0m%\cWAou$CBsYfm3CpWSB<$WL#GEE@HAJ
+%gtU'h=+d?+P@5Na\O@Ks=n746nca0L\OH1kpLYGe#6<r4^58PgQp,TcPt*uVpV71p_*L$E^#BV([lXh,e;_FQ%Hm)loFP]SSaSbD
+%(JD9<oNqH4Eg.AG3EPrKX./lLE)l;=B\VL08PktiQ]LT>4YA`O"0]l7qi"jqH2%:?#7f1)i5#?JS!K*$g&,9J]ZQXJHhHeO=7;_d
+%1D;!:r\L_WEaHdHYA5Ek^8,jfo+A`OZQohs"D>#u5keO7MY(0D-Kr1`g5:nM6pQ?'B1Wf%:_OXtKd%=Pm-_-b%>7SMceAIt@9[j@
+%g"GO:PqMU@pu5Xmmjs9"kTl(`(X\V?*ul(j/[(A5.ZH5l7:,I\Y\XDtI+$3nLd8$nK_LKKqA:?C`TP%KaZ_t/1Qn%*d-QZQ0aM)&
+%lu>Hsp,'mA`CCnGF<^aGk+`-?A!+Nf:=st6CYJki-I#S/.9jJZH'JdM8;<REmje+DHkE\q0fDWnN@],-Yfm8#ISqs_Tbooe=[XR]
+%EG\MIj]mu(5uh'R,lnH-PP&c]R*,`F-s\ZbJ^Y_,^k9W_=oQWT^!,EkTVM=IaNbU3PA:P:"$fC*K/5asIO^^TDCJ,`4Ea(!H3*Y*
+%I$^Z5K5P(q%!:p1%S=EUZ,hpfJjtVJ*`HfB!#[3:@SfD^!kP7,)?GNpV6HuK7sV94c[a$m%/msOX+2,Jk^l3$-a?hqB]-k?)`iW\
+%mR$-01IU)bjnMX`h.5l-`aAiY7#.a:_'LK*##Nj1`d6FgKg6'<JKhOS1O.j)<N>Mr^_&j"_%=k;8!T_>1dL]PUE0Pi?R2!AOt*+7
+%Q,_.>#0Maq\uXWO=bn#Ig1:^Tc^$9c%B7>I."7;?'\9i?>!82?Z"mB.3`+?s]\"Xo+;q\l_qI_aZ&8bsT:X,!JBXEu0mj2q!VAL%
+%NAsQOmJm7+0t79Jp?[A4L8T^h`AJ^4Z:b]h\4-8*SjBrL<%0^aJ0@O35'XO&0E[mP_9:*WGk`nU)Y@/EJq*tTY6EY(\k"oV$6p$t
+%cuTie(<\QIc_?,F/2!\X!$?dWOD-9&iYj-o:5Nm2SYh]I)(8?R:F8c*kRCV,T*=;(ODcunG$tr*#:+#Z!Am]M_[<W4g^tmfU'T)t
+%)k17sk_A7$%%no8gjP*p.ZNC8.%Q7KHBp2A+."a:6kS>Xd2Tr(!0kV9omaKQL8o$f!#m406&M%V5id2bjOC#8WOIGS%!<_\jBRbR
+%a;CHJ3l6O__@A'%37P!%P)gf"6XjC^ebVmCemTSB!!P?@.r^b9)^&$P6\0eZ7Mc8aXpH/m,*+^^Ee0$d)J?k716g6$/R0%tL"Sb6
+%#_O'JdD,7:^'\Q+=KJggnq)cLaYYI"8k:!K:K9su^`^uWd?jSokZ1M\JoLof@dtZ-U9(^SmHcq4!MJ.]EV%;0NRFI<2kLS#1kf'J
+%e7Do@a0qcH+?S\+X&pS(Uate40Pj2K3U!o_Jl%!E]sN?h#C4IAmV-FH5hE(oN8ZdupoFQ/7kub-PfJGqe9pKaP,k]a]O7#O/7&F2
+%cfQ_(A\eSgc1e'J%,I3AL0#^a0LhNZnc^]Pi",ql-WIbh=paXTe]\5,_))IN@#lYs+S6M>Y8iOJ-US/Q`IUG)YR8+[Tj/2T(j9DR
+%S-,h6Z?/`^H(V>fW#\Es3eV\[+XMhd"9bELd"]?#'(?\_R\Bms0np;:$hXRO/O=GN*K#^9dJ?Il]'aUA4LIJ!E=%(!;Y+W=#2N>V
+%/h;VJ"j<eoM'aZ$&m3Oi!@WW+W.A@85]Ch!a+A3M&3uU[23E^f$1D;TiMu.!);)*TpqqRCEM@>4C4)2p@6:h/aB1>s%M0a1C^P_U
+%.S2)kAk*N=,9(+#'sT$9.UlPX+PCmB6B$4GD:u(*8jW`\i/6_>PkJ'1;Gn0M5jOKL;B;Ad^Tgs]dGkkd4oqJ&'J'e'VK6lA\q5kr
+%PR.,oc>m"#!2n37(?IY,/HKZqYJRsYAA$"%"nX7)/c_e1#4GMXTGdABlGkS[n6?#eB!0,8Ub%7VW3f[g)i'q_,0Gbk>[ilgDU;0]
+%1+Y*[1ha)0.#l28.]a8oan'dS+XRX$cm.,P'u5d)/V0h\,@OQX^p?aXON*Gf2O?[Z7mUHjd".2DdNf829#tSJns)?Q,g50JK#.XD
+%Kg]Z0=M9rX(Y0pIaXZ[H4#GD+AU;uUM2C7B-/_T2$Ia)T*RRR"&$Tp(l?M7t%!o9.$Hb,ng.F:6n6E^(!YAb;-7%B4#D-6Q&iO=k
+%6lR7RW8$LF&SS02W_K%\@"jWD3Yno)gk'(56N)Lq+e!$P-O[6.GSgPc`RZodaiU-id9)D>7N=&[P(?%J#\jVS:$NOLK0&-QCmSig
+%K1$*4HS+*Y$i$6CG*YY6@ER+C'ibWpn]7GUnOjOc(#@@ChrEp6("aYr9:aF1;J^O/MkOY-Xscj5FP.D]N`]KS$#ICDL%D[F`3+`Q
+%iG0jV*Mg6=Q'oWdkib"?D+uV>[NgF]%[AAL#,M4/`C!r=^nQc'bd!IU=<$./"i!+0oE#Q"/lA=f#g:PPY@T3\,H(T+aKQ(a-U?=7
+%js#%G-hBd\OO#I/9t"V!-fXsT$tToWYooOa$js#(&P5Kup.UekVD.$0[1Le73f@C*iR/_l7KNiX7T2[[jXZm6RMnjiD6$p%00h6T
+%!u)Va0d24XD-Ab@Ymnf^!*_.cWZ?p&O@7b<EGJ)4L!ahs?Gf_dX9PeBp`_!q%&Y6'"bU>?55_Vd9UbMZdm9.Vo0mUG)TDjS"iWAl
+%Fp5%K#nYdsE!O3]<B@@81?kAQ:b>^VKk*XX6R!H[VOU9ZI$C`le"N4&!/6l%LtG$<j-tZhO/7+Z=1Vedep%Ni)0c5:%XJ=0Z\#nF
+%RpV7*d^lZfU,sT(F%GH2$'8-Y8<2@;"4Aqr!L+3;"?3)p[#?/%[]s7nTtu(0e7b_=RH;S##`68KF,S`jK6XckBfn;%3oU8'BAINP
+%Fq\OD->GT0.;1h@#,(SQ.>pYOpg0Gf&R/!O;5]j=nAn4p$nRh=@%<?b$fFFEoO)^6m1&>Pqq/3jgnS=)+B^'TH^Hr5#OSM-\t\X$
+%%3sM3O5S\j!0+r"_,TFM3FI2V$b&77]kh81au,fD_.j%ZXm2!S#-3I?HMk1%[EaPlJlpT4DkZ[mO[_2'<`_T'+m+=ogeeEK:]M(s
+%%2r(WF>?B[P6D5Lo;#->M67iTZDe)$AWs(+CX@WK)J?kK4t-DFgBF<le-PrK76Vnf%MkqfMQPN;I/^2/6:c4NXoss3F#X7c$\Gl@
+%>m.:'cOrbh<^p;JN)'I\+SY6li8er@^qs<eRKmY4p)I.'OTm_C`>^uu#QRIM@9D/6U]E$)Cc=T2el-dHf=SD*2@90)?&/u>4dV8s
+%BekVRp$F2N?CW!Kb6`r4ZouAlba\F$,((/GKm`!<5a1T7O"0($3kumbSXuTQ3mF)?,?dY#i1sb`k>P-#R97$M,QoJX=,\f?)C!%)
+%[lEA<>$H'5"F]bpMea*?/llF8aun-MPGtCBoWf9&:Y;uFK2jH[CQ&-"a%^"U5qBNo!:Qt.CeFa8KEtC!6CJP27<)T.!,c!H[NW&)
+%Hp+$J=u9RHH*i@fkZ5BgNo%Q"f(iMn$;0=l*LRl)]M=Y%+AL-@+@(XH#WONhfIHuo)3^,,H#JJp,&A"`/V'Ocp/HE[0H)r`%"_OD
+%6mm4ce!/.i9/@o.E6E!NDBt[-iJ^H2ZX>oE"s4Q":#G)$3W0<=P!:$L3Q8NoP_k4J4/Q\uo8s.:B_)O)V"o.992R4oianTlAf+T[
+%$U>o>mh-cmi@(G?m=f>d&_T=gnnQ<M-MUos3i#&<T?BT+7BS$XeV1-5cZr\V0a,s[BUiRsNJeMd4KiJc=S%fI^`gO=9%6gr$8)cs
+%bcmBjS3bRS%Z)O?5Fa::IOO#ILRA>P#dZPT]4q]lbZK6fkW@c,KJ5LEWB_Y%+qS8ela-B`Ggus^%kYbf.ij<HV3ShQhj(u6Qd'=q
+%JZ#L`*Kf+\4\:lj_Bb1T7Qr"t%.-8%3(7n@/e=j[(jlm:otV1?)^&7NFg0^K3!?(C*@L(G#2C[pcer:>VRN4"UPD*iTL0*=]n0GN
+%brdt+9S3di%AF9';!e!T`VMe>XHJX5rPsgsnKe):@]h-Y,Zp-OhBl708rC7>7s]ddqoEFc44l4c"%93fS1BH9ro[NN:Zs;-qY+>`
+%6MB+1CE2G]4^I!f'nQDYg63?6,q#OVe)TOeZLj>RL[(/I4Ln:d;rsRjmq[ajpsn8Yr=6[2NtI]n%6jSnOCPQL-)el`qd\iI7=.!"
+%$'`T2(5i2=rOG%58Wp5@6tMFN$T_GPY.Ya<!j9'Mho]1!0E1h>$P?OO^V(Ap4FP`';(*ga=!Lkb-e7nFX04uW]EfpW2>V:2r%:#5
+%%_VUn3#emB=,S!E'#.T_JDi'qD-kp[(452?R%6q1o_YRLh:!L-:o$_Z\,sF7%^>:pCVF#B'oTb+Z.aP]nL2_u*#0p=Ln?Wl[]C7X
+%jfKkH!DP[epY"@i@^/6oZ9'=F%DCiWEBLb7]G._ap40(o7]^FPTp`/fo@4X!S6sl1(2G_+GK'>NSFTGIT78X(`a[JQ9H>0#Q)luh
+%g#B7M2ZT<;i`G/qc(-Z#6<kQ8X/<p+ZG#B)RFE:e@!W&0(6c=%T>(8Zj/7^unG84C[k6tbpYo<&L@sRPGi#fZO/k3Rna*Et@Xfst
+%1'n+6:YZ\9.::pn]:lh9:S8M-Wd2;A7.W>>H9fBi$R[d_@YK3r%^-_S%Vm7bd^*`c(?aFZ0(KoSQaJlm0l"G(6S6&;H$[eEXD&uR
+%Nu+s%^J'8_7hlU0qR4cQn$Hkp!Ih:_h1mkEB(@GD,,aVRd=Ad79#<ts3@h.NXT#-\3KMq,5@B`L>ID%ca$3eRra]u4I^nn%_&0.4
+%Hq(lDEtp6+X?_kWf!o/QYuiXhUrY^qTl<ZU*P5]kd,;/io60Jf'*W^IATWTVG7Hg6E`iZ?WBTI.)*q]3/LON_oe.9(rdZ6"fSF\I
+%[g\;Im'YioPr#IF7l.+a'VWdG<<Ha->%D%62>V"(1'"eE4\<%B3U!(pS^^kgoZ!^jo2kCqR$2lD>B[AKWi!NO)t_D&9p93bm"Ebf
+%/O&""*J0#8&:",ioN9>U3PXh$$b<hBY22R[S*qP@7Bos_[QOh3]QEV^WUEka?r,q=dq?E:Ql__hkhj"!L1e5]m(#hk7[j;Jr.sjh
+%o0ll3YSmPaf67jP\F!ALEj$Nf]C73^'jo_'TI5J]Parls'jk)a7Qs$7>cd#%%2UbtVt%Uo*K)dZG9)e<Tch;,<P<'bN]n=mEarUX
+%Es/b$<Ta3I*Fd(QcAer.`MEmNkHi@$e'/P%Ko+F4LWra#\nJRDe0T!]^NNN%SYmf"ToVsDc`b#;!qea`>XD\)YEgUTZsNE:r9jH[
+%^2+I`RK*`1\ZnNg:Vg\0S8^H@UgO.FPS-Y>RZ>6:,6`RGB2?iUVf1UX_EZ>K*.-Lg1%tV0(W23HS#0f7Ji2hY!KGn6$L`Ib@Vg(4
+%+O-JE?%XT8WYK<Y8R\lB*gdhbb'J2Fi@H#S%GX&Aq2opMm*!SP`JW/`>!/+Y6V;Uhi62I,C[jk.gbIrhaID4*2>>T*5nE4M>p7cf
+%;#5AHc]69tjk:i3qYg*/.O"(<2^oTX6O2-I1H@0C$3lRA(c\[Ff3T]:3hLU;\[OK(MKS`.@_Gn;:?o^J=2c[U241ZFX"A[Y5<Sl%
+%o!Z(J[OcYfeo<dF_N0\6b9PSInZJX"*_B^ckOR^V5AqHUc6%J-DgWm7.sC>Ar('5'E1L@`3*'H2IJ(;qEHtNT[-lDjj47Oa6k7%U
+%G&E^MD"oa_HZ/Xl*q/b$@f<gpRl3L"qtK=DYY4DD.nQ:mp)Nk%E@a$H@?&0m5TnCGU\OT_!RXT0I=Cb`:Q$.3Aj8'9-MLKd=^mT@
+%i87$O7$mlgX+R<GD>j+Z,P0!iI;o%]&,4Ot3&it1/iQo>7C\sCL>r*n:S+CFDK"eOrL>WacK+0aK^7W,=AqQsK#.8ApkcUXN"2G,
+%eU$<p[[attqAF+356e6,f.:9"9[/kB*\r'5]$=*0<QrSm/\DG^:HeQJ`9Y6jO-VDf&fNp<^AEB!pH5s5pA<1i7XE4GT1?kIH1QP?
+%BY)FS`9>5=>urrXMaW5BhO'pl+Rsbs@WA_FIk*Htn'>[?F'fH=B]92Rhi.J$p;C=9erH^DMn@DM++?m5nP^sL--9,`cT^o%oX#Fc
+%F\Bq&\E\N`4TA+S&'f#4QVtH%c&s1>q*fK[+'LZc[>M!Ap>c+<*`\R42pNH"\,D6,WFFfMWqjIIhk%K,-Z:l!];PCP[:![/Nf>,M
+%!E-4;hmmO3n(PBlhnK&:I<XoMKc>7(5Bq/IcF#I?((SEeoT87t.bhU'G1UVPFmn1^c`iI3DuO@h\)2"-[q'_)Yu(8<[qY`bg"BLK
+%1E/N:U#@*RqQKCeK^bq)T3A2CIh[..7d#dt=UGkCd@s50AgQ1gCYQ4"PKkc&Q_Lr)WgMs$27p87Q;k4]"^lnRLSI./X,(\_%RsiW
+%s3kE3MFW[^ET3bjdPAoDPKcjMQY6p^8)UYdmL!h70Lu>K6ru8)Q>E09YMt4JG"+t*7">B)*DcaAKS+OC!BWXHAf-OAqTq6Oa:o=7
+%]So!MSu,b+_5g7ji-.)uj%'J%=^r6hABO[)QOt_#b\-'A]"ssZEJupkjT$ninj%f9<+d&!6%DaN\%.sH!FLjsak'-qQW_6L3&BW1
+%\-CtT&=9;Bp&k[gj>$c"_-KN1$^"_R-M@J-U,0C1o-3gJ*1Z/9MWtZO+M,q<ft,P^ED^"#lL<Ai(KCjC5WQh$HOXst/eL\O+m#Ij
+%EEV9QA#`ULjbNAOm$\%S3eX>?9.V/R]7=\B2oRpp\\=W]#eH[+3,29;].Up;!H$%8#S>-K_&a.T71=X-0*#f;["3HL`F\6;h2L?i
+%_@H`f-3M?+2NXY*#*Ks_g'`a<*Q2,mF3ksQ-dZXD9$eW3N5<7YN_E[8kOMbRZ]ZmNOLT0./A@'MLDW[Yo)oabE'>Ur/R\(E)-(fJ
+%6NMfP1'autHD;Y:+N,;98dUL#4jKci*J,6o<AjqI!B+>>FIN,=[Lm!/%#La`+V7C8#oO*ZJ4rK/EpX-]gQfQE>;0<4He"MB;DAYB
+%J?'6?0*FHoFOj;_X5LAG!(!.Udr_M*_4TL<'"=eQiNE[f\3u+)$FAd]N<D1JMsG]+?oA/8*)$rJPe>M?aL>j5.QFM>KTUVQ5QR]j
+%#g+!+HQ+]2!"NV6"NE%)>i.%#d8b.65SlKp,%XF.PdEedMB-diD?U(%H3un^I7&T3RBed*3+9dZI4kF#=VOi"SOR%VRc5t(-iadI
+%0_WhEfL,AR]?r#iNOl$c/+.1<F1M^3`'IQ<:e4CtJ;*<\HCfCK+X`*PFB"bB`!G\GA8G)0*BYQ&6s,(<n%(+pSYiQ29U3j^B>E=7
+%Fgl":#TTd[P9:i[rPF(Im[T;pq#JuW-M4_PX$P(t$H<fU)dume'c79c\M!VX"[^,r7AbJCl,OrB:e(qO@k!qTVh03q8fi."<SD+6
+%EWkqJNr&6>Q6.3IaRD;BN(Lt,(r+Y-'W_C5?I[j5(%.M'+p0[8LnT_"GYJO'+F(lZbU>(LO\q70L`Z'G-VhV5&<>(8_%dO08)["A
+%6'9h5W977a_]dAJ`9B"W4.u!e_T!DYY00,1M9d\?/JN`1&6t5JcVD"%Ko(q1%B>s24,>^/7WF1c[OjoZ%6ukmjd7Y,S:P?8l5HtP
+%#hI`#I#a;T_1B-84HLkP,V1JH2cUDA/>eB*%<4A1$3UBc,L]CX_OT89P3=8?mfngJ0`Hu5Qc1j4N)<1Oc!&P%PQ@F*Khjtr(Pq5t
+%e/OX+:jY_6:Y8U>!t`,V)htupp^6JL>7lJB*/[^I0HOFb[5_V8!luWn:Eu'\fW5f.[c7[1$"@Qba<*P,5u7X1Wj<-8e-$[e*da"T
+%'A&CT1YW[[qljdbn<`s=!?&m#=hIX*F`VMq$o%N[%OAKaBV6$ZLB=bbd5M%h<eZ>8G;nZ!E`e^Eqk5nbm*'5]AIsenf@T&<Xf[Q-
+%a>sQG,8Au!TS]D7(T;6(@3?nSTX$=q;?=Xra"ZE^*XcI43Q0Xf\.B^S.eq-D!9\S7)$4e;mb:a+rIF@5qM$+oWC,TPE&j.!_35L@
+%_*Qq.ab4&1.Y1B;#!aXJL'^F&kUIc@=@WY+&"t't#F'"UV+6dW?g`U38-3Ng9f?"q]o=a41_q7/+5!CR:*QCP0RL5,g0dW"N#SL@
+%R8F!YmQSYtgR@I6_?_Jj$+MA"R_aiCLn$.$rW3C4d4%lrAlesV(WI:KhGXGP5L0O/aF=cW&3snW73/rD!P,0>3DLhT)q`<QNgnD4
+%dKXXZfuf'b:-n5(aWO\M0N:6mic6/XLr,uB5e-l;3L8C'J\f0f0An/3$K_ss.+f\DLSE]NK+X&]gY`g2f:T:Qj4;AWAg(F&<"X14
+%m=?F$NB'ph5:qnGK'8Xo%<.t0A?iPmk!sI:k(l#lGG=C\eJ9SJ7$md)<sp@!2safi/T'_dM\nC=,d*stBqUR0"sHC^q1u-Q"@[@l
+%-:Akh*!%9-8<sDURq<pX%QF_B9#1W\LTPQXR?53*h%94T"RAIJ&%<E'"Loj22")ng,:&sY3mGb_]%"qO#*KOfSe2Yu`0:HAN);jL
+%JDD@c2F1u-g'BkI%V=:U%2Lu,[kh-dT\5nJ<1:BTs2Uh/q5qYd6msKLk64KC('l7ULI+QWG9`=dT:l3JReU-sh>^-AU^>ZA*du3V
+%Y!5(5cPuHW(B4;oYN6G.pq&X\qj6JUYJhY5o>WKH6(@h3rd)d>&_0\$)_IOLX8hi5034r>8G!o!pUi$=hss;k?GB8$V@d4cF)_rd
+%mnmKKds9kYbI$`kX$m/up9OLAjOXH1_=Bf*N)uL8X'DR:g$_AVB$^9V,X45JIf"7PV*8D"eno0Bd:'XuV1B!LA^^uVIk"?i']<A.
+%Iu]!*lU@l+8rEp&^/M3fT`D1dqN^D,@DeE^eGp`A92:;$/5iWGXg\t3_V](`UGZ#SnUBXJHL/U`UV@PI?bKk6Dsp_'/QefWG#g@/
+%?]c*Ka7Lo)Mq&e$XDofbXS-8%%c)I(^"DpfC+2?tdbVqRWKi]:XOcT24rIKJep6[g5SFh`)u7e2dMiAo/6X]4lG(K'RH%3W9Y]D5
+%fs\)N:]L"?/^nISbhD;VA11NX)cT;#pYIRBs/n=lme#Y`=i?cQhgP(>nWP>]Cms'9ZW1k#+eQUDHEB5YQ)N30&\#F-IJ2HF.B(;E
+%*P1@fm2J8134*J_Uoo]7#6X0ML7B$[>889*'g&k-`l"h%\<"Zh9[4h_j5]S]rig"SBBqc$<?!Ig7I$[eV:S1Y>G\FHl-M_F)q7O\
+%q=FJ"99Da%YP50c*c!KM3`BE&-ib-LD:GKsG(CQ7D#n,BB>AjQS$?N#q^Ji7qY?Qd'k9Zo%e!$Iq=gQ7:.A:]pTP!`k1NI\5@/RB
+%19NWTfofd?PB&'3lEc2[7K.1[*_ip2(OS6?[2:Zn!tE;n=WPWg3>D.ZLAWYGXdIl/h8Ck5cM:orU7&$(mgad7"oHhPq0k,e7JQ81
+%I9Qk4<&fjSSkBN"^2diFVj&7;HHk[5n<]=r]TX.ifl'(sX#BO4q,fFrLG:$H%18H\=XIY0l4kNW]]&6Bhn=cXm-U[/DA;\W"Sl%9
+%Z0[ATi%(rjB#3QJ_>dlB=H/&WnKFO,?ed"9kDZ7`5BLoZ0rS+i[q+G&=hVBM?fPbE>Q=MdlEOI7"mZu_(R8`3Kr0oce(:aj(&aA;
+%PP/@u[2Xs//!!fHk-MV)k"Gn'7-QFAG&3Q<?>SQ^"(1%(Q#>0'?p-r*0A>pkO@\QUhK1>.pXnP/XD6pZeneYVU!KNG9?0Dr[TL':
+%kfspL[[k%9B/mVu<?m57PoIAPmE?.;ptcX6pY7harI\\9%NSk7Wd:c.]FCo2<=G=BpnjZ9S2l$Y2ttJKT\08@X_Pp^;ec+)Q,BF8
+%<G-`@0)YV0:LChaqnslHcp/QEXrU_,B]>'_?FY7VjR(aXF'nQXhl1,AE0fnkeQ.70VN'CH"`+$l7-@_=NZJ.G=O8N\efWPNihLq<
+%*G7:T);6Vc=tj^c_9\Nr]%Il9U<%ma859'^B;][<>TT+mF2?"5oj`XKhp&i[?r:!C`pt^eqMa0SiTrT0e+DE9LFKn0.F_klq587O
+%D\&;Ip%1gAgXK>Qo$4*!UO_R8B`7Z'kHEW[i2>>?=#L\<I-J0hUH.DlhhbaOiQ$"\J!_(R3bh9jip`Pa-P"E*Lp5cHr`A!J+Yhr^
+%N6ogOPlRMgZjNJI6[o5>fi\[u9u>S[ab"A:,&j[@h!_BWIcA1tDs('^C9oW,n9+G_Idb6>";'h21P[mt_\)_4i$IuVc*t+=WNREB
+%Ce3I;(bUu^0aWGQjl#u2NmOgZI*%c-7MD]Y?_+VK^*Vt7Q>(JO'kkBA=a;kZMqhQkVEMDMOmL'`:E'L*ZcauBqn\E6h9*cE@@$c<
+%+.l9Q6<ttZ8iLEHqr9k+BC(X8`lI8YggX8l3;S_liQf_BPUouigA#Ya)nit<H<Au?P28ss%c1d[6VprFf*F(:rL32!c`.s(!0BGG
+%:r<ONc]#@ceu#ASFWFi-aPEFLY?p'C0K'#&jLH_,<4d2b=s_A:IMaGVcH-g7&Y8V]E7^'OT,r\1hu3s>(b51rhMt[F:1$4"$@$"J
+%ZI&aZ:#,o2RDUGHZQ$pq(d)[7Up`C)bKi9GYUjh`>s<8hLXYd4VjfmkhQp_B"GMHPqDg77S?%E/l_SF3T*H"@]PVb$)5oat]6kbH
+%UXu%=e)JTJoN?qj'5$srVhK,0i4r6ZH18*0G]78;LKMFdhX&93a6aP@LEo6eC<\l&chb_nI=C(om8JSAhOAX1+74+7gl["h=,]d\
+%28W@7g<T<a*r>g%oD?:+34)22pIh=-+_]VMX7i*uG3AjWS5cfKpTFM*rR%RJZke)PI(AL2Dg1WdCNjabh1,4T[6&SN?i+ipR[IIP
+%;RVFob%.mJSDC"l?er;9mkoLO\uj_rXIRtA<D%pN^92M$gNRJcpb>4&rj/g.6Bh@!Z>Dj&0i+4Z";mQNiPD>:Q=>`uPn^M-KRp;O
+%:bPIt9n6i62(F_Fa5`@r:NI5*MJ)HnYic;e8_8jP#5VP?jjf,SA9T@J$kj0PZO#S0Cgq,m[LS;la3_fGntVeL6f;KZB:Wi!i#qS=
+%)fT;Yn7"()"?;&c;kR=<?OZili0k7RPu#mPQ4["[KY1p*d]V*MiO]co&g2X\gpc2J#['Q#<e_&IOfJI11mD7Hnd-NK#?;SsCXTn8
+%A?IZGMt5jM22*KT08aZ%'D>McpC\5F_"aS_&Y+-('FSRkI$5*&)=W0`lbo"kZt-nF?"\$Z$QO+/-P_hK_=>.TR^\SZTNR"YXp!eq
+%6$+ZI#Wq+;RfQd0^;O=Y+;[OD*`HKG'(b^FJ'^$+<6J0U7)7"43IIXJ/07\lF<Jj#@;t3Jl7RDj&#:!ReRNP@q?!)t"a*Wc-D(E_
+%@tEQPi^4'1,r?t<.\a5RJOru-h*"1c#6TfK9&L=i%udX#!C=2_\b3<81G/CZLdMrV0:>0;#]WT2MJuu31G^r#OH=TZ3&cB!RUgdj
+%o^KX'6_8I?XG/\QQ9Rm5DrH3KiFj:)0&\e"<9,cT)"j<Ak`DJ!);q:>ZN85.=n.1T3hD>FC[&"m/s@Uf4(QqCj8occoNsA1ZEO%%
+%:#b:NE!A,%!-OH$[Y+&#@4qG=RFu4\")t[U,V8N!8)-Ib9@1eQlS+l%2?QO(dg@)Z[a'+&iM<cDmh\5#/33(GA=*t$JK5n)f2^'`
+%3]F9-S)!$j2A:V8R)2PZ\K]YNMS3&h5OL"IFj#Y5H397]4QVl'T%CgbNF8Bi`Fus%bbHP]Kb;UE9DGV6Ka#^'a5\maC5d^_"]'h9
+%?th:Pfd4F&A1drq"euXH/did/R\'R=+b8FjbCDP&p&tTX1ZB$=I^5T'cTi"L!M2D+I@fkLKSg8<<-`uqUTPd2#q#D+OOFm`r'HbT
+%r`J<Z!\ZB,o98@'d3V&\`i`rYLs>8lE?i?!4<F,5d($?YT+gn%>''d*!BI+l;[-;O6!PX?b>EL25ZV!QSWH-:CE4a!_KLG?g?/,c
+%NEron1uX4U78=iS%"UYDT]5BM$8k)&")]Mk:^'7G#5k1E?%BJKqiF0mP3b,>Q#86A;@-]$>mk&g!aos^hl[]qG(cmr&$nQX)4n7S
+%8M(4dE6LXi==/*cJh'lLeBA(%2uk:9%r#IG1)VhSrbbGB3:'!(/lOmY+^?(YkCR4J$:7+i@U8+T#5"<K?>ST=LT*Nm*.VNRXm#7b
+%p]Ai#=YPD\PakFB-;-*O!CI\K'*2Q%#g)*r:d<%ek;$"%#bQXu=_WKB+fKs+Li)KG;LXDsTf$CoJ;$Jl7a!$BbA?jRNZT\N2`Dm!
+%/Vi!KktZj2lrHZ'LN!pV)?>C+5mc=VBmqj*W#dL,9M"D9&S]'R8dZ\++"GHbX4T??Po*98VAVZ*L[,q)oYCO$eQXC-HU%_$T$drh
+%:n8K_NW^$:,I8T<!)`8k/5q)Y.?+9(5QY22AQp'fG^I7le%nG+aT:=6^`Jag,bQi7>H<8T6Th;gh1e5]'sK-SJF+$U%Ci((,cL_B
+%+s8#cQ2$CC#]R`$n+mA&i"QIn;G'2>MRsH3J5=OA*si3,%J0U'5eui[QsD0pGBU^(a!(7MIJl%2/,R`Gs,aF6+o`NJEE?99!\Z_'
+%^:^YRm!g\`Yl""$IN'm9/+1TAS\adp'\3&/iS@t(r>gB72ARe[3q_;9hEu0U@"lJoJ+f/*@kjac!ZbCNWY^[A?ID`.,\-o*GkMRp
+%ZsU#&`,37mX`5'Z9b>qO;pUYOqJX^#AIs4N%mf"f!J0le>'=X'8;27,f+Zkh5:S3S_0:c'.17E:*aT-+n23TUBW_/S(=2jsl1Nrr
+%0.rpOje_5[[>P.kFQ-.NYIkkPRn9Q5VSi81o@()@JfK4M?X1ZMrM3VXmPTW@^@Q6,#O2K%;!dWl(B3]m'3Sj.\4T!rfZ+?4UK"hj
+%N1SV0==e&b.Mi+`kf)G8rRJ`AY;^@M#c4Y,^0WP^@kX&r/Z!>?Hf_o+Z.R62C0+G6bHI36NhA>i/SP;NRPRbMESkW\m%*(PZ*`t#
+%'jsS%ch;7G=?<CWWf:dc(<H@fH`N)@/)BO/Ki:#fAOD/hK3N+Wjgt\JJ!@)\8;-?SB2>W62m?>t<B<-J[3i#+!2e\$/R+:']l8:9
+%qM<SeV_"7l$9k+Nco&M69oF'&K+HeMGN;-\j]CirJt-"E]620JY;p:9U8?=cVPA@5b.-"!&$8:ffMYH/2=/hf21*-qqr1Lkm\MSQ
+%2dJGE".oBoS];2YoD=uOQ`QS1SbQkJ:Yp*McHQGYZ2&\T+#U?B6gF&MV]Nq\VAK#dWnk#Ngq)d,3>7KLV=M\r$\o9@<J_=B_,5C;
+%$ZHM5(bomuYa4'+4+@]E-TV'So:nUdD!ZOlV_"In)#eK$baQZ_3fTF;>K%*\)obKm)*>9V/+sjGrpUd(n9t>0H$YG7J.:"Ap?Dh"
+%4co3M3-N0HA`)\L+.)Zb25#0*)WG_]=@IlaV^KJnR3,0KZq9;'?[k]Ij+cU6Z7E0N%X)47qgRM^p=2K5%q2uYHXOk3<L]>^_Sj$,
+%[suq`?8-MB#2RpS[s0Kbc-$B=p:pS_kC?amR.^:((JfNL8<C3X]+-I5dW]!.LcLoMlka<T@IX:]XbKiRD^)o\4+!@oAFTSVa&_i6
+%(2LQnhlbY^(4?^o*!QWIHqfSD'WkHgZ/Lp.l<)>aMn<':gN`#GV6)#I3_jZe*<./Vk<#MOH>'l:l41M?'NkX?I0S5kF6bT+*m]3B
+%h6V)lD/jW,ZWN(HNFgBe4"%$nHgb22ZhN2fER`k@G#2#1M^(&!(Y=_=0WJ&kq2Bd[76O#)<X2X^FB';bdu@Y^VlW*'^$Ft"%3K^j
+%R'/Ceig;YWCm[>%@fgYoh=KeBr,NUgN<leTT,k-'HgCU?8%[^)XQgflJ@&\XBUY?Blgg>R;'*9r'DFY]+#N0?eo>\?GHk?#+3P[O
+%j7o&TnJT8SeN_j`0HYSqFmGqW+13a@9>#"fYl7%>^?!-'P?[0kWL3<?e4%s$D*M=<qbWF;S/\C#J+ZZ>T&.ABfsAEJZMW"jCT3^R
+%mb^"9Do;L%D3E'a/P"9Mh$8A@If&QHMUV]@/Uf[+n\WC84#bCLf-Y)!PD[ei@m$YXn"Ffg0:P*Y]B'^9%SJZmn1[%dIt6k"*060>
+%Gg'[tMAt'sZ`o6cn\<>$s3fk@W7@k_)DG%0&$-*>9^j$)$0V(1kuBJh3M2a<aK/0XWG,cN2TAAa@/t]GqpL,/rtfUGo`CuRfjl*N
+%/ll`;Vj.$S.C>m!Mc@PlGplW<WEE(.E4Y(K9Gr.?k^:QqF;DgcaQ3WH[>LUs]j+GoR`(m"3rpiH6R]KZ0[i-#b[G'a$BY\\3Kf#/
+%\u\(<C^t^0-K/GOK2agQ6l(2?b4r*'O^:UV@?O&#0k:U\Ap)VZ.AP?i`j$hE]L`UTnSp!&l&qh03"$G11,tZV1Wb:2E(h-<LhjSZ
+%/gD/o8G^3^A=CYmj\7mU<]]p`q?5]XFP]mu)G1e3[e3JeR;Z\P#)qM!`6hss2FkkVaC/0Tf,+5g#s<s;BA6ep"?`oc7+38U$'Rm\
+%,R\Q(pai+hEMA]]l5nQ1$DOoGdiOH/Pdcc+J3#r1JsCL&br<0<+eMK?\f"XSYi`pd@Kk#TU+>=]e;SulQ?_%6;[QF+?j@$N'V2-9
+%gEt&CT=h<Uk8>_R.o'X=K;Kk@cE*5nfqFiU_@q1Xl/6Lg-T6-r5g6])j:;e[Ch_*fJt^fWd:22?n:!Y.P:Si\a"Al"O]0K0I$U!.
+%NE=K.n:b?P*57R<a<ZWkKBQ?eT@EMDnPm^P&DfB/*)T(YCD69id0U&8\iL4fJp5"@Q!>$D/ke"CjI>eDi/>HY#^<nT<6TAV'I$9:
+%__,Xp;CP^d_tR;b6/$r2:(EfBM?''b;=T\/.bRCGnIpqcP@1)3L;P8[Nc%@PN<q6NN*D`!GRfW/&.DZ63il%*aL2FCKlCPm9L-go
+%'=L+"O"J-oTTHJ$9"GLdfEI+dP.:f%#ZN?u&:G2Rhu`?R^J@rm>g_O8.;!\OVQ7=GLifF74QS<,*>2id/KdE.o1<]BP!o`Fk@BS9
+%<,0jK6#,fO4B/>E'Wi[>Pkru\Q*M&l[3Z(,&t;-UY(ucfRBB4H,U"<U_'\V+=+nVOlD-fm!cjU:Kg=8C;j[j.<#qIh6n&L?fYMG2
+%clXEY&82H[OffNOLg\C,aUc8#:_js2^S/QN:(ieCkRnlk<W"d0Zn^Jsp_q#HaG2b9aMqPfF*j:em)&X]#UrtXS7WWsN@'EjH#\D>
+%I-RsHe%^,e"F]PK84=1m*4hoEZWL+7EqMc&1-J+p=H#\"lJ^B0.>/611chF@Z:-kc$u&RG"IfF<6BGm-*6(#6Jm*\CQ2kfa%7cE_
+%a"Z%!#SQgoWcSXs/dp#?nc6lFN*GD""oskqGROh=GgJ6lWphm;!eOSb7P]+*he!o@a#'#q..e*(Kh\X];J(\AU&rNB8-l"X:Ml3U
+%Lt8&NK>POOifVhQ,I%fKY/[Ute/53OU\Tcf/ieI7+q8Wg/Q_EZ7!8]8/`G]pBgQ>#*7L)5#M(>n\As,.NohJA'hM6[cOl0jQeMVo
+%'J!G"6%MP4H#?Jq<Yj"ud&gD<.87Yp_$eL??f4'9eH1t-cBii?@-Ci#V\(#V@=9e7p#BHREZDq.C;S0RENFLjQj#2ai>8d@P9smm
+%LQ!)S;CcQT#!kKDW0Tk&:t'Y7@%q$PF]$la=@Q'.!/r7<6%U9?3V5Lg(pL`fOrLbr.iB[J2.M?OGRb(f)1nD)3.QXMOID>n_XMpi
+%HE<SbNCUp&ct-?M3WplmL-a"[N16VZ#_5Jb?>B9_>U_B--Hm6%k$Y-o\/6t6'!db24<_0IJ2MVC#.PL`4A!NF1o69rS&O0/[Sf9^
+%M'jtfI5f7lKc42gh7+.;F-M@\MI8b<VjVQaYHqV1Ga;;?U\Kr6`t!Hi/$rcg,<SsSeu-&p5dHfDJilo1'.+<D3V'D<8><"TU*gk.
+%bQ<F*X_CBV:j(2rVmFY(hPVObOg)4OEljIY"6ho<ckfBL7$p<KOKnkOE/h?pLo6r0"V&>7Yf!JT3hWclA#dod3_f8u>=/ZD$>6\K
+%BumETPF3TtR>0/WF&WXrgC^:L!G%8f:bp"$*Ha;nYAbRuMCtc!*0[V23j-GYJSDps-4O]g?3lW;S]r%g,D-E(/)*d/F^e0,OefcT
+%9uoTB_I9La`jLrY#!qpH&6JoVL2e\Sp0c4k.g_jH6kWq/n$>3UXb>AZ61:8.H6HBo7-eNCa?4jDmJ)Y3Zo+O9FU`r@ZJK\*c*.AL
+%*tZN9F_"Y!:T>;@<*YU/W)R"/:"#9kV9)'%nekhO'gRkL9XJ38q*"mrZ'Wk/^+JDq/=eDYWEC:+Z1t3YEn+C.c:DIm(I93Mf%<HO
+%fgniqX&3sTjV^u@N9Z)FKkE-2MAb]@C-!N)'U'4[8338S5e)@R1J8L'dh]PH"j9Ish6S+%!%<R,K$iQ9=dB@fA@+W/ljm0AKi/'Y
+%J=)[bKuJ8JAGRd]1c)uW#=@T7-b>$KAe=;HLkNc)M(Z%eU2O<HS&EgUP8-j;(.4Q:39)\0*@AC:e55<0q[BZ\SKZ8NO9f%mfk),O
+%&6M<04l]6p5n?9Q=X]to(sE`;S$3qFq52o0mKqX5_4T[74"D%[N]Q#hU=`%/`fl:iLCW"eBb)?Gq'6=L8hB?$^`$h]$C>K'U8dR9
+%)_D&6Rb5"jJAERWC64-@]&nO2jn#TRC@+n+S(9-PG,GY,i2$X9_"6n%+2S/&2Ts*4(<BXu8F=1o<.mcUODNprNtR(ZNU`R\dM[K>
+%dL,!t'i%Po'fRkpO>Bd-Nc\+b3DpZZn0-M5*`b6878k4L2]dS!%t$>:=]cHSct+OcaGhDt/D=j^$__(r$tYd-*IJZ_4TP"5.PV5G
+%RrHRm7FA!NgEo7._o(T#38Oe^D]NsZJuJ2EHjM)'4br"n&k.C3<a4]h-tCo^@>'^%-mU@707]uY8Xn`H[qfuBP6N=kjIf^^3Y[b=
+%mU@$W95F$Z.e82UZEQa*p<ZeG((QR]]OcaSA,Tk&kZSRh=QTUJm`*UZ@-lt1-$4Gs+h(F(9!X3tN?'Gd4&J?1)@?T$+EjL+&%H#a
+%%k`^;a5?:;Tn,s>T2$OiTd@\lDX`:anR4dqE$CGb(/E*q0(ts=W#Rgt%2dH[&6i(&#2Da23BYI6N+aAVK4@J@7i[bi?'VOpe?osi
+%,(j[3E!gU;b])1o\]i<TCEFp-)I)6B*!]\Dhr#LDPZ"rk_%3]g]]GI#'F0J\BO@6VX8n_kLO!CSaNb`"/1gK;l)lW.AU(5+M$R.C
+%gB\%R$MB70-,PTY[[E:!UX>GNe1ST<@B]gdR'TW93_a0N-_;S@lq/-83]qRo:(@B`BJTi3)oms!^nF:q2Fit"1d$O(a3fg0W\'t4
+%ABJS/%5OBJTtk^"3?6!nGVb6_>S^Ir\u!Mg&M)1[G7n@FdT#'5Xo8kK@VHH0LTdE9atn_OgNCF[7(UGn$f<Y+^Ck8\a:;Z<.`OaL
+%SAqY]O;:TZ5rrq1@K$j!A!l@@6RF*REaTeJLUX3r.LXhr7XJ-U#Za`bdk"iP3pL!gGbP^:hS.*1)m\Mq2k*.5W4;#SRNjD#.i1lF
+%Rh)&H,8`,&b"2(CO3^de24YAJnfCQ$,h,L_-ug%/95A3REGQUk(&PEnbMldPq]Qkl^s_YlSS!,H!^E%dBo@-]ZeGZlQtNWZ'E'=.
+%5:#fbi&2orFpPt8_lpFIU`nATliOFlW$Xo:aHG`pR48b"7LmXZ`SVIK>]O3V+`"I.YW+890Y)dXK+jCC4S04A\M3*hX")++iPGV8
+%C>sOHG(mY`N&[s]RS^^2O3eW:.7B!UfN`Sj[13R.D;)h/MKl.0)+W!W#*.,b$+-&+;74:A<EQ@\16clA(e[fXXLgO63[7]Nf=gEi
+%'mhPX!Kn?H14RpneUb^5.8hBheIrk?'J[i%\r^SE*%*/T[)l0D)(LPP3Q>J0Nd1qKOa&om;0bO'8+bS_SB6_6],[Z$%&f[J\Ml35
+%gWYR>=2*"VT`oZ(MG_sQ1_0:Kl%#!U&KSGt?1pG82J&m1kb&njCMf8o_SC\A*ChJ1!1kPQk,98XI:RN>CC,c(L26;7RO?B3;o>%.
+%fa7'TY0p;=]f>ckTIX9K<M*+pP\?7j#<Z(B/i;@.>_\+!VNt,1_[G(8R-cju$52U9_%1t0/eeRqbO[1*/^/g!'#Bdm]0]b?OH-p`
+%@G=HsY6iH9*7.2Np>H5`@>&]GTdf^>=ob90bak?T+CV2AdJ$!!WCO,NbfC=S/([5[6j"*e%rlhk`'d+,&V3RLU$('g;P74-ai@aJ
+%T95O.Vn6?G>$f-rnO1e*=P\D11N5J8Tom[(E\p>*gQ'XG0F(f<q/2m[L.!4%a(A7B+M?+m\1:%S0Pp_S2r2g^dO!:b<@Qqh:dX>D
+%$Ls?+Tp7\(KcDoWkRR=(K>loPo0b<(@&9!CF!JC/?VZ6IQKd$D&j;cq^]BoI/a?1!2)r(8aB>K3U'_<NnE"Q2FnA4'VsH`*)oQ7H
+%'KR`^(mCqJY_a>?`$+oo"kXuCEJL5<93)+DG+-PS-&TdclP]io8U-kX`a6snn"phEX*i[I!5$^f!ZCA\gUG@@gU'3nODZP0frf%q
+%3!>m^rlXPQ[3hG+2s],)C0'LU/_`06e#m2?p)TWECXt4\^T%gc)aK3:\n/V5XptCM,HNl$:pmBbmFsHJ:npV&VEo,"nW[(I"@2gp
+%+?;tA,RBN?[ap;6^-(A)6%bR:4mfPKinDU)@`"N_c%0gT5UY<`7N<E/'\)>oh$Ab+k-/nG6$11p@<a%)J9-c[Ogdq&RY9E<3JbJp
+%<Hib2B:;Yf+IEDhi1bX.Y`8^6+HS#r8-Gdre)K'0;%2'R7?%0>]E+qPPp"cLq:#qf6oYb%^^Ql'&tI+d;DV=Hi,fjN$4>l\]Ih$`
+%*!-[N@`!RXfQ#UCa$Z)j(bFbu1Vd#Qn[8`!8FU,_@VeuMRk/Sn)87Rf0EATiTads3K/"FuQ>%d<,+Q*gE&M,Hkd!FkU2tVoOFJm4
+%!Ue1rGu+2Q!%5Sm:(rS$QcCk:i$\8c1l2#;IYJ,"S,49bMeeeEQXK<+-5/\<$3p@u==")GrbZ\qJhu,40e&\'4D"X6)I-+(;Wh<L
+%WW2Y06W`:Za4B$kaN'"*#AP+aDee&O:epH.crCKl-<lofYPr&,_XQP&8gXa4&?Z\\)<RqjXtkG]\-+]+9FpUB<G;mGS4`b`BIN/`
+%S23"0qDMQk&ATr\>`":[d#iqC,soM")HA,j-nq"h)Nfj[5\@s!SuGr114UE'oHWYNi#qK=(a*eT=Wq.6Y/N%7PftM\Off!C10==Q
+%.I)(;UHM.&5naSH=!cV^:Z]QRa,qT]Ba@Fh:S^g(9l1rhHN=FEk?bCX(mZ$"[]RY;RYV'^JL&,U?$95aOdiO\-+tY9C!rBU,##G!
+%I)V?qD(jD5!%BAB(!^/S?-0QU%<ti,jS).ZXRKQe;MTIr%++ScT.bOU\HKVZS--6j8dmKU?Q43:?hoYrV.McIFPnQrFK#i[!?_fe
+%2($!:).LZV2B?/mFn"b?=8R^H6rQLq0UZN4hZsr$9u?KFbQ25Fg$rbh*_mr%5oLDDTg&O4*ll)aI5)?X(j\ercVT8D#YA1GLp@.0
+%-/9`Z_/1,3]:Q"a)4_[.K8"]3V!5p#WrsE[E!DUEkm(=B1nH]Rfr)6H-<*Jm\f^W7e[f]8-2D:*0s]GY_3uLg:,jbTAZkXm6e&G9
+%=3f%JgsM2q@QG]8"#_^*EPT2")RAlX.iI,rRM2eUr%QT"P?g."!q.#Y9]QS/26UbWM&DU*gLnSA)^`B!"Xe5E1?8'pWD$L1?s5E-
+%l(6lmJn1$SJi#S_8*gh/kWkk!/L-+NGC$:4fRcO^Z@;dTMpT-'!`nnR-;jkr[GJ:$!:15K`"89uO];FfT!mpSXs(J_4S"SMR*&-a
+%<(g>q!]e\WeI-Nb/K&BABV*IQC%QFrZ![XoRQIF`A&a2pcLql3-^pRJ](@QE9H0:T#>nDA!Y>d,bt*MI8fR9nd$LMHBJ.;cM3&mY
+%5YkIGG+98PaTX+!d@m+qYiP>J\L6[,A@aM#$b9X.#Q_Yn,qIB29S@_;R9kV]P5pot0uQu@/5`^KfGK9DBYnRSB>p,#d(r,kIY>Cn
+%%\!Ju/Z8`+N$qB\o4lQO="7=Z97fQTU:Z;G#\q=+o,V@_/?/^*c-iEI0V"9L#+)d[!-%+R'h_77J5h@DeWO`=B;KPnd6bH;XcT\)
+%c87:*J6+:lm7a"\&Oj)]'\ef@LX@K^QDRi0TA60j$^><HfotrN<%h=M=#?<U=eQ)9:;X?sbY%)8$+;1?4dR.]EVCqm24A;+d>;BF
+%-MrP_`*og_S"^%K80q*/NSGJ%=!ZDY3ljSG(faYKWiOJf`CA+2Rj_8l:L8dr&1DNWl4==K5n.KhcsZSS01Mipj;!C.9+Q'[h5V@G
+%Ii74C=oqZ]hTK;Vg8cq4a)L5BR.,E^n#FVRRMm0Ljm_m*Uqnn:jXq*TlM.q9aqk2-8Fb>$[apnq/$fpAVkF_!S'F(9fh!&8E)i'H
+%B56aK,pQ<R&eTqRFul5I;[EkDOrGBg"1?)j3C#sSiB[/AS4Lsf$:5T?f-0Q:"pNFSDa:[\_m7R$[A@kukG)j,7%U"[=6;&0$gYbH
+%@%nphC5%dqnb7X.PK+82*/"ktZt]P,)2-,'_PDmrqO0*O77n\ZE^8WG'R01ULbI-nc79G\fF$&h/OiV-WhGPHiK<%H*PTAMe-XJR
+%)"p:VbcsLJ:M<+JRML&OI&ksb^m<#5lpD3J9B-'!gH+hIR]6mC"Ouu_V=Y2@6A*arl"EE.=W0?BA9UA*_LY6kbW;8K)Mjc8N,d8L
+%4?AW0^cY!Q%#BkZPB8qWG/]2TPIJso&W"j"MKoJkL=C_p-AGG2S'>Y^L-f73mg*kR7h!/V<uDii""-TDM6j?gMng;<%9+oQeC5*K
+%mO5rI.gTG.2<b8A?*9peN6Z!N$YP:G84O2`";sthRTcR7KB2:lQWPFR(1Ea(&0t3Qn-$cSP_I4`%er=0C&m:H9cPL;9*rma,T7&6
+%OHBq_)hRgQaqQ!e+QgfY(<K(/Op+*iBJX(Y]i6HY+XmO&&e,0V1'D<TE^N5t4OKINS4ZS_.2&TKcefKEiq3U97[1lUClRF/bWfla
+%KNZ*bm<Ta1a'n'`.N'4_@1KGD7*,=\hD'`>"VZIF9S.e'>Ctcti4u]/40Rn'Z=&AbT(3l+nd*)<0i?o"b>Hk>*,d@+(9C]8i<hA'
+%0oaTimE7V(dh/52OhlR)<Z"G;l@b`Sc[nlB(FC-4d)$(iA7Q80=b3Z9Gd\f!^hGXM`ba3nP-7O2%AGQaV`^uVkC)GH:r!<0UhC6/
+%,_n<("s$[o@mD;-ZLE![LpFBH,^SO\LI=iW\0pZe,n$&:rZ96Y@^Zup!BH6`0G_NkCnm(L31nfF3AC,?(mpmM"C32S/Y%.Q.9S@8
+%2OK*!,F'\f=GPsc.?OZud0e89U<<d19b-_Q.?^bdD>X^9Kc=]GI[J9kLn<j%fCgM*&fpOt=Di]C,3p(aCf@HGP_DEn+o$]1"589e
+%:n7[n:_/qq?OFc&fU*6B$"FdF+..a,@0W=eY6&8`7k:FgM9C#8"FG.1iofdMQ$<&en&I/@<',-siJI9hC2#K&qFq;7iC&],&#u5W
+%foSc&jC"M1Q607T':^RX]I.d(O;I[6ecG^K[ENO>Ys=_#D-Ai3T'63V$6H^m=paoK_<_tX!?:iR!@'$N@5:PB06lO[L+%D/o<EFl
+%:'LP?iO/d]UPH51!i5NVVIklI]m)$ChHn,>R6h2m18Y.dL8N.o?n)M#"2u)'h5_.?&-5L]&V<7u9dH9lD&reT_,;Rq#RE2\%Qagh
+%MJ(NBFG]<^^iW*Q$p>QiU*(p_pj=6LL"HB5hP$VNAgR[iW5OXmipYFYr"G#Cad#J`c,\p0:6'>U!e@Q#1!LP#6`3q?8ONpp$$V)=
+%RQh4TZ['&GHVdPG%RKQt@(nb@2!@\^WQ7SN-#0,D8[SSj[keY!AH:I9#/S^132-U+0oV4^`F3#07,S-.N9gNE,Psr4!aQTr\Dga(
+%]+KSKoRoW%,?ck^]3M^eRY!#Ac%)_XnQcVu:B2ak-?knb$ofjTp4e6_OH&+6a2an8Jh1m12iKA>P_T?7Cj*^ipj*_rJskEH)R1gV
+%iR!+_+,()q\)EVj4,0RDWXep'acljm+d'q*$"a#F:jcI]$Z;nqD!]n?]h:B;TiF2\eAb19'LcNb!$"D8l;mtinsRfji,B78JhTa:
+%e:RrN$?(Ql3hl'Eibf1J`#sFoJjVd7MBPe)^<\tf$U"Br*WK9>bO#'ZL]kDX>d50r.+BSenoRqM!HAf4*8&3G"Rf9!^]oRo9lh$!
+%JOB86peK_U7.J.Tcs-k/LI0uU.`SNA6"c(BKb-[Jd&\4k:U:iAKa3l].km_MZ',Zj:T;fH&Bfr@'_/j\joXL,/e1D(TEuVOUY@M%
+%'[I=SFcT'#/;'=i.+,7Q?dk]<VEo)59nLIhQO<%6+$,PpYiGsi"ULScL',GGL5B<'Qr;Wl)7E)1An!PO(H5;374TODO3@N*4J<KV
+%Fc1B(Hkk!3Ip.X[2(TJL'da,#S#.W(p;@_bPOG1Qd:,Yni;a2dhOVcrC(T?UjXFdE@+7]L,]!KHn7;-DB],F.liCXrUC^,>A2#dh
+%5<@_T7$]/4>mR&l^1dl3(E?Z.^bp6ph8.g_&1L_0/>\j=HlZnM6Mp:b'U_?o*28!9m>B<m/B/GTRg57Abcq07'eTk_+_F@P1_%kh
+%;):.O]tbIm@$]%HJO9D\hc,$J9ju_lH;g1u"`^5heW':-YbIOVH2sM,er?I`+[86uE=5C-391AJ$QjqY1Y@QrDGS^dK%_&umg+g\
+%`-=<ukQ/5GRQC4\*2TF)/tpB,M4*uAE/fLnf0)!MGlBIdVM,Y*L[$&$C4bRR'$!!L0I`_]5W**lI'9M(TKZ'!kVO\Lra&OjGp=su
+%>rC[cPaPVm+M^nh>YEk-\Vs,c+p'VfLu:X@eRfA[#U5d]1hC3XalKuC_^=B$(4NPaR%8&"LL'2+Q76JB0ZkBt;#qIdgD:&GMV'6E
+%FBm`]\>@/Qb$tZIk%q]\EbWp`;9J$_AZIg+KM9`,M&$([?gpTZ)GQ.p?ULCl=MK6W*A`-/9<O/q9!4P?`9A\hWWec4MWHW&12\o$
+%`Ca_bQo.Q2KPFp`R:PkV9HmrSaD_+]%A,(`.VoJ\\<rig%e,:%_Vrli=<CQp_l0R0a5J;`Ps$RkVL>T\nW(/UC'FK2M6mN3O2Grj
+%N;5i%Qd3;X-:OZh+e+(3I9e8]I#P5Zfe"=C8iW[:kpX]I3*+.O<kW/I%$0Y:&;pUlR@R/V8,/FlM';'a('0%T"'4^fs/,-$U)sS^
+%7K*MI(%irMHO9sM\#6/;)<Hoq2KUnY9I:Gd"&Nt+/l<hp?)#/^HUS^F)?r5=6/KK0L:A!D<5%>4!@oVA,!&B/Bd$?4-BrPJ)c;Xt
+%Lq@;?:qA#_M;\>!Ya26pm73'5RafOP>'-H1*K&-pC4_j'PPnCqIc$eJ`>Bq:'Bt$$Z`q4V[%F4R%uF*:Z"%JdG8B:FFG]I@4Cb&m
+%c?3^IM-CYYCL#$os2G;O&H6Q]I"m1;)tc(PQVtKJVdT`lR!;%FOie$OI@;%'DbpL=p7ipam0IEXa]F>>O_'0<^0G,AM:;MF]pds#
+%9;pN6/=l9Y3e\J>N$1GJ1\po-%*K/!/&2uFq*f7L!ME/8+.ipFb[Y+8XDg:)n5(D+8"[]_`$NV4L,b>U"&"mIi#%oZ,%5lQ!]<7"
+%/b*Hd3u0)gVC):XNo("iTZMXlfJGSSV8P>AJM>IAKZSW4#.Om*2\)h7E?YQ:b'1s<_!uNnF2]FEXBC;&duhH`8&GlI.tAXtKG8eO
+%8%c^t3a#=%_XI"!SDgdY*"0ibggL5^B[,8j1r?"f8"b,/IKaeaV_.+)Of;8,<CS'd4^>SMVC5Ob:)s+oggA,DJ0*`i=I2U.@gONe
+%%#;)nXS7D9:L`%3#or)9ksu^IeG)Ms<csY9>S$?:l@9G9[;rbXe]?/)^_Q4:?6b;m(fiVsP73`&F=JaBf3l$?JV4'nKa:Fm$?09'
+%Xj)6<n?Rkbf5ug&e5.DP&P%`k8liglZG%#`i)'`qqQdW<!`DUm>FK@;_nt(b)!@l7$J1Kp!,-hsB$"R^QRlND#1JjST0l4i(mZ&2
+%mKLU^6)T((&*JY%=F>d!(t#E3muLc.LXLc`EU,V%bK@)+3^`caTUar5$!3X%%SB@9koN+1Bo?h`FrS@kOeiD"S^=!Cj6j55$2;]Y
+%-'WZ(Mo"nH\97;Qd&,E:8G8AC;SaA+S`G&OA3Ah,U8&U`PINrF@1?C.c".IKbM50V3aGA_U&tGJT%\CNgBtANNZ?ARn1_![+E,8h
+%Bo4;sBWX^'gm!dkIDV_r&RQ^-Ci[`'`O?,lOi]+:Yr75Y<B:/fQ6T4Ah!\eFfnmcIe#"<&J`0D*29\W9UM<]Z?;N&2_K;^m3&1eB
+%QFKi.XC*q(kQP?PANpo2#,jI]du,a/s3KPK0.)i4IDaqOE"BrH(i4ih-A)uZ3+IS^,TE4`_X<iTO8%?mQ))^jDDgA.flQinZSSto
+%8sNAjP+;4VY.d:2M3L@giV&OIk"3^6RmQ*=A/S>F7Pg+blu9m*KUdi$1E@T`TST=<m_5NBF+K]9Jj<R0jG&KOC4W5#c5A(FKn0**
+%lShF/'!rn1:fL%HA_7lL'ac-_Yq$!*BFu'lM33^X]ElG98=u1Ma9@=f60:?N;"Fp_V\m=l)"^`U/7,,jY_(b%;P?EKaiqW;:WZdr
+%91c+&Aqub:_D"Yb5;)+$6lV:cW@n]qn\hD=(RHi7TWHS.!&7k[Pa,^8gk19S"P=7`94gRib%?9iI#t.T+c;g:A#4HSM*$UK+ZPqr
+%?@U%%.V6Ok;QN(`T1,U.TG*KT/>V@4&jeFI3=]>Ndf<irC*tH.9bC+X.O@)B6ZU$Fr$44@l+ieE;6nme3C,b>!kf1]\;Cn\a&u\W
+%i(*mu)8T=0,],$nVNUfbS4-s,;,LXim-qs'e/1rf'W1ej!1(H-Q;c\`/3X,MOQ8;"#\\fDq1tPC9'H]B0PL/t#T=s>*rO,XYWkB_
+%W*:_u^GC^4/D/e`%hqUK8VTL=(]';XFCXYnp+h818]it0UAPb=!9&0)mYdm,!T,A%5tE73;:Ik"7$9B>Z=.&+P\+kN'@$W=o`S%B
+%5g;N0J&$W$R7*:R'7cJR,_@2;0.b4&?nDZl+,S280F:;G)4$9s^7<1g/\NM>-\^363*@q,8d#BQHK3qWnZ\gh5ebBo'X0uQcX9\7
+%"ElcLZfDiDSk-(;UBsdEII^i+g_`VNE.E.qKbPZaZ^c\%659S'dR5Blr!gs26a!=4bZKP2r'6R%J=%2>8tAZf*'eBX^qGqj74IIo
+%W=eXFd9AXcVm-sIH]7!>,d0Cg1k;3t@1>UoKLJS"?jqBC,#jP`_EJV>R0c=d)OHL,*QLt%_^WJ[,TS[emf>GUkX,tBI55sb7KGk(
+%8Bsc^]VlC^&qGDFJUP/_)?eh9*"epqM3>]-+]VC]@8<s5Ymh>0>h7i(-g)%#.s5"t,9XOa5[9'n71+'m8_PZI;F,c\,"up%E4cr@
+%80S"I<"A:)73mRXP[8?`h3X:L`X%rl&/r5>L2^-q:1<99A]9t&%aG_`fQ<>h3oNJ+8->:#,1;t9d`UJU$CW)'P[<g/_,;ie-We19
+%*S_lio$q,$GgDC77#4ToB8o>iTDC^H<>24AdD.T7A=F0OeLg:r1`i)B6,KONFJOpBjXKgIcB:KP2c30-JO1EqnNFZGUjJYCLmmur
+%;D'#Q'O:2K4Vj(K/Jb.^Le+S'iHU"V'>G.9%$6m,:cG3fOd7sR8pj:)Hm9oMnW"3L<+uV23Y,4fBTc>Vl4LlWP#ClC"FVGa\[2kE
+%:*:XR1h[Zfk3,b0Sba1C8p0-'Kie?O]F0/;6eW;rN<k25;_m9qZm:G6!i2dP0LU%(*28/IHjDY?90Oh5..eg.0OdI"@6/hb!c/Ic
+%9LBuFPs^FdEKOSX9BeWZ)K%!N2-/k9?'25AW+8S0\NuBP@q\gs:'V`4^e;Wq!IGQJ6K"Z,EZeH3-@R#(3`un"$_(W&LerU:PG,Y9
+%@uT>RKmKtt6:_RlAdeu%g4U'+,3<0h;S5Ft$Hg8q]AY$[#aV9Z?FWG#H!<YsRSV'o!=:O@1bij'2M#AV@Phs0qh(hM:/Gp)\H+!r
+%)I2$Z<35#5OWS9C-)4?NS[`]A'9Z+aTYrBjfoluH?:"0j'7i\2O9fi1#O!ZB,Rtq_U?n-lE&K%jG8R19.n2*AI.s"acmRcipWRZH
+%/&SJGqu5;gf<+*J2;X92DpahlOG590k1r/c*hP!s5^=k.Ti0<caS8FMa9Y9BgEO\',\Vq/#cZZo!O*HOm.%qaKUe-1I#$HGM6L)W
+%#nkk1FCDDD*Ce)*1_H#m`TV?)?8m_'%+nZ6OWFK(;C.GM;(3h3?cXUO;AI6"?g9781Ut6hdBJ!I*KLeDLO)b;O3&YEe)M]YW$/>`
+%I0'JuA4D_[VLN@S7^7)Jk'<,UN@K-krC^'D!S8W;raJi%URK!m705>T&k_FjS9H(i->*HO*n$;a'88P?W0@.8rO,h)_Tt\"q>@%q
+%,Ke1d=<!/r"\d(N%Z3G1O<NoO;,Xk:T.:cJ!\q'Ac3#BY[aEX@G"EO@(Sh)/X+TXN@5q(S'-R\/"^/;;aYHX!nuFIo`>jb,YH*5@
+%4rTH^VMl68E`WgL=(^A\Q*/`7jREGN;9B7rV_LieWX_ep*f<c!Yp`<j8i-(d$q!oT0(>;4ou'Hu%2a$YUh+2p#9*%@l)PH`RmuP2
+%UuD<Y+\1!#D``q;UNCbIHW8RU/*h@Z5==N^Q[.c;\0%#;P_M@L'q6#@_f/RqqM2"I%)LIL0LZ/bOHS-`Uk?^l0^+`%^.'1k8<OdR
+%kcou_kW<H[C.P-EctI+ZSlAQ1akIk48CsR1ig*it6"X5FF2tjhQdX><mbaEkonH\!-#&_i#(U^n.O>O6hUXIMFd[HhAB`7:A&cd!
+%nHt`7B3eT.ghZ6D^`*X$'4NdERWJoM_G=9*60f4q&V;r1@a^/@#uQG75d'ro9M,U)Qe`m\5]q+t\f4=J.J4R$])sCC>i=R7CC*R\
+%N[n7P,gZt5cVbCT`oP@;nOQbSk"9].a67XHdi0q,51=^nn?Y@#*AY:u-N8@_YJ24o:e5p&N]o<7,oQ=DoV0a#PVG[SfeZ<dAnfPb
+%)ZE++)2r6&W#pj=16YmiaWu]O<-0I%q8'HQNOpr6q+8_d+XlhRs$7Ada:'t;"X]C`7&`Ze?cYkM:I*/o.9FR^92!8mR_TQJ(8SK3
+%):Pi.9Jbpc2GN#gb'c`',ah]TKZ8asN.pmqVMK7AP`RZN!d2qAZa_P^J_lVRJ2il/G%&0j'D-u8UL-B6gl>u#([6iGdY_LG"p9FG
+%^K<hF/#g.:P+#fc>Hofj=I3I7HBN<W6%W/FPJ[EG,RYH"UK;o?aEIK?X-cj(?q<eEe+4df3#\O)l'Rm4iJ&b$V(a.VS/ImCLh%l-
+%0]V"m&b<#:HHE6t`nhZ0oN;e)A/*8_IjS'DJLZbfiYjKV9XFj/fg'oc/0"d+0jt&`ckb8)$j18)_,+=OGVIMf/EDVWkgns?m)pIp
+%E<?-!&.]?J&aO#h8*RS%#`\,b5K6+aK6\__!4t6)U?&LFH;0p2;^<e_dD8?]Lm+[T;)/LY8LC65`Fk,,-q6XOq^Wua:>d6tHD?!B
+%#Gh_63<0Jl.)-FOr[D-;O[kY'*`s^5YWfujalONL-`,9fYGE?\,0<"b&Z"/Q0N]"L3S(F5I`42dOn2>#RmLR@Yo(b&$DG$$6S)-d
+%rIbCK(<86uF59^c!^)G\Qh)iYbcZ[\8Fu_l;Ma=Fc/1..KCZN6R!&_*5_/ckEFnDGY)<m>8WYUeh@0@.=oW:qVCl5Q3NT\jZK'X!
+%A*(?]W-);(Q-4.\%Dqtr$Mg'iom5H>\2O3I2JC4tE7ioJ$*T;b/(_!:3u19`.fktIQ]FH.@]q[qYptfmU.&\$NLM]&&;:IXJ(/eQ
+%D2Zb!D@-oo[X:'1D]4bYjT+]7#;1e$Op^A9C;$g98n6YYf6])m"fZ;ZdFRjG92u6V`@-QYU@SD&NuLHm@7Xt1B`)3fA_^7#d-00t
+%^T/OSC^b[.nOd@R*e#i`N13_s.F+Ba*WJ`n:`LZV%D=?]DGBg.dAMjmi*S`+q#AG8P>"C>^K*^mY@j9W8B4U&^K=&&5Nl;GJW;JP
+%@^<rnUOS/3VFY".\Qab0R;Z3:cmqt=R1ndK,.X9?Oe+q/Pt(c^j#P.IFOc'eR^0f3E5tLK;#1O7F9A%S?KOO]SR433/]Y\[h-%9+
+%$u5`AF!\K*,5j1A`m+ot04Eh7@58V@d<(!P@d6g@j:-b)lDFjh>Y6r<fO)61>.1P?Q+qQ^W*I+^5rTKUNiFRYmALHQ7lRf.Q?4=l
+%JjYiYZV`_HKLt_<%Cn7meS@la4/[_iT*,!%U^d1k_c\!8\P$RQA`j+((27kP)5K+gd?4k)jJ\eTm.Sd_Tdh7@mU1__+M[dC"EnI@
+%D-!LU["c$7Z;S+hkr.$K?nEt2M"pGPb:tT,)H#h5BMQJ0FfR5bb$YlHP%&NJ/%k]BEJZ#W]%(+YYIIV\Wb+L$:9WS^=447:ST8R0
+%A]uGZ*&M<aWQ@!H($Ab<?#QqoeeK`;$*#LkKX3_@i;[/(P1:YsBi[rG(=inR-AtXFMXP0*.f@[4>W/(A91b.QF^,kZg;@pfO,'K(
+%bpS!D.F]7XLp"is63UPW_L8H,44Wc+B1k5TBW"a&b%N+UkWiTgkIOY\TDQMj>,A_!'`Y91oiCoh1;X7%IVq.1[d]=iqVqkOSKU&6
+%RMA.p2M_8!s%2NG)BB?dM!_k:>Ffc72.:pEXu3gK1.";'1hkHcBS=?.@lhR%)lQ!TDe6l1>.Pm8:M7cDA$gDpdFp1Y[;i8'6Yu.]
+%p#CZL.Zh.VOEo/;#qFeDU]K"9/eWt4'<@(,%E)lKFMmZk1P6/\Cb_lQ`,+G9gRN_+p8?:(ZnDAlNI/&Fr]M)rWfU)o8l+Y062.L(
+%>8qd%0MYM25;;J;7\?+NN2?O@\PX%BX2<hFq2lOZ$8_KTpg8LB00f;go:mC>/Ls`akJ*Ib=NiMSCCQ^?9G5s$Wq%VQ;Q?2rh6g2V
+%:TH4&+lEm@Y//s3%n@j$U<5uA>]3><WkV$<UX<LYkin-a.\uma37Ms\eZ!_*Z\01YggJ0-]-L>GPYJ`./.J("f[r'-gOBD'7712I
+%jh$^RYP*nP'9D>_RB"l;S^`OjQK=S'W"!#h$6NP+bgis,b(4!WrBH];W;'/j-S[gLAu#/^RnW\dK;U<F#%4/!L5iB$]9AQWgWaE[
+%D79"k;De]fN2UkY`gbER/PS?u]Km`eV>=i*p172faKI.sK7;bl2hJCl?*Xbl=age"s+c)dq**g';[oq6eL/8kCtb&*Ltl$Jd.kuc
+%0V%*jE`9@V,0/`$<2og^/tP%GAEhOYO\EjId8BX05+p1<Bg7t;,p=M3]_g@lWg1g]?TB]>1<nMYrSqaJp]'WZhRb\maAHe4R3:=%
+%-/4oKRC&\AiJ_A06`c,8>%P#uX];>!\<H;PPr"]\nSobA7h%;KD3#Y7cYE=OoAf0:15X#qC:'G3qqt!=s4^&-a6diK_if^%_*]eW
+%N;a>:"/T1F]TTCJNr7XG!<8O+a.Kfn,N0n-&S$qW)".bj61Et5Dl%1JjYgA2U"b92"qsaNCqs3+Du*75o1cGEhLp0U2teGJ21SAO
+%>''J:@>Ql!(osb:cF)#n?<\$7b)2u\epE%HVEc.04J\1^PAf$l?XtbKnmW*VEbR@u&`RbY.iX]#Hu8ib0PU1!lCg-`j2Tt$%f\.9
+%Enk@,2Kn0PP^7.1[0DA,+ofhI'?W7?c&?tfoPQe)Xq%E3_D7`u:5M!,Ep]PLb@Td):pZ27_*?9&VRUklM`X%V]o?t-3N[*qp4(#h
+%rXF;BZC'5<fJUGClXO;)O+$7^>V&L$nP<8,^Oq%"[h9ur82!F8VAKp-&0jiW=(3[P8r\>h(U^o:c2%MAo"KS\mh:0&Jb@pYiKd2"
+%ftf7Yoaa$lQ,`hns)p*d[kYSr.IZGFmFQ%HH\>WVj.QAT%TD?q[CG+)m$jQR`@ZBbmR`<'e[(mkG'hZ+6KBk*q!+pOE?jWi-\""+
+%N#4OMBXe*XbW'.SN^H8E/5i#$$?5h85/4edr2Yif0H#R4BCKY6f_f-sr]QWuot_?[#1Y$)]S!2j0'b-Hhr.t_Ie$bCXeu#'F.d54
+%D(ojIR/`GWruU=;j=nW(<6G39))^U-ro.P=J#TPld6_2iQTMprLG=Q,QQt]s63R8i:Hf^W[".j<pb<9WQVA1>I8G`-J4E.$`loe[
+%rhCiu<G'=?LF7tWD)Td%mLarDM%\5G_t-i>Q@^s@a?P!FA4Ikd7kH)L7jReH2pn!L;2FKmS*82NI_Xi0j8\>"'!<1OB,&\DCncc9
+%oL-f]6Gc1G*DQO.-]04J[=:YH(d^GBe))D>oX@];AJ5mYo;FT<bbMa!GK?O+TMbES8capQn3t?f&CEE[1H^-:JEEn77bm#':7NLX
+%h=r+T;h)Ooo8eb]&VCDC+^l<t,03'^ec@,_7NI76rdC@\gDK)Kn"W=hA]sO]*?>3$/V*\_<'Ml.GDG/t%gMX2EHP8V,)GOZ34r;1
+%@-'ri<ZVpKEA195O+&JoKl".Vc"VQfV=!K@co]]`UVFuh(^Vjf_>g(Kh!^"3qX9d$LqhQ=NK<q?2K&L(iqd#^>E[:;D"4n'HNf6)
+%L8d\eE,/([/7[fS=gg%?O!Jl**+^0gPf*Nq<(R&;TE[IAJ-9$)^d3SB77]-1hb&HL8&cN,"VtbNpOBqYc>+)g<JE^Qg?hpNb+ug^
+%X#BoiE@3],G8e?DB9Ri*>1"3/r>H2\,3%KGF]tB7UHBKC@=pf!)qLkjdONQ]?g)F.!Y"q"KtMF</i&("'gn[Nm+?PubM\$1`Smnk
+%$'q!,kT>Y?OTggN)5I"-#0$oV,%D<G!!=,QN5D'+s$QRKIl8l08.#t-<bk5,Sgs\W-AA&m*rX:Q(QB4/R1Pp=p-J_FkqD@us-=JH
+%J#>m;heuk$]9C>FETYs\NB&raokL&tdBLuI?*p+Mr^8:gLVO%V1p@[c^\dmK(5C=t\_ai,&8*sib=\bbCJT]f[d2.6KM/0g(<FL_
+%lgBIH,"@&um;06^s*HU(s8H!s4b/#4j]B.bn"*GW_Jpbij/S(d7dV`cr\^+\ZUk+/Z=KEmF!\.$c*Mf&LZ.j014A-McXSCVT9oT7
+%4Mf^MB.%\)&Yji"*nPn0`P9XVYE,m^?Xjkf:c+?RM5"t?;AorBYQ"#E9DC)@6L+#P#sSa.r[[/o=T1GXCg-<VonT)X\)##iO8jj`
+%m'RPn)5aC,6\:D-!>_KDRaKLADT.)61*8`('akTT2-H1=Or!.$STO5-oEbG.&<u(oDpD*&aS))n(A4.e''>5G=>1F"a3>XfLag;;
+%IHQ>\*3Sn+EkB6YT'O/i,>nmJI9tk[oP8<pS%bhSB;O?)ojm$\pWHpe@7sAdS.I9dN+Bk+2&Q8>DILo9aRAKL51Wq-]8B>a*^mP6
+%?Z$KWHr&AXlNA4CR-tFL`Vm_dppJmRc,Fo$d@I^F5=-V2>$3-3l&UEqo"<O>6r]A"(<FhRXX<im.)rNM<;Jt8`u0u5g[.cZ30!PA
+%N(WaqdIHMKSr)qP@i.pj0r.X?gqnGl<YR6TQG>J-\J`hea%^j7[*=A,%jN<<S*CANo^/a7Q[0$,8'k$WNm[If3BurKgL<$c8-u-G
+%,BV5q%"_'NA\`d!^chIM_f6&8!;%/4(&f21i[&@tdHZb>9NsBRJV]I+es@D$4!.CG&uVSU-_JPfEGHlpMcNbE+8U)QXb8b]eo_fn
+%=*c`<7kpSY-mn"E>N>.Dh8*/gqApq=TjN/Q55eae-&R]seuja\7MCe@h$d.%9X\"%[8KJ28imp2GmRjrPf:mj-f=K.Tl)Oc:uOrs
+%^iNmNCMbn6F@sk_NK9B?#D3V%.ggb38OA0FWHr_bOm7>Q"TCN"I+6Y6*lNt7mWMb@'b\A+_k/,-2#6?qn2K@/_e3G*Kq8>r2k@+M
+%gd5T+CA#sIot"\e/DJMfQ<UmhXJ-3sCft$rV=`U_9P0+\j.g>E[CW/=s1I*&epa`#^4+a7<u7*:k?F,c@_X51$P,mJfn-plBgq#W
+%fan%)XC/$]F0I08%9CpoXZmE:e_2qK.E,DKgpT7$H5nM@;3bWK;]`E0*BkIH'Rn`CUb.HBo4>qDg<0)ij4@6Ts8/U,j(2et/dta$
+%[F)JlBs5)mcn7<ClY>?I5!V%ml64UL3#g8rJ4<:KSQTgR<Egp[eIY77E`F:eTuuJ1g-rU#9'%#"_Du!k*GDB,lAd02[&G\nKkf/k
+%GhQqQ<Ki<?,dd$=2lrd:W#4#ILagTP.OcrtOnjR.Zn/q&fdqQ6"LP=`>&Mf?8tRC!X/fYYQ)+OM2!\nUjE3f@&!b2H$>M"A$X%%<
+%B#ZIQEgMYbknBAfL'mQSK4pOaX6$CbWeKZ%MdZ@]Y9s]h7I81SYh7K-:h4QJN(0)&1)-l?,\%/b&Rh\T5p]sW,Qe2>*['hXhgu5m
+%"L+rN7J65GY`aeM.lh;'5;)nQFOWlUKg@Gp<"]g76.4AJI\[nq_35%&6nT&])>g/C8Qm=[(.9u5\P+!BVYYW22d.jKV3P&GU7msZ
+%(B"hF.q`Ef>uJ`Y'j[rR].QQ@bK!s84oYrTjD*Ge,W`p&i);!*cpc//M4mp&)jrgYX%nVN_^qN#_\muDA4V^V]fh"aJgY#CZS3._
+%#a%oJ?iBi*#L30r+Id-=(=j8;$pi'V4rfVIL454FrD<g;nGT#CUK(L>ooL2Ef*!2pQ-<op7sfoITf)bCKjVP[j$tKkce:$SR/RA2
+%mg6:R\s'j8d\\P9S:IFV&,WKn7r($Q@hj@oX+8b(M(8/8FVhHp;B5DAG\>)3d%o2*0OG*ss7p)5#+Ls_9kuB-gQ(oEA7i]n<;&*F
+%qu6N[!rVf^&)UQSQ;p*<o:LJMJ-lG;&%H*R;qU]]rr,Cs1H[(IUlGuYk:'/h#@D[1aC\k?!%gs*>S\kO!+ESBquLIY7$<fN\97fM
+%62^+[pa]DhXd!OIFF28PCI$),aAu:PfiNudbbi<u"eW5_F%K)@i,4)jnJ?*ppQW$0L-#%GoQ^\*[g$;=_g^=8Y\MDA?b6cq*/rX'
+%5G\;:Ri\<AamV8NR):fm3R12"B^U[]0CXSGX]6AZpZT6Yq^n(Z(.Mb`BA('gYaaO#h#.1aF-B)nP>pIj(];R6Kl`B`F.]i>r7`LT
+%Ut9J]=,9('OihW$DR?^B\,M\7dLQ)>m1@10J1T!EN&LK+8Gs?'i7ZCFLrY+hGV],bc/q6lg&+E>'\LW#N(/DU=T!BtT0K1M$MmnR
+%[#"1iDPJD4@/RL/3be*'C"7u;U`H&7g=+5b[f^p0lm=.:ec$mo1JZjeOgR_:rPM(ko&S&Y#-[S^^b8SR7HR\`<b+,ndNrP$Q*]2;
+%1TPY%/*5`'2U[^?Y#$1We^#>>Q"oVLe!38+40@&F^$_,*kZANj&%R>R8o6]0hPlbE%Q5&&`faY@>I$U9_d$d=11`kmLmTkL.OkP)
+%/ZBY=D:uKdL)Z%b8Jf,$n<d&^m;(_ulE8lHO`FaeD3C2J\MD%I`C[O'lcD_.OK_acQVcmd2BC&>/(ZXtY0k:\=0>ae-)=d9Lhc4F
+%[jE1T2+!c1QY:*0Mb;Ns/N!&72N]NuIgqK/5=C,+:EZJah\4eOchaXO?W8DF7@qI>KFpL"78/Hb'p\Ti3t`1:TTuD_+.$$B3U-fk
+%UTO4#'AZH4S4a&>ZQ-2+W\kNl,]gV]R8&J-lHt1$'g`X%.rBRM@pCSS7gfBI<pI)!D9stS[AM*.^25Yp8'Q8o=X>FTe8Jf%\C'W&
+%&4M3:k!/&hFO7&@e/1c4*^$bRE0&ES&J[%Lc%4-ORalp7XIQ]tB_?&f$E\bgNm"gbg,ZM]PKKte2R5;19jRr#S[Nu]fp&@UTjM^q
+%bN!$CgM9rY]_gnN54g/_q.Y_Po0iol7D5`^)7qF6Ujctj_5EDYPub(fRj'=G)`DFoT[jGKcB;+Hfjf8/rA^u5WW$-+ruq"aIG.O%
+%BB]VrO57,?XIR$G7?["rS)[)%Gf96?N1j?j0Gl:h8p8ud80Y1X7(\/mK!Rb\V?kTmd"4*bR#8KGImu^mpL(Ch$4KGLR8&6h>mlXc
+%<\W_E^hL/.0H<?Ph[+_hb+^Om;T18_-7+dfdkZ2"8m!C[qN<U`dhUAO2!3)EaM(mI3\#gXJ[V(@cKU79e=*LZbIYBYd(m]VZ4L2$
+%JqC6YUHAB#jT_h^%>+B"[hTXXA&nnGTZOtap;uU!4dZF$Lj`H#%#QlgUN(W/ZY\338?kA,+/uun>jbAe/(h%b^F$jA4%Kbcmc%`q
+%P2[lQ*KIYQp5f_.07ZW&`#i/WrMV`6X%(?2=roOk=j<n)HOj\mc<.90Xb[q=NE'tm2FU,,[I4UZ6bAr1WgU)Li/,f9603f$6b-g0
+%%>p"b5JUmN\FA[c54)*l#&foLJ63M:BX\lA6jb`Y.&2nHXAY$t1H7glJY_>3:(WYX1`?Is_aqq/H4<H`@'_^gXO_.js55I&@6o'5
+%C,kWPD-<0umB@Ei'H%?-?#(X:;J<g8;Pnd3;St6IWGQ=Wd2N=%NO)C>UTDU1P&`CL=r\G/WN\EAPp&c,;%B6e]fYW57X>)L<Z9;Y
+%2Be>FM@QcQ>:s!Tc=a20c.8]F);$P8BJ^3.PLPIjT[:^j^WL7llqb?)C,_VNA%!ok'iO`V*_iS>HdJ,Fp(8\%8:tS2@U3(^$_f*j
+%#J72k$3ZhA-upH%'[;N8(FUVt(/q=H;s-D7RNu^kJg7!Vp58i[g7tK6US`<t:lP)rQSWOk'nKlJA)3Igao^P2`Z"lWAbW"5A0\%7
+%,HMrJj97XT3\6/<+YET+!!e[L$Ekk4R#PZgFu5mK*;OMQBT+danY?>jNQigZ,q!'U&Rq#X00Ak3\c@]r29tZ$=?f9$JnfId>72/q
+%PUe8N3`gjO)+D^KnnBC+Sru$2^gUp@NhWqAUhguHM`@ZZC_4,eEPh(t'(8HDbe$2s:;%rRVI)brVIJ[b+iSK[9?C%<b-fri_W0L)
+%(+ai:K%^Af(b4C/Q0nW6E'PPPr*MqYo0",g+R3j'j3Qn]IhlV4*6S*:S)b7.+N:TlS"A/Z[3VkS[&Cuf]%H_NRL$EqdHGYZ&TL-]
+%>8B\geBSXW2EGj.O'04]W-*G&Z;[cEgMQnGr`caoaAUt@U;a`F*U;:<"t*j#&-!W2=K9j<TW'si][cWZ6kicrS4VgPO@5N5n.3M7
+%Z`^<KJgo`fhJ$gYl5uf:UUD0EfUsF8==lIU>l3W1279i^/Z,tZPI6(4NgEXFah^S9:&]i/*tF$b%u@8t/LT:YA5u^GW"I2^JJQHG
+%28[m&F(qb;,,pYA>:<$?iTdr-56i9`I8M7*3(m^icWZe81,hToEboI4.sr#r4tqYiHpqd^[-OW6f<TDO8/3b^WaA.%O-]7\iV;_4
+%engo-bM"tB9P[t\44L:,j$p&7"dd8t[C8_+p=dNfd1gaX#5&=+d5)YZG@4i:91ABab&K%(02*W?C3dseRi?`p@m;#;A)n2p6n,.9
+%mROgp.Z:a^GG8Io3fSu'frX1Ym6;BO.p!,7JZ1-B;kL"t=e2I]]/h@@<*(BGWq.R9>$S>CN3K:a.,N&35iq5!A@7UoV.K*V@'q?1
+%+Snkn#`^%h!XV[I%E.*LUn)@FN<@83am,V.hR(ZL7i[d(4";gC.P7$+NOj(Qdcg`-Op&(-e'd8;LqhZ(UHNLCc]iK$"QOY_R]XCo
+%<b:VeNqE@6'(Ee:#kXrn[PR6\78mG'P;X_da-!R0MYGd9T4g^+&h)5;4u`"hNegbY7(f6=iYA!qYNUde746#(lA7G6'UT5]\r$UT
+%'m8#A9obs>H<JgMVDosrMGC*OF@*Zm)>2._88K7'-==S$q$N/'=)^RAJeR\i*0IG_KR<qJq8R9m=)^L?JrY5\ku#fk02('H'^$`K
+%_$ToE:<5A)7_U.OMf!<Kg'p':h2il8%6:0=O;$=W3MP>k'A<m5BfF%j,uI``5eA0[m910585Hk+NH<Nca9h6ge?k]!0A78gGUYai
+%TPuJ4hmU+R`.RD,/p1kU<$'ReH-hScU09mmTpDVj6B=/OoV`EiNuA^C]CHH14K>/sQ<-mi>".Q(g2rRKb+i,i[m"S)-QG0V7__hR
+%$JYDl!Z&])CELq:Yg#p3oE:]FXMDlU,>JM(ieW+0:'`i=OFSQN#WSP'@$ZjA?^dI7,MWDAEC.I'T[pS`[2:Xc-JFStb`(=k1)/L.
+%C2+:4:dIdqXs#A)<s>#M"jS/WSiqli,2nn&&rnstiKt8kNp0(oc;C%"KO`d_*-4H`0df(CDFTjIMi_duXU^J$L:*u'lc9]O2<(V[
+%'.2"[`)T6jX$A!XXt!Zb3UV]lj%cO5mZ<mt:8g1UULjlk<%cEic#IW9N]Wrs\=/k_n<W+Nf*Z'd=j[3toWDaO]rO'Y%l?T#!J(J[
+%qW>Z_DY5[,7/gEfZ,$4p`.,Oj5<W_fMuG4]F82;SogK?ChtQ/TiD;>d8pLX9TBYCXY[)W@Rr&kq>>HEuDd*IUopq2sRmo3ceRJ2*
+%20qj6*b5.=QY/8H?6%tE:k._$VD>dRAHqhQK\"iVmUo;`$>\\lJU:G-bFY?e]H<3fr5%N0ZuD@9^#(8M2UhKB@c]Wq,jm.l]rh7H
+%OXDmjY?u,eHq_F1&+=c<8$fs3cYSXp:(C'`PPmm`pFb\#'Sha3gVWa]0ndR<:bD*Hp):%&/2A-NWU00)#"QA]c[,<`r$mo`*XFF`
+%"5u/#?Ydpoq-<1[Kf+tjOahS.g+EPLiqhMY4ubX:ai'h/*aG;h_al0l]iXqkg/TBXc*p2l+]COlcLelBhYX4LSWd2?GknU+*_5eW
+%O;M1B*St[5ek'9n<3?u7;fAeBrGo0,NGXTSLrMtIn&*'53'F78V;"0D$%^EeC7VZ^\^i$'SDK.,__5rpWjTAPFm&[hOkm';F_gG,
+%p+_"&9m20JZ_Y+=J)p;m-K=)+NTN,2gmKFJd-`9qe">h/^H^6?530,B5*''rT<Hn<*lVK]WT2SQZd[P!M_h2.e;Lci=SMI/_sVWu
+%m2Jh(c^<O&=a5t.MQ'<NV_6;+A,AAr1=t`FYI<st@!<OZ5B#qH*VN0.Mm&8NRo/V_GO"b_\d]C\VhZUi`n&]GA,i,lV[ou)@f)n:
+%l4hKSouOi4'i*VcXLX(G8n-=m=2i5Yl9"E5fZ_hQg-*+g5L9&LT[PaER!r+b&)jFXi('=B[LK$S(<Y'#b8VD3:8?59gPFCZb6-S7
+%NF+jR<SX^]e&,???<e;6S\?/X?^l1A=qCMYcaZo?a"Z+NpWI+7UNOiLoIB%]s'G/dYr^]5pJUmi:0eo78t-'HLR7?2N]]FWMTO3K
+%Zd[H6-bb&c(GAp^L5IW;7GK?5(]@TKCS%`GH-WM?>3KYsrKc:(;(/cuo#2\mSYBH[!`.FV&*R7?!^>EA+'_5-a8ua'kHCVWe&U:k
+%=ZdflVn7[Y9<DXh\e[PP6/@7sqRN1\4k<:fNNL17R`/@7:@k1Nc'P6/;jW8_Hi0Eqr#B'K1HV_72o;G_T!g--O@c?GJPbIQO*EF,
+%Y,A,I`RCU>a6`GAA'cst[.850?Is=WHBGd%$Jh;6G1iFXKfqB6_qdJ!Vk]GUdnXi=N`N&1O4dbk6[&d5H$6+Kqh;N2X-XW7V_=BD
+%a1>#c0=9K[LM4#-dckfsoJ5Y7fUZ>rNr#*a7$uZlgMpVO:8QWKa.CG>gSE;RRo#g55@J`(\-T1I%poAAe7gmu4%3%@iC^Gcp`&V-
+%*qnn0NW8OM[Y['\2thYGm7bhmn!g9bFLn[A'K,a_mIEeA5IR>"Kp/3SO*3QIf[A$orEO^?P>8Fp_QfC=DN?/(qekWi:o!\\Y&kYF
+%k.3&[=CGo$7QN[D:'3PF\ikpU&4mOA:ZY?ZSZW(XYLNm)D,rmQEMbUXkVjI3FZPA.VPp:N86lCAbI]fO]iU%aD:RKP3pe+p](*KE
+%;p'=?f7tlMIr"cN,?0!`bZJ4$k=;U4mkq)(p;";*UO#Z#ZPD)?N?s6:C#"oUK`:;qA+e^?1&W.H+/b])^F$nDlZ_s(+19]0jf<:<
+%@VZk/qq*U)IC;!m&C%u@0AC3l=1i"I[EI)i]jt#&;=^#rD^OO\HfI2eC\q_E.k.B5@5Xn]>!JtpU_RBe^Wg\FND71EH0RJ/o<6L9
+%e=Q6]Y[['mfD)pkmE]Kl<&4FKFXq(-=C:<MotQC]Y@b2iFKa+ie#t-.AH1NYCL^2ES=-RJfBk_MhDG17aILjdVI*-;K2oa8`A2=N
+%h4HI%*A)sPH^iHR;nfX,lW3[nE^7D%K"LkX=fT1XD._;T,MUhc;Qbg9QO@Wl@ai`j9<Rk`Ki#q9hL;c;%[;,!UUL%c,@t?X:!fk%
+%]PZP*1=`Df%Pt(Xot2.keAb:UXmC"IU&"(q"*;#;ODnQ7B'.r49agCVr:QV-qt@GWhL96@h7b9:%/s9s,l!XG#>X0N+SYP@iBnu6
+%'s8h/\8tlq4ro*kf&OmGDI?Cb96TDiUA-WpXrXB0_J9'\CFq#1c.gPQo<3s@f932o`a3pThqBW+n;8Ma@*h#-lc:]8bCR'dj=%L0
+%auqm9jcCe6/r@fVqYKlOD2Us*p?]AGf&c+@iL:4\`T#MK(S5Z"E;GQ(/k@;'m%2fg=p0uEi0qj/EBVs:9!7iF\b8U(kPV+j8,q@L
+%bJYKL@1]Pi,TPRNKM"QEZ'VG%#0"q\1pT]/#5fO`>)nJtfT!!s7$'T5G\hc:GIi-DJ*\n5<[-OH,OQSq+uko,Ic'p'>N5At4SA%F
+%(\,7JIEZkZX2S7=2a#[L6H.F012Ch]O+'#3(\r:0iB=hn%IRmmVUh!ULNdjJp1V']M3<Tm%"go(-4TF4CMPRuDgBp::q.ssK?L#r
+%.be=rW/7R1SaKZr>LUF>Y*R(*WdtEpdFWcXRLd;t,;?N2AZ!?<N=\oI79\S"S-pe%nootuA)9tC]s$gH.lEh4T[OKZR#j9hr5a:S
+%hXDADU:EM2(E2CM9_'TTAqe5ll^n#$EUhNUEH;Y)9#XpdT"_ce_hu]V7/?^;r!aP&?cce7md72emN>NG)_\8+8=S9cCnT0V2IV8)
+%4Ql[*Y;r;Z)QeXS>'rZWe'$OJm=ART>0U#mmW#Ln\DEq(?8TC*p<2;9'kKSfLb@)$1JcM41p62j7k=$OIipe^6VWhUeEk#9/8kid
+%7NS'.7I;r&g1be2ImD>Zp[<,p-!3$Wqo2'd]g(ED%"kU99;[>_H*kKDZle.XBC.C$@]C\p5qSZRbZ^NVmfrXKRS9&mDD]gbH,tZ$
+%H$-R&h:Pi[%1[&fOkhuHpOS,^E0/WVf86&+2>/r5T00\6,Kn2eU_s)l\8`'@L7oU1NEo,gY8fpKTCQA4h9J#dQ\Vgb6X_eJ=UYVY
+%kiZCLn.Bb%YE'TlePHqHWlH@_&_Wrb&j$LY<tD;)nYD2R.33AQ(--6O"ap;]/Kj_J-qhXpJ4NIbjBTJp(WZ=lMV6&2aW_,VngHUp
+%k%N?^*:70]UgN0/kV["d`ea5UXE"?]F(EC[V):7oog7!VbhXp7?VY#^Rb`j]G*6Fm?<K(/9oHJu<dX2h&!^o(H!$f(amQnZ_X$I8
+%1X07.D(t^a<=X?:I:95060d`_)(V$117f;G^%;qdBJq_e'ASuc8^$qs"r3YL8;d'i%1:di%ng''O>8*GN__m<iRXTp7*)If`-fOc
+%dJII\@U=ahe`R`109$m,I!R:YVme:-gWtSG7i(LB.M%r*U0Tq@(?s?fUW!=BiKS-0<'o_08Mh_<O$jX.]4#^IHjR7HVcd\ZB0g4*
+%[X'R[Of='ZP_l0Hdj'.t,Gjcqe[ogM<.4a^K&"[9GOiT9Rr'JL!;DEj],>YqFUg#okCQmMT3/S$+[`8B=_LrFM5cWWlnp`F(2`\%
+%QcEfu8N2uR\Q@Zf9//6&4Tb*OM5=bG0e[YGo!,XYI7^RpHXDpoqNg`$8W8KO[8UeT#fV^Zc8Kq+/fI5,]XE+(WOLTc-utY"D>2HF
+%E&ks8g?dQ*T.T29.>?LP7Z"O;E;++QQo7UZVnnOm,ker0^PAYeg[H<NV5+\8$pf,J+UG"C>fNTk#-l`l/dP)Y2:c$?2cVb@*\i$A
+%TiX<YbFt:Cm+n9TkcIEfI`-PT8l*ogFm]tHbtM:qLA=MDb^o;#]j_MQhIWe@rkt&okg#*&:U)d!6juSNJb($>Ch,@NLGlI6O<-l9
+%81r6*lX\.>PTdRs#PH*3c"QM1'2tI:;du]UejKZU?V,#dT!"nZGC>nSX#l,Nlt')@k!%e$;?$4[4"FUgi(cLt6d:To_4_I$@tg:j
+%s(*s)`W3*AcHg"V?K"gCcg[aH9l6+-l;Q].HnSEZhJ>-AY0P+SFahSgNFqkce"(An(q^36lioj#gp$"+6kGb`k]r>:((YfgW?_+%
+%k$km9*sTW;_hFuLnL@8tf[Pa9mfLW=Ls+i:Lg)F'[0o^f@hocrcopg@FcQX`6uUAD?KO2`:O$/Y/fRk^GWk.m?eC'%Dr7?+K6l4p
+%C6?hrej!$W2NhPC:,FcCF2I60ZX9uuGKA&A@-^-HV\1=hm6p"-=2C!8X<C0?E;Y/J1aL*o1m]7"+:fseghj.cQ)OBemu,"u0Vp>/
+%5E5r<>cKCg%oVL<^-on@Lb9uQ"F#2"P[<;?:"`fj+UVI1>(#qO?Uq$&*\OIRn_/8e`Ksa$PfHi7IjckqAG6UP;Ehh.np<)-0O$:3
+%Z;uo-LY7,L]@1qBj'eN;hB>`HM%$DtnU8/3"$f6%T/C]c@^f*%Hf(@QPoD657]k?0[o(qL;AS$Ic+L:_!a86dB^#1*k6Dg\,F_uO
+%*L6LgiFR&JH^S@jLN<1X258]`(:gjT_VT:*?!(ESj"[:rpSJoTFP33l=LR_8D=r:=AKs;T#3GS2j6d9'L;B43/.:Y=$0LF7#a=ks
+%4N+I`I\W;o2i[V8bEKYbnb'A5HlB*Bh8eijL!/li,)80HSHD0%?Y*M%WGm7I(JZ;&:`8c.9UE1V':)3n[(7bE)'NimP/n'@#3_P*
+%7GH2n9HekHdN8iq"j:I!rG[7mn4c.?OMJC!/<3;LgoaAi!#1.-f!<Z&4RCNYq6IOQFEokAe'0)grG#OF#.8%7E6c@!+P(.oq]=F.
+%I^3U,@JOq*>klTO7:TOk?DDSDBJ5B_q'IX3a"7fl-iq5-JQ:3*)f'U=$)[)MA:TN_+br6$Nt)*L\YSB*B\E+&rU#cC#gaD/7IQV9
+%SAOmh)HWFAa0Jhe1&Om-Qo9nP7'?@M,?/`BK^e1a;>)"_J]9Ze/mSnOh,GpmMf[]3BP<>NQ4XMZ1)J-AeMA7nJN'V#rb`=QXQ;.Q
+%Wj#a5r;;Pn1;q'iogH%K>ZcuQN_jdIC.k(@F,FNdIU=-q?qFh<[X'!"Ne[bY_H&5"4FDqQq0N^YXJ`>=d`!t0F4j%ncRY==`emlA
+%H$&R]^m0/T-').tK6snbK5F>$Fr95g/6_TCSe9XoY`cXGiCKgcoPM6_\UVA1\c4SMQMY:n.WqfoCj0]PQ8lelkq.6d9AFoYNK+QK
+%b&MEY8OWNcBAYhseR_;>U\4J?g&$P`RFgnYfB]?(MlG=35-aeW=bMsDIH-tg/16Z]iu^Vro<l/'[iu`&PhY3XE@[aq:2Tcj,%&Qs
+%E7FOW^b:hpoeGiWF5.CIKIF[jm6Ifn)[4uifKou@VPbERg#j/UMGB:.F^MWH1R7A)@HMl45KsBF_b4R+ABo+^02%gWgk!;l)ka):
+%mQ`,sl40=0$PYRKP'h4eIsb;UO!+@$"K6GQj/jJW`,;ICeSi&^KuVq7"6NJ]9]e^V<nT\fqSsn$Yc_mYo3[&K^emVk.M@8S\Pt-s
+%[O,Fd,%kD4TCq524`JJ-A0,!VoeDAfjdcra\Z8\t<R0^RPoS-,K)puJ;7Vq,e+7>E28D/;eRETTYM:M3B>[tNa\eG+`?TSkY?W3L
+%R>Vq`G!&?5:#oem%ciW)J"4XV$.M4HI/Bf!B30L$5[LfD!Y5Q_CH((a<lMtD%55/up)TVcgOl/kX9[qZ8A!:$6cdptm:!D;]6:G:
+%moetOW=092DV2jBnU[@:mPtK,BWQ1CFMtGl)W8C+g0Ls;at=201jV:=gf(NT2ulG:]$n/f3RZab*ZO8]En%(?7e`7k>cDMtm/A\=
+%o[N(A5l/D'UWVP5GBsd:h\<LWS&*=FE,^S]S#tri/DYH-bk\Ms/C)6nRYtV`R-X31UC$*]oCgFV+F/]Ja)\h/>&/6`21T,"#"0[@
+%.bG^uWc=quZTlM"jM;_bQn^Re*i`[(49JuL)[erWZG&c&a^pM?2S21(Dn,Ts]Y)]Nl@eMK9A\JAo"e69e'l6>>(DpJ(+)4F]OdZN
+%RA*[dXWYg8Ksj^g-2.IE#EPqG`]6oRL:]\l,aT82RgY9dZ%*HW,PrZFJf_?*AfRqgBrNl>R"60#fX>;6S@DnE6"><nb3P]d/Qr@E
+%l(W%^*4fes+*aklSVNB9@Y(pu+e^3G;0?4-KH9[&Cq-tZ[:is9KR6.?ijsEu)3Q^H_V1buk?W_Vg"nq9CKQQdk',k:`M(uL/[A,)
+%1PURD8(L*2g=>O.7IlJm>bole"u)DXc].paYK4TJ/EgTHJR)t/kJH=jB&'A:[XEu1KJ&>5;qO4l6h'T_,[&tF?&N`5>d3uJ(;>l%
+%@h)\Lb1<>pkOS,OaJE*U:B@:p##G4jRR7qfbmW@A)!0(qqnbTQ0"<QH.dI05_NtRbjU>aJXl8-QE,Du_=rDQ?i0CjW9MWsW)S'Ku
+%M`EaR[W!SY[<;WMk(6huaE*'$OtSPOSRJ\\r/r1mmXL]4_U=s/\X<\O]$HYE92Y*0FO2IFP=$-T?t$HGi)OV3*76CIM0ADA^:mh"
+%;e]"eflY1C*#d.8.u*)kQa1)/X@J:MOn:@a@[QXVC%dWf2KHpMNGLX$h1_LN\s?is\6tIVYCcG?C]bq"p9eV;)n9K8"O1n1AF)Xr
+%7r94]Jb1ZtR[]X87uo[72o<g:UL<QVDf4so`#L'"Xg^@EH/X"'a1#KA=fZ#6bp4BGd8%rk1U>P.2r`$1a-0q_GIe+e7.D`XZ5XlD
+%*[$f)8YIIie&V'jcq5eVW"HCQYeTSe,25Nn]`@?P4p-G$"k4W5PK]6g$cqErF'2?K$_8`:9[%U>'2o_$>b58teao6R?7FV8Hh[Cb
+%98'BCV!so<9G>XZYd"W/'3[,'J1QTnj,^gV6UETgqW@<L!>=,/KuP3M%>-Es6+%bs0&$[@aoOQP%\"o;bcoL1)f<chO77UVJa&>8
+%hZ+;3jmD'=ml=t9^<HnW'tCT,\i^sU*bmF45A6'T+m=*!FLi/S_Pti:YfM]I\AH"3Y[&;3GkNmj+h0WgW-M1.!=<TU`lQ6V@^f*R
+%KRb6Ueg(gnFGZt.Zo;$9B/N=MM#jVt*aIhj18%6lS:Esg'X!Z8E+q#RMJ6<M1N/=;9XNS^;Dqob[_pd=Q4;)M.>!n:Qd*AfNOdOi
+%5n,Mc_\K`\&SC-Z_H:`/R6<LW)p)E&nL[-)Oqpcp5HJong"h'Ap.M#,Sg`+\md]92pbNJ/[`igPkYX6C)$l[;OWPjBc95iu?q2g>
+%?=^'+W-)jR@h`JWqj=5IVuWh%*u=1pWsq"TMb3OCLe1o\^C:MdHf49h3BM5G"5<EAc^7BX$]aRLJ:oi9[EOoD$'oG%Ub.HUL>g;[
+%&*I1K"jmNAlS6RO?oPhP7gVd=j9nB./-jLXC!>PTYs$tIbdW=F12hI#9Vl&bqTAe$$Xc;Es)sO?*>YN:j\MH]B7.gb["[Cd!<^si
+%W8]([+?*s*%MPAWn0lSmCj@(5K-TXcdtTHGb&VrOKIR0F0-`Ci6$b=BK$Lu1]ZKVUKW6%*P81sPOa^2GO3e^oZ-:]i/3eVG'$GGq
+%SR<p"*[X<8bh^^dEc(JDFm>otIfZg%a!$bZEiHm\nKnRLaeaaNbKCL@Lc2VLH#=-!"u#S*AJYU&HV'VQnR=(S/-G$='$KF"_t/as
+%-([aAbGsC5?`mL[)_8O4.UVrm&WqY%k3b"X8ofI[PQ8OBk,UoYaSh?af7h3lpX'hmGgafVi]ch9#BP`fptOHN%:X43S"08<0BaDM
+%BkP+Ga:M.CX*'p_plh*P$gJCHY9-#4*I7U"hG!taCX^RWAKOOEo8NkEgR,3QN_iV2=k"flcT_*-m-Jfd$*RR\`KRM+[QD2o\cUpF
+%cecDsb]dL,G-ZF2jgfC[[LhhIq"aa)QGOO5@oqX5p$f2OmDVlu]3D!,/)sGKc>W\1[I8E)%[cJf@&D9*JOJFUq,$`r2&"G%<3:ME
+%)LUR0n5-O\R;*?D[If6SFlcl"+*jegpIr!f>ipL6g2nr?IAg?D9Js*MQMs^g%`jQSq2'm,Fb>><ncKD&ldjACq2pH4Fb:nso$SV[
+%eicq`kO)I?6e+5V11[-SJVU7JcVuuO*S\CteV;\\J)m;<h/s.Ngp6:%WccWe_hp&8:c0We(*g>Us%p+@E5i\'\3\JHckg.4o";k%
+%a$\Cgn9lmoIVB<m;\6=sTNMbZfC2To?bGKp%oqp,\#/\*M`k%a5c/Kb<6YkTB&r;^"Q[iG4KaaS>kk"-?9C";6e0s"-ofHa?l`Bb
+%#0nPXGp.Dj#<7(Uf,<*-C^tNN,Au9HT'\4LHs%7J7WA(V/*87q`?IN200G_68:Z%m`ncY4387;R;`6b-_fZ@BE^=rY[F<8,Q0&dP
+%c#J'S?^0]-B6,7=(PHF:V#_7"D2c)G%+"&9B<,D<RhMC<!R<UB=RkE<3Pa=n?7fg,ZT2pf/74Y(K4f7aOIZ9'i7T+.CnhL#(nStQ
+%c??cPI#lK4fb[D.[Zc--+.g^Xc<ep,lo*d<-$.8bn8+,]UpgYg^p>&q?oTMrRff2*JZa-_2iS!df&9r%O>i.&cF0N'5'Su@D'7_=
+%bR`$S5A\-gRMB%=DDM_]Ha+;A5,1"(ME*Q-c#f<ViRsYCZ-emRkZTbLA`RX8)\NgRi!c4%!R>k?XLGd6ZNb&Xhg)\]B5;/6Ee_68
+%Hd?.=DeH+!f`oUAoldbmlr81iCj8+4CThR3cF/(NI5u4Yj4GDCTj56KBBu>AX^9=[%W!-2`T$Q,k;[5-gY);R)j^#;[P:j]"ch:[
+%f23<FrAOLWIQ`SmFF!$=lWGd3!?#P5kI4KJS05hrj8,'u)!?\p?34TkJ/%tp`;"qf13"MX\Q3NTi#9j`Jhc:MLDZWgc/BWsDM>0!
+%*b$+8OYGf[LDY5\oN.;BJJdR/*aB72mP$HLS;;16h-VX@HoW]hLD]3&-$(fZ\D#g>3Q1\ZaEhaB3"O;DEQ#A$m-%=Zj*%]&b<_(s
+%<#W`7ru>M'EqboT(jBtiho-2f$8)X%pQ$K;kJef.6B#,]U0&1?SC6%Fo<g7`j#/a&,fD\9NUPQ:72A=N0DK-B-XtkBB^mG]j!oo0
+%Ju1++0s:22r"NUFKsJ8b3Q*n4A[)BV\:YT<(I3rFYmEXI(geiK4>1069>2s9(t[3'nMXV?".9ZSY1I'2"u-UZ/+oZj5D'g9bLs9O
+%@bd[U1+-NNEi5D2od(g%+ZGYb%V>HlEG'1sc\iWQ7,7_@@XL0mAjhTa@n4cT7>r#F5`G$8C&JHLggtSUrW$D4040/41!]Z.rF1S&
+%LUkps7#WpC6S0<5^'"rQ#@^s0@a:#X`YgVAFKtcAc$TP&l%j?1$R!V_N3b970-;odpYP4V&EAf4r`k8!$b=#?`&Pk`E'NMi_5>th
+%F+`saieo&$j`jG$GJ`MP^=E(DIgRpUrIWupLiHANpeh^aMLV_QaMknF`43M"[g^3bmR=Q+6B%CH2dIb>*.-Z>T=F&GqZatuoB\+<
+%1!W,:=3V?;o:a&:Cq.[[F6IS>*:1jETu.UqZ-2`[k]#ju/.3K$_'Ass3daST&<ljNIg-pr@)H!/]QA8*1,p`C_,$`A'l:B+Z@5)]
+%\,fb4,Ns)XE$i[&V4b_kfh3t8rWG8el',d@q@RhZJdnX3`K-\0'l:C>?+CM-h!Cm+jeBX-Cq'oqGp.:>dAQUMk\tm]fJ:h4g7-$Q
+%6AO=.@(7J(\?Zp>=G8&r_bGOq91=UdfPnkCh%%fjHkG1mU;PLnh*6Z)B37_iJ.B'-=\*>;&3=(4L@b3:k!b'ONT$GWoJEt<Q[fQI
+%[L'^ar^5o=q,,K0"gb0!^b6WIY2&"frgl*I+6LVjiJP=l>d5TK_j/^:o)'Ig>bOTgVR0TM\:P06H%$5DY+.NZ1\)4CE.oKXYEggV
+%*Nk2.h)ciS7>EC(8:7X+K+:u:e)sS5-9>DJL>,*a/;+Kll7bGR%X5K;o:a((p18O5E!71u\9hL*3aC>X#0LOlk]#Vpb4toW5_gj_
+%a[C,$#p$2"@=A\,^=7NHU%VXMflAOlYK9F9=5P5Y![RUodn:c;HiM69!7^.b>VhS=;fW$%21NlHjOgnR.T:#0?cIm-VG["=^4pjC
+%ja4i+<+bU6of&E-(#t4Wk`d&Q3NZ>@O/(C3fNW<GS6_S_=W?k1W(r@=fn:T<%S>h`5_F+R`inWg6sJuBGF^_\F;Ngl2h9NCYgZ<h
+%I[I/ZH=mgOrP4aA]0'\orpa7X0.^F</f7u0$b_sEA5!tL3)aX2_-dtHM'\]NDBbHEMd313bRDm79#mI5([lH)N)nA903DF<*S&5W
+%hD`aupb\K)![?/-]Y9UHm4%H<Yh+U0pVdnED.Z\!h'.p"gP:N/>YZ[o5IImHkh>:lQ'f9?2!LAW7,dh"L^.t>l\"Ss3-sH+9Xp]G
+%rRJZHjh>DYGf7UBOBhaJV8R_Q:aFZPIS7IO0BnJG'--JSN4<ji-pu.@H.GPq!*iVI>8Ir<f<&:O=tG^:YZpmq3mF.=QU[mSgk0b\
+%G+)`3KF_t/ei:+[AP5+a/$<OPq(kd@(3pE/LR7OqR;mO:kjtBq8LrpM7ahEl9fuLT$bu#*%#MsBWN:1Ga`i\A27]iD61NbMEJ4LX
+%(YBOM6H0G*1"rqS&V7d'NaLMJ5Y]hd[Z&f'>d'f$X<k$,O)Y7Yd&s7UiV[fl/HHb)hNrDf:G6uhh"Fp,GM,[.0$?UkqfoU1C_<tS
+%1_>Ck.B44SX`#kR`cuBH*'CN-ELnq;d$XXrS.n(l)-E\nph\X%rlVK/]FIulTCZi7M_&Kp`_?[h;na)-Z:o"kOV[cAlEFK'@T,3A
+%d63i:7,,OcgLYqDBWUlIc3>22O\'qTZd57a@.M:[Qolu2Pm><2k';67,HJiOE(S^3btNGI40O7\j5#a&*ganO\%WPm.``FAXY7S"
+%_2Dk1O>,OLEPs!`Qd*<)=[5!6EhgOEVZX'\VJ395:jC:MNC%+rGlC>QJ0u;=Z'i5dikQ7L+V>a-R"Gh*,t98u#fGG;(Nu`pH`S+J
+%qoB`6gPZn'Wm&JnV1g=+e@OB2@/Zh,*A67Aq8G@-CtgA(=Y<S[91GHiN3pZK!TGZb>oBE0NXj:Oo%e?)Z6EYI^R$43CTI2UY9oaV
+%n3]^"<Lu<'`k4I3@_&pNkOH*e85mQ;T"gU;Q><PagVu=h\IRL;Y?87+OH:j%(DP&U#)dKeb7Vp2Yo'EPrRHQgZ$aS8Q9i-eLB96M
+%Eltk..[JHfDi?V"$]*nkHa1fj15hS<hT!#$B>C^_bY9#ogru#p`eiK#)_Y4ZVgM>HnWmG$l[a?HN&`HZHO'9UZ6aD"anC`+*os?p
+%liVjq)=;BirSH>^i\O<P;J/*Y0TXg]SkC^"/1R&8iBm8;_sQgHCAS9A^os6;(%jRe\D<%DQm>TsF)g8hH/NlsR]p#Pfrn2],r-Qa
+%I7NjgEjo^+[[<aW7aI>eZ1YomkLU%mjn2MuZ#pfgRZ";78]NqV)!,7L)N6U/R/Pj:G"hdCh3].'9=t2%^CaN:XBMRk2#<V+,;@>0
+%Ha@da%)?.[H`^BU:?C*hF)fZU.5@/Y`g^n-r'KQ<mdX!-Bbg'-SfrO@pBt#1N7=$J()5(IZb;#raBdS,[>MSMk9-5NSZh7l&i5=#
+%fiOeV%*61(1lBXhq(Q*fRK5I\PR+e4Zbg#AcE0678;G;G;RL,1nQmW)a5SB)hX$3)Fon8"2gffjbsZ&GPE4apiN0IbC*f%4#>aZH
+%X7##Ihjl3&n#S^c`_u,f]=#<7CJ[%GBRPg@Z-(bo>PtOIeiEYS^\Bd*<K]q?kMj&EI9R:QVsVXI<O[0nZu\FCI67#shVN9Wrm-A`
+%k@ME@Q#;Yk*Y5/Y:W9dt*f&A'X2EM-`tMYV8GaLT)RiqmX`ND!pNlij-,*aTAO=#@X5i_9WpJSi3BDA0gg]u_\!:i!%R\4^_1&=b
+%]dnhteqP!7UW\RVn[NoW(sbD>2^TKu(\M22/=FX[eiF`e5`Y"$>R89o]Ut&U61-SaMdL=0n2?_L[>MuNC2Q>S"d_`GEe2%J/J9]2
+%]=k"eWu&<um_]CrVSq3.e_tD='VW&Cr#=>XC\B7PKLk4bB)R((3/CkMmk.AECmJc.*aIUpHLAuBM0(E:.9DO)2Vot)HUtV>HI$)7
+%?<MKL\l1fnLjX>\D^TK/_i#V6?XA*T';#e!4C!RI\+-rtUiWgW'!InY1@^^K<rTUYE.=5n^$P%^pkV;/Ii#O,PG$*_/>$0ijn#N:
+%(8^bGc?LmHc5#jj&pr*`gdg`%!U\Fu21tV^:=I?!^3$4?=BVK3GU^qngE3'^OQrRuhEJ]dGP_HL<QK3#!e7$%JP<T?%d\FI@@QuH
+%J\fmCH`I`P_I>nhf@B$nQ`!XjV;o)Qpg#l/"E\)ps"3&Q/UnoBHfmc&>2)3q/[\sVXmpWtdiY/Ud&cZLiO<DRQZ]JQI]d7.\Sc7S
+%#_aVohL,:mm37bH*Y#Rc\+_1:A#FPFX/O(@G?FiSnZC<r%LK=SSo"Gt,uMltB!oP(7&UbdCHpD&/i4J^Rtp6l06HPV:T)iY$Al+R
+%g>R:Y3R.gA]o.uViU:;,NK%*'C,9jfH5R3FB:u3+`u[t\Vh_7pgh5S/d$YsC*^i-dm+H4Xjq9>]^KljTebl1uLjaV'h[Ve7;NIW(
+%B+"Zd5MV7/a)EI)no+J4s5@,"jiR3#)ZaX=#50g@rVB97Z<*Ie=>hqjH7JcGmm=`/Ge-;lG`NuAC/1InLOB!\/tVGNp;50#^(#,G
+%5+W\!eG3/?$0^:]%il6`humqBcYjIcp\&a7pu[&eND2pHA[GMDgLr!QhpM(5<(F:+O(>7<Z`V.;R2`HsDQ`(s:J5\,G:eX*O]q9l
+%8=Peb_o*qA>V#;sjq<L\r0RV_?+p!n4p&dLdTY!2=*D/OHTth*KC91Pq/+HZkURYqV_59]Vu6)TTi_%Ah%:aCZDF&,2sF,.4Ts^B
+%jf,ej'T,&n5+aU^mER]KhH>=Y1tKANjR2uc_Y8,O\EVo-MQN`C.tu":DEp#"$P@NM*FQpM1.!gaYOh'#6j_1La@23.gb%F/hBe'T
+%kbEr)l/A^G&H/)ujUg&#^(/'6SPSfPTbANBZ0'V:'0:P()CkbT<mk=E]7fnfD9:8WiHSDY5fE/2)[a2Y'D^SJ7ilSY]%p/cB<L##
+%*AicN8cIe!i^M:5mj05s[sH`[iS?GYXs%6KcpNcVI[[e]!Yr@.&4=kc?'5(3KsLC&iGJJS%^FNCZg?5[;+OlN2VPq3I\lgE3br:Z
+%F4l?Hl*:-:n=^LV_-(XKI"C\ZfYcCe+mS0s[Jl7PmVQ7jgV`PF@9hc5`LH6W?JVL5ZZ6OHpR*'scquM*PDef'B&`^8m`8H[^ACiS
+%\8JpS,CJ5C.Vs5LVeF'#EgL^!6,f9kZnD[MW9rUGS/:tsr3H';>1gr@!krt-&W6mPq1n5n>.43)8=ZP5ag.gcT0C@TmYV75UN5o'
+%p*#'QWG2Q_He,Kj8mqT[GJ6#W;1?nPRq/_*/oS%T_<_p*94H7n%N"D3pRmqF#%InCqkIET3\mNWE;Ir)2=J!Bo'NL")mJ7i@R1j7
+%kI56a\(DIC%-2VI]A?M"Y]5:b(A6cnPCj-H4*Ms,eY#`@4I[,D[Vo*;`a5X>&Qlb+na$aJAi]ti#<E9gmq)6pjFfWGk!%e&e40ld
+%%Ir[l'kC]-G-dOXAT#0FG?b8+M;1CVPAJQDXl_[8M&VHO49:(-'H5ACJ,Ha!G,.;Tn_:+B.f,oI/++HA*FWQ7InO'hdbRms2:4l8
+%"<TdgW;CtC4+'*[*'JcelIA4#Baf!glqQi\2S-ks%A[.K\*j3'])2!7HhL+fF%]u<ZiS9URb;$:H4/Cl07NOt_2B^*;CMBF#;;M(
+%a5nYU^m#ASc_j+3(/=3EO2W8Fg%3YZ(XeMf7t%0tpg:5q_<Zi3^M@u]*:W3Z>j%mYL32b**^c8gWSHKh7BIcbHF&'f*qg\]QdZj6
+%qrq/(1E[IcnRU9)^7WY.PW/^*2nEGphgM#n"t>T&NKeW87Z_*WI=&I[h99d`UQJjS\)!7cS]U'qI5jI5cYDQ77*3R7hE`m,Ibi5]
+%S?/![MA<l8XI^6ccb4>`YTIG.g-Z369q2q:O*atg?6^o-4,3@[KcN-B\j/66I2?kZX2Jee*`"`_"1jYLXj's0[eEoh0%9uYa-:/$
+%G,gtRd-)GTNVjQ]ottpZkMK:0.0etr6<rG4LD=!7as0*SpU@mV=P_U=]GH>qp9$f(\C8`&VP@;Vo[0;H`2EJ!HLUT4W-^J\8penC
+%4"N'@Qf%d3p2[V#"(kTV[pN4O8o*$K8F&WJrqR$:"+:u6-_ET00Z+H=Cj(MdH5Xiem2Z4Eq*&OE.3\uK=[QGAirnc<[hgJK&&-81
+%DmWY\I!mB)rf[XR='[AMcr&GEKH*DU_c9AX35Nt5s)+lq(C!YP>Cl9/;@oI2iTN-)J=",fZ&n_#Fli8b.A>JgTco,O2NCb3eW4Mh
+%Q!Ynt;Z6cdKe55uid*J'Fj^'06oqZ/Q38=;5[p*FfmHsn%CASSXfmjU;B$B9)0pS?G'S8?+7mgtr,umL-2\:VGOLDQmn:,dYFNlF
+%>A$7kj^p[Oe*MFkptT-Ci8'1G"N1;g;ksJ%\s'g:j#Pr,nTV=!n's/S(@/"D/,eRIC26%_>KXX/AN04_pXs'HD>MXA9GK]Jq84[k
+%.51ROLHNR;cU]-><G=81p5-bHq;+"AK5douZ0CLpYP?]'EPmYKdcF.XI2\4@GC,.QO3Xhol)1tdlpmU>;mX<[BTQ]+`3Xeu\4smW
+%g1+cs5hLmQZX;tQ!&55"3H'Or$q5Y>HolKnM>m9^eE%!`2\2"UfhNOn7q\m]:cgVXM>@.eZ1p*I`PqSr^gT3$fIc;:E`Z3%;Go&4
+%j_3X:86t;"SrjMl]-HX[]6MWCcZ,VDmAK5ub/LcT0`,Vhs%^&[3C0R9'o%Z.d9L#1md.UeRh_"XY)m)n)8D!V$6@`,nSP_g6ot?P
+%Wpn[5FDt=7hK(HKdcJt>)YQ^Tf0BD7Yn1os[R1q5Q)hn%f#EF)FYN0m/6GR@Q@#tJ$;0@J[X)1G]5cAQh(Qnm&@(,p#B;LbH8C^T
+%Lc7c@T2mIumhD7!H0ga\)FY[\ls.4>[Q\">J^)&_Cko=0r[:%AWabk<<MqL(X\%.qe(k,SPKWdfeY<);N&8gb?luHCE9&e40KB9j
+%0U1mP`cdH0I5b(^p=O&4`oFae=7IO'q0M9XU?%@3n2mt"GdtBACsl"'fM;U+ii^ek2Y;3o8jX:gJ#oF!(QlVb`E+gA=WV^JHCaU>
+%He1FR:"8l0ZZ?;A/#c%o?g.914".Yq9\'>B@ob74gWjoNWP0$)SLa,RF`m`BaE".:eh[Ks6CM\gY^9O"buI!WenT;^B;X_U%ShY3
+%>%sT9Y[U-Cl.=Kjns7cXM?BZk"bX'MYf1)9<qZE[lJV<P*K9+_c#9tdrn:^Jk%ObC"($]HBq0J\OP(3=VOrN`a6i[R1`kMmD!tot
+%;e6K37"]2u7cLNEg+KVq,$X."E84!0Mj^XF"In?A<$E44#pI:X'q'KVj5YakjqoYda%(B0pDSnRA./<3Xl?s[M(/^P]"L7U04pdY
+%2_p)nYNi/'NI;#b7HniY04sbaYe[D\4!YEpY1U9O*2YhLqMo@cB^e*iFQfCb-MlB]I89ue21uH\nJMYW`^KDU(dMI,1UIW>*UkP/
+%bUrQ>SRSaASHI3gK8O-fK6fPe(fGf\0ccG#K=X2S>7F11.YDaq,\2,?6UEW,*E8u)NEqt_C9h%0KG9`8]Y*W:(13\h6_&l\FV3oP
+%`Fd`\]A,pC(idH:3D))Z6B9HOfYcq;204%DH8K`Dc=M9P/F5=6d3jJgKUs=Zo3tfj7dn<nG(-X1'Z=7#0=up""lG$6>@"8YquebB
+%c*_BK:<_*SSI?u;3l"B`(A49Hkqh=blt,QicahN'e!-M0<3Z+*=TLBrZE.Scn"u#S[@?U5+WX;;X_]g9\5drO2_NErhGG->8[?>]
+%0@in9ZaJp_H5\"A5W^5J(Yq]N&#shp1!bqZjf-G`BM`a[$1Tb,6/bYgq:H9CqtplE#s3H7BHLp3+nak?[gr_L@F?SfO@UX5^Z')1
+%%uIY*RRF]d"*n:"cC]7B>edn+GFLJ$qb"??G=\h59QpGN1]>PO?P_tDJMK9L;U8q5_e2U)GkXphW]liCc)AU<#pmnd<%V%'W^njc
+%U3\PX;t%AH)YSkV2U#cKF0^9P(TYqA9UeIKZajSR":n:#UY%r.C::g+Y^/#eY%00/")EBk%fquB@<,TpqF[M8%ndiAG5TTu2?Us*
+%_5pd\0&Y/']#JpkNG"WX4M%FnnbrA!b@^)cf\O,1O&K];)s9baDT!iV?R_(n^KdrTb86$I7GHE&"f6"F%A[:FF^3V5RMft[m9G9k
+%g:i!K6ba)FiHh]m%O;)d;#J;G/J`9Of9[\?q`q!1T0@^dY2F4YD4]i=aNBM-NI4<Hbu3Eg>`r[eAu1mh2t%GM!A,'epUZn]p*q$Q
+%'N_UWhT?;A[\?e8Gi;-F=M,X]YGZE=dP^6tTSa!eYC'9e$?&,D&+pDkTNdRZ?%A19)h&2t11$<=[IW!lY7H!<mh5Gj2uS38gRYIP
+%HVn.TDWrcKV6q7:Lt*]>T"iWfZHW_I^p"V]bW0iJn_`r9-g`SV%p"CdYP<kOH;ipqQCO,Ds3HHORI2^&3&]3eNE@(Ng(P$.!oGV>
+%ScA="RH)"=aToMn;9XNuh[>E<V>FAk&9%kl2)-k!&47*&AkUZ37EMZHp\>"tDr=D<RuH/A-Sr9,g-sM`n)E0=f-f2sJhMcdf>2gO
+%0D0I,\JpX6:qrh7>sI$ZkrPiKHC2;<FgHY;X@"UF'&AJTdXLdJVn^L,?Jhb8Dm>KbnfE$QDPOHE(rsFm"0&h%c7(KhGHVW>r!5%8
+%4)m,<r!5$Ud-*D,@t(Dq!$"Hq%R38g,SR\F*))2TI$pj,js1/t;mP<jb97)V+gKr7b97)_RjfoFYT.*P%V*HsQ9u)Q0$0>:QkMj\
+%5re!Q#,LiP&JPX_W/18be!;jG@*[(C-r,kg/e.#E=7'ilEEK!<leT\7BrZt)\@1,3&M:e^+f7[Ac_\_XZDie\TaR?HCH4FIM7rd5
+%Q^7;@5enWF2nZ_+_pbfgZsr6;RGM<dPg6.@s5Xh:LOCSe5pp1D[D>.B0'_pKDn"pl%=.Nb^"QEY.piVqB0TPkikm:[We9^M6ROg+
+%_h9Df7BK28^bLu$B:j<l0P+Cf;jr?g\^Y:FXf:!)]0&d%L<$jUao2tI>Fmd4H4S@Ud9o8X3?2(rJD?o6rj8-e;6jOjf[>nl-5r)2
+%3/np/meN^DSgQb;8$D+n<_e1_>XGgi/r-#aU=</+K;g`INI>/jB57.hOR8Cu=24P,idW4^>NdcZ37T/=i#^ULSO+tj"u1%o>-cN&
+%R,K*a)sC_lQ:&(1*FY]8W*dndKJM(dr/p>=$"'Vc0+@UL7NQ$kLlI?4U=B%-8EfY5+usuj45cSP*C^Aq]$]hR#<-:.VA7@V1"80C
+%#2Z@(j:I+tX,L/JB:(dX^'[F9fjgaQhg$3*&6JDEmmd#oaTFr)Pm`S=+)uc&bt2t.Nn3W>)kN,EVVRSV^"K>KVR]p/+["H1rjTM*
+%8a^t#p%c>_UgLB^1Z9=U=S+RY5Q&g@H0'D!,SKak!Fi%_,'1-.l1?bR]Xi#+0sS=pil7&4Yp:J$_aO'L%^c6](,fYKd=3/rJ_Sti
+%:d7%eL>'AbD(,NtA$u+"HP[P[O(>bos#]!,m+rKrd?;-*T6Xq6^LBuW^6SR$?;:%EMr9mH4?Qu+l,pAl"T@Lq^9_t4b-gu%j6YBA
+%&gFX<,-f0j1IAEV+:5?c4[Vot=$7,d)o?h%8,-Z1c3%!>^'bemLm3PW.]V;?%7(IrU]VZ>i:&>UEZ_G"ID[RdKTEniA<Qr%>NY)o
+%`!Z$F)Is"QaFR<]'%#PpP<N9UQh%8`qi+#6Rk6Z+D<Q%al)@$?)^*;P2RJ#G`RX,B(Kk'@S.LZgeHtZZ85u*cZt?=BREACu'1qH+
+%&J<4D\c,&V1<YE*D;SZ'I)"tJ0(RD^qhT19?o6E.0@=m:)Ssb(VpQ"T\*OiB1lO4MWCYpMa.^thqZ?[UQ,V%qg-JQCqn\haG!$l?
+%N]1/h,l)Cp:QT8LdEaK(+I2$Nf_pK2&1LhY_>mmqlYS'B6:pV;@9hUCBY;HrYVf+hM5o``2]Fmj;hYJ9POk^*6Ej:YNF%.JY0`RG
+%Xl7[;1oNP1iEI&*8,\(BrJ-`ad)j[9FR((:%>MRbm5n5rJIpt.67%.U@IXmIqpUaRa@dMp`P=%^Y!/b?*H[FuH-Q&WSuJ#40k@$b
+%!MVk28ODL7n"'':e1T&*ZdV&u4q)eq-3ot[MQK8$e1Q3'J`cpKA,*PrabBJhq_\<^;5FSR@k>U(q!W7DGAD,I:$<&84!2B82K9%3
+%_/pC%I7-cD'-qLL8RoD%@X5WpW0\0/ZsiFcmPu3EFTGr>&tub\4:IeC54`I@NeFVq]U<bb&@k$&:s&&Ql7,4m)\uXD&H5ak)IkZO
+%FM*(L`_Z%b1_Lgk_n:tc]utjOd<PT--="rF*15,b91D-C0B#TQU;7C)]r=tO3.YJic#ClE%G!j\-&p34<#$s4WLgBn[L8e)3H[ef
+%j2pR]F._,g<8j=4Cd!R7cr3C^`HRNCkCK.OF<XW'LQH_/#B?qZ<nMlUN/MVNrfL#<$q109oSIq74,!7W;-;J"rBu,sl_D5NDT(dX
+%pn-aP"\_Oqkjn4@,GE*E>4+pm;X2#7kDgrIT0^R1P9csJC@CS4bL\$IUGRA;nP&ghr[PB)^M_^f*3YZ(Nh1[p+FK0\4MjrCZ:ho)
+%+Kl[29RAXuMN[ScoEk]^%noqjB0)Wsh]behTWd@n87tI!>@2`5XDXMA9VdK*8Rr_LSYi!!BSS4HUu[Z"6RC&chlnS6g_>JDlc)Vf
+%K"7fug[uS4f#$a@Gk-0JD[2jser9u+\RGo.MYk=OY/fqIe9uWP>Ib;`Gug-ZDsbP;kpeNe4qM^;nB$KLRuk/R29D24K/F8H+lp*1
+%LoZPgLUZ[9$lc_7lam[i"P$n(>n@+tl6s>8&>BL5GX&VpbF_Jr2Tbcjd6aH];"lX$4G8^h6H\Lt*`J=h;@"0m$8KqTUiu/>n]'6R
+%p8WLb7D)biiZO/>lde++$?mFUj1%npY:%)f5eEtUg3@kIp%?L<=I:Tg[aYZ%?)Dpsd)SIPQ4%\J>n7/&_`E[u<^MC[E\&2QU/>7%
+%??(W9!4K9CgFj@)fg'T0NV*]_j?HM'KQ%j&1%5`@W!]sHJrc=hok#f38ld%<pC&Q<0$hCL&7-3L&.!8S9aLFO:`"/lZ.4+j9GI$+
+%YnsHqU%V3%*t@]#9XdCZEOaLEAAA.%QmfU/[T\'j.W1u5MGZO"5),%d8Q!g/<VC"1rOq\MH1]X:\8c&qjUdcfA8<nFpXPt>fb5@Z
+%MC_RI&b]Pt*XdtcAdOaX(;lQbojTm:mN"Q;oQmst.W"79(Z%)bp3JM&(fU>D!5F>NL"a$%3UqOhi!`qBMhKffT8,tC2fA/S+=[9[
+%Pl#\TFNB;o>f+(n>0mE__O88T&r)6bL@S&FbWd-rKPdEN$+8)<0-K^3!5gCRK8!;-Q\Rpg=BIFGF$Wc)J5G6]S[(pgK>Bb"UPcUd
+%pUgSPpc')8jR6H`3[e1:fi(ko+2j9_;;)C$q9h5^%ZC<a;1r;/.LJ<HK^obakXK)7?u3$6foP#sDa%\u];9jNcZ1MmKi*J>qtA8[
+%]=HK8BcMmg$]SY5mf64jr7tUR7L&@4rW1?m'*!gTr!?0:G7$?c]nKQ#d;2BCc9TL-TS;e%5[Gjag]cQ@_.q3$.CAuZZ">Y=qGQls
+%^P)J-B')"2*T^W%;;F^,0eR\DZ<Z`;m<<JlOFVXn^l=V'[t\CtYnL*"$kcTJ_M.EA!.oN>dp(%-PFE0j-L39@[QZhS?N@#k-s5-)
+%2YIF95]ZSUS">tmA*(A=9UkjAcYT-:'LW[M$Q*]1%fdiDW#h4Y_+V1rADP?;o$?b\,0shV$o0GjfSbkeIO)KJ@e:bu>c0je\X*-p
+%Hi9LQo^"Q-h$M#^4DWa3puLF(^?FCf`j/;o!8!62$GlA9GX`rcB%)aJl(WT6D%u%+M/Rh:^'Z`j[l1(cY`C.FV#COf#fEX:7tp!p
+%987dm4A:fh<Uc)XO)[GlO,cBC2s[D5Wpd_8OIBSS)D&Vu/So.H45^AUU8ATJGoTOa@Z&-C^qttJos2]5T"$`oPRZ$l\OW`F>`C8G
+%YIDhMl\@.a(uA4/:OknGYI4'hWf8!CS30C\,tjNC=lV'd)OAg->>dJ@\-.sO7Edq^m5K59S@L^E".>WD7GK@A]j$!!SK=Y(&uW#@
+%dRi[+d<_aU/t;tuV>cA'\8e,F$^A_H\p5="hqB$",^Tui1WR;mP3<0YkCc;e%(a4TnHOf'FMC*i=_5t4RkpB@bScTA@jFM!0HDf=
+%N[5-VPXs5\NR\&Pr*"(@Zp7FafFQH@YWWc9(d'Ph5qB]Q68Wk@ZqT@r-g][&3\tH;j`Ue+#fGcr%fRi9,&#$ULCjA8#_*NGDk`J>
+%OA28=UmWA"?;ed$^%K*`+OinJRUs1uC)cL8p43knF`gt2anFWG;fj[PDK>E#1u/k,9)tN`e.DR11=Wi;0IBZ#4_mVEXQ[qYdGGJ0
+%Zf/M\JeJne9]7=6UE=#!_T1;Q1!uUciTN@"5\D<h"DoN/Vin/DCX03]<:4(_@(]Sk'@(n_%eQ[IU$hjTDQ5c#NTmf_#aX-12S+T3
+%rS=%ALqKpTYR!V9Y?Hoe-(!V"\=.9cq)*TF=9/G2hJB+[s7^]5CMb<4p'LX,+peAbA#/OYe7/*rAk31=Q9^6\#+WU9Cq):mk<Ac+
+%<@rK[4@&8DhgCj1AZ8[8?#-M;p^`-#)DjMP((U65l4nH`91@4/P>tA0gOWf%YD3=Y*KorJV&re82dXC.Ki\b25'?`Paekq*%f:jk
+%`PE#'n3F)2fkM8*Y=ge:oO6>\!D1f4)uEFo+bWVbM#77WeU?cl;;!VIVls_FS)&5:O=P60r=&QqU.mSl]X[9>m9rjs/i9NcW(ImS
+%kK1D3Ih%&4HPm!>1I2Qlb/Qrei(O[bLO.oK^u.lt"GcMUP$r;V#_I\dD\NW*"@7"rPYj+o'*Q/1Hn6->B7_6cGfhEOS-af*E$&mO
+%%*euAE3Lsi?uRFuJj[-W,@GI;#_GG=@j>B#-4#2*WuM:qo5SeI1kWQ40E?_]_'c.XPFar4jRGNT9J)P9K/5e)*(HPnL;B9##S-[8
+%&MQ2>5]H;Qp-rDF^"i%-gJipeXM.Jg%UjMqhr",BT4WRaG-1iu$:fmk-f#!j;bb<BcNeH#QAV0>Q*5hlnY(9"gJ@iqa#u*\*@O=G
+%H#o^'\gS,J=K>I[lB4m-J]?g)NJ5BAcSOC$AJZa%=-gFkZcT."N#^3^\3'!JW&[YF20/,M\-W]:m[_$#iF:MJ$1_WQ/q8-'IU\BU
+%c8[3tr'3gJ24&61S2i;kD6Mdaj5R[>g<68)Mm,9$JrV9bh/&??G"OQEgG>8CfrIpJ&BkT;gKFn6E_#T69OEm+^[h1nnbOA0-aETF
+%l*a06o;je2[g'_,GnTB8'IhD4_(19[R)40!k1<2uiVKFj3s8hKpR.tD%+\'!"<#`:29e`ITE;U[D!-3/Q?JnSIGopLL6peAl@QsH
+%,EU)e`HpeD4[^E>WE?M)UN.`gMk)f9q8RTddlkJGmS/I&@OP>#dH[?S[[oe514N5o^"2'I1ZgI-2gt_"Y>a1]#VM&.T3KLIHb$i0
+%B=\H0h9(dfk,EFG06a0Elnm86V3qN*?_r#GIRBE6[r]6)i^7moZiFI%^K`#NhdLI8BP=hSBJb`%ZNjho2g"JAWuL,K+K[2*9`3[0
+%SpLmH,ic&qrc^6]C[G<Ze\8H\jlq!&rMeV_Bsas`C+6QPgN8t'f%"':?*>@"s*cNUeXi6&et]Wd/`cU5S!t>qV07&_\'jWMk20`3
+%F2r3VgKV)O*Y)s=++>L[eY)Y!opRR#/h+Zug0<jhMj;t#lggnd6a9gs[aoqXrHXh2Z*Te?V-D7@d[Kc-(Z/O^Q&:9TZYmm+5Ptn#
+%WTb5'nd7ie/p$:Sh6$$ecrnm<b=@ukh5R+bXmNGn]6ILC3@M)l<bb5(7'E[e2<Boa);4=U;C&[KG@W@L\WAJ$N@]^.AZlUTG&nVZ
+%O51W2H:8QV<"OgJqWAY!YNt\)\a$<RJ(s@K?prHKBDJ>#Y8R9Uj^!6`V,7[4Ft>3sZL@&D01b!UXKmkG53,O+ZI_cKHM)QVr&ON9
+%NGk@McMHarJ&a15F(.lk=SPqc]qpRV(F_TImQW?;SR:V-ZT[%%[^31l:rQ8S^qhdhic6c%mZoM,F4JZoSrH),[T?B\YQ%ol.:(eI
+%bi_0^hX+\hl_a!)=uDc)![\1M_1J3_.dq*iDIIc@>qN3;j!Dh[njWF4Z[R?]]3)$#Im/f-66YJ!+hm=+IoUs+N=,<S&rSj%]f"[7
+%l<EMJSbl,n^;!.ipc?Bf]q<lGI:&SJSRnPYSKh)3I(I[[$:\E;.4eVCL$GPm./se&K>+@;gfsc%4mupNTC2HjV#P`gkga*@q955X
+%Yl36SjVS$Crl#$Z$,=^O%sOHLAe3jEm4`bR[?JnE)n!54]j/1Z=[%6II9b(E(Ar=TKPD%HlhBk^c\K_gbN_k<Di[OK3YXdXN>dCF
+%Y?sD`WGi`eB2m&1F*i3,leZ-9lM$i<VEUL"#=Qt7L[sfonX&\'m"DpsI$S+c^*BkenoQ`=;%>4jig>e,MQ%!9Jb(0oDX\Gm)l7cM
+%[mpa)bZ8`BGgGOt?Yl!)-#tV2^H&KV9Tr?WF,6T<a\d"_]_T'C2.[CH/DVLb\PucrIuE!XO,$h(MRReUhk3j_nTOV!MsZ4kH1nnG
+%Agub'I0o3;m2tJu"DXU9h82cE=1bG/mBYJ^dL.5::]Yi[*W'MYBE+;T0.>9@/p"5"no=(=2P>)_=[e4elIONpG%p?Clb14M5mA>E
+%)CqkH8\Mu3R;Y:M51cqfgb>7eVU"j5,S420.<N9B^&>&VEUPG?h4/,VKmr5%D>8(e;k\7+lVl5q+gH]5:ZfdUlClqVfum0^W*&<M
+%&70V9iKNQh,6.RUQL>,q(TM,B9rtn09)H>.l8Nm@:2Qn)#t]SuSJfHa;!W>*<k>fUqMDbqE?k"/[8M#S`.pMHc#O=L:>]oRc?gYN
+%/]34MhbA]0+:P>.^03UQIM\I/C1o!,m!Uk=[5L32FR+\<(L,_U?$DEAX3KYd[t=nm?mjX(K.e8EQB%[:3OBkQndchTci(")LX<me
+%MJYL?`A#4Z"me=G.3<-!k*C3+i<"BQYj^T$]:rX"@XkT/(L'i&L\jm>`>Sab>YV&=N]3h!4M5P&\dY-A>dK3E["jiX`8?:A%(CD/
+%YMYSN2q^!no3d/irphrOru&\"#+[X(@SoTIoB%M!ODQZFA+^"bWRC[pbT<D.)r<kL<\XEUGD]Atb]Elsba%Ed1G"Atqhr>tRt^];
+%Q0Xugo@']io#E,CdUhR@hQ+@=BQjXf1tkLEkGM/DX_-grP<fDDSREODS_7@dFF,H;HZ^EA(L+No]Wq&+Wu^0Zp<Z'%kcCCe06=8'
+%WB2MspX]7+Md2iRF?Jc%rNKKljVJiUNu;HLNV)4#g2k"R`4un[+5VFJn%./>Sa\4\J'l8M<O]W11%3IVN/hgXV9A,(b@*UE3>Edg
+%r8("Ob5-R`f2n!8$X%d_HsN3<?G/YC4m8,*l]3i<_Yac5H9/\)rbPCZ3:GGE\`ic08hG3B9LE\A:qK^XXo.RIS[3\gGP7eR\TcKH
+%/g>tqUE?NAq;6*oAVL=^9aBPO>`I)l.;U"@q($sjaLe,4i<F-Fm?Q*)f*aaeD"3b'L&O8XN:*1\Ni;*7TpEP)P]1a]l'78Xed``]
+%k6S,u.,BrQY0s7):YNH9h't(EYFL`qmZK7J#rq<TPfU*a,*=<;NtOH27V(^7?\"Y+%Rq^Qjmsm_@q.pT/"L<M,0.]Z,l!mB;'O'#
+%LlANd!_VP+(m2n'T1=_X)^DWr4Rd8;O^hlhU>gM@-$!g\8FeGJ"_C?FLkJdB)V"*GOBs0j%/WmGa2Wpoi!fW#-$!g\a@$lL@?ej<
+%0d9s+Bf6<Fm,](H8`4tNPfU*a,,&LV!7eas,;KbQ3B9@E*_X/Fru=YlfGKatYmCJ5Nl$V=gA]#UCL:ZMk:]<]HN?S]f&_1AaK[HD
+%GqRF:7#m6=BprA#6&?R#,;NI$5;^(j@RSX[_uCjP%&jrH^?8?;a2Wq2M#9bV^9>D0m!4s_jn9u;OVGd+7>W!',Efj^SjeJU)^CM$
+%fOn&*a2Wr%c/i;/,%$3>)1OF`2P8CeTGQOfNVON0Yl+m;T-Z@e@4i425>,`T92/3nr@FrDN12@Fg4#@;Hq$.Tg%MbJjth=I38+#3
+%UujJ^r\2IfZ_Z`iYeBHhrXCc'Gb8[H=]4i/!=hi4r@FrDN4e7_gWu%OcV2OR,hpY.Ra6:&4oaV^YSg9<8[b8)V"*ieq$jdZ?N0!B
+%@&"r[PANNWC-KPH9Xt$PWVHr8RrJ7-;Y-<%@l;C%Z_Z_>I[`%=p9URW1\*5`D*L[.4u<)%PAEHVC-JD:(6`T"956ZNQF)LWT-Z@e
+%@J)#'Ib&9u>Jf<fNcS'4?1mrYV5C.VfrmV(h9uPq7D=6"BN;)4eCuFm1B6&&O8eSQQ6Wa_>SeJeU/imFZ[An:bZU33CAMB_f7#8/
+%C6+@d<jhme[7I+RS]]o'd9<p$[26>radNAlp'%V==*)m@Fo`(+;RVk.TB![a:O%9T*rl4m5Bb&d1G]M(GkQ2rpYaM<amr`lZO1ar
+%rLL5]2KA%IpooI%qul7;93F@-[r^<8U/A\$KQJt1^]^Hp)-a\hC8MtXB9XM1d4.;JnoVn'^&qR5hBZ:^^";3@_\:;U*ciahO.B.d
+%3@:DGlq?)i\9Bb6PY,(NGaZAA?/eH])'OD7RZm7CWJIT?Apch=.:EHT;jkGp,i@qI6DjPrWI1=Pg(CLL"@:%/[K+:m\?><Q@=rVB
+%9&gOT[ZD-1$PII<Aft;Po<Z8e+.15VJ]il3AX'PV\eLRJ'*6R0ge&i2K<'[-q/7SXN$FQUj/=*9BDelrUo-5_<"TA."eOd`*&f)F
+%%BU=H#`$FOJHY;]c$7BR6Q5"c<gCt_5*gdK[VoY4Q_]V/1.q[!U0Nh#nK`R\PB!CRnQdg.g!CfZ97o[R_6QDPCtCc_Ju2\_4r1t7
+%9S0on7CPTk!fnUp]#qpd>];)SOtpY8.5R3HKFa,c!^+S[0U2n:IAqL?"PD'bdfSX!201NrG\]RmXfu!=6/XKBo>%)q]aTf(:P?5d
+%O'6+25sb]UY&Bo1m;O=ilq&(pF(!K8UC3B'O64"k-a6aiHn:=!ON\hskX.lSXpg[EH/bKY;A$`r>cbZ5,_h(\(A`c@juA_K:C-Pm
+%O?1krs59`L)'FG$pc8qc6?ABKB$I@@qGuB6$8=6)9FEfV6(iL_Fb!>JiFjf"0:iT*a33JQ4=f2?'O7"77QfZH,#ZdCRaGm*$^L9k
+%aT8B*#ERm_"a'sTQZRaWMmQ`)QYrS[27I!ddT=YoE.,t6g^1+0:aSV4^oR['[Us'-otePMZAp/4VEXEZNL%ZEXn^[dR.Z5%nh&p'
+%n2QdsS;QrTNP@U?8p2pmoUH>8WR/c*QuAjbAf-k$9N6"W-HJ<#qh-uLjcCUd\3u++T!0oBK&B8GSl#5P=.p`;'TFs[%`OS*Oskl+
+%M%*-Z4!$W&'>cG8/&?t!)*)lU50`h<\dc[?&7<e'588aPrIF>Laq;i\*XomTfMYAR$8U%%)i&%L)P0?1a]uCur+:reJ`f*O(2VE?
+%E?BIP7:K>L&P.:mK.?G>jFJh3ET0XUM2WHg1*@auecUR2-l*eY+9s)=#WY)r,kMSd0,uO?$_rC8K:.$,-pCZ8WWED5rij]/E7lgQ
+%Hlqm@KN2I$03n8fl+7htR$clpf7U`4NtiC%KT=aZL]l&&"0u*60.7-(">'d+-[_c$bnnggFUFcT=@3ujcru/i;?l(9='`QSJ8Ga&
+%,SA:TmmZcsYot.PO^M1r`/:]Ac&u[unQ:huVC;;'a+[=kkTaBpfUBk/%]qh4K!,sD1]@pYk/552\D4k-N0AJEEj<nD?V$"/*J0r-
+%nH=M#`tJq]^nItDe4j=0?61SWYn/CMmE3ejiZkV$0J!&LLd9sA*LW;:DD2;`;I$(n3+QU,8c7!o6('!QHj39[U]g=U,tf0C@<f:s
+%-)DET)K>J9!$O1]ERVd%o^h<RXHU$I0VX<'fuC8<eJL.dZW>L"#rWb2;Z`\T!^SIs,Ut5l;4M\ncWDh'fo[<:%Bq8??U>Te<Ru_b
+%;2C#b"-$<iOBGrs\-oMND8E68We6Xg"_RXJk<b9aOV5ITQ/I1P8O,dRE=t_Lm:>km6On-)cmUR;h2mBd6o8`^.8^Ldn=RQd*^CF,
+%5PRS?Zmj6LnG%S#5XF?n@?+st@FM<2:5rj$BP!dZ/u?Z&n9c.>es'DVaZ%!BnGM5s9b&Rs>/'LY+_*fD8WQl9Hq7:UWM)tH#ojP2
+%1L,O-&mW6(Ze$uf%uHHYB+WFa#b07r5dT^]!DoZT6bIdU#D*lcm8EKu3M.Hl34PTF#=65#F=]V`TqH%\4]8SHFmF<0(k^RcBsB$a
+%TH!#H5)7(E-H]gpA21('"J;nV$.DQ``h9sWKGpin3C;ea(_?m:\Yt@+dNM'!6UX2m+sr:Cc?L+,<PX_-AV"H)FJN\-+UFFJNN5e;
+%,0+JoC1(Ba+N\+lFkC-\)KsC`2HA!+#6D\o$D+aPD8fG*J"rqc6[,5OXu/mJ*cTaSenM_81O,'o$q<?05.scE%T@p94(fQUU#lsh
+%MsS@2^]St,?t*80P?9.kEi:J#L:/NT;2>a]2M%4c.0+H=QjZM*8!%`b?_thT'?(3'9[Pc/3MQ;+-POlAAn=&o`cpl^R]G\uE-.r[
+%<)Z:LF=F!s+fE#SH8EK@Seb@ScF$WP`s&HSVF7J!>Sq/pO^)7I*l\jGLJsQ!6,br"`=gY0C_?1&#eHHR@)D)>63eq&@T?7nYgX:_
+%80/h@NC&aJ0L\TEAJCZNN<j5^.2(&0?e^^8AsZ$(=\6%3W$qcR7rYIT8<7Qs=?`+WPoBo37G/4]("U6tQ'BVBI;ZjZ:U&&'!R\Si
+%Q1@aE;Oq?57i27eD1l^b$-f<AFN?HbTR)VI=!:s^7=oI,Sh%[HcrWo)7a;`l23O70Oj`<2-MVT?.M7VVWXDCl=nIsSdJD6eE'Bp;
+%'I3CAGcOP^/<PXrSuK^@DoqCf5adSeKNg>n4<_l!a=D657FhR)#E)"?>[O]]#Zh2,I\ijn-<9_5mR6T'$=?E(WV/*(P0Y'Zn,c/.
+%U>Zj_!MZhd0Jo-Y7*6C5a4c9V/#rP^p;A@KPH<-DjJG&j<8:tDr?r'FTgCAR)L;D>EC*6<WiRVs)^a2dE#hQ-V^_G<EGLH[:7;g!
+%Rc`%\dNpj1Pmius_&Y9f\k4J`W`<`"fkhlkUre*:1,;@HiB@M.BXC4&4ko$K.!9s@<frPCj?ksA&Gnd55o2MGosrA!A\*?KKUV.P
+%j=67tn:lNdNB%`Jl\$:I&Oc!4eCeV6O[es8\.V*)::hr%c)//aN9*V`^r`aDEYR+U&h\sa)l\Lm:!)DC^&cW[ihHAQl#r\Ukp\6@
+%5kE%te*J@1/<h8<j9.<^3_c@oOSTHVLnKIq>qRN'+PIlHG6j'A4R_+oT&+O>4SFSC.Y3WtVo-t4,YpKn4>ARZCi`_2nHBe:[R0QU
+%-E=nd\ekZ0Uf;?I)ck8$#UN5Hp-GH-ZshF?S(FkV((uTa_5?7iD]HciK1L#+K5RP?_Asr5XWd.F89#G*kU,?8[#j?iP?`1aKc;*k
+%jQGQs?oVO.7Kf$Q!&P[oN04W=Z_;=S$]0SuaI*TI@tC"\Z"P-gkX/4^OIR:9,n[CmK4se>,bDFQjYhh2$n.Dip!ZH>g4UR%MPS4S
+%5&GDh,R*Q\po[a/nn_923g/b5X;T/A:*["ZT$(nBRlJ,?Q'.jN/m;"OF1?br$T9L0/=//,QaSb62Hg,?_hG*#Cu-K*-(a0=4PKKX
+%,^S/IIiNO/>Z8@[-S`V]=CDZ_.mEVO!@<OV-L068oM)faHhZXTI2R?/(*C`mitXjHeI^'5PHs^\`h&FH-YECr'uFo1dD*WIZ5]"l
+%ks\io&sV^nY@n8MZ$h01"Jc%Fru>f9-*=r]?XB(AqY4J9%!k'N/V:).!lH-W$nH0Y<L`[+elDZeo6LB+Y5M/gGq"Hhr0?8#J6+0Q
+%*7+&d64@oElPIn!Z.;M6iAP\>UtA2lYI$_&UEP'2j(i5^i;X9IR,j1JU$O%ck0Q"dnqHtbK_,+dQ+VAM>A@I6]@-NNeF`Crl:q5M
+%?#BMB[o55VlMoA9C9)LO=FI:.iu@<]?11#mFfTS1pD6\G96C"%FQl^aomb.>&V'~>
+%AI9_PrivateDataEnd
diff --git a/doc/arm/isc-logo.pdf b/doc/arm/isc-logo.pdf
new file mode 100644
index 0000000..71d3fdd
--- /dev/null
+++ b/doc/arm/isc-logo.pdf
diff --git a/doc/arm/man.dig.html b/doc/arm/man.dig.html
new file mode 100644
index 0000000..7d0e437
--- /dev/null
+++ b/doc/arm/man.dig.html
@@ -0,0 +1,665 @@
+<!--
+ - Copyright (C) 2004-2007 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2000-2003 Internet Software Consortium.
+ - 
+ - Permission to use, copy, modify, and distribute this software for any
+ - purpose with or without fee is hereby granted, provided that the above
+ - copyright notice and this permission notice appear in all copies.
+ - 
+ - THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
+ - REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
+ - AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
+ - INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
+ - LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
+ - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
+ - PERFORMANCE OF THIS SOFTWARE.
+-->
+<!-- $Id: man.dig.html,v 1.2.2.48 2007/10/31 01:35:59 marka Exp $ -->
+<html>
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
+<title>dig</title>
+<meta name="generator" content="DocBook XSL Stylesheets V1.71.1">
+<link rel="start" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual">
+<link rel="up" href="Bv9ARM.ch10.html" title="Manual pages">
+<link rel="prev" href="Bv9ARM.ch10.html" title="Manual pages">
+<link rel="next" href="man.host.html" title="host">
+</head>
+<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
+<div class="navheader">
+<table width="100%" summary="Navigation header">
+<tr><th colspan="3" align="center">dig</th></tr>
+<tr>
+<td width="20%" align="left">
+<a accesskey="p" href="Bv9ARM.ch10.html">Prev</a> </td>
+<th width="60%" align="center">Manual pages</th>
+<td width="20%" align="right"> <a accesskey="n" href="man.host.html">Next</a>
+</td>
+</tr>
+</table>
+<hr>
+</div>
+<div class="refentry" lang="en">
+<a name="man.dig"></a><div class="titlepage"></div>
+<div class="refnamediv">
+<h2>Name</h2>
+<p>dig &#8212; DNS lookup utility</p>
+</div>
+<div class="refsynopsisdiv">
+<h2>Synopsis</h2>
+<div class="cmdsynopsis"><p><code class="command">dig</code>  [@server] [<code class="option">-b <em class="replaceable"><code>address</code></em></code>] [<code class="option">-c <em class="replaceable"><code>class</code></em></code>] [<code class="option">-f <em class="replaceable"><code>filename</code></em></code>] [<code class="option">-k <em class="replaceable"><code>filename</code></em></code>] [<code class="option">-p <em class="replaceable"><code>port#</code></em></code>] [<code class="option">-q <em class="replaceable"><code>name</code></em></code>] [<code class="option">-t <em class="replaceable"><code>type</code></em></code>] [<code class="option">-x <em class="replaceable"><code>addr</code></em></code>] [<code class="option">-y <em class="replaceable"><code>[<span class="optional">hmac:</span>]name:key</code></em></code>] [<code class="option">-4</code>] [<code class="option">-6</code>] [name] [type] [class] [queryopt...]</p></div>
+<div class="cmdsynopsis"><p><code class="command">dig</code>  [<code class="option">-h</code>]</p></div>
+<div class="cmdsynopsis"><p><code class="command">dig</code>  [global-queryopt...] [query...]</p></div>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2564025"></a><h2>DESCRIPTION</h2>
+<p><span><strong class="command">dig</strong></span>
+      (domain information groper) is a flexible tool
+      for interrogating DNS name servers.  It performs DNS lookups and
+      displays the answers that are returned from the name server(s) that
+      were queried.  Most DNS administrators use <span><strong class="command">dig</strong></span> to
+      troubleshoot DNS problems because of its flexibility, ease of use and
+      clarity of output.  Other lookup tools tend to have less functionality
+      than <span><strong class="command">dig</strong></span>.
+    </p>
+<p>
+      Although <span><strong class="command">dig</strong></span> is normally used with
+      command-line
+      arguments, it also has a batch mode of operation for reading lookup
+      requests from a file.  A brief summary of its command-line arguments
+      and options is printed when the <code class="option">-h</code> option is given.
+      Unlike earlier versions, the BIND 9 implementation of
+      <span><strong class="command">dig</strong></span> allows multiple lookups to be issued
+      from the
+      command line.
+    </p>
+<p>
+      Unless it is told to query a specific name server,
+      <span><strong class="command">dig</strong></span> will try each of the servers listed
+      in
+      <code class="filename">/etc/resolv.conf</code>.
+    </p>
+<p>
+      When no command line arguments or options are given, will perform an
+      NS query for "." (the root).
+    </p>
+<p>
+      It is possible to set per-user defaults for <span><strong class="command">dig</strong></span> via
+      <code class="filename">${HOME}/.digrc</code>.  This file is read and
+      any options in it
+      are applied before the command line arguments.
+    </p>
+<p>
+      The IN and CH class names overlap with the IN and CH top level
+      domains names.  Either use the <code class="option">-t</code> and
+      <code class="option">-c</code> options to specify the type and class or
+      use the <code class="option">-q</code> the specify the domain name or
+      use "IN." and "CH." when looking up these top level domains.
+    </p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2569712"></a><h2>SIMPLE USAGE</h2>
+<p>
+      A typical invocation of <span><strong class="command">dig</strong></span> looks like:
+      </p>
+<pre class="programlisting"> dig @server name type </pre>
+<p>
+      where:
+
+      </p>
+<div class="variablelist"><dl>
+<dt><span class="term"><code class="constant">server</code></span></dt>
+<dd><p>
+              is the name or IP address of the name server to query.  This can
+              be an IPv4
+              address in dotted-decimal notation or an IPv6
+              address in colon-delimited notation.  When the supplied
+              <em class="parameter"><code>server</code></em> argument is a
+              hostname,
+              <span><strong class="command">dig</strong></span> resolves that name before
+              querying that name
+              server.  If no <em class="parameter"><code>server</code></em>
+              argument is provided,
+              <span><strong class="command">dig</strong></span> consults <code class="filename">/etc/resolv.conf</code>
+              and queries the name servers listed there.  The reply from the
+              name
+              server that responds is displayed.
+            </p></dd>
+<dt><span class="term"><code class="constant">name</code></span></dt>
+<dd><p>
+              is the name of the resource record that is to be looked up.
+            </p></dd>
+<dt><span class="term"><code class="constant">type</code></span></dt>
+<dd><p>
+              indicates what type of query is required &#8212;
+              ANY, A, MX, SIG, etc.
+              <em class="parameter"><code>type</code></em> can be any valid query
+              type.  If no
+              <em class="parameter"><code>type</code></em> argument is supplied,
+              <span><strong class="command">dig</strong></span> will perform a lookup for an
+              A record.
+            </p></dd>
+</dl></div>
+<p>
+    </p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2623002"></a><h2>OPTIONS</h2>
+<p>
+      The <code class="option">-b</code> option sets the source IP address of the query
+      to <em class="parameter"><code>address</code></em>.  This must be a valid
+      address on
+      one of the host's network interfaces or "0.0.0.0" or "::".  An optional
+      port
+      may be specified by appending "#&lt;port&gt;"
+    </p>
+<p>
+      The default query class (IN for internet) is overridden by the
+      <code class="option">-c</code> option.  <em class="parameter"><code>class</code></em> is
+      any valid
+      class, such as HS for Hesiod records or CH for Chaosnet records.
+    </p>
+<p>
+      The <code class="option">-f</code> option makes <span><strong class="command">dig </strong></span>
+      operate
+      in batch mode by reading a list of lookup requests to process from the
+      file <em class="parameter"><code>filename</code></em>.  The file contains a
+      number of
+      queries, one per line.  Each entry in the file should be organized in
+      the same way they would be presented as queries to
+      <span><strong class="command">dig</strong></span> using the command-line interface.
+    </p>
+<p>
+      If a non-standard port number is to be queried, the
+      <code class="option">-p</code> option is used.  <em class="parameter"><code>port#</code></em> is
+      the port number that <span><strong class="command">dig</strong></span> will send its
+      queries
+      instead of the standard DNS port number 53.  This option would be used
+      to test a name server that has been configured to listen for queries
+      on a non-standard port number.
+    </p>
+<p>
+      The <code class="option">-4</code> option forces <span><strong class="command">dig</strong></span>
+      to only
+      use IPv4 query transport.  The <code class="option">-6</code> option forces
+      <span><strong class="command">dig</strong></span> to only use IPv6 query transport.
+    </p>
+<p>
+      The <code class="option">-t</code> option sets the query type to
+      <em class="parameter"><code>type</code></em>.  It can be any valid query type
+      which is
+      supported in BIND 9.  The default query type is "A", unless the
+      <code class="option">-x</code> option is supplied to indicate a reverse lookup.
+      A zone transfer can be requested by specifying a type of AXFR.  When
+      an incremental zone transfer (IXFR) is required,
+      <em class="parameter"><code>type</code></em> is set to <code class="literal">ixfr=N</code>.
+      The incremental zone transfer will contain the changes made to the zone
+      since the serial number in the zone's SOA record was
+      <em class="parameter"><code>N</code></em>.
+    </p>
+<p>
+      The <code class="option">-q</code> option sets the query name to 
+      <em class="parameter"><code>name</code></em>.  This useful do distinguish the
+      <em class="parameter"><code>name</code></em> from other arguments.
+    </p>
+<p>
+      Reverse lookups &#8212; mapping addresses to names &#8212; are simplified by the
+      <code class="option">-x</code> option.  <em class="parameter"><code>addr</code></em> is
+      an IPv4
+      address in dotted-decimal notation, or a colon-delimited IPv6 address.
+      When this option is used, there is no need to provide the
+      <em class="parameter"><code>name</code></em>, <em class="parameter"><code>class</code></em> and
+      <em class="parameter"><code>type</code></em> arguments.  <span><strong class="command">dig</strong></span>
+      automatically performs a lookup for a name like
+      <code class="literal">11.12.13.10.in-addr.arpa</code> and sets the
+      query type and
+      class to PTR and IN respectively.  By default, IPv6 addresses are
+      looked up using nibble format under the IP6.ARPA domain.
+      To use the older RFC1886 method using the IP6.INT domain
+      specify the <code class="option">-i</code> option.  Bit string labels (RFC2874)
+      are now experimental and are not attempted.
+    </p>
+<p>
+      To sign the DNS queries sent by <span><strong class="command">dig</strong></span> and
+      their
+      responses using transaction signatures (TSIG), specify a TSIG key file
+      using the <code class="option">-k</code> option.  You can also specify the TSIG
+      key itself on the command line using the <code class="option">-y</code> option;
+      <em class="parameter"><code>hmac</code></em> is the type of the TSIG, default HMAC-MD5,
+      <em class="parameter"><code>name</code></em> is the name of the TSIG key and
+      <em class="parameter"><code>key</code></em> is the actual key.  The key is a
+      base-64
+      encoded string, typically generated by
+      <span class="citerefentry"><span class="refentrytitle">dnssec-keygen</span>(8)</span>.
+
+      Caution should be taken when using the <code class="option">-y</code> option on
+      multi-user systems as the key can be visible in the output from
+      <span class="citerefentry"><span class="refentrytitle">ps</span>(1)</span>
+      or in the shell's history file.  When
+      using TSIG authentication with <span><strong class="command">dig</strong></span>, the name
+      server that is queried needs to know the key and algorithm that is
+      being used.  In BIND, this is done by providing appropriate
+      <span><strong class="command">key</strong></span> and <span><strong class="command">server</strong></span> statements in
+      <code class="filename">named.conf</code>.
+    </p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2649413"></a><h2>QUERY OPTIONS</h2>
+<p><span><strong class="command">dig</strong></span>
+      provides a number of query options which affect
+      the way in which lookups are made and the results displayed.  Some of
+      these set or reset flag bits in the query header, some determine which
+      sections of the answer get printed, and others determine the timeout
+      and retry strategies.
+    </p>
+<p>
+      Each query option is identified by a keyword preceded by a plus sign
+      (<code class="literal">+</code>).  Some keywords set or reset an
+      option.  These may be preceded
+      by the string <code class="literal">no</code> to negate the meaning of
+      that keyword.  Other
+      keywords assign values to options like the timeout interval.  They
+      have the form <code class="option">+keyword=value</code>.
+      The query options are:
+
+      </p>
+<div class="variablelist"><dl>
+<dt><span class="term"><code class="option">+[no]tcp</code></span></dt>
+<dd><p>
+              Use [do not use] TCP when querying name servers.  The default
+              behavior is to use UDP unless an AXFR or IXFR query is
+              requested, in
+              which case a TCP connection is used.
+            </p></dd>
+<dt><span class="term"><code class="option">+[no]vc</code></span></dt>
+<dd><p>
+              Use [do not use] TCP when querying name servers.  This alternate
+              syntax to <em class="parameter"><code>+[no]tcp</code></em> is
+              provided for backwards
+              compatibility.  The "vc" stands for "virtual circuit".
+            </p></dd>
+<dt><span class="term"><code class="option">+[no]ignore</code></span></dt>
+<dd><p>
+              Ignore truncation in UDP responses instead of retrying with TCP.
+               By
+              default, TCP retries are performed.
+            </p></dd>
+<dt><span class="term"><code class="option">+domain=somename</code></span></dt>
+<dd><p>
+              Set the search list to contain the single domain
+              <em class="parameter"><code>somename</code></em>, as if specified in
+              a
+              <span><strong class="command">domain</strong></span> directive in
+              <code class="filename">/etc/resolv.conf</code>, and enable
+              search list
+              processing as if the <em class="parameter"><code>+search</code></em>
+              option were given.
+            </p></dd>
+<dt><span class="term"><code class="option">+[no]search</code></span></dt>
+<dd><p>
+              Use [do not use] the search list defined by the searchlist or
+              domain
+              directive in <code class="filename">resolv.conf</code> (if
+              any).
+              The search list is not used by default.
+            </p></dd>
+<dt><span class="term"><code class="option">+[no]showsearch</code></span></dt>
+<dd><p>
+              Perform [do not perform] a search showing intermediate
+	      results.
+            </p></dd>
+<dt><span class="term"><code class="option">+[no]defname</code></span></dt>
+<dd><p>
+              Deprecated, treated as a synonym for <em class="parameter"><code>+[no]search</code></em>
+            </p></dd>
+<dt><span class="term"><code class="option">+[no]aaonly</code></span></dt>
+<dd><p>
+              Sets the "aa" flag in the query.
+            </p></dd>
+<dt><span class="term"><code class="option">+[no]aaflag</code></span></dt>
+<dd><p>
+              A synonym for <em class="parameter"><code>+[no]aaonly</code></em>.
+            </p></dd>
+<dt><span class="term"><code class="option">+[no]adflag</code></span></dt>
+<dd><p>
+              Set [do not set] the AD (authentic data) bit in the query.  The
+              AD bit
+              currently has a standard meaning only in responses, not in
+              queries,
+              but the ability to set the bit in the query is provided for
+              completeness.
+            </p></dd>
+<dt><span class="term"><code class="option">+[no]cdflag</code></span></dt>
+<dd><p>
+              Set [do not set] the CD (checking disabled) bit in the query.
+              This
+              requests the server to not perform DNSSEC validation of
+              responses.
+            </p></dd>
+<dt><span class="term"><code class="option">+[no]cl</code></span></dt>
+<dd><p>
+              Display [do not display] the CLASS when printing the record.
+            </p></dd>
+<dt><span class="term"><code class="option">+[no]ttlid</code></span></dt>
+<dd><p>
+              Display [do not display] the TTL when printing the record.
+            </p></dd>
+<dt><span class="term"><code class="option">+[no]recurse</code></span></dt>
+<dd><p>
+              Toggle the setting of the RD (recursion desired) bit in the
+              query.
+              This bit is set by default, which means <span><strong class="command">dig</strong></span>
+              normally sends recursive queries.  Recursion is automatically
+              disabled
+              when the <em class="parameter"><code>+nssearch</code></em> or
+              <em class="parameter"><code>+trace</code></em> query options are
+              used.
+            </p></dd>
+<dt><span class="term"><code class="option">+[no]nssearch</code></span></dt>
+<dd><p>
+              When this option is set, <span><strong class="command">dig</strong></span>
+              attempts to find the
+              authoritative name servers for the zone containing the name
+              being
+              looked up and display the SOA record that each name server has
+              for the
+              zone.
+            </p></dd>
+<dt><span class="term"><code class="option">+[no]trace</code></span></dt>
+<dd><p>
+              Toggle tracing of the delegation path from the root name servers
+              for
+              the name being looked up.  Tracing is disabled by default.  When
+              tracing is enabled, <span><strong class="command">dig</strong></span> makes
+              iterative queries to
+              resolve the name being looked up.  It will follow referrals from
+              the
+              root servers, showing the answer from each server that was used
+              to
+              resolve the lookup.
+            </p></dd>
+<dt><span class="term"><code class="option">+[no]cmd</code></span></dt>
+<dd><p>
+              Toggles the printing of the initial comment in the output
+              identifying
+              the version of <span><strong class="command">dig</strong></span> and the query
+              options that have
+              been applied.  This comment is printed by default.
+            </p></dd>
+<dt><span class="term"><code class="option">+[no]short</code></span></dt>
+<dd><p>
+              Provide a terse answer.  The default is to print the answer in a
+              verbose form.
+            </p></dd>
+<dt><span class="term"><code class="option">+[no]identify</code></span></dt>
+<dd><p>
+              Show [or do not show] the IP address and port number that
+              supplied the
+              answer when the <em class="parameter"><code>+short</code></em> option
+              is enabled.  If
+              short form answers are requested, the default is not to show the
+              source address and port number of the server that provided the
+              answer.
+            </p></dd>
+<dt><span class="term"><code class="option">+[no]comments</code></span></dt>
+<dd><p>
+              Toggle the display of comment lines in the output.  The default
+              is to
+              print comments.
+            </p></dd>
+<dt><span class="term"><code class="option">+[no]stats</code></span></dt>
+<dd><p>
+              This query option toggles the printing of statistics: when the
+              query
+              was made, the size of the reply and so on.  The default
+              behavior is
+              to print the query statistics.
+            </p></dd>
+<dt><span class="term"><code class="option">+[no]qr</code></span></dt>
+<dd><p>
+              Print [do not print] the query as it is sent.
+              By default, the query is not printed.
+            </p></dd>
+<dt><span class="term"><code class="option">+[no]question</code></span></dt>
+<dd><p>
+              Print [do not print] the question section of a query when an
+              answer is
+              returned.  The default is to print the question section as a
+              comment.
+            </p></dd>
+<dt><span class="term"><code class="option">+[no]answer</code></span></dt>
+<dd><p>
+              Display [do not display] the answer section of a reply.  The
+              default
+              is to display it.
+            </p></dd>
+<dt><span class="term"><code class="option">+[no]authority</code></span></dt>
+<dd><p>
+              Display [do not display] the authority section of a reply.  The
+              default is to display it.
+            </p></dd>
+<dt><span class="term"><code class="option">+[no]additional</code></span></dt>
+<dd><p>
+              Display [do not display] the additional section of a reply.
+              The default is to display it.
+            </p></dd>
+<dt><span class="term"><code class="option">+[no]all</code></span></dt>
+<dd><p>
+              Set or clear all display flags.
+            </p></dd>
+<dt><span class="term"><code class="option">+time=T</code></span></dt>
+<dd><p>
+
+              Sets the timeout for a query to
+              <em class="parameter"><code>T</code></em> seconds.  The default
+	      timeout is 5 seconds.
+              An attempt to set <em class="parameter"><code>T</code></em> to less
+              than 1 will result
+              in a query timeout of 1 second being applied.
+            </p></dd>
+<dt><span class="term"><code class="option">+tries=T</code></span></dt>
+<dd><p>
+              Sets the number of times to try UDP queries to server to
+              <em class="parameter"><code>T</code></em> instead of the default, 3.
+              If
+              <em class="parameter"><code>T</code></em> is less than or equal to
+              zero, the number of
+              tries is silently rounded up to 1.
+            </p></dd>
+<dt><span class="term"><code class="option">+retry=T</code></span></dt>
+<dd><p>
+              Sets the number of times to retry UDP queries to server to
+              <em class="parameter"><code>T</code></em> instead of the default, 2.
+              Unlike
+              <em class="parameter"><code>+tries</code></em>, this does not include
+              the initial
+              query.
+            </p></dd>
+<dt><span class="term"><code class="option">+ndots=D</code></span></dt>
+<dd><p>
+              Set the number of dots that have to appear in
+              <em class="parameter"><code>name</code></em> to <em class="parameter"><code>D</code></em> for it to be
+              considered absolute.  The default value is that defined using
+              the
+              ndots statement in <code class="filename">/etc/resolv.conf</code>, or 1 if no
+              ndots statement is present.  Names with fewer dots are
+              interpreted as
+              relative names and will be searched for in the domains listed in
+              the
+              <code class="option">search</code> or <code class="option">domain</code> directive in
+              <code class="filename">/etc/resolv.conf</code>.
+            </p></dd>
+<dt><span class="term"><code class="option">+bufsize=B</code></span></dt>
+<dd><p>
+              Set the UDP message buffer size advertised using EDNS0 to
+              <em class="parameter"><code>B</code></em> bytes.  The maximum and minimum sizes
+	      of this buffer are 65535 and 0 respectively.  Values outside
+	      this range are rounded up or down appropriately.  
+	      Values other than zero will cause a EDNS query to be sent.
+            </p></dd>
+<dt><span class="term"><code class="option">+edns=#</code></span></dt>
+<dd><p>
+	       Specify the EDNS version to query with.  Valid values
+	       are 0 to 255.  Setting the EDNS version will cause a
+	       EDNS query to be sent.  <code class="option">+noedns</code> clears the
+	       remembered EDNS version.
+	    </p></dd>
+<dt><span class="term"><code class="option">+[no]multiline</code></span></dt>
+<dd><p>
+              Print records like the SOA records in a verbose multi-line
+              format with human-readable comments.  The default is to print
+              each record on a single line, to facilitate machine parsing
+              of the <span><strong class="command">dig</strong></span> output.
+            </p></dd>
+<dt><span class="term"><code class="option">+[no]fail</code></span></dt>
+<dd><p>
+              Do not try the next server if you receive a SERVFAIL.  The
+              default is
+              to not try the next server which is the reverse of normal stub
+              resolver
+              behavior.
+            </p></dd>
+<dt><span class="term"><code class="option">+[no]besteffort</code></span></dt>
+<dd><p>
+              Attempt to display the contents of messages which are malformed.
+              The default is to not display malformed answers.
+            </p></dd>
+<dt><span class="term"><code class="option">+[no]dnssec</code></span></dt>
+<dd><p>
+              Requests DNSSEC records be sent by setting the DNSSEC OK bit
+              (DO)
+              in the OPT record in the additional section of the query.
+            </p></dd>
+<dt><span class="term"><code class="option">+[no]sigchase</code></span></dt>
+<dd><p>
+              Chase DNSSEC signature chains.  Requires dig be compiled with
+              -DDIG_SIGCHASE.
+            </p></dd>
+<dt><span class="term"><code class="option">+trusted-key=####</code></span></dt>
+<dd>
+<p>
+              Specifies a file containing trusted keys to be used with
+	      <code class="option">+sigchase</code>.  Each DNSKEY record must be
+	      on its own line.
+            </p>
+<p>
+	      If not specified <span><strong class="command">dig</strong></span> will look for
+	      <code class="filename">/etc/trusted-key.key</code> then
+	      <code class="filename">trusted-key.key</code> in the current directory.
+	    </p>
+<p>
+              Requires dig be compiled with -DDIG_SIGCHASE.
+	    </p>
+</dd>
+<dt><span class="term"><code class="option">+[no]topdown</code></span></dt>
+<dd><p>
+              When chasing DNSSEC signature chains perform a top-down
+              validation.
+              Requires dig be compiled with -DDIG_SIGCHASE.
+            </p></dd>
+</dl></div>
+<p>
+
+    </p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2650468"></a><h2>MULTIPLE QUERIES</h2>
+<p>
+      The BIND 9 implementation of <span><strong class="command">dig </strong></span>
+      supports
+      specifying multiple queries on the command line (in addition to
+      supporting the <code class="option">-f</code> batch file option).  Each of those
+      queries can be supplied with its own set of flags, options and query
+      options.
+    </p>
+<p>
+      In this case, each <em class="parameter"><code>query</code></em> argument
+      represent an
+      individual query in the command-line syntax described above.  Each
+      consists of any of the standard options and flags, the name to be
+      looked up, an optional query type and class and any query options that
+      should be applied to that query.
+    </p>
+<p>
+      A global set of query options, which should be applied to all queries,
+      can also be supplied.  These global query options must precede the
+      first tuple of name, class, type, options, flags, and query options
+      supplied on the command line.  Any global query options (except
+      the <code class="option">+[no]cmd</code> option) can be
+      overridden by a query-specific set of query options.  For example:
+      </p>
+<pre class="programlisting">
+dig +qr www.isc.org any -x 127.0.0.1 isc.org ns +noqr
+</pre>
+<p>
+      shows how <span><strong class="command">dig</strong></span> could be used from the
+      command line
+      to make three lookups: an ANY query for <code class="literal">www.isc.org</code>, a
+      reverse lookup of 127.0.0.1 and a query for the NS records of
+      <code class="literal">isc.org</code>.
+
+      A global query option of <em class="parameter"><code>+qr</code></em> is
+      applied, so
+      that <span><strong class="command">dig</strong></span> shows the initial query it made
+      for each
+      lookup.  The final query has a local query option of
+      <em class="parameter"><code>+noqr</code></em> which means that <span><strong class="command">dig</strong></span>
+      will not print the initial query when it looks up the NS records for
+      <code class="literal">isc.org</code>.
+    </p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2650553"></a><h2>IDN SUPPORT</h2>
+<p>
+      If <span><strong class="command">dig</strong></span> has been built with IDN (internationalized
+      domain name) support, it can accept and display non-ASCII domain names.
+      <span><strong class="command">dig</strong></span> appropriately converts character encoding of
+      domain name before sending a request to DNS server or displaying a
+      reply from the server.
+      If you'd like to turn off the IDN support for some reason, defines
+      the <code class="envar">IDN_DISABLE</code> environment variable.
+      The IDN support is disabled if the variable is set when 
+      <span><strong class="command">dig</strong></span> runs.
+    </p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2650582"></a><h2>FILES</h2>
+<p><code class="filename">/etc/resolv.conf</code>
+    </p>
+<p><code class="filename">${HOME}/.digrc</code>
+    </p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2650603"></a><h2>SEE ALSO</h2>
+<p><span class="citerefentry"><span class="refentrytitle">host</span>(1)</span>,
+      <span class="citerefentry"><span class="refentrytitle">named</span>(8)</span>,
+      <span class="citerefentry"><span class="refentrytitle">dnssec-keygen</span>(8)</span>,
+      <em class="citetitle">RFC1035</em>.
+    </p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2650641"></a><h2>BUGS</h2>
+<p>
+      There are probably too many query options.
+    </p>
+</div>
+</div>
+<div class="navfooter">
+<hr>
+<table width="100%" summary="Navigation footer">
+<tr>
+<td width="40%" align="left">
+<a accesskey="p" href="Bv9ARM.ch10.html">Prev</a> </td>
+<td width="20%" align="center"><a accesskey="u" href="Bv9ARM.ch10.html">Up</a></td>
+<td width="40%" align="right"> <a accesskey="n" href="man.host.html">Next</a>
+</td>
+</tr>
+<tr>
+<td width="40%" align="left" valign="top">Manual pages </td>
+<td width="20%" align="center"><a accesskey="h" href="Bv9ARM.html">Home</a></td>
+<td width="40%" align="right" valign="top"> host</td>
+</tr>
+</table>
+</div>
+</body>
+</html>
diff --git a/doc/arm/man.dnssec-keygen.html b/doc/arm/man.dnssec-keygen.html
new file mode 100644
index 0000000..3b8d2d8
--- /dev/null
+++ b/doc/arm/man.dnssec-keygen.html
@@ -0,0 +1,269 @@
+<!--
+ - Copyright (C) 2004-2007 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2000-2003 Internet Software Consortium.
+ - 
+ - Permission to use, copy, modify, and distribute this software for any
+ - purpose with or without fee is hereby granted, provided that the above
+ - copyright notice and this permission notice appear in all copies.
+ - 
+ - THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
+ - REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
+ - AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
+ - INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
+ - LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
+ - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
+ - PERFORMANCE OF THIS SOFTWARE.
+-->
+<!-- $Id: man.dnssec-keygen.html,v 1.2.2.47 2007/10/31 01:35:59 marka Exp $ -->
+<html>
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
+<title>dnssec-keygen</title>
+<meta name="generator" content="DocBook XSL Stylesheets V1.71.1">
+<link rel="start" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual">
+<link rel="up" href="Bv9ARM.ch10.html" title="Manual pages">
+<link rel="prev" href="man.host.html" title="host">
+<link rel="next" href="man.dnssec-signzone.html" title="dnssec-signzone">
+</head>
+<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
+<div class="navheader">
+<table width="100%" summary="Navigation header">
+<tr><th colspan="3" align="center"><span class="application">dnssec-keygen</span></th></tr>
+<tr>
+<td width="20%" align="left">
+<a accesskey="p" href="man.host.html">Prev</a> </td>
+<th width="60%" align="center">Manual pages</th>
+<td width="20%" align="right"> <a accesskey="n" href="man.dnssec-signzone.html">Next</a>
+</td>
+</tr>
+</table>
+<hr>
+</div>
+<div class="refentry" lang="en">
+<a name="man.dnssec-keygen"></a><div class="titlepage"></div>
+<div class="refnamediv">
+<h2>Name</h2>
+<p><span class="application">dnssec-keygen</span> &#8212; DNSSEC key generation tool</p>
+</div>
+<div class="refsynopsisdiv">
+<h2>Synopsis</h2>
+<div class="cmdsynopsis"><p><code class="command">dnssec-keygen</code>  {-a <em class="replaceable"><code>algorithm</code></em>} {-b <em class="replaceable"><code>keysize</code></em>} {-n <em class="replaceable"><code>nametype</code></em>} [<code class="option">-c <em class="replaceable"><code>class</code></em></code>] [<code class="option">-e</code>] [<code class="option">-f <em class="replaceable"><code>flag</code></em></code>] [<code class="option">-g <em class="replaceable"><code>generator</code></em></code>] [<code class="option">-h</code>] [<code class="option">-k</code>] [<code class="option">-p <em class="replaceable"><code>protocol</code></em></code>] [<code class="option">-r <em class="replaceable"><code>randomdev</code></em></code>] [<code class="option">-s <em class="replaceable"><code>strength</code></em></code>] [<code class="option">-t <em class="replaceable"><code>type</code></em></code>] [<code class="option">-v <em class="replaceable"><code>level</code></em></code>] {name}</p></div>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2597830"></a><h2>DESCRIPTION</h2>
+<p><span><strong class="command">dnssec-keygen</strong></span>
+      generates keys for DNSSEC (Secure DNS), as defined in RFC 2535
+      and RFC 4034.  It can also generate keys for use with
+      TSIG (Transaction Signatures), as defined in RFC 2845.
+    </p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2597844"></a><h2>OPTIONS</h2>
+<div class="variablelist"><dl>
+<dt><span class="term">-a <em class="replaceable"><code>algorithm</code></em></span></dt>
+<dd>
+<p>
+            Selects the cryptographic algorithm.  The value of
+            <code class="option">algorithm</code> must be one of RSAMD5 (RSA) or RSASHA1,
+            	      DSA, DH (Diffie Hellman), or HMAC-MD5.  These values
+            are case insensitive.
+          </p>
+<p>
+            Note 1: that for DNSSEC, RSASHA1 is a mandatory to implement
+            algorithm,
+            and DSA is recommended.  For TSIG, HMAC-MD5 is mandatory.
+          </p>
+<p>
+            Note 2: HMAC-MD5 and DH automatically set the -k flag.
+          </p>
+</dd>
+<dt><span class="term">-b <em class="replaceable"><code>keysize</code></em></span></dt>
+<dd><p>
+            Specifies the number of bits in the key.  The choice of key
+            size depends on the algorithm used.  RSAMD5 / RSASHA1 keys must be
+            between
+            512 and 2048 bits.  Diffie Hellman keys must be between
+            128 and 4096 bits.  DSA keys must be between 512 and 1024
+            bits and an exact multiple of 64.  HMAC-MD5 keys must be
+            between 1 and 512 bits.
+          </p></dd>
+<dt><span class="term">-n <em class="replaceable"><code>nametype</code></em></span></dt>
+<dd><p>
+            Specifies the owner type of the key.  The value of
+            <code class="option">nametype</code> must either be ZONE (for a DNSSEC
+            zone key (KEY/DNSKEY)), HOST or ENTITY (for a key associated with
+            a host (KEY)),
+            USER (for a key associated with a user(KEY)) or OTHER (DNSKEY).
+            These values are
+            case insensitive.
+          </p></dd>
+<dt><span class="term">-c <em class="replaceable"><code>class</code></em></span></dt>
+<dd><p>
+            Indicates that the DNS record containing the key should have
+            the specified class.  If not specified, class IN is used.
+          </p></dd>
+<dt><span class="term">-e</span></dt>
+<dd><p>
+            If generating an RSAMD5/RSASHA1 key, use a large exponent.
+          </p></dd>
+<dt><span class="term">-f <em class="replaceable"><code>flag</code></em></span></dt>
+<dd><p>
+            Set the specified flag in the flag field of the KEY/DNSKEY record.
+            		The only recognized flag is KSK (Key Signing Key) DNSKEY.
+          </p></dd>
+<dt><span class="term">-g <em class="replaceable"><code>generator</code></em></span></dt>
+<dd><p>
+            If generating a Diffie Hellman key, use this generator.
+            Allowed values are 2 and 5.  If no generator
+            is specified, a known prime from RFC 2539 will be used
+            if possible; otherwise the default is 2.
+          </p></dd>
+<dt><span class="term">-h</span></dt>
+<dd><p>
+            Prints a short summary of the options and arguments to
+            <span><strong class="command">dnssec-keygen</strong></span>.
+          </p></dd>
+<dt><span class="term">-k</span></dt>
+<dd><p>
+            Generate KEY records rather than DNSKEY records.
+          </p></dd>
+<dt><span class="term">-p <em class="replaceable"><code>protocol</code></em></span></dt>
+<dd><p>
+            Sets the protocol value for the generated key.  The protocol
+            is a number between 0 and 255.  The default is 3 (DNSSEC).
+            Other possible values for this argument are listed in
+            RFC 2535 and its successors.
+          </p></dd>
+<dt><span class="term">-r <em class="replaceable"><code>randomdev</code></em></span></dt>
+<dd><p>
+            Specifies the source of randomness.  If the operating
+            system does not provide a <code class="filename">/dev/random</code>
+            or equivalent device, the default source of randomness
+            is keyboard input.  <code class="filename">randomdev</code>
+            specifies
+            the name of a character device or file containing random
+            data to be used instead of the default.  The special value
+            <code class="filename">keyboard</code> indicates that keyboard
+            input should be used.
+          </p></dd>
+<dt><span class="term">-s <em class="replaceable"><code>strength</code></em></span></dt>
+<dd><p>
+            Specifies the strength value of the key.  The strength is
+            a number between 0 and 15, and currently has no defined
+            purpose in DNSSEC.
+          </p></dd>
+<dt><span class="term">-t <em class="replaceable"><code>type</code></em></span></dt>
+<dd><p>
+            Indicates the use of the key.  <code class="option">type</code> must be
+            one of AUTHCONF, NOAUTHCONF, NOAUTH, or NOCONF.  The default
+            is AUTHCONF.  AUTH refers to the ability to authenticate
+            data, and CONF the ability to encrypt data.
+          </p></dd>
+<dt><span class="term">-v <em class="replaceable"><code>level</code></em></span></dt>
+<dd><p>
+            Sets the debugging level.
+          </p></dd>
+</dl></div>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2598187"></a><h2>GENERATED KEYS</h2>
+<p>
+      When <span><strong class="command">dnssec-keygen</strong></span> completes
+      successfully,
+      it prints a string of the form <code class="filename">Knnnn.+aaa+iiiii</code>
+      to the standard output.  This is an identification string for
+      the key it has generated.
+    </p>
+<div class="itemizedlist"><ul type="disc">
+<li><p><code class="filename">nnnn</code> is the key name.
+        </p></li>
+<li><p><code class="filename">aaa</code> is the numeric representation
+          of the
+          algorithm.
+        </p></li>
+<li><p><code class="filename">iiiii</code> is the key identifier (or
+          footprint).
+        </p></li>
+</ul></div>
+<p><span><strong class="command">dnssec-keygen</strong></span> 
+      creates two files, with names based
+      on the printed string.  <code class="filename">Knnnn.+aaa+iiiii.key</code>
+      contains the public key, and
+      <code class="filename">Knnnn.+aaa+iiiii.private</code> contains the
+      private
+      key.
+    </p>
+<p>
+      The <code class="filename">.key</code> file contains a DNS KEY record
+      that
+      can be inserted into a zone file (directly or with a $INCLUDE
+      statement).
+    </p>
+<p>
+      The <code class="filename">.private</code> file contains
+      algorithm-specific
+      fields.  For obvious security reasons, this file does not have
+      general read permission.
+    </p>
+<p>
+      Both <code class="filename">.key</code> and <code class="filename">.private</code>
+      files are generated for symmetric encryption algorithms such as
+      HMAC-MD5, even though the public and private key are equivalent.
+    </p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2598295"></a><h2>EXAMPLE</h2>
+<p>
+      To generate a 768-bit DSA key for the domain
+      <strong class="userinput"><code>example.com</code></strong>, the following command would be
+      issued:
+    </p>
+<p><strong class="userinput"><code>dnssec-keygen -a DSA -b 768 -n ZONE example.com</code></strong>
+    </p>
+<p>
+      The command would print a string of the form:
+    </p>
+<p><strong class="userinput"><code>Kexample.com.+003+26160</code></strong>
+    </p>
+<p>
+      In this example, <span><strong class="command">dnssec-keygen</strong></span> creates
+      the files <code class="filename">Kexample.com.+003+26160.key</code>
+      and
+      <code class="filename">Kexample.com.+003+26160.private</code>.
+    </p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2600195"></a><h2>SEE ALSO</h2>
+<p><span class="citerefentry"><span class="refentrytitle">dnssec-signzone</span>(8)</span>,
+      <em class="citetitle">BIND 9 Administrator Reference Manual</em>,
+      <em class="citetitle">RFC 2535</em>,
+      <em class="citetitle">RFC 2845</em>,
+      <em class="citetitle">RFC 2539</em>.
+    </p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2600226"></a><h2>AUTHOR</h2>
+<p><span class="corpauthor">Internet Systems Consortium</span>
+    </p>
+</div>
+</div>
+<div class="navfooter">
+<hr>
+<table width="100%" summary="Navigation footer">
+<tr>
+<td width="40%" align="left">
+<a accesskey="p" href="man.host.html">Prev</a> </td>
+<td width="20%" align="center"><a accesskey="u" href="Bv9ARM.ch10.html">Up</a></td>
+<td width="40%" align="right"> <a accesskey="n" href="man.dnssec-signzone.html">Next</a>
+</td>
+</tr>
+<tr>
+<td width="40%" align="left" valign="top">host </td>
+<td width="20%" align="center"><a accesskey="h" href="Bv9ARM.html">Home</a></td>
+<td width="40%" align="right" valign="top"> <span class="application">dnssec-signzone</span>
+</td>
+</tr>
+</table>
+</div>
+</body>
+</html>
diff --git a/doc/arm/man.dnssec-signzone.html b/doc/arm/man.dnssec-signzone.html
new file mode 100644
index 0000000..2d0ce06
--- /dev/null
+++ b/doc/arm/man.dnssec-signzone.html
@@ -0,0 +1,323 @@
+<!--
+ - Copyright (C) 2004-2007 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2000-2003 Internet Software Consortium.
+ - 
+ - Permission to use, copy, modify, and distribute this software for any
+ - purpose with or without fee is hereby granted, provided that the above
+ - copyright notice and this permission notice appear in all copies.
+ - 
+ - THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
+ - REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
+ - AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
+ - INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
+ - LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
+ - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
+ - PERFORMANCE OF THIS SOFTWARE.
+-->
+<!-- $Id: man.dnssec-signzone.html,v 1.2.2.46 2007/10/31 01:35:59 marka Exp $ -->
+<html>
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
+<title>dnssec-signzone</title>
+<meta name="generator" content="DocBook XSL Stylesheets V1.71.1">
+<link rel="start" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual">
+<link rel="up" href="Bv9ARM.ch10.html" title="Manual pages">
+<link rel="prev" href="man.dnssec-keygen.html" title="dnssec-keygen">
+<link rel="next" href="man.named-checkconf.html" title="named-checkconf">
+</head>
+<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
+<div class="navheader">
+<table width="100%" summary="Navigation header">
+<tr><th colspan="3" align="center"><span class="application">dnssec-signzone</span></th></tr>
+<tr>
+<td width="20%" align="left">
+<a accesskey="p" href="man.dnssec-keygen.html">Prev</a> </td>
+<th width="60%" align="center">Manual pages</th>
+<td width="20%" align="right"> <a accesskey="n" href="man.named-checkconf.html">Next</a>
+</td>
+</tr>
+</table>
+<hr>
+</div>
+<div class="refentry" lang="en">
+<a name="man.dnssec-signzone"></a><div class="titlepage"></div>
+<div class="refnamediv">
+<h2>Name</h2>
+<p><span class="application">dnssec-signzone</span> &#8212; DNSSEC zone signing tool</p>
+</div>
+<div class="refsynopsisdiv">
+<h2>Synopsis</h2>
+<div class="cmdsynopsis"><p><code class="command">dnssec-signzone</code>  [<code class="option">-a</code>] [<code class="option">-c <em class="replaceable"><code>class</code></em></code>] [<code class="option">-d <em class="replaceable"><code>directory</code></em></code>] [<code class="option">-e <em class="replaceable"><code>end-time</code></em></code>] [<code class="option">-f <em class="replaceable"><code>output-file</code></em></code>] [<code class="option">-g</code>] [<code class="option">-h</code>] [<code class="option">-k <em class="replaceable"><code>key</code></em></code>] [<code class="option">-l <em class="replaceable"><code>domain</code></em></code>] [<code class="option">-i <em class="replaceable"><code>interval</code></em></code>] [<code class="option">-I <em class="replaceable"><code>input-format</code></em></code>] [<code class="option">-j <em class="replaceable"><code>jitter</code></em></code>] [<code class="option">-N <em class="replaceable"><code>soa-serial-format</code></em></code>] [<code class="option">-o <em class="replaceable"><code>origin</code></em></code>] [<code class="option">-O <em class="replaceable"><code>output-format</code></em></code>] [<code class="option">-p</code>] [<code class="option">-r <em class="replaceable"><code>randomdev</code></em></code>] [<code class="option">-s <em class="replaceable"><code>start-time</code></em></code>] [<code class="option">-t</code>] [<code class="option">-v <em class="replaceable"><code>level</code></em></code>] [<code class="option">-z</code>] {zonefile} [key...]</p></div>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2598823"></a><h2>DESCRIPTION</h2>
+<p><span><strong class="command">dnssec-signzone</strong></span>
+      signs a zone.  It generates
+      NSEC and RRSIG records and produces a signed version of the
+      zone. The security status of delegations from the signed zone
+      (that is, whether the child zones are secure or not) is
+      determined by the presence or absence of a
+      <code class="filename">keyset</code> file for each child zone.
+    </p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2598842"></a><h2>OPTIONS</h2>
+<div class="variablelist"><dl>
+<dt><span class="term">-a</span></dt>
+<dd><p>
+            Verify all generated signatures.
+          </p></dd>
+<dt><span class="term">-c <em class="replaceable"><code>class</code></em></span></dt>
+<dd><p>
+            Specifies the DNS class of the zone.
+          </p></dd>
+<dt><span class="term">-k <em class="replaceable"><code>key</code></em></span></dt>
+<dd><p>
+            Treat specified key as a key signing key ignoring any
+            key flags.  This option may be specified multiple times.
+          </p></dd>
+<dt><span class="term">-l <em class="replaceable"><code>domain</code></em></span></dt>
+<dd><p>
+            Generate a DLV set in addition to the key (DNSKEY) and DS sets.
+            The domain is appended to the name of the records.
+          </p></dd>
+<dt><span class="term">-d <em class="replaceable"><code>directory</code></em></span></dt>
+<dd><p>
+            Look for <code class="filename">keyset</code> files in
+            <code class="option">directory</code> as the directory
+          </p></dd>
+<dt><span class="term">-g</span></dt>
+<dd><p>
+            Generate DS records for child zones from keyset files.
+            Existing DS records will be removed.
+          </p></dd>
+<dt><span class="term">-s <em class="replaceable"><code>start-time</code></em></span></dt>
+<dd><p>
+            Specify the date and time when the generated RRSIG records
+            become valid.  This can be either an absolute or relative
+            time.  An absolute start time is indicated by a number
+            in YYYYMMDDHHMMSS notation; 20000530144500 denotes
+            14:45:00 UTC on May 30th, 2000.  A relative start time is
+            indicated by +N, which is N seconds from the current time.
+            If no <code class="option">start-time</code> is specified, the current
+            time minus 1 hour (to allow for clock skew) is used.
+          </p></dd>
+<dt><span class="term">-e <em class="replaceable"><code>end-time</code></em></span></dt>
+<dd><p>
+            Specify the date and time when the generated RRSIG records
+            expire.  As with <code class="option">start-time</code>, an absolute
+            time is indicated in YYYYMMDDHHMMSS notation.  A time relative
+            to the start time is indicated with +N, which is N seconds from
+            the start time.  A time relative to the current time is
+            indicated with now+N.  If no <code class="option">end-time</code> is
+            specified, 30 days from the start time is used as a default.
+          </p></dd>
+<dt><span class="term">-f <em class="replaceable"><code>output-file</code></em></span></dt>
+<dd><p>
+            The name of the output file containing the signed zone.  The
+            default is to append <code class="filename">.signed</code> to
+            the
+            input filename.
+          </p></dd>
+<dt><span class="term">-h</span></dt>
+<dd><p>
+            Prints a short summary of the options and arguments to
+            <span><strong class="command">dnssec-signzone</strong></span>.
+          </p></dd>
+<dt><span class="term">-i <em class="replaceable"><code>interval</code></em></span></dt>
+<dd>
+<p>
+            When a previously-signed zone is passed as input, records
+            may be resigned.  The <code class="option">interval</code> option
+            specifies the cycle interval as an offset from the current
+            time (in seconds).  If a RRSIG record expires after the
+            cycle interval, it is retained.  Otherwise, it is considered
+            to be expiring soon, and it will be replaced.
+          </p>
+<p>
+            The default cycle interval is one quarter of the difference
+            between the signature end and start times.  So if neither
+            <code class="option">end-time</code> or <code class="option">start-time</code>
+            are specified, <span><strong class="command">dnssec-signzone</strong></span>
+            generates
+            signatures that are valid for 30 days, with a cycle
+            interval of 7.5 days.  Therefore, if any existing RRSIG records
+            are due to expire in less than 7.5 days, they would be
+            replaced.
+          </p>
+</dd>
+<dt><span class="term">-I <em class="replaceable"><code>input-format</code></em></span></dt>
+<dd><p>
+            The format of the input zone file.
+	    Possible formats are <span><strong class="command">"text"</strong></span> (default)
+	    and <span><strong class="command">"raw"</strong></span>.
+	    This option is primarily intended to be used for dynamic
+            signed zones so that the dumped zone file in a non-text
+            format containing updates can be signed directly.
+	    The use of this option does not make much sense for
+	    non-dynamic zones.
+          </p></dd>
+<dt><span class="term">-j <em class="replaceable"><code>jitter</code></em></span></dt>
+<dd>
+<p>
+            When signing a zone with a fixed signature lifetime, all
+            RRSIG records issued at the time of signing expires
+            simultaneously.  If the zone is incrementally signed, i.e.
+            a previously-signed zone is passed as input to the signer,
+            all expired signatures have to be regenerated at about the
+            same time.  The <code class="option">jitter</code> option specifies a
+            jitter window that will be used to randomize the signature
+            expire time, thus spreading incremental signature
+            regeneration over time.
+          </p>
+<p>
+            Signature lifetime jitter also to some extent benefits
+            validators and servers by spreading out cache expiration,
+            i.e. if large numbers of RRSIGs don't expire at the same time
+            from all caches there will be less congestion than if all
+            validators need to refetch at mostly the same time.
+          </p>
+</dd>
+<dt><span class="term">-n <em class="replaceable"><code>ncpus</code></em></span></dt>
+<dd><p>
+            Specifies the number of threads to use.  By default, one
+            thread is started for each detected CPU.
+          </p></dd>
+<dt><span class="term">-N <em class="replaceable"><code>soa-serial-format</code></em></span></dt>
+<dd>
+<p>
+            The SOA serial number format of the signed zone.
+	    Possible formats are <span><strong class="command">"keep"</strong></span> (default),
+            <span><strong class="command">"increment"</strong></span> and
+	    <span><strong class="command">"unixtime"</strong></span>.
+          </p>
+<div class="variablelist"><dl>
+<dt><span class="term"><span><strong class="command">"keep"</strong></span></span></dt>
+<dd><p>Do not modify the SOA serial number.</p></dd>
+<dt><span class="term"><span><strong class="command">"increment"</strong></span></span></dt>
+<dd><p>Increment the SOA serial number using RFC 1982
+                      arithmetics.</p></dd>
+<dt><span class="term"><span><strong class="command">"unixtime"</strong></span></span></dt>
+<dd><p>Set the SOA serial number to the number of seconds
+	        since epoch.</p></dd>
+</dl></div>
+</dd>
+<dt><span class="term">-o <em class="replaceable"><code>origin</code></em></span></dt>
+<dd><p>
+            The zone origin.  If not specified, the name of the zone file
+            is assumed to be the origin.
+          </p></dd>
+<dt><span class="term">-O <em class="replaceable"><code>output-format</code></em></span></dt>
+<dd><p>
+            The format of the output file containing the signed zone.
+	    Possible formats are <span><strong class="command">"text"</strong></span> (default)
+	    and <span><strong class="command">"raw"</strong></span>.
+          </p></dd>
+<dt><span class="term">-p</span></dt>
+<dd><p>
+            Use pseudo-random data when signing the zone.  This is faster,
+            but less secure, than using real random data.  This option
+            may be useful when signing large zones or when the entropy
+            source is limited.
+          </p></dd>
+<dt><span class="term">-r <em class="replaceable"><code>randomdev</code></em></span></dt>
+<dd><p>
+            Specifies the source of randomness.  If the operating
+            system does not provide a <code class="filename">/dev/random</code>
+            or equivalent device, the default source of randomness
+            is keyboard input.  <code class="filename">randomdev</code>
+            specifies
+            the name of a character device or file containing random
+            data to be used instead of the default.  The special value
+            <code class="filename">keyboard</code> indicates that keyboard
+            input should be used.
+          </p></dd>
+<dt><span class="term">-t</span></dt>
+<dd><p>
+            Print statistics at completion.
+          </p></dd>
+<dt><span class="term">-v <em class="replaceable"><code>level</code></em></span></dt>
+<dd><p>
+            Sets the debugging level.
+          </p></dd>
+<dt><span class="term">-z</span></dt>
+<dd><p>
+            Ignore KSK flag on key when determining what to sign.
+          </p></dd>
+<dt><span class="term">zonefile</span></dt>
+<dd><p>
+            The file containing the zone to be signed.
+          </p></dd>
+<dt><span class="term">key</span></dt>
+<dd><p>
+	    Specify which keys should be used to sign the zone.  If
+	    no keys are specified, then the zone will be examined
+	    for DNSKEY records at the zone apex.  If these are found and
+	    there are matching private keys, in the current directory,
+	    then these will be used for signing.
+          </p></dd>
+</dl></div>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2641307"></a><h2>EXAMPLE</h2>
+<p>
+      The following command signs the <strong class="userinput"><code>example.com</code></strong>
+      zone with the DSA key generated by <span><strong class="command">dnssec-keygen</strong></span>
+      (Kexample.com.+003+17247).  The zone's keys must be in the master
+      file (<code class="filename">db.example.com</code>).  This invocation looks
+      for <code class="filename">keyset</code> files, in the current directory,
+      so that DS records can be generated from them (<span><strong class="command">-g</strong></span>).
+    </p>
+<pre class="programlisting">% dnssec-signzone -g -o example.com db.example.com \
+Kexample.com.+003+17247
+db.example.com.signed
+%</pre>
+<p>
+      In the above example, <span><strong class="command">dnssec-signzone</strong></span> creates
+      the file <code class="filename">db.example.com.signed</code>.  This
+      file should be referenced in a zone statement in a
+      <code class="filename">named.conf</code> file.
+    </p>
+<p>
+      This example re-signs a previously signed zone with default parameters.
+      The private keys are assumed to be in the current directory.
+    </p>
+<pre class="programlisting">% cp db.example.com.signed db.example.com
+% dnssec-signzone -o example.com db.example.com
+db.example.com.signed
+%</pre>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2641380"></a><h2>SEE ALSO</h2>
+<p><span class="citerefentry"><span class="refentrytitle">dnssec-keygen</span>(8)</span>,
+      <em class="citetitle">BIND 9 Administrator Reference Manual</em>,
+      <em class="citetitle">RFC 2535</em>.
+    </p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2641404"></a><h2>AUTHOR</h2>
+<p><span class="corpauthor">Internet Systems Consortium</span>
+    </p>
+</div>
+</div>
+<div class="navfooter">
+<hr>
+<table width="100%" summary="Navigation footer">
+<tr>
+<td width="40%" align="left">
+<a accesskey="p" href="man.dnssec-keygen.html">Prev</a> </td>
+<td width="20%" align="center"><a accesskey="u" href="Bv9ARM.ch10.html">Up</a></td>
+<td width="40%" align="right"> <a accesskey="n" href="man.named-checkconf.html">Next</a>
+</td>
+</tr>
+<tr>
+<td width="40%" align="left" valign="top">
+<span class="application">dnssec-keygen</span> </td>
+<td width="20%" align="center"><a accesskey="h" href="Bv9ARM.html">Home</a></td>
+<td width="40%" align="right" valign="top"> <span class="application">named-checkconf</span>
+</td>
+</tr>
+</table>
+</div>
+</body>
+</html>
diff --git a/doc/arm/man.host.html b/doc/arm/man.host.html
new file mode 100644
index 0000000..6bc2188
--- /dev/null
+++ b/doc/arm/man.host.html
@@ -0,0 +1,249 @@
+<!--
+ - Copyright (C) 2004-2007 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2000-2003 Internet Software Consortium.
+ - 
+ - Permission to use, copy, modify, and distribute this software for any
+ - purpose with or without fee is hereby granted, provided that the above
+ - copyright notice and this permission notice appear in all copies.
+ - 
+ - THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
+ - REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
+ - AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
+ - INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
+ - LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
+ - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
+ - PERFORMANCE OF THIS SOFTWARE.
+-->
+<!-- $Id: man.host.html,v 1.2.2.46 2007/10/31 01:35:59 marka Exp $ -->
+<html>
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
+<title>host</title>
+<meta name="generator" content="DocBook XSL Stylesheets V1.71.1">
+<link rel="start" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual">
+<link rel="up" href="Bv9ARM.ch10.html" title="Manual pages">
+<link rel="prev" href="man.dig.html" title="dig">
+<link rel="next" href="man.dnssec-keygen.html" title="dnssec-keygen">
+</head>
+<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
+<div class="navheader">
+<table width="100%" summary="Navigation header">
+<tr><th colspan="3" align="center">host</th></tr>
+<tr>
+<td width="20%" align="left">
+<a accesskey="p" href="man.dig.html">Prev</a> </td>
+<th width="60%" align="center">Manual pages</th>
+<td width="20%" align="right"> <a accesskey="n" href="man.dnssec-keygen.html">Next</a>
+</td>
+</tr>
+</table>
+<hr>
+</div>
+<div class="refentry" lang="en">
+<a name="man.host"></a><div class="titlepage"></div>
+<div class="refnamediv">
+<h2>Name</h2>
+<p>host &#8212; DNS lookup utility</p>
+</div>
+<div class="refsynopsisdiv">
+<h2>Synopsis</h2>
+<div class="cmdsynopsis"><p><code class="command">host</code>  [<code class="option">-aCdlnrsTwv</code>] [<code class="option">-c <em class="replaceable"><code>class</code></em></code>] [<code class="option">-N <em class="replaceable"><code>ndots</code></em></code>] [<code class="option">-R <em class="replaceable"><code>number</code></em></code>] [<code class="option">-t <em class="replaceable"><code>type</code></em></code>] [<code class="option">-W <em class="replaceable"><code>wait</code></em></code>] [<code class="option">-m <em class="replaceable"><code>flag</code></em></code>] [<code class="option">-4</code>] [<code class="option">-6</code>] {name} [server]</p></div>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2597000"></a><h2>DESCRIPTION</h2>
+<p><span><strong class="command">host</strong></span>
+      is a simple utility for performing DNS lookups.
+      It is normally used to convert names to IP addresses and vice versa.
+      When no arguments or options are given,
+      <span><strong class="command">host</strong></span>
+      prints a short summary of its command line arguments and options.
+    </p>
+<p><em class="parameter"><code>name</code></em> is the domain name that is to be
+      looked
+      up.  It can also be a dotted-decimal IPv4 address or a colon-delimited
+      IPv6 address, in which case <span><strong class="command">host</strong></span> will by
+      default
+      perform a reverse lookup for that address.
+      <em class="parameter"><code>server</code></em> is an optional argument which
+      is either
+      the name or IP address of the name server that <span><strong class="command">host</strong></span>
+      should query instead of the server or servers listed in
+      <code class="filename">/etc/resolv.conf</code>.
+    </p>
+<p>
+      The <code class="option">-a</code> (all) option is equivalent to setting the
+      <code class="option">-v</code> option and asking <span><strong class="command">host</strong></span> to make
+      a query of type ANY.
+    </p>
+<p>
+      When the <code class="option">-C</code> option is used, <span><strong class="command">host</strong></span>
+      will attempt to display the SOA records for zone
+      <em class="parameter"><code>name</code></em> from all the listed
+      authoritative name
+      servers for that zone.  The list of name servers is defined by the NS
+      records that are found for the zone.
+    </p>
+<p>
+      The <code class="option">-c</code> option instructs to make a DNS query of class
+      <em class="parameter"><code>class</code></em>.  This can be used to lookup
+      Hesiod or
+      Chaosnet class resource records.  The default class is IN (Internet).
+    </p>
+<p>
+      Verbose output is generated by <span><strong class="command">host</strong></span> when
+      the
+      <code class="option">-d</code> or <code class="option">-v</code> option is used.  The two
+      options are equivalent.  They have been provided for backwards
+      compatibility.  In previous versions, the <code class="option">-d</code> option
+      switched on debugging traces and <code class="option">-v</code> enabled verbose
+      output.
+    </p>
+<p>
+      List mode is selected by the <code class="option">-l</code> option.  This makes
+      <span><strong class="command">host</strong></span> perform a zone transfer for zone
+      <em class="parameter"><code>name</code></em>.  Transfer the zone printing out
+      the NS, PTR
+      and address records (A/AAAA).  If combined with <code class="option">-a</code>
+      all records will be printed.
+    </p>
+<p>
+      The <code class="option">-i</code>
+      option specifies that reverse lookups of IPv6 addresses should
+      use the IP6.INT domain as defined in RFC1886.
+      The default is to use IP6.ARPA.
+    </p>
+<p>
+      The <code class="option">-N</code> option sets the number of dots that have to be
+      in <em class="parameter"><code>name</code></em> for it to be considered
+      absolute.  The
+      default value is that defined using the ndots statement in
+      <code class="filename">/etc/resolv.conf</code>, or 1 if no ndots
+      statement is
+      present.  Names with fewer dots are interpreted as relative names and
+      will be searched for in the domains listed in the <span class="type">search</span>
+      or <span class="type">domain</span> directive in
+      <code class="filename">/etc/resolv.conf</code>.
+    </p>
+<p>
+      The number of UDP retries for a lookup can be changed with the
+      <code class="option">-R</code> option.  <em class="parameter"><code>number</code></em>
+      indicates
+      how many times <span><strong class="command">host</strong></span> will repeat a query
+      that does
+      not get answered.  The default number of retries is 1.  If
+      <em class="parameter"><code>number</code></em> is negative or zero, the
+      number of
+      retries will default to 1.
+    </p>
+<p>
+      Non-recursive queries can be made via the <code class="option">-r</code> option.
+      Setting this option clears the <span class="type">RD</span> &#8212; recursion
+      desired &#8212; bit in the query which <span><strong class="command">host</strong></span> makes.
+      This should mean that the name server receiving the query will not
+      attempt to resolve <em class="parameter"><code>name</code></em>.  The
+      <code class="option">-r</code> option enables <span><strong class="command">host</strong></span>
+      to mimic
+      the behavior of a name server by making non-recursive queries and
+      expecting to receive answers to those queries that are usually
+      referrals to other name servers.
+    </p>
+<p>
+      By default <span><strong class="command">host</strong></span> uses UDP when making
+      queries.  The
+      <code class="option">-T</code> option makes it use a TCP connection when querying
+      the name server.  TCP will be automatically selected for queries that
+      require it, such as zone transfer (AXFR) requests.
+    </p>
+<p>
+      The <code class="option">-4</code> option forces <span><strong class="command">host</strong></span> to only
+      use IPv4 query transport.  The <code class="option">-6</code> option forces
+      <span><strong class="command">host</strong></span> to only use IPv6 query transport.
+    </p>
+<p>
+      The <code class="option">-t</code> option is used to select the query type.
+      <em class="parameter"><code>type</code></em> can be any recognized query
+      type: CNAME,
+      NS, SOA, SIG, KEY, AXFR, etc.  When no query type is specified,
+      <span><strong class="command">host</strong></span> automatically selects an appropriate
+      query
+      type.  By default it looks for A records, but if the
+      <code class="option">-C</code> option was given, queries will be made for SOA
+      records, and if <em class="parameter"><code>name</code></em> is a
+      dotted-decimal IPv4
+      address or colon-delimited IPv6 address, <span><strong class="command">host</strong></span> will
+      query for PTR records.  If a query type of IXFR is chosen the starting
+      serial number can be specified by appending an equal followed by the
+      starting serial number (e.g. -t IXFR=12345678).
+    </p>
+<p>
+      The time to wait for a reply can be controlled through the
+      <code class="option">-W</code> and <code class="option">-w</code> options.  The
+      <code class="option">-W</code> option makes <span><strong class="command">host</strong></span>
+      wait for
+      <em class="parameter"><code>wait</code></em> seconds.  If <em class="parameter"><code>wait</code></em>
+      is less than one, the wait interval is set to one second.  When the
+      <code class="option">-w</code> option is used, <span><strong class="command">host</strong></span>
+      will
+      effectively wait forever for a reply.  The time to wait for a response
+      will be set to the number of seconds given by the hardware's maximum
+      value for an integer quantity.
+    </p>
+<p>
+      The <code class="option">-s</code> option tells <span><strong class="command">host</strong></span> 
+      <span class="emphasis"><em>not</em></span> to send the query to the next nameserver
+      if any server responds with a SERVFAIL response, which is the
+      reverse of normal stub resolver behavior.
+    </p>
+<p>
+      The <code class="option">-m</code> can be used to set the memory usage debugging
+      flags
+      <em class="parameter"><code>record</code></em>, <em class="parameter"><code>usage</code></em> and
+      <em class="parameter"><code>trace</code></em>.
+    </p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2597514"></a><h2>IDN SUPPORT</h2>
+<p>
+      If <span><strong class="command">host</strong></span> has been built with IDN (internationalized
+      domain name) support, it can accept and display non-ASCII domain names. 
+      <span><strong class="command">host</strong></span> appropriately converts character encoding of
+      domain name before sending a request to DNS server or displaying a
+      reply from the server.
+      If you'd like to turn off the IDN support for some reason, defines
+      the <code class="envar">IDN_DISABLE</code> environment variable.
+      The IDN support is disabled if the variable is set when
+      <span><strong class="command">host</strong></span> runs.
+    </p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2597543"></a><h2>FILES</h2>
+<p><code class="filename">/etc/resolv.conf</code>
+    </p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2597557"></a><h2>SEE ALSO</h2>
+<p><span class="citerefentry"><span class="refentrytitle">dig</span>(1)</span>,
+      <span class="citerefentry"><span class="refentrytitle">named</span>(8)</span>.
+    </p>
+</div>
+</div>
+<div class="navfooter">
+<hr>
+<table width="100%" summary="Navigation footer">
+<tr>
+<td width="40%" align="left">
+<a accesskey="p" href="man.dig.html">Prev</a> </td>
+<td width="20%" align="center"><a accesskey="u" href="Bv9ARM.ch10.html">Up</a></td>
+<td width="40%" align="right"> <a accesskey="n" href="man.dnssec-keygen.html">Next</a>
+</td>
+</tr>
+<tr>
+<td width="40%" align="left" valign="top">dig </td>
+<td width="20%" align="center"><a accesskey="h" href="Bv9ARM.html">Home</a></td>
+<td width="40%" align="right" valign="top"> <span class="application">dnssec-keygen</span>
+</td>
+</tr>
+</table>
+</div>
+</body>
+</html>
diff --git a/doc/arm/man.named-checkconf.html b/doc/arm/man.named-checkconf.html
new file mode 100644
index 0000000..7db5021
--- /dev/null
+++ b/doc/arm/man.named-checkconf.html
@@ -0,0 +1,130 @@
+<!--
+ - Copyright (C) 2004-2007 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2000-2003 Internet Software Consortium.
+ - 
+ - Permission to use, copy, modify, and distribute this software for any
+ - purpose with or without fee is hereby granted, provided that the above
+ - copyright notice and this permission notice appear in all copies.
+ - 
+ - THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
+ - REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
+ - AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
+ - INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
+ - LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
+ - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
+ - PERFORMANCE OF THIS SOFTWARE.
+-->
+<!-- $Id: man.named-checkconf.html,v 1.2.2.49 2007/10/31 01:35:59 marka Exp $ -->
+<html>
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
+<title>named-checkconf</title>
+<meta name="generator" content="DocBook XSL Stylesheets V1.71.1">
+<link rel="start" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual">
+<link rel="up" href="Bv9ARM.ch10.html" title="Manual pages">
+<link rel="prev" href="man.dnssec-signzone.html" title="dnssec-signzone">
+<link rel="next" href="man.named-checkzone.html" title="named-checkzone">
+</head>
+<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
+<div class="navheader">
+<table width="100%" summary="Navigation header">
+<tr><th colspan="3" align="center"><span class="application">named-checkconf</span></th></tr>
+<tr>
+<td width="20%" align="left">
+<a accesskey="p" href="man.dnssec-signzone.html">Prev</a> </td>
+<th width="60%" align="center">Manual pages</th>
+<td width="20%" align="right"> <a accesskey="n" href="man.named-checkzone.html">Next</a>
+</td>
+</tr>
+</table>
+<hr>
+</div>
+<div class="refentry" lang="en">
+<a name="man.named-checkconf"></a><div class="titlepage"></div>
+<div class="refnamediv">
+<h2>Name</h2>
+<p><span class="application">named-checkconf</span> &#8212; named configuration file syntax checking tool</p>
+</div>
+<div class="refsynopsisdiv">
+<h2>Synopsis</h2>
+<div class="cmdsynopsis"><p><code class="command">named-checkconf</code>  [<code class="option">-v</code>] [<code class="option">-j</code>] [<code class="option">-t <em class="replaceable"><code>directory</code></em></code>] {filename} [<code class="option">-z</code>]</p></div>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2599604"></a><h2>DESCRIPTION</h2>
+<p><span><strong class="command">named-checkconf</strong></span>
+      checks the syntax, but not the semantics, of a named
+      configuration file.
+    </p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2599618"></a><h2>OPTIONS</h2>
+<div class="variablelist"><dl>
+<dt><span class="term">-t <em class="replaceable"><code>directory</code></em></span></dt>
+<dd><p>
+            Chroot to <code class="filename">directory</code> so that
+            include
+            directives in the configuration file are processed as if
+            run by a similarly chrooted named.
+          </p></dd>
+<dt><span class="term">-v</span></dt>
+<dd><p>
+            Print the version of the <span><strong class="command">named-checkconf</strong></span>
+            program and exit.
+          </p></dd>
+<dt><span class="term">-z</span></dt>
+<dd><p>
+	    Perform a test load of all master zones found in
+	    <code class="filename">named.conf</code>.
+          </p></dd>
+<dt><span class="term">-j</span></dt>
+<dd><p>
+            When loading a zonefile read the journal if it exists.
+          </p></dd>
+<dt><span class="term">filename</span></dt>
+<dd><p>
+            The name of the configuration file to be checked.  If not
+            specified, it defaults to <code class="filename">/etc/named.conf</code>.
+          </p></dd>
+</dl></div>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2599720"></a><h2>RETURN VALUES</h2>
+<p><span><strong class="command">named-checkconf</strong></span>
+      returns an exit status of 1 if
+      errors were detected and 0 otherwise.
+    </p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2599734"></a><h2>SEE ALSO</h2>
+<p><span class="citerefentry"><span class="refentrytitle">named</span>(8)</span>,
+      <span class="citerefentry"><span class="refentrytitle">named-checkzone</span>(8)</span>,
+      <em class="citetitle">BIND 9 Administrator Reference Manual</em>.
+    </p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2599764"></a><h2>AUTHOR</h2>
+<p><span class="corpauthor">Internet Systems Consortium</span>
+    </p>
+</div>
+</div>
+<div class="navfooter">
+<hr>
+<table width="100%" summary="Navigation footer">
+<tr>
+<td width="40%" align="left">
+<a accesskey="p" href="man.dnssec-signzone.html">Prev</a> </td>
+<td width="20%" align="center"><a accesskey="u" href="Bv9ARM.ch10.html">Up</a></td>
+<td width="40%" align="right"> <a accesskey="n" href="man.named-checkzone.html">Next</a>
+</td>
+</tr>
+<tr>
+<td width="40%" align="left" valign="top">
+<span class="application">dnssec-signzone</span> </td>
+<td width="20%" align="center"><a accesskey="h" href="Bv9ARM.html">Home</a></td>
+<td width="40%" align="right" valign="top"> <span class="application">named-checkzone</span>
+</td>
+</tr>
+</table>
+</div>
+</body>
+</html>
diff --git a/doc/arm/man.named-checkzone.html b/doc/arm/man.named-checkzone.html
new file mode 100644
index 0000000..93e17ec
--- /dev/null
+++ b/doc/arm/man.named-checkzone.html
@@ -0,0 +1,294 @@
+<!--
+ - Copyright (C) 2004-2007 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2000-2003 Internet Software Consortium.
+ - 
+ - Permission to use, copy, modify, and distribute this software for any
+ - purpose with or without fee is hereby granted, provided that the above
+ - copyright notice and this permission notice appear in all copies.
+ - 
+ - THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
+ - REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
+ - AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
+ - INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
+ - LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
+ - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
+ - PERFORMANCE OF THIS SOFTWARE.
+-->
+<!-- $Id: man.named-checkzone.html,v 1.2.2.52 2007/10/31 01:35:59 marka Exp $ -->
+<html>
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
+<title>named-checkzone</title>
+<meta name="generator" content="DocBook XSL Stylesheets V1.71.1">
+<link rel="start" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual">
+<link rel="up" href="Bv9ARM.ch10.html" title="Manual pages">
+<link rel="prev" href="man.named-checkconf.html" title="named-checkconf">
+<link rel="next" href="man.named.html" title="named">
+</head>
+<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
+<div class="navheader">
+<table width="100%" summary="Navigation header">
+<tr><th colspan="3" align="center"><span class="application">named-checkzone</span></th></tr>
+<tr>
+<td width="20%" align="left">
+<a accesskey="p" href="man.named-checkconf.html">Prev</a> </td>
+<th width="60%" align="center">Manual pages</th>
+<td width="20%" align="right"> <a accesskey="n" href="man.named.html">Next</a>
+</td>
+</tr>
+</table>
+<hr>
+</div>
+<div class="refentry" lang="en">
+<a name="man.named-checkzone"></a><div class="titlepage"></div>
+<div class="refnamediv">
+<h2>Name</h2>
+<p><span class="application">named-checkzone</span>, <span class="application">named-compilezone</span> &#8212; zone file validity checking or converting tool</p>
+</div>
+<div class="refsynopsisdiv">
+<h2>Synopsis</h2>
+<div class="cmdsynopsis"><p><code class="command">named-checkzone</code>  [<code class="option">-d</code>] [<code class="option">-j</code>] [<code class="option">-q</code>] [<code class="option">-v</code>] [<code class="option">-c <em class="replaceable"><code>class</code></em></code>] [<code class="option">-f <em class="replaceable"><code>format</code></em></code>] [<code class="option">-F <em class="replaceable"><code>format</code></em></code>] [<code class="option">-i <em class="replaceable"><code>mode</code></em></code>] [<code class="option">-k <em class="replaceable"><code>mode</code></em></code>] [<code class="option">-m <em class="replaceable"><code>mode</code></em></code>] [<code class="option">-M <em class="replaceable"><code>mode</code></em></code>] [<code class="option">-n <em class="replaceable"><code>mode</code></em></code>] [<code class="option">-o <em class="replaceable"><code>filename</code></em></code>] [<code class="option">-s <em class="replaceable"><code>style</code></em></code>] [<code class="option">-S <em class="replaceable"><code>mode</code></em></code>] [<code class="option">-t <em class="replaceable"><code>directory</code></em></code>] [<code class="option">-w <em class="replaceable"><code>directory</code></em></code>] [<code class="option">-D</code>] [<code class="option">-W <em class="replaceable"><code>mode</code></em></code>] {zonename} {filename}</p></div>
+<div class="cmdsynopsis"><p><code class="command">named-compilezone</code>  [<code class="option">-d</code>] [<code class="option">-j</code>] [<code class="option">-q</code>] [<code class="option">-v</code>] [<code class="option">-c <em class="replaceable"><code>class</code></em></code>] [<code class="option">-C <em class="replaceable"><code>mode</code></em></code>] [<code class="option">-f <em class="replaceable"><code>format</code></em></code>] [<code class="option">-F <em class="replaceable"><code>format</code></em></code>] [<code class="option">-i <em class="replaceable"><code>mode</code></em></code>] [<code class="option">-k <em class="replaceable"><code>mode</code></em></code>] [<code class="option">-m <em class="replaceable"><code>mode</code></em></code>] [<code class="option">-n <em class="replaceable"><code>mode</code></em></code>] [<code class="option">-o <em class="replaceable"><code>filename</code></em></code>] [<code class="option">-s <em class="replaceable"><code>style</code></em></code>] [<code class="option">-t <em class="replaceable"><code>directory</code></em></code>] [<code class="option">-w <em class="replaceable"><code>directory</code></em></code>] [<code class="option">-D</code>] [<code class="option">-W <em class="replaceable"><code>mode</code></em></code>] {zonename} {filename}</p></div>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2600689"></a><h2>DESCRIPTION</h2>
+<p><span><strong class="command">named-checkzone</strong></span>
+      checks the syntax and integrity of a zone file.  It performs the
+      same checks as <span><strong class="command">named</strong></span> does when loading a
+      zone.  This makes <span><strong class="command">named-checkzone</strong></span> useful for
+      checking zone files before configuring them into a name server.
+    </p>
+<p>
+        <span><strong class="command">named-compilezone</strong></span> is similar to
+	<span><strong class="command">named-checkzone</strong></span>, but it always dumps the
+        zone contents to a specified file in a specified format.
+	Additionally, it applies stricter check levels by default,
+        since the dump output will be used as an actual zone file
+	loaded by <span><strong class="command">named</strong></span>.
+	When manually specified otherwise, the check levels must at
+        least be as strict as those specified in the
+	<span><strong class="command">named</strong></span> configuration file.
+     </p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2600739"></a><h2>OPTIONS</h2>
+<div class="variablelist"><dl>
+<dt><span class="term">-d</span></dt>
+<dd><p>
+            Enable debugging.
+          </p></dd>
+<dt><span class="term">-q</span></dt>
+<dd><p>
+            Quiet mode - exit code only.
+          </p></dd>
+<dt><span class="term">-v</span></dt>
+<dd><p>
+            Print the version of the <span><strong class="command">named-checkzone</strong></span>
+            program and exit.
+          </p></dd>
+<dt><span class="term">-j</span></dt>
+<dd><p>
+            When loading the zone file read the journal if it exists.
+          </p></dd>
+<dt><span class="term">-c <em class="replaceable"><code>class</code></em></span></dt>
+<dd><p>
+            Specify the class of the zone.  If not specified "IN" is assumed.
+          </p></dd>
+<dt><span class="term">-i <em class="replaceable"><code>mode</code></em></span></dt>
+<dd>
+<p>
+	      Perform post-load zone integrity checks.  Possible modes are
+	      <span><strong class="command">"full"</strong></span> (default),
+	      <span><strong class="command">"full-sibling"</strong></span>,
+	      <span><strong class="command">"local"</strong></span>,
+	      <span><strong class="command">"local-sibling"</strong></span> and
+	      <span><strong class="command">"none"</strong></span>.
+	  </p>
+<p>
+	      Mode <span><strong class="command">"full"</strong></span> checks that MX records
+	      refer to A or AAAA record (both in-zone and out-of-zone
+	      hostnames).  Mode <span><strong class="command">"local"</strong></span> only
+	      checks MX records which refer to in-zone hostnames.
+	  </p>
+<p>
+	      Mode <span><strong class="command">"full"</strong></span> checks that SRV records
+	      refer to A or AAAA record (both in-zone and out-of-zone
+	      hostnames).  Mode <span><strong class="command">"local"</strong></span> only
+	      checks SRV records which refer to in-zone hostnames.
+	  </p>
+<p>
+	      Mode <span><strong class="command">"full"</strong></span> checks that delegation NS
+	      records refer to A or AAAA record (both in-zone and out-of-zone
+	      hostnames).  It also checks that glue address records
+	      in the zone match those advertised by the child.
+	      Mode <span><strong class="command">"local"</strong></span> only checks NS records which
+	      refer to in-zone hostnames or that some required glue exists,
+	      that is when the nameserver is in a child zone.
+	  </p>
+<p>
+	      Mode <span><strong class="command">"full-sibling"</strong></span> and
+	      <span><strong class="command">"local-sibling"</strong></span> disable sibling glue
+	      checks but are otherwise the same as <span><strong class="command">"full"</strong></span>
+	      and <span><strong class="command">"local"</strong></span> respectively.
+	  </p>
+<p>
+	      Mode <span><strong class="command">"none"</strong></span> disables the checks.
+	  </p>
+</dd>
+<dt><span class="term">-f <em class="replaceable"><code>format</code></em></span></dt>
+<dd><p>
+	    Specify the format of the zone file.
+	    Possible formats are <span><strong class="command">"text"</strong></span> (default)
+	    and <span><strong class="command">"raw"</strong></span>.
+	  </p></dd>
+<dt><span class="term">-F <em class="replaceable"><code>format</code></em></span></dt>
+<dd><p>
+	    Specify the format of the output file specified.
+	    Possible formats are <span><strong class="command">"text"</strong></span> (default)
+	    and <span><strong class="command">"raw"</strong></span>.
+	    For <span><strong class="command">named-checkzone</strong></span>,
+	    this does not cause any effects unless it dumps the zone
+	    contents.
+	  </p></dd>
+<dt><span class="term">-k <em class="replaceable"><code>mode</code></em></span></dt>
+<dd><p>
+            Perform <span><strong class="command">"check-names"</strong></span> checks with the
+	    specified failure mode.
+            Possible modes are <span><strong class="command">"fail"</strong></span>
+	    (default for <span><strong class="command">named-compilezone</strong></span>),
+            <span><strong class="command">"warn"</strong></span>
+	    (default for <span><strong class="command">named-checkzone</strong></span>) and
+            <span><strong class="command">"ignore"</strong></span>.
+          </p></dd>
+<dt><span class="term">-m <em class="replaceable"><code>mode</code></em></span></dt>
+<dd><p>
+            Specify whether MX records should be checked to see if they
+            are addresses.  Possible modes are <span><strong class="command">"fail"</strong></span>,
+            <span><strong class="command">"warn"</strong></span> (default) and
+            <span><strong class="command">"ignore"</strong></span>.
+          </p></dd>
+<dt><span class="term">-M <em class="replaceable"><code>mode</code></em></span></dt>
+<dd><p>
+	    Check if a MX record refers to a CNAME.
+            Possible modes are <span><strong class="command">"fail"</strong></span>,
+            <span><strong class="command">"warn"</strong></span> (default) and
+            <span><strong class="command">"ignore"</strong></span>.
+	  </p></dd>
+<dt><span class="term">-n <em class="replaceable"><code>mode</code></em></span></dt>
+<dd><p>
+            Specify whether NS records should be checked to see if they
+            are addresses.
+	    Possible modes are <span><strong class="command">"fail"</strong></span>
+	    (default for <span><strong class="command">named-compilezone</strong></span>),
+            <span><strong class="command">"warn"</strong></span>
+	    (default for <span><strong class="command">named-checkzone</strong></span>) and
+            <span><strong class="command">"ignore"</strong></span>.
+          </p></dd>
+<dt><span class="term">-o <em class="replaceable"><code>filename</code></em></span></dt>
+<dd><p>
+            Write zone output to <code class="filename">filename</code>.
+	    This is mandatory for <span><strong class="command">named-compilezone</strong></span>.
+          </p></dd>
+<dt><span class="term">-s <em class="replaceable"><code>style</code></em></span></dt>
+<dd><p>
+	    Specify the style of the dumped zone file.
+	    Possible styles are <span><strong class="command">"full"</strong></span> (default)
+	    and <span><strong class="command">"relative"</strong></span>.
+	    The full format is most suitable for processing
+	    automatically by a separate script.
+	    On the other hand, the relative format is more
+	    human-readable and is thus suitable for editing by hand.
+	    For <span><strong class="command">named-checkzone</strong></span>
+	    this does not cause any effects unless it dumps the zone
+	    contents.
+	    It also does not have any meaning if the output format
+	    is not text.
+	  </p></dd>
+<dt><span class="term">-S <em class="replaceable"><code>mode</code></em></span></dt>
+<dd><p>
+	    Check if a SRV record refers to a CNAME.
+            Possible modes are <span><strong class="command">"fail"</strong></span>,
+            <span><strong class="command">"warn"</strong></span> (default) and
+            <span><strong class="command">"ignore"</strong></span>.
+	  </p></dd>
+<dt><span class="term">-t <em class="replaceable"><code>directory</code></em></span></dt>
+<dd><p>
+            Chroot to <code class="filename">directory</code> so that
+            include
+            directives in the configuration file are processed as if
+            run by a similarly chrooted named.
+          </p></dd>
+<dt><span class="term">-w <em class="replaceable"><code>directory</code></em></span></dt>
+<dd><p>
+            chdir to <code class="filename">directory</code> so that
+            relative
+            filenames in master file $INCLUDE directives work.  This
+            is similar to the directory clause in
+            <code class="filename">named.conf</code>.
+          </p></dd>
+<dt><span class="term">-D</span></dt>
+<dd><p>
+            Dump zone file in canonical format.
+	    This is always enabled for <span><strong class="command">named-compilezone</strong></span>.
+          </p></dd>
+<dt><span class="term">-W <em class="replaceable"><code>mode</code></em></span></dt>
+<dd><p>
+            Specify whether to check for non-terminal wildcards.
+            Non-terminal wildcards are almost always the result of a
+            failure to understand the wildcard matching algorithm (RFC 1034).
+            Possible modes are <span><strong class="command">"warn"</strong></span> (default)
+            and
+            <span><strong class="command">"ignore"</strong></span>.
+          </p></dd>
+<dt><span class="term">zonename</span></dt>
+<dd><p>
+            The domain name of the zone being checked.
+          </p></dd>
+<dt><span class="term">filename</span></dt>
+<dd><p>
+            The name of the zone file.
+          </p></dd>
+</dl></div>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2655177"></a><h2>RETURN VALUES</h2>
+<p><span><strong class="command">named-checkzone</strong></span>
+      returns an exit status of 1 if
+      errors were detected and 0 otherwise.
+    </p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2655191"></a><h2>SEE ALSO</h2>
+<p><span class="citerefentry"><span class="refentrytitle">named</span>(8)</span>,
+      <span class="citerefentry"><span class="refentrytitle">named-checkconf</span>(8)</span>,
+      <em class="citetitle">RFC 1035</em>,
+      <em class="citetitle">BIND 9 Administrator Reference Manual</em>.
+    </p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2655224"></a><h2>AUTHOR</h2>
+<p><span class="corpauthor">Internet Systems Consortium</span>
+    </p>
+</div>
+</div>
+<div class="navfooter">
+<hr>
+<table width="100%" summary="Navigation footer">
+<tr>
+<td width="40%" align="left">
+<a accesskey="p" href="man.named-checkconf.html">Prev</a> </td>
+<td width="20%" align="center"><a accesskey="u" href="Bv9ARM.ch10.html">Up</a></td>
+<td width="40%" align="right"> <a accesskey="n" href="man.named.html">Next</a>
+</td>
+</tr>
+<tr>
+<td width="40%" align="left" valign="top">
+<span class="application">named-checkconf</span> </td>
+<td width="20%" align="center"><a accesskey="h" href="Bv9ARM.html">Home</a></td>
+<td width="40%" align="right" valign="top"> <span class="application">named</span>
+</td>
+</tr>
+</table>
+</div>
+</body>
+</html>
diff --git a/doc/arm/man.named.html b/doc/arm/man.named.html
new file mode 100644
index 0000000..70539b4
--- /dev/null
+++ b/doc/arm/man.named.html
@@ -0,0 +1,293 @@
+<!--
+ - Copyright (C) 2004-2007 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2000-2003 Internet Software Consortium.
+ - 
+ - Permission to use, copy, modify, and distribute this software for any
+ - purpose with or without fee is hereby granted, provided that the above
+ - copyright notice and this permission notice appear in all copies.
+ - 
+ - THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
+ - REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
+ - AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
+ - INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
+ - LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
+ - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
+ - PERFORMANCE OF THIS SOFTWARE.
+-->
+<!-- $Id: man.named.html,v 1.2.2.53 2007/10/31 01:35:59 marka Exp $ -->
+<html>
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
+<title>named</title>
+<meta name="generator" content="DocBook XSL Stylesheets V1.71.1">
+<link rel="start" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual">
+<link rel="up" href="Bv9ARM.ch10.html" title="Manual pages">
+<link rel="prev" href="man.named-checkzone.html" title="named-checkzone">
+<link rel="next" href="man.rndc.html" title="rndc">
+</head>
+<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
+<div class="navheader">
+<table width="100%" summary="Navigation header">
+<tr><th colspan="3" align="center"><span class="application">named</span></th></tr>
+<tr>
+<td width="20%" align="left">
+<a accesskey="p" href="man.named-checkzone.html">Prev</a> </td>
+<th width="60%" align="center">Manual pages</th>
+<td width="20%" align="right"> <a accesskey="n" href="man.rndc.html">Next</a>
+</td>
+</tr>
+</table>
+<hr>
+</div>
+<div class="refentry" lang="en">
+<a name="man.named"></a><div class="titlepage"></div>
+<div class="refnamediv">
+<h2>Name</h2>
+<p><span class="application">named</span> &#8212; Internet domain name server</p>
+</div>
+<div class="refsynopsisdiv">
+<h2>Synopsis</h2>
+<div class="cmdsynopsis"><p><code class="command">named</code>  [<code class="option">-4</code>] [<code class="option">-6</code>] [<code class="option">-c <em class="replaceable"><code>config-file</code></em></code>] [<code class="option">-d <em class="replaceable"><code>debug-level</code></em></code>] [<code class="option">-f</code>] [<code class="option">-g</code>] [<code class="option">-m <em class="replaceable"><code>flag</code></em></code>] [<code class="option">-n <em class="replaceable"><code>#cpus</code></em></code>] [<code class="option">-p <em class="replaceable"><code>port</code></em></code>] [<code class="option">-s</code>] [<code class="option">-t <em class="replaceable"><code>directory</code></em></code>] [<code class="option">-u <em class="replaceable"><code>user</code></em></code>] [<code class="option">-v</code>] [<code class="option">-x <em class="replaceable"><code>cache-file</code></em></code>]</p></div>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2601798"></a><h2>DESCRIPTION</h2>
+<p><span><strong class="command">named</strong></span>
+      is a Domain Name System (DNS) server,
+      part of the BIND 9 distribution from ISC.  For more
+      information on the DNS, see RFCs 1033, 1034, and 1035.
+    </p>
+<p>
+      When invoked without arguments, <span><strong class="command">named</strong></span>
+      will
+      read the default configuration file
+      <code class="filename">/etc/named.conf</code>, read any initial
+      data, and listen for queries.
+    </p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2601829"></a><h2>OPTIONS</h2>
+<div class="variablelist"><dl>
+<dt><span class="term">-4</span></dt>
+<dd><p>
+            Use IPv4 only even if the host machine is capable of IPv6.
+            <code class="option">-4</code> and <code class="option">-6</code> are mutually
+            exclusive.
+          </p></dd>
+<dt><span class="term">-6</span></dt>
+<dd><p>
+            Use IPv6 only even if the host machine is capable of IPv4.
+            <code class="option">-4</code> and <code class="option">-6</code> are mutually
+            exclusive.
+          </p></dd>
+<dt><span class="term">-c <em class="replaceable"><code>config-file</code></em></span></dt>
+<dd><p>
+            Use <em class="replaceable"><code>config-file</code></em> as the
+            configuration file instead of the default,
+            <code class="filename">/etc/named.conf</code>.  To
+            ensure that reloading the configuration file continues
+            to work after the server has changed its working
+            directory due to to a possible
+            <code class="option">directory</code> option in the configuration
+            file, <em class="replaceable"><code>config-file</code></em> should be
+            an absolute pathname.
+          </p></dd>
+<dt><span class="term">-d <em class="replaceable"><code>debug-level</code></em></span></dt>
+<dd><p>
+            Set the daemon's debug level to <em class="replaceable"><code>debug-level</code></em>.
+            Debugging traces from <span><strong class="command">named</strong></span> become
+            more verbose as the debug level increases.
+          </p></dd>
+<dt><span class="term">-f</span></dt>
+<dd><p>
+            Run the server in the foreground (i.e. do not daemonize).
+          </p></dd>
+<dt><span class="term">-g</span></dt>
+<dd><p>
+            Run the server in the foreground and force all logging
+            to <code class="filename">stderr</code>.
+          </p></dd>
+<dt><span class="term">-m <em class="replaceable"><code>flag</code></em></span></dt>
+<dd><p>
+	    Turn on memory usage debugging flags.  Possible flags are
+	    <em class="replaceable"><code>usage</code></em>,
+	    <em class="replaceable"><code>trace</code></em>,
+	    <em class="replaceable"><code>record</code></em>,
+	    <em class="replaceable"><code>size</code></em>, and
+	    <em class="replaceable"><code>mctx</code></em>.
+	    These correspond to the ISC_MEM_DEBUGXXXX flags described in
+	    <code class="filename">&lt;isc/mem.h&gt;</code>.
+          </p></dd>
+<dt><span class="term">-n <em class="replaceable"><code>#cpus</code></em></span></dt>
+<dd><p>
+            Create <em class="replaceable"><code>#cpus</code></em> worker threads
+            to take advantage of multiple CPUs.  If not specified,
+            <span><strong class="command">named</strong></span> will try to determine the
+            number of CPUs present and create one thread per CPU.
+            If it is unable to determine the number of CPUs, a
+            single worker thread will be created.
+          </p></dd>
+<dt><span class="term">-p <em class="replaceable"><code>port</code></em></span></dt>
+<dd><p>
+            Listen for queries on port <em class="replaceable"><code>port</code></em>.  If not
+            specified, the default is port 53.
+          </p></dd>
+<dt><span class="term">-s</span></dt>
+<dd>
+<p>
+            Write memory usage statistics to <code class="filename">stdout</code> on exit.
+          </p>
+<div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
+<h3 class="title">Note</h3>
+<p>
+              This option is mainly of interest to BIND 9 developers
+              and may be removed or changed in a future release.
+            </p>
+</div>
+</dd>
+<dt><span class="term">-t <em class="replaceable"><code>directory</code></em></span></dt>
+<dd>
+<p>Chroot
+	    to <em class="replaceable"><code>directory</code></em> after
+            processing the command line arguments, but before
+            reading the configuration file.
+          </p>
+<div class="warning" style="margin-left: 0.5in; margin-right: 0.5in;">
+<h3 class="title">Warning</h3>
+<p>
+              This option should be used in conjunction with the
+              <code class="option">-u</code> option, as chrooting a process
+              running as root doesn't enhance security on most
+              systems; the way <code class="function">chroot(2)</code> is
+              defined allows a process with root privileges to
+              escape a chroot jail.
+            </p>
+</div>
+</dd>
+<dt><span class="term">-u <em class="replaceable"><code>user</code></em></span></dt>
+<dd>
+<p>Setuid
+	    to <em class="replaceable"><code>user</code></em> after completing
+            privileged operations, such as creating sockets that
+            listen on privileged ports.
+          </p>
+<div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
+<h3 class="title">Note</h3>
+<p>
+              On Linux, <span><strong class="command">named</strong></span> uses the kernel's
+              		capability mechanism to drop all root privileges
+              except the ability to <code class="function">bind(2)</code> to
+              a
+              privileged port and set process resource limits.
+              Unfortunately, this means that the <code class="option">-u</code>
+              option only works when <span><strong class="command">named</strong></span> is
+              run
+              on kernel 2.2.18 or later, or kernel 2.3.99-pre3 or
+              later, since previous kernels did not allow privileges
+              to be retained after <code class="function">setuid(2)</code>.
+            </p>
+</div>
+</dd>
+<dt><span class="term">-v</span></dt>
+<dd><p>
+            Report the version number and exit.
+          </p></dd>
+<dt><span class="term">-x <em class="replaceable"><code>cache-file</code></em></span></dt>
+<dd>
+<p>
+            Load data from <em class="replaceable"><code>cache-file</code></em> into the
+            cache of the default view.
+          </p>
+<div class="warning" style="margin-left: 0.5in; margin-right: 0.5in;">
+<h3 class="title">Warning</h3>
+<p>
+              This option must not be used.  It is only of interest
+              to BIND 9 developers and may be removed or changed in a
+              future release.
+            </p>
+</div>
+</dd>
+</dl></div>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2604492"></a><h2>SIGNALS</h2>
+<p>
+      In routine operation, signals should not be used to control
+      the nameserver; <span><strong class="command">rndc</strong></span> should be used
+      instead.
+    </p>
+<div class="variablelist"><dl>
+<dt><span class="term">SIGHUP</span></dt>
+<dd><p>
+            Force a reload of the server.
+          </p></dd>
+<dt><span class="term">SIGINT, SIGTERM</span></dt>
+<dd><p>
+            Shut down the server.
+          </p></dd>
+</dl></div>
+<p>
+      The result of sending any other signals to the server is undefined.
+    </p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2604542"></a><h2>CONFIGURATION</h2>
+<p>
+      The <span><strong class="command">named</strong></span> configuration file is too complex
+      to describe in detail here.  A complete description is provided
+      in the
+      <em class="citetitle">BIND 9 Administrator Reference Manual</em>.
+    </p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2604562"></a><h2>FILES</h2>
+<div class="variablelist"><dl>
+<dt><span class="term"><code class="filename">/etc/named.conf</code></span></dt>
+<dd><p>
+            The default configuration file.
+          </p></dd>
+<dt><span class="term"><code class="filename">/var/run/named.pid</code></span></dt>
+<dd><p>
+            The default process-id file.
+          </p></dd>
+</dl></div>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2604605"></a><h2>SEE ALSO</h2>
+<p><em class="citetitle">RFC 1033</em>,
+      <em class="citetitle">RFC 1034</em>,
+      <em class="citetitle">RFC 1035</em>,
+      <span class="citerefentry"><span class="refentrytitle">named-checkconf</span>(8)</span>,
+      <span class="citerefentry"><span class="refentrytitle">named-checkzone</span>(8)</span>,
+      <span class="citerefentry"><span class="refentrytitle">rndc</span>(8)</span>,
+      <span class="citerefentry"><span class="refentrytitle">lwresd</span>(8)</span>,
+      <span class="citerefentry"><span class="refentrytitle">named.conf</span>(5)</span>,
+      <em class="citetitle">BIND 9 Administrator Reference Manual</em>.
+    </p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2604881"></a><h2>AUTHOR</h2>
+<p><span class="corpauthor">Internet Systems Consortium</span>
+    </p>
+</div>
+</div>
+<div class="navfooter">
+<hr>
+<table width="100%" summary="Navigation footer">
+<tr>
+<td width="40%" align="left">
+<a accesskey="p" href="man.named-checkzone.html">Prev</a> </td>
+<td width="20%" align="center"><a accesskey="u" href="Bv9ARM.ch10.html">Up</a></td>
+<td width="40%" align="right"> <a accesskey="n" href="man.rndc.html">Next</a>
+</td>
+</tr>
+<tr>
+<td width="40%" align="left" valign="top">
+<span class="application">named-checkzone</span> </td>
+<td width="20%" align="center"><a accesskey="h" href="Bv9ARM.html">Home</a></td>
+<td width="40%" align="right" valign="top"> <span class="application">rndc</span>
+</td>
+</tr>
+</table>
+</div>
+</body>
+</html>
diff --git a/doc/arm/man.rndc-confgen.html b/doc/arm/man.rndc-confgen.html
new file mode 100644
index 0000000..056bcbd
--- /dev/null
+++ b/doc/arm/man.rndc-confgen.html
@@ -0,0 +1,222 @@
+<!--
+ - Copyright (C) 2004-2007 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2000-2003 Internet Software Consortium.
+ - 
+ - Permission to use, copy, modify, and distribute this software for any
+ - purpose with or without fee is hereby granted, provided that the above
+ - copyright notice and this permission notice appear in all copies.
+ - 
+ - THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
+ - REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
+ - AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
+ - INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
+ - LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
+ - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
+ - PERFORMANCE OF THIS SOFTWARE.
+-->
+<!-- $Id: man.rndc-confgen.html,v 1.2.2.55 2007/10/31 01:35:59 marka Exp $ -->
+<html>
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
+<title>rndc-confgen</title>
+<meta name="generator" content="DocBook XSL Stylesheets V1.71.1">
+<link rel="start" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual">
+<link rel="up" href="Bv9ARM.ch10.html" title="Manual pages">
+<link rel="prev" href="man.rndc.conf.html" title="rndc.conf">
+</head>
+<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
+<div class="navheader">
+<table width="100%" summary="Navigation header">
+<tr><th colspan="3" align="center"><span class="application">rndc-confgen</span></th></tr>
+<tr>
+<td width="20%" align="left">
+<a accesskey="p" href="man.rndc.conf.html">Prev</a> </td>
+<th width="60%" align="center">Manual pages</th>
+<td width="20%" align="right"> </td>
+</tr>
+</table>
+<hr>
+</div>
+<div class="refentry" lang="en">
+<a name="man.rndc-confgen"></a><div class="titlepage"></div>
+<div class="refnamediv">
+<h2>Name</h2>
+<p><span class="application">rndc-confgen</span> &#8212; rndc key generation tool</p>
+</div>
+<div class="refsynopsisdiv">
+<h2>Synopsis</h2>
+<div class="cmdsynopsis"><p><code class="command">rndc-confgen</code>  [<code class="option">-a</code>] [<code class="option">-b <em class="replaceable"><code>keysize</code></em></code>] [<code class="option">-c <em class="replaceable"><code>keyfile</code></em></code>] [<code class="option">-h</code>] [<code class="option">-k <em class="replaceable"><code>keyname</code></em></code>] [<code class="option">-p <em class="replaceable"><code>port</code></em></code>] [<code class="option">-r <em class="replaceable"><code>randomfile</code></em></code>] [<code class="option">-s <em class="replaceable"><code>address</code></em></code>] [<code class="option">-t <em class="replaceable"><code>chrootdir</code></em></code>] [<code class="option">-u <em class="replaceable"><code>user</code></em></code>]</p></div>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2605524"></a><h2>DESCRIPTION</h2>
+<p><span><strong class="command">rndc-confgen</strong></span>
+      generates configuration files
+      for <span><strong class="command">rndc</strong></span>.  It can be used as a
+      convenient alternative to writing the
+      <code class="filename">rndc.conf</code> file
+      and the corresponding <span><strong class="command">controls</strong></span>
+      and <span><strong class="command">key</strong></span>
+      statements in <code class="filename">named.conf</code> by hand.
+      Alternatively, it can be run with the <span><strong class="command">-a</strong></span>
+      option to set up a <code class="filename">rndc.key</code> file and
+      avoid the need for a <code class="filename">rndc.conf</code> file
+      and a <span><strong class="command">controls</strong></span> statement altogether.
+    </p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2605590"></a><h2>OPTIONS</h2>
+<div class="variablelist"><dl>
+<dt><span class="term">-a</span></dt>
+<dd>
+<p>
+            Do automatic <span><strong class="command">rndc</strong></span> configuration.
+            This creates a file <code class="filename">rndc.key</code>
+            in <code class="filename">/etc</code> (or whatever
+            <code class="varname">sysconfdir</code>
+            was specified as when <acronym class="acronym">BIND</acronym> was
+            built)
+            that is read by both <span><strong class="command">rndc</strong></span>
+            and <span><strong class="command">named</strong></span> on startup.  The
+            <code class="filename">rndc.key</code> file defines a default
+            command channel and authentication key allowing
+            <span><strong class="command">rndc</strong></span> to communicate with
+            <span><strong class="command">named</strong></span> on the local host
+            with no further configuration.
+          </p>
+<p>
+            Running <span><strong class="command">rndc-confgen -a</strong></span> allows
+            BIND 9 and <span><strong class="command">rndc</strong></span> to be used as
+            drop-in
+            replacements for BIND 8 and <span><strong class="command">ndc</strong></span>,
+            with no changes to the existing BIND 8
+            <code class="filename">named.conf</code> file.
+          </p>
+<p>
+            If a more elaborate configuration than that
+            generated by <span><strong class="command">rndc-confgen -a</strong></span>
+            is required, for example if rndc is to be used remotely,
+            you should run <span><strong class="command">rndc-confgen</strong></span> without
+            the
+            <span><strong class="command">-a</strong></span> option and set up a
+            <code class="filename">rndc.conf</code> and
+            <code class="filename">named.conf</code>
+            as directed.
+          </p>
+</dd>
+<dt><span class="term">-b <em class="replaceable"><code>keysize</code></em></span></dt>
+<dd><p>
+            Specifies the size of the authentication key in bits.
+            Must be between 1 and 512 bits; the default is 128.
+          </p></dd>
+<dt><span class="term">-c <em class="replaceable"><code>keyfile</code></em></span></dt>
+<dd><p>
+            Used with the <span><strong class="command">-a</strong></span> option to specify
+            an alternate location for <code class="filename">rndc.key</code>.
+          </p></dd>
+<dt><span class="term">-h</span></dt>
+<dd><p>
+            Prints a short summary of the options and arguments to
+            <span><strong class="command">rndc-confgen</strong></span>.
+          </p></dd>
+<dt><span class="term">-k <em class="replaceable"><code>keyname</code></em></span></dt>
+<dd><p>
+            Specifies the key name of the rndc authentication key.
+            This must be a valid domain name.
+            The default is <code class="constant">rndc-key</code>.
+          </p></dd>
+<dt><span class="term">-p <em class="replaceable"><code>port</code></em></span></dt>
+<dd><p>
+            Specifies the command channel port where <span><strong class="command">named</strong></span>
+            listens for connections from <span><strong class="command">rndc</strong></span>.
+            The default is 953.
+          </p></dd>
+<dt><span class="term">-r <em class="replaceable"><code>randomfile</code></em></span></dt>
+<dd><p>
+            Specifies a source of random data for generating the
+            authorization.  If the operating
+            system does not provide a <code class="filename">/dev/random</code>
+            or equivalent device, the default source of randomness
+            is keyboard input.  <code class="filename">randomdev</code>
+            specifies
+            the name of a character device or file containing random
+            data to be used instead of the default.  The special value
+            <code class="filename">keyboard</code> indicates that keyboard
+            input should be used.
+          </p></dd>
+<dt><span class="term">-s <em class="replaceable"><code>address</code></em></span></dt>
+<dd><p>
+            Specifies the IP address where <span><strong class="command">named</strong></span>
+            listens for command channel connections from
+            <span><strong class="command">rndc</strong></span>.  The default is the loopback
+            address 127.0.0.1.
+          </p></dd>
+<dt><span class="term">-t <em class="replaceable"><code>chrootdir</code></em></span></dt>
+<dd><p>
+            Used with the <span><strong class="command">-a</strong></span> option to specify
+            a directory where <span><strong class="command">named</strong></span> will run
+            chrooted.  An additional copy of the <code class="filename">rndc.key</code>
+            will be written relative to this directory so that
+            it will be found by the chrooted <span><strong class="command">named</strong></span>.
+          </p></dd>
+<dt><span class="term">-u <em class="replaceable"><code>user</code></em></span></dt>
+<dd><p>
+            Used with the <span><strong class="command">-a</strong></span> option to set the
+            owner
+            of the <code class="filename">rndc.key</code> file generated.
+            If
+            <span><strong class="command">-t</strong></span> is also specified only the file
+            in
+            the chroot area has its owner changed.
+          </p></dd>
+</dl></div>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2606454"></a><h2>EXAMPLES</h2>
+<p>
+      To allow <span><strong class="command">rndc</strong></span> to be used with
+      no manual configuration, run
+    </p>
+<p><strong class="userinput"><code>rndc-confgen -a</code></strong>
+    </p>
+<p>
+      To print a sample <code class="filename">rndc.conf</code> file and
+      corresponding <span><strong class="command">controls</strong></span> and <span><strong class="command">key</strong></span>
+      statements to be manually inserted into <code class="filename">named.conf</code>,
+      run
+    </p>
+<p><strong class="userinput"><code>rndc-confgen</code></strong>
+    </p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2609036"></a><h2>SEE ALSO</h2>
+<p><span class="citerefentry"><span class="refentrytitle">rndc</span>(8)</span>,
+      <span class="citerefentry"><span class="refentrytitle">rndc.conf</span>(5)</span>,
+      <span class="citerefentry"><span class="refentrytitle">named</span>(8)</span>,
+      <em class="citetitle">BIND 9 Administrator Reference Manual</em>.
+    </p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2609075"></a><h2>AUTHOR</h2>
+<p><span class="corpauthor">Internet Systems Consortium</span>
+    </p>
+</div>
+</div>
+<div class="navfooter">
+<hr>
+<table width="100%" summary="Navigation footer">
+<tr>
+<td width="40%" align="left">
+<a accesskey="p" href="man.rndc.conf.html">Prev</a> </td>
+<td width="20%" align="center"><a accesskey="u" href="Bv9ARM.ch10.html">Up</a></td>
+<td width="40%" align="right"> </td>
+</tr>
+<tr>
+<td width="40%" align="left" valign="top">
+<code class="filename">rndc.conf</code> </td>
+<td width="20%" align="center"><a accesskey="h" href="Bv9ARM.html">Home</a></td>
+<td width="40%" align="right" valign="top"> </td>
+</tr>
+</table>
+</div>
+</body>
+</html>
diff --git a/doc/arm/man.rndc.conf.html b/doc/arm/man.rndc.conf.html
new file mode 100644
index 0000000..4e8154c
--- /dev/null
+++ b/doc/arm/man.rndc.conf.html
@@ -0,0 +1,255 @@
+<!--
+ - Copyright (C) 2004-2007 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2000-2003 Internet Software Consortium.
+ - 
+ - Permission to use, copy, modify, and distribute this software for any
+ - purpose with or without fee is hereby granted, provided that the above
+ - copyright notice and this permission notice appear in all copies.
+ - 
+ - THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
+ - REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
+ - AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
+ - INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
+ - LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
+ - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
+ - PERFORMANCE OF THIS SOFTWARE.
+-->
+<!-- $Id: man.rndc.conf.html,v 1.2.2.55 2007/10/31 01:35:59 marka Exp $ -->
+<html>
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
+<title>rndc.conf</title>
+<meta name="generator" content="DocBook XSL Stylesheets V1.71.1">
+<link rel="start" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual">
+<link rel="up" href="Bv9ARM.ch10.html" title="Manual pages">
+<link rel="prev" href="man.rndc.html" title="rndc">
+<link rel="next" href="man.rndc-confgen.html" title="rndc-confgen">
+</head>
+<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
+<div class="navheader">
+<table width="100%" summary="Navigation header">
+<tr><th colspan="3" align="center"><code class="filename">rndc.conf</code></th></tr>
+<tr>
+<td width="20%" align="left">
+<a accesskey="p" href="man.rndc.html">Prev</a> </td>
+<th width="60%" align="center">Manual pages</th>
+<td width="20%" align="right"> <a accesskey="n" href="man.rndc-confgen.html">Next</a>
+</td>
+</tr>
+</table>
+<hr>
+</div>
+<div class="refentry" lang="en">
+<a name="man.rndc.conf"></a><div class="titlepage"></div>
+<div class="refnamediv">
+<h2>Name</h2>
+<p><code class="filename">rndc.conf</code> &#8212; rndc configuration file</p>
+</div>
+<div class="refsynopsisdiv">
+<h2>Synopsis</h2>
+<div class="cmdsynopsis"><p><code class="command">rndc.conf</code> </p></div>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2603676"></a><h2>DESCRIPTION</h2>
+<p><code class="filename">rndc.conf</code> is the configuration file
+      for <span><strong class="command">rndc</strong></span>, the BIND 9 name server control
+      utility.  This file has a similar structure and syntax to
+      <code class="filename">named.conf</code>.  Statements are enclosed
+      in braces and terminated with a semi-colon.  Clauses in
+      the statements are also semi-colon terminated.  The usual
+      comment styles are supported:
+    </p>
+<p>
+      C style: /* */
+    </p>
+<p>
+      C++ style: // to end of line
+    </p>
+<p>
+      Unix style: # to end of line
+    </p>
+<p><code class="filename">rndc.conf</code> is much simpler than
+      <code class="filename">named.conf</code>.  The file uses three
+      statements: an options statement, a server statement
+      and a key statement.
+    </p>
+<p>
+      The <code class="option">options</code> statement contains five clauses.
+      The <code class="option">default-server</code> clause is followed by the
+      name or address of a name server.  This host will be used when
+      no name server is given as an argument to
+      <span><strong class="command">rndc</strong></span>.  The <code class="option">default-key</code>
+      clause is followed by the name of a key which is identified by
+      a <code class="option">key</code> statement.  If no
+      <code class="option">keyid</code> is provided on the rndc command line,
+      and no <code class="option">key</code> clause is found in a matching
+      <code class="option">server</code> statement, this default key will be
+      used to authenticate the server's commands and responses.  The
+      <code class="option">default-port</code> clause is followed by the port
+      to connect to on the remote name server.  If no
+      <code class="option">port</code> option is provided on the rndc command
+      line, and no <code class="option">port</code> clause is found in a
+      matching <code class="option">server</code> statement, this default port
+      will be used to connect.
+      The <code class="option">default-source-address</code> and
+      <code class="option">default-source-address-v6</code> clauses which
+      can be used to set the IPv4 and IPv6 source addresses
+      respectively.
+    </p>
+<p>
+      After the <code class="option">server</code> keyword, the server
+      statement includes a string which is the hostname or address
+      for a name server.  The statement has three possible clauses:
+      <code class="option">key</code>, <code class="option">port</code> and
+      <code class="option">addresses</code>. The key name must match the
+      name of a key statement in the file.  The port number
+      specifies the port to connect to.  If an <code class="option">addresses</code>
+      clause is supplied these addresses will be used instead of
+      the server name.  Each address can take an optional port.
+      If an <code class="option">source-address</code> or <code class="option">source-address-v6</code>
+      of supplied then these will be used to specify the IPv4 and IPv6
+      source addresses respectively.
+    </p>
+<p>
+      The <code class="option">key</code> statement begins with an identifying
+      string, the name of the key.  The statement has two clauses.
+      <code class="option">algorithm</code> identifies the encryption algorithm
+      for <span><strong class="command">rndc</strong></span> to use; currently only HMAC-MD5
+      is
+      supported.  This is followed by a secret clause which contains
+      the base-64 encoding of the algorithm's encryption key.  The
+      base-64 string is enclosed in double quotes.
+    </p>
+<p>
+      There are two common ways to generate the base-64 string for the
+      secret.  The BIND 9 program <span><strong class="command">rndc-confgen</strong></span>
+      can
+      be used to generate a random key, or the
+      <span><strong class="command">mmencode</strong></span> program, also known as
+      <span><strong class="command">mimencode</strong></span>, can be used to generate a
+      base-64
+      string from known input.  <span><strong class="command">mmencode</strong></span> does
+      not
+      ship with BIND 9 but is available on many systems.  See the
+      EXAMPLE section for sample command lines for each.
+    </p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2604121"></a><h2>EXAMPLE</h2>
+<pre class="programlisting">
+      options {
+        default-server  localhost;
+        default-key     samplekey;
+      };
+</pre>
+<p>
+    </p>
+<pre class="programlisting">
+      server localhost {
+        key             samplekey;
+      };
+</pre>
+<p>
+    </p>
+<pre class="programlisting">
+      server testserver {
+        key		testkey;
+        addresses	{ localhost port 5353; };
+      };
+</pre>
+<p>
+    </p>
+<pre class="programlisting">
+      key samplekey {
+        algorithm       hmac-md5;
+        secret          "6FMfj43Osz4lyb24OIe2iGEz9lf1llJO+lz";
+      };
+</pre>
+<p>
+    </p>
+<pre class="programlisting">
+      key testkey {
+        algorithm	hmac-md5;
+        secret		"R3HI8P6BKw9ZwXwN3VZKuQ==";
+      };
+    </pre>
+<p>
+    </p>
+<p>
+      In the above example, <span><strong class="command">rndc</strong></span> will by
+      default use
+      the server at localhost (127.0.0.1) and the key called samplekey.
+      Commands to the localhost server will use the samplekey key, which
+      must also be defined in the server's configuration file with the
+      same name and secret.  The key statement indicates that samplekey
+      uses the HMAC-MD5 algorithm and its secret clause contains the
+      base-64 encoding of the HMAC-MD5 secret enclosed in double quotes.
+    </p>
+<p>
+      If <span><strong class="command">rndc -s testserver</strong></span> is used then <span><strong class="command">rndc</strong></span> will
+      connect to server on localhost port 5353 using the key testkey.
+    </p>
+<p>
+      To generate a random secret with <span><strong class="command">rndc-confgen</strong></span>:
+    </p>
+<p><strong class="userinput"><code>rndc-confgen</code></strong>
+    </p>
+<p>
+      A complete <code class="filename">rndc.conf</code> file, including
+      the
+      randomly generated key, will be written to the standard
+      output.  Commented-out <code class="option">key</code> and
+      <code class="option">controls</code> statements for
+      <code class="filename">named.conf</code> are also printed.
+    </p>
+<p>
+      To generate a base-64 secret with <span><strong class="command">mmencode</strong></span>:
+    </p>
+<p><strong class="userinput"><code>echo "known plaintext for a secret" | mmencode</code></strong>
+    </p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2604994"></a><h2>NAME SERVER CONFIGURATION</h2>
+<p>
+      The name server must be configured to accept rndc connections and
+      to recognize the key specified in the <code class="filename">rndc.conf</code>
+      file, using the controls statement in <code class="filename">named.conf</code>.
+      See the sections on the <code class="option">controls</code> statement in the
+      BIND 9 Administrator Reference Manual for details.
+    </p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2605019"></a><h2>SEE ALSO</h2>
+<p><span class="citerefentry"><span class="refentrytitle">rndc</span>(8)</span>,
+      <span class="citerefentry"><span class="refentrytitle">rndc-confgen</span>(8)</span>,
+      <span class="citerefentry"><span class="refentrytitle">mmencode</span>(1)</span>,
+      <em class="citetitle">BIND 9 Administrator Reference Manual</em>.
+    </p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2605058"></a><h2>AUTHOR</h2>
+<p><span class="corpauthor">Internet Systems Consortium</span>
+    </p>
+</div>
+</div>
+<div class="navfooter">
+<hr>
+<table width="100%" summary="Navigation footer">
+<tr>
+<td width="40%" align="left">
+<a accesskey="p" href="man.rndc.html">Prev</a> </td>
+<td width="20%" align="center"><a accesskey="u" href="Bv9ARM.ch10.html">Up</a></td>
+<td width="40%" align="right"> <a accesskey="n" href="man.rndc-confgen.html">Next</a>
+</td>
+</tr>
+<tr>
+<td width="40%" align="left" valign="top">
+<span class="application">rndc</span> </td>
+<td width="20%" align="center"><a accesskey="h" href="Bv9ARM.html">Home</a></td>
+<td width="40%" align="right" valign="top"> <span class="application">rndc-confgen</span>
+</td>
+</tr>
+</table>
+</div>
+</body>
+</html>
diff --git a/doc/arm/man.rndc.html b/doc/arm/man.rndc.html
new file mode 100644
index 0000000..96ed547
--- /dev/null
+++ b/doc/arm/man.rndc.html
@@ -0,0 +1,202 @@
+<!--
+ - Copyright (C) 2004-2007 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2000-2003 Internet Software Consortium.
+ - 
+ - Permission to use, copy, modify, and distribute this software for any
+ - purpose with or without fee is hereby granted, provided that the above
+ - copyright notice and this permission notice appear in all copies.
+ - 
+ - THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
+ - REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
+ - AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
+ - INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
+ - LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
+ - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
+ - PERFORMANCE OF THIS SOFTWARE.
+-->
+<!-- $Id: man.rndc.html,v 1.2.2.54 2007/10/31 01:35:59 marka Exp $ -->
+<html>
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
+<title>rndc</title>
+<meta name="generator" content="DocBook XSL Stylesheets V1.71.1">
+<link rel="start" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual">
+<link rel="up" href="Bv9ARM.ch10.html" title="Manual pages">
+<link rel="prev" href="man.named.html" title="named">
+<link rel="next" href="man.rndc.conf.html" title="rndc.conf">
+</head>
+<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
+<div class="navheader">
+<table width="100%" summary="Navigation header">
+<tr><th colspan="3" align="center"><span class="application">rndc</span></th></tr>
+<tr>
+<td width="20%" align="left">
+<a accesskey="p" href="man.named.html">Prev</a> </td>
+<th width="60%" align="center">Manual pages</th>
+<td width="20%" align="right"> <a accesskey="n" href="man.rndc.conf.html">Next</a>
+</td>
+</tr>
+</table>
+<hr>
+</div>
+<div class="refentry" lang="en">
+<a name="man.rndc"></a><div class="titlepage"></div>
+<div class="refnamediv">
+<h2>Name</h2>
+<p><span class="application">rndc</span> &#8212; name server control utility</p>
+</div>
+<div class="refsynopsisdiv">
+<h2>Synopsis</h2>
+<div class="cmdsynopsis"><p><code class="command">rndc</code>  [<code class="option">-b <em class="replaceable"><code>source-address</code></em></code>] [<code class="option">-c <em class="replaceable"><code>config-file</code></em></code>] [<code class="option">-k <em class="replaceable"><code>key-file</code></em></code>] [<code class="option">-s <em class="replaceable"><code>server</code></em></code>] [<code class="option">-p <em class="replaceable"><code>port</code></em></code>] [<code class="option">-V</code>] [<code class="option">-y <em class="replaceable"><code>key_id</code></em></code>] {command}</p></div>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2603169"></a><h2>DESCRIPTION</h2>
+<p><span><strong class="command">rndc</strong></span>
+      controls the operation of a name
+      server.  It supersedes the <span><strong class="command">ndc</strong></span> utility
+      that was provided in old BIND releases.  If
+      <span><strong class="command">rndc</strong></span> is invoked with no command line
+      options or arguments, it prints a short summary of the
+      supported commands and the available options and their
+      arguments.
+    </p>
+<p><span><strong class="command">rndc</strong></span>
+      communicates with the name server
+      over a TCP connection, sending commands authenticated with
+      digital signatures.  In the current versions of
+      <span><strong class="command">rndc</strong></span> and <span><strong class="command">named</strong></span>,
+      the only supported authentication algorithm is HMAC-MD5,
+      which uses a shared secret on each end of the connection.
+      This provides TSIG-style authentication for the command
+      request and the name server's response.  All commands sent
+      over the channel must be signed by a key_id known to the
+      server.
+    </p>
+<p><span><strong class="command">rndc</strong></span>
+      reads a configuration file to
+      determine how to contact the name server and decide what
+      algorithm and key it should use.
+    </p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2603219"></a><h2>OPTIONS</h2>
+<div class="variablelist"><dl>
+<dt><span class="term">-b <em class="replaceable"><code>source-address</code></em></span></dt>
+<dd><p>
+            Use <em class="replaceable"><code>source-address</code></em>
+            as the source address for the connection to the server.
+            Multiple instances are permitted to allow setting of both
+            the IPv4 and IPv6 source addresses.
+          </p></dd>
+<dt><span class="term">-c <em class="replaceable"><code>config-file</code></em></span></dt>
+<dd><p>
+            Use <em class="replaceable"><code>config-file</code></em>
+            as the configuration file instead of the default,
+            <code class="filename">/etc/rndc.conf</code>.
+          </p></dd>
+<dt><span class="term">-k <em class="replaceable"><code>key-file</code></em></span></dt>
+<dd><p>
+            Use <em class="replaceable"><code>key-file</code></em>
+            as the key file instead of the default,
+            <code class="filename">/etc/rndc.key</code>.  The key in
+            <code class="filename">/etc/rndc.key</code> will be used to
+            authenticate
+            commands sent to the server if the <em class="replaceable"><code>config-file</code></em>
+            does not exist.
+          </p></dd>
+<dt><span class="term">-s <em class="replaceable"><code>server</code></em></span></dt>
+<dd><p><em class="replaceable"><code>server</code></em> is
+            the name or address of the server which matches a
+            server statement in the configuration file for
+            <span><strong class="command">rndc</strong></span>.  If no server is supplied on the
+            command line, the host named by the default-server clause
+            in the options statement of the <span><strong class="command">rndc</strong></span>
+	    configuration file will be used.
+          </p></dd>
+<dt><span class="term">-p <em class="replaceable"><code>port</code></em></span></dt>
+<dd><p>
+            Send commands to TCP port
+            <em class="replaceable"><code>port</code></em>
+            instead
+            of BIND 9's default control channel port, 953.
+          </p></dd>
+<dt><span class="term">-V</span></dt>
+<dd><p>
+            Enable verbose logging.
+          </p></dd>
+<dt><span class="term">-y <em class="replaceable"><code>key_id</code></em></span></dt>
+<dd><p>
+            Use the key <em class="replaceable"><code>key_id</code></em>
+            from the configuration file.
+            <em class="replaceable"><code>key_id</code></em>
+            must be
+            known by named with the same algorithm and secret string
+            in order for control message validation to succeed.
+            If no <em class="replaceable"><code>key_id</code></em>
+            is specified, <span><strong class="command">rndc</strong></span> will first look
+            for a key clause in the server statement of the server
+            being used, or if no server statement is present for that
+            host, then the default-key clause of the options statement.
+            Note that the configuration file contains shared secrets
+            which are used to send authenticated control commands
+            to name servers.  It should therefore not have general read
+            or write access.
+          </p></dd>
+</dl></div>
+<p>
+      For the complete set of commands supported by <span><strong class="command">rndc</strong></span>,
+      see the BIND 9 Administrator Reference Manual or run
+      <span><strong class="command">rndc</strong></span> without arguments to see its help
+      message.
+    </p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2603512"></a><h2>LIMITATIONS</h2>
+<p><span><strong class="command">rndc</strong></span>
+      does not yet support all the commands of
+      the BIND 8 <span><strong class="command">ndc</strong></span> utility.
+    </p>
+<p>
+      There is currently no way to provide the shared secret for a
+      <code class="option">key_id</code> without using the configuration file.
+    </p>
+<p>
+      Several error messages could be clearer.
+    </p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2603543"></a><h2>SEE ALSO</h2>
+<p><span class="citerefentry"><span class="refentrytitle">rndc.conf</span>(5)</span>,
+      <span class="citerefentry"><span class="refentrytitle">named</span>(8)</span>,
+      <span class="citerefentry"><span class="refentrytitle">named.conf</span>(5)</span>,
+      <span class="citerefentry"><span class="refentrytitle">ndc</span>(8)</span>,
+      <em class="citetitle">BIND 9 Administrator Reference Manual</em>.
+    </p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2603590"></a><h2>AUTHOR</h2>
+<p><span class="corpauthor">Internet Systems Consortium</span>
+    </p>
+</div>
+</div>
+<div class="navfooter">
+<hr>
+<table width="100%" summary="Navigation footer">
+<tr>
+<td width="40%" align="left">
+<a accesskey="p" href="man.named.html">Prev</a> </td>
+<td width="20%" align="center"><a accesskey="u" href="Bv9ARM.ch10.html">Up</a></td>
+<td width="40%" align="right"> <a accesskey="n" href="man.rndc.conf.html">Next</a>
+</td>
+</tr>
+<tr>
+<td width="40%" align="left" valign="top">
+<span class="application">named</span> </td>
+<td width="20%" align="center"><a accesskey="h" href="Bv9ARM.html">Home</a></td>
+<td width="40%" align="right" valign="top"> <code class="filename">rndc.conf</code>
+</td>
+</tr>
+</table>
+</div>
+</body>
+</html>
diff --git a/doc/draft/draft-baba-dnsext-acl-reqts-01.txt b/doc/draft/draft-baba-dnsext-acl-reqts-01.txt
new file mode 100644
index 0000000..1030e57
--- /dev/null
+++ b/doc/draft/draft-baba-dnsext-acl-reqts-01.txt
@@ -0,0 +1,336 @@
+
+
+
+
+Internet-Draft                                                   T. Baba
+Expires: March 11, 2004                                         NTT Data
+                                                      September 11, 2003
+
+
+         Requirements for Access Control in Domain Name Systems
+                   draft-baba-dnsext-acl-reqts-01.txt
+
+Status of this Memo
+
+   This document is an Internet-Draft and is subject to 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 draft documents 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 "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/1id-abstracts.html
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html
+
+   Distribution of this memo is unlimited.
+
+   This Internet-Draft will expire on March 11, 2004.
+
+Abstract
+
+   This document describes the requirements for access control
+   mechanisms in the Domain Name System (DNS), which authenticate
+   clients and then allow or deny access to resource records in the
+   zone according to the access control list (ACL).
+
+1. Introduction
+
+   The Domain Name System (DNS) is a hierarchical, distributed, highly
+   available database used for bi-directional mapping between domain
+   names and IP addresses, for email routing, and for other information
+   [RFC1034, 1035].  DNS security extensions (DNSSEC) have been defined
+   to authenticate the data in DNS and provide key distribution services
+   using SIG, KEY, and NXT resource records (RRs) [RFC2535].
+
+
+
+Baba                     Expires March 11, 2004                 [Page 1]
+
+Internet-Draft       DNS Access Control Requirements      September 2003
+
+
+   At the 28th IETF Meeting in Houston in 1993, DNS security design team
+   started a discussion about DNSSEC and agreed to accept the assumption
+   that "DNS data is public".  Accordingly, confidentiality for queries
+   or responses is not provided by DNSSEC, nor are any sort of access
+   control lists or other means to differentiate inquirers.  However,
+   about ten years has passed, access control in DNS has been more
+   important than before.  Currently, new RRs are proposed to add new
+   functionality to DNS such as ENUM [RFC2916].  Such new RRs may
+   contain private information.  Thus, DNS access control will be
+   needed.
+
+   Furthermore, with DNS access control mechanism, access from
+   unauthorized clients can be blocked when they perform DNS name
+   resolution.  Thus, for example, Denial of Service (DoS) attacks
+   against a server used by a closed user group can be prevented using
+   this mechanism if IP address of the server is not revealed by other
+   sources.
+
+   This document describes the requirements for access control
+   mechanisms in DNS.
+
+2. Terminology
+
+   AC-aware client
+      This is the client that understands the DNS access control
+      extensions. This client may be an end host which has a stub
+      resolver, or a cashing/recursive name server which has a
+      full-service resolver.
+
+   AC-aware server
+      This is the authoritative name server that understands the DNS
+      access control extensions.
+
+   ACE
+      An Access Control Entry.  This is the smallest unit of access
+      control policy.  It grants or denies a given set of access
+      rights to a set of principals.  An ACE is a component of an ACL,
+      which is associated with a resource.
+
+   ACL
+      An Access Control List.  This contains all of the access control
+      policies which are directly associated with a particular
+      resource.  These policies are expressed as ACEs.
+
+   Client
+      A program or host which issues DNS requests and accepts its
+      responses. A client may be an end host or a cashing/recursive name
+      server.
+
+
+
+Baba                     Expires March 11, 2004                 [Page 2]
+
+Internet-Draft       DNS Access Control Requirements      September 2003
+
+
+   RRset
+      All resource records (RRs) having the same NAME, CLASS and TYPE
+      are called a Resource Record Set (RRset).
+
+3. Requirements
+
+   This section describes the requirements for access control in DNS.
+
+3.1 Authentication
+
+3.1.1 Client Authentication Mechanism
+
+   The AC-aware server must identify AC-aware clients based on IP
+   address and/or domain name (user ID or host name), and must
+   authenticate them using strong authentication mechanism such as
+   digital signature or message authentication code (MAC).
+
+   SIG(0) RR [RFC2931] contains a domain name associated with sender's
+   public key in its signer's name field, and TSIG RR [RFC2845] also
+   contains a domain name associated with shared secret key in its key
+   name field.  Each of these domain names can be a host name or a user
+   name, and can be used as a sender's identifier for access control.
+   Furthermore, SIG(0) uses digital signatures, and TSIG uses MACs for
+   message authentication.  These mechanisms can be used to authenticate
+   AC-aware clients.
+
+   Server authentication may be also provided.
+
+3.1.2 End-to-End Authentication
+
+   In current DNS model, caching/recursive name servers are deployed
+   between end hosts and authoritative name servers.  Although
+   authoritative servers can authenticate caching/recursive name servers
+   using SIG(0) or TSIG, they cannot authenticate end hosts behind them.
+   For end-to-end authentication, the mechanism for an end host to
+   discover the target authoritative name server and directly access to
+   it bypassing caching/recursive name servers is needed.  For example,
+   an end host can get the IP addresses of the authoritative name
+   servers by retrieving NS RRs for the zone via local caching/recursive
+   name server.
+
+   In many enterprise networks, however, there are firewalls that block
+   all DNS packets other than those going to/from the particular
+   caching/recursive servers.  To deal with this problem, one can
+   implement packet forwarding function on the caching/recursive servers
+   and enable end-to-end authentication via the caching/recursive
+   servers.
+
+
+
+
+Baba                     Expires March 11, 2004                 [Page 3]
+
+Internet-Draft       DNS Access Control Requirements      September 2003
+
+
+3.1.3 Authentication Key Retrieval
+
+   Keys which are used to authenticate clients should be able to be
+   automatically retrieved.  The KEY RR is used to store a public key
+   for a zone or a host that is associated with a domain name.  SIG(0)
+   RR uses a public key in KEY RR for verifying the signature.  If
+   DNSSEC is available, the KEY RR would be protected by the SIG RR.
+   KEY RR or newly defined RR can be used to automatic key retrieval.
+
+3.2 Confidentiality
+
+3.2.1 Data Encryption
+
+   To avoid disclosure to eavesdroppers, the response containing the
+   RRsets which are restricted to access from particular users should be
+   encrypted.  Currently, no encryption mechanism is specified in DNS.
+   Therefore, new RRs should be defined for DNS message encryption.
+   Instead, IPsec [RFC2401] can be used to provide confidentiality if
+   name server and resolver can set up security associations dynamically
+   using IPsec API [IPSECAPI] when encryption is required.
+
+   In case encryption is applied, entire DNS message including DNS
+   header should be encrypted to hide information including error code.
+
+   Query encryption may be also provided for hiding query information.
+
+3.2.2 Key Exchange
+
+   If DNS message encryption is provided, automatic key exchange
+   mechanism should be also provided.  [RFC2930] specifies a TKEY RR
+   that can be used to establish and delete shared secret keys used by
+   TSIG between a client and a server.  With minor extensions, TKEY can
+   be used to establish shared secret keys used for message encryption.
+
+3.2.3 Caching
+
+   The RRset that is restricted to access from particular users must not
+   be cached.  To avoid caching, the TTL of the RR that is restricted to
+   access should be set to zero during transit.
+
+3.3 Access Control
+
+3.3.1 Granularity of Access Control
+
+   Control of access on a per-user/per-host granularity must be
+   supported.  Control of access to individual RRset (not just the
+   entire zone) must be also supported.  However, SOA, NS, SIG, NXT,
+   KEY, and DS RRs must be publicly accessible to avoid unexpected
+   results.
+   
+
+Baba                     Expires March 11, 2004                 [Page 4]
+
+Internet-Draft       DNS Access Control Requirements      September 2003
+
+
+3.3.2 ACL Representation
+
+   Access Control List (ACL) format must be standardized so that both
+   the primary and secondary AC-aware servers can recognize the same
+   ACL.  Although ACL may appear in or out of zone data, it must be
+   transferred to the secondary AC-aware server with associated zone
+   data.  It is a good idea to contain ACL in zone data, because ACL can
+   be transferred with zone data using existing zone transfer mechanisms
+   automatically.  However, ACL must not be published except for
+   authorized secondary master servers.
+   
+   In zone data master files, ACL should be specified using TXT RRs or
+   newly defined RRs.  In each access control entry (ACE), authorized
+   entities (host or user) must be described using domain name (host
+   name, user name, or IP address in in-addr.arpa/ip6.arpa format).
+   There may be other access control attributes such as access time.
+
+   It must be possible to create publicly readable entries, which may be
+   read even by unauthenticated clients.
+
+3.3.3 Zone/ACL Transfer
+
+   As mentioned above, ACL should be transferred from a primary AC-aware
+   server to a secondary AC-aware server with associated zone data.
+   When an AC-aware server receives a zone/ACL transfer request, the
+   server must authenticate the client, and should encrypt the zone
+   data and associated ACL during transfer.
+
+3.4 Backward/co-existence Compatibility
+
+   Any new protocols to be defined for access control in DNS must be
+   backward compatible with existing DNS protocol.  AC-aware servers
+   must be able to process normal DNS query without authentication, and
+   must respond if retrieving RRset is publicly accessible.
+   
+   Modifications to root/gTLD/ccTLD name servers are not allowed.
+
+4. Security Considerations
+
+   This document discusses the requirements for access control
+   mechanisms in DNS.
+
+5. Acknowledgements
+
+   This work is funded by the Telecommunications Advancement
+   Organization of Japan (TAO).
+
+   The author would like to thank the members of the NTT DATA network
+   security team for their important contribution to this work.
+
+
+Baba                     Expires March 11, 2004                 [Page 5]
+
+Internet-Draft       DNS Access Control Requirements      September 2003
+
+
+6. References
+
+   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
+              STD 13, RFC 1034, November 1987.
+
+   [RFC1035]  Mockapetris, P., "Domain names - implementation and
+              specification", STD 13, RFC 1035, November 1987.
+
+   [RFC2401]  Kent, S. and R. Atkinson, "Security Architecture for the
+              Internet Protocol", RFC 2401, November 1998.
+
+   [RFC2535]  Eastlake, D., "Domain Name System Security Extensions",
+              RFC 2535, March 1999.
+
+   [RFC2845]  Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington,
+              "Secret Key Transaction Authentication for DNS (TSIG)", 
+              RFC 2845, May 2000.
+
+   [RFC2916]  Faltstrom, P., "E.164 number and DNS", RFC 2916,
+              September 2000.
+
+   [RFC2930]  Eastlake, D., "Secret Key Establishment for DNS (TKEY RR)",
+              RFC 2930, September 2000.
+
+   [RFC2931]  Eastlake, D., "DNS Request and Transaction Signatures
+              (SIG(0)s)", RFC 2931, September 2000.
+
+   [IPSECAPI] Sommerfeld, W., "Requirements for an IPsec API",
+              draft-ietf-ipsp-ipsec-apireq-00.txt, June 2003, Work in
+              Progress.
+
+
+Author's Address
+
+   Tatsuya Baba
+   NTT Data Corporation
+   Research and Development Headquarters
+   Kayabacho Tower, 1-21-2, Shinkawa, Chuo-ku,
+   Tokyo 104-0033, Japan
+   
+   Tel: +81 3 3523 8081
+   Fax: +81 3 3523 8090
+   Email: babatt@nttdata.co.jp
+
+
+
+
+
+
+
+
+Baba                     Expires March 11, 2004                 [Page 6]
diff --git a/doc/draft/draft-daigle-napstr-04.txt b/doc/draft/draft-daigle-napstr-04.txt
new file mode 100644
index 0000000..fffa8a5
--- /dev/null
+++ b/doc/draft/draft-daigle-napstr-04.txt
@@ -0,0 +1,1232 @@
+
+
+Network Working Group                                          L. Daigle
+Internet-Draft                                                 A. Newton
+Expires: August 15, 2004                                  VeriSign, Inc.
+                                                       February 15, 2004
+
+
+    Domain-based Application Service Location Using SRV RRs and the
+              Dynamic Delegation Discovery Service (DDDS)
+                       draft-daigle-napstr-04.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 draft documents 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 "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/ietf/1id-abstracts.txt.
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+   This Internet-Draft will expire on August 15, 2004.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2004).  All Rights Reserved.
+
+Abstract
+
+   This memo defines a generalized mechanism for application service
+   naming that allows service location without relying on rigid domain
+   naming conventions (so-called name hacks).  The proposal defines a
+   Dynamic Delegation Discovery System (DDDS) Application to map domain
+   name, application service name, and application protocol to target
+   server and port, dynamically.
+
+
+
+
+
+
+
+Daigle & Newton          Expires August 15, 2004                [Page 1]
+
+Internet-Draft           draft-daigle-napstr-04            February 2004
+
+
+Table of Contents
+
+   1.    Introduction . . . . . . . . . . . . . . . . . . . . . . . .  4
+   2.    Straightforward-NAPTR (S-NAPTR) Specification  . . . . . . .  4
+   2.1   Key Terms  . . . . . . . . . . . . . . . . . . . . . . . . .  4
+   2.2   S-NAPTR DDDS Application Usage . . . . . . . . . . . . . . .  5
+   2.2.1 Ordering and Preference  . . . . . . . . . . . . . . . . . .  5
+   2.2.2 Matching and non-Matching NAPTR Records  . . . . . . . . . .  5
+   2.2.3 Terminal and Non-Terminal NAPTR Records  . . . . . . . . . .  5
+   2.2.4 S-NAPTR and Successive Resolution  . . . . . . . . . . . . .  6
+   2.2.5 Clients Supporting Multiple Protocols  . . . . . . . . . . .  6
+   3.    Guidelines . . . . . . . . . . . . . . . . . . . . . . . . .  7
+   3.1   Guidelines for Application Protocol Developers . . . . . . .  7
+   3.1.1 Registration of application service and protocol tags  . . .  7
+   3.1.2 Definition of conditions for retry/failure . . . . . . . . .  8
+   3.1.3 Server identification and handshake  . . . . . . . . . . . .  8
+   3.2   Guidelines for Domain Administrators . . . . . . . . . . . .  8
+   3.3   Guidelines for Client Software Writers . . . . . . . . . . .  9
+   4.    Illustrations  . . . . . . . . . . . . . . . . . . . . . . .  9
+   4.1   Use Cases  . . . . . . . . . . . . . . . . . . . . . . . . .  9
+   4.2   Service Discovery within a Domain  . . . . . . . . . . . . . 10
+   4.3   Multiple Protocols . . . . . . . . . . . . . . . . . . . . . 10
+   4.4   Remote Hosting . . . . . . . . . . . . . . . . . . . . . . . 11
+   4.5   Sets of NAPTR RRs  . . . . . . . . . . . . . . . . . . . . . 12
+   4.6   Sample sequence diagram  . . . . . . . . . . . . . . . . . . 12
+   5.    Motivation and Discussion  . . . . . . . . . . . . . . . . . 14
+   5.1   So, why not just SRV records?  . . . . . . . . . . . . . . . 15
+   5.2   So, why not just NAPTR records?  . . . . . . . . . . . . . . 15
+   6.    IANA Considerations  . . . . . . . . . . . . . . . . . . . . 16
+   7.    Security Considerations  . . . . . . . . . . . . . . . . . . 16
+   8.    Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
+         References . . . . . . . . . . . . . . . . . . . . . . . . . 17
+         Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 18
+   A.    Application Service Location Application of DDDS . . . . . . 18
+   A.1   Application Unique String  . . . . . . . . . . . . . . . . . 18
+   A.2   First Well Known Rule  . . . . . . . . . . . . . . . . . . . 18
+   A.3   Expected Output  . . . . . . . . . . . . . . . . . . . . . . 18
+   A.4   Flags  . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
+   A.5   Service Parameters . . . . . . . . . . . . . . . . . . . . . 19
+   A.5.1 Application Services . . . . . . . . . . . . . . . . . . . . 19
+   A.5.2 Application Protocols  . . . . . . . . . . . . . . . . . . . 20
+   A.6   Valid Rules  . . . . . . . . . . . . . . . . . . . . . . . . 20
+   A.7   Valid Databases  . . . . . . . . . . . . . . . . . . . . . . 20
+   B.    Pseudo pseudocode for S-NAPTR  . . . . . . . . . . . . . . . 20
+   B.1   Finding the first (best) target  . . . . . . . . . . . . . . 20
+   B.2   Finding subsequent targets . . . . . . . . . . . . . . . . . 21
+         Full Copyright Statement . . . . . . . . . . . . . . . . . . 23
+
+
+
+
+Daigle & Newton          Expires August 15, 2004                [Page 2]
+
+Internet-Draft           draft-daigle-napstr-04            February 2004
+
+
+1. Introduction
+
+   This memo defines a generalized mechanism for application service
+   naming that allows service location without relying on rigid domain
+   naming conventions (so-called name hacks).  The proposal defines a
+   Dynamic Delegation Discovery System (DDDS -- see [6]) Application to
+   map domain name, application service name, and application protocol
+   to target server and port, dynamically.
+
+   As discussed in Section 5, existing approaches to using DNS records
+   to dynamically determining the current host for a given application
+   service are limited in terms of the use cases supported.  To address
+   some of the limitations, this document defines a DDDS Application to
+   map service+protocol+domain to specific server addresses using both
+   NAPTR [7] and SRV ([5]) DNS resource records.  This can be viewed as
+   a more general version of the use of SRV and/or a very restricted
+   application of the use of NAPTR resource records.
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC2119 ([2]).
+
+2. Straightforward-NAPTR (S-NAPTR) Specification
+
+   The precise details of the specification of this DDDS application are
+   given in Appendix A.  This section defines the usage of the DDDS
+   application.
+
+2.1 Key Terms
+
+   An "application service" is a generic term for some type of
+   application, indpendent of the protocol that may be used to offer it.
+   Each application service will be associated with an IANA-registered
+   tag.  For example, instant messaging is a type of application
+   service, which can be implemented by many different application-layer
+   protocols, and the tag "IM" (used as an illustration here) could be
+   registered for it.
+
+   An "application protocol" is used to implement the application
+   service.  These are also associated with IANA-registered tags.  In
+   the case where multiple transports are available for the application,
+   separate tags should be defined for each transport.
+
+   The intention is that the combination of application service and
+   protocol tags should be specific enough that finding a known pair
+   (e.g., "IM:ProtC") is sufficient for a client to identify a server
+   with which it can communicate.
+
+
+
+
+Daigle & Newton          Expires August 15, 2004                [Page 3]
+
+Internet-Draft           draft-daigle-napstr-04            February 2004
+
+
+   Some protocols support multiple application services.  For example,
+   LDAP is an application protocol, and can be found supporting various
+   services (e.g., "whitepages", "directory enabled networking", etc).
+
+2.2 S-NAPTR DDDS Application Usage
+
+   As outlined in Appendix A, NAPTR records are used to store
+   application service+protocol information for a given domain.
+   Following the DDDS standard, these records are looked up,  and the
+   rewrite rules (contained in the NAPTR records) are used to determine
+   the successive DNS lookups, until a desirable target is found.
+
+   For the rest of this section, refer to the set of NAPTR resource
+   records for example.com shown in the figure below.
+
+   example.com.
+   ;;       order pref flags service     regexp replacement
+   IN NAPTR 100   10   ""    "WP:whois++" ""    bunyip.example.
+   IN NAPTR 100   20   "s"   "WP:ldap"    ""    _ldap._tcp.myldap.example.com.
+   IN NAPTR 200   10   ""    "IM:protA"   ""    someisp.example.
+   IN NAPTR 200   30   "a"   "IM:protB"   ""    myprotB.example.com.
+
+
+2.2.1 Ordering and Preference
+
+   A client retrieves all of the NAPTR records associated with the
+   target domain name (example.com, above).  These are to be sorted in
+   terms of increasing ORDER, and increasing PREF within each ORDER.
+
+2.2.2 Matching and non-Matching NAPTR Records
+
+   Starting with the first sorted NAPTR record, the client examines the
+   SERVICE field to find a match.  In the case of the S-NAPTR DDDS
+   application, that means a SERVICE field that includes the tags for
+   the desired application service and a supported application protocol.
+
+   If more than one NAPTR record matches, they are processed in
+   increasing sort order.
+
+2.2.3 Terminal and Non-Terminal NAPTR Records
+
+   A NAPTR record with an empty FLAG field is "non-terminal".  That is,
+   more NAPTR RR lookups are to be performed.  Thus, to process a NAPTR
+   record with an empty FLAG field in S-NAPTR, the REPLACEMENT field is
+   used as the target of the next DNS lookup -- for NAPTR RRs.
+
+   In S-NAPTR, the only terminal flags are "S" and "A".  These are
+   called "terminal" NAPTR lookups because they denote the end of the
+
+
+
+Daigle & Newton          Expires August 15, 2004                [Page 4]
+
+Internet-Draft           draft-daigle-napstr-04            February 2004
+
+
+   DDDS/NAPTR processing rules.  In the case of an "S" flag, the
+   REPLACEMENT field is used as the target of a DNS query for SRV RRs,
+   and normal SRV processing is applied.  In the case of an "A" flag, an
+   address record is sought for the REPLACEMENT field target (and the
+   default protocol port is assumed).
+
+2.2.4 S-NAPTR and Successive Resolution
+
+   As shown in the example NAPTR RR set above, it is possible to have
+   multiple possible targets for a single application service+protocol
+   pair.  These are to be pursued in order until a server is
+   successfully contacted or all possible matching NAPTR records have
+   been successively pursued to terminal lookups and servers contacted.
+   That is, a client must backtrack and attempt other resolution paths
+   in the case of failure.
+
+   "Failure" is declared, and backtracking must be used when
+
+   o  the designated remote server (host and port) fail to provide
+      appropriate security credentials for the *originating* domain
+
+   o  connection to the designated remote server otherwise fails -- the
+      specifics terms of which are defined when an application protocol
+      is registered
+
+   o  the S-NAPTR-designated DNS lookup fails to yield expected results
+      -- e.g., no A RR for an "A" target, no SRV record for an "S"
+      target, or no NAPTR record with appropriate application service
+      and protocol for a NAPTR lookup.  Except in the case of the very
+      first NAPTR lookup, this last is a configuration error:  the fact
+      that example.com has a NAPTR record pointing to "bunyip.example"
+      for the "WP:Whois++" service and protocol means the administrator
+      of example.com believes that service exists.  If bunyip.example
+      has no "WP:Whois++" NAPTR record, the application client MUST
+      backtrack and try the next available "WP:Whois++" option from
+      example.com.  As there is none, the whole resolution fails.
+
+   An application client first queries for the NAPTR RRs for the domain
+   of a named application service.  The application client MUST select
+   one protocol to choose The PREF field of the NAPTR RRs may be used by
+   the domain administrator to The first DNS query is for the NAPTR RRs
+   in the original target domain (example.com, above).
+
+2.2.5 Clients Supporting Multiple Protocols
+
+   In the case of an application client that supports more than one
+   protocol for a given application service, it MUST pursue S-NAPTR
+   resolution completely for one protocol before trying another.j It MAY
+
+
+
+Daigle & Newton          Expires August 15, 2004                [Page 5]
+
+Internet-Draft           draft-daigle-napstr-04            February 2004
+
+
+   choose which protocol to try first based on its own preference, or
+   from the PREF ranking in the first set of NAPTR records (i.e., those
+   for the target named domain).    However, the chosen protocol MUST be
+   listed in that first NAPTR RR set.
+
+   That is, what the client MUST NOT do is start looking for one
+   protocol, observe that a successive NAPTR RR set supports another of
+   its preferred protocols, and continue the S-NAPTR resolution based on
+   that protocol.  For example, even if someisp.example offers the "IM"
+   service with protocol "ProtB", there is no reason to believe it does
+   so on behalf of example.com (since there is no such pointer in
+   example.com's NAPTR RR set).
+
+3. Guidelines
+
+3.1 Guidelines for Application Protocol Developers
+
+   The purpose of S-NAPTR is to provide application standards developers
+   with a more powerful framework (than SRV RRs alone) for naming
+   service targets, without requiring each application protocol (or
+   service) standard to define a separate DDDS application.
+
+   Note that this approach is intended specifically for use when it
+   makes sense to associate services with particular domain names (e.g.,
+   e-mail addresses, SIP addresses, etc).  A non-goal is having all
+   manner of label mapped into domain names in order to use this.
+
+   Specifically not addressed in this document is how to select the
+   domain for which the service+protocol is being sought.  It is up to
+   other conventions to define how that might be used (e.g., instant
+   messaging standards can define what domain to use from IM URIs, how
+   to step down from foobar.example.com to example.com, and so on, if
+   that is applicable).
+
+   Although this document proposes a DDDS application that does not use
+   all the features of NAPTR resource records, it does not mean to imply
+   that DNS resolvers should fail to implement all aspects of the NAPTR
+   RR standard.  A DDDS application is a client use convention.
+
+   The rest of this section outlines the specific elements that protocol
+   developers must determine and document in order to make use of S-
+   NAPTR.
+
+3.1.1 Registration of application service and protocol tags
+
+   Application protocol developers that wish to make use of S-NAPTR must
+   make provision to register any relevant application service and
+   application protocol tags, as described in Section 6.
+
+
+
+Daigle & Newton          Expires August 15, 2004                [Page 6]
+
+Internet-Draft           draft-daigle-napstr-04            February 2004
+
+
+3.1.2 Definition of conditions for retry/failure
+
+   One other important aspect that must be defined is the expected
+   behaviour for interacting with the servers that are reached via S-
+   NAPTR.  Specifically,  under what circumstances should the client
+   retry a target that was found via S-NAPTR?  What should it consider a
+   failure that causes it to return to the S-NAPTR process to determine
+   the next serviceable target (a less preferred target)?
+
+   For example, if the client gets a "connection refused" from a server,
+   should it retry for some (protocol-dependent) period of time?  Or,
+   should it try the next-preferred target in the S-NAPTR chain of
+   resolution?  Should it only try the next-preferred target if it
+   receives a protocol-specific permanent error message?
+
+   The most important thing is to select one expected behaviour and
+   document it as part of the use of S-NAPTR.
+
+   As noted earlier, failure to provide appropriate credentials to
+   identify the server as being authoritative for the original taret
+   domain is always considered a failure condition.
+
+3.1.3 Server identification and handshake
+
+   As noted in Section 7, use of the DNS for server location increases
+   the importance of using protocol-specific handshakes to determine and
+   confirm the identity of the server that is eventually reached.
+
+   Therefore, application protocol developers using S-NAPTR should
+   identify the mechanics of the expected identification handshake when
+   the client connects to a server found through S-NAPTR.
+
+3.2 Guidelines for Domain Administrators
+
+   Although S-NAPTR aims to provide a "straightforward" application of
+   DDDS and use of NAPTR records, it is still possible to create very
+   complex chains and dependencies with the NAPTR and SRV records.
+
+   Therefore, domain administrators are called upon to use S-NAPTR with
+   as much restraint as possible, while still achieving their service
+   design goals.
+
+   The complete set of NAPTR, SRV and A RRs that are "reachable" through
+   the S-NAPTR process for a particular application service can be
+   thought of as a "tree".  Each NAPTR RR retrieved points to more NAPTR
+   or SRV records; each SRV record points to several A record lookups.
+   Even though a particular client can "prune" the tree to use only
+   those records referring to application protocols supported by the
+
+
+
+Daigle & Newton          Expires August 15, 2004                [Page 7]
+
+Internet-Draft           draft-daigle-napstr-04            February 2004
+
+
+   client, the tree could be quite deep, and retracing the tree to retry
+   other targets can become expensive if the tree has many branches.
+
+   Therefore,
+
+   o  Fewer branches is better:  for both NAPTR and SRV records, provide
+      different targets with varying preferences where appropriate
+      (e.g., to provide backup services, etc), but don't look for
+      reasons to provide more.
+
+   o  Shallower is better:  avoid using NAPTR records to "rename"
+      services within a zone.  Use NAPTR records to identify services
+      hosted elsewhere (i.e., where you cannot reasonably provide the
+      SRV records in your own zone).
+
+
+3.3 Guidelines for Client Software Writers
+
+   To properly understand DDDS/NAPTR, an implementor must read [6].
+   However, the most important aspect to keep in mind is that, if one
+   target fails to work for the application, it is expected that the
+   application will continue through the S-NAPTR tree to try the (less
+   preferred) alternatives.
+
+4. Illustrations
+
+4.1 Use Cases
+
+   The basic intended use cases for which S-NAPTR has been developed
+   are:
+
+   o  Service discovery within a domain.  For example, this can be used
+      to find the "authoritative" server for some type of service within
+      a domain (see the specific example in Section 4.2).
+
+   o  Multiple protocols.  This is increasingly common as new
+      application services are defined.  This includes the case of
+      instant messaging (a service) which can be offered with multiple
+      protocols (see Section 4.3).
+
+   o  Remote hosting.  Each of the above use cases applies within the
+      administration of a single domain.  However, one domain operator
+      may elect to engage another organization to provide an application
+      service.  See Section 4.4 for an example that cannot be served by
+      SRV records alone.
+
+
+
+
+
+
+Daigle & Newton          Expires August 15, 2004                [Page 8]
+
+Internet-Draft           draft-daigle-napstr-04            February 2004
+
+
+4.2 Service Discovery within a Domain
+
+   There are occasions when it is useful to be able to determine the
+   "authoritative" server for a given application service within a
+   domain.  This is "discovery", because there is no a priori knowledge
+   as to whether or where the service is offered; it is therefore
+   important to determine the location and characteristics of the
+   offered service.
+
+   For example, there is growing discussion of having a generic
+   mechanism for locating the keys or certificates associated with
+   particular application (servers) operated in (or for) a particular
+   domain.  Here's a hypothetical case for storing application key or
+   certificate data for a given domain.  The premise is that some
+   credentials registry (CredReg) service has been defined to be a leaf
+   node service holding the keys/certs for the servers operated by (or
+   for) the domain.  Furthermore, it is assumed that more than one
+   protocol is available to provide the service for a particular domain.
+   This DDDS-based approach is used to find the CredReg server that
+   holds the information.
+
+   Thus, the set of NAPTR records for thinkingcat.example might look
+   like this:
+
+   thinkingcat.example.
+   ;;       order pref flags service                 regexp  replacement
+   IN NAPTR 100   10   ""    "CREDREG:ldap:iris-beep" ""     theserver.thinkingcat.example.
+
+   Note that another domain, offering the same application service,
+   might offer it using a different set of application protocols:
+
+   anotherdomain.example.
+   ;;       order pref flags service                    regexp replacement
+   IN NAPTR 100   10   ""    "CREDREG:iris-lw:iris-beep" ""    foo.anotherdomain.example.
+
+
+4.3 Multiple Protocols
+
+   As it stands, there are several different protocols proposed for
+   offering "instant message" services.  Assuming that "IM" was
+   registered as an application service, this DDDS application could be
+   used to determine the available services for delivering to a target.
+
+   Two particular features of instant messaging should be noted:
+
+   1.  gatewaying is expected to bridge communications across protocols
+
+   2.  instant messaging servers are likely to be operated out of a
+
+
+
+Daigle & Newton          Expires August 15, 2004                [Page 9]
+
+Internet-Draft           draft-daigle-napstr-04            February 2004
+
+
+       different domain than the instant messaging address, and servers
+       of different protocols may be offered by independent
+       organizations
+
+   For example, "thinkingcat.example" may support its own servers for
+   the "ProtA" instant messaging protocol, but rely on outsourcing from
+   "example.com" for "ProtC" and "ProtB" servers.
+
+   Using this DDDS-based approach, thinkingcat.example can indicate a
+   preference ranking for the different types of servers for the instant
+   messaging service, and yet the out-sourcer can independently rank the
+   preference and ordering of servers.  This independence is not
+   achievable through the use of SRV records alone.
+
+   Thus, to find the IM services for thinkingcat.example, the NAPTR
+   records for thinkingcat.example are retrieved:
+
+   thinkingcat.example.
+   ;;	order pref flags service   regexp replacement
+   IN NAPTR 100  10   "s"   "IM:ProtA" ""    _ProtA._tcp.thinkingcat.example.
+   IN NAPTR 100  20   "s"   "IM:ProtB" ""    _ProtB._tcp.example.com.
+   IN NAPTR 100  30   "s"   "IM:ProtC" ""    _ProtC._tcp.example.com.
+
+   and then the administrators at example.com can manage the preference
+   rankings of the servers they use to support the ProtB service:
+
+   _ProtB._tcp.example.com.
+    ;;    Pref Weight Port  Target
+   IN SRV 10    0     10001 bigiron.example.com
+   IN SRV 20    0     10001 backup.im.example.com
+   IN SRV 30    0     10001 nuclearfallout.australia-isp.example
+
+
+4.4 Remote Hosting
+
+   In the Instant Message hosting example in Section 4.3, the service
+   owner (thinkingcat.example) had to host pointers to the hosting
+   service's SRV records in the thinkingcat.example domain.
+
+   A better way to approach this is to have one NAPTR RR in the
+   thinkingcat.example domain pointing to all the hosted services, and
+   the hosting domain has NAPTR records for each service to map them to
+   whatever local hosts it chooses (and may change from time to time).
+
+
+
+
+
+
+
+
+Daigle & Newton          Expires August 15, 2004               [Page 10]
+
+Internet-Draft           draft-daigle-napstr-04            February 2004
+
+
+   thinkingcat.example.
+   ;;      order pref flags service         regexp replacement
+   IN NAPTR 100  10   "s"   "IM:ProtA"       ""    _ProtA._tcp.thinkingcat.example.
+   IN NAPTR 100  20   ""    "IM:ProtB:ProtC" ""    thinkingcat.example.com.
+
+
+   and then the administrators at example.com can break out the
+   individual application protocols and manage the preference rankings
+   of the servers they use to support the ProtB service (as before):
+
+   thinkingcat.example.com.
+   ;;      order pref flags service   regexp  replacement
+   IN NAPTR 100  10   "s"   "IM:ProtC" ""     _ProtC._tcp.example.com.
+   IN NAPTR 100  20   "s"   "IM:ProtB" ""     _ProtB._tcp.example.com.
+
+
+
+   _ProtC._tcp.example.com.
+    ;;    Pref Weight Port  Target
+   IN SRV 10    0     10001 bigiron.example.com
+   IN SRV 20    0     10001 backup.im.example.com
+   IN SRV 30    0     10001 nuclearfallout.australia-isp.example
+
+
+4.5 Sets of NAPTR RRs
+
+   Note that the above sections assumed that there was one service
+   available (via S-NAPTR) per domain.  Often, that will not be the
+   case.  Assuming thinkingcat.example had the CredReg service set up as
+   described in Section 4.2 and the instant messaging service set up as
+   described in Section 4.4, then a client querying for the NAPTR RR set
+   from thinkingcat.com would get the following answer:
+
+   thinkingcat.example.
+   ;;       order pref flags service          regexp  replacement
+   IN NAPTR 100   10   "s"   "IM:ProtA"        ""     _ProtA._tcp.thinkingcat.example.
+   IN NAPTR 100   20   ""    "IM:ProtB:ProtC:" ""     thinkingcat.example.com.
+   IN NAPTR 200   10   ""    "CREDREG:ldap:iris-beep" "" bouncer.thinkingcat.example.
+
+   Sorting them by increasing "ORDER", the client would look through the
+   SERVICE strings to determine if there was a NAPTR RR that matched the
+   application service it was looking for, with an application protocol
+   it could use.  The first (lowest PREF) record that so matched is the
+   one the client would use to continue.
+
+4.6 Sample sequence diagram
+
+   Consider the example in Section 4.3.  Visually, the sequence of steps
+
+
+
+Daigle & Newton          Expires August 15, 2004               [Page 11]
+
+Internet-Draft           draft-daigle-napstr-04            February 2004
+
+
+   required for the client to reach the final server for a "ProtB"
+   service for IM for the thinkingcat.example domain is as follows:
+
+
+   Client   NS for                NS for
+            thinkingcat.example   example.com    backup.im.example.com
+                |                     |                  |
+     1 -------->|                     |                  |
+     2 <--------|                     |                  |
+     3 ------------------------------>|                  |
+     4 <------------------------------|                  |
+     5 ------------------------------>|                  |
+     6 <------------------------------|                  |
+     7 ------------------------------>|                  |
+     8 <------------------------------|                  |
+     9 ------------------------------------------------->|
+    10 <-------------------------------------------------|
+    11 ------------------------------------------------->|
+    12 <-------------------------------------------------|
+   (...)
+
+
+
+   1.  the name server (NS) for thinkingcat.example is reached with a
+        request for all NAPTR records
+
+   2.  the server responds with the NAPTR records shown in Section 4.3.
+
+   3.  the second NAPTR record matches the desired criteria; that has an
+        "s" flag and a replacement fields of "_ProtB._tcp.example.com".
+        So, the client looks up SRV records for that target, ultimately
+        making the request of the NS for example.com.
+
+   4.  the response includes the SRV records listed in Section 4.3.
+
+   5.  the client attempts to reach the server with the lowest PREF in
+        the SRV list -- looking up the A record for the SRV record's
+        target (bigiron.example.com).
+
+   6.  the example.com NS responds with an error message -- no such
+        machine!
+
+   7.  the client attempts to reach the second server in the SRV list,
+        and looks up the A record for backup.im.example.com
+
+   8.  the client gets the A record with the IP address for
+        backup.im.example.com from example.com's NS.
+
+
+
+
+Daigle & Newton          Expires August 15, 2004               [Page 12]
+
+Internet-Draft           draft-daigle-napstr-04            February 2004
+
+
+   9.  the client connects to that IP address, on port 10001 (from the
+        SRV record), using ProtB over tcp.
+
+   10.  the server responds with an "OK" message.
+
+   11.  the client uses ProtB to challenge that this server has
+        credentials to operate the service for the original domain
+        (thinkingcat.example)
+
+   12.  the server responds, and the rest is IM.
+
+
+5. Motivation and Discussion
+
+   Increasingly, application protocol standards are using domain names
+   to identify server targets, and stipulating that clients should look
+   up SRV resource records to determine the host and port providing the
+   server.  This enables a distinction between naming an application
+   service target and actually hosting the server.  It also increases
+   flexibility in hosting the target service:
+
+   o  the server may be operated by a completely different organization
+      without having to list the details of that organization's DNS
+      setup (SRVs)
+
+   o  multiple instances can be set up (e.g., for load balancing or
+      secondaries)
+
+   o  it can be moved from time to time without disrupting clients'
+      access, etc.
+
+   This is quite useful, but Section 5.1 outlines some of the
+   limitations inherent in the approach.
+
+   That is, while SRV records can be used to map from a specific service
+   name and protocol for a specific domain to a specific server, SRV
+   records are limited to one layer of indirection, and are focused on
+   server administration rather than on application naming.  And, while
+   the DDDS specification and use of NAPTR allows multiple levels of
+   redirection before locating the target server machine with an SRV
+   record, this proposal requires only a subset of NAPTR strictly bound
+   to domain names, without making use of the REGEXP field of NAPTR.
+   These restrictions make the client's resolution process much more
+   predictable and efficient than with some potential uses of NAPTR
+   records.  This is dubbed "S-NAPTR" -- a "S"traightforward use of
+   NAPTR records.
+
+
+
+
+
+Daigle & Newton          Expires August 15, 2004               [Page 13]
+
+Internet-Draft           draft-daigle-napstr-04            February 2004
+
+
+5.1 So, why not just SRV records?
+
+   An expected question at this point is: this is so similar in
+   structure to SRV records, why are we doing this with DDDS/NAPTR?
+
+   Limitations of SRV include:
+
+   o  SRV provides a single layer of indirection -- the outcome of an
+      SRV lookup is a new domain name for which the A RR is to be found.
+
+   o  the purpose of SRV is focused on individual server administration,
+      not application naming: as stated in [5] "The SRV RR allows
+      administrators to use several servers for a single domain, to move
+      services from host to host with little fuss, and to designate some
+      hosts as primary servers for a service and others as backups."
+
+   o  target servers by "service" (e.g., "ldap") and "protocol" (e.g.,
+      "tcp") in a given domain.  The definition of these terms implies
+      specific things (e.g., that protocol should be one of UDP or TCP)
+      without being precise.  Restriction to UDP and TCP is insufficient
+      for the uses described here.
+
+   The basic answer is that SRV records provide mappings from protocol
+   names to host and port.  The use cases described herein require an
+   additional layer -- from some service label to servers that may in
+   fact be hosted within different administrative domains.  We could
+   tweak SRV to say that the next lookup could be something other than
+   an address record, but that is more complex than is necessary for
+   most applications of SRV.
+
+5.2 So, why not just NAPTR records?
+
+   That's a trick question.  NAPTR records cannot appear in the wild --
+   see [6].  They must be part of a DDDS application.
+
+   The purpose here is to define a single, common mechanism (the DDDS
+   application) to use NAPTR when all that is desired is simple DNS-
+   based location of services.  This should be easy for applications to
+   use -- some simple IANA registrations and it's done.
+
+   Also, NAPTR has very powerful tools for expressing "rewrite" rules.
+   That power (==complexity) makes some protocol designers and service
+   administrators nervous.  The concern is that it can translate into
+   unintelligible, noodle-like rule sets that are difficult to test and
+   administer.
+
+   This proposed DDDS application specifically uses a subset of NAPTR's
+   abilities.  Only "replacement" expressions are allowed, not "regular
+
+
+
+Daigle & Newton          Expires August 15, 2004               [Page 14]
+
+Internet-Draft           draft-daigle-napstr-04            February 2004
+
+
+   expressions".
+
+6. IANA Considerations
+
+   This document calls for 2 IANA registries:  one for application
+   service tags, and one for application protocol tags.
+
+   Application service and protocol tags should be defined in an RFC
+   (unless the "x-" experimental form is used, in which case they are
+   unregistered).  There are no restrictions placed on the tags other
+   than that they must conform with the syntax defined below (Appendix
+   A.5).  The IANA registries should list the tags and the RFC that
+   defines their use.
+
+7. Security Considerations
+
+   The security of this approach to application service location is only
+   as good as the security of the DNS servers along the way.  If any of
+   them is compromised, bogus NAPTR and SRV records could be inserted to
+   redirect clients to unintended destinations.  This problem is hardly
+   unique to S-NAPTR (or NAPTR in general).
+
+   To protect against DNS-vectored attacks, applications should define
+   some form of end-to-end authentication to ensure that the correct
+   destination has been reached.  Many application protocols such as
+   HTTPS, BEEP, IMAP, etc...  define the necessary handshake mechansims
+   to accomplish this task.
+
+   The basic mechanism works in the following way:
+
+   1.  During some portion of the protocol handshake, the client sends
+       to the server the original name of the desired destination (i.e.
+       no transformations that may have resulted from NAPTR
+       replacements, SRV targets, or CNAME changes).  In certain cases
+       where the application protocol does not have such a feature but
+       TLS may be used, it is possible to use the "server_name" TLS
+       extension.
+
+   2.  The server sends back to the client a credential with the
+       appropriate name.  For X.509 certificates, the name would either
+       be in the subjectDN or subjectAltName fields.  For Kerberos, the
+       name would be a service principle name.
+
+   3.  Using the matching semantics defined by the application protocol,
+       the client compares the name in the credential with the name sent
+       to the server.
+
+   4.  If the names match, there is reasonable assurance that the
+
+
+
+Daigle & Newton          Expires August 15, 2004               [Page 15]
+
+Internet-Draft           draft-daigle-napstr-04            February 2004
+
+
+       correct end point has been reached.
+
+   It is important to note that this document does not define either the
+   handshake mechanism, the specific credenential naming fields, nor the
+   name matching semantics.  Definitions of S-NAPTR for particular
+   application protocols MUST define these.
+
+8. Acknowledgements
+
+   Many thanks to Dave Blacka, Patrik Faltstrom, Sally Floyd for
+   discussion and input that has (hopefully!) provoked clarifying
+   revisions of this document.
+
+References
+
+   [1]  Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource
+        Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
+
+   [2]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
+        Levels", BCP 14, RFC 2119, March 1997.
+
+   [3]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
+        Specifications: ABNF", RFC 2234, November 1997.
+
+   [4]  Eastlake, D., "Domain Name System Security Extensions", RFC
+        2535, March 1999.
+
+   [5]  Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for
+        specifying the location of services (DNS SRV)", RFC 2782,
+        February 2000.
+
+   [6]  Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
+        One: The Comprehensive DDDS", RFC 3401, October 2002.
+
+   [7]  Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
+        Three: The Domain Name System (DNS) Database", RFC 3403, October
+        2002.
+
+   [8]  Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
+        Four: The Uniform Resource Identifiers (URI)", RFC 3404, October
+        2002.
+
+
+
+
+
+
+
+
+
+
+Daigle & Newton          Expires August 15, 2004               [Page 16]
+
+Internet-Draft           draft-daigle-napstr-04            February 2004
+
+
+Authors' Addresses
+
+   Leslie Daigle
+   VeriSign, Inc.
+   21355 Ridgetop Circle
+   Dulles, VA  20166
+   US
+
+   EMail: leslie@verisignlabs.com; leslie@thinkingcat.com
+
+
+   Andrew Newton
+   VeriSign, Inc.
+   21355 Ridgetop Circle
+   Dulles, VA  20166
+   US
+
+   EMail: anewton@verisignlabs.com
+
+Appendix A. Application Service Location Application of DDDS
+
+   This section defines the DDDS application, as described in [6].
+
+A.1 Application Unique String
+
+   The Application Unique String is domain label for which an
+   authoritative server for a particular service is sought.
+
+A.2 First Well Known Rule
+
+   The "First Well Known Rule" is identity -- that is, the output of the
+   rule is the Application Unique String, the domain label for which the
+   authoritative server for a particular service is sought.
+
+A.3 Expected Output
+
+   The expected output of this Application is the information necessary
+   to connect to authoritative server(s) (host, port, protocol) for an
+   application service within a given a given domain.
+
+A.4 Flags
+
+   This DDDS Application uses only 2 of the Flags defined for the
+   URI/URN Resolution Application ([8]): "S" and "A".  No other Flags
+   are valid.
+
+   Both are for terminal lookups.  This means that the Rule is the last
+   one and that the flag determines what the next stage should be.  The
+
+
+
+Daigle & Newton          Expires August 15, 2004               [Page 17]
+
+Internet-Draft           draft-daigle-napstr-04            February 2004
+
+
+   "S" flag means that the output of this Rule is a domain label for
+   which one or more SRV [5] records exist.  "A" means that the output
+   of the Rule is a domain name and should be used to lookup address
+   records for that domain.
+
+   Consistent with the DDDS algorithm, if the Flag string is empty the
+   next lookup is for another NAPTR record (for the replacement target).
+
+A.5 Service Parameters
+
+   Service Parameters for this Application take the form of a string of
+   characters that follow this ABNF ([3]):
+
+      service-parms = [ [app-service] *(":" app-protocol)]
+      app-service   = experimental-service  / iana-registered-service
+      app-protocol  = experimental-protocol / iana-registered-protocol
+      experimental-service      = "x-" 1*30ALPHANUMSYM
+      experimental-protocol     = "x-" 1*30ALPHANUMSYM
+      iana-registered-service   = ALPHA *31ALPHANUMSYM
+      iana-registered-protocol  = ALPHA *31ALPHANUM
+      ALPHA         =  %x41-5A / %x61-7A   ; A-Z / a-z
+      DIGIT         =  %x30-39 ; 0-9
+      SYM           =  %x2B / %x2D / %x2E  ; "+" / "-" / "."
+      ALPHANUMSYM   =  ALPHA / DIGIT / SYM
+      ; The app-service and app-protocol tags are limited to 32
+      ; characters and must start with an alphabetic character.
+      ; The service-parms are considered case-insensitive.
+
+   Thus, the Service Parameters may consist of an empty string, just an
+   app-service, or an app-service with one or more app-protocol
+   specifications separated by the ":" symbol.
+
+   Note that this is similar to, but not the same as the syntax used in
+   the URI DDDS application ([8]).  The DDDS DNS database requires each
+   DDDS application to define the syntax of allowable service strings.
+   The syntax here is expanded to allow the characters that are valid in
+   any URI scheme name (see [1]).  Since "+" (the separator used in the
+   RFC3404 service parameter string) is an allowed character for URI
+   scheme names, ":" is chosen as the separator here.
+
+A.5.1 Application Services
+
+   The "app-service" must be a registered service [this will be an IANA
+   registry; this is not the IANA port registry, because we want to
+   define services for which there is no single protocol, and we don't
+   want to use up port space for nothing].
+
+
+
+
+
+Daigle & Newton          Expires August 15, 2004               [Page 18]
+
+Internet-Draft           draft-daigle-napstr-04            February 2004
+
+
+A.5.2 Application Protocols
+
+   The protocol identifiers that are valid for the "app-protocol"
+   production are any standard, registered protocols [IANA registry
+   again -- is this the list of well known/registered ports?].
+
+A.6 Valid Rules
+
+   Only substitution Rules are permitted for this application.  That is,
+   no regular expressions are allowed.
+
+A.7 Valid Databases
+
+   At present only one DDDS Database is specified for this Application.
+   [7] specifies a DDDS Database that uses the NAPTR DNS resource record
+   to contain the rewrite rules.  The Keys for this database are encoded
+   as domain-names.
+
+   The First Well Known Rule produces a domain name, and this is the Key
+   that is used for the first lookup -- the NAPTR records for that
+   domain are requested.
+
+   DNS servers MAY interpret Flag values and use that information to
+   include appropriate NAPTR, SRV or A records in the Additional
+   Information portion of the DNS packet.  Clients are encouraged to
+   check for additional information but are not required to do so.  See
+   the Additional Information Processing section of [7] for more
+   information on NAPTR records and the Additional Information section
+   of a DNS response packet.
+
+Appendix B. Pseudo pseudocode for S-NAPTR
+
+B.1 Finding the first (best) target
+
+   Assuming the client supports 1 protocol for a particular application
+   service, the following pseudocode outlines the expected process to
+   find the first (best) target for the client, using S-NAPTR.
+
+
+    target = [initial domain]
+    naptr-done = false
+
+    while (not naptr-done)
+     {
+      NAPTR-RRset = [DNSlookup of NAPTR RRs for target]
+      [sort NAPTR-RRset by ORDER, and PREF within each ORDER]
+      rr-done = false
+      cur-rr = [first NAPTR RR]
+
+
+
+Daigle & Newton          Expires August 15, 2004               [Page 19]
+
+Internet-Draft           draft-daigle-napstr-04            February 2004
+
+
+      while (not rr-done)
+         if ([SERVICE field of cur-rr contains desired application
+              service and application protocol])
+            rr-done = true
+            target= [REPLACEMENT target of NAPTR RR]
+         else
+            cur-rr = [next rr in list]
+
+         if (not empty [FLAG in cur-rr])
+            naptr-done = true
+     }
+
+    port = -1
+
+    if ([FLAG in cur-rr is "S"])
+     {
+      SRV-RRset = [DNSlookup of SRV RRs for target]
+      [sort SRV-RRset based on PREF]
+      target = [target of first RR of SRV-RRset]
+      port = [port in first RR of SRV-RRset]
+     }
+
+    ; now, whether it was an "S" or an "A" in the NAPTR, we
+    ; have the target for an A record lookup
+
+    host = [DNSlookup of target]
+
+    return (host, port)
+
+
+
+B.2 Finding subsequent targets
+
+   The pseudocode in Appendix B is crafted to find the first, most
+   preferred, host-port pair for a particular application service an
+   protocol.  If, for any reason, that host-port pair did not work
+   (connection refused, application-level error), the client is expected
+   to try the next host-port in the S-NAPTR tree.
+
+   The pseudocode above does not permit retries -- once complete, it
+   sheds all context of where in the S-NAPTR tree it finished.
+   Therefore, client software writers could
+
+   o  entwine the application-specific protocol with the DNS lookup and
+      RRset processing described in the pseudocode and continue the S-
+      NAPTR processing if the application code fails to connect to a
+      located host-port pair;
+
+
+
+
+Daigle & Newton          Expires August 15, 2004               [Page 20]
+
+Internet-Draft           draft-daigle-napstr-04            February 2004
+
+
+   o  use callbacks for the S-NAPTR processing;
+
+   o  use an S-NAPTR resolution routine that finds *all* valid servers
+      for the required application service and protocol from the
+      originating domain, and provides them in sorted order for the
+      application to try in order.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Daigle & Newton          Expires August 15, 2004               [Page 21]
+
+Internet-Draft           draft-daigle-napstr-04            February 2004
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2004).  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 Standards process must be
+   followed, or as required to translate it into 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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Daigle & Newton          Expires August 15, 2004               [Page 22]
+
diff --git a/doc/draft/draft-danisch-dns-rr-smtp-03.txt b/doc/draft/draft-danisch-dns-rr-smtp-03.txt
new file mode 100644
index 0000000..4a01d91
--- /dev/null
+++ b/doc/draft/draft-danisch-dns-rr-smtp-03.txt
@@ -0,0 +1,1960 @@
+
+
+
+INTERNET-DRAFT                                           Hadmut Danisch
+Category: Experimental                                         Oct 2003
+Expires: Apr 1, 2004
+
+ The RMX DNS RR and method for lightweight SMTP sender authorization
+                   draft-danisch-dns-rr-smtp-03.txt
+
+Status of this Memo
+
+   This document is an Internet-Draft and is subject to 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 draft documents 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 "work in
+   progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/1id-abstracts.html
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html
+
+Abstract
+
+   This memo introduces a new authorization scheme for SMTP e-mail
+   transport. It is designed to be a simple and robust protection
+   against e-mail fraud, spam and worms. It is based solely on
+   organisational security mechanisms and does not require but still
+   allow use of cryptography. This memo also focuses on security and
+   privacy problems and requirements in context of spam defense. In
+   contrast to prior versions of the draft a new RR type is not
+   required anymore.
+
+
+
+
+
+
+
+
+
+
+
+
+Hadmut Danisch                Experimental                      [Page 1]
+
+INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
+
+
+                           Table of Contents
+
+
+1.  General Issues . . . . . . . . . . . . . . . . . . . . . . . . .   4
+2.  Problem and threat description . . . . . . . . . . . . . . . . .   4
+    2.1.  Mail sender forgery  . . . . . . . . . . . . . . . . . . .   4
+          2.1.1  Definition of sender forgery  . . . . . . . . . . .   4
+          2.1.2  Spam  . . . . . . . . . . . . . . . . . . . . . . .   5
+          2.1.3  E-Mail Worms  . . . . . . . . . . . . . . . . . . .   5
+          2.1.4  E-Mail spoofing and fraud . . . . . . . . . . . . .   5
+    2.2.  Indirect damage caused by forgery  . . . . . . . . . . . .   6
+    2.3.  Technical problem analysis . . . . . . . . . . . . . . . .   6
+    2.4.  Shortcomings of cryptographical approaches . . . . . . . .   7
+3.  A DNS based sender address verification  . . . . . . . . . . . .   7
+    3.1.  Overview . . . . . . . . . . . . . . . . . . . . . . . . .   7
+    3.2.  Envelope vs. header sender address . . . . . . . . . . . .   9
+    3.3.  Domain part vs. full sender address  . . . . . . . . . . .   9
+4.  Mapping of E-Mail addresses to DNS names . . . . . . . . . . . .  10
+    4.1.  Domain part only . . . . . . . . . . . . . . . . . . . . .  10
+    4.2.  Full address . . . . . . . . . . . . . . . . . . . . . . .  11
+    4.3.  Empty address  . . . . . . . . . . . . . . . . . . . . . .  11
+5.  Mandatory entry types and their syntax . . . . . . . . . . . . .  11
+    5.1.  Overall structure  . . . . . . . . . . . . . . . . . . . .  11
+    5.2.  Unused . . . . . . . . . . . . . . . . . . . . . . . . . .  12
+    5.3.  IPv4 and IPv6 address ranges . . . . . . . . . . . . . . .  12
+    5.4.  DNS Hostname . . . . . . . . . . . . . . . . . . . . . . .  13
+          5.4.1  Road warriors and DynDNS entries  . . . . . . . . .  13
+    5.5.  APL Reference  . . . . . . . . . . . . . . . . . . . . . .  14
+    5.6.  Domain Member  . . . . . . . . . . . . . . . . . . . . . .  14
+    5.7.  Full Address Query . . . . . . . . . . . . . . . . . . . .  15
+    5.8.  DNS mapped authorization . . . . . . . . . . . . . . . . .  15
+    5.9.  RMX reference  . . . . . . . . . . . . . . . . . . . . . .  16
+6.  Optional and experimental entry types  . . . . . . . . . . . . .  16
+    6.1.  TLS fingerprint  . . . . . . . . . . . . . . . . . . . . .  16
+    6.2.  TLS and LDAP . . . . . . . . . . . . . . . . . . . . . . .  16
+    6.3.  PGP or S/MIME signature  . . . . . . . . . . . . . . . . .  16
+    6.4.  Transparent Challenge/Response . . . . . . . . . . . . . .  17
+    6.5.  SASL Challenge/Response  . . . . . . . . . . . . . . . . .  17
+7.  Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . .  17
+    7.1.  Alternative encoding as TXT records  . . . . . . . . . . .  17
+    7.2.  RMX Records  . . . . . . . . . . . . . . . . . . . . . . .  17
+          7.2.1  Overall structure . . . . . . . . . . . . . . . . .  18
+          7.2.2  Record encoding . . . . . . . . . . . . . . . . . .  18
+          7.2.3  Encoding of IPv4 and IPv6 address ranges  . . . . .  18
+          7.2.4  Encoding of DNS . . . . . . . . . . . . . . . . . .  18
+          7.2.5  Encoding of unused and full query . . . . . . . . .  19
+          7.2.6  Additional Records  . . . . . . . . . . . . . . . .  19
+8.  Message Headers  . . . . . . . . . . . . . . . . . . . . . . . .  19
+
+
+
+Hadmut Danisch                Experimental                      [Page 2]
+
+INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
+
+
+9.  SMTP error messages  . . . . . . . . . . . . . . . . . . . . . .  20
+10.  Message relaying and forwarding . . . . . . . . . . . . . . . .  20
+    10.1.  Problem description . . . . . . . . . . . . . . . . . . .  20
+    10.2.  Trusted relaying/forwarding . . . . . . . . . . . . . . .  21
+    10.3.  Untrusted relaying/forwarding . . . . . . . . . . . . . .  21
+11.  Security Considerations . . . . . . . . . . . . . . . . . . . .  22
+    11.1.  Draft specific considerations . . . . . . . . . . . . . .  22
+          11.1.1  Authentication strength  . . . . . . . . . . . . .  22
+          11.1.2  Where Authentication and Authorization end . . . .  22
+          11.1.3  Vulnerability of DNS . . . . . . . . . . . . . . .  23
+          11.1.4  Sneaking RMX attack?   . . . . . . . . . . . . . .  25
+          11.1.5  Open SMTP relays . . . . . . . . . . . . . . . . .  25
+          11.1.6  Unforged Spam  . . . . . . . . . . . . . . . . . .  25
+          11.1.7  Reliability of Whois Entries . . . . . . . . . . .  26
+          11.1.8  Hazards for Freedom of Speech  . . . . . . . . . .  26
+    11.2.  General Considerations about spam defense . . . . . . . .  27
+          11.2.1  Action vs. reaction  . . . . . . . . . . . . . . .  27
+          11.2.2  Content based Denial of Service attacks  . . . . .  27
+12.  Privacy Considerations  . . . . . . . . . . . . . . . . . . . .  28
+    12.1.  Draft specific considerations . . . . . . . . . . . . . .  28
+          12.1.1  No content leaking . . . . . . . . . . . . . . . .  28
+          12.1.2  Message reception and sender domain  . . . . . . .  28
+          12.1.3  Network structure  . . . . . . . . . . . . . . . .  29
+          12.1.4  Owner information distribution . . . . . . . . . .  29
+    12.2.  General Considerations about spam defense . . . . . . . .  29
+          12.2.1  Content leaking of content filters . . . . . . . .  29
+          12.2.2  Black- and Whitelists  . . . . . . . . . . . . . .  30
+13.  Deployment Considerations . . . . . . . . . . . . . . . . . . .  30
+    13.1.  Compatibility . . . . . . . . . . . . . . . . . . . . . .  30
+          13.1.1  Compatibility with old mail receivers  . . . . . .  30
+          13.1.2  Compatibility with old mail senders  . . . . . . .  30
+          13.1.3  Compatibility with old DNS clients . . . . . . . .  30
+          13.1.4  Compatibility with old DNS servers . . . . . . . .  30
+    13.2.  Enforcement policy  . . . . . . . . . . . . . . . . . . .  31
+14.  General considerations about fighting spam  . . . . . . . . . .  31
+    14.1.  The economical problem  . . . . . . . . . . . . . . . . .  31
+    14.2.  The POP problem . . . . . . . . . . . . . . . . . . . . .  32
+    14.3.  The network structure problem . . . . . . . . . . . . . .  33
+    14.4.  The mentality problem . . . . . . . . . . . . . . . . . .  33
+    14.5.  The identity problem  . . . . . . . . . . . . . . . . . .  33
+    14.6.  The multi-legislation problem . . . . . . . . . . . . . .  34
+Implementation and further Information . . . . . . . . . . . . . . .  34
+References . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  34
+Draft History  . . . . . . . . . . . . . . . . . . . . . . . . . . .  35
+Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . .  35
+
+
+
+
+
+
+Hadmut Danisch                Experimental                      [Page 3]
+
+INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
+
+
+1.  General Issues
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in
+   this document are to be interpreted as described in RFC 2119 [1].
+
+2.  Problem and threat description
+
+2.1.  Mail sender forgery
+
+   The amount of e-mails with forged sender addresses has dramatically
+   increased. As a consequence, damages and annoyances caused by such
+   e-mails increased as well. In the majority of examined e-mails the
+   domain name of the envelope sender address was forged, and the e-
+   mail was sent from an IP address which does not belong to a network
+   used by the actual owner of the domain.
+
+2.1.1.  Definition of sender forgery
+
+   As discussions, comments to prior versions of this draft, and
+   different approaches to stop forgery showed, different perceptions
+   of "mail forgery" exist. For example, there are mechanisms to
+   verify e-mail addresses for mailing lists, web servers, or to stop
+   spam, which do send a message with a random number to the given
+   address and expect the user to send a reply. Here, someone is
+   considered to be allowed to use a particular e-mail address, if and
+   only if he is able to receive informations sent to this address,
+   and is able to reply to such a message. While this definition
+   appears to be quite plausible and natural, it can't be used for a
+   simple technical solution. Sending back a challenge and expecting a
+   reply is simply too much overhead and time delay, and not every
+   authorized sender is able or willing to reply (e.g. because he went
+   offline or is not a human).
+
+   Within the scope of this memo, sender forgery means that the
+   initiator of an e-mail transfer (which is the original sender in
+   contrast to relays) uses a sender address which he was not
+   authorized to use. Being authorized to use an address means that
+   the owner (administrator) of the internet domain has given
+   permission, i.e. agrees with the use of the address by that
+   particular sender. This memo will cover both the permission of the
+   full e-mail address and the domain part only for simplicity.
+
+   Within context of Internet and SMTP, the sender address usually
+   occurs twice, once as the envelope sender address in SMTP, and once
+   as the address given in the RFC822 mail header. While the following
+   considerations apply to both addresses in principle, it is
+   important to stress that both addresses have distinct semantics and
+
+
+
+Hadmut Danisch                Experimental                      [Page 4]
+
+INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
+
+
+   are not neccessarily the same. The envelope address identifies the
+   initiator of the transport, while the header identifies the author
+   of the message content. Since this memo deals with the message
+   transport only and completely ignores the message content, the
+   method should naturally be applied to the envelope sender address.
+
+2.1.2.  Spam
+
+   A common and well known problem is the dramatic increase of
+   unsolicited e-mail, commonly called "spam". Again, the majority of
+   examined e-mails had forged sender addresses.  The abused domains
+   were mainly those of common webmailers as hotmail or yahoo, or
+   well-known companies.
+
+   Unfortunately, there is no accurate definition of spam availabe
+   yet, and neither are the concise technical criterions to filter or
+   block spam with technical mechanisms. There are efforts to design
+   content based filters, but these filters are expensive in
+   calculation time (and sometimes money), and they do not reliably
+   provide predictable results. Usually they give false positives
+   and/or require user interaction. Content filters in general suffer
+   from a design problem described later in this memo.  Therefore,
+   this proposal does not use the content based approach to block
+   spam.
+
+   As analysis of spam messages showed, most of spam messages were
+   sent with forged envelope sender addresses. This has mainly three
+   reasons.  The first reason is, that spam senders usually do not
+   want to be contacted by e-mail. The second reason is, that they do
+   not want to be blacklisted easily. The third reason is, that spam
+   is or is going to be unlawful in many countries, and the sender
+   does not want to reveal his identity. Therefore, spam is considered
+   to be a special case of sender forgery.
+
+2.1.3.  E-Mail Worms
+
+   Another example of sender forgery is the reproduction of e-mail
+   worms. Most worms do choose random sender addresses, e.g.  using
+   the addresses found in mailboxes on the infected system. In most
+   cases analyzed by the author, the e-mails sent by the reproduction
+   process can also be categorized as forged, since the infected
+   system would under normal circumstances not be authorized to send
+   e-mails with such e-mail addresses. So forgery does not require a
+   malicious human to be directly involved. This memo covers any kind
+   of e-mail sender address forgery, included those generated by
+   malicious software.
+
+2.1.4.  E-Mail spoofing and fraud
+
+
+
+Hadmut Danisch                Experimental                      [Page 5]
+
+INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
+
+
+   Forging e-mail sender addresses for fraud or other kinds of
+   deception ("human engineering") has also dramatically increased.
+   There are many known cases where single or mass e-mails were sent
+   with wrong sender addresses, pretending to come from service
+   provider, software manufacturers etc., and asking the receiver to
+   install any software or patches, or to reply with any confidential
+   information. The Internet is becoming more and more a scene of
+   crime, and so are it's services, including e-mail. It is obvious
+   that crime based on e-mail is eased by the fact that SMTP allows
+   arbitrary sender address spoofing.
+
+2.2.  Indirect damage caused by forgery
+
+   As observed by the author, mass mails and worms with forged sender
+   addresses can cause a severe damage for the real owner of the
+   abused sender addresses. If a sender A is sending an e-mail to the
+   receiver B, pretending to be C by using a sender address of C's
+   domain, then C has currently no chance to prevent this, since C's
+   machines and software are not involved in any way in the delivery
+   process between A and B.  B will nevertheless send any error
+   messages (virus/spam alert, "no such user", etc.) to C, erroneously
+   assuming that the message was sent by C. The author found several
+   cases where this flood of error messages caused a severe denial of
+   service or a dramatic increase of costs, e.g. when C was
+   downloading the e-mail through expensive or low bandwidth
+   connections (e.g. modem or mobile phones), or where disk space was
+   limited. The author examined mass mailings, where several tens or
+   hundreds of thousands of messages were sent to several addresses
+   around the world, where these messages caused only annoyance. But
+   since several thousands of these addresses were invalid or didn't
+   accept the message, the owner of the DNS domain which was abused by
+   the spammer to forge sender addresses was flooded for several
+   months with thousands of error messages, jamming the e-mail system
+   and causing severe costs and damages.
+
+   As a consequence, when A sends a message to B, pretending to be C,
+   there must be any mechanism to allow C to inform B about the fact,
+   that A is not authorized to use C as a sender address. This is what
+   this memo is about.
+
+2.3.  Technical problem analysis
+
+   Why does e-mail forgery actually exist? Because of the lack of the
+   Simple Mail Transfer Protocol SMTP[2] to provide any kind of sender
+   authentication, authorisation, or verification. This protocol was
+   designed at a time where security was not an issue. Efforts have
+   been made to block forged e-mails by requiring the sender address
+   domain part to be resolvable.  This method provides protection from
+
+
+
+Hadmut Danisch                Experimental                      [Page 6]
+
+INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
+
+
+   e-mails with non-existing sender domains, and indeed, for some time
+   it blocked most spam e-mails. However, since attackers and spam
+   senders began to abuse existing domain names, this method was
+   rendered ineffective.
+
+2.4.  Shortcomings of cryptographical approaches
+
+   At a first glance, the problem of sender address forgery might
+   appear to be solvable with cryptographic methods such as challenge
+   response authentications or digital signatures. A deeper analysis
+   shows that only a small, closed user group could be covered with
+   cryptographical methods. Any method used to stop spam forgery must
+   be suitable to detect forgery not only for a small number of
+   particular addresses, but for all addresses on the world. An
+   attacker does not need to know the secrets belonging to a
+   particular address. It is sufficient to be able to forge any
+   address and thus to know any secret key. Since there are several
+   hundreds of millions of users, there will always be a large amount
+   of compromised keys, thus spoiling any common cryptographic method.
+   Furthermore, cryptography has proven to be far too complicated and
+   error prone to be commonly administered and reliably implemented.
+   Many e-mail and DNS administrators do not have the knowledge
+   required to deal with cryptographic mechanisms. Many legislations
+   do not allow the general deployment of cryptography and a directory
+   service with public keys. For these reasons, cryptography is
+   applicable only to a small and closed group of users, but not to
+   all participants of the e-mail service.
+
+3.  A DNS based sender address verification
+
+3.1.  Overview
+
+   To gain improvement in e-mail authenticity while keeping as much
+   SMTP compatibility as possible, a method is suggested which doesn't
+   change SMTP at all.
+
+   The idea is to store informations about how to verify who is
+   authorized to transmit e-mails through SMTP with a particular
+   sender address (either full address or - for simplicity - only the
+   domain part of the address) in a directory service, which is
+   currently the DNS. To be precise, the verification consists of two
+   steps, the classical pair of authentication and authorization:
+
+   The first step is the authentication. While several methods are
+   possible to perform authentication (see below), the most important
+   and robust method is the verification of the sender's IP address.
+   This is done implicitely by TCP/IP and the TCP sequence number. The
+   authenticated identity is the IP address. It has to be stressed
+
+
+
+Hadmut Danisch                Experimental                      [Page 7]
+
+INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
+
+
+   that this TCP/IP "authentication" is a weak authentication and
+   vulnerable to several attacks. It is nevertheless sufficient for
+   this purpose, especially for blocking spam. It doesn't take any
+   implementation and it doesn't cost: It is already there, it is a
+   functionality of TCP/IP. An incoming SMTP connection based on
+   TCP/IP already carries the sender's IP address without any
+   modification of SMTP. See below (section Entry types) for more
+   details about authentication methods.
+
+   The second step is the authorization. It is based on the identity
+   given by the previous authentication step, e.g. the IP address of
+   the originator of the incoming SMTP connection,  and on the
+   envelope sender address. The mechanism proposed in this memo
+   answers the question "Is that particular sender (IP address,...)
+   allowed to send with that sender address" by querying and
+   processing informations stored in a directory service, which is
+   DNS.
+
+   When the sender has issued the "MAIL FROM:" SMTP command, the
+   receiving mail transfer agent (MTA) can - and modern MTAs do -
+   perform some authorization checks, e.g. run a local rule database
+   or check whether the sender domain is resolvable.
+
+   The suggested method is to let the DNS server for the sender domain
+   provide informations about who - this means for example which IP
+   address - is authorized to use an address or a domain as a part of
+   it.  After receiving the "MAIL FROM:" SMTP command, the receiving
+   MTA can verify, whether e. g. the IP address of the sending MTA is
+   authorized to send mails with this domain name. Therefore, a list
+   of entries with authorized IP addresses or other informations is
+   provided by the authoritative DNS server of that domain. The entry
+   types are described in the subsequent chapters. Some of these
+   methods are
+
+     - An IPv4 or IPv6 network address and mask
+     - A fully qualified domain name referring to an A record
+     - A fully qualified domain name referring to an APL record
+
+   RMX records of these types would look like this:
+
+      somedomain.de.      IN RMX ipv4:10.0.0.0/8
+      rmxtest.de.         IN RMX host:relay.provider.com
+      danisch.de.         IN RMX apl:relays.rackland.de
+      relays.rackland.de. IN APL 1:213.133.101.23/32 1:1.2.3.0/24
+
+   where the machine with the example address 213.133.101.23 and the
+   machines in the example subnet 1.2.3.0/24 are the only machines
+   allowed to send e-mails with an envelope sender address of domain
+
+
+
+Hadmut Danisch                Experimental                      [Page 8]
+
+INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
+
+
+   danisch.de. Since the APL records do not necessarily belong to the
+   same domain or zone table as the RMX records, this easily allows to
+   refer to APL records defined by someone else, e.g. the internet
+   access or server hosting provider, thus reducing administrative
+   overhead to a minimum. In the example given above, the domain
+   danisch.de and several other domains are hosted by the service
+   provider Rackland. So if the relay structure of Rackland is
+   modified, only the zone of rackland.de needs to be modified. The
+   domain owners don't need to care about such details.
+
+3.2.  Envelope vs. header sender address
+
+   Questions were raised why the proposed mechanism is based on the
+   envelope sender address, and not on the sender address given in the
+   message header. Technically, both can be used. Actually, it makes
+   sense to use the envelope address.
+
+   In common, the header sender address identifies the author of the
+   content, while the envelope sender tells who caused the
+   transmission.  The approach proposed in this memo is transmission
+   based, not content based. We can not authorize the author of a
+   message if we don't have contact with him, if the message does not
+   already contain a signature. In contrast, the sending MTA is linked
+   to an IP address which can be used for authentication. This
+   mechanism might not be very strong, but it is available and
+   sufficient to solve today's e-mail security problems.
+
+   Some people argued that it is the header address and not the sender
+   address, which is displayed in common mail readers (MUAs), and
+   where the receiver believes the mail comes from. That's true, but
+   it doesn't help. There are many cases where the header sender
+   differs from the envelope sender for good reasons (see below in the
+   consequences chapter for the discussion about relaying).  Relaying,
+   mailing lists etc. require to replace the sender address used for
+   RMX. If this were the header address, the message header would have
+   to be modified. This is undesirable.
+
+3.3.  Domain part vs. full sender address
+
+   Former versions of this draft were limited to the domain part of
+   the sender address. The first reason is that it is common and MX-
+   like, to lookup only the domain part of an e-mail address in DNS.
+   The second reason is, that it was left to the private business of
+   the domain administration to handle details of user verification.
+   The idea was that the domain administration takes care to verify
+   the left part of an e-mail address with an arbitrary method of
+   their individual taste. RMX was originally designed to ignore the
+   left part of the address and to expect the domain administration to
+
+
+
+Hadmut Danisch                Experimental                      [Page 9]
+
+INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
+
+
+   take over responsibility for enforcing their policy. If, e.g., a
+   spam message arrived and passed the RMX mechanism, it is known to
+   be authorized by the domain administration and they can be blamed,
+   no matter what is on the left side of the sender address - it's
+   their private problem what happens on the left side of the @. By
+   far the most of the comments to prior versions of this draft agreed
+   with that. A few comments asked for a finer granularity.
+
+   And indeed, there is no technical reason against a finer
+   granularity.  All it takes is a mapping from a given envelope
+   sender address to a DNS name, and the RMX lookup for that
+   particular e-mail address could be done instead of a lookup for the
+   domain part only.  However, to my knowledge, most domain
+   administrators would not like to provide an RMX entry for every
+   single e-mail address. In many cases, this would also overload DNS
+   servers.
+
+   It is to be discussed how to cover both views. One method could be
+   to query the full address, and if no RMX records were found to
+   query the domain part only. A different approach would be to query
+   the domain part only, and if it's RMX record contain a special
+   entry, then a new query for the full address is triggered. A third
+   way would be to always query the full address and to leave the
+   problem to the wildcard mechanism of DNS. This still has to be
+   discussed and will be described in future versions of this draft.
+
+
+
+
+
+
+
+
+
+
+
+4.  Mapping of E-Mail addresses to DNS names
+
+   To perform the RMX query, a mapping is needed from E-Mail addresses
+   to DNS fully qualified domain names.
+
+   This chapter is under development and just a first approach.
+
+4.1.  Domain part only
+
+   Mapping of the domain part is trivial, since the domain part of an
+   e-mail address itself is a valid DNS name and does not need
+   translation. It might be nevertheless desirable to distinguish the
+
+
+
+Hadmut Danisch                Experimental                     [Page 10]
+
+INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
+
+
+   RMX entries from other entries, depending of the encoding of the
+   records. If the RMX entries are encoded in TXT record types, they
+   might collide with other uses of TXT records.  It might be
+   necessary to prepend the domain part with a special prefix, e.g.
+   _rmx. So the e-mail address some.user@example.com could be mapped
+   to example.com or _rmx.example.com.
+
+4.2.  Full address
+
+   Mapping a full address is slightly more difficult. The @ sign must
+   be unambiguously translated, and therefore can not be simply
+   translated into a dot. The e-mail addresses some.user@example.com
+   and some@user.example.com must have different mappings. Therefore,
+   the @ sign could be translated into _rmx, implicitely assuming that
+   this is not an allowed domain name component of normal domain
+   names. Then the rightmost _rmx in the mapped DNS name always
+   corresponds to the @ sign. some.user@example.com would e translated
+   into some.user._rmx.example.com and can be covered by a wildcard
+   entry like *._rmx.example.com.
+
+   Character encoding and character sets are still to be discussed.
+
+4.3.  Empty address
+
+   Unfortunately, SMTP allows empty envelope sender addresses to be
+   used for error messages. Empty sender addresses can therefore not
+   be prohibited. As observed, a significant amount of spam was sent
+   with such an empty sender address. To solve this problem, the host
+   name given in the HELO or EHLO command is taken to lookup the RMX
+   records instead. This makes sense, since such messages were
+   generated by the machine, not a human.
+
+
+
+
+5.  Mandatory entry types and their syntax
+
+   The entry types described in this section MUST be supported by any
+   implementation of this draft.
+
+5.1.  Overall structure
+
+   Similar to APL, an RMX record is just a concatenation of zero or
+   more RMX entries. The entries within one record form an ordered
+   rule base as commonly usual in packet filtes and firewall rulesets,
+   i. e. they are processed one ofter another until the first entry
+   matches. This entry determines the result of the query. Once a
+   matching entry is found, the RMX processing is finished.
+
+
+
+Hadmut Danisch                Experimental                     [Page 11]
+
+INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
+
+
+   For any domain name there should not exist more than a single RMX
+   record. Due to the structure of DNS, it is nevertheless possible to
+   have more than a single RMX record. Multiple RMX records are
+   treated as a single record consisting of the concatenation of all
+   records. While the entries in a record are ordered, the records are
+   not ordered and may be processed in arbitrary order. If the order
+   of the entries matters, it is the zone maintainer's responsibility
+   to keep those entries in a single record. For example, there are
+   negative entries, which exclude IP addresses from authorization.
+   It is important that these entries are processed before positive
+   entries giving permission to a wider address range. Since order is
+   guaranteed only within a record, corresponding negative and
+   positive entries must be put in the same record.
+
+   An RMX record may consist of one or more entries, where the entries
+   are separated by whitespace. An entry must not contain white space.
+   Each entry consists of an optional exclamation sign, a tag, a
+   colon, and the entry data:
+
+      [!] TAG : ENTRY-SPECIFIC-DATA
+
+   If the entry starts with an exclamation sign, the entry is negated.
+   See the entry type description below for details.
+
+   The TAG is the mnemonic type identifier or the decimal number of
+   the entry. The TAG is case-insensitive. It is immediately followed
+   by a colon.
+
+   The syntax and semantics of ENTRY-SPECIFIC-DATA depends of the the
+   entry type. See description below.
+
+   Example:
+
+      danisch.de.  IN RMX apl:relays.rackland.de !ipv4:1.2.3.5
+   ipv4:1.2.3.0/24
+
+5.2.  Unused
+
+   This is a primitive entry which just says that this sender address
+   will never be used as a sender address under any circumstances.
+   Example:
+
+   testdomain.danisch.de    IN RMX unused:
+
+5.3.  IPv4 and IPv6 address ranges
+
+   These entry types contain a bit sequence representing a CIDR
+   address part. If that bit sequence matches the given IP address,
+
+
+
+Hadmut Danisch                Experimental                     [Page 12]
+
+INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
+
+
+   authorization is granted or denied, depending on the negation flag.
+
+   The entry is prepended with the tag "IPv4" or "IPv6". The colon is
+   followed with an IPv4 or IPv6 address in standard notation,
+   optionally followed by a slash and a mask length. If the negation
+   flag is set, then the given address range is excluded.  Examples:
+
+   danisch.de   IN RMX ipv4:213.133.101.23 ipv6:fe00::0
+                IN RMX ipv4:10.0.0.0/8     ipv6:fec0::0/16
+                IN RMX !ipv4:1.2.3.4
+
+   (Please note that it does not make much sense to use
+   RFC1918-Addresses in RMX records, this is just to give a syntax
+   example.)
+
+
+5.4.  DNS Hostname
+
+   This entry type simply contains a regular DNS name, which is to be
+   resolved as a host name (fetch the A record or IPv6 equivalent). If
+   the given IP address matches the result, authorization is granted
+   or denied, depending on the negation flag.  It is still to be
+   defined how to treat unresolvable entries.
+
+   The entry is prepended with the tag "host", followed by a colon and
+   the hostname. Examples:
+
+   danisch.de  IN RMX host:relay.provider.de
+               IN RMX !host:badmachine.domain.de apl:relays.domain.de
+
+5.4.1.  Road warriors and DynDNS entries
+
+   Several people argued against RMX that it would break their
+   existing installation which delivers e-mail from dynamically
+   assigned IP addresses, because their IP providers didn't assign a
+   static address, or because they are a road warrior, plugging their
+   notebook in any hotel room on the world.
+
+   RMX provides a simple solution. If such a machine has a dynamically
+   updated DNS entry (e.g. DynDNS), all it takes is an RMX entry of
+   the hostname type pointing to this dynamic DNS entry.
+
+   The cleaner solution would be to deliver mail the same way as it is
+   received: If downloaded by POP from a central relay with a static
+   address, where the MX points to, then it would be a good idea to
+   deliver e-mail the same way in reverse direction. Unfortunately,
+   plain POP does not support uploading yet.
+
+
+
+
+Hadmut Danisch                Experimental                     [Page 13]
+
+INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
+
+
+5.5.  APL Reference
+
+   This entry type simply contains a regular DNS name, which is to be
+   resolved as an APL record index  (fetch the APL record).  If the
+   given IP address positively  matches the APL, authorization is
+   granted. Details of the semantic (espially when the negation bit is
+   set) are still to be defined.  It is still to be defined how to
+   treat unresolvable entries.
+
+   The entry is prepended with the tag "host", followed by a colon and
+   the hostname. Example:
+
+   danisch.de     IN RMX apl:relays.rackland.de
+
+5.6.  Domain Member
+
+   In many cases it is desirable to cover all hosts of a given domain
+   with an RMX record without the need to duplicate the list of these
+   hosts. This entry type does it (thanks to Eric A. Hall for pointing
+   out this entry type).  It contains a regular DNS name.
+
+   If this entry type is given, a reverse DNS query for the IP address
+   of the sending MTA is performed to find its official fully
+   qualified domain name. To prevent spoofing, this domain name is
+   accepted only if a subsequent address query to the given domain
+   name points to exactly the IP address of the sending MTA (the usual
+   procedure to verify PTR records).
+
+   The entry matches if the fully qualified domain name of the sending
+   MTA ends in the given domain. The negation flag works as usual.
+
+   The tag for this entry type is "domain". After the colon the domain
+   name is given, but might be empty, thus pointing to itself.
+   Example:
+
+      somedomain.org  IN RMX domain:somedomain.org domain:provider.com
+
+   would authorize all machines which's hostname can be verified
+   through an PTR and A query, and which ends in "somedomain.org" or
+   "provider.com".
+
+   With such an entry, large companies with different networks can
+   easily be covered with just a single and simple RMX entry.
+   Obviously, it requires proper PTR records.
+
+   As a special shortcut, the DNS name may be empty. In this case the
+   domain name of the zone itself is taken. Thus, with a very simple
+   entry of the type
+
+
+
+Hadmut Danisch                Experimental                     [Page 14]
+
+INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
+
+
+     somecompany.com  IN RMX domain:
+
+   a company could authorize all machines which's IP addresses map to
+   DNS names end in somecompany.com, which applies in the majority of
+   companies.
+
+
+
+
+5.7.  Full Address Query
+
+   As described above, RMX records will in most cases apply to the
+   domain part of the sender address. In special cases it might be
+   desirable to query the RMX record for a particular address.  An RMX
+   entry of the Full Address Query type may occur in a domain RMX
+   record only. It signals that the RMX record for the full address is
+   to be fetched and processed.
+
+   This entry type does not take arguments. The negation flag is not
+   supported. The tag is "full".
+
+   If such a full address query is to be performed, the mail address
+   must be mapped to a valid and non-ambiguos DNS name. This mapping
+   is still to be defined. It is not sufficient to simply replace the
+   @ with a dot, because of case sensitivity, character sets, etc. The
+   e-mail addresses
+
+      john.doe@example.org
+      John.Doe@example.org
+      john@doe.example.org
+
+   must all be mapped to different DNS entries. This entry type might
+   vanish in future versions of the draft, depending on the discussion
+   about whether to query the domain name part only or the full
+   address.
+
+5.8.  DNS mapped authorization
+
+   As I learned from comments to prior versions of the draft and from
+   alternative proposals, many users wish to have a DNS mapped
+   authorization table, i. e. the client queries a DNS entry of the
+   form a.b.c.d.domain, where a.b.c.d is the sender's IP address.
+   Since people wish to have this, RMX will now include such a mapping
+   entry. The entry has a parameter giving the DNS domain name where
+   to look at. If the parameter is empty, then the same domain is
+   taken as for the RMX lookup.
+
+   As this is currently under construction and discussion in an IETF
+
+
+
+Hadmut Danisch                Experimental                     [Page 15]
+
+INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
+
+
+   group, details will be published in future versions of this draft.
+
+5.9.  RMX reference
+
+   This entry type has no parameters. It means that all those machines
+   are authorized, which are pointed to by an MX record.
+
+6.  Optional and experimental entry types
+
+   The following subsections roughly describe further entry types
+   which might not be supported by all implementations and might not
+   be allowed in all legislations. These methods might vanish in
+   future versions of the draft and are just considerations about what
+   to include in RMX and what to not include. The main purpose of this
+   section is to start discussion about such entry types.
+
+   The disadvantage of the following methods is that they violate the
+   basic idea of RMX, i. e. to be simple, robust, easy to implement
+   and easy to administer. I personally do not believe that it is a
+   good idea or even feasible to implement cryptography for a world
+   wide e-mail transfer network. Keep in mind that cryptographic keys
+   can be copied.  If only <0.1% of cryptographic keys were revealed,
+   this completely compromises and spoils RMX. Cryptography is simply
+   the wrong tool for the problem RMX is intended to solve. I
+   nevertheless like to discuss these methods.
+
+6.1.  TLS fingerprint
+
+   The sender is considered to be authorized if the message was
+   transmitted through SMTP and TLS, and the sender used a certificate
+   matching the fingerprint given in the RMX record.
+
+6.2.  TLS and LDAP
+
+   This means that the receiver should perform an LDAP query for the
+   sender address (through the LDAP SRV record or given in the RMX
+   record), fetch the X.509 certificate for the sender. The sender is
+   considered to be authorized when the message was transmitted
+   through SMTP and TLS using this certificate.
+
+6.3.  PGP or S/MIME signature
+
+   It would be possible to accept a message only if it was signed with
+   PGP or S/MIME with a key which's fingerprint is given in the RMX
+   record or to be fetched from LDAP or any PGP database.  This is
+   just for discussion, since it violates the idea of RMX to focus on
+   the transport, not on the content. It would also allow replay
+   attacks and not cover the envelope sender address or message
+
+
+
+Hadmut Danisch                Experimental                     [Page 16]
+
+INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
+
+
+   header.
+
+6.4.  Transparent Challenge/Response
+
+   It would also be possible to implement a challenge-response
+   mechanism without modifying the syntax of SMTP. For example, the
+   receiving MTA could issue a challenge with it's very first greeting
+   message, the sending MTA could hide the response in the HELO
+   parameter and when the receiving MTA later learns the sender
+   envelope address, it could verify the response based on
+   informations in the RMX record.
+
+6.5.  SASL Challenge/Response
+
+   Modern SMTP implementations already include a SASL mechanisms,
+   which easily allows to plugin new authentication mechanisms. While
+   common SASL mechanisms require to use a previously shared password,
+   a new mechanism could perform a challenge response authentication
+   as a SASL method.
+
+
+
+
+
+
+7.  Encoding
+
+7.1.  Alternative encoding as TXT records
+
+   The main objection against the prior versions of this draft was
+   that it requires a new RR entry type and upgrading all DNS servers.
+
+   Therefore and alternative encoding is proposed. Instead of using a
+   new RR type, the TXT record type is used to contain the RMX record.
+   The records would simply look as described in the entry type
+   chapters above, e.g.
+
+      _rmx.danisch.de.   IN TXT "apl:relays.rackland.de"
+
+   To allow smooth introduction of RMX without the need to immediately
+   upgrade all DNS servers, all clients (which have to be newly
+   installed anyway) MUST support both the TXT and the RMX records. A
+   client has to perform an ANY or a TXT and a RMX query. Servers/zone
+   tables may currently use TXT entries but SHOULD use RMX entries in
+   future.
+
+7.2.  RMX Records
+
+
+
+
+Hadmut Danisch                Experimental                     [Page 17]
+
+INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
+
+
+7.2.1.  Overall structure
+
+   Each entry starts with an octet containting the entry type and the
+   negation flag:
+
+      +---+---+---+---+---+---+---+---+------
+      | N |    Entry Type Code        | Parameters...
+      +---+---+---+---+---+---+---+---+------
+
+      N           If this bit (MSB) is set, an IP address
+                  matching this entry is not authorized,
+                  but explicitely rejected. See entry
+                  type descriptions for details.
+
+      Entry Type  A 7bit number simply determining the entry
+                  type.
+
+
+   Currently, entries do not have an explicit length field, the entry
+   length is determined implicitely by the entry type. Applications
+   are required to abort if an unknown entry type is found, instead of
+   skipping unknown entries.
+
+7.2.2.  Record encoding
+
+   A RMX record is simply a concatenation of RMX entries.
+
+7.2.3.  Encoding of IPv4 and IPv6 address ranges
+
+   After the entry type tag as described above, one octet follows
+   giving the length L of the bit sequence. Then a sequence of exactly
+   as many octets follows as needed to carry L bits of information (=
+   trunc((L+7)/8) ).
+
+      +---+---+---+---+---+---+---+---+
+      | N | Entry Type Code  (1 or 2) |
+      +---+---+---+---+---+---+---+---+
+      |         Length Field L        |
+      +---+---+---+---+---+---+---+---+
+      |           Bit Field           |
+      /        ((L+7)/8) Octets       /
+      +---+---+---+---+---+---+---+---+
+
+
+7.2.4.  Encoding of DNS
+
+   After the entry type tag immediately follows a DNS encoded and
+   compressed [3] domain name.
+
+
+
+Hadmut Danisch                Experimental                     [Page 18]
+
+INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
+
+
+      +---+---+---+---+---+---+---+---+
+      | N |  Entry Type Code  (3..5)  |
+      +---+---+---+---+---+---+---+---+
+      |         Length Field L        |
+      +---+---+---+---+---+---+---+---+
+      |  Encoded DNS                  |
+      /  Name as described in RFC1035 /
+      +---+---+---+---+---+---+---+---+
+
+   In contrast to earlier versions of this draft, the DNS name cannot
+   be compressed, since this would cause decompression errors when a
+   DNS server is part of the query chain which does not know this
+   particular RR type.
+
+7.2.5.  Encoding of unused and full query
+
+   These entries do not contain parameters and does not allow the
+   negation flag.  So the encoding is quite simple:
+
+      +---+---+---+---+---+---+---+---+
+      | 0 |  Entry Type Code  (6 or 7)|
+      +---+---+---+---+---+---+---+---+
+
+
+
+7.2.6.  Additional Records
+
+   In order to avoid the need of a second query to resolve the given
+   host name, a DNS server should enclose the A record for that domain
+   name in the additional section of the additional section of the DNS
+   reply, if the server happens to be authoritative.
+
+   In order to avoid the need of a second query to resolve the given
+   host name, a DNS server should enclose the APL record for that
+   domain name in the additional section of the additional section of
+   the DNS reply, if the server happens to be authoritative.
+
+
+
+8.  Message Headers
+
+   An RMX query must be followed by any kind of action depending on
+   the RMX result. One action might be to reject the message.  Another
+   action might be to add a header line to the message body, thus
+   allowing MUAs and delivery programs to filter or sort messages.
+
+   In future, the RMX result might be melted into the Received: header
+   line.
+
+
+
+Hadmut Danisch                Experimental                     [Page 19]
+
+INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
+
+
+   The details of such entries are to be discussed. As a proposal the
+   following form is suggested:
+
+     X-RMX: RESULT addr ADDRESS by HOST on DATE mechanism MECHANISM
+
+   where
+
+   RESULT is one of "Granted", "Denied", "NotInRMX", "NoRMX",
+   "TempFail", "BadData", "Trusted".
+
+   ADDRESS is the IP address of the sending machine
+
+   HOST is the name of the machine performing the RMX query.
+
+   DATE is the date of the query.
+
+   MECHANISM is the RMX method used to authorize the sender.
+
+
+
+9.  SMTP error messages
+
+   If a message is rejected because of RMX records, an error message
+   should be issued which explains the details.  It is to be discussed
+   whether new SMTP error codes are to be defined.
+
+
+10.  Message relaying and forwarding
+
+10.1.  Problem description
+
+   Message forwarding and relaying means that an MTA which received an
+   e-mail by SMTP does not deliver it locally, but resends the message
+   - usually unchanged except for an additional Received header line
+   and maybe the recipient's address rewritten - to the next SMTP MTA.
+   Message forwarding is an essential functionality of e-mail
+   transport services, for example:
+
+     - Message transport from outer MX relay to the intranet
+     - Message forwarding and Cc-ing by .forward or .procmail-alike
+       mechanisms
+     - Mailing list processing
+     - Message reception by mail relays with low MX priority,
+       usually provided by third parties as a stand-by service
+       in case of relay failure or maintenance
+     - "Forwarding" and "Bouncing" as a MUA functionality
+
+   In all these cases a message is sent by SMTP from a host which is
+
+
+
+Hadmut Danisch                Experimental                     [Page 20]
+
+INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
+
+
+   not covered by the original sender domain's RMX records.  While the
+   RMX records would forbid accepting this message, it still must be
+   accepted. The following subsections explain how to cope with
+   relaying.
+
+10.2.  Trusted relaying/forwarding
+
+   In some cases the receiving MTA trusts the sending MTA to not fake
+   messages and to already have checked the RMX records at message
+   reception. As a typical example, a company might have an outer mail
+   relay which receives messages from the Internet and checks the RMX
+   records. This relay then forwards the messages to the different
+   department's mail servers. It does not make sense for these
+   department mail servers to check the RMX record, since the RMX
+   records have already been checked and - since the message was
+   relayed by the outer relay - always would deny the message. In this
+   case there is a trust relationship between the department relays
+   and the outer relay.  So RMX checking is turned off for trusted
+   relays. In this example, the department relays would not check
+   messages from the outer relay (but for intranet security, they
+   could still check RMX records of the other departments sub-domains
+   to avoid internal forgery between departments).
+
+   Another common example are the low-priority MX relays, which
+   receive and cache e-mails when the high-priority relays are down.
+   In this case, the high-priority relay would trust the low-priority
+   relay to have verified the sender authorization and would not
+   perform another RMX verification (which would obviously fail).
+
+   When a relay forwards a message to a trusting machine, the envelope
+   sender address should remain unchanged.
+
+10.3.  Untrusted relaying/forwarding
+
+   If the receiving MTA does not trust the forwarding MTA, then there
+   is no chance to leave the sender envelope address unchanged. At a
+   first glance this might appear impracticable, but this is
+   absolutely necessary. If an untrusted MTA could claim to have
+   forwarded a message from a foreign sender address, it could have
+   forged the message as well. Spammers and forgers would just have to
+   act as such a relay.
+
+   Therefore, it is required that, when performing untrusted
+   forwarding, the envelope sender address has to be replaced by the
+   sender address of someone responsible for the relaying mechanism,
+   e.g. the owner of the mailing list or the mail address of the user
+   who's .forward caused the transmission. It is important to stress
+   that untrusted relaying/forwarding means taking over responsibility
+
+
+
+Hadmut Danisch                Experimental                     [Page 21]
+
+INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
+
+
+   for the message.  It is the idea of RMX records to tie
+   responsibility to message transmission. Untrusted relaying without
+   replacing the sender address would mean to transmit without taking
+   responsibility.
+
+   The disadvantage is that the original sender address is lost.
+   Therefore, whenever a sender address replacement happens, the
+   Received-Line must contain the old address. Many of today's MTAs
+   already insert the envelope recipient address, but not the sender
+   address into the Received header line. It seems reasonable to
+   require every Received line to include both the sender and
+   recipient address of the incoming SMTP connection.
+
+
+11.  Security Considerations
+
+11.1.  Draft specific considerations
+
+11.1.1.  Authentication strength
+
+   It is important to stress, that the suggested method does not
+   provide high level security and does not completely prevent forged
+   e-mails or spam under any circumstances. It is a robust, but not
+   highly reliable and completely secure security mechanism. Keep in
+   mind that it is based on DNS, and DNS is not secure today.
+   Authorization is based on the IP address. The very same machine
+   with the very same IP address could be authorized to send e-mail
+   with a given sender address and sending spam at the same time.
+   Maybe because several users are logged in. Or because several
+   customers use the same relay of the same ISP, where one customer
+   could use the sender address of a different customer. It is up to
+   the ISP to prevent this or not. Machines can still be hijacked.
+   Spammers are also domain owners. They can simply use their own
+   domain and authorize themselves. You will always find people on the
+   world who do not care about security and open their relays and RMX
+   records for others to abuse them.  RMX is to be considered as a
+   very cheap and simple light weight mechanism, which can
+   nevertheless provide a significant improvement in mail security
+   against a certain class of attacks, until a successor of SMTP has
+   been defined and commonly accepted.
+
+11.1.2.  Where Authentication and Authorization end
+
+   Previous versions of RMX records did not cover the local part of
+   the e-mail address, i.e. what's on the left side of the @ sign.
+   This is still to be discussed. Authentication and authorization are
+   limited to the sending MTA's IP address. The authentication is
+   limited to the TCP functionality, which is sufficient for light
+
+
+
+Hadmut Danisch                Experimental                     [Page 22]
+
+INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
+
+
+   weight authentication. The RMX records authorize the IP address of
+   the sending host only, not the particular sender of the message. So
+   if a machine is authorized to use sender addresses of more than a
+   single domain, the authentication scheme does not prevent that any
+   user on this machine can send with any of these domains. RMX is not
+   a substitute for the host security of the involved machines.
+
+   The proposed authentication scheme can be seen as a "half way
+   authentication": It does not track back an e-mail to the effective
+   sender. It tracks only half of the way, i. e. it tracks back to the
+   domain and it's DNS administrators who authorized that particular
+   sender IP address to use it for sending e-mail. How the party
+   responsible for that domain performs user authentication, whom it
+   grants access to, how it helds people responsible for abuse, is
+   completely left as the private business of those who are in charge
+   of that domain. So this draft does not interfere with the domain's
+   individual security policy or any legislation about such policies.
+   On the other hand, the proposed authentication scheme does not give
+   any statement about the nature and quality of the domain's security
+   policy. This is an essential feature of the proposal: E-mail
+   authentication must be deployed world wide, otherwise it won't do
+   the job. Any security scheme interfering with the local
+   legislations or the domain's security policy will not be accepted
+   and can't effectively deployed. Therefore, the security policy must
+   remain the domain's private business, no matter how lousy the
+   policy might be.
+
+   In order to achieve this and to make use of the only existing world
+   wide Internet directory scheme (DNS), the approach of this proposal
+   is to just ignore the local part of the sender address (i.e. what's
+   left of the @ part) and limit view to the domain part. After all,
+   that's what we do anyway when delivering to a given address with
+   SMTP.
+
+11.1.3.  Vulnerability of DNS
+
+   DNS is an essential part of the proposed authentication scheme,
+   since it requires any directory service, and DNS is currently the
+   only one available. Unfortunately, DNS is vulnerable and can be
+   spoofed and poisoned. This flaw is commonly known and weakens many
+   network services, but for reasons beyond that draft DNS has not
+   been significantly improved yet. After the first version of this
+   draft, I received several comments who asked me not to use DNS
+   because of its lack of security. I took this into consideration,
+   but came to the conclusion that this is unfeasible: Any
+   authentication scheme linked to some kind of symbolic identity (in
+   this case the domain name) needs some kind of infrastructure and
+   trusted assignment. There are basically two ways to do it: Do it
+
+
+
+Hadmut Danisch                Experimental                     [Page 23]
+
+INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
+
+
+   yourself and trust nobody else, or let someone else do it. There
+   are methods to do it the former way, e.g. to give someone some kind
+   of authentication information after a first successful e-mail
+   exchange, e.g. some kind of cookie or special e-mail address. This
+   is certainly interesting and powerful, but it does not solve the
+   problem on a world wide scale and is far to complicated and error
+   prone for the average user, i. e. 99% of the users.
+
+   The latter method to let someone else do the symbolic name
+   assignment and create the authentication framework is well known.
+   It context of public key cryptography, this is called a Public Key
+   Infrastructure (PKI). On of the best known facts about PKIs is
+   that, until now, we don't have any covering a significant part of
+   the Internet. And we won't have any in near future. The complexity
+   is far too high, it is too expensive, and it involves cooperation
+   of every single user, which is simply unrealistic and extremely
+   error prone. So what do we have we can use? All we have is the DNS
+   and the Whois database. And we have countries who don't allow
+   cryptography. So the proposal was designed to use DNS without
+   cryptography. It does not avoid DNS because of its vulnerability,
+   it asks for a better DNS, but accepts the DNS as it is for the
+   moment. Currently there are two main threats caused by the DNS
+   weakness:
+
+      - A spammer/forger could spoof DNS in order to gain false
+        authorization to send fake e-mails.
+
+      - An attacker could spoof DNS in order to block delivery from
+        authorized machines, i. e. perform a Denial of Service attack.
+
+   The first one is rather unrealistic, because it would require an
+   average spammer to poison a significant part of the DNS servers of
+   its victims. A spammer sending messages to one million receipients
+   would need to poison at least 1-10% which is 10,000 to 100,000
+   receipient's DNS servers. This should be unfeasible in most cases.
+
+   In contrast, the second threat is a severe one. If an attacker
+   wanted to block messages from one company to another, he just needs
+   to poison the recipients DNS server with a wrong RMX record in
+   order to make the recipient's SMTP machine reject all messages. And
+   this is feasible since the attacker needs to poison only a single
+   DNS server. But does this make SMTP more vulnerable? No. Because
+   the attacker can already do even more without RMX. By poisoning the
+   sender's DNS server with wrong MX records, the attacker can also
+   block message delivery or even redirect the messages to the
+   attacker's machine, thus preventing any delivery error messages and
+   furthermore getting access to the messages.
+
+
+
+
+Hadmut Danisch                Experimental                     [Page 24]
+
+INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
+
+
+   As a consequence, e-mail delivery by SMTP requires a better DNS
+   anyway. The requirements are not significantly expanded by RMX.
+
+11.1.4.  Sneaking RMX attack?
+
+   While writing a test implementation, a certain kind of attack came
+   into my mind. I'm still not sure, whether this attack is possible
+   on any DNS server, but I believe it should be mentioned:
+
+   Imagine an unauthorized sender is sending a forged mail (e.g.
+   spam).  At connection time, before querying the RMX record, the
+   receiving MTA usually performs a PTR query for the IP address of
+   the sending MTA. If the sender has control over the authoritative
+   name server for that particular IP address, the sender could give a
+   normal PTR answer, but could append a wrong RMX, APL, or A record
+   in the additional section of the query. A subsequent RMX query
+   could receive wrong DNS data if the DNS server used by the
+   receiving MTA accepted those forged records.
+
+11.1.5.  Open SMTP relays
+
+   Open SMTP relays (i.e. machines who accept any e-mail message from
+   anyone and deliver to the world) abused by spammers are a one of
+   the main problems of spam defense and sender backtracking. In most
+   cases this problem just vanishes because foreign open relay
+   machines will not be covered by the RMX records of the forged
+   sender address. But there are two special cases:
+
+   If the spammer knows about a domain which authorizes this
+   particular machine, that domain can be used for forgery. But in
+   this case, the IP address of the relay machine and the RMX records
+   of the domain track back to the persons responsible. Both can be
+   demanded to fix the relay or remove the RMX record for this
+   machine. An open relay is a security flaw like leaving the machine
+   open for everybody to login and send random mails from inside. Once
+   the administrative persons refuse to solve the problem, they can be
+   identified as spammers and held responsible.
+
+   The second special case is when a domain authorizes all IP
+   addresses by having the network 0.0.0.0/0 in the RMX/APL record. In
+   this case, open relays don't make things worse. It's up to the
+   recipient's MTA to reject mails from domains with loose security
+   policies.
+
+11.1.6.  Unforged Spam
+
+   This proposal does not prevent spam (which is, by the way, not yet
+   exactly defined), it prevents forgery. Since spam is against law
+
+
+
+Hadmut Danisch                Experimental                     [Page 25]
+
+INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
+
+
+   and violates the recipients rights, spam depends on untracability
+   of the sender. In practice the sender forges the sender address
+   (other cases see below). This proposal is designed to detect such
+   forgeries.
+
+   However, the RMX approach is rendered ineffective, if the sender
+   doesn't forge. If the sender uses just a normal address of it's own
+   domain, this is just a plain, normal e-mail, which needs to be let
+   through. Since it is up to the human's taste whether this is spam
+   or not, there's no technical way to reliably identify this as spam.
+   But since the sender domain is known, this domain can be
+   blacklisted or legal steps can be gone into.
+
+11.1.7.  Reliability of Whois Entries
+
+   Once the RMX infrastructure gets deployed, what's the security
+   gain?  It allows to determine the domain which's DNS zone
+   authorized the sending machine. What's that good for? There are
+   some immediate uses of the domain name, e.g. in black- and
+   whitelisting. But in most cases this is just the starting point of
+   further investigations, either performed automatically before
+   message acceptance, or manually after spam has been received and
+   complainted about.
+
+   The next step after determining the domain is determining the
+   people responsible for this domain. This can sometimes be achieved
+   by querying the Whois databases. Unfortunately, many whois entries
+   are useless because they are incomplete, wrong, obsolete, or in
+   uncommon languages. Furthermore, there are several formats of
+   address informations which make it difficult to automatically
+   extract the address. Sometimes the whois entry identifies the
+   provider and not the owner of the domain. Whois servers are not
+   built for high availability and sometimes unreachable.
+
+   Therefore, a mandatory standard is required about the contents and
+   the format of whois entries, and the availability of the servers.
+   After receiving the MAIL FROM SMTP command with the sender envelope
+   address, the receiving MTA could check the RMX record and Whois
+   entry. If it doesn't point to a real human, the message could be
+   rejected and an error message like "Ask your provider to fix your
+   Whois entry" could be issued. Obviously, domain providers must be
+   held responsible for wrong entries. It might still be acceptable to
+   allow anonymous domains, i. e. domains which don't point to a
+   responsible human. But it is the receivers choice to accept e-mails
+   from such domains or not.
+
+11.1.8.  Hazards for Freedom of Speech
+
+
+
+
+Hadmut Danisch                Experimental                     [Page 26]
+
+INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
+
+
+   Currently, some governments try to enforce limitations of internet
+   traffic in order to cut unwanted content providers from the
+   network. Some of these governments try to hide a whole country
+   behind firewalls, others try to force Internet providers to poison
+   DNS servers with wrong A records for web servers, e.g. one county
+   administration in Germany tries to do so. If message reception
+   depends on DNS entries, the same governments will try to block not
+   only HTTP, but SMTP also.
+
+   However, since most MTAs already reject messages from unresolvable
+   domain names this is not a new threat.
+
+11.2.  General Considerations about spam defense
+
+   After discussing security requirements of the proposal, now the
+   security advantages of the RMX approach over content based filters
+   will be explained. Basically, there are three kinds of content
+   filters:
+
+      - Those who upload the message or some digest to an external
+        third party and ask "Is this spam"?
+
+      - Those who download a set of patterns and rules from a third
+        party and apply this set to incoming messages in order to
+        determine whether it is spam.
+
+      - Those who are independent and don't contact any third party,
+        but try to learn themselves what is spam and what isn't.
+
+
+   The message filters provided by some e-mail service providers are
+   usually not a kind of their own, but a combination of the first two
+   kinds.
+
+11.2.1.  Action vs. reaction
+
+   Content filters suffer from a fundamental design problem: They are
+   late. They need to see some content of the same kind before in
+   order to learn and to block further distribution.
+
+   This works for viruses and worms, which redistribute. This doesn't
+   work for spam, since spam is usually not redistributed after the
+   first delivery. When the filters have learned or downloaded new
+   pattern sets, it's too late.
+
+   This proposal does not have this problem.
+
+11.2.2.  Content based Denial of Service attacks
+
+
+
+Hadmut Danisch                Experimental                     [Page 27]
+
+INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
+
+
+   All three kinds of content filters, but especially the second and
+   the third kind are vulnerable to content based Denial of Service
+   attacks.
+
+   If some kind of third party (e.g. non-democratic government,
+   intellectual property warriors, religious groups, military, secret
+   services, patriots, public relation agents, etc.) wants certain
+   contents not to be distributed, they could either poison the
+   pattern/rule databases or feed wrong sets to particular receivers.
+
+   Such pattern/rule sets are the perfect tool for censoring e-mail
+   traffic and denial of service attacks by governments and other
+   parties, and a similar threat are virus filters. E. g. the content
+   industry could demand to teach all virus and spam filters to delete
+   all e-mails containing the URL of an MP3 web server outside the
+   legislations. Software manufacturers could try to block all e-mails
+   containing software license keys, thus trying to make unallowed
+   distribution more difficult. Governments could try to block
+   distribution of unwanted informations.
+
+   This proposal does not have this problem.
+
+
+12.  Privacy Considerations
+
+   (It was proposed on the 56th IETF meeting to have a privacy section
+   in drafts and RFCs.)
+
+12.1.  Draft specific considerations
+
+12.1.1.  No content leaking
+
+   Since the RMX approach doesn't touch the contents of a message in
+   any way, there is obviously no way of leaking out any information
+   about the content of the message. RMX is based solely on the
+   envelope recipient address. However, methods to fix problems not
+   covered by RMX might allow content leaking, e.g. if the acceptance
+   of a message with an empty sender address requires the reference to
+   the message id of an e-mail recently sent, this allows an attacker
+   to verify whether a certain message was delivered from there.
+
+12.1.2.  Message reception and sender domain
+
+   Message delivery triggers RMX and APL requests by the recipient.
+   Thus, the admin of the DNS server or an eavesdropper could learn
+   that the given machine has just received a message with a sender
+   from this address, even if the SMTP traffic itself had been
+   encrypted.
+
+
+
+Hadmut Danisch                Experimental                     [Page 28]
+
+INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
+
+
+   However, most of today's MTAs do query the MX and A records of the
+   domain after the MAIL FROM command, so this is not a real new
+   threat.
+
+12.1.3.  Network structure
+
+   Since RMX and its associated APL records provide a complete list of
+   all IP addresses of hosts authorized to send messages from this
+   address, they do reveal informations about the network structure
+   and maybe the lifestyle of the domain owner, since a growing number
+   of domains are owned by single persons or families. E.g. the RMX
+   records could reveal where someone has his job or spends his time
+   at weekends.
+
+   If such informations are to be kept secret, it is the user's job to
+   not sent e-mails from there and to relay them from non-compromising
+   IP addresses.
+
+12.1.4.  Owner information distribution
+
+   As described above, RMX depends partly on the reliability of the
+   whois database entries. It does not make anonymous domains
+   impossible, but it requires to keep the database entries "true", i.
+   e. if a whois entry does not contain informations about the
+   responsible person, this must be unambigously labeled as anonymous.
+   It must not contain fake names and addresses to pretend a non-
+   existing person. However, since most Internet users on the world
+   feel extremely annoyed by spam, they will urge their MTA admin to
+   reject messages from anonymous domains. The domain owner will have
+   the choice to either remain anonymous but be not able to send e-
+   mail to everyone in the world, or to be able but to reveal his
+   identity to everyone on the world.
+
+   It would be possible to provide whois-like services only to
+   recipients of recent messages, but this would make things too
+   complicated to be commonly adopted.
+
+12.2.  General Considerations about spam defense
+
+12.2.1.  Content leaking of content filters
+
+   As described above in the Security chapter, there are spam filters
+   which inherently allow leakage of the message body. Those filters
+   upload either the message body, or in most cases just some kind of
+   checksum to a third party, which replies whether this is to be seen
+   as spam or not. The idea is to keep a databases of all digests of
+   all messages.  If a message is sent more often than some threshold,
+   it is to be considered as a mass mail and therefore tagged as spam.
+
+
+
+Hadmut Danisch                Experimental                     [Page 29]
+
+INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
+
+
+   While the digest itself does not reveal the content of the message,
+   it perfectly reveals where a particular message has been delivered
+   to. If a government finds just a single unwanted message, if a
+   software manufacturer finds a single message with a stolen product
+   license key, if someone finds a message with unpatriotic content,
+   it takes just a single database lookup to get a list of all people
+   who received this particular message. Content filters with digest
+   upload are the perfect "Big Brother".
+
+12.2.2.  Black- and Whitelists
+
+   Some proposals against spam are based on a central database of
+   white- or blacklisted IP addresses, Sender names, Message IDs or
+   whatever. Again, there is a central database which learns who has
+   received which e-mail or from which sender with every query. This
+   allows tracking relations between persons, which is also a breach
+   of privacy.
+
+
+
+13.  Deployment Considerations
+
+13.1.  Compatibility
+
+13.1.1.  Compatibility with old mail receivers
+
+   Since the suggested extension doesn't change the SMTP protocol at
+   all, it is fully compatible with old mail receivers. They simply
+   don't ask for the RMX records and don't perform the check.
+
+13.1.2.  Compatibility with old mail senders
+
+   Since the SMTP protocol is unchanged and the SMTP sender is not
+   involved in the check, the method is fully compatible with old mail
+   senders.
+
+13.1.3.  Compatibility with old DNS clients
+
+   Since the RMX is a new RR, the existing DNS protocol and zone
+   informations remain completely untouched.
+
+   If RMX is provided as a TXT record instead, it must be ensured that
+   no other software is misinterpreting this entry.
+
+13.1.4.  Compatibility with old DNS servers
+
+   Full compatibility: If the server does not support RMX records, RMX
+   in TXT records can be used.
+
+
+
+Hadmut Danisch                Experimental                     [Page 30]
+
+INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
+
+
+13.2.  Enforcement policy
+
+   Obviously, for reasons of backward compatibility and smooth
+   introduction of this scheme, RMX records can't be required
+   immediately. Domains without RMX records must temporarily be
+   treated the same way as they are treated right now, i.e. e-mail
+   must be accepted from anywhere. But once the scheme becomes
+   sufficiently widespread, mail relays can start to refuse e-mails
+   with sender addresses from domains without RMX records, thus
+   forcing the owner of the domain to include a statement of
+   authorization into the domain's zone table.  Domain owners will
+   still be free to have an RMX record with a network and mask
+   0.0.0.0/0, i.e. to allow e-mails with that domain from everywhere.
+   On the other hand, mail receivers will be free to refuse mails from
+   domains without RMX records or RMX records which are too loose.
+   Advanced MTAs might have a configuration option to set the maximum
+   number of IP addresses authorized to use a domain. E-mails from a
+   domain, which's RMX records exceed this limit, would be rejected.
+   For example, a relay could reject e-mails from domains which
+   authorize more than 8 IP addresses. That allows to accept e-mails
+   only from domains with a reasonable security policy.
+
+
+
+14.  General considerations about fighting spam
+
+   Is there a concise technical solution against spam? Yes.
+
+   Will it be deployed? Certainly not.
+
+   Why not? Because of the strong non-technical interests of several
+   parties against a solution to the problem, as described below.
+   Since these are non-technical reasons, they might be beyond the
+   scope of such a draft. But since they are the main problems that
+   prevent fighting spam, it is unavoidable to address them. This
+   chapter exists temporarily only and should support the discussion
+   of solutions. It is not supposed to be included in a later RFC.
+
+14.1.  The economical problem
+
+   As has been recently illustrated in the initial session of the
+   IRTF's Anti Spam Research Group (ASRG) on the 56th IETF meeting,
+   sending spam is a business with significant revenues.
+
+   But a much bigger business is selling Anti-Spam software. This is a
+   billion dollar market, and it is rapidly growing. Any simple and
+   effective solution against spam would defeat revenues and drive
+   several companies into bankrupt, would make consultants jobless.
+
+
+
+Hadmut Danisch                Experimental                     [Page 31]
+
+INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
+
+
+   Therefore, spam is essential for the Anti-Spam business. If there
+   is no spam, then no Anti-Spam software can be sold, similar to the
+   Anti-Virus business. There are extremely strong efforts to keep
+   this market growing. Viruses, Worms, and now spam are just perfect
+   to keep this market alive: It is not sufficient to just buy a
+   software. Databases need to be updated continuously, thus making
+   the cash flow continuously. Have a single, simple, and permanent
+   solution to the problem and - boom - this billion dollar market is
+   dead.
+
+   That's one of the reasons why people are expected to live with
+   spam. They have to live with it to make them buy Anti-Spam
+   software.  Content filters are perfect products to keep this market
+   alive.
+
+14.2.  The POP problem
+
+   Another problem is the history of mail delivery. Once upon a time,
+   there used to be very few SMTP relays which handled the e-mail
+   traffic of all the world, and everybody was happy with that. Then
+   odd things like Personal Computers, which are sometimes switched
+   off, portable computers, dynamicly assigned IP addresses, IP access
+   from hotel rooms, etc. was invented, and people became unhappy,
+   because SMTP does not support delivery to such machines. To make
+   them happy again, the Post Office Protocol[4] was invented, which
+   turned the last part of message delivery from SMTP's push style
+   into a pull style, thus making virtually every computer on the
+   world with any random IP address a potential receiver of mails for
+   random domains. Unfortunately, only receiving e-mail was covered,
+   but sending e-mail was left to SMTP.
+
+   The result is that today we have only very few SMTP relays pointed
+   to by MX records, but an extreme number of hosts sending e-mail
+   with SMTP from any IP address with sender addresses from any
+   domain. Mail delivery has become very asymmetric. Insecurity,
+   especially forgeability, has become an essential part of mail
+   transport.
+
+   That problem could easily be fixed: Use protocols which allow
+   uploading of messages to be delivered. If a host doesn't receive
+   messages by SMTP, it shouldn't deliver by SMTP.  Mail delivery
+   should go the same way back that incoming mail went in.  This is
+   not a limitation to those people on the road who plug their
+   portable computer in any hotel room's phone plug and use any
+   provider. If there is a POP server granting download access from
+   anywhere, then the same server should be ready to accept uploading
+   of outgoing messages.
+
+
+
+
+Hadmut Danisch                Experimental                     [Page 32]
+
+INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
+
+
+   But as I saw from the comments on the first version of this draft,
+   people religiously insist on sending e-mail with their domain from
+   any computer with any IP address in the world, e.g. when visiting a
+   friend using her computer. It appears to be impossible to convince
+   people that stopping mail forgery requires every one of them to
+   give up forging.
+
+14.3.  The network structure problem
+
+   A subsequent problem is that many organisations failed to implement
+   a proper mail delivery structure and heavily based their network on
+   this asymmetry. I received harsh comments from Universities who
+   were unable to give their network a good structure. While they do
+   have a central mail relay for incoming mail to the universities
+   domain, they developed a structure where every member of the
+   University randomly sends e-mails with that University's domain as
+   a sender address from home or everywhere in the world with any
+   dynamically assigned IP address from any provider. So this domain
+   is to be used from every possible IP address on earth, and they are
+   unable to operate any authentication scheme. Furthermore, they were
+   unable to understand that such a policy heavily supports spam and
+   that they have to expect that people don't accept such e-mails
+   anymore once they become blacklisted.
+
+   As long as organisations insist on having such policies, spammers
+   will have a perfect playground.
+
+14.4.  The mentality problem
+
+   Another problem is the mentality of many internet users of certain
+   countries. I received harsh comments from people who strongly
+   insisted on the freedom to send any e-mail with any sender address
+   from anywhere, and who heavily refused any kind of authentication
+   step or any limitation, because they claimed that this would
+   infringe their constitutional "Freedom of speech". They are
+   undeviatingly convinced that "Freedom of speech" guarantees their
+   right to talk to everybody with any sender address, and that is has
+   to be kept the recipient's own problem to sort out what he doesn't
+   want to read - on the recipient's expense.
+
+   It requires a clear statement that the constitutional "Freedom of
+   Speech" does not cover molesting people with unsolicited e-mail
+   with forged sender address.
+
+14.5.  The identity problem
+
+   How does one fight against mail forgery? With authentication.  What
+   is authentication? In simple words: Making sure that the sender's
+
+
+
+Hadmut Danisch                Experimental                     [Page 33]
+
+INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
+
+
+   real identity meets the recipients idea of who is the sender, based
+   on the sender address which came with the message.
+
+   What is identity? It is the main problem. Several countries have
+   different ideas of "identity", which turn out to be somehow
+   incompatible. In some countries people have identity cards and
+   never change their name and birthday. Identities are created by
+   human birth, not by identity changes. Other countries do not have
+   such a tight idea about identity. People's temporary identity is
+   based on nothing more than a driving license and a social security
+   number.  With this background, it is virtually impossible to create
+   a trustworthy PKI covering all Internet users. I learned that it is
+   extremely difficult to convince some people to give up random e-
+   mail sending.
+
+14.6.  The multi-legislation problem
+
+   Many proposals about fighting spam are feasible under certain
+   legislations only, and are inacceptable under some of the
+   legislations. But a world wide applicable method is required.
+   That's why the approach to ask everone on the world to sign
+   messages with cryptographic keys is not feasible.
+
+
+Implementation and further Information
+
+   Further informations and a test implementation are available at
+
+      http://www.danisch.de/work/security/antispam.html
+      http://www.danisch.de/software/rmx/
+
+
+   Additional informations and a technology overview are also
+   available at
+
+      http://www.mikerubel.org/computers/rmx_records/
+
+
+References
+
+
+
+1.   S. Bradner, "Key words for use in RFCs to Indicate Requirement Lev-
+     els," RFC 2119 (March 1997).
+
+2.   J. Klensin, "Simple Mail Transfer Protocol," RFC 2821 (April 2001).
+
+
+
+
+
+Hadmut Danisch                Experimental                     [Page 34]
+
+INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
+
+
+3.   P. Mockapetris, "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION,"
+     RFC 1035 (November 1987).
+
+4.   J. Myers, M. Rose, "Post Office Protocol - Version 3," RFC 1939
+     (May 1996).
+
+
+Draft History
+
+   00  Dec 2002
+   01  Apr 2003
+   02  Jun 2003
+   03  Oct 2003
+
+Author's Address
+
+   Hadmut Danisch
+
+   Tennesseeallee 58
+   76149 Karlsruhe
+   Germany
+
+   Phone:  ++49-721-843004 or ++49-351-4850477
+   E-Mail: rfc@danisch.de
+
+Comments
+
+   Please send comments to rfc@danisch.de.
+
+Expiry
+
+   This drafts expires on Apr 1, 2004.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hadmut Danisch                Experimental                     [Page 35]
+
diff --git a/doc/draft/draft-dnsext-opcode-discover-02.txt b/doc/draft/draft-dnsext-opcode-discover-02.txt
new file mode 100644
index 0000000..7b5e8cc
--- /dev/null
+++ b/doc/draft/draft-dnsext-opcode-discover-02.txt
@@ -0,0 +1,241 @@
+
+IETF DNSEXT WG                                             Bill Manning
+draft-dnsext-opcode-discover-02.txt                              ep.net
+                                                             Paul Vixie
+                                                                    ISC
+                                                            13 Oct 2003
+
+
+                         The DISCOVER opcode
+
+This document is an Internet-Draft and is subject to all provisions of
+Section 10 of RFC2026.
+
+Comments may be submitted to the group mailing list at "mdns@zocalo.net"
+or the authors.
+
+Distribution of this memo is unlimited.
+
+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 draft documents 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 "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/ietf/1id-abstracts.txt
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+The capitalized keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+document are to be interpreted as described in RFC 2119
+
+0. Abstract:
+
+   The QUERY opcode in the DNS is designed for unicast. With the
+   development of multicast capabilities in the DNS, it is desireable
+   to have a more robust opcode for server interactions since a single
+   request may generate replies from multiple responders. So DISCOVER
+   is defined to deal with replies from multiple responders.
+
+   As such, this document extends the core DNS specifications to allow
+   clients to have a method for coping with replies from multiple
+   responders. Use of this new opcode may facilitate DNS operations in
+   modern networking topologies. A prototype of the DISCOVER opcode
+   was developed during the TBDS project (1999-2000), funded under DARPA
+   grant F30602-99-1-0523.
+
+1. Introduction:
+
+   This document describes an experimental extension to the DNS to receive
+   multiple responses which is the likely result when using DNS that has
+   enabled multicast queries.  This approach was developed as part of the
+   TBDS research project, funded under DARPA grant F30602-99-1-0523.  The
+   full processing rules used by TBDS are documented here for possible
+   incorporation in a future revision of the DNS specification."
+
+2. Method:
+
+        DISCOVER works like QUERY except:
+
+        1. it can be sent to a broadcast or multicast destination. QUERY
+           isn't defined for non-unicast, and arguably shouldn't be.
+
+        2. the Question section, if present, has <QNAME=zonename,QTYPE=SOA>
+           tuples. TBDS tried to augment this structure as follows:
+           <QNAME=service,QTYPE=SRV>. While this worked for our purposes in
+           TBDS, it is cleaner to place the SRV question in a separate pass.
+
+        3. if QDCOUNT equals 0 then only servers willing to do recursion should
+           answer. Other servers must silently discard the DISCOVER request.
+
+        4. if QDCOUNT is not equal to 0 then only servers who are authoritative
+           for the zones named by some QNAME should answer.
+
+        5. responses may echo the request's Question section or leave it blank,
+           just like QUERY.
+
+        6. responses have standard Answer, Authority, and Additional sections.
+           e.g. the response is the same as that to a QUERY. It is desireable
+           that zero content answers not be sent to avoid badly formed or
+           unfulfilled requests. Responses should be sent to the unicast
+           address of the requester and the source address should reflect
+           the unicast address of the responder.
+
+   Example usage for gethostby{name,addr}-style requestors:
+
+        Compute the zone name of the enclosing in-addr.arpa, ip6.int, or
+        ip6.arpa domain.
+
+        DISCOVER whether anyone in-scope is authoritative for this zone.
+
+                If so, query these authoritative servers for local
+                in-addr/ip6 names.
+
+        If not, DISCOVER whether there are recursive servers available.
+
+                If so, query these recursive servers for local
+                in-addr/ip6 names.
+
+        So, a node will issue a multicast request with the DISCOVER opcode at
+        some particular multicast scope.  Then determine, from the replies,
+        whether there are any DNS servers which are authoritative (or support
+        recursion) for the zone. Replies to DISCOVER requests MUST set the
+        Recursion Available (RA) flag in the DNS message header.
+
+        It is important to recognize that a requester must be prepared to
+        receive multiple replies from multiple responders. We expect that
+        there will be a single response per responder.
+
+        Once one learns a host's FQDN by the above means, repeat the process
+        for discovering the closest enclosing authoritative server of such
+        local name.
+
+        Cache all NS and A data learned in this process, respecting TTL's.
+
+   TBDS usage for SRV requestors:
+
+        Do the gethostbyaddr() and gethostbyname() on one's own link-local
+        address, using the above process.
+
+        Assume that the closest enclosing zone for which an authority server
+        answers an in-scope DISCOVER packet is "this host's parent domain".
+
+        Compute the SRV name as _service._transport.*.parentdomain.
+
+        This is a change to the definition as defined in RFC 1034.
+        A wildcard label ("*") in the QNAME used in a DNS message with
+        opcode DISCOVER SHOULD be evaluated with special rules.  The
+        wildcard matches any label for which the DNS server data is
+        authoritative.  For example 'x.*.example.com.' would match
+        'x.y.example.com.' and 'x.yy.example.com.' provided that the
+        server was authoritative for 'example.com.'  In this particular
+        case, we suggest the follwing considerations be made:
+
+   getservbyname() can be satisfied by issuing a request with
+   this computed SRV name.  This structure can be
+   populated by values returned from a request as follows:
+
+        s_name    The name of the service, "_service" without the
+                  preceding underscore.
+        s_aliases The names returned in the SRV RRs in replies
+                  to the query.
+        s_port    The port number in the SRV RRs replies to the
+                  query.  If these port numbers disagree - one
+                  of the port numbers is chosen, and only those
+                  names which correspond are returned.
+        s_proto   The transport protocol from named by the
+                  "_transport" label, without the preceding
+                  underscore.
+
+        Send SRV query for this name to discovered local authoritative servers.
+
+     Usage for disconnected networks with no authoritative servers:
+
+        Hosts should run a "stub server" which acts as though its FQDN is a
+        zone name.  Computed SOA gives the host's FQDN as MNAME, "." as the
+        ANAME, seconds-since-1Jan2000 as the SERIAL, low constants for EXPIRE
+        and the other timers.  Compute NS as the host's FQDN.  Compute the
+        glue as the host's link-local address. Or Hosts may run a
+        "DNS stub server" which acts as though its FQDN is a zone name.  The
+        rules governing the behavior of this stub server are given elsewhere
+        [1] [2].
+
+        Such stub servers should answer DISCOVER packets for its zone, and
+        will be found by the iterative "discover closest enclosing authority
+        server" by DISCOVER clients, either in the gethostbyname() or SRV
+        cases described above.  Note that stub servers only answer with
+        zone names which exactly match QNAME's, not with zone names which
+        are owned by QNAME's.
+
+   The main deviation from the DNS[3][4] model is that a host (like, say, a
+   printer offering LPD services) has a DNS server which answers authoritatively
+   for something which hasn't been delegated to it.  However, the only way that
+   such DNS servers can be discovered is with a new opcode, DISCOVER, which
+   is explicitly defined to discover undelegated zones for tightly scoped
+   purposes.  Therefore this isn't officially a violation of DNS's coherency
+   principles. In some cases a responder to DISCOVER may not be traditional
+   DNS software, it could be special purpose software.
+
+3. IANA Considerations
+
+        As a new opcode, the IANA will need to assign a numeric value
+        for the memnonic. The last OPCODE assigned was "5", for UPDATE.
+        Test implementations have used OPCODE "6".
+
+4. Security Considerations
+
+        No new security considerations are known to be introduced with any new
+        opcode, however using multicast for service discovery has the potential
+        for denial of service, primarly from flooding attacks. It may also be
+        possible to enable deliberate misconfiguration of clients simply by
+        running a malicious DNS resolver that claims to be authoritative for
+        things that it is not. One possible way to mitigate this effect is by
+        use of credentials, such as CERT resource records within an RR set.
+        The TBDS project took this approach.
+
+5. Attribution:
+
+        This material was generated in discussions on the mdns mailing list
+hosted by Zocalo in March 2000. Updated by discussion in September/October
+2003.  David Lawrence, Scott Rose, Stuart Cheshire, Bill Woodcock,
+Erik Guttman, Bill Manning and Paul Vixie were active contributors.
+
+6. Author's Address
+
+   Bill Manning
+   PO 12317
+   Marina del Rey, CA. 90295
+   +1.310.322.8102
+   bmanning@karoshi.com
+
+   Paul Vixie
+   Internet Software Consortium
+   950 Charter Street
+   Redwood City, CA 94063
+   +1 650 779 7001
+   <vixie@isc.org>
+
+7. References
+
+Informational References:
+
+[1]  Esibov, L., Aboba, B., Thaler, D., "Multicast DNS",
+        draft-ietf-dnsext-mdns-00.txt, November 2000. Expired
+
+[2] Woodcock, B., Manning, B., "Multicast Domain Name Service",
+        draft-manning-dnsext-mdns-00.txt,  August 2000.  Expired.
+
+Normative References:
+[3]  Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES",
+        RFC 1034, November 1987.
+[4]  Mockapetris, P., "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION",
+        RFC 1035, November 1987
+
+        ----------------------------EOL-----------------------
+
diff --git a/doc/draft/draft-durand-dnsop-dynreverse-00.txt b/doc/draft/draft-durand-dnsop-dynreverse-00.txt
new file mode 100644
index 0000000..224e7ad1
--- /dev/null
+++ b/doc/draft/draft-durand-dnsop-dynreverse-00.txt
@@ -0,0 +1,240 @@
+Internet Engineering Task Force                             Alain Durand
+INTERNET-DRAFT                                          SUN Microsystems
+Feb 21, 2003
+Expires Aug 2, 2003
+
+
+
+                Dynamic reverse DNS for IPv6
+              <draft-durand-dnsop-dynreverse-00.txt>
+
+
+
+Status of this memo
+
+
+   This memo provides information to the Internet community.  It does
+   not specify an Internet standard of any kind.  This memo is in full
+   conformance with all provisions of Section 10 of RFC2026 [RFC2026].
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/ietf/1id-abstracts.txt
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+
+
+Abstract
+
+   This document describes a method to dynamically generate PTR records
+   and corresponding A or AAAA records when the reverse path DNS tree is
+   not populated.
+
+   A special domain dynrev.arpa. is reserved for that purpose.
+
+
+1. Introduction
+
+   In IPv4, the reverse path tree of the DNS under in-addr.arpa.
+   although not perfectly maintained, is still mostly usable and its
+   existence is important for a number of applications that relies on
+   its existence and decent status.  Some applications performs some
+   (very) weak security checks based on it. Mail relays relies on it for
+   some anti-spams checks an some FTP server will not let you in unless
+   your IP address resolve properly with a PTR record.
+
+   IPv6 addresses being much longer (and cumbersome) than IPv4
+   addresses, it is to fear that the reverse path tree under ip6.arpa.
+   would not be as well maintained.  Also, tools like 6to4, Isatap and
+   others have made creative use of the 128 bits of an IPv6 address to
+   automatically embed an IPv4 address to enable seamless connection to
+   the IPv6 Internet. However, no provision has been made to make sure
+   the reverse path tree gets automatically updated as well for those
+   new IPv6 addresses.  One step furter, RFC3041 describes a mechanism
+   to basically use random bits in the bottom part of an IPv6 address to
+   preserver anonymity. If those addresses are to resolve in the reverse
+   path tree, it obviously has to be with anonymous data as well.
+   Another point to note is that home customer ISPs in IPv4 have a
+   current practice to pre-populate the reverse path tree with names
+   automatically derived from the IP addresses. This practice is no
+   longer possible in IPv6, where IP address allocation is not dense as
+   it is the case in IPv4. The mere size of typical customer allocation
+   (2^48 according to the recommendation of RFC3177) makes it
+   impossible.
+
+   Applications that check the existence of PTR records usually follow
+   this by checking if the name pointed by the PTR resolve in a A (or
+   AAAA for IPv6) that match the original IP address. Thus the forward
+   path tree must also include the corresponding data.
+
+   One simple approach of this problem is to simply declare the usage of
+   the reverse path DNS as described above obsolete.  The author believe
+   this is too strong an approach for now.
+
+   Similarly, a completely different approach would be to deprecate the
+   usage of DNS for the reverse tree altogether and replace it by
+   something inspired from ICMP name-info messages. The author believes
+   that this approached is an important departure from the current
+   practise and thus not very realistic.  Also, there are some concerns
+   about the the security implications of this method as any node could
+   easily impersonate any name. This approach would fundamentally change
+   the underlying assumption of "I trust what has been put in the DNS by
+   the local administrators" to "I trust what has been configured on
+   each machine I query directly".
+
+
+
+2. Dynamic record generation
+
+   If static pre-population of the tree is not possible anymore and data
+   still need to be returned to applications using getnameinfo(), the
+   alternative is dynamic record generation.  This can be done is two
+   places: in the DNS servers responsible for the allocated space (/64
+   or /48) in the ip6.arpa. domain.  or in the DNS resolvers (either the
+   sub resolver library or the recursive DNS server).
+
+   2.1. On the resolver side.
+
+   The resolver, either in the recursive DNS server or in the stub
+   library could theoretically generate this data.
+
+   In case DNSsec is in place, the recursive DNS server would have to
+   pretend these records are authentic.
+
+   If the synthesis is done in the stub-resolver library, no record
+   needs to be actually generated, only the right information needs to
+   be passed to getnameinfo() and getaddrinfo().  If the synthesis is
+   done in the recursive DNS server, no modification is required to
+   existing stub resolvers.
+
+
+2.2. On the server side.
+
+   PTR records could be generated automatically by the server
+   responsible for the reverse path tree of an IPv6 prefix (a /64 or /48
+   prefixes or basically anything in between) when static data is not
+   available.
+
+   There could be impact on DNSsec as the zone or some parts of the zone
+   may need to be resigned each time a DNS query is made for an
+   unpopulated address. This can be seen as a DOS attack on a DNSsec
+   zone, so server side synthesis is not recommended if DNSsec is
+   deployed.
+
+
+
+3. Synthesis
+
+   The algorithm is simple: Do the normal queries. If the query returns
+   No such domain, replace this answer by the synthetized one if
+   possible.
+
+3.1. PTR synthesis
+
+   The synthetized PTR for a DNS string [X] is simply [X].dynrev.arpa.
+   where [X] is any valid DNS name.
+
+   The fact that the synthetized PTR points to the dynrev.arpa. domain
+   is an indication to the applications that this record has been
+   dynamically generated.
+
+
+3.2. A synthesis
+
+   If [X] is in the form a.b.c.d.in-addr.arpa, one can synthetized an A
+   record for the string [X].dynrev.arpa. which value is d.c.b.a. with
+   a,b,c & d being integer [0..255]
+
+
+3.3. AAAA synthesis
+
+   If [X] is in the form
+   a.b.c.d.e.f.g.h.i.j.k.l.m.n.o.p.q.s.t.u.v.w.x.y.z.A.B.C.D.E.F.in-
+   addr.arpa, one can synthetized a AAAA record for the string
+   [X].dynrev.arpa. which value is
+   FEDC:BAzy:xwvu:tsrq:ponm:lkji:hgfe:dcba with
+   a,b,c....x,y,z,A,B,C,D,E,F being hexadecimal digits.
+
+
+3.4. Server side synthesis
+
+   If synthesis is done on the server side, PTR could be set not to use
+   the dynrev.arpa domain but the local domain name instead.  It culd be
+   for instance dynrev.mydomain.com.
+
+   Note also that server side synthesis is not incompatible with
+   resolver side synthesis.
+
+
+
+4. IANA considerations
+
+   The dynrev.arpa. domain is reserved for the purpose of this document.
+
+
+
+5. Security considerations
+
+   Section 2. discusses the the interactions with DNSsec.
+
+
+
+6. Authors addresses
+
+   Alain Durand
+   SUN Microsystems, Inc
+   17, Network Circle
+   UMPK17-202
+   Menlo Park, CA 94025
+   USA
+   Mail: Alain.Durand@sun.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/doc/draft/draft-ietf-dnsext-2929bis-01.txt b/doc/draft/draft-ietf-dnsext-2929bis-01.txt
new file mode 100644
index 0000000..fa41e76
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsext-2929bis-01.txt
@@ -0,0 +1,928 @@
+
+INTERNET-DRAFT                                    Donald E. Eastlake 3rd
+Obsoletes RFC 2929, Updates RFC 1183               Motorola Laboratories
+Expires: February 2006                                       August 2005
+
+
+
+              Domain Name System (DNS) IANA Considerations
+              ------ ---- ------ ----- ---- --------------
+                   <draft-ietf-dnsext-2929bis-01.txt>
+
+
+
+Status of This Document
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   Distribution of this draft is unlimited.  It is intended to become
+   the new BCP 42 obsoleting RFC 2929.  Comments should be sent to the
+   DNS Working Group mailing list <namedroppers@ops.ietf.org>.
+
+   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 draft documents 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 a "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/1id-abstracts.html
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html
+
+
+
+Abstract
+
+   Internet Assigned Number Authority (IANA) parameter assignment
+   considerations are given for the allocation of Domain Name System
+   (DNS) classes, RR types, operation codes, error codes, RR header
+   bits, and AFSDB subtypes.
+
+
+
+
+
+
+
+
+D. Eastlake 3rd                                                 [Page 1]
+
+
+INTERNET-DRAFT           DNS IANA Considerations             August 2005
+
+
+Table of Contents
+
+      Status of This Document....................................1
+      Abstract...................................................1
+
+      Table of Contents..........................................2
+
+      1. Introduction............................................3
+      2. DNS Query/Response Headers..............................3
+      2.1 One Spare Bit?.........................................4
+      2.2 Opcode Assignment......................................4
+      2.3 RCODE Assignment.......................................5
+      3. DNS Resource Records....................................6
+      3.1 RR TYPE IANA Considerations............................7
+      3.1.1 DNS TYPE Allocation Policy...........................8
+      3.1.2 Special Note on the OPT RR...........................9
+      3.1.3 The AFSDB RR Subtype Field...........................9
+      3.2 RR CLASS IANA Considerations...........................9
+      3.3 RR NAME Considerations................................11
+      4. Security Considerations................................11
+
+      Appendix: Changes from RFC 2929...........................12
+
+      Copyright and Disclaimer..................................13
+      Normative References......................................13
+      Informative References....................................14
+
+      Authors Addresses.........................................16
+      Expiration and File Name..................................16
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+D. Eastlake 3rd                                                 [Page 2]
+
+
+INTERNET-DRAFT           DNS IANA Considerations             August 2005
+
+
+1. Introduction
+
+   The Domain Name System (DNS) provides replicated distributed secure
+   hierarchical databases which hierarchically store "resource records"
+   (RRs) under domain names.  DNS data is structured into CLASSes and
+   zones which can be independently maintained.  See [RFC 1034, 1035,
+   2136, 2181, 4033] familiarity with which is assumed.
+
+   This document provides, either directly or by reference, general IANA
+   parameter assignment considerations applying across DNS query and
+   response headers and all RRs.  There may be additional IANA
+   considerations that apply to only a particular RR type or
+   query/response opcode.  See the specific RFC defining that RR type or
+   query/response opcode for such considerations if they have been
+   defined, except for AFSDB RR considerations [RFC 1183] which are
+   included herein. This RFC obsoletes [RFC 2929].
+
+   IANA currently maintains a web page of DNS parameters.  See
+   <http://www.iana.org/numbers.htm>.
+
+   "IETF Standards Action", "IETF Consensus", "Specification Required",
+   and "Private Use" are as defined in [RFC 2434].
+
+
+
+2. DNS Query/Response Headers
+
+   The header for DNS queries and responses contains field/bits in the
+   following diagram taken from [RFC 2136, 2929]:
+
+                                              1  1  1  1  1  1
+                0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
+               +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+               |                      ID                       |
+               +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+               |QR|   Opcode  |AA|TC|RD|RA| Z|AD|CD|   RCODE   |
+               +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+               |                QDCOUNT/ZOCOUNT                |
+               +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+               |                ANCOUNT/PRCOUNT                |
+               +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+               |                NSCOUNT/UPCOUNT                |
+               +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+               |                    ARCOUNT                    |
+               +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+   The ID field identifies the query and is echoed in the response so
+   they can be matched.
+
+   The QR bit indicates whether the header is for a query or a response.
+
+
+D. Eastlake 3rd                                                 [Page 3]
+
+
+INTERNET-DRAFT           DNS IANA Considerations             August 2005
+
+
+   The AA, TC, RD, RA, AD, and CD bits are each theoretically meaningful
+   only in queries or only in responses, depending on the bit.  However,
+   many DNS implementations copy the query header as the initial value
+   of the response header without clearing bits.  Thus any attempt to
+   use a "query" bit with a different meaning in a response or to define
+   a query meaning for a "response" bit is dangerous given existing
+   implementation.  Such meanings may only be assigned by an IETF
+   Standards Action.
+
+   The unsigned fields query count (QDCOUNT), answer count (ANCOUNT),
+   authority count (NSCOUNT), and additional information count (ARCOUNT)
+   express the number of records in each section for all opcodes except
+   Update.  These fields have the same structure and data type for
+   Update but are instead the counts for the zone (ZOCOUNT),
+   prerequisite (PRCOUNT), update (UPCOUNT), and additional information
+   (ARCOUNT) sections.
+
+
+
+2.1 One Spare Bit?
+
+   There have been ancient DNS implementations for which the Z bit being
+   on in a query meant that only a response from the primary server for
+   a zone is acceptable.  It is believed that current DNS
+   implementations ignore this bit.
+
+   Assigning a meaning to the Z bit requires an IETF Standards Action.
+
+
+
+2.2 Opcode Assignment
+
+   Currently DNS OpCodes are assigned as follows:
+
+          OpCode Name                      Reference
+
+           0     Query                     [RFC 1035]
+           1     IQuery  (Inverse Query, Obsolete) [RFC 3425]
+           2     Status                    [RFC 1035]
+           3     available for assignment
+           4     Notify                    [RFC 1996]
+           5     Update                    [RFC 2136]
+          6-15   available for assignment
+
+   New OpCode assignments require an IETF Standards Action as modified
+   by [RFC 4020].
+
+
+
+
+
+
+D. Eastlake 3rd                                                 [Page 4]
+
+
+INTERNET-DRAFT           DNS IANA Considerations             August 2005
+
+
+2.3 RCODE Assignment
+
+   It would appear from the DNS header above that only four bits of
+   RCODE, or response/error code are available.  However, RCODEs can
+   appear not only at the top level of a DNS response but also inside
+   OPT RRs [RFC 2671], TSIG RRs [RFC 2845], and TKEY RRs [RFC 2930].
+   The OPT RR provides an eight bit extension resulting in a 12 bit
+   RCODE field and the TSIG and TKEY RRs have a 16 bit RCODE field.
+
+   Error codes appearing in the DNS header and in these three RR types
+   all refer to the same error code space with the single exception of
+   error code 16 which has a different meaning in the OPT RR from its
+   meaning in other contexts.  See table below.
+
+        RCODE   Name    Description                        Reference
+        Decimal
+          Hexadecimal
+         0    NoError   No Error                           [RFC 1035]
+         1    FormErr   Format Error                       [RFC 1035]
+         2    ServFail  Server Failure                     [RFC 1035]
+         3    NXDomain  Non-Existent Domain                [RFC 1035]
+         4    NotImp    Not Implemented                    [RFC 1035]
+         5    Refused   Query Refused                      [RFC 1035]
+         6    YXDomain  Name Exists when it should not     [RFC 2136]
+         7    YXRRSet   RR Set Exists when it should not   [RFC 2136]
+         8    NXRRSet   RR Set that should exist does not  [RFC 2136]
+         9    NotAuth   Server Not Authoritative for zone  [RFC 2136]
+        10    NotZone   Name not contained in zone         [RFC 2136]
+        11 - 15         Available for assignment
+        16    BADVERS   Bad OPT Version                    [RFC 2671]
+        16    BADSIG    TSIG Signature Failure             [RFC 2845]
+        17    BADKEY    Key not recognized                 [RFC 2845]
+        18    BADTIME   Signature out of time window       [RFC 2845]
+        19    BADMODE   Bad TKEY Mode                      [RPC 2930]
+        20    BADNAME   Duplicate key name                 [RPF 2930]
+        21    BADALG    Algorithm not supported            [RPF 2930]
+
+        22 - 3,840
+          0x0016 - 0x0F00   Available for assignment
+
+        3,841 - 4,095
+          0x0F01 - 0x0FFF   Private Use
+
+        4,096 - 65,534
+          0x1000 - 0xFFFE   Available for assignment
+
+        65,535
+          0xFFFF            Reserved, can only be allocated by an IETF
+                            Standards Action.
+
+
+
+D. Eastlake 3rd                                                 [Page 5]
+
+
+INTERNET-DRAFT           DNS IANA Considerations             August 2005
+
+
+   Since it is important that RCODEs be understood for interoperability,
+   assignment of new RCODE listed above as "available for assignment"
+   requires an IETF Consensus.
+
+
+
+3. DNS Resource Records
+
+   All RRs have the same top level format shown in the figure below
+   taken from [RFC 1035]:
+
+                                       1  1  1  1  1  1
+         0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
+       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+       |                                               |
+       /                                               /
+       /                      NAME                     /
+       |                                               |
+       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+       |                      TYPE                     |
+       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+       |                     CLASS                     |
+       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+       |                      TTL                      |
+       |                                               |
+       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+       |                   RDLENGTH                    |
+       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--|
+       /                     RDATA                     /
+       /                                               /
+       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+   NAME is an owner name, i.e., the name of the node to which this
+   resource record pertains.  NAMEs are specific to a CLASS as described
+   in section 3.2.  NAMEs consist of an ordered sequence of one or more
+   labels each of which has a label type [RFC 1035, 2671].
+
+   TYPE is a two octet unsigned integer containing one of the RR TYPE
+   codes.  See section 3.1.
+
+   CLASS is a two octet unsigned integer containing one of the RR CLASS
+   codes.  See section 3.2.
+
+   TTL is a four octet (32 bit) bit unsigned integer that specifies the
+   number of seconds that the resource record may be cached before the
+   source of the information should again be consulted.  Zero is
+   interpreted to mean that the RR can only be used for the transaction
+   in progress.
+
+   RDLENGTH is an unsigned 16 bit integer that specifies the length in
+
+
+D. Eastlake 3rd                                                 [Page 6]
+
+
+INTERNET-DRAFT           DNS IANA Considerations             August 2005
+
+
+   octets of the RDATA field.
+
+   RDATA is a variable length string of octets that constitutes the
+   resource. The format of this information varies according to the TYPE
+   and in some cases the CLASS of the resource record.
+
+
+
+3.1 RR TYPE IANA Considerations
+
+   There are three subcategories of RR TYPE numbers: data TYPEs, QTYPEs,
+   and MetaTYPEs.
+
+   Data TYPEs are the primary means of storing data.  QTYPES can only be
+   used in queries.  Meta-TYPEs designate transient data associated with
+   an particular DNS message and in some cases can also be used in
+   queries.  Thus far, data TYPEs have been assigned from 1 upwards plus
+   the block from 100 through 103 while Q and Meta Types have been
+   assigned from 255 downwards except for the OPT Meta-RR which is
+   assigned TYPE 41.  There have been DNS implementations which made
+   caching decisions based on the top bit of the bottom byte of the RR
+   TYPE.
+
+   There are currently three Meta-TYPEs assigned: OPT [RFC 2671], TSIG
+   [RFC 2845], and TKEY [RFC 2930].
+
+   There are currently five QTYPEs assigned: * (all), MAILA, MAILB,
+   AXFR, and IXFR.
+
+   Considerations for the allocation of new RR TYPEs are as follows:
+
+     Decimal
+   Hexadecimal
+
+     0
+   0x0000 - TYPE zero is used as a special indicator for the SIG RR [RFC
+          2535] and in other circumstances and must never be allocated
+          for ordinary use.
+
+     1 - 127
+   0x0001 - 0x007F - remaining TYPEs in this range are assigned for data
+          TYPEs by the DNS TYPE Allocation Policy as specified in
+          section 3.1.1.
+
+     128 - 255
+   0x0080 - 0x00FF - remaining TYPEs in this rage are assigned for Q and
+          Meta TYPEs by the DNS TYPE Allocation Policy as specified in
+          section 3.1.1.
+
+
+
+
+D. Eastlake 3rd                                                 [Page 7]
+
+
+INTERNET-DRAFT           DNS IANA Considerations             August 2005
+
+
+     256 - 32,767
+   0x0100 - 0x7FFF - assigned for data, Q, or Meta TYPE use by the DNS
+          TYPE Allocation Policy as specified in section 3.1.1.
+
+     32,768 - 65,279
+   0x8000 - 0xFEFF - Specification Required as defined in [RFC 2434].
+
+     65,280 - 65534
+   0xFF00 - 0xFFFE - Private Use.
+
+     65,535
+   0xFFFF - Reserved, can only be assigned by an IETF Standards Action.
+
+
+
+3.1.1 DNS TYPE Allocation Policy
+
+   Parameter values specified above as assigned based on DNS TYPE
+   Allocation Policy. That is, Expert Review with the additional
+   requirement that the review be based on a complete template as
+   specified below which has been posted for three weeks to the
+   namedroppers@ops.ietf.org mailing list.
+
+   Partial or draft templates may be posted with the intend of
+   soliciting feedback.
+
+
+                 DNS RR TYPE PARAMETER ALLOCATION TEMPLATE
+
+        Date:
+
+        Name and email of originator:
+
+        Pointer to internet-draft or other document giving a detailed
+        description of the protocol use of the new RR Type:
+
+        What need is the new RR TYPE intended to fix?
+
+        What existing RR TYPE(s) come closest to filling that need and why are
+        they unsatisfactory?
+
+        Does the proposed RR TYPR require special handling within the DNS
+        different from an Unknown RR TYPE?
+
+        Comments:
+
+
+
+
+
+
+
+D. Eastlake 3rd                                                 [Page 8]
+
+
+INTERNET-DRAFT           DNS IANA Considerations             August 2005
+
+
+3.1.2 Special Note on the OPT RR
+
+   The OPT (OPTion) RR, number 41, is specified in [RFC 2671].  Its
+   primary purpose is to extend the effective field size of various DNS
+   fields including RCODE, label type, OpCode, flag bits, and RDATA
+   size.  In particular, for resolvers and servers that recognize it, it
+   extends the RCODE field from 4 to 12 bits.
+
+
+
+3.1.3 The AFSDB RR Subtype Field
+
+   The AFSDB RR [RFC 1183] is a CLASS insensitive RR that has the same
+   RDATA field structure as the MX RR but the 16 bit unsigned integer
+   field at the beginning of the RDATA is interpreted as a subtype as
+   follows:
+
+     Decimal
+   Hexadecimal
+
+     0
+   0x0000 -  Allocation requires IETF Standards Action.
+
+     1
+   0x0001 - Andrews File Service v3.0 Location Service [RFC 1183].
+
+     2
+   0x0002 - DCE/NCA root cell directory node [RFC 1183].
+
+     3 - 65,279
+   0x0003 - 0xFEFF - Allocation by IETF Consensus.
+
+     65,280 - 65,534
+   0xFF00 - 0xFFFE - Private Use.
+
+     65,535
+   0xFFFF - Reserved, allocation requires IETF Standards Action.
+
+
+
+3.2 RR CLASS IANA Considerations
+
+   DNS CLASSes have been little used but constitute another dimension of
+   the DNS distributed database.  In particular, there is no necessary
+   relationship between the name space or root servers for one CLASS and
+   those for another CLASS.  The same name can have completely different
+   meanings in different CLASSes; however, the label types are the same
+   and the null label is usable only as root in every CLASS.  However,
+   as global networking and DNS have evolved, the IN, or Internet, CLASS
+   has dominated DNS use.
+
+
+D. Eastlake 3rd                                                 [Page 9]
+
+
+INTERNET-DRAFT           DNS IANA Considerations             August 2005
+
+
+   There are two subcategories of DNS CLASSes: normal data containing
+   classes and QCLASSes that are only meaningful in queries or updates.
+
+   The current CLASS assignments and considerations for future
+   assignments are as follows:
+
+     Decimal
+   Hexadecimal
+
+     0
+   0x0000 - Reserved, assignment requires an IETF Standards Action.
+
+     1
+   0x0001 - Internet (IN).
+
+     2
+   0x0002 - Available for assignment by IETF Consensus as a data CLASS.
+
+     3
+   0x0003 - Chaos (CH) [Moon 1981].
+
+     4
+   0x0004 - Hesiod (HS) [Dyer 1987].
+
+     5 - 127
+   0x0005 - 0x007F - available for assignment by IETF Consensus for data
+          CLASSes only.
+
+     128 - 253
+   0x0080 - 0x00FD - available for assignment by IETF Consensus for
+          QCLASSes only.
+
+     254
+   0x00FE - QCLASS None [RFC 2136].
+
+     255
+   0x00FF - QCLASS Any [RFC 1035].
+
+     256 - 32,767
+   0x0100 - 0x7FFF - Assigned by IETF Consensus.
+
+     32,768 - 65,279
+   0x8000 - 0xFEFF - Assigned based on Specification Required as defined
+          in [RFC 2434].
+
+     65,280 - 65,534
+   0xFF00 - 0xFFFE - Private Use.
+
+     65,535
+   0xFFFF - Reserved, can only be assigned by an IETF Standards Action.
+
+
+D. Eastlake 3rd                                                [Page 10]
+
+
+INTERNET-DRAFT           DNS IANA Considerations             August 2005
+
+
+3.3 RR NAME Considerations
+
+   DNS NAMEs are sequences of labels [RFC 1035].  The last label in each
+   NAME is "ROOT" which is the zero length label.  By definition, the
+   null or ROOT label can not be used for any other NAME purpose.
+
+   At the present time, there are two categories of label types, data
+   labels and compression labels.  Compression labels are pointers to
+   data labels elsewhere within an RR or DNS message and are intended to
+   shorten the wire encoding of NAMEs.  The two existing data label
+   types are sometimes referred to as Text and Binary.  Text labels can,
+   in fact, include any octet value including zero value octets but most
+   current uses involve only [US-ASCII].  For retrieval, Text labels are
+   defined to treat ASCII upper and lower case letter codes as matching
+   [insensitive].  Binary labels are bit sequences [RFC 2673]. The
+   Binary label type is Experimental [RFC 3363].
+
+   IANA considerations for label types are given in [RFC 2671].
+
+   NAMEs are local to a CLASS.  The Hesiod [Dyer 1987] and Chaos [Moon
+   1981] CLASSes are essentially for local use.  The IN or Internet
+   CLASS is thus the only DNS CLASS in global use on the Internet at
+   this time.
+
+   A somewhat out-of-date description of name allocation in the IN Class
+   is given in [RFC 1591].  Some information on reserved top level
+   domain names is in BCP 32 [RFC 2606].
+
+
+
+4. Security Considerations
+
+   This document addresses IANA considerations in the allocation of
+   general DNS parameters, not security.  See [RFC 4033, 4034, 4035] for
+   secure DNS considerations.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+D. Eastlake 3rd                                                [Page 11]
+
+
+INTERNET-DRAFT           DNS IANA Considerations             August 2005
+
+
+Appendix: Changes from RFC 2929
+
+   RFC Editor: This Appendix should be deleted for publication.
+
+   Changes from RFC 2929 to this draft:
+
+   1. Changed many "IETF Consensus" for RR TYPEs to be "DNS TYPE
+   Allocation Policy" and add the specification of that policy. Change
+   some remaining "IETF Standards Action" allocation requirements to say
+   "as modified by [RFC 4020]".
+
+   2. Updated various RFC references.
+
+   3. Mentioned that the Binary label type is now Experimental and
+   IQuery is Obsolete.
+
+   4. Changed allocation status of RR Type 0xFFFF and RCODE 0xFFFF to be
+   IETF Standards Action required.
+
+   5. Add an IANA allocation policy for the AFSDB RR Subtype field.
+
+   6. Addition of reference to case insensitive draft.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+D. Eastlake 3rd                                                [Page 12]
+
+
+INTERNET-DRAFT           DNS IANA Considerations             August 2005
+
+
+Copyright and Disclaimer
+
+   Copyright (C) The Internet Society (2005).  This document is subject to
+   the rights, licenses and restrictions contained in BCP 78, and except
+   as set forth therein, the authors retain all their rights.
+
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+
+Normative References
+
+   [RFC 1034] - Mockapetris, P., "Domain Names - Concepts and
+   Facilities", STD 13, RFC 1034, November 1987.
+
+   [RFC 1035] - Mockapetris, P., "Domain Names - Implementation and
+   Specifications", STD 13, RFC 1035, November 1987.
+
+   [RFC 1183] - Everhart, C., Mamakos, L., Ullmann, R., and P.
+   Mockapetris, "New DNS RR Definitions", RFC 1183, October 1990.
+
+   [RFC 1996] - Vixie, P., "A Mechanism for Prompt Notification of Zone
+   Changes (DNS NOTIFY)", RFC 1996, August 1996.
+
+   [RFC 2136] - Vixie, P., Thomson, S., Rekhter, Y. and J. Bound,
+   "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136,
+   April 1997.
+
+   [RFC 2181] - Elz, R. and R. Bush, "Clarifications to the DNS
+   Specification", RFC 2181, July 1997.
+
+   [RFC 2434] - Narten, T. and H. Alvestrand, "Guidelines for Writing an
+   IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
+
+   [RFC 2671] - Vixie, P., "Extension mechanisms for DNS (EDNS0)", RFC
+   2671, August 1999.
+
+   [RFC 2673] - Crawford, M., "Binary Labels in the Domain Name System",
+   RFC 2673, August 1999.
+
+   [RFC 2845] - Vixie, P., Gudmundsson, O., Eastlake, D. and B.
+   Wellington, "Secret Key Transaction Authentication for DNS (TSIG)",
+   RFC 2845, May 2000.
+
+
+D. Eastlake 3rd                                                [Page 13]
+
+
+INTERNET-DRAFT           DNS IANA Considerations             August 2005
+
+
+   [RFC 2930] - Eastlake, D., "Secret Key Establishment for DNS (TKEY
+   RR)", September 2000.
+
+   [RFC 3363] - Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T.
+   Hain, "Representing Internet Protocol version 6 (IPv6) Addresses in
+   the Domain Name System (DNS)", RFC 3363, August 2002.
+
+   [RFC 3425] - Lawrence, D., "Obsoleting IQUERY", RFC 3425, November
+   2002.
+
+   [RFC 4020] - Kompella, K. and A. Zinin, "Early IANA Allocation of
+   Standards Track Code Points", BCP 100, RFC 4020, February 2005.
+
+   [RFC 4033] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
+   Rose, "DNS Security Introduction and Requirements", RFC 4033, March
+   2005.
+
+   [RFC 4034] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
+   Rose, "Resource Records for the DNS Security Extensions", RFC 4034,
+   March 2005.
+
+   [RFC 4044] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
+   Rose, "Protocol Modifications for the DNS Security Extensions", RFC
+   4035, March 2005.
+
+   [US-ASCII] - ANSI, "USA Standard Code for Information Interchange",
+   X3.4, American National Standards Institute: New York, 1968.
+
+
+
+Informative References
+
+   [Dyer 1987] - Dyer, S., and F. Hsu, "Hesiod", Project Athena
+   Technical Plan - Name Service, April 1987,
+
+   [Moon 1981] - D. Moon, "Chaosnet", A.I. Memo 628, Massachusetts
+   Institute of Technology Artificial Intelligence Laboratory, June
+   1981.
+
+   [RFC 1591] - Postel, J., "Domain Name System Structure and
+   Delegation", RFC 1591, March 1994.
+
+   [RFC 2929] - Eastlake 3rd, D., Brunner-Williams, E., and B. Manning,
+   "Domain Name System (DNS) IANA Considerations", BCP 42, RFC 2929,
+   September 2000.
+
+   [RFC 2606] - Eastlake, D. and A. Panitz, "Reserved Top Level DNS
+   Names", RFC 2606, June 1999.
+
+   [insensitive] - Eastlake, D., "Domain Name System (DNS) Case
+
+
+D. Eastlake 3rd                                                [Page 14]
+
+
+INTERNET-DRAFT           DNS IANA Considerations             August 2005
+
+
+   Insensitivity Clarification", draft-ietf-dnsext-insensitive-*.txt,
+   work in progress.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+D. Eastlake 3rd                                                [Page 15]
+
+
+INTERNET-DRAFT           DNS IANA Considerations             August 2005
+
+
+Authors Addresses
+
+   Donald E. Eastlake 3rd
+   Motorola Laboratories
+   155 Beaver Street
+   Milford, MA 01757 USA
+
+   Telephone:   +1-508-786-7554 (w)
+   email:       Donald.Eastlake@motorola.com
+
+
+
+Expiration and File Name
+
+   This draft expires February 2006.
+
+   Its file name is draft-ietf-dnsext-2929bis-01.txt.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+D. Eastlake 3rd                                                [Page 16]
+
diff --git a/doc/draft/draft-ietf-dnsext-axfr-clarify-05.txt b/doc/draft/draft-ietf-dnsext-axfr-clarify-05.txt
new file mode 100644
index 0000000..f0ce70a
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsext-axfr-clarify-05.txt
@@ -0,0 +1,393 @@
+
+
+
+INTERNET-DRAFT                                      Andreas Gustafsson
+draft-ietf-dnsext-axfr-clarify-05.txt                     Nominum Inc.
+                                                         November 2002
+
+
+               DNS Zone Transfer Protocol Clarifications
+
+
+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 draft documents 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 "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/ietf/1id-abstracts.txt
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+Abstract
+
+   In the Domain Name System, zone data is replicated among
+   authoritative DNS servers by means of the "zone transfer" protocol,
+   also known as the "AXFR" protocol.  This memo clarifies, updates, and
+   adds missing detail to the original AXFR protocol specification in
+   RFC1034.
+
+1. Introduction
+
+   The original definition of the DNS zone transfer protocol consists of
+   a single paragraph in [RFC1034] section 4.3.5 and some additional
+   notes in [RFC1035] section 6.3.  It is not sufficiently detailed to
+   serve as the sole basis for constructing interoperable
+   implementations.  This document is an attempt to provide a more
+   complete definition of the protocol.  Where the text in RFC1034
+   conflicts with existing practice, the existing practice has been
+   codified in the interest of interoperability.
+
+
+
+
+Expires May 2003                                                [Page 1]
+
+draft-ietf-dnsext-axfr-clarify-05.txt                      November 2002
+
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC 2119].
+
+2. The zone transfer request
+
+   To initiate a zone transfer, the slave server sends a zone transfer
+   request to the master server over a reliable transport such as TCP.
+   The form of this request is specified in sufficient detail in RFC1034
+   and needs no further clarification.
+
+   Implementers are advised that one server implementation in widespread
+   use sends AXFR requests where the TCP message envelope size exceeds
+   the DNS request message size by two octets.
+
+3. The zone transfer response
+
+   If the master server is unable or unwilling to provide a zone
+   transfer, it MUST respond with a single DNS message containing an
+   appropriate RCODE other than NOERROR.  If the master is not
+   authoritative for the requested zone, the RCODE SHOULD be 9
+   (NOTAUTH).
+
+   Slave servers should note that some master server implementations
+   will simply close the connection when denying the slave access to the
+   zone.  Therefore, slaves MAY interpret an immediate graceful close of
+   the TCP connection as equivalent to a "Refused" response (RCODE 5).
+
+   If a zone transfer can be provided, the master server sends one or
+   more DNS messages containing the zone data as described below.
+
+3.1. Multiple answers per message
+
+   The zone data in a zone transfer response is a sequence of answer
+   RRs.  These RRs are transmitted in the answer section(s) of one or
+   more DNS response messages.
+
+   The AXFR protocol definition in RFC1034 does not make a clear
+   distinction between response messages and answer RRs.  Historically,
+   DNS servers always transmitted a single answer RR per message.  This
+   encoding is wasteful due to the overhead of repeatedly sending DNS
+   message headers and the loss of domain name compression
+   opportunities.  To improve efficiency, some newer servers support a
+   mode where multiple RRs are transmitted in a single DNS response
+   message.
+
+   A master MAY transmit multiple answer RRs per response message up to
+   the largest number that will fit within the 65535 byte limit on TCP
+
+
+
+Expires May 2003                                                [Page 2]
+
+draft-ietf-dnsext-axfr-clarify-05.txt                      November 2002
+
+
+   DNS message size.  In the case of a small zone, this can cause the
+   entire transfer to be transmitted in a single response message.
+
+   Slaves MUST accept messages containing any number of answer RRs.  For
+   compatibility with old slaves, masters that support sending multiple
+   answers per message SHOULD be configurable to revert to the
+   historical mode of one answer per message, and the configuration
+   SHOULD be settable on a per-slave basis.
+
+3.2. DNS message header contents
+
+   RFC1034 does not specify the contents of the DNS message header of
+   the zone transfer response messages.  The header of each message MUST
+   be as follows:
+
+       ID      Copy from request
+       QR      1
+       OPCODE  QUERY
+       AA      1, but MAY be 0 when RCODE is not NOERROR
+       TC      0
+       RD      Copy from request, or 0
+       RA      Set according to availability of recursion, or 0
+       Z       0
+       AD      0
+       CD      0
+       RCODE   NOERROR on success, error code otherwise
+
+   The slave MUST check the RCODE in each message and abort the transfer
+   if it is not NOERROR.  It SHOULD check the ID of the first message
+   received and abort the transfer if it does not match the ID of the
+   request.  The ID SHOULD be ignored in subsequent messages, and fields
+   other than RCODE and ID SHOULD be ignored in all messages, to ensure
+   interoperability with certain older implementations which transmit
+   incorrect or arbitrary values in these fields.
+
+3.3. Additional section and SIG processing
+
+   Zone transfer responses are not subject to any kind of additional
+   section processing or automatic inclusion of SIG records.  SIG RRs in
+   the zone data are treated exactly the same as any other RR type.
+
+3.4. The question section
+
+   RFC1034 does not specify whether zone transfer response messages have
+   a question section or not.  The initial message of a zone transfer
+   response SHOULD have a question section identical to that in the
+   request.  Subsequent messages SHOULD NOT have a question section,
+   though the final message MAY.  The receiving slave server MUST accept
+
+
+
+Expires May 2003                                                [Page 3]
+
+draft-ietf-dnsext-axfr-clarify-05.txt                      November 2002
+
+
+   any combination of messages with and without a question section.
+
+3.5. The authority section
+
+   The master server MUST transmit messages with an empty authority
+   section.  Slaves MUST ignore any authority section contents they may
+   receive from masters that do not comply with this requirement.
+
+3.6. The additional section
+
+   The additional section MAY contain additional RRs such as transaction
+   signatures.  The slave MUST ignore any unexpected RRs in the
+   additional section.  It MUST NOT treat additional section RRs as zone
+   data.
+
+4. Zone data
+
+   The purpose of the zone transfer mechanism is to exactly replicate at
+   each slave the set of RRs associated with a particular zone at its
+   primary master.  An RR is associated with a zone by being loaded from
+   the master file of that zone at the primary master server, or by some
+   other, equivalent method for configuring zone data.
+
+   This replication shall be complete and unaltered, regardless of how
+   many and which intermediate masters/slaves are involved, and
+   regardless of what other zones those intermediate masters/slaves do
+   or do not serve, and regardless of what data may be cached in
+   resolvers associated with the intermediate masters/slaves.
+
+   Therefore, in a zone transfer the master MUST send exactly those
+   records that are associated with the zone, whether or not their owner
+   names would be considered to be "in" the zone for purposes of
+   resolution, and whether or not they would be eligible for use as glue
+   in responses.  The transfer MUST NOT include any RRs that are not
+   associated with the zone, such as RRs associated with zones other
+   than the one being transferred or present in the cache of the local
+   resolver, even if their owner names are in the zone being transferred
+   or are pointed to by NS records in the zone being transferred.
+
+   The slave MUST associate the RRs received in a zone transfer with the
+   specific zone being transferred, and maintain that association for
+   purposes of acting as a master in outgoing transfers.
+
+5. Transmission order
+
+   RFC1034 states that "The first and last messages must contain the
+   data for the top authoritative node of the zone".  This is not
+   consistent with existing practice.  All known master implementations
+
+
+
+Expires May 2003                                                [Page 4]
+
+draft-ietf-dnsext-axfr-clarify-05.txt                      November 2002
+
+
+   send, and slave implementations expect to receive, the zone's SOA RR
+   as the first and last record of the transfer.
+
+   Therefore, the quoted sentence is hereby superseded by the sentence
+   "The first and last RR transmitted must be the SOA record of the
+   zone".
+
+   The initial and final SOA record MUST be identical, with the possible
+   exception of case and compression.  In particular, they MUST have the
+   same serial number.  The slave MUST consider the transfer to be
+   complete when, and only when, it has received the message containing
+   the second SOA record.
+
+   The transmission order of all other RRs in the zone is undefined.
+   Each of them SHOULD be transmitted only once, and slaves MUST ignore
+   any duplicate RRs received.
+
+6. Security Considerations
+
+   The zone transfer protocol as defined in [RFC1034] and clarified by
+   this memo does not have any built-in mechanisms for the slave to
+   securely verify the identity of the master server and the integrity
+   of the transferred zone data.  The use of a cryptographic mechanism
+   for ensuring authenticity and integrity, such as TSIG [RFC2845],
+   IPSEC, or TLS, is RECOMMENDED.
+
+   The zone transfer protocol allows read-only public access to the
+   complete zone data.  Since data in the DNS is public by definition,
+   this is generally acceptable.  Sites that wish to avoid disclosing
+   their full zone data MAY restrict zone transfer access to authorized
+   slaves.
+
+   These clarifications are not believed to themselves introduce any new
+   security problems, nor to solve any existing ones.
+
+Acknowledgements
+
+   Many people have contributed input and commentary to earlier versions
+   of this document, including but not limited to Bob Halley, Dan
+   Bernstein, Eric A. Hall, Josh Littlefield, Kevin Darcy, Robert Elz,
+   Levon Esibov, Mark Andrews, Michael Patton, Peter Koch, Sam
+   Trenholme, and Brian Wellington.
+
+References
+
+   [RFC1034] - Domain Names - Concepts and Facilities, P. Mockapetris,
+   November 1987.
+
+
+
+
+Expires May 2003                                                [Page 5]
+
+draft-ietf-dnsext-axfr-clarify-05.txt                      November 2002
+
+
+   [RFC1035] - Domain Names - Implementation and Specifications, P.
+   Mockapetris, November 1987.
+
+   [RFC2119] - Key words for use in RFCs to Indicate Requirement Levels,
+   S. Bradner, BCP 14, March 1997.
+
+   [RFC2845] - Secret Key Transaction Authentication for DNS (TSIG).  P.
+   Vixie, O. Gudmundsson, D. Eastlake, B. Wellington, May 2000.
+
+Author's Address
+
+   Andreas Gustafsson
+   Nominum Inc.
+   2385 Bay Rd
+   Redwood City, CA 94063
+   USA
+
+   Phone: +1 650 381 6004
+
+   Email: gson@nominum.com
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2000 - 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 implmentation 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 Standards process must be
+   followed, or as required to translate it into 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
+
+
+
+Expires May 2003                                                [Page 6]
+
+draft-ietf-dnsext-axfr-clarify-05.txt                      November 2002
+
+
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Expires May 2003                                                [Page 7]
+
+
diff --git a/doc/draft/draft-ietf-dnsext-dhcid-rr-12.txt b/doc/draft/draft-ietf-dnsext-dhcid-rr-12.txt
new file mode 100644
index 0000000..07749d9
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsext-dhcid-rr-12.txt
@@ -0,0 +1,674 @@
+
+
+
+
+DNSEXT                                                          M. Stapp
+Internet-Draft                                       Cisco Systems, Inc.
+Expires: September 1, 2006                                      T. Lemon
+                                                           Nominum, Inc.
+                                                           A. Gustafsson
+                                          Araneus Information Systems Oy
+                                                       February 28, 2006
+
+
+           A DNS RR for Encoding DHCP Information (DHCID RR)
+                  <draft-ietf-dnsext-dhcid-rr-12.txt>
+
+Status of this Memo
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   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 draft documents 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 "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/ietf/1id-abstracts.txt.
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+   This Internet-Draft will expire on September 1, 2006.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   It is possible for DHCP clients to attempt to update the same DNS
+   FQDN or attempt to update a DNS FQDN that has been added to the DNS
+   for another purpose as they obtain DHCP leases.  Whether the DHCP
+   server or the clients themselves perform the DNS updates, conflicts
+   can arise.  To resolve such conflicts, "Resolution of DNS Name
+
+
+
+Stapp, et al.           Expires September 1, 2006               [Page 1]
+
+Internet-Draft                The DHCID RR                 February 2006
+
+
+   Conflicts" [1] proposes storing client identifiers in the DNS to
+   unambiguously associate domain names with the DHCP clients to which
+   they refer.  This memo defines a distinct RR type for this purpose
+   for use by DHCP clients and servers, the "DHCID" RR.
+
+
+Table of Contents
+
+   1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   3.  The DHCID RR . . . . . . . . . . . . . . . . . . . . . . . . .  3
+     3.1.  DHCID RDATA format . . . . . . . . . . . . . . . . . . . .  3
+     3.2.  DHCID Presentation Format  . . . . . . . . . . . . . . . .  4
+     3.3.  The DHCID RR Identifier Type Codes . . . . . . . . . . . .  4
+     3.4.  The DHCID RR Digest Type Code  . . . . . . . . . . . . . .  4
+     3.5.  Computation of the RDATA . . . . . . . . . . . . . . . . .  5
+       3.5.1.  Using the Client's DUID  . . . . . . . . . . . . . . .  5
+       3.5.2.  Using the Client Identifier Option . . . . . . . . . .  5
+       3.5.3.  Using the Client's htype and chaddr  . . . . . . . . .  6
+     3.6.  Examples . . . . . . . . . . . . . . . . . . . . . . . . .  6
+       3.6.1.  Example 1  . . . . . . . . . . . . . . . . . . . . . .  6
+       3.6.2.  Example 2  . . . . . . . . . . . . . . . . . . . . . .  6
+       3.6.3.  Example 3  . . . . . . . . . . . . . . . . . . . . . .  7
+   4.  Use of the DHCID RR  . . . . . . . . . . . . . . . . . . . . .  7
+   5.  Updater Behavior . . . . . . . . . . . . . . . . . . . . . . .  8
+   6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8
+   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  8
+   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  9
+   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  9
+     9.1.  Normative References . . . . . . . . . . . . . . . . . . .  9
+     9.2.  Informative References . . . . . . . . . . . . . . . . . . 10
+   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
+   Intellectual Property and Copyright Statements . . . . . . . . . . 12
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Stapp, et al.           Expires September 1, 2006               [Page 2]
+
+Internet-Draft                The DHCID RR                 February 2006
+
+
+1.  Terminology
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [2].
+
+
+2.  Introduction
+
+   A set of procedures to allow DHCP [6] [10] clients and servers to
+   automatically update the DNS (RFC 1034 [3], RFC 1035 [4]) is proposed
+   in "Resolution of DNS Name Conflicts" [1].
+
+   Conflicts can arise if multiple DHCP clients wish to use the same DNS
+   name or a DHCP client attempts to use a name added for another
+   purpose.  To resolve such conflicts, "Resolution of DNS Name
+   Conflicts" [1] proposes storing client identifiers in the DNS to
+   unambiguously associate domain names with the DHCP clients using
+   them.  In the interest of clarity, it is preferable for this DHCP
+   information to use a distinct RR type.  This memo defines a distinct
+   RR for this purpose for use by DHCP clients or servers, the "DHCID"
+   RR.
+
+   In order to obscure potentially sensitive client identifying
+   information, the data stored is the result of a one-way SHA-256 hash
+   computation.  The hash includes information from the DHCP client's
+   message as well as the domain name itself, so that the data stored in
+   the DHCID RR will be dependent on both the client identification used
+   in the DHCP protocol interaction and the domain name.  This means
+   that the DHCID RDATA will vary if a single client is associated over
+   time with more than one name.  This makes it difficult to 'track' a
+   client as it is associated with various domain names.
+
+
+3.  The DHCID RR
+
+   The DHCID RR is defined with mnemonic DHCID and type code [TBD].  The
+   DHCID RR is only defined in the IN class.  DHCID RRs cause no
+   additional section processing.  The DHCID RR is not a singleton type.
+
+3.1.  DHCID RDATA format
+
+   The RDATA section of a DHCID RR in transmission contains RDLENGTH
+   octets of binary data.  The format of this data and its
+   interpretation by DHCP servers and clients are described below.
+
+   DNS software should consider the RDATA section to be opaque.  DHCP
+   clients or servers use the DHCID RR to associate a DHCP client's
+
+
+
+Stapp, et al.           Expires September 1, 2006               [Page 3]
+
+Internet-Draft                The DHCID RR                 February 2006
+
+
+   identity with a DNS name, so that multiple DHCP clients and servers
+   may deterministically perform dynamic DNS updates to the same zone.
+   From the updater's perspective, the DHCID resource record RDATA
+   consists of a 2-octet identifier type, in network byte order,
+   followed by a 1-octet digest type, followed by one or more octets
+   representing the actual identifier:
+
+           < 2 octets >    Identifier type code
+           < 1 octet >     Digest type code
+           < n octets >    Digest (length depends on digest type)
+
+3.2.  DHCID Presentation Format
+
+   In DNS master files, the RDATA is represented as a single block in
+   base 64 encoding identical to that used for representing binary data
+   in RFC 3548 [7].  The data may be divided up into any number of white
+   space separated substrings, down to single base 64 digits, which are
+   concatenated to form the complete RDATA.  These substrings can span
+   lines using the standard parentheses.
+
+3.3.  The DHCID RR Identifier Type Codes
+
+   The DHCID RR Identifier Type Code specifies what data from the DHCP
+   client's request was used as input into the hash function.  The
+   identifier type codes are defined in a registry maintained by IANA,
+   as specified in Section 7.  The initial list of assigned values for
+   the identifier type code is:
+
+   0x0000 = htype, chaddr from a DHCPv4 client's DHCPREQUEST [6].
+   0x0001 = The data octets (i.e., the Type and Client-Identifier
+      fields) from a DHCPv4 client's Client Identifier option [9].
+   0x0002 = The client's DUID (i.e., the data octets of a DHCPv6
+      client's Client Identifier option [10] or the DUID field from a
+      DHCPv4 client's Client Identifier option [12]).
+
+   0x0003 - 0xfffe = Available to be assigned by IANA.
+
+   0xffff = RESERVED
+
+3.4.  The DHCID RR Digest Type Code
+
+   The DHCID RR Digest Type Code is an identifier for the digest
+   algorithm used.  The digest is calculated over an identifier and the
+   canonical FQDN as described in the next section.
+
+   The digest type codes are defined in a registry maintained by IANA,
+   as specified in Section 7.  The initial list of assigned values for
+   the digest type codes is: value 0 is reserved and value 1 is SHA-256.
+
+
+
+Stapp, et al.           Expires September 1, 2006               [Page 4]
+
+Internet-Draft                The DHCID RR                 February 2006
+
+
+   Reserving other types requires IETF standards action.  Defining new
+   values will also require IETF standards action to document how DNS
+   updaters are to deal with multiple digest types.
+
+3.5.  Computation of the RDATA
+
+   The DHCID RDATA is formed by concatenating the 2-octet identifier
+   type code with variable-length data.
+
+   The RDATA for all type codes other than 0xffff, which is reserved for
+   future expansion, is formed by concatenating the 2-octet identifier
+   type code, the 1-octet digest type code, and the digest value (32
+   octets for SHA-256).
+
+       < identifier-type > < digest-type > < digest >
+
+   The input to the digest hash function is defined to be:
+
+       digest = SHA-256(< identifier > < FQDN >)
+
+   The FQDN is represented in the buffer in unambiguous canonical form
+   as described in RFC 4034 [8], section 6.1.  The identifier type code
+   and the identifier are related as specified in Section 3.3: the
+   identifier type code describes the source of the identifier.
+
+   A DHCPv4 updater uses the 0x0002 type code if a Client Identifier
+   option is present in the DHCPv4 messages and it is encoded as
+   specified in [12].  Otherwise, the updater uses 0x0001 if a Client
+   Identifier option is present and 0x0000 if not.
+
+   A DHCPv6 updater always uses the 0x0002 type code.
+
+3.5.1.  Using the Client's DUID
+
+   When the updater is using the Client's DUID (either from a DHCPv6
+   Client Identifier option or from a portion of the DHCPv4 Client
+   Identifier option encoded as specified in [12]), the first two octets
+   of the DHCID RR MUST be 0x0002, in network byte order.  The third
+   octet is the digest type code (1 for SHA-256).  The rest of the DHCID
+   RR MUST contain the results of computing the SHA-256 hash across the
+   octets of the DUID followed by the FQDN.
+
+3.5.2.  Using the Client Identifier Option
+
+   When the updater is using the DHCPv4 Client Identifier option sent by
+   the client in its DHCPREQUEST message, the first two octets of the
+   DHCID RR MUST be 0x0001, in network byte order.  The third octet is
+   the digest type code (1 for SHA-256).  The rest of the DHCID RR MUST
+
+
+
+Stapp, et al.           Expires September 1, 2006               [Page 5]
+
+Internet-Draft                The DHCID RR                 February 2006
+
+
+   contain the results of computing the SHA-256 hash across the data
+   octets (i.e., the Type and Client-Identifier fields) of the option,
+   followed by the FQDN.
+
+3.5.3.  Using the Client's htype and chaddr
+
+   When the updater is using the client's link-layer address as the
+   identifier, the first two octets of the DHCID RDATA MUST be zero.
+   The third octet is the digest type code (1 for SHA-256).  To generate
+   the rest of the resource record, the updater computes a one-way hash
+   using the SHA-256 algorithm across a buffer containing the client's
+   network hardware type, link-layer address, and the FQDN data.
+   Specifically, the first octet of the buffer contains the network
+   hardware type as it appeared in the DHCP 'htype' field of the
+   client's DHCPREQUEST message.  All of the significant octets of the
+   'chaddr' field in the client's DHCPREQUEST message follow, in the
+   same order in which the octets appear in the DHCPREQUEST message.
+   The number of significant octets in the 'chaddr' field is specified
+   in the 'hlen' field of the DHCPREQUEST message.  The FQDN data, as
+   specified above, follows.
+
+3.6.  Examples
+
+3.6.1.  Example 1
+
+   A DHCP server allocating the IPv4 address 10.0.0.1 to a client with
+   Ethernet MAC address 01:02:03:04:05:06 using domain name
+   "client.example.com" uses the client's link-layer address to identify
+   the client.  The DHCID RDATA is composed by setting the two type
+   octets to zero, the 1-octet digest type to 1 for SHA-256, and
+   performing an SHA-256 hash computation across a buffer containing the
+   Ethernet MAC type octet, 0x01, the six octets of MAC address, and the
+   domain name (represented as specified in Section 3.5).
+
+     client.example.com.   A       10.0.0.1
+     client.example.com.   DHCID   ( AAABxLmlskllE0MVjd57zHcWmEH3pCQ6V
+                                     ytcKD//7es/deY= )
+
+   If the DHCID RR type is not supported, the RDATA would be encoded
+   [13] as:
+
+     \# 35 ( 000001c4b9a5b249651343158dde7bcc77169841f7a4243a572b5c283
+             fffedeb3f75e6 )
+
+3.6.2.  Example 2
+
+   A DHCP server allocates the IPv4 address 10.0.12.99 to a client which
+   included the DHCP client-identifier option data 01:07:08:09:0a:0b:0c
+
+
+
+Stapp, et al.           Expires September 1, 2006               [Page 6]
+
+Internet-Draft                The DHCID RR                 February 2006
+
+
+   in its DHCP request.  The server updates the name "chi.example.com"
+   on the client's behalf, and uses the DHCP client identifier option
+   data as input in forming a DHCID RR.  The DHCID RDATA is formed by
+   setting the two type octets to the value 0x0001, the 1-octet digest
+   type to 1 for SHA-256, and performing a SHA-256 hash computation
+   across a buffer containing the seven octets from the client-id option
+   and the FQDN (represented as specified in Section 3.5).
+
+     chi.example.com.      A       10.0.12.99
+     chi.example.com.      DHCID   ( AAEBOSD+XR3Os/0LozeXVqcNc7FwCfQdW
+                                     L3b/NaiUDlW2No= )
+
+   If the DHCID RR type is not supported, the RDATA would be encoded
+   [13] as:
+
+     \# 35 ( 0001013920fe5d1dceb3fd0ba3379756a70d73b17009f41d58bddbfcd
+             6a2503956d8da )
+
+3.6.3.  Example 3
+
+   A DHCP server allocates the IPv6 address 2000::1234:5678 to a client
+   which included the DHCPv6 client-identifier option data 00:01:00:06:
+   41:2d:f1:66:01:02:03:04:05:06 in its DHCPv6 request.  The server
+   updates the name "chi6.example.com" on the client's behalf, and uses
+   the DHCP client identifier option data as input in forming a DHCID
+   RR.  The DHCID RDATA is formed by setting the two type octets to the
+   value 0x0002, the 1-octet digest type to 1 for SHA-256, and
+   performing a SHA-256 hash computation across a buffer containing the
+   14 octets from the client-id option and the FQDN (represented as
+   specified in Section 3.5).
+
+     chi6.example.com.     AAAA    2000::1234:5678
+     chi6.example.com.     DHCID   ( AAIBY2/AuCccgoJbsaxcQc9TUapptP69l
+                                     OjxfNuVAA2kjEA= )
+
+   If the DHCID RR type is not supported, the RDATA would be encoded
+   [13] as:
+
+     \# 35 ( 000201636fc0b8271c82825bb1ac5c41cf5351aa69b4febd94e8f17cd
+             b95000da48c40 )
+
+
+4.  Use of the DHCID RR
+
+   This RR MUST NOT be used for any purpose other than that detailed in
+   "Resolution of DNS Name Conflicts" [1].  Although this RR contains
+   data that is opaque to DNS servers, the data must be consistent
+   across all entities that update and interpret this record.
+
+
+
+Stapp, et al.           Expires September 1, 2006               [Page 7]
+
+Internet-Draft                The DHCID RR                 February 2006
+
+
+   Therefore, new data formats may only be defined through actions of
+   the DHC Working Group, as a result of revising [1].
+
+
+5.  Updater Behavior
+
+   The data in the DHCID RR allows updaters to determine whether more
+   than one DHCP client desires to use a particular FQDN.  This allows
+   site administrators to establish policy about DNS updates.  The DHCID
+   RR does not establish any policy itself.
+
+   Updaters use data from a DHCP client's request and the domain name
+   that the client desires to use to compute a client identity hash, and
+   then compare that hash to the data in any DHCID RRs on the name that
+   they wish to associate with the client's IP address.  If an updater
+   discovers DHCID RRs whose RDATA does not match the client identity
+   that they have computed, the updater SHOULD conclude that a different
+   client is currently associated with the name in question.  The
+   updater SHOULD then proceed according to the site's administrative
+   policy.  That policy might dictate that a different name be selected,
+   or it might permit the updater to continue.
+
+
+6.  Security Considerations
+
+   The DHCID record as such does not introduce any new security problems
+   into the DNS.  In order to obscure the client's identity information,
+   a one-way hash is used.  And, in order to make it difficult to
+   'track' a client by examining the names associated with a particular
+   hash value, the FQDN is included in the hash computation.  Thus, the
+   RDATA is dependent on both the DHCP client identification data and on
+   each FQDN associated with the client.
+
+   However, it should be noted that an attacker that has some knowledge,
+   such as of MAC addresses commonly used in DHCP client identification
+   data, may be able to discover the client's DHCP identify by using a
+   brute-force attack.  Even without any additional knowledge, the
+   number of unknown bits used in computing the hash is typically only
+   48 to 80.
+
+   Administrators should be wary of permitting unsecured DNS updates to
+   zones, whether or not they are exposed to the global Internet.  Both
+   DHCP clients and servers SHOULD use some form of update
+   authentication (e.g., TSIG [11]) when performing DNS updates.
+
+
+7.  IANA Considerations
+
+
+
+
+Stapp, et al.           Expires September 1, 2006               [Page 8]
+
+Internet-Draft                The DHCID RR                 February 2006
+
+
+   IANA is requested to allocate a DNS RR type number for the DHCID
+   record type.
+
+   This specification defines a new number-space for the 2-octet
+   identifier type codes associated with the DHCID RR.  IANA is
+   requested to establish a registry of the values for this number-
+   space.  Three initial values are assigned in Section 3.3, and the
+   value 0xFFFF is reserved for future use.  New DHCID RR identifier
+   type codes are assigned through Standards Action, as defined in RFC
+   2434 [5].
+
+   This specification defines a new number-space for the 1-octet digest
+   type codes associated with the DHCID RR.  IANA is requested to
+   establish a registry of the values for this number-space.  Two
+   initial values are assigned in Section 3.4.  New DHCID RR digest type
+   codes are assigned through Standards Action, as defined in RFC 2434
+   [5].
+
+
+8.  Acknowledgements
+
+   Many thanks to Harald Alvestrand, Ralph Droms, Olafur Gudmundsson,
+   Sam Hartman, Josh Littlefield, Pekka Savola, and especially Bernie
+   Volz for their review and suggestions.
+
+
+9.  References
+
+9.1.  Normative References
+
+   [1]  Stapp, M. and B. Volz, "Resolution of DNS Name Conflicts Among
+        DHCP Clients (draft-ietf-dhc-dns-resolution-*)", February 2006.
+
+   [2]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
+        Levels", BCP 14, RFC 2119, March 1997.
+
+   [3]  Mockapetris, P., "Domain names - concepts and facilities",
+        STD 13, RFC 1034, November 1987.
+
+   [4]  Mockapetris, P., "Domain names - implementation and
+        specification", STD 13, RFC 1035, November 1987.
+
+   [5]  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
+        Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
+
+
+
+
+
+
+
+Stapp, et al.           Expires September 1, 2006               [Page 9]
+
+Internet-Draft                The DHCID RR                 February 2006
+
+
+9.2.  Informative References
+
+   [6]   Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
+         March 1997.
+
+   [7]   Josefsson, S., "The Base16, Base32, and Base64 Data Encodings",
+         RFC 3548, July 2003.
+
+   [8]   Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+         "Resource Records for the DNS Security Extensions", RFC 4034,
+         March 2005.
+
+   [9]   Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
+         Extensions", RFC 2132, March 1997.
+
+   [10]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M.
+         Carney, "Dynamic Host Configuration Protocol for IPv6
+         (DHCPv6)", RFC 3315, July 2003.
+
+   [11]  Vixie, P., Gudmundsson, O., Eastlake, D., and B. Wellington,
+         "Secret Key Transaction Authentication for DNS (TSIG)",
+         RFC 2845, May 2000.
+
+   [12]  Lemon, T. and B. Sommerfeld, "Node-specific Client Identifiers
+         for Dynamic Host Configuration Protocol Version Four (DHCPv4)",
+         RFC 4361, February 2006.
+
+   [13]  Gustafsson, A., "Handling of Unknown DNS Resource Record (RR)
+         Types", RFC 3597, September 2003.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Stapp, et al.           Expires September 1, 2006              [Page 10]
+
+Internet-Draft                The DHCID RR                 February 2006
+
+
+Authors' Addresses
+
+   Mark Stapp
+   Cisco Systems, Inc.
+   1414 Massachusetts Ave.
+   Boxborough, MA  01719
+   USA
+
+   Phone: 978.936.1535
+   Email: mjs@cisco.com
+
+
+   Ted Lemon
+   Nominum, Inc.
+   950 Charter St.
+   Redwood City, CA  94063
+   USA
+
+   Email: mellon@nominum.com
+
+
+   Andreas Gustafsson
+   Araneus Information Systems Oy
+   Ulappakatu 1
+   02320 Espoo
+   Finland
+
+   Email: gson@araneus.fi
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Stapp, et al.           Expires September 1, 2006              [Page 11]
+
+Internet-Draft                The DHCID RR                 February 2006
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2006).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Stapp, et al.           Expires September 1, 2006              [Page 12]
+
+
diff --git a/doc/draft/draft-ietf-dnsext-dns-name-p-s-00.txt b/doc/draft/draft-ietf-dnsext-dns-name-p-s-00.txt
new file mode 100644
index 0000000..438e800
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsext-dns-name-p-s-00.txt
@@ -0,0 +1,1397 @@
+DNS Extensions Working Group                                   G. Sisson
+Internet-Draft                                                 B. Laurie
+Expires: January 11, 2006                                        Nominet
+                                                           July 10, 2005
+
+
+            Derivation of DNS Name Predecessor and Successor
+                   draft-ietf-dnsext-dns-name-p-s-00
+
+Status of this Memo
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   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 draft documents 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 "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/ietf/1id-abstracts.txt.
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+   This Internet-Draft will expire on January 11, 2006.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).
+
+Abstract
+
+   This document describes two methods for deriving the canonically-
+   ordered predecessor and successor of a DNS name.  These methods may
+   be used for dynamic NSEC resource record synthesis, enabling
+   security-aware name servers to provide authenticated denial of
+   existence without disclosing other owner names in a DNSSEC-secured
+   zone.
+
+
+
+
+
+Sisson & Laurie         Expires January 11, 2006                [Page 1]
+
+Internet-Draft     DNS Name Predecessor and Successor          July 2005
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   2.  Notational Conventions . . . . . . . . . . . . . . . . . . . .  3
+   3.  Absolute Method  . . . . . . . . . . . . . . . . . . . . . . .  4
+     3.1.  Derivation of DNS Name Predecessor . . . . . . . . . . . .  4
+     3.2.  Derivation of DNS Name Successor . . . . . . . . . . . . .  4
+   4.  Modified Method  . . . . . . . . . . . . . . . . . . . . . . .  5
+     4.1.  Derivation of DNS Name Predecessor . . . . . . . . . . . .  6
+     4.2.  Derivation of DNS Name Successor . . . . . . . . . . . . .  6
+   5.  Notes  . . . . . . . . . . . . . . . . . . . . . . . . . . . .  7
+     5.1.  Case Considerations  . . . . . . . . . . . . . . . . . . .  7
+     5.2.  Choice of Range  . . . . . . . . . . . . . . . . . . . . .  7
+     5.3.  Wild Card Considerations . . . . . . . . . . . . . . . . .  8
+     5.4.  Possible Modifications . . . . . . . . . . . . . . . . . .  8
+       5.4.1.  Restriction of Effective Maximum DNS Name Length . . .  8
+       5.4.2.  Use of Modified Method With Zones Containing
+               SRV RRs  . . . . . . . . . . . . . . . . . . . . . . .  9
+   6.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
+     6.1.  Examples of Immediate Predecessors Using Absolute
+           Method . . . . . . . . . . . . . . . . . . . . . . . . . . 10
+     6.2.  Examples of Immediate Successors Using Absolute Method . . 13
+     6.3.  Examples of Predecessors Using Modified Method . . . . . . 19
+     6.4.  Examples of Successors Using Modified Method . . . . . . . 20
+   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 21
+   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 21
+   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
+     10.1. Normative References . . . . . . . . . . . . . . . . . . . 22
+     10.2. Informative References . . . . . . . . . . . . . . . . . . 22
+   9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 21
+   Appendix A.  Change History  . . . . . . . . . . . . . . . . . . . 22
+     A.1.  Changes from sisson-02 to ietf-00  . . . . . . . . . . . . 22
+     A.2.  Changes from sisson-01 to sisson-02  . . . . . . . . . . . 23
+     A.3.  Changes from sisson-00 to sisson-01  . . . . . . . . . . . 23
+   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
+   Intellectual Property and Copyright Statements . . . . . . . . . . 25
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sisson & Laurie         Expires January 11, 2006                [Page 2]
+
+Internet-Draft     DNS Name Predecessor and Successor          July 2005
+
+
+1.  Introduction
+
+   One of the proposals for avoiding the exposure of zone information
+   during the deployment DNSSEC is dynamic NSEC resource record (RR)
+   synthesis.  This technique is described in [I-D.ietf-dnsext-dnssec-
+   trans] and [I-D.ietf-dnsext-dnssec-online-signing], and involves the
+   generation of NSEC RRs that just span the query name for non-existent
+   owner names.  In order to do this, the DNS names which would occur
+   just prior to and just following a given query name must be
+   calculated in real time, as maintaining a list of all possible owner
+   names that might occur in a zone would be impracticable.
+
+   Section 6.1 of [RFC4034] defines canonical DNS name order.  This
+   document does not amend or modify this definition.  However, the
+   derivation of immediate predecessor and successor, while trivial, is
+   non-obvious.  Accordingly, several methods are described here as an
+   aid to implementors and a reference to other interested parties.
+
+   This document describes two methods:
+
+   1.  An ``absolute method'', which returns the immediate predecessor
+       or successor of a domain name such that no valid DNS name could
+       exist between that DNS name and the predecessor or successor.
+
+   2.  A ``modified method'', which returns a predecessor and successor
+       which are more economical in size and computation.  This method
+       is restricted to use with zones consisting only of single-label
+       owner names where a maximum-length owner name would not result in
+       a DNS name exceeding the maximum DNS name length.  This is,
+       however, the type of zone for which the technique of online-
+       signing is most likely to be used.
+
+
+2.  Notational Conventions
+
+   The following notational conventions are used in this document for
+   economy of expression:
+
+   N: An unspecified DNS name.
+
+   P(N): Immediate predecessor to N (absolute method).
+
+   S(N): Immediate successor to N (absolute method).
+
+   P'(N): Predecessor to N (modified method).
+
+
+
+
+
+
+Sisson & Laurie         Expires January 11, 2006                [Page 3]
+
+Internet-Draft     DNS Name Predecessor and Successor          July 2005
+
+
+   S'(N): Successor to N (modified method).
+
+
+3.  Absolute Method
+
+   These derivations assume that all uppercase US-ASCII letters in N
+   have already been replaced by their corresponding lowercase
+   equivalents.  Unless otherwise specified, processing stops after the
+   first step in which a condition is met.
+
+3.1.  Derivation of DNS Name Predecessor
+
+   To derive P(N):
+
+   1.  If N is the same as the owner name of the zone apex, prepend N
+       repeatedly with labels of the maximum length possible consisting
+       of octets of the maximum sort value (e.g. 0xff) until N is the
+       maximum length possible; otherwise continue to the next step.
+
+   2.  If the least significant (left-most) label of N consists of a
+       single octet of the minimum sort value (e.g. 0x00), remove that
+       label; otherwise continue to the next step.
+
+   3.  If the least significant (right-most) octet in the least
+       significant (left-most) label of N is the minimum sort value,
+       remove the least significant octet and continue with step 5.
+
+   4.  Decrement the value of the least significant (right-most) octet,
+       skipping any values that correspond to uppercase US-ASCII
+       letters, and then append the label with as many octets as
+       possible of the maximum sort value.  Continue to the next step.
+
+   5.  Prepend N repeatedly with labels of as long a length as possible
+       consisting of octets of the maximum sort value until N is the
+       maximum length possible.
+
+3.2.  Derivation of DNS Name Successor
+
+   To derive S(N):
+
+   1.  If N is two or more octets shorter than the maximum DNS name
+       length, prepend N with a label containing a single octet of the
+       minimum sort value (e.g. 0x00); otherwise continue to the next
+       step.
+
+   2.  If N is one or more octets shorter than the maximum DNS name
+       length and the least significant (left-most) label is one or more
+       octets shorter than the maximum label length, append an octet of
+
+
+
+Sisson & Laurie         Expires January 11, 2006                [Page 4]
+
+Internet-Draft     DNS Name Predecessor and Successor          July 2005
+
+
+       the minimum sort value to the least significant label; otherwise
+       continue to the next step.
+
+   3.  Increment the value of the least significant (right-most) octet
+       in the least significant (left-most) label that is less than the
+       maximum sort value (e.g. 0xff), skipping any values that
+       correspond to uppercase US-ASCII letters, and then remove any
+       octets to the right of that one.  If all octets in the label are
+       the maximum sort value, then continue to the next step.
+
+   4.  Remove the least significant (left-most) label.  If N is now the
+       same as the owner name of the zone apex, do nothing.  (This will
+       occur only if N is the maximum possible name in canonical DNS
+       name order, and thus has wrapped to the owner name of zone apex.)
+       Otherwise repeat starting at step 2.
+
+
+4.  Modified Method
+
+   This method is for use with zones consisting only of single-label
+   owner names where an owner name consisting of label of maximum length
+   would not result in a DNS name which exceeded the maximum DNS name
+   length.  This method is computationally simpler and returns values
+   which are more economical in size than the absolute method.  It
+   differs from the absolute method detailed above in the following
+   ways:
+
+   1.  Step 1 of the derivation P(N) has been omitted as the existence
+       of the owner name of the zone apex never requires denial.
+
+   2.  A new step 1 has been introduced which removes unnecessary
+       labels.
+
+   3.  Step 4 of the derivation P(N) has been omitted as it is only
+       necessary for zones containing owner names consisting of more
+       than one label.  This omission generally results in a significant
+       reduction of the length of derived predecessors.
+
+   4.  Step 1 of the derivation S(N) had been omitted as it is only
+       necessary for zones containing owner names consisting of more
+       than one label.  This omission results in a tiny reduction of the
+       length of derived successors, and maintains consistency with the
+       modification of step 4 of the derivation P(N) described above.
+
+   5.  Steps 2 and 4 of the derivation S(N) have been modified to
+       eliminate checks for maximum DNS name length, as it is an
+       assumption of this method that no DNS name in the zone can exceed
+       the maximum DNS name length.
+
+
+
+Sisson & Laurie         Expires January 11, 2006                [Page 5]
+
+Internet-Draft     DNS Name Predecessor and Successor          July 2005
+
+
+   These derivations assume that all uppercase US-ASCII letters in N
+   have already been replaced by their corresponding lowercase
+   equivalents.  Unless otherwise specified, processing stops after the
+   first step in which a condition is met.
+
+4.1.  Derivation of DNS Name Predecessor
+
+   To derive P'(N):
+
+   1.  If N has more labels than the number of labels in the owner name
+       of the apex + 1, repeatedly remove the least significant (left-
+       most) label until N has no more labels than the number of labels
+       in the owner name of the apex + 1; otherwise continue to next
+       step.
+
+   2.  If the least significant (left-most) label of N consists of a
+       single octet of the minimum sort value (e.g. 0x00), remove that
+       label; otherwise continue to the next step.
+
+   3.  If the least significant (right-most) octet in the least
+       significant (left-most) label of N is the minimum sort value,
+       remove the least significant octet.
+
+   4.  Decrement the value of the least significant (right-most) octet,
+       skipping any values which correspond to uppercase US-ASCII
+       letters, and then append the label with as many octets as
+       possible of the maximum sort value.
+
+4.2.  Derivation of DNS Name Successor
+
+   To derive S'(N):
+
+   1.  If N has more labels than the number of labels in the owner name
+       of the apex + 1, repeatedly remove the least significant (left-
+       most) label until N has no more labels than the number of labels
+       in the owner name of the apex + 1.  Continue to next step.
+
+   2.  If the least significant (left-most) label of N is one or more
+       octets shorter than the maximum label length, append an octet of
+       the minimum sort value to the least significant label; otherwise
+       continue to the next step.
+
+   3.  Increment the value of the least significant (right-most) octet
+       in the least significant (left-most) label that is less than the
+       maximum sort value (e.g. 0xff), skipping any values which
+       correspond to uppercase US-ASCII letters, and then remove any
+       octets to the right of that one.  If all octets in the label are
+       the maximum sort value, then continue to the next step.
+
+
+
+Sisson & Laurie         Expires January 11, 2006                [Page 6]
+
+Internet-Draft     DNS Name Predecessor and Successor          July 2005
+
+
+   4.  Remove the least significant (left-most) label.  (This will occur
+       only if the least significant label is the maximum label length
+       and consists entirely of octets of the maximum sort value, and
+       thus has wrapped to the owner name of the zone apex.)
+
+
+5.  Notes
+
+5.1.  Case Considerations
+
+   Section 3.5 of [RFC1034] specifies that "while upper and lower case
+   letters are allowed in [DNS] names, no significance is attached to
+   the case".  Additionally, Section 6.1 of [RFC4034] states that when
+   determining canonical DNS name order, "uppercase US-ASCII letters are
+   treated as if they were lowercase US-ASCII letters".  Consequently,
+   values corresponding to US-ASCII uppercase letters must be skipped
+   when decrementing and incrementing octets in the derivations
+   described in Section 3.1 and Section 3.2.
+
+   The following pseudo-code is illustrative:
+
+   Decrement the value of an octet:
+
+      if (octet == '[')       // '[' is just after uppercase 'Z'
+              octet = '@';    // '@' is just prior to uppercase 'A'
+      else
+              octet--;
+
+   Increment the value of an octet:
+
+      if (octet == '@')       // '@' is just prior to uppercase 'A'
+              octet = '[';    // '[' is just after uppercase 'Z'
+      else
+              octet++;
+
+5.2.  Choice of Range
+
+   [RFC2181] makes the clarification that "any binary string whatever
+   can be used as the label of any resource record".  Consequently the
+   minimum sort value may be set as 0x00 and the maximum sort value as
+   0xff, and the range of possible values will be any DNS name which
+   contains octets of any value other than those corresponding to
+   uppercase US-ASCII letters.
+
+   However, if all owner names in a zone are in the letter-digit-hyphen,
+   or LDH, format specified in [RFC1034], it may be desirable to
+   restrict the range of possible values to DNS names containing only
+   LDH values.  This has the effect of:
+
+
+
+Sisson & Laurie         Expires January 11, 2006                [Page 7]
+
+Internet-Draft     DNS Name Predecessor and Successor          July 2005
+
+
+   1.  making the output of tools such as `dig' and `nslookup' less
+       subject to confusion;
+
+   2.  minimising the impact that NSEC RRs containing DNS names with
+       non-LDH values (or non-printable values) might have on faulty DNS
+       resolver implementations; and
+
+   3.  preventing the possibility of results which are wildcard DNS
+       names (see Section 5.3).
+
+   This may be accomplished by using a minimum sort value of 0x1f (US-
+   ASCII character `-') and a maximum sort value of 0x7a (US-ASCII
+   character lowercase `z'), and then skipping non-LDH, non-lowercase
+   values when incrementing or decrementing octets.
+
+5.3.  Wild Card Considerations
+
+   Neither derivation avoids the possibility that the result may be a
+   DNS name containing a wildcard label, i.e. a label containing a
+   single octet with the value 0x2a (US-ASCII character `*').  With
+   additional tests, wildcard DNS names may be explicitly avoided;
+   alternatively, if the range of octet values can be restricted to
+   those corresponding to letter-digit-hyphen, or LDH, characters (see
+   Section 5.2), such DNS names will not occur.
+
+   Note that it is improbable that a result which is a wildcard DNS name
+   will occur unintentionally; even if one does occur either as the
+   owner name of, or in the RDATA of an NSEC RR, it is treated as a
+   literal DNS name with no special meaning.
+
+5.4.  Possible Modifications
+
+5.4.1.  Restriction of Effective Maximum DNS Name Length
+
+   [RFC1034] specifies that "the total number of octets that represent a
+   [DNS] name (i.e., the sum of all label octets and label lengths) is
+   limited to 255", including the null (zero-length) label which
+   represents the root.  For the purpose of deriving predecessors and
+   successors during NSEC RR synthesis, the maximum DNS name length may
+   be effectively restricted to the length of the longest DNS name in
+   the zone.  This will minimise the size of responses containing
+   synthesised NSEC RRs but, especially in the case of the modified
+   method, may result in some additional computational complexity.
+
+   Note that this modification will have the effect of revealing
+   information about the longest name in the zone.  Moreover, when the
+   contents of the zone changes, e.g. during dynamic updates and zone
+   transfers, care must be taken to ensure that the effective maximum
+
+
+
+Sisson & Laurie         Expires January 11, 2006                [Page 8]
+
+Internet-Draft     DNS Name Predecessor and Successor          July 2005
+
+
+   DNS name length agrees with the new contents.
+
+5.4.2.  Use of Modified Method With Zones Containing SRV RRs
+
+   Normally the modified method cannot be used in zones that contain
+   SRV RRs [RFC2782], as SRV RRs have owner names which contain multiple
+   labels.  However the use of SRV RRs can be accommodated by various
+   techniques.  There are at least four possible ways to do this:
+
+   1.  Use conventional NSEC RRs for the region of the zone that
+       contains first-level labels beginning with the underscore (`_')
+       character.  For the purposes of generating these NSEC RRs, the
+       existence of (possibly fictional) ownernames `9{63}' and `a'
+       could be assumed, providing a lower and upper bound for this
+       region.  Then all queries where the QNAME doesn't exist but
+       contains a first-level label beginning with an underscore could
+       be handled using the normal DNSSEC protocol.
+
+       This approach would make it possible to enumerate all DNS names
+       in the zone containing a first-level label beginning with
+       underscore, including all SRV RRs, but this may be of less a
+       concern to the zone administrator than incurring the overhead of
+       the absolute method or of the following variants of the modified
+       method.
+
+   2.  The absolute method could be used for synthesising NSEC RRs for
+       all queries where the QNAME contains a leading underscore.
+       However this re-introduces the susceptibility of the absolute
+       method to denial of service activity, as an attacker could send
+       queries for an effectively inexhaustible supply of domain names
+       beginning with a leading underscore.
+
+   3.  A variant of the modified method could be used for synthesising
+       NSEC RRs for all queries where the QNAME contains a leading
+       underscore.  This variant would assume that all predecessors and
+       successors to queries where the QNAME contains a leading
+       underscore may consist of two lablels rather than only one.  This
+       introduces a little additional complexity without incurring the
+       full increase in response size and computational complexity as
+       the absolute method.
+
+   4.  Finally, a variant the modified method which assumes that all
+       owner names in the zone consist of one or two labels could be
+       used.  However this negates much of the reduction in response
+       size of the modified method and may be nearly as computationally
+       complex as the absolute method.
+
+
+
+
+
+Sisson & Laurie         Expires January 11, 2006                [Page 9]
+
+Internet-Draft     DNS Name Predecessor and Successor          July 2005
+
+
+6.  Examples
+
+   In the following examples:
+
+      the owner name of the zone apex is "example.com.";
+
+      the range of octet values is 0x00 - 0xff excluding values
+      corresponding to uppercase US-ASCII letters; and
+
+      non-printable octet values are expressed as three-digit decimal
+      numbers preceded by a backslash (as specified in Section 5.1 of
+      [RFC1035]).
+
+6.1.  Examples of Immediate Predecessors Using Absolute Method
+
+   Example of typical case:
+
+      P(foo.example.com.) =
+
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255.\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255.\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255.fon\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255.example.com.
+
+      or, in alternate notation:
+
+           \255{49}.\255{63}.\255{63}.fon\255{60}.example.com.
+
+      where {n} represents the number of repetitions of an octet.
+
+
+
+
+
+
+Sisson & Laurie         Expires January 11, 2006               [Page 10]
+
+Internet-Draft     DNS Name Predecessor and Successor          July 2005
+
+
+   Example where least significant (left-most) label of DNS name
+   consists of a single octet of the minimum sort value:
+
+      P(\000.foo.example.com.) = foo.example.com.
+
+   Example where least significant (right-most) octet of least
+   significant (left-most) label has the minimum sort value:
+
+      P(foo\000.example.com.) =
+
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255.\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255.\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255.\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255.foo.example.com.
+
+      or, in alternate notation:
+
+           \255{45}.\255{63}.\255{63}.\255{63}.foo.example.com.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sisson & Laurie         Expires January 11, 2006               [Page 11]
+
+Internet-Draft     DNS Name Predecessor and Successor          July 2005
+
+
+   Example where DNS name contains an octet which must be decremented by
+   skipping values corresponding to US-ASCII uppercase letters:
+
+      P(fo\[.example.com.) =
+
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255.\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255.\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255.fo\@\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255.example.com.
+
+      or, in alternate notation:
+
+           \255{49}.\255{63}.\255{63}.fo\@\255{60}.example.com.
+
+      where {n} represents the number of repetitions of an octet.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sisson & Laurie         Expires January 11, 2006               [Page 12]
+
+Internet-Draft     DNS Name Predecessor and Successor          July 2005
+
+
+   Example where DNS name is the owner name of the zone apex, and
+   consequently wraps to the DNS name with the maximum possible sort
+   order in the zone:
+
+      P(example.com.) =
+
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255.\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255.\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255.\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255.example.com.
+
+      or, in alternate notation:
+
+           \255{49}.\255{63}.\255{63}.\255{63}.example.com.
+
+6.2.  Examples of Immediate Successors Using Absolute Method
+
+   Example of typical case:
+
+      S(foo.example.com.) = \000.foo.example.com.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sisson & Laurie         Expires January 11, 2006               [Page 13]
+
+Internet-Draft     DNS Name Predecessor and Successor          July 2005
+
+
+   Example where DNS name is one octet short of the maximum DNS name
+   length:
+
+      N =  fooooooooooooooooooooooooooooooooooooooooooooooo
+           .ooooooooooooooooooooooooooooooooooooooooooooooo
+           oooooooooooooooo.ooooooooooooooooooooooooooooooo
+           oooooooooooooooooooooooooooooooo.ooooooooooooooo
+           oooooooooooooooooooooooooooooooooooooooooooooooo.example.com.
+
+      or, in alternate notation:
+
+           fo{47}.o{63}.o{63}.o{63}.example.com.
+
+      S(N) =
+
+           fooooooooooooooooooooooooooooooooooooooooooooooo
+           \000.ooooooooooooooooooooooooooooooooooooooooooo
+           oooooooooooooooooooo.ooooooooooooooooooooooooooo
+           oooooooooooooooooooooooooooooooooooo.ooooooooooo
+           oooooooooooooooooooooooooooooooooooooooooooooooo
+           oooo.example.com.
+
+      or, in alternate notation:
+
+           fo{47}\000.o{63}.o{63}.o{63}.example.com.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sisson & Laurie         Expires January 11, 2006               [Page 14]
+
+Internet-Draft     DNS Name Predecessor and Successor          July 2005
+
+
+   Example where DNS name is the maximum DNS name length:
+
+      N  = fooooooooooooooooooooooooooooooooooooooooooooooo
+           o.oooooooooooooooooooooooooooooooooooooooooooooo
+           ooooooooooooooooo.oooooooooooooooooooooooooooooo
+           ooooooooooooooooooooooooooooooooo.oooooooooooooo
+           oooooooooooooooooooooooooooooooooooooooooooooooo
+           o.example.com.
+
+      or, in alternate notation:
+
+           fo{48}.o{63}.o{63}.o{63}.example.com.
+
+      S(N) =
+
+           fooooooooooooooooooooooooooooooooooooooooooooooo
+           p.oooooooooooooooooooooooooooooooooooooooooooooo
+           ooooooooooooooooo.oooooooooooooooooooooooooooooo
+           ooooooooooooooooooooooooooooooooo.oooooooooooooo
+           oooooooooooooooooooooooooooooooooooooooooooooooo
+           o.example.com.
+
+      or, in alternate notation:
+
+           fo{47}p.o{63}.o{63}.o{63}.example.com.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sisson & Laurie         Expires January 11, 2006               [Page 15]
+
+Internet-Draft     DNS Name Predecessor and Successor          July 2005
+
+
+   Example where DNS name is the maximum DNS name length and the least
+   significant (left-most) label has the maximum sort value:
+
+      N =  \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255.ooooooooooooooooooooooooooooooooooooooooooo
+           oooooooooooooooooooo.ooooooooooooooooooooooooooo
+           oooooooooooooooooooooooooooooooooooo.ooooooooooo
+           oooooooooooooooooooooooooooooooooooooooooooooooo
+           oooo.example.com.
+
+      or, in alternate notation:
+
+           \255{49}.o{63}.o{63}.o{63}.example.com.
+
+      S(N) =
+
+           oooooooooooooooooooooooooooooooooooooooooooooooo
+           oooooooooooooop.oooooooooooooooooooooooooooooooo
+           ooooooooooooooooooooooooooooooo.oooooooooooooooo
+           ooooooooooooooooooooooooooooooooooooooooooooooo.
+           example.com.
+
+      or, in alternate notation:
+
+           o{62}p.o{63}.o{63}.example.com.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sisson & Laurie         Expires January 11, 2006               [Page 16]
+
+Internet-Draft     DNS Name Predecessor and Successor          July 2005
+
+
+   Example where DNS name is the maximum DNS name length and the eight
+   least significant (right-most) octets of the least significant (left-
+   most) label have the maximum sort value:
+
+      N  = foooooooooooooooooooooooooooooooooooooooo\255
+           \255\255\255\255\255\255\255.ooooooooooooooooooo
+           oooooooooooooooooooooooooooooooooooooooooooo.ooo
+           oooooooooooooooooooooooooooooooooooooooooooooooo
+           oooooooooooo.ooooooooooooooooooooooooooooooooooo
+           oooooooooooooooooooooooooooo.example.com.
+
+      or, in alternate notation:
+
+           fo{40}\255{8}.o{63}.o{63}.o{63}.example.com.
+
+      S(N) =
+
+           fooooooooooooooooooooooooooooooooooooooop.oooooo
+           oooooooooooooooooooooooooooooooooooooooooooooooo
+           ooooooooo.oooooooooooooooooooooooooooooooooooooo
+           ooooooooooooooooooooooooo.oooooooooooooooooooooo
+           ooooooooooooooooooooooooooooooooooooooooo.example.com.
+
+      or, in alternate notation:
+
+           fo{39}p.o{63}.o{63}.o{63}.example.com.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sisson & Laurie         Expires January 11, 2006               [Page 17]
+
+Internet-Draft     DNS Name Predecessor and Successor          July 2005
+
+
+   Example where DNS name is the maximum DNS name length and contains an
+   octet which must be incremented by skipping values corresponding to
+   US-ASCII uppercase letters:
+
+      N  = fooooooooooooooooooooooooooooooooooooooooooooooo
+           \@.ooooooooooooooooooooooooooooooooooooooooooooo
+           oooooooooooooooooo.ooooooooooooooooooooooooooooo
+           oooooooooooooooooooooooooooooooooo.ooooooooooooo
+           oooooooooooooooooooooooooooooooooooooooooooooooo
+           oo.example.com.
+
+      or, in alternate notation:
+
+           fo{47}\@.o{63}.o{63}.o{63}.example.com.
+
+      S(N) =
+
+           fooooooooooooooooooooooooooooooooooooooooooooooo
+           \[.ooooooooooooooooooooooooooooooooooooooooooooo
+           oooooooooooooooooo.ooooooooooooooooooooooooooooo
+           oooooooooooooooooooooooooooooooooo.ooooooooooooo
+           oooooooooooooooooooooooooooooooooooooooooooooooo
+           oo.example.com.
+
+      or, in alternate notation:
+
+           fo{47}\[.o{63}.o{63}.o{63}.example.com.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sisson & Laurie         Expires January 11, 2006               [Page 18]
+
+Internet-Draft     DNS Name Predecessor and Successor          July 2005
+
+
+   Example where DNS name has the maximum possible sort order in the
+   zone, and consequently wraps to the owner name of the zone apex:
+
+      N  = \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255.\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255.\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255.\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255.example.com.
+
+      or, in alternate notation:
+
+           \255{49}.\255{63}.\255{63}.\255{63}.example.com.
+
+      S(N) = example.com.
+
+6.3.  Examples of Predecessors Using Modified Method
+
+   Example of typical case:
+
+      P'(foo.example.com.) =
+
+           fon\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255.example.com.
+
+      or, in alternate notation:
+
+           fon\255{60}.example.com.
+
+
+
+
+Sisson & Laurie         Expires January 11, 2006               [Page 19]
+
+Internet-Draft     DNS Name Predecessor and Successor          July 2005
+
+
+   Example where DNS name contains more labels than DNS names in the
+   zone:
+
+      P'(bar.foo.example.com.) = foo.example.com.
+
+   Example where least significant (right-most) octet of least
+   significant (left-most) label has the minimum sort value:
+
+      P'(foo\000.example.com.) = foo.example.com.
+
+   Example where least significant (left-most) label has the minimum
+   sort value:
+
+      P'(\000.example.com.) = example.com.
+
+   Example where DNS name is the owner name of the zone apex, and
+   consequently wraps to the DNS name with the maximum possible sort
+   order in the zone:
+
+      P'(example.com.) =
+
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255.example.com.
+
+      or, in alternate notation:
+
+           \255{63}.example.com.
+
+6.4.  Examples of Successors Using Modified Method
+
+   Example of typical case:
+
+      S'(foo.example.com.) = foo\000.example.com.
+
+   Example where DNS name contains more labels than DNS names in the
+   zone:
+
+      S'(bar.foo.example.com.) = foo\000.example.com.
+
+
+
+
+
+
+
+
+
+Sisson & Laurie         Expires January 11, 2006               [Page 20]
+
+Internet-Draft     DNS Name Predecessor and Successor          July 2005
+
+
+   Example where least significant (left-most) label has the maximum
+   sort value, and consequently wraps to the owner name of the zone
+   apex:
+
+      N  = \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255.example.com.
+
+      or, in alternate notation:
+
+           \255{63}.example.com.
+
+      S'(N) = example.com.
+
+
+7.  Security Considerations
+
+   The derivation of some predecessors/successors requires the testing
+   of more conditions than others.  Consequently the effectiveness of a
+   denial-of-service attack may be enhanced by sending queries that
+   require more conditions to be tested.  The modified method involves
+   the testing of fewer conditions than the absolute method and
+   consequently is somewhat less susceptible to this exposure.
+
+
+8.  IANA Considerations
+
+   This document has no IANA actions.
+
+   Note to RFC Editor: This section is included to make it clear during
+   pre-publication review that this document has no IANA actions.  It
+   may therefore be removed should it be published as an RFC.
+
+
+9.  Acknowledgments
+
+   The authors would like to thank Olaf Kolkman, Olafur Gudmundsson and
+   Niall O'Reilly for their review and input.
+
+
+10.  References
+
+
+
+
+
+
+
+Sisson & Laurie         Expires January 11, 2006               [Page 21]
+
+Internet-Draft     DNS Name Predecessor and Successor          July 2005
+
+
+10.1  Normative References
+
+   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
+              STD 13, RFC 1034, November 1987.
+
+   [RFC1035]  Mockapetris, P., "Domain names - implementation and
+              specification", STD 13, RFC 1035, November 1987.
+
+   [RFC2181]  Elz, R. and R. Bush, "Clarifications to the DNS
+              Specification", RFC 2181, July 1997.
+
+   [RFC2782]  Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
+              specifying the location of services (DNS SRV)", RFC 2782,
+              February 2000.
+
+   [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
+              Rose, "Resource Records for the DNS Security Extensions",
+              RFC 4034, March 2005.
+
+10.2  Informative References
+
+   [I-D.ietf-dnsext-dnssec-online-signing]
+              Ihren, J. and S. Weiler, "Minimally Covering NSEC Records
+              and DNSSEC On-line Signing",
+              draft-ietf-dnsext-dnssec-online-signing-00 (work in
+              progress), May 2005.
+
+   [I-D.ietf-dnsext-dnssec-trans]
+              Arends, R., Koch, P., and J. Schlyter, "Evaluating DNSSEC
+              Transition Mechanisms",
+              draft-ietf-dnsext-dnssec-trans-02 (work in progress),
+              February 2005.
+
+
+Appendix A.  Change History
+
+A.1.  Changes from sisson-02 to ietf-00
+
+   o  Added notes on use of SRV RRs with modified method.
+
+   o  Changed reference from weiler-dnssec-online-signing to ietf-
+      dnsext-dnssec-online-signing.
+
+   o  Changed reference from ietf-dnsext-dnssec-records to RFC 4034.
+
+   o  Miscellaneous minor changes to text.
+
+
+
+
+
+Sisson & Laurie         Expires January 11, 2006               [Page 22]
+
+Internet-Draft     DNS Name Predecessor and Successor          July 2005
+
+
+A.2.  Changes from sisson-01 to sisson-02
+
+   o  Added modified version of derivation (with supporting examples).
+
+   o  Introduced notational conventions N, P(N), S(N), P'(N) and S'(N).
+
+   o  Added clarification to derivations about when processing stops.
+
+   o  Miscellaneous minor changes to text.
+
+A.3.  Changes from sisson-00 to sisson-01
+
+   o  Split step 3 of derivation of DNS name predecessor into two
+      distinct steps for clarity.
+
+   o  Added clarifying text and examples related to the requirement to
+      avoid uppercase characters when decrementing or incrementing
+      octets.
+
+   o  Added optimisation using restriction of effective maximum DNS name
+      length.
+
+   o  Changed examples to use decimal rather than octal notation as per
+      [RFC1035].
+
+   o  Corrected DNS name length of some examples.
+
+   o  Added reference to weiler-dnssec-online-signing.
+
+   o  Miscellaneous minor changes to text.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sisson & Laurie         Expires January 11, 2006               [Page 23]
+
+Internet-Draft     DNS Name Predecessor and Successor          July 2005
+
+
+Authors' Addresses
+
+   Geoffrey Sisson
+   Nominet
+   Sandford Gate
+   Sandy Lane West
+   Oxford
+   OX4 6LB
+   GB
+
+   Phone: +44 1865 332339
+   Email: geoff@nominet.org.uk
+
+
+   Ben Laurie
+   Nominet
+   17 Perryn Road
+   London
+   W3 7LR
+   GB
+
+   Phone: +44 20 8735 0686
+   Email: ben@algroup.co.uk
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sisson & Laurie         Expires January 11, 2006               [Page 24]
+
+Internet-Draft     DNS Name Predecessor and Successor          July 2005
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2005).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Sisson & Laurie         Expires January 11, 2006               [Page 25]
+
diff --git a/doc/draft/draft-ietf-dnsext-dnssec-2535typecode-change-06.txt b/doc/draft/draft-ietf-dnsext-dnssec-2535typecode-change-06.txt
new file mode 100644
index 0000000..bcc2b4e
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsext-dnssec-2535typecode-change-06.txt
@@ -0,0 +1,442 @@
+
+
+INTERNET-DRAFT                                             Samuel Weiler
+Expires: June 2004                                     December 15, 2003
+Updates: RFC 2535, [DS]
+
+	 Legacy Resolver Compatibility for Delegation Signer
+	 draft-ietf-dnsext-dnssec-2535typecode-change-06.txt
+
+Status of this Memo
+
+   This document is an Internet-Draft and is subject to 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 draft documents 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 "work in
+   progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/1id-abstracts.html
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html
+
+   Comments should be sent to the author or to the DNSEXT WG mailing
+   list: namedroppers@ops.ietf.org
+
+Abstract
+
+   As the DNS Security (DNSSEC) specifications have evolved, the
+   syntax and semantics of the DNSSEC resource records (RRs) have
+   changed.  Many deployed nameservers understand variants of these
+   semantics.  Dangerous interactions can occur when a resolver that
+   understands an earlier version of these semantics queries an
+   authoritative server that understands the new delegation signer
+   semantics, including at least one failure scenario that will cause
+   an unsecured zone to be unresolvable.  This document changes the
+   type codes and mnemonics of the DNSSEC RRs (SIG, KEY, and NXT) to
+   avoid those interactions.
+
+Changes between 05 and 06:
+
+   Signifigantly reworked the IANA section -- went back to one
+   algorithm registry.
+
+   Removed Diffie-Hellman from the list of zone-signing algorithms
+   (leaving only DSA, RSA/SHA-1, and private algorithms).
+
+   Added a DNSKEY flags field registry.
+
+Changes between 04 and 05:
+
+   IESG approved publication.
+
+   Cleaned up an internal reference in the acknowledgements section.
+
+   Retained KEY and SIG for TKEY, too.  Added TKEY (2930) reference.
+
+   Changed the names of both new registries.  Added algorithm
+   mnemonics to the new zone signing algorithm registry.  Minor
+   rewording in the IANA section for clarity.
+
+   Cleaned up formatting of references.  Replaced unknown-rr draft
+   references with RFC3597.  Bumped DS version number.
+
+Changes between 03 and 04:
+
+   Clarified that RRSIG(0) may be defined by standards action.
+
+   Created a new algorithm registry and renamed the old algorithm
+   registry for SIG(0) only.  Added references to the appropriate
+   crypto algorithm and format specifications.
+
+   Several minor rephrasings.
+
+Changes between 02 and 03:
+
+   KEY (as well as SIG) retained for SIG(0) use only.
+
+Changes between 01 and 02:
+
+   SIG(0) still uses SIG, not RRSIG.  Added 2931 reference.
+
+   Domain names embedded in NSECs and RRSIGs are not compressible and
+   are not downcased.  Added unknown-rrs reference (as informative).
+
+   Simplified the last paragraph of section 3 (NSEC doesn't always
+   signal a negative answer).
+
+   Changed the suggested type code assignments.
+
+   Added 2119 reference.
+
+   Added definitions of "unsecure delegation" and "unsecure referral",
+   since they're not clearly defined elsewhere.
+
+   Moved 2065 to informative references, not normative.
+
+1. Introduction
+
+   The DNSSEC protocol has been through many iterations whose syntax
+   and semantics are not completely compatible.  This has occurred as
+   part of the ordinary process of proposing a protocol, implementing
+   it, testing it in the increasingly complex and diverse environment
+   of the Internet, and refining the definitions of the initial
+   Proposed Standard.  In the case of DNSSEC, the process has been
+   complicated by DNS's criticality and wide deployment and the need
+   to add security while minimizing daily operational complexity.
+
+   A weak area for previous DNS specifications has been lack of detail
+   in specifying resolver behavior, leaving implementors largely on
+   their own to determine many details of resolver function.  This,
+   combined with the number of iterations the DNSSEC spec has been
+   through, has resulted in fielded code with a wide variety of
+   behaviors.  This variety makes it difficult to predict how a
+   protocol change will be handled by all deployed resolvers.  The
+   risk that a change will cause unacceptable or even catastrophic
+   failures makes it difficult to design and deploy a protocol change.
+   One strategy for managing that risk is to structure protocol
+   changes so that existing resolvers can completely ignore input that
+   might confuse them or trigger undesirable failure modes.
+
+   This document addresses a specific problem caused by Delegation
+   Signer's [DS] introduction of new semantics for the NXT RR that are
+   incompatible with the semantics in RFC 2535 [RFC2535].  Answers
+   provided by DS-aware servers can trigger an unacceptable failure
+   mode in some resolvers that implement RFC 2535, which provides a
+   great disincentive to sign zones with DS.  The changes defined in
+   this document allow for the incremental deployment of DS.
+
+1.1 Terminology
+
+   In this document, the term "unsecure delegation" means any
+   delegation for which no DS record appears at the parent.  An
+   "unsecure referral" is an answer from the parent containing an NS
+   RRset and a proof that no DS record exists for that name.
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC2119].
+
+1.2 The Problem
+
+   Delegation Signer introduces new semantics for the NXT RR that are
+   incompatible with the semantics in RFC 2535.  In RFC 2535, NXT
+   records were only required to be returned as part of a
+   non-existence proof.  With DS, an unsecure referral returns, in
+   addition to the NS, a proof of non-existence of a DS RR in the form
+   of an NXT and SIG(NXT).  RFC 2535 didn't specify how a resolver was
+   to interpret a response with both an NS and an NXT in the authority
+   section, RCODE=0, and AA=0.  Some widely deployed 2535-aware
+   resolvers interpret any answer with an NXT as a proof of
+   non-existence of the requested record.  This results in unsecure
+   delegations being invisible to 2535-aware resolvers and violates
+   the basic architectural principle that DNSSEC must do no harm --
+   the signing of zones must not prevent the resolution of unsecured
+   delegations.
+
+2. Possible Solutions
+
+   This section presents several solutions that were considered.
+   Section 3 describes the one selected.
+
+2.1. Change SIG, KEY, and NXT type codes
+
+   To avoid the problem described above, legacy (RFC2535-aware)
+   resolvers need to be kept from seeing unsecure referrals that
+   include NXT records in the authority section.  The simplest way to
+   do that is to change the type codes for SIG, KEY, and NXT.
+
+   The obvious drawback to this is that new resolvers will not be able
+   to validate zones signed with the old RRs.  This problem already
+   exists, however, because of the changes made by DS, and resolvers
+   that understand the old RRs (and have compatibility issues with DS)
+   are far more prevalent than 2535-signed zones.
+
+2.2. Change a subset of type codes
+
+   The observed problem with unsecure referrals could be addressed by
+   changing only the NXT type code or another subset of the type codes
+   that includes NXT.  This has the virtue of apparent simplicity, but
+   it risks introducing new problems or not going far enough.  It's
+   quite possible that more incompatibilities exist between DS and
+   earlier semantics.  Legacy resolvers may also be confused by seeing
+   records they recognize (SIG and KEY) while being unable to find
+   NXTs.  Although it may seem unnecessary to fix that which is not
+   obviously broken, it's far cleaner to change all of the type codes
+   at once.  This will leave legacy resolvers and tools completely
+   blinded to DNSSEC -- they will see only unknown RRs.
+
+2.3. Replace the DO bit
+
+   Another way to keep legacy resolvers from ever seeing DNSSEC
+   records with DS semantics is to have authoritative servers only
+   send that data to DS-aware resolvers.  It's been proposed that
+   assigning a new EDNS0 flag bit to signal DS-awareness (tentatively
+   called "DA"), and having authoritative servers send DNSSEC data
+   only in response to queries with the DA bit set, would accomplish
+   this.  This bit would presumably supplant the DO bit described in
+   RFC 3225.
+
+   This solution is sufficient only if all 2535-aware resolvers zero
+   out EDNS0 flags that they don't understand.  If one passed through
+   the DA bit unchanged, it would still see the new semantics, and it
+   would probably fail to see unsecure delegations.  Since it's
+   impractical to know how every DNS implementation handles unknown
+   EDNS0 flags, this is not a universal solution.  It could, though,
+   be considered in addition to changing the RR type codes.
+
+2.4. Increment the EDNS version
+
+   Another possible solution is to increment the EDNS version number
+   as defined in RFC 2671 [RFC2671], on the assumption that all
+   existing implementations will reject higher versions than they
+   support, and retain the DO bit as the signal for DNSSEC awareness.
+   This approach has not been tested.
+
+2.5. Do nothing
+
+   There is a large deployed base of DNS resolvers that understand
+   DNSSEC as defined by the standards track RFC 2535 and RFC 2065
+   and, due to under specification in those documents, interpret any
+   answer with an NXT as a non-existence proof.  So long as that is
+   the case, zone owners will have a strong incentive to not sign any
+   zones that contain unsecure delegations, lest those delegations be
+   invisible to such a large installed base.  This will dramatically
+   slow DNSSEC adoption.
+
+   Unfortunately, without signed zones there's no clear incentive for
+   operators of resolvers to upgrade their software to support the new
+   version of DNSSEC, as defined in [DS].  Historical data suggests
+   that resolvers are rarely upgraded, and that old nameserver code
+   never dies.
+
+   Rather than wait years for resolvers to be upgraded through natural
+   processes before signing zones with unsecure delegations,
+   addressing this problem with a protocol change will immediately
+   remove the disincentive for signing zones and allow widespread
+   deployment of DNSSEC.
+
+3. Protocol changes
+
+   This document changes the type codes of SIG, KEY, and NXT.  This
+   approach is the cleanest and safest of those discussed above,
+   largely because the behavior of resolvers that receive unknown type
+   codes is well understood.  This approach has also received the most
+   testing.
+
+   To avoid operational confusion, it's also necessary to change the
+   mnemonics for these RRs.  DNSKEY will be the replacement for KEY,
+   with the mnemonic indicating that these keys are not for
+   application use, per [RFC3445].  RRSIG (Resource Record SIGnature)
+   will replace SIG, and NSEC (Next SECure) will replace NXT.  These
+   new types completely replace the old types, except that SIG(0)
+   [RFC2931] and TKEY [RFC2930] will continue to use SIG and KEY.
+
+   The new types will have exactly the same syntax and semantics as
+   specified for SIG, KEY, and NXT in RFC 2535 and [DS] except for
+   the following:
+
+      1) Consistent with [RFC3597], domain names embedded in
+      RRSIG and NSEC RRs MUST NOT be compressed,
+
+      2) Embedded domain names in RRSIG and NSEC RRs are not downcased
+      for purposes of DNSSEC canonical form and ordering nor for
+      equality comparison, and
+
+      3) An RRSIG with a type-covered field of zero has undefined
+      semantics.  The meaning of such a resource record may only be
+      defined by IETF Standards Action.
+
+   If a resolver receives the old types, it SHOULD treat them as
+   unknown RRs and SHOULD NOT assign any special meaning to them or
+   give them any special treatment.  It MUST NOT use them for DNSSEC
+   validations or other DNS operational decision making.  For example,
+   a resolver MUST NOT use DNSKEYs to validate SIGs or use KEYs to
+   validate RRSIGs.  If SIG, KEY, or NXT RRs are included in a zone,
+   they MUST NOT receive special treatment.  As an example, if a SIG
+   is included in a signed zone, there MUST be an RRSIG for it.
+   Authoritative servers may wish to give error messages when loading
+   zones containing SIG or NXT records (KEY records may be included
+   for SIG(0) or TKEY).
+
+   As a clarification to previous documents, some positive responses,
+   particularly wildcard proofs and unsecure referrals, will contain
+   NSEC RRs.  Resolvers MUST NOT treat answers with NSEC RRs as
+   negative answers merely because they contain an NSEC.
+
+4. IANA Considerations
+
+4.1 DNS Resource Record Types
+
+   This document updates the IANA registry for DNS Resource Record
+   Types by assigning types 46, 47, and 48 to the RRSIG, NSEC, and
+   DNSKEY RRs, respectively.
+
+   Types 24 and 25 (SIG and KEY) are retained for SIG(0) [RFC2931] and
+   TKEY [RFC2930] use only.
+
+   Type 30 (NXT) should be marked as Obsolete.
+
+4.2 DNS Security Algorithm Numbers
+
+   To allow zone signing (DNSSEC) and transaction security mechanisms
+   (SIG(0) and TKEY) to use different sets of algorithms, the existing
+   "DNS Security Algorithm Numbers" registry is modified to include
+   the applicability of each algorithm.  Specifically, two new columns
+   are added to the registry, showing whether each algorithm may be
+   used for zone signing, transaction security mechanisms, or both.
+   Only algorithms usable for zone signing may be used in DNSKEY,
+   RRSIG, and DS RRs.  Only algorithms usable for SIG(0) and/or TSIG
+   may be used in SIG and KEY RRs.
+
+   All currently defined algorithms remain usable for transaction
+   security mechanisms.  Only RSA/SHA-1, DSA/SHA-1, and private
+   algorithms (types 253 and 254) may be used for zone signing.  Note
+   that the registry does not contain the requirement level of each
+   algorithm, only whether or not an algorithm may be used for the
+   given purposes.  For example, RSA/MD5, while allowed for
+   transaction security mechanisms, is NOT RECOMMENDED, per RFC3110.
+
+   Additionally, the presentation format algorithm mnemonics from
+   RFC2535 Section 7 are added to the registry.  This document assigns
+   RSA/SHA-1 the mnemonic RSASHA1.
+
+   As before, assignment of new algorithms in this registry requires
+   IETF Standards Action.  Additionally, modification of algorithm
+   mnemonics or applicability requires IETF Standards Action.
+   Documents defining a new algorithm must address the applicability
+   of the algorithm and should assign a presentation mnemonic to the
+   algorithm.
+
+4.3 DNSKEY Flags
+
+   Like the KEY resource record, DNSKEY contains a 16-bit flags field.
+   This document creates a new registry for the DNSKEY flags field.
+
+   Initially, this registry only contains an assignment for bit 7 (the
+   ZONE bit).  Bits 0-6 and 8-15 are available for assignment by IETF
+   Standards Action.
+
+4.4 DNSKEY Protocol Octet
+
+   Like the KEY resource record, DNSKEY contains an eight bit protocol
+   field.  The only defined value for this field is 3 (DNSSEC).  No
+   other values are allowed, hence no IANA registry is needed for this
+   field.
+
+5. Security Considerations
+
+   The changes introduced here do not materially affect security.
+   The implications of trying to use both new and legacy types
+   together are not well understood, and attempts to do so would
+   probably lead to unintended and dangerous results.
+
+   Changing type codes will leave code paths in legacy resolvers that
+   are never exercised.  Unexercised code paths are a frequent source
+   of security holes, largely because those code paths do not get
+   frequent scrutiny.
+
+   Doing nothing, as described in section 2.5, will slow DNSSEC
+   deployment.  While this does not decrease security, it also fails
+   to increase it.
+
+6. Normative references
+
+   [RFC2535] Eastlake, D., "Domain Name System Security Extensions",
+             RFC 2535, March 1999.
+
+   [DS]      Gudmundsson, O., "Delegation Signer Resource Record",
+             draft-ietf-dnsext-delegation-signer-15.txt, work in
+             progress, June 2003.
+
+   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+             Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures
+             (SIG(0)s)", RFC 2931, September 2000.
+
+   [RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY
+             RR)", RFC 2930, September 2000.
+
+   [RFC2536] Eastlake, D., "DSA KEYs and SIGs in the Domain Name
+             System (DNS)", RFC 2436, March 1999.
+
+   [RFC2539] Eastlake, D., "Storage of Diffie-Hellman Keys in the
+             Domain Name System (DNS)", RFC 2539, March 1999.
+
+   [RFC3110] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the
+             Domain Name System (DNS)", RFC 3110, May 2001.
+
+7. Informative References
+
+   [RFC2065] Eastlake, D. and C. Kaufman, "Domain Name System Security
+             Extensions", RFC 2065, January 1997.
+
+   [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
+	     2671, August 1999.
+
+   [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC
+             3225, December 2001.
+
+   [RFC2929] Eastlake, D., E. Brunner-Williams, and B. Manning,
+	     "Domain Name System (DNS) IANA Considerations", BCP 42,
+	     RFC 2929, September 2000.
+
+   [RFC3445] Massey, D., and S. Rose, "Limiting the Scope of the KEY
+	     Resource Record (RR)", RFC 3445, December 2002.
+
+   [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource
+             Record (RR) Types", RFC 3597, September 2003.
+
+8. Acknowledgments
+
+   The changes introduced here and the analysis of alternatives had
+   many contributors.  With apologies to anyone overlooked, those
+   include: Micheal Graff, John Ihren, Olaf Kolkman, Mark Kosters, Ed
+   Lewis, Bill Manning, and Suzanne Woolf.
+
+   Thanks to Jakob Schlyter and Mark Andrews for identifying the
+   incompatibility described in section 1.2.
+
+   In addition to the above, the author would like to thank Scott
+   Rose, Olafur Gudmundsson, and Sandra Murphy for their substantive
+   comments.
+
+9. Author's Address
+
+   Samuel Weiler
+   SPARTA, Inc.
+   7075 Samuel Morse Drive
+   Columbia, MD 21046
+   USA
+   weiler@tislabs.com
+
diff --git a/doc/draft/draft-ietf-dnsext-dnssec-bis-updates-01.txt b/doc/draft/draft-ietf-dnsext-dnssec-bis-updates-01.txt
new file mode 100644
index 0000000..3a800f9
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsext-dnssec-bis-updates-01.txt
@@ -0,0 +1,616 @@
+
+
+
+Network Working Group                                          S. Weiler
+Internet-Draft                                               SPARTA, Inc
+Updates: 4034, 4035 (if approved)                           May 23, 2005
+Expires: November 24, 2005
+
+
+         Clarifications and Implementation Notes for DNSSECbis
+                draft-ietf-dnsext-dnssec-bis-updates-01
+
+Status of this Memo
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   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 draft documents 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 "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/ietf/1id-abstracts.txt.
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+   This Internet-Draft will expire on November 24, 2005.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).
+
+Abstract
+
+   This document is a collection of minor technical clarifications to
+   the DNSSECbis document set.  It is meant to serve as a resource to
+   implementors as well as an interim repository of possible DNSSECbis
+   errata.
+
+
+
+
+
+
+
+Weiler                  Expires November 24, 2005               [Page 1]
+
+Internet-Draft       DNSSECbis Implementation Notes             May 2005
+
+
+Proposed additions in future versions
+
+   An index sorted by the section of DNSSECbis being clarified.
+
+   A list of proposed protocol changes being made in other documents,
+   such as NSEC3 and Epsilon.  This document would not make those
+   changes, merely provide an index into the documents that are making
+   changes.
+
+Changes between -00 and -01
+
+   Document significantly restructured.
+
+   Added section on QTYPE=ANY.
+
+Changes between personal submission and first WG draft
+
+   Added Section 2.1 based on namedroppers discussions from March 9-10,
+   2005.
+
+   Added Section 3.4, Section 3.3, Section 4.3, and Section 2.2.
+
+   Added the DNSSECbis RFC numbers.
+
+   Figured out the confusion in Section 4.1.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Weiler                  Expires November 24, 2005               [Page 2]
+
+Internet-Draft       DNSSECbis Implementation Notes             May 2005
+
+
+Table of Contents
+
+   1.  Introduction and Terminology . . . . . . . . . . . . . . . . .  4
+     1.1   Structure of this Document . . . . . . . . . . . . . . . .  4
+     1.2   Terminology  . . . . . . . . . . . . . . . . . . . . . . .  4
+   2.  Significant Concerns . . . . . . . . . . . . . . . . . . . . .  4
+     2.1   Clarifications on Non-Existence Proofs . . . . . . . . . .  4
+     2.2   Empty Non-Terminal Proofs  . . . . . . . . . . . . . . . .  5
+     2.3   Validating Responses to an ANY Query . . . . . . . . . . .  5
+   3.  Interoperability Concerns  . . . . . . . . . . . . . . . . . .  5
+     3.1   Unknown DS Message Digest Algorithms . . . . . . . . . . .  5
+     3.2   Private Algorithms . . . . . . . . . . . . . . . . . . . .  6
+     3.3   Caution About Local Policy and Multiple RRSIGs . . . . . .  6
+     3.4   Key Tag Calculation  . . . . . . . . . . . . . . . . . . .  7
+   4.  Minor Corrections and Clarifications . . . . . . . . . . . . .  7
+     4.1   Finding Zone Cuts  . . . . . . . . . . . . . . . . . . . .  7
+     4.2   Clarifications on DNSKEY Usage . . . . . . . . . . . . . .  7
+     4.3   Errors in Examples . . . . . . . . . . . . . . . . . . . .  8
+   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  8
+   6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8
+   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  8
+     7.1   Normative References . . . . . . . . . . . . . . . . . . .  8
+     7.2   Informative References . . . . . . . . . . . . . . . . . .  9
+       Author's Address . . . . . . . . . . . . . . . . . . . . . . .  9
+   A.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . .  9
+       Intellectual Property and Copyright Statements . . . . . . . . 11
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Weiler                  Expires November 24, 2005               [Page 3]
+
+Internet-Draft       DNSSECbis Implementation Notes             May 2005
+
+
+1.  Introduction and Terminology
+
+   This document lists some minor clarifications and corrections to
+   DNSSECbis, as described in [1], [2], and [3].
+
+   It is intended to serve as a resource for implementors and as a
+   repository of items that need to be addressed when advancing the
+   DNSSECbis documents from Proposed Standard to Draft Standard.
+
+   In this version (-01 of the WG document), feedback is particularly
+   solicited on the structure of the document and whether the text in
+   the recently added sections is correct and sufficient.
+
+   Proposed substantive additions to this document should be sent to the
+   namedroppers mailing list as well as to the editor of this document.
+   The editor would greatly prefer text suitable for direct inclusion in
+   this document.
+
+1.1  Structure of this Document
+
+   The clarifications to DNSSECbis are sorted according to the editor's
+   impression of their importance, starting with ones which could, if
+   ignored, lead to security and stability problems and progressing down
+   to clarifications that are likely to have little operational impact.
+   Mere typos and awkward phrasings are not addressed unless they could
+   lead to misinterpretation of the DNSSECbis documents.
+
+1.2  Terminology
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [4].
+
+2.  Significant Concerns
+
+   This section provides clarifications that, if overlooked, could lead
+   to security issues or major interoperability problems.
+
+2.1  Clarifications on Non-Existence Proofs
+
+   RFC4035 Section 5.4 slightly underspecifies the algorithm for
+   checking non-existence proofs.  In particular, the algorithm there
+   might incorrectly allow the NSEC from the parent side of a zone cut
+   to prove the non-existence of either other RRs at that name in the
+   child zone or other names in the child zone.  It might also allow a
+   NSEC at the same name as a DNAME to prove the non-existence of names
+   beneath that DNAME.
+
+
+
+
+Weiler                  Expires November 24, 2005               [Page 4]
+
+Internet-Draft       DNSSECbis Implementation Notes             May 2005
+
+
+   A parent-side delegation NSEC (one with the NS bit set, but no SOA
+   bit set, and with a singer field that's shorter than the owner name)
+   must not be used to assume non-existence of any RRs below that zone
+   cut (both RRs at that ownername and at ownernames with more leading
+   labels, no matter their content).  Similarly, an NSEC with the DNAME
+   bit set must not be used to assume the non-existence of any
+   descendant of that NSEC's owner name.
+
+2.2  Empty Non-Terminal Proofs
+
+   To be written, based on Roy Arends' May 11th message to namedroppers.
+
+2.3  Validating Responses to an ANY Query
+
+   RFC4035 does not address now to validate responses when QTYPE=*.  As
+   described in Section 6.2.2 of RFC1034, a proper response to QTYPE=*
+   may include a subset of the RRsets at a given name -- it is not
+   necessary to include all RRsets at the QNAME in the response.
+
+   When validating a response to QTYPE=*, validate all received RRsets
+   that match QNAME and QCLASS.  If any of those RRsets fail validation,
+   treat the answer as Bogus.  If there are no RRsets matching QNAME and
+   QCLASS, validate that fact using the rules in RFC4035 Section 5.4 (as
+   clarified in this document).  To be clear, a validator must not
+   insist on receiving all records at the QNAME in response to QTYPE=*.
+
+3.  Interoperability Concerns
+
+3.1  Unknown DS Message Digest Algorithms
+
+   Section 5.2 of RFC4035 includes rules for how to handle delegations
+   to zones that are signed with entirely unsupported algorithms, as
+   indicated by the algorithms shown in those zone's DS RRsets.  It does
+   not explicitly address how to handle DS records that use unsupported
+   message digest algorithms.  In brief, DS records using unknown or
+   unsupported message digest algorithms MUST be treated the same way as
+   DS records referring to DNSKEY RRs of unknown or unsupported
+   algorithms.
+
+   The existing text says:
+
+      If the validator does not support any of the algorithms listed
+      in an authenticated DS RRset, then the resolver has no supported
+      authentication path leading from the parent to the child.  The
+      resolver should treat this case as it would the case of an
+      authenticated NSEC RRset proving that no DS RRset exists, as
+      described above.
+
+
+
+
+Weiler                  Expires November 24, 2005               [Page 5]
+
+Internet-Draft       DNSSECbis Implementation Notes             May 2005
+
+
+   To paraphrase the above, when determining the security status of a
+   zone, a validator discards (for this purpose only) any DS records
+   listing unknown or unsupported algorithms.  If none are left, the
+   zone is treated as if it were unsigned.
+
+   Modified to consider DS message digest algorithms, a validator also
+   discards any DS records using unknown or unsupported message digest
+   algorithms.
+
+3.2  Private Algorithms
+
+   As discussed above, section 5.2 of RFC4035 requires that validators
+   make decisions about the security status of zones based on the public
+   key algorithms shown in the DS records for those zones.  In the case
+   of private algorithms, as described in RFC4034 Appendix A.1.1, the
+   eight-bit algorithm field in the DS RR is not conclusive about what
+   algorithm(s) is actually in use.
+
+   If no private algorithms appear in the DS set or if any supported
+   algorithm appears in the DS set, no special processing will be
+   needed.  In the remaining cases, the security status of the zone
+   depends on whether or not the resolver supports any of the private
+   algorithms in use (provided that these DS records use supported hash
+   functions, as discussed in Section 3.1).  In these cases, the
+   resolver MUST retrieve the corresponding DNSKEY for each private
+   algorithm DS record and examine the public key field to determine the
+   algorithm in use.  The security-aware resolver MUST ensure that the
+   hash of the DNSKEY RR's owner name and RDATA matches the digest in
+   the DS RR.  If they do not match, and no other DS establishes that
+   the zone is secure, the referral should be considered BAD data, as
+   discussed in RFC4035.
+
+   This clarification facilitates the broader use of private algorithms,
+   as suggested by [5].
+
+3.3  Caution About Local Policy and Multiple RRSIGs
+
+   When multiple RRSIGs cover a given RRset, RFC4035 Section 5.3.3
+   suggests that "the local resolver security policy determines whether
+   the resolver also has to test these RRSIG RRs and how to resolve
+   conflicts if these RRSIG RRs lead to differing results."  In most
+   cases, a resolver would be well advised to accept any valid RRSIG as
+   sufficient.  If the first RRSIG tested fails validation, a resolver
+   would be well advised to try others, giving a successful validation
+   result if any can be validated and giving a failure only if all
+   RRSIGs fail validation.
+
+   If a resolver adopts a more restrictive policy, there's a danger that
+
+
+
+Weiler                  Expires November 24, 2005               [Page 6]
+
+Internet-Draft       DNSSECbis Implementation Notes             May 2005
+
+
+   properly-signed data might unnecessarily fail validation, perhaps
+   because of cache timing issues.  Furthermore, certain zone management
+   techniques, like the Double Signature Zone-signing Key Rollover
+   method described in section 4.2.1.2 of [6] might not work reliably.
+
+3.4  Key Tag Calculation
+
+   RFC4034 Appendix B.1 incorrectly defines the Key Tag field
+   calculation for algorithm 1.  It correctly says that the Key Tag is
+   the most significant 16 of the least significant 24 bits of the
+   public key modulus.  However, RFC4034 then goes on to incorrectly say
+   that this is 4th to last and 3rd to last octets of the public key
+   modulus.  It is, in fact, the 3rd to last and 2nd to last octets.
+
+4.  Minor Corrections and Clarifications
+
+4.1  Finding Zone Cuts
+
+   Appendix C.8 of RFC4035 discusses sending DS queries to the servers
+   for a parent zone.  To do that, a resolver may first need to apply
+   special rules to discover what those servers are.
+
+   As explained in Section 3.1.4.1 of RFC4035, security-aware name
+   servers need to apply special processing rules to handle the DS RR,
+   and in some situations the resolver may also need to apply special
+   rules to locate the name servers for the parent zone if the resolver
+   does not already have the parent's NS RRset.  Section 4.2 of RFC4035
+   specifies a mechanism for doing that.
+
+4.2  Clarifications on DNSKEY Usage
+
+   Questions of the form "can I use a different DNSKEY for signing the
+   X" have occasionally arisen.
+
+   The short answer is "yes, absolutely".  You can even use a different
+   DNSKEY for each RRset in a zone, subject only to practical limits on
+   the size of the DNSKEY RRset.  However, be aware that there is no way
+   to tell resolvers what a particularly DNSKEY is supposed to be used
+   for -- any DNSKEY in the zone's signed DNSKEY RRset may be used to
+   authenticate any RRset in the zone.  For example, if a weaker or less
+   trusted DNSKEY is being used to authenticate NSEC RRsets or all
+   dynamically updated records, that same DNSKEY can also be used to
+   sign any other RRsets from the zone.
+
+   Furthermore, note that the SEP bit setting has no effect on how a
+   DNSKEY may be used -- the validation process is specifically
+   prohibited from using that bit by RFC4034 section 2.1.2.  It possible
+   to use a DNSKEY without the SEP bit set as the sole secure entry
+
+
+
+Weiler                  Expires November 24, 2005               [Page 7]
+
+Internet-Draft       DNSSECbis Implementation Notes             May 2005
+
+
+   point to the zone, yet use a DNSKEY with the SEP bit set to sign all
+   RRsets in the zone (other than the DNSKEY RRset).  It's also possible
+   to use a single DNSKEY, with or without the SEP bit set, to sign the
+   entire zone, including the DNSKEY RRset itself.
+
+4.3  Errors in Examples
+
+   The text in RFC4035 Section C.1 refers to the examples in B.1 as
+   "x.w.example.com" while B.1 uses "x.w.example".  This is painfully
+   obvious in the second paragraph where it states that the RRSIG labels
+   field value of 3 indicates that the answer was not the result of
+   wildcard expansion.  This is true for "x.w.example" but not for
+   "x.w.example.com", which of course has a label count of 4
+   (antithetically, a label count of 3 would imply the answer was the
+   result of a wildcard expansion).
+
+   The first paragraph of RFC4035 Section C.6 also has a minor error:
+   the reference to "a.z.w.w.example" should instead be "a.z.w.example",
+   as in the previous line.
+
+5.  IANA Considerations
+
+   This document specifies no IANA Actions.
+
+6.  Security Considerations
+
+   This document does not make fundamental changes to the DNSSEC
+   protocol, as it was generally understood when DNSSECbis was
+   published.  It does, however, address some ambiguities and omissions
+   in those documents that, if not recognized and addressed in
+   implementations, could lead to security failures.  In particular, the
+   validation algorithm clarifications in Section 2 are critical for
+   preserving the security properties DNSSEC offers.  Furthermore,
+   failure to address some of the interoperability concerns in Section 3
+   could limit the ability to later change or expand DNSSEC, including
+   by adding new algorithms.
+
+7.  References
+
+7.1  Normative References
+
+   [1]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+        "DNS Security Introduction and Requirements", RFC 4033,
+        March 2005.
+
+   [2]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+        "Resource Records for the DNS Security Extensions", RFC 4034,
+        March 2005.
+
+
+
+Weiler                  Expires November 24, 2005               [Page 8]
+
+Internet-Draft       DNSSECbis Implementation Notes             May 2005
+
+
+   [3]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+        "Protocol Modifications for the DNS Security Extensions",
+        RFC 4035, March 2005.
+
+   [4]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
+        Levels", BCP 14, RFC 2119, March 1997.
+
+7.2  Informative References
+
+   [5]  Blacka, D., "DNSSEC Experiments",
+        draft-blacka-dnssec-experiments-00 (work in progress),
+        December 2004.
+
+   [6]  Gieben, R. and O. Kolkman, "DNSSEC Operational Practices",
+        draft-ietf-dnsop-dnssec-operational-practices-04 (work in
+        progress), May 2005.
+
+
+Author's Address
+
+   Samuel Weiler
+   SPARTA, Inc
+   7075 Samuel Morse Drive
+   Columbia, Maryland  21046
+   US
+
+   Email: weiler@tislabs.com
+
+Appendix A.  Acknowledgments
+
+   The editor is extremely grateful to those who, in addition to finding
+   errors and omissions in the DNSSECbis document set, have provided
+   text suitable for inclusion in this document.
+
+   The lack of specificity about handling private algorithms, as
+   described in Section 3.2, and the lack of specificity in handling ANY
+   queries, as described in Section 2.3, were discovered by David
+   Blacka.
+
+   The error in algorithm 1 key tag calculation, as described in
+   Section 3.4, was found by Abhijit Hayatnagarkar.  Donald Eastlake
+   contributed text for Section 3.4.
+
+   The bug relating to delegation NSEC RR's in Section 2.1 was found by
+   Roy Badami.  Roy Arends found the related problem with DNAME.
+
+   The errors in the RFC4035 examples were found by Roy Arends, who also
+   contributed text for Section 4.3 of this document.
+
+
+
+Weiler                  Expires November 24, 2005               [Page 9]
+
+Internet-Draft       DNSSECbis Implementation Notes             May 2005
+
+
+   The editor would like to thank Olafur Gudmundsson and Scott Rose for
+   their substantive comments on the text of this document.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Weiler                  Expires November 24, 2005              [Page 10]
+
+Internet-Draft       DNSSECbis Implementation Notes             May 2005
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2005).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Weiler                  Expires November 24, 2005              [Page 11]
+
diff --git a/doc/draft/draft-ietf-dnsext-dnssec-experiments-01.txt b/doc/draft/draft-ietf-dnsext-dnssec-experiments-01.txt
new file mode 100644
index 0000000..ee03583
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsext-dnssec-experiments-01.txt
@@ -0,0 +1,784 @@
+
+
+
+DNSEXT                                                         D. Blacka
+Internet-Draft                                            Verisign, Inc.
+Expires: January 19, 2006                                  July 18, 2005
+
+
+                           DNSSEC Experiments
+                draft-ietf-dnsext-dnssec-experiments-01
+
+Status of this Memo
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   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 draft documents 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 "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/ietf/1id-abstracts.txt.
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+   This Internet-Draft will expire on January 19, 2006.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).
+
+Abstract
+
+   In the long history of the development of the DNS security extensions
+   [1] (DNSSEC), a number of alternate methodologies and modifications
+   have been proposed and rejected for practical, rather than strictly
+   technical, reasons.  There is a desire to be able to experiment with
+   these alternate methods in the public DNS.  This document describes a
+   methodology for deploying alternate, non-backwards-compatible, DNSSEC
+   methodologies in an experimental fashion without disrupting the
+   deployment of standard DNSSEC.
+
+
+
+
+Blacka                  Expires January 19, 2006                [Page 1]
+
+Internet-Draft             DNSSEC Experiments                  July 2005
+
+
+Table of Contents
+
+   1.   Definitions and Terminology  . . . . . . . . . . . . . . . .   3
+   2.   Overview . . . . . . . . . . . . . . . . . . . . . . . . . .   4
+   3.   Experiments  . . . . . . . . . . . . . . . . . . . . . . . .   5
+   4.   Method . . . . . . . . . . . . . . . . . . . . . . . . . . .   6
+   5.   Defining an Experiment . . . . . . . . . . . . . . . . . . .   8
+   6.   Considerations . . . . . . . . . . . . . . . . . . . . . . .   9
+   7.   Transitions  . . . . . . . . . . . . . . . . . . . . . . . .  10
+   8.   Security Considerations  . . . . . . . . . . . . . . . . . .  11
+   9.   IANA Considerations  . . . . . . . . . . . . . . . . . . . .  12
+   10.  References . . . . . . . . . . . . . . . . . . . . . . . . .  13
+     10.1   Normative References . . . . . . . . . . . . . . . . . .  13
+     10.2   Informative References . . . . . . . . . . . . . . . . .  13
+        Author's Address . . . . . . . . . . . . . . . . . . . . . .  13
+        Intellectual Property and Copyright Statements . . . . . . .  14
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Blacka                  Expires January 19, 2006                [Page 2]
+
+Internet-Draft             DNSSEC Experiments                  July 2005
+
+
+1.  Definitions and Terminology
+
+   Throughout this document, familiarity with the DNS system (RFC 1035
+   [4]) and the DNS security extensions ([1], [2], and [3].
+
+   The key words "MUST, "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY, and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [5].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Blacka                  Expires January 19, 2006                [Page 3]
+
+Internet-Draft             DNSSEC Experiments                  July 2005
+
+
+2.  Overview
+
+   Historically, experimentation with DNSSEC alternatives has been a
+   problematic endeavor.  There has typically been a desire to both
+   introduce non-backwards-compatible changes to DNSSEC, and to try
+   these changes on real zones in the public DNS.  This creates a
+   problem when the change to DNSSEC would make all or part of the zone
+   using those changes appear bogus (bad) or otherwise broken to
+   existing DNSSEC-aware resolvers.
+
+   This document describes a standard methodology for setting up public
+   DNSSEC experiments.  This methodology addresses the issue of co-
+   existence with standard DNSSEC and DNS by using unknown algorithm
+   identifiers to hide the experimental DNSSEC protocol modifications
+   from standard DNSSEC-aware resolvers.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Blacka                  Expires January 19, 2006                [Page 4]
+
+Internet-Draft             DNSSEC Experiments                  July 2005
+
+
+3.  Experiments
+
+   When discussing DNSSEC experiments, it is necessary to classify these
+   experiments into two broad categories:
+
+   Backwards-Compatible: describes experimental changes that, while not
+      strictly adhering to the DNSSEC standard, are nonetheless
+      interoperable with clients and server that do implement the DNSSEC
+      standard.
+
+   Non-Backwards-Compatible: describes experiments that would cause a
+      standard DNSSEC-aware resolver to (incorrectly) determine that all
+      or part of a zone is bogus, or to otherwise not interoperable with
+      standard DNSSEC clients and servers.
+
+   Not included in these terms are experiments with the core DNS
+   protocol itself.
+
+   The methodology described in this document is not necessary for
+   backwards-compatible experiments, although it certainly could be used
+   if desired.
+
+   Note that, in essence, this metholodolgy would also be used to
+   introduce a new DNSSEC algorithm, independently from any DNSSEC
+   experimental protocol change.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Blacka                  Expires January 19, 2006                [Page 5]
+
+Internet-Draft             DNSSEC Experiments                  July 2005
+
+
+4.  Method
+
+   The core of the methodology is the use of strictly "unknown"
+   algorithms to sign the experimental zone, and more importantly,
+   having only unknown algorithm DS records for the delegation to the
+   zone at the parent.
+
+   This technique works because of the way DNSSEC-compliant validators
+   are expected to work in the presence of a DS set with only unknown
+   algorithms.  From [3], Section 5.2:
+
+      If the validator does not support any of the algorithms listed in
+      an authenticated DS RRset, then the resolver has no supported
+      authentication path leading from the parent to the child.  The
+      resolver should treat this case as it would the case of an
+      authenticated NSEC RRset proving that no DS RRset exists, as
+      described above.
+
+   And further:
+
+      If the resolver does not support any of the algorithms listed in
+      an authenticated DS RRset, then the resolver will not be able to
+      verify the authentication path to the child zone.  In this case,
+      the resolver SHOULD treat the child zone as if it were unsigned.
+
+   While this behavior isn't strictly mandatory (as marked by MUST), it
+   is unlikely that a validator would not implement the behavior, or,
+   more to the point, it will not violate this behavior in an unsafe way
+   (see below (Section 6).)
+
+   Because we are talking about experiments, it is RECOMMENDED that
+   private algorithm numbers be used (see [2], appendix A.1.1.  Note
+   that secure handling of private algorithms requires special handing
+   by the validator logic.  See [6] for futher details.)  Normally,
+   instead of actually inventing new signing algorithms, the recommended
+   path is to create alternate algorithm identifiers that are aliases
+   for the existing, known algorithms.  While, strictly speaking, it is
+   only necessary to create an alternate identifier for the mandatory
+   algorithms, it is RECOMMENDED that all OPTIONAL defined algorithms be
+   aliased as well.
+
+   It is RECOMMENDED that for a particular DNSSEC experiment, a
+   particular domain name base is chosen for all new algorithms, then
+   the algorithm number (or name) is prepended to it.  For example, for
+   experiment A, the base name of "dnssec-experiment-a.example.com" is
+   chosen.  Then, aliases for algorithms 3 (DSA) and 5 (RSASHA1) are
+   defined to be "3.dnssec-experiment-a.example.com" and "5.dnssec-
+   experiment-a.example.com".  However, any unique identifier will
+
+
+
+Blacka                  Expires January 19, 2006                [Page 6]
+
+Internet-Draft             DNSSEC Experiments                  July 2005
+
+
+   suffice.
+
+   Using this method, resolvers (or, more specificially, DNSSEC
+   validators) essentially indicate their ability to understand the
+   DNSSEC experiment's semantics by understanding what the new algorithm
+   identifiers signify.
+
+   This method creates two classes of DNSSEC-aware servers and
+   resolvers: servers and resolvers that are aware of the experiment
+   (and thus recognize the experiments algorithm identifiers and
+   experimental semantics), and servers and resolvers that are unware of
+   the experiment.
+
+   This method also precludes any zone from being both in an experiment
+   and in a classic DNSSEC island of security.  That is, a zone is
+   either in an experiment and only experimentally validatable, or it
+   isn't.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Blacka                  Expires January 19, 2006                [Page 7]
+
+Internet-Draft             DNSSEC Experiments                  July 2005
+
+
+5.  Defining an Experiment
+
+   The DNSSEC experiment must define the particular set of (previously
+   unknown) algorithms that identify the experiment, and define what
+   each unknown algorithm identifier means.  Typically, unless the
+   experiment is actually experimenting with a new DNSSEC algorithm,
+   this will be a mapping of private algorithm identifiers to existing,
+   known algorithms.
+
+   Normally the experiment will choose a DNS name as the algorithm
+   identifier base.  This DNS name SHOULD be under the control of the
+   authors of the experiment.  Then the experiment will define a mapping
+   between known mandatory and optional algorithms into this private
+   algorithm identifier space.  Alternately, the experiment MAY use the
+   OID private algorithm space instead (using algorithm number 254), or
+   may choose non-private algorithm numbers, although this would require
+   an IANA allocation (see below (Section 9).)
+
+   For example, an experiment might specify in its description the DNS
+   name "dnssec-experiment-a.example.com" as the base name, and provide
+   the mapping of "3.dnssec-experiment-a.example.com" is an alias of
+   DNSSEC algorithm 3 (DSA), and "5.dnssec-experiment-a.example.com" is
+   an alias of DNSSEC algorithm 5 (RSASHA1).
+
+   Resolvers MUST then only recognize the experiment's semantics when
+   present in a zone signed by one or more of these private algorithms.
+
+   In general, however, resolvers involved in the experiment are
+   expected to understand both standard DNSSEC and the defined
+   experimental DNSSEC protocol, although this isn't required.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Blacka                  Expires January 19, 2006                [Page 8]
+
+Internet-Draft             DNSSEC Experiments                  July 2005
+
+
+6.  Considerations
+
+   There are a number of considerations with using this methodology.
+
+   1.  Under some circumstances, it may be that the experiment will not
+       be sufficiently masked by this technique and may cause resolution
+       problem for resolvers not aware of the experiment.  For instance,
+       the resolver may look at the not validatable response and
+       conclude that the response is bogus, either due to local policy
+       or implementation details.  This is not expected to be the common
+       case, however.
+
+   2.  In general, it will not be possible for DNSSEC-aware resolvers
+       not aware of the experiment to build a chain of trust through an
+       experimental zone.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Blacka                  Expires January 19, 2006                [Page 9]
+
+Internet-Draft             DNSSEC Experiments                  July 2005
+
+
+7.  Transitions
+
+   If an experiment is successful, there may be a desire to move the
+   experiment to a standards-track extension.  One way to do so would be
+   to move from private algorithm numbers to IANA allocated algorithm
+   numbers, with otherwise the same meaning.  This would still leave a
+   divide between resolvers that understood the extension versus
+   resolvers that did not.  It would, in essence, create an additional
+   version of DNSSEC.
+
+   An alternate technique might be to do a typecode rollover, thus
+   actually creating a definitive new version of DNSSEC.  There may be
+   other transition techniques available, as well.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Blacka                  Expires January 19, 2006               [Page 10]
+
+Internet-Draft             DNSSEC Experiments                  July 2005
+
+
+8.  Security Considerations
+
+   Zones using this methodology will be considered insecure by all
+   resolvers except those aware of the experiment.  It is not generally
+   possible to create a secure delegation from an experimental zone that
+   will be followed by resolvers unaware of the experiment.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Blacka                  Expires January 19, 2006               [Page 11]
+
+Internet-Draft             DNSSEC Experiments                  July 2005
+
+
+9.  IANA Considerations
+
+   IANA may need to allocate new DNSSEC algorithm numbers if that
+   transition approach is taken, or the experiment decides to use
+   allocated numbers to begin with.  No IANA action is required to
+   deploy an experiment using private algorithm identifiers.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Blacka                  Expires January 19, 2006               [Page 12]
+
+Internet-Draft             DNSSEC Experiments                  July 2005
+
+
+10.  References
+
+10.1  Normative References
+
+   [1]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+        "DNS Security Introduction and Requirements", RFC 4033,
+        March 2005.
+
+   [2]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+        "Resource Records for the DNS Security Extensions", RFC 4034,
+        March 2005.
+
+   [3]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+        "Protocol Modifications for the DNS Security Extensions",
+        RFC 4035, March 2005.
+
+10.2  Informative References
+
+   [4]  Mockapetris, P., "Domain names - implementation and
+        specification", STD 13, RFC 1035, November 1987.
+
+   [5]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
+        Levels", BCP 14, RFC 2119, March 1997.
+
+   [6]  Weiler, S., "Clarifications and Implementation Notes for
+        DNSSECbis", draft-weiler-dnsext-dnssec-bis-updates-00 (work in
+        progress), March 2005.
+
+
+Author's Address
+
+   David Blacka
+   Verisign, Inc.
+   21355 Ridgetop Circle
+   Dulles, VA  20166
+   US
+
+   Phone: +1 703 948 3200
+   Email: davidb@verisign.com
+   URI:   http://www.verisignlabs.com
+
+
+
+
+
+
+
+
+
+
+
+Blacka                  Expires January 19, 2006               [Page 13]
+
+Internet-Draft             DNSSEC Experiments                  July 2005
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2005).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Blacka                  Expires January 19, 2006               [Page 14]
+
diff --git a/doc/draft/draft-ietf-dnsext-dnssec-online-signing-02.txt b/doc/draft/draft-ietf-dnsext-dnssec-online-signing-02.txt
new file mode 100644
index 0000000..7503c66
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsext-dnssec-online-signing-02.txt
@@ -0,0 +1,616 @@
+
+
+
+Network Working Group                                          S. Weiler
+Internet-Draft                                               SPARTA, Inc
+Updates: 4034, 4035 (if approved)                               J. Ihren
+Expires: July 24, 2006                                     Autonomica AB
+                                                        January 20, 2006
+
+
+       Minimally Covering NSEC Records and DNSSEC On-line Signing
+               draft-ietf-dnsext-dnssec-online-signing-02
+
+Status of this Memo
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   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 draft documents 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 "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/ietf/1id-abstracts.txt.
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+   This Internet-Draft will expire on July 24, 2006.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   This document describes how to construct DNSSEC NSEC resource records
+   that cover a smaller range of names than called for by RFC4034.  By
+   generating and signing these records on demand, authoritative name
+   servers can effectively stop the disclosure of zone contents
+   otherwise made possible by walking the chain of NSEC records in a
+   signed zone.
+
+
+
+
+Weiler & Ihren            Expires July 24, 2006                 [Page 1]
+
+Internet-Draft                NSEC Epsilon                  January 2006
+
+
+Changes from ietf-01 to ietf-02
+
+   Clarified that a generated NSEC RR's type bitmap MUST have the RRSIG
+   and NSEC bits set, to be consistent with DNSSECbis -- previous text
+   said SHOULD.
+
+   Made the applicability statement a little less oppressive.
+
+Changes from ietf-00 to ietf-01
+
+   Added an applicability statement, making reference to ongoing work on
+   NSEC3.
+
+   Added the phrase "epsilon functions", which has been commonly used to
+   describe the technique and already appeared in the header of each
+   page, in place of "increment and decrement functions".  Also added an
+   explanatory sentence.
+
+   Corrected references from 4034 section 6.2 to section 6.1.
+
+   Fixed an out-of-date reference to [-bis] and other typos.
+
+   Replaced IANA Considerations text.
+
+   Escaped close parentheses in examples.
+
+   Added some more acknowledgements.
+
+Changes from weiler-01 to ietf-00
+
+   Inserted RFC numbers for 4033, 4034, and 4035.
+
+   Specified contents of bitmap field in synthesized NSEC RR's, pointing
+   out that this relaxes a constraint in 4035.  Added 4035 to the
+   Updates header.
+
+Changes from weiler-00 to weiler-01
+
+   Clarified that this updates RFC4034 by relaxing requirements on the
+   next name field.
+
+   Added examples covering wildcard names.
+
+   In the 'better functions' section, reiterated that perfect functions
+   aren't needed.
+
+   Added a reference to RFC 2119.
+
+
+
+
+Weiler & Ihren            Expires July 24, 2006                 [Page 2]
+
+Internet-Draft                NSEC Epsilon                  January 2006
+
+
+Table of Contents
+
+   1.  Introduction and Terminology . . . . . . . . . . . . . . . . .  4
+   2.  Applicability of This Technique  . . . . . . . . . . . . . . .  4
+   3.  Minimally Covering NSEC Records  . . . . . . . . . . . . . . .  5
+   4.  Better Epsilon Functions . . . . . . . . . . . . . . . . . . .  6
+   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  7
+   6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  7
+   7.  Normative References . . . . . . . . . . . . . . . . . . . . .  8
+   Appendix A.  Acknowledgments . . . . . . . . . . . . . . . . . . .  8
+   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
+   Intellectual Property and Copyright Statements . . . . . . . . . . 11
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Weiler & Ihren            Expires July 24, 2006                 [Page 3]
+
+Internet-Draft                NSEC Epsilon                  January 2006
+
+
+1.  Introduction and Terminology
+
+   With DNSSEC [1], an NSEC record lists the next instantiated name in
+   its zone, proving that no names exist in the "span" between the
+   NSEC's owner name and the name in the "next name" field.  In this
+   document, an NSEC record is said to "cover" the names between its
+   owner name and next name.
+
+   Through repeated queries that return NSEC records, it is possible to
+   retrieve all of the names in the zone, a process commonly called
+   "walking" the zone.  Some zone owners have policies forbidding zone
+   transfers by arbitrary clients; this side-effect of the NSEC
+   architecture subverts those policies.
+
+   This document presents a way to prevent zone walking by constructing
+   NSEC records that cover fewer names.  These records can make zone
+   walking take approximately as many queries as simply asking for all
+   possible names in a zone, making zone walking impractical.  Some of
+   these records must be created and signed on demand, which requires
+   on-line private keys.  Anyone contemplating use of this technique is
+   strongly encouraged to review the discussion of the risks of on-line
+   signing in Section 6.
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [4].
+
+
+2.  Applicability of This Technique
+
+   The technique presented here may be useful to a zone owner that wants
+   to use DNSSEC, is concerned about exposure of its zone contents via
+   zone walking, and is willing to bear the costs of on-line signing.
+
+   As discussed in Section 6, on-line signing has several security
+   risks, including an increased likelihood of private keys being
+   disclosed and an increased risk of denial of service attack.  Anyone
+   contemplating use of this technique is strongly encouraged to review
+   the discussion of the risks of on-line signing in Section 6.
+
+   Furthermore, at the time this document was published, the DNSEXT
+   working group was actively working on a mechanism to prevent zone
+   walking that does not require on-line signing (tentatively called
+   NSEC3).  The new mechanism is likely to expose slightly more
+   information about the zone than this technique (e.g. the number of
+   instantiated names), but it may be preferable to this technique.
+
+
+
+
+
+Weiler & Ihren            Expires July 24, 2006                 [Page 4]
+
+Internet-Draft                NSEC Epsilon                  January 2006
+
+
+3.  Minimally Covering NSEC Records
+
+   This mechanism involves changes to NSEC records for instantiated
+   names, which can still be generated and signed in advance, as well as
+   the on-demand generation and signing of new NSEC records whenever a
+   name must be proven not to exist.
+
+   In the 'next name' field of instantiated names' NSEC records, rather
+   than list the next instantiated name in the zone, list any name that
+   falls lexically after the NSEC's owner name and before the next
+   instantiated name in the zone, according to the ordering function in
+   RFC4034 [2] section 6.1.  This relaxes the requirement in section
+   4.1.1 of RFC4034 that the 'next name' field contains the next owner
+   name in the zone.  This change is expected to be fully compatible
+   with all existing DNSSEC validators.  These NSEC records are returned
+   whenever proving something specifically about the owner name (e.g.
+   that no resource records of a given type appear at that name).
+
+   Whenever an NSEC record is needed to prove the non-existence of a
+   name, a new NSEC record is dynamically produced and signed.  The new
+   NSEC record has an owner name lexically before the QNAME but
+   lexically following any existing name and a 'next name' lexically
+   following the QNAME but before any existing name.
+
+   The generated NSEC record's type bitmap MUST have the RRSIG and NSEC
+   bits set and SHOULD NOT have any other bits set.  This relaxes the
+   requirement in Section 2.3 of RFC4035 that NSEC RRs not appear at
+   names that did not exist before the zone was signed.
+
+   The functions to generate the lexically following and proceeding
+   names need not be perfect nor consistent, but the generated NSEC
+   records must not cover any existing names.  Furthermore, this
+   technique works best when the generated NSEC records cover as few
+   names as possible.  In this document, the functions that generate the
+   nearby names are called 'epsilon' functions, a reference to the
+   mathematical convention of using the greek letter epsilon to
+   represent small deviations.
+
+   An NSEC record denying the existence of a wildcard may be generated
+   in the same way.  Since the NSEC record covering a non-existent
+   wildcard is likely to be used in response to many queries,
+   authoritative name servers using the techniques described here may
+   want to pregenerate or cache that record and its corresponding RRSIG.
+
+   For example, a query for an A record at the non-instantiated name
+   example.com might produce the following two NSEC records, the first
+   denying the existence of the name example.com and the second denying
+   the existence of a wildcard:
+
+
+
+Weiler & Ihren            Expires July 24, 2006                 [Page 5]
+
+Internet-Draft                NSEC Epsilon                  January 2006
+
+
+             exampld.com 3600 IN NSEC example-.com ( RRSIG NSEC )
+
+             \).com 3600 IN NSEC +.com ( RRSIG NSEC )
+
+   Before answering a query with these records, an authoritative server
+   must test for the existence of names between these endpoints.  If the
+   generated NSEC would cover existing names (e.g. exampldd.com or
+   *bizarre.example.com), a better epsilon function may be used or the
+   covered name closest to the QNAME could be used as the NSEC owner
+   name or next name, as appropriate.  If an existing name is used as
+   the NSEC owner name, that name's real NSEC record MUST be returned.
+   Using the same example, assuming an exampldd.com delegation exists,
+   this record might be returned from the parent:
+
+             exampldd.com 3600 IN NSEC example-.com ( NS DS RRSIG NSEC )
+
+   Like every authoritative record in the zone, each generated NSEC
+   record MUST have corresponding RRSIGs generated using each algorithm
+   (but not necessarily each DNSKEY) in the zone's DNSKEY RRset, as
+   described in RFC4035 [3] section 2.2.  To minimize the number of
+   signatures that must be generated, a zone may wish to limit the
+   number of algorithms in its DNSKEY RRset.
+
+
+4.  Better Epsilon Functions
+
+   Section 6.1 of RFC4034 defines a strict ordering of DNS names.
+   Working backwards from that definition, it should be possible to
+   define epsilon functions that generate the immediately following and
+   preceding names, respectively.  This document does not define such
+   functions.  Instead, this section presents functions that come
+   reasonably close to the perfect ones.  As described above, an
+   authoritative server should still ensure than no generated NSEC
+   covers any existing name.
+
+   To increment a name, add a leading label with a single null (zero-
+   value) octet.
+
+   To decrement a name, decrement the last character of the leftmost
+   label, then fill that label to a length of 63 octets with octets of
+   value 255.  To decrement a null (zero-value) octet, remove the octet
+   -- if an empty label is left, remove the label.  Defining this
+   function numerically: fill the left-most label to its maximum length
+   with zeros (numeric, not ASCII zeros) and subtract one.
+
+   In response to a query for the non-existent name foo.example.com,
+   these functions produce NSEC records of:
+
+
+
+
+Weiler & Ihren            Expires July 24, 2006                 [Page 6]
+
+Internet-Draft                NSEC Epsilon                  January 2006
+
+
+     fon\255\255\255\255\255\255\255\255\255\255\255\255\255\255
+     \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
+     \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
+     \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
+     \255.example.com 3600 IN NSEC \000.foo.example.com ( NSEC RRSIG )
+
+     \)\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
+     \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
+     \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
+     \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
+     \255\255.example.com 3600 IN NSEC \000.*.example.com ( NSEC RRSIG )
+
+   The first of these NSEC RRs proves that no exact match for
+   foo.example.com exists, and the second proves that there is no
+   wildcard in example.com.
+
+   Both of these functions are imperfect: they don't take into account
+   constraints on number of labels in a name nor total length of a name.
+   As noted in the previous section, though, this technique does not
+   depend on the use of perfect epsilon functions: it is sufficient to
+   test whether any instantiated names fall into the span covered by the
+   generated NSEC and, if so, substitute those instantiated owner names
+   for the NSEC owner name or next name, as appropriate.
+
+
+5.  IANA Considerations
+
+   This document specifies no IANA Actions.
+
+
+6.  Security Considerations
+
+   This approach requires on-demand generation of RRSIG records.  This
+   creates several new vulnerabilities.
+
+   First, on-demand signing requires that a zone's authoritative servers
+   have access to its private keys.  Storing private keys on well-known
+   internet-accessible servers may make them more vulnerable to
+   unintended disclosure.
+
+   Second, since generation of digital signatures tends to be
+   computationally demanding, the requirement for on-demand signing
+   makes authoritative servers vulnerable to a denial of service attack.
+
+   Lastly, if the epsilon functions are predictable, on-demand signing
+   may enable a chosen-plaintext attack on a zone's private keys.  Zones
+   using this approach should attempt to use cryptographic algorithms
+   that are resistant to chosen-plaintext attacks.  It's worth noting
+
+
+
+Weiler & Ihren            Expires July 24, 2006                 [Page 7]
+
+Internet-Draft                NSEC Epsilon                  January 2006
+
+
+   that while DNSSEC has a "mandatory to implement" algorithm, that is a
+   requirement on resolvers and validators -- there is no requirement
+   that a zone be signed with any given algorithm.
+
+   The success of using minimally covering NSEC record to prevent zone
+   walking depends greatly on the quality of the epsilon functions
+   chosen.  An increment function that chooses a name obviously derived
+   from the next instantiated name may be easily reverse engineered,
+   destroying the value of this technique.  An increment function that
+   always returns a name close to the next instantiated name is likewise
+   a poor choice.  Good choices of epsilon functions are the ones that
+   produce the immediately following and preceding names, respectively,
+   though zone administrators may wish to use less perfect functions
+   that return more human-friendly names than the functions described in
+   Section 4 above.
+
+   Another obvious but misguided concern is the danger from synthesized
+   NSEC records being replayed.  It's possible for an attacker to replay
+   an old but still validly signed NSEC record after a new name has been
+   added in the span covered by that NSEC, incorrectly proving that
+   there is no record at that name.  This danger exists with DNSSEC as
+   defined in [3].  The techniques described here actually decrease the
+   danger, since the span covered by any NSEC record is smaller than
+   before.  Choosing better epsilon functions will further reduce this
+   danger.
+
+7.  Normative References
+
+   [1]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+        "DNS Security Introduction and Requirements", RFC 4033,
+        March 2005.
+
+   [2]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+        "Resource Records for the DNS Security Extensions", RFC 4034,
+        March 2005.
+
+   [3]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+        "Protocol Modifications for the DNS Security Extensions",
+        RFC 4035, March 2005.
+
+   [4]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
+        Levels", BCP 14, RFC 2119, March 1997.
+
+
+Appendix A.  Acknowledgments
+
+   Many individuals contributed to this design.  They include, in
+   addition to the authors of this document, Olaf Kolkman, Ed Lewis,
+
+
+
+Weiler & Ihren            Expires July 24, 2006                 [Page 8]
+
+Internet-Draft                NSEC Epsilon                  January 2006
+
+
+   Peter Koch, Matt Larson, David Blacka, Suzanne Woolf, Jaap Akkerhuis,
+   Jakob Schlyter, Bill Manning, and Joao Damas.
+
+   In addition, the editors would like to thank Ed Lewis, Scott Rose,
+   and David Blacka for their careful review of the document.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Weiler & Ihren            Expires July 24, 2006                 [Page 9]
+
+Internet-Draft                NSEC Epsilon                  January 2006
+
+
+Authors' Addresses
+
+   Samuel Weiler
+   SPARTA, Inc
+   7075 Samuel Morse Drive
+   Columbia, Maryland  21046
+   US
+
+   Email: weiler@tislabs.com
+
+
+   Johan Ihren
+   Autonomica AB
+   Bellmansgatan 30
+   Stockholm  SE-118 47
+   Sweden
+
+   Email: johani@autonomica.se
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Weiler & Ihren            Expires July 24, 2006                [Page 10]
+
+Internet-Draft                NSEC Epsilon                  January 2006
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2006).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Weiler & Ihren            Expires July 24, 2006                [Page 11]
+
diff --git a/doc/draft/draft-ietf-dnsext-dnssec-opt-in-07.txt b/doc/draft/draft-ietf-dnsext-dnssec-opt-in-07.txt
new file mode 100644
index 0000000..17e28e8
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsext-dnssec-opt-in-07.txt
@@ -0,0 +1,896 @@
+
+
+
+DNSEXT                                                         R. Arends
+Internet-Draft                                      Telematica Instituut
+Expires: January 19, 2006                                     M. Kosters
+                                                               D. Blacka
+                                                          Verisign, Inc.
+                                                           July 18, 2005
+
+
+                             DNSSEC Opt-In
+                   draft-ietf-dnsext-dnssec-opt-in-07
+
+Status of this Memo
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   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 draft documents 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 "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/ietf/1id-abstracts.txt.
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+   This Internet-Draft will expire on January 19, 2006.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).
+
+Abstract
+
+   In the DNS security extensions (DNSSEC, defined in RFC 4033 [3], RFC
+   4034 [4], and RFC 4035 [5]), delegations to unsigned subzones are
+   cryptographically secured.  Maintaining this cryptography is not
+   practical or necessary.  This document describes an experimental
+   "Opt-In" model that allows administrators to omit this cryptography
+   and manage the cost of adopting DNSSEC with large zones.
+
+
+
+Arends, et al.          Expires January 19, 2006                [Page 1]
+
+Internet-Draft                DNSSEC Opt-In                    July 2005
+
+
+Table of Contents
+
+   1.  Definitions and Terminology  . . . . . . . . . . . . . . . . .  3
+   2.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   3.  Experimental Status  . . . . . . . . . . . . . . . . . . . . .  4
+   4.  Protocol Additions . . . . . . . . . . . . . . . . . . . . . .  4
+     4.1   Server Considerations  . . . . . . . . . . . . . . . . . .  5
+       4.1.1   Delegations Only . . . . . . . . . . . . . . . . . . .  5
+       4.1.2   Insecure Delegation Responses  . . . . . . . . . . . .  6
+       4.1.3   Wildcards and Opt-In . . . . . . . . . . . . . . . . .  6
+       4.1.4   Dynamic Update . . . . . . . . . . . . . . . . . . . .  7
+     4.2   Client Considerations  . . . . . . . . . . . . . . . . . .  7
+       4.2.1   Delegations Only . . . . . . . . . . . . . . . . . . .  7
+       4.2.2   Validation Process Changes . . . . . . . . . . . . . .  7
+       4.2.3   NSEC Record Caching  . . . . . . . . . . . . . . . . .  8
+       4.2.4   Use of the AD bit  . . . . . . . . . . . . . . . . . .  8
+   5.  Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . .  8
+   6.  Example  . . . . . . . . . . . . . . . . . . . . . . . . . . .  9
+   7.  Transition Issues  . . . . . . . . . . . . . . . . . . . . . . 10
+   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
+   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 12
+   10.   Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . 12
+   11.   References . . . . . . . . . . . . . . . . . . . . . . . . . 13
+     11.1  Normative References . . . . . . . . . . . . . . . . . . . 13
+     11.2  Informative References . . . . . . . . . . . . . . . . . . 13
+       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14
+   A.  Implementing Opt-In using "Views"  . . . . . . . . . . . . . . 14
+       Intellectual Property and Copyright Statements . . . . . . . . 16
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al.          Expires January 19, 2006                [Page 2]
+
+Internet-Draft                DNSSEC Opt-In                    July 2005
+
+
+1.  Definitions and Terminology
+
+   Throughout this document, familiarity with the DNS system (RFC 1035
+   [1]), DNS security extensions ([3], [4], and [5], referred to in this
+   document as "standard DNSSEC"), and DNSSEC terminology (RFC 3090
+   [10]) is assumed.
+
+   The following abbreviations and terms are used in this document:
+
+   RR: is used to refer to a DNS resource record.
+   RRset: refers to a Resource Record Set, as defined by [8].  In this
+      document, the RRset is also defined to include the covering RRSIG
+      records, if any exist.
+   signed name: refers to a DNS name that has, at minimum, a (signed)
+      NSEC record.
+   unsigned name: refers to a DNS name that does not (at least) have a
+      NSEC record.
+   covering NSEC record/RRset: is the NSEC record used to prove
+      (non)existence of a particular name or RRset.  This means that for
+      a RRset or name 'N', the covering NSEC record has the name 'N', or
+      has an owner name less than 'N' and "next" name greater than 'N'.
+   delegation: refers to a NS RRset with a name different from the
+      current zone apex (non-zone-apex), signifying a delegation to a
+      subzone.
+   secure delegation: refers to a signed name containing a delegation
+      (NS RRset), and a signed DS RRset, signifying a delegation to a
+      signed subzone.
+   insecure delegation: refers to a signed name containing a delegation
+      (NS RRset), but lacking a DS RRset, signifying a delegation to an
+      unsigned subzone.
+   Opt-In insecure delegation: refers to an unsigned name containing
+      only a delegation NS RRset.  The covering NSEC record uses the
+      Opt-In methodology described in this document.
+
+   The key words "MUST, "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY, and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [7].
+
+2.  Overview
+
+   The cost to cryptographically secure delegations to unsigned zones is
+   high for large delegation-centric zones and zones where insecure
+   delegations will be updated rapidly.  For these zones, the costs of
+   maintaining the NSEC record chain may be extremely high relative to
+   the gain of cryptographically authenticating existence of unsecured
+   zones.
+
+   This document describes an experimental method of eliminating the
+
+
+
+Arends, et al.          Expires January 19, 2006                [Page 3]
+
+Internet-Draft                DNSSEC Opt-In                    July 2005
+
+
+   superfluous cryptography present in secure delegations to unsigned
+   zones.  Using "Opt-In", a zone administrator can choose to remove
+   insecure delegations from the NSEC chain.  This is accomplished by
+   extending the semantics of the NSEC record by using a redundant bit
+   in the type map.
+
+3.  Experimental Status
+
+   This document describes an EXPERIMENTAL extension to DNSSEC.  It
+   interoperates with non-experimental DNSSEC using the technique
+   described in [6].  This experiment is identified with the following
+   private algorithms (using algorithm 253):
+
+   "3.optin.verisignlabs.com": is an alias for DNSSEC algorithm 3, DSA,
+      and
+   "5.optin.verisignlabs.com": is an alias for DNSSEC algorithm 5,
+      RSASHA1.
+
+   Servers wishing to sign and serve zones that utilize Opt-In MUST sign
+   the zone with only one or more of these private algorithms.  This
+   requires the signing tools and servers to support private algorithms,
+   as well as Opt-In.
+
+   Resolvers wishing to validate Opt-In zones MUST only do so when the
+   zone is only signed using one or more of these private algorithms.
+
+   The remainder of this document assumes that the servers and resolvers
+   involved are aware of and are involved in this experiment.
+
+4.  Protocol Additions
+
+   In DNSSEC, delegation NS RRsets are not signed, but are instead
+   accompanied by a NSEC RRset of the same name and (possibly) a DS
+   record.  The security status of the subzone is determined by the
+   presence or absence of the DS RRset, cryptographically proven by the
+   NSEC record.  Opt-In expands this definition by allowing insecure
+   delegations to exist within an otherwise signed zone without the
+   corresponding NSEC record at the delegation's owner name.  These
+   insecure delegations are proven insecure by using a covering NSEC
+   record.
+
+   Since this represents a change of the interpretation of NSEC records,
+   resolvers must be able to distinguish between RFC standard DNSSEC
+   NSEC records and Opt-In NSEC records.  This is accomplished by
+   "tagging" the NSEC records that cover (or potentially cover) insecure
+   delegation nodes.  This tag is indicated by the absence of the NSEC
+   bit in the type map.  Since the NSEC bit in the type map merely
+   indicates the existence of the record itself, this bit is redundant
+
+
+
+Arends, et al.          Expires January 19, 2006                [Page 4]
+
+Internet-Draft                DNSSEC Opt-In                    July 2005
+
+
+   and safe for use as a tag.
+
+   An Opt-In tagged NSEC record does not assert the (non)existence of
+   the delegations that it covers (except for a delegation with the same
+   name).  This allows for the addition or removal of these delegations
+   without recalculating or resigning records in the NSEC chain.
+   However, Opt-In tagged NSEC records do assert the (non)existence of
+   other RRsets.
+
+   An Opt-In NSEC record MAY have the same name as an insecure
+   delegation.  In this case, the delegation is proven insecure by the
+   lack of a DS bit in type map and the signed NSEC record does assert
+   the existence of the delegation.
+
+   Zones using Opt-In MAY contain a mixture of Opt-In tagged NSEC
+   records and standard DNSSEC NSEC records.  If a NSEC record is not
+   Opt-In, there MUST NOT be any insecure delegations (or any other
+   records) between it and the RRsets indicated by the 'next domain
+   name' in the NSEC RDATA.  If it is Opt-In, there MUST only be
+   insecure delegations between it and the next node indicated by the
+   'next domain name' in the NSEC RDATA.
+
+   In summary,
+
+   o  An Opt-In NSEC type is identified by a zero-valued (or not-
+      specified) NSEC bit in the type bit map of the NSEC record.
+   o  A RFC2535bis NSEC type is identified by a one-valued NSEC bit in
+      the type bit map of the NSEC record.
+
+   and,
+
+   o  An Opt-In NSEC record does not assert the non-existence of a name
+      between its owner name and "next" name, although it does assert
+      that any name in this span MUST be an insecure delegation.
+   o  An Opt-In NSEC record does assert the (non)existence of RRsets
+      with the same owner name.
+
+4.1  Server Considerations
+
+   Opt-In imposes some new requirements on authoritative DNS servers.
+
+4.1.1  Delegations Only
+
+   This specification dictates that only insecure delegations may exist
+   between the owner and "next" names of an Opt-In tagged NSEC record.
+   Signing tools SHOULD NOT generate signed zones that violate this
+   restriction.  Servers SHOULD refuse to load and/or serve zones that
+   violate this restriction.  Servers also SHOULD reject AXFR or IXFR
+
+
+
+Arends, et al.          Expires January 19, 2006                [Page 5]
+
+Internet-Draft                DNSSEC Opt-In                    July 2005
+
+
+   responses that violate this restriction.
+
+4.1.2  Insecure Delegation Responses
+
+   When returning an Opt-In insecure delegation, the server MUST return
+   the covering NSEC RRset in the Authority section.
+
+   In standard DNSSEC, NSEC records already must be returned along with
+   the insecure delegation.  The primary difference that this proposal
+   introduces is that the Opt-In tagged NSEC record will have a
+   different owner name from the delegation RRset.  This may require
+   implementations to search for the covering NSEC RRset.
+
+4.1.3  Wildcards and Opt-In
+
+   Standard DNSSEC describes the practice of returning NSEC records to
+   prove the non-existence of an applicable wildcard in non-existent
+   name responses.  This NSEC record can be described as a "negative
+   wildcard proof".  The use of Opt-In NSEC records changes the
+   necessity for this practice.  For non-existent name responses when
+   the query name (qname) is covered by an Opt-In tagged NSEC record,
+   servers MAY choose to omit the wildcard proof record, and clients
+   MUST NOT treat the absence of this NSEC record as a validation error.
+
+   The intent of the standard DNSSEC negative wildcard proof requirement
+   is to prevent malicious users from undetectably removing valid
+   wildcard responses.  In order for this cryptographic proof to work,
+   the resolver must be able to prove:
+
+   1.  The exact qname does not exist.  This is done by the "normal"
+       NSEC record.
+   2.  No applicable wildcard exists.  This is done by returning a NSEC
+       record proving that the wildcard does not exist (this is the
+       negative wildcard proof).
+
+   However, if the NSEC record covering the exact qname is an Opt-In
+   NSEC record, the resolver will not be able to prove the first part of
+   this equation, as the qname might exist as an insecure delegation.
+   Thus, since the total proof cannot be completed, the negative
+   wildcard proof NSEC record is not useful.
+
+   The negative wildcard proof is also not useful when returned as part
+   of an Opt-In insecure delegation response for a similar reason: the
+   resolver cannot prove that the qname does or does not exist, and
+   therefore cannot prove that a wildcard expansion is valid.
+
+   The presence of an Opt-In tagged NSEC record does not change the
+   practice of returning a NSEC along with a wildcard expansion.  Even
+
+
+
+Arends, et al.          Expires January 19, 2006                [Page 6]
+
+Internet-Draft                DNSSEC Opt-In                    July 2005
+
+
+   though the Opt-In NSEC will not be able to prove that the wildcard
+   expansion is valid, it will prove that the wildcard expansion is not
+   masking any signed records.
+
+4.1.4  Dynamic Update
+
+   Opt-In changes the semantics of Secure DNS Dynamic Update [9].  In
+   particular, it introduces the need for rules that describe when to
+   add or remove a delegation name from the NSEC chain.  This document
+   does not attempt to define these rules.  Until these rules are
+   defined, servers MUST NOT process DNS Dynamic Update requests against
+   zones that use Opt-In NSEC records.  Servers SHOULD return responses
+   to update requests with RCODE=REFUSED.
+
+4.2  Client Considerations
+
+   Opt-In imposes some new requirements on security-aware resolvers
+   (caching or otherwise).
+
+4.2.1  Delegations Only
+
+   As stated in the "Server Considerations" section above, this
+   specification restricts the namespace covered by Opt-In tagged NSEC
+   records to insecure delegations only.  Thus, resolvers MUST reject as
+   invalid any records that fall within an Opt-In NSEC record's span
+   that are not NS records or corresponding glue records.
+
+4.2.2  Validation Process Changes
+
+   This specification does not change the resolver's resolution
+   algorithm.  However, it does change the DNSSEC validation process.
+   Resolvers MUST be able to use Opt-In tagged NSEC records to
+   cryptographically prove the validity and security status (as
+   insecure) of a referral.  Resolvers determine the security status of
+   the referred-to zone as follows:
+
+   o  In standard DNSSEC, the security status is proven by the existence
+      or absence of a DS RRset at the same name as the delegation.  The
+      existence of the DS RRset indicates that the referred-to zone is
+      signed.  The absence of the DS RRset is proven using a verified
+      NSEC record of the same name that does not have the DS bit set in
+      the type map.  This NSEC record MAY also be tagged as Opt-In.
+   o  Using Opt-In, the security status is proven by the existence of a
+      DS record (for signed) or the presence of a verified Opt-In tagged
+      NSEC record that covers the delegation name.  That is, the NSEC
+      record does not have the NSEC bit set in the type map, and the
+      delegation name falls between the NSEC's owner and "next" name.
+
+
+
+
+Arends, et al.          Expires January 19, 2006                [Page 7]
+
+Internet-Draft                DNSSEC Opt-In                    July 2005
+
+
+   Using Opt-In does not substantially change the nature of following
+   referrals within DNSSEC.  At every delegation point, the resolver
+   will have cryptographic proof that the referred-to subzone is signed
+   or unsigned.
+
+   When receiving either an Opt-In insecure delegation response or a
+   non-existent name response where that name is covered by an Opt-In
+   tagged NSEC record, the resolver MUST NOT require proof (in the form
+   of a NSEC record) that a wildcard did not exist.
+
+4.2.3  NSEC Record Caching
+
+   Caching resolvers MUST be able to retrieve the appropriate covering
+   Opt-In NSEC record when returning referrals that need them.  This
+   requirement differs from standard DNSSEC in that the covering NSEC
+   will not have the same owner name as the delegation.  Some
+   implementations may have to use new methods for finding these NSEC
+   records.
+
+4.2.4  Use of the AD bit
+
+   The AD bit, as defined by [2] and [5], MUST NOT be set when:
+
+   o  sending a Name Error (RCODE=3) response where the covering NSEC is
+      tagged as Opt-In.
+   o  sending an Opt-In insecure delegation response, unless the
+      covering (Opt-In) NSEC record's owner name equals the delegation
+      name.
+
+   This rule is based on what the Opt-In NSEC record actually proves:
+   for names that exist between the Opt-In NSEC record's owner and
+   "next" names, the Opt-In NSEC record cannot prove the non-existence
+   or existence of the name.  As such, not all data in the response has
+   been cryptographically verified, so the AD bit cannot be set.
+
+5.  Benefits
+
+   Using Opt-In allows administrators of large and/or changing
+   delegation-centric zones to minimize the overhead involved in
+   maintaining the security of the zone.
+
+   Opt-In accomplishes this by eliminating the need for NSEC records for
+   insecure delegations.  This, in a zone with a large number of
+   delegations to unsigned subzones, can lead to substantial space
+   savings (both in memory and on disk).  Additionally, Opt-In allows
+   for the addition or removal of insecure delegations without modifying
+   the NSEC record chain.  Zones that are frequently updating insecure
+   delegations (e.g., TLDs) can avoid the substantial overhead of
+
+
+
+Arends, et al.          Expires January 19, 2006                [Page 8]
+
+Internet-Draft                DNSSEC Opt-In                    July 2005
+
+
+   modifying and resigning the affected NSEC records.
+
+6.  Example
+
+   Consider the zone EXAMPLE, shown below.  This is a zone where all of
+   the NSEC records are tagged as Opt-In.
+
+   Example A: Fully Opt-In Zone.
+
+         EXAMPLE.               SOA    ...
+         EXAMPLE.               RRSIG  SOA ...
+         EXAMPLE.               NS     FIRST-SECURE.EXAMPLE.
+         EXAMPLE.               RRSIG  NS ...
+         EXAMPLE.               DNSKEY ...
+         EXAMPLE.               RRSIG  DNSKEY ...
+         EXAMPLE.               NSEC   FIRST-SECURE.EXAMPLE. (
+                                       SOA NS RRSIG DNSKEY )
+         EXAMPLE.               RRSIG  NSEC ...
+
+         FIRST-SECURE.EXAMPLE.  A      ...
+         FIRST-SECURE.EXAMPLE.  RRSIG  A ...
+         FIRST-SECURE.EXAMPLE.  NSEC   NOT-SECURE-2.EXAMPLE. A RRSIG
+         FIRST-SECURE.EXAMPLE.  RRSIG  NSEC ...
+
+         NOT-SECURE.EXAMPLE.    NS     NS.NOT-SECURE.EXAMPLE.
+         NS.NOT-SECURE.EXAMPLE. A      ...
+
+         NOT-SECURE-2.EXAMPLE.  NS     NS.NOT-SECURE.EXAMPLE.
+         NOT-SECURE-2.EXAMPLE   NSEC   SECOND-SECURE.EXAMPLE NS RRSIG
+         NOT-SECURE-2.EXAMPLE   RRSIG  NSEC ...
+
+         SECOND-SECURE.EXAMPLE. NS     NS.ELSEWHERE.
+         SECOND-SECURE.EXAMPLE. DS     ...
+         SECOND-SECURE.EXAMPLE. RRSIG  DS ...
+         SECOND-SECURE.EXAMPLE. NSEC   EXAMPLE. NS RRSIG DNSKEY
+         SECOND-SECURE.EXAMPLE. RRSIG  NSEC ...
+
+         UNSIGNED.EXAMPLE.      NS     NS.UNSIGNED.EXAMPLE.
+         NS.UNSIGNED.EXAMPLE.   A      ...
+
+
+   In this example, a query for a signed RRset (e.g., "FIRST-
+   SECURE.EXAMPLE A"), or a secure delegation ("WWW.SECOND-
+   SECURE.EXAMPLE A") will result in a standard DNSSEC response.
+
+   A query for a nonexistent RRset will result in a response that
+   differs from standard DNSSEC by: the NSEC record will be tagged as
+   Opt-In, there may be no NSEC record proving the non-existence of a
+
+
+
+Arends, et al.          Expires January 19, 2006                [Page 9]
+
+Internet-Draft                DNSSEC Opt-In                    July 2005
+
+
+   matching wildcard record, and the AD bit will not be set.
+
+   A query for an insecure delegation RRset (or a referral) will return
+   both the answer (in the Authority section) and the corresponding
+   Opt-In NSEC record to prove that it is not secure.
+
+   Example A.1: Response to query for WWW.UNSIGNED.EXAMPLE.  A
+
+
+         RCODE=NOERROR, AD=0
+
+         Answer Section:
+
+         Authority Section:
+         UNSIGNED.EXAMPLE.      NS     NS.UNSIGNED.EXAMPLE
+         SECOND-SECURE.EXAMPLE. NSEC   EXAMPLE. NS RRSIG DS
+         SECOND-SECURE.EXAMPLE. RRSIG  NSEC ...
+
+         Additional Section:
+         NS.UNSIGNED.EXAMPLE.   A      ...
+
+   In the Example A.1 zone, the EXAMPLE. node MAY use either style of
+   NSEC record, because there are no insecure delegations that occur
+   between it and the next node, FIRST-SECURE.EXAMPLE.  In other words,
+   Example A would still be a valid zone if the NSEC record for EXAMPLE.
+   was changed to the following RR:
+
+         EXAMPLE.               NSEC   FIRST-SECURE.EXAMPLE. (SOA NS
+                                       RRSIG DNSKEY NSEC )
+
+   However, the other NSEC records (FIRST-SECURE.EXAMPLE. and SECOND-
+   SECURE.EXAMPLE.)  MUST be tagged as Opt-In because there are insecure
+   delegations in the range they define.  (NOT-SECURE.EXAMPLE. and
+   UNSIGNED.EXAMPLE., respectively).
+
+   NOT-SECURE-2.EXAMPLE. is an example of an insecure delegation that is
+   part of the NSEC chain and also covered by an Opt-In tagged NSEC
+   record.  Because NOT-SECURE-2.EXAMPLE. is a signed name, it cannot be
+   removed from the zone without modifying and resigning the prior NSEC
+   record.  Delegations with names that fall between NOT-SECURE-
+   2.EXAMPLE. and SECOND-SECURE.EXAMPLE. may be added or removed without
+   resigning any NSEC records.
+
+7.  Transition Issues
+
+   Opt-In is not backwards compatible with standard DNSSEC and is
+   considered experimental.  Standard DNSSEC compliant implementations
+   would not recognize Opt-In tagged NSEC records as different from
+
+
+
+Arends, et al.          Expires January 19, 2006               [Page 10]
+
+Internet-Draft                DNSSEC Opt-In                    July 2005
+
+
+   standard NSEC records.  Because of this, standard DNSSEC
+   implementations, if they were to validate Opt-In style responses,
+   would reject all Opt-In insecure delegations within a zone as
+   invalid.  However, by only signing with private algorithms, standard
+   DNSSEC implementations will treat Opt-In responses as unsigned.
+
+   It should be noted that all elements in the resolution path between
+   (and including) the validator and the authoritative name server must
+   be aware of the Opt-In experiment and implement the Opt-In semantics
+   for successful validation to be possible.  In particular, this
+   includes any caching middleboxes between the validator and
+   authoritative name server.
+
+8.  Security Considerations
+
+   Opt-In allows for unsigned names, in the form of delegations to
+   unsigned subzones, to exist within an otherwise signed zone.  All
+   unsigned names are, by definition, insecure, and their validity or
+   existence cannot by cryptographically proven.
+
+   In general:
+
+   o  Records with unsigned names (whether existing or not) suffer from
+      the same vulnerabilities as records in an unsigned zone.  These
+      vulnerabilities are described in more detail in [12] (note in
+      particular sections 2.3, "Name Games" and 2.6, "Authenticated
+      Denial").
+   o  Records with signed names have the same security whether or not
+      Opt-In is used.
+
+   Note that with or without Opt-In, an insecure delegation may have its
+   contents undetectably altered by an attacker.  Because of this, the
+   primary difference in security that Opt-In introduces is the loss of
+   the ability to prove the existence or nonexistence of an insecure
+   delegation within the span of an Opt-In NSEC record.
+
+   In particular, this means that a malicious entity may be able to
+   insert or delete records with unsigned names.  These records are
+   normally NS records, but this also includes signed wildcard
+   expansions (while the wildcard record itself is signed, its expanded
+   name is an unsigned name).
+
+   For example, if a resolver received the following response from the
+   example zone above:
+
+
+
+
+
+
+
+Arends, et al.          Expires January 19, 2006               [Page 11]
+
+Internet-Draft                DNSSEC Opt-In                    July 2005
+
+
+   Example S.1: Response to query for WWW.DOES-NOT-EXIST.EXAMPLE.  A
+
+         RCODE=NOERROR
+
+         Answer Section:
+
+         Authority Section:
+         DOES-NOT-EXIST.EXAMPLE. NS     NS.FORGED.
+         EXAMPLE.                NSEC   FIRST-SECURE.EXAMPLE. SOA NS \
+                                        RRSIG DNSKEY
+         EXAMPLE.                RRSIG  NSEC ...
+
+         Additional Section:
+
+
+   The resolver would have no choice but to believe that the referral to
+   NS.FORGED. is valid.  If a wildcard existed that would have been
+   expanded to cover "WWW.DOES-NOT-EXIST.EXAMPLE.", an attacker could
+   have undetectably removed it and replaced it with the forged
+   delegation.
+
+   Note that being able to add a delegation is functionally equivalent
+   to being able to add any record type: an attacker merely has to forge
+   a delegation to nameserver under his/her control and place whatever
+   records needed at the subzone apex.
+
+   While in particular cases, this issue may not present a significant
+   security problem, in general it should not be lightly dismissed.
+   Therefore, it is strongly RECOMMENDED that Opt-In be used sparingly.
+   In particular, zone signing tools SHOULD NOT default to Opt-In, and
+   MAY choose to not support Opt-In at all.
+
+9.  IANA Considerations
+
+   None.
+
+10.  Acknowledgments
+
+   The contributions, suggestions and remarks of the following persons
+   (in alphabetic order) to this draft are acknowledged:
+
+      Mats Dufberg, Miek Gieben, Olafur Gudmundsson, Bob Halley, Olaf
+      Kolkman, Edward Lewis, Ted Lindgreen, Rip Loomis, Bill Manning,
+      Dan Massey, Scott Rose, Mike Schiraldi, Jakob Schlyter, Brian
+      Wellington.
+
+11.  References
+
+
+
+
+Arends, et al.          Expires January 19, 2006               [Page 12]
+
+Internet-Draft                DNSSEC Opt-In                    July 2005
+
+
+11.1  Normative References
+
+   [1]  Mockapetris, P., "Domain names - implementation and
+        specification", STD 13, RFC 1035, November 1987.
+
+   [2]  Wellington, B. and O. Gudmundsson, "Redefinition of DNS
+        Authenticated Data (AD) bit", RFC 3655, November 2003.
+
+   [3]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+        "DNS Security Introduction and Requirements", RFC 4033,
+        March 2005.
+
+   [4]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+        "Resource Records for the DNS Security Extensions", RFC 4034,
+        March 2005.
+
+   [5]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+        "Protocol Modifications for the DNS Security Extensions",
+        RFC 4035, March 2005.
+
+   [6]  Blacka, D., "DNSSEC Experiments",
+        draft-ietf-dnsext-dnssec-experiments-01 (work in progress),
+        July 2005.
+
+11.2  Informative References
+
+   [7]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
+         Levels", BCP 14, RFC 2119, March 1997.
+
+   [8]   Elz, R. and R. Bush, "Clarifications to the DNS Specification",
+         RFC 2181, July 1997.
+
+   [9]   Eastlake, D., "Secure Domain Name System Dynamic Update",
+         RFC 2137, April 1997.
+
+   [10]  Lewis, E., "DNS Security Extension Clarification on Zone
+         Status", RFC 3090, March 2001.
+
+   [11]  Conrad, D., "Indicating Resolver Support of DNSSEC", RFC 3225,
+         December 2001.
+
+   [12]  Atkins, D. and R. Austein, "Threat Analysis of the Domain Name
+         System (DNS)", RFC 3833, August 2004.
+
+
+
+
+
+
+
+
+Arends, et al.          Expires January 19, 2006               [Page 13]
+
+Internet-Draft                DNSSEC Opt-In                    July 2005
+
+
+Authors' Addresses
+
+   Roy Arends
+   Telematica Instituut
+   Drienerlolaan 5
+   7522 NB  Enschede
+   NL
+
+   Email: roy.arends@telin.nl
+
+
+   Mark Kosters
+   Verisign, Inc.
+   21355 Ridgetop Circle
+   Dulles, VA  20166
+   US
+
+   Phone: +1 703 948 3200
+   Email: markk@verisign.com
+   URI:   http://www.verisignlabs.com
+
+
+   David Blacka
+   Verisign, Inc.
+   21355 Ridgetop Circle
+   Dulles, VA  20166
+   US
+
+   Phone: +1 703 948 3200
+   Email: davidb@verisign.com
+   URI:   http://www.verisignlabs.com
+
+Appendix A.  Implementing Opt-In using "Views"
+
+   In many cases, it may be convenient to implement an Opt-In zone by
+   combining two separately maintained "views" of a zone at request
+   time.  In this context, "view" refers to a particular version of a
+   zone, not to any specific DNS implementation feature.
+
+   In this scenario, one view is the secure view, the other is the
+   insecure (or legacy) view.  The secure view consists of an entirely
+   signed zone using Opt-In tagged NSEC records.  The insecure view
+   contains no DNSSEC information.  It is helpful, although not
+   necessary, for the secure view to be a subset (minus DNSSEC records)
+   of the insecure view.
+
+   In addition, the only RRsets that may solely exist in the insecure
+   view are non-zone-apex NS RRsets.  That is, all non-NS RRsets (and
+
+
+
+Arends, et al.          Expires January 19, 2006               [Page 14]
+
+Internet-Draft                DNSSEC Opt-In                    July 2005
+
+
+   the zone apex NS RRset) MUST be signed and in the secure view.
+
+   These two views may be combined at request time to provide a virtual,
+   single Opt-In zone.  The following algorithm is used when responding
+   to each query:
+      V_A is the secure view as described above.
+      V_B is the insecure view as described above.
+      R_A is a response generated from V_A, following RFC 2535bis.
+      R_B is a response generated from V_B, following DNS resolution as
+      per RFC 1035 [1].
+      R_C is the response generated by combining R_A with R_B, as
+      described below.
+      A query is DNSSEC-aware if it either has the DO bit [11] turned
+      on, or is for a DNSSEC-specific record type.
+
+
+
+   1.  If V_A is a subset of V_B and the query is not DNSSEC-aware,
+       generate and return R_B, otherwise
+   2.  Generate R_A.
+   3.  If R_A's RCODE != NXDOMAIN, return R_A, otherwise
+   4.  Generate R_B and combine it with R_A to form R_C:
+          For each section (ANSWER, AUTHORITY, ADDITIONAL), copy the
+          records from R_A into R_B, EXCEPT the AUTHORITY section SOA
+          record, if R_B's RCODE = NOERROR.
+   5.  Return R_C.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al.          Expires January 19, 2006               [Page 15]
+
+Internet-Draft                DNSSEC Opt-In                    July 2005
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2005).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Arends, et al.          Expires January 19, 2006               [Page 16]
+
diff --git a/doc/draft/draft-ietf-dnsext-dnssec-rsasha256-00.txt b/doc/draft/draft-ietf-dnsext-dnssec-rsasha256-00.txt
new file mode 100644
index 0000000..390420a
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsext-dnssec-rsasha256-00.txt
@@ -0,0 +1,392 @@
+
+
+
+DNS Extensions working group                                   J. Jansen
+Internet-Draft                                                NLnet Labs
+Expires: July 5, 2006                                       January 2006
+
+
+     Use of RSA/SHA-256 DNSKEY and RRSIG Resource Records in DNSSEC
+                 draft-ietf-dnsext-dnssec-rsasha256-00
+
+Status of this Memo
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   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 draft documents 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 "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/ietf/1id-abstracts.txt.
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+   This Internet-Draft will expire on July 5, 2006.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   This document describes how to produce RSA/SHA-256 DNSKEY and RRSIG
+   resource records for use in the Domain Name System Security
+   Extensions (DNSSEC, RFC4033, RFC4034, and RFC4035).
+
+
+
+
+
+
+
+
+
+Jansen                    Expires July 5, 2006                  [Page 1]
+
+Internet-Draft       RSA/SHA-256 DNSKEYs and RRSIGS         January 2006
+
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
+   2.  RSA/SHA-256 DNSKEY Resource Records . . . . . . . . . . . . . . 3
+   3.  RSA/SHA-256 RRSIG Resource Records  . . . . . . . . . . . . . . 3
+   4.  Implementation Considerations . . . . . . . . . . . . . . . . . 4
+   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4
+   6.  Security Considerations . . . . . . . . . . . . . . . . . . . . 4
+   7.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 5
+   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 5
+     8.1.  Normative References  . . . . . . . . . . . . . . . . . . . 5
+     8.2.  Informative References  . . . . . . . . . . . . . . . . . . 5
+   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 6
+   Intellectual Property and Copyright Statements  . . . . . . . . . . 7
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Jansen                    Expires July 5, 2006                  [Page 2]
+
+Internet-Draft       RSA/SHA-256 DNSKEYs and RRSIGS         January 2006
+
+
+1.  Introduction
+
+   The Domain Name System (DNS) is the global hierarchical distributed
+   database for Internet Addressing.  The DNS has been extended to use
+   digital signatures and cryptographic keys for the verification of
+   data.  RFC4033 [1], RFC4034 [2], and RFC4035 [3] describe these DNS
+   Security Extensions.
+
+   RFC4034 describes how to store DNSKEY and RRSIG resource records, and
+   specifies a list of cryptographic algorithms to use.  This document
+   extends that list with the algorithm RSA/SHA-256, and specifies how
+   to store RSA/SHA-256 DNSKEY data and how to produce RSA/SHA-256 RRSIG
+   resource records.
+
+   Familiarity with the RSA [7] and SHA-256 [5] algorithms is assumed in
+   this document.
+
+
+2.  RSA/SHA-256 DNSKEY Resource Records
+
+   RSA public keys for use with RSA/SHA-256 are stored in DNSKEY
+   resource records (RRs) with the algorithm number [TBA].
+
+   The format of the DNSKEY RR can be found in RFC4034 [2] and RFC3110
+   [6].
+
+
+3.  RSA/SHA-256 RRSIG Resource Records
+
+   RSA/SHA-256 signatures are stored in the DNS using RRSIG resource
+   records (RRs) with algorithm number [TBA].
+
+   The value of the signature field in the RRSIG RR is calculated as
+   follows.  The values for the fields that precede the signature data
+   are specified in RFC4034 [2].
+
+   hash = SHA-256(data)
+
+   signature = ( 00 | 01 | FF* | 00 | prefix | hash ) ** e (mod n)
+
+   Where SHA-256 is the message digest algorithm as specified in FIPS
+   180 [5], | is concatenation, 00, 01, FF and 00 are fixed octets of
+   corresponding hexadecimal value, "e" is the private exponent of the
+   signing RSA key, and "n" is the public modulus of the signing key.
+   The FF octet MUST be repeated the maximum number of times so that the
+   total length of the signature equals the length of the modulus of the
+   signer's public key ("n"). "data" is the data of the resource record
+   set that is signed, as specified in RFC4034 [2].
+
+
+
+Jansen                    Expires July 5, 2006                  [Page 3]
+
+Internet-Draft       RSA/SHA-256 DNSKEYs and RRSIGS         January 2006
+
+
+   The prefix is the ASN.1 BER SHA-256 algorithm designator prefix as
+   specified in PKCS 2.1 [4]:
+
+   hex 30 31 30 0d 06 09 60 86 48 01 65 03 04 02 01 05 00 04 20
+
+   This prefix should make the use of standard cryptographic libraries
+   easier.  These specifications are taken directly from PKCS #1 v2.1
+   section 9.2 [4].
+
+
+4.  Implementation Considerations
+
+   DNSSEC aware implementations MUST be able to support RRSIG resource
+   records with the RSA/SHA-256 algorithm.
+
+   If both RSA/SHA-256 and RSA/SHA-1 RRSIG resource records are
+   available for a certain rrset, with a secure path to their keys, the
+   validator SHOULD ignore the SHA-1 signature.  If the RSA/SHA-256
+   signature does not verify the data, and the RSA/SHA-1 does, the
+   validator SHOULD mark the data with the security status from the RSA/
+   SHA-256 signature.
+
+
+5.  IANA Considerations
+
+   IANA has not yet assigned an algorithm number for RSA/SHA-256.
+
+   The algorithm list from RFC4034 Appendix A.1 [2] is extended with the
+   following entry:
+
+                                   Zone
+   Value Algorithm    [Mnemonic] Signing  References   Status
+   ----- ----------- ----------- -------- ----------  ---------
+   [tba] RSA/SHA-256 [RSASHA256]      y        [TBA]  MANDATORY
+
+
+6.  Security Considerations
+
+   Recently, weaknesses have been discovered in the SHA-1 hashing
+   algorithm.  It is therefore strongly encouraged to deploy SHA-256
+   where SHA-1 is used now, as soon as the DNS software supports it.
+
+   SHA-256 is considered sufficiently strong for the immediate future,
+   but predictions about future development in cryptography and
+   cryptanalysis are beyond the scope of this document.
+
+
+
+
+
+
+Jansen                    Expires July 5, 2006                  [Page 4]
+
+Internet-Draft       RSA/SHA-256 DNSKEYs and RRSIGS         January 2006
+
+
+7.  Acknowledgments
+
+   This document is a minor extension to RFC4034 [2].  Also, we try to
+   follow the documents RFC3110 [6] and draft-ietf-dnsext-ds-sha256.txt
+   [8] for consistency.  The authors of and contributors to these
+   documents are gratefully acknowledged for their hard work.
+
+   The following people provided additional feedback and text: Jaap
+   Akkerhuis, Miek Gieben and Wouter Wijngaards.
+
+
+8.  References
+
+8.1.  Normative References
+
+   [1]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+        "DNS Security Introduction and Requirements", RFC 4033,
+        March 2005.
+
+   [2]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+        "Resource Records for the DNS Security Extensions", RFC 4034,
+        March 2005.
+
+   [3]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+        "Protocol Modifications for the DNS Security Extensions",
+        RFC 4035, March 2005.
+
+   [4]  Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards
+        (PKCS) #1: RSA Cryptography Specifications Version 2.1",
+        RFC 3447, February 2003.
+
+   [5]  National Institute of Standards and Technology, "Secure Hash
+        Standard", FIPS PUB 180-2, August 2002.
+
+   [6]  Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name
+        System (DNS)", RFC 3110, May 2001.
+
+8.2.  Informative References
+
+   [7]  Schneier, B., "Applied Cryptography Second Edition: protocols,
+        algorithms, and source code in C", Wiley and Sons , ISBN 0-471-
+        11709-9, 1996.
+
+   [8]  Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer (DS)
+        Resource Records (RRs)", Work in Progress Feb 2006.
+
+
+
+
+
+
+Jansen                    Expires July 5, 2006                  [Page 5]
+
+Internet-Draft       RSA/SHA-256 DNSKEYs and RRSIGS         January 2006
+
+
+Author's Address
+
+   Jelte Jansen
+   NLnet Labs
+   Kruislaan 419
+   Amsterdam  1098VA
+   NL
+
+   Email: jelte@NLnetLabs.nl
+   URI:   http://www.nlnetlabs.nl/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Jansen                    Expires July 5, 2006                  [Page 6]
+
+Internet-Draft       RSA/SHA-256 DNSKEYs and RRSIGS         January 2006
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2006).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Jansen                    Expires July 5, 2006                  [Page 7]
+
diff --git a/doc/draft/draft-ietf-dnsext-dnssec-trans-02.txt b/doc/draft/draft-ietf-dnsext-dnssec-trans-02.txt
new file mode 100644
index 0000000..dd8cbf0
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsext-dnssec-trans-02.txt
@@ -0,0 +1,839 @@
+
+DNS Extensions Working Group                                   R. Arends
+Internet-Draft                                      Telematica Instituut
+Expires: August 25, 2005                                         P. Koch
+                                                                DENIC eG
+                                                             J. Schlyter
+                                                                  NIC-SE
+                                                       February 21, 2005
+
+
+                Evaluating DNSSEC Transition Mechanisms
+                 draft-ietf-dnsext-dnssec-trans-02.txt
+
+Status of this Memo
+
+   This document is an Internet-Draft and is subject to all provisions
+   of Section 3 of RFC 3667.  By submitting this Internet-Draft, each
+   author represents that any applicable patent or other IPR claims of
+   which he or she is aware have been or will be disclosed, and any of
+   which he or she become aware will be disclosed, in accordance with
+   RFC 3668.
+
+   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 draft documents 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 "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/ietf/1id-abstracts.txt.
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+   This Internet-Draft will expire on August 25, 2005.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).
+
+Abstract
+
+   This document collects and summarizes different proposals for
+   alternative and additional strategies for authenticated denial in DNS
+   responses, evaluates these proposals and gives a recommendation for a
+
+
+
+Arends, et al.           Expires August 25, 2005                [Page 1]
+
+Internet-Draft    Evaluating DNSSEC Transition Mechanisms  February 2005
+
+
+   way forward.
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   2.  Transition Mechanisms  . . . . . . . . . . . . . . . . . . . .  3
+     2.1   Mechanisms With Need of Updating DNSSEC-bis  . . . . . . .  4
+       2.1.1   Dynamic NSEC Synthesis . . . . . . . . . . . . . . . .  4
+       2.1.2   Add Versioning/Subtyping to Current NSEC . . . . . . .  5
+       2.1.3   Type Bit Map NSEC Indicator  . . . . . . . . . . . . .  6
+       2.1.4   New Apex Type  . . . . . . . . . . . . . . . . . . . .  6
+       2.1.5   NSEC White Lies  . . . . . . . . . . . . . . . . . . .  7
+       2.1.6   NSEC Optional via DNSSKEY Flag . . . . . . . . . . . .  8
+       2.1.7   New Answer Pseudo RR Type  . . . . . . . . . . . . . .  9
+       2.1.8   SIG(0) Based Authenticated Denial  . . . . . . . . . .  9
+     2.2   Mechanisms Without Need of Updating DNSSEC-bis . . . . . . 10
+       2.2.1   Partial Type-code and Signal Rollover  . . . . . . . . 10
+       2.2.2   A Complete Type-code and Signal Rollover . . . . . . . 11
+       2.2.3   Unknown Algorithm in RRSIG . . . . . . . . . . . . . . 11
+   3.  Recommendation . . . . . . . . . . . . . . . . . . . . . . . . 12
+   4.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
+   5.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
+     5.1   Normative References . . . . . . . . . . . . . . . . . . . 13
+     5.2   Informative References . . . . . . . . . . . . . . . . . . 13
+       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14
+       Intellectual Property and Copyright Statements . . . . . . . . 15
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al.           Expires August 25, 2005                [Page 2]
+
+Internet-Draft    Evaluating DNSSEC Transition Mechanisms  February 2005
+
+
+1.  Introduction
+
+   This report shall document the process of dealing with the NSEC
+   walking problem late in the Last Call for
+   [I-D.ietf-dnsext-dnssec-intro, I-D.ietf-dnsext-dnssec-protocol,
+   I-D.ietf-dnsext-dnssec-records].  It preserves some of the discussion
+   that took place in the DNSEXT WG during the first half of June 2004
+   as well as some additional ideas that came up subsequently.
+
+   This is an edited excerpt of the chairs' mail to the WG:
+      The working group consents on not including NSEC-alt in the
+      DNSSEC-bis documents.  The working group considers to take up
+      "prevention of zone enumeration" as a work item.
+      There may be multiple mechanisms to allow for co-existence with
+      DNSSEC-bis.  The chairs allow the working group a little over a
+      week (up to June 12, 2004) to come to consensus on a possible
+      modification to the document to enable gentle rollover.  If that
+      consensus cannot be reached the DNSSEC-bis documents will go out
+      as-is.
+
+   To ease the process of getting consensus, a summary of the proposed
+   solutions and analysis of the pros and cons were written during the
+   weekend.
+
+   This summary includes:
+
+      An inventory of the proposed mechanisms to make a transition to
+      future work on authenticated denial of existence.
+      List the known Pros and Cons, possibly provide new arguments, and
+      possible security considerations of these mechanisms.
+      Provide a recommendation on a way forward that is least disruptive
+      to the DNSSEC-bis specifications as they stand and keep an open
+      path to other methods for authenticated denial of existence.
+
+   The descriptions of the proposals in this document are coarse and do
+   not cover every detail necessary for implementation.  In any case,
+   documentation and further study is needed before implementaion and/or
+   deployment, including those which seem to be solely operational in
+   nature.
+
+2.  Transition Mechanisms
+
+   In the light of recent discussions and past proposals, we have found
+   several ways to allow for transition to future expansion of
+   authenticated denial.  We tried to illuminate the paths and pitfalls
+   in these ways forward.  Some proposals lead to a versioning of
+   DNSSEC, where DNSSEC-bis may co-exist with DNSSEC-ter, other
+   proposals are 'clean' but may cause delay, while again others may be
+
+
+
+Arends, et al.           Expires August 25, 2005                [Page 3]
+
+Internet-Draft    Evaluating DNSSEC Transition Mechanisms  February 2005
+
+
+   plain hacks.
+
+   Some paths do not introduce versioning, and might require the current
+   DNSSEC-bis documents to be fully updated to allow for extensions to
+   authenticated denial mechanisms.  Other paths introduce versioning
+   and do not (or minimally) require DNSSEC-bis documents to be updated,
+   allowing DNSSEC-bis to be deployed, while future versions can be
+   drafted independent from or partially depending on DNSSEC-bis.
+
+2.1  Mechanisms With Need of Updating DNSSEC-bis
+
+   Mechanisms in this category demand updates to the DNSSEC-bis document
+   set.
+
+2.1.1  Dynamic NSEC Synthesis
+
+   This proposal assumes that NSEC RRs and the authenticating RRSIG will
+   be generated dynamically to just cover the (non existent) query name.
+   The owner name is (the) one preceding the name queried for, the Next
+   Owner Name Field has the value of the Query Name Field + 1 (first
+   successor in canonical ordering).  A separate key (the normal ZSK or
+   a separate ZSK per authoritative server) would be used for RRSIGs on
+   NSEC RRs.  This is a defense against enumeration, though it has the
+   presumption of online signing.
+
+2.1.1.1  Coexistence and Migration
+
+   There is no change in interpretation other then that the next owner
+   name might or might not exist.
+
+2.1.1.2  Limitations
+
+   This introduces an unbalanced cost between query and response
+   generation due to dynamic generation of signatures.
+
+2.1.1.3  Amendments to DNSSEC-bis
+
+   The current DNSSEC-bis documents might need to be updated to indicate
+   that the next owner name might not be an existing name in the zone.
+   This is not a real change to the spec since implementers have been
+   warned not to synthesize with previously cached NSEC records.  A
+   specific bit to identify the dynamic signature generating key might
+   be useful as well, to prevent it from being used to fake positive
+   data.
+
+2.1.1.4  Cons
+
+   Unbalanced cost is a ground for DDoS.  Though this protects against
+
+
+
+Arends, et al.           Expires August 25, 2005                [Page 4]
+
+Internet-Draft    Evaluating DNSSEC Transition Mechanisms  February 2005
+
+
+   enumeration, it is not really a path for versioning.
+
+2.1.1.5  Pros
+
+   Hardly any amendments to DNSSEC-bis.
+
+2.1.2  Add Versioning/Subtyping to Current NSEC
+
+   This proposal introduces versioning for the NSEC RR type (a.k.a.
+   subtyping) by adding a (one octet) version field to the NSEC RDATA.
+   Version number 0 is assigned to the current (DNSSEC-bis) meaning,
+   making this an 'Must Be Zero' (MBZ) for the to be published docset.
+
+2.1.2.1  Coexistence and Migration
+
+   Since the versioning is done inside the NSEC RR, different versions
+   may coexist.  However, depending on future methods, that may or may
+   not be useful inside a single zone.  Resolvers cannot ask for
+   specific NSEC versions but may be able to indicate version support by
+   means of a to be defined EDNS option bit.
+
+2.1.2.2  Limitations
+
+   There are no technical limitations, though it will cause delay to
+   allow testing of the (currently unknown) new NSEC interpretation.
+
+   Since the versioning and signaling is done inside the NSEC RR, future
+   methods will likely be restricted to a single RR type authenticated
+   denial (as opposed to e.g.  NSEC-alt, which currently proposes three
+   RR types).
+
+2.1.2.3  Amendments to DNSSEC-bis
+
+   Full Update of the current DNSSEC-bis documents to provide for new
+   fields in NSEC, while specifying behavior in case of unknown field
+   values.
+
+2.1.2.4  Cons
+
+   Though this is a clean and clear path without versioning DNSSEC, it
+   takes some time to design, gain consensus, update the current
+   dnssec-bis document, test and implement a new authenticated denial
+   record.
+
+2.1.2.5  Pros
+
+   Does not introduce an iteration to DNSSEC while providing a clear and
+   clean migration strategy.
+
+
+
+Arends, et al.           Expires August 25, 2005                [Page 5]
+
+Internet-Draft    Evaluating DNSSEC Transition Mechanisms  February 2005
+
+
+2.1.3  Type Bit Map NSEC Indicator
+
+   Bits in the type-bit-map are reused or allocated to signify the
+   interpretation of NSEC.
+
+   This proposal assumes that future extensions make use of the existing
+   NSEC RDATA syntax, while it may need to change the interpretation of
+   the RDATA or introduce an alternative denial mechanism, invoked by
+   the specific type-bit-map-bits.
+
+2.1.3.1  Coexistence and migration
+
+   Old and new NSEC meaning could coexist, depending how the signaling
+   would be defined.  The bits for NXT, NSEC, RRSIG or other outdated RR
+   types are available  as well as those covering meta/query types or
+   types to be specifically allocated.
+
+2.1.3.2  Limitations
+
+   This mechanism uses an NSEC field that was not designed for that
+   purpose.  Similar methods were discussed during the Opt-In discussion
+   and the Silly-State discussion.
+
+2.1.3.3  Amendments to DNSSEC-bis
+
+   The specific type-bit-map-bits must be allocated and they need to be
+   specified as 'Must Be Zero' (MBZ) when used for standard (dnssec-bis)
+   interpretation.  Also, behaviour of the resolver and validator must
+   be documented in case unknown values are encountered for the MBZ
+   field.  Currently the protocol document specifies that the validator
+   MUST ignore the setting of the NSEC and the RRSIG bits, while other
+   bits are only used for the specific purpose of the type-bit-map field
+
+2.1.3.4  Cons
+
+   The type-bit-map was not designed for this purpose.  It is a
+   straightforward hack.  Text in protocol section 5.4 was put in
+   specially to defend against this usage.
+
+2.1.3.5  Pros
+
+   No change needed to the on-the-wire protocol as specified in the
+   current docset.
+
+2.1.4  New Apex Type
+
+   This introduces a new Apex type (parallel to the zone's SOA)
+   indicating the DNSSEC version (or authenticated denial) used in or
+
+
+
+Arends, et al.           Expires August 25, 2005                [Page 6]
+
+Internet-Draft    Evaluating DNSSEC Transition Mechanisms  February 2005
+
+
+   for this zone.
+
+2.1.4.1  Coexistence and Migration
+
+   Depending on the design of this new RR type multiple denial
+   mechanisms may coexist in a zone.  Old validators will not understand
+   and thus ignore the new type, so interpretation of the new NSEC
+   scheme may fail, negative responses may appear 'bogus'.
+
+2.1.4.2  Limitations
+
+   A record of this kind is likely to carry additional
+   feature/versioning indications unrelated to the current question of
+   authenticated denial.
+
+2.1.4.3  Amendments to DNSSEC-bis
+
+   The current DNSSEC-bis documents need to be updated to indicate that
+   the absence of this type indicates dnssec-bis, and that the (mere)
+   presence of this type indicated unknown versions.
+
+2.1.4.4  Cons
+
+   The only other 'zone' or 'apex' record is the SOA record.  Though
+   this proposal is not new, it is yet unknown how it might fulfill
+   authenticated denial extensions.  This new RR type would only provide
+   for a generalized signaling mechanism, not the new authenticated
+   denial scheme.  Since it is likely to be general in nature, due to
+   this generality consensus is not to be reached soon.
+
+2.1.4.5  Pros
+
+   This approach would allow for a lot of other per zone information to
+   be transported or signaled to both (slave) servers and resolvers.
+
+2.1.5  NSEC White Lies
+
+   This proposal disables one part of NSEC (the pointer part) by means
+   of a special target (root, apex, owner, ...), leaving intact only the
+   ability to authenticate denial of existence of RR sets, not denial of
+   existence of domain names (NXDOMAIN).  It may be necessary to have
+   one working NSEC to prove the absence of a wildcard.
+
+2.1.5.1  Coexistence and Migration
+
+   The NSEC target can be specified per RR, so standard NSEC and 'white
+   lie' NSEC can coexist in a zone.  There is no need for migration
+   because no versioning is introduced or intended.
+
+
+
+Arends, et al.           Expires August 25, 2005                [Page 7]
+
+Internet-Draft    Evaluating DNSSEC Transition Mechanisms  February 2005
+
+
+2.1.5.2  Limitations
+
+   This proposal breaks the protocol and is applicable to certain types
+   of zones only (no wildcard, no deep names, delegation only).  Most of
+   the burden is put on the resolver side and operational consequences
+   are yet to be studied.
+
+2.1.5.3  Amendments to DNSSEC-bis
+
+   The current DNSSEC-bis documents need to be updated to indicate that
+   the NXDOMAIN responses may be insecure.
+
+2.1.5.4  Cons
+
+   Strictly speaking this breaks the protocol and doesn't fully fulfill
+   the requirements for authenticated denial of existence.  Security
+   implications need to be carefully documented: search path problems
+   (forged denial of existence may lead to wrong expansion of non-FQDNs
+   [RFC1535]) and replay attacks to deny existence of records.
+
+2.1.5.5  Pros
+
+   Hardly any amendments to DNSSEC-bis.  Operational "trick" that is
+   available anyway.
+
+2.1.6  NSEC Optional via DNSSKEY Flag
+
+   A new DNSKEY may be defined to declare NSEC optional per zone.
+
+2.1.6.1  Coexistence and Migration
+
+   Current resolvers/validators will not understand the Flag bit and
+   will have to treat negative responses as bogus.  Otherwise, no
+   migration path is needed since NSEC is simply turned off.
+
+2.1.6.2  Limitations
+
+   NSEC can only be made completely optional at the cost of being unable
+   to prove unsecure delegations (absence of a DS RR [RFC3658]).  A next
+   to this approach would just disable authenticated denial for
+   non-existence of nodes.
+
+2.1.6.3  Amendments to DNSSEC-bis
+
+   New DNSKEY Flag to be defined.  Resolver/Validator behaviour needs to
+   be specified in the light of absence of authenticated denial.
+
+
+
+
+
+Arends, et al.           Expires August 25, 2005                [Page 8]
+
+Internet-Draft    Evaluating DNSSEC Transition Mechanisms  February 2005
+
+
+2.1.6.4  Cons
+
+   Doesn't fully meet requirements.  Operational consequences to be
+   studied.
+
+2.1.6.5  Pros
+
+   Official version of the "trick" presented in (8).  Operational
+   problems can be addressed during future work on validators.
+
+2.1.7  New Answer Pseudo RR Type
+
+   A new pseudo RR type may be defined that will be dynamically created
+   (and signed) by the responding authoritative server.  The RR in the
+   response will cover the QNAME, QCLASS and QTYPE and will authenticate
+   both denial of existence of name (NXDOMAIN) or RRset.
+
+2.1.7.1  Coexistence and Migration
+
+   Current resolvers/validators will not understand the pseudo RR and
+   will thus not be able to process negative responses so testified.  A
+   signaling or solicitation method would have to be specified.
+
+2.1.7.2  Limitations
+
+   This method can only be used with online keys and online signing
+   capacity.
+
+2.1.7.3  Amendments to DNSSEC-bis
+
+   Signaling method needs to be defined.
+
+2.1.7.4  Cons
+
+   Keys have to be held and processed online with all security
+   implications.  An additional flag for those keys identifying them as
+   online or negative answer only keys should be considered.
+
+2.1.7.5  Pros
+
+   Expands DNSSEC authentication to the RCODE.
+
+2.1.8  SIG(0) Based Authenticated Denial
+
+
+2.1.8.1  Coexistence and Migration
+
+
+
+
+
+Arends, et al.           Expires August 25, 2005                [Page 9]
+
+Internet-Draft    Evaluating DNSSEC Transition Mechanisms  February 2005
+
+
+2.1.8.2  Limitations
+
+
+2.1.8.3  Amendments to DNSSEC-bis
+
+
+2.1.8.4  Cons
+
+
+2.1.8.5  Pros
+
+
+2.2  Mechanisms Without Need of Updating DNSSEC-bis
+
+2.2.1  Partial Type-code and Signal Rollover
+
+   Carefully crafted type code/signal rollover to define a new
+   authenticated denial space that extends/replaces DNSSEC-bis
+   authenticated denial space.  This particular path is illuminated by
+   Paul Vixie in a Message-Id <20040602070859.0F50913951@sa.vix.com>
+   posted to <namedroppers@ops.ietf.org> 2004-06-02.
+
+2.2.1.1  Coexistence and Migration
+
+   To protect the current resolver for future versions, a new DNSSEC-OK
+   bit must be allocated to make clear it does or does not understand
+   the future version.  Also, a new DS type needs to be allocated to
+   allow differentiation between a current signed delegation and a
+   'future' signed delegation.  Also, current NSEC needs to be rolled
+   into a new authenticated denial type.
+
+2.2.1.2  Limitations
+
+   None.
+
+2.2.1.3  Amendments to DNSSEC-bis
+
+   None.
+
+2.2.1.4  Cons
+
+   It is cumbersome to carefully craft an TCR that 'just fits'.  The
+   DNSSEC-bis protocol has many 'borderline' cases that needs special
+   consideration.  It might be easier to do a full TCR, since a few of
+   the types and signals need upgrading anyway.
+
+
+
+
+
+
+Arends, et al.           Expires August 25, 2005               [Page 10]
+
+Internet-Draft    Evaluating DNSSEC Transition Mechanisms  February 2005
+
+
+2.2.1.5  Pros
+
+   Graceful adoption of future versions of NSEC, while there are no
+   amendments to DNSSEC-bis.
+
+2.2.2  A Complete Type-code and Signal Rollover
+
+   A new DNSSEC space is defined which can exist independent of current
+   DNSSEC-bis space.
+
+   This proposal assumes that all current DNSSEC type-codes
+   (RRSIG/DNSKEY/NSEC/DS) and signals (DNSSEC-OK) are not used in any
+   future versions of DNSSEC.  Any future version of DNSSEC has its own
+   types to allow for keys, signatures, authenticated denial, etcetera.
+
+2.2.2.1  Coexistence and Migration
+
+   Both spaces can co-exist.  They can be made completely orthogonal.
+
+2.2.2.2  Limitations
+
+   None.
+
+2.2.2.3  Amendments to DNSSEC-bis
+
+   None.
+
+2.2.2.4  Cons
+
+   With this path we abandon the current DNSSEC-bis.  Though it is easy
+   to role specific well-known and well-tested parts into the re-write,
+   once deployment has started this path is very expensive for
+   implementers, registries, registrars and registrants as well as
+   resolvers/users.  A TCR is not to be expected to occur frequently, so
+   while a next generation authenticated denial may be enabled by a TCR,
+   it is likely that that TCR will only be agreed upon if it serves a
+   whole basket of changes or additions.  A quick introduction of
+   NSEC-ng should not be expected from this path.
+
+2.2.2.5  Pros
+
+   No amendments/changes to current DNSSEC-bis docset needed.  It is
+   always there as last resort.
+
+2.2.3  Unknown Algorithm in RRSIG
+
+   This proposal assumes that future extensions make use of the existing
+   NSEC RDATA syntax, while it may need to change the interpretation of
+
+
+
+Arends, et al.           Expires August 25, 2005               [Page 11]
+
+Internet-Draft    Evaluating DNSSEC Transition Mechanisms  February 2005
+
+
+   the RDATA or introduce an alternative denial mechanism, invoked by
+   the specific unknown signing algorithm.  The different interpretation
+   would be signaled by use of different signature algorithms in the
+   RRSIG records covering the NSEC RRs.
+
+   When an entire zone is signed with a single unknown algorithm, it
+   will cause implementations that follow current dnssec-bis documents
+   to treat individual RRsets as unsigned.
+
+2.2.3.1  Coexistence and migration
+
+   Old and new NSEC RDATA interpretation or known and unknown Signatures
+   can NOT coexist in a zone since signatures cover complete (NSEC)
+   RRSets.
+
+2.2.3.2  Limitations
+
+   Validating resolvers agnostic of new interpretation will treat the
+   NSEC RRset as "not signed".  This affects wildcard and non-existence
+   proof, as well as proof for (un)secured delegations.  Also, all
+   positive signatures (RRSIGs on RRSets other than DS, NSEC) appear
+   insecure/bogus to an old validator.
+
+   The algorithm version space is split for each future version of
+   DNSSEC.  Violation of the 'modular components' concept.  We use the
+   'validator' to protect the 'resolver' from unknown interpretations.
+
+2.2.3.3  Amendments to DNSSEC-bis
+
+   None.
+
+2.2.3.4  Cons
+
+   The algorithm field was not designed for this purpose.  This is a
+   straightforward hack.
+
+2.2.3.5  Pros
+
+   No amendments/changes to current DNSSEC-bis docset needed.
+
+3.  Recommendation
+
+   The authors recommend that the working group commits to and starts
+   work on a partial TCR, allowing graceful transition towards a future
+   version of NSEC.  Meanwhile, to accomodate the need for an
+   immediately, temporary, solution against zone-traversal, we recommend
+   On-Demand NSEC synthesis.
+
+
+
+
+Arends, et al.           Expires August 25, 2005               [Page 12]
+
+Internet-Draft    Evaluating DNSSEC Transition Mechanisms  February 2005
+
+
+   This approach does not require any mandatory changes to DNSSEC-bis,
+   does not violate the protocol and fulfills the requirements.  As a
+   side effect, it moves the cost of implementation and deployment to
+   the users (zone owners) of this mechanism.
+
+4.  Acknowledgements
+
+   The authors would like to thank Sam Weiler and Mark Andrews for their
+   input and constructive comments.
+
+5.  References
+
+5.1  Normative References
+
+   [I-D.ietf-dnsext-dnssec-intro]
+              Arends, R., Austein, R., Massey, D., Larson, M. and S.
+              Rose, "DNS Security Introduction and Requirements",
+              Internet-Draft draft-ietf-dnsext-dnssec-intro-13, October
+              2004.
+
+   [I-D.ietf-dnsext-dnssec-protocol]
+              Arends, R., "Protocol Modifications for the DNS Security
+              Extensions",
+              Internet-Draft draft-ietf-dnsext-dnssec-protocol-09,
+              October 2004.
+
+   [I-D.ietf-dnsext-dnssec-records]
+              Arends, R., "Resource Records for the DNS Security
+              Extensions",
+              Internet-Draft draft-ietf-dnsext-dnssec-records-11,
+              October 2004.
+
+   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
+              STD 13, RFC 1034, November 1987.
+
+   [RFC1035]  Mockapetris, P., "Domain names - implementation and
+              specification", STD 13, RFC 1035, November 1987.
+
+   [RFC2931]  Eastlake, D., "DNS Request and Transaction Signatures (
+              SIG(0)s)", RFC 2931, September 2000.
+
+5.2  Informative References
+
+   [RFC1535]  Gavron, E., "A Security Problem and Proposed Correction
+              With Widely Deployed DNS Software", RFC 1535, October
+              1993.
+
+   [RFC2535]  Eastlake, D., "Domain Name System Security Extensions",
+
+
+
+Arends, et al.           Expires August 25, 2005               [Page 13]
+
+Internet-Draft    Evaluating DNSSEC Transition Mechanisms  February 2005
+
+
+              RFC 2535, March 1999.
+
+   [RFC2629]  Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
+              June 1999.
+
+   [RFC3658]  Gudmundsson, O., "Delegation Signer (DS) Resource Record
+              (RR)", RFC 3658, December 2003.
+
+
+Authors' Addresses
+
+   Roy Arends
+   Telematica Instituut
+   Brouwerijstraat 1
+   Enschede  7523 XC
+   The Netherlands
+
+   Phone: +31 53 4850485
+   Email: roy.arends@telin.nl
+
+
+   Peter Koch
+   DENIC eG
+   Wiesenh"uttenplatz 26
+   Frankfurt  60329
+   Germany
+
+   Phone: +49 69 27235 0
+   Email: pk@DENIC.DE
+
+
+   Jakob Schlyter
+   NIC-SE
+   Box 5774
+   Stockholm  SE-114 87
+   Sweden
+
+   Email: jakob@nic.se
+   URI:   http://www.nic.se/
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al.           Expires August 25, 2005               [Page 14]
+
+Internet-Draft    Evaluating DNSSEC Transition Mechanisms  February 2005
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2005).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Arends, et al.           Expires August 25, 2005               [Page 15]
+
+
diff --git a/doc/draft/draft-ietf-dnsext-ds-sha256-05.txt b/doc/draft/draft-ietf-dnsext-ds-sha256-05.txt
new file mode 100644
index 0000000..2460cb6
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsext-ds-sha256-05.txt
@@ -0,0 +1,504 @@
+
+
+
+Network Working Group                                        W. Hardaker
+Internet-Draft                                                    Sparta
+Expires: August 25, 2006                               February 21, 2006
+
+
+ Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs)
+                   draft-ietf-dnsext-ds-sha256-05.txt
+
+Status of this Memo
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   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 draft documents 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 "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/ietf/1id-abstracts.txt.
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+   This Internet-Draft will expire on August 25, 2006.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   This document specifies how to use the SHA-256 digest type in DNS
+   Delegation Signer (DS) Resource Records (RRs).  DS records, when
+   stored in a parent zone, point to key signing DNSKEY key(s) in a
+   child zone.
+
+
+
+
+
+
+
+
+Hardaker                 Expires August 25, 2006                [Page 1]
+
+Internet-Draft       Use of SHA-256 in DNSSEC DS RRs       February 2006
+
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
+   2.  Implementing the SHA-256 algorithm for DS record support  . . . 3
+     2.1.  DS record field values  . . . . . . . . . . . . . . . . . . 3
+     2.2.  DS Record with SHA-256 Wire Format  . . . . . . . . . . . . 3
+     2.3.  Example DS Record Using SHA-256 . . . . . . . . . . . . . . 4
+   3.  Implementation Requirements . . . . . . . . . . . . . . . . . . 4
+   4.  Deployment Considerations . . . . . . . . . . . . . . . . . . . 4
+   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
+   6.  Security Considerations . . . . . . . . . . . . . . . . . . . . 5
+     6.1.  Potential Digest Type Downgrade Attacks . . . . . . . . . . 5
+     6.2.  SHA-1 vs SHA-256 Considerations for DS Records  . . . . . . 6
+   7.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6
+   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
+     8.1.  Normative References  . . . . . . . . . . . . . . . . . . . 7
+     8.2.  Informative References  . . . . . . . . . . . . . . . . . . 7
+   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 8
+   Intellectual Property and Copyright Statements  . . . . . . . . . . 9
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hardaker                 Expires August 25, 2006                [Page 2]
+
+Internet-Draft       Use of SHA-256 in DNSSEC DS RRs       February 2006
+
+
+1.  Introduction
+
+   The DNSSEC [RFC4033] [RFC4034] [RFC4035] DS RR is published in parent
+   zones to distribute a cryptographic digest of a child's Key Signing
+   Key (KSK) DNSKEY RR.  The DS RRset is signed by at least one of the
+   parent zone's private zone data signing keys for each algorithm in
+   use by the parent.  Each signature is published in an RRSIG resource
+   record, owned by the same domain as the DS RRset and with a type
+   covered of DS.
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC2119].
+
+
+2.  Implementing the SHA-256 algorithm for DS record support
+
+   This document specifies that the digest type code [XXX: To be
+   assigned by IANA; likely 2] is to be assigned to SHA-256 [SHA256]
+   [SHA256CODE] for use within DS records.  The results of the digest
+   algorithm MUST NOT be truncated and the entire 32 byte digest result
+   is to be published in the DS record.
+
+2.1.  DS record field values
+
+   Using the SHA-256 digest algorithm within a DS record will make use
+   of the following DS-record fields:
+
+   Digest type: [XXX: To be assigned by IANA; likely 2]
+
+   Digest: A SHA-256 bit digest value calculated by using the following
+      formula ("|" denotes concatenation).  The resulting value is not
+      truncated and the entire 32 byte result is to used in the
+      resulting DS record and related calculations.
+
+        digest = SHA_256(DNSKEY owner name | DNSKEY RDATA)
+
+      where DNSKEY RDATA is defined by [RFC4034] as:
+
+        DNSKEY RDATA = Flags | Protocol | Algorithm | Public Key
+
+   The Key Tag field and Algorithm fields remain unchanged by this
+   document and are specified in the [RFC4034] specification.
+
+2.2.  DS Record with SHA-256 Wire Format
+
+   The resulting on-the-wire format for the resulting DS record will be
+   [XXX: IANA assignment should replace the 2 below]:
+
+
+
+Hardaker                 Expires August 25, 2006                [Page 3]
+
+Internet-Draft       Use of SHA-256 in DNSSEC DS RRs       February 2006
+
+
+                           1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
+       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |           Key Tag             |  Algorithm    | DigestType=2  |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      /                                                               /
+      /            Digest  (length for SHA-256 is 32 bytes)           /
+      /                                                               /
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
+
+2.3.  Example DS Record Using SHA-256
+
+   The following is an example DNSKEY and matching DS record.  This
+   DNSKEY record comes from the example DNSKEY/DS records found in
+   section 5.4 of [RFC4034].
+
+   The DNSKEY record:
+
+   dskey.example.com. 86400 IN DNSKEY 256 3 5 ( AQOeiiR0GOMYkDshWoSKz9Xz
+                                                fwJr1AYtsmx3TGkJaNXVbfi/
+                                                2pHm822aJ5iI9BMzNXxeYCmZ
+                                                DRD99WYwYqUSdjMmmAphXdvx
+                                                egXd/M5+X7OrzKBaMbCVdFLU
+                                                Uh6DhweJBjEVv5f2wwjM9Xzc
+                                                nOf+EPbtG9DMBmADjFDc2w/r
+                                                ljwvFw==
+                                                ) ;  key id = 60485
+
+   The resulting DS record covering the above DNSKEY record using a SHA-
+   256 digest: [RFC Editor: please replace XXX with the assigned digest
+   type (likely 2):]
+
+   dskey.example.com. 86400 IN DS 60485 5 XXX ( D4B7D520E7BB5F0F67674A0C
+                                                CEB1E3E0614B93C4F9E99B83
+                                                83F6A1E4469DA50A )
+
+
+3.  Implementation Requirements
+
+   Implementations MUST support the use of the SHA-256 algorithm in DS
+   RRs.  Validator implementations SHOULD ignore DS RRs containing SHA-1
+   digests if DS RRs with SHA-256 digests are present in the DS RRset.
+
+
+4.  Deployment Considerations
+
+   If a validator does not support the SHA-256 digest type and no other
+   DS RR exists in a zone's DS RRset with a supported digest type, then
+
+
+
+Hardaker                 Expires August 25, 2006                [Page 4]
+
+Internet-Draft       Use of SHA-256 in DNSSEC DS RRs       February 2006
+
+
+   the validator has no supported authentication path leading from the
+   parent to the child.  The resolver should treat this case as it would
+   the case of an authenticated NSEC RRset proving that no DS RRset
+   exists, as described in [RFC4035], section 5.2.
+
+   Because zone administrators can not control the deployment speed of
+   support for SHA-256 in validators that may be referencing any of
+   their zones, zone operators should consider deploying both SHA-1 and
+   SHA-256 based DS records.  This should be done for every DNSKEY for
+   which DS records are being generated.  Whether to make use of both
+   digest types and for how long is a policy decision that extends
+   beyond the scope of this document.
+
+
+5.  IANA Considerations
+
+   Only one IANA action is required by this document:
+
+   The Digest Type to be used for supporting SHA-256 within DS records
+   needs to be assigned by IANA.  This document requests that the Digest
+   Type value of 2 be assigned to the SHA-256 digest algorithm.
+
+   At the time of this writing, the current digest types assigned for
+   use in DS records are as follows:
+
+      VALUE     Digest Type          Status
+        0       Reserved                -
+        1       SHA-1                MANDATORY
+        2       SHA-256              MANDATORY
+      3-255    Unassigned               -
+
+
+6.  Security Considerations
+
+6.1.  Potential Digest Type Downgrade Attacks
+
+   A downgrade attack from a stronger digest type to a weaker one is
+   possible if all of the following are true:
+
+   o  A zone includes multiple DS records for a given child's DNSKEY,
+      each of which use a different digest type.
+
+   o  A validator accepts a weaker digest even if a stronger one is
+      present but invalid.
+
+   For example, if the following conditions are all true:
+
+
+
+
+
+Hardaker                 Expires August 25, 2006                [Page 5]
+
+Internet-Draft       Use of SHA-256 in DNSSEC DS RRs       February 2006
+
+
+   o  Both SHA-1 and SHA-256 based digests are published in DS records
+      within a parent zone for a given child zone's DNSKEY.
+
+   o  The DS record with the SHA-1 digest matches the digest computed
+      using the child zone's DNSKEY.
+
+   o  The DS record with the SHA-256 digest fails to match the digest
+      computed using the child zone's DNSKEY.
+
+   Then if the validator accepts the above situation as secure then this
+   can be used as a downgrade attack since the stronger SHA-256 digest
+   is ignored.
+
+6.2.  SHA-1 vs SHA-256 Considerations for DS Records
+
+   Users of DNSSEC are encouraged to deploy SHA-256 as soon as software
+   implementations allow for it.  SHA-256 is widely believed to be more
+   resilient to attack than SHA-1, and confidence in SHA-1's strength is
+   being eroded by recently-announced attacks.  Regardless of whether or
+   not the attacks on SHA-1 will affect DNSSEC, it is believed (at the
+   time of this writing) that SHA-256 is the better choice for use in DS
+   records.
+
+   At the time of this publication, the SHA-256 digest algorithm is
+   considered sufficiently strong for the immediate future.  It is also
+   considered sufficient for use in DNSSEC DS RRs for the immediate
+   future.  However, future published attacks may weaken the usability
+   of this algorithm within the DS RRs.  It is beyond the scope of this
+   document to speculate extensively on the cryptographic strength of
+   the SHA-256 digest algorithm.
+
+   Likewise, it is also beyond the scope of this document to specify
+   whether or for how long SHA-1 based DS records should be
+   simultaneously published alongside SHA-256 based DS records.
+
+
+7.  Acknowledgments
+
+   This document is a minor extension to the existing DNSSEC documents
+   and those authors are gratefully appreciated for the hard work that
+   went into the base documents.
+
+   The following people contributed to portions of this document in some
+   fashion: Mark Andrews, Roy Arends, Olafur Gudmundsson, Paul Hoffman,
+   Olaf M. Kolkman, Edward Lewis, Scott Rose, Stuart E. Schechter, Sam
+   Weiler.
+
+
+
+
+
+Hardaker                 Expires August 25, 2006                [Page 6]
+
+Internet-Draft       Use of SHA-256 in DNSSEC DS RRs       February 2006
+
+
+8.  References
+
+8.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
+              Rose, "DNS Security Introduction and Requirements",
+              RFC 4033, March 2005.
+
+   [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
+              Rose, "Resource Records for the DNS Security Extensions",
+              RFC 4034, March 2005.
+
+   [RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
+              Rose, "Protocol Modifications for the DNS Security
+              Extensions", RFC 4035, March 2005.
+
+   [SHA256]   National Institute of Standards and Technology, "Secure
+              Hash Algorithm. NIST FIPS 180-2", August 2002.
+
+8.2.  Informative References
+
+   [SHA256CODE]
+              Eastlake, D., "US Secure Hash Algorithms (SHA)",
+              June 2005.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hardaker                 Expires August 25, 2006                [Page 7]
+
+Internet-Draft       Use of SHA-256 in DNSSEC DS RRs       February 2006
+
+
+Author's Address
+
+   Wes Hardaker
+   Sparta
+   P.O. Box 382
+   Davis, CA  95617
+   US
+
+   Email: hardaker@tislabs.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hardaker                 Expires August 25, 2006                [Page 8]
+
+Internet-Draft       Use of SHA-256 in DNSSEC DS RRs       February 2006
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2006).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Hardaker                 Expires August 25, 2006                [Page 9]
+
diff --git a/doc/draft/draft-ietf-dnsext-ecc-key-07.txt b/doc/draft/draft-ietf-dnsext-ecc-key-07.txt
new file mode 100644
index 0000000..2cdcdb1
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsext-ecc-key-07.txt
@@ -0,0 +1,928 @@
+
+INTERNET-DRAFT                                       ECC Keys in the DNS
+Expires: January 2006                                          July 2005
+
+
+
+                     Elliptic Curve KEYs in the DNS
+                     -------- ----- ---- -- --- ---
+                   <draft-ietf-dnsext-ecc-key-07.txt>
+
+                         Richard C. Schroeppel
+                          Donald Eastlake 3rd
+
+
+Status of This Document
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   This draft is intended to be become a Proposed Standard RFC.
+   Distribution of this document is unlimited. Comments should be sent
+   to the DNS mailing list <namedroppers@ops.ietf.org>.
+
+   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 draft documents 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 a "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/1id-abstracts.html
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html
+
+
+Abstract
+
+   The standard method for storing elliptic curve cryptographic keys and
+   signatures in the Domain Name System is specified.
+
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005). All Rights Reserved.
+
+
+
+
+
+R. Schroeppel, et al                                            [Page 1]
+
+
+INTERNET-DRAFT                                       ECC Keys in the DNS
+
+
+Acknowledgement
+
+   The assistance of Hilarie K. Orman in the production of this document
+   is greatfully acknowledged.
+
+
+
+Table of Contents
+
+      Status of This Document....................................1
+      Abstract...................................................1
+      Copyright Notice...........................................1
+
+      Acknowledgement............................................2
+      Table of Contents..........................................2
+
+      1. Introduction............................................3
+      2. Elliptic Curve Data in Resource Records.................3
+      3. The Elliptic Curve Equation.............................9
+      4. How do I Compute Q, G, and Y?..........................10
+      5. Elliptic Curve SIG Resource Records....................11
+      6. Performance Considerations.............................13
+      7. Security Considerations................................13
+      8. IANA Considerations....................................13
+      Copyright and Disclaimer..................................14
+
+      Informational References..................................15
+      Normative Refrences.......................................15
+
+      Author's Addresses........................................16
+      Expiration and File Name..................................16
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+R. Schroeppel, et al                                            [Page 2]
+
+
+INTERNET-DRAFT                                       ECC Keys in the DNS
+
+
+1. Introduction
+
+   The Domain Name System (DNS) is the global hierarchical replicated
+   distributed database system for Internet addressing, mail proxy, and
+   other information. The DNS has been extended to include digital
+   signatures and cryptographic keys as described in [RFC 4033, 4034,
+   4035].
+
+   This document describes how to store elliptic curve cryptographic
+   (ECC) keys and signatures in the DNS so they can be used for a
+   variety of security purposes.  Familiarity with ECC cryptography is
+   assumed [Menezes].
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC 2119].
+
+
+
+2. Elliptic Curve Data in Resource Records
+
+   Elliptic curve public keys are stored in the DNS within the RDATA
+   portions of key RRs, such as RRKEY and KEY [RFC 4034] RRs, with the
+   structure shown below.
+
+   The research world continues to work on the issue of which is the
+   best elliptic curve system, which finite field to use, and how to
+   best represent elements in the field.  So, representations are
+   defined for every type of finite field, and every type of elliptic
+   curve.  The reader should be aware that there is a unique finite
+   field with a particular number of elements, but many possible
+   representations of that field and its elements.  If two different
+   representations of a field are given, they are interconvertible with
+   a tedious but practical precomputation, followed by a fast
+   computation for each field element to be converted.  It is perfectly
+   reasonable for an algorithm to work internally with one field
+   representation, and convert to and from a different external
+   representation.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+R. Schroeppel, et al                                            [Page 3]
+
+
+INTERNET-DRAFT                                       ECC Keys in the DNS
+
+
+                            1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
+        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       |S M -FMT- A B Z|
+       +-+-+-+-+-+-+-+-+
+       |       LP      |
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       |                        P (length determined from LP)       .../
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       |       LF      |
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       |                        F (length determined from LF)       .../
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       |             DEG               |
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       |             DEGH              |
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       |             DEGI              |
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       |             DEGJ              |
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       |             TRDV              |
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       |S|     LH      |
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       |                        H (length determined from LH)       .../
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       |S|     LK      |
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       |                        K (length determined from LK)       .../
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       |       LQ      |
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       |                        Q (length determined from LQ)       .../
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       |       LA      |
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       |                        A (length determined from LA)       .../
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       |             ALTA              |
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       |       LB      |
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       |                        B (length determined from LB)       .../
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       |       LC      |
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       |                        C (length determined from LC)       .../
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       |       LG      |
+
+
+R. Schroeppel, et al                                            [Page 4]
+
+
+INTERNET-DRAFT                                       ECC Keys in the DNS
+
+
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       |                        G (length determined from LG)       .../
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       |       LY      |
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       |                        Y (length determined from LY)       .../
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   SMFMTABZ is a flags octet as follows:
+
+        S = 1 indicates that the remaining 7 bits of the octet selects
+           one of 128 predefined choices of finite field, element
+           representation, elliptic curve, and signature parameters.
+           MFMTABZ are omitted, as are all parameters from LP through G.
+           LY and Y are retained.
+
+        If S = 0, the remaining parameters are as in the picture and
+           described below.
+
+        M determines the type of field underlying the elliptic curve.
+
+        M = 0 if the field is a GF[2^N] field;
+
+        M = 1 if the field is a (mod P) or GF[P^D] field with P>2.
+
+        FMT is a three bit field describing the format of the field
+           representation.
+
+        FMT = 0  for a (mod P) field.
+            > 0  for an extension field, either GF[2^D] or GF[P^D].
+                The degree D of the extension, and the field polynomial
+                must be specified.  The field polynomial is always monic
+                (leading coefficient 1.)
+
+        FMT = 1  The field polynomial is given explicitly; D is implied.
+
+        If FMT >=2, the degree D is given explicitly.
+
+           = 2  The field polynomial is implicit.
+           = 3  The field polynomial is a binomial.  P>2.
+           = 4  The field polynomial is a trinomial.
+           = 5  The field polynomial is the quotient of a trinomial by a
+                short polynomial.  P=2.
+           = 6  The field polynomial is a pentanomial.  P=2.
+
+        Flags A and B apply to the elliptic curve parameters.
+
+
+
+
+
+
+R. Schroeppel, et al                                            [Page 5]
+
+
+INTERNET-DRAFT                                       ECC Keys in the DNS
+
+
+        A = 1 When P>=5, the curve parameter A is negated.  If P=2, then
+              A=1 indicates that the A parameter is special.  See the
+              ALTA parameter below, following A.  The combination A=1,
+              P=3 is forbidden.
+
+        B = 1 When P>=5, the curve parameter B is negated.  If P=2 or 3,
+              then B=1 indicates an alternate elliptic curve equation is
+              used.  When P=2 and B=1, an additional curve parameter C
+              is present.
+
+        The Z bit SHOULD be set to zero on creation of an RR and MUST be
+           ignored when processing an RR (when S=0).
+
+   Most of the remaining parameters are present in some formats and
+   absent in others.  The presence or absence of a parameter is
+   determined entirely by the flags.  When a parameter occurs, it is in
+   the order defined by the picture.
+
+   Of the remaining parameters, PFHKQABCGY are variable length.  When
+   present, each is preceded by a one-octet length field as shown in the
+   diagram above.  The length field does not include itself.  The length
+   field may have values from 0 through 110.  The parameter length in
+   octets is determined by a conditional formula: If LL<=64, the
+   parameter length is LL.  If LL>64, the parameter length is 16 times
+   (LL-60).  In some cases, a parameter value of 0 is sensible, and MAY
+   be represented by an LL value of 0, with the data field omitted.  A
+   length value of 0 represents a parameter value of 0, not an absent
+   parameter.  (The data portion occupies 0 space.)  There is no
+   requirement that a parameter be represented in the minimum number of
+   octets; high-order 0 octets are allowed at the front end.  Parameters
+   are always right adjusted, in a field of length defined by LL.  The
+   octet-order is always most-significant first, least-significant last.
+   The parameters H and K may have an optional sign bit stored in the
+   unused high-order bit of their length fields.
+
+   LP defines the length of the prime P.  P must be an odd prime.  The
+   parameters LP,P are present if and only if the flag M=1.  If M=0, the
+   prime is 2.
+
+   LF,F define an explicit field polynomial.  This parameter pair is
+   present only when FMT = 1.  The length of a polynomial coefficient is
+   ceiling(log2 P) bits.  Coefficients are in the numerical range
+   [0,P-1].  The coefficients are packed into fixed-width fields, from
+   higher order to lower order.  All coefficients must be present,
+   including any 0s and also the leading coefficient (which is required
+   to be 1).  The coefficients are right justified into the octet string
+   of length specified by LF, with the low-order "constant" coefficient
+   at the right end.  As a concession to storage efficiency, the higher
+   order bits of the leading coefficient may be elided, discarding high-
+   order 0 octets and reducing LF.  The degree is calculated by
+
+
+R. Schroeppel, et al                                            [Page 6]
+
+
+INTERNET-DRAFT                                       ECC Keys in the DNS
+
+
+   determining the bit position of the left most 1-bit in the F data
+   (counting the right most bit as position 0), and dividing by
+   ceiling(log2 P).  The division must be exact, with no remainder.  In
+   this format, all of the other degree and field parameters are
+   omitted.  The next parameters will be LQ,Q.
+
+   If FMT>=2, the degree of the field extension is specified explicitly,
+   usually along with other parameters to define the field polynomial.
+
+   DEG is a two octet field that defines the degree of the field
+   extension.  The finite field will have P^DEG elements.  DEG is
+   present when FMT>=2.
+
+   When FMT=2, the field polynomial is specified implicitly.  No other
+   parameters are required to define the field; the next parameters
+   present will be the LQ,Q pair.  The implicit field poynomial is the
+   lexicographically smallest irreducible (mod P) polynomial of the
+   correct degree.  The ordering of polynomials is by highest-degree
+   coefficients first -- the leading coefficient 1 is most important,
+   and the constant term is least important.  Coefficients are ordered
+   by sign-magnitude: 0 < 1 < -1 < 2 < -2 < ...  The first polynomial of
+   degree D is X^D (which is not irreducible).  The next is X^D+1, which
+   is sometimes irreducible, followed by X^D-1, which isn't.  Assuming
+   odd P, this series continues to X^D - (P-1)/2, and then goes to X^D +
+   X, X^D + X + 1, X^D + X - 1, etc.
+
+   When FMT=3, the field polynomial is a binomial, X^DEG + K.  P must be
+   odd.  The polynomial is determined by the degree and the low order
+   term K.  Of all the field parameters, only the LK,K parameters are
+   present.  The high-order bit of the LK octet stores on optional sign
+   for K; if the sign bit is present, the field polynomial is X^DEG - K.
+
+   When FMT=4, the field polynomial is a trinomial, X^DEG + H*X^DEGH +
+   K.  When P=2, the H and K parameters are implicitly 1, and are
+   omitted from the representation.  Only DEG and DEGH are present; the
+   next parameters are LQ,Q.  When P>2, then LH,H and LK,K are
+   specified.  Either or both of LH, LK may contain a sign bit for its
+   parameter.
+
+   When FMT=5, then P=2 (only).  The field polynomial is the exact
+   quotient of a trinomial divided by a small polynomial, the trinomial
+   divisor.  The small polynomial is right-adjusted in the two octet
+   field TRDV.  DEG specifies the degree of the field.  The degree of
+   TRDV is calculated from the position of the high-order 1 bit.  The
+   trinomial to be divided is X^(DEG+degree(TRDV)) + X^DEGH + 1.  If
+   DEGH is 0, the middle term is omitted from the trinomial.  The
+   quotient must be exact, with no remainder.
+
+   When FMT=6, then P=2 (only).  The field polynomial is a pentanomial,
+   with the degrees of the middle terms given by the three 2-octet
+
+
+R. Schroeppel, et al                                            [Page 7]
+
+
+INTERNET-DRAFT                                       ECC Keys in the DNS
+
+
+   values DEGH, DEGI, DEGJ.  The polynomial is X^DEG + X^DEGH + X^DEGI +
+   X^DEGJ + 1.  The values must satisfy the inequality DEG > DEGH > DEGI
+   > DEGJ > 0.
+
+        DEGH, DEGI, DEGJ  are two-octet fields that define the degree of
+           a term in a field polynomial.   DEGH is present when FMT = 4,
+           5, or 6.  DEGI and DEGJ are present only when FMT = 6.
+
+        TRDV is a two-octet right-adjusted binary polynomial of degree <
+           16.  It is present only for FMT=5.
+
+        LH and H define the H parameter, present only when FMT=4 and P
+           is odd.  The high bit of LH is an optional sign bit for H.
+
+        LK and K define the K parameter, present when FMT = 3 or 4, and
+           P is odd.  The high bit of LK is an optional sign bit for K.
+
+   The remaining parameters are concerned with the elliptic curve and
+   the signature algorithm.
+
+        LQ defines the length of the prime Q.  Q is a prime > 2^159.
+
+   In all 5 of the parameter pairs LA+A,LB+B,LC+C,LG+G,LY+Y, the data
+   member of the pair is an element from the finite field defined
+   earlier.  The length field defines a long octet string.  Field
+   elements are represented as (mod P) polynomials of degree < DEG, with
+   DEG or fewer coefficients.  The coefficients are stored from left to
+   right, higher degree to lower, with the constant term last.  The
+   coefficients are represented as integers in the range [0,P-1].  Each
+   coefficient is allocated an area of ceiling(log2 P) bits.  The field
+   representation is right-justified; the "constant term" of the field
+   element ends at the right most bit.  The coefficients are fitted
+   adjacently without regard for octet boundaries.  (Example: if P=5,
+   three bits are used for each coefficient.  If the field is GF[5^75],
+   then 225 bits are required for the coefficients, and as many as 29
+   octets may be needed in the data area.  Fewer octets may be used if
+   some high-order coefficients are 0.)  If a flag requires a field
+   element to be negated, each non-zero coefficient K is replaced with
+   P-K.  To save space, 0 bits may be removed from the left end of the
+   element representation, and the length field reduced appropriately.
+   This would normally only happen with A,B,C, because the designer
+   chose curve parameters with some high-order 0 coefficients or bits.
+
+   If the finite field is simply (mod P), then the field elements are
+   simply numbers (mod P), in the usual right-justified notation.  If
+   the finite field is GF[2^D], the field elements are the usual right-
+   justified polynomial basis representation.
+
+
+
+
+
+R. Schroeppel, et al                                            [Page 8]
+
+
+INTERNET-DRAFT                                       ECC Keys in the DNS
+
+
+        LA,A is the first parameter of the elliptic curve equation.
+           When P>=5, the flag A = 1 indicates A should be negated (mod
+           P).  When P=2 (indicated by the flag M=0), the flag A = 1
+           indicates that the parameter pair LA,A is replaced by the two
+           octet parameter ALTA.  In this case, the parameter A in the
+           curve equation is x^ALTA, where x is the field generator.
+           Parameter A often has the value 0, which may be indicated by
+           LA=0 (with no A data field), and sometimes A is 1, which may
+           be represented with LA=1 and a data field of 1, or by setting
+           the A flag and using an ALTA value of 0.
+
+        LB,B is the second parameter of the elliptic curve equation.
+           When P>=5, the flag B = 1 indicates B should be negated (mod
+           P).  When P=2 or 3, the flag B selects an alternate curve
+           equation.
+
+        LC,C is the third parameter of the elliptic curve equation,
+           present only when P=2 (indicated by flag M=0) and flag B=1.
+
+        LG,G defines a point on the curve, of order Q.  The W-coordinate
+           of the curve point is given explicitly; the Z-coordinate is
+           implicit.
+
+        LY,Y is the user's public signing key, another curve point of
+           order Q.  The W-coordinate is given explicitly; the Z-
+           coordinate is implicit.  The LY,Y parameter pair is always
+           present.
+
+
+
+3. The Elliptic Curve Equation
+
+   (The coordinates of an elliptic curve point are named W,Z instead of
+   the more usual X,Y to avoid confusion with the Y parameter of the
+   signing key.)
+
+   The elliptic curve equation is determined by the flag octet, together
+   with information about the prime P.  The primes 2 and 3 are special;
+   all other primes are treated identically.
+
+   If M=1, the (mod P) or GF[P^D] case, the curve equation is Z^2 = W^3
+   + A*W + B.  Z,W,A,B are all numbers (mod P) or elements of GF[P^D].
+   If A and/or B is negative (i.e., in the range from P/2 to P), and
+   P>=5, space may be saved by putting the sign bit(s) in the A and B
+   bits of the flags octet, and the magnitude(s) in the parameter
+   fields.
+
+   If M=1 and P=3, the B flag has a different meaning: it specifies an
+   alternate curve equation, Z^2 = W^3 + A*W^2 + B.  The middle term of
+   the right-hand-side is different.  When P=3, this equation is more
+
+
+R. Schroeppel, et al                                            [Page 9]
+
+
+INTERNET-DRAFT                                       ECC Keys in the DNS
+
+
+   commonly used.
+
+   If M=0, the GF[2^N] case, the curve equation is Z^2 + W*Z = W^3 +
+   A*W^2 + B.  Z,W,A,B are all elements of the field GF[2^N].  The A
+   parameter can often be 0 or 1, or be chosen as a single-1-bit value.
+   The flag B is used to select an alternate curve equation, Z^2 + C*Z =
+   W^3 + A*W + B.  This is the only time that the C parameter is used.
+
+
+
+4. How do I Compute Q, G, and Y?
+
+   The number of points on the curve is the number of solutions to the
+   curve equation, + 1 (for the "point at infinity").  The prime Q must
+   divide the number of points.  Usually the curve is chosen first, then
+   the number of points is determined with Schoof's algorithm.  This
+   number is factored, and if it has a large prime divisor, that number
+   is taken as Q.
+
+   G must be a point of order Q on the curve, satisfying the equation
+
+        Q * G  =  the point at infinity (on the elliptic curve)
+
+   G may be chosen by selecting a random [RFC 1750] curve point, and
+   multiplying it by (number-of-points-on-curve/Q).  G must not itself
+   be the "point at infinity"; in this astronomically unlikely event, a
+   new random curve point is recalculated.
+
+   G is specified by giving its W-coordinate.  The Z-coordinate is
+   calculated from the curve equation.  In general, there will be two
+   possible Z values.  The rule is to choose the "positive" value.
+
+   In the (mod P) case, the two possible Z values sum to P.  The smaller
+   value is less than P/2; it is used in subsequent calculations.  In
+   GF[P^D] fields, the highest-degree non-zero coefficient of the field
+   element Z is used; it is chosen to be less than P/2.
+
+   In the GF[2^N] case, the two possible Z values xor to W (or to the
+   parameter C with the alternate curve equation).  The numerically
+   smaller Z value (the one which does not contain the highest-order 1
+   bit of W (or C)) is used in subsequent calculations.
+
+   Y is specified by giving the W-coordinate of the user's public
+   signature key.  The Z-coordinate value is determined from the curve
+   equation.  As with G, there are two possible Z values; the same rule
+   is followed for choosing which Z to use.
+
+
+
+
+
+
+R. Schroeppel, et al                                           [Page 10]
+
+
+INTERNET-DRAFT                                       ECC Keys in the DNS
+
+
+   During the key generation process, a random [RFC 1750] number X must
+   be generated such that 1 <= X <= Q-1.  X is the private key and is
+   used in the final step of public key generation where Y is computed
+   as
+
+        Y = X * G (as points on the elliptic curve)
+
+   If the Z-coordinate of the computed point Y is wrong (i.e., Z > P/2
+   in the (mod P) case, or the high-order non-zero coefficient of Z >
+   P/2 in the GF[P^D] case, or Z sharing a high bit with W(C) in the
+   GF[2^N] case), then X must be replaced with Q-X.  This will
+   correspond to the correct Z-coordinate.
+
+
+
+5. Elliptic Curve SIG Resource Records
+
+   The signature portion of an RR RDATA area when using the EC
+   algorithm, for example in the RRSIG and SIG [RFC records] RRs is
+   shown below.
+
+                       1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
+   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                   R, (length determined from LQ)           .../
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                   S, (length determined from LQ)           .../
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   R and S are integers (mod Q).  Their length is specified by the LQ
+   field of the corresponding KEY RR and can also be calculated from the
+   SIG RR's RDLENGTH. They are right justified, high-order-octet first.
+   The same conditional formula for calculating the length from LQ is
+   used as for all the other length fields above.
+
+   The data signed is determined as specified in [RFC 2535].  Then the
+   following steps are taken where Q, P, G, and Y are as specified in
+   the public key [Schneier]:
+
+     hash = SHA-1 ( data )
+
+     Generate random [RFC 4086] K such that 0 < K < Q.  (Never sign two
+          different messages with the same K.  K should be chosen from a
+          very large space: If an opponent learns a K value for a single
+          signature, the user's signing key is compromised, and a forger
+          can sign arbitrary messages. There is no harm in signing the
+          same message multiple times with the same key or different
+          keys.)
+
+     R = (the W-coordinate of ( K*G on the elliptic curve )) interpreted
+
+
+R. Schroeppel, et al                                           [Page 11]
+
+
+INTERNET-DRAFT                                       ECC Keys in the DNS
+
+
+          as an integer, and reduced (mod Q).  (R must not be 0.  In
+          this astronomically unlikely event, generate a new random K
+          and recalculate R.)
+
+     S = ( K^(-1) * (hash + X*R) ) mod Q.
+
+     S must not be 0.  In this astronomically unlikely event, generate a
+          new random K and recalculate R and S.
+
+     If S > Q/2, set S = Q - S.
+
+     The pair (R,S) is the signature.
+
+     Another party verifies the signature as follows:
+
+          Check that 0 < R < Q and 0 < S < Q/2.  If not, it can not be a
+               valid EC sigature.
+
+          hash = SHA-1 ( data )
+
+          Sinv = S^(-1) mod Q.
+
+          U1 = (hash * Sinv) mod Q.
+
+          U2 = (R * Sinv) mod Q.
+
+          (U1 * G + U2 * Y) is computed on the elliptic curve.
+
+          V = (the W-coordinate of this point) interpreted as an integer
+               and reduced (mod Q).
+
+          The signature is valid if V = R.
+
+     The reason for requiring S < Q/2 is that, otherwise, both (R,S) and
+     (R,Q-S) would be valid signatures for the same data.  Note that a
+     signature that is valid for hash(data) is also valid for
+     hash(data)+Q or hash(data)-Q, if these happen to fall in the range
+     [0,2^160-1].  It's believed to be computationally infeasible to
+     find data that hashes to an assigned value, so this is only a
+     cosmetic blemish.  The blemish can be eliminated by using Q >
+     2^160, at the cost of having slightly longer signatures, 42 octets
+     instead of 40.
+
+     We must specify how a field-element E ("the W-coordinate") is to be
+     interpreted as an integer.  The field-element E is regarded as a
+     radix-P integer, with the digits being the coefficients in the
+     polynomial basis representation of E.  The digits are in the ragne
+     [0,P-1].  In the two most common cases, this reduces to "the
+     obvious thing".  In the (mod P) case, E is simply a residue mod P,
+     and is taken as an integer in the range [0,P-1].  In the GF[2^D]
+
+
+R. Schroeppel, et al                                           [Page 12]
+
+
+INTERNET-DRAFT                                       ECC Keys in the DNS
+
+
+     case, E is in the D-bit polynomial basis representation, and is
+     simply taken as an integer in the range [0,(2^D)-1].  For other
+     fields GF[P^D], it's necessary to do some radix conversion
+     arithmetic.
+
+
+
+  6. Performance Considerations
+
+     Elliptic curve signatures use smaller moduli or field sizes than
+     RSA and DSA.  Creation of a curve is slow, but not done very often.
+     Key generation is faster than RSA or DSA.
+
+     DNS implementations have been optimized for small transfers,
+     typically less than 512 octets including DNS overhead. Larger
+     transfers will perform correctly and and extensions have been
+     standardized to make larger transfers more efficient [RFC 2671].
+     However, it is still advisable at this time to make reasonable
+     efforts to minimize the size of RR sets stored within the DNS
+     consistent with adequate security.
+
+
+
+  7. Security Considerations
+
+     Keys retrieved from the DNS should not be trusted unless (1) they
+     have been securely obtained from a secure resolver or independently
+     verified by the user and (2) this secure resolver and secure
+     obtainment or independent verification conform to security policies
+     acceptable to the user.  As with all cryptographic algorithms,
+     evaluating the necessary strength of the key is essential and
+     dependent on local policy.
+
+     Some specific key generation considerations are given in the body
+     of this document.
+
+
+
+  8. IANA Considerations
+
+     The key and signature data structures defined herein correspond to
+     the value 4 in the Algorithm number field of the IANA registry
+
+     Assignment of meaning to the remaining ECC data flag bits or to
+     values of ECC fields outside the ranges for which meaning in
+     defined in this document requires an IETF consensus as defined in
+     [RFC 2434].
+
+
+
+
+
+R. Schroeppel, et al                                           [Page 13]
+
+
+INTERNET-DRAFT                                       ECC Keys in the DNS
+
+
+  Copyright and Disclaimer
+
+     Copyright (C) The Internet Society 2005.  This document is subject
+     to the rights, licenses and restrictions contained in BCP 78, and
+     except as set forth therein, the authors retain all their rights.
+
+
+     This document and the information contained herein are provided on
+     an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
+     REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
+     THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+R. Schroeppel, et al                                           [Page 14]
+
+
+INTERNET-DRAFT                                       ECC Keys in the DNS
+
+
+  Informational References
+
+     [RFC 1034] - P. Mockapetris, "Domain names - concepts and
+     facilities", 11/01/1987.
+
+     [RFC 1035] - P. Mockapetris, "Domain names - implementation and
+     specification", 11/01/1987.
+
+     [RFC 2671] - P. Vixie, "Extension Mechanisms for DNS (EDNS0)",
+     August 1999.
+
+     [RFC 4033] - Arends, R., Austein, R., Larson, M., Massey, D., and
+     S. Rose, "DNS Security Introduction and Requirements", RFC 4033,
+     March 2005.
+
+     [RFC 4035] - Arends, R., Austein, R., Larson, M., Massey, D., and
+     S. Rose, "Protocol Modifications for the DNS Security Extensions",
+     RFC 4035, March 2005.
+
+     [RFC 4086] - Eastlake, D., 3rd, Schiller, J., and S. Crocker,
+     "Randomness Requirements for Security", BCP 106, RFC 4086, June
+     2005.
+
+     [Schneier] - Bruce Schneier, "Applied Cryptography: Protocols,
+     Algorithms, and Source Code in C", 1996, John Wiley and Sons
+
+     [Menezes] - Alfred Menezes, "Elliptic Curve Public Key
+     Cryptosystems", 1993 Kluwer.
+
+     [Silverman] - Joseph Silverman, "The Arithmetic of Elliptic
+     Curves", 1986, Springer Graduate Texts in mathematics #106.
+
+
+
+  Normative Refrences
+
+     [RFC 2119] - S. Bradner, "Key words for use in RFCs to Indicate
+     Requirement Levels", March 1997.
+
+     [RFC 2434] - T. Narten, H. Alvestrand, "Guidelines for Writing an
+     IANA Considerations Section in RFCs", October 1998.
+
+     [RFC 4034] - Arends, R., Austein, R., Larson, M., Massey, D., and
+     S. Rose, "Resource Records for the DNS Security Extensions", RFC
+     4034, March 2005.
+
+
+
+
+
+
+
+R. Schroeppel, et al                                           [Page 15]
+
+
+INTERNET-DRAFT                                       ECC Keys in the DNS
+
+
+  Author's Addresses
+
+     Rich Schroeppel
+     500 S. Maple Drive
+     Woodland Hills, UT 84653 USA
+
+     Telephone:   +1-505-844-9079(w)
+     Email:       rschroe@sandia.gov
+
+
+     Donald E. Eastlake 3rd
+     Motorola Laboratories
+     155 Beaver Street
+     Milford, MA 01757 USA
+
+     Telephone:   +1 508-786-7554 (w)
+     EMail:       Donald.Eastlake@motorola.com
+
+
+
+  Expiration and File Name
+
+     This draft expires in January 2006.
+
+     Its file name is draft-ietf-dnsext-ecc-key-07.txt.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+R. Schroeppel, et al                                           [Page 16]
+
diff --git a/doc/draft/draft-ietf-dnsext-interop3597-02.txt b/doc/draft/draft-ietf-dnsext-interop3597-02.txt
new file mode 100644
index 0000000..160afc3
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsext-interop3597-02.txt
@@ -0,0 +1,334 @@
+DNS Extensions Working Group                                 J. Schlyter
+Internet-Draft                                              May 19, 2005
+Expires: November 20, 2005
+
+
+                     RFC 3597 Interoperability Report
+                   draft-ietf-dnsext-interop3597-02.txt
+
+Status of this Memo
+
+    By submitting this Internet-Draft, each author represents that any
+    applicable patent or other IPR claims of which he or she is aware
+    have been or will be disclosed, and any of which he or she becomes
+    aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+    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 draft documents 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 "work in progress."
+
+    The list of current Internet-Drafts can be accessed at
+    http://www.ietf.org/ietf/1id-abstracts.txt.
+
+    The list of Internet-Draft Shadow Directories can be accessed at
+    http://www.ietf.org/shadow.html.
+
+    This Internet-Draft will expire on November 20, 2005.
+
+Copyright Notice
+
+    Copyright (C) The Internet Society (2005).
+
+Abstract
+
+    This memo documents the result from the RFC 3597 (Handling of Unknown
+    DNS Resource Record Types) interoperability testing.
+
+
+
+
+
+
+
+
+
+
+Schlyter                Expires November 20, 2005               [Page 1]
+
+Internet-Draft      RFC 3597 Interoperability Report            May 2005
+
+
+Table of Contents
+
+    1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+    2.  Implementations  . . . . . . . . . . . . . . . . . . . . . . .  3
+    3.  Tests  . . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
+      3.1   Authoritative Primary Name Server  . . . . . . . . . . . .  3
+      3.2   Authoritative Secondary Name Server  . . . . . . . . . . .  3
+      3.3   Full Recursive Resolver  . . . . . . . . . . . . . . . . .  4
+      3.4   Stub Resolver  . . . . . . . . . . . . . . . . . . . . . .  4
+      3.5   DNSSEC Signer  . . . . . . . . . . . . . . . . . . . . . .  4
+    4.  Problems found . . . . . . . . . . . . . . . . . . . . . . . .  4
+    5.  Summary  . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
+    6.  Normative References . . . . . . . . . . . . . . . . . . . . .  4
+        Author's Address . . . . . . . . . . . . . . . . . . . . . . .  4
+    A.  Test zone data . . . . . . . . . . . . . . . . . . . . . . . .  5
+        Intellectual Property and Copyright Statements . . . . . . . .  6
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Schlyter                Expires November 20, 2005               [Page 2]
+
+Internet-Draft      RFC 3597 Interoperability Report            May 2005
+
+
+1.  Introduction
+
+    This memo documents the result from the RFC 3597 (Handling of Unknown
+    DNS Resource Record Types) interoperability testing.  The test was
+    performed during June and July 2004 by request of the IETF DNS
+    Extensions Working Group.
+
+2.  Implementations
+
+    The following is a list, in alphabetic order, of implementations
+    tested for compliance with RFC 3597:
+
+       DNSJava 1.6.4
+       ISC BIND 8.4.5
+       ISC BIND 9.3.0
+       NSD 2.1.1
+       Net::DNS 0.47 patchlevel 1
+       Nominum ANS 2.2.1.0.d
+
+    These implementations covers the following functions (number of
+    implementations tested for each function in paranthesis):
+
+       Authoritative Name Servers (4)
+       Full Recursive Resolver (2)
+       Stub Resolver (4)
+       DNSSEC Zone Signers (2)
+
+    All listed implementations are genetically different.
+
+3.  Tests
+
+    The following tests was been performed to validate compliance with
+    RFC 3597 section 3 ("Transparency"), 4 ("Domain Name Compression")
+    and 5 ("Text Representation").
+
+3.1  Authoritative Primary Name Server
+
+    The test zone data (Appendix A) was loaded into the name server
+    implementation and the server was queried for the loaded information.
+
+3.2  Authoritative Secondary Name Server
+
+    The test zone data (Appendix A) was transferred using AXFR from
+    another name server implementation and the server was queried for the
+    transferred information.
+
+
+
+
+
+
+Schlyter                Expires November 20, 2005               [Page 3]
+
+Internet-Draft      RFC 3597 Interoperability Report            May 2005
+
+
+3.3  Full Recursive Resolver
+
+    A recursive resolver was queried for resource records from a domain
+    with the test zone data (Appendix A).
+
+3.4  Stub Resolver
+
+    A stub resolver was used to query resource records from a domain with
+    the test zone data (Appendix A).
+
+3.5  DNSSEC Signer
+
+    A DNSSEC signer was used to sign a zone with test zone data
+    (Appendix A).
+
+4.  Problems found
+
+    Two implementations had problems with text presentation of zero
+    length RDATA.
+
+    One implementation had problems with text presentation of RR type
+    code and classes >= 4096.
+
+    Bug reports were filed for problems found.
+
+5.  Summary
+
+    Unknown type codes works in the tested authoritative servers,
+    recursive resolvers and stub clients.
+
+    No changes are needed to advance RFC 3597 to draft standard.
+
+6.  Normative References
+
+    [1]  Gustafsson, A., "Handling of Unknown DNS Resource Record (RR)
+         Types", RFC 3597, September 2003.
+
+
+Author's Address
+
+    Jakob Schlyter
+
+    Email: jakob@rfc.se
+
+
+
+
+
+
+
+
+Schlyter                Expires November 20, 2005               [Page 4]
+
+Internet-Draft      RFC 3597 Interoperability Report            May 2005
+
+
+Appendix A.  Test zone data
+
+    ; A-record encoded as TYPE1
+    a  TYPE1  \# 4 7f000001
+    a  TYPE1  192.0.2.1
+    a  A      \# 4 7f000002
+
+    ; draft-ietf-secsh-dns-05.txt
+    sshfp  TYPE44  \# 22 01 01 c691e90714a1629d167de8e5ee0021f12a7eaa1e
+
+    ; bogus test record (from RFC 3597)
+    type731    TYPE731    \# 6 abcd (
+                               ef 01 23 45 )
+
+    ; zero length RDATA (from RFC 3597)
+    type62347  TYPE62347  \# 0
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Schlyter                Expires November 20, 2005               [Page 5]
+
+Internet-Draft      RFC 3597 Interoperability Report            May 2005
+
+
+Intellectual Property Statement
+
+    The IETF takes no position regarding the validity or scope of any
+    Intellectual Property Rights or other rights that might be claimed to
+    pertain to the implementation or use of the technology described in
+    this document or the extent to which any license under such rights
+    might or might not be available; nor does it represent that it has
+    made any independent effort to identify any such rights.  Information
+    on the procedures with respect to rights in RFC documents can be
+    found in BCP 78 and BCP 79.
+
+    Copies of IPR disclosures made to the IETF Secretariat and any
+    assurances of licenses to be made available, or the result of an
+    attempt made to obtain a general license or permission for the use of
+    such proprietary rights by implementers or users of this
+    specification can be obtained from the IETF on-line IPR repository at
+    http://www.ietf.org/ipr.
+
+    The IETF invites any interested party to bring to its attention any
+    copyrights, patents or patent applications, or other proprietary
+    rights that may cover technology that may be required to implement
+    this standard.  Please address the information to the IETF at
+    ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+    This document and the information contained herein are provided on an
+    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+    ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+Copyright Statement
+
+    Copyright (C) The Internet Society (2005).  This document is subject
+    to the rights, licenses and restrictions contained in BCP 78, and
+    except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+    Funding for the RFC Editor function is currently provided by the
+    Internet Society.
+
+
+
+
+Schlyter                Expires November 20, 2005               [Page 6]
+
+
diff --git a/doc/draft/draft-ietf-dnsext-keyrr-key-signing-flag-12.txt b/doc/draft/draft-ietf-dnsext-keyrr-key-signing-flag-12.txt
new file mode 100644
index 0000000..6bffb70
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsext-keyrr-key-signing-flag-12.txt
@@ -0,0 +1,560 @@
+
+DNS Extensions                                                O. Kolkman
+Internet-Draft                                                  RIPE NCC
+Expires: June 17, 2004                                       J. Schlyter
+
+                                                                E. Lewis
+                                                                    ARIN
+                                                       December 18, 2003
+
+
+                   DNSKEY RR Secure Entry Point Flag
+              draft-ietf-dnsext-keyrr-key-signing-flag-12
+
+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 draft documents 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 "work in progress."
+
+   The list of current Internet-Drafts can be accessed at http://
+   www.ietf.org/ietf/1id-abstracts.txt.
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+   This Internet-Draft will expire on June 17, 2004.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2003). All Rights Reserved.
+
+Abstract
+
+   With the Delegation Signer (DS) resource record the concept of a
+   public key acting as a secure entry point has been introduced. During
+   exchanges of public keys with the parent there is a need to
+   differentiate secure entry point keys from other public keys in the
+   DNSKEY resource record (RR) set.  A flag bit in the DNSKEY RR is
+   defined to indicate that DNSKEY is to be used as a secure entry
+   point. The flag bit is intended to assist in operational procedures
+   to correctly generate DS resource records, or to indicate what
+   DNSKEYs are intended for static configuration. The flag bit is not to
+
+
+
+Kolkman, et al.          Expires June 17, 2004                  [Page 1]
+
+Internet-Draft     DNSKEY RR Secure Entry Point Flag       December 2003
+
+
+   be used in the DNS verification protocol. This document updates RFC
+   2535 and RFC 3445.
+
+Table of Contents
+
+   1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3
+   2. The Secure Entry Point (SEP) Flag  . . . . . . . . . . . . . . . 4
+   3. DNSSEC Protocol Changes  . . . . . . . . . . . . . . . . . . . . 5
+   4. Operational Guidelines . . . . . . . . . . . . . . . . . . . . . 5
+   5. Security Considerations  . . . . . . . . . . . . . . . . . . . . 6
+   6. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . . 6
+   7. Internationalization Considerations  . . . . . . . . . . . . . . 6
+   8. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . . 6
+      Normative References . . . . . . . . . . . . . . . . . . . . . . 7
+      Informative References . . . . . . . . . . . . . . . . . . . . . 7
+      Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
+      Intellectual Property and Copyright Statements . . . . . . . . . 9
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kolkman, et al.          Expires June 17, 2004                  [Page 2]
+
+Internet-Draft     DNSKEY RR Secure Entry Point Flag       December 2003
+
+
+1. Introduction
+
+   "All keys are equal but some keys are more equal than others" [6]
+
+   With the definition of the Delegation Signer Resource Record (DS RR)
+   [5] it has become important to differentiate between the keys in the
+   DNSKEY RR set that are (to be) pointed to by parental DS RRs and the
+   other keys in the DNSKEY RR set.  We refer to these public keys as
+   Secure Entry Point (SEP) keys.  A SEP key either used to generate a
+   DS RR or is distributed to resolvers that use the key as the root of
+   a trusted subtree[3].
+
+   In early deployment tests, the use of two (kinds of) key pairs for
+   each zone has been prevalent.  For one kind of key pair the private
+   key is used to sign just the zone's DNSKEY resource record (RR) set.
+   Its public key is intended to be referenced by a DS RR at the parent
+   or configured statically in a resolver.  The private key of the other
+   kind of key pair is used to sign the rest of the zone's data sets.
+   The former key pair is called a key-signing key (KSK) and the latter
+   is called a zone-signing key (ZSK).  In practice there have been
+   usually one of each kind of key pair, but there will be multiples of
+   each at times.
+
+   It should be noted that division of keys pairs into KSK's and ZSK's
+   is not mandatory in any definition of DNSSEC, not even with the
+   introduction of the DS RR.  But, in testing, this distinction has
+   been helpful when designing key roll over (key super-cession)
+   schemes.  Given that the distinction has proven helpful, the labels
+   KSK and ZSK have begun to stick.
+
+   There is a need to differentiate the public keys for the key pairs
+   that are used for key signing from keys that are not used key signing
+   (KSKs vs ZSKs). This need is driven by knowing which DNSKEYs are to
+   be sent for generating DS RRs, which DNSKEYs are to be distributed to
+   resolvers, and which keys are fed to the signer application at the
+   appropriate time.
+
+   In other words, the SEP bit provides an in-band method to communicate
+   a DNSKEY RR's intended use to third parties. As an example we present
+   3 use cases in which the bit is useful:
+
+      The parent is a registry, the parent and the child use secured DNS
+      queries and responses, with a preexisting trust-relation, or plain
+      DNS over a secured channel to exchange the child's  DNSKEY RR
+      sets. Since a DNSKEY RR set will contain a complete DNSKEY RRset
+      the SEP bit can be used to isolate the DNSKEYs for which a DS RR
+      needs to be created.
+
+
+
+
+Kolkman, et al.          Expires June 17, 2004                  [Page 3]
+
+Internet-Draft     DNSKEY RR Secure Entry Point Flag       December 2003
+
+
+      An administrator has configured a DNSKEY as root for a trusted
+      subtree into security aware resolver. Using a special purpose tool
+      that queries for the KEY RRs from that domain's apex, the
+      administrator will be able to notice the roll over of the trusted
+      anchor by a change of the subset of KEY RRs with the DS flag set.
+
+      A signer might use the SEP bit on the public key to determine
+      which private key to use to exclusively sign the DNSKEY RRset and
+      which private key to use to sign the other RRsets in the zone.
+
+   As demonstrated in the above examples it is important to be able to
+   differentiate the SEP keys from the other keys in a DNSKEY RR set in
+   the flow between signer and (parental) key-collector and in the flow
+   between the signer and the resolver configuration. The SEP flag is to
+   be of no interest to the flow between the verifier and the
+   authoritative data store.
+
+   The reason for the term "SEP" is a result of the observation that the
+   distinction between KSK and ZSK key pairs is made by the signer, a
+   key pair could be used as both a KSK and a ZSK at the same time. To
+   be clear, the term SEP was coined to lessen the confusion caused by
+   the overlap. ( Once this label was applied, it had the side effect of
+   removing the temptation to have both a KSK flag bit and a ZSK flag
+   bit.)
+
+   The key words "MAY","MAY NOT", "MUST", "MUST NOT", "REQUIRED",
+   "RECOMMENDED", "SHOULD", and "SHOULD NOT" in this document are to be
+   interpreted as described in RFC2119 [1].
+
+2. The Secure Entry Point (SEP) Flag
+
+
+                           1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
+       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |              flags          |S|   protocol    |   algorithm   |
+      |                             |E|               |               |
+      |                             |P|               |               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                                                               /
+      /                        public key                             /
+      /                                                               /
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                                DNSKEY RR Format
+
+
+
+
+
+
+Kolkman, et al.          Expires June 17, 2004                  [Page 4]
+
+Internet-Draft     DNSKEY RR Secure Entry Point Flag       December 2003
+
+
+   This document assigns the 15'th bit in the flags field as the secure
+   entry point (SEP) bit.  If the the bit is set to 1 the key is
+   intended to be used as secure entry point key.  One SHOULD NOT assign
+   special meaning to the key if the bit is set to 0.  Operators can
+   recognize the secure entry point key by the even or odd-ness of the
+   decimal representation of the flag field.
+
+3. DNSSEC Protocol Changes
+
+   The bit MUST NOT be used during the resolving and verification
+   process. The SEP flag is only used to provide a hint about the
+   different administrative properties of the key and therefore the use
+   of the SEP flag does not change the DNS resolution protocol or the
+   resolution process.
+
+4. Operational Guidelines
+
+   The SEP bit is set by the key-pair-generator and MAY be used by the
+   zone signer to decide whether the public part of the key pair is to
+   be prepared for input to a DS RR generation function.  The SEP bit is
+   recommended to be set (to 1) whenever the public key of the key pair
+   will be distributed to the parent zone to build the authentication
+   chain or if the public key is to be distributed for static
+   configuration in verifiers.
+
+   When a key pair is created, the operator needs to indicate whether
+   the SEP bit is to be set in the DNSKEY RR.  As the SEP bit is within
+   the data that is used to compute the 'key tag field' in the SIG RR,
+   changing the SEP bit will change the identity of the key within DNS.
+   In other words, once a key is used to generate signatures, the
+   setting of the SEP bit is to remain constant. If not, a verifier will
+   not be able to find the relevant KEY RR.
+
+   When signing a zone, it is intended that the key(s) with the SEP bit
+   set (if such keys exist) are used to sign the KEY RR set of the zone.
+   The same key can be used to sign the rest of the zone data too.  It
+   is conceivable that not all keys with a SEP bit set will sign the
+   DNSKEY RR set, such keys might be pending retirement or not yet in
+   use.
+
+   When verifying a RR set, the SEP bit is not intended to play a role.
+   How the key is used by the verifier is not intended to be a
+   consideration at key creation time.
+
+   Although the SEP flag provides a hint on which public key is to be
+   used as trusted root, administrators can choose to ignore the fact
+   that a DNSKEY has its SEP bit set or not when configuring a trusted
+   root for their resolvers.
+
+
+
+Kolkman, et al.          Expires June 17, 2004                  [Page 5]
+
+Internet-Draft     DNSKEY RR Secure Entry Point Flag       December 2003
+
+
+   Using the SEP flag a key roll over can be automated. The parent can
+   use an existing trust relation to verify DNSKEY RR sets in which a
+   new DNSKEY RR with the SEP flag appears.
+
+5. Security Considerations
+
+   As stated in Section 3 the flag is not to be used in the resolution
+   protocol or to determine the security status of a key. The flag is to
+   be used for administrative purposes only.
+
+   No trust in a key should be inferred from this flag - trust MUST be
+   inferred from an existing chain of trust or an out-of-band exchange.
+
+   Since this flag might be used for automating public key exchanges, we
+   think the following consideration is in place.
+
+   Automated mechanisms for roll over of the DS RR might be vulnerable
+   to a class of replay attacks.  This might happen after a public key
+   exchange where a DNSKEY RR set, containing two DNSKEY RRs with the
+   SEP flag set, is sent to the parent.  The parent verifies the DNSKEY
+   RR set with the existing trust relation and creates the new DS RR
+   from the DNSKEY RR that the current DS RR is not pointing to.  This
+   key exchange might be replayed. Parents are encouraged to implement a
+   replay defense. A simple defense can be based on a registry of keys
+   that have been used to generate DS RRs during the most recent roll
+   over. These same considerations apply to entities that configure keys
+   in resolvers.
+
+6. IANA Considerations
+
+   The flag bits  in the DNSKEY RR are assigned by IETF consensus and
+   registered in the DNSKEY Flags registry (created by [4]). This
+   document assigns the 15th bit in the DNSKEY RR as the Secure Entry
+   Point (SEP) bit.
+
+7. Internationalization Considerations
+
+   Although SEP is a popular acronym in many different languages, there
+   are no internationalization considerations.
+
+8. Acknowledgments
+
+   The ideas documented in this document are inspired by communications
+   we had with numerous people and ideas published by other folk. Among
+   others Mark Andrews, Rob Austein, Miek Gieben, Olafur Gudmundsson,
+   Daniel Karrenberg, Dan Massey, Scott Rose, Marcos Sanz and Sam Weiler
+   have contributed ideas and provided feedback.
+
+
+
+
+Kolkman, et al.          Expires June 17, 2004                  [Page 6]
+
+Internet-Draft     DNSKEY RR Secure Entry Point Flag       December 2003
+
+
+   This document saw the light during a workshop on DNSSEC operations
+   hosted by USC/ISI in August 2002.
+
+Normative References
+
+   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
+        Levels", BCP 14, RFC 2119, March 1997.
+
+   [2]  Eastlake, D., "Domain Name System Security Extensions", RFC
+        2535, March 1999.
+
+   [3]  Lewis, E., "DNS Security Extension Clarification on Zone
+        Status", RFC 3090, March 2001.
+
+   [4]  Weiler, S., "Legacy Resolver Compatibility for Delegation
+        Signer", draft-ietf-dnsext-dnssec-2535typecode-change-05 (work
+        in progress), October 2003.
+
+Informative References
+
+   [5]  Gudmundsson, O., "Delegation Signer Resource Record",
+        draft-ietf-dnsext-delegation-signer-15 (work in progress), June
+        2003.
+
+   [6]  Orwell, G. and R. Steadman (illustrator), "Animal Farm; a Fairy
+        Story", ISBN 0151002177 (50th anniversary edition), April 1996.
+
+
+Authors' Addresses
+
+   Olaf M. Kolkman
+   RIPE NCC
+   Singel 256
+   Amsterdam  1016 AB
+   NL
+
+   Phone: +31 20 535 4444
+   EMail: olaf@ripe.net
+   URI:   http://www.ripe.net/
+
+
+   Jakob Schlyter
+   Karl Gustavsgatan 15
+   Goteborg  SE-411 25
+   Sweden
+
+   EMail: jakob@schlyter.se
+
+
+
+
+Kolkman, et al.          Expires June 17, 2004                  [Page 7]
+
+Internet-Draft     DNSKEY RR Secure Entry Point Flag       December 2003
+
+
+   Edward P. Lewis
+   ARIN
+   3635 Concorde Parkway Suite 200
+   Chantilly, VA  20151
+   US
+
+   Phone: +1 703 227 9854
+   EMail: edlewis@arin.net
+   URI:   http://www.arin.net/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kolkman, et al.          Expires June 17, 2004                  [Page 8]
+
+Internet-Draft     DNSKEY RR Secure Entry Point Flag       December 2003
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   intellectual property or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; neither does it represent that it
+   has made any effort to identify any such rights. Information on the
+   IETF's procedures with respect to rights in standards-track and
+   standards-related documentation can be found in BCP-11. Copies of
+   claims of rights made available for publication and any assurances of
+   licenses to be made available, or the result of an attempt made to
+   obtain a general license or permission for the use of such
+   proprietary rights by implementors or users of this specification can
+   be obtained from the IETF Secretariat.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights which may cover technology that may be required to practice
+   this standard. Please address the information to the IETF Executive
+   Director.
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2003). 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 Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assignees.
+
+   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
+
+
+
+Kolkman, et al.          Expires June 17, 2004                  [Page 9]
+
+Internet-Draft     DNSKEY RR Secure Entry Point Flag       December 2003
+
+
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kolkman, et al.          Expires June 17, 2004                 [Page 10]
+
+
diff --git a/doc/draft/draft-ietf-dnsext-mdns-43.txt b/doc/draft/draft-ietf-dnsext-mdns-43.txt
new file mode 100644
index 0000000..5de6e85
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsext-mdns-43.txt
@@ -0,0 +1,1740 @@
+
+
+
+
+
+
+DNSEXT Working Group                                       Bernard Aboba
+INTERNET-DRAFT                                               Dave Thaler
+Category: Standards Track                                   Levon Esibov
+<draft-ietf-dnsext-mdns-43.txt>                    Microsoft Corporation
+29 August 2005
+
+              Linklocal Multicast Name Resolution (LLMNR)
+
+Status of this Memo
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   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 draft documents 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 "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/ietf/1id-abstracts.txt.
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+   This Internet-Draft will expire on March 15, 2006.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society 2005.
+
+Abstract
+
+   The goal of Link-Local Multicast Name Resolution (LLMNR) is to enable
+   name resolution in scenarios in which conventional DNS name
+   resolution is not possible.  LLMNR supports all current and future
+   DNS formats, types and classes, while operating on a separate port
+   from DNS, and with a distinct resolver cache.  Since LLMNR only
+   operates on the local link, it cannot be considered a substitute for
+   DNS.
+
+
+
+
+
+Aboba, Thaler & Esibov       Standards Track                    [Page 1]
+
+
+
+
+
+INTERNET-DRAFT                    LLMNR                   29 August 2005
+
+
+Table of Contents
+
+1.     Introduction ..........................................    3
+   1.1       Requirements ....................................    4
+   1.2       Terminology .....................................    4
+2.     Name Resolution Using LLMNR ...........................    4
+   2.1       LLMNR Packet Format .............................    6
+   2.2       Sender Behavior .................................    9
+   2.3       Responder Behavior ..............................   10
+   2.4       Unicast Queries and Responses ...................   12
+   2.5       Off-link Detection ..............................   13
+   2.6       Responder Responsibilities ......................   13
+   2.7       Retransmission and Jitter .......................   14
+   2.8       DNS TTL .........................................   15
+   2.9       Use of the Authority and Additional Sections ....   15
+3.     Usage model ...........................................   16
+   3.1       LLMNR Configuration .............................   17
+4.     Conflict Resolution ...................................   18
+   4.1       Uniqueness Verification .........................   19
+   4.2       Conflict Detection and Defense ..................   20
+   4.3       Considerations for Multiple Interfaces ..........   21
+   4.4       API issues ......................................   22
+5.     Security Considerations ...............................   22
+   5.1       Denial of Service ...............................   23
+   5.2       Spoofing ...............,........................   23
+   5.3       Authentication ..................................   24
+   5.4       Cache and Port Separation .......................   25
+6.     IANA considerations ...................................   25
+7.     Constants .............................................   25
+8.     References ............................................   25
+   8.1       Normative References ............................   25
+   8.2       Informative References ..........................   26
+Acknowledgments ..............................................   27
+Authors' Addresses ...........................................   28
+Intellectual Property Statement ..............................   28
+Disclaimer of Validity .......................................   29
+Copyright Statement ..........................................   29
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Aboba, Thaler & Esibov       Standards Track                    [Page 2]
+
+
+
+
+
+INTERNET-DRAFT                    LLMNR                   29 August 2005
+
+
+1.  Introduction
+
+   This document discusses Link Local Multicast Name Resolution (LLMNR),
+   which is based on the DNS packet format and supports all current and
+   future DNS formats, types and classes.  LLMNR operates on a separate
+   port from the Domain Name System (DNS), with a distinct resolver
+   cache.
+
+   The goal of LLMNR is to enable name resolution in scenarios in which
+   conventional DNS name resolution is not possible.  Usage scenarios
+   (discussed in more detail in Section 3.1) include situations in which
+   hosts are not configured with the address of a DNS server; where the
+   DNS server is unavailable or unreachable; where there is no DNS
+   server authoritative for the name of a host, or where the
+   authoritative DNS server does not have the desired RRs, as described
+   in Section 2.
+
+   Since LLMNR only operates on the local link, it cannot be considered
+   a substitute for DNS.  Link-scope multicast addresses are used to
+   prevent propagation of LLMNR traffic across routers, potentially
+   flooding the network.  LLMNR queries can also be sent to a unicast
+   address, as described in Section 2.4.
+
+   Propagation of LLMNR packets on the local link is considered
+   sufficient to enable name resolution in small networks.  In such
+   networks, if a network has a gateway, then typically the network is
+   able to provide DNS server configuration.  Configuration issues are
+   discussed in Section 3.1.
+
+   In the future, it may be desirable to consider use of multicast name
+   resolution with multicast scopes beyond the link-scope.  This could
+   occur if LLMNR deployment is successful, the need arises for
+   multicast name resolution beyond the link-scope, or multicast routing
+   becomes ubiquitous.  For example, expanded support for multicast name
+   resolution might be required for mobile ad-hoc networks.
+
+   Once we have experience in LLMNR deployment in terms of
+   administrative issues, usability and impact on the network, it will
+   be possible to reevaluate which multicast scopes are appropriate for
+   use with multicast name resolution.  IPv4 administratively scoped
+   multicast usage is specified in "Administratively Scoped IP
+   Multicast" [RFC2365].
+
+   Service discovery in general, as well as discovery of DNS servers
+   using LLMNR in particular, is outside of the scope of this document,
+   as is name resolution over non-multicast capable media.
+
+
+
+
+
+Aboba, Thaler & Esibov       Standards Track                    [Page 3]
+
+
+
+
+
+INTERNET-DRAFT                    LLMNR                   29 August 2005
+
+
+1.1.  Requirements
+
+   In this document, several words are used to signify the requirements
+   of the specification.  The key words "MUST", "MUST NOT", "REQUIRED",
+   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY",
+   and "OPTIONAL" in this document are to be interpreted as described in
+   [RFC2119].
+
+1.2.  Terminology
+
+   This document assumes familiarity with DNS terminology defined in
+   [RFC1035].  Other terminology used in this document includes:
+
+Positively Resolved
+     Responses with RCODE set to zero are referred to in this document
+     as "positively resolved".
+
+Routable Address
+     An address other than a Link-Local address.  This includes globally
+     routable addresses, as well as private addresses.
+
+Reachable
+     An LLMNR responder considers one of its addresses reachable over a
+     link if it will respond to an ARP or Neighbor Discovery query for
+     that address received on that link.
+
+Responder
+     A host that listens to LLMNR queries, and responds to those for
+     which it is authoritative.
+
+Sender
+     A host that sends an LLMNR query.
+
+UNIQUE
+     There are some scenarios when multiple responders may respond to
+     the same query.  There are other scenarios when only one responder
+     may respond to a query.  Names for which only a single responder is
+     anticipated are referred to as UNIQUE.  Name uniqueness is
+     configured on the responder, and therefore uniqueness verification
+     is the responder's responsibility.
+
+2.  Name Resolution Using LLMNR
+
+   LLMNR is a peer-to-peer name resolution protocol that is not intended
+   as a replacement for DNS.  LLMNR queries are sent to and received on
+   port 5355.  The IPv4 link-scope multicast address a given responder
+   listens to, and to which a sender sends queries, is 224.0.0.252.  The
+   IPv6 link-scope multicast address a given responder listens to, and
+
+
+
+Aboba, Thaler & Esibov       Standards Track                    [Page 4]
+
+
+
+
+
+INTERNET-DRAFT                    LLMNR                   29 August 2005
+
+
+   to which a sender sends all queries, is FF02:0:0:0:0:0:1:3.
+
+   Typically a host is configured as both an LLMNR sender and a
+   responder.  A host MAY be configured as a sender, but not a
+   responder.  However, a host configured as a responder MUST act as a
+   sender, if only to verify the uniqueness of names as described in
+   Section 4.  This document does not specify how names are chosen or
+   configured.  This may occur via any mechanism, including DHCPv4
+   [RFC2131] or DHCPv6 [RFC3315].
+
+   LLMNR usage MAY be configured manually or automatically on a per
+   interface basis.  By default, LLMNR responders SHOULD be enabled on
+   all interfaces, at all times.  Enabling LLMNR for use in situations
+   where a DNS server has been configured will result in a change in
+   default behavior without a simultaneous update to configuration
+   information.  Where this is considered undesirable, LLMNR SHOULD NOT
+   be enabled by default, so that hosts will neither listen on the link-
+   scope multicast address, nor will they send queries to that address.
+
+   By default, LLMNR queries MAY be sent only when one of the following
+   conditions are met:
+
+   [1] No manual or automatic DNS configuration has been performed.
+       If DNS server address(es) have been configured, then LLMNR
+       SHOULD NOT be used as the primary name resolution mechanism,
+       although it MAY be used as a secondary name resolution
+       mechanism.  A dual stack host SHOULD attempt to reach DNS
+       servers overall protocols on which DNS server address(es) are
+       configured, prior to sending LLMNR queries.  For dual stack
+       hosts configured with DNS server address(es) for one protocol
+       but not another, this inplies that DNS queries SHOULD be sent
+       over the protocol configured with a DNS server, prior to
+       sending LLMNR queries.
+
+   [2] All attempts to resolve the name via DNS on all interfaces
+       have failed after exhausting the searchlist.  This can occur
+       because DNS servers did not respond, or because they
+       responded to DNS queries with RCODE=3 (Authoritative Name
+       Error) or RCODE=0, and an empty answer section.  Where a
+       single resolver call generates DNS queries for A and AAAA RRs,
+       an implementation MAY choose not to send LLMNR queries if any
+       of the DNS queries is successful.  An LLMNR query SHOULD only
+       be sent for the originally requested name;  a searchlist
+       is not used to form additional LLMNR queries.
+
+   While these conditions are necessary for sending an LLMNR query, they
+   are not sufficient.  While an LLMNR sender MAY send a query for any
+   name, it also MAY impose additional conditions on sending LLMNR
+
+
+
+Aboba, Thaler & Esibov       Standards Track                    [Page 5]
+
+
+
+
+
+INTERNET-DRAFT                    LLMNR                   29 August 2005
+
+
+   queries.  For example, a sender configured with a DNS server MAY send
+   LLMNR queries only for unqualified names and for fully qualified
+   domain names within configured zones.
+
+   A typical sequence of events for LLMNR usage is as follows:
+
+   [a]  DNS servers are not configured or attempts to resolve the
+        name via DNS have failed, after exhausting the searchlist.
+        Also, the name to be queried satisfies the restrictions
+        imposed by the implementation.
+
+   [b]  An LLMNR sender sends an LLMNR query to the link-scope
+        multicast address(es), unless a unicast query is indicated,
+        as specified in Section 2.4.
+
+   [c]  A responder responds to this query only if it is authoritative
+        for the domain name in the query.  A responder responds to a
+        multicast query by sending a unicast UDP response to the sender.
+        Unicast queries are responded to as indicated in Section 2.4.
+
+   [d]  Upon reception of the response, the sender processes it.
+
+   The sections that follow provide further details on sender and
+   responder behavior.
+
+2.1.  LLMNR Packet Format
+
+   LLMNR is based on the DNS packet format defined in [RFC1035] Section
+   4 for both queries and responses.  LLMNR implementations SHOULD send
+   UDP queries and responses only as large as are known to be
+   permissible without causing fragmentation.  When in doubt a maximum
+   packet size of 512 octets SHOULD be used.  LLMNR implementations MUST
+   accept UDP queries and responses as large as the smaller of the link
+   MTU or 9194 octets (Ethernet jumbo frame size of 9KB (9216) minus 22
+   octets for the header, VLAN tag and CRC).
+
+2.1.1.  LLMNR Header Format
+
+   LLMNR queries and responses utilize the DNS header format defined in
+   [RFC1035] with exceptions noted below:
+
+
+
+
+
+
+
+
+
+
+
+Aboba, Thaler & Esibov       Standards Track                    [Page 6]
+
+
+
+
+
+INTERNET-DRAFT                    LLMNR                   29 August 2005
+
+
+                                   1  1  1  1  1  1
+     0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
+   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+   |                      ID                       |
+   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+   |QR|   Opcode  | C|TC| T| Z| Z| Z| Z|   RCODE   |
+   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+   |                    QDCOUNT                    |
+   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+   |                    ANCOUNT                    |
+   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+   |                    NSCOUNT                    |
+   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+   |                    ARCOUNT                    |
+   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+   where:
+
+ID   A 16 bit identifier assigned by the program that generates any kind
+     of query.  This identifier is copied from the query to the response
+     and can be used by the sender to match responses to outstanding
+     queries. The ID field in a query SHOULD be set to a pseudo-random
+     value.  For advice on generation of pseudo-random values, please
+     consult [RFC1750].
+
+QR   Query/Response.  A one bit field, which if set indicates that the
+     message is an LLMNR response; if clear then the message is an LLMNR
+     query.
+
+OPCODE
+     A four bit field that specifies the kind of query in this message.
+     This value is set by the originator of a query and copied into the
+     response.  This specification defines the behavior of standard
+     queries and responses (opcode value of zero).  Future
+     specifications may define the use of other opcodes with LLMNR.
+     LLMNR senders and responders MUST support standard queries (opcode
+     value of zero).  LLMNR queries with unsupported OPCODE values MUST
+     be silently discarded by responders.
+
+C    Conflict.  When set within a request, the 'C'onflict bit indicates
+     that a sender has received multiple LLMNR responses to this query.
+     In an LLMNR response, if the name is considered UNIQUE, then the
+     'C' bit is clear, otherwise it is set.  LLMNR senders do not
+     retransmit queries with the 'C' bit set.  Responders MUST NOT
+     respond to LLMNR queries with the 'C' bit set, but may start the
+     uniqueness verification process, as described in Section 4.2.
+
+
+
+
+
+Aboba, Thaler & Esibov       Standards Track                    [Page 7]
+
+
+
+
+
+INTERNET-DRAFT                    LLMNR                   29 August 2005
+
+
+TC   TrunCation - specifies that this message was truncated due to
+     length greater than that permitted on the transmission channel.
+     The TC bit MUST NOT be set in an LLMNR query and if set is ignored
+     by an LLMNR responder.  If the TC bit is set in an LLMNR response,
+     then the sender SHOULD discard the response and resend the LLMNR
+     query over TCP using the unicast address of the responder as the
+     destination address.  See  [RFC2181] and Section 2.4 of this
+     specification for further discussion of the TC bit.
+
+T    Tentative.  The 'T'entative bit is set in a response if the
+     responder is authoritative for the name, but has not yet verified
+     the uniqueness of the name.  A responder MUST ignore the 'T' bit in
+     a query, if set.  A response with the 'T' bit set is silently
+     discarded by the sender, except if it is a uniqueness query, in
+     which case a conflict has been detected and a responder MUST
+     resolve the conflict as described in Section 4.1.
+
+Z    Reserved for future use.  Implementations of this specification
+     MUST set these bits to zero in both queries and responses.  If
+     these bits are set in a LLMNR query or response, implementations of
+     this specification MUST ignore them.  Since reserved bits could
+     conceivably be used for different purposes than in DNS,
+     implementors are advised not to enable processing of these bits in
+     an LLMNR implementation starting from a DNS code base.
+
+RCODE
+     Response code -- this 4 bit field is set as part of LLMNR
+     responses.  In an LLMNR query, the sender MUST set RCODE to zero;
+     the responder ignores the RCODE and assumes it to be zero.  The
+     response to a multicast LLMNR query MUST have RCODE set to zero.  A
+     sender MUST silently discard an LLMNR response with a non-zero
+     RCODE sent in response to a multicast query.
+
+     If an LLMNR responder is authoritative for the name in a multicast
+     query, but an error is encountered, the responder SHOULD send an
+     LLMNR response with an RCODE of zero, no RRs in the answer section,
+     and the TC bit set.  This will cause the query to be resent using
+     TCP, and allow the inclusion of a non-zero RCODE in the response to
+     the TCP query.  Responding with the TC bit set is preferable to not
+     sending a response, since it enables errors to be diagnosed.
+     Errors include those defined in [RFC2845], such as BADSIG(16),
+     BADKEY(17) and BADTIME(18).
+
+     Since LLMNR responders only respond to LLMNR queries for names for
+     which they are authoritative, LLMNR responders MUST NOT respond
+     with an RCODE of 3; instead, they should not respond at all.
+
+     LLMNR implementations MUST support EDNS0 [RFC2671] and extended
+
+
+
+Aboba, Thaler & Esibov       Standards Track                    [Page 8]
+
+
+
+
+
+INTERNET-DRAFT                    LLMNR                   29 August 2005
+
+
+     RCODE values.
+
+QDCOUNT
+     An unsigned 16 bit integer specifying the number of entries in the
+     question section.  A sender MUST place only one question into the
+     question section of an LLMNR query.  LLMNR responders MUST silently
+     discard LLMNR queries with QDCOUNT not equal to one.  LLMNR senders
+     MUST silently discard LLMNR responses with QDCOUNT not equal to
+     one.
+
+ANCOUNT
+     An unsigned 16 bit integer specifying the number of resource
+     records in the answer section.  LLMNR responders MUST silently
+     discard LLMNR queries with ANCOUNT not equal to zero.
+
+NSCOUNT
+     An unsigned 16 bit integer specifying the number of name server
+     resource records in the authority records section.  Authority
+     record section processing is described in Section 2.9.  LLMNR
+     responders MUST silently discard LLMNR queries with NSCOUNT not
+     equal to zero.
+
+ARCOUNT
+     An unsigned 16 bit integer specifying the number of resource
+     records in the additional records section.  Additional record
+     section processing is described in Section 2.9.
+
+2.2.  Sender Behavior
+
+   A sender MAY send an LLMNR query for any legal resource record  type
+   (e.g., A, AAAA, PTR, SRV, etc.) to the link-scope multicast address.
+   As described in Section 2.4, a sender MAY also send a unicast query.
+
+   The sender MUST anticipate receiving no replies to some LLMNR
+   queries, in the event that no responders are available within the
+   link-scope.  If no response is received, a resolver treats it as a
+   response that the name does not exist (RCODE=3 is returned).  A
+   sender can handle duplicate responses by discarding responses with a
+   source IP address and ID field that duplicate a response already
+   received.
+
+   When multiple valid LLMNR responses are received with the 'C' bit
+   set, they SHOULD be concatenated and treated in the same manner that
+   multiple RRs received from the same DNS server would be.  However,
+   responses with the 'C' bit set SHOULD NOT be concatenated with
+   responses with the 'C' bit clear; instead, only the responses with
+   the 'C' bit set SHOULD be returned.  If valid LLMNR response(s) are
+   received along with error response(s), then the error responses are
+
+
+
+Aboba, Thaler & Esibov       Standards Track                    [Page 9]
+
+
+
+
+
+INTERNET-DRAFT                    LLMNR                   29 August 2005
+
+
+   silently discarded.
+
+   If error responses are received from both DNS and LLMNR, then the
+   lowest RCODE value should be returned. For example, if either DNS or
+   LLMNR receives a response with RCODE=0, then this should returned to
+   the caller.
+
+   Since the responder may order the RRs in the response so as to
+   indicate preference, the sender SHOULD preserve ordering in the
+   response to the querying application.
+
+2.3.  Responder Behavior
+
+   An LLMNR response MUST be sent to the sender via unicast.
+
+   Upon configuring an IP address, responders typically will synthesize
+   corresponding A, AAAA and PTR RRs so as to be able to respond to
+   LLMNR queries for these RRs.  An SOA RR is synthesized only when a
+   responder has another RR in addition to the SOA RR;  the SOA RR MUST
+   NOT be the only RR that a responder has.  However, in general whether
+   RRs are manually or automatically created is an implementation
+   decision.
+
+   For example, a host configured to have computer name "host1" and to
+   be a member of the "example.com" domain, and with IPv4 address
+   192.0.2.1 and IPv6 address 2001:0DB8::1:2:3:FF:FE:4:5:6 might be
+   authoritative for the following records:
+
+   host1. IN A 192.0.2.1
+          IN AAAA 2001:0DB8::1:2:3:FF:FE:4:5:6
+
+   host1.example.com. IN A 192.0.2.1
+          IN AAAA 2001:0DB8::1:2:3:FF:FE:4:5:6
+
+   1.2.0.192.in-addr.arpa. IN PTR host1.
+          IN PTR host1.example.com.
+
+   6.0.5.0.4.0.E.F.F.F.3.0.2.0.1.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.
+   ip6.arpa IN PTR host1.  (line split for formatting reasons)
+            IN PTR host1.example.com.
+
+   An LLMNR responder might be further manually configured with the name
+   of a local mail server with an MX RR included in the "host1." and
+   "host1.example.com." records.
+
+   In responding to queries:
+
+
+
+
+
+Aboba, Thaler & Esibov       Standards Track                   [Page 10]
+
+
+
+
+
+INTERNET-DRAFT                    LLMNR                   29 August 2005
+
+
+[a]  Responders MUST listen on UDP port 5355 on the link-scope multicast
+     address(es) defined in Section 2, and on UDP and TCP port 5355 on
+     the unicast address(es) that could be set as the source address(es)
+     when the responder responds to the LLMNR query.
+
+[b]  Responders MUST direct responses to the port from which the query
+     was sent.  When queries are received via TCP this is an inherent
+     part of the transport protocol.  For queries received by UDP the
+     responder MUST take note of the source port and use that as the
+     destination port in the response.  Responses MUST always be sent
+     from the port to which they were directed.
+
+[c]  Responders MUST respond to LLMNR queries for names and addresses
+     they are authoritative for.  This applies to both forward and
+     reverse lookups, with the exception of queries with the 'C' bit
+     set, which do not elicit a response.
+
+[d]  Responders MUST NOT respond to LLMNR queries for names they are not
+     authoritative for.
+
+[e]  Responders MUST NOT respond using data from the LLMNR or DNS
+     resolver cache.
+
+[f]  If a DNS server is running on a host that supports LLMNR, the DNS
+     server MUST respond to LLMNR queries only for the RRSets relating
+     to the host on which the server is running, but MUST NOT respond
+     for other records for which the server is authoritative.  DNS
+     servers also MUST NOT send LLMNR queries in order to resolve DNS
+     queries.
+
+[g]  If a responder is authoritative for a name, it MUST respond with
+     RCODE=0 and an empty answer section, if the type of query does not
+     match a RR that the responder has.
+
+   As an example, a host configured to respond to LLMNR queries for the
+   name "foo.example.com."  is authoritative for the name
+   "foo.example.com.".  On receiving an LLMNR query for an A RR with the
+   name "foo.example.com." the host authoritatively responds with A
+   RR(s) that contain IP address(es) in the RDATA of the resource
+   record.  If the responder has a AAAA RR, but no A RR, and an A RR
+   query is received, the responder would respond with RCODE=0 and an
+   empty answer section.
+
+   In conventional DNS terminology a DNS server authoritative for a zone
+   is authoritative for all the domain names under the zone apex except
+   for the branches delegated into separate zones.  Contrary to
+   conventional DNS terminology, an LLMNR responder is authoritative
+   only for the zone apex.
+
+
+
+Aboba, Thaler & Esibov       Standards Track                   [Page 11]
+
+
+
+
+
+INTERNET-DRAFT                    LLMNR                   29 August 2005
+
+
+   For example the host "foo.example.com." is not authoritative for the
+   name "child.foo.example.com." unless the host is configured with
+   multiple names, including "foo.example.com."  and
+   "child.foo.example.com.".  As a result, "foo.example.com." cannot
+   reply to an LLMNR query for "child.foo.example.com." with RCODE=3
+   (authoritative name error).  The purpose of limiting the name
+   authority scope of a responder is to prevent complications that could
+   be caused by coexistence of two or more hosts with the names
+   representing child and parent (or grandparent) nodes in the DNS tree,
+   for example, "foo.example.com." and "child.foo.example.com.".
+
+   Without the restriction on authority an LLMNR query for an A resource
+   record for the name "child.foo.example.com." would result in two
+   authoritative responses: RCODE=3 (authoritative name error) received
+   from "foo.example.com.", and a requested A record - from
+   "child.foo.example.com.".  To prevent this ambiguity, LLMNR enabled
+   hosts could perform a dynamic update of the parent (or grandparent)
+   zone with a delegation to a child zone;  for example a host
+   "child.foo.example.com." could send a dynamic update for the NS and
+   glue A record to "foo.example.com.".  However, this approach
+   significantly complicates implementation of LLMNR and would not be
+   acceptable for lightweight hosts.
+
+2.4.  Unicast Queries and Responses
+
+   Unicast queries SHOULD be sent when:
+
+   [a] A sender repeats a query after it received a response
+       with the TC bit set to the previous LLMNR multicast query, or
+
+   [b] The sender queries for a PTR RR of a fully formed IP address
+       within the "in-addr.arpa" or "ip6.arpa" zones.
+
+   Unicast LLMNR queries MUST be done using TCP and the responses MUST
+   be sent using the same TCP connection as the query.  Senders MUST
+   support sending TCP queries, and responders MUST support listening
+   for TCP queries. If the sender of a TCP query receives a response to
+   that query not using TCP, the response MUST be silently discarded.
+
+   Unicast UDP queries MUST be silently discarded.
+
+   If TCP connection setup cannot be completed in order to send a
+   unicast TCP query, this is treated as a response that no records of
+   the specified type and class exist for the specified name (it is
+   treated the same as a response with RCODE=0 and an empty answer
+   section).
+
+
+
+
+
+Aboba, Thaler & Esibov       Standards Track                   [Page 12]
+
+
+
+
+
+INTERNET-DRAFT                    LLMNR                   29 August 2005
+
+
+2.5.  "Off link" Detection
+
+   A sender MUST select a source address for LLMNR queries that is
+   assigned on the interface on which the query is sent.  The
+   destination address of an LLMNR query MUST be a link-scope multicast
+   address or a unicast address.
+
+   A responder MUST select a source address for responses that is
+   assigned on the interface on which the query was received.  The
+   destination address of an LLMNR response MUST be a unicast address.
+
+   On receiving an LLMNR query, the responder MUST check whether it was
+   sent to a LLMNR multicast addresses defined in Section 2.  If it was
+   sent to another multicast address, then the query MUST be silently
+   discarded.
+
+   Section 2.4 discusses use of TCP for LLMNR queries and responses.  In
+   composing an LLMNR query using TCP, the sender MUST set the Hop Limit
+   field in the IPv6 header and the TTL field in the IPv4 header of the
+   response to one (1).  The responder SHOULD set the TTL or Hop Limit
+   settings on the TCP listen socket to one (1) so that SYN-ACK packets
+   will have TTL (IPv4) or Hop Limit (IPv6) set to one (1). This
+   prevents an incoming connection from off-link since the sender will
+   not receive a SYN-ACK from the responder.
+
+   For UDP queries and responses, the Hop Limit field in the IPv6 header
+   and the TTL field in the IPV4 header MAY be set to any value.
+   However, it is RECOMMENDED that the value 255 be used for
+   compatibility with Apple Bonjour [Bonjour].
+
+   Implementation note:
+
+      In the sockets API for IPv4 [POSIX], the IP_TTL and
+      IP_MULTICAST_TTL socket options are used to set the TTL of
+      outgoing unicast and multicast packets. The IP_RECVTTL socket
+      option is available on some platforms to retrieve the IPv4 TTL of
+      received packets with recvmsg().  [RFC2292] specifies similar
+      options for setting and retrieving the IPv6 Hop Limit.
+
+2.6.  Responder Responsibilities
+
+   It is the responsibility of the responder to ensure that RRs returned
+   in LLMNR responses MUST only include values that are valid on the
+   local interface, such as IPv4 or IPv6 addresses valid on the local
+   link or names defended using the mechanism described in Section 4.
+   IPv4 Link-Local addresses are defined in [RFC3927].  IPv6 Link-Local
+   addresses are defined in [RFC2373].  In particular:
+
+
+
+
+Aboba, Thaler & Esibov       Standards Track                   [Page 13]
+
+
+
+
+
+INTERNET-DRAFT                    LLMNR                   29 August 2005
+
+
+   [a] If a link-scope IPv6 address is returned in a AAAA RR,
+       that address MUST be valid on the local link over which
+       LLMNR is used.
+
+   [b] If an IPv4 address is returned, it MUST be reachable
+       through the link over which LLMNR is used.
+
+   [c] If a name is returned (for example in a CNAME, MX
+       or SRV RR), the name MUST be resolvable on the local
+       link over which LLMNR is used.
+
+   Where multiple addresses represent valid responses to a query, the
+   order in which the addresses are returned is as follows:
+
+   [d] If the source address of the query is a link-scope address,
+       then the responder SHOULD include a link-scope address first
+       in the response, if available.
+
+   [e] If the source address of the query is a routable address,
+       then the responder MUST include a routable address first
+       in the response, if available.
+
+2.7.  Retransmission and Jitter
+
+   An LLMNR sender uses the timeout interval LLMNR_TIMEOUT to determine
+   when to retransmit an LLMNR query.  An LLMNR sender SHOULD either
+   estimate the LLMNR_TIMEOUT for each interface, or set a reasonably
+   high initial timeout.  Suggested constants are described in Section
+   7.
+
+   If an LLMNR query sent over UDP is not resolved within LLMNR_TIMEOUT,
+   then a sender SHOULD repeat the transmission of the query in order to
+   assure that it was received by a host capable of responding to it,
+   while increasing the value of LLMNR_TIMEOUT exponentially.  An LLMNR
+   query SHOULD NOT be sent more than three times.
+
+   Where LLMNR queries are sent using TCP, retransmission is handled by
+   the transport layer.  Queries with the 'C' bit set MUST be sent using
+   multicast UDP and MUST NOT be retransmitted.
+
+   An LLMNR sender cannot know in advance if a query sent using
+   multicast will receive no response, one response, or more than one
+   response.  An LLMNR sender MUST wait for LLMNR_TIMEOUT if no response
+   has been received, or if it is necessary to collect all potential
+   responses, such as if a uniqueness verification query is being made.
+   Otherwise an LLMNR sender SHOULD consider a multicast query answered
+   after the first response is received, if that response has the 'C'
+   bit clear.
+
+
+
+Aboba, Thaler & Esibov       Standards Track                   [Page 14]
+
+
+
+
+
+INTERNET-DRAFT                    LLMNR                   29 August 2005
+
+
+   However, if the first response has the 'C' bit set, then the sender
+   SHOULD wait for LLMNR_TIMEOUT in order to collect all possible
+   responses.  When multiple valid answers are received, they may first
+   be concatenated, and then treated in the same manner that multiple
+   RRs received from the same DNS server would.  A unicast query sender
+   considers the query answered after the first response is received, so
+   that it only waits for LLMNR_TIMEOUT if no response has been
+   received.
+
+   Since it is possible for a response with the 'C' bit clear to be
+   followed by a response with the 'C' bit set, an LLMNR sender SHOULD
+   be prepared to process additional responses for the purposes of
+   conflict detection and LLMNR_TIMEOUT estimation, even after it has
+   considered a query answered.
+
+   In order to avoid synchronization, the transmission of each LLMNR
+   query and response SHOULD delayed by a time randomly selected from
+   the interval 0 to JITTER_INTERVAL. This delay MAY be avoided by
+   responders responding with names which they have previously
+   determined to be UNIQUE (see Section 4 for details).
+
+2.8.  DNS TTL
+
+   The responder should insert a pre-configured TTL value in the records
+   returned in an LLMNR response.  A default value of 30 seconds is
+   RECOMMENDED.  In highly dynamic environments (such as mobile ad-hoc
+   networks), the TTL value may need to be reduced.
+
+   Due to the TTL minimalization necessary when caching an RRset, all
+   TTLs in an RRset MUST be set to the same value.
+
+2.9.  Use of the Authority and Additional Sections
+
+   Unlike the DNS, LLMNR is a peer-to-peer protocol and does not have a
+   concept of delegation.  In LLMNR, the NS resource record type may be
+   stored and queried for like any other type, but it has no special
+   delegation semantics as it does in the DNS.  Responders MAY have NS
+   records associated with the names for which they are authoritative,
+   but they SHOULD NOT include these NS records in the authority
+   sections of responses.
+
+   Responders SHOULD insert an SOA record into the authority section of
+   a negative response, to facilitate negative caching as specified in
+   [RFC2308]. The TTL of this record is set from the minimum of the
+   MINIMUM field of the SOA record and the TTL of the SOA itself, and
+   indicates how long a resolver may cache the negative answer.  The
+   owner name of the SOA record (MNAME) MUST be set to the query name.
+   The RNAME, SERIAL, REFRESH, RETRY and EXPIRE values MUST be ignored
+
+
+
+Aboba, Thaler & Esibov       Standards Track                   [Page 15]
+
+
+
+
+
+INTERNET-DRAFT                    LLMNR                   29 August 2005
+
+
+   by senders.  Negative responses without SOA records SHOULD NOT be
+   cached.
+
+   In LLMNR, the additional section is primarily intended for use by
+   EDNS0, TSIG and SIG(0).  As a result, unless the 'C' bit is set,
+   senders MAY only include pseudo RR-types in the additional section of
+   a query; unless the 'C' bit is set, responders MUST ignore the
+   additional section of queries containing other RR types.
+
+   In queries where the 'C' bit is set, the sender SHOULD include the
+   conflicting RRs in the additional section.  Since conflict
+   notifications are advisory, responders SHOULD log information from
+   the additional section, but otherwise MUST ignore the additional
+   section.
+
+   Senders MUST NOT cache RRs from the authority or additional section
+   of a response as answers, though they may be used for other purposes
+   such as negative caching.
+
+3.  Usage Model
+
+   Since LLMNR is a secondary name resolution mechanism, its usage is in
+   part determined by the behavior of DNS implementations.  This
+   document does not specify any changes to DNS resolver behavior, such
+   as searchlist processing or retransmission/failover policy.  However,
+   robust DNS resolver implementations are more likely to avoid
+   unnecessary LLMNR queries.
+
+   As noted in [DNSPerf], even when DNS servers are configured, a
+   significant fraction of DNS queries do not receive a response, or
+   result in negative responses due to missing inverse mappings or NS
+   records that point to nonexistent or inappropriate hosts.  This has
+   the potential to result in a large number of unnecessary LLMNR
+   queries.
+
+   [RFC1536] describes common DNS implementation errors and fixes.  If
+   the proposed fixes are implemented, unnecessary LLMNR queries will be
+   reduced substantially, and so implementation of [RFC1536] is
+   recommended.
+
+   For example, [RFC1536] Section 1 describes issues with retransmission
+   and recommends implementation of a retransmission policy based on
+   round trip estimates, with exponential backoff.  [RFC1536] Section 4
+   describes issues with failover, and recommends that resolvers try
+   another server when they don't receive a response to a query.  These
+   policies are likely to avoid unnecessary LLMNR queries.
+
+   [RFC1536] Section 3 describes zero answer bugs, which if addressed
+
+
+
+Aboba, Thaler & Esibov       Standards Track                   [Page 16]
+
+
+
+
+
+INTERNET-DRAFT                    LLMNR                   29 August 2005
+
+
+   will also reduce unnecessary LLMNR queries.
+
+   [RFC1536] Section 6 describes name error bugs and recommended
+   searchlist processing that will reduce unnecessary RCODE=3
+   (authoritative name) errors, thereby also reducing unnecessary LLMNR
+   queries.
+
+3.1.  LLMNR Configuration
+
+   Since IPv4 and IPv6 utilize distinct configuration mechanisms, it is
+   possible for a dual stack host to be configured with the address of a
+   DNS server over IPv4, while remaining unconfigured with a DNS server
+   suitable for use over IPv6.
+
+   In these situations, a dual stack host will send AAAA queries to the
+   configured DNS server over IPv4.  However, an IPv6-only host
+   unconfigured with a DNS server suitable for use over IPv6 will be
+   unable to resolve names using DNS.  Automatic IPv6 DNS configuration
+   mechanisms (such as [RFC3315] and [DNSDisc]) are not yet widely
+   deployed, and not all DNS servers support IPv6.  Therefore lack of
+   IPv6 DNS configuration may be a common problem in the short term, and
+   LLMNR may prove useful in enabling link-local name resolution over
+   IPv6.
+
+   Where a DHCPv4 server is available but not a DHCPv6 server [RFC3315],
+   IPv6-only hosts may not be configured with a DNS server.  Where there
+   is no DNS server authoritative for the name of a host or the
+   authoritative DNS server does not support dynamic client update over
+   IPv6 or DHCPv6-based dynamic update, then an IPv6-only host will not
+   be able to do DNS dynamic update, and other hosts will not be able to
+   resolve its name.
+
+   For example, if the configured DNS server responds to a AAAA RR query
+   sent over IPv4 or IPv6 with an authoritative name error (RCODE=3) or
+   RCODE=0 and an empty answer section, then a AAAA RR query sent using
+   LLMNR over IPv6 may be successful in resolving the name of an
+   IPv6-only host on the local link.
+
+   Similarly, if a DHCPv4 server is available providing DNS server
+   configuration, and DNS server(s) exist which are authoritative for
+   the A RRs of local hosts and support either dynamic client update
+   over IPv4 or DHCPv4-based dynamic update, then the names of local
+   IPv4 hosts can be resolved over IPv4 without LLMNR.  However,  if no
+   DNS server is authoritative for the names of local hosts, or the
+   authoritative DNS server(s) do not support dynamic update, then LLMNR
+   enables linklocal name resolution over IPv4.
+
+   Where DHCPv4 or DHCPv6 is implemented, DHCP options can be used to
+
+
+
+Aboba, Thaler & Esibov       Standards Track                   [Page 17]
+
+
+
+
+
+INTERNET-DRAFT                    LLMNR                   29 August 2005
+
+
+   configure LLMNR on an interface.  The LLMNR Enable Option, described
+   in [LLMNREnable], can be used to explicitly enable or disable use of
+   LLMNR on an interface.  The LLMNR Enable Option does not determine
+   whether or in which order DNS itself is used for name resolution.
+   The order in which various name resolution mechanisms should be used
+   can be specified using the Name Service Search Option (NSSO) for DHCP
+   [RFC2937], using the LLMNR Enable Option code carried in the NSSO
+   data.
+
+   It is possible that DNS configuration mechanisms will go in and out
+   of service.  In these circumstances, it is possible for hosts within
+   an administrative domain to be inconsistent in their DNS
+   configuration.
+
+   For example, where DHCP is used for configuring DNS servers, one or
+   more DHCP servers can fail.  As a result, hosts configured prior to
+   the outage will be configured with a DNS server, while hosts
+   configured after the outage will not.  Alternatively, it is possible
+   for the DNS configuration mechanism to continue functioning while
+   configured DNS servers fail.
+
+   An outage in the DNS configuration mechanism may result in hosts
+   continuing to use LLMNR even once the outage is repaired.  Since
+   LLMNR only enables linklocal name resolution, this represents a
+   degradation in capabilities.  As a result, hosts without a configured
+   DNS server may wish to periodically attempt to obtain DNS
+   configuration if permitted by the configuration mechanism in use.  In
+   the absence of other guidance, a default retry interval of one (1)
+   minute is RECOMMENDED.
+
+4.  Conflict Resolution
+
+   By default, a responder SHOULD be configured to behave as though its
+   name is UNIQUE on each interface on which LLMNR is enabled.  However,
+   it is also possible to configure multiple responders to be
+   authoritative for the same name.  For example, multiple responders
+   MAY respond to a query for an A or AAAA type record for a cluster
+   name (assigned to multiple hosts in the cluster).
+
+   To detect duplicate use of a name, an administrator can use a name
+   resolution utility which employs LLMNR and lists both responses and
+   responders.  This would allow an administrator to diagnose behavior
+   and potentially to intervene and reconfigure LLMNR responders who
+   should not be configured to respond to the same name.
+
+
+
+
+
+
+
+Aboba, Thaler & Esibov       Standards Track                   [Page 18]
+
+
+
+
+
+INTERNET-DRAFT                    LLMNR                   29 August 2005
+
+
+4.1.  Uniqueness Verification
+
+   Prior to sending an LLMNR response with the 'T' bit clear, a
+   responder configured with a UNIQUE name MUST verify that there is no
+   other host within the scope of LLMNR query propagation that is
+   authoritative for the same name on that interface.
+
+   Once a responder has verified that its name is UNIQUE, if it receives
+   an LLMNR query for that name, with the 'C' bit clear, it MUST
+   respond, with the 'T' bit clear. Prior to verifying that its name is
+   UNIQUE, a responder MUST set the 'T' bit in responses.
+
+   Uniqueness verification is carried out when the host:
+
+     - starts up or is rebooted
+     - wakes from sleep (if the network interface was inactive
+       during sleep)
+     - is configured to respond to LLMNR queries on an interface
+       enabled for transmission and reception of IP traffic
+     - is configured to respond to LLMNR queries using additional
+       UNIQUE resource records
+     - verifies the acquisition of a new IP address and configuration
+       on an interface
+
+   To verify uniqueness, a responder MUST send an LLMNR query with the
+   'C' bit clear, over all protocols on which it responds to LLMNR
+   queries (IPv4 and/or IPv6).  It is RECOMMENDED that responders verify
+   uniqueness of a name by sending a query for the name with type='ANY'.
+
+   If no response is received, the sender retransmits the query, as
+   specified in Section 2.7.  If a response is received, the sender MUST
+   check if the source address matches the address of any of its
+   interfaces; if so, then the response is not considered a conflict,
+   since it originates from the sender.  To avoid triggering conflict
+   detection, a responder that detects that it is connected to the same
+   link on multiple interfaces SHOULD set the 'C' bit in responses.
+
+   If a response is received with the 'T' bit clear, the responder MUST
+   NOT use the name in response to LLMNR queries received over any
+   protocol (IPv4 or IPv6).  If a response is received with the 'T' bit
+   set, the responder MUST check if the source IP address in the
+   response, interpreted as an unsigned integer, is less than the source
+   IP address in the query.  If so, the responder MUST NOT use the name
+   in response to LLMNR queries received over any protocol (IPv4 or
+   IPv6).  For the purpose of uniqueness verification, the contents of
+   the answer section in a response is irrelevant.
+
+   Periodically carrying out uniqueness verification in an attempt to
+
+
+
+Aboba, Thaler & Esibov       Standards Track                   [Page 19]
+
+
+
+
+
+INTERNET-DRAFT                    LLMNR                   29 August 2005
+
+
+   detect name conflicts is not necessary, wastes network bandwidth, and
+   may actually be detrimental.  For example, if network links are
+   joined only briefly, and are separated again before any new
+   communication is initiated, temporary conflicts are benign and no
+   forced reconfiguration is required.  LLMNR responders SHOULD NOT
+   periodically attempt uniqueness verification.
+
+4.2.  Conflict Detection and Defense
+
+   Hosts on disjoint network links may configure the same name for use
+   with LLMNR.  If these separate network links are later joined or
+   bridged together, then there may be multiple hosts which are now on
+   the same link, trying to use the same name.
+
+   In order to enable ongoing detection of name conflicts, when an LLMNR
+   sender receives multiple LLMNR responses to a query, it MUST check if
+   the 'C' bit is clear in any of the responses.  If so, the sender
+   SHOULD send another query for the same name, type and class, this
+   time with the 'C' bit set, with the potentially conflicting resource
+   records included in the additional section.
+
+   Queries with the 'C' bit set are considered advisory and responders
+   MUST verify the existence of a conflict before acting on it.  A
+   responder receiving a query with the 'C' bit set MUST NOT respond.
+
+   If the query is for a UNIQUE name, then the responder MUST send its
+   own query for the same name, type and class, with the 'C' bit clear.
+   If a response is received, the sender MUST check if the source
+   address matches the address of any of its interfaces; if so, then the
+   response is not considered a conflict, since it originates from the
+   sender.  To avoid triggering conflict detection, a responder that
+   detects that it is connected to the same link on multiple interfaces
+   SHOULD set the 'C' bit in responses.
+
+   An LLMNR responder MUST NOT ignore conflicts once detected and SHOULD
+   log them.  Upon detecting a conflict, an LLMNR responder MUST
+   immediately stop using the conflicting name in response to LLMNR
+   queries received over any supported protocol, if the source IP
+   address in the response, interpreted as an unsigned integer, is less
+   than the source IP address in the uniqueness verification query.
+
+   After stopping the use of a name, the responder MAY elect to
+   configure a new name.  However, since name reconfiguration may be
+   disruptive, this is not required, and a responder may have been
+   configured to respond to multiple names so that alternative names may
+   already be available.  A host that has stopped the use of a name may
+   attempt uniqueness verification again after the expiration of the TTL
+   of the conflicting response.
+
+
+
+Aboba, Thaler & Esibov       Standards Track                   [Page 20]
+
+
+
+
+
+INTERNET-DRAFT                    LLMNR                   29 August 2005
+
+
+4.3.  Considerations for Multiple Interfaces
+
+   A multi-homed host may elect to configure LLMNR on only one of its
+   active interfaces.  In many situations this will be adequate.
+   However, should a host need to configure LLMNR on more than one of
+   its active interfaces, there are some additional precautions it MUST
+   take.  Implementers who are not planning to support LLMNR on multiple
+   interfaces simultaneously may skip this section.
+
+   Where a host is configured to issue LLMNR queries on more than one
+   interface, each interface maintains its own independent LLMNR
+   resolver cache, containing the responses to LLMNR queries.
+
+   A multi-homed host checks the uniqueness of UNIQUE records as
+   described in Section 4.  The situation is illustrated in figure 1.
+
+        ----------  ----------
+         |      |    |      |
+        [A]    [myhost]   [myhost]
+
+      Figure 1.  Link-scope name conflict
+
+   In this situation, the multi-homed myhost will probe for, and defend,
+   its host name on both interfaces.  A conflict will be detected on one
+   interface, but not the other.  The multi-homed myhost will not be
+   able to respond with a host RR for "myhost" on the interface on the
+   right (see Figure 1).  The multi-homed host may, however, be
+   configured to use the "myhost" name on the interface on the left.
+
+   Since names are only unique per-link, hosts on different links could
+   be using the same name.  If an LLMNR client sends requests over
+   multiple interfaces, and receives replies from more than one, the
+   result returned to the client is defined by the implementation.  The
+   situation is illustrated in figure 2.
+
+        ----------  ----------
+         |      |    |     |
+        [A]    [myhost]   [A]
+
+
+      Figure 2.  Off-segment name conflict
+
+   If host myhost is configured to use LLMNR on both interfaces, it will
+   send LLMNR queries on both interfaces.  When host myhost sends a
+   query for the host RR for name "A" it will receive a response from
+   hosts on both interfaces.
+
+   Host myhost cannot distinguish between the situation shown in Figure
+
+
+
+Aboba, Thaler & Esibov       Standards Track                   [Page 21]
+
+
+
+
+
+INTERNET-DRAFT                    LLMNR                   29 August 2005
+
+
+   2, and that shown in Figure 3 where no conflict exists.
+
+                [A]
+               |   |
+           -----   -----
+               |   |
+              [myhost]
+
+      Figure 3.  Multiple paths to same host
+
+   This illustrates that the proposed name conflict resolution mechanism
+   does not support detection or resolution of conflicts between hosts
+   on different links.  This problem can also occur with DNS when a
+   multi-homed host is connected to two different networks with
+   separated name spaces.  It is not the intent of this document to
+   address the issue of uniqueness of names within DNS.
+
+4.4.  API Issues
+
+   [RFC2553] provides an API which can partially solve the name
+   ambiguity problem for applications written to use this API, since the
+   sockaddr_in6 structure exposes the scope within which each scoped
+   address exists, and this structure can be used for both IPv4 (using
+   v4-mapped IPv6 addresses) and IPv6 addresses.
+
+   Following the example in Figure 2, an application on 'myhost' issues
+   the request getaddrinfo("A", ...) with ai_family=AF_INET6 and
+   ai_flags=AI_ALL|AI_V4MAPPED.  LLMNR requests will be sent from both
+   interfaces and the resolver library will return a list containing
+   multiple addrinfo structures, each with an associated sockaddr_in6
+   structure.  This list will thus contain the IPv4 and IPv6 addresses
+   of both hosts responding to the name 'A'.  Link-local addresses will
+   have a sin6_scope_id value that disambiguates which interface is used
+   to reach the address.  Of course, to the application, Figures 2 and 3
+   are still indistinguishable, but this API allows the application to
+   communicate successfully with any address in the list.
+
+5.  Security Considerations
+
+   LLMNR is a peer-to-peer name resolution protocol designed for use on
+   the local link.  While LLMNR limits the vulnerability of responders
+   to off-link senders, it is possible for an off-link responder to
+   reach a sender.
+
+   In scenarios such as public "hotspots" attackers can be present on
+   the same link.  These threats are most serious in wireless networks
+   such as 802.11, since attackers on a wired network will require
+   physical access to the network, while wireless attackers may mount
+
+
+
+Aboba, Thaler & Esibov       Standards Track                   [Page 22]
+
+
+
+
+
+INTERNET-DRAFT                    LLMNR                   29 August 2005
+
+
+   attacks from a distance.  Link-layer security such as [IEEE-802.11i]
+   can be of assistance against these threats if it is available.
+
+   This section details security measures available to mitigate threats
+   from on and off-link attackers.
+
+5.1.  Denial of Service
+
+   Attackers may take advantage of LLMNR conflict detection by
+   allocating the same name, denying service to other LLMNR responders
+   and possibly allowing an attacker to receive packets destined for
+   other hosts.  By logging conflicts, LLMNR responders can provide
+   forensic evidence of these attacks.
+
+   An attacker may spoof LLMNR queries from a victim's address in order
+   to mount a denial of service attack.  Responders setting the IPv6 Hop
+   Limit or IPv4 TTL field to a value larger than one in an LLMNR UDP
+   response may be able to reach the victim across the Internet.
+
+   While LLMNR responders only respond to queries for which they are
+   authoritative and LLMNR does not provide wildcard query support, an
+   LLMNR response may be larger than the query, and an attacker can
+   generate multiple responses to a query for a name used by multiple
+   responders.  A sender may protect itself against unsolicited
+   responses by silently discarding them as rapidly as possible.
+
+5.2.  Spoofing
+
+   LLMNR is designed to prevent reception of queries sent by an off-link
+   attacker.  LLMNR requires that responders receiving UDP queries check
+   that they are sent to a link-scope multicast address.  However, it is
+   possible that some routers may not properly implement link-scope
+   multicast, or that link-scope multicast addresses may leak into the
+   multicast routing system.  To prevent successful setup of TCP
+   connections by an off-link sender, responders receiving a TCP SYN
+   reply with a TCP SYN-ACK with TTL set to one (1).
+
+   While it is difficult for an off-link attacker to send an LLMNR query
+   to a responder,  it is possible for an off-link attacker to spoof a
+   response to a query (such as an A or AAAA query for a popular
+   Internet host), and by using a TTL or Hop Limit field larger than one
+   (1), for the forged response to reach the LLMNR sender.  Since the
+   forged response will only be accepted if it contains a matching ID
+   field, choosing a pseudo-random ID field within queries provides some
+   protection against off-link responders.
+
+   Since LLMNR queries can be sent when DNS server(s) do not respond, an
+   attacker can execute a denial of service attack on the DNS server(s)
+
+
+
+Aboba, Thaler & Esibov       Standards Track                   [Page 23]
+
+
+
+
+
+INTERNET-DRAFT                    LLMNR                   29 August 2005
+
+
+   and then poison the LLMNR cache by responding to an LLMNR query with
+   incorrect information.  As noted in "Threat Analysis of the Domain
+   Name System (DNS)" [RFC3833] these threats also exist with DNS, since
+   DNS response spoofing tools are available that can allow an attacker
+   to respond to a query more quickly than a distant DNS server.
+   However, while switched networks or link layer security may make it
+   difficult for an on-link attacker to snoop unicast DNS queries,
+   multicast LLMNR queries are propagated to all hosts on the link,
+   making it possible for an on-link attacker to spoof LLMNR responses
+   without having to guess the value of the ID field in the query.
+
+   Since LLMNR queries are sent and responded to on the local-link, an
+   attacker will need to respond more quickly to provide its own
+   response prior to arrival of the response from a legitimate
+   responder.   If an LLMNR query is sent for an off-link host, spoofing
+   a response in a timely way is not difficult, since a legitimate
+   response will never be received.
+
+   Limiting the situations in which LLMNR queries are sent, as described
+   in Section 2, is the best protection against these attacks.  If LLMNR
+   is given higher priority than DNS among the enabled name resolution
+   mechanisms, a denial of service attack on the DNS server would not be
+   necessary in order to poison the LLMNR cache, since LLMNR queries
+   would be sent even when the DNS server is available.  In addition,
+   the LLMNR cache, once poisoned, would take precedence over the DNS
+   cache, eliminating the benefits of cache separation.  As a result,
+   LLMNR is only used as a name resolution mechanism of last resort.
+
+5.3.  Authentication
+
+   LLMNR is a peer-to-peer name resolution protocol, and as a result,
+   it is often deployed in situations where no trust model can be
+   assumed.  This makes it difficult to apply existing DNS security
+   mechanisms to LLMNR.
+
+   LLMNR does not support "delegated trust" (CD or AD bits).  As a
+   result, unless LLMNR senders are DNSSEC aware, it is not feasible to
+   use DNSSEC [RFC4033] with LLMNR.
+
+   If authentication is desired, and a pre-arranged security
+   configuration is possible, then the following security mechanisms may
+   be used:
+
+[a]  LLMNR implementations MAY support TSIG [RFC2845] and/or SIG(0)
+     [RFC2931] security mechanisms. "DNS Name Service based on Secure
+     Multicast DNS for IPv6 Mobile Ad Hoc Networks" [LLMNRSec] describes
+     the use of TSIG to secure LLMNR responses, based on group keys.
+
+
+
+
+Aboba, Thaler & Esibov       Standards Track                   [Page 24]
+
+
+
+
+
+INTERNET-DRAFT                    LLMNR                   29 August 2005
+
+
+[b]  IPsec ESP with a null-transform MAY be used to authenticate unicast
+     LLMNR queries and responses or LLMNR responses to multicast
+     queries.  In a small network without a certificate authority, this
+     can be most easily accomplished through configuration of a group
+     pre-shared key for trusted hosts.
+
+   Where these mechanisms cannot be supported, responses to LLMNR
+   queries may be unauthenticated.
+
+5.4.  Cache and Port Separation
+
+   In order to prevent responses to LLMNR queries from polluting the DNS
+   cache, LLMNR implementations MUST use a distinct, isolated cache for
+   LLMNR on each interface.  The use of separate caches is most
+   effective when LLMNR is used as a name resolution mechanism of last
+   resort, since this minimizes the opportunities for poisoning the
+   LLMNR cache, and decreases reliance on it.
+
+   LLMNR operates on a separate port from DNS, reducing the likelihood
+   that a DNS server will unintentionally respond to an LLMNR query.
+
+6.  IANA Considerations
+
+   This specification creates one new name space:  the reserved bits in
+   the LLMNR header.  These are allocated by IETF Consensus, in
+   accordance with BCP 26 [RFC2434].
+
+   LLMNR requires allocation of port 5355 for both TCP and UDP.
+
+   LLMNR requires allocation of link-scope multicast IPv4 address
+   224.0.0.252, as well as link-scope multicast IPv6 address
+   FF02:0:0:0:0:0:1:3.
+
+7.  Constants
+
+   The following timing constants are used in this protocol; they are
+   not intended to be user configurable.
+
+      JITTER_INTERVAL      100 ms
+      LLMNR_TIMEOUT        1 second (if set statically on all interfaces)
+                           100 ms (IEEE 802 media, including IEEE 802.11)
+
+8.  References
+
+8.1.  Normative References
+
+[RFC1035] Mockapetris, P., "Domain Names - Implementation and
+          Specification", RFC 1035, November 1987.
+
+
+
+Aboba, Thaler & Esibov       Standards Track                   [Page 25]
+
+
+
+
+
+INTERNET-DRAFT                    LLMNR                   29 August 2005
+
+
+[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+          Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
+          Specification", RFC 2181, July 1997.
+
+[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)",
+          RFC 2308, March 1998.
+
+[RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing
+          Architecture", RFC 2373, July 1998.
+
+[RFC2434] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA
+          Considerations Section in RFCs", BCP 26, RFC 2434, October
+          1998.
+
+[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671,
+          August 1999.
+
+[RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington,
+          "Secret Key Transaction Authentication for DNS (TSIG)", RFC
+          2845, May 2000.
+
+[RFC2931] Eastlake, D., "DNS Request and Transaction Signatures
+          (SIG(0)s)", RFC 2931, September 2000.
+
+8.2.  Informative References
+
+[Bonjour] Cheshire, S. and M. Krochmal, "Multicast DNS", Internet draft
+          (work in progress), draft-cheshire-dnsext-multicastdns-05.txt,
+          June 2005.
+
+[DNSPerf] Jung, J., et al., "DNS Performance and the Effectiveness of
+          Caching", IEEE/ACM Transactions on Networking, Volume 10,
+          Number 5, pp. 589, October 2002.
+
+[DNSDisc] Durand, A., Hagino, I. and D. Thaler, "Well known site local
+          unicast addresses to communicate with recursive DNS servers",
+          Internet draft (work in progress), draft-ietf-ipv6-dns-
+          discovery-07.txt, October 2002.
+
+[IEEE-802.11i]
+          Institute of Electrical and Electronics Engineers, "Supplement
+          to Standard for Telecommunications and Information Exchange
+          Between Systems - LAN/MAN Specific Requirements - Part 11:
+          Wireless LAN Medium Access Control (MAC) and Physical Layer
+          (PHY) Specifications: Specification for Enhanced Security",
+          IEEE 802.11i, July 2004.
+
+
+
+Aboba, Thaler & Esibov       Standards Track                   [Page 26]
+
+
+
+
+
+INTERNET-DRAFT                    LLMNR                   29 August 2005
+
+
+[LLMNREnable]
+          Guttman, E., "DHCP LLMNR Enable Option", Internet draft (work
+          in progress), draft-guttman-mdns-enable-02.txt, April 2002.
+
+[LLMNRSec]
+          Jeong, J., Park, J. and H. Kim, "DNS Name Service based on
+          Secure Multicast DNS for IPv6 Mobile Ad Hoc Networks", ICACT
+          2004, Phoenix Park, Korea, February 9-11, 2004.
+
+[POSIX]   IEEE Std. 1003.1-2001 Standard for Information Technology --
+          Portable Operating System Interface (POSIX). Open Group
+          Technical Standard: Base Specifications, Issue 6, December
+          2001.  ISO/IEC 9945:2002.  http://www.opengroup.org/austin
+
+[RFC1536] Kumar, A., et. al., "DNS Implementation Errors and Suggested
+          Fixes", RFC 1536, October 1993.
+
+[RFC1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness
+          Recommendations for Security", RFC 1750, December 1994.
+
+[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
+          March 1997.
+
+[RFC2292] Stevens, W. and M. Thomas, "Advanced Sockets API for IPv6",
+          RFC 2292, February 1998.
+
+[RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC
+          2365, July 1998.
+
+[RFC2553] Gilligan, R., Thomson, S., Bound, J. and W. Stevens, "Basic
+          Socket Interface Extensions for IPv6", RFC 2553, March 1999.
+
+[RFC2937] Smith, C., "The Name Service Search Option for DHCP", RFC
+          2937, September 2000.
+
+[RFC3315] Droms, R., et al., "Dynamic Host Configuration Protocol for
+          IPv6 (DHCPv6)", RFC 3315, July 2003.
+
+[RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name
+          System (DNS)", RFC 3833, August 2004.
+
+[RFC3927] Cheshire, S., Aboba, B. and E. Guttman, "Dynamic Configuration
+          of Link-Local IPv4 Addresses", RFC 3927, October 2004.
+
+[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose,
+          "DNS Security Introduction and Requirement", RFC 4033, March
+          2005.
+
+
+
+
+Aboba, Thaler & Esibov       Standards Track                   [Page 27]
+
+
+
+
+
+INTERNET-DRAFT                    LLMNR                   29 August 2005
+
+
+Acknowledgments
+
+   This work builds upon original work done on multicast DNS by Bill
+   Manning and Bill Woodcock.  Bill Manning's work was funded under
+   DARPA grant #F30602-99-1-0523.  The authors gratefully acknowledge
+   their contribution to the current specification.  Constructive input
+   has also been received from Mark Andrews, Rob Austein, Randy Bush,
+   Stuart Cheshire, Ralph Droms, Robert Elz, James Gilroy, Olafur
+   Gudmundsson, Andreas Gustafsson, Erik Guttman, Myron Hattig,
+   Christian Huitema, Olaf Kolkman, Mika Liljeberg, Keith Moore,
+   Tomohide Nagashima, Thomas Narten, Erik Nordmark, Markku Savela, Mike
+   St. Johns, Sander Van-Valkenburg, and Brian Zill.
+
+Authors' Addresses
+
+   Bernard Aboba
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA 98052
+
+   Phone: +1 425 706 6605
+   EMail: bernarda@microsoft.com
+
+   Dave Thaler
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA 98052
+
+   Phone: +1 425 703 8835
+   EMail: dthaler@microsoft.com
+
+   Levon Esibov
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA 98052
+
+   EMail: levone@microsoft.com
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+
+
+Aboba, Thaler & Esibov       Standards Track                   [Page 28]
+
+
+
+
+
+INTERNET-DRAFT                    LLMNR                   29 August 2005
+
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at ietf-
+   ipr@ietf.org.
+
+Disclaimer of Validity
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2005).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+Open Issues
+
+   Open issues with this specification are tracked on the following web
+   site:
+
+   http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html
+
+
+
+
+
+
+
+
+
+
+
+Aboba, Thaler & Esibov       Standards Track                   [Page 29]
+
+
diff --git a/doc/draft/draft-ietf-dnsext-nsec3-04.txt b/doc/draft/draft-ietf-dnsext-nsec3-04.txt
new file mode 100644
index 0000000..8c6c5b1
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsext-nsec3-04.txt
@@ -0,0 +1,2352 @@
+
+
+
+Network Working Group                                          B. Laurie
+Internet-Draft                                                 G. Sisson
+Expires: August 5, 2006                                        R. Arends
+                                                                 Nominet
+                                                           February 2006
+
+
+             DNSSEC Hash Authenticated Denial of Existence
+                       draft-ietf-dnsext-nsec3-04
+
+Status of this Memo
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   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 draft documents 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 "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/ietf/1id-abstracts.txt.
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+   This Internet-Draft will expire on August 5, 2006.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   The DNS Security Extensions introduces the NSEC resource record for
+   authenticated denial of existence.  This document introduces a new
+   resource record as an alternative to NSEC that provides measures
+   against zone enumeration and allows for gradual expansion of
+   delegation-centric zones.
+
+
+
+
+
+Laurie, et al.           Expires August 5, 2006                 [Page 1]
+
+Internet-Draft                    nsec3                    February 2006
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
+     1.1.  Rationale  . . . . . . . . . . . . . . . . . . . . . . . .  4
+     1.2.  Reserved Words . . . . . . . . . . . . . . . . . . . . . .  4
+     1.3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  4
+   2.  NSEC versus NSEC3  . . . . . . . . . . . . . . . . . . . . . .  5
+   3.  The NSEC3 Resource Record  . . . . . . . . . . . . . . . . . .  5
+     3.1.  NSEC3 RDATA Wire Format  . . . . . . . . . . . . . . . . .  6
+       3.1.1.  The Hash Function Field  . . . . . . . . . . . . . . .  6
+       3.1.2.  The Opt-In Flag Field  . . . . . . . . . . . . . . . .  7
+       3.1.3.  The Iterations Field . . . . . . . . . . . . . . . . .  8
+       3.1.4.  The Salt Length Field  . . . . . . . . . . . . . . . .  8
+       3.1.5.  The Salt Field . . . . . . . . . . . . . . . . . . . .  8
+       3.1.6.  The Next Hashed Ownername Field  . . . . . . . . . . .  9
+       3.1.7.  The Type Bit Maps Field  . . . . . . . . . . . . . . .  9
+     3.2.  The NSEC3 RR Presentation Format . . . . . . . . . . . . . 10
+   4.  Creating Additional NSEC3 RRs for Empty Non-Terminals  . . . . 11
+   5.  Calculation of the Hash  . . . . . . . . . . . . . . . . . . . 11
+   6.  Including NSEC3 RRs in a Zone  . . . . . . . . . . . . . . . . 11
+   7.  Responding to NSEC3 Queries  . . . . . . . . . . . . . . . . . 12
+   8.  Special Considerations . . . . . . . . . . . . . . . . . . . . 13
+     8.1.  Proving Nonexistence . . . . . . . . . . . . . . . . . . . 13
+     8.2.  Salting  . . . . . . . . . . . . . . . . . . . . . . . . . 14
+     8.3.  Iterations . . . . . . . . . . . . . . . . . . . . . . . . 15
+     8.4.  Hash Collision . . . . . . . . . . . . . . . . . . . . . . 16
+       8.4.1.  Avoiding Hash Collisions during generation . . . . . . 16
+       8.4.2.  Second Preimage Requirement Analysis . . . . . . . . . 16
+       8.4.3.  Possible Hash Value Truncation Method  . . . . . . . . 17
+       8.4.4.  Server Response to a Run-time Collision  . . . . . . . 17
+       8.4.5.  Parameters that Cover the Zone . . . . . . . . . . . . 18
+   9.  Performance Considerations . . . . . . . . . . . . . . . . . . 18
+   10. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 18
+   11. Security Considerations  . . . . . . . . . . . . . . . . . . . 18
+   12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
+     12.1. Normative References . . . . . . . . . . . . . . . . . . . 21
+     12.2. Informative References . . . . . . . . . . . . . . . . . . 22
+   Editorial Comments . . . . . . . . . . . . . . . . . . . . . . . .
+   Appendix A.  Example Zone  . . . . . . . . . . . . . . . . . . . . 22
+   Appendix B.  Example Responses . . . . . . . . . . . . . . . . . . 27
+     B.1.  answer . . . . . . . . . . . . . . . . . . . . . . . . . . 27
+       B.1.1.  Authenticating the Example DNSKEY RRset  . . . . . . . 29
+     B.2.  Name Error . . . . . . . . . . . . . . . . . . . . . . . . 30
+     B.3.  No Data Error  . . . . . . . . . . . . . . . . . . . . . . 32
+       B.3.1.  No Data Error, Empty Non-Terminal  . . . . . . . . . . 33
+     B.4.  Referral to Signed Zone  . . . . . . . . . . . . . . . . . 34
+     B.5.  Referral to Unsigned Zone using the Opt-In Flag  . . . . . 35
+     B.6.  Wildcard Expansion . . . . . . . . . . . . . . . . . . . . 36
+
+
+
+Laurie, et al.           Expires August 5, 2006                 [Page 2]
+
+Internet-Draft                    nsec3                    February 2006
+
+
+     B.7.  Wildcard No Data Error . . . . . . . . . . . . . . . . . . 38
+     B.8.  DS Child Zone No Data Error  . . . . . . . . . . . . . . . 39
+   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41
+   Intellectual Property and Copyright Statements . . . . . . . . . . 42
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Laurie, et al.           Expires August 5, 2006                 [Page 3]
+
+Internet-Draft                    nsec3                    February 2006
+
+
+1.  Introduction
+
+1.1.  Rationale
+
+   The DNS Security Extensions included the NSEC RR to provide
+   authenticated denial of existence.  Though the NSEC RR meets the
+   requirements for authenticated denial of existence, it introduced a
+   side-effect in that the contents of a zone can be enumerated.  This
+   property introduces undesired policy issues.
+
+   An enumerated zone can be used either directly as a source of
+   probable e-mail addresses for spam, or indirectly as a key for
+   multiple WHOIS queries to reveal registrant data which many
+   registries may be under strict legal obligations to protect.  Many
+   registries therefore prohibit copying of their zone file; however the
+   use of NSEC RRs renders these policies unenforceable.
+
+   A second problem was the requirement that the existence of all record
+   types in a zone - including unsigned delegation points - must be
+   accounted for, despite the fact that unsigned delegation point
+   records are not signed.  This requirement has a side-effect that the
+   overhead of signed zones is not related to the increase in security
+   of subzones.  This requirement does not allow the zones' size to grow
+   in relation to the growth of signed subzones.
+
+   In the past, solutions (draft-ietf-dnsext-dnssec-opt-in) have been
+   proposed as a measure against these side effects but at the time were
+   regarded as secondary over the need to have a stable DNSSEC
+   specification.  With (draft-vixie-dnssec-ter) [14] a graceful
+   transition path to future enhancements is introduced, while current
+   DNSSEC deployment can continue.  This document presents the NSEC3
+   Resource Record which mitigates these issues with the NSEC RR.
+
+   The reader is assumed to be familiar with the basic DNS and DNSSEC
+   concepts described in RFC 1034 [1], RFC 1035 [2], RFC 4033 [3], RFC
+   4034 [4], RFC 4035 [5] and subsequent RFCs that update them: RFC 2136
+   [6], RFC2181 [7] and RFC2308 [8].
+
+1.2.  Reserved Words
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [9].
+
+1.3.  Terminology
+
+   The practice of discovering the contents of a zone, i.e. enumerating
+   the domains within a zone, is known as "zone enumeration".  Zone
+
+
+
+Laurie, et al.           Expires August 5, 2006                 [Page 4]
+
+Internet-Draft                    nsec3                    February 2006
+
+
+   enumeration was not practical prior to the introduction of DNSSEC.
+
+   In this document the term "original ownername" refers to a standard
+   ownername.  Because this proposal uses the result of a hash function
+   over the original (unmodified) ownername, this result is referred to
+   as "hashed ownername".
+
+   "Hash order" means the order in which hashed ownernames are arranged
+   according to their numerical value, treating the leftmost (lowest
+   numbered) octet as the most significant octet.  Note that this is the
+   same as the canonical ordering specified in RFC 4034 [4].
+
+   An "empty non-terminal" is a domain name that owns no resource
+   records but has subdomains that do.
+
+   The "closest encloser" of a (nonexistent) domain name is the longest
+   domain name, including empty non-terminals, that matches the
+   rightmost part of the nonexistent domain name.
+
+   "Base32 encoding" is "Base 32 Encoding with Extended Hex Alphabet" as
+   specified in RFC 3548bis [15].
+
+
+2.  NSEC versus NSEC3
+
+   This document does NOT obsolete the NSEC record, but gives an
+   alternative for authenticated denial of existence.  NSEC and NSEC3
+   RRs can not co-exist in a zone.  See draft-vixie-dnssec-ter [14] for
+   a signaling mechanism to allow for graceful transition towards NSEC3.
+
+
+3.  The NSEC3 Resource Record
+
+   The NSEC3 RR provides Authenticated Denial of Existence for DNS
+   Resource Record Sets.
+
+   The NSEC3 Resource Record (RR) lists RR types present at the NSEC3
+   RR's original ownername.  It includes the next hashed ownername in
+   the hash order of the zone.  The complete set of NSEC3 RRs in a zone
+   indicates which RRsets exist for the original ownername of the RRset
+   and form a chain of hashed ownernames in the zone.  This information
+   is used to provide authenticated denial of existence for DNS data, as
+   described in RFC 4035 [5].  To provide protection against zone
+   enumeration, the ownernames used in the NSEC3 RR are cryptographic
+   hashes of the original ownername prepended to the name of the zone.
+   The NSEC3 RR indicates which hash function is used to construct the
+   hash, which salt is used, and how many iterations of the hash
+   function are performed over the original ownername.  The hashing
+
+
+
+Laurie, et al.           Expires August 5, 2006                 [Page 5]
+
+Internet-Draft                    nsec3                    February 2006
+
+
+   technique is described fully in Section 5.
+
+   Hashed ownernames of unsigned delegations may be excluded from the
+   chain.  An NSEC3 record which span covers the hash of an unsigned
+   delegation's ownername is referred to as an Opt-In NSEC3 record and
+   is indicated by the presence of a flag.
+
+   The ownername for the NSEC3 RR is the base32 encoding of the hashed
+   ownername prepended to the name of the zone..
+
+   The type value for the NSEC3 RR is XX.
+
+   The NSEC3 RR RDATA format is class independent and is described
+   below.
+
+   The class MUST be the same as the original ownername's class.
+
+   The NSEC3 RR SHOULD have the same TTL value as the SOA minimum TTL
+   field.  This is in the spirit of negative caching [8].
+
+3.1.  NSEC3 RDATA Wire Format
+
+   The RDATA of the NSEC3 RR is as shown below:
+
+                        1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   | Hash Function |O|                Iterations                   |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |  Salt Length  |                     Salt                      /
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   /                     Next Hashed Ownername                     /
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   /                         Type Bit Maps                         /
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   "O" is the Opt-In Flag field.
+
+3.1.1.  The Hash Function Field
+
+   The Hash Function field identifies the cryptographic hash function
+   used to construct the hash-value.
+
+   The values are as defined for the DS record (see RFC 3658 [10]).
+
+   On reception, a resolver MUST ignore an NSEC3 RR with an unknown hash
+   function value.
+
+
+
+
+Laurie, et al.           Expires August 5, 2006                 [Page 6]
+
+Internet-Draft                    nsec3                    February 2006
+
+
+3.1.2.  The Opt-In Flag Field
+
+   The Opt-In Flag field indicates whether this NSEC3 RR covers unsigned
+   delegations.
+
+   In DNSSEC, NS RRsets at delegation points are not signed, and may be
+   accompanied by a DS record.  The security status of the subzone is
+   determined by the presence or absence of the DS RRset,
+   cryptographically proven by the NSEC record or the signed DS RRset.
+   The presence of the Opt-In flag expands this definition by allowing
+   insecure delegations to exist within an otherwise signed zone without
+   the corresponding NSEC3 record at the delegation's (hashed) owner
+   name.  These delegations are proven insecure by using a covering
+   NSEC3 record.
+
+   Resolvers must be able to distinguish between NSEC3 records and
+   Opt-In NSEC3 records.  This is accomplished by setting the Opt-In
+   flag of the NSEC3 records that cover (or potentially cover) insecure
+   delegation nodes.
+
+   An Opt-In NSEC3 record does not assert the existence or non-existence
+   of the insecure delegations that it covers.  This allows for the
+   addition or removal of these delegations without recalculating or
+   resigning records in the NSEC3 chain.  However, Opt-In NSEC3 records
+   do assert the (non)existence of other, authoritative RRsets.
+
+   An Opt-In NSEC3 record MAY have the same original owner name as an
+   insecure delegation.  In this case, the delegation is proven insecure
+   by the lack of a DS bit in type map and the signed NSEC3 record does
+   assert the existence of the delegation.
+
+   Zones using Opt-In MAY contain a mixture of Opt-In NSEC3 records and
+   non-Opt-In NSEC3 records.  If an NSEC3 record is not Opt-In, there
+   MUST NOT be any hashed ownernames of insecure delegations (nor any
+   other records) between it and the RRsets indicated by the 'Next
+   Hashed Ownername' in the NSEC3 RDATA.  If it is Opt-In, there MUST
+   only be hashed ownernames of insecure delegations between it and the
+   next node indicated by the 'Next Hashed Ownername' in the NSEC3
+   RDATA.
+
+   In summary,
+   o  An Opt-In NSEC3 type is identified by an Opt-In Flag field value
+      of 1.
+   o  A non Opt-In NSEC3 type is identified by an Opt-In Flag field
+      value of 0.
+   and,
+
+
+
+
+
+Laurie, et al.           Expires August 5, 2006                 [Page 7]
+
+Internet-Draft                    nsec3                    February 2006
+
+
+   o  An Opt-In NSEC3 record does not assert the non-existence of a hash
+      ownername between its ownername and next hashed ownername,
+      although it does assert that any hashed name in this span MUST be
+      of an insecure delegation.
+   o  An Opt-In NSEC3 record does assert the (non)existence of RRsets
+      with the same hashed owner name.
+
+3.1.3.  The Iterations Field
+
+   The Iterations field defines the number of times the hash has been
+   iterated.  More iterations results in greater resiliency of the hash
+   value against dictionary attacks, but at a higher cost for both the
+   server and resolver.  See Section 5 for details of this field's use.
+
+   Iterations make an attack more costly by making the hash computation
+   more computationally intensive, e.g. by iterating the hash function a
+   number of times.
+
+   When generating a few hashes this performance loss will not be a
+   problem, as a validator can handle a delay of a few milliseconds.
+   But when doing a dictionary attack it will also multiply the attack
+   workload by a factor, which is a problem for the attacker.
+
+3.1.4.  The Salt Length Field
+
+   The salt length field defines the length of the salt in octets.
+
+3.1.5.  The Salt Field
+
+   The Salt field is not present when the Salt Length Field has a value
+   of 0.
+
+   The Salt field is appended to the original ownername before hashing
+   in order to defend against precalculated dictionary attacks.  See
+   Section 5 for details on how the salt is used.
+
+   Salt is used to make dictionary attacks using precomputation more
+   costly.  A dictionary can only be computed after the attacker has the
+   salt, hence a new salt means that the dictionary has to be
+   regenerated with the new salt.
+
+   There MUST be a complete set of NSEC3 records covering the entire
+   zone that use the same salt value.  The requirement exists so that,
+   given any qname within a zone, at least one covering NSEC3 RRset may
+   be found.  While it may be theoretically possible to produce a set of
+   NSEC3s that use different salts that cover the entire zone, it is
+   computationally infeasible to generate such a set.  See Section 8.2
+   for further discussion.
+
+
+
+Laurie, et al.           Expires August 5, 2006                 [Page 8]
+
+Internet-Draft                    nsec3                    February 2006
+
+
+   The salt value SHOULD be changed from time to time - this is to
+   prevent the use of a precomputed dictionary to reduce the cost of
+   enumeration.
+
+3.1.6.  The Next Hashed Ownername Field
+
+   The Next Hashed Ownername field contains the next hashed ownername in
+   hash order.  That is, given the set of all hashed owernames, the Next
+   Hashed Ownername contains the hash value that immediately follows the
+   owner hash value for the given NSEC3 record.  The value of the Next
+   Hashed Ownername Field in the last NSEC3 record in the zone is the
+   same as the ownername of the first NSEC3 RR in the zone in hash
+   order.
+
+   Hashed ownernames of glue RRsets MUST NOT be listed in the Next
+   Hashed Ownername unless at least one authoritative RRset exists at
+   the same ownername.  Hashed ownernames of delegation NS RRsets MUST
+   be listed if the Opt-In bit is clear.
+
+   Note that the Next Hashed Ownername field is not encoded, unlike the
+   NSEC3 RR's ownername.  It is the unmodified binary hash value.  It
+   does not include the name of the containing zone.
+
+   The length of this field is the length of the hash value produced by
+   the hash function selected by the Hash Function field.
+
+3.1.7.  The Type Bit Maps Field
+
+   The Type Bit Maps field identifies the RRset types which exist at the
+   NSEC3 RR's original ownername.
+
+   The Type bits for the NSEC3 RR and RRSIG RR MUST be set during
+   generation, and MUST be ignored during processing.
+
+   The RR type space is split into 256 window blocks, each representing
+   the low-order 8 bits of the 16-bit RR type space.  Each block that
+   has at least one active RR type is encoded using a single octet
+   window number (from 0 to 255), a single octet bitmap length (from 1
+   to 32) indicating the number of octets used for the window block's
+   bitmap, and up to 32 octets (256 bits) of bitmap.
+
+   Blocks are present in the NSEC3 RR RDATA in increasing numerical
+   order.
+
+   "|" denotes concatenation
+
+   Type Bit Map(s) Field = ( Window Block # | Bitmap Length | Bitmap ) +
+
+
+
+
+Laurie, et al.           Expires August 5, 2006                 [Page 9]
+
+Internet-Draft                    nsec3                    February 2006
+
+
+   Each bitmap encodes the low-order 8 bits of RR types within the
+   window block, in network bit order.  The first bit is bit 0.  For
+   window block 0, bit 1 corresponds to RR type 1 (A), bit 2 corresponds
+   to RR type 2 (NS), and so forth.  For window block 1, bit 1
+   corresponds to RR type 257, bit 2 to RR type 258.  If a bit is set to
+   1, it indicates that an RRset of that type is present for the NSEC3
+   RR's ownername.  If a bit is set to 0, it indicates that no RRset of
+   that type is present for the NSEC3 RR's ownername.
+
+   Since bit 0 in window block 0 refers to the non-existing RR type 0,
+   it MUST be set to 0.  After verification, the validator MUST ignore
+   the value of bit 0 in window block 0.
+
+   Bits representing Meta-TYPEs or QTYPEs as specified in RFC 2929 [11]
+   (section 3.1) or within the range reserved for assignment only to
+   QTYPEs and Meta-TYPEs MUST be set to 0, since they do not appear in
+   zone data.  If encountered, they must be ignored upon reading.
+
+   Blocks with no types present MUST NOT be included.  Trailing zero
+   octets in the bitmap MUST be omitted.  The length of each block's
+   bitmap is determined by the type code with the largest numerical
+   value, within that block, among the set of RR types present at the
+   NSEC3 RR's actual ownername.  Trailing zero octets not specified MUST
+   be interpreted as zero octets.
+
+3.2.  The NSEC3 RR Presentation Format
+
+   The presentation format of the RDATA portion is as follows:
+
+   The Opt-In Flag Field is represented as an unsigned decimal integer.
+   The value is either 0 or 1.
+
+   The Hash field is presented as a mnemonic of the hash or as an
+   unsigned decimal integer.  The value has a maximum of 127.
+
+   The Iterations field is presented as an unsigned decimal integer.
+
+   The Salt Length field is not presented.
+
+   The Salt field is represented as a sequence of case-insensitive
+   hexadecimal digits.  Whitespace is not allowed within the sequence.
+   The Salt Field is represented as "-" (without the quotes) when the
+   Salt Length field has value 0.
+
+   The Next Hashed Ownername field is represented as a sequence of case-
+   insensitive base32 digits, without whitespace.
+
+   The Type Bit Maps Field is represented as a sequence of RR type
+
+
+
+Laurie, et al.           Expires August 5, 2006                [Page 10]
+
+Internet-Draft                    nsec3                    February 2006
+
+
+   mnemonics.  When the mnemonic is not known, the TYPE representation
+   as described in RFC 3597 [12] (section 5) MUST be used.
+
+
+4.  Creating Additional NSEC3 RRs for Empty Non-Terminals
+
+   In order to prove the non-existence of a record that might be covered
+   by a wildcard, it is necessary to prove the existence of its closest
+   encloser.  A closest encloser might be an empty non-terminal.
+
+   Additional NSEC3 RRs are generated for empty non-terminals.  These
+   additional NSEC3 RRs are identical in format to NSEC3 RRs that cover
+   existing RRs in the zone except that their type-maps only indicated
+   the existence of an NSEC3 RRset and an RRSIG RRset.
+
+   This relaxes the requirement in Section 2.3 of RFC4035 that NSEC RRs
+   not appear at names that did not exist before the zone was signed.
+   [Comment.1]
+
+
+5.  Calculation of the Hash
+
+   Define H(x) to be the hash of x using the hash function selected by
+   the NSEC3 record and || to indicate concatenation.  Then define:
+
+   IH(salt,x,0)=H(x || salt)
+
+   IH(salt,x,k)=H(IH(salt,x,k-1) || salt) if k > 0
+
+   Then the calculated hash of an ownername is
+   IH(salt,ownername,iterations-1), where the ownername is the canonical
+   form.
+
+   The canonical form of the ownername is the wire format of the
+   ownername where:
+   1.  The ownername is fully expanded (no DNS name compression) and
+       fully qualified;
+   2.  All uppercase US-ASCII letters are replaced by the corresponding
+       lowercase US-ASCII letters;
+   3.  If the ownername is a wildcard name, the ownername is in its
+       original unexpanded form, including the "*" label (no wildcard
+       substitution);
+   This form is as defined in section 6.2 of RFC 4034 ([4]).
+
+
+6.  Including NSEC3 RRs in a Zone
+
+   Each ownername within the zone that owns authoritative RRsets MUST
+
+
+
+Laurie, et al.           Expires August 5, 2006                [Page 11]
+
+Internet-Draft                    nsec3                    February 2006
+
+
+   have a corresponding NSEC3 RR.  Ownernames that correspond to
+   unsigned delegations MAY have a corresponding NSEC3 RR, however, if
+   there is not, there MUST be a covering NSEC3 RR with the Opt-In flag
+   set to 1.  Other non-authoritative RRs are not included in the set of
+   NSEC3 RRs.
+
+   Each empty non-terminal MUST have an NSEC3 record.
+
+   The TTL value for any NSEC3 RR SHOULD be the same as the minimum TTL
+   value field in the zone SOA RR.
+
+   The type bitmap of every NSEC3 resource record in a signed zone MUST
+   indicate the presence of both the NSEC3 RR type itself and its
+   corresponding RRSIG RR type.
+
+   The following steps describe the proper construction of NSEC3
+   records.  [Comment.2]
+   1.  For each unique original ownername in the zone, add an NSEC3
+       RRset.  If Opt-In is being used, ownernames of unsigned
+       delegations may be excluded, but must be considered for empty-
+       non-terminals.  The ownername of the NSEC3 RR is the hashed
+       equivalent of the original owner name, prepended to the zone
+       name.  The Next Hashed Ownername field is left blank for the
+       moment.  If Opt-In is being used, set the Opt-In bit to one.
+   2.  For each RRset at the original owner name, set the corresponding
+       bit in the type bit map.
+   3.  If the difference in number of labels between the apex and the
+       original ownername is greater then 1, additional NSEC3s need to
+       be added for every empty non-terminal between the apex and the
+       original ownername.  This process may generate NSEC3 RRs with
+       duplicate hashed ownernames.
+   4.  Sort the set of NSEC3 RRs into hash order.  Hash order is the
+       ascending numerical order of the non-encoded hash values.
+   5.  Combine NSEC3 RRs with identical hashed ownernames by replacing
+       with a single NSEC3 RR with the type map consisting of the union
+       of the types represented by the set of NSEC3 RRs.
+   6.  In each NSEC3 RR, insert the Next Hashed Ownername by using the
+       value of the next NSEC3 RR in hash order.  The Next Hashed
+       Ownername of the last NSEC3 in the zone contains the value of the
+       hashed ownername of the first NSEC3 in the hash order.
+
+
+7.  Responding to NSEC3 Queries
+
+   Since NSEC3 ownernames are not represented in the NSEC3 chain like
+   other zone ownernames, direct queries for NSEC3 ownernames present a
+   special case.
+
+
+
+
+Laurie, et al.           Expires August 5, 2006                [Page 12]
+
+Internet-Draft                    nsec3                    February 2006
+
+
+   The special case arises when the following are all true:
+   o  The QNAME equals an existing NSEC3 ownername, and
+   o  There are no other record types that exist at QNAME, and
+   o  The QTYPE does not equal NSEC3.
+   These conditions describe a particular case: the answer should be a
+   NOERROR/NODATA response, but there is no NSEC3 RRset for H(QNAME) to
+   include in the authority section.
+
+   However, the NSEC3 RRset with ownername equal to QNAME is able to
+   prove its own existence.  Thus, when answering this query, the
+   authoritative server MUST include the NSEC3 RRset whose ownername
+   equals QNAME.  This RRset proves that QNAME is an existing name with
+   types NSEC3 and RRSIG.  The authoritative server MUST also include
+   the NSEC3 RRset that covers the hash of QNAME.  This RRset proves
+   that no other types exist.
+
+   When validating a NOERROR/NODATA response, validators MUST check for
+   a NSEC3 RRset with ownername equals to QNAME, and MUST accept that
+   (validated) NSEC3 RRset as proof that QNAME exists.  The validator
+   MUST also check for an NSEC3 RRset that covers the hash of QNAME as
+   proof that QTYPE doesn't exist.
+
+   Other cases where the QNAME equals an existing NSEC3 ownername may be
+   answered normally.
+
+
+8.  Special Considerations
+
+   The following paragraphs clarify specific behaviour explain special
+   considerations for implementations.
+
+8.1.  Proving Nonexistence
+
+   If a wildcard resource record appears in a zone, its asterisk label
+   is treated as a literal symbol and is treated in the same way as any
+   other ownername for purposes of generating NSEC3 RRs.  RFC 4035 [5]
+   describes the impact of wildcards on authenticated denial of
+   existence.
+
+   In order to prove there exist no RRs for a domain, as well as no
+   source of synthesis, an RR must be shown for the closest encloser,
+   and non-existence must be shown for all closer labels and for the
+   wildcard at the closest encloser.
+
+   This can be done as follows.  If the QNAME in the query is
+   omega.alfa.beta.example, and the closest encloser is beta.example
+   (the nearest ancestor to omega.alfa.beta.example), then the server
+   should return an NSEC3 that demonstrates the nonexistence of
+
+
+
+Laurie, et al.           Expires August 5, 2006                [Page 13]
+
+Internet-Draft                    nsec3                    February 2006
+
+
+   alfa.beta.example, an NSEC3 that demonstrates the nonexistence of
+   *.beta.example, and an NSEC3 that demonstrates the existence of
+   beta.example.  This takes between one and three NSEC3 records, since
+   a single record can, by chance, prove more than one of these facts.
+
+   When a verifier checks this response, then the existence of
+   beta.example together with the non-existence of alfa.beta.example
+   proves that the closest encloser is indeed beta.example.  The non-
+   existence of *.beta.example shows that there is no wildcard at the
+   closest encloser, and so no source of synthesis for
+   omega.alfa.beta.example.  These two facts are sufficient to satisfy
+   the resolver that the QNAME cannot be resolved.
+
+   In practice, since the NSEC3 owner and next names are hashed, if the
+   server responds with an NSEC3 for beta.example, the resolver will
+   have to try successively longer names, starting with example, moving
+   to beta.example, alfa.beta.example, and so on, until one of them
+   hashes to a value that matches the interval (but not the ownername
+   nor next owner name) of one of the returned NSEC3s (this name will be
+   alfa.beta.example).  Once it has done this, it knows the closest
+   encloser (i.e. beta.example), and can then easily check the other two
+   required proofs.
+
+   Note that it is not possible for one of the shorter names tried by
+   the resolver to be denied by one of the returned NSEC3s, since, by
+   definition, all these names exist and so cannot appear within the
+   range covered by an NSEC3.  Note, however, that the first name that
+   the resolver tries MUST be the apex of the zone, since names above
+   the apex could be denied by one of the returned NSEC3s.
+
+8.2.  Salting
+
+   Augmenting original ownernames with salt before hashing increases the
+   cost of a dictionary of pre-generated hash-values.  For every bit of
+   salt, the cost of a precomputed dictionary doubles (because there
+   must be an entry for each word combined with each possible salt
+   value).  The NSEC3 RR can use a maximum of 2040 bits (255 octets) of
+   salt, multiplying the cost by 2^2040.  This means that an attacker
+   must, in practice, recompute the dictionary each time the salt is
+   changed.
+
+   There MUST be at least one complete set of NSEC3s for the zone using
+   the same salt value.
+
+   The salt SHOULD be changed periodically to prevent precomputation
+   using a single salt.  It is RECOMMENDED that the salt be changed for
+   every resigning.
+
+
+
+
+Laurie, et al.           Expires August 5, 2006                [Page 14]
+
+Internet-Draft                    nsec3                    February 2006
+
+
+   Note that this could cause a resolver to see records with different
+   salt values for the same zone.  This is harmless, since each record
+   stands alone (that is, it denies the set of ownernames whose hashes,
+   using the salt in the NSEC3 record, fall between the two hashes in
+   the NSEC3 record) - it is only the server that needs a complete set
+   of NSEC3 records with the same salt in order to be able to answer
+   every possible query.
+
+   There is no prohibition with having NSEC3 with different salts within
+   the same zone.  However, in order for authoritative servers to be
+   able to consistently find covering NSEC3 RRs, the authoritative
+   server MUST choose a single set of parameters (algorithm, salt, and
+   iterations) to use when selecting NSEC3s.  In the absence of any
+   other metadata, the server does this by using the parameters from the
+   zone apex NSEC3, recognizable by the presence of the SOA bit in the
+   type map.  If there is more than one NSEC3 record that meets this
+   description, then the server may arbitrarily choose one.  Because of
+   this, if there is a zone apex NSEC3 RR within a zone, it MUST be part
+   of a complete NSEC3 set.  Conversely, if there exists an incomplete
+   set of NSEC3 RRs using the same parameters within a zone, there MUST
+   NOT be an NSEC3 RR using those parameters with the SOA bit set.
+
+8.3.  Iterations
+
+   Setting the number of iterations used allows the zone owner to choose
+   the cost of computing a hash, and so the cost of generating a
+   dictionary.  Note that this is distinct from the effect of salt,
+   which prevents the use of a single precomputed dictionary for all
+   time.
+
+   Obviously the number of iterations also affects the zone owner's cost
+   of signing the zone as well as the verifiers cost of verifying the
+   zone.  We therefore impose an upper limit on the number of
+   iterations.  We base this on the number of iterations that
+   approximately doubles the cost of signing the zone.
+
+   A zone owner MUST NOT use a value higher than shown in the table
+   below for iterations.  A resolver MAY treat a response with a higher
+   value as bogus.
+
+                       +--------------+------------+
+                       | RSA Key Size | Iterations |
+                       +--------------+------------+
+                       | 1024         | 3,000      |
+                       | 2048         | 20,000     |
+                       | 4096         | 150,000    |
+                       +--------------+------------+
+
+
+
+
+Laurie, et al.           Expires August 5, 2006                [Page 15]
+
+Internet-Draft                    nsec3                    February 2006
+
+
+                       +--------------+------------+
+                       | DSA Key Size | Iterations |
+                       +--------------+------------+
+                       | 1024         | 1,500      |
+                       | 2048         | 5,000      |
+                       +--------------+------------+
+
+   This table is based on 150,000 SHA-1's per second, 50 RSA signs per
+   second for 1024 bit keys, 7 signs per second for 2048 bit keys, 1
+   sign per second for 4096 bit keys, 100 DSA signs per second for 1024
+   bit keys and 30 signs per second for 2048 bit keys.
+
+   Note that since RSA verifications are 10-100 times faster than
+   signatures (depending on key size), in the case of RSA the legal
+   values of iterations can substantially increase the cost of
+   verification.
+
+8.4.  Hash Collision
+
+   Hash collisions occur when different messages have the same hash
+   value.  The expected number of domain names needed to give a 1 in 2
+   chance of a single collision is about 2^(n/2) for a hash of length n
+   bits (i.e. 2^80 for SHA-1).  Though this probability is extremely
+   low, the following paragraphs deal with avoiding collisions and
+   assessing possible damage in the event of an attack using hash
+   collisions.
+
+8.4.1.  Avoiding Hash Collisions during generation
+
+   During generation of NSEC3 RRs, hash values are supposedly unique.
+   In the (academic) case of a collision occurring, an alternative salt
+   MUST be chosen and all hash values MUST be regenerated.
+
+8.4.2.  Second Preimage Requirement Analysis
+
+   A cryptographic hash function has a second-preimage resistance
+   property.  The second-preimage resistance property means that it is
+   computationally infeasible to find another message with the same hash
+   value as a given message, i.e. given preimage X, to find a second
+   preimage X' != X such that hash(X) = hash(X').  The work factor for
+   finding a second preimage is of the order of 2^160 for SHA-1.  To
+   mount an attack using an existing NSEC3 RR, an adversary needs to
+   find a second preimage.
+
+   Assuming an adversary is capable of mounting such an extreme attack,
+   the actual damage is that a response message can be generated which
+   claims that a certain QNAME (i.e. the second pre-image) does exist,
+   while in reality QNAME does not exist (a false positive), which will
+
+
+
+Laurie, et al.           Expires August 5, 2006                [Page 16]
+
+Internet-Draft                    nsec3                    February 2006
+
+
+   either cause a security aware resolver to re-query for the non-
+   existent name, or to fail the initial query.  Note that the adversary
+   can't mount this attack on an existing name but only on a name that
+   the adversary can't choose and does not yet exist.
+
+8.4.3.  Possible Hash Value Truncation Method
+
+   The previous sections outlined the low probability and low impact of
+   a second-preimage attack.  When impact and probability are low, while
+   space in a DNS message is costly, truncation is tempting.  Truncation
+   might be considered to allow for shorter ownernames and rdata for
+   hashed labels.  In general, if a cryptographic hash is truncated to n
+   bits, then the expected number of domains required to give a 1 in 2
+   probability of a single collision is approximately 2^(n/2) and the
+   work factor to produce a second preimage is 2^n.
+
+   An extreme hash value truncation would be truncating to the shortest
+   possible unique label value.  This would be unwise, since the work
+   factor to produce second preimages would then approximate the size of
+   the zone (sketch of proof: if the zone has k entries, then the length
+   of the names when truncated down to uniqueness should be proportional
+   to log_2(k).  Since the work factor to produce a second pre-image is
+   2^n for an n-bit hash, then in this case it is 2^(C log_2(k)) (where
+   C is some constant), i.e.  C'k - a work factor of k).
+
+   Though the mentioned truncation can be maximized to a certain
+   extreme, the probability of collision increases exponentially for
+   every truncated bit.  Given the low impact of hash value collisions
+   and limited space in DNS messages, the balance between truncation
+   profit and collision damage may be determined by local policy.  Of
+   course, the size of the corresponding RRSIG RR is not reduced, so
+   truncation is of limited benefit.
+
+   Truncation could be signaled simply by reducing the length of the
+   first label in the ownername.  Note that there would have to be a
+   corresponding reduction in the length of the Next Hashed Ownername
+   field.
+
+8.4.4.  Server Response to a Run-time Collision
+
+   In the astronomically unlikely event that a server is unable to prove
+   nonexistence because the hash of the name that does not exist
+   collides with a name that does exist, the server is obviously broken,
+   and should, therefore, return a response with an RCODE of 2 (server
+   failure).
+
+
+
+
+
+
+Laurie, et al.           Expires August 5, 2006                [Page 17]
+
+Internet-Draft                    nsec3                    February 2006
+
+
+8.4.5.  Parameters that Cover the Zone
+
+   Secondary servers (and perhaps other entities) need to reliably
+   determine which NSEC3 parameters (that is, hash, salt and iterations)
+   are present at every hashed ownername, in order to be able to choose
+   an appropriate set of NSEC3 records for negative responses.  This is
+   indicated by the parameters at the apex: any set of parameters that
+   is used in an NSEC3 record whose original ownername is the apex of
+   the zone MUST be present throughout the zone.
+
+   A method to determine which NSEC3 in a complete chain corresponds to
+   the apex is to look for a NSEC3 RRset which has the SOA bit set in
+   the RDATA bit type maps field.
+
+
+9.  Performance Considerations
+
+   Iterated hashes impose a performance penalty on both authoritative
+   servers and resolvers.  Therefore, the number of iterations should be
+   carefully chosen.  In particular it should be noted that a high value
+   for iterations gives an attacker a very good denial of service
+   attack, since the attacker need not bother to verify the results of
+   their queries, and hence has no performance penalty of his own.
+
+   On the other hand, nameservers with low query rates and limited
+   bandwidth are already subject to a bandwidth based denial of service
+   attack, since responses are typically an order of magnitude larger
+   than queries, and hence these servers may choose a high value of
+   iterations in order to increase the difficulty of offline attempts to
+   enumerate their namespace without significantly increasing their
+   vulnerability to denial of service attacks.
+
+
+10.  IANA Considerations
+
+   IANA needs to allocate a RR type code for NSEC3 from the standard RR
+   type space (type XXX requested).  IANA needs to open a new registry
+   for the NSEC3 Hash Functions.  The range for this registry is 0-127.
+   Defined types are:
+
+      0 is reserved.
+      1 is SHA-1 ([13]).
+      127 is experimental.
+
+
+11.  Security Considerations
+
+   The NSEC3 records are still susceptible to dictionary attacks (i.e.
+
+
+
+Laurie, et al.           Expires August 5, 2006                [Page 18]
+
+Internet-Draft                    nsec3                    February 2006
+
+
+   the attacker retrieves all the NSEC3 records, then calculates the
+   hashes of all likely domain names, comparing against the hashes found
+   in the NSEC3 records, and thus enumerating the zone).  These are
+   substantially more expensive than enumerating the original NSEC
+   records would have been, and in any case, such an attack could also
+   be used directly against the name server itself by performing queries
+   for all likely names, though this would obviously be more detectable.
+   The expense of this off-line attack can be chosen by setting the
+   number of iterations in the NSEC3 RR.
+
+   Domains are also susceptible to a precalculated dictionary attack -
+   that is, a list of hashes for all likely names is computed once, then
+   NSEC3 is scanned periodically and compared against the precomputed
+   hashes.  This attack is prevented by changing the salt on a regular
+   basis.
+
+   Walking the NSEC3 RRs will reveal the total number of records in the
+   zone, and also what types they are.  This could be mitigated by
+   adding dummy entries, but certainly an upper limit can always be
+   found.
+
+   Hash collisions may occur.  If they do, it will be impossible to
+   prove the non-existence of the colliding domain - however, this is
+   fantastically unlikely, and, in any case, DNSSEC already relies on
+   SHA-1 to not collide.
+
+   Responses to queries where QNAME equals an NSEC3 ownername that has
+   no other types may be undetectably changed from a NOERROR/NODATA
+   response to a NAME ERROR response.
+
+   The Opt-In Flag (O) allows for unsigned names, in the form of
+   delegations to unsigned subzones, to exist within an otherwise signed
+   zone.  All unsigned names are, by definition, insecure, and their
+   validity or existence cannot by cryptographically proven.
+
+   In general:
+      Records with unsigned names (whether existing or not) suffer from
+      the same vulnerabilities as records in an unsigned zone.  These
+      vulnerabilities are described in more detail in [16] (note in
+      particular sections 2.3, "Name Games" and 2.6, "Authenticated
+      Denial").
+      Records with signed names have the same security whether or not
+      Opt-In is used.
+
+   Note that with or without Opt-In, an insecure delegation may be
+   undetectably altered by an attacker.  Because of this, the primary
+   difference in security when using Opt-In is the loss of the ability
+   to prove the existence or nonexistence of an insecure delegation
+
+
+
+Laurie, et al.           Expires August 5, 2006                [Page 19]
+
+Internet-Draft                    nsec3                    February 2006
+
+
+   within the span of an Opt-In NSEC3 record.
+
+   In particular, this means that a malicious entity may be able to
+   insert or delete records with unsigned names.  These records are
+   normally NS records, but this also includes signed wildcard
+   expansions (while the wildcard record itself is signed, its expanded
+   name is an unsigned name).
+
+   For example, if a resolver received the following response from the
+   example zone above:
+
+   Example S.1: Response to query for WWW.DOES-NOT-EXIST.EXAMPLE.  A
+
+           RCODE=NOERROR
+
+           Answer Section:
+
+           Authority Section:
+           DOES-NOT-EXIST.EXAMPLE. NS     NS.FORGED.
+           EXAMPLE.                NSEC   FIRST-SECURE.EXAMPLE. SOA NS \
+                                          RRSIG DNSKEY
+           abcd...                 RRSIG  NSEC3 ...
+
+           Additional Section:
+
+   The resolver would have no choice but to accept that the referral to
+   NS.FORGED. is valid.  If a wildcard existed that would have been
+   expanded to cover "WWW.DOES-NOT-EXIST.EXAMPLE.", an attacker could
+   have undetectably removed it and replaced it with the forged
+   delegation.
+
+   Note that being able to add a delegation is functionally equivalent
+   to being able to add any record type: an attacker merely has to forge
+   a delegation to nameserver under his/her control and place whatever
+   records needed at the subzone apex.
+
+   While in particular cases, this issue may not present a significant
+   security problem, in general it should not be lightly dismissed.
+   Therefore, it is strongly RECOMMENDED that Opt-In be used sparingly.
+   In particular, zone signing tools SHOULD NOT default to using Opt-In,
+   and MAY choose to not support Opt-In at all.
+
+
+12.  References
+
+
+
+
+
+
+
+Laurie, et al.           Expires August 5, 2006                [Page 20]
+
+Internet-Draft                    nsec3                    February 2006
+
+
+12.1.  Normative References
+
+   [1]   Mockapetris, P., "Domain names - concepts and facilities",
+         STD 13, RFC 1034, November 1987.
+
+   [2]   Mockapetris, P., "Domain names - implementation and
+         specification", STD 13, RFC 1035, November 1987.
+
+   [3]   Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+         "DNS Security Introduction and Requirements", RFC 4033,
+         March 2005.
+
+   [4]   Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+         "Resource Records for the DNS Security Extensions", RFC 4034,
+         March 2005.
+
+   [5]   Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+         "Protocol Modifications for the DNS Security Extensions",
+         RFC 4035, March 2005.
+
+   [6]   Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic
+         Updates in the Domain Name System (DNS UPDATE)", RFC 2136,
+         April 1997.
+
+   [7]   Elz, R. and R. Bush, "Clarifications to the DNS Specification",
+         RFC 2181, July 1997.
+
+   [8]   Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)",
+         RFC 2308, March 1998.
+
+   [9]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
+         Levels", BCP 14, RFC 2119, March 1997.
+
+   [10]  Gudmundsson, O., "Delegation Signer (DS) Resource Record (RR)",
+         RFC 3658, December 2003.
+
+   [11]  Eastlake, D., Brunner-Williams, E., and B. Manning, "Domain
+         Name System (DNS) IANA Considerations", BCP 42, RFC 2929,
+         September 2000.
+
+   [12]  Gustafsson, A., "Handling of Unknown DNS Resource Record (RR)
+         Types", RFC 3597, September 2003.
+
+   [13]  Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)",
+         RFC 3174, September 2001.
+
+
+
+
+
+
+Laurie, et al.           Expires August 5, 2006                [Page 21]
+
+Internet-Draft                    nsec3                    February 2006
+
+
+12.2.  Informative References
+
+   [14]  Vixie, P., "Extending DNSSEC-BIS (DNSSEC-TER)",
+         draft-vixie-dnssec-ter-01 (work in progress), June 2004.
+
+   [15]  Josefsson, Ed., S,., "The Base16, Base32, and Base64 Data
+         Encodings.", draft-josefsson-rfc3548bis-00 (work in progress),
+         October 2005.
+
+   [16]  Atkins, D. and R. Austein, "Threat Analysis of the Domain Name
+         System (DNS)", RFC 3833, August 2004.
+
+Editorial Comments
+
+   [Comment.1]  Although, strictly speaking, the names *did* exist.
+
+   [Comment.2]  Note that this method makes it impossible to detect
+                (extremely unlikely) hash collisions.
+
+
+Appendix A.  Example Zone
+
+   This is a zone showing its NSEC3 records.  They can also be used as
+   test vectors for the hash algorithm.
+
+   The data in the example zone is currently broken, as it uses a
+   different base32 alphabet.  This shall be fixed in the next release.
+
+
+   example.       3600 IN SOA ns1.example. bugs.x.w.example. (
+                              1
+                              3600
+                              300
+                              3600000
+                              3600 )
+                  3600 RRSIG  SOA 5 1 3600 20050712112304 (
+                              20050612112304 62699 example.
+                              RtctD6aLUU5Md5wOOItilS7JXX1tf58Ql3sK
+                              mTXkL13jqLiUFOGg0uzqRh1U9GbydS0P7M0g
+                              qYIt90txzE/4+g== )
+                  3600 NS     ns1.example.
+                  3600 NS     ns2.example.
+                  3600 RRSIG  NS 5 1 3600 20050712112304 (
+                              20050612112304 62699 example.
+                              hNyyin2JpECIFxW4vsj8RhHcWCQKUXgO+z4l
+                              m7g2zM8q3Qpsm/gYIXSF2Rhj6lAG7esR/X9d
+                              1SH5r/wfjuCg+g== )
+                  3600 MX     1 xx.example.
+
+
+
+Laurie, et al.           Expires August 5, 2006                [Page 22]
+
+Internet-Draft                    nsec3                    February 2006
+
+
+                  3600 RRSIG  MX 5 1 3600 20050712112304 (
+                              20050612112304 62699 example.
+                              L/ZDLMSZJKITmSxmM9Kni37/wKQsdSg6FT0l
+                              NMm14jy2Stp91Pwp1HQ1hAMkGWAqCMEKPMtU
+                              S/o/g5C8VM6ftQ== )
+                  3600 DNSKEY 257 3 5 (
+                              AQOnsGyJvywVjYmiLbh0EwIRuWYcDiB/8blX
+                              cpkoxtpe19Oicv6Zko+8brVsTMeMOpcUeGB1
+                              zsYKWJ7BvR2894hX
+                              ) ; Key ID = 21960
+                  3600 DNSKEY 256 3 5 (
+                              AQO0gEmbZUL6xbD/xQczHbnwYnf+jQjwz/sU
+                              5k44rHTt0Ty+3aOdYoome9TjGMhwkkGby1TL
+                              ExXT48OGGdbfIme5
+                              ) ; Key ID = 62699
+                  3600 RRSIG  DNSKEY 5 1 3600 20050712112304 (
+                              20050612112304 62699 example.
+                              e6EB+K21HbyZzoLUeRDb6+g0+n8XASYe6h+Z
+                              xtnB31sQXZgq8MBHeNFDQW9eZw2hjT9zMClx
+                              mTkunTYzqWJrmQ== )
+                  3600 RRSIG  DNSKEY 5 1 3600 20050712112304 (
+                              20050612112304 21960 example.
+                              SnWLiNWLbOuiKU/F/wVMokvcg6JVzGpQ2VUk
+                              ZbKjB9ON0t3cdc+FZbOCMnEHRJiwgqlnncik
+                              3w7ZY2UWyYIvpw== )
+   5pe7ctl7pfs2cilroy5dcofx4rcnlypd.example. 3600 NSEC3  0 1 1 (
+                              deadbeaf
+                              7nomf47k3vlidh4vxahhpp47l3tgv7a2
+                              NSEC3 RRSIG )
+                  3600 RRSIG  NSEC3 5 2 3600 20050712112304 (
+                              20050612112304 62699 example.
+                              PTWYq4WZmmtgh9UQif342HWf9DD9RuuM4ii5
+                              Z1oZQgRi5zrsoKHAgl2YXprF2Rfk1TLgsiFQ
+                              sb7KfbaUo/vzAg== )
+   7nomf47k3vlidh4vxahhpp47l3tgv7a2.example. 3600 NSEC3  0 1 1 (
+                              deadbeaf
+                              dw4o7j64wnel3j4jh7fb3c5n7w3js2yb
+                              MX NSEC3 RRSIG )
+                  3600 RRSIG  NSEC3 5 2 3600 20050712112304 (
+                              20050612112304 62699 example.
+                              YTcqole3h8EOsTT3HKnwhR1QS8borR0XtZaA
+                              ZrLsx6n0RDC1AAdZONYOvdqvcal9PmwtWjlo
+                              MEFQmc/gEuxojA== )
+   a.example.     3600 IN NS  ns1.a.example.
+                  3600 IN NS  ns2.a.example.
+                  3600 DS     58470 5 1 3079F1593EBAD6DC121E202A8B
+                              766A6A4837206C )
+                  3600 RRSIG  DS 5 2 3600 20050712112304 (
+
+
+
+Laurie, et al.           Expires August 5, 2006                [Page 23]
+
+Internet-Draft                    nsec3                    February 2006
+
+
+                              20050612112304 62699 example.
+                              QavhbsSmEvJLSUzGoTpsV3SKXCpaL1UO3Ehn
+                              cB0ObBIlex/Zs9kJyG/9uW1cYYt/1wvgzmX2
+                              0kx7rGKTc3RQDA== )
+   ns1.a.example. 3600 IN A   192.0.2.5
+   ns2.a.example. 3600 IN A   192.0.2.6
+   ai.example.    3600 IN A   192.0.2.9
+                  3600 RRSIG  A 5 2 3600 20050712112304 (
+                              20050612112304 62699 example.
+                              plY5M26ED3Owe3YX0pBIhgg44j89NxUaoBrU
+                              6bLRr99HpKfFl1sIy18JiRS7evlxCETZgubq
+                              ZXW5S+1VjMZYzQ== )
+                  3600 HINFO  "KLH-10" "ITS"
+                  3600 RRSIG  HINFO 5 2 3600 20050712112304 (
+                              20050612112304 62699 example.
+                              AR0hG/Z/e+vlRhxRQSVIFORzrJTBpdNHhwUk
+                              tiuqg+zGqKK84eIqtrqXelcE2szKnF3YPneg
+                              VGNmbgPnqDVPiA== )
+                  3600 AAAA   2001:db8:0:0:0:0:f00:baa9
+                  3600 RRSIG  AAAA 5 2 3600 20050712112304 (
+                              20050612112304 62699 example.
+                              PNF/t7+DeosEjhfuL0kmsNJvn16qhYyLI9FV
+                              ypSCorFx/PKIlEL3syomkYM2zcXVSRwUXMns
+                              l5/UqLCJJ9BDMg== )
+   b.example.     3600 IN NS  ns1.b.example.
+                  3600 IN NS  ns2.b.example.
+   ns1.b.example. 3600 IN A   192.0.2.7
+   ns2.b.example. 3600 IN A   192.0.2.8
+   dw4o7j64wnel3j4jh7fb3c5n7w3js2yb.example. 3600 NSEC3  0 1 1 (
+                              deadbeaf
+                              gmnfcccja7wkax3iv26bs75myptje3qk
+                              MX DNSKEY NS SOA NSEC3 RRSIG )
+                  3600 RRSIG  NSEC3 5 2 3600 20050712112304 (
+                              20050612112304 62699 example.
+                              VqEbXiZLJVYmo25fmO3IuHkAX155y8NuA50D
+                              C0NmJV/D4R3rLm6tsL6HB3a3f6IBw6kKEa2R
+                              MOiKMSHozVebqw== )
+   gmnfcccja7wkax3iv26bs75myptje3qk.example. 3600 NSEC3  0 1 1 (
+                              deadbeaf
+                              jt4bbfokgbmr57qx4nqucvvn7fmo6ab6
+                              DS NS NSEC3 RRSIG )
+                  3600 RRSIG  NSEC3 5 2 3600 20050712112304 (
+                              20050612112304 62699 example.
+                              ZqkdmF6eICpHyn1Cj7Yvw+nLcbji46Qpe76/
+                              ZetqdZV7K5sO3ol5dOc0dZyXDqsJp1is5StW
+                              OwQBGbOegrW/Zw== )
+   jt4bbfokgbmr57qx4nqucvvn7fmo6ab6.example. 3600 NSEC3  0 1 1 (
+                              deadbeaf
+
+
+
+Laurie, et al.           Expires August 5, 2006                [Page 24]
+
+Internet-Draft                    nsec3                    February 2006
+
+
+                              kcll7fqfnisuhfekckeeqnmbbd4maanu
+                              NSEC3 RRSIG )
+                  3600 RRSIG  NSEC3 5 2 3600 20050712112304 (
+                              20050612112304 62699 example.
+                              FXyCVQUdFF1EW1NcgD2V724/It0rn3lr+30V
+                              IyjmqwOMvQ4G599InTpiH46xhX3U/FmUzHOK
+                              94Zbq3k8lgdpZA== )
+   kcll7fqfnisuhfekckeeqnmbbd4maanu.example. 3600 NSEC3  1 1 1 (
+                              deadbeaf
+                              n42hbhnjj333xdxeybycax5ufvntux5d
+                              MX NSEC3 RRSIG )
+                  3600 RRSIG  NSEC3 5 2 3600 20050712112304 (
+                              20050612112304 62699 example.
+                              d0g8MTOvVwByOAIwvYV9JrTHwJof1VhnMKuA
+                              IBj6Xaeney86RBZYgg7Qyt9WnQSK3uCEeNpx
+                              TOLtc5jPrkL4zQ== )
+   n42hbhnjj333xdxeybycax5ufvntux5d.example. 3600 NSEC3  0 1 1 (
+                              deadbeaf
+                              nimwfwcnbeoodmsc6npv3vuaagaevxxu
+                              A NSEC3 RRSIG )
+                  3600 RRSIG  NSEC3 5 2 3600 20050712112304 (
+                              20050612112304 62699 example.
+                              MZGzllh+YFqZbY8SkHxARhXFiMDPS0tvQYyy
+                              91tj+lbl45L/BElD3xxB/LZMO8vQejYtMLHj
+                              xFPFGRIW3wKnrA== )
+   nimwfwcnbeoodmsc6npv3vuaagaevxxu.example. 3600 NSEC3  0 1 1 (
+                              deadbeaf
+                              vhgwr2qgykdkf4m6iv6vkagbxozphazr
+                              HINFO A AAAA NSEC3 RRSIG )
+                  3600 RRSIG  NSEC3 5 2 3600 20050712112304 (
+                              20050612112304 62699 example.
+                              c3zQdK68cYTHTjh1cD6pi0vblXwzyoU/m7Qx
+                              z8kaPYikbJ9vgSl9YegjZukgQSwybHUC0SYG
+                              jL33Wm1p07TBdw== )
+   ns1.example.   3600 A      192.0.2.1
+                  3600 RRSIG  A 5 2 3600 20050712112304 (
+                              20050612112304 62699 example.
+                              QLGkaqWXxRuE+MHKkMvVlswg65HcyjvD1fyb
+                              BDZpcfiMHH9w4x1eRqRamtSDTcqLfUrcYkrr
+                              nWWLepz1PjjShQ== )
+   ns2.example.   3600 A      192.0.2.2
+                  3600 RRSIG  A 5 2 3600 20050712112304 (
+                              20050612112304 62699 example.
+                              UoIZaC1O6XHRWGHBOl8XFQKPdYTkRCz6SYh3
+                              P2mZ3xfY22fLBCBDrEnOc8pGDGijJaLl26Cz
+                              AkeTJu3J3auUiA== )
+   vhgwr2qgykdkf4m6iv6vkagbxozphazr.example. 3600 NSEC3  0 1 1 (
+                              deadbeaf
+
+
+
+Laurie, et al.           Expires August 5, 2006                [Page 25]
+
+Internet-Draft                    nsec3                    February 2006
+
+
+                              wbyijvpnyj33pcpi3i44ecnibnaj7eiw
+                              HINFO A AAAA NSEC3 RRSIG )
+                  3600 RRSIG  NSEC3 5 2 3600 20050712112304 (
+                              20050612112304 62699 example.
+                              leFhoF5FXZAiNOxK4OBOOA0WKdbaD5lLDT/W
+                              kLoyWnQ6WGBwsUOdsEcVmqz+1n7q9bDf8G8M
+                              5SNSHIyfpfsi6A== )
+   *.w.example.   3600 MX     1 ai.example.
+                  3600 RRSIG  MX 5 3 3600 20050712112304 (
+                              20050612112304 62699 example.
+                              sYNUPHn1/gJ87wTHNksGdRm3vfnSFa2BbofF
+                              xGfJLF5A4deRu5f0hvxhAFDCcXfIASj7z0wQ
+                              gQlgxEwhvQDEaQ== )
+   x.w.example.   3600 MX     1 xx.example.
+                  3600 RRSIG  MX 5 3 3600 20050712112304 (
+                              20050612112304 62699 example.
+                              s1XQ/8SlViiEDik9edYs1Ooe3XiXo453Dg7w
+                              lqQoewuDzmtd6RaLNu52W44zTM1EHJES8ujP
+                              U9VazOa1KEIq1w== )
+   x.y.w.example. 3600 MX     1 xx.example.
+                  3600 RRSIG  MX 5 4 3600 20050712112304 (
+                              20050612112304 62699 example.
+                              aKVCGO/Fx9rm04UUsHRTTYaDA8o8dGfyq6t7
+                              uqAcYxU9xiXP+xNtLHBv7er6Q6f2JbOs6SGF
+                              9VrQvJjwbllAfA== )
+   wbyijvpnyj33pcpi3i44ecnibnaj7eiw.example. 3600 NSEC3  0 1 1 (
+                              deadbeaf
+                              zjxfz5o7t4ty4u3f6fa7mhhqzjln4mui
+                              A NSEC3 RRSIG )
+                  3600 RRSIG  NSEC3 5 2 3600 20050712112304 (
+                              20050612112304 62699 example.
+                              ledFAaDCqDxapQ1FvBAjjK2DP06iQj8AN6gN
+                              ZycTeSmobKLTpzbgQp8uKYYe/DPHjXYmuEhd
+                              oorBv4xkb0flXw== )
+   xx.example.    3600 A      192.0.2.10
+                  3600 RRSIG  A 5 2 3600 20050712112304 (
+                              20050612112304 62699 example.
+                              XSuMVjNxovbZUsnKU6oQDygaK+WB+O5HYQG9
+                              tJgphHIX7TM4uZggfR3pNM+4jeC8nt2OxZZj
+                              cxwCXWj82GVGdw== )
+                  3600 HINFO  "KLH-10" "TOPS-20"
+                  3600 RRSIG  HINFO 5 2 3600 20050712112304 (
+                              20050612112304 62699 example.
+                              ghS2DimOqPSacG9j6KMgXSfTMSjLxvoxvx3q
+                              OKzzPst4tEbAmocF2QX8IrSHr67m4ZLmd2Fk
+                              KMf4DgNBDj+dIQ== )
+                  3600 AAAA   2001:db8:0:0:0:0:f00:baaa
+                  3600 RRSIG  AAAA 5 2 3600 20050712112304 (
+
+
+
+Laurie, et al.           Expires August 5, 2006                [Page 26]
+
+Internet-Draft                    nsec3                    February 2006
+
+
+                              20050612112304 62699 example.
+                              rto7afZkXYB17IfmQCT5QoEMMrlkeOoAGXzo
+                              w8Wmcg86Fc+MQP0hyXFScI1gYNSgSSoDMXIy
+                              rzKKwb8J04/ILw== )
+   zjxfz5o7t4ty4u3f6fa7mhhqzjln4mui.example. 3600 NSEC3  0 1 1 (
+                              deadbeaf
+                              5pe7ctl7pfs2cilroy5dcofx4rcnlypd
+                              MX NSEC3 RRSIG )
+                  3600 RRSIG  NSEC3 5 2 3600 20050712112304 (
+                              20050612112304 62699 example.
+                              eULkdWjcjmM+wXQcr7zXNfnGLgHjZSJINGkt
+                              7Zmvp7WKVAqoHMm1RXV8IfBH1aRgv5+/Lgny
+                              OcFlrPGPMm48/A== )
+
+
+Appendix B.  Example Responses
+
+   The examples in this section show response messages using the signed
+   zone example in Appendix A.
+
+B.1.  answer
+
+   A successful query to an authoritative server.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Laurie, et al.           Expires August 5, 2006                [Page 27]
+
+Internet-Draft                    nsec3                    February 2006
+
+
+   ;; Header: QR AA DO RCODE=0
+   ;;
+   ;; Question
+   x.w.example.        IN MX
+
+   ;; Answer
+   x.w.example.   3600 IN MX  1 xx.example.
+   x.w.example.   3600 IN RRSIG  MX 5 3 3600 20050712112304 (
+                              20050612112304 62699 example.
+                              s1XQ/8SlViiEDik9edYs1Ooe3XiXo453Dg7w
+                              lqQoewuDzmtd6RaLNu52W44zTM1EHJES8ujP
+                              U9VazOa1KEIq1w== )
+
+   ;; Authority
+   example.       3600 IN NS  ns1.example.
+   example.       3600 IN NS  ns2.example.
+   example.       3600 IN RRSIG  NS 5 1 3600 20050712112304 (
+                              20050612112304 62699 example.
+                              hNyyin2JpECIFxW4vsj8RhHcWCQKUXgO+z4l
+                              m7g2zM8q3Qpsm/gYIXSF2Rhj6lAG7esR/X9d
+                              1SH5r/wfjuCg+g== )
+
+   ;; Additional
+   xx.example.    3600 IN A   192.0.2.10
+   xx.example.    3600 IN RRSIG  A 5 2 3600 20050712112304 (
+                              20050612112304 62699 example.
+                              XSuMVjNxovbZUsnKU6oQDygaK+WB+O5HYQG9
+                              tJgphHIX7TM4uZggfR3pNM+4jeC8nt2OxZZj
+                              cxwCXWj82GVGdw== )
+   xx.example.    3600 IN AAAA   2001:db8::f00:baaa
+   xx.example.    3600 IN RRSIG  AAAA 5 2 3600 20050712112304 (
+                              20050612112304 62699 example.
+                              rto7afZkXYB17IfmQCT5QoEMMrlkeOoAGXzo
+                              w8Wmcg86Fc+MQP0hyXFScI1gYNSgSSoDMXIy
+                              rzKKwb8J04/ILw== )
+   ns1.example.   3600 IN A   192.0.2.1
+   ns1.example.   3600 IN RRSIG  A 5 2 3600 20050712112304 (
+                              20050612112304 62699 example.
+                              QLGkaqWXxRuE+MHKkMvVlswg65HcyjvD1fyb
+                              BDZpcfiMHH9w4x1eRqRamtSDTcqLfUrcYkrr
+                              nWWLepz1PjjShQ== )
+   ns2.example.   3600 IN A   192.0.2.2
+   ns2.example.   3600 IN RRSIG  A 5 2 3600 20050712112304 (
+                              20050612112304 62699 example.
+                              UoIZaC1O6XHRWGHBOl8XFQKPdYTkRCz6SYh3
+                              P2mZ3xfY22fLBCBDrEnOc8pGDGijJaLl26Cz
+                              AkeTJu3J3auUiA== )
+
+
+
+
+Laurie, et al.           Expires August 5, 2006                [Page 28]
+
+Internet-Draft                    nsec3                    February 2006
+
+
+   The query returned an MX RRset for "x.w.example".  The corresponding
+   RRSIG RR indicates that the MX RRset was signed by an "example"
+   DNSKEY with algorithm 5 and key tag 62699.  The resolver needs the
+   corresponding DNSKEY RR in order to authenticate this answer.  The
+   discussion below describes how a resolver might obtain this DNSKEY
+   RR.
+
+   The RRSIG RR indicates the original TTL of the MX RRset was 3600,
+   and, for the purpose of authentication, the current TTL is replaced
+   by 3600.  The RRSIG RR's labels field value of 3 indicates that the
+   answer was not the result of wildcard expansion.  The "x.w.example"
+   MX RRset is placed in canonical form, and, assuming the current time
+   falls between the signature inception and expiration dates, the
+   signature is authenticated.
+
+B.1.1.  Authenticating the Example DNSKEY RRset
+
+   This example shows the logical authentication process that starts
+   from a configured root DNSKEY RRset (or DS RRset) and moves down the
+   tree to authenticate the desired "example" DNSKEY RRset.  Note that
+   the logical order is presented for clarity.  An implementation may
+   choose to construct the authentication as referrals are received or
+   to construct the authentication chain only after all RRsets have been
+   obtained, or in any other combination it sees fit.  The example here
+   demonstrates only the logical process and does not dictate any
+   implementation rules.
+
+   We assume the resolver starts with a configured DNSKEY RRset for the
+   root zone (or a configured DS RRset for the root zone).  The resolver
+   checks whether this configured DNSKEY RRset is present in the root
+   DNSKEY RRset (or whether a DS RR in the DS RRset matches some DNSKEY
+   RR in the root DNSKEY RRset), whether this DNSKEY RR has signed the
+   root DNSKEY RRset, and whether the signature lifetime is valid.  If
+   all these conditions are met, all keys in the DNSKEY RRset are
+   considered authenticated.  The resolver then uses one (or more) of
+   the root DNSKEY RRs to authenticate the "example" DS RRset.  Note
+   that the resolver may have to query the root zone to obtain the root
+   DNSKEY RRset or "example" DS RRset.
+
+   Once the DS RRset has been authenticated using the root DNSKEY, the
+   resolver checks the "example" DNSKEY RRset for some "example" DNSKEY
+   RR that matches one of the authenticated "example" DS RRs.  If such a
+   matching "example" DNSKEY is found, the resolver checks whether this
+   DNSKEY RR has signed the "example" DNSKEY RRset and the signature
+   lifetime is valid.  If these conditions are met, all keys in the
+   "example" DNSKEY RRset are considered authenticated.
+
+   Finally, the resolver checks that some DNSKEY RR in the "example"
+
+
+
+Laurie, et al.           Expires August 5, 2006                [Page 29]
+
+Internet-Draft                    nsec3                    February 2006
+
+
+   DNSKEY RRset uses algorithm 5 and has a key tag of 62699.  This
+   DNSKEY is used to authenticate the RRSIG included in the response.
+   If multiple "example" DNSKEY RRs match this algorithm and key tag,
+   then each DNSKEY RR is tried, and the answer is authenticated if any
+   of the matching DNSKEY RRs validate the signature as described above.
+
+B.2.  Name Error
+
+   An authoritative name error.  The NSEC3 RRs prove that the name does
+   not exist and that no covering wildcard exists.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Laurie, et al.           Expires August 5, 2006                [Page 30]
+
+Internet-Draft                    nsec3                    February 2006
+
+
+   ;; Header: QR AA DO RCODE=3
+   ;;
+   ;; Question
+   a.c.x.w.example.         IN A
+
+   ;; Answer
+   ;; (empty)
+
+   ;; Authority
+   example.       3600 IN SOA ns1.example. bugs.x.w.example. (
+                              1
+                              3600
+                              300
+                              3600000
+                              3600
+                              )
+   example.       3600 IN RRSIG  SOA 5 1 3600 20050712112304 (
+                              20050612112304 62699 example.
+                              RtctD6aLUU5Md5wOOItilS7JXX1tf58Ql3sK
+                              mTXkL13jqLiUFOGg0uzqRh1U9GbydS0P7M0g
+                              qYIt90txzE/4+g== )
+   7nomf47k3vlidh4vxahhpp47l3tgv7a2.example. 3600 IN NSEC3  0 1 1 (
+                              deadbeaf
+                              dw4o7j64wnel3j4jh7fb3c5n7w3js2yb
+                              MX NSEC3 RRSIG )
+   7nomf47k3vlidh4vxahhpp47l3tgv7a2.example. 3600 IN RRSIG  NSEC3 (
+                              5 2 3600 20050712112304
+                              20050612112304 62699 example.
+                              YTcqole3h8EOsTT3HKnwhR1QS8borR0XtZaA
+                              ZrLsx6n0RDC1AAdZONYOvdqvcal9PmwtWjlo
+                              MEFQmc/gEuxojA== )
+   nimwfwcnbeoodmsc6npv3vuaagaevxxu.example. 3600 IN NSEC3  0 1 1 (
+                              deadbeaf
+                              vhgwr2qgykdkf4m6iv6vkagbxozphazr
+                              HINFO A AAAA NSEC3 RRSIG )
+   nimwfwcnbeoodmsc6npv3vuaagaevxxu.example. 3600 IN RRSIG  NSEC3 (
+                              5 2 3600 20050712112304
+                              20050612112304 62699 example.
+                              c3zQdK68cYTHTjh1cD6pi0vblXwzyoU/m7Qx
+                              z8kaPYikbJ9vgSl9YegjZukgQSwybHUC0SYG
+                              jL33Wm1p07TBdw== )
+   ;; Additional
+   ;; (empty)
+
+   The query returned two NSEC3 RRs that prove that the requested data
+   does not exist and no wildcard applies.  The negative reply is
+   authenticated by verifying both NSEC3 RRs.  The NSEC3 RRs are
+   authenticated in a manner identical to that of the MX RRset discussed
+
+
+
+Laurie, et al.           Expires August 5, 2006                [Page 31]
+
+Internet-Draft                    nsec3                    February 2006
+
+
+   above.  At least one of the owner names of the NSEC3 RRs will match
+   the closest encloser.  At least one of the NSEC3 RRs prove that there
+   exists no longer name.  At least one of the NSEC3 RRs prove that
+   there exists no wildcard RRsets that should have been expanded.  The
+   closest encloser can be found by hashing the apex ownername (The SOA
+   RR's ownername, or the ownername of the DNSKEY RRset referred by an
+   RRSIG RR), matching it to the ownername of one of the NSEC3 RRs, and
+   if that fails, continue by adding labels.  In other words, the
+   resolver first hashes example, checks for a matching NSEC3 ownername,
+   then hashes w.example, checks, and finally hashes w.x.example and
+   checks.
+
+   In the above example, the name 'x.w.example' hashes to
+   '7nomf47k3vlidh4vxahhpp47l3tgv7a2'.  This indicates that this might
+   be the closest encloser.  To prove that 'c.x.w.example' and
+   '*.x.w.example' do not exists, these names are hashed to respectively
+   'qsgoxsf2lanysajhtmaylde4tqwnqppl' and
+   'cvljzyf6nsckjowghch4tt3nohocpdka'.  The two NSEC3 records prove that
+   these hashed ownernames do not exists, since the names are within the
+   given intervals.
+
+B.3.  No Data Error
+
+   A "no data" response.  The NSEC3 RR proves that the name exists and
+   that the requested RR type does not.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Laurie, et al.           Expires August 5, 2006                [Page 32]
+
+Internet-Draft                    nsec3                    February 2006
+
+
+   ;; Header: QR AA DO RCODE=0
+   ;;
+   ;; Question
+   ns1.example.        IN MX
+
+   ;; Answer
+   ;; (empty)
+
+   ;; Authority
+   example.       3600 IN SOA ns1.example. bugs.x.w.example. (
+                              1
+                              3600
+                              300
+                              3600000
+                              3600
+                              )
+   example.       3600 IN RRSIG  SOA 5 1 3600 20050712112304 (
+                              20050612112304 62699 example.
+                              RtctD6aLUU5Md5wOOItilS7JXX1tf58Ql3sK
+                              mTXkL13jqLiUFOGg0uzqRh1U9GbydS0P7M0g
+                              qYIt90txzE/4+g== )
+   wbyijvpnyj33pcpi3i44ecnibnaj7eiw.example. 3600 IN NSEC3  0 1 1 (
+                              deadbeaf
+                              zjxfz5o7t4ty4u3f6fa7mhhqzjln4mui
+                              A NSEC3 RRSIG )
+   wbyijvpnyj33pcpi3i44ecnibnaj7eiw.example. 3600 IN RRSIG  NSEC3 (
+                              5 2 3600 20050712112304
+                              20050612112304 62699 example.
+                              ledFAaDCqDxapQ1FvBAjjK2DP06iQj8AN6gN
+                              ZycTeSmobKLTpzbgQp8uKYYe/DPHjXYmuEhd
+                              oorBv4xkb0flXw== )
+   ;; Additional
+   ;; (empty)
+
+   The query returned an NSEC3 RR that proves that the requested name
+   exists ("ns1.example." hashes to "wbyijvpnyj33pcpi3i44ecnibnaj7eiw"),
+   but the requested RR type does not exist (type MX is absent in the
+   type code list of the NSEC RR).  The negative reply is authenticated
+   by verifying the NSEC3 RR.  The NSEC3 RR is authenticated in a manner
+   identical to that of the MX RRset discussed above.
+
+B.3.1.  No Data Error, Empty Non-Terminal
+
+   A "no data" response because of an empty non-terminal.  The NSEC3 RR
+   proves that the name exists and that the requested RR type does not.
+
+
+
+
+
+
+Laurie, et al.           Expires August 5, 2006                [Page 33]
+
+Internet-Draft                    nsec3                    February 2006
+
+
+   ;; Header: QR AA DO RCODE=0
+   ;;
+   ;; Question
+   y.w.example.        IN A
+
+   ;; Answer
+   ;; (empty)
+
+   ;; Authority
+   example.       3600 IN SOA ns1.example. bugs.x.w.example. (
+                              1
+                              3600
+                              300
+                              3600000
+                              3600
+                              )
+   example.       3600 IN RRSIG  SOA 5 1 3600 20050712112304 (
+                              20050612112304 62699 example.
+                              RtctD6aLUU5Md5wOOItilS7JXX1tf58Ql3sK
+                              mTXkL13jqLiUFOGg0uzqRh1U9GbydS0P7M0g
+                              qYIt90txzE/4+g== )
+   jt4bbfokgbmr57qx4nqucvvn7fmo6ab6.example. 3600 IN NSEC3  0 1 1 (
+                              deadbeaf
+                              kcll7fqfnisuhfekckeeqnmbbd4maanu
+                              NSEC3 RRSIG )
+   jt4bbfokgbmr57qx4nqucvvn7fmo6ab6.example. 3600 IN RRSIG  NSEC3 (
+                              5 2 3600 20050712112304
+                              20050612112304 62699 example.
+                              FXyCVQUdFF1EW1NcgD2V724/It0rn3lr+30V
+                              IyjmqwOMvQ4G599InTpiH46xhX3U/FmUzHOK
+                              94Zbq3k8lgdpZA== )
+
+   The query returned an NSEC3 RR that proves that the requested name
+   exists ("y.w.example." hashes to "jt4bbfokgbmr57qx4nqucvvn7fmo6ab6"),
+   but the requested RR type does not exist (Type A is absent in the
+   type-bit-maps of the NSEC3 RR).  The negative reply is authenticated
+   by verifying the NSEC3 RR.  The NSEC3 RR is authenticated in a manner
+   identical to that of the MX RRset discussed above.  Note that, unlike
+   generic empty non terminal proof using NSECs, this is identical to
+   proving a No Data Error.  This example is solely mentioned to be
+   complete.
+
+B.4.  Referral to Signed Zone
+
+   Referral to a signed zone.  The DS RR contains the data which the
+   resolver will need to validate the corresponding DNSKEY RR in the
+   child zone's apex.
+
+
+
+
+Laurie, et al.           Expires August 5, 2006                [Page 34]
+
+Internet-Draft                    nsec3                    February 2006
+
+
+   ;; Header: QR DO RCODE=0
+   ;;
+
+   ;; Question
+   mc.a.example.       IN MX
+
+   ;; Answer
+   ;; (empty)
+
+   ;; Authority
+   a.example.     3600 IN NS  ns1.a.example.
+   a.example.     3600 IN NS  ns2.a.example.
+   a.example.     3600 IN DS  58470 5 1 (
+                              3079F1593EBAD6DC121E202A8B766A6A4837
+                              206C )
+   a.example.     3600 IN RRSIG  DS 5 2 3600 20050712112304 (
+                              20050612112304 62699 example.
+                              QavhbsSmEvJLSUzGoTpsV3SKXCpaL1UO3Ehn
+                              cB0ObBIlex/Zs9kJyG/9uW1cYYt/1wvgzmX2
+                              0kx7rGKTc3RQDA== )
+
+   ;; Additional
+   ns1.a.example. 3600 IN A   192.0.2.5
+   ns2.a.example. 3600 IN A   192.0.2.6
+
+   The query returned a referral to the signed "a.example." zone.  The
+   DS RR is authenticated in a manner identical to that of the MX RRset
+   discussed above.  This DS RR is used to authenticate the "a.example"
+   DNSKEY RRset.
+
+   Once the "a.example" DS RRset has been authenticated using the
+   "example" DNSKEY, the resolver checks the "a.example" DNSKEY RRset
+   for some "a.example" DNSKEY RR that matches the DS RR.  If such a
+   matching "a.example" DNSKEY is found, the resolver checks whether
+   this DNSKEY RR has signed the "a.example" DNSKEY RRset and whether
+   the signature lifetime is valid.  If all these conditions are met,
+   all keys in the "a.example" DNSKEY RRset are considered
+   authenticated.
+
+B.5.  Referral to Unsigned Zone using the Opt-In Flag
+
+   The NSEC3 RR proves that nothing for this delegation was signed in
+   the parent zone.  There is no proof that the delegation exists
+
+
+
+
+
+
+
+
+Laurie, et al.           Expires August 5, 2006                [Page 35]
+
+Internet-Draft                    nsec3                    February 2006
+
+
+   ;; Header: QR DO RCODE=0
+   ;;
+   ;; Question
+   mc.b.example.       IN MX
+
+   ;; Answer
+   ;; (empty)
+
+   ;; Authority
+   b.example.     3600 IN NS  ns1.b.example.
+   b.example.     3600 IN NS  ns2.b.example.
+   kcll7fqfnisuhfekckeeqnmbbd4maanu.example. 3600 IN NSEC3  1 1 1 (
+                              deadbeaf
+                              n42hbhnjj333xdxeybycax5ufvntux5d
+                              MX NSEC3 RRSIG )
+   kcll7fqfnisuhfekckeeqnmbbd4maanu.example. 3600 IN RRSIG  NSEC3 (
+                              5 2 3600 20050712112304
+                              20050612112304 62699 example.
+                              d0g8MTOvVwByOAIwvYV9JrTHwJof1VhnMKuA
+                              IBj6Xaeney86RBZYgg7Qyt9WnQSK3uCEeNpx
+                              TOLtc5jPrkL4zQ== )
+
+   ;; Additional
+   ns1.b.example. 3600 IN A   192.0.2.7
+   ns2.b.example. 3600 IN A   192.0.2.8
+
+   The query returned a referral to the unsigned "b.example." zone.  The
+   NSEC3 proves that no authentication leads from "example" to
+   "b.example", since the hash of "b.example"
+   ("ldjpfcucebeks5azmzpty4qlel4cftzo") is within the NSEC3 interval and
+   the NSEC3 opt-in bit is set.  The NSEC3 RR is authenticated in a
+   manner identical to that of the MX RRset discussed above.
+
+B.6.  Wildcard Expansion
+
+   A successful query that was answered via wildcard expansion.  The
+   label count in the answer's RRSIG RR indicates that a wildcard RRset
+   was expanded to produce this response, and the NSEC3 RR proves that
+   no closer match exists in the zone.
+
+
+
+
+
+
+
+
+
+
+
+
+Laurie, et al.           Expires August 5, 2006                [Page 36]
+
+Internet-Draft                    nsec3                    February 2006
+
+
+   ;; Header: QR AA DO RCODE=0
+   ;;
+   ;; Question
+   a.z.w.example.      IN MX
+
+   ;; Answer
+   a.z.w.example. 3600 IN MX  1 ai.example.
+   a.z.w.example. 3600 IN RRSIG  MX 5 3 3600 20050712112304 (
+                              20050612112304 62699 example.
+                              sYNUPHn1/gJ87wTHNksGdRm3vfnSFa2BbofF
+                              xGfJLF5A4deRu5f0hvxhAFDCcXfIASj7z0wQ
+                              gQlgxEwhvQDEaQ== )
+   ;; Authority
+   example.       3600 NS     ns1.example.
+   example.       3600 NS     ns2.example.
+   example.       3600 IN RRSIG  NS 5 1 3600 20050712112304 (
+                              20050612112304 62699 example.
+                              hNyyin2JpECIFxW4vsj8RhHcWCQKUXgO+z4l
+                              m7g2zM8q3Qpsm/gYIXSF2Rhj6lAG7esR/X9d
+                              1SH5r/wfjuCg+g== )
+   zjxfz5o7t4ty4u3f6fa7mhhqzjln4mui.example. 3600 IN NSEC3  0 1 1 (
+                              deadbeaf
+                              5pe7ctl7pfs2cilroy5dcofx4rcnlypd
+                              MX NSEC3 RRSIG )
+   zjxfz5o7t4ty4u3f6fa7mhhqzjln4mui.example. 3600 IN RRSIG  NSEC3 (
+                              5 2 3600 20050712112304
+                              20050612112304 62699 example.
+                              eULkdWjcjmM+wXQcr7zXNfnGLgHjZSJINGkt
+                              7Zmvp7WKVAqoHMm1RXV8IfBH1aRgv5+/Lgny
+                              OcFlrPGPMm48/A== )
+   ;; Additional
+   ai.example.    3600 IN A   192.0.2.9
+   ai.example.    3600 IN RRSIG  A 5 2 3600 20050712112304 (
+                              20050612112304 62699 example.
+                              plY5M26ED3Owe3YX0pBIhgg44j89NxUaoBrU
+                              6bLRr99HpKfFl1sIy18JiRS7evlxCETZgubq
+                              ZXW5S+1VjMZYzQ== )
+   ai.example.    3600 AAAA   2001:db8::f00:baa9
+   ai.example.    3600 IN RRSIG  AAAA 5 2 3600 20050712112304 (
+                              20050612112304 62699 example.
+                              PNF/t7+DeosEjhfuL0kmsNJvn16qhYyLI9FV
+                              ypSCorFx/PKIlEL3syomkYM2zcXVSRwUXMns
+                              l5/UqLCJJ9BDMg== )
+
+   The query returned an answer that was produced as a result of
+   wildcard expansion.  The answer section contains a wildcard RRset
+   expanded as it would be in a traditional DNS response, and the
+   corresponding RRSIG indicates that the expanded wildcard MX RRset was
+
+
+
+Laurie, et al.           Expires August 5, 2006                [Page 37]
+
+Internet-Draft                    nsec3                    February 2006
+
+
+   signed by an "example" DNSKEY with algorithm 5 and key tag 62699.
+   The RRSIG indicates that the original TTL of the MX RRset was 3600,
+   and, for the purpose of authentication, the current TTL is replaced
+   by 3600.  The RRSIG labels field value of 2 indicates that the answer
+   is the result of wildcard expansion, as the "a.z.w.example" name
+   contains 4 labels.  The name "a.z.w.example" is replaced by
+   "*.w.example", the MX RRset is placed in canonical form, and,
+   assuming that the current time falls between the signature inception
+   and expiration dates, the signature is authenticated.
+
+   The NSEC3 proves that no closer match (exact or closer wildcard)
+   could have been used to answer this query, and the NSEC3 RR must also
+   be authenticated before the answer is considered valid.
+
+B.7.  Wildcard No Data Error
+
+   A "no data" response for a name covered by a wildcard.  The NSEC3 RRs
+   prove that the matching wildcard name does not have any RRs of the
+   requested type and that no closer match exists in the zone.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Laurie, et al.           Expires August 5, 2006                [Page 38]
+
+Internet-Draft                    nsec3                    February 2006
+
+
+   ;; Header: QR AA DO RCODE=0
+   ;;
+   ;; Question
+   a.z.w.example.      IN AAAA
+
+   ;; Answer
+   ;; (empty)
+
+   ;; Authority
+   example.       3600 IN SOA ns1.example. bugs.x.w.example. (
+                              1
+                              3600
+                              300
+                              3600000
+                              3600
+                              )
+   example.       3600 IN RRSIG  SOA 5 1 3600 20050712112304 (
+                              20050612112304 62699 example.
+                              RtctD6aLUU5Md5wOOItilS7JXX1tf58Ql3sK
+                              mTXkL13jqLiUFOGg0uzqRh1U9GbydS0P7M0g
+                              qYIt90txzE/4+g== )
+   zjxfz5o7t4ty4u3f6fa7mhhqzjln4mui.example. 3600 IN NSEC3  0 1 1 (
+                              deadbeaf
+                              5pe7ctl7pfs2cilroy5dcofx4rcnlypd
+                              MX NSEC3 RRSIG )
+   zjxfz5o7t4ty4u3f6fa7mhhqzjln4mui.example. 3600 IN RRSIG  NSEC3 (
+                              5 2 3600 20050712112304
+                              20050612112304 62699 example.
+                              eULkdWjcjmM+wXQcr7zXNfnGLgHjZSJINGkt
+                              7Zmvp7WKVAqoHMm1RXV8IfBH1aRgv5+/Lgny
+                              OcFlrPGPMm48/A== )
+   ;; Additional
+   ;; (empty)
+
+   The query returned NSEC3 RRs that prove that the requested data does
+   not exist and no wildcard applies.  The negative reply is
+   authenticated by verifying both NSEC3 RRs.
+
+B.8.  DS Child Zone No Data Error
+
+   A "no data" response for a QTYPE=DS query that was mistakenly sent to
+   a name server for the child zone.
+
+
+
+
+
+
+
+
+
+Laurie, et al.           Expires August 5, 2006                [Page 39]
+
+Internet-Draft                    nsec3                    February 2006
+
+
+   ;; Header: QR AA DO RCODE=0
+   ;;
+   ;; Question
+   example.            IN DS
+
+   ;; Answer
+   ;; (empty)
+
+   ;; Authority
+   example.       3600 IN SOA ns1.example. bugs.x.w.example. (
+                              1
+                              3600
+                              300
+                              3600000
+                              3600
+                              )
+   example.       3600 IN RRSIG  SOA 5 1 3600 20050712112304 (
+                              20050612112304 62699 example.
+                              RtctD6aLUU5Md5wOOItilS7JXX1tf58Ql3sK
+                              mTXkL13jqLiUFOGg0uzqRh1U9GbydS0P7M0g
+                              qYIt90txzE/4+g== )
+   dw4o7j64wnel3j4jh7fb3c5n7w3js2yb.example. 3600 IN NSEC3  0 1 1 (
+                              deadbeaf
+                              gmnfcccja7wkax3iv26bs75myptje3qk
+                              MX DNSKEY NS SOA NSEC3 RRSIG )
+   dw4o7j64wnel3j4jh7fb3c5n7w3js2yb.example. 3600 IN RRSIG  NSEC3 (
+                              5 2 3600 20050712112304
+                              20050612112304 62699 example.
+                              VqEbXiZLJVYmo25fmO3IuHkAX155y8NuA50D
+                              C0NmJV/D4R3rLm6tsL6HB3a3f6IBw6kKEa2R
+                              MOiKMSHozVebqw== )
+
+   ;; Additional
+   ;; (empty)
+
+   The query returned NSEC RRs that shows the requested was answered by
+   a child server ("example" server).  The NSEC RR indicates the
+   presence of an SOA RR, showing that the answer is from the child .
+   Queries for the "example" DS RRset should be sent to the parent
+   servers ("root" servers).
+
+
+
+
+
+
+
+
+
+
+
+Laurie, et al.           Expires August 5, 2006                [Page 40]
+
+Internet-Draft                    nsec3                    February 2006
+
+
+Authors' Addresses
+
+   Ben Laurie
+   Nominet
+   17 Perryn Road
+   London  W3 7LR
+   England
+
+   Phone: +44 (20) 8735 0686
+   Email: ben@algroup.co.uk
+
+
+   Geoffrey Sisson
+   Nominet
+
+
+   Roy Arends
+   Nominet
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Laurie, et al.           Expires August 5, 2006                [Page 41]
+
+Internet-Draft                    nsec3                    February 2006
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2006).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Laurie, et al.           Expires August 5, 2006                [Page 42]
+
diff --git a/doc/draft/draft-ietf-dnsext-nsid-01.txt b/doc/draft/draft-ietf-dnsext-nsid-01.txt
new file mode 100644
index 0000000..90d1a06
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsext-nsid-01.txt
@@ -0,0 +1,840 @@
+
+
+
+Network Working Group                                         R. Austein
+Internet-Draft                                                       ISC
+Expires: July 15, 2006                                  January 11, 2006
+
+
+                DNS Name Server Identifier Option (NSID)
+                       draft-ietf-dnsext-nsid-01
+
+Status of this Memo
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   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 draft documents 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 "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/ietf/1id-abstracts.txt.
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+   This Internet-Draft will expire on July 15, 2006.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   With the increased use of DNS anycast, load balancing, and other
+   mechanisms allowing more than one DNS name server to share a single
+   IP address, it is sometimes difficult to tell which of a pool of name
+   servers has answered a particular query.  While existing ad-hoc
+   mechanism allow an operator to send follow-up queries when it is
+   necessary to debug such a configuration, the only completely reliable
+   way to obtain the identity of the name server which responded is to
+   have the name server include this information in the response itself.
+   This note defines a protocol extension to support this functionality.
+
+
+
+Austein                   Expires July 15, 2006                 [Page 1]
+
+Internet-Draft                  DNS NSID                    January 2006
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+     1.1.  Reserved Words . . . . . . . . . . . . . . . . . . . . . .  3
+   2.  Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
+     2.1.  Resolver Behavior  . . . . . . . . . . . . . . . . . . . .  4
+     2.2.  Name Server Behavior . . . . . . . . . . . . . . . . . . .  4
+     2.3.  The NSID Option  . . . . . . . . . . . . . . . . . . . . .  4
+     2.4.  Presentation Format  . . . . . . . . . . . . . . . . . . .  5
+   3.  Discussion . . . . . . . . . . . . . . . . . . . . . . . . . .  6
+     3.1.  The NSID Payload . . . . . . . . . . . . . . . . . . . . .  6
+     3.2.  NSID Is Not Transitive . . . . . . . . . . . . . . . . . .  8
+     3.3.  User Interface Issues  . . . . . . . . . . . . . . . . . .  8
+     3.4.  Truncation . . . . . . . . . . . . . . . . . . . . . . . .  9
+   4.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
+   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
+   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
+   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
+     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 13
+     7.2.  Informative References . . . . . . . . . . . . . . . . . . 13
+   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14
+   Intellectual Property and Copyright Statements . . . . . . . . . . 15
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Austein                   Expires July 15, 2006                 [Page 2]
+
+Internet-Draft                  DNS NSID                    January 2006
+
+
+1.  Introduction
+
+   With the increased use of DNS anycast, load balancing, and other
+   mechanisms allowing more than one DNS name server to share a single
+   IP address, it is sometimes difficult to tell which of a pool of name
+   servers has answered a particular query.
+
+   Existing ad-hoc mechanisms allow an operator to send follow-up
+   queries when it is necessary to debug such a configuration, but there
+   are situations in which this is not a totally satisfactory solution,
+   since anycast routing may have changed, or the server pool in
+   question may be behind some kind of extremely dynamic load balancing
+   hardware.  Thus, while these ad-hoc mechanisms are certainly better
+   than nothing (and have the advantage of already being deployed), a
+   better solution seems desirable.
+
+   Given that a DNS query is an idempotent operation with no retained
+   state, it would appear that the only completely reliable way to
+   obtain the identity of the name server which responded to a
+   particular query is to have that name server include identifying
+   information in the response itself.  This note defines a protocol
+   enhancement to achieve this.
+
+1.1.  Reserved Words
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC2119].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Austein                   Expires July 15, 2006                 [Page 3]
+
+Internet-Draft                  DNS NSID                    January 2006
+
+
+2.  Protocol
+
+   This note uses an EDNS [RFC2671] option to signal the resolver's
+   desire for information identifying the name server and to hold the
+   name server's response, if any.
+
+2.1.  Resolver Behavior
+
+   A resolver signals its desire for information identifying a name
+   server by sending an empty NSID option (Section 2.3) in an EDNS OPT
+   pseudo-RR in the query message.
+
+   The resolver MUST NOT include any NSID payload data in the query
+   message.
+
+   The semantics of an NSID request are not transitive.  That is: the
+   presence of an NSID option in a query is a request that the name
+   server which receives the query identify itself.  If the name server
+   side of a recursive name server receives an NSID request, the client
+   is asking the recursive name server to identify itself; if the
+   resolver side of the recursive name server wishes to receive
+   identifying information, it is free to add NSID requests in its own
+   queries, but that is a separate matter.
+
+2.2.  Name Server Behavior
+
+   A name server which understands the NSID option and chooses to honor
+   a particular NSID request responds by including identifying
+   information in a NSID option (Section 2.3) in an EDNS OPT pseudo-RR
+   in the response message.
+
+   The name server MUST ignore any NSID payload data that might be
+   present in the query message.
+
+   The NSID option is not transitive.  A name server MUST NOT send an
+   NSID option back to a resolver which did not request it.  In
+   particular, while a recursive name server may choose to add an NSID
+   option when sending a query, this has no effect on the presence or
+   absence of the NSID option in the recursive name server's response to
+   the original client.
+
+   As stated in Section 2.1, this mechanism is not restricted to
+   authoritative name servers; the semantics are intended to be equally
+   applicable to recursive name servers.
+
+2.3.  The NSID Option
+
+   The OPTION-CODE for the NSID option is [TBD].
+
+
+
+Austein                   Expires July 15, 2006                 [Page 4]
+
+Internet-Draft                  DNS NSID                    January 2006
+
+
+   The OPTION-DATA for the NSID option is an opaque byte string the
+   semantics of which are deliberately left outside the protocol.  See
+   Section 3.1 for discussion.
+
+2.4.  Presentation Format
+
+   User interfaces MUST read and write the content of the NSID option as
+   a sequence of hexadecimal digits, two digits per payload octet.
+
+   The NSID payload is binary data.  Any comparison between NSID
+   payloads MUST be a comparison of the raw binary data.  Copy
+   operations MUST NOT assume that the raw NSID payload is null-
+   terminated.  Any resemblance between raw NSID payload data and any
+   form of text is purely a convenience, and does not change the
+   underlying nature of the payload data.
+
+   See Section 3.3 for discussion.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Austein                   Expires July 15, 2006                 [Page 5]
+
+Internet-Draft                  DNS NSID                    January 2006
+
+
+3.  Discussion
+
+   This section discusses certain aspects of the protocol and explains
+   considerations that led to the chosen design.
+
+3.1.  The NSID Payload
+
+   The syntax and semantics of the content of the NSID option is
+   deliberately left outside the scope of this specification.  This
+   section describe some of the kinds of data that server administrators
+   might choose to provide as the content of the NSID option, and
+   explains the reasoning behind choosing a simple opaque byte string.
+
+   There are several possibilities for the payload of the NSID option:
+
+   o  It could be the "real" name of the specific name server within the
+      name server pool.
+
+   o  It could be the "real" IP address (IPv4 or IPv6) of the name
+      server within the name server pool.
+
+   o  It could be some sort of pseudo-random number generated in a
+      predictable fashion somehow using the server's IP address or name
+      as a seed value.
+
+   o  It could be some sort of probabilisticly unique identifier
+      initially derived from some sort of random number generator then
+      preserved across reboots of the name server.
+
+   o  It could be some sort of dynamicly generated identifier so that
+      only the name server operator could tell whether or not any two
+      queries had been answered by the same server.
+
+   o  It could be a blob of signed data, with a corresponding key which
+      might (or might not) be available via DNS lookups.
+
+   o  It could be a blob of encrypted data, the key for which could be
+      restricted to parties with a need to know (in the opinion of the
+      server operator).
+
+   o  It could be an arbitrary string of octets chosen at the discretion
+      of the name server operator.
+
+   Each of these options has advantages and disadvantages:
+
+   o  Using the "real" name is simple, but the name server may not have
+      a "real" name.
+
+
+
+
+Austein                   Expires July 15, 2006                 [Page 6]
+
+Internet-Draft                  DNS NSID                    January 2006
+
+
+   o  Using the "real" address is also simple, and the name server
+      almost certainly does have at least one non-anycast IP address for
+      maintenance operations, but the operator of the name server may
+      not be willing to divulge its non-anycast address.
+
+   o  Given that one common reason for using anycast DNS techniques is
+      an attempt to harden a critical name server against denial of
+      service attacks, some name server operators are likely to want an
+      identifier other than the "real" name or "real" address of the
+      name server instance.
+
+   o  Using a hash or pseudo-random number can provide a fixed length
+      value that the resolver can use to tell two name servers apart
+      without necessarily being able to tell where either one of them
+      "really" is, but makes debugging more difficult if one happens to
+      be in a friendly open environment.  Furthermore, hashing might not
+      add much value, since a hash based on an IPv4 address still only
+      involves a 32-bit search space, and DNS names used for servers
+      that operators might have to debug at 4am tend not to be very
+      random.
+
+   o  Probabilisticly unique identifiers have similar properties to
+      hashed identifiers, but (given a sufficiently good random number
+      generator) are immune to the search space issues.  However, the
+      strength of this approach is also its weakness: there is no
+      algorithmic transformation by which even the server operator can
+      associate name server instances with identifiers while debugging,
+      which might be annoying.  This approach also requires the name
+      server instance to preserve the probabilisticly unique identifier
+      across reboots, but this does not appear to be a serious
+      restriction, since authoritative nameservers almost always have
+      some form of nonvolatile storage in any case, and in the rare case
+      of a name server that does not have any way to store such an
+      identifier, nothing terrible will happen if the name server just
+      generates a new identifier every time it reboots.
+
+   o  Using an arbitrary octet string gives name server operators yet
+      another thing to configure, or mis-configure, or forget to
+      configure.  Having all the nodes in an anycast name server
+      constellation identify themselves as "My Name Server" would not be
+      particularly useful.
+
+   Given all of the issues listed above, there does not appear to be a
+   single solution that will meet all needs.  Section 2.3 therefore
+   defines the NSID payload to be an opaque byte string and leaves the
+   choice up to the implementor and name server operator.  The following
+   guidelines may be useful to implementors and server operators:
+
+
+
+
+Austein                   Expires July 15, 2006                 [Page 7]
+
+Internet-Draft                  DNS NSID                    January 2006
+
+
+   o  Operators for whom divulging the unicast address is an issue could
+      use the raw binary representation of a probabilisticly unique
+      random number.  This should probably be the default implementation
+      behavior.
+
+   o  Operators for whom divulging the unicast address is not an issue
+      could just use the raw binary representation of a unicast address
+      for simplicity.  This should only be done via an explicit
+      configuration choice by the operator.
+
+   o  Operators who really need or want the ability to set the NSID
+      payload to an arbitrary value could do so, but this should only be
+      done via an explicit configuration choice by the operator.
+
+   This approach appears to provide enough information for useful
+   debugging without unintentionally leaking the maintenance addresses
+   of anycast name servers to nogoodniks, while also allowing name
+   server operators who do not find such leakage threatening to provide
+   more information at their own discretion.
+
+3.2.  NSID Is Not Transitive
+
+   As specified in Section 2.1 and Section 2.2, the NSID option is not
+   transitive.  This is strictly a hop-by-hop mechanism.
+
+   Most of the discussion of name server identification to date has
+   focused on identifying authoritative name servers, since the best
+   known cases of anycast name servers are a subset of the name servers
+   for the root zone.  However, given that anycast DNS techniques are
+   also applicable to recursive name servers, the mechanism may also be
+   useful with recursive name servers.  The hop-by-hop semantics support
+   this.
+
+   While there might be some utility in having a transitive variant of
+   this mechanism (so that, for example, a stub resolver could ask a
+   recursive server to tell it which authoritative name server provided
+   a particular answer to the recursive name server), the semantics of
+   such a variant would be more complicated, and are left for future
+   work.
+
+3.3.  User Interface Issues
+
+   Given the range of possible payload contents described in
+   Section 3.1, it is not possible to define a single presentation
+   format for the NSID payload that is efficient, convenient,
+   unambiguous, and aesthetically pleasing.  In particular, while it is
+   tempting to use a presentation format that uses some form of textual
+   strings, attempting to support this would significantly complicate
+
+
+
+Austein                   Expires July 15, 2006                 [Page 8]
+
+Internet-Draft                  DNS NSID                    January 2006
+
+
+   what's intended to be a very simple debugging mechanism.
+
+   In some cases the content of the NSID payload may be binary data
+   meaningful only to the name server operator, and may not be
+   meaningful to the user or application, but the user or application
+   must be able to capture the entire content anyway in order for it to
+   be useful.  Thus, the presentation format must support arbitrary
+   binary data.
+
+   In cases where the name server operator derives the NSID payload from
+   textual data, a textual form such as US-ASCII or UTF-8 strings might
+   at first glance seem easier for a user to deal with.  There are,
+   however, a number of complex issues involving internationalized text
+   which, if fully addressed here, would require a set of rules
+   significantly longer than the rest of this specification.  See
+   [RFC2277] for an overview of some of these issues.
+
+   It is much more important for the NSID payload data to be passed
+   unambiguously from server administrator to user and back again than
+   it is for the payload data data to be pretty while in transit.  In
+   particular, it's critical that it be straightforward for a user to
+   cut and paste an exact copy of the NSID payload output by a debugging
+   tool into other formats such as email messages or web forms without
+   distortion.  Hexadecimal strings, while ugly, are also robust.
+
+3.4.  Truncation
+
+   In some cases, adding the NSID option to a response message may
+   trigger message truncation.  This specification does not change the
+   rules for DNS message truncation in any way, but implementors will
+   need to pay attention to this issue.
+
+   Including the NSID option in a response is always optional, so this
+   specification never requires name servers to truncate response
+   messages.
+
+   By definition, a resolver that requests NSID responses also supports
+   EDNS, so a resolver that requests NSID responses can also use the
+   "sender's UDP payload size" field of the OPT pseudo-RR to signal a
+   receive buffer size large enough to make truncation unlikely.
+
+
+
+
+
+
+
+
+
+
+
+Austein                   Expires July 15, 2006                 [Page 9]
+
+Internet-Draft                  DNS NSID                    January 2006
+
+
+4.  IANA Considerations
+
+   This mechanism requires allocation of one ENDS option code for the
+   NSID option (Section 2.3).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Austein                   Expires July 15, 2006                [Page 10]
+
+Internet-Draft                  DNS NSID                    January 2006
+
+
+5.  Security Considerations
+
+   This document describes a channel signaling mechanism, intended
+   primarily for debugging.  Channel signaling mechanisms are outside
+   the scope of DNSSEC per se.  Applications that require integrity
+   protection for the data being signaled will need to use a channel
+   security mechanism such as TSIG [RFC2845].
+
+   Section 3.1 discusses a number of different kinds of information that
+   a name server operator might choose to provide as the value of the
+   NSID option.  Some of these kinds of information are security
+   sensitive in some environments.  This specification deliberately
+   leaves the syntax and semantics of the NSID option content up to the
+   implementation and the name server operator.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Austein                   Expires July 15, 2006                [Page 11]
+
+Internet-Draft                  DNS NSID                    January 2006
+
+
+6.  Acknowledgements
+
+   Joe Abley, Harald Alvestrand, Mark Andrews, Roy Arends, Steve
+   Bellovin, Randy Bush, David Conrad, Johan Ihren, Daniel Karrenberg,
+   Peter Koch, Mike Patton, Mike StJohns, Paul Vixie, Sam Weiler, and
+   Suzanne Woolf.  Apologies to anyone inadvertently omitted from the
+   above list.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Austein                   Expires July 15, 2006                [Page 12]
+
+Internet-Draft                  DNS NSID                    January 2006
+
+
+7.  References
+
+7.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", RFC 2119, BCP 14, March 1997.
+
+   [RFC2671]  Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
+              RFC 2671, August 1999.
+
+   [RFC2845]  Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.
+              Wellington, "Secret Key Transaction Authentication for DNS
+              (TSIG)", RFC 2845, May 2000.
+
+7.2.  Informative References
+
+   [RFC2277]  Alvestrand, H., "IETF Policy on Character Sets and
+              Languages", RFC 2277, BCP 18, January 1998.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Austein                   Expires July 15, 2006                [Page 13]
+
+Internet-Draft                  DNS NSID                    January 2006
+
+
+Author's Address
+
+   Rob Austein
+   ISC
+   950 Charter Street
+   Redwood City, CA  94063
+   USA
+
+   Email: sra@isc.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Austein                   Expires July 15, 2006                [Page 14]
+
+Internet-Draft                  DNS NSID                    January 2006
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2006).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Austein                   Expires July 15, 2006                [Page 15]
+
diff --git a/doc/draft/draft-ietf-dnsext-rfc2536bis-dsa-06.txt b/doc/draft/draft-ietf-dnsext-rfc2536bis-dsa-06.txt
new file mode 100644
index 0000000..5b6d655
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsext-rfc2536bis-dsa-06.txt
@@ -0,0 +1,464 @@
+
+INTERNET-DRAFT                                DSA Information in the DNS
+OBSOLETES: RFC 2536                               Donald E. Eastlake 3rd
+                                                   Motorola Laboratories
+Expires: January 2006                                          July 2005
+
+
+            DSA Keying and Signature Information in the DNS
+            --- ------ --- --------- ----------- -- --- ---
+               <draft-ietf-dnsext-rfc2536bis-dsa-06.txt>
+                         Donald E. Eastlake 3rd
+
+
+Status of This Document
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   Distribution of this document is unlimited. Comments should be sent
+   to the DNS extensions working group mailing list
+   <namedroppers@ops.ietf.org>.
+
+   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 draft documents 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 a "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/1id-abstracts.html
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html
+
+
+Abstract
+
+   The standard method of encoding US Government Digital Signature
+   Algorithm keying and signature information for use in the Domain Name
+   System is specified.
+
+
+Copyright Notice
+
+   Copyright (C) The Internet Society 2005. All Rights Reserved.
+
+
+
+
+
+D. Eastlake 3rd                                                 [Page 1]
+
+
+INTERNET-DRAFT                                DSA Information in the DNS
+
+
+Table of Contents
+
+      Status of This Document....................................1
+      Abstract...................................................1
+      Copyright Notice...........................................1
+
+      Table of Contents..........................................2
+
+      1. Introduction............................................3
+      2. DSA Keying Information..................................3
+      3. DSA Signature Information...............................4
+      4. Performance Considerations..............................4
+      5. Security Considerations.................................5
+      6. IANA Considerations.....................................5
+      Copyright and Disclaimer...................................5
+
+      Normative References.......................................7
+      Informative References.....................................7
+
+      Authors Address............................................8
+      Expiration and File Name...................................8
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+D. Eastlake 3rd                                                 [Page 2]
+
+
+INTERNET-DRAFT                                DSA Information in the DNS
+
+
+1. Introduction
+
+   The Domain Name System (DNS) is the global hierarchical replicated
+   distributed database system for Internet addressing, mail proxy, and
+   other information [RFC 1034, 1035]. The DNS has been extended to
+   include digital signatures and cryptographic keys as described in
+   [RFC 4033, 4034, 4035] and additional work is underway which would
+   require the storage of keying and signature information in the DNS.
+
+   This document describes how to encode US Government Digital Signature
+   Algorithm (DSA) keys and signatures in the DNS.  Familiarity with the
+   US Digital Signature Algorithm is assumed [FIPS 186-2, Schneier].
+
+
+
+2. DSA Keying Information
+
+   When DSA public keys are stored in the DNS, the structure of the
+   relevant part of the RDATA part of the RR being used is the fields
+   listed below in the order given.
+
+   The period of key validity is not included in this data but is
+   indicated separately, for example by an RR such as RRSIG which signs
+   and authenticates the RR containing the keying information.
+
+        Field     Size
+        -----     ----
+         T         1  octet
+         Q        20  octets
+         P        64 + T*8  octets
+         G        64 + T*8  octets
+         Y        64 + T*8  octets
+
+   As described in [FIPS 186-2] and [Schneier], T is a key size
+   parameter chosen such that 0 <= T <= 8.  (The meaning if the T octet
+   is greater than 8 is reserved and the remainder of the data may have
+   a different format in that case.)  Q is a prime number selected at
+   key generation time such that 2**159 < Q < 2**160. Thus Q is always
+   20 octets long and, as with all other fields, is stored in "big-
+   endian" network order.  P, G, and Y are calculated as directed by the
+   [FIPS 186-2] key generation algorithm [Schneier].  P is in the range
+   2**(511+64T) < P < 2**(512+64T) and thus is 64 + 8*T octets long.  G
+   and Y are quantities modulo P and so can be up to the same length as
+   P and are allocated fixed size fields with the same number of octets
+   as P.
+
+   During the key generation process, a random number X must be
+   generated such that 1 <= X <= Q-1.  X is the private key and is used
+   in the final step of public key generation where Y is computed as
+
+
+
+D. Eastlake 3rd                                                 [Page 3]
+
+
+INTERNET-DRAFT                                DSA Information in the DNS
+
+
+        Y = G**X mod P
+
+
+
+3. DSA Signature Information
+
+   The portion of the RDATA area used for US Digital Signature Algorithm
+   signature information is shown below with fields in the order they
+   are listed and the contents of each multi-octet field in "big-endian"
+   network order.
+
+        Field     Size
+        -----     ----
+         T         1 octet
+         R        20 octets
+         S        20 octets
+
+   First, the data signed must be determined.  Then the following steps
+   are taken, as specified in [FIPS 186-2], where Q, P, G, and Y are as
+   specified in the public key [Schneier]:
+
+        hash = SHA-1 ( data )
+
+        Generate a random K such that 0 < K < Q.
+
+        R = ( G**K mod P ) mod Q
+
+        S = ( K**(-1) * (hash + X*R) ) mod Q
+
+   For information on the SHA-1 hash function see [FIPS 180-2] and [RFC
+   3174].
+
+   Since Q is 160 bits long, R and S can not be larger than 20 octets,
+   which is the space allocated.
+
+   T is copied from the public key.  It is not logically necessary in
+   the SIG but is present so that values of T > 8 can more conveniently
+   be used as an escape for extended versions of DSA or other algorithms
+   as later standardized.
+
+
+
+4. Performance Considerations
+
+   General signature generation speeds are roughly the same for RSA [RFC
+   3110] and DSA.  With sufficient pre-computation, signature generation
+   with DSA is faster than RSA.  Key generation is also faster for DSA.
+   However, signature verification is an order of magnitude slower than
+   RSA when the RSA public exponent is chosen to be small, as is
+   recommended for some applications.
+
+
+D. Eastlake 3rd                                                 [Page 4]
+
+
+INTERNET-DRAFT                                DSA Information in the DNS
+
+
+   Current DNS implementations are optimized for small transfers,
+   typically less than 512 bytes including DNS overhead.  Larger
+   transfers will perform correctly and extensions have been
+   standardized [RFC 2671] to make larger transfers more efficient, it
+   is still advisable at this time to make reasonable efforts to
+   minimize the size of RR sets containing keying and/or signature
+   inforamtion consistent with adequate security.
+
+
+
+5. Security Considerations
+
+   Keys retrieved from the DNS should not be trusted unless (1) they
+   have been securely obtained from a secure resolver or independently
+   verified by the user and (2) this secure resolver and secure
+   obtainment or independent verification conform to security policies
+   acceptable to the user.  As with all cryptographic algorithms,
+   evaluating the necessary strength of the key is essential and
+   dependent on local policy.
+
+   The key size limitation of a maximum of 1024 bits ( T = 8 ) in the
+   current DSA standard may limit the security of DSA.  For particular
+   applications, implementors are encouraged to consider the range of
+   available algorithms and key sizes.
+
+   DSA assumes the ability to frequently generate high quality random
+   numbers.  See [random] for guidance.  DSA is designed so that if
+   biased rather than random numbers are used, high bandwidth covert
+   channels are possible.  See [Schneier] and more recent research.  The
+   leakage of an entire DSA private key in only two DSA signatures has
+   been demonstrated.  DSA provides security only if trusted
+   implementations, including trusted random number generation, are
+   used.
+
+
+
+6. IANA Considerations
+
+   Allocation of meaning to values of the T parameter that are not
+   defined herein (i.e., > 8 ) requires an IETF standards actions.  It
+   is intended that values unallocated herein be used to cover future
+   extensions of the DSS standard.
+
+
+
+Copyright and Disclaimer
+
+   Copyright (C) The Internet Society (2005).  This document is subject to
+   the rights, licenses and restrictions contained in BCP 78, and except
+   as set forth therein, the authors retain all their rights.
+
+
+D. Eastlake 3rd                                                 [Page 5]
+
+
+INTERNET-DRAFT                                DSA Information in the DNS
+
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+D. Eastlake 3rd                                                 [Page 6]
+
+
+INTERNET-DRAFT                                DSA Information in the DNS
+
+
+Normative References
+
+   [FIPS 186-2] - U.S. Federal Information Processing Standard: Digital
+   Signature Standard, 27 January 2000.
+
+   [RFC 4034] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
+   Rose, "Resource Records for the DNS Security Extensions", RFC 4034,
+   March 2005.
+
+
+
+Informative References
+
+   [RFC 1034] - "Domain names - concepts and facilities", P.
+   Mockapetris, 11/01/1987.
+
+   [RFC 1035] - "Domain names - implementation and specification", P.
+   Mockapetris, 11/01/1987.
+
+   [RFC 2671] - "Extension Mechanisms for DNS (EDNS0)", P. Vixie, August
+   1999.
+
+   [RFC 3110] - "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System
+   (DNS)", D.  Eastlake 3rd. May 2001.
+
+   [RFC 3174] - "US Secure Hash Algorithm 1 (SHA1)", D. Eastlake, P.
+   Jones, September 2001.
+
+   [RFC 4033] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
+   Rose, "DNS Security Introduction and Requirements", RFC 4033, March
+   2005.
+
+   [RFC 4035] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
+   Rose, "Protocol Modifications for the DNS Security Extensions", RFC
+   4035, March 2005.
+
+   [RFC 4086] - Eastlake, D., 3rd, Schiller, J., and S. Crocker,
+   "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
+
+   [Schneier] - "Applied Cryptography Second Edition: protocols,
+   algorithms, and source code in C" (second edition), Bruce Schneier,
+   1996, John Wiley and Sons, ISBN 0-471-11709-9.
+
+
+
+
+
+
+
+
+
+
+D. Eastlake 3rd                                                 [Page 7]
+
+
+INTERNET-DRAFT                                DSA Information in the DNS
+
+
+Authors Address
+
+   Donald E. Eastlake 3rd
+   Motorola Labortories
+   155 Beaver Street
+   Milford, MA 01757 USA
+
+   Telephone:   +1-508-786-7554(w)
+   EMail:       Donald.Eastlake@motorola.com
+
+
+
+Expiration and File Name
+
+   This draft expires in January 2006.
+
+   Its file name is draft-ietf-dnsext-rfc2536bis-dsa-06.txt.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+D. Eastlake 3rd                                                 [Page 8]
+
diff --git a/doc/draft/draft-ietf-dnsext-rfc2538bis-04.txt b/doc/draft/draft-ietf-dnsext-rfc2538bis-04.txt
new file mode 100644
index 0000000..2ec9dbe
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsext-rfc2538bis-04.txt
@@ -0,0 +1,840 @@
+
+
+
+Network Working Group                                       S. Josefsson
+Internet-Draft                                           August 30, 2005
+Expires: March 3, 2006
+
+
+          Storing Certificates in the Domain Name System (DNS)
+                    draft-ietf-dnsext-rfc2538bis-04
+
+Status of this Memo
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   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 draft documents 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 "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/ietf/1id-abstracts.txt.
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+   This Internet-Draft will expire on March 3, 2006.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).
+
+Abstract
+
+   Cryptographic public keys are frequently published and their
+   authenticity demonstrated by certificates.  A CERT resource record
+   (RR) is defined so that such certificates and related certificate
+   revocation lists can be stored in the Domain Name System (DNS).
+
+   This document obsoletes RFC 2538.
+
+
+
+
+
+
+Josefsson                 Expires March 3, 2006                 [Page 1]
+
+Internet-Draft       Storing Certificates in the DNS         August 2005
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   2.  The CERT Resource Record . . . . . . . . . . . . . . . . . . .  3
+     2.1.  Certificate Type Values  . . . . . . . . . . . . . . . . .  4
+     2.2.  Text Representation of CERT RRs  . . . . . . . . . . . . .  5
+     2.3.  X.509 OIDs . . . . . . . . . . . . . . . . . . . . . . . .  6
+   3.  Appropriate Owner Names for CERT RRs . . . . . . . . . . . . .  6
+     3.1.  Content-based X.509 CERT RR Names  . . . . . . . . . . . .  7
+     3.2.  Purpose-based X.509 CERT RR Names  . . . . . . . . . . . .  8
+     3.3.  Content-based OpenPGP CERT RR Names  . . . . . . . . . . .  9
+     3.4.  Purpose-based OpenPGP CERT RR Names  . . . . . . . . . . .  9
+     3.5.  Owner names for IPKIX, ISPKI, and IPGP . . . . . . . . . .  9
+   4.  Performance Considerations . . . . . . . . . . . . . . . . . . 10
+   5.  Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 10
+   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
+   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
+   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 11
+   9.  Changes since RFC 2538 . . . . . . . . . . . . . . . . . . . . 11
+   Appendix A.  Copying conditions  . . . . . . . . . . . . . . . . . 12
+   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
+     10.1. Normative References . . . . . . . . . . . . . . . . . . . 12
+     10.2. Informative References . . . . . . . . . . . . . . . . . . 13
+   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14
+   Intellectual Property and Copyright Statements . . . . . . . . . . 15
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Josefsson                 Expires March 3, 2006                 [Page 2]
+
+Internet-Draft       Storing Certificates in the DNS         August 2005
+
+
+1.  Introduction
+
+   Public keys are frequently published in the form of a certificate and
+   their authenticity is commonly demonstrated by certificates and
+   related certificate revocation lists (CRLs).  A certificate is a
+   binding, through a cryptographic digital signature, of a public key,
+   a validity interval and/or conditions, and identity, authorization,
+   or other information.  A certificate revocation list is a list of
+   certificates that are revoked, and incidental information, all signed
+   by the signer (issuer) of the revoked certificates.  Examples are
+   X.509 certificates/CRLs in the X.500 directory system or OpenPGP
+   certificates/revocations used by OpenPGP software.
+
+   Section 2 below specifies a CERT resource record (RR) for the storage
+   of certificates in the Domain Name System [1] [2].
+
+   Section 3 discusses appropriate owner names for CERT RRs.
+
+   Sections 4, 5, and 6 below cover performance, IANA, and security
+   considerations, respectively.
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [3].
+
+
+2.  The CERT Resource Record
+
+   The CERT resource record (RR) has the structure given below.  Its RR
+   type code is 37.
+
+                       1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
+   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |             type              |             key tag           |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |   algorithm   |                                               /
+   +---------------+            certificate or CRL                 /
+   /                                                               /
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
+
+   The type field is the certificate type as defined in section 2.1
+   below.
+
+   The key tag field is the 16 bit value computed for the key embedded
+   in the certificate, using the RRSIG Key Tag algorithm described in
+   Appendix B of [10].  This field is used as an efficiency measure to
+   pick which CERT RRs may be applicable to a particular key.  The key
+
+
+
+Josefsson                 Expires March 3, 2006                 [Page 3]
+
+Internet-Draft       Storing Certificates in the DNS         August 2005
+
+
+   tag can be calculated for the key in question and then only CERT RRs
+   with the same key tag need be examined.  However, the key must always
+   be transformed to the format it would have as the public key portion
+   of a DNSKEY RR before the key tag is computed.  This is only possible
+   if the key is applicable to an algorithm (and limits such as key size
+   limits) defined for DNS security.  If it is not, the algorithm field
+   MUST BE zero and the tag field is meaningless and SHOULD BE zero.
+
+   The algorithm field has the same meaning as the algorithm field in
+   DNSKEY and RRSIG RRs [10], except that a zero algorithm field
+   indicates the algorithm is unknown to a secure DNS, which may simply
+   be the result of the algorithm not having been standardized for
+   DNSSEC.
+
+2.1.  Certificate Type Values
+
+   The following values are defined or reserved:
+
+       Value  Mnemonic  Certificate Type
+       -----  --------  ----------------
+           0            reserved
+           1  PKIX      X.509 as per PKIX
+           2  SPKI      SPKI certificate
+           3  PGP       OpenPGP packet
+           4  IPKIX     The URL of an X.509 data object
+           5  ISPKI     The URL of an SPKI certificate
+           6  IPGP      The URL of an OpenPGP packet
+       7-252            available for IANA assignment
+         253  URI       URI private
+         254  OID       OID private
+   255-65534            available for IANA assignment
+       65535            reserved
+
+   The PKIX type is reserved to indicate an X.509 certificate conforming
+   to the profile being defined by the IETF PKIX working group.  The
+   certificate section will start with a one-byte unsigned OID length
+   and then an X.500 OID indicating the nature of the remainder of the
+   certificate section (see 2.3 below).  (NOTE: X.509 certificates do
+   not include their X.500 directory type designating OID as a prefix.)
+
+   The SPKI type is reserved to indicate the SPKI certificate format
+   [13], for use when the SPKI documents are moved from experimental
+   status.
+
+   The PGP type indicates an OpenPGP packet as described in [6] and its
+   extensions and successors.  Two uses are to transfer public key
+   material and revocation signatures.  The data is binary, and MUST NOT
+   be encoded into an ASCII armor.  An implementation SHOULD process
+
+
+
+Josefsson                 Expires March 3, 2006                 [Page 4]
+
+Internet-Draft       Storing Certificates in the DNS         August 2005
+
+
+   transferable public keys as described in section 10.1 of [6], but it
+   MAY handle additional OpenPGP packets.
+
+   The IPKIX, ISPKI and IPGP types indicate a URL which will serve the
+   content that would have been in the "certificate, CRL or URL" field
+   of the corresponding (PKIX, SPKI or PGP) packet types.  These types
+   are known as "indirect".  These packet types MUST be used when the
+   content is too large to fit in the CERT RR, and MAY be used at the
+   implementer's discretion.  They SHOULD NOT be used where the entire
+   UDP packet would have fit in 512 bytes.
+
+   The URI private type indicates a certificate format defined by an
+   absolute URI.  The certificate portion of the CERT RR MUST begin with
+   a null terminated URI [5] and the data after the null is the private
+   format certificate itself.  The URI SHOULD be such that a retrieval
+   from it will lead to documentation on the format of the certificate.
+   Recognition of private certificate types need not be based on URI
+   equality but can use various forms of pattern matching so that, for
+   example, subtype or version information can also be encoded into the
+   URI.
+
+   The OID private type indicates a private format certificate specified
+   by an ISO OID prefix.  The certificate section will start with a one-
+   byte unsigned OID length and then a BER encoded OID indicating the
+   nature of the remainder of the certificate section.  This can be an
+   X.509 certificate format or some other format.  X.509 certificates
+   that conform to the IETF PKIX profile SHOULD be indicated by the PKIX
+   type, not the OID private type.  Recognition of private certificate
+   types need not be based on OID equality but can use various forms of
+   pattern matching such as OID prefix.
+
+2.2.  Text Representation of CERT RRs
+
+   The RDATA portion of a CERT RR has the type field as an unsigned
+   decimal integer or as a mnemonic symbol as listed in section 2.1
+   above.
+
+   The key tag field is represented as an unsigned decimal integer.
+
+   The algorithm field is represented as an unsigned decimal integer or
+   a mnemonic symbol as listed in [10].
+
+   The certificate / CRL portion is represented in base 64 [14] and may
+   be divided up into any number of white space separated substrings,
+   down to single base 64 digits, which are concatenated to obtain the
+   full signature.  These substrings can span lines using the standard
+   parenthesis.
+
+
+
+
+Josefsson                 Expires March 3, 2006                 [Page 5]
+
+Internet-Draft       Storing Certificates in the DNS         August 2005
+
+
+   Note that the certificate / CRL portion may have internal sub-fields,
+   but these do not appear in the master file representation.  For
+   example, with type 254, there will be an OID size, an OID, and then
+   the certificate / CRL proper.  But only a single logical base 64
+   string will appear in the text representation.
+
+2.3.  X.509 OIDs
+
+   OIDs have been defined in connection with the X.500 directory for
+   user certificates, certification authority certificates, revocations
+   of certification authority, and revocations of user certificates.
+   The following table lists the OIDs, their BER encoding, and their
+   length-prefixed hex format for use in CERT RRs:
+
+       id-at-userCertificate
+           = { joint-iso-ccitt(2) ds(5) at(4) 36 }
+              == 0x 03 55 04 24
+       id-at-cACertificate
+           = { joint-iso-ccitt(2) ds(5) at(4) 37 }
+              == 0x 03 55 04 25
+       id-at-authorityRevocationList
+           = { joint-iso-ccitt(2) ds(5) at(4) 38 }
+              == 0x 03 55 04 26
+       id-at-certificateRevocationList
+           = { joint-iso-ccitt(2) ds(5) at(4) 39 }
+              == 0x 03 55 04 27
+
+
+3.  Appropriate Owner Names for CERT RRs
+
+   It is recommended that certificate CERT RRs be stored under a domain
+   name related to their subject, i.e., the name of the entity intended
+   to control the private key corresponding to the public key being
+   certified.  It is recommended that certificate revocation list CERT
+   RRs be stored under a domain name related to their issuer.
+
+   Following some of the guidelines below may result in the use in DNS
+   names of characters that require DNS quoting which is to use a
+   backslash followed by the octal representation of the ASCII code for
+   the character (e.g., \000 for NULL).
+
+   The choice of name under which CERT RRs are stored is important to
+   clients that perform CERT queries.  In some situations, the clients
+   may not know all information about the CERT RR object it wishes to
+   retrieve.  For example, a client may not know the subject name of an
+   X.509 certificate, or the e-mail address of the owner of an OpenPGP
+   key.  Further, the client might only know the hostname of a service
+   that uses X.509 certificates or the Key ID of an OpenPGP key.
+
+
+
+Josefsson                 Expires March 3, 2006                 [Page 6]
+
+Internet-Draft       Storing Certificates in the DNS         August 2005
+
+
+   Therefore, two owner name guidelines are defined: content-based owner
+   names and purpose-based owner names.  A content-based owner name is
+   derived from the content of the CERT RR data; for example, the
+   Subject field in an X.509 certificate or the User ID field in OpenPGP
+   keys.  A purpose-based owner name is a name that a client retrieving
+   CERT RRs MUST already know; for example, the host name of an X.509
+   protected service or the Key ID of an OpenPGP key.  The content-based
+   and purpose-based owner name MAY be the same; for example, when a
+   client looks up a key based on the From: address of an incoming
+   e-mail.
+
+   Implementations SHOULD use the purpose-based owner name guidelines
+   described in this document, and MAY use CNAMEs of content-based owner
+   names (or other names), pointing to the purpose-based owner name.
+
+3.1.  Content-based X.509 CERT RR Names
+
+   Some X.509 versions permit multiple names to be associated with
+   subjects and issuers under "Subject Alternate Name" and "Issuer
+   Alternate Name".  For example, X.509v3 has such Alternate Names with
+   an ASN.1 specification as follows:
+
+        GeneralName ::= CHOICE {
+           otherName                  [0] INSTANCE OF OTHER-NAME,
+           rfc822Name                 [1] IA5String,
+           dNSName                    [2] IA5String,
+           x400Address                [3] EXPLICIT OR-ADDRESS.&Type,
+           directoryName              [4] EXPLICIT Name,
+           ediPartyName               [5] EDIPartyName,
+           uniformResourceIdentifier  [6] IA5String,
+           iPAddress                  [7] OCTET STRING,
+           registeredID               [8] OBJECT IDENTIFIER
+        }
+
+   The recommended locations of CERT storage are as follows, in priority
+   order:
+   1.  If a domain name is included in the identification in the
+       certificate or CRL, that should be used.
+   2.  If a domain name is not included but an IP address is included,
+       then the translation of that IP address into the appropriate
+       inverse domain name should be used.
+   3.  If neither of the above is used, but a URI containing a domain
+       name is present, that domain name should be used.
+   4.  If none of the above is included but a character string name is
+       included, then it should be treated as described for OpenPGP
+       names below.
+
+
+
+
+
+Josefsson                 Expires March 3, 2006                 [Page 7]
+
+Internet-Draft       Storing Certificates in the DNS         August 2005
+
+
+   5.  If none of the above apply, then the distinguished name (DN)
+       should be mapped into a domain name as specified in [4].
+
+   Example 1: An X.509v3 certificate is issued to /CN=John Doe /DC=Doe/
+   DC=com/DC=xy/O=Doe Inc/C=XY/ with Subject Alternative Names of (a)
+   string "John (the Man) Doe", (b) domain name john-doe.com, and (c)
+   uri <https://www.secure.john-doe.com:8080/>.  The storage locations
+   recommended, in priority order, would be
+   1.  john-doe.com,
+   2.  www.secure.john-doe.com, and
+   3.  Doe.com.xy.
+
+   Example 2: An X.509v3 certificate is issued to /CN=James Hacker/
+   L=Basingstoke/O=Widget Inc/C=GB/ with Subject Alternate names of (a)
+   domain name widget.foo.example, (b) IPv4 address 10.251.13.201, and
+   (c) string "James Hacker <hacker@mail.widget.foo.example>".  The
+   storage locations recommended, in priority order, would be
+   1.  widget.foo.example,
+   2.  201.13.251.10.in-addr.arpa, and
+   3.  hacker.mail.widget.foo.example.
+
+3.2.  Purpose-based X.509 CERT RR Names
+
+   Due to the difficulty for clients that do not already possess a
+   certificate to reconstruct the content-based owner name, purpose-
+   based owner names are recommended in this section.  Recommendations
+   for purpose-based owner names vary per scenario.  The following table
+   summarizes the purpose-based X.509 CERT RR owner name guidelines for
+   use with S/MIME [16], SSL/TLS [11], and IPSEC [12]:
+
+    Scenario             Owner name
+    ------------------   ----------------------------------------------
+    S/MIME Certificate   Standard translation of an RFC 2822 email
+                         address.  Example: An S/MIME certificate for
+                         "postmaster@example.org" will use a standard
+                         hostname translation of the owner name,
+                         "postmaster.example.org".
+
+    TLS Certificate      Hostname of the TLS server.
+
+    IPSEC Certificate    Hostname of the IPSEC machine and/or, for IPv4
+                         or IPv6 addresses, the fully qualified domain
+                         name in the appropriate reverse domain.
+
+   An alternate approach for IPSEC is to store raw public keys [15].
+
+
+
+
+
+
+Josefsson                 Expires March 3, 2006                 [Page 8]
+
+Internet-Draft       Storing Certificates in the DNS         August 2005
+
+
+3.3.  Content-based OpenPGP CERT RR Names
+
+   OpenPGP signed keys (certificates) use a general character string
+   User ID [6].  However, it is recommended by OpenPGP that such names
+   include the RFC 2822 [8] email address of the party, as in "Leslie
+   Example <Leslie@host.example>".  If such a format is used, the CERT
+   should be under the standard translation of the email address into a
+   domain name, which would be leslie.host.example in this case.  If no
+   RFC 2822 name can be extracted from the string name, no specific
+   domain name is recommended.
+
+   If a user has more than one email address, the CNAME type can be used
+   to reduce the amount of data stored in the DNS.  Example:
+
+      $ORIGIN example.org.
+      smith        IN CERT PGP 0 0 <OpenPGP binary>
+      john.smith   IN CNAME smith
+      js           IN CNAME smith
+
+3.4.  Purpose-based OpenPGP CERT RR Names
+
+   Applications that receive an OpenPGP packet containing encrypted or
+   signed data but do not know the email address of the sender will have
+   difficulties constructing the correct owner name and cannot use the
+   content-based owner name guidelines.  However, these clients commonly
+   know the key fingerprint or the Key ID.  The key ID is found in
+   OpenPGP packets, and the key fingerprint is commonly found in
+   auxilliary data that may be available.  In this case, use of an owner
+   name identical to the key fingerprint and the key ID expressed in
+   hexadecimal [14] is recommended.  Example:
+
+      $ORIGIN example.org.
+      0424D4EE81A0E3D119C6F835EDA21E94B565716F IN CERT PGP ...
+      F835EDA21E94B565716F                     IN CERT PGP ...
+      B565716F                                 IN CERT PGP ...
+
+   If the same key material is stored for several owner names, the use
+   of CNAME may be used to avoid data duplication.  Note that CNAME is
+   not always applicable, because it maps one owner name to the other
+   for all purposes, which may be sub-optimal when two keys with the
+   same Key ID are stored.
+
+3.5.  Owner names for IPKIX, ISPKI, and IPGP
+
+   These types are stored under the same owner names, both purpose- and
+   content-based, as the PKIX, SPKI and PGP types.
+
+
+
+
+
+Josefsson                 Expires March 3, 2006                 [Page 9]
+
+Internet-Draft       Storing Certificates in the DNS         August 2005
+
+
+4.  Performance Considerations
+
+   Current Domain Name System (DNS) implementations are optimized for
+   small transfers, typically not more than 512 bytes including
+   overhead.  While larger transfers will perform correctly and work is
+   underway to make larger transfers more efficient, it is still
+   advisable at this time to make every reasonable effort to minimize
+   the size of certificates stored within the DNS.  Steps that can be
+   taken may include using the fewest possible optional or extension
+   fields and using short field values for necessary variable length
+   fields.
+
+   The RDATA field in the DNS protocol may only hold data of size 65535
+   octets (64kb) or less.  This means that each CERT RR MUST NOT contain
+   more than 64kb of payload, even if the corresponding certificate or
+   certificate revocation list is larger.  This document addresses this
+   by defining "indirect" data types for each normal type.
+
+
+5.  Contributors
+
+   The majority of this document is copied verbatim from RFC 2538, by
+   Donald Eastlake 3rd and Olafur Gudmundsson.
+
+
+6.  Acknowledgements
+
+   Thanks to David Shaw and Michael Graff for their contributions to
+   earlier works that motivated, and served as inspiration for, this
+   document.
+
+   This document was improved by suggestions and comments from Olivier
+   Dubuisson, Olaf M. Kolkman, Ben Laurie, Edward Lewis, Jason
+   Sloderbeck, Samuel Weiler, and Florian Weimer.  No doubt the list is
+   incomplete.  We apologize to anyone we left out.
+
+
+7.  Security Considerations
+
+   By definition, certificates contain their own authenticating
+   signature.  Thus, it is reasonable to store certificates in non-
+   secure DNS zones or to retrieve certificates from DNS with DNS
+   security checking not implemented or deferred for efficiency.  The
+   results MAY be trusted if the certificate chain is verified back to a
+   known trusted key and this conforms with the user's security policy.
+
+   Alternatively, if certificates are retrieved from a secure DNS zone
+   with DNS security checking enabled and are verified by DNS security,
+
+
+
+Josefsson                 Expires March 3, 2006                [Page 10]
+
+Internet-Draft       Storing Certificates in the DNS         August 2005
+
+
+   the key within the retrieved certificate MAY be trusted without
+   verifying the certificate chain if this conforms with the user's
+   security policy.
+
+   If an organization chooses to issue certificates for it's employees,
+   placing CERT RR's in the DNS by owner name, and if DNSSEC (with NSEC)
+   is in use, it is possible for someone to enumerate all employees of
+   the organization.  This is usually not considered desirable, for the
+   same reason enterprise phone listings are not often publicly
+   published and are even mark confidential.
+
+   When the URI type is used, it should be understood that it introduces
+   an additional indirection that may allow for a new attack vector.
+   One method to secure that indirection is to include a hash of the
+   certificate in the URI itself.
+
+   CERT RRs are not used by DNSSEC [9], so there are no security
+   considerations related to CERT RRs and securing the DNS itself.
+
+   If DNSSEC is used, then the non-existence of a CERT RR and,
+   consequently, certificates or revocation lists can be securely
+   asserted.  Without DNSSEC, this is not possible.
+
+
+8.  IANA Considerations
+
+   Certificate types 0x0000 through 0x00FF and 0xFF00 through 0xFFFF can
+   only be assigned by an IETF standards action [7].  This document
+   assigns 0x0001 through 0x0006 and 0x00FD and 0x00FE.  Certificate
+   types 0x0100 through 0xFEFF are assigned through IETF Consensus [7]
+   based on RFC documentation of the certificate type.  The availability
+   of private types under 0x00FD and 0x00FE should satisfy most
+   requirements for proprietary or private types.
+
+   The CERT RR reuses the DNS Security Algorithm Numbers registry.  In
+   particular, the CERT RR requires that algorithm number 0 remain
+   reserved, as described in Section 2.  The IANA is directed to
+   reference the CERT RR as a user of this registry and value 0, in
+   particular.
+
+
+9.  Changes since RFC 2538
+
+   1.   Editorial changes to conform with new document requirements,
+        including splitting reference section into two parts and
+        updating the references to point at latest versions, and to add
+        some additional references.
+
+
+
+
+Josefsson                 Expires March 3, 2006                [Page 11]
+
+Internet-Draft       Storing Certificates in the DNS         August 2005
+
+
+   2.   Improve terminology.  For example replace "PGP" with "OpenPGP",
+        to align with RFC 2440.
+   3.   In section 2.1, clarify that OpenPGP public key data are binary,
+        not the ASCII armored format, and reference 10.1 in RFC 2440 on
+        how to deal with OpenPGP keys, and acknowledge that
+        implementations may handle additional packet types.
+   4.   Clarify that integers in the representation format are decimal.
+   5.   Replace KEY/SIG with DNSKEY/RRSIG etc, to align with DNSSECbis
+        terminology.  Improve reference for Key Tag Algorithm
+        calculations.
+   6.   Add examples that suggest use of CNAME to reduce bandwidth.
+   7.   In section 3, appended the last paragraphs that discuss
+        "content-based" vs "purpose-based" owner names.  Add section 3.2
+        for purpose-based X.509 CERT owner names, and section 3.4 for
+        purpose-based OpenPGP CERT owner names.
+   8.   Added size considerations.
+   9.   The SPKI types has been reserved, until RFC 2692/2693 is moved
+        from the experimental status.
+   10.  Added indirect types IPKIX, ISPKI, and IPGP.
+
+
+Appendix A.  Copying conditions
+
+   Regarding the portion of this document that was written by Simon
+   Josefsson ("the author", for the remainder of this section), the
+   author makes no guarantees and is not responsible for any damage
+   resulting from its use.  The author grants irrevocable permission to
+   anyone to use, modify, and distribute it in any way that does not
+   diminish the rights of anyone else to use, modify, and distribute it,
+   provided that redistributed derivative works do not contain
+   misleading author or version information.  Derivative works need not
+   be licensed under similar terms.
+
+
+10.  References
+
+10.1.  Normative References
+
+   [1]   Mockapetris, P., "Domain names - concepts and facilities",
+         STD 13, RFC 1034, November 1987.
+
+   [2]   Mockapetris, P., "Domain names - implementation and
+         specification", STD 13, RFC 1035, November 1987.
+
+   [3]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
+         Levels", BCP 14, RFC 2119, March 1997.
+
+   [4]   Kille, S., Wahl, M., Grimstad, A., Huber, R., and S. Sataluri,
+
+
+
+Josefsson                 Expires March 3, 2006                [Page 12]
+
+Internet-Draft       Storing Certificates in the DNS         August 2005
+
+
+         "Using Domains in LDAP/X.500 Distinguished Names", RFC 2247,
+         January 1998.
+
+   [5]   Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
+         Resource Identifiers (URI): Generic Syntax", RFC 2396,
+         August 1998.
+
+   [6]   Callas, J., Donnerhacke, L., Finney, H., and R. Thayer,
+         "OpenPGP Message Format", RFC 2440, November 1998.
+
+   [7]   Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
+         Considerations Section in RFCs", BCP 26, RFC 2434,
+         October 1998.
+
+   [8]   Resnick, P., "Internet Message Format", RFC 2822, April 2001.
+
+   [9]   Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+         "DNS Security Introduction and Requirements", RFC 4033,
+         March 2005.
+
+   [10]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+         "Resource Records for the DNS Security Extensions", RFC 4034,
+         March 2005.
+
+10.2.  Informative References
+
+   [11]  Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
+         RFC 2246, January 1999.
+
+   [12]  Kent, S. and R. Atkinson, "Security Architecture for the
+         Internet Protocol", RFC 2401, November 1998.
+
+   [13]  Ellison, C., Frantz, B., Lampson, B., Rivest, R., Thomas, B.,
+         and T. Ylonen, "SPKI Certificate Theory", RFC 2693,
+         September 1999.
+
+   [14]  Josefsson, S., "The Base16, Base32, and Base64 Data Encodings",
+         RFC 3548, July 2003.
+
+   [15]  Richardson, M., "A Method for Storing IPsec Keying Material in
+         DNS", RFC 4025, March 2005.
+
+   [16]  Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions
+         (S/MIME) Version 3.1 Message Specification", RFC 3851,
+         July 2004.
+
+
+
+
+
+
+Josefsson                 Expires March 3, 2006                [Page 13]
+
+Internet-Draft       Storing Certificates in the DNS         August 2005
+
+
+Author's Address
+
+   Simon Josefsson
+
+   Email: simon@josefsson.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Josefsson                 Expires March 3, 2006                [Page 14]
+
+Internet-Draft       Storing Certificates in the DNS         August 2005
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2005).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Josefsson                 Expires March 3, 2006                [Page 15]
+
diff --git a/doc/draft/draft-ietf-dnsext-rfc2539bis-dhk-06.txt b/doc/draft/draft-ietf-dnsext-rfc2539bis-dhk-06.txt
new file mode 100644
index 0000000..5e6cb1d
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsext-rfc2539bis-dhk-06.txt
@@ -0,0 +1,580 @@
+
+INTERNET-DRAFT                     Diffie-Hellman Information in the DNS
+OBSOLETES: RFC 2539                               Donald E. Eastlake 3rd
+                                                   Motorola Laboratories
+Expires: January 2006                                          July 2005
+
+
+
+
+        Storage of Diffie-Hellman Keying Information in the DNS
+        ------- -- -------------- ------ ----------- -- --- ---
+               <draft-ietf-dnsext-rfc2539bis-dhk-06.txt>
+
+
+
+Status of This Document
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   Distribution of this document is unlimited. Comments should be sent
+   to the DNS extensions working group mailing list
+   <namedroppers@ops.ietf.org>.
+
+   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 draft documents 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 a "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/1id-abstracts.html
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html
+
+
+Abstract
+
+   The standard method for encoding Diffie-Hellman keys in the Domain
+   Name System is specified.
+
+
+
+Copyright
+
+   Copyright (C) The Internet Society 2005.
+
+
+
+D. Eastlake 3rd                                                 [Page 1]
+
+
+INTERNET-DRAFT                     Diffie-Hellman Information in the DNS
+
+
+Acknowledgements
+
+   Part of the format for Diffie-Hellman keys and the description
+   thereof was taken from a work in progress by Ashar Aziz, Tom Markson,
+   and Hemma Prafullchandra.  In addition, the following persons
+   provided useful comments that were incorporated into the predecessor
+   of this document: Ran Atkinson, Thomas Narten.
+
+
+
+Table of Contents
+
+      Status of This Document....................................1
+      Abstract...................................................1
+      Copyright..................................................1
+
+      Acknowledgements...........................................2
+      Table of Contents..........................................2
+
+      1. Introduction............................................3
+      1.1 About This Document....................................3
+      1.2 About Diffie-Hellman...................................3
+      2. Encoding Diffie-Hellman Keying Information..............4
+      3. Performance Considerations..............................5
+      4. IANA Considerations.....................................5
+      5. Security Considerations.................................5
+      Copyright and Disclaimer...................................5
+
+      Normative References.......................................7
+      Informative Refences.......................................7
+
+      Author Address.............................................8
+      Expiration and File Name...................................8
+
+      Appendix A: Well known prime/generator pairs...............9
+      A.1. Well-Known Group 1:  A 768 bit prime..................9
+      A.2. Well-Known Group 2:  A 1024 bit prime.................9
+      A.3. Well-Known Group 3:  A 1536 bit prime................10
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+D. Eastlake 3rd                                                 [Page 2]
+
+
+INTERNET-DRAFT                     Diffie-Hellman Information in the DNS
+
+
+1. Introduction
+
+   The Domain Name System (DNS) is the global hierarchical replicated
+   distributed database system for Internet addressing, mail proxy, and
+   similar information [RFC 1034, 1035]. The DNS has been extended to
+   include digital signatures and cryptographic keys as described in
+   [RFC 4033, 4034, 4035] and additonal work is underway which would use
+   the storage of keying information in the DNS.
+
+
+
+1.1 About This Document
+
+   This document describes how to store Diffie-Hellman keys in the DNS.
+   Familiarity with the Diffie-Hellman key exchange algorithm is assumed
+   [Schneier, RFC 2631].
+
+
+
+1.2 About Diffie-Hellman
+
+   Diffie-Hellman requires two parties to interact to derive keying
+   information which can then be used for authentication.  Thus Diffie-
+   Hellman is inherently a key agreement algorithm. As a result, no
+   format is defined for Diffie-Hellman "signature information".  For
+   example, assume that two parties have local secrets "i" and "j".
+   Assume they each respectively calculate X and Y as follows:
+
+        X = g**i ( mod p )
+
+        Y = g**j ( mod p )
+
+   They exchange these quantities and then each calculates a Z as
+   follows:
+
+        Zi = Y**i ( mod p )
+
+        Zj = X**j ( mod p )
+
+   Zi and Zj will both be equal to g**(i*j)(mod p) and will be a shared
+   secret between the two parties that an adversary who does not know i
+   or j will not be able to learn from the exchanged messages (unless
+   the adversary can derive i or j by performing a discrete logarithm
+   mod p which is hard for strong p and g).
+
+   The private key for each party is their secret i (or j).  The public
+   key is the pair p and g, which must be the same for the parties, and
+   their individual X (or Y).
+
+   For further information about Diffie-Hellman and precautions to take
+
+
+D. Eastlake 3rd                                                 [Page 3]
+
+
+INTERNET-DRAFT                     Diffie-Hellman Information in the DNS
+
+
+   in deciding on a p and g, see [RFC 2631].
+
+
+
+2. Encoding Diffie-Hellman Keying Information
+
+   When Diffie-Hellman keys appear within the RDATA portion of a RR,
+   they are encoded as shown below.
+
+   The period of key validity is not included in this data but is
+   indicated separately, for example by an RR such as RRSIG which signs
+   and authenticates the RR containing the keying information.
+
+                            1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
+        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       |           KEY flags           |    protocol   |  algorithm=2  |
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       |     prime length (or flag)    |  prime (p) (or special)       /
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       /  prime (p)  (variable length) |       generator length        |
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       | generator (g) (variable length)                               |
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       |     public value length       | public value (variable length)/
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       /  public value (g^i mod p)    (variable length)                |
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Prime length is the length of the Diffie-Hellman prime (p) in bytes
+   if it is 16 or greater.  Prime contains the binary representation of
+   the Diffie-Hellman prime with most significant byte first (i.e., in
+   network order). If "prime length" field is 1 or 2, then the "prime"
+   field is actually an unsigned index into a table of 65,536
+   prime/generator pairs and the generator length SHOULD be zero.  See
+   Appedix A for defined table entries and Section 4 for information on
+   allocating additional table entries.  The meaning of a zero or 3
+   through 15 value for "prime length" is reserved.
+
+   Generator length is the length of the generator (g) in bytes.
+   Generator is the binary representation of generator with most
+   significant byte first.  PublicValueLen is the Length of the Public
+   Value (g**i (mod p)) in bytes.  PublicValue is the binary
+   representation of the DH public value with most significant byte
+   first.
+
+
+
+
+
+
+
+D. Eastlake 3rd                                                 [Page 4]
+
+
+INTERNET-DRAFT                     Diffie-Hellman Information in the DNS
+
+
+3. Performance Considerations
+
+   Current DNS implementations are optimized for small transfers,
+   typically less than 512 bytes including DNS overhead.  Larger
+   transfers will perform correctly and extensions have been
+   standardized [RFC 2671] to make larger transfers more efficient. But
+   it is still advisable at this time to make reasonable efforts to
+   minimize the size of RR sets containing keying information consistent
+   with adequate security.
+
+
+
+4. IANA Considerations
+
+   Assignment of meaning to Prime Lengths of 0 and 3 through 15 requires
+   an IETF consensus as defined in [RFC 2434].
+
+   Well known prime/generator pairs number 0x0000 through 0x07FF can
+   only be assigned by an IETF standards action. [RFC 2539], the
+   Proposed Standard predecessor of this document, assigned 0x0001
+   through 0x0002. This document additionally assigns 0x0003.  Pairs
+   number 0s0800 through 0xBFFF can be assigned based on RFC
+   documentation. Pairs number 0xC000 through 0xFFFF are available for
+   private use and are not centrally coordinated. Use of such private
+   pairs outside of a closed environment may result in conflicts and/or
+   security failures.
+
+
+
+5. Security Considerations
+
+   Keying information retrieved from the DNS should not be trusted
+   unless (1) it has been securely obtained from a secure resolver or
+   independently verified by the user and (2) this secure resolver and
+   secure obtainment or independent verification conform to security
+   policies acceptable to the user.  As with all cryptographic
+   algorithms, evaluating the necessary strength of the key is important
+   and dependent on security policy.
+
+   In addition, the usual Diffie-Hellman key strength considerations
+   apply. (p-1)/2 should also be prime, g should be primitive mod p, p
+   should be "large", etc. See [RFC 2631, Schneier].
+
+
+
+Copyright and Disclaimer
+
+   Copyright (C) The Internet Society (2005).  This document is subject to
+   the rights, licenses and restrictions contained in BCP 78, and except
+   as set forth therein, the authors retain all their rights.
+
+
+D. Eastlake 3rd                                                 [Page 5]
+
+
+INTERNET-DRAFT                     Diffie-Hellman Information in the DNS
+
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+D. Eastlake 3rd                                                 [Page 6]
+
+
+INTERNET-DRAFT                     Diffie-Hellman Information in the DNS
+
+
+Normative References
+
+   [RFC 2631] - "Diffie-Hellman Key Agreement Method", E. Rescorla, June
+   1999.
+
+   [RFC 2434] - "Guidelines for Writing an IANA Considerations Section
+   in RFCs", T.  Narten, H. Alvestrand, October 1998.
+
+   [RFC 4034] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
+   Rose, "Resource Records for the DNS Security Extensions", RFC 4034,
+   March 2005.
+
+
+
+Informative Refences
+
+   [RFC 1034] - "Domain names - concepts and facilities", P.
+   Mockapetris, November 1987.
+
+   [RFC 1035] - "Domain names - implementation and specification", P.
+   Mockapetris, November 1987.
+
+   [RFC 2539] - "Storage of Diffie-Hellman Keys in the Domain Name
+   System (DNS)", D. Eastlake, March 1999, obsoleted by this RFC.
+
+   [RFC 2671] - "Extension Mechanisms for DNS (EDNS0)", P. Vixie, August
+   1999.
+
+   [RFC 4033] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
+   Rose, "DNS Security Introduction and Requirements", RFC 4033, March
+   2005.
+
+   [RFC 4035] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
+   Rose, "Protocol Modifications for the DNS Security Extensions", RFC
+   4035, March 2005.
+
+   [Schneier] - Bruce Schneier, "Applied Cryptography: Protocols,
+   Algorithms, and Source Code in C" (Second Edition), 1996, John Wiley
+   and Sons.
+
+
+
+
+
+
+
+
+
+
+
+
+
+D. Eastlake 3rd                                                 [Page 7]
+
+
+INTERNET-DRAFT                     Diffie-Hellman Information in the DNS
+
+
+Author Address
+
+   Donald E. Eastlake 3rd
+   Motorola Laboratories
+   155 Beaver Street
+   Milford, MA 01757 USA
+
+   Telephone:   +1-508-786-7554
+   EMail:       Donald.Eastlake@motorola.com
+
+
+
+Expiration and File Name
+
+   This draft expires in January 2006.
+
+   Its file name is draft-ietf-dnsext-rfc2539bis-dhk-06.txt.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+D. Eastlake 3rd                                                 [Page 8]
+
+
+INTERNET-DRAFT                     Diffie-Hellman Information in the DNS
+
+
+Appendix A: Well known prime/generator pairs
+
+   These numbers are copied from the IPSEC effort where the derivation of
+   these values is more fully explained and additional information is
+   available.
+   Richard Schroeppel performed all the mathematical and computational
+   work for this appendix.
+
+
+
+A.1. Well-Known Group 1:  A 768 bit prime
+
+   The prime is 2^768 - 2^704 - 1 + 2^64 * { [2^638 pi] + 149686 }.  Its
+   decimal value is
+          155251809230070893513091813125848175563133404943451431320235
+          119490296623994910210725866945387659164244291000768028886422
+          915080371891804634263272761303128298374438082089019628850917
+          0691316593175367469551763119843371637221007210577919
+
+   Prime modulus: Length (32 bit words): 24, Data (hex):
+            FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
+            29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
+            EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
+            E485B576 625E7EC6 F44C42E9 A63A3620 FFFFFFFF FFFFFFFF
+
+   Generator: Length (32 bit words): 1, Data (hex): 2
+
+
+
+A.2. Well-Known Group 2:  A 1024 bit prime
+
+   The prime is 2^1024 - 2^960 - 1 + 2^64 * { [2^894 pi] + 129093 }.
+   Its decimal value is
+         179769313486231590770839156793787453197860296048756011706444
+         423684197180216158519368947833795864925541502180565485980503
+         646440548199239100050792877003355816639229553136239076508735
+         759914822574862575007425302077447712589550957937778424442426
+         617334727629299387668709205606050270810842907692932019128194
+         467627007
+
+   Prime modulus:  Length (32 bit words): 32, Data (hex):
+            FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
+            29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
+            EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
+            E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
+            EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381
+            FFFFFFFF FFFFFFFF
+
+   Generator: Length (32 bit words): 1, Data (hex): 2
+
+
+
+D. Eastlake 3rd                                                 [Page 9]
+
+
+INTERNET-DRAFT                     Diffie-Hellman Information in the DNS
+
+
+A.3. Well-Known Group 3:  A 1536 bit prime
+
+   The prime is 2^1536 - 2^1472 - 1 + 2^64 * { [2^1406 pi] +  741804 }.
+   Its decimal value is
+            241031242692103258855207602219756607485695054850245994265411
+            694195810883168261222889009385826134161467322714147790401219
+            650364895705058263194273070680500922306273474534107340669624
+            601458936165977404102716924945320037872943417032584377865919
+            814376319377685986952408894019557734611984354530154704374720
+            774996976375008430892633929555996888245787241299381012913029
+            459299994792636526405928464720973038494721168143446471443848
+            8520940127459844288859336526896320919633919
+
+   Prime modulus Length (32 bit words): 48, Data (hex):
+              FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
+              29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
+              EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
+              E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
+              EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE45B3D
+              C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F
+              83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
+              670C354E 4ABC9804 F1746C08 CA237327 FFFFFFFF FFFFFFFF
+
+   Generator: Length (32 bit words):  1, Data (hex): 2
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+D. Eastlake 3rd                                                [Page 10]
+
diff --git a/doc/draft/draft-ietf-dnsext-signed-nonexistence-requirements-01.txt b/doc/draft/draft-ietf-dnsext-signed-nonexistence-requirements-01.txt
new file mode 100644
index 0000000..0af13c6
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsext-signed-nonexistence-requirements-01.txt
@@ -0,0 +1,755 @@
+
+
+Network Working Group                                          B. Laurie
+Internet-Draft                                                   Nominet
+Expires: March 2, 2005                                         R. Loomis
+                                                                    SAIC
+                                                          September 2004
+
+
+
+      Requirements related to DNSSEC Signed Proof of Non-Existence
+         draft-ietf-dnsext-signed-nonexistence-requirements-01
+
+
+Status of this Memo
+
+
+   This document is an Internet-Draft and is subject to all provisions
+   of section 3 of RFC 3667.  By submitting this Internet-Draft, each
+   author represents that any applicable patent or other IPR claims of
+   which he or she is aware have been or will be disclosed, and any of
+   which he or she become aware will be disclosed, in accordance with
+   RFC 3668.
+
+
+   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 draft documents 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 "work in progress."
+
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/ietf/1id-abstracts.txt.
+
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+
+   This Internet-Draft will expire on March 2, 2005.
+
+
+Copyright Notice
+
+
+   Copyright (C) The Internet Society (2004).
+
+
+Abstract
+
+
+   DNSSEC-bis uses the NSEC record to provide authenticated denial of
+   existence of RRsets.  NSEC also has the side-effect of permitting
+   zone enumeration, even if zone transfers have been forbidden.
+   Because some see this as a problem, this document has been assembled
+   to detail the possible requirements for denial of existence A/K/A
+   signed proof of non-existence.
+
+
+
+
+Laurie & Loomis          Expires March 2, 2005                  [Page 1]
+Internet-Draft      signed-nonexistence-requirements      September 2004
+
+
+
+Table of Contents
+
+
+   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .   3
+   2.   Non-purposes . . . . . . . . . . . . . . . . . . . . . . . .   3
+   3.   Zone Enumeration . . . . . . . . . . . . . . . . . . . . . .   3
+   4.   Zone Enumeration II  . . . . . . . . . . . . . . . . . . . .   4
+   5.   Zone Enumeration III . . . . . . . . . . . . . . . . . . . .   4
+   6.   Exposure of Contents . . . . . . . . . . . . . . . . . . . .   4
+   7.   Zone Size  . . . . . . . . . . . . . . . . . . . . . . . . .   4
+   8.   Single Method  . . . . . . . . . . . . . . . . . . . . . . .   5
+   9.   Empty Non-terminals  . . . . . . . . . . . . . . . . . . . .   5
+   10.  Prevention of Precomputed Dictionary Attacks . . . . . . . .   6
+   11.  DNSSEC-Adoption and Zone-Growth Relationship . . . . . . . .   6
+   12.  Non-overlap of denial records with possible zone records . .   7
+   13.  Exposure of Private Keys . . . . . . . . . . . . . . . . . .   7
+   14.  Minimisation of Zone Signing Cost  . . . . . . . . . . . . .   8
+   15.  Minimisation of Asymmetry  . . . . . . . . . . . . . . . . .   8
+   16.  Minimisation of Client Complexity  . . . . . . . . . . . . .   8
+   17.  Completeness . . . . . . . . . . . . . . . . . . . . . . . .   8
+   18.  Purity of Namespace  . . . . . . . . . . . . . . . . . . . .   8
+   19.  Replay Attacks . . . . . . . . . . . . . . . . . . . . . . .   8
+   20.  Compatibility with NSEC  . . . . . . . . . . . . . . . . . .   8
+   21.  Compatibility with NSEC II . . . . . . . . . . . . . . . . .   9
+   22.  Compatibility with NSEC III  . . . . . . . . . . . . . . . .   9
+   23.  Coexistence with NSEC  . . . . . . . . . . . . . . . . . . .   9
+   24.  Coexistence with NSEC II . . . . . . . . . . . . . . . . . .   9
+   25.  Protocol Design  . . . . . . . . . . . . . . . . . . . . . .   9
+   26.  Process  . . . . . . . . . . . . . . . . . . . . . . . . . .   9
+   27.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . .   9
+   28.  Requirements notation  . . . . . . . . . . . . . . . . . . .   9
+   29.  Security Considerations  . . . . . . . . . . . . . . . . . .  10
+   30.  References . . . . . . . . . . . . . . . . . . . . . . . . .  10
+   30.1   Normative References . . . . . . . . . . . . . . . . . . .  10
+   30.2   Informative References . . . . . . . . . . . . . . . . . .  10
+        Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  10
+        Intellectual Property and Copyright Statements . . . . . . .  11
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Laurie & Loomis          Expires March 2, 2005                  [Page 2]
+Internet-Draft      signed-nonexistence-requirements      September 2004
+
+
+
+1.  Introduction
+
+
+   NSEC records allow trivial enumeration of zones - a situation that
+   has existed for several years but which has recently been raised as a
+   significant concern for DNSSECbis deployment in several zones.
+   Alternate proposals have been made that make zone enumeration more
+   difficult, and some previous proposals to modify DNSSEC had related
+   requirements/desirements that are relevant to the discussion.  In
+   addition the original designs for NSEC/NXT records were based on
+   working group discussions and the choices made were not always
+   documented with context and requirements-- so some of those choices
+   may need to be restated as requirements.  Overall, the working group
+   needs to better understand the requirements for denial of existence
+   (and certain other requirements related to DNSSECbis deployment) in
+   order to evaluate the proposals that may replace NSEC.
+
+
+   In the remainder of this document, "NSEC++" is used as shorthand for
+   "a denial of existence proof that will replace NSEC".  "NSECbis" has
+   also been used as shorthand for this, but we avoid that usage since
+   NSECbis will not be part of DNSSECbis and therefore there might be
+   some confusion.
+
+
+2.  Non-purposes
+
+
+   This document does not currently document the reasons why zone
+   enumeration might be "bad" from a privacy, security, business, or
+   other perspective--except insofar as those reasons result in
+   requirements.  Once the list of requirements is complete and vaguely
+   coherent, the trade-offs (reducing zone enumeration will have X cost,
+   while providing Y benefit) may be revisited.  The editors of this
+   compendium received inputs on the potential reasons why zone
+   enumeration is bad (and there was significant discussion on the
+   DNSEXT WG mailing list) but that information fell outside the scope
+   of this document.
+
+
+   Note also that this document does not assume that NSEC *must* be
+   replaced with NSEC++, if the requirements can be met through other
+   methods (e.g., "white lies" with the current NSEC).  As is stated
+   above, this document is focused on requirements collection and
+   (ideally) prioritization rather than on the actual implementation.
+
+
+3.  Zone Enumeration
+
+
+   Authenticated denial should not permit trivial zone enumeration.
+
+
+   Additional discussion:  NSEC (and NXT before it) provide a linked
+   list that could be "walked" to trivially enumerate all the signed
+   records in a zone.  This requirement is primarily (though not
+
+
+
+
+Laurie & Loomis          Expires March 2, 2005                  [Page 3]
+Internet-Draft      signed-nonexistence-requirements      September 2004
+
+
+
+   exclusively) important for zones that either are delegation-only/
+   -mostly or do not have reverse lookup (PTR) records configured, since
+   enterprises that have PTR records for all A records have already
+   provided a similar capability to enumerate the contents of DNS zones.
+
+
+   Contributor: various
+
+
+4.  Zone Enumeration II
+
+
+   Zone enumeration should be at least as difficult as it would be to
+   effect a dictionary attack using simple DNS queries to do the same in
+   an unsecured zone.
+
+
+   (Editor comment: it is not clear how to measure difficulty in this
+   case.  Some examples could be monetary cost, bandwidth, processing
+   power or some combination of these.  It has also been suggested that
+   the requirement is that the graph of difficulty of enumeration vs.
+   the fraction of the zone enumerated should be approximately the same
+   shape in the two cases)
+
+
+   Contributor: Nominet
+
+
+5.  Zone Enumeration III
+
+
+   Enumeration of a zone with random contents should computationally
+   infeasible.
+
+
+   Editor comment: this is proposed as a way of evaluating the
+   effectiveness of a proposal rather than as a requirement anyone would
+   actually have in practice.
+
+
+   Contributor: Alex Bligh
+
+
+6.  Exposure of Contents
+
+
+   NSEC++ should not expose any of the contents of the zone (apart from
+   the NSEC++ records themselves, of course).
+
+
+   Editor comment: this is a weaker requirement than prevention of
+   enumeration, but certainly any zone that satisfied this requirement
+   would also satisfy the trivial prevention of enumeration requirement.
+
+
+   Contributor: Ed Lewis
+
+
+7.  Zone Size
+
+
+   Requirement:  NSEC++ should make it possible to take precautions
+   against trivial zone size estimates.  Since not all zone owners care
+
+
+
+
+Laurie & Loomis          Expires March 2, 2005                  [Page 4]
+Internet-Draft      signed-nonexistence-requirements      September 2004
+
+
+
+   about others estimation of the size of a zone, it is not always
+   necessary to prohibit trivial estimation of the size of the zone but
+   NSEC++ should allow such measures.
+
+
+   Additional Discussion: Even with proposals based on obfuscating names
+   with hashes it is trivial to give very good estimates of the number
+   of domains in a certain zone.  Just send 10 random queries and look
+   at the range between the two hash values returned in each NSEC++.  As
+   hash output can be assumed to follow a rectangular random
+   distribution, using the mean difference between the two values, you
+   can estimate the total number of records.  It is probably sufficient
+   to look at even one NSEC++, since the two hash values should follow a
+   (I believe) Poisson distribution.
+
+
+   The concern is motivated by some wording remembered from NSEC, which
+   stated that NSEC MUST only be present for existing owner names in the
+   zone, and MUST NOT be present for non-existing owner names.  If
+   similar wording were carried over to NSEC++, introducing bogus owner
+   names in the hash chain (an otherwise simple solution to guard
+   against trivial estimates of zone size) wouldn't be allowed.
+
+
+   One simple attempt at solving this is to describe in the
+   specifications how zone signer tools can add a number of random
+   "junk" records.
+
+
+   Editor's comment: it is interesting that obfuscating names might
+   actually make it easier to estimate zone size.
+
+
+   Contributor: Simon Josefsson.
+
+
+8.  Single Method
+
+
+   Requirement:  A single NSEC++ method must be able to carry both
+   old-style denial (i.e.  plain labels) and whatever the new style
+   looks like.  Having two separate denial methods could result in
+   cornercases where one method can deny the other and vice versa.
+
+
+   Additional discussion:  This requirement can help -bis folks to a
+   smooth upgrade to -ter.  First they'd change the method while the
+   content is the same, then they can change content of the method.
+
+
+   Contributor: Roy Arends.
+
+
+9.  Empty Non-terminals
+
+
+   Requirement:  Empty-non-terminals (ENT) should remain empty.  In
+   other words, adding NSEC++ records to an existing DNS structure
+   should not cause the creation of NSEC++ records (or related records)
+
+
+
+
+Laurie & Loomis          Expires March 2, 2005                  [Page 5]
+Internet-Draft      signed-nonexistence-requirements      September 2004
+
+
+
+   at points that are otherwise ENT.
+
+
+   Additional discussion:  Currently NSEC complies with ENT requirement:
+   b.example.com NSEC a.c.example.com implies the existence of an ENT
+   with ownername c.example.com.  NSEC2 breaks that requirement, since
+   the ownername is entirely hashed causing the structure to disappear.
+   This is why EXIST was introduced.  But EXIST causes ENT to be
+   non-empty-terminals.  Next to the dissappearance of ENT, it causes
+   (some) overhead since an EXIST record needs a SIG, NSEC2 and
+   SIG(NSEC2).  DNSNR honours this requirement by hashing individual
+   labels instead of ownernames.  However this causes very long labels.
+   Truncation is a measure against very long ownernames, but that is
+   controversial.  There is a fair discussion of the validity of
+   truncation in the DNSNR draft, but that hasn't got proper review yet.
+
+
+   Contributor: Roy Arends.
+
+
+   (Editor comment: it is not clear to us that an EXIST record needs an
+   NSEC2 record, since it is a special purpose record only used for
+   denial of existence)
+
+
+10.  Prevention of Precomputed Dictionary Attacks
+
+
+   Requirement:  NSEC++ needs to provide a method to reduce the
+   effectiveness of precomputed dictionary attacks.
+
+
+   Additional Discussion:  Salt is a measure against dictionary attacks.
+   There are other possible measures (such as iterating hashes in
+   NSEC2).  The salt needs to be communicated in every response, since
+   it is needed in every verification.  Some have suggested to move the
+   salt to a special record instead of the denial record.  I think this
+   is not wise.  Response size has more priority over zone size.  An
+   extra record causes a larger response than a larger existing record.
+
+
+   Contributor: Roy Arends.
+
+
+   (Editor comment: the current version of NSEC2 also has the salt in
+   every NSEC2 record)
+
+
+11.  DNSSEC-Adoption and Zone-Growth Relationship
+
+
+   Background:  Currently with NSEC, when a delegation centric zone
+   deploys DNSSEC, the zone-size multiplies by a non-trivial factor even
+   when the DNSSEC-adoption rate of the subzones remains low--because
+   each delegation point creates at least one NSEC record and
+   corresponding signature in the parent even if the child is not
+   signed.
+
+
+
+
+
+Laurie & Loomis          Expires March 2, 2005                  [Page 6]
+Internet-Draft      signed-nonexistence-requirements      September 2004
+
+
+
+   Requirements:  A delegation-only (or delegation-mostly) zone that is
+   signed but which has no signed child zones should initially need only
+   to add SIG(SOA), DNSKEY, and SIG(DNSKEY) at the apex, along with some
+   minimal set of NSEC++ records to cover zone contents.  Further,
+   during the transition of a delegation-only zone from 0% signed
+   children to 100% signed children, the growth in the delegation-only
+   zone should be roughly proportional to the percentage of signed child
+   zones.
+
+
+   Additional Discussion: This is why DNSNR has the Authoritative Only
+   bit.  This is similar to opt-in for delegations only.  This (bit) is
+   currently the only method to help delegation-centric zone cope with
+   zone-growth due to DNSSEC adoption.  As an example, A delegation only
+   zone which deploys DNSSEC with the help of this bit, needs to add
+   SIG(SOA), DNSKEY, SIG(DNSKEY), DNSNR, SIG(DNSNR) at the apex.  No
+   more than that.
+
+
+   Contributor: Roy Arends.
+
+
+12.  Non-overlap of denial records with possible zone records
+
+
+   Requirement:  NSEC++ records should in some way be differentiated
+   from regular zone records, so that there is no possibility that a
+   record in the zone could be duplicated by a non-existence proof
+   (NSEC++) record.
+
+
+   Additional discussion:  This requirement is derived from a discussion
+   on the DNSEXT mailing list related to copyrights and domain names.
+   As was outlined there, one solution is to put NSEC++ records in a
+   separate namespace, e.g.: $ORIGIN co.uk.
+   873bcdba87401b485022b8dcd4190e3e IN NS jim.rfc1035.com ; your
+   delegation 873bcdba87401b485022b8dcd4190e3e._no IN NSEC++ 881345...
+   ; for amazon.co.uk.
+
+
+   Contributor: various
+
+
+   (Editor comment:  One of us still does not see why a conflict
+   matters.  Even if there is an apparent conflict or overlap, the
+   "conflicting" NSEC2 name _only_ appears in NSEC2 records, and the
+   other name _never_ appears in NSEC2 records.)
+
+
+13.  Exposure of Private Keys
+
+
+   Private keys associated with the public keys in the DNS should be
+   exposed as little as possible.  It is highly undesirable for private
+   keys to be distributed to nameservers, or to otherwise be available
+   in the run-time environment of nameservers.
+
+
+
+
+
+Laurie & Loomis          Expires March 2, 2005                  [Page 7]
+Internet-Draft      signed-nonexistence-requirements      September 2004
+
+
+
+   Contributors: Nominet, Olaf Kolkman, Ed Lewis
+
+
+14.  Minimisation of Zone Signing Cost
+
+
+   The additional cost of creating an NSEC++ signed zone should not
+   significantly exceed the cost of creating an ordinary signed zone.
+
+
+   Contributor: Nominet
+
+
+15.  Minimisation of Asymmetry
+
+
+   Nameservers should have to do as little additional work as necessary.
+   More precisely, it is desirable for any increase in cost incurred by
+   the nameservers to be offset by a proportionate increase in cost to
+   DNS `clients', e.g.  stub and/or `full-service' resolvers.
+
+
+   Contributor: Nominet
+
+
+16.  Minimisation of Client Complexity
+
+
+   Caching, wildcards, CNAMEs, DNAMEs should continue to work without
+   adding too much complexity at the client side.
+
+
+   Contributor: Olaf Kolkman
+
+
+17.  Completeness
+
+
+   A proof of nonexistence should be possible for all nonexistent data
+   in the zone.
+
+
+   Contributor: Olaf Kolkman
+
+
+18.  Purity of Namespace
+
+
+   The name space should not be muddied with fake names or data sets.
+
+
+   Contributor: Ed Lewis
+
+
+19.  Replay Attacks
+
+
+   NSEC++ should not allow a replay to be used to deny existence of an
+   RR that actually exists.
+
+
+   Contributor: Ed Lewis
+
+
+20.  Compatibility with NSEC
+
+
+   NSEC++ should not introduce changes incompatible with NSEC.
+
+
+
+
+Laurie & Loomis          Expires March 2, 2005                  [Page 8]
+Internet-Draft      signed-nonexistence-requirements      September 2004
+
+
+
+   Contributor: Ed Lewis
+
+
+21.  Compatibility with NSEC II
+
+
+   NSEC++ should differ from NSEC in a way that is transparent to the
+   resolver or validator.
+
+
+   Contributor: Ed Lewis
+
+
+22.  Compatibility with NSEC III
+
+
+   NSEC++ should differ from NSEC as little as possible whilst achieving
+   other requirements.
+
+
+   Contributor: Alex Bligh
+
+
+23.  Coexistence with NSEC
+
+
+   NSEC++ should be optional, allowing NSEC to be used instead.
+
+
+   Contributor: Ed Lewis, Alex Bligh
+
+
+24.  Coexistence with NSEC II
+
+
+   NSEC++ should not impose extra work on those content with NSEC.
+
+
+   Contributor: Ed Lewis
+
+
+25.  Protocol Design
+
+
+   A good security protocol would allow signing the nonexistence of some
+   selected names without revealing anything about other names.
+
+
+   Contributor: Dan Bernstein
+
+
+26.  Process
+
+
+   Clearly not all of these requirements can be met.  Therefore the next
+   phase of this document will be to either prioritise them or narrow
+   them down to a non-contradictory set, which should then allow us to
+   judge proposals on the basis of their fit.
+
+
+27.  Acknowledgements
+
+
+28.  Requirements notation
+
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+
+
+
+
+Laurie & Loomis          Expires March 2, 2005                  [Page 9]
+Internet-Draft      signed-nonexistence-requirements      September 2004
+
+
+
+   document are to be interpreted as            described in [RFC2119].
+
+
+29.  Security Considerations
+
+
+   There are currently no security considerations called out in this
+   draft.  There will be security considerations in the choice of which
+   requirements will be implemented, but there are no specific security
+   requirements during the requirements collection process.
+
+
+30.  References
+
+
+30.1  Normative References
+
+
+   [dnssecbis-protocol]
+              "DNSSECbis Protocol Definitions", BCP XX, RFC XXXX, Some
+              Month 2004.
+
+
+30.2  Informative References
+
+
+   [RFC2026]  Bradner, S., "The Internet Standards Process -- Revision
+              3", BCP 9, RFC 2026, October 1996.
+
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+
+   [RFC2418]  Bradner, S., "IETF Working Group Guidelines and
+              Procedures", BCP 25, RFC 2418, September 1998.
+
+
+
+Authors' Addresses
+
+
+   Ben Laurie
+   Nominet
+   17 Perryn Road
+   London  W3 7LR
+   England
+
+
+   Phone: +44 (20) 8735 0686
+   EMail: ben@algroup.co.uk
+
+
+
+   Rip Loomis
+   Science Applications International Corporation
+   7125 Columbia Gateway Drive, Suite 300
+   Columbia, MD  21046
+   US
+
+
+   EMail: gilbert.r.loomis@saic.com
+
+
+
+
+Laurie & Loomis          Expires March 2, 2005                 [Page 10]
+Internet-Draft      signed-nonexistence-requirements      September 2004
+
+
+
+Intellectual Property Statement
+
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+
+Disclaimer of Validity
+
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+
+Copyright Statement
+
+
+   Copyright (C) The Internet Society (2004).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+
+Acknowledgment
+
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+Laurie & Loomis          Expires March 2, 2005                 [Page 11]
\ No newline at end of file
diff --git a/doc/draft/draft-ietf-dnsext-tkey-renewal-mode-05.txt b/doc/draft/draft-ietf-dnsext-tkey-renewal-mode-05.txt
new file mode 100644
index 0000000..9c73c68
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsext-tkey-renewal-mode-05.txt
@@ -0,0 +1,1292 @@
+
+
+
+
+
+DNS Extensions                                              Yuji Kamite
+Internet-Draft                                       NTT Communications
+Expires: April 15, 2005                                 Masaya Nakayama
+                                                The University of Tokyo
+                                                       October 14, 2004
+
+
+
+                      TKEY Secret Key Renewal Mode
+                 draft-ietf-dnsext-tkey-renewal-mode-05
+
+
+Status of this Memo
+
+   This document is an Internet-Draft and is subject to all provisions
+   of section 3 of RFC 3667.  By submitting this Internet-Draft, each
+   author represents that any applicable patent or other IPR claims of
+   which he or she is aware have been or will be disclosed, and any of
+   which he or she become aware will be disclosed, in accordance with
+   RFC 3668.
+
+   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 draft documents 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 "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/ietf/1id-abstracts.txt.
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+   This Internet-Draft will expire on April 15, 2005.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2004).
+
+Abstract
+
+   This document defines a new mode in TKEY and proposes an atomic
+   method for changing secret keys used for TSIG periodically.
+   Originally, TKEY provides methods of setting up shared secrets other
+
+
+
+Kamite, et. al.          Expires April 15, 2005                 [Page 1]
+
+INTERNET-DRAFT                                              October 2004
+
+
+   than manual exchange, but it cannot control timing of key renewal
+   very well though it can add or delete shared keys separately. This
+   proposal is a systematical key renewal procedure intended for
+   preventing signing DNS messages with old and non-safe keys
+   permanently.
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+     1.1   Defined Words  . . . . . . . . . . . . . . . . . . . . . .  3
+     1.2   New Format and Assigned Numbers  . . . . . . . . . . . . .  4
+     1.3   Overview of Secret Key Renewal Mode  . . . . . . . . . . .  4
+   2.  Shared Secret Key Renewal  . . . . . . . . . . . . . . . . . .  5
+     2.1   Key Usage Time Check . . . . . . . . . . . . . . . . . . .  5
+     2.2   Partial Revocation . . . . . . . . . . . . . . . . . . . .  6
+     2.3   Key Renewal Message Exchange . . . . . . . . . . . . . . .  7
+       2.3.1   Query for Key Renewal  . . . . . . . . . . . . . . . .  7
+       2.3.2   Response for Key Renewal . . . . . . . . . . . . . . .  7
+       2.3.3   Attributes of Generated Key  . . . . . . . . . . . . .  8
+       2.3.4   TKEY RR structure  . . . . . . . . . . . . . . . . . .  8
+     2.4   Key Adoption . . . . . . . . . . . . . . . . . . . . . . . 10
+       2.4.1   Query for Key Adoption . . . . . . . . . . . . . . . . 10
+       2.4.2   Response for Key Adoption  . . . . . . . . . . . . . . 10
+     2.5   Keying Schemes . . . . . . . . . . . . . . . . . . . . . . 11
+       2.5.1   DH Exchange for Key Renewal  . . . . . . . . . . . . . 11
+       2.5.2   Server Assigned Keying for Key Renewal . . . . . . . . 12
+       2.5.3   Resolver Assigned Keying for Key Renewal . . . . . . . 13
+     2.6   Considerations about Non-compliant Hosts . . . . . . . . . 14
+   3.  Secret Storage . . . . . . . . . . . . . . . . . . . . . . . . 15
+   4.  Compulsory Key Revocation  . . . . . . . . . . . . . . . . . . 15
+     4.1   Compulsory Key Revocation by Server  . . . . . . . . . . . 15
+     4.2   Authentication Methods Considerations  . . . . . . . . . . 15
+   5.  Special Considerations for Two Servers' Case   . . . . . . . . 16
+     5.1   To Cope with Collisions of Renewal Requests  . . . . . . . 16
+   6.  Key Name Considerations  . . . . . . . . . . . . . . . . . . . 17
+   7.  Example Usage of Secret Key Renewal Mode   . . . . . . . . . . 17
+   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 20
+   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 20
+  10.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
+  11.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
+    11.1   Normative References . . . . . . . . . . . . . . . . . . . 21
+    11.2   Informative References . . . . . . . . . . . . . . . . . . 21
+       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 22
+       Intellectual Property and Copyright Statements . . . . . . . . 23
+
+
+
+
+
+
+
+Kamite, et. al.          Expires April 15, 2005                 [Page 2]
+
+INTERNET-DRAFT                                              October 2004
+
+
+1.  Introduction
+
+   TSIG [RFC2845] provides DNS message integrity and the
+   request/transaction authentication by means of message authentication
+   codes (MAC). TSIG is a practical solution in view of calculation
+   speed and availability. However, TSIG does not have exchanging
+   mechanism of shared secret keys between server and resolver, and
+   administrators might have to exchange secret keys manually. TKEY
+   [RFC2930] is introduced to solve such problem and it can exchange
+   secrets for TSIG via networks.
+
+   In various modes of TKEY, a server and a resolver can add or delete a
+   secret key be means of TKEY message exchange. However, the existing
+   TKEY does not care fully about the management of keys which became
+   too old, or dangerous after long time usage.
+
+   It is ideal that the number of secret which a pair of hosts share
+   should be limited only one, because having too many keys for the same
+   purpose might not only be a burden to resolvers for managing and
+   distinguishing according to servers to query, but also does not seem
+   to be safe in terms of storage and protection against attackers.
+   Moreover, perhaps holding old keys long time might give attackers
+   chances to compromise by scrupulous calculation.
+
+   Therefore, when a new shared secret is established by TKEY, the
+   previous old secret should be revoked immediately. To accomplish
+   this, DNS servers must support a protocol for key renewal. This
+   document specifies procedure to refresh secret keys between two hosts
+   which is defined within the framework of TKEY, and it is called "TKEY
+   Secret Key Renewal Mode".
+
+   The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "MAY" and
+   "OPTIONAL" in this document are to be interpreted as described in
+   [RFC2119].
+
+
+1.1.  Defined Words
+
+   * Inception Time: Beginning of the shared secret key lifetime. This
+   value is determined when the key is generated.
+
+   * Expiry Limit: Time limit of the key's validity. This value is
+   determined when a new key is generated. After Expiry Limit, server
+   and client (resolver) must not authenticate TSIG signed with the key.
+   Therefore, Renewal to the next key should be carried out before
+   Expiry Limit.
+
+   * Partial Revocation Time: Time when server judges the key is too old
+
+
+
+Kamite, et. al.          Expires April 15, 2005                 [Page 3]
+
+INTERNET-DRAFT                                              October 2004
+
+
+   and must be updated. It must be between Inception Time and Expiry
+   Limit.  This value is determined by server freely following its
+   security policy. e.g., If the time from Inception to Partial
+   Revocation is short, renewal will be carried out more often, which
+   might be safer.
+
+   * Revocation Time: Time when the key becomes invalid and can be
+   removed. This value is not determined in advance because it is the
+   actual time when revocation is completed.
+
+   * Adoption Time: Time when the new key is adopted as the next key
+   formally. After Adoption, the key is valid and server and client can
+   generate or verify TSIG making use of it. Adoption Time also means
+   the time when it becomes possible to remove the previous key, so
+   Revocation and Adoption are usually done at the same time.
+
+
+                  Partial
+    Inception     Revocation    Revocation         Expiry Limit
+     |                |              |             |
+     |----------------|- - - - - - >>|- (revoked) -|
+     |                |              |             |
+    previous key      |      |       |
+                             |- - - -|-------------------->> time
+                             |       |               new key
+                         Inception   Adoption
+
+
+1.2.  New Format and Assigned Numbers
+
+   TSIG
+         ERROR = (PartialRevoke), TBD
+
+   TKEY
+         Mode  = (server assignment for key renewal), TBD
+         Mode  = (Diffie-Hellman exchange for key renewal), TBD
+         Mode  = (resolver assignment for key renewal), TBD
+         Mode  = (key adoption), TBD
+
+
+1.3.  Overview of Secret Key Renewal Mode
+
+   When a server receives a query from a client signed with a TSIG key,
+   It always checks if the present time is within the range of usage
+   duration it considers safe. If it is judged that the key is too old,
+   i.e., after Partial Revocation Time, the server comes to be in
+   Partial Revocation state about the key, and this key is called
+   partially revoked.
+
+
+
+Kamite, et. al.          Expires April 15, 2005                 [Page 4]
+
+INTERNET-DRAFT                                              October 2004
+
+
+   In this state, if a client sends a normal query (e.g., question about
+   A RR) other than TKEY Renewal request with TSIG signed with the old
+   key, the server returns an error message to notify that the time to
+   renew has come. This is called "PartialRevoke" error message. It is
+   server's choice whether it returns PartialRevoke or not. If and only
+   if the server is ready for changing its own key, it decides to return
+   PartialRevoke.
+
+   The client which got this error is able to notice that it is
+   necessary to refresh the secret. To make a new shared secret, it
+   sends a TKEY Renewal request, in which several keying methods are
+   available. It can make use of TSIG authentication signed with the
+   partially revoked key mentioned above.
+
+   After new secret establishment, the client sends a TKEY Adoption
+   request for renewal confirmation. This can also be authenticated with
+   the partially revoked key. If this is admitted by the server, the new
+   key is formally adopted, and at the same time the corresponding old
+   secret is invalidated. Then the client can send the first query again
+   signed with the new key.
+
+   Key renewal procedure is executed based on two-phase commit
+   mechanism. The first phase is the TKEY Renewal request and its
+   response, which means preparatory confirmation for key update. The
+   second phase is Adoption request and its response. If the server gets
+   request and client receives the response successfully, they can
+   finish renewal process. If any error happens and renewal process
+   fails during these phases, client should roll back to the beginning
+   of the first phase, and send TKEY Renewal request again. This
+   rollback can be done until the Expiry Limit of the key.
+
+
+2.  Shared Secret Key Renewal
+
+   Suppose a server and a client agree to change their TSIG keys
+   periodically. Key renewal procedure is defined between two hosts.
+
+2.1.  Key Usage Time Check
+
+   Whenever a server receives a query with TSIG and can find a key that
+   is used for signing it, the server checks its Inception Time, Partial
+   Revocation Time and Expiry Limit (this information is usually
+   memorized by the server).
+
+   When the present time is before Inception Time, the server MUST NOT
+   verify TSIG with the key, and server acts the same way as when the
+   key used by the client is not recognized. It follows [RFC2845] 4.5.1.
+
+
+
+
+Kamite, et. al.          Expires April 15, 2005                 [Page 5]
+
+INTERNET-DRAFT                                              October 2004
+
+
+   When the present time is equal to Inception Time, or between
+   Inception Time and Partial Revocation Time, the behavior of the
+   server is the same as when a valid key is found. It follows [RFC2845]
+   4.5.2 and 4.5.3.
+
+   When the present time is the same as the Partial Revocation Time, or
+   between the Partial Revocation Time and Expiry Limit, the server
+   comes to be in Partial Revocation state about the TSIG key and
+   behaves according to the next section.
+
+   When the present time is the same as the Expiry Time or after it, the
+   server MUST NOT verify TSIG with the key, and returns error messages
+   in the same way as when the key used by the client is not recognized.
+   It follows [RFC2845] 4.5.1.
+
+
+2.2.  Partial Revocation
+
+   In Partial Revocation state, we say the server has partially revoked
+   the key and the key has become a "partially revoked key".
+
+   If server has received a query signed with the partially revoked key
+   for TKEY Renewal request (See section 2.3.) or Key Adoption request
+   (See section 2.4.), then server does proper process following each
+   specification. If it is for TKEY key deletion request ([RFC2930]
+   4.2), server MAY process usual deletion operation defined therein.
+
+   If server receives other types of query signed with the partially
+   revoked key, and both the corresponding MAC and signed TIME are
+   verified, then server begins returning answer whose TSIG error code
+   is "PartialRevoke" (See section 9.). Server MUST randomly but with
+   increasing frequency return PartialRevoke when in the Partial
+   Revocation state.
+
+   Server can decide when it actually sends PartialRevoke, checking if
+   it is appropriate time for renewal. Server MUST NOT return
+   PartialRevoke if this is apart long lived TSIG transaction (such as
+   AXFR) that started before the Partial Revocation Time.
+
+   If the client receives PartialRevoke and understands it, then it MUST
+   retry the query with the old key unless a new key has been adopted.
+   Client SHOULD start the process to renew the TSIG key. For key
+   renewal procedure, see details in Section 2.3 and 2.4.
+
+   PartialRevoke period (i.e., time while server returns PartialRevoke
+   randomely) SHOULD be small, say 2-5% of key lifetime. This is
+   server's choice.
+
+
+
+
+Kamite, et. al.          Expires April 15, 2005                 [Page 6]
+
+INTERNET-DRAFT                                              October 2004
+
+
+   Server MUST keep track of clients ignoring PartialRevoke, thus
+   indicating ignorance of this TKEY mode.
+
+   PartialRevoke error messages have the role to inform clients of the
+   keys' partial revocation and urge them to send TKEY Renewal requests.
+   These error responses MUST be signed with those partial revoked keys
+   if the queries are signed with them. They are sent only when the
+   signing keys are found to be partially revoked. If the MAC of TSIG
+   cannot be verified with the partially revoked keys, servers MUST NOT
+   return PartialRevoke error with MAC, but MUST return another error
+   such as "BADSIG" without MAC (following [RFC2845] 4.5.3); in other
+   words, a server informs its key's partial revocation only when the
+   MAC in the received query is valid.
+
+
+2.3.  Key Renewal Message Exchange
+
+2.3.1.  Query for Key Renewal
+
+   If a client has received a PartialRevoke error and authenticated the
+   response based on TSIG MAC, it sends a TKEY query for Key Renewal (in
+   this document, we call it Renewal request, too.) to the server. The
+   request MUST be signed with TSIG or SIG(0) [RFC2931] for
+   authentication. If TSIG is selected, the client can sign it with the
+   partial revoked key.
+
+   Key Renewal can use one of several keying methods which is indicated
+   in "Mode" field of TKEY RR, and its message structure is dependent on
+   that method.
+
+
+2.3.2.  Response for Key Renewal
+
+   The server which has received Key Renewal request first tries to
+   verify TSIG or SIG(0) accompanying it. If the TSIG is signed and
+   verified with the partially revoked key, the request MUST be
+   authenticated.
+
+   After authentication, server must check existing old key's validity.
+   If the partially revoked key indicated in the request TKEY's OldName
+   and OldAlgorithm field (See section 2.3.4.) does not exist at the
+   server, "BADKEY" [RFC2845] is given in Error field for response. If
+   any other error happens, server returns appropriate error messages
+   following the specification described in section 2.5. If there are no
+   errors, server returns a Key Renewal answer. This answer MUST be
+   signed with TSIG or SIG(0) for authentication.
+
+   When this answer is successfully returned and no error is detected by
+
+
+
+Kamite, et. al.          Expires April 15, 2005                 [Page 7]
+
+INTERNET-DRAFT                                              October 2004
+
+
+   client, a new shared secret can be established. The details of
+   concrete keying procedure are given in the section 2.5.
+
+   Note:
+      Sometimes Adoption message and new Renewal request will cross on
+      the wire. In this case the newly generated key Adoption message is
+      resent.
+
+
+2.3.3.  Attributes of Generated Key
+
+   As a result of this message exchange, client comes to know the newly
+   generated key's attributes such as key's name, Inception Time and
+   Expiry Limit. They are decided by the server and told to the client;
+   in particular, however, once the server has decided Expiry Limit and
+   returned a response, it should obey the decision as far as it can. In
+   other words, they SHOULD NOT change time values for checking Expiry
+   Limit in the future without any special reason, such as security
+   issue like "Emergency Compulsory Revocation" described in section 8.
+
+   On the other hand, Partial Revocation Time of this generated key is
+   not decided based on the request, and not informed to the client. The
+   server can determine any value as long as it is between Inception
+   Time and Expiry Limit. However, the period from Inception to Partial
+   Revocation SHOULD be fixed as the server side's configuration or be
+   set the same as the corresponding old key's one.
+
+   Note:
+      Even if client sends Key Renewal request though the key described
+      in OldName has not been partially revoked yet, server does renewal
+      processes.  At the moment when the server accepts such requests
+      with valid authentication, it MUST forcibly consider the key is
+      already partially revoked, that is, the key's Partial Revocation
+      Time must be changed into the present time (i.e., the time when
+      the server receives the request).
+
+
+2.3.4.  TKEY RR structure
+
+   TKEY RR for Key Renewal message has the structure given below. In
+   principle, format and definition for each field follows [RFC2930].
+   Note that each keying scheme sometimes needs different interpretation
+   of RDATA field; for detail, see section 2.5.
+
+        Field        Type         Comment
+        -------      ------       -------
+        NAME         domain       used for a new key, see below
+        TYPE         u_int16_t    (defined in [RFC2930])
+
+
+
+Kamite, et. al.          Expires April 15, 2005                 [Page 8]
+
+INTERNET-DRAFT                                              October 2004
+
+
+        CLASS        u_int16_t    (defined in [RFC2930])
+        TTL          u_int32_t    (defined in [RFC2930])
+        RDLEN        u_int16_t    (defined in [RFC2930])
+        RDATA:
+         Algorithm:   domain       algorithm for a new key
+         Inception:   u_int32_t    about the keying material
+         Expiration:  u_int32_t    about the keying material
+         Mode:        u_int16_t    scheme for key agreement
+                                   see section 9.
+         Error:       u_int16_t    see description below
+         Key Size:    u_int16_t    see description below
+         Key Data:    octet-stream
+         Other Size:  u_int16_t    (defined in [RFC2930])
+                                   size of other data
+         Other Data:               newly defined: see description below
+
+
+     For "NAME" field, both non-root and root name are allowed. It may
+     be used for a new key's name in the same manner as [RFC2930] 2.1.
+
+     "Algorithm" specifies which algorithm is used for agreed keying
+     material, which is used for identification of the next key.
+
+     "Inception" and "Expiration" are used for the valid period of
+     keying material. The meanings differ somewhat according to whether
+     the message is request or answer, and its keying scheme.
+
+     "Key Data" has different meanings according to keying schemes.
+
+     "Mode" field stores the value in accordance with the keying method,
+     and see section 2.5. Servers and clients supporting TKEY Renewal
+     method MUST implement "Diffie-Hellman exchange for key renewal"
+     scheme. All other modes are OPTIONAL.
+
+     "Error" is an extended RCODE which includes "PartialRevoke" value
+     too. See section 9.
+
+     "Other Data" field has the structure given below.  They describe
+     attributes of the key to be renewed.
+
+        in Other Data filed:
+
+          Field            Type       Comment
+          -------          ------     -------
+          OldNAME          domain     name of the old key
+          OldAlgorithm     domain     algorithm of the old key
+
+
+
+
+
+Kamite, et. al.          Expires April 15, 2005                 [Page 9]
+
+INTERNET-DRAFT                                              October 2004
+
+
+          "OldName" indicates the name of the previous key (usually,
+          this is partially revoked key's name that client noticed by
+          PartialRevoke answer from server), and "OldAlogirthm"
+          indicates its algorithm.
+
+
+2.4.  Key Adoption
+
+2.4.1.  Query for Key Adoption
+
+   After receiving a TKEY Renewal answer, the client gets the same
+   secret as the server. Then, it sends a TKEY Adoption request. The
+   request's question section's QNAME field is the same as the NAME
+   filed of TKEY written below. In additional section, there is one TKEY
+   RR that has the structure and values described below.
+
+     "NAME" field is the new key's name to be adopted which was already
+     generated by Renewal message exchange. "Algorithm" is its
+     algorithm. "Inception" means the key's Inception Time, and
+     "Expiration" means Expiry Limit.
+
+     "Mode" field is the value of "key adoption". See section 9.
+
+     "Other Data" field in Adoption has the same structure as that of
+     Renewal request message. "OldName" means the previous old key, and
+     "OldAlogirthm" means its algorithm.
+
+   Key Adoption request MUST be signed with TSIG or SIG(0) for
+   authentication. The client can sign TSIG with the previous key. Note
+   that until Adoption is finished, the new key is treated as invalid,
+   thus it cannot be used for authentication immediately.
+
+
+2.4.2.  Response for Key Adoption
+
+   The server which has received Adoption request, it verifies TSIG or
+   SIG(0) accompanying it. If the TSIG is signed with the partially
+   revoked key and can be verified, the message MUST be authenticated.
+
+   If the next new key indicated by the request TKEY's "NAME" is not
+   present at the server, BADNAME [RFC2845] is given in Error field and
+   the error message is returned.
+
+   If the next key exists but it has not been adopted formally yet, the
+   server confirms the previous key's existence indicated by the
+   "OldName" and "OldAlgorithm" field. If it succeeds, the server
+   executes Adoption of the next key and Revocation of the previous key.
+   Response message duplicates the request's TKEY RR with NOERROR,
+
+
+
+Kamite, et. al.          Expires April 15, 2005                [Page 10]
+
+INTERNET-DRAFT                                              October 2004
+
+
+   including "OldName" and "OldAlgorithm" that indicate the revoked key.
+
+   If the next key exists but it is already adopted, the server returns
+   a response message regardless of the substance of the request TKEY's
+   "OldName". In this response, Response TKEY RR has the same data as
+   the request's one except as to its "Other Data" that is changed into
+   null (i.e., "Other Size" is zero), which is intended for telling the
+   client that the previous key name was ignored, and the new key is
+   already available.
+
+   Client sometimes has to retry Adoption request. Suppose the client
+   sent request signed with the partially revoked key, but its response
+   did not return successfully (e.g., due to the drop of UDP packet).
+   Client will probably retry Adoption request; however, the request
+   will be refused in the form of TSIG "BADKEY" error because the
+   previous key was already revoked. In this case, client will
+   retransmit Adoption request signed with the next key, and expect a
+   response which has null "Other Data" for confirming the completion of
+   renewal.
+
+
+2.5.  Keying Schemes
+
+   In Renewal message exchanges, there are no limitations as to which
+   keying method is actually used. The specification of keying
+   algorithms is independent of the general procedure of Renewal that is
+   described in section 2.3.
+
+   Now this document specifies three algorithms in this section, but
+   other future documents can make extensions defining other methods.
+
+
+2.5.1.  DH Exchange for Key Renewal
+
+   This scheme is defined as an extended method of [RFC2930] 4.1. This
+   specification only describes the difference from it and special
+   notice; assume that all other points, such as keying material
+   computation, are the exactly same as the specification of [RFC2930]
+   4.1.
+
+   Query
+      In Renewal request for type TKEY with this mode, there is one TKEY
+      RR and one KEY RR in the additional information section. KEY RR is
+      the client's Diffie-Hellman public key [RFC2539].
+
+      QNAME in question section is the same as that of "NAME" field in
+      TKEY RR, i.e., it means the requested new key's name.
+
+
+
+
+Kamite, et. al.          Expires April 15, 2005                [Page 11]
+
+INTERNET-DRAFT                                              October 2004
+
+
+      TKEY "Mode" field stores the value of "DH exchange for key
+      renewal". See section 9.
+
+      TKEY "Inception" and "Expiration" are those requested for the
+      keying material, that is, requested usage period of a new key.
+
+      TKEY "Key Data" is used as a random, following [RFC2930] 4.1.
+
+   Response
+      The server which received this request first verifies the TSIG,
+      SIG(0) or DNSSEC lookup of KEY RR used. After authentication, the
+      old key's existence validity is checked, following section 2.3. If
+      any incompatible DH key is found in the request, "BADKEY"
+      [RFC2845] is given in Error field for response. "FORMERR" is given
+      if the query included no DH KEY.
+
+      If there are no errors, the server processes a response according
+      to Diffie-Hellman algorithm and returns the answer. In this
+      answer, there is one TKEY RR in answer section and KEY RR(s) in
+      additional section.
+
+      As long as no error has occurred, all values of TKEY are equal to
+      that of the request message except TKEY NAME, TKEY RDLEN, RDATA's
+      Inception, Expiration, Key Size and Key Data.
+
+      TKEY "NAME" field in the answer specifies the name of newly
+      produced key which the client MUST use.
+
+      TKEY "Inception" and "Expiration" mean the periods of the produced
+      key usage. "Inception" is set to be the time when the new key is
+      actually generated or the time before it, and it will be regarded
+      as Inception Time. "Expiration" is determined by the server, and
+      it will be regarded as Expiry Limit.
+
+      TKEY "Key Data" is used as an additional nonce, following
+      [RFC2930] 4.1.
+
+      The resolver supplied Diffie-Hellman KEY RR SHOULD be echoed in
+      the additional section and a server Diffie-Hellman KEY RR will
+      also be present in the answer section, following [RFC2930] 4.1.
+
+
+2.5.2.  Server Assigned Keying for Key Renewal
+
+   This scheme is defined as an extended method of [RFC2930] 4.4. This
+   specification only describes the difference from it and special
+   notice; assume that all other points, such as secret encrypting
+   method, are the exactly same as the specification of [RFC2930] 4.4.
+
+
+
+Kamite, et. al.          Expires April 15, 2005                [Page 12]
+
+INTERNET-DRAFT                                              October 2004
+
+
+   Query
+      In Renewal request for type TKEY with this mode, there is one TKEY
+      RR and one KEY RR in the additional information section. KEY RR is
+      used in encrypting the response.
+
+      QNAME in question section is the same as that of "NAME" field in
+      TKEY RR, i.e., it means the requested new key's name.
+
+      TKEY "Mode" field stores the value of "server assignment for key
+      renewal". See section 9.
+
+      TKEY "Inception" and "Expiration" are those requested for the
+      keying material, that is, requested usage period of a new key.
+
+      TKEY "Key Data" is provided following the specification of
+      [RFC2930] 4.4.
+
+   Response
+      The server which received this request first verifies the TSIG,
+      SIG(0) or DNSSEC lookup of KEY RR used. After authentication, the
+      old key's existence validity is checked, following section 2.3.
+      "FORMERR" is given if the query specified no encryption key.
+
+      If there are no errors, the server response contains one TKEY RR
+      in the answer section, and echoes the KEY RR provided in the query
+      in the additional information section.
+
+      TKEY "NAME" field in the answer specifies the name of newly
+      produced key which the client MUST use.
+
+      TKEY "Inception" and "Expiration" mean the periods of the produced
+      key usage. "Inception" is set to be the time when the new key is
+      actually generated or the time before it, and it will be regarded
+      as Inception Time. "Expiration" is determined by the server, and
+      it will be regarded as Expiry Limit.
+
+      TKEY "Key Data" is the assigned keying data encrypted under the
+      public key in the resolver provided KEY RR, which is the same as
+      [RFC2930] 4.4.
+
+
+2.5.3.  Resolver Assigned Keying for Key Renewal
+
+   This scheme is defined as an extended method of [RFC2930] 4.5. This
+   specification only describes the difference from it and special
+   notice; assume that all other points, such as secret encrypting
+   method, are the exactly same as the specification of [RFC2930] 4.5.
+
+
+
+
+Kamite, et. al.          Expires April 15, 2005                [Page 13]
+
+INTERNET-DRAFT                                              October 2004
+
+
+   Query
+      In Renewal request for type TKEY with this mode, there is one TKEY
+      RR and one KEY RR in the additional information section. TKEY RR
+      has the encrypted keying material and KEY RR is the server public
+      key used to encrypt the data.
+
+      QNAME in question section is the same as that of "NAME" field in
+      TKEY RR, i.e., it means the requested new key's name.
+
+      TKEY "Mode" field stores the value of "resolver assignment for key
+      renewal". See section 9.
+
+      TKEY "Inception" and "Expiration" are those requested for the
+      keying material, that is, requested usage period of a new key.
+
+      TKEY "Key Data" is the encrypted keying material.
+
+   Response
+      The server which received this request first verifies the TSIG,
+      SIG(0) or DNSSEC lookup of KEY RR used. After authentication, the
+      old key's existence validity is checked, following section 2.3.
+      "FORMERR" is given if the server does not have the corresponding
+      private key for the KEY RR that was shown sin the request.
+
+      If there are no errors, the server returns a response. The
+      response contains a TKEY RR in the answer section to tell the
+      shared key's name and its usage time values.
+
+      TKEY "NAME" field in the answer specifies the name of newly
+      produced key which the client MUST use.
+
+      TKEY "Inception" and "Expiration" mean the periods of the produced
+      key usage. "Inception" is set to be the time when the new key is
+      actually generated or the time before it, and it will be regarded
+      as Inception Time. "Expiration" is determined by the server, and
+      it will be regarded as Expiry Limit.
+
+
+2.6.  Considerations about Non-compliant Hosts
+
+   Key Renewal requests and responses must be exchanged between hosts
+   which can understand them and do proper processes. PartialRevoke
+   error messages will be only ignored if they should be returned to
+   non-compliant hosts.
+
+   Note that server does not inform actively the necessity of renewal to
+   clients, but inform it as responses invoked by client's query.
+   Server needs not care whether the PartialRevoke errors has reached
+
+
+
+Kamite, et. al.          Expires April 15, 2005                [Page 14]
+
+INTERNET-DRAFT                                              October 2004
+
+
+   client or not. If client has not received yet because of any reasons
+   such as packet drops, it will resend the queries, and finally will be
+   able to get PartialRevoke information.
+
+
+3.  Secret Storage
+
+   Every server keeps all secrets and attached information, e.g.,
+   Inception Time, Expiry Limit, etc. safely to be able to recover from
+   unexpected stop. To accomplish this, formally adopted keys SHOULD be
+   memorized not only on memory, but also be stored in the form of some
+   files. It will become more secure if they are stored in ecrypted
+   form.
+
+
+4.  Compulsory Key Revocation
+
+4.1.  Compulsory Key Revocation by Server
+
+   There is a rare but possible case that although servers have already
+   partially revoked keys, clients do not try to send any Renewal
+   requests. If this state continues, in the future it will become the
+   time of Expiry Limit. After Expiry Limit, the keys will be expired
+   and completely removed, so this is called Compulsory Key Revocation
+   by server.
+
+   If Expiry Limit is too distant from the Partial Revocation Time, then
+   even though very long time passes, clients will be able to refresh
+   secrets only if they add TSIG signed with those old partially revoked
+   keys into requests, which is not safe.
+
+   On the other hand, if Expiry Limit is too close to Partial Revocation
+   Time, perhaps clients might not be able to notice their keys' Partial
+   Revocation by getting "PartialRevoke" errors.
+
+   Therefore, servers should set proper Expiry Limit to their keys,
+   considering both their keys' safety, and enough time for clients to
+   send requests and process renewal.
+
+
+4.2.  Authentication Methods Considerations
+
+   It might be ideal to provide both SIG(0) and TSIG as authentication
+   methods. For example:
+
+     A client and a server start SIG(0) authentication at first, to
+     establish TSIG shared keys by means of "Query for Diffie-Hellman
+     Exchanged Keying" as described in [RFC2930] 4.1. Once they get
+
+
+
+Kamite, et. al.          Expires April 15, 2005                [Page 15]
+
+INTERNET-DRAFT                                              October 2004
+
+
+     shared secret, they keep using TSIG for queries and responses.
+     After a while the server returns a "ParitalRevoke" error and they
+     begin a key renewal process. Both TSIG signed with partially
+     revoked keys and SIG(0) are okay for authentication, but TSIG would
+     be easier to use considering calculation efficiency.
+
+     Suppose now client is halted for long time with some reason.
+     Because server does not execute any renewal process, it will
+     finally do Compulsory Revocation. Even if client restarts and sends
+     a key Renewal request, it will fail because old key is already
+     deleted at server.
+
+     At this moment, however, if client also uses SIG(0) as another
+     authentication method, it can make a new shared key again and
+     recover successfully by sending "Query for Diffie-Hellman Exchanged
+     Keying" with SIG(0).
+
+
+5.  Special Considerations for Two servers' Case
+
+   This section refers to the case where both hosts are DNS servers
+   which can act as full resolvers as well and using one shared key
+   only. If one server (called Server A) wants to refresh a shared key
+   (called "Key A-B"), it will await a TKEY Renewal request from the
+   other server (called Server B). However, perhaps Server A wants to
+   refresh the key right now.
+
+   In this case, Server A is allowed to send a Renewal request to Server
+   B, if Server A knows the Key A-B is too old and wants to renew it
+   immediately.
+
+   Note that the initiative in key renewal belongs to Server A because
+   it can notice the Partial Revocation Time and decide key renewal. If
+   Server B has information about Partial Revocation Time as well, it
+   can also decide for itself to send Renewal request to Server A.
+   However, it is not essential for both two servers have information
+   about key renewal timing.
+
+5.1.  To Cope with Collisions of Renewal Requests
+
+   At least one of two hosts which use Key Renewal must know their key
+   renewal information such as Partial Revocation Time. It is okay that
+   both hosts have it.
+
+   Provided that both two servers know key renewal timing information,
+   there is possibility for them to begin partial revocation and sending
+   Renewal requests to each other at the same time. Such collisions will
+   not happen so often because Renewal requests are usually invoked when
+
+
+
+Kamite, et. al.          Expires April 15, 2005                [Page 16]
+
+INTERNET-DRAFT                                              October 2004
+
+
+   hosts want to send queries, but it is possible.
+
+   When one of two servers tries to send Renewal requests, it MUST
+   protect old secrets that it has partially revoked and prevent it from
+   being refreshed by any requests from the other server (i.e., it must
+   lock the old secret during the process of renewal). While the server
+   is sending Renewal requests and waiting responses, it ignores the
+   other server's Renewal requests.
+
+   Therefore, servers might fail to change secrets by means of their own
+   requests to others. After failure they will try to resend, but they
+   should wait for random delays by the next retries. If they get any
+   Renewal requests from others while they are waiting, their shared
+   keys may be refreshed, then they do not need to send any Renewal
+   requests now for themselves.
+
+
+6.  Key Name Considerations
+
+   Since both servers and clients have only to distinguish new secrets
+   and old ones, keys' names do not need to be specified strictly.
+   However, it is recommended that some serial number or key generation
+   time be added to the name and that the names of keys between the same
+   pair of hosts should have some common labels among their keys. For
+   example, suppose A.example.com. and B.example.com. share the key
+   "<serial number>.A.example.com.B.example.com." such as
+   "10010.A.example.com.B.example.com.". After key renewal, they change
+   their secret and name into "10011.A.example.com.B.example.com."
+
+   Servers and clients must be able to use keys properly for each query.
+   Because TSIG secret keys themselves do not have any particular IDs to
+   be distinguished and would be identified by their names and
+   algorithm, it must be understood correctly what keys are refreshed.
+
+
+7.  Example Usage of Secret Key Renewal Mode
+
+   This is an example of Renewal mode usage where a Server,
+   server.example.com, and a Client, client.exmple.com have an initial
+   shared secret key named "00.client.example.com.server.example.com".
+
+     (1) The time values for key
+     "00.client.example.com.server.example.com" was set as follows:
+     Inception Time is at 1:00, Expiry Limit is at 21:00.
+
+     (2) At Server, renewal time has been set: Partial Revocation Time
+     is at 20:00.
+
+
+
+
+Kamite, et. al.          Expires April 15, 2005                [Page 17]
+
+INTERNET-DRAFT                                              October 2004
+
+
+     (3) Suppose the present time is 19:55. If Client sends a query
+     signed with key "00.client.example.com.server.example.com" to ask
+     the IP address of "www.example.com", finally it will get a proper
+     answer from Server with valid TSIG (NOERROR).
+
+     (4) At 20:05. Client sends a query to ask the IP address of
+     "www2.example.com". It is signed with key
+     "00.client.example.com.server.example.com". Server returns an
+     answer for the IP address. However, server has begun retuning
+     PartialRevoke Error randomely. This answer includes valid TSIG MAC
+     signed with "00.client.example.com.server.example.com", and its
+     Error Code indicates PartialRevoke. Client understands that the
+     current key is partially revoked.
+
+     (5) At 20:06. Client sends a Renewal request to Server. This
+     request is signed with key
+     "00.client.example.com.server.example.com". It includes data such
+     as:
+
+      Question Section:
+         QNAME = 01.client.example.com. (Client can set this freely)
+         TYPE  = TKEY
+
+      Additional Section:
+         01.client.example.com. TKEY
+          Algorithm    = hmac-md5-sig-alg.reg.int.
+          Inception    = (value meaning 20:00)
+          Expiration   = (value meaning next day's 16:00)
+          Mode         = (DH exchange for key renewal)
+          OldName      = 00.client.example.com.server.example.com.
+          OldAlgorithm = hmac-md5-sig-alg.reg.int.
+
+      Additional Section also contains a KEY RR for DH and a TSIG RR.
+
+     (6) As soon as Server receives this request, it verifies TSIG. It
+     is signed with the partially revoked key
+     "00.client.example.com.server.example.com". and Server accepts the
+     request. It creates a new key by Diffie-Hellman calculation and
+     returns an answer which includes data such as:
+
+      Answer Section:
+         01.client.example.com.server.example.com. TKEY
+          Algorithm    = hmac-md5-sig-alg.reg.int.
+          Inception    = (value meaning 20:00)
+          Expiration   = (value meaning next day's 16:00)
+          Mode         = (DH exchange for key renewal)
+          OldName      = 00.client.example.com.server.example.com.
+          OldAlgorithm = hmac-md5-sig-alg.reg.int.
+
+
+
+Kamite, et. al.          Expires April 15, 2005                [Page 18]
+
+INTERNET-DRAFT                                              October 2004
+
+
+     Answer Section also contains KEY RRs for DH.
+
+      Additional Section also contains a TSIG RR.
+     This response is signed with key
+     "00.client.example.com.server.example.com" without error.
+
+     At the same time, Server decides to set the Partial Revocation Time
+     of this new key "01.client.example.com.server.example.com." as next
+     day's 15:00.
+
+     (7) Client gets the response and checks TSIG MAC, and calculates
+     Diffie-Hellman. It will get a new key, and it has been named
+     "01.client.example.com.server.example.com" by Server.
+
+     (8) At 20:07. Client sends an Adoption request to Server. This
+     request is signed with the previous key
+     "00.client.example.com.server.example.com". It includes:
+
+      Question Section:
+         QNAME = 01.client.example.com.server.example.com.
+         TYPE  = TKEY
+
+      Additional Section:
+         01.client.example.com.server.example.com. TKEY
+          Algorithm    = hmac-md5-sig-alg.reg.int.
+          Inception    = (value meaning 20:00)
+          Expiration   = (value meaning next day's 16:00)
+          Mode         = (key adoption)
+          OldName      = 00.client.example.com.server.example.com.
+          OldAlgorithm = hmac-md5-sig-alg.reg.int.
+
+     Additional Section also contains a TSIG RR.
+
+     (9) Server verifies the query's TSIG. It is signed with the
+     previous key and authenticated. It returns a response whose TKEY RR
+     is the same as the request's one. The response is signed with key
+     "00.client.example.com.server.example.com.". As soon as the
+     response is sent, Server revokes and removes the previous key. At
+     the same time, key "01.client.example.com.server.example.com." is
+     validated.
+
+     (10) Client acknowledges the success of Adoption by receiving the
+     response.  Then, it retries to send an original question about
+     "www2.example.com". It is signed with the adopted key
+     "01.client.example.com.server.example.com", so Server authenticates
+     it and returns an answer.
+
+
+
+
+
+Kamite, et. al.          Expires April 15, 2005                [Page 19]
+
+INTERNET-DRAFT                                              October 2004
+
+
+     (11) This key is used until next day's 15:00. After that, it will
+     be partially revoked again.
+
+
+8.  Security Considerations
+
+   This document considers about how to refresh shared secret. Secret
+   changed by this method is used at servers in support of TSIG
+   [RFC2845].
+
+   [RFC2104] says that current attacks to HMAC do not indicate a
+   specific recommended frequency for key changes but periodic key
+   refreshment is a fundamental security practice that helps against
+   potential weaknesses of the function and keys, and limits the damage
+   of an exposed key. TKEY Secret Key Renewal provides the method of
+   periodical key refreshment.
+
+   In TKEY Secret Key Renewal, clients need to send two requests
+   (Renewal and Adoption) and spend time to finish their key renewal
+   processes. Thus the usage period of secrets should be considered
+   carefully based on both TKEY processing performance and security.
+
+   This document specifies the procedure of periodical key renewal, but
+   actually there is possibility for servers to have no choice other
+   than revoking their secret keys immediately especially when the keys
+   are found to be compromised by attackers. This is called "Emergency
+   Compulsory Revocation". For example, suppose the original Expiry
+   Limit was set at 21:00, Partial Revocation Time at 20:00 and
+   Inception Time at 1:00.  if at 11:00 the key is found to be
+   compromised, the server sets Expiry Limit forcibly to be 11:00 or
+   before it.
+
+   Consequently, once Compulsory Revocation (See section 4.) is carried
+   out, normal renewal process described in this document cannot be done
+   any more as far as the key is concerned. However, after such
+   accidents happened, the two hosts are able to establish secret keys
+   and begin renewal procedure only if they have other (non-compromised)
+   shared TSIG keys or safe SIG(0) keys for the authentication of
+   initial secret establishment such as Diffie-Hellman Exchanged Keying.
+
+
+9.  IANA Considerations
+
+   IANA needs to allocate a value for "DH exchange for key renewal",
+   "server assignment for key renewal", "resolver assignment for key
+   renewal" and "key adoption" in the mode filed of TKEY. It also needs
+   to allocate a value for "PartialRevoke" from the extended RCODE
+   space.
+
+
+
+Kamite, et. al.          Expires April 15, 2005                [Page 20]
+
+INTERNET-DRAFT                                              October 2004
+
+
+10.  Acknowledgements
+
+   The authors would like to thank Olafur Gudmundsson, whose helpful
+   input and comments contributed greatly to this document.
+
+
+11.  References
+
+11.1.  Normative References
+
+[RFC2119]
+     Bradner, S., "Key words for use in RFCs to Indicate Requirement
+     Levels", RFC 2119, March 1997.
+
+[RFC2539]
+     D. Eastlake 3rd, "Storage of Diffie-Hellman Keys in the Domain Name
+     System (DNS)", RFC 2539, March 1999.
+
+[RFC2845]
+     Vixie, P., Gudmundsson, O., Eastlake, D. and B.  Wellington,
+     "Secret Key Transaction Authentication for DNS (TSIG)", RFC 2845,
+     May 2000.
+
+[RFC2930]
+     D. Eastlake 3rd, ``Secret Key Establishment for DNS (TKEY RR)'',
+     RFC 2930, September 2000.
+
+[RFC2931]
+     D. Eastlake 3rd, "DNS Request and Transaction Signatures (SIG(0)s
+     )", RFC 2931, September 2000.
+
+11.2.  Informative References
+
+[RFC2104]
+     H. Krawczyk, M.Bellare, R. Canetti, "Keyed-Hashing for Message
+     Authentication", RFC2104, February 1997.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kamite, et. al.          Expires April 15, 2005                [Page 21]
+
+INTERNET-DRAFT                                              October 2004
+
+
+Authors' Addresses
+
+   Yuji Kamite
+   NTT Communications Corporation
+   Tokyo Opera City Tower
+   3-20-2 Nishi Shinjuku, Shinjuku-ku, Tokyo
+   163-1421, Japan
+   EMail: y.kamite@ntt.com
+
+
+   Masaya Nakayama
+   Information Technology Center, The University of Tokyo
+   2-11-16 Yayoi, Bunkyo-ku, Tokyo
+   113-8658, Japan
+   EMail: nakayama@nc.u-tokyo.ac.jp
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kamite, et. al.          Expires April 15, 2005                [Page 22]
+
+INTERNET-DRAFT                                              October 2004
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2004).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Kamite, et. al.          Expires April 15, 2005                [Page 23]
+
+
+
diff --git a/doc/draft/draft-ietf-dnsext-trustupdate-threshold-00.txt b/doc/draft/draft-ietf-dnsext-trustupdate-threshold-00.txt
new file mode 100644
index 0000000..a598826
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsext-trustupdate-threshold-00.txt
@@ -0,0 +1,1501 @@
+Network Working Group                                           J. Ihren
+Internet-Draft                                             Autonomica AB
+Expires: April 18, 2005                                       O. Kolkman
+                                                                RIPE NCC
+                                                              B. Manning
+                                                                  EP.net
+                                                        October 18, 2004
+
+
+
+  An In-Band Rollover Mechanism and an Out-Of-Band Priming Method for
+                         DNSSEC Trust Anchors.
+               draft-ietf-dnsext-trustupdate-threshold-00
+
+
+Status of this Memo
+
+
+   By submitting this Internet-Draft, I certify that any applicable
+   patent or other IPR claims of which I am aware have been disclosed,
+   and any of which I become aware will be disclosed, in accordance with
+   RFC 3668.
+
+
+   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 draft documents 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 "work in progress."
+
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/ietf/1id-abstracts.txt.
+
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+
+   This Internet-Draft will expire on April 18, 2005.
+
+
+Copyright Notice
+
+
+   Copyright (C) The Internet Society (2004).  All Rights Reserved.
+
+
+Abstract
+
+
+   The DNS Security Extensions (DNSSEC) works by validating so called
+   chains of authority.  The start of these chains of authority are
+   usually public keys that are anchored in the DNS clients.  These keys
+   are known as the so called trust anchors.
+
+
+
+
+
+Ihren, et al.            Expires April 18, 2005                 [Page 1]
+Internet-Draft    DNSSEC Threshold-based Trust Update       October 2004
+
+
+
+   This memo describes a method how these client trust anchors can be
+   replaced using the DNS validation and querying mechanisms (in-band)
+   when the key pairs used for signing by zone owner are rolled.
+
+
+   This memo also describes a method to establish the validity of trust
+   anchors for initial configuration, or priming, using out of band
+   mechanisms.
+
+
+Table of Contents
+
+
+   1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
+     1.1   Key Signing Keys, Zone Signing Keys and Secure Entry
+           Points . . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   2.  Introduction and Background  . . . . . . . . . . . . . . . . .  5
+     2.1   Dangers of Stale Trust Anchors . . . . . . . . . . . . . .  5
+   3.  Threshold-based Trust Anchor Rollover  . . . . . . . . . . . .  7
+     3.1   The Rollover . . . . . . . . . . . . . . . . . . . . . . .  7
+     3.2   Threshold-based Trust Update . . . . . . . . . . . . . . .  8
+     3.3   Possible Trust Update States . . . . . . . . . . . . . . .  9
+     3.4   Implementation notes . . . . . . . . . . . . . . . . . . . 10
+     3.5   Possible transactions  . . . . . . . . . . . . . . . . . . 11
+       3.5.1   Single DNSKEY replaced . . . . . . . . . . . . . . . . 12
+       3.5.2   Addition of a new DNSKEY (no removal)  . . . . . . . . 12
+       3.5.3   Removal of old DNSKEY (no addition)  . . . . . . . . . 12
+       3.5.4   Multiple DNSKEYs replaced  . . . . . . . . . . . . . . 12
+     3.6   Removal of trust anchors for a trust point . . . . . . . . 12
+     3.7   No need for resolver-side overlap of old and new keys  . . 13
+   4.  Bootstrapping automatic rollovers  . . . . . . . . . . . . . . 14
+     4.1   Priming Keys . . . . . . . . . . . . . . . . . . . . . . . 14
+       4.1.1   Bootstrapping trust anchors using a priming key  . . . 14
+       4.1.2   Distribution of priming keys . . . . . . . . . . . . . 15
+   5.  The Threshold Rollover Mechanism vs Priming  . . . . . . . . . 16
+   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 17
+     6.1   Threshold-based Trust Update Security Considerations . . . 17
+     6.2   Priming Key Security Considerations  . . . . . . . . . . . 17
+   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 19
+   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
+   8.1   Normative References . . . . . . . . . . . . . . . . . . . . 20
+   8.2   Informative References . . . . . . . . . . . . . . . . . . . 20
+       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 20
+   A.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 22
+   B.  Document History . . . . . . . . . . . . . . . . . . . . . . . 23
+     B.1   prior to version 00  . . . . . . . . . . . . . . . . . . . 23
+     B.2   version 00 . . . . . . . . . . . . . . . . . . . . . . . . 23
+       Intellectual Property and Copyright Statements . . . . . . . . 24
+
+
+
+
+
+
+
+Ihren, et al.            Expires April 18, 2005                 [Page 2]
+Internet-Draft    DNSSEC Threshold-based Trust Update       October 2004
+
+
+
+1.  Terminology
+
+
+   The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED",
+   and "MAY" in this document are to be interpreted as described in
+   RFC2119 [1].
+
+
+   The term "zone" refers to the unit of administrative control in the
+   Domain Name System.  In this document "name server" denotes a DNS
+   name server that is authoritative (i.e.  knows all there is to know)
+   for a DNS zone.  A "zone owner" is the entity responsible for signing
+   and publishing a zone on a name server.  The terms "authentication
+   chain", "bogus", "trust anchors" and "Island of Security" are defined
+   in [4].  Throughout this document we use the term "resolver" to mean
+   "Validating Stub Resolvers" as defined in [4].
+
+
+   We use the term "security apex" as the zone for which a trust anchor
+   has been configured (by validating clients) and which is therefore,
+   by definition, at the root of an island of security.  The
+   configuration of trust anchors is a client side issue.  Therefore a
+   zone owner may not always know if their zone has become a security
+   apex.
+
+
+   A "stale anchor" is a trust anchor (a public key) that relates to a
+   key that is not used for signing.  Since trust anchors indicate that
+   a zone is supposed to be secure a validator will mark the all data in
+   an island of security as bogus when all trust anchors become stale.
+
+
+   It is assumed that the reader is familiar with public key
+   cryptography concepts [REF: Schneier Applied Cryptography] and is
+   able to distinguish between the private and public parts of a key
+   based on the context in which we use the term "key".  If there is a
+   possible ambiguity we will explicitly mention if a private or a
+   public part of a key is used.
+
+
+   The term "administrator" is used loosely throughout the text.  In
+   some cases an administrator is meant to be a person, in other cases
+   the administrator may be a process that has been delegated certain
+   responsibilities.
+
+
+1.1  Key Signing Keys, Zone Signing Keys and Secure Entry Points
+
+
+   Although the DNSSEC protocol does not make a distinction between
+   different keys the operational practice is that a distinction is made
+   between zone signing keys and key signing keys.  A key signing key is
+   used to exclusively sign the DNSKEY Resource Record (RR) set at the
+   apex of a zone and the zone signing keys sign all the data in the
+   zone (including the DNSKEY RRset at the apex).
+
+
+
+
+
+Ihren, et al.            Expires April 18, 2005                 [Page 3]
+Internet-Draft    DNSSEC Threshold-based Trust Update       October 2004
+
+
+
+   Keys that are intended to be used as the start of the authentication
+   chain for a particular zone, either because they are pointed to by a
+   parental DS RR or because they are configured as a trust anchor, are
+   called Secure Entry Point (SEP) keys.  In practice these SEP keys
+   will be key signing keys.
+
+
+   In order for the mechanism described herein to work the keys that are
+   intended to be used as secure entry points MUST have the SEP [2] flag
+   set.  In the examples it is assumed that keys with the SEP flag set
+   are used as key signing keys and thus exclusively sign the DNSKEY
+   RRset published at the apex of the zone.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ihren, et al.            Expires April 18, 2005                 [Page 4]
+Internet-Draft    DNSSEC Threshold-based Trust Update       October 2004
+
+
+
+2.  Introduction and Background
+
+
+   When DNSSEC signatures are validated the resolver constructs a chain
+   of authority from a pre-configured trust anchor to the DNSKEY
+   Resource Record (RR), which contains the public key that validates
+   the signature stored in an RRSIG RR.  DNSSEC is designed so that the
+   administrator of a resolver can validate data in multiple islands of
+   security by configuring multiple trust anchors.
+
+
+   It is expected that resolvers will have more than one trust anchor
+   configured.  Although there is no deployment experience it is not
+   unreasonable to expect resolvers to be configured with a number of
+   trust anchors that varies between order 1 and order 1000.  Because
+   zone owners are expected to roll their keys, trust anchors will have
+   to be maintained (in the resolver end) in order not to become stale.
+
+
+   Since there is no global key maintenance policy for zone owners and
+   there are no mechanisms in the DNS to signal the key maintenance
+   policy it may be very hard for resolvers administrators to keep their
+   set of trust anchors up to date.  For instance, if there is only one
+   trust anchor configured and the key maintenance policy is clearly
+   published, through some out of band trusted channel, then a resolver
+   administrator can probably keep track of key rollovers and update the
+   trust anchor manually.  However, with an increasing number of trust
+   anchors all rolled according to individual policies that are all
+   published through different channels this soon becomes an
+   unmanageable problem.
+
+
+2.1  Dangers of Stale Trust Anchors
+
+
+   Whenever a SEP key at a security apex is rolled there exists a danger
+   that "stale anchors" are created.  A stale anchor is a trust anchor
+   (i.e.  a public key configured in a validating resolver) that relates
+   to a private key that is no longer used for signing.
+
+
+   The problem with a stale anchors is that they will (from the
+   validating resolvers point of view) prove data to be false even
+   though it is actually correct.  This is because the data is either
+   signed by a new key or is no longer signed and the resolver expects
+   data to be signed by the old (now stale) key.
+
+
+   This situation is arguably worse than not having a trusted key
+   configured for the secure entry point, since with a stale key no
+   lookup is typically possible (presuming that the default
+   configuration of a validating recursive nameserver is to not give out
+   data that is signed but failed to verify.
+
+
+   The danger of making configured trust anchors become stale anchors
+
+
+
+
+Ihren, et al.            Expires April 18, 2005                 [Page 5]
+Internet-Draft    DNSSEC Threshold-based Trust Update       October 2004
+
+
+
+   may be a reason for zone owners not to roll their keys.  If a
+   resolver is configured with many trust anchors that need manual
+   maintenance it may be easy to not notice a key rollover at a security
+   apex, resulting in a stale anchor.
+
+
+   In Section 3 this memo sets out a lightweight, in-DNS, mechanism to
+   track key rollovers and modify the configured trust anchors
+   accordingly.  The mechanism is stateless and does not need protocol
+   extensions.  The proposed design is that this mechanism is
+   implemented as a "trust updating machine" that is run entirely
+   separate from the validating resolver except that the trust updater
+   will have influence over the trust anchors used by the latter.
+
+
+   In Section 4 we describe a method [Editors note: for now only the
+   frame work and a set of requirements] to install trust anchors.  This
+   method can be used at first configuration or when the trust anchors
+   became stale (typically due to a failure to track several rollover
+   events).
+
+
+   The choice for which domains trust anchors are to be configured is a
+   local policy issue.  So is the choice which trust anchors has
+   prevalence if there are multiple chains of trust to a given piece of
+   DNS data (e.g.  when a parent zone and its child both have trust
+   anchors configured).  Both issues are out of the scope of this
+   document.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ihren, et al.            Expires April 18, 2005                 [Page 6]
+Internet-Draft    DNSSEC Threshold-based Trust Update       October 2004
+
+
+
+3.  Threshold-based Trust Anchor Rollover
+
+
+3.1  The Rollover
+
+
+   When a key pair is replaced all signatures (in DNSSEC these are the
+   RRSIG records) created with the old key will be replaced by new
+   signatures created by the new key.  Access to the new public key is
+   needed to verify these signatures.
+
+
+   Since zone signing keys are in "the middle" of a chain of authority
+   they can be verified using the signature made by a key signing key.
+   Rollover of zone signing keys is therefore transparent to validators
+   and requires no action in the validator end.
+
+
+   But if a key signing key is rolled a resolver can determine its
+   authenticity by either following the authorization chain from the
+   parents DS record, an out-of-DNS authentication mechanism or by
+   relying on other trust anchors known for the zone in which the key is
+   rolled.
+
+
+   The threshold trust anchor rollover mechanism (or trust update),
+   described below, is based on using existing trust anchors to verify a
+   subset of the available signatures.  This is then used as the basis
+   for a decision to accept the new keys as valid trust anchors.
+
+
+   Our example pseudo zone below contains a number of key signing keys
+   numbered 1 through Y and two zone signing keys A and B.  During a key
+   rollover key 2 is replaced by key Y+1.  The zone content changes
+   from:
+
+
+          example.com.  DNSKEY key1
+          example.com.  DNSKEY key2
+          example.com.  DNSKEY key3
+          ...
+          example.com.  DNSKEY keyY
+
+
+          example.com.  DNSKEY keyA
+          example.com.  DNSKEY keyB
+
+
+          example.com.  RRSIG DNSKEY ... (key1)
+          example.com.  RRSIG DNSKEY ... (key2)
+          example.com.  RRSIG DNSKEY ... (key3)
+          ...
+          example.com.  RRSIG DNSKEY ... (keyY)
+          example.com.  RRSIG DNSKEY ... (keyA)
+          example.com.  RRSIG DNSKEY ... (keyB)
+
+
+    to:
+
+
+
+
+Ihren, et al.            Expires April 18, 2005                 [Page 7]
+Internet-Draft    DNSSEC Threshold-based Trust Update       October 2004
+
+
+
+          example.com.  DNSKEY key1
+          example.com.  DNSKEY key3
+          ...
+          example.com.  DNSKEY keyY
+          example.com.  DNSKEY keyY+1
+
+
+          example.com.  RRSIG DNSKEY ... (key1)
+          example.com.  RRSIG DNSKEY ... (key3)
+          ...
+          example.com.  RRSIG DNSKEY ... (keyY)
+          example.com.  RRSIG DNSKEY ... (keyY+1)
+          example.com.  RRSIG DNSKEY ... (keyA)
+          example.com.  RRSIG DNSKEY ... (keyB)
+
+
+   When the rollover becomes visible to the verifying stub resolver it
+   will be able to verify the RRSIGs associated with key1, key3 ...
+   keyY.  There will be no RRSIG by key2 and the RRSIG by keyY+1 will
+   not be used for validation, since that key is previously unknown and
+   therefore not trusted.
+
+
+   Note that this example is simplified.  Because of operational
+   considerations described in [5] having a period during which the two
+   key signing keys are both available is necessary.
+
+
+3.2  Threshold-based Trust Update
+
+
+   The threshold-based trust update algorithm applies as follows.  If
+   for a particular secure entry point
+   o  if the DNSKEY RRset in the zone has been replaced by a more recent
+      one (as determined by comparing the RRSIG inception dates)
+   and
+   o  if at least M configured trust anchors directly verify the related
+      RRSIGs over the new DNSKEY RRset
+   and
+   o  the number of configured trust anchors that verify the related
+      RRSIGs over the new DNSKEY RRset exceed a locally defined minimum
+      number that should be greater than one
+   then all the trust anchors for the particular secure entry point are
+   replaced by the set of keys from the zones DNSKEY RRset that have the
+   SEP flag set.
+
+
+   The choices for the rollover acceptance policy parameter M is left to
+   the administrator of the resolver.  To be certain that a rollover is
+   accepted up by resolvers using this mechanism zone owners should roll
+   as few SEP keys at a time as possible (preferably just one).  That
+   way they comply to the most strict rollover acceptance policy of
+   M=N-1.
+
+
+
+
+
+Ihren, et al.            Expires April 18, 2005                 [Page 8]
+Internet-Draft    DNSSEC Threshold-based Trust Update       October 2004
+
+
+
+   The value of M has an upper bound, limited by the number of of SEP
+   keys a zone owner publishes (i.e.  N).  But there is also a lower
+   bound, since it will not be safe to base the trust in too few
+   signatures.  The corner case is M=1 when any validating RRSIG will be
+   sufficient for a complete replacement of the trust anchors for that
+   secure entry point.  This is not a recommended configuration, since
+   that will allow an attacker to initiate rollover of the trust anchors
+   himself given access to just one compromised key.  Hence M should in
+   be strictly larger than 1 as shown by the third requirement above.
+
+
+   If the rollover acceptance policy is M=1 then the result for the
+   rollover in our example above should be that the local database of
+   trust anchors is updated by removing key "key2" from and adding key
+   "keyY+1" to the key store.
+
+
+3.3  Possible Trust Update States
+
+
+   We define five states for trust anchor configuration at the client
+   side.
+   PRIMING: There are no trust anchors configured.  There may be priming
+      keys available for initial priming of trust anchors.
+   IN-SYNC: The set of trust anchors configured exactly matches the set
+      of SEP keys used by the zone owner to sign the zone.
+   OUT-OF-SYNC: The set of trust anchors is not exactly the same as the
+      set of SEP keys used by the zone owner to sign the zone but there
+      are enough SEP key in use by the zone owner that is also in the
+      trust anchor configuration.
+   UNSYNCABLE: There is not enough overlap between the configured trust
+      anchors and the set of SEP keys used to sign the zone for the new
+      set to be accepted by the validator (i.e.  the number of
+      signatures that verify is not sufficient).
+   STALE: There is no overlap between the configured trust anchors and
+      the set of SEP keys used to sign the zone.  Here validation of
+      data is no longer possible and hence we are in a situation where
+      the trust anchors are stale.
+
+
+   Of these five states only two (IN-SYNC and OUT-OF-SYNC) are part of
+   the automatic trust update mechanism.  The PRIMING state is where a
+   validator is located before acquiring an up-to-date set of trust
+   anchors.  The transition from PRIMING to IN-SYNC is manual (see
+   Section 4 below).
+
+
+   Example: assume a secure entry point with four SEP keys and a
+   validator with the policy that it will accept any update to the set
+   of trust anchors as long as no more than two signatures fail to
+   validate (i.e.  M >= N-2) and at least two signature does validate
+   (i.e.  M >= 2).  In this case the rollover of a single key will move
+   the validator from IN-SYNC to OUT-OF-SYNC.  When the trust update
+
+
+
+
+Ihren, et al.            Expires April 18, 2005                 [Page 9]
+Internet-Draft    DNSSEC Threshold-based Trust Update       October 2004
+
+
+
+   state machine updates the trust anchors it returns to state IN-SYNC.
+
+
+   If if for some reason it fails to update the trust anchors then the
+   next rollover (of a different key) will move the validator from
+   OUT-OF-SYNC to OUT-OF-SYNC (again), since there are still two keys
+   that are configured as trust anchors and that is sufficient to accpt
+   an automatic update of the trust anchors.
+
+
+   The UNSYNCABLE state is where a validator is located if it for some
+   reason fails to incorporate enough updates to the trust anchors to be
+   able to accept new updates according to its local policy.  In this
+   example (i.e.  with the policy specified above) this will either be
+   because M < N-2 or M < 2, which does not suffice to authenticate a
+   successful update of trust anchors.
+
+
+   Continuing with the previous example where two of the four SEP keys
+   have already rolled, but the validator has failed to update the set
+   of trust anchors.  When the third key rolls over there will only be
+   one trust anchor left that can do successful validation.  This is not
+   sufficient to enable automatic update of the trust anchors, hence the
+   new state is UNSYNCABLE.  Note, however, that the remaining
+   up-to-date trust anchor is still enough to do successful validation
+   so the validator is still "working" from a DNSSEC point of view.
+
+
+   The STALE state, finally, is where a validator ends up when it has
+   zero remaining current trust anchors.  This is a dangerous state,
+   since the stale trust anchors will cause all validation to fail.  The
+   escape is to remove the stale trust anchors and thereby revert to the
+   PRIMING state.
+
+
+3.4  Implementation notes
+
+
+   The DNSSEC protocol specification ordains that a DNSKEY to which a DS
+   record points should be self-signed.  Since the keys that serve as
+   trust anchors and the keys that are pointed to by DS records serve
+   the same purpose, they are both secure entry points, we RECOMMEND
+   that zone owners who want to facilitate the automated rollover scheme
+   documented herein self-sign DNSKEYs with the SEP bit set and that
+   implementation check that DNSKEYs with the SEP bit set are
+   self-signed.
+
+
+   In order to maintain a uniform way of determining that a keyset in
+   the zone has been replaced by a more recent set the automatic trust
+   update machine SHOULD only accept new DNSKEY RRsets if the
+   accompanying RRSIGs show a more recent inception date than the
+   present set of trust anchors.  This is also needed as a safe guard
+   against possible replay attacks where old updates are replayed
+   "backwards" (i.e.  one change at a time, but going in the wrong
+
+
+
+
+Ihren, et al.            Expires April 18, 2005                [Page 10]
+Internet-Draft    DNSSEC Threshold-based Trust Update       October 2004
+
+
+
+   direction, thereby luring the validator into the UNSYNCABLE and
+   finally STALE states).
+
+
+   In order to be resilient against failures the implementation should
+   collect the DNSKEY RRsets from (other) authoritative servers if
+   verification of the self signatures fails.
+
+
+   The threshold-based trust update mechanism SHOULD only be applied to
+   algorithms, as represented in the algorithm field in the DNSKEY/RRSIG
+   [3], that the resolver is aware of.  In other words the SEP keys of
+   unknown algorithms should not be used when counting the number of
+   available signatures (the N constant) and the SEP keys of unknown
+   algorithm should not be entered as trust anchors.
+
+
+   When in state UNSYNCABLE or STALE manual intervention will be needed
+   to return to the IN-SYNC state.  These states should be flagged.  The
+   most appropriate action is human audit possibly followed by
+   re-priming (Section 4) the keyset (i.e.  manual transfer to the
+   PRIMING state through removal of the configured trust anchors).
+
+
+   An implementation should regularly probe the the authoritative
+   nameservers for new keys.  Since there is no mechanism to publish
+   rollover frequencies this document RECOMMENDS zone owners not to roll
+   their key signing keys more often than once per month and resolver
+   administrators to probe for key rollsovers (and apply the threshold
+   criterion for acceptance of trust update) not less often than once
+   per month.  If the rollover frequency is higher than the probing
+   frequency then trust anchors may become stale.  The exact relation
+   between the frequencies depends on the number of SEP keys rolled by
+   the zone owner and the value M configured by the resolver
+   administrator.
+
+
+   In all the cases below a transaction where the threshold criterion is
+   not satisfied should be considered bad (i.e.  possibly spoofed or
+   otherwise corrupted data).  The most appropriate action is human
+   audit.
+
+
+   There is one case where a "bad" state may be escaped from in an
+   automated fashion.  This is when entering the STALE state where all
+   DNSSEC validation starts to fail.  If this happens it is concievable
+   that it is better to completely discard the stale trust anchors
+   (thereby reverting to the PRIMING state where validation is not
+   possible).  A local policy that automates removal of stale trust
+   anchors is therefore suggested.
+
+
+3.5  Possible transactions
+
+
+
+
+
+
+Ihren, et al.            Expires April 18, 2005                [Page 11]
+Internet-Draft    DNSSEC Threshold-based Trust Update       October 2004
+
+
+
+3.5.1  Single DNSKEY replaced
+
+
+   This is probably the most typical transaction on the zone owners
+   part.  The result should be that if the threshold criterion is
+   satisfied then the key store is updated by removal of the old trust
+   anchor and addition of the new key as a new trust anchor.  Note that
+   if the DNSKEY RRset contains exactly M keys replacement of keys is
+   not possible, i.e.  for automatic rollover to work M must be stricly
+   less than N.
+
+
+3.5.2  Addition of a new DNSKEY (no removal)
+
+
+   If the threshold criterion is satisfied then the new key is added as
+   a configured trust anchor.  Not more than N-M keys can be added at
+   once, since otherwise the algorithm will fail.
+
+
+3.5.3  Removal of old DNSKEY (no addition)
+
+
+   If the threshold criterion is satisfied then the old key is removed
+   from being a configured trust anchor.  Note that it is not possible
+   to reduce the size of the DNSKEY RRset to a size smaller than the
+   minimum required value for M.
+
+
+3.5.4  Multiple DNSKEYs replaced
+
+
+   Arguably it is not a good idea for the zone administrator to replace
+   several keys at the same time, but from the resolver point of view
+   this is exactly what will happen if the validating resolver for some
+   reason failed to notice a previous rollover event.
+
+
+   Not more than N-M keys can be replaced at one time or the threshold
+   criterion will not be satisfied.  Or, expressed another way: as long
+   as the number of changed keys is less than or equal to N-M the
+   validator is in state OUT-OF-SYNC.  When the number of changed keys
+   becomes greater than N-M the state changes to UNSYNCABLE and manual
+   action is needed.
+
+
+3.6  Removal of trust anchors for a trust point
+
+
+   If the parent of a secure entry point gets signed and it's trusted
+   keys get configured in the key store of the validating resolver then
+   the configured trust anchors for the child should be removed entirely
+   unless explicitly configured (in the utility configuration) to be an
+   exception.
+
+
+   The reason for such a configuration would be that the resolver has a
+   local policy that requires maintenance of trusted keys further down
+   the tree hierarchy than strictly needed from the point of view.
+
+
+
+
+Ihren, et al.            Expires April 18, 2005                [Page 12]
+Internet-Draft    DNSSEC Threshold-based Trust Update       October 2004
+
+
+
+   The default action when the parent zone changes from unsigned to
+   signed should be to remove the configured trust anchors for the
+   child.  This form of "garbage collect" will ensure that the automatic
+   rollover machinery scales as DNSSEC deployment progresses.
+
+
+3.7  No need for resolver-side overlap of old and new keys
+
+
+   It is worth pointing out that there is no need for the resolver to
+   keep state about old keys versus new keys, beyond the requirement of
+   tracking signature inception time for the covering RRSIGs as
+   described in Section 3.4.
+
+
+   From the resolver point of view there are only trusted and not
+   trusted keys.  The reason is that the zone owner needs to do proper
+   maintenance of RRSIGs regardless of the resolver rollover mechanism
+   and hence must ensure that no key rolled out out the DNSKEY set until
+   there cannot be any RRSIGs created by this key still legally cached.
+
+
+   Hence the rollover mechanism is entirely stateless with regard to the
+   keys involved: as soon as the resolver (or in this case the rollover
+   tracking utility) detects a change in the DNSKEY RRset (i.e.  it is
+   now in the state OUT-OF-SYNC) with a sufficient number of matching
+   RRSIGs the configured trust anchors are immediately updated (and
+   thereby the machine return to state IN-SYNC).  I.e.  the rollover
+   machine changes states (mostly oscillating between IN-SYNC and
+   OUT-OF-SYNC), but the status of the DNSSEC keys is stateless.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ihren, et al.            Expires April 18, 2005                [Page 13]
+Internet-Draft    DNSSEC Threshold-based Trust Update       October 2004
+
+
+
+4.  Bootstrapping automatic rollovers
+
+
+   It is expected that with the ability to automatically roll trust
+   anchors at trust points will follow a diminished unwillingness to
+   roll these keys, since the risks associated with stale keys are
+   minimized.
+
+
+   The problem of "priming" the trust anchors, or bringing them into
+   sync (which could happen if a resolver is off line for a long period
+   in which a set of SEP keys in a zone 'evolve' away from its trust
+   anchor configuration) remains.
+
+
+   For (re)priming we can rely on out of band technology and we propose
+   the following framework.
+
+
+4.1  Priming Keys
+
+
+   If all the trust anchors roll somewhat frequently (on the order of
+   months or at most about a year) then it will not be possible to
+   design a device, or a software distribution that includes trust
+   anchors, that after being manufactured is put on a shelf for several
+   key rollover periods before being brought into use (since no trust
+   anchors that were known at the time of manufacture remain active).
+
+
+   To alleviate this we propose the concept of "priming keys".  Priming
+   keys are ordinary DNSSEC Key Signing Keys with the characteristic
+   that
+   o  The private part of a priming key signs the DNSKEY RRset at the
+      security apex, i.e.  at least one RRSIG DNSKEY is created by a
+      priming key rather than by an "ordinary" trust anchor
+   o  the public parts of priming keys are not included in the DNSKEY
+      RRset.  Instead the public parts of priming keys are only
+      available out-of-band.
+   o  The public parts of the priming keys have a validity period.
+      Within this period they can be used to obtain trust anchors.
+   o  The priming key pairs are long lived (relative to the key rollover
+      period.)
+
+
+4.1.1  Bootstrapping trust anchors using a priming key
+
+
+   To install the trust anchors for a particular security apex an
+   administrator of a validating resolver will need to:
+   o  query for the DNSKEY RRset of the zone at the security apex;
+   o  verify the self signatures of all DNSKEYs in the RRset;
+   o  verify the signature of the RRSIG made with a priming key --
+      verification using one of the public priming keys that is valid at
+      that moment is sufficient;
+
+
+
+
+
+Ihren, et al.            Expires April 18, 2005                [Page 14]
+Internet-Draft    DNSSEC Threshold-based Trust Update       October 2004
+
+
+
+   o  create the trust anchors by extracting the DNSKEY RRs with the SEP
+      flag set.
+   The SEP keys with algorithms unknown to the validating resolver
+   SHOULD be ignored during the creation of the trust anchors.
+
+
+4.1.2  Distribution of priming keys
+
+
+   The public parts of the priming keys SHOULD be distributed
+   exclusively through out-of-DNS mechanisms.  The requirements for a
+   distribution mechanism are:
+   o  it can carry the "validity" period for the priming keys;
+   o  it can carry the self-signature of the priming keys;
+   o  and it allows for verification using trust relations outside the
+      DNS.
+   A distribution mechanism would benefit from:
+   o  the availability of revocation lists;
+   o  the ability of carrying zone owners policy information such as
+      recommended values for "M" and "N" and a rollover frequency;
+   o  and the technology on which is based is readily available.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ihren, et al.            Expires April 18, 2005                [Page 15]
+Internet-Draft    DNSSEC Threshold-based Trust Update       October 2004
+
+
+
+5.  The Threshold Rollover Mechanism vs Priming
+
+
+   There is overlap between the threshold-based trust updater and the
+   Priming method.  One could exclusively use the Priming method for
+   maintaining the trust anchors.  However the priming method probably
+   relies on "non-DNS' technology and may therefore not be available for
+   all devices that have a resolver.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ihren, et al.            Expires April 18, 2005                [Page 16]
+Internet-Draft    DNSSEC Threshold-based Trust Update       October 2004
+
+
+
+6.  Security Considerations
+
+
+6.1  Threshold-based Trust Update Security Considerations
+
+
+   A clear issue for resolvers will be how to ensure that they track all
+   rollover events for the zones they have configure trust anchors for.
+   Because of temporary outages validating resolvers may have missed a
+   rollover of a KSK.  The parameters that determine the robustness
+   against failures are: the length of the period between rollovers
+   during which the KSK set is stable and validating resolvers can
+   actually notice the change; the number of available KSKs (i.e.  N)
+   and the number of signatures that may fail to validate (i.e.  N-M).
+
+
+   With a large N (i.e.  many KSKs) and a small value of M this
+   operation becomes more robust since losing one key, for whatever
+   reason, will not be crucial.  Unfortunately the choice for the number
+   of KSKs is a local policy issue for the zone owner while the choice
+   for the parameter M is a local policy issue for the resolver
+   administrator.
+
+
+   Higher values of M increase the resilience against attacks somewhat;
+   more signatures need to verify for a rollover to be approved.  On the
+   other hand the number of rollover events that may pass unnoticed
+   before the resolver reaches the UNSYNCABLE state goes down.
+
+
+   The threshold-based trust update intentionally does not provide a
+   revocation mechanism.  In the case that a sufficient number of
+   private keys of a zone owner are simultaneously compromised the the
+   attacker may use these private keys to roll the trust anchors of (a
+   subset of) the resolvers.  This is obviously a bad situation but it
+   is not different from most other public keys systems.
+
+
+   However, it is important to point out that since any reasonable trust
+   anchor rollover policy (in validating resolvers) will require more
+   than one RRSIG to validate this proposal does provide security
+   concious zone administrators with the option of not storing the
+   individual private keys in the same location and thereby decreasing
+   the likelihood of simultaneous compromise.
+
+
+6.2  Priming Key Security Considerations
+
+
+   Since priming keys are not included in the DNSKEY RR set they are
+   less sensitive to packet size constraints and can be chosen
+   relatively large.  The private parts are only needed to sign the
+   DNSKEY RR set during the validity period of the particular priming
+   key pair.  Note that the private part of the priming key is used each
+   time when a DNSKEY RRset has to be resigned.  In practice there is
+   therefore little difference between the usage pattern of the private
+
+
+
+
+Ihren, et al.            Expires April 18, 2005                [Page 17]
+Internet-Draft    DNSSEC Threshold-based Trust Update       October 2004
+
+
+
+   part of key signing keys and priming keys.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ihren, et al.            Expires April 18, 2005                [Page 18]
+Internet-Draft    DNSSEC Threshold-based Trust Update       October 2004
+
+
+
+7.  IANA Considerations
+
+
+   NONE.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ihren, et al.            Expires April 18, 2005                [Page 19]
+Internet-Draft    DNSSEC Threshold-based Trust Update       October 2004
+
+
+
+8.  References
+
+
+8.1  Normative References
+
+
+   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
+        Levels", BCP 14, RFC 2119, March 1997.
+
+
+   [2]  Kolkman, O., Schlyter, J. and E. Lewis, "Domain Name System KEY
+        (DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag",
+        RFC 3757, May 2004.
+
+
+   [3]  Arends, R., "Resource Records for the DNS Security Extensions",
+        draft-ietf-dnsext-dnssec-records-10 (work in progress),
+        September 2004.
+
+
+8.2  Informative References
+
+
+   [4]  Arends, R., Austein, R., Massey, D., Larson, M. and S. Rose,
+        "DNS Security Introduction and Requirements",
+        draft-ietf-dnsext-dnssec-intro-12 (work in progress), September
+        2004.
+
+
+   [5]  Kolkman, O., "DNSSEC Operational Practices",
+        draft-ietf-dnsop-dnssec-operational-practices-01 (work in
+        progress), May 2004.
+
+
+   [6]  Housley, R., Ford, W., Polk, T. and D. Solo, "Internet X.509
+        Public Key Infrastructure Certificate and CRL Profile", RFC
+        2459, January 1999.
+
+
+
+Authors' Addresses
+
+
+   Johan Ihren
+   Autonomica AB
+   Bellmansgatan 30
+   Stockholm  SE-118 47
+   Sweden
+
+
+   EMail: johani@autonomica.se
+
+
+
+
+
+
+
+
+
+
+
+
+Ihren, et al.            Expires April 18, 2005                [Page 20]
+Internet-Draft    DNSSEC Threshold-based Trust Update       October 2004
+
+
+
+   Olaf M. Kolkman
+   RIPE NCC
+   Singel 256
+   Amsterdam  1016 AB
+   NL
+
+
+   Phone: +31 20 535 4444
+   EMail: olaf@ripe.net
+   URI:   http://www.ripe.net/
+
+
+
+   Bill Manning
+   EP.net
+   Marina del Rey, CA  90295
+   USA
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ihren, et al.            Expires April 18, 2005                [Page 21]
+Internet-Draft    DNSSEC Threshold-based Trust Update       October 2004
+
+
+
+Appendix A.  Acknowledgments
+
+
+   The present design for in-band automatic rollovers of DNSSEC trust
+   anchors is the result of many conversations and it is no longer
+   possible to remember exactly who contributed what.
+
+
+   In addition we've also had appreciated help from (in no particular
+   order) Paul Vixie, Sam Weiler, Suzanne Woolf, Steve Crocker, Matt
+   Larson and Mark Kosters.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ihren, et al.            Expires April 18, 2005                [Page 22]
+Internet-Draft    DNSSEC Threshold-based Trust Update       October 2004
+
+
+
+Appendix B.  Document History
+
+
+   This appendix will be removed if and when the document is submitted
+   to the RFC editor.
+
+
+   The version you are reading is tagged as $Revision: 1.1.230.1 $.
+
+
+   Text between square brackets, other than references, are editorial
+   comments and will be removed.
+
+
+B.1  prior to version 00
+
+
+   This draft was initially published as a personal submission under the
+   name draft-kolkman-dnsext-dnssec-in-band-rollover-00.txt.
+
+
+   Kolkman documented the ideas provided by Ihren and Manning.  In the
+   process of documenting (and prototyping) Kolkman changed some of the
+   details of the M-N algorithms working.  Ihren did not have a chance
+   to review the draft before Kolkman posted;
+
+
+   Kolkman takes responsibilities for omissions, fuzzy definitions and
+   mistakes.
+
+
+B.2  version 00
+   o  The name of the draft was changed as a result of the draft being
+      adopted as a working group document.
+   o  A small section on the concept of stale trust anchors was added.
+   o  The different possible states are more clearly defined, including
+      examples of transitions between states.
+   o  The terminology is changed throughout the document.  The old term
+      "M-N" is replaced by "threshold" (more or less).  Also the
+      interpretation of the constants M and N is significantly
+      simplified to bring the usage more in line with "standard"
+      threshold terminlogy.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ihren, et al.            Expires April 18, 2005                [Page 23]
+Internet-Draft    DNSSEC Threshold-based Trust Update       October 2004
+
+
+
+Intellectual Property Statement
+
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+
+Disclaimer of Validity
+
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+
+Copyright Statement
+
+
+   Copyright (C) The Internet Society (2004).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+
+Acknowledgment
+
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Ihren, et al.            Expires April 18, 2005                [Page 24] 
\ No newline at end of file
diff --git a/doc/draft/draft-ietf-dnsext-trustupdate-timers-02.txt b/doc/draft/draft-ietf-dnsext-trustupdate-timers-02.txt
new file mode 100644
index 0000000..7cb9063
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsext-trustupdate-timers-02.txt
@@ -0,0 +1,730 @@
+
+
+
+
+Network Working Group                                         M. StJohns
+Internet-Draft                                             Nominum, Inc.
+Expires: July 14, 2006                                  January 10, 2006
+
+
+               Automated Updates of DNSSEC Trust Anchors
+                draft-ietf-dnsext-trustupdate-timers-02
+
+Status of this Memo
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   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 draft documents 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 "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/ietf/1id-abstracts.txt.
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+   This Internet-Draft will expire on July 14, 2006.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   This document describes a means for automated, authenticated and
+   authorized updating of DNSSEC "trust anchors".  The method provides
+   protection against single key compromise of a key in the trust point
+   key set.  Based on the trust established by the presence of a current
+   anchor, other anchors may be added at the same place in the
+   hierarchy, and, ultimately, supplant the existing anchor.
+
+   This mechanism, if adopted, will require changes to resolver
+   management behavior (but not resolver resolution behavior), and the
+
+
+
+StJohns                   Expires July 14, 2006                 [Page 1]
+
+Internet-Draft             trustanchor-update               January 2006
+
+
+   addition of a single flag bit to the DNSKEY record.
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+     1.1.  Compliance Nomenclature  . . . . . . . . . . . . . . . . .  3
+     1.2.  Changes since -00  . . . . . . . . . . . . . . . . . . . .  3
+   2.  Theory of Operation  . . . . . . . . . . . . . . . . . . . . .  4
+     2.1.  Revocation . . . . . . . . . . . . . . . . . . . . . . . .  4
+     2.2.  Add Hold-Down  . . . . . . . . . . . . . . . . . . . . . .  5
+     2.3.  Remove Hold-down . . . . . . . . . . . . . . . . . . . . .  5
+     2.4.  Active Refresh . . . . . . . . . . . . . . . . . . . . . .  6
+     2.5.  Resolver Parameters  . . . . . . . . . . . . . . . . . . .  6
+       2.5.1.  Add Hold-Down Time . . . . . . . . . . . . . . . . . .  6
+       2.5.2.  Remove Hold-Down Time  . . . . . . . . . . . . . . . .  6
+       2.5.3.  Minimum Trust Anchors per Trust Point  . . . . . . . .  6
+   3.  Changes to DNSKEY RDATA Wire Format  . . . . . . . . . . . . .  6
+   4.  State Table  . . . . . . . . . . . . . . . . . . . . . . . . .  7
+     4.1.  Events . . . . . . . . . . . . . . . . . . . . . . . . . .  7
+     4.2.  States . . . . . . . . . . . . . . . . . . . . . . . . . .  8
+     4.3.  Trust Point Deletion . . . . . . . . . . . . . . . . . . .  8
+   5.  Scenarios  . . . . . . . . . . . . . . . . . . . . . . . . . .  8
+     5.1.  Adding A Trust Anchor  . . . . . . . . . . . . . . . . . .  9
+     5.2.  Deleting a Trust Anchor  . . . . . . . . . . . . . . . . .  9
+     5.3.  Key Roll-Over  . . . . . . . . . . . . . . . . . . . . . .  9
+     5.4.  Active Key Compromised . . . . . . . . . . . . . . . . . .  9
+     5.5.  Stand-by Key Compromised . . . . . . . . . . . . . . . . . 10
+   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
+   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
+     7.1.  Key Ownership vs Acceptance Policy . . . . . . . . . . . . 10
+     7.2.  Multiple Key Compromise  . . . . . . . . . . . . . . . . . 10
+     7.3.  Dynamic Updates  . . . . . . . . . . . . . . . . . . . . . 11
+   8.  Normative References . . . . . . . . . . . . . . . . . . . . . 11
+   Editorial Comments . . . . . . . . . . . . . . . . . . . . . . . .
+   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12
+   Intellectual Property and Copyright Statements . . . . . . . . . . 13
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+StJohns                   Expires July 14, 2006                 [Page 2]
+
+Internet-Draft             trustanchor-update               January 2006
+
+
+1.  Introduction
+
+   As part of the reality of fielding DNSSEC (Domain Name System
+   Security Extensions) [RFC2535] [RFC4033][RFC4034][RFC4035], the
+   community has come to the realization that there will not be one
+   signed name space, but rather islands of signed name space each
+   originating from specific points (i.e. 'trust points') in the DNS
+   tree.  Each of those islands will be identified by the trust point
+   name, and validated by at least one associated public key.  For the
+   purpose of this document we'll call the association of that name and
+   a particular key a 'trust anchor'.  A particular trust point can have
+   more than one key designated as a trust anchor.
+
+   For a DNSSEC-aware resolver to validate information in a DNSSEC
+   protected branch of the hierarchy, it must have knowledge of a trust
+   anchor applicable to that branch.  It may also have more than one
+   trust anchor for any given trust point.  Under current rules, a chain
+   of trust for DNSSEC-protected data that chains its way back to ANY
+   known trust anchor is considered 'secure'.
+
+   Because of the probable balkanization of the DNSSEC tree due to
+   signing voids at key locations, a resolver may need to know literally
+   thousands of trust anchors to perform its duties. (e.g.  Consider an
+   unsigned ".COM".)  Requiring the owner of the resolver to manually
+   manage this many relationships is problematic.  It's even more
+   problematic when considering the eventual requirement for key
+   replacement/update for a given trust anchor.  The mechanism described
+   herein won't help with the initial configuration of the trust anchors
+   in the resolvers, but should make trust point key replacement/
+   rollover more viable.
+
+   As mentioned above, this document describes a mechanism whereby a
+   resolver can update the trust anchors for a given trust point, mainly
+   without human intervention at the resolver.  There are some corner
+   cases discussed (e.g. multiple key compromise) that may require
+   manual intervention, but they should be few and far between.  This
+   document DOES NOT discuss the general problem of the initial
+   configuration of trust anchors for the resolver.
+
+1.1.  Compliance Nomenclature
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in BCP 14, [RFC2119].
+
+1.2.  Changes since -00
+
+   Added the concept of timer triggered resolver queries to refresh the
+
+
+
+StJohns                   Expires July 14, 2006                 [Page 3]
+
+Internet-Draft             trustanchor-update               January 2006
+
+
+   resolvers view of the trust anchor key RRSet.
+
+   Re-submitted expired draft as -01.  Updated DNSSEC RFC References.
+
+   Draft -02.  Added the IANA Considerations section.  Added text to
+   describe what happens if all trust anchors at a trust point are
+   deleted.
+
+
+2.  Theory of Operation
+
+   The general concept of this mechanism is that existing trust anchors
+   can be used to authenticate new trust anchors at the same point in
+   the DNS hierarchy.  When a new SEP key is added to a trust point
+   DNSKEY RRSet, and when that RRSet is validated by an existing trust
+   anchor, then the new key can be added to the set of trust anchors.
+
+   There are some issues with this approach which need to be mitigated.
+   For example, a compromise of one of the existing keys could allow an
+   attacker to add their own 'valid' data.  This implies a need for a
+   method to revoke an existing key regardless of whether or not that
+   key is compromised.  As another example assuming a single key
+   compromise, an attacker could add a new key and revoke all the other
+   old keys.
+
+2.1.  Revocation
+
+   Assume two trust anchor keys A and B. Assume that B has been
+   compromised.  Without a specific revocation bit, B could invalidate A
+   simply by sending out a signed trust point key set which didn't
+   contain A. To fix this, we add a mechanism which requires knowledge
+   of the private key of a DNSKEY to revoke that DNSKEY.
+
+   A key is considered revoked when the resolver sees the key in a self-
+   signed RRSet and the key has the REVOKE bit (see Section 6 below) set
+   to '1'.  Once the resolver sees the REVOKE bit, it MUST NOT use this
+   key as a trust anchor or for any other purposes except validating the
+   RRSIG over the DNSKEY RRSet specifically for the purpose of
+   validating the revocation.  Unlike the 'Add' operation below,
+   revocation is immediate and permanent upon receipt of a valid
+   revocation at the resolver.
+
+   N.B. A DNSKEY with the REVOKE bit set has a different fingerprint
+   than one without the bit set.  This affects the matching of a DNSKEY
+   to DS records in the parent, or the fingerprint stored at a resolver
+   used to configure a trust point. [msj3]
+
+   In the given example, the attacker could revoke B because it has
+
+
+
+StJohns                   Expires July 14, 2006                 [Page 4]
+
+Internet-Draft             trustanchor-update               January 2006
+
+
+   knowledge of B's private key, but could not revoke A.
+
+2.2.  Add Hold-Down
+
+   Assume two trust point keys A and B. Assume that B has been
+   compromised.  An attacker could generate and add a new trust anchor
+   key - C (by adding C to the DNSKEY RRSet and signing it with B), and
+   then invalidate the compromised key.  This would result in the both
+   the attacker and owner being able to sign data in the zone and have
+   it accepted as valid by resolvers.
+
+   To mitigate, but not completely solve, this problem, we add a hold-
+   down time to the addition of the trust anchor.  When the resolver
+   sees a new SEP key in a validated trust point DNSKEY RRSet, the
+   resolver starts an acceptance timer, and remembers all the keys that
+   validated the RRSet.  If the resolver ever sees the DNSKEY RRSet
+   without the new key but validly signed, it stops the acceptance
+   process and resets the acceptance timer.  If all of the keys which
+   were originally used to validate this key are revoked prior to the
+   timer expiring, the resolver stops the acceptance process and resets
+   the timer.
+
+   Once the timer expires, the new key will be added as a trust anchor
+   the next time the validated RRSet with the new key is seen at the
+   resolver.  The resolver MUST NOT treat the new key as a trust anchor
+   until the hold down time expires AND it has retrieved and validated a
+   DNSKEY RRSet after the hold down time which contains the new key.
+
+   N.B.: Once the resolver has accepted a key as a trust anchor, the key
+   MUST be considered a valid trust anchor by that resolver until
+   explictly revoked as described above.
+
+   In the given example, the zone owner can recover from a compromise by
+   revoking B and adding a new key D and signing the DNSKEY RRSet with
+   both A and B.
+
+   The reason this does not completely solve the problem has to do with
+   the distributed nature of DNS.  The resolver only knows what it sees.
+   A determined attacker who holds one compromised key could keep a
+   single resolver from realizing that key had been compromised by
+   intercepting 'real' data from the originating zone and substituting
+   their own (e.g. using the example, signed only by B).  This is no
+   worse than the current situation assuming a compromised key.
+
+2.3.  Remove Hold-down
+
+   A new key which has been seen by the resolver, but hasn't reached
+   it's add hold-down time, MAY be removed from the DNSKEY RRSet by the
+
+
+
+StJohns                   Expires July 14, 2006                 [Page 5]
+
+Internet-Draft             trustanchor-update               January 2006
+
+
+   zone owner.  If the resolver sees a validated DNSKEY RRSet without
+   this key, it waits for the remove hold-down time and then, if the key
+   hasn't reappeared, SHOULD discard any information about the key.
+
+2.4.  Active Refresh
+
+   A resolver which has been configured for automatic update of keys
+   from a particular trust point MUST query that trust point (e.g. do a
+   lookup for the DNSKEY RRSet and related RRSIG records) no less often
+   than the lesser of 15 days or half the original TTL for the DNSKEY
+   RRSet or half the RRSIG expiration interval.  The expiration interval
+   is the amount of time from when the RRSIG was last retrieved until
+   the expiration time in the RRSIG.
+
+   If the query fails, the resolver MUST repeat the query until
+   satisfied no more often than once an hour and no less often than the
+   lesser of 1 day or 10% of the original TTL or 10% of the original
+   expiration interval.
+
+2.5.  Resolver Parameters
+
+2.5.1.  Add Hold-Down Time
+
+   The add hold-down time is 30 days or the expiration time of the TTL
+   of the first trust point DNSKEY RRSet which contained the key,
+   whichever is greater.  This ensures that at least two validated
+   DNSKEY RRSets which contain the new key MUST be seen by the resolver
+   prior to the key's acceptance.
+
+2.5.2.  Remove Hold-Down Time
+
+   The remove hold-down time is 30 days.
+
+2.5.3.  Minimum Trust Anchors per Trust Point
+
+   A compliant resolver MUST be able to manage at least five SEP keys
+   per trust point.
+
+
+3.  Changes to DNSKEY RDATA Wire Format
+
+   Bit n [msj2] of the DNSKEY Flags field is designated as the 'REVOKE'
+   flag.  If this bit is set to '1', AND the resolver sees an
+   RRSIG(DNSKEY) signed by the associated key, then the resolver MUST
+   consider this key permanently invalid for all purposes except for
+   validing the revocation.
+
+
+
+
+
+StJohns                   Expires July 14, 2006                 [Page 6]
+
+Internet-Draft             trustanchor-update               January 2006
+
+
+4.  State Table
+
+   The most important thing to understand is the resolver's view of any
+   key at a trust point.  The following state table describes that view
+   at various points in the key's lifetime.  The table is a normative
+   part of this specification.  The initial state of the key is 'Start'.
+   The resolver's view of the state of the key changes as various events
+   occur.
+
+   [msj1] This is the state of a trust point key as seen from the
+   resolver.  The column on the left indicates the current state.  The
+   header at the top shows the next state.  The intersection of the two
+   shows the event that will cause the state to transition from the
+   current state to the next.
+
+                             NEXT STATE
+           --------------------------------------------------
+    FROM   |Start  |AddPend |Valid  |Missing|Revoked|Removed|
+   ----------------------------------------------------------
+   Start   |       |NewKey  |       |       |       |       |
+   ----------------------------------------------------------
+   AddPend |KeyRem |        |AddTime|       |       |
+   ----------------------------------------------------------
+   Valid   |       |        |       |KeyRem |Revbit |       |
+   ----------------------------------------------------------
+   Missing |       |        |KeyPres|       |Revbit |       |
+   ----------------------------------------------------------
+   Revoked |       |        |       |       |       |RemTime|
+   ----------------------------------------------------------
+   Removed |       |        |       |       |       |       |
+   ----------------------------------------------------------
+
+4.1.  Events
+   NewKey The resolver sees a valid DNSKEY RRSet with a new SEP key.
+      That key will become a new trust anchor for the named trust point
+      after its been present in the RRSet for at least 'add time'.
+   KeyPres The key has returned to the valid DNSKEY RRSet.
+   KeyRem The resolver sees a valid DNSKEY RRSet that does not contain
+      this key.
+   AddTime The key has been in every valid DNSKEY RRSet seen for at
+      least the 'add time'.
+   RemTime A revoked key has been missing from the trust point DNSKEY
+      RRSet for sufficient time to be removed from the trust set.
+   RevBit The key has appeared in the trust anchor DNSKEY RRSet with its
+      "REVOKED" bit set, and there is an RRSig over the DNSKEY RRSet
+      signed by this key.
+
+
+
+
+
+StJohns                   Expires July 14, 2006                 [Page 7]
+
+Internet-Draft             trustanchor-update               January 2006
+
+
+4.2.  States
+   Start The key doesn't yet exist as a trust anchor at the resolver.
+      It may or may not exist at the zone server, but hasn't yet been
+      seen at the resolver.
+   AddPend The key has been seen at the resolver, has its 'SEP' bit set,
+      and has been included in a validated DNSKEY RRSet.  There is a
+      hold-down time for the key before it can be used as a trust
+      anchor.
+   Valid The key has been seen at the resolver and has been included in
+      all validated DNSKEY RRSets from the time it was first seen up
+      through the hold-down time.  It is now valid for verifying RRSets
+      that arrive after the hold down time.  Clarification: The DNSKEY
+      RRSet does not need to be continuously present at the resolver
+      (e.g. its TTL might expire).  If the RRSet is seen, and is
+      validated (i.e. verifies against an existing trust anchor), this
+      key MUST be in the RRSet otherwise a 'KeyRem' event is triggered.
+   Missing This is an abnormal state.  The key remains as a valid trust
+      point key, but was not seen at the resolver in the last validated
+      DNSKEY RRSet.  This is an abnormal state because the zone operator
+      should be using the REVOKE bit prior to removal.  [Discussion
+      item: Should a missing key be considered revoked after some period
+      of time?]
+   Revoked This is the state a key moves to once the resolver sees an
+      RRSIG(DNSKEY) signed by this key where that DNSKEY RRSet contains
+      this key with its REVOKE bit set to '1'.  Once in this state, this
+      key MUST permanently be considered invalid as a trust anchor.
+   Removed After a fairly long hold-down time, information about this
+      key may be purged from the resolver.  A key in the removed state
+      MUST NOT be considered a valid trust anchor.
+
+4.3.  Trust Point Deletion
+
+   A trust point which has all of its trust anchors revoked is
+   considered deleted and is treated as if the trust point was never
+   configured.  If there are no superior trust points, data at and below
+   the deleted trust point are considered insecure.  If there there ARE
+   superior trust points, data at and below the deleted trust point are
+   evaluated with respect to the superior trust point.
+
+
+5.  Scenarios
+
+   The suggested model for operation is to have one active key and one
+   stand-by key at each trust point.  The active key will be used to
+   sign the DNSKEY RRSet.  The stand-by key will not normally sign this
+   RRSet, but the resolver will accept it as a trust anchor if/when it
+   sees the signature on the trust point DNSKEY RRSet.
+
+
+
+
+StJohns                   Expires July 14, 2006                 [Page 8]
+
+Internet-Draft             trustanchor-update               January 2006
+
+
+   Since the stand-by key is not in active signing use, the associated
+   private key may (and SHOULD) be provided with additional protections
+   not normally available to a key that must be used frequently.  E.g.
+   locked in a safe, split among many parties, etc.  Notionally, the
+   stand-by key should be less subject to compromise than an active key,
+   but that will be dependent on operational concerns not addressed
+   here.
+
+5.1.  Adding A Trust Anchor
+
+   Assume an existing trust anchor key 'A'.
+   1.  Generate a new key pair.
+   2.  Create a DNSKEY record from the key pair and set the SEP and Zone
+       Key bits.
+   3.  Add the DNSKEY to the RRSet.
+   4.  Sign the DNSKEY RRSet ONLY with the existing trust anchor key -
+       'A'.
+   5.  Wait a while.
+
+5.2.  Deleting a Trust Anchor
+
+   Assume existing trust anchors 'A' and 'B' and that you want to revoke
+   and delete 'A'.
+   1.  Set the revolcation bit on key 'A'.
+   2.  Sign the DNSKEY RRSet with both 'A' and 'B'.
+   'A' is now revoked.  The operator SHOULD include the revoked 'A' in
+   the RRSet for at least the remove hold-down time, but then may remove
+   it from the DNSKEY RRSet.
+
+5.3.  Key Roll-Over
+
+   Assume existing keys A and B. 'A' is actively in use (i.e. has been
+   signing the DNSKEY RRSet.)  'B' was the stand-by key. (i.e. has been
+   in the DNSKEY RRSet and is a valid trust anchor, but wasn't being
+   used to sign the RRSet.)
+   1.  Generate a new key pair 'C'.
+   2.  Add 'C' to the DNSKEY RRSet.
+   3.  Set the revocation bit on key 'A'.
+   4.  Sign the RRSet with 'A' and 'B'.
+   'A' is now revoked, 'B' is now the active key, and 'C' will be the
+   stand-by key once the hold-down expires.  The operator SHOULD include
+   the revoked 'A' in the RRSet for at least the remove hold-down time,
+   but may then remove it from the DNSKEY RRSet.
+
+5.4.  Active Key Compromised
+
+   This is the same as the mechanism for Key Roll-Over (Section 5.3)
+   above assuming 'A' is the active key.
+
+
+
+StJohns                   Expires July 14, 2006                 [Page 9]
+
+Internet-Draft             trustanchor-update               January 2006
+
+
+5.5.  Stand-by Key Compromised
+
+   Using the same assumptions and naming conventions as Key Roll-Over
+   (Section 5.3) above:
+   1.  Generate a new key pair 'C'.
+   2.  Add 'C' to the DNSKEY RRSet.
+   3.  Set the revocation bit on key 'B'.
+   4.  Sign the RRSet with 'A' and 'B'.
+   'B' is now revoked, 'A' remains the active key, and 'C' will be the
+   stand-by key once the hold-down expires.  'B' SHOULD continue to be
+   included in the RRSet for the remove hold-down time.
+
+
+6.  IANA Considerations
+
+   The IANA will need to assign a bit in the DNSKEY flags field (see
+   section 4.3 of [RFC3755]) for the REVOKE bit.  There are no other
+   IANA actions required.
+
+
+7.  Security Considerations
+
+7.1.  Key Ownership vs Acceptance Policy
+
+   The reader should note that, while the zone owner is responsible
+   creating and distributing keys, it's wholly the decision of the
+   resolver owner as to whether to accept such keys for the
+   authentication of the zone information.  This implies the decision
+   update trust anchor keys based on trust for a current trust anchor
+   key is also the resolver owner's decision.
+
+   The resolver owner (and resolver implementers) MAY choose to permit
+   or prevent key status updates based on this mechanism for specific
+   trust points.  If they choose to prevent the automated updates, they
+   will need to establish a mechanism for manual or other out-of-band
+   updates outside the scope of this document.
+
+7.2.  Multiple Key Compromise
+
+   This scheme permits recovery as long as at least one valid trust
+   anchor key remains uncompromised.  E.g. if there are three keys, you
+   can recover if two of them are compromised.  The zone owner should
+   determine their own level of comfort with respect to the number of
+   active valid trust anchors in a zone and should be prepared to
+   implement recovery procedures once they detect a compromise.  A
+   manual or other out-of-band update of all resolvers will be required
+   if all trust anchor keys at a trust point are compromised.
+
+
+
+
+StJohns                   Expires July 14, 2006                [Page 10]
+
+Internet-Draft             trustanchor-update               January 2006
+
+
+7.3.  Dynamic Updates
+
+   Allowing a resolver to update its trust anchor set based in-band key
+   information is potentially less secure than a manual process.
+   However, given the nature of the DNS, the number of resolvers that
+   would require update if a trust anchor key were compromised, and the
+   lack of a standard management framework for DNS, this approach is no
+   worse than the existing situation.
+
+8.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2535]  Eastlake, D., "Domain Name System Security Extensions",
+              RFC 2535, March 1999.
+
+   [RFC3755]  Weiler, S., "Legacy Resolver Compatibility for Delegation
+              Signer (DS)", RFC 3755, May 2004.
+
+   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
+              Rose, "DNS Security Introduction and Requirements",
+              RFC 4033, March 2005.
+
+   [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
+              Rose, "Resource Records for the DNS Security Extensions",
+              RFC 4034, March 2005.
+
+   [RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
+              Rose, "Protocol Modifications for the DNS Security
+              Extensions", RFC 4035, March 2005.
+
+Editorial Comments
+
+   [msj1]  msj: N.B. This table is preliminary and will be revised to
+           match implementation experience.  For example, should there
+           be a state for "Add hold-down expired, but haven't seen the
+           new RRSet"?
+
+   [msj2]  msj: To be assigned.
+
+   [msj3]  msj: For discussion: What's the implementation guidance for
+           resolvers currently with respect to the non-assigned flag
+           bits?  If they consider the flag bit when doing key matching
+           at the trust anchor, they won't be able to match.
+
+
+
+
+
+
+StJohns                   Expires July 14, 2006                [Page 11]
+
+Internet-Draft             trustanchor-update               January 2006
+
+
+Author's Address
+
+   Michael StJohns
+   Nominum, Inc.
+   2385 Bay Road
+   Redwood City, CA  94063
+   USA
+
+   Phone: +1-301-528-4729
+   Email: Mike.StJohns@nominum.com
+   URI:   www.nominum.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+StJohns                   Expires July 14, 2006                [Page 12]
+
+Internet-Draft             trustanchor-update               January 2006
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2006).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+StJohns                   Expires July 14, 2006                [Page 13]
+
+
diff --git a/doc/draft/draft-ietf-dnsext-tsig-sha-06.txt b/doc/draft/draft-ietf-dnsext-tsig-sha-06.txt
new file mode 100644
index 0000000..00476ae
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsext-tsig-sha-06.txt
@@ -0,0 +1,522 @@
+
+INTERNET-DRAFT                                    Donald E. Eastlake 3rd
+UPDATES RFC 2845                                   Motorola Laboratories
+Expires: July 2006                                          January 2006
+
+                  HMAC SHA TSIG Algorithm Identifiers
+                  ---- --- ---- --------- -----------
+                  <draft-ietf-dnsext-tsig-sha-06.txt>
+
+
+Status of This Document
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   This draft is intended to be become a Proposed Standard RFC.
+   Distribution of this document is unlimited. Comments should be sent
+   to the DNSEXT working group mailing list <namedroppers@ops.ietf.org>.
+
+   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 draft documents 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 "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/1id-abstracts.html
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html
+
+
+Abstract
+
+   Use of the Domain Name System TSIG resource record requires
+   specification of a cryptographic message authentication code.
+   Currently identifiers have been specified only for the HMAC MD5
+   (Message Digest) and GSS (Generic Security Service) TSIG algorithms.
+   This document standardizes identifiers and implementation
+   requirements for additional HMAC SHA (Secure Hash Algorithm) TSIG
+   algorithms and standardizes how to specify and handle the truncation
+   of HMAC values in TSIG.
+
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+
+
+D. Eastlake 3rd                                                 [Page 1]
+
+
+INTERNET-DRAFT                                 HMAC-SHA TSIG Identifiers
+
+
+Table of Contents
+
+      Status of This Document....................................1
+      Abstract...................................................1
+      Copyright Notice...........................................1
+
+      Table of Contents..........................................2
+
+      1. Introduction............................................3
+
+      2. Algorithms and Identifiers..............................4
+
+      3. Specifying Truncation...................................5
+      3.1 Truncation Specification...............................5
+
+      4. TSIG Truncation Policy and Error Provisions.............6
+
+      5. IANA Considerations.....................................7
+      6. Security Considerations.................................7
+      7. Copyright and Disclaimer................................7
+
+      8. Normative References....................................8
+      9. Informative References..................................8
+
+      Author's Address...........................................9
+      Additional IPR Provisions..................................9
+      Expiration and File Name...................................9
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+D. Eastlake 3rd                                                 [Page 2]
+
+
+INTERNET-DRAFT                                 HMAC-SHA TSIG Identifiers
+
+
+1. Introduction
+
+   [RFC 2845] specifies a TSIG Resource Record (RR) that can be used to
+   authenticate DNS (Domain Name System [STD 13]) queries and responses.
+   This RR contains a domain name syntax data item which names the
+   authentication algorithm used. [RFC 2845] defines the HMAC-MD5.SIG-
+   ALG.REG.INT name for authentication codes using the HMAC [RFC 2104]
+   algorithm with the MD5 [RFC 1321] hash algorithm. IANA has also
+   registered "gss-tsig" as an identifier for TSIG authentication where
+   the cryptographic operations are delegated to the Generic Security
+   Service (GSS) [RFC 3645].
+
+   It should be noted that use of TSIG presumes prior agreement, between
+   the resolver and server involved, as to the algorithm and key to be
+   used.
+
+   In Section 2, this document specifies additional names for TSIG
+   authentication algorithms based on US NIST SHA (United States,
+   National Institute of Science and Technology, Secure Hash Algorithm)
+   algorithms and HMAC and specifies the implementation requirements for
+   those algorithms.
+
+   In Section 3, this document specifies the effect of inequality
+   between the normal output size of the specified hash function and the
+   length of MAC (message authentication code) data given in the TSIG
+   RR. In particular, it specifies that a shorter length field value
+   specifies truncation and a longer length field is an error.
+
+   In Section 4, policy restrictions and implications related to
+   truncation and a new error code to indicate truncation shorter than
+   permitted by policy are described and specified.
+
+   The use herein of MUST, SHOULD, MAY, MUST NOT, and SHOULD NOT is as
+   defined in [RFC 2119].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+D. Eastlake 3rd                                                 [Page 3]
+
+
+INTERNET-DRAFT                                 HMAC-SHA TSIG Identifiers
+
+
+2. Algorithms and Identifiers
+
+   TSIG Resource Records (RRs) [RFC 2845] are used to authenticate DNS
+   queries and responses.  They are intended to be efficient symmetric
+   authentication codes based on a shared secret. (Asymmetric signatures
+   can be provided using the SIG RR [RFC 2931]. In particular, SIG(0)
+   can be used for transaction signatures.) Used with a strong hash
+   function, HMAC [RFC 2104] provides a way to calculate such symmetric
+   authentication codes. The only specified HMAC based TSIG algorithm
+   identifier has been HMAC-MD5.SIG-ALG.REG.INT based on MD5 [RFC 1321].
+
+   The use of SHA-1 [FIPS 180-2, RFC 3174], which is a 160 bit hash, as
+   compared with the 128 bits for MD5, and additional hash algorithms in
+   the SHA family [FIPS 180-2, RFC 3874, SHA2draft] with 224, 256, 384,
+   and 512 bits, may be preferred in some cases particularly since
+   increasingly successful cryptanalytic attacks are being made on the
+   shorter hashes.
+
+   Use of TSIG between a DNS resolver and server is by mutual agreement.
+   That agreement can include the support of additional algorithms and
+   criteria as to which algorithms and truncations are acceptable,
+   subject to the restriction and guidelines in Section 3 and 4 below.
+   Key agreement can be by the TKEY mechanism [RFC 2930] or other
+   mutually agreeable method.
+
+   The current HMAC-MD5.SIG-ALG.REG.INT and gss-tsig identifiers are
+   included in the table below for convenience.  Implementations which
+   support TSIG MUST also implement HMAC SHA1 and HMAC SHA256 and MAY
+   implement gss-tsig and the other algorithms listed below.
+
+         Mandatory      HMAC-MD5.SIG-ALG.REG.INT
+         Optional       gss-tsig
+         Mandatory      hmac-sha1
+         Optional       hmac-sha224
+         Mandatory      hmac-sha256
+         Optional       hamc-sha384
+         Optional       hmac-sha512
+
+   SHA-1 truncated to 96 bits (12 octets) SHOULD be implemented.
+
+
+
+
+
+
+
+
+
+
+
+
+
+D. Eastlake 3rd                                                 [Page 4]
+
+
+INTERNET-DRAFT                                 HMAC-SHA TSIG Identifiers
+
+
+3. Specifying Truncation
+
+   When space is at a premium and the strength of the full length of an
+   HMAC is not needed, it is reasonable to truncate the HMAC output and
+   use the truncated value for authentication. HMAC SHA-1 truncated to
+   96 bits is an option available in several IETF protocols including
+   IPSEC and TLS.
+
+   The TSIG RR [RFC 2845] includes a "MAC size" field, which gives the
+   size of the MAC field in octets. But [RFC 2845] does not specify what
+   to do if this MAC size differs from the length of the output of HMAC
+   for a particular hash function. Truncation is indicated by a MAC size
+   less than the HMAC size as specified below.
+
+
+
+3.1 Truncation Specification
+
+   The specification for TSIG handling is changed as follows:
+
+   1. If "MAC size" field is greater than HMAC output length:
+         This case MUST NOT be generated and if received MUST cause the
+      packet to be dropped and RCODE 1 (FORMERR) to be returned.
+
+   2. If "MAC size" field equals HMAC output length:
+         Operation is as described in [RFC 2845] with the entire output
+      HMAC output present.
+
+   3. "MAC size" field is less than HMAC output length but greater than
+      that specified in case 4 below:
+         This is sent when the signer has truncated the HMAC output to
+      an allowable length, as described in RFC 2104, taking initial
+      octets and discarding trailing octets. TSIG truncation can only be
+      to an integral number of octets. On receipt of a packet with
+      truncation thus indicated, the locally calculated MAC is similarly
+      truncated and only the truncated values compared for
+      authentication. The request MAC used when calculating the TSIG MAC
+      for a reply is the truncated request MAC.
+
+   4. "MAC size" field is less than the larger of 10 (octets) and half
+      the length of the hash function in use:
+         With the exception of certain TSIG error messages described in
+      RFC 2845 section 3.2 where it is permitted that the MAC size be
+      zero, this case MUST NOT be generated and if received MUST cause
+      the packet to be dropped and RCODE 1 (FORMERR) to be returned. The
+      size limit for this case can also, for the hash functions
+      mentioned in this document, be stated as less than half the hash
+      function length for hash functions other than MD5 and less than 10
+      octets for MD5.
+
+
+
+D. Eastlake 3rd                                                 [Page 5]
+
+
+INTERNET-DRAFT                                 HMAC-SHA TSIG Identifiers
+
+
+4. TSIG Truncation Policy and Error Provisions
+
+   Use of TSIG is by mutual agreement between a resolver and server.
+   Implicit in such "agreement" are criterion as to acceptable keys and
+   algorithms and, with the extensions in this document, truncations.
+   Note that it is common for implementations to bind the TSIG secret
+   key or keys that may be in place at a resolver and server to
+   particular algorithms. Thus such implementations only permit the use
+   of an algorithm if there is an associated key in place. Receipt of an
+   unknown, unimplemented, or disabled algorithm typically results in a
+   BADKEY error.
+
+      Local policies MAY require the rejection of TSIGs even though they
+   use an algorithm for which implementation is mandatory.
+
+      When a local policy permits acceptance of a TSIG with a particular
+   algorithm and a particular non-zero amount of truncation it SHOULD
+   also permit the use of that algorithm with lesser truncation (a
+   longer MAC) up to the full HMAC output.
+
+      Regardless of a lower acceptable truncated MAC length specified by
+   local policy, a reply SHOULD be sent with a MAC at least as long as
+   that in the corresponding request unless the request specified a MAC
+   length longer than the HMAC output.
+
+      Implementations permitting multiple acceptable algorithms and/or
+   truncations SHOULD permit this list to be ordered by presumed
+   strength and SHOULD allow different truncations for the same
+   algorithm to be treated as separate entities in this list. When so
+   implemented, policies SHOULD accept a presumed stronger algorithm and
+   truncation than the minimum strength required by the policy.
+
+      If a TSIG is received with truncation which is permitted under
+   Section 3 above but the MAC is too short for the local policy in
+   force, an RCODE of TBA [22 suggested](BADTRUNC) MUST be returned.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+D. Eastlake 3rd                                                 [Page 6]
+
+
+INTERNET-DRAFT                                 HMAC-SHA TSIG Identifiers
+
+
+5. IANA Considerations
+
+   This document, on approval for publication as a standards track RFC,
+   (1) registers the new TSIG algorithm identifiers listed in Section 2
+   with IANA and (2) allocates the BADTRUNC RCODE TBA [22 suggested] in
+   Section 4. [RFC 2845]
+
+
+
+6. Security Considerations
+
+   For all of the message authentication code algorithms listed herein,
+   those producing longer values are believed to be stronger; however,
+   while there have been some arguments that mild truncation can
+   strengthen a MAC by reducing the information available to an
+   attacker, excessive truncation clearly weakens authentication by
+   reducing the number of bits an attacker has to try to break the
+   authentication by brute force [RFC 2104].
+
+   Significant progress has been made recently in cryptanalysis of hash
+   function of the type used herein, all of which ultimately derive from
+   the design of MD4. While the results so far should not effect HMAC,
+   the stronger SHA-1 and SHA-256 algorithms are being made mandatory
+   due to caution.
+
+   See the Security Considerations section of [RFC 2845].  See also the
+   Security Considerations section of [RFC 2104] from which the limits
+   on truncation in this RFC were taken.
+
+
+
+7. Copyright and Disclaimer
+
+   Copyright (C) The Internet Society (2006).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+
+
+
+D. Eastlake 3rd                                                 [Page 7]
+
+
+INTERNET-DRAFT                                 HMAC-SHA TSIG Identifiers
+
+
+8. Normative References
+
+   [FIPS 180-2] - "Secure Hash Standard", (SHA-1/224/256/384/512) US
+   Federal Information Processing Standard, with Change Notice 1,
+   February 2004.
+
+   [RFC 1321] - Rivest, R., "The MD5 Message-Digest Algorithm ", RFC
+   1321, April 1992.
+
+   [RFC 2104] - Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
+   Hashing for Message Authentication", RFC 2104, February 1997.
+
+   [RFC 2119] - Bradner, S., "Key words for use in RFCs to Indicate
+   Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC 2845] - Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.
+   Wellington, "Secret Key Transaction Authentication for DNS (TSIG)",
+   RFC 2845, May 2000.
+
+   [RFC 3174] - Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm
+   1 (SHA1)", RFC 3174, September 2001.
+
+   [RFC 3874] - R. Housely, "A 224-bit One-way Hash Function: SHA-224",
+   September 2004,
+
+   [SHA2draft] - Eastlake, D., T. Hansen, "US Secure Hash Algorithms
+   (SHA)", draft-eastlake-sha2-*.txt, work in progress.
+
+   [STD 13]
+         Mockapetris, P., "Domain names - concepts and facilities", STD
+         13, RFC 1034, November 1987.
+
+         Mockapetris, P., "Domain names - implementation and
+         specification", STD 13, RFC 1035, November 1987.
+
+
+
+9. Informative References.
+
+   [RFC 2930] - Eastlake 3rd, D., "Secret Key Establishment for DNS
+   (TKEY RR)", RFC 2930, September 2000.
+
+   [RFC 2931] - Eastlake 3rd, D., "DNS Request and Transaction
+   Signatures ( SIG(0)s )", RFC 2931, September 2000.
+
+   [RFC 3645] - Kwan, S., Garg, P., Gilroy, J., Esibov, L., Westhead,
+   J., and R. Hall, "Generic Security Service Algorithm for Secret Key
+   Transaction Authentication for DNS (GSS-TSIG)", RFC 3645, October
+   2003.
+
+
+
+D. Eastlake 3rd                                                 [Page 8]
+
+
+INTERNET-DRAFT                                 HMAC-SHA TSIG Identifiers
+
+
+Author's Address
+
+   Donald E. Eastlake 3rd
+   Motorola Laboratories
+   155 Beaver Street
+   Milford, MA 01757 USA
+
+   Telephone:   +1-508-786-7554 (w)
+
+   EMail:       Donald.Eastlake@motorola.com
+
+
+
+Additional IPR Provisions
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed
+   to pertain to the implementation or use of the technology
+   described in this document or the extent to which any license
+   under such rights might or might not be available; nor does it
+   represent that it has made any independent effort to identify any
+   such rights.  Information on the procedures with respect to
+   rights in RFC documents can be found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use
+   of such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository
+   at http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention
+   any copyrights, patents or patent applications, or other
+   proprietary rights that may cover technology that may be required
+   to implement this standard.  Please address the information to the
+   IETF at ietf-ipr@ietf.org.
+
+
+
+Expiration and File Name
+
+   This draft expires in July 2006.
+
+   Its file name is draft-ietf-dnsext-tsig-sha-06.txt
+
+
+
+
+
+
+
+
+D. Eastlake 3rd                                                 [Page 9]
+
diff --git a/doc/draft/draft-ietf-dnsext-wcard-clarify-10.txt b/doc/draft/draft-ietf-dnsext-wcard-clarify-10.txt
new file mode 100644
index 0000000..9cf88a5
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsext-wcard-clarify-10.txt
@@ -0,0 +1,1063 @@
+Internet-Draft                  dnsext-wcard           January 9, 2006
+
+DNSEXT Working Group                                          E. Lewis
+INTERNET DRAFT                                                 NeuStar
+Expiration Date: July 9, 2006                          January 9, 2006
+Updates RFC 1034, RFC 2672
+
+                              The Role of Wildcards
+                            in the Domain Name System
+                      draft-ietf-dnsext-wcard-clarify-10.txt
+
+Status of this Memo
+
+      By submitting this Internet-Draft, each author represents that
+      any applicable patent or other IPR claims of which he or she is
+      aware have been or will be disclosed, and any of which he or she
+      becomes aware will be disclosed, in accordance with Section 6 of
+      BCP 79.
+
+      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 draft documents 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 "work in
+      progress."
+
+      The list of current Internet-Drafts can be accessed at
+        http://www.ietf.org/ietf/1id-abstracts.txt
+
+      The list of Internet-Draft Shadow Directories can be accessed at
+        http://www.ietf.org/shadow.html
+
+      This Internet-Draft will expire on July 9, 2006.
+
+Copyright Notice
+
+      Copyright (C) The Internet Society (2006).
+
+Abstract
+
+      This is an update to the wildcard definition of RFC 1034.  The
+      interaction with wildcards and CNAME is changed, an error
+      condition removed, and the words defining some concepts central
+      to wildcards are changed.  The overall goal is not to change
+      wildcards, but to refine the definition of RFC 1034.
+
+
+
+
+DNSEXT Working Group        Expires July 9, 2006             [Page  1]
+
+Internet-Draft                  dnsext-wcard           January 9, 2006
+
+Table of Contents
+
+1.    Introduction   .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  3
+1 1   Motivation                                                     3
+1 2   The Original Definition                                        3
+1 3   Roadmap to This Document                                       4
+1 3 1 New Terms                                                      4
+1.3.2 Changed Text                                                   5
+1.3.3 Considerations with Special Types                              5
+1.4   Standards Terminology                                          5
+2.    Wildcard Syntax   .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  6
+2.1   Identifying a Wildcard                                         6
+2.1.1 Wild Card Domain Name and Asterisk Label                       6
+2.1.2 Asterisks and Other Characters                                 6
+2.1.3 Non-terminal Wild Card Domain Names                            6
+2.2   Existence Rules                                                7
+2.2.1 An Example                                                     7
+2.2.2 Empty Non-terminals                                            9
+2.2.3 Yet Another Definition of Existence                           10
+2.3   When is a Wild Card Domain Name Not Special                   10
+3.    Impact of a Wild Card Domain Name On a Response .  .  .  .  . 10
+3.1   Step 2                                                        10
+3.2   Step 3                                                        11
+3.3   Part 'c'                                                      11
+3.3.1 Closest Encloser and the Source of Synthesis                  12
+3.3.2 Closest Encloser and Source of Synthesis Examples             12
+3.3.3 Type Matching                                                 13
+4.    Considerations with Special Types   .  .  .  .  .  .  .  .  . 13
+4.1   SOA RRSet at a Wild Card Domain Name                          13
+4.2   NS RRSet at a Wild Card Domain Name                           14
+4.2.1 Discarded Notions                                             14
+4.3   CNAME RRSet at a Wild Card Domain Name                        15
+4.4   DNAME RRSet at a Wild Card Domain Name                        15
+4.5   SRV RRSet at a Wild Card Domain Name                          16
+4.6   DS RRSet at a Wild Card Domain Name                           16
+4.7   NSEC RRSet at a Wild Card Domain Name                         17
+4.8   RRSIG at a Wild Card Domain Name                              17
+4.9   Empty Non-terminal Wild Card Domain Name                      17
+5.    Security Considerations .  .  .  .  .  .  .  .  .  .  .  .  . 17
+6.    IANA Considerations     .  .  .  .  .  .  .  .  .  .  .  .  . 17
+7.    References              .  .  .  .  .  .  .  .  .  .  .  .  . 17
+8.    Editor                  .  .  .  .  .  .  .  .  .  .  .  .  . 18
+9.    Others Contributing to the Document    .  .  .  .  .  .  .  . 18
+10.   Trailing Boilerplate    .  .  .  .  .  .  .  .  .  .  .  .  . 19
+
+
+
+
+
+
+
+
+DNSEXT Working Group        Expires July 9, 2006             [Page  2]
+
+Internet-Draft                  dnsext-wcard           January 9, 2006
+
+1. Introduction
+
+      In RFC 1034 [RFC1034], sections 4.3.2 and 4.3.3 describe the
+      synthesis of answers from special resource records called
+      wildcards.  The definition in RFC 1034 is incomplete and has
+      proven to be confusing.  This document describes the wildcard
+      synthesis by adding to the discussion and making limited
+      modifications.  Modifications are made to close inconsistencies
+      that have led to interoperability issues.  This description
+      does not expand the service intended by the original definition.
+
+      Staying within the spirit and style of the original documents,
+      this document avoids specifying rules for DNS implementations
+      regarding wildcards.  The intention is to only describe what is
+      needed for interoperability, not restrict implementation choices.
+      In addition, consideration is given to minimize any backwards
+      compatibility issues with implementations that comply with RFC
+      1034's definition.
+
+      This document is focused on the concept of wildcards as defined
+      in RFC 1034.  Nothing is implied regarding alternative means of
+      synthesizing resource record sets, nor are alternatives discussed.
+
+1.1 Motivation
+
+      Many DNS implementations diverge, in different ways, from the
+      original definition of wildcards.  Although there is clearly a
+      need to clarify the original documents in light of this alone,
+      the impetus for this document lay in the engineering of the DNS
+      security extensions [RFC4033].  With an unclear definition of
+      wildcards the design of authenticated denial became entangled.
+
+      This document is intended to limit its changes, documenting only
+      those based on implementation experience, and to remain as close
+      to the original document as possible.  To reinforce that this
+      document is meant to clarify and adjust and not redefine wildcards,
+      relevant sections of RFC 1034 are repeated verbatim to facilitate
+      comparison of the old and new text.
+
+1.2 The Original Definition
+
+      The definition of the wildcard concept is comprised by the
+      documentation of the algorithm by which a name server prepares
+      a response (in RFC 1034's section 4.3.2) and the way in which
+      a resource record (set) is identified as being a source of
+      synthetic data (section 4.3.3).
+
+      This is the definition of the term "wildcard" as it appears in
+      RFC 1034, section 4.3.3.
+
+
+
+DNSEXT Working Group        Expires July 9, 2006             [Page  3]
+
+Internet-Draft                  dnsext-wcard           January 9, 2006
+
+# In the previous algorithm, special treatment was given to RRs with
+# owner names starting with the label "*".  Such RRs are called
+# wildcards. Wildcard RRs can be thought of as instructions for
+# synthesizing RRs.  When the appropriate conditions are met, the name
+# server creates RRs with an owner name equal to the query name and
+# contents taken from the wildcard RRs.
+
+      This passage follows the algorithm in which the term wildcard
+      is first used.   In this definition, wildcard refers to resource
+      records.  In other usage, wildcard has referred to domain names,
+      and it has been used to describe the operational practice of
+      relying on wildcards to generate answers.  It is clear from this
+      that there is a need to define clear and unambiguous terminology
+      in the process of discussing wildcards.
+
+      The mention of the use of wildcards in the preparation of a
+      response is contained in step 3c of RFC 1034's section 4.3.2
+      entitled "Algorithm."  Note that "wildcard" does not appear in
+      the algorithm, instead references are made to the "*" label.
+      The portion of the algorithm relating to wildcards is
+      deconstructed in detail in section 3 of this document, this is
+      the beginning of the relevant portion of the "Algorithm."
+
+#    c. If at some label, a match is impossible (i.e., the
+#       corresponding label does not exist), look to see if [...]
+#       the "*" label exists.
+
+      The scope of this document is the RFC 1034 definition of
+      wildcards and the implications of updates to those documents,
+      such as DNSSEC.  Alternate schemes for synthesizing answers are
+      not considered.  (Note that there is no reference listed.  No
+      document is known to describe any alternate schemes, although
+      there has been some mention of them in mailing lists.)
+
+1.3 Roadmap to This Document
+
+      This document accomplishes these three items.
+      o Defines new terms
+      o Makes minor changes to avoid conflicting concepts
+      o Describes the actions of certain resource records as wildcards
+
+1.3.1 New Terms
+
+      To help in discussing what resource records are wildcards, two
+      terms will be defined - "asterisk label" and "wild card domain
+      name".  These are defined in section 2.1.1.
+
+      To assist in clarifying the role of wildcards in the name server
+      algorithm in RFC 1034, 4.3.2, "source of synthesis" and "closest
+      encloser" are defined.  These definitions are in section 3.3.2.
+      "Label match" is defined in section 3.2.
+
+DNSEXT Working Group        Expires July 9, 2006             [Page  4]
+
+Internet-Draft                  dnsext-wcard           January 9, 2006
+
+      The new terms are used to make discussions of wildcards clearer.
+      Terminology doesn't directly have an impact on implementations.
+
+1.3.2 Changed Text
+
+      The definition of "existence" is changed superficially.  This
+      change will not be apparent to implementations; it is needed to
+      make descriptions more precise.  The change appears in section
+      2.2.3.
+
+      RFC 1034, section 4.3.3., seems to prohibit having two asterisk
+      labels in a wildcard owner name.  With this document the
+      restriction is removed entirely.  This change and its implications
+      are in section 2.1.3.
+
+      The actions when a source of synthesis owns a CNAME RR are
+      changed to mirror the actions if an exact match name owns a
+      CNAME RR.  This is an addition to the words in RFC 1034,
+      section 4.3.2, step 3, part c.  The discussion of this is in
+      section 3.3.3.
+
+      Only the latter change represents an impact to implementations.
+      The definition of existence is not a protocol impact.  The change
+      to the restriction on names is unlikely to have an impact, as
+      RFC 1034 contained no specification on when and how to enforce the
+      restriction.
+
+1.3.3 Considerations with Special Types
+
+      This document describes semantics of wildcard RRSets for
+      "interesting" types as well as empty non-terminal wildcards.
+      Understanding these situations in the context of wildcards has
+      been clouded because these types incur special processing if
+      they are the result of an exact match.  This discussion is in
+      section 4.
+
+      These discussions do not have an implementation impact, they cover
+      existing knowledge of the types, but to a greater level of detail.
+
+1.4 Standards Terminology
+
+      This document does not use terms as defined in "Key words for use
+      in RFCs to Indicate Requirement Levels." [RFC2119]
+
+      Quotations of RFC 1034 are denoted by a '#' in the leftmost
+      column.  References to section "4.3.2" are assumed to refer
+      to RFC 1034's section 4.3.2, simply titled "Algorithm."
+
+
+
+
+
+DNSEXT Working Group        Expires July 9, 2006             [Page  5]
+
+Internet-Draft                  dnsext-wcard           January 9, 2006
+
+2. Wildcard Syntax
+
+      The syntax of a wildcard is the same as any other DNS resource
+      record, across all classes and types.  The only significant
+      feature is the owner name.
+
+      Because wildcards are encoded as resource records with special
+      names, they are included in zone transfers and incremental zone
+      transfers[RFC1995] just as non-wildcard resource records are.
+      This feature has been under appreciated until discussions on
+      alternative approaches to wildcards appeared on mailing lists.
+
+2.1 Identifying a Wildcard
+
+      To provide a more accurate description of wildcards, the
+      definition has to start with a discussion of the domain names
+      that appear as owners.  Two new terms are needed, "Asterisk
+      Label" and "Wild Card Domain Name."
+
+2.1.1 Wild Card Domain Name and Asterisk Label
+
+      A "wild card domain name" is defined by having its initial
+      (i.e., left-most or least significant) label be, in binary format:
+
+           0000 0001 0010 1010 (binary) = 0x01 0x2a (hexadecimal)
+
+      The first octet is the normal label type and length for a 1 octet
+      long label, the second octet is the ASCII representation [RFC20]
+      for the '*' character.
+
+      A descriptive name of a label equaling that value is an "asterisk
+      label."
+
+      RFC 1034's definition of wildcard would be "a resource record
+      owned by a wild card domain name."
+
+2.1.2 Asterisks and Other Characters
+
+      No label values other than that in section 2.1.1 are asterisk
+      labels, hence names beginning with other labels are never wild
+      card domain names.  Labels such as 'the*' and '**' are not
+      asterisk labels so these labels do not start wild card domain
+      names.
+
+2.1.3 Non-terminal Wild Card Domain Names
+
+      In section 4.3.3, the following is stated:
+
+# ..........................  The owner name of the wildcard RRs is of
+# the form "*.<anydomain>", where <anydomain> is any domain name.
+# <anydomain> should not contain other * labels......................
+
+DNSEXT Working Group        Expires July 9, 2006             [Page  6]
+
+Internet-Draft                  dnsext-wcard           January 9, 2006
+
+      The restriction is now removed.  The original documentation of it
+      is incomplete and the restriction does not serve any purpose
+      given years of operational experience.
+
+      There are three possible reasons for putting the restriction in
+      place, but none of the three has held up over time.  One is
+      that the restriction meant that there would never be subdomains
+      of wild card domain names, but the restriciton as stated still
+      permits "example.*.example." for instance.  Another is that
+      wild card domain names are not intended to be empty non-terminals,
+      but this situation does not disrupt the algorithm in 4.3.2.
+      Finally, "nested" wild card domain names are not ambiguous once
+      the concept of the closest encloser had been documented.
+
+      A wild card domain name can have subdomains.  There is no need
+      to inspect the subdomains to see if there is another asterisk
+      label in any subdomain.
+
+      A wild card domain name can be an empty non-terminal.  (See the
+      upcoming sections on empty non-terminals.)  In this case, any
+      lookup encountering it will terminate as would any empty
+      non-terminal match.
+
+2.2 Existence Rules
+
+      The notion that a domain name 'exists' is mentioned in the
+      definition of wildcards.  In section 4.3.3 of RFC 1034:
+
+# Wildcard RRs do not apply:
+#
+...
+#   - When the query name or a name between the wildcard domain and
+#     the query name is know[n] to exist.  For example, if a wildcard
+
+      "Existence" is therefore an important concept in the understanding
+      of wildcards.  Unfortunately, the definition of what exists, in RFC
+      1034, is unclear.  So, in sections 2.2.2. and 2.2.3, another look is
+      taken at the definition of existence.
+
+2.2.1 An Example
+
+      To illustrate what is meant by existence consider this complete
+      zone:
+
+
+
+
+
+
+
+
+
+DNSEXT Working Group        Expires July 9, 2006             [Page  7]
+
+Internet-Draft                  dnsext-wcard           January 9, 2006
+
+        $ORIGIN example.
+        example.                 3600 IN  SOA   <SOA RDATA>
+        example.                 3600     NS    ns.example.com.
+        example.                 3600     NS    ns.example.net.
+        *.example.               3600     TXT   "this is a wild card"
+        *.example.               3600     MX    10 host1.example.
+        sub.*.example.           3600     TXT   "this is not a wild card"
+        host1.example.           3600     A     192.0.4.1
+        _ssh._tcp.host1.example. 3600     SRV  <SRV RDATA>
+        _ssh._tcp.host2.example. 3600     SRV  <SRV RDATA>
+        subdel.example.          3600     NS   ns.example.com.
+        subdel.example.          3600     NS   ns.example.net.
+
+      A look at the domain names in a tree structure is helpful:
+
+                                    |
+                    -------------example------------
+                   /           /         \          \
+                  /           /           \          \
+                 /           /             \          \
+                *          host1          host2      subdel
+                |            |             |
+                |            |             |
+               sub         _tcp          _tcp
+                             |             |
+                             |             |
+                           _ssh          _ssh
+
+      The following responses would be synthesized from one of the
+      wildcards in the zone:
+
+          QNAME=host3.example. QTYPE=MX, QCLASS=IN
+               the answer will be a "host3.example. IN MX ..."
+
+          QNAME=host3.example. QTYPE=A, QCLASS=IN
+               the answer will reflect "no error, but no data"
+               because there is no A RR set at '*.example.'
+
+          QNAME=foo.bar.example. QTYPE=TXT, QCLASS=IN
+               the answer will be "foo.bar.example. IN TXT ..."
+               because bar.example. does not exist, but the wildcard
+               does.
+
+      The following responses would not be synthesized from any of the
+      wildcards in the zone:
+
+          QNAME=host1.example., QTYPE=MX, QCLASS=IN
+               because host1.example. exists
+
+          QNAME=sub.*.example., QTYPE=MX, QCLASS=IN
+               because sub.*.example. exists
+
+DNSEXT Working Group        Expires July 9, 2006             [Page  8]
+
+Internet-Draft                  dnsext-wcard           January 9, 2006
+
+          QNAME=_telnet._tcp.host1.example., QTYPE=SRV, QCLASS=IN
+               because _tcp.host1.example. exists (without data)
+
+          QNAME=host.subdel.example., QTYPE=A, QCLASS=IN
+               because subdel.example. exists (and is a zone cut)
+
+          QNAME=ghost.*.example., QTYPE=MX, QCLASS=IN
+               because *.example. exists
+
+      The final example highlights one common misconception about
+      wildcards.  A wildcard "blocks itself" in the sense that a
+      wildcard does not match its own subdomains.  I.e. "*.example."
+      does not match all names in the "example." zone, it fails to
+      match the names below "*.example." To cover names under
+      "*.example.", another wild card domain name is needed -
+      "*.*.example." - which covers all but it's own subdomains.
+
+2.2.2 Empty Non-terminals
+
+      Empty non-terminals [RFC2136, Section 7.16] are domain names
+      that own no resource records but have subdomains that do.  In
+      section 2.2.1, "_tcp.host1.example." is an example of a empty
+      non-terminal name.  Empty non-terminals are introduced by this
+      text in section 3.1 of RFC 1034:
+
+# The domain name space is a tree structure.  Each node and leaf on
+# the tree corresponds to a resource set (which may be empty).  The
+# domain system makes no distinctions between the uses of the
+# interior nodes and leaves, and this memo uses the term "node" to
+# refer to both.
+
+      The parenthesized "which may be empty" specifies that empty non-
+      terminals are explicitly recognized, and that empty non-terminals
+      "exist."
+
+      Pedantically reading the above paragraph can lead to an
+      interpretation that all possible domains exist - up to the
+      suggested limit of 255 octets for a domain name [RFC1035].
+      For example, www.example. may have an A RR, and as far as is
+      practically concerned, is a leaf of the domain tree.  But the
+      definition can be taken to mean that sub.www.example. also
+      exists, albeit with no data.  By extension, all possible domains
+      exist, from the root on down.
+
+      As RFC 1034 also defines "an authoritative name error indicating
+      that the name does not exist" in section 4.3.1, so this apparently
+      is not the intent of the original definition, justifying the
+      need for an updated definition in the next section.
+
+
+
+
+DNSEXT Working Group        Expires July 9, 2006             [Page  9]
+
+Internet-Draft                  dnsext-wcard           January 9, 2006
+
+2.2.3 Yet Another Definition of Existence
+
+      RFC1034's wording is fixed by the following paragraph:
+
+      The domain name space is a tree structure.  Nodes in the tree
+      either own at least one RRSet and/or have descendants that
+      collectively own at least one RRSet.  A node may exist with no
+      RRSets only if it has descendents that do, this node is an empty
+      non-terminal.
+
+      A node with no descendants is a leaf node.  Empty leaf nodes do
+      not exist.
+
+      Note that at a zone boundary, the domain name owns data,
+      including the NS RR set.  In the delegating zone, the NS RR
+      set is not authoritative, but that is of no consequence here.
+      The domain name owns data, therefore, it exists.
+
+2.3 When is a Wild Card Domain Name Not Special
+
+      When a wild card domain name appears in a message's query section,
+      no special processing occurs.  An asterisk label in a query name
+      only matches a single, corresponding asterisk label in the
+      existing zone tree when the 4.3.2 algorithm is being followed.
+
+      When a wild card domain name appears in the resource data of a
+      record, no special processing occurs.  An asterisk label in that
+      context literally means just an asterisk.
+
+3. Impact of a Wild Card Domain Name On a Response
+
+      RFC 1034's description of how wildcards impact response
+      generation is in its section 4.3.2.  That passage contains the
+      algorithm followed by a server in constructing a response.
+      Within that algorithm, step 3, part 'c' defines the behavior of
+      the wildcard.
+
+      The algorithm in section 4.3.2. is not intended to be pseudo-code,
+      i.e., its steps are not intended to be followed in strict order.
+      The "algorithm" is a suggested means of implementing the
+      requirements.  As such, in step 3, parts a, b, and c, do not have
+      to be implemented in that order, provided that the result of the
+      implemented code is compliant with the protocol's specification.
+
+3.1 Step 2
+
+      Step 2 of section 4.3.2 reads:
+
+#   2. Search the available zones for the zone which is the nearest
+#      ancestor to QNAME.  If such a zone is found, go to step 3,
+#      otherwise step 4.
+
+DNSEXT Working Group        Expires July 9, 2006             [Page 10]
+
+Internet-Draft                  dnsext-wcard           January 9, 2006
+
+      In this step, the most appropriate zone for the response is
+      chosen.  The significance of this step is that it means all of
+      step 3 is being performed within one zone.  This has significance
+      when considering whether or not an SOA RR can be ever be used for
+      synthesis.
+
+3.2 Step 3
+
+      Step 3 is dominated by three parts, labelled 'a', 'b', and 'c'.
+      But the beginning of the step is important and needs explanation.
+
+#   3. Start matching down, label by label, in the zone.  The
+#      matching process can terminate several ways:
+
+      The word 'matching' refers to label matching.  The concept
+      is based in the view of the zone as the tree of existing names.
+      The query name is considered to be an ordered sequence of
+      labels - as if the name were a path from the root to the owner
+      of the desired data.  (Which it is - 3rd paragraph of RFC 1034,
+      section 3.1.)
+
+      The process of label matching a query name ends in exactly one of
+      three choices, the parts 'a', 'b', and 'c'.  Either the name is
+      found, the name is below a cut point, or the name is not found.
+
+      Once one of the parts is chosen, the other parts are not
+      considered.  (E.g., do not execute part 'c' and then change
+      the execution path to finish in part 'b'.)  The process of label
+      matching is also done independent of the query type (QTYPE).
+
+      Parts 'a' and 'b' are not an issue for this clarification as they
+      do not relate to record synthesis.  Part 'a' is an exact match
+      that results in an answer, part 'b' is a referral.
+
+3.3 Part 'c'
+
+      The context of part 'c' is that the process of label matching the
+      labels of the query name has resulted in a situation in which
+      there is no corresponding label in the tree.  It is as if the
+      lookup has "fallen off the tree."
+
+#     c. If at some label, a match is impossible (i.e., the
+#        corresponding label does not exist), look to see if [...]
+#        the "*" label exists.
+
+      To help describe the process of looking 'to see if [...] the "*"
+      label exists' a term has been coined to describe the last domain
+      (node) matched.  The term is "closest encloser."
+
+
+
+
+DNSEXT Working Group        Expires July 9, 2006             [Page 11]
+
+Internet-Draft                  dnsext-wcard           January 9, 2006
+
+3.3.1 Closest Encloser and the Source of Synthesis
+
+      The closest encloser is the node in the zone's tree of existing
+      domain names that has the most labels matching the query name
+      (consecutively, counting from the root label downward). Each match
+      is a "label match" and the order of the labels is the same.
+
+      The closest encloser is, by definition, an existing name in the
+      zone.  The closest encloser might be an empty non-terminal or even
+      be a wild card domain name itself.  In no circumstances is the
+      closest encloser to be used to synthesize records for the current
+      query.
+
+      The source of synthesis is defined in the context of a query
+      process as that wild card domain name immediately descending
+      from the closest encloser, provided that this wild card domain
+      name exists.  "Immediately descending" means that the source
+      of synthesis has a name of the form:
+            <asterisk label>.<closest encloser>.
+      A source of synthesis does not guarantee having a RRSet to use
+      for synthesis.  The source of synthesis could be an empty
+      non-terminal.
+
+      If the source of synthesis does not exist (not on the domain
+      tree), there will be no wildcard synthesis.  There is no search
+      for an alternate.
+
+      The important concept is that for any given lookup process, there
+      is at most one place at which wildcard synthetic records can be
+      obtained.  If the source of synthesis does not exist, the lookup
+      terminates, the lookup does not look for other wildcard records.
+
+3.3.2 Closest Encloser and Source of Synthesis Examples
+
+      To illustrate, using the example zone in section 2.2.1 of this
+      document, the following chart shows QNAMEs and the closest
+      enclosers.
+
+      QNAME                       Closest Encloser    Source of Synthesis
+      host3.example.              example.            *.example.
+      _telnet._tcp.host1.example. _tcp.host1.example. no source
+      _telnet._tcp.host2.example. host2.example.      no source
+      _telnet._tcp.host3.example. example.            *.example.
+      _chat._udp.host3.example.   example.            *.example.
+      foobar.*.example.           *.example.          no source
+
+
+
+
+
+
+
+DNSEXT Working Group        Expires July 9, 2006             [Page 12]
+
+Internet-Draft                  dnsext-wcard           January 9, 2006
+
+3.3.3 Type Matching
+
+       RFC 1034 concludes part 'c' with this:
+
+#            If the "*" label does not exist, check whether the name
+#            we are looking for is the original QNAME in the query
+#            or a name we have followed due to a CNAME.  If the name
+#            is original, set an authoritative name error in the
+#            response and exit.  Otherwise just exit.
+#
+#            If the "*" label does exist, match RRs at that node
+#            against QTYPE.  If any match, copy them into the answer
+#            section, but set the owner of the RR to be QNAME, and
+#            not the node with the "*" label.  Go to step 6.
+
+      The final paragraph covers the role of the QTYPE in the lookup
+      process.
+
+      Based on implementation feedback and similarities between step
+      'a' and step 'c' a change to this passage has been made.
+
+      The change is to add the following text to step 'c' prior to the
+      instructions to "go to step 6":
+
+               If the data at the source of synthesis is a CNAME, and
+               QTYPE doesn't match CNAME, copy the CNAME RR into the
+               answer section of the response changing the owner name
+               to the QNAME, change QNAME to the canonical name in the
+               CNAME RR, and go back to step 1.
+
+      This is essentially the same text in step a covering the
+      processing of CNAME RRSets.
+
+4. Considerations with Special Types
+
+      Sections 2 and 3 of this document discuss wildcard synthesis
+      with respect to names in the domain tree and ignore the impact
+      of types.  In this section, the implication of wildcards of
+      specific types are discussed.  The types covered are those
+      that have proven to be the most difficult to understand.  The
+      types are SOA, NS, CNAME, DNAME, SRV, DS, NSEC, RRSIG and
+      "none," i.e., empty non-terminal wild card domain names.
+
+4.1 SOA RRSet at a Wild Card Domain Name
+
+      A wild card domain name owning an SOA RRSet means that the
+      domain is at the root of the zone (apex).  The domain can not
+      be a source of synthesis because that is, by definition, a
+      descendent node (of the closest encloser) and a zone apex is
+      at the top of the zone.
+
+
+DNSEXT Working Group        Expires July 9, 2006             [Page 13]
+
+Internet-Draft                  dnsext-wcard           January 9, 2006
+
+      Although a wild card domain name owning an SOA RRSet can never
+      be a source of synthesis, there is no reason to forbid the
+      ownership of an SOA RRSet.
+
+      E.g., given this zone:
+             $ORIGIN *.example.
+             @                 3600 IN  SOA   <SOA RDATA>
+                               3600     NS    ns1.example.com.
+                               3600     NS    ns1.example.net.
+             www               3600     TXT   "the www txt record"
+
+      A query for www.*.example.'s TXT record would still find the
+      "the www txt record" answer.  The asterisk label only becomes
+      significant when section 4.3.2, step 3 part 'c' is in effect.
+
+      Of course, there would need to be a delegation in the parent
+      zone, "example." for this to work too.  This is covered in the
+      next section.
+
+4.2 NS RRSet at a Wild Card Domain Name
+
+      With the definition of DNSSEC [RFC4033, RFC4034, RFC4035] now
+      in place, the semantics of a wild card domain name owning an
+      NS RRSet has come to be poorly defined.  The dilemma relates to
+      a conflict between the rules for synthesis in part 'c' and the
+      fact that the resulting synthesis generates a record for which
+      the zone is not authoritative.  In a DNSSEC signed zone, the
+      mechanics of signature management (generation and inclusion
+      in a message) have become unclear.
+
+      Salient points of the working group discussion on this topic is
+      summarized in section 4.2.1.
+
+      As a result of these discussion, there is no definition given for
+      wild card domain names owning an NS RRSet.  The semantics are
+      left undefined until there is a clear need to have a set defined,
+      and until there is a clear direction to proceed.  Operationally,
+      inclusion of wild card NS RRSets in a zone is discouraged, but
+      not barred.
+
+4.2.1 Discarded Notions
+
+      Prior to DNSSEC, a wild card domain name owning a NS RRSet
+      appeared to be workable, and there are some instances in which
+      it is found in deployments using implementations that support
+      this.  Continuing to allow this in the specification is not
+      tenable with DNSSEC.  The reason is that the synthesis of the
+      NS RRSet is being done in a zone that has delegated away the
+      responsibility for the name.  This "unauthorized" synthesis is
+      not a problem for the base DNS protocol, but DNSSEC, in affirming
+      the authorization model for DNS exposes the problem.
+
+DNSEXT Working Group        Expires July 9, 2006             [Page 14]
+
+Internet-Draft                  dnsext-wcard           January 9, 2006
+
+      Outright banning of wildcards of type NS is also untenable as
+      the DNS protocol does not define how to handle "illegal" data.
+      Implementations may choose not to load a zone, but there is no
+      protocol definition.  The lack of the definition is complicated
+      by having to cover dynamic update [RFC 2136], zone transfers,
+      as well as loading at the master server.  The case of a client
+      (resolver, caching server) getting a wildcard of type NS in
+      a reply would also have to be considered.
+
+      Given the daunting challenge of a complete definition of how to
+      ban such records, dealing with existing implementations that
+      permit the records today is a further complication.  There are
+      uses of wild card domain name owning NS RRSets.
+
+      One compromise proposed would have redefined wildcards of type
+      NS to not be used in synthesis, this compromise fell apart
+      because it would have required significant edits to the DNSSEC
+      signing and validation work.  (Again, DNSSEC catches
+      unauthorized data.)
+
+      With no clear consensus forming on the solution to this dilemma,
+      and the realization that wildcards of type NS are a rarity in
+      operations, the best course of action is to leave this open-ended
+      until "it matters."
+
+4.3 CNAME RRSet at a Wild Card Domain Name
+
+      The issue of a CNAME RRSet owned by a wild card domain name has
+      prompted a suggested change to the last paragraph of step 3c of
+      the algorithm in 4.3.2.  The changed text appears in section
+      3.3.3 of this document.
+
+4.4 DNAME RRSet at a Wild Card Domain Name
+
+      Ownership of a DNAME [RFC2672] RRSet by a wild card domain name
+      represents a threat to the coherency of the DNS and is to be
+      avoided or outright rejected.  Such a DNAME RRSet represents
+      non-deterministic synthesis of rules fed to different caches.
+      As caches are fed the different rules (in an unpredictable
+      manner) the caches will cease to be coherent.  ("As caches
+      are fed" refers to the storage in a cache of records obtained
+      in responses by recursive or iterative servers.)
+
+      For example, assume one cache, responding to a recursive
+      request, obtains the record:
+         "a.b.example. DNAME foo.bar.example.net."
+      and another cache obtains:
+         "b.example.  DNAME foo.bar.example.net."
+      both generated from the record:
+         "*.example. DNAME foo.bar.example.net."
+      by an authoritative server.
+
+DNSEXT Working Group        Expires July 9, 2006             [Page 15]
+
+Internet-Draft                  dnsext-wcard           January 9, 2006
+
+      The DNAME specification is not clear on whether DNAME records
+      in a cache are used to rewrite queries.  In some interpretations,
+      the rewrite occurs, in some, it is not.  Allowing for the
+      occurrence of rewriting, queries for "sub.a.b.example. A" may
+      be rewritten as "sub.foo.bar.tld. A" by the former caching
+      server and may be rewritten as "sub.a.foo.bar.tld. A" by the
+      latter.  Coherency is lost, an operational nightmare ensues.
+
+      Another justification for banning or avoiding wildcard DNAME
+      records is the observation that such a record could synthesize
+      a DNAME owned by "sub.foo.bar.example." and "foo.bar.example."
+      There is a restriction in the DNAME definition that no domain
+      exist below a DNAME-owning domain, hence, the wildcard DNAME
+      is not to be permitted.
+
+4.5 SRV RRSet at a Wild Card Domain Name
+
+      The definition of the SRV RRset is RFC 2782 [RFC2782].  In the
+      definition of the record, there is some confusion over the term
+      "Name."  The definition reads as follows:
+
+# The format of the SRV RR
+...
+#    _Service._Proto.Name TTL Class SRV Priority Weight Port Target
+...
+#  Name
+#   The domain this RR refers to.  The SRV RR is unique in that the
+#   name one searches for is not this name; the example near the end
+#   shows this clearly.
+
+      Do not confuse the definition "Name" with the owner name.  I.e.,
+      once removing the _Service and _Proto labels from the owner name
+      of the SRV RRSet, what remains could be a wild card domain name
+      but this is immaterial to the SRV RRSet.
+
+      E.g.,  If an SRV record is:
+         _foo._udp.*.example. 10800 IN SRV 0 1 9 old-slow-box.example.
+
+      *.example is a wild card domain name and although it is the Name
+      of the SRV RR, it is not the owner (domain name).  The owner
+      domain name is "_foo._udp.*.example." which is not a wild card
+      domain name.
+
+      The confusion is likely based on the mixture of the specification
+      of the SRV RR and the description of a "use case."
+
+4.6 DS RRSet at a Wild Card Domain Name
+
+      A DS RRSet owned by a wild card domain name is meaningless and
+      harmless.  This statement is made in the context that an NS RRSet
+      at a wild card domain name is undefined.  At a non-delegation
+
+DNSEXT Working Group        Expires July 9, 2006             [Page 16]
+
+Internet-Draft                  dnsext-wcard           January 9, 2006
+
+      point, a DS RRSet has no value (no corresponding DNSKEY RRSet
+      will be used in DNSSEC validation).  If there is a synthesized
+      DS RRSet, it alone will not be very useful as it exists in the
+      context of a delegation point.
+
+4.7 NSEC RRSet at a Wild Card Domain Name
+
+      Wild card domain names in DNSSEC signed zones will have an NSEC
+      RRSet.  Synthesis of these records will only occur when the
+      query exactly matches the record.  Synthesized NSEC RR's will not
+      be harmful as they will never be used in negative caching or to
+      generate a negative response.  [RFC2308]
+
+4.8 RRSIG at a Wild Card Domain Name
+
+      RRSIG records will be present at a wild card domain name in a
+      signed zone, and will be synthesized along with data sought in a
+      query.  The fact that the owner name is synthesized is not a
+      problem as the label count in the RRSIG will instruct the
+      verifying code to ignore it.
+
+4.9 Empty Non-terminal Wild Card Domain Name
+
+      If a source of synthesis is an empty non-terminal, then the
+      response will be one of no error in the return code and no RRSet
+      in the answer section.
+
+5. Security Considerations
+
+      This document is refining the specifications to make it more
+      likely that security can be added to DNS.  No functional
+      additions are being made, just refining what is considered
+      proper to allow the DNS, security of the DNS, and extending
+      the DNS to be more predictable.
+
+6. IANA Considerations
+
+       None.
+
+7. References
+
+      Normative References
+
+      [RFC20]   ASCII Format for Network Interchange, V.G. Cerf,
+                Oct-16-1969
+
+      [RFC1034] Domain Names - Concepts and Facilities,
+                P.V. Mockapetris, Nov-01-1987
+
+      [RFC1035] Domain Names - Implementation and Specification, P.V
+                Mockapetris, Nov-01-1987
+
+DNSEXT Working Group        Expires July 9, 2006             [Page 17]
+
+Internet-Draft                  dnsext-wcard           January 9, 2006
+
+      [RFC1995] Incremental Zone Transfer in DNS, M. Ohta, August 1996
+
+      [RFC2119] Key Words for Use in RFCs to Indicate Requirement
+                Levels, S Bradner, March 1997
+
+      [RFC2308] Negative Caching of DNS Queries (DNS NCACHE),
+                M. Andrews, March 1998
+
+      [RFC2672] Non-Terminal DNS Name Redirection, M. Crawford,
+                August 1999.
+
+      [RFC2782] A DNS RR for specifying the location of services (DNS
+                SRV), A. Gulbrandsen, et.al., February 2000
+
+      [RFC4033] DNS Security Introduction and Requirements, R. Arends,
+                et.al., March 2005
+
+      [RFC4034] Resource Records for the DNS Security Extensions,
+                R. Arends, et.al., March 2005
+
+      [RFC4035] Protocol Modifications for the DNS Security Extensions,
+                R. Arends, et.al., March 2005
+
+      Informative References
+
+      [RFC2136] Dynamic Updates in the Domain Name System (DNS UPDATE),
+                P. Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound,
+                April 1997
+
+8. Editor
+
+           Name:         Edward Lewis
+           Affiliation:  NeuStar
+           Address:      46000 Center Oak Plaza, Sterling, VA, 20166, US
+           Phone:        +1-571-434-5468
+           Email:        ed.lewis@neustar.biz
+
+      Comments on this document can be sent to the editor or the mailing
+      list for the DNSEXT WG, namedroppers@ops.ietf.org.
+
+9. Others Contributing to the Document
+
+      This document represents the work of a large working group.  The
+      editor merely recorded the collective wisdom of the working group.
+
+
+
+
+
+
+
+
+
+DNSEXT Working Group        Expires July 9, 2006             [Page 17]
+
+Internet-Draft                  dnsext-wcard           January 9, 2006
+
+10. Trailing Boilerplate
+
+      Copyright (C) The Internet Society (2006).
+
+      This document is subject to the rights, licenses and restrictions
+      contained in BCP 78, and except as set forth therein, the authors
+      retain all their rights.
+
+      This document and the information contained herein are provided
+      on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION
+      HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET
+      SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
+
+Intellectual Property
+
+      The IETF takes no position regarding the validity or scope of
+      any Intellectual Property Rights or other rights that might
+      be claimed to pertain to the implementation or use of the
+      technology described in this document or the extent to which
+      any license under such rights might or might not be available;
+      nor does it represent that it has made any independent effort
+      to identify any such rights.  Information on the procedures
+      with respect to rights in RFC documents can be found in BCP 78
+      and BCP 79.
+
+      Copies of IPR disclosures made to the IETF Secretariat and any
+      assurances of licenses to be made available, or the result of an
+      attempt made to obtain a general license or permission for the
+      use of such proprietary rights by implementers or users of this
+      specification can be obtained from the IETF on-line IPR
+      repository at http://www.ietf.org/ipr.  The IETF invites any
+      interested party to bring to its attention any copyrights,
+      patents or patent applications, or other proprietary rights
+      that may cover technology that may be required to implement
+      this standard.  Please address the information to the IETF at
+      ietf-ipr@ietf.org.
+
+Acknowledgement
+
+      Funding for the RFC Editor function is currently provided by the
+      Internet Society.
+
+Expiration
+
+      This document expires on or about July 9, 2006.
+
+
+
+DNSEXT Working Group        Expires July 9, 2006             [Page 19]
diff --git a/doc/draft/draft-ietf-dnsop-bad-dns-res-05.txt b/doc/draft/draft-ietf-dnsop-bad-dns-res-05.txt
new file mode 100644
index 0000000..0855ba3
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsop-bad-dns-res-05.txt
@@ -0,0 +1,1232 @@
+
+
+
+DNS Operations                                                 M. Larson
+Internet-Draft                                                 P. Barber
+Expires: August 14, 2006                                        VeriSign
+                                                       February 10, 2006
+
+
+                  Observed DNS Resolution Misbehavior
+                    draft-ietf-dnsop-bad-dns-res-05
+
+Status of this Memo
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   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 draft documents 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 "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/ietf/1id-abstracts.txt.
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+   This Internet-Draft will expire on August 14, 2006.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   This memo describes DNS iterative resolver behavior that results in a
+   significant query volume sent to the root and top-level domain (TLD)
+   name servers.  We offer implementation advice to iterative resolver
+   developers to alleviate these unnecessary queries.  The
+   recommendations made in this document are a direct byproduct of
+   observation and analysis of abnormal query traffic patterns seen at
+   two of the thirteen root name servers and all thirteen com/net TLD
+   name servers.
+
+
+
+Larson & Barber          Expires August 14, 2006                [Page 1]
+
+Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
+
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [1].
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+     1.1.  A note about terminology in this memo  . . . . . . . . . .  3
+   2.  Observed iterative resolver misbehavior  . . . . . . . . . . .  5
+     2.1.  Aggressive requerying for delegation information . . . . .  5
+       2.1.1.  Recommendation . . . . . . . . . . . . . . . . . . . .  6
+     2.2.  Repeated queries to lame servers . . . . . . . . . . . . .  7
+       2.2.1.  Recommendation . . . . . . . . . . . . . . . . . . . .  7
+     2.3.  Inability to follow multiple levels of indirection . . . .  8
+       2.3.1.  Recommendation . . . . . . . . . . . . . . . . . . . .  9
+     2.4.  Aggressive retransmission when fetching glue . . . . . . .  9
+       2.4.1.  Recommendation . . . . . . . . . . . . . . . . . . . . 10
+     2.5.  Aggressive retransmission behind firewalls . . . . . . . . 10
+       2.5.1.  Recommendation . . . . . . . . . . . . . . . . . . . . 11
+     2.6.  Misconfigured NS records . . . . . . . . . . . . . . . . . 11
+       2.6.1.  Recommendation . . . . . . . . . . . . . . . . . . . . 12
+     2.7.  Name server records with zero TTL  . . . . . . . . . . . . 12
+       2.7.1.  Recommendation . . . . . . . . . . . . . . . . . . . . 13
+     2.8.  Unnecessary dynamic update messages  . . . . . . . . . . . 13
+       2.8.1.  Recommendation . . . . . . . . . . . . . . . . . . . . 14
+     2.9.  Queries for domain names resembling IPv4 addresses . . . . 14
+       2.9.1.  Recommendation . . . . . . . . . . . . . . . . . . . . 14
+     2.10. Misdirected recursive queries  . . . . . . . . . . . . . . 15
+       2.10.1. Recommendation . . . . . . . . . . . . . . . . . . . . 15
+     2.11. Suboptimal name server selection algorithm . . . . . . . . 15
+       2.11.1. Recommendation . . . . . . . . . . . . . . . . . . . . 16
+   3.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 17
+   4.  IANA considerations  . . . . . . . . . . . . . . . . . . . . . 18
+   5.  Security considerations  . . . . . . . . . . . . . . . . . . . 19
+   6.  Internationalization considerations  . . . . . . . . . . . . . 20
+   7.  Informative References . . . . . . . . . . . . . . . . . . . . 20
+   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
+   Intellectual Property and Copyright Statements . . . . . . . . . . 22
+
+
+
+
+
+
+
+
+
+
+
+
+Larson & Barber          Expires August 14, 2006                [Page 2]
+
+Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
+
+
+1.  Introduction
+
+   Observation of query traffic received by two root name servers and
+   the thirteen com/net TLD name servers has revealed that a large
+   proportion of the total traffic often consists of "requeries".  A
+   requery is the same question (<QNAME, QTYPE, QCLASS>) asked
+   repeatedly at an unexpectedly high rate.  We have observed requeries
+   from both a single IP address and multiple IP addresses (i.e., the
+   same query received simultaneously from multiple IP addresses).
+
+   By analyzing requery events we have found that the cause of the
+   duplicate traffic is almost always a deficient iterative resolver,
+   stub resolver or application implementation combined with an
+   operational anomaly.  The implementation deficiencies we have
+   identified to date include well-intentioned recovery attempts gone
+   awry, insufficient caching of failures, early abort when multiple
+   levels of indirection must be followed, and aggressive retry by stub
+   resolvers or applications.  Anomalies that we have seen trigger
+   requery events include lame delegations, unusual glue records, and
+   anything that makes all authoritative name servers for a zone
+   unreachable (DoS attacks, crashes, maintenance, routing failures,
+   congestion, etc.).
+
+   In the following sections, we provide a detailed explanation of the
+   observed behavior and recommend changes that will reduce the requery
+   rate.  None of the changes recommended affects the core DNS protocol
+   specification; instead, this document consists of guidelines to
+   implementors of iterative resolvers.
+
+1.1.  A note about terminology in this memo
+
+   To recast an old saying about standards, the nice thing about DNS
+   terms is that there are so many of them to choose from.  Writing or
+   talking about DNS can be difficult and cause confusion resulting from
+   a lack of agreed-upon terms for its various components.  Further
+   complicating matters are implementations that combine multiple roles
+   into one piece of software, which makes naming the result
+   problematic.  An example is the entity that accepts recursive
+   queries, issues iterative queries as necessary to resolve the initial
+   recursive query, caches responses it receives, and which is also able
+   to answer questions about certain zones authoritatively.  This entity
+   is an iterative resolver combined with an authoritative name server
+   and is often called a "recursive name server" or a "caching name
+   server".
+
+   This memo is concerned principally with the behavior of iterative
+   resolvers, which are typically found as part of a recursive name
+   server.  This memo uses the more precise term "iterative resolver",
+
+
+
+Larson & Barber          Expires August 14, 2006                [Page 3]
+
+Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
+
+
+   because the focus is usually on that component.  In instances where
+   the name server role of this entity requires mentioning, this memo
+   uses the term "recursive name server".  As an example of the
+   difference, the name server component of a recursive name server
+   receives DNS queries and the iterative resolver component sends
+   queries.
+
+   The advent of IPv6 requires mentioning AAAA records as well as A
+   records when discussing glue.  To avoid continuous repetition and
+   qualification, this memo uses the general term "address record" to
+   encompass both A and AAAA records when a particular situation is
+   relevant to both types.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Larson & Barber          Expires August 14, 2006                [Page 4]
+
+Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
+
+
+2.  Observed iterative resolver misbehavior
+
+2.1.  Aggressive requerying for delegation information
+
+   There can be times when every name server in a zone's NS RRset is
+   unreachable (e.g., during a network outage), unavailable (e.g., the
+   name server process is not running on the server host) or
+   misconfigured (e.g., the name server is not authoritative for the
+   given zone, also known as "lame").  Consider an iterative resolver
+   that attempts to resolve a query for a domain name in such a zone and
+   discovers that none of the zone's name servers can provide an answer.
+   We have observed a recursive name server implementation whose
+   iterative resolver then verifies the zone's NS RRset in its cache by
+   querying for the zone's delegation information: it sends a query for
+   the zone's NS RRset to one of the parent zone's name servers.  (Note
+   that queries with QTYPE=NS are not required by the standard
+   resolution algorithm described in section 4.3.2 of RFC 1034 [2].
+   These NS queries represent this implementation's addition to that
+   algorithm.)
+
+   For example, suppose that "example.com" has the following NS RRset:
+
+     example.com.   IN   NS   ns1.example.com.
+     example.com.   IN   NS   ns2.example.com.
+
+   Upon receipt of a query for "www.example.com" and assuming that
+   neither "ns1.example.com" nor "ns2.example.com" can provide an
+   answer, this iterative resolver implementation immediately queries a
+   "com" zone name server for the "example.com" NS RRset to verify it
+   has the proper delegation information.  This implementation performs
+   this query to a zone's parent zone for each recursive query it
+   receives that fails because of a completely unresponsive set of name
+   servers for the target zone.  Consider the effect when a popular zone
+   experiences a catastrophic failure of all its name servers: now every
+   recursive query for domain names in that zone sent to this recursive
+   name server implementation results in a query to the failed zone's
+   parent name servers.  On one occasion when several dozen popular
+   zones became unreachable, the query load on the com/net name servers
+   increased by 50%.
+
+   We believe this verification query is not reasonable.  Consider the
+   circumstances: When an iterative resolver is resolving a query for a
+   domain name in a zone it has not previously searched, it uses the
+   list of name servers in the referral from the target zone's parent.
+   If on its first attempt to search the target zone, none of the name
+   servers in the referral is reachable, a verification query to the
+   parent would be pointless: this query to the parent would come so
+   quickly on the heels of the referral that it would be almost certain
+
+
+
+Larson & Barber          Expires August 14, 2006                [Page 5]
+
+Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
+
+
+   to contain the same list of name servers.  The chance of discovering
+   any new information is slim.
+
+   The other possibility is that the iterative resolver successfully
+   contacts one of the target zone's name servers and then caches the NS
+   RRset from the authority section of a response, the proper behavior
+   according to section 5.4.1 of RFC 2181 [3], because the NS RRset from
+   the target zone is more trustworthy than delegation information from
+   the parent zone.  If, while processing a subsequent recursive query,
+   the iterative resolver discovers that none of the name servers
+   specified in the cached NS RRset is available or authoritative,
+   querying the parent would be wrong.  An NS RRset from the parent zone
+   would now be less trustworthy than data already in the cache.
+
+   For this query of the parent zone to be useful, the target zone's
+   entire set of name servers would have to change AND the former set of
+   name servers would have to be deconfigured or decommissioned AND the
+   delegation information in the parent zone would have to be updated
+   with the new set of name servers, all within the TTL of the target
+   zone's NS RRset.  We believe this scenario is uncommon:
+   administrative best practices dictate that changes to a zone's set of
+   name servers happen gradually when at all possible, with servers
+   removed from the NS RRset left authoritative for the zone as long as
+   possible.  The scenarios that we can envision that would benefit from
+   the parent requery behavior do not outweigh its damaging effects.
+
+   This section should not be understood to claim that all queries to a
+   zone's parent are bad.  In some cases, such queries are not only
+   reasonable but required.  Consider the situation when required
+   information, such as the address of a name server (i.e., the address
+   record corresponding to the RDATA of an NS record), has timed out of
+   an iterative resolver's cache before the corresponding NS record.  If
+   the name of the name server is below the apex of the zone, then the
+   name server's address record is only available as glue in the parent
+   zone.  For example, consider this NS record:
+
+     example.com.        IN   NS   ns.example.com.
+
+   If a cache has this NS record but not the address record for
+   "ns.example.com", it is unable to contact the "example.com" zone
+   directly and must query the "com" zone to obtain the address record.
+   Note, however, that such a query would not have QTYPE=NS according to
+   the standard resolution algorithm.
+
+2.1.1.  Recommendation
+
+   An iterative resolver MUST NOT send a query for the NS RRset of a
+   non-responsive zone to any of the name servers for that zone's parent
+
+
+
+Larson & Barber          Expires August 14, 2006                [Page 6]
+
+Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
+
+
+   zone.  For the purposes of this injunction, a non-responsive zone is
+   defined as a zone for which every name server listed in the zone's NS
+   RRset:
+
+   1.  is not authoritative for the zone (i.e., lame), or,
+
+   2.  returns a server failure response (RCODE=2), or,
+
+   3.  is dead or unreachable according to section 7.2 of RFC 2308 [4].
+
+2.2.  Repeated queries to lame servers
+
+   Section 2.1 describes a catastrophic failure: when every name server
+   for a zone is unable to provide an answer for one reason or another.
+   A more common occurrence is when a subset of a zone's name servers
+   are unavailable or misconfigured.  Different failure modes have
+   different expected durations.  Some symptoms indicate problems that
+   are potentially transient; for example, various types of ICMP
+   unreachable messages because a name server process is not running or
+   a host or network is unreachable, or a complete lack of a response to
+   a query.  Such responses could be the result of a host rebooting or
+   temporary outages; these events don't necessarily require any human
+   intervention and can be reasonably expected to be temporary.
+
+   Other symptoms clearly indicate a condition requiring human
+   intervention, such as lame server: if a name server is misconfigured
+   and not authoritative for a zone delegated to it, it is reasonable to
+   assume that this condition has potential to last longer than
+   unreachability or unresponsiveness.  Consequently, repeated queries
+   to known lame servers are not useful.  In this case of a condition
+   with potential to persist for a long time, a better practice would be
+   to maintain a list of known lame servers and avoid querying them
+   repeatedly in a short interval.
+
+   It should also be noted, however, that some authoritative name server
+   implementations appear to be lame only for queries of certain types
+   as described in RFC 4074 [5].  In this case, it makes sense to retry
+   the "lame" servers for other types of queries, particularly when all
+   known authoritative name servers appear to be "lame".
+
+2.2.1.  Recommendation
+
+   Iterative resolvers SHOULD cache name servers that they discover are
+   not authoritative for zones delegated to them (i.e. lame servers).
+   If this caching is performed, lame servers MUST be cached against the
+   specific query tuple <zone name, class, server IP address>.  Zone
+   name can be derived from the owner name of the NS record that was
+   referenced to query the name server that was discovered to be lame.
+
+
+
+Larson & Barber          Expires August 14, 2006                [Page 7]
+
+Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
+
+
+   Implementations that perform lame server caching MUST refrain from
+   sending queries to known lame servers based on a time interval from
+   when the server is discovered to be lame.  A minimum interval of
+   thirty minutes is RECOMMENDED.
+
+   An exception to this recommendation occurs if all name servers for a
+   zone are marked lame.  In that case, the iterative resolver SHOULD
+   temporarily ignore the servers' lameness status and query one or more
+   servers.  This behavior is a workaround for the type-specific
+   lameness issue described in the previous section.
+
+   Implementors should take care not to make lame server avoidance logic
+   overly broad: note that a name server could be lame for a parent zone
+   but not a child zone, e.g., lame for "example.com" but properly
+   authoritative for "sub.example.com".  Therefore a name server should
+   not be automatically considered lame for subzones.  In the case
+   above, even if a name server is known to be lame for "example.com",
+   it should be queried for QNAMEs at or below "sub.example.com" if an
+   NS record indicates it should be authoritative for that zone.
+
+2.3.  Inability to follow multiple levels of indirection
+
+   Some iterative resolver implementations are unable to follow
+   sufficient levels of indirection.  For example, consider the
+   following delegations:
+
+     foo.example.        IN   NS   ns1.example.com.
+     foo.example.        IN   NS   ns2.example.com.
+
+     example.com.        IN   NS   ns1.test.example.net.
+     example.com.        IN   NS   ns2.test.example.net.
+
+     test.example.net.   IN   NS   ns1.test.example.net.
+     test.example.net.   IN   NS   ns2.test.example.net.
+
+   An iterative resolver resolving the name "www.foo.example" must
+   follow two levels of indirection, first obtaining address records for
+   "ns1.test.example.net" or "ns2.test.example.net" in order to obtain
+   address records for "ns1.example.com" or "ns2.example.com" in order
+   to query those name servers for the address records of
+   "www.foo.example".  While this situation may appear contrived, we
+   have seen multiple similar occurrences and expect more as new generic
+   top-level domains (gTLDs) become active.  We anticipate many zones in
+   new gTLDs will use name servers in existing gTLDs, increasing the
+   number of delegations using out-of-zone name servers.
+
+
+
+
+
+
+Larson & Barber          Expires August 14, 2006                [Page 8]
+
+Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
+
+
+2.3.1.  Recommendation
+
+   Clearly constructing a delegation that relies on multiple levels of
+   indirection is not a good administrative practice.  However, the
+   practice is widespread enough to require that iterative resolvers be
+   able to cope with it.  Iterative resolvers SHOULD be able to handle
+   arbitrary levels of indirection resulting from out-of-zone name
+   servers.  Iterative resolvers SHOULD implement a level-of-effort
+   counter to avoid loops or otherwise performing too much work in
+   resolving pathological cases.
+
+   A best practice that avoids this entire issue of indirection is to
+   name one or more of a zone's name servers in the zone itself.  For
+   example, if the zone is named "example.com", consider naming some of
+   the name servers "ns{1,2,...}.example.com" (or similar).
+
+2.4.  Aggressive retransmission when fetching glue
+
+   When an authoritative name server responds with a referral, it
+   includes NS records in the authority section of the response.
+   According to the algorithm in section 4.3.2 of RFC 1034 [2], the name
+   server should also "put whatever addresses are available into the
+   additional section, using glue RRs if the addresses are not available
+   from authoritative data or the cache."  Some name server
+   implementations take this address inclusion a step further with a
+   feature called "glue fetching".  A name server that implements glue
+   fetching attempts to include address records for every NS record in
+   the authority section.  If necessary, the name server issues multiple
+   queries of its own to obtain any missing address records.
+
+   Problems with glue fetching can arise in the context of
+   "authoritative-only" name servers, which only serve authoritative
+   data and ignore requests for recursion.  Such an entity will not
+   normally generate any queries of its own.  Instead it answers non-
+   recursive queries from iterative resolvers looking for information in
+   zones it serves.  With glue fetching enabled, however, an
+   authoritative server invokes an iterative resolver to look up an
+   unknown address record to complete the additional section of a
+   response.
+
+   We have observed situations where the iterative resolver of a glue-
+   fetching name server can send queries that reach other name servers,
+   but is apparently prevented from receiving the responses.  For
+   example, perhaps the name server is authoritative-only and therefore
+   its administrators expect it to receive only queries and not
+   responses.  Perhaps unaware of glue fetching and presuming that the
+   name server's iterative resolver will generate no queries, its
+   administrators place the name server behind a network device that
+
+
+
+Larson & Barber          Expires August 14, 2006                [Page 9]
+
+Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
+
+
+   prevents it from receiving responses.  If this is the case, all glue-
+   fetching queries will go answered.
+
+   We have observed name server implementations whose iterative
+   resolvers retry excessively when glue-fetching queries are
+   unanswered.  A single com/net name server has received hundreds of
+   queries per second from a single such source.  Judging from the
+   specific queries received and based on additional analysis, we
+   believe these queries result from overly aggressive glue fetching.
+
+2.4.1.  Recommendation
+
+   Implementers whose name servers support glue fetching SHOULD take
+   care to avoid sending queries at excessive rates.  Implementations
+   SHOULD support throttling logic to detect when queries are sent but
+   no responses are received.
+
+2.5.  Aggressive retransmission behind firewalls
+
+   A common occurrence and one of the largest sources of repeated
+   queries at the com/net and root name servers appears to result from
+   resolvers behind misconfigured firewalls.  In this situation, an
+   iterative resolver is apparently allowed to send queries through a
+   firewall to other name servers, but not receive the responses.  The
+   result is more queries than necessary because of retransmission, all
+   of which are useless because the responses are never received.  Just
+   as with the glue-fetching scenario described in Section 2.4, the
+   queries are sometimes sent at excessive rates.  To make matters
+   worse, sometimes the responses, sent in reply to legitimate queries,
+   trigger an alarm on the originator's intrusion detection system.  We
+   are frequently contacted by administrators responding to such alarms
+   who believe our name servers are attacking their systems.
+
+   Not only do some resolvers in this situation retransmit queries at an
+   excessive rate, but they continue to do so for days or even weeks.
+   This scenario could result from an organization with multiple
+   recursive name servers, only a subset of whose iterative resolvers'
+   traffic is improperly filtered in this manner.  Stub resolvers in the
+   organization could be configured to query multiple recursive name
+   servers.  Consider the case where a stub resolver queries a filtered
+   recursive name server first.  The iterative resolver of this
+   recursive name server sends one or more queries whose replies are
+   filtered, so it can't respond to the stub resolver, which times out.
+   Then the stub resolver retransmits to a recursive name server that is
+   able to provide an answer.  Since resolution ultimately succeeds the
+   underlying problem might not be recognized or corrected.  A popular
+   stub resolver implementation has a very aggressive retransmission
+   schedule, including simultaneous queries to multiple recursive name
+
+
+
+Larson & Barber          Expires August 14, 2006               [Page 10]
+
+Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
+
+
+   servers, which could explain how such a situation could persist
+   without being detected.
+
+2.5.1.  Recommendation
+
+   The most obvious recommendation is that administrators SHOULD take
+   care not to place iterative resolvers behind a firewall that allows
+   queries to pass through but not the resulting replies.
+
+   Iterative resolvers SHOULD take care to avoid sending queries at
+   excessive rates.  Implementations SHOULD support throttling logic to
+   detect when queries are sent but no responses are received.
+
+2.6.  Misconfigured NS records
+
+   Sometimes a zone administrator forgets to add the trailing dot on the
+   domain names in the RDATA of a zone's NS records.  Consider this
+   fragment of the zone file for "example.com":
+
+     $ORIGIN example.com.
+     example.com.      3600   IN   NS   ns1.example.com  ; Note missing
+     example.com.      3600   IN   NS   ns2.example.com  ; trailing dots
+
+   The zone's authoritative servers will parse the NS RDATA as
+   "ns1.example.com.example.com" and "ns2.example.com.example.com" and
+   return NS records with this incorrect RDATA in responses, including
+   typically the authority section of every response containing records
+   from the "example.com" zone.
+
+   Now consider a typical sequence of queries.  An iterative resolver
+   attempting to resolve address records for "www.example.com" with no
+   cached information for this zone will query a "com" authoritative
+   server.  The "com" server responds with a referral to the
+   "example.com" zone, consisting of NS records with valid RDATA and
+   associated glue records.  (This example assumes that the
+   "example.com" zone delegation information is correct in the "com"
+   zone.)  The iterative resolver caches the NS RRset from the "com"
+   server and follows the referral by querying one of the "example.com"
+   authoritative servers.  This server responds with the
+   "www.example.com" address record in the answer section and,
+   typically, the "example.com" NS records in the authority section and,
+   if space in the message remains, glue address records in the
+   additional section.  According to Section 5.4 of RFC 2181 [3], NS
+   records in the authority section of an authoritative answer are more
+   trustworthy than NS records from the authority section of a non-
+   authoritative answer.  Thus the "example.com" NS RRset just received
+   from the "example.com" authoritative server overrides the
+   "example.com" NS RRset received moments ago from the "com"
+
+
+
+Larson & Barber          Expires August 14, 2006               [Page 11]
+
+Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
+
+
+   authoritative server.
+
+   But the "example.com" zone contains the erroneous NS RRset as shown
+   in the example above.  Subsequent queries for names in "example.com"
+   will cause the iterative resolver to attempt to use the incorrect NS
+   records and so it will try to resolve the nonexistent names
+   "ns1.example.com.example.com" and "ns2.example.com.example.com".  In
+   this example, since all of the zone's name servers are named in the
+   zone itself (i.e., "ns1.example.com.example.com" and
+   "ns2.example.com.example.com" both end in "example.com") and all are
+   bogus, the iterative resolver cannot reach any "example.com" name
+   servers.  Therefore attempts to resolve these names result in address
+   record queries to the "com" authoritative servers.  Queries for such
+   obviously bogus glue address records occur frequently at the com/net
+   name servers.
+
+2.6.1.  Recommendation
+
+   An authoritative server can detect this situation.  A trailing dot
+   missing from an NS record's RDATA always results by definition in a
+   name server name that exists somewhere under the apex of the zone the
+   NS record appears in.  Note that further levels of delegation are
+   possible, so a missing trailing dot could inadvertently create a name
+   server name that actually exists in a subzone.
+
+   An authoritative name server SHOULD issue a warning when one of a
+   zone's NS records references a name server below the zone's apex when
+   a corresponding address record does not exist in the zone AND there
+   are no delegated subzones where the address record could exist.
+
+2.7.  Name server records with zero TTL
+
+   Sometimes a popular com/net subdomain's zone is configured with a TTL
+   of zero on the zone's NS records, which prohibits these records from
+   being cached and will result in a higher query volume to the zone's
+   authoritative servers.  The zone's administrator should understand
+   the consequences of such a configuration and provision resources
+   accordingly.  A zero TTL on the zone's NS RRset, however, carries
+   additional consequences beyond the zone itself: if an iterative
+   resolver cannot cache a zone's NS records because of a zero TTL, it
+   will be forced to query that zone's parent's name servers each time
+   it resolves a name in the zone.  The com/net authoritative servers do
+   see an increased query load when a popular com/net subdomain's zone
+   is configured with a TTL of zero on the zone's NS records.
+
+   A zero TTL on an RRset expected to change frequently is extreme but
+   permissible.  A zone's NS RRset is a special case, however, because
+   changes to it must be coordinated with the zone's parent.  In most
+
+
+
+Larson & Barber          Expires August 14, 2006               [Page 12]
+
+Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
+
+
+   zone parent/child relationships we are aware of, there is typically
+   some delay involved in effecting changes.  Further, changes to the
+   set of a zone's authoritative name servers (and therefore to the
+   zone's NS RRset) are typically relatively rare: providing reliable
+   authoritative service requires a reasonably stable set of servers.
+   Therefore an extremely low or zero TTL on a zone's NS RRset rarely
+   makes sense, except in anticipation of an upcoming change.  In this
+   case, when the zone's administrator has planned a change and does not
+   want iterative resolvers throughout the Internet to cache the NS
+   RRset for a long period of time, a low TTL is reasonable.
+
+2.7.1.  Recommendation
+
+   Because of the additional load placed on a zone's parent's
+   authoritative servers resulting from a zero TTL on a zone's NS RRset,
+   under such circumstances authoritative name servers SHOULD issue a
+   warning when loading a zone.
+
+2.8.  Unnecessary dynamic update messages
+
+   The UPDATE message specified in RFC 2136 [6] allows an authorized
+   agent to update a zone's data on an authoritative name server using a
+   DNS message sent over the network.  Consider the case of an agent
+   desiring to add a particular resource record.  Because of zone cuts,
+   the agent does not necessarily know the proper zone to which the
+   record should be added.  The dynamic update process requires that the
+   agent determine the appropriate zone so the UPDATE message can be
+   sent to one of the zone's authoritative servers (typically the
+   primary master as specified in the zone's SOA MNAME field).
+
+   The appropriate zone to update is the closest enclosing zone, which
+   cannot be determined only by inspecting the domain name of the record
+   to be updated, since zone cuts can occur anywhere.  One way to
+   determine the closest enclosing zone entails walking up the name
+   space tree by sending repeated UPDATE messages until success.  For
+   example, consider an agent attempting to add an address record with
+   the name "foo.bar.example.com".  The agent could first attempt to
+   update the "foo.bar.example.com" zone.  If the attempt failed, the
+   update could be directed to the "bar.example.com" zone, then the
+   "example.com" zone, then the "com" zone, and finally the root zone.
+
+   A popular dynamic agent follows this algorithm.  The result is many
+   UPDATE messages received by the root name servers, the com/net
+   authoritative servers, and presumably other TLD authoritative
+   servers.  A valid question is why the algorithm proceeds to send
+   updates all the way to TLD and root name servers.  This behavior is
+   not entirely unreasonable: in enterprise DNS architectures with an
+   "internal root" design, there could conceivably be private, non-
+
+
+
+Larson & Barber          Expires August 14, 2006               [Page 13]
+
+Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
+
+
+   public TLD or root zones that would be the appropriate targets for a
+   dynamic update.
+
+   A significant deficiency with this algorithm is that knowledge of a
+   given UPDATE message's failure is not helpful in directing future
+   UPDATE messages to the appropriate servers.  A better algorithm would
+   be to find the closest enclosing zone by walking up the name space
+   with queries for SOA or NS rather than "probing" with UPDATE
+   messages.  Once the appropriate zone is found, an UPDATE message can
+   be sent.  In addition, the results of these queries can be cached to
+   aid in determining closest enclosing zones for future updates.  Once
+   the closest enclosing zone is determined with this method, the update
+   will either succeed or fail and there is no need to send further
+   updates to higher-level zones.  The important point is that walking
+   up the tree with queries yields cacheable information, whereas
+   walking up the tree by sending UPDATE messages does not.
+
+2.8.1.  Recommendation
+
+   Dynamic update agents SHOULD send SOA or NS queries to progressively
+   higher-level names to find the closest enclosing zone for a given
+   name to update.  Only after the appropriate zone is found should the
+   client send an UPDATE message to one of the zone's authoritative
+   servers.  Update clients SHOULD NOT "probe" using UPDATE messages by
+   walking up the tree to progressively higher-level zones.
+
+2.9.  Queries for domain names resembling IPv4 addresses
+
+   The root name servers receive a significant number of A record
+   queries where the QNAME looks like an IPv4 address.  The source of
+   these queries is unknown.  It could be attributed to situations where
+   a user believes an application will accept either a domain name or an
+   IP address in a given configuration option.  The user enters an IP
+   address, but the application assumes any input is a domain name and
+   attempts to resolve it, resulting in an A record lookup.  There could
+   also be applications that produce such queries in a misguided attempt
+   to reverse map IP addresses.
+
+   These queries result in Name Error (RCODE=3) responses.  An iterative
+   resolver can negatively cache such responses, but each response
+   requires a separate cache entry, i.e., a negative cache entry for the
+   domain name "192.0.2.1" does not prevent a subsequent query for the
+   domain name "192.0.2.2".
+
+2.9.1.  Recommendation
+
+   It would be desirable for the root name servers not to have to answer
+   these queries: they unnecessarily consume CPU resources and network
+
+
+
+Larson & Barber          Expires August 14, 2006               [Page 14]
+
+Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
+
+
+   bandwidth.  A possible solution is to delegate these numeric TLDs
+   from the root zone to a separate set of servers to absorb the
+   traffic.  The "black hole servers" used by the AS 112 Project [8],
+   which are currently delegated the in-addr.arpa zones corresponding to
+   RFC 1918 [7] private use address space, would be a possible choice to
+   receive these delegations.  Of course, the proper and usual root zone
+   change procedures would have to be followed to make such a change to
+   the root zone.
+
+2.10.  Misdirected recursive queries
+
+   The root name servers receive a significant number of recursive
+   queries (i.e., queries with the RD bit set in the header).  Since
+   none of the root servers offers recursion, the servers' response in
+   such a situation ignores the request for recursion and the response
+   probably does not contain the data the querier anticipated.  Some of
+   these queries result from users configuring stub resolvers to query a
+   root server.  (This situation is not hypothetical: we have received
+   complaints from users when this configuration does not work as
+   hoped.)  Of course, users should not direct stub resolvers to use
+   name servers that do not offer recursion, but we are not aware of any
+   stub resolver implementation that offers any feedback to the user
+   when so configured, aside from simply "not working".
+
+2.10.1.  Recommendation
+
+   When the IP address of a name server that supposedly offers recursion
+   is configured in a stub resolver using an interactive user interface,
+   the resolver could send a test query to verify that the server indeed
+   supports recursion (i.e., verify that the response has the RA bit set
+   in the header).  The user could be immediately notified if the server
+   is non-recursive.
+
+   The stub resolver could also report an error, either through a user
+   interface or in a log file, if the queried server does not support
+   recursion.  Error reporting SHOULD be throttled to avoid a
+   notification or log message for every response from a non-recursive
+   server.
+
+2.11.  Suboptimal name server selection algorithm
+
+   An entire document could be devoted to the topic of problems with
+   different implementations of the recursive resolution algorithm.  The
+   entire process of recursion is woefully under specified, requiring
+   each implementor to design an algorithm.  Sometimes implementors make
+   poor design choices that could be avoided if a suggested algorithm
+   and best practices were documented, but that is a topic for another
+   document.
+
+
+
+Larson & Barber          Expires August 14, 2006               [Page 15]
+
+Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
+
+
+   Some deficiencies cause significant operational impact and are
+   therefore worth mentioning here.  One of these is name server
+   selection by an iterative resolver.  When an iterative resolver wants
+   to contact one of a zone's authoritative name servers, how does it
+   choose from the NS records listed in the zone's NS RRset?  If the
+   selection mechanism is suboptimal, queries are not spread evenly
+   among a zone's authoritative servers.  The details of the selection
+   mechanism are up to the implementor, but we offer some suggestions.
+
+2.11.1.  Recommendation
+
+   This list is not conclusive, but reflects the changes that would
+   produce the most impact in terms of reducing disproportionate query
+   load among a zone's authoritative servers.  I.e., these changes would
+   help spread the query load evenly.
+
+   o  Do not make assumptions based on NS RRset order: all NS RRs SHOULD
+      be treated equally.  (In the case of the "com" zone, for example,
+      most of the root servers return the NS record for "a.gtld-
+      servers.net" first in the authority section of referrals.
+      Apparently as a result, this server receives disproportionately
+      more traffic than the other 12 authoritative servers for "com".)
+
+   o  Use all NS records in an RRset.  (For example, we are aware of
+      implementations that hard-coded information for a subset of the
+      root servers.)
+
+   o  Maintain state and favor the best-performing of a zone's
+      authoritative servers.  A good definition of performance is
+      response time.  Non-responsive servers can be penalized with an
+      extremely high response time.
+
+   o  Do not lock onto the best-performing of a zone's name servers.  An
+      iterative resolver SHOULD periodically check the performance of
+      all of a zone's name servers to adjust its determination of the
+      best-performing one.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Larson & Barber          Expires August 14, 2006               [Page 16]
+
+Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
+
+
+3.  Acknowledgments
+
+   The authors would like to thank the following people for their
+   comments that improved this document: Andras Salamon, Dave Meyer,
+   Doug Barton, Jaap Akkerhuis, Jinmei Tatuya, John Brady, Kevin Darcy,
+   Olafur Gudmundsson, Pekka Savola, Peter Koch and Rob Austein.  We
+   apologize if we have omitted anyone; any oversight was unintentional.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Larson & Barber          Expires August 14, 2006               [Page 17]
+
+Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
+
+
+4.  IANA considerations
+
+   There are no new IANA considerations introduced by this memo.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Larson & Barber          Expires August 14, 2006               [Page 18]
+
+Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
+
+
+5.  Security considerations
+
+   The iterative resolver misbehavior discussed in this document exposes
+   the root and TLD name servers to increased risk of both intentional
+   and unintentional denial of service attacks.
+
+   We believe that implementation of the recommendations offered in this
+   document will reduce the amount of unnecessary traffic seen at root
+   and TLD name servers, thus reducing the opportunity for an attacker
+   to use such queries to his or her advantage.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Larson & Barber          Expires August 14, 2006               [Page 19]
+
+Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
+
+
+6.  Internationalization considerations
+
+   There are no new internationalization considerations introduced by
+   this memo.
+
+7.  Informative References
+
+   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
+        Levels", BCP 14, RFC 2119, March 1997.
+
+   [2]  Mockapetris, P., "Domain names - concepts and facilities",
+        STD 13, RFC 1034, November 1987.
+
+   [3]  Elz, R. and R. Bush, "Clarifications to the DNS Specification",
+        RFC 2181, July 1997.
+
+   [4]  Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)",
+        RFC 2308, March 1998.
+
+   [5]  Morishita, Y. and T. Jinmei, "Common Misbehavior Against DNS
+        Queries for IPv6 Addresses", RFC 4074, May 2005.
+
+   [6]  Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic
+        Updates in the Domain Name System (DNS UPDATE)", RFC 2136,
+        April 1997.
+
+   [7]  Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E.
+        Lear, "Address Allocation for Private Internets", BCP 5,
+        RFC 1918, February 1996.
+
+   [8]  <http://www.as112.net>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Larson & Barber          Expires August 14, 2006               [Page 20]
+
+Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
+
+
+Authors' Addresses
+
+   Matt Larson
+   VeriSign, Inc.
+   21345 Ridgetop Circle
+   Dulles, VA  20166-6503
+   USA
+
+   Email: mlarson@verisign.com
+
+
+   Piet Barber
+   VeriSign, Inc.
+   21345 Ridgetop Circle
+   Dulles, VA  20166-6503
+   USA
+
+   Email: pbarber@verisign.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Larson & Barber          Expires August 14, 2006               [Page 21]
+
+Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2006).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Larson & Barber          Expires August 14, 2006               [Page 22]
+
diff --git a/doc/draft/draft-ietf-dnsop-dnssec-operational-practices-08.txt b/doc/draft/draft-ietf-dnsop-dnssec-operational-practices-08.txt
new file mode 100644
index 0000000..8ca68a8
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsop-dnssec-operational-practices-08.txt
@@ -0,0 +1,2016 @@
+
+
+
+DNSOP                                                         O. Kolkman
+Internet-Draft                                                 R. Gieben
+Obsoletes: 2541 (if approved)                                 NLnet Labs
+Expires: September 7, 2006                                 March 6, 2006
+
+
+                      DNSSEC Operational Practices
+          draft-ietf-dnsop-dnssec-operational-practices-08.txt
+
+Status of this Memo
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   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 draft documents 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 "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/ietf/1id-abstracts.txt.
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+   This Internet-Draft will expire on September 7, 2006.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   This document describes a set of practices for operating the DNS with
+   security extensions (DNSSEC).  The target audience is zone
+   administrators deploying DNSSEC.
+
+   The document discusses operational aspects of using keys and
+   signatures in the DNS.  It discusses issues as key generation, key
+   storage, signature generation, key rollover and related policies.
+
+
+
+
+Kolkman & Gieben        Expires September 7, 2006               [Page 1]
+
+Internet-Draft        DNSSEC Operational Practices            March 2006
+
+
+   This document obsoletes RFC 2541, as it covers more operational
+   ground and gives more up to date requirements with respect to key
+   sizes and the new DNSSEC specification.
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
+     1.1.  The Use of the Term 'key'  . . . . . . . . . . . . . . . .  4
+     1.2.  Time Definitions . . . . . . . . . . . . . . . . . . . . .  5
+   2.  Keeping the Chain of Trust Intact  . . . . . . . . . . . . . .  5
+   3.  Keys Generation and Storage  . . . . . . . . . . . . . . . . .  6
+     3.1.  Zone and Key Signing Keys  . . . . . . . . . . . . . . . .  6
+       3.1.1.  Motivations for the KSK and ZSK Separation . . . . . .  7
+       3.1.2.  KSKs for High Level Zones  . . . . . . . . . . . . . .  8
+     3.2.  Key Generation . . . . . . . . . . . . . . . . . . . . . .  8
+     3.3.  Key Effectivity Period . . . . . . . . . . . . . . . . . .  9
+     3.4.  Key Algorithm  . . . . . . . . . . . . . . . . . . . . . .  9
+     3.5.  Key Sizes  . . . . . . . . . . . . . . . . . . . . . . . . 10
+     3.6.  Private Key Storage  . . . . . . . . . . . . . . . . . . . 12
+   4.  Signature generation, Key Rollover and Related Policies  . . . 12
+     4.1.  Time in DNSSEC . . . . . . . . . . . . . . . . . . . . . . 12
+       4.1.1.  Time Considerations  . . . . . . . . . . . . . . . . . 13
+     4.2.  Key Rollovers  . . . . . . . . . . . . . . . . . . . . . . 14
+       4.2.1.  Zone Signing Key Rollovers . . . . . . . . . . . . . . 15
+       4.2.2.  Key Signing Key Rollovers  . . . . . . . . . . . . . . 19
+       4.2.3.  Difference Between ZSK and KSK Rollovers . . . . . . . 20
+       4.2.4.  Automated Key Rollovers  . . . . . . . . . . . . . . . 21
+     4.3.  Planning for Emergency Key Rollover  . . . . . . . . . . . 22
+       4.3.1.  KSK Compromise . . . . . . . . . . . . . . . . . . . . 22
+       4.3.2.  ZSK Compromise . . . . . . . . . . . . . . . . . . . . 24
+       4.3.3.  Compromises of Keys Anchored in Resolvers  . . . . . . 24
+     4.4.  Parental Policies  . . . . . . . . . . . . . . . . . . . . 24
+       4.4.1.  Initial Key Exchanges and Parental Policies
+               Considerations . . . . . . . . . . . . . . . . . . . . 24
+       4.4.2.  Storing Keys or Hashes?  . . . . . . . . . . . . . . . 25
+       4.4.3.  Security Lameness  . . . . . . . . . . . . . . . . . . 25
+       4.4.4.  DS Signature Validity Period . . . . . . . . . . . . . 26
+   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 26
+   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 27
+   7.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 27
+   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
+     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 27
+     8.2.  Informative References . . . . . . . . . . . . . . . . . . 28
+   Appendix A.  Terminology . . . . . . . . . . . . . . . . . . . . . 29
+   Appendix B.  Zone Signing Key Rollover Howto . . . . . . . . . . . 30
+   Appendix C.  Typographic Conventions . . . . . . . . . . . . . . . 31
+   Appendix D.  Document Details and Changes  . . . . . . . . . . . . 33
+
+
+
+Kolkman & Gieben        Expires September 7, 2006               [Page 2]
+
+Internet-Draft        DNSSEC Operational Practices            March 2006
+
+
+     D.1.  draft-ietf-dnsop-dnssec-operational-practices-00 . . . . . 33
+     D.2.  draft-ietf-dnsop-dnssec-operational-practices-01 . . . . . 33
+     D.3.  draft-ietf-dnsop-dnssec-operational-practices-02 . . . . . 33
+     D.4.  draft-ietf-dnsop-dnssec-operational-practices-03 . . . . . 33
+     D.5.  draft-ietf-dnsop-dnssec-operational-practices-04 . . . . . 34
+     D.6.  draft-ietf-dnsop-dnssec-operational-practices-05 . . . . . 34
+     D.7.  draft-ietf-dnsop-dnssec-operational-practices-06 . . . . . 34
+     D.8.  draft-ietf-dnsop-dnssec-operational-practices-07 . . . . . 34
+     D.9.  draft-ietf-dnsop-dnssec-operational-practices-08 . . . . . 34
+   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35
+   Intellectual Property and Copyright Statements . . . . . . . . . . 36
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kolkman & Gieben        Expires September 7, 2006               [Page 3]
+
+Internet-Draft        DNSSEC Operational Practices            March 2006
+
+
+1.  Introduction
+
+   This document describes how to run a DNSSEC (DNS SECure) enabled
+   environment.  It is intended for operators who have knowledge of the
+   DNS (see RFC 1034 [1] and RFC 1035 [2]) and want deploy DNSSEC.  See
+   RFC 4033 [4] for an introduction into DNSSEC and RFC 4034 [5] for the
+   newly introduced Resource Records and finally RFC 4035 [6] for the
+   protocol changes.
+
+   During workshops and early operational deployment tests, operators
+   and system administrators have gained experience about operating the
+   DNS with security extensions (DNSSEC).  This document translates
+   these experiences into a set of practices for zone administrators.
+   At the time of writing, there exists very little experience with
+   DNSSEC in production environments; this document should therefore
+   explicitly not be seen as representing 'Best Current Practices'.
+
+   The procedures herein are focused on the maintenance of signed zones
+   (i.e. signing and publishing zones on authoritative servers).  It is
+   intended that maintenance of zones such as re-signing or key
+   rollovers be transparent to any verifying clients on the Internet.
+
+   The structure of this document is as follows.  In Section 2 we
+   discuss the importance of keeping the "chain of trust" intact.
+   Aspects of key generation and storage of private keys are discussed
+   in Section 3; the focus in this section is mainly on the private part
+   of the key(s).  Section 4 describes considerations concerning the
+   public part of the keys.  Since these public keys appear in the DNS
+   one has to take into account all kinds of timing issues, which are
+   discussed in Section 4.1.  Section 4.2 and Section 4.3 deal with the
+   rollover, or supercession, of keys.  Finally Section 4.4 discusses
+   considerations on how parents deal with their children's public keys
+   in order to maintain chains of trust.
+
+   The typographic conventions used in this document are explained in
+   Appendix C.
+
+   Since this is a document with operational suggestions and there are
+   no protocol specifications, the RFC 2119 [9] language does not apply.
+
+   This document obsoletes RFC 2541 [12].
+
+1.1.  The Use of the Term 'key'
+
+   It is assumed that the reader is familiar with the concept of
+   asymmetric keys on which DNSSEC is based (Public Key Cryptography
+   [18]).  Therefore, this document will use the term 'key' rather
+   loosely.  Where it is written that 'a key is used to sign data' it is
+
+
+
+Kolkman & Gieben        Expires September 7, 2006               [Page 4]
+
+Internet-Draft        DNSSEC Operational Practices            March 2006
+
+
+   assumed that the reader understands that it is the private part of
+   the key pair that is used for signing.  It is also assumed that the
+   reader understands that the public part of the key pair is published
+   in the DNSKEY resource record and that it is the public part that is
+   used in key exchanges.
+
+1.2.  Time Definitions
+
+   In this document we will be using a number of time related terms.
+   The following definitions apply:
+   o  "Signature validity period"
+         The period that a signature is valid.  It starts at the time
+         specified in the signature inception field of the RRSIG RR and
+         ends at the time specified in the expiration field of the RRSIG
+         RR.
+   o  "Signature publication period"
+         Time after which a signature (made with a specific key) is
+         replaced with a new signature (made with the same key).  This
+         replacement takes place by publishing the relevant RRSIG in the
+         master zone file.
+         After one stops publishing an RRSIG in a zone it may take a
+         while before the RRSIG has expired from caches and has actually
+         been removed from the DNS.
+   o  "Key effectivity period"
+         The period during which a key pair is expected to be effective.
+         This period is defined as the time between the first inception
+         time stamp and the last expiration date of any signature made
+         with this key, regardless of any discontinuity in the use of
+         the key.
+         The key effectivity period can span multiple signature validity
+         periods.
+   o  "Maximum/Minimum Zone Time to Live (TTL)"
+         The maximum or minimum value of the TTLs from the complete set
+         of RRs in a zone.  Note that the minimum TTL is not the same as
+         the MINIMUM field in the SOA RR.  See [11] for more
+         information.
+
+
+2.  Keeping the Chain of Trust Intact
+
+   Maintaining a valid chain of trust is important because broken chains
+   of trust will result in data being marked as Bogus (as defined in [4]
+   section 5), which may cause entire (sub)domains to become invisible
+   to verifying clients.  The administrators of secured zones have to
+   realize that their zone is, to verifying clients, part of a chain of
+   trust.
+
+   As mentioned in the introduction, the procedures herein are intended
+
+
+
+Kolkman & Gieben        Expires September 7, 2006               [Page 5]
+
+Internet-Draft        DNSSEC Operational Practices            March 2006
+
+
+   to ensure that maintenance of zones, such as re-signing or key
+   rollovers, will be transparent to the verifying clients on the
+   Internet.
+
+   Administrators of secured zones will have to keep in mind that data
+   published on an authoritative primary server will not be immediately
+   seen by verifying clients; it may take some time for the data to be
+   transferred to other secondary authoritative nameservers and clients
+   may be fetching data from caching non-authoritative servers.  In this
+   light it is good to note that the time for a zone transfer from
+   master to slave is negligible when using NOTIFY [8] and IXFR [7],
+   increasing by reliance on AXFR, and more if you rely on the SOA
+   timing parameters for zone refresh.
+
+   For the verifying clients it is important that data from secured
+   zones can be used to build chains of trust regardless of whether the
+   data came directly from an authoritative server, a caching nameserver
+   or some middle box.  Only by carefully using the available timing
+   parameters can a zone administrator assure that the data necessary
+   for verification can be obtained.
+
+   The responsibility for maintaining the chain of trust is shared by
+   administrators of secured zones in the chain of trust.  This is most
+   obvious in the case of a 'key compromise' when a trade off between
+   maintaining a valid chain of trust and replacing the compromised keys
+   as soon as possible must be made.  Then zone administrators will have
+   to make a trade off, between keeping the chain of trust intact -
+   thereby allowing for attacks with the compromised key - or to
+   deliberately break the chain of trust and making secured sub domains
+   invisible to security aware resolvers.  Also see Section 4.3.
+
+
+3.  Keys Generation and Storage
+
+   This section describes a number of considerations with respect to the
+   security of keys.  It deals with the generation, effectivity period,
+   size and storage of private keys.
+
+3.1.  Zone and Key Signing Keys
+
+   The DNSSEC validation protocol does not distinguish between different
+   types of DNSKEYs.  All DNSKEYs can be used during the validation.  In
+   practice operators use Key Signing and Zone Signing Keys and use the
+   so-called (Secure Entry Point) SEP [3] flag to distinguish between
+   them during operations.  The dynamics and considerations are
+   discussed below.
+
+   To make zone re-signing and key rollover procedures easier to
+
+
+
+Kolkman & Gieben        Expires September 7, 2006               [Page 6]
+
+Internet-Draft        DNSSEC Operational Practices            March 2006
+
+
+   implement, it is possible to use one or more keys as Key Signing Keys
+   (KSK).  These keys will only sign the apex DNSKEY RRSet in a zone.
+   Other keys can be used to sign all the RRSets in a zone and are
+   referred to as Zone Signing Keys (ZSK).  In this document we assume
+   that KSKs are the subset of keys that are used for key exchanges with
+   the parent and potentially for configuration as trusted anchors - the
+   SEP keys.  In this document we assume a one-to-one mapping between
+   KSK and SEP keys and we assume the SEP flag to be set on all KSKs.
+
+3.1.1.  Motivations for the KSK and ZSK Separation
+
+   Differentiating between the KSK and ZSK functions has several
+   advantages:
+
+   o  No parent/child interaction is required when ZSKs are updated.
+   o  The KSK can be made stronger (i.e. using more bits in the key
+      material).  This has little operational impact since it is only
+      used to sign a small fraction of the zone data.  Also the KSK is
+      only used to verify the zone's key set, not for other RRSets in
+      the zone.
+   o  As the KSK is only used to sign a key set, which is most probably
+      updated less frequently than other data in the zone, it can be
+      stored separately from and in a safer location than the ZSK.
+   o  A KSK can have a longer key effectivity period.
+
+   For almost any method of key management and zone signing the KSK is
+   used less frequently than the ZSK.  Once a key set is signed with the
+   KSK all the keys in the key set can be used as ZSK.  If a ZSK is
+   compromised, it can be simply dropped from the key set.  The new key
+   set is then re-signed with the KSK.
+
+   Given the assumption that for KSKs the SEP flag is set, the KSK can
+   be distinguished from a ZSK by examining the flag field in the DNSKEY
+   RR.  If the flag field is an odd number it is a KSK.  If it is an
+   even number it is a ZSK.
+
+   The zone signing key can be used to sign all the data in a zone on a
+   regular basis.  When a zone signing key is to be rolled, no
+   interaction with the parent is needed.  This allows for "Signature
+   Validity Periods" on the order of days.
+
+   The key signing key is only to be used to sign the DNSKEY RRs in a
+   zone.  If a key signing key is to be rolled over, there will be
+   interactions with parties other than the zone administrator.  These
+   can include the registry of the parent zone or administrators of
+   verifying resolvers that have the particular key configured as secure
+   entry points.  Hence, the key effectivity period of these keys can
+   and should be made much longer.  Although, given a long enough key,
+
+
+
+Kolkman & Gieben        Expires September 7, 2006               [Page 7]
+
+Internet-Draft        DNSSEC Operational Practices            March 2006
+
+
+   the Key Effectivity Period can be on the order of years we suggest
+   planning for a key effectivity of the order of a few months so that a
+   key rollover remains an operational routine.
+
+3.1.2.  KSKs for High Level Zones
+
+   Higher level zones are generally more sensitive than lower level
+   zones.  Anyone controlling or breaking the security of a zone thereby
+   obtains authority over all of its sub domains (except in the case of
+   resolvers that have locally configured the public key of a sub
+   domain, in which case this, and only this, sub domain wouldn't be
+   affected by the compromise of the parent zone).  Therefore, extra
+   care should be taken with high level zones and strong keys should
+   used.
+
+   The root zone is the most critical of all zones.  Someone controlling
+   or compromising the security of the root zone would control the
+   entire DNS name space of all resolvers using that root zone (except
+   in the case of resolvers that have locally configured the public key
+   of a sub domain).  Therefore, the utmost care must be taken in the
+   securing of the root zone.  The strongest and most carefully handled
+   keys should be used.  The root zone private key should always be kept
+   off line.
+
+   Many resolvers will start at a root server for their access to and
+   authentication of DNS data.  Securely updating the trust anchors in
+   an enormous population of resolvers around the world will be
+   extremely difficult.
+
+3.2.  Key Generation
+
+   Careful generation of all keys is a sometimes overlooked but
+   absolutely essential element in any cryptographically secure system.
+   The strongest algorithms used with the longest keys are still of no
+   use if an adversary can guess enough to lower the size of the likely
+   key space so that it can be exhaustively searched.  Technical
+   suggestions for the generation of random keys will be found in RFC
+   4086 [15].  One should carefully assess if the random number
+   generator used during key generation adheres to these suggestions.
+
+   Keys with a long effectivity period are particularly sensitive as
+   they will represent a more valuable target and be subject to attack
+   for a longer time than short period keys.  It is strongly recommended
+   that long term key generation occur off-line in a manner isolated
+   from the network via an air gap or, at a minimum, high level secure
+   hardware.
+
+
+
+
+
+Kolkman & Gieben        Expires September 7, 2006               [Page 8]
+
+Internet-Draft        DNSSEC Operational Practices            March 2006
+
+
+3.3.  Key Effectivity Period
+
+   For various reasons keys in DNSSEC need to be changed once in a
+   while.  The longer a key is in use, the greater the probability that
+   it will have been compromised through carelessness, accident,
+   espionage, or cryptanalysis.  Furthermore when key rollovers are too
+   rare an event, they will not become part of the operational habit and
+   there is risk that nobody on-site will remember the procedure for
+   rollover when the need is there.
+
+   From a purely operational perspective a reasonable key effectivity
+   period for Key Signing Keys is 13 months, with the intent to replace
+   them after 12 months.  An intended key effectivity period of a month
+   is reasonable for Zone Signing Keys.
+
+   For key sizes that matches these effectivity periods see Section 3.5.
+
+   As argued in Section 3.1.2 securely updating trust anchors will be
+   extremely difficult.  On the other hand the "operational habit"
+   argument does also apply to trust anchor reconfiguration.  If a short
+   key-effectivity period is used and the trust anchor configuration has
+   to be revisited on a regular basis the odds that the configuration
+   tends to be forgotten is smaller.  The trade-off is against a system
+   that is so dynamic that administrators of the validating clients will
+   not be able to follow the modifications.
+
+   Key effectivity periods can be made very short, as in the order of a
+   few minutes.  But when replacing keys one has to take the
+   considerations from Section 4.1 and Section 4.2 into account.
+
+3.4.  Key Algorithm
+
+   There are currently three different types of algorithms that can be
+   used in DNSSEC: RSA, DSA and elliptic curve cryptography.  The latter
+   is fairly new and has yet to be standardized for usage in DNSSEC.
+
+   RSA has been developed in an open and transparent manner.  As the
+   patent on RSA expired in 2000, its use is now also free.
+
+   DSA has been developed by NIST.  The creation of signatures takes
+   roughly the same time as with RSA, but is 10 to 40 times as slow for
+   verification [18].
+
+   We suggest the use of RSA/SHA-1 as the preferred algorithm for the
+   key.  The current known attacks on RSA can be defeated by making your
+   key longer.  As the MD5 hashing algorithm is showing (theoretical)
+   cracks, we recommend the usage of SHA-1.
+
+
+
+
+Kolkman & Gieben        Expires September 7, 2006               [Page 9]
+
+Internet-Draft        DNSSEC Operational Practices            March 2006
+
+
+   At the time of publication it is known that the SHA-1 hash has
+   cryptanalysis issues.  There is work in progress on addressing these
+   issues.  We recommend the use of public key algorithms based on
+   hashes stronger than SHA-1, e.g.  SHA-256, as soon as these
+   algorithms are available in protocol specifications (See [20] and
+   [21] ) and implementations.
+
+3.5.  Key Sizes
+
+   When choosing key sizes, zone administrators will need to take into
+   account how long a key will be used, how much data will be signed
+   during the key publication period (See Section 8.10 of [18]) and,
+   optionally, how large the key size of the parent is.  As the chain of
+   trust really is "a chain", there is not much sense in making one of
+   the keys in the chain several times larger then the others.  As
+   always, it's the weakest link that defines the strength of the entire
+   chain.  Also see Section 3.1.1 for a discussion of how keys serving
+   different roles (ZSK v.  KSK) may need different key sizes.
+
+   Generating a key of the correct size is a difficult problem, RFC 3766
+   [14] tries to deal with that problem.  The first part of the
+   selection procedure in Section 1 of the RFC states:
+
+      1. Determine the attack resistance necessary to satisfy the
+         security requirements of the application.  Do this by
+         estimating the minimum number of computer operations that
+         the attacker will be forced to do in order to compromise
+         the security of the system and then take the logarithm base
+         two of that number.  Call that logarithm value "n".
+
+         A 1996 report recommended 90 bits as a good all-around choice
+         for system security.  The 90 bit number should be increased
+         by about 2/3 bit/year, or about 96 bits in 2005.
+
+   [14] goes on to explain how this number "n" can be used to calculate
+   the key sizes in public key cryptography.  This culminated in the
+   table given below (slightly modified for our purpose):
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kolkman & Gieben        Expires September 7, 2006              [Page 10]
+
+Internet-Draft        DNSSEC Operational Practices            March 2006
+
+
+      +-------------+-----------+--------------+
+      | System      |           |              |
+      | requirement | Symmetric | RSA or DSA   |
+      | for attack  | key size  | modulus size |
+      | resistance  | (bits)    | (bits)       |
+      | (bits)      |           |              |
+      +-------------+-----------+--------------+
+      |     70      |     70    |      947     |
+      |     80      |     80    |     1228     |
+      |     90      |     90    |     1553     |
+      |    100      |    100    |     1926     |
+      |    150      |    150    |     4575     |
+      |    200      |    200    |     8719     |
+      |    250      |    250    |    14596     |
+      +-------------+-----------+--------------+
+
+   The key sizes given are rather large.  This is because these keys are
+   resilient against a trillionaire attacker.  Assuming this rich
+   attacker will not attack your key and that the key is rolled over
+   once a year, we come to the following recommendations about KSK
+   sizes; 1024 bits low value domains, 1300 for medium value and 2048
+   for the high value domains.
+
+   Whether a domain is of low, medium, high value depends solely on the
+   views of the zone owner.  One could for instance view leaf nodes in
+   the DNS as of low value and TLDs or the root zone of high value.  The
+   suggested key sizes should be safe for the next 5 years.
+
+   As ZSKs can be rolled over more easily (and thus more often) the key
+   sizes can be made smaller.  But as said in the introduction of this
+   paragraph, making the ZSKs' key sizes too small (in relation to the
+   KSKs' sizes) doesn't make much sense.  Try to limit the difference in
+   size to about 100 bits.
+
+   Note that nobody can see into the future, and that these key sizes
+   are only provided here as a guide.  Further information can be found
+   in [17] and Section 7.5 of [18].  It should be noted though that [17]
+   is already considered overly optimistic about what key sizes are
+   considered safe.
+
+   One final note concerning key sizes.  Larger keys will increase the
+   sizes of the RRSIG and DNSKEY records and will therefore increase the
+   chance of DNS UDP packet overflow.  Also the time it takes to
+   validate and create RRSIGs increases with larger keys, so don't
+   needlessly double your key sizes.
+
+
+
+
+
+
+Kolkman & Gieben        Expires September 7, 2006              [Page 11]
+
+Internet-Draft        DNSSEC Operational Practices            March 2006
+
+
+3.6.  Private Key Storage
+
+   It is recommended that, where possible, zone private keys and the
+   zone file master copy that is to be signed, be kept and used in off-
+   line, non-network connected, physically secure machines only.
+   Periodically an application can be run to add authentication to a
+   zone by adding RRSIG and NSEC RRs.  Then the augmented file can be
+   transferred.
+
+   When relying on dynamic update to manage a signed zone [10], be aware
+   that at least one private key of the zone will have to reside on the
+   master server.  This key is only as secure as the amount of exposure
+   the server receives to unknown clients and the security of the host.
+   Although not mandatory one could administer the DNS in the following
+   way.  The master that processes the dynamic updates is unavailable
+   from generic hosts on the Internet, it is not listed in the NS RR
+   set, although its name appears in the SOA RRs MNAME field.  The
+   nameservers in the NS RR set are able to receive zone updates through
+   NOTIFY, IXFR, AXFR or an out-of-band distribution mechanism.  This
+   approach is known as the "hidden master" setup.
+
+   The ideal situation is to have a one way information flow to the
+   network to avoid the possibility of tampering from the network.
+   Keeping the zone master file on-line on the network and simply
+   cycling it through an off-line signer does not do this.  The on-line
+   version could still be tampered with if the host it resides on is
+   compromised.  For maximum security, the master copy of the zone file
+   should be off net and should not be updated based on an unsecured
+   network mediated communication.
+
+   In general keeping a zone-file off-line will not be practical and the
+   machines on which zone files are maintained will be connected to a
+   network.  Operators are advised to take security measures to shield
+   unauthorized access to the master copy.
+
+   For dynamically updated secured zones [10] both the master copy and
+   the private key that is used to update signatures on updated RRs will
+   need to be on-line.
+
+
+4.  Signature generation, Key Rollover and Related Policies
+
+4.1.  Time in DNSSEC
+
+   Without DNSSEC all times in DNS are relative.  The SOA fields
+   REFRESH, RETRY and EXPIRATION are timers used to determine the time
+   elapsed after a slave server synchronized with a master server.  The
+   Time to Live (TTL) value and the SOA RR minimum TTL parameter [11]
+
+
+
+Kolkman & Gieben        Expires September 7, 2006              [Page 12]
+
+Internet-Draft        DNSSEC Operational Practices            March 2006
+
+
+   are used to determine how long a forwarder should cache data after it
+   has been fetched from an authoritative server.  By using a signature
+   validity period, DNSSEC introduces the notion of an absolute time in
+   the DNS.  Signatures in DNSSEC have an expiration date after which
+   the signature is marked as invalid and the signed data is to be
+   considered Bogus.
+
+4.1.1.  Time Considerations
+
+   Because of the expiration of signatures, one should consider the
+   following:
+   o  We suggest the Maximum Zone TTL of your zone data to be a fraction
+      of your signature validity period.
+         If the TTL would be of similar order as the signature validity
+         period, then all RRSets fetched during the validity period
+         would be cached until the signature expiration time.  Section
+         7.1 of [4] suggests that "the resolver may use the time
+         remaining before expiration of the signature validity period of
+         a signed RRSet as an upper bound for the TTL".  As a result
+         query load on authoritative servers would peak at signature
+         expiration time, as this is also the time at which records
+         simultaneously expire from caches.
+         To avoid query load peaks we suggest the TTL on all the RRs in
+         your zone to be at least a few times smaller than your
+         signature validity period.
+   o  We suggest the Signature Publication Period to end at least one
+      Maximum Zone TTL duration before the end of the Signature Validity
+      Period.
+         Re-signing a zone shortly before the end of the signature
+         validity period may cause simultaneous expiration of data from
+         caches.  This in turn may lead to peaks in the load on
+         authoritative servers.
+   o  We suggest the minimum zone TTL to be long enough to both fetch
+      and verify all the RRs in the trust chain.  In workshop
+      environments it has been demonstrated [19] that a low TTL (under 5
+      to 10 minutes) caused disruptions because of the following two
+      problems:
+         1.  During validation, some data may expire before the
+         validation is complete.  The validator should be able to keep
+         all data, until is completed.  This applies to all RRs needed
+         to complete the chain of trust: DSs, DNSKEYs, RRSIGs, and the
+         final answers i.e. the RRSet that is returned for the initial
+         query.
+         2.  Frequent verification causes load on recursive nameservers.
+         Data at delegation points, DSs, DNSKEYs and RRSIGs benefit from
+         caching.  The TTL on those should be relatively long.
+
+
+
+
+
+Kolkman & Gieben        Expires September 7, 2006              [Page 13]
+
+Internet-Draft        DNSSEC Operational Practices            March 2006
+
+
+   o  Slave servers will need to be able to fetch newly signed zones
+      well before the RRSIGs in the zone served by the slave server pass
+      their signature expiration time.
+         When a slave server is out of sync with its master and data in
+         a zone is signed by expired signatures it may be better for the
+         slave server not to give out any answer.
+         Normally a slave server that is not able to contact a master
+         server for an extended period will expire a zone.  When that
+         happens the server will respond differently to queries for that
+         zone.  Some servers issue SERVFAIL while others turn off the
+         'AA' bit in the answers.  The time of expiration is set in the
+         SOA record and is relative to the last successful refresh
+         between the master and the slave server.  There exists no
+         coupling between the signature expiration of RRSIGs in the zone
+         and the expire parameter in the SOA.
+         If the server serves a DNSSEC zone then it may well happen that
+         the signatures expire well before the SOA expiration timer
+         counts down to zero.  It is not possible to completely prevent
+         this from happening by tweaking the SOA parameters.
+         However, the effects can be minimized where the SOA expiration
+         time is equal or shorter than the signature validity period.
+         The consequence of an authoritative server not being able to
+         update a zone, whilst that zone includes expired signatures, is
+         that non-secure resolvers will continue to be able to resolve
+         data served by the particular slave servers while security
+         aware resolvers will experience problems because of answers
+         being marked as Bogus.
+         We suggest the SOA expiration timer being approximately one
+         third or one fourth of the signature validity period.  It will
+         allow problems with transfers from the master server to be
+         noticed before the actual signature times out.
+         We also suggest that operators of nameservers that supply
+         secondary services develop 'watch dogs' to spot upcoming
+         signature expirations in zones they slave, and take appropriate
+         action.
+         When determining the value for the expiration parameter one has
+         to take the following into account: What are the chances that
+         all my secondaries expire the zone; How quickly can I reach an
+         administrator of secondary servers to load a valid zone?  All
+         these arguments are not DNSSEC specific but may influence the
+         choice of your signature validity intervals.
+
+4.2.  Key Rollovers
+
+   A DNSSEC key cannot be used forever (see Section 3.3).  So key
+   rollovers -- or supercessions, as they are sometimes called -- are a
+   fact of life when using DNSSEC.  Zone administrators who are in the
+   process of rolling their keys have to take into account that data
+
+
+
+Kolkman & Gieben        Expires September 7, 2006              [Page 14]
+
+Internet-Draft        DNSSEC Operational Practices            March 2006
+
+
+   published in previous versions of their zone still lives in caches.
+   When deploying DNSSEC, this becomes an important consideration;
+   ignoring data that may be in caches may lead to loss of service for
+   clients.
+
+   The most pressing example of this occurs when zone material signed
+   with an old key is being validated by a resolver which does not have
+   the old zone key cached.  If the old key is no longer present in the
+   current zone, this validation fails, marking the data Bogus.
+   Alternatively, an attempt could be made to validate data which is
+   signed with a new key against an old key that lives in a local cache,
+   also resulting in data being marked Bogus.
+
+4.2.1.  Zone Signing Key Rollovers
+
+   For zone signing key rollovers there are two ways to make sure that
+   during the rollover data still cached can be verified with the new
+   key sets or newly generated signatures can be verified with the keys
+   still in caches.  One schema, described in Section 4.2.1.2, uses
+   double signatures; the other uses key pre-publication
+   (Section 4.2.1.1).  The pros, cons and recommendations are described
+   in Section 4.2.1.3.
+
+4.2.1.1.  Pre-publish Key Rollover
+
+   This section shows how to perform a ZSK rollover without the need to
+   sign all the data in a zone twice - the so-called "pre-publish
+   rollover".This method has advantages in the case of a key compromise.
+   If the old key is compromised, the new key has already been
+   distributed in the DNS.  The zone administrator is then able to
+   quickly switch to the new key and remove the compromised key from the
+   zone.  Another major advantage is that the zone size does not double,
+   as is the case with the double signature ZSK rollover.  A small
+   "HOWTO" for this kind of rollover can be found in Appendix B.
+
+   Pre-publish Key Rollover involves four stages as follows:
+
+    initial         new DNSKEY       new RRSIGs      DNSKEY removal
+
+    SOA0            SOA1             SOA2            SOA3
+    RRSIG10(SOA0)   RRSIG10(SOA1)    RRSIG11(SOA2)   RRSIG11(SOA3)
+
+    DNSKEY1         DNSKEY1          DNSKEY1         DNSKEY1
+    DNSKEY10        DNSKEY10         DNSKEY10        DNSKEY11
+                    DNSKEY11         DNSKEY11
+    RRSIG1 (DNSKEY) RRSIG1 (DNSKEY)  RRSIG1(DNSKEY)  RRSIG1 (DNSKEY)
+    RRSIG10(DNSKEY) RRSIG10(DNSKEY)  RRSIG11(DNSKEY) RRSIG11(DNSKEY)
+
+
+
+
+Kolkman & Gieben        Expires September 7, 2006              [Page 15]
+
+Internet-Draft        DNSSEC Operational Practices            March 2006
+
+
+   initial: Initial version of the zone: DNSKEY 1 is the key signing
+      key.  DNSKEY 10 is used to sign all the data of the zone, the zone
+      signing key.
+   new DNSKEY: DNSKEY 11 is introduced into the key set.  Note that no
+      signatures are generated with this key yet, but this does not
+      secure against brute force attacks on the public key.  The minimum
+      duration of this pre-roll phase is the time it takes for the data
+      to propagate to the authoritative servers plus TTL value of the
+      key set.
+   new RRSIGs: At the "new RRSIGs" stage (SOA serial 2) DNSKEY 11 is
+      used to sign the data in the zone exclusively (i.e. all the
+      signatures from DNSKEY 10 are removed from the zone).  DNSKEY 10
+      remains published in the key set.  This way data that was loaded
+      into caches from version 1 of the zone can still be verified with
+      key sets fetched from version 2 of the zone.
+      The minimum time that the key set including DNSKEY 10 is to be
+      published is the time that it takes for zone data from the
+      previous version of the zone to expire from old caches i.e. the
+      time it takes for this zone to propagate to all authoritative
+      servers plus the Maximum Zone TTL value of any of the data in the
+      previous version of the zone.
+   DNSKEY removal: DNSKEY 10 is removed from the zone.  The key set, now
+      only containing DNSKEY 1 and DNSKEY 11 is re-signed with the
+      DNSKEY 1.
+
+   The above scheme can be simplified by always publishing the "future"
+   key immediately after the rollover.  The scheme would look as follows
+   (we show two rollovers); the future key is introduced in "new DNSKEY"
+   as DNSKEY 12 and again a newer one, numbered 13, in "new DNSKEY
+   (II)":
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kolkman & Gieben        Expires September 7, 2006              [Page 16]
+
+Internet-Draft        DNSSEC Operational Practices            March 2006
+
+
+       initial             new RRSIGs          new DNSKEY
+
+       SOA0                SOA1                SOA2
+       RRSIG10(SOA0)       RRSIG11(SOA1)       RRSIG11(SOA2)
+
+       DNSKEY1             DNSKEY1             DNSKEY1
+       DNSKEY10            DNSKEY10            DNSKEY11
+       DNSKEY11            DNSKEY11            DNSKEY12
+       RRSIG1(DNSKEY)      RRSIG1 (DNSKEY)     RRSIG1(DNSKEY)
+       RRSIG10(DNSKEY)     RRSIG11(DNSKEY)     RRSIG11(DNSKEY)
+
+
+       new RRSIGs (II)     new DNSKEY (II)
+
+       SOA3                SOA4
+       RRSIG12(SOA3)       RRSIG12(SOA4)
+
+       DNSKEY1             DNSKEY1
+       DNSKEY11            DNSKEY12
+       DNSKEY12            DNSKEY13
+       RRSIG1(DNSKEY)      RRSIG1(DNSKEY)
+       RRSIG12(DNSKEY)     RRSIG12(DNSKEY)
+
+
+   Pre-Publish Key Rollover, showing two rollovers.
+
+   Note that the key introduced in the "new DNSKEY" phase is not used
+   for production yet; the private key can thus be stored in a
+   physically secure manner and does not need to be 'fetched' every time
+   a zone needs to be signed.
+
+4.2.1.2.  Double Signature Zone Signing Key Rollover
+
+   This section shows how to perform a ZSK key rollover using the double
+   zone data signature scheme, aptly named "double sig rollover".
+
+   During the "new DNSKEY" stage the new version of the zone file will
+   need to propagate to all authoritative servers and the data that
+   exists in (distant) caches will need to expire, requiring at least
+   the maximum Zone TTL.
+
+
+
+
+
+
+
+
+
+
+
+Kolkman & Gieben        Expires September 7, 2006              [Page 17]
+
+Internet-Draft        DNSSEC Operational Practices            March 2006
+
+
+   Double Signature Zone Signing Key Rollover involves three stages as
+   follows:
+
+       initial             new DNSKEY         DNSKEY removal
+
+       SOA0                SOA1               SOA2
+       RRSIG10(SOA0)       RRSIG10(SOA1)      RRSIG11(SOA2)
+                           RRSIG11(SOA1)
+
+       DNSKEY1             DNSKEY1            DNSKEY1
+       DNSKEY10            DNSKEY10           DNSKEY11
+                           DNSKEY11
+       RRSIG1(DNSKEY)      RRSIG1(DNSKEY)     RRSIG1(DNSKEY)
+       RRSIG10(DNSKEY)     RRSIG10(DNSKEY)    RRSIG11(DNSKEY)
+                           RRSIG11(DNSKEY)
+
+   initial: Initial Version of the zone: DNSKEY 1 is the key signing
+      key.  DNSKEY 10 is used to sign all the data of the zone, the zone
+      signing key.
+   new DNSKEY: At the "New DNSKEY" stage (SOA serial 1) DNSKEY 11 is
+      introduced into the key set and all the data in the zone is signed
+      with DNSKEY 10 and DNSKEY 11.  The rollover period will need to
+      continue until all data from version 0 of the zone has expired
+      from remote caches.  This will take at least the maximum Zone TTL
+      of version 0 of the zone.
+   DNSKEY removal: DNSKEY 10 is removed from the zone.  All the
+      signatures from DNSKEY 10 are removed from the zone.  The key set,
+      now only containing DNSKEY 11, is re-signed with DNSKEY 1.
+
+   At every instance, RRSIGs from the previous version of the zone can
+   be verified with the DNSKEY RRSet from the current version and the
+   other way around.  The data from the current version can be verified
+   with the data from the previous version of the zone.  The duration of
+   the "new DNSKEY" phase and the period between rollovers should be at
+   least the Maximum Zone TTL.
+
+   Making sure that the "new DNSKEY" phase lasts until the signature
+   expiration time of the data in initial version of the zone is
+   recommended.  This way all caches are cleared of the old signatures.
+   However, this duration could be considerably longer than the Maximum
+   Zone TTL, making the rollover a lengthy procedure.
+
+   Note that in this example we assumed that the zone was not modified
+   during the rollover.  New data can be introduced in the zone as long
+   as it is signed with both keys.
+
+
+
+
+
+
+Kolkman & Gieben        Expires September 7, 2006              [Page 18]
+
+Internet-Draft        DNSSEC Operational Practices            March 2006
+
+
+4.2.1.3.  Pros and Cons of the Schemes
+
+   Pre-publish Key Rollover: This rollover does not involve signing the
+      zone data twice.  Instead, before the actual rollover, the new key
+      is published in the key set and thus available for cryptanalysis
+      attacks.  A small disadvantage is that this process requires four
+      steps.  Also the pre-publish scheme involves more parental work
+      when used for KSK rollovers as explained in Section 4.2.3.
+   Double Signature Zone-signing Key Rollover: The drawback of this
+      signing scheme is that during the rollover the number of
+      signatures in your zone doubles, this may be prohibitive if you
+      have very big zones.  An advantage is that it only requires three
+      steps.
+
+4.2.2.  Key Signing Key Rollovers
+
+   For the rollover of a key signing key the same considerations as for
+   the rollover of a zone signing key apply.  However we can use a
+   double signature scheme to guarantee that old data (only the apex key
+   set) in caches can be verified with a new key set and vice versa.
+   Since only the key set is signed with a KSK, zone size considerations
+   do not apply.
+
+
+       initial        new DNSKEY        DS change       DNSKEY removal
+     Parent:
+       SOA0           -------->         SOA1            -------->
+       RRSIGpar(SOA0) -------->         RRSIGpar(SOA1)  -------->
+       DS1            -------->         DS2             -------->
+       RRSIGpar(DS)   -------->         RRSIGpar(DS)    -------->
+
+
+     Child:
+       SOA0            SOA1             -------->       SOA2
+       RRSIG10(SOA0)   RRSIG10(SOA1)    -------->       RRSIG10(SOA2)
+                                        -------->
+       DNSKEY1         DNSKEY1          -------->       DNSKEY2
+                       DNSKEY2          -------->
+       DNSKEY10        DNSKEY10         -------->       DNSKEY10
+       RRSIG1 (DNSKEY) RRSIG1 (DNSKEY)  -------->       RRSIG2 (DNSKEY)
+                       RRSIG2 (DNSKEY)  -------->
+       RRSIG10(DNSKEY) RRSIG10(DNSKEY)  -------->       RRSIG10(DNSKEY)
+
+   Stages of Deployment for Key Signing Key Rollover.
+
+
+
+
+
+
+
+Kolkman & Gieben        Expires September 7, 2006              [Page 19]
+
+Internet-Draft        DNSSEC Operational Practices            March 2006
+
+
+   initial: Initial version of the zone.  The parental DS points to
+      DNSKEY1.  Before the rollover starts the child will have to verify
+      what the TTL is of the DS RR that points to DNSKEY1 - it is needed
+      during the rollover and we refer to the value as TTL_DS.
+   new DNSKEY: During the "new DNSKEY" phase the zone administrator
+      generates a second KSK, DNSKEY2.  The key is provided to the
+      parent and the child will have to wait until a new DS RR has been
+      generated that points to DNSKEY2.  After that DS RR has been
+      published on all servers authoritative for the parent's zone, the
+      zone administrator has to wait at least TTL_DS to make sure that
+      the old DS RR has expired from caches.
+   DS change: The parent replaces DS1 with DS2.
+   DNSKEY removal: DNSKEY1 has been removed.
+
+   The scenario above puts the responsibility for maintaining a valid
+   chain of trust with the child.  It also is based on the premises that
+   the parent only has one DS RR (per algorithm) per zone.  An
+   alternative mechanism has been considered.  Using an established
+   trust relation, the interaction can be performed in-band, and the
+   removal of the keys by the child can possibly be signaled by the
+   parent.  In this mechanism there are periods where there are two DS
+   RRs at the parent.  Since at the moment of writing the protocol for
+   this interaction has not been developed, further discussion is out of
+   scope for this document.
+
+4.2.3.  Difference Between ZSK and KSK Rollovers
+
+   Note that KSK rollovers and ZSK rollovers are different in the sense
+   that a KSK rollover requires interaction with the parent (and
+   possibly replacing of trust anchors) and the ensuing delay while
+   waiting for it.
+
+   A zone key rollover can be handled in two different ways: pre-publish
+   (Section Section 4.2.1.1) and double signature (Section
+   Section 4.2.1.2).
+
+   As the KSK is used to validate the key set and because the KSK is not
+   changed during a ZSK rollover, a cache is able to validate the new
+   key set of the zone.  The pre-publish method would also work for a
+   KSK rollover.  The records that are to be pre-published are the
+   parental DS RRs.  The pre-publish method has some drawbacks for KSKs.
+   We first describe the rollover scheme and then indicate these
+   drawbacks.
+
+
+
+
+
+
+
+
+Kolkman & Gieben        Expires September 7, 2006              [Page 20]
+
+Internet-Draft        DNSSEC Operational Practices            March 2006
+
+
+     initial         new DS           new DNSKEY      DS/DNSKEY removal
+   Parent:
+     SOA0            SOA1             -------->       SOA2
+     RRSIGpar(SOA0)  RRSIGpar(SOA1)   -------->       RRSIGpar(SOA2)
+     DS1             DS1              -------->       DS2
+                     DS2              -------->
+     RRSIGpar(DS)    RRSIGpar(DS)     -------->       RRSIGpar(DS)
+
+
+
+   Child:
+     SOA0            -------->        SOA1            SOA1
+     RRSIG10(SOA0)   -------->        RRSIG10(SOA1)   RRSIG10(SOA1)
+                     -------->
+     DNSKEY1         -------->        DNSKEY2         DNSKEY2
+                     -------->
+     DNSKEY10        -------->        DNSKEY10        DNSKEY10
+     RRSIG1 (DNSKEY) -------->        RRSIG2(DNSKEY)  RRSIG2 (DNSKEY)
+     RRSIG10(DNSKEY) -------->        RRSIG10(DNSKEY) RRSIG10(DNSKEY)
+
+   Stages of Deployment for a Pre-publish Key Signing Key rollover.
+
+   When the child zone wants to roll it notifies the parent during the
+   "new DS" phase and submits the new key (or the corresponding DS) to
+   the parent.  The parent publishes DS1 and DS2, pointing to DNSKEY1
+   and DNSKEY2 respectively.  During the rollover ("new DNSKEY" phase),
+   which can take place as soon as the new DS set propagated through the
+   DNS, the child replaces DNSKEY1 with DNSKEY2.  Immediately after that
+   ("DS/DNSKEY removal" phase) it can notify the parent that the old DS
+   record can be deleted.
+
+   The drawbacks of this scheme are that during the "new DS" phase the
+   parent cannot verify the match between the DS2 RR and DNSKEY2 using
+   the DNS -- as DNSKEY2 is not yet published.  Besides, we introduce a
+   "security lame" key (See Section 4.4.3).  Finally the child-parent
+   interaction consists of two steps.  The "double signature" method
+   only needs one interaction.
+
+4.2.4.  Automated Key Rollovers
+
+   As keys must be renewed periodically, there is some motivation to
+   automate the rollover process.  Consider that:
+
+   o  ZSK rollovers are easy to automate as only the child zone is
+      involved.
+   o  A KSK rollover needs interaction between parent and child.  Data
+      exchange is needed to provide the new keys to the parent,
+      consequently, this data must be authenticated and integrity must
+
+
+
+Kolkman & Gieben        Expires September 7, 2006              [Page 21]
+
+Internet-Draft        DNSSEC Operational Practices            March 2006
+
+
+      be guaranteed in order to avoid attacks on the rollover.
+
+4.3.  Planning for Emergency Key Rollover
+
+   This section deals with preparation for a possible key compromise.
+   Our advice is to have a documented procedure ready for when a key
+   compromise is suspected or confirmed.
+
+   When the private material of one of your keys is compromised it can
+   be used for as long as a valid trust chain exists.  A trust chain
+   remains intact for:
+   o  as long as a signature over the compromised key in the trust chain
+      is valid,
+   o  as long as a parental DS RR (and signature) points to the
+      compromised key,
+   o  as long as the key is anchored in a resolver and is used as a
+      starting point for validation (this is generally the hardest to
+      update).
+
+   While a trust chain to your compromised key exists, your name-space
+   is vulnerable to abuse by anyone who has obtained illegitimate
+   possession of the key.  Zone operators have to make a trade off if
+   the abuse of the compromised key is worse than having data in caches
+   that cannot be validated.  If the zone operator chooses to break the
+   trust chain to the compromised key, data in caches signed with this
+   key cannot be validated.  However, if the zone administrator chooses
+   to take the path of a regular roll-over, the malicious key holder can
+   spoof data so that it appears to be valid.
+
+4.3.1.  KSK Compromise
+
+   A zone containing a DNSKEY RRSet with a compromised KSK is vulnerable
+   as long as the compromised KSK is configured as trust anchor or a
+   parental DS points to it.
+
+   A compromised KSK can be used to sign the key set of an attacker's
+   zone.  That zone could be used to poison the DNS.
+
+   Therefore when the KSK has been compromised, the trust anchor or the
+   parental DS, should be replaced as soon as possible.  It is local
+   policy whether to break the trust chain during the emergency
+   rollover.  The trust chain would be broken when the compromised KSK
+   is removed from the child's zone while the parent still has a DS
+   pointing to the compromised KSK (the assumption is that there is only
+   one DS at the parent.  If there are multiple DSs this does not apply
+   -- however the chain of trust of this particular key is broken).
+
+   Note that an attacker's zone still uses the compromised KSK and the
+
+
+
+Kolkman & Gieben        Expires September 7, 2006              [Page 22]
+
+Internet-Draft        DNSSEC Operational Practices            March 2006
+
+
+   presence of a parental DS would cause the data in this zone to appear
+   as valid.  Removing the compromised key would cause the attacker's
+   zone to appear as valid and the child's zone as Bogus.  Therefore we
+   advise not to remove the KSK before the parent has a DS to a new KSK
+   in place.
+
+4.3.1.1.  Keeping the Chain of Trust Intact
+
+   If we follow this advice the timing of the replacement of the KSK is
+   somewhat critical.  The goal is to remove the compromised KSK as soon
+   as the new DS RR is available at the parent.  And also make sure that
+   the signature made with a new KSK over the key set with the
+   compromised KSK in it expires just after the new DS appears at the
+   parent.  Thus removing the old cruft in one swoop.
+
+   The procedure is as follows:
+   1.  Introduce a new KSK into the key set, keep the compromised KSK in
+       the key set.
+   2.  Sign the key set, with a short validity period.  The validity
+       period should expire shortly after the DS is expected to appear
+       in the parent and the old DSs have expired from caches.
+   3.  Upload the DS for this new key to the parent.
+   4.  Follow the procedure of the regular KSK rollover: Wait for the DS
+       to appear in the authoritative servers and then wait as long as
+       the TTL of the old DS RRs.  If necessary re-sign the DNSKEY RRSet
+       and modify/extend the expiration time.
+   5.  Remove the compromised DNSKEY RR from the zone and re-sign the
+       key set using your "normal" validity interval.
+
+   An additional danger of a key compromise is that the compromised key
+   could be used to facilitate a legitimate DNSKEY/DS rollover and/or
+   nameserver changes at the parent.  When that happens the domain may
+   be in dispute.  An authenticated out-of-band and secure notify
+   mechanism to contact a parent is needed in this case.
+
+   Note that this is only a problem when the DNSKEY and or DS records
+   are used for authentication at the parent.
+
+4.3.1.2.  Breaking the Chain of Trust
+
+   There are two methods to break the chain of trust.  The first method
+   causes the child zone to appear as 'Bogus' to validating resolvers.
+   The other causes the the child zone to appear as 'insecure'.  These
+   are described below.
+
+   In the method that causes the child zone to appear as 'Bogus' to
+   validating resolvers, the child zone replaces the current KSK with a
+   new one and resigns the key set.  Next it sends the DS of the new key
+
+
+
+Kolkman & Gieben        Expires September 7, 2006              [Page 23]
+
+Internet-Draft        DNSSEC Operational Practices            March 2006
+
+
+   to the parent.  Only after the parent has placed the new DS in the
+   zone, the child's chain of trust is repaired.
+
+   An alternative method of breaking the chain of trust is by removing
+   the DS RRs from the parent zone altogether.  As a result the child
+   zone would become insecure.
+
+4.3.2.  ZSK Compromise
+
+   Primarily because there is no parental interaction required when a
+   ZSK is compromised, the situation is less severe than with a KSK
+   compromise.  The zone must still be re-signed with a new ZSK as soon
+   as possible.  As this is a local operation and requires no
+   communication between the parent and child this can be achieved
+   fairly quickly.  However, one has to take into account that just as
+   with a normal rollover the immediate disappearance of the old
+   compromised key may lead to verification problems.  Also note that as
+   long as the RRSIG over the compromised ZSK is not expired the zone
+   may be still at risk.
+
+4.3.3.  Compromises of Keys Anchored in Resolvers
+
+   A key can also be pre-configured in resolvers.  For instance, if
+   DNSSEC is successfully deployed the root key may be pre-configured in
+   most security aware resolvers.
+
+   If trust-anchor keys are compromised, the resolvers using these keys
+   should be notified of this fact.  Zone administrators may consider
+   setting up a mailing list to communicate the fact that a SEP key is
+   about to be rolled over.  This communication will of course need to
+   be authenticated e.g. by using digital signatures.
+
+   End-users faced with the task of updating an anchored key should
+   always validate the new key.  New keys should be authenticated out-
+   of-band, for example, looking them up on an SSL secured announcement
+   website.
+
+4.4.  Parental Policies
+
+4.4.1.  Initial Key Exchanges and Parental Policies Considerations
+
+   The initial key exchange is always subject to the policies set by the
+   parent.  When designing a key exchange policy one should take into
+   account that the authentication and authorization mechanisms used
+   during a key exchange should be as strong as the authentication and
+   authorization mechanisms used for the exchange of delegation
+   information between parent and child.  I.e. there is no implicit need
+   in DNSSEC to make the authentication process stronger than it was in
+
+
+
+Kolkman & Gieben        Expires September 7, 2006              [Page 24]
+
+Internet-Draft        DNSSEC Operational Practices            March 2006
+
+
+   DNS.
+
+   Using the DNS itself as the source for the actual DNSKEY material,
+   with an out-of-band check on the validity of the DNSKEY, has the
+   benefit that it reduces the chances of user error.  A DNSKEY query
+   tool can make use of the SEP bit [3] to select the proper key from a
+   DNSSEC key set; thereby reducing the chance that the wrong DNSKEY is
+   sent.  It can validate the self-signature over a key; thereby
+   verifying the ownership of the private key material.  Fetching the
+   DNSKEY from the DNS ensures that the chain of trust remains intact
+   once the parent publishes the DS RR indicating the child is secure.
+
+   Note: the out-of-band verification is still needed when the key-
+   material is fetched via the DNS.  The parent can never be sure
+   whether the DNSKEY RRs have been spoofed or not.
+
+4.4.2.  Storing Keys or Hashes?
+
+   When designing a registry system one should consider which of the
+   DNSKEYs and/or the corresponding DSs to store.  Since a child zone
+   might wish to have a DS published using a message digest algorithm
+   not yet understood by the registry, the registry can't count on being
+   able to generate the DS record from a raw DNSKEY.  Thus, we recommend
+   that registry systems at least support storing DS records.
+
+   It may also be useful to store DNSKEYs, since having them may help
+   during troubleshooting and, as long as the child's chosen message
+   digest is supported, the overhead of generating DS records from them
+   is minimal.  Having an out-of-band mechanism, such as a registry
+   directory (e.g.  Whois), to find out which keys are used to generate
+   DS Resource Records for specific owners and/or zones may also help
+   with troubleshooting.
+
+   The storage considerations also relate to the design of the customer
+   interface and the method by which data is transferred between
+   registrant and registry; Will the child zone administrator be able to
+   upload DS RRs with unknown hash algorithms or does the interface only
+   allow DNSKEYs?  In the registry-registrar model one can use the
+   DNSSEC EPP protocol extension [16] which allows transfer of DS RRs
+   and optionally DNSKEY RRs.
+
+4.4.3.  Security Lameness
+
+   Security Lameness is defined as what happens when a parent has a DS
+   RR pointing to a non-existing DNSKEY RR.  When this happens the
+   child's zone may be marked as "Bogus" by verifying DNS clients.
+
+   As part of a comprehensive delegation check the parent could, at key
+
+
+
+Kolkman & Gieben        Expires September 7, 2006              [Page 25]
+
+Internet-Draft        DNSSEC Operational Practices            March 2006
+
+
+   exchange time, verify that the child's key is actually configured in
+   the DNS.  However if a parent does not understand the hashing
+   algorithm used by child the parental checks are limited to only
+   comparing the key id.
+
+   Child zones should be very careful removing DNSKEY material,
+   specifically SEP keys, for which a DS RR exists.
+
+   Once a zone is "security lame", a fix (e.g. removing a DS RR) will
+   take time to propagate through the DNS.
+
+4.4.4.  DS Signature Validity Period
+
+   Since the DS can be replayed as long as it has a valid signature, a
+   short signature validity period over the DS minimizes the time a
+   child is vulnerable in the case of a compromise of the child's
+   KSK(s).  A signature validity period that is too short introduces the
+   possibility that a zone is marked Bogus in case of a configuration
+   error in the signer.  There may not be enough time to fix the
+   problems before signatures expire.  Something as mundane as operator
+   unavailability during weekends shows the need for DS signature
+   validity periods longer than 2 days.  We recommend an absolute
+   minimum for a DS signature validity period of a few days.
+
+   The maximum signature validity period of the DS record depends on how
+   long child zones are willing to be vulnerable after a key compromise.
+   On the other hand shortening the DS signature validity interval
+   increases the operational risk for the parent.  Therefore the parent
+   may have policy to use a signature validity interval that is
+   considerably longer than the child would hope for.
+
+   A compromise between the operational constraints of the parent and
+   minimizing damage for the child may result in a DS signature validity
+   period somewhere between the order of a week to order of months.
+
+   In addition to the signature validity period, which sets a lower
+   bound on the number of times the zone owner will need to sign the
+   zone data and which sets an upper bound to the time a child is
+   vulnerable after key compromise, there is the TTL value on the DS
+   RRs.  Shortening the TTL means that the authoritative servers will
+   see more queries.  But on the other hand, a short TTL lowers the
+   persistence of DS RRSets in caches thereby increases the speed with
+   which updated DS RRSets propagate through the DNS.
+
+
+5.  IANA Considerations
+
+   This overview document introduces no new IANA considerations.
+
+
+
+Kolkman & Gieben        Expires September 7, 2006              [Page 26]
+
+Internet-Draft        DNSSEC Operational Practices            March 2006
+
+
+6.  Security Considerations
+
+   DNSSEC adds data integrity to the DNS.  This document tries to assess
+   the operational considerations to maintain a stable and secure DNSSEC
+   service.  Not taking into account the 'data propagation' properties
+   in the DNS will cause validation failures and may make secured zones
+   unavailable to security aware resolvers.
+
+
+7.  Acknowledgments
+
+   Most of the ideas in this draft were the result of collective efforts
+   during workshops, discussions and try outs.
+
+   At the risk of forgetting individuals who were the original
+   contributors of the ideas we would like to acknowledge people who
+   were actively involved in the compilation of this document.  In
+   random order: Rip Loomis, Olafur Gudmundsson, Wesley Griffin, Michael
+   Richardson, Scott Rose, Rick van Rein, Tim McGinnis, Gilles Guette
+   Olivier Courtay, Sam Weiler, Jelte Jansen, Niall O'Reilly, Holger
+   Zuleger, Ed Lewis, Hilarie Orman, Marcos Sanz and Peter Koch.
+
+   Some material in this document has been copied from RFC 2541 [12].
+
+   Mike StJohns designed the key exchange between parent and child
+   mentioned in the last paragraph of Section 4.2.2
+
+   Section 4.2.4 was supplied by G. Guette and O. Courtay.
+
+   Emma Bretherick, Adrian Bedford and Lindy Foster corrected many of
+   the spelling and style issues.
+
+   Kolkman and Gieben take the blame for introducing all miscakes(SIC).
+
+   Kolkman was employed by the RIPE NCC while working on this document.
+
+
+8.  References
+
+8.1.  Normative References
+
+   [1]  Mockapetris, P., "Domain names - concepts and facilities",
+        STD 13, RFC 1034, November 1987.
+
+   [2]  Mockapetris, P., "Domain names - implementation and
+        specification", STD 13, RFC 1035, November 1987.
+
+   [3]  Kolkman, O., Schlyter, J., and E. Lewis, "Domain Name System KEY
+
+
+
+Kolkman & Gieben        Expires September 7, 2006              [Page 27]
+
+Internet-Draft        DNSSEC Operational Practices            March 2006
+
+
+        (DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag",
+        RFC 3757, May 2004.
+
+   [4]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+        "DNS Security Introduction and Requirements", RFC 4033,
+        March 2005.
+
+   [5]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+        "Resource Records for the DNS Security Extensions", RFC 4034,
+        March 2005.
+
+   [6]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+        "Protocol Modifications for the DNS Security Extensions",
+        RFC 4035, March 2005.
+
+8.2.  Informative References
+
+   [7]   Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,
+         August 1996.
+
+   [8]   Vixie, P., "A Mechanism for Prompt Notification of Zone Changes
+         (DNS NOTIFY)", RFC 1996, August 1996.
+
+   [9]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
+         Levels", BCP 14, RFC 2119, March 1997.
+
+   [10]  Eastlake, D., "Secure Domain Name System Dynamic Update",
+         RFC 2137, April 1997.
+
+   [11]  Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)",
+         RFC 2308, March 1998.
+
+   [12]  Eastlake, D., "DNS Security Operational Considerations",
+         RFC 2541, March 1999.
+
+   [13]  Gudmundsson, O., "Delegation Signer (DS) Resource Record (RR)",
+         RFC 3658, December 2003.
+
+   [14]  Orman, H. and P. Hoffman, "Determining Strengths For Public
+         Keys Used For Exchanging Symmetric Keys", BCP 86, RFC 3766,
+         April 2004.
+
+   [15]  Eastlake, D., Schiller, J., and S. Crocker, "Randomness
+         Requirements for Security", BCP 106, RFC 4086, June 2005.
+
+   [16]  Hollenbeck, S., "Domain Name System (DNS) Security Extensions
+         Mapping for the Extensible Provisioning Protocol (EPP)",
+         RFC 4310, December 2005.
+
+
+
+Kolkman & Gieben        Expires September 7, 2006              [Page 28]
+
+Internet-Draft        DNSSEC Operational Practices            March 2006
+
+
+   [17]  Lenstra, A. and E. Verheul, "Selecting Cryptographic Key
+         Sizes", The Journal of Cryptology 14 (255-293), 2001.
+
+   [18]  Schneier, B., "Applied Cryptography: Protocols, Algorithms, and
+         Source Code in C", ISBN (hardcover) 0-471-12845-7, ISBN
+         (paperback) 0-471-59756-2, Published by John Wiley & Sons Inc.,
+         1996.
+
+   [19]  Rose, S., "NIST DNSSEC workshop notes", June 2001.
+
+   [20]  Jansen, J., "Use of RSA/SHA-256 DNSKEY and RRSIG Resource
+         Records in DNSSEC", draft-ietf-dnsext-dnssec-rsasha256-00.txt
+         (work in progress), January 2006.
+
+   [21]  Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer (DS)
+         Resource Records (RRs)", draft-ietf-dnsext-ds-sha256-04.txt
+         (work in progress), January 2006.
+
+
+Appendix A.  Terminology
+
+   In this document there is some jargon used that is defined in other
+   documents.  In most cases we have not copied the text from the
+   documents defining the terms but given a more elaborate explanation
+   of the meaning.  Note that these explanations should not be seen as
+   authoritative.
+
+   Anchored Key: A DNSKEY configured in resolvers around the globe.
+      This key is hard to update, hence the term anchored.
+   Bogus: Also see Section 5 of [4].  An RRSet in DNSSEC is marked
+      "Bogus" when a signature of a RRSet does not validate against a
+      DNSKEY.
+   Key Signing Key or KSK: A Key Signing Key (KSK) is a key that is used
+      exclusively for signing the apex key set.  The fact that a key is
+      a KSK is only relevant to the signing tool.
+   Key size: The term 'key size' can be substituted by 'modulus size'
+      throughout the document.  It is mathematically more correct to use
+      modulus size, but as this is a document directed at operators we
+      feel more at ease with the term key size.
+   Private and Public Keys: DNSSEC secures the DNS through the use of
+      public key cryptography.  Public key cryptography is based on the
+      existence of two (mathematically related) keys, a public key and a
+      private key.  The public keys are published in the DNS by use of
+      the DNSKEY Resource Record (DNSKEY RR).  Private keys should
+      remain private.
+
+
+
+
+
+
+Kolkman & Gieben        Expires September 7, 2006              [Page 29]
+
+Internet-Draft        DNSSEC Operational Practices            March 2006
+
+
+   Key Rollover: A key rollover (also called key supercession in some
+      environments) is the act of replacing one key pair by another at
+      the end of a key effectivity period.
+   Secure Entry Point key or SEP Key: A KSK that has a parental DS
+      record pointing to it or is configured as a trust anchor.
+      Although not required by the protocol we recommend that the SEP
+      flag [3] is set on these keys.
+   Self-signature: This is only applies to signatures over DNSKEYs; a
+      signature made with DNSKEY x, over DNSKEY x is called a self-
+      signature.  Note: without further information self-signatures
+      convey no trust, they are useful to check the authenticity of the
+      DNSKEY, i.e. they can be used as a hash.
+   Singing the Zone File: The term used for the event where an
+      administrator joyfully signs its zone file while producing melodic
+      sound patterns.
+   Signer: The system that has access to the private key material and
+      signs the Resource Record sets in a zone.  A signer may be
+      configured to sign only parts of the zone e.g. only those RRSets
+      for which existing signatures are about to expire.
+   Zone Signing Key or ZSK: A Zone Signing Key (ZSK) is a key that is
+      used for signing all data in a zone.  The fact that a key is a ZSK
+      is only relevant to the signing tool.
+   Zone Administrator: The 'role' that is responsible for signing a zone
+      and publishing it on the primary authoritative server.
+
+
+Appendix B.  Zone Signing Key Rollover Howto
+
+   Using the pre-published signature scheme and the most conservative
+   method to assure oneself that data does not live in caches, here
+   follows the "HOWTO".
+   Step 0: The preparation: Create two keys and publish both in your key
+      set.  Mark one of the keys as "active" and the other as
+      "published".  Use the "active" key for signing your zone data.
+      Store the private part of the "published" key, preferably off-
+      line.
+      The protocol does not provide for attributes to mark a key as
+      active or published.  This is something you have to do on your
+      own, through the use of a notebook or key management tool.
+   Step 1: Determine expiration: At the beginning of the rollover make a
+      note of the highest expiration time of signatures in your zone
+      file created with the current key marked as "active".
+      Wait until the expiration time marked in Step 1 has passed
+   Step 2: Then start using the key that was marked as "published" to
+      sign your data i.e. mark it as "active".  Stop using the key that
+      was marked as "active", mark it as "rolled".
+
+
+
+
+
+Kolkman & Gieben        Expires September 7, 2006              [Page 30]
+
+Internet-Draft        DNSSEC Operational Practices            March 2006
+
+
+   Step 3: It is safe to engage in a new rollover (Step 1) after at
+      least one "signature validity period".
+
+
+Appendix C.  Typographic Conventions
+
+   The following typographic conventions are used in this document:
+   Key notation: A key is denoted by DNSKEYx, where x is a number or an
+      identifier, x could be thought of as the key id.
+   RRSet notations: RRs are only denoted by the type.  All other
+      information - owner, class, rdata and TTL - is left out.  Thus:
+      "example.com 3600 IN A 192.0.2.1" is reduced to "A".  RRSets are a
+      list of RRs.  A example of this would be: "A1, A2", specifying the
+      RRSet containing two "A" records.  This could again be abbreviated
+      to just "A".
+   Signature notation: Signatures are denoted as RRSIGx(RRSet), which
+      means that RRSet is signed with DNSKEYx.
+   Zone representation: Using the above notation we have simplified the
+      representation of a signed zone by leaving out all unnecessary
+      details such as the names and by representing all data by "SOAx"
+   SOA representation: SOAs are represented as SOAx, where x is the
+      serial number.
+   Using this notation the following signed zone:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kolkman & Gieben        Expires September 7, 2006              [Page 31]
+
+Internet-Draft        DNSSEC Operational Practices            March 2006
+
+
+   example.net.      86400  IN SOA  ns.example.net. bert.example.net. (
+                            2006022100   ; serial
+                            86400        ; refresh (  24 hours)
+                            7200         ; retry   (   2 hours)
+                            3600000      ; expire  (1000 hours)
+                            28800 )      ; minimum (   8 hours)
+                     86400  RRSIG   SOA 5 2 86400 20130522213204 (
+                                  20130422213204 14 example.net.
+                                  cmL62SI6iAX46xGNQAdQ... )
+                     86400  NS      a.iana-servers.net.
+                     86400  NS      b.iana-servers.net.
+                     86400  RRSIG   NS 5 2 86400 20130507213204 (
+                                  20130407213204 14 example.net.
+                                  SO5epiJei19AjXoUpFnQ ... )
+                     86400  DNSKEY  256 3 5 (
+                                  EtRB9MP5/AvOuVO0I8XDxy0... ) ; id = 14
+                     86400  DNSKEY  257 3 5 (
+                                  gsPW/Yy19GzYIY+Gnr8HABU... ) ; id = 15
+                     86400  RRSIG   DNSKEY 5 2 86400 20130522213204 (
+                                  20130422213204 14 example.net.
+                                  J4zCe8QX4tXVGjV4e1r9... )
+                     86400  RRSIG   DNSKEY 5 2 86400 20130522213204 (
+                                  20130422213204 15 example.net.
+                                  keVDCOpsSeDReyV6O... )
+                     86400  RRSIG   NSEC 5 2 86400 20130507213204 (
+                                  20130407213204 14 example.net.
+                                  obj3HEp1GjnmhRjX... )
+   a.example.net.    86400  IN TXT  "A label"
+                     86400  RRSIG   TXT 5 3 86400 20130507213204 (
+                                  20130407213204 14 example.net.
+                                  IkDMlRdYLmXH7QJnuF3v... )
+                     86400  NSEC    b.example.com. TXT RRSIG NSEC
+                     86400  RRSIG   NSEC 5 3 86400 20130507213204 (
+                                  20130407213204 14 example.net.
+                                  bZMjoZ3bHjnEz0nIsPMM... )
+                     ...
+
+   is reduced to the following representation:
+
+       SOA2006022100
+       RRSIG14(SOA2006022100)
+       DNSKEY14
+       DNSKEY15
+
+       RRSIG14(KEY)
+       RRSIG15(KEY)
+
+   The rest of the zone data has the same signature as the SOA record,
+
+
+
+Kolkman & Gieben        Expires September 7, 2006              [Page 32]
+
+Internet-Draft        DNSSEC Operational Practices            March 2006
+
+
+   i.e a RRSIG created with DNSKEY 14.
+
+
+Appendix D.  Document Details and Changes
+
+   This section is to be removed by the RFC editor if and when the
+   document is published.
+
+   $Id: draft-ietf-dnsop-dnssec-operational-practices.xml,v 1.31.2.14
+   2005/03/21 15:51:41 dnssec Exp $
+
+D.1.  draft-ietf-dnsop-dnssec-operational-practices-00
+
+   Submission as working group document.  This document is a modified
+   and updated version of draft-kolkman-dnssec-operational-practices-00.
+
+D.2.  draft-ietf-dnsop-dnssec-operational-practices-01
+
+   changed the definition of "Bogus" to reflect the one in the protocol
+   draft.
+
+   Bad to Bogus
+
+   Style and spelling corrections
+
+   KSK - SEP mapping made explicit.
+
+   Updates from Sam Weiler added
+
+D.3.  draft-ietf-dnsop-dnssec-operational-practices-02
+
+   Style and errors corrected.
+
+   Added Automatic rollover requirements from I-D.ietf-dnsop-key-
+   rollover-requirements.
+
+D.4.  draft-ietf-dnsop-dnssec-operational-practices-03
+
+   Added the definition of Key effectivity period and used that term
+   instead of Key validity period.
+
+   Modified the order of the sections, based on a suggestion by Rip
+   Loomis.
+
+   Included parts from RFC 2541 [12].  Most of its ground was already
+   covered.  This document obsoletes RFC 2541 [12].  Section 3.1.2
+   deserves some review as it in contrast to RFC 2541 does _not_ give
+   recomendations about root-zone keys.
+
+
+
+Kolkman & Gieben        Expires September 7, 2006              [Page 33]
+
+Internet-Draft        DNSSEC Operational Practices            March 2006
+
+
+   added a paragraph to Section 4.4.4
+
+D.5.  draft-ietf-dnsop-dnssec-operational-practices-04
+
+   Somewhat more details added about the pre-publish KSK rollover.  Also
+   moved that subsection down a bit.
+
+   Editorial and content nits that came in during wg last call were
+   fixed.
+
+D.6.  draft-ietf-dnsop-dnssec-operational-practices-05
+
+   Applied some another set of comments that came in _after_ the the
+   WGLC.
+
+   Applied comments from Hilarie Orman and made a referece to RFC 3766.
+   Deleted of a lot of key length discussion and took over the
+   recommendations from RFC 3766.
+
+   Reworked all the heading of the rollover figures
+
+D.7.  draft-ietf-dnsop-dnssec-operational-practices-06
+
+   One comment from Scott Rose applied.
+
+   Marcos Sanz gave a lots of editorial nits.  Almost all are
+   incorporated.
+
+D.8.  draft-ietf-dnsop-dnssec-operational-practices-07
+
+   Peter Koch's comments applied.
+
+   SHA-1/SHA-256 remarks added
+
+D.9.  draft-ietf-dnsop-dnssec-operational-practices-08
+
+   IESG comments applied.  Added headers and some captions to the tables
+   and applied all the nits.
+
+   IESG DISCUSS comments applied
+
+
+
+
+
+
+
+
+
+
+
+Kolkman & Gieben        Expires September 7, 2006              [Page 34]
+
+Internet-Draft        DNSSEC Operational Practices            March 2006
+
+
+Authors' Addresses
+
+   Olaf M. Kolkman
+   NLnet Labs
+   Kruislaan 419
+   Amsterdam  1098 VA
+   The Netherlands
+
+   Email: olaf@nlnetlabs.nl
+   URI:   http://www.nlnetlabs.nl
+
+
+   Miek Gieben
+   NLnet Labs
+   Kruislaan 419
+   Amsterdam  1098 VA
+   The Netherlands
+
+   Email: miek@nlnetlabs.nl
+   URI:   http://www.nlnetlabs.nl
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kolkman & Gieben        Expires September 7, 2006              [Page 35]
+
+Internet-Draft        DNSSEC Operational Practices            March 2006
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2006).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Kolkman & Gieben        Expires September 7, 2006              [Page 36]
+
diff --git a/doc/draft/draft-ietf-dnsop-inaddr-required-07.txt b/doc/draft/draft-ietf-dnsop-inaddr-required-07.txt
new file mode 100644
index 0000000..bcd0d14
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsop-inaddr-required-07.txt
@@ -0,0 +1,396 @@
+
+
+
+
+
+
+INTERNET-DRAFT                                                  D. Senie
+Category: BCP                                     Amaranth Networks Inc.
+Expires in six months                                          July 2005
+
+               Encouraging the use of DNS IN-ADDR Mapping
+		    draft-ietf-dnsop-inaddr-required-07.txt 
+
+Status of this Memo
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   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 draft documents 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 "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/ietf/1id-abstracts.txt
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html
+
+Abstract
+
+   Mapping of addresses to names has been a feature of DNS.  Many sites,
+   implement it, many others don't.  Some applications attempt to use it
+   as a part of a security strategy. The goal of this document is to
+   encourage proper deployment of address to name mappings, and provide
+   guidance for their use.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society. (2005)
+
+1. Introduction
+
+   The Domain Name Service has provision for providing mapping of IP
+   addresses to host names. It is common practice to ensure both name to
+   address, and address to name mappings are provided for networks. This
+   practice, while documented, has never been required, though it is
+   generally encouraged.  This document both encourages the presence of
+
+
+
+Senie                                                           [Page 1]
+
+Internet-Draft Encouraging the use of DNS IN-ADDR Mapping      July 2005
+
+
+   these mappings and discourages reliance on such mappings for security
+   checks.
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [RFC2119].
+
+2. Discussion
+
+
+   From the early days of the Domain Name Service [RFC883] a special
+   domain has been set aside for resolving mappings of IP addresses to
+   domain names.  This was refined in [RFC1035], describing the .IN-
+   ADDR.ARPA in use today.  For the in the IPv6 address space, .IP6.ARPA
+   was added [RFC3152]. This document uses IPv4 CIDR block sizes and
+   allocation strategy where there are differences and uses IPv4
+   terminology.  Aside from these differences, this document can and
+   should be applied to both address spaces.
+
+   The assignment of blocks of IP address space was delegated to three
+   regional registries. Guidelines for the registries are specified in
+   [RFC2050], which requires regional registries to maintain IN-ADDR
+   records on the large blocks of space issued to ISPs and others.
+
+   ARIN's policy requires ISPs to maintain IN-ADDR for /16 or larger
+   allocations. For smaller allocations, ARIN can provide IN-ADDR for
+   /24 and shorter prefixes. [ARIN].  APNIC provides methods for ISPs to
+   update IN-ADDR, however the present version of its policy document
+   for IPv4 [APNIC] dropped the IN-ADDR requirements that were in draft
+   copies of this document. As of this writing, it appears APNIC has no
+   actual policy on IN-ADDR.  RIPE appears to have the strongest policy
+   in this area [RIPE302] indicating Local Internet Registries should
+   provide IN-ADDR services, and delegate those as appropriate when
+   address blocks are delegated.
+
+   As we can see, the regional registries have their own policies for
+   recommendations and/or requirements for IN-ADDR maintenance. It
+   should be noted, however, that many address blocks were allocated
+   before the creation of the regional registries, and thus it is
+   unclear whether any of the policies of the registries are binding on
+   those who hold blocks from that era.
+
+   Registries allocate address blocks on CIDR [RFC1519] boundaries.
+   Unfortunately the IN-ADDR zones are based on classful allocations.
+   Guidelines [RFC2317] for delegating on non-octet-aligned boundaries
+   exist, but are not always implemented.
+
+3. Examples of impact of missing IN-ADDR
+
+
+
+Senie                                                           [Page 2]
+
+Internet-Draft Encouraging the use of DNS IN-ADDR Mapping      July 2005
+
+
+   These are some examples of problems that may be introduced by
+   reliance on IN-ADDR.
+
+   Some applications use DNS lookups for security checks. To ensure
+   validity of claimed names, some applications will look up IN-ADDR
+   records to get names, and then look up the resultant name to see if
+   it maps back to the address originally known. Failure to resolve
+   matching names is seen as a potential security concern.
+
+   Some FTP sites will flat-out reject users, even for anonymous FTP, if
+   the IN-ADDR lookup fails or if the result of the IN-ADDR lookup when
+   itself resolved, does not match. Some Telnet servers also implement
+   this check.
+
+   Web sites are in some cases using IN-ADDR checks to verify whether
+   the client is located within a certain geopolitical entity. This
+   approach has been employed for downloads of crypto software, for
+   example, where export of that software is prohibited to some locales.
+   Credit card anti-fraud systems also use these methods for geographic
+   placement purposes.
+
+   The popular TCP Wrappers program found on most Unix and Linux systems
+   has options to enforce IN-ADDR checks and to reject any client that
+   does not resolve. This program also has a way to check to see that
+   the name given by a PTR record then resolves back to the same IP
+   address. This method provdes more comfort but no appreciable
+   additional security.
+
+   Some anti-spam (anti junk email) systems use IN-ADDR to verify the
+   presence of a PTR record, or validate the PTR value points back to
+   the same address.
+
+   Many web servers look up the IN-ADDR of visitors to be used in log
+   analysis.  This adds to the server load, but in the case of IN-ADDR
+   unavailability, it can lead to delayed responses for users.
+
+   Traceroutes with descriptive IN-ADDR naming proves useful when
+   debugging problems spanning large areas. When this information is
+   missing, the traceroutes take longer, and it takes additional steps
+   to determine that network is the cause of problems.
+
+   Wider-scale implementation of IN-ADDR on dialup, wireless access and
+   other such client-oriented portions of the Internet would result in
+   lower latency for queries (due to lack of negative caching), and
+   lower name server load and DNS traffic.
+
+4. Recommendations
+
+
+
+
+Senie                                                           [Page 3]
+
+Internet-Draft Encouraging the use of DNS IN-ADDR Mapping      July 2005
+
+
+   4.1 Delegation Recommendations
+
+
+   Regional Registries and any Local Registries to whom they delegate
+   should establish and convey a policy to those to whom they delegate
+   blocks that IN-ADDR mappings are recommended.  Policies should
+   recommend those receiving delegations to provide IN-ADDR service
+   and/or delegate to downstream customers.
+
+   Network operators should define and implement policies and procedures
+   which delegate IN-ADDR to their clients who wish to run their own IN-
+   ADDR DNS services, and provide IN-ADDR services for those who do not
+   have the resources to do it themselves.  Delegation mechanisms should
+   permit the downstream customer to implement and comply with IETF
+   recommendations application of IN-ADDR to CIDR [RFC2317].
+
+   All IP address space assigned and in use should be resolved by IN-
+   ADDR records. All PTR records must use canonical names.
+
+   All IP addresses in use within a block should have an IN-ADDR
+   mapping. Those addresses not in use, and those that are not valid for
+   use (zeros or ones broadcast addresses within a CIDR block) need not
+   have mappings.
+
+   It should be noted that due to CIDR, many addresses that appear to be
+   otherwise valid host addresses may actually be zeroes or ones
+   broadcast addresses. As such, attempting to audit a site's degree of
+   compliance may only be done with knowledge of the internal subnet
+   architecture of the site.  It can be assumed, however, any host that
+   originates an IP packet necessarily will have a valid host address,
+   and must therefore have an IN-ADDR mapping.
+
+4.2 Application Recommendations
+
+
+   Applications SHOULD NOT rely on IN-ADDR for proper operation. The use
+   of IN-ADDR, sometimes in conjunction with a lookup of the name
+   resulting from the PTR record provides no real security, can lead to
+   erroneous results and generally just increases load on DNS servers.
+   Further, in cases where address block holders fail to properly
+   configure IN-ADDR, users of those blocks are penalized.
+
+5. Security Considerations
+
+   This document has no negative impact on security. While it could be
+   argued that lack of PTR record capabilities provides a degree of
+   anonymity, this is really not valid. Trace routes, whois lookups and
+   other sources will still provide methods for discovering identity.
+
+
+
+Senie                                                           [Page 4]
+
+Internet-Draft Encouraging the use of DNS IN-ADDR Mapping      July 2005
+
+
+   By recommending applications avoid using IN-ADDR as a security
+   mechanism this document points out that this practice, despite its
+   use by many applications, is an ineffective form of security.
+   Applications should use better mechanisms of authentication.
+
+6. IANA Considerations
+
+   There are no IANA considerations for this document.
+
+7. References
+
+7.1 Normative References
+
+   [RFC883] P.V. Mockapetris, "Domain names: Implementation
+   specification," RFC883, November 1983.
+
+   [RFC1035] P.V. Mockapetris, "Domain Names: Implementation
+   Specification," RFC 1035, November 1987.
+
+   [RFC1519] V. Fuller, et. al., "Classless Inter-Domain Routing (CIDR):
+   an Address Assignment and Aggregation Strategy," RFC 1519, September
+   1993.
+
+   [RFC2026] S. Bradner, "The Internet Standards Process -- Revision 3",
+   RFC 2026, BCP 9, October 1996.
+
+   [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
+   Requirement Levels", RFC 2119, BCP 14, March 1997.
+
+   [RFC2050] K. Hubbard, et. al., "Internet Registry IP Allocation
+   Guidelines", RFC2050, BCP 12, Novebmer 1996.
+
+   [RFC2317] H. Eidnes, et. al., "Classless IN-ADDR.ARPA delegation,"
+   RFC 2317, March 1998.
+
+   [RFC3152] R. Bush, "Delegation of IP6.ARPA," RFC 3152, BCP 49, August
+   2001.
+
+7.2 Informative References
+
+   [ARIN] "ISP Guidelines for Requesting Initial IP Address Space," date
+   unknown, http://www.arin.net/regserv/initial-isp.html
+
+   [APNIC] "Policies For IPv4 Address Space Management in the Asia
+   Pacific Region," APNIC-086, 13 January 2003.
+
+   [RIPE302] "Policy for Reverse Address Delegation of IPv4 and IPv6
+   Address Space in the RIPE NCC Service Region", RIPE-302, April 26,
+
+
+
+Senie                                                           [Page 5]
+
+Internet-Draft Encouraging the use of DNS IN-ADDR Mapping      July 2005
+
+
+   2004. http://www.ripe.net//ripe/docs/rev-del.html
+
+
+
+8. Acknowledgements
+
+   Thanks to Peter Koch and Gary Miller for their input, and to many
+   people who encouraged me to write this document.
+
+9. Author's Address
+
+   Daniel Senie
+   Amaranth Networks Inc.
+   324 Still River Road
+   Bolton, MA 01740
+
+   Phone: (978) 779-5100
+
+   EMail: dts@senie.com
+
+10.  Full Copyright Statement
+
+      Copyright (C) The Internet Society (2005).
+
+      This document is subject to the rights, licenses and restrictions
+      contained in BCP 78, and except as set forth therein, the authors
+      retain all their rights.
+
+      This document and the information contained herein are provided
+      on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
+      REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
+      THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
+
+Intellectual Property
+
+      The IETF takes no position regarding the validity or scope of any
+      Intellectual Property Rights or other rights that might be claimed
+      to pertain to the implementation or use of the technology
+      described in this document or the extent to which any license
+      under such rights might or might not be available; nor does it
+      represent that it has made any independent effort to identify any
+      such rights.  Information on the procedures with respect to
+      rights in RFC documents can be found in BCP 78 and BCP 79.
+
+
+
+
+Senie                                                           [Page 6]
+
+Internet-Draft Encouraging the use of DNS IN-ADDR Mapping      July 2005
+
+
+      Copies of IPR disclosures made to the IETF Secretariat and any
+      assurances of licenses to be made available, or the result of an
+      attempt made to obtain a general license or permission for the use
+      of such proprietary rights by implementers or users of this
+      specification can be obtained from the IETF on-line IPR repository
+      at http://www.ietf.org/ipr.
+
+      The IETF invites any interested party to bring to its attention
+      any copyrights, patents or patent applications, or other
+      proprietary rights that may cover technology that may be required
+      to implement this standard.  Please address the information to the
+      IETF at ietf-ipr@ietf.org.
+
+      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 draft documents 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 "work in progress."
+
+      The list of current Internet-Drafts can be accessed at
+      http://www.ietf.org/1id-abstracts.html
+
+      The list of Internet-Draft Shadow Directories can be
+      accessed at http://www.ietf.org/shadow.html
+
+Acknowledgement
+
+      Funding for the RFC Editor function is currently provided by the
+      Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Senie                                                           [Page 7]
+
diff --git a/doc/draft/draft-ietf-dnsop-ipv6-dns-configuration-06.txt b/doc/draft/draft-ietf-dnsop-ipv6-dns-configuration-06.txt
new file mode 100644
index 0000000..bf2afcd
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsop-ipv6-dns-configuration-06.txt
@@ -0,0 +1,1848 @@
+
+
+
+DNS Operations WG                                          J. Jeong, Ed.
+Internet-Draft                              ETRI/University of Minnesota
+Expires: November 6, 2005                                    May 5, 2005
+
+
+      IPv6 Host Configuration of DNS Server Information Approaches
+             draft-ietf-dnsop-ipv6-dns-configuration-06.txt
+
+Status of this Memo
+
+   This document is an Internet-Draft and is subject to all provisions
+   of Section 3 of RFC 3667.  By submitting this Internet-Draft, each
+   author represents that any applicable patent or other IPR claims of
+   which he or she is aware have been or will be disclosed, and any of
+   which he or she become aware will be disclosed, in accordance with
+   RFC 3668.
+
+   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 draft documents 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 "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/ietf/1id-abstracts.txt.
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+   This Internet-Draft will expire on November 6, 2005.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).
+
+Abstract
+
+   This document describes three approaches for IPv6 recursive DNS
+   server address configuration.  It details the operational attributes
+   of three solutions: RA option, DHCPv6 option, and Well-known anycast
+   addresses for recursive DNS servers.  Additionally, it suggests the
+   deployment scenarios in four kinds of networks, such as ISP,
+   Enterprise, 3GPP, and Unmanaged networks, considering multi-solution
+   resolution.  Therefore, this document will give the audience a
+
+
+
+Jeong                   Expires November 6, 2005                [Page 1]
+
+Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
+
+
+   guideline for IPv6 host DNS configuration.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Jeong                   Expires November 6, 2005                [Page 2]
+
+Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
+   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  6
+   3.  IPv6 DNS Configuration Approaches  . . . . . . . . . . . . . .  7
+     3.1   RA Option  . . . . . . . . . . . . . . . . . . . . . . . .  7
+       3.1.1   Advantages . . . . . . . . . . . . . . . . . . . . . .  8
+       3.1.2   Disadvantages  . . . . . . . . . . . . . . . . . . . .  8
+       3.1.3   Observations . . . . . . . . . . . . . . . . . . . . .  9
+     3.2   DHCPv6 Option  . . . . . . . . . . . . . . . . . . . . . .  9
+       3.2.1   Advantages . . . . . . . . . . . . . . . . . . . . . . 11
+       3.2.2   Disadvantages  . . . . . . . . . . . . . . . . . . . . 12
+       3.2.3   Observations . . . . . . . . . . . . . . . . . . . . . 12
+     3.3   Well-known Anycast Addresses . . . . . . . . . . . . . . . 12
+       3.3.1   Advantages . . . . . . . . . . . . . . . . . . . . . . 13
+       3.3.2   Disadvantages  . . . . . . . . . . . . . . . . . . . . 14
+       3.3.3   Observations . . . . . . . . . . . . . . . . . . . . . 14
+   4.  Interworking among IPv6 DNS Configuration Approaches . . . . . 15
+   5.  Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 16
+     5.1   ISP Network  . . . . . . . . . . . . . . . . . . . . . . . 16
+       5.1.1   RA Option Approach . . . . . . . . . . . . . . . . . . 16
+       5.1.2   DHCPv6 Option Approach . . . . . . . . . . . . . . . . 17
+       5.1.3   Well-known Anycast Addresses Approach  . . . . . . . . 17
+     5.2   Enterprise Network . . . . . . . . . . . . . . . . . . . . 17
+     5.3   3GPP Network . . . . . . . . . . . . . . . . . . . . . . . 18
+       5.3.1   Currently Available Mechanisms and Recommendations . . 19
+       5.3.2   RA Extension . . . . . . . . . . . . . . . . . . . . . 19
+       5.3.3   Stateless DHCPv6 . . . . . . . . . . . . . . . . . . . 20
+       5.3.4   Well-known Addresses . . . . . . . . . . . . . . . . . 21
+       5.3.5   Recommendations  . . . . . . . . . . . . . . . . . . . 21
+     5.4   Unmanaged Network  . . . . . . . . . . . . . . . . . . . . 22
+       5.4.1   Case A: Gateway does not provide IPv6 at all . . . . . 22
+       5.4.2   Case B: A dual-stack gateway connected to a
+               dual-stack ISP . . . . . . . . . . . . . . . . . . . . 22
+       5.4.3   Case C: A dual-stack gateway connected to an
+               IPv4-only ISP  . . . . . . . . . . . . . . . . . . . . 22
+       5.4.4   Case D: A gateway connected to an IPv6-only ISP  . . . 23
+   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 24
+     6.1   RA Option  . . . . . . . . . . . . . . . . . . . . . . . . 25
+     6.2   DHCPv6 Option  . . . . . . . . . . . . . . . . . . . . . . 25
+     6.3   Well-known Anycast Addresses . . . . . . . . . . . . . . . 25
+   7.  Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 26
+   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28
+   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
+     9.1   Normative References . . . . . . . . . . . . . . . . . . . 29
+     9.2   Informative References . . . . . . . . . . . . . . . . . . 29
+       Author's Address . . . . . . . . . . . . . . . . . . . . . . . 31
+   A.  Link-layer Multicast Acknowledgements for RA Option  . . . . . 32
+
+
+
+Jeong                   Expires November 6, 2005                [Page 3]
+
+Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
+
+
+       Intellectual Property and Copyright Statements . . . . . . . . 33
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Jeong                   Expires November 6, 2005                [Page 4]
+
+Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
+
+
+1.  Introduction
+
+   Neighbor Discovery (ND) for IP Version 6 and IPv6 Stateless Address
+   Autoconfiguration provide the ways to configure either fixed or
+   mobile nodes with one or more IPv6 addresses, default routes and some
+   other parameters [3][4].  To support the access to additional
+   services in the Internet that are identified by a DNS name, such as a
+   web server, the configuration of at least one recursive DNS server is
+   also needed for DNS name resolution.
+
+   This document describes three approaches of recursive DNS server
+   address configuration for IPv6 host: (a) RA option [8], (b) DHCPv6
+   option [5]-[7], and (c) Well-known anycast addresses for recursive
+   DNS servers [9].  Also, it suggests the applicable scenarios for four
+   kinds of networks: (a) ISP network, (b) Enterprise network, (c) 3GPP
+   network, and (d) Unmanaged network.
+
+   This document is just an analysis of each possible approach, and does
+   not make any recommendation on a particular one or on a combination
+   of particular ones.  Some approaches may even not be adopted at all
+   as a result of further discussion.
+
+   Therefore, the objective of this document is to help the audience
+   select the approaches suitable for IPv6 host configuration of
+   recursive DNS servers.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Jeong                   Expires November 6, 2005                [Page 5]
+
+Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
+
+
+2.  Terminology
+
+   This document uses the terminology described in [3]-[9].  In
+   addition, a new term is defined below:
+
+   o  Recursive DNS Server (RDNSS): A Recursive DNS Server is a name
+      server that offers the recursive service of DNS name resolution.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Jeong                   Expires November 6, 2005                [Page 6]
+
+Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
+
+
+3.  IPv6 DNS Configuration Approaches
+
+   In this section, the operational attributes of the three solutions
+   are described in detail.
+
+3.1  RA Option
+
+   The RA approach is to define a new ND option called the RDNSS option
+   that contains a recursive DNS server address.  Existing ND transport
+   mechanisms (i.e., advertisements and solicitations) are used.  This
+   works in the same way that nodes learn about routers and prefixes.
+   An IPv6 host can configure the IPv6 addresses of one or more RDNSSes
+   via RA message periodically sent by a router or solicited by a Router
+   Solicitation (RS) [8].
+
+   This approach needs RDNSS information to be configured in the routers
+   doing the advertisements.  The configuration of RDNSS addresses can
+   be performed manually by an operator or other ways, such as automatic
+   configuration through a DHCPv6 client running on the router.  When
+   advertising more than one RDNSS option, an RA message includes as
+   many RDNSS options as RDNSSes.
+
+   Through the ND protocol and RDNSS option along with a prefix
+   information option, an IPv6 host can perform its network
+   configuration of its IPv6 address and RDNSS simultaneously [3][4].
+   The RA option for RDNSS can be used on any network that supports the
+   use of ND.
+
+   However, it is worth noting that some link layers, such as Wireless
+   LANs (e.g., IEEE 802.11 a/b/g), do not support reliable multicast,
+   which means that they cannot guarantee the timely delivery of RA
+   messages [25]-[28].  This is discussed in Appendix A.
+
+   The RA approach is useful in some mobile environments where the
+   addresses of the RDNSSes are changing because the RA option includes
+   a lifetime field that allows client to use RDNSSes nearer to the
+   client.  This can be configured to a value that will require the
+   client to time out the entry and switch over to another RDNSS address
+   [8].  However, from the viewpoint of implementation, the lifetime
+   field would seem to make matters a bit more complex.  Instead of just
+   writing to a DNS configuration file, such as resolv.conf for the list
+   of RDNSS addresses, we have to have a daemon around (or a program
+   that is called at the defined intervals) that keeps monitoring the
+   lifetime of RDNSSes all the time.
+
+   The preference value of RDNSS, included in the RDNSS option, allows
+   IPv6 hosts to select primary RDNSS among several RDNSSes; this can be
+   used for the load balancing of RDNSSes [8].
+
+
+
+Jeong                   Expires November 6, 2005                [Page 7]
+
+Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
+
+
+3.1.1  Advantages
+
+   The RA option for RDNSS has a number of advantages.  These include:
+
+   1.  The RA option is an extension of existing ND/Autoconfig
+       mechanisms [3][4], and does not require a change in the base ND
+       protocol.
+
+   2.  This approach, like ND, works well on a variety of link types
+       including point-to-point links, point-to-multipoint, and
+       multipoint-to-multipoint (i.e., Ethernet LANs), etc.  RFC 2461
+       [3] states, however, that there may be some link types on which
+       ND is not feasible; on such links, some other mechanisms will be
+       needed for DNS configuration.
+
+   3.  All of the information a host needs to run the basic Internet
+       applications such as the email, web, ftp, etc., can be obtained
+       with the addition of this option to ND and address
+       autoconfiguration.  The use of a single mechanism is more
+       reliable and easier to provide than when the RDNSS information is
+       learned via another protocol mechanism.  Debugging problems when
+       multiple protocol mechanisms are being used is harder and much
+       more complex.
+
+   4.  This mechanism works over a broad range of scenarios and
+       leverages IPv6 ND.  This works well on links that support
+       broadcast reliably (e.g., Ethernet LANs) but not necessarily on
+       other links (e.g., Wireless LANs): Refer to Appendix A.  Also,
+       this works well on links that are high performance (e.g.,
+       Ethernet LANs) and low performance (e.g., Cellular networks).  In
+       the latter case, by combining the RDNSS information with the
+       other information in the RA, the host can learn all of the
+       information needed to use most Internet applications, such as the
+       web in a single packet.  This not only saves bandwidth where this
+       is an issue, but also minimizes the delay needed to learn the
+       RDNSS information.
+
+   5.  The RA approach could be used as a model for other similar types
+       of configuration information.  New RA options for other server
+       addresses, such as NTP server address, that are common to all
+       clients on a subnet would be easy to define.
+
+
+3.1.2  Disadvantages
+
+   1.  ND is mostly implemented in the kernel of operating system.
+       Therefore, if ND supports the configuration of some additional
+       services, such as DNS servers, ND should be extended in the
+
+
+
+Jeong                   Expires November 6, 2005                [Page 8]
+
+Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
+
+
+       kernel, and complemented by a user-land process.  DHCPv6,
+       however, has more flexibility for the extension of service
+       discovery because it is an application layer protocol.
+
+   2.  The current ND framework should be modified to facilitate the
+       synchronization between another ND cache for RDNSSes in the
+       kernel space and the DNS configuration file in the user space.
+       Because it is unacceptable to write and rewrite to the DNS
+       configuration file (e.g., resolv.conf) from the kernel, another
+       approach is needed.  One simple approach to solve this is to have
+       a daemon listening to what the kernel conveys, and to have the
+       daemon do these steps, but such a daemon is not needed with the
+       current ND framework.
+
+   3.  It is necessary to configure RDNSS addresses at least at one
+       router on every link where this information needs to be
+       configured via the RA option.
+
+
+3.1.3  Observations
+
+   The proposed RDNSS RA option along with the IPv6 ND and
+   Autoconfiguration allows a host to obtain all of the information it
+   needs to access the basic Internet services like the web, email, ftp,
+   etc.  This is preferable in the environments where hosts use RAs to
+   autoconfigure their addresses and all the hosts on the subnet share
+   the same router and server addresses.  If the configuration
+   information can be obtained from a single mechanism, it is preferable
+   because it does not add additional delay, and it uses a minimum of
+   bandwidth.  The environments like this include the homes, public
+   cellular networks, and enterprise environments where no per host
+   configuration is needed, but exclude public WLAN hot spots.
+
+   DHCPv6 is preferable where it is being used for address configuration
+   and if there is a need for host specific configuration [5]-[7].  The
+   environments like this are most likely to be the enterprise
+   environments where the local administration chooses to have per host
+   configuration control.
+
+Note
+
+   The observation section is based on what the proponents of each
+   approach think makes a good overall solution.
+
+3.2  DHCPv6 Option
+
+   DHCPv6 [5] includes the "DNS Recursive Name Server" option, through
+   which a host can obtain a list of IP addresses of recursive DNS
+
+
+
+Jeong                   Expires November 6, 2005                [Page 9]
+
+Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
+
+
+   servers [7].  The DNS Recursive Name Server option carries a list of
+   IPv6 addresses of RDNSSes to which the host may send DNS queries.
+   The DNS servers are listed in the order of preference for use by the
+   DNS resolver on the host.
+
+   The DNS Recursive Name Server option can be carried in any DHCPv6
+   Reply message, in response to either a Request or an Information
+   request message.  Thus, the DNS Recursive Name Server option can be
+   used either when DHCPv6 is used for address assignment, or when
+   DHCPv6 is used only for other configuration information as stateless
+   DHCPv6 [6].
+
+   Stateless DHCPv6 can be deployed either using DHCPv6 servers running
+   on general-purpose computers, or on router hardware.  Several router
+   vendors currently implement stateless DHCPv6 servers.  Deploying
+   stateless DHCPv6 in routers has the advantage that no special
+   hardware is required, and should work well for networks where DHCPv6
+   is needed for very straightforward configuration of network devices.
+
+   However, routers can also act as DHCPv6 relay agents.  In this case,
+   the DHCPv6 server need not be on the router - it can be on a general
+   purpose computer.  This has the potential to give the operator of the
+   DHCPv6 server more flexibility in how the DHCPv6 server responds to
+   individual clients - clients can easily be given different
+   configuration information based on their identity, or for any other
+   reason.  Nothing precludes adding this flexibility to a router, but
+   generally in current practice, DHCP servers running on general-
+   purpose hosts tend to have more configuration options than those that
+   are embedded in routers.
+
+   DHCPv6 currently provides a mechanism for reconfiguring DHCPv6
+   clients that use a stateful configuration assignment.  To do this,
+   the DHCPv6 server sends a Reconfigure message to the client.  The
+   client validates the Reconfigure message, and then contacts the
+   DHCPv6 server to obtain updated configuration information.  Using
+   this mechanism, it is currently possible to propagate new
+   configuration information to DHCPv6 clients as this information
+   changes.
+
+   The DHC Working Group is currently studying an additional mechanism
+   through which configuration information, including the list of
+   RDNSSes, can be updated.  The lifetime option for DHCPv6 [10] assigns
+   a lifetime to configuration information obtained through DHCPv6.  At
+   the expiration of the lifetime, the host contacts the DHCPv6 server
+   to obtain updated configuration information, including the list of
+   RDNSSes.  This lifetime gives the network administrator another
+   mechanism to configure hosts with new RDNSSes by controlling the time
+   at which the host refreshes the list.
+
+
+
+Jeong                   Expires November 6, 2005               [Page 10]
+
+Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
+
+
+   The DHC Working Group has also discussed the possibility of defining
+   an extension to DHCPv6 that would allow the use of multicast to
+   provide configuration information to multiple hosts with a single
+   DHCPv6 message.  Because of the lack of deployment experience, the WG
+   has deferred consideration of multicast DHCPv6 configuration at this
+   time.  Experience with DHCPv4 has not identified a requirement for
+   multicast message delivery, even in large service provider networks
+   with tens of thousands of hosts that may initiate a DHCPv4 message
+   exchange simultaneously.
+
+3.2.1  Advantages
+
+   The DHCPv6 option for RDNSS has a number of advantages.  These
+   include:
+
+   1.  DHCPv6 currently provides a general mechanism for conveying
+       network configuration information to clients.  So configuring
+       DHCPv6 servers allows the network administrator to configure
+       RDNSSes along with the addresses of other network services, as
+       well as location-specific information like time zones.
+
+   2.  As a consequence, when the network administrator goes to
+       configure DHCPv6, all the configuration information can be
+       managed through a single service, typically with a single user
+       interface and a single configuration database.
+
+   3.  DHCPv6 allows for the configuration of a host with information
+       specific to that host, so that hosts on the same link can be
+       configured with different RDNSSes as well as with other
+       configuration information.  This capability is important in some
+       network deployments such as service provider networks or WiFi hot
+       spots.
+
+   4.  A mechanism exists for extending DHCPv6 to support the
+       transmission of additional configuration that has not yet been
+       anticipated.
+
+   5.  Hosts that require other configuration information such as the
+       addresses of SIP servers and NTP servers are likely to need
+       DHCPv6 for other configuration information.
+
+   6.  The specification for configuration of RDNSSes through DHCPv6 is
+       available as an RFC.  No new protocol extensions such as new
+       options are necessary.
+
+   7.  Interoperability among independent implementations has been
+       demonstrated.
+
+
+
+
+Jeong                   Expires November 6, 2005               [Page 11]
+
+Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
+
+
+3.2.2  Disadvantages
+
+   The DHCPv6 option for RDNSS has a few disadvantages.  These include:
+
+   1.  Update currently requires message from server (however, see
+       [10]).
+
+   2.  Because DNS information is not contained in RA messages, the host
+       must receive two messages from the router, and must transmit at
+       least one message to the router.  On networks where bandwidth is
+       at a premium, this is a disadvantage, although on most networks
+       it is not a practical concern.
+
+   3.  Increased latency for initial configuration - in addition to
+       waiting for an RA message, the client must now exchange packets
+       with a DHCPv6 server; even if it is locally installed on a
+       router, this will slightly extend the time required to configure
+       the client.  For clients that are moving rapidly from one network
+       to another, this will be a disadvantage.
+
+
+3.2.3  Observations
+
+   In the general case, on general-purpose networks, stateless DHCPv6
+   provides significant advantages and no significant disadvantages.
+   Even in the case where bandwidth is at a premium and low latency is
+   desired, if hosts require other configuration information in addition
+   to a list of RDNSSes or if hosts must be configured selectively,
+   those hosts will use DHCPv6 and the use of the DHCPv6 DNS recursive
+   name server option will be advantageous.
+
+   However, we are aware of some applications where it would be
+   preferable to put the RDNSS information into an RA packet; for
+   example, on a cell phone network, where bandwidth is at a premium and
+   extremely low latency is desired.  The final DNS configuration draft
+   should be written so as to allow these special applications to be
+   handled using DNS information in the RA packet.
+
+3.3  Well-known Anycast Addresses
+
+   Anycast uses the same routing system as unicast [11].  However,
+   administrative entities are local ones.  The local entities may
+   accept unicast routes (including default routes) to anycast servers
+   from adjacent entities.  The administrative entities should not
+   advertise their peers routes to their internal anycast servers, if
+   they want to prohibit external access from some peers to the servers.
+   If some advertisement is inevitable (such as the case with default
+   routes), the packets to the servers should be blocked at the boundary
+
+
+
+Jeong                   Expires November 6, 2005               [Page 12]
+
+Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
+
+
+   of the entities.  Thus, for this anycast, not only unicast routing
+   but also unicast ND protocols can be used as is.
+
+   First of all, the well-known anycast addresses approach is much
+   different from that discussed at IPv6 Working Group in the past [9].
+   It should be noted that "anycast" in this memo is simpler than that
+   of RFC 1546 [11] and RFC 3513 [12] where it is assumed to be
+   prohibited to have multiple servers on a single link sharing an
+   anycast address.  That is, on a link, an anycast address is assumed
+   to be unique.  DNS clients today already have redundancy by having
+   multiple well-known anycast addresses configured as RDNSS addresses.
+   There is no point in having multiple RDNSSes sharing an anycast
+   address on a single link.
+
+   The approach with well-known anycast addresses is to set multiple
+   well-known anycast addresses in clients' resolver configuration files
+   from the beginning, say, as factory default.  Thus, there is no
+   transport mechanism and no packet format [9].
+
+   An anycast address is an address shared by multiple servers (in this
+   case, the servers are RDNSSes).  A request from a client to the
+   anycast address is routed to a server selected by the routing system.
+   However, it is a bad idea to mandate "site" boundary on anycast
+   addresses, because most users just do not have their own servers and
+   want to access their ISPs' across their site boundaries.  Larger
+   sites may also depend on their ISPs or may have their own RDNSSes
+   within "site" boundaries.
+
+3.3.1  Advantages
+
+   The basic advantage of the well-known addresses approach is that it
+   uses no transport mechanism.  Thus,
+
+   1.  There is no delay to get the response and no further delay by
+       packet losses.
+
+   2.  The approach can be combined with any other configuration
+       mechanisms, such as the RA-based approach and DHCP based
+       approach, as well as the factory default configuration.
+
+   3.  The approach works over any environment where DNS works.
+
+   Another advantage is that the approach needs to configure DNS servers
+   as a router, but nothing else.  Considering that DNS servers do need
+   configuration, the amount of overall configuration effort is
+   proportional to the number of the DNS servers and scales linearly.
+   It should be noted that, in the simplest case where a subscriber to
+   an ISP does not have any DNS server, the subscriber naturally
+
+
+
+Jeong                   Expires November 6, 2005               [Page 13]
+
+Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
+
+
+   accesses DNS servers of the ISP even though the subscriber and the
+   ISP do nothing and there is no protocol to exchange DNS server
+   information between the subscriber and the ISP.
+
+3.3.2  Disadvantages
+
+   Well-known anycast addresses approach requires that DNS servers (or
+   routers near it as a proxy) act as routers to advertise their anycast
+   addresses to the routing system, which requires some configuration
+   (see the last paragraph of the previous section on the scalability of
+   the effort).
+
+3.3.3  Observations
+
+   If other approaches are used in addition, the well-known anycast
+   addresses should also be set in RA or DHCP configuration files to
+   reduce the configuration effort of users.
+
+   The redundancy by multiple RDNSSes is better provided by multiple
+   servers having different anycast addresses than multiple servers
+   sharing the same anycast address because the former approach allows
+   stale servers to still generate routes to their anycast addresses.
+   Thus, in a routing domain (or domains sharing DNS servers), there
+   will be only one server having an anycast address unless the domain
+   is so large that load distribution is necessary.
+
+   Small ISPs will operate one RDNSS at each anycast address which is
+   shared by all the subscribers.  Large ISPs may operate multiple
+   RDNSSes at each anycast address to distribute and reduce load, where
+   the boundary between RDNSSes may be fixed (redundancy is still
+   provided by multiple addresses) or change dynamically.  DNS packets
+   with the well-known anycast addresses are not expected (though not
+   prohibited) to cross ISP boundaries, as ISPs are expected to be able
+   to take care of themselves.
+
+   Because "anycast" in this memo is simpler than that of RFC 1546 [11]
+   and RFC 3513 [12] where it is assumed to be administratively
+   prohibited to have multiple servers on a single link sharing an
+   anycast address, anycast in this memo should be implemented as
+   UNICAST of RFC 2461 [3] and RFC 3513 [12].  As a result, ND-related
+   instability disappears.  Thus, anycast in well-known anycast
+   addresses approach can and should use the anycast address as a source
+   unicast (according to RFC 3513 [12]) address of packets of UDP and
+   TCP responses.  With TCP, if a route flips and packets to an anycast
+   address are routed to a new server, it is expected that the flip is
+   detected by ICMP or sequence number inconsistency and the TCP
+   connection is reset and retried.
+
+
+
+
+Jeong                   Expires November 6, 2005               [Page 14]
+
+Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
+
+
+4.  Interworking among IPv6 DNS Configuration Approaches
+
+   Three approaches can work together for IPv6 host configuration of
+   RDNSS.  This section shows a consideration on how these approaches
+   can interwork each other.
+
+   For ordering between RA and DHCP approaches, the O (Other stateful
+   configuration) flag in RA message can be used [8][32].  If no RDNSS
+   option is included, an IPv6 host may perform DNS configuration
+   through DHCPv6 [5]-[7] regardless of whether the O flag is set or
+   not.
+
+   The well-known anycast addresses approach fully interworks with the
+   other approaches.  That is, the other approaches can remove the
+   configuration effort on servers by using the well-known addresses as
+   the default configuration.  Moreover, the clients preconfigured with
+   the well-known anycast addresses can be further configured to use
+   other approaches to override the well-known addresses, if the
+   configuration information from other approaches is available.
+   Otherwise, all the clients need to have the well-known anycast
+   addresses preconfigured.  In order to use the anycast approach along
+   with two other approaches, there are three choices as follows:
+
+   1.  The first choice is that well-known addresses are used as last
+       resort, when an IPv6 host cannot get RDNSS information through RA
+       and DHCP.  The well-known anycast addresses have to be
+       preconfigured in all of IPv6 hosts' resolver configuration files.
+
+   2.  The second is that an IPv6 host can configure well-known
+       addresses as the most preferable in its configuration file even
+       though either an RA option or DHCP option is available.
+
+   3.  The last is that the well-known anycast addresses can be set in
+       RA or DHCP configuration to reduce the configuration effort of
+       users.  According to either the RA or DHCP mechanism, the well-
+       known addresses can be obtained by an IPv6 host.  Because this
+       approach is the most convenient for users, the last option is
+       recommended.
+
+
+Note
+
+   This section does not necessarily mean this document suggests
+   adopting all these three approaches and making them interwork in the
+   way described here.  In fact, some approaches may even not be adopted
+   at all as a result of further discussion.
+
+
+
+
+
+Jeong                   Expires November 6, 2005               [Page 15]
+
+Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
+
+
+5.  Deployment Scenarios
+
+   Regarding the DNS configuration on the IPv6 host, several mechanisms
+   are being considered at the DNSOP Working Group such as RA option,
+   DHCPv6 option and well-known preconfigured anycast addresses as of
+   today, and this document is a final result from the long thread.  In
+   this section, we suggest four applicable scenarios of three
+   approaches for IPv6 DNS configuration.
+
+Note
+
+   In the applicable scenarios, authors do not implicitly push any
+   specific approaches into the restricted environments.  No enforcement
+   is in each scenario and all mentioned scenarios are probable.  The
+   main objective of this work is to provide a useful guideline for IPv6
+   DNS configuration.
+
+5.1  ISP Network
+
+   A characteristic of ISP network is that multiple Customer Premises
+   Equipment (CPE) devices are connected to IPv6 PE (Provider Edge)
+   routers and each PE connects multiple CPE devices to the backbone
+   network infrastructure [13].  The CPEs may be hosts or routers.
+
+   In the case where the CPE is a router, there is a customer network
+   that is connected to the ISP backbone through the CPE.  Typically,
+   each customer network gets a different IPv6 prefix from an IPv6 PE
+   router, but the same RDNSS configuration will be distributed.
+
+   This section discusses how the different approaches to distributing
+   DNS information are compared in an ISP network.
+
+5.1.1  RA Option Approach
+
+   When the CPE is a host, the RA option for RDNSS can be used to allow
+   the CPE to get RDNSS information as well as /64 prefix information
+   for stateless address autoconfiguration at the same time when the
+   host is attached to a new subnet [8].  Because an IPv6 host must
+   receive at least one RA message for stateless address
+   autoconfiguration and router configuration, the host could receive
+   RDNSS configuration information in that RA without the overhead of an
+   additional message exchange.
+
+   When the CPE is a router, the CPE may accept the RDNSS information
+   from the RA on the interface connected to the ISP, and copy that
+   information into the RAs advertised in the customer network.
+
+   This approach is more valuable in the mobile host scenario, in which
+
+
+
+Jeong                   Expires November 6, 2005               [Page 16]
+
+Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
+
+
+   the host must receive at least an RA message for detecting a new
+   network, than in other scenarios generally although administrator
+   should configure RDNSS information on the routers.  Secure ND [14]
+   can provide extended security when using RA messages.
+
+5.1.2  DHCPv6 Option Approach
+
+   DHCPv6 can be used for RDNSS configuration through the use of the DNS
+   option, and can provide other configuration information in the same
+   message with RDNSS configuration [5]-[7].  The DHCPv6 DNS option is
+   already in place for DHCPv6 as RFC 3646 [7] and DHCPv6-lite or
+   stateless DHCP [6] is nowhere as complex as a full DHCPv6
+   implementation.  DHCP is a client-server model protocol, so ISPs can
+   handle user identification on its network intentionally, and also
+   authenticated DHCP [15] can be used for secure message exchange.
+
+   The expected model for deployment of IPv6 service by ISPs is to
+   assign a prefix to each customer, which will be used by the customer
+   gateway to assign a /64 prefix to each network in the customer's
+   network.  Prefix delegation with DHCP (DHCPv6 PD) has already been
+   adopted by ISPs for automating the assignment of the customer prefix
+   to the customer gateway [17].  DNS configuration can be carried in
+   the same DHCPv6 message exchange used for DHCPv6 to efficiently
+   provide that information, along with any other configuration
+   information needed by the customer gateway or customer network.  This
+   service model can be useful to Home or SOHO subscribers.  The Home or
+   SOHO gateway, which is a customer gateway for ISP, can then pass that
+   RDNSS configuration information to the hosts in the customer network
+   through DHCP.
+
+5.1.3  Well-known Anycast Addresses Approach
+
+   The well-known anycast addresses approach is also a feasible and
+   simple mechanism for ISP [9].  The use of well-known anycast
+   addresses avoids some of the security risks in rogue messages sent
+   through an external protocol like RA or DHCPv6.  The configuration of
+   hosts for the use of well-known anycast addresses requires no
+   protocol or manual configuration, but the configuration of routing
+   for the anycast addresses requires intervention on the part of the
+   network administrator.  Also, the number of special addresses would
+   be equal to the number of RDNSSes that could be made available to
+   subscribers.
+
+5.2  Enterprise Network
+
+   Enterprise network is defined as a network that has multiple internal
+   links, one or more router connections, to one or more Providers and
+   is actively managed by a network operations entity [16].  An
+
+
+
+Jeong                   Expires November 6, 2005               [Page 17]
+
+Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
+
+
+   enterprise network can get network prefixes from an ISP by either
+   manual configuration or prefix delegation [17].  In most cases,
+   because an enterprise network manages its own DNS domains, it
+   operates its own DNS servers for the domains.  These DNS servers
+   within enterprise network process recursive DNS name resolution
+   requests from IPv6 hosts as RDNSSes.  The RDNSS configuration in the
+   enterprise network can be performed like in Section 4, in which three
+   approaches can be used together as follows:
+
+   1.  An IPv6 host can decide which approach is or may be used in its
+       subnet with the O flag in RA message [8][32].  As the first
+       choice in Section 4, well-known anycast addresses can be used as
+       a last resort when RDNSS information cannot be obtained through
+       either an RA option or DHCP option.  This case needs IPv6 hosts
+       to preconfigure the well-known anycast addresses in their DNS
+       configuration files.
+
+   2.  When the enterprise prefers the well-known anycast approach to
+       others, IPv6 hosts should preconfigure the well-known anycast
+       addresses like in the first choice.
+
+   3.  The last choice, a more convenient and transparent way, does not
+       need IPv6 hosts to preconfigure the well-known anycast addresses
+       because the addresses are delivered to IPv6 hosts via either the
+       RA option or DHCPv6 option as if they were unicast addresses.
+       This way is most recommended for the sake of user's convenience.
+
+
+5.3  3GPP Network
+
+   The IPv6 DNS configuration is a missing part of IPv6
+   autoconfiguration and an important part of the basic IPv6
+   functionality in the 3GPP User Equipment (UE).  The higher level
+   description of the 3GPP architecture can be found in [18], and
+   transition to IPv6 in 3GPP networks is analyzed in [19] and [20].
+
+   In the 3GPP architecture, there is a dedicated link between the UE
+   and the GGSN called the Packet Data Protocol (PDP) Context.  This
+   link is created through the PDP Context activation procedure [21].
+   There is a separate PDP context type for IPv4 and IPv6 traffic.  If a
+   3GPP UE user is communicating using IPv6 (having an active IPv6 PDP
+   context), it cannot be assumed that (s)he has simultaneously an
+   active IPv4 PDP context, and DNS queries could be done using IPv4.  A
+   3GPP UE can thus be an IPv6 node, and it needs to somehow discover
+   the address of the RDNSS.  Before IP-based services (e.g., web
+   browsing or e-mail) can be used, the IPv6 (and IPv4) RDNSS addresses
+   need to be discovered in the 3GPP UE.
+
+
+
+
+Jeong                   Expires November 6, 2005               [Page 18]
+
+Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
+
+
+   Section 5.3.1 briefly summarizes currently available mechanisms in
+   3GPP networks and recommendations. 5.3.2 analyzes the Router
+   Advertisement based solution, 5.3.3 analyzes the Stateless DHCPv6
+   mechanism, and 5.3.4 analyzes the Well-known addresses approach.
+   Section 5.3.5 finally summarizes the recommendations.
+
+5.3.1  Currently Available Mechanisms and Recommendations
+
+   3GPP has defined a mechanism, in which RDNSS addresses can be
+   received in the PDP context activation (a control plane mechanism).
+   That is called the Protocol Configuration Options Information Element
+   (PCO-IE) mechanism [22].  The RDNSS addresses can also be received
+   over the air (using text messages), or typed in manually in the UE.
+   Note that the two last mechanisms are not very well scalable.  The UE
+   user most probably does not want to type IPv6 RDNSS addresses
+   manually in his/her UE.  The use of well-known addresses is briefly
+   discussed in section 5.3.4.
+
+   It is seen that the mechanisms above most probably are not sufficient
+   for the 3GPP environment.  IPv6 is intended to operate in a zero-
+   configuration manner, no matter what the underlying network
+   infrastructure is.  Typically, the RDNSS address is needed to make an
+   IPv6 node operational - and the DNS configuration should be as simple
+   as the address autoconfiguration mechanism.  It must also be noted
+   that there will be additional IP interfaces in some near future 3GPP
+   UEs, e.g., WLAN, and 3GPP-specific DNS configuration mechanisms (such
+   as PCO-IE [22]) do not work for those IP interfaces.  In other words,
+   a good IPv6 DNS configuration mechanism should also work in a multi-
+   access network environment.
+
+   From a 3GPP point of view, the best IPv6 DNS configuration solution
+   is feasible for a very large number of IPv6-capable UEs (can be even
+   hundreds of millions in one operator's network), is automatic and
+   thus requires no user action.  It is suggested to standardize a
+   lightweight, stateless mechanism that works in all network
+   environments.  The solution could then be used for 3GPP, 3GPP2, WLAN
+   and other access network technologies.  A light, stateless IPv6 DNS
+   configuration mechanism is thus not only needed in 3GPP networks, but
+   also 3GPP networks and UEs would certainly benefit from the new
+   mechanism.
+
+5.3.2  RA Extension
+
+   Router Advertisement extension [8] is a lightweight IPv6 DNS
+   configuration mechanism that requires minor changes in the 3GPP UE
+   IPv6 stack and Gateway GPRS Support Node (GGSN, the default router in
+   the 3GPP architecture) IPv6 stack.  This solution can be specified in
+   the IETF (no action needed in the 3GPP) and taken in use in 3GPP UEs
+
+
+
+Jeong                   Expires November 6, 2005               [Page 19]
+
+Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
+
+
+   and GGSNs
+
+   In this solution, an IPv6-capable UE configures DNS information via
+   RA message sent by its default router (GGSN), i.e., RDNSS option for
+   recursive DNS server is included in the RA message.  This solution is
+   easily scalable for a very large number of UEs.  The operator can
+   configure the RDNSS addresses in the GGSN as a part of normal GGSN
+   configuration.  The IPv6 RDNSS address is received in the Router
+   Advertisement, and an extra Round Trip Time (RTT) for asking RDNSS
+   addresses can be avoided.
+
+   If thinking about the cons, this mechanism still requires
+   standardization effort in the IETF, and the end nodes and routers
+   need to support this mechanism.  The equipment software update
+   should, however, be pretty straightforward, and new IPv6 equipment
+   could support RA extension already from the beginning.
+
+5.3.3  Stateless DHCPv6
+
+   DHCPv6-based solution needs the implementation of Stateless DHCP [6]
+   and DHCPv6 DNS options [7] in the UE, and a DHCPv6 server in the
+   operator's network.  A possible configuration is such that the GGSN
+   works as a DHCP relay.
+
+   Pros for Stateless DHCPv6-based solution are
+
+   1.  Stateless DHCPv6 is a standardized mechanism.
+
+   2.  DHCPv6 can be used for receiving other configuration information
+       than RDNSS addresses, e.g., SIP server addresses.
+
+   3.  DHCPv6 works in different network environments.
+
+   4.  When DHCPv6 service is deployed through a single, centralized
+       server, the RDNSS configuration information can be updated by the
+       network administrator at a single source.
+
+   Some issues with DHCPv6 in 3GPP networks are listed below:
+
+   1.  DHCPv6 requires an additional server in the network unless the
+       (Stateless) DHCPv6 functionality is integrated into a router
+       already existing, and that means one box more to be maintained.
+
+   2.  DHCPv6 is not necessarily needed for 3GPP UE IPv6 addressing
+       (3GPP Stateless Address Autoconfiguration is typically used), and
+       not automatically implemented in 3GPP IPv6 UEs.
+
+
+
+
+
+Jeong                   Expires November 6, 2005               [Page 20]
+
+Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
+
+
+   3.  Scalability and reliability of DHCPv6 in very large 3GPP networks
+       (with tens or hundreds of millions of UEs) may be an issue, at
+       least the redundancy needs to be taken care of.  However, if the
+       DHCPv6 service is integrated into the network elements, such as a
+       router operating system, scalability and reliability is
+       comparable with other DNS configuration approaches.
+
+   4.  It is sub-optimal to utilize the radio resources in 3GPP networks
+       for DHCPv6 messages if there is a simpler alternative available.
+
+       *  The use of Stateless DHCPv6 adds one round trip delay to the
+          case in which the UE can start transmitting data right after
+          the Router Advertisement.
+
+   5.  If the DNS information (suddenly) changes, Stateless DHCPv6 can
+       not automatically update the UE, see [23].
+
+
+5.3.4  Well-known Addresses
+
+   Using well-known addresses is also a feasible and a light mechanism
+   for 3GPP UEs.  Those well-known addresses can be preconfigured in the
+   UE software and the operator makes the corresponding configuration on
+   the network side.  So this is a very easy mechanism for the UE, but
+   requires some configuration work in the network.  When using well-
+   known addresses, UE forwards queries to any of the preconfigured
+   addresses.  In the current proposal [9], IPv6 anycast addresses are
+   suggested.
+
+Note
+
+   The IPv6 DNS configuration proposal based on the use of well-known
+   site-local addresses developed at the IPv6 Working Group was seen as
+   a feasible mechanism for 3GPP UEs, but opposition by some people in
+   the IETF and finally deprecating IPv6 site-local addresses made it
+   impossible to standardize it.  Note that this mechanism is
+   implemented in some existing operating systems today (also in some
+   3GPP UEs) as a last resort of IPv6 DNS configuration.
+
+5.3.5  Recommendations
+
+   It is suggested that a lightweight, stateless DNS configuration
+   mechanism is specified as soon as possible.  From a 3GPP UE and
+   network point of view, the Router Advertisement based mechanism looks
+   most promising.  The sooner a light, stateless mechanism is
+   specified, the sooner we can get rid of using well-known site-local
+   addresses for IPv6 DNS configuration.
+
+
+
+
+Jeong                   Expires November 6, 2005               [Page 21]
+
+Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
+
+
+5.4  Unmanaged Network
+
+   There are 4 deployment scenarios of interest in unmanaged networks
+   [24]:
+
+   1.  A gateway which does not provide IPv6 at all;
+
+   2.  A dual-stack gateway connected to a dual-stack ISP;
+
+   3.  A dual-stack gateway connected to an IPv4-only ISP; and
+
+   4.  A gateway connected to an IPv6-only ISP.
+
+
+5.4.1  Case A: Gateway does not provide IPv6 at all
+
+   In this case, the gateway does not provide IPv6; the ISP may or may
+   not provide IPv6.  Automatic or Configured tunnels are the
+   recommended transition mechanisms for this scenario.
+
+   The case where dual-stack hosts behind an NAT, that need access to an
+   IPv6 RDNSS, cannot be entirely ruled out.  The DNS configuration
+   mechanism has to work over the tunnel, and the underlying tunneling
+   mechanism could be implementing NAT traversal.  The tunnel server
+   assumes the role of a relay (both for DHCP and Well-known anycast
+   addresses approaches).
+
+   RA-based mechanism is relatively straightforward in its operation,
+   assuming the tunnel server is also the IPv6 router emitting RAs.
+   Well-known anycast addresses approach seems also simple in operation
+   across the tunnel, but the deployment model using Well-known anycast
+   addresses in a tunneled environment is unclear or not well
+   understood.
+
+5.4.2  Case B: A dual-stack gateway connected to a dual-stack ISP
+
+   This is similar to a typical IPv4 home user scenario, where DNS
+   configuration parameters are obtained using DHCP.  Except that
+   Stateless DHCPv6 is used, as opposed to the IPv4 scenario where the
+   DHCP server is stateful (maintains the state for clients).
+
+5.4.3  Case C: A dual-stack gateway connected to an IPv4-only ISP
+
+   This is similar to Case B. If a gateway provides IPv6 connectivity by
+   managing tunnels, then it is also supposed to provide access to an
+   RDNSS.  Like this, the tunnel for IPv6 connectivity originates from
+   the dual-stack gateway instead of the host.
+
+
+
+
+Jeong                   Expires November 6, 2005               [Page 22]
+
+Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
+
+
+5.4.4  Case D: A gateway connected to an IPv6-only ISP
+
+   This is similar to Case B.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Jeong                   Expires November 6, 2005               [Page 23]
+
+Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
+
+
+6.  Security Considerations
+
+   As security requirements depend solely on applications and are
+   different application by application, there can be no generic
+   requirement defined at IP or application layer for DNS.
+
+   However, it should be noted that cryptographic security requires
+   configured secret information that full autoconfiguration and
+   cryptographic security are mutually exclusive.  People insisting on
+   secure full autoconfiguration will get false security, false
+   autoconfiguration or both.
+
+   In some deployment scenarios [19], where cryptographic security is
+   required for applications, the secret information for the
+   cryptographic security is preconfigured through which application
+   specific configuration data, including those for DNS, can be securely
+   configured.  It should be noted that if applications requiring
+   cryptographic security depend on DNS, the applications also require
+   cryptographic security to DNS.  Therefore, the full autoconfiguration
+   of DNS is not acceptable.
+
+   However, with full autoconfiguration, weaker but still reasonable
+   security is being widely accepted and will continue to be acceptable.
+   That is, with full autoconfiguration, which means there is no
+   cryptographic security for the autoconfiguration, it is already
+   assumed that the local environment is secure enough that the
+   information from the local autoconfiguration server has acceptable
+   security even without cryptographic security.  Thus, the
+   communication between the local DNS client and local DNS server has
+   acceptable security.
+
+   In autoconfiguring recursive servers, DNSSEC may be overkill, because
+   DNSSEC [29] needs the configuration and reconfiguration of clients at
+   root key roll-over [30][31].  Even if additional keys for secure key
+   roll-over are added at the initial configuration, they are as
+   vulnerable as the original keys to some forms of attacks, such as
+   social hacking.  Another problem of using DNSSEC and
+   autoconfiguration together is that DNSSEC requires secure time, which
+   means secure communication with autoconfigured time servers, which
+   requires configured secret information.  Therefore, in order that the
+   autoconfiguration may be secure, it requires configured secret
+   information.
+
+   If DNSSEC [29] is used and the signatures are verified on the client
+   host, the misconfiguration of a DNS server may be simply denial of
+   service.  Also, if local routing environment is not reliable, clients
+   may be directed to a false resolver with the same IP address as the
+   true one.
+
+
+
+Jeong                   Expires November 6, 2005               [Page 24]
+
+Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
+
+
+6.1  RA Option
+
+   The security of RA option for RDNSS is the same as the ND protocol
+   security [3][8].  The RA option does not add any new vulnerability.
+
+   It should be noted that the vulnerability of ND is not worse and is a
+   subset of the attacks that any node attached to a LAN can do
+   independently of ND.  A malicious node on a LAN can promiscuously
+   receive packets for any router's MAC address and send packets with
+   the router's MAC address as the source MAC address in the L2 header.
+   As a result, the L2 switches send packets addressed to the router to
+   the malicious node.  Also, this attack can send redirects that tell
+   the hosts to send their traffic somewhere else.  The malicious node
+   can send unsolicited RA or NA replies, answer RS or NS requests, etc.
+   All of this can be done independently of implementing ND.  Therefore,
+   the RA option for RDNSS does not add to the vulnerability.
+
+   Security issues regarding the ND protocol were discussed at IETF SEND
+   (Securing Neighbor Discovery) Working Group and RFC 3971 for the ND
+   security has been published [14].
+
+6.2  DHCPv6 Option
+
+   The DNS Recursive Name Server option may be used by an intruder DHCP
+   server to cause DHCP clients to send DNS queries to an intruder DNS
+   recursive name server [7].  The results of these misdirected DNS
+   queries may be used to spoof DNS names.
+
+   To avoid attacks through the DNS Recursive Name Server option, the
+   DHCP client SHOULD require DHCP authentication (see section
+   "Authentication of DHCP messages" in RFC 3315 [5]) before installing
+   a list of DNS recursive name servers obtained through authenticated
+   DHCP.
+
+6.3  Well-known Anycast Addresses
+
+   Well-known anycast addresses does not require configuration security
+   since there is no protocol [9].
+
+   The DNS server with the preconfigured addresses are still reasonably
+   reliable, if local environment is reasonably secure, that is, there
+   is no active attackers receiving queries to the anycast addresses of
+   the servers and reply to them.
+
+
+
+
+
+
+
+
+Jeong                   Expires November 6, 2005               [Page 25]
+
+Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
+
+
+7.  Contributors
+
+   Ralph Droms
+   Cisco Systems, Inc.
+   1414 Massachusetts Ave.
+   Boxboro, MA  01719
+   US
+
+   Phone: +1 978 936 1674
+   Email: rdroms@cisco.com
+
+
+   Robert M. Hinden
+   Nokia
+   313 Fairchild Drive
+   Mountain View, CA  94043
+   US
+
+   Phone: +1 650 625 2004
+   Email: bob.hinden@nokia.com
+
+
+   Ted Lemon
+   Nominum, Inc.
+   950 Charter Street
+   Redwood City, CA  94043
+   US
+
+   Email: Ted.Lemon@nominum.com
+
+
+   Masataka Ohta
+   Tokyo Institute of Technology
+   2-12-1, O-okayama, Meguro-ku
+   Tokyo  152-8552
+   Japan
+
+   Phone: +81 3 5734 3299
+   Fax:   +81 3 5734 3299
+   Email: mohta@necom830.hpcl.titech.ac.jp
+
+
+   Soohong Daniel Park
+   Mobile Platform Laboratory, SAMSUNG Electronics
+   416 Maetan-3dong, Yeongtong-Gu
+   Suwon, Gyeonggi-Do  443-742
+   Korea
+
+
+
+
+Jeong                   Expires November 6, 2005               [Page 26]
+
+Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
+
+
+   Phone: +82 31 200 4508
+   Email: soohong.park@samsung.com
+
+
+   Suresh Satapati
+   Cisco Systems, Inc.
+   San Jose, CA  95134
+   US
+
+   Email: satapati@cisco.com
+
+
+   Juha Wiljakka
+   Nokia
+   Visiokatu 3
+   FIN-33720, TAMPERE
+   Finland
+
+   Phone: +358 7180 48372
+   Email: juha.wiljakka@nokia.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Jeong                   Expires November 6, 2005               [Page 27]
+
+Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
+
+
+8.  Acknowledgements
+
+   This draft has greatly benefited from inputs by David Meyer, Rob
+   Austein, Tatuya Jinmei, Pekka Savola, Tim Chown, Luc Beloeil,
+   Christian Huitema, Thomas Narten, Pascal Thubert, and Greg Daley.
+   Also, Tony Bonanno proofread this draft.  The authors appreciate
+   their contribution.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Jeong                   Expires November 6, 2005               [Page 28]
+
+Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
+
+
+9.  References
+
+9.1  Normative References
+
+   [1]  Bradner, S., "IETF Rights in Contributions", RFC 3667,
+        February 2004.
+
+   [2]  Bradner, S., "Intellectual Property Rights in IETF Technology",
+        RFC 3668, February 2004.
+
+   [3]  Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery
+        for IP Version 6 (IPv6)", RFC 2461, December 1998.
+
+   [4]  Thomson, S. and T. Narten, "IPv6 Stateless Address
+        Autoconfiguration", RFC 2462, December 1998.
+
+   [5]  Droms, R., Ed., "Dynamic Host Configuration Protocol for IPv6
+        (DHCPv6)", RFC 3315, July 2003.
+
+   [6]  Droms, R., "Stateless Dynamic Host Configuration Protocol (DHCP)
+        Service for IPv6", RFC 3736, April 2004.
+
+   [7]  Droms, R., Ed., "DNS Configuration options for Dynamic Host
+        Configuration Protocol for IPv6 (DHCPv6)", RFC 3646,
+        December 2003.
+
+9.2  Informative References
+
+   [8]   Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, "IPv6 DNS
+         Discovery based on Router Advertisement",
+         draft-jeong-dnsop-ipv6-dns-discovery-04.txt (Work in Progress),
+         February 2005.
+
+   [9]   Ohta, M., "Preconfigured DNS Server Addresses",
+         draft-ohta-preconfigured-dns-01.txt (Work in Progress),
+         February 2004.
+
+   [10]  Venaas, S., Chown, T., and B. Volz, "Information Refresh Time
+         Option for DHCPv6", draft-ietf-dhc-lifetime-03.txt (Work in
+         Progress), January 2005.
+
+   [11]  Partridge, C., Mendez, T., and W. Milliken, "Host Anycasting
+         Service", RFC 1546, November 1993.
+
+   [12]  Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6)
+         Addressing Architecture", RFC 3513, April 2003.
+
+   [13]  Lind, M., Ed., "Scenarios and Analysis for Introduction IPv6
+
+
+
+Jeong                   Expires November 6, 2005               [Page 29]
+
+Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
+
+
+         into ISP Networks", RFC 4029, March 2005.
+
+   [14]  Arkko, J., Ed., "SEcure Neighbor Discovery (SEND)", RFC 3971,
+         March 2005.
+
+   [15]  Droms, R. and W. Arbaugh, "Authentication for DHCP Messages",
+         RFC 3118, June 2001.
+
+   [16]  Bound, J., Ed., "IPv6 Enterprise Network Scenarios",
+         draft-ietf-v6ops-ent-scenarios-05.txt (Work in Progress),
+         July 2004.
+
+   [17]  Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host
+         Configuration Protocol (DHCP) version 6", RFC 3633,
+         December 2003.
+
+   [18]  Wasserman, M., Ed., "Recommendations for IPv6 in 3GPP
+         Standards", RFC 3314, September 2002.
+
+   [19]  Soininen, J., Ed., "Transition Scenarios for 3GPP Networks",
+         RFC 3574, August 2003.
+
+   [20]  Wiljakka, J., Ed., "Analysis on IPv6 Transition in 3GPP
+         Networks", draft-ietf-v6ops-3gpp-analysis-11.txt (Work in
+         Progress), October 2004.
+
+   [21]  3GPP TS 23.060 V5.4.0, "General Packet Radio Service (GPRS);
+         Service description; Stage 2 (Release 5)", December 2002.
+
+   [22]  3GPP TS 24.008 V5.8.0, "Mobile radio interface Layer 3
+         specification; Core network protocols; Stage 3 (Release 5)",
+         June 2003.
+
+   [23]  Chown, T., Venaas, S., and A. Vijayabhaskar, "Renumbering
+         Requirements for Stateless DHCPv6",
+         draft-ietf-dhc-stateless-dhcpv6-renumbering-02.txt (Work in
+         Progress), October 2004.
+
+   [24]  Huitema, C., Ed., "Unmanaged Networks IPv6 Transition
+         Scenarios", RFC 3750, April 2004.
+
+   [25]  ANSI/IEEE Std 802.11, "Part 11: Wireless LAN Medium Access
+         Control (MAC) and Physical Layer (PHY) Specifications",
+         March 1999.
+
+   [26]  IEEE Std 802.11a, "Part 11: Wireless LAN Medium Access Control
+         (MAC) and Physical Layer (PHY) specifications: High-speed
+         Physical Layer in the 5 GHZ Band", September 1999.
+
+
+
+Jeong                   Expires November 6, 2005               [Page 30]
+
+Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
+
+
+   [27]  IEEE Std 802.11b, "Part 11: Wireless LAN Medium Access Control
+         (MAC) and Physical Layer (PHY) specifications: Higher-Speed
+         Physical Layer Extension in the 2.4 GHz Band", September 1999.
+
+   [28]  IEEE P802.11g/D8.2, "Part 11: Wireless LAN Medium Access
+         Control (MAC) and Physical Layer (PHY) specifications: Further
+         Higher Data Rate Extension in the 2.4 GHz Band", April 2003.
+
+   [29]  Eastlake, D., "Domain Name System Security Extensions",
+         RFC 2535, March 1999.
+
+   [30]  Kolkman, O. and R. Gieben, "DNSSEC Operational Practices",
+         draft-ietf-dnsop-dnssec-operational-practices-03.txt (Work in
+         Progress), December 2004.
+
+   [31]  Guette, G. and O. Courtay, "Requirements for Automated Key
+         Rollover in DNSSEC",
+         draft-ietf-dnsop-key-rollover-requirements-02.txt (Work in
+         Progress), January 2005.
+
+   [32]  Park, S., Madanapalli, S., and T. Jinmei, "Considerations on M
+         and O Flags of IPv6 Router Advertisement",
+         draft-ietf-ipv6-ra-mo-flags-01.txt (Work in Progress),
+         March 2005.
+
+
+Author's Address
+
+   Jaehoon Paul Jeong (editor)
+   ETRI/Department of Computer Science and Engineering
+   University of Minnesota
+   117 Pleasant Street SE
+   Minneapolis, MN  55455
+   US
+
+   Phone: +1 651 587 7774
+   Fax:   +1 612 625 2002
+   Email: jjeong@cs.umn.edu
+   URI:   http://www.cs.umn.edu/~jjeong/
+
+
+
+
+
+
+
+
+
+
+
+
+Jeong                   Expires November 6, 2005               [Page 31]
+
+Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
+
+
+Appendix A.  Link-layer Multicast Acknowledgements for RA Option
+
+   One benefit of an RA option [8] is to be able to multicast the
+   advertisements, reducing the need for duplicated unicast
+   communications.
+
+   However, some link-layers may not support this as well as others.
+   Consider, for example, WLAN networks where multicast is unreliable.
+   The unreliability problem is caused by lack of ACK for multicast,
+   especially on the path from the Access Point (AP) to the Station
+   (STA), which is specific to CSMA/CA of WLAN, such as IEEE 802.11
+   a/b/g [25]-[28].  That is, a multicast packet is unacknowledged on
+   the path from the AP to the STA, but acknowledged in the reverse
+   direction from the STA to the AP [25].  For example, when a router is
+   placed at wired network connected to an AP, a host may sometimes not
+   receive RA message advertised through the AP.  Therefore, the RA
+   option solution might not work well on a congested medium that uses
+   unreliable multicast for RA.
+
+   The fact that this problem has not been addressed in Neighbor
+   Discovery [3] indicates that the extra link-layer acknowledgements
+   have not been considered a serious problem till now.
+
+   A possible mitigation technique could be to map all-nodes link- local
+   multicast address to the link-layer broadcast address, and to rely on
+   the ND retransmissions for message delivery in order to achieve more
+   reliability.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Jeong                   Expires November 6, 2005               [Page 32]
+
+Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2005).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Jeong                   Expires November 6, 2005               [Page 33]
+
diff --git a/doc/draft/draft-ietf-dnsop-ipv6-dns-issues-11.txt b/doc/draft/draft-ietf-dnsop-ipv6-dns-issues-11.txt
new file mode 100644
index 0000000..1276f9f
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsop-ipv6-dns-issues-11.txt
@@ -0,0 +1,1682 @@
+
+
+
+
+DNS Operations WG                                              A. Durand
+Internet-Draft                                    SUN Microsystems, Inc.
+Expires: January 17, 2006                                       J. Ihren
+                                                              Autonomica
+                                                               P. Savola
+                                                               CSC/FUNET
+                                                           July 16, 2005
+
+
+          Operational Considerations and Issues with IPv6 DNS
+                draft-ietf-dnsop-ipv6-dns-issues-11.txt
+
+Status of this Memo
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   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 draft documents 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 "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/ietf/1id-abstracts.txt.
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+   This Internet-Draft will expire on January 17, 2006.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).
+
+Abstract
+
+   This memo presents operational considerations and issues with IPv6
+   Domain Name System (DNS), including a summary of special IPv6
+   addresses, documentation of known DNS implementation misbehaviour,
+   recommendations and considerations on how to perform DNS naming for
+   service provisioning and for DNS resolver IPv6 support,
+
+
+
+Durand, et al.          Expires January 17, 2006                [Page 1]
+
+Internet-Draft        Considerations with IPv6 DNS             July 2005
+
+
+   considerations for DNS updates for both the forward and reverse
+   trees, and miscellaneous issues.  This memo is aimed to include a
+   summary of information about IPv6 DNS considerations for those who
+   have experience with IPv4 DNS.
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
+     1.1   Representing IPv6 Addresses in DNS Records . . . . . . . .  4
+     1.2   Independence of DNS Transport and DNS Records  . . . . . .  4
+     1.3   Avoiding IPv4/IPv6 Name Space Fragmentation  . . . . . . .  5
+     1.4   Query Type '*' and A/AAAA Records  . . . . . . . . . . . .  5
+   2.  DNS Considerations about Special IPv6 Addresses  . . . . . . .  5
+     2.1   Limited-scope Addresses  . . . . . . . . . . . . . . . . .  6
+     2.2   Temporary Addresses  . . . . . . . . . . . . . . . . . . .  6
+     2.3   6to4 Addresses . . . . . . . . . . . . . . . . . . . . . .  6
+     2.4   Other Transition Mechanisms  . . . . . . . . . . . . . . .  6
+   3.  Observed DNS Implementation Misbehaviour . . . . . . . . . . .  7
+     3.1   Misbehaviour of DNS Servers and Load-balancers . . . . . .  7
+     3.2   Misbehaviour of DNS Resolvers  . . . . . . . . . . . . . .  7
+   4.  Recommendations for Service Provisioning using DNS . . . . . .  7
+     4.1   Use of Service Names instead of Node Names . . . . . . . .  8
+     4.2   Separate vs the Same Service Names for IPv4 and IPv6 . . .  8
+     4.3   Adding the Records Only when Fully IPv6-enabled  . . . . .  9
+     4.4   The Use of TTL for IPv4 and IPv6 RRs . . . . . . . . . . . 10
+       4.4.1   TTL With Courtesy Additional Data  . . . . . . . . . . 10
+       4.4.2   TTL With Critical Additional Data  . . . . . . . . . . 10
+     4.5   IPv6 Transport Guidelines for DNS Servers  . . . . . . . . 11
+   5.  Recommendations for DNS Resolver IPv6 Support  . . . . . . . . 11
+     5.1   DNS Lookups May Query IPv6 Records Prematurely . . . . . . 11
+     5.2   Obtaining a List of DNS Recursive Resolvers  . . . . . . . 13
+     5.3   IPv6 Transport Guidelines for Resolvers  . . . . . . . . . 13
+   6.  Considerations about Forward DNS Updating  . . . . . . . . . . 13
+     6.1   Manual or Custom DNS Updates . . . . . . . . . . . . . . . 14
+     6.2   Dynamic DNS  . . . . . . . . . . . . . . . . . . . . . . . 14
+   7.  Considerations about Reverse DNS Updating  . . . . . . . . . . 15
+     7.1   Applicability of Reverse DNS . . . . . . . . . . . . . . . 15
+     7.2   Manual or Custom DNS Updates . . . . . . . . . . . . . . . 16
+     7.3   DDNS with Stateless Address Autoconfiguration  . . . . . . 16
+     7.4   DDNS with DHCP . . . . . . . . . . . . . . . . . . . . . . 18
+     7.5   DDNS with Dynamic Prefix Delegation  . . . . . . . . . . . 18
+   8.  Miscellaneous DNS Considerations . . . . . . . . . . . . . . . 19
+     8.1   NAT-PT with DNS-ALG  . . . . . . . . . . . . . . . . . . . 19
+     8.2   Renumbering Procedures and Applications' Use of DNS  . . . 19
+   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
+   10.   Security Considerations  . . . . . . . . . . . . . . . . . . 20
+   11.   References . . . . . . . . . . . . . . . . . . . . . . . . . 20
+     11.1  Normative References . . . . . . . . . . . . . . . . . . . 20
+
+
+
+Durand, et al.          Expires January 17, 2006                [Page 2]
+
+Internet-Draft        Considerations with IPv6 DNS             July 2005
+
+
+     11.2  Informative References . . . . . . . . . . . . . . . . . . 22
+       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 24
+   A.  Unique Local Addressing Considerations for DNS . . . . . . . . 25
+   B.  Behaviour of Additional Data in IPv4/IPv6 Environments . . . . 25
+     B.1   Description of Additional Data Scenarios . . . . . . . . . 26
+     B.2   Which Additional Data to Keep, If Any? . . . . . . . . . . 27
+     B.3   Discussion of the Potential Problems . . . . . . . . . . . 28
+       Intellectual Property and Copyright Statements . . . . . . . . 30
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Durand, et al.          Expires January 17, 2006                [Page 3]
+
+Internet-Draft        Considerations with IPv6 DNS             July 2005
+
+
+1.  Introduction
+
+   This memo presents operational considerations and issues with IPv6
+   DNS; it is meant to be an extensive summary and a list of pointers
+   for more information about IPv6 DNS considerations for those with
+   experience with IPv4 DNS.
+
+   The purpose of this document is to give information about various
+   issues and considerations related to DNS operations with IPv6; it is
+   not meant to be a normative specification or standard for IPv6 DNS.
+
+   The first section gives a brief overview of how IPv6 addresses and
+   names are represented in the DNS, how transport protocols and
+   resource records (don't) relate, and what IPv4/IPv6 name space
+   fragmentation means and how to avoid it; all of these are described
+   at more length in other documents.
+
+   The second section summarizes the special IPv6 address types and how
+   they relate to DNS.  The third section describes observed DNS
+   implementation misbehaviours which have a varying effect on the use
+   of IPv6 records with DNS.  The fourth section lists recommendations
+   and considerations for provisioning services with DNS.  The fifth
+   section in turn looks at recommendations and considerations about
+   providing IPv6 support in the resolvers.  The sixth and seventh
+   sections describe considerations with forward and reverse DNS
+   updates, respectively.  The eighth section introduces several
+   miscellaneous IPv6 issues relating to DNS for which no better place
+   has been found in this memo.  Appendix A looks briefly at the
+   requirements for unique local addressing.
+
+1.1  Representing IPv6 Addresses in DNS Records
+
+   In the forward zones, IPv6 addresses are represented using AAAA
+   records.  In the reverse zones, IPv6 address are represented using
+   PTR records in the nibble format under the ip6.arpa. tree.  See
+   [RFC3596] for more about IPv6 DNS usage, and [RFC3363] or [RFC3152]
+   for background information.
+
+   In particular one should note that the use of A6 records in the
+   forward tree or Bitlabels in the reverse tree is not recommended
+   [RFC3363].  Using DNAME records is not recommended in the reverse
+   tree in conjunction with A6 records; the document did not mean to
+   take a stance on any other use of DNAME records [RFC3364].
+
+1.2  Independence of DNS Transport and DNS Records
+
+   DNS has been designed to present a single, globally unique name space
+   [RFC2826].  This property should be maintained, as described here and
+
+
+
+Durand, et al.          Expires January 17, 2006                [Page 4]
+
+Internet-Draft        Considerations with IPv6 DNS             July 2005
+
+
+   in Section 1.3.
+
+   The IP version used to transport the DNS queries and responses is
+   independent of the records being queried: AAAA records can be queried
+   over IPv4, and A records over IPv6.  The DNS servers must not make
+   any assumptions about what data to return for Answer and Authority
+   sections based on the underlying transport used in a query.
+
+   However, there is some debate whether the addresses in Additional
+   section could be selected or filtered using hints obtained from which
+   transport was being used; this has some obvious problems because in
+   many cases the transport protocol does not correlate with the
+   requests, and because a "bad" answer is in a way worse than no answer
+   at all (consider the case where the client is led to believe that a
+   name received in the additional record does not have any AAAA records
+   at all).
+
+   As stated in [RFC3596]:
+
+      The IP protocol version used for querying resource records is
+      independent of the protocol version of the resource records; e.g.,
+      IPv4 transport can be used to query IPv6 records and vice versa.
+
+
+1.3  Avoiding IPv4/IPv6 Name Space Fragmentation
+
+   To avoid the DNS name space from fragmenting into parts where some
+   parts of DNS are only visible using IPv4 (or IPv6) transport, the
+   recommendation is to always keep at least one authoritative server
+   IPv4-enabled, and to ensure that recursive DNS servers support IPv4.
+   See DNS IPv6 transport guidelines [RFC3901] for more information.
+
+1.4  Query Type '*' and A/AAAA Records
+
+   QTYPE=* is typically only used for debugging or management purposes;
+   it is worth keeping in mind that QTYPE=* ("ANY" queries) only return
+   any available RRsets, not *all* the RRsets, because the caches do not
+   necessarily have all the RRsets and have no way of guaranteeing that
+   they have all the RRsets.  Therefore, to get both A and AAAA records
+   reliably, two separate queries must be made.
+
+2.  DNS Considerations about Special IPv6 Addresses
+
+   There are a couple of IPv6 address types which are somewhat special;
+   these are considered here.
+
+
+
+
+
+
+Durand, et al.          Expires January 17, 2006                [Page 5]
+
+Internet-Draft        Considerations with IPv6 DNS             July 2005
+
+
+2.1  Limited-scope Addresses
+
+   The IPv6 addressing architecture [RFC3513] includes two kinds of
+   local-use addresses: link-local (fe80::/10) and site-local
+   (fec0::/10).  The site-local addresses have been deprecated [RFC3879]
+   but are discussed with unique local addresses in Appendix A.
+
+   Link-local addresses should never be published in DNS (whether in
+   forward or reverse tree), because they have only local (to the
+   connected link) significance [I-D.durand-dnsop-dont-publish].
+
+2.2  Temporary Addresses
+
+   Temporary addresses defined in RFC3041 [RFC3041] (sometimes called
+   "privacy addresses") use a random number as the interface identifier.
+   Having DNS AAAA records that are updated to always contain the
+   current value of a node's temporary address would defeat the purpose
+   of the mechanism and is not recommended.  However, it would still be
+   possible to return a non-identifiable name (e.g., the IPv6 address in
+   hexadecimal format), as described in [RFC3041].
+
+2.3  6to4 Addresses
+
+   6to4 [RFC3056] specifies an automatic tunneling mechanism which maps
+   a public IPv4 address V4ADDR to an IPv6 prefix 2002:V4ADDR::/48.
+
+   If the reverse DNS population would be desirable (see Section 7.1 for
+   applicability), there are a number of possible ways to do so.
+
+   The main proposal [I-D.huston-6to4-reverse-dns] aims to design an
+   autonomous reverse-delegation system that anyone being capable of
+   communicating using a specific 6to4 address would be able to set up a
+   reverse delegation to the corresponding 6to4 prefix.  This could be
+   deployed by e.g., Regional Internet Registries (RIRs).  This is a
+   practical solution, but may have some scalability concerns.
+
+2.4  Other Transition Mechanisms
+
+   6to4 is mentioned as a case of an IPv6 transition mechanism requiring
+   special considerations.  In general, mechanisms which include a
+   special prefix may need a custom solution; otherwise, for example
+   when IPv4 address is embedded as the suffix or not embedded at all,
+   special solutions are likely not needed.
+
+   Note that it does not seem feasible to provide reverse DNS with
+   another automatic tunneling mechanism, Teredo [I-D.huitema-v6ops-
+   teredo]; this is because the IPv6 address is based on the IPv4
+   address and UDP port of the current NAT mapping which is likely to be
+
+
+
+Durand, et al.          Expires January 17, 2006                [Page 6]
+
+Internet-Draft        Considerations with IPv6 DNS             July 2005
+
+
+   relatively short-lived.
+
+3.  Observed DNS Implementation Misbehaviour
+
+   Several classes of misbehaviour in DNS servers, load-balancers and
+   resolvers have been observed.  Most of these are rather generic, not
+   only applicable to IPv6 -- but in some cases, the consequences of
+   this misbehaviour are extremely severe in IPv6 environments and
+   deserve to be mentioned.
+
+3.1  Misbehaviour of DNS Servers and Load-balancers
+
+   There are several classes of misbehaviour in certain DNS servers and
+   load-balancers which have been noticed and documented [RFC4074]: some
+   implementations silently drop queries for unimplemented DNS records
+   types, or provide wrong answers to such queries (instead of a proper
+   negative reply).  While typically these issues are not limited to
+   AAAA records, the problems are aggravated by the fact that AAAA
+   records are being queried instead of (mainly) A records.
+
+   The problems are serious because when looking up a DNS name, typical
+   getaddrinfo() implementations, with AF_UNSPEC hint given, first try
+   to query the AAAA records of the name, and after receiving a
+   response, query the A records.  This is done in a serial fashion --
+   if the first query is never responded to (instead of properly
+   returning a negative answer), significant timeouts will occur.
+
+   In consequence, this is an enormous problem for IPv6 deployments, and
+   in some cases, IPv6 support in the software has even been disabled
+   due to these problems.
+
+   The solution is to fix or retire those misbehaving implementations,
+   but that is likely not going to be effective.  There are some
+   possible ways to mitigate the problem, e.g., by performing the
+   lookups somewhat in parallel and reducing the timeout as long as at
+   least one answer has been received; but such methods remain to be
+   investigated; slightly more on this is included in Section 5.
+
+3.2  Misbehaviour of DNS Resolvers
+
+   Several classes of misbehaviour have also been noticed in DNS
+   resolvers [I-D.ietf-dnsop-bad-dns-res].  However, these do not seem
+   to directly impair IPv6 use, and are only referred to for
+   completeness.
+
+4.  Recommendations for Service Provisioning using DNS
+
+   When names are added in the DNS to facilitate a service, there are
+
+
+
+Durand, et al.          Expires January 17, 2006                [Page 7]
+
+Internet-Draft        Considerations with IPv6 DNS             July 2005
+
+
+   several general guidelines to consider to be able to do it as
+   smoothly as possible.
+
+4.1  Use of Service Names instead of Node Names
+
+   It makes sense to keep information about separate services logically
+   separate in the DNS by using a different DNS hostname for each
+   service.  There are several reasons for doing this, for example:
+
+   o  It allows more flexibility and ease for migration of (only a part
+      of) services from one node to another,
+
+   o  It allows configuring different properties (e.g., TTL) for each
+      service, and
+
+   o  It allows deciding separately for each service whether to publish
+      the IPv6 addresses or not (in cases where some services are more
+      IPv6-ready than others).
+
+   Using SRV records [RFC2782] would avoid these problems.
+   Unfortunately, those are not sufficiently widely used to be
+   applicable in most cases.  Hence an operation technique is to use
+   service names instead of node names (or, "hostnames").  This
+   operational technique is not specific to IPv6, but required to
+   understand the considerations described in Section 4.2 and
+   Section 4.3.
+
+   For example, assume a node named "pobox.example.com" provides both
+   SMTP and IMAP service.  Instead of configuring the MX records to
+   point at "pobox.example.com", and configuring the mail clients to
+   look up the mail via IMAP from "pobox.example.com", one could use
+   e.g., "smtp.example.com" for SMTP (for both message submission and
+   mail relaying between SMTP servers) and "imap.example.com" for IMAP.
+   Note that in the specific case of SMTP relaying, the server itself
+   must typically also be configured to know all its names to ensure
+   loops do not occur.  DNS can provide a layer of indirection between
+   service names and where the service actually is, and using which
+   addresses.  (Obviously, when wanting to reach a specific node, one
+   should use the hostname rather than a service name.)
+
+4.2  Separate vs the Same Service Names for IPv4 and IPv6
+
+   The service naming can be achieved in basically two ways: when a
+   service is named "service.example.com" for IPv4, the IPv6-enabled
+   service could either be added to "service.example.com", or added
+   separately under a different name, e.g., in a sub-domain, like,
+   "service.ipv6.example.com".
+
+
+
+
+Durand, et al.          Expires January 17, 2006                [Page 8]
+
+Internet-Draft        Considerations with IPv6 DNS             July 2005
+
+
+   These two methods have different characteristics.  Using a different
+   name allows for easier service piloting, minimizing the disturbance
+   to the "regular" users of IPv4 service; however, the service would
+   not be used transparently, without the user/application explicitly
+   finding it and asking for it -- which would be a disadvantage in most
+   cases.  When the different name is under a sub-domain, if the
+   services are deployed within a restricted network (e.g., inside an
+   enterprise), it's possible to prefer them transparently, at least to
+   a degree, by modifying the DNS search path; however, this is a
+   suboptimal solution.  Using the same service name is the "long-term"
+   solution, but may degrade performance for those clients whose IPv6
+   performance is lower than IPv4, or does not work as well (see
+   Section 4.3 for more).
+
+   In most cases, it makes sense to pilot or test a service using
+   separate service names, and move to the use of the same name when
+   confident enough that the service level will not degrade for the
+   users unaware of IPv6.
+
+4.3  Adding the Records Only when Fully IPv6-enabled
+
+   The recommendation is that AAAA records for a service should not be
+   added to the DNS until all of following are true:
+
+   1.  The address is assigned to the interface on the node.
+
+   2.  The address is configured on the interface.
+
+   3.  The interface is on a link which is connected to the IPv6
+       infrastructure.
+
+   In addition, if the AAAA record is added for the node, instead of
+   service as recommended, all the services of the node should be IPv6-
+   enabled prior to adding the resource record.
+
+   For example, if an IPv6 node is isolated from an IPv6 perspective
+   (e.g., it is not connected to IPv6 Internet) constraint #3 would mean
+   that it should not have an address in the DNS.
+
+   Consider the case of two dual-stack nodes, which both have IPv6
+   enabled, but the server does not have (global) IPv6 connectivity.  As
+   the client looks up the server's name, only A records are returned
+   (if the recommendations above are followed), and no IPv6
+   communication, which would have been unsuccessful, is even attempted.
+
+   The issues are not always so black-and-white.  Usually it's important
+   that the service offered using both protocols is of roughly equal
+   quality, using the appropriate metrics for the service (e.g.,
+
+
+
+Durand, et al.          Expires January 17, 2006                [Page 9]
+
+Internet-Draft        Considerations with IPv6 DNS             July 2005
+
+
+   latency, throughput, low packet loss, general reliability, etc.) --
+   this is typically very important especially for interactive or real-
+   time services.  In many cases, the quality of IPv6 connectivity may
+   not yet be equal to that of IPv4, at least globally -- this has to be
+   taken into consideration when enabling services.
+
+4.4  The Use of TTL for IPv4 and IPv6 RRs
+
+   The behaviour of DNS caching when different TTL values are used for
+   different RRsets of the same name calls for explicit discussion.  For
+   example, let's consider two unrelated zone fragments:
+
+      example.com.        300    IN    MX     foo.example.com.
+      foo.example.com.    300    IN    A      192.0.2.1
+      foo.example.com.    100    IN    AAAA   2001:db8::1
+
+   ...
+
+      child.example.com.    300  IN    NS     ns.child.example.com.
+      ns.child.example.com. 300  IN    A      192.0.2.1
+      ns.child.example.com. 100  IN    AAAA   2001:db8::1
+
+   In the former case, we have "courtesy" additional data; in the
+   latter, we have "critical" additional data.  See more extensive
+   background discussion of additional data handling in Appendix B.
+
+4.4.1  TTL With Courtesy Additional Data
+
+   When a caching resolver asks for the MX record of example.com, it
+   gets back "foo.example.com".  It may also get back either one or both
+   of the A and AAAA records in the additional section.  The resolver
+   must explicitly query for both A and AAAA records [RFC2821].
+
+   After 100 seconds, the AAAA record is removed from the cache(s)
+   because its TTL expired.  It could be argued to be useful for the
+   caching resolvers to discard the A record when the shorter TTL (in
+   this case, for the AAAA record) expires; this would avoid the
+   situation where there would be a window of 200 seconds when
+   incomplete information is returned from the cache.  Further argument
+   for discarding is that in the normal operation, the TTL values are so
+   high that very likely the incurred additional queries would not be
+   noticeable, compared to the obtained performance optimization.  The
+   behaviour in this scenario is unspecified.
+
+4.4.2  TTL With Critical Additional Data
+
+   The difference to courtesy additional data is that the A/AAAA records
+   served by the parent zone cannot be queried explicitly.  Therefore
+
+
+
+Durand, et al.          Expires January 17, 2006               [Page 10]
+
+Internet-Draft        Considerations with IPv6 DNS             July 2005
+
+
+   after 100 seconds the AAAA record is removed from the cache(s), but
+   the A record remains.  Queries for the remaining 200 seconds
+   (provided that there are no further queries from the parent which
+   could refresh the caches) only return the A record, leading to a
+   potential opererational situation with unreachable servers.
+
+   Similar cache flushing strategies apply in this scenario; the record.
+
+4.5  IPv6 Transport Guidelines for DNS Servers
+
+   As described in Section 1.3 and [RFC3901], there should continue to
+   be at least one authoritative IPv4 DNS server for every zone, even if
+   the zone has only IPv6 records.  (Note that obviously, having more
+   servers with robust connectivity would be preferable, but this is the
+   minimum recommendation; also see [RFC2182].)
+
+5.  Recommendations for DNS Resolver IPv6 Support
+
+   When IPv6 is enabled on a node, there are several things to consider
+   to ensure that the process is as smooth as possible.
+
+5.1  DNS Lookups May Query IPv6 Records Prematurely
+
+   The system library that implements the getaddrinfo() function for
+   looking up names is a critical piece when considering the robustness
+   of enabling IPv6; it may come in basically three flavours:
+
+   1.  The system library does not know whether IPv6 has been enabled in
+       the kernel of the operating system: it may start looking up AAAA
+       records with getaddrinfo() and AF_UNSPEC hint when the system is
+       upgraded to a system library version which supports IPv6.
+
+   2.  The system library might start to perform IPv6 queries with
+       getaddrinfo() only when IPv6 has been enabled in the kernel.
+       However, this does not guarantee that there exists any useful
+       IPv6 connectivity (e.g., the node could be isolated from the
+       other IPv6 networks, only having link-local addresses).
+
+   3.  The system library might implement a toggle which would apply
+       some heuristics to the "IPv6-readiness" of the node before
+       starting to perform queries; for example, it could check whether
+       only link-local IPv6 address(es) exists, or if at least one
+       global IPv6 address exists.
+
+   First, let us consider generic implications of unnecessary queries
+   for AAAA records: when looking up all the records in the DNS, AAAA
+   records are typically tried first, and then A records.  These are
+   done in serial, and the A query is not performed until a response is
+
+
+
+Durand, et al.          Expires January 17, 2006               [Page 11]
+
+Internet-Draft        Considerations with IPv6 DNS             July 2005
+
+
+   received to the AAAA query.  Considering the misbehaviour of DNS
+   servers and load-balancers, as described in Section 3.1, the look-up
+   delay for AAAA may incur additional unnecessary latency, and
+   introduce a component of unreliability.
+
+   One option here could be to do the queries partially in parallel; for
+   example, if the final response to the AAAA query is not received in
+   0.5 seconds, start performing the A query while waiting for the
+   result (immediate parallelism might be unoptimal, at least without
+   information sharing between the look-up threads, as that would
+   probably lead to duplicate non-cached delegation chain lookups).
+
+   An additional concern is the address selection, which may, in some
+   circumstances, prefer AAAA records over A records even when the node
+   does not have any IPv6 connectivity [I-D.ietf-v6ops-v6onbydefault].
+   In some cases, the implementation may attempt to connect or send a
+   datagram on a physical link [I-D.ietf-v6ops-onlinkassumption],
+   incurring very long protocol timeouts, instead of quickly failing
+   back to IPv4.
+
+   Now, we can consider the issues specific to each of the three
+   possibilities:
+
+   In the first case, the node performs a number of completely useless
+   DNS lookups as it will not be able to use the returned AAAA records
+   anyway.  (The only exception is where the application desires to know
+   what's in the DNS, but not use the result for communication.)  One
+   should be able to disable these unnecessary queries, for both latency
+   and reliability reasons.  However, as IPv6 has not been enabled, the
+   connections to IPv6 addresses fail immediately, and if the
+   application is programmed properly, the application can fall
+   gracefully back to IPv4 [RFC4038].
+
+   The second case is similar to the first, except it happens to a
+   smaller set of nodes when IPv6 has been enabled but connectivity has
+   not been provided yet; similar considerations apply, with the
+   exception that IPv6 records, when returned, will be actually tried
+   first which may typically lead to long timeouts.
+
+   The third case is a bit more complex: optimizing away the DNS lookups
+   with only link-locals is probably safe (but may be desirable with
+   different lookup services which getaddrinfo() may support), as the
+   link-locals are typically automatically generated when IPv6 is
+   enabled, and do not indicate any form of IPv6 connectivity.  That is,
+   performing DNS lookups only when a non-link-local address has been
+   configured on any interface could be beneficial -- this would be an
+   indication that either the address has been configured either from a
+   router advertisement, DHCPv6 [RFC3315], or manually.  Each would
+
+
+
+Durand, et al.          Expires January 17, 2006               [Page 12]
+
+Internet-Draft        Considerations with IPv6 DNS             July 2005
+
+
+   indicate at least some form of IPv6 connectivity, even though there
+   would not be guarantees of it.
+
+   These issues should be analyzed at more depth, and the fixes found
+   consensus on, perhaps in a separate document.
+
+5.2  Obtaining a List of DNS Recursive Resolvers
+
+   In scenarios where DHCPv6 is available, a host can discover a list of
+   DNS recursive resolvers through DHCPv6 "DNS Recursive Name Server"
+   option [RFC3646].  This option can be passed to a host through a
+   subset of DHCPv6 [RFC3736].
+
+   The IETF is considering the development of alternative mechanisms for
+   obtaining the list of DNS recursive name servers when DHCPv6 is
+   unavailable or inappropriate.  No decision about taking on this
+   development work has been reached as of this writing (Aug 2004)
+   [I-D.ietf-dnsop-ipv6-dns-configuration].
+
+   In scenarios where DHCPv6 is unavailable or inappropriate, mechanisms
+   under consideration for development include the use of well-known
+   addresses [I-D.ohta-preconfigured-dns] and the use of Router
+   Advertisements to convey the information [I-D.jeong-dnsop-ipv6-dns-
+   discovery].
+
+   Note that even though IPv6 DNS resolver discovery is a recommended
+   procedure, it is not required for dual-stack nodes in dual-stack
+   networks as IPv6 DNS records can be queried over IPv4 as well as
+   IPv6.  Obviously, nodes which are meant to function without manual
+   configuration in IPv6-only networks must implement the DNS resolver
+   discovery function.
+
+5.3  IPv6 Transport Guidelines for Resolvers
+
+   As described in Section 1.3 and [RFC3901], the recursive resolvers
+   should be IPv4-only or dual-stack to be able to reach any IPv4-only
+   DNS server.  Note that this requirement is also fulfilled by an IPv6-
+   only stub resolver pointing to a dual-stack recursive DNS resolver.
+
+6.  Considerations about Forward DNS Updating
+
+   While the topic of how to enable updating the forward DNS, i.e., the
+   mapping from names to the correct new addresses, is not specific to
+   IPv6, it should be considered especially due to the advent of
+   Stateless Address Autoconfiguration [RFC2462].
+
+   Typically forward DNS updates are more manageable than doing them in
+   the reverse DNS, because the updater can often be assumed to "own" a
+
+
+
+Durand, et al.          Expires January 17, 2006               [Page 13]
+
+Internet-Draft        Considerations with IPv6 DNS             July 2005
+
+
+   certain DNS name -- and we can create a form of security relationship
+   with the DNS name and the node which is allowed to update it to point
+   to a new address.
+
+   A more complex form of DNS updates -- adding a whole new name into a
+   DNS zone, instead of updating an existing name -- is considered out
+   of scope for this memo as it could require zone-wide authentication.
+   Adding a new name in the forward zone is a problem which is still
+   being explored with IPv4, and IPv6 does not seem to add much new in
+   that area.
+
+6.1  Manual or Custom DNS Updates
+
+   The DNS mappings can also be maintained by hand, in a semi-automatic
+   fashion or by running non-standardized protocols.  These are not
+   considered at more length in this memo.
+
+6.2  Dynamic DNS
+
+   Dynamic DNS updates (DDNS) [RFC2136] [RFC3007] is a standardized
+   mechanism for dynamically updating the DNS.  It works equally well
+   with stateless address autoconfiguration (SLAAC), DHCPv6 or manual
+   address configuration.  It is important to consider how each of these
+   behave if IP address-based authentication, instead of stronger
+   mechanisms [RFC3007], was used in the updates.
+
+   1.  manual addresses are static and can be configured
+
+   2.  DHCPv6 addresses could be reasonably static or dynamic, depending
+       on the deployment, and could or could not be configured on the
+       DNS server for the long term
+
+   3.  SLAAC addresses are typically stable for a long time, but could
+       require work to be configured and maintained.
+
+   As relying on IP addresses for Dynamic DNS is rather insecure at
+   best, stronger authentication should always be used; however, this
+   requires that the authorization keying will be explicitly configured
+   using unspecified operational methods.
+
+   Note that with DHCP it is also possible that the DHCP server updates
+   the DNS, not the host.  The host might only indicate in the DHCP
+   exchange which hostname it would prefer, and the DHCP server would
+   make the appropriate updates.  Nonetheless, while this makes setting
+   up a secure channel between the updater and the DNS server easier, it
+   does not help much with "content" security, i.e., whether the
+   hostname was acceptable -- if the DNS server does not include
+   policies, they must be included in the DHCP server (e.g., a regular
+
+
+
+Durand, et al.          Expires January 17, 2006               [Page 14]
+
+Internet-Draft        Considerations with IPv6 DNS             July 2005
+
+
+   host should not be able to state that its name is "www.example.com").
+   DHCP-initiated DDNS updates have been extensively described in
+   [I-D.ietf-dhc-ddns-resolution], [I-D.ietf-dhc-fqdn-option] and
+   [I-D.ietf-dnsext-dhcid-rr].
+
+   The nodes must somehow be configured with the information about the
+   servers where they will attempt to update their addresses, sufficient
+   security material for authenticating themselves to the server, and
+   the hostname they will be updating.  Unless otherwise configured, the
+   first could be obtained by looking up the authoritative name servers
+   for the hostname; the second must be configured explicitly unless one
+   chooses to trust the IP address-based authentication (not a good
+   idea); and lastly, the nodename is typically pre-configured somehow
+   on the node, e.g., at install time.
+
+   Care should be observed when updating the addresses not to use longer
+   TTLs for addresses than are preferred lifetimes for the addresses, so
+   that if the node is renumbered in a managed fashion, the amount of
+   stale DNS information is kept to the minimum.  That is, if the
+   preferred lifetime of an address expires, the TTL of the record needs
+   be modified unless it was already done before the expiration.  For
+   better flexibility, the DNS TTL should be much shorter (e.g., a half
+   or a third) than the lifetime of an address; that way, the node can
+   start lowering the DNS TTL if it seems like the address has not been
+   renewed/refreshed in a while.  Some discussion on how an
+   administrator could manage the DNS TTL is included in [I-D.ietf-
+   v6ops-renumbering-procedure]; this could be applied to (smart) hosts
+   as well.
+
+7.  Considerations about Reverse DNS Updating
+
+   Updating the reverse DNS zone may be difficult because of the split
+   authority over an address.  However, first we have to consider the
+   applicability of reverse DNS in the first place.
+
+7.1  Applicability of Reverse DNS
+
+   Today, some applications use reverse DNS to either look up some hints
+   about the topological information associated with an address (e.g.
+   resolving web server access logs), or as a weak form of a security
+   check, to get a feel whether the user's network administrator has
+   "authorized" the use of the address (on the premises that adding a
+   reverse record for an address would signal some form of
+   authorization).
+
+   One additional, maybe slightly more useful usage is ensuring that the
+   reverse and forward DNS contents match (by looking up the pointer to
+   the name by the IP address from the reverse tree, and ensuring that a
+
+
+
+Durand, et al.          Expires January 17, 2006               [Page 15]
+
+Internet-Draft        Considerations with IPv6 DNS             July 2005
+
+
+   record under the name in the forward tree points to the IP address)
+   and correspond to a configured name or domain.  As a security check,
+   it is typically accompanied by other mechanisms, such as a user/
+   password login; the main purpose of the reverse+forward DNS check is
+   to weed out the majority of unauthorized users, and if someone
+   managed to bypass the checks, he would still need to authenticate
+   "properly".
+
+   It may also be desirable to store IPsec keying material corresponding
+   to an IP address in the reverse DNS, as justified and described in
+   [RFC4025].
+
+   It is not clear whether it makes sense to require or recommend that
+   reverse DNS records be updated.  In many cases, it would just make
+   more sense to use proper mechanisms for security (or topological
+   information lookup) in the first place.  At minimum, the applications
+   which use it as a generic authorization (in the sense that a record
+   exists at all) should be modified as soon as possible to avoid such
+   lookups completely.
+
+   The applicability is discussed at more length in [I-D.ietf-dnsop-
+   inaddr-required].
+
+7.2  Manual or Custom DNS Updates
+
+   Reverse DNS can of course be updated using manual or custom methods.
+   These are not further described here, except for one special case.
+
+   One way to deploy reverse DNS would be to use wildcard records, for
+   example, by configuring one name for a subnet (/64) or a site (/48).
+   As a concrete example, a site (or the site's ISP) could configure the
+   reverses of the prefix 2001:db8:f00::/48 to point to one name using a
+   wildcard record like "*.0.0.f.0.8.b.d.0.1.0.0.2.ip6.arpa.  IN PTR
+   site.example.com."  Naturally, such a name could not be verified from
+   the forward DNS, but would at least provide some form of "topological
+   information" or "weak authorization" if that is really considered to
+   be useful.  Note that this is not actually updating the DNS as such,
+   as the whole point is to avoid DNS updates completely by manually
+   configuring a generic name.
+
+7.3  DDNS with Stateless Address Autoconfiguration
+
+   Dynamic reverse DNS with SLAAC is simpler than forward DNS updates in
+   some regard, while being more difficult in another, as described
+   below.
+
+   The address space administrator decides whether the hosts are trusted
+   to update their reverse DNS records or not.  If they are trusted and
+
+
+
+Durand, et al.          Expires January 17, 2006               [Page 16]
+
+Internet-Draft        Considerations with IPv6 DNS             July 2005
+
+
+   deployed at the same site (e.g., not across the Internet), a simple
+   address-based authorization is typically sufficient (i.e., check that
+   the DNS update is done from the same IP address as the record being
+   updated); stronger security can also be used [RFC3007].  If they
+   aren't allowed to update the reverses, no update can occur.  However,
+   such address-based update authorization operationally requires that
+   ingress filtering [RFC3704] has been set up at the border of the site
+   where the updates occur, and as close to the updater as possible.
+
+   Address-based authorization is simpler with reverse DNS (as there is
+   a connection between the record and the address) than with forward
+   DNS.  However, when a stronger form of security is used, forward DNS
+   updates are simpler to manage because the host can be assumed to have
+   an association with the domain.  Note that the user may roam to
+   different networks, and does not necessarily have any association
+   with the owner of that address space -- so, assuming stronger form of
+   authorization for reverse DNS updates than an address association is
+   generally infeasible.
+
+   Moreover, the reverse zones must be cleaned up by an unspecified
+   janitorial process: the node does not typically know a priori that it
+   will be disconnected, and cannot send a DNS update using the correct
+   source address to remove a record.
+
+   A problem with defining the clean-up process is that it is difficult
+   to ensure that a specific IP address and the corresponding record are
+   no longer being used.  Considering the huge address space, and the
+   unlikelihood of collision within 64 bits of the interface
+   identifiers, a process which would remove the record after no traffic
+   has been seen from a node in a long period of time (e.g., a month or
+   year) might be one possible approach.
+
+   To insert or update the record, the node must discover the DNS server
+   to send the update to somehow, similar to as discussed in
+   Section 6.2.  One way to automate this is looking up the DNS server
+   authoritative (e.g., through SOA record) for the IP address being
+   updated, but the security material (unless the IP address-based
+   authorization is trusted) must also be established by some other
+   means.
+
+   One should note that Cryptographically Generated Addresses [RFC3972]
+   (CGAs) may require a slightly different kind of treatment.  CGAs are
+   addresses where the interface identifier is calculated from a public
+   key, a modifier (used as a nonce), the subnet prefix, and other data.
+   Depending on the usage profile, CGAs might or might not be changed
+   periodically due to e.g., privacy reasons.  As the CGA address is not
+   predicatable, a reverse record can only reasonably be inserted in the
+   DNS by the node which generates the address.
+
+
+
+Durand, et al.          Expires January 17, 2006               [Page 17]
+
+Internet-Draft        Considerations with IPv6 DNS             July 2005
+
+
+7.4  DDNS with DHCP
+
+   With DHCPv4, the reverse DNS name is typically already inserted to
+   the DNS that reflects to the name (e.g., "dhcp-67.example.com").  One
+   can assume similar practice may become commonplace with DHCPv6 as
+   well; all such mappings would be pre-configured, and would require no
+   updating.
+
+   If a more explicit control is required, similar considerations as
+   with SLAAC apply, except for the fact that typically one must update
+   a reverse DNS record instead of inserting one (if an address
+   assignment policy that reassigns disused addresses is adopted) and
+   updating a record seems like a slightly more difficult thing to
+   secure.  However, it is yet uncertain how DHCPv6 is going to be used
+   for address assignment.
+
+   Note that when using DHCP, either the host or the DHCP server could
+   perform the DNS updates; see the implications in Section 6.2.
+
+   If disused addresses were to be reassigned, host-based DDNS reverse
+   updates would need policy considerations for DNS record modification,
+   as noted above.  On the other hand, if disused address were not to be
+   assigned, host-based DNS reverse updates would have similar
+   considerations as SLAAC in Section 7.3.  Server-based updates have
+   similar properties except that the janitorial process could be
+   integrated with DHCP address assignment.
+
+7.5  DDNS with Dynamic Prefix Delegation
+
+   In cases where a prefix, instead of an address, is being used and
+   updated, one should consider what is the location of the server where
+   DDNS updates are made.  That is, where the DNS server is located:
+
+   1.  At the same organization as the prefix delegator.
+
+   2.  At the site where the prefixes are delegated to.  In this case,
+       the authority of the DNS reverse zone corresponding to the
+       delegated prefix is also delegated to the site.
+
+   3.  Elsewhere; this implies a relationship between the site and where
+       DNS server is located, and such a relationship should be rather
+       straightforward to secure as well.  Like in the previous case,
+       the authority of the DNS reverse zone is also delegated.
+
+   In the first case, managing the reverse DNS (delegation) is simpler
+   as the DNS server and the prefix delegator are in the same
+   administrative domain (as there is no need to delegate anything at
+   all); alternatively, the prefix delegator might forgo DDNS reverse
+
+
+
+Durand, et al.          Expires January 17, 2006               [Page 18]
+
+Internet-Draft        Considerations with IPv6 DNS             July 2005
+
+
+   capability altogether, and use e.g., wildcard records (as described
+   in Section 7.2).  In the other cases, it can be slighly more
+   difficult, particularly as the site will have to configure the DNS
+   server to be authoritative for the delegated reverse zone, implying
+   automatic configuration of the DNS server -- as the prefix may be
+   dynamic.
+
+   Managing the DDNS reverse updates is typically simple in the second
+   case, as the updated server is located at the local site, and
+   arguably IP address-based authentication could be sufficient (or if
+   not, setting up security relationships would be simpler).  As there
+   is an explicit (security) relationship between the parties in the
+   third case, setting up the security relationships to allow reverse
+   DDNS updates should be rather straightforward as well (but IP
+   address-based authentication might not be acceptable).  In the first
+   case, however, setting up and managing such relationships might be a
+   lot more difficult.
+
+8.  Miscellaneous DNS Considerations
+
+   This section describes miscellaneous considerations about DNS which
+   seem related to IPv6, for which no better place has been found in
+   this document.
+
+8.1  NAT-PT with DNS-ALG
+
+   The DNS-ALG component of NAT-PT mangles A records  to look like AAAA
+   records to the IPv6-only nodes.  Numerous problems have been
+   identified with DNS-ALG [I-D.ietf-v6ops-natpt-to-exprmntl].  This is
+   a strong reason not to use NAT-PT in the first place.
+
+8.2  Renumbering Procedures and Applications' Use of DNS
+
+   One of the most difficult problems of systematic IP address
+   renumbering procedures [I-D.ietf-v6ops-renumbering-procedure] is that
+   an application which looks up a DNS name disregards information such
+   as TTL, and uses the result obtained from DNS as long as it happens
+   to be stored in the memory of the application.  For applications
+   which run for a long time, this could be days, weeks or even months;
+   some applications may be clever enough to organize the data
+   structures and functions in such a manner that look-ups get refreshed
+   now and then.
+
+   While the issue appears to have a clear solution, "fix the
+   applications", practically this is not reasonable immediate advice;
+   the TTL information is not typically available in the APIs and
+   libraries (so, the advice becomes "fix the applications, APIs and
+   libraries"), and a lot more analysis is needed on how to practically
+
+
+
+Durand, et al.          Expires January 17, 2006               [Page 19]
+
+Internet-Draft        Considerations with IPv6 DNS             July 2005
+
+
+   go about to achieve the ultimate goal of avoiding using the names
+   longer than expected.
+
+9.  Acknowledgements
+
+   Some recommendations (Section 4.3, Section 5.1) about IPv6 service
+   provisioning were moved here from [I-D.ietf-v6ops-mech-v2] by Erik
+   Nordmark and Bob Gilligan.  Havard Eidnes and Michael Patton provided
+   useful feedback and improvements.  Scott Rose, Rob Austein, Masataka
+   Ohta, and Mark Andrews helped in clarifying the issues regarding
+   additional data and the use of TTL.  Jefsey Morfin, Ralph Droms,
+   Peter Koch, Jinmei Tatuya, Iljitsch van Beijnum, Edward Lewis, and
+   Rob Austein provided useful feedback during the WG last call.  Thomas
+   Narten provided extensive feedback during the IESG evaluation.
+
+10.  Security Considerations
+
+   This document reviews the operational procedures for IPv6 DNS
+   operations and does not have security considerations in itself.
+
+   However, it is worth noting that in particular with Dynamic DNS
+   Updates, security models based on the source address validation are
+   very weak and cannot be recommended -- they could only be considered
+   in the environments where ingress filtering [RFC3704] has been
+   deployed.  On the other hand, it should be noted that setting up an
+   authorization mechanism (e.g., a shared secret, or public-private
+   keys) between a node and the DNS server has to be done manually, and
+   may require quite a bit of time and expertise.
+
+   To re-emphasize what was already stated, the reverse+forward DNS
+   check provides very weak security at best, and the only
+   (questionable) security-related use for them may be in conjunction
+   with other mechanisms when authenticating a user.
+
+11.  References
+
+11.1  Normative References
+
+   [I-D.ietf-dnsop-ipv6-dns-configuration]
+              Jeong, J., "IPv6 Host Configuration of DNS Server
+              Information Approaches",
+              draft-ietf-dnsop-ipv6-dns-configuration-06 (work in
+              progress), May 2005.
+
+   [I-D.ietf-ipv6-unique-local-addr]
+              Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
+              Addresses", draft-ietf-ipv6-unique-local-addr-09 (work in
+              progress), January 2005.
+
+
+
+Durand, et al.          Expires January 17, 2006               [Page 20]
+
+Internet-Draft        Considerations with IPv6 DNS             July 2005
+
+
+   [I-D.ietf-v6ops-renumbering-procedure]
+              Baker, F., "Procedures for Renumbering an IPv6 Network
+              without a Flag Day",
+              draft-ietf-v6ops-renumbering-procedure-05 (work in
+              progress), March 2005.
+
+   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
+              STD 13, RFC 1034, November 1987.
+
+   [RFC2136]  Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
+              "Dynamic Updates in the Domain Name System (DNS UPDATE)",
+              RFC 2136, April 1997.
+
+   [RFC2181]  Elz, R. and R. Bush, "Clarifications to the DNS
+              Specification", RFC 2181, July 1997.
+
+   [RFC2182]  Elz, R., Bush, R., Bradner, S., and M. Patton, "Selection
+              and Operation of Secondary DNS Servers", BCP 16, RFC 2182,
+              July 1997.
+
+   [RFC2462]  Thomson, S. and T. Narten, "IPv6 Stateless Address
+              Autoconfiguration", RFC 2462, December 1998.
+
+   [RFC2671]  Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
+              RFC 2671, August 1999.
+
+   [RFC2821]  Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
+              April 2001.
+
+   [RFC3007]  Wellington, B., "Secure Domain Name System (DNS) Dynamic
+              Update", RFC 3007, November 2000.
+
+   [RFC3041]  Narten, T. and R. Draves, "Privacy Extensions for
+              Stateless Address Autoconfiguration in IPv6", RFC 3041,
+              January 2001.
+
+   [RFC3056]  Carpenter, B. and K. Moore, "Connection of IPv6 Domains
+              via IPv4 Clouds", RFC 3056, February 2001.
+
+   [RFC3152]  Bush, R., "Delegation of IP6.ARPA", BCP 49, RFC 3152,
+              August 2001.
+
+   [RFC3315]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
+              and M. Carney, "Dynamic Host Configuration Protocol for
+              IPv6 (DHCPv6)", RFC 3315, July 2003.
+
+   [RFC3363]  Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T.
+              Hain, "Representing Internet Protocol version 6 (IPv6)
+
+
+
+Durand, et al.          Expires January 17, 2006               [Page 21]
+
+Internet-Draft        Considerations with IPv6 DNS             July 2005
+
+
+              Addresses in the Domain Name System (DNS)", RFC 3363,
+              August 2002.
+
+   [RFC3364]  Austein, R., "Tradeoffs in Domain Name System (DNS)
+              Support for Internet Protocol version 6 (IPv6)", RFC 3364,
+              August 2002.
+
+   [RFC3513]  Hinden, R. and S. Deering, "Internet Protocol Version 6
+              (IPv6) Addressing Architecture", RFC 3513, April 2003.
+
+   [RFC3596]  Thomson, S., Huitema, C., Ksinant, V., and M. Souissi,
+              "DNS Extensions to Support IP Version 6", RFC 3596,
+              October 2003.
+
+   [RFC3646]  Droms, R., "DNS Configuration options for Dynamic Host
+              Configuration Protocol for IPv6 (DHCPv6)", RFC 3646,
+              December 2003.
+
+   [RFC3736]  Droms, R., "Stateless Dynamic Host Configuration Protocol
+              (DHCP) Service for IPv6", RFC 3736, April 2004.
+
+   [RFC3879]  Huitema, C. and B. Carpenter, "Deprecating Site Local
+              Addresses", RFC 3879, September 2004.
+
+   [RFC3901]  Durand, A. and J. Ihren, "DNS IPv6 Transport Operational
+              Guidelines", BCP 91, RFC 3901, September 2004.
+
+   [RFC4038]  Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E.
+              Castro, "Application Aspects of IPv6 Transition",
+              RFC 4038, March 2005.
+
+   [RFC4074]  Morishita, Y. and T. Jinmei, "Common Misbehavior Against
+              DNS Queries for IPv6 Addresses", RFC 4074, May 2005.
+
+11.2  Informative References
+
+   [I-D.durand-dnsop-dont-publish]
+              Durand, A. and T. Chown, "To publish, or not to publish,
+              that is the question.", draft-durand-dnsop-dont-publish-00
+              (work in progress), February 2005.
+
+   [I-D.huitema-v6ops-teredo]
+              Huitema, C., "Teredo: Tunneling IPv6 over UDP through
+              NATs", draft-huitema-v6ops-teredo-05 (work in progress),
+              April 2005.
+
+   [I-D.huston-6to4-reverse-dns]
+              Huston, G., "6to4 Reverse DNS Delegation",
+
+
+
+Durand, et al.          Expires January 17, 2006               [Page 22]
+
+Internet-Draft        Considerations with IPv6 DNS             July 2005
+
+
+              draft-huston-6to4-reverse-dns-03 (work in progress),
+              October 2004.
+
+   [I-D.ietf-dhc-ddns-resolution]
+              Stapp, M. and B. Volz, "Resolution of FQDN Conflicts among
+              DHCP Clients", draft-ietf-dhc-ddns-resolution-09 (work in
+              progress), June 2005.
+
+   [I-D.ietf-dhc-fqdn-option]
+              Stapp, M. and Y. Rekhter, "The DHCP Client FQDN Option",
+              draft-ietf-dhc-fqdn-option-10 (work in progress),
+              February 2005.
+
+   [I-D.ietf-dnsext-dhcid-rr]
+              Stapp, M., Lemon, T., and A. Gustafsson, "A DNS RR for
+              encoding DHCP information (DHCID RR)",
+              draft-ietf-dnsext-dhcid-rr-09 (work in progress),
+              February 2005.
+
+   [I-D.ietf-dnsop-bad-dns-res]
+              Larson, M. and P. Barber, "Observed DNS Resolution
+              Misbehavior", draft-ietf-dnsop-bad-dns-res-03 (work in
+              progress), October 2004.
+
+   [I-D.ietf-dnsop-inaddr-required]
+              Senie, D., "Encouraging the use of DNS IN-ADDR Mapping",
+              draft-ietf-dnsop-inaddr-required-06 (work in progress),
+              February 2005.
+
+   [I-D.ietf-v6ops-3gpp-analysis]
+              Wiljakka, J., "Analysis on IPv6 Transition in 3GPP
+              Networks", draft-ietf-v6ops-3gpp-analysis-11 (work in
+              progress), October 2004.
+
+   [I-D.ietf-v6ops-mech-v2]
+              Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
+              for IPv6 Hosts and Routers", draft-ietf-v6ops-mech-v2-07
+              (work in progress), March 2005.
+
+   [I-D.ietf-v6ops-natpt-to-exprmntl]
+              Aoun, C. and E. Davies, "Reasons to Move NAT-PT to
+              Experimental", draft-ietf-v6ops-natpt-to-exprmntl-01 (work
+              in progress), July 2005.
+
+   [I-D.ietf-v6ops-onlinkassumption]
+              Roy, S., "IPv6 Neighbor Discovery On-Link Assumption
+              Considered Harmful", draft-ietf-v6ops-onlinkassumption-03
+              (work in progress), May 2005.
+
+
+
+Durand, et al.          Expires January 17, 2006               [Page 23]
+
+Internet-Draft        Considerations with IPv6 DNS             July 2005
+
+
+   [I-D.ietf-v6ops-v6onbydefault]
+              Roy, S., Durand, A., and J. Paugh, "Issues with Dual Stack
+              IPv6 on by Default", draft-ietf-v6ops-v6onbydefault-03
+              (work in progress), July 2004.
+
+   [I-D.jeong-dnsop-ipv6-dns-discovery]
+              Jeong, J., "IPv6 DNS Configuration based on Router
+              Advertisement", draft-jeong-dnsop-ipv6-dns-discovery-04
+              (work in progress), February 2005.
+
+   [I-D.ohta-preconfigured-dns]
+              Ohta, M., "Preconfigured DNS Server Addresses",
+              draft-ohta-preconfigured-dns-01 (work in progress),
+              February 2004.
+
+   [RFC2766]  Tsirtsis, G. and P. Srisuresh, "Network Address
+              Translation - Protocol Translation (NAT-PT)", RFC 2766,
+              February 2000.
+
+   [RFC2782]  Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
+              specifying the location of services (DNS SRV)", RFC 2782,
+              February 2000.
+
+   [RFC2826]  Internet Architecture Board, "IAB Technical Comment on the
+              Unique DNS Root", RFC 2826, May 2000.
+
+   [RFC3704]  Baker, F. and P. Savola, "Ingress Filtering for Multihomed
+              Networks", BCP 84, RFC 3704, March 2004.
+
+   [RFC3972]  Aura, T., "Cryptographically Generated Addresses (CGA)",
+              RFC 3972, March 2005.
+
+   [RFC4025]  Richardson, M., "A Method for Storing IPsec Keying
+              Material in DNS", RFC 4025, March 2005.
+
+
+Authors' Addresses
+
+   Alain Durand
+   SUN Microsystems, Inc.
+   17 Network circle UMPL17-202
+   Menlo Park, CA  94025
+   USA
+
+   Email: Alain.Durand@sun.com
+
+
+
+
+
+
+Durand, et al.          Expires January 17, 2006               [Page 24]
+
+Internet-Draft        Considerations with IPv6 DNS             July 2005
+
+
+   Johan Ihren
+   Autonomica
+   Bellmansgatan 30
+   SE-118 47 Stockholm
+   Sweden
+
+   Email: johani@autonomica.se
+
+
+   Pekka Savola
+   CSC/FUNET
+   Espoo
+   Finland
+
+   Email: psavola@funet.fi
+
+Appendix A.  Unique Local Addressing Considerations for DNS
+
+   Unique local addresses [I-D.ietf-ipv6-unique-local-addr] have
+   replaced the now-deprecated site-local addresses [RFC3879].  From the
+   perspective of the DNS, the locally generated unique local addresses
+   (LUL) and site-local addresses have similar properties.
+
+   The interactions with DNS come in two flavors: forward and reverse
+   DNS.
+
+   To actually use local addresses within a site, this implies the
+   deployment of a "split-faced" or a fragmented DNS name space, for the
+   zones internal to the site, and the outsiders' view to it.  The
+   procedures to achieve this are not elaborated here.  The implication
+   is that local addresses must not be published in the public DNS.
+
+   To faciliate reverse DNS (if desired) with local addresses, the stub
+   resolvers must look for DNS information from the local DNS servers,
+   not e.g. starting from the root servers, so that the local
+   information may be provided locally.  Note that the experience of
+   private addresses in IPv4 has shown that the root servers get loaded
+   for requests for private address lookups in any case.  This
+   requirement is discussed in [I-D.ietf-ipv6-unique-local-addr].
+
+Appendix B.  Behaviour of Additional Data in IPv4/IPv6 Environments
+
+   DNS responses do not always fit in a single UDP packet.  We'll
+   examine the cases which happen when this is due to too much data in
+   the Additional Section.
+
+
+
+
+
+
+Durand, et al.          Expires January 17, 2006               [Page 25]
+
+Internet-Draft        Considerations with IPv6 DNS             July 2005
+
+
+B.1  Description of Additional Data Scenarios
+
+   There are two kinds of additional data:
+
+   1.  "critical" additional data; this must be included in all
+       scenarios, with all the RRsets, and
+
+   2.  "courtesy" additional data; this could be sent in full, with only
+       a few RRsets, or with no RRsets, and can be fetched separately as
+       well, but at the cost of additional queries.
+
+   The responding server can algorithmically determine which type the
+   additional data is by checking whether it's at or below a zone cut.
+
+   Only those additional data records (even if sometimes carelessly
+   termed "glue") are considered "critical" or real "glue" if and only
+   if they meet the abovementioned condition, as specified in Section
+   4.2.1 of [RFC1034].
+
+   Remember that resource record sets (RRsets) are never "broken up", so
+   if a name has 4 A records and 5 AAAA records, you can either return
+   all 9, all 4 A records, all 5 AAAA records or nothing.  In
+   particular, notice that for the "critical" additional data getting
+   all the RRsets can be critical.
+
+   In particular, [RFC2181] specifies (in Section 9) that:
+
+   a.  if all the "critical" RRsets do not fit, the sender should set
+       the TC bit, and the recipient should discard the whole response
+       and retry using mechanism allowing larger responses such as TCP.
+
+   b.  "courtesy" additional data should not cause the setting of TC
+       bit, but instead all the non-fitting additional data RRsets
+       should be removed.
+
+   An example of the "courtesy" additional data is A/AAAA records in
+   conjunction with MX records as shown in Section 4.4; an example of
+   the "critical" additional data is shown below (where getting both the
+   A and AAAA RRsets is critical w.r.t. to the NS RR):
+
+      child.example.com.    IN   NS ns.child.example.com.
+      ns.child.example.com. IN    A 192.0.2.1
+      ns.child.example.com. IN AAAA 2001:db8::1
+
+   When there is too much "courtesy" additional data, at least the non-
+   fitting RRsets should be removed [RFC2181]; however, as the
+   additional data is not critical, even all of it could be safely
+   removed.
+
+
+
+Durand, et al.          Expires January 17, 2006               [Page 26]
+
+Internet-Draft        Considerations with IPv6 DNS             July 2005
+
+
+   When there is too much "critical" additional data, TC bit will have
+   to be set, and the recipient should ignore the response and retry
+   using TCP; if some data were to be left in the UDP response, the
+   issue is which data could be retained.
+
+   Failing to discard the response with TC bit or omitting critical
+   information but not setting TC bit lead to an unrecoverable problem.
+   Omitting only some of the RRsets if all would not fit (but not
+   setting TC bit) leads to a performance problem.  These are discussed
+   in the next two subsections.
+
+B.2  Which Additional Data to Keep, If Any?
+
+   If the implementation decides to keep as much data (whether
+   "critical" or "courtesy") as possible in the UDP responses, it might
+   be tempting to use the transport of the DNS query as a hint in either
+   of these cases: return the AAAA records if the query was done over
+   IPv6, or return the A records if the query was done over IPv4.
+   However, this breaks the model of independence of DNS transport and
+   resource records, as noted in Section 1.2.
+
+   With courtesy additional data, as long as enough RRsets will be
+   removed so that TC will not be set, it is allowed to send as many
+   complete RRsets as the implementations prefers.  However, the
+   implementations are also free to omit all such RRsets, even if
+   complete.  Omitting all the RRsets (when removing only some would
+   suffice) may create a performance penalty, whereby the client may
+   need to issue one or more additional queries to obtain necessary
+   and/or consistent information.
+
+   With critical additional data, the alternatives are either returning
+   nothing (and absolutely requiring a retry with TCP) or returning
+   something (working also in the case if the recipient does not discard
+   the response and retry using TCP) in addition to setting the TC bit.
+   If the process for selecting "something" from the critical data would
+   otherwise be practically "flipping the coin" between A and AAAA
+   records, it could be argued that if one looked at the transport of
+   the query, it would have a larger possibility of being right than
+   just 50/50.  In other words, if the returned critical additional data
+   would have to be selected somehow, using something more sophisticated
+   than a random process would seem justifiable.
+
+   That is, leaving in some intelligently selected critical additional
+   data is a tradeoff between creating an optimization for those
+   resolvers which ignore the "should discard" recommendation, and
+   causing a protocol problem by propagating inconsistent information
+   about "critical" records in the caches.
+
+
+
+
+Durand, et al.          Expires January 17, 2006               [Page 27]
+
+Internet-Draft        Considerations with IPv6 DNS             July 2005
+
+
+   Similarly, leaving in the complete courtesy additional data RRsets
+   instead of removing all the RRsets is a performance tradeoff as
+   described in the next section.
+
+B.3  Discussion of the Potential Problems
+
+   As noted above, the temptation for omitting only some of the
+   additional data could be problematic.  This is discussed more below.
+
+   For courtesy additional data, this causes a potential performance
+   problem as this requires that the clients issue re-queries for the
+   potentially omitted RRsets.  For critical additional data, this
+   causes a potential unrecoverable problem if the response is not
+   discarded and the query not re-tried with TCP, as the nameservers
+   might be reachable only through the omitted RRsets.
+
+   If an implementation would look at the transport used for the query,
+   it is worth remembering that often the host using the records is
+   different from the node requesting them from the authoritative DNS
+   server (or even a caching resolver).  So, whichever version the
+   requestor (e.g., a recursive server in the middle) uses makes no
+   difference to the ultimate user of the records, whose transport
+   capabilities might differ from those of the requestor.  This might
+   result in e.g., inappropriately returning A records to an IPv6-only
+   node, going through a translation, or opening up another IP-level
+   session (e.g., a PDP context [I-D.ietf-v6ops-3gpp-analysis]).
+   Therefore, at least in many scenarios, it would be very useful if the
+   information returned would be consistent and complete -- or if that
+   is not feasible, return no misleading information but rather leave it
+   to the client to query again.
+
+   The problem of too much additional data seems to be an operational
+   one: the zone administrator entering too many records which will be
+   returned either truncated (or missing some RRsets, depending on
+   implementations) to the users.  A protocol fix for this is using
+   EDNS0 [RFC2671] to signal the capacity for larger UDP packet sizes,
+   pushing up the relevant threshold.  Further, DNS server
+   implementations should rather omit courtesy additional data
+   completely rather than including only some RRsets [RFC2181].  An
+   operational fix for this is having the DNS server implementations
+   return a warning when the administrators create zones which would
+   result in too much additional data being returned.  Further, DNS
+   server implementations should warn of or disallow such zone
+   configurations which are recursive or otherwise difficult to manage
+   by the protocol.
+
+   Additionally, to avoid the case where an application would not get an
+   address at all due to some of courtesy additional data being omitted,
+
+
+
+Durand, et al.          Expires January 17, 2006               [Page 28]
+
+Internet-Draft        Considerations with IPv6 DNS             July 2005
+
+
+   the resolvers should be able to query the specific records of the
+   desired protocol, not just rely on getting all the required RRsets in
+   the additional section.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Durand, et al.          Expires January 17, 2006               [Page 29]
+
+Internet-Draft        Considerations with IPv6 DNS             July 2005
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2005).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Durand, et al.          Expires January 17, 2006               [Page 30]
+
+
diff --git a/doc/draft/draft-ietf-dnsop-ipv6-transport-guidelines-01.txt b/doc/draft/draft-ietf-dnsop-ipv6-transport-guidelines-01.txt
new file mode 100644
index 0000000..b2e2341
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsop-ipv6-transport-guidelines-01.txt
@@ -0,0 +1,300 @@
+Internet Engineering Task Force                         A.Durand
+INTERNET-DRAFT                             SUN Microsystems,inc.
+November, 24, 2003                                      J. Ihren
+Expires May 25, 2004                                  Autonomica
+
+
+               DNS IPv6 transport operational guidelines
+          <draft-ietf-dnsop-ipv6-transport-guidelines-01.txt>
+
+
+
+Status of this Memo
+
+   This memo provides information to the Internet community. It does not
+   specify an Internet standard of any kind. This memo is in full
+   conformance with all provisions of Section 10 of RFC2026
+
+   Internet-Drafts are draft documents 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 "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/1id-abstracts.html
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html
+
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2003).  All Rights Reserved.
+
+
+Abstract
+
+   This memo provides guidelines and Best Current Practice to operate
+   DNS in a world where queries and responses are carried in a mixed
+   environment of IPv4 and IPv6 networks.
+
+
+Acknowledgment
+
+   This document is the result of many conversations that happened in
+   the DNS community at IETF and elsewhere since 2001. During that
+   period of time, a number of Internet drafts have been published to
+   clarify various aspects of the issues at stake. This document focuses
+   on the conclusion of those discussions.
+
+   The authors would like to acknowledge the role of Pekka Savola in his
+   thorough review of the document.
+
+
+1. Terminology
+
+   The phrase "IPv4 name server" indicates a name server available over
+   IPv4 transport. It does not imply anything about what DNS data is
+   served. Likewise, "IPv6 name server" indicates a name server
+   available over IPv6 transport. The phrase "dual-stack DNS server"
+   indicates a DNS server that is actually configured to run both
+   protocols, IPv4 and IPv6, and not merely a server running on a system
+   capable of running both but actually configured to run only one.
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [2119].
+
+
+2. Introduction to the Problem of Name Space Fragmentation:
+     following the referral chain
+
+   The caching resolver that tries to look up a name starts out at the
+   root, and follows referrals until it is referred to a nameserver that
+   is authoritative for the name.  If somewhere down the chain of
+   referrals it is referred to a nameserver that is only accessible over
+   an unavailable type of transport, a traditional nameserver is unable
+   to finish the task.
+
+   When the Internet moves from IPv4 to a mixture of IPv4 and IPv6 it is
+   only a matter of time until this starts to happen. The complete DNS
+   hierarchy then starts to fragment into a graph where authoritative
+   nameservers for certain nodes are only accessible over a certain
+   transport. What is feared is that a node using only a particular
+   version of IP, querying information about another node using the same
+   version of IP can not do it because, somewhere in the chain of
+   servers accessed during the resolution process, one or more of them
+   will only be accessible with the other version of IP.
+
+   With all DNS data only available over IPv4 transport everything is
+   simple. IPv4 resolvers can use the intended mechanism of following
+   referrals from the root and down while IPv6 resolvers have to work
+   through a "translator", i.e. they have to use a second name server on
+   a so-called "dual stack" host as a "forwarder" since they cannot
+   access the DNS data directly.
+
+   With all DNS data only available over IPv6 transport everything would
+   be equally simple, with the exception of old legacy IPv4 name servers
+   having to switch to a forwarding configuration.
+
+   However, the second situation will not arise in a foreseeable time.
+   Instead, it is expected that the transition will be from IPv4 only to
+   a mixture of IPv4 and IPv6, with DNS data of theoretically three
+   categories depending on whether it is available only over IPv4
+   transport, only over IPv6 or both.
+
+   Having DNS data available on both transports is the best situation.
+   The major question is how to ensure that it as quickly as possible
+   becomes the norm. However, while it is obvious that some DNS data
+   will only be available over v4 transport for a long time it is also
+   obvious that it is important to avoid fragmenting the name space
+   available to IPv4 only hosts. I.e. during transition it is not
+   acceptable to break the name space that we presently have available
+   for IPv4-only hosts.
+
+
+3. Policy Based Avoidance of Name Space Fragmentation
+
+   Today there are only a few DNS "zones" on the public Internet that
+   are  available over IPv6 transport, and most of them can be regarded
+   as "experimental". However, as soon as the root and top level domains
+   are available over IPv6 transport, it is reasonable to expect that it
+   will become more common to have zones served by IPv6 servers.
+
+   Having those zones served only by IPv6-only name server would not be
+   a good development, since this will fragment the previously
+   unfragmented IPv4 name space and there are strong reasons to find a
+   mechanism to avoid it.
+
+   The RECOMMENDED approach to maintain name space continuity is to use
+   administrative policies, as described in the next section.
+
+
+4. DNS IPv6 Transport RECOMMENDED Guidelines
+
+   In order to preserve name space continuity, the following administrative
+   policies are RECOMMENDED:
+      - every recursive DNS server SHOULD be either IPv4-only or dual
+      stack,
+      - every single DNS zone SHOULD be served by at least one IPv4
+      reachable DNS server.
+
+   This rules out IPv6-only DNS servers performing full recursion and
+   DNS zones served only by IPv6-only DNS servers.  However, one could
+   very well design a configuration where a chain of IPv6 only DNS
+   servers forward queries to a set of dual stack DNS servers actually
+   performing those recursive queries.  This approach could be revisited
+   if/when translation techniques between IPv4 and IPv6 were to be
+   widely deployed.
+
+   In order to help enforcing the second point, the optional operational
+   zone validation processes SHOULD ensure that there is at least one
+   IPv4 address record available for the name servers of any child
+   delegations within the zone.
+
+
+5. Security Considerations
+
+   Being a critical piece of the Internet infrastructure, the DNS is a
+   potential value target and thus should be protected.  Great care
+   should be taken not to weaken the security of DNS while introducing
+   IPv6 operation.
+
+   Keeping the DNS name space from fragmenting is a critical thing for
+   the availability and the operation of the Internet; this memo
+   addresses this issue by clear and simple operational guidelines.
+
+   The RECOMMENDED guidelines are compatible with the operation of
+   DNSSEC and do not introduce any new security issues.
+
+
+6. Author Addresses
+
+   Alain Durand
+   SUN Microsystems, Inc
+   17 Network circle UMPK17-202
+   Menlo Park, CA, 94025
+   USA
+   Mail: Alain.Durand@sun.com
+
+   Johan Ihren
+   Autonomica
+   Bellmansgatan 30
+   SE-118 47 Stockholm, Sweden
+   Mail: johani@autonomica.se
+
+
+7. Normative References
+
+   [2119]  Bradner, S., "Key Words for Use in RFCs to Indicate
+           Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+
+8. Full Copyright Statement
+
+   "Copyright (C) The Internet Society (2003).  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 Standards process must be
+   followed, or as required to translate it into 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.
+
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/doc/draft/draft-ietf-dnsop-key-rollover-requirements-02.txt b/doc/draft/draft-ietf-dnsop-key-rollover-requirements-02.txt
new file mode 100644
index 0000000..6bece56
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsop-key-rollover-requirements-02.txt
@@ -0,0 +1,389 @@
+
+DNSOP                                                          G. Guette
+Internet-Draft                                             IRISA / INRIA
+Expires: July 19, 2005                                        O. Courtay
+                                                             Thomson R&D
+                                                        January 18, 2005
+
+           Requirements for Automated Key Rollover in DNSSEC
+           draft-ietf-dnsop-key-rollover-requirements-02.txt
+
+Status of this Memo
+
+   By submitting this Internet-Draft, I certify that any applicable 
+   patent or other IPR claims of which I am aware have been disclosed, 
+   and any of which I become aware will be disclosed, in accordance with 
+   RFC 3668.  
+
+   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 draft documents 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 "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/ietf/1id-abstracts.txt.
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+   This Internet-Draft will expire on July 19, 2005.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).  All Rights Reserved.
+
+Abstract
+
+   This document describes problems that appear during an automated
+   rollover and gives the requirements for the design of communication
+   between parent zone and child zone during an automated rollover
+   process.  This document is essentially about in-band key rollover.
+
+
+
+
+Guette & Courtay         Expires July 19, 2005                  [Page 1]
+Internet-Draft      Automated Rollover Requirements         January 2005
+
+Table of Contents
+
+   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
+   2.   The Key Rollover Process . . . . . . . . . . . . . . . . . . . 3
+   3.   Basic Requirements . . . . . . . . . . . . . . . . . . . . . . 4
+   4.   Messages authentication and information exchanged  . . . . . . 5
+   5.   Emergency Rollover . . . . . . . . . . . . . . . . . . . . . . 5
+   6.   Security consideration . . . . . . . . . . . . . . . . . . . . 6
+   7.   Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 6
+   8.   Normative References . . . . . . . . . . . . . . . . . . . . . 6
+        Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 7
+   A.   Documents details and changes  . . . . . . . . . . . . . . . . 7
+        Intellectual Property and Copyright Statements . . . . . . . . 8
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Guette & Courtay         Expires July 19, 2005                  [Page 2]
+Internet-Draft      Automated Rollover Requirements         January 2005
+
+1.  Introduction
+
+   The DNS security extensions (DNSSEC) [4][6][5][7] uses public-key
+   cryptography and digital signatures.  It stores the public part of
+   keys in DNSKEY Resource Records (RRs).  Because old keys and
+   frequently used keys are vulnerable, they must be renewed
+   periodically.  In DNSSEC, this is the case for Zone Signing Keys
+   (ZSKs) and Key Signing Keys (KSKs) [1][2].  Automation of key
+   exchanges between parents and children is necessary for large zones
+   because there are too many changes to handle.
+
+   Let us consider for example a zone with 100000 secure delegations.
+   If the child zones change their keys once a year on average, that
+   implies 300 changes per day for the parent zone.  This amount of
+   changes is hard to manage manually.
+
+   Automated rollover is optional and resulting from an agreement
+   between the administrator of the parent zone and the administrator of
+   the child zone.  Of course, key rollover can also be done manually by
+   administrators.
+
+   This document describes the requirements for a protocol to perform
+   the automated key rollover process and focusses on interaction
+   between parent and child zone.
+
+2.  The Key Rollover Process
+
+   Key rollover consists of renewing the DNSSEC keys used to sign
+   resource records in a given DNS zone file.  There are two types of
+   rollover, ZSK rollovers and KSK rollovers.
+
+   During a ZSK rollover, all changes are local to the zone that renews
+   its key: there is no need to contact other zones administrators to
+   propagate the performed changes because a ZSK has no associated DS
+   record in the parent zone.
+
+   During a KSK rollover, new DS RR(s) must be created and stored in the
+   parent zone.  In consequence, data must be exchanged between child
+   and parent zones.
+
+   The key rollover is built from two parts of different nature:
+   o  An algorithm that generates new keys and signs the zone file.  It
+      can be local to the zone,
+   o  the interaction between parent and child zones.
+
+   One example of manual key rollover [3] is:
+   o  The child zone creates a new KSK,
+
+
+Guette & Courtay         Expires July 19, 2005                  [Page 3]
+Internet-Draft      Automated Rollover Requirements         January 2005
+
+   o  the child zone waits for the creation of the DS RR in its parent
+      zone,
+   o  the child zone deletes the old key,
+   o  the parent zone deletes the old DS RR.
+
+   This document concentrates on defining interactions between entities
+   present in key rollover process.
+
+3.  Basic Requirements
+
+   This section provides the requirements for automated key rollover in
+   case of normal use.  Exceptional case like emergency rollover is
+   specifically described later in this document.
+
+   The main condition during a key rollover is that the chain of trust
+   must be preserved to every validating DNS client.  No matter if this
+   client retrieves some of the RRs from recursive caching name server
+   or from the authoritative servers for the zone involved in the
+   rollover.
+
+   Automated key rollover solution may be interrupted by a manual
+   intervention.  This manual intervention should not compromise the
+   security state of the chain of trust.  If the chain is safe before
+   the manual intervention, the chain of trust must remain safe during
+   and after the manual intervention
+
+   Two entities act during a KSK rollover: the child zone and its parent
+   zone.  These zones are generally managed by different administrators.
+   These administrators should agree on some parameters like
+   availability of automated rollover, the maximum delay between
+   notification of changes in the child zone and the resigning of the
+   parent zone.  The child zone needs to know this delay to schedule its
+   changes and/or to verify that the changes had been taken into account
+   in the parent zone.  Hence, the child zone can also avoid some
+   critical cases where all child key are changed prior to the DS RR
+   creation.
+
+   By keeping some resource records during a given time, the recursive
+   cache servers can act on the automated rollover.  The existence of
+   recursive cache servers must be taken into account by automated
+   rollover solution.
+
+   Indeed, during an automated key rollover a name server could have to
+   retrieve some DNSSEC data.  An automated key rollover solution must
+   ensure that these data are not old DNSSEC material retrieved from a
+   recursive name server.
+
+
+
+Guette & Courtay         Expires July 19, 2005                  [Page 4]
+Internet-Draft      Automated Rollover Requirements         January 2005
+
+4.  Messages authentication and information exchanged
+
+   This section addresses in-band rollover, security of out-of-band
+   mechanisms is out of scope of this document.
+
+   The security provided by DNSSEC must not be compromised by the key
+   rollover, thus every exchanged message must be authenticated to avoid
+   fake rollover messages from malicious parties.
+
+   Once the changes related to a KSK are made in a child zone, there are
+   two ways for the parent zone to take this changes into account:
+   o  the child zone notify directly or not directly its parent zone in
+      order to create the new DS RR and store this DS RR in parent zone
+      file,
+   o  or the parent zone poll the child zone.
+
+   In both cases, the parent zone must receive all the child keys that
+   need the creation of associated DS RRs in the parent zone.
+
+   Because errors could occur during the transmission of keys between
+   child and parent, the key exchange protocol must be fault tolerant.
+   Should an error occured during the automated key rollover, an
+   automated key rollover solution must be able to keep the zone files
+   in a consistent state.
+
+5.  Emergency Rollover
+
+   Emergency key rollover is a special case of rollover decided by the
+   zone administrator generally for security reasons.  In consequence,
+   emergency key rollover can break some of the requirement described
+   above.
+
+   A zone key might be compromised and an attacker can use the
+   compromised key to create and sign fake records.  To avoid this, the
+   zone administrator may change the compromised key or all its keys as
+   soon as possible, without waiting for the creation of new DS RRs in
+   its parent zone.
+
+   Fast changes may break the chain of trust.  The part of DNS tree
+   having this zone as apex can become unverifiable, but the break of
+   the chain of trust is necessary if the administrator wants to prevent
+   the compromised key from being used (to spoof DNS data).
+
+   Parent and child zones sharing an automated rollover mechanism,
+   should have an out-of-band way to re-establish a consistent state at
+   the delegation point (DS and DNSKEY RRs).  This allows to avoid that
+   a malicious party uses the compromised key to roll the zone keys.
+
+
+Guette & Courtay         Expires July 19, 2005                  [Page 5]
+Internet-Draft      Automated Rollover Requirements         January 2005
+
+6.  Security consideration
+
+   The automated key rollover process in DNSSEC allows automated renewal
+   of any kind of DNS key (ZSK or KSK).  It is essential that parent
+   side and child side can do mutual authentication.  Moreover,
+   integrity of the material exchanged between the parent and child zone
+   must be provided to ensure the right DS are created.
+
+   As in any application using public key cryptography, in DNSSEC a key
+   may be compromised.  What to do in such a case can be describe in the
+   zone local policy and can violate some requirements described in this
+   draft.  The emergency rollover can break the chain of trust in order
+   to protect the zone against the use of the compromised key.
+
+7.  Acknowledgments
+
+   The authors want to thank members of IDsA project for their
+   contribution to this document.
+
+8  Normative References
+
+   [1]  Gudmundsson, O., "Delegation Signer (DS) Resource Record (RR)",
+        RFC 3658, December 2003.
+
+   [2]  Kolkman, O., Schlyter, J. and E. Lewis, "Domain Name System KEY
+        (DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag",
+        RFC 3757, May 2004.
+
+   [3]  Kolkman, O., "DNSSEC Operational Practices",
+        draft-ietf-dnsop-dnssec-operational-practice-01 (work in
+        progress), May 2004.
+
+   [4]  Eastlake, D., "Domain Name System Security Extensions", RFC
+        2535, March 1999.
+
+   [5]  Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose,
+        "Resource Records for the DNS Security Extensions",
+        draft-ietf-dnsext-dnssec-records-11 (work in progress), October
+        2004.
+
+   [6]  Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose,
+        "DNS Security Introduction and Requirements",
+        draft-ietf-dnsext-dnssec-intro-13 (work in progress), October
+        2004.
+
+   [7]  Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose,
+        "Protocol Modifications for the DNS Security Extensions",
+        draft-ietf-dnsext-dnssec-protocol-09 (work in progress), October
+
+
+Guette & Courtay         Expires July 19, 2005                  [Page 6]
+Internet-Draft      Automated Rollover Requirements         January 2005
+
+        2004.
+
+Authors' Addresses
+
+   Gilles Guette
+   IRISA / INRIA
+   Campus de Beaulieu
+   35042  Rennes CEDEX
+   FR
+
+   EMail: gilles.guette@irisa.fr
+   URI:   http://www.irisa.fr
+
+   Olivier Courtay
+   Thomson R&D
+   1, avenue Belle Fontaine
+   35510  Cesson S?vign? CEDEX
+   FR
+
+   EMail: olivier.courtay@thomson.net
+
+Appendix A.  Documents details and changes
+
+   This section is to be removed by the RFC editor if and when the
+   document is published.
+
+   Section about NS RR rollover has been removed
+
+   Remarks from Samuel Weiler and Rip Loomis added
+
+   Clarification about in-band rollover and in emergency section
+
+   Section 3, details about recursive cache servers added
+
+
+
+
+
+
+
+
+Guette & Courtay         Expires July 19, 2005                  [Page 7]
+Internet-Draft      Automated Rollover Requirements         January 2005
+
+Intellectual Property Statement
+
+     The IETF takes no position regarding the validity or scope of any 
+     intellectual property or other rights that might be claimed to 
+     pertain to the implementation or use of the technology described 
+     in this document or the extent to which any license under such 
+     rights might or might not be available; neither does it represent 
+     that it has made any effort to identify any such rights. 
+     Information on the IETF's procedures with respect to rights in 
+     IETF Documents can be found in BCP 78 and 79.   
+          
+     Copies of IPR disclosures made to the IETF Secretariat and any 
+     assurances of licenses to be made available, or the result of an 
+     attempt made to obtain a general license or permission for the use 
+     of such proprietary rights by implementers or users of this 
+     specification can be obtained from the IETF on-line IPR repository 
+     at http://www.ietf.org/ipr. 
+      
+     The IETF invites any interested party to bring to its attention 
+     any copyrights, patents or patent applications, or other 
+     proprietary rights which may cover technology that may be required 
+     to implement this standard. Please address the information to the 
+     IETF at ietf-ipr.org. 
+      
+    
+ Full Copyright Statement 
+    
+   Copyright (C) The Internet Society (2005).  This document is subject 
+   to the rights, licenses and restrictions contained in BCP 78, and 
+   except as set forth therein, the authors retain all their rights. 
+    
+   This document and the information contained herein are provided on an 
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+ Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+         
+
+
+Guette & Courtay         Expires July 19, 2005                  [Page 8]
diff --git a/doc/draft/draft-ietf-dnsop-respsize-02.txt b/doc/draft/draft-ietf-dnsop-respsize-02.txt
new file mode 100644
index 0000000..63fe2de
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsop-respsize-02.txt
@@ -0,0 +1,480 @@
+
+
+
+
+
+
+   DNSOP Working Group                                     Paul Vixie, ISC
+   INTERNET-DRAFT                                         Akira Kato, WIDE
+   <draft-ietf-dnsop-respsize-02.txt>                            July 2005
+
+                           DNS Response Size Issues
+
+   Status of this Memo
+      By submitting this Internet-Draft, each author represents that any
+      applicable patent or other IPR claims of which he or she is aware
+      have been or will be disclosed, and any of which he or she becomes
+      aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+      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 draft documents 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 "work in progress."
+
+      The list of current Internet-Drafts can be accessed at
+      http://www.ietf.org/ietf/1id-abstracts.txt
+
+      The list of Internet-Draft Shadow Directories can be accessed at
+      http://www.ietf.org/shadow.html.
+
+   Copyright Notice
+
+      Copyright (C) The Internet Society (2005).  All Rights Reserved.
+
+
+
+
+                                    Abstract
+
+      With a mandated default minimum maximum message size of 512 octets,
+      the DNS protocol presents some special problems for zones wishing to
+      expose a moderate or high number of authority servers (NS RRs).  This
+      document explains the operational issues caused by, or related to
+      this response size limit.
+
+
+
+
+
+
+   Expires December 2005                                           [Page 1]
+
+   INTERNET-DRAFT                  July 2005                       RESPSIZE
+
+
+   1 - Introduction and Overview
+
+   1.1. The DNS standard (see [RFC1035 4.2.1]) limits message size to 512
+   octets.  Even though this limitation was due to the required minimum UDP
+   reassembly limit for IPv4, it is a hard DNS protocol limit and is not
+   implicitly relaxed by changes in transport, for example to IPv6.
+
+   1.2. The EDNS0 standard (see [RFC2671 2.3, 4.5]) permits larger
+   responses by mutual agreement of the requestor and responder.  However,
+   deployment of EDNS0 cannot be expected to reach every Internet resolver
+   in the short or medium term.  The 512 octet message size limit remains
+   in practical effect at this time.
+
+   1.3. Since DNS responses include a copy of the request, the space
+   available for response data is somewhat less than the full 512 octets.
+   For negative responses, there is rarely a space constraint.  For
+   positive and delegation responses, though, every octet must be carefully
+   and sparingly allocated.  This document specifically addresses
+   delegation response sizes.
+
+   2 - Delegation Details
+
+   2.1. A delegation response will include the following elements:
+
+      Header Section: fixed length (12 octets)
+      Question Section: original query (name, class, type)
+      Answer Section: (empty)
+      Authority Section: NS RRset (nameserver names)
+      Additional Section: A and AAAA RRsets (nameserver addresses)
+
+   2.2. If the total response size would exceed 512 octets, and if the data
+   that would not fit belonged in the question, answer, or authority
+   section, then the TC bit will be set (indicating truncation) which may
+   cause the requestor to retry using TCP, depending on what information
+   was desired and what information was omitted.  If a retry using TCP is
+   needed, the total cost of the transaction is much higher.  (See [RFC1123
+   6.1.3.2] for details on the protocol requirement that UDP be attempted
+   before falling back to TCP.)
+
+   2.3. RRsets are never sent partially unless truncation occurs, in which
+   case the final apparent RRset in the final nonempty section must be
+   considered "possibly damaged".  With or without truncation, the glue
+   present in the additional data section should be considered "possibly
+   incomplete", and requestors should be prepared to re-query for any
+   damaged or missing RRsets.  For multi-transport name or mail services,
+
+
+
+   Expires December 2005                                           [Page 2]
+
+   INTERNET-DRAFT                  July 2005                       RESPSIZE
+
+
+   this can mean querying for an IPv6 (AAAA) RRset even when an IPv4 (A)
+   RRset is present.
+
+   2.4. DNS label compression allows a domain name to be instantiated only
+   once per DNS message, and then referenced with a two-octet "pointer"
+   from other locations in that same DNS message.  If all nameserver names
+   in a message are similar (for example, all ending in ".ROOT-
+   SERVERS.NET"), then more space will be available for uncompressable data
+   (such as nameserver addresses).
+
+   2.5. The query name can be as long as 255 characters of presentation
+   data, which can be up to 256 octets of network data.  In this worst case
+   scenario, the question section will be 260 octets in size, which would
+   leave only 240 octets for the authority and additional sections (after
+   deducting 12 octets for the fixed length header.)
+
+   2.6. Average and maximum question section sizes can be predicted by the
+   zone owner, since they will know what names actually exist, and can
+   measure which ones are queried for most often.  For cost and performance
+   reasons, the majority of requests should be satisfied without truncation
+   or TCP retry.
+
+   2.7. Requestors who deliberately send large queries to force truncation
+   are only increasing their own costs, and cannot effectively attack the
+   resources of an authority server since the requestor would have to retry
+   using TCP to complete the attack.  An attack that always used TCP would
+   have a lower cost.
+
+   2.8. The minimum useful number of address records is two, since with
+   only one address, the probability that it would refer to an unreachable
+   server is too high.  Truncation which occurs after two address records
+   have been added to the additional data section is therefore less
+   operationally significant than truncation which occurs earlier.
+
+   2.9. The best case is no truncation.  This is because many requestors
+   will retry using TCP by reflex, or will automatically re-query for
+   RRsets that are "possibly truncated", without considering whether the
+   omitted data was actually necessary.
+
+   2.10. Each added NS RR for a zone will add a minimum of between 16 and
+   44 octets to every untruncated referral or negative response from the
+   zone's authority servers (16 octets for an NS RR, 16 octets for an A RR,
+   and 28 octets for an AAAA RR), in addition to whatever space is taken by
+   the nameserver name (NS NSDNAME and A/AAAA owner name).
+
+
+
+
+   Expires December 2005                                           [Page 3]
+
+   INTERNET-DRAFT                  July 2005                       RESPSIZE
+
+
+   3 - Analysis
+
+   3.1. An instrumented protocol trace of a best case delegation response
+   follows.  Note that 13 servers are named, and 13 addresses are given.
+   This query was artificially designed to exactly reach the 512 octet
+   limit.
+
+      ;; flags: qr rd; QUERY: 1, ANS: 0, AUTH: 13, ADDIT: 13
+      ;; QUERY SECTION:
+      ;;  [23456789.123456789.123456789.\
+           123456789.123456789.123456789.com A IN]        ;; @80
+
+      ;; AUTHORITY SECTION:
+      com.                 86400 NS  E.GTLD-SERVERS.NET.  ;; @112
+      com.                 86400 NS  F.GTLD-SERVERS.NET.  ;; @128
+      com.                 86400 NS  G.GTLD-SERVERS.NET.  ;; @144
+      com.                 86400 NS  H.GTLD-SERVERS.NET.  ;; @160
+      com.                 86400 NS  I.GTLD-SERVERS.NET.  ;; @176
+      com.                 86400 NS  J.GTLD-SERVERS.NET.  ;; @192
+      com.                 86400 NS  K.GTLD-SERVERS.NET.  ;; @208
+      com.                 86400 NS  L.GTLD-SERVERS.NET.  ;; @224
+      com.                 86400 NS  M.GTLD-SERVERS.NET.  ;; @240
+      com.                 86400 NS  A.GTLD-SERVERS.NET.  ;; @256
+      com.                 86400 NS  B.GTLD-SERVERS.NET.  ;; @272
+      com.                 86400 NS  C.GTLD-SERVERS.NET.  ;; @288
+      com.                 86400 NS  D.GTLD-SERVERS.NET.  ;; @304
+
+      ;; ADDITIONAL SECTION:
+      A.GTLD-SERVERS.NET.  86400 A   192.5.6.30           ;; @320
+      B.GTLD-SERVERS.NET.  86400 A   192.33.14.30         ;; @336
+      C.GTLD-SERVERS.NET.  86400 A   192.26.92.30         ;; @352
+      D.GTLD-SERVERS.NET.  86400 A   192.31.80.30         ;; @368
+      E.GTLD-SERVERS.NET.  86400 A   192.12.94.30         ;; @384
+      F.GTLD-SERVERS.NET.  86400 A   192.35.51.30         ;; @400
+      G.GTLD-SERVERS.NET.  86400 A   192.42.93.30         ;; @416
+      H.GTLD-SERVERS.NET.  86400 A   192.54.112.30        ;; @432
+      I.GTLD-SERVERS.NET.  86400 A   192.43.172.30        ;; @448
+      J.GTLD-SERVERS.NET.  86400 A   192.48.79.30         ;; @464
+      K.GTLD-SERVERS.NET.  86400 A   192.52.178.30        ;; @480
+      L.GTLD-SERVERS.NET.  86400 A   192.41.162.30        ;; @496
+      M.GTLD-SERVERS.NET.  86400 A   192.55.83.30         ;; @512
+
+      ;; MSG SIZE  sent: 80  rcvd: 512
+
+
+
+
+
+   Expires December 2005                                           [Page 4]
+
+   INTERNET-DRAFT                  July 2005                       RESPSIZE
+
+
+   3.2. For longer query names, the number of address records supplied will
+   be lower.  Furthermore, it is only by using a common parent name (which
+   is GTLD-SERVERS.NET in this example) that all 13 addresses are able to
+   fit.  The following output from a response simulator demonstrates these
+   properties:
+
+      % perl respsize.pl a.dns.br b.dns.br c.dns.br d.dns.br
+      a.dns.br requires 10 bytes
+      b.dns.br requires 4 bytes
+      c.dns.br requires 4 bytes
+      d.dns.br requires 4 bytes
+      # of NS: 4
+      For maximum size query (255 byte):
+              if only A is considered:     # of A is 4 (green)
+              if A and AAAA are condered:  # of A+AAAA is 3 (yellow)
+              if prefer_glue A is assumed: # of A is 4, # of AAAA is 3 (yellow)
+      For average size query (64 byte):
+              if only A is considered:     # of A is 4 (green)
+              if A and AAAA are condered:  # of A+AAAA is 4 (green)
+              if prefer_glue A is assumed: # of A is 4, # of AAAA is 4 (green)
+
+      % perl respsize.pl ns-ext.isc.org ns.psg.com ns.ripe.net ns.eu.int
+      ns-ext.isc.org requires 16 bytes
+      ns.psg.com requires 12 bytes
+      ns.ripe.net requires 13 bytes
+      ns.eu.int requires 11 bytes
+      # of NS: 4
+      For maximum size query (255 byte):
+              if only A is considered:     # of A is 4 (green)
+              if A and AAAA are condered:  # of A+AAAA is 3 (yellow)
+              if prefer_glue A is assumed: # of A is 4, # of AAAA is 2 (yellow)
+      For average size query (64 byte):
+              if only A is considered:     # of A is 4 (green)
+              if A and AAAA are condered:  # of A+AAAA is 4 (green)
+              if prefer_glue A is assumed: # of A is 4, # of AAAA is 4 (green)
+
+   (Note: The response simulator program is shown in Section 5.)
+
+   Here we use the term "green" if all address records could fit, or
+   "orange" if two or more could fit, or "red" if fewer than two could fit.
+   It's clear that without a common parent for nameserver names, much space
+   would be lost.  For these examples we use an average/common name size of
+   15 octets, befitting our assumption of GTLD-SERVERS.NET as our common
+   parent name.
+
+
+
+
+   Expires December 2005                                           [Page 5]
+
+   INTERNET-DRAFT                  July 2005                       RESPSIZE
+
+
+   We're assuming an average query name size of 64 since that is the
+   typical average maximum size seen in trace data at the time of this
+   writing.  If Internationalized Domain Name (IDN) or any other technology
+   which results in larger query names be deployed significantly in advance
+   of EDNS, then new measurements and new estimates will have to be made.
+
+   4 - Conclusions
+
+   4.1. The current practice of giving all nameserver names a common parent
+   (such as GTLD-SERVERS.NET or ROOT-SERVERS.NET) saves space in DNS
+   responses and allows for more nameservers to be enumerated than would
+   otherwise be possible.  (Note that in this case it is wise to serve the
+   common parent domain's zone from the same servers that are named within
+   it, in order to limit external dependencies when all your eggs are in a
+   single basket.)
+
+   4.2. Thirteen (13) seems to be the effective maximum number of
+   nameserver names usable traditional (non-extended) DNS, assuming a
+   common parent domain name, and given that response truncation is
+   undesirable as an average case, and assuming mostly IPv4-only
+   reachability (only A RRs exist, not AAAA RRs).
+
+   4.3. Adding two to five IPv6 nameserver address records (AAAA RRs) to a
+   prototypical delegation that currently contains thirteen (13) IPv4
+   nameserver addresses (A RRs) for thirteen (13) nameserver names under a
+   common parent, would not have a significant negative operational impact
+   on the domain name system.
+
+   5 - Source Code
+
+   #!/usr/bin/perl
+   #
+   # SYNOPSIS
+   #    repsize.pl [ -z zone ] fqdn_ns1 fqdn_ns2 ...
+   #        if all queries are assumed to have zone suffux, such as "jp" in
+   #     JP TLD servers, specify it in -z option
+   #
+   use strict;
+   use Getopt::Std;
+   my ($sz_msg) = (512);
+   my ($sz_header, $sz_ptr, $sz_rr_a, $sz_rr_aaaa) = (12, 2, 16, 28);
+   my ($sz_type, $sz_class, $sz_ttl, $sz_rdlen) = (2, 2, 4, 2);
+   my (%namedb, $name, $nssect, %opts, $optz);
+   my $n_ns = 0;
+
+
+
+
+   Expires December 2005                                           [Page 6]
+
+   INTERNET-DRAFT                  July 2005                       RESPSIZE
+
+
+   getopt('z', opts);
+   if (defined($opts{'z'})) {
+        server_name_len($opts{'z'}); # just register it
+   }
+
+   foreach $name (@ARGV) {
+        my $len;
+        $n_ns++;
+        $len = server_name_len($name);
+           print "$name requires $len bytes\n";
+        $nssect += $sz_ptr + $sz_type + $sz_class + $sz_ttl + $sz_rdlen + $len;
+   }
+   print "# of NS: $n_ns\n";
+   arsect(255, $nssect, $n_ns, "maximum");
+   arsect(64, $nssect, $n_ns, "average");
+
+   sub server_name_len {
+       my ($name) = @_;
+       my (@labels, $len, $n, $suffix);
+
+       $name =~ tr/A-Z/a-z/;
+       @labels = split(/./, $name);
+       $len = length(join('.', @labels)) + 2;
+       for ($n = 0; $#labels >= 0; $n++, shift @labels) {
+           $suffix = join('.', @labels);
+           return length($name) - length($suffix) + $sz_ptr
+               if (defined($namedb{$suffix}));
+           $namedb{$suffix} = 1;
+       }
+       return $len;
+   }
+
+   sub arsect {
+       my ($sz_query, $nssect, $n_ns, $cond) = @_;
+       my ($space, $n_a, $n_a_aaaa, $n_p_aaaa, $ansect);
+       $ansect = $sz_query + 1 + $sz_type + $sz_class;
+       $space = $sz_msg - $sz_header - $ansect - $nssect;
+       $n_a = atmost(int($space / $sz_rr_a), $n_ns);
+       $n_a_aaaa = atmost(int($space / ($sz_rr_a + $sz_rr_aaaa)), $n_ns);
+       $n_p_aaaa = atmost(int(($space - $sz_rr_a * $n_ns) / $sz_rr_aaaa), $n_ns);
+       printf "For %s size query (%d byte):\n", $cond, $sz_query;
+       printf "if only A is considered:     ";
+       printf "# of A is %d (%s)\n", $n_a, &judge($n_a, $n_ns);
+       printf "if A and AAAA are condered:  ";
+       printf "# of A+AAAA is %d (%s)\n", $n_a_aaaa, &judge($n_a_aaaa, $n_ns);
+
+
+
+   Expires December 2005                                           [Page 7]
+
+   INTERNET-DRAFT                  July 2005                       RESPSIZE
+
+
+       printf "if prefer_glue A is assumed: ";
+       printf "# of A is %d, # of AAAA is %d (%s)\n",
+           $n_a, $n_p_aaaa, &judge($n_p_aaaa, $n_ns);
+   }
+
+   sub judge {
+       my ($n, $n_ns) = @_;
+       return "green" if ($n >= $n_ns);
+       return "yellow" if ($n >= 2);
+       return "orange" if ($n == 1);
+       return "red";
+   }
+
+   sub atmost {
+       my ($a, $b) = @_;
+       return 0 if ($a < 0);
+       return $b if ($a > $b);
+       return $a;
+   }
+
+   Security Considerations
+
+   The recommendations contained in this document have no known security
+   implications.
+
+   IANA Considerations
+
+   This document does not call for changes or additions to any IANA
+   registry.
+
+   IPR Statement
+
+   Copyright (C) The Internet Society (2005).  This document is subject to
+   the rights, licenses and restrictions contained in BCP 78, and except as
+   set forth therein, the authors retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR
+   IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+
+
+
+   Expires December 2005                                           [Page 8]
+
+   INTERNET-DRAFT                  July 2005                       RESPSIZE
+
+
+   Authors' Addresses
+
+   Paul Vixie
+      950 Charter Street
+      Redwood City, CA 94063
+      +1 650 423 1301
+      vixie@isc.org
+
+   Akira Kato
+      University of Tokyo, Information Technology Center
+      2-11-16 Yayoi Bunkyo
+      Tokyo 113-8658, JAPAN
+      +81 3 5841 2750
+      kato@wide.ad.jp
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+   Expires December 2005                                           [Page 9]
+
\ No newline at end of file
diff --git a/doc/draft/draft-ietf-dnsop-serverid-06.txt b/doc/draft/draft-ietf-dnsop-serverid-06.txt
new file mode 100644
index 0000000..c6ec7e4
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsop-serverid-06.txt
@@ -0,0 +1,618 @@
+
+
+
+
+Network Working Group                                           S. Woolf
+Internet-Draft                         Internet Systems Consortium, Inc.
+Expires: September 6, 2006                                     D. Conrad
+                                                           Nominum, Inc.
+                                                           March 5, 2006
+
+
+    Requirements for a Mechanism Identifying a Name Server Instance
+                      draft-ietf-dnsop-serverid-06
+
+Status of this Memo
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   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 draft documents 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 "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/ietf/1id-abstracts.txt.
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+   This Internet-Draft will expire on September 6, 2006.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   With the increased use of DNS anycast, load balancing, and other
+   mechanisms allowing more than one DNS name server to share a single
+   IP address, it is sometimes difficult to tell which of a pool of name
+   servers has answered a particular query.  A standardized mechanism to
+   determine the identity of a name server responding to a particular
+   query would be useful, particularly as a diagnostic aid for
+   administrators.  Existing ad hoc mechanisms for addressing this need
+
+
+
+Woolf & Conrad          Expires September 6, 2006               [Page 1]
+
+Internet-Draft                  Serverid                      March 2006
+
+
+   have some shortcomings, not the least of which is the lack of prior
+   analysis of exactly how such a mechanism should be designed and
+   deployed.  This document describes the existing convention used in
+   some widely deployed implementations of the DNS protocol, including
+   advantages and disadvantages, and discusses some attributes of an
+   improved mechanism.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Woolf & Conrad          Expires September 6, 2006               [Page 2]
+
+Internet-Draft                  Serverid                      March 2006
+
+
+1.  Introduction and Rationale
+
+   Identifying which name server is responding to queries is often
+   useful, particularly in attempting to diagnose name server
+   difficulties.  This is most obviously useful for authoritative
+   nameservers in the attempt to diagnose the source or prevalence of
+   inaccurate data, but can also conceivably be useful for caching
+   resolvers in similar and other situations.  Furthermore, the ability
+   to identify which server is responding to a query has become more
+   useful as DNS has become more critical to more Internet users, and as
+   network and server deployment topologies have become more complex.
+
+   The traditional means for determining which of several possible
+   servers is answering a query has traditionally been based on the use
+   of the server's IP address as a unique identifier.  However, the
+   modern Internet has seen the deployment of various load balancing,
+   fault-tolerance, or attack-resistance schemes such as shared use of
+   unicast IP addresses as documented in [RFC3258].  An unfortunate side
+   effect of these schemes has been to make the use of IP addresses as
+   identifiers somewhat problematic.  Specifically, a dedicated DNS
+   query may not go to the same server as answered a previous query,
+   even though sent to the same IP address.  Non-DNS methods such as
+   ICMP ping, TCP connections, or non-DNS UDP packets (such as those
+   generated by tools like "traceroute"), etc., may well be even less
+   certain to reach the same server as the one which receives the DNS
+   queries.
+
+   There is a well-known and frequently-used technique for determining
+   an identity for a nameserver more specific than the possibly-non-
+   unique "server that answered the query I sent to IP address XXX".
+   The widespread use of the existing convention suggests a need for a
+   documented, interoperable means of querying the identity of a
+   nameserver that may be part of an anycast or load-balancing cluster.
+   At the same time, however, it also has some drawbacks that argue
+   against standardizing it as it's been practiced so far.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Woolf & Conrad          Expires September 6, 2006               [Page 3]
+
+Internet-Draft                  Serverid                      March 2006
+
+
+2.  Existing Conventions
+
+   For some time, the commonly deployed Berkeley Internet Name Domain
+   implementation of the DNS protocol suite from the Internet Systems
+   Consortium [BIND] has supported a way of identifying a particular
+   server via the use of a standards-compliant, if somewhat unusual, DNS
+   query.  Specifically, a query to a recent BIND server for a TXT
+   resource record in class 3 (CHAOS) for the domain name
+   "HOSTNAME.BIND." will return a string that can be configured by the
+   name server administrator to provide a unique identifier for the
+   responding server.  (The value defaults to the result of a
+   gethostname() call).  This mechanism, which is an extension of the
+   BIND convention of using CHAOS class TXT RR queries to sub-domains of
+   the "BIND." domain for version information, has been copied by
+   several name server vendors.
+
+   A refinement to the BIND-based mechanism, which dropped the
+   implementation-specific string, replaces ".BIND" with ".SERVER".
+   Thus the query string to learn the unique name of a server may be
+   queried as "ID.SERVER".
+
+   (For reference, the other well-known name used by recent versions of
+   BIND within the CHAOS class "BIND." domain is "VERSION.BIND."  A
+   query for a CHAOS TXT RR for this name will return an
+   administratively defined string which defaults to the version of the
+   server responding.  This is, however, not generally implemented by
+   other vendors.)
+
+2.1.  Advantages
+
+   There are several valuable attributes to this mechanism, which
+   account for its usefulness.
+
+   1.  The "HOSTNAME.BIND" or "ID.SERVER" query response mechanism is
+       within the DNS protocol itself.  An identification mechanism that
+       relies on the DNS protocol is more likely to be successful
+       (although not guaranteed) in going to the same system as a
+       "normal" DNS query.
+
+   2.  Since the identity information is requested and returned within
+       the DNS protocol, it doesn't require allowing any other query
+       mechanism to the server, such as holes in firewalls for
+       otherwise-unallowed ICMP Echo requests.  Thus it is likely to
+       reach the same server over a path subject to the same routing,
+       resource, and security policy as the query, without any special
+       exceptions to site security policy.
+
+
+
+
+
+Woolf & Conrad          Expires September 6, 2006               [Page 4]
+
+Internet-Draft                  Serverid                      March 2006
+
+
+   3.  It is simple to configure.  An administrator can easily turn on
+       this feature and control the results of the relevant query.
+
+   4.  It allows the administrator complete control of what information
+       is given out in the response, minimizing passive leakage of
+       implementation or configuration details.  Such details are often
+       considered sensitive by infrastructure operators.
+
+   5.  Hypothetically, since it's an ordinary DNS record and the
+       relevant DNSSEC RRs are class independent, the id.server response
+       RR could be signed, which has the advantages described in
+       [RFC4033].
+
+2.2.  Disadvantages
+
+   At the same time, there are some serious drawbacks to the CHAOS/TXT
+   query mechanism that argue against standardizing it as it currently
+   operates.
+
+   1.  It requires an additional query to correlate between the answer
+       to a DNS query under normal conditions and the supposed identity
+       of the server receiving the query.  There are a number of
+       situations in which this simply isn't reliable.
+
+   2.  It reserves an entire class in the DNS (CHAOS) for what amounts
+       to one zone.  While CHAOS class is defined in [RFC1034] and
+       [RFC1035], it's not clear that supporting it solely for this
+       purpose is a good use of the namespace or of implementation
+       effort.
+
+   3.  The initial and still common form, using .BIND, is implementation
+       specific.  BIND is one DNS implementation.  At the time of this
+       writing, it is probably the most prevalent for authoritative
+       servers.  This does not justify standardizing on its ad hoc
+       solution to a problem shared across many operators and
+       implementors.  Meanwhile, the proposed refinement changes the
+       string but preserves the ad hoc CHAOS/TXT mechanism.
+
+   4.  There is no convention or shared understanding of what
+       information an answer to such a query for a server identity could
+       or should include, including a possible encoding or
+       authentication mechanism.
+
+   The first of the listed disadvantages may be technically the most
+   serious.  It argues for an attempt to design a good answer to the
+   problem that "I need to know what nameserver is answering my
+   queries", not simply a convenient one.
+
+
+
+
+Woolf & Conrad          Expires September 6, 2006               [Page 5]
+
+Internet-Draft                  Serverid                      March 2006
+
+
+2.3.  Characteristics of an Implementation Neutral Convention
+
+   The discussion above of advantages and disadvantages to the
+   HOSTNAME.BIND mechanism suggest some requirements for a better
+   solution to the server identification problem.  These are summarized
+   here as guidelines for any effort to provide appropriate protocol
+   extensions:
+
+   1.  The mechanism adopted must be in-band for the DNS protocol.  That
+       is, it needs to allow the query for the server's identifying
+       information to be part of a normal, operational query.  It should
+       also permit a separate, dedicated query for the server's
+       identifying information.  But it should preserve the ability of
+       the CHAOS/TXT query-based mechanism to work through firewalls and
+       in other situations where only DNS can be relied upon to reach
+       the server of interest.
+
+   2.  The new mechanism should not require dedicated namespaces or
+       other reserved values outside of the existing protocol mechanisms
+       for these, i.e. the OPT pseudo-RR.  In particular, it should not
+       propagate the existing drawback of requiring support for a CLASS
+       and top level domain in the authoritative server (or the querying
+       tool) to be useful.
+
+   3.  Support for the identification functionality should be easy to
+       implement and easy to enable.  It must be easy to disable and
+       should lend itself to access controls on who can query for it.
+
+   4.  It should be possible to return a unique identifier for a server
+       without requiring the exposure of information that may be non-
+       public and considered sensitive by the operator, such as a
+       hostname or unicast IP address maintained for administrative
+       purposes.
+
+   5.  It should be possible to authenticate the received data by some
+       mechanism analogous to those provided by DNSSEC.  In this
+       context, the need could be met by including encryption options in
+       the specification of a new mechanism.
+
+   6.  The identification mechanism should not be implementation-
+       specific.
+
+
+
+
+
+
+
+
+
+
+Woolf & Conrad          Expires September 6, 2006               [Page 6]
+
+Internet-Draft                  Serverid                      March 2006
+
+
+3.  IANA Considerations
+
+   This document proposes no specific IANA action.  Protocol extensions,
+   if any, to meet the requirements described are out of scope for this
+   document.  A proposed extension, specified and adopted by normal IETF
+   process, is described in [NSID], including relevant IANA action.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Woolf & Conrad          Expires September 6, 2006               [Page 7]
+
+Internet-Draft                  Serverid                      March 2006
+
+
+4.  Security Considerations
+
+   Providing identifying information as to which server is responding to
+   a particular query from a particular location in the Internet can be
+   seen as information leakage and thus a security risk.  This motivates
+   the suggestion above that a new mechanism for server identification
+   allow the administrator to disable the functionality altogether or
+   partially restrict availability of the data.  It also suggests that
+   the serverid data should not be readily correlated with a hostname or
+   unicast IP address that may be considered private to the nameserver
+   operator's management infrastructure.
+
+   Propagation of protocol or service meta-data can sometimes expose the
+   application to denial of service or other attack.  As DNS is a
+   critically important infrastructure service for the production
+   Internet, extra care needs to be taken against this risk for
+   designers, implementors, and operators of a new mechanism for server
+   identification.
+
+   Both authentication and confidentiality of serverid data are
+   potentially of interest to administrators-- that is, operators may
+   wish to make serverid data available and reliable to themselves and
+   their chosen associates only.  This would imply both an ability to
+   authenticate it to themselves and keep it private from arbitrary
+   other parties.  This led to Characteristics 4 and 5 of an improved
+   solution.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Woolf & Conrad          Expires September 6, 2006               [Page 8]
+
+Internet-Draft                  Serverid                      March 2006
+
+
+5.  Acknowledgements
+
+   The technique for host identification documented here was initially
+   implemented by Paul Vixie of the Internet Software Consortium in the
+   Berkeley Internet Name Daemon package.  Comments and questions on
+   earlier drafts were provided by Bob Halley, Brian Wellington, Andreas
+   Gustafsson, Ted Hardie, Chris Yarnell, Randy Bush, and members of the
+   ICANN Root Server System Advisory Committee.  The newest version
+   takes a significantly different direction from previous versions,
+   owing to discussion among contributors to the DNSOP working group and
+   others, particularly Olafur Gudmundsson, Ed Lewis, Bill Manning, Sam
+   Weiler, and Rob Austein.
+
+6.  References
+
+   [1]  Mockapetris, P., "Domain Names - Concepts and Facilities",
+        RFC 1034, STD 0013, November 1987.
+
+   [2]  Mockapetris, P., "Domain Names - Implementation and
+        Specification", RFC 1035, STD 0013, November 1987.
+
+   [3]  Hardie, T., "Distributing Authoritative Name Servers via Shared
+        Unicast Addresses", RFC 3258, April 2002.
+
+   [4]  ISC, "BIND 9 Configuration Reference".
+
+   [5]  Austein, S., "DNS Name Server Identifier Option (NSID)",
+        Internet Drafts http://www.ietf.org/internet-drafts/
+        draft-ietf-dnsext-nsid-01.txt, January 2006.
+
+   [6]  Arends, R., Austein, S., Larson, M., Massey, D., and S. Rose,
+        "DNS Security Introduction and Requirements", RFC 4033,
+        March 2005.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Woolf & Conrad          Expires September 6, 2006               [Page 9]
+
+Internet-Draft                  Serverid                      March 2006
+
+
+Authors' Addresses
+
+   Suzanne Woolf
+   Internet Systems Consortium, Inc.
+   950 Charter Street
+   Redwood City, CA  94063
+   US
+
+   Phone: +1 650 423-1333
+   Email: woolf@isc.org
+   URI:   http://www.isc.org/
+
+
+   David Conrad
+   Nominum, Inc.
+   2385 Bay Road
+   Redwood City, CA  94063
+   US
+
+   Phone: +1 1 650 381 6003
+   Email: david.conrad@nominum.com
+   URI:   http://www.nominum.com/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Woolf & Conrad          Expires September 6, 2006              [Page 10]
+
+Internet-Draft                  Serverid                      March 2006
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2006).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Woolf & Conrad          Expires September 6, 2006              [Page 11]
+
+
diff --git a/doc/draft/draft-ietf-enum-e164-gstn-np-05.txt b/doc/draft/draft-ietf-enum-e164-gstn-np-05.txt
new file mode 100644
index 0000000..3353b3b
--- /dev/null
+++ b/doc/draft/draft-ietf-enum-e164-gstn-np-05.txt
@@ -0,0 +1,1588 @@
+
+                                                            Mark Foster 
+Internet Draft                                              Tom McGarry 
+Document: <draft-ietf-enum-e164-gstn-np-05.txt>                James Yu 
+                                                          NeuStar, Inc. 
+Category: Informational                                   June 24, 2002 
+ 
+ 
+              Number Portability in the GSTN: An Overview 
+ 
+ 
+Status of this Memo 
+ 
+   This document is an Internet-Draft and is in full conformance with 
+   all provisions of Section 10 of RFC2026 [RFC].  
+ 
+   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 draft documents 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 "work in 
+   progress."  
+    
+   The list of current Internet-Drafts can be accessed at 
+   http://www.ietf.org/ietf/1id-abstracts.txt. 
+     
+   The list of Internet-Draft Shadow Directories can be accessed at 
+   http://www.ietf.org/shadow.html. 
+    
+ 
+   Copyright Notice 
+ 
+      Copyright (C) The Internet Society (2002).  All rights reserved. 
+    
+    
+   Abstract 
+    
+   This document provides an overview of E.164 telephone number 
+   portability (NP) in the Global Switched Telephone Network (GSTN).    
+   NP is a regulatory imperative seeking to liberalize local telephony 
+   service competition, by enabling end-users to retain telephone 
+   numbers while changing service providers.  NP changes the 
+   fundamental nature of a dialed E.164 number from a hierarchical 
+   physical routing address to a virtual address, thereby requiring the 
+   transparent translation of the later to the former.  In addition, 
+   there are various regulatory constraints that establish relevant 
+   parameters for NP implementation, most of which are not network 
+   technology specific.  Consequently, the implementation of NP 
+   behavior consistent with applicable regulatory constraints, as well 
+   as the need for interoperation with the existing GSTN NP 
+   implementations, are relevant topics for numerous areas of IP 
+   telephony work-in-progress at IETF. 
+  
+Foster,McGarry,Yu         Expired on December 23, 2002        [Page 1] 
+
+Number Portability in the GSTN: An Overview               June 24, 2002 
+
+    
+   Table of Contents 
+    
+    1.  Introduction ...............................................  2 
+    2.  Abbreviations and Acronyms .................................  4 
+    3.  Types of Number Portability ................................  5 
+    4.  Service Provider Number Portability Schemes ................  7 
+       4.1   All Call Query (ACQ) ..................................  7 
+       4.2   Query on Release (QoR) ................................  8 
+       4.3   Call Dropback .........................................  9 
+       4.4   Onward Routing (OR) ...................................  9 
+       4.5   Comparisons of the Four Schemes ....................... 10 
+    5.  Database Queries in the NP Environment ..................... 11 
+       5.1   U.S. and Canada ....................................... 12 
+       5.2   Europe ................................................ 13 
+    6.  Call Routing in the NP Environment ......................... 14 
+       6.1   U.S. and Canada ....................................... 14 
+       6.2   Europe ................................................ 15 
+    7.  NP Implementations for Geographic E.164 Numbers ............ 17 
+    8.  Number Conservation Method Enabled By NP ................... 20 
+       8.1   Block Pooling ......................................... 20 
+       8.2   ITN Pooling ........................................... 21 
+    9.  Potential Implications ..................................... 21 
+   10.  Security Considerations .................................... 24 
+   11.  IANA Considerations ........................................ 24 
+   12.  Normative References ....................................... 24 
+   13.  Informative References ..................................... 25 
+   14.  Acknowledgement ............................................ 25 
+   15.  AuthorsË Addresses ......................................... 25 
+    
+ 
+    
+1. Introduction 
+    
+   This document provides an overview of E.164 telephone number 
+   portability in the Global Switched Telephone Network (GSTN).  There 
+   are considered to be three types of number portability (NP): service 
+   provider portability (SPNP), location portability (not to be 
+   confused with terminal mobility), and service portability. 
+    
+   Service provider portability (SPNP), the focus of the present draft, 
+   is a regulatory imperative in many countries seeking to liberalize 
+   telephony service competition, especially local service.  
+   Historically, local telephony service (as compared to long distance 
+   or international service) has been regulated as a utility-like form 
+   of service.  While a number of countries had begun liberalization 
+   (e.g. privatization, de-regulation, or re-regulation) some years 
+   ago, the advent of NP is relatively recent (since ~1995). 
+    
+   E.164 numbers can be non-geographic and geographic numbers.  Non-
+   geographic numbers do not reveal the locations information of those 
+   numbers.  Geographic E.164 numbers were intentionally designed as 
+   hierarchical routing addresses which could systematically be digit-
+   analyzed to ascertain the country, serving network provider, serving 
+  
+Foster,McGarry,Yu           Expired on December 23, 2002      [Page 2] 
+
+Number Portability in the GSTN: An Overview               June 24, 2002 
+
+   end-office switch, and specific line of the called party.  As such, 
+   without NP a subscriber wishing to change service providers would 
+   incur a number change as a consequence of being served off of a 
+   different end-office switch operated by the new service provider.  
+   The cost and convenience impact to the subscriber of changing 
+   numbers is seen as barrier to competition.  Hence NP has become 
+   associated with GSTN infrastructure enhancements associated with a 
+   competitive environment driven by regulatory directives. 
+    
+   Forms of SPNP have been deployed or are being deployed widely in the 
+   GSTN in various parts of the world, including the U.S., Canada, 
+   Western Europe, Australia, and the Pacific Rim (e.g. Hong Kong). 
+   Other regions, such as South America (e.g. Brazil) are actively 
+   considering it. 
+    
+   Implementation of NP within a national telephony infrastructure 
+   entails potentially significant changes to numbering administration, 
+   network element signaling, call routing and processing, billing, 
+   service management, and other functions. 
+    
+   NP changes the fundamental nature of a dialed E.164 number from a 
+   hierarchical physical routing address to a virtual address.  NP 
+   implementations attempt to encapsulate the impacts to the GSTN and 
+   make NP transparent to subscribers by incorporating a translation 
+   function to map a dialed, potentially ported E.164 address, into a 
+   network routing address (either a number prefix or another E.164 
+   address) which can be hierarchically routed. 
+    
+   This is roughly analogous to the use of network address translation 
+   on IP addresses to enable IP address portability by containing the 
+   impact of the address change to the edge of the network and retain 
+   the use of CIDR blocks in the core which can be route aggregated by 
+   the network service provider to the rest of the internet. 
+    
+   NP bifurcates the historical role of a subscriberËs E.164 address 
+   into two or more data elements (a dialed or virtual address, and a 
+   network routing address) that must be made available to network 
+   elements through an NP translations database, carried by forward 
+   call signaling, and recorded on call detail records.  Not only is 
+   call processing and routing affected, but also so is SS7/C7 
+   messaging.  A number of TCAP-based SS7 messaging sets utilize an 
+   E.164 address as an application-level network element address in the 
+   global title address (GTA) field of the SCCP message header.  
+   Consequently, SS7/C7 signaling transfer points (STPs) and gateways 
+   need to be able to perform n-digit global title translation (GTT) to 
+   translate a dialed E.164 address into its network address 
+   counterpart via the NP database. 
+    
+   In addition, there are various national regulatory constraints that 
+   establish relevant parameters for NP implementation, most of which 
+   are not network technology specific.  Consequently, implementations 
+   of NP behavior in IP telephony consistent with applicable regulatory 
+   constraints, as well as the need for interoperation with the 
+
+  
+Foster,McGarry,Yu           Expired on December 23, 2002      [Page 3] 
+
+Number Portability in the GSTN: An Overview               June 24, 2002 
+
+   existing GSTN NP implementations, are relevant topics for numerous 
+   areas of IP telephony work-in-progress at IETF. 
+    
+   This document describes three types of number portability and the 
+   four schemes that have been standardized to support SPNP for 
+   geographic E.164 numbersspecifically.  Following that, specific 
+   information regarding the call routing and database query 
+   implementations are described for several regions (North American 
+   and Europe) and industries (wireless vs. wireline). The Number 
+   Portability Database (NPDB) interfaces and the call routing schemes 
+   that are used in the North America and Europe are described to show 
+   the variety of standards that may be implemented worldwide.  A 
+   glance of the NP implementations worldwide is provided.  Number 
+   pooling is briefly discussed to show how NP is being enhanced in the 
+   U.S. to conserve North American area codes.  The conclusion briefly 
+   touches the potential impacts of NP on IP & Telecommunications 
+   Interoperability.  Appendix A provides some specific technical and 
+   regulatory information on NP in North America.  Appendix B describes 
+   the number portability administration process that manages the 
+   number portability database in North America. 
+    
+    
+2. Abbreviations and Acronyms 
+    
+   ACQ     All Call Query 
+   AIN     Advanced Intelligent Network 
+   AMPS    Advanced Mobile Phone System 
+   ANSI    American National Standards Institute 
+   CDMA    Code Division Multiple Access 
+   CdPA    Called Party Address 
+   CdPN    Called Party Number 
+   CH      Code Holder 
+   CMIP    Common Management Information Protocol 
+   CS1     Capability Set 1 
+   CS2     Capability Set 2 
+   DN      Directory Number 
+   DNS     Domain Name System 
+   ETSI    European Technical Standards Institute 
+   FCI     Forward Call Indicator 
+   GAP     Generic Address Parameter 
+   GMSC    Gateway Mobile Services Switching Center or Gateway Mobile 
+           Switching Center 
+   GSM     Global System for Mobile Communications 
+   GSTN    Global Switched Telephone Network 
+   GW      Gateways 
+   HLR     Home Location Register 
+   IAM     Initial Address Message 
+   IETF    Internet Engineering Task Force 
+   ILNP    Interim LNP 
+   IN      Intelligent Network 
+   INAP    Intelligent Network Application Part 
+   INP     Interim NP     
+   IP      Internet Protocol 
+   IS-41   Interim Standards Number 41 
+  
+Foster,McGarry,Yu           Expired on December 23, 2002      [Page 4] 
+
+Number Portability in the GSTN: An Overview               June 24, 2002 
+
+   ISDN    Integrated Services Digital Network 
+   ISUP    ISDN User Part 
+   ITN     Individual Telephony Number  
+   ITU     International Telecommunication Union 
+   ITU-TS  ITU-Telecommunication Sector 
+   LDAP    Lightweight Directory Access Protocol  
+   LEC     Local Exchange Carrier 
+   LERG    Local Exchange Routing Guide 
+   LNP     Local Number Portability 
+   LRN     Location Routing Number 
+   MAP     Mobile Application Part 
+   MNP     Mobile Number Portability 
+   MSRN    Mobile Station Roaming Number 
+   MTP     Message Transfer Part 
+   NANP    North American Numbering Plan 
+   NP      Number Portability 
+   NPDB    Number Portability Database 
+   NRN     Network Routing Number 
+   OR      Onward Routing 
+   OSS     Operation Support System 
+   PCS     Personal Communication Services 
+   PNTI    Ported Number Translation Indicator 
+   PODP    Public Office Dialing Plan 
+   PUC     Public Utility Commission 
+   QoR     Query on Release 
+   RN      Routing Number 
+   RTP     Return to Pivot 
+   SCCP    Signaling Connection Control Part 
+   SCP     Service Control Point  
+   SIP     Session Initiation Protocol 
+   SMR     Special Mobile Radio 
+   SMS     Service Management System 
+   SPNP    Service Provider Number Portability 
+   SRF     Signaling Relaying Function 
+   SRI     Send Routing Information 
+   SS7     Signaling System Number 7 
+   STP     Signaling Transfer Point 
+   TCAP    Transaction Capabilities Application Part 
+   TDMA    Time Division Multiple Access 
+   TN      Telephone Number 
+   TRIP    Telephony Routing Information Protocol 
+   URL     Universal Resource Locator 
+   U.S.    United States 
+    
+    
+3. Types of Number Portability 
+    
+   As there are several types of E.164 numbers (telephone numbers, or 
+   just TN) in the GSTN, there are correspondingly several types of 
+   E.164 NP in the GSTN.  First there are so-call non-geographic E.164 
+   numbers, commonly used for service-specific applications such as 
+   freephone (800 or 0800).  Portability of these numbers is called 
+   non-geographic number portability (NGNP).  NGNP, for example, was 
+   deployed in the U.S. in 1986-92. 
+  
+Foster,McGarry,Yu           Expired on December 23, 2002      [Page 5] 
+
+Number Portability in the GSTN: An Overview               June 24, 2002 
+
+    
+   Geographic number portability, which includes traditional fixed or 
+   wireline numbers as well as mobile numbers which are allocated out 
+   of geographic number range prefixes, is called NP or GNP or in the 
+   U.S. local number portability (LNP). 
+    
+   Number portability allows the telephony subscribers in the Global 
+   Switched Telephone Network (GSTN) to keep their phone numbers when 
+   they change their service providers or subscribed services, or when 
+   they move to a new location.   
+    
+   The ability to change the service provider while keeping the same 
+   phone number is called service provider portability (SPNP) also 
+   known as "operator portability." 
+    
+   The ability to change the subscriberËs fixed service location while 
+   keeping the same phone number is called location portability. 
+    
+   The ability to change the subscribed services (e.g., from the plain 
+   old telephone service to Integrated Services Digital Network (ISDN) 
+   services) while keeping the same phone number is called service 
+   portability.  Another aspect of service portability is to allow the 
+   subscribers to enjoy the subscribed services in the same way when 
+   they roam outside their home networks as is supported by the 
+   cellular/wireless networks. 
+    
+   In addition, mobile number portability (MNP) refers to specific NP 
+   implementation in mobile networks either as part of a broader NP 
+   implementation in the GSTN or on a stand-alone basis.  Where 
+   interoperation of LNP and MNP is supported, service portability 
+   between fixed and mobile service types is possible. 
+    
+   At present, SPNP has been the primary form of NP deployed due to its 
+   relevance in enabling local service competition. 
+    
+   Also in use in the GSTN are the terms interim NP (INP) or Interim 
+   LNP (ILNP) and true NP.  Interim NP usually refers to the use of 
+   remote call forwarding-like measures to forward calls to ported 
+   numbers through the donor network to the new service network.  These 
+   are considered interim relative to true NP, which seeks to remove 
+   the donor network or old service provider from the call or signaling 
+   path altogether.  Often the distinction between interim and true NP 
+   is a national regulatory matter relative to the 
+   technical/operational requirements imposed on NP in that country. 
+    
+   Implementations of true NP in certain countries (e.g. U.S., Canada, 
+   Spain, Belgium, Denmark) may pose specific requirements for IP 
+   telephony implementations as a result of regulatory and industry 
+   requirements for providing call routing and signaling independent of 
+   the donor network or last previous serving network. 
+    
+    
+    
+    
+  
+Foster,McGarry,Yu           Expired on December 23, 2002      [Page 6] 
+
+Number Portability in the GSTN: An Overview               June 24, 2002 
+
+ 
+4. Service Provider Number Portability Schemes 
+    
+   Four schemes can be used to support service provider portability and 
+   are briefly described below.  But first, some further terms are 
+   introduced. 
+    
+   The donor network is the network that first assigned a telephone 
+   number (e.g., TN +1-202-533-1234) to a subscriber, out of a number 
+   range administratively (e.g., +1 202-533) assigned to it.  The 
+   current service provider (new SP) or new serving network is the 
+   network that currently serves the ported number. The old serving 
+   network (or old SP) is the network that previously served the ported 
+   number before the number was ported to the new serving network. 
+   Since a TN can port a number of times, the old SP is not necessarily 
+   the same as the donor network, except for the first time the TN 
+   ports away, or if the TN ports back into the donor network and away 
+   again.  While the new SP and old SP roles are transitory as a TN 
+   ports around, the donor network is always the same for any 
+   particular TN based on the service provider to whom the subtending 
+   number range was administratively assigned.  See the discussion 
+   below on number pooling, as this enhancement to NP further 
+   bifurcates the role of donor network into two (the number range or 
+   code holder network, and the block holder network). 
+    
+   To simplify the illustration, all the transit networks are ignored, 
+   the originating or donor network is the one that performs the 
+   database queries or call redirection, and the dialed directory 
+   number (TN) has been ported out of the donor network before.  
+    
+   It is assumed that the old serving network, the new serving network 
+   and the donor network are different networks so as to show which 
+   networks are involved in call handling and routing and database 
+   queries in each of four schemes.  Please note that the port of the 
+   number (process of moving it from one network to another) happened 
+   prior to the call setup and is not included in the call steps.  
+   Information carried in the signaling messages to support each of the 
+   four schemes is not discussed to simplify the explanation. 
+    
+    
+4.1 All Call Query (ACQ) 
+    
+   Figure 1 shows the call steps for the ACQ scheme.  Those call steps 
+   are as follows: 
+ 
+   (1) The Originating Network receives a call from the caller and 
+       sends a query to a centrally administered Number Portability 
+       Database (NPDB), a copy of which is usually resident on a 
+       network element within its network or through a third party 
+       provider. 
+   (2) The NPDB returns the routing number associated with the dialed 
+       directory number.  The routing number is discussed later in 
+       Section 6. 
+
+  
+Foster,McGarry,Yu           Expired on December 23, 2002      [Page 7] 
+
+Number Portability in the GSTN: An Overview               June 24, 2002 
+
+   (3) The Originating Network uses the routing number to route the 
+       call to the new serving network. 
+    
+    
+   +-------------+              +-----------+    Number   +-----------+ 
+   | Centralized |              | New Serv. |    ported   | Old Serv. | 
+   |    NPDB     |    +-------->|  Network  |<------------|  Network  | 
+   +-------------+    |         +-----------+             +-----------+ 
+       ^  |           | 
+       |  |           | 
+      1|  |         3.| 
+       |  | 2.        | 
+       |  |           | 
+       |  v           | 
+    +----------+      |         +----------+           +----------+ 
+    |   Orig.  |------+         |   Donor  |           | Internal | 
+    |  Network |                |  Network |           |   NPDB   | 
+    +----------+                +----------+           +----------+ 
+    
+    
+              Figure 1 - All Call Query (ACQ) Scheme. 
+ 
+ 
+4.2 Query on Release (QoR) 
+ 
+  Figure 2 shows the call steps for the QoR scheme.  Those call steps 
+  are as follows: 
+    
+    
+   +-------------+              +-----------+    Number   +-----------+ 
+   | Centralized |              | New Serv. |    ported   | Old Serv. | 
+   |    NPDB     |              |  Network  |<------------|  Network  | 
+   +-------------+              +-----------+             +-----------+ 
+       ^  |                          ^ 
+       |  | 4.                       | 
+     3.|  |              5.          | 
+       |  |   +----------------------+ 
+       |  |   | 
+       |  v   | 
+    +----------+      2.        +----------+           +----------+ 
+    |   Orig.  |<---------------|   Donor  |           | Internal | 
+    |  Network |--------------->|  Network |           |   NPDB   | 
+    +----------+      1.        +----------+           +----------+ 
+    
+                   
+                Figure 2 - Query on Release (QoR) Scheme. 
+    
+   (1) The Originating Network receives a call from the caller and 
+       routes the call to the donor network. 
+   (2) The donor network releases the call and indicates that the 
+       dialed directory number has been ported out of that switch. 
+   (3) The Originating Network sends a query to its copy of the 
+       centrally administered NPDB. 
+
+  
+Foster,McGarry,Yu           Expired on December 23, 2002      [Page 8] 
+
+Number Portability in the GSTN: An Overview               June 24, 2002 
+
+   (4) The NPDB returns the routing number associated with the dialed 
+       directory number.   
+   (5) The Originating Network uses the routing number to route the 
+       call to the new serving network. 
+    
+    
+4.3 Call Dropback 
+    
+  Figure 3 shows the call steps for the Dropback scheme.  This scheme 
+  is also known as "Return to Pivot (RTP)."  Those call steps are as 
+  follows: 
+    
+   (1) The Originating Network receives a call from the caller and 
+       routes the call to the donor network. 
+   (2) The donor network detects that the dialed directory number has 
+       been ported out of the donor switch and checks with an internal 
+       network-specific NPDB.  
+   (3) The internal NPDB returns the routing number associated with the 
+       dialed directory number. 
+   (4) The donor network releases the call by providing the routing 
+       number. 
+   (5) The Originating Network uses the routing number to route the 
+       call to the new serving network. 
+    
+   +-------------+              +-----------+    Number   +-----------+ 
+   | Centralized |              | New Serv. |    porting  | Old Serv. | 
+   |    NPDB     |              |  Network  |<------------|  Network  | 
+   +-------------+              +-----------+             +-----------+ 
+                                    /\ 
+                                     | 
+                           5.        | 
+            +------------------------+ 
+            | 
+            | 
+    +----------+       4.       +----------+     3.    +----------+ 
+    |   Orig.  |<---------------|   Donor  |<----------| Internal | 
+    |  Network |--------------->|  Network |---------->|   NPDB   | 
+    +----------+      1.        +----------+    2.     +----------+ 
+    
+                   
+                      Figure 3 - Dropback Scheme. 
+    
+    
+4.4 Onward Routing (OR) 
+    
+  Figure 4 shows the call steps for the OR scheme.  Those call steps 
+  are as follows: 
+    
+   (1) The Originating Network receives a call from the caller and 
+       routes the call to the donor network. 
+   (2) The donor network detects that the dialed directory number has 
+       been ported out of the donor switch and checks with an internal 
+       network-specific NPDB.  
+
+  
+Foster,McGarry,Yu           Expired on December 23, 2002      [Page 9] 
+
+Number Portability in the GSTN: An Overview               June 24, 2002 
+
+   (3) The internal NPDB returns the routing number associated with the 
+       dialed directory number. 
+   (4) The donor network uses the routing number to route the call to 
+       the new serving network. 
+ 
+    
+   +-------------+              +-----------+    Number   +-----------+ 
+   | Centralized |              | New Serv. |    porting  | Old Serv. | 
+   |    NPDB     |              |  Network  |<------------|  Network  | 
+   +-------------+              +-----------+             +-----------+ 
+                                    /\ 
+                                     | 
+                                   4.| 
+                                     | 
+    +----------+                +----------+     3.    +----------+ 
+    |   Orig.  |                |   Donor  |<----------| Internal | 
+    |  Network |--------------->|  Network |---------->|   NPDB   | 
+    +----------+      1.        +----------+    2.     +----------+ 
+    
+                   
+                 Figure 4 - Onward Routing (OR) Scheme. 
+ 
+4.5 Comparisons of the Four Schemes 
+    
+   Only the ACQ scheme does not involve the donor network when routing 
+   the call to the new serving network of the dialed ported number.  
+   The other three schemes involve call setup to or signaling with the 
+   donor network.   
+    
+   Only the OR scheme requires the setup of two physical call segments, 
+   one from the Originating Network to the donor network and the other 
+   from the donor network to the new serving network.  The OR scheme is 
+   the least efficient in terms of using the network transmission 
+   facilities.  The QoR and Dropback schemes set up calls to the donor 
+   network first but release the call back to the Originating Network 
+   that then initiates a new call to the Current Serving Network.  For 
+   the QoR and Dropback schemes, circuits are still reserved one by one 
+   between the Originating Network and the donor network when the 
+   Originating Network sets up the call towards the donor network.  
+   Those circuits are released one by one when the call is released 
+   from the donor network back to the Originating Network.  The ACQ 
+   scheme is the most efficient in terms of using the switching and 
+   transmission facilities for the call. 
+    
+   Both the ACQ and QoR schemes involve Centralized NPDBs for the 
+   Originating Network to retrieve the routing information.  
+   Centralized NPDB means that the NPDB contains ported number 
+   information from multiple networks.  This is in contrast to the 
+   internal network-specific NPDB that is used for the Dropback and OR 
+   schemes.  The internal NPDB only contains information about the 
+   numbers that were ported out of the donor network.  The internal 
+   NPDB can be a stand-alone database that contains information about 
+   all or some ported-out numbers from the donor network.  It can also 
+   reside on the donor switch and only contains information about those 
+  
+Foster,McGarry,Yu           Expired on December 23, 2002      [Page 10] 
+
+Number Portability in the GSTN: An Overview               June 24, 2002 
+
+   numbers ported out of the donor switch.  In that case, no query to a 
+   stand-alone internal NPDB is required.  The donor switch for a 
+   particular phone number is the switch to which the number range is 
+   assigned from which that phone number was originally assigned. 
+    
+   For example, number ranges in the North American Numbering Plan 
+   (NANP) are usually assigned in the form of central office codes (CO 
+   codes) comprising a six-digit prefix formatted as a NPA+NXX.  Thus a 
+   switch serving +1-202-533 would typically serve +1-202-533-0000 
+   through +1-202-533-9999. In major cities, switches usually host 
+   several CO codes.  NPA stands for Numbering Plan Area that is also 
+   known as the area code.  It is three-digit long and has the format 
+   of NXX where N is any digit from 2 to 9 and X is any digit from 0 to 
+   9.  NXX in the NPA+NXX format is known as the office code that has 
+   the same format as the NPA.  When a NPA+NXX code is set as 
+   Ÿportable÷ in the Local Exchange Routing Guide (LERG), it becomes a 
+   "portable NPA+NXX" code. 
+    
+   Similarly, in other national E.164 numbering plans, number ranges 
+   cover a contiguous range of numbers within that range.  Once a 
+   number within that range has ported away from the donor network, all 
+   numbers in that range are considered potentially ported and should 
+   be queried in the NPDB. 
+    
+   The ACQ scheme has two versions.  One version is for the Originating 
+   Network to always query the NPDB when a call is received from the 
+   caller regardless whether the dialed directory number belongs to any 
+   number range that is portable or has at least one number ported out. 
+   The other version is to check whether the dialed directory number 
+   belongs to any number range that is portable or has at least one 
+   number ported out.  If yes, an NPDB query is sent. If not, no NPDB 
+   query is sent.  The former performs better when there are many 
+   portable number ranges.  The latter performs better when there are 
+   not too many portable number ranges at the expense of checking every 
+   call to see whether NPDB query is needed.  The latter ACQ scheme is 
+   similar to the QoR scheme except that the QoR scheme uses call setup 
+   and relies on the donor network to indicate "number ported out" 
+   before launching the NPDB query. 
+    
+    
+5. Database Queries in the NP Environment 
+    
+   As indicated earlier, the ACQ and QoR schemes require that a switch 
+   query the NPDB for routing information.  Various standards have been 
+   defined for the switch-to-NPDB interface.  Those interfaces with 
+   their protocol stacks are briefly described below.  The term "NPDB" 
+   is used for a stand-alone database that may support just one or some 
+   or all of the interfaces mentioned below.  The NPDB query contains 
+   the dialed directory number and the NPDB response contains the 
+   routing number.  There are certainly other information that is sent 
+   in the query and response.  The primary interest is to get the 
+   routing number from the NPDB to the switch for call routing. 
+    
+    
+  
+Foster,McGarry,Yu           Expired on December 23, 2002      [Page 11] 
+
+Number Portability in the GSTN: An Overview               June 24, 2002 
+
+5.1 U.S. and Canada 
+    
+   One of the following five NPDB interfaces can be used to query an 
+   NPDB: 
+    
+   (a) Advanced Intelligent Network (AIN) using the American National 
+       Standards Institute (ANSI)  version of the Intelligent Network 
+       Application Part (INAP) [ANSI SS] [ANSI DB].  The INAP is 
+       carried on top of the protocol stack that includes the (ANSI) 
+       Message Transfer Part (MTP) Levels 1 through 3, ANSI Signaling 
+       Connection Control Part (SCCP), and ANSI Transaction 
+       Capabilities Application Part (TCAP).  This interface can be 
+       used by the wireline or wireless switches, is specific to the NP 
+       implementation in North America, and is modeled on the Public 
+       Office Dialing Plan (PODP) trigger defined in the Advanced 
+       Intelligent Network (AIN) 0.1 call model.  
+    
+   (b) Intelligent Network (IN), which is similar to the one used for 
+       querying the 800 databases.  The IN protocol is carried on top 
+       of the protocol stack that includes the ANSI MTP Levels 1 
+       through 3, ANSI SCCP, and ANSI TCAP.  This interface can be used 
+       by the wireline or wireless switches. 
+    
+   (c) ANSI IS-41 [IS41] [ISNP], which is carried on top of the 
+       protocol stack that includes the ANSI MTP Levels 1 through 3, 
+       ANSI SCCP, and ANSI TCAP.  This interface can be used by the IS-
+       41 based cellular/Personal Communication Services (PCS) wireless 
+       switches (e.g., AMPS, TDMA and CDMA).  Cellular systems use 
+       spectrum at 800 MHz range and PCS systems use spectrum at 1900 
+       MHz range. 
+    
+   (d) Global System for Mobile Communication Mobile Application Part 
+       (GSM MAP) [GSM], which is carried on top of the protocol stack 
+       that includes the ANSI MTP Levels 1 through 3, ANSI SCCP, and 
+       International Telecommunication Union - Telecommunication Sector  
+       (ITU-TS) TCAP.  It can be used by the PCS1900 wireless switches 
+       that are based on the GSM technologies.  GSM is a series of 
+       wireless standards defined by the European Telecommunications 
+       Standards Institute (ETSI). 
+    
+   (e) ISUP triggerless translation.  NP translations are performed 
+       transparently to the switching network by the signaling network 
+       (e.g. Signaling Transfer Points (STPs) or signaling gateways).  
+       ISUP IAM messages are examined to determine if the CdPN field 
+       has already been translated, and if not, an NPDB query is 
+       performed, and the appropriate parameters in the IAM message 
+       modified to reflect the results of the translation.   The 
+       modified IAM message is forwarded by the signaling node on to 
+       the designated DPC in a transparent manner to continue call 
+       setup.  The NPDB can be integrated with the signaling node or be 
+       accessed via an API locally or by a query to a remote NPDB using 
+       a proprietary protocol or the schemes described above. 
+    
+    
+  
+Foster,McGarry,Yu           Expired on December 23, 2002      [Page 12] 
+
+Number Portability in the GSTN: An Overview               June 24, 2002 
+
+   Wireline switches have the choice of using either (a), (b), or (e).  
+   IS-41 based wireless switches have the choice of using (a), (b), 
+   (c), or (e).  PCS1900 wireless switches have the choice of using 
+   (a), (b), (d), or (e). In the United States, service provider 
+   portability will be supported by both the wireline and wireless 
+   systems, not only within the wireline or wireless domain but also 
+   across the wireline/wireless boundary.  However, this is not true in 
+   Europe where service provider portability is usually supported only 
+   within the wireline or wireless domain, not across the 
+   wireline/wireless boundary due to explicit use of service-specific 
+   number range prefixes.  The reason is to avoid caller confusion 
+   about the call charge. GSM systems in Europe are assigned 
+   distinctive destination network codes, and the caller pays a higher 
+   charge when calling a GSM directory number. 
+    
+      
+5.2 Europe 
+    
+   One of the following two interfaces can be used to query an NPDB: 
+    
+   (a) Capability Set 1 (CS1) of the ITU-TS INAP [CS1], which is 
+       carried on top of the protocol stack that includes the ITU-TS 
+       MTP Levels 1 through 3, ITU-TS SCCP, and ITU-TS TCAP. 
+    
+   (b) Capability Set 2 (CS2) of the ITU-TS INAP [CS2], which is 
+       carried on top of the protocol stack that includes the ITU-TS 
+       MTP Levels 1 through ITU-TS MTP Levels 1 through 3, ITU-TS SCCP, 
+       and ITU-TS TCAP. 
+    
+   Wireline switches have the choice of using either (a) or (b); 
+   however, all the implementations in Europe so far are based on CS1.  
+   As indicated earlier that number portability in Europe does not go 
+   across the wireline/wireless boundary.  The wireless switches can 
+   also use (a) or (b) to query the NPDBs if those NPDBs contains 
+   ported wireless directory numbers.  The term "Mobile Number 
+   Portability (MNP)" is used for the support of service provider 
+   portability by the GSM networks in Europe.  
+    
+   In most, if not all, cases in Europe, the calls to the wireless 
+   directory numbers are routed to the wireless donor network first.  
+   Over there, an internal NPDB is queried to determine whether the 
+   dialed wireless directory number has been ported out or not.  In 
+   this case, the interface to the internal NPDB is not subject to 
+   standardization. 
+
+   MNP in Europe can also be supported via MNP Signaling Relay Function 
+   (MNP-SRF).  Again, an internal NPDB or a database integrated at the 
+   MNP-SRF is used to modify the SCCP Called Party Address parameter in 
+   the GSM MAP messages so that they can be re-directed to the wireless 
+   serving network.   Call routing involving MNP will be explained in 
+   Section 6.2. 
+    
+    
+    
+  
+Foster,McGarry,Yu           Expired on December 23, 2002      [Page 13] 
+
+Number Portability in the GSTN: An Overview               June 24, 2002 
+
+6. Call Routing in the NP Environment 
+ 
+   This section discusses the call routing after the routing 
+   information has been retrieved either through an NPDB query or an 
+   internal database lookup at the donor switch, or from the Integrated 
+   Services Digital Network User Part (ISUP) signaling message (e.g., 
+   for the Dropback scheme).  For the ACQ, QoR and Dropback schemes, it 
+   is the Originating Network that has the routing information and is 
+   ready to route the call.  For the OR scheme, it is the donor network 
+   that has the routing information and is ready to route the call.   
+    
+   A number of triggering schemes may be employed that determine where 
+   in the call path the NPDB query is performed.  In the U.S. an ŸN-1÷ 
+   policy is used, which essentially says that for domestic calls, the 
+   originating local carriers performs the query, otherwise, the long 
+   distance carrier is expected to.  To ensure independence of the 
+   actual trigger policy employed in any one carrier, forward call 
+   signaling is used to flag that an NPDB query has already been 
+   performed and to therefore suppress any subsequent NP triggers that 
+   may be encountered in downstream switches, in downstream networks.  
+   This allows the earliest able network in the call path to perform 
+   the query without introducing additional costs and call setup delays 
+   were redundant queries performed downstream. 
+    
+     
+6.1 U.S. and Canada 
+    
+   In the U.S. and Canada, a ten-digit North American Numbering Plan 
+   (NANP) number called Location Routing Number (LRN) is assigned to 
+   every switch involved in NP.  In the NANP, a switch is not reachable 
+   unless it has a unique number range (CO code) assigned to it.  
+   Consequently, the LRN for a switch is always assigned out of a CO 
+   code that is assigned to that switch. 
+    
+   The LRN assigned to a switch currently serving a particular ported 
+   telephone number is returned as the network routing address in the 
+   NPDB response.  The service portability scheme that was adopted in 
+   the North America is very often referred to as the LRN scheme or 
+   method. 
+    
+   LRN serves as a network address for terminating calls served off 
+   that switch using ported numbers.  The LRN is assigned by the switch 
+   operator using any of the unique CO codes (NPA+NXX) assigned to that 
+   switch.  The LRN is considered a non-dialable address, as the same 
+   10-digit number value may be assigned to a line on that switch.  A 
+   switch may have more than one LRN. 
+    
+   During call routing/processing, a switch performs an NPDB query to 
+   obtain the LRN associated with the dialed directory number. NPDB 
+   queries are performed for all the dialed directory numbers whose 
+   NPA+NXX codes are marked as portable NPA+NXX at that switch. When 
+   formulating the ISUP Initial Address Message (IAM) to be sent to the 
+   next switch, the switch puts the ten-digit LRN in the ISUP Called 
+   Party Number (CdPN) parameter and the originally dialed directory 
+  
+Foster,McGarry,Yu           Expired on December 23, 2002      [Page 14] 
+
+Number Portability in the GSTN: An Overview               June 24, 2002 
+
+   number in the ISUP Generic Address parameter (GAP).  A new code in 
+   the GAP was defined to indicate that the address information in the 
+   GAP is the dialed directory number. A new bit in the ISUP Forward 
+   Call Indicator (FCI) parameter, the Ported Number Translation 
+   Indicator (PNTI) bit, is set to imply that NPDB query has already 
+   been performed.  All the switches in the downstream will not perform 
+   the NPDB query if the PNTI bit is set. 
+    
+   When the terminating switch receives the IAM and sees the PNTI bit 
+   in the FCI parameter set and its own LRN in the CdPN parameter, it 
+   retrieves the originally dialed directory number from the GAP and 
+   uses the dialed directory number to terminate the call. 
+    
+   A dialed directory number with a portable NPA+NXX does not imply 
+   that directory number has been ported.  The NPDBs currently do not 
+   store records for non-ported directory numbers.  In that case, the 
+   NPDB will return the same dialed directory number instead of the 
+   LRN.  The switch will then set the PNTI bit but keep the dialed 
+   directory number in the CdPN parameter. 
+    
+   In the real world environment, the Originating Network is not always 
+   the one that performs the NPDB query.  For example, it is usually 
+   the long distance carriers that query the NPDBs for long distance 
+   calls.  In that case, the Originating Network operated by the local 
+   exchange carrier (LEC) simply routes the call to the long distance 
+   carrier that is to handle that call.   A wireless network acting as 
+   the Originating Network can also route the call to the 
+   interconnected local exchange carrier network if it does not want to 
+   support the NPDB interface at its mobile switches. 
+    
+    
+6.2 Europe 
+    
+   In some European countries, a routing number is prefixed to the 
+   dialed directory number.  The ISUP CdPN parameter in the IAM will 
+   contain the routing prefix and the dialed directory number.  For 
+   example, United Kingdom uses routing prefixes with the format of 
+   5XXXXX and Italy uses C600XXXXX as the routing prefix.  The networks 
+   use the information in the ISUP CdPN parameter to route the call to 
+   the New/Current Serving Network. 
+    
+   The routing prefix can identify the Current Serving Network or the 
+   Current Serving Switch of a ported number.  For the former case, 
+   another query to the "internal" NPDB at the Current Serving Network 
+   is required to identify the Current Serving Switch before routing 
+   the call to that switch.  This shields the Current Serving Switch 
+   information for a ported number from the other networks at the 
+   expense of an additional NPDB query.  Another routing number, may be 
+   meaningful within the Current Serving Network, will replace the 
+   previously prefixed routing number in the ISUP CdPN parameter.  For 
+   the latter case, the call is routed to the Current Serving Switch 
+   without an additional NPDB query. 
+    
+
+  
+Foster,McGarry,Yu           Expired on December 23, 2002      [Page 15] 
+
+Number Portability in the GSTN: An Overview               June 24, 2002 
+
+   When the terminating switch receives the IAM and sees its own 
+   routing prefix in the CdPN parameter, it retrieves the originally 
+   dialed directory number after the routing prefix, and uses the 
+   dialed directory number to terminate the call.  
+    
+   The call routing example described above shows one of the three 
+   methods that can be used to transport the Directory Number (DN) and 
+   the Routing Number (RN) in the ISUP IAM message.  In addition, some 
+   other information may be added/modified as is listed in the ETSI 302 
+   097 document [ETSIISUP], which is based on the ITU-T Recommendation 
+   Q.769.1 [ITUISUP].  The three methods and the enhancements in the 
+   ISUP to support number portability are briefly described below 
+    
+   (a) Two separate parameters with the CdPN parameter containing the 
+      RN and a new Called Directory Number (CdDN) parameter containing 
+      the DN.  A new value for the Nature of Address (NOA) indicator in 
+      the CdPN parameter is defined to indicate that the RN is in the 
+      CdPN parameter.  The switches use the CdPN parameter to route the 
+      call as is done today. 
+    
+   (b) Two separate parameters with the CdPN parameter containing the 
+      DN and a new Network Routing Number (NRN) parameter containing 
+      the RN.  This method requires that the switches use the NRN 
+      parameter to route the call. 
+    
+   (c) Concatenated parameter with the CdPN parameter containing the RN 
+      plus the DN.  A new Nature of Address (NOA) indicator in the CdPN 
+      parameter is defined to indicate that the RN is concatenated with 
+      the DN in the CdPN parameter.  Some countries may not use new NOA 
+      value because the routing prefix does not overlap with the dialed 
+      directory numbers.  But if the routing prefix overlaps with the 
+      dialed directory numbers, a new NOA value must be assigned.  For 
+      example, Spain uses "XXXXXX" as the routing prefix to identify 
+      the new serving network and uses a new NOA value of 126. 
+    
+   There is also a network option to add a new ISUP parameter called 
+   Number Portability Forwarding Information parameter.  This parameter 
+   has a four-bit Number Portability Status Indicator field that can 
+   provide an indication whether number portability query is done for 
+   the called directory number and whether the called directory number 
+   is ported or not if the number portability query is done. 
+ 
+   Please note that all those NP enhancements for a ported number can 
+   only be used in the country that defined them.  This is because 
+   number portability is supported within a nation.  Within each 
+   nation, the telecommunications industry or the regulatory bodies can 
+   decide which method or methods to use.  Number portability related 
+   parameters and coding are usually not passed across the national 
+   boundaries unless the interconnection agreements allow that.  For 
+   example, a UK routing prefix can only be used in UK, and would cause 
+   routing problem if it appears outside UK. 
+    
+
+
+  
+Foster,McGarry,Yu           Expired on December 23, 2002      [Page 16] 
+
+Number Portability in the GSTN: An Overview               June 24, 2002 
+
+   As indicated earlier, an originating wireless network can query the 
+   NPDB and concatenate the RN with DN in the CdPN parameter and route 
+   the call directly to the Current Serving Network.   
+    
+   If NPDBs do not contain information about the wireless directory 
+   numbers, the call, originated from either a wireline or a wireless 
+   network, will be routed to the Wireless donor network.  Over there, 
+   an internal NPDB is queried to retrieve the RN that then is 
+   concatenated with the DN in the CdPN parameter. 
+    
+   There are several ways of realizing MNP.  When MNP-SRF is supported, 
+   the Gateway Mobile Services Switching Center (GMSC) at the wireless 
+   donor network, when receiving a call from the wireline network, can 
+   send the GSM MAP Send Routing Information (SRI) message to the MNP-
+   SRF.  The MNP-SRF interrogates an internal or integrated NPDB for 
+   the RN of the MNP-SRF of the wireless Current Serving Network and 
+   prefixes the RN to the dialed wireless directory number in the 
+   global title address information in the SCCP Called Party Address 
+   (CdPA) parameter.  This SRI message will be routed to the MNP-SRF of 
+   the wireless Current Serving Network, which then responds with an 
+   acknowledgement by providing the RN plus the dialed wireless 
+   directory number as the Mobile Station Roaming Number (MSRN).  The 
+   GMSC of the wireless donor network formulates the ISUP IAM with the 
+   RN plus the dialed wireless directory number in the CdPN parameter 
+   and routes the call to the wireless Current Serving Network.  A GMSC 
+   of the wireless Current Serving Network receives the call and sends 
+   an SRI message to the associated MNP-SRF where the global title 
+   address information of the SCCP CdPA parameter contains only the 
+   dialed wireless directory number.  The MNP-SRF then replaces the 
+   global title address information in the SCCP CdPA parameter with the 
+   address information associated with a Home Location Register (HLR) 
+   that hosts the dialed wireless directory number and forwards the 
+   message to that HLR after verifying that the dialed wireless 
+   directory number is a ported-in number.   The HLR then returns an 
+   acknowledgement by providing an MSRN for the GMSC to route the call 
+   to the MSC that currently serves the mobile station that is 
+   associated with the dialed wireless directory number.  Please see 
+   [MNP] for details and additional scenarios. 
+    
+    
+7. NP Implementations for Geographic E.164 Numbers 
+ 
+   This section shows the known SPNP implementations worldwide.  
+    
+   +-------------+----------------------------------------------------+ 
+   +   Country   +             SPNP Implementation                    + 
+   +-------------+----------------------------------------------------+ 
+   +  Argentina  + Analyzing operative viability now. Will determine  + 
+   +             + whether portability should be made obligatory      + 
+   +             + after a technical solution has been determined.    + 
+   +-------------+----------------------------------------------------+ 
+   +  Australia  + NP supported by wireline operators since 11/30/99. + 
+   +             + NP among wireless operators in March/April 2000,   + 
+
+  
+Foster,McGarry,Yu           Expired on December 23, 2002      [Page 17] 
+
+Number Portability in the GSTN: An Overview               June 24, 2002 
+
+   +             + but may be delayed to 1Q01. The access provider    + 
+   +             + or long distance provider has the obligation to    + 
+   +             + route the call to the correct destination. The     + 
+   +             + donor network is obligated to maintain and make    + 
+   +             + available a register of numbers ported away from   +  
+   +             + its network.  Telstra uses onward routing via an   + 
+   +             + on-switch solution.                                + 
+   +-------------+----------------------------------------------------+ 
+   +   Austria   + Uses onward routing at the donor network.  Routing + 
+   +             + prefix is "86xx" where "xx" identifies the         + 
+   +             + recipient network.                                 + 
+   +-------------+----------------------------------------------------+ 
+   +  Belgium    + ACQ selected by the industry. Routing prefix is    + 
+   +             + "Cxxxx" where "xxxx" identifies the recipient      + 
+   +             + switch. Another routing prefix is "C00xx" with "xx"+ 
+   +             + identifying the recipient network.  Plan to use NOA+ 
+   +             + to identify concatenated numbers and abandon the   + 
+   +             + hexadecimal routing prefix.                        + 
+   +-------------+----------------------------------------------------+ 
+   +  Brazil     + Considering NP for wireless users.                 + 
+   +-------------+----------------------------------------------------+ 
+   +  Chile      + There has been discussions lately on NP.           + 
+   +-------------+----------------------------------------------------+ 
+   +  Colombia   + There was an Article 3.1 on NP to support NP prior + 
+   +             + to December 31, 1999 when NP became technically    + 
+   +             + possible. Regulator has not yet issued regulations + 
+   +             + concerning this matter.                            + 
+   +-------------+----------------------------------------------------+ 
+   +  Denmark    + Uses ACQ. Routing number not passed between        + 
+   +             + operators; however, NOA is set to "112" to         + 
+   +             + indicate "ported number."  QoR can be used based   + 
+   +             + on bilateral agreements.                           +        
+   +-------------+----------------------------------------------------+ 
+   +  Finland    + Uses ACQ.  Routing prefix is "1Dxxy" where "xxy"   + 
+   +             + identifies the recipient network and service type. + 
+   +-------------+----------------------------------------------------+ 
+   +  France     + Uses onward routing.  Routing prefix is "Z0xxx"    + 
+   +             + where "xxx" identifies the recipient switch.       + 
+   +-------------+----------------------------------------------------+ 
+   +  Germany    + The originating network needs to do necessary      + 
+   +             + rerouting.  Operators decide their own solution(s).+ 
+   +             + Deutsche Telekom uses ACQ.  Routing prefix is      + 
+   +             + "Dxxx" where "xxx" identifies the recipient        + 
+   +             + network.                                           + 
+   +-------------+----------------------------------------------------+ 
+   +  Hong Kong  + Recipient network informs other networks about     + 
+   +             + ported-in numbers.  Routing prefix is "14x" where  + 
+   +             + "14x" identifies the recipient network, or a       + 
+   +             + routing number of "4x" plus 7 or 8 digits is used  +  
+   +             + where "4x" identifies the recipient network and    + 
+   +             + the rest of digits identify the called party.      + 
+   +-------------+----------------------------------------------------+ 
+   +  Ireland    + Operators choose their own solution but use onward + 
+   +             + routing now. Routing prefix is "1750" as the intra-+ 
+  
+Foster,McGarry,Yu           Expired on December 23, 2002      [Page 18] 
+
+Number Portability in the GSTN: An Overview               June 24, 2002 
+
+   +             + network routing code (network-specific) and        + 
+   +             + "1752xxx" to "1759xxx" for GNP where "xxx"         + 
+   +             + identifies the recipient switch.                   + 
+   +-------------+----------------------------------------------------+ 
+   +  Italy      + Uses onward routing. Routing prefix is "C600xxxxx" + 
+   +             + where "xxxxx" identifies the recipient switch.     + 
+   +             + Telecom Italia uses IN solution and other operators+              
+   +             + use on-switch solution.                            + 
+   +-------------+----------------------------------------------------+ 
+   +  Japan      + Uses onward routing.  Donor switch uses IN to get  + 
+   +             + routing number.                                    + 
+   +-------------+----------------------------------------------------+ 
+   +  Mexico     + NP is considered in the Telecom law; however, the  + 
+   +             + regulator (Cofetel) or the new local entrants have + 
+   +             + started no initiatives on this process.            + 
+   +-------------+----------------------------------------------------+ 
+   + Netherlands + Operators decide NP scheme to use.  Operators have + 
+   +             + chosen ACQ or QoR.  KPN implemented IN solution    + 
+   +             + similar to U.S. solution.  Routing prefix is not   + 
+   +             + passed between operators.                          + 
+   +-------------+----------------------------------------------------+ 
+   +  Norway     + OR for short-term and ACQ for long-term.  QoR is   + 
+   +             + optional. Routing prefix can be "xxx" with NOA=8,  + 
+   +             + or "142xx" with NOA=3 where "xxx" or "xx"          + 
+   +             + identifies the recipient network.                  + 
+   +------------ +----------------------------------------------------+ 
+   +  Peru       + Wireline NP may be supported in 2001.              + 
+   +-------------+----------------------------------------------------+ 
+   +  Portugal   + No NP today.                                       + 
+   +-------------+----------------------------------------------------+ 
+   +  Spain      + Uses ACQ.  Telefonica uses QoR within its network. + 
+   +             + Routing prefix is  "xxyyzz" where "xxyyzz"         + 
+   +             + identifies the recipient network.  NOA is set to   + 
+   +             + 126.                                               + 
+   +-------------+----------------------------------------------------+ 
+   +  Sweden     + Standardized the ACQ but OR for operators without  + 
+   +             + IN. Routing prefix is "xxx" with NOA=8 or "394xxx" + 
+   +             + with NOA=3 where "xxx" identifies the recipient    + 
+   +             + network. But operators decide NP scheme to use.    + 
+   +             + Telia uses onward routing between operators.       + 
+   +-------------+----------------------------------------------------+ 
+   + Switzerland + Uses OR now and QoR in 2001.  Routing prefix is    + 
+   +             + "980xxx" where "xxx" identifies the recipient      +        
+   +             + network.                                           + 
+   +-------------+----------------------------------------------------+ 
+   +  UK         + Uses onward routing. Routing prefix is "5xxxxx"    + 
+   +             + where "xxxxx" identifies the recipient switch. NOA + 
+   +             + is 126. BT uses the dropback scheme in some parts  + 
+   +             + of its network.                                    + 
+   +-------------+----------------------------------------------------+ 
+   +  US         + Uses ACQ.  "Location Routing Number (LRN)" is used + 
+   +             + in the Called Party Number parameter.  Called party+ 
+   +             + number is carried in the Generic Address Parameter + 
+   +             + Use a PNTI indicator in the Forward Call Indicator + 
+  
+Foster,McGarry,Yu           Expired on December 23, 2002      [Page 19] 
+
+Number Portability in the GSTN: An Overview               June 24, 2002 
+
+   +             + parameter to indicate that NPDB dip has been       + 
+   +             + performed.                                         + 
+   +-------------+----------------------------------------------------+ 
+    
+    
+8. Number Conservation Methods Enabled by NP 
+ 
+   In addition to porting numbers NP provides the ability for number 
+   administrators to assign numbering resources to operators in smaller 
+   increments.  Today it is common for numbering resources to be 
+   assigned to telephone operators in a large block of consecutive 
+   telephone numbers (TNs).  For example, in North America each of 
+   these blocks contains 10,000 TNs and is of the format NXX+0000 to 
+   NXX+9999.  Operators are assigned a specific NXX, or block.  That 
+   operator is referred to as the block holder.  In that block there 
+   are 10,000 TNs with line numbers ranging from 0000 to 9999.   
+    
+   Instead of assigning an entire block to the operator NP allows the 
+   administrator to assign a sub-block or even an individual telephone 
+   number.  This is referred to as block pooling and individual 
+   telephone number (ITN) pooling, respectively.  
+     
+    
+8.1 Block Pooling 
+    
+   Block Pooling refers to the process whereby the number administrator 
+   assigns a range of numbers defined by a logical sub-block of the 
+   existing block.  Using North America as an example, block pooling 
+   would allow the administrator to assign sub-blocks of 1,000 TNs to 
+   multiple operators.  That is, NXX+0000 to NXX+0999 can be assigned 
+   to operator A, NXX+1000 to NXX+1999 can be assigned to operator B, 
+   NXX-2000 to 2999 can be assigned to operator C, etc.  In this 
+   example block pooling divides one block of 10,000 TNs into ten 
+   blocks of 1,000 TNs.   
+    
+   Porting the sub-blocks from the block holder enables block pooling.  
+   Using the example above operator A is the block holder, as well as, 
+   the holder of the first sub-block, NXX+0000 to NXX+0999.  The second 
+   sub-block, NXX+1000 to NXX+1999, is ported from operator A to 
+   operator B.  The third sub-block, NXX+2000 to NXX+2999, is ported 
+   from operator A to operator C, and so on.  NP administrative 
+   processes and call processing will enable proper and efficient 
+   routing.   
+    
+   From a number administration and NP administration perspective block 
+   pooling introduces a new concept, that of the sub-block holder.  
+   Block pooling requires coordination between the number 
+   administrator, the NP administrator, the block holder, and the sub-
+   block holder.  Block pooling must be implemented in a manner that 
+   allows for NP within the sub-blocks.  Each TN can have a different 
+   serving operator, sub-block holder, and block holder. 
+      
+    
+    
+  
+Foster,McGarry,Yu           Expired on December 23, 2002      [Page 20] 
+
+Number Portability in the GSTN: An Overview               June 24, 2002 
+
+8.2 ITN Pooling 
+    
+   ITN pooling refers to the process whereby the number administrator 
+   assigns individual telephone numbers to operators.  Using the North 
+   American example, one block of 10,000 TNs can be divided into 10,000 
+   ITNs.  ITN is more commonly deployed in freephone services.   
+    
+   In ITN the block is not assigned to an operator but to a central 
+   administrator.  The administrator then assigns ITNs to operators.  
+   NP administrative processes and call processing will enable proper 
+   and efficient routing. 
+    
+ 
+9. Potential Implications 
+    
+   There are three general areas of impact to IP telephony work-in-
+   progress at IETF: 
+    
+   - Interoperation between NP in GSTN and IP telephony 
+   - NP implementation or emulation in IP telephony 
+   - Interconnection to NP administrative environment 
+    
+   A good understanding of how number portability is supported in the 
+   GSTN is important when addressing the interworking issues between 
+   IP-based networks and the GSTN.  This is especially important when 
+   the IP-based network needs to route the calls to the GSTN.  As shown 
+   in Section 5, there are a variety of standards with various protocol 
+   stacks for the switch-to-NPDB interface.  Not only that, the 
+   national variations of the protocol standards make it very 
+   complicated to deal with in a global environment.  If an entity in 
+   the IP-based network needs to query those existing NPDBs for routing 
+   number information to terminate the calls to the destination GSTN, 
+   it would be impractical, if not an impossible, job for that entity 
+   to support all those interface standards to access the NPDBs in many 
+   countries. 
+    
+   Several alternatives may address this particular problem.  One 
+   alternative is to use certain entities in the IP-based networks for 
+   dealing with NP query, similar to the International Switches that 
+   are used in the GSTN to interwork different national ISUP 
+   variations.  This will force signaling information associated with 
+   the calls to certain NP-capable networks in the terminating GSTN to 
+   be routed to those IP entities that support the NP functions.  Those 
+   IP entities then query the NPDBs in the terminating country.   This 
+   will limit the number of NPDB interfaces that certain IP entities 
+   need to support.  Another alternative can be to define a "common" 
+   interface to be supported by all the NPDBs so that all the IP 
+   entities use that standardized protocol to query them.   The 
+   existing NPDBs can support this additional interface, or new NPDBs 
+   can be deployed that contain the same information but support the 
+   common IP interface. The candidates for such a common interface 
+   include Lightweight Directory Access Protocol (LDAP) and SIP 
+   [SIP](e.g., using the SIP redirection capability).  Certainly 
+
+  
+Foster,McGarry,Yu           Expired on December 23, 2002      [Page 21] 
+
+Number Portability in the GSTN: An Overview               June 24, 2002 
+
+   another possibility is to use interworking function to convert from 
+   one protocol to another. 
+    
+   IP-based networks can handle the domestic calls between two GSTNs.  
+   If the originating GSTN has performed NPDB query, SIP will need to 
+   transport and make use of some of the ISUP signaling information 
+   even if ISUP signaling may be encapsulated in SIP.  Also, IP-based 
+   networks may perform the NPDB queries, as the N-1 carrier.  In that 
+   case, SIP also needs to transport the NP related information while 
+   the call is being routed to the destination GSTN.  There are three 
+   pieces of NP related information that SIP needs to transport.  They 
+   are 1) the called directory number, 2) a routing number, and 3) a 
+   NPDB dip indicator.  The NPDB dip indicator is needed so that the 
+   terminating GSTN will not perform another NPDB dip.  The routing 
+   number is needed so that it is used to route the call to the 
+   destination network or switch in the destination GSTN.  The called 
+   directory number is needed so that the terminating GSTN switch can 
+   terminate the call.  When the routing number is present, the NPDB 
+   dip indicator may not be present because there are cases where 
+   routing number is added for routing the call even if NP is not 
+   involved.  One issue is how to transport the NP related information 
+   via SIP.  The SIP Universal Resource Locator (URL) is one mechanism.  
+   Another better choice may be to add an extension to the "tel" URL 
+   [TEL] that is also supported by SIP.  Please see [TELNP] for the 
+   proposed extensions to the "tel" URL to support NP and freephone 
+   service.  Those extensions to the "tel" URL will be automatically 
+   supported by SIP because they can be carried as the optional 
+   parameters in the user portion of the "sip" URL. 
+    
+   For a called directory number that belongs to a country that 
+   supports NP, and if the IP-based network is to perform the NPDB 
+   query, the logical step is to perform the NPDB dip first to retrieve 
+   the routing number and use that routing number to select the correct 
+   IP telephony gateways that can reach the serving switch that serves 
+   the called directory number.  Therefore, if the "rn" parameter is 
+   present in the "tel" URL or sip URL in the SIP INVITE message, it 
+   instead of the called directory number should be used for making 
+   routing decisions assuming that no other higher priority routing-
+   related parameters such as the Ÿcic÷ are present.  If "rn" is not 
+   present, then the dialed directory number can be used as the routing 
+   number for making routing decisions.   
+    
+   Telephony Routing Information Protocol (TRIP) [TRIP] is a policy 
+   driven inter-administrative domain protocol for advertising the 
+   reachability of telephony destinations between location servers, and 
+   for advertising attributes of the routes to those destinations.  
+   With the NP in mind, it is very important to know that it is the 
+   routing number, if present, not the called directory number that 
+   should be used to check against the TRIP tables for making the 
+   routing decisions.   
+    
+   Overlap signaling exists in the GSTN today.  For a call routing from 
+   the originating GSTN to the IP-based network that involves overlap 
+   signaling, NP will impact the call processing within the IP-based 
+  
+Foster,McGarry,Yu           Expired on December 23, 2002      [Page 22] 
+
+Number Portability in the GSTN: An Overview               June 24, 2002 
+
+   networks if they must deal with the overlap signaling.  The entities 
+   in the IP-based networks that are to retrieve the NP information 
+   (e.g., the routing number) must collect a complete called directory 
+   number information before retrieving the NP information for a ported 
+   number.  Otherwise, the information retrieval won't be successful.   
+   This is an issue for the IP-based networks if the originating GSTN 
+   does not handle the overlap signaling by collecting the complete 
+   called directory number. 
+    
+   The IETF enum working group is defining the use of Domain Name 
+   System (DNS) for identifying available services associated with a 
+   particular E.164 number [ENUM].  [ENUMPO] outlines the principles 
+   for the operation of a telephone number service that resolves 
+   telephone numbers into Internet domain name addresses and service-
+   specific directory discovery.  [ENUMPO] implements a three-level 
+   approach where the first level is the mapping of the telephone 
+   number delegation tree to the authority to which the number has been 
+   delegated, the second level is the provision of the requested DNS 
+   resource records from a service registrar, and the third level is 
+   the provision of service specific data from the service provider 
+   itself.  NP certainly must be considered at the first level because 
+   the telephony service providers do not "own" or control the 
+   telephone numbers under the NP environment; therefore, they may not 
+   be the proper entities to have the authority for a given E.164 
+   number.  Not only that, there is a regulatory requirement on NP in 
+   some countries that the donor network should not be relied on to 
+   reach the delegated authority during the DNS process .  The 
+   delegated authority for a given E.164 number is likely to be an 
+   entity designated by the end user that owns/controls a specific 
+   telephone number or one that is designated by the service registrar. 
+    
+   Since the telephony service providers may have the need to use ENUM 
+   for their network-related services (e.g., map an E.164 number to a 
+   HLR Identifier in the wireless networks), their ENUM records must be 
+   collocated with those of the telephony subscribers.  If that is the 
+   case, NP will impact ENUM when a telephony subscriber who has ENUM 
+   service changes the telephony service provider.  This is because 
+   that the ENUM records from the new telephony service provider must 
+   replace those from the old telephony service provider.  To avoid the 
+   NP impact on ENUM, it is recommended that the telephony service 
+   providers use a different domain tree for their network-related 
+   service.  For example, if e164.arpa is chosen for Ÿend user÷ ENUM, a 
+   domain tree different from e164.arpa should be used for Ÿcarrier÷ 
+   ENUM. 
+    
+   The IP-based networks also may need to support some forms of number 
+   portability in the future if E.164 numbers [E164] are assigned to 
+   the IP-based end users.  One method is to assign a GSTN routing 
+   number for each IP-based network domain or entity in a NP-capable 
+   country.  This may increase the number of digits in the routing 
+   number to incorporate the IP entities and impact the existing 
+   routing in the GSTN.  Another method is to associate each IP entity 
+   with a particular GSTN gateway.  At that particular GSTN gateway, 
+   the called directory number then is used to locate the IP-entity 
+  
+Foster,McGarry,Yu           Expired on December 23, 2002      [Page 23] 
+
+Number Portability in the GSTN: An Overview               June 24, 2002 
+
+   that serves that dialed directory number.  Yet, another method can 
+   be to assign a special routing number so that the call to an end 
+   user currently served by an IP entity is routed to the nearest GSTN 
+   gateway.  The called directory number then is used to locate the IP-
+   entity that serves that dialed directory number.  A mechanism can be 
+   developed or used for the IP-based network to locate the IP entity 
+   that serves a particular dialed directory number.  Many other types 
+   of networks use E.164 numbers to identify the end users or terminals 
+   in those networks.  Number portability among GSTN, IP-based network 
+   and those various types of networks may also need to be supported in 
+   the future. 
+    
+ 
+10. Security Considerations 
+ 
+   This document does not raise any security issues. 
+ 
+ 
+11. IANA Considerations 
+ 
+   This document introduces no new values for IANA registration. 
+    
+ 
+12. Normative References  
+ 
+   [ANSI OSS] ANSI Technical Requirements No. 1, "Number Portability -
+        Operator Services Switching Systems," April 1999. 
+    
+   [ANSI SS] ANSI Technical Requirements No. 2, "Number Portability -
+        Switching Systems," April 1999. 
+             
+   [ANSI DB] ANSI Technical Requirements No. 3, "Number Portability 
+        Database and Global Title Translation," April 1999.         
+          
+   [CS1] ITU-T Q-series  Recommendations - Supplement 4, "Number 
+        portability Capability set 1 requirements for service provider 
+        portability (All call query and onward routing)," May 1998. 
+    
+   [CS2] ITU-T Q-series  Recommendations - Supplement 5, "Number 
+        portability -Capability set 2 requirements for service provider 
+        portability (Query on release and Dropback)," March 1999. 
+    
+   [E164] ITU-T Recommendation E.164, "The International Public 
+        Telecommunications Numbering Plan," 1997. 
+    
+   [ENUM] P. Falstrom, "E.164 number and DNS," RFC 2916. 
+    
+   [ETSIISUP] ETSI EN 302 097 V.1.2.2, ŸIntegrated Services Digital 
+        Network (ISDN); Signalling System No.7 (SS7); ISDN User Part 
+        (ISUP); Enhancement for support of Number Portability (NP) 
+        [ITU-T Recommendation Q.769.1 (2000), modified] 
+    
+   [GSM]  GSM 09.02: "Digital cellular telecommunications system (Phase 
+        2+); Mobile Application Part (MAP) specification". 
+  
+Foster,McGarry,Yu           Expired on December 23, 2002      [Page 24] 
+
+Number Portability in the GSTN: An Overview              March 1, 2002 
+ 
+ 
+ 
+   [IS41] TIA/EIA IS-756 Rev. A, "TIA/EIA-41-D Enhancements for 
+        Wireless Number Portability Phase II (December 1998)"Number 
+        Portability Network Support," April 1998. 
+    
+   [ITUISUP] ITU-T Recommendation Q.769.1, "Signaling System No. 7 - 
+        ISDN User Part Enhancements for the Support of Number 
+        Portability," December 1999. 
+    
+   [MNP] ETSI EN 301 716 (2000-10) European Standard 
+        (Telecommunications series) Digital cellular telecommunications 
+        system (Phase 2+); Support of Mobile Number Portability (MNP); 
+        Technical Realisation; Stage 2; (GSM 03.66 Version 7.2.0 
+        Release 1998). 
+    
+   [RFC] Scott Bradner, RFC2026, "The Internet Standards Process -- 
+        Revision 3," October 1996. 
+    
+ 
+13. Informative References  
+ 
+   [ENUMPO] A. Brown and G. Vaudreuil, "ENUM Service Specific 
+        Provisioning: Principles of Operations," draft-ietf-enum-
+        operation-02.txt, February 23, 2001. 
+    
+   [SIP] J. Rosenberg, et al., draft-ietf-sip-rfc2543bis-09.txt, "SIP: 
+        Session Initiation Protocol," February 27, 2002. 
+    
+   [TEL] H. Schulzrinne and A. Vaha-Sipila, draft-antti-rfc2806bis-
+        04.txt, "URIs for Telephone Calls," May 24, 2002. 
+ 
+   [TELNP] J. Yu, draft-yu-tel-url-05.txt, "Extensions to the "tel" URL 
+        to support Number Portability and Freephone Service," June 14, 
+        2002. 
+    
+   [TRIP] J. Rosenberg, H. Salama and M. Squire, RFC 3219, "Telephony 
+        Routing Information Protocol (TRIP)," January 2002. 
+    
+    
+14. Acknowledgment 
+    
+   The authors would like to thank Monika Muench for providing 
+   information on ISUP and MNP. 
+    
+    
+15. Authors' Addresses 
+    
+   Mark D. Foster 
+   NeuStar, Inc. 
+   1120 Vermont Avenue, NW, 
+   Suite 400 
+   Washington, D.C. 20005 
+   United States 
+  
+Foster,McGarry,Yu           Expired on August 31, 2002        [Page 25] 
+
+Number Portability in the GSTN: An Overview              March 1, 2002 
+ 
+ 
+    
+   Phone: +1-202-533-2800 
+   Fax:   +1-202-533-2987 
+   Email: mark.foster@neustar.biz 
+          
+   Tom McGarry 
+   NeuStar, Inc. 
+   1120 Vermont Avenue, NW, 
+   Suite 400 
+   Washington, D.C. 20005 
+   United States 
+    
+   Phone: +1-202-533-2810 
+   Fax:   +1-202-533-2987 
+   Email: tom.mcgarry@neustar.biz 
+    
+   James Yu 
+   NeuStar, Inc. 
+   1120 Vermont Avenue, NW,  
+   Suite 400 
+   Washington, D.C. 20005 
+   United States 
+    
+   Phone: +1-202-533-2814 
+   Fax:   +1-202-533-2987 
+   Email: james.yu@neustar.biz 
+    
+    
+    
+Full Copyright Statement 
+ 
+   "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 Standards process must be 
+   followed, or as required to translate it into 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. 
+    
+
+  
+Foster,McGarry,Yu           Expired on August 31, 2002        [Page 26] 
+
+Number Portability in the GSTN: An Overview              March 1, 2002 
+ 
+ 
+   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. 
+    
+    
+Acknowledgement 
+ 
+   Funding for the RFC Editor function is currently provided by the 
+   Internet Society. 
+ 
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+  
+Foster,McGarry,Yu           Expired on August 31, 2002        [Page 27] 
+
\ No newline at end of file
diff --git a/doc/draft/draft-ietf-ipv6-node-requirements-08.txt b/doc/draft/draft-ietf-ipv6-node-requirements-08.txt
new file mode 100644
index 0000000..2d5c87e
--- /dev/null
+++ b/doc/draft/draft-ietf-ipv6-node-requirements-08.txt
@@ -0,0 +1,1200 @@
+
+
+
+
+
+
+IPv6 Working Group                                 John Loughney (ed)
+Internet-Draft                                                  Nokia
+                                                     January 14, 2004
+
+Expires: July 14, 2004
+
+
+
+                         IPv6 Node Requirements
+                draft-ietf-ipv6-node-requirements-08.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 draft documents 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 "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/ietf/1id-abstracts.txt.
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2003).  All Rights Reserved.
+
+Abstract
+
+   This document defines requirements for IPv6 nodes.  It is expected
+   that IPv6 will be deployed in a wide range of devices and situations.
+   Specifying the requirements for IPv6 nodes allows IPv6 to function
+   well and interoperate in a large number of situations and
+   deployments.
+
+
+
+
+
+Loughney (editor)          February 16, 2004                    [Page 1]
+
+
+
+
+
+Internet-Draft
+
+
+Table of Contents
+
+   1.   Introduction
+   1.1 Requirement Language
+   1.2  Scope of this Document
+   1.3  Description of IPv6 Nodes
+   2.   Abbreviations Used in This Document
+   3.   Sub-IP Layer
+   3.1  Transmission of IPv6 Packets over Ethernet Networks - RFC2464
+   3.2  IP version 6 over PPP - RFC2472
+   3.3  IPv6 over ATM Networks - RFC2492
+   4.   IP Layer
+   4.1  Internet Protocol Version 6 - RFC2460
+   4.2  Neighbor Discovery for IPv6 - RFC2461
+   4.3  Path MTU Discovery & Packet Size
+   4.4  ICMP for the Internet Protocol Version 6 (IPv6) - RFC2463
+   4.5  Addressing
+   4.6  Multicast Listener Discovery (MLD) for IPv6 - RFC2710
+   5.   Transport and DNS
+   5.1  Transport Layer
+   5.2  DNS
+   5.3  Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
+   6.   IPv4 Support and Transition
+   6.1  Transition Mechanisms
+   7.   Mobility
+   8.   Security
+   8.1  Basic Architecture
+   8.2  Security Protocols
+   8.3  Transforms and Algorithms
+   8.4  Key Management Methods
+   9.   Router Functionality
+   9.1  General
+   10.  Network Management
+   10.1 MIBs
+   11.  Security Considerations
+   12.  References
+   12.1 Normative
+   12.2 Non-Normative
+   13.  Authors and Acknowledgements
+   14.  Editor's Address
+   Notices
+
+
+
+
+
+
+
+
+
+
+Loughney (editor)          February 16, 2004                    [Page 2]
+
+
+
+
+
+Internet-Draft
+
+
+1. Introduction
+
+   The goal of this document is to define the common functionality
+   required from both IPv6 hosts and routers.  Many IPv6 nodes will
+   implement optional or additional features, but all IPv6 nodes can be
+   expected to implement the mandatory requirements listed in this
+   document.
+
+   This document tries to avoid discussion of protocol details, and
+   references RFCs for this purpose.  In case of any conflicting text,
+   this document takes less precedence than the normative RFCs, unless
+   additional clarifying text is included in this document.
+
+   Although the document points to different specifications, it should
+   be noted that in most cases, the granularity of requirements are
+   smaller than a single specification, as many specifications define
+   multiple, independent pieces, some of which may not be mandatory.
+
+   As it is not always possible for an implementer to know the exact
+   usage of IPv6 in a node, an overriding requirement for IPv6 nodes is
+   that they should adhere to Jon Postel's Robustness Principle:
+
+      Be conservative in what you do, be liberal in what you accept from
+      others [RFC-793].
+
+1.1 Requirement Language
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [RFC-2119].
+
+1.2 Scope of this Document
+
+   IPv6 covers many specifications.  It is intended that IPv6 will be
+   deployed in many different situations and environments.  Therefore,
+   it is important to develop the requirements for IPv6 nodes, in order
+   to ensure interoperability.
+
+   This document assumes that all IPv6 nodes meet the minimum
+   requirements specified here.
+
+1.3 Description of IPv6 Nodes
+
+   From Internet Protocol, Version 6 (IPv6) Specification [RFC-2460] we
+   have the following definitions:
+
+      Description of an IPv6 Node
+
+
+
+
+Loughney (editor)          February 16, 2004                    [Page 3]
+
+
+
+
+
+Internet-Draft
+
+
+       - a device that implements IPv6
+
+      Description of an IPv6 router
+
+       - a node that forwards IPv6 packets not explicitly addressed to
+         itself.
+
+      Description of an IPv6 Host
+
+       - any node that is not a router.
+
+2. Abbreviations Used in This Document
+
+   ATM   Asynchronous Transfer Mode
+
+   AH    Authentication Header
+
+   DAD   Duplicate Address Detection
+
+   ESP   Encapsulating Security Payload
+
+   ICMP  Internet Control Message Protocol
+
+   IKE   Internet Key Exchange
+
+   MIB   Management Information Base
+
+   MLD   Multicast Listener Discovery
+
+   MTU   Maximum Transfer Unit
+
+   NA    Neighbor Advertisement
+
+   NBMA  Non-Broadcast Multiple Access
+
+   ND    Neighbor Discovery
+
+   NS    Neighbor Solicitation
+
+   NUD   Neighbor Unreachability Detection
+
+   PPP   Point-to-Point Protocol
+
+   PVC   Permanent Virtual Circuit
+
+   SVC   Switched Virtual Circuit
+
+3. Sub-IP Layer
+
+
+
+Loughney (editor)          February 16, 2004                    [Page 4]
+
+
+
+
+
+Internet-Draft
+
+
+   An IPv6 node must include support for one or more IPv6 link-layer
+   specifications.  Which link-layer specifications are included will
+   depend upon what link-layers are supported by the hardware available
+   on the system.  It is possible for a conformant IPv6 node to support
+   IPv6 on some of its interfaces and not on others.
+
+   As IPv6 is run over new layer 2 technologies, it is expected that new
+   specifications will be issued.  This section highlights some major
+   layer 2 technologies and is not intended to be complete.
+
+3.1 Transmission of IPv6 Packets over Ethernet Networks - RFC2464
+
+   Nodes supporting IPv6 over Ethernet interfaces MUST implement
+   Transmission of IPv6 Packets over Ethernet Networks [RFC-2464].
+
+3.2 IP version 6 over PPP - RFC2472
+
+   Nodes supporting IPv6 over PPP MUST implement IPv6 over PPP [RFC-
+   2472].
+
+3.3 IPv6 over ATM Networks - RFC2492
+
+   Nodes supporting IPv6 over ATM Networks MUST implement IPv6 over ATM
+   Networks [RFC-2492].  Additionally, RFC 2492 states:
+
+      A minimally conforming IPv6/ATM driver SHALL support the PVC mode
+      of operation. An IPv6/ATM driver that supports the full SVC mode
+      SHALL also support PVC mode of operation.
+
+4. IP Layer
+
+4.1 Internet Protocol Version 6 - RFC2460
+
+   The Internet Protocol Version 6 is specified in [RFC-2460]. This
+   specification MUST be supported.
+
+   Unrecognized options in Hop-by-Hop Options or Destination Options
+   extensions MUST be processed as described in RFC 2460.
+
+   The node MUST follow the packet transmission rules in RFC 2460.
+
+   Nodes MUST always be able to send, receive and process fragment
+   headers.  All conformant IPv6 implementations MUST be capable of
+   sending and receving IPv6 packets; forwarding functionality MAY be
+   supported
+
+   RFC 2460 specifies extension headers and the processing for these
+   headers.
+
+
+
+Loughney (editor)          February 16, 2004                    [Page 5]
+
+
+
+
+
+Internet-Draft
+
+
+      A full implementation of IPv6 includes implementation of the
+      following extension headers: Hop-by-Hop Options, Routing (Type 0),
+      Fragment, Destination Options, Authentication and Encapsulating
+      Security Payload. [RFC-2460]
+
+   An IPv6 node MUST be able to process these headers.  It should be
+   noted that there is some discussion about the use of Routing Headers
+   and possible security threats [IPv6-RH] caused by them.
+
+4.2 Neighbor Discovery for IPv6 - RFC2461
+
+   Neighbor Discovery SHOULD be supported.  RFC 2461 states:
+
+      "Unless specified otherwise (in a document that covers operating
+      IP over a particular link type) this document applies to all link
+      types. However, because ND uses link-layer multicast for some of
+      its services, it is possible that on some link types (e.g., NBMA
+      links) alternative protocols or mechanisms to implement those
+      services will be specified (in the appropriate document covering
+      the operation of IP over a particular link type).  The services
+      described in this document that are not directly dependent on
+      multicast, such as Redirects, Next-hop determination, Neighbor
+      Unreachability Detection, etc., are expected to be provided as
+      specified in this document.  The details of how one uses ND on
+      NBMA links is an area for further study."
+
+   Some detailed analysis of Neighbor Discovery follows:
+
+   Router Discovery is how hosts locate routers that reside on an
+   attached link. Router Discovery MUST be supported for
+   implementations.
+
+   Prefix Discovery is how hosts discover the set of address prefixes
+   that define which destinations are on-link for an attached link.
+   Prefix discovery MUST be supported for implementations. Neighbor
+   Unreachability Detection (NUD) MUST be supported for all paths
+   between hosts and neighboring nodes. It is not required for paths
+   between routers.  However, when a node receives a unicast Neighbor
+   Solicitation (NS) message (that may be a NUD's NS), the node MUST
+   respond to it (i.e. send a unicast Neighbor Advertisement).
+
+   Duplicate Address Detection MUST be supported on all links supporting
+   link-layer multicast (RFC2462 section 5.4 specifies DAD MUST take
+   place on all unicast addresses).
+
+   A host implementation MUST support sending Router Solicitations.
+
+   Receiving and processing Router Advertisements MUST be supported for
+
+
+
+Loughney (editor)          February 16, 2004                    [Page 6]
+
+
+
+
+
+Internet-Draft
+
+
+   host implementations. The ability to understand specific Router
+   Advertisement options is dependent on supporting the specification
+   where the RA is specified.
+
+   Sending and Receiving Neighbor Solicitation (NS) and Neighbor
+   Advertisement (NA) MUST be supported. NS and NA messages are required
+   for Duplicate Address Detection (DAD).
+
+   Redirect functionality SHOULD be supported. If the node is a router,
+   Redirect functionality MUST be supported.
+
+4.3 Path MTU Discovery & Packet Size
+
+4.3.1 Path MTU Discovery - RFC1981
+
+   Path MTU Discovery [RFC-1981] SHOULD be supported, though minimal
+   implementations MAY choose to not support it and avoid large packets.
+   The rules in RFC 2460 MUST be followed for packet fragmentation and
+   reassembly.
+
+4.3.2 IPv6 Jumbograms - RFC2675
+
+   IPv6 Jumbograms [RFC-2675] MAY be supported.
+
+4.4  ICMP for the Internet Protocol Version 6 (IPv6) - RFC2463
+
+   ICMPv6 [RFC-2463] MUST be supported.
+
+4.5 Addressing
+
+4.5.1 IP Version 6 Addressing Architecture - RFC3513
+
+   The IPv6 Addressing Architecture [RFC-3513] MUST be supported.
+
+4.5.2 IPv6 Stateless Address Autoconfiguration - RFC2462
+
+   IPv6 Stateless Address Autoconfiguration is defined in [RFC-2462].
+   This specification MUST be supported for nodes that are hosts.
+
+   Nodes that are routers MUST be able to generate link local addresses
+   as described in RFC 2462 [RFC-2462].
+
+   From 2462:
+
+      The autoconfiguration process specified in this document applies
+      only to hosts and not routers. Since host autoconfiguration uses
+      information advertised by routers, routers will need to be
+      configured by some other means. However, it is expected that
+
+
+
+Loughney (editor)          February 16, 2004                    [Page 7]
+
+
+
+
+
+Internet-Draft
+
+
+      routers will generate link-local addresses using the mechanism
+      described in this document. In addition, routers are expected to
+      successfully pass the Duplicate Address Detection procedure
+      described in this document on all addresses prior to assigning
+      them to an interface.
+
+   Duplicate Address Detection (DAD) MUST be supported.
+
+4.5.3 Privacy Extensions for Address Configuration in IPv6 - RFC3041
+
+   Privacy Extensions for Stateless Address Autoconfiguration [RFC-3041]
+   SHOULD be supported.  It is recommended that this behavior be
+   configurable on a connection basis within each application when
+   available.  It is noted that a number of applications do not work
+   with addresses generated with this method, while other applications
+   work quite well with them.
+
+4.5.4 Default Address Selection for IPv6 - RFC3484
+
+   The rules specified in the Default Address Selection for IPv6 [RFC-
+   3484] document MUST be implemented. It is expected that IPv6 nodes
+   will need to deal with multiple addresses.
+
+4.5.5 Stateful Address Autoconfiguration
+
+   Stateful Address Autoconfiguration MAY be supported. DHCPv6 [RFC-
+   3315] is the standard stateful address configuration protocol; see
+   section 5.3 for DHCPv6 support.
+
+   Nodes which do not support Stateful Address Autoconfiguration may be
+   unable to obtain any IPv6 addresses aside from link-local addresses
+   when it receives a router advertisement with the 'M' flag (Managed
+   address configuration) set and which contains no prefixes advertised
+   for Stateless Address Autoconfiguration (see section 4.5.2).
+   Additionally, such nodes will be unable to obtain other configuration
+   information such as the addresses of DNS servers when it is connected
+   to a link over which the node receives a router advertisement in
+   which the 'O' flag ("Other stateful configuration") is set.
+
+4.6 Multicast Listener Discovery (MLD) for IPv6 - RFC2710
+
+   Nodes that need to join multicast groups SHOULD implement MLDv2
+   [MLDv2]. However, if the node has applications, which only need
+   support for Any- Source Multicast [RFC3569], the node MAY implement
+   MLDv1 [MLDv1] instead. If the node has applications, which need
+   support for Source- Specific Multicast [RFC3569, SSMARCH], the node
+   MUST support MLDv2 [MLDv2].
+
+
+
+
+Loughney (editor)          February 16, 2004                    [Page 8]
+
+
+
+
+
+Internet-Draft
+
+
+   When MLD is used, the rules in "Source Address Selection for the
+   Multicast Listener Discovery (MLD) Protocol" [RFC-3590] MUST be
+   followed.
+
+5. Transport Layer and DNS
+
+5.1 Transport Layer
+
+5.1.1 TCP and UDP over IPv6 Jumbograms - RFC2147
+
+   This specification MUST be supported if jumbograms are implemented
+   [RFC- 2675].
+
+5.2 DNS
+
+   DNS, as described in [RFC-1034], [RFC-1035], [RFC-3152], [RFC-3363]
+   and [RFC-3596] MAY be supported.  Not all nodes will need to resolve
+   names. All nodes that need to resolve names SHOULD implement stub-
+   resolver [RFC-1034] functionality, in RFC 1034 section 5.3.1 with
+   support for:
+
+    - AAAA type Resource Records [RFC-3596];
+    - reverse addressing in ip6.arpa using PTR records [RFC-3152];
+    - EDNS0 [RFC-2671] to allow for DNS packet sizes larger than 512
+      octets.
+
+   Those nodes are RECOMMENDED to support DNS security extentions
+   [DNSSEC- INTRO], [DNSSEC-REC] and [DNSSEC-PROT].
+
+   Those nodes are NOT RECOMMENDED to support the experimental A6 and
+   DNAME Resource Records [RFC-3363].
+
+5.2.2 Format for Literal IPv6 Addresses in URL's - RFC2732
+
+   RFC 2732 MUST be supported if applications on the node use URL's.
+
+5.3 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) - RFC3315
+
+5.3.1 Managed Address Configuration
+
+   Those IPv6 Nodes that use DHCP for address assignment initiate DHCP
+   to obtain IPv6 addresses and other configuration information upon
+   receipt of a Router Advertisement with the 'M' flag set, as described
+   in section 5.5.3 of RFC 2462.  In addition, in the absence of a
+   router, those IPv6 Nodes that use DHCP for address assignment MUST
+   initiate DHCP to obtain IPv6 addresses and other configuration
+   information, as described in section 5.5.2 of RFC 2462.  Those IPv6
+   nodes that do not use DHCP for address assignment can ignore the 'M'
+
+
+
+Loughney (editor)          February 16, 2004                    [Page 9]
+
+
+
+
+
+Internet-Draft
+
+
+   flag in Router Advertisements.
+
+5.3.2 Other Configuration Information
+
+   Those IPv6 Nodes that use DHCP to obtain other configuration
+   information initiate DHCP for other configuration information upon
+   receipt of a Router Advertisement with the 'O' flag set, as described
+   in section 5.5.3 of RFC 2462.  Those IPv6 nodes that do not use DHCP
+   for other configuration information can ignore the 'O' flag in Router
+   Advertisements.
+
+   An IPv6 Node can use the subset of DHCP described in [DHCPv6-SL] to
+   obtain other configuration information.
+
+6. IPv4 Support and Transition
+
+   IPv6 nodes MAY support IPv4.
+
+6.1 Transition Mechanisms
+
+6.1.1 Transition Mechanisms for IPv6 Hosts and Routers - RFC2893
+
+   If an IPv6 node implements dual stack and tunneling, then RFC2893
+   MUST be supported.
+
+   RFC 2893 is currently being updated.
+
+7. Mobile IP
+
+   The Mobile IPv6 [MIPv6] specification defines requirements for the
+   following types of nodes:
+
+       - mobile nodes
+       - correspondent nodes with support for route optimization
+       - home agents
+       - all IPv6 routers
+
+   Hosts MAY support mobile node functionality described in Section 8.5
+   of [MIPv6], including support of generic packet tunneling [RFC-2473]
+   and secure home agent communications [MIPv6-HASEC].
+
+   Hosts SHOULD support route optimization requirements for
+   correspondent nodes described in Section 8.2 of [MIPv6].
+
+   Routers SHOULD support the generic mobility-related requirements for
+   all IPv6 routers described in Section 8.3 of [MIPv6]. Routers MAY
+   support the home agent functionality described in Section 8.4 of
+   [MIPv6], including support of [RFC-2473] and [MIPv6-HASEC].
+
+
+
+Loughney (editor)          February 16, 2004                   [Page 10]
+
+
+
+
+
+Internet-Draft
+
+
+8. Security
+
+   This section describes the specification of IPsec for the IPv6 node.
+
+8.1 Basic Architecture
+
+   Security Architecture for the Internet Protocol [RFC-2401] MUST be
+   supported. RFC-2401 is being updated by the IPsec Working Group.
+
+8.2 Security Protocols
+
+   ESP [RFC-2406] MUST be supported. AH [RFC-2402] MUST be supported.
+   RFC- 2406 and RFC 2402 are being updated by the IPsec Working Group.
+
+
+8.3 Transforms and Algorithms
+
+   Current IPsec RFCs specify the support of certain transforms and
+   algorithms, NULL encryption, DES-CBC, HMAC-SHA-1-96, and HMAC-MD5-96.
+   The requirements for these are discussed first, and then additional
+   algorithms 3DES-CBC, AES-128-CBC and HMAC-SHA-256-96 are discussed.
+
+   NULL encryption algorithm [RFC-2410] MUST be supported for providing
+   integrity service and also for debugging use.
+
+   The "ESP DES-CBC Cipher Algorithm With Explicit IV" [RFC-2405] SHOULD
+   NOT be supported. Security issues related to the use of DES are
+   discussed in [DESDIFF], [DESINT], [DESCRACK]. It is still listed as
+   required by the existing IPsec RFCs, but as it is currently viewed as
+   an inherently weak algorithm, and no longer fulfills its intended
+   role.
+
+   The NULL authentication algorithm [RFC-2406] MUST be supported within
+   ESP. The use of HMAC-SHA-1-96 within AH and ESP, described in [RFC-
+   2404] MUST be supported. The use of HMAC-MD5-96 within AH and ESP,
+   described in [RFC-2403] MUST be supported. An implementer MUST refer
+   to Keyed- Hashing for Message Authentication [RFC-2104].
+
+   3DES-CBC does not suffer from the issues related to DES-CBC. 3DES-CBC
+   and ESP CBC-Mode Cipher Algorithms [RFC-2451] MAY be supported. AES-
+   CBC Cipher Algorithm [RFC-3602] MUST be supported, as it is expected
+   to be a widely available, secure algorithm that is required for
+   interoperability. It is not required by the current IPsec RFCs, but
+   is expected to become required in the future.
+
+   In addition to the above requirements, "Cryptographic Algorithm
+   Implementation Requirements For ESP And AH" [CRYPTREQ] contains the
+   current set of mandatory to implement algorithms for ESP and AH as
+
+
+
+Loughney (editor)          February 16, 2004                   [Page 11]
+
+
+
+
+
+Internet-Draft
+
+
+   well as specifying algorithms that should be implemented because they
+   may be promoted to mandatory at some future time.  It is RECOMMENDED
+   that IPv6 nodes conform to the requirements in this document.
+
+8.4 Key Management Methods
+
+   Manual keying MUST be supported.
+
+   IKE [RFC-2407] [RFC-2408] [RFC-2409] MAY be supported for unicast
+   traffic. Where key refresh, anti-replay features of AH and ESP, or
+   on- demand creation of Security Associations (SAs) is required,
+   automated keying MUST be supported. Note that the IPsec WG is working
+   on the successor to IKE [IKE2]. Key management methods for multicast
+   traffic are also being worked on by the MSEC WG.
+
+   "Cryptographic Algorithms for use in the Internet Key Exchange
+   Version 2" [IKEv2ALGO] defines the current set of mandatory to
+   implement algorithms for use of IKEv2 as well as specifying
+   algorithms that should be implemented because they made be promoted
+   to mandatory at some future time. It is RECOMMENDED that IPv6 nodes
+   implementing IKEv2 conform to the requirements in this
+   document.
+
+9. Router-Specific Functionality
+
+   This section defines general host considerations for IPv6 nodes that
+   act as routers.  Currently, this section does not discuss routing-
+   specific requirements.
+
+9.1 General
+
+9.1.1 IPv6 Router Alert Option - RFC2711
+
+
+   The IPv6 Router Alert Option [RFC-2711] is an optional IPv6 Hop-by-
+   Hop Header that is used in conjunction with some protocols (e.g.,
+   RSVP [RFC- 2205], or MLD [RFC-2710]). The Router Alert option will
+   need to be implemented whenever protocols that mandate its usage are
+   implemented. See Section 4.6.
+
+9.1.2 Neighbor Discovery for IPv6 - RFC2461
+
+   Sending Router Advertisements and processing Router Solicitation MUST
+   be supported.
+
+10. Network Management
+
+   Network Management MAY be supported by IPv6 nodes.  However, for IPv6
+
+
+
+Loughney (editor)          February 16, 2004                   [Page 12]
+
+
+
+
+
+Internet-Draft
+
+
+   nodes that are embedded devices, network management may be the only
+   possibility to control these nodes.
+
+10.1 Management Information Base Modules (MIBs)
+
+   The following two MIBs SHOULD be supported by nodes that support an
+   SNMP agent.
+
+10.1.1  IP Forwarding Table MIB
+
+   IP Forwarding Table MIB [RFC-2096BIS] SHOULD be supported by nodes
+   that support an SNMP agent.
+
+10.1.2 Management Information Base for the Internet Protocol (IP)
+
+   IP MIB [RFC-2011BIS] SHOULD be supported by nodes that support an
+   SNMP agent.
+
+11. Security Considerations
+
+   This draft does not affect the security of the Internet, but
+   implementations of IPv6 are expected to support a minimum set of
+   security features to ensure security on the Internet.  "IP Security
+   Document Roadmap" [RFC-2411] is important for everyone to read.
+
+   The security considerations in RFC2460 describe the following:
+
+      The security features of IPv6 are described in the Security
+      Architecture for the Internet Protocol [RFC-2401].
+
+12. References
+
+12.1 Normative
+
+   [CRYPTREQ]     D. Eastlake 3rd, "Cryptographic Algorithm Implementa-
+                  tion Requirements For ESP And AH", draft-ietf-ipsec-
+                  esp-ah-algorithms-01.txt, January 2004.
+
+   [IKEv2ALGO]    J. Schiller, "Cryptographic Algorithms for use in the
+                  Internet Key Exchange Version 2", draft-ietf-ipsec-
+                  ikev2-algorithms-04.txt, Work in Progress.
+
+   [DHCPv6-SL]    R. Droms, "A Guide to Implementing Stateless DHCPv6
+                  Service", draft- ietf-dhc-dhcpv6-stateless-00.txt,
+                  Work in Progress.
+
+   [MIPv6]        J. Arkko, D. Johnson and C. Perkins, "Mobility Support
+                  in IPv6", draft- ietf-mobileip-ipv6-24.txt, Work in
+
+
+
+Loughney (editor)          February 16, 2004                   [Page 13]
+
+
+
+
+
+Internet-Draft
+
+
+                  progress.
+
+   [MIPv6-HASEC]  J. Arkko, V. Devarapalli and F. Dupont, "Using IPsec
+                  to Protect Mobile IPv6 Signaling between Mobile Nodes
+                  and Home Agents", draft-ietf- mobileip-mipv6-ha-
+                  ipsec-06.txt, Work in Progress.
+
+   [MLDv2]        Vida, R. et al., "Multicast Listener Discovery Version
+                  2 (MLDv2) for IPv6", draft-vida-mld-v2-07.txt, Work in
+                  Progress.
+
+   [RFC-1035]     Mockapetris, P., "Domain names - implementation and
+                  specification", STD 13, RFC 1035, November 1987.
+
+   [RFC-1981]     McCann, J., Mogul, J. and Deering, S., "Path MTU
+                  Discovery for IP version 6", RFC 1981, August 1996.
+
+   [RFC-2096BIS]  Haberman, B. and Wasserman, M., "IP Forwarding Table
+                  MIB", draft-ietf- ipv6-rfc2096-update-07.txt, Work in
+                  Progress.
+
+   [RFC-2011BIS]  Routhier, S (ed), "Management Information Base for the
+                  Internet Protocol (IP)", draft-ietf-ipv6-rfc2011-
+                  update-07.txt, Work in progress.
+
+   [RFC-2104]     Krawczyk, K., Bellare, M., and Canetti, R., "HMAC:
+                  Keyed-Hashing for Message Authentication", RFC 2104,
+                  February 1997.
+
+   [RFC-2119]     Bradner, S., "Key words for use in RFCs to Indicate
+                  Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC-2401]     Kent, S. and Atkinson, R., "Security Architecture for
+                  the Internet Protocol", RFC 2401, November 1998.
+
+   [RFC-2402]     Kent, S. and Atkinson, R.,  "IP Authentication
+                  Header", RFC 2402, November 1998.
+
+   [RFC-2403]     Madson, C., and Glenn, R., "The Use of HMAC-MD5 within
+                  ESP and AH", RFC 2403, November 1998.
+
+   [RFC-2404]     Madson, C., and Glenn, R., "The Use of HMAC-SHA-1
+                  within ESP and AH", RFC 2404, November 1998.
+
+   [RFC-2405]     Madson, C. and Doraswamy, N., "The ESP DES-CBC Cipher
+                  Algorithm With Explicit IV", RFC 2405, November 1998.
+
+   [RFC-2406]     Kent, S. and Atkinson, R., "IP Encapsulating Security
+
+
+
+Loughney (editor)          February 16, 2004                   [Page 14]
+
+
+
+
+
+Internet-Draft
+
+
+                  Protocol (ESP)", RFC 2406, November 1998.
+
+   [RFC-2407]     Piper, D., "The Internet IP Security Domain of
+                  Interpretation for ISAKMP", RFC 2407, November 1998.
+
+   [RFC-2408]     Maughan, D., Schertler, M., Schneider, M., and Turner,
+                  J., "Internet Security Association and Key Management
+                  Protocol (ISAKMP)", RFC 2408, November 1998.
+
+   [RFC-2409]     Harkins, D., and Carrel, D., "The Internet Key
+                  Exchange (IKE)", RFC 2409, November 1998.
+
+   [RFC-2410]     Glenn, R. and Kent, S., "The NULL Encryption Algorithm
+                  and Its Use With IPsec", RFC 2410, November 1998.
+
+   [RFC-2451]     Pereira, R. and Adams, R., "The ESP CBC-Mode Cipher
+                  Algorithms", RFC 2451, November 1998.
+
+   [RFC-2460]     Deering, S. and Hinden, R., "Internet Protocol, Ver-
+                  sion 6 (IPv6) Specification", RFC 2460, December 1998.
+
+   [RFC-2461]     Narten, T., Nordmark, E. and Simpson, W., "Neighbor
+                  Discovery for IP Version 6 (IPv6)", RFC 2461, December
+                  1998.
+
+   [RFC-2462]     Thomson, S. and Narten, T., "IPv6 Stateless Address
+                  Autoconfiguration", RFC 2462.
+
+   [RFC-2463]     Conta, A. and Deering, S., "ICMP for the Internet Pro-
+                  tocol Version 6 (IPv6)", RFC 2463, December 1998.
+
+   [RFC-2472]     Haskin, D. and Allen, E., "IP version 6 over PPP", RFC
+                  2472, December 1998.
+
+   [RFC-2473]     Conta, A. and Deering, S., "Generic Packet Tunneling
+                  in IPv6 Specification", RFC 2473, December 1998.  Xxx
+                  add
+
+   [RFC-2671]     Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
+                  2671, August 1999.
+
+   [RFC-2710]     Deering, S., Fenner, W. and Haberman, B., "Multicast
+                  Listener Discovery (MLD) for IPv6", RFC 2710, October
+                  1999.
+
+   [RFC-2711]     Partridge, C. and Jackson, A., "IPv6 Router Alert
+                  Option", RFC 2711, October 1999.
+
+
+
+
+Loughney (editor)          February 16, 2004                   [Page 15]
+
+
+
+
+
+Internet-Draft
+
+
+   [RFC-3041]     Narten, T. and Draves, R., "Privacy Extensions for
+                  Stateless Address Autoconfiguration in IPv6", RFC
+                  3041, January 2001.
+
+   [RFC-3152]     Bush, R., "Delegation of IP6.ARPA", RFC 3152, August
+                  2001.
+
+   [RFC-3315]     Bound, J. et al., "Dynamic Host Configuration Protocol
+                  for IPv6 (DHCPv6)", RFC 3315, July 2003.
+
+   [RFC-3363]     Bush, R., et al., "Representing Internet Protocol ver-
+                  sion 6 (IPv6) Addresses in the Domain Name System
+                  (DNS)", RFC 3363, August 2002.
+
+   [RFC-3484]     Draves, R., "Default Address Selection for IPv6", RFC
+                  3484, February 2003.
+
+   [RFC-3513]     Hinden, R. and Deering, S. "IP Version 6 Addressing
+                  Architecture", RFC 3513, April 2003.
+
+   [RFC-3590]     Haberman, B., "Source Address Selection for the Multi-
+                  cast Listener Discovery (MLD) Protocol", RFC 3590,
+                  September 2003.
+
+   [RFC-3596]     Thomson, S., et al., "DNS Extensions to support IP
+                  version 6", RFC 3596, October 2003.
+
+   [RFC-3602]     S. Frankel, "The AES-CBC Cipher Algorithm and Its Use
+                  with IPsec", RFC 3602, September 2003.
+
+12.2 Non-Normative
+
+   [ANYCAST]      Hagino, J and Ettikan K., "An Analysis of IPv6 Anycast",
+                  draft-ietf- ipngwg-ipv6-anycast-analysis-02.txt, Work in
+                  Progress.
+
+   [DESDIFF]      Biham, E., Shamir, A., "Differential Cryptanalysis of
+                  DES-like cryptosystems", Journal of Cryptology Vol 4, Jan
+                  1991.
+
+   [DESCRACK]     Cracking DES, O'Reilly & Associates, Sebastapol, CA 2000.
+   
+   [DESINT]       Bellovin, S., "An Issue With DES-CBC When Used Without
+                  Strong Integrity", Proceedings of the 32nd IETF, Danvers,
+                  MA, April 1995.
+
+   [DHCPv6-SL]    Droms, R., "A Guide to Implementing Stateless DHCPv6 Ser-
+                  vice", draft- ietf-dhc-dhcpv6-stateless-02.txt, Work in
+
+
+
+Loughney (editor)          February 16, 2004                   [Page 16]
+
+
+
+
+
+Internet-Draft
+
+
+                  Progress.
+
+   [DNSSEC-INTRO] Arends, R., Austein, R., Larson, M., Massey, D. and Rose,
+                  S., "DNS Security Introduction and Requirements" draft-
+                  ietf-dnsext-dnssec-intro- 06.txt, Work in Progress.
+
+   [DNSSEC-REC]   Arends, R., Austein, R., Larson, M., Massey, D. and Rose,
+                  S., "Resource Records for the DNS Security Extensions",
+                  draft-ietf-dnsext-dnssec- records-04.txt, Work in Pro-
+                  gress.
+
+   [DNSSEC-PROT]  Arends, R., Austein, R., Larson, M., Massey, D. and Rose,
+                  S., "Protocol Modifications for the DNS Security Exten-
+                  sions", draft-ietf-dnsext- dnssec-protocol-02.txt, Work
+                  in Progress.
+
+   [IKE2]         Kaufman, C. (ed), "Internet Key Exchange (IKEv2) Proto-
+                  col", draft-ietf- ipsec-ikev2-10.txt, Work in Progress.
+  
+   [IPv6-RH]      P. Savola, "Security of IPv6 Routing Header and Home
+                  Address Options", draft-savola-ipv6-rh-ha-security-
+                  03.txt, Work in Progress, March 2002.
+
+   [MC-THREAT]    Ballardie A. and Crowcroft, J.; Multicast-Specific Secu-
+                  rity Threats and Counter-Measures; In Proceedings "Sympo-
+                  sium on Network and Distributed System Security", Febru-
+                  ary 1995, pp.2-16.
+
+   [RFC-793]      Postel, J., "Transmission Control Protocol", RFC 793,
+                  August 1980.
+
+   [RFC-1034]     Mockapetris, P., "Domain names - concepts and facili-
+                  ties", RFC 1034, November 1987.
+
+   [RFC-2147]     Borman, D., "TCP and UDP over IPv6 Jumbograms", RFC 2147,
+                  May 1997.
+
+   [RFC-2205]     Braden, B. (ed.), Zhang, L., Berson, S., Herzog, S. and
+                  S. Jamin, "Resource ReSerVation Protocol (RSVP)", RFC
+                  2205, September 1997.
+
+   [RFC-2464]     Crawford, M., "Transmission of IPv6 Packets over Ethernet
+                  Networks", RFC 2462, December 1998.
+
+   [RFC-2492]     G. Armitage, M. Jork, P. Schulter, G. Harter, IPv6 over
+                  ATM Networks", RFC 2492, January 1999.
+
+   [RFC-2675]     Borman, D., Deering, S. and Hinden, B., "IPv6
+
+
+
+Loughney (editor)          February 16, 2004                   [Page 17]
+
+
+
+
+
+Internet-Draft
+
+
+                  Jumbograms", RFC 2675, August 1999.
+
+   [RFC-2732]     R. Hinden, B. Carpenter, L. Masinter, "Format for Literal
+                  IPv6 Addresses in URL's", RFC 2732, December 1999.
+
+   [RFC-2851]     M. Daniele, B. Haberman, S. Routhier, J. Schoenwaelder,
+                  "Textual Conventions for Internet Network Addresses", RFC
+                  2851, June 2000.
+
+   [RFC-2893]     Gilligan, R. and Nordmark, E., "Transition Mechanisms for
+                  IPv6 Hosts and Routers", RFC 2893, August 2000.
+
+   [RFC-3569]     S. Bhattacharyya, Ed., "An Overview of Source-Specific
+                  Multicast (SSM)", RFC 3569, July 2003.
+
+   [SSM-ARCH]     H. Holbrook, B. Cain, "Source-Specific Multicast for IP",
+                  draft-ietf- ssm-arch-03.txt, Work in Progress.
+
+13. Authors and Acknowledgements
+
+   This document was written by the IPv6 Node Requirements design team:
+
+      Jari Arkko
+      [jari.arkko@ericsson.com]
+
+      Marc Blanchet
+      [marc.blanchet@viagenie.qc.ca]
+
+      Samita Chakrabarti
+      [samita.chakrabarti@eng.sun.com]
+
+      Alain Durand
+      [alain.durand@sun.com]
+
+      Gerard Gastaud
+      [gerard.gastaud@alcatel.fr]
+
+      Jun-ichiro itojun Hagino
+      [itojun@iijlab.net]
+
+      Atsushi Inoue
+      [inoue@isl.rdc.toshiba.co.jp]
+
+      Masahiro Ishiyama
+      [masahiro@isl.rdc.toshiba.co.jp]
+
+      John Loughney
+      [john.loughney@nokia.com]
+
+
+
+Loughney (editor)          February 16, 2004                   [Page 18]
+
+
+
+
+
+Internet-Draft
+
+
+      Rajiv Raghunarayan
+      [raraghun@cisco.com]
+
+      Shoichi Sakane
+      [shouichi.sakane@jp.yokogawa.com]
+
+      Dave Thaler
+      [dthaler@windows.microsoft.com]
+
+      Juha Wiljakka
+      [juha.wiljakka@Nokia.com]
+
+   The authors would like to thank Ran Atkinson, Jim Bound, Brian Car-
+   penter, Ralph Droms, Christian Huitema, Adam Machalek, Thomas Narten,
+   Juha Ollila and Pekka Savola for their comments.
+
+14. Editor's Contact Information
+
+   Comments or questions regarding this document should be sent to the
+   IPv6 Working Group mailing list (ipv6@ietf.org) or to:
+
+      John Loughney
+      Nokia Research Center
+      Itamerenkatu 11-13
+      00180 Helsinki
+      Finland
+
+      Phone: +358 50 483 6242
+      Email: John.Loughney@Nokia.com
+
+Notices
+
+   The IETF takes no position regarding the validity or scope of any
+   intellectual property or other rights that might be claimed to per-
+   tain to the implementation or use of the technology described in this
+   document or the extent to which any license under such rights might
+   or might not be available; neither does it represent that it has made
+   any effort to identify any such rights.  Information on the IETF's
+   procedures with respect to rights in standards-track and standards-
+   related documentation can be found in BCP-11.  Copies of claims of
+   rights made available for publication and any assurances of licenses
+   to be made available, or the result of an attempt made to obtain a
+   general license or permission for the use of such proprietary rights
+   by implementors or users of this specification can be obtained from
+   the IETF Secretariat.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+
+
+
+Loughney (editor)          February 16, 2004                   [Page 19]
+
+
+
+
+
+Internet-Draft
+
+
+   rights, which may cover technology that may be required to practice
+   this standard.  Please address the information to the IETF Executive
+   Director.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Loughney (editor)          February 16, 2004                   [Page 20]
+
+
diff --git a/doc/draft/draft-ietf-secsh-dns-05.txt b/doc/draft/draft-ietf-secsh-dns-05.txt
new file mode 100644
index 0000000..a272d81
--- /dev/null
+++ b/doc/draft/draft-ietf-secsh-dns-05.txt
@@ -0,0 +1,614 @@
+Secure Shell Working Group                                   J. Schlyter
+Internet-Draft                                                   OpenSSH
+Expires: March 5, 2004                                        W. Griffin
+                                                                  SPARTA
+                                                       September 5, 2003
+
+
+           Using DNS to Securely Publish SSH Key Fingerprints
+                      draft-ietf-secsh-dns-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 draft documents 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 "work in progress."
+
+   The list of current Internet-Drafts can be accessed at http://
+   www.ietf.org/ietf/1id-abstracts.txt.
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+   This Internet-Draft will expire on March 5, 2004.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2003). All Rights Reserved.
+
+Abstract
+
+   This document describes a method to verify SSH host keys using
+   DNSSEC. The document defines a new DNS resource record that contains
+   a standard SSH key fingerprint.
+
+
+
+
+
+
+
+
+
+
+
+Schlyter & Griffin       Expires March 5, 2004                  [Page 1]
+
+Internet-Draft          DNS and SSH Fingerprints          September 2003
+
+
+Table of Contents
+
+   1.    Introduction . . . . . . . . . . . . . . . . . . . . . . . .  3
+   2.    SSH Host Key Verification  . . . . . . . . . . . . . . . . .  3
+   2.1   Method . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   2.2   Implementation Notes . . . . . . . . . . . . . . . . . . . .  3
+   2.3   Fingerprint Matching . . . . . . . . . . . . . . . . . . . .  4
+   2.4   Authentication . . . . . . . . . . . . . . . . . . . . . . .  4
+   3.    The SSHFP Resource Record  . . . . . . . . . . . . . . . . .  4
+   3.1   The SSHFP RDATA Format . . . . . . . . . . . . . . . . . . .  5
+   3.1.1 Algorithm Number Specification . . . . . . . . . . . . . . .  5
+   3.1.2 Fingerprint Type Specification . . . . . . . . . . . . . . .  5
+   3.1.3 Fingerprint  . . . . . . . . . . . . . . . . . . . . . . . .  5
+   3.2   Presentation Format of the SSHFP RR  . . . . . . . . . . . .  6
+   4.    Security Considerations  . . . . . . . . . . . . . . . . . .  6
+   5.    IANA Considerations  . . . . . . . . . . . . . . . . . . . .  7
+         Normative References . . . . . . . . . . . . . . . . . . . .  8
+         Informational References . . . . . . . . . . . . . . . . . .  8
+         Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  9
+   A.    Acknowledgements . . . . . . . . . . . . . . . . . . . . . .  9
+         Intellectual Property and Copyright Statements . . . . . . . 10
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Schlyter & Griffin       Expires March 5, 2004                  [Page 2]
+
+Internet-Draft          DNS and SSH Fingerprints          September 2003
+
+
+1. Introduction
+
+   The SSH [6] protocol provides secure remote login and other secure
+   network services over an insecure network.  The security of the
+   connection relies on the server authenticating itself to the client
+   as well as the user authenticating itself to the server.
+
+   If a connection is established to a server whose public key is not
+   already known to the client, a fingerprint of the key is presented to
+   the user for verification.  If the user decides that the fingerprint
+   is correct and accepts the key, the key is saved locally and used for
+   verification for all following connections. While some
+   security-conscious users verify the fingerprint out-of-band before
+   accepting the key, many users blindly accept the presented key.
+
+   The method described here can provide out-of-band verification by
+   looking up a fingerprint of the server public key in the DNS [1][2]
+   and using DNSSEC [5] to verify the lookup.
+
+   In order to distribute the fingerprint using DNS, this document
+   defines a new DNS resource record, "SSHFP", to carry the fingerprint.
+
+   Basic understanding of the DNS system [1][2] and the DNS security
+   extensions [5] is assumed by this document.
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [3].
+
+2. SSH Host Key Verification
+
+2.1 Method
+
+   Upon connection to a SSH server, the SSH client MAY look up the SSHFP
+   resource record(s) for the host it is connecting to.  If the
+   algorithm and fingerprint of the key received from the SSH server
+   match the algorithm and fingerprint of one of the SSHFP resource
+   record(s) returned from DNS, the client MAY accept the identity of
+   the server.
+
+2.2 Implementation Notes
+
+   Client implementors SHOULD provide a configurable policy used to
+   select the order of methods used to verify a host key. This document
+   defines one method: Fingerprint storage in DNS. Another method
+   defined in the SSH Architecture [6] uses local files to store keys
+   for comparison. Other methods that could be defined in the future
+   might include storing fingerprints in LDAP or other databases. A
+
+
+
+Schlyter & Griffin       Expires March 5, 2004                  [Page 3]
+
+Internet-Draft          DNS and SSH Fingerprints          September 2003
+
+
+   configurable policy will allow administrators to determine which
+   methods they want to use and in what order the methods should be
+   prioritized. This will allow administrators to determine how much
+   trust they want to place in the different methods.
+
+   One specific scenario for having a configurable policy is where
+   clients do not use fully qualified host names to connect to servers.
+   In this scenario, the implementation SHOULD verify the host key
+   against a local database before verifying the key via the fingerprint
+   returned from DNS. This would help prevent an attacker from injecting
+   a DNS search path into the local resolver and forcing the client to
+   connect to a different host.
+
+2.3 Fingerprint Matching
+
+   The public key and the SSHFP resource record are matched together by
+   comparing algorithm number and fingerprint.
+
+      The public key algorithm and the SSHFP algorithm number MUST
+      match.
+
+      A message digest of the public key, using the message digest
+      algorithm specified in the SSHFP fingerprint type, MUST match the
+      SSHFP fingerprint.
+
+
+2.4 Authentication
+
+   A public key verified using this method MUST NOT be trusted if the
+   SSHFP resource record (RR) used for verification was not
+   authenticated by a trusted SIG RR.
+
+   Clients that do validate the DNSSEC signatures themselves SHOULD use
+   standard DNSSEC validation procedures.
+
+   Clients that do not validate the DNSSEC signatures themselves MUST
+   use a secure transport, e.g. TSIG [9], SIG(0) [10] or IPsec [8],
+   between themselves and the entity performing the signature
+   validation.
+
+3. The SSHFP Resource Record
+
+   The SSHFP resource record (RR) is used to store a fingerprint of a
+   SSH public host key that is associated with a Domain Name System
+   (DNS) name.
+
+   The RR type code for the SSHFP RR is TBA.
+
+
+
+
+Schlyter & Griffin       Expires March 5, 2004                  [Page 4]
+
+Internet-Draft          DNS and SSH Fingerprints          September 2003
+
+
+3.1 The SSHFP RDATA Format
+
+   The RDATA for a SSHFP RR consists of an algorithm number, fingerprint
+   type and the fingerprint of the public host key.
+
+         1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
+         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+         |   algorithm   |    fp type    |                               /
+         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               /
+         /                                                               /
+         /                          fingerprint                          /
+         /                                                               /
+         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+3.1.1 Algorithm Number Specification
+
+   This algorithm number octet describes the algorithm of the public
+   key.  The following values are assigned:
+
+          Value    Algorithm name
+          -----    --------------
+          0        reserved
+          1        RSA
+          2        DSS
+
+   Reserving other types requires IETF consensus [4].
+
+3.1.2 Fingerprint Type Specification
+
+   The fingerprint type octet describes the message-digest algorithm
+   used to calculate the fingerprint of the public key.  The following
+   values are assigned:
+
+          Value    Fingerprint type
+          -----    ----------------
+          0        reserved
+          1        SHA-1
+
+   Reserving other types requires IETF consensus [4].
+
+   For interoperability reasons, as few fingerprint types as possible
+   should be reserved.  The only reason to reserve additional types is
+   to increase security.
+
+3.1.3 Fingerprint
+
+
+
+
+Schlyter & Griffin       Expires March 5, 2004                  [Page 5]
+
+Internet-Draft          DNS and SSH Fingerprints          September 2003
+
+
+   The fingerprint is calculated over the public key blob as described
+   in [7].
+
+   The message-digest algorithm is presumed to produce an opaque octet
+   string output which is placed as-is in the RDATA fingerprint field.
+
+3.2 Presentation Format of the SSHFP RR
+
+   The RDATA of the presentation format of the SSHFP resource record
+   consists of two numbers (algorithm and fingerprint type) followed by
+   the fingerprint itself presented in hex, e.g:
+
+         host.example.  SSHFP 2 1 123456789abcdef67890123456789abcdef67890
+
+   The use of mnemonics instead of numbers is not allowed.
+
+4. Security Considerations
+
+   Currently, the amount of trust a user can realistically place in a
+   server key is proportional to the amount of attention paid to
+   verifying that the public key presented actually corresponds to the
+   private key of the server. If a user accepts a key without verifying
+   the fingerprint with something learned through a secured channel, the
+   connection is vulnerable to a man-in-the-middle attack.
+
+   The overall security of using SSHFP for SSH host key verification is
+   dependent on the security policies of the SSH host administrator and
+   DNS zone administrator (in transferring the fingerprint), detailed
+   aspects of how verification is done in the SSH implementation, and in
+   the client's diligence in accessing the DNS in a secure manner.
+
+   One such aspect is in which order fingerprints are looked up (e.g.
+   first checking local file and then SSHFP).  We note that in addition
+   to protecting the first-time transfer of host keys, SSHFP can
+   optionally be used for stronger host key protection.
+
+      If SSHFP is checked first, new SSH host keys may be distributed by
+      replacing the corresponding SSHFP in DNS.
+
+      If SSH host key verification can be configured to require SSHFP,
+      SSH host key revocation can be implemented by removing the
+      corresponding SSHFP from DNS.
+
+   As stated in Section 2.2, we recommend that SSH implementors provide
+   a policy mechanism to control the order of methods used for host key
+   verification. One specific scenario for having a configurable policy
+   is where clients use unqualified host names to connect to servers. In
+   this case, we recommend that SSH implementations check the host key
+
+
+
+Schlyter & Griffin       Expires March 5, 2004                  [Page 6]
+
+Internet-Draft          DNS and SSH Fingerprints          September 2003
+
+
+   against a local database before verifying the key via the fingerprint
+   returned from DNS. This would help prevent an attacker from injecting
+   a DNS search path into the local resolver and forcing the client to
+   connect to a different host.
+
+   A different approach to solve the DNS search path issue would be for
+   clients to use a trusted DNS search path, i.e., one not acquired
+   through DHCP or other autoconfiguration mechanisms. Since there is no
+   way with current DNS lookup APIs to tell whether a search path is
+   from a trusted source, the entire client system would need to be
+   configured with this trusted DNS search path.
+
+   Another dependency is on the implementation of DNSSEC itself.  As
+   stated in Section 2.4, we mandate the use of secure methods for
+   lookup and that SSHFP RRs are authenticated by trusted SIG RRs.  This
+   is especially important if SSHFP is to be used as a basis for host
+   key rollover and/or revocation, as described above.
+
+   Since DNSSEC only protects the integrity of the host key fingerprint
+   after it is signed by the DNS zone administrator, the fingerprint
+   must be transferred securely from the SSH host administrator to the
+   DNS zone administrator.  This could be done manually between the
+   administrators or automatically using secure DNS dynamic update [11]
+   between the SSH server and the nameserver.  We note that this is no
+   different from other key enrollment situations, e.g. a client sending
+   a certificate request to a certificate authority for signing.
+
+5. IANA Considerations
+
+   IANA needs to allocate a RR type code for SSHFP from the standard RR
+   type space (type 44 requested).
+
+   IANA needs to open a new registry for the SSHFP RR type for public
+   key algorithms.  Defined types are:
+
+         0 is reserved
+         1 is RSA
+         2 is DSA
+
+    Adding new reservations requires IETF consensus [4].
+
+   IANA needs to open a new registry for the SSHFP RR type for
+   fingerprint types.  Defined types are:
+
+         0 is reserved
+         1 is SHA-1
+
+    Adding new reservations requires IETF consensus [4].
+
+
+
+Schlyter & Griffin       Expires March 5, 2004                  [Page 7]
+
+Internet-Draft          DNS and SSH Fingerprints          September 2003
+
+
+Normative References
+
+   [1]  Mockapetris, P., "Domain names - concepts and facilities", STD
+        13, RFC 1034, November 1987.
+
+   [2]  Mockapetris, P., "Domain names - implementation and
+        specification", STD 13, RFC 1035, November 1987.
+
+   [3]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
+        Levels", BCP 14, RFC 2119, March 1997.
+
+   [4]  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
+        Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
+
+   [5]  Eastlake, D., "Domain Name System Security Extensions", RFC
+        2535, March 1999.
+
+   [6]  Ylonen, T., Kivinen, T., Saarinen, M., Rinne, T. and S.
+        Lehtinen, "SSH Protocol Architecture",
+        draft-ietf-secsh-architecture-14 (work in progress), July 2003.
+
+   [7]  Ylonen, T., Kivinen, T., Saarinen, M., Rinne, T. and S.
+        Lehtinen, "SSH Transport Layer Protocol",
+        draft-ietf-secsh-transport-16 (work in progress), July 2003.
+
+Informational References
+
+   [8]   Thayer, R., Doraswamy, N. and R. Glenn, "IP Security Document
+         Roadmap", RFC 2411, November 1998.
+
+   [9]   Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington,
+         "Secret Key Transaction Authentication for DNS (TSIG)", RFC
+         2845, May 2000.
+
+   [10]  Eastlake, D., "DNS Request and Transaction Signatures (
+         SIG(0)s)", RFC 2931, September 2000.
+
+   [11]  Wellington, B., "Secure Domain Name System (DNS) Dynamic
+         Update", RFC 3007, November 2000.
+
+
+
+
+
+
+
+
+
+
+
+
+Schlyter & Griffin       Expires March 5, 2004                  [Page 8]
+
+Internet-Draft          DNS and SSH Fingerprints          September 2003
+
+
+Authors' Addresses
+
+   Jakob Schlyter
+   OpenSSH
+   812 23rd Avenue SE
+   Calgary, Alberta  T2G 1N8
+   Canada
+
+   EMail: jakob@openssh.com
+   URI:   http://www.openssh.com/
+
+
+   Wesley Griffin
+   SPARTA
+   7075 Samuel Morse Drive
+   Columbia, MD  21046
+   USA
+
+   EMail: wgriffin@sparta.com
+   URI:   http://www.sparta.com/
+
+Appendix A. Acknowledgements
+
+   The authors gratefully acknowledge, in no particular order, the
+   contributions of the following persons:
+
+      Martin Fredriksson
+
+      Olafur Gudmundsson
+
+      Edward Lewis
+
+      Bill Sommerfeld
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Schlyter & Griffin       Expires March 5, 2004                  [Page 9]
+
+Internet-Draft          DNS and SSH Fingerprints          September 2003
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   intellectual property or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; neither does it represent that it
+   has made any effort to identify any such rights. Information on the
+   IETF's procedures with respect to rights in standards-track and
+   standards-related documentation can be found in BCP-11. Copies of
+   claims of rights made available for publication and any assurances of
+   licenses to be made available, or the result of an attempt made to
+   obtain a general license or permission for the use of such
+   proprietary rights by implementors or users of this specification can
+   be obtained from the IETF Secretariat.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights which may cover technology that may be required to practice
+   this standard. Please address the information to the IETF Executive
+   Director.
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2003). 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 Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assignees.
+
+   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
+
+
+
+Schlyter & Griffin       Expires March 5, 2004                 [Page 10]
+
+Internet-Draft          DNS and SSH Fingerprints          September 2003
+
+
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Schlyter & Griffin       Expires March 5, 2004                 [Page 11]
+
diff --git a/doc/draft/draft-ihren-dnsext-threshold-validation-00.txt b/doc/draft/draft-ihren-dnsext-threshold-validation-00.txt
new file mode 100644
index 0000000..3578d2a
--- /dev/null
+++ b/doc/draft/draft-ihren-dnsext-threshold-validation-00.txt
@@ -0,0 +1,519 @@
+
+Internet Draft                                          Johan Ihren
+draft-ihren-dnsext-threshold-validation-00.txt          Autonomica
+February 2003
+Expires in six months
+
+
+                        Threshold Validation: 
+
+	 A Mechanism for Improved Trust and Redundancy for DNSSEC Keys
+
+
+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 draft documents 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 "work in
+   progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/ietf/1id-abstracts.txt
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+
+Abstract
+
+   This memo documents a proposal for a different method of validation
+   for DNSSEC aware resolvers. The key change is that by changing from
+   a model of one Key Signing Key, KSK, at a time to multiple KSKs it
+   will be possible to increase the aggregated trust in the signed
+   keys by leveraging from the trust associated with the different
+   signees. 
+
+   By having multiple keys to chose from validating resolvers get the
+   opportunity to use local policy to reflect actual trust in
+   different keys. For instance, it is possible to trust a single,
+   particular key ultimately, while requiring multiple valid
+   signatures by less trusted keys for validation to succeed.
+   Furthermore, with multiple KSKs there are additional redundancy
+   benefits available since it is possible to roll over different KSKs
+   at different times which may make rollover scenarios easier to
+   manage.
+
+Contents
+
+	1. Terminology
+	2. Introduction and Background
+
+	3. Trust in DNSSEC Keys
+	3.1. Key Management, Split Keys and Trust Models
+	3.2. Trust Expansion: Authentication versus Authorization
+
+	4. Proposed Semantics for Signing the KEY Resource Record 
+           Set
+	4.1. Packet Size Considerations
+
+	5. Proposed Use of Multiple "Trusted Keys" in a Validating 
+           Resolver
+	5.1. Not All Possible KSKs Need to Be Trusted
+	5.2. Possible to do Threshold Validation
+	5.3. Not All Trusted Keys Will Be Available
+
+	6. Additional Benefits from Having Multiple KSKs
+	6.1. More Robust Key Rollovers
+	6.2. Evaluation of Multiple Key Distribution Mechanisms
+
+	7. Security Considerations
+	8. IANA Considerations.
+	9. References
+	9.1. Normative.
+	9.2. Informative.
+	10. Acknowledgments.
+	11. Authors' Address
+
+
+1. Terminology
+
+   The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED",
+   and "MAY" in this document are to be interpreted as described in
+   RFC 2119. 
+
+   The term "zone" refers to the unit of administrative control in the
+   Domain Name System. "Name server" denotes a DNS name server that is
+   authoritative (i.e. knows all there is to know) for a DNS zone,
+   typically the root zone. A "resolver", is a DNS "client", i.e. an
+   entity that sends DNS queries to authoritative nameservers and
+   interpret the results. A "validating resolver" is a resolver that
+   attempts to perform DNSSEC validation on data it retrieves by doing
+   DNS lookups.
+
+
+2. Introduction and Background
+
+   From a protocol perspective there is no real difference between
+   different keys in DNSSEC. They are all just keys. However, in
+   actual use there is lots of difference. First and foremost, most
+   DNSSEC keys have in-band verification. I.e. the keys are signed by
+   some other key, and this other key is in its turn also signed by
+   yet another key. This way a "chain of trust" is created. Such
+   chains have to end in what is referred to as a "trusted key" for
+   validation of DNS lookups to be possible. 
+
+   A "trusted key" is a the public part of a key that the resolver
+   acquired by some other means than by looking it up in DNS. The
+   trusted key has to be explicitly configured.
+
+   A node in the DNS hierarchy that issues such out-of-band "trusted
+   keys" is called a "security apex" and the trusted key for that apex
+   is the ultimate source of trust for all DNS lookups within that
+   entire subtree.
+
+   DNSSEC is designed to be able to work with more than on security
+   apex. These apexes will all share the problem of how to distribute
+   their "trusted keys" in a way that provides validating resolvers
+   confidence in the distributed keys. 
+
+   Maximizing that confidence is crucial to the usefulness of DNSSEC
+   and this document tries to address this issue.
+
+
+3. Trust in DNSSEC Keys
+
+   In the end the trust that a validating resolver will be able to put
+   in a key that it cannot validate within DNSSEC will have to be a
+   function of
+
+   	    * trust in the key issuer, aka the KSK holder
+
+	    * trust in the distribution method
+
+	    * trust in extra, out-of-band verification
+
+   The KSK holder needs to be trusted not to accidentally lose private
+   keys in public places. Furthermore it needs to be trusted to
+   perform correct identification of the ZSK holders in case they are
+   separate from the KSK holder itself.
+
+   The distribution mechanism can be more or less tamper-proof. If the
+   key holder publishes the public key, or perhaps just a secure
+   fingerprint of the key in a major newspaper it may be rather
+   difficult to tamper with. A key acquired that way may be easier to
+   trust than if it had just been downloaded from a web page.
+
+   Out-of-band verification can for instance be the key being signed
+   by a certificate issued by a known Certificate Authority that the
+   resolver has reason to trust.
+
+3.1. Simplicity vs Trust 
+
+   The fewer keys that are in use the simpler the key management
+   becomes. Therefore increasing the number of keys should only be
+   considered when the complexity is not the major concern. A perfect
+   example of this is the distinction between so called Key Signing
+   Keys, KSK, and Zone Signing Keys, ZSK. This distinction adds
+   overall complexity but simplifies real life operations and was an
+   overall gain since operational simplification was considered to be
+   a more crucial issue than the added complexity.
+
+   In the case of a security apex there are additional issues to
+   consider, among them
+
+      * maximizing trust in the KSK received out-of-band
+
+      * authenticating the legitimacy of the ZSKs used
+
+   In some cases this will be easy, since the same entity will manage
+   both ZSKs and KSKs (i.e. it will authenticate itself, somewhat
+   similar to a self-signed certificate). In some environments it will
+   be possible to get the trusted key installed in the resolver end by
+   decree (this would seem to be a likely method within corporate and
+   government environments).
+
+   In other cases, however, this will possibly not be sufficient. In
+   the case of the root zone this is obvious, but there may well be
+   other cases.
+
+3.2. Expanding the "Trust Base"
+
+   For a security apex where the ZSKs and KSK are not held by the same
+   entity the KSK will effectively authenticate the identity of
+   whoever does real operational zone signing. The amount of trust
+   that the data signed by a ZSK will get is directly dependent on
+   whether the end resolver trusts the KSK or not, since the resolver
+   has no OOB access to the public part of the ZSKs (for practical
+   reasons).
+
+   Since the KSK holder is distinct from the ZSK holder the obvious
+   question is whether it would then be possible to further improve
+   the situation by using multiple KSK holders and thereby expanding
+   the trust base to the union of that available to each individual
+   KSK holder. "Trust base" is an invented term intended to signify
+   the aggregate of Internet resolvers that will eventually choose to
+   trust a key issued by a particular KSK holder.
+
+   A crucial issue when considering trust expansion through addition
+   of multiple KSK holders is that the KSK holders are only used to
+   authenticate the ZSKs used for signing the zone. I.e. the function
+   performed by the KSK is basically:
+
+   	     "This is indeed the official ZSK holder for this zone,
+   	     I've verified this fact to the best of my abilitites."
+
+   Which can be thought of as similar to the service of a public
+   notary. I.e. the point with adding more KSK holders is to improve
+   the public trust in data signed by the ZSK holders by improving the
+   strength of available authentication. 
+
+   Therefore adding more KSK holders, each with their own trust base,
+   is by definition a good thing. More authentication is not
+   controversial. On the contrary, when it comes to authentication,
+   the more the merrier.
+
+   
+4. Proposed Semantics for Signing the KEY Resource Record Set
+
+   In DNSSEC according to RFC2535 all KEY Resource Records are used to
+   sign all authoritative data in the zone, including the KEY RRset
+   itself, since RFC2535 makes no distinction between Key Signing
+   Keys, KSK, and Zone Signing Keys, ZSK.  With Delegation Signer [DS]
+   it is possible to change this to the KEY RRset being signed with
+   all KSKs and ZSKs but the rest of the zone only being signed by the
+   ZSKs.
+
+   This proposal changes this one step further, by recommending that
+   the KEY RRset is only signed by the Key Signing Keys, KSK, and
+   explicitly not by the Zone Signing Keys, ZSK. The reason for this
+   is to maximize the amount of space in the DNS response packet that
+   is available for additional KSKs and signatures thereof. The rest
+   of the authoritative zone contents are as previously signed by only
+   the ZSKs.
+
+4.1. Packet Size Considerations
+
+   The reason for the change is to keep down the size of the aggregate
+   of KEY RRset plus SIG(KEY) that resolvers will need to acquire to
+   perform validation of data below a security apex. For DNSSEC data
+   to be returned the DNSSEC OK bit in the EDNS0 OPT Record has to be
+   set, and therefore the allowed packet size can be assumed to be at
+   least the EDNS0 minimum of 4000 bytes.
+
+   When querying for KEY + SIG(KEY) for "." (the case that is assumed
+   to be most crucial) the size of the response packet after the
+   change to only sign the KEY RR with the KSKs break down into a
+   rather large space of possibilities. Here are a few examples for
+   the possible alternatives for different numbers of KSKs and ZSKs
+   for some different key lengths (all RSA keys, with a public
+   exponent that is < 254). This is all based upon the size of the
+   response for the particular example of querying for
+   
+	". KEY IN"
+
+   with a response of entire KEY + SIG(KEY) with the authority and
+   additional sections empty:
+
+   	      ZSK/768 and KSK/1024   (real small)
+	      Max 12 KSK +  3 ZSK  at 3975
+	          10 KSK +  8 ZSK  at 3934
+		   8 KSK + 13 ZSK  at 3893
+
+	      ZSK/768 + KSK/1280
+	      MAX 10 KSK +  2 ZSK  at 3913
+	           8 KSK +  9 ZSK  at 3970
+                   6 KSK + 15 ZSK  at 3914
+
+	      ZSK/768 + KSK/1536
+	      MAX  8 KSK +  4 ZSK  at 3917
+                   7 KSK +  8 ZSK  at 3938
+                   6 KSK + 12 ZSK  at 3959
+
+              ZSK/768 + KSK/2048
+              MAX  6 KSK +  5 ZSK  at 3936
+                   5 KSK + 10 ZSK  at 3942
+
+              ZSK/1024 + KSK/1024
+              MAX 12 KSK +  2 ZSK  at 3943
+                  11 KSK +  4 ZSK  at 3930
+                  10 KSK +  6 ZSK  at 3917
+                   8 KSK + 10 ZSK  at 3891
+
+              ZSK/1024 + KSK/1536
+              MAX  8 KSK +  3 ZSK  at 3900
+                   7 KSK +  6 ZSK  at 3904
+                   6 KSK +  9 ZSK  at 3908
+
+              ZSK/1024 + KSK/2048
+              MAX  6 KSK +  4 ZSK  at 3951
+                   5 KSK +  8 ZSK  at 3972
+                   4 KSK + 12 ZSK  at 3993
+
+   Note that these are just examples and this document is not making
+   any recommendations on suitable choices of either key lengths nor
+   number of different keys employed at a security apex.
+
+   This document does however, based upon the above figures, make the
+   recommendation that at a security apex that expects to distribute
+   "trusted keys" the KEY RRset should only be signed with the KSKs
+   and not with the ZSKs to keep the size of the response packets
+   down.
+
+
+5. Proposed Use of Multiple "Trusted Keys" in a Validating Resolver
+
+   In DNSSEC according to RFC2535[RFC2535] validation is the process
+   of tracing a chain of signatures (and keys) upwards through the DNS
+   hierarchy until a "trusted key" is reached. If there is a known
+   trusted key present at a security apex above the starting point
+   validation becomes an exercise with a binary outcome: either the
+   validation succeeds or it fails. No intermediate states are
+   possible.
+
+   With multiple "trusted keys" (i.e. the KEY RRset for the security
+   apex signed by multiple KSKs) this changes into a more complicated
+   space of alternatives. From the perspective of complexity that may
+   be regarded as a change for the worse. However, from a perspective
+   of maximizing available trust the multiple KSKs add value to the
+   system.
+
+5.1. Possible to do Threshold Validation
+
+   With multiple KSKs a new option that opens for the security
+   concious resolver is to not trust a key individually. Instead the
+   resolver may decide to require the validated signatures to exceed a
+   threshold. For instance, given M trusted keys it is possible for
+   the resolver to require N-of-M signatures to treat the data as
+   validated.
+
+   I.e. with the following pseudo-configuration in a validating
+   resolver
+
+   	security-apex "." IN {
+	   keys { ksk-1 .... ;
+      	          ksk-2 .... ;
+	          ksk-3 .... ; 
+		  ksk-4 .... ;
+		  ksk-5 .... ;
+	        };
+	   validation {
+	      # Note that ksk-4 is not present below
+	      keys { ksk-1; ksk-2; ksk-3; ksk-5; }; 
+              # 3 signatures needed with 4 possible keys, aka 75%
+              needed-signatures 3;
+           };
+	};
+
+   we configure five trusted keys for the root zone, but require two
+   valid signatures for the top-most KEY for validation to
+   succeed. I.e.  threshold validation does not force multiple
+   signatures on the entire signature chain, only on the top-most
+   signature, closest to the security apex for which the resolver has
+   trusted keys.		    
+
+5.2. Not All Trusted Keys Will Be Available
+
+   With multiple KSKs held and managed by separate entities the end
+   resolvers will not always manage to get access to all possible
+   trusted keys. In the case of just a single KSK this would be fatal
+   to validation and necessary to avoid at whatever cost. But with
+   several fully trusted keys available the resolver can decide to
+   trust several of them individually. An example based upon more
+   pseudo-configuration:
+
+   	security-apex "." IN {
+	   keys { ksk-1 .... ;
+      	          ksk-2 .... ;
+	          ksk-3 .... ; 
+		  ksk-4 .... ;
+		  ksk-5 .... ;
+	        };
+	   validation {
+	      # Only these two keys are trusted independently
+	      keys { ksk-1; ksk-4; }; 
+              # With these keys a single signature is sufficient
+	      needed-signatures 1;
+           };
+	};
+
+   Here we have the same five keys and instruct the validating
+   resolver to fully trust data that ends up with just one signature
+   from by a fully trusted key.
+
+   The typical case where this will be useful is for the case where
+   there is a risk of the resolver not catching a rollover event by
+   one of the KSKs. By doing rollovers of different KSKs with
+   different schedules it is possible for a resolver to "survive"
+   missing a rollover without validation breaking. This improves
+   overall robustness from a management point of view.
+
+5.3. Not All Possible KSKs Need to Be Trusted
+
+   With just one key available it simply has to be trusted, since that
+   is the only option available. With multiple KSKs the validating
+   resolver immediately get the option of implementing a local policy
+   of only trusting some of the possible keys.
+
+   This local policy can be implemented either by simply not
+   configuring keys that are not trusted or, possibly, configure them
+   but specify to the resolver that certain keys are not to be
+   ultimately trusted alone.
+
+
+6. Additional Benefits from Having Multiple KSKs
+
+6.1. More Robust Key Rollovers
+
+   With only one KSK the rollover operation will be a delicate
+   operation since the new trusted key needs to reach every validating
+   resolver before the old key is retired. For this reason it is
+   expected that long periods of overlap will be needed.
+
+   With multiple KSKs this changes into a system where different
+   "series" of KSKs can have different rollover schedules, thereby
+   changing from one "big" rollover to several "smaller" rollovers.
+
+   If the resolver trusts several of the available keys individually
+   then even a failure to track a certain rollover operation within
+   the overlap period will not be fatal to validation since the other
+   available trusted keys will be sufficient.
+
+6.2. Evaluation of Multiple Key Distribution Mechanisms
+
+   Distribution of the trusted keys for the DNS root zone is
+   recognized to be a difficult problem that ...
+
+   With only one trusted key, from one single "source" to distribute
+   it will be difficult to evaluate what distribution mechanism works
+   best. With multiple KSKs, held by separate entitites it will be
+   possible to measure how large fraction of the resolver population
+   that is trusting what subsets of KSKs.
+
+
+7. Security Considerations
+
+   From a systems perspective the simplest design is arguably the
+   best, i.e. one single holder of both KSK and ZSKs. However, if that
+   is not possible in all cases a more complex scheme is needed where
+   additional trust is injected by using multiple KSK holders, each
+   contributing trust, then there are only two alternatives
+   available. The first is so called "split keys", where a single key
+   is split up among KSK holders, each contributing trust. The second
+   is the multiple KSK design outlined in this proposal.
+
+   Both these alternatives provide for threshold mechanisms. However
+   split keys makes the threshold integral to the key generating
+   mechanism (i.e. it will be a property of the keys how many
+   signatures are needed). In the case of multiple KSKs the threshold
+   validation is not a property of the keys but rather local policy in
+   the validating resolver. A benefit from this is that it is possible
+   for different resolvers to use different trust policies. Some may
+   configure threshold validation requiring multiple signatures and
+   specific keys (optimizing for security) while others may choose to
+   accept a single signature from a larger set of keys (optimizing for
+   redundancy). Since the security requirements are different it would
+   seem to be a good idea to make this choice local policy rather than
+   global policy.
+
+   Furthermore, a clear issue for validating resolvers will be how to
+   ensure that they track all rollover events for keys they
+   trust. Even with operlap during the rollover (which is clearly
+   needed) there is still a need to be exceedingly careful not to miss
+   any rollovers (or fail to acquire a new key) since without this
+   single key validation will fail. With multiple KSKs this operation
+   becomes more robust, since different KSKs may roll at different
+   times according to different rollover schedules and losing one key,
+   for whatever reason, will not be crucial unless the resolver
+   intentionally chooses to be completely dependent on that exact key.
+
+8. IANA Considerations.
+
+   NONE.
+
+
+9. References
+
+9.1. Normative.
+
+   [RFC2535] Domain Name System Security Extensions. D. Eastlake. 
+	     March 1999.
+
+   [RFC3090] DNS Security Extension Clarification on Zone Status. 
+	     E. Lewis.  March 2001.
+
+
+9.2. Informative.
+
+   [RFC3110] RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System
+	     (DNS). D.  Eastlake 3rd. May 2001.
+
+   [RFC3225] Indicating Resolver Support of DNSSEC. D. Conrad. 
+	     December 2001.
+
+   [DS]      Delegation Signer Resource Record. 
+	     O. Gudmundsson. October 2002. Work In Progress.
+
+10. Acknowledgments.
+
+   Bill Manning came up with the original idea of moving complexity
+   from the signing side down to the resolver in the form of threshold
+   validation. I've also had much appreciated help from (in no
+   particular order) Jakob Schlyter, Paul Vixie, Olafur Gudmundson and
+   Olaf Kolkman.
+
+
+11. Authors' Address
+Johan Ihren
+Autonomica AB
+Bellmansgatan 30
+SE-118 47 Stockholm, Sweden
+johani@autonomica.se
diff --git a/doc/draft/draft-kato-dnsop-local-zones-00.txt b/doc/draft/draft-kato-dnsop-local-zones-00.txt
new file mode 100644
index 0000000..d857cd9
--- /dev/null
+++ b/doc/draft/draft-kato-dnsop-local-zones-00.txt
@@ -0,0 +1,295 @@
+
+
+
+Internet Engineering Task Force                         Akira Kato, WIDE
+INTERNET-DRAFT                                           Paul Vixie, ISC
+Expires: August 24, 2003                               February 24, 2003
+
+
+          Operational Guidelines for "local" zones in the DNS
+                  draft-kato-dnsop-local-zones-00.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 draft documents 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 ``work in progress.''
+
+To view the list Internet-Draft Shadow Directories, see
+http://www.ietf.org/shadow.html.
+
+Distribution of this memo is unlimited.
+
+The internet-draft will expire in 6 months.  The date of expiration will
+be August 24, 2003.
+
+
+Abstract
+
+A large number of DNS queries regarding to the "local" zones are sent
+over the Internet in every second.  This memo describes operational
+guidelines to reduce the unnecessary DNS traffic as well as the load of
+the Root DNS Servers.
+
+1.  Introduction
+
+While it has yet been described in a RFC, .local is used to provide a
+local subspace of the DNS tree.  Formal delegation process has not been
+completed for this TLD.  In spite of this informal status, .local has
+been used in many installations regardless of the awareness of the
+users.  Usually, the local DNS servers are not authoritative to the
+.local domain, they end up to send queries to the Root DNS Servers.
+
+There are several other DNS zones which describe the "local"
+information.  .localhost has been used to describe the localhost for
+more than a couple of decades and virtually all of the DNS servers are
+configured authoritative for .localhost and its reverse zone .127.in-
+
+
+KATO                    Expires: August 24, 2003                [Page 1]
+
+
+DRAFT                        DNS local zones               February 2003
+
+addr.arpa.  However, there are other "local" zones currently used in the
+Internet or Intranets connected to the Internet through NATs or similar
+devices.
+
+At a DNS server of an university in Japan, half of the DNS queries sent
+to one of the 13 Root DNS Servers were regarding to the .local.  At
+another DNS Server running in one of the Major ISPs in Japan, the 1/4
+were .local.  If those "local" queries are able to direct other DNS
+servers than Root, or they can be resolved locally, it contributes the
+reduction of the Root DNS Servers.
+
+2.  Rationale
+
+Any DNS queries regarding to "local" names should not be sent to the DNS
+servers on the Internet.
+
+3.  Operational Guidelines
+
+Those queries should be processed at the DNS servers internal to each
+site so that the severs respond with NXDOMAIN rather than sending
+queries to the DNS servers outside.
+
+The "local" names have common DNS suffixes which are listed below:
+
+3.1.  Local host related zones:
+
+Following two zones are described in [Barr, 1996] and .localhost is also
+defined in [Eastlake, 1999] .
+
+     o .localhost
+     o .127.in-addr.arpa
+
+
+Following two zones are for the loopback address in IPv6 [Hinden, 1998]
+.  While the TLD for IPv6 reverse lookup is .arpa as defined in [Bush,
+2001] , the old TLD .int has been used for this purpose for years
+[Thomson, 1995] and many implementations still use .int.  So it is
+suggested that both zones should be provided for each IPv6 reverse
+lookup zone for a while.
+
+     o 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.int
+     o 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa
+
+
+3.2.  Locally created name space
+
+While the use of .local has been proposed in several Internet-Drafts, it
+has not been described in any Internet documents with formal status.
+However, the amount of the queries for .local is much larger than
+others, it is suggested to resolve the following zone locally:
+
+
+
+
+KATO                    Expires: August 24, 2003                [Page 2]
+
+
+DRAFT                        DNS local zones               February 2003
+
+     o .local
+
+
+
+3.3.  Private or site-local addresses
+
+The following IPv4 "private" addresses [Rekhter, 1996] and IPv6 site-
+local addresses [Hinden, 1998] should be resolved locally:
+
+     o 10.in-addr.arpa
+     o 16.172.in-addr.arpa
+     o 17.172.in-addr.arpa
+     o 18.172.in-addr.arpa
+     o 19.172.in-addr.arpa
+     o 20.172.in-addr.arpa
+     o 21.172.in-addr.arpa
+     o 22.172.in-addr.arpa
+     o 23.172.in-addr.arpa
+     o 24.172.in-addr.arpa
+     o 25.172.in-addr.arpa
+     o 26.172.in-addr.arpa
+     o 27.172.in-addr.arpa
+     o 28.172.in-addr.arpa
+     o 29.172.in-addr.arpa
+     o 30.172.in-addr.arpa
+     o 31.172.in-addr.arpa
+     o 168.192.in-addr.arpa
+     o c.e.f.ip6.int
+     o d.e.f.ip6.int
+     o e.e.f.ip6.int
+     o f.e.f.ip6.int
+     o c.e.f.ip6.arpa
+     o d.e.f.ip6.arpa
+     o e.e.f.ip6.arpa
+     o f.e.f.ip6.arpa
+
+
+3.4.  Link-local addresses
+
+The link-local address blocks for IPv4 [IANA, 2002] and IPv6 [Hinden,
+1998] should be resolved locally:
+
+     o 254.169.in-addr.arpa
+     o 8.e.f.ip6.int
+     o 9.e.f.ip6.int
+     o a.e.f.ip6.int
+     o b.e.f.ip6.int
+     o 8.e.f.ip6.arpa
+     o 9.e.f.ip6.arpa
+     o a.e.f.ip6.arpa
+     o b.e.f.ip6.arpa
+
+
+
+KATO                    Expires: August 24, 2003                [Page 3]
+
+
+DRAFT                        DNS local zones               February 2003
+
+4.  Suggestions to developers
+
+4.1.  Suggestions to DNS software implementors
+
+In order to avoid unnecessary traffic, it is suggested that DNS software
+implementors provide configuration templates or default configurations
+so that the names described in the previous section are resolved locally
+rather than sent to other DNS servers in the Internet.
+
+4.2.  Suggestions to developers of NATs or similar devices
+
+There are many NAT or similar devices available in the market.
+Regardless of the availability of DNS Servers in those devices, it is
+suggested that those devices are able to filter the DNS traffic or
+respond to the DNS traffic related to "local" zones by configuration
+regardless of its ability of DNS service.  It is suggested that this
+functionality is activated by default.
+
+5.  IANA Consideration
+
+While .local TLD has yet defined officially, there are substantial
+queries to the Root DNS Servers as of writing. About 1/4 to 1/2% of the
+traffic sent to the Root DNS Servers are related to the .local zone.
+Therefore, while it is not formally defined, it is suggested that IANA
+delegates .local TLD to an organization.
+
+The AS112 Project [Vixie, ] serves authoritative DNS service for RFC1918
+address and the link-local address.  It has several DNS server instances
+around the world by using BGP Anycast [Hardie, 2002] .  So the AS112
+Project is one of the candidates to host the .local TLD.
+
+Authors' addresses
+
+     Akira Kato
+     The University of Tokyo, Information Technology Center
+     2-11-16 Yayoi Bunkyo
+     Tokyo 113-8658, JAPAN
+     Tel: +81 3-5841-2750
+     Email: kato@wide.ad.jp
+
+
+     Paul Vixie
+     Internet Software Consortium
+     950 Charter Street
+     Redwood City, CA 94063, USA
+     Tel: +1 650-779-7001
+     Email: vixie@isc.org
+
+
+
+
+
+
+
+KATO                    Expires: August 24, 2003                [Page 4]
+
+
+DRAFT                        DNS local zones               February 2003
+
+References
+
+To be filled
+
+References
+
+Barr, 1996.
+D. Barr, "Common DNS Operational and Configuration Errors" in RFC1912
+(February 1996).
+
+Eastlake, 1999.
+D. Eastlake, "Reserved Top Level DNS Names" in RFC2606 (June 1999).
+
+Hinden, 1998.
+R. Hinden and S. Deering, "IP Version 6 Addressing Architecture" in
+RFC2373 (July 1998).
+
+Bush, 2001.
+R. Bush, "Delegation of IP6.ARPA" in RFC3152 (August 2001).
+
+Thomson, 1995.
+S. Thomson and C. Huitema, "DNS Extensions to support IP version 6" in
+RFC1886 (December 1995).
+
+Rekhter, 1996.
+Y. Rekhter, B. Moskowitz, D. Karrenberg, G. J. de Groot, and E. Lear,
+"Address Allocation for Private Internets" in RFC1918 (February 1996).
+
+IANA, 2002.
+IANA, "Special-Use IPv4 Addresses" in RFC3330 (September 2002).
+
+Vixie, .
+P. Vixie, "AS112 Project" in AS112. http://www.as112.net/.
+
+Hardie, 2002.
+T. Hardie, "Distributing Authoritative Name Servers via Shared Unicast
+Addresses" in RFC3258 (April 2002).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+KATO                    Expires: August 24, 2003                [Page 5]
+
diff --git a/doc/draft/draft-park-ipv6-extensions-dns-pnp-00.txt b/doc/draft/draft-park-ipv6-extensions-dns-pnp-00.txt
new file mode 100644
index 0000000..f9eaf26
--- /dev/null
+++ b/doc/draft/draft-park-ipv6-extensions-dns-pnp-00.txt
@@ -0,0 +1,1830 @@
+  
+  
+  
+  INTERNET-DRAFT                                       S. Daniel Park
+  Expires: October 2003                              Syam Madanapalli
+  File:                                           SAMSUNG Electronics
+  draft-park-ipv6-extensions-dns-pnp-00.txt                April 2003
+  
+  
+  
+  
+                 IPv6 Extensions for DNS Plug and Play
+  
+  
+  
+  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 draft documents 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 "work in
+  progress."
+
+  The list of current Internet-Drafts can be accessed at
+  http://www.ietf.org/ietf/1id-abstracts.txt
+
+  The list of Internet-Draft Shadow Directories can be accessed at
+  http://www.ietf.org/shadow.html.
+  
+  
+  
+  Abstract  
+  
+  This document proposes automatic configuration of domain name (FQDN)
+  for IPv6 nodes using Domain Name Auto-Configuration (called 6DNAC) as
+  a part of IPv6 plug and play feature. 6DNAC allows the automatic
+  registration of domain name and corresponding IPv6 Addresses with
+  the DNS server. In order to provide 6DNAC function, Neighbor Discovery
+  Protocol [2461] will be used. Moreover, 6DNAC does not require any
+  changes to the existing DNS system.
+  
+  
+  Table of Contents 
+  
+  1.       Introduction .............................................  3
+  2.       Terminology ..............................................  3
+  3.       6DNAC Design Principles ..................................  4
+  4.       6DNAC Overview ...........................................  4
+  5.       6DNAC Requirements .......................................  5
+  5.1.     6DANR Client Requirements ................................  5
+  5.2.     6DNAC Server Requirements ................................  6
+    
+Park & Madanapalli             Expires October 2003             [Page 1]
+
+INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003    
+    
+  6.       6DNAC Messages and Option Formats ........................  6
+  6.1.     Router Advertisement (RA) Message Format .................  6
+  6.2.     Neighbor Solicitation (NS) Message Format ................  7
+  6.3.     Neighbor Advertisement (NA) Message Format ...............  8
+  6.4.     Option Formats ...........................................  8
+  6.4.1.   DNS Zone Suffix Information Option Format ................  8
+  6.4.2.   Domain Name (FQDN) Option Format .........................  9
+  6.4.3.   Router Alert Option for 6DNAC ............................ 10
+  7.       6DNAC Operation .......................................... 10
+  7.1.     6DNAC Network Topology ................................... 11
+  7.2.     6DNAC Operational Scenarios .............................. 12
+  7.2.1.   Domain Name Registration-Success Case .................... 12
+  7.2.2.   Domain Name Registration-with DupAddrDetectTransmits=2.... 14
+  7.2.3.   Domain Name Registration-Defend Case ..................... 16
+  7.2.4.   Domain Name Registration in Retry Mode ................... 19
+  7.2.5.   Domain Name Registration when DAD Fails .................. 20
+  7.3.     DNS Zone Suffix Discovery and FQDN Construction .......... 22
+  7.3.1.   Sending Router Advertisement Messages .................... 22
+  7.3.2.   Processing Router Advertisement Messages ................. 22
+  7.3.3.   FQDN Lifetime expiry ..................................... 23
+  7.3.4.   Host Naming Algorithm .................................... 23
+  7.4.     Duplicate Domain Name Detection .......................... 23
+  7.4.1.   DAD with All Nodes Multicast Address ..................... 24
+  7.4.1.1. Sending Neighbor Solicitation Messages ................... 24
+  7.4.1.2. Processing Neighbor Solicitation Messages ................ 24
+  7.4.1.3. Sending Neighbor Advertisement Messages .................. 25
+  7.4.1.4. Processing Neighbor Advertisement Messages ............... 25
+  7.4.1.5. Pros and Cons ............................................ 25
+  7.4.2.   DAD with Router Alert Option for 6DNAC ................... 25
+  7.4.2.1. Sending Neighbor Solicitation Messages ................... 25
+  7.4.2.2. Processing Neighbor Solicitation Messages ................ 26
+  7.4.2.3. Sending Neighbor Advertisement Messages .................. 26
+  7.4.2.4. Processing Neighbor Advertisement Messages ............... 26
+  7.4.2.5. Pros and Cons ............................................ 26
+  7.4.3.   Explicit Detection of Duplicate Domain Name .............. 26
+  7.4.3.1. Sending Neighbor Solicitation Messages ................... 26
+  7.4.3.2. Processing Neighbor Solicitation Messages ................ 26
+  7.4.3.3. Sending Neighbor Advertisement Messages .................. 27
+  7.4.3.4. Processing Neighbor Advertisement Messages ............... 27
+  7.4.3.5. Pros and Cons ............................................ 27
+  7.4.4.   Retry Mode for Re-registering Domain Name ................ 27
+  7.5.     Domain Name Registration ................................. 27
+  8.       Security Consideration ................................... 27
+  9.       IANA Consideration ....................................... 28
+  10.      Acknowledgement .......................................... 28
+  11.      Intellectual Property .................................... 28
+  12.      Copyright ................................................ 28
+  13.      References ............................................... 29
+  14.      Author's Addresses ....................................... 30
+
+
+
+
+
+
+
+
+Park & Madanapalli             Expires October 2003             [Page 2]
+
+INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003  
+  
+  1. Introduction 
+  
+  Today, most networks use DNS[1034][1035] for convenience. In case of
+  IPv6, DNS is more important element because of IPv6 long addresses
+  which are difficult to remember. In addition, small networks like home
+  networks using IPv6, should be able to make network easily without
+  manual configuration. Also, these small networks may not have DHCP
+  Server, DNS Server etc. that are used to configure the network. This
+  document discusses IPv6 Domain Name Auto-Configuration(6DNAC) procedure
+  for generating and registering the Domain Name and IPv6 addresses with
+  the DNS Server automatically. In order to use 6DNAC, IPv6 nodes are
+  required to implement lightweight functions specified in this document.
+  6DNAC can be applied to all defined IPv6 unicast addresses except Link
+  local IPv6 addresses, viz: Site-local and Global addresses.
+  
+  6DNAC uses Neighbor Discovery Protocol [2461] with new additions
+  (defined in section 6) and DAD procedures for generating and 
+  registering the Domain Name with the DNS server automatically.
+  
+  
+  2. Terminology
+
+  6DNAC         - IPv6 Domain Name Auto Configuration. It can provide
+                  IPv6 hosts with Domain Name Generation and 
+                  Registration automatically.
+  
+  6DNAC Client  - An IPv6 node that can generate its own unique Domain
+                  Name. Section 3 identifies the new requirements that
+                  6DNAC places on an IPv6 node to be a 6DNAC node.
+                  
+  6DNAC Server  - An IPv6 node that can collect and registrate Domain
+                  Name and IPv6 addresses automatically. 6DNAC server
+                  uses the information from the DAD operation messages
+                  with newly defined options for the registration of the 
+                  Domain Name and IPv6 Addresses. Section 3 identifies
+                  the new requirements that 6DNAC places on an IPv6 
+                  node to be a 6DNAC server. Also 6DNAC server can have 
+                  various other functions depending on network 
+                  environment and the network operator. For instance 
+                  6DNAC Server can acts as a Gateway as well Home Server
+                  in Home Networks.
+ 
+  DAD           - Duplicate Address Detection (is defined [2461]) 
+  
+  DFQDND        - Duplicate Domain Name Detection
+
+  FQDN          - Fully Qualified Domain Name - FQDN and Domain Name are 
+                  used interchangeably in this document.
+  
+  NA            - Neighbor Advertisement message (is defined [2461]) 
+  
+  NS            - Neighbor Solicitation message (is defined [2461])
+
+  RA            - Router Advertisement message (is defined [2461]) 
+
+  SLAAC         - Stateless Address Autoconfiguration [2462].
+
+Park & Madanapalli             Expires October 2003             [Page 3]
+
+INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003  
+  
+  3. 6DNAC Design Principles
+  
+  This section discusses the design principles of 6DNAC mechanism.
+  
+  1. The new procedures for plug and play DNS should not cause changes
+     to existing DNS system. 6DNAC requires lightweight functions to be 
+     implemented only at the client side of the DNS system, and uses the 
+     existing DDNS UPDATE [2136] to communicate with DNS Servers.
+  
+  2. Introducing a new protocol will always introduce new problems. 
+     6DNAC uses the existing protocols NDP [2461] with minor extensions 
+     for generating and registering the domain name automatically 
+     without defining a new protocol
+  
+  3. Reusing proven and well understood design principles/patterns 
+     will always yield a robust system. 6DNAC is based on IPv6 Address 
+     Auotoconfiguration principle, where routers advertise the prefix
+     and host adds the interface ID to the prefix and forms the IPv6 
+     address. Domain Name (FQDN) also contains two parts: host name 
+     and DNS zone suffix. Routers can advertise the DNS zone suffix 
+     on a particular link in Router Advertisements (RA Messages) and 
+     hosts can prefix their preferred host name to the DNS zone suffix
+     and form the fully qualified domain name. Also the detection of
+     duplicate domain name is similar to Duplicate Address Detection
+     (DAD) and can be part of DAD operation itself.
+  
+  
+  4. 6DNAC Overview
+  
+  6DNAC proposes minor extensions to NDP [2461] for automatic generation
+  and registration of domain name with the DNS server. It introduces two
+  new options: DNS Zone Suffix and Fully Qualified Domain Name. DNS Zone
+  Suffix option is carried in Router Advertisement (RA) messages for
+  notifying IPv6 nodes about the valid DNS Zone Suffix on the link and
+  FQDN option in Neighbor Solicitation (NS) and Neighbor Advertisement
+  (NA) messages to detect duplicate domain name. 6DNAC consists of two
+  components: 6DNAC Client and 6DNAC Server. 6DNAC Clients generate the
+  domain name based on DNS Zone Suffix using Host Naming Algorithm (see
+  section 7.3.1) and 6DNAC Server collects and registers the DNS
+  information with the DNS Server on behalf of 6DNAC Clients.
+
+  The automatic configuration of domain name using 6DNAC consists of
+  three parts.
+
+     - DNS Zone Suffix Discovery and FQDN Construction:
+
+       IPv6 Nodes collect DNS Zone Suffix information from Router
+       Advertisements and constructs FQDN by prefixing host name to the
+       DNS Zone Suffix. The IPv6 Nodes are required to implement Host 
+       Naming Algorithm for generating host part of the FQDN in the 
+       absence of administrator.
+
+  Generation of node's FQDN within the node itself has advantages. Nodes
+  can provide forward and reverse name lookups independent of the DNS
+  System by sending queries directly to IPv6 nodes [NIQ]. Moreover Domain
+  Name is some thing that is owned by the node.
+
+Park & Madanapalli             Expires October 2003             [Page 4]
+
+INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003
+  
+     - Duplicate Domain Name Detection
+
+       All nodes are expected to go for DAD for all new IPv6 unicast
+       addresses, regardless of whether they are obtained through 
+       stateful, stateless or manual configuration. 6DNAC uses the DAD 
+       messages with new option for carrying the Domain Name along with 
+       the new IPv6 Address. 6DNAC Server captures this information and
+       updates DNS Server provided that the IPv6 Address and its domain
+       name are not duplicate. If the domain name is already in use, 
+       the 6DNAC server replies to the sender with FQDN Option in NA 
+       message indicating that the domain name is duplicate. Then the
+       node is expected to generate another domain name using host 
+       naming algorithm and go for DAD. This time the DAD is only for
+       duplicate domain name detection (DFQDND). In order to avoid
+       confusion with the normal NDP processing, the target address 
+       field of the NS message must carry the unspecified address 
+       in retry mode.  This can be repeated depending on number of
+       retries defined by the administrator in the host naming algorithm.
+
+  
+     - Domain Name Registration
+
+       6DNAC Server detects the DNS information (IPv6 Address and 
+       corresponding FQDN) from DAD/DFQDND messages and updates DNS 
+       Server using existing protocol DDNS UPDATE [2136] provided that
+       the IPv6 Address and its domain name are not duplicate.
+  
+  If an IPv6 Address is duplicate, the IPv6 node cannot perform
+  stateless address autoconfiguration repeatedly. Unlike IPv6 stateless 
+  address autoconfiguration, 6DNAC allows the automatic configuration of
+  domain name repeatedly if the domain name is duplicate depending on 
+  number of retries defined by the administrator in the host naming 
+  algorithm.
+  
+  
+  5. 6DNAC Requirements 
+  
+  Depending on the 6DNAC functionality, the IPv6 nodes implement, they
+  are called either 6DNAC Clients or 6DNAC Servers. The following 
+  sections lists the requirements that the 6DNAC Client and 6DNAC server
+  must support.
+   
+   
+  5.1. 6DANC Client Requirements
+  
+        - 6DNAC Client must recognize and process the following NDP 
+          extensions
+
+              - DNS Zone Suffix option in RA messages for generating its
+                domain name (FQDN).
+
+              - Domain Name option in NS and NA messages for detecting 
+                the duplicate domain name
+ 
+ 
+ 
+
+Park & Madanapalli             Expires October 2003             [Page 5]
+
+INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003 
+  
+        - It must generate its domain name (FQDN) based on the DNS 
+          suffix that it got from the router advertisement. And it must 
+          have a host naming algorithm for generating the host part of
+          the FQDN.
+
+        - If NA message is received with unspecified target address and
+          FQDN option, then the node must treat that the domain is 
+          duplicate.
+  
+  
+  5.2. 6DNAC Server Requirements
+  
+        - 6DNAC Server must recognize and process the following NDP
+          extensions
+      
+              - If the 6DNAC Server is a router on the link, then it
+                must advertise DNS Zone Suffix option in RA messages
+                for hosts to generate their domain name (FQDN).
+
+              - FQDN option in NS messages for detecting new DNS
+                information for of nodes on the link for which it
+                must update the AAAA RR and PTR RR in DNS Server.
+
+              - FQDN option in NA messages for notifying duplicate
+                domain name with unspecified target address.
+  
+        - 6DNAC server must update the DNS Server (both AAAA RR and
+          PTR RR) dynamically using DDNS UPDATE [2136].
+  
+        - 6DNAC server must cache this (newly detected) FQDN, Link
+          Layer Address, and IPv6 Address information, so that it can
+          decide whether it really needs to update DNS Server or not,
+          to avoid redundant updates. This information will also be
+          used for notifying the duplicate domain name.
+  
+  
+  6. 6DNAC Messages and Option Formats
+  
+  In order to achieve the plug and play DNS, 6DNAC proposes new 
+  extensions to the NDP [2461]. This section specifies the new
+  additions to NDP messages and formats of new options.
+  
+  
+  6.1. Router Advertisement (RA) Message Format
+  
+  Routers send out Router Advertisement (RA) message periodically, or
+  in response to a Router Solicitation. 6DNAC does not modify the format
+  of the RA message, but proposes new option (DNS Zone Suffix Information)
+  to be carried in RA messages.
+
+
+
+
+
+
+
+
+Park & Madanapalli             Expires October 2003             [Page 6]
+
+INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003
+  
+      0                   1                   2                   3
+      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |     Type      |     Code      |          Checksum             |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     | Cur Hop Limit |M|O|  Reserved |       Router Lifetime         |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |                         Reachable Time                        |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |                          Retrans Timer                        |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |   Options ...                                                 |
+     /                                                               /
+     |                  DNS Zone Suffix Information                  |
+     |                                                               |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+  
+  
+                          <Figure: 1 RA message>
+  
+  
+  
+  6.2. Neighbor Solicitation (NS) Message Format 
+  
+  6DNAC does not modify the format of the Neighbor Solicitation (NS)
+  message, but proposes new option (FQDN Option) to be carried in NS
+  messages. When a node is going for DAD, the node must include FQDN
+  option in NS message to participate in plug and play DNS. If the
+  node is going for Explicit Detection of Duplicate Domain Name, the
+  node must use FQDN option in NS message and unspecified address in
+  the target address field.
+  
+  
+      0                   1                   2                   3 
+      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |     Type      |     Code      |          Checksum             |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |                           Reserved                            |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |                                                               |
+     +                                                               +
+     |                                                               |
+     +                       Target Address                          +
+     |                                                               |
+     +                                                               +
+     |                                                               |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |   Options ...                                                 |
+     /                                                               /
+     |                         Domain Name                           |
+     |                                                               |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+  
+  
+                         <Figure: 2 NS message>
+  
+Park & Madanapalli             Expires October 2003             [Page 7]
+
+INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003  
+  
+  6.3. Neighbor Advertisement (NA) Message Format 
+  
+  6DNAC does not modify the format of the Neighbor Advertisement (NA)
+  message, but proposes new option (FQDN Option) to be carried in NA
+  messages. 6DNAC Server sends NA message with FQDN option to 6DNAC
+  Client that is performing duplicate domain name detection in case
+  the domain name found to be duplicate.
+
+      0                   1                   2                   3
+      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |     Type      |     Code      |          Checksum             |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |R|S|O|                     Reserved                            |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |                                                               |
+     +                                                               +
+     |                                                               |
+     +                       Target Address                          +
+     |                                                               |
+     +                                                               +
+     |                                                               |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |   Options ...                                                 |
+     /                                                               /
+     |                         FQDN Option                           |
+     |                                                               |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+  
+  
+                          <Figure: 3 NA message> 
+  
+  
+  6.4 Option Formats
+  
+  6.4.1. DNS Zone Suffix Information Option Format
+  
+  IPv6 nodes require DNS Zone Suffix for constructing their FQDN.
+  6DNAC introduces new option for routers to advertise the DNS Zone
+  Suffix Information for IPv6 nodes on the link. The suffix information
+  should be configured into routers manually.
+
+      0                   1                   2                   3
+      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |     Type      |    Length     |          Reserved             |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |                          Valid Lifetime                       |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |                                                               |
+     /                       DNS Zone Suffix                         /
+     |                                                               |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+  
+  
+                   <Figure: 4 DNS Zone Suffix Information>
+
+Park & Madanapalli             Expires October 2003             [Page 8]
+
+INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003  
+  
+  Type              [TBD]
+  
+  Length            8-bit unsigned integer. The length of the option
+                    (including the type and length fields) in units of
+                    8 octets.
+  
+  Reserved          This field is unused. It must be initialized to zero
+                    by the sender and must be ignored by the receiver.
+  
+  Valid Life Time   32-bit signed integer.  The maximum time, in 
+                    seconds, over which this suffix is valid. Nodes 
+                    should treat this as the life time for their domain
+                    name. Nodes should contact the source of this
+                    information before expiry of this time interval.
+                    A value of all one bits (0xFFFFFFFF) represents
+                    infinity.
+  
+  DNS Zone Suffix   The suffix part of the FQDN. The data in the DNS 
+                    Zone Suffix field should be encoded according to 
+                    DNS encoding rules specified in [1035].
+  
+  
+  
+  6.4.2. Domain Name (FQDN) Option Format
+  
+  
+      0                   1                   2                   3
+      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |     Type      |    Length     |          Reserved             |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |                          Valid Lifetime                       |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |                                                               |
+     +                                                               +
+     |                                                               |
+     +                       FQDN Target Address                     +
+     |                                                               |
+     +                                                               +
+     |                                                               |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |                                                               |
+     /                         Domain Name                           /
+     |                                                               |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+  
+  
+                      <Figure: 5 FQDN Information>
+  
+  Type                 [TBD]
+  
+  Length               8-bit unsigned integer. The length of the option
+                       (including the type and length fields) in units 
+                       of 8 octets.  It must be greater than 3.
+                       
+                       
+
+Park & Madanapalli             Expires October 2003             [Page 9]
+
+INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003                       
+  
+  Reserved             This field is unused. It must be initialized to
+                       zero by the sender and must be ignored by the
+                       receiver.
+  
+  Valid Life Time      32-bit signed integer.  The maximum time, in 
+                       seconds, over which this domain name is valid
+                       6DNAC should deregister this domain name at
+                       the expiry of this interval. 6DNAC clients
+                       should send updates by the expiry of this 
+                       interval. A value of all one bits (0xFFFFFFFF)
+                       represents infinity.
+
+  FQDN Target Address  The Address for which the FQDN maps to.  It 
+                       should be same as Target Address field of the 
+                       NS message in case of DAD & duplicate FQDN are
+                       running in parallel.
+
+  Domain Name          The domain name (FQDN) of the node. The data in
+                       the domain name should be encoded according to
+                       DNS encoding rules specified in [1035].
+  
+  
+  6.4.3. Router Alert Option for 6DNAC
+
+  Router Alert Option for 6DNAC is new option within the IPv6 Hop-by-Hop
+  Header for using in NDP messages.  The presence of this option in NS
+  message informs the router that this NS message is carrying Domain
+  Name information and must be processed by the 6DNAC Server on the router.
+  6DNAC Clients can use this option for sending DAD packets instead
+  of addressing the DAD packets to the all-nodes multicast address
+  when 6DNAC Server is implemented on router.
+ 
+  The Router Alert option has the following format:
+
+  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+  |0 0 0|0 0 1 0 1|0 0 0 0 0 0 1 0|        Value (2 octets)       |
+  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                     Length = 2
+
+  Values are registered and maintained by the IANA. For 6DNAC, the 
+  value has to be assigned by IANA.
+
+  Further information about this option can be obtained from 
+  IPv6 Router Alert Option [2711].
+
+
+  7. 6DNAC Operation
+  
+  6DNAC provides mechanisms for automatic generation of domain name
+  and registering it with the DNS Server for IPv6 nodes. 6DNAC consists
+  of two components: 6DNAC Client and 6DNAC Server. All nodes that want
+  to participate in plug and play DNS are required to implement 6DNAC
+  Client functionality, and one of the IPv6 nodes is required to 
+  implement 6DNAC Server functionality. The IPv6 node that implements 
+  the 6DNAC Server functionality must know the location of the DNS 
+  Server and must be a trusted node to send DDNS UPDATE [2136] messages.
+
+Park & Madanapalli             Expires October 2003            [Page 10]
+
+INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003  
+  
+  7.1. 6DNAC Network Topology
+  
+  This section identifies the possible locations for the 6DNAC Server.
+  Note that, all nodes are required to implement 6DNAC Client 
+  functionality for constructing the domain name from the DNS Zone 
+  Suffix Information advertised by the router.  Figure 6 illustrates 
+  IPv6 host (H4) implementing 6DNAC Server functionality. In this case 
+  H4 can serve only one link (that it belongs to) for automatic 
+  registration of domain name. H4 must observe the DAD packets on the 
+  link to detect the DNS information, this requires all nodes on the 
+  link must belong to same solicited node multicast address. In general,
+  this may not be the case. So the node that is going for DAD must use
+  all nodes multicast address for DAD packets, so that the 6DNAC Server
+  (H4) can observe the DAD packets, detects IPv6 address and 
+  corresponding domain name, checks if this domain name is duplicate 
+  and finally registers the domain name with the DNS Server.
+ 
+  
+                          6DNAC Server
+      +---+                   +---+                     +----------+
+      | H1|                   | H4|<--- DDNS UPDATE --->|DNS Server|
+      +-+-+                   +-+-+                     +----+-----+
+        |                       |           +----+       +---/
+        |                       |           |    |      /
+     ---+-----+-----------+-----+-----------+ R1 +-----+
+              |           |                 |    |
+              |           |                 +----+
+            +-+-+       +-+-+
+            | H2|       | H3|
+            +---+       +---+
+  
+  
+  H1, H2, H3 - 6DNAC Clients
+  H4         - 6DNAC Server
+  R1         - Router
+  
+  
+                  <Figure: 6 Example of 6DNAC Topology>
+  
+  
+  Figure 7 shows the 6DNAC Server implemented on a router R1. In this
+  case a single 6DNAC server can serve multiple links for automatic
+  configuration of the domain name. This topology also has flexibility
+  of using DAD packets with Router Alert option instead of sending DAD
+  packets to all nodes multicast address. The routers are required to
+  process all the packets with Router Alert option as per [2711].
+
+  In case of Home Networks, R1 is will acts as a Home Gateway (CPE)
+  connected to ISP. R1 delegates the prefix from the ISP edge router.
+  After delegating the prefix the CPE can advertise the DNS Zone suffix
+  along with the prefix information to the nodes on the links to which
+  the router is connected to. Note that the R1 must be configured with
+  the DNS Zone suffix Information manually. 
+
+
+
+
+Park & Madanapalli             Expires October 2003            [Page 11]
+
+INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003
+  
+                         +---+       +---+ 
+                         | H3+       | H4|
+                         +-+-+       +-+-+
+                           |           |
+                           |   LINK2   |
+      +---+             ---+--------+--+--          +----------+
+      | H1|                         |               |DNS Server|
+      +-+-+                         |               +----+-----+
+        |                        +--+-+           -------/
+        |         LINK 1         |    |          /
+     ---+-----+------------------+ R1 +---------+
+              |                  |    |      DDNS UPDATE
+              |                  +----+
+            +-+-+             6DNAC Server
+            | H2|
+            +---+
+  
+  
+  H1, H2 - 6DNAC Clients on Link1
+  H3, H4 - 6DNAC Clients on Link2
+  R1     - Router with 6DNAC Server, serving both Link1 and Link2
+  
+  
+       <Figure: 7 Example of 6DNAC Server serving multiple links>
+  
+  
+  7.2. 6DNAC Operational Scenarios
+  
+  This section provides message sequence charts for various 6DNAC
+  operational scenarios assuming that the 6DNAC Server is implemented
+  on a router. All the scenarios assume that the normal boot up time
+  stateless address autoconfiguration of Link Local address derived
+  from the Interface Identifier has been completed successfully. And
+  it is also assumed that the router is already configured with the
+  DNS Zone Suffix Information.
+
+  
+  Legend:
+  
+  6DNAC-A, B, C  : 6DNAC Clients
+  6DNAC-S        : 6DNAC Server/Router
+  DAD            : Duplicate Address Detection
+  DFQDND         : Duplicate Domain Name Detection
+  DNS-S          : DNS Server
+  
+  
+  7.2.1. Domain Name Registration-Successful Case 
+
+  This scenario starts when a 6DNAC Client receives RA message with
+  DNS Zone Suffix and other parameters including address prefix as
+  specified in NDP [2461] and wants configure its IPv6 address (Global
+  or Site Local) and domain name. It is Assumed that the 
+  DupAddrDetectTransmits is set to 1.
+
+
+
+
+Park & Madanapalli             Expires October 2003            [Page 12]
+
+INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003
+  
+   +---------+      +---------+      +---------+
+   | 6DNAC-C |      | 6DNAC-S |      |  DNS-S  |
+   +----+----+      +----+----+      +----+----+
+        |                |                |
+        |     RA with    |                |
+        | DNS Suffix Opt |                |
+        |<---------------|                |
+        |       #1       |                |
+        |---+            |                |
+  Construct |#2          |                |
+    FQDN    |            |                |
+        |<--+            |                |
+DAD/DFQDND Starts        |                |
+        |                |                |
+        |                |                |
+        |    NS With     |                |
+        |    FQDN Opt    |                |
+        |--------------->|                |
+        |       #3       |                |
+        |                |                |
+        |                |------+         |
+        |          Create FQDN  | #4      |
+        |            <FQDN,C>   |         |
+        |                |<-----+         |
+        |                |                |
+        |                |  Register FQDN |
+        |                |--------------->|
+        |                |       #5       |
+        |   #6           |                |
+        |--------+       |                |
+   No Response   |       |                |
+  DFQDND-Success |       |                |
+        |<-------+       |                |
+        |                |                |
+        |                |                |
+        v                V                v  
+
+
+          <Figure: 8 Domain Name Generation and Registration>
+           
+  
+  #1. 6DNAC Server (Router) sends out router advertisement with DNS
+      Suffix information along with other parameters as specified in
+      NDP [2461].
+  
+  #2. 6DNAC Client processes the router advertisement and constructs
+      the FQDN by prefixing hostname to the DNS Zone Suffix. It also
+      constructs IPv6 address from the autoconfiguration prefix
+      information option.
+
+  #3. 6DNAC Client starts duplicate address & FQDN detection for the
+      IPv6 address & FQDN constructed and sends out a Neighbor
+      Solicitation message with FQDN option. 
+
+      Note that the DAD packets must be addressed to all nodes multicast
+      address if Router Alert option is not used. 
+      
+Park & Madanapalli             Expires October 2003            [Page 13]
+
+INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003          
+
+  #4. 6DNAC Server processes the Neighbor Solicitation message sent by
+      6DNAC Client as part of duplicate FQDN detection procedure and
+      creates a FQDN entry in its FQDN Cache (assuming that there is no
+      entry <FQDN,C>), where C is Link Layer Address of the 6DNAC Client.
+
+  #5.  6DNAC Server then registers FQDN and corresponding IPv6 address
+       through the existing protocol DDNS UPDATE.
+
+  #6.  6DNAC Client times out and observes that there is no response to
+       defend its duplicate FQDN detection procedure and the node is
+       successful in configuring its domain name.
+  
+  Note that, Stateless Address Autoconfiguration DAD procedure is not
+  depicted in the following message sequence chart, which simultaneously
+  happens along with duplicate FQDN detection.
+  
+
+  7.2.2. Domain Name Registration-with DupAddrDetectTransmits=2 
+
+  This scenario starts when a 6DNAC Client receives RA message with
+  DNS Zone Suffix and other parameters including address prefix as
+  specified in NDP [2461] and wants configure its IPv6 address (Global
+  or Site Local) and domain name. The node is configured with 
+  DupAddrDetectTransmits = 2 for reliability in delivering DAD messages.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Park & Madanapalli             Expires October 2003            [Page 14]
+
+INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003 
+
+   +---------+      +---------+      +---------+
+   | 6DNAC-C |      | 6DNAC-S |      |  DNS-S  |
+   +----+----+      +----+----+      +----+----+
+        |                |                |
+        |     RA with    |                |
+        | DNS Suffix Opt |                |
+        |<---------------|                |
+        |       #1       |                |
+        |---+            |                |
+  Construct |#2          |                |
+    FQDN    |            |                |
+        |<--+            |                |
+DAD/DFQDND Starts        |                |
+        |                |                |
+        |                |                |
+        |    NS With     |                |
+        |    FQDN Opt    |                |
+        |--------------->|                |
+        |       #3       |                |
+        |                |                |
+        |                |------+         |
+        |          Create FQDN  | #4      |
+        |            <FQDN,C>   |         |
+        |                |<-----+         |
+        |                |                |
+        |                |  Register FQDN |
+        |                |--------------->|
+        |                |       #5       |
+        |    NS With     |                |
+        |    FQDN Opt    |                |
+        |--------------->|                |
+        |      #6        |                |
+        |                |                |
+        |          Lookup FQDN            |
+        |          Entry exists           |
+        |                |------+         |
+        |             Ignore    | #7      |
+        |                |<-----+         |
+        |   #8           |                |
+        |--------+       |                |
+   No Response   |       |                |
+  DFQDND-Success |       |                |
+        |<-------+       |                |
+        |                |                |
+        |                |                |
+        v                V                v  
+
+  
+  
+            <Figure: 9 Verification of duplicated Domain Name>
+
+
+  Steps from #1 to #5 are same as that of scenario.7.2.1.
+  
+  #6. 6DNAC Client sends out second Neighbor Solicitation message with
+      FQDN option as part of duplicate FQDN detection.
+      
+Park & Madanapalli             Expires October 2003            [Page 15]
+
+INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003      
+
+  #7. 6DNAC Server receives and observes that the FQDN Cache exactly
+      matches with that of the NS information and ignores the NS message.
+
+  #8. 6DNAC Client times out and observes that there is no response to
+      defend its duplicate FQDN detection procedure and the node is
+      successful in configuring its domain name..
+
+  
+  7.2.3. Domain Name Registration-Defend Case 
+
+  This scenario starts when two 6DNAC Client receive RA message with
+  DNS Zone Suffix and other parameters including address prefix as
+  specified in NDP [2461] and both the nodes want configure their IPv6
+  address (Global or Site Local) and domain name. In this scenario both
+  the nodes want to have same domain name.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Park & Madanapalli             Expires October 2003            [Page 16]
+
+INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003
+
+
+
+   +---------+      +---------+      +---------+      +---------+
+   | 6DNAC-A |      | 6DNAC-S |      | 6DNAC-B |      |  DNS-S  |
+   +----+----+      +----+----+      +----+----+      +----+----+
+        |                |                |                |
+        |     RA with    |     RA with    |                |
+        | DNS Suffix Opt | DNS Suffix Opt |                |
+        |<---------------|--------------->|                |
+        |       #1       |       #1       |                |
+        |---+            |                |---+            |
+  Construct | #2         |          Construct | #2         |
+      FQDN  |            |              FQDN  |            |
+        |<--+            |                |<--+            |
+ DAD/DFQDND Starts       |         DAD/DFQDND Starts       |
+        |                |            <DELAYED>            |
+        |                |                |                |
+        |    NS with     |                |                |
+        |    FQDN Opt    |                |                |
+        |--------------->|                |                |
+        |      #3        |                |                |
+        |            No Entry             |                |
+        |                |------+         |                |
+        |          Create FQDN  | #4      |                |
+        |            <FQDN,A>   |         |                |
+        |                |<-----+         |                |
+        |                |                |                |
+        |                |         Register FQDN #5        |
+        |                |-------------------------------->|
+        |                |                |                |
+        |                |    NS with     |                |
+        |                |    FQDN Opt    |                |
+        |                |<---------------|                |
+        |                |       #6       |                |
+        |                |------+         |                |
+        |         FQDN is in use|         |                |
+        |          Defend DFQDND| #7      |                |
+        |                |<-----+         |                |
+        |                |                |                |
+        |                |    NA with     |                |
+        |                |    D-flag Set  |                |
+        |                |--------------->|                |
+        |                |       #8       |                |
+        |------+         |                |---+            |
+ No Response   | #9      |            Enter   | #10        |
+ DFQDND Success|         |          Retry Mode|            |
+        |<-----+         |                |<--+            |
+        |                |                |                |
+        v                v                v                v
+
+         
+       <Figure: 10 Multiple Hosts Requesting Same Domain Name>
+
+
+
+
+
+Park & Madanapalli             Expires October 2003            [Page 17]
+
+INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003          
+
+  #1. 6DNAC Server (Router) sends out router advertisement with DNS
+      Suffix information.
+      
+  #2. 6DNAC Clients A&B process the router advertisement and construct
+      their FQDN by prefixing hostname to the DNS Zone Suffix.  They
+      also construct IPv6 address from the autoconfiguration prefix
+      information option.
+      
+      When each host is trying to go for DAD, all hosts must have
+      random delay to avoid the traffic congestion according to [2461].
+      So here it is assumed that 6DNAC Client-A starts DAD first and
+      6DNAC Client-B starts DAD later.
+
+  #3. 6DNAC Client-A starts duplicate address & FQDN detection for the
+      IPv6 address & FQDN constructed and sends out a Neighbor
+      Solicitation message with FQDN option.
+   
+  #4. 6DNAC Server processes the Neighbor Solicitation message sent by
+      6DNAC Client-A as part of duplicate FQDN detection procedure and
+      creates a FQDN entry in its FQDN Cache (assuming that there is no
+      entry <FQDN,A>), where A is Link Layer Address of the 6DNAC Client-A.
+
+  #5. 6DNAC Server then registers FQDN and corresponding IPv6 address
+      through the existing protocol DDNS UPDATE.
+
+  #6. 6DNAC Client-B starts duplicate address & FQDN detection for the
+      IPv6 address & FQDN constructed and sends out a Neighbor Solicitation
+      message with FQDN option. 
+
+  #7. 6DNAC Server processes the Neighbor Solicitation message sent by
+      6DNAC Client-B as part of duplicate FQDN detection procedure and 
+      finds that the domain name is already in use by the 6DNAC Client-A.
+      Hence, concludes to defend the duplicate FQDN detection of 6DNAC
+      Client-B.
+
+  #8. 6DNAC Server sends out Neighbor Advertisement message with FQDN
+      option to 6DNAC Client-B to defend its duplicate FQDN detection.
+
+  #9. 6DNAC Client-A times out and observes that there is no response to
+      defend its duplicate FQDN detection procedure and the node is 
+      successful in configuring its domain name.
+
+  #10. 6DNAC Client-B observes that there is a NA with FQDN option
+       indicating that the domain name is duplicate and enters Retry
+       Mode. In retry mode, 6DNAC Client constructs another FQDN based
+       on Host Naming Algorithm. The number of retries is defined by the
+       administrator and must be a configurable value.
+  
+
+
+
+
+
+
+
+
+
+Park & Madanapalli             Expires October 2003            [Page 18]
+
+INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003  
+  
+  7.2.4. Domain Name Registration in Retry Mode
+
+  Pre-Conditions:
+
+  1. Duplicate Address Detection has succeeded 
+  2. Duplicate FQDN Detection FAILED
+  3. FQDN is the first FQDN one constructed and FAILED
+  4. FQDN2 is the second FQDN to be constructed
+  5. The Neighbor Solicitation in the 'Retry Mode'
+    carries unspecified address in its target field (NS*).
+
+   +---------+      +---------+      +---------+
+   | 6DNAC-C |      | 6DNAC-S |      |  DNS-S  |
+   +----+----+      +----+----+      +----+----+
+        |                |                |
+        |--------+       |                |
+    Construct    | #1    |                |
+    new FQDN2    |       |                |
+        |<-------+       |                |
+        |                |                |
+  DFQDND Restarts        |                |
+        |                |                |
+        |                |                |
+        |    NS* With    |                |
+        |    FQDN Opt    |                |
+        |--------------->|                |
+        |       #2       |                |
+        |                |                |
+        |            No Entry             |
+        |                |------+         |
+        |          Create FQDN  | #3      |
+        |            <FQDN2,C>  |         |
+        |                |<-----+         |
+        |                |                |
+        |                | Register FQDN2 |
+        |                |--------------->|
+        |                |       #4       |
+        |                |                |
+        |--------+       |                |
+   No Response   | #5    |                |
+  DFQDND-Success |       |                |
+        |<-------+       |                |
+        |                |                |
+        v                V                v
+
+                
+                <Figure: 11 Regeneration of Domain Name>
+                
+
+
+
+
+
+
+
+
+
+Park & Madanapalli             Expires October 2003            [Page 19]
+
+INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003
+ 
+  #1. 6DNAC Client constructs the FQDN again as per Host Naming Algorithm,
+      the DNS Zone Suffix, and it is FQDN2.
+  #2. It then starts Duplicate Detection only for Domain Name. 6DNAC
+      Client sends out NS with FQDN option and unspecified target
+      address.
+
+  #3. 6DNAC Server processes the Retry Mode NS message and finds that
+      the FQDN2 is not in use and creates Cache entry as <FQDN2, C>.
+
+  #4. It then starts registration procedures with the DNS Server.
+
+  #5. Meanwhile, 6DNAC Client timesout and observes that there is no
+      defending NA for its DFQDND NS sent out and successfully
+      configures its domain name.
+
+
+  7.2.5. Domain Name Registration when DAD Fails
+
+  Duplicate domain name detection and subsequent registration starts 
+  if and only if the DAD for IPv6 address succeeds. If the DAD for
+  IPv6 address fails then no actions are taken for domain name. When
+  DAD fails for stateless address autoconfiguration, then the domain
+  configuration starts only when the address has been configured using 
+  Stateful Address Configuration methods and the node is going on DAD
+  for this address.
+
+  This scenario starts when a 6DNAC Client receives RA message with
+  DNS Zone Suffix and other parameters including address prefix as
+  specified in NDP [2461] and wants configure its IPv6 address (Global
+  or Site Local) and domain name.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Park & Madanapalli             Expires October 2003            [Page 20]
+
+INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003
+
+   +---------+      +---------+      +---------+      +---------+
+   | 6DNAC-A |      | 6DNAC-S |      | 6DNAC-B |      |  DNS-S  |
+   +----+----+      +----+----+      +----+----+      +----+----+
+        |                |                |                |
+        |                |                |                |
+        |     RA with    |                |                |
+        | DNS Suffix Opt |                |                |
+        |<---------------|                |                |
+        |       #1       |                |                |
+        |-----+          |                |                |
+    Construct |          |                |                |
+      FQDN&   | #2       |                |                |
+    IPv6 Addr |          |                |                |
+        |<----+          |                |                |
+ DAD/DFQDND Starts       |                |                |
+        |                |                |                |
+        |                |                |                |
+        |    NS with     |                |                |
+        |    FQDN Opt    |                |                |
+        |--------------->+--------------->|                |
+        |       #3       |        #3      |                |
+        |            No Entry             |                |
+        |                |------+         |                |
+        |          Create FQDN  |         |                |
+        |            <FQDN,A>   | #4      |                |
+        |                |<-----+         |                |
+        |                |                |                |
+        |                |                |------+         |
+        |                |           My IPv6 Addr| #5      |
+        |                |                |<-----+         |
+        |                |   Defend DAD   |                |
+        |                |    with NA     |                |
+        |<---------------+<---------------|                |
+        |      #6        |       #6       |                |
+        |              Entry              |                |
+        |                |------+         |                |
+        |          Delete FQDN  | #7      |                |
+        |                |<-----+         |                |
+        |                |                |                |
+        |----+           |                |                |
+  DAD Failed | #8        |                |                |
+ Stop DFQDND |           |                |                |
+        |<---+           |                |                |
+        |                |                |                |
+        v                v                v                v
+
+                     <Figure: 12 DAD failure>
+
+  #1. 6DNAC Server sends out Router Advertisement to 6DNAC Client-A.
+
+  #2. 6DNAC Client-A constructs IPv6 Address based on the prefix and
+      FQDN as per Host Naming Algorithm. 
+
+  #3. It then starts Duplicate address & FQDN Detection, for the newly 
+      constructed IPv6 address and FQDN, and sends out DAD/DFQDND NS
+      with FQDN option.  
+
+Park & Madanapalli             Expires October 2003            [Page 21]
+
+INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003      
+
+  #4. 6DNAC Server processes the DAD/DFQDND NS message and finds 
+      that there is no entry for the FQDN in its cache. And,
+      creates Cache entry as <FQDN, A> and starts a Registration
+      timer with RegistrationWaitTime seconds.
+
+  #5. 6DNAC Client-B finds that the DAD/DFQDND-NS target address is 
+      in its unicast address list.  
+
+  #6. It then starts defending DAD by sending NA to all-nodes multicast.
+
+  #7. 6DNAC Server finds that the DAD has failed for 6DNAC Client-A.  
+      And, deletes its FQDN Cache entry <FQDN,A>.
+      
+  #8. 6DNAC Client gets defending DAD-NA and desists from DAD. 
+      And also, stops Duplicate FQDN Detection as well.
+      At this point the address must be configured using stateful 
+      methods and the domain name registration starts with the DAD
+      for the newly constructed IPv6 address.
+  
+  7.3. DNS Zone Suffix Discovery and FQDN Construction
+  
+  7.3.1. Sending Router Advertisement Messages
+
+  Routers send out Router Advertisement message periodically, 
+  or in response to a Router Solicitation. Router should include 
+  the DNS Zone Suffix Option in their advertisements. If the DNS
+  Zone Suffix changes (similar to Site Renumbering), then it should
+  advertise the Old Zone Suffix with zero Valid Lifetime and New
+  Zone Suffix with proper non-zero Valid Lifetime.  In any other
+  case, a router should not send this option twice in a single
+  router advertisement.
+
+  7.3.2. Processing Router Advertisement Messages  
+
+  For each DNS Zone Suffix Option in Router Advertisement,
+
+  a. 6DNAC node stores the Zone Suffix information in its local
+     database.  Also, constructs FQDN as per Host Naming Algorithm.
+
+  b. If the node has not configured FQDN yet,
+
+     1. If the node is going to perform DAD for either Site local or 
+        Global Address, then it should include FQDN option to perform
+        Duplicate FQDN Detection in parallel with DAD.
+
+     2. If the node has already got either Site local or Global 
+        address, then it should send out NS with FQDN option and 
+        unspecified target address to perform Duplicate FQDN 
+        Detection.
+
+  c. If the node has already configured FQDN, and if the 
+     advertisement carries two DNS Zone Suffix Options,
+     First DNS Zone Suffix should match with the configured FQDN 
+     Suffix and its Valid Lifetime must be zero. Second DNS Zone
+
+
+
+Park & Madanapalli             Expires October 2003            [Page 22]
+
+INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003
+
+
+     Suffix should have non-zero Valid Lifetime. In this case, the
+     node constructs new FQDN based on the new DNS Zone Suffix (from
+     second DNS Zone Suffix option), and perform Duplicate FQDN 
+     Detection with unspecified target address.  Also, it should
+     overwrite the old FQDN with the newly constructed FQDN.
+     
+
+  7.3.3. FQDN Lifetime expiry
+
+  6DNAC Server:  
+  It should delete the FQDN cache entry and should de-register from
+  the DNS Server.
+
+  6DNAC Client:
+  It should send update to 6DNAC Server by restarting the Duplicate 
+  FQDN Detection. 
+  
+  7.3.4. Host Naming Algorithm
+ 
+  A node constructs FQDN by combining DNS Zone Suffix and the hostname
+  as depicted in the following diagram.
+
+     +------------------+----------------------------------+
+     |     Host Name    |          Advertised Suffix       |
+     +------------------+----------------------------------+
+
+          <Figure 13: Fully Qualified Domain Name format>
+
+  A node can choose Host Name using any of the following methods:
+ 
+  a. String form of random number generated from the Interface 
+     Identifier.
+     
+  b. List of configured Host Names provided by the administrator.
+
+  
+  The number of retries must be specified in this algorithm in 
+  case of domain name duplication.
+  
+    
+  7.4. Duplicate Domain Name Detection
+  
+  The procedure for detecting duplicated FQDNs uses Neighbor
+  Solicitation and Advertisement messages as described below.
+
+  If a duplicate FQDN is detected during the procedure, the
+  FQDN cannot be assigned to the node.
+
+  An FQDN on which the DFQDND Procedure is applied is said 
+  to be tentative until the procedure has completed successfully.  
+  A tentative FQDN is not considered "assigned to the node" in the 
+  traditional sense.  That is, the node must accept Neighbor 
+  Advertisement message containing the tentative FQDN in the FQDN 
+  Option.
+
+
+Park & Madanapalli             Expires October 2003            [Page 23]
+
+INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003
+
+
+  It should also be noted that DFQDN must be performed prior to 
+  registering with DNS Server to prevent multiple nodes from using 
+  the same FQDN simultaneously. All the Duplicate Address Detection 
+  Neighbor Solicitation messages must carry Source Link Layer Address 
+  Option as specified in NDP [2461]. 
+
+  The detection of duplicate FQDN can be achieved through one of the
+  following three types of procedures.
+  
+  1. DAD with All Nodes Multicast Address
+  2. DAD with Router Alert Option for 6DNAC.
+  3. Explicit Detection of Duplicate Domain Name
+   
+  Even though three solutions are listed, authors prefer only one 
+  procedure to be followed in future based on further analysis and
+  comments received from others. 
+  
+  7.4.1. DAD with All Nodes Multicast Address
+  
+  7.4.1.1. Sending Neighbor Solicitation Messages
+
+  6DNAC Client sends Neighbor Solicitation Messages as part
+  of Duplicate Address Detection SLAAC [2462] with the following 
+  extra information and modifications:
+
+  a. Include FQDN Option in the DAD Neighbor Solicitation Message
+  b. Destination Address is set to All Nodes Multicast Address
+
+  There may be a case where DAD has succeeded but DFQDND is in Retry 
+  Mode. In such case, the Neighbor Solicitation must carry unspecified 
+  address in the ICMP target address field and new domain name in FQDN
+  option to re-try the registration of the domain name.
+
+  7.4.1.2. Processing Neighbor Solicitation Messages
+
+  6DNAC Clients must ignore the FQDN option found in any of the
+  neighbor solicitation messages.
+
+  6DNAC Server processes FQDN Option found in the Duplicate Address 
+  Detection Neighbor Solicitation Messages as described below:
+
+  Lookup FQDN Cache for the domain name in FQDN Option.
+
+  If the entry exists and 
+   i. Link Layer Address matches with SLLA option, this is the case, 
+      where node has changed its IPv6 address or updating the valid 
+      life time. 6DNAC Server updates its cache and also updates DNS
+      Server using DDNS-UPDATE. If there is no change in IPv6 address
+      or life time then no updates are sent to the DNS server. 
+
+  ii. Link Layer Address differs with SLLA option, defend the duplicate 
+      FQDN Detection by sending Neighbor Advertisement Message as 
+      described in $7.4.1.3$.
+
+
+
+Park & Madanapalli             Expires October 2003            [Page 24]
+
+INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003
+
+
+  else,
+    Lookup FQDN Cache for the Link Layer Address in SLLA Option.
+
+    If the entry exists, update the FQDN Cache and update DNS Server 
+    using DDNS-UPDATE. This is the case, where node has changed its
+    domain name (similar to Site Re-numbering).
+
+    If then entry does not exists, then it means that this is the new 
+    registration. It must create a cache entry and start Registration    
+    
+    timer with RegistrationWaitTime. At the expiry of the Registration
+    timer, it should update DNS Server with DDNS-UPDATE.
+
+  7.4.1.3. Sending Neighbor Advertisement Messages
+
+  6DNAC Server sends Neighbor Advertisement Messages as part
+  of Duplicate Address Detection SLAAC [2462] with the FQDN Option 
+  in Neighbor Advertisement message to defend duplicate FQDN 
+  detection.
+
+  There may be the case where defending of duplicate address detection 
+  is not required but defending of FQDN is required.  In such instance, 
+  the defending Neighbor Advertisement must carry FQDN and unspecified
+  address in the ICMP target address field.
+
+  7.4.1.4. Processing Neighbor Advertisement Messages
+
+  6DNAC Server must ignore the any FQDN option found any of 
+  the neighbor advertisement messages.  If the Neighbor Advertisement
+  is a DAD defending, then it must delete its FQDN Cache entry created 
+  on the reception of DAD Neighbor Solicitation message.
+
+  When 6DNAC Clients gets the duplicate address detection neighbor
+  advertisement messages with FQDN option set it means that its
+  duplicate FQDN detection failed and enters Retry Mode.
+
+  7.4.1.5. Pros and Cons
+  
+  The advantage of this procedure is that it does not need any 
+  extension header options to be included. The disadvantage of this 
+  procedure is that, it needs change in the existing DAD procedure.
+  The change is only that the DAD neighbor solicitations are to be 
+  addressed to all nodes multicast address instead of solicited 
+  node multicast address. The another disadvantage is that, it needs 
+  the existence of Duplicate Address Detection Procedure to 
+  perform duplicate FQDN detection. 
+  
+  7.4.2. DAD with Router Alert Option for 6DNAC
+
+  7.4.2.1. Sending Neighbor Solicitation Messages
+
+  6DNAC Client sends Neighbor Solicitation Messages as part
+  of Duplicate Address Detection SLAAC [2462] with the following 
+  extra information:
+
+
+Park & Madanapalli             Expires October 2003            [Page 25]
+
+INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003
+
+
+  a. Include Hop-by-Hop extension Header with Router Alert Option
+     for 6DNAC as described in IPv6 Router Alert Option[2711].
+
+  b. Include FQDN Option in the DAD Neighbor Solicitation Message
+
+  7.4.2.2. Processing Neighbor Solicitation Messages
+
+  This is same as described in $7.4.1.2$. 
+
+  7.4.2.3. Sending Neighbor Advertisement Messages
+
+  This is same as described in $7.4.1.3$. 
+
+  7.4.2.4. Processing Neighbor Advertisement Messages
+
+  This is same as described in $7.4.1.4$.
+
+  7.4.2.5. Pros and Cons
+
+  The advantage of this procedure is that it does not disturb
+  the existing implementation and their way of processing the 
+  packets.  The disadvantage is that, it needs the existence 
+  of Duplicate Address Detection Procedure to perform duplicate 
+  FQDN detection. Another disadvantage is that this procedure 
+  requires 6DNAC Server functionality to be implemented on Router.
+  However, in this case 6DNAC Server can serve multiple links.
+  
+  7.4.3. Explicit Detection of Duplicate Domain Name
+
+  In this procedure Duplicate FQDN Detection starts after completion
+  of successful Site local or Global Address configuration.
+  
+  7.4.3.1. Sending Neighbor Solicitation Messages
+
+  6DNAC Client sends Neighbor Solicitation Messages as part
+  of Duplicate FQDN Detection with the following information:
+
+  a. Include FQDN Option in the Neighbor Solicitation Message
+
+  b. Destination Address is set to All Nodes Multicast Address
+     or uses Router Alert Option for 6DNAC, when 6DNAC Server is 
+     implemented on router.
+
+  c. Target Address is set to Unspecified Address
+
+  d. Other fields are set as per DAD SLAAC [2462].
+
+  7.4.3.2. Processing Neighbor Solicitation Messages
+
+  This is same as described in $7.4.1.2$.
+
+
+
+
+
+
+Park & Madanapalli             Expires October 2003            [Page 26]
+
+INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003 
+
+
+  7.4.3.3. Sending Neighbor Advertisement Messages
+
+  This is same as described in $7.4.1.3$.
+
+  7.4.3.4. Processing Neighbor Advertisement Messages
+
+  This is same as described in $7.4.1.4$.
+
+  7.4.3.5. Pros and Cons
+
+  The advantage of this procedure is that it does not need the
+  existing duplicate address detection procedure.  This is introduced
+  as the DAD procedure is found to be redundant in when IPv6 addresses
+  are constructed from the interface ID [DIID].
+
+  Note that, if 6DNAC Clients know the address of 6DNAC Server then
+  they can directly send DFQDND-NS to 6DNAC Server. 
+
+  7.4.4. Retry Mode for Re-registering Domain Name
+
+  In retry mode, nodes construct new FQDN as per Host Naming Algorithm.
+  Then they restart Duplicate FQDN Detection as described in $7.4.3$.
+
+
+  7.5. Domain Name Registration
+  
+  6DNAC Server must be an authenticated to update the DNS Server.
+  6DNAC Server must also be configured with the DNS Server 
+  information.
+
+  6DNAC Server detects the DNS information (IPv6 Address and 
+  corresponding FQDN) from DAD/DFQDND messages and caches the
+  information. It also have an associated Registration Timer with 
+  RegistrationWaitTime to wait for the successful completion of 
+  DFQDND and update DNS Server using existing protocol DDNS UPDATE 
+  [2136].
+  
+                 
+  8. Security Consideration
+   
+  If someone wants to hijack correct Domain Name registration, they 
+  could send a NS message with incorrect or same Domain Name to the
+  6DNAC server repeatedly and server would start the Domain Name 
+  registration through above mechanism, which is a security hole. 
+  As described in [2461], a host can check validity of NDP messages.
+  If the NDP message include an IP Authentication Header, the message
+  authenticates correctly. For DNS UPDATE processing, secure DNS
+  Dynamic Update is described in [3007].
+  
+
+
+
+
+
+
+
+Park & Madanapalli             Expires October 2003            [Page 27]
+
+INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003
+
+  
+  9. IANA Consideration
+  
+  Values in the Router Alert Option are registered and maintained by
+  IANA. For 6DNAC, the value has to be assigned by IANA. Also IANA is
+  required to assign the Type values for DNS Zone Suffix Information
+  option and FADN option.
+
+  
+  10. Acknowledgement
+  
+  Special thanks are due to Badrinarayana N.S. and Christian Huitema for
+  many helpful suggestions and revisions. 
+  
+  
+  11. Intellectual Property
+
+  The following notice is copied from RFC 2026 [Bradner, 1996],
+  Section 10.4, and describes the position of the IETF concerning
+  intellectual property claims made against this document.
+
+  The IETF takes no position regarding the validity or scope of any
+  intellectual property or other rights that might be claimed to
+  pertain to the implementation or use other technology described in
+
+  this document or the extent to which any license under such rights
+  might or might not be available; neither does it represent that it
+  
+  has made any effort to identify any such rights.  Information on the
+  IETF's procedures with respect to rights in standards-track and
+  standards-related documentation can be found in BCP-11.  Copies of
+  claims of rights made available for publication and any assurances
+  of licenses to be made available, or the result of an attempt made
+  to obtain a general license or permission for the use of such
+  proprietary rights by implementers or users of this specification
+  can be obtained from the IETF Secretariat.
+
+  The IETF invites any interested party to bring to its attention any
+  copyrights, patents or patent applications, or other proprietary
+  rights which may cover technology that may be required to practice
+  this standard.  Please address the information to the IETF Executive
+  Director.
+  
+  
+  12. Copyright
+
+  The following copyright notice is copied from RFC 2026 [Bradner,
+  1996], Section 10.4, and describes the applicable copyright for this
+  document.
+
+  Copyright (C) The Internet Society July 12, 2001. 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
+
+Park & Madanapalli             Expires October 2003            [Page 28]
+
+INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003
+
+
+  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 Standards process must be
+  followed, or as required to translate it into languages other than
+  English.
+
+  The limited permissions granted above are perpetual and will not be
+  revoked by the Internet Society or its successors or assignees.
+
+  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.
+  
+  
+  13. References
+   
+  [2373]        Hinden, R. and S. Deering, "IP Version 6 Addressing 
+                Architecture", RFC 2373, July 1998. 
+       
+  [2460]        Deering, S. abd R. Hinden, "Internet Protocol, 
+                Version 6 (IPv6) Specification", RFC 2460, 
+                December 1998. 
+               
+  [2461]        Narten, T., Nordmark, E. and W. Simpson, "Neighbor 
+                Discovery for IP version 6(IPv6)", RFC 2461, December 
+                1998. 
+
+  [2462]        S. Thomson and Narten T, "IPv6 Stateless Address Auto- 
+                Configuration", RFC 2462, December 1998. 
+               
+  [2711]        C. Patridge and A.Jackson, "IPv6 Router Alert Option",
+                RFC 2711, October 1999. 
+             
+  [1034]        P. Mockapetris, "DOMAIN NAMES - CONCEPTS AND 
+                FACILITIES", RFC 1034, November 1987. 
+               
+  [1035]        P. Mockapetris, "Domain Names - Implementation and 
+                Specification" RFC 1035, November 1987. 
+
+  [2136]        P. Vixie et al., "Dynamic Updates in the Domain Name
+                System (DNS UPDATE)", RFC2136, April 1997.
+                
+  [3007]        B. Wellington, "Secure Domain Name System (DNS) Dynamic 
+                Update", RFC 3007, November 2000.
+
+
+
+Park & Madanapalli             Expires October 2003            [Page 29]
+
+INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003
+
+                 
+  [DIID]        yokohama-dad-vs-diid.pdf
+                at http://playground.sun.com/ipng/presentations/July2002/
+                
+  [DNSISSUES]   Durand, A., "IPv6 DNS transition issues", draft-ietf-              
+                dnsop-ipv6-dns-issues-00.txt, work in progress.
+                
+  [PREFIX]      S. Miyakawa, R. Droms, "Requirements for IPv6 prefix
+                delegation", draft-ietf-ipv6-prefix-delegation-
+                requirement-01.txt, work in progress.
+   
+  [Autoreg]     H. Kitamura, "Domain Name Auto-Registration for 
+                Plugged-in IPv6 Nodes", draft-ietf-dnsext-ipv6-name-
+                auto-reg-00.txt, work in progress.
+
+  [NIQ]         Matt Crawford, "IPv6 Node Information Queries", <draft-
+                ietf-ipngwg-icmp-name-lookups-09.txt>, work in progress.
+                  
+  
+  14. Author's Addresses 
+  
+  Soohong Daniel Park 
+  Mobile Platform Laboratory, SAMSUNG Electronics, KOREA 
+  Phone: +82-31-200-3728 
+  Email:soohong.park@samsung.com
+  
+  Syam Madanapalli
+  Network Systems Division, SAMSUNG India Software Operations, INDIA
+  Phone: +91-80-5550555
+  Email:syam@samsung.com
+  
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Park & Madanapalli             Expires October 2003            [Page 30]
diff --git a/doc/draft/update b/doc/draft/update
new file mode 100644
index 0000000..6ac2090
--- /dev/null
+++ b/doc/draft/update
@@ -0,0 +1,46 @@
+#!/bin/sh
+commit=
+for i
+do
+	z=`expr "$i" : 'http://www.ietf.org/internet-drafts/\(.*\)'`
+	if test -n "$z"
+	then
+		i="$z"
+	fi
+	if test -f "$i"
+	then
+		continue
+	fi
+	pat=`echo "$i" | sed 's/...txt/??.txt/'`
+	old=`echo $pat 2> /dev/null`
+	if test "X$old" != "X$pat"
+	then
+		newer=0
+		for j in $old
+		do
+			if test $j ">" $i
+			then
+				 newer=1
+			fi
+		done
+		if test $newer = 1
+		then
+			continue;
+		fi
+	fi
+	if fetch "http://www.ietf.org/internet-drafts/$i" 
+	then
+		cvs add "$i" 
+		if test "X$old" != "X$pat"
+		then
+			rm $old
+			cvs delete $old
+			commit="$commit $old"
+		fi
+		commit="$commit $i"
+	fi
+done
+if test -n "$commit"
+then
+	cvs commit -m "new draft" $commit
+fi
diff --git a/doc/misc/Makefile.in b/doc/misc/Makefile.in
new file mode 100644
index 0000000..40a62fe
--- /dev/null
+++ b/doc/misc/Makefile.in
@@ -0,0 +1,47 @@
+# Copyright (C) 2004, 2007  Internet Systems Consortium, Inc. ("ISC")
+# Copyright (C) 2001  Internet Software Consortium.
+#
+# Permission to use, copy, modify, and/or distribute this software for any
+# purpose with or without fee is hereby granted, provided that the above
+# copyright notice and this permission notice appear in all copies.
+#
+# THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
+# REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
+# AND FITNESS.  IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
+# INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
+# LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
+# OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
+# PERFORMANCE OF THIS SOFTWARE.
+
+# $Id: Makefile.in,v 1.3.18.3 2007/08/28 07:20:03 tbox Exp $
+
+srcdir =	@srcdir@
+VPATH =		@srcdir@
+top_srcdir =	@top_srcdir@
+
+@BIND9_MAKE_RULES@
+
+PERL = @PERL@
+
+MANOBJS = options
+
+doc man:: ${MANOBJS}
+
+docclean manclean maintainer-clean::
+	rm -f options
+
+# Do not make options depend on ../../bin/tests/cfg_test, doing so
+# will cause excessively clever versions of make to attempt to build
+# that program right here, right now, if it is missing, which will
+# cause make doc to bomb.
+
+CFG_TEST = ../../bin/tests/cfg_test
+
+options: FORCE
+	if test -x ${CFG_TEST} && \
+	   ${CFG_TEST} --named --grammar | \
+	   ${PERL} ${srcdir}/format-options.pl >$@.new ; then \
+		mv -f $@.new $@ ; \
+	else \
+		rm -f $@.new ; \
+	fi
diff --git a/doc/misc/dnssec b/doc/misc/dnssec
new file mode 100644
index 0000000..4451e6c
--- /dev/null
+++ b/doc/misc/dnssec
@@ -0,0 +1,84 @@
+Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+Copyright (C) 2000-2002  Internet Software Consortium.
+See COPYRIGHT in the source root or http://isc.org/copyright.html for terms.
+
+DNSSEC Release Notes
+
+This document summarizes the state of the DNSSEC implementation in
+this release of BIND9.
+
+
+OpenSSL Library Required
+
+To support DNSSEC, BIND 9 must be linked with version 0.9.6e or newer of
+the OpenSSL library.  As of BIND 9.2, the library is no longer
+included in the distribution - it must be provided by the operating
+system or installed separately.
+
+To build BIND 9 with OpenSSL, use "configure --with-openssl".  If
+the OpenSSL library is installed in a nonstandard location, you can
+specify a path as in "configure --with-openssl=/var".
+
+
+Key Generation and Signing
+
+The tools for generating DNSSEC keys and signatures are now in the
+bin/dnssec directory.  Documentation for these programs can be found
+in doc/arm/Bv9ARM.4.html and the man pages.
+
+The random data used in generating DNSSEC keys and signatures comes
+from either /dev/random (if the OS supports it) or keyboard input.
+Alternatively, a device or file containing entropy/random data can be
+specified.
+
+
+Serving Secure Zones
+
+When acting as an authoritative name server, BIND9 includes KEY, SIG
+and NXT records in responses as specified in RFC2535 when the request
+has the DO flag set in the query.
+
+
+Secure Resolution
+
+Basic support for validation of DNSSEC signatures in responses has
+been implemented but should still be considered experimental.
+
+When acting as a caching name server, BIND9 is capable of performing
+basic DNSSEC validation of positive as well as nonexistence responses.
+This functionality is enabled by including a "trusted-keys" clause
+in the configuration file, containing the top-level zone key of the
+the DNSSEC tree.
+
+Validation of wildcard responses is not currently supported.  In
+particular, a "name does not exist" response will validate
+successfully even if it does not contain the NXT records to prove the
+nonexistence of a matching wildcard.
+
+Proof of insecure status for insecure zones delegated from secure
+zones works when the zones are completely insecure.  Privately
+secured zones delegated from secure zones will not work in all cases,
+such as when the privately secured zone is served by the same server
+as an ancestor (but not parent) zone.
+
+Handling of the CD bit in queries is now fully implemented.  Validation
+is not attempted for recursive queries if CD is set.
+
+
+Secure Dynamic Update
+
+Dynamic update of secure zones has been implemented, but may not be
+complete.  Affected NXT and SIG records are updated by the server when
+an update occurs.  Advanced access control is possible using the
+"update-policy" statement in the zone definition.
+
+
+Secure Zone Transfers
+
+BIND 9 does not implement the zone transfer security mechanisms of
+RFC2535 section 5.6, and we have no plans to implement them in the
+future as we consider them inferior to the use of TSIG or SIG(0) to
+ensure the integrity of zone transfers.
+
+
+$Id: dnssec,v 1.19 2004/03/05 05:04:53 marka Exp $
diff --git a/doc/misc/format-options.pl b/doc/misc/format-options.pl
new file mode 100644
index 0000000..70b334e
--- /dev/null
+++ b/doc/misc/format-options.pl
@@ -0,0 +1,36 @@
+#!/usr/bin/perl
+#
+# Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+# Copyright (C) 2001  Internet Software Consortium.
+#
+# Permission to use, copy, modify, and distribute this software for any
+# purpose with or without fee is hereby granted, provided that the above
+# copyright notice and this permission notice appear in all copies.
+#
+# THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
+# REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
+# AND FITNESS.  IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
+# INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
+# LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
+# OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
+# PERFORMANCE OF THIS SOFTWARE.
+
+# $Id: format-options.pl,v 1.2 2004/03/05 05:04:53 marka Exp $
+
+print <<END;
+
+This is a summary of the named.conf options supported by 
+this version of BIND 9.
+
+END
+
+# Break long lines
+while (<>) {
+	s/\t/        /g;
+	if (length >= 79) {
+		m!^( *)!;
+		my $indent = $1;
+		s!^(.{0,75}) (.*)$!\1\n$indent    \2!;
+	}
+	print;
+}
diff --git a/doc/misc/ipv6 b/doc/misc/ipv6
new file mode 100644
index 0000000..aeba275
--- /dev/null
+++ b/doc/misc/ipv6
@@ -0,0 +1,113 @@
+Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+Copyright (C) 2000, 2001  Internet Software Consortium.
+See COPYRIGHT in the source root or http://isc.org/copyright.html for terms.
+
+Currently, there are multiple interesting problems with ipv6
+implementations on various platforms.  These problems range from not
+being able to use ipv6 with bind9 (or in particular the ISC socket
+library, contained in libisc) to listen-on lists not being respected,
+to strange warnings but seemingly correct behavior of named.
+
+COMPILE-TIME ISSUES
+-------------------
+
+The socket library requires a certain level of support from the
+operating system.  In particular, it must follow the advanced ipv6
+socket API to be usable.  The systems which do not follow this will
+currently not get any warnings or errors, but ipv6 will simply not
+function on them.
+
+These systems currently include, but are not limited to:
+
+	AIX 3.4 (with ipv6 patches)
+
+
+RUN-TIME ISSUES
+---------------
+
+In the original drafts of the ipv6 RFC documents, binding an ipv6
+socket to the ipv6 wildcard address would also cause the socket to
+accept ipv4 connections and datagrams.  When an ipv4 packet is
+received on these systems, it is mapped into an ipv6 address.  For
+example, 1.2.3.4 would be mapped into ::ffff:1.2.3.4.  The intent of
+this mapping was to make transition from an ipv4-only application into
+ipv6 easier, by only requiring one socket to be open on a given port.
+
+Later, it was discovered that this was generally a bad idea.  For one,
+many firewalls will block connection to 1.2.3.4, but will let through
+::ffff:1.2.3.4.  This, of course, is bad.  Also, access control lists
+written to accept only ipv4 addresses were suddenly ignored unless
+they were rewritten to handle the ipv6 mapped addresses as well.
+
+Partly because of these problems, the latest IPv6 API introduces an
+explicit knob (the "IPV6_V6ONLY" socket option ) to turn off the ipv6
+mapped address usage.
+
+In bind9, we first check if both the advanced API and the IPV6_V6ONLY
+socket option are available.  If both of them are available, bind9
+named will bind to the ipv6 wildcard port for both TCP and UDP.
+Otherwise named will make a warning and try to bind to all available
+ipv6 addresses separately.
+
+In any case, bind9 named binds to specific addresses for ipv4 sockets.
+
+The followings are historical notes when we always bound to the ipv6
+wildcard port regardless of the availability of the API support.
+These problems should not happen with the closer checks above.
+
+
+IPV6 Sockets Accept IPV4, Specific IPV4 Addresses Bindings Fail
+---------------------------------------------------------------
+
+The only OS which seems to do this is (some kernel versions of) linux.
+If an ipv6 socket is bound to the ipv6 wildcard socket, and a specific
+ipv4 socket is later bound (say, to 1.2.3.4 port 53) the ipv4 binding
+will fail.
+
+What this means to bind9 is that the application will log warnings
+about being unable to bind to a socket because the address is already
+in use.  Since the ipv6 socket will accept ipv4 packets and map them,
+however, the ipv4 addresses continue to function.
+
+The effect is that the config file listen-on directive will not be
+respected on these systems.
+
+
+IPV6 Sockets Accept IPV4, Specific IPV4 Address Bindings Succeed
+----------------------------------------------------------------
+
+In this case, the system allows opening an ipv6 wildcard address
+socket and then binding to a more specific ipv4 address later.  An
+example of this type of system is Digital Unix with ipv6 patches
+applied.
+
+What this means to bind9 is that the application will respect
+listen-on in regards to ipv4 sockets, but it will use mapped ipv6
+addresses for any that do not match the listen-on list.  This, in
+effect, makes listen-on useless for these machines as well.
+
+
+IPV6 Sockets Do Not Accept IPV4
+-------------------------------
+
+On these systems, opening an IPV6 socket does not implicitly open any
+ipv4 sockets.  An example of these systems are NetBSD-current with the
+latest KAME patch, and other systems which use the latest KAME patches
+as their ipv6 implementation.
+
+On these systems, listen-on is fully functional, as the ipv6 socket
+only accepts ipv6 packets, and the ipv4 sockets will handle the ipv4
+packets.
+
+
+RELEVANT RFCs
+-------------
+
+3513:  Internet Protocol Version 6 (IPv6) Addressing Architecture
+
+3493:  Basic Socket Interface Extensions for IPv6
+
+3542:  Advanced Sockets Application Program Interface (API) for IPv6
+
+
+$Id: ipv6,v 1.6.18.3 2004/08/10 04:28:41 jinmei Exp $
diff --git a/doc/misc/migration b/doc/misc/migration
new file mode 100644
index 0000000..b48371b
--- /dev/null
+++ b/doc/misc/migration
@@ -0,0 +1,257 @@
+Copyright (C) 2004, 2007  Internet Systems Consortium, Inc. ("ISC")
+Copyright (C) 2000, 2001, 2003  Internet Software Consortium.
+See COPYRIGHT in the source root or http://isc.org/copyright.html for terms.
+
+                   BIND 8 to BIND 9 Migration Notes
+
+BIND 9 is designed to be mostly upwards compatible with BIND 8, but
+there is still a number of caveats you should be aware of when
+upgrading an existing BIND 8 installation to use BIND 9.
+
+
+1. Configuration File Compatibility
+
+1.1. Unimplemented Options and Changed Defaults
+
+BIND 9 supports most, but not all of the named.conf options of BIND 8.
+For a complete list of implemented options, see doc/misc/options.
+
+If your named.conf file uses an unimplemented option, named will log a
+warning message.  A message is also logged about each option whose
+default has changed unless the option is set explicitly in named.conf.
+
+The default of the "transfer-format" option has changed from
+"one-answer" to "many-answers".  If you have slave servers that do not
+understand the many-answers zone transfer format (e.g., BIND 4.9.5 or
+older) you need to explicitly specify "transfer-format one-answer;" in
+either the options block or a server statement.
+
+1.2. Handling of Configuration File Errors
+
+In BIND 9, named refuses to start if it detects an error in
+named.conf.  Earlier versions would start despite errors, causing the
+server to run with a partial configuration.  Errors detected during
+subsequent reloads do not cause the server to exit.
+
+Errors in master files do not cause the server to exit, but they
+do cause the zone not to load.
+
+1.3. Logging
+
+The set of logging categories in BIND 9 is different from that
+in BIND 8.  If you have customised your logging on a per-category
+basis, you need to modify your logging statement to use the
+new categories.
+
+Another difference is that the "logging" statement only takes effect
+after the entire named.conf file has been read.  This means that when
+the server starts up, any messages about errors in the configuration
+file are always logged to the default destination (syslog) when the
+server first starts up, regardless of the contents of the "logging"
+statement.  In BIND 8, the new logging configuration took effect
+immediately after the "logging" statement was read.
+
+1.4. Notify messages and Refresh queries
+
+The source address and port for these is now controlled by
+"notify-source" and "transfer-source", respectively, rather that
+query-source as in BIND 8.
+
+1.5. Multiple Classes.
+
+Multiple classes have to be put into explicit views for each class.
+
+
+2. Zone File Compatibility
+
+2.1. Strict RFC1035 Interpretation of TTLs in Zone Files
+
+BIND 9 strictly complies with the RFC1035 and RFC2308 rules regarding
+omitted TTLs in zone files.  Omitted TTLs are replaced by the value
+specified with the $TTL directive, or by the previous explicit TTL if
+there is no $TTL directive.
+
+If there is no $TTL directive and the first RR in the file does not
+have an explicit TTL field, the zone file is illegal according to
+RFC1035 since the TTL of the first RR is undefined.  Unfortunately,
+BIND 4 and many versions of BIND 8 accept such files without warning
+and use the value of the SOA MINTTL field as a default for missing TTL
+values.
+
+BIND 9.0 and 9.1 completely refused to load such files.  BIND 9.2
+emulates the nonstandard BIND 4/8 SOA MINTTL behaviour and loads the
+files anyway (provided the SOA is the first record in the file), but
+will issue the warning message "no TTL specified; using SOA MINTTL
+instead".
+
+To avoid problems, we recommend that you use a $TTL directive in each
+zone file.
+
+2.2. Periods in SOA Serial Numbers Deprecated
+
+Some versions of BIND allow SOA serial numbers with an embedded
+period, like "3.002", and convert them into integers in a rather
+unintuitive way.  This feature is not supported by BIND 9; serial
+numbers must be integers.
+
+2.3. Handling of Unbalanced Quotes
+
+TXT records with unbalanced quotes, like 'host TXT "foo', were not
+treated as errors in some versions of BIND.  If your zone files
+contain such records, you will get potentially confusing error
+messages like "unexpected end of file" because BIND 9 will interpret
+everything up to the next quote character as a literal string.
+
+2.4. Handling of Line Breaks
+
+Some versions of BIND accept RRs containing line breaks that are not
+properly quoted with parentheses, like the following SOA:
+
+	@	IN SOA	ns.example. hostmaster.example.
+			( 1 3600 1800 1814400 3600 )
+
+This is not legal master file syntax and will be treated as an error
+by BIND 9.  The fix is to move the opening parenthesis to the first
+line.
+
+2.5. Unimplemented BIND 8 Extensions
+
+$GENERATE: The "$$" construct for getting a literal $ into a domain
+name is deprecated.  Use \$ instead.
+
+2.6. TXT records are no longer automatically split.
+
+Some versions of BIND accepted strings in TXT RDATA consisting of more
+than 255 characters and silently split them to be able to encode the
+strings in a protocol conformant way. You may now see errors like this
+        dns_rdata_fromtext: local.db:119: ran out of space
+if you have TXT RRs with too longs strings. Make sure to split the
+string in the zone data file at or before a single one reaches 255
+characters.
+
+3. Interoperability Impact of New Protocol Features
+
+3.1. EDNS0
+
+BIND 9 uses EDNS0 (RFC2671) to advertise its receive buffer size.  It
+also sets DO EDNS flag bit in queries to indicate that it wishes to
+receive DNSSEC responses.
+
+Most older servers that do not support EDNS0, including prior versions
+of BIND, will send a FORMERR or NOTIMP response to these queries.
+When this happens, BIND 9 will automatically retry the query without
+EDNS0.
+
+Unfortunately, there exists at least one non-BIND name server
+implementation that silently ignores these queries instead of sending
+an error response.  Resolving names in zones where all or most
+authoritative servers use this server will be very slow or fail
+completely.  We have contacted the manufacturer of the name server in
+case, and they are working on a solution.
+
+When BIND 9 communicates with a server that does support EDNS0, such as
+another BIND 9 server, responses of up to 4096 bytes may be
+transmitted as a single UDP datagram which is subject to fragmentation
+at the IP level.  If a firewall incorrectly drops IP fragments, it can
+cause resolution to slow down dramatically or fail.
+
+3.2. Zone Transfers
+
+Outgoing zone transfers now use the "many-answers" format by default.
+This format is not understood by certain old versions of BIND 4.  
+You can work around this problem using the option "transfer-format
+one-answer;", but since these old versions all have known security
+problems, the correct fix is to upgrade the slave servers.
+
+Zone transfers to Windows 2000 DNS servers sometimes fail due to a
+bug in the Windows 2000 DNS server where DNS messages larger than
+16K are not handled properly.  Obtain the latest service pack for
+Windows 2000 from Microsoft to address this issue.  In the meantime,
+the problem can be worked around by setting "transfer-format one-answer;".
+http://support.microsoft.com/default.aspx?scid=kb;en-us;297936
+
+4. Unrestricted Character Set
+
+		BIND 9.2 only
+
+BIND 9 does not restrict the character set of domain names - it is
+fully 8-bit clean in accordance with RFC2181 section 11.
+
+It is strongly recommended that hostnames published in the DNS follow
+the RFC952 rules, but BIND 9 will not enforce this restriction.
+
+Historically, some applications have suffered from security flaws
+where data originating from the network, such as names returned by
+gethostbyaddr(), are used with insufficient checking and may cause a
+breach of security when containing unexpected characters; see
+<http://www.cert.org/advisories/CA-96.04.corrupt_info_from_servers.html>
+for details.  Some earlier versions of BIND attempt to protect these
+flawed applications from attack by discarding data containing
+characters deemed inappropriate in host names or mail addresses, under
+the control of the "check-names" option in named.conf and/or "options
+no-check-names" in resolv.conf.  BIND 9 provides no such protection;
+if applications with these flaws are still being used, they should
+be upgraded.
+
+	BIND 9.3 onwards implements check-names.
+
+5. Server Administration Tools
+
+5.1 Ndc Replaced by Rndc
+
+The "ndc" program has been replaced by "rndc", which is capable of
+remote operation.  Unlike ndc, rndc requires a configuration file.
+The easiest way to generate a configuration file is to run
+"rndc-confgen -a"; see the man pages for rndc(8), rndc-confgen(8),
+and rndc.conf(5) for details.
+
+5.2. Nsupdate Differences
+
+The BIND 8 implementation of nsupdate had an undocumented feature
+where an update request would be broken down into multiple requests
+based upon the discovered zones that contained the records.  This
+behaviour has not been implemented in BIND 9.  Each update request
+must pertain to a single zone, but it is still possible to do multiple
+updates in a single invocation of nsupdate by terminating each update
+with an empty line or a "send" command.
+
+
+6. No Information Leakage between Zones
+
+BIND 9 stores the authoritative data for each zone in a separate data
+structure, as recommended in RFC1035 and as required by DNSSEC and
+IXFR.  When a BIND 9 server is authoritative for both a child zone and
+its parent, it will have two distinct sets of NS records at the
+delegation point: the authoritative NS records at the child's apex,
+and a set of glue NS records in the parent.
+
+BIND 8 was unable to properly distinguish between these two sets of NS
+records and would "leak" the child's NS records into the parent,
+effectively causing the parent zone to be silently modified: responses
+and zone transfers from the parent contained the child's NS records
+rather than the glue configured into the parent (if any).  In the case
+of children of type "stub", this behaviour was documented as a feature,
+allowing the glue NS records to be omitted from the parent
+configuration.
+
+Sites that were relying on this BIND 8 behaviour need to add any
+omitted glue NS records, and any necessary glue A records, to the
+parent zone.
+
+Although stub zones can no longer be used as a mechanism for injecting
+NS records into their parent zones, they are still useful as a way of
+directing queries for a given domain to a particular set of name
+servers.
+
+
+7. Umask not Modified
+
+The BIND 8 named unconditionally sets the umask to 022.  BIND 9 does
+not; the umask inherited from the parent process remains in effect.
+This may cause files created by named, such as journal files, to be
+created with different file permissions than they did in BIND 8.  If
+necessary, the umask should be set explicitly in the script used to
+start the named process.
+
+
+$Id: migration,v 1.45.18.2 2007/09/07 06:34:21 marka Exp $
diff --git a/doc/misc/migration-4to9 b/doc/misc/migration-4to9
new file mode 100644
index 0000000..008cbed
--- /dev/null
+++ b/doc/misc/migration-4to9
@@ -0,0 +1,57 @@
+Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+Copyright (C) 2001  Internet Software Consortium.
+See COPYRIGHT in the source root or http://isc.org/copyright.html for terms.
+
+$Id: migration-4to9,v 1.4 2004/03/05 05:04:53 marka Exp $
+
+		   BIND 4 to BIND 9 Migration Notes
+
+To transition from BIND 4 to BIND 9 you first need to convert your
+configuration file to the new format.  There is a conversion tool in
+contrib/named-bootconf that allows you to do this.
+
+	named-bootconf.sh < /etc/named.boot > /etc/named.conf
+
+BIND 9 uses a system assigned port for the UDP queries it makes rather
+than port 53 that BIND 4 uses.  This may conflict with some firewalls.
+The following directives in /etc/named.conf allows you to specify
+a port to use.
+
+	query-source address * port 53;
+	transfer-source * port 53;
+	notify-source * port 53;
+
+BIND 9 no longer uses the minimum field to specify the TTL of records
+without a explicit TTL.  Use the $TTL directive to specify a default TTL
+before the first record without a explicit TTL.
+
+	$TTL 3600
+	@	IN	SOA	ns1.example.com. hostmaster.example.com. (
+				2001021100
+				7200
+				1200
+				3600000
+				7200 )
+
+BIND 9 does not support multiple CNAMEs with the same owner name.
+	
+	Illegal:
+	www.example.com. CNAME host1.example.com.
+	www.example.com. CNAME host2.example.com.
+
+BIND 9 does not support "CNAMEs with other data" with the same owner name,
+ignoring the DNSSEC records (SIG, NXT, KEY) that BIND 4 did not support.
+
+	Illegal:
+	www.example.com. CNAME host1.example.com.
+	www.example.com. MX 10 host2.example.com.
+
+BIND 9 is less tolerant of errors in master files, so check your logs and
+fix any errors reported.  The named-checkzone program can also be to check
+master files.
+
+Outgoing zone transfers now use the "many-answers" format by default.
+This format is not understood by certain old versions of BIND 4.  
+You can work around this problem using the option "transfer-format
+one-answer;", but since these old versions all have known security
+problems, the correct fix is to upgrade the slave servers.
diff --git a/doc/misc/options b/doc/misc/options
new file mode 100644
index 0000000..a17c522
--- /dev/null
+++ b/doc/misc/options
@@ -0,0 +1,481 @@
+
+This is a summary of the named.conf options supported by 
+this version of BIND 9.
+
+options {
+        avoid-v4-udp-ports { <port>; ... };
+        avoid-v6-udp-ports { <port>; ... };
+        blackhole { <address_match_element>; ... };
+        coresize <size>;
+        datasize <size>;
+        deallocate-on-exit <boolean>; // obsolete
+        directory <quoted_string>;
+        dump-file <quoted_string>;
+        fake-iquery <boolean>; // obsolete
+        files <size>;
+        has-old-clients <boolean>; // obsolete
+        heartbeat-interval <integer>;
+        host-statistics <boolean>; // not implemented
+        host-statistics-max <integer>; // not implemented
+        hostname ( <quoted_string> | none );
+        interface-interval <integer>;
+        listen-on [ port <integer> ] { <address_match_element>; ... };
+        listen-on-v6 [ port <integer> ] { <address_match_element>; ... };
+        match-mapped-addresses <boolean>;
+        memstatistics-file <quoted_string>;
+        multiple-cnames <boolean>; // obsolete
+        named-xfer <quoted_string>; // obsolete
+        pid-file ( <quoted_string> | none );
+        port <integer>;
+        querylog <boolean>;
+        recursing-file <quoted_string>;
+        random-device <quoted_string>;
+        recursive-clients <integer>;
+        serial-queries <integer>; // obsolete
+        serial-query-rate <integer>;
+        server-id ( <quoted_string> | none |;
+        stacksize <size>;
+        statistics-file <quoted_string>;
+        statistics-interval <integer>; // not yet implemented
+        tcp-clients <integer>;
+        tcp-listen-queue <integer>;
+        tkey-dhkey <quoted_string> <integer>;
+        tkey-gssapi-credential <quoted_string>;
+        tkey-domain <quoted_string>;
+        transfers-per-ns <integer>;
+        transfers-in <integer>;
+        transfers-out <integer>;
+        treat-cr-as-space <boolean>; // obsolete
+        use-id-pool <boolean>; // obsolete
+        use-ixfr <boolean>;
+        version ( <quoted_string> | none );
+        flush-zones-on-shutdown <boolean>;
+        allow-query-cache { <address_match_element>; ... };
+        allow-recursion { <address_match_element>; ... };
+        allow-v6-synthesis { <address_match_element>; ... }; // obsolete
+        sortlist { <address_match_element>; ... };
+        topology { <address_match_element>; ... }; // not implemented
+        auth-nxdomain <boolean>; // default changed
+        minimal-responses <boolean>;
+        recursion <boolean>;
+        rrset-order { [ class <string> ] [ type <string> ] [ name
+            <quoted_string> ] <string> <string>; ... };
+        provide-ixfr <boolean>;
+        request-ixfr <boolean>;
+        fetch-glue <boolean>; // obsolete
+        rfc2308-type1 <boolean>; // not yet implemented
+        additional-from-auth <boolean>;
+        additional-from-cache <boolean>;
+        query-source <querysource4>;
+        query-source-v6 <querysource6>;
+        cleaning-interval <integer>;
+        min-roots <integer>; // not implemented
+        lame-ttl <integer>;
+        max-ncache-ttl <integer>;
+        max-cache-ttl <integer>;
+        transfer-format ( many-answers | one-answer );
+        max-cache-size <size_no_default>;
+        check-names ( master | slave | response ) ( fail | warn | ignore );
+        cache-file <quoted_string>;
+        suppress-initial-notify <boolean>; // not yet implemented
+        preferred-glue <string>;
+        dual-stack-servers [ port <integer> ] { ( <quoted_string> [port
+            <integer>] | <ipv4_address> [port <integer>] | <ipv6_address> [port <integer>] ); ... };
+        edns-udp-size <integer>;
+        max-udp-size <integer>;
+        root-delegation-only [ exclude { <quoted_string>; ... } ];
+        disable-algorithms <string> { <string>; ... };
+        dnssec-enable <boolean>;
+        dnssec-validation <boolean>;
+        dnssec-lookaside <string> trust-anchor <string>;
+        dnssec-must-be-secure <string> <boolean>;
+        dnssec-accept-expired <boolean>;
+        ixfr-from-differences <ixfrdiff>;
+        acache-enable <boolean>;
+        acache-cleaning-interval <integer>;
+        max-acache-size <size_no_default>;
+        clients-per-query <integer>;
+        max-clients-per-query <integer>;
+        empty-server <string>;
+        empty-contact <string>;
+        empty-zones-enable <boolean>;
+        disable-empty-zone <string>;
+        zero-no-soa-ttl-cache <boolean>;
+        allow-query { <address_match_element>; ... };
+        allow-transfer { <address_match_element>; ... };
+        allow-update { <address_match_element>; ... };
+        allow-update-forwarding { <address_match_element>; ... };
+        allow-notify { <address_match_element>; ... };
+        masterfile-format ( text | raw );
+        notify <notifytype>;
+        notify-source ( <ipv4_address> | * ) [ port ( <integer> | * ) ];
+        notify-source-v6 ( <ipv6_address> | * ) [ port ( <integer> | * ) ];
+        also-notify [ port <integer> ] { ( <ipv4_address> | <ipv6_address>
+            ) [ port <integer> ]; ... };
+        notify-delay <integer>;
+        dialup <dialuptype>;
+        forward ( first | only );
+        forwarders [ port <integer> ] { ( <ipv4_address> | <ipv6_address> )
+            [ port <integer> ]; ... };
+        maintain-ixfr-base <boolean>; // obsolete
+        max-ixfr-log-size <size>; // obsolete
+        max-journal-size <size_no_default>;
+        max-transfer-time-in <integer>;
+        max-transfer-time-out <integer>;
+        max-transfer-idle-in <integer>;
+        max-transfer-idle-out <integer>;
+        max-retry-time <integer>;
+        min-retry-time <integer>;
+        max-refresh-time <integer>;
+        min-refresh-time <integer>;
+        multi-master <boolean>;
+        sig-validity-interval <integer>;
+        transfer-source ( <ipv4_address> | * ) [ port ( <integer> | * ) ];
+        transfer-source-v6 ( <ipv6_address> | * ) [ port ( <integer> | * ) ];
+        alt-transfer-source ( <ipv4_address> | * ) [ port ( <integer> | * )
+            ];
+        alt-transfer-source-v6 ( <ipv6_address> | * ) [ port ( <integer> |
+            * ) ];
+        use-alt-transfer-source <boolean>;
+        zone-statistics <boolean>;
+        key-directory <quoted_string>;
+        check-wildcard <boolean>;
+        check-integrity <boolean>;
+        check-mx ( fail | warn | ignore );
+        check-mx-cname ( fail | warn | ignore );
+        check-srv-cname ( fail | warn | ignore );
+        check-sibling <boolean>;
+        zero-no-soa-ttl <boolean>;
+        update-check-ksk <boolean>;
+};
+
+controls {
+        inet ( <ipv4_address> | <ipv6_address> | * ) [ port ( <integer> | *
+            ) ] allow { <address_match_element>; ... } [ keys { <string>; ... } ];
+        unix <quoted_string> perm <integer> owner <integer> group <integer>
+            [ keys { <string>; ... } ];
+};
+
+acl <string> { <address_match_element>; ... };
+
+masters <string> [ port <integer> ] { ( <masters> | <ipv4_address> [port
+    <integer>] | <ipv6_address> [port <integer>] ) [ key <string> ]; ... };
+
+logging {
+        channel <string> {
+                file <log_file>;
+                syslog <optional_facility>;
+                null;
+                stderr;
+                severity <log_severity>;
+                print-time <boolean>;
+                print-severity <boolean>;
+                print-category <boolean>;
+        };
+        category <string> { <string>; ... };
+};
+
+view <string> <optional_class> {
+        match-clients { <address_match_element>; ... };
+        match-destinations { <address_match_element>; ... };
+        match-recursive-only <boolean>;
+        key <string> {
+                algorithm <string>;
+                secret <string>;
+        };
+        zone <string> <optional_class> {
+                type ( master | slave | stub | hint | forward |
+                    delegation-only );
+                file <quoted_string>;
+                journal <quoted_string>;
+                ixfr-base <quoted_string>; // obsolete
+                ixfr-tmp-file <quoted_string>; // obsolete
+                masters [ port <integer> ] { ( <masters> | <ipv4_address>
+                    [port <integer>] | <ipv6_address> [port <integer>] ) [ key <string> ]; ... };
+                pubkey <integer> <integer> <integer> <quoted_string>; //
+                    obsolete
+                update-policy { ( grant | deny ) <string> ( name |
+                    subdomain | wildcard | self | selfsub | selfwild ) <string> <rrtypelist>; ... };
+                database <string>;
+                delegation-only <boolean>;
+                check-names ( fail | warn | ignore );
+                ixfr-from-differences <boolean>;
+                allow-query { <address_match_element>; ... };
+                allow-transfer { <address_match_element>; ... };
+                allow-update { <address_match_element>; ... };
+                allow-update-forwarding { <address_match_element>; ... };
+                allow-notify { <address_match_element>; ... };
+                masterfile-format ( text | raw );
+                notify <notifytype>;
+                notify-source ( <ipv4_address> | * ) [ port ( <integer> | *
+                    ) ];
+                notify-source-v6 ( <ipv6_address> | * ) [ port ( <integer>
+                    | * ) ];
+                also-notify [ port <integer> ] { ( <ipv4_address> |
+                    <ipv6_address> ) [ port <integer> ]; ... };
+                notify-delay <integer>;
+                dialup <dialuptype>;
+                forward ( first | only );
+                forwarders [ port <integer> ] { ( <ipv4_address> |
+                    <ipv6_address> ) [ port <integer> ]; ... };
+                maintain-ixfr-base <boolean>; // obsolete
+                max-ixfr-log-size <size>; // obsolete
+                max-journal-size <size_no_default>;
+                max-transfer-time-in <integer>;
+                max-transfer-time-out <integer>;
+                max-transfer-idle-in <integer>;
+                max-transfer-idle-out <integer>;
+                max-retry-time <integer>;
+                min-retry-time <integer>;
+                max-refresh-time <integer>;
+                min-refresh-time <integer>;
+                multi-master <boolean>;
+                sig-validity-interval <integer>;
+                transfer-source ( <ipv4_address> | * ) [ port ( <integer> |
+                    * ) ];
+                transfer-source-v6 ( <ipv6_address> | * ) [ port (
+                    <integer> | * ) ];
+                alt-transfer-source ( <ipv4_address> | * ) [ port (
+                    <integer> | * ) ];
+                alt-transfer-source-v6 ( <ipv6_address> | * ) [ port (
+                    <integer> | * ) ];
+                use-alt-transfer-source <boolean>;
+                zone-statistics <boolean>;
+                key-directory <quoted_string>;
+                check-wildcard <boolean>;
+                check-integrity <boolean>;
+                check-mx ( fail | warn | ignore );
+                check-mx-cname ( fail | warn | ignore );
+                check-srv-cname ( fail | warn | ignore );
+                check-sibling <boolean>;
+                zero-no-soa-ttl <boolean>;
+                update-check-ksk <boolean>;
+        };
+        dlz <string> {
+                database <string>;
+        };
+        server <netprefix> {
+                bogus <boolean>;
+                provide-ixfr <boolean>;
+                request-ixfr <boolean>;
+                support-ixfr <boolean>; // obsolete
+                transfers <integer>;
+                transfer-format ( many-answers | one-answer );
+                keys <server_key>;
+                edns <boolean>;
+                edns-udp-size <integer>;
+                max-udp-size <integer>;
+                notify-source ( <ipv4_address> | * ) [ port ( <integer> | *
+                    ) ];
+                notify-source-v6 ( <ipv6_address> | * ) [ port ( <integer>
+                    | * ) ];
+                query-source <querysource4>;
+                query-source-v6 <querysource6>;
+                transfer-source ( <ipv4_address> | * ) [ port ( <integer> |
+                    * ) ];
+                transfer-source-v6 ( <ipv6_address> | * ) [ port (
+                    <integer> | * ) ];
+        };
+        trusted-keys { <string> <integer> <integer> <integer>
+            <quoted_string>; ... };
+        allow-query-cache { <address_match_element>; ... };
+        allow-recursion { <address_match_element>; ... };
+        allow-v6-synthesis { <address_match_element>; ... }; // obsolete
+        sortlist { <address_match_element>; ... };
+        topology { <address_match_element>; ... }; // not implemented
+        auth-nxdomain <boolean>; // default changed
+        minimal-responses <boolean>;
+        recursion <boolean>;
+        rrset-order { [ class <string> ] [ type <string> ] [ name
+            <quoted_string> ] <string> <string>; ... };
+        provide-ixfr <boolean>;
+        request-ixfr <boolean>;
+        fetch-glue <boolean>; // obsolete
+        rfc2308-type1 <boolean>; // not yet implemented
+        additional-from-auth <boolean>;
+        additional-from-cache <boolean>;
+        query-source <querysource4>;
+        query-source-v6 <querysource6>;
+        cleaning-interval <integer>;
+        min-roots <integer>; // not implemented
+        lame-ttl <integer>;
+        max-ncache-ttl <integer>;
+        max-cache-ttl <integer>;
+        transfer-format ( many-answers | one-answer );
+        max-cache-size <size_no_default>;
+        check-names ( master | slave | response ) ( fail | warn | ignore );
+        cache-file <quoted_string>;
+        suppress-initial-notify <boolean>; // not yet implemented
+        preferred-glue <string>;
+        dual-stack-servers [ port <integer> ] { ( <quoted_string> [port
+            <integer>] | <ipv4_address> [port <integer>] | <ipv6_address> [port <integer>] ); ... };
+        edns-udp-size <integer>;
+        max-udp-size <integer>;
+        root-delegation-only [ exclude { <quoted_string>; ... } ];
+        disable-algorithms <string> { <string>; ... };
+        dnssec-enable <boolean>;
+        dnssec-validation <boolean>;
+        dnssec-lookaside <string> trust-anchor <string>;
+        dnssec-must-be-secure <string> <boolean>;
+        dnssec-accept-expired <boolean>;
+        ixfr-from-differences <ixfrdiff>;
+        acache-enable <boolean>;
+        acache-cleaning-interval <integer>;
+        max-acache-size <size_no_default>;
+        clients-per-query <integer>;
+        max-clients-per-query <integer>;
+        empty-server <string>;
+        empty-contact <string>;
+        empty-zones-enable <boolean>;
+        disable-empty-zone <string>;
+        zero-no-soa-ttl-cache <boolean>;
+        allow-query { <address_match_element>; ... };
+        allow-transfer { <address_match_element>; ... };
+        allow-update { <address_match_element>; ... };
+        allow-update-forwarding { <address_match_element>; ... };
+        allow-notify { <address_match_element>; ... };
+        masterfile-format ( text | raw );
+        notify <notifytype>;
+        notify-source ( <ipv4_address> | * ) [ port ( <integer> | * ) ];
+        notify-source-v6 ( <ipv6_address> | * ) [ port ( <integer> | * ) ];
+        also-notify [ port <integer> ] { ( <ipv4_address> | <ipv6_address>
+            ) [ port <integer> ]; ... };
+        notify-delay <integer>;
+        dialup <dialuptype>;
+        forward ( first | only );
+        forwarders [ port <integer> ] { ( <ipv4_address> | <ipv6_address> )
+            [ port <integer> ]; ... };
+        maintain-ixfr-base <boolean>; // obsolete
+        max-ixfr-log-size <size>; // obsolete
+        max-journal-size <size_no_default>;
+        max-transfer-time-in <integer>;
+        max-transfer-time-out <integer>;
+        max-transfer-idle-in <integer>;
+        max-transfer-idle-out <integer>;
+        max-retry-time <integer>;
+        min-retry-time <integer>;
+        max-refresh-time <integer>;
+        min-refresh-time <integer>;
+        multi-master <boolean>;
+        sig-validity-interval <integer>;
+        transfer-source ( <ipv4_address> | * ) [ port ( <integer> | * ) ];
+        transfer-source-v6 ( <ipv6_address> | * ) [ port ( <integer> | * ) ];
+        alt-transfer-source ( <ipv4_address> | * ) [ port ( <integer> | * )
+            ];
+        alt-transfer-source-v6 ( <ipv6_address> | * ) [ port ( <integer> |
+            * ) ];
+        use-alt-transfer-source <boolean>;
+        zone-statistics <boolean>;
+        key-directory <quoted_string>;
+        check-wildcard <boolean>;
+        check-integrity <boolean>;
+        check-mx ( fail | warn | ignore );
+        check-mx-cname ( fail | warn | ignore );
+        check-srv-cname ( fail | warn | ignore );
+        check-sibling <boolean>;
+        zero-no-soa-ttl <boolean>;
+        update-check-ksk <boolean>;
+        database <string>;
+};
+
+lwres {
+        listen-on [ port <integer> ] { ( <ipv4_address> | <ipv6_address> )
+            [ port <integer> ]; ... };
+        view <string> <optional_class>;
+        search { <string>; ... };
+        ndots <integer>;
+};
+
+key <string> {
+        algorithm <string>;
+        secret <string>;
+};
+
+zone <string> <optional_class> {
+        type ( master | slave | stub | hint | forward | delegation-only );
+        file <quoted_string>;
+        journal <quoted_string>;
+        ixfr-base <quoted_string>; // obsolete
+        ixfr-tmp-file <quoted_string>; // obsolete
+        masters [ port <integer> ] { ( <masters> | <ipv4_address> [port
+            <integer>] | <ipv6_address> [port <integer>] ) [ key <string> ]; ... };
+        pubkey <integer> <integer> <integer> <quoted_string>; // obsolete
+        update-policy { ( grant | deny ) <string> ( name | subdomain |
+            wildcard | self | selfsub | selfwild ) <string> <rrtypelist>; ... };
+        database <string>;
+        delegation-only <boolean>;
+        check-names ( fail | warn | ignore );
+        ixfr-from-differences <boolean>;
+        allow-query { <address_match_element>; ... };
+        allow-transfer { <address_match_element>; ... };
+        allow-update { <address_match_element>; ... };
+        allow-update-forwarding { <address_match_element>; ... };
+        allow-notify { <address_match_element>; ... };
+        masterfile-format ( text | raw );
+        notify <notifytype>;
+        notify-source ( <ipv4_address> | * ) [ port ( <integer> | * ) ];
+        notify-source-v6 ( <ipv6_address> | * ) [ port ( <integer> | * ) ];
+        also-notify [ port <integer> ] { ( <ipv4_address> | <ipv6_address>
+            ) [ port <integer> ]; ... };
+        notify-delay <integer>;
+        dialup <dialuptype>;
+        forward ( first | only );
+        forwarders [ port <integer> ] { ( <ipv4_address> | <ipv6_address> )
+            [ port <integer> ]; ... };
+        maintain-ixfr-base <boolean>; // obsolete
+        max-ixfr-log-size <size>; // obsolete
+        max-journal-size <size_no_default>;
+        max-transfer-time-in <integer>;
+        max-transfer-time-out <integer>;
+        max-transfer-idle-in <integer>;
+        max-transfer-idle-out <integer>;
+        max-retry-time <integer>;
+        min-retry-time <integer>;
+        max-refresh-time <integer>;
+        min-refresh-time <integer>;
+        multi-master <boolean>;
+        sig-validity-interval <integer>;
+        transfer-source ( <ipv4_address> | * ) [ port ( <integer> | * ) ];
+        transfer-source-v6 ( <ipv6_address> | * ) [ port ( <integer> | * ) ];
+        alt-transfer-source ( <ipv4_address> | * ) [ port ( <integer> | * )
+            ];
+        alt-transfer-source-v6 ( <ipv6_address> | * ) [ port ( <integer> |
+            * ) ];
+        use-alt-transfer-source <boolean>;
+        zone-statistics <boolean>;
+        key-directory <quoted_string>;
+        check-wildcard <boolean>;
+        check-integrity <boolean>;
+        check-mx ( fail | warn | ignore );
+        check-mx-cname ( fail | warn | ignore );
+        check-srv-cname ( fail | warn | ignore );
+        check-sibling <boolean>;
+        zero-no-soa-ttl <boolean>;
+        update-check-ksk <boolean>;
+};
+
+dlz <string> {
+        database <string>;
+};
+
+server <netprefix> {
+        bogus <boolean>;
+        provide-ixfr <boolean>;
+        request-ixfr <boolean>;
+        support-ixfr <boolean>; // obsolete
+        transfers <integer>;
+        transfer-format ( many-answers | one-answer );
+        keys <server_key>;
+        edns <boolean>;
+        edns-udp-size <integer>;
+        max-udp-size <integer>;
+        notify-source ( <ipv4_address> | * ) [ port ( <integer> | * ) ];
+        notify-source-v6 ( <ipv6_address> | * ) [ port ( <integer> | * ) ];
+        query-source <querysource4>;
+        query-source-v6 <querysource6>;
+        transfer-source ( <ipv4_address> | * ) [ port ( <integer> | * ) ];
+        transfer-source-v6 ( <ipv6_address> | * ) [ port ( <integer> | * ) ];
+};
+
+trusted-keys { <string> <integer> <integer> <integer> <quoted_string>; ... };
+
diff --git a/doc/misc/rfc-compliance b/doc/misc/rfc-compliance
new file mode 100644
index 0000000..4c87c66
--- /dev/null
+++ b/doc/misc/rfc-compliance
@@ -0,0 +1,62 @@
+Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+Copyright (C) 2001  Internet Software Consortium.
+See COPYRIGHT in the source root or http://isc.org/copyright.html for terms.
+
+$Id: rfc-compliance,v 1.4 2004/03/05 05:04:53 marka Exp $
+
+BIND 9 is striving for strict compliance with IETF standards.  We
+believe this release of BIND 9 complies with the following RFCs, with
+the caveats and exceptions listed in the numbered notes below.  Note
+that a number of these RFCs do not have the status of Internet
+standards but are proposed or draft standards, experimental RFCs, 
+or Best Current Practice (BCP) documents.
+
+  RFC1034
+  RFC1035 [1] [2]
+  RFC1123
+  RFC1183
+  RFC1535
+  RFC1536
+  RFC1706
+  RFC1712
+  RFC1750
+  RFC1876
+  RFC1982
+  RFC1995
+  RFC1996
+  RFC2136
+  RFC2163
+  RFC2181
+  RFC2230
+  RFC2308
+  RFC2535 [3] [4]
+  RFC2536
+  RFC2537
+  RFC2538
+  RFC2539
+  RFC2671
+  RFC2672
+  RFC2673
+  RFC2782
+  RFC2915
+  RFC2930
+  RFC2931 [5]
+  RFC3007
+
+
+[1] Queries to zones that have failed to load return SERVFAIL rather
+than a non-authoritative response.  This is considered a feature.
+
+[2] CLASS ANY queries are not supported.  This is considered a feature.
+
+[3] Wildcard records are not supported in DNSSEC secure zones.
+
+[4] Servers authoritative for secure zones being resolved by BIND 9
+must support EDNS0 (RFC2671), and must return all relevant SIGs and
+NXTs in responses rather than relying on the resolving server to
+perform separate queries for missing SIGs and NXTs.
+
+[5] When receiving a query signed with a SIG(0), the server will only
+be able to verify the signature if it has the key in its local
+authoritative data; it will not do recursion or validation to
+retrieve unknown keys.
diff --git a/doc/misc/roadmap b/doc/misc/roadmap
new file mode 100644
index 0000000..f63a469
--- /dev/null
+++ b/doc/misc/roadmap
@@ -0,0 +1,47 @@
+Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+Copyright (C) 2000, 2001  Internet Software Consortium.
+See COPYRIGHT in the source root or http://isc.org/copyright.html for terms.
+
+$Id: roadmap,v 1.2 2004/03/05 05:04:54 marka Exp $
+
+Road Map to the BIND 9 Source Tree
+
+bin/named		The name server.  This relies heavily on the
+			libraries in lib/isc and lib/dns.
+    client.c		Handling of incoming client requests
+    query.c		Query processing
+bin/rndc		The remote name daemon control program
+bin/dig			The "dig" program
+bin/dnssec		The DNSSEC signer and other DNSSEC tools
+bin/nsupdate		The "nsupdate" program
+bin/tests		Test suites and miscellaneous test programs
+bin/tests/system	System tests; see bin/tests/system/README
+lib/dns			The DNS library
+    resolver.c		The "full resolver" (performs recursive lookups)
+    validator.c		The DNSSEC validator
+    db.c		The database interface
+    sdb.c		The simple database interface
+    rbtdb.c		The red-black tree database
+lib/dns/rdata		Routines for handling the various RR types
+lib/dns/sec		Cryptographic libraries for DNSSEC
+lib/isc			The ISC library
+    task.c		Task library
+    unix/socket.c	Unix implementation of socket library
+lib/isccfg		Routines for reading and writing ISC-style
+			configuration files like named.conf and rndc.conf
+lib/isccc		The command channel library, used by rndc.
+lib/tests		Support code for the test suites.
+lib/lwres		The lightweight resolver library.
+doc/draft		Current internet-drafts pertaining to the DNS
+doc/rfc			RFCs pertaining to the DNS
+doc/misc		Miscellaneous documentation
+doc/arm			The BIND 9 Administrator Reference Manual
+doc/man			Man pages
+contrib			Contributed and other auxiliary code
+contrib/idn/mdnkit	The multilingual domain name evaluation kit
+contrib/sdb		Sample drivers for the simple database interface
+make			Makefile fragments, used by configure
+
+The library interfaces are mainly documented in the form of comments
+in the header files.  For example, the task subsystem is documented in
+lib/isc/include/isc/task.h
diff --git a/doc/misc/sdb b/doc/misc/sdb
new file mode 100644
index 0000000..552028a
--- /dev/null
+++ b/doc/misc/sdb
@@ -0,0 +1,169 @@
+Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+Copyright (C) 2000, 2001  Internet Software Consortium.
+See COPYRIGHT in the source root or http://isc.org/copyright.html for terms.
+
+Using the BIND 9 Simplified Database Interface
+
+This document describes the care and feeding of the BIND 9 Simplified
+Database Interface, which allows you to extend BIND 9 with new ways
+of obtaining the data that is published as DNS zones.
+
+
+The Original BIND 9 Database Interface
+
+BIND 9 has a well-defined "back-end database interface" that makes it
+possible to replace the component of the name server responsible for
+the storage and retrieval of zone data, called the "database", on a
+per-zone basis.  The default database is an in-memory, red-black-tree
+data structure commonly referred to as "rbtdb", but it is possible to
+write drivers to support any number of alternative database
+technologies such as in-memory hash tables, application specific
+persistent on-disk databases, object databases, or relational
+databases.
+
+The original BIND 9 database interface defined in <dns/db.h> is
+designed to efficiently support the full set of database functionality
+needed by a name server that implements the complete DNS protocols,
+including features such as zone transfers, dynamic update, and DNSSEC.
+Each of these aspects of name server operations places its own set of
+demands on the data store, with the result that the database API is
+quite complex and contains operations that are highly specific to the
+DNS.  For example, data are stored in a binary format, the name space
+is tree structured, and sets of data records are conceptually
+associated with DNSSEC signature sets.  For these reasons, writing a
+driver using this interface is a highly nontrivial undertaking.
+
+
+The Simplified Database Interface
+
+Many BIND users wish to provide access to various data sources through
+the DNS, but are not necessarily interested in completely replacing
+the in-memory "rbt" database or in supporting features like dynamic
+update, DNSSEC, or even zone transfers.
+
+Often, all you want is limited, read-only DNS access to an existing
+system.  For example, you may have an existing relational database
+containing hostname/address mappings and wish to provide forvard and
+reverse DNS lookups based on this information.  Or perhaps you want to
+set up a simple DNS-based load balancing system where the name server
+answers queries about a single DNS name with a dynamically changing
+set of A records.
+
+BIND 9.1 introduced a new, simplified database interface, or "sdb",
+which greatly simplifies the writing of drivers for these kinds of
+applications.
+
+
+The sdb Driver
+
+An sdb driver is an object module, typically written in C, which is
+linked into the name server and registers itself with the sdb
+subsystem.  It provides a set of callback functions, which also serve
+to advertise its capabilities.  When the name server receives DNS
+queries, invokes the callback functions to obtain the data to respond
+with.
+
+Unlike the full database interface, the sdb interface represents all
+domain names and resource records as ASCII text.
+
+
+Writing an sdb Driver
+
+When a driver is registered, it specifies its name, a list of callback
+functions, and flags.
+
+The flags specify whether the driver wants to use relative domain
+names where possible.
+
+The callback functions are as follows.  The only one that must be
+defined is lookup().
+
+  - create(zone, argc, argv, driverdata, dbdata)
+	  Create a database object for "zone".
+
+  - destroy(zone, driverdata, dbdata)
+	  Destroy the database object for "zone".
+
+  - lookup(zone, name, dbdata, lookup)
+	  Return all the records at the domain name "name".
+
+  - authority(zone, dbdata, lookup)
+	  Return the SOA and NS records at the zone apex.
+
+  - allnodes(zone, dbdata, allnodes)
+	  Return all data in the zone, for zone transfers.
+
+For more detail about these functions and their parameters, see
+bind9/lib/dns/include/dns/sdb.h.  For example drivers, see
+bind9/contrib/sdb.
+
+
+Rebuilding the Server
+
+The driver module and header file must be copied to (or linked into)
+the bind9/bin/named and bind9/bin/named/include directories
+respectively, and must be added to the DBDRIVER_OBJS and DBDRIVER_SRCS
+lines in bin/named/Makefile.in (e.g. for the timedb sample sdb driver,
+add timedb.c to DBDRIVER_SRCS and timedb.@O@ to DBDRIVER_OBJS).  If
+the driver needs additional header files or libraries in nonstandard
+places, the DBDRIVER_INCLUDES and DBDRIVER_LIBS lines should also be
+updated.
+
+Calls to dns_sdb_register() and dns_sdb_unregister() (or wrappers,
+e.g. timedb_init() and timedb_clear() for the timedb sample sdb
+driver) must be inserted into the server, in bind9/bin/named/main.c.
+Registration should be in setup(), before the call to
+ns_server_create().  Unregistration should be in cleanup(),
+after the call to ns_server_destroy().  A #include should be added
+corresponding to the driver header file.
+
+You should try doing this with one or more of the sample drivers
+before attempting to write a driver of your own.
+
+
+Configuring the Server
+
+To make a zone use a new database driver, specify a "database" option
+in its "zone" statement in named.conf.  For example, if the driver
+registers itself under the name "acmedb", you might say
+
+   zone "foo.com" {
+	   database "acmedb";
+   };
+
+You can pass arbitrary arguments to the create() function of the
+driver by adding any number of whitespace-separated words after the
+driver name:
+
+   zone "foo.com" {
+	   database "acmedb -mode sql -connect 10.0.0.1";
+   };
+
+
+Hints for Driver Writers
+
+ - If a driver is generating data on the fly, it probably should
+   not implement the allnodes() function, since a zone transfer
+   will not be meaningful.  The allnodes() function is more relevant
+   with data from a database.
+
+ - The authority() function is necessary if and only if the lookup()
+   function will not add SOA and NS records at the zone apex.  If
+   SOA and NS records are provided by the lookup() function,
+   the authority() function should be NULL.
+
+ - When a driver is registered, an opaque object can be provided.  This
+   object is passed into the database create() and destroy() functions.
+
+ - When a database is created, an opaque object can be created that
+   is associated with that database.  This object is passed into the
+   lookup(), authority(), and allnodes() functions, and is
+   destroyed by the destroy() function.
+
+
+Future Directions
+
+A future release may support dynamic loading of sdb drivers.
+
+
+$Id: sdb,v 1.6 2004/03/05 05:04:54 marka Exp $
diff --git a/doc/rfc/index b/doc/rfc/index
new file mode 100644
index 0000000..990d4a9
--- /dev/null
+++ b/doc/rfc/index
@@ -0,0 +1,114 @@
+ 952:	DOD INTERNET HOST TABLE SPECIFICATION
+1032:	DOMAIN ADMINISTRATORS GUIDE
+1033:	DOMAIN ADMINISTRATORS OPERATIONS GUIDE
+1034:	DOMAIN NAMES - CONCEPTS AND FACILITIES
+1035:	DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION
+1101:	DNS Encoding of Network Names and Other Types
+1122:	Requirements for Internet Hosts -- Communication Layers
+1123:	Requirements for Internet Hosts -- Application and Support
+1183:	New DNS RR Definitions (AFSDB, RP, X25, ISDN and RT)
+1348:	DNS NSAP RRs
+1535:	A Security Problem and Proposed Correction
+	   With Widely Deployed DNS Software
+1536:	Common DNS Implementation Errors and Suggested Fixes
+1537:	Common DNS Data File Configuration Errors
+1591:	Domain Name System Structure and Delegation
+1611:	DNS Server MIB Extensions
+1612:	DNS Resolver MIB Extensions
+1706:	DNS NSAP Resource Records
+1712:	DNS Encoding of Geographical Location
+1750:	Randomness Recommendations for Security
+1876:	A Means for Expressing Location Information in the Domain Name System
+1886:	DNS Extensions to support IP version 6
+1982:	Serial Number Arithmetic
+1995:	Incremental Zone Transfer in DNS
+1996:	A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)
+2052:	A DNS RR for specifying the location of services (DNS SRV)
+2104:	HMAC: Keyed-Hashing for Message Authentication
+2119:	Key words for use in RFCs to Indicate Requirement Levels
+2133:	Basic Socket Interface Extensions for IPv6
+2136:	Dynamic Updates in the Domain Name System (DNS UPDATE)
+2137:	Secure Domain Name System Dynamic Update
+2163:	Using the Internet DNS to Distribute MIXER
+	 Conformant Global Address Mapping (MCGAM)
+2168:	Resolution of Uniform Resource Identifiers using the Domain Name System
+2181:	Clarifications to the DNS Specification
+2230:	Key Exchange Delegation Record for the DNS
+2308:	Negative Caching of DNS Queries (DNS NCACHE)
+2317:	Classless IN-ADDR.ARPA delegation
+2373:	IP Version 6 Addressing Architecture
+2374:	An IPv6 Aggregatable Global Unicast Address Format
+2375:	IPv6 Multicast Address Assignments
+2418:	IETF Working Group Guidelines and Procedures
+2535:	Domain Name System Security Extensions
+2536:	DSA KEYs and SIGs in the Domain Name System (DNS)
+2537:	RSA/MD5 KEYs and SIGs in the Domain Name System (DNS)
+2538:	Storing Certificates in the Domain Name System (DNS)
+2539:	Storage of Diffie-Hellman Keys in the Domain Name System (DNS)
+2540:	Detached Domain Name System (DNS) Information
+2541:	DNS Security Operational Considerations
+2553:	Basic Socket Interface Extensions for IPv6
+2671:	Extension Mechanisms for DNS (EDNS0)
+2672:	Non-Terminal DNS Name Redirection
+2673:	Binary Labels in the Domain Name System
+2782:	A DNS RR for specifying the location of services (DNS SRV)
+2825:	A Tangled Web: Issues of I18N, Domain Names, and the
+	 Other Internet protocols
+2826:	IAB Technical Comment on the Unique DNS Root
+2845:	Secret Key Transaction Authentication for DNS (TSIG)
+2874:	DNS Extensions to Support IPv6 Address Aggregation and Renumbering
+2915:	The Naming Authority Pointer (NAPTR) DNS Resource Record
+2929:	Domain Name System (DNS) IANA Considerations
+2930:	Secret Key Establishment for DNS (TKEY RR)
+2931:	DNS Request and Transaction Signatures ( SIG(0)s )
+3007:	Secure Domain Name System (DNS) Dynamic Update
+3008:	Domain Name System Security (DNSSEC) Signing Authority
+3071:	Reflections on the DNS, RFC 1591, and Categories of Domains
+3090:	DNS Security Extension Clarification on Zone Status
+3110:	RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS)
+3123:	A DNS RR Type for Lists of Address Prefixes (APL RR)
+3152:	Delegation of IP6.ARPA
+3197:	Applicability Statement for DNS MIB Extensions
+3225:	Indicating Resolver Support of DNSSEC
+3226:	DNSSEC and IPv6 A6 aware server/resolver message size requirements
+3258:	Distributing Authoritative Name Servers via Shared Unicast Addresses
+3363:	Representing Internet Protocol version 6 (IPv6)
+	 Addresses in the Domain Name System (DNS)
+3364:	Tradeoffs in Domain Name System (DNS) Support
+	 for Internet Protocol version 6 (IPv6)
+3425:	Obsoleting IQUERY
+3445:	Limiting the Scope of the KEY Resource Record (RR)
+3490:	Internationalizing Domain Names In Applications (IDNA)
+3491:	Nameprep: A Stringprep Profile for Internationalized Domain Names (IDN)
+3492:	Punycode:A Bootstring encoding of Unicode for
+	  Internationalized Domain Names in Applications (IDNA)
+3493:	Basic Socket Interface Extensions for IPv6
+3513:	Internet Protocol Version 6 (IPv6) Addressing Architecture
+3596:	DNS Extensions to Support IP Version 6
+3597:	Handling of Unknown DNS Resource Record (RR) Types
+3645:	Generic Security Service Algorithm for
+	  Secret Key Transaction Authentication for DNS (GSS-TSIG)
+3655:	Redefinition of DNS Authenticated Data (AD) bit
+3658:	Delegation Signer (DS) Resource Record (RR)
+3757:	Domain Name System KEY (DNSKEY) Resource Record (RR)
+	  Secure Entry Point (SEP) Flag
+3833:	Threat Analysis of the Domain Name System (DNS)
+3845:	DNS Security (DNSSEC) NextSECure (NSEC) RDATA Format
+3901:	DNS IPv6 Transport Operational Guidelines
+4025:	A Method for Storing IPsec Keying Material in DNS
+4033:	DNS Security Introduction and Requirements
+4034:	Resource Records for the DNS Security Extensions
+4035:	Protocol Modifications for the DNS Security Extensions
+4074:	Common Misbehavior Against DNS Queries for IPv6 Addresses
+4159:	Deprecation of "ip6.int"
+4193:	Unique Local IPv6 Unicast Addresses
+4255:	Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints
+4343:	Domain Name System (DNS) Case Insensitivity Clarification
+4367:	What's in a Name: False Assumptions about DNS Names
+4398:	Storing Certificates in the Domain Name System (DNS)
+4431:	The DNSSEC Lookaside Validation (DLV) DNS Resource Record
+4408:	Sender Policy Framework (SPF) for Authorizing Use of Domains
+	 in E-Mail, Version 1
+4470:	Minimally Covering NSEC Records and DNSSEC On-line Signing
+4634:	US Secure Hash Algorithms (SHA and HMAC-SHA)
+4641:	DNSSEC Operational Practices
diff --git a/doc/rfc/rfc1032.txt b/doc/rfc/rfc1032.txt
new file mode 100644
index 0000000..0e82721
--- /dev/null
+++ b/doc/rfc/rfc1032.txt
@@ -0,0 +1,781 @@
+Network Working Group                                       M. Stahl
+Request for Comments: 1032                         SRI International
+                                                       November 1987
+
+
+                      DOMAIN ADMINISTRATORS GUIDE
+
+
+STATUS OF THIS MEMO
+
+   This memo describes procedures for registering a domain with the
+   Network Information Center (NIC) of Defense Data Network (DDN), and
+   offers guidelines on the establishment and administration of a domain
+   in accordance with the requirements specified in RFC-920.  It is
+   intended for use by domain administrators.  This memo should be used
+   in conjunction with RFC-920, which is an official policy statement of
+   the Internet Activities Board (IAB) and the Defense Advanced Research
+   Projects Agency (DARPA).  Distribution of this memo is unlimited.
+
+BACKGROUND
+
+   Domains are administrative entities that provide decentralized
+   management of host naming and addressing.  The domain-naming system
+   is distributed and hierarchical.
+
+   The NIC is designated by the Defense Communications Agency (DCA) to
+   provide registry services for the domain-naming system on the DDN and
+   DARPA portions of the Internet.
+
+   As registrar of top-level and second-level domains, as well as
+   administrator of the root domain name servers on behalf of DARPA and
+   DDN, the NIC is responsible for maintaining the root server zone
+   files and their binary equivalents.  In addition, the NIC is
+   responsible for administering the top-level domains of "ARPA," "COM,"
+   "EDU," "ORG," "GOV," and "MIL" on behalf of DCA and DARPA until it
+   becomes feasible for other appropriate organizations to assume those
+   responsibilities.
+
+   It is recommended that the guidelines described in this document be
+   used by domain administrators in the establishment and control of
+   second-level domains.
+
+THE DOMAIN ADMINISTRATOR
+
+   The role of the domain administrator (DA) is that of coordinator,
+   manager, and technician.  If his domain is established at the second
+   level or lower in the tree, the DA must register by interacting with
+   the management of the domain directly above his, making certain that
+
+
+
+Stahl                                                           [Page 1]
+
+RFC 1032              DOMAIN ADMINISTRATORS GUIDE          November 1987
+
+
+   his domain satisfies all the requirements of the administration under
+   which his domain would be situated.  To find out who has authority
+   over the name space he wishes to join, the DA can ask the NIC
+   Hostmaster.  Information on contacts for the top-level and second-
+   level domains can also be found on line in the file NETINFO:DOMAIN-
+   CONTACTS.TXT, which is available from the NIC via anonymous FTP.
+
+   The DA should be technically competent; he should understand the
+   concepts and procedures for operating a domain server, as described
+   in RFC-1034, and make sure that the service provided is reliable and
+   uninterrupted.  It is his responsibility or that of his delegate to
+   ensure that the data will be current at all times.  As a manager, the
+   DA must be able to handle complaints about service provided by his
+   domain name server.  He must be aware of the behavior of the hosts in
+   his domain, and take prompt action on reports of problems, such as
+   protocol violations or other serious misbehavior.  The administrator
+   of a domain must be a responsible person who has the authority to
+   either enforce these actions himself or delegate them to someone
+   else.
+
+   Name assignments within a domain are controlled by the DA, who should
+   verify that names are unique within his domain and that they conform
+   to standard naming conventions.  He furnishes access to names and
+   name-related information to users both inside and outside his domain.
+   He should work closely with the personnel he has designated as the
+   "technical and zone" contacts for his domain, for many administrative
+   decisions will be made on the basis of input from these people.
+
+THE DOMAIN TECHNICAL AND ZONE CONTACT
+
+   A zone consists of those contiguous parts of the domain tree for
+   which a domain server has complete information and over which it has
+   authority.  A domain server may be authoritative for more than one
+   zone.  The domain technical/zone contact is the person who tends to
+   the technical aspects of maintaining the domain's name server and
+   resolver software, and database files.  He keeps the name server
+   running, and interacts with technical people in other domains and
+   zones to solve problems that affect his zone.
+
+POLICIES
+
+   Domain or host name choices and the allocation of domain name space
+   are considered to be local matters.  In the event of conflicts, it is
+   the policy of the NIC not to get involved in local disputes or in the
+   local decision-making process.  The NIC will not act as referee in
+   disputes over such matters as who has the "right" to register a
+   particular top-level or second-level domain for an organization.  The
+   NIC considers this a private local matter that must be settled among
+
+
+
+Stahl                                                           [Page 2]
+
+RFC 1032              DOMAIN ADMINISTRATORS GUIDE          November 1987
+
+
+   the parties involved prior to their commencing the registration
+   process with the NIC.  Therefore, it is assumed that the responsible
+   person for a domain will have resolved any local conflicts among the
+   members of his domain before registering that domain with the NIC.
+   The NIC will give guidance, if requested, by answering specific
+   technical questions, but will not provide arbitration in disputes at
+   the local level.  This policy is also in keeping with the distributed
+   hierarchical nature of the domain-naming system in that it helps to
+   distribute the tasks of solving problems and handling questions.
+
+   Naming conventions for hosts should follow the rules specified in
+   RFC-952.  From a technical standpoint, domain names can be very long.
+   Each segment of a domain name may contain up to 64 characters, but
+   the NIC strongly advises DAs to choose names that are 12 characters
+   or fewer, because behind every domain system there is a human being
+   who must keep track of the names, addresses, contacts, and other data
+   in a database.  The longer the name, the more likely the data
+   maintainer is to make a mistake.  Users also will appreciate shorter
+   names.  Most people agree that short names are easier to remember and
+   type; most domain names registered so far are 12 characters or fewer.
+
+   Domain name assignments are made on a first-come-first-served basis.
+   The NIC has chosen not to register individual hosts directly under
+   the top-level domains it administers.  One advantage of the domain
+   naming system is that administration and data maintenance can be
+   delegated down a hierarchical tree.  Registration of hosts at the
+   same level in the tree as a second-level domain would dilute the
+   usefulness of this feature.  In addition, the administrator of a
+   domain is responsible for the actions of hosts within his domain.  We
+   would not want to find ourselves in the awkward position of policing
+   the actions of individual hosts.  Rather, the subdomains registered
+   under these top-level domains retain the responsibility for this
+   function.
+
+   Countries that wish to be registered as top-level domains are
+   required to name themselves after the two-letter country code listed
+   in the international standard ISO-3166.  In some cases, however, the
+   two-letter ISO country code is identical to a state code used by the
+   U.S. Postal Service.  Requests made by countries to use the three-
+   letter form of country code specified in the ISO-3166 standard will
+   be considered in such cases so as to prevent possible conflicts and
+   confusion.
+
+
+
+
+
+
+
+
+
+Stahl                                                           [Page 3]
+
+RFC 1032              DOMAIN ADMINISTRATORS GUIDE          November 1987
+
+
+HOW TO REGISTER
+
+   Obtain a domain questionnaire from the NIC hostmaster, or FTP the
+   file NETINFO:DOMAIN-TEMPLATE.TXT from host SRI-NIC.ARPA.
+
+   Fill out the questionnaire completely.  Return it via electronic mail
+   to HOSTMASTER@SRI-NIC.ARPA.
+
+   The APPENDIX to this memo contains the application form for
+   registering a top-level or second-level domain with the NIC.  It
+   supersedes the version of the questionnaire found in RFC-920.  The
+   application should be submitted by the person administratively
+   responsible for the domain, and must be filled out completely before
+   the NIC will authorize establishment of a top-level or second-level
+   domain.  The DA is responsible for keeping his domain's data current
+   with the NIC or with the registration agent with which his domain is
+   registered.  For example, the CSNET and UUCP managements act as
+   domain filters, processing domain applications for their own
+   organizations.  They pass pertinent information along periodically to
+   the NIC for incorporation into the domain database and root server
+   files.  The online file NETINFO:ALTERNATE-DOMAIN-PROCEDURE.TXT
+   outlines this procedure.  It is highly recommended that the DA review
+   this information periodically and provide any corrections or
+   additions.  Corrections should be submitted via electronic mail.
+
+WHICH DOMAIN NAME?
+
+   The designers of the domain-naming system initiated several general
+   categories of names as top-level domain names, so that each could
+   accommodate a variety of organizations.  The current top-level
+   domains registered with the DDN Network Information Center are ARPA,
+   COM, EDU, GOV, MIL, NET, and ORG, plus a number of top-level country
+   domains.  To join one of these, a DA needs to be aware of the purpose
+   for which it was intended.
+
+      "ARPA" is a temporary domain.  It is by default appended to the
+      names of hosts that have not yet joined a domain.  When the system
+      was begun in 1984, the names of all hosts in the Official DoD
+      Internet Host Table maintained by the NIC were changed by adding
+      of the label ".ARPA" in order to accelerate a transition to the
+      domain-naming system.  Another reason for the blanket name changes
+      was to force hosts to become accustomed to using the new style
+      names and to modify their network software, if necessary.  This
+      was done on a network-wide basis and was directed by DCA in DDN
+      Management Bulletin No. 22.  Hosts that fall into this domain will
+      eventually move to other branches of the domain tree.
+
+
+
+
+
+Stahl                                                           [Page 4]
+
+RFC 1032              DOMAIN ADMINISTRATORS GUIDE          November 1987
+
+
+      "COM" is meant to incorporate subdomains of companies and
+      businesses.
+
+      "EDU" was initiated to accommodate subdomains set up by
+      universities and other educational institutions.
+
+      "GOV" exists to act as parent domain for subdomains set up by
+      government agencies.
+
+      "MIL" was initiated to act as parent to subdomains that are
+      developed by military organizations.
+
+      "NET" was introduced as a parent domain for various network-type
+      organizations.  Organizations that belong within this top-level
+      domain are generic or network-specific, such as network service
+      centers and consortia.  "NET" also encompasses network
+      management-related organizations, such as information centers and
+      operations centers.
+
+      "ORG" exists as a parent to subdomains that do not clearly fall
+      within the other top-level domains.  This may include technical-
+      support groups, professional societies, or similar organizations.
+
+   One of the guidelines in effect in the domain-naming system is that a
+   host should have only one name regardless of what networks it is
+   connected to.  This implies, that, in general, domain names should
+   not include routing information or addresses.  For example, a host
+   that has one network connection to the Internet and another to BITNET
+   should use the same name when talking to either network.  For a
+   description of the syntax of domain names, please refer to Section 3
+   of RFC-1034.
+
+VERIFICATION OF DATA
+
+   The verification process can be accomplished in several ways.  One of
+   these is through the NIC WHOIS server.  If he has access to WHOIS,
+   the DA can type the command "whois domain <domain name><return>".
+   The reply from WHOIS will supply the following: the name and address
+   of the organization "owning" the domain; the name of the domain; its
+   administrative, technical, and zone contacts; the host names and
+   network addresses of sites providing name service for the domain.
+
+
+
+
+
+
+
+
+
+
+Stahl                                                           [Page 5]
+
+RFC 1032              DOMAIN ADMINISTRATORS GUIDE          November 1987
+
+
+         Example:
+
+         @whois domain rice.edu<Return>
+
+            Rice University (RICE-DOM)
+            Advanced Studies and Research
+            Houston, TX 77001
+
+            Domain Name: RICE.EDU
+
+               Administrative Contact:
+               Kennedy, Ken  (KK28)  Kennedy@LLL-CRG.ARPA (713) 527-4834
+               Technical Contact, Zone Contact:
+               Riffle, Vicky R.  (VRR)  rif@RICE.EDU
+               (713) 527-8101 ext 3844
+
+            Domain servers:
+
+            RICE.EDU                     128.42.5.1
+            PENDRAGON.CS.PURDUE.EDU      128.10.2.5
+
+
+   Alternatively, the DA can send an electronic mail message to
+   SERVICE@SRI-NIC.ARPA.  In the subject line of the message header, the
+   DA should type "whois domain <domain name>".  The requested
+   information will be returned via electronic mail.  This method is
+   convenient for sites that do not have access to the NIC WHOIS
+   service.
+
+   The initial application for domain authorization should be submitted
+   via electronic mail, if possible, to HOSTMASTER@SRI-NIC.ARPA.  The
+   questionnaire described in the appendix may be used or a separate
+   application can be FTPed from host SRI-NIC.ARPA.  The information
+   provided by the administrator will be reviewed by hostmaster
+   personnel for completeness.  There will most likely be a few
+   exchanges of correspondence via electronic mail, the preferred method
+   of communication, prior to authorization of the domain.
+
+HOW TO GET MORE INFORMATION
+
+   An informational table of the top-level domains and their root
+   servers is contained in the file NETINFO:DOMAINS.TXT online at SRI-
+   NIC.ARPA. This table can be obtained by FTPing the file.
+   Alternatively, the information can be acquired by opening a TCP or
+   UDP connection to the NIC Host Name Server, port 101 on SRI-NIC.ARPA,
+   and invoking the command "ALL-DOM".
+
+
+
+
+
+Stahl                                                           [Page 6]
+
+RFC 1032              DOMAIN ADMINISTRATORS GUIDE          November 1987
+
+
+   The following online files, all available by FTP from SRI-NIC.ARPA,
+   contain pertinent domain information:
+
+      - NETINFO:DOMAINS.TXT, a table of all top-level domains and the
+        network addresses of the machines providing domain name
+        service for them.  It is updated each time a new top-level
+        domain is approved.
+
+      - NETINFO:DOMAIN-INFO.TXT contains a concise list of all
+        top-level and second-level domain names registered with the
+        NIC and is updated monthly.
+
+      - NETINFO:DOMAIN-CONTACTS.TXT also contains a list of all the
+        top level and second-level domains, but includes the
+        administrative, technical and zone contacts for each as well.
+
+      - NETINFO:DOMAIN-TEMPLATE.TXT contains the questionnaire to be
+        completed before registering a top-level or second-level
+        domain.
+
+   For either general or specific information on the domain system, do
+   one or more of the following:
+
+      1. Send electronic mail to HOSTMASTER@SRI-NIC.ARPA
+
+      2. Call the toll-free NIC hotline at (800) 235-3155
+
+      3. Use FTP to get background RFCs and other files maintained
+         online at the NIC.  Some pertinent RFCs are listed below in
+         the REFERENCES section of this memo.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Stahl                                                           [Page 7]
+
+RFC 1032              DOMAIN ADMINISTRATORS GUIDE          November 1987
+
+
+REFERENCES
+
+   The references listed here provide important background information
+   on the domain-naming system.  Path names of the online files
+   available via anonymous FTP from the SRI-NIC.ARPA host are noted in
+   brackets.
+
+      1. Defense Communications Agency DDN Defense Communications
+         System, DDN Management Bulletin No. 22, Domain Names
+         Transition, March 1984.
+         [ DDN-NEWS:DDN-MGT-BULLETIN-22.TXT ]
+
+      2. Defense Communications Agency DDN Defense Communications
+         System, DDN Management Bulletin No. 32, Phase I of the Domain
+         Name Implementation, January 1987.
+         [ DDN-NEWS:DDN-MGT-BULLETIN-32.TXT ]
+
+      3. Harrenstien, K., M. Stahl, and E. Feinler, "Hostname
+         Server", RFC-953, DDN Network Information Center, SRI
+         International, October 1985.  [ RFC:RFC953.TXT ]
+
+      4. Harrenstien, K., M. Stahl, and E. Feinler, "Official DoD
+         Internet Host Table Specification", RFC-952, DDN Network
+         Information Center, SRI International, October 1985.
+         [ RFC:RFC952.TXT ]
+
+      5. ISO, "Codes for the Representation of Names of Countries",
+         ISO-3166, International Standards Organization, May 1981.
+         [ Not online ]
+
+      6. Lazear, W.D., "MILNET Name Domain Transition", RFC-1031,
+         Mitre Corporation, October 1987.  [ RFC:RFC1031.TXT ]
+
+      7. Lottor, M.K., "Domain Administrators Operations Guide",
+         RFC-1033, DDN Network Information Center, SRI International,
+         July 1987.  [ RFC:RFC1033.TXT ]
+
+      8. Mockapetris, P., "Domain Names - Concepts and Facilities",
+         RFC-1034, USC Information Sciences Institute, October 1987.
+         [ RFC:RFC1034.TXT ]
+
+      9. Mockapetris, P., "Domain Names - Implementation and
+         Specification", RFC-1035, USC Information Sciences Institute,
+         October 1987.  [ RFC:RFC1035.TXT ]
+
+     10. Mockapetris, P., "The Domain Name System", Proceedings of the
+         IFIP 6.5 Working Conference on Computer Message Services,
+         Nottingham, England, May 1984.  Also as ISI/RS-84-133, June
+
+
+
+Stahl                                                           [Page 8]
+
+RFC 1032              DOMAIN ADMINISTRATORS GUIDE          November 1987
+
+
+         1984.  [ Not online ]
+
+     11. Mockapetris, P., J. Postel, and P. Kirton, "Name Server
+         Design for Distributed Systems", Proceedings of the Seventh
+         International Conference on Computer Communication, October
+         30 to November 3 1984, Sidney, Australia.  Also as
+         ISI/RS-84-132, June 1984.  [ Not online ]
+
+     12. Partridge, C., "Mail Routing and the Domain System", RFC-974,
+         CSNET-CIC, BBN Laboratories, January 1986.
+         [ RFC:RFC974.TXT ]
+
+     13. Postel, J., "The Domain Names Plan and Schedule", RFC-881,
+         USC Information Sciences Institute, November 1983.
+         [ RFC:RFC881.TXT ]
+
+     14. Reynolds, J., and Postel, J., "Assigned Numbers", RFC-1010
+         USC Information Sciences Institute, May 1986.
+         [ RFC:RFC1010.TXT ]
+
+     15. Romano, S., and Stahl, M., "Internet Numbers", RFC-1020,
+         SRI, November 1987.
+         [ RFC:RFC1020.TXT ]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Stahl                                                           [Page 9]
+
+RFC 1032              DOMAIN ADMINISTRATORS GUIDE          November 1987
+
+
+APPENDIX
+
+   The following questionnaire may be FTPed from SRI-NIC.ARPA as
+   NETINFO:DOMAIN-TEMPLATE.TXT.
+
+   ---------------------------------------------------------------------
+
+   To establish a domain, the following information must be sent to the
+   NIC Domain Registrar (HOSTMASTER@SRI-NIC.ARPA):
+
+   NOTE: The key people must have electronic mailboxes and NIC
+   "handles," unique NIC database identifiers.  If you have access to
+   "WHOIS", please check to see if you are registered and if so, make
+   sure the information is current.  Include only your handle and any
+   changes (if any) that need to be made in your entry.  If you do not
+   have access to "WHOIS", please provide all the information indicated
+   and a NIC handle will be assigned.
+
+   (1)  The name of the top-level domain to join.
+
+         For example:  COM
+
+   (2) The NIC handle of the administrative head of the organization.
+   Alternately, the person's name, title, mailing address, phone number,
+   organization, and network mailbox.  This is the contact point for
+   administrative and policy questions about the domain.  In the case of
+   a research project, this should be the principal investigator.
+
+         For example:
+
+            Administrator
+
+               Organization  The NetWorthy Corporation
+               Name          Penelope Q. Sassafrass
+               Title         President
+               Mail Address  The NetWorthy Corporation
+                             4676 Andrews Way, Suite 100
+                             Santa Clara, CA 94302-1212
+               Phone Number  (415) 123-4567
+               Net Mailbox   Sassafrass@ECHO.TNC.COM
+               NIC Handle    PQS
+
+   (3)  The NIC handle of the technical contact for the domain.
+   Alternately, the person's name, title, mailing address, phone number,
+   organization, and network mailbox.  This is the contact point for
+   problems concerning the domain or zone, as well as for updating
+   information about the domain or zone.
+
+
+
+
+Stahl                                                          [Page 10]
+
+RFC 1032              DOMAIN ADMINISTRATORS GUIDE          November 1987
+
+
+         For example:
+
+            Technical and Zone Contact
+
+               Organization  The NetWorthy Corporation
+               Name          Ansel A. Aardvark
+               Title         Executive Director
+               Mail Address  The NetWorthy Corporation
+                             4676 Andrews Way, Suite 100
+                             Santa Clara, CA. 94302-1212
+               Phone Number  (415) 123-6789
+               Net Mailbox   Aardvark@ECHO.TNC.COM
+               NIC Handle    AAA2
+
+   (4)  The name of the domain (up to 12 characters).  This is the name
+   that will be used in tables and lists associating the domain with the
+   domain server addresses.  [While, from a technical standpoint, domain
+   names can be quite long (programmers beware), shorter names are
+   easier for people to cope with.]
+
+         For example:  TNC
+
+   (5)  A description of the servers that provide the domain service for
+   translating names to addresses for hosts in this domain, and the date
+   they will be operational.
+
+         A good way to answer this question is to say "Our server is
+         supplied by person or company X and does whatever their standard
+         issue server does."
+
+            For example:  Our server is a copy of the one operated by
+            the NIC; it will be installed and made operational on
+            1 November 1987.
+
+   (6) Domains must provide at least two independent servers for the
+   domain.  Establishing the servers in physically separate locations
+   and on different PSNs is strongly recommended.  A description of the
+   server machine and its backup, including
+
+
+
+
+
+
+
+
+
+
+
+
+
+Stahl                                                          [Page 11]
+
+RFC 1032              DOMAIN ADMINISTRATORS GUIDE          November 1987
+
+
+         (a) Hardware and software (using keywords from the Assigned
+         Numbers RFC).
+
+         (b) Host domain name and network addresses (which host on which
+         network for each connected network).
+
+         (c) Any domain-style nicknames (please limit your domain-style
+         nickname request to one)
+
+         For example:
+
+            - Hardware and software
+
+               VAX-11/750  and  UNIX,    or
+               IBM-PC      and  MS-DOS,  or
+               DEC-1090    and  TOPS-20
+
+            - Host domain names and network addresses
+
+               BAR.FOO.COM 10.9.0.193 on ARPANET
+
+            - Domain-style nickname
+
+               BR.FOO.COM (same as BAR.FOO.COM 10.9.0.13 on ARPANET)
+
+   (7)  Planned mapping of names of any other network hosts, other than
+   the server machines, into the new domain's naming space.
+
+         For example:
+
+            BAR-FOO2.ARPA (10.8.0.193) -> FOO2.BAR.COM
+            BAR-FOO3.ARPA (10.7.0.193) -> FOO3.BAR.COM
+            BAR-FOO4.ARPA (10.6.0.193) -> FOO4.BAR.COM
+
+
+   (8)  An estimate of the number of hosts that will be in the domain.
+
+         (a) Initially
+         (b) Within one year
+         (c) Two years
+         (d) Five years.
+
+         For example:
+
+            (a) Initially  =   50
+            (b) One year   =  100
+            (c) Two years  =  200
+            (d) Five years =  500
+
+
+
+Stahl                                                          [Page 12]
+
+RFC 1032              DOMAIN ADMINISTRATORS GUIDE          November 1987
+
+
+   (9)  The date you expect the fully qualified domain name to become
+   the official host name in HOSTS.TXT.
+
+         Please note: If changing to a fully qualified domain name (e.g.,
+         FOO.BAR.COM) causes a change in the official host name of an
+         ARPANET or MILNET host, DCA approval must be obtained beforehand.
+         Allow 10 working days for your requested changes to be processed.
+
+         ARPANET sites should contact ARPANETMGR@DDN1.ARPA.  MILNET sites
+         should contact HOSTMASTER@SRI-NIC.ARPA, 800-235-3155, for
+         further instructions.
+
+   (10) Please describe your organization briefly.
+
+         For example: The NetWorthy Corporation is a consulting
+         organization of people working with UNIX and the C language in an
+         electronic networking environment.  It sponsors two technical
+         conferences annually and distributes a bimonthly newsletter.
+
+   ---------------------------------------------------------------------
+
+   This example of a completed application corresponds to the examples
+   found in the companion document RFC-1033, "Domain Administrators
+   Operations Guide."
+
+   (1)  The name of the top-level domain to join.
+
+            COM
+
+   (2)  The NIC handle of the administrative contact person.
+
+            NIC Handle    JAKE
+
+   (3)  The NIC handle of the domain's technical and zone
+         contact person.
+
+            NIC Handle    DLE6
+
+   (4)  The name of the domain.
+
+            SRI
+
+   (5)  A description of the servers.
+
+            Our server is the TOPS20 server JEEVES supplied by ISI; it
+            will be installed and made operational on 1 July 1987.
+
+
+
+
+
+Stahl                                                          [Page 13]
+
+RFC 1032              DOMAIN ADMINISTRATORS GUIDE          November 1987
+
+
+   (6)  A description of the server machine and its backup:
+
+            (a) Hardware and software
+
+               DEC-1090T   and  TOPS20
+               DEC-2065    and  TOPS20
+
+            (b) Host domain name and network address
+
+               KL.SRI.COM  10.1.0.2 on ARPANET, 128.18.10.6 on SRINET
+               STRIPE.SRI.COM  10.4.0.2 on ARPANET, 128.18.10.4 on SRINET
+
+            (c) Domain-style nickname
+
+               None
+
+   (7)  Planned mapping of names of any other network hosts, other than
+   the server machines, into the new domain's naming space.
+
+            SRI-Blackjack.ARPA (128.18.2.1) -> Blackjack.SRI.COM
+            SRI-CSL.ARPA (192.12.33.2) -> CSL.SRI.COM
+
+   (8)  An estimate of the number of hosts that will be directly within
+   this domain.
+
+            (a) Initially  =   50
+            (b) One year   =  100
+            (c) Two years  =  200
+            (d) Five years =  500
+
+   (9)  A date when you expect the fully qualified domain name to become
+   the official host name in HOSTS.TXT.
+
+            31 September 1987
+
+   (10)  Brief description of organization.
+
+            SRI International is an independent, nonprofit, scientific
+            research organization.  It performs basic and applied research
+            for government and commercial clients, and contributes to
+            worldwide economic, scientific, industrial, and social progress
+            through research and related services.
+
+
+
+
+
+
+
+
+
+Stahl                                                          [Page 14]
+
diff --git a/doc/rfc/rfc1033.txt b/doc/rfc/rfc1033.txt
new file mode 100644
index 0000000..37029fd
--- /dev/null
+++ b/doc/rfc/rfc1033.txt
@@ -0,0 +1,1229 @@
+Network Working Group                                         M. Lottor
+Request For Comments:  1033                           SRI International
+                                                          November 1987
+
+
+                 DOMAIN ADMINISTRATORS OPERATIONS GUIDE
+
+
+
+STATUS OF THIS MEMO
+
+   This RFC provides guidelines for domain administrators in operating a
+   domain server and maintaining their portion of the hierarchical
+   database.  Familiarity with the domain system is assumed.
+   Distribution of this memo is unlimited.
+
+ACKNOWLEDGMENTS
+
+   This memo is a formatted collection of notes and excerpts from the
+   references listed at the end of this document.  Of particular mention
+   are Paul Mockapetris and Kevin Dunlap.
+
+INTRODUCTION
+
+   A domain server requires a few files to get started.  It will
+   normally have some number of boot/startup files (also known as the
+   "safety belt" files).  One section will contain a list of possible
+   root servers that the server will use to find the up-to-date list of
+   root servers.  Another section will list the zone files to be loaded
+   into the server for your local domain information.  A zone file
+   typically contains all the data for a particular domain.  This guide
+   describes the data formats that can be used in zone files and
+   suggested parameters to use for certain fields.  If you are
+   attempting to do anything advanced or tricky, consult the appropriate
+   domain RFC's for more details.
+
+   Note:  Each implementation of domain software may require different
+   files.  Zone files are standardized but some servers may require
+   other startup files.  See the appropriate documentation that comes
+   with your software.  See the appendix for some specific examples.
+
+ZONES
+
+   A zone defines the contents of a contiguous section of the domain
+   space, usually bounded by administrative boundaries.  There will
+   typically be a separate data file for each zone.  The data contained
+   in a zone file is composed of entries called Resource Records (RRs).
+
+
+
+
+Lottor                                                          [Page 1]
+
+RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
+
+
+   You may only put data in your domain server that you are
+   authoritative for.  You must not add entries for domains other than
+   your own (except for the special case of "glue records").
+
+   A domain server will probably read a file on start-up that lists the
+   zones it should load into its database.  The format of this file is
+   not standardized and is different for most domain server
+   implementations.  For each zone it will normally contain the domain
+   name of the zone and the file name that contains the data to load for
+   the zone.
+
+ROOT SERVERS
+
+   A resolver will need to find the root servers when it first starts.
+   When the resolver boots, it will typically read a list of possible
+   root servers from a file.
+
+   The resolver will cycle through the list trying to contact each one.
+   When it finds a root server, it will ask it for the current list of
+   root servers.  It will then discard the list of root servers it read
+   from the data file and replace it with the current list it received.
+
+   Root servers will not change very often.  You can get the names of
+   current root servers from the NIC.
+
+   FTP the file NETINFO:ROOT-SERVERS.TXT or send a mail request to
+   NIC@SRI-NIC.ARPA.
+
+   As of this date (June 1987) they are:
+
+           SRI-NIC.ARPA       10.0.0.51    26.0.0.73
+           C.ISI.EDU          10.0.0.52
+           BRL-AOS.ARPA       192.5.25.82  192.5.22.82   128.20.1.2
+           A.ISI.EDU          26.3.0.103
+
+RESOURCE RECORDS
+
+   Records in the zone data files are called resource records (RRs).
+   They are specified in RFC-883 and RFC-973.  An RR has a standard
+   format as shown:
+
+           <name>   [<ttl>]   [<class>]   <type>   <data>
+
+   The record is divided into fields which are separated by white space.
+
+      <name>
+
+         The name field defines what domain name applies to the given
+
+
+
+Lottor                                                          [Page 2]
+
+RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
+
+
+         RR.  In some cases the name field can be left blank and it will
+         default to the name field of the previous RR.
+
+      <ttl>
+
+         TTL stands for Time To Live.  It specifies how long a domain
+         resolver should cache the RR before it throws it out and asks a
+         domain server again.  See the section on TTL's.  If you leave
+         the TTL field blank it will default to the minimum time
+         specified in the SOA record (described later).
+
+      <class>
+
+         The class field specifies the protocol group.  If left blank it
+         will default to the last class specified.
+
+      <type>
+
+         The type field specifies what type of data is in the RR.  See
+         the section on types.
+
+      <data>
+
+         The data field is defined differently for each type and class
+         of data.  Popular RR data formats are described later.
+
+   The domain system does not guarantee to preserve the order of
+   resource records.  Listing RRs (such as multiple address records) in
+   a certain order does not guarantee they will be used in that order.
+
+   Case is preserved in names and data fields when loaded into the name
+   server.  All comparisons and lookups in the name server are case
+   insensitive.
+
+   Parenthesis ("(",")") are used to group data that crosses a line
+   boundary.
+
+   A semicolon (";") starts a comment; the remainder of the line is
+   ignored.
+
+   The asterisk ("*") is used for wildcarding.
+
+   The at-sign ("@") denotes the current default domain name.
+
+
+
+
+
+
+
+
+Lottor                                                          [Page 3]
+
+RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
+
+
+NAMES
+
+   A domain name is a sequence of labels separated by dots.
+
+   Domain names in the zone files can be one of two types, either
+   absolute or relative.  An absolute name is the fully qualified domain
+   name and is terminated with a period.  A relative name does not
+   terminate with a period, and the current default domain is appended
+   to it.  The default domain is usually the name of the domain that was
+   specified in the boot file that loads each zone.
+
+   The domain system allows a label to contain any 8-bit character.
+   Although the domain system has no restrictions, other protocols such
+   as SMTP do have name restrictions.  Because of other protocol
+   restrictions, only the following characters are recommended for use
+   in a host name (besides the dot separator):
+
+           "A-Z", "a-z", "0-9", dash and underscore
+
+TTL's  (Time To Live)
+
+   It is important that TTLs are set to appropriate values.  The TTL is
+   the time (in seconds) that a resolver will use the data it got from
+   your server before it asks your server again.  If you set the value
+   too low, your server will get loaded down with lots of repeat
+   requests.  If you set it too high, then information you change will
+   not get distributed in a reasonable amount of time.  If you leave the
+   TTL field blank, it will default to what is specified in the SOA
+   record for the zone.
+
+   Most host information does not change much over long time periods.  A
+   good way to set up your TTLs would be to set them at a high value,
+   and then lower the value if you know a change will be coming soon.
+   You might set most TTLs to anywhere between a day (86400) and a week
+   (604800).  Then, if you know some data will be changing in the near
+   future, set the TTL for that RR down to a lower value (an hour to a
+   day) until the change takes place, and then put it back up to its
+   previous value.
+
+   Also, all RRs with the same name, class, and type should have the
+   same TTL value.
+
+CLASSES
+
+   The domain system was designed to be protocol independent.  The class
+   field is used to identify the protocol group that each RR is in.
+
+   The class of interest to people using TCP/IP software is the class
+
+
+
+Lottor                                                          [Page 4]
+
+RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
+
+
+   "Internet".  Its standard designation is "IN".
+
+   A zone file should only contain RRs of the same class.
+
+TYPES
+
+   There are many defined RR types.  For a complete list, see the domain
+   specification RFCs.  Here is a list of current commonly used types.
+   The data for each type is described in the data section.
+
+                Designation                Description
+              ==========================================
+               SOA                 Start Of Authority
+               NS                  Name Server
+
+               A                   Internet Address
+               CNAME               Canonical Name (nickname pointer)
+               HINFO               Host Information
+               WKS                 Well Known Services
+
+               MX                  Mail Exchanger
+
+               PTR                 Pointer
+
+SOA  (Start Of Authority)
+
+           <name>  [<ttl>]  [<class>]  SOA  <origin>  <person>  (
+                           <serial>
+                           <refresh>
+                           <retry>
+                           <expire>
+                           <minimum> )
+
+   The Start Of Authority record designates the start of a zone.  The
+   zone ends at the next SOA record.
+
+   <name> is the name of the zone.
+
+   <origin> is the name of the host on which the master zone file
+   resides.
+
+   <person> is a mailbox for the person responsible for the zone.  It is
+   formatted like a mailing address but the at-sign that normally
+   separates the user from the host name is replaced with a dot.
+
+   <serial> is the version number of the zone file.  It should be
+   incremented anytime a change is made to data in the zone.
+
+
+
+
+Lottor                                                          [Page 5]
+
+RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
+
+
+   <refresh> is how long, in seconds, a secondary name server is to
+   check with the primary name server to see if an update is needed.  A
+   good value here would be one hour (3600).
+
+   <retry> is how long, in seconds, a secondary name server is to retry
+   after a failure to check for a refresh.  A good value here would be
+   10 minutes (600).
+
+   <expire> is the upper limit, in seconds, that a secondary name server
+   is to use the data before it expires for lack of getting a refresh.
+   You want this to be rather large, and a nice value is 3600000, about
+   42 days.
+
+   <minimum> is the minimum number of seconds to be used for TTL values
+   in RRs.  A minimum of at least a day is a good value here (86400).
+
+   There should only be one SOA record per zone.  A sample SOA record
+   would look something like:
+
+           @   IN   SOA   SRI-NIC.ARPA.   HOSTMASTER.SRI-NIC.ARPA. (
+                           45         ;serial
+                           3600       ;refresh
+                           600        ;retry
+                           3600000    ;expire
+                           86400 )    ;minimum
+
+
+NS  (Name Server)
+
+           <domain>   [<ttl>] [<class>]   NS   <server>
+
+   The NS record lists the name of a machine that provides domain
+   service for a particular domain.  The name associated with the RR is
+   the domain name and the data portion is the name of a host that
+   provides the service.  If machines SRI-NIC.ARPA and C.ISI.EDU provide
+   name lookup service for the domain COM then the following entries
+   would be used:
+
+           COM.    NS      SRI-NIC.ARPA.
+                   NS      C.ISI.EDU.
+
+   Note that the machines providing name service do not have to live in
+   the named domain.  There should be one NS record for each server for
+   a domain.  Also note that the name "COM" defaults for the second NS
+   record.
+
+   NS records for a domain exist in both the zone that delegates the
+   domain, and in the domain itself.
+
+
+
+Lottor                                                          [Page 6]
+
+RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
+
+
+GLUE RECORDS
+
+   If the name server host for a particular domain is itself inside the
+   domain, then a 'glue' record will be needed.  A glue record is an A
+   (address) RR that specifies the address of the server.  Glue records
+   are only needed in the server delegating the domain, not in the
+   domain itself.  If for example the name server for domain SRI.COM was
+   KL.SRI.COM, then the NS record would look like this, but you will
+   also need to have the following A record.
+
+           SRI.COM.	NS	KL.SRI.COM.
+           KL.SRI.COM.  A	10.1.0.2
+
+
+A  (Address)
+
+           <host>   [<ttl>] [<class>]   A   <address>
+
+   The data for an A record is an internet address in dotted decimal
+   form.  A sample A record might look like:
+
+           SRI-NIC.ARPA.           A       10.0.0.51
+
+   There should be one A record for each address of a host.
+
+CNAME ( Canonical Name)
+
+           <nickname>   [<ttl>] [<class>]   CNAME   <host>
+
+   The CNAME record is used for nicknames.  The name associated with the
+   RR is the nickname.  The data portion is the official name.  For
+   example, a machine named SRI-NIC.ARPA may want to have the nickname
+   NIC.ARPA.  In that case, the following RR would be used:
+
+           NIC.ARPA.       CNAME   SRI-NIC.ARPA.
+
+   There must not be any other RRs associated with a nickname of the
+   same class.
+
+   Nicknames are also useful when a host changes it's name.  In that
+   case, it is usually a good idea to have a CNAME pointer so that
+   people still using the old name will get to the right place.
+
+
+
+
+
+
+
+
+
+Lottor                                                          [Page 7]
+
+RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
+
+
+HINFO (Host Info)
+
+           <host>   [<ttl>] [<class>]   HINFO   <hardware>   <software>
+
+   The HINFO record gives information about a particular host.  The data
+   is two strings separated by whitespace.  The first string is a
+   hardware description and the second is software.  The hardware is
+   usually a manufacturer name followed by a dash and model designation.
+   The software string is usually the name of the operating system.
+
+   Official HINFO types can be found in the latest Assigned Numbers RFC,
+   the latest of which is RFC-1010.  The Hardware type is called the
+   Machine name and the Software type is called the System name.
+
+   Some sample HINFO records:
+
+           SRI-NIC.ARPA.           HINFO   DEC-2060 TOPS20
+           UCBARPA.Berkeley.EDU.   HINFO   VAX-11/780 UNIX
+
+
+WKS (Well Known Services)
+
+           <host> [<ttl>] [<class>] WKS <address> <protocol> <services>
+
+   The WKS record is used to list Well Known Services a host provides.
+   WKS's are defined to be services on port numbers below 256.  The WKS
+   record lists what services are available at a certain address using a
+   certain protocol.  The common protocols are TCP or UDP.  A sample WKS
+   record for a host offering the same services on all address would
+   look like:
+
+   Official protocol names can be found in the latest Assigned Numbers
+   RFC, the latest of which is RFC-1010.
+
+           SRI-NIC.ARPA.   WKS  10.0.0.51  TCP  TELNET FTP SMTP
+                           WKS  10.0.0.51  UDP  TIME
+                           WKS  26.0.0.73  TCP  TELNET FTP SMTP
+                           WKS  26.0.0.73  UDP  TIME
+
+MX (Mail Exchanger)  (See RFC-974 for more details.)
+
+           <name>   [<ttl>] [<class>]   MX   <preference>   <host>
+
+   MX records specify where mail for a domain name should be delivered.
+   There may be multiple MX records for a particular name.  The
+   preference value specifies the order a mailer should try multiple MX
+   records when delivering mail.  Zero is the highest preference.
+   Multiple records for the same name may have the same preference.
+
+
+
+Lottor                                                          [Page 8]
+
+RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
+
+
+   A host BAR.FOO.COM may want its mail to be delivered to the host
+   PO.FOO.COM and would then use the MX record:
+
+           BAR.FOO.COM.    MX      10      PO.FOO.COM.
+
+   A host BAZ.FOO.COM may want its mail to be delivered to one of three
+   different machines, in the following order:
+
+           BAZ.FOO.COM.    MX      10      PO1.FOO.COM.
+                           MX      20      PO2.FOO.COM.
+                           MX      30      PO3.FOO.COM.
+
+   An entire domain of hosts not connected to the Internet may want
+   their mail to go through a mail gateway that knows how to deliver
+   mail to them.  If they would like mail addressed to any host in the
+   domain FOO.COM to go through the mail gateway they might use:
+
+           FOO.COM.        MX       10     RELAY.CS.NET.
+           *.FOO.COM.      MX       20     RELAY.CS.NET.
+
+   Note that you can specify a wildcard in the MX record to match on
+   anything in FOO.COM, but that it won't match a plain FOO.COM.
+
+IN-ADDR.ARPA
+
+   The structure of names in the domain system is set up in a
+   hierarchical way such that the address of a name can be found by
+   tracing down the domain tree contacting a server for each label of
+   the name.  Because of this 'indexing' based on name, there is no easy
+   way to translate a host address back into its host name.
+
+   In order to do the reverse translation easily, a domain was created
+   that uses hosts' addresses as part of a name that then points to the
+   data for that host.  In this way, there is now an 'index' to hosts'
+   RRs based on their address.  This address mapping domain is called
+   IN-ADDR.ARPA.  Within that domain are subdomains for each network,
+   based on network number.  Also, for consistency and natural
+   groupings, the 4 octets of a host number are reversed.
+
+   For example, the ARPANET is net 10.  That means there is a domain
+   called 10.IN-ADDR.ARPA.  Within this domain there is a PTR RR at
+   51.0.0.10.IN-ADDR that points to the RRs for the host SRI-NIC.ARPA
+   (who's address is 10.0.0.51).  Since the NIC is also on the MILNET
+   (Net 26, address 26.0.0.73), there is also a PTR RR at 73.0.0.26.IN-
+   ADDR.ARPA that points to the same RR's for SRI-NIC.ARPA.  The format
+   of these special pointers is defined below along with the examples
+   for the NIC.
+
+
+
+
+Lottor                                                          [Page 9]
+
+RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
+
+
+PTR
+
+           <special-name>   [<ttl>] [<class>]   PTR   <name>
+
+   The PTR record is used to let special names point to some other
+   location in the domain tree.  They are mainly used in the IN-
+   ADDR.ARPA records for translation of addresses to names.  PTR's
+   should use official names and not aliases.
+
+   For example, host SRI-NIC.ARPA with addresses 10.0.0.51 and 26.0.0.73
+   would have the following records in the respective zone files for net
+   10 and net 26:
+
+           51.0.0.10.IN-ADDR.ARPA.  PTR   SRI-NIC.ARPA.
+           73.0.0.26.IN-ADDR.ARPA.  PTR   SRI-NIC.ARPA.
+
+GATEWAY PTR's
+
+   The IN-ADDR tree is also used to locate gateways on a particular
+   network.  Gateways have the same kind of PTR RRs as hosts (as above)
+   but in addition they have other PTRs used to locate them by network
+   number alone.  These records have only 1, 2, or 3 octets as part of
+   the name depending on whether they are class A, B, or C networks,
+   respectively.
+
+   Lets take the SRI-CSL gateway for example.  It connects 3 different
+   networks, one class A, one class B and one class C.  It will have the
+   standard RR's for a host in the CSL.SRI.COM zone:
+
+           GW.CSL.SRI.COM.    A    10.2.0.2
+                              A    128.18.1.1
+                              A    192.12.33.2
+
+   Also, in 3 different zones (one for each network), it will have one
+   of the following number to name translation pointers:
+
+           2.0.2.10.IN-ADDR.ARPA.      PTR   GW.CSL.SRI.COM.
+           1.1.18.128.IN-ADDR.ARPA.    PTR   GW.CSL.SRI.COM.
+           1.33.12.192.IN-ADDR.ARPA.   PTR   GW.CSL.SRI.COM.
+
+   In addition, in each of the same 3 zones will be one of the following
+   gateway location pointers:
+
+           10.IN-ADDR.ARPA.            PTR   GW.CSL.SRI.COM.
+           18.128.IN-ADDR.ARPA.        PTR   GW.CSL.SRI.COM.
+           33.12.192.IN-ADDR.ARPA.     PTR   GW.CSL.SRI.COM.
+
+
+
+
+
+Lottor                                                         [Page 10]
+
+RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
+
+
+INSTRUCTIONS
+
+   Adding a subdomain.
+
+      To add a new subdomain to your domain:
+
+         Setup the other domain server and/or the new zone file.
+
+         Add an NS record for each server of the new domain to the zone
+         file of the parent domain.
+
+         Add any necessary glue RRs.
+
+   Adding a host.
+
+      To add a new host to your zone files:
+
+         Edit the appropriate zone file for the domain the host is in.
+
+         Add an entry for each address of the host.
+
+         Optionally add CNAME, HINFO, WKS, and MX records.
+
+         Add the reverse IN-ADDR entry for each host address in the
+         appropriate zone files for each network the host in on.
+
+   Deleting a host.
+
+      To delete a host from the zone files:
+
+         Remove all the hosts' resource records from the zone file of
+         the domain the host is in.
+
+         Remove all the hosts' PTR records from the IN-ADDR zone files
+         for each network the host was on.
+
+   Adding gateways.
+
+         Follow instructions for adding a host.
+
+         Add the gateway location PTR records for each network the
+         gateway is on.
+
+   Deleting gateways.
+
+         Follow instructions for deleting a host.
+
+         Also delete the gateway location PTR records for each network
+
+
+
+Lottor                                                         [Page 11]
+
+RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
+
+
+         the gateway was on.
+
+COMPLAINTS
+
+   These are the suggested steps you should take if you are having
+   problems that you believe are caused by someone else's name server:
+
+
+   1.  Complain privately to the responsible person for the domain.  You
+   can find their mailing address in the SOA record for the domain.
+
+   2.  Complain publicly to the responsible person for the domain.
+
+   3.  Ask the NIC for the administrative person responsible for the
+   domain.  Complain.  You can also find domain contacts on the NIC in
+   the file NETINFO:DOMAIN-CONTACTS.TXT
+
+   4.  Complain to the parent domain authorities.
+
+   5.  Ask the parent authorities to excommunicate the domain.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lottor                                                         [Page 12]
+
+RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
+
+
+EXAMPLE DOMAIN SERVER DATABASE FILES
+
+   The following examples show how zone files are set up for a typical
+   organization.  SRI will be used as the example organization.  SRI has
+   decided to divided their domain SRI.COM into a few subdomains, one
+   for each group that wants one.  The subdomains are CSL and ISTC.
+
+   Note the following interesting items:
+
+      There are both hosts and domains under SRI.COM.
+
+      CSL.SRI.COM is both a domain name and a host name.
+
+      All the domains are serviced by the same pair of domain servers.
+
+      All hosts at SRI are on net 128.18 except hosts in the CSL domain
+      which are on net 192.12.33.  Note that a domain does not have to
+      correspond to a physical network.
+
+      The examples do not necessarily correspond to actual data in use
+      by the SRI domain.
+
+                       SRI Domain Organization
+
+                               +-------+
+                               |  COM  |
+                               +-------+
+                                   |
+                               +-------+
+                               |  SRI  |
+                               +-------+
+                                   |
+                        +----------++-----------+
+                        |           |           |
+                    +-------+    +------+   +-------+
+                    |  CSL  |    | ISTC |   | Hosts |
+                    +-------+    +------+   +-------+
+                        |           |
+                    +-------+    +-------+
+                    | Hosts |    | Hosts |
+                    +-------+    +-------+
+
+
+
+
+
+
+
+
+
+
+Lottor                                                         [Page 13]
+
+RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
+
+
+   [File "CONFIG.CMD".  Since bootstrap files are not standardized, this
+   file is presented using a pseudo configuration file syntax.]
+
+   load root server list             from file ROOT.SERVERS
+   load zone SRI.COM.                from file SRI.ZONE
+   load zone CSL.SRI.COM.            from file CSL.ZONE
+   load zone ISTC.SRI.COM.           from file ISTC.ZONE
+   load zone 18.128.IN-ADDR.ARPA.    from file SRINET.ZONE
+   load zone 33.12.192.IN-ADDR.ARPA. from file SRI-CSL-NET.ZONE
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lottor                                                         [Page 14]
+
+RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
+
+
+   [File "ROOT.SERVERS".  Again, the format of this file is not
+   standardized.]
+
+   ;list of possible root servers
+   SRI-NIC.ARPA       10.0.0.51    26.0.0.73
+   C.ISI.EDU          10.0.0.52
+   BRL-AOS.ARPA       192.5.25.82  192.5.22.82   128.20.1.2
+   A.ISI.EDU          26.3.0.103
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lottor                                                         [Page 15]
+
+RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
+
+
+   [File "SRI.ZONE"]
+
+   SRI.COM.        IN      SOA     KL.SRI.COM. DLE.STRIPE.SRI.COM. (
+                                   870407  ;serial
+                                   1800    ;refresh every 30 minutes
+                                   600     ;retry every 10 minutes
+                                   604800  ;expire after a week
+                                   86400   ;default of an hour
+                                   )
+
+   SRI.COM.        NS      KL.SRI.COM.
+                   NS      STRIPE.SRI.COM.
+                   MX      10      KL.SRI.COM.
+
+   ;SRI.COM hosts
+
+   KL              A       10.1.0.2
+                   A       128.18.10.6
+                   MX      10      KL.SRI.COM.
+
+   STRIPE          A       10.4.0.2
+   STRIPE          A       128.18.10.4
+                   MX      10      STRIPE.SRI.COM.
+
+   NIC             CNAME   SRI-NIC.ARPA.
+
+   Blackjack       A       128.18.2.1
+                   HINFO   VAX-11/780      UNIX
+                   WKS     128.18.2.1      TCP TELNET FTP
+
+   CSL             A       192.12.33.2
+                   HINFO   FOONLY-F4       TOPS20
+                   WKS     192.12.33.2     TCP TELNET FTP SMTP FINGER
+                   MX      10      CSL.SRI.COM.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lottor                                                         [Page 16]
+
+RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
+
+
+   [File "CSL.ZONE"]
+
+   CSL.SRI.COM.    IN      SOA     KL.SRI.COM. DLE.STRIPE.SRI.COM. (
+                                   870330  ;serial
+                                   1800    ;refresh every 30 minutes
+                                   600     ;retry every 10 minutes
+                                   604800  ;expire after a week
+                                   86400   ;default of a day
+                                   )
+
+   CSL.SRI.COM.    NS              KL.SRI.COM.
+                   NS              STRIPE.SRI.COM.
+                   A               192.12.33.2
+
+   ;CSL.SRI.COM hosts
+
+   A               CNAME   CSL.SRI.COM.
+   B               A       192.12.33.3
+                   HINFO   FOONLY-F4       TOPS20
+                   WKS     192.12.33.3     TCP TELNET FTP SMTP
+   GW              A       10.2.0.2
+                   A       192.12.33.1
+                   A       128.18.1.1
+                   HINFO   PDP-11/23       MOS
+   SMELLY          A       192.12.33.4
+                   HINFO   IMAGEN          IMAGEN
+   SQUIRREL        A       192.12.33.5
+                   HINFO   XEROX-1100      INTERLISP
+   VENUS           A       192.12.33.7
+                   HINFO   SYMBOLICS-3600  LISPM
+   HELIUM          A       192.12.33.30
+                   HINFO   SUN-3/160       UNIX
+   ARGON           A       192.12.33.31
+                   HINFO   SUN-3/75        UNIX
+   RADON           A       192.12.33.32
+                   HINFO   SUN-3/75        UNIX
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lottor                                                         [Page 17]
+
+RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
+
+
+   [File "ISTC.ZONE"]
+
+   ISTC.SRI.COM.   IN  SOA     KL.SRI.COM. roemers.JOYCE.ISTC.SRI.COM. (
+                               870406      ;serial
+                               1800        ;refresh every 30 minutes
+                               600         ;retry every 10 minutes
+                               604800      ;expire after a week
+                               86400       ;default of a day
+                               )
+
+   ISTC.SRI.COM.   NS              KL.SRI.COM.
+                   NS              STRIPE.SRI.COM.
+                   MX              10      SPAM.ISTC.SRI.COM.
+
+   ; ISTC hosts
+
+   joyce           A       128.18.4.2
+                   HINFO   VAX-11/750 UNIX
+   bozo            A       128.18.0.6
+                   HINFO   SUN UNIX
+   sundae          A       128.18.0.11
+                   HINFO   SUN UNIX
+   tsca            A       128.18.0.201
+                   A       10.3.0.2
+                   HINFO   VAX-11/750 UNIX
+                   MX      10  TSCA.ISTC.SRI.COM.
+   tsc             CNAME   tsca
+   prmh            A       128.18.0.203
+                   A       10.2.0.51
+                   HINFO   PDP-11/44 UNIX
+   spam            A       128.18.4.3
+                   A       10.2.0.107
+                   HINFO   VAX-11/780 UNIX
+                   MX      10  SPAM.ISTC.SRI.COM.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lottor                                                         [Page 18]
+
+RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
+
+
+   [File "SRINET.ZONE"]
+
+   18.128.IN-ADDR.ARPA.    IN  SOA  KL.SRI.COM  DLE.STRIPE.SRI.COM. (
+                               870406  ;serial
+                               1800    ;refresh every 30 minutes
+                               600     ;retry every 10 minutes
+                               604800  ;expire after a week
+                               86400   ;default of a day
+                               )
+
+   18.128.IN-ADDR.ARPA.    NS      KL.SRI.COM.
+                           NS      STRIPE.SRI.COM.
+                           PTR     GW.CSL.SRI.COM.
+
+   ; SRINET [128.18.0.0] Address Translations
+
+   ; SRI.COM Hosts
+   1.2.18.128.IN-ADDR.ARPA.        PTR     Blackjack.SRI.COM.
+
+   ; ISTC.SRI.COM Hosts
+   2.4.18.128.IN-ADDR.ARPA.        PTR     joyce.ISTC.SRI.COM.
+   6.0.18.128.IN-ADDR.ARPA.        PTR     bozo.ISTC.SRI.COM.
+   11.0.18.128.IN-ADDR.ARPA.       PTR     sundae.ISTC.SRI.COM.
+   201.0.18.128.IN-ADDR.ARPA.      PTR     tsca.ISTC.SRI.COM.
+   203.0.18.128.IN-ADDR.ARPA.      PTR     prmh.ISTC.SRI.COM.
+   3.4.18.128.IN-ADDR.ARPA.        PTR     spam.ISTC.SRI.COM.
+
+   ; CSL.SRI.COM Hosts
+   1.1.18.128.IN-ADDR.ARPA.        PTR     GW.CSL.SRI.COM.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lottor                                                         [Page 19]
+
+RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
+
+
+   [File "SRI-CSL-NET.ZONE"]
+
+   33.12.192.IN-ADDR.ARPA. IN  SOA KL.SRI.COM  DLE.STRIPE.SRI.COM. (
+                               870404  ;serial
+                               1800    ;refresh every 30 minutes
+                               600     ;retry every 10 minutes
+                               604800  ;expire after a week
+                               86400   ;default of a day
+                               )
+
+   33.12.192.IN-ADDR.ARPA. NS      KL.SRI.COM.
+                           NS      STRIPE.SRI.COM.
+                           PTR     GW.CSL.SRI.COM.
+
+   ; SRI-CSL-NET [192.12.33.0] Address Translations
+
+   ; SRI.COM Hosts
+   2.33.12.192.IN-ADDR.ARPA.       PTR     CSL.SRI.COM.
+
+   ; CSL.SRI.COM Hosts
+   1.33.12.192.IN-ADDR.ARPA.       PTR     GW.CSL.SRI.COM.
+   3.33.12.192.IN-ADDR.ARPA.       PTR     B.CSL.SRI.COM.
+   4.33.12.192.IN-ADDR.ARPA.       PTR     SMELLY.CSL.SRI.COM.
+   5.33.12.192.IN-ADDR.ARPA.       PTR     SQUIRREL.CSL.SRI.COM.
+   7.33.12.192.IN-ADDR.ARPA.       PTR     VENUS.CSL.SRI.COM.
+   30.33.12.192.IN-ADDR.ARPA.      PTR     HELIUM.CSL.SRI.COM.
+   31.33.12.192.IN-ADDR.ARPA.      PTR     ARGON.CSL.SRI.COM.
+   32.33.12.192.IN-ADDR.ARPA.      PTR     RADON.CSL.SRI.COM.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lottor                                                         [Page 20]
+
+RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
+
+
+APPENDIX
+
+   BIND (Berkeley Internet Name Domain server) distributed with 4.3 BSD
+   UNIX
+
+   This section describes two BIND implementation specific files; the
+   boot file and the cache file.  BIND has other options, files, and
+   specifications that are not described here.  See the Name Server
+   Operations Guide for BIND for details.
+
+   The boot file for BIND is usually called "named.boot".  This
+   corresponds to file "CONFIG.CMD" in the example section.
+
+           --------------------------------------------------------
+           cache         .                         named.ca
+           primary       SRI.COM                   SRI.ZONE
+           primary       CSL.SRI.COM               CSL.ZONE
+           primary       ISTC.SRI.COM              ISTC.ZONE
+           primary       18.128.IN-ADDR.ARPA       SRINET.ZONE
+           primary       33.12.192.IN-ADDR.ARPA    SRI-CSL-NET.ZONE
+           --------------------------------------------------------
+
+   The cache file for BIND is usually called "named.ca".  This
+   corresponds to file "ROOT.SERVERS" in the example section.
+
+           -------------------------------------------------
+           ;list of possible root servers
+           .       1          IN   NS   SRI-NIC.ARPA.
+                                   NS   C.ISI.EDU.
+                                   NS   BRL-AOS.ARPA.
+                                   NS   C.ISI.EDU.
+           ;and their addresses
+           SRI-NIC.ARPA.           A    10.0.0.51
+                                   A    26.0.0.73
+           C.ISI.EDU.              A    10.0.0.52
+           BRL-AOS.ARPA.           A    192.5.25.82
+                                   A    192.5.22.82
+                                   A    128.20.1.2
+           A.ISI.EDU.              A    26.3.0.103
+           -------------------------------------------------
+
+
+
+
+
+
+
+
+
+
+
+Lottor                                                         [Page 21]
+
+RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
+
+
+REFERENCES
+
+   [1]  Dunlap, K., "Name Server Operations Guide for BIND", CSRG,
+        Department of Electrical Engineering and Computer Sciences,
+        University of California, Berkeley, California.
+
+   [2]  Partridge, C., "Mail Routing and the Domain System", RFC-974,
+        CSNET CIC BBN Laboratories, January 1986.
+
+   [3]  Mockapetris, P., "Domains Names - Concepts and Facilities",
+        RFC-1034, USC/Information Sciences Institute, November 1987.
+
+   [4]  Mockapetris, P., "Domain Names - Implementations Specification",
+        RFC-1035, USC/Information Sciences Institute, November 1987.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lottor                                                         [Page 22]
+
diff --git a/doc/rfc/rfc1034.txt b/doc/rfc/rfc1034.txt
new file mode 100644
index 0000000..55cdb21
--- /dev/null
+++ b/doc/rfc/rfc1034.txt
@@ -0,0 +1,3077 @@
+Network Working Group                                     P. Mockapetris
+Request for Comments: 1034                                           ISI
+Obsoletes: RFCs 882, 883, 973                              November 1987
+
+
+                 DOMAIN NAMES - CONCEPTS AND FACILITIES
+
+
+
+1. STATUS OF THIS MEMO
+
+This RFC is an introduction to the Domain Name System (DNS), and omits
+many details which can be found in a companion RFC, "Domain Names -
+Implementation and Specification" [RFC-1035].  That RFC assumes that the
+reader is familiar with the concepts discussed in this memo.
+
+A subset of DNS functions and data types constitute an official
+protocol.  The official protocol includes standard queries and their
+responses and most of the Internet class data formats (e.g., host
+addresses).
+
+However, the domain system is intentionally extensible.  Researchers are
+continuously proposing, implementing and experimenting with new data
+types, query types, classes, functions, etc.  Thus while the components
+of the official protocol are expected to stay essentially unchanged and
+operate as a production service, experimental behavior should always be
+expected in extensions beyond the official protocol.  Experimental or
+obsolete features are clearly marked in these RFCs, and such information
+should be used with caution.
+
+The reader is especially cautioned not to depend on the values which
+appear in examples to be current or complete, since their purpose is
+primarily pedagogical.  Distribution of this memo is unlimited.
+
+2. INTRODUCTION
+
+This RFC introduces domain style names, their use for Internet mail and
+host address support, and the protocols and servers used to implement
+domain name facilities.
+
+2.1. The history of domain names
+
+The impetus for the development of the domain system was growth in the
+Internet:
+
+   - Host name to address mappings were maintained by the Network
+     Information Center (NIC) in a single file (HOSTS.TXT) which
+     was FTPed by all hosts [RFC-952, RFC-953].  The total network
+
+
+
+Mockapetris                                                     [Page 1]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+     bandwidth consumed in distributing a new version by this
+     scheme is proportional to the square of the number of hosts in
+     the network, and even when multiple levels of FTP are used,
+     the outgoing FTP load on the NIC host is considerable.
+     Explosive growth in the number of hosts didn't bode well for
+     the future.
+
+   - The network population was also changing in character.  The
+     timeshared hosts that made up the original ARPANET were being
+     replaced with local networks of workstations.  Local
+     organizations were administering their own names and
+     addresses, but had to wait for the NIC to change HOSTS.TXT to
+     make changes visible to the Internet at large.  Organizations
+     also wanted some local structure on the name space.
+
+   - The applications on the Internet were getting more
+     sophisticated and creating a need for general purpose name
+     service.
+
+
+The result was several ideas about name spaces and their management
+[IEN-116, RFC-799, RFC-819, RFC-830].  The proposals varied, but a
+common thread was the idea of a hierarchical name space, with the
+hierarchy roughly corresponding to organizational structure, and names
+using "."  as the character to mark the boundary between hierarchy
+levels.  A design using a distributed database and generalized resources
+was described in [RFC-882, RFC-883].  Based on experience with several
+implementations, the system evolved into the scheme described in this
+memo.
+
+The terms "domain" or "domain name" are used in many contexts beyond the
+DNS described here.  Very often, the term domain name is used to refer
+to a name with structure indicated by dots, but no relation to the DNS.
+This is particularly true in mail addressing [Quarterman 86].
+
+2.2. DNS design goals
+
+The design goals of the DNS influence its structure.  They are:
+
+   - The primary goal is a consistent name space which will be used
+     for referring to resources.  In order to avoid the problems
+     caused by ad hoc encodings, names should not be required to
+     contain network identifiers, addresses, routes, or similar
+     information as part of the name.
+
+   - The sheer size of the database and frequency of updates
+     suggest that it must be maintained in a distributed manner,
+     with local caching to improve performance.  Approaches that
+
+
+
+Mockapetris                                                     [Page 2]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+     attempt to collect a consistent copy of the entire database
+     will become more and more expensive and difficult, and hence
+     should be avoided.  The same principle holds for the structure
+     of the name space, and in particular mechanisms for creating
+     and deleting names; these should also be distributed.
+
+   - Where there tradeoffs between the cost of acquiring data, the
+     speed of updates, and the accuracy of caches, the source of
+     the data should control the tradeoff.
+
+   - The costs of implementing such a facility dictate that it be
+     generally useful, and not restricted to a single application.
+     We should be able to use names to retrieve host addresses,
+     mailbox data, and other as yet undetermined information.  All
+     data associated with a name is tagged with a type, and queries
+     can be limited to a single type.
+
+   - Because we want the name space to be useful in dissimilar
+     networks and applications, we provide the ability to use the
+     same name space with different protocol families or
+     management.  For example, host address formats differ between
+     protocols, though all protocols have the notion of address.
+     The DNS tags all data with a class as well as the type, so
+     that we can allow parallel use of different formats for data
+     of type address.
+
+   - We want name server transactions to be independent of the
+     communications system that carries them.  Some systems may
+     wish to use datagrams for queries and responses, and only
+     establish virtual circuits for transactions that need the
+     reliability (e.g., database updates, long transactions); other
+     systems will use virtual circuits exclusively.
+
+   - The system should be useful across a wide spectrum of host
+     capabilities.  Both personal computers and large timeshared
+     hosts should be able to use the system, though perhaps in
+     different ways.
+
+2.3. Assumptions about usage
+
+The organization of the domain system derives from some assumptions
+about the needs and usage patterns of its user community and is designed
+to avoid many of the the complicated problems found in general purpose
+database systems.
+
+The assumptions are:
+
+   - The size of the total database will initially be proportional
+
+
+
+Mockapetris                                                     [Page 3]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+     to the number of hosts using the system, but will eventually
+     grow to be proportional to the number of users on those hosts
+     as mailboxes and other information are added to the domain
+     system.
+
+   - Most of the data in the system will change very slowly (e.g.,
+     mailbox bindings, host addresses), but that the system should
+     be able to deal with subsets that change more rapidly (on the
+     order of seconds or minutes).
+
+   - The administrative boundaries used to distribute
+     responsibility for the database will usually correspond to
+     organizations that have one or more hosts.  Each organization
+     that has responsibility for a particular set of domains will
+     provide redundant name servers, either on the organization's
+     own hosts or other hosts that the organization arranges to
+     use.
+
+   - Clients of the domain system should be able to identify
+     trusted name servers they prefer to use before accepting
+     referrals to name servers outside of this "trusted" set.
+
+   - Access to information is more critical than instantaneous
+     updates or guarantees of consistency.  Hence the update
+     process allows updates to percolate out through the users of
+     the domain system rather than guaranteeing that all copies are
+     simultaneously updated.  When updates are unavailable due to
+     network or host failure, the usual course is to believe old
+     information while continuing efforts to update it.  The
+     general model is that copies are distributed with timeouts for
+     refreshing.  The distributor sets the timeout value and the
+     recipient of the distribution is responsible for performing
+     the refresh.  In special situations, very short intervals can
+     be specified, or the owner can prohibit copies.
+
+   - In any system that has a distributed database, a particular
+     name server may be presented with a query that can only be
+     answered by some other server.  The two general approaches to
+     dealing with this problem are "recursive", in which the first
+     server pursues the query for the client at another server, and
+     "iterative", in which the server refers the client to another
+     server and lets the client pursue the query.  Both approaches
+     have advantages and disadvantages, but the iterative approach
+     is preferred for the datagram style of access.  The domain
+     system requires implementation of the iterative approach, but
+     allows the recursive approach as an option.
+
+
+
+
+
+Mockapetris                                                     [Page 4]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+The domain system assumes that all data originates in master files
+scattered through the hosts that use the domain system.  These master
+files are updated by local system administrators.  Master files are text
+files that are read by a local name server, and hence become available
+through the name servers to users of the domain system.  The user
+programs access name servers through standard programs called resolvers.
+
+The standard format of master files allows them to be exchanged between
+hosts (via FTP, mail, or some other mechanism); this facility is useful
+when an organization wants a domain, but doesn't want to support a name
+server.  The organization can maintain the master files locally using a
+text editor, transfer them to a foreign host which runs a name server,
+and then arrange with the system administrator of the name server to get
+the files loaded.
+
+Each host's name servers and resolvers are configured by a local system
+administrator [RFC-1033].  For a name server, this configuration data
+includes the identity of local master files and instructions on which
+non-local master files are to be loaded from foreign servers.  The name
+server uses the master files or copies to load its zones.  For
+resolvers, the configuration data identifies the name servers which
+should be the primary sources of information.
+
+The domain system defines procedures for accessing the data and for
+referrals to other name servers.  The domain system also defines
+procedures for caching retrieved data and for periodic refreshing of
+data defined by the system administrator.
+
+The system administrators provide:
+
+   - The definition of zone boundaries.
+
+   - Master files of data.
+
+   - Updates to master files.
+
+   - Statements of the refresh policies desired.
+
+The domain system provides:
+
+   - Standard formats for resource data.
+
+   - Standard methods for querying the database.
+
+   - Standard methods for name servers to refresh local data from
+     foreign name servers.
+
+
+
+
+
+Mockapetris                                                     [Page 5]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+2.4. Elements of the DNS
+
+The DNS has three major components:
+
+   - The DOMAIN NAME SPACE and RESOURCE RECORDS, which are
+     specifications for a tree structured name space and data
+     associated with the names.  Conceptually, each node and leaf
+     of the domain name space tree names a set of information, and
+     query operations are attempts to extract specific types of
+     information from a particular set.  A query names the domain
+     name of interest and describes the type of resource
+     information that is desired.  For example, the Internet
+     uses some of its domain names to identify hosts; queries for
+     address resources return Internet host addresses.
+
+   - NAME SERVERS are server programs which hold information about
+     the domain tree's structure and set information.  A name
+     server may cache structure or set information about any part
+     of the domain tree, but in general a particular name server
+     has complete information about a subset of the domain space,
+     and pointers to other name servers that can be used to lead to
+     information from any part of the domain tree.  Name servers
+     know the parts of the domain tree for which they have complete
+     information; a name server is said to be an AUTHORITY for
+     these parts of the name space.  Authoritative information is
+     organized into units called ZONEs, and these zones can be
+     automatically distributed to the name servers which provide
+     redundant service for the data in a zone.
+
+   - RESOLVERS are programs that extract information from name
+     servers in response to client requests.  Resolvers must be
+     able to access at least one name server and use that name
+     server's information to answer a query directly, or pursue the
+     query using referrals to other name servers.  A resolver will
+     typically be a system routine that is directly accessible to
+     user programs; hence no protocol is necessary between the
+     resolver and the user program.
+
+These three components roughly correspond to the three layers or views
+of the domain system:
+
+   - From the user's point of view, the domain system is accessed
+     through a simple procedure or OS call to a local resolver.
+     The domain space consists of a single tree and the user can
+     request information from any section of the tree.
+
+   - From the resolver's point of view, the domain system is
+     composed of an unknown number of name servers.  Each name
+
+
+
+Mockapetris                                                     [Page 6]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+     server has one or more pieces of the whole domain tree's data,
+     but the resolver views each of these databases as essentially
+     static.
+
+   - From a name server's point of view, the domain system consists
+     of separate sets of local information called zones.  The name
+     server has local copies of some of the zones.  The name server
+     must periodically refresh its zones from master copies in
+     local files or foreign name servers.  The name server must
+     concurrently process queries that arrive from resolvers.
+
+In the interests of performance, implementations may couple these
+functions.  For example, a resolver on the same machine as a name server
+might share a database consisting of the the zones managed by the name
+server and the cache managed by the resolver.
+
+3. DOMAIN NAME SPACE and RESOURCE RECORDS
+
+3.1. Name space specifications and terminology
+
+The domain name space is a tree structure.  Each node and leaf on the
+tree corresponds to a resource set (which may be empty).  The domain
+system makes no distinctions between the uses of the interior nodes and
+leaves, and this memo uses the term "node" to refer to both.
+
+Each node has a label, which is zero to 63 octets in length.  Brother
+nodes may not have the same label, although the same label can be used
+for nodes which are not brothers.  One label is reserved, and that is
+the null (i.e., zero length) label used for the root.
+
+The domain name of a node is the list of the labels on the path from the
+node to the root of the tree.  By convention, the labels that compose a
+domain name are printed or read left to right, from the most specific
+(lowest, farthest from the root) to the least specific (highest, closest
+to the root).
+
+Internally, programs that manipulate domain names should represent them
+as sequences of labels, where each label is a length octet followed by
+an octet string.  Because all domain names end at the root, which has a
+null string for a label, these internal representations can use a length
+byte of zero to terminate a domain name.
+
+By convention, domain names can be stored with arbitrary case, but
+domain name comparisons for all present domain functions are done in a
+case-insensitive manner, assuming an ASCII character set, and a high
+order zero bit.  This means that you are free to create a node with
+label "A" or a node with label "a", but not both as brothers; you could
+refer to either using "a" or "A".  When you receive a domain name or
+
+
+
+Mockapetris                                                     [Page 7]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+label, you should preserve its case.  The rationale for this choice is
+that we may someday need to add full binary domain names for new
+services; existing services would not be changed.
+
+When a user needs to type a domain name, the length of each label is
+omitted and the labels are separated by dots (".").  Since a complete
+domain name ends with the root label, this leads to a printed form which
+ends in a dot.  We use this property to distinguish between:
+
+   - a character string which represents a complete domain name
+     (often called "absolute").  For example, "poneria.ISI.EDU."
+
+   - a character string that represents the starting labels of a
+     domain name which is incomplete, and should be completed by
+     local software using knowledge of the local domain (often
+     called "relative").  For example, "poneria" used in the
+     ISI.EDU domain.
+
+Relative names are either taken relative to a well known origin, or to a
+list of domains used as a search list.  Relative names appear mostly at
+the user interface, where their interpretation varies from
+implementation to implementation, and in master files, where they are
+relative to a single origin domain name.  The most common interpretation
+uses the root "." as either the single origin or as one of the members
+of the search list, so a multi-label relative name is often one where
+the trailing dot has been omitted to save typing.
+
+To simplify implementations, the total number of octets that represent a
+domain name (i.e., the sum of all label octets and label lengths) is
+limited to 255.
+
+A domain is identified by a domain name, and consists of that part of
+the domain name space that is at or below the domain name which
+specifies the domain.  A domain is a subdomain of another domain if it
+is contained within that domain.  This relationship can be tested by
+seeing if the subdomain's name ends with the containing domain's name.
+For example, A.B.C.D is a subdomain of B.C.D, C.D, D, and " ".
+
+3.2. Administrative guidelines on use
+
+As a matter of policy, the DNS technical specifications do not mandate a
+particular tree structure or rules for selecting labels; its goal is to
+be as general as possible, so that it can be used to build arbitrary
+applications.  In particular, the system was designed so that the name
+space did not have to be organized along the lines of network
+boundaries, name servers, etc.  The rationale for this is not that the
+name space should have no implied semantics, but rather that the choice
+of implied semantics should be left open to be used for the problem at
+
+
+
+Mockapetris                                                     [Page 8]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+hand, and that different parts of the tree can have different implied
+semantics.  For example, the IN-ADDR.ARPA domain is organized and
+distributed by network and host address because its role is to translate
+from network or host numbers to names; NetBIOS domains [RFC-1001, RFC-
+1002] are flat because that is appropriate for that application.
+
+However, there are some guidelines that apply to the "normal" parts of
+the name space used for hosts, mailboxes, etc., that will make the name
+space more uniform, provide for growth, and minimize problems as
+software is converted from the older host table.  The political
+decisions about the top levels of the tree originated in RFC-920.
+Current policy for the top levels is discussed in [RFC-1032].  MILNET
+conversion issues are covered in [RFC-1031].
+
+Lower domains which will eventually be broken into multiple zones should
+provide branching at the top of the domain so that the eventual
+decomposition can be done without renaming.  Node labels which use
+special characters, leading digits, etc., are likely to break older
+software which depends on more restrictive choices.
+
+3.3. Technical guidelines on use
+
+Before the DNS can be used to hold naming information for some kind of
+object, two needs must be met:
+
+   - A convention for mapping between object names and domain
+     names.  This describes how information about an object is
+     accessed.
+
+   - RR types and data formats for describing the object.
+
+These rules can be quite simple or fairly complex.  Very often, the
+designer must take into account existing formats and plan for upward
+compatibility for existing usage.  Multiple mappings or levels of
+mapping may be required.
+
+For hosts, the mapping depends on the existing syntax for host names
+which is a subset of the usual text representation for domain names,
+together with RR formats for describing host addresses, etc.  Because we
+need a reliable inverse mapping from address to host name, a special
+mapping for addresses into the IN-ADDR.ARPA domain is also defined.
+
+For mailboxes, the mapping is slightly more complex.  The usual mail
+address <local-part>@<mail-domain> is mapped into a domain name by
+converting <local-part> into a single label (regardles of dots it
+contains), converting <mail-domain> into a domain name using the usual
+text format for domain names (dots denote label breaks), and
+concatenating the two to form a single domain name.  Thus the mailbox
+
+
+
+Mockapetris                                                     [Page 9]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+HOSTMASTER@SRI-NIC.ARPA is represented as a domain name by
+HOSTMASTER.SRI-NIC.ARPA.  An appreciation for the reasons behind this
+design also must take into account the scheme for mail exchanges [RFC-
+974].
+
+The typical user is not concerned with defining these rules, but should
+understand that they usually are the result of numerous compromises
+between desires for upward compatibility with old usage, interactions
+between different object definitions, and the inevitable urge to add new
+features when defining the rules.  The way the DNS is used to support
+some object is often more crucial than the restrictions inherent in the
+DNS.
+
+3.4. Example name space
+
+The following figure shows a part of the current domain name space, and
+is used in many examples in this RFC.  Note that the tree is a very
+small subset of the actual name space.
+
+                                   |
+                                   |
+             +---------------------+------------------+
+             |                     |                  |
+            MIL                   EDU                ARPA
+             |                     |                  |
+             |                     |                  |
+       +-----+-----+               |     +------+-----+-----+
+       |     |     |               |     |      |           |
+      BRL  NOSC  DARPA             |  IN-ADDR  SRI-NIC     ACC
+                                   |
+       +--------+------------------+---------------+--------+
+       |        |                  |               |        |
+      UCI      MIT                 |              UDEL     YALE
+                |                 ISI
+                |                  |
+            +---+---+              |
+            |       |              |
+           LCS  ACHILLES  +--+-----+-----+--------+
+            |             |  |     |     |        |
+            XX            A  C   VAXA  VENERA Mockapetris
+
+In this example, the root domain has three immediate subdomains: MIL,
+EDU, and ARPA.  The LCS.MIT.EDU domain has one immediate subdomain named
+XX.LCS.MIT.EDU.  All of the leaves are also domains.
+
+3.5. Preferred name syntax
+
+The DNS specifications attempt to be as general as possible in the rules
+
+
+
+Mockapetris                                                    [Page 10]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+for constructing domain names.  The idea is that the name of any
+existing object can be expressed as a domain name with minimal changes.
+However, when assigning a domain name for an object, the prudent user
+will select a name which satisfies both the rules of the domain system
+and any existing rules for the object, whether these rules are published
+or implied by existing programs.
+
+For example, when naming a mail domain, the user should satisfy both the
+rules of this memo and those in RFC-822.  When creating a new host name,
+the old rules for HOSTS.TXT should be followed.  This avoids problems
+when old software is converted to use domain names.
+
+The following syntax will result in fewer problems with many
+applications that use domain names (e.g., mail, TELNET).
+
+<domain> ::= <subdomain> | " "
+
+<subdomain> ::= <label> | <subdomain> "." <label>
+
+<label> ::= <letter> [ [ <ldh-str> ] <let-dig> ]
+
+<ldh-str> ::= <let-dig-hyp> | <let-dig-hyp> <ldh-str>
+
+<let-dig-hyp> ::= <let-dig> | "-"
+
+<let-dig> ::= <letter> | <digit>
+
+<letter> ::= any one of the 52 alphabetic characters A through Z in
+upper case and a through z in lower case
+
+<digit> ::= any one of the ten digits 0 through 9
+
+Note that while upper and lower case letters are allowed in domain
+names, no significance is attached to the case.  That is, two names with
+the same spelling but different case are to be treated as if identical.
+
+The labels must follow the rules for ARPANET host names.  They must
+start with a letter, end with a letter or digit, and have as interior
+characters only letters, digits, and hyphen.  There are also some
+restrictions on the length.  Labels must be 63 characters or less.
+
+For example, the following strings identify hosts in the Internet:
+
+A.ISI.EDU  XX.LCS.MIT.EDU  SRI-NIC.ARPA
+
+3.6. Resource Records
+
+A domain name identifies a node.  Each node has a set of resource
+
+
+
+Mockapetris                                                    [Page 11]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+information, which may be empty.  The set of resource information
+associated with a particular name is composed of separate resource
+records (RRs).  The order of RRs in a set is not significant, and need
+not be preserved by name servers, resolvers, or other parts of the DNS.
+
+When we talk about a specific RR, we assume it has the following:
+
+owner           which is the domain name where the RR is found.
+
+type            which is an encoded 16 bit value that specifies the type
+                of the resource in this resource record.  Types refer to
+                abstract resources.
+
+                This memo uses the following types:
+
+                A               a host address
+
+                CNAME           identifies the canonical name of an
+                                alias
+
+                HINFO           identifies the CPU and OS used by a host
+
+                MX              identifies a mail exchange for the
+                                domain.  See [RFC-974 for details.
+
+                NS
+                the authoritative name server for the domain
+
+                PTR
+                a pointer to another part of the domain name space
+
+                SOA
+                identifies the start of a zone of authority]
+
+class           which is an encoded 16 bit value which identifies a
+                protocol family or instance of a protocol.
+
+                This memo uses the following classes:
+
+                IN              the Internet system
+
+                CH              the Chaos system
+
+TTL             which is the time to live of the RR.  This field is a 32
+                bit integer in units of seconds, an is primarily used by
+                resolvers when they cache RRs.  The TTL describes how
+                long a RR can be cached before it should be discarded.
+
+
+
+
+Mockapetris                                                    [Page 12]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+RDATA           which is the type and sometimes class dependent data
+                which describes the resource:
+
+                A               For the IN class, a 32 bit IP address
+
+                                For the CH class, a domain name followed
+                                by a 16 bit octal Chaos address.
+
+                CNAME           a domain name.
+
+                MX              a 16 bit preference value (lower is
+                                better) followed by a host name willing
+                                to act as a mail exchange for the owner
+                                domain.
+
+                NS              a host name.
+
+                PTR             a domain name.
+
+                SOA             several fields.
+
+The owner name is often implicit, rather than forming an integral part
+of the RR.  For example, many name servers internally form tree or hash
+structures for the name space, and chain RRs off nodes.  The remaining
+RR parts are the fixed header (type, class, TTL) which is consistent for
+all RRs, and a variable part (RDATA) that fits the needs of the resource
+being described.
+
+The meaning of the TTL field is a time limit on how long an RR can be
+kept in a cache.  This limit does not apply to authoritative data in
+zones; it is also timed out, but by the refreshing policies for the
+zone.  The TTL is assigned by the administrator for the zone where the
+data originates.  While short TTLs can be used to minimize caching, and
+a zero TTL prohibits caching, the realities of Internet performance
+suggest that these times should be on the order of days for the typical
+host.  If a change can be anticipated, the TTL can be reduced prior to
+the change to minimize inconsistency during the change, and then
+increased back to its former value following the change.
+
+The data in the RDATA section of RRs is carried as a combination of
+binary strings and domain names.  The domain names are frequently used
+as "pointers" to other data in the DNS.
+
+3.6.1. Textual expression of RRs
+
+RRs are represented in binary form in the packets of the DNS protocol,
+and are usually represented in highly encoded form when stored in a name
+server or resolver.  In this memo, we adopt a style similar to that used
+
+
+
+Mockapetris                                                    [Page 13]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+in master files in order to show the contents of RRs.  In this format,
+most RRs are shown on a single line, although continuation lines are
+possible using parentheses.
+
+The start of the line gives the owner of the RR.  If a line begins with
+a blank, then the owner is assumed to be the same as that of the
+previous RR.  Blank lines are often included for readability.
+
+Following the owner, we list the TTL, type, and class of the RR.  Class
+and type use the mnemonics defined above, and TTL is an integer before
+the type field.  In order to avoid ambiguity in parsing, type and class
+mnemonics are disjoint, TTLs are integers, and the type mnemonic is
+always last. The IN class and TTL values are often omitted from examples
+in the interests of clarity.
+
+The resource data or RDATA section of the RR are given using knowledge
+of the typical representation for the data.
+
+For example, we might show the RRs carried in a message as:
+
+    ISI.EDU.        MX      10 VENERA.ISI.EDU.
+                    MX      10 VAXA.ISI.EDU.
+    VENERA.ISI.EDU. A       128.9.0.32
+                    A       10.1.0.52
+    VAXA.ISI.EDU.   A       10.2.0.27
+                    A       128.9.0.33
+
+The MX RRs have an RDATA section which consists of a 16 bit number
+followed by a domain name.  The address RRs use a standard IP address
+format to contain a 32 bit internet address.
+
+This example shows six RRs, with two RRs at each of three domain names.
+
+Similarly we might see:
+
+    XX.LCS.MIT.EDU. IN      A       10.0.0.44
+                    CH      A       MIT.EDU. 2420
+
+This example shows two addresses for XX.LCS.MIT.EDU, each of a different
+class.
+
+3.6.2. Aliases and canonical names
+
+In existing systems, hosts and other resources often have several names
+that identify the same resource.  For example, the names C.ISI.EDU and
+USC-ISIC.ARPA both identify the same host.  Similarly, in the case of
+mailboxes, many organizations provide many names that actually go to the
+same mailbox; for example Mockapetris@C.ISI.EDU, Mockapetris@B.ISI.EDU,
+
+
+
+Mockapetris                                                    [Page 14]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+and PVM@ISI.EDU all go to the same mailbox (although the mechanism
+behind this is somewhat complicated).
+
+Most of these systems have a notion that one of the equivalent set of
+names is the canonical or primary name and all others are aliases.
+
+The domain system provides such a feature using the canonical name
+(CNAME) RR.  A CNAME RR identifies its owner name as an alias, and
+specifies the corresponding canonical name in the RDATA section of the
+RR.  If a CNAME RR is present at a node, no other data should be
+present; this ensures that the data for a canonical name and its aliases
+cannot be different.  This rule also insures that a cached CNAME can be
+used without checking with an authoritative server for other RR types.
+
+CNAME RRs cause special action in DNS software.  When a name server
+fails to find a desired RR in the resource set associated with the
+domain name, it checks to see if the resource set consists of a CNAME
+record with a matching class.  If so, the name server includes the CNAME
+record in the response and restarts the query at the domain name
+specified in the data field of the CNAME record.  The one exception to
+this rule is that queries which match the CNAME type are not restarted.
+
+For example, suppose a name server was processing a query with for USC-
+ISIC.ARPA, asking for type A information, and had the following resource
+records:
+
+    USC-ISIC.ARPA   IN      CNAME   C.ISI.EDU
+
+    C.ISI.EDU       IN      A       10.0.0.52
+
+Both of these RRs would be returned in the response to the type A query,
+while a type CNAME or * query should return just the CNAME.
+
+Domain names in RRs which point at another name should always point at
+the primary name and not the alias.  This avoids extra indirections in
+accessing information.  For example, the address to name RR for the
+above host should be:
+
+    52.0.0.10.IN-ADDR.ARPA  IN      PTR     C.ISI.EDU
+
+rather than pointing at USC-ISIC.ARPA.  Of course, by the robustness
+principle, domain software should not fail when presented with CNAME
+chains or loops; CNAME chains should be followed and CNAME loops
+signalled as an error.
+
+3.7. Queries
+
+Queries are messages which may be sent to a name server to provoke a
+
+
+
+Mockapetris                                                    [Page 15]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+response.  In the Internet, queries are carried in UDP datagrams or over
+TCP connections.  The response by the name server either answers the
+question posed in the query, refers the requester to another set of name
+servers, or signals some error condition.
+
+In general, the user does not generate queries directly, but instead
+makes a request to a resolver which in turn sends one or more queries to
+name servers and deals with the error conditions and referrals that may
+result.  Of course, the possible questions which can be asked in a query
+does shape the kind of service a resolver can provide.
+
+DNS queries and responses are carried in a standard message format.  The
+message format has a header containing a number of fixed fields which
+are always present, and four sections which carry query parameters and
+RRs.
+
+The most important field in the header is a four bit field called an
+opcode which separates different queries.  Of the possible 16 values,
+one (standard query) is part of the official protocol, two (inverse
+query and status query) are options, one (completion) is obsolete, and
+the rest are unassigned.
+
+The four sections are:
+
+Question        Carries the query name and other query parameters.
+
+Answer          Carries RRs which directly answer the query.
+
+Authority       Carries RRs which describe other authoritative servers.
+                May optionally carry the SOA RR for the authoritative
+                data in the answer section.
+
+Additional      Carries RRs which may be helpful in using the RRs in the
+                other sections.
+
+Note that the content, but not the format, of these sections varies with
+header opcode.
+
+3.7.1. Standard queries
+
+A standard query specifies a target domain name (QNAME), query type
+(QTYPE), and query class (QCLASS) and asks for RRs which match.  This
+type of query makes up such a vast majority of DNS queries that we use
+the term "query" to mean standard query unless otherwise specified.  The
+QTYPE and QCLASS fields are each 16 bits long, and are a superset of
+defined types and classes.
+
+
+
+
+
+Mockapetris                                                    [Page 16]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+The QTYPE field may contain:
+
+<any type>      matches just that type. (e.g., A, PTR).
+
+AXFR            special zone transfer QTYPE.
+
+MAILB           matches all mail box related RRs (e.g. MB and MG).
+
+*               matches all RR types.
+
+The QCLASS field may contain:
+
+<any class>     matches just that class (e.g., IN, CH).
+
+*               matches aLL RR classes.
+
+Using the query domain name, QTYPE, and QCLASS, the name server looks
+for matching RRs.  In addition to relevant records, the name server may
+return RRs that point toward a name server that has the desired
+information or RRs that are expected to be useful in interpreting the
+relevant RRs.  For example, a name server that doesn't have the
+requested information may know a name server that does; a name server
+that returns a domain name in a relevant RR may also return the RR that
+binds that domain name to an address.
+
+For example, a mailer tying to send mail to Mockapetris@ISI.EDU might
+ask the resolver for mail information about ISI.EDU, resulting in a
+query for QNAME=ISI.EDU, QTYPE=MX, QCLASS=IN.  The response's answer
+section would be:
+
+    ISI.EDU.        MX      10 VENERA.ISI.EDU.
+                    MX      10 VAXA.ISI.EDU.
+
+while the additional section might be:
+
+    VAXA.ISI.EDU.   A       10.2.0.27
+                    A       128.9.0.33
+    VENERA.ISI.EDU. A       10.1.0.52
+                    A       128.9.0.32
+
+Because the server assumes that if the requester wants mail exchange
+information, it will probably want the addresses of the mail exchanges
+soon afterward.
+
+Note that the QCLASS=* construct requires special interpretation
+regarding authority.  Since a particular name server may not know all of
+the classes available in the domain system, it can never know if it is
+authoritative for all classes.  Hence responses to QCLASS=* queries can
+
+
+
+Mockapetris                                                    [Page 17]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+never be authoritative.
+
+3.7.2. Inverse queries (Optional)
+
+Name servers may also support inverse queries that map a particular
+resource to a domain name or domain names that have that resource.  For
+example, while a standard query might map a domain name to a SOA RR, the
+corresponding inverse query might map the SOA RR back to the domain
+name.
+
+Implementation of this service is optional in a name server, but all
+name servers must at least be able to understand an inverse query
+message and return a not-implemented error response.
+
+The domain system cannot guarantee the completeness or uniqueness of
+inverse queries because the domain system is organized by domain name
+rather than by host address or any other resource type.  Inverse queries
+are primarily useful for debugging and database maintenance activities.
+
+Inverse queries may not return the proper TTL, and do not indicate cases
+where the identified RR is one of a set (for example, one address for a
+host having multiple addresses).  Therefore, the RRs returned in inverse
+queries should never be cached.
+
+Inverse queries are NOT an acceptable method for mapping host addresses
+to host names; use the IN-ADDR.ARPA domain instead.
+
+A detailed discussion of inverse queries is contained in [RFC-1035].
+
+3.8. Status queries (Experimental)
+
+To be defined.
+
+3.9. Completion queries (Obsolete)
+
+The optional completion services described in RFCs 882 and 883 have been
+deleted.  Redesigned services may become available in the future, or the
+opcodes may be reclaimed for other use.
+
+4. NAME SERVERS
+
+4.1. Introduction
+
+Name servers are the repositories of information that make up the domain
+database.  The database is divided up into sections called zones, which
+are distributed among the name servers.  While name servers can have
+several optional functions and sources of data, the essential task of a
+name server is to answer queries using data in its zones.  By design,
+
+
+
+Mockapetris                                                    [Page 18]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+name servers can answer queries in a simple manner; the response can
+always be generated using only local data, and either contains the
+answer to the question or a referral to other name servers "closer" to
+the desired information.
+
+A given zone will be available from several name servers to insure its
+availability in spite of host or communication link failure.  By
+administrative fiat, we require every zone to be available on at least
+two servers, and many zones have more redundancy than that.
+
+A given name server will typically support one or more zones, but this
+gives it authoritative information about only a small section of the
+domain tree.  It may also have some cached non-authoritative data about
+other parts of the tree.  The name server marks its responses to queries
+so that the requester can tell whether the response comes from
+authoritative data or not.
+
+4.2. How the database is divided into zones
+
+The domain database is partitioned in two ways: by class, and by "cuts"
+made in the name space between nodes.
+
+The class partition is simple.  The database for any class is organized,
+delegated, and maintained separately from all other classes.  Since, by
+convention, the name spaces are the same for all classes, the separate
+classes can be thought of as an array of parallel namespace trees.  Note
+that the data attached to nodes will be different for these different
+parallel classes.  The most common reasons for creating a new class are
+the necessity for a new data format for existing types or a desire for a
+separately managed version of the existing name space.
+
+Within a class, "cuts" in the name space can be made between any two
+adjacent nodes.  After all cuts are made, each group of connected name
+space is a separate zone.  The zone is said to be authoritative for all
+names in the connected region.  Note that the "cuts" in the name space
+may be in different places for different classes, the name servers may
+be different, etc.
+
+These rules mean that every zone has at least one node, and hence domain
+name, for which it is authoritative, and all of the nodes in a
+particular zone are connected.  Given, the tree structure, every zone
+has a highest node which is closer to the root than any other node in
+the zone.  The name of this node is often used to identify the zone.
+
+It would be possible, though not particularly useful, to partition the
+name space so that each domain name was in a separate zone or so that
+all nodes were in a single zone.  Instead, the database is partitioned
+at points where a particular organization wants to take over control of
+
+
+
+Mockapetris                                                    [Page 19]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+a subtree.  Once an organization controls its own zone it can
+unilaterally change the data in the zone, grow new tree sections
+connected to the zone, delete existing nodes, or delegate new subzones
+under its zone.
+
+If the organization has substructure, it may want to make further
+internal partitions to achieve nested delegations of name space control.
+In some cases, such divisions are made purely to make database
+maintenance more convenient.
+
+4.2.1. Technical considerations
+
+The data that describes a zone has four major parts:
+
+   - Authoritative data for all nodes within the zone.
+
+   - Data that defines the top node of the zone (can be thought of
+     as part of the authoritative data).
+
+   - Data that describes delegated subzones, i.e., cuts around the
+     bottom of the zone.
+
+   - Data that allows access to name servers for subzones
+     (sometimes called "glue" data).
+
+All of this data is expressed in the form of RRs, so a zone can be
+completely described in terms of a set of RRs.  Whole zones can be
+transferred between name servers by transferring the RRs, either carried
+in a series of messages or by FTPing a master file which is a textual
+representation.
+
+The authoritative data for a zone is simply all of the RRs attached to
+all of the nodes from the top node of the zone down to leaf nodes or
+nodes above cuts around the bottom edge of the zone.
+
+Though logically part of the authoritative data, the RRs that describe
+the top node of the zone are especially important to the zone's
+management.  These RRs are of two types: name server RRs that list, one
+per RR, all of the servers for the zone, and a single SOA RR that
+describes zone management parameters.
+
+The RRs that describe cuts around the bottom of the zone are NS RRs that
+name the servers for the subzones.  Since the cuts are between nodes,
+these RRs are NOT part of the authoritative data of the zone, and should
+be exactly the same as the corresponding RRs in the top node of the
+subzone.  Since name servers are always associated with zone boundaries,
+NS RRs are only found at nodes which are the top node of some zone.  In
+the data that makes up a zone, NS RRs are found at the top node of the
+
+
+
+Mockapetris                                                    [Page 20]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+zone (and are authoritative) and at cuts around the bottom of the zone
+(where they are not authoritative), but never in between.
+
+One of the goals of the zone structure is that any zone have all the
+data required to set up communications with the name servers for any
+subzones.  That is, parent zones have all the information needed to
+access servers for their children zones.  The NS RRs that name the
+servers for subzones are often not enough for this task since they name
+the servers, but do not give their addresses.  In particular, if the
+name of the name server is itself in the subzone, we could be faced with
+the situation where the NS RRs tell us that in order to learn a name
+server's address, we should contact the server using the address we wish
+to learn.  To fix this problem, a zone contains "glue" RRs which are not
+part of the authoritative data, and are address RRs for the servers.
+These RRs are only necessary if the name server's name is "below" the
+cut, and are only used as part of a referral response.
+
+4.2.2. Administrative considerations
+
+When some organization wants to control its own domain, the first step
+is to identify the proper parent zone, and get the parent zone's owners
+to agree to the delegation of control.  While there are no particular
+technical constraints dealing with where in the tree this can be done,
+there are some administrative groupings discussed in [RFC-1032] which
+deal with top level organization, and middle level zones are free to
+create their own rules.  For example, one university might choose to use
+a single zone, while another might choose to organize by subzones
+dedicated to individual departments or schools.  [RFC-1033] catalogs
+available DNS software an discusses administration procedures.
+
+Once the proper name for the new subzone is selected, the new owners
+should be required to demonstrate redundant name server support.  Note
+that there is no requirement that the servers for a zone reside in a
+host which has a name in that domain.  In many cases, a zone will be
+more accessible to the internet at large if its servers are widely
+distributed rather than being within the physical facilities controlled
+by the same organization that manages the zone.  For example, in the
+current DNS, one of the name servers for the United Kingdom, or UK
+domain, is found in the US.  This allows US hosts to get UK data without
+using limited transatlantic bandwidth.
+
+As the last installation step, the delegation NS RRs and glue RRs
+necessary to make the delegation effective should be added to the parent
+zone.  The administrators of both zones should insure that the NS and
+glue RRs which mark both sides of the cut are consistent and remain so.
+
+4.3. Name server internals
+
+
+
+
+Mockapetris                                                    [Page 21]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+4.3.1. Queries and responses
+
+The principal activity of name servers is to answer standard queries.
+Both the query and its response are carried in a standard message format
+which is described in [RFC-1035].  The query contains a QTYPE, QCLASS,
+and QNAME, which describe the types and classes of desired information
+and the name of interest.
+
+The way that the name server answers the query depends upon whether it
+is operating in recursive mode or not:
+
+   - The simplest mode for the server is non-recursive, since it
+     can answer queries using only local information: the response
+     contains an error, the answer, or a referral to some other
+     server "closer" to the answer.  All name servers must
+     implement non-recursive queries.
+
+   - The simplest mode for the client is recursive, since in this
+     mode the name server acts in the role of a resolver and
+     returns either an error or the answer, but never referrals.
+     This service is optional in a name server, and the name server
+     may also choose to restrict the clients which can use
+     recursive mode.
+
+Recursive service is helpful in several situations:
+
+   - a relatively simple requester that lacks the ability to use
+     anything other than a direct answer to the question.
+
+   - a request that needs to cross protocol or other boundaries and
+     can be sent to a server which can act as intermediary.
+
+   - a network where we want to concentrate the cache rather than
+     having a separate cache for each client.
+
+Non-recursive service is appropriate if the requester is capable of
+pursuing referrals and interested in information which will aid future
+requests.
+
+The use of recursive mode is limited to cases where both the client and
+the name server agree to its use.  The agreement is negotiated through
+the use of two bits in query and response messages:
+
+   - The recursion available, or RA bit, is set or cleared by a
+     name server in all responses.  The bit is true if the name
+     server is willing to provide recursive service for the client,
+     regardless of whether the client requested recursive service.
+     That is, RA signals availability rather than use.
+
+
+
+Mockapetris                                                    [Page 22]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+   - Queries contain a bit called recursion desired or RD.  This
+     bit specifies specifies whether the requester wants recursive
+     service for this query.  Clients may request recursive service
+     from any name server, though they should depend upon receiving
+     it only from servers which have previously sent an RA, or
+     servers which have agreed to provide service through private
+     agreement or some other means outside of the DNS protocol.
+
+The recursive mode occurs when a query with RD set arrives at a server
+which is willing to provide recursive service; the client can verify
+that recursive mode was used by checking that both RA and RD are set in
+the reply.  Note that the name server should never perform recursive
+service unless asked via RD, since this interferes with trouble shooting
+of name servers and their databases.
+
+If recursive service is requested and available, the recursive response
+to a query will be one of the following:
+
+   - The answer to the query, possibly preface by one or more CNAME
+     RRs that specify aliases encountered on the way to an answer.
+
+   - A name error indicating that the name does not exist.  This
+     may include CNAME RRs that indicate that the original query
+     name was an alias for a name which does not exist.
+
+   - A temporary error indication.
+
+If recursive service is not requested or is not available, the non-
+recursive response will be one of the following:
+
+   - An authoritative name error indicating that the name does not
+     exist.
+
+   - A temporary error indication.
+
+   - Some combination of:
+
+     RRs that answer the question, together with an indication
+     whether the data comes from a zone or is cached.
+
+     A referral to name servers which have zones which are closer
+     ancestors to the name than the server sending the reply.
+
+   - RRs that the name server thinks will prove useful to the
+     requester.
+
+
+
+
+
+
+Mockapetris                                                    [Page 23]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+4.3.2. Algorithm
+
+The actual algorithm used by the name server will depend on the local OS
+and data structures used to store RRs.  The following algorithm assumes
+that the RRs are organized in several tree structures, one for each
+zone, and another for the cache:
+
+   1. Set or clear the value of recursion available in the response
+      depending on whether the name server is willing to provide
+      recursive service.  If recursive service is available and
+      requested via the RD bit in the query, go to step 5,
+      otherwise step 2.
+
+   2. Search the available zones for the zone which is the nearest
+      ancestor to QNAME.  If such a zone is found, go to step 3,
+      otherwise step 4.
+
+   3. Start matching down, label by label, in the zone.  The
+      matching process can terminate several ways:
+
+         a. If the whole of QNAME is matched, we have found the
+            node.
+
+            If the data at the node is a CNAME, and QTYPE doesn't
+            match CNAME, copy the CNAME RR into the answer section
+            of the response, change QNAME to the canonical name in
+            the CNAME RR, and go back to step 1.
+
+            Otherwise, copy all RRs which match QTYPE into the
+            answer section and go to step 6.
+
+         b. If a match would take us out of the authoritative data,
+            we have a referral.  This happens when we encounter a
+            node with NS RRs marking cuts along the bottom of a
+            zone.
+
+            Copy the NS RRs for the subzone into the authority
+            section of the reply.  Put whatever addresses are
+            available into the additional section, using glue RRs
+            if the addresses are not available from authoritative
+            data or the cache.  Go to step 4.
+
+         c. If at some label, a match is impossible (i.e., the
+            corresponding label does not exist), look to see if a
+            the "*" label exists.
+
+            If the "*" label does not exist, check whether the name
+            we are looking for is the original QNAME in the query
+
+
+
+Mockapetris                                                    [Page 24]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+            or a name we have followed due to a CNAME.  If the name
+            is original, set an authoritative name error in the
+            response and exit.  Otherwise just exit.
+
+            If the "*" label does exist, match RRs at that node
+            against QTYPE.  If any match, copy them into the answer
+            section, but set the owner of the RR to be QNAME, and
+            not the node with the "*" label.  Go to step 6.
+
+   4. Start matching down in the cache.  If QNAME is found in the
+      cache, copy all RRs attached to it that match QTYPE into the
+      answer section.  If there was no delegation from
+      authoritative data, look for the best one from the cache, and
+      put it in the authority section.  Go to step 6.
+
+   5. Using the local resolver or a copy of its algorithm (see
+      resolver section of this memo) to answer the query.  Store
+      the results, including any intermediate CNAMEs, in the answer
+      section of the response.
+
+   6. Using local data only, attempt to add other RRs which may be
+      useful to the additional section of the query.  Exit.
+
+4.3.3. Wildcards
+
+In the previous algorithm, special treatment was given to RRs with owner
+names starting with the label "*".  Such RRs are called wildcards.
+Wildcard RRs can be thought of as instructions for synthesizing RRs.
+When the appropriate conditions are met, the name server creates RRs
+with an owner name equal to the query name and contents taken from the
+wildcard RRs.
+
+This facility is most often used to create a zone which will be used to
+forward mail from the Internet to some other mail system.  The general
+idea is that any name in that zone which is presented to server in a
+query will be assumed to exist, with certain properties, unless explicit
+evidence exists to the contrary.  Note that the use of the term zone
+here, instead of domain, is intentional; such defaults do not propagate
+across zone boundaries, although a subzone may choose to achieve that
+appearance by setting up similar defaults.
+
+The contents of the wildcard RRs follows the usual rules and formats for
+RRs.  The wildcards in the zone have an owner name that controls the
+query names they will match.  The owner name of the wildcard RRs is of
+the form "*.<anydomain>", where <anydomain> is any domain name.
+<anydomain> should not contain other * labels, and should be in the
+authoritative data of the zone.  The wildcards potentially apply to
+descendants of <anydomain>, but not to <anydomain> itself.  Another way
+
+
+
+Mockapetris                                                    [Page 25]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+to look at this is that the "*" label always matches at least one whole
+label and sometimes more, but always whole labels.
+
+Wildcard RRs do not apply:
+
+   - When the query is in another zone.  That is, delegation cancels
+     the wildcard defaults.
+
+   - When the query name or a name between the wildcard domain and
+     the query name is know to exist.  For example, if a wildcard
+     RR has an owner name of "*.X", and the zone also contains RRs
+     attached to B.X, the wildcards would apply to queries for name
+     Z.X (presuming there is no explicit information for Z.X), but
+     not to B.X, A.B.X, or X.
+
+A * label appearing in a query name has no special effect, but can be
+used to test for wildcards in an authoritative zone; such a query is the
+only way to get a response containing RRs with an owner name with * in
+it.  The result of such a query should not be cached.
+
+Note that the contents of the wildcard RRs are not modified when used to
+synthesize RRs.
+
+To illustrate the use of wildcard RRs, suppose a large company with a
+large, non-IP/TCP, network wanted to create a mail gateway.  If the
+company was called X.COM, and IP/TCP capable gateway machine was called
+A.X.COM, the following RRs might be entered into the COM zone:
+
+    X.COM           MX      10      A.X.COM
+
+    *.X.COM         MX      10      A.X.COM
+
+    A.X.COM         A       1.2.3.4
+    A.X.COM         MX      10      A.X.COM
+
+    *.A.X.COM       MX      10      A.X.COM
+
+This would cause any MX query for any domain name ending in X.COM to
+return an MX RR pointing at A.X.COM.  Two wildcard RRs are required
+since the effect of the wildcard at *.X.COM is inhibited in the A.X.COM
+subtree by the explicit data for A.X.COM.  Note also that the explicit
+MX data at X.COM and A.X.COM is required, and that none of the RRs above
+would match a query name of XX.COM.
+
+4.3.4. Negative response caching (Optional)
+
+The DNS provides an optional service which allows name servers to
+distribute, and resolvers to cache, negative results with TTLs.  For
+
+
+
+Mockapetris                                                    [Page 26]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+example, a name server can distribute a TTL along with a name error
+indication, and a resolver receiving such information is allowed to
+assume that the name does not exist during the TTL period without
+consulting authoritative data.  Similarly, a resolver can make a query
+with a QTYPE which matches multiple types, and cache the fact that some
+of the types are not present.
+
+This feature can be particularly important in a system which implements
+naming shorthands that use search lists beacuse a popular shorthand,
+which happens to require a suffix toward the end of the search list,
+will generate multiple name errors whenever it is used.
+
+The method is that a name server may add an SOA RR to the additional
+section of a response when that response is authoritative.  The SOA must
+be that of the zone which was the source of the authoritative data in
+the answer section, or name error if applicable.  The MINIMUM field of
+the SOA controls the length of time that the negative result may be
+cached.
+
+Note that in some circumstances, the answer section may contain multiple
+owner names.  In this case, the SOA mechanism should only be used for
+the data which matches QNAME, which is the only authoritative data in
+this section.
+
+Name servers and resolvers should never attempt to add SOAs to the
+additional section of a non-authoritative response, or attempt to infer
+results which are not directly stated in an authoritative response.
+There are several reasons for this, including: cached information isn't
+usually enough to match up RRs and their zone names, SOA RRs may be
+cached due to direct SOA queries, and name servers are not required to
+output the SOAs in the authority section.
+
+This feature is optional, although a refined version is expected to
+become part of the standard protocol in the future.  Name servers are
+not required to add the SOA RRs in all authoritative responses, nor are
+resolvers required to cache negative results.  Both are recommended.
+All resolvers and recursive name servers are required to at least be
+able to ignore the SOA RR when it is present in a response.
+
+Some experiments have also been proposed which will use this feature.
+The idea is that if cached data is known to come from a particular zone,
+and if an authoritative copy of the zone's SOA is obtained, and if the
+zone's SERIAL has not changed since the data was cached, then the TTL of
+the cached data can be reset to the zone MINIMUM value if it is smaller.
+This usage is mentioned for planning purposes only, and is not
+recommended as yet.
+
+
+
+
+
+Mockapetris                                                    [Page 27]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+4.3.5. Zone maintenance and transfers
+
+Part of the job of a zone administrator is to maintain the zones at all
+of the name servers which are authoritative for the zone.  When the
+inevitable changes are made, they must be distributed to all of the name
+servers.  While this distribution can be accomplished using FTP or some
+other ad hoc procedure, the preferred method is the zone transfer part
+of the DNS protocol.
+
+The general model of automatic zone transfer or refreshing is that one
+of the name servers is the master or primary for the zone.  Changes are
+coordinated at the primary, typically by editing a master file for the
+zone.  After editing, the administrator signals the master server to
+load the new zone.  The other non-master or secondary servers for the
+zone periodically check for changes (at a selectable interval) and
+obtain new zone copies when changes have been made.
+
+To detect changes, secondaries just check the SERIAL field of the SOA
+for the zone.  In addition to whatever other changes are made, the
+SERIAL field in the SOA of the zone is always advanced whenever any
+change is made to the zone.  The advancing can be a simple increment, or
+could be based on the write date and time of the master file, etc.  The
+purpose is to make it possible to determine which of two copies of a
+zone is more recent by comparing serial numbers.  Serial number advances
+and comparisons use sequence space arithmetic, so there is a theoretic
+limit on how fast a zone can be updated, basically that old copies must
+die out before the serial number covers half of its 32 bit range.  In
+practice, the only concern is that the compare operation deals properly
+with comparisons around the boundary between the most positive and most
+negative 32 bit numbers.
+
+The periodic polling of the secondary servers is controlled by
+parameters in the SOA RR for the zone, which set the minimum acceptable
+polling intervals.  The parameters are called REFRESH, RETRY, and
+EXPIRE.  Whenever a new zone is loaded in a secondary, the secondary
+waits REFRESH seconds before checking with the primary for a new serial.
+If this check cannot be completed, new checks are started every RETRY
+seconds.  The check is a simple query to the primary for the SOA RR of
+the zone.  If the serial field in the secondary's zone copy is equal to
+the serial returned by the primary, then no changes have occurred, and
+the REFRESH interval wait is restarted.  If the secondary finds it
+impossible to perform a serial check for the EXPIRE interval, it must
+assume that its copy of the zone is obsolete an discard it.
+
+When the poll shows that the zone has changed, then the secondary server
+must request a zone transfer via an AXFR request for the zone.  The AXFR
+may cause an error, such as refused, but normally is answered by a
+sequence of response messages.  The first and last messages must contain
+
+
+
+Mockapetris                                                    [Page 28]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+the data for the top authoritative node of the zone.  Intermediate
+messages carry all of the other RRs from the zone, including both
+authoritative and non-authoritative RRs.  The stream of messages allows
+the secondary to construct a copy of the zone.  Because accuracy is
+essential, TCP or some other reliable protocol must be used for AXFR
+requests.
+
+Each secondary server is required to perform the following operations
+against the master, but may also optionally perform these operations
+against other secondary servers.  This strategy can improve the transfer
+process when the primary is unavailable due to host downtime or network
+problems, or when a secondary server has better network access to an
+"intermediate" secondary than to the primary.
+
+5. RESOLVERS
+
+5.1. Introduction
+
+Resolvers are programs that interface user programs to domain name
+servers.  In the simplest case, a resolver receives a request from a
+user program (e.g., mail programs, TELNET, FTP) in the form of a
+subroutine call, system call etc., and returns the desired information
+in a form compatible with the local host's data formats.
+
+The resolver is located on the same machine as the program that requests
+the resolver's services, but it may need to consult name servers on
+other hosts.  Because a resolver may need to consult several name
+servers, or may have the requested information in a local cache, the
+amount of time that a resolver will take to complete can vary quite a
+bit, from milliseconds to several seconds.
+
+A very important goal of the resolver is to eliminate network delay and
+name server load from most requests by answering them from its cache of
+prior results.  It follows that caches which are shared by multiple
+processes, users, machines, etc., are more efficient than non-shared
+caches.
+
+5.2. Client-resolver interface
+
+5.2.1. Typical functions
+
+The client interface to the resolver is influenced by the local host's
+conventions, but the typical resolver-client interface has three
+functions:
+
+   1. Host name to host address translation.
+
+      This function is often defined to mimic a previous HOSTS.TXT
+
+
+
+Mockapetris                                                    [Page 29]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+      based function.  Given a character string, the caller wants
+      one or more 32 bit IP addresses.  Under the DNS, it
+      translates into a request for type A RRs.  Since the DNS does
+      not preserve the order of RRs, this function may choose to
+      sort the returned addresses or select the "best" address if
+      the service returns only one choice to the client.  Note that
+      a multiple address return is recommended, but a single
+      address may be the only way to emulate prior HOSTS.TXT
+      services.
+
+   2. Host address to host name translation
+
+      This function will often follow the form of previous
+      functions.  Given a 32 bit IP address, the caller wants a
+      character string.  The octets of the IP address are reversed,
+      used as name components, and suffixed with "IN-ADDR.ARPA".  A
+      type PTR query is used to get the RR with the primary name of
+      the host.  For example, a request for the host name
+      corresponding to IP address 1.2.3.4 looks for PTR RRs for
+      domain name "4.3.2.1.IN-ADDR.ARPA".
+
+   3. General lookup function
+
+      This function retrieves arbitrary information from the DNS,
+      and has no counterpart in previous systems.  The caller
+      supplies a QNAME, QTYPE, and QCLASS, and wants all of the
+      matching RRs.  This function will often use the DNS format
+      for all RR data instead of the local host's, and returns all
+      RR content (e.g., TTL) instead of a processed form with local
+      quoting conventions.
+
+When the resolver performs the indicated function, it usually has one of
+the following results to pass back to the client:
+
+   - One or more RRs giving the requested data.
+
+     In this case the resolver returns the answer in the
+     appropriate format.
+
+   - A name error (NE).
+
+     This happens when the referenced name does not exist.  For
+     example, a user may have mistyped a host name.
+
+   - A data not found error.
+
+     This happens when the referenced name exists, but data of the
+     appropriate type does not.  For example, a host address
+
+
+
+Mockapetris                                                    [Page 30]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+     function applied to a mailbox name would return this error
+     since the name exists, but no address RR is present.
+
+It is important to note that the functions for translating between host
+names and addresses may combine the "name error" and "data not found"
+error conditions into a single type of error return, but the general
+function should not.  One reason for this is that applications may ask
+first for one type of information about a name followed by a second
+request to the same name for some other type of information; if the two
+errors are combined, then useless queries may slow the application.
+
+5.2.2. Aliases
+
+While attempting to resolve a particular request, the resolver may find
+that the name in question is an alias.  For example, the resolver might
+find that the name given for host name to address translation is an
+alias when it finds the CNAME RR.  If possible, the alias condition
+should be signalled back from the resolver to the client.
+
+In most cases a resolver simply restarts the query at the new name when
+it encounters a CNAME.  However, when performing the general function,
+the resolver should not pursue aliases when the CNAME RR matches the
+query type.  This allows queries which ask whether an alias is present.
+For example, if the query type is CNAME, the user is interested in the
+CNAME RR itself, and not the RRs at the name it points to.
+
+Several special conditions can occur with aliases.  Multiple levels of
+aliases should be avoided due to their lack of efficiency, but should
+not be signalled as an error.  Alias loops and aliases which point to
+non-existent names should be caught and an error condition passed back
+to the client.
+
+5.2.3. Temporary failures
+
+In a less than perfect world, all resolvers will occasionally be unable
+to resolve a particular request.  This condition can be caused by a
+resolver which becomes separated from the rest of the network due to a
+link failure or gateway problem, or less often by coincident failure or
+unavailability of all servers for a particular domain.
+
+It is essential that this sort of condition should not be signalled as a
+name or data not present error to applications.  This sort of behavior
+is annoying to humans, and can wreak havoc when mail systems use the
+DNS.
+
+While in some cases it is possible to deal with such a temporary problem
+by blocking the request indefinitely, this is usually not a good choice,
+particularly when the client is a server process that could move on to
+
+
+
+Mockapetris                                                    [Page 31]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+other tasks.  The recommended solution is to always have temporary
+failure as one of the possible results of a resolver function, even
+though this may make emulation of existing HOSTS.TXT functions more
+difficult.
+
+5.3. Resolver internals
+
+Every resolver implementation uses slightly different algorithms, and
+typically spends much more logic dealing with errors of various sorts
+than typical occurances.  This section outlines a recommended basic
+strategy for resolver operation, but leaves details to [RFC-1035].
+
+5.3.1. Stub resolvers
+
+One option for implementing a resolver is to move the resolution
+function out of the local machine and into a name server which supports
+recursive queries.  This can provide an easy method of providing domain
+service in a PC which lacks the resources to perform the resolver
+function, or can centralize the cache for a whole local network or
+organization.
+
+All that the remaining stub needs is a list of name server addresses
+that will perform the recursive requests.  This type of resolver
+presumably needs the information in a configuration file, since it
+probably lacks the sophistication to locate it in the domain database.
+The user also needs to verify that the listed servers will perform the
+recursive service; a name server is free to refuse to perform recursive
+services for any or all clients.  The user should consult the local
+system administrator to find name servers willing to perform the
+service.
+
+This type of service suffers from some drawbacks.  Since the recursive
+requests may take an arbitrary amount of time to perform, the stub may
+have difficulty optimizing retransmission intervals to deal with both
+lost UDP packets and dead servers; the name server can be easily
+overloaded by too zealous a stub if it interprets retransmissions as new
+requests.  Use of TCP may be an answer, but TCP may well place burdens
+on the host's capabilities which are similar to those of a real
+resolver.
+
+5.3.2. Resources
+
+In addition to its own resources, the resolver may also have shared
+access to zones maintained by a local name server.  This gives the
+resolver the advantage of more rapid access, but the resolver must be
+careful to never let cached information override zone data.  In this
+discussion the term "local information" is meant to mean the union of
+the cache and such shared zones, with the understanding that
+
+
+
+Mockapetris                                                    [Page 32]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+authoritative data is always used in preference to cached data when both
+are present.
+
+The following resolver algorithm assumes that all functions have been
+converted to a general lookup function, and uses the following data
+structures to represent the state of a request in progress in the
+resolver:
+
+SNAME           the domain name we are searching for.
+
+STYPE           the QTYPE of the search request.
+
+SCLASS          the QCLASS of the search request.
+
+SLIST           a structure which describes the name servers and the
+                zone which the resolver is currently trying to query.
+                This structure keeps track of the resolver's current
+                best guess about which name servers hold the desired
+                information; it is updated when arriving information
+                changes the guess.  This structure includes the
+                equivalent of a zone name, the known name servers for
+                the zone, the known addresses for the name servers, and
+                history information which can be used to suggest which
+                server is likely to be the best one to try next.  The
+                zone name equivalent is a match count of the number of
+                labels from the root down which SNAME has in common with
+                the zone being queried; this is used as a measure of how
+                "close" the resolver is to SNAME.
+
+SBELT           a "safety belt" structure of the same form as SLIST,
+                which is initialized from a configuration file, and
+                lists servers which should be used when the resolver
+                doesn't have any local information to guide name server
+                selection.  The match count will be -1 to indicate that
+                no labels are known to match.
+
+CACHE           A structure which stores the results from previous
+                responses.  Since resolvers are responsible for
+                discarding old RRs whose TTL has expired, most
+                implementations convert the interval specified in
+                arriving RRs to some sort of absolute time when the RR
+                is stored in the cache.  Instead of counting the TTLs
+                down individually, the resolver just ignores or discards
+                old RRs when it runs across them in the course of a
+                search, or discards them during periodic sweeps to
+                reclaim the memory consumed by old RRs.
+
+
+
+
+
+Mockapetris                                                    [Page 33]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+5.3.3. Algorithm
+
+The top level algorithm has four steps:
+
+   1. See if the answer is in local information, and if so return
+      it to the client.
+
+   2. Find the best servers to ask.
+
+   3. Send them queries until one returns a response.
+
+   4. Analyze the response, either:
+
+         a. if the response answers the question or contains a name
+            error, cache the data as well as returning it back to
+            the client.
+
+         b. if the response contains a better delegation to other
+            servers, cache the delegation information, and go to
+            step 2.
+
+         c. if the response shows a CNAME and that is not the
+            answer itself, cache the CNAME, change the SNAME to the
+            canonical name in the CNAME RR and go to step 1.
+
+         d. if the response shows a servers failure or other
+            bizarre contents, delete the server from the SLIST and
+            go back to step 3.
+
+Step 1 searches the cache for the desired data. If the data is in the
+cache, it is assumed to be good enough for normal use.  Some resolvers
+have an option at the user interface which will force the resolver to
+ignore the cached data and consult with an authoritative server.  This
+is not recommended as the default.  If the resolver has direct access to
+a name server's zones, it should check to see if the desired data is
+present in authoritative form, and if so, use the authoritative data in
+preference to cached data.
+
+Step 2 looks for a name server to ask for the required data.  The
+general strategy is to look for locally-available name server RRs,
+starting at SNAME, then the parent domain name of SNAME, the
+grandparent, and so on toward the root.  Thus if SNAME were
+Mockapetris.ISI.EDU, this step would look for NS RRs for
+Mockapetris.ISI.EDU, then ISI.EDU, then EDU, and then . (the root).
+These NS RRs list the names of hosts for a zone at or above SNAME.  Copy
+the names into SLIST.  Set up their addresses using local data.  It may
+be the case that the addresses are not available.  The resolver has many
+choices here; the best is to start parallel resolver processes looking
+
+
+
+Mockapetris                                                    [Page 34]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+for the addresses while continuing onward with the addresses which are
+available.  Obviously, the design choices and options are complicated
+and a function of the local host's capabilities.  The recommended
+priorities for the resolver designer are:
+
+   1. Bound the amount of work (packets sent, parallel processes
+      started) so that a request can't get into an infinite loop or
+      start off a chain reaction of requests or queries with other
+      implementations EVEN IF SOMEONE HAS INCORRECTLY CONFIGURED
+      SOME DATA.
+
+   2. Get back an answer if at all possible.
+
+   3. Avoid unnecessary transmissions.
+
+   4. Get the answer as quickly as possible.
+
+If the search for NS RRs fails, then the resolver initializes SLIST from
+the safety belt SBELT.  The basic idea is that when the resolver has no
+idea what servers to ask, it should use information from a configuration
+file that lists several servers which are expected to be helpful.
+Although there are special situations, the usual choice is two of the
+root servers and two of the servers for the host's domain.  The reason
+for two of each is for redundancy.  The root servers will provide
+eventual access to all of the domain space.  The two local servers will
+allow the resolver to continue to resolve local names if the local
+network becomes isolated from the internet due to gateway or link
+failure.
+
+In addition to the names and addresses of the servers, the SLIST data
+structure can be sorted to use the best servers first, and to insure
+that all addresses of all servers are used in a round-robin manner.  The
+sorting can be a simple function of preferring addresses on the local
+network over others, or may involve statistics from past events, such as
+previous response times and batting averages.
+
+Step 3 sends out queries until a response is received.  The strategy is
+to cycle around all of the addresses for all of the servers with a
+timeout between each transmission.  In practice it is important to use
+all addresses of a multihomed host, and too aggressive a retransmission
+policy actually slows response when used by multiple resolvers
+contending for the same name server and even occasionally for a single
+resolver.  SLIST typically contains data values to control the timeouts
+and keep track of previous transmissions.
+
+Step 4 involves analyzing responses.  The resolver should be highly
+paranoid in its parsing of responses.  It should also check that the
+response matches the query it sent using the ID field in the response.
+
+
+
+Mockapetris                                                    [Page 35]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+The ideal answer is one from a server authoritative for the query which
+either gives the required data or a name error.  The data is passed back
+to the user and entered in the cache for future use if its TTL is
+greater than zero.
+
+If the response shows a delegation, the resolver should check to see
+that the delegation is "closer" to the answer than the servers in SLIST
+are.  This can be done by comparing the match count in SLIST with that
+computed from SNAME and the NS RRs in the delegation.  If not, the reply
+is bogus and should be ignored.  If the delegation is valid the NS
+delegation RRs and any address RRs for the servers should be cached.
+The name servers are entered in the SLIST, and the search is restarted.
+
+If the response contains a CNAME, the search is restarted at the CNAME
+unless the response has the data for the canonical name or if the CNAME
+is the answer itself.
+
+Details and implementation hints can be found in [RFC-1035].
+
+6. A SCENARIO
+
+In our sample domain space, suppose we wanted separate administrative
+control for the root, MIL, EDU, MIT.EDU and ISI.EDU zones.  We might
+allocate name servers as follows:
+
+
+                                   |(C.ISI.EDU,SRI-NIC.ARPA
+                                   | A.ISI.EDU)
+             +---------------------+------------------+
+             |                     |                  |
+            MIL                   EDU                ARPA
+             |(SRI-NIC.ARPA,       |(SRI-NIC.ARPA,    |
+             | A.ISI.EDU           | C.ISI.EDU)       |
+       +-----+-----+               |     +------+-----+-----+
+       |     |     |               |     |      |           |
+      BRL  NOSC  DARPA             |  IN-ADDR  SRI-NIC     ACC
+                                   |
+       +--------+------------------+---------------+--------+
+       |        |                  |               |        |
+      UCI      MIT                 |              UDEL     YALE
+                |(XX.LCS.MIT.EDU, ISI
+                |ACHILLES.MIT.EDU) |(VAXA.ISI.EDU,VENERA.ISI.EDU,
+            +---+---+              | A.ISI.EDU)
+            |       |              |
+           LCS   ACHILLES +--+-----+-----+--------+
+            |             |  |     |     |        |
+            XX            A  C   VAXA  VENERA Mockapetris
+
+
+
+
+Mockapetris                                                    [Page 36]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+In this example, the authoritative name server is shown in parentheses
+at the point in the domain tree at which is assumes control.
+
+Thus the root name servers are on C.ISI.EDU, SRI-NIC.ARPA, and
+A.ISI.EDU.  The MIL domain is served by SRI-NIC.ARPA and A.ISI.EDU.  The
+EDU domain is served by SRI-NIC.ARPA. and C.ISI.EDU.  Note that servers
+may have zones which are contiguous or disjoint.  In this scenario,
+C.ISI.EDU has contiguous zones at the root and EDU domains.  A.ISI.EDU
+has contiguous zones at the root and MIL domains, but also has a non-
+contiguous zone at ISI.EDU.
+
+6.1. C.ISI.EDU name server
+
+C.ISI.EDU is a name server for the root, MIL, and EDU domains of the IN
+class, and would have zones for these domains.  The zone data for the
+root domain might be:
+
+    .       IN      SOA     SRI-NIC.ARPA. HOSTMASTER.SRI-NIC.ARPA. (
+                            870611          ;serial
+                            1800            ;refresh every 30 min
+                            300             ;retry every 5 min
+                            604800          ;expire after a week
+                            86400)          ;minimum of a day
+                    NS      A.ISI.EDU.
+                    NS      C.ISI.EDU.
+                    NS      SRI-NIC.ARPA.
+
+    MIL.    86400   NS      SRI-NIC.ARPA.
+            86400   NS      A.ISI.EDU.
+
+    EDU.    86400   NS      SRI-NIC.ARPA.
+            86400   NS      C.ISI.EDU.
+
+    SRI-NIC.ARPA.   A       26.0.0.73
+                    A       10.0.0.51
+                    MX      0 SRI-NIC.ARPA.
+                    HINFO   DEC-2060 TOPS20
+
+    ACC.ARPA.       A       26.6.0.65
+                    HINFO   PDP-11/70 UNIX
+                    MX      10 ACC.ARPA.
+
+    USC-ISIC.ARPA.  CNAME   C.ISI.EDU.
+
+    73.0.0.26.IN-ADDR.ARPA.  PTR    SRI-NIC.ARPA.
+    65.0.6.26.IN-ADDR.ARPA.  PTR    ACC.ARPA.
+    51.0.0.10.IN-ADDR.ARPA.  PTR    SRI-NIC.ARPA.
+    52.0.0.10.IN-ADDR.ARPA.  PTR    C.ISI.EDU.
+
+
+
+Mockapetris                                                    [Page 37]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+    103.0.3.26.IN-ADDR.ARPA. PTR    A.ISI.EDU.
+
+    A.ISI.EDU. 86400 A      26.3.0.103
+    C.ISI.EDU. 86400 A      10.0.0.52
+
+This data is represented as it would be in a master file.  Most RRs are
+single line entries; the sole exception here is the SOA RR, which uses
+"(" to start a multi-line RR and ")" to show the end of a multi-line RR.
+Since the class of all RRs in a zone must be the same, only the first RR
+in a zone need specify the class.  When a name server loads a zone, it
+forces the TTL of all authoritative RRs to be at least the MINIMUM field
+of the SOA, here 86400 seconds, or one day.  The NS RRs marking
+delegation of the MIL and EDU domains, together with the glue RRs for
+the servers host addresses, are not part of the authoritative data in
+the zone, and hence have explicit TTLs.
+
+Four RRs are attached to the root node: the SOA which describes the root
+zone and the 3 NS RRs which list the name servers for the root.  The
+data in the SOA RR describes the management of the zone.  The zone data
+is maintained on host SRI-NIC.ARPA, and the responsible party for the
+zone is HOSTMASTER@SRI-NIC.ARPA.  A key item in the SOA is the 86400
+second minimum TTL, which means that all authoritative data in the zone
+has at least that TTL, although higher values may be explicitly
+specified.
+
+The NS RRs for the MIL and EDU domains mark the boundary between the
+root zone and the MIL and EDU zones.  Note that in this example, the
+lower zones happen to be supported by name servers which also support
+the root zone.
+
+The master file for the EDU zone might be stated relative to the origin
+EDU.  The zone data for the EDU domain might be:
+
+    EDU.  IN SOA SRI-NIC.ARPA. HOSTMASTER.SRI-NIC.ARPA. (
+                            870729 ;serial
+                            1800 ;refresh every 30 minutes
+                            300 ;retry every 5 minutes
+                            604800 ;expire after a week
+                            86400 ;minimum of a day
+                            )
+                    NS SRI-NIC.ARPA.
+                    NS C.ISI.EDU.
+
+    UCI 172800 NS ICS.UCI
+                    172800 NS ROME.UCI
+    ICS.UCI 172800 A 192.5.19.1
+    ROME.UCI 172800 A 192.5.19.31
+
+
+
+
+Mockapetris                                                    [Page 38]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+    ISI 172800 NS VAXA.ISI
+                    172800 NS A.ISI
+                    172800 NS VENERA.ISI.EDU.
+    VAXA.ISI 172800 A 10.2.0.27
+                    172800 A 128.9.0.33
+    VENERA.ISI.EDU. 172800 A 10.1.0.52
+                    172800 A 128.9.0.32
+    A.ISI 172800 A 26.3.0.103
+
+    UDEL.EDU.  172800 NS LOUIE.UDEL.EDU.
+                    172800 NS UMN-REI-UC.ARPA.
+    LOUIE.UDEL.EDU. 172800 A 10.0.0.96
+                    172800 A 192.5.39.3
+
+    YALE.EDU.  172800 NS YALE.ARPA.
+    YALE.EDU.  172800 NS YALE-BULLDOG.ARPA.
+
+    MIT.EDU.  43200 NS XX.LCS.MIT.EDU.
+                      43200 NS ACHILLES.MIT.EDU.
+    XX.LCS.MIT.EDU.  43200 A 10.0.0.44
+    ACHILLES.MIT.EDU. 43200 A 18.72.0.8
+
+Note the use of relative names here.  The owner name for the ISI.EDU. is
+stated using a relative name, as are two of the name server RR contents.
+Relative and absolute domain names may be freely intermixed in a master
+
+6.2. Example standard queries
+
+The following queries and responses illustrate name server behavior.
+Unless otherwise noted, the queries do not have recursion desired (RD)
+in the header.  Note that the answers to non-recursive queries do depend
+on the server being asked, but do not depend on the identity of the
+requester.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mockapetris                                                    [Page 39]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+6.2.1. QNAME=SRI-NIC.ARPA, QTYPE=A
+
+The query would look like:
+
+               +---------------------------------------------------+
+    Header     | OPCODE=SQUERY                                     |
+               +---------------------------------------------------+
+    Question   | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=A           |
+               +---------------------------------------------------+
+    Answer     | <empty>                                           |
+               +---------------------------------------------------+
+    Authority  | <empty>                                           |
+               +---------------------------------------------------+
+    Additional | <empty>                                           |
+               +---------------------------------------------------+
+
+The response from C.ISI.EDU would be:
+
+               +---------------------------------------------------+
+    Header     | OPCODE=SQUERY, RESPONSE, AA                       |
+               +---------------------------------------------------+
+    Question   | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=A           |
+               +---------------------------------------------------+
+    Answer     | SRI-NIC.ARPA. 86400 IN A 26.0.0.73                |
+               |               86400 IN A 10.0.0.51                |
+               +---------------------------------------------------+
+    Authority  | <empty>                                           |
+               +---------------------------------------------------+
+    Additional | <empty>                                           |
+               +---------------------------------------------------+
+
+The header of the response looks like the header of the query, except
+that the RESPONSE bit is set, indicating that this message is a
+response, not a query, and the Authoritative Answer (AA) bit is set
+indicating that the address RRs in the answer section are from
+authoritative data.  The question section of the response matches the
+question section of the query.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mockapetris                                                    [Page 40]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+If the same query was sent to some other server which was not
+authoritative for SRI-NIC.ARPA, the response might be:
+
+               +---------------------------------------------------+
+    Header     | OPCODE=SQUERY,RESPONSE                            |
+               +---------------------------------------------------+
+    Question   | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=A           |
+               +---------------------------------------------------+
+    Answer     | SRI-NIC.ARPA. 1777 IN A 10.0.0.51                 |
+               |               1777 IN A 26.0.0.73                 |
+               +---------------------------------------------------+
+    Authority  | <empty>                                           |
+               +---------------------------------------------------+
+    Additional | <empty>                                           |
+               +---------------------------------------------------+
+
+This response is different from the previous one in two ways: the header
+does not have AA set, and the TTLs are different.  The inference is that
+the data did not come from a zone, but from a cache.  The difference
+between the authoritative TTL and the TTL here is due to aging of the
+data in a cache.  The difference in ordering of the RRs in the answer
+section is not significant.
+
+6.2.2. QNAME=SRI-NIC.ARPA, QTYPE=*
+
+A query similar to the previous one, but using a QTYPE of *, would
+receive the following response from C.ISI.EDU:
+
+               +---------------------------------------------------+
+    Header     | OPCODE=SQUERY, RESPONSE, AA                       |
+               +---------------------------------------------------+
+    Question   | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=*           |
+               +---------------------------------------------------+
+    Answer     | SRI-NIC.ARPA. 86400 IN  A     26.0.0.73           |
+               |                         A     10.0.0.51           |
+               |                         MX    0 SRI-NIC.ARPA.     |
+               |                         HINFO DEC-2060 TOPS20     |
+               +---------------------------------------------------+
+    Authority  | <empty>                                           |
+               +---------------------------------------------------+
+    Additional | <empty>                                           |
+               +---------------------------------------------------+
+
+
+
+
+
+
+
+
+
+Mockapetris                                                    [Page 41]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+If a similar query was directed to two name servers which are not
+authoritative for SRI-NIC.ARPA, the responses might be:
+
+               +---------------------------------------------------+
+    Header     | OPCODE=SQUERY, RESPONSE                           |
+               +---------------------------------------------------+
+    Question   | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=*           |
+               +---------------------------------------------------+
+    Answer     | SRI-NIC.ARPA. 12345 IN     A       26.0.0.73      |
+               |                            A       10.0.0.51      |
+               +---------------------------------------------------+
+    Authority  | <empty>                                           |
+               +---------------------------------------------------+
+    Additional | <empty>                                           |
+               +---------------------------------------------------+
+
+and
+
+               +---------------------------------------------------+
+    Header     | OPCODE=SQUERY, RESPONSE                           |
+               +---------------------------------------------------+
+    Question   | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=*           |
+               +---------------------------------------------------+
+    Answer     | SRI-NIC.ARPA. 1290 IN HINFO  DEC-2060 TOPS20      |
+               +---------------------------------------------------+
+    Authority  | <empty>                                           |
+               +---------------------------------------------------+
+    Additional | <empty>                                           |
+               +---------------------------------------------------+
+
+Neither of these answers have AA set, so neither response comes from
+authoritative data.  The different contents and different TTLs suggest
+that the two servers cached data at different times, and that the first
+server cached the response to a QTYPE=A query and the second cached the
+response to a HINFO query.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mockapetris                                                    [Page 42]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+6.2.3. QNAME=SRI-NIC.ARPA, QTYPE=MX
+
+This type of query might be result from a mailer trying to look up
+routing information for the mail destination HOSTMASTER@SRI-NIC.ARPA.
+The response from C.ISI.EDU would be:
+
+               +---------------------------------------------------+
+    Header     | OPCODE=SQUERY, RESPONSE, AA                       |
+               +---------------------------------------------------+
+    Question   | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=MX          |
+               +---------------------------------------------------+
+    Answer     | SRI-NIC.ARPA. 86400 IN     MX      0 SRI-NIC.ARPA.|
+               +---------------------------------------------------+
+    Authority  | <empty>                                           |
+               +---------------------------------------------------+
+    Additional | SRI-NIC.ARPA. 86400 IN     A       26.0.0.73      |
+               |                            A       10.0.0.51      |
+               +---------------------------------------------------+
+
+This response contains the MX RR in the answer section of the response.
+The additional section contains the address RRs because the name server
+at C.ISI.EDU guesses that the requester will need the addresses in order
+to properly use the information carried by the MX.
+
+6.2.4. QNAME=SRI-NIC.ARPA, QTYPE=NS
+
+C.ISI.EDU would reply to this query with:
+
+               +---------------------------------------------------+
+    Header     | OPCODE=SQUERY, RESPONSE, AA                       |
+               +---------------------------------------------------+
+    Question   | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=NS          |
+               +---------------------------------------------------+
+    Answer     | <empty>                                           |
+               +---------------------------------------------------+
+    Authority  | <empty>                                           |
+               +---------------------------------------------------+
+    Additional | <empty>                                           |
+               +---------------------------------------------------+
+
+The only difference between the response and the query is the AA and
+RESPONSE bits in the header.  The interpretation of this response is
+that the server is authoritative for the name, and the name exists, but
+no RRs of type NS are present there.
+
+6.2.5. QNAME=SIR-NIC.ARPA, QTYPE=A
+
+If a user mistyped a host name, we might see this type of query.
+
+
+
+Mockapetris                                                    [Page 43]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+C.ISI.EDU would answer it with:
+
+               +---------------------------------------------------+
+    Header     | OPCODE=SQUERY, RESPONSE, AA, RCODE=NE             |
+               +---------------------------------------------------+
+    Question   | QNAME=SIR-NIC.ARPA., QCLASS=IN, QTYPE=A           |
+               +---------------------------------------------------+
+    Answer     | <empty>                                           |
+               +---------------------------------------------------+
+    Authority  | . SOA SRI-NIC.ARPA. HOSTMASTER.SRI-NIC.ARPA.      |
+               |       870611 1800 300 604800 86400                |
+               +---------------------------------------------------+
+    Additional | <empty>                                           |
+               +---------------------------------------------------+
+
+This response states that the name does not exist.  This condition is
+signalled in the response code (RCODE) section of the header.
+
+The SOA RR in the authority section is the optional negative caching
+information which allows the resolver using this response to assume that
+the name will not exist for the SOA MINIMUM (86400) seconds.
+
+6.2.6. QNAME=BRL.MIL, QTYPE=A
+
+If this query is sent to C.ISI.EDU, the reply would be:
+
+               +---------------------------------------------------+
+    Header     | OPCODE=SQUERY, RESPONSE                           |
+               +---------------------------------------------------+
+    Question   | QNAME=BRL.MIL, QCLASS=IN, QTYPE=A                 |
+               +---------------------------------------------------+
+    Answer     | <empty>                                           |
+               +---------------------------------------------------+
+    Authority  | MIL.             86400 IN NS       SRI-NIC.ARPA.  |
+               |                  86400    NS       A.ISI.EDU.     |
+               +---------------------------------------------------+
+    Additional | A.ISI.EDU.                A        26.3.0.103     |
+               | SRI-NIC.ARPA.             A        26.0.0.73      |
+               |                           A        10.0.0.51      |
+               +---------------------------------------------------+
+
+This response has an empty answer section, but is not authoritative, so
+it is a referral.  The name server on C.ISI.EDU, realizing that it is
+not authoritative for the MIL domain, has referred the requester to
+servers on A.ISI.EDU and SRI-NIC.ARPA, which it knows are authoritative
+for the MIL domain.
+
+
+
+
+
+Mockapetris                                                    [Page 44]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+6.2.7. QNAME=USC-ISIC.ARPA, QTYPE=A
+
+The response to this query from A.ISI.EDU would be:
+
+               +---------------------------------------------------+
+    Header     | OPCODE=SQUERY, RESPONSE, AA                       |
+               +---------------------------------------------------+
+    Question   | QNAME=USC-ISIC.ARPA., QCLASS=IN, QTYPE=A          |
+               +---------------------------------------------------+
+    Answer     | USC-ISIC.ARPA. 86400 IN CNAME      C.ISI.EDU.     |
+               | C.ISI.EDU.     86400 IN A          10.0.0.52      |
+               +---------------------------------------------------+
+    Authority  | <empty>                                           |
+               +---------------------------------------------------+
+    Additional | <empty>                                           |
+               +---------------------------------------------------+
+
+Note that the AA bit in the header guarantees that the data matching
+QNAME is authoritative, but does not say anything about whether the data
+for C.ISI.EDU is authoritative.  This complete reply is possible because
+A.ISI.EDU happens to be authoritative for both the ARPA domain where
+USC-ISIC.ARPA is found and the ISI.EDU domain where C.ISI.EDU data is
+found.
+
+If the same query was sent to C.ISI.EDU, its response might be the same
+as shown above if it had its own address in its cache, but might also
+be:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mockapetris                                                    [Page 45]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+               +---------------------------------------------------+
+    Header     | OPCODE=SQUERY, RESPONSE, AA                       |
+               +---------------------------------------------------+
+    Question   | QNAME=USC-ISIC.ARPA., QCLASS=IN, QTYPE=A          |
+               +---------------------------------------------------+
+    Answer     | USC-ISIC.ARPA.   86400 IN CNAME   C.ISI.EDU.      |
+               +---------------------------------------------------+
+    Authority  | ISI.EDU.        172800 IN NS      VAXA.ISI.EDU.   |
+               |                           NS      A.ISI.EDU.      |
+               |                           NS      VENERA.ISI.EDU. |
+               +---------------------------------------------------+
+    Additional | VAXA.ISI.EDU.   172800    A       10.2.0.27       |
+               |                 172800    A       128.9.0.33      |
+               | VENERA.ISI.EDU. 172800    A       10.1.0.52       |
+               |                 172800    A       128.9.0.32      |
+               | A.ISI.EDU.      172800    A       26.3.0.103      |
+               +---------------------------------------------------+
+
+This reply contains an authoritative reply for the alias USC-ISIC.ARPA,
+plus a referral to the name servers for ISI.EDU.  This sort of reply
+isn't very likely given that the query is for the host name of the name
+server being asked, but would be common for other aliases.
+
+6.2.8. QNAME=USC-ISIC.ARPA, QTYPE=CNAME
+
+If this query is sent to either A.ISI.EDU or C.ISI.EDU, the reply would
+be:
+
+               +---------------------------------------------------+
+    Header     | OPCODE=SQUERY, RESPONSE, AA                       |
+               +---------------------------------------------------+
+    Question   | QNAME=USC-ISIC.ARPA., QCLASS=IN, QTYPE=A          |
+               +---------------------------------------------------+
+    Answer     | USC-ISIC.ARPA. 86400 IN CNAME      C.ISI.EDU.     |
+               +---------------------------------------------------+
+    Authority  | <empty>                                           |
+               +---------------------------------------------------+
+    Additional | <empty>                                           |
+               +---------------------------------------------------+
+
+Because QTYPE=CNAME, the CNAME RR itself answers the query, and the name
+server doesn't attempt to look up anything for C.ISI.EDU.  (Except
+possibly for the additional section.)
+
+6.3. Example resolution
+
+The following examples illustrate the operations a resolver must perform
+for its client.  We assume that the resolver is starting without a
+
+
+
+Mockapetris                                                    [Page 46]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+cache, as might be the case after system boot.  We further assume that
+the system is not one of the hosts in the data and that the host is
+located somewhere on net 26, and that its safety belt (SBELT) data
+structure has the following information:
+
+    Match count = -1
+    SRI-NIC.ARPA.   26.0.0.73       10.0.0.51
+    A.ISI.EDU.      26.3.0.103
+
+This information specifies servers to try, their addresses, and a match
+count of -1, which says that the servers aren't very close to the
+target.  Note that the -1 isn't supposed to be an accurate closeness
+measure, just a value so that later stages of the algorithm will work.
+
+The following examples illustrate the use of a cache, so each example
+assumes that previous requests have completed.
+
+6.3.1. Resolve MX for ISI.EDU.
+
+Suppose the first request to the resolver comes from the local mailer,
+which has mail for PVM@ISI.EDU.  The mailer might then ask for type MX
+RRs for the domain name ISI.EDU.
+
+The resolver would look in its cache for MX RRs at ISI.EDU, but the
+empty cache wouldn't be helpful.  The resolver would recognize that it
+needed to query foreign servers and try to determine the best servers to
+query.  This search would look for NS RRs for the domains ISI.EDU, EDU,
+and the root.  These searches of the cache would also fail.  As a last
+resort, the resolver would use the information from the SBELT, copying
+it into its SLIST structure.
+
+At this point the resolver would need to pick one of the three available
+addresses to try.  Given that the resolver is on net 26, it should
+choose either 26.0.0.73 or 26.3.0.103 as its first choice.  It would
+then send off a query of the form:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mockapetris                                                    [Page 47]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+               +---------------------------------------------------+
+    Header     | OPCODE=SQUERY                                     |
+               +---------------------------------------------------+
+    Question   | QNAME=ISI.EDU., QCLASS=IN, QTYPE=MX               |
+               +---------------------------------------------------+
+    Answer     | <empty>                                           |
+               +---------------------------------------------------+
+    Authority  | <empty>                                           |
+               +---------------------------------------------------+
+    Additional | <empty>                                           |
+               +---------------------------------------------------+
+
+The resolver would then wait for a response to its query or a timeout.
+If the timeout occurs, it would try different servers, then different
+addresses of the same servers, lastly retrying addresses already tried.
+It might eventually receive a reply from SRI-NIC.ARPA:
+
+               +---------------------------------------------------+
+    Header     | OPCODE=SQUERY, RESPONSE                           |
+               +---------------------------------------------------+
+    Question   | QNAME=ISI.EDU., QCLASS=IN, QTYPE=MX               |
+               +---------------------------------------------------+
+    Answer     | <empty>                                           |
+               +---------------------------------------------------+
+    Authority  | ISI.EDU.        172800 IN NS       VAXA.ISI.EDU.  |
+               |                           NS       A.ISI.EDU.     |
+               |                           NS       VENERA.ISI.EDU.|
+               +---------------------------------------------------+
+    Additional | VAXA.ISI.EDU.   172800    A        10.2.0.27      |
+               |                 172800    A        128.9.0.33     |
+               | VENERA.ISI.EDU. 172800    A        10.1.0.52      |
+               |                 172800    A        128.9.0.32     |
+               | A.ISI.EDU.      172800    A        26.3.0.103     |
+               +---------------------------------------------------+
+
+The resolver would notice that the information in the response gave a
+closer delegation to ISI.EDU than its existing SLIST (since it matches
+three labels).  The resolver would then cache the information in this
+response and use it to set up a new SLIST:
+
+    Match count = 3
+    A.ISI.EDU.      26.3.0.103
+    VAXA.ISI.EDU.   10.2.0.27       128.9.0.33
+    VENERA.ISI.EDU. 10.1.0.52       128.9.0.32
+
+A.ISI.EDU appears on this list as well as the previous one, but that is
+purely coincidental.  The resolver would again start transmitting and
+waiting for responses.  Eventually it would get an answer:
+
+
+
+Mockapetris                                                    [Page 48]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+               +---------------------------------------------------+
+    Header     | OPCODE=SQUERY, RESPONSE, AA                       |
+               +---------------------------------------------------+
+    Question   | QNAME=ISI.EDU., QCLASS=IN, QTYPE=MX               |
+               +---------------------------------------------------+
+    Answer     | ISI.EDU.                MX 10 VENERA.ISI.EDU.     |
+               |                         MX 20 VAXA.ISI.EDU.       |
+               +---------------------------------------------------+
+    Authority  | <empty>                                           |
+               +---------------------------------------------------+
+    Additional | VAXA.ISI.EDU.   172800  A  10.2.0.27              |
+               |                 172800  A  128.9.0.33             |
+               | VENERA.ISI.EDU. 172800  A  10.1.0.52              |
+               |                 172800  A  128.9.0.32             |
+               +---------------------------------------------------+
+
+The resolver would add this information to its cache, and return the MX
+RRs to its client.
+
+6.3.2. Get the host name for address 26.6.0.65
+
+The resolver would translate this into a request for PTR RRs for
+65.0.6.26.IN-ADDR.ARPA.  This information is not in the cache, so the
+resolver would look for foreign servers to ask.  No servers would match,
+so it would use SBELT again.  (Note that the servers for the ISI.EDU
+domain are in the cache, but ISI.EDU is not an ancestor of
+65.0.6.26.IN-ADDR.ARPA, so the SBELT is used.)
+
+Since this request is within the authoritative data of both servers in
+SBELT, eventually one would return:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mockapetris                                                    [Page 49]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+               +---------------------------------------------------+
+    Header     | OPCODE=SQUERY, RESPONSE, AA                       |
+               +---------------------------------------------------+
+    Question   | QNAME=65.0.6.26.IN-ADDR.ARPA.,QCLASS=IN,QTYPE=PTR |
+               +---------------------------------------------------+
+    Answer     | 65.0.6.26.IN-ADDR.ARPA.    PTR     ACC.ARPA.      |
+               +---------------------------------------------------+
+    Authority  | <empty>                                           |
+               +---------------------------------------------------+
+    Additional | <empty>                                           |
+               +---------------------------------------------------+
+
+6.3.3. Get the host address of poneria.ISI.EDU
+
+This request would translate into a type A request for poneria.ISI.EDU.
+The resolver would not find any cached data for this name, but would
+find the NS RRs in the cache for ISI.EDU when it looks for foreign
+servers to ask.  Using this data, it would construct a SLIST of the
+form:
+
+    Match count = 3
+
+    A.ISI.EDU.      26.3.0.103
+    VAXA.ISI.EDU.   10.2.0.27       128.9.0.33
+    VENERA.ISI.EDU. 10.1.0.52
+
+A.ISI.EDU is listed first on the assumption that the resolver orders its
+choices by preference, and A.ISI.EDU is on the same network.
+
+One of these servers would answer the query.
+
+7. REFERENCES and BIBLIOGRAPHY
+
+[Dyer 87]       Dyer, S., and F. Hsu, "Hesiod", Project Athena
+                Technical Plan - Name Service, April 1987, version 1.9.
+
+                Describes the fundamentals of the Hesiod name service.
+
+[IEN-116]       J. Postel, "Internet Name Server", IEN-116,
+                USC/Information Sciences Institute, August 1979.
+
+                A name service obsoleted by the Domain Name System, but
+                still in use.
+
+
+
+
+
+
+
+
+Mockapetris                                                    [Page 50]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+[Quarterman 86] Quarterman, J., and J. Hoskins, "Notable Computer
+                Networks",Communications of the ACM, October 1986,
+                volume 29, number 10.
+
+[RFC-742]       K. Harrenstien, "NAME/FINGER", RFC-742, Network
+                Information Center, SRI International, December 1977.
+
+[RFC-768]       J. Postel, "User Datagram Protocol", RFC-768,
+                USC/Information Sciences Institute, August 1980.
+
+[RFC-793]       J. Postel, "Transmission Control Protocol", RFC-793,
+                USC/Information Sciences Institute, September 1981.
+
+[RFC-799]       D. Mills, "Internet Name Domains", RFC-799, COMSAT,
+                September 1981.
+
+                Suggests introduction of a hierarchy in place of a flat
+                name space for the Internet.
+
+[RFC-805]       J. Postel, "Computer Mail Meeting Notes", RFC-805,
+                USC/Information Sciences Institute, February 1982.
+
+[RFC-810]       E. Feinler, K. Harrenstien, Z. Su, and V. White, "DOD
+                Internet Host Table Specification", RFC-810, Network
+                Information Center, SRI International, March 1982.
+
+                Obsolete.  See RFC-952.
+
+[RFC-811]       K. Harrenstien, V. White, and E. Feinler, "Hostnames
+                Server", RFC-811, Network Information Center, SRI
+                International, March 1982.
+
+                Obsolete.  See RFC-953.
+
+[RFC-812]       K. Harrenstien, and V. White, "NICNAME/WHOIS", RFC-812,
+                Network Information Center, SRI International, March
+                1982.
+
+[RFC-819]       Z. Su, and J. Postel, "The Domain Naming Convention for
+                Internet User Applications", RFC-819, Network
+                Information Center, SRI International, August 1982.
+
+                Early thoughts on the design of the domain system.
+                Current implementation is completely different.
+
+[RFC-821]       J. Postel, "Simple Mail Transfer Protocol", RFC-821,
+                USC/Information Sciences Institute, August 1980.
+
+
+
+
+Mockapetris                                                    [Page 51]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+[RFC-830]       Z. Su, "A Distributed System for Internet Name Service",
+                RFC-830, Network Information Center, SRI International,
+                October 1982.
+
+                Early thoughts on the design of the domain system.
+                Current implementation is completely different.
+
+[RFC-882]       P. Mockapetris, "Domain names - Concepts and
+                Facilities," RFC-882, USC/Information Sciences
+                Institute, November 1983.
+
+                Superceeded by this memo.
+
+[RFC-883]       P. Mockapetris, "Domain names - Implementation and
+                Specification," RFC-883, USC/Information Sciences
+                Institute, November 1983.
+
+                Superceeded by this memo.
+
+[RFC-920]       J. Postel and J. Reynolds, "Domain Requirements",
+                RFC-920, USC/Information Sciences Institute
+                October 1984.
+
+                Explains the naming scheme for top level domains.
+
+[RFC-952]       K. Harrenstien, M. Stahl, E. Feinler, "DoD Internet Host
+                Table Specification", RFC-952, SRI, October 1985.
+
+                Specifies the format of HOSTS.TXT, the host/address
+                table replaced by the DNS.
+
+[RFC-953]       K. Harrenstien, M. Stahl, E. Feinler, "HOSTNAME Server",
+                RFC-953, SRI, October 1985.
+
+                This RFC contains the official specification of the
+                hostname server protocol, which is obsoleted by the DNS.
+                This TCP based protocol accesses information stored in
+                the RFC-952 format, and is used to obtain copies of the
+                host table.
+
+[RFC-973]       P. Mockapetris, "Domain System Changes and
+                Observations", RFC-973, USC/Information Sciences
+                Institute, January 1986.
+
+                Describes changes to RFC-882 and RFC-883 and reasons for
+                them.  Now obsolete.
+
+
+
+
+
+Mockapetris                                                    [Page 52]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+[RFC-974]       C. Partridge, "Mail routing and the domain system",
+                RFC-974, CSNET CIC BBN Labs, January 1986.
+
+                Describes the transition from HOSTS.TXT based mail
+                addressing to the more powerful MX system used with the
+                domain system.
+
+[RFC-1001]      NetBIOS Working Group, "Protocol standard for a NetBIOS
+                service on a TCP/UDP transport: Concepts and Methods",
+                RFC-1001, March 1987.
+
+                This RFC and RFC-1002 are a preliminary design for
+                NETBIOS on top of TCP/IP which proposes to base NetBIOS
+                name service on top of the DNS.
+
+[RFC-1002]      NetBIOS Working Group, "Protocol standard for a NetBIOS
+                service on a TCP/UDP transport: Detailed
+                Specifications", RFC-1002, March 1987.
+
+[RFC-1010]      J. Reynolds and J. Postel, "Assigned Numbers", RFC-1010,
+                USC/Information Sciences Institute, May 1987
+
+                Contains socket numbers and mnemonics for host names,
+                operating systems, etc.
+
+[RFC-1031]      W. Lazear, "MILNET Name Domain Transition", RFC-1031,
+                November 1987.
+
+                Describes a plan for converting the MILNET to the DNS.
+
+[RFC-1032]      M. K. Stahl, "Establishing a Domain - Guidelines for
+                Administrators", RFC-1032, November 1987.
+
+                Describes the registration policies used by the NIC to
+                administer the top level domains and delegate subzones.
+
+[RFC-1033]      M. K. Lottor, "Domain Administrators Operations Guide",
+                RFC-1033, November 1987.
+
+                A cookbook for domain administrators.
+
+[Solomon 82]    M. Solomon, L. Landweber, and D. Neuhengen, "The CSNET
+                Name Server", Computer Networks, vol 6, nr 3, July 1982.
+
+                Describes a name service for CSNET which is independent
+                from the DNS and DNS use in the CSNET.
+
+
+
+
+
+Mockapetris                                                    [Page 53]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+Index
+
+          A   12
+          Absolute names   8
+          Aliases   14, 31
+          Authority   6
+          AXFR   17
+
+          Case of characters   7
+          CH   12
+          CNAME   12, 13, 31
+          Completion queries   18
+
+          Domain name   6, 7
+
+          Glue RRs   20
+
+          HINFO   12
+
+          IN   12
+          Inverse queries   16
+          Iterative   4
+
+          Label   7
+
+          Mailbox names   9
+          MX   12
+
+          Name error   27, 36
+          Name servers   5, 17
+          NE   30
+          Negative caching   44
+          NS   12
+
+          Opcode   16
+
+          PTR   12
+
+          QCLASS   16
+          QTYPE   16
+
+          RDATA   13
+          Recursive   4
+          Recursive service   22
+          Relative names   7
+          Resolvers   6
+          RR   12
+
+
+
+
+Mockapetris                                                    [Page 54]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+          Safety belt   33
+          Sections   16
+          SOA   12
+          Standard queries   22
+
+          Status queries   18
+          Stub resolvers   32
+
+          TTL   12, 13
+
+          Wildcards   25
+
+          Zone transfers   28
+          Zones   19
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mockapetris                                                    [Page 55]
+
diff --git a/doc/rfc/rfc1035.txt b/doc/rfc/rfc1035.txt
new file mode 100644
index 0000000..b1a9bf5
--- /dev/null
+++ b/doc/rfc/rfc1035.txt
@@ -0,0 +1,3077 @@
+Network Working Group                                     P. Mockapetris
+Request for Comments: 1035                                           ISI
+                                                           November 1987
+Obsoletes: RFCs 882, 883, 973
+
+            DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION
+
+
+1. STATUS OF THIS MEMO
+
+This RFC describes the details of the domain system and protocol, and
+assumes that the reader is familiar with the concepts discussed in a
+companion RFC, "Domain Names - Concepts and Facilities" [RFC-1034].
+
+The domain system is a mixture of functions and data types which are an
+official protocol and functions and data types which are still
+experimental.  Since the domain system is intentionally extensible, new
+data types and experimental behavior should always be expected in parts
+of the system beyond the official protocol.  The official protocol parts
+include standard queries, responses and the Internet class RR data
+formats (e.g., host addresses).  Since the previous RFC set, several
+definitions have changed, so some previous definitions are obsolete.
+
+Experimental or obsolete features are clearly marked in these RFCs, and
+such information should be used with caution.
+
+The reader is especially cautioned not to depend on the values which
+appear in examples to be current or complete, since their purpose is
+primarily pedagogical.  Distribution of this memo is unlimited.
+
+                           Table of Contents
+
+  1. STATUS OF THIS MEMO                                              1
+  2. INTRODUCTION                                                     3
+      2.1. Overview                                                   3
+      2.2. Common configurations                                      4
+      2.3. Conventions                                                7
+          2.3.1. Preferred name syntax                                7
+          2.3.2. Data Transmission Order                              8
+          2.3.3. Character Case                                       9
+          2.3.4. Size limits                                         10
+  3. DOMAIN NAME SPACE AND RR DEFINITIONS                            10
+      3.1. Name space definitions                                    10
+      3.2. RR definitions                                            11
+          3.2.1. Format                                              11
+          3.2.2. TYPE values                                         12
+          3.2.3. QTYPE values                                        12
+          3.2.4. CLASS values                                        13
+
+
+
+Mockapetris                                                     [Page 1]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+          3.2.5. QCLASS values                                       13
+      3.3. Standard RRs                                              13
+          3.3.1. CNAME RDATA format                                  14
+          3.3.2. HINFO RDATA format                                  14
+          3.3.3. MB RDATA format (EXPERIMENTAL)                      14
+          3.3.4. MD RDATA format (Obsolete)                          15
+          3.3.5. MF RDATA format (Obsolete)                          15
+          3.3.6. MG RDATA format (EXPERIMENTAL)                      16
+          3.3.7. MINFO RDATA format (EXPERIMENTAL)                   16
+          3.3.8. MR RDATA format (EXPERIMENTAL)                      17
+          3.3.9. MX RDATA format                                     17
+          3.3.10. NULL RDATA format (EXPERIMENTAL)                   17
+          3.3.11. NS RDATA format                                    18
+          3.3.12. PTR RDATA format                                   18
+          3.3.13. SOA RDATA format                                   19
+          3.3.14. TXT RDATA format                                   20
+      3.4. ARPA Internet specific RRs                                20
+          3.4.1. A RDATA format                                      20
+          3.4.2. WKS RDATA format                                    21
+      3.5. IN-ADDR.ARPA domain                                       22
+      3.6. Defining new types, classes, and special namespaces       24
+  4. MESSAGES                                                        25
+      4.1. Format                                                    25
+          4.1.1. Header section format                               26
+          4.1.2. Question section format                             28
+          4.1.3. Resource record format                              29
+          4.1.4. Message compression                                 30
+      4.2. Transport                                                 32
+          4.2.1. UDP usage                                           32
+          4.2.2. TCP usage                                           32
+  5. MASTER FILES                                                    33
+      5.1. Format                                                    33
+      5.2. Use of master files to define zones                       35
+      5.3. Master file example                                       36
+  6. NAME SERVER IMPLEMENTATION                                      37
+      6.1. Architecture                                              37
+          6.1.1. Control                                             37
+          6.1.2. Database                                            37
+          6.1.3. Time                                                39
+      6.2. Standard query processing                                 39
+      6.3. Zone refresh and reload processing                        39
+      6.4. Inverse queries (Optional)                                40
+          6.4.1. The contents of inverse queries and responses       40
+          6.4.2. Inverse query and response example                  41
+          6.4.3. Inverse query processing                            42
+
+
+
+
+
+
+Mockapetris                                                     [Page 2]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+      6.5. Completion queries and responses                          42
+  7. RESOLVER IMPLEMENTATION                                         43
+      7.1. Transforming a user request into a query                  43
+      7.2. Sending the queries                                       44
+      7.3. Processing responses                                      46
+      7.4. Using the cache                                           47
+  8. MAIL SUPPORT                                                    47
+      8.1. Mail exchange binding                                     48
+      8.2. Mailbox binding (Experimental)                            48
+  9. REFERENCES and BIBLIOGRAPHY                                     50
+  Index                                                              54
+
+2. INTRODUCTION
+
+2.1. Overview
+
+The goal of domain names is to provide a mechanism for naming resources
+in such a way that the names are usable in different hosts, networks,
+protocol families, internets, and administrative organizations.
+
+From the user's point of view, domain names are useful as arguments to a
+local agent, called a resolver, which retrieves information associated
+with the domain name.  Thus a user might ask for the host address or
+mail information associated with a particular domain name.  To enable
+the user to request a particular type of information, an appropriate
+query type is passed to the resolver with the domain name.  To the user,
+the domain tree is a single information space; the resolver is
+responsible for hiding the distribution of data among name servers from
+the user.
+
+From the resolver's point of view, the database that makes up the domain
+space is distributed among various name servers.  Different parts of the
+domain space are stored in different name servers, although a particular
+data item will be stored redundantly in two or more name servers.  The
+resolver starts with knowledge of at least one name server.  When the
+resolver processes a user query it asks a known name server for the
+information; in return, the resolver either receives the desired
+information or a referral to another name server.  Using these
+referrals, resolvers learn the identities and contents of other name
+servers.  Resolvers are responsible for dealing with the distribution of
+the domain space and dealing with the effects of name server failure by
+consulting redundant databases in other servers.
+
+Name servers manage two kinds of data.  The first kind of data held in
+sets called zones; each zone is the complete database for a particular
+"pruned" subtree of the domain space.  This data is called
+authoritative.  A name server periodically checks to make sure that its
+zones are up to date, and if not, obtains a new copy of updated zones
+
+
+
+Mockapetris                                                     [Page 3]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+from master files stored locally or in another name server.  The second
+kind of data is cached data which was acquired by a local resolver.
+This data may be incomplete, but improves the performance of the
+retrieval process when non-local data is repeatedly accessed.  Cached
+data is eventually discarded by a timeout mechanism.
+
+This functional structure isolates the problems of user interface,
+failure recovery, and distribution in the resolvers and isolates the
+database update and refresh problems in the name servers.
+
+2.2. Common configurations
+
+A host can participate in the domain name system in a number of ways,
+depending on whether the host runs programs that retrieve information
+from the domain system, name servers that answer queries from other
+hosts, or various combinations of both functions.  The simplest, and
+perhaps most typical, configuration is shown below:
+
+                 Local Host                        |  Foreign
+                                                   |
+    +---------+               +----------+         |  +--------+
+    |         | user queries  |          |queries  |  |        |
+    |  User   |-------------->|          |---------|->|Foreign |
+    | Program |               | Resolver |         |  |  Name  |
+    |         |<--------------|          |<--------|--| Server |
+    |         | user responses|          |responses|  |        |
+    +---------+               +----------+         |  +--------+
+                                |     A            |
+                cache additions |     | references |
+                                V     |            |
+                              +----------+         |
+                              |  cache   |         |
+                              +----------+         |
+
+User programs interact with the domain name space through resolvers; the
+format of user queries and user responses is specific to the host and
+its operating system.  User queries will typically be operating system
+calls, and the resolver and its cache will be part of the host operating
+system.  Less capable hosts may choose to implement the resolver as a
+subroutine to be linked in with every program that needs its services.
+Resolvers answer user queries with information they acquire via queries
+to foreign name servers and the local cache.
+
+Note that the resolver may have to make several queries to several
+different foreign name servers to answer a particular user query, and
+hence the resolution of a user query may involve several network
+accesses and an arbitrary amount of time.  The queries to foreign name
+servers and the corresponding responses have a standard format described
+
+
+
+Mockapetris                                                     [Page 4]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+in this memo, and may be datagrams.
+
+Depending on its capabilities, a name server could be a stand alone
+program on a dedicated machine or a process or processes on a large
+timeshared host.  A simple configuration might be:
+
+                 Local Host                        |  Foreign
+                                                   |
+      +---------+                                  |
+     /         /|                                  |
+    +---------+ |             +----------+         |  +--------+
+    |         | |             |          |responses|  |        |
+    |         | |             |   Name   |---------|->|Foreign |
+    |  Master |-------------->|  Server  |         |  |Resolver|
+    |  files  | |             |          |<--------|--|        |
+    |         |/              |          | queries |  +--------+
+    +---------+               +----------+         |
+
+Here a primary name server acquires information about one or more zones
+by reading master files from its local file system, and answers queries
+about those zones that arrive from foreign resolvers.
+
+The DNS requires that all zones be redundantly supported by more than
+one name server.  Designated secondary servers can acquire zones and
+check for updates from the primary server using the zone transfer
+protocol of the DNS.  This configuration is shown below:
+
+                 Local Host                        |  Foreign
+                                                   |
+      +---------+                                  |
+     /         /|                                  |
+    +---------+ |             +----------+         |  +--------+
+    |         | |             |          |responses|  |        |
+    |         | |             |   Name   |---------|->|Foreign |
+    |  Master |-------------->|  Server  |         |  |Resolver|
+    |  files  | |             |          |<--------|--|        |
+    |         |/              |          | queries |  +--------+
+    +---------+               +----------+         |
+                                A     |maintenance |  +--------+
+                                |     +------------|->|        |
+                                |      queries     |  |Foreign |
+                                |                  |  |  Name  |
+                                +------------------|--| Server |
+                             maintenance responses |  +--------+
+
+In this configuration, the name server periodically establishes a
+virtual circuit to a foreign name server to acquire a copy of a zone or
+to check that an existing copy has not changed.  The messages sent for
+
+
+
+Mockapetris                                                     [Page 5]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+these maintenance activities follow the same form as queries and
+responses, but the message sequences are somewhat different.
+
+The information flow in a host that supports all aspects of the domain
+name system is shown below:
+
+                 Local Host                        |  Foreign
+                                                   |
+    +---------+               +----------+         |  +--------+
+    |         | user queries  |          |queries  |  |        |
+    |  User   |-------------->|          |---------|->|Foreign |
+    | Program |               | Resolver |         |  |  Name  |
+    |         |<--------------|          |<--------|--| Server |
+    |         | user responses|          |responses|  |        |
+    +---------+               +----------+         |  +--------+
+                                |     A            |
+                cache additions |     | references |
+                                V     |            |
+                              +----------+         |
+                              |  Shared  |         |
+                              | database |         |
+                              +----------+         |
+                                A     |            |
+      +---------+     refreshes |     | references |
+     /         /|               |     V            |
+    +---------+ |             +----------+         |  +--------+
+    |         | |             |          |responses|  |        |
+    |         | |             |   Name   |---------|->|Foreign |
+    |  Master |-------------->|  Server  |         |  |Resolver|
+    |  files  | |             |          |<--------|--|        |
+    |         |/              |          | queries |  +--------+
+    +---------+               +----------+         |
+                                A     |maintenance |  +--------+
+                                |     +------------|->|        |
+                                |      queries     |  |Foreign |
+                                |                  |  |  Name  |
+                                +------------------|--| Server |
+                             maintenance responses |  +--------+
+
+The shared database holds domain space data for the local name server
+and resolver.  The contents of the shared database will typically be a
+mixture of authoritative data maintained by the periodic refresh
+operations of the name server and cached data from previous resolver
+requests.  The structure of the domain data and the necessity for
+synchronization between name servers and resolvers imply the general
+characteristics of this database, but the actual format is up to the
+local implementor.
+
+
+
+
+Mockapetris                                                     [Page 6]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+Information flow can also be tailored so that a group of hosts act
+together to optimize activities.  Sometimes this is done to offload less
+capable hosts so that they do not have to implement a full resolver.
+This can be appropriate for PCs or hosts which want to minimize the
+amount of new network code which is required.  This scheme can also
+allow a group of hosts can share a small number of caches rather than
+maintaining a large number of separate caches, on the premise that the
+centralized caches will have a higher hit ratio.  In either case,
+resolvers are replaced with stub resolvers which act as front ends to
+resolvers located in a recursive server in one or more name servers
+known to perform that service:
+
+                   Local Hosts                     |  Foreign
+                                                   |
+    +---------+                                    |
+    |         | responses                          |
+    | Stub    |<--------------------+              |
+    | Resolver|                     |              |
+    |         |----------------+    |              |
+    +---------+ recursive      |    |              |
+                queries        |    |              |
+                               V    |              |
+    +---------+ recursive     +----------+         |  +--------+
+    |         | queries       |          |queries  |  |        |
+    | Stub    |-------------->| Recursive|---------|->|Foreign |
+    | Resolver|               | Server   |         |  |  Name  |
+    |         |<--------------|          |<--------|--| Server |
+    +---------+ responses     |          |responses|  |        |
+                              +----------+         |  +--------+
+                              |  Central |         |
+                              |   cache  |         |
+                              +----------+         |
+
+In any case, note that domain components are always replicated for
+reliability whenever possible.
+
+2.3. Conventions
+
+The domain system has several conventions dealing with low-level, but
+fundamental, issues.  While the implementor is free to violate these
+conventions WITHIN HIS OWN SYSTEM, he must observe these conventions in
+ALL behavior observed from other hosts.
+
+2.3.1. Preferred name syntax
+
+The DNS specifications attempt to be as general as possible in the rules
+for constructing domain names.  The idea is that the name of any
+existing object can be expressed as a domain name with minimal changes.
+
+
+
+Mockapetris                                                     [Page 7]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+However, when assigning a domain name for an object, the prudent user
+will select a name which satisfies both the rules of the domain system
+and any existing rules for the object, whether these rules are published
+or implied by existing programs.
+
+For example, when naming a mail domain, the user should satisfy both the
+rules of this memo and those in RFC-822.  When creating a new host name,
+the old rules for HOSTS.TXT should be followed.  This avoids problems
+when old software is converted to use domain names.
+
+The following syntax will result in fewer problems with many
+
+applications that use domain names (e.g., mail, TELNET).
+
+<domain> ::= <subdomain> | " "
+
+<subdomain> ::= <label> | <subdomain> "." <label>
+
+<label> ::= <letter> [ [ <ldh-str> ] <let-dig> ]
+
+<ldh-str> ::= <let-dig-hyp> | <let-dig-hyp> <ldh-str>
+
+<let-dig-hyp> ::= <let-dig> | "-"
+
+<let-dig> ::= <letter> | <digit>
+
+<letter> ::= any one of the 52 alphabetic characters A through Z in
+upper case and a through z in lower case
+
+<digit> ::= any one of the ten digits 0 through 9
+
+Note that while upper and lower case letters are allowed in domain
+names, no significance is attached to the case.  That is, two names with
+the same spelling but different case are to be treated as if identical.
+
+The labels must follow the rules for ARPANET host names.  They must
+start with a letter, end with a letter or digit, and have as interior
+characters only letters, digits, and hyphen.  There are also some
+restrictions on the length.  Labels must be 63 characters or less.
+
+For example, the following strings identify hosts in the Internet:
+
+A.ISI.EDU XX.LCS.MIT.EDU SRI-NIC.ARPA
+
+2.3.2. Data Transmission Order
+
+The order of transmission of the header and data described in this
+document is resolved to the octet level.  Whenever a diagram shows a
+
+
+
+Mockapetris                                                     [Page 8]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+group of octets, the order of transmission of those octets is the normal
+order in which they are read in English.  For example, in the following
+diagram, the octets are transmitted in the order they are numbered.
+
+     0                   1
+     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |       1       |       2       |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |       3       |       4       |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |       5       |       6       |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+Whenever an octet represents a numeric quantity, the left most bit in
+the diagram is the high order or most significant bit.  That is, the bit
+labeled 0 is the most significant bit.  For example, the following
+diagram represents the value 170 (decimal).
+
+     0 1 2 3 4 5 6 7
+    +-+-+-+-+-+-+-+-+
+    |1 0 1 0 1 0 1 0|
+    +-+-+-+-+-+-+-+-+
+
+Similarly, whenever a multi-octet field represents a numeric quantity
+the left most bit of the whole field is the most significant bit.  When
+a multi-octet quantity is transmitted the most significant octet is
+transmitted first.
+
+2.3.3. Character Case
+
+For all parts of the DNS that are part of the official protocol, all
+comparisons between character strings (e.g., labels, domain names, etc.)
+are done in a case-insensitive manner.  At present, this rule is in
+force throughout the domain system without exception.  However, future
+additions beyond current usage may need to use the full binary octet
+capabilities in names, so attempts to store domain names in 7-bit ASCII
+or use of special bytes to terminate labels, etc., should be avoided.
+
+When data enters the domain system, its original case should be
+preserved whenever possible.  In certain circumstances this cannot be
+done.  For example, if two RRs are stored in a database, one at x.y and
+one at X.Y, they are actually stored at the same place in the database,
+and hence only one casing would be preserved.  The basic rule is that
+case can be discarded only when data is used to define structure in a
+database, and two names are identical when compared in a case
+insensitive manner.
+
+
+
+
+Mockapetris                                                     [Page 9]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+Loss of case sensitive data must be minimized.  Thus while data for x.y
+and X.Y may both be stored under a single location x.y or X.Y, data for
+a.x and B.X would never be stored under A.x, A.X, b.x, or b.X.  In
+general, this preserves the case of the first label of a domain name,
+but forces standardization of interior node labels.
+
+Systems administrators who enter data into the domain database should
+take care to represent the data they supply to the domain system in a
+case-consistent manner if their system is case-sensitive.  The data
+distribution system in the domain system will ensure that consistent
+representations are preserved.
+
+2.3.4. Size limits
+
+Various objects and parameters in the DNS have size limits.  They are
+listed below.  Some could be easily changed, others are more
+fundamental.
+
+labels          63 octets or less
+
+names           255 octets or less
+
+TTL             positive values of a signed 32 bit number.
+
+UDP messages    512 octets or less
+
+3. DOMAIN NAME SPACE AND RR DEFINITIONS
+
+3.1. Name space definitions
+
+Domain names in messages are expressed in terms of a sequence of labels.
+Each label is represented as a one octet length field followed by that
+number of octets.  Since every domain name ends with the null label of
+the root, a domain name is terminated by a length byte of zero.  The
+high order two bits of every length octet must be zero, and the
+remaining six bits of the length field limit the label to 63 octets or
+less.
+
+To simplify implementations, the total length of a domain name (i.e.,
+label octets and label length octets) is restricted to 255 octets or
+less.
+
+Although labels can contain any 8 bit values in octets that make up a
+label, it is strongly recommended that labels follow the preferred
+syntax described elsewhere in this memo, which is compatible with
+existing host naming conventions.  Name servers and resolvers must
+compare labels in a case-insensitive manner (i.e., A=a), assuming ASCII
+with zero parity.  Non-alphabetic codes must match exactly.
+
+
+
+Mockapetris                                                    [Page 10]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+3.2. RR definitions
+
+3.2.1. Format
+
+All RRs have the same top level format shown below:
+
+                                    1  1  1  1  1  1
+      0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    |                                               |
+    /                                               /
+    /                      NAME                     /
+    |                                               |
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    |                      TYPE                     |
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    |                     CLASS                     |
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    |                      TTL                      |
+    |                                               |
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    |                   RDLENGTH                    |
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--|
+    /                     RDATA                     /
+    /                                               /
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+
+where:
+
+NAME            an owner name, i.e., the name of the node to which this
+                resource record pertains.
+
+TYPE            two octets containing one of the RR TYPE codes.
+
+CLASS           two octets containing one of the RR CLASS codes.
+
+TTL             a 32 bit signed integer that specifies the time interval
+                that the resource record may be cached before the source
+                of the information should again be consulted.  Zero
+                values are interpreted to mean that the RR can only be
+                used for the transaction in progress, and should not be
+                cached.  For example, SOA records are always distributed
+                with a zero TTL to prohibit caching.  Zero values can
+                also be used for extremely volatile data.
+
+RDLENGTH        an unsigned 16 bit integer that specifies the length in
+                octets of the RDATA field.
+
+
+
+Mockapetris                                                    [Page 11]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+RDATA           a variable length string of octets that describes the
+                resource.  The format of this information varies
+                according to the TYPE and CLASS of the resource record.
+
+3.2.2. TYPE values
+
+TYPE fields are used in resource records.  Note that these types are a
+subset of QTYPEs.
+
+TYPE            value and meaning
+
+A               1 a host address
+
+NS              2 an authoritative name server
+
+MD              3 a mail destination (Obsolete - use MX)
+
+MF              4 a mail forwarder (Obsolete - use MX)
+
+CNAME           5 the canonical name for an alias
+
+SOA             6 marks the start of a zone of authority
+
+MB              7 a mailbox domain name (EXPERIMENTAL)
+
+MG              8 a mail group member (EXPERIMENTAL)
+
+MR              9 a mail rename domain name (EXPERIMENTAL)
+
+NULL            10 a null RR (EXPERIMENTAL)
+
+WKS             11 a well known service description
+
+PTR             12 a domain name pointer
+
+HINFO           13 host information
+
+MINFO           14 mailbox or mail list information
+
+MX              15 mail exchange
+
+TXT             16 text strings
+
+3.2.3. QTYPE values
+
+QTYPE fields appear in the question part of a query.  QTYPES are a
+superset of TYPEs, hence all TYPEs are valid QTYPEs.  In addition, the
+following QTYPEs are defined:
+
+
+
+Mockapetris                                                    [Page 12]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+AXFR            252 A request for a transfer of an entire zone
+
+MAILB           253 A request for mailbox-related records (MB, MG or MR)
+
+MAILA           254 A request for mail agent RRs (Obsolete - see MX)
+
+*               255 A request for all records
+
+3.2.4. CLASS values
+
+CLASS fields appear in resource records.  The following CLASS mnemonics
+and values are defined:
+
+IN              1 the Internet
+
+CS              2 the CSNET class (Obsolete - used only for examples in
+                some obsolete RFCs)
+
+CH              3 the CHAOS class
+
+HS              4 Hesiod [Dyer 87]
+
+3.2.5. QCLASS values
+
+QCLASS fields appear in the question section of a query.  QCLASS values
+are a superset of CLASS values; every CLASS is a valid QCLASS.  In
+addition to CLASS values, the following QCLASSes are defined:
+
+*               255 any class
+
+3.3. Standard RRs
+
+The following RR definitions are expected to occur, at least
+potentially, in all classes.  In particular, NS, SOA, CNAME, and PTR
+will be used in all classes, and have the same format in all classes.
+Because their RDATA format is known, all domain names in the RDATA
+section of these RRs may be compressed.
+
+<domain-name> is a domain name represented as a series of labels, and
+terminated by a label with zero length.  <character-string> is a single
+length octet followed by that number of characters.  <character-string>
+is treated as binary information, and can be up to 256 characters in
+length (including the length octet).
+
+
+
+
+
+
+
+
+Mockapetris                                                    [Page 13]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+3.3.1. CNAME RDATA format
+
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    /                     CNAME                     /
+    /                                               /
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+where:
+
+CNAME           A <domain-name> which specifies the canonical or primary
+                name for the owner.  The owner name is an alias.
+
+CNAME RRs cause no additional section processing, but name servers may
+choose to restart the query at the canonical name in certain cases.  See
+the description of name server logic in [RFC-1034] for details.
+
+3.3.2. HINFO RDATA format
+
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    /                      CPU                      /
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    /                       OS                      /
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+where:
+
+CPU             A <character-string> which specifies the CPU type.
+
+OS              A <character-string> which specifies the operating
+                system type.
+
+Standard values for CPU and OS can be found in [RFC-1010].
+
+HINFO records are used to acquire general information about a host.  The
+main use is for protocols such as FTP that can use special procedures
+when talking between machines or operating systems of the same type.
+
+3.3.3. MB RDATA format (EXPERIMENTAL)
+
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    /                   MADNAME                     /
+    /                                               /
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+where:
+
+MADNAME         A <domain-name> which specifies a host which has the
+                specified mailbox.
+
+
+
+Mockapetris                                                    [Page 14]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+MB records cause additional section processing which looks up an A type
+RRs corresponding to MADNAME.
+
+3.3.4. MD RDATA format (Obsolete)
+
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    /                   MADNAME                     /
+    /                                               /
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+where:
+
+MADNAME         A <domain-name> which specifies a host which has a mail
+                agent for the domain which should be able to deliver
+                mail for the domain.
+
+MD records cause additional section processing which looks up an A type
+record corresponding to MADNAME.
+
+MD is obsolete.  See the definition of MX and [RFC-974] for details of
+the new scheme.  The recommended policy for dealing with MD RRs found in
+a master file is to reject them, or to convert them to MX RRs with a
+preference of 0.
+
+3.3.5. MF RDATA format (Obsolete)
+
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    /                   MADNAME                     /
+    /                                               /
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+where:
+
+MADNAME         A <domain-name> which specifies a host which has a mail
+                agent for the domain which will accept mail for
+                forwarding to the domain.
+
+MF records cause additional section processing which looks up an A type
+record corresponding to MADNAME.
+
+MF is obsolete.  See the definition of MX and [RFC-974] for details ofw
+the new scheme.  The recommended policy for dealing with MD RRs found in
+a master file is to reject them, or to convert them to MX RRs with a
+preference of 10.
+
+
+
+
+
+
+
+Mockapetris                                                    [Page 15]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+3.3.6. MG RDATA format (EXPERIMENTAL)
+
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    /                   MGMNAME                     /
+    /                                               /
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+where:
+
+MGMNAME         A <domain-name> which specifies a mailbox which is a
+                member of the mail group specified by the domain name.
+
+MG records cause no additional section processing.
+
+3.3.7. MINFO RDATA format (EXPERIMENTAL)
+
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    /                    RMAILBX                    /
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    /                    EMAILBX                    /
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+where:
+
+RMAILBX         A <domain-name> which specifies a mailbox which is
+                responsible for the mailing list or mailbox.  If this
+                domain name names the root, the owner of the MINFO RR is
+                responsible for itself.  Note that many existing mailing
+                lists use a mailbox X-request for the RMAILBX field of
+                mailing list X, e.g., Msgroup-request for Msgroup.  This
+                field provides a more general mechanism.
+
+
+EMAILBX         A <domain-name> which specifies a mailbox which is to
+                receive error messages related to the mailing list or
+                mailbox specified by the owner of the MINFO RR (similar
+                to the ERRORS-TO: field which has been proposed).  If
+                this domain name names the root, errors should be
+                returned to the sender of the message.
+
+MINFO records cause no additional section processing.  Although these
+records can be associated with a simple mailbox, they are usually used
+with a mailing list.
+
+
+
+
+
+
+
+
+Mockapetris                                                    [Page 16]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+3.3.8. MR RDATA format (EXPERIMENTAL)
+
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    /                   NEWNAME                     /
+    /                                               /
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+where:
+
+NEWNAME         A <domain-name> which specifies a mailbox which is the
+                proper rename of the specified mailbox.
+
+MR records cause no additional section processing.  The main use for MR
+is as a forwarding entry for a user who has moved to a different
+mailbox.
+
+3.3.9. MX RDATA format
+
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    |                  PREFERENCE                   |
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    /                   EXCHANGE                    /
+    /                                               /
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+where:
+
+PREFERENCE      A 16 bit integer which specifies the preference given to
+                this RR among others at the same owner.  Lower values
+                are preferred.
+
+EXCHANGE        A <domain-name> which specifies a host willing to act as
+                a mail exchange for the owner name.
+
+MX records cause type A additional section processing for the host
+specified by EXCHANGE.  The use of MX RRs is explained in detail in
+[RFC-974].
+
+3.3.10. NULL RDATA format (EXPERIMENTAL)
+
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    /                  <anything>                   /
+    /                                               /
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+Anything at all may be in the RDATA field so long as it is 65535 octets
+or less.
+
+
+
+
+Mockapetris                                                    [Page 17]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+NULL records cause no additional section processing.  NULL RRs are not
+allowed in master files.  NULLs are used as placeholders in some
+experimental extensions of the DNS.
+
+3.3.11. NS RDATA format
+
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    /                   NSDNAME                     /
+    /                                               /
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+where:
+
+NSDNAME         A <domain-name> which specifies a host which should be
+                authoritative for the specified class and domain.
+
+NS records cause both the usual additional section processing to locate
+a type A record, and, when used in a referral, a special search of the
+zone in which they reside for glue information.
+
+The NS RR states that the named host should be expected to have a zone
+starting at owner name of the specified class.  Note that the class may
+not indicate the protocol family which should be used to communicate
+with the host, although it is typically a strong hint.  For example,
+hosts which are name servers for either Internet (IN) or Hesiod (HS)
+class information are normally queried using IN class protocols.
+
+3.3.12. PTR RDATA format
+
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    /                   PTRDNAME                    /
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+where:
+
+PTRDNAME        A <domain-name> which points to some location in the
+                domain name space.
+
+PTR records cause no additional section processing.  These RRs are used
+in special domains to point to some other location in the domain space.
+These records are simple data, and don't imply any special processing
+similar to that performed by CNAME, which identifies aliases.  See the
+description of the IN-ADDR.ARPA domain for an example.
+
+
+
+
+
+
+
+
+Mockapetris                                                    [Page 18]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+3.3.13. SOA RDATA format
+
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    /                     MNAME                     /
+    /                                               /
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    /                     RNAME                     /
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    |                    SERIAL                     |
+    |                                               |
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    |                    REFRESH                    |
+    |                                               |
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    |                     RETRY                     |
+    |                                               |
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    |                    EXPIRE                     |
+    |                                               |
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    |                    MINIMUM                    |
+    |                                               |
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+where:
+
+MNAME           The <domain-name> of the name server that was the
+                original or primary source of data for this zone.
+
+RNAME           A <domain-name> which specifies the mailbox of the
+                person responsible for this zone.
+
+SERIAL          The unsigned 32 bit version number of the original copy
+                of the zone.  Zone transfers preserve this value.  This
+                value wraps and should be compared using sequence space
+                arithmetic.
+
+REFRESH         A 32 bit time interval before the zone should be
+                refreshed.
+
+RETRY           A 32 bit time interval that should elapse before a
+                failed refresh should be retried.
+
+EXPIRE          A 32 bit time value that specifies the upper limit on
+                the time interval that can elapse before the zone is no
+                longer authoritative.
+
+
+
+
+
+Mockapetris                                                    [Page 19]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+MINIMUM         The unsigned 32 bit minimum TTL field that should be
+                exported with any RR from this zone.
+
+SOA records cause no additional section processing.
+
+All times are in units of seconds.
+
+Most of these fields are pertinent only for name server maintenance
+operations.  However, MINIMUM is used in all query operations that
+retrieve RRs from a zone.  Whenever a RR is sent in a response to a
+query, the TTL field is set to the maximum of the TTL field from the RR
+and the MINIMUM field in the appropriate SOA.  Thus MINIMUM is a lower
+bound on the TTL field for all RRs in a zone.  Note that this use of
+MINIMUM should occur when the RRs are copied into the response and not
+when the zone is loaded from a master file or via a zone transfer.  The
+reason for this provison is to allow future dynamic update facilities to
+change the SOA RR with known semantics.
+
+
+3.3.14. TXT RDATA format
+
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    /                   TXT-DATA                    /
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+where:
+
+TXT-DATA        One or more <character-string>s.
+
+TXT RRs are used to hold descriptive text.  The semantics of the text
+depends on the domain where it is found.
+
+3.4. Internet specific RRs
+
+3.4.1. A RDATA format
+
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    |                    ADDRESS                    |
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+where:
+
+ADDRESS         A 32 bit Internet address.
+
+Hosts that have multiple Internet addresses will have multiple A
+records.
+
+
+
+
+
+Mockapetris                                                    [Page 20]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+A records cause no additional section processing.  The RDATA section of
+an A line in a master file is an Internet address expressed as four
+decimal numbers separated by dots without any imbedded spaces (e.g.,
+"10.2.0.52" or "192.0.5.6").
+
+3.4.2. WKS RDATA format
+
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    |                    ADDRESS                    |
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    |       PROTOCOL        |                       |
+    +--+--+--+--+--+--+--+--+                       |
+    |                                               |
+    /                   <BIT MAP>                   /
+    /                                               /
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+where:
+
+ADDRESS         An 32 bit Internet address
+
+PROTOCOL        An 8 bit IP protocol number
+
+<BIT MAP>       A variable length bit map.  The bit map must be a
+                multiple of 8 bits long.
+
+The WKS record is used to describe the well known services supported by
+a particular protocol on a particular internet address.  The PROTOCOL
+field specifies an IP protocol number, and the bit map has one bit per
+port of the specified protocol.  The first bit corresponds to port 0,
+the second to port 1, etc.  If the bit map does not include a bit for a
+protocol of interest, that bit is assumed zero.  The appropriate values
+and mnemonics for ports and protocols are specified in [RFC-1010].
+
+For example, if PROTOCOL=TCP (6), the 26th bit corresponds to TCP port
+25 (SMTP).  If this bit is set, a SMTP server should be listening on TCP
+port 25; if zero, SMTP service is not supported on the specified
+address.
+
+The purpose of WKS RRs is to provide availability information for
+servers for TCP and UDP.  If a server supports both TCP and UDP, or has
+multiple Internet addresses, then multiple WKS RRs are used.
+
+WKS RRs cause no additional section processing.
+
+In master files, both ports and protocols are expressed using mnemonics
+or decimal numbers.
+
+
+
+
+Mockapetris                                                    [Page 21]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+3.5. IN-ADDR.ARPA domain
+
+The Internet uses a special domain to support gateway location and
+Internet address to host mapping.  Other classes may employ a similar
+strategy in other domains.  The intent of this domain is to provide a
+guaranteed method to perform host address to host name mapping, and to
+facilitate queries to locate all gateways on a particular network in the
+Internet.
+
+Note that both of these services are similar to functions that could be
+performed by inverse queries; the difference is that this part of the
+domain name space is structured according to address, and hence can
+guarantee that the appropriate data can be located without an exhaustive
+search of the domain space.
+
+The domain begins at IN-ADDR.ARPA and has a substructure which follows
+the Internet addressing structure.
+
+Domain names in the IN-ADDR.ARPA domain are defined to have up to four
+labels in addition to the IN-ADDR.ARPA suffix.  Each label represents
+one octet of an Internet address, and is expressed as a character string
+for a decimal value in the range 0-255 (with leading zeros omitted
+except in the case of a zero octet which is represented by a single
+zero).
+
+Host addresses are represented by domain names that have all four labels
+specified.  Thus data for Internet address 10.2.0.52 is located at
+domain name 52.0.2.10.IN-ADDR.ARPA.  The reversal, though awkward to
+read, allows zones to be delegated which are exactly one network of
+address space.  For example, 10.IN-ADDR.ARPA can be a zone containing
+data for the ARPANET, while 26.IN-ADDR.ARPA can be a separate zone for
+MILNET.  Address nodes are used to hold pointers to primary host names
+in the normal domain space.
+
+Network numbers correspond to some non-terminal nodes at various depths
+in the IN-ADDR.ARPA domain, since Internet network numbers are either 1,
+2, or 3 octets.  Network nodes are used to hold pointers to the primary
+host names of gateways attached to that network.  Since a gateway is, by
+definition, on more than one network, it will typically have two or more
+network nodes which point at it.  Gateways will also have host level
+pointers at their fully qualified addresses.
+
+Both the gateway pointers at network nodes and the normal host pointers
+at full address nodes use the PTR RR to point back to the primary domain
+names of the corresponding hosts.
+
+For example, the IN-ADDR.ARPA domain will contain information about the
+ISI gateway between net 10 and 26, an MIT gateway from net 10 to MIT's
+
+
+
+Mockapetris                                                    [Page 22]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+net 18, and hosts A.ISI.EDU and MULTICS.MIT.EDU.  Assuming that ISI
+gateway has addresses 10.2.0.22 and 26.0.0.103, and a name MILNET-
+GW.ISI.EDU, and the MIT gateway has addresses 10.0.0.77 and 18.10.0.4
+and a name GW.LCS.MIT.EDU, the domain database would contain:
+
+    10.IN-ADDR.ARPA.           PTR MILNET-GW.ISI.EDU.
+    10.IN-ADDR.ARPA.           PTR GW.LCS.MIT.EDU.
+    18.IN-ADDR.ARPA.           PTR GW.LCS.MIT.EDU.
+    26.IN-ADDR.ARPA.           PTR MILNET-GW.ISI.EDU.
+    22.0.2.10.IN-ADDR.ARPA.    PTR MILNET-GW.ISI.EDU.
+    103.0.0.26.IN-ADDR.ARPA.   PTR MILNET-GW.ISI.EDU.
+    77.0.0.10.IN-ADDR.ARPA.    PTR GW.LCS.MIT.EDU.
+    4.0.10.18.IN-ADDR.ARPA.    PTR GW.LCS.MIT.EDU.
+    103.0.3.26.IN-ADDR.ARPA.   PTR A.ISI.EDU.
+    6.0.0.10.IN-ADDR.ARPA.     PTR MULTICS.MIT.EDU.
+
+Thus a program which wanted to locate gateways on net 10 would originate
+a query of the form QTYPE=PTR, QCLASS=IN, QNAME=10.IN-ADDR.ARPA.  It
+would receive two RRs in response:
+
+    10.IN-ADDR.ARPA.           PTR MILNET-GW.ISI.EDU.
+    10.IN-ADDR.ARPA.           PTR GW.LCS.MIT.EDU.
+
+The program could then originate QTYPE=A, QCLASS=IN queries for MILNET-
+GW.ISI.EDU. and GW.LCS.MIT.EDU. to discover the Internet addresses of
+these gateways.
+
+A resolver which wanted to find the host name corresponding to Internet
+host address 10.0.0.6 would pursue a query of the form QTYPE=PTR,
+QCLASS=IN, QNAME=6.0.0.10.IN-ADDR.ARPA, and would receive:
+
+    6.0.0.10.IN-ADDR.ARPA.     PTR MULTICS.MIT.EDU.
+
+Several cautions apply to the use of these services:
+   - Since the IN-ADDR.ARPA special domain and the normal domain
+     for a particular host or gateway will be in different zones,
+     the possibility exists that that the data may be inconsistent.
+
+   - Gateways will often have two names in separate domains, only
+     one of which can be primary.
+
+   - Systems that use the domain database to initialize their
+     routing tables must start with enough gateway information to
+     guarantee that they can access the appropriate name server.
+
+   - The gateway data only reflects the existence of a gateway in a
+     manner equivalent to the current HOSTS.TXT file.  It doesn't
+     replace the dynamic availability information from GGP or EGP.
+
+
+
+Mockapetris                                                    [Page 23]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+3.6. Defining new types, classes, and special namespaces
+
+The previously defined types and classes are the ones in use as of the
+date of this memo.  New definitions should be expected.  This section
+makes some recommendations to designers considering additions to the
+existing facilities.  The mailing list NAMEDROPPERS@SRI-NIC.ARPA is the
+forum where general discussion of design issues takes place.
+
+In general, a new type is appropriate when new information is to be
+added to the database about an existing object, or we need new data
+formats for some totally new object.  Designers should attempt to define
+types and their RDATA formats that are generally applicable to all
+classes, and which avoid duplication of information.  New classes are
+appropriate when the DNS is to be used for a new protocol, etc which
+requires new class-specific data formats, or when a copy of the existing
+name space is desired, but a separate management domain is necessary.
+
+New types and classes need mnemonics for master files; the format of the
+master files requires that the mnemonics for type and class be disjoint.
+
+TYPE and CLASS values must be a proper subset of QTYPEs and QCLASSes
+respectively.
+
+The present system uses multiple RRs to represent multiple values of a
+type rather than storing multiple values in the RDATA section of a
+single RR.  This is less efficient for most applications, but does keep
+RRs shorter.  The multiple RRs assumption is incorporated in some
+experimental work on dynamic update methods.
+
+The present system attempts to minimize the duplication of data in the
+database in order to insure consistency.  Thus, in order to find the
+address of the host for a mail exchange, you map the mail domain name to
+a host name, then the host name to addresses, rather than a direct
+mapping to host address.  This approach is preferred because it avoids
+the opportunity for inconsistency.
+
+In defining a new type of data, multiple RR types should not be used to
+create an ordering between entries or express different formats for
+equivalent bindings, instead this information should be carried in the
+body of the RR and a single type used.  This policy avoids problems with
+caching multiple types and defining QTYPEs to match multiple types.
+
+For example, the original form of mail exchange binding used two RR
+types one to represent a "closer" exchange (MD) and one to represent a
+"less close" exchange (MF).  The difficulty is that the presence of one
+RR type in a cache doesn't convey any information about the other
+because the query which acquired the cached information might have used
+a QTYPE of MF, MD, or MAILA (which matched both).  The redesigned
+
+
+
+Mockapetris                                                    [Page 24]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+service used a single type (MX) with a "preference" value in the RDATA
+section which can order different RRs.  However, if any MX RRs are found
+in the cache, then all should be there.
+
+4. MESSAGES
+
+4.1. Format
+
+All communications inside of the domain protocol are carried in a single
+format called a message.  The top level format of message is divided
+into 5 sections (some of which are empty in certain cases) shown below:
+
+    +---------------------+
+    |        Header       |
+    +---------------------+
+    |       Question      | the question for the name server
+    +---------------------+
+    |        Answer       | RRs answering the question
+    +---------------------+
+    |      Authority      | RRs pointing toward an authority
+    +---------------------+
+    |      Additional     | RRs holding additional information
+    +---------------------+
+
+The header section is always present.  The header includes fields that
+specify which of the remaining sections are present, and also specify
+whether the message is a query or a response, a standard query or some
+other opcode, etc.
+
+The names of the sections after the header are derived from their use in
+standard queries.  The question section contains fields that describe a
+question to a name server.  These fields are a query type (QTYPE), a
+query class (QCLASS), and a query domain name (QNAME).  The last three
+sections have the same format: a possibly empty list of concatenated
+resource records (RRs).  The answer section contains RRs that answer the
+question; the authority section contains RRs that point toward an
+authoritative name server; the additional records section contains RRs
+which relate to the query, but are not strictly answers for the
+question.
+
+
+
+
+
+
+
+
+
+
+
+
+Mockapetris                                                    [Page 25]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+4.1.1. Header section format
+
+The header contains the following fields:
+
+                                    1  1  1  1  1  1
+      0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    |                      ID                       |
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    |QR|   Opcode  |AA|TC|RD|RA|   Z    |   RCODE   |
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    |                    QDCOUNT                    |
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    |                    ANCOUNT                    |
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    |                    NSCOUNT                    |
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    |                    ARCOUNT                    |
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+where:
+
+ID              A 16 bit identifier assigned by the program that
+                generates any kind of query.  This identifier is copied
+                the corresponding reply and can be used by the requester
+                to match up replies to outstanding queries.
+
+QR              A one bit field that specifies whether this message is a
+                query (0), or a response (1).
+
+OPCODE          A four bit field that specifies kind of query in this
+                message.  This value is set by the originator of a query
+                and copied into the response.  The values are:
+
+                0               a standard query (QUERY)
+
+                1               an inverse query (IQUERY)
+
+                2               a server status request (STATUS)
+
+                3-15            reserved for future use
+
+AA              Authoritative Answer - this bit is valid in responses,
+                and specifies that the responding name server is an
+                authority for the domain name in question section.
+
+                Note that the contents of the answer section may have
+                multiple owner names because of aliases.  The AA bit
+
+
+
+Mockapetris                                                    [Page 26]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+                corresponds to the name which matches the query name, or
+                the first owner name in the answer section.
+
+TC              TrunCation - specifies that this message was truncated
+                due to length greater than that permitted on the
+                transmission channel.
+
+RD              Recursion Desired - this bit may be set in a query and
+                is copied into the response.  If RD is set, it directs
+                the name server to pursue the query recursively.
+                Recursive query support is optional.
+
+RA              Recursion Available - this be is set or cleared in a
+                response, and denotes whether recursive query support is
+                available in the name server.
+
+Z               Reserved for future use.  Must be zero in all queries
+                and responses.
+
+RCODE           Response code - this 4 bit field is set as part of
+                responses.  The values have the following
+                interpretation:
+
+                0               No error condition
+
+                1               Format error - The name server was
+                                unable to interpret the query.
+
+                2               Server failure - The name server was
+                                unable to process this query due to a
+                                problem with the name server.
+
+                3               Name Error - Meaningful only for
+                                responses from an authoritative name
+                                server, this code signifies that the
+                                domain name referenced in the query does
+                                not exist.
+
+                4               Not Implemented - The name server does
+                                not support the requested kind of query.
+
+                5               Refused - The name server refuses to
+                                perform the specified operation for
+                                policy reasons.  For example, a name
+                                server may not wish to provide the
+                                information to the particular requester,
+                                or a name server may not wish to perform
+                                a particular operation (e.g., zone
+
+
+
+Mockapetris                                                    [Page 27]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+                                transfer) for particular data.
+
+                6-15            Reserved for future use.
+
+QDCOUNT         an unsigned 16 bit integer specifying the number of
+                entries in the question section.
+
+ANCOUNT         an unsigned 16 bit integer specifying the number of
+                resource records in the answer section.
+
+NSCOUNT         an unsigned 16 bit integer specifying the number of name
+                server resource records in the authority records
+                section.
+
+ARCOUNT         an unsigned 16 bit integer specifying the number of
+                resource records in the additional records section.
+
+4.1.2. Question section format
+
+The question section is used to carry the "question" in most queries,
+i.e., the parameters that define what is being asked.  The section
+contains QDCOUNT (usually 1) entries, each of the following format:
+
+                                    1  1  1  1  1  1
+      0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    |                                               |
+    /                     QNAME                     /
+    /                                               /
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    |                     QTYPE                     |
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    |                     QCLASS                    |
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+where:
+
+QNAME           a domain name represented as a sequence of labels, where
+                each label consists of a length octet followed by that
+                number of octets.  The domain name terminates with the
+                zero length octet for the null label of the root.  Note
+                that this field may be an odd number of octets; no
+                padding is used.
+
+QTYPE           a two octet code which specifies the type of the query.
+                The values for this field include all codes valid for a
+                TYPE field, together with some more general codes which
+                can match more than one type of RR.
+
+
+
+Mockapetris                                                    [Page 28]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+QCLASS          a two octet code that specifies the class of the query.
+                For example, the QCLASS field is IN for the Internet.
+
+4.1.3. Resource record format
+
+The answer, authority, and additional sections all share the same
+format: a variable number of resource records, where the number of
+records is specified in the corresponding count field in the header.
+Each resource record has the following format:
+                                    1  1  1  1  1  1
+      0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    |                                               |
+    /                                               /
+    /                      NAME                     /
+    |                                               |
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    |                      TYPE                     |
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    |                     CLASS                     |
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    |                      TTL                      |
+    |                                               |
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    |                   RDLENGTH                    |
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--|
+    /                     RDATA                     /
+    /                                               /
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+where:
+
+NAME            a domain name to which this resource record pertains.
+
+TYPE            two octets containing one of the RR type codes.  This
+                field specifies the meaning of the data in the RDATA
+                field.
+
+CLASS           two octets which specify the class of the data in the
+                RDATA field.
+
+TTL             a 32 bit unsigned integer that specifies the time
+                interval (in seconds) that the resource record may be
+                cached before it should be discarded.  Zero values are
+                interpreted to mean that the RR can only be used for the
+                transaction in progress, and should not be cached.
+
+
+
+
+
+Mockapetris                                                    [Page 29]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+RDLENGTH        an unsigned 16 bit integer that specifies the length in
+                octets of the RDATA field.
+
+RDATA           a variable length string of octets that describes the
+                resource.  The format of this information varies
+                according to the TYPE and CLASS of the resource record.
+                For example, the if the TYPE is A and the CLASS is IN,
+                the RDATA field is a 4 octet ARPA Internet address.
+
+4.1.4. Message compression
+
+In order to reduce the size of messages, the domain system utilizes a
+compression scheme which eliminates the repetition of domain names in a
+message.  In this scheme, an entire domain name or a list of labels at
+the end of a domain name is replaced with a pointer to a prior occurance
+of the same name.
+
+The pointer takes the form of a two octet sequence:
+
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    | 1  1|                OFFSET                   |
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+The first two bits are ones.  This allows a pointer to be distinguished
+from a label, since the label must begin with two zero bits because
+labels are restricted to 63 octets or less.  (The 10 and 01 combinations
+are reserved for future use.)  The OFFSET field specifies an offset from
+the start of the message (i.e., the first octet of the ID field in the
+domain header).  A zero offset specifies the first byte of the ID field,
+etc.
+
+The compression scheme allows a domain name in a message to be
+represented as either:
+
+   - a sequence of labels ending in a zero octet
+
+   - a pointer
+
+   - a sequence of labels ending with a pointer
+
+Pointers can only be used for occurances of a domain name where the
+format is not class specific.  If this were not the case, a name server
+or resolver would be required to know the format of all RRs it handled.
+As yet, there are no such cases, but they may occur in future RDATA
+formats.
+
+If a domain name is contained in a part of the message subject to a
+length field (such as the RDATA section of an RR), and compression is
+
+
+
+Mockapetris                                                    [Page 30]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+used, the length of the compressed name is used in the length
+calculation, rather than the length of the expanded name.
+
+Programs are free to avoid using pointers in messages they generate,
+although this will reduce datagram capacity, and may cause truncation.
+However all programs are required to understand arriving messages that
+contain pointers.
+
+For example, a datagram might need to use the domain names F.ISI.ARPA,
+FOO.F.ISI.ARPA, ARPA, and the root.  Ignoring the other fields of the
+message, these domain names might be represented as:
+
+       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    20 |           1           |           F           |
+       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    22 |           3           |           I           |
+       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    24 |           S           |           I           |
+       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    26 |           4           |           A           |
+       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    28 |           R           |           P           |
+       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    30 |           A           |           0           |
+       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    40 |           3           |           F           |
+       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    42 |           O           |           O           |
+       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    44 | 1  1|                20                       |
+       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    64 | 1  1|                26                       |
+       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    92 |           0           |                       |
+       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+The domain name for F.ISI.ARPA is shown at offset 20.  The domain name
+FOO.F.ISI.ARPA is shown at offset 40; this definition uses a pointer to
+concatenate a label for FOO to the previously defined F.ISI.ARPA.  The
+domain name ARPA is defined at offset 64 using a pointer to the ARPA
+component of the name F.ISI.ARPA at 20; note that this pointer relies on
+ARPA being the last label in the string at 20.  The root domain name is
+
+
+
+Mockapetris                                                    [Page 31]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+defined by a single octet of zeros at 92; the root domain name has no
+labels.
+
+4.2. Transport
+
+The DNS assumes that messages will be transmitted as datagrams or in a
+byte stream carried by a virtual circuit.  While virtual circuits can be
+used for any DNS activity, datagrams are preferred for queries due to
+their lower overhead and better performance.  Zone refresh activities
+must use virtual circuits because of the need for reliable transfer.
+
+The Internet supports name server access using TCP [RFC-793] on server
+port 53 (decimal) as well as datagram access using UDP [RFC-768] on UDP
+port 53 (decimal).
+
+4.2.1. UDP usage
+
+Messages sent using UDP user server port 53 (decimal).
+
+Messages carried by UDP are restricted to 512 bytes (not counting the IP
+or UDP headers).  Longer messages are truncated and the TC bit is set in
+the header.
+
+UDP is not acceptable for zone transfers, but is the recommended method
+for standard queries in the Internet.  Queries sent using UDP may be
+lost, and hence a retransmission strategy is required.  Queries or their
+responses may be reordered by the network, or by processing in name
+servers, so resolvers should not depend on them being returned in order.
+
+The optimal UDP retransmission policy will vary with performance of the
+Internet and the needs of the client, but the following are recommended:
+
+   - The client should try other servers and server addresses
+     before repeating a query to a specific address of a server.
+
+   - The retransmission interval should be based on prior
+     statistics if possible.  Too aggressive retransmission can
+     easily slow responses for the community at large.  Depending
+     on how well connected the client is to its expected servers,
+     the minimum retransmission interval should be 2-5 seconds.
+
+More suggestions on server selection and retransmission policy can be
+found in the resolver section of this memo.
+
+4.2.2. TCP usage
+
+Messages sent over TCP connections use server port 53 (decimal).  The
+message is prefixed with a two byte length field which gives the message
+
+
+
+Mockapetris                                                    [Page 32]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+length, excluding the two byte length field.  This length field allows
+the low-level processing to assemble a complete message before beginning
+to parse it.
+
+Several connection management policies are recommended:
+
+   - The server should not block other activities waiting for TCP
+     data.
+
+   - The server should support multiple connections.
+
+   - The server should assume that the client will initiate
+     connection closing, and should delay closing its end of the
+     connection until all outstanding client requests have been
+     satisfied.
+
+   - If the server needs to close a dormant connection to reclaim
+     resources, it should wait until the connection has been idle
+     for a period on the order of two minutes.  In particular, the
+     server should allow the SOA and AXFR request sequence (which
+     begins a refresh operation) to be made on a single connection.
+     Since the server would be unable to answer queries anyway, a
+     unilateral close or reset may be used instead of a graceful
+     close.
+
+5. MASTER FILES
+
+Master files are text files that contain RRs in text form.  Since the
+contents of a zone can be expressed in the form of a list of RRs a
+master file is most often used to define a zone, though it can be used
+to list a cache's contents.  Hence, this section first discusses the
+format of RRs in a master file, and then the special considerations when
+a master file is used to create a zone in some name server.
+
+5.1. Format
+
+The format of these files is a sequence of entries.  Entries are
+predominantly line-oriented, though parentheses can be used to continue
+a list of items across a line boundary, and text literals can contain
+CRLF within the text.  Any combination of tabs and spaces act as a
+delimiter between the separate items that make up an entry.  The end of
+any line in the master file can end with a comment.  The comment starts
+with a ";" (semicolon).
+
+The following entries are defined:
+
+    <blank>[<comment>]
+
+
+
+
+Mockapetris                                                    [Page 33]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+    $ORIGIN <domain-name> [<comment>]
+
+    $INCLUDE <file-name> [<domain-name>] [<comment>]
+
+    <domain-name><rr> [<comment>]
+
+    <blank><rr> [<comment>]
+
+Blank lines, with or without comments, are allowed anywhere in the file.
+
+Two control entries are defined: $ORIGIN and $INCLUDE.  $ORIGIN is
+followed by a domain name, and resets the current origin for relative
+domain names to the stated name.  $INCLUDE inserts the named file into
+the current file, and may optionally specify a domain name that sets the
+relative domain name origin for the included file.  $INCLUDE may also
+have a comment.  Note that a $INCLUDE entry never changes the relative
+origin of the parent file, regardless of changes to the relative origin
+made within the included file.
+
+The last two forms represent RRs.  If an entry for an RR begins with a
+blank, then the RR is assumed to be owned by the last stated owner.  If
+an RR entry begins with a <domain-name>, then the owner name is reset.
+
+<rr> contents take one of the following forms:
+
+    [<TTL>] [<class>] <type> <RDATA>
+
+    [<class>] [<TTL>] <type> <RDATA>
+
+The RR begins with optional TTL and class fields, followed by a type and
+RDATA field appropriate to the type and class.  Class and type use the
+standard mnemonics, TTL is a decimal integer.  Omitted class and TTL
+values are default to the last explicitly stated values.  Since type and
+class mnemonics are disjoint, the parse is unique.  (Note that this
+order is different from the order used in examples and the order used in
+the actual RRs; the given order allows easier parsing and defaulting.)
+
+<domain-name>s make up a large share of the data in the master file.
+The labels in the domain name are expressed as character strings and
+separated by dots.  Quoting conventions allow arbitrary characters to be
+stored in domain names.  Domain names that end in a dot are called
+absolute, and are taken as complete.  Domain names which do not end in a
+dot are called relative; the actual domain name is the concatenation of
+the relative part with an origin specified in a $ORIGIN, $INCLUDE, or as
+an argument to the master file loading routine.  A relative name is an
+error when no origin is available.
+
+
+
+
+
+Mockapetris                                                    [Page 34]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+<character-string> is expressed in one or two ways: as a contiguous set
+of characters without interior spaces, or as a string beginning with a "
+and ending with a ".  Inside a " delimited string any character can
+occur, except for a " itself, which must be quoted using \ (back slash).
+
+Because these files are text files several special encodings are
+necessary to allow arbitrary data to be loaded.  In particular:
+
+                of the root.
+
+@               A free standing @ is used to denote the current origin.
+
+\X              where X is any character other than a digit (0-9), is
+                used to quote that character so that its special meaning
+                does not apply.  For example, "\." can be used to place
+                a dot character in a label.
+
+\DDD            where each D is a digit is the octet corresponding to
+                the decimal number described by DDD.  The resulting
+                octet is assumed to be text and is not checked for
+                special meaning.
+
+( )             Parentheses are used to group data that crosses a line
+                boundary.  In effect, line terminations are not
+                recognized within parentheses.
+
+;               Semicolon is used to start a comment; the remainder of
+                the line is ignored.
+
+5.2. Use of master files to define zones
+
+When a master file is used to load a zone, the operation should be
+suppressed if any errors are encountered in the master file.  The
+rationale for this is that a single error can have widespread
+consequences.  For example, suppose that the RRs defining a delegation
+have syntax errors; then the server will return authoritative name
+errors for all names in the subzone (except in the case where the
+subzone is also present on the server).
+
+Several other validity checks that should be performed in addition to
+insuring that the file is syntactically correct:
+
+   1. All RRs in the file should have the same class.
+
+   2. Exactly one SOA RR should be present at the top of the zone.
+
+   3. If delegations are present and glue information is required,
+      it should be present.
+
+
+
+Mockapetris                                                    [Page 35]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+   4. Information present outside of the authoritative nodes in the
+      zone should be glue information, rather than the result of an
+      origin or similar error.
+
+5.3. Master file example
+
+The following is an example file which might be used to define the
+ISI.EDU zone.and is loaded with an origin of ISI.EDU:
+
+@   IN  SOA     VENERA      Action\.domains (
+                                 20     ; SERIAL
+                                 7200   ; REFRESH
+                                 600    ; RETRY
+                                 3600000; EXPIRE
+                                 60)    ; MINIMUM
+
+        NS      A.ISI.EDU.
+        NS      VENERA
+        NS      VAXA
+        MX      10      VENERA
+        MX      20      VAXA
+
+A       A       26.3.0.103
+
+VENERA  A       10.1.0.52
+        A       128.9.0.32
+
+VAXA    A       10.2.0.27
+        A       128.9.0.33
+
+
+$INCLUDE <SUBSYS>ISI-MAILBOXES.TXT
+
+Where the file <SUBSYS>ISI-MAILBOXES.TXT is:
+
+    MOE     MB      A.ISI.EDU.
+    LARRY   MB      A.ISI.EDU.
+    CURLEY  MB      A.ISI.EDU.
+    STOOGES MG      MOE
+            MG      LARRY
+            MG      CURLEY
+
+Note the use of the \ character in the SOA RR to specify the responsible
+person mailbox "Action.domains@E.ISI.EDU".
+
+
+
+
+
+
+
+Mockapetris                                                    [Page 36]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+6. NAME SERVER IMPLEMENTATION
+
+6.1. Architecture
+
+The optimal structure for the name server will depend on the host
+operating system and whether the name server is integrated with resolver
+operations, either by supporting recursive service, or by sharing its
+database with a resolver.  This section discusses implementation
+considerations for a name server which shares a database with a
+resolver, but most of these concerns are present in any name server.
+
+6.1.1. Control
+
+A name server must employ multiple concurrent activities, whether they
+are implemented as separate tasks in the host's OS or multiplexing
+inside a single name server program.  It is simply not acceptable for a
+name server to block the service of UDP requests while it waits for TCP
+data for refreshing or query activities.  Similarly, a name server
+should not attempt to provide recursive service without processing such
+requests in parallel, though it may choose to serialize requests from a
+single client, or to regard identical requests from the same client as
+duplicates.  A name server should not substantially delay requests while
+it reloads a zone from master files or while it incorporates a newly
+refreshed zone into its database.
+
+6.1.2. Database
+
+While name server implementations are free to use any internal data
+structures they choose, the suggested structure consists of three major
+parts:
+
+   - A "catalog" data structure which lists the zones available to
+     this server, and a "pointer" to the zone data structure.  The
+     main purpose of this structure is to find the nearest ancestor
+     zone, if any, for arriving standard queries.
+
+   - Separate data structures for each of the zones held by the
+     name server.
+
+   - A data structure for cached data. (or perhaps separate caches
+     for different classes)
+
+All of these data structures can be implemented an identical tree
+structure format, with different data chained off the nodes in different
+parts: in the catalog the data is pointers to zones, while in the zone
+and cache data structures, the data will be RRs.  In designing the tree
+framework the designer should recognize that query processing will need
+to traverse the tree using case-insensitive label comparisons; and that
+
+
+
+Mockapetris                                                    [Page 37]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+in real data, a few nodes have a very high branching factor (100-1000 or
+more), but the vast majority have a very low branching factor (0-1).
+
+One way to solve the case problem is to store the labels for each node
+in two pieces: a standardized-case representation of the label where all
+ASCII characters are in a single case, together with a bit mask that
+denotes which characters are actually of a different case.  The
+branching factor diversity can be handled using a simple linked list for
+a node until the branching factor exceeds some threshold, and
+transitioning to a hash structure after the threshold is exceeded.  In
+any case, hash structures used to store tree sections must insure that
+hash functions and procedures preserve the casing conventions of the
+DNS.
+
+The use of separate structures for the different parts of the database
+is motivated by several factors:
+
+   - The catalog structure can be an almost static structure that
+     need change only when the system administrator changes the
+     zones supported by the server.  This structure can also be
+     used to store parameters used to control refreshing
+     activities.
+
+   - The individual data structures for zones allow a zone to be
+     replaced simply by changing a pointer in the catalog.  Zone
+     refresh operations can build a new structure and, when
+     complete, splice it into the database via a simple pointer
+     replacement.  It is very important that when a zone is
+     refreshed, queries should not use old and new data
+     simultaneously.
+
+   - With the proper search procedures, authoritative data in zones
+     will always "hide", and hence take precedence over, cached
+     data.
+
+   - Errors in zone definitions that cause overlapping zones, etc.,
+     may cause erroneous responses to queries, but problem
+     determination is simplified, and the contents of one "bad"
+     zone can't corrupt another.
+
+   - Since the cache is most frequently updated, it is most
+     vulnerable to corruption during system restarts.  It can also
+     become full of expired RR data.  In either case, it can easily
+     be discarded without disturbing zone data.
+
+A major aspect of database design is selecting a structure which allows
+the name server to deal with crashes of the name server's host.  State
+information which a name server should save across system crashes
+
+
+
+Mockapetris                                                    [Page 38]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+includes the catalog structure (including the state of refreshing for
+each zone) and the zone data itself.
+
+6.1.3. Time
+
+Both the TTL data for RRs and the timing data for refreshing activities
+depends on 32 bit timers in units of seconds.  Inside the database,
+refresh timers and TTLs for cached data conceptually "count down", while
+data in the zone stays with constant TTLs.
+
+A recommended implementation strategy is to store time in two ways:  as
+a relative increment and as an absolute time.  One way to do this is to
+use positive 32 bit numbers for one type and negative numbers for the
+other.  The RRs in zones use relative times; the refresh timers and
+cache data use absolute times.  Absolute numbers are taken with respect
+to some known origin and converted to relative values when placed in the
+response to a query.  When an absolute TTL is negative after conversion
+to relative, then the data is expired and should be ignored.
+
+6.2. Standard query processing
+
+The major algorithm for standard query processing is presented in
+[RFC-1034].
+
+When processing queries with QCLASS=*, or some other QCLASS which
+matches multiple classes, the response should never be authoritative
+unless the server can guarantee that the response covers all classes.
+
+When composing a response, RRs which are to be inserted in the
+additional section, but duplicate RRs in the answer or authority
+sections, may be omitted from the additional section.
+
+When a response is so long that truncation is required, the truncation
+should start at the end of the response and work forward in the
+datagram.  Thus if there is any data for the authority section, the
+answer section is guaranteed to be unique.
+
+The MINIMUM value in the SOA should be used to set a floor on the TTL of
+data distributed from a zone.  This floor function should be done when
+the data is copied into a response.  This will allow future dynamic
+update protocols to change the SOA MINIMUM field without ambiguous
+semantics.
+
+6.3. Zone refresh and reload processing
+
+In spite of a server's best efforts, it may be unable to load zone data
+from a master file due to syntax errors, etc., or be unable to refresh a
+zone within the its expiration parameter.  In this case, the name server
+
+
+
+Mockapetris                                                    [Page 39]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+should answer queries as if it were not supposed to possess the zone.
+
+If a master is sending a zone out via AXFR, and a new version is created
+during the transfer, the master should continue to send the old version
+if possible.  In any case, it should never send part of one version and
+part of another.  If completion is not possible, the master should reset
+the connection on which the zone transfer is taking place.
+
+6.4. Inverse queries (Optional)
+
+Inverse queries are an optional part of the DNS.  Name servers are not
+required to support any form of inverse queries.  If a name server
+receives an inverse query that it does not support, it returns an error
+response with the "Not Implemented" error set in the header.  While
+inverse query support is optional, all name servers must be at least
+able to return the error response.
+
+6.4.1. The contents of inverse queries and responses          Inverse
+queries reverse the mappings performed by standard query operations;
+while a standard query maps a domain name to a resource, an inverse
+query maps a resource to a domain name.  For example, a standard query
+might bind a domain name to a host address; the corresponding inverse
+query binds the host address to a domain name.
+
+Inverse queries take the form of a single RR in the answer section of
+the message, with an empty question section.  The owner name of the
+query RR and its TTL are not significant.  The response carries
+questions in the question section which identify all names possessing
+the query RR WHICH THE NAME SERVER KNOWS.  Since no name server knows
+about all of the domain name space, the response can never be assumed to
+be complete.  Thus inverse queries are primarily useful for database
+management and debugging activities.  Inverse queries are NOT an
+acceptable method of mapping host addresses to host names; use the IN-
+ADDR.ARPA domain instead.
+
+Where possible, name servers should provide case-insensitive comparisons
+for inverse queries.  Thus an inverse query asking for an MX RR of
+"Venera.isi.edu" should get the same response as a query for
+"VENERA.ISI.EDU"; an inverse query for HINFO RR "IBM-PC UNIX" should
+produce the same result as an inverse query for "IBM-pc unix".  However,
+this cannot be guaranteed because name servers may possess RRs that
+contain character strings but the name server does not know that the
+data is character.
+
+When a name server processes an inverse query, it either returns:
+
+   1. zero, one, or multiple domain names for the specified
+      resource as QNAMEs in the question section
+
+
+
+Mockapetris                                                    [Page 40]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+   2. an error code indicating that the name server doesn't support
+      inverse mapping of the specified resource type.
+
+When the response to an inverse query contains one or more QNAMEs, the
+owner name and TTL of the RR in the answer section which defines the
+inverse query is modified to exactly match an RR found at the first
+QNAME.
+
+RRs returned in the inverse queries cannot be cached using the same
+mechanism as is used for the replies to standard queries.  One reason
+for this is that a name might have multiple RRs of the same type, and
+only one would appear.  For example, an inverse query for a single
+address of a multiply homed host might create the impression that only
+one address existed.
+
+6.4.2. Inverse query and response example          The overall structure
+of an inverse query for retrieving the domain name that corresponds to
+Internet address 10.1.0.52 is shown below:
+
+                         +-----------------------------------------+
+           Header        |          OPCODE=IQUERY, ID=997          |
+                         +-----------------------------------------+
+          Question       |                 <empty>                 |
+                         +-----------------------------------------+
+           Answer        |        <anyname> A IN 10.1.0.52         |
+                         +-----------------------------------------+
+          Authority      |                 <empty>                 |
+                         +-----------------------------------------+
+         Additional      |                 <empty>                 |
+                         +-----------------------------------------+
+
+This query asks for a question whose answer is the Internet style
+address 10.1.0.52.  Since the owner name is not known, any domain name
+can be used as a placeholder (and is ignored).  A single octet of zero,
+signifying the root, is usually used because it minimizes the length of
+the message.  The TTL of the RR is not significant.  The response to
+this query might be:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mockapetris                                                    [Page 41]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+                         +-----------------------------------------+
+           Header        |         OPCODE=RESPONSE, ID=997         |
+                         +-----------------------------------------+
+          Question       |QTYPE=A, QCLASS=IN, QNAME=VENERA.ISI.EDU |
+                         +-----------------------------------------+
+           Answer        |  VENERA.ISI.EDU  A IN 10.1.0.52         |
+                         +-----------------------------------------+
+          Authority      |                 <empty>                 |
+                         +-----------------------------------------+
+         Additional      |                 <empty>                 |
+                         +-----------------------------------------+
+
+Note that the QTYPE in a response to an inverse query is the same as the
+TYPE field in the answer section of the inverse query.  Responses to
+inverse queries may contain multiple questions when the inverse is not
+unique.  If the question section in the response is not empty, then the
+RR in the answer section is modified to correspond to be an exact copy
+of an RR at the first QNAME.
+
+6.4.3. Inverse query processing
+
+Name servers that support inverse queries can support these operations
+through exhaustive searches of their databases, but this becomes
+impractical as the size of the database increases.  An alternative
+approach is to invert the database according to the search key.
+
+For name servers that support multiple zones and a large amount of data,
+the recommended approach is separate inversions for each zone.  When a
+particular zone is changed during a refresh, only its inversions need to
+be redone.
+
+Support for transfer of this type of inversion may be included in future
+versions of the domain system, but is not supported in this version.
+
+6.5. Completion queries and responses
+
+The optional completion services described in RFC-882 and RFC-883 have
+been deleted.  Redesigned services may become available in the future.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mockapetris                                                    [Page 42]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+7. RESOLVER IMPLEMENTATION
+
+The top levels of the recommended resolver algorithm are discussed in
+[RFC-1034].  This section discusses implementation details assuming the
+database structure suggested in the name server implementation section
+of this memo.
+
+7.1. Transforming a user request into a query
+
+The first step a resolver takes is to transform the client's request,
+stated in a format suitable to the local OS, into a search specification
+for RRs at a specific name which match a specific QTYPE and QCLASS.
+Where possible, the QTYPE and QCLASS should correspond to a single type
+and a single class, because this makes the use of cached data much
+simpler.  The reason for this is that the presence of data of one type
+in a cache doesn't confirm the existence or non-existence of data of
+other types, hence the only way to be sure is to consult an
+authoritative source.  If QCLASS=* is used, then authoritative answers
+won't be available.
+
+Since a resolver must be able to multiplex multiple requests if it is to
+perform its function efficiently, each pending request is usually
+represented in some block of state information.  This state block will
+typically contain:
+
+   - A timestamp indicating the time the request began.
+     The timestamp is used to decide whether RRs in the database
+     can be used or are out of date.  This timestamp uses the
+     absolute time format previously discussed for RR storage in
+     zones and caches.  Note that when an RRs TTL indicates a
+     relative time, the RR must be timely, since it is part of a
+     zone.  When the RR has an absolute time, it is part of a
+     cache, and the TTL of the RR is compared against the timestamp
+     for the start of the request.
+
+     Note that using the timestamp is superior to using a current
+     time, since it allows RRs with TTLs of zero to be entered in
+     the cache in the usual manner, but still used by the current
+     request, even after intervals of many seconds due to system
+     load, query retransmission timeouts, etc.
+
+   - Some sort of parameters to limit the amount of work which will
+     be performed for this request.
+
+     The amount of work which a resolver will do in response to a
+     client request must be limited to guard against errors in the
+     database, such as circular CNAME references, and operational
+     problems, such as network partition which prevents the
+
+
+
+Mockapetris                                                    [Page 43]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+     resolver from accessing the name servers it needs.  While
+     local limits on the number of times a resolver will retransmit
+     a particular query to a particular name server address are
+     essential, the resolver should have a global per-request
+     counter to limit work on a single request.  The counter should
+     be set to some initial value and decremented whenever the
+     resolver performs any action (retransmission timeout,
+     retransmission, etc.)  If the counter passes zero, the request
+     is terminated with a temporary error.
+
+     Note that if the resolver structure allows one request to
+     start others in parallel, such as when the need to access a
+     name server for one request causes a parallel resolve for the
+     name server's addresses, the spawned request should be started
+     with a lower counter.  This prevents circular references in
+     the database from starting a chain reaction of resolver
+     activity.
+
+   - The SLIST data structure discussed in [RFC-1034].
+
+     This structure keeps track of the state of a request if it
+     must wait for answers from foreign name servers.
+
+7.2. Sending the queries
+
+As described in [RFC-1034], the basic task of the resolver is to
+formulate a query which will answer the client's request and direct that
+query to name servers which can provide the information.  The resolver
+will usually only have very strong hints about which servers to ask, in
+the form of NS RRs, and may have to revise the query, in response to
+CNAMEs, or revise the set of name servers the resolver is asking, in
+response to delegation responses which point the resolver to name
+servers closer to the desired information.  In addition to the
+information requested by the client, the resolver may have to call upon
+its own services to determine the address of name servers it wishes to
+contact.
+
+In any case, the model used in this memo assumes that the resolver is
+multiplexing attention between multiple requests, some from the client,
+and some internally generated.  Each request is represented by some
+state information, and the desired behavior is that the resolver
+transmit queries to name servers in a way that maximizes the probability
+that the request is answered, minimizes the time that the request takes,
+and avoids excessive transmissions.  The key algorithm uses the state
+information of the request to select the next name server address to
+query, and also computes a timeout which will cause the next action
+should a response not arrive.  The next action will usually be a
+transmission to some other server, but may be a temporary error to the
+
+
+
+Mockapetris                                                    [Page 44]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+client.
+
+The resolver always starts with a list of server names to query (SLIST).
+This list will be all NS RRs which correspond to the nearest ancestor
+zone that the resolver knows about.  To avoid startup problems, the
+resolver should have a set of default servers which it will ask should
+it have no current NS RRs which are appropriate.  The resolver then adds
+to SLIST all of the known addresses for the name servers, and may start
+parallel requests to acquire the addresses of the servers when the
+resolver has the name, but no addresses, for the name servers.
+
+To complete initialization of SLIST, the resolver attaches whatever
+history information it has to the each address in SLIST.  This will
+usually consist of some sort of weighted averages for the response time
+of the address, and the batting average of the address (i.e., how often
+the address responded at all to the request).  Note that this
+information should be kept on a per address basis, rather than on a per
+name server basis, because the response time and batting average of a
+particular server may vary considerably from address to address.  Note
+also that this information is actually specific to a resolver address /
+server address pair, so a resolver with multiple addresses may wish to
+keep separate histories for each of its addresses.  Part of this step
+must deal with addresses which have no such history; in this case an
+expected round trip time of 5-10 seconds should be the worst case, with
+lower estimates for the same local network, etc.
+
+Note that whenever a delegation is followed, the resolver algorithm
+reinitializes SLIST.
+
+The information establishes a partial ranking of the available name
+server addresses.  Each time an address is chosen and the state should
+be altered to prevent its selection again until all other addresses have
+been tried.  The timeout for each transmission should be 50-100% greater
+than the average predicted value to allow for variance in response.
+
+Some fine points:
+
+   - The resolver may encounter a situation where no addresses are
+     available for any of the name servers named in SLIST, and
+     where the servers in the list are precisely those which would
+     normally be used to look up their own addresses.  This
+     situation typically occurs when the glue address RRs have a
+     smaller TTL than the NS RRs marking delegation, or when the
+     resolver caches the result of a NS search.  The resolver
+     should detect this condition and restart the search at the
+     next ancestor zone, or alternatively at the root.
+
+
+
+
+
+Mockapetris                                                    [Page 45]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+   - If a resolver gets a server error or other bizarre response
+     from a name server, it should remove it from SLIST, and may
+     wish to schedule an immediate transmission to the next
+     candidate server address.
+
+7.3. Processing responses
+
+The first step in processing arriving response datagrams is to parse the
+response.  This procedure should include:
+
+   - Check the header for reasonableness.  Discard datagrams which
+     are queries when responses are expected.
+
+   - Parse the sections of the message, and insure that all RRs are
+     correctly formatted.
+
+   - As an optional step, check the TTLs of arriving data looking
+     for RRs with excessively long TTLs.  If a RR has an
+     excessively long TTL, say greater than 1 week, either discard
+     the whole response, or limit all TTLs in the response to 1
+     week.
+
+The next step is to match the response to a current resolver request.
+The recommended strategy is to do a preliminary matching using the ID
+field in the domain header, and then to verify that the question section
+corresponds to the information currently desired.  This requires that
+the transmission algorithm devote several bits of the domain ID field to
+a request identifier of some sort.  This step has several fine points:
+
+   - Some name servers send their responses from different
+     addresses than the one used to receive the query.  That is, a
+     resolver cannot rely that a response will come from the same
+     address which it sent the corresponding query to.  This name
+     server bug is typically encountered in UNIX systems.
+
+   - If the resolver retransmits a particular request to a name
+     server it should be able to use a response from any of the
+     transmissions.  However, if it is using the response to sample
+     the round trip time to access the name server, it must be able
+     to determine which transmission matches the response (and keep
+     transmission times for each outgoing message), or only
+     calculate round trip times based on initial transmissions.
+
+   - A name server will occasionally not have a current copy of a
+     zone which it should have according to some NS RRs.  The
+     resolver should simply remove the name server from the current
+     SLIST, and continue.
+
+
+
+
+Mockapetris                                                    [Page 46]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+7.4. Using the cache
+
+In general, we expect a resolver to cache all data which it receives in
+responses since it may be useful in answering future client requests.
+However, there are several types of data which should not be cached:
+
+   - When several RRs of the same type are available for a
+     particular owner name, the resolver should either cache them
+     all or none at all.  When a response is truncated, and a
+     resolver doesn't know whether it has a complete set, it should
+     not cache a possibly partial set of RRs.
+
+   - Cached data should never be used in preference to
+     authoritative data, so if caching would cause this to happen
+     the data should not be cached.
+
+   - The results of an inverse query should not be cached.
+
+   - The results of standard queries where the QNAME contains "*"
+     labels if the data might be used to construct wildcards.  The
+     reason is that the cache does not necessarily contain existing
+     RRs or zone boundary information which is necessary to
+     restrict the application of the wildcard RRs.
+
+   - RR data in responses of dubious reliability.  When a resolver
+     receives unsolicited responses or RR data other than that
+     requested, it should discard it without caching it.  The basic
+     implication is that all sanity checks on a packet should be
+     performed before any of it is cached.
+
+In a similar vein, when a resolver has a set of RRs for some name in a
+response, and wants to cache the RRs, it should check its cache for
+already existing RRs.  Depending on the circumstances, either the data
+in the response or the cache is preferred, but the two should never be
+combined.  If the data in the response is from authoritative data in the
+answer section, it is always preferred.
+
+8. MAIL SUPPORT
+
+The domain system defines a standard for mapping mailboxes into domain
+names, and two methods for using the mailbox information to derive mail
+routing information.  The first method is called mail exchange binding
+and the other method is mailbox binding.  The mailbox encoding standard
+and mail exchange binding are part of the DNS official protocol, and are
+the recommended method for mail routing in the Internet.  Mailbox
+binding is an experimental feature which is still under development and
+subject to change.
+
+
+
+
+Mockapetris                                                    [Page 47]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+The mailbox encoding standard assumes a mailbox name of the form
+"<local-part>@<mail-domain>".  While the syntax allowed in each of these
+sections varies substantially between the various mail internets, the
+preferred syntax for the ARPA Internet is given in [RFC-822].
+
+The DNS encodes the <local-part> as a single label, and encodes the
+<mail-domain> as a domain name.  The single label from the <local-part>
+is prefaced to the domain name from <mail-domain> to form the domain
+name corresponding to the mailbox.  Thus the mailbox HOSTMASTER@SRI-
+NIC.ARPA is mapped into the domain name HOSTMASTER.SRI-NIC.ARPA.  If the
+<local-part> contains dots or other special characters, its
+representation in a master file will require the use of backslash
+quoting to ensure that the domain name is properly encoded.  For
+example, the mailbox Action.domains@ISI.EDU would be represented as
+Action\.domains.ISI.EDU.
+
+8.1. Mail exchange binding
+
+Mail exchange binding uses the <mail-domain> part of a mailbox
+specification to determine where mail should be sent.  The <local-part>
+is not even consulted.  [RFC-974] specifies this method in detail, and
+should be consulted before attempting to use mail exchange support.
+
+One of the advantages of this method is that it decouples mail
+destination naming from the hosts used to support mail service, at the
+cost of another layer of indirection in the lookup function.  However,
+the addition layer should eliminate the need for complicated "%", "!",
+etc encodings in <local-part>.
+
+The essence of the method is that the <mail-domain> is used as a domain
+name to locate type MX RRs which list hosts willing to accept mail for
+<mail-domain>, together with preference values which rank the hosts
+according to an order specified by the administrators for <mail-domain>.
+
+In this memo, the <mail-domain> ISI.EDU is used in examples, together
+with the hosts VENERA.ISI.EDU and VAXA.ISI.EDU as mail exchanges for
+ISI.EDU.  If a mailer had a message for Mockapetris@ISI.EDU, it would
+route it by looking up MX RRs for ISI.EDU.  The MX RRs at ISI.EDU name
+VENERA.ISI.EDU and VAXA.ISI.EDU, and type A queries can find the host
+addresses.
+
+8.2. Mailbox binding (Experimental)
+
+In mailbox binding, the mailer uses the entire mail destination
+specification to construct a domain name.  The encoded domain name for
+the mailbox is used as the QNAME field in a QTYPE=MAILB query.
+
+Several outcomes are possible for this query:
+
+
+
+Mockapetris                                                    [Page 48]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+   1. The query can return a name error indicating that the mailbox
+      does not exist as a domain name.
+
+      In the long term, this would indicate that the specified
+      mailbox doesn't exist.  However, until the use of mailbox
+      binding is universal, this error condition should be
+      interpreted to mean that the organization identified by the
+      global part does not support mailbox binding.  The
+      appropriate procedure is to revert to exchange binding at
+      this point.
+
+   2. The query can return a Mail Rename (MR) RR.
+
+      The MR RR carries new mailbox specification in its RDATA
+      field.  The mailer should replace the old mailbox with the
+      new one and retry the operation.
+
+   3. The query can return a MB RR.
+
+      The MB RR carries a domain name for a host in its RDATA
+      field.  The mailer should deliver the message to that host
+      via whatever protocol is applicable, e.g., b,SMTP.
+
+   4. The query can return one or more Mail Group (MG) RRs.
+
+      This condition means that the mailbox was actually a mailing
+      list or mail group, rather than a single mailbox.  Each MG RR
+      has a RDATA field that identifies a mailbox that is a member
+      of the group.  The mailer should deliver a copy of the
+      message to each member.
+
+   5. The query can return a MB RR as well as one or more MG RRs.
+
+      This condition means the the mailbox was actually a mailing
+      list.  The mailer can either deliver the message to the host
+      specified by the MB RR, which will in turn do the delivery to
+      all members, or the mailer can use the MG RRs to do the
+      expansion itself.
+
+In any of these cases, the response may include a Mail Information
+(MINFO) RR.  This RR is usually associated with a mail group, but is
+legal with a MB.  The MINFO RR identifies two mailboxes.  One of these
+identifies a responsible person for the original mailbox name.  This
+mailbox should be used for requests to be added to a mail group, etc.
+The second mailbox name in the MINFO RR identifies a mailbox that should
+receive error messages for mail failures.  This is particularly
+appropriate for mailing lists when errors in member names should be
+reported to a person other than the one who sends a message to the list.
+
+
+
+Mockapetris                                                    [Page 49]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+New fields may be added to this RR in the future.
+
+
+9. REFERENCES and BIBLIOGRAPHY
+
+[Dyer 87]       S. Dyer, F. Hsu, "Hesiod", Project Athena
+                Technical Plan - Name Service, April 1987, version 1.9.
+
+                Describes the fundamentals of the Hesiod name service.
+
+[IEN-116]       J. Postel, "Internet Name Server", IEN-116,
+                USC/Information Sciences Institute, August 1979.
+
+                A name service obsoleted by the Domain Name System, but
+                still in use.
+
+[Quarterman 86] J. Quarterman, and J. Hoskins, "Notable Computer Networks",
+                Communications of the ACM, October 1986, volume 29, number
+                10.
+
+[RFC-742]       K. Harrenstien, "NAME/FINGER", RFC-742, Network
+                Information Center, SRI International, December 1977.
+
+[RFC-768]       J. Postel, "User Datagram Protocol", RFC-768,
+                USC/Information Sciences Institute, August 1980.
+
+[RFC-793]       J. Postel, "Transmission Control Protocol", RFC-793,
+                USC/Information Sciences Institute, September 1981.
+
+[RFC-799]       D. Mills, "Internet Name Domains", RFC-799, COMSAT,
+                September 1981.
+
+                Suggests introduction of a hierarchy in place of a flat
+                name space for the Internet.
+
+[RFC-805]       J. Postel, "Computer Mail Meeting Notes", RFC-805,
+                USC/Information Sciences Institute, February 1982.
+
+[RFC-810]       E. Feinler, K. Harrenstien, Z. Su, and V. White, "DOD
+                Internet Host Table Specification", RFC-810, Network
+                Information Center, SRI International, March 1982.
+
+                Obsolete.  See RFC-952.
+
+[RFC-811]       K. Harrenstien, V. White, and E. Feinler, "Hostnames
+                Server", RFC-811, Network Information Center, SRI
+                International, March 1982.
+
+
+
+
+Mockapetris                                                    [Page 50]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+                Obsolete.  See RFC-953.
+
+[RFC-812]       K. Harrenstien, and V. White, "NICNAME/WHOIS", RFC-812,
+                Network Information Center, SRI International, March
+                1982.
+
+[RFC-819]       Z. Su, and J. Postel, "The Domain Naming Convention for
+                Internet User Applications", RFC-819, Network
+                Information Center, SRI International, August 1982.
+
+                Early thoughts on the design of the domain system.
+                Current implementation is completely different.
+
+[RFC-821]       J. Postel, "Simple Mail Transfer Protocol", RFC-821,
+                USC/Information Sciences Institute, August 1980.
+
+[RFC-830]       Z. Su, "A Distributed System for Internet Name Service",
+                RFC-830, Network Information Center, SRI International,
+                October 1982.
+
+                Early thoughts on the design of the domain system.
+                Current implementation is completely different.
+
+[RFC-882]       P. Mockapetris, "Domain names - Concepts and
+                Facilities," RFC-882, USC/Information Sciences
+                Institute, November 1983.
+
+                Superceeded by this memo.
+
+[RFC-883]       P. Mockapetris, "Domain names - Implementation and
+                Specification," RFC-883, USC/Information Sciences
+                Institute, November 1983.
+
+                Superceeded by this memo.
+
+[RFC-920]       J. Postel and J. Reynolds, "Domain Requirements",
+                RFC-920, USC/Information Sciences Institute,
+                October 1984.
+
+                Explains the naming scheme for top level domains.
+
+[RFC-952]       K. Harrenstien, M. Stahl, E. Feinler, "DoD Internet Host
+                Table Specification", RFC-952, SRI, October 1985.
+
+                Specifies the format of HOSTS.TXT, the host/address
+                table replaced by the DNS.
+
+
+
+
+
+Mockapetris                                                    [Page 51]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+[RFC-953]       K. Harrenstien, M. Stahl, E. Feinler, "HOSTNAME Server",
+                RFC-953, SRI, October 1985.
+
+                This RFC contains the official specification of the
+                hostname server protocol, which is obsoleted by the DNS.
+                This TCP based protocol accesses information stored in
+                the RFC-952 format, and is used to obtain copies of the
+                host table.
+
+[RFC-973]       P. Mockapetris, "Domain System Changes and
+                Observations", RFC-973, USC/Information Sciences
+                Institute, January 1986.
+
+                Describes changes to RFC-882 and RFC-883 and reasons for
+                them.
+
+[RFC-974]       C. Partridge, "Mail routing and the domain system",
+                RFC-974, CSNET CIC BBN Labs, January 1986.
+
+                Describes the transition from HOSTS.TXT based mail
+                addressing to the more powerful MX system used with the
+                domain system.
+
+[RFC-1001]      NetBIOS Working Group, "Protocol standard for a NetBIOS
+                service on a TCP/UDP transport: Concepts and Methods",
+                RFC-1001, March 1987.
+
+                This RFC and RFC-1002 are a preliminary design for
+                NETBIOS on top of TCP/IP which proposes to base NetBIOS
+                name service on top of the DNS.
+
+[RFC-1002]      NetBIOS Working Group, "Protocol standard for a NetBIOS
+                service on a TCP/UDP transport: Detailed
+                Specifications", RFC-1002, March 1987.
+
+[RFC-1010]      J. Reynolds, and J. Postel, "Assigned Numbers", RFC-1010,
+                USC/Information Sciences Institute, May 1987.
+
+                Contains socket numbers and mnemonics for host names,
+                operating systems, etc.
+
+[RFC-1031]      W. Lazear, "MILNET Name Domain Transition", RFC-1031,
+                November 1987.
+
+                Describes a plan for converting the MILNET to the DNS.
+
+[RFC-1032]      M. Stahl, "Establishing a Domain - Guidelines for
+                Administrators", RFC-1032, November 1987.
+
+
+
+Mockapetris                                                    [Page 52]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+                Describes the registration policies used by the NIC to
+                administer the top level domains and delegate subzones.
+
+[RFC-1033]      M. Lottor, "Domain Administrators Operations Guide",
+                RFC-1033, November 1987.
+
+                A cookbook for domain administrators.
+
+[Solomon 82]    M. Solomon, L. Landweber, and D. Neuhengen, "The CSNET
+                Name Server", Computer Networks, vol 6, nr 3, July 1982.
+
+                Describes a name service for CSNET which is independent
+                from the DNS and DNS use in the CSNET.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mockapetris                                                    [Page 53]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+Index
+
+          *   13
+
+          ;   33, 35
+
+          <character-string>   35
+          <domain-name>   34
+
+          @   35
+
+          \   35
+
+          A   12
+
+          Byte order   8
+
+          CH   13
+          Character case   9
+          CLASS   11
+          CNAME   12
+          Completion   42
+          CS   13
+
+          Hesiod   13
+          HINFO   12
+          HS   13
+
+          IN   13
+          IN-ADDR.ARPA domain   22
+          Inverse queries   40
+
+          Mailbox names   47
+          MB   12
+          MD   12
+          MF   12
+          MG   12
+          MINFO   12
+          MINIMUM   20
+          MR   12
+          MX   12
+
+          NS   12
+          NULL   12
+
+          Port numbers   32
+          Primary server   5
+          PTR   12, 18
+
+
+
+Mockapetris                                                    [Page 54]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+          QCLASS   13
+          QTYPE   12
+
+          RDATA   12
+          RDLENGTH  11
+
+          Secondary server   5
+          SOA   12
+          Stub resolvers   7
+
+          TCP   32
+          TXT   12
+          TYPE   11
+
+          UDP   32
+
+          WKS   12
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mockapetris                                                    [Page 55]
+
diff --git a/doc/rfc/rfc1101.txt b/doc/rfc/rfc1101.txt
new file mode 100644
index 0000000..66c9d8b
--- /dev/null
+++ b/doc/rfc/rfc1101.txt
@@ -0,0 +1,787 @@
+
+
+
+
+
+
+Network Working Group                                     P. Mockapetris
+Request for Comments: 1101                                           ISI
+Updates: RFCs 1034, 1035                                      April 1989
+
+
+             DNS Encoding of Network Names and Other Types
+
+
+1. STATUS OF THIS MEMO
+
+   This RFC proposes two extensions to the Domain Name System:
+
+      - A specific method for entering and retrieving RRs which map
+        between network names and numbers.
+
+      - Ideas for a general method for describing mappings between
+        arbitrary identifiers and numbers.
+
+   The method for mapping between network names and addresses is a
+   proposed standard, the ideas for a general method are experimental.
+
+   This RFC assumes that the reader is familiar with the DNS [RFC 1034,
+   RFC 1035] and its use.  The data shown is for pedagogical use and
+   does not necessarily reflect the real Internet.
+
+   Distribution of this memo is unlimited.
+
+2. INTRODUCTION
+
+   The DNS is extensible and can be used for a virtually unlimited
+   number of data types, name spaces, etc.  New type definitions are
+   occasionally necessary as are revisions or deletions of old types
+   (e.g., MX replacement of MD and MF [RFC 974]), and changes described
+   in [RFC 973].  This RFC describes changes due to the general need to
+   map between identifiers and values, and a specific need for network
+   name support.
+
+   Users wish to be able to use the DNS to map between network names and
+   numbers.  This need is the only capability found in HOSTS.TXT which
+   is not available from the DNS.  In designing a method to do this,
+   there were two major areas of concern:
+
+      - Several tradeoffs involving control of network names, the
+        syntax of network names, backward compatibility, etc.
+
+      - A desire to create a method which would be sufficiently
+        general to set a good precedent for future mappings,
+        for example, between TCP-port names and numbers,
+
+
+
+Mockapetris                                                     [Page 1]
+
+RFC 1101     DNS Encoding of Network Names and Other Types    April 1989
+
+
+        autonomous system names and numbers, X.500 Relative
+        Distinguished Names (RDNs) and their servers, or whatever.
+
+   It was impossible to reconcile these two areas of concern for network
+   names because of the desire to unify network number support within
+   existing IP address to host name support.  The existing support is
+   the IN-ADDR.ARPA section of the DNS name space.  As a result this RFC
+   describes one structure for network names which builds on the
+   existing support for host names, and another family of structures for
+   future yellow pages (YP) functions such as conversions between TCP-
+   port numbers and mnemonics.
+
+   Both structures are described in following sections.  Each structure
+   has a discussion of design issues and specific structure
+   recommendations.
+
+   We wish to avoid defining structures and methods which can work but
+   do not because of indifference or errors on the part of system
+   administrators when maintaining the database.  The WKS RR is an
+   example.  Thus, while we favor distribution as a general method, we
+   also recognize that centrally maintained tables (such as HOSTS.TXT)
+   are usually more consistent though less maintainable and timely.
+   Hence we recommend both specific methods for mapping network names,
+   addresses, and subnets, as well as an instance of the general method
+   for mapping between allocated network numbers and network names.
+   (Allocation is centrally performed by the SRI Network Information
+   Center, aka the NIC).
+
+3. NETWORK NAME ISSUES AND DISCUSSION
+
+   The issues involved in the design were the definition of network name
+   syntax, the mappings to be provided, and possible support for similar
+   functions at the subnet level.
+
+3.1. Network name syntax
+
+   The current syntax for network names, as defined by [RFC 952] is an
+   alphanumeric string of up to 24 characters, which begins with an
+   alpha, and may include "." and "-" except as first and last
+   characters.  This is the format which was also used for host names
+   before the DNS.  Upward compatibility with existing names might be a
+   goal of any new scheme.
+
+   However, the present syntax has been used to define a flat name
+   space, and hence would prohibit the same distributed name allocation
+   method used for host names.  There is some sentiment for allowing the
+   NIC to continue to allocate and regulate network names, much as it
+   allocates numbers, but the majority opinion favors local control of
+
+
+
+Mockapetris                                                     [Page 2]
+
+RFC 1101     DNS Encoding of Network Names and Other Types    April 1989
+
+
+   network names.  Although it would be possible to provide a flat space
+   or a name space in which, for example, the last label of a domain
+   name captured the old-style network name, any such approach would add
+   complexity to the method and create different rules for network names
+   and host names.
+
+   For these reasons, we assume that the syntax of network names will be
+   the same as the expanded syntax for host names permitted in [HR].
+   The new syntax expands the set of names to allow leading digits, so
+   long as the resulting representations do not conflict with IP
+   addresses in decimal octet form.  For example, 3Com.COM and 3M.COM
+   are now legal, although 26.0.0.73.COM is not.  See [HR] for details.
+
+   The price is that network names will get as complicated as host
+   names.  An administrator will be able to create network names in any
+   domain under his control, and also create network number to name
+   entries in IN-ADDR.ARPA domains under his control.  Thus, the name
+   for the ARPANET might become NET.ARPA, ARPANET.ARPA or Arpa-
+   network.MIL., depending on the preferences of the owner.
+
+3.2. Mappings
+
+   The desired mappings, ranked by priority with most important first,
+   are:
+
+      - Mapping a IP address or network number to a network name.
+
+        This mapping is for use in debugging tools and status displays
+        of various sorts.  The conversion from IP address to network
+        number is well known for class A, B, and C IP addresses, and
+        involves a simple mask operation.  The needs of other classes
+        are not yet defined and are ignored for the rest of this RFC.
+
+      - Mapping a network name to a network address.
+
+        This facility is of less obvious application, but a
+        symmetrical mapping seems desirable.
+
+      - Mapping an organization to its network names and numbers.
+
+        This facility is useful because it may not always be possible
+        to guess the local choice for network names, but the
+        organization name is often well known.
+
+      - Similar mappings for subnets, even when nested.
+
+        The primary application is to be able to identify all of the
+        subnets involved in a particular IP address.  A secondary
+
+
+
+Mockapetris                                                     [Page 3]
+
+RFC 1101     DNS Encoding of Network Names and Other Types    April 1989
+
+
+        requirement is to retrieve address mask information.
+
+3.3. Network address section of the name space
+
+   The network name syntax discussed above can provide domain names
+   which will contain mappings from network names to various quantities,
+   but we also need a section of the name space, organized by network
+   and subnet number to hold the inverse mappings.
+
+   The choices include:
+
+      - The same network number slots already assigned and delegated
+        in the IN-ADDR.ARPA section of the name space.
+
+        For example, 10.IN-ADDR.ARPA for class A net 10,
+        2.128.IN-ADDR.ARPA for class B net 128.2, etc.
+
+      - Host-zero addresses in the IN-ADDR.ARPA tree.  (A host field
+        of all zero in an IP address is prohibited because of
+        confusion related to broadcast addresses, et al.)
+
+        For example, 0.0.0.10.IN-ADDR.ARPA for class A net 10,
+        0.0.2.128.IN-ADDR.arpa for class B net 128.2, etc.  Like the
+        first scheme, it uses in-place name space delegations to
+        distribute control.
+
+        The main advantage of this scheme over the first is that it
+        allows convenient names for subnets as well as networks.  A
+        secondary advantage is that it uses names which are not in use
+        already, and hence it is possible to test whether an
+        organization has entered this information in its domain
+        database.
+
+      - Some new section of the name space.
+
+        While this option provides the most opportunities, it creates
+        a need to delegate a whole new name space.  Since the IP
+        address space is so closely related to the network number
+        space, most believe that the overhead of creating such a new
+        space is overwhelming and would lead to the WKS syndrome.  (As
+        of February, 1989, approximately 400 sections of the
+        IN-ADDR.ARPA tree are already delegated, usually at network
+        boundaries.)
+
+
+
+
+
+
+
+
+Mockapetris                                                     [Page 4]
+
+RFC 1101     DNS Encoding of Network Names and Other Types    April 1989
+
+
+4. SPECIFICS FOR NETWORK NAME MAPPINGS
+
+   The proposed solution uses information stored at:
+
+      - Names in the IN-ADDR.ARPA tree that correspond to host-zero IP
+        addresses.  The same method is used for subnets in a nested
+        fashion.  For example, 0.0.0.10.IN-ADDR.ARPA. for net 10.
+
+        Two types of information are stored here: PTR RRs which point
+        to the network name in their data sections, and A RRs, which
+        are present if the network (or subnet) is subnetted further.
+        If a type A RR is present, then it has the address mask as its
+        data.  The general form is:
+
+        <reversed-host-zero-number>.IN-ADDR.ARPA. PTR <network-name>
+        <reversed-host-zero-number>.IN-ADDR.ARPA. A   <subnet-mask>
+
+        For example:
+
+        0.0.0.10.IN-ADDR.ARPA.  PTR     ARPANET.ARPA.
+
+        or
+
+        0.0.2.128.IN-ADDR.ARPA. PTR     cmu-net.cmu.edu.
+                                A       255.255.255.0
+
+        In general, this information will be added to an existing
+        master file for some IN-ADDR.ARPA domain for each network
+        involved.  Similar RRs can be used at host-zero subnet
+        entries.
+
+      - Names which are network names.
+
+        The data stored here is PTR RRs pointing at the host-zero
+        entries.  The general form is:
+
+        <network-name> ptr <reversed-host-zero-number>.IN-ADDR.ARPA
+
+        For example:
+
+        ARPANET.ARPA.           PTR     0.0.0.10.IN-ADDR.ARPA.
+
+        or
+
+        isi-net.isi.edu.        PTR     0.0.9.128.IN-ADDR.ARPA.
+
+        In general, this information will be inserted in the master
+        file for the domain name of the organization; this is a
+
+
+
+Mockapetris                                                     [Page 5]
+
+RFC 1101     DNS Encoding of Network Names and Other Types    April 1989
+
+
+        different file from that which holds the information below
+        IN-ADDR.ARPA.  Similar PTR RRs can be used at subnet names.
+
+      - Names corresponding to organizations.
+
+        The data here is one or more PTR RRs pointing at the
+        IN-ADDR.ARPA names corresponding to host-zero entries for
+        networks.
+
+        For example:
+
+        ISI.EDU.        PTR     0.0.9.128.IN-ADDR.ARPA.
+
+        MCC.COM.        PTR     0.167.5.192.IN-ADDR.ARPA.
+                        PTR     0.168.5.192.IN-ADDR.ARPA.
+                        PTR     0.169.5.192.IN-ADDR.ARPA.
+                        PTR     0.0.62.128.IN-ADDR.ARPA.
+
+4.1. A simple example
+
+   The ARPANET is a Class A network without subnets.  The RRs which
+   would be added, assuming the ARPANET.ARPA was selected as a network
+   name, would be:
+
+   ARPA.                   PTR     0.0.0.10.IN-ADDR.ARPA.
+
+   ARPANET.ARPA.           PTR     0.0.0.10.IN-ADDR.ARPA.
+
+   0.0.0.10.IN-ADDR.ARPA.  PTR     ARPANET.ARPA.
+
+   The first RR states that the organization named ARPA owns net 10 (It
+   might also own more network numbers, and these would be represented
+   with an additional RR per net.)  The second states that the network
+   name ARPANET.ARPA. maps to net 10.  The last states that net 10 is
+   named ARPANET.ARPA.
+
+   Note that all of the usual host and corresponding IN-ADDR.ARPA
+   entries would still be required.
+
+4.2. A complicated, subnetted example
+
+   The ISI network is 128.9, a class B number.  Suppose the ISI network
+   was organized into two levels of subnet, with the first level using
+   an additional 8 bits of address, and the second level using 4 bits,
+   for address masks of x'FFFFFF00' and X'FFFFFFF0'.
+
+   Then the following RRs would be entered in ISI's master file for the
+   ISI.EDU zone:
+
+
+
+Mockapetris                                                     [Page 6]
+
+RFC 1101     DNS Encoding of Network Names and Other Types    April 1989
+
+
+   ; Define network entry
+   isi-net.isi.edu.                PTR  0.0.9.128.IN-ADDR.ARPA.
+
+   ; Define first level subnets
+   div1-subnet.isi.edu.            PTR  0.1.9.128.IN-ADDR.ARPA.
+   div2-subnet.isi.edu.            PTR  0.2.9.128.IN-ADDR.ARPA.
+
+   ; Define second level subnets
+   inc-subsubnet.isi.edu.          PTR  16.2.9.128.IN-ADDR.ARPA.
+
+   in the 9.128.IN-ADDR.ARPA zone:
+
+   ; Define network number and address mask
+   0.0.9.128.IN-ADDR.ARPA.         PTR  isi-net.isi.edu.
+                                   A    255.255.255.0  ;aka X'FFFFFF00'
+
+   ; Define one of the first level subnet numbers and masks
+   0.1.9.128.IN-ADDR.ARPA.         PTR  div1-subnet.isi.edu.
+                                   A    255.255.255.240 ;aka X'FFFFFFF0'
+
+   ; Define another first level subnet number and mask
+   0.2.9.128.IN-ADDR.ARPA.         PTR  div2-subnet.isi.edu.
+                                   A    255.255.255.240 ;aka X'FFFFFFF0'
+
+   ; Define second level subnet number
+   16.2.9.128.IN-ADDR.ARPA.        PTR  inc-subsubnet.isi.edu.
+
+   This assumes that the ISI network is named isi-net.isi.edu., first
+   level subnets are named div1-subnet.isi.edu. and div2-
+   subnet.isi.edu., and a second level subnet is called inc-
+   subsubnet.isi.edu.  (In a real system as complicated as this there
+   would be more first and second level subnets defined, but we have
+   shown enough to illustrate the ideas.)
+
+4.3. Procedure for using an IP address to get network name
+
+   Depending on whether the IP address is class A, B, or C, mask off the
+   high one, two, or three bytes, respectively.  Reverse the octets,
+   suffix IN-ADDR.ARPA, and do a PTR query.
+
+   For example, suppose the IP address is 10.0.0.51.
+
+      1. Since this is a class A address, use a mask x'FF000000' and
+         get 10.0.0.0.
+
+      2. Construct the name 0.0.0.10.IN-ADDR.ARPA.
+
+      3. Do a PTR query.  Get back
+
+
+
+Mockapetris                                                     [Page 7]
+
+RFC 1101     DNS Encoding of Network Names and Other Types    April 1989
+
+
+         0.0.0.10.IN-ADDR.ARPA.  PTR     ARPANET.ARPA.
+
+      4. Conclude that the network name is "ARPANET.ARPA."
+
+   Suppose that the IP address is 128.9.2.17.
+
+      1. Since this is a class B address, use a mask of x'FFFF0000'
+         and get 128.9.0.0.
+
+      2. Construct the name 0.0.9.128.IN-ADDR.ARPA.
+
+      3. Do a PTR query.  Get back
+
+         0.0.9.128.IN-ADDR.ARPA.       PTR     isi-net.isi.edu
+
+      4. Conclude that the network name is "isi-net.isi.edu."
+
+4.4. Procedure for finding all subnets involved with an IP address
+
+   This is a simple extension of the IP address to network name method.
+   When the network entry is located, do a lookup for a possible A RR.
+   If the A RR is found, look up the next level of subnet using the
+   original IP address and the mask in the A RR.  Repeat this procedure
+   until no A RR is found.
+
+   For example, repeating the use of 128.9.2.17.
+
+      1. As before construct a query for 0.0.9.128.IN-ADDR.ARPA.
+         Retrieve:
+
+         0.0.9.128.IN-ADDR.ARPA.  PTR    isi-net.isi.edu.
+                                  A      255.255.255.0
+
+      2. Since an A RR was found, repeat using mask from RR
+         (255.255.255.0), constructing a query for
+         0.2.9.128.IN-ADDR.ARPA.  Retrieve:
+
+         0.2.9.128.IN-ADDR.ARPA.  PTR    div2-subnet.isi.edu.
+                                  A      255.255.255.240
+
+      3. Since another A RR was found, repeat using mask
+         255.255.255.240 (x'FFFFFFF0').  constructing a query for
+         16.2.9.128.IN-ADDR.ARPA.  Retrieve:
+
+         16.2.9.128.IN-ADDR.ARPA. PTR    inc-subsubnet.isi.edu.
+
+      4. Since no A RR is present at 16.2.9.128.IN-ADDR.ARPA., there
+         are no more subnet levels.
+
+
+
+Mockapetris                                                     [Page 8]
+
+RFC 1101     DNS Encoding of Network Names and Other Types    April 1989
+
+
+5. YP ISSUES AND DISCUSSION
+
+   The term "Yellow Pages" is used in almost as many ways as the term
+   "domain", so it is useful to define what is meant herein by YP.  The
+   general problem to be solved is to create a method for creating
+   mappings from one kind of identifier to another, often with an
+   inverse capability.  The traditional methods are to search or use a
+   precomputed index of some kind.
+
+   Searching is impractical when the search is too large, and
+   precomputed indexes are possible only when it is possible to specify
+   search criteria in advance, and pay for the resources necessary to
+   build the index.  For example, it is impractical to search the entire
+   domain tree to find a particular address RR, so we build the IN-
+   ADDR.ARPA YP.  Similarly, we could never build an Internet-wide index
+   of "hosts with a load average of less than 2" in less time than it
+   would take for the data to change, so indexes are a useless approach
+   for that problem.
+
+   Such a precomputed index is what we mean by YP, and we regard the
+   IN-ADDR.ARPA domain as the first instance of a YP in the DNS.
+   Although a single, centrally-managed YP for well-known values such as
+   TCP-port is desirable, we regard organization-specific YPs for, say,
+   locally defined TCP ports as a natural extension, as are combinations
+   of YPs using search lists to merge the two.
+
+   In examining Internet Numbers [RFC 997] and Assigned Numbers [RFC
+   1010], it is clear that there are several mappings which might be of
+   value.  For example:
+
+   <assigned-network-name> <==> <IP-address>
+   <autonomous-system-id>  <==> <number>
+   <protocol-id>           <==> <number>
+   <port-id>               <==> <number>
+   <ethernet-type>         <==> <number>
+   <public-data-net>       <==> <IP-address>
+
+   Following the IN-ADDR example, the YP takes the form of a domain tree
+   organized to optimize retrieval by search key and distribution via
+   normal DNS rules.  The name used as a key must include:
+
+      1. A well known origin.  For example, IN-ADDR.ARPA is the
+         current IP-address to host name YP.
+
+      2. A "from" data type.  This identifies the input type of the
+         mapping.  This is necessary because we may be mapping
+         something as anonymous as a number to any number of
+         mnemonics, etc.
+
+
+
+Mockapetris                                                     [Page 9]
+
+RFC 1101     DNS Encoding of Network Names and Other Types    April 1989
+
+
+      3. A "to" data type.  Since we assume several symmetrical
+         mnemonic <==> number mappings, this is also necessary.
+
+   This ordering reflects the natural scoping of control, and hence the
+   order of the components in a domain name.  Thus domain names would be
+   of the form:
+
+   <from-value>.<to-data-type>.<from-data-type>.<YP-origin>
+
+   To make this work, we need to define well-know strings for each of
+   these metavariables, as well as encoding rules for converting a
+   <from-value> into a domain name.  We might define:
+
+   <YP-origin>     :=YP
+   <from-data-type>:=TCP-port | IN-ADDR | Number |
+                     Assigned-network-number | Name
+   <to-data-type>  :=<from-data-type>
+
+   Note that "YP" is NOT a valid country code under [ISO 3166] (although
+   we may want to worry about the future), and the existence of a
+   syntactically valid <to-data-type>.<from-data-type> pair does not
+   imply that a meaningful mapping exists, or is even possible.
+
+   The encoding rules might be:
+
+   TCP-port        Six character alphanumeric
+
+   IN-ADDR         Reversed 4-octet decimal string
+
+   Number          decimal integer
+
+   Assigned-network-number
+                   Reversed 4-octet decimal string
+
+   Name            Domain name
+
+6. SPECIFICS FOR YP MAPPINGS
+
+6.1. TCP-PORT
+
+   $origin Number.TCP-port.YP.
+
+   23              PTR     TELNET.TCP-port.Number.YP.
+   25              PTR     SMTP.TCP-port.Number.YP.
+
+   $origin TCP-port.Number.YP.
+
+   TELNET          PTR     23.Number.TCP-port.YP.
+
+
+
+Mockapetris                                                    [Page 10]
+
+RFC 1101     DNS Encoding of Network Names and Other Types    April 1989
+
+
+   SMTP            PTR     25.Number.TCP-port.YP.
+
+   Thus the mapping between 23 and TELNET is represented by a pair of
+   PTR RRs, one for each direction of the mapping.
+
+6.2. Assigned networks
+
+   Network numbers are assigned by the NIC and reported in "Internet
+   Numbers" RFCs.  To create a YP, the NIC would set up two domains:
+
+   Name.Assigned-network-number.YP and Assigned-network-number.YP
+
+   The first would contain entries of the form:
+
+   $origin Name.Assigned-network-number.YP.
+
+   0.0.0.4         PTR     SATNET.Assigned-network-number.Name.YP.
+   0.0.0.10        PTR     ARPANET.Assigned-network-number.Name.YP.
+
+   The second would contain entries of the form:
+
+   $origin Assigned-network-number.Name.YP.
+
+   SATNET.         PTR     0.0.0.4.Name.Assigned-network-number.YP.
+   ARPANET.        PTR     0.0.0.10.Name.Assigned-network-number.YP.
+
+   These YPs are not in conflict with the network name support described
+   in the first half of this RFC since they map between ASSIGNED network
+   names and numbers, not those allocated by the organizations
+   themselves.  That is, they document the NIC's decisions about
+   allocating network numbers but do not automatically track any
+   renaming performed by the new owners.
+
+   As a practical matter, we might want to create both of these domains
+   to enable users on the Internet to experiment with centrally
+   maintained support as well as the distributed version, or might want
+   to implement only the allocated number to name mapping and request
+   organizations to convert their allocated network names to the network
+   names described in the distributed model.
+
+6.3. Operational improvements
+
+   We could imagine that all conversion routines using these YPs might
+   be instructed to use "YP.<local-domain>" followed by "YP."  as a
+   search list.  Thus, if the organization ISI.EDU wished to define
+   locally meaningful TCP-PORT, it would define the domains:
+
+   <TCP-port.Number.YP.ISI.EDU> and <Number.TCP-port.YP.ISI.EDU>.
+
+
+
+Mockapetris                                                    [Page 11]
+
+RFC 1101     DNS Encoding of Network Names and Other Types    April 1989
+
+
+   We could add another level of indirection in the YP lookup, defining
+   the <to-data-type>.<from-data-type>.<YP-origin> nodes to point to the
+   YP tree, rather than being the YP tree directly.  This would enable
+   entries of the form:
+
+   IN-ADDR.Netname.YP.   PTR     IN-ADDR.ARPA.
+
+   to splice in YPs from other origins or existing spaces.
+
+   Another possibility would be to shorten the RDATA section of the RRs
+   which map back and forth by deleting the origin.  This could be done
+   either by allowing the domain name in the RDATA portion to not
+   identify a real domain name, or by defining a new RR which used a
+   simple text string rather than a domain name.
+
+   Thus, we might replace
+
+   $origin Assigned-network-number.Name.YP.
+
+   SATNET.         PTR     0.0.0.4.Name.Assigned-network-number.YP.
+   ARPANET.        PTR     0.0.0.10.Name.Assigned-network-number.YP.
+
+   with
+
+   $origin Assigned-network-number.Name.YP.
+
+   SATNET.         PTR     0.0.0.4.
+   ARPANET.        PTR     0.0.0.10.
+
+   or
+
+   $origin Assigned-network-number.Name.YP.
+
+   SATNET.         PTT     "0.0.0.4"
+   ARPANET.        PTT     "0.0.0.10"
+
+   where PTT is a new type whose RDATA section is a text string.
+
+7. ACKNOWLEDGMENTS
+
+   Drew Perkins, Mark Lottor, and Rob Austein contributed several of the
+   ideas in this RFC.  Numerous contributions, criticisms, and
+   compromises were produced in the IETF Domain working group and the
+   NAMEDROPPERS mailing list.
+
+
+
+
+
+
+
+Mockapetris                                                    [Page 12]
+
+RFC 1101     DNS Encoding of Network Names and Other Types    April 1989
+
+
+8. REFERENCES
+
+   [HR]        Braden, B., editor, "Requirements for Internet Hosts",
+               RFC in preparation.
+
+   [ISO 3166]  ISO, "Codes for the Representation of Names of
+               Countries", 1981.
+
+   [RFC 882]   Mockapetris, P., "Domain names - Concepts and
+               Facilities", RFC 882, USC/Information Sciences Institute,
+               November 1983.
+
+               Superseded by RFC 1034.
+
+   [RFC 883]   Mockapetris, P.,"Domain names - Implementation and
+               Specification", RFC 883, USC/Information Sciences
+               Institute, November 1983.
+
+               Superceeded by RFC 1035.
+
+   [RFC 920]   Postel, J. and J. Reynolds, "Domain Requirements", RFC
+               920, October 1984.
+
+               Explains the naming scheme for top level domains.
+
+   [RFC 952]   Harrenstien, K., M. Stahl, and E. Feinler, "DoD Internet
+               Host Table Specification", RFC 952, SRI, October 1985.
+
+               Specifies the format of HOSTS.TXT, the host/address table
+               replaced by the DNS
+
+   [RFC 973]   Mockapetris, P., "Domain System Changes and
+               Observations", RFC 973, USC/Information Sciences
+               Institute, January 1986.
+
+               Describes changes to RFCs 882 and 883 and reasons for
+               them.
+
+   [RFC 974]   Partridge, C., "Mail routing and the domain system", RFC
+               974, CSNET CIC BBN Labs, January 1986.
+
+               Describes the transition from HOSTS.TXT based mail
+               addressing to the more powerful MX system used with the
+               domain system.
+
+
+
+
+
+
+
+Mockapetris                                                    [Page 13]
+
+RFC 1101     DNS Encoding of Network Names and Other Types    April 1989
+
+
+   [RFC 997]   Reynolds, J., and J. Postel, "Internet Numbers", RFC 997,
+               USC/Information Sciences Institute, March 1987
+
+               Contains network numbers, autonomous system numbers, etc.
+
+   [RFC 1010]  Reynolds, J., and J. Postel, "Assigned Numbers", RFC
+               1010, USC/Information Sciences Institute, May 1987
+
+               Contains socket numbers and mnemonics for host names,
+               operating systems, etc.
+
+
+   [RFC 1034]  Mockapetris, P., "Domain names - Concepts and
+               Facilities", RFC 1034, USC/Information Sciences
+               Institute, November 1987.
+
+               Introduction/overview of the DNS.
+
+   [RFC 1035]  Mockapetris, P., "Domain names - Implementation and
+               Specification", RFC 1035, USC/Information Sciences
+               Institute, November 1987.
+
+               DNS implementation instructions.
+
+Author's Address:
+
+   Paul Mockapetris
+   USC/Information Sciences Institute
+   4676 Admiralty Way
+   Marina del Rey, CA 90292
+
+   Phone: (213) 822-1511
+
+   Email: PVM@ISI.EDU
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mockapetris                                                    [Page 14]
+
\ No newline at end of file
diff --git a/doc/rfc/rfc1122.txt b/doc/rfc/rfc1122.txt
new file mode 100644
index 0000000..c14f2e5
--- /dev/null
+++ b/doc/rfc/rfc1122.txt
@@ -0,0 +1,6844 @@
+
+
+
+
+
+
+Network Working Group                    Internet Engineering Task Force
+Request for Comments: 1122                             R. Braden, Editor
+                                                            October 1989
+
+
+        Requirements for Internet Hosts -- Communication Layers
+
+
+Status of This Memo
+
+   This RFC is an official specification for the Internet community.  It
+   incorporates by reference, amends, corrects, and supplements the
+   primary protocol standards documents relating to hosts.  Distribution
+   of this document is unlimited.
+
+Summary
+
+   This is one RFC of a pair that defines and discusses the requirements
+   for Internet host software.  This RFC covers the communications
+   protocol layers: link layer, IP layer, and transport layer; its
+   companion RFC-1123 covers the application and support protocols.
+
+
+
+                           Table of Contents
+
+
+
+
+   1.  INTRODUCTION ...............................................    5
+      1.1  The Internet Architecture ..............................    6
+         1.1.1  Internet Hosts ....................................    6
+         1.1.2  Architectural Assumptions .........................    7
+         1.1.3  Internet Protocol Suite ...........................    8
+         1.1.4  Embedded Gateway Code .............................   10
+      1.2  General Considerations .................................   12
+         1.2.1  Continuing Internet Evolution .....................   12
+         1.2.2  Robustness Principle ..............................   12
+         1.2.3  Error Logging .....................................   13
+         1.2.4  Configuration .....................................   14
+      1.3  Reading this Document ..................................   15
+         1.3.1  Organization ......................................   15
+         1.3.2  Requirements ......................................   16
+         1.3.3  Terminology .......................................   17
+      1.4  Acknowledgments ........................................   20
+
+   2. LINK LAYER ..................................................   21
+      2.1  INTRODUCTION ...........................................   21
+
+
+
+Internet Engineering Task Force                                 [Page 1]
+
+
+
+
+RFC1122                       INTRODUCTION                  October 1989
+
+
+      2.2  PROTOCOL WALK-THROUGH ..................................   21
+      2.3  SPECIFIC ISSUES ........................................   21
+         2.3.1  Trailer Protocol Negotiation ......................   21
+         2.3.2  Address Resolution Protocol -- ARP ................   22
+            2.3.2.1  ARP Cache Validation .........................   22
+            2.3.2.2  ARP Packet Queue .............................   24
+         2.3.3  Ethernet and IEEE 802 Encapsulation ...............   24
+      2.4  LINK/INTERNET LAYER INTERFACE ..........................   25
+      2.5  LINK LAYER REQUIREMENTS SUMMARY ........................   26
+
+   3. INTERNET LAYER PROTOCOLS ....................................   27
+      3.1 INTRODUCTION ............................................   27
+      3.2  PROTOCOL WALK-THROUGH ..................................   29
+         3.2.1 Internet Protocol -- IP ............................   29
+            3.2.1.1  Version Number ...............................   29
+            3.2.1.2  Checksum .....................................   29
+            3.2.1.3  Addressing ...................................   29
+            3.2.1.4  Fragmentation and Reassembly .................   32
+            3.2.1.5  Identification ...............................   32
+            3.2.1.6  Type-of-Service ..............................   33
+            3.2.1.7  Time-to-Live .................................   34
+            3.2.1.8  Options ......................................   35
+         3.2.2 Internet Control Message Protocol -- ICMP ..........   38
+            3.2.2.1  Destination Unreachable ......................   39
+            3.2.2.2  Redirect .....................................   40
+            3.2.2.3  Source Quench ................................   41
+            3.2.2.4  Time Exceeded ................................   41
+            3.2.2.5  Parameter Problem ............................   42
+            3.2.2.6  Echo Request/Reply ...........................   42
+            3.2.2.7  Information Request/Reply ....................   43
+            3.2.2.8  Timestamp and Timestamp Reply ................   43
+            3.2.2.9  Address Mask Request/Reply ...................   45
+         3.2.3  Internet Group Management Protocol IGMP ...........   47
+      3.3  SPECIFIC ISSUES ........................................   47
+         3.3.1  Routing Outbound Datagrams ........................   47
+            3.3.1.1  Local/Remote Decision ........................   47
+            3.3.1.2  Gateway Selection ............................   48
+            3.3.1.3  Route Cache ..................................   49
+            3.3.1.4  Dead Gateway Detection .......................   51
+            3.3.1.5  New Gateway Selection ........................   55
+            3.3.1.6  Initialization ...............................   56
+         3.3.2  Reassembly ........................................   56
+         3.3.3  Fragmentation .....................................   58
+         3.3.4  Local Multihoming .................................   60
+            3.3.4.1  Introduction .................................   60
+            3.3.4.2  Multihoming Requirements .....................   61
+            3.3.4.3  Choosing a Source Address ....................   64
+         3.3.5  Source Route Forwarding ...........................   65
+
+
+
+Internet Engineering Task Force                                 [Page 2]
+
+
+
+
+RFC1122                       INTRODUCTION                  October 1989
+
+
+         3.3.6  Broadcasts ........................................   66
+         3.3.7  IP Multicasting ...................................   67
+         3.3.8  Error Reporting ...................................   69
+      3.4  INTERNET/TRANSPORT LAYER INTERFACE .....................   69
+      3.5  INTERNET LAYER REQUIREMENTS SUMMARY ....................   72
+
+   4. TRANSPORT PROTOCOLS .........................................   77
+      4.1  USER DATAGRAM PROTOCOL -- UDP ..........................   77
+         4.1.1  INTRODUCTION ......................................   77
+         4.1.2  PROTOCOL WALK-THROUGH .............................   77
+         4.1.3  SPECIFIC ISSUES ...................................   77
+            4.1.3.1  Ports ........................................   77
+            4.1.3.2  IP Options ...................................   77
+            4.1.3.3  ICMP Messages ................................   78
+            4.1.3.4  UDP Checksums ................................   78
+            4.1.3.5  UDP Multihoming ..............................   79
+            4.1.3.6  Invalid Addresses ............................   79
+         4.1.4  UDP/APPLICATION LAYER INTERFACE ...................   79
+         4.1.5  UDP REQUIREMENTS SUMMARY ..........................   80
+      4.2  TRANSMISSION CONTROL PROTOCOL -- TCP ...................   82
+         4.2.1  INTRODUCTION ......................................   82
+         4.2.2  PROTOCOL WALK-THROUGH .............................   82
+            4.2.2.1  Well-Known Ports .............................   82
+            4.2.2.2  Use of Push ..................................   82
+            4.2.2.3  Window Size ..................................   83
+            4.2.2.4  Urgent Pointer ...............................   84
+            4.2.2.5  TCP Options ..................................   85
+            4.2.2.6  Maximum Segment Size Option ..................   85
+            4.2.2.7  TCP Checksum .................................   86
+            4.2.2.8  TCP Connection State Diagram .................   86
+            4.2.2.9  Initial Sequence Number Selection ............   87
+            4.2.2.10  Simultaneous Open Attempts ..................   87
+            4.2.2.11  Recovery from Old Duplicate SYN .............   87
+            4.2.2.12  RST Segment .................................   87
+            4.2.2.13  Closing a Connection ........................   87
+            4.2.2.14  Data Communication ..........................   89
+            4.2.2.15  Retransmission Timeout ......................   90
+            4.2.2.16  Managing the Window .........................   91
+            4.2.2.17  Probing Zero Windows ........................   92
+            4.2.2.18  Passive OPEN Calls ..........................   92
+            4.2.2.19  Time to Live ................................   93
+            4.2.2.20  Event Processing ............................   93
+            4.2.2.21  Acknowledging Queued Segments ...............   94
+         4.2.3  SPECIFIC ISSUES ...................................   95
+            4.2.3.1  Retransmission Timeout Calculation ...........   95
+            4.2.3.2  When to Send an ACK Segment ..................   96
+            4.2.3.3  When to Send a Window Update .................   97
+            4.2.3.4  When to Send Data ............................   98
+
+
+
+Internet Engineering Task Force                                 [Page 3]
+
+
+
+
+RFC1122                       INTRODUCTION                  October 1989
+
+
+            4.2.3.5  TCP Connection Failures ......................  100
+            4.2.3.6  TCP Keep-Alives ..............................  101
+            4.2.3.7  TCP Multihoming ..............................  103
+            4.2.3.8  IP Options ...................................  103
+            4.2.3.9  ICMP Messages ................................  103
+            4.2.3.10  Remote Address Validation ...................  104
+            4.2.3.11  TCP Traffic Patterns ........................  104
+            4.2.3.12  Efficiency ..................................  105
+         4.2.4  TCP/APPLICATION LAYER INTERFACE ...................  106
+            4.2.4.1  Asynchronous Reports .........................  106
+            4.2.4.2  Type-of-Service ..............................  107
+            4.2.4.3  Flush Call ...................................  107
+            4.2.4.4  Multihoming ..................................  108
+         4.2.5  TCP REQUIREMENT SUMMARY ...........................  108
+
+   5.  REFERENCES .................................................  112
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Internet Engineering Task Force                                 [Page 4]
+
+
+
+
+RFC1122                       INTRODUCTION                  October 1989
+
+
+1.  INTRODUCTION
+
+   This document is one of a pair that defines and discusses the
+   requirements for host system implementations of the Internet protocol
+   suite.  This RFC covers the communication protocol layers:  link
+   layer, IP layer, and transport layer.  Its companion RFC,
+   "Requirements for Internet Hosts -- Application and Support"
+   [INTRO:1], covers the application layer protocols.  This document
+   should also be read in conjunction with "Requirements for Internet
+   Gateways" [INTRO:2].
+
+   These documents are intended to provide guidance for vendors,
+   implementors, and users of Internet communication software.  They
+   represent the consensus of a large body of technical experience and
+   wisdom, contributed by the members of the Internet research and
+   vendor communities.
+
+   This RFC enumerates standard protocols that a host connected to the
+   Internet must use, and it incorporates by reference the RFCs and
+   other documents describing the current specifications for these
+   protocols.  It corrects errors in the referenced documents and adds
+   additional discussion and guidance for an implementor.
+
+   For each protocol, this document also contains an explicit set of
+   requirements, recommendations, and options.  The reader must
+   understand that the list of requirements in this document is
+   incomplete by itself; the complete set of requirements for an
+   Internet host is primarily defined in the standard protocol
+   specification documents, with the corrections, amendments, and
+   supplements contained in this RFC.
+
+   A good-faith implementation of the protocols that was produced after
+   careful reading of the RFC's and with some interaction with the
+   Internet technical community, and that followed good communications
+   software engineering practices, should differ from the requirements
+   of this document in only minor ways.  Thus, in many cases, the
+   "requirements" in this RFC are already stated or implied in the
+   standard protocol documents, so that their inclusion here is, in a
+   sense, redundant.  However, they were included because some past
+   implementation has made the wrong choice, causing problems of
+   interoperability, performance, and/or robustness.
+
+   This document includes discussion and explanation of many of the
+   requirements and recommendations.  A simple list of requirements
+   would be dangerous, because:
+
+   o    Some required features are more important than others, and some
+        features are optional.
+
+
+
+Internet Engineering Task Force                                 [Page 5]
+
+
+
+
+RFC1122                       INTRODUCTION                  October 1989
+
+
+   o    There may be valid reasons why particular vendor products that
+        are designed for restricted contexts might choose to use
+        different specifications.
+
+   However, the specifications of this document must be followed to meet
+   the general goal of arbitrary host interoperation across the
+   diversity and complexity of the Internet system.  Although most
+   current implementations fail to meet these requirements in various
+   ways, some minor and some major, this specification is the ideal
+   towards which we need to move.
+
+   These requirements are based on the current level of Internet
+   architecture.  This document will be updated as required to provide
+   additional clarifications or to include additional information in
+   those areas in which specifications are still evolving.
+
+   This introductory section begins with a brief overview of the
+   Internet architecture as it relates to hosts, and then gives some
+   general advice to host software vendors.  Finally, there is some
+   guidance on reading the rest of the document and some terminology.
+
+   1.1  The Internet Architecture
+
+      General background and discussion on the Internet architecture and
+      supporting protocol suite can be found in the DDN Protocol
+      Handbook [INTRO:3]; for background see for example [INTRO:9],
+      [INTRO:10], and [INTRO:11].  Reference [INTRO:5] describes the
+      procedure for obtaining Internet protocol documents, while
+      [INTRO:6] contains a list of the numbers assigned within Internet
+      protocols.
+
+      1.1.1  Internet Hosts
+
+         A host computer, or simply "host," is the ultimate consumer of
+         communication services.  A host generally executes application
+         programs on behalf of user(s), employing network and/or
+         Internet communication services in support of this function.
+         An Internet host corresponds to the concept of an "End-System"
+         used in the OSI protocol suite [INTRO:13].
+
+         An Internet communication system consists of interconnected
+         packet networks supporting communication among host computers
+         using the Internet protocols.  The networks are interconnected
+         using packet-switching computers called "gateways" or "IP
+         routers" by the Internet community, and "Intermediate Systems"
+         by the OSI world [INTRO:13].  The RFC "Requirements for
+         Internet Gateways" [INTRO:2] contains the official
+         specifications for Internet gateways.  That RFC together with
+
+
+
+Internet Engineering Task Force                                 [Page 6]
+
+
+
+
+RFC1122                       INTRODUCTION                  October 1989
+
+
+         the present document and its companion [INTRO:1] define the
+         rules for the current realization of the Internet architecture.
+
+         Internet hosts span a wide range of size, speed, and function.
+         They range in size from small microprocessors through
+         workstations to mainframes and supercomputers.  In function,
+         they range from single-purpose hosts (such as terminal servers)
+         to full-service hosts that support a variety of online network
+         services, typically including remote login, file transfer, and
+         electronic mail.
+
+         A host is generally said to be multihomed if it has more than
+         one interface to the same or to different networks.  See
+         Section 1.1.3 on "Terminology".
+
+      1.1.2  Architectural Assumptions
+
+         The current Internet architecture is based on a set of
+         assumptions about the communication system.  The assumptions
+         most relevant to hosts are as follows:
+
+         (a)  The Internet is a network of networks.
+
+              Each host is directly connected to some particular
+              network(s); its connection to the Internet is only
+              conceptual.  Two hosts on the same network communicate
+              with each other using the same set of protocols that they
+              would use to communicate with hosts on distant networks.
+
+         (b)  Gateways don't keep connection state information.
+
+              To improve robustness of the communication system,
+              gateways are designed to be stateless, forwarding each IP
+              datagram independently of other datagrams.  As a result,
+              redundant paths can be exploited to provide robust service
+              in spite of failures of intervening gateways and networks.
+
+              All state information required for end-to-end flow control
+              and reliability is implemented in the hosts, in the
+              transport layer or in application programs.  All
+              connection control information is thus co-located with the
+              end points of the communication, so it will be lost only
+              if an end point fails.
+
+         (c)  Routing complexity should be in the gateways.
+
+              Routing is a complex and difficult problem, and ought to
+              be performed by the gateways, not the hosts.  An important
+
+
+
+Internet Engineering Task Force                                 [Page 7]
+
+
+
+
+RFC1122                       INTRODUCTION                  October 1989
+
+
+              objective is to insulate host software from changes caused
+              by the inevitable evolution of the Internet routing
+              architecture.
+
+         (d)  The System must tolerate wide network variation.
+
+              A basic objective of the Internet design is to tolerate a
+              wide range of network characteristics -- e.g., bandwidth,
+              delay, packet loss, packet reordering, and maximum packet
+              size.  Another objective is robustness against failure of
+              individual networks, gateways, and hosts, using whatever
+              bandwidth is still available.  Finally, the goal is full
+              "open system interconnection": an Internet host must be
+              able to interoperate robustly and effectively with any
+              other Internet host, across diverse Internet paths.
+
+              Sometimes host implementors have designed for less
+              ambitious goals.  For example, the LAN environment is
+              typically much more benign than the Internet as a whole;
+              LANs have low packet loss and delay and do not reorder
+              packets.  Some vendors have fielded host implementations
+              that are adequate for a simple LAN environment, but work
+              badly for general interoperation.  The vendor justifies
+              such a product as being economical within the restricted
+              LAN market.  However, isolated LANs seldom stay isolated
+              for long; they are soon gatewayed to each other, to
+              organization-wide internets, and eventually to the global
+              Internet system.  In the end, neither the customer nor the
+              vendor is served by incomplete or substandard Internet
+              host software.
+
+              The requirements spelled out in this document are designed
+              for a full-function Internet host, capable of full
+              interoperation over an arbitrary Internet path.
+
+
+      1.1.3  Internet Protocol Suite
+
+         To communicate using the Internet system, a host must implement
+         the layered set of protocols comprising the Internet protocol
+         suite.  A host typically must implement at least one protocol
+         from each layer.
+
+         The protocol layers used in the Internet architecture are as
+         follows [INTRO:4]:
+
+
+         o  Application Layer
+
+
+
+Internet Engineering Task Force                                 [Page 8]
+
+
+
+
+RFC1122                       INTRODUCTION                  October 1989
+
+
+              The application layer is the top layer of the Internet
+              protocol suite.  The Internet suite does not further
+              subdivide the application layer, although some of the
+              Internet application layer protocols do contain some
+              internal sub-layering.  The application layer of the
+              Internet suite essentially combines the functions of the
+              top two layers -- Presentation and Application -- of the
+              OSI reference model.
+
+              We distinguish two categories of application layer
+              protocols:  user protocols that provide service directly
+              to users, and support protocols that provide common system
+              functions.  Requirements for user and support protocols
+              will be found in the companion RFC [INTRO:1].
+
+              The most common Internet user protocols are:
+
+                o  Telnet (remote login)
+                o  FTP    (file transfer)
+                o  SMTP   (electronic mail delivery)
+
+              There are a number of other standardized user protocols
+              [INTRO:4] and many private user protocols.
+
+              Support protocols, used for host name mapping, booting,
+              and management, include SNMP, BOOTP, RARP, and the Domain
+              Name System (DNS) protocols.
+
+
+         o  Transport Layer
+
+              The transport layer provides end-to-end communication
+              services for applications.  There are two primary
+              transport layer protocols at present:
+
+                o Transmission Control Protocol (TCP)
+                o User Datagram Protocol (UDP)
+
+              TCP is a reliable connection-oriented transport service
+              that provides end-to-end reliability, resequencing, and
+              flow control.  UDP is a connectionless ("datagram")
+              transport service.
+
+              Other transport protocols have been developed by the
+              research community, and the set of official Internet
+              transport protocols may be expanded in the future.
+
+              Transport layer protocols are discussed in Chapter 4.
+
+
+
+Internet Engineering Task Force                                 [Page 9]
+
+
+
+
+RFC1122                       INTRODUCTION                  October 1989
+
+
+         o  Internet Layer
+
+              All Internet transport protocols use the Internet Protocol
+              (IP) to carry data from source host to destination host.
+              IP is a connectionless or datagram internetwork service,
+              providing no end-to-end delivery guarantees. Thus, IP
+              datagrams may arrive at the destination host damaged,
+              duplicated, out of order, or not at all.  The layers above
+              IP are responsible for reliable delivery service when it
+              is required.  The IP protocol includes provision for
+              addressing, type-of-service specification, fragmentation
+              and reassembly, and security information.
+
+              The datagram or connectionless nature of the IP protocol
+              is a fundamental and characteristic feature of the
+              Internet architecture.  Internet IP was the model for the
+              OSI Connectionless Network Protocol [INTRO:12].
+
+              ICMP is a control protocol that is considered to be an
+              integral part of IP, although it is architecturally
+              layered upon IP, i.e., it uses IP to carry its data end-
+              to-end just as a transport protocol like TCP or UDP does.
+              ICMP provides error reporting, congestion reporting, and
+              first-hop gateway redirection.
+
+              IGMP is an Internet layer protocol used for establishing
+              dynamic host groups for IP multicasting.
+
+              The Internet layer protocols IP, ICMP, and IGMP are
+              discussed in Chapter 3.
+
+
+         o  Link Layer
+
+              To communicate on its directly-connected network, a host
+              must implement the communication protocol used to
+              interface to that network.  We call this a link layer or
+              media-access layer protocol.
+
+              There is a wide variety of link layer protocols,
+              corresponding to the many different types of networks.
+              See Chapter 2.
+
+
+      1.1.4  Embedded Gateway Code
+
+         Some Internet host software includes embedded gateway
+         functionality, so that these hosts can forward packets as a
+
+
+
+Internet Engineering Task Force                                [Page 10]
+
+
+
+
+RFC1122                       INTRODUCTION                  October 1989
+
+
+         gateway would, while still performing the application layer
+         functions of a host.
+
+         Such dual-purpose systems must follow the Gateway Requirements
+         RFC [INTRO:2]  with respect to their gateway functions, and
+         must follow the present document with respect to their host
+         functions.  In all overlapping cases, the two specifications
+         should be in agreement.
+
+         There are varying opinions in the Internet community about
+         embedded gateway functionality.  The main arguments are as
+         follows:
+
+         o    Pro: in a local network environment where networking is
+              informal, or in isolated internets, it may be convenient
+              and economical to use existing host systems as gateways.
+
+              There is also an architectural argument for embedded
+              gateway functionality: multihoming is much more common
+              than originally foreseen, and multihoming forces a host to
+              make routing decisions as if it were a gateway.  If the
+              multihomed  host contains an embedded gateway, it will
+              have full routing knowledge and as a result will be able
+              to make more optimal routing decisions.
+
+         o    Con: Gateway algorithms and protocols are still changing,
+              and they will continue to change as the Internet system
+              grows larger.  Attempting to include a general gateway
+              function within the host IP layer will force host system
+              maintainers to track these (more frequent) changes.  Also,
+              a larger pool of gateway implementations will make
+              coordinating the changes more difficult.  Finally, the
+              complexity of a gateway IP layer is somewhat greater than
+              that of a host, making the implementation and operation
+              tasks more complex.
+
+              In addition, the style of operation of some hosts is not
+              appropriate for providing stable and robust gateway
+              service.
+
+         There is considerable merit in both of these viewpoints.  One
+         conclusion can be drawn: an host administrator must have
+         conscious control over whether or not a given host acts as a
+         gateway.  See Section 3.1 for the detailed requirements.
+
+
+
+
+
+
+
+Internet Engineering Task Force                                [Page 11]
+
+
+
+
+RFC1122                       INTRODUCTION                  October 1989
+
+
+   1.2  General Considerations
+
+      There are two important lessons that vendors of Internet host
+      software have learned and which a new vendor should consider
+      seriously.
+
+      1.2.1  Continuing Internet Evolution
+
+         The enormous growth of the Internet has revealed problems of
+         management and scaling in a large datagram-based packet
+         communication system.  These problems are being addressed, and
+         as a result there will be continuing evolution of the
+         specifications described in this document.  These changes will
+         be carefully planned and controlled, since there is extensive
+         participation in this planning by the vendors and by the
+         organizations responsible for operations of the networks.
+
+         Development, evolution, and revision are characteristic of
+         computer network protocols today, and this situation will
+         persist for some years.  A vendor who develops computer
+         communication software for the Internet protocol suite (or any
+         other protocol suite!) and then fails to maintain and update
+         that software for changing specifications is going to leave a
+         trail of unhappy customers.  The Internet is a large
+         communication network, and the users are in constant contact
+         through it.  Experience has shown that knowledge of
+         deficiencies in vendor software propagates quickly through the
+         Internet technical community.
+
+      1.2.2  Robustness Principle
+
+         At every layer of the protocols, there is a general rule whose
+         application can lead to enormous benefits in robustness and
+         interoperability [IP:1]:
+
+                "Be liberal in what you accept, and
+                 conservative in what you send"
+
+         Software should be written to deal with every conceivable
+         error, no matter how unlikely; sooner or later a packet will
+         come in with that particular combination of errors and
+         attributes, and unless the software is prepared, chaos can
+         ensue.  In general, it is best to assume that the network is
+         filled with malevolent entities that will send in packets
+         designed to have the worst possible effect.  This assumption
+         will lead to suitable protective design, although the most
+         serious problems in the Internet have been caused by
+         unenvisaged mechanisms triggered by low-probability events;
+
+
+
+Internet Engineering Task Force                                [Page 12]
+
+
+
+
+RFC1122                       INTRODUCTION                  October 1989
+
+
+         mere human malice would never have taken so devious a course!
+
+         Adaptability to change must be designed into all levels of
+         Internet host software.  As a simple example, consider a
+         protocol specification that contains an enumeration of values
+         for a particular header field -- e.g., a type field, a port
+         number, or an error code; this enumeration must be assumed to
+         be incomplete.  Thus, if a protocol specification defines four
+         possible error codes, the software must not break when a fifth
+         code shows up.  An undefined code might be logged (see below),
+         but it must not cause a failure.
+
+         The second part of the principle is almost as important:
+         software on other hosts may contain deficiencies that make it
+         unwise to exploit legal but obscure protocol features.  It is
+         unwise to stray far from the obvious and simple, lest untoward
+         effects result elsewhere.  A corollary of this is "watch out
+         for misbehaving hosts"; host software should be prepared, not
+         just to survive other misbehaving hosts, but also to cooperate
+         to limit the amount of disruption such hosts can cause to the
+         shared communication facility.
+
+      1.2.3  Error Logging
+
+         The Internet includes a great variety of host and gateway
+         systems, each implementing many protocols and protocol layers,
+         and some of these contain bugs and mis-features in their
+         Internet protocol software.  As a result of complexity,
+         diversity, and distribution of function, the diagnosis of
+         Internet problems is often very difficult.
+
+         Problem diagnosis will be aided if host implementations include
+         a carefully designed facility for logging erroneous or
+         "strange" protocol events.  It is important to include as much
+         diagnostic information as possible when an error is logged.  In
+         particular, it is often useful to record the header(s) of a
+         packet that caused an error.  However, care must be taken to
+         ensure that error logging does not consume prohibitive amounts
+         of resources or otherwise interfere with the operation of the
+         host.
+
+         There is a tendency for abnormal but harmless protocol events
+         to overflow error logging files; this can be avoided by using a
+         "circular" log, or by enabling logging only while diagnosing a
+         known failure.  It may be useful to filter and count duplicate
+         successive messages.  One strategy that seems to work well is:
+         (1) always count abnormalities and make such counts accessible
+         through the management protocol (see [INTRO:1]); and (2) allow
+
+
+
+Internet Engineering Task Force                                [Page 13]
+
+
+
+
+RFC1122                       INTRODUCTION                  October 1989
+
+
+         the logging of a great variety of events to be selectively
+         enabled.  For example, it might useful to be able to "log
+         everything" or to "log everything for host X".
+
+         Note that different managements may have differing policies
+         about the amount of error logging that they want normally
+         enabled in a host.  Some will say, "if it doesn't hurt me, I
+         don't want to know about it", while others will want to take a
+         more watchful and aggressive attitude about detecting and
+         removing protocol abnormalities.
+
+      1.2.4  Configuration
+
+         It would be ideal if a host implementation of the Internet
+         protocol suite could be entirely self-configuring.  This would
+         allow the whole suite to be implemented in ROM or cast into
+         silicon, it would simplify diskless workstations, and it would
+         be an immense boon to harried LAN administrators as well as
+         system vendors.  We have not reached this ideal; in fact, we
+         are not even close.
+
+         At many points in this document, you will find a requirement
+         that a parameter be a configurable option.  There are several
+         different reasons behind such requirements.  In a few cases,
+         there is current uncertainty or disagreement about the best
+         value, and it may be necessary to update the recommended value
+         in the future.  In other cases, the value really depends on
+         external factors -- e.g., the size of the host and the
+         distribution of its communication load, or the speeds and
+         topology of nearby networks -- and self-tuning algorithms are
+         unavailable and may be insufficient.  In some cases,
+         configurability is needed because of administrative
+         requirements.
+
+         Finally, some configuration options are required to communicate
+         with obsolete or incorrect implementations of the protocols,
+         distributed without sources, that unfortunately persist in many
+         parts of the Internet.  To make correct systems coexist with
+         these faulty systems, administrators often have to "mis-
+         configure" the correct systems.  This problem will correct
+         itself gradually as the faulty systems are retired, but it
+         cannot be ignored by vendors.
+
+         When we say that a parameter must be configurable, we do not
+         intend to require that its value be explicitly read from a
+         configuration file at every boot time.  We recommend that
+         implementors set up a default for each parameter, so a
+         configuration file is only necessary to override those defaults
+
+
+
+Internet Engineering Task Force                                [Page 14]
+
+
+
+
+RFC1122                       INTRODUCTION                  October 1989
+
+
+         that are inappropriate in a particular installation.  Thus, the
+         configurability requirement is an assurance that it will be
+         POSSIBLE to override the default when necessary, even in a
+         binary-only or ROM-based product.
+
+         This document requires a particular value for such defaults in
+         some cases.  The choice of default is a sensitive issue when
+         the configuration item controls the accommodation to existing
+         faulty systems.  If the Internet is to converge successfully to
+         complete interoperability, the default values built into
+         implementations must implement the official protocol, not
+         "mis-configurations" to accommodate faulty implementations.
+         Although marketing considerations have led some vendors to
+         choose mis-configuration defaults, we urge vendors to choose
+         defaults that will conform to the standard.
+
+         Finally, we note that a vendor needs to provide adequate
+         documentation on all configuration parameters, their limits and
+         effects.
+
+
+   1.3  Reading this Document
+
+      1.3.1  Organization
+
+         Protocol layering, which is generally used as an organizing
+         principle in implementing network software, has also been used
+         to organize this document.  In describing the rules, we assume
+         that an implementation does strictly mirror the layering of the
+         protocols.  Thus, the following three major sections specify
+         the requirements for the link layer, the internet layer, and
+         the transport layer, respectively.  A companion RFC [INTRO:1]
+         covers application level software.  This layerist organization
+         was chosen for simplicity and clarity.
+
+         However, strict layering is an imperfect model, both for the
+         protocol suite and for recommended implementation approaches.
+         Protocols in different layers interact in complex and sometimes
+         subtle ways, and particular functions often involve multiple
+         layers.  There are many design choices in an implementation,
+         many of which involve creative "breaking" of strict layering.
+         Every implementor is urged to read references [INTRO:7] and
+         [INTRO:8].
+
+         This document describes the conceptual service interface
+         between layers using a functional ("procedure call") notation,
+         like that used in the TCP specification [TCP:1].  A host
+         implementation must support the logical information flow
+
+
+
+Internet Engineering Task Force                                [Page 15]
+
+
+
+
+RFC1122                       INTRODUCTION                  October 1989
+
+
+         implied by these calls, but need not literally implement the
+         calls themselves.  For example, many implementations reflect
+         the coupling between the transport layer and the IP layer by
+         giving them shared access to common data structures.  These
+         data structures, rather than explicit procedure calls, are then
+         the agency for passing much of the information that is
+         required.
+
+         In general, each major section of this document is organized
+         into the following subsections:
+
+         (1)  Introduction
+
+         (2)  Protocol Walk-Through -- considers the protocol
+              specification documents section-by-section, correcting
+              errors, stating requirements that may be ambiguous or
+              ill-defined, and providing further clarification or
+              explanation.
+
+         (3)  Specific Issues -- discusses protocol design and
+              implementation issues that were not included in the walk-
+              through.
+
+         (4)  Interfaces -- discusses the service interface to the next
+              higher layer.
+
+         (5)  Summary -- contains a summary of the requirements of the
+              section.
+
+
+         Under many of the individual topics in this document, there is
+         parenthetical material labeled "DISCUSSION" or
+         "IMPLEMENTATION". This material is intended to give
+         clarification and explanation of the preceding requirements
+         text.  It also includes some suggestions on possible future
+         directions or developments.  The implementation material
+         contains suggested approaches that an implementor may want to
+         consider.
+
+         The summary sections are intended to be guides and indexes to
+         the text, but are necessarily cryptic and incomplete.  The
+         summaries should never be used or referenced separately from
+         the complete RFC.
+
+      1.3.2  Requirements
+
+         In this document, the words that are used to define the
+         significance of each particular requirement are capitalized.
+
+
+
+Internet Engineering Task Force                                [Page 16]
+
+
+
+
+RFC1122                       INTRODUCTION                  October 1989
+
+
+         These words are:
+
+         *    "MUST"
+
+              This word or the adjective "REQUIRED" means that the item
+              is an absolute requirement of the specification.
+
+         *    "SHOULD"
+
+              This word or the adjective "RECOMMENDED" means that there
+              may exist valid reasons in particular circumstances to
+              ignore this item, but the full implications should be
+              understood and the case carefully weighed before choosing
+              a different course.
+
+         *    "MAY"
+
+              This word or the adjective "OPTIONAL" means that this item
+              is truly optional.  One vendor may choose to include the
+              item because a particular marketplace requires it or
+              because it enhances the product, for example; another
+              vendor may omit the same item.
+
+
+         An implementation is not compliant if it fails to satisfy one
+         or more of the MUST requirements for the protocols it
+         implements.  An implementation that satisfies all the MUST and
+         all the SHOULD requirements for its protocols is said to be
+         "unconditionally compliant"; one that satisfies all the MUST
+         requirements but not all the SHOULD requirements for its
+         protocols is said to be "conditionally compliant".
+
+      1.3.3  Terminology
+
+         This document uses the following technical terms:
+
+         Segment
+              A segment is the unit of end-to-end transmission in the
+              TCP protocol.  A segment consists of a TCP header followed
+              by application data.  A segment is transmitted by
+              encapsulation inside an IP datagram.
+
+         Message
+              In this description of the lower-layer protocols, a
+              message is the unit of transmission in a transport layer
+              protocol.  In particular, a TCP segment is a message.  A
+              message consists of a transport protocol header followed
+              by application protocol data.  To be transmitted end-to-
+
+
+
+Internet Engineering Task Force                                [Page 17]
+
+
+
+
+RFC1122                       INTRODUCTION                  October 1989
+
+
+              end through the Internet, a message must be encapsulated
+              inside a datagram.
+
+         IP Datagram
+              An IP datagram is the unit of end-to-end transmission in
+              the IP protocol.  An IP datagram consists of an IP header
+              followed by transport layer data, i.e., of an IP header
+              followed by a message.
+
+              In the description of the internet layer (Section 3), the
+              unqualified term "datagram" should be understood to refer
+              to an IP datagram.
+
+         Packet
+              A packet is the unit of data passed across the interface
+              between the internet layer and the link layer.  It
+              includes an IP header and data.  A packet may be a
+              complete IP datagram or a fragment of an IP datagram.
+
+         Frame
+              A frame is the unit of transmission in a link layer
+              protocol, and consists of a link-layer header followed by
+              a packet.
+
+         Connected Network
+              A network to which a host is interfaced is often known as
+              the "local network" or the "subnetwork" relative to that
+              host.  However, these terms can cause confusion, and
+              therefore we use the term "connected network" in this
+              document.
+
+         Multihomed
+              A host is said to be multihomed if it has multiple IP
+              addresses.  For a discussion of multihoming, see Section
+              3.3.4 below.
+
+         Physical network interface
+              This is a physical interface to a connected network and
+              has a (possibly unique) link-layer address.  Multiple
+              physical network interfaces on a single host may share the
+              same link-layer address, but the address must be unique
+              for different hosts on the same physical network.
+
+         Logical [network] interface
+              We define a logical [network] interface to be a logical
+              path, distinguished by a unique IP address, to a connected
+              network.  See Section 3.3.4.
+
+
+
+
+Internet Engineering Task Force                                [Page 18]
+
+
+
+
+RFC1122                       INTRODUCTION                  October 1989
+
+
+         Specific-destination address
+              This is the effective destination address of a datagram,
+              even if it is broadcast or multicast; see Section 3.2.1.3.
+
+         Path
+              At a given moment, all the IP datagrams from a particular
+              source host to a particular destination host will
+              typically traverse the same sequence of gateways.  We use
+              the term "path" for this sequence.  Note that a path is
+              uni-directional; it is not unusual to have different paths
+              in the two directions between a given host pair.
+
+         MTU
+              The maximum transmission unit, i.e., the size of the
+              largest packet that can be transmitted.
+
+
+         The terms frame, packet, datagram, message, and segment are
+         illustrated by the following schematic diagrams:
+
+         A. Transmission on connected network:
+           _______________________________________________
+          | LL hdr | IP hdr |         (data)              |
+          |________|________|_____________________________|
+
+           <---------- Frame ----------------------------->
+                    <----------Packet -------------------->
+
+
+         B. Before IP fragmentation or after IP reassembly:
+                    ______________________________________
+                   | IP hdr | transport| Application Data |
+                   |________|____hdr___|__________________|
+
+                    <--------  Datagram ------------------>
+                             <-------- Message ----------->
+           or, for TCP:
+                    ______________________________________
+                   | IP hdr |  TCP hdr | Application Data |
+                   |________|__________|__________________|
+
+                    <--------  Datagram ------------------>
+                             <-------- Segment ----------->
+
+
+
+
+
+
+
+
+Internet Engineering Task Force                                [Page 19]
+
+
+
+
+RFC1122                       INTRODUCTION                  October 1989
+
+
+   1.4  Acknowledgments
+
+      This document incorporates contributions and comments from a large
+      group of Internet protocol experts, including representatives of
+      university and research labs, vendors, and government agencies.
+      It was assembled primarily by the Host Requirements Working Group
+      of the Internet Engineering Task Force (IETF).
+
+      The Editor would especially like to acknowledge the tireless
+      dedication of the following people, who attended many long
+      meetings and generated 3 million bytes of electronic mail over the
+      past 18 months in pursuit of this document: Philip Almquist, Dave
+      Borman (Cray Research), Noel Chiappa, Dave Crocker (DEC), Steve
+      Deering (Stanford), Mike Karels (Berkeley), Phil Karn (Bellcore),
+      John Lekashman (NASA), Charles Lynn (BBN), Keith McCloghrie (TWG),
+      Paul Mockapetris (ISI), Thomas Narten (Purdue), Craig Partridge
+      (BBN), Drew Perkins (CMU), and James Van Bokkelen (FTP Software).
+
+      In addition, the following people made major contributions to the
+      effort: Bill Barns (Mitre), Steve Bellovin (AT&T), Mike Brescia
+      (BBN), Ed Cain (DCA), Annette DeSchon (ISI), Martin Gross (DCA),
+      Phill Gross (NRI), Charles Hedrick (Rutgers), Van Jacobson (LBL),
+      John Klensin (MIT), Mark Lottor (SRI), Milo Medin (NASA), Bill
+      Melohn (Sun Microsystems), Greg Minshall (Kinetics), Jeff Mogul
+      (DEC), John Mullen (CMC), Jon Postel (ISI), John Romkey (Epilogue
+      Technology), and Mike StJohns (DCA).  The following also made
+      significant contributions to particular areas: Eric Allman
+      (Berkeley), Rob Austein (MIT), Art Berggreen (ACC), Keith Bostic
+      (Berkeley), Vint Cerf (NRI), Wayne Hathaway (NASA), Matt Korn
+      (IBM), Erik Naggum (Naggum Software, Norway), Robert Ullmann
+      (Prime Computer), David Waitzman (BBN), Frank Wancho (USA), Arun
+      Welch (Ohio State), Bill Westfield (Cisco), and Rayan Zachariassen
+      (Toronto).
+
+      We are grateful to all, including any contributors who may have
+      been inadvertently omitted from this list.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Internet Engineering Task Force                                [Page 20]
+
+
+
+
+RFC1122                        LINK LAYER                   October 1989
+
+
+2. LINK LAYER
+
+   2.1  INTRODUCTION
+
+      All Internet systems, both hosts and gateways, have the same
+      requirements for link layer protocols.  These requirements are
+      given in Chapter 3 of "Requirements for Internet Gateways"
+      [INTRO:2], augmented with the material in this section.
+
+   2.2  PROTOCOL WALK-THROUGH
+
+      None.
+
+   2.3  SPECIFIC ISSUES
+
+      2.3.1  Trailer Protocol Negotiation
+
+         The trailer protocol [LINK:1] for link-layer encapsulation MAY
+         be used, but only when it has been verified that both systems
+         (host or gateway) involved in the link-layer communication
+         implement trailers.  If the system does not dynamically
+         negotiate use of the trailer protocol on a per-destination
+         basis, the default configuration MUST disable the protocol.
+
+         DISCUSSION:
+              The trailer protocol is a link-layer encapsulation
+              technique that rearranges the data contents of packets
+              sent on the physical network.  In some cases, trailers
+              improve the throughput of higher layer protocols by
+              reducing the amount of data copying within the operating
+              system.  Higher layer protocols are unaware of trailer
+              use, but both the sending and receiving host MUST
+              understand the protocol if it is used.
+
+              Improper use of trailers can result in very confusing
+              symptoms.  Only packets with specific size attributes are
+              encapsulated using trailers, and typically only a small
+              fraction of the packets being exchanged have these
+              attributes.  Thus, if a system using trailers exchanges
+              packets with a system that does not, some packets
+              disappear into a black hole while others are delivered
+              successfully.
+
+         IMPLEMENTATION:
+              On an Ethernet, packets encapsulated with trailers use a
+              distinct Ethernet type [LINK:1], and trailer negotiation
+              is performed at the time that ARP is used to discover the
+              link-layer address of a destination system.
+
+
+
+Internet Engineering Task Force                                [Page 21]
+
+
+
+
+RFC1122                        LINK LAYER                   October 1989
+
+
+              Specifically, the ARP exchange is completed in the usual
+              manner using the normal IP protocol type, but a host that
+              wants to speak trailers will send an additional "trailer
+              ARP reply" packet, i.e., an ARP reply that specifies the
+              trailer encapsulation protocol type but otherwise has the
+              format of a normal ARP reply.  If a host configured to use
+              trailers receives a trailer ARP reply message from a
+              remote machine, it can add that machine to the list of
+              machines that understand trailers, e.g., by marking the
+              corresponding entry in the ARP cache.
+
+              Hosts wishing to receive trailer encapsulations send
+              trailer ARP replies whenever they complete exchanges of
+              normal ARP messages for IP.  Thus, a host that received an
+              ARP request for its IP protocol address would send a
+              trailer ARP reply in addition to the normal IP ARP reply;
+              a host that sent the IP ARP request would send a trailer
+              ARP reply when it received the corresponding IP ARP reply.
+              In this way, either the requesting or responding host in
+              an IP ARP exchange may request that it receive trailer
+              encapsulations.
+
+              This scheme, using extra trailer ARP reply packets rather
+              than sending an ARP request for the trailer protocol type,
+              was designed to avoid a continuous exchange of ARP packets
+              with a misbehaving host that, contrary to any
+              specification or common sense, responded to an ARP reply
+              for trailers with another ARP reply for IP.  This problem
+              is avoided by sending a trailer ARP reply in response to
+              an IP ARP reply only when the IP ARP reply answers an
+              outstanding request; this is true when the hardware
+              address for the host is still unknown when the IP ARP
+              reply is received.  A trailer ARP reply may always be sent
+              along with an IP ARP reply responding to an IP ARP
+              request.
+
+      2.3.2  Address Resolution Protocol -- ARP
+
+         2.3.2.1  ARP Cache Validation
+
+            An implementation of the Address Resolution Protocol (ARP)
+            [LINK:2] MUST provide a mechanism to flush out-of-date cache
+            entries.  If this mechanism involves a timeout, it SHOULD be
+            possible to configure the timeout value.
+
+            A mechanism to prevent ARP flooding (repeatedly sending an
+            ARP Request for the same IP address, at a high rate) MUST be
+            included.  The recommended maximum rate is 1 per second per
+
+
+
+Internet Engineering Task Force                                [Page 22]
+
+
+
+
+RFC1122                        LINK LAYER                   October 1989
+
+
+            destination.
+
+            DISCUSSION:
+                 The ARP specification [LINK:2] suggests but does not
+                 require a timeout mechanism to invalidate cache entries
+                 when hosts change their Ethernet addresses.  The
+                 prevalence of proxy ARP (see Section 2.4 of [INTRO:2])
+                 has significantly increased the likelihood that cache
+                 entries in hosts will become invalid, and therefore
+                 some ARP-cache invalidation mechanism is now required
+                 for hosts.  Even in the absence of proxy ARP, a long-
+                 period cache timeout is useful in order to
+                 automatically correct any bad ARP data that might have
+                 been cached.
+
+            IMPLEMENTATION:
+                 Four mechanisms have been used, sometimes in
+                 combination, to flush out-of-date cache entries.
+
+                 (1)  Timeout -- Periodically time out cache entries,
+                      even if they are in use.  Note that this timeout
+                      should be restarted when the cache entry is
+                      "refreshed" (by observing the source fields,
+                      regardless of target address, of an ARP broadcast
+                      from the system in question).  For proxy ARP
+                      situations, the timeout needs to be on the order
+                      of a minute.
+
+                 (2)  Unicast Poll -- Actively poll the remote host by
+                      periodically sending a point-to-point ARP Request
+                      to it, and delete the entry if no ARP Reply is
+                      received from N successive polls.  Again, the
+                      timeout should be on the order of a minute, and
+                      typically N is 2.
+
+                 (3)  Link-Layer Advice -- If the link-layer driver
+                      detects a delivery problem, flush the
+                      corresponding ARP cache entry.
+
+                 (4)  Higher-layer Advice -- Provide a call from the
+                      Internet layer to the link layer to indicate a
+                      delivery problem.  The effect of this call would
+                      be to invalidate the corresponding cache entry.
+                      This call would be analogous to the
+                      "ADVISE_DELIVPROB()" call from the transport layer
+                      to the Internet layer (see Section 3.4), and in
+                      fact the ADVISE_DELIVPROB routine might in turn
+                      call the link-layer advice routine to invalidate
+
+
+
+Internet Engineering Task Force                                [Page 23]
+
+
+
+
+RFC1122                        LINK LAYER                   October 1989
+
+
+                      the ARP cache entry.
+
+                 Approaches (1) and (2) involve ARP cache timeouts on
+                 the order of a minute or less.  In the absence of proxy
+                 ARP, a timeout this short could create noticeable
+                 overhead traffic on a very large Ethernet.  Therefore,
+                 it may be necessary to configure a host to lengthen the
+                 ARP cache timeout.
+
+         2.3.2.2  ARP Packet Queue
+
+            The link layer SHOULD save (rather than discard) at least
+            one (the latest) packet of each set of packets destined to
+            the same unresolved IP address, and transmit the saved
+            packet when the address has been resolved.
+
+            DISCUSSION:
+                 Failure to follow this recommendation causes the first
+                 packet of every exchange to be lost.  Although higher-
+                 layer protocols can generally cope with packet loss by
+                 retransmission, packet loss does impact performance.
+                 For example, loss of a TCP open request causes the
+                 initial round-trip time estimate to be inflated.  UDP-
+                 based applications such as the Domain Name System are
+                 more seriously affected.
+
+      2.3.3  Ethernet and IEEE 802 Encapsulation
+
+         The IP encapsulation for Ethernets is described in RFC-894
+         [LINK:3], while RFC-1042 [LINK:4] describes the IP
+         encapsulation for IEEE 802 networks.  RFC-1042 elaborates and
+         replaces the discussion in Section 3.4 of [INTRO:2].
+
+         Every Internet host connected to a 10Mbps Ethernet cable:
+
+         o    MUST be able to send and receive packets using RFC-894
+              encapsulation;
+
+         o    SHOULD be able to receive RFC-1042 packets, intermixed
+              with RFC-894 packets; and
+
+         o    MAY be able to send packets using RFC-1042 encapsulation.
+
+
+         An Internet host that implements sending both the RFC-894 and
+         the RFC-1042 encapsulations MUST provide a configuration switch
+         to select which is sent, and this switch MUST default to RFC-
+         894.
+
+
+
+Internet Engineering Task Force                                [Page 24]
+
+
+
+
+RFC1122                        LINK LAYER                   October 1989
+
+
+         Note that the standard IP encapsulation in RFC-1042 does not
+         use the protocol id value (K1=6) that IEEE reserved for IP;
+         instead, it uses a value (K1=170) that implies an extension
+         (the "SNAP") which can be used to hold the Ether-Type field.
+         An Internet system MUST NOT send 802 packets using K1=6.
+
+         Address translation from Internet addresses to link-layer
+         addresses on Ethernet and IEEE 802 networks MUST be managed by
+         the Address Resolution Protocol (ARP).
+
+         The MTU for an Ethernet is 1500 and for 802.3 is 1492.
+
+         DISCUSSION:
+              The IEEE 802.3 specification provides for operation over a
+              10Mbps Ethernet cable, in which case Ethernet and IEEE
+              802.3 frames can be physically intermixed.  A receiver can
+              distinguish Ethernet and 802.3 frames by the value of the
+              802.3 Length field; this two-octet field coincides in the
+              header with the Ether-Type field of an Ethernet frame.  In
+              particular, the 802.3 Length field must be less than or
+              equal to 1500, while all valid Ether-Type values are
+              greater than 1500.
+
+              Another compatibility problem arises with link-layer
+              broadcasts.  A broadcast sent with one framing will not be
+              seen by hosts that can receive only the other framing.
+
+              The provisions of this section were designed to provide
+              direct interoperation between 894-capable and 1042-capable
+              systems on the same cable, to the maximum extent possible.
+              It is intended to support the present situation where
+              894-only systems predominate, while providing an easy
+              transition to a possible future in which 1042-capable
+              systems become common.
+
+              Note that 894-only systems cannot interoperate directly
+              with 1042-only systems.  If the two system types are set
+              up as two different logical networks on the same cable,
+              they can communicate only through an IP gateway.
+              Furthermore, it is not useful or even possible for a
+              dual-format host to discover automatically which format to
+              send, because of the problem of link-layer broadcasts.
+
+   2.4  LINK/INTERNET LAYER INTERFACE
+
+      The packet receive interface between the IP layer and the link
+      layer MUST include a flag to indicate whether the incoming packet
+      was addressed to a link-layer broadcast address.
+
+
+
+Internet Engineering Task Force                                [Page 25]
+
+
+
+
+RFC1122                        LINK LAYER                   October 1989
+
+
+      DISCUSSION
+           Although the IP layer does not generally know link layer
+           addresses (since every different network medium typically has
+           a different address format), the broadcast address on a
+           broadcast-capable medium is an important special case.  See
+           Section 3.2.2, especially the DISCUSSION concerning broadcast
+           storms.
+
+      The packet send interface between the IP and link layers MUST
+      include the 5-bit TOS field (see Section 3.2.1.6).
+
+      The link layer MUST NOT report a Destination Unreachable error to
+      IP solely because there is no ARP cache entry for a destination.
+
+   2.5  LINK LAYER REQUIREMENTS SUMMARY
+
+                                                  |       | | | |S| |
+                                                  |       | | | |H| |F
+                                                  |       | | | |O|M|o
+                                                  |       | |S| |U|U|o
+                                                  |       | |H| |L|S|t
+                                                  |       |M|O| |D|T|n
+                                                  |       |U|U|M| | |o
+                                                  |       |S|L|A|N|N|t
+                                                  |       |T|D|Y|O|O|t
+FEATURE                                           |SECTION| | | |T|T|e
+--------------------------------------------------|-------|-|-|-|-|-|--
+                                                  |       | | | | | |
+Trailer encapsulation                             |2.3.1  | | |x| | |
+Send Trailers by default without negotiation      |2.3.1  | | | | |x|
+ARP                                               |2.3.2  | | | | | |
+  Flush out-of-date ARP cache entries             |2.3.2.1|x| | | | |
+  Prevent ARP floods                              |2.3.2.1|x| | | | |
+  Cache timeout configurable                      |2.3.2.1| |x| | | |
+  Save at least one (latest) unresolved pkt       |2.3.2.2| |x| | | |
+Ethernet and IEEE 802 Encapsulation               |2.3.3  | | | | | |
+  Host able to:                                   |2.3.3  | | | | | |
+    Send & receive RFC-894 encapsulation          |2.3.3  |x| | | | |
+    Receive RFC-1042 encapsulation                |2.3.3  | |x| | | |
+    Send RFC-1042 encapsulation                   |2.3.3  | | |x| | |
+      Then config. sw. to select, RFC-894 dflt    |2.3.3  |x| | | | |
+  Send K1=6 encapsulation                         |2.3.3  | | | | |x|
+  Use ARP on Ethernet and IEEE 802 nets           |2.3.3  |x| | | | |
+Link layer report b'casts to IP layer             |2.4    |x| | | | |
+IP layer pass TOS to link layer                   |2.4    |x| | | | |
+No ARP cache entry treated as Dest. Unreach.      |2.4    | | | | |x|
+
+
+
+
+
+Internet Engineering Task Force                                [Page 26]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+3. INTERNET LAYER PROTOCOLS
+
+   3.1 INTRODUCTION
+
+      The Robustness Principle: "Be liberal in what you accept, and
+      conservative in what you send" is particularly important in the
+      Internet layer, where one misbehaving host can deny Internet
+      service to many other hosts.
+
+      The protocol standards used in the Internet layer are:
+
+      o    RFC-791 [IP:1] defines the IP protocol and gives an
+           introduction to the architecture of the Internet.
+
+      o    RFC-792 [IP:2] defines ICMP, which provides routing,
+           diagnostic and error functionality for IP.  Although ICMP
+           messages are encapsulated within IP datagrams, ICMP
+           processing is considered to be (and is typically implemented
+           as) part of the IP layer.  See Section 3.2.2.
+
+      o    RFC-950 [IP:3] defines the mandatory subnet extension to the
+           addressing architecture.
+
+      o    RFC-1112 [IP:4] defines the Internet Group Management
+           Protocol IGMP, as part of a recommended extension to hosts
+           and to the host-gateway interface to support Internet-wide
+           multicasting at the IP level.  See Section 3.2.3.
+
+           The target of an IP multicast may be an arbitrary group of
+           Internet hosts.  IP multicasting is designed as a natural
+           extension of the link-layer multicasting facilities of some
+           networks, and it provides a standard means for local access
+           to such link-layer multicasting facilities.
+
+      Other important references are listed in Section 5 of this
+      document.
+
+      The Internet layer of host software MUST implement both IP and
+      ICMP.  See Section 3.3.7 for the requirements on support of IGMP.
+
+      The host IP layer has two basic functions:  (1) choose the "next
+      hop" gateway or host for outgoing IP datagrams and (2) reassemble
+      incoming IP datagrams.  The IP layer may also (3) implement
+      intentional fragmentation of outgoing datagrams.  Finally, the IP
+      layer must (4) provide diagnostic and error functionality.  We
+      expect that IP layer functions may increase somewhat in the
+      future, as further Internet control and management facilities are
+      developed.
+
+
+
+Internet Engineering Task Force                                [Page 27]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+      For normal datagrams, the processing is straightforward.  For
+      incoming datagrams, the IP layer:
+
+      (1)  verifies that the datagram is correctly formatted;
+
+      (2)  verifies that it is destined to the local host;
+
+      (3)  processes options;
+
+      (4)  reassembles the datagram if necessary; and
+
+      (5)  passes the encapsulated message to the appropriate
+           transport-layer protocol module.
+
+      For outgoing datagrams, the IP layer:
+
+      (1)  sets any fields not set by the transport layer;
+
+      (2)  selects the correct first hop on the connected network (a
+           process called "routing");
+
+      (3)  fragments the datagram if necessary and if intentional
+           fragmentation is implemented (see Section 3.3.3); and
+
+      (4)  passes the packet(s) to the appropriate link-layer driver.
+
+
+      A host is said to be multihomed if it has multiple IP addresses.
+      Multihoming introduces considerable confusion and complexity into
+      the protocol suite, and it is an area in which the Internet
+      architecture falls seriously short of solving all problems.  There
+      are two distinct problem areas in multihoming:
+
+      (1)  Local multihoming --  the host itself is multihomed; or
+
+      (2)  Remote multihoming -- the local host needs to communicate
+           with a remote multihomed host.
+
+      At present, remote multihoming MUST be handled at the application
+      layer, as discussed in the companion RFC [INTRO:1].  A host MAY
+      support local multihoming, which is discussed in this document,
+      and in particular in Section 3.3.4.
+
+      Any host that forwards datagrams generated by another host is
+      acting as a gateway and MUST also meet the specifications laid out
+      in the gateway requirements RFC [INTRO:2].  An Internet host that
+      includes embedded gateway code MUST have a configuration switch to
+      disable the gateway function, and this switch MUST default to the
+
+
+
+Internet Engineering Task Force                                [Page 28]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+      non-gateway mode.  In this mode, a datagram arriving through one
+      interface will not be forwarded to another host or gateway (unless
+      it is source-routed), regardless of whether the host is single-
+      homed or multihomed.  The host software MUST NOT automatically
+      move into gateway mode if the host has more than one interface, as
+      the operator of the machine may neither want to provide that
+      service nor be competent to do so.
+
+      In the following, the action specified in certain cases is to
+      "silently discard" a received datagram.  This means that the
+      datagram will be discarded without further processing and that the
+      host will not send any ICMP error message (see Section 3.2.2) as a
+      result.  However, for diagnosis of problems a host SHOULD provide
+      the capability of logging the error (see Section 1.2.3), including
+      the contents of the silently-discarded datagram, and SHOULD record
+      the event in a statistics counter.
+
+      DISCUSSION:
+           Silent discard of erroneous datagrams is generally intended
+           to prevent "broadcast storms".
+
+   3.2  PROTOCOL WALK-THROUGH
+
+      3.2.1 Internet Protocol -- IP
+
+         3.2.1.1  Version Number: RFC-791 Section 3.1
+
+            A datagram whose version number is not 4 MUST be silently
+            discarded.
+
+         3.2.1.2  Checksum: RFC-791 Section 3.1
+
+            A host MUST verify the IP header checksum on every received
+            datagram and silently discard every datagram that has a bad
+            checksum.
+
+         3.2.1.3  Addressing: RFC-791 Section 3.2
+
+            There are now five classes of IP addresses: Class A through
+            Class E.  Class D addresses are used for IP multicasting
+            [IP:4], while Class E addresses are reserved for
+            experimental use.
+
+            A multicast (Class D) address is a 28-bit logical address
+            that stands for a group of hosts, and may be either
+            permanent or transient.  Permanent multicast addresses are
+            allocated by the Internet Assigned Number Authority
+            [INTRO:6], while transient addresses may be allocated
+
+
+
+Internet Engineering Task Force                                [Page 29]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+            dynamically to transient groups.  Group membership is
+            determined dynamically using IGMP [IP:4].
+
+            We now summarize the important special cases for Class A, B,
+            and C IP addresses, using the following notation for an IP
+            address:
+
+                { <Network-number>, <Host-number> }
+
+            or
+                { <Network-number>, <Subnet-number>, <Host-number> }
+
+            and the notation "-1" for a field that contains all 1 bits.
+            This notation is not intended to imply that the 1-bits in an
+            address mask need be contiguous.
+
+            (a)  { 0, 0 }
+
+                 This host on this network.  MUST NOT be sent, except as
+                 a source address as part of an initialization procedure
+                 by which the host learns its own IP address.
+
+                 See also Section 3.3.6 for a non-standard use of {0,0}.
+
+            (b)  { 0, <Host-number> }
+
+                 Specified host on this network.  It MUST NOT be sent,
+                 except as a source address as part of an initialization
+                 procedure by which the host learns its full IP address.
+
+            (c)  { -1, -1 }
+
+                 Limited broadcast.  It MUST NOT be used as a source
+                 address.
+
+                 A datagram with this destination address will be
+                 received by every host on the connected physical
+                 network but will not be forwarded outside that network.
+
+            (d)  { <Network-number>, -1 }
+
+                 Directed broadcast to the specified network.  It MUST
+                 NOT be used as a source address.
+
+            (e)  { <Network-number>, <Subnet-number>, -1 }
+
+                 Directed broadcast to the specified subnet.  It MUST
+                 NOT be used as a source address.
+
+
+
+Internet Engineering Task Force                                [Page 30]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+            (f)  { <Network-number>, -1, -1 }
+
+                 Directed broadcast to all subnets of the specified
+                 subnetted network.  It MUST NOT be used as a source
+                 address.
+
+            (g)  { 127, <any> }
+
+                 Internal host loopback address.  Addresses of this form
+                 MUST NOT appear outside a host.
+
+            The <Network-number> is administratively assigned so that
+            its value will be unique in the entire world.
+
+            IP addresses are not permitted to have the value 0 or -1 for
+            any of the <Host-number>, <Network-number>, or <Subnet-
+            number> fields (except in the special cases listed above).
+            This implies that each of these fields will be at least two
+            bits long.
+
+            For further discussion of broadcast addresses, see Section
+            3.3.6.
+
+            A host MUST support the subnet extensions to IP [IP:3].  As
+            a result, there will be an address mask of the form:
+            {-1, -1, 0} associated with each of the host's local IP
+            addresses; see Sections 3.2.2.9 and 3.3.1.1.
+
+            When a host sends any datagram, the IP source address MUST
+            be one of its own IP addresses (but not a broadcast or
+            multicast address).
+
+            A host MUST silently discard an incoming datagram that is
+            not destined for the host.  An incoming datagram is destined
+            for the host if the datagram's destination address field is:
+
+            (1)  (one of) the host's IP address(es); or
+
+            (2)  an IP broadcast address valid for the connected
+                 network; or
+
+            (3)  the address for a multicast group of which the host is
+                 a member on the incoming physical interface.
+
+            For most purposes, a datagram addressed to a broadcast or
+            multicast destination is processed as if it had been
+            addressed to one of the host's IP addresses; we use the term
+            "specific-destination address" for the equivalent local IP
+
+
+
+Internet Engineering Task Force                                [Page 31]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+            address of the host.  The specific-destination address is
+            defined to be the destination address in the IP header
+            unless the header contains a broadcast or multicast address,
+            in which case the specific-destination is an IP address
+            assigned to the physical interface on which the datagram
+            arrived.
+
+            A host MUST silently discard an incoming datagram containing
+            an IP source address that is invalid by the rules of this
+            section.  This validation could be done in either the IP
+            layer or by each protocol in the transport layer.
+
+            DISCUSSION:
+                 A mis-addressed datagram might be caused by a link-
+                 layer broadcast of a unicast datagram or by a gateway
+                 or host that is confused or mis-configured.
+
+                 An architectural goal for Internet hosts was to allow
+                 IP addresses to be featureless 32-bit numbers, avoiding
+                 algorithms that required a knowledge of the IP address
+                 format.  Otherwise, any future change in the format or
+                 interpretation of IP addresses will require host
+                 software changes.  However, validation of broadcast and
+                 multicast addresses violates this goal; a few other
+                 violations are described elsewhere in this document.
+
+                 Implementers should be aware that applications
+                 depending upon the all-subnets directed broadcast
+                 address (f) may be unusable on some networks.  All-
+                 subnets broadcast is not widely implemented in vendor
+                 gateways at present, and even when it is implemented, a
+                 particular network administration may disable it in the
+                 gateway configuration.
+
+         3.2.1.4  Fragmentation and Reassembly: RFC-791 Section 3.2
+
+            The Internet model requires that every host support
+            reassembly.  See Sections 3.3.2 and 3.3.3 for the
+            requirements on fragmentation and reassembly.
+
+         3.2.1.5  Identification: RFC-791 Section 3.2
+
+            When sending an identical copy of an earlier datagram, a
+            host MAY optionally retain the same Identification field in
+            the copy.
+
+
+
+
+
+
+Internet Engineering Task Force                                [Page 32]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+            DISCUSSION:
+                 Some Internet protocol experts have maintained that
+                 when a host sends an identical copy of an earlier
+                 datagram, the new copy should contain the same
+                 Identification value as the original.  There are two
+                 suggested advantages:  (1) if the datagrams are
+                 fragmented and some of the fragments are lost, the
+                 receiver may be able to reconstruct a complete datagram
+                 from fragments of the original and the copies; (2) a
+                 congested gateway might use the IP Identification field
+                 (and Fragment Offset) to discard duplicate datagrams
+                 from the queue.
+
+                 However, the observed patterns of datagram loss in the
+                 Internet do not favor the probability of retransmitted
+                 fragments filling reassembly gaps, while other
+                 mechanisms (e.g., TCP repacketizing upon
+                 retransmission) tend to prevent retransmission of an
+                 identical datagram [IP:9].  Therefore, we believe that
+                 retransmitting the same Identification field is not
+                 useful.  Also, a connectionless transport protocol like
+                 UDP would require the cooperation of the application
+                 programs to retain the same Identification value in
+                 identical datagrams.
+
+         3.2.1.6  Type-of-Service: RFC-791 Section 3.2
+
+            The "Type-of-Service" byte in the IP header is divided into
+            two sections:  the Precedence field (high-order 3 bits), and
+            a field that is customarily called "Type-of-Service" or
+            "TOS" (low-order 5 bits).  In this document, all references
+            to "TOS" or the "TOS field" refer to the low-order 5 bits
+            only.
+
+            The Precedence field is intended for Department of Defense
+            applications of the Internet protocols.  The use of non-zero
+            values in this field is outside the scope of this document
+            and the IP standard specification.  Vendors should consult
+            the Defense Communication Agency (DCA) for guidance on the
+            IP Precedence field and its implications for other protocol
+            layers.  However, vendors should note that the use of
+            precedence will most likely require that its value be passed
+            between protocol layers in just the same way as the TOS
+            field is passed.
+
+            The IP layer MUST provide a means for the transport layer to
+            set the TOS field of every datagram that is sent; the
+            default is all zero bits.  The IP layer SHOULD pass received
+
+
+
+Internet Engineering Task Force                                [Page 33]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+            TOS values up to the transport layer.
+
+            The particular link-layer mappings of TOS contained in RFC-
+            795 SHOULD NOT be implemented.
+
+            DISCUSSION:
+                 While the TOS field has been little used in the past,
+                 it is expected to play an increasing role in the near
+                 future.  The TOS field is expected to be used to
+                 control two aspects of gateway operations: routing and
+                 queueing algorithms.  See Section 2 of [INTRO:1] for
+                 the requirements on application programs to specify TOS
+                 values.
+
+                 The TOS field may also be mapped into link-layer
+                 service selectors.  This has been applied to provide
+                 effective sharing of serial lines by different classes
+                 of TCP traffic, for example.  However, the mappings
+                 suggested in RFC-795 for networks that were included in
+                 the Internet as of 1981 are now obsolete.
+
+         3.2.1.7  Time-to-Live: RFC-791 Section 3.2
+
+            A host MUST NOT send a datagram with a Time-to-Live (TTL)
+            value of zero.
+
+            A host MUST NOT discard a datagram just because it was
+            received with TTL less than 2.
+
+            The IP layer MUST provide a means for the transport layer to
+            set the TTL field of every datagram that is sent.  When a
+            fixed TTL value is used, it MUST be configurable.  The
+            current suggested value will be published in the "Assigned
+            Numbers" RFC.
+
+            DISCUSSION:
+                 The TTL field has two functions: limit the lifetime of
+                 TCP segments (see RFC-793 [TCP:1], p. 28), and
+                 terminate Internet routing loops.  Although TTL is a
+                 time in seconds, it also has some attributes of a hop-
+                 count, since each gateway is required to reduce the TTL
+                 field by at least one.
+
+                 The intent is that TTL expiration will cause a datagram
+                 to be discarded by a gateway but not by the destination
+                 host; however, hosts that act as gateways by forwarding
+                 datagrams must follow the gateway rules for TTL.
+
+
+
+
+Internet Engineering Task Force                                [Page 34]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+                 A higher-layer protocol may want to set the TTL in
+                 order to implement an "expanding scope" search for some
+                 Internet resource.  This is used by some diagnostic
+                 tools, and is expected to be useful for locating the
+                 "nearest" server of a given class using IP
+                 multicasting, for example.  A particular transport
+                 protocol may also want to specify its own TTL bound on
+                 maximum datagram lifetime.
+
+                 A fixed value must be at least big enough for the
+                 Internet "diameter," i.e., the longest possible path.
+                 A reasonable value is about twice the diameter, to
+                 allow for continued Internet growth.
+
+         3.2.1.8  Options: RFC-791 Section 3.2
+
+            There MUST be a means for the transport layer to specify IP
+            options to be included in transmitted IP datagrams (see
+            Section 3.4).
+
+            All IP options (except NOP or END-OF-LIST) received in
+            datagrams MUST be passed to the transport layer (or to ICMP
+            processing when the datagram is an ICMP message).  The IP
+            and transport layer MUST each interpret those IP options
+            that they understand and silently ignore the others.
+
+            Later sections of this document discuss specific IP option
+            support required by each of ICMP, TCP, and UDP.
+
+            DISCUSSION:
+                 Passing all received IP options to the transport layer
+                 is a deliberate "violation of strict layering" that is
+                 designed to ease the introduction of new transport-
+                 relevant IP options in the future.  Each layer must
+                 pick out any options that are relevant to its own
+                 processing and ignore the rest.  For this purpose,
+                 every IP option except NOP and END-OF-LIST will include
+                 a specification of its own length.
+
+                 This document does not define the order in which a
+                 receiver must process multiple options in the same IP
+                 header.  Hosts sending multiple options must be aware
+                 that this introduces an ambiguity in the meaning of
+                 certain options when combined with a source-route
+                 option.
+
+            IMPLEMENTATION:
+                 The IP layer must not crash as the result of an option
+
+
+
+Internet Engineering Task Force                                [Page 35]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+                 length that is outside the possible range.  For
+                 example, erroneous option lengths have been observed to
+                 put some IP implementations into infinite loops.
+
+            Here are the requirements for specific IP options:
+
+
+            (a)  Security Option
+
+                 Some environments require the Security option in every
+                 datagram; such a requirement is outside the scope of
+                 this document and the IP standard specification.  Note,
+                 however, that the security options described in RFC-791
+                 and RFC-1038 are obsolete.  For DoD applications,
+                 vendors should consult [IP:8] for guidance.
+
+
+            (b)  Stream Identifier Option
+
+                 This option is obsolete; it SHOULD NOT be sent, and it
+                 MUST be silently ignored if received.
+
+
+            (c)  Source Route Options
+
+                 A host MUST support originating a source route and MUST
+                 be able to act as the final destination of a source
+                 route.
+
+                 If host receives a datagram containing a completed
+                 source route (i.e., the pointer points beyond the last
+                 field), the datagram has reached its final destination;
+                 the option as received (the recorded route) MUST be
+                 passed up to the transport layer (or to ICMP message
+                 processing).  This recorded route will be reversed and
+                 used to form a return source route for reply datagrams
+                 (see discussion of IP Options in Section 4).  When a
+                 return source route is built, it MUST be correctly
+                 formed even if the recorded route included the source
+                 host (see case (B) in the discussion below).
+
+                 An IP header containing more than one Source Route
+                 option MUST NOT be sent; the effect on routing of
+                 multiple Source Route options is implementation-
+                 specific.
+
+                 Section 3.3.5 presents the rules for a host acting as
+                 an intermediate hop in a source route, i.e., forwarding
+
+
+
+Internet Engineering Task Force                                [Page 36]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+                 a source-routed datagram.
+
+                 DISCUSSION:
+                      If a source-routed datagram is fragmented, each
+                      fragment will contain a copy of the source route.
+                      Since the processing of IP options (including a
+                      source route) must precede reassembly, the
+                      original datagram will not be reassembled until
+                      the final destination is reached.
+
+                      Suppose a source routed datagram is to be routed
+                      from host S to host D via gateways G1, G2, ... Gn.
+                      There was an ambiguity in the specification over
+                      whether the source route option in a datagram sent
+                      out by S should be (A) or (B):
+
+                          (A):  {>>G2, G3, ... Gn, D}     <--- CORRECT
+
+                          (B):  {S, >>G2, G3, ... Gn, D}  <---- WRONG
+
+                      (where >> represents the pointer).  If (A) is
+                      sent, the datagram received at D will contain the
+                      option: {G1, G2, ... Gn >>}, with S and D as the
+                      IP source and destination addresses.  If (B) were
+                      sent, the datagram received at D would again
+                      contain S and D as the same IP source and
+                      destination addresses, but the option would be:
+                      {S, G1, ...Gn >>}; i.e., the originating host
+                      would be the first hop in the route.
+
+
+            (d)  Record Route Option
+
+                 Implementation of originating and processing the Record
+                 Route option is OPTIONAL.
+
+
+            (e)  Timestamp Option
+
+                 Implementation of originating and processing the
+                 Timestamp option is OPTIONAL.  If it is implemented,
+                 the following rules apply:
+
+                 o    The originating host MUST record a timestamp in a
+                      Timestamp option whose Internet address fields are
+                      not pre-specified or whose first pre-specified
+                      address is the host's interface address.
+
+
+
+
+Internet Engineering Task Force                                [Page 37]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+                 o    The destination host MUST (if possible) add the
+                      current timestamp to a Timestamp option before
+                      passing the option to the transport layer or to
+                      ICMP for processing.
+
+                 o    A timestamp value MUST follow the rules given in
+                      Section 3.2.2.8 for the ICMP Timestamp message.
+
+
+      3.2.2 Internet Control Message Protocol -- ICMP
+
+         ICMP messages are grouped into two classes.
+
+         *
+              ICMP error messages:
+
+               Destination Unreachable   (see Section 3.2.2.1)
+               Redirect                  (see Section 3.2.2.2)
+               Source Quench             (see Section 3.2.2.3)
+               Time Exceeded             (see Section 3.2.2.4)
+               Parameter Problem         (see Section 3.2.2.5)
+
+
+         *
+              ICMP query messages:
+
+                Echo                     (see Section 3.2.2.6)
+                Information              (see Section 3.2.2.7)
+                Timestamp                (see Section 3.2.2.8)
+                Address Mask             (see Section 3.2.2.9)
+
+
+         If an ICMP message of unknown type is received, it MUST be
+         silently discarded.
+
+         Every ICMP error message includes the Internet header and at
+         least the first 8 data octets of the datagram that triggered
+         the error; more than 8 octets MAY be sent; this header and data
+         MUST be unchanged from the received datagram.
+
+         In those cases where the Internet layer is required to pass an
+         ICMP error message to the transport layer, the IP protocol
+         number MUST be extracted from the original header and used to
+         select the appropriate transport protocol entity to handle the
+         error.
+
+         An ICMP error message SHOULD be sent with normal (i.e., zero)
+         TOS bits.
+
+
+
+Internet Engineering Task Force                                [Page 38]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+         An ICMP error message MUST NOT be sent as the result of
+         receiving:
+
+         *    an ICMP error message, or
+
+         *    a datagram destined to an IP broadcast or IP multicast
+              address, or
+
+         *    a datagram sent as a link-layer broadcast, or
+
+         *    a non-initial fragment, or
+
+         *    a datagram whose source address does not define a single
+              host -- e.g., a zero address, a loopback address, a
+              broadcast address, a multicast address, or a Class E
+              address.
+
+         NOTE: THESE RESTRICTIONS TAKE PRECEDENCE OVER ANY REQUIREMENT
+         ELSEWHERE IN THIS DOCUMENT FOR SENDING ICMP ERROR MESSAGES.
+
+         DISCUSSION:
+              These rules will prevent the "broadcast storms" that have
+              resulted from hosts returning ICMP error messages in
+              response to broadcast datagrams.  For example, a broadcast
+              UDP segment to a non-existent port could trigger a flood
+              of ICMP Destination Unreachable datagrams from all
+              machines that do not have a client for that destination
+              port.  On a large Ethernet, the resulting collisions can
+              render the network useless for a second or more.
+
+              Every datagram that is broadcast on the connected network
+              should have a valid IP broadcast address as its IP
+              destination (see Section 3.3.6).  However, some hosts
+              violate this rule.  To be certain to detect broadcast
+              datagrams, therefore, hosts are required to check for a
+              link-layer broadcast as well as an IP-layer broadcast
+              address.
+
+         IMPLEMENTATION:
+              This requires that the link layer inform the IP layer when
+              a link-layer broadcast datagram has been received; see
+              Section 2.4.
+
+         3.2.2.1  Destination Unreachable: RFC-792
+
+            The following additional codes are hereby defined:
+
+                    6 = destination network unknown
+
+
+
+Internet Engineering Task Force                                [Page 39]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+                    7 = destination host unknown
+
+                    8 = source host isolated
+
+                    9 = communication with destination network
+                            administratively prohibited
+
+                   10 = communication with destination host
+                            administratively prohibited
+
+                   11 = network unreachable for type of service
+
+                   12 = host unreachable for type of service
+
+            A host SHOULD generate Destination Unreachable messages with
+            code:
+
+            2    (Protocol Unreachable), when the designated transport
+                 protocol is not supported; or
+
+            3    (Port Unreachable), when the designated transport
+                 protocol (e.g., UDP) is unable to demultiplex the
+                 datagram but has no protocol mechanism to inform the
+                 sender.
+
+            A Destination Unreachable message that is received MUST be
+            reported to the transport layer.  The transport layer SHOULD
+            use the information appropriately; for example, see Sections
+            4.1.3.3, 4.2.3.9, and 4.2.4 below.  A transport protocol
+            that has its own mechanism for notifying the sender that a
+            port is unreachable (e.g., TCP, which sends RST segments)
+            MUST nevertheless accept an ICMP Port Unreachable for the
+            same purpose.
+
+            A Destination Unreachable message that is received with code
+            0 (Net), 1 (Host), or 5 (Bad Source Route) may result from a
+            routing transient and MUST therefore be interpreted as only
+            a hint, not proof, that the specified destination is
+            unreachable [IP:11].  For example, it MUST NOT be used as
+            proof of a dead gateway (see Section 3.3.1).
+
+         3.2.2.2  Redirect: RFC-792
+
+            A host SHOULD NOT send an ICMP Redirect message; Redirects
+            are to be sent only by gateways.
+
+            A host receiving a Redirect message MUST update its routing
+            information accordingly.  Every host MUST be prepared to
+
+
+
+Internet Engineering Task Force                                [Page 40]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+            accept both Host and Network Redirects and to process them
+            as described in Section 3.3.1.2 below.
+
+            A Redirect message SHOULD be silently discarded if the new
+            gateway address it specifies is not on the same connected
+            (sub-) net through which the Redirect arrived [INTRO:2,
+            Appendix A], or if the source of the Redirect is not the
+            current first-hop gateway for the specified destination (see
+            Section 3.3.1).
+
+         3.2.2.3  Source Quench: RFC-792
+
+            A host MAY send a Source Quench message if it is
+            approaching, or has reached, the point at which it is forced
+            to discard incoming datagrams due to a shortage of
+            reassembly buffers or other resources.  See Section 2.2.3 of
+            [INTRO:2] for suggestions on when to send Source Quench.
+
+            If a Source Quench message is received, the IP layer MUST
+            report it to the transport layer (or ICMP processing). In
+            general, the transport or application layer SHOULD implement
+            a mechanism to respond to Source Quench for any protocol
+            that can send a sequence of datagrams to the same
+            destination and which can reasonably be expected to maintain
+            enough state information to make this feasible.  See Section
+            4 for the handling of Source Quench by TCP and UDP.
+
+            DISCUSSION:
+                 A Source Quench may be generated by the target host or
+                 by some gateway in the path of a datagram.  The host
+                 receiving a Source Quench should throttle itself back
+                 for a period of time, then gradually increase the
+                 transmission rate again.  The mechanism to respond to
+                 Source Quench may be in the transport layer (for
+                 connection-oriented protocols like TCP) or in the
+                 application layer (for protocols that are built on top
+                 of UDP).
+
+                 A mechanism has been proposed [IP:14] to make the IP
+                 layer respond directly to Source Quench by controlling
+                 the rate at which datagrams are sent, however, this
+                 proposal is currently experimental and not currently
+                 recommended.
+
+         3.2.2.4  Time Exceeded: RFC-792
+
+            An incoming Time Exceeded message MUST be passed to the
+            transport layer.
+
+
+
+Internet Engineering Task Force                                [Page 41]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+            DISCUSSION:
+                 A gateway will send a Time Exceeded Code 0 (In Transit)
+                 message when it discards a datagram due to an expired
+                 TTL field.  This indicates either a gateway routing
+                 loop or too small an initial TTL value.
+
+                 A host may receive a Time Exceeded Code 1 (Reassembly
+                 Timeout) message from a destination host that has timed
+                 out and discarded an incomplete datagram; see Section
+                 3.3.2 below.  In the future, receipt of this message
+                 might be part of some "MTU discovery" procedure, to
+                 discover the maximum datagram size that can be sent on
+                 the path without fragmentation.
+
+         3.2.2.5  Parameter Problem: RFC-792
+
+            A host SHOULD generate Parameter Problem messages.  An
+            incoming Parameter Problem message MUST be passed to the
+            transport layer, and it MAY be reported to the user.
+
+            DISCUSSION:
+                 The ICMP Parameter Problem message is sent to the
+                 source host for any problem not specifically covered by
+                 another ICMP message.  Receipt of a Parameter Problem
+                 message generally indicates some local or remote
+                 implementation error.
+
+            A new variant on the Parameter Problem message is hereby
+            defined:
+              Code 1 = required option is missing.
+
+            DISCUSSION:
+                 This variant is currently in use in the military
+                 community for a missing security option.
+
+         3.2.2.6  Echo Request/Reply: RFC-792
+
+            Every host MUST implement an ICMP Echo server function that
+            receives Echo Requests and sends corresponding Echo Replies.
+            A host SHOULD also implement an application-layer interface
+            for sending an Echo Request and receiving an Echo Reply, for
+            diagnostic purposes.
+
+            An ICMP Echo Request destined to an IP broadcast or IP
+            multicast address MAY be silently discarded.
+
+
+
+
+
+
+Internet Engineering Task Force                                [Page 42]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+            DISCUSSION:
+                 This neutral provision results from a passionate debate
+                 between those who feel that ICMP Echo to a broadcast
+                 address provides a valuable diagnostic capability and
+                 those who feel that misuse of this feature can too
+                 easily create packet storms.
+
+            The IP source address in an ICMP Echo Reply MUST be the same
+            as the specific-destination address (defined in Section
+            3.2.1.3) of the corresponding ICMP Echo Request message.
+
+            Data received in an ICMP Echo Request MUST be entirely
+            included in the resulting Echo Reply.  However, if sending
+            the Echo Reply requires intentional fragmentation that is
+            not implemented, the datagram MUST be truncated to maximum
+            transmission size (see Section 3.3.3) and sent.
+
+            Echo Reply messages MUST be passed to the ICMP user
+            interface, unless the corresponding Echo Request originated
+            in the IP layer.
+
+            If a Record Route and/or Time Stamp option is received in an
+            ICMP Echo Request, this option (these options) SHOULD be
+            updated to include the current host and included in the IP
+            header of the Echo Reply message, without "truncation".
+            Thus, the recorded route will be for the entire round trip.
+
+            If a Source Route option is received in an ICMP Echo
+            Request, the return route MUST be reversed and used as a
+            Source Route option for the Echo Reply message.
+
+         3.2.2.7  Information Request/Reply: RFC-792
+
+            A host SHOULD NOT implement these messages.
+
+            DISCUSSION:
+                 The Information Request/Reply pair was intended to
+                 support self-configuring systems such as diskless
+                 workstations, to allow them to discover their IP
+                 network numbers at boot time.  However, the RARP and
+                 BOOTP protocols provide better mechanisms for a host to
+                 discover its own IP address.
+
+         3.2.2.8  Timestamp and Timestamp Reply: RFC-792
+
+            A host MAY implement Timestamp and Timestamp Reply.  If they
+            are implemented, the following rules MUST be followed.
+
+
+
+
+Internet Engineering Task Force                                [Page 43]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+            o    The ICMP Timestamp server function returns a Timestamp
+                 Reply to every Timestamp message that is received.  If
+                 this function is implemented, it SHOULD be designed for
+                 minimum variability in delay (e.g., implemented in the
+                 kernel to avoid delay in scheduling a user process).
+
+            The following cases for Timestamp are to be handled
+            according to the corresponding rules for ICMP Echo:
+
+            o    An ICMP Timestamp Request message to an IP broadcast or
+                 IP multicast address MAY be silently discarded.
+
+            o    The IP source address in an ICMP Timestamp Reply MUST
+                 be the same as the specific-destination address of the
+                 corresponding Timestamp Request message.
+
+            o    If a Source-route option is received in an ICMP Echo
+                 Request, the return route MUST be reversed and used as
+                 a Source Route option for the Timestamp Reply message.
+
+            o    If a Record Route and/or Timestamp option is received
+                 in a Timestamp Request, this (these) option(s) SHOULD
+                 be updated to include the current host and included in
+                 the IP header of the Timestamp Reply message.
+
+            o    Incoming Timestamp Reply messages MUST be passed up to
+                 the ICMP user interface.
+
+            The preferred form for a timestamp value (the "standard
+            value") is in units of milliseconds since midnight Universal
+            Time.  However, it may be difficult to provide this value
+            with millisecond resolution.  For example, many systems use
+            clocks that update only at line frequency, 50 or 60 times
+            per second.  Therefore, some latitude is allowed in a
+            "standard value":
+
+            (a)  A "standard value" MUST be updated at least 15 times
+                 per second (i.e., at most the six low-order bits of the
+                 value may be undefined).
+
+            (b)  The accuracy of a "standard value" MUST approximate
+                 that of operator-set CPU clocks, i.e., correct within a
+                 few minutes.
+
+
+
+
+
+
+
+
+Internet Engineering Task Force                                [Page 44]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+         3.2.2.9  Address Mask Request/Reply: RFC-950
+
+            A host MUST support the first, and MAY implement all three,
+            of the following methods for determining the address mask(s)
+            corresponding to its IP address(es):
+
+            (1)  static configuration information;
+
+            (2)  obtaining the address mask(s) dynamically as a side-
+                 effect of the system initialization process (see
+                 [INTRO:1]); and
+
+            (3)  sending ICMP Address Mask Request(s) and receiving ICMP
+                 Address Mask Reply(s).
+
+            The choice of method to be used in a particular host MUST be
+            configurable.
+
+            When method (3), the use of Address Mask messages, is
+            enabled, then:
+
+            (a)  When it initializes, the host MUST broadcast an Address
+                 Mask Request message on the connected network
+                 corresponding to the IP address.  It MUST retransmit
+                 this message a small number of times if it does not
+                 receive an immediate Address Mask Reply.
+
+            (b)  Until it has received an Address Mask Reply, the host
+                 SHOULD assume a mask appropriate for the address class
+                 of the IP address, i.e., assume that the connected
+                 network is not subnetted.
+
+            (c)  The first Address Mask Reply message received MUST be
+                 used to set the address mask corresponding to the
+                 particular local IP address.  This is true even if the
+                 first Address Mask Reply message is "unsolicited", in
+                 which case it will have been broadcast and may arrive
+                 after the host has ceased to retransmit Address Mask
+                 Requests.  Once the mask has been set by an Address
+                 Mask Reply, later Address Mask Reply messages MUST be
+                 (silently) ignored.
+
+            Conversely, if Address Mask messages are disabled, then no
+            ICMP Address Mask Requests will be sent, and any ICMP
+            Address Mask Replies received for that local IP address MUST
+            be (silently) ignored.
+
+            A host SHOULD make some reasonableness check on any address
+
+
+
+Internet Engineering Task Force                                [Page 45]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+            mask it installs; see IMPLEMENTATION section below.
+
+            A system MUST NOT send an Address Mask Reply unless it is an
+            authoritative agent for address masks.  An authoritative
+            agent may be a host or a gateway, but it MUST be explicitly
+            configured as a address mask agent.  Receiving an address
+            mask via an Address Mask Reply does not give the receiver
+            authority and MUST NOT be used as the basis for issuing
+            Address Mask Replies.
+
+            With a statically configured address mask, there SHOULD be
+            an additional configuration flag that determines whether the
+            host is to act as an authoritative agent for this mask,
+            i.e., whether it will answer Address Mask Request messages
+            using this mask.
+
+            If it is configured as an agent, the host MUST broadcast an
+            Address Mask Reply for the mask on the appropriate interface
+            when it initializes.
+
+            See "System Initialization" in [INTRO:1] for more
+            information about the use of Address Mask Request/Reply
+            messages.
+
+            DISCUSSION
+                 Hosts that casually send Address Mask Replies with
+                 invalid address masks have often been a serious
+                 nuisance.  To prevent this, Address Mask Replies ought
+                 to be sent only by authoritative agents that have been
+                 selected by explicit administrative action.
+
+                 When an authoritative agent receives an Address Mask
+                 Request message, it will send a unicast Address Mask
+                 Reply to the source IP address.  If the network part of
+                 this address is zero (see (a) and (b) in 3.2.1.3), the
+                 Reply will be broadcast.
+
+                 Getting no reply to its Address Mask Request messages,
+                 a host will assume there is no agent and use an
+                 unsubnetted mask, but the agent may be only temporarily
+                 unreachable.  An agent will broadcast an unsolicited
+                 Address Mask Reply whenever it initializes, in order to
+                 update the masks of all hosts that have initialized in
+                 the meantime.
+
+            IMPLEMENTATION:
+                 The following reasonableness check on an address mask
+                 is suggested: the mask is not all 1 bits, and it is
+
+
+
+Internet Engineering Task Force                                [Page 46]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+                 either zero or else the 8 highest-order bits are on.
+
+      3.2.3  Internet Group Management Protocol IGMP
+
+         IGMP [IP:4] is a protocol used between hosts and gateways on a
+         single network to establish hosts' membership in particular
+         multicast groups.  The gateways use this information, in
+         conjunction with a multicast routing protocol, to support IP
+         multicasting across the Internet.
+
+         At this time, implementation of IGMP is OPTIONAL; see Section
+         3.3.7 for more information.  Without IGMP, a host can still
+         participate in multicasting local to its connected networks.
+
+   3.3  SPECIFIC ISSUES
+
+      3.3.1  Routing Outbound Datagrams
+
+         The IP layer chooses the correct next hop for each datagram it
+         sends.  If the destination is on a connected network, the
+         datagram is sent directly to the destination host; otherwise,
+         it has to be routed to a gateway on a connected network.
+
+         3.3.1.1  Local/Remote Decision
+
+            To decide if the destination is on a connected network, the
+            following algorithm MUST be used [see IP:3]:
+
+            (a)  The address mask (particular to a local IP address for
+                 a multihomed host) is a 32-bit mask that selects the
+                 network number and subnet number fields of the
+                 corresponding IP address.
+
+            (b)  If the IP destination address bits extracted by the
+                 address mask match the IP source address bits extracted
+                 by the same mask, then the destination is on the
+                 corresponding connected network, and the datagram is to
+                 be transmitted directly to the destination host.
+
+            (c)  If not, then the destination is accessible only through
+                 a gateway.  Selection of a gateway is described below
+                 (3.3.1.2).
+
+            A special-case destination address is handled as follows:
+
+            *    For a limited broadcast or a multicast address, simply
+                 pass the datagram to the link layer for the appropriate
+                 interface.
+
+
+
+Internet Engineering Task Force                                [Page 47]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+            *    For a (network or subnet) directed broadcast, the
+                 datagram can use the standard routing algorithms.
+
+            The host IP layer MUST operate correctly in a minimal
+            network environment, and in particular, when there are no
+            gateways.  For example, if the IP layer of a host insists on
+            finding at least one gateway to initialize, the host will be
+            unable to operate on a single isolated broadcast net.
+
+         3.3.1.2  Gateway Selection
+
+            To efficiently route a series of datagrams to the same
+            destination, the source host MUST keep a "route cache" of
+            mappings to next-hop gateways.  A host uses the following
+            basic algorithm on this cache to route a datagram; this
+            algorithm is designed to put the primary routing burden on
+            the gateways [IP:11].
+
+            (a)  If the route cache contains no information for a
+                 particular destination, the host chooses a "default"
+                 gateway and sends the datagram to it.  It also builds a
+                 corresponding Route Cache entry.
+
+            (b)  If that gateway is not the best next hop to the
+                 destination, the gateway will forward the datagram to
+                 the best next-hop gateway and return an ICMP Redirect
+                 message to the source host.
+
+            (c)  When it receives a Redirect, the host updates the
+                 next-hop gateway in the appropriate route cache entry,
+                 so later datagrams to the same destination will go
+                 directly to the best gateway.
+
+            Since the subnet mask appropriate to the destination address
+            is generally not known, a Network Redirect message SHOULD be
+            treated identically to a Host Redirect message; i.e., the
+            cache entry for the destination host (only) would be updated
+            (or created, if an entry for that host did not exist) for
+            the new gateway.
+
+            DISCUSSION:
+                 This recommendation is to protect against gateways that
+                 erroneously send Network Redirects for a subnetted
+                 network, in violation of the gateway requirements
+                 [INTRO:2].
+
+            When there is no route cache entry for the destination host
+            address (and the destination is not on the connected
+
+
+
+Internet Engineering Task Force                                [Page 48]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+            network), the IP layer MUST pick a gateway from its list of
+            "default" gateways.  The IP layer MUST support multiple
+            default gateways.
+
+            As an extra feature, a host IP layer MAY implement a table
+            of "static routes".  Each such static route MAY include a
+            flag specifying whether it may be overridden by ICMP
+            Redirects.
+
+            DISCUSSION:
+                 A host generally needs to know at least one default
+                 gateway to get started.  This information can be
+                 obtained from a configuration file or else from the
+                 host startup sequence, e.g., the BOOTP protocol (see
+                 [INTRO:1]).
+
+                 It has been suggested that a host can augment its list
+                 of default gateways by recording any new gateways it
+                 learns about.  For example, it can record every gateway
+                 to which it is ever redirected.  Such a feature, while
+                 possibly useful in some circumstances, may cause
+                 problems in other cases (e.g., gateways are not all
+                 equal), and it is not recommended.
+
+                 A static route is typically a particular preset mapping
+                 from destination host or network into a particular
+                 next-hop gateway; it might also depend on the Type-of-
+                 Service (see next section).  Static routes would be set
+                 up by system administrators to override the normal
+                 automatic routing mechanism, to handle exceptional
+                 situations.  However, any static routing information is
+                 a potential source of failure as configurations change
+                 or equipment fails.
+
+         3.3.1.3  Route Cache
+
+            Each route cache entry needs to include the following
+            fields:
+
+            (1)  Local IP address (for a multihomed host)
+
+            (2)  Destination IP address
+
+            (3)  Type(s)-of-Service
+
+            (4)  Next-hop gateway IP address
+
+            Field (2) MAY be the full IP address of the destination
+
+
+
+Internet Engineering Task Force                                [Page 49]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+            host, or only the destination network number.  Field (3),
+            the TOS, SHOULD be included.
+
+            See Section 3.3.4.2 for a discussion of the implications of
+            multihoming for the lookup procedure in this cache.
+
+            DISCUSSION:
+                 Including the Type-of-Service field in the route cache
+                 and considering it in the host route algorithm will
+                 provide the necessary mechanism for the future when
+                 Type-of-Service routing is commonly used in the
+                 Internet.  See Section 3.2.1.6.
+
+                 Each route cache entry defines the endpoints of an
+                 Internet path.  Although the connecting path may change
+                 dynamically in an arbitrary way, the transmission
+                 characteristics of the path tend to remain
+                 approximately constant over a time period longer than a
+                 single typical host-host transport connection.
+                 Therefore, a route cache entry is a natural place to
+                 cache data on the properties of the path.  Examples of
+                 such properties might be the maximum unfragmented
+                 datagram size (see Section 3.3.3), or the average
+                 round-trip delay measured by a transport protocol.
+                 This data will generally be both gathered and used by a
+                 higher layer protocol, e.g., by TCP, or by an
+                 application using UDP.  Experiments are currently in
+                 progress on caching path properties in this manner.
+
+                 There is no consensus on whether the route cache should
+                 be keyed on destination host addresses alone, or allow
+                 both host and network addresses.  Those who favor the
+                 use of only host addresses argue that:
+
+                 (1)  As required in Section 3.3.1.2, Redirect messages
+                      will generally result in entries keyed on
+                      destination host addresses; the simplest and most
+                      general scheme would be to use host addresses
+                      always.
+
+                 (2)  The IP layer may not always know the address mask
+                      for a network address in a complex subnetted
+                      environment.
+
+                 (3)  The use of only host addresses allows the
+                      destination address to be used as a pure 32-bit
+                      number, which may allow the Internet architecture
+                      to be more easily extended in the future without
+
+
+
+Internet Engineering Task Force                                [Page 50]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+                      any change to the hosts.
+
+                 The opposing view is that allowing a mixture of
+                 destination hosts and networks in the route cache:
+
+                 (1)  Saves memory space.
+
+                 (2)  Leads to a simpler data structure, easily
+                      combining the cache with the tables of default and
+                      static routes (see below).
+
+                 (3)  Provides a more useful place to cache path
+                      properties, as discussed earlier.
+
+
+            IMPLEMENTATION:
+                 The cache needs to be large enough to include entries
+                 for the maximum number of destination hosts that may be
+                 in use at one time.
+
+                 A route cache entry may also include control
+                 information used to choose an entry for replacement.
+                 This might take the form of a "recently used" bit, a
+                 use count, or a last-used timestamp, for example.  It
+                 is recommended that it include the time of last
+                 modification of the entry, for diagnostic purposes.
+
+                 An implementation may wish to reduce the overhead of
+                 scanning the route cache for every datagram to be
+                 transmitted.  This may be accomplished with a hash
+                 table to speed the lookup, or by giving a connection-
+                 oriented transport protocol a "hint" or temporary
+                 handle on the appropriate cache entry, to be passed to
+                 the IP layer with each subsequent datagram.
+
+                 Although we have described the route cache, the lists
+                 of default gateways, and a table of static routes as
+                 conceptually distinct, in practice they may be combined
+                 into a single "routing table" data structure.
+
+         3.3.1.4  Dead Gateway Detection
+
+            The IP layer MUST be able to detect the failure of a "next-
+            hop" gateway that is listed in its route cache and to choose
+            an alternate gateway (see Section 3.3.1.5).
+
+            Dead gateway detection is covered in some detail in RFC-816
+            [IP:11]. Experience to date has not produced a complete
+
+
+
+Internet Engineering Task Force                                [Page 51]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+            algorithm which is totally satisfactory, though it has
+            identified several forbidden paths and promising techniques.
+
+            *    A particular gateway SHOULD NOT be used indefinitely in
+                 the absence of positive indications that it is
+                 functioning.
+
+            *    Active probes such as "pinging" (i.e., using an ICMP
+                 Echo Request/Reply exchange) are expensive and scale
+                 poorly.  In particular, hosts MUST NOT actively check
+                 the status of a first-hop gateway by simply pinging the
+                 gateway continuously.
+
+            *    Even when it is the only effective way to verify a
+                 gateway's status, pinging MUST be used only when
+                 traffic is being sent to the gateway and when there is
+                 no other positive indication to suggest that the
+                 gateway is functioning.
+
+            *    To avoid pinging, the layers above and/or below the
+                 Internet layer SHOULD be able to give "advice" on the
+                 status of route cache entries when either positive
+                 (gateway OK) or negative (gateway dead) information is
+                 available.
+
+
+            DISCUSSION:
+                 If an implementation does not include an adequate
+                 mechanism for detecting a dead gateway and re-routing,
+                 a gateway failure may cause datagrams to apparently
+                 vanish into a "black hole".  This failure can be
+                 extremely confusing for users and difficult for network
+                 personnel to debug.
+
+                 The dead-gateway detection mechanism must not cause
+                 unacceptable load on the host, on connected networks,
+                 or on first-hop gateway(s).  The exact constraints on
+                 the timeliness of dead gateway detection and on
+                 acceptable load may vary somewhat depending on the
+                 nature of the host's mission, but a host generally
+                 needs to detect a failed first-hop gateway quickly
+                 enough that transport-layer connections will not break
+                 before an alternate gateway can be selected.
+
+                 Passing advice from other layers of the protocol stack
+                 complicates the interfaces between the layers, but it
+                 is the preferred approach to dead gateway detection.
+                 Advice can come from almost any part of the IP/TCP
+
+
+
+Internet Engineering Task Force                                [Page 52]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+                 architecture, but it is expected to come primarily from
+                 the transport and link layers.  Here are some possible
+                 sources for gateway advice:
+
+                 o    TCP or any connection-oriented transport protocol
+                      should be able to give negative advice, e.g.,
+                      triggered by excessive retransmissions.
+
+                 o    TCP may give positive advice when (new) data is
+                      acknowledged.  Even though the route may be
+                      asymmetric, an ACK for new data proves that the
+                      acknowleged data must have been transmitted
+                      successfully.
+
+                 o    An ICMP Redirect message from a particular gateway
+                      should be used as positive advice about that
+                      gateway.
+
+                 o    Link-layer information that reliably detects and
+                      reports host failures (e.g., ARPANET Destination
+                      Dead messages) should be used as negative advice.
+
+                 o    Failure to ARP or to re-validate ARP mappings may
+                      be used as negative advice for the corresponding
+                      IP address.
+
+                 o    Packets arriving from a particular link-layer
+                      address are evidence that the system at this
+                      address is alive.  However, turning this
+                      information into advice about gateways requires
+                      mapping the link-layer address into an IP address,
+                      and then checking that IP address against the
+                      gateways pointed to by the route cache.  This is
+                      probably prohibitively inefficient.
+
+                 Note that positive advice that is given for every
+                 datagram received may cause unacceptable overhead in
+                 the implementation.
+
+                 While advice might be passed using required arguments
+                 in all interfaces to the IP layer, some transport and
+                 application layer protocols cannot deduce the correct
+                 advice.  These interfaces must therefore allow a
+                 neutral value for advice, since either always-positive
+                 or always-negative advice leads to incorrect behavior.
+
+                 There is another technique for dead gateway detection
+                 that has been commonly used but is not recommended.
+
+
+
+Internet Engineering Task Force                                [Page 53]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+                 This technique depends upon the host passively
+                 receiving ("wiretapping") the Interior Gateway Protocol
+                 (IGP) datagrams that the gateways are broadcasting to
+                 each other.  This approach has the drawback that a host
+                 needs to recognize all the interior gateway protocols
+                 that gateways may use (see [INTRO:2]).  In addition, it
+                 only works on a broadcast network.
+
+                 At present, pinging (i.e., using ICMP Echo messages) is
+                 the mechanism for gateway probing when absolutely
+                 required.  A successful ping guarantees that the
+                 addressed interface and its associated machine are up,
+                 but it does not guarantee that the machine is a gateway
+                 as opposed to a host.  The normal inference is that if
+                 a Redirect or other evidence indicates that a machine
+                 was a gateway, successful pings will indicate that the
+                 machine is still up and hence still a gateway.
+                 However, since a host silently discards packets that a
+                 gateway would forward or redirect, this assumption
+                 could sometimes fail.  To avoid this problem, a new
+                 ICMP message under development will ask "are you a
+                 gateway?"
+
+            IMPLEMENTATION:
+                 The following specific algorithm has been suggested:
+
+                 o    Associate a "reroute timer" with each gateway
+                      pointed to by the route cache.  Initialize the
+                      timer to a value Tr, which must be small enough to
+                      allow detection of a dead gateway before transport
+                      connections time out.
+
+                 o    Positive advice would reset the reroute timer to
+                      Tr.  Negative advice would reduce or zero the
+                      reroute timer.
+
+                 o    Whenever the IP layer used a particular gateway to
+                      route a datagram, it would check the corresponding
+                      reroute timer.  If the timer had expired (reached
+                      zero), the IP layer would send a ping to the
+                      gateway, followed immediately by the datagram.
+
+                 o    The ping (ICMP Echo) would be sent again if
+                      necessary, up to N times.  If no ping reply was
+                      received in N tries, the gateway would be assumed
+                      to have failed, and a new first-hop gateway would
+                      be chosen for all cache entries pointing to the
+                      failed gateway.
+
+
+
+Internet Engineering Task Force                                [Page 54]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+                 Note that the size of Tr is inversely related to the
+                 amount of advice available.  Tr should be large enough
+                 to insure that:
+
+                 *    Any pinging will be at a low level (e.g., <10%) of
+                      all packets sent to a gateway from the host, AND
+
+                 *    pinging is infrequent (e.g., every 3 minutes)
+
+                 Since the recommended algorithm is concerned with the
+                 gateways pointed to by route cache entries, rather than
+                 the cache entries themselves, a two level data
+                 structure (perhaps coordinated with ARP or similar
+                 caches) may be desirable for implementing a route
+                 cache.
+
+         3.3.1.5  New Gateway Selection
+
+            If the failed gateway is not the current default, the IP
+            layer can immediately switch to a default gateway.  If it is
+            the current default that failed, the IP layer MUST select a
+            different default gateway (assuming more than one default is
+            known) for the failed route and for establishing new routes.
+
+            DISCUSSION:
+                 When a gateway does fail, the other gateways on the
+                 connected network will learn of the failure through
+                 some inter-gateway routing protocol.  However, this
+                 will not happen instantaneously, since gateway routing
+                 protocols typically have a settling time of 30-60
+                 seconds.  If the host switches to an alternative
+                 gateway before the gateways have agreed on the failure,
+                 the new target gateway will probably forward the
+                 datagram to the failed gateway and send a Redirect back
+                 to the host pointing to the failed gateway (!).  The
+                 result is likely to be a rapid oscillation in the
+                 contents of the host's route cache during the gateway
+                 settling period.  It has been proposed that the dead-
+                 gateway logic should include some hysteresis mechanism
+                 to prevent such oscillations.  However, experience has
+                 not shown any harm from such oscillations, since
+                 service cannot be restored to the host until the
+                 gateways' routing information does settle down.
+
+            IMPLEMENTATION:
+                 One implementation technique for choosing a new default
+                 gateway is to simply round-robin among the default
+                 gateways in the host's list.  Another is to rank the
+
+
+
+Internet Engineering Task Force                                [Page 55]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+                 gateways in priority order, and when the current
+                 default gateway is not the highest priority one, to
+                 "ping" the higher-priority gateways slowly to detect
+                 when they return to service.  This pinging can be at a
+                 very low rate, e.g., 0.005 per second.
+
+         3.3.1.6  Initialization
+
+            The following information MUST be configurable:
+
+            (1)  IP address(es).
+
+            (2)  Address mask(s).
+
+            (3)  A list of default gateways, with a preference level.
+
+            A manual method of entering this configuration data MUST be
+            provided.  In addition, a variety of methods can be used to
+            determine this information dynamically; see the section on
+            "Host Initialization" in [INTRO:1].
+
+            DISCUSSION:
+                 Some host implementations use "wiretapping" of gateway
+                 protocols on a broadcast network to learn what gateways
+                 exist.  A standard method for default gateway discovery
+                 is under development.
+
+      3.3.2  Reassembly
+
+         The IP layer MUST implement reassembly of IP datagrams.
+
+         We designate the largest datagram size that can be reassembled
+         by EMTU_R ("Effective MTU to receive"); this is sometimes
+         called the "reassembly buffer size".  EMTU_R MUST be greater
+         than or equal to 576, SHOULD be either configurable or
+         indefinite, and SHOULD be greater than or equal to the MTU of
+         the connected network(s).
+
+         DISCUSSION:
+              A fixed EMTU_R limit should not be built into the code
+              because some application layer protocols require EMTU_R
+              values larger than 576.
+
+         IMPLEMENTATION:
+              An implementation may use a contiguous reassembly buffer
+              for each datagram, or it may use a more complex data
+              structure that places no definite limit on the reassembled
+              datagram size; in the latter case, EMTU_R is said to be
+
+
+
+Internet Engineering Task Force                                [Page 56]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+              "indefinite".
+
+              Logically, reassembly is performed by simply copying each
+              fragment into the packet buffer at the proper offset.
+              Note that fragments may overlap if successive
+              retransmissions use different packetizing but the same
+              reassembly Id.
+
+              The tricky part of reassembly is the bookkeeping to
+              determine when all bytes of the datagram have been
+              reassembled.  We recommend Clark's algorithm [IP:10] that
+              requires no additional data space for the bookkeeping.
+              However, note that, contrary to [IP:10], the first
+              fragment header needs to be saved for inclusion in a
+              possible ICMP Time Exceeded (Reassembly Timeout) message.
+
+         There MUST be a mechanism by which the transport layer can
+         learn MMS_R, the maximum message size that can be received and
+         reassembled in an IP datagram (see GET_MAXSIZES calls in
+         Section 3.4).  If EMTU_R is not indefinite, then the value of
+         MMS_R is given by:
+
+            MMS_R = EMTU_R - 20
+
+         since 20 is the minimum size of an IP header.
+
+         There MUST be a reassembly timeout.  The reassembly timeout
+         value SHOULD be a fixed value, not set from the remaining TTL.
+         It is recommended that the value lie between 60 seconds and 120
+         seconds.  If this timeout expires, the partially-reassembled
+         datagram MUST be discarded and an ICMP Time Exceeded message
+         sent to the source host (if fragment zero has been received).
+
+         DISCUSSION:
+              The IP specification says that the reassembly timeout
+              should be the remaining TTL from the IP header, but this
+              does not work well because gateways generally treat TTL as
+              a simple hop count rather than an elapsed time.  If the
+              reassembly timeout is too small, datagrams will be
+              discarded unnecessarily, and communication may fail.  The
+              timeout needs to be at least as large as the typical
+              maximum delay across the Internet.  A realistic minimum
+              reassembly timeout would be 60 seconds.
+
+              It has been suggested that a cache might be kept of
+              round-trip times measured by transport protocols for
+              various destinations, and that these values might be used
+              to dynamically determine a reasonable reassembly timeout
+
+
+
+Internet Engineering Task Force                                [Page 57]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+              value.  Further investigation of this approach is
+              required.
+
+              If the reassembly timeout is set too high, buffer
+              resources in the receiving host will be tied up too long,
+              and the MSL (Maximum Segment Lifetime) [TCP:1] will be
+              larger than necessary.  The MSL controls the maximum rate
+              at which fragmented datagrams can be sent using distinct
+              values of the 16-bit Ident field; a larger MSL lowers the
+              maximum rate.  The TCP specification [TCP:1] arbitrarily
+              assumes a value of 2 minutes for MSL.  This sets an upper
+              limit on a reasonable reassembly timeout value.
+
+      3.3.3  Fragmentation
+
+         Optionally, the IP layer MAY implement a mechanism to fragment
+         outgoing datagrams intentionally.
+
+         We designate by EMTU_S ("Effective MTU for sending") the
+         maximum IP datagram size that may be sent, for a particular
+         combination of IP source and destination addresses and perhaps
+         TOS.
+
+         A host MUST implement a mechanism to allow the transport layer
+         to learn MMS_S, the maximum transport-layer message size that
+         may be sent for a given {source, destination, TOS} triplet (see
+         GET_MAXSIZES call in Section 3.4).  If no local fragmentation
+         is performed, the value of MMS_S will be:
+
+            MMS_S = EMTU_S - <IP header size>
+
+         and EMTU_S must be less than or equal to the MTU of the network
+         interface corresponding to the source address of the datagram.
+         Note that <IP header size> in this equation will be 20, unless
+         the IP reserves space to insert IP options for its own purposes
+         in addition to any options inserted by the transport layer.
+
+         A host that does not implement local fragmentation MUST ensure
+         that the transport layer (for TCP) or the application layer
+         (for UDP) obtains MMS_S from the IP layer and does not send a
+         datagram exceeding MMS_S in size.
+
+         It is generally desirable to avoid local fragmentation and to
+         choose EMTU_S low enough to avoid fragmentation in any gateway
+         along the path.  In the absence of actual knowledge of the
+         minimum MTU along the path, the IP layer SHOULD use
+         EMTU_S <= 576 whenever the destination address is not on a
+         connected network, and otherwise use the connected network's
+
+
+
+Internet Engineering Task Force                                [Page 58]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+         MTU.
+
+         The MTU of each physical interface MUST be configurable.
+
+         A host IP layer implementation MAY have a configuration flag
+         "All-Subnets-MTU", indicating that the MTU of the connected
+         network is to be used for destinations on different subnets
+         within the same network, but not for other networks.  Thus,
+         this flag causes the network class mask, rather than the subnet
+         address mask, to be used to choose an EMTU_S.  For a multihomed
+         host, an "All-Subnets-MTU" flag is needed for each network
+         interface.
+
+         DISCUSSION:
+              Picking the correct datagram size to use when sending data
+              is a complex topic [IP:9].
+
+              (a)  In general, no host is required to accept an IP
+                   datagram larger than 576 bytes (including header and
+                   data), so a host must not send a larger datagram
+                   without explicit knowledge or prior arrangement with
+                   the destination host.  Thus, MMS_S is only an upper
+                   bound on the datagram size that a transport protocol
+                   may send; even when MMS_S exceeds 556, the transport
+                   layer must limit its messages to 556 bytes in the
+                   absence of other knowledge about the destination
+                   host.
+
+              (b)  Some transport protocols (e.g., TCP) provide a way to
+                   explicitly inform the sender about the largest
+                   datagram the other end can receive and reassemble
+                   [IP:7].  There is no corresponding mechanism in the
+                   IP layer.
+
+                   A transport protocol that assumes an EMTU_R larger
+                   than 576 (see Section 3.3.2), can send a datagram of
+                   this larger size to another host that implements the
+                   same protocol.
+
+              (c)  Hosts should ideally limit their EMTU_S for a given
+                   destination to the minimum MTU of all the networks
+                   along the path, to avoid any fragmentation.  IP
+                   fragmentation, while formally correct, can create a
+                   serious transport protocol performance problem,
+                   because loss of a single fragment means all the
+                   fragments in the segment must be retransmitted
+                   [IP:9].
+
+
+
+
+Internet Engineering Task Force                                [Page 59]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+              Since nearly all networks in the Internet currently
+              support an MTU of 576 or greater, we strongly recommend
+              the use of 576 for datagrams sent to non-local networks.
+
+              It has been suggested that a host could determine the MTU
+              over a given path by sending a zero-offset datagram
+              fragment and waiting for the receiver to time out the
+              reassembly (which cannot complete!) and return an ICMP
+              Time Exceeded message.  This message would include the
+              largest remaining fragment header in its body.  More
+              direct mechanisms are being experimented with, but have
+              not yet been adopted (see e.g., RFC-1063).
+
+      3.3.4  Local Multihoming
+
+         3.3.4.1  Introduction
+
+            A multihomed host has multiple IP addresses, which we may
+            think of as "logical interfaces".  These logical interfaces
+            may be associated with one or more physical interfaces, and
+            these physical interfaces may be connected to the same or
+            different networks.
+
+            Here are some important cases of multihoming:
+
+            (a)  Multiple Logical Networks
+
+                 The Internet architects envisioned that each physical
+                 network would have a single unique IP network (or
+                 subnet) number.  However, LAN administrators have
+                 sometimes found it useful to violate this assumption,
+                 operating a LAN with multiple logical networks per
+                 physical connected network.
+
+                 If a host connected to such a physical network is
+                 configured to handle traffic for each of N different
+                 logical networks, then the host will have N logical
+                 interfaces.  These could share a single physical
+                 interface, or might use N physical interfaces to the
+                 same network.
+
+            (b)  Multiple Logical Hosts
+
+                 When a host has multiple IP addresses that all have the
+                 same <Network-number> part (and the same <Subnet-
+                 number> part, if any), the logical interfaces are known
+                 as "logical hosts".  These logical interfaces might
+                 share a single physical interface or might use separate
+
+
+
+Internet Engineering Task Force                                [Page 60]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+                 physical interfaces to the same physical network.
+
+            (c)  Simple Multihoming
+
+                 In this case, each logical interface is mapped into a
+                 separate physical interface and each physical interface
+                 is connected to a different physical network.  The term
+                 "multihoming" was originally applied only to this case,
+                 but it is now applied more generally.
+
+                 A host with embedded gateway functionality will
+                 typically fall into the simple multihoming case.  Note,
+                 however, that a host may be simply multihomed without
+                 containing an embedded gateway, i.e., without
+                 forwarding datagrams from one connected network to
+                 another.
+
+                 This case presents the most difficult routing problems.
+                 The choice of interface (i.e., the choice of first-hop
+                 network) may significantly affect performance or even
+                 reachability of remote parts of the Internet.
+
+
+            Finally, we note another possibility that is NOT
+            multihoming:  one logical interface may be bound to multiple
+            physical interfaces, in order to increase the reliability or
+            throughput between directly connected machines by providing
+            alternative physical paths between them.  For instance, two
+            systems might be connected by multiple point-to-point links.
+            We call this "link-layer multiplexing".  With link-layer
+            multiplexing, the protocols above the link layer are unaware
+            that multiple physical interfaces are present; the link-
+            layer device driver is responsible for multiplexing and
+            routing packets across the physical interfaces.
+
+            In the Internet protocol architecture, a transport protocol
+            instance ("entity") has no address of its own, but instead
+            uses a single Internet Protocol (IP) address.  This has
+            implications for the IP, transport, and application layers,
+            and for the interfaces between them.  In particular, the
+            application software may have to be aware of the multiple IP
+            addresses of a multihomed host; in other cases, the choice
+            can be made within the network software.
+
+         3.3.4.2  Multihoming Requirements
+
+            The following general rules apply to the selection of an IP
+            source address for sending a datagram from a multihomed
+
+
+
+Internet Engineering Task Force                                [Page 61]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+            host.
+
+            (1)  If the datagram is sent in response to a received
+                 datagram, the source address for the response SHOULD be
+                 the specific-destination address of the request.  See
+                 Sections 4.1.3.5 and 4.2.3.7 and the "General Issues"
+                 section of [INTRO:1] for more specific requirements on
+                 higher layers.
+
+                 Otherwise, a source address must be selected.
+
+            (2)  An application MUST be able to explicitly specify the
+                 source address for initiating a connection or a
+                 request.
+
+            (3)  In the absence of such a specification, the networking
+                 software MUST choose a source address.  Rules for this
+                 choice are described below.
+
+
+            There are two key requirement issues related to multihoming:
+
+            (A)  A host MAY silently discard an incoming datagram whose
+                 destination address does not correspond to the physical
+                 interface through which it is received.
+
+            (B)  A host MAY restrict itself to sending (non-source-
+                 routed) IP datagrams only through the physical
+                 interface that corresponds to the IP source address of
+                 the datagrams.
+
+
+            DISCUSSION:
+                 Internet host implementors have used two different
+                 conceptual models for multihoming, briefly summarized
+                 in the following discussion.  This document takes no
+                 stand on which model is preferred; each seems to have a
+                 place.  This ambivalence is reflected in the issues (A)
+                 and (B) being optional.
+
+                 o    Strong ES Model
+
+                      The Strong ES (End System, i.e., host) model
+                      emphasizes the host/gateway (ES/IS) distinction,
+                      and would therefore substitute MUST for MAY in
+                      issues (A) and (B) above.  It tends to model a
+                      multihomed host as a set of logical hosts within
+                      the same physical host.
+
+
+
+Internet Engineering Task Force                                [Page 62]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+                      With respect to (A), proponents of the Strong ES
+                      model note that automatic Internet routing
+                      mechanisms could not route a datagram to a
+                      physical interface that did not correspond to the
+                      destination address.
+
+                      Under the Strong ES model, the route computation
+                      for an outgoing datagram is the mapping:
+
+                         route(src IP addr, dest IP addr, TOS)
+                                                        -> gateway
+
+                      Here the source address is included as a parameter
+                      in order to select a gateway that is directly
+                      reachable on the corresponding physical interface.
+                      Note that this model logically requires that in
+                      general there be at least one default gateway, and
+                      preferably multiple defaults, for each IP source
+                      address.
+
+                 o    Weak ES Model
+
+                      This view de-emphasizes the ES/IS distinction, and
+                      would therefore substitute MUST NOT for MAY in
+                      issues (A) and (B).  This model may be the more
+                      natural one for hosts that wiretap gateway routing
+                      protocols, and is necessary for hosts that have
+                      embedded gateway functionality.
+
+                      The Weak ES Model may cause the Redirect mechanism
+                      to fail.  If a datagram is sent out a physical
+                      interface that does not correspond to the
+                      destination address, the first-hop gateway will
+                      not realize when it needs to send a Redirect.  On
+                      the other hand, if the host has embedded gateway
+                      functionality, then it has routing information
+                      without listening to Redirects.
+
+                      In the Weak ES model, the route computation for an
+                      outgoing datagram is the mapping:
+
+                         route(dest IP addr, TOS) -> gateway, interface
+
+
+
+
+
+
+
+
+
+Internet Engineering Task Force                                [Page 63]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+         3.3.4.3  Choosing a Source Address
+
+            DISCUSSION:
+                 When it sends an initial connection request (e.g., a
+                 TCP "SYN" segment) or a datagram service request (e.g.,
+                 a UDP-based query), the transport layer on a multihomed
+                 host needs to know which source address to use.  If the
+                 application does not specify it, the transport layer
+                 must ask the IP layer to perform the conceptual
+                 mapping:
+
+                     GET_SRCADDR(remote IP addr, TOS)
+                                               -> local IP address
+
+                 Here TOS is the Type-of-Service value (see Section
+                 3.2.1.6), and the result is the desired source address.
+                 The following rules are suggested for implementing this
+                 mapping:
+
+                 (a)  If the remote Internet address lies on one of the
+                      (sub-) nets to which the host is directly
+                      connected, a corresponding source address may be
+                      chosen, unless the corresponding interface is
+                      known to be down.
+
+                 (b)  The route cache may be consulted, to see if there
+                      is an active route to the specified destination
+                      network through any network interface; if so, a
+                      local IP address corresponding to that interface
+                      may be chosen.
+
+                 (c)  The table of static routes, if any (see Section
+                      3.3.1.2) may be similarly consulted.
+
+                 (d)  The default gateways may be consulted.  If these
+                      gateways are assigned to different interfaces, the
+                      interface corresponding to the gateway with the
+                      highest preference may be chosen.
+
+                 In the future, there may be a defined way for a
+                 multihomed host to ask the gateways on all connected
+                 networks for advice about the best network to use for a
+                 given destination.
+
+            IMPLEMENTATION:
+                 It will be noted that this process is essentially the
+                 same as datagram routing (see Section 3.3.1), and
+                 therefore hosts may be able to combine the
+
+
+
+Internet Engineering Task Force                                [Page 64]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+                 implementation of the two functions.
+
+      3.3.5  Source Route Forwarding
+
+         Subject to restrictions given below, a host MAY be able to act
+         as an intermediate hop in a source route, forwarding a source-
+         routed datagram to the next specified hop.
+
+         However, in performing this gateway-like function, the host
+         MUST obey all the relevant rules for a gateway forwarding
+         source-routed datagrams [INTRO:2].  This includes the following
+         specific provisions, which override the corresponding host
+         provisions given earlier in this document:
+
+         (A)  TTL (ref. Section 3.2.1.7)
+
+              The TTL field MUST be decremented and the datagram perhaps
+              discarded as specified for a gateway in [INTRO:2].
+
+         (B)  ICMP Destination Unreachable (ref. Section 3.2.2.1)
+
+              A host MUST be able to generate Destination Unreachable
+              messages with the following codes:
+
+              4    (Fragmentation Required but DF Set) when a source-
+                   routed datagram cannot be fragmented to fit into the
+                   target network;
+
+              5    (Source Route Failed) when a source-routed datagram
+                   cannot be forwarded, e.g., because of a routing
+                   problem or because the next hop of a strict source
+                   route is not on a connected network.
+
+         (C)  IP Source Address (ref. Section 3.2.1.3)
+
+              A source-routed datagram being forwarded MAY (and normally
+              will) have a source address that is not one of the IP
+              addresses of the forwarding host.
+
+         (D)  Record Route Option (ref. Section 3.2.1.8d)
+
+              A host that is forwarding a source-routed datagram
+              containing a Record Route option MUST update that option,
+              if it has room.
+
+         (E)  Timestamp Option (ref. Section 3.2.1.8e)
+
+              A host that is forwarding a source-routed datagram
+
+
+
+Internet Engineering Task Force                                [Page 65]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+              containing a Timestamp Option MUST add the current
+              timestamp to that option, according to the rules for this
+              option.
+
+         To define the rules restricting host forwarding of source-
+         routed datagrams, we use the term "local source-routing" if the
+         next hop will be through the same physical interface through
+         which the datagram arrived; otherwise, it is "non-local
+         source-routing".
+
+         o    A host is permitted to perform local source-routing
+              without restriction.
+
+         o    A host that supports non-local source-routing MUST have a
+              configurable switch to disable forwarding, and this switch
+              MUST default to disabled.
+
+         o    The host MUST satisfy all gateway requirements for
+              configurable policy filters [INTRO:2] restricting non-
+              local forwarding.
+
+         If a host receives a datagram with an incomplete source route
+         but does not forward it for some reason, the host SHOULD return
+         an ICMP Destination Unreachable (code 5, Source Route Failed)
+         message, unless the datagram was itself an ICMP error message.
+
+      3.3.6  Broadcasts
+
+         Section 3.2.1.3 defined the four standard IP broadcast address
+         forms:
+
+           Limited Broadcast:  {-1, -1}
+
+           Directed Broadcast:  {<Network-number>,-1}
+
+           Subnet Directed Broadcast:
+                              {<Network-number>,<Subnet-number>,-1}
+
+           All-Subnets Directed Broadcast: {<Network-number>,-1,-1}
+
+         A host MUST recognize any of these forms in the destination
+         address of an incoming datagram.
+
+         There is a class of hosts* that use non-standard broadcast
+         address forms, substituting 0 for -1.  All hosts SHOULD
+_________________________
+*4.2BSD Unix and its derivatives, but not 4.3BSD.
+
+
+
+
+Internet Engineering Task Force                                [Page 66]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+         recognize and accept any of these non-standard broadcast
+         addresses as the destination address of an incoming datagram.
+         A host MAY optionally have a configuration option to choose the
+         0 or the -1 form of broadcast address, for each physical
+         interface, but this option SHOULD default to the standard (-1)
+         form.
+
+         When a host sends a datagram to a link-layer broadcast address,
+         the IP destination address MUST be a legal IP broadcast or IP
+         multicast address.
+
+         A host SHOULD silently discard a datagram that is received via
+         a link-layer broadcast (see Section 2.4) but does not specify
+         an IP multicast or broadcast destination address.
+
+         Hosts SHOULD use the Limited Broadcast address to broadcast to
+         a connected network.
+
+
+         DISCUSSION:
+              Using the Limited Broadcast address instead of a Directed
+              Broadcast address may improve system robustness.  Problems
+              are often caused by machines that do not understand the
+              plethora of broadcast addresses (see Section 3.2.1.3), or
+              that may have different ideas about which broadcast
+              addresses are in use.  The prime example of the latter is
+              machines that do not understand subnetting but are
+              attached to a subnetted net.  Sending a Subnet Broadcast
+              for the connected network will confuse those machines,
+              which will see it as a message to some other host.
+
+              There has been discussion on whether a datagram addressed
+              to the Limited Broadcast address ought to be sent from all
+              the interfaces of a multihomed host.  This specification
+              takes no stand on the issue.
+
+      3.3.7  IP Multicasting
+
+         A host SHOULD support local IP multicasting on all connected
+         networks for which a mapping from Class D IP addresses to
+         link-layer addresses has been specified (see below).  Support
+         for local IP multicasting includes sending multicast datagrams,
+         joining multicast groups and receiving multicast datagrams, and
+         leaving multicast groups.  This implies support for all of
+         [IP:4] except the IGMP protocol itself, which is OPTIONAL.
+
+
+
+
+
+
+Internet Engineering Task Force                                [Page 67]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+         DISCUSSION:
+              IGMP provides gateways that are capable of multicast
+              routing with the information required to support IP
+              multicasting across multiple networks.  At this time,
+              multicast-routing gateways are in the experimental stage
+              and are not widely available.  For hosts that are not
+              connected to networks with multicast-routing gateways or
+              that do not need to receive multicast datagrams
+              originating on other networks, IGMP serves no purpose and
+              is therefore optional for now.  However, the rest of
+              [IP:4] is currently recommended for the purpose of
+              providing IP-layer access to local network multicast
+              addressing, as a preferable alternative to local broadcast
+              addressing.  It is expected that IGMP will become
+              recommended at some future date, when multicast-routing
+              gateways have become more widely available.
+
+         If IGMP is not implemented, a host SHOULD still join the "all-
+         hosts" group (224.0.0.1) when the IP layer is initialized and
+         remain a member for as long as the IP layer is active.
+
+         DISCUSSION:
+              Joining the "all-hosts" group will support strictly local
+              uses of multicasting, e.g., a gateway discovery protocol,
+              even if IGMP is not implemented.
+
+         The mapping of IP Class D addresses to local addresses is
+         currently specified for the following types of networks:
+
+         o    Ethernet/IEEE 802.3, as defined in [IP:4].
+
+         o    Any network that supports broadcast but not multicast,
+              addressing: all IP Class D addresses map to the local
+              broadcast address.
+
+         o    Any type of point-to-point link (e.g., SLIP or HDLC
+              links): no mapping required.  All IP multicast datagrams
+              are sent as-is, inside the local framing.
+
+         Mappings for other types of networks will be specified in the
+         future.
+
+         A host SHOULD provide a way for higher-layer protocols or
+         applications to determine which of the host's connected
+         network(s) support IP multicast addressing.
+
+
+
+
+
+
+Internet Engineering Task Force                                [Page 68]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+      3.3.8  Error Reporting
+
+         Wherever practical, hosts MUST return ICMP error datagrams on
+         detection of an error, except in those cases where returning an
+         ICMP error message is specifically prohibited.
+
+         DISCUSSION:
+              A common phenomenon in datagram networks is the "black
+              hole disease": datagrams are sent out, but nothing comes
+              back.  Without any error datagrams, it is difficult for
+              the user to figure out what the problem is.
+
+   3.4  INTERNET/TRANSPORT LAYER INTERFACE
+
+      The interface between the IP layer and the transport layer MUST
+      provide full access to all the mechanisms of the IP layer,
+      including options, Type-of-Service, and Time-to-Live.  The
+      transport layer MUST either have mechanisms to set these interface
+      parameters, or provide a path to pass them through from an
+      application, or both.
+
+      DISCUSSION:
+           Applications are urged to make use of these mechanisms where
+           applicable, even when the mechanisms are not currently
+           effective in the Internet (e.g., TOS).  This will allow these
+           mechanisms to be immediately useful when they do become
+           effective, without a large amount of retrofitting of host
+           software.
+
+      We now describe a conceptual interface between the transport layer
+      and the IP layer, as a set of procedure calls.  This is an
+      extension of the information in Section 3.3 of RFC-791 [IP:1].
+
+
+      *    Send Datagram
+
+                SEND(src, dst, prot, TOS, TTL, BufPTR, len, Id, DF, opt
+                     => result )
+
+           where the parameters are defined in RFC-791.  Passing an Id
+           parameter is optional; see Section 3.2.1.5.
+
+
+      *    Receive Datagram
+
+                RECV(BufPTR, prot
+                     => result, src, dst, SpecDest, TOS, len, opt)
+
+
+
+
+Internet Engineering Task Force                                [Page 69]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+           All the parameters are defined in RFC-791, except for:
+
+                SpecDest = specific-destination address of datagram
+                            (defined in Section 3.2.1.3)
+
+           The result parameter dst contains the datagram's destination
+           address.  Since this may be a broadcast or multicast address,
+           the SpecDest parameter (not shown in RFC-791) MUST be passed.
+           The parameter opt contains all the IP options received in the
+           datagram; these MUST also be passed to the transport layer.
+
+
+      *    Select Source Address
+
+                GET_SRCADDR(remote, TOS)  -> local
+
+                remote = remote IP address
+                TOS = Type-of-Service
+                local = local IP address
+
+           See Section 3.3.4.3.
+
+
+      *    Find Maximum Datagram Sizes
+
+                GET_MAXSIZES(local, remote, TOS) -> MMS_R, MMS_S
+
+                MMS_R = maximum receive transport-message size.
+                MMS_S = maximum send transport-message size.
+               (local, remote, TOS defined above)
+
+           See Sections 3.3.2 and 3.3.3.
+
+
+      *    Advice on Delivery Success
+
+                ADVISE_DELIVPROB(sense, local, remote, TOS)
+
+           Here the parameter sense is a 1-bit flag indicating whether
+           positive or negative advice is being given; see the
+           discussion in Section 3.3.1.4. The other parameters were
+           defined earlier.
+
+
+      *    Send ICMP Message
+
+                SEND_ICMP(src, dst, TOS, TTL, BufPTR, len, Id, DF, opt)
+                     -> result
+
+
+
+Internet Engineering Task Force                                [Page 70]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+                (Parameters defined in RFC-791).
+
+           Passing an Id parameter is optional; see Section 3.2.1.5.
+           The transport layer MUST be able to send certain ICMP
+           messages:  Port Unreachable or any of the query-type
+           messages.  This function could be considered to be a special
+           case of the SEND() call, of course; we describe it separately
+           for clarity.
+
+
+      *    Receive ICMP Message
+
+                RECV_ICMP(BufPTR ) -> result, src, dst, len, opt
+
+                (Parameters defined in RFC-791).
+
+           The IP layer MUST pass certain ICMP messages up to the
+           appropriate transport-layer routine.  This function could be
+           considered to be a special case of the RECV() call, of
+           course; we describe it separately for clarity.
+
+           For an ICMP error message, the data that is passed up MUST
+           include the original Internet header plus all the octets of
+           the original message that are included in the ICMP message.
+           This data will be used by the transport layer to locate the
+           connection state information, if any.
+
+           In particular, the following ICMP messages are to be passed
+           up:
+
+           o    Destination Unreachable
+
+           o    Source Quench
+
+           o    Echo Reply (to ICMP user interface, unless the Echo
+                Request originated in the IP layer)
+
+           o    Timestamp Reply (to ICMP user interface)
+
+           o    Time Exceeded
+
+
+      DISCUSSION:
+           In the future, there may be additions to this interface to
+           pass path data (see Section 3.3.1.3) between the IP and
+           transport layers.
+
+
+
+
+
+Internet Engineering Task Force                                [Page 71]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+   3.5  INTERNET LAYER REQUIREMENTS SUMMARY
+
+
+                                                 |        | | | |S| |
+                                                 |        | | | |H| |F
+                                                 |        | | | |O|M|o
+                                                 |        | |S| |U|U|o
+                                                 |        | |H| |L|S|t
+                                                 |        |M|O| |D|T|n
+                                                 |        |U|U|M| | |o
+                                                 |        |S|L|A|N|N|t
+                                                 |        |T|D|Y|O|O|t
+FEATURE                                          |SECTION | | | |T|T|e
+-------------------------------------------------|--------|-|-|-|-|-|--
+                                                 |        | | | | | |
+Implement IP and ICMP                            |3.1     |x| | | | |
+Handle remote multihoming in application layer   |3.1     |x| | | | |
+Support local multihoming                        |3.1     | | |x| | |
+Meet gateway specs if forward datagrams          |3.1     |x| | | | |
+Configuration switch for embedded gateway        |3.1     |x| | | | |1
+   Config switch default to non-gateway          |3.1     |x| | | | |1
+   Auto-config based on number of interfaces     |3.1     | | | | |x|1
+Able to log discarded datagrams                  |3.1     | |x| | | |
+   Record in counter                             |3.1     | |x| | | |
+                                                 |        | | | | | |
+Silently discard Version != 4                    |3.2.1.1 |x| | | | |
+Verify IP checksum, silently discard bad dgram   |3.2.1.2 |x| | | | |
+Addressing:                                      |        | | | | | |
+  Subnet addressing (RFC-950)                    |3.2.1.3 |x| | | | |
+  Src address must be host's own IP address      |3.2.1.3 |x| | | | |
+  Silently discard datagram with bad dest addr   |3.2.1.3 |x| | | | |
+  Silently discard datagram with bad src addr    |3.2.1.3 |x| | | | |
+Support reassembly                               |3.2.1.4 |x| | | | |
+Retain same Id field in identical datagram       |3.2.1.5 | | |x| | |
+                                                 |        | | | | | |
+TOS:                                             |        | | | | | |
+  Allow transport layer to set TOS               |3.2.1.6 |x| | | | |
+  Pass received TOS up to transport layer        |3.2.1.6 | |x| | | |
+  Use RFC-795 link-layer mappings for TOS        |3.2.1.6 | | | |x| |
+TTL:                                             |        | | | | | |
+  Send packet with TTL of 0                      |3.2.1.7 | | | | |x|
+  Discard received packets with TTL < 2          |3.2.1.7 | | | | |x|
+  Allow transport layer to set TTL               |3.2.1.7 |x| | | | |
+  Fixed TTL is configurable                      |3.2.1.7 |x| | | | |
+                                                 |        | | | | | |
+IP Options:                                      |        | | | | | |
+  Allow transport layer to send IP options       |3.2.1.8 |x| | | | |
+  Pass all IP options rcvd to higher layer       |3.2.1.8 |x| | | | |
+
+
+
+Internet Engineering Task Force                                [Page 72]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+  IP layer silently ignore unknown options       |3.2.1.8 |x| | | | |
+  Security option                                |3.2.1.8a| | |x| | |
+  Send Stream Identifier option                  |3.2.1.8b| | | |x| |
+  Silently ignore Stream Identifer option        |3.2.1.8b|x| | | | |
+  Record Route option                            |3.2.1.8d| | |x| | |
+  Timestamp option                               |3.2.1.8e| | |x| | |
+Source Route Option:                             |        | | | | | |
+  Originate & terminate Source Route options     |3.2.1.8c|x| | | | |
+  Datagram with completed SR passed up to TL     |3.2.1.8c|x| | | | |
+  Build correct (non-redundant) return route     |3.2.1.8c|x| | | | |
+  Send multiple SR options in one header         |3.2.1.8c| | | | |x|
+                                                 |        | | | | | |
+ICMP:                                            |        | | | | | |
+  Silently discard ICMP msg with unknown type    |3.2.2   |x| | | | |
+  Include more than 8 octets of orig datagram    |3.2.2   | | |x| | |
+      Included octets same as received           |3.2.2   |x| | | | |
+  Demux ICMP Error to transport protocol         |3.2.2   |x| | | | |
+  Send ICMP error message with TOS=0             |3.2.2   | |x| | | |
+  Send ICMP error message for:                   |        | | | | | |
+   - ICMP error msg                              |3.2.2   | | | | |x|
+   - IP b'cast or IP m'cast                      |3.2.2   | | | | |x|
+   - Link-layer b'cast                           |3.2.2   | | | | |x|
+   - Non-initial fragment                        |3.2.2   | | | | |x|
+   - Datagram with non-unique src address        |3.2.2   | | | | |x|
+  Return ICMP error msgs (when not prohibited)   |3.3.8   |x| | | | |
+                                                 |        | | | | | |
+  Dest Unreachable:                              |        | | | | | |
+    Generate Dest Unreachable (code 2/3)         |3.2.2.1 | |x| | | |
+    Pass ICMP Dest Unreachable to higher layer   |3.2.2.1 |x| | | | |
+    Higher layer act on Dest Unreach             |3.2.2.1 | |x| | | |
+      Interpret Dest Unreach as only hint        |3.2.2.1 |x| | | | |
+  Redirect:                                      |        | | | | | |
+    Host send Redirect                           |3.2.2.2 | | | |x| |
+    Update route cache when recv Redirect        |3.2.2.2 |x| | | | |
+    Handle both Host and Net Redirects           |3.2.2.2 |x| | | | |
+    Discard illegal Redirect                     |3.2.2.2 | |x| | | |
+  Source Quench:                                 |        | | | | | |
+    Send Source Quench if buffering exceeded     |3.2.2.3 | | |x| | |
+    Pass Source Quench to higher layer           |3.2.2.3 |x| | | | |
+    Higher layer act on Source Quench            |3.2.2.3 | |x| | | |
+  Time Exceeded: pass to higher layer            |3.2.2.4 |x| | | | |
+  Parameter Problem:                             |        | | | | | |
+    Send Parameter Problem messages              |3.2.2.5 | |x| | | |
+    Pass Parameter Problem to higher layer       |3.2.2.5 |x| | | | |
+    Report Parameter Problem to user             |3.2.2.5 | | |x| | |
+                                                 |        | | | | | |
+  ICMP Echo Request or Reply:                    |        | | | | | |
+    Echo server and Echo client                  |3.2.2.6 |x| | | | |
+
+
+
+Internet Engineering Task Force                                [Page 73]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+    Echo client                                  |3.2.2.6 | |x| | | |
+    Discard Echo Request to broadcast address    |3.2.2.6 | | |x| | |
+    Discard Echo Request to multicast address    |3.2.2.6 | | |x| | |
+    Use specific-dest addr as Echo Reply src     |3.2.2.6 |x| | | | |
+    Send same data in Echo Reply                 |3.2.2.6 |x| | | | |
+    Pass Echo Reply to higher layer              |3.2.2.6 |x| | | | |
+    Reflect Record Route, Time Stamp options     |3.2.2.6 | |x| | | |
+    Reverse and reflect Source Route option      |3.2.2.6 |x| | | | |
+                                                 |        | | | | | |
+  ICMP Information Request or Reply:             |3.2.2.7 | | | |x| |
+  ICMP Timestamp and Timestamp Reply:            |3.2.2.8 | | |x| | |
+    Minimize delay variability                   |3.2.2.8 | |x| | | |1
+    Silently discard b'cast Timestamp            |3.2.2.8 | | |x| | |1
+    Silently discard m'cast Timestamp            |3.2.2.8 | | |x| | |1
+    Use specific-dest addr as TS Reply src       |3.2.2.8 |x| | | | |1
+    Reflect Record Route, Time Stamp options     |3.2.2.6 | |x| | | |1
+    Reverse and reflect Source Route option      |3.2.2.8 |x| | | | |1
+    Pass Timestamp Reply to higher layer         |3.2.2.8 |x| | | | |1
+    Obey rules for "standard value"              |3.2.2.8 |x| | | | |1
+                                                 |        | | | | | |
+  ICMP Address Mask Request and Reply:           |        | | | | | |
+    Addr Mask source configurable                |3.2.2.9 |x| | | | |
+    Support static configuration of addr mask    |3.2.2.9 |x| | | | |
+    Get addr mask dynamically during booting     |3.2.2.9 | | |x| | |
+    Get addr via ICMP Addr Mask Request/Reply    |3.2.2.9 | | |x| | |
+      Retransmit Addr Mask Req if no Reply       |3.2.2.9 |x| | | | |3
+      Assume default mask if no Reply            |3.2.2.9 | |x| | | |3
+      Update address mask from first Reply only  |3.2.2.9 |x| | | | |3
+    Reasonableness check on Addr Mask            |3.2.2.9 | |x| | | |
+    Send unauthorized Addr Mask Reply msgs       |3.2.2.9 | | | | |x|
+      Explicitly configured to be agent          |3.2.2.9 |x| | | | |
+    Static config=> Addr-Mask-Authoritative flag |3.2.2.9 | |x| | | |
+      Broadcast Addr Mask Reply when init.       |3.2.2.9 |x| | | | |3
+                                                 |        | | | | | |
+ROUTING OUTBOUND DATAGRAMS:                      |        | | | | | |
+  Use address mask in local/remote decision      |3.3.1.1 |x| | | | |
+  Operate with no gateways on conn network       |3.3.1.1 |x| | | | |
+  Maintain "route cache" of next-hop gateways    |3.3.1.2 |x| | | | |
+  Treat Host and Net Redirect the same           |3.3.1.2 | |x| | | |
+  If no cache entry, use default gateway         |3.3.1.2 |x| | | | |
+    Support multiple default gateways            |3.3.1.2 |x| | | | |
+  Provide table of static routes                 |3.3.1.2 | | |x| | |
+    Flag: route overridable by Redirects         |3.3.1.2 | | |x| | |
+  Key route cache on host, not net address       |3.3.1.3 | | |x| | |
+  Include TOS in route cache                     |3.3.1.3 | |x| | | |
+                                                 |        | | | | | |
+  Able to detect failure of next-hop gateway     |3.3.1.4 |x| | | | |
+  Assume route is good forever                   |3.3.1.4 | | | |x| |
+
+
+
+Internet Engineering Task Force                                [Page 74]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+  Ping gateways continuously                     |3.3.1.4 | | | | |x|
+  Ping only when traffic being sent              |3.3.1.4 |x| | | | |
+  Ping only when no positive indication          |3.3.1.4 |x| | | | |
+  Higher and lower layers give advice            |3.3.1.4 | |x| | | |
+  Switch from failed default g'way to another    |3.3.1.5 |x| | | | |
+  Manual method of entering config info          |3.3.1.6 |x| | | | |
+                                                 |        | | | | | |
+REASSEMBLY and FRAGMENTATION:                    |        | | | | | |
+  Able to reassemble incoming datagrams          |3.3.2   |x| | | | |
+    At least 576 byte datagrams                  |3.3.2   |x| | | | |
+    EMTU_R configurable or indefinite            |3.3.2   | |x| | | |
+  Transport layer able to learn MMS_R            |3.3.2   |x| | | | |
+  Send ICMP Time Exceeded on reassembly timeout  |3.3.2   |x| | | | |
+    Fixed reassembly timeout value               |3.3.2   | |x| | | |
+                                                 |        | | | | | |
+  Pass MMS_S to higher layers                    |3.3.3   |x| | | | |
+  Local fragmentation of outgoing packets        |3.3.3   | | |x| | |
+     Else don't send bigger than MMS_S           |3.3.3   |x| | | | |
+  Send max 576 to off-net destination            |3.3.3   | |x| | | |
+  All-Subnets-MTU configuration flag             |3.3.3   | | |x| | |
+                                                 |        | | | | | |
+MULTIHOMING:                                     |        | | | | | |
+  Reply with same addr as spec-dest addr         |3.3.4.2 | |x| | | |
+  Allow application to choose local IP addr      |3.3.4.2 |x| | | | |
+  Silently discard d'gram in "wrong" interface   |3.3.4.2 | | |x| | |
+  Only send d'gram through "right" interface     |3.3.4.2 | | |x| | |4
+                                                 |        | | | | | |
+SOURCE-ROUTE FORWARDING:                         |        | | | | | |
+  Forward datagram with Source Route option      |3.3.5   | | |x| | |1
+    Obey corresponding gateway rules             |3.3.5   |x| | | | |1
+      Update TTL by gateway rules                |3.3.5   |x| | | | |1
+      Able to generate ICMP err code 4, 5        |3.3.5   |x| | | | |1
+      IP src addr not local host                 |3.3.5   | | |x| | |1
+      Update Timestamp, Record Route options     |3.3.5   |x| | | | |1
+    Configurable switch for non-local SRing      |3.3.5   |x| | | | |1
+      Defaults to OFF                            |3.3.5   |x| | | | |1
+    Satisfy gwy access rules for non-local SRing |3.3.5   |x| | | | |1
+    If not forward, send Dest Unreach (cd 5)     |3.3.5   | |x| | | |2
+                                                 |        | | | | | |
+BROADCAST:                                       |        | | | | | |
+  Broadcast addr as IP source addr               |3.2.1.3 | | | | |x|
+  Receive 0 or -1 broadcast formats OK           |3.3.6   | |x| | | |
+  Config'ble option to send 0 or -1 b'cast       |3.3.6   | | |x| | |
+    Default to -1 broadcast                      |3.3.6   | |x| | | |
+  Recognize all broadcast address formats        |3.3.6   |x| | | | |
+  Use IP b'cast/m'cast addr in link-layer b'cast |3.3.6   |x| | | | |
+  Silently discard link-layer-only b'cast dg's   |3.3.6   | |x| | | |
+  Use Limited Broadcast addr for connected net   |3.3.6   | |x| | | |
+
+
+
+Internet Engineering Task Force                                [Page 75]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+                                                 |        | | | | | |
+MULTICAST:                                       |        | | | | | |
+  Support local IP multicasting (RFC-1112)       |3.3.7   | |x| | | |
+  Support IGMP (RFC-1112)                        |3.3.7   | | |x| | |
+  Join all-hosts group at startup                |3.3.7   | |x| | | |
+  Higher layers learn i'face m'cast capability   |3.3.7   | |x| | | |
+                                                 |        | | | | | |
+INTERFACE:                                       |        | | | | | |
+  Allow transport layer to use all IP mechanisms |3.4     |x| | | | |
+  Pass interface ident up to transport layer     |3.4     |x| | | | |
+  Pass all IP options up to transport layer      |3.4     |x| | | | |
+  Transport layer can send certain ICMP messages |3.4     |x| | | | |
+  Pass spec'd ICMP messages up to transp. layer  |3.4     |x| | | | |
+     Include IP hdr+8 octets or more from orig.  |3.4     |x| | | | |
+  Able to leap tall buildings at a single bound  |3.5     | |x| | | |
+
+Footnotes:
+
+(1)  Only if feature is implemented.
+
+(2)  This requirement is overruled if datagram is an ICMP error message.
+
+(3)  Only if feature is implemented and is configured "on".
+
+(4)  Unless has embedded gateway functionality or is source routed.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Internet Engineering Task Force                                [Page 76]
+
+
+
+
+RFC1122                  TRANSPORT LAYER -- UDP             October 1989
+
+
+4. TRANSPORT PROTOCOLS
+
+   4.1  USER DATAGRAM PROTOCOL -- UDP
+
+      4.1.1  INTRODUCTION
+
+         The User Datagram Protocol UDP [UDP:1] offers only a minimal
+         transport service -- non-guaranteed datagram delivery -- and
+         gives applications direct access to the datagram service of the
+         IP layer.  UDP is used by applications that do not require the
+         level of service of TCP or that wish to use communications
+         services (e.g., multicast or broadcast delivery) not available
+         from TCP.
+
+         UDP is almost a null protocol; the only services it provides
+         over IP are checksumming of data and multiplexing by port
+         number.  Therefore, an application program running over UDP
+         must deal directly with end-to-end communication problems that
+         a connection-oriented protocol would have handled -- e.g.,
+         retransmission for reliable delivery, packetization and
+         reassembly, flow control, congestion avoidance, etc., when
+         these are required.  The fairly complex coupling between IP and
+         TCP will be mirrored in the coupling between UDP and many
+         applications using UDP.
+
+      4.1.2  PROTOCOL WALK-THROUGH
+
+         There are no known errors in the specification of UDP.
+
+      4.1.3  SPECIFIC ISSUES
+
+         4.1.3.1  Ports
+
+            UDP well-known ports follow the same rules as TCP well-known
+            ports; see Section 4.2.2.1 below.
+
+            If a datagram arrives addressed to a UDP port for which
+            there is no pending LISTEN call, UDP SHOULD send an ICMP
+            Port Unreachable message.
+
+         4.1.3.2  IP Options
+
+            UDP MUST pass any IP option that it receives from the IP
+            layer transparently to the application layer.
+
+            An application MUST be able to specify IP options to be sent
+            in its UDP datagrams, and UDP MUST pass these options to the
+            IP layer.
+
+
+
+Internet Engineering Task Force                                [Page 77]
+
+
+
+
+RFC1122                  TRANSPORT LAYER -- UDP             October 1989
+
+
+            DISCUSSION:
+                 At present, the only options that need be passed
+                 through UDP are Source Route, Record Route, and Time
+                 Stamp.  However, new options may be defined in the
+                 future, and UDP need not and should not make any
+                 assumptions about the format or content of options it
+                 passes to or from the application; an exception to this
+                 might be an IP-layer security option.
+
+                 An application based on UDP will need to obtain a
+                 source route from a request datagram and supply a
+                 reversed route for sending the corresponding reply.
+
+         4.1.3.3  ICMP Messages
+
+            UDP MUST pass to the application layer all ICMP error
+            messages that it receives from the IP layer.  Conceptually
+            at least, this may be accomplished with an upcall to the
+            ERROR_REPORT routine (see Section 4.2.4.1).
+
+            DISCUSSION:
+                 Note that ICMP error messages resulting from sending a
+                 UDP datagram are received asynchronously.  A UDP-based
+                 application that wants to receive ICMP error messages
+                 is responsible for maintaining the state necessary to
+                 demultiplex these messages when they arrive; for
+                 example, the application may keep a pending receive
+                 operation for this purpose.  The application is also
+                 responsible to avoid confusion from a delayed ICMP
+                 error message resulting from an earlier use of the same
+                 port(s).
+
+         4.1.3.4  UDP Checksums
+
+            A host MUST implement the facility to generate and validate
+            UDP checksums.  An application MAY optionally be able to
+            control whether a UDP checksum will be generated, but it
+            MUST default to checksumming on.
+
+            If a UDP datagram is received with a checksum that is non-
+            zero and invalid, UDP MUST silently discard the datagram.
+            An application MAY optionally be able to control whether UDP
+            datagrams without checksums should be discarded or passed to
+            the application.
+
+            DISCUSSION:
+                 Some applications that normally run only across local
+                 area networks have chosen to turn off UDP checksums for
+
+
+
+Internet Engineering Task Force                                [Page 78]
+
+
+
+
+RFC1122                  TRANSPORT LAYER -- UDP             October 1989
+
+
+                 efficiency.  As a result, numerous cases of undetected
+                 errors have been reported.  The advisability of ever
+                 turning off UDP checksumming is very controversial.
+
+            IMPLEMENTATION:
+                 There is a common implementation error in UDP
+                 checksums.  Unlike the TCP checksum, the UDP checksum
+                 is optional; the value zero is transmitted in the
+                 checksum field of a UDP header to indicate the absence
+                 of a checksum.  If the transmitter really calculates a
+                 UDP checksum of zero, it must transmit the checksum as
+                 all 1's (65535).  No special action is required at the
+                 receiver, since zero and 65535 are equivalent in 1's
+                 complement arithmetic.
+
+         4.1.3.5  UDP Multihoming
+
+            When a UDP datagram is received, its specific-destination
+            address MUST be passed up to the application layer.
+
+            An application program MUST be able to specify the IP source
+            address to be used for sending a UDP datagram or to leave it
+            unspecified (in which case the networking software will
+            choose an appropriate source address).  There SHOULD be a
+            way to communicate the chosen source address up to the
+            application layer (e.g, so that the application can later
+            receive a reply datagram only from the corresponding
+            interface).
+
+            DISCUSSION:
+                 A request/response application that uses UDP should use
+                 a source address for the response that is the same as
+                 the specific destination address of the request.  See
+                 the "General Issues" section of [INTRO:1].
+
+         4.1.3.6  Invalid Addresses
+
+            A UDP datagram received with an invalid IP source address
+            (e.g., a broadcast or multicast address) must be discarded
+            by UDP or by the IP layer (see Section 3.2.1.3).
+
+            When a host sends a UDP datagram, the source address MUST be
+            (one of) the IP address(es) of the host.
+
+      4.1.4  UDP/APPLICATION LAYER INTERFACE
+
+         The application interface to UDP MUST provide the full services
+         of the IP/transport interface described in Section 3.4 of this
+
+
+
+Internet Engineering Task Force                                [Page 79]
+
+
+
+
+RFC1122                  TRANSPORT LAYER -- UDP             October 1989
+
+
+         document.  Thus, an application using UDP needs the functions
+         of the GET_SRCADDR(), GET_MAXSIZES(), ADVISE_DELIVPROB(), and
+         RECV_ICMP() calls described in Section 3.4.  For example,
+         GET_MAXSIZES() can be used to learn the effective maximum UDP
+         maximum datagram size for a particular {interface,remote
+         host,TOS} triplet.
+
+         An application-layer program MUST be able to set the TTL and
+         TOS values as well as IP options for sending a UDP datagram,
+         and these values must be passed transparently to the IP layer.
+         UDP MAY pass the received TOS up to the application layer.
+
+      4.1.5  UDP REQUIREMENTS SUMMARY
+
+
+                                                 |        | | | |S| |
+                                                 |        | | | |H| |F
+                                                 |        | | | |O|M|o
+                                                 |        | |S| |U|U|o
+                                                 |        | |H| |L|S|t
+                                                 |        |M|O| |D|T|n
+                                                 |        |U|U|M| | |o
+                                                 |        |S|L|A|N|N|t
+                                                 |        |T|D|Y|O|O|t
+FEATURE                                          |SECTION | | | |T|T|e
+-------------------------------------------------|--------|-|-|-|-|-|--
+                                                 |        | | | | | |
+    UDP                                          |        | | | | | |
+-------------------------------------------------|--------|-|-|-|-|-|--
+                                                 |        | | | | | |
+UDP send Port Unreachable                        |4.1.3.1 | |x| | | |
+                                                 |        | | | | | |
+IP Options in UDP                                |        | | | | | |
+ - Pass rcv'd IP options to applic layer         |4.1.3.2 |x| | | | |
+ - Applic layer can specify IP options in Send   |4.1.3.2 |x| | | | |
+ - UDP passes IP options down to IP layer        |4.1.3.2 |x| | | | |
+                                                 |        | | | | | |
+Pass ICMP msgs up to applic layer                |4.1.3.3 |x| | | | |
+                                                 |        | | | | | |
+UDP checksums:                                   |        | | | | | |
+ - Able to generate/check checksum               |4.1.3.4 |x| | | | |
+ - Silently discard bad checksum                 |4.1.3.4 |x| | | | |
+ - Sender Option to not generate checksum        |4.1.3.4 | | |x| | |
+   - Default is to checksum                      |4.1.3.4 |x| | | | |
+ - Receiver Option to require checksum           |4.1.3.4 | | |x| | |
+                                                 |        | | | | | |
+UDP Multihoming                                  |        | | | | | |
+ - Pass spec-dest addr to application            |4.1.3.5 |x| | | | |
+
+
+
+Internet Engineering Task Force                                [Page 80]
+
+
+
+
+RFC1122                  TRANSPORT LAYER -- UDP             October 1989
+
+
+ - Applic layer can specify Local IP addr        |4.1.3.5 |x| | | | |
+ - Applic layer specify wild Local IP addr       |4.1.3.5 |x| | | | |
+ - Applic layer notified of Local IP addr used   |4.1.3.5 | |x| | | |
+                                                 |        | | | | | |
+Bad IP src addr silently discarded by UDP/IP     |4.1.3.6 |x| | | | |
+Only send valid IP source address                |4.1.3.6 |x| | | | |
+UDP Application Interface Services               |        | | | | | |
+Full IP interface of 3.4 for application         |4.1.4   |x| | | | |
+ - Able to spec TTL, TOS, IP opts when send dg   |4.1.4   |x| | | | |
+ - Pass received TOS up to applic layer          |4.1.4   | | |x| | |
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Internet Engineering Task Force                                [Page 81]
+
+
+
+
+RFC1122                  TRANSPORT LAYER -- TCP             October 1989
+
+
+   4.2  TRANSMISSION CONTROL PROTOCOL -- TCP
+
+      4.2.1  INTRODUCTION
+
+         The Transmission Control Protocol TCP [TCP:1] is the primary
+         virtual-circuit transport protocol for the Internet suite.  TCP
+         provides reliable, in-sequence delivery of a full-duplex stream
+         of octets (8-bit bytes).  TCP is used by those applications
+         needing reliable, connection-oriented transport service, e.g.,
+         mail (SMTP), file transfer (FTP), and virtual terminal service
+         (Telnet); requirements for these application-layer protocols
+         are described in [INTRO:1].
+
+      4.2.2  PROTOCOL WALK-THROUGH
+
+         4.2.2.1  Well-Known Ports: RFC-793 Section 2.7
+
+            DISCUSSION:
+                 TCP reserves port numbers in the range 0-255 for
+                 "well-known" ports, used to access services that are
+                 standardized across the Internet.  The remainder of the
+                 port space can be freely allocated to application
+                 processes.  Current well-known port definitions are
+                 listed in the RFC entitled "Assigned Numbers"
+                 [INTRO:6].  A prerequisite for defining a new well-
+                 known port is an RFC documenting the proposed service
+                 in enough detail to allow new implementations.
+
+                 Some systems extend this notion by adding a third
+                 subdivision of the TCP port space: reserved ports,
+                 which are generally used for operating-system-specific
+                 services.  For example, reserved ports might fall
+                 between 256 and some system-dependent upper limit.
+                 Some systems further choose to protect well-known and
+                 reserved ports by permitting only privileged users to
+                 open TCP connections with those port values.  This is
+                 perfectly reasonable as long as the host does not
+                 assume that all hosts protect their low-numbered ports
+                 in this manner.
+
+         4.2.2.2  Use of Push: RFC-793 Section 2.8
+
+            When an application issues a series of SEND calls without
+            setting the PUSH flag, the TCP MAY aggregate the data
+            internally without sending it.  Similarly, when a series of
+            segments is received without the PSH bit, a TCP MAY queue
+            the data internally without passing it to the receiving
+            application.
+
+
+
+Internet Engineering Task Force                                [Page 82]
+
+
+
+
+RFC1122                  TRANSPORT LAYER -- TCP             October 1989
+
+
+            The PSH bit is not a record marker and is independent of
+            segment boundaries.  The transmitter SHOULD collapse
+            successive PSH bits when it packetizes data, to send the
+            largest possible segment.
+
+            A TCP MAY implement PUSH flags on SEND calls.  If PUSH flags
+            are not implemented, then the sending TCP: (1) must not
+            buffer data indefinitely, and (2) MUST set the PSH bit in
+            the last buffered segment (i.e., when there is no more
+            queued data to be sent).
+
+            The discussion in RFC-793 on pages 48, 50, and 74
+            erroneously implies that a received PSH flag must be passed
+            to the application layer.  Passing a received PSH flag to
+            the application layer is now OPTIONAL.
+
+            An application program is logically required to set the PUSH
+            flag in a SEND call whenever it needs to force delivery of
+            the data to avoid a communication deadlock.  However, a TCP
+            SHOULD send a maximum-sized segment whenever possible, to
+            improve performance (see Section 4.2.3.4).
+
+            DISCUSSION:
+                 When the PUSH flag is not implemented on SEND calls,
+                 i.e., when the application/TCP interface uses a pure
+                 streaming model, responsibility for aggregating any
+                 tiny data fragments to form reasonable sized segments
+                 is partially borne by the application layer.
+
+                 Generally, an interactive application protocol must set
+                 the PUSH flag at least in the last SEND call in each
+                 command or response sequence.  A bulk transfer protocol
+                 like FTP should set the PUSH flag on the last segment
+                 of a file or when necessary to prevent buffer deadlock.
+
+                 At the receiver, the PSH bit forces buffered data to be
+                 delivered to the application (even if less than a full
+                 buffer has been received). Conversely, the lack of a
+                 PSH bit can be used to avoid unnecessary wakeup calls
+                 to the application process; this can be an important
+                 performance optimization for large timesharing hosts.
+                 Passing the PSH bit to the receiving application allows
+                 an analogous optimization within the application.
+
+         4.2.2.3  Window Size: RFC-793 Section 3.1
+
+            The window size MUST be treated as an unsigned number, or
+            else large window sizes will appear like negative windows
+
+
+
+Internet Engineering Task Force                                [Page 83]
+
+
+
+
+RFC1122                  TRANSPORT LAYER -- TCP             October 1989
+
+
+            and TCP will not work.  It is RECOMMENDED that
+            implementations reserve 32-bit fields for the send and
+            receive window sizes in the connection record and do all
+            window computations with 32 bits.
+
+            DISCUSSION:
+                 It is known that the window field in the TCP header is
+                 too small for high-speed, long-delay paths.
+                 Experimental TCP options have been defined to extend
+                 the window size; see for example [TCP:11].  In
+                 anticipation of the adoption of such an extension, TCP
+                 implementors should treat windows as 32 bits.
+
+         4.2.2.4  Urgent Pointer: RFC-793 Section 3.1
+
+            The second sentence is in error: the urgent pointer points
+            to the sequence number of the LAST octet (not LAST+1) in a
+            sequence of urgent data.  The description on page 56 (last
+            sentence) is correct.
+
+            A TCP MUST support a sequence of urgent data of any length.
+
+            A TCP MUST inform the application layer asynchronously
+            whenever it receives an Urgent pointer and there was
+            previously no pending urgent data, or whenever the Urgent
+            pointer advances in the data stream.  There MUST be a way
+            for the application to learn how much urgent data remains to
+            be read from the connection, or at least to determine
+            whether or not more urgent data remains to be read.
+
+            DISCUSSION:
+                 Although the Urgent mechanism may be used for any
+                 application, it is normally used to send "interrupt"-
+                 type commands to a Telnet program (see "Using Telnet
+                 Synch Sequence" section in [INTRO:1]).
+
+                 The asynchronous or "out-of-band" notification will
+                 allow the application to go into "urgent mode", reading
+                 data from the TCP connection.  This allows control
+                 commands to be sent to an application whose normal
+                 input buffers are full of unprocessed data.
+
+            IMPLEMENTATION:
+                 The generic ERROR-REPORT() upcall described in Section
+                 4.2.4.1 is a possible mechanism for informing the
+                 application of the arrival of urgent data.
+
+
+
+
+
+Internet Engineering Task Force                                [Page 84]
+
+
+
+
+RFC1122                  TRANSPORT LAYER -- TCP             October 1989
+
+
+         4.2.2.5  TCP Options: RFC-793 Section 3.1
+
+            A TCP MUST be able to receive a TCP option in any segment.
+            A TCP MUST ignore without error any TCP option it does not
+            implement, assuming that the option has a length field (all
+            TCP options defined in the future will have length fields).
+            TCP MUST be prepared to handle an illegal option length
+            (e.g., zero) without crashing; a suggested procedure is to
+            reset the connection and log the reason.
+
+         4.2.2.6  Maximum Segment Size Option: RFC-793 Section 3.1
+
+            TCP MUST implement both sending and receiving the Maximum
+            Segment Size option [TCP:4].
+
+            TCP SHOULD send an MSS (Maximum Segment Size) option in
+            every SYN segment when its receive MSS differs from the
+            default 536, and MAY send it always.
+
+            If an MSS option is not received at connection setup, TCP
+            MUST assume a default send MSS of 536 (576-40) [TCP:4].
+
+            The maximum size of a segment that TCP really sends, the
+            "effective send MSS," MUST be the smaller of the send MSS
+            (which reflects the available reassembly buffer size at the
+            remote host) and the largest size permitted by the IP layer:
+
+               Eff.snd.MSS =
+
+                  min(SendMSS+20, MMS_S) - TCPhdrsize - IPoptionsize
+
+            where:
+
+            *    SendMSS is the MSS value received from the remote host,
+                 or the default 536 if no MSS option is received.
+
+            *    MMS_S is the maximum size for a transport-layer message
+                 that TCP may send.
+
+            *    TCPhdrsize is the size of the TCP header; this is
+                 normally 20, but may be larger if TCP options are to be
+                 sent.
+
+            *    IPoptionsize is the size of any IP options that TCP
+                 will pass to the IP layer with the current message.
+
+
+            The MSS value to be sent in an MSS option must be less than
+
+
+
+Internet Engineering Task Force                                [Page 85]
+
+
+
+
+RFC1122                  TRANSPORT LAYER -- TCP             October 1989
+
+
+            or equal to:
+
+               MMS_R - 20
+
+            where MMS_R is the maximum size for a transport-layer
+            message that can be received (and reassembled).  TCP obtains
+            MMS_R and MMS_S from the IP layer; see the generic call
+            GET_MAXSIZES in Section 3.4.
+
+            DISCUSSION:
+                 The choice of TCP segment size has a strong effect on
+                 performance.  Larger segments increase throughput by
+                 amortizing header size and per-datagram processing
+                 overhead over more data bytes; however, if the packet
+                 is so large that it causes IP fragmentation, efficiency
+                 drops sharply if any fragments are lost [IP:9].
+
+                 Some TCP implementations send an MSS option only if the
+                 destination host is on a non-connected network.
+                 However, in general the TCP layer may not have the
+                 appropriate information to make this decision, so it is
+                 preferable to leave to the IP layer the task of
+                 determining a suitable MTU for the Internet path.  We
+                 therefore recommend that TCP always send the option (if
+                 not 536) and that the IP layer determine MMS_R as
+                 specified in 3.3.3 and 3.4.  A proposed IP-layer
+                 mechanism to measure the MTU would then modify the IP
+                 layer without changing TCP.
+
+         4.2.2.7  TCP Checksum: RFC-793 Section 3.1
+
+            Unlike the UDP checksum (see Section 4.1.3.4), the TCP
+            checksum is never optional.  The sender MUST generate it and
+            the receiver MUST check it.
+
+         4.2.2.8  TCP Connection State Diagram: RFC-793 Section 3.2,
+            page 23
+
+            There are several problems with this diagram:
+
+            (a)  The arrow from SYN-SENT to SYN-RCVD should be labeled
+                 with "snd SYN,ACK", to agree with the text on page 68
+                 and with Figure 8.
+
+            (b)  There could be an arrow from SYN-RCVD state to LISTEN
+                 state, conditioned on receiving a RST after a passive
+                 open (see text page 70).
+
+
+
+
+Internet Engineering Task Force                                [Page 86]
+
+
+
+
+RFC1122                  TRANSPORT LAYER -- TCP             October 1989
+
+
+            (c)  It is possible to go directly from FIN-WAIT-1 to the
+                 TIME-WAIT state (see page 75 of the spec).
+
+
+         4.2.2.9  Initial Sequence Number Selection: RFC-793 Section
+            3.3, page 27
+
+            A TCP MUST use the specified clock-driven selection of
+            initial sequence numbers.
+
+         4.2.2.10  Simultaneous Open Attempts: RFC-793 Section 3.4, page
+            32
+
+            There is an error in Figure 8: the packet on line 7 should
+            be identical to the packet on line 5.
+
+            A TCP MUST support simultaneous open attempts.
+
+            DISCUSSION:
+                 It sometimes surprises implementors that if two
+                 applications attempt to simultaneously connect to each
+                 other, only one connection is generated instead of two.
+                 This was an intentional design decision; don't try to
+                 "fix" it.
+
+         4.2.2.11  Recovery from Old Duplicate SYN: RFC-793 Section 3.4,
+            page 33
+
+            Note that a TCP implementation MUST keep track of whether a
+            connection has reached SYN_RCVD state as the result of a
+            passive OPEN or an active OPEN.
+
+         4.2.2.12  RST Segment: RFC-793 Section 3.4
+
+            A TCP SHOULD allow a received RST segment to include data.
+
+            DISCUSSION
+                 It has been suggested that a RST segment could contain
+                 ASCII text that encoded and explained the cause of the
+                 RST.  No standard has yet been established for such
+                 data.
+
+         4.2.2.13  Closing a Connection: RFC-793 Section 3.5
+
+            A TCP connection may terminate in two ways: (1) the normal
+            TCP close sequence using a FIN handshake, and (2) an "abort"
+            in which one or more RST segments are sent and the
+            connection state is immediately discarded.  If a TCP
+
+
+
+Internet Engineering Task Force                                [Page 87]
+
+
+
+
+RFC1122                  TRANSPORT LAYER -- TCP             October 1989
+
+
+            connection is closed by the remote site, the local
+            application MUST be informed whether it closed normally or
+            was aborted.
+
+            The normal TCP close sequence delivers buffered data
+            reliably in both directions.  Since the two directions of a
+            TCP connection are closed independently, it is possible for
+            a connection to be "half closed," i.e., closed in only one
+            direction, and a host is permitted to continue sending data
+            in the open direction on a half-closed connection.
+
+            A host MAY implement a "half-duplex" TCP close sequence, so
+            that an application that has called CLOSE cannot continue to
+            read data from the connection.  If such a host issues a
+            CLOSE call while received data is still pending in TCP, or
+            if new data is received after CLOSE is called, its TCP
+            SHOULD send a RST to show that data was lost.
+
+            When a connection is closed actively, it MUST linger in
+            TIME-WAIT state for a time 2xMSL (Maximum Segment Lifetime).
+            However, it MAY accept a new SYN from the remote TCP to
+            reopen the connection directly from TIME-WAIT state, if it:
+
+            (1)  assigns its initial sequence number for the new
+                 connection to be larger than the largest sequence
+                 number it used on the previous connection incarnation,
+                 and
+
+            (2)  returns to TIME-WAIT state if the SYN turns out to be
+                 an old duplicate.
+
+
+            DISCUSSION:
+                 TCP's full-duplex data-preserving close is a feature
+                 that is not included in the analogous ISO transport
+                 protocol TP4.
+
+                 Some systems have not implemented half-closed
+                 connections, presumably because they do not fit into
+                 the I/O model of their particular operating system.  On
+                 these systems, once an application has called CLOSE, it
+                 can no longer read input data from the connection; this
+                 is referred to as a "half-duplex" TCP close sequence.
+
+                 The graceful close algorithm of TCP requires that the
+                 connection state remain defined on (at least)  one end
+                 of the connection, for a timeout period of 2xMSL, i.e.,
+                 4 minutes.  During this period, the (remote socket,
+
+
+
+Internet Engineering Task Force                                [Page 88]
+
+
+
+
+RFC1122                  TRANSPORT LAYER -- TCP             October 1989
+
+
+                 local socket) pair that defines the connection is busy
+                 and cannot be reused.  To shorten the time that a given
+                 port pair is tied up, some TCPs allow a new SYN to be
+                 accepted in TIME-WAIT state.
+
+         4.2.2.14  Data Communication: RFC-793 Section 3.7, page 40
+
+            Since RFC-793 was written, there has been extensive work on
+            TCP algorithms to achieve efficient data communication.
+            Later sections of the present document describe required and
+            recommended TCP algorithms to determine when to send data
+            (Section 4.2.3.4), when to send an acknowledgment (Section
+            4.2.3.2), and when to update the window (Section 4.2.3.3).
+
+            DISCUSSION:
+                 One important performance issue is "Silly Window
+                 Syndrome" or "SWS" [TCP:5], a stable pattern of small
+                 incremental window movements resulting in extremely
+                 poor TCP performance.  Algorithms to avoid SWS are
+                 described below for both the sending side (Section
+                 4.2.3.4) and the receiving side (Section 4.2.3.3).
+
+                 In brief, SWS is caused by the receiver advancing the
+                 right window edge whenever it has any new buffer space
+                 available to receive data and by the sender using any
+                 incremental window, no matter how small, to send more
+                 data [TCP:5].  The result can be a stable pattern of
+                 sending tiny data segments, even though both sender and
+                 receiver have a large total buffer space for the
+                 connection.  SWS can only occur during the transmission
+                 of a large amount of data; if the connection goes
+                 quiescent, the problem will disappear.  It is caused by
+                 typical straightforward implementation of window
+                 management, but the sender and receiver algorithms
+                 given below will avoid it.
+
+                 Another important TCP performance issue is that some
+                 applications, especially remote login to character-at-
+                 a-time hosts, tend to send streams of one-octet data
+                 segments.  To avoid deadlocks, every TCP SEND call from
+                 such applications must be "pushed", either explicitly
+                 by the application or else implicitly by TCP.  The
+                 result may be a stream of TCP segments that contain one
+                 data octet each, which makes very inefficient use of
+                 the Internet and contributes to Internet congestion.
+                 The Nagle Algorithm described in Section 4.2.3.4
+                 provides a simple and effective solution to this
+                 problem.  It does have the effect of clumping
+
+
+
+Internet Engineering Task Force                                [Page 89]
+
+
+
+
+RFC1122                  TRANSPORT LAYER -- TCP             October 1989
+
+
+                 characters over Telnet connections; this may initially
+                 surprise users accustomed to single-character echo, but
+                 user acceptance has not been a problem.
+
+                 Note that the Nagle algorithm and the send SWS
+                 avoidance algorithm play complementary roles in
+                 improving performance.  The Nagle algorithm discourages
+                 sending tiny segments when the data to be sent
+                 increases in small increments, while the SWS avoidance
+                 algorithm discourages small segments resulting from the
+                 right window edge advancing in small increments.
+
+                 A careless implementation can send two or more
+                 acknowledgment segments per data segment received.  For
+                 example, suppose the receiver acknowledges every data
+                 segment immediately.  When the application program
+                 subsequently consumes the data and increases the
+                 available receive buffer space again, the receiver may
+                 send a second acknowledgment segment to update the
+                 window at the sender.  The extreme case occurs with
+                 single-character segments on TCP connections using the
+                 Telnet protocol for remote login service.  Some
+                 implementations have been observed in which each
+                 incoming 1-character segment generates three return
+                 segments: (1) the acknowledgment, (2) a one byte
+                 increase in the window, and (3) the echoed character,
+                 respectively.
+
+         4.2.2.15  Retransmission Timeout: RFC-793 Section 3.7, page 41
+
+            The algorithm suggested in RFC-793 for calculating the
+            retransmission timeout is now known to be inadequate; see
+            Section 4.2.3.1 below.
+
+            Recent work by Jacobson [TCP:7] on Internet congestion and
+            TCP retransmission stability has produced a transmission
+            algorithm combining "slow start" with "congestion
+            avoidance".  A TCP MUST implement this algorithm.
+
+            If a retransmitted packet is identical to the original
+            packet (which implies not only that the data boundaries have
+            not changed, but also that the window and acknowledgment
+            fields of the header have not changed), then the same IP
+            Identification field MAY be used (see Section 3.2.1.5).
+
+            IMPLEMENTATION:
+                 Some TCP implementors have chosen to "packetize" the
+                 data stream, i.e., to pick segment boundaries when
+
+
+
+Internet Engineering Task Force                                [Page 90]
+
+
+
+
+RFC1122                  TRANSPORT LAYER -- TCP             October 1989
+
+
+                 segments are originally sent and to queue these
+                 segments in a "retransmission queue" until they are
+                 acknowledged.  Another design (which may be simpler) is
+                 to defer packetizing until each time data is
+                 transmitted or retransmitted, so there will be no
+                 segment retransmission queue.
+
+                 In an implementation with a segment retransmission
+                 queue, TCP performance may be enhanced by repacketizing
+                 the segments awaiting acknowledgment when the first
+                 retransmission timeout occurs.  That is, the
+                 outstanding segments that fitted would be combined into
+                 one maximum-sized segment, with a new IP Identification
+                 value.  The TCP would then retain this combined segment
+                 in the retransmit queue until it was acknowledged.
+                 However, if the first two segments in the
+                 retransmission queue totalled more than one maximum-
+                 sized segment, the TCP would retransmit only the first
+                 segment using the original IP Identification field.
+
+         4.2.2.16  Managing the Window: RFC-793 Section 3.7, page 41
+
+            A TCP receiver SHOULD NOT shrink the window, i.e., move the
+            right window edge to the left.  However, a sending TCP MUST
+            be robust against window shrinking, which may cause the
+            "useable window" (see Section 4.2.3.4) to become negative.
+
+            If this happens, the sender SHOULD NOT send new data, but
+            SHOULD retransmit normally the old unacknowledged data
+            between SND.UNA and SND.UNA+SND.WND.  The sender MAY also
+            retransmit old data beyond SND.UNA+SND.WND, but SHOULD NOT
+            time out the connection if data beyond the right window edge
+            is not acknowledged.  If the window shrinks to zero, the TCP
+            MUST probe it in the standard way (see next Section).
+
+            DISCUSSION:
+                 Many TCP implementations become confused if the window
+                 shrinks from the right after data has been sent into a
+                 larger window.  Note that TCP has a heuristic to select
+                 the latest window update despite possible datagram
+                 reordering; as a result, it may ignore a window update
+                 with a smaller window than previously offered if
+                 neither the sequence number nor the acknowledgment
+                 number is increased.
+
+
+
+
+
+
+
+Internet Engineering Task Force                                [Page 91]
+
+
+
+
+RFC1122                  TRANSPORT LAYER -- TCP             October 1989
+
+
+         4.2.2.17  Probing Zero Windows: RFC-793 Section 3.7, page 42
+
+            Probing of zero (offered) windows MUST be supported.
+
+            A TCP MAY keep its offered receive window closed
+            indefinitely.  As long as the receiving TCP continues to
+            send acknowledgments in response to the probe segments, the
+            sending TCP MUST allow the connection to stay open.
+
+            DISCUSSION:
+                 It is extremely important to remember that ACK
+                 (acknowledgment) segments that contain no data are not
+                 reliably transmitted by TCP.  If zero window probing is
+                 not supported, a connection may hang forever when an
+                 ACK segment that re-opens the window is lost.
+
+                 The delay in opening a zero window generally occurs
+                 when the receiving application stops taking data from
+                 its TCP.  For example, consider a printer daemon
+                 application, stopped because the printer ran out of
+                 paper.
+
+            The transmitting host SHOULD send the first zero-window
+            probe when a zero window has existed for the retransmission
+            timeout period (see Section 4.2.2.15), and SHOULD increase
+            exponentially the interval between successive probes.
+
+            DISCUSSION:
+                 This procedure minimizes delay if the zero-window
+                 condition is due to a lost ACK segment containing a
+                 window-opening update.  Exponential backoff is
+                 recommended, possibly with some maximum interval not
+                 specified here.  This procedure is similar to that of
+                 the retransmission algorithm, and it may be possible to
+                 combine the two procedures in the implementation.
+
+         4.2.2.18  Passive OPEN Calls:  RFC-793 Section 3.8
+
+            Every passive OPEN call either creates a new connection
+            record in LISTEN state, or it returns an error; it MUST NOT
+            affect any previously created connection record.
+
+            A TCP that supports multiple concurrent users MUST provide
+            an OPEN call that will functionally allow an application to
+            LISTEN on a port while a connection block with the same
+            local port is in SYN-SENT or SYN-RECEIVED state.
+
+            DISCUSSION:
+
+
+
+Internet Engineering Task Force                                [Page 92]
+
+
+
+
+RFC1122                  TRANSPORT LAYER -- TCP             October 1989
+
+
+                 Some applications (e.g., SMTP servers) may need to
+                 handle multiple connection attempts at about the same
+                 time.  The probability of a connection attempt failing
+                 is reduced by giving the application some means of
+                 listening for a new connection at the same time that an
+                 earlier connection attempt is going through the three-
+                 way handshake.
+
+            IMPLEMENTATION:
+                 Acceptable implementations of concurrent opens may
+                 permit multiple passive OPEN calls, or they may allow
+                 "cloning" of LISTEN-state connections from a single
+                 passive OPEN call.
+
+         4.2.2.19  Time to Live: RFC-793 Section 3.9, page 52
+
+            RFC-793 specified that TCP was to request the IP layer to
+            send TCP segments with TTL = 60.  This is obsolete; the TTL
+            value used to send TCP segments MUST be configurable.  See
+            Section 3.2.1.7 for discussion.
+
+         4.2.2.20  Event Processing: RFC-793 Section 3.9
+
+            While it is not strictly required, a TCP SHOULD be capable
+            of queueing out-of-order TCP segments.  Change the "may" in
+            the last sentence of the first paragraph on page 70 to
+            "should".
+
+            DISCUSSION:
+                 Some small-host implementations have omitted segment
+                 queueing because of limited buffer space.  This
+                 omission may be expected to adversely affect TCP
+                 throughput, since loss of a single segment causes all
+                 later segments to appear to be "out of sequence".
+
+            In general, the processing of received segments MUST be
+            implemented to aggregate ACK segments whenever possible.
+            For example, if the TCP is processing a series of queued
+            segments, it MUST process them all before sending any ACK
+            segments.
+
+            Here are some detailed error corrections and notes on the
+            Event Processing section of RFC-793.
+
+            (a)  CLOSE Call, CLOSE-WAIT state, p. 61: enter LAST-ACK
+                 state, not CLOSING.
+
+            (b)  LISTEN state, check for SYN (pp. 65, 66): With a SYN
+
+
+
+Internet Engineering Task Force                                [Page 93]
+
+
+
+
+RFC1122                  TRANSPORT LAYER -- TCP             October 1989
+
+
+                 bit, if the security/compartment or the precedence is
+                 wrong for the segment, a reset is sent.  The wrong form
+                 of reset is shown in the text; it should be:
+
+                   <SEQ=0><ACK=SEG.SEQ+SEG.LEN><CTL=RST,ACK>
+
+
+            (c)  SYN-SENT state, Check for SYN, p. 68: When the
+                 connection enters ESTABLISHED state, the following
+                 variables must be set:
+                    SND.WND <- SEG.WND
+                    SND.WL1 <- SEG.SEQ
+                    SND.WL2 <- SEG.ACK
+
+
+            (d)  Check security and precedence, p. 71: The first heading
+                 "ESTABLISHED STATE" should really be a list of all
+                 states other than SYN-RECEIVED: ESTABLISHED, FIN-WAIT-
+                 1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, and
+                 TIME-WAIT.
+
+            (e)  Check SYN bit, p. 71:  "In SYN-RECEIVED state and if
+                 the connection was initiated with a passive OPEN, then
+                 return this connection to the LISTEN state and return.
+                 Otherwise...".
+
+            (f)  Check ACK field, SYN-RECEIVED state, p. 72: When the
+                 connection enters ESTABLISHED state, the variables
+                 listed in (c) must be set.
+
+            (g)  Check ACK field, ESTABLISHED state, p. 72: The ACK is a
+                 duplicate if SEG.ACK =< SND.UNA (the = was omitted).
+                 Similarly, the window should be updated if: SND.UNA =<
+                 SEG.ACK =< SND.NXT.
+
+            (h)  USER TIMEOUT, p. 77:
+
+                 It would be better to notify the application of the
+                 timeout rather than letting TCP force the connection
+                 closed.  However, see also Section 4.2.3.5.
+
+
+         4.2.2.21  Acknowledging Queued Segments: RFC-793 Section 3.9
+
+            A TCP MAY send an ACK segment acknowledging RCV.NXT when a
+            valid segment arrives that is in the window but not at the
+            left window edge.
+
+
+
+
+Internet Engineering Task Force                                [Page 94]
+
+
+
+
+RFC1122                  TRANSPORT LAYER -- TCP             October 1989
+
+
+            DISCUSSION:
+                 RFC-793 (see page 74) was ambiguous about whether or
+                 not an ACK segment should be sent when an out-of-order
+                 segment was received, i.e., when SEG.SEQ was unequal to
+                 RCV.NXT.
+
+                 One reason for ACKing out-of-order segments might be to
+                 support an experimental algorithm known as "fast
+                 retransmit".   With this algorithm, the sender uses the
+                 "redundant" ACK's to deduce that a segment has been
+                 lost before the retransmission timer has expired.  It
+                 counts the number of times an ACK has been received
+                 with the same value of SEG.ACK and with the same right
+                 window edge.  If more than a threshold number of such
+                 ACK's is received, then the segment containing the
+                 octets starting at SEG.ACK is assumed to have been lost
+                 and is retransmitted, without awaiting a timeout.  The
+                 threshold is chosen to compensate for the maximum
+                 likely segment reordering in the Internet.  There is
+                 not yet enough experience with the fast retransmit
+                 algorithm to determine how useful it is.
+
+      4.2.3  SPECIFIC ISSUES
+
+         4.2.3.1  Retransmission Timeout Calculation
+
+            A host TCP MUST implement Karn's algorithm and Jacobson's
+            algorithm for computing the retransmission timeout ("RTO").
+
+            o    Jacobson's algorithm for computing the smoothed round-
+                 trip ("RTT") time incorporates a simple measure of the
+                 variance [TCP:7].
+
+            o    Karn's algorithm for selecting RTT measurements ensures
+                 that ambiguous round-trip times will not corrupt the
+                 calculation of the smoothed round-trip time [TCP:6].
+
+            This implementation also MUST include "exponential backoff"
+            for successive RTO values for the same segment.
+            Retransmission of SYN segments SHOULD use the same algorithm
+            as data segments.
+
+            DISCUSSION:
+                 There were two known problems with the RTO calculations
+                 specified in RFC-793.  First, the accurate measurement
+                 of RTTs is difficult when there are retransmissions.
+                 Second, the algorithm to compute the smoothed round-
+                 trip time is inadequate [TCP:7], because it incorrectly
+
+
+
+Internet Engineering Task Force                                [Page 95]
+
+
+
+
+RFC1122                  TRANSPORT LAYER -- TCP             October 1989
+
+
+                 assumed that the variance in RTT values would be small
+                 and constant.  These problems were solved by Karn's and
+                 Jacobson's algorithm, respectively.
+
+                 The performance increase resulting from the use of
+                 these improvements varies from noticeable to dramatic.
+                 Jacobson's algorithm for incorporating the measured RTT
+                 variance is especially important on a low-speed link,
+                 where the natural variation of packet sizes causes a
+                 large variation in RTT.  One vendor found link
+                 utilization on a 9.6kb line went from 10% to 90% as a
+                 result of implementing Jacobson's variance algorithm in
+                 TCP.
+
+            The following values SHOULD be used to initialize the
+            estimation parameters for a new connection:
+
+            (a)  RTT = 0 seconds.
+
+            (b)  RTO = 3 seconds.  (The smoothed variance is to be
+                 initialized to the value that will result in this RTO).
+
+            The recommended upper and lower bounds on the RTO are known
+            to be inadequate on large internets.  The lower bound SHOULD
+            be measured in fractions of a second (to accommodate high
+            speed LANs) and the upper bound should be 2*MSL, i.e., 240
+            seconds.
+
+            DISCUSSION:
+                 Experience has shown that these initialization values
+                 are reasonable, and that in any case the Karn and
+                 Jacobson algorithms make TCP behavior reasonably
+                 insensitive to the initial parameter choices.
+
+         4.2.3.2  When to Send an ACK Segment
+
+            A host that is receiving a stream of TCP data segments can
+            increase efficiency in both the Internet and the hosts by
+            sending fewer than one ACK (acknowledgment) segment per data
+            segment received; this is known as a "delayed ACK" [TCP:5].
+
+            A TCP SHOULD implement a delayed ACK, but an ACK should not
+            be excessively delayed; in particular, the delay MUST be
+            less than 0.5 seconds, and in a stream of full-sized
+            segments there SHOULD be an ACK for at least every second
+            segment.
+
+            DISCUSSION:
+
+
+
+Internet Engineering Task Force                                [Page 96]
+
+
+
+
+RFC1122                  TRANSPORT LAYER -- TCP             October 1989
+
+
+                 A delayed ACK gives the application an opportunity to
+                 update the window and perhaps to send an immediate
+                 response.  In particular, in the case of character-mode
+                 remote login, a delayed ACK can reduce the number of
+                 segments sent by the server by a factor of 3 (ACK,
+                 window update, and echo character all combined in one
+                 segment).
+
+                 In addition, on some large multi-user hosts, a delayed
+                 ACK can substantially reduce protocol processing
+                 overhead by reducing the total number of packets to be
+                 processed [TCP:5].  However, excessive delays on ACK's
+                 can disturb the round-trip timing and packet "clocking"
+                 algorithms [TCP:7].
+
+         4.2.3.3  When to Send a Window Update
+
+            A TCP MUST include a SWS avoidance algorithm in the receiver
+            [TCP:5].
+
+            IMPLEMENTATION:
+                 The receiver's SWS avoidance algorithm determines when
+                 the right window edge may be advanced; this is
+                 customarily known as "updating the window".  This
+                 algorithm combines with the delayed ACK algorithm (see
+                 Section 4.2.3.2) to determine when an ACK segment
+                 containing the current window will really be sent to
+                 the receiver.  We use the notation of RFC-793; see
+                 Figures 4 and 5 in that document.
+
+                 The solution to receiver SWS is to avoid advancing the
+                 right window edge RCV.NXT+RCV.WND in small increments,
+                 even if data is received from the network in small
+                 segments.
+
+                 Suppose the total receive buffer space is RCV.BUFF.  At
+                 any given moment, RCV.USER octets of this total may be
+                 tied up with data that has been received and
+                 acknowledged but which the user process has not yet
+                 consumed.  When the connection is quiescent, RCV.WND =
+                 RCV.BUFF and RCV.USER = 0.
+
+                 Keeping the right window edge fixed as data arrives and
+                 is acknowledged requires that the receiver offer less
+                 than its full buffer space, i.e., the receiver must
+                 specify a RCV.WND that keeps RCV.NXT+RCV.WND constant
+                 as RCV.NXT increases.  Thus, the total buffer space
+                 RCV.BUFF is generally divided into three parts:
+
+
+
+Internet Engineering Task Force                                [Page 97]
+
+
+
+
+RFC1122                  TRANSPORT LAYER -- TCP             October 1989
+
+
+
+                 |<------- RCV.BUFF ---------------->|
+                      1             2            3
+             ----|---------|------------------|------|----
+                        RCV.NXT               ^
+                                           (Fixed)
+
+             1 - RCV.USER =  data received but not yet consumed;
+             2 - RCV.WND =   space advertised to sender;
+             3 - Reduction = space available but not yet
+                             advertised.
+
+
+                 The suggested SWS avoidance algorithm for the receiver
+                 is to keep RCV.NXT+RCV.WND fixed until the reduction
+                 satisfies:
+
+                      RCV.BUFF - RCV.USER - RCV.WND  >=
+
+                             min( Fr * RCV.BUFF, Eff.snd.MSS )
+
+                 where Fr is a fraction whose recommended value is 1/2,
+                 and Eff.snd.MSS is the effective send MSS for the
+                 connection (see Section 4.2.2.6).  When the inequality
+                 is satisfied, RCV.WND is set to RCV.BUFF-RCV.USER.
+
+                 Note that the general effect of this algorithm is to
+                 advance RCV.WND in increments of Eff.snd.MSS (for
+                 realistic receive buffers:  Eff.snd.MSS < RCV.BUFF/2).
+                 Note also that the receiver must use its own
+                 Eff.snd.MSS, assuming it is the same as the sender's.
+
+         4.2.3.4  When to Send Data
+
+            A TCP MUST include a SWS avoidance algorithm in the sender.
+
+            A TCP SHOULD implement the Nagle Algorithm [TCP:9] to
+            coalesce short segments.  However, there MUST be a way for
+            an application to disable the Nagle algorithm on an
+            individual connection.  In all cases, sending data is also
+            subject to the limitation imposed by the Slow Start
+            algorithm (Section 4.2.2.15).
+
+            DISCUSSION:
+                 The Nagle algorithm is generally as follows:
+
+                      If there is unacknowledged data (i.e., SND.NXT >
+                      SND.UNA), then the sending TCP buffers all user
+
+
+
+Internet Engineering Task Force                                [Page 98]
+
+
+
+
+RFC1122                  TRANSPORT LAYER -- TCP             October 1989
+
+
+                      data (regardless of the PSH bit), until the
+                      outstanding data has been acknowledged or until
+                      the TCP can send a full-sized segment (Eff.snd.MSS
+                      bytes; see Section 4.2.2.6).
+
+                 Some applications (e.g., real-time display window
+                 updates) require that the Nagle algorithm be turned
+                 off, so small data segments can be streamed out at the
+                 maximum rate.
+
+            IMPLEMENTATION:
+                 The sender's SWS avoidance algorithm is more difficult
+                 than the receivers's, because the sender does not know
+                 (directly) the receiver's total buffer space RCV.BUFF.
+                 An approach which has been found to work well is for
+                 the sender to calculate Max(SND.WND), the maximum send
+                 window it has seen so far on the connection, and to use
+                 this value as an estimate of RCV.BUFF.  Unfortunately,
+                 this can only be an estimate; the receiver may at any
+                 time reduce the size of RCV.BUFF.  To avoid a resulting
+                 deadlock, it is necessary to have a timeout to force
+                 transmission of data, overriding the SWS avoidance
+                 algorithm.  In practice, this timeout should seldom
+                 occur.
+
+                 The "useable window" [TCP:5] is:
+
+                      U = SND.UNA + SND.WND - SND.NXT
+
+                 i.e., the offered window less the amount of data sent
+                 but not acknowledged.  If D is the amount of data
+                 queued in the sending TCP but not yet sent, then the
+                 following set of rules is recommended.
+
+                 Send data:
+
+                 (1)  if a maximum-sized segment can be sent, i.e, if:
+
+                           min(D,U) >= Eff.snd.MSS;
+
+
+                 (2)  or if the data is pushed and all queued data can
+                      be sent now, i.e., if:
+
+                          [SND.NXT = SND.UNA and] PUSHED and D <= U
+
+                      (the bracketed condition is imposed by the Nagle
+                      algorithm);
+
+
+
+Internet Engineering Task Force                                [Page 99]
+
+
+
+
+RFC1122                  TRANSPORT LAYER -- TCP             October 1989
+
+
+                 (3)  or if at least a fraction Fs of the maximum window
+                      can be sent, i.e., if:
+
+                          [SND.NXT = SND.UNA and]
+
+                                  min(D.U) >= Fs * Max(SND.WND);
+
+
+                 (4)  or if data is PUSHed and the override timeout
+                      occurs.
+
+                 Here Fs is a fraction whose recommended value is 1/2.
+                 The override timeout should be in the range 0.1 - 1.0
+                 seconds.  It may be convenient to combine this timer
+                 with the timer used to probe zero windows (Section
+                 4.2.2.17).
+
+                 Finally, note that the SWS avoidance algorithm just
+                 specified is to be used instead of the sender-side
+                 algorithm contained in [TCP:5].
+
+         4.2.3.5  TCP Connection Failures
+
+            Excessive retransmission of the same segment by TCP
+            indicates some failure of the remote host or the Internet
+            path.  This failure may be of short or long duration.  The
+            following procedure MUST be used to handle excessive
+            retransmissions of data segments [IP:11]:
+
+            (a)  There are two thresholds R1 and R2 measuring the amount
+                 of retransmission that has occurred for the same
+                 segment.  R1 and R2 might be measured in time units or
+                 as a count of retransmissions.
+
+            (b)  When the number of transmissions of the same segment
+                 reaches or exceeds threshold R1, pass negative advice
+                 (see Section 3.3.1.4) to the IP layer, to trigger
+                 dead-gateway diagnosis.
+
+            (c)  When the number of transmissions of the same segment
+                 reaches a threshold R2 greater than R1, close the
+                 connection.
+
+            (d)  An application MUST be able to set the value for R2 for
+                 a particular connection.  For example, an interactive
+                 application might set R2 to "infinity," giving the user
+                 control over when to disconnect.
+
+
+
+
+Internet Engineering Task Force                               [Page 100]
+
+
+
+
+RFC1122                  TRANSPORT LAYER -- TCP             October 1989
+
+
+            (d)  TCP SHOULD inform the application of the delivery
+                 problem (unless such information has been disabled by
+                 the application; see Section 4.2.4.1), when R1 is
+                 reached and before R2.  This will allow a remote login
+                 (User Telnet) application program to inform the user,
+                 for example.
+
+            The value of R1 SHOULD correspond to at least 3
+            retransmissions, at the current RTO.  The value of R2 SHOULD
+            correspond to at least 100 seconds.
+
+            An attempt to open a TCP connection could fail with
+            excessive retransmissions of the SYN segment or by receipt
+            of a RST segment or an ICMP Port Unreachable.  SYN
+            retransmissions MUST be handled in the general way just
+            described for data retransmissions, including notification
+            of the application layer.
+
+            However, the values of R1 and R2 may be different for SYN
+            and data segments.  In particular, R2 for a SYN segment MUST
+            be set large enough to provide retransmission of the segment
+            for at least 3 minutes.  The application can close the
+            connection (i.e., give up on the open attempt) sooner, of
+            course.
+
+            DISCUSSION:
+                 Some Internet paths have significant setup times, and
+                 the number of such paths is likely to increase in the
+                 future.
+
+         4.2.3.6  TCP Keep-Alives
+
+            Implementors MAY include "keep-alives" in their TCP
+            implementations, although this practice is not universally
+            accepted.  If keep-alives are included, the application MUST
+            be able to turn them on or off for each TCP connection, and
+            they MUST default to off.
+
+            Keep-alive packets MUST only be sent when no data or
+            acknowledgement packets have been received for the
+            connection within an interval.  This interval MUST be
+            configurable and MUST default to no less than two hours.
+
+            It is extremely important to remember that ACK segments that
+            contain no data are not reliably transmitted by TCP.
+            Consequently, if a keep-alive mechanism is implemented it
+            MUST NOT interpret failure to respond to any specific probe
+            as a dead connection.
+
+
+
+Internet Engineering Task Force                               [Page 101]
+
+
+
+
+RFC1122                  TRANSPORT LAYER -- TCP             October 1989
+
+
+            An implementation SHOULD send a keep-alive segment with no
+            data; however, it MAY be configurable to send a keep-alive
+            segment containing one garbage octet, for compatibility with
+            erroneous TCP implementations.
+
+            DISCUSSION:
+                 A "keep-alive" mechanism periodically probes the other
+                 end of a connection when the connection is otherwise
+                 idle, even when there is no data to be sent.  The TCP
+                 specification does not include a keep-alive mechanism
+                 because it could:  (1) cause perfectly good connections
+                 to break during transient Internet failures; (2)
+                 consume unnecessary bandwidth ("if no one is using the
+                 connection, who cares if it is still good?"); and (3)
+                 cost money for an Internet path that charges for
+                 packets.
+
+                 Some TCP implementations, however, have included a
+                 keep-alive mechanism.  To confirm that an idle
+                 connection is still active, these implementations send
+                 a probe segment designed to elicit a response from the
+                 peer TCP.  Such a segment generally contains SEG.SEQ =
+                 SND.NXT-1 and may or may not contain one garbage octet
+                 of data.  Note that on a quiet connection SND.NXT =
+                 RCV.NXT, so that this SEG.SEQ will be outside the
+                 window.  Therefore, the probe causes the receiver to
+                 return an acknowledgment segment, confirming that the
+                 connection is still live.  If the peer has dropped the
+                 connection due to a network partition or a crash, it
+                 will respond with a RST instead of an acknowledgment
+                 segment.
+
+                 Unfortunately, some misbehaved TCP implementations fail
+                 to respond to a segment with SEG.SEQ = SND.NXT-1 unless
+                 the segment contains data.  Alternatively, an
+                 implementation could determine whether a peer responded
+                 correctly to keep-alive packets with no garbage data
+                 octet.
+
+                 A TCP keep-alive mechanism should only be invoked in
+                 server applications that might otherwise hang
+                 indefinitely and consume resources unnecessarily if a
+                 client crashes or aborts a connection during a network
+                 failure.
+
+
+
+
+
+
+
+Internet Engineering Task Force                               [Page 102]
+
+
+
+
+RFC1122                  TRANSPORT LAYER -- TCP             October 1989
+
+
+         4.2.3.7  TCP Multihoming
+
+            If an application on a multihomed host does not specify the
+            local IP address when actively opening a TCP connection,
+            then the TCP MUST ask the IP layer to select a local IP
+            address before sending the (first) SYN.  See the function
+            GET_SRCADDR() in Section 3.4.
+
+            At all other times, a previous segment has either been sent
+            or received on this connection, and TCP MUST use the same
+            local address is used that was used in those previous
+            segments.
+
+         4.2.3.8  IP Options
+
+            When received options are passed up to TCP from the IP
+            layer, TCP MUST ignore options that it does not understand.
+
+            A TCP MAY support the Time Stamp and Record Route options.
+
+            An application MUST be able to specify a source route when
+            it actively opens a TCP connection, and this MUST take
+            precedence over a source route received in a datagram.
+
+            When a TCP connection is OPENed passively and a packet
+            arrives with a completed IP Source Route option (containing
+            a return route), TCP MUST save the return route and use it
+            for all segments sent on this connection.  If a different
+            source route arrives in a later segment, the later
+            definition SHOULD override the earlier one.
+
+         4.2.3.9  ICMP Messages
+
+            TCP MUST act on an ICMP error message passed up from the IP
+            layer, directing it to the connection that created the
+            error.  The necessary demultiplexing information can be
+            found in the IP header contained within the ICMP message.
+
+            o    Source Quench
+
+                 TCP MUST react to a Source Quench by slowing
+                 transmission on the connection.  The RECOMMENDED
+                 procedure is for a Source Quench to trigger a "slow
+                 start," as if a retransmission timeout had occurred.
+
+            o    Destination Unreachable -- codes 0, 1, 5
+
+                 Since these Unreachable messages indicate soft error
+
+
+
+Internet Engineering Task Force                               [Page 103]
+
+
+
+
+RFC1122                  TRANSPORT LAYER -- TCP             October 1989
+
+
+                 conditions, TCP MUST NOT abort the connection, and it
+                 SHOULD make the information available to the
+                 application.
+
+                 DISCUSSION:
+                      TCP could report the soft error condition directly
+                      to the application layer with an upcall to the
+                      ERROR_REPORT routine, or it could merely note the
+                      message and report it to the application only when
+                      and if the TCP connection times out.
+
+            o    Destination Unreachable -- codes 2-4
+
+                 These are hard error conditions, so TCP SHOULD abort
+                 the connection.
+
+            o    Time Exceeded -- codes 0, 1
+
+                 This should be handled the same way as Destination
+                 Unreachable codes 0, 1, 5 (see above).
+
+            o    Parameter Problem
+
+                 This should be handled the same way as Destination
+                 Unreachable codes 0, 1, 5 (see above).
+
+
+         4.2.3.10  Remote Address Validation
+
+            A TCP implementation MUST reject as an error a local OPEN
+            call for an invalid remote IP address (e.g., a broadcast or
+            multicast address).
+
+            An incoming SYN with an invalid source address must be
+            ignored either by TCP or by the IP layer (see Section
+            3.2.1.3).
+
+            A TCP implementation MUST silently discard an incoming SYN
+            segment that is addressed to a broadcast or multicast
+            address.
+
+         4.2.3.11  TCP Traffic Patterns
+
+            IMPLEMENTATION:
+                 The TCP protocol specification [TCP:1] gives the
+                 implementor much freedom in designing the algorithms
+                 that control the message flow over the connection --
+                 packetizing, managing the window, sending
+
+
+
+Internet Engineering Task Force                               [Page 104]
+
+
+
+
+RFC1122                  TRANSPORT LAYER -- TCP             October 1989
+
+
+                 acknowledgments, etc.  These design decisions are
+                 difficult because a TCP must adapt to a wide range of
+                 traffic patterns.  Experience has shown that a TCP
+                 implementor needs to verify the design on two extreme
+                 traffic patterns:
+
+                 o    Single-character Segments
+
+                      Even if the sender is using the Nagle Algorithm,
+                      when a TCP connection carries remote login traffic
+                      across a low-delay LAN the receiver will generally
+                      get a stream of single-character segments.  If
+                      remote terminal echo mode is in effect, the
+                      receiver's system will generally echo each
+                      character as it is received.
+
+                 o    Bulk Transfer
+
+                      When TCP is used for bulk transfer, the data
+                      stream should be made up (almost) entirely of
+                      segments of the size of the effective MSS.
+                      Although TCP uses a sequence number space with
+                      byte (octet) granularity, in bulk-transfer mode
+                      its operation should be as if TCP used a sequence
+                      space that counted only segments.
+
+                 Experience has furthermore shown that a single TCP can
+                 effectively and efficiently handle these two extremes.
+
+                 The most important tool for verifying a new TCP
+                 implementation is a packet trace program.  There is a
+                 large volume of experience showing the importance of
+                 tracing a variety of traffic patterns with other TCP
+                 implementations and studying the results carefully.
+
+
+         4.2.3.12  Efficiency
+
+            IMPLEMENTATION:
+                 Extensive experience has led to the following
+                 suggestions for efficient implementation of TCP:
+
+                 (a)  Don't Copy Data
+
+                      In bulk data transfer, the primary CPU-intensive
+                      tasks are copying data from one place to another
+                      and checksumming the data.  It is vital to
+                      minimize the number of copies of TCP data.  Since
+
+
+
+Internet Engineering Task Force                               [Page 105]
+
+
+
+
+RFC1122                  TRANSPORT LAYER -- TCP             October 1989
+
+
+                      the ultimate speed limitation may be fetching data
+                      across the memory bus, it may be useful to combine
+                      the copy with checksumming, doing both with a
+                      single memory fetch.
+
+                 (b)  Hand-Craft the Checksum Routine
+
+                      A good TCP checksumming routine is typically two
+                      to five times faster than a simple and direct
+                      implementation of the definition.  Great care and
+                      clever coding are often required and advisable to
+                      make the checksumming code "blazing fast".  See
+                      [TCP:10].
+
+                 (c)  Code for the Common Case
+
+                      TCP protocol processing can be complicated, but
+                      for most segments there are only a few simple
+                      decisions to be made.  Per-segment processing will
+                      be greatly speeded up by coding the main line to
+                      minimize the number of decisions in the most
+                      common case.
+
+
+      4.2.4  TCP/APPLICATION LAYER INTERFACE
+
+         4.2.4.1  Asynchronous Reports
+
+            There MUST be a mechanism for reporting soft TCP error
+            conditions to the application.  Generically, we assume this
+            takes the form of an application-supplied ERROR_REPORT
+            routine that may be upcalled [INTRO:7] asynchronously from
+            the transport layer:
+
+               ERROR_REPORT(local connection name, reason, subreason)
+
+            The precise encoding of the reason and subreason parameters
+            is not specified here.  However, the conditions that are
+            reported asynchronously to the application MUST include:
+
+            *    ICMP error message arrived (see 4.2.3.9)
+
+            *    Excessive retransmissions (see 4.2.3.5)
+
+            *    Urgent pointer advance (see 4.2.2.4).
+
+            However, an application program that does not want to
+            receive such ERROR_REPORT calls SHOULD be able to
+
+
+
+Internet Engineering Task Force                               [Page 106]
+
+
+
+
+RFC1122                  TRANSPORT LAYER -- TCP             October 1989
+
+
+            effectively disable these calls.
+
+            DISCUSSION:
+                 These error reports generally reflect soft errors that
+                 can be ignored without harm by many applications.  It
+                 has been suggested that these error report calls should
+                 default to "disabled," but this is not required.
+
+         4.2.4.2  Type-of-Service
+
+            The application layer MUST be able to specify the Type-of-
+            Service (TOS) for segments that are sent on a connection.
+            It not required, but the application SHOULD be able to
+            change the TOS during the connection lifetime.  TCP SHOULD
+            pass the current TOS value without change to the IP layer,
+            when it sends segments on the connection.
+
+            The TOS will be specified independently in each direction on
+            the connection, so that the receiver application will
+            specify the TOS used for ACK segments.
+
+            TCP MAY pass the most recently received TOS up to the
+            application.
+
+            DISCUSSION
+                 Some applications (e.g., SMTP) change the nature of
+                 their communication during the lifetime of a
+                 connection, and therefore would like to change the TOS
+                 specification.
+
+                 Note also that the OPEN call specified in RFC-793
+                 includes a parameter ("options") in which the caller
+                 can specify IP options such as source route, record
+                 route, or timestamp.
+
+         4.2.4.3  Flush Call
+
+            Some TCP implementations have included a FLUSH call, which
+            will empty the TCP send queue of any data for which the user
+            has issued SEND calls but which is still to the right of the
+            current send window.  That is, it flushes as much queued
+            send data as possible without losing sequence number
+            synchronization.  This is useful for implementing the "abort
+            output" function of Telnet.
+
+
+
+
+
+
+
+Internet Engineering Task Force                               [Page 107]
+
+
+
+
+RFC1122                  TRANSPORT LAYER -- TCP             October 1989
+
+
+         4.2.4.4  Multihoming
+
+            The user interface outlined in sections 2.7 and 3.8 of RFC-
+            793 needs to be extended for multihoming.  The OPEN call
+            MUST have an optional parameter:
+
+                OPEN( ... [local IP address,] ... )
+
+            to allow the specification of the local IP address.
+
+            DISCUSSION:
+                 Some TCP-based applications need to specify the local
+                 IP address to be used to open a particular connection;
+                 FTP is an example.
+
+            IMPLEMENTATION:
+                 A passive OPEN call with a specified "local IP address"
+                 parameter will await an incoming connection request to
+                 that address.  If the parameter is unspecified, a
+                 passive OPEN will await an incoming connection request
+                 to any local IP address, and then bind the local IP
+                 address of the connection to the particular address
+                 that is used.
+
+                 For an active OPEN call, a specified "local IP address"
+                 parameter will be used for opening the connection.  If
+                 the parameter is unspecified, the networking software
+                 will choose an appropriate local IP address (see
+                 Section 3.3.4.2) for the connection
+
+      4.2.5  TCP REQUIREMENT SUMMARY
+
+                                                 |        | | | |S| |
+                                                 |        | | | |H| |F
+                                                 |        | | | |O|M|o
+                                                 |        | |S| |U|U|o
+                                                 |        | |H| |L|S|t
+                                                 |        |M|O| |D|T|n
+                                                 |        |U|U|M| | |o
+                                                 |        |S|L|A|N|N|t
+                                                 |        |T|D|Y|O|O|t
+FEATURE                                          |SECTION | | | |T|T|e
+-------------------------------------------------|--------|-|-|-|-|-|--
+                                                 |        | | | | | |
+Push flag                                        |        | | | | | |
+  Aggregate or queue un-pushed data              |4.2.2.2 | | |x| | |
+  Sender collapse successive PSH flags           |4.2.2.2 | |x| | | |
+  SEND call can specify PUSH                     |4.2.2.2 | | |x| | |
+
+
+
+Internet Engineering Task Force                               [Page 108]
+
+
+
+
+RFC1122                  TRANSPORT LAYER -- TCP             October 1989
+
+
+    If cannot: sender buffer indefinitely        |4.2.2.2 | | | | |x|
+    If cannot: PSH last segment                  |4.2.2.2 |x| | | | |
+  Notify receiving ALP of PSH                    |4.2.2.2 | | |x| | |1
+  Send max size segment when possible            |4.2.2.2 | |x| | | |
+                                                 |        | | | | | |
+Window                                           |        | | | | | |
+  Treat as unsigned number                       |4.2.2.3 |x| | | | |
+  Handle as 32-bit number                        |4.2.2.3 | |x| | | |
+  Shrink window from right                       |4.2.2.16| | | |x| |
+  Robust against shrinking window                |4.2.2.16|x| | | | |
+  Receiver's window closed indefinitely          |4.2.2.17| | |x| | |
+  Sender probe zero window                       |4.2.2.17|x| | | | |
+    First probe after RTO                        |4.2.2.17| |x| | | |
+    Exponential backoff                          |4.2.2.17| |x| | | |
+  Allow window stay zero indefinitely            |4.2.2.17|x| | | | |
+  Sender timeout OK conn with zero wind          |4.2.2.17| | | | |x|
+                                                 |        | | | | | |
+Urgent Data                                      |        | | | | | |
+  Pointer points to last octet                   |4.2.2.4 |x| | | | |
+  Arbitrary length urgent data sequence          |4.2.2.4 |x| | | | |
+  Inform ALP asynchronously of urgent data       |4.2.2.4 |x| | | | |1
+  ALP can learn if/how much urgent data Q'd      |4.2.2.4 |x| | | | |1
+                                                 |        | | | | | |
+TCP Options                                      |        | | | | | |
+  Receive TCP option in any segment              |4.2.2.5 |x| | | | |
+  Ignore unsupported options                     |4.2.2.5 |x| | | | |
+  Cope with illegal option length                |4.2.2.5 |x| | | | |
+  Implement sending & receiving MSS option       |4.2.2.6 |x| | | | |
+  Send MSS option unless 536                     |4.2.2.6 | |x| | | |
+  Send MSS option always                         |4.2.2.6 | | |x| | |
+  Send-MSS default is 536                        |4.2.2.6 |x| | | | |
+  Calculate effective send seg size              |4.2.2.6 |x| | | | |
+                                                 |        | | | | | |
+TCP Checksums                                    |        | | | | | |
+  Sender compute checksum                        |4.2.2.7 |x| | | | |
+  Receiver check checksum                        |4.2.2.7 |x| | | | |
+                                                 |        | | | | | |
+Use clock-driven ISN selection                   |4.2.2.9 |x| | | | |
+                                                 |        | | | | | |
+Opening Connections                              |        | | | | | |
+  Support simultaneous open attempts             |4.2.2.10|x| | | | |
+  SYN-RCVD remembers last state                  |4.2.2.11|x| | | | |
+  Passive Open call interfere with others        |4.2.2.18| | | | |x|
+  Function: simultan. LISTENs for same port      |4.2.2.18|x| | | | |
+  Ask IP for src address for SYN if necc.        |4.2.3.7 |x| | | | |
+    Otherwise, use local addr of conn.           |4.2.3.7 |x| | | | |
+  OPEN to broadcast/multicast IP Address         |4.2.3.14| | | | |x|
+  Silently discard seg to bcast/mcast addr       |4.2.3.14|x| | | | |
+
+
+
+Internet Engineering Task Force                               [Page 109]
+
+
+
+
+RFC1122                  TRANSPORT LAYER -- TCP             October 1989
+
+
+                                                 |        | | | | | |
+Closing Connections                              |        | | | | | |
+  RST can contain data                           |4.2.2.12| |x| | | |
+  Inform application of aborted conn             |4.2.2.13|x| | | | |
+  Half-duplex close connections                  |4.2.2.13| | |x| | |
+    Send RST to indicate data lost               |4.2.2.13| |x| | | |
+  In TIME-WAIT state for 2xMSL seconds           |4.2.2.13|x| | | | |
+    Accept SYN from TIME-WAIT state              |4.2.2.13| | |x| | |
+                                                 |        | | | | | |
+Retransmissions                                  |        | | | | | |
+  Jacobson Slow Start algorithm                  |4.2.2.15|x| | | | |
+  Jacobson Congestion-Avoidance algorithm        |4.2.2.15|x| | | | |
+  Retransmit with same IP ident                  |4.2.2.15| | |x| | |
+  Karn's algorithm                               |4.2.3.1 |x| | | | |
+  Jacobson's RTO estimation alg.                 |4.2.3.1 |x| | | | |
+  Exponential backoff                            |4.2.3.1 |x| | | | |
+  SYN RTO calc same as data                      |4.2.3.1 | |x| | | |
+  Recommended initial values and bounds          |4.2.3.1 | |x| | | |
+                                                 |        | | | | | |
+Generating ACK's:                                |        | | | | | |
+  Queue out-of-order segments                    |4.2.2.20| |x| | | |
+  Process all Q'd before send ACK                |4.2.2.20|x| | | | |
+  Send ACK for out-of-order segment              |4.2.2.21| | |x| | |
+  Delayed ACK's                                  |4.2.3.2 | |x| | | |
+    Delay < 0.5 seconds                          |4.2.3.2 |x| | | | |
+    Every 2nd full-sized segment ACK'd           |4.2.3.2 |x| | | | |
+  Receiver SWS-Avoidance Algorithm               |4.2.3.3 |x| | | | |
+                                                 |        | | | | | |
+Sending data                                     |        | | | | | |
+  Configurable TTL                               |4.2.2.19|x| | | | |
+  Sender SWS-Avoidance Algorithm                 |4.2.3.4 |x| | | | |
+  Nagle algorithm                                |4.2.3.4 | |x| | | |
+    Application can disable Nagle algorithm      |4.2.3.4 |x| | | | |
+                                                 |        | | | | | |
+Connection Failures:                             |        | | | | | |
+  Negative advice to IP on R1 retxs              |4.2.3.5 |x| | | | |
+  Close connection on R2 retxs                   |4.2.3.5 |x| | | | |
+  ALP can set R2                                 |4.2.3.5 |x| | | | |1
+  Inform ALP of  R1<=retxs<R2                    |4.2.3.5 | |x| | | |1
+  Recommended values for R1, R2                  |4.2.3.5 | |x| | | |
+  Same mechanism for SYNs                        |4.2.3.5 |x| | | | |
+    R2 at least 3 minutes for SYN                |4.2.3.5 |x| | | | |
+                                                 |        | | | | | |
+Send Keep-alive Packets:                         |4.2.3.6 | | |x| | |
+  - Application can request                      |4.2.3.6 |x| | | | |
+  - Default is "off"                             |4.2.3.6 |x| | | | |
+  - Only send if idle for interval               |4.2.3.6 |x| | | | |
+  - Interval configurable                        |4.2.3.6 |x| | | | |
+
+
+
+Internet Engineering Task Force                               [Page 110]
+
+
+
+
+RFC1122                  TRANSPORT LAYER -- TCP             October 1989
+
+
+  - Default at least 2 hrs.                      |4.2.3.6 |x| | | | |
+  - Tolerant of lost ACK's                       |4.2.3.6 |x| | | | |
+                                                 |        | | | | | |
+IP Options                                       |        | | | | | |
+  Ignore options TCP doesn't understand          |4.2.3.8 |x| | | | |
+  Time Stamp support                             |4.2.3.8 | | |x| | |
+  Record Route support                           |4.2.3.8 | | |x| | |
+  Source Route:                                  |        | | | | | |
+    ALP can specify                              |4.2.3.8 |x| | | | |1
+      Overrides src rt in datagram               |4.2.3.8 |x| | | | |
+    Build return route from src rt               |4.2.3.8 |x| | | | |
+    Later src route overrides                    |4.2.3.8 | |x| | | |
+                                                 |        | | | | | |
+Receiving ICMP Messages from IP                  |4.2.3.9 |x| | | | |
+  Dest. Unreach (0,1,5) => inform ALP            |4.2.3.9 | |x| | | |
+  Dest. Unreach (0,1,5) => abort conn            |4.2.3.9 | | | | |x|
+  Dest. Unreach (2-4) => abort conn              |4.2.3.9 | |x| | | |
+  Source Quench => slow start                    |4.2.3.9 | |x| | | |
+  Time Exceeded => tell ALP, don't abort         |4.2.3.9 | |x| | | |
+  Param Problem => tell ALP, don't abort         |4.2.3.9 | |x| | | |
+                                                 |        | | | | | |
+Address Validation                               |        | | | | | |
+  Reject OPEN call to invalid IP address         |4.2.3.10|x| | | | |
+  Reject SYN from invalid IP address             |4.2.3.10|x| | | | |
+  Silently discard SYN to bcast/mcast addr       |4.2.3.10|x| | | | |
+                                                 |        | | | | | |
+TCP/ALP Interface Services                       |        | | | | | |
+  Error Report mechanism                         |4.2.4.1 |x| | | | |
+  ALP can disable Error Report Routine           |4.2.4.1 | |x| | | |
+  ALP can specify TOS for sending                |4.2.4.2 |x| | | | |
+    Passed unchanged to IP                       |4.2.4.2 | |x| | | |
+  ALP can change TOS during connection           |4.2.4.2 | |x| | | |
+  Pass received TOS up to ALP                    |4.2.4.2 | | |x| | |
+  FLUSH call                                     |4.2.4.3 | | |x| | |
+  Optional local IP addr parm. in OPEN           |4.2.4.4 |x| | | | |
+-------------------------------------------------|--------|-|-|-|-|-|--
+-------------------------------------------------|--------|-|-|-|-|-|--
+
+FOOTNOTES:
+
+(1)  "ALP" means Application-Layer program.
+
+
+
+
+
+
+
+
+
+
+Internet Engineering Task Force                               [Page 111]
+
+
+
+
+RFC1122                  TRANSPORT LAYER -- TCP             October 1989
+
+
+5.  REFERENCES
+
+INTRODUCTORY REFERENCES
+
+
+[INTRO:1] "Requirements for Internet Hosts -- Application and Support,"
+     IETF Host Requirements Working Group, R. Braden, Ed., RFC-1123,
+     October 1989.
+
+[INTRO:2]  "Requirements for Internet Gateways,"  R. Braden and J.
+     Postel, RFC-1009, June 1987.
+
+[INTRO:3]  "DDN Protocol Handbook," NIC-50004, NIC-50005, NIC-50006,
+     (three volumes), SRI International, December 1985.
+
+[INTRO:4]  "Official Internet Protocols," J. Reynolds and J. Postel,
+     RFC-1011, May 1987.
+
+     This document is republished periodically with new RFC numbers; the
+     latest version must be used.
+
+[INTRO:5]  "Protocol Document Order Information," O. Jacobsen and J.
+     Postel, RFC-980, March 1986.
+
+[INTRO:6]  "Assigned Numbers," J. Reynolds and J. Postel, RFC-1010, May
+     1987.
+
+     This document is republished periodically with new RFC numbers; the
+     latest version must be used.
+
+[INTRO:7] "Modularity and Efficiency in Protocol Implementations," D.
+     Clark, RFC-817, July 1982.
+
+[INTRO:8] "The Structuring of Systems Using Upcalls," D. Clark, 10th ACM
+     SOSP, Orcas Island, Washington, December 1985.
+
+
+Secondary References:
+
+
+[INTRO:9]  "A Protocol for Packet Network Intercommunication," V. Cerf
+     and R. Kahn, IEEE Transactions on Communication, May 1974.
+
+[INTRO:10]  "The ARPA Internet Protocol," J. Postel, C. Sunshine, and D.
+     Cohen, Computer Networks, Vol. 5, No. 4, July 1981.
+
+[INTRO:11]  "The DARPA Internet Protocol Suite," B. Leiner, J. Postel,
+     R. Cole and D. Mills, Proceedings INFOCOM 85, IEEE, Washington DC,
+
+
+
+Internet Engineering Task Force                               [Page 112]
+
+
+
+
+RFC1122                  TRANSPORT LAYER -- TCP             October 1989
+
+
+     March 1985.  Also in: IEEE Communications Magazine, March 1985.
+     Also available as ISI-RS-85-153.
+
+[INTRO:12] "Final Text of DIS8473, Protocol for Providing the
+     Connectionless Mode Network Service," ANSI, published as RFC-994,
+     March 1986.
+
+[INTRO:13] "End System to Intermediate System Routing Exchange
+     Protocol," ANSI X3S3.3, published as RFC-995, April 1986.
+
+
+LINK LAYER REFERENCES
+
+
+[LINK:1] "Trailer Encapsulations," S. Leffler and M. Karels, RFC-893,
+     April 1984.
+
+[LINK:2] "An Ethernet Address Resolution Protocol," D. Plummer, RFC-826,
+     November 1982.
+
+[LINK:3] "A Standard for the Transmission of IP Datagrams over Ethernet
+     Networks," C. Hornig, RFC-894, April 1984.
+
+[LINK:4] "A Standard for the Transmission of IP Datagrams over IEEE 802
+     "Networks," J. Postel and J. Reynolds, RFC-1042, February 1988.
+
+     This RFC contains a great deal of information of importance to
+     Internet implementers planning to use IEEE 802 networks.
+
+
+IP LAYER REFERENCES
+
+
+[IP:1] "Internet Protocol (IP)," J. Postel, RFC-791, September 1981.
+
+[IP:2] "Internet Control Message Protocol (ICMP)," J. Postel, RFC-792,
+     September 1981.
+
+[IP:3] "Internet Standard Subnetting Procedure," J. Mogul and J. Postel,
+     RFC-950, August 1985.
+
+[IP:4]  "Host Extensions for IP Multicasting," S. Deering, RFC-1112,
+     August 1989.
+
+[IP:5] "Military Standard Internet Protocol," MIL-STD-1777, Department
+     of Defense, August 1983.
+
+     This specification, as amended by RFC-963, is intended to describe
+
+
+
+Internet Engineering Task Force                               [Page 113]
+
+
+
+
+RFC1122                  TRANSPORT LAYER -- TCP             October 1989
+
+
+     the Internet Protocol but has some serious omissions (e.g., the
+     mandatory subnet extension [IP:3] and the optional multicasting
+     extension [IP:4]).  It is also out of date.  If there is a
+     conflict, RFC-791, RFC-792, and RFC-950 must be taken as
+     authoritative, while the present document is authoritative over
+     all.
+
+[IP:6] "Some Problems with the Specification of the Military Standard
+     Internet Protocol," D. Sidhu, RFC-963, November 1985.
+
+[IP:7] "The TCP Maximum Segment Size and Related Topics," J. Postel,
+     RFC-879, November 1983.
+
+     Discusses and clarifies the relationship between the TCP Maximum
+     Segment Size option and the IP datagram size.
+
+[IP:8] "Internet Protocol Security Options,"  B. Schofield, RFC-1108,
+     October 1989.
+
+[IP:9] "Fragmentation Considered Harmful," C. Kent and J. Mogul, ACM
+     SIGCOMM-87, August 1987.  Published as ACM Comp Comm Review, Vol.
+     17, no. 5.
+
+     This useful paper discusses the problems created by Internet
+     fragmentation and presents alternative solutions.
+
+[IP:10] "IP Datagram Reassembly Algorithms," D. Clark, RFC-815, July
+     1982.
+
+     This and the following paper should be read by every implementor.
+
+[IP:11] "Fault Isolation and Recovery," D. Clark, RFC-816, July 1982.
+
+SECONDARY IP REFERENCES:
+
+
+[IP:12] "Broadcasting Internet Datagrams in the Presence of Subnets," J.
+     Mogul, RFC-922, October 1984.
+
+[IP:13] "Name, Addresses, Ports, and Routes," D. Clark, RFC-814, July
+     1982.
+
+[IP:14] "Something a Host Could Do with Source Quench: The Source Quench
+     Introduced Delay (SQUID)," W. Prue and J. Postel, RFC-1016, July
+     1987.
+
+     This RFC first described directed broadcast addresses.  However,
+     the bulk of the RFC is concerned with gateways, not hosts.
+
+
+
+Internet Engineering Task Force                               [Page 114]
+
+
+
+
+RFC1122                  TRANSPORT LAYER -- TCP             October 1989
+
+
+UDP REFERENCES:
+
+
+[UDP:1] "User Datagram Protocol," J. Postel, RFC-768, August 1980.
+
+
+TCP REFERENCES:
+
+
+[TCP:1] "Transmission Control Protocol," J. Postel, RFC-793, September
+     1981.
+
+
+[TCP:2] "Transmission Control Protocol," MIL-STD-1778, US Department of
+     Defense, August 1984.
+
+     This specification as amended by RFC-964 is intended to describe
+     the same protocol as RFC-793 [TCP:1].  If there is a conflict,
+     RFC-793 takes precedence, and the present document is authoritative
+     over both.
+
+
+[TCP:3] "Some Problems with the Specification of the Military Standard
+     Transmission Control Protocol," D. Sidhu and T. Blumer, RFC-964,
+     November 1985.
+
+
+[TCP:4] "The TCP Maximum Segment Size and Related Topics," J. Postel,
+     RFC-879, November 1983.
+
+
+[TCP:5] "Window and Acknowledgment Strategy in TCP," D. Clark, RFC-813,
+     July 1982.
+
+
+[TCP:6] "Round Trip Time Estimation," P. Karn & C. Partridge, ACM
+     SIGCOMM-87, August 1987.
+
+
+[TCP:7] "Congestion Avoidance and Control," V. Jacobson, ACM SIGCOMM-88,
+     August 1988.
+
+
+SECONDARY TCP REFERENCES:
+
+
+[TCP:8] "Modularity and Efficiency in Protocol Implementation," D.
+     Clark, RFC-817, July 1982.
+
+
+
+Internet Engineering Task Force                               [Page 115]
+
+
+
+
+RFC1122                  TRANSPORT LAYER -- TCP             October 1989
+
+
+[TCP:9] "Congestion Control in IP/TCP," J. Nagle, RFC-896, January 1984.
+
+
+[TCP:10] "Computing the Internet Checksum," R. Braden, D. Borman, and C.
+     Partridge, RFC-1071, September 1988.
+
+
+[TCP:11] "TCP Extensions for Long-Delay Paths," V. Jacobson & R. Braden,
+     RFC-1072, October 1988.
+
+
+Security Considerations
+
+   There are many security issues in the communication layers of host
+   software, but a full discussion is beyond the scope of this RFC.
+
+   The Internet architecture generally provides little protection
+   against spoofing of IP source addresses, so any security mechanism
+   that is based upon verifying the IP source address of a datagram
+   should be treated with suspicion.  However, in restricted
+   environments some source-address checking may be possible.  For
+   example, there might be a secure LAN whose gateway to the rest of the
+   Internet discarded any incoming datagram with a source address that
+   spoofed the LAN address.  In this case, a host on the LAN could use
+   the source address to test for local vs. remote source.  This problem
+   is complicated by source routing, and some have suggested that
+   source-routed datagram forwarding by hosts (see Section 3.3.5) should
+   be outlawed for security reasons.
+
+   Security-related issues are mentioned in sections concerning the IP
+   Security option (Section 3.2.1.8), the ICMP Parameter Problem message
+   (Section 3.2.2.5), IP options in UDP datagrams (Section 4.1.3.2), and
+   reserved TCP ports (Section 4.2.2.1).
+
+Author's Address
+
+   Robert Braden
+   USC/Information Sciences Institute
+   4676 Admiralty Way
+   Marina del Rey, CA 90292-6695
+
+   Phone: (213) 822 1511
+
+   EMail: Braden@ISI.EDU
+
+
+
+
+
+
+
+Internet Engineering Task Force                               [Page 116]
+
diff --git a/doc/rfc/rfc1123.txt b/doc/rfc/rfc1123.txt
new file mode 100644
index 0000000..51cdf83
--- /dev/null
+++ b/doc/rfc/rfc1123.txt
@@ -0,0 +1,5782 @@
+
+
+
+
+
+
+Network Working Group                    Internet Engineering Task Force
+Request for Comments: 1123                             R. Braden, Editor
+                                                            October 1989
+
+
+       Requirements for Internet Hosts -- Application and Support
+
+Status of This Memo
+
+   This RFC is an official specification for the Internet community.  It
+   incorporates by reference, amends, corrects, and supplements the
+   primary protocol standards documents relating to hosts.  Distribution
+   of this document is unlimited.
+
+Summary
+
+   This RFC is one of a pair that defines and discusses the requirements
+   for Internet host software.  This RFC covers the application and
+   support protocols; its companion RFC-1122 covers the communication
+   protocol layers: link layer, IP layer, and transport layer.
+
+
+
+                           Table of Contents
+
+
+
+
+   1.  INTRODUCTION ...............................................    5
+      1.1  The Internet Architecture ..............................    6
+      1.2  General Considerations .................................    6
+         1.2.1  Continuing Internet Evolution .....................    6
+         1.2.2  Robustness Principle ..............................    7
+         1.2.3  Error Logging .....................................    8
+         1.2.4  Configuration .....................................    8
+      1.3  Reading this Document ..................................   10
+         1.3.1  Organization ......................................   10
+         1.3.2  Requirements ......................................   10
+         1.3.3  Terminology .......................................   11
+      1.4  Acknowledgments ........................................   12
+
+   2.  GENERAL ISSUES .............................................   13
+      2.1  Host Names and Numbers .................................   13
+      2.2  Using Domain Name Service ..............................   13
+      2.3  Applications on Multihomed hosts .......................   14
+      2.4  Type-of-Service ........................................   14
+      2.5  GENERAL APPLICATION REQUIREMENTS SUMMARY ...............   15
+
+
+
+
+Internet Engineering Task Force                                 [Page 1]
+
+
+
+
+RFC1123                       INTRODUCTION                  October 1989
+
+
+   3.  REMOTE LOGIN -- TELNET PROTOCOL ............................   16
+      3.1  INTRODUCTION ...........................................   16
+      3.2  PROTOCOL WALK-THROUGH ..................................   16
+         3.2.1  Option Negotiation ................................   16
+         3.2.2  Telnet Go-Ahead Function ..........................   16
+         3.2.3  Control Functions .................................   17
+         3.2.4  Telnet "Synch" Signal .............................   18
+         3.2.5  NVT Printer and Keyboard ..........................   19
+         3.2.6  Telnet Command Structure ..........................   20
+         3.2.7  Telnet Binary Option ..............................   20
+         3.2.8  Telnet Terminal-Type Option .......................   20
+      3.3  SPECIFIC ISSUES ........................................   21
+         3.3.1  Telnet End-of-Line Convention .....................   21
+         3.3.2  Data Entry Terminals ..............................   23
+         3.3.3  Option Requirements ...............................   24
+         3.3.4  Option Initiation .................................   24
+         3.3.5  Telnet Linemode Option ............................   25
+      3.4  TELNET/USER INTERFACE ..................................   25
+         3.4.1  Character Set Transparency ........................   25
+         3.4.2  Telnet Commands ...................................   26
+         3.4.3  TCP Connection Errors .............................   26
+         3.4.4  Non-Default Telnet Contact Port ...................   26
+         3.4.5  Flushing Output ...................................   26
+      3.5.  TELNET REQUIREMENTS SUMMARY ...........................   27
+
+   4.  FILE TRANSFER ..............................................   29
+      4.1  FILE TRANSFER PROTOCOL -- FTP ..........................   29
+         4.1.1  INTRODUCTION ......................................   29
+         4.1.2.  PROTOCOL WALK-THROUGH ............................   29
+            4.1.2.1  LOCAL Type ...................................   29
+            4.1.2.2  Telnet Format Control ........................   30
+            4.1.2.3  Page Structure ...............................   30
+            4.1.2.4  Data Structure Transformations ...............   30
+            4.1.2.5  Data Connection Management ...................   31
+            4.1.2.6  PASV Command .................................   31
+            4.1.2.7  LIST and NLST Commands .......................   31
+            4.1.2.8  SITE Command .................................   32
+            4.1.2.9  STOU Command .................................   32
+            4.1.2.10  Telnet End-of-line Code .....................   32
+            4.1.2.11  FTP Replies .................................   33
+            4.1.2.12  Connections .................................   34
+            4.1.2.13  Minimum Implementation; RFC-959 Section .....   34
+         4.1.3  SPECIFIC ISSUES ...................................   35
+            4.1.3.1  Non-standard Command Verbs ...................   35
+            4.1.3.2  Idle Timeout .................................   36
+            4.1.3.3  Concurrency of Data and Control ..............   36
+            4.1.3.4  FTP Restart Mechanism ........................   36
+         4.1.4  FTP/USER INTERFACE ................................   39
+
+
+
+Internet Engineering Task Force                                 [Page 2]
+
+
+
+
+RFC1123                       INTRODUCTION                  October 1989
+
+
+            4.1.4.1  Pathname Specification .......................   39
+            4.1.4.2  "QUOTE" Command ..............................   40
+            4.1.4.3  Displaying Replies to User ...................   40
+            4.1.4.4  Maintaining Synchronization ..................   40
+         4.1.5   FTP REQUIREMENTS SUMMARY .........................   41
+      4.2  TRIVIAL FILE TRANSFER PROTOCOL -- TFTP .................   44
+         4.2.1  INTRODUCTION ......................................   44
+         4.2.2  PROTOCOL WALK-THROUGH .............................   44
+            4.2.2.1  Transfer Modes ...............................   44
+            4.2.2.2  UDP Header ...................................   44
+         4.2.3  SPECIFIC ISSUES ...................................   44
+            4.2.3.1  Sorcerer's Apprentice Syndrome ...............   44
+            4.2.3.2  Timeout Algorithms ...........................   46
+            4.2.3.3  Extensions ...................................   46
+            4.2.3.4  Access Control ...............................   46
+            4.2.3.5  Broadcast Request ............................   46
+         4.2.4  TFTP REQUIREMENTS SUMMARY .........................   47
+
+   5.  ELECTRONIC MAIL -- SMTP and RFC-822 ........................   48
+      5.1  INTRODUCTION ...........................................   48
+      5.2  PROTOCOL WALK-THROUGH ..................................   48
+         5.2.1  The SMTP Model ....................................   48
+         5.2.2  Canonicalization ..................................   49
+         5.2.3  VRFY and EXPN Commands ............................   50
+         5.2.4  SEND, SOML, and SAML Commands .....................   50
+         5.2.5  HELO Command ......................................   50
+         5.2.6  Mail Relay ........................................   51
+         5.2.7  RCPT Command ......................................   52
+         5.2.8  DATA Command ......................................   53
+         5.2.9  Command Syntax ....................................   54
+         5.2.10  SMTP Replies .....................................   54
+         5.2.11  Transparency .....................................   55
+         5.2.12  WKS Use in MX Processing .........................   55
+         5.2.13  RFC-822 Message Specification ....................   55
+         5.2.14  RFC-822 Date and Time Specification ..............   55
+         5.2.15  RFC-822 Syntax Change ............................   56
+         5.2.16  RFC-822  Local-part ..............................   56
+         5.2.17  Domain Literals ..................................   57
+         5.2.18  Common Address Formatting Errors .................   58
+         5.2.19  Explicit Source Routes ...........................   58
+      5.3  SPECIFIC ISSUES ........................................   59
+         5.3.1  SMTP Queueing Strategies ..........................   59
+            5.3.1.1 Sending Strategy ..............................   59
+            5.3.1.2  Receiving strategy ...........................   61
+         5.3.2  Timeouts in SMTP ..................................   61
+         5.3.3  Reliable Mail Receipt .............................   63
+         5.3.4  Reliable Mail Transmission ........................   63
+         5.3.5  Domain Name Support ...............................   65
+
+
+
+Internet Engineering Task Force                                 [Page 3]
+
+
+
+
+RFC1123                       INTRODUCTION                  October 1989
+
+
+         5.3.6  Mailing Lists and Aliases .........................   65
+         5.3.7  Mail Gatewaying ...................................   66
+         5.3.8  Maximum Message Size ..............................   68
+      5.4  SMTP REQUIREMENTS SUMMARY ..............................   69
+
+   6. SUPPORT SERVICES ............................................   72
+      6.1 DOMAIN NAME TRANSLATION .................................   72
+         6.1.1 INTRODUCTION .......................................   72
+         6.1.2  PROTOCOL WALK-THROUGH .............................   72
+            6.1.2.1  Resource Records with Zero TTL ...............   73
+            6.1.2.2  QCLASS Values ................................   73
+            6.1.2.3  Unused Fields ................................   73
+            6.1.2.4  Compression ..................................   73
+            6.1.2.5  Misusing Configuration Info ..................   73
+         6.1.3  SPECIFIC ISSUES ...................................   74
+            6.1.3.1  Resolver Implementation ......................   74
+            6.1.3.2  Transport Protocols ..........................   75
+            6.1.3.3  Efficient Resource Usage .....................   77
+            6.1.3.4  Multihomed Hosts .............................   78
+            6.1.3.5  Extensibility ................................   79
+            6.1.3.6  Status of RR Types ...........................   79
+            6.1.3.7  Robustness ...................................   80
+            6.1.3.8  Local Host Table .............................   80
+         6.1.4  DNS USER INTERFACE ................................   81
+            6.1.4.1  DNS Administration ...........................   81
+            6.1.4.2  DNS User Interface ...........................   81
+            6.1.4.3 Interface Abbreviation Facilities .............   82
+         6.1.5  DOMAIN NAME SYSTEM REQUIREMENTS SUMMARY ...........   84
+      6.2  HOST INITIALIZATION ....................................   87
+         6.2.1  INTRODUCTION ......................................   87
+         6.2.2  REQUIREMENTS ......................................   87
+            6.2.2.1  Dynamic Configuration ........................   87
+            6.2.2.2  Loading Phase ................................   89
+      6.3  REMOTE MANAGEMENT ......................................   90
+         6.3.1  INTRODUCTION ......................................   90
+         6.3.2  PROTOCOL WALK-THROUGH .............................   90
+         6.3.3  MANAGEMENT REQUIREMENTS SUMMARY ...................   92
+
+   7.  REFERENCES .................................................   93
+
+
+
+
+
+
+
+
+
+
+
+
+Internet Engineering Task Force                                 [Page 4]
+
+
+
+
+RFC1123                       INTRODUCTION                  October 1989
+
+
+1.  INTRODUCTION
+
+   This document is one of a pair that defines and discusses the
+   requirements for host system implementations of the Internet protocol
+   suite.  This RFC covers the applications layer and support protocols.
+   Its companion RFC, "Requirements for Internet Hosts -- Communications
+   Layers" [INTRO:1] covers the lower layer protocols: transport layer,
+   IP layer, and link layer.
+
+   These documents are intended to provide guidance for vendors,
+   implementors, and users of Internet communication software.  They
+   represent the consensus of a large body of technical experience and
+   wisdom, contributed by members of the Internet research and vendor
+   communities.
+
+   This RFC enumerates standard protocols that a host connected to the
+   Internet must use, and it incorporates by reference the RFCs and
+   other documents describing the current specifications for these
+   protocols.  It corrects errors in the referenced documents and adds
+   additional discussion and guidance for an implementor.
+
+   For each protocol, this document also contains an explicit set of
+   requirements, recommendations, and options.  The reader must
+   understand that the list of requirements in this document is
+   incomplete by itself; the complete set of requirements for an
+   Internet host is primarily defined in the standard protocol
+   specification documents, with the corrections, amendments, and
+   supplements contained in this RFC.
+
+   A good-faith implementation of the protocols that was produced after
+   careful reading of the RFC's and with some interaction with the
+   Internet technical community, and that followed good communications
+   software engineering practices, should differ from the requirements
+   of this document in only minor ways.  Thus, in many cases, the
+   "requirements" in this RFC are already stated or implied in the
+   standard protocol documents, so that their inclusion here is, in a
+   sense, redundant.  However, they were included because some past
+   implementation has made the wrong choice, causing problems of
+   interoperability, performance, and/or robustness.
+
+   This document includes discussion and explanation of many of the
+   requirements and recommendations.  A simple list of requirements
+   would be dangerous, because:
+
+   o    Some required features are more important than others, and some
+        features are optional.
+
+   o    There may be valid reasons why particular vendor products that
+
+
+
+Internet Engineering Task Force                                 [Page 5]
+
+
+
+
+RFC1123                       INTRODUCTION                  October 1989
+
+
+        are designed for restricted contexts might choose to use
+        different specifications.
+
+   However, the specifications of this document must be followed to meet
+   the general goal of arbitrary host interoperation across the
+   diversity and complexity of the Internet system.  Although most
+   current implementations fail to meet these requirements in various
+   ways, some minor and some major, this specification is the ideal
+   towards which we need to move.
+
+   These requirements are based on the current level of Internet
+   architecture.  This document will be updated as required to provide
+   additional clarifications or to include additional information in
+   those areas in which specifications are still evolving.
+
+   This introductory section begins with general advice to host software
+   vendors, and then gives some guidance on reading the rest of the
+   document.  Section 2 contains general requirements that may be
+   applicable to all application and support protocols.  Sections 3, 4,
+   and 5 contain the requirements on protocols for the three major
+   applications: Telnet, file transfer, and electronic mail,
+   respectively. Section 6 covers the support applications: the domain
+   name system, system initialization, and management.  Finally, all
+   references will be found in Section 7.
+
+   1.1  The Internet Architecture
+
+      For a brief introduction to the Internet architecture from a host
+      viewpoint, see Section 1.1 of [INTRO:1].  That section also
+      contains recommended references for general background on the
+      Internet architecture.
+
+   1.2  General Considerations
+
+      There are two important lessons that vendors of Internet host
+      software have learned and which a new vendor should consider
+      seriously.
+
+      1.2.1  Continuing Internet Evolution
+
+         The enormous growth of the Internet has revealed problems of
+         management and scaling in a large datagram-based packet
+         communication system.  These problems are being addressed, and
+         as a result there will be continuing evolution of the
+         specifications described in this document.  These changes will
+         be carefully planned and controlled, since there is extensive
+         participation in this planning by the vendors and by the
+         organizations responsible for operations of the networks.
+
+
+
+Internet Engineering Task Force                                 [Page 6]
+
+
+
+
+RFC1123                       INTRODUCTION                  October 1989
+
+
+         Development, evolution, and revision are characteristic of
+         computer network protocols today, and this situation will
+         persist for some years.  A vendor who develops computer
+         communication software for the Internet protocol suite (or any
+         other protocol suite!) and then fails to maintain and update
+         that software for changing specifications is going to leave a
+         trail of unhappy customers.  The Internet is a large
+         communication network, and the users are in constant contact
+         through it.  Experience has shown that knowledge of
+         deficiencies in vendor software propagates quickly through the
+         Internet technical community.
+
+      1.2.2  Robustness Principle
+
+         At every layer of the protocols, there is a general rule whose
+         application can lead to enormous benefits in robustness and
+         interoperability:
+
+                "Be liberal in what you accept, and
+                 conservative in what you send"
+
+         Software should be written to deal with every conceivable
+         error, no matter how unlikely; sooner or later a packet will
+         come in with that particular combination of errors and
+         attributes, and unless the software is prepared, chaos can
+         ensue.  In general, it is best to assume that the network is
+         filled with malevolent entities that will send in packets
+         designed to have the worst possible effect.  This assumption
+         will lead to suitable protective design, although the most
+         serious problems in the Internet have been caused by
+         unenvisaged mechanisms triggered by low-probability events;
+         mere human malice would never have taken so devious a course!
+
+         Adaptability to change must be designed into all levels of
+         Internet host software.  As a simple example, consider a
+         protocol specification that contains an enumeration of values
+         for a particular header field -- e.g., a type field, a port
+         number, or an error code; this enumeration must be assumed to
+         be incomplete.  Thus, if a protocol specification defines four
+         possible error codes, the software must not break when a fifth
+         code shows up.  An undefined code might be logged (see below),
+         but it must not cause a failure.
+
+         The second part of the principle is almost as important:
+         software on other hosts may contain deficiencies that make it
+         unwise to exploit legal but obscure protocol features.  It is
+         unwise to stray far from the obvious and simple, lest untoward
+         effects result elsewhere.  A corollary of this is "watch out
+
+
+
+Internet Engineering Task Force                                 [Page 7]
+
+
+
+
+RFC1123                       INTRODUCTION                  October 1989
+
+
+         for misbehaving hosts"; host software should be prepared, not
+         just to survive other misbehaving hosts, but also to cooperate
+         to limit the amount of disruption such hosts can cause to the
+         shared communication facility.
+
+      1.2.3  Error Logging
+
+         The Internet includes a great variety of host and gateway
+         systems, each implementing many protocols and protocol layers,
+         and some of these contain bugs and mis-features in their
+         Internet protocol software.  As a result of complexity,
+         diversity, and distribution of function, the diagnosis of user
+         problems is often very difficult.
+
+         Problem diagnosis will be aided if host implementations include
+         a carefully designed facility for logging erroneous or
+         "strange" protocol events.  It is important to include as much
+         diagnostic information as possible when an error is logged.  In
+         particular, it is often useful to record the header(s) of a
+         packet that caused an error.  However, care must be taken to
+         ensure that error logging does not consume prohibitive amounts
+         of resources or otherwise interfere with the operation of the
+         host.
+
+         There is a tendency for abnormal but harmless protocol events
+         to overflow error logging files; this can be avoided by using a
+         "circular" log, or by enabling logging only while diagnosing a
+         known failure.  It may be useful to filter and count duplicate
+         successive messages.  One strategy that seems to work well is:
+         (1) always count abnormalities and make such counts accessible
+         through the management protocol (see Section 6.3); and (2)
+         allow the logging of a great variety of events to be
+         selectively enabled.  For example, it might useful to be able
+         to "log everything" or to "log everything for host X".
+
+         Note that different managements may have differing policies
+         about the amount of error logging that they want normally
+         enabled in a host.  Some will say, "if it doesn't hurt me, I
+         don't want to know about it", while others will want to take a
+         more watchful and aggressive attitude about detecting and
+         removing protocol abnormalities.
+
+      1.2.4  Configuration
+
+         It would be ideal if a host implementation of the Internet
+         protocol suite could be entirely self-configuring.  This would
+         allow the whole suite to be implemented in ROM or cast into
+         silicon, it would simplify diskless workstations, and it would
+
+
+
+Internet Engineering Task Force                                 [Page 8]
+
+
+
+
+RFC1123                       INTRODUCTION                  October 1989
+
+
+         be an immense boon to harried LAN administrators as well as
+         system vendors.  We have not reached this ideal; in fact, we
+         are not even close.
+
+         At many points in this document, you will find a requirement
+         that a parameter be a configurable option.  There are several
+         different reasons behind such requirements.  In a few cases,
+         there is current uncertainty or disagreement about the best
+         value, and it may be necessary to update the recommended value
+         in the future.  In other cases, the value really depends on
+         external factors -- e.g., the size of the host and the
+         distribution of its communication load, or the speeds and
+         topology of nearby networks -- and self-tuning algorithms are
+         unavailable and may be insufficient.  In some cases,
+         configurability is needed because of administrative
+         requirements.
+
+         Finally, some configuration options are required to communicate
+         with obsolete or incorrect implementations of the protocols,
+         distributed without sources, that unfortunately persist in many
+         parts of the Internet.  To make correct systems coexist with
+         these faulty systems, administrators often have to "mis-
+         configure" the correct systems.  This problem will correct
+         itself gradually as the faulty systems are retired, but it
+         cannot be ignored by vendors.
+
+         When we say that a parameter must be configurable, we do not
+         intend to require that its value be explicitly read from a
+         configuration file at every boot time.  We recommend that
+         implementors set up a default for each parameter, so a
+         configuration file is only necessary to override those defaults
+         that are inappropriate in a particular installation.  Thus, the
+         configurability requirement is an assurance that it will be
+         POSSIBLE to override the default when necessary, even in a
+         binary-only or ROM-based product.
+
+         This document requires a particular value for such defaults in
+         some cases.  The choice of default is a sensitive issue when
+         the configuration item controls the accommodation to existing
+         faulty systems.  If the Internet is to converge successfully to
+         complete interoperability, the default values built into
+         implementations must implement the official protocol, not
+         "mis-configurations" to accommodate faulty implementations.
+         Although marketing considerations have led some vendors to
+         choose mis-configuration defaults, we urge vendors to choose
+         defaults that will conform to the standard.
+
+         Finally, we note that a vendor needs to provide adequate
+
+
+
+Internet Engineering Task Force                                 [Page 9]
+
+
+
+
+RFC1123                       INTRODUCTION                  October 1989
+
+
+         documentation on all configuration parameters, their limits and
+         effects.
+
+
+   1.3  Reading this Document
+
+      1.3.1  Organization
+
+         In general, each major section is organized into the following
+         subsections:
+
+         (1)  Introduction
+
+         (2)  Protocol Walk-Through -- considers the protocol
+              specification documents section-by-section, correcting
+              errors, stating requirements that may be ambiguous or
+              ill-defined, and providing further clarification or
+              explanation.
+
+         (3)  Specific Issues -- discusses protocol design and
+              implementation issues that were not included in the walk-
+              through.
+
+         (4)  Interfaces -- discusses the service interface to the next
+              higher layer.
+
+         (5)  Summary -- contains a summary of the requirements of the
+              section.
+
+         Under many of the individual topics in this document, there is
+         parenthetical material labeled "DISCUSSION" or
+         "IMPLEMENTATION".  This material is intended to give
+         clarification and explanation of the preceding requirements
+         text.  It also includes some suggestions on possible future
+         directions or developments.  The implementation material
+         contains suggested approaches that an implementor may want to
+         consider.
+
+         The summary sections are intended to be guides and indexes to
+         the text, but are necessarily cryptic and incomplete.  The
+         summaries should never be used or referenced separately from
+         the complete RFC.
+
+      1.3.2  Requirements
+
+         In this document, the words that are used to define the
+         significance of each particular requirement are capitalized.
+         These words are:
+
+
+
+Internet Engineering Task Force                                [Page 10]
+
+
+
+
+RFC1123                       INTRODUCTION                  October 1989
+
+
+         *    "MUST"
+
+              This word or the adjective "REQUIRED" means that the item
+              is an absolute requirement of the specification.
+
+         *    "SHOULD"
+
+              This word or the adjective "RECOMMENDED" means that there
+              may exist valid reasons in particular circumstances to
+              ignore this item, but the full implications should be
+              understood and the case carefully weighed before choosing
+              a different course.
+
+         *    "MAY"
+
+              This word or the adjective "OPTIONAL" means that this item
+              is truly optional.  One vendor may choose to include the
+              item because a particular marketplace requires it or
+              because it enhances the product, for example; another
+              vendor may omit the same item.
+
+
+         An implementation is not compliant if it fails to satisfy one
+         or more of the MUST requirements for the protocols it
+         implements.  An implementation that satisfies all the MUST and
+         all the SHOULD requirements for its protocols is said to be
+         "unconditionally compliant"; one that satisfies all the MUST
+         requirements but not all the SHOULD requirements for its
+         protocols is said to be "conditionally compliant".
+
+      1.3.3  Terminology
+
+         This document uses the following technical terms:
+
+         Segment
+              A segment is the unit of end-to-end transmission in the
+              TCP protocol.  A segment consists of a TCP header followed
+              by application data.  A segment is transmitted by
+              encapsulation in an IP datagram.
+
+         Message
+              This term is used by some application layer protocols
+              (particularly SMTP) for an application data unit.
+
+         Datagram
+              A [UDP] datagram is the unit of end-to-end transmission in
+              the UDP protocol.
+
+
+
+
+Internet Engineering Task Force                                [Page 11]
+
+
+
+
+RFC1123                       INTRODUCTION                  October 1989
+
+
+         Multihomed
+              A host is said to be multihomed if it has multiple IP
+              addresses to connected networks.
+
+
+
+   1.4  Acknowledgments
+
+      This document incorporates contributions and comments from a large
+      group of Internet protocol experts, including representatives of
+      university and research labs, vendors, and government agencies.
+      It was assembled primarily by the Host Requirements Working Group
+      of the Internet Engineering Task Force (IETF).
+
+      The Editor would especially like to acknowledge the tireless
+      dedication of the following people, who attended many long
+      meetings and generated 3 million bytes of electronic mail over the
+      past 18 months in pursuit of this document: Philip Almquist, Dave
+      Borman (Cray Research), Noel Chiappa, Dave Crocker (DEC), Steve
+      Deering (Stanford), Mike Karels (Berkeley), Phil Karn (Bellcore),
+      John Lekashman (NASA), Charles Lynn (BBN), Keith McCloghrie (TWG),
+      Paul Mockapetris (ISI), Thomas Narten (Purdue), Craig Partridge
+      (BBN), Drew Perkins (CMU), and James Van Bokkelen (FTP Software).
+
+      In addition, the following people made major contributions to the
+      effort: Bill Barns (Mitre), Steve Bellovin (AT&T), Mike Brescia
+      (BBN), Ed Cain (DCA), Annette DeSchon (ISI), Martin Gross (DCA),
+      Phill Gross (NRI), Charles Hedrick (Rutgers), Van Jacobson (LBL),
+      John Klensin (MIT), Mark Lottor (SRI), Milo Medin (NASA), Bill
+      Melohn (Sun Microsystems), Greg Minshall (Kinetics), Jeff Mogul
+      (DEC), John Mullen (CMC), Jon Postel (ISI), John Romkey (Epilogue
+      Technology), and Mike StJohns (DCA).  The following also made
+      significant contributions to particular areas: Eric Allman
+      (Berkeley), Rob Austein (MIT), Art Berggreen (ACC), Keith Bostic
+      (Berkeley), Vint Cerf (NRI), Wayne Hathaway (NASA), Matt Korn
+      (IBM), Erik Naggum (Naggum Software, Norway), Robert Ullmann
+      (Prime Computer), David Waitzman (BBN), Frank Wancho (USA), Arun
+      Welch (Ohio State), Bill Westfield (Cisco), and Rayan Zachariassen
+      (Toronto).
+
+      We are grateful to all, including any contributors who may have
+      been inadvertently omitted from this list.
+
+
+
+
+
+
+
+
+
+Internet Engineering Task Force                                [Page 12]
+
+
+
+
+RFC1123              APPLICATIONS LAYER -- GENERAL          October 1989
+
+
+2.  GENERAL ISSUES
+
+   This section contains general requirements that may be applicable to
+   all application-layer protocols.
+
+   2.1  Host Names and Numbers
+
+      The syntax of a legal Internet host name was specified in RFC-952
+      [DNS:4].  One aspect of host name syntax is hereby changed: the
+      restriction on the first character is relaxed to allow either a
+      letter or a digit.  Host software MUST support this more liberal
+      syntax.
+
+      Host software MUST handle host names of up to 63 characters and
+      SHOULD handle host names of up to 255 characters.
+
+      Whenever a user inputs the identity of an Internet host, it SHOULD
+      be possible to enter either (1) a host domain name or (2) an IP
+      address in dotted-decimal ("#.#.#.#") form.  The host SHOULD check
+      the string syntactically for a dotted-decimal number before
+      looking it up in the Domain Name System.
+
+      DISCUSSION:
+           This last requirement is not intended to specify the complete
+           syntactic form for entering a dotted-decimal host number;
+           that is considered to be a user-interface issue.  For
+           example, a dotted-decimal number must be enclosed within
+           "[ ]" brackets for SMTP mail (see Section 5.2.17).  This
+           notation could be made universal within a host system,
+           simplifying the syntactic checking for a dotted-decimal
+           number.
+
+           If a dotted-decimal number can be entered without such
+           identifying delimiters, then a full syntactic check must be
+           made, because a segment of a host domain name is now allowed
+           to begin with a digit and could legally be entirely numeric
+           (see Section 6.1.2.4).  However, a valid host name can never
+           have the dotted-decimal form #.#.#.#, since at least the
+           highest-level component label will be alphabetic.
+
+   2.2  Using Domain Name Service
+
+      Host domain names MUST be translated to IP addresses as described
+      in Section 6.1.
+
+      Applications using domain name services MUST be able to cope with
+      soft error conditions.  Applications MUST wait a reasonable
+      interval between successive retries due to a soft error, and MUST
+
+
+
+Internet Engineering Task Force                                [Page 13]
+
+
+
+
+RFC1123              APPLICATIONS LAYER -- GENERAL          October 1989
+
+
+      allow for the possibility that network problems may deny service
+      for hours or even days.
+
+      An application SHOULD NOT rely on the ability to locate a WKS
+      record containing an accurate listing of all services at a
+      particular host address, since the WKS RR type is not often used
+      by Internet sites.  To confirm that a service is present, simply
+      attempt to use it.
+
+   2.3  Applications on Multihomed hosts
+
+      When the remote host is multihomed, the name-to-address
+      translation will return a list of alternative IP addresses.  As
+      specified in Section 6.1.3.4, this list should be in order of
+      decreasing preference.  Application protocol implementations
+      SHOULD be prepared to try multiple addresses from the list until
+      success is obtained.  More specific requirements for SMTP are
+      given in Section 5.3.4.
+
+      When the local host is multihomed, a UDP-based request/response
+      application SHOULD send the response with an IP source address
+      that is the same as the specific destination address of the UDP
+      request datagram.  The "specific destination address" is defined
+      in the "IP Addressing" section of the companion RFC [INTRO:1].
+
+      Similarly, a server application that opens multiple TCP
+      connections to the same client SHOULD use the same local IP
+      address for all.
+
+   2.4  Type-of-Service
+
+      Applications MUST select appropriate TOS values when they invoke
+      transport layer services, and these values MUST be configurable.
+      Note that a TOS value contains 5 bits, of which only the most-
+      significant 3 bits are currently defined; the other two bits MUST
+      be zero.
+
+      DISCUSSION:
+           As gateway algorithms are developed to implement Type-of-
+           Service, the recommended values for various application
+           protocols may change.  In addition, it is likely that
+           particular combinations of users and Internet paths will want
+           non-standard TOS values.  For these reasons, the TOS values
+           must be configurable.
+
+           See the latest version of the "Assigned Numbers" RFC
+           [INTRO:5] for the recommended TOS values for the major
+           application protocols.
+
+
+
+Internet Engineering Task Force                                [Page 14]
+
+
+
+
+RFC1123              APPLICATIONS LAYER -- GENERAL          October 1989
+
+
+   2.5  GENERAL APPLICATION REQUIREMENTS SUMMARY
+
+                                               |          | | | |S| |
+                                               |          | | | |H| |F
+                                               |          | | | |O|M|o
+                                               |          | |S| |U|U|o
+                                               |          | |H| |L|S|t
+                                               |          |M|O| |D|T|n
+                                               |          |U|U|M| | |o
+                                               |          |S|L|A|N|N|t
+                                               |          |T|D|Y|O|O|t
+FEATURE                                        |SECTION   | | | |T|T|e
+-----------------------------------------------|----------|-|-|-|-|-|--
+                                               |          | | | | | |
+User interfaces:                               |          | | | | | |
+  Allow host name to begin with digit          |2.1       |x| | | | |
+  Host names of up to 635 characters           |2.1       |x| | | | |
+  Host names of up to 255 characters           |2.1       | |x| | | |
+  Support dotted-decimal host numbers          |2.1       | |x| | | |
+  Check syntactically for dotted-dec first     |2.1       | |x| | | |
+                                               |          | | | | | |
+Map domain names per Section 6.1               |2.2       |x| | | | |
+Cope with soft DNS errors                      |2.2       |x| | | | |
+   Reasonable interval between retries         |2.2       |x| | | | |
+   Allow for long outages                      |2.2       |x| | | | |
+Expect WKS records to be available             |2.2       | | | |x| |
+                                               |          | | | | | |
+Try multiple addr's for remote multihomed host |2.3       | |x| | | |
+UDP reply src addr is specific dest of request |2.3       | |x| | | |
+Use same IP addr for related TCP connections   |2.3       | |x| | | |
+Specify appropriate TOS values                 |2.4       |x| | | | |
+  TOS values configurable                      |2.4       |x| | | | |
+  Unused TOS bits zero                         |2.4       |x| | | | |
+                                               |          | | | | | |
+                                               |          | | | | | |
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Internet Engineering Task Force                                [Page 15]
+
+
+
+
+RFC1123                  REMOTE LOGIN -- TELNET             October 1989
+
+
+3.  REMOTE LOGIN -- TELNET PROTOCOL
+
+   3.1  INTRODUCTION
+
+      Telnet is the standard Internet application protocol for remote
+      login.  It provides the encoding rules to link a user's
+      keyboard/display on a client ("user") system with a command
+      interpreter on a remote server system.  A subset of the Telnet
+      protocol is also incorporated within other application protocols,
+      e.g., FTP and SMTP.
+
+      Telnet uses a single TCP connection, and its normal data stream
+      ("Network Virtual Terminal" or "NVT" mode) is 7-bit ASCII with
+      escape sequences to embed control functions.  Telnet also allows
+      the negotiation of many optional modes and functions.
+
+      The primary Telnet specification is to be found in RFC-854
+      [TELNET:1], while the options are defined in many other RFCs; see
+      Section 7 for references.
+
+   3.2  PROTOCOL WALK-THROUGH
+
+      3.2.1  Option Negotiation: RFC-854, pp. 2-3
+
+         Every Telnet implementation MUST include option negotiation and
+         subnegotiation machinery [TELNET:2].
+
+         A host MUST carefully follow the rules of RFC-854 to avoid
+         option-negotiation loops.  A host MUST refuse (i.e, reply
+         WONT/DONT to a DO/WILL) an unsupported option.  Option
+         negotiation SHOULD continue to function (even if all requests
+         are refused) throughout the lifetime of a Telnet connection.
+
+         If all option negotiations fail, a Telnet implementation MUST
+         default to, and support, an NVT.
+
+         DISCUSSION:
+              Even though more sophisticated "terminals" and supporting
+              option negotiations are becoming the norm, all
+              implementations must be prepared to support an NVT for any
+              user-server communication.
+
+      3.2.2  Telnet Go-Ahead Function: RFC-854, p. 5, and RFC-858
+
+         On a host that never sends the Telnet command Go Ahead (GA),
+         the Telnet Server MUST attempt to negotiate the Suppress Go
+         Ahead option (i.e., send "WILL Suppress Go Ahead").  A User or
+         Server Telnet MUST always accept negotiation of the Suppress Go
+
+
+
+Internet Engineering Task Force                                [Page 16]
+
+
+
+
+RFC1123                  REMOTE LOGIN -- TELNET             October 1989
+
+
+         Ahead option.
+
+         When it is driving a full-duplex terminal for which GA has no
+         meaning, a User Telnet implementation MAY ignore GA commands.
+
+         DISCUSSION:
+              Half-duplex ("locked-keyboard") line-at-a-time terminals
+              for which the Go-Ahead mechanism was designed have largely
+              disappeared from the scene.  It turned out to be difficult
+              to implement sending the Go-Ahead signal in many operating
+              systems, even some systems that support native half-duplex
+              terminals.  The difficulty is typically that the Telnet
+              server code does not have access to information about
+              whether the user process is blocked awaiting input from
+              the Telnet connection, i.e., it cannot reliably determine
+              when to send a GA command.  Therefore, most Telnet Server
+              hosts do not send GA commands.
+
+              The effect of the rules in this section is to allow either
+              end of a Telnet connection to veto the use of GA commands.
+
+              There is a class of half-duplex terminals that is still
+              commercially important: "data entry terminals," which
+              interact in a full-screen manner.  However, supporting
+              data entry terminals using the Telnet protocol does not
+              require the Go Ahead signal; see Section 3.3.2.
+
+      3.2.3  Control Functions: RFC-854, pp. 7-8
+
+         The list of Telnet commands has been extended to include EOR
+         (End-of-Record), with code 239 [TELNET:9].
+
+         Both User and Server Telnets MAY support the control functions
+         EOR, EC, EL, and Break, and MUST support AO, AYT, DM, IP, NOP,
+         SB, and SE.
+
+         A host MUST be able to receive and ignore any Telnet control
+         functions that it does not support.
+
+         DISCUSSION:
+              Note that a Server Telnet is required to support the
+              Telnet IP (Interrupt Process) function, even if the server
+              host has an equivalent in-stream function (e.g., Control-C
+              in many systems).  The Telnet IP function may be stronger
+              than an in-stream interrupt command, because of the out-
+              of-band effect of TCP urgent data.
+
+              The EOR control function may be used to delimit the
+
+
+
+Internet Engineering Task Force                                [Page 17]
+
+
+
+
+RFC1123                  REMOTE LOGIN -- TELNET             October 1989
+
+
+              stream.  An important application is data entry terminal
+              support (see Section 3.3.2).  There was concern that since
+              EOR had not been defined in RFC-854, a host that was not
+              prepared to correctly ignore unknown Telnet commands might
+              crash if it received an EOR.  To protect such hosts, the
+              End-of-Record option [TELNET:9] was introduced; however, a
+              properly implemented Telnet program will not require this
+              protection.
+
+      3.2.4  Telnet "Synch" Signal: RFC-854, pp. 8-10
+
+         When it receives "urgent" TCP data, a User or Server Telnet
+         MUST discard all data except Telnet commands until the DM (and
+         end of urgent) is reached.
+
+         When it sends Telnet IP (Interrupt Process), a User Telnet
+         SHOULD follow it by the Telnet "Synch" sequence, i.e., send as
+         TCP urgent data the sequence "IAC IP IAC DM".  The TCP urgent
+         pointer points to the DM octet.
+
+         When it receives a Telnet IP command, a Server Telnet MAY send
+         a Telnet "Synch" sequence back to the user, to flush the output
+         stream.  The choice ought to be consistent with the way the
+         server operating system behaves when a local user interrupts a
+         process.
+
+         When it receives a Telnet AO command, a Server Telnet MUST send
+         a Telnet "Synch" sequence back to the user, to flush the output
+         stream.
+
+         A User Telnet SHOULD have the capability of flushing output
+         when it sends a Telnet IP; see also Section 3.4.5.
+
+         DISCUSSION:
+              There are three possible ways for a User Telnet to flush
+              the stream of server output data:
+
+              (1)  Send AO after IP.
+
+                   This will cause the server host to send a "flush-
+                   buffered-output" signal to its operating system.
+                   However, the AO may not take effect locally, i.e.,
+                   stop terminal output at the User Telnet end, until
+                   the Server Telnet has received and processed the AO
+                   and has sent back a "Synch".
+
+              (2)  Send DO TIMING-MARK [TELNET:7] after IP, and discard
+                   all output locally until a WILL/WONT TIMING-MARK is
+
+
+
+Internet Engineering Task Force                                [Page 18]
+
+
+
+
+RFC1123                  REMOTE LOGIN -- TELNET             October 1989
+
+
+                   received from the Server Telnet.
+
+                   Since the DO TIMING-MARK will be processed after the
+                   IP at the server, the reply to it should be in the
+                   right place in the output data stream.  However, the
+                   TIMING-MARK will not send a "flush buffered output"
+                   signal to the server operating system.  Whether or
+                   not this is needed is dependent upon the server
+                   system.
+
+              (3)  Do both.
+
+              The best method is not entirely clear, since it must
+              accommodate a number of existing server hosts that do not
+              follow the Telnet standards in various ways.  The safest
+              approach is probably to provide a user-controllable option
+              to select (1), (2), or (3).
+
+      3.2.5  NVT Printer and Keyboard: RFC-854, p. 11
+
+         In NVT mode, a Telnet SHOULD NOT send characters with the
+         high-order bit 1, and MUST NOT send it as a parity bit.
+         Implementations that pass the high-order bit to applications
+         SHOULD negotiate binary mode (see Section 3.2.6).
+
+
+         DISCUSSION:
+              Implementors should be aware that a strict reading of
+              RFC-854 allows a client or server expecting NVT ASCII to
+              ignore characters with the high-order bit set.  In
+              general, binary mode is expected to be used for
+              transmission of an extended (beyond 7-bit) character set
+              with Telnet.
+
+              However, there exist applications that really need an 8-
+              bit NVT mode, which is currently not defined, and these
+              existing applications do set the high-order bit during
+              part or all of the life of a Telnet connection.  Note that
+              binary mode is not the same as 8-bit NVT mode, since
+              binary mode turns off end-of-line processing.  For this
+              reason, the requirements on the high-order bit are stated
+              as SHOULD, not MUST.
+
+              RFC-854 defines a minimal set of properties of a "network
+              virtual terminal" or NVT; this is not meant to preclude
+              additional features in a real terminal.  A Telnet
+              connection is fully transparent to all 7-bit ASCII
+              characters, including arbitrary ASCII control characters.
+
+
+
+Internet Engineering Task Force                                [Page 19]
+
+
+
+
+RFC1123                  REMOTE LOGIN -- TELNET             October 1989
+
+
+              For example, a terminal might support full-screen commands
+              coded as ASCII escape sequences; a Telnet implementation
+              would pass these sequences as uninterpreted data.  Thus,
+              an NVT should not be conceived as a terminal type of a
+              highly-restricted device.
+
+      3.2.6  Telnet Command Structure: RFC-854, p. 13
+
+         Since options may appear at any point in the data stream, a
+         Telnet escape character (known as IAC, with the value 255) to
+         be sent as data MUST be doubled.
+
+      3.2.7  Telnet Binary Option: RFC-856
+
+         When the Binary option has been successfully negotiated,
+         arbitrary 8-bit characters are allowed.  However, the data
+         stream MUST still be scanned for IAC characters, any embedded
+         Telnet commands MUST be obeyed, and data bytes equal to IAC
+         MUST be doubled.  Other character processing (e.g., replacing
+         CR by CR NUL or by CR LF) MUST NOT be done.  In particular,
+         there is no end-of-line convention (see Section 3.3.1) in
+         binary mode.
+
+         DISCUSSION:
+              The Binary option is normally negotiated in both
+              directions, to change the Telnet connection from NVT mode
+              to "binary mode".
+
+              The sequence IAC EOR can be used to delimit blocks of data
+              within a binary-mode Telnet stream.
+
+      3.2.8  Telnet Terminal-Type Option: RFC-1091
+
+         The Terminal-Type option MUST use the terminal type names
+         officially defined in the Assigned Numbers RFC [INTRO:5], when
+         they are available for the particular terminal.  However, the
+         receiver of a Terminal-Type option MUST accept any name.
+
+         DISCUSSION:
+              RFC-1091 [TELNET:10] updates an earlier version of the
+              Terminal-Type option defined in RFC-930.  The earlier
+              version allowed a server host capable of supporting
+              multiple terminal types to learn the type of a particular
+              client's terminal, assuming that each physical terminal
+              had an intrinsic type.  However, today a "terminal" is
+              often really a terminal emulator program running in a PC,
+              perhaps capable of emulating a range of terminal types.
+              Therefore, RFC-1091 extends the specification to allow a
+
+
+
+Internet Engineering Task Force                                [Page 20]
+
+
+
+
+RFC1123                  REMOTE LOGIN -- TELNET             October 1989
+
+
+              more general terminal-type negotiation between User and
+              Server Telnets.
+
+   3.3  SPECIFIC ISSUES
+
+      3.3.1  Telnet End-of-Line Convention
+
+         The Telnet protocol defines the sequence CR LF to mean "end-
+         of-line".  For terminal input, this corresponds to a command-
+         completion or "end-of-line" key being pressed on a user
+         terminal; on an ASCII terminal, this is the CR key, but it may
+         also be labelled "Return" or "Enter".
+
+         When a Server Telnet receives the Telnet end-of-line sequence
+         CR LF as input from a remote terminal, the effect MUST be the
+         same as if the user had pressed the "end-of-line" key on a
+         local terminal.  On server hosts that use ASCII, in particular,
+         receipt of the Telnet sequence CR LF must cause the same effect
+         as a local user pressing the CR key on a local terminal.  Thus,
+         CR LF and CR NUL MUST have the same effect on an ASCII server
+         host when received as input over a Telnet connection.
+
+         A User Telnet MUST be able to send any of the forms: CR LF, CR
+         NUL, and LF.  A User Telnet on an ASCII host SHOULD have a
+         user-controllable mode to send either CR LF or CR NUL when the
+         user presses the "end-of-line" key, and CR LF SHOULD be the
+         default.
+
+         The Telnet end-of-line sequence CR LF MUST be used to send
+         Telnet data that is not terminal-to-computer (e.g., for Server
+         Telnet sending output, or the Telnet protocol incorporated
+         another application protocol).
+
+         DISCUSSION:
+              To allow interoperability between arbitrary Telnet clients
+              and servers, the Telnet protocol defined a standard
+              representation for a line terminator.  Since the ASCII
+              character set includes no explicit end-of-line character,
+              systems have chosen various representations, e.g., CR, LF,
+              and the sequence CR LF.  The Telnet protocol chose the CR
+              LF sequence as the standard for network transmission.
+
+              Unfortunately, the Telnet protocol specification in RFC-
+              854 [TELNET:1] has turned out to be somewhat ambiguous on
+              what character(s) should be sent from client to server for
+              the "end-of-line" key.  The result has been a massive and
+              continuing interoperability headache, made worse by
+              various faulty implementations of both User and Server
+
+
+
+Internet Engineering Task Force                                [Page 21]
+
+
+
+
+RFC1123                  REMOTE LOGIN -- TELNET             October 1989
+
+
+              Telnets.
+
+              Although the Telnet protocol is based on a perfectly
+              symmetric model, in a remote login session the role of the
+              user at a terminal differs from the role of the server
+              host.  For example, RFC-854 defines the meaning of CR, LF,
+              and CR LF as output from the server, but does not specify
+              what the User Telnet should send when the user presses the
+              "end-of-line" key on the terminal; this turns out to be
+              the point at issue.
+
+              When a user presses the "end-of-line" key, some User
+              Telnet implementations send CR LF, while others send CR
+              NUL (based on a different interpretation of the same
+              sentence in RFC-854).  These will be equivalent for a
+              correctly-implemented ASCII server host, as discussed
+              above.  For other servers, a mode in the User Telnet is
+              needed.
+
+              The existence of User Telnets that send only CR NUL when
+              CR is pressed creates a dilemma for non-ASCII hosts: they
+              can either treat CR NUL as equivalent to CR LF in input,
+              thus precluding the possibility of entering a "bare" CR,
+              or else lose complete interworking.
+
+              Suppose a user on host A uses Telnet to log into a server
+              host B, and then execute B's User Telnet program to log
+              into server host C.  It is desirable for the Server/User
+              Telnet combination on B to be as transparent as possible,
+              i.e., to appear as if A were connected directly to C.  In
+              particular, correct implementation will make B transparent
+              to Telnet end-of-line sequences, except that CR LF may be
+              translated to CR NUL or vice versa.
+
+         IMPLEMENTATION:
+              To understand Telnet end-of-line issues, one must have at
+              least a general model of the relationship of Telnet to the
+              local operating system.  The Server Telnet process is
+              typically coupled into the terminal driver software of the
+              operating system as a pseudo-terminal.  A Telnet end-of-
+              line sequence received by the Server Telnet must have the
+              same effect as pressing the end-of-line key on a real
+              locally-connected terminal.
+
+              Operating systems that support interactive character-at-
+              a-time applications (e.g., editors) typically have two
+              internal modes for their terminal I/O: a formatted mode,
+              in which local conventions for end-of-line and other
+
+
+
+Internet Engineering Task Force                                [Page 22]
+
+
+
+
+RFC1123                  REMOTE LOGIN -- TELNET             October 1989
+
+
+              formatting rules have been applied to the data stream, and
+              a "raw" mode, in which the application has direct access
+              to every character as it was entered.  A Server Telnet
+              must be implemented in such a way that these modes have
+              the same effect for remote as for local terminals.  For
+              example, suppose a CR LF or CR NUL is received by the
+              Server Telnet on an ASCII host.  In raw mode, a CR
+              character is passed to the application; in formatted mode,
+              the local system's end-of-line convention is used.
+
+      3.3.2  Data Entry Terminals
+
+         DISCUSSION:
+              In addition to the line-oriented and character-oriented
+              ASCII terminals for which Telnet was designed, there are
+              several families of video display terminals that are
+              sometimes known as "data entry terminals" or DETs.  The
+              IBM 3270 family is a well-known example.
+
+              Two Internet protocols have been designed to support
+              generic DETs: SUPDUP [TELNET:16, TELNET:17], and the DET
+              option [TELNET:18, TELNET:19].  The DET option drives a
+              data entry terminal over a Telnet connection using (sub-)
+              negotiation.  SUPDUP is a completely separate terminal
+              protocol, which can be entered from Telnet by negotiation.
+              Although both SUPDUP and the DET option have been used
+              successfully in particular environments, neither has
+              gained general acceptance or wide implementation.
+
+              A different approach to DET interaction has been developed
+              for supporting the IBM 3270 family through Telnet,
+              although the same approach would be applicable to any DET.
+              The idea is to enter a "native DET" mode, in which the
+              native DET input/output stream is sent as binary data.
+              The Telnet EOR command is used to delimit logical records
+              (e.g., "screens") within this binary stream.
+
+         IMPLEMENTATION:
+              The rules for entering and leaving native DET mode are as
+              follows:
+
+              o    The Server uses the Terminal-Type option [TELNET:10]
+                   to learn that the client is a DET.
+
+              o    It is conventional, but not required, that both ends
+                   negotiate the EOR option [TELNET:9].
+
+              o    Both ends negotiate the Binary option [TELNET:3] to
+
+
+
+Internet Engineering Task Force                                [Page 23]
+
+
+
+
+RFC1123                  REMOTE LOGIN -- TELNET             October 1989
+
+
+                   enter native DET mode.
+
+              o    When either end negotiates out of binary mode, the
+                   other end does too, and the mode then reverts to
+                   normal NVT.
+
+
+      3.3.3  Option Requirements
+
+         Every Telnet implementation MUST support the Binary option
+         [TELNET:3] and the Suppress Go Ahead option [TELNET:5], and
+         SHOULD support the Echo [TELNET:4], Status [TELNET:6], End-of-
+         Record [TELNET:9], and Extended Options List [TELNET:8]
+         options.
+
+         A User or Server Telnet SHOULD support the Window Size Option
+         [TELNET:12] if the local operating system provides the
+         corresponding capability.
+
+         DISCUSSION:
+              Note that the End-of-Record option only signifies that a
+              Telnet can receive a Telnet EOR without crashing;
+              therefore, every Telnet ought to be willing to accept
+              negotiation of the End-of-Record option.  See also the
+              discussion in Section 3.2.3.
+
+      3.3.4  Option Initiation
+
+         When the Telnet protocol is used in a client/server situation,
+         the server SHOULD initiate negotiation of the terminal
+         interaction mode it expects.
+
+         DISCUSSION:
+              The Telnet protocol was defined to be perfectly
+              symmetrical, but its application is generally asymmetric.
+              Remote login has been known to fail because NEITHER side
+              initiated negotiation of the required non-default terminal
+              modes.  It is generally the server that determines the
+              preferred mode, so the server needs to initiate the
+              negotiation; since the negotiation is symmetric, the user
+              can also initiate it.
+
+         A client (User Telnet) SHOULD provide a means for users to
+         enable and disable the initiation of option negotiation.
+
+         DISCUSSION:
+              A user sometimes needs to connect to an application
+              service (e.g., FTP or SMTP) that uses Telnet for its
+
+
+
+Internet Engineering Task Force                                [Page 24]
+
+
+
+
+RFC1123                  REMOTE LOGIN -- TELNET             October 1989
+
+
+              control stream but does not support Telnet options.  User
+              Telnet may be used for this purpose if initiation of
+              option negotiation is  disabled.
+
+      3.3.5  Telnet Linemode Option
+
+         DISCUSSION:
+              An important new Telnet option, LINEMODE [TELNET:12], has
+              been proposed.  The LINEMODE option provides a standard
+              way for a User Telnet and a Server Telnet to agree that
+              the client rather than the server will perform terminal
+              character processing.  When the client has prepared a
+              complete line of text, it will send it to the server in
+              (usually) one TCP packet.  This option will greatly
+              decrease the packet cost of Telnet sessions and will also
+              give much better user response over congested or long-
+              delay networks.
+
+              The LINEMODE option allows dynamic switching between local
+              and remote character processing.  For example, the Telnet
+              connection will automatically negotiate into single-
+              character mode while a full screen editor is running, and
+              then return to linemode when the editor is finished.
+
+              We expect that when this RFC is released, hosts should
+              implement the client side of this option, and may
+              implement the server side of this option.  To properly
+              implement the server side, the server needs to be able to
+              tell the local system not to do any input character
+              processing, but to remember its current terminal state and
+              notify the Server Telnet process whenever the state
+              changes.  This will allow password echoing and full screen
+              editors to be handled properly, for example.
+
+   3.4  TELNET/USER INTERFACE
+
+      3.4.1  Character Set Transparency
+
+         User Telnet implementations SHOULD be able to send or receive
+         any 7-bit ASCII character.  Where possible, any special
+         character interpretations by the user host's operating system
+         SHOULD be bypassed so that these characters can conveniently be
+         sent and received on the connection.
+
+         Some character value MUST be reserved as "escape to command
+         mode"; conventionally, doubling this character allows it to be
+         entered as data.  The specific character used SHOULD be user
+         selectable.
+
+
+
+Internet Engineering Task Force                                [Page 25]
+
+
+
+
+RFC1123                  REMOTE LOGIN -- TELNET             October 1989
+
+
+         On binary-mode connections, a User Telnet program MAY provide
+         an escape mechanism for entering arbitrary 8-bit values, if the
+         host operating system doesn't allow them to be entered directly
+         from the keyboard.
+
+         IMPLEMENTATION:
+              The transparency issues are less pressing on servers, but
+              implementors should take care in dealing with issues like:
+              masking off parity bits (sent by an older, non-conforming
+              client) before they reach programs that expect only NVT
+              ASCII, and properly handling programs that request 8-bit
+              data streams.
+
+      3.4.2  Telnet Commands
+
+         A User Telnet program MUST provide a user the capability of
+         entering any of the Telnet control functions IP, AO, or AYT,
+         and SHOULD provide the capability of entering EC, EL, and
+         Break.
+
+      3.4.3  TCP Connection Errors
+
+         A User Telnet program SHOULD report to the user any TCP errors
+         that are reported by the transport layer (see "TCP/Application
+         Layer Interface" section in [INTRO:1]).
+
+      3.4.4  Non-Default Telnet Contact Port
+
+         A User Telnet program SHOULD allow the user to optionally
+         specify a non-standard contact port number at the Server Telnet
+         host.
+
+      3.4.5  Flushing Output
+
+         A User Telnet program SHOULD provide the user the ability to
+         specify whether or not output should be flushed when an IP is
+         sent; see Section 3.2.4.
+
+         For any output flushing scheme that causes the User Telnet to
+         flush output locally until a Telnet signal is received from the
+         Server, there SHOULD be a way for the user to manually restore
+         normal output, in case the Server fails to send the expected
+         signal.
+
+
+
+
+
+
+
+
+Internet Engineering Task Force                                [Page 26]
+
+
+
+
+RFC1123                  REMOTE LOGIN -- TELNET             October 1989
+
+
+   3.5.  TELNET REQUIREMENTS SUMMARY
+
+
+                                                 |        | | | |S| |
+                                                 |        | | | |H| |F
+                                                 |        | | | |O|M|o
+                                                 |        | |S| |U|U|o
+                                                 |        | |H| |L|S|t
+                                                 |        |M|O| |D|T|n
+                                                 |        |U|U|M| | |o
+                                                 |        |S|L|A|N|N|t
+                                                 |        |T|D|Y|O|O|t
+FEATURE                                          |SECTION | | | |T|T|e
+-------------------------------------------------|--------|-|-|-|-|-|--
+                                                 |        | | | | | |
+Option Negotiation                               |3.2.1   |x| | | | |
+  Avoid negotiation loops                        |3.2.1   |x| | | | |
+  Refuse unsupported options                     |3.2.1   |x| | | | |
+  Negotiation OK anytime on connection           |3.2.1   | |x| | | |
+  Default to NVT                                 |3.2.1   |x| | | | |
+  Send official name in Term-Type option         |3.2.8   |x| | | | |
+  Accept any name in Term-Type option            |3.2.8   |x| | | | |
+  Implement Binary, Suppress-GA options          |3.3.3   |x| | | | |
+  Echo, Status, EOL, Ext-Opt-List options        |3.3.3   | |x| | | |
+  Implement Window-Size option if appropriate    |3.3.3   | |x| | | |
+  Server initiate mode negotiations              |3.3.4   | |x| | | |
+  User can enable/disable init negotiations      |3.3.4   | |x| | | |
+                                                 |        | | | | | |
+Go-Aheads                                        |        | | | | | |
+  Non-GA server negotiate SUPPRESS-GA option     |3.2.2   |x| | | | |
+  User or Server accept SUPPRESS-GA option       |3.2.2   |x| | | | |
+  User Telnet ignore GA's                        |3.2.2   | | |x| | |
+                                                 |        | | | | | |
+Control Functions                                |        | | | | | |
+  Support SE NOP DM IP AO AYT SB                 |3.2.3   |x| | | | |
+  Support EOR EC EL Break                        |3.2.3   | | |x| | |
+  Ignore unsupported control functions           |3.2.3   |x| | | | |
+  User, Server discard urgent data up to DM      |3.2.4   |x| | | | |
+  User Telnet send "Synch" after IP, AO, AYT     |3.2.4   | |x| | | |
+  Server Telnet reply Synch to IP                |3.2.4   | | |x| | |
+  Server Telnet reply Synch to AO                |3.2.4   |x| | | | |
+  User Telnet can flush output when send IP      |3.2.4   | |x| | | |
+                                                 |        | | | | | |
+Encoding                                         |        | | | | | |
+  Send high-order bit in NVT mode                |3.2.5   | | | |x| |
+  Send high-order bit as parity bit              |3.2.5   | | | | |x|
+  Negot. BINARY if pass high-ord. bit to applic  |3.2.5   | |x| | | |
+  Always double IAC data byte                    |3.2.6   |x| | | | |
+
+
+
+Internet Engineering Task Force                                [Page 27]
+
+
+
+
+RFC1123                  REMOTE LOGIN -- TELNET             October 1989
+
+
+  Double IAC data byte in binary mode            |3.2.7   |x| | | | |
+  Obey Telnet cmds in binary mode                |3.2.7   |x| | | | |
+  End-of-line, CR NUL in binary mode             |3.2.7   | | | | |x|
+                                                 |        | | | | | |
+End-of-Line                                      |        | | | | | |
+  EOL at Server same as local end-of-line        |3.3.1   |x| | | | |
+  ASCII Server accept CR LF or CR NUL for EOL    |3.3.1   |x| | | | |
+  User Telnet able to send CR LF, CR NUL, or LF  |3.3.1   |x| | | | |
+    ASCII user able to select CR LF/CR NUL       |3.3.1   | |x| | | |
+    User Telnet default mode is CR LF            |3.3.1   | |x| | | |
+  Non-interactive uses CR LF for EOL             |3.3.1   |x| | | | |
+                                                 |        | | | | | |
+User Telnet interface                            |        | | | | | |
+  Input & output all 7-bit characters            |3.4.1   | |x| | | |
+  Bypass local op sys interpretation             |3.4.1   | |x| | | |
+  Escape character                               |3.4.1   |x| | | | |
+     User-settable escape character              |3.4.1   | |x| | | |
+  Escape to enter 8-bit values                   |3.4.1   | | |x| | |
+  Can input IP, AO, AYT                          |3.4.2   |x| | | | |
+  Can input EC, EL, Break                        |3.4.2   | |x| | | |
+  Report TCP connection errors to user           |3.4.3   | |x| | | |
+  Optional non-default contact port              |3.4.4   | |x| | | |
+  Can spec: output flushed when IP sent          |3.4.5   | |x| | | |
+  Can manually restore output mode               |3.4.5   | |x| | | |
+                                                 |        | | | | | |
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Internet Engineering Task Force                                [Page 28]
+
+
+
+
+RFC1123                   FILE TRANSFER -- FTP              October 1989
+
+
+4.  FILE TRANSFER
+
+   4.1  FILE TRANSFER PROTOCOL -- FTP
+
+      4.1.1  INTRODUCTION
+
+         The File Transfer Protocol FTP is the primary Internet standard
+         for file transfer.  The current specification is contained in
+         RFC-959 [FTP:1].
+
+         FTP uses separate simultaneous TCP connections for control and
+         for data transfer.  The FTP protocol includes many features,
+         some of which are not commonly implemented.  However, for every
+         feature in FTP, there exists at least one implementation.  The
+         minimum implementation defined in RFC-959 was too small, so a
+         somewhat larger minimum implementation is defined here.
+
+         Internet users have been unnecessarily burdened for years by
+         deficient FTP implementations.  Protocol implementors have
+         suffered from the erroneous opinion that implementing FTP ought
+         to be a small and trivial task.  This is wrong, because FTP has
+         a user interface, because it has to deal (correctly) with the
+         whole variety of communication and operating system errors that
+         may occur, and because it has to handle the great diversity of
+         real file systems in the world.
+
+      4.1.2.  PROTOCOL WALK-THROUGH
+
+         4.1.2.1  LOCAL Type: RFC-959 Section 3.1.1.4
+
+            An FTP program MUST support TYPE I ("IMAGE" or binary type)
+            as well as TYPE L 8 ("LOCAL" type with logical byte size 8).
+            A machine whose memory is organized into m-bit words, where
+            m is not a multiple of 8, MAY also support TYPE L m.
+
+            DISCUSSION:
+                 The command "TYPE L 8" is often required to transfer
+                 binary data between a machine whose memory is organized
+                 into (e.g.) 36-bit words and a machine with an 8-bit
+                 byte organization.  For an 8-bit byte machine, TYPE L 8
+                 is equivalent to IMAGE.
+
+                 "TYPE L m" is sometimes specified to the FTP programs
+                 on two m-bit word machines to ensure the correct
+                 transfer of a native-mode binary file from one machine
+                 to the other.  However, this command should have the
+                 same effect on these machines as "TYPE I".
+
+
+
+
+Internet Engineering Task Force                                [Page 29]
+
+
+
+
+RFC1123                   FILE TRANSFER -- FTP              October 1989
+
+
+         4.1.2.2  Telnet Format Control: RFC-959 Section 3.1.1.5.2
+
+            A host that makes no distinction between TYPE N and TYPE T
+            SHOULD implement TYPE T to be identical to TYPE N.
+
+            DISCUSSION:
+                 This provision should ease interoperation with hosts
+                 that do make this distinction.
+
+                 Many hosts represent text files internally as strings
+                 of ASCII characters, using the embedded ASCII format
+                 effector characters (LF, BS, FF, ...) to control the
+                 format when a file is printed.  For such hosts, there
+                 is no distinction between "print" files and other
+                 files.  However, systems that use record structured
+                 files typically need a special format for printable
+                 files (e.g., ASA carriage control).   For the latter
+                 hosts, FTP allows a choice of TYPE N or TYPE T.
+
+         4.1.2.3  Page Structure: RFC-959 Section 3.1.2.3 and Appendix I
+
+            Implementation of page structure is NOT RECOMMENDED in
+            general. However, if a host system does need to implement
+            FTP for "random access" or "holey" files, it MUST use the
+            defined page structure format rather than define a new
+            private FTP format.
+
+         4.1.2.4  Data Structure Transformations: RFC-959 Section 3.1.2
+
+            An FTP transformation between record-structure and file-
+            structure SHOULD be invertible, to the extent possible while
+            making the result useful on the target host.
+
+            DISCUSSION:
+                 RFC-959 required strict invertibility between record-
+                 structure and file-structure, but in practice,
+                 efficiency and convenience often preclude it.
+                 Therefore, the requirement is being relaxed.  There are
+                 two different objectives for transferring a file:
+                 processing it on the target host, or just storage.  For
+                 storage, strict invertibility is important.  For
+                 processing, the file created on the target host needs
+                 to be in the format expected by application programs on
+                 that host.
+
+                 As an example of the conflict, imagine a record-
+                 oriented operating system that requires some data files
+                 to have exactly 80 bytes in each record.  While STORing
+
+
+
+Internet Engineering Task Force                                [Page 30]
+
+
+
+
+RFC1123                   FILE TRANSFER -- FTP              October 1989
+
+
+                 a file on such a host, an FTP Server must be able to
+                 pad each line or record to 80 bytes; a later retrieval
+                 of such a file cannot be strictly invertible.
+
+         4.1.2.5  Data Connection Management: RFC-959 Section 3.3
+
+            A User-FTP that uses STREAM mode SHOULD send a PORT command
+            to assign a non-default data port before each transfer
+            command is issued.
+
+            DISCUSSION:
+                 This is required because of the long delay after a TCP
+                 connection is closed until its socket pair can be
+                 reused, to allow multiple transfers during a single FTP
+                 session.  Sending a port command can avoided if a
+                 transfer mode other than stream is used, by leaving the
+                 data transfer connection open between transfers.
+
+         4.1.2.6  PASV Command: RFC-959 Section 4.1.2
+
+            A server-FTP MUST implement the PASV command.
+
+            If multiple third-party transfers are to be executed during
+            the same session, a new PASV command MUST be issued before
+            each transfer command, to obtain a unique port pair.
+
+            IMPLEMENTATION:
+                 The format of the 227 reply to a PASV command is not
+                 well standardized.  In particular, an FTP client cannot
+                 assume that the parentheses shown on page 40 of RFC-959
+                 will be present (and in fact, Figure 3 on page 43 omits
+                 them).  Therefore, a User-FTP program that interprets
+                 the PASV reply must scan the reply for the first digit
+                 of the host and port numbers.
+
+                 Note that the host number h1,h2,h3,h4 is the IP address
+                 of the server host that is sending the reply, and that
+                 p1,p2 is a non-default data transfer port that PASV has
+                 assigned.
+
+         4.1.2.7  LIST and NLST Commands: RFC-959 Section 4.1.3
+
+            The data returned by an NLST command MUST contain only a
+            simple list of legal pathnames, such that the server can use
+            them directly as the arguments of subsequent data transfer
+            commands for the individual files.
+
+            The data returned by a LIST or NLST command SHOULD use an
+
+
+
+Internet Engineering Task Force                                [Page 31]
+
+
+
+
+RFC1123                   FILE TRANSFER -- FTP              October 1989
+
+
+            implied TYPE AN, unless the current type is EBCDIC, in which
+            case an implied TYPE EN SHOULD be used.
+
+            DISCUSSION:
+                 Many FTP clients support macro-commands that will get
+                 or put files matching a wildcard specification, using
+                 NLST to obtain a list of pathnames.  The expansion of
+                 "multiple-put" is local to the client, but "multiple-
+                 get" requires cooperation by the server.
+
+                 The implied type for LIST and NLST is designed to
+                 provide compatibility with existing User-FTPs, and in
+                 particular with multiple-get commands.
+
+         4.1.2.8  SITE Command: RFC-959 Section 4.1.3
+
+            A Server-FTP SHOULD use the SITE command for non-standard
+            features, rather than invent new private commands or
+            unstandardized extensions to existing commands.
+
+         4.1.2.9  STOU Command: RFC-959 Section 4.1.3
+
+            The STOU command stores into a uniquely named file.  When it
+            receives an STOU command, a Server-FTP MUST return the
+            actual file name in the "125 Transfer Starting" or the "150
+            Opening Data Connection" message that precedes the transfer
+            (the 250 reply code mentioned in RFC-959 is incorrect).  The
+            exact format of these messages is hereby defined to be as
+            follows:
+
+                125 FILE: pppp
+                150 FILE: pppp
+
+            where pppp represents the unique pathname of the file that
+            will be written.
+
+         4.1.2.10  Telnet End-of-line Code: RFC-959, Page 34
+
+            Implementors MUST NOT assume any correspondence between READ
+            boundaries on the control connection and the Telnet EOL
+            sequences (CR LF).
+
+            DISCUSSION:
+                 Thus, a server-FTP (or User-FTP) must continue reading
+                 characters from the control connection until a complete
+                 Telnet EOL sequence is encountered, before processing
+                 the command (or response, respectively).  Conversely, a
+                 single READ from the control connection may include
+
+
+
+Internet Engineering Task Force                                [Page 32]
+
+
+
+
+RFC1123                   FILE TRANSFER -- FTP              October 1989
+
+
+                 more than one FTP command.
+
+         4.1.2.11  FTP Replies: RFC-959 Section 4.2, Page 35
+
+            A Server-FTP MUST send only correctly formatted replies on
+            the control connection.  Note that RFC-959 (unlike earlier
+            versions of the FTP spec) contains no provision for a
+            "spontaneous" reply message.
+
+            A Server-FTP SHOULD use the reply codes defined in RFC-959
+            whenever they apply.  However, a server-FTP MAY use a
+            different reply code when needed, as long as the general
+            rules of Section 4.2 are followed. When the implementor has
+            a choice between a 4xx and 5xx reply code, a Server-FTP
+            SHOULD send a 4xx (temporary failure) code when there is any
+            reasonable possibility that a failed FTP will succeed a few
+            hours later.
+
+            A User-FTP SHOULD generally use only the highest-order digit
+            of a 3-digit reply code for making a procedural decision, to
+            prevent difficulties when a Server-FTP uses non-standard
+            reply codes.
+
+            A User-FTP MUST be able to handle multi-line replies.  If
+            the implementation imposes a limit on the number of lines
+            and if this limit is exceeded, the User-FTP MUST recover,
+            e.g., by ignoring the excess lines until the end of the
+            multi-line reply is reached.
+
+            A User-FTP SHOULD NOT interpret a 421 reply code ("Service
+            not available, closing control connection") specially, but
+            SHOULD detect closing of the control connection by the
+            server.
+
+            DISCUSSION:
+                 Server implementations that fail to strictly follow the
+                 reply rules often cause FTP user programs to hang.
+                 Note that RFC-959 resolved ambiguities in the reply
+                 rules found in earlier FTP specifications and must be
+                 followed.
+
+                 It is important to choose FTP reply codes that properly
+                 distinguish between temporary and permanent failures,
+                 to allow the successful use of file transfer client
+                 daemons.  These programs depend on the reply codes to
+                 decide whether or not to retry a failed transfer; using
+                 a permanent failure code (5xx) for a temporary error
+                 will cause these programs to give up unnecessarily.
+
+
+
+Internet Engineering Task Force                                [Page 33]
+
+
+
+
+RFC1123                   FILE TRANSFER -- FTP              October 1989
+
+
+                 When the meaning of a reply matches exactly the text
+                 shown in RFC-959, uniformity will be enhanced by using
+                 the RFC-959 text verbatim.  However, a Server-FTP
+                 implementor is encouraged to choose reply text that
+                 conveys specific system-dependent information, when
+                 appropriate.
+
+         4.1.2.12  Connections: RFC-959 Section 5.2
+
+            The words "and the port used" in the second paragraph of
+            this section of RFC-959 are erroneous (historical), and they
+            should be ignored.
+
+            On a multihomed server host, the default data transfer port
+            (L-1) MUST be associated with the same local IP address as
+            the corresponding control connection to port L.
+
+            A user-FTP MUST NOT send any Telnet controls other than
+            SYNCH and IP on an FTP control connection. In particular, it
+            MUST NOT attempt to negotiate Telnet options on the control
+            connection.  However, a server-FTP MUST be capable of
+            accepting and refusing Telnet negotiations (i.e., sending
+            DONT/WONT).
+
+            DISCUSSION:
+                 Although the RFC says: "Server- and User- processes
+                 should follow the conventions for the Telnet
+                 protocol...[on the control connection]", it is not the
+                 intent that Telnet option negotiation is to be
+                 employed.
+
+         4.1.2.13  Minimum Implementation; RFC-959 Section 5.1
+
+            The following commands and options MUST be supported by
+            every server-FTP and user-FTP, except in cases where the
+            underlying file system or operating system does not allow or
+            support a particular command.
+
+                 Type: ASCII Non-print, IMAGE, LOCAL 8
+                 Mode: Stream
+                 Structure: File, Record*
+                 Commands:
+                    USER, PASS, ACCT,
+                    PORT, PASV,
+                    TYPE, MODE, STRU,
+                    RETR, STOR, APPE,
+                    RNFR, RNTO, DELE,
+                    CWD,  CDUP, RMD,  MKD,  PWD,
+
+
+
+Internet Engineering Task Force                                [Page 34]
+
+
+
+
+RFC1123                   FILE TRANSFER -- FTP              October 1989
+
+
+                    LIST, NLST,
+                    SYST, STAT,
+                    HELP, NOOP, QUIT.
+
+            *Record structure is REQUIRED only for hosts whose file
+            systems support record structure.
+
+            DISCUSSION:
+                 Vendors are encouraged to implement a larger subset of
+                 the protocol.  For example, there are important
+                 robustness features in the protocol (e.g., Restart,
+                 ABOR, block mode) that would be an aid to some Internet
+                 users but are not widely implemented.
+
+                 A host that does not have record structures in its file
+                 system may still accept files with STRU R, recording
+                 the byte stream literally.
+
+      4.1.3  SPECIFIC ISSUES
+
+         4.1.3.1  Non-standard Command Verbs
+
+            FTP allows "experimental" commands, whose names begin with
+            "X".  If these commands are subsequently adopted as
+            standards, there may still be existing implementations using
+            the "X" form.  At present, this is true for the directory
+            commands:
+
+                RFC-959   "Experimental"
+
+                  MKD        XMKD
+                  RMD        XRMD
+                  PWD        XPWD
+                  CDUP       XCUP
+                  CWD        XCWD
+
+            All FTP implementations SHOULD recognize both forms of these
+            commands, by simply equating them with extra entries in the
+            command lookup table.
+
+            IMPLEMENTATION:
+                 A User-FTP can access a server that supports only the
+                 "X" forms by implementing a mode switch, or
+                 automatically using the following procedure: if the
+                 RFC-959 form of one of the above commands is rejected
+                 with a 500 or 502 response code, then try the
+                 experimental form; any other response would be passed
+                 to the user.
+
+
+
+Internet Engineering Task Force                                [Page 35]
+
+
+
+
+RFC1123                   FILE TRANSFER -- FTP              October 1989
+
+
+         4.1.3.2  Idle Timeout
+
+            A Server-FTP process SHOULD have an idle timeout, which will
+            terminate the process and close the control connection if
+            the server is inactive (i.e., no command or data transfer in
+            progress) for a long period of time.  The idle timeout time
+            SHOULD be configurable, and the default should be at least 5
+            minutes.
+
+            A client FTP process ("User-PI" in RFC-959) will need
+            timeouts on responses only if it is invoked from a program.
+
+            DISCUSSION:
+                 Without a timeout, a Server-FTP process may be left
+                 pending indefinitely if the corresponding client
+                 crashes without closing the control connection.
+
+         4.1.3.3  Concurrency of Data and Control
+
+            DISCUSSION:
+                 The intent of the designers of FTP was that a user
+                 should be able to send a STAT command at any time while
+                 data transfer was in progress and that the server-FTP
+                 would reply immediately with status -- e.g., the number
+                 of bytes transferred so far.  Similarly, an ABOR
+                 command should be possible at any time during a data
+                 transfer.
+
+                 Unfortunately, some small-machine operating systems
+                 make such concurrent programming difficult, and some
+                 other implementers seek minimal solutions, so some FTP
+                 implementations do not allow concurrent use of the data
+                 and control connections.  Even such a minimal server
+                 must be prepared to accept and defer a STAT or ABOR
+                 command that arrives during data transfer.
+
+         4.1.3.4  FTP Restart Mechanism
+
+            The description of the 110 reply on pp. 40-41 of RFC-959 is
+            incorrect; the correct description is as follows.  A restart
+            reply message, sent over the control connection from the
+            receiving FTP to the User-FTP, has the format:
+
+                110 MARK ssss = rrrr
+
+            Here:
+
+            *    ssss is a text string that appeared in a Restart Marker
+
+
+
+Internet Engineering Task Force                                [Page 36]
+
+
+
+
+RFC1123                   FILE TRANSFER -- FTP              October 1989
+
+
+                 in the data stream and encodes a position in the
+                 sender's file system;
+
+            *    rrrr encodes the corresponding position in the
+                 receiver's file system.
+
+            The encoding, which is specific to a particular file system
+            and network implementation, is always generated and
+            interpreted by the same system, either sender or receiver.
+
+            When an FTP that implements restart receives a Restart
+            Marker in the data stream, it SHOULD force the data to that
+            point to be written to stable storage before encoding the
+            corresponding position rrrr.  An FTP sending Restart Markers
+            MUST NOT assume that 110 replies will be returned
+            synchronously with the data, i.e., it must not await a 110
+            reply before sending more data.
+
+            Two new reply codes are hereby defined for errors
+            encountered in restarting a transfer:
+
+              554 Requested action not taken: invalid REST parameter.
+
+                 A 554 reply may result from a FTP service command that
+                 follows a REST command.  The reply indicates that the
+                 existing file at the Server-FTP cannot be repositioned
+                 as specified in the REST.
+
+              555 Requested action not taken: type or stru mismatch.
+
+                 A 555 reply may result from an APPE command or from any
+                 FTP service command following a REST command.  The
+                 reply indicates that there is some mismatch between the
+                 current transfer parameters (type and stru) and the
+                 attributes of the existing file.
+
+            DISCUSSION:
+                 Note that the FTP Restart mechanism requires that Block
+                 or Compressed mode be used for data transfer, to allow
+                 the Restart Markers to be included within the data
+                 stream.  The frequency of Restart Markers can be low.
+
+                 Restart Markers mark a place in the data stream, but
+                 the receiver may be performing some transformation on
+                 the data as it is stored into stable storage.  In
+                 general, the receiver's encoding must include any state
+                 information necessary to restart this transformation at
+                 any point of the FTP data stream.  For example, in TYPE
+
+
+
+Internet Engineering Task Force                                [Page 37]
+
+
+
+
+RFC1123                   FILE TRANSFER -- FTP              October 1989
+
+
+                 A transfers, some receiver hosts transform CR LF
+                 sequences into a single LF character on disk.   If a
+                 Restart Marker happens to fall between CR and LF, the
+                 receiver must encode in rrrr that the transfer must be
+                 restarted in a "CR has been seen and discarded" state.
+
+                 Note that the Restart Marker is required to be encoded
+                 as a string of printable ASCII characters, regardless
+                 of the type of the data.
+
+                 RFC-959 says that restart information is to be returned
+                 "to the user".  This should not be taken literally.  In
+                 general, the User-FTP should save the restart
+                 information (ssss,rrrr) in stable storage, e.g., append
+                 it to a restart control file.  An empty restart control
+                 file should be created when the transfer first starts
+                 and deleted automatically when the transfer completes
+                 successfully.  It is suggested that this file have a
+                 name derived in an easily-identifiable manner from the
+                 name of the file being transferred and the remote host
+                 name; this is analogous to the means used by many text
+                 editors for naming "backup" files.
+
+                 There are three cases for FTP restart.
+
+                 (1)  User-to-Server Transfer
+
+                      The User-FTP puts Restart Markers <ssss> at
+                      convenient places in the data stream.  When the
+                      Server-FTP receives a Marker, it writes all prior
+                      data to disk, encodes its file system position and
+                      transformation state as rrrr, and returns a "110
+                      MARK ssss = rrrr" reply over the control
+                      connection.  The User-FTP appends the pair
+                      (ssss,rrrr) to its restart control file.
+
+                      To restart the transfer, the User-FTP fetches the
+                      last (ssss,rrrr) pair from the restart control
+                      file, repositions its local file system and
+                      transformation state using ssss, and sends the
+                      command "REST rrrr" to the Server-FTP.
+
+                 (2)  Server-to-User Transfer
+
+                      The Server-FTP puts Restart Markers <ssss> at
+                      convenient places in the data stream.  When the
+                      User-FTP receives a Marker, it writes all prior
+                      data to disk, encodes its file system position and
+
+
+
+Internet Engineering Task Force                                [Page 38]
+
+
+
+
+RFC1123                   FILE TRANSFER -- FTP              October 1989
+
+
+                      transformation state as rrrr, and appends the pair
+                      (rrrr,ssss) to its restart control file.
+
+                      To restart the transfer, the User-FTP fetches the
+                      last (rrrr,ssss) pair from the restart control
+                      file, repositions its local file system and
+                      transformation state using rrrr, and sends the
+                      command "REST ssss" to the Server-FTP.
+
+                 (3)  Server-to-Server ("Third-Party") Transfer
+
+                      The sending Server-FTP puts Restart Markers <ssss>
+                      at convenient places in the data stream.  When it
+                      receives a Marker, the receiving Server-FTP writes
+                      all prior data to disk, encodes its file system
+                      position and transformation state as rrrr, and
+                      sends a "110 MARK ssss = rrrr" reply over the
+                      control connection to the User.  The User-FTP
+                      appends the pair (ssss,rrrr) to its restart
+                      control file.
+
+                      To restart the transfer, the User-FTP fetches the
+                      last (ssss,rrrr) pair from the restart control
+                      file, sends "REST ssss" to the sending Server-FTP,
+                      and sends "REST rrrr" to the receiving Server-FTP.
+
+
+      4.1.4  FTP/USER INTERFACE
+
+         This section discusses the user interface for a User-FTP
+         program.
+
+         4.1.4.1  Pathname Specification
+
+            Since FTP is intended for use in a heterogeneous
+            environment, User-FTP implementations MUST support remote
+            pathnames as arbitrary character strings, so that their form
+            and content are not limited by the conventions of the local
+            operating system.
+
+            DISCUSSION:
+                 In particular, remote pathnames can be of arbitrary
+                 length, and all the printing ASCII characters as well
+                 as space (0x20) must be allowed.  RFC-959 allows a
+                 pathname to contain any 7-bit ASCII character except CR
+                 or LF.
+
+
+
+
+
+Internet Engineering Task Force                                [Page 39]
+
+
+
+
+RFC1123                   FILE TRANSFER -- FTP              October 1989
+
+
+         4.1.4.2  "QUOTE" Command
+
+            A User-FTP program MUST implement a "QUOTE" command that
+            will pass an arbitrary character string to the server and
+            display all resulting response messages to the user.
+
+            To make the "QUOTE" command useful, a User-FTP SHOULD send
+            transfer control commands to the server as the user enters
+            them, rather than saving all the commands and sending them
+            to the server only when a data transfer is started.
+
+            DISCUSSION:
+                 The "QUOTE" command is essential to allow the user to
+                 access servers that require system-specific commands
+                 (e.g., SITE or ALLO), or to invoke new or optional
+                 features that are not implemented by the User-FTP.  For
+                 example, "QUOTE" may be used to specify "TYPE A T" to
+                 send a print file to hosts that require the
+                 distinction, even if the User-FTP does not recognize
+                 that TYPE.
+
+         4.1.4.3  Displaying Replies to User
+
+            A User-FTP SHOULD display to the user the full text of all
+            error reply messages it receives.  It SHOULD have a
+            "verbose" mode in which all commands it sends and the full
+            text and reply codes it receives are displayed, for
+            diagnosis of problems.
+
+         4.1.4.4  Maintaining Synchronization
+
+            The state machine in a User-FTP SHOULD be forgiving of
+            missing and unexpected reply messages, in order to maintain
+            command synchronization with the server.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Internet Engineering Task Force                                [Page 40]
+
+
+
+
+RFC1123                   FILE TRANSFER -- FTP              October 1989
+
+
+      4.1.5   FTP REQUIREMENTS SUMMARY
+
+                                           |               | | | |S| |
+                                           |               | | | |H| |F
+                                           |               | | | |O|M|o
+                                           |               | |S| |U|U|o
+                                           |               | |H| |L|S|t
+                                           |               |M|O| |D|T|n
+                                           |               |U|U|M| | |o
+                                           |               |S|L|A|N|N|t
+                                           |               |T|D|Y|O|O|t
+FEATURE                                    |SECTION        | | | |T|T|e
+-------------------------------------------|---------------|-|-|-|-|-|--
+Implement TYPE T if same as TYPE N         |4.1.2.2        | |x| | | |
+File/Record transform invertible if poss.  |4.1.2.4        | |x| | | |
+User-FTP send PORT cmd for stream mode     |4.1.2.5        | |x| | | |
+Server-FTP implement PASV                  |4.1.2.6        |x| | | | |
+  PASV is per-transfer                     |4.1.2.6        |x| | | | |
+NLST reply usable in RETR cmds             |4.1.2.7        |x| | | | |
+Implied type for LIST and NLST             |4.1.2.7        | |x| | | |
+SITE cmd for non-standard features         |4.1.2.8        | |x| | | |
+STOU cmd return pathname as specified      |4.1.2.9        |x| | | | |
+Use TCP READ boundaries on control conn.   |4.1.2.10       | | | | |x|
+                                           |               | | | | | |
+Server-FTP send only correct reply format  |4.1.2.11       |x| | | | |
+Server-FTP use defined reply code if poss. |4.1.2.11       | |x| | | |
+  New reply code following Section 4.2     |4.1.2.11       | | |x| | |
+User-FTP use only high digit of reply      |4.1.2.11       | |x| | | |
+User-FTP handle multi-line reply lines     |4.1.2.11       |x| | | | |
+User-FTP handle 421 reply specially        |4.1.2.11       | | | |x| |
+                                           |               | | | | | |
+Default data port same IP addr as ctl conn |4.1.2.12       |x| | | | |
+User-FTP send Telnet cmds exc. SYNCH, IP   |4.1.2.12       | | | | |x|
+User-FTP negotiate Telnet options          |4.1.2.12       | | | | |x|
+Server-FTP handle Telnet options           |4.1.2.12       |x| | | | |
+Handle "Experimental" directory cmds       |4.1.3.1        | |x| | | |
+Idle timeout in server-FTP                 |4.1.3.2        | |x| | | |
+    Configurable idle timeout              |4.1.3.2        | |x| | | |
+Receiver checkpoint data at Restart Marker |4.1.3.4        | |x| | | |
+Sender assume 110 replies are synchronous  |4.1.3.4        | | | | |x|
+                                           |               | | | | | |
+Support TYPE:                              |               | | | | | |
+  ASCII - Non-Print (AN)                   |4.1.2.13       |x| | | | |
+  ASCII - Telnet (AT) -- if same as AN     |4.1.2.2        | |x| | | |
+  ASCII - Carriage Control (AC)            |959 3.1.1.5.2  | | |x| | |
+  EBCDIC - (any form)                      |959 3.1.1.2    | | |x| | |
+  IMAGE                                    |4.1.2.1        |x| | | | |
+  LOCAL 8                                  |4.1.2.1        |x| | | | |
+
+
+
+Internet Engineering Task Force                                [Page 41]
+
+
+
+
+RFC1123                   FILE TRANSFER -- FTP              October 1989
+
+
+  LOCAL m                                  |4.1.2.1        | | |x| | |2
+                                           |               | | | | | |
+Support MODE:                              |               | | | | | |
+  Stream                                   |4.1.2.13       |x| | | | |
+  Block                                    |959 3.4.2      | | |x| | |
+                                           |               | | | | | |
+Support STRUCTURE:                         |               | | | | | |
+  File                                     |4.1.2.13       |x| | | | |
+  Record                                   |4.1.2.13       |x| | | | |3
+  Page                                     |4.1.2.3        | | | |x| |
+                                           |               | | | | | |
+Support commands:                          |               | | | | | |
+  USER                                     |4.1.2.13       |x| | | | |
+  PASS                                     |4.1.2.13       |x| | | | |
+  ACCT                                     |4.1.2.13       |x| | | | |
+  CWD                                      |4.1.2.13       |x| | | | |
+  CDUP                                     |4.1.2.13       |x| | | | |
+  SMNT                                     |959 5.3.1      | | |x| | |
+  REIN                                     |959 5.3.1      | | |x| | |
+  QUIT                                     |4.1.2.13       |x| | | | |
+                                           |               | | | | | |
+  PORT                                     |4.1.2.13       |x| | | | |
+  PASV                                     |4.1.2.6        |x| | | | |
+  TYPE                                     |4.1.2.13       |x| | | | |1
+  STRU                                     |4.1.2.13       |x| | | | |1
+  MODE                                     |4.1.2.13       |x| | | | |1
+                                           |               | | | | | |
+  RETR                                     |4.1.2.13       |x| | | | |
+  STOR                                     |4.1.2.13       |x| | | | |
+  STOU                                     |959 5.3.1      | | |x| | |
+  APPE                                     |4.1.2.13       |x| | | | |
+  ALLO                                     |959 5.3.1      | | |x| | |
+  REST                                     |959 5.3.1      | | |x| | |
+  RNFR                                     |4.1.2.13       |x| | | | |
+  RNTO                                     |4.1.2.13       |x| | | | |
+  ABOR                                     |959 5.3.1      | | |x| | |
+  DELE                                     |4.1.2.13       |x| | | | |
+  RMD                                      |4.1.2.13       |x| | | | |
+  MKD                                      |4.1.2.13       |x| | | | |
+  PWD                                      |4.1.2.13       |x| | | | |
+  LIST                                     |4.1.2.13       |x| | | | |
+  NLST                                     |4.1.2.13       |x| | | | |
+  SITE                                     |4.1.2.8        | | |x| | |
+  STAT                                     |4.1.2.13       |x| | | | |
+  SYST                                     |4.1.2.13       |x| | | | |
+  HELP                                     |4.1.2.13       |x| | | | |
+  NOOP                                     |4.1.2.13       |x| | | | |
+                                           |               | | | | | |
+
+
+
+Internet Engineering Task Force                                [Page 42]
+
+
+
+
+RFC1123                   FILE TRANSFER -- FTP              October 1989
+
+
+User Interface:                            |               | | | | | |
+  Arbitrary pathnames                      |4.1.4.1        |x| | | | |
+  Implement "QUOTE" command                |4.1.4.2        |x| | | | |
+  Transfer control commands immediately    |4.1.4.2        | |x| | | |
+  Display error messages to user           |4.1.4.3        | |x| | | |
+    Verbose mode                           |4.1.4.3        | |x| | | |
+  Maintain synchronization with server     |4.1.4.4        | |x| | | |
+
+Footnotes:
+
+(1)  For the values shown earlier.
+
+(2)  Here m is number of bits in a memory word.
+
+(3)  Required for host with record-structured file system, optional
+     otherwise.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Internet Engineering Task Force                                [Page 43]
+
+
+
+
+RFC1123                  FILE TRANSFER -- TFTP              October 1989
+
+
+   4.2  TRIVIAL FILE TRANSFER PROTOCOL -- TFTP
+
+      4.2.1  INTRODUCTION
+
+         The Trivial File Transfer Protocol TFTP is defined in RFC-783
+         [TFTP:1].
+
+         TFTP provides its own reliable delivery with UDP as its
+         transport protocol, using a simple stop-and-wait acknowledgment
+         system.  Since TFTP has an effective window of only one 512
+         octet segment, it can provide good performance only over paths
+         that have a small delay*bandwidth product.  The TFTP file
+         interface is very simple, providing no access control or
+         security.
+
+         TFTP's most important application is bootstrapping a host over
+         a local network, since it is simple and small enough to be
+         easily implemented in EPROM [BOOT:1, BOOT:2].  Vendors are
+         urged to support TFTP for booting.
+
+      4.2.2  PROTOCOL WALK-THROUGH
+
+         The TFTP specification [TFTP:1] is written in an open style,
+         and does not fully specify many parts of the protocol.
+
+         4.2.2.1  Transfer Modes: RFC-783, Page 3
+
+            The transfer mode "mail" SHOULD NOT be supported.
+
+         4.2.2.2  UDP Header: RFC-783, Page 17
+
+            The Length field of a UDP header is incorrectly defined; it
+            includes the UDP header length (8).
+
+      4.2.3  SPECIFIC ISSUES
+
+         4.2.3.1  Sorcerer's Apprentice Syndrome
+
+            There is a serious bug, known as the "Sorcerer's Apprentice
+            Syndrome," in the protocol specification.  While it does not
+            cause incorrect operation of the transfer (the file will
+            always be transferred correctly if the transfer completes),
+            this bug may cause excessive retransmission, which may cause
+            the transfer to time out.
+
+            Implementations MUST contain the fix for this problem: the
+            sender (i.e., the side originating the DATA packets) must
+            never resend the current DATA packet on receipt of a
+
+
+
+Internet Engineering Task Force                                [Page 44]
+
+
+
+
+RFC1123                  FILE TRANSFER -- TFTP              October 1989
+
+
+            duplicate ACK.
+
+            DISCUSSION:
+                 The bug is caused by the protocol rule that either
+                 side, on receiving an old duplicate datagram, may
+                 resend the current datagram.  If a packet is delayed in
+                 the network but later successfully delivered after
+                 either side has timed out and retransmitted a packet, a
+                 duplicate copy of the response may be generated.  If
+                 the other side responds to this duplicate with a
+                 duplicate of its own, then every datagram will be sent
+                 in duplicate for the remainder of the transfer (unless
+                 a datagram is lost, breaking the repetition).  Worse
+                 yet, since the delay is often caused by congestion,
+                 this duplicate transmission will usually causes more
+                 congestion, leading to more delayed packets, etc.
+
+                 The following example may help to clarify this problem.
+
+                     TFTP A                  TFTP B
+
+                 (1)  Receive ACK X-1
+                      Send DATA X
+                 (2)                          Receive DATA X
+                                              Send ACK X
+                        (ACK X is delayed in network,
+                         and  A times out):
+                 (3)  Retransmit DATA X
+
+                 (4)                          Receive DATA X again
+                                              Send ACK X again
+                 (5)  Receive (delayed) ACK X
+                      Send DATA X+1
+                 (6)                          Receive DATA X+1
+                                              Send ACK X+1
+                 (7)  Receive ACK X again
+                      Send DATA X+1 again
+                 (8)                          Receive DATA X+1 again
+                                              Send ACK X+1 again
+                 (9)  Receive ACK X+1
+                      Send DATA X+2
+                 (10)                         Receive DATA X+2
+                                              Send ACK X+3
+                 (11) Receive ACK X+1 again
+                      Send DATA X+2 again
+                 (12)                         Receive DATA X+2 again
+                                              Send ACK X+3 again
+
+
+
+
+Internet Engineering Task Force                                [Page 45]
+
+
+
+
+RFC1123                  FILE TRANSFER -- TFTP              October 1989
+
+
+                 Notice that once the delayed ACK arrives, the protocol
+                 settles down to duplicate all further packets
+                 (sequences 5-8 and 9-12).  The problem is caused not by
+                 either side timing out, but by both sides
+                 retransmitting the current packet when they receive a
+                 duplicate.
+
+                 The fix is to break the retransmission loop, as
+                 indicated above.  This is analogous to the behavior of
+                 TCP.  It is then possible to remove the retransmission
+                 timer on the receiver, since the resent ACK will never
+                 cause any action; this is a useful simplification where
+                 TFTP is used in a bootstrap program.  It is OK to allow
+                 the timer to remain, and it may be helpful if the
+                 retransmitted ACK replaces one that was genuinely lost
+                 in the network.  The sender still requires a retransmit
+                 timer, of course.
+
+         4.2.3.2  Timeout Algorithms
+
+            A TFTP implementation MUST use an adaptive timeout.
+
+            IMPLEMENTATION:
+                 TCP retransmission algorithms provide a useful base to
+                 work from.  At least an exponential backoff of
+                 retransmission timeout is necessary.
+
+         4.2.3.3  Extensions
+
+            A variety of non-standard extensions have been made to TFTP,
+            including additional transfer modes and a secure operation
+            mode (with passwords).  None of these have been
+            standardized.
+
+         4.2.3.4  Access Control
+
+            A server TFTP implementation SHOULD include some
+            configurable access control over what pathnames are allowed
+            in TFTP operations.
+
+         4.2.3.5  Broadcast Request
+
+            A TFTP request directed to a broadcast address SHOULD be
+            silently ignored.
+
+            DISCUSSION:
+                 Due to the weak access control capability of TFTP,
+                 directed broadcasts of TFTP requests to random networks
+
+
+
+Internet Engineering Task Force                                [Page 46]
+
+
+
+
+RFC1123                  FILE TRANSFER -- TFTP              October 1989
+
+
+                 could create a significant security hole.
+
+      4.2.4  TFTP REQUIREMENTS SUMMARY
+
+                                                 |        | | | |S| |
+                                                 |        | | | |H| |F
+                                                 |        | | | |O|M|o
+                                                 |        | |S| |U|U|o
+                                                 |        | |H| |L|S|t
+                                                 |        |M|O| |D|T|n
+                                                 |        |U|U|M| | |o
+                                                 |        |S|L|A|N|N|t
+                                                 |        |T|D|Y|O|O|t
+FEATURE                                          |SECTION | | | |T|T|e
+-------------------------------------------------|--------|-|-|-|-|-|--
+Fix Sorcerer's Apprentice Syndrome               |4.2.3.1 |x| | | | |
+Transfer modes:                                  |        | | | | | |
+  netascii                                       |RFC-783 |x| | | | |
+  octet                                          |RFC-783 |x| | | | |
+  mail                                           |4.2.2.1 | | | |x| |
+  extensions                                     |4.2.3.3 | | |x| | |
+Use adaptive timeout                             |4.2.3.2 |x| | | | |
+Configurable access control                      |4.2.3.4 | |x| | | |
+Silently ignore broadcast request                |4.2.3.5 | |x| | | |
+-------------------------------------------------|--------|-|-|-|-|-|--
+-------------------------------------------------|--------|-|-|-|-|-|--
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Internet Engineering Task Force                                [Page 47]
+
+
+
+
+RFC1123                  MAIL -- SMTP & RFC-822             October 1989
+
+
+5.  ELECTRONIC MAIL -- SMTP and RFC-822
+
+   5.1  INTRODUCTION
+
+      In the TCP/IP protocol suite, electronic mail in a format
+      specified in RFC-822 [SMTP:2] is transmitted using the Simple Mail
+      Transfer Protocol (SMTP) defined in RFC-821 [SMTP:1].
+
+      While SMTP has remained unchanged over the years, the Internet
+      community has made several changes in the way SMTP is used.  In
+      particular, the conversion to the Domain Name System (DNS) has
+      caused changes in address formats and in mail routing.  In this
+      section, we assume familiarity with the concepts and terminology
+      of the DNS, whose requirements are given in Section 6.1.
+
+      RFC-822 specifies the Internet standard format for electronic mail
+      messages.  RFC-822 supercedes an older standard, RFC-733, that may
+      still be in use in a few places, although it is obsolete.  The two
+      formats are sometimes referred to simply by number ("822" and
+      "733").
+
+      RFC-822 is used in some non-Internet mail environments with
+      different mail transfer protocols than SMTP, and SMTP has also
+      been adapted for use in some non-Internet environments.  Note that
+      this document presents the rules for the use of SMTP and RFC-822
+      for the Internet environment only; other mail environments that
+      use these protocols may be expected to have their own rules.
+
+   5.2  PROTOCOL WALK-THROUGH
+
+      This section covers both RFC-821 and RFC-822.
+
+      The SMTP specification in RFC-821 is clear and contains numerous
+      examples, so implementors should not find it difficult to
+      understand.  This section simply updates or annotates portions of
+      RFC-821 to conform with current usage.
+
+      RFC-822 is a long and dense document, defining a rich syntax.
+      Unfortunately, incomplete or defective implementations of RFC-822
+      are common.  In fact, nearly all of the many formats of RFC-822
+      are actually used, so an implementation generally needs to
+      recognize and correctly interpret all of the RFC-822 syntax.
+
+      5.2.1  The SMTP Model: RFC-821 Section 2
+
+         DISCUSSION:
+              Mail is sent by a series of request/response transactions
+              between a client, the "sender-SMTP," and a server, the
+
+
+
+Internet Engineering Task Force                                [Page 48]
+
+
+
+
+RFC1123                  MAIL -- SMTP & RFC-822             October 1989
+
+
+              "receiver-SMTP".  These transactions pass (1) the message
+              proper, which is composed of header and body, and (2) SMTP
+              source and destination addresses, referred to as the
+              "envelope".
+
+              The SMTP programs are analogous to Message Transfer Agents
+              (MTAs) of X.400.  There will be another level of protocol
+              software, closer to the end user, that is responsible for
+              composing and analyzing RFC-822 message headers; this
+              component is known as the "User Agent" in X.400, and we
+              use that term in this document.  There is a clear logical
+              distinction between the User Agent and the SMTP
+              implementation, since they operate on different levels of
+              protocol.  Note, however, that this distinction is may not
+              be exactly reflected the structure of typical
+              implementations of Internet mail.  Often there is a
+              program known as the "mailer" that implements SMTP and
+              also some of the User Agent functions; the rest of the
+              User Agent functions are included in a user interface used
+              for entering and reading mail.
+
+              The SMTP envelope is constructed at the originating site,
+              typically by the User Agent when the message is first
+              queued for the Sender-SMTP program.  The envelope
+              addresses may be derived from information in the message
+              header, supplied by the user interface (e.g., to implement
+              a bcc: request), or derived from local configuration
+              information (e.g., expansion of a mailing list).  The SMTP
+              envelope cannot in general be re-derived from the header
+              at a later stage in message delivery, so the envelope is
+              transmitted separately from the message itself using the
+              MAIL and RCPT commands of SMTP.
+
+              The text of RFC-821 suggests that mail is to be delivered
+              to an individual user at a host.  With the advent of the
+              domain system and of mail routing using mail-exchange (MX)
+              resource records, implementors should now think of
+              delivering mail to a user at a domain, which may or may
+              not be a particular host.  This DOES NOT change the fact
+              that SMTP is a host-to-host mail exchange protocol.
+
+      5.2.2  Canonicalization: RFC-821 Section 3.1
+
+         The domain names that a Sender-SMTP sends in MAIL and RCPT
+         commands MUST have been  "canonicalized," i.e., they must be
+         fully-qualified principal names or domain literals, not
+         nicknames or domain abbreviations.  A canonicalized name either
+         identifies a host directly or is an MX name; it cannot be a
+
+
+
+Internet Engineering Task Force                                [Page 49]
+
+
+
+
+RFC1123                  MAIL -- SMTP & RFC-822             October 1989
+
+
+         CNAME.
+
+      5.2.3  VRFY and EXPN Commands: RFC-821 Section 3.3
+
+         A receiver-SMTP MUST implement VRFY and SHOULD implement EXPN
+         (this requirement overrides RFC-821).  However, there MAY be
+         configuration information to disable VRFY and EXPN in a
+         particular installation; this might even allow EXPN to be
+         disabled for selected lists.
+
+         A new reply code is defined for the VRFY command:
+
+              252 Cannot VRFY user (e.g., info is not local), but will
+                  take message for this user and attempt delivery.
+
+         DISCUSSION:
+              SMTP users and administrators make regular use of these
+              commands for diagnosing mail delivery problems.  With the
+              increasing use of multi-level mailing list expansion
+              (sometimes more than two levels), EXPN has been
+              increasingly important for diagnosing inadvertent mail
+              loops.  On the other hand,  some feel that EXPN represents
+              a significant privacy, and perhaps even a security,
+              exposure.
+
+      5.2.4  SEND, SOML, and SAML Commands: RFC-821 Section 3.4
+
+         An SMTP MAY implement the commands to send a message to a
+         user's terminal: SEND, SOML, and SAML.
+
+         DISCUSSION:
+              It has been suggested that the use of mail relaying
+              through an MX record is inconsistent with the intent of
+              SEND to deliver a message immediately and directly to a
+              user's terminal.  However, an SMTP receiver that is unable
+              to write directly to the user terminal can return a "251
+              User Not Local" reply to the RCPT following a SEND, to
+              inform the originator of possibly deferred delivery.
+
+      5.2.5  HELO Command: RFC-821 Section 3.5
+
+         The sender-SMTP MUST ensure that the <domain> parameter in a
+         HELO command is a valid principal host domain name for the
+         client host.  As a result, the receiver-SMTP will not have to
+         perform MX resolution on this name in order to validate the
+         HELO parameter.
+
+         The HELO receiver MAY verify that the HELO parameter really
+
+
+
+Internet Engineering Task Force                                [Page 50]
+
+
+
+
+RFC1123                  MAIL -- SMTP & RFC-822             October 1989
+
+
+         corresponds to the IP address of the sender.  However, the
+         receiver MUST NOT refuse to accept a message, even if the
+         sender's HELO command fails verification.
+
+         DISCUSSION:
+              Verifying the HELO parameter requires a domain name lookup
+              and may therefore take considerable time.  An alternative
+              tool for tracking bogus mail sources is suggested below
+              (see "DATA Command").
+
+              Note also that the HELO argument is still required to have
+              valid <domain> syntax, since it will appear in a Received:
+              line; otherwise, a 501 error is to be sent.
+
+         IMPLEMENTATION:
+              When HELO parameter validation fails, a suggested
+              procedure is to insert a note about the unknown
+              authenticity of the sender into the message header (e.g.,
+              in the "Received:"  line).
+
+      5.2.6  Mail Relay: RFC-821 Section 3.6
+
+         We distinguish three types of mail (store-and-) forwarding:
+
+         (1)  A simple forwarder or "mail exchanger" forwards a message
+              using private knowledge about the recipient; see section
+              3.2 of RFC-821.
+
+         (2)  An SMTP mail "relay" forwards a message within an SMTP
+              mail environment as the result of an explicit source route
+              (as defined in section 3.6 of RFC-821).  The SMTP relay
+              function uses the "@...:" form of source route from RFC-
+              822 (see Section 5.2.19 below).
+
+         (3)  A mail "gateway" passes a message between different
+              environments.  The rules for mail gateways are discussed
+              below in Section 5.3.7.
+
+         An Internet host that is forwarding a message but is not a
+         gateway to a different mail environment (i.e., it falls under
+         (1) or (2)) SHOULD NOT alter any existing header fields,
+         although the host will add an appropriate Received: line as
+         required in Section 5.2.8.
+
+         A Sender-SMTP SHOULD NOT send a RCPT TO: command containing an
+         explicit source route using the "@...:" address form.  Thus,
+         the relay function defined in section  3.6 of RFC-821 should
+         not be used.
+
+
+
+Internet Engineering Task Force                                [Page 51]
+
+
+
+
+RFC1123                  MAIL -- SMTP & RFC-822             October 1989
+
+
+         DISCUSSION:
+              The intent is to discourage all source routing and to
+              abolish explicit source routing for mail delivery within
+              the Internet environment.  Source-routing is unnecessary;
+              the simple target address "user@domain" should always
+              suffice.  This is the result of an explicit architectural
+              decision to use universal naming rather than source
+              routing for mail.  Thus, SMTP provides end-to-end
+              connectivity, and the DNS provides globally-unique,
+              location-independent names.  MX records handle the major
+              case where source routing might otherwise be needed.
+
+         A receiver-SMTP MUST accept the explicit source route syntax in
+         the envelope, but it MAY implement the relay function as
+         defined in section 3.6 of RFC-821.  If it does not implement
+         the relay function, it SHOULD attempt to deliver the message
+         directly to the host to the right of the right-most "@" sign.
+
+         DISCUSSION:
+              For example, suppose a host that does not implement the
+              relay function receives a message with the SMTP command:
+              "RCPT TO:<@ALPHA,@BETA:joe@GAMMA>", where ALPHA, BETA, and
+              GAMMA represent domain names.  Rather than immediately
+              refusing the message with a 550 error reply as suggested
+              on page 20 of RFC-821, the host should try to forward the
+              message to GAMMA directly, using: "RCPT TO:<joe@GAMMA>".
+              Since this host does not support relaying, it is not
+              required to update the reverse path.
+
+              Some have suggested that source routing may be needed
+              occasionally for manually routing mail around failures;
+              however, the reality and importance of this need is
+              controversial.  The use of explicit SMTP mail relaying for
+              this purpose is discouraged, and in fact it may not be
+              successful, as many host systems do not support it.  Some
+              have used the "%-hack" (see Section 5.2.16) for this
+              purpose.
+
+      5.2.7  RCPT Command: RFC-821 Section 4.1.1
+
+         A host that supports a receiver-SMTP MUST support the reserved
+         mailbox "Postmaster".
+
+         The receiver-SMTP MAY verify RCPT parameters as they arrive;
+         however, RCPT responses MUST NOT be delayed beyond a reasonable
+         time (see Section 5.3.2).
+
+         Therefore, a "250 OK" response to a RCPT does not necessarily
+
+
+
+Internet Engineering Task Force                                [Page 52]
+
+
+
+
+RFC1123                  MAIL -- SMTP & RFC-822             October 1989
+
+
+         imply that the delivery address(es) are valid.  Errors found
+         after message acceptance will be reported by mailing a
+         notification message to an appropriate address (see Section
+         5.3.3).
+
+         DISCUSSION:
+              The set of conditions under which a RCPT parameter can be
+              validated immediately is an engineering design choice.
+              Reporting destination mailbox errors to the Sender-SMTP
+              before mail is transferred is generally desirable to save
+              time and network bandwidth, but this advantage is lost if
+              RCPT verification is lengthy.
+
+              For example, the receiver can verify immediately any
+              simple local reference, such as a single locally-
+              registered mailbox.  On the other hand, the "reasonable
+              time" limitation generally implies deferring verification
+              of a mailing list until after the message has been
+              transferred and accepted, since verifying a large mailing
+              list can take a very long time.  An implementation might
+              or might not choose to defer validation of addresses that
+              are non-local and therefore require a DNS lookup.  If a
+              DNS lookup is performed but a soft domain system error
+              (e.g., timeout) occurs, validity must be assumed.
+
+      5.2.8  DATA Command: RFC-821 Section 4.1.1
+
+         Every receiver-SMTP (not just one that "accepts a message for
+         relaying or for final delivery" [SMTP:1]) MUST insert a
+         "Received:" line at the beginning of a message.  In this line,
+         called a "time stamp line" in RFC-821:
+
+         *    The FROM field SHOULD contain both (1) the name of the
+              source host as presented in the HELO command and (2) a
+              domain literal containing the IP address of the source,
+              determined from the TCP connection.
+
+         *    The ID field MAY contain an "@" as suggested in RFC-822,
+              but this is not required.
+
+         *    The FOR field MAY contain a list of <path> entries when
+              multiple RCPT commands have been given.
+
+
+         An Internet mail program MUST NOT change a Received: line that
+         was previously added to the message header.
+
+
+
+
+
+Internet Engineering Task Force                                [Page 53]
+
+
+
+
+RFC1123                  MAIL -- SMTP & RFC-822             October 1989
+
+
+         DISCUSSION:
+              Including both the source host and the IP source address
+              in the Received: line may provide enough information for
+              tracking illicit mail sources and eliminate a need to
+              explicitly verify the HELO parameter.
+
+              Received: lines are primarily intended for humans tracing
+              mail routes, primarily of diagnosis of faults.  See also
+              the discussion under 5.3.7.
+
+         When the receiver-SMTP makes "final delivery" of a message,
+         then it MUST pass the MAIL FROM: address from the SMTP envelope
+         with the message, for use if an error notification message must
+         be sent later (see Section 5.3.3).  There is an analogous
+         requirement when gatewaying from the Internet into a different
+         mail environment; see Section 5.3.7.
+
+         DISCUSSION:
+              Note that the final reply to the DATA command depends only
+              upon the successful transfer and storage of the message.
+              Any problem with the destination address(es) must either
+              (1) have been reported in an SMTP error reply to the RCPT
+              command(s), or (2) be reported in a later error message
+              mailed to the originator.
+
+         IMPLEMENTATION:
+              The MAIL FROM: information may be passed as a parameter or
+              in a Return-Path: line inserted at the beginning of the
+              message.
+
+      5.2.9  Command Syntax: RFC-821 Section 4.1.2
+
+         The syntax shown in RFC-821 for the MAIL FROM: command omits
+         the case of an empty path:  "MAIL FROM: <>" (see RFC-821 Page
+         15).  An empty reverse path MUST be supported.
+
+      5.2.10  SMTP Replies:  RFC-821 Section 4.2
+
+         A receiver-SMTP SHOULD send only the reply codes listed in
+         section 4.2.2 of RFC-821 or in this document.  A receiver-SMTP
+         SHOULD use the text shown in examples in RFC-821 whenever
+         appropriate.
+
+         A sender-SMTP MUST determine its actions only by the reply
+         code, not by the text (except for 251 and 551 replies); any
+         text, including no text at all, must be acceptable.  The space
+         (blank) following the reply code is considered part of the
+         text.  Whenever possible, a sender-SMTP SHOULD test only the
+
+
+
+Internet Engineering Task Force                                [Page 54]
+
+
+
+
+RFC1123                  MAIL -- SMTP & RFC-822             October 1989
+
+
+         first digit of the reply code, as specified in Appendix E of
+         RFC-821.
+
+         DISCUSSION:
+              Interoperability problems have arisen with SMTP systems
+              using reply codes that are not listed explicitly in RFC-
+              821 Section 4.3 but are legal according to the theory of
+              reply codes explained in Appendix E.
+
+      5.2.11  Transparency: RFC-821 Section 4.5.2
+
+         Implementors MUST be sure that their mail systems always add
+         and delete periods to ensure message transparency.
+
+      5.2.12  WKS Use in MX Processing: RFC-974, p. 5
+
+         RFC-974 [SMTP:3] recommended that the domain system be queried
+         for WKS ("Well-Known Service") records, to verify that each
+         proposed mail target does support SMTP.  Later experience has
+         shown that WKS is not widely supported, so the WKS step in MX
+         processing SHOULD NOT be used.
+
+      The following are notes on RFC-822, organized by section of that
+      document.
+
+      5.2.13  RFC-822 Message Specification: RFC-822 Section 4
+
+         The syntax shown for the Return-path line omits the possibility
+         of a null return path, which is used to prevent looping of
+         error notifications (see Section 5.3.3).  The complete syntax
+         is:
+
+             return = "Return-path"  ":" route-addr
+                    / "Return-path"  ":" "<" ">"
+
+         The set of optional header fields is hereby expanded to include
+         the Content-Type field defined in RFC-1049 [SMTP:7].  This
+         field "allows mail reading systems to automatically identify
+         the type of a structured message body and to process it for
+         display accordingly".  [SMTP:7]  A User Agent MAY support this
+         field.
+
+      5.2.14  RFC-822 Date and Time Specification: RFC-822 Section 5
+
+         The syntax for the date is hereby changed to:
+
+            date = 1*2DIGIT month 2*4DIGIT
+
+
+
+
+Internet Engineering Task Force                                [Page 55]
+
+
+
+
+RFC1123                  MAIL -- SMTP & RFC-822             October 1989
+
+
+         All mail software SHOULD use 4-digit years in dates, to ease
+         the transition to the next century.
+
+         There is a strong trend towards the use of numeric timezone
+         indicators, and implementations SHOULD use numeric timezones
+         instead of timezone names.  However, all implementations MUST
+         accept either notation.  If timezone names are used, they MUST
+         be exactly as defined in RFC-822.
+
+         The military time zones are specified incorrectly in RFC-822:
+         they count the wrong way from UT (the signs are reversed).  As
+         a result, military time zones in RFC-822 headers carry no
+         information.
+
+         Finally, note that there is a typo in the definition of "zone"
+         in the syntax summary of appendix D; the correct definition
+         occurs in Section 3 of RFC-822.
+
+      5.2.15  RFC-822 Syntax Change: RFC-822 Section 6.1
+
+         The syntactic definition of "mailbox" in RFC-822 is hereby
+         changed to:
+
+            mailbox =  addr-spec            ; simple address
+                    / [phrase] route-addr   ; name & addr-spec
+
+         That is, the phrase preceding a route address is now OPTIONAL.
+         This change makes the following header field legal, for
+         example:
+
+             From: <craig@nnsc.nsf.net>
+
+      5.2.16  RFC-822  Local-part: RFC-822 Section 6.2
+
+         The basic mailbox address specification has the form: "local-
+         part@domain".  Here "local-part", sometimes called the "left-
+         hand side" of the address, is domain-dependent.
+
+         A host that is forwarding the message but is not the
+         destination host implied by the right-hand side "domain" MUST
+         NOT interpret or modify the "local-part" of the address.
+
+         When mail is to be gatewayed from the Internet mail environment
+         into a foreign mail environment (see Section 5.3.7), routing
+         information for that foreign environment MAY be embedded within
+         the "local-part" of the address.  The gateway will then
+         interpret this local part appropriately for the foreign mail
+         environment.
+
+
+
+Internet Engineering Task Force                                [Page 56]
+
+
+
+
+RFC1123                  MAIL -- SMTP & RFC-822             October 1989
+
+
+         DISCUSSION:
+              Although source routes are discouraged within the Internet
+              (see Section 5.2.6), there are non-Internet mail
+              environments whose delivery mechanisms do depend upon
+              source routes.  Source routes for extra-Internet
+              environments can generally be buried in the "local-part"
+              of the address (see Section 5.2.16) while mail traverses
+              the Internet.  When the mail reaches the appropriate
+              Internet mail gateway, the gateway will interpret the
+              local-part and build the necessary address or route for
+              the target mail environment.
+
+              For example, an Internet host might send mail to:
+              "a!b!c!user@gateway-domain".  The complex local part
+              "a!b!c!user" would be uninterpreted within the Internet
+              domain, but could be parsed and understood by the
+              specified mail gateway.
+
+              An embedded source route is sometimes encoded in the
+              "local-part" using "%" as a right-binding routing
+              operator.  For example, in:
+
+                 user%domain%relay3%relay2@relay1
+
+              the "%" convention implies that the mail is to be routed
+              from "relay1" through "relay2", "relay3", and finally to
+              "user" at "domain".  This is commonly known as the "%-
+              hack".  It is suggested that "%" have lower precedence
+              than any other routing operator (e.g., "!") hidden in the
+              local-part; for example, "a!b%c" would be interpreted as
+              "(a!b)%c".
+
+              Only the target host (in this case, "relay1") is permitted
+              to analyze the local-part "user%domain%relay3%relay2".
+
+      5.2.17  Domain Literals: RFC-822 Section 6.2.3
+
+         A mailer MUST be able to accept and parse an Internet domain
+         literal whose content ("dtext"; see RFC-822) is a dotted-
+         decimal host address.  This satisfies the requirement of
+         Section 2.1 for the case of mail.
+
+         An SMTP MUST accept and recognize a domain literal for any of
+         its own IP addresses.
+
+
+
+
+
+
+
+Internet Engineering Task Force                                [Page 57]
+
+
+
+
+RFC1123                  MAIL -- SMTP & RFC-822             October 1989
+
+
+      5.2.18  Common Address Formatting Errors: RFC-822 Section 6.1
+
+         Errors in formatting or parsing 822 addresses are unfortunately
+         common.  This section mentions only the most common errors.  A
+         User Agent MUST accept all valid RFC-822 address formats, and
+         MUST NOT generate illegal address syntax.
+
+         o    A common error is to leave out the semicolon after a group
+              identifier.
+
+         o    Some systems fail to fully-qualify domain names in
+              messages they generate.  The right-hand side of an "@"
+              sign in a header address field MUST be a fully-qualified
+              domain name.
+
+              For example, some systems fail to fully-qualify the From:
+              address; this prevents a "reply" command in the user
+              interface from automatically constructing a return
+              address.
+
+              DISCUSSION:
+                   Although RFC-822 allows the local use of abbreviated
+                   domain names within a domain, the application of
+                   RFC-822 in Internet mail does not allow this.  The
+                   intent is that an Internet host must not send an SMTP
+                   message header containing an abbreviated domain name
+                   in an address field.  This allows the address fields
+                   of the header to be passed without alteration across
+                   the Internet, as required in Section 5.2.6.
+
+         o    Some systems mis-parse multiple-hop explicit source routes
+              such as:
+
+                  @relay1,@relay2,@relay3:user@domain.
+
+
+         o    Some systems over-qualify domain names by adding a
+              trailing dot to some or all domain names in addresses or
+              message-ids.  This violates RFC-822 syntax.
+
+
+      5.2.19  Explicit Source Routes: RFC-822 Section 6.2.7
+
+         Internet host software SHOULD NOT create an RFC-822 header
+         containing an address with an explicit source route, but MUST
+         accept such headers for compatibility with earlier systems.
+
+         DISCUSSION:
+
+
+
+Internet Engineering Task Force                                [Page 58]
+
+
+
+
+RFC1123                  MAIL -- SMTP & RFC-822             October 1989
+
+
+              In an understatement, RFC-822 says "The use of explicit
+              source routing is discouraged".  Many hosts implemented
+              RFC-822 source routes incorrectly, so the syntax cannot be
+              used unambiguously in practice.  Many users feel the
+              syntax is ugly.  Explicit source routes are not needed in
+              the mail envelope for delivery; see Section 5.2.6.  For
+              all these reasons, explicit source routes using the RFC-
+              822 notations are not to be used in Internet mail headers.
+
+              As stated in Section 5.2.16, it is necessary to allow an
+              explicit source route to be buried in the local-part of an
+              address, e.g., using the "%-hack", in order to allow mail
+              to be gatewayed into another environment in which explicit
+              source routing is necessary.  The vigilant will observe
+              that there is no way for a User Agent to detect and
+              prevent the use of such implicit source routing when the
+              destination is within the Internet.  We can only
+              discourage source routing of any kind within the Internet,
+              as unnecessary and undesirable.
+
+   5.3  SPECIFIC ISSUES
+
+      5.3.1  SMTP Queueing Strategies
+
+         The common structure of a host SMTP implementation includes
+         user mailboxes, one or more areas for queueing messages in
+         transit, and one or more daemon processes for sending and
+         receiving mail.  The exact structure will vary depending on the
+         needs of the users on the host and the number and size of
+         mailing lists supported by the host.  We describe several
+         optimizations that have proved helpful, particularly for
+         mailers supporting high traffic levels.
+
+         Any queueing strategy MUST include:
+
+         o    Timeouts on all activities.  See Section 5.3.2.
+
+         o    Never sending error messages in response to error
+              messages.
+
+
+         5.3.1.1 Sending Strategy
+
+            The general model of a sender-SMTP is one or more processes
+            that periodically attempt to transmit outgoing mail.  In a
+            typical system, the program that composes a message has some
+            method for requesting immediate attention for a new piece of
+            outgoing mail, while mail that cannot be transmitted
+
+
+
+Internet Engineering Task Force                                [Page 59]
+
+
+
+
+RFC1123                  MAIL -- SMTP & RFC-822             October 1989
+
+
+            immediately MUST be queued and periodically retried by the
+            sender.  A mail queue entry will include not only the
+            message itself but also the envelope information.
+
+            The sender MUST delay retrying a particular destination
+            after one attempt has failed.  In general, the retry
+            interval SHOULD be at least 30 minutes; however, more
+            sophisticated and variable strategies will be beneficial
+            when the sender-SMTP can determine the reason for non-
+            delivery.
+
+            Retries continue until the message is transmitted or the
+            sender gives up; the give-up time generally needs to be at
+            least 4-5 days.  The parameters to the retry algorithm MUST
+            be configurable.
+
+            A sender SHOULD keep a list of hosts it cannot reach and
+            corresponding timeouts, rather than just retrying queued
+            mail items.
+
+            DISCUSSION:
+                 Experience suggests that failures are typically
+                 transient (the target system has crashed), favoring a
+                 policy of two connection attempts in the first hour the
+                 message is in the queue, and then backing off to once
+                 every two or three hours.
+
+                 The sender-SMTP can shorten the queueing delay by
+                 cooperation with the receiver-SMTP.  In particular, if
+                 mail is received from a particular address, it is good
+                 evidence that any mail queued for that host can now be
+                 sent.
+
+                 The strategy may be further modified as a result of
+                 multiple addresses per host (see Section 5.3.4), to
+                 optimize delivery time vs. resource usage.
+
+                 A sender-SMTP may have a large queue of messages for
+                 each unavailable destination host, and if it retried
+                 all these messages in every retry cycle, there would be
+                 excessive Internet overhead and the daemon would be
+                 blocked for a long period.  Note that an SMTP can
+                 generally determine that a delivery attempt has failed
+                 only after a timeout of a minute or more; a one minute
+                 timeout per connection will result in a very large
+                 delay if it is repeated for dozens or even hundreds of
+                 queued messages.
+
+
+
+
+Internet Engineering Task Force                                [Page 60]
+
+
+
+
+RFC1123                  MAIL -- SMTP & RFC-822             October 1989
+
+
+            When the same message is to be delivered to several users on
+            the same host, only one copy of the message SHOULD be
+            transmitted.  That is, the sender-SMTP should use the
+            command sequence: RCPT, RCPT,... RCPT, DATA instead of the
+            sequence: RCPT, DATA, RCPT, DATA,... RCPT, DATA.
+            Implementation of this efficiency feature is strongly urged.
+
+            Similarly, the sender-SMTP MAY support multiple concurrent
+            outgoing mail transactions to achieve timely delivery.
+            However, some limit SHOULD be imposed to protect the host
+            from devoting all its resources to mail.
+
+            The use of the different addresses of a multihomed host is
+            discussed below.
+
+         5.3.1.2  Receiving strategy
+
+            The receiver-SMTP SHOULD attempt to keep a pending listen on
+            the SMTP port at all times.  This will require the support
+            of multiple incoming TCP connections for SMTP.  Some limit
+            MAY be imposed.
+
+            IMPLEMENTATION:
+                 When the receiver-SMTP receives mail from a particular
+                 host address, it could notify the sender-SMTP to retry
+                 any mail pending for that host address.
+
+      5.3.2  Timeouts in SMTP
+
+         There are two approaches to timeouts in the sender-SMTP:  (a)
+         limit the time for each SMTP command separately, or (b) limit
+         the time for the entire SMTP dialogue for a single mail
+         message.  A sender-SMTP SHOULD use option (a), per-command
+         timeouts.  Timeouts SHOULD be easily reconfigurable, preferably
+         without recompiling the SMTP code.
+
+         DISCUSSION:
+              Timeouts are an essential feature of an SMTP
+              implementation.  If the timeouts are too long (or worse,
+              there are no timeouts), Internet communication failures or
+              software bugs in receiver-SMTP programs can tie up SMTP
+              processes indefinitely.  If the timeouts are too short,
+              resources will be wasted with attempts that time out part
+              way through message delivery.
+
+              If option (b) is used, the timeout has to be very large,
+              e.g., an hour, to allow time to expand very large mailing
+              lists.  The timeout may also need to increase linearly
+
+
+
+Internet Engineering Task Force                                [Page 61]
+
+
+
+
+RFC1123                  MAIL -- SMTP & RFC-822             October 1989
+
+
+              with the size of the message, to account for the time to
+              transmit a very large message.  A large fixed timeout
+              leads to two problems:  a failure can still tie up the
+              sender for a very long time, and very large messages may
+              still spuriously time out (which is a wasteful failure!).
+
+              Using the recommended option (a), a timer is set for each
+              SMTP command and for each buffer of the data transfer.
+              The latter means that the overall timeout is inherently
+              proportional to the size of the message.
+
+         Based on extensive experience with busy mail-relay hosts, the
+         minimum per-command timeout values SHOULD be as follows:
+
+         o    Initial 220 Message: 5 minutes
+
+              A Sender-SMTP process needs to distinguish between a
+              failed TCP connection and a delay in receiving the initial
+              220 greeting message.  Many receiver-SMTPs will accept a
+              TCP connection but delay delivery of the 220 message until
+              their system load will permit more mail to be processed.
+
+         o    MAIL Command: 5 minutes
+
+
+         o    RCPT Command: 5 minutes
+
+              A longer timeout would be required if processing of
+              mailing lists and aliases were not deferred until after
+              the message was accepted.
+
+         o    DATA Initiation: 2 minutes
+
+              This is while awaiting the "354 Start Input" reply to a
+              DATA command.
+
+         o    Data Block: 3 minutes
+
+              This is while awaiting the completion of each TCP SEND
+              call transmitting a chunk of data.
+
+         o    DATA Termination: 10 minutes.
+
+              This is while awaiting the "250 OK" reply. When the
+              receiver gets the final period terminating the message
+              data, it typically performs processing to deliver the
+              message to a user mailbox.  A spurious timeout at this
+              point would be very wasteful, since the message has been
+
+
+
+Internet Engineering Task Force                                [Page 62]
+
+
+
+
+RFC1123                  MAIL -- SMTP & RFC-822             October 1989
+
+
+              successfully sent.
+
+         A receiver-SMTP SHOULD have a timeout of at least 5 minutes
+         while it is awaiting the next command from the sender.
+
+      5.3.3  Reliable Mail Receipt
+
+         When the receiver-SMTP accepts a piece of mail (by sending a
+         "250 OK" message in response to DATA), it is accepting
+         responsibility for delivering or relaying the message.  It must
+         take this responsibility seriously, i.e., it MUST NOT lose the
+         message for frivolous reasons, e.g., because the host later
+         crashes or because of a predictable resource shortage.
+
+         If there is a delivery failure after acceptance of a message,
+         the receiver-SMTP MUST formulate and mail a notification
+         message.  This notification MUST be sent using a null ("<>")
+         reverse path in the envelope; see Section 3.6 of RFC-821.  The
+         recipient of this notification SHOULD be the address from the
+         envelope return path (or the Return-Path: line).  However, if
+         this address is null ("<>"),  the receiver-SMTP MUST NOT send a
+         notification.  If the address is an explicit source route, it
+         SHOULD be stripped down to its final hop.
+
+         DISCUSSION:
+              For example, suppose that an error notification must be
+              sent for a message that arrived with:
+              "MAIL FROM:<@a,@b:user@d>".  The notification message
+              should be sent to: "RCPT TO:<user@d>".
+
+              Some delivery failures after the message is accepted by
+              SMTP will be unavoidable.  For example, it may be
+              impossible for the receiver-SMTP to validate all the
+              delivery addresses in RCPT command(s) due to a "soft"
+              domain system error or because the target is a mailing
+              list (see earlier discussion of RCPT).
+
+         To avoid receiving duplicate messages as the result of
+         timeouts, a receiver-SMTP MUST seek to minimize the time
+         required to respond to the final "." that ends a message
+         transfer.  See RFC-1047 [SMTP:4] for a discussion of this
+         problem.
+
+      5.3.4  Reliable Mail Transmission
+
+         To transmit a message, a sender-SMTP determines the IP address
+         of the target host from the destination address in the
+         envelope.  Specifically, it maps the string to the right of the
+
+
+
+Internet Engineering Task Force                                [Page 63]
+
+
+
+
+RFC1123                  MAIL -- SMTP & RFC-822             October 1989
+
+
+         "@" sign into an IP address.  This mapping or the transfer
+         itself may fail with a soft error, in which case the sender-
+         SMTP will requeue the outgoing mail for a later retry, as
+         required in Section 5.3.1.1.
+
+         When it succeeds, the mapping can result in a list of
+         alternative delivery addresses rather than a single address,
+         because of (a) multiple MX records, (b) multihoming, or both.
+         To provide reliable mail transmission, the sender-SMTP MUST be
+         able to try (and retry) each of the addresses in this list in
+         order, until a delivery attempt succeeds.  However, there MAY
+         also be a configurable limit on the number of alternate
+         addresses that can be tried.  In any case, a host SHOULD try at
+         least two addresses.
+
+         The following information is to be used to rank the host
+         addresses:
+
+         (1)  Multiple MX Records -- these contain a preference
+              indication that should be used in sorting.  If there are
+              multiple destinations with the same preference and there
+              is no clear reason to favor one (e.g., by address
+              preference), then the sender-SMTP SHOULD pick one at
+              random to spread the load across multiple mail exchanges
+              for a specific organization; note that this is a
+              refinement of the procedure in [DNS:3].
+
+         (2)  Multihomed host -- The destination host (perhaps taken
+              from the preferred MX record) may be multihomed, in which
+              case the domain name resolver will return a list of
+              alternative IP addresses.  It is the responsibility of the
+              domain name resolver interface (see Section 6.1.3.4 below)
+              to have ordered this list by decreasing preference, and
+              SMTP MUST try them in the order presented.
+
+         DISCUSSION:
+              Although the capability to try multiple alternative
+              addresses is required, there may be circumstances where
+              specific installations want to limit or disable the use of
+              alternative addresses.  The question of whether a sender
+              should attempt retries using the different addresses of a
+              multihomed host has been controversial.  The main argument
+              for using the multiple addresses is that it maximizes the
+              probability of timely delivery, and indeed sometimes the
+              probability of any delivery; the counter argument is that
+              it may result in unnecessary resource use.
+
+              Note that resource use is also strongly determined by the
+
+
+
+Internet Engineering Task Force                                [Page 64]
+
+
+
+
+RFC1123                  MAIL -- SMTP & RFC-822             October 1989
+
+
+              sending strategy discussed in Section 5.3.1.
+
+      5.3.5  Domain Name Support
+
+         SMTP implementations MUST use the mechanism defined in Section
+         6.1 for mapping between domain names and IP addresses.  This
+         means that every Internet SMTP MUST include support for the
+         Internet DNS.
+
+         In particular, a sender-SMTP MUST support the MX record scheme
+         [SMTP:3].  See also Section 7.4 of [DNS:2] for information on
+         domain name support for SMTP.
+
+      5.3.6  Mailing Lists and Aliases
+
+         An SMTP-capable host SHOULD support both the alias and the list
+         form of address expansion for multiple delivery.  When a
+         message is delivered or forwarded to each address of an
+         expanded list form, the return address in the envelope
+         ("MAIL FROM:") MUST be changed to be the address of a person
+         who administers the list, but the message header MUST be left
+         unchanged; in particular, the "From" field of the message is
+         unaffected.
+
+         DISCUSSION:
+              An important mail facility is a mechanism for multi-
+              destination delivery of a single message, by transforming
+              or "expanding" a pseudo-mailbox address into a list of
+              destination mailbox addresses.  When a message is sent to
+              such a pseudo-mailbox (sometimes called an "exploder"),
+              copies are forwarded or redistributed to each mailbox in
+              the expanded list.  We classify such a pseudo-mailbox as
+              an "alias" or a "list", depending upon the expansion
+              rules:
+
+              (a)  Alias
+
+                   To expand an alias, the recipient mailer simply
+                   replaces the pseudo-mailbox address in the envelope
+                   with each of the expanded addresses in turn; the rest
+                   of the envelope and the message body are left
+                   unchanged.  The message is then delivered or
+                   forwarded to each expanded address.
+
+              (b)  List
+
+                   A mailing list may be said to operate by
+                   "redistribution" rather than by "forwarding".  To
+
+
+
+Internet Engineering Task Force                                [Page 65]
+
+
+
+
+RFC1123                  MAIL -- SMTP & RFC-822             October 1989
+
+
+                   expand a list, the recipient mailer replaces the
+                   pseudo-mailbox address in the envelope with each of
+                   the expanded addresses in turn. The return address in
+                   the envelope is changed so that all error messages
+                   generated by the final deliveries will be returned to
+                   a list administrator, not to the message originator,
+                   who generally has no control over the contents of the
+                   list and will typically find error messages annoying.
+
+
+      5.3.7  Mail Gatewaying
+
+         Gatewaying mail between different mail environments, i.e.,
+         different mail formats and protocols, is complex and does not
+         easily yield to standardization.  See for example [SMTP:5a],
+         [SMTP:5b].  However, some general requirements may be given for
+         a gateway between the Internet and another mail environment.
+
+         (A)  Header fields MAY be rewritten when necessary as messages
+              are gatewayed across mail environment boundaries.
+
+              DISCUSSION:
+                   This may involve interpreting the local-part of the
+                   destination address, as suggested in Section 5.2.16.
+
+                   The other mail systems gatewayed to the Internet
+                   generally use a subset of RFC-822 headers, but some
+                   of them do not have an equivalent to the SMTP
+                   envelope.  Therefore, when a message leaves the
+                   Internet environment, it may be necessary to fold the
+                   SMTP envelope information into the message header.  A
+                   possible solution would be to create new header
+                   fields to carry the envelope information (e.g., "X-
+                   SMTP-MAIL:" and "X-SMTP-RCPT:"); however, this would
+                   require changes in mail programs in the foreign
+                   environment.
+
+         (B)  When forwarding a message into or out of the Internet
+              environment, a gateway MUST prepend a Received: line, but
+              it MUST NOT alter in any way a Received: line that is
+              already in the header.
+
+              DISCUSSION:
+                   This requirement is a subset of the general
+                   "Received:" line requirement of Section 5.2.8; it is
+                   restated here for emphasis.
+
+                   Received: fields of messages originating from other
+
+
+
+Internet Engineering Task Force                                [Page 66]
+
+
+
+
+RFC1123                  MAIL -- SMTP & RFC-822             October 1989
+
+
+                   environments may not conform exactly to RFC822.
+                   However, the most important use of Received: lines is
+                   for debugging mail faults, and this debugging can be
+                   severely hampered by well-meaning gateways that try
+                   to "fix" a Received: line.
+
+                   The gateway is strongly encouraged to indicate the
+                   environment and protocol in the "via" clauses of
+                   Received field(s) that it supplies.
+
+         (C)  From the Internet side, the gateway SHOULD accept all
+              valid address formats in SMTP commands and in RFC-822
+              headers, and all valid RFC-822 messages.  Although a
+              gateway must accept an RFC-822 explicit source route
+              ("@...:" format) in either the RFC-822 header or in the
+              envelope, it MAY or may not act on the source route; see
+              Sections 5.2.6 and 5.2.19.
+
+              DISCUSSION:
+                   It is often tempting to restrict the range of
+                   addresses accepted at the mail gateway to simplify
+                   the translation into addresses for the remote
+                   environment.  This practice is based on the
+                   assumption that mail users have control over the
+                   addresses their mailers send to the mail gateway.  In
+                   practice, however, users have little control over the
+                   addresses that are finally sent; their mailers are
+                   free to change addresses into any legal RFC-822
+                   format.
+
+         (D)  The gateway MUST ensure that all header fields of a
+              message that it forwards into the Internet meet the
+              requirements for Internet mail.  In particular, all
+              addresses in "From:", "To:", "Cc:", etc., fields must be
+              transformed (if necessary) to satisfy RFC-822 syntax, and
+              they must be effective and useful for sending replies.
+
+
+         (E)  The translation algorithm used to convert mail from the
+              Internet protocols to another environment's protocol
+              SHOULD try to ensure that error messages from the foreign
+              mail environment are delivered to the return path from the
+              SMTP envelope, not to the sender listed in the "From:"
+              field of the RFC-822 message.
+
+              DISCUSSION:
+                   Internet mail lists usually place the address of the
+                   mail list maintainer in the envelope but leave the
+
+
+
+Internet Engineering Task Force                                [Page 67]
+
+
+
+
+RFC1123                  MAIL -- SMTP & RFC-822             October 1989
+
+
+                   original message header intact (with the "From:"
+                   field containing the original sender).  This yields
+                   the behavior the average recipient expects: a reply
+                   to the header gets sent to the original sender, not
+                   to a mail list maintainer; however, errors get sent
+                   to the maintainer (who can fix the problem) and not
+                   the sender (who probably cannot).
+
+         (F)  Similarly, when forwarding a message from another
+              environment into the Internet, the gateway SHOULD set the
+              envelope return path in accordance with an error message
+              return address, if any, supplied by the foreign
+              environment.
+
+
+      5.3.8  Maximum Message Size
+
+         Mailer software MUST be able to send and receive messages of at
+         least 64K bytes in length (including header), and a much larger
+         maximum size is highly desirable.
+
+         DISCUSSION:
+              Although SMTP does not define the maximum size of a
+              message, many systems impose implementation limits.
+
+              The current de facto minimum limit in the Internet is 64K
+              bytes.  However, electronic mail is used for a variety of
+              purposes that create much larger messages.  For example,
+              mail is often used instead of FTP for transmitting ASCII
+              files, and in particular to transmit entire documents.  As
+              a result, messages can be 1 megabyte or even larger.  We
+              note that the present document together with its lower-
+              layer companion contains 0.5 megabytes.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Internet Engineering Task Force                                [Page 68]
+
+
+
+
+RFC1123                  MAIL -- SMTP & RFC-822             October 1989
+
+
+   5.4  SMTP REQUIREMENTS SUMMARY
+
+                                               |          | | | |S| |
+                                               |          | | | |H| |F
+                                               |          | | | |O|M|o
+                                               |          | |S| |U|U|o
+                                               |          | |H| |L|S|t
+                                               |          |M|O| |D|T|n
+                                               |          |U|U|M| | |o
+                                               |          |S|L|A|N|N|t
+                                               |          |T|D|Y|O|O|t
+FEATURE                                        |SECTION   | | | |T|T|e
+-----------------------------------------------|----------|-|-|-|-|-|--
+                                               |          | | | | | |
+RECEIVER-SMTP:                                 |          | | | | | |
+  Implement VRFY                               |5.2.3     |x| | | | |
+  Implement EXPN                               |5.2.3     | |x| | | |
+    EXPN, VRFY configurable                    |5.2.3     | | |x| | |
+  Implement SEND, SOML, SAML                   |5.2.4     | | |x| | |
+  Verify HELO parameter                        |5.2.5     | | |x| | |
+    Refuse message with bad HELO               |5.2.5     | | | | |x|
+  Accept explicit src-route syntax in env.     |5.2.6     |x| | | | |
+  Support "postmaster"                         |5.2.7     |x| | | | |
+  Process RCPT when received (except lists)    |5.2.7     | | |x| | |
+      Long delay of RCPT responses             |5.2.7     | | | | |x|
+                                               |          | | | | | |
+  Add Received: line                           |5.2.8     |x| | | | |
+      Received: line include domain literal    |5.2.8     | |x| | | |
+  Change previous Received: line               |5.2.8     | | | | |x|
+  Pass Return-Path info (final deliv/gwy)      |5.2.8     |x| | | | |
+  Support empty reverse path                   |5.2.9     |x| | | | |
+  Send only official reply codes               |5.2.10    | |x| | | |
+  Send text from RFC-821 when appropriate      |5.2.10    | |x| | | |
+  Delete "." for transparency                  |5.2.11    |x| | | | |
+  Accept and recognize self domain literal(s)  |5.2.17    |x| | | | |
+                                               |          | | | | | |
+  Error message about error message            |5.3.1     | | | | |x|
+  Keep pending listen on SMTP port             |5.3.1.2   | |x| | | |
+  Provide limit on recv concurrency            |5.3.1.2   | | |x| | |
+  Wait at least 5 mins for next sender cmd     |5.3.2     | |x| | | |
+  Avoidable delivery failure after "250 OK"    |5.3.3     | | | | |x|
+  Send error notification msg after accept     |5.3.3     |x| | | | |
+    Send using null return path                |5.3.3     |x| | | | |
+    Send to envelope return path               |5.3.3     | |x| | | |
+    Send to null address                       |5.3.3     | | | | |x|
+    Strip off explicit src route               |5.3.3     | |x| | | |
+  Minimize acceptance delay (RFC-1047)         |5.3.3     |x| | | | |
+-----------------------------------------------|----------|-|-|-|-|-|--
+
+
+
+Internet Engineering Task Force                                [Page 69]
+
+
+
+
+RFC1123                  MAIL -- SMTP & RFC-822             October 1989
+
+
+                                               |          | | | | | |
+SENDER-SMTP:                                   |          | | | | | |
+  Canonicalized domain names in MAIL, RCPT     |5.2.2     |x| | | | |
+  Implement SEND, SOML, SAML                   |5.2.4     | | |x| | |
+  Send valid principal host name in HELO       |5.2.5     |x| | | | |
+  Send explicit source route in RCPT TO:       |5.2.6     | | | |x| |
+  Use only reply code to determine action      |5.2.10    |x| | | | |
+  Use only high digit of reply code when poss. |5.2.10    | |x| | | |
+  Add "." for transparency                     |5.2.11    |x| | | | |
+                                               |          | | | | | |
+  Retry messages after soft failure            |5.3.1.1   |x| | | | |
+    Delay before retry                         |5.3.1.1   |x| | | | |
+    Configurable retry parameters              |5.3.1.1   |x| | | | |
+    Retry once per each queued dest host       |5.3.1.1   | |x| | | |
+  Multiple RCPT's for same DATA                |5.3.1.1   | |x| | | |
+  Support multiple concurrent transactions     |5.3.1.1   | | |x| | |
+    Provide limit on concurrency               |5.3.1.1   | |x| | | |
+                                               |          | | | | | |
+  Timeouts on all activities                   |5.3.1     |x| | | | |
+    Per-command timeouts                       |5.3.2     | |x| | | |
+    Timeouts easily reconfigurable             |5.3.2     | |x| | | |
+    Recommended times                          |5.3.2     | |x| | | |
+  Try alternate addr's in order                |5.3.4     |x| | | | |
+    Configurable limit on alternate tries      |5.3.4     | | |x| | |
+    Try at least two alternates                |5.3.4     | |x| | | |
+  Load-split across equal MX alternates        |5.3.4     | |x| | | |
+  Use the Domain Name System                   |5.3.5     |x| | | | |
+    Support MX records                         |5.3.5     |x| | | | |
+    Use WKS records in MX processing           |5.2.12    | | | |x| |
+-----------------------------------------------|----------|-|-|-|-|-|--
+                                               |          | | | | | |
+MAIL FORWARDING:                               |          | | | | | |
+  Alter existing header field(s)               |5.2.6     | | | |x| |
+  Implement relay function: 821/section 3.6    |5.2.6     | | |x| | |
+    If not, deliver to RHS domain              |5.2.6     | |x| | | |
+  Interpret 'local-part' of addr               |5.2.16    | | | | |x|
+                                               |          | | | | | |
+MAILING LISTS AND ALIASES                      |          | | | | | |
+  Support both                                 |5.3.6     | |x| | | |
+  Report mail list error to local admin.       |5.3.6     |x| | | | |
+                                               |          | | | | | |
+MAIL GATEWAYS:                                 |          | | | | | |
+  Embed foreign mail route in local-part       |5.2.16    | | |x| | |
+  Rewrite header fields when necessary         |5.3.7     | | |x| | |
+  Prepend Received: line                       |5.3.7     |x| | | | |
+  Change existing Received: line               |5.3.7     | | | | |x|
+  Accept full RFC-822 on Internet side         |5.3.7     | |x| | | |
+  Act on RFC-822 explicit source route         |5.3.7     | | |x| | |
+
+
+
+Internet Engineering Task Force                                [Page 70]
+
+
+
+
+RFC1123                  MAIL -- SMTP & RFC-822             October 1989
+
+
+  Send only valid RFC-822 on Internet side     |5.3.7     |x| | | | |
+  Deliver error msgs to envelope addr          |5.3.7     | |x| | | |
+  Set env return path from err return addr     |5.3.7     | |x| | | |
+                                               |          | | | | | |
+USER AGENT -- RFC-822                          |          | | | | | |
+  Allow user to enter <route> address          |5.2.6     | | | |x| |
+  Support RFC-1049 Content Type field          |5.2.13    | | |x| | |
+  Use 4-digit years                            |5.2.14    | |x| | | |
+  Generate numeric timezones                   |5.2.14    | |x| | | |
+  Accept all timezones                         |5.2.14    |x| | | | |
+  Use non-num timezones from RFC-822           |5.2.14    |x| | | | |
+  Omit phrase before route-addr                |5.2.15    | | |x| | |
+  Accept and parse dot.dec. domain literals    |5.2.17    |x| | | | |
+  Accept all RFC-822 address formats           |5.2.18    |x| | | | |
+  Generate invalid RFC-822 address format      |5.2.18    | | | | |x|
+  Fully-qualified domain names in header       |5.2.18    |x| | | | |
+  Create explicit src route in header          |5.2.19    | | | |x| |
+  Accept explicit src route in header          |5.2.19    |x| | | | |
+                                               |          | | | | | |
+Send/recv at least 64KB messages               |5.3.8     |x| | | | |
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Internet Engineering Task Force                                [Page 71]
+
+
+
+
+RFC1123               SUPPORT SERVICES -- DOMAINS           October 1989
+
+
+6. SUPPORT SERVICES
+
+   6.1 DOMAIN NAME TRANSLATION
+
+      6.1.1 INTRODUCTION
+
+         Every host MUST implement a resolver for the Domain Name System
+         (DNS), and it MUST implement a mechanism using this DNS
+         resolver to convert host names to IP addresses and vice-versa
+         [DNS:1, DNS:2].
+
+         In addition to the DNS, a host MAY also implement a host name
+         translation mechanism that searches a local Internet host
+         table.  See Section 6.1.3.8 for more information on this
+         option.
+
+         DISCUSSION:
+              Internet host name translation was originally performed by
+              searching local copies of a table of all hosts.  This
+              table became too large to update and distribute in a
+              timely manner and too large to fit into many hosts, so the
+              DNS was invented.
+
+              The DNS creates a distributed database used primarily for
+              the translation between host names and host addresses.
+              Implementation of DNS software is required.  The DNS
+              consists of two logically distinct parts: name servers and
+              resolvers (although implementations often combine these
+              two logical parts in the interest of efficiency) [DNS:2].
+
+              Domain name servers store authoritative data about certain
+              sections of the database and answer queries about the
+              data.  Domain resolvers query domain name servers for data
+              on behalf of user processes.  Every host therefore needs a
+              DNS resolver; some host machines will also need to run
+              domain name servers.  Since no name server has complete
+              information, in general it is necessary to obtain
+              information from more than one name server to resolve a
+              query.
+
+      6.1.2  PROTOCOL WALK-THROUGH
+
+         An implementor must study references [DNS:1] and [DNS:2]
+         carefully.  They provide a thorough description of the theory,
+         protocol, and implementation of the domain name system, and
+         reflect several years of experience.
+
+
+
+
+
+Internet Engineering Task Force                                [Page 72]
+
+
+
+
+RFC1123               SUPPORT SERVICES -- DOMAINS           October 1989
+
+
+         6.1.2.1  Resource Records with Zero TTL: RFC-1035 Section 3.2.1
+
+            All DNS name servers and resolvers MUST properly handle RRs
+            with a zero TTL: return the RR to the client but do not
+            cache it.
+
+            DISCUSSION:
+                 Zero TTL values are interpreted to mean that the RR can
+                 only be used for the transaction in progress, and
+                 should not be cached; they are useful for extremely
+                 volatile data.
+
+         6.1.2.2  QCLASS Values: RFC-1035 Section 3.2.5
+
+            A query with "QCLASS=*" SHOULD NOT be used unless the
+            requestor is seeking data from more than one class.  In
+            particular, if the requestor is only interested in Internet
+            data types, QCLASS=IN MUST be used.
+
+         6.1.2.3  Unused Fields: RFC-1035 Section 4.1.1
+
+            Unused fields in a query or response message MUST be zero.
+
+         6.1.2.4  Compression: RFC-1035 Section 4.1.4
+
+            Name servers MUST use compression in responses.
+
+            DISCUSSION:
+                 Compression is essential to avoid overflowing UDP
+                 datagrams; see Section 6.1.3.2.
+
+         6.1.2.5  Misusing Configuration Info: RFC-1035 Section 6.1.2
+
+            Recursive name servers and full-service resolvers generally
+            have some configuration information containing hints about
+            the location of root or local name servers.  An
+            implementation MUST NOT include any of these hints in a
+            response.
+
+            DISCUSSION:
+                 Many implementors have found it convenient to store
+                 these hints as if they were cached data, but some
+                 neglected to ensure that this "cached data" was not
+                 included in responses.  This has caused serious
+                 problems in the Internet when the hints were obsolete
+                 or incorrect.
+
+
+
+
+
+Internet Engineering Task Force                                [Page 73]
+
+
+
+
+RFC1123               SUPPORT SERVICES -- DOMAINS           October 1989
+
+
+      6.1.3  SPECIFIC ISSUES
+
+         6.1.3.1  Resolver Implementation
+
+            A name resolver SHOULD be able to multiplex concurrent
+            requests if the host supports concurrent processes.
+
+            In implementing a DNS resolver, one of two different models
+            MAY optionally be chosen: a full-service resolver, or a stub
+            resolver.
+
+
+            (A)  Full-Service Resolver
+
+                 A full-service resolver is a complete implementation of
+                 the resolver service, and is capable of dealing with
+                 communication failures, failure of individual name
+                 servers, location of the proper name server for a given
+                 name, etc.  It must satisfy the following requirements:
+
+                 o    The resolver MUST implement a local caching
+                      function to avoid repeated remote access for
+                      identical requests, and MUST time out information
+                      in the cache.
+
+                 o    The resolver SHOULD be configurable with start-up
+                      information pointing to multiple root name servers
+                      and multiple name servers for the local domain.
+                      This insures that the resolver will be able to
+                      access the whole name space in normal cases, and
+                      will be able to access local domain information
+                      should the local network become disconnected from
+                      the rest of the Internet.
+
+
+            (B)  Stub Resolver
+
+                 A "stub resolver" relies on the services of a recursive
+                 name server on the connected network or a "nearby"
+                 network.  This scheme allows the host to pass on the
+                 burden of the resolver function to a name server on
+                 another host.  This model is often essential for less
+                 capable hosts, such as PCs, and is also recommended
+                 when the host is one of several workstations on a local
+                 network, because it allows all of the workstations to
+                 share the cache of the recursive name server and hence
+                 reduce the number of domain requests exported by the
+                 local network.
+
+
+
+Internet Engineering Task Force                                [Page 74]
+
+
+
+
+RFC1123               SUPPORT SERVICES -- DOMAINS           October 1989
+
+
+                 At a minimum, the stub resolver MUST be capable of
+                 directing its requests to redundant recursive name
+                 servers.  Note that recursive name servers are allowed
+                 to restrict the sources of requests that they will
+                 honor, so the host administrator must verify that the
+                 service will be provided.  Stub resolvers MAY implement
+                 caching if they choose, but if so, MUST timeout cached
+                 information.
+
+
+         6.1.3.2  Transport Protocols
+
+            DNS resolvers and recursive servers MUST support UDP, and
+            SHOULD support TCP, for sending (non-zone-transfer) queries.
+            Specifically, a DNS resolver or server that is sending a
+            non-zone-transfer query MUST send a UDP query first.  If the
+            Answer section of the response is truncated and if the
+            requester supports TCP, it SHOULD try the query again using
+            TCP.
+
+            DNS servers MUST be able to service UDP queries and SHOULD
+            be able to service TCP queries.  A name server MAY limit the
+            resources it devotes to TCP queries, but it SHOULD NOT
+            refuse to service a TCP query just because it would have
+            succeeded with UDP.
+
+            Truncated responses MUST NOT be saved (cached) and later
+            used in such a way that the fact that they are truncated is
+            lost.
+
+            DISCUSSION:
+                 UDP is preferred over TCP for queries because UDP
+                 queries have much lower overhead, both in packet count
+                 and in connection state.  The use of UDP is essential
+                 for heavily-loaded servers, especially the root
+                 servers.  UDP also offers additional robustness, since
+                 a resolver can attempt several UDP queries to different
+                 servers for the cost of a single TCP query.
+
+                 It is possible for a DNS response to be truncated,
+                 although this is a very rare occurrence in the present
+                 Internet DNS.  Practically speaking, truncation cannot
+                 be predicted, since it is data-dependent.  The
+                 dependencies include the number of RRs in the answer,
+                 the size of each RR, and the savings in space realized
+                 by the name compression algorithm.  As a rule of thumb,
+                 truncation in NS and MX lists should not occur for
+                 answers containing 15 or fewer RRs.
+
+
+
+Internet Engineering Task Force                                [Page 75]
+
+
+
+
+RFC1123               SUPPORT SERVICES -- DOMAINS           October 1989
+
+
+                 Whether it is possible to use a truncated answer
+                 depends on the application.  A mailer must not use a
+                 truncated MX response, since this could lead to mail
+                 loops.
+
+                 Responsible practices can make UDP suffice in the vast
+                 majority of cases.  Name servers must use compression
+                 in responses.  Resolvers must differentiate truncation
+                 of the Additional section of a response (which only
+                 loses extra information) from truncation of the Answer
+                 section (which for MX records renders the response
+                 unusable by mailers).  Database administrators should
+                 list only a reasonable number of primary names in lists
+                 of name servers, MX alternatives, etc.
+
+                 However, it is also clear that some new DNS record
+                 types defined in the future will contain information
+                 exceeding the 512 byte limit that applies to UDP, and
+                 hence will require TCP.  Thus, resolvers and name
+                 servers should implement TCP services as a backup to
+                 UDP today, with the knowledge that they will require
+                 the TCP service in the future.
+
+            By private agreement, name servers and resolvers MAY arrange
+            to use TCP for all traffic between themselves.  TCP MUST be
+            used for zone transfers.
+
+            A DNS server MUST have sufficient internal concurrency that
+            it can continue to process UDP queries while awaiting a
+            response or performing a zone transfer on an open TCP
+            connection [DNS:2].
+
+            A server MAY support a UDP query that is delivered using an
+            IP broadcast or multicast address.  However, the Recursion
+            Desired bit MUST NOT be set in a query that is multicast,
+            and MUST be ignored by name servers receiving queries via a
+            broadcast or multicast address.  A host that sends broadcast
+            or multicast DNS queries SHOULD send them only as occasional
+            probes, caching the IP address(es) it obtains from the
+            response(s) so it can normally send unicast queries.
+
+            DISCUSSION:
+                 Broadcast or (especially) IP multicast can provide a
+                 way to locate nearby name servers without knowing their
+                 IP addresses in advance.  However, general broadcasting
+                 of recursive queries can result in excessive and
+                 unnecessary load on both network and servers.
+
+
+
+
+Internet Engineering Task Force                                [Page 76]
+
+
+
+
+RFC1123               SUPPORT SERVICES -- DOMAINS           October 1989
+
+
+         6.1.3.3  Efficient Resource Usage
+
+            The following requirements on servers and resolvers are very
+            important to the health of the Internet as a whole,
+            particularly when DNS services are invoked repeatedly by
+            higher level automatic servers, such as mailers.
+
+            (1)  The resolver MUST implement retransmission controls to
+                 insure that it does not waste communication bandwidth,
+                 and MUST impose finite bounds on the resources consumed
+                 to respond to a single request.  See [DNS:2] pages 43-
+                 44 for specific recommendations.
+
+            (2)  After a query has been retransmitted several times
+                 without a response, an implementation MUST give up and
+                 return a soft error to the application.
+
+            (3)  All DNS name servers and resolvers SHOULD cache
+                 temporary failures, with a timeout period of the order
+                 of minutes.
+
+                 DISCUSSION:
+                      This will prevent applications that immediately
+                      retry soft failures (in violation of Section 2.2
+                      of this document) from generating excessive DNS
+                      traffic.
+
+            (4)  All DNS name servers and resolvers SHOULD cache
+                 negative responses that indicate the specified name, or
+                 data of the specified type, does not exist, as
+                 described in [DNS:2].
+
+            (5)  When a DNS server or resolver retries a UDP query, the
+                 retry interval SHOULD be constrained by an exponential
+                 backoff algorithm, and SHOULD also have upper and lower
+                 bounds.
+
+                 IMPLEMENTATION:
+                      A measured RTT and variance (if available) should
+                      be used to calculate an initial retransmission
+                      interval.  If this information is not available, a
+                      default of no less than 5 seconds should be used.
+                      Implementations may limit the retransmission
+                      interval, but this limit must exceed twice the
+                      Internet maximum segment lifetime plus service
+                      delay at the name server.
+
+            (6)  When a resolver or server receives a Source Quench for
+
+
+
+Internet Engineering Task Force                                [Page 77]
+
+
+
+
+RFC1123               SUPPORT SERVICES -- DOMAINS           October 1989
+
+
+                 a query it has issued, it SHOULD take steps to reduce
+                 the rate of querying that server in the near future.  A
+                 server MAY ignore a Source Quench that it receives as
+                 the result of sending a response datagram.
+
+                 IMPLEMENTATION:
+                      One recommended action to reduce the rate is to
+                      send the next query attempt to an alternate
+                      server, if there is one available.  Another is to
+                      backoff the retry interval for the same server.
+
+
+         6.1.3.4  Multihomed Hosts
+
+            When the host name-to-address function encounters a host
+            with multiple addresses, it SHOULD rank or sort the
+            addresses using knowledge of the immediately connected
+            network number(s) and any other applicable performance or
+            history information.
+
+            DISCUSSION:
+                 The different addresses of a multihomed host generally
+                 imply different Internet paths, and some paths may be
+                 preferable to others in performance, reliability, or
+                 administrative restrictions.  There is no general way
+                 for the domain system to determine the best path.  A
+                 recommended approach is to base this decision on local
+                 configuration information set by the system
+                 administrator.
+
+            IMPLEMENTATION:
+                 The following scheme has been used successfully:
+
+                 (a)  Incorporate into the host configuration data a
+                      Network-Preference List, that is simply a list of
+                      networks in preferred order.  This list may be
+                      empty if there is no preference.
+
+                 (b)  When a host name is mapped into a list of IP
+                      addresses, these addresses should be sorted by
+                      network number, into the same order as the
+                      corresponding networks in the Network-Preference
+                      List.  IP addresses whose networks do not appear
+                      in the Network-Preference List should be placed at
+                      the end of the list.
+
+
+
+
+
+
+Internet Engineering Task Force                                [Page 78]
+
+
+
+
+RFC1123               SUPPORT SERVICES -- DOMAINS           October 1989
+
+
+         6.1.3.5  Extensibility
+
+            DNS software MUST support all well-known, class-independent
+            formats [DNS:2], and SHOULD be written to minimize the
+            trauma associated with the introduction of new well-known
+            types and local experimentation with non-standard types.
+
+            DISCUSSION:
+                 The data types and classes used by the DNS are
+                 extensible, and thus new types will be added and old
+                 types deleted or redefined.  Introduction of new data
+                 types ought to be dependent only upon the rules for
+                 compression of domain names inside DNS messages, and
+                 the translation between printable (i.e., master file)
+                 and internal formats for Resource Records (RRs).
+
+                 Compression relies on knowledge of the format of data
+                 inside a particular RR.  Hence compression must only be
+                 used for the contents of well-known, class-independent
+                 RRs, and must never be used for class-specific RRs or
+                 RR types that are not well-known.  The owner name of an
+                 RR is always eligible for compression.
+
+                 A name server may acquire, via zone transfer, RRs that
+                 the server doesn't know how to convert to printable
+                 format.  A resolver can receive similar information as
+                 the result of queries.  For proper operation, this data
+                 must be preserved, and hence the implication is that
+                 DNS software cannot use textual formats for internal
+                 storage.
+
+                 The DNS defines domain name syntax very generally -- a
+                 string of labels each containing up to 63 8-bit octets,
+                 separated by dots, and with a maximum total of 255
+                 octets.  Particular applications of the DNS are
+                 permitted to further constrain the syntax of the domain
+                 names they use, although the DNS deployment has led to
+                 some applications allowing more general names.  In
+                 particular, Section 2.1 of this document liberalizes
+                 slightly the syntax of a legal Internet host name that
+                 was defined in RFC-952 [DNS:4].
+
+         6.1.3.6  Status of RR Types
+
+            Name servers MUST be able to load all RR types except MD and
+            MF from configuration files.  The MD and MF types are
+            obsolete and MUST NOT be implemented; in particular, name
+            servers MUST NOT load these types from configuration files.
+
+
+
+Internet Engineering Task Force                                [Page 79]
+
+
+
+
+RFC1123               SUPPORT SERVICES -- DOMAINS           October 1989
+
+
+            DISCUSSION:
+                 The RR types MB, MG, MR, NULL, MINFO and RP are
+                 considered experimental, and applications that use the
+                 DNS cannot expect these RR types to be supported by
+                 most domains.  Furthermore these types are subject to
+                 redefinition.
+
+                 The TXT and WKS RR types have not been widely used by
+                 Internet sites; as a result, an application cannot rely
+                 on the the existence of a TXT or WKS RR in most
+                 domains.
+
+         6.1.3.7  Robustness
+
+            DNS software may need to operate in environments where the
+            root servers or other servers are unavailable due to network
+            connectivity or other problems.  In this situation, DNS name
+            servers and resolvers MUST continue to provide service for
+            the reachable part of the name space, while giving temporary
+            failures for the rest.
+
+            DISCUSSION:
+                 Although the DNS is meant to be used primarily in the
+                 connected Internet, it should be possible to use the
+                 system in networks which are unconnected to the
+                 Internet.  Hence implementations must not depend on
+                 access to root servers before providing service for
+                 local names.
+
+         6.1.3.8  Local Host Table
+
+            DISCUSSION:
+                 A host may use a local host table as a backup or
+                 supplement to the DNS.  This raises the question of
+                 which takes precedence, the DNS or the host table; the
+                 most flexible approach would make this a configuration
+                 option.
+
+                 Typically, the contents of such a supplementary host
+                 table will be determined locally by the site.  However,
+                 a publically-available table of Internet hosts is
+                 maintained by the DDN Network Information Center (DDN
+                 NIC), with a format documented in [DNS:4].  This table
+                 can be retrieved from the DDN NIC using a protocol
+                 described in [DNS:5].  It must be noted that this table
+                 contains only a small fraction of all Internet hosts.
+                 Hosts using this protocol to retrieve the DDN NIC host
+                 table should use the VERSION command to check if the
+
+
+
+Internet Engineering Task Force                                [Page 80]
+
+
+
+
+RFC1123               SUPPORT SERVICES -- DOMAINS           October 1989
+
+
+                 table has changed before requesting the entire table
+                 with the ALL command.  The VERSION identifier should be
+                 treated as an arbitrary string and tested only for
+                 equality; no numerical sequence may be assumed.
+
+                 The DDN NIC host table includes administrative
+                 information that is not needed for host operation and
+                 is therefore not currently included in the DNS
+                 database; examples include network and gateway entries.
+                 However, much of this additional information will be
+                 added to the DNS in the future.  Conversely, the DNS
+                 provides essential services (in particular, MX records)
+                 that are not available from the DDN NIC host table.
+
+      6.1.4  DNS USER INTERFACE
+
+         6.1.4.1  DNS Administration
+
+            This document is concerned with design and implementation
+            issues in host software, not with administrative or
+            operational issues.  However, administrative issues are of
+            particular importance in the DNS, since errors in particular
+            segments of this large distributed database can cause poor
+            or erroneous performance for many sites.  These issues are
+            discussed in [DNS:6] and [DNS:7].
+
+         6.1.4.2  DNS User Interface
+
+            Hosts MUST provide an interface to the DNS for all
+            application programs running on the host.  This interface
+            will typically direct requests to a system process to
+            perform the resolver function [DNS:1, 6.1:2].
+
+            At a minimum, the basic interface MUST support a request for
+            all information of a specific type and class associated with
+            a specific name, and it MUST return either all of the
+            requested information, a hard error code, or a soft error
+            indication.  When there is no error, the basic interface
+            returns the complete response information without
+            modification, deletion, or ordering, so that the basic
+            interface will not need to be changed to accommodate new
+            data types.
+
+            DISCUSSION:
+                 The soft error indication is an essential part of the
+                 interface, since it may not always be possible to
+                 access particular information from the DNS; see Section
+                 6.1.3.3.
+
+
+
+Internet Engineering Task Force                                [Page 81]
+
+
+
+
+RFC1123               SUPPORT SERVICES -- DOMAINS           October 1989
+
+
+            A host MAY provide other DNS interfaces tailored to
+            particular functions, transforming the raw domain data into
+            formats more suited to these functions.  In particular, a
+            host MUST provide a DNS interface to facilitate translation
+            between host addresses and host names.
+
+         6.1.4.3 Interface Abbreviation Facilities
+
+            User interfaces MAY provide a method for users to enter
+            abbreviations for commonly-used names.  Although the
+            definition of such methods is outside of the scope of the
+            DNS specification, certain rules are necessary to insure
+            that these methods allow access to the entire DNS name space
+            and to prevent excessive use of Internet resources.
+
+            If an abbreviation method is provided, then:
+
+            (a)  There MUST be some convention for denoting that a name
+                 is already complete, so that the abbreviation method(s)
+                 are suppressed.  A trailing dot is the usual method.
+
+            (b)  Abbreviation expansion MUST be done exactly once, and
+                 MUST be done in the context in which the name was
+                 entered.
+
+
+            DISCUSSION:
+                 For example, if an abbreviation is used in a mail
+                 program for a destination, the abbreviation should be
+                 expanded into a full domain name and stored in the
+                 queued message with an indication that it is already
+                 complete.  Otherwise, the abbreviation might be
+                 expanded with a mail system search list, not the
+                 user's, or a name could grow due to repeated
+                 canonicalizations attempts interacting with wildcards.
+
+            The two most common abbreviation methods are:
+
+            (1)  Interface-level aliases
+
+                 Interface-level aliases are conceptually implemented as
+                 a list of alias/domain name pairs. The list can be
+                 per-user or per-host, and separate lists can be
+                 associated with different functions, e.g. one list for
+                 host name-to-address translation, and a different list
+                 for mail domains.  When the user enters a name, the
+                 interface attempts to match the name to the alias
+                 component of a list entry, and if a matching entry can
+
+
+
+Internet Engineering Task Force                                [Page 82]
+
+
+
+
+RFC1123               SUPPORT SERVICES -- DOMAINS           October 1989
+
+
+                 be found, the name is replaced by the domain name found
+                 in the pair.
+
+                 Note that interface-level aliases and CNAMEs are
+                 completely separate mechanisms; interface-level aliases
+                 are a local matter while CNAMEs are an Internet-wide
+                 aliasing mechanism which is a required part of any DNS
+                 implementation.
+
+            (2)  Search Lists
+
+                 A search list is conceptually implemented as an ordered
+                 list of domain names.  When the user enters a name, the
+                 domain names in the search list are used as suffixes to
+                 the user-supplied name, one by one, until a domain name
+                 with the desired associated data is found, or the
+                 search list is exhausted.  Search lists often contain
+                 the name of the local host's parent domain or other
+                 ancestor domains.  Search lists are often per-user or
+                 per-process.
+
+                 It SHOULD be possible for an administrator to disable a
+                 DNS search-list facility.  Administrative denial may be
+                 warranted in some cases, to prevent abuse of the DNS.
+
+                 There is danger that a search-list mechanism will
+                 generate excessive queries to the root servers while
+                 testing whether user input is a complete domain name,
+                 lacking a final period to mark it as complete.  A
+                 search-list mechanism MUST have one of, and SHOULD have
+                 both of, the following two provisions to prevent this:
+
+                 (a)  The local resolver/name server can implement
+                      caching  of negative responses (see Section
+                      6.1.3.3).
+
+                 (b)  The search list expander can require two or more
+                      interior dots in a generated domain name before it
+                      tries using the name in a query to non-local
+                      domain servers, such as the root.
+
+                 DISCUSSION:
+                      The intent of this requirement is to avoid
+                      excessive delay for the user as the search list is
+                      tested, and more importantly to prevent excessive
+                      traffic to the root and other high-level servers.
+                      For example, if the user supplied a name "X" and
+                      the search list contained the root as a component,
+
+
+
+Internet Engineering Task Force                                [Page 83]
+
+
+
+
+RFC1123               SUPPORT SERVICES -- DOMAINS           October 1989
+
+
+                      a query would have to consult a root server before
+                      the next search list alternative could be tried.
+                      The resulting load seen by the root servers and
+                      gateways near the root would be multiplied by the
+                      number of hosts in the Internet.
+
+                      The negative caching alternative limits the effect
+                      to the first time a name is used.  The interior
+                      dot rule is simpler to implement but can prevent
+                      easy use of some top-level names.
+
+
+      6.1.5  DOMAIN NAME SYSTEM REQUIREMENTS SUMMARY
+
+                                               |           | | | |S| |
+                                               |           | | | |H| |F
+                                               |           | | | |O|M|o
+                                               |           | |S| |U|U|o
+                                               |           | |H| |L|S|t
+                                               |           |M|O| |D|T|n
+                                               |           |U|U|M| | |o
+                                               |           |S|L|A|N|N|t
+                                               |           |T|D|Y|O|O|t
+FEATURE                                        |SECTION    | | | |T|T|e
+-----------------------------------------------|-----------|-|-|-|-|-|--
+GENERAL ISSUES                                 |           | | | | | |
+                                               |           | | | | | |
+Implement DNS name-to-address conversion       |6.1.1      |x| | | | |
+Implement DNS address-to-name conversion       |6.1.1      |x| | | | |
+Support conversions using host table           |6.1.1      | | |x| | |
+Properly handle RR with zero TTL               |6.1.2.1    |x| | | | |
+Use QCLASS=* unnecessarily                     |6.1.2.2    | |x| | | |
+  Use QCLASS=IN for Internet class             |6.1.2.2    |x| | | | |
+Unused fields zero                             |6.1.2.3    |x| | | | |
+Use compression in responses                   |6.1.2.4    |x| | | | |
+                                               |           | | | | | |
+Include config info in responses               |6.1.2.5    | | | | |x|
+Support all well-known, class-indep. types     |6.1.3.5    |x| | | | |
+Easily expand type list                        |6.1.3.5    | |x| | | |
+Load all RR types (except MD and MF)           |6.1.3.6    |x| | | | |
+Load MD or MF type                             |6.1.3.6    | | | | |x|
+Operate when root servers, etc. unavailable    |6.1.3.7    |x| | | | |
+-----------------------------------------------|-----------|-|-|-|-|-|--
+RESOLVER ISSUES:                               |           | | | | | |
+                                               |           | | | | | |
+Resolver support multiple concurrent requests  |6.1.3.1    | |x| | | |
+Full-service resolver:                         |6.1.3.1    | | |x| | |
+  Local caching                                |6.1.3.1    |x| | | | |
+
+
+
+Internet Engineering Task Force                                [Page 84]
+
+
+
+
+RFC1123               SUPPORT SERVICES -- DOMAINS           October 1989
+
+
+  Information in local cache times out         |6.1.3.1    |x| | | | |
+  Configurable with starting info              |6.1.3.1    | |x| | | |
+Stub resolver:                                 |6.1.3.1    | | |x| | |
+  Use redundant recursive name servers         |6.1.3.1    |x| | | | |
+  Local caching                                |6.1.3.1    | | |x| | |
+  Information in local cache times out         |6.1.3.1    |x| | | | |
+Support for remote multi-homed hosts:          |           | | | | | |
+  Sort multiple addresses by preference list   |6.1.3.4    | |x| | | |
+                                               |           | | | | | |
+-----------------------------------------------|-----------|-|-|-|-|-|--
+TRANSPORT PROTOCOLS:                           |           | | | | | |
+                                               |           | | | | | |
+Support UDP queries                            |6.1.3.2    |x| | | | |
+Support TCP queries                            |6.1.3.2    | |x| | | |
+  Send query using UDP first                   |6.1.3.2    |x| | | | |1
+  Try TCP if UDP answers are truncated         |6.1.3.2    | |x| | | |
+Name server limit TCP query resources          |6.1.3.2    | | |x| | |
+  Punish unnecessary TCP query                 |6.1.3.2    | | | |x| |
+Use truncated data as if it were not           |6.1.3.2    | | | | |x|
+Private agreement to use only TCP              |6.1.3.2    | | |x| | |
+Use TCP for zone transfers                     |6.1.3.2    |x| | | | |
+TCP usage not block UDP queries                |6.1.3.2    |x| | | | |
+Support broadcast or multicast queries         |6.1.3.2    | | |x| | |
+  RD bit set in query                          |6.1.3.2    | | | | |x|
+  RD bit ignored by server is b'cast/m'cast    |6.1.3.2    |x| | | | |
+  Send only as occasional probe for addr's     |6.1.3.2    | |x| | | |
+-----------------------------------------------|-----------|-|-|-|-|-|--
+RESOURCE USAGE:                                |           | | | | | |
+                                               |           | | | | | |
+Transmission controls, per [DNS:2]             |6.1.3.3    |x| | | | |
+  Finite bounds per request                    |6.1.3.3    |x| | | | |
+Failure after retries => soft error            |6.1.3.3    |x| | | | |
+Cache temporary failures                       |6.1.3.3    | |x| | | |
+Cache negative responses                       |6.1.3.3    | |x| | | |
+Retries use exponential backoff                |6.1.3.3    | |x| | | |
+  Upper, lower bounds                          |6.1.3.3    | |x| | | |
+Client handle Source Quench                    |6.1.3.3    | |x| | | |
+Server ignore Source Quench                    |6.1.3.3    | | |x| | |
+-----------------------------------------------|-----------|-|-|-|-|-|--
+USER INTERFACE:                                |           | | | | | |
+                                               |           | | | | | |
+All programs have access to DNS interface      |6.1.4.2    |x| | | | |
+Able to request all info for given name        |6.1.4.2    |x| | | | |
+Returns complete info or error                 |6.1.4.2    |x| | | | |
+Special interfaces                             |6.1.4.2    | | |x| | |
+  Name<->Address translation                   |6.1.4.2    |x| | | | |
+                                               |           | | | | | |
+Abbreviation Facilities:                       |6.1.4.3    | | |x| | |
+
+
+
+Internet Engineering Task Force                                [Page 85]
+
+
+
+
+RFC1123               SUPPORT SERVICES -- DOMAINS           October 1989
+
+
+  Convention for complete names                |6.1.4.3    |x| | | | |
+  Conversion exactly once                      |6.1.4.3    |x| | | | |
+  Conversion in proper context                 |6.1.4.3    |x| | | | |
+  Search list:                                 |6.1.4.3    | | |x| | |
+    Administrator can disable                  |6.1.4.3    | |x| | | |
+    Prevention of excessive root queries       |6.1.4.3    |x| | | | |
+      Both methods                             |6.1.4.3    | |x| | | |
+-----------------------------------------------|-----------|-|-|-|-|-|--
+-----------------------------------------------|-----------|-|-|-|-|-|--
+
+1.   Unless there is private agreement between particular resolver and
+     particular server.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Internet Engineering Task Force                                [Page 86]
+
+
+
+
+RFC1123            SUPPORT SERVICES -- INITIALIZATION       October 1989
+
+
+   6.2  HOST INITIALIZATION
+
+      6.2.1  INTRODUCTION
+
+         This section discusses the initialization of host software
+         across a connected network, or more generally across an
+         Internet path.  This is necessary for a diskless host, and may
+         optionally be used for a host with disk drives.  For a diskless
+         host, the initialization process is called "network booting"
+         and is controlled by a bootstrap program located in a boot ROM.
+
+         To initialize a diskless host across the network, there are two
+         distinct phases:
+
+         (1)  Configure the IP layer.
+
+              Diskless machines often have no permanent storage in which
+              to store network configuration information, so that
+              sufficient configuration information must be obtained
+              dynamically to support the loading phase that follows.
+              This information must include at least the IP addresses of
+              the host and of the boot server.  To support booting
+              across a gateway, the address mask and a list of default
+              gateways are also required.
+
+         (2)  Load the host system code.
+
+              During the loading phase, an appropriate file transfer
+              protocol is used to copy the system code across the
+              network from the boot server.
+
+         A host with a disk may perform the first step, dynamic
+         configuration.  This is important for microcomputers, whose
+         floppy disks allow network configuration information to be
+         mistakenly duplicated on more than one host.  Also,
+         installation of new hosts is much simpler if they automatically
+         obtain their configuration information from a central server,
+         saving administrator time and decreasing the probability of
+         mistakes.
+
+      6.2.2  REQUIREMENTS
+
+         6.2.2.1  Dynamic Configuration
+
+            A number of protocol provisions have been made for dynamic
+            configuration.
+
+            o    ICMP Information Request/Reply messages
+
+
+
+Internet Engineering Task Force                                [Page 87]
+
+
+
+
+RFC1123            SUPPORT SERVICES -- INITIALIZATION       October 1989
+
+
+                 This obsolete message pair was designed to allow a host
+                 to find the number of the network it is on.
+                 Unfortunately, it was useful only if the host already
+                 knew the host number part of its IP address,
+                 information that hosts requiring dynamic configuration
+                 seldom had.
+
+            o    Reverse Address Resolution Protocol (RARP) [BOOT:4]
+
+                 RARP is a link-layer protocol for a broadcast medium
+                 that allows a host to find its IP address given its
+                 link layer address.  Unfortunately, RARP does not work
+                 across IP gateways and therefore requires a RARP server
+                 on every network.  In addition, RARP does not provide
+                 any other configuration information.
+
+            o    ICMP Address Mask Request/Reply messages
+
+                 These ICMP messages allow a host to learn the address
+                 mask for a particular network interface.
+
+            o    BOOTP Protocol [BOOT:2]
+
+                 This protocol allows a host to determine the IP
+                 addresses of the local host and the boot server, the
+                 name of an appropriate boot file, and optionally the
+                 address mask and list of default gateways.  To locate a
+                 BOOTP server, the host broadcasts a BOOTP request using
+                 UDP.  Ad hoc gateway extensions have been used to
+                 transmit the BOOTP broadcast through gateways, and in
+                 the future the IP Multicasting facility will provide a
+                 standard mechanism for this purpose.
+
+
+            The suggested approach to dynamic configuration is to use
+            the BOOTP protocol with the extensions defined in "BOOTP
+            Vendor Information Extensions" RFC-1084 [BOOT:3].  RFC-1084
+            defines some important general (not vendor-specific)
+            extensions.  In particular, these extensions allow the
+            address mask to be supplied in BOOTP; we RECOMMEND that the
+            address mask be supplied in this manner.
+
+            DISCUSSION:
+                 Historically, subnetting was defined long after IP, and
+                 so a separate mechanism (ICMP Address Mask messages)
+                 was designed to supply the address mask to a host.
+                 However, the IP address mask and the corresponding IP
+                 address conceptually form a pair, and for operational
+
+
+
+Internet Engineering Task Force                                [Page 88]
+
+
+
+
+RFC1123            SUPPORT SERVICES -- INITIALIZATION       October 1989
+
+
+                 simplicity they ought to be defined at the same time
+                 and by the same mechanism, whether a configuration file
+                 or a dynamic mechanism like BOOTP.
+
+                 Note that BOOTP is not sufficiently general to specify
+                 the configurations of all interfaces of a multihomed
+                 host.  A multihomed host must either use BOOTP
+                 separately for each interface, or configure one
+                 interface using BOOTP to perform the loading, and
+                 perform the complete initialization from a file later.
+
+                 Application layer configuration information is expected
+                 to be obtained from files after loading of the system
+                 code.
+
+         6.2.2.2  Loading Phase
+
+            A suggested approach for the loading phase is to use TFTP
+            [BOOT:1] between the IP addresses established by BOOTP.
+
+            TFTP to a broadcast address SHOULD NOT be used, for reasons
+            explained in Section 4.2.3.4.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Internet Engineering Task Force                                [Page 89]
+
+
+
+
+RFC1123              SUPPORT SERVICES -- MANAGEMENT         October 1989
+
+
+   6.3  REMOTE MANAGEMENT
+
+      6.3.1  INTRODUCTION
+
+         The Internet community has recently put considerable effort
+         into the development of network management protocols.  The
+         result has been a two-pronged approach [MGT:1, MGT:6]:  the
+         Simple Network Management Protocol (SNMP) [MGT:4] and the
+         Common Management Information Protocol over TCP (CMOT) [MGT:5].
+
+         In order to be managed using SNMP or CMOT, a host will need to
+         implement an appropriate management agent.  An Internet host
+         SHOULD include an agent for either SNMP or CMOT.
+
+         Both SNMP and CMOT operate on a Management Information Base
+         (MIB) that defines a collection of management values.  By
+         reading and setting these values, a remote application may
+         query and change the state of the managed system.
+
+         A standard MIB [MGT:3] has been defined for use by both
+         management protocols, using data types defined by the Structure
+         of Management Information (SMI) defined in [MGT:2].  Additional
+         MIB variables can be introduced under the "enterprises" and
+         "experimental" subtrees of the MIB naming space [MGT:2].
+
+         Every protocol module in the host SHOULD implement the relevant
+         MIB variables.  A host SHOULD implement the MIB variables as
+         defined in the most recent standard MIB, and MAY implement
+         other MIB variables when appropriate and useful.
+
+      6.3.2  PROTOCOL WALK-THROUGH
+
+         The MIB is intended to cover both hosts and gateways, although
+         there may be detailed differences in MIB application to the two
+         cases.  This section contains the appropriate interpretation of
+         the MIB for hosts.  It is likely that later versions of the MIB
+         will include more entries for host management.
+
+         A managed host must implement the following groups of MIB
+         object definitions: System, Interfaces, Address Translation,
+         IP, ICMP, TCP, and UDP.
+
+         The following specific interpretations apply to hosts:
+
+         o    ipInHdrErrors
+
+              Note that the error "time-to-live exceeded" can occur in a
+              host only when it is forwarding a source-routed datagram.
+
+
+
+Internet Engineering Task Force                                [Page 90]
+
+
+
+
+RFC1123              SUPPORT SERVICES -- MANAGEMENT         October 1989
+
+
+         o    ipOutNoRoutes
+
+              This object counts datagrams discarded because no route
+              can be found.  This may happen in a host if all the
+              default gateways in the host's configuration are down.
+
+         o    ipFragOKs, ipFragFails, ipFragCreates
+
+              A host that does not implement intentional fragmentation
+              (see "Fragmentation" section of [INTRO:1]) MUST return the
+              value zero for these three objects.
+
+         o    icmpOutRedirects
+
+              For a host, this object MUST always be zero, since hosts
+              do not send Redirects.
+
+         o    icmpOutAddrMaskReps
+
+              For a host, this object MUST always be zero, unless the
+              host is an authoritative source of address mask
+              information.
+
+         o    ipAddrTable
+
+              For a host, the "IP Address Table" object is effectively a
+              table of logical interfaces.
+
+         o    ipRoutingTable
+
+              For a host, the "IP Routing Table" object is effectively a
+              combination of the host's Routing Cache and the static
+              route table described in "Routing Outbound Datagrams"
+              section of [INTRO:1].
+
+              Within each ipRouteEntry, ipRouteMetric1...4 normally will
+              have no meaning for a host and SHOULD always be -1, while
+              ipRouteType will normally have the value "remote".
+
+              If destinations on the connected network do not appear in
+              the Route Cache (see "Routing Outbound Datagrams section
+              of [INTRO:1]), there will be no entries with ipRouteType
+              of "direct".
+
+
+         DISCUSSION:
+              The current MIB does not include Type-of-Service in an
+              ipRouteEntry, but a future revision is expected to make
+
+
+
+Internet Engineering Task Force                                [Page 91]
+
+
+
+
+RFC1123              SUPPORT SERVICES -- MANAGEMENT         October 1989
+
+
+              this addition.
+
+              We also expect the MIB to be expanded to allow the remote
+              management of applications (e.g., the ability to partially
+              reconfigure mail systems).  Network service applications
+              such as mail systems should therefore be written with the
+              "hooks" for remote management.
+
+      6.3.3  MANAGEMENT REQUIREMENTS SUMMARY
+
+                                               |           | | | |S| |
+                                               |           | | | |H| |F
+                                               |           | | | |O|M|o
+                                               |           | |S| |U|U|o
+                                               |           | |H| |L|S|t
+                                               |           |M|O| |D|T|n
+                                               |           |U|U|M| | |o
+                                               |           |S|L|A|N|N|t
+                                               |           |T|D|Y|O|O|t
+FEATURE                                        |SECTION    | | | |T|T|e
+-----------------------------------------------|-----------|-|-|-|-|-|--
+Support SNMP or CMOT agent                     |6.3.1      | |x| | | |
+Implement specified objects in standard MIB    |6.3.1      | |x| | | |
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Internet Engineering Task Force                                [Page 92]
+
+
+
+
+RFC1123              SUPPORT SERVICES -- MANAGEMENT         October 1989
+
+
+7.  REFERENCES
+
+   This section lists the primary references with which every
+   implementer must be thoroughly familiar.  It also lists some
+   secondary references that are suggested additional reading.
+
+   INTRODUCTORY REFERENCES:
+
+
+   [INTRO:1] "Requirements for Internet Hosts -- Communication Layers,"
+        IETF Host Requirements Working Group, R. Braden, Ed., RFC-1122,
+        October 1989.
+
+   [INTRO:2]  "DDN Protocol Handbook," NIC-50004, NIC-50005, NIC-50006,
+        (three volumes), SRI International, December 1985.
+
+   [INTRO:3]  "Official Internet Protocols," J. Reynolds and J. Postel,
+        RFC-1011, May 1987.
+
+        This document is republished periodically with new RFC numbers;
+        the latest version must be used.
+
+   [INTRO:4]  "Protocol Document Order Information," O. Jacobsen and J.
+        Postel, RFC-980, March 1986.
+
+   [INTRO:5]  "Assigned Numbers," J. Reynolds and J. Postel, RFC-1010,
+        May 1987.
+
+        This document is republished periodically with new RFC numbers;
+        the latest version must be used.
+
+
+   TELNET REFERENCES:
+
+
+   [TELNET:1]  "Telnet Protocol Specification," J. Postel and J.
+        Reynolds, RFC-854, May 1983.
+
+   [TELNET:2]  "Telnet Option Specification," J. Postel and J. Reynolds,
+        RFC-855, May 1983.
+
+   [TELNET:3]  "Telnet Binary Transmission," J. Postel and J. Reynolds,
+        RFC-856, May 1983.
+
+   [TELNET:4]  "Telnet Echo Option," J. Postel and J. Reynolds, RFC-857,
+        May 1983.
+
+   [TELNET:5]  "Telnet Suppress Go Ahead Option," J. Postel and J.
+
+
+
+Internet Engineering Task Force                                [Page 93]
+
+
+
+
+RFC1123              SUPPORT SERVICES -- MANAGEMENT         October 1989
+
+
+        Reynolds, RFC-858, May 1983.
+
+   [TELNET:6]  "Telnet Status Option," J. Postel and J. Reynolds, RFC-
+        859, May 1983.
+
+   [TELNET:7]  "Telnet Timing Mark Option," J. Postel and J. Reynolds,
+        RFC-860, May 1983.
+
+   [TELNET:8]  "Telnet Extended Options List," J. Postel and J.
+        Reynolds, RFC-861, May 1983.
+
+   [TELNET:9]  "Telnet End-Of-Record Option," J. Postel, RFC-855,
+        December 1983.
+
+   [TELNET:10] "Telnet Terminal-Type Option," J. VanBokkelen, RFC-1091,
+        February 1989.
+
+        This document supercedes RFC-930.
+
+   [TELNET:11] "Telnet Window Size Option," D. Waitzman, RFC-1073,
+        October 1988.
+
+   [TELNET:12] "Telnet Linemode Option," D. Borman, RFC-1116, August
+        1989.
+
+   [TELNET:13] "Telnet Terminal Speed Option," C. Hedrick, RFC-1079,
+        December 1988.
+
+   [TELNET:14] "Telnet Remote Flow Control Option," C. Hedrick, RFC-
+        1080, November 1988.
+
+
+   SECONDARY TELNET REFERENCES:
+
+
+   [TELNET:15] "Telnet Protocol," MIL-STD-1782, U.S. Department of
+        Defense, May 1984.
+
+        This document is intended to describe the same protocol as RFC-
+        854.  In case of conflict, RFC-854 takes precedence, and the
+        present document takes precedence over both.
+
+   [TELNET:16] "SUPDUP Protocol," M. Crispin, RFC-734, October 1977.
+
+   [TELNET:17] "Telnet SUPDUP Option," M. Crispin, RFC-736, October
+        1977.
+
+   [TELNET:18] "Data Entry Terminal Option," J. Day, RFC-732, June 1977.
+
+
+
+Internet Engineering Task Force                                [Page 94]
+
+
+
+
+RFC1123              SUPPORT SERVICES -- MANAGEMENT         October 1989
+
+
+   [TELNET:19] "TELNET Data Entry Terminal option -- DODIIS
+        Implementation," A. Yasuda and T. Thompson, RFC-1043, February
+        1988.
+
+
+   FTP REFERENCES:
+
+
+   [FTP:1]  "File Transfer Protocol," J. Postel and J. Reynolds, RFC-
+        959, October 1985.
+
+   [FTP:2]  "Document File Format Standards," J. Postel, RFC-678,
+        December 1974.
+
+   [FTP:3]  "File Transfer Protocol," MIL-STD-1780, U.S. Department of
+        Defense, May 1984.
+
+        This document is based on an earlier version of the FTP
+        specification (RFC-765) and is obsolete.
+
+
+   TFTP REFERENCES:
+
+
+   [TFTP:1]  "The TFTP Protocol Revision 2," K. Sollins, RFC-783, June
+        1981.
+
+
+   MAIL REFERENCES:
+
+
+   [SMTP:1]  "Simple Mail Transfer Protocol," J. Postel, RFC-821, August
+        1982.
+
+   [SMTP:2]  "Standard For The Format of ARPA Internet Text Messages,"
+        D. Crocker, RFC-822, August 1982.
+
+        This document obsoleted an earlier specification, RFC-733.
+
+   [SMTP:3]  "Mail Routing and the Domain System," C. Partridge, RFC-
+        974, January 1986.
+
+        This RFC describes the use of MX records, a mandatory extension
+        to the mail delivery process.
+
+   [SMTP:4]  "Duplicate Messages and SMTP," C. Partridge, RFC-1047,
+        February 1988.
+
+
+
+
+Internet Engineering Task Force                                [Page 95]
+
+
+
+
+RFC1123              SUPPORT SERVICES -- MANAGEMENT         October 1989
+
+
+   [SMTP:5a]  "Mapping between X.400 and RFC 822," S. Kille, RFC-987,
+        June 1986.
+
+   [SMTP:5b]  "Addendum to RFC-987," S. Kille, RFC-???, September 1987.
+
+        The two preceding RFC's define a proposed standard for
+        gatewaying mail between the Internet and the X.400 environments.
+
+   [SMTP:6]  "Simple Mail Transfer Protocol,"  MIL-STD-1781, U.S.
+        Department of Defense, May 1984.
+
+        This specification is intended to describe the same protocol as
+        does RFC-821.  However, MIL-STD-1781 is incomplete; in
+        particular, it does not include MX records [SMTP:3].
+
+   [SMTP:7]  "A Content-Type Field for Internet Messages," M. Sirbu,
+        RFC-1049, March 1988.
+
+
+   DOMAIN NAME SYSTEM REFERENCES:
+
+
+   [DNS:1]  "Domain Names - Concepts and Facilities," P. Mockapetris,
+        RFC-1034, November 1987.
+
+        This document and the following one obsolete RFC-882, RFC-883,
+        and RFC-973.
+
+   [DNS:2]  "Domain Names - Implementation and Specification," RFC-1035,
+        P. Mockapetris, November 1987.
+
+
+   [DNS:3]  "Mail Routing and the Domain System," C. Partridge, RFC-974,
+        January 1986.
+
+
+   [DNS:4]  "DoD Internet Host Table Specification," K. Harrenstein,
+        RFC-952, M. Stahl, E. Feinler, October 1985.
+
+        SECONDARY DNS REFERENCES:
+
+
+   [DNS:5]  "Hostname Server," K. Harrenstein, M. Stahl, E. Feinler,
+        RFC-953, October 1985.
+
+   [DNS:6]  "Domain Administrators Guide," M. Stahl, RFC-1032, November
+        1987.
+
+
+
+
+Internet Engineering Task Force                                [Page 96]
+
+
+
+
+RFC1123              SUPPORT SERVICES -- MANAGEMENT         October 1989
+
+
+   [DNS:7]  "Domain Administrators Operations Guide," M. Lottor, RFC-
+        1033, November 1987.
+
+   [DNS:8]  "The Domain Name System Handbook," Vol. 4 of Internet
+        Protocol Handbook, NIC 50007, SRI Network Information Center,
+        August 1989.
+
+
+   SYSTEM INITIALIZATION REFERENCES:
+
+
+   [BOOT:1] "Bootstrap Loading Using TFTP," R. Finlayson, RFC-906, June
+        1984.
+
+   [BOOT:2] "Bootstrap Protocol (BOOTP)," W. Croft and J. Gilmore, RFC-
+        951, September 1985.
+
+   [BOOT:3] "BOOTP Vendor Information Extensions," J. Reynolds, RFC-
+        1084, December 1988.
+
+        Note: this RFC revised and obsoleted RFC-1048.
+
+   [BOOT:4] "A Reverse Address Resolution Protocol," R. Finlayson, T.
+        Mann, J. Mogul, and M. Theimer, RFC-903, June 1984.
+
+
+   MANAGEMENT REFERENCES:
+
+
+   [MGT:1]  "IAB Recommendations for the Development of Internet Network
+        Management Standards," V. Cerf, RFC-1052, April 1988.
+
+   [MGT:2]  "Structure and Identification of Management Information for
+        TCP/IP-based internets," M. Rose and K. McCloghrie, RFC-1065,
+        August 1988.
+
+   [MGT:3]  "Management Information Base for Network Management of
+        TCP/IP-based internets," M. Rose and K. McCloghrie, RFC-1066,
+        August 1988.
+
+   [MGT:4]  "A Simple Network Management Protocol," J. Case, M. Fedor,
+        M. Schoffstall, and C. Davin, RFC-1098, April 1989.
+
+   [MGT:5]  "The Common Management Information Services and Protocol
+        over TCP/IP," U. Warrier and L. Besaw, RFC-1095, April 1989.
+
+   [MGT:6]  "Report of the Second Ad Hoc Network Management Review
+        Group," V. Cerf, RFC-1109, August 1989.
+
+
+
+Internet Engineering Task Force                                [Page 97]
+
+
+
+
+RFC1123              SUPPORT SERVICES -- MANAGEMENT         October 1989
+
+
+Security Considerations
+
+   There are many security issues in the application and support
+   programs of host software, but a full discussion is beyond the scope
+   of this RFC.  Security-related issues are mentioned in sections
+   concerning TFTP (Sections 4.2.1, 4.2.3.4, 4.2.3.5), the SMTP VRFY and
+   EXPN commands (Section 5.2.3), the SMTP HELO command (5.2.5), and the
+   SMTP DATA command (Section 5.2.8).
+
+Author's Address
+
+   Robert Braden
+   USC/Information Sciences Institute
+   4676 Admiralty Way
+   Marina del Rey, CA 90292-6695
+
+   Phone: (213) 822 1511
+
+   EMail: Braden@ISI.EDU
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Internet Engineering Task Force                                [Page 98]
+
diff --git a/doc/rfc/rfc1183.txt b/doc/rfc/rfc1183.txt
new file mode 100644
index 0000000..6f08044
--- /dev/null
+++ b/doc/rfc/rfc1183.txt
@@ -0,0 +1,619 @@
+
+
+
+
+
+
+Network Working Group                                        C. Everhart
+Request for Comments: 1183                                      Transarc
+Updates: RFCs 1034, 1035                                      L. Mamakos
+                                                  University of Maryland
+                                                              R. Ullmann
+                                                          Prime Computer
+                                                  P. Mockapetris, Editor
+                                                                     ISI
+                                                            October 1990
+
+
+                         New DNS RR Definitions
+
+Status of this Memo
+
+   This memo defines five new DNS types for experimental purposes.  This
+   RFC describes an Experimental Protocol for the Internet community,
+   and requests discussion and suggestions for improvements.
+   Distribution of this memo is unlimited.
+
+Table of Contents
+
+   Introduction....................................................    1
+   1. AFS Data Base location.......................................    2
+   2. Responsible Person...........................................    3
+   2.1. Identification of the guilty party.........................    3
+   2.2. The Responsible Person RR..................................    4
+   3. X.25 and ISDN addresses, Route Binding.......................    6
+   3.1. The X25 RR.................................................    6
+   3.2. The ISDN RR................................................    7
+   3.3. The Route Through RR.......................................    8
+   REFERENCES and BIBLIOGRAPHY.....................................    9
+   Security Considerations.........................................   10
+   Authors' Addresses..............................................   11
+
+Introduction
+
+   This RFC defines the format of new Resource Records (RRs) for the
+   Domain Name System (DNS), and reserves corresponding DNS type
+   mnemonics and numerical codes.  The definitions are in three
+   independent sections: (1) location of AFS database servers, (2)
+   location of responsible persons, and (3) representation of X.25 and
+   ISDN addresses and route binding.  All are experimental.
+
+   This RFC assumes that the reader is familiar with the DNS [3,4].  The
+   data shown is for pedagogical use and does not necessarily reflect
+   the real Internet.
+
+
+
+
+Everhart, Mamakos, Ullmann & Mockapetris                        [Page 1]
+
+RFC 1183                 New DNS RR Definitions             October 1990
+
+
+1. AFS Data Base location
+
+   This section defines an extension of the DNS to locate servers both
+   for AFS (AFS is a registered trademark of Transarc Corporation) and
+   for the Open Software Foundation's (OSF) Distributed Computing
+   Environment (DCE) authenticated naming system using HP/Apollo's NCA,
+   both to be components of the OSF DCE.  The discussion assumes that
+   the reader is familiar with AFS [5] and NCA [6].
+
+   The AFS (originally the Andrew File System) system uses the DNS to
+   map from a domain name to the name of an AFS cell database server.
+   The DCE Naming service uses the DNS for a similar function: mapping
+   from the domain name of a cell to authenticated name servers for that
+   cell.  The method uses a new RR type with mnemonic AFSDB and type
+   code of 18 (decimal).
+
+   AFSDB has the following format:
+
+   <owner> <ttl> <class> AFSDB <subtype> <hostname>
+
+   Both RDATA fields are required in all AFSDB RRs.  The <subtype> field
+   is a 16 bit integer.  The <hostname> field is a domain name of a host
+   that has a server for the cell named by the owner name of the RR.
+
+   The format of the AFSDB RR is class insensitive.  AFSDB records cause
+   type A additional section processing for <hostname>.  This, in fact,
+   is the rationale for using a new type code, rather than trying to
+   build the same functionality with TXT RRs.
+
+   Note that the format of AFSDB in a master file is identical to MX.
+   For purposes of the DNS itself, the subtype is merely an integer.
+   The present subtype semantics are discussed below, but changes are
+   possible and will be announced in subsequent RFCs.
+
+   In the case of subtype 1, the host has an AFS version 3.0 Volume
+   Location Server for the named AFS cell.  In the case of subtype 2,
+   the host has an authenticated name server holding the cell-root
+   directory node for the named DCE/NCA cell.
+
+   The use of subtypes is motivated by two considerations.  First, the
+   space of DNS RR types is limited.  Second, the services provided are
+   sufficiently distinct that it would continue to be confusing for a
+   client to attempt to connect to a cell's servers using the protocol
+   for one service, if the cell offered only the other service.
+
+   As an example of the use of this RR, suppose that the Toaster
+   Corporation has deployed AFS 3.0 but not (yet) the OSF's DCE.  Their
+   cell, named toaster.com, has three "AFS 3.0 cell database server"
+
+
+
+Everhart, Mamakos, Ullmann & Mockapetris                        [Page 2]
+
+RFC 1183                 New DNS RR Definitions             October 1990
+
+
+   machines: bigbird.toaster.com, ernie.toaster.com, and
+   henson.toaster.com.  These three machines would be listed in three
+   AFSDB RRs.  These might appear in a master file as:
+
+   toaster.com.   AFSDB   1 bigbird.toaster.com.
+   toaster.com.   AFSDB   1 ernie.toaster.com.
+   toaster.com.   AFSDB   1 henson.toaster.com.
+
+   As another example use of this RR, suppose that Femto College (domain
+   name femto.edu) has deployed DCE, and that their DCE cell root
+   directory is served by processes running on green.femto.edu and
+   turquoise.femto.edu.  Furthermore, their DCE file servers also run
+   AFS 3.0-compatible volume location servers, on the hosts
+   turquoise.femto.edu and orange.femto.edu.  These machines would be
+   listed in four AFSDB RRs, which might appear in a master file as:
+
+   femto.edu.   AFSDB   2 green.femto.edu.
+   femto.edu.   AFSDB   2 turquoise.femto.edu.
+   femto.edu.   AFSDB   1 turquoise.femto.edu.
+   femto.edu.   AFSDB   1 orange.femto.edu.
+
+2. Responsible Person
+
+   The purpose of this section is to provide a standard method for
+   associating responsible person identification to any name in the DNS.
+
+   The domain name system functions as a distributed database which
+   contains many different form of information.  For a particular name
+   or host, you can discover it's Internet address, mail forwarding
+   information, hardware type and operating system among others.
+
+   A key aspect of the DNS is that the tree-structured namespace can be
+   divided into pieces, called zones, for purposes of distributing
+   control and responsibility.  The responsible person for zone database
+   purposes is named in the SOA RR for that zone.  This section
+   describes an extension which allows different responsible persons to
+   be specified for different names in a zone.
+
+2.1. Identification of the guilty party
+
+   Often it is desirable to be able to identify the responsible entity
+   for a particular host.  When that host is down or malfunctioning, it
+   is difficult to contact those parties which might resolve or repair
+   the host.  Mail sent to POSTMASTER may not reach the person in a
+   timely fashion.  If the host is one of a multitude of workstations,
+   there may be no responsible person which can be contacted on that
+   host.
+
+
+
+
+Everhart, Mamakos, Ullmann & Mockapetris                        [Page 3]
+
+RFC 1183                 New DNS RR Definitions             October 1990
+
+
+   The POSTMASTER mailbox on that host continues to be a good contact
+   point for mail problems, and the zone contact in the SOA record for
+   database problem, but the RP record allows us to associate a mailbox
+   to entities that don't receive mail or are not directly connected
+   (namespace-wise) to the problem (e.g., GATEWAY.ISI.EDU might want to
+   point at HOTLINE@BBN.COM, and GATEWAY doesn't get mail, nor does the
+   ISI zone administrator have a clue about fixing gateways).
+
+2.2. The Responsible Person RR
+
+   The method uses a new RR type with mnemonic RP and type code of 17
+   (decimal).
+
+   RP has the following format:
+
+   <owner> <ttl> <class> RP <mbox-dname> <txt-dname>
+
+   Both RDATA fields are required in all RP RRs.
+
+   The first field, <mbox-dname>, is a domain name that specifies the
+   mailbox for the responsible person.  Its format in master files uses
+   the DNS convention for mailbox encoding, identical to that used for
+   the RNAME mailbox field in the SOA RR.  The root domain name (just
+   ".") may be specified for <mbox-dname> to indicate that no mailbox is
+   available.
+
+   The second field, <txt-dname>, is a domain name for which TXT RR's
+   exist.  A subsequent query can be performed to retrieve the
+   associated TXT resource records at <txt-dname>.  This provides a
+   level of indirection so that the entity can be referred to from
+   multiple places in the DNS.  The root domain name (just ".") may be
+   specified for <txt-dname> to indicate that the TXT_DNAME is absent,
+   and no associated TXT RR exists.
+
+   The format of the RP RR is class insensitive.  RP records cause no
+   additional section processing.  (TXT additional section processing
+   for <txt-dname> is allowed as an option, but only if it is disabled
+   for the root, i.e., ".").
+
+   The Responsible Person RR can be associated with any node in the
+   Domain Name System hierarchy, not just at the leaves of the tree.
+
+   The TXT RR associated with the TXT_DNAME contain free format text
+   suitable for humans.  Refer to [4] for more details on the TXT RR.
+
+   Multiple RP records at a single name may be present in the database.
+   They should have identical TTLs.
+
+
+
+
+Everhart, Mamakos, Ullmann & Mockapetris                        [Page 4]
+
+RFC 1183                 New DNS RR Definitions             October 1990
+
+
+   EXAMPLES
+
+   Some examples of how the RP record might be used.
+
+   sayshell.umd.edu. A     128.8.1.14
+                     MX    10 sayshell.umd.edu.
+                     HINFO NeXT UNIX
+                     WKS   128.8.1.14 tcp ftp telnet smtp
+                     RP    louie.trantor.umd.edu.  LAM1.people.umd.edu.
+
+   LAM1.people.umd.edu. TXT (
+         "Louis A. Mamakos, (301) 454-2946, don't call me at home!" )
+
+   In this example, the responsible person's mailbox for the host
+   SAYSHELL.UMD.EDU is louie@trantor.umd.edu.  The TXT RR at
+   LAM1.people.umd.edu provides additional information and advice.
+
+   TERP.UMD.EDU.    A     128.8.10.90
+                    MX    10 128.8.10.90
+                    HINFO MICROVAX-II UNIX
+                    WKS   128.8.10.90 udp domain
+                    WKS   128.8.10.90 tcp ftp telnet smtp domain
+                    RP    louie.trantor.umd.edu. LAM1.people.umd.edu.
+                    RP    root.terp.umd.edu. ops.CS.UMD.EDU.
+
+   TRANTOR.UMD.EDU. A     128.8.10.14
+                    MX    10 trantor.umd.edu.
+                    HINFO MICROVAX-II UNIX
+                    WKS   128.8.10.14 udp domain
+                    WKS   128.8.10.14 tcp ftp telnet smtp domain
+                    RP    louie.trantor.umd.edu. LAM1.people.umd.edu.
+                    RP    petry.netwolf.umd.edu. petry.people.UMD.EDU.
+                    RP    root.trantor.umd.edu. ops.CS.UMD.EDU.
+                    RP    gregh.sunset.umd.edu.  .
+
+   LAM1.people.umd.edu.  TXT   "Louis A. Mamakos (301) 454-2946"
+   petry.people.umd.edu. TXT   "Michael G. Petry (301) 454-2946"
+   ops.CS.UMD.EDU.       TXT   "CS Operations Staff (301) 454-2943"
+
+   This set of resource records has two hosts, TRANTOR.UMD.EDU and
+   TERP.UMD.EDU, as well as a number of TXT RRs.  Note that TERP.UMD.EDU
+   and TRANTOR.UMD.EDU both reference the same pair of TXT resource
+   records, although the mail box names (root.terp.umd.edu and
+   root.trantor.umd.edu) differ.
+
+   Here, we obviously care much more if the machine flakes out, as we've
+   specified four persons which might want to be notified of problems or
+   other events involving TRANTOR.UMD.EDU.  In this example, the last RP
+
+
+
+Everhart, Mamakos, Ullmann & Mockapetris                        [Page 5]
+
+RFC 1183                 New DNS RR Definitions             October 1990
+
+
+   RR for TRANTOR.UMD.EDU specifies a mailbox (gregh.sunset.umd.edu),
+   but no associated TXT RR.
+
+3. X.25 and ISDN addresses, Route Binding
+
+   This section describes an experimental representation of X.25 and
+   ISDN addresses in the DNS, as well as a route binding method,
+   analogous to the MX for mail routing, for very large scale networks.
+
+   There are several possible uses, all experimental at this time.
+   First, the RRs provide simple documentation of the correct addresses
+   to use in static configurations of IP/X.25 [11] and SMTP/X.25 [12].
+
+   The RRs could also be used automatically by an internet network-layer
+   router, typically IP.  The procedure would be to map IP address to
+   domain name, then name to canonical name if needed, then following RT
+   records, and finally attempting an IP/X.25 call to the address found.
+   Alternately, configured domain names could be resolved to identify IP
+   to X.25/ISDN bindings for a static but periodically refreshed routing
+   table.
+
+   This provides a function similar to ARP for wide area non-broadcast
+   networks that will scale well to a network with hundreds of millions
+   of hosts.
+
+   Also, a standard address binding reference will facilitate other
+   experiments in the use of X.25 and ISDN, especially in serious
+   inter-operability testing.  The majority of work in such a test is
+   establishing the n-squared entries in static tables.
+
+   Finally, the RRs are intended for use in a proposal [13] by one of
+   the authors for a possible next-generation internet.
+
+3.1. The X25 RR
+
+   The X25 RR is defined with mnemonic X25 and type code 19 (decimal).
+
+   X25 has the following format:
+
+   <owner> <ttl> <class> X25 <PSDN-address>
+
+   <PSDN-address> is required in all X25 RRs.
+
+   <PSDN-address> identifies the PSDN (Public Switched Data Network)
+   address in the X.121 [10] numbering plan associated with <owner>.
+   Its format in master files is a <character-string> syntactically
+   identical to that used in TXT and HINFO.
+
+
+
+
+Everhart, Mamakos, Ullmann & Mockapetris                        [Page 6]
+
+RFC 1183                 New DNS RR Definitions             October 1990
+
+
+   The format of X25 is class insensitive.  X25 RRs cause no additional
+   section processing.
+
+   The <PSDN-address> is a string of decimal digits, beginning with the
+   4 digit DNIC (Data Network Identification Code), as specified in
+   X.121. National prefixes (such as a 0) MUST NOT be used.
+
+   For example:
+
+   Relay.Prime.COM.  X25       311061700956
+
+3.2. The ISDN RR
+
+   The ISDN RR is defined with mnemonic ISDN and type code 20 (decimal).
+
+   An ISDN (Integrated Service Digital Network) number is simply a
+   telephone number.  The intent of the members of the CCITT is to
+   upgrade all telephone and data network service to a common service.
+
+   The numbering plan (E.163/E.164) is the same as the familiar
+   international plan for POTS (an un-official acronym, meaning Plain
+   Old Telephone Service).  In E.166, CCITT says "An E.163/E.164
+   telephony subscriber may become an ISDN subscriber without a number
+   change."
+
+   ISDN has the following format:
+
+   <owner> <ttl> <class> ISDN <ISDN-address> <sa>
+
+   The <ISDN-address> field is required; <sa> is optional.
+
+   <ISDN-address> identifies the ISDN number of <owner> and DDI (Direct
+   Dial In) if any, as defined by E.164 [8] and E.163 [7], the ISDN and
+   PSTN (Public Switched Telephone Network) numbering plan.  E.163
+   defines the country codes, and E.164 the form of the addresses.  Its
+   format in master files is a <character-string> syntactically
+   identical to that used in TXT and HINFO.
+
+   <sa> specifies the subaddress (SA).  The format of <sa> in master
+   files is a <character-string> syntactically identical to that used in
+   TXT and HINFO.
+
+   The format of ISDN is class insensitive.  ISDN RRs cause no
+   additional section processing.
+
+   The <ISDN-address> is a string of characters, normally decimal
+   digits, beginning with the E.163 country code and ending with the DDI
+   if any.  Note that ISDN, in Q.931, permits any IA5 character in the
+
+
+
+Everhart, Mamakos, Ullmann & Mockapetris                        [Page 7]
+
+RFC 1183                 New DNS RR Definitions             October 1990
+
+
+   general case.
+
+   The <sa> is a string of hexadecimal digits.  For digits 0-9, the
+   concrete encoding in the Q.931 call setup information element is
+   identical to BCD.
+
+   For example:
+
+   Relay.Prime.COM.   IN   ISDN      150862028003217
+   sh.Prime.COM.      IN   ISDN      150862028003217 004
+
+   (Note: "1" is the country code for the North American Integrated
+   Numbering Area, i.e., the system of "area codes" familiar to people
+   in those countries.)
+
+   The RR data is the ASCII representation of the digits.  It is encoded
+   as one or two <character-string>s, i.e., count followed by
+   characters.
+
+   CCITT recommendation E.166 [9] defines prefix escape codes for the
+   representation of ISDN (E.163/E.164) addresses in X.121, and PSDN
+   (X.121) addresses in E.164.  It specifies that the exact codes are a
+   "national matter", i.e., different on different networks.  A host
+   connected to the ISDN may be able to use both the X25 and ISDN
+   addresses, with the local prefix added.
+
+3.3. The Route Through RR
+
+   The Route Through RR is defined with mnemonic RT and type code 21
+   (decimal).
+
+   The RT resource record provides a route-through binding for hosts
+   that do not have their own direct wide area network addresses.  It is
+   used in much the same way as the MX RR.
+
+   RT has the following format:
+
+   <owner> <ttl> <class> RT <preference> <intermediate-host>
+
+   Both RDATA fields are required in all RT RRs.
+
+   The first field, <preference>, is a 16 bit integer, representing the
+   preference of the route.  Smaller numbers indicate more preferred
+   routes.
+
+   <intermediate-host> is the domain name of a host which will serve as
+   an intermediate in reaching the host specified by <owner>.  The DNS
+   RRs associated with <intermediate-host> are expected to include at
+
+
+
+Everhart, Mamakos, Ullmann & Mockapetris                        [Page 8]
+
+RFC 1183                 New DNS RR Definitions             October 1990
+
+
+   least one A, X25, or ISDN record.
+
+   The format of the RT RR is class insensitive.  RT records cause type
+   X25, ISDN, and A additional section processing for <intermediate-
+   host>.
+
+   For example,
+
+   sh.prime.com.      IN   RT   2    Relay.Prime.COM.
+                      IN   RT   10   NET.Prime.COM.
+   *.prime.com.       IN   RT   90   Relay.Prime.COM.
+
+   When a host is looking up DNS records to attempt to route a datagram,
+   it first looks for RT records for the destination host, which point
+   to hosts with address records (A, X25, ISDN) compatible with the wide
+   area networks available to the host.  If it is itself in the set of
+   RT records, it discards any RTs with preferences higher or equal to
+   its own.  If there are no (remaining) RTs, it can then use address
+   records of the destination itself.
+
+   Wild-card RTs are used exactly as are wild-card MXs.  RT's do not
+   "chain"; that is, it is not valid to use the RT RRs found for a host
+   referred to by an RT.
+
+   The concrete encoding is identical to the MX RR.
+
+REFERENCES and BIBLIOGRAPHY
+
+   [1] Stahl, M., "Domain Administrators Guide", RFC 1032, Network
+       Information Center, SRI International, November 1987.
+
+   [2] Lottor, M., "Domain Administrators Operations Guide", RFC 1033,
+       Network Information Center, SRI International, November, 1987.
+
+   [3] Mockapetris, P., "Domain Names - Concepts and Facilities", RFC
+       1034, USC/Information Sciences Institute, November 1987.
+
+   [4] Mockapetris, P., "Domain Names - Implementation and
+       Specification", RFC 1035, USC/Information Sciences Institute,
+       November 1987.
+
+   [5] Spector A., and M. Kazar, "Uniting File Systems", UNIX Review,
+       7(3), pp. 61-69, March 1989.
+
+   [6] Zahn, et al., "Network Computing Architecture", Prentice-Hall,
+       1989.
+
+   [7] International Telegraph and Telephone Consultative Committee,
+
+
+
+Everhart, Mamakos, Ullmann & Mockapetris                        [Page 9]
+
+RFC 1183                 New DNS RR Definitions             October 1990
+
+
+       "Numbering Plan for the International Telephone Service", CCITT
+       Recommendations E.163., IXth Plenary Assembly, Melbourne, 1988,
+       Fascicle II.2 ("Blue Book").
+
+   [8] International Telegraph and Telephone Consultative Committee,
+       "Numbering Plan for the ISDN Era", CCITT Recommendations E.164.,
+       IXth Plenary Assembly, Melbourne, 1988, Fascicle II.2 ("Blue
+       Book").
+
+   [9] International Telegraph and Telephone Consultative Committee.
+       "Numbering Plan Interworking in the ISDN Era", CCITT
+       Recommendations E.166., IXth Plenary Assembly, Melbourne, 1988,
+       Fascicle II.2 ("Blue Book").
+
+  [10] International Telegraph and Telephone Consultative Committee,
+       "International Numbering Plan for the Public Data Networks",
+       CCITT Recommendations X.121., IXth Plenary Assembly, Melbourne,
+       1988, Fascicle VIII.3 ("Blue Book"); provisional, Geneva, 1978;
+       amended, Geneva, 1980, Malaga-Torremolinos, 1984 and Melborne,
+       1988.
+
+  [11] Korb, J., "Standard for the Transmission of IP datagrams Over
+       Public Data Networks", RFC 877, Purdue University, September
+       1983.
+
+  [12] Ullmann, R., "SMTP on X.25", RFC 1090, Prime Computer, February
+       1989.
+
+  [13] Ullmann, R., "TP/IX: The Next Internet", Prime Computer
+       (unpublished), July 1990.
+
+  [14] Mockapetris, P., "DNS Encoding of Network Names and Other Types",
+       RFC 1101, USC/Information Sciences Institute, April 1989.
+
+Security Considerations
+
+   Security issues are not addressed in this memo.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Everhart, Mamakos, Ullmann & Mockapetris                       [Page 10]
+
+RFC 1183                 New DNS RR Definitions             October 1990
+
+
+Authors' Addresses
+
+   Craig F. Everhart
+   Transarc Corporation
+   The Gulf Tower
+   707 Grant Street
+   Pittsburgh, PA  15219
+
+   Phone: +1 412 338 4467
+
+   EMail: Craig_Everhart@transarc.com
+
+
+   Louis A. Mamakos
+   Network Infrastructure Group
+   Computer Science Center
+   University of Maryland
+   College Park, MD 20742-2411
+
+   Phone: +1-301-405-7836
+
+   Email: louie@Sayshell.UMD.EDU
+
+
+   Robert Ullmann 10-30
+   Prime Computer, Inc.
+   500 Old Connecticut Path
+   Framingham, MA 01701
+
+   Phone: +1 508 620 2800 ext 1736
+
+   Email: Ariel@Relay.Prime.COM
+
+
+   Paul Mockapetris
+   USC Information Sciences Institute
+   4676 Admiralty Way
+   Marina del Rey, CA 90292
+
+   Phone: 213-822-1511
+
+   EMail: pvm@isi.edu
+
+
+
+
+
+
+
+
+
+Everhart, Mamakos, Ullmann & Mockapetris                       [Page 11]
+
\ No newline at end of file
diff --git a/doc/rfc/rfc1348.txt b/doc/rfc/rfc1348.txt
new file mode 100644
index 0000000..d9e5dea
--- /dev/null
+++ b/doc/rfc/rfc1348.txt
@@ -0,0 +1,227 @@
+
+
+
+
+
+
+Network Working Group                                         B. Manning
+Request for Comments: 1348                               Rice University
+Updates: RFCs 1034, 1035                                       July 1992
+
+
+                              DNS NSAP RRs
+
+Status of this Memo
+
+   This memo defines an Experimental Protocol for the Internet
+   community.  Discussion and suggestions for improvement are requested.
+   Please refer to the current edition of the "IAB Official Protocol
+   Standards" for the standardization state and status of this protocol.
+   Distribution of this memo is unlimited.
+
+Table of Contents
+
+   Introduction .....................................................  1
+   Background .......................................................  1
+   NSAP RR ..........................................................  2
+   NSAP-PTR RR ......................................................  2
+   REFERENCES and BIBLIOGRAPHY ......................................  3
+   Security Considerations ..........................................  4
+   Author's Address .................................................  4
+
+Introduction
+
+   This RFC defines the format of two new Resource Records (RRs) for the
+   Domain Name System (DNS), and reserves corresponding DNS type
+   mnemonic and numerical codes.  This format may be used with the any
+   proposal that has variable length addresses, but is targeted for CLNP
+   use.
+
+   This memo assumes that the reader is familiar with the DNS [3,4].
+
+Background
+
+   This section describes an experimental representation of NSAP
+   addresses in the DNS. There are several reasons to take this approch.
+   First, it provides simple documentation of the correct addresses to
+   use in static configurations of CLNP compliant hosts and routers.
+
+   NSAP support requires that a new DNS resource record entry type
+   ("NSAP") be defined, to store longer Internet (i.e., NSAP) addresses.
+   This resource record allows mapping from DNS names to NSAP addresses,
+   and will contain entries for systems which are able to run Internet
+   applications, over TCP or UDP, over CLNP.
+
+
+
+
+Manning                                                         [Page 1]
+
+RFC 1348                      DNS NSAP RRs                     July 1992
+
+
+   The backward translation (from NSAP address to DNS name) is
+   facilitated by definition of an associated resource record. This
+   resource record is known as "NSAP-PTR", and is used in a manner
+   analogous to the existing "in-addr.arpa".
+
+   These RRs are intended for use in a proposal [6] by one of the
+   members of the NOOP WG to address the next-generation internet.
+
+The NSAP RR
+
+   The NSAP RR is defined with mnemonic NSAP and type code 22 (decimal).
+
+   An NSAP (Network Service Access Protocol) number is a unique string
+   to OSI transport service.
+
+   The numbering plan follows RFC 1237 and associated OSI definitions
+   for NSAP format.
+
+   NSAP has the following format:
+
+   <owner> <ttl> <class> NSAP <length> <NSAP-address>
+
+   All fields are required.
+
+   <length> identifies the number of octets in the <NSAP-address> as
+   defined by the various national and international authorities.
+
+   <NSAP-address> enumerates the actual octet values assigned by the
+   assigning authority.  Its format in master files is a <character-
+   string> syntactically identical to that used in TXT and HINFO.
+
+   The format of NSAP is class insensitive.  NSAP RR causes no
+   additional section processing.
+
+   For example:
+
+foo.bar.com.    IN  NSAP   21 47000580ffff000000321099991111222233334444
+host.school.de  IN  NSAP   17 39276f3100111100002222333344449876
+
+   The RR data is the ASCII representation of the digits.  It is encoded
+   as two <character-strings>, i.e., count followed by characters.
+
+The NSAP-PTR RR
+
+   The NSAP-PTR RR is defined with mnemonic NSAP-PTR and a type code 23
+   (decimal).
+
+   Its function is analogous to the PTR record used for IP addresses
+
+
+
+Manning                                                         [Page 2]
+
+RFC 1348                      DNS NSAP RRs                     July 1992
+
+
+   [4,7].
+
+   NSAP-PTR has the following format:
+
+   <NSAP-suffix> <ttl> <class> NSAP-PTR <owner>
+
+   All fields are required.
+
+   <NSAP-suffix> enumerates the actual octet values assigned by the
+   assigning authority for the LOCAL network.  Its format in master
+   files is a <character-string> syntactically identical to that used in
+   TXT and HINFO.
+
+   The format of NSAP-PTR is class insensitive.  NSAP-PTR RR causes no
+   additional section processing.
+
+   For example:
+
+   In net ff08000574.nsap-in-addr.arpa:
+
+   444433332222111199990123000000ff    NSAP-PTR   foo.bar.com.
+
+   Or in net 11110031f67293.nsap-in-addr.arpa:
+
+   67894444333322220000  NSAP-PTR        host.school.de.
+
+   The RR data is the ASCII representation of the digits.  It is encoded
+   as a <character-string>.
+
+REFERENCES and BIBLIOGRAPHY
+
+   [1] Stahl, M., "Domain Administrators Guide", RFC 1032, Network
+       Information Center, SRI International, November 1987.
+
+   [2] Lottor, M., "Domain Administrators Operations Guide", RFC 1033,
+       Network Information Center, SRI International, November, 1987.
+
+   [3] Mockapetris, P., "Domain Names - Concepts and Facilities", RFC
+       1034, USC/Information Sciences Institute, November 1987.
+
+   [4] Mockapetris, P., "Domain Names - Implementation and
+       Specification", RFC 1035, USC/Information Sciences Institute,
+       November 1987.
+
+   [5] Colella, R., Gardner, E., and R. Callon, "Guidelines for OSI
+       NSAP Allocation in the Internet", RFC 1237, NIST, Mitre, DEC,
+       July 1991.
+
+
+
+
+Manning                                                         [Page 3]
+
+RFC 1348                      DNS NSAP RRs                     July 1992
+
+
+   [6] Callon, R., "TCP and UDP with Bigger Addresses (TUBA),
+       A Simple Proposal for Internet Addressing and Routing",
+       Digital Equipment Corporation, RFC 1347, June 1992.
+
+   [7] Mockapetris, P., "DNS Encoding of Network Names and Other Types",
+       RFC 1101, USC/Information Sciences Institute, April 1989.
+
+   [8] ISO/IEC.  Information Processing Systems -- Data Communications
+       -- Network Service Definition Addendum 2: Network Layer Address-
+       ing. International Standard 8348/Addendum 2, ISO/IEC JTC 1,
+       Switzerland, 1988.
+
+   [9] Bryant, P., "NSAPs", PB660, IPTAG/92/23, SCIENCE AND ENGINEERING
+       RESEARCH COUNCIL, RUTHERFORD APPLETON LABORATORY May 1992.
+
+Security Considerations
+
+   Security issues are not addressed in this memo.
+
+Author's Address
+
+   Bill Manning
+   Rice University - ONCS
+   PO Box 1892
+   6100 South Main
+   Houston, Texas  77251-1892
+
+   Phone: +1.713.285.5415
+   EMail: bmanning@rice.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Manning                                                         [Page 4]
+
\ No newline at end of file
diff --git a/doc/rfc/rfc1535.txt b/doc/rfc/rfc1535.txt
new file mode 100644
index 0000000..03bddee
--- /dev/null
+++ b/doc/rfc/rfc1535.txt
@@ -0,0 +1,283 @@
+
+
+
+
+
+
+Network Working Group                                          E. Gavron
+Request for Comments: 1535                            ACES Research Inc.
+Category: Informational                                     October 1993
+
+
+              A Security Problem and Proposed Correction
+                   With Widely Deployed DNS Software
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard.  Distribution of this memo is
+   unlimited.
+
+Abstract
+
+   This document discusses a flaw in some of the currently distributed
+   name resolver clients.  The flaw exposes a security weakness related
+   to the search heuristic invoked by these same resolvers when users
+   provide a partial domain name, and which is easy to exploit (although
+   not by the masses).  This document points out the flaw, a case in
+   point, and a solution.
+
+Background
+
+   Current Domain Name Server clients are designed to ease the burden of
+   remembering IP dotted quad addresses.  As such they translate human-
+   readable names into addresses and other resource records.  Part of
+   the translation process includes understanding and dealing with
+   hostnames that are not fully qualified domain names (FQDNs).
+
+   An absolute "rooted" FQDN is of the format {name}{.} A non "rooted"
+   domain name is of the format {name}
+
+   A domain name may have many parts and typically these include the
+   host, domain, and type.  Example:  foobar.company.com or
+   fooschool.university.edu.
+
+Flaw
+
+   The problem with most widely distributed resolvers based on the BSD
+   BIND resolver is that they attempt to resolve a partial name by
+   processing a search list of partial domains to be added to portions
+   of the specified host name until a DNS record is found.  This
+   "feature" is disabled by default in the official BIND 4.9.2 release.
+
+   Example: A TELNET attempt by    User@Machine.Tech.ACES.COM
+                             to    UnivHost.University.EDU
+
+
+
+Gavron                                                          [Page 1]
+
+RFC 1535               DNS Software Enhancements            October 1993
+
+
+   The resolver client will realize that since "UnivHost.University.EDU"
+   does not end with a ".", it is not an absolute "rooted" FQDN.  It
+   will then try the following combinations until a resource record is
+   found:
+
+                UnivHost.University.EDU.Tech.ACES.COM.
+                UnivHost.University.EDU.ACES.COM.
+                UnivHost.University.EDU.COM.
+                UnivHost.University.EDU.
+
+Security Issue
+
+   After registering the EDU.COM domain, it was discovered that an
+   unliberal application of one wildcard CNAME record would cause *all*
+   connects from any .COM site to any .EDU site to terminate at one
+   target machine in the private edu.com sub-domain.
+
+   Further, discussion reveals that specific hostnames registered in
+   this private subdomain, or any similarly named subdomain may be used
+   to spoof a host.
+
+        Example:        harvard.edu.com.        CNAME   targethost
+
+   Thus all connects to Harvard.edu from all .com sites would end up at
+   targthost, a machine which could provide a Harvard.edu login banner.
+
+   This is clearly unacceptable.  Further, it could only be made worse
+   with domains like COM.EDU, MIL.GOV, GOV.COM, etc.
+
+Public vs. Local Name Space Administration
+
+   The specification of the Domain Name System and the software that
+   implements it provides an undifferentiated hierarchy which permits
+   delegation of administration for subordinate portions of the name
+   space.  Actual administration of the name space is divided between
+   "public" and "local" portions.  Public administration pertains to all
+   top-level domains, such as .COM and .EDU.  For some domains, it also
+   pertains to some number of sub-domain levels.  The multi-level nature
+   of the public administration is most evident for top-level domains
+   for countries.  For example in the Fully Qualified Domain Name,
+   dbc.mtview.ca.us., the portion "mtview.ca.us" represents three levels
+   of public administration.  Only the left-most portion is subject to
+   local administration.
+
+
+
+
+
+
+
+
+Gavron                                                          [Page 2]
+
+RFC 1535               DNS Software Enhancements            October 1993
+
+
+   The danger of the heuristic search common in current practise is that
+   it it is possible to "intercept" the search by matching against an
+   unintended value while walking up the search list.  While this is
+   potentially dangerous at any level, it is entirely unacceptable when
+   the error impacts users outside of a local administration.
+
+   When attempting to resolve a partial domain name, DNS resolvers use
+   the Domain Name of the searching host for deriving the search list.
+   Existing DNS resolvers do not distinguish the portion of that name
+   which is in the locally administered scope from the part that is
+   publically administered.
+
+Solution(s)
+
+   At a minimum, DNS resolvers must honor the BOUNDARY between local and
+   public administration, by limiting any search lists to locally-
+   administered portions of the Domain Name space.  This requires a
+   parameter which shows the scope of the name space controlled by the
+   local administrator.
+
+   This would permit progressive searches from the most qualified to
+   less qualified up through the locally controlled domain, but not
+   beyond.
+
+   For example, if the local user were trying to reach:
+
+        User@chief.admin.DESERTU.EDU from
+        starburst,astro.DESERTU.EDU,
+
+   it is reasonable to permit the user to enter just chief.admin, and
+   for the search to cover:
+
+        chief.admin.astro.DESERTU.EDU
+        chief.admin.DESERTU.EDU
+
+   but not
+
+        chief.admin.EDU
+
+   In this case, the value of "search" should be set to "DESERTU.EDU"
+   because that's the scope of the name space controlled by the local
+   DNS administrator.
+
+   This is more than a mere optimization hack.  The local administrator
+   has control over the assignment of names within the locally
+   administered domain, so the administrator can make sure that
+   abbreviations result in the right thing.  Outside of the local
+   control, users are necessarily at risk.
+
+
+
+Gavron                                                          [Page 3]
+
+RFC 1535               DNS Software Enhancements            October 1993
+
+
+   A more stringent mechanism is implemented in BIND 4.9.2, to respond
+   to this problem:
+
+   The DNS Name resolver clients narrows its IMPLICIT search list IF ANY
+   to only try the first and the last of the examples shown.
+
+   Any additional search alternatives must be configured into the
+   resolver EXPLICITLY.
+
+   DNS Name resolver software SHOULD NOT use implicit search lists in
+   attempts to resolve partial names into absolute FQDNs other than the
+   hosts's immediate parent domain.
+
+   Resolvers which continue to use implicit search lists MUST limit
+   their scope to locally administered sub-domains.
+
+   DNS Name resolver software SHOULD NOT come pre-configured with
+   explicit search lists that perpetuate this problem.
+
+   Further, in any event where a "." exists in a specified name it
+   should be assumed to be a fully qualified domain name (FQDN) and
+   SHOULD be tried as a rooted name first.
+
+   Example:  Given  user@a.b.c.d connecting to e.f.g.h  only two tries
+             should be attempted as a result of using an implicit
+             search list:
+
+                e.f.g.h.  and e.f.g.h.b.c.d.
+
+             Given user@a.b.c.d. connecting to host those same two
+             tries would appear as:
+
+                x.b.c.d.  and x.
+
+   Some organizations make regular use of multi-part, partially
+   qualified Domain Names.  For example, host foo.loc1.org.city.state.us
+   might be used to making references to bar.loc2, or mumble.loc3, all
+   of which refer to whatever.locN.org.city.state.us
+
+   The stringent implicit search rules for BIND 4.9.2 will now cause
+   these searches to fail.  To return the ability for them to succeed,
+   configuration of the client resolvers must be changed to include an
+   explicit search rule for org.city.state.us.  That is, it must contain
+   an explicit rule for any -- and each -- portion of the locally-
+   administered sub-domain that it wishes to have as part of the search
+   list.
+
+
+
+
+
+Gavron                                                          [Page 4]
+
+RFC 1535               DNS Software Enhancements            October 1993
+
+
+References
+
+   [1] Mockapetris, P., "Domain Names Concepts and Facilities", STD 13,
+       RFC 1034, USC/Information Sciences Institute, November 1987.
+
+   [2] Mockapetris, P., "Domain Names Implementation and Specification",
+       STD 13, RFC 1035, USC/Information Sciences Institute, November
+       1987.
+
+   [3] Partridge, C., "Mail Routing and the Domain System", STD 14, RFC
+       974, CSNET CIC BBN, January 1986.
+
+   [4] Kumar, A., Postel, J., Neuman, C., Danzig, P., and S. Miller,
+       "Common DNS Implementation Errors and Suggested Fixes", RFC 1536,
+       USC/Information Sciences Institute, USC, October 1993.
+
+   [5] Beertema, P., "Common DNS Data File Configuration Errors", RFC
+       1537, CWI, October 1993.
+
+Security Considerations
+
+   This memo indicates vulnerabilities with all too-forgiving DNS
+   clients.  It points out a correction that would eliminate the future
+   potential of the problem.
+
+Author's Address
+
+   Ehud Gavron
+   ACES Research Inc.
+   PO Box 14546
+   Tucson, AZ 85711
+
+   Phone: (602) 743-9841
+   EMail: gavron@aces.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gavron                                                          [Page 5]
+
diff --git a/doc/rfc/rfc1536.txt b/doc/rfc/rfc1536.txt
new file mode 100644
index 0000000..5ff2b25
--- /dev/null
+++ b/doc/rfc/rfc1536.txt
@@ -0,0 +1,675 @@
+
+
+
+
+
+
+Network Working Group                                           A. Kumar
+Request for Comments: 1536                                     J. Postel
+Category: Informational                                        C. Neuman
+                                                                     ISI
+                                                               P. Danzig
+                                                               S. Miller
+                                                                     USC
+                                                            October 1993
+
+
+          Common DNS Implementation Errors and Suggested Fixes
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard.  Distribution of this memo is
+   unlimited.
+
+Abstract
+
+   This memo describes common errors seen in DNS implementations and
+   suggests some fixes. Where applicable, violations of recommendations
+   from STD 13, RFC 1034 and STD 13, RFC 1035 are mentioned. The memo
+   also describes, where relevant, the algorithms followed in BIND
+   (versions 4.8.3 and 4.9 which the authors referred to) to serve as an
+   example.
+
+Introduction
+
+   The last few years have seen, virtually, an explosion of DNS traffic
+   on the NSFnet backbone. Various DNS implementations and various
+   versions of these implementations interact with each other, producing
+   huge amounts of unnecessary traffic. Attempts are being made by
+   researchers all over the internet, to document the nature of these
+   interactions, the symptomatic traffic patterns and to devise remedies
+   for the sick pieces of software.
+
+   This draft is an attempt to document fixes for known DNS problems so
+   people know what problems to watch out for and how to repair broken
+   software.
+
+1. Fast Retransmissions
+
+   DNS implements the classic request-response scheme of client-server
+   interaction. UDP is, therefore, the chosen protocol for communication
+   though TCP is used for zone transfers. The onus of requerying in case
+   no response is seen in a "reasonable" period of time, lies with the
+   client. Although RFC 1034 and 1035 do not recommend any
+
+
+
+Kumar, Postel, Neuman, Danzig & Miller                          [Page 1]
+
+RFC 1536            Common DNS Implementation Errors        October 1993
+
+
+   retransmission policy, RFC 1035 does recommend that the resolvers
+   should cycle through a list of servers. Both name servers and stub
+   resolvers should, therefore, implement some kind of a retransmission
+   policy based on round trip time estimates of the name servers. The
+   client should back-off exponentially, probably to a maximum timeout
+   value.
+
+   However, clients might not implement either of the two. They might
+   not wait a sufficient amount of time before retransmitting or they
+   might not back-off their inter-query times sufficiently.
+
+   Thus, what the server would see will be a series of queries from the
+   same querying entity, spaced very close together. Of course, a
+   correctly implemented server discards all duplicate queries but the
+   queries contribute to wide-area traffic, nevertheless.
+
+   We classify a retransmission of a query as a pure Fast retry timeout
+   problem when a series of query packets meet the following conditions.
+
+      a. Query packets are seen within a time less than a "reasonable
+         waiting period" of each other.
+
+      b. No response to the original query was seen i.e., we see two or
+         more queries, back to back.
+
+      c. The query packets share the same query identifier.
+
+      d. The server eventually responds to the query.
+
+A GOOD IMPLEMENTATION:
+
+   BIND (we looked at versions 4.8.3 and 4.9) implements a good
+   retransmission algorithm which solves or limits all of these
+   problems.  The Berkeley stub-resolver queries servers at an interval
+   that starts at the greater of 4 seconds and 5 seconds divided by the
+   number of servers the resolver queries. The resolver cycles through
+   servers and at the end of a cycle, backs off the time out
+   exponentially.
+
+   The Berkeley full-service resolver (built in with the program
+   "named") starts with a time-out equal to the greater of 4 seconds and
+   two times the round-trip time estimate of the server.  The time-out
+   is backed off with each cycle, exponentially, to a ceiling value of
+   45 seconds.
+
+
+
+
+
+
+
+Kumar, Postel, Neuman, Danzig & Miller                          [Page 2]
+
+RFC 1536            Common DNS Implementation Errors        October 1993
+
+
+FIXES:
+
+      a. Estimate round-trip times or set a reasonably high initial
+         time-out.
+
+      b. Back-off timeout periods exponentially.
+
+      c. Yet another fundamental though difficult fix is to send the
+         client an acknowledgement of a query, with a round-trip time
+         estimate.
+
+   Since UDP is used, no response is expected by the client until the
+   query is complete.  Thus, it is less likely to have information about
+   previous packets on which to estimate its back-off time.  Unless, you
+   maintain state across queries, so subsequent queries to the same
+   server use information from previous queries.  Unfortunately, such
+   estimates are likely to be inaccurate for chained requests since the
+   variance is likely to be high.
+
+   The fix chosen in the ARDP library used by Prospero is that the
+   server will send an initial acknowledgement to the client in those
+   cases where the server expects the query to take a long time (as
+   might be the case for chained queries).  This initial acknowledgement
+   can include an expected time to wait before retrying.
+
+   This fix is more difficult since it requires that the client software
+   also be trained to expect the acknowledgement packet. This, in an
+   internet of millions of hosts is at best a hard problem.
+
+2. Recursion Bugs
+
+   When a server receives a client request, it first looks up its zone
+   data and the cache to check if the query can be answered. If the
+   answer is unavailable in either place, the server seeks names of
+   servers that are more likely to have the information, in its cache or
+   zone data. It then does one of two things. If the client desires the
+   server to recurse and the server architecture allows recursion, the
+   server chains this request to these known servers closest to the
+   queried name. If the client doesn't seek recursion or if the server
+   cannot handle recursion, it returns the list of name servers to the
+   client assuming the client knows what to do with these records.
+
+   The client queries this new list of name servers to get either the
+   answer, or names of another set of name servers to query. This
+   process repeats until the client is satisfied. Servers might also go
+   through this chaining process if the server returns a CNAME record
+   for the queried name. Some servers reprocess this name to try and get
+   the desired record type.
+
+
+
+Kumar, Postel, Neuman, Danzig & Miller                          [Page 3]
+
+RFC 1536            Common DNS Implementation Errors        October 1993
+
+
+   However, in certain cases, this chain of events may not be good. For
+   example, a broken or malicious name server might list itself as one
+   of the name servers to query again. The unsuspecting client resends
+   the same query to the same server.
+
+   In another situation, more difficult to detect, a set of servers
+   might form a loop wherein A refers to B and B refers to A. This loop
+   might involve more than two servers.
+
+   Yet another error is where the client does not know how to process
+   the list of name servers returned, and requeries the same server
+   since that is one (of the few) servers it knows.
+
+   We, therefore, classify recursion bugs into three distinct
+   categories:
+
+      a. Ignored referral: Client did not know how to handle NS records
+         in the AUTHORITY section.
+
+      b. Too many referrals: Client called on a server too many times,
+         beyond a "reasonable" number, with same query. This is
+         different from a Fast retransmission problem and a Server
+         Failure detection problem in that a response is seen for every
+         query.  Also, the identifiers are always different. It implies
+         client is in a loop and should have detected that and broken
+         it.  (RFC 1035 mentions that client should not recurse beyond
+         a certain depth.)
+
+      c. Malicious Server: a server refers to itself in the authority
+         section. If a server does not have an answer now, it is very
+         unlikely it will be any better the next time you query it,
+         specially when it claims to be authoritative over a domain.
+
+      RFC 1034 warns against such situations, on page 35.
+
+      "Bound the amount of work (packets sent, parallel processes
+       started) so that a request can't get into an infinite loop or
+       start off a chain reaction of requests or queries with other
+       implementations EVEN IF SOMEONE HAS INCORRECTLY CONFIGURED
+       SOME DATA."
+
+A GOOD IMPLEMENTATION:
+
+   BIND fixes at least one of these problems. It places an upper limit
+   on the number of recursive queries it will make, to answer a
+   question.  It chases a maximum of 20 referral links and 8 canonical
+   name translations.
+
+
+
+
+Kumar, Postel, Neuman, Danzig & Miller                          [Page 4]
+
+RFC 1536            Common DNS Implementation Errors        October 1993
+
+
+FIXES:
+
+      a. Set an upper limit on the number of referral links and CNAME
+         links you are willing to chase.
+
+         Note that this is not guaranteed to break only recursion loops.
+         It could, in a rare case, prune off a very long search path,
+         prematurely.  We know, however, with high probability, that if
+         the number of links cross a certain metric (two times the depth
+         of the DNS tree), it is a recursion problem.
+
+      b. Watch out for self-referring servers. Avoid them whenever
+         possible.
+
+      c. Make sure you never pass off an authority NS record with your
+         own name on it!
+
+      d. Fix clients to accept iterative answers from servers not built
+         to provide recursion. Such clients should either be happy with
+         the non-authoritative answer or be willing to chase the
+         referral links themselves.
+
+3. Zero Answer Bugs:
+
+   Name servers sometimes return an authoritative NOERROR with no
+   ANSWER, AUTHORITY or ADDITIONAL records. This happens when the
+   queried name is valid but it does not have a record of the desired
+   type. Of course, the server has authority over the domain.
+
+   However, once again, some implementations of resolvers do not
+   interpret this kind of a response reasonably. They always expect an
+   answer record when they see an authoritative NOERROR. These entities
+   continue to resend their queries, possibly endlessly.
+
+A GOOD IMPLEMENTATION
+
+   BIND resolver code does not query a server more than 3 times. If it
+   is unable to get an answer from 4 servers, querying them three times
+   each, it returns error.
+
+   Of course, it treats a zero-answer response the way it should be
+   treated; with respect!
+
+FIXES:
+
+      a. Set an upper limit on the number of retransmissions for a given
+         query, at the very least.
+
+
+
+
+Kumar, Postel, Neuman, Danzig & Miller                          [Page 5]
+
+RFC 1536            Common DNS Implementation Errors        October 1993
+
+
+      b. Fix resolvers to interpret such a response as an authoritative
+         statement of non-existence of the record type for the given
+         name.
+
+4. Inability to detect server failure:
+
+   Servers in the internet are not very reliable (they go down every
+   once in a while) and resolvers are expected to adapt to the changed
+   scenario by not querying the server for a while. Thus, when a server
+   does not respond to a query, resolvers should try another server.
+   Also, non-stub resolvers should update their round trip time estimate
+   for the server to a large value so that server is not tried again
+   before other, faster servers.
+
+   Stub resolvers, however, cycle through a fixed set of servers and if,
+   unfortunately, a server is down while others do not respond for other
+   reasons (high load, recursive resolution of query is taking more time
+   than the resolver's time-out, ....), the resolver queries the dead
+   server again! In fact, some resolvers might not set an upper limit on
+   the number of query retransmissions they will send and continue to
+   query dead servers indefinitely.
+
+   Name servers running system or chained queries might also suffer from
+   the same problem. They store names of servers they should query for a
+   given domain. They cycle through these names and in case none of them
+   answers, hit each one more than one. It is, once again, important
+   that there be an upper limit on the number of retransmissions, to
+   prevent network overload.
+
+   This behavior is clearly in violation of the dictum in RFC 1035 (page
+   46)
+
+      "If a resolver gets a server error or other bizarre response
+       from a name server, it should remove it from SLIST, and may
+       wish to schedule an immediate transmission to the next
+       candidate server address."
+
+   Removal from SLIST implies that the server is not queried again for
+   some time.
+
+   Correctly implemented full-service resolvers should, as pointed out
+   before, update round trip time values for servers that do not respond
+   and query them only after other, good servers. Full-service resolvers
+   might, however, not follow any of these common sense directives. They
+   query dead servers, and they query them endlessly.
+
+
+
+
+
+
+Kumar, Postel, Neuman, Danzig & Miller                          [Page 6]
+
+RFC 1536            Common DNS Implementation Errors        October 1993
+
+
+A GOOD IMPLEMENTATION:
+
+   BIND places an upper limit on the number of times it queries a
+   server.  Both the stub-resolver and the full-service resolver code do
+   this.  Also, since the full-service resolver estimates round-trip
+   times and sorts name server addresses by these estimates, it does not
+   query a dead server again, until and unless all the other servers in
+   the list are dead too!  Further, BIND implements exponential back-off
+   too.
+
+FIXES:
+
+      a. Set an upper limit on number of retransmissions.
+
+      b. Measure round-trip time from servers (some estimate is better
+         than none). Treat no response as a "very large" round-trip
+         time.
+
+      c. Maintain a weighted rtt estimate and decay the "large" value
+         slowly, with time, so that the server is eventually tested
+         again, but not after an indefinitely long period.
+
+      d. Follow an exponential back-off scheme so that even if you do
+         not restrict the number of queries, you do not overload the
+         net excessively.
+
+5. Cache Leaks:
+
+   Every resource record returned by a server is cached for TTL seconds,
+   where the TTL value is returned with the RR. Full-service (or stub)
+   resolvers cache the RR and answer any queries based on this cached
+   information, in the future, until the TTL expires. After that, one
+   more query to the wide-area network gets the RR in cache again.
+
+   Full-service resolvers might not implement this caching mechanism
+   well. They might impose a limit on the cache size or might not
+   interpret the TTL value correctly. In either case, queries repeated
+   within a TTL period of a RR constitute a cache leak.
+
+A GOOD/BAD IMPLEMENTATION:
+
+   BIND has no restriction on the cache size and the size is governed by
+   the limits on the virtual address space of the machine it is running
+   on. BIND caches RRs for the duration of the TTL returned with each
+   record.
+
+   It does, however, not follow the RFCs with respect to interpretation
+   of a 0 TTL value. If a record has a TTL value of 0 seconds, BIND uses
+
+
+
+Kumar, Postel, Neuman, Danzig & Miller                          [Page 7]
+
+RFC 1536            Common DNS Implementation Errors        October 1993
+
+
+   the minimum TTL value, for that zone, from the SOA record and caches
+   it for that duration. This, though it saves some traffic on the
+   wide-area network, is not correct behavior.
+
+FIXES:
+
+      a. Look over your caching mechanism to ensure TTLs are interpreted
+         correctly.
+
+      b. Do not restrict cache sizes (come on, memory is cheap!).
+         Expired entries are reclaimed periodically, anyway. Of course,
+         the cache size is bound to have some physical limit. But, when
+         possible, this limit should be large (run your name server on
+         a machine with a large amount of physical memory).
+
+      c. Possibly, a mechanism is needed to flush the cache, when it is
+         known or even suspected that the information has changed.
+
+6. Name Error Bugs:
+
+   This bug is very similar to the Zero Answer bug. A server returns an
+   authoritative NXDOMAIN when the queried name is known to be bad, by
+   the server authoritative for the domain, in the absence of negative
+   caching. This authoritative NXDOMAIN response is usually accompanied
+   by the SOA record for the domain, in the authority section.
+
+   Resolvers should recognize that the name they queried for was a bad
+   name and should stop querying further.
+
+   Some resolvers might, however, not interpret this correctly and
+   continue to query servers, expecting an answer record.
+
+   Some applications, in fact, prompt NXDOMAIN answers! When given a
+   perfectly good name to resolve, they append the local domain to it
+   e.g., an application in the domain "foo.bar.com", when trying to
+   resolve the name "usc.edu" first tries "usc.edu.foo.bar.com", then
+   "usc.edu.bar.com" and finally the good name "usc.edu". This causes at
+   least two queries that return NXDOMAIN, for every good query. The
+   problem is aggravated since the negative answers from the previous
+   queries are not cached.  When the same name is sought again, the
+   process repeats.
+
+   Some DNS resolver implementations suffer from this problem, too. They
+   append successive sub-parts of the local domain using an implicit
+   searchlist mechanism, when certain conditions are satisfied and try
+   the original name, only when this first set of iterations fails. This
+   behavior recently caused pandemonium in the Internet when the domain
+   "edu.com" was registered and a wildcard "CNAME" record placed at the
+
+
+
+Kumar, Postel, Neuman, Danzig & Miller                          [Page 8]
+
+RFC 1536            Common DNS Implementation Errors        October 1993
+
+
+   top level. All machines from "com" domains trying to connect to hosts
+   in the "edu" domain ended up with connections to the local machine in
+   the "edu.com" domain!
+
+GOOD/BAD IMPLEMENTATIONS:
+
+   Some local versions of BIND already implement negative caching. They
+   typically cache negative answers with a very small TTL, sufficient to
+   answer a burst of queries spaced close together, as is typically
+   seen.
+
+   The next official public release of BIND (4.9.2) will have negative
+   caching as an ifdef'd feature.
+
+   The BIND resolver appends local domain to the given name, when one of
+   two conditions is met:
+
+      i.  The name has no periods and the flag RES_DEFNAME is set.
+      ii. There is no trailing period and the flag RES_DNSRCH is set.
+
+   The flags RES_DEFNAME and RES_DNSRCH are default resolver options, in
+   BIND, but can be changed at compile time.
+
+   Only if the name, so generated, returns an NXDOMAIN is the original
+   name tried as a Fully Qualified Domain Name. And only if it contains
+   at least one period.
+
+FIXES:
+
+      a. Fix the resolver code.
+
+      b. Negative Caching. Negative caching servers will restrict the
+         traffic seen on the wide-area network, even if not curb it
+         altogether.
+
+      c. Applications and resolvers should not append the local domain to
+         names they seek to resolve, as far as possible. Names
+         interspersed with periods should be treated as Fully Qualified
+         Domain Names.
+
+         In other words, Use searchlists only when explicitly specified.
+         No implicit searchlists should be used. A name that contains
+         any dots should first be tried as a FQDN and if that fails, with
+         the local domain name (or searchlist if specified) appended. A
+         name containing no dots can be appended with the searchlist right
+         away, but once again, no implicit searchlists should be used.
+
+
+
+
+
+Kumar, Postel, Neuman, Danzig & Miller                          [Page 9]
+
+RFC 1536            Common DNS Implementation Errors        October 1993
+
+
+   Associated with the name error bug is another problem where a server
+   might return an authoritative NXDOMAIN, although the name is valid. A
+   secondary server, on start-up, reads the zone information from the
+   primary, through a zone transfer. While it is in the process of
+   loading the zones, it does not have information about them, although
+   it is authoritative for them.  Thus, any query for a name in that
+   domain is answered with an NXDOMAIN response code. This problem might
+   not be disastrous were it not for negative caching servers that cache
+   this answer and so propagate incorrect information over the internet.
+
+BAD IMPLEMENTATION:
+
+   BIND apparently suffers from this problem.
+
+   Also, a new name added to the primary database will take a while to
+   propagate to the secondaries. Until that time, they will return
+   NXDOMAIN answers for a good name. Negative caching servers store this
+   answer, too and aggravate this problem further. This is probably a
+   more general DNS problem but is apparently more harmful in this
+   situation.
+
+FIX:
+
+      a. Servers should start answering only after loading all the zone
+         data. A failed server is better than a server handing out
+         incorrect information.
+
+      b. Negative cache records for a very small time, sufficient only
+         to ward off a burst of requests for the same bad name. This
+         could be related to the round-trip time of the server from
+         which the negative answer was received. Alternatively, a
+         statistical measure of the amount of time for which queries
+         for such names are received could be used. Minimum TTL value
+         from the SOA record is not advisable since they tend to be
+         pretty large.
+
+      c. A "PUSH" (or, at least, a "NOTIFY") mechanism should be allowed
+         and implemented, to allow the primary server to inform
+         secondaries that the database has been modified since it last
+         transferred zone data.  To alleviate the problem of "too many
+         zone transfers" that this might cause, Incremental Zone
+         Transfers should also be part of DNS.  Also, the primary should
+         not NOTIFY/PUSH with every update but bunch a good number
+         together.
+
+
+
+
+
+
+
+Kumar, Postel, Neuman, Danzig & Miller                         [Page 10]
+
+RFC 1536            Common DNS Implementation Errors        October 1993
+
+
+7. Format Errors:
+
+   Some resolvers issue query packets that do not necessarily conform to
+   standards as laid out in the relevant RFCs. This unnecessarily
+   increases net traffic and wastes server time.
+
+FIXES:
+
+      a. Fix resolvers.
+
+      b. Each resolver verify format of packets before sending them out,
+         using a mechanism outside of the resolver. This is, obviously,
+         needed only if step 1 cannot be followed.
+
+References
+
+   [1] Mockapetris, P., "Domain Names Concepts and Facilities", STD 13,
+       RFC 1034, USC/Information Sciences Institute, November 1987.
+
+   [2] Mockapetris, P., "Domain Names Implementation and Specification",
+       STD 13, RFC 1035, USC/Information Sciences Institute, November
+       1987.
+
+   [3] Partridge, C., "Mail Routing and the Domain System", STD 14, RFC
+       974, CSNET CIC BBN, January 1986.
+
+   [4] Gavron, E., "A Security Problem and Proposed Correction With
+       Widely Deployed DNS Software", RFC 1535, ACES Research Inc.,
+       October 1993.
+
+   [5] Beertema, P., "Common DNS Data File Configuration Errors", RFC
+       1537, CWI, October 1993.
+
+Security Considerations
+
+   Security issues are not discussed in this memo.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kumar, Postel, Neuman, Danzig & Miller                         [Page 11]
+
+RFC 1536            Common DNS Implementation Errors        October 1993
+
+
+Authors' Addresses
+
+   Anant Kumar
+   USC Information Sciences Institute
+   4676 Admiralty Way
+   Marina Del Rey CA 90292-6695
+
+   Phone:(310) 822-1511
+   FAX:  (310) 823-6741
+   EMail: anant@isi.edu
+
+
+   Jon Postel
+   USC Information Sciences Institute
+   4676 Admiralty Way
+   Marina Del Rey CA 90292-6695
+
+   Phone:(310) 822-1511
+   FAX:  (310) 823-6714
+   EMail: postel@isi.edu
+
+
+   Cliff Neuman
+   USC Information Sciences Institute
+   4676 Admiralty Way
+   Marina Del Rey CA 90292-6695
+
+   Phone:(310) 822-1511
+   FAX:  (310) 823-6714
+   EMail: bcn@isi.edu
+
+
+   Peter Danzig
+   Computer Science Department
+   University of Southern California
+   University Park
+
+   EMail: danzig@caldera.usc.edu
+
+
+   Steve Miller
+   Computer Science Department
+   University of Southern California
+   University Park
+   Los Angeles CA 90089
+
+   EMail: smiller@caldera.usc.edu
+
+
+
+
+Kumar, Postel, Neuman, Danzig & Miller                         [Page 12]
+
diff --git a/doc/rfc/rfc1537.txt b/doc/rfc/rfc1537.txt
new file mode 100644
index 0000000..81b9768
--- /dev/null
+++ b/doc/rfc/rfc1537.txt
@@ -0,0 +1,507 @@
+
+
+
+
+
+
+Network Working Group                                        P. Beertema
+Request for Comments: 1537                                           CWI
+Category: Informational                                     October 1993
+
+
+               Common DNS Data File Configuration Errors
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard.  Distribution of this memo is
+   unlimited.
+
+Abstract
+
+   This memo describes errors often found in DNS data files. It points
+   out common mistakes system administrators tend to make and why they
+   often go unnoticed for long periods of time.
+
+Introduction
+
+   Due to the lack of extensive documentation and automated tools, DNS
+   zone files have mostly been configured by system administrators, by
+   hand. Some of the rules for writing the data files are rather subtle
+   and a few common mistakes are seen in domains worldwide.
+
+   This document is an attempt to list "surprises" that administrators
+   might find hidden in their zone files. It describes the symptoms of
+   the malady and prescribes medicine to cure that. It also gives some
+   general recommendations and advice on specific nameserver and zone
+   file issues and on the (proper) use of the Domain Name System.
+
+1. SOA records
+
+   A problem I've found in quite some nameservers is that the various
+   timers have been set (far) too low. Especially for top level domain
+   nameservers this causes unnecessary traffic over international and
+   intercontinental links.
+
+   Unfortunately the examples given in the BIND manual, in RFC's and in
+   some expert documents give those very short timer values, and that's
+   most likely what people have modeled their SOA records after.
+
+   First of all a short explanation of the timers used in the SOA
+   record:
+
+
+
+
+
+
+Beertema                                                        [Page 1]
+
+RFC 1537       Common DNS Data File Configuration Errors    October 1993
+
+
+        - Refresh: The SOA record of the primary server is checked
+                   every "refresh" time by the secondary servers;
+                   if it has changed, a zone transfer is done.
+
+        - Retry: If a secondary server cannot reach the primary
+                 server, it tries it again every "retry" time.
+
+        - Expire: If for "expire" time the primary server cannot
+                  be reached, all information about the zone is
+                  invalidated on the secondary servers (i.e., they
+                  are no longer authoritative for that zone).
+
+        - Minimum TTL: The default TTL value for all records in the
+                       zone file; a different TTL value may be given
+                       explicitly in a record when necessary.
+                       (This timer is named "Minimum", and that's
+                       what it's function should be according to
+                       STD 13, RFC 1035, but most (all?)
+                       implementations take it as the default value
+                       exported with records without an explicit TTL
+                       value).
+
+   For top level domain servers I would recommend the following values:
+
+          86400 ; Refresh     24 hours
+           7200 ; Retry        2 hours
+        2592000 ; Expire      30 days
+         345600 ; Minimum TTL  4 days
+
+   For other servers I would suggest:
+
+          28800 ; Refresh     8 hours
+           7200 ; Retry       2 hours
+         604800 ; Expire      7 days
+          86400 ; Minimum TTL 1 day
+
+   but here the frequency of changes, the required speed of propagation,
+   the reachability of the primary server etc. play a role in optimizing
+   the timer values.
+
+2. Glue records
+
+   Quite often, people put unnecessary glue (A) records in their zone
+   files. Even worse is that I've even seen *wrong* glue records for an
+   external host in a primary zone file! Glue records need only be in a
+   zone file if the server host is within the zone and there is no A
+   record for that host elsewhere in the zone file.
+
+
+
+
+Beertema                                                        [Page 2]
+
+RFC 1537       Common DNS Data File Configuration Errors    October 1993
+
+
+   Old BIND versions ("native" 4.8.3 and older versions) showed the
+   problem that wrong glue records could enter secondary servers in a
+   zone transfer.
+
+3. "Secondary server surprise"
+
+   I've seen it happen on various occasions that hosts got bombarded by
+   nameserver requests without knowing why. On investigation it turned
+   out then that such a host was supposed to (i.e., the information was
+   in the root servers) run secondary for some domain (or reverse (in-
+   addr.arpa)) domain, without that host's nameserver manager having
+   been asked or even been told so!
+
+   Newer BIND versions (4.9 and later) solved this problem.  At the same
+   time though the fix has the disadvantage that it's far less easy to
+   spot this problem.
+
+   Practice has shown that most domain registrars accept registrations
+   of nameservers without checking if primary (!) and secondary servers
+   have been set up, informed, or even asked.  It should also be noted
+   that a combination of long-lasting unreachability of primary
+   nameservers, (therefore) expiration of zone information, plus static
+   IP routing, can lead to massive network traffic that can fill up
+   lines completely.
+
+4. "MX records surprise"
+
+   In a sense similar to point 3. Sometimes nameserver managers enter MX
+   records in their zone files that point to external hosts, without
+   first asking or even informing the systems managers of those external
+   hosts.  This has to be fought out between the nameserver manager and
+   the systems managers involved. Only as a last resort, if really
+   nothing helps to get the offending records removed, can the systems
+   manager turn to the naming authority of the domain above the
+   offending domain to get the problem sorted out.
+
+5. "Name extension surprise"
+
+   Sometimes one encounters weird names, which appear to be an external
+   name extended with a local domain. This is caused by forgetting to
+   terminate a name with a dot: names in zone files that don't end with
+   a dot are always expanded with the name of the current zone (the
+   domain that the zone file stands for or the last $ORIGIN).
+
+   Example: zone file for foo.xx:
+
+   pqr          MX 100  relay.yy.
+   xyz          MX 100  relay.yy           (no trailing dot!)
+
+
+
+Beertema                                                        [Page 3]
+
+RFC 1537       Common DNS Data File Configuration Errors    October 1993
+
+
+   When fully written out this stands for:
+
+      pqr.foo.xx.  MX 100  relay.yy.
+      xyz.foo.xx.  MX 100  relay.yy.foo.xx.   (name extension!)
+
+6. Missing secondary servers
+
+   It is required that there be a least 2 nameservers for a domain. For
+   obvious reasons the nameservers for top level domains need to be very
+   well reachable from all over the Internet. This implies that there
+   must be more than just 2 of them; besides, most of the (secondary)
+   servers should be placed at "strategic" locations, e.g., close to a
+   point where international and/or intercontinental lines come
+   together.  To keep things manageable, there shouldn't be too many
+   servers for a domain either.
+
+   Important aspects in selecting the location of primary and secondary
+   servers are reliability (network, host) and expedient contacts: in
+   case of problems, changes/fixes must be carried out quickly.  It
+   should be considered logical that primary servers for European top
+   level domains should run on a host in Europe, preferably (if
+   possible) in the country itself. For each top level domain there
+   should be 2 secondary servers in Europe and 2 in the USA, but there
+   may of course be more on either side.  An excessive number of
+   nameservers is not a good idea though; a recommended maximum is 7
+   nameservers.  In Europe, EUnet has offered to run secondary server
+   for each European top level domain.
+
+7. Wildcard MX records
+
+   Wildcard MX records should be avoided where possible. They often
+   cause confusion and errors: especially beginning nameserver managers
+   tend to overlook the fact that a host/domain listed with ANY type of
+   record in a zone file is NOT covered by an overall wildcard MX record
+   in that zone; this goes not only for simple domain/host names, but
+   also for names that cover one or more domains. Take the following
+   example in zone foo.bar:
+
+         *            MX 100  mailhost
+         pqr          MX 100  mailhost
+         abc.def      MX 100  mailhost
+
+   This makes pqr.foo.bar, def.foo.bar and abd.def.foo.bar valid
+   domains, but the wildcard MX record covers NONE of them, nor anything
+   below them.  To cover everything by MX records, the required entries
+   are:
+
+
+
+
+
+Beertema                                                        [Page 4]
+
+RFC 1537       Common DNS Data File Configuration Errors    October 1993
+
+
+         *            MX 100  mailhost
+         pqr          MX 100  mailhost
+         *.pqr        MX 100  mailhost
+         abc.def      MX 100  mailhost
+         *.def        MX 100  mailhost
+         *.abc.def    MX 100  mailhost
+
+   An overall wildcard MX record is almost never useful.
+
+   In particular the zone file of a top level domain should NEVER
+   contain only an overall wildcard MX record (*.XX). The effect of such
+   a wildcard MX record can be that mail is unnecessarily sent across
+   possibly expensive links, only to fail at the destination or gateway
+   that the record points to. Top level domain zone files should
+   explicitly list at least all the officially registered primary
+   subdomains.
+
+   Whereas overall wildcard MX records should be avoided, wildcard MX
+   records are acceptable as an explicit part of subdomain entries,
+   provided they are allowed under a given subdomain (to be determined
+   by the naming authority for that domain).
+
+   Example:
+
+         foo.xx.      MX 100  gateway.xx.
+                      MX 200  fallback.yy.
+         *.foo.xx.    MX 100  gateway.xx.
+                      MX 200  fallback.yy.
+8. Hostnames
+
+   People appear to sometimes look only at STD 11, RFC 822 to determine
+   whether a particular hostname is correct or not. Hostnames should
+   strictly conform to the syntax given in STD 13, RFC 1034 (page 11),
+   with *addresses* in addition conforming to RFC 822. As an example
+   take "c&w.blues" which is perfectly legal according to RFC 822, but
+   which can have quite surprising effects on particular systems, e.g.,
+   "telnet c&w.blues" on a Unix system.
+
+9. HINFO records
+
+   There appears to be a common misunderstanding that one of the data
+   fields (usually the second field) in HINFO records is optional. A
+   recent scan of all reachable nameservers in only one country revealed
+   some 300 incomplete HINFO records. Specifying two data fields in a
+   HINFO record is mandatory (RFC 1033), but note that this does *not*
+   mean that HINFO records themselves are mandatory.
+
+
+
+
+
+Beertema                                                        [Page 5]
+
+RFC 1537       Common DNS Data File Configuration Errors    October 1993
+
+
+10. Safety measures and specialties
+
+   Nameservers and resolvers aren't flawless. Bogus queries should be
+   kept from being forwarded to the root servers, since they'll only
+   lead to unnecessary intercontinental traffic. Known bogus queries
+   that can easily be dealt with locally are queries for 0 and broadcast
+   addresses.  To catch such queries, every nameserver should run
+   primary for the 0.in-addr.arpa and 255.in-addr.arpa zones; the zone
+   files need only contain a SOA and an NS record.
+
+   Also each nameserver should run primary for 0.0.127.in-addr.arpa;
+   that zone file should contain a SOA and NS record and an entry:
+
+         1    PTR     localhost.
+
+   There has been extensive discussion about whether or not to append
+   the local domain to it. The conclusion was that "localhost." would be
+   the best solution; reasons given were:
+
+   - "localhost" itself is used and expected to work on some systems.
+
+   - translating 127.0.0.1 into "localhost.my_domain" can cause some
+     software to connect to itself using the loopback interface when
+     it didn't want to.
+
+   Note that all domains that contain hosts should have a "localhost" A
+   record in them.
+
+   People maintaining zone files with the Serial number given in dotted
+   decimal notation (e.g., when SCCS is used to maintain the files)
+   should beware of a bug in all BIND versions: if the serial number is
+   in Release.Version (dotted decimal) notation, then it is virtually
+   impossible to change to a higher release: because of the wrong way
+   that notation is turned into an integer, it results in a serial
+   number that is LOWER than that of the former release.
+
+   For this reason and because the Serial is an (unsigned) integer
+   according to STD 13, RFC 1035, it is recommended not to use the
+   dotted decimal notation. A recommended notation is to use the date
+   (yyyymmdd), if necessary with an extra digit (yyyymmddn) if there is
+   or can be more than one change per day in a zone file.
+
+   Very old versions of DNS resolver code have a bug that causes queries
+   for A records with domain names like "192.16.184.3" to go out. This
+   happens when users type in IP addresses and the resolver code does
+   not catch this case before sending out a DNS query. This problem has
+   been fixed in all resolver implementations known to us but if it
+   still pops up it is very serious because all those queries will go to
+
+
+
+Beertema                                                        [Page 6]
+
+RFC 1537       Common DNS Data File Configuration Errors    October 1993
+
+
+   the root servers looking for top level domains like "3" etc. It is
+   strongly recommended to install the latest (publicly) available BIND
+   version plus all available patches to get rid of these and other
+   problems.
+
+   Running secondary nameserver off another secondary nameserver is
+   possible, but not recommended unless really necessary: there are
+   known cases where it has led to problems like bogus TTL values. This
+   can be caused by older or flawed implementations, but secondary
+   nameservers in principle should always transfer their zones from the
+   official primary nameserver.
+
+11. Some general points
+
+   The Domain Name System and nameserver are purely technical tools, not
+   meant in any way to exert control or impose politics. The function of
+   a naming authority is that of a clearing house. Anyone registering a
+   subdomain under a particular (top level) domain becomes naming
+   authority and therewith the sole responsible for that subdomain.
+   Requests to enter MX or NS records concerning such a subdomain
+   therefore always MUST be honored by the registrar of the next higher
+   domain.
+
+   Examples of practices that are not allowed are:
+
+      - imposing specific mail routing (MX records) when registering
+        a subdomain.
+
+      - making registration of a subdomain dependent on to the use of
+        certain networks or services.
+
+      - using TXT records as a means of (free) commercial advertising.
+
+   In the latter case a network service provider could decide to cut off
+   a particular site until the offending TXT records have been removed
+   from the site's zone file.
+
+   Of course there are obvious cases where a naming authority can refuse
+   to register a particular subdomain and can require a proposed name to
+   be changed in order to get it registered (think of DEC trying to
+   register a domain IBM.XX).
+
+   There are also cases were one has to probe the authority of the
+   person: sending in the application - not every systems manager should
+   be able to register a domain name for a whole university.  The naming
+   authority can impose certain extra rules as long as they don't
+   violate or conflict with the rights and interest of the registrars of
+   subdomains; a top level domain registrar may e.g., require that there
+
+
+
+Beertema                                                        [Page 7]
+
+RFC 1537       Common DNS Data File Configuration Errors    October 1993
+
+
+   be primary subdomain "ac" and "co" only and that subdomains be
+   registered under those primary subdomains.
+
+   The naming authority can also interfere in exceptional cases like the
+   one mentioned in point 4, e.g., by temporarily removing a domain's
+   entry from the nameserver zone files; this of course should be done
+   only with extreme care and only as a last resort.
+
+   When adding NS records for subdomains, top level domain nameserver
+   managers should realize that the people setting up the nameserver for
+   a subdomain often are rather inexperienced and can make mistakes that
+   can easily lead to the subdomain becoming completely unreachable or
+   that can cause unnecessary DNS traffic (see point 1). It is therefore
+   highly recommended that, prior to entering such an NS record, the
+   (top level) nameserver manager does a couple of sanity checks on the
+   new nameserver (SOA record and timers OK?, MX records present where
+   needed? No obvious errors made? Listed secondary servers
+   operational?). Things that cannot be caught though by such checks
+   are:
+
+      - resolvers set up to use external hosts as nameservers
+
+      - nameservers set up to use external hosts as forwarders
+        without permission from those hosts.
+
+   Care should also be taken when registering 2-letter subdomains.
+   Although this is allowed, an implication is that abbreviated
+   addressing (see STD 11, RFC 822, paragraph 6.2.2) is not possible in
+   and under that subdomain.  When requested to register such a domain,
+   one should always notify the people of this consequence. As an
+   example take the name "cs", which is commonly used for Computer
+   Science departments: it is also the name of the top level domain for
+   Czecho-Slovakia, so within the domain cs.foo.bar the user@host.cs is
+   ambiguous in that in can denote both a user on the host
+   host.cs.foo.bar and a user on the host "host" in Czecho-Slovakia.
+   (This example does not take into account the recent political changes
+   in the mentioned country).
+
+References
+
+   [1] Mockapetris, P., "Domain Names Concepts and Facilities", STD 13,
+       RFC 1034, USC/Information Sciences Institute, November 1987.
+
+   [2] Mockapetris, P., "Domain Names Implementation and Specification",
+       STD 13, RFC 1035, USC/Information Sciences Institute, November
+       1987.
+
+
+
+
+
+Beertema                                                        [Page 8]
+
+RFC 1537       Common DNS Data File Configuration Errors    October 1993
+
+
+   [3] Partridge, C., "Mail Routing and the Domain System", STD 14, RFC
+       974, CSNET CIC BBN, January 1986.
+
+   [4] Gavron, E., "A Security Problem and Proposed Correction With
+       Widely Deployed DNS Software", RFC 1535, ACES Research Inc.,
+       October 1993.
+
+   [5] Kumar, A., Postel, J., Neuman, C., Danzig, P., and S. Miller,
+       "Common DNS Implementation Errors and Suggested Fixes", RFC 1536,
+       USC/Information Sciences Institute, USC, October 1993.
+
+Security Considerations
+
+   Security issues are not discussed in this memo.
+
+Author's Address
+
+   Piet Beertema
+   CWI
+   Kruislaan 413
+   NL-1098 SJ Amsterdam
+   The Netherlands
+
+   Phone: +31 20 592 4112
+   FAX:   +31 20 592 4199
+   EMail: Piet.Beertema@cwi.nl
+
+
+Editor's Address
+
+   Anant Kumar
+   USC Information Sciences Institute
+   4676 Admiralty Way
+   Marina Del Rey CA 90292-6695
+
+   Phone:(310) 822-1511
+   FAX:  (310) 823-6741
+   EMail: anant@isi.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+Beertema                                                        [Page 9]
+
\ No newline at end of file
diff --git a/doc/rfc/rfc1591.txt b/doc/rfc/rfc1591.txt
new file mode 100644
index 0000000..89e0a25
--- /dev/null
+++ b/doc/rfc/rfc1591.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+Network Working Group                                          J. Postel
+Request for Comments: 1591                                           ISI
+Category: Informational                                       March 1994
+
+
+              Domain Name System Structure and Delegation
+
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  This memo
+   does not specify an Internet standard of any kind.  Distribution of
+   this memo is unlimited.
+
+1. Introduction
+
+   This memo provides some information on the structure of the names in
+   the Domain Name System (DNS), specifically the top-level domain
+   names; and on the administration of domains.  The Internet Assigned
+   Numbers Authority (IANA) is the overall authority for the IP
+   Addresses, the Domain Names, and many other parameters, used in the
+   Internet.  The day-to-day responsibility for the assignment of IP
+   Addresses, Autonomous System Numbers, and most top and second level
+   Domain Names are handled by the Internet Registry (IR) and regional
+   registries.
+
+2.  The Top Level Structure of the Domain Names
+
+   In the Domain Name System (DNS) naming of computers there is a
+   hierarchy of names.  The root of system is unnamed.  There are a set
+   of what are called "top-level domain names" (TLDs).  These are the
+   generic TLDs (EDU, COM, NET, ORG, GOV, MIL, and INT), and the two
+   letter country codes from ISO-3166.  It is extremely unlikely that
+   any other TLDs will be created.
+
+   Under each TLD may be created a hierarchy of names.  Generally, under
+   the generic TLDs the structure is very flat.  That is, many
+   organizations are registered directly under the TLD, and any further
+   structure is up to the individual organizations.
+
+   In the country TLDs, there is a wide variation in the structure, in
+   some countries the structure is very flat, in others there is
+   substantial structural organization.  In some country domains the
+   second levels are generic categories (such as, AC, CO, GO, and RE),
+   in others they are based on political geography, and in still others,
+   organization names are listed directly under the country code.  The
+   organization for the US country domain is described in RFC 1480 [1].
+
+
+
+
+Postel                                                          [Page 1]
+
+RFC 1591      Domain Name System Structure and Delegation     March 1994
+
+
+   Each of the generic TLDs was created for a general category of
+   organizations.  The country code domains (for example, FR, NL, KR,
+   US) are each organized by an administrator for that country.  These
+   administrators may further delegate the management of portions of the
+   naming tree.  These administrators are performing a public service on
+   behalf of the Internet community.  Descriptions of the generic
+   domains and the US country domain follow.
+
+   Of these generic domains, five are international in nature, and two
+   are restricted to use by entities in the United States.
+
+   World Wide Generic Domains:
+
+   COM - This domain is intended for commercial entities, that is
+         companies.  This domain has grown very large and there is
+         concern about the administrative load and system performance if
+         the current growth pattern is continued.  Consideration is
+         being taken to subdivide the COM domain and only allow future
+         commercial registrations in the subdomains.
+
+   EDU - This domain was originally intended for all educational
+         institutions.  Many Universities, colleges, schools,
+         educational service organizations, and educational consortia
+         have registered here.  More recently a decision has been taken
+         to limit further registrations to 4 year colleges and
+         universities.  Schools and 2-year colleges will be registered
+         in the country domains (see US Domain, especially K12 and CC,
+         below).
+
+   NET - This domain is intended to hold only the computers of network
+         providers, that is the NIC and NOC computers, the
+         administrative computers, and the network node computers.  The
+         customers of the network provider would have domain names of
+         their own (not in the NET TLD).
+
+   ORG - This domain is intended as the miscellaneous TLD for
+         organizations that didn't fit anywhere else.  Some non-
+         government organizations may fit here.
+
+   INT - This domain is for organizations established by international
+         treaties, or international databases.
+
+   United States Only Generic Domains:
+
+   GOV - This domain was originally intended for any kind of government
+         office or agency.  More recently a decision was taken to
+         register only agencies of the US Federal government in this
+         domain.  State and local agencies are registered in the country
+
+
+
+Postel                                                          [Page 2]
+
+RFC 1591      Domain Name System Structure and Delegation     March 1994
+
+
+         domains (see US Domain, below).
+
+   MIL - This domain is used by the US military.
+
+   Example country code Domain:
+
+   US - As an example of a country domain, the US domain provides for
+        the registration of all kinds of entities in the United States
+        on the basis of political geography, that is, a hierarchy of
+        <entity-name>.<locality>.<state-code>.US.  For example,
+        "IBM.Armonk.NY.US".  In addition, branches of the US domain are
+        provided within each state for schools (K12), community colleges
+        (CC), technical schools (TEC), state government agencies
+        (STATE), councils of governments (COG),libraries (LIB), museums
+        (MUS), and several other generic types of entities (see RFC 1480
+        for details [1]).
+
+   To find a contact for a TLD use the "whois" program to access the
+   database on the host rs.internic.net.  Append "-dom" to the name of
+   TLD you are interested in.  For example:
+
+                       whois -h rs.internic.net us-dom
+      or
+                       whois -h rs.internic.net edu-dom
+
+3.  The Administration of Delegated Domains
+
+   The Internet Assigned Numbers Authority (IANA) is responsible for the
+   overall coordination and management of the Domain Name System (DNS),
+   and especially the delegation of portions of the name space called
+   top-level domains.  Most of these top-level domains are two-letter
+   country codes taken from the ISO standard 3166.
+
+   A central Internet Registry (IR) has been selected and designated to
+   handled the bulk of the day-to-day administration of the Domain Name
+   System.  Applications for new top-level domains (for example, country
+   code domains) are handled by the IR with consultation with the IANA.
+   The central IR is INTERNIC.NET.  Second level domains in COM, EDU,
+   ORG, NET, and GOV are registered by the Internet Registry at the
+   InterNIC.  The second level domains in the MIL are registered by the
+   DDN registry at NIC.DDN.MIL.  Second level names in INT are
+   registered by the PVM at ISI.EDU.
+
+   While all requests for new top-level domains must be sent to the
+   Internic (at hostmaster@internic.net), the regional registries are
+   often enlisted to assist in the administration of the DNS, especially
+   in solving problems with a country administration.  Currently, the
+   RIPE NCC is the regional registry for Europe and the APNIC is the
+
+
+
+Postel                                                          [Page 3]
+
+RFC 1591      Domain Name System Structure and Delegation     March 1994
+
+
+   regional registry for the Asia-Pacific region, while the INTERNIC
+   administers the North America region, and all the as yet undelegated
+   regions.
+
+      The contact mailboxes for these regional registries are:
+
+         INTERNIC        hostmaster@internic.net
+         APNIC           hostmaster@apnic.net
+         RIPE NCC        ncc@ripe.net
+
+   The policy concerns involved when a new top-level domain is
+   established are described in the following.  Also mentioned are
+   concerns raised when it is necessary to change the delegation of an
+   established domain from one party to another.
+
+   A new top-level domain is usually created and its management
+   delegated to a "designated manager" all at once.
+
+   Most of these same concerns are relevant when a sub-domain is
+   delegated and in general the principles described here apply
+   recursively to all delegations of the Internet DNS name space.
+
+   The major concern in selecting a designated manager for a domain is
+   that it be able to carry out the necessary responsibilities, and have
+   the ability to do a equitable, just, honest, and competent job.
+
+   1) The key requirement is that for each domain there be a designated
+      manager for supervising that domain's name space.  In the case of
+      top-level domains that are country codes this means that there is
+      a manager that supervises the domain names and operates the domain
+      name system in that country.
+
+      The manager must, of course, be on the Internet.  There must be
+      Internet Protocol (IP) connectivity to the nameservers and email
+      connectivity to the management and staff of the manager.
+
+      There must be an administrative contact and a technical contact
+      for each domain.  For top-level domains that are country codes at
+      least the administrative contact must reside in the country
+      involved.
+
+   2) These designated authorities are trustees for the delegated
+      domain, and have a duty to serve the community.
+
+      The designated manager is the trustee of the top-level domain for
+      both the nation, in the case of a country code, and the global
+      Internet community.
+
+
+
+
+Postel                                                          [Page 4]
+
+RFC 1591      Domain Name System Structure and Delegation     March 1994
+
+
+      Concerns about "rights" and "ownership" of domains are
+      inappropriate.  It is appropriate to be concerned about
+      "responsibilities" and "service" to the community.
+
+   3) The designated manager must be equitable to all groups in the
+      domain that request domain names.
+
+      This means that the same rules are applied to all requests, all
+      requests must be processed in a non-discriminatory fashion, and
+      academic and commercial (and other) users are treated on an equal
+      basis.  No bias shall be shown regarding requests that may come
+      from customers of some other business related to the manager --
+      e.g., no preferential service for customers of a particular data
+      network provider.  There can be no requirement that a particular
+      mail system (or other application), protocol, or product be used.
+
+      There are no requirements on subdomains of top-level domains
+      beyond the requirements on higher-level domains themselves.  That
+      is, the requirements in this memo are applied recursively.  In
+      particular, all subdomains shall be allowed to operate their own
+      domain name servers, providing in them whatever information the
+      subdomain manager sees fit (as long as it is true and correct).
+
+   4) Significantly interested parties in the domain should agree that
+      the designated manager is the appropriate party.
+
+      The IANA tries to have any contending parties reach agreement
+      among themselves, and generally takes no action to change things
+      unless all the contending parties agree; only in cases where the
+      designated manager has substantially mis-behaved would the IANA
+      step in.
+
+      However, it is also appropriate for interested parties to have
+      some voice in selecting the designated manager.
+
+      There are two cases where the IANA and the central IR may
+      establish a new top-level domain and delegate only a portion of
+      it: (1) there are contending parties that cannot agree, or (2) the
+      applying party may not be able to represent or serve the whole
+      country.  The later case sometimes arises when a party outside a
+      country is trying to be helpful in getting networking started in a
+      country -- this is sometimes called a "proxy" DNS service.
+
+      The Internet DNS Names Review Board (IDNB), a committee
+      established by the IANA, will act as a review panel for cases in
+      which the parties can not reach agreement among themselves.  The
+      IDNB's decisions will be binding.
+
+
+
+
+Postel                                                          [Page 5]
+
+RFC 1591      Domain Name System Structure and Delegation     March 1994
+
+
+   5) The designated manager must do a satisfactory job of operating the
+      DNS service for the domain.
+
+      That is, the actual management of the assigning of domain names,
+      delegating subdomains and operating nameservers must be done with
+      technical competence.  This includes keeping the central IR (in
+      the case of top-level domains) or other higher-level domain
+      manager advised of the status of the domain, responding to
+      requests in a timely manner, and operating the database with
+      accuracy, robustness, and resilience.
+
+      There must be a primary and a secondary nameserver that have IP
+      connectivity to the Internet and can be easily checked for
+      operational status and database accuracy by the IR and the IANA.
+
+      In cases when there are persistent problems with the proper
+      operation of a domain, the delegation may be revoked, and possibly
+      delegated to another designated manager.
+
+   6) For any transfer of the designated manager trusteeship from one
+      organization to another, the higher-level domain manager (the IANA
+      in the case of top-level domains) must receive communications from
+      both the old organization and the new organization that assure the
+      IANA that the transfer in mutually agreed, and that the new
+      organization understands its responsibilities.
+
+      It is also very helpful for the IANA to receive communications
+      from other parties that may be concerned or affected by the
+      transfer.
+
+4. Rights to Names
+
+   1) Names and Trademarks
+
+      In case of a dispute between domain name registrants as to the
+      rights to a particular name, the registration authority shall have
+      no role or responsibility other than to provide the contact
+      information to both parties.
+
+      The registration of a domain name does not have any Trademark
+      status.  It is up to the requestor to be sure he is not violating
+      anyone else's Trademark.
+
+   2) Country Codes
+
+      The IANA is not in the business of deciding what is and what is
+      not a country.
+
+
+
+
+Postel                                                          [Page 6]
+
+RFC 1591      Domain Name System Structure and Delegation     March 1994
+
+
+      The selection of the ISO 3166 list as a basis for country code
+      top-level domain names was made with the knowledge that ISO has a
+      procedure for determining which entities should be and should not
+      be on that list.
+
+5. Security Considerations
+
+   Security issues are not discussed in this memo.
+
+6. Acknowledgements
+
+   Many people have made comments on draft version of these descriptions
+   and procedures.  Steve Goldstein and John Klensin have been
+   particularly helpful.
+
+7. Author's Address
+
+   Jon Postel
+   USC/Information Sciences Institute
+   4676 Admiralty Way
+   Marina del Rey, CA  90292
+
+   Phone: 310-822-1511
+   Fax:   310-823-6714
+   EMail: Postel@ISI.EDU
+
+7. References
+
+   [1] Cooper, A., and J. Postel, "The US Domain", RFC 1480,
+       USC/Information Sciences Institute, June 1993.
+
+   [2] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1340,
+       USC/Information Sciences Institute, July 1992.
+
+   [3] Mockapetris, P., "Domain Names - Concepts and Facilities", STD
+       13, RFC 1034, USC/Information Sciences Institute, November 1987.
+
+   [4] Mockapetris, P., "Domain Names - Implementation and
+       Specification", STD 13, RFC 1035, USC/Information Sciences
+       Institute, November 1987.
+
+   [6] Partridge, C., "Mail Routing and the Domain System", STD 14, RFC
+       974, CSNET CIC BBN, January 1986.
+
+   [7] Braden, R., Editor, "Requirements for Internet Hosts --
+       Application and Support", STD 3, RFC 1123, Internet Engineering
+       Task Force, October 1989.
+
+
+
+
+Postel                                                          [Page 7]
+
diff --git a/doc/rfc/rfc1611.txt b/doc/rfc/rfc1611.txt
new file mode 100644
index 0000000..ed5b93a
--- /dev/null
+++ b/doc/rfc/rfc1611.txt
@@ -0,0 +1,1683 @@
+
+
+
+
+
+
+Network Working Group                                         R. Austein
+Request for Comments: 1611               Epilogue Technology Corporation
+Category: Standards Track                                     J. Saperia
+                                           Digital Equipment Corporation
+                                                                May 1994
+
+                       DNS Server MIB Extensions
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Table of Contents
+
+   1. Introduction ..............................................    1
+   2. The SNMPv2 Network Management Framework ...................    2
+   2.1 Object Definitions .......................................    2
+   3. Overview ..................................................    2
+   3.1 Resolvers ................................................    3
+   3.2 Name Servers .............................................    3
+   3.3 Selected Objects .........................................    4
+   3.4 Textual Conventions ......................................    4
+   4. Definitions ...............................................    5
+   5. Acknowledgements ..........................................   28
+   6. References ................................................   28
+   7. Security Considerations ...................................   29
+   8. Authors' Addresses ........................................   30
+
+1.  Introduction
+
+   This memo defines a portion of the Management Information Base (MIB)
+   for use with network management protocols in the Internet community.
+   In particular, it describes a set of extensions which instrument DNS
+   name server functions.  This memo was produced by the DNS working
+   group.
+
+   With the adoption of the Internet-standard Network Management
+   Framework [4,5,6,7], and with a large number of vendor
+   implementations of these standards in commercially available
+   products, it became possible to provide a higher level of effective
+   network management in TCP/IP-based internets than was previously
+   available.  With the growth in the use of these standards, it has
+   become possible to consider the management of other elements of the
+   infrastructure beyond the basic TCP/IP protocols.  A key element of
+
+
+
+Austein & Saperia                                               [Page 1]
+
+RFC 1611               DNS Server MIB Extensions                May 1994
+
+
+   the TCP/IP infrastructure is the DNS.
+
+   Up to this point there has been no mechanism to integrate the
+   management of the DNS with SNMP-based managers.  This memo provides
+   the mechanisms by which IP-based management stations can effectively
+   manage DNS name server software in an integrated fashion.
+
+   We have defined DNS MIB objects to be used in conjunction with the
+   Internet MIB to allow access to and control of DNS name server
+   software via SNMP by the Internet community.
+
+2.  The SNMPv2 Network Management Framework
+
+   The SNMPv2 Network Management Framework consists of four major
+   components.  They are:
+
+      o  RFC 1442 which defines the SMI, the mechanisms used for
+         describing and naming objects for the purpose of management.
+
+      o  STD 17, RFC 1213 defines MIB-II, the core set of managed objects
+         for the Internet suite of protocols.
+
+      o  RFC 1445 which defines the administrative and other architectural
+         aspects of the framework.
+
+      o  RFC 1448 which defines the protocol used for network access to
+         managed objects.
+
+      The Framework permits new objects to be defined for the purpose of
+      experimentation and evaluation.
+
+2.1.  Object Definitions
+
+   Managed objects are accessed via a virtual information store, termed
+   the Management Information Base or MIB.  Objects in the MIB are
+   defined using the subset of Abstract Syntax Notation One (ASN.1)
+   defined in the SMI.  In particular, each object object type is named
+   by an OBJECT IDENTIFIER, an administratively assigned name.  The
+   object type together with an object instance serves to uniquely
+   identify a specific instantiation of the object.  For human
+   convenience, we often use a textual string, termed the descriptor, to
+   refer to the object type.
+
+3.  Overview
+
+   In theory, the DNS world is pretty simple.  There are two kinds of
+   entities: resolvers and name servers.  Resolvers ask questions.  Name
+   servers answer them.  The real world, however, is not so simple.
+
+
+
+Austein & Saperia                                               [Page 2]
+
+RFC 1611               DNS Server MIB Extensions                May 1994
+
+
+   Implementors have made widely differing choices about how to divide
+   DNS functions between resolvers and servers.  They have also
+   constructed various sorts of exotic hybrids.  The most difficult task
+   in defining this MIB was to accommodate this wide range of entities
+   without having to come up with a separate MIB for each.
+
+   We divided up the various DNS functions into two, non-overlapping
+   classes, called "resolver functions" and "name server functions."  A
+   DNS entity that performs what we define as resolver functions
+   contains a resolver, and therefore must implement the MIB groups
+   required of all resolvers which are defined in a separate MIB Module.
+   A DNS entity which implements name server functions is considered to
+   be a name server, and must implement the MIB groups required for name
+   servers in this module.  If the same piece of software performs both
+   resolver and server functions, we imagine that it contains both a
+   resolver and a server and would thus implement both the DNS Server
+   and DNS Resolver MIBs.
+
+3.1.  Resolvers
+
+   In our model, a resolver is a program (or piece thereof) which
+   obtains resource records from servers.  Normally it does so at the
+   behest of an application, but may also do so as part of its own
+   operation.  A resolver sends DNS protocol queries and receives DNS
+   protocol replies.  A resolver neither receives queries nor sends
+   replies.  A full service resolver is one that knows how to resolve
+   queries: it obtains the needed resource records by contacting a
+   server authoritative for the records desired.  A stub resolver does
+   not know how to resolve queries: it sends all queries to a local name
+   server, setting the "recursion desired" flag to indicate that it
+   hopes that the name server will be willing to resolve the query.  A
+   resolver may (optionally) have a cache for remembering previously
+   acquired resource records.  It may also have a negative cache for
+   remembering names or data that have been determined not to exist.
+
+3.2.  Name Servers
+
+   A name server is a program (or piece thereof) that provides resource
+   records to resolvers.  All references in this document to "a name
+   server" imply "the name server's role"; in some cases the name
+   server's role and the resolver's role might be combined into a single
+   program.  A name server receives DNS protocol queries and sends DNS
+   protocol replies.  A name server neither sends queries nor receives
+   replies.  As a consequence, name servers do not have caches.
+   Normally, a name server would expect to receive only those queries to
+   which it could respond with authoritative information.  However, if a
+   name server receives a query that it cannot respond to with purely
+   authoritative information, it may choose to try to obtain the
+
+
+
+Austein & Saperia                                               [Page 3]
+
+RFC 1611               DNS Server MIB Extensions                May 1994
+
+
+   necessary additional information from a resolver which may or may not
+   be a separate process.
+
+3.3.  Selected Objects
+
+   Many of the objects included in this memo have been created from
+   information contained in the DNS specifications [1,2], as amended and
+   clarified by subsequent host requirements documents [3].  Other
+   objects have been created based on experience with existing DNS
+   management tools, expected operational needs, the statistics
+   generated by existing DNS implementations, and the configuration
+   files used by existing DNS implementations.  These objects have been
+   ordered into groups as follows:
+
+      o  Server Configuration Group
+
+      o  Server Counter Group
+
+      o  Server Optional Counter Group
+
+      o  Server Zone Group
+
+   This information has been converted into a standard form using the
+   SNMPv2 SMI defined in [9].  For the most part, the descriptions are
+   influenced by the DNS related RFCs noted above.  For example, the
+   descriptions for counters used for the various types of queries of
+   DNS records are influenced by the definitions used for the various
+   record types found in [2].
+
+3.4.  Textual Conventions
+
+   Several conceptual data types have been introduced as a textual
+   conventions in this DNS MIB document.  These additions will
+   facilitate the common understanding of information used by the DNS.
+   No changes to the SMI or the SNMP are necessary to support these
+   conventions.
+
+   Readers familiar with MIBs designed to manage entities in the lower
+   layers of the Internet protocol suite may be surprised at the number
+   of non-enumerated integers used in this MIB to represent values such
+   as DNS RR class and type numbers.  The reason for this choice is
+   simple: the DNS itself is designed as an extensible protocol,
+   allowing new classes and types of resource records to be added to the
+   protocol without recoding the core DNS software.  Using non-
+   enumerated integers to represent these data types in this MIB allows
+   the MIB to accommodate these changes as well.
+
+
+
+
+
+Austein & Saperia                                               [Page 4]
+
+RFC 1611               DNS Server MIB Extensions                May 1994
+
+
+4.  Definitions
+
+   DNS-SERVER-MIB DEFINITIONS ::= BEGIN
+
+   IMPORTS
+       mib-2
+           FROM RFC-1213
+       MODULE-IDENTITY, OBJECT-TYPE, OBJECT-IDENTITY,
+       IpAddress, Counter32, Gauge32
+           FROM SNMPv2-SMI
+       TEXTUAL-CONVENTION, RowStatus, DisplayString, TruthValue
+           FROM SNMPv2-TC
+       MODULE-COMPLIANCE, OBJECT-GROUP
+           FROM SNMPv2-CONF;
+
+   dns OBJECT-IDENTITY
+       STATUS  current
+       DESCRIPTION
+               "The OID assigned to DNS MIB work by the IANA."
+       ::= { mib-2 32 }
+
+   dnsServMIB MODULE-IDENTITY
+       LAST-UPDATED "9401282251Z"
+       ORGANIZATION "IETF DNS Working Group"
+       CONTACT-INFO
+               "       Rob Austein
+               Postal: Epilogue Technology Corporation
+                       268 Main Street, Suite 283
+                       North Reading, MA 10864
+                       US
+                  Tel: +1 617 245 0804
+                  Fax: +1 617 245 8122
+               E-Mail: sra@epilogue.com
+
+                       Jon Saperia
+               Postal: Digital Equipment Corporation
+                       110 Spit Brook Road
+                       ZKO1-3/H18
+                       Nashua, NH 03062-2698
+                       US
+                  Tel: +1 603 881 0480
+                  Fax: +1 603 881 0120
+                Email: saperia@zko.dec.com"
+       DESCRIPTION
+               "The MIB module for entities implementing the server side
+               of the Domain Name System (DNS) protocol."
+       ::= { dns 1 }
+
+
+
+
+Austein & Saperia                                               [Page 5]
+
+RFC 1611               DNS Server MIB Extensions                May 1994
+
+
+   dnsServMIBObjects       OBJECT IDENTIFIER ::= { dnsServMIB 1 }
+
+   -- (Old-style) groups in the DNS server MIB.
+
+   dnsServConfig           OBJECT IDENTIFIER ::= { dnsServMIBObjects 1 }
+   dnsServCounter          OBJECT IDENTIFIER ::= { dnsServMIBObjects 2 }
+   dnsServOptCounter       OBJECT IDENTIFIER ::= { dnsServMIBObjects 3 }
+   dnsServZone             OBJECT IDENTIFIER ::= { dnsServMIBObjects 4 }
+
+
+   -- Textual conventions
+
+   DnsName ::= TEXTUAL-CONVENTION
+       -- A DISPLAY-HINT would be nice, but difficult to express.
+       STATUS  current
+       DESCRIPTION
+               "A DNS name is a sequence of labels.  When DNS names are
+               displayed, the boundaries between labels are typically
+               indicated by dots (e.g. `Acme' and `COM' are labels in
+               the name `Acme.COM').  In the DNS protocol, however, no
+               such separators are needed because each label is encoded
+               as a length octet followed by the indicated number of
+               octets of label.  For example, `Acme.COM' is encoded as
+               the octet sequence { 4, 'A', 'c', 'm', 'e', 3, 'C', 'O',
+               'M', 0 } (the final 0 is the length of the name of the
+               root domain, which appears implicitly at the end of any
+               DNS name).  This MIB uses the same encoding as the DNS
+               protocol.
+
+               A DnsName must always be a fully qualified name.  It is
+               an error to encode a relative domain name as a DnsName
+               without first making it a fully qualified name."
+       REFERENCE
+               "RFC-1034 section 3.1."
+       SYNTAX  OCTET STRING (SIZE (0..255))
+
+   DnsNameAsIndex ::= TEXTUAL-CONVENTION
+       STATUS  current
+       DESCRIPTION
+               "This textual convention is like a DnsName, but is used
+               as an index componant in tables.  Alphabetic characters
+               in names of this type are restricted to uppercase: the
+               characters 'a' through 'z' are mapped to the characters
+               'A' through 'Z'.  This restriction is intended to make
+               the lexical ordering imposed by SNMP useful when applied
+               to DNS names.
+
+               Note that it is theoretically possible for a valid DNS
+
+
+
+Austein & Saperia                                               [Page 6]
+
+RFC 1611               DNS Server MIB Extensions                May 1994
+
+
+               name to exceed the allowed length of an SNMP object
+               identifer, and thus be impossible to represent in tables
+               in this MIB that are indexed by DNS name.  Sampling of
+               DNS names in current use on the Internet suggests that
+               this limit does not pose a serious problem in practice."
+       REFERENCE
+               "RFC-1034 section 3.1, RFC-1448 section 4.1."
+       SYNTAX  DnsName
+
+   DnsClass ::= TEXTUAL-CONVENTION
+       DISPLAY-HINT "2d"
+       STATUS  current
+       DESCRIPTION
+               "This data type is used to represent the class values
+               which appear in Resource Records in the DNS.  A 16-bit
+               unsigned integer is used to allow room for new classes
+               of records to be defined.  Existing standard classes are
+               listed in the DNS specifications."
+       REFERENCE
+               "RFC-1035 section 3.2.4."
+       SYNTAX  INTEGER (0..65535)
+
+   DnsType ::= TEXTUAL-CONVENTION
+       DISPLAY-HINT "2d"
+       STATUS  current
+       DESCRIPTION
+               "This data type is used to represent the type values
+               which appear in Resource Records in the DNS.  A 16-bit
+               unsigned integer is used to allow room for new record
+               types to be defined.  Existing standard types are listed
+               in the DNS specifications."
+       REFERENCE
+               "RFC-1035 section 3.2.2."
+       SYNTAX  INTEGER (0..65535)
+
+   DnsQClass ::= TEXTUAL-CONVENTION
+       DISPLAY-HINT "2d"
+       STATUS  current
+       DESCRIPTION
+               "This data type is used to represent the QClass values
+               which appear in Resource Records in the DNS.  A 16-bit
+               unsigned integer is used to allow room for new QClass
+               records to be defined.  Existing standard QClasses are
+               listed in the DNS specification."
+       REFERENCE
+               "RFC-1035 section 3.2.5."
+       SYNTAX  INTEGER (0..65535)
+
+
+
+
+Austein & Saperia                                               [Page 7]
+
+RFC 1611               DNS Server MIB Extensions                May 1994
+
+
+   DnsQType ::= TEXTUAL-CONVENTION
+       DISPLAY-HINT "2d"
+       STATUS  current
+       DESCRIPTION
+               "This data type is used to represent the QType values
+               which appear in Resource Records in the DNS.  A 16-bit
+               unsigned integer is used to allow room for new QType
+               records to be defined.  Existing standard QTypes are
+               listed in the DNS specification."
+       REFERENCE
+               "RFC-1035 section 3.2.3."
+       SYNTAX  INTEGER (0..65535)
+
+   DnsTime ::= TEXTUAL-CONVENTION
+       DISPLAY-HINT "4d"
+       STATUS  current
+       DESCRIPTION
+               "DnsTime values are 32-bit unsigned integers which
+               measure time in seconds."
+       REFERENCE
+               "RFC-1035."
+       SYNTAX  Gauge32
+
+
+   DnsOpCode ::= TEXTUAL-CONVENTION
+       STATUS  current
+       DESCRIPTION
+               "This textual convention is used to represent the DNS
+               OPCODE values used in the header section of DNS
+               messages.  Existing standard OPCODE values are listed in
+               the DNS specifications."
+       REFERENCE
+               "RFC-1035 section 4.1.1."
+       SYNTAX  INTEGER (0..15)
+
+   DnsRespCode ::= TEXTUAL-CONVENTION
+       STATUS  current
+       DESCRIPTION
+               "This data type is used to represent the DNS RCODE value
+               in DNS response messages.  Existing standard RCODE
+               values are listed in the DNS specifications."
+       REFERENCE
+               "RFC-1035 section 4.1.1."
+       SYNTAX  INTEGER (0..15)
+
+
+
+
+
+
+
+Austein & Saperia                                               [Page 8]
+
+RFC 1611               DNS Server MIB Extensions                May 1994
+
+
+   -- Server Configuration Group
+
+   dnsServConfigImplementIdent OBJECT-TYPE
+       SYNTAX      DisplayString
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "The implementation identification string for the DNS
+               server software in use on the system, for example;
+               `FNS-2.1'"
+       ::= { dnsServConfig 1 }
+
+   dnsServConfigRecurs  OBJECT-TYPE
+       SYNTAX      INTEGER { available(1),
+                             restricted(2),
+                             unavailable(3) }
+       MAX-ACCESS  read-write
+       STATUS      current
+       DESCRIPTION
+               "This represents the recursion services offered by this
+               name server.  The values that can be read or written
+               are:
+
+               available(1) - performs recursion on requests from
+               clients.
+
+               restricted(2) - recursion is performed on requests only
+               from certain clients, for example; clients on an access
+               control list.
+
+               unavailable(3) - recursion is not available."
+        ::= { dnsServConfig 2 }
+
+   dnsServConfigUpTime OBJECT-TYPE
+       SYNTAX      DnsTime
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "If the server has a persistent state (e.g., a process),
+               this value will be the time elapsed since it started.
+               For software without persistant state, this value will
+               be zero."
+       ::= { dnsServConfig 3 }
+
+   dnsServConfigResetTime OBJECT-TYPE
+       SYNTAX      DnsTime
+       MAX-ACCESS  read-only
+       STATUS      current
+
+
+
+Austein & Saperia                                               [Page 9]
+
+RFC 1611               DNS Server MIB Extensions                May 1994
+
+
+       DESCRIPTION
+               "If the server has a persistent state (e.g., a process)
+               and supports a `reset' operation (e.g., can be told to
+               re-read configuration files), this value will be the
+               time elapsed since the last time the name server was
+               `reset.'  For software that does not have persistence or
+               does not support a `reset' operation, this value will be
+               zero."
+       ::= { dnsServConfig 4 }
+
+   dnsServConfigReset OBJECT-TYPE
+       SYNTAX      INTEGER { other(1),
+                             reset(2),
+                             initializing(3),
+                             running(4) }
+       MAX-ACCESS  read-write
+       STATUS      current
+       DESCRIPTION
+               "Status/action object to reinitialize any persistant name
+               server state.  When set to reset(2), any persistant
+               name server state (such as a process) is reinitialized as
+               if the name server had just been started.  This value
+               will never be returned by a read operation.  When read,
+               one of the following values will be returned:
+                   other(1) - server in some unknown state;
+                   initializing(3) - server (re)initializing;
+                   running(4) - server currently running."
+       ::= { dnsServConfig 5 }
+
+
+   -- Server Counter Group
+
+   dnsServCounterAuthAns OBJECT-TYPE
+       SYNTAX      Counter32
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "Number of queries which were authoritatively answered."
+       ::= { dnsServCounter 2 }
+
+   dnsServCounterAuthNoNames OBJECT-TYPE
+       SYNTAX      Counter32
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "Number of queries for which `authoritative no such name'
+               responses were made."
+       ::= { dnsServCounter 3 }
+
+
+
+Austein & Saperia                                              [Page 10]
+
+RFC 1611               DNS Server MIB Extensions                May 1994
+
+
+   dnsServCounterAuthNoDataResps OBJECT-TYPE
+       SYNTAX      Counter32
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "Number of queries for which `authoritative no such data'
+               (empty answer) responses were made."
+       ::= { dnsServCounter 4 }
+
+   dnsServCounterNonAuthDatas OBJECT-TYPE
+       SYNTAX      Counter32
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "Number of queries which were non-authoritatively
+               answered (cached data)."
+       ::= { dnsServCounter 5 }
+
+   dnsServCounterNonAuthNoDatas OBJECT-TYPE
+       SYNTAX      Counter32
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "Number of queries which were non-authoritatively
+               answered with no data (empty answer)."
+       ::= { dnsServCounter 6 }
+
+   dnsServCounterReferrals OBJECT-TYPE
+       SYNTAX      Counter32
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "Number of requests that were referred to other servers."
+       ::= { dnsServCounter 7 }
+
+   dnsServCounterErrors OBJECT-TYPE
+       SYNTAX      Counter32
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "Number of requests the server has processed that were
+               answered with errors (RCODE values other than 0 and 3)."
+       REFERENCE
+               "RFC-1035 section 4.1.1."
+       ::= { dnsServCounter 8 }
+
+   dnsServCounterRelNames OBJECT-TYPE
+       SYNTAX      Counter32
+
+
+
+Austein & Saperia                                              [Page 11]
+
+RFC 1611               DNS Server MIB Extensions                May 1994
+
+
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "Number of requests received by the server for names that
+               are only 1 label long (text form - no internal dots)."
+       ::= { dnsServCounter 9 }
+
+   dnsServCounterReqRefusals OBJECT-TYPE
+       SYNTAX      Counter32
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "Number of DNS requests refused by the server."
+       ::= { dnsServCounter 10 }
+
+   dnsServCounterReqUnparses OBJECT-TYPE
+       SYNTAX      Counter32
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "Number of requests received which were unparseable."
+       ::= { dnsServCounter 11 }
+
+   dnsServCounterOtherErrors OBJECT-TYPE
+       SYNTAX      Counter32
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "Number of requests which were aborted for other (local)
+               server errors."
+       ::= { dnsServCounter 12 }
+
+   -- DNS Server Counter Table
+
+   dnsServCounterTable OBJECT-TYPE
+       SYNTAX      SEQUENCE OF DnsServCounterEntry
+       MAX-ACCESS  not-accessible
+       STATUS      current
+       DESCRIPTION
+               "Counter information broken down by DNS class and type."
+       ::= { dnsServCounter 13 }
+
+   dnsServCounterEntry OBJECT-TYPE
+       SYNTAX      DnsServCounterEntry
+       MAX-ACCESS  not-accessible
+       STATUS      current
+       DESCRIPTION
+               "This table contains count information for each DNS class
+
+
+
+Austein & Saperia                                              [Page 12]
+
+RFC 1611               DNS Server MIB Extensions                May 1994
+
+
+               and type value known to the server.  The index allows
+               management software to to create indices to the table to
+               get the specific information desired, e.g., number of
+               queries over UDP for records with type value `A' which
+               came to this server.  In order to prevent an
+               uncontrolled expansion of rows in the table; if
+               dnsServCounterRequests is 0 and dnsServCounterResponses
+               is 0, then the row does not exist and `no such' is
+               returned when the agent is queried for such instances."
+       INDEX     { dnsServCounterOpCode,
+                   dnsServCounterQClass,
+                   dnsServCounterQType,
+                   dnsServCounterTransport }
+       ::= { dnsServCounterTable 1 }
+
+   DnsServCounterEntry ::=
+       SEQUENCE {
+           dnsServCounterOpCode
+               DnsOpCode,
+           dnsServCounterQClass
+               DnsClass,
+           dnsServCounterQType
+               DnsType,
+           dnsServCounterTransport
+               INTEGER,
+           dnsServCounterRequests
+               Counter32,
+           dnsServCounterResponses
+               Counter32
+           }
+
+   dnsServCounterOpCode OBJECT-TYPE
+       SYNTAX      DnsOpCode
+       MAX-ACCESS  not-accessible
+       STATUS      current
+       DESCRIPTION
+               "The DNS OPCODE being counted in this row of the table."
+       ::= { dnsServCounterEntry 1 }
+
+   dnsServCounterQClass OBJECT-TYPE
+       SYNTAX      DnsClass
+       MAX-ACCESS  not-accessible
+       STATUS      current
+       DESCRIPTION
+               "The class of record being counted in this row of the
+               table."
+       ::= { dnsServCounterEntry 2 }
+
+
+
+
+Austein & Saperia                                              [Page 13]
+
+RFC 1611               DNS Server MIB Extensions                May 1994
+
+
+   dnsServCounterQType OBJECT-TYPE
+       SYNTAX      DnsType
+       MAX-ACCESS  not-accessible
+       STATUS      current
+       DESCRIPTION
+               "The type of record which is being counted in this row in
+               the table."
+       ::= { dnsServCounterEntry 3 }
+
+   dnsServCounterTransport OBJECT-TYPE
+       SYNTAX      INTEGER { udp(1), tcp(2), other(3) }
+       MAX-ACCESS  not-accessible
+       STATUS      current
+       DESCRIPTION
+               "A value of udp(1) indicates that the queries reported on
+               this row were sent using UDP.
+
+               A value of tcp(2) indicates that the queries reported on
+               this row were sent using TCP.
+
+               A value of other(3) indicates that the queries reported
+               on this row were sent using a transport that was neither
+               TCP nor UDP."
+       ::= { dnsServCounterEntry 4 }
+
+   dnsServCounterRequests OBJECT-TYPE
+       SYNTAX      Counter32
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "Number of requests (queries) that have been recorded in
+               this row of the table."
+       ::= { dnsServCounterEntry 5 }
+
+   dnsServCounterResponses OBJECT-TYPE
+       SYNTAX      Counter32
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "Number of responses made by the server since
+               initialization for the kind of query identified on this
+               row of the table."
+       ::= { dnsServCounterEntry 6 }
+
+
+
+
+
+
+
+
+Austein & Saperia                                              [Page 14]
+
+RFC 1611               DNS Server MIB Extensions                May 1994
+
+
+   -- Server Optional Counter Group
+
+   -- The Server Optional Counter Group is intended for those systems
+   -- which make distinctions between the different sources of the DNS
+   -- queries as defined below.
+   --
+   -- Objects in this group are implemented on servers which distinguish
+   -- between queries which originate from the same host as the server,
+   -- queries from one of an arbitrary group of hosts that are on an
+   -- access list defined by the server, and queries from hosts that do
+   -- not fit either of these descriptions.
+   --
+   -- The objects found in the Server Counter group are totals.  Thus if
+   -- one wanted to identify, for example, the number of queries from
+   -- `remote' hosts which have been given authoritative answers, one
+   -- would subtract the current values of ServOptCounterFriendsAuthAns
+   -- and ServOptCounterSelfAuthAns from servCounterAuthAns.
+   --
+   -- The purpose of these distinctions is to allow for implementations
+   -- to group queries and responses on this basis.  One way in which
+   -- servers may make these distinctions is by looking at the source IP
+   -- address of the DNS query.  If the source of the query is `your
+   -- own' then the query should be counted as `yourself' (local host).
+   -- If the source of the query matches an `access list,' the query
+   -- came from a friend.  What constitutes an `access list' is
+   -- implementation dependent and could be as simple as a rule that all
+   -- hosts on the same IP network as the DNS server are classed
+   -- `friends.'
+   --
+   -- In order to avoid double counting, the following rules apply:
+   --
+   -- 1. No host is in more than one of the three groups defined above.
+   --
+   -- 2. All queries from the local host are always counted in the
+   --    `yourself' group regardless of what the access list, if any,
+   --    says.
+   --
+   -- 3. The access list should not define `your friends' in such a way
+   --    that it includes all hosts.   That is, not everybody is your
+   --    `friend.'
+
+   dnsServOptCounterSelfAuthAns OBJECT-TYPE
+       SYNTAX      Counter32
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "Number of requests the server has processed which
+               originated from a resolver on the same host for which
+
+
+
+Austein & Saperia                                              [Page 15]
+
+RFC 1611               DNS Server MIB Extensions                May 1994
+
+
+               there has been an authoritative answer."
+       ::= { dnsServOptCounter 1 }
+
+   dnsServOptCounterSelfAuthNoNames OBJECT-TYPE
+       SYNTAX      Counter32
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "Number of requests the server has processed which
+               originated from a resolver on the same host for which
+               there has been an authoritative no such name answer
+               given."
+       ::= { dnsServOptCounter 2 }
+
+   dnsServOptCounterSelfAuthNoDataResps OBJECT-TYPE
+       SYNTAX      Counter32
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "Number of requests the server has processed which
+               originated from a resolver on the same host for which
+               there has been an authoritative no such data answer
+               (empty answer) made."
+       ::= { dnsServOptCounter 3 }
+
+   dnsServOptCounterSelfNonAuthDatas OBJECT-TYPE
+       SYNTAX      Counter32
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "Number of requests the server has processed which
+               originated from a resolver on the same host for which a
+               non-authoritative answer (cached data) was made."
+       ::= { dnsServOptCounter 4 }
+
+   dnsServOptCounterSelfNonAuthNoDatas OBJECT-TYPE
+       SYNTAX      Counter32
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "Number of requests the server has processed which
+               originated from a resolver on the same host for which a
+               `non-authoritative, no such data' response was made
+               (empty answer)."
+       ::= { dnsServOptCounter 5 }
+
+   dnsServOptCounterSelfReferrals OBJECT-TYPE
+       SYNTAX      Counter32
+
+
+
+Austein & Saperia                                              [Page 16]
+
+RFC 1611               DNS Server MIB Extensions                May 1994
+
+
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "Number of queries the server has processed which
+               originated from a resolver on the same host and were
+               referred to other servers."
+       ::= { dnsServOptCounter 6 }
+
+   dnsServOptCounterSelfErrors OBJECT-TYPE
+       SYNTAX      Counter32
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "Number of requests the server has processed which
+               originated from a resolver on the same host which have
+               been answered with errors (RCODEs other than 0 and 3)."
+       REFERENCE
+               "RFC-1035 section 4.1.1."
+       ::= { dnsServOptCounter 7 }
+
+   dnsServOptCounterSelfRelNames OBJECT-TYPE
+       SYNTAX      Counter32
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "Number of requests received for names that are only 1
+               label long (text form - no internal dots) the server has
+               processed which originated from a resolver on the same
+               host."
+       ::= { dnsServOptCounter 8 }
+
+   dnsServOptCounterSelfReqRefusals OBJECT-TYPE
+       SYNTAX      Counter32
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "Number of DNS requests refused by the server which
+               originated from a resolver on the same host."
+       ::= { dnsServOptCounter 9 }
+
+   dnsServOptCounterSelfReqUnparses OBJECT-TYPE
+       SYNTAX      Counter32
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "Number of requests received which were unparseable and
+               which originated from a resolver on the same host."
+       ::= { dnsServOptCounter 10 }
+
+
+
+Austein & Saperia                                              [Page 17]
+
+RFC 1611               DNS Server MIB Extensions                May 1994
+
+
+   dnsServOptCounterSelfOtherErrors OBJECT-TYPE
+       SYNTAX      Counter32
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "Number of requests which were aborted for other (local)
+               server errors and which originated on the same host."
+       ::= { dnsServOptCounter 11 }
+
+   dnsServOptCounterFriendsAuthAns OBJECT-TYPE
+       SYNTAX      Counter32
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "Number of queries originating from friends which were
+               authoritatively answered.  The definition of friends is
+               a locally defined matter."
+       ::= { dnsServOptCounter 12 }
+
+   dnsServOptCounterFriendsAuthNoNames OBJECT-TYPE
+       SYNTAX      Counter32
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "Number of queries originating from friends, for which
+               authoritative `no such name' responses were made.  The
+               definition of friends is a locally defined matter."
+       ::= { dnsServOptCounter 13 }
+
+   dnsServOptCounterFriendsAuthNoDataResps OBJECT-TYPE
+       SYNTAX      Counter32
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "Number of queries originating from friends for which
+               authoritative no such data (empty answer) responses were
+               made.  The definition of friends is a locally defined
+               matter."
+       ::= { dnsServOptCounter 14 }
+
+   dnsServOptCounterFriendsNonAuthDatas OBJECT-TYPE
+       SYNTAX      Counter32
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "Number of queries originating from friends which were
+               non-authoritatively answered (cached data). The
+               definition of friends is a locally defined matter."
+
+
+
+Austein & Saperia                                              [Page 18]
+
+RFC 1611               DNS Server MIB Extensions                May 1994
+
+
+       ::= { dnsServOptCounter 15 }
+
+   dnsServOptCounterFriendsNonAuthNoDatas OBJECT-TYPE
+       SYNTAX      Counter32
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "Number of queries originating from friends which were
+               non-authoritatively answered with no such data (empty
+               answer)."
+       ::= { dnsServOptCounter 16 }
+
+   dnsServOptCounterFriendsReferrals OBJECT-TYPE
+       SYNTAX      Counter32
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "Number of requests which originated from friends that
+               were referred to other servers.  The definition of
+               friends is a locally defined matter."
+       ::= { dnsServOptCounter 17 }
+
+   dnsServOptCounterFriendsErrors OBJECT-TYPE
+       SYNTAX      Counter32
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "Number of requests the server has processed which
+               originated from friends and were answered with errors
+               (RCODE values other than 0 and 3).  The definition of
+               friends is a locally defined matter."
+       REFERENCE
+               "RFC-1035 section 4.1.1."
+       ::= { dnsServOptCounter 18 }
+
+   dnsServOptCounterFriendsRelNames OBJECT-TYPE
+       SYNTAX      Counter32
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "Number of requests received for names from friends that
+               are only 1 label long (text form - no internal dots) the
+               server has processed."
+       ::= { dnsServOptCounter 19 }
+
+   dnsServOptCounterFriendsReqRefusals OBJECT-TYPE
+       SYNTAX      Counter32
+       MAX-ACCESS  read-only
+
+
+
+Austein & Saperia                                              [Page 19]
+
+RFC 1611               DNS Server MIB Extensions                May 1994
+
+
+       STATUS      current
+       DESCRIPTION
+               "Number of DNS requests refused by the server which were
+               received from `friends'."
+       ::= { dnsServOptCounter 20 }
+
+   dnsServOptCounterFriendsReqUnparses OBJECT-TYPE
+       SYNTAX      Counter32
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "Number of requests received which were unparseable and
+               which originated from `friends'."
+       ::= { dnsServOptCounter 21 }
+
+   dnsServOptCounterFriendsOtherErrors OBJECT-TYPE
+       SYNTAX      Counter32
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "Number of requests which were aborted for other (local)
+               server errors and which originated from `friends'."
+       ::= { dnsServOptCounter 22 }
+
+
+   -- Server Zone Group
+
+   -- DNS Management Zone Configuration Table
+
+   -- This table contains zone configuration information.
+
+   dnsServZoneTable OBJECT-TYPE
+       SYNTAX      SEQUENCE OF DnsServZoneEntry
+       MAX-ACCESS  not-accessible
+       STATUS      current
+       DESCRIPTION
+               "Table of zones for which this name server provides
+               information.  Each of the zones may be loaded from stable
+               storage via an implementation-specific mechanism or may
+               be obtained from another name server via a zone transfer.
+
+               If name server doesn't load any zones, this table is
+               empty."
+       ::= { dnsServZone 1 }
+
+   dnsServZoneEntry OBJECT-TYPE
+       SYNTAX      DnsServZoneEntry
+       MAX-ACCESS  not-accessible
+
+
+
+Austein & Saperia                                              [Page 20]
+
+RFC 1611               DNS Server MIB Extensions                May 1994
+
+
+       STATUS      current
+       DESCRIPTION
+               "An entry in the name server zone table.  New rows may be
+               added either via SNMP or by the name server itself."
+       INDEX     { dnsServZoneName,
+                   dnsServZoneClass }
+       ::= { dnsServZoneTable 1 }
+
+   DnsServZoneEntry ::=
+       SEQUENCE {
+           dnsServZoneName
+               DnsNameAsIndex,
+           dnsServZoneClass
+               DnsClass,
+           dnsServZoneLastReloadSuccess
+               DnsTime,
+           dnsServZoneLastReloadAttempt
+               DnsTime,
+           dnsServZoneLastSourceAttempt
+               IpAddress,
+           dnsServZoneStatus
+               RowStatus,
+           dnsServZoneSerial
+               Counter32,
+           dnsServZoneCurrent
+               TruthValue,
+           dnsServZoneLastSourceSuccess
+               IpAddress
+       }
+
+   dnsServZoneName OBJECT-TYPE
+       SYNTAX      DnsNameAsIndex
+       MAX-ACCESS  not-accessible
+       STATUS      current
+       DESCRIPTION
+               "DNS name of the zone described by this row of the table.
+               This is the owner name of the SOA RR that defines the
+               top of the zone. This is name is in uppercase:
+               characters 'a' through 'z' are mapped to 'A' through 'Z'
+               in order to make the lexical ordering useful."
+       ::= { dnsServZoneEntry 1 }
+
+   dnsServZoneClass OBJECT-TYPE
+       SYNTAX      DnsClass
+       MAX-ACCESS  not-accessible
+       STATUS      current
+       DESCRIPTION
+               "DNS class of the RRs in this zone."
+
+
+
+Austein & Saperia                                              [Page 21]
+
+RFC 1611               DNS Server MIB Extensions                May 1994
+
+
+       ::= { dnsServZoneEntry 2 }
+
+   dnsServZoneLastReloadSuccess OBJECT-TYPE
+       SYNTAX      DnsTime
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "Elapsed time in seconds since last successful reload of
+               this zone."
+       ::= { dnsServZoneEntry 3 }
+
+   dnsServZoneLastReloadAttempt OBJECT-TYPE
+       SYNTAX      DnsTime
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "Elapsed time in seconds since last attempted reload of
+               this zone."
+       ::= { dnsServZoneEntry 4 }
+
+   dnsServZoneLastSourceAttempt OBJECT-TYPE
+       SYNTAX      IpAddress
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "IP address of host from which most recent zone transfer
+               of this zone was attempted.  This value should match the
+               value of dnsServZoneSourceSuccess if the attempt was
+               succcessful.  If zone transfer has not been attempted
+               within the memory of this name server, this value should
+               be 0.0.0.0."
+       ::= { dnsServZoneEntry 5 }
+
+   dnsServZoneStatus OBJECT-TYPE
+       SYNTAX      RowStatus
+       MAX-ACCESS  read-create
+       STATUS      current
+       DESCRIPTION
+               "The status of the information represented in this row of
+               the table."
+       ::= { dnsServZoneEntry 6 }
+
+   dnsServZoneSerial OBJECT-TYPE
+       SYNTAX      Counter32
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "Zone serial number (from the SOA RR) of the zone
+
+
+
+Austein & Saperia                                              [Page 22]
+
+RFC 1611               DNS Server MIB Extensions                May 1994
+
+
+               represented by this row of the table.  If the zone has
+               not been successfully loaded within the memory of this
+               name server, the value of this variable is zero."
+       ::= { dnsServZoneEntry 7 }
+
+   dnsServZoneCurrent OBJECT-TYPE
+       SYNTAX      TruthValue
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "Whether the server's copy of the zone represented by
+               this row of the table is currently valid.  If the zone
+               has never been successfully loaded or has expired since
+               it was last succesfully loaded, this variable will have
+               the value false(2), otherwise this variable will have
+               the value true(1)."
+       ::= { dnsServZoneEntry 8 }
+
+   dnsServZoneLastSourceSuccess OBJECT-TYPE
+       SYNTAX      IpAddress
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "IP address of host which was the source of the most
+               recent successful zone transfer for this zone.  If
+               unknown (e.g., zone has never been successfully
+               transfered) or irrelevant (e.g., zone was loaded from
+               stable storage), this value should be 0.0.0.0."
+       ::= { dnsServZoneEntry 9 }
+
+   -- DNS Zone Source Table
+
+   dnsServZoneSrcTable OBJECT-TYPE
+       SYNTAX      SEQUENCE OF DnsServZoneSrcEntry
+       MAX-ACCESS  not-accessible
+       STATUS      current
+       DESCRIPTION
+               "This table is a list of IP addresses from which the
+               server will attempt to load zone information using DNS
+               zone transfer operations.  A reload may occur due to SNMP
+               operations that create a row in dnsServZoneTable or a
+               SET to object dnsServZoneReload.  This table is only
+               used when the zone is loaded via zone transfer."
+       ::= { dnsServZone 2 }
+
+   dnsServZoneSrcEntry OBJECT-TYPE
+       SYNTAX      DnsServZoneSrcEntry
+       MAX-ACCESS  not-accessible
+
+
+
+Austein & Saperia                                              [Page 23]
+
+RFC 1611               DNS Server MIB Extensions                May 1994
+
+
+       STATUS      current
+       DESCRIPTION
+               "An entry in the name server zone source table."
+       INDEX     { dnsServZoneSrcName,
+                   dnsServZoneSrcClass,
+                   dnsServZoneSrcAddr }
+       ::= { dnsServZoneSrcTable 1 }
+
+   DnsServZoneSrcEntry ::=
+       SEQUENCE {
+           dnsServZoneSrcName
+               DnsNameAsIndex,
+           dnsServZoneSrcClass
+               DnsClass,
+           dnsServZoneSrcAddr
+               IpAddress,
+           dnsServZoneSrcStatus
+               RowStatus
+       }
+
+   dnsServZoneSrcName OBJECT-TYPE
+       SYNTAX      DnsNameAsIndex
+       MAX-ACCESS  not-accessible
+       STATUS      current
+       DESCRIPTION
+               "DNS name of the zone to which this entry applies."
+       ::= { dnsServZoneSrcEntry 1 }
+
+   dnsServZoneSrcClass OBJECT-TYPE
+       SYNTAX      DnsClass
+       MAX-ACCESS  not-accessible
+       STATUS      current
+       DESCRIPTION
+               "DNS class of zone to which this entry applies."
+       ::= { dnsServZoneSrcEntry 2 }
+
+   dnsServZoneSrcAddr OBJECT-TYPE
+       SYNTAX      IpAddress
+       MAX-ACCESS  not-accessible
+       STATUS      current
+       DESCRIPTION
+               "IP address of name server host from which this zone
+               might be obtainable."
+       ::= { dnsServZoneSrcEntry 3 }
+
+   dnsServZoneSrcStatus OBJECT-TYPE
+       SYNTAX      RowStatus
+       MAX-ACCESS  read-create
+
+
+
+Austein & Saperia                                              [Page 24]
+
+RFC 1611               DNS Server MIB Extensions                May 1994
+
+
+       STATUS      current
+       DESCRIPTION
+               "The status of the information represented in this row of
+               the table."
+       ::= { dnsServZoneSrcEntry 4 }
+
+
+   -- SNMPv2 groups.
+
+   dnsServMIBGroups        OBJECT IDENTIFIER ::= { dnsServMIB 2 }
+
+   dnsServConfigGroup OBJECT-GROUP
+       OBJECTS   { dnsServConfigImplementIdent,
+                   dnsServConfigRecurs,
+                   dnsServConfigUpTime,
+                   dnsServConfigResetTime,
+                   dnsServConfigReset }
+       STATUS      current
+       DESCRIPTION
+               "A collection of objects providing basic configuration
+               control of a DNS name server."
+       ::= { dnsServMIBGroups 1 }
+
+   dnsServCounterGroup OBJECT-GROUP
+       OBJECTS   { dnsServCounterAuthAns,
+                   dnsServCounterAuthNoNames,
+                   dnsServCounterAuthNoDataResps,
+                   dnsServCounterNonAuthDatas,
+                   dnsServCounterNonAuthNoDatas,
+                   dnsServCounterReferrals,
+                   dnsServCounterErrors,
+                   dnsServCounterRelNames,
+                   dnsServCounterReqRefusals,
+                   dnsServCounterReqUnparses,
+                   dnsServCounterOtherErrors,
+                   dnsServCounterOpCode,
+                   dnsServCounterQClass,
+                   dnsServCounterQType,
+                   dnsServCounterTransport,
+                   dnsServCounterRequests,
+                   dnsServCounterResponses }
+       STATUS      current
+       DESCRIPTION
+               "A collection of objects providing basic instrumentation
+               of a DNS name server."
+       ::= { dnsServMIBGroups 2 }
+
+
+
+
+
+Austein & Saperia                                              [Page 25]
+
+RFC 1611               DNS Server MIB Extensions                May 1994
+
+
+   dnsServOptCounterGroup OBJECT-GROUP
+       OBJECTS   { dnsServOptCounterSelfAuthAns,
+                   dnsServOptCounterSelfAuthNoNames,
+                   dnsServOptCounterSelfAuthNoDataResps,
+                   dnsServOptCounterSelfNonAuthDatas,
+                   dnsServOptCounterSelfNonAuthNoDatas,
+                   dnsServOptCounterSelfReferrals,
+                   dnsServOptCounterSelfErrors,
+                   dnsServOptCounterSelfRelNames,
+                   dnsServOptCounterSelfReqRefusals,
+                   dnsServOptCounterSelfReqUnparses,
+                   dnsServOptCounterSelfOtherErrors,
+                   dnsServOptCounterFriendsAuthAns,
+                   dnsServOptCounterFriendsAuthNoNames,
+                   dnsServOptCounterFriendsAuthNoDataResps,
+                   dnsServOptCounterFriendsNonAuthDatas,
+                   dnsServOptCounterFriendsNonAuthNoDatas,
+                   dnsServOptCounterFriendsReferrals,
+                   dnsServOptCounterFriendsErrors,
+                   dnsServOptCounterFriendsRelNames,
+                   dnsServOptCounterFriendsReqRefusals,
+                   dnsServOptCounterFriendsReqUnparses,
+                   dnsServOptCounterFriendsOtherErrors }
+       STATUS      current
+       DESCRIPTION
+               "A collection of objects providing extended
+               instrumentation of a DNS name server."
+       ::= { dnsServMIBGroups 3 }
+
+   dnsServZoneGroup OBJECT-GROUP
+       OBJECTS   { dnsServZoneName,
+                   dnsServZoneClass,
+                   dnsServZoneLastReloadSuccess,
+                   dnsServZoneLastReloadAttempt,
+                   dnsServZoneLastSourceAttempt,
+                   dnsServZoneLastSourceSuccess,
+                   dnsServZoneStatus,
+                   dnsServZoneSerial,
+                   dnsServZoneCurrent,
+                   dnsServZoneSrcName,
+                   dnsServZoneSrcClass,
+                   dnsServZoneSrcAddr,
+                   dnsServZoneSrcStatus }
+       STATUS      current
+       DESCRIPTION
+               "A collection of objects providing configuration control
+               of a DNS name server which loads authoritative zones."
+       ::= { dnsServMIBGroups 4 }
+
+
+
+Austein & Saperia                                              [Page 26]
+
+RFC 1611               DNS Server MIB Extensions                May 1994
+
+
+   -- Compliances.
+
+   dnsServMIBCompliances OBJECT IDENTIFIER ::= { dnsServMIB 3 }
+
+   dnsServMIBCompliance MODULE-COMPLIANCE
+       STATUS      current
+       DESCRIPTION
+               "The compliance statement for agents implementing the DNS
+               name server MIB extensions."
+       MODULE -- This MIB module
+           MANDATORY-GROUPS { dnsServConfigGroup, dnsServCounterGroup }
+           GROUP   dnsServOptCounterGroup
+           DESCRIPTION
+               "The server optional counter group is unconditionally
+               optional."
+           GROUP   dnsServZoneGroup
+           DESCRIPTION
+               "The server zone group is mandatory for any name server
+               that acts as an authoritative server for any DNS zone."
+           OBJECT  dnsServConfigRecurs
+           MIN-ACCESS      read-only
+           DESCRIPTION
+               "This object need not be writable."
+           OBJECT  dnsServConfigReset
+           MIN-ACCESS      read-only
+           DESCRIPTION
+               "This object need not be writable."
+       ::= { dnsServMIBCompliances 1 }
+
+   END
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Austein & Saperia                                              [Page 27]
+
+RFC 1611               DNS Server MIB Extensions                May 1994
+
+
+5.  Acknowledgements
+
+   This document is the result of work undertaken the by DNS working
+   group.  The authors would particularly like to thank the following
+   people for their contributions to this document: Philip Almquist,
+   Frank Kastenholz (FTP Software), Joe Peck (DEC), Dave Perkins
+   (SynOptics), Win Treese (DEC), and Mimi Zohar (IBM).
+
+6.  References
+
+   [1] Mockapetris, P., "Domain Names -- Concepts and Facilities", STD
+       13, RFC 1034, USC/Information Sciences Institute, November 1987.
+
+   [2] Mockapetris, P., "Domain Names -- Implementation and
+       Specification", STD 13, RFC 1035, USC/Information Sciences
+       Institute, November 1987.
+
+   [3] Braden, R., Editor, "Requirements for Internet Hosts --
+       Application and Support, STD 3, RFC 1123, USC/Information
+       Sciences Institute, October 1989.
+
+   [4] Rose, M., and K. McCloghrie, "Structure and Identification of
+       Management Information for TCP/IP-based internets", STD 16, RFC
+       1155, Performance Systems International, Hughes LAN Systems, May
+       1990.
+
+   [5] McCloghrie, K., and M. Rose, "Management Information Base for
+       Network Management of TCP/IP-based internets", RFC 1156, Hughes
+       LAN Systems, Performance Systems International, May 1990.
+
+   [6] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple
+       Network Management Protocol", STD 15, RFC 1157, SNMP Research,
+       Performance Systems International, Performance Systems
+       International, MIT Laboratory for Computer Science, May 1990.
+
+   [7] Rose, M., and K. McCloghrie, Editors, "Concise MIB Definitions",
+       STD 16, RFC 1212, Performance Systems International, Hughes LAN
+       Systems, March 1991.
+
+   [8] McCloghrie, K., and M. Rose, Editors, "Management Information
+       Base for Network Management of TCP/IP-based internets: MIB-II",
+       STD 17, RFC 1213, Hughes LAN Systems, Performance Systems
+       International, March 1991.
+
+   [9] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Structure
+       of Management Information for version 2 of the Simple Network
+       Management Protocol (SNMPv2)", RFC 1442, SNMP Research, Inc.,
+       Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon
+
+
+
+Austein & Saperia                                              [Page 28]
+
+RFC 1611               DNS Server MIB Extensions                May 1994
+
+
+       University, April 1993.
+
+  [10] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Textual
+       Conventions for version 2 of the the Simple Network Management
+       Protocol (SNMPv2)", RFC 1443, SNMP Research, Inc., Hughes LAN
+       Systems, Dover Beach Consulting, Inc., Carnegie Mellon
+       University, April 1993.
+
+  [11] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser,
+       "Conformance Statements for version 2 of the the Simple Network
+       Management Protocol (SNMPv2)", RFC 1444, SNMP Research, Inc.,
+       Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon
+       University, April 1993.
+
+  [12] Galvin, J., and K. McCloghrie, "Administrative Model for version
+       2 of the Simple Network Management Protocol (SNMPv2)", RFC 1445,
+       Trusted Information Systems, Hughes LAN Systems, April 1993.
+
+  [13] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol
+       Operations for version 2 of the Simple Network Management
+       Protocol (SNMPv2)", RFC 1448, SNMP Research, Inc., Hughes LAN
+       Systems, Dover Beach Consulting, Inc., Carnegie Mellon
+       University, April 1993.
+
+  [14] "Information processing systems - Open Systems Interconnection -
+       Specification of Abstract Syntax Notation One (ASN.1)",
+       International Organization for Standardization, International
+       Standard 8824, December 1987.
+
+7.  Security Considerations
+
+   Security issues are not discussed in this memo.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Austein & Saperia                                              [Page 29]
+
+RFC 1611               DNS Server MIB Extensions                May 1994
+
+
+8.  Authors' Addresses
+
+   Rob Austein
+   Epilogue Technology Corporation
+   268 Main Street, Suite 283
+   North Reading, MA 01864
+   USA
+
+   Phone: +1-617-245-0804
+   Fax:   +1-617-245-8122
+   EMail: sra@epilogue.com
+
+
+   Jon Saperia
+   Digital Equipment Corporation
+   110 Spit Brook Road
+   ZKO1-3/H18
+   Nashua, NH 03062-2698
+   USA
+
+   Phone: +1-603-881-0480
+   Fax:   +1-603-881-0120
+   EMail: saperia@zko.dec.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Austein & Saperia                                              [Page 30]
+
diff --git a/doc/rfc/rfc1612.txt b/doc/rfc/rfc1612.txt
new file mode 100644
index 0000000..4ef23b0
--- /dev/null
+++ b/doc/rfc/rfc1612.txt
@@ -0,0 +1,1795 @@
+
+
+
+
+
+
+Network Working Group                                         R. Austein
+Request for Comments: 1612               Epilogue Technology Corporation
+Category: Standards Track                                     J. Saperia
+                                           Digital Equipment Corporation
+                                                                May 1994
+
+
+                      DNS Resolver MIB Extensions
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Table of Contents
+
+   1. Introduction ..............................................    1
+   2. The SNMPv2 Network Management Framework ...................    2
+   2.1 Object Definitions .......................................    2
+   3. Overview ..................................................    2
+   3.1 Resolvers ................................................    3
+   3.2 Name Servers .............................................    3
+   3.3 Selected Objects .........................................    4
+   3.4 Textual Conventions ......................................    4
+   4. Definitions ...............................................    5
+   5. Acknowledgements ..........................................   30
+   6. References ................................................   30
+   7. Security Considerations ...................................   32
+   8. Authors' Addresses ........................................   32
+
+1.  Introduction
+
+   This memo defines a portion of the Management Information Base (MIB)
+   for use with network management protocols in the Internet community.
+   In particular, it describes a set of extensions which instrument DNS
+   resolver functions.  This memo was produced by the DNS working group.
+
+   With the adoption of the Internet-standard Network Management
+   Framework [4,5,6,7], and with a large number of vendor
+   implementations of these standards in commercially available
+   products, it became possible to provide a higher level of effective
+   network management in TCP/IP-based internets than was previously
+   available.  With the growth in the use of these standards, it has
+   become possible to consider the management of other elements of the
+   infrastructure beyond the basic TCP/IP protocols.  A key element of
+
+
+
+Austein & Saperia                                               [Page 1]
+
+RFC 1612                    DNS Resolver MIB                    May 1994
+
+
+   the TCP/IP infrastructure is the DNS.
+
+   Up to this point there has been no mechanism to integrate the
+   management of the DNS with SNMP-based managers.  This memo provides
+   the mechanisms by which IP-based management stations can effectively
+   manage DNS resolver software in an integrated fashion.
+
+   We have defined DNS MIB objects to be used in conjunction with the
+   Internet MIB to allow access to and control of DNS resolver software
+   via SNMP by the Internet community.
+
+2.  The SNMPv2 Network Management Framework
+
+   The SNMPv2 Network Management Framework consists of four major
+   components.  They are:
+
+      o  RFC 1442 which defines the SMI, the mechanisms used for
+         describing and naming objects for the purpose of management.
+
+      o  STD 17, RFC 1213 defines MIB-II, the core set of managed
+         objects for the Internet suite of protocols.
+
+      o  RFC 1445 which defines the administrative and other
+         architectural aspects of the framework.
+
+      o  RFC 1448 which defines the protocol used for network access to
+         managed objects.
+
+   The Framework permits new objects to be defined for the purpose of
+   experimentation and evaluation.
+
+2.1.  Object Definitions
+
+   Managed objects are accessed via a virtual information store, termed
+   the Management Information Base or MIB.  Objects in the MIB are
+   defined using the subset of Abstract Syntax Notation One (ASN.1)
+   defined in the SMI.  In particular, each object object type is named
+   by an OBJECT IDENTIFIER, an administratively assigned name.  The
+   object type together with an object instance serves to uniquely
+   identify a specific instantiation of the object.  For human
+   convenience, we often use a textual string, termed the descriptor, to
+   refer to the object type.
+
+3.  Overview
+
+   In theory, the DNS world is pretty simple.  There are two kinds of
+   entities: resolvers and name servers.  Resolvers ask questions.  Name
+   servers answer them.  The real world, however, is not so simple.
+
+
+
+Austein & Saperia                                               [Page 2]
+
+RFC 1612                    DNS Resolver MIB                    May 1994
+
+
+   Implementors have made widely differing choices about how to divide
+   DNS functions between resolvers and servers.  They have also
+   constructed various sorts of exotic hybrids.  The most difficult task
+   in defining this MIB was to accommodate this wide range of entities
+   without having to come up with a separate MIB for each.
+
+   We divided up the various DNS functions into two, non-overlapping
+   classes, called "resolver functions" and "name server functions."  A
+   DNS entity that performs what we define as resolver functions
+   contains a resolver, and therefore must implement the MIB groups
+   required of all resolvers which are defined in this module.  Some
+   resolvers also implement "optional" functions such as a cache, in
+   which case they must also implement the cache group contained in this
+   MIB.  A DNS entity which implements name server functions is
+   considered to be a name server, and must implement the MIB groups
+   required for name servers which are defined in a separate module.  If
+   the same piece of software performs both resolver and server
+   functions, we imagine that it contains both a resolver and a server
+   and would thus implement both the DNS Server and DNS Resolver MIBs.
+
+3.1.  Resolvers
+
+   In our model, a resolver is a program (or piece thereof) which
+   obtains resource records from servers.  Normally it does so at the
+   behest of an application, but may also do so as part of its own
+   operation.  A resolver sends DNS protocol queries and receives DNS
+   protocol replies.  A resolver neither receives queries nor sends
+   replies.  A full service resolver is one that knows how to resolve
+   queries: it obtains the needed resource records by contacting a
+   server authoritative for the records desired.  A stub resolver does
+   not know how to resolve queries: it sends all queries to a local name
+   server, setting the "recursion desired" flag to indicate that it
+   hopes that the name server will be willing to resolve the query.  A
+   resolver may (optionally) have a cache for remembering previously
+   acquired resource records.  It may also have a negative cache for
+   remembering names or data that have been determined not to exist.
+
+3.2.  Name Servers
+
+   A name server is a program (or piece thereof) that provides resource
+   records to resolvers.  All references in this document to "a name
+   server" imply "the name server's role"; in some cases the name
+   server's role and the resolver's role might be combined into a single
+   program.  A name server receives DNS protocol queries and sends DNS
+   protocol replies.  A name server neither sends queries nor receives
+   replies.  As a consequence, name servers do not have caches.
+   Normally, a name server would expect to receive only those queries to
+   which it could respond with authoritative information.  However, if a
+
+
+
+Austein & Saperia                                               [Page 3]
+
+RFC 1612                    DNS Resolver MIB                    May 1994
+
+
+   name server receives a query that it cannot respond to with purely
+   authoritative information, it may choose to try to obtain the
+   necessary additional information from a resolver which may or may not
+   be a separate process.
+
+3.3.  Selected Objects
+
+   Many of the objects included in this memo have been created from
+   information contained in the DNS specifications [1,2], as amended and
+   clarified by subsequent host requirements documents [3].  Other
+   objects have been created based on experience with existing DNS
+   management tools, expected operational needs, the statistics
+   generated by existing DNS implementations, and the configuration
+   files used by existing DNS implementations.  These objects have been
+   ordered into groups as follows:
+
+         o  Resolver Configuration Group
+
+         o  Resolver Counter Group
+
+         o  Resolver Lame Delegation Group
+
+         o  Resolver Cache Group
+
+         o  Resolver Negative Cache Group
+
+         o  Resolver Optional Counter Group
+
+   This information has been converted into a standard form using the
+   SNMPv2 SMI defined in [9].  For the most part, the descriptions are
+   influenced by the DNS related RFCs noted above.  For example, the
+   descriptions for counters used for the various types of queries of
+   DNS records are influenced by the definitions used for the various
+   record types found in [2].
+
+3.4.  Textual Conventions
+
+   Several conceptual data types have been introduced as a textual
+   conventions in the DNS Server MIB document and have been imported
+   into this MIB module.  These additions will facilitate the common
+   understanding of information used by the DNS.  No changes to the SMI
+   or the SNMP are necessary to support these conventions.
+
+   Readers familiar with MIBs designed to manage entities in the lower
+   layers of the Internet protocol suite may be surprised at the number
+   of non-enumerated integers used in this MIB to represent values such
+   as DNS RR class and type numbers.  The reason for this choice is
+   simple: the DNS itself is designed as an extensible protocol,
+
+
+
+Austein & Saperia                                               [Page 4]
+
+RFC 1612                    DNS Resolver MIB                    May 1994
+
+
+   allowing new classes and types of resource records to be added to the
+   protocol without recoding the core DNS software.  Using non-
+   enumerated integers to represent these data types in this MIB allows
+   the MIB to accommodate these changes as well.
+
+4.  Definitions
+
+   DNS-RESOLVER-MIB DEFINITIONS ::= BEGIN
+
+   IMPORTS
+       MODULE-IDENTITY, OBJECT-TYPE, IpAddress, Counter32, Integer32
+           FROM SNMPv2-SMI
+       TEXTUAL-CONVENTION, RowStatus, DisplayString
+           FROM SNMPv2-TC
+       MODULE-COMPLIANCE, OBJECT-GROUP
+           FROM SNMPv2-CONF
+       dns, DnsName, DnsNameAsIndex, DnsClass, DnsType, DnsQClass,
+       DnsQType, DnsTime, DnsOpCode, DnsRespCode
+           FROM DNS-SERVER-MIB;
+
+   -- DNS Resolver MIB
+
+   dnsResMIB MODULE-IDENTITY
+       LAST-UPDATED "9401282250Z"
+       ORGANIZATION "IETF DNS Working Group"
+       CONTACT-INFO
+               "       Rob Austein
+               Postal: Epilogue Technology Corporation
+                       268 Main Street, Suite 283
+                       North Reading, MA 10864
+                       US
+                  Tel: +1 617 245 0804
+                  Fax: +1 617 245 8122
+               E-Mail: sra@epilogue.com
+
+                       Jon Saperia
+               Postal: Digital Equipment Corporation
+                       110 Spit Brook Road
+                       ZKO1-3/H18
+                       Nashua, NH 03062-2698
+                       US
+                  Tel: +1 603 881 0480
+                  Fax: +1 603 881 0120
+               E-mail: saperia@zko.dec.com"
+       DESCRIPTION
+               "The MIB module for entities implementing the client
+               (resolver) side of the Domain Name System (DNS)
+               protocol."
+
+
+
+Austein & Saperia                                               [Page 5]
+
+RFC 1612                    DNS Resolver MIB                    May 1994
+
+
+       ::= { dns 2 }
+
+   dnsResMIBObjects        OBJECT IDENTIFIER ::= { dnsResMIB 1 }
+
+   -- (Old-style) groups in the DNS resolver MIB.
+
+   dnsResConfig            OBJECT IDENTIFIER ::= { dnsResMIBObjects 1 }
+   dnsResCounter           OBJECT IDENTIFIER ::= { dnsResMIBObjects 2 }
+   dnsResLameDelegation    OBJECT IDENTIFIER ::= { dnsResMIBObjects 3 }
+   dnsResCache             OBJECT IDENTIFIER ::= { dnsResMIBObjects 4 }
+   dnsResNCache            OBJECT IDENTIFIER ::= { dnsResMIBObjects 5 }
+   dnsResOptCounter        OBJECT IDENTIFIER ::= { dnsResMIBObjects 6 }
+
+
+   -- Resolver Configuration Group
+
+   dnsResConfigImplementIdent OBJECT-TYPE
+       SYNTAX      DisplayString
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "The implementation identification string for the
+               resolver software in use on the system, for example;
+               `RES-2.1'"
+       ::= { dnsResConfig 1 }
+
+   dnsResConfigService OBJECT-TYPE
+       SYNTAX      INTEGER { recursiveOnly(1),
+                             iterativeOnly(2),
+                             recursiveAndIterative(3) }
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "Kind of DNS resolution service provided:
+
+               recursiveOnly(1) indicates a stub resolver.
+
+               iterativeOnly(2) indicates a normal full service
+               resolver.
+
+               recursiveAndIterative(3) indicates a full-service
+               resolver which performs a mix of recursive and iterative
+               queries."
+        ::= { dnsResConfig 2 }
+
+   dnsResConfigMaxCnames OBJECT-TYPE
+       SYNTAX      INTEGER (0..2147483647)
+       MAX-ACCESS  read-write
+
+
+
+Austein & Saperia                                               [Page 6]
+
+RFC 1612                    DNS Resolver MIB                    May 1994
+
+
+       STATUS      current
+       DESCRIPTION
+               "Limit on how many CNAMEs the resolver should allow
+               before deciding that there's a CNAME loop.  Zero means
+               that resolver has no explicit CNAME limit."
+       REFERENCE
+               "RFC-1035 section 7.1."
+       ::= { dnsResConfig 3 }
+
+   -- DNS Resolver Safety Belt Table
+
+   dnsResConfigSbeltTable OBJECT-TYPE
+       SYNTAX      SEQUENCE OF DnsResConfigSbeltEntry
+       MAX-ACCESS  not-accessible
+       STATUS      current
+       DESCRIPTION
+               "Table of safety belt information used by the resolver
+               when it hasn't got any better idea of where to send a
+               query, such as when the resolver is booting or is a stub
+               resolver."
+       ::= { dnsResConfig 4 }
+
+   dnsResConfigSbeltEntry OBJECT-TYPE
+       SYNTAX      DnsResConfigSbeltEntry
+       MAX-ACCESS  not-accessible
+       STATUS      current
+       DESCRIPTION
+               "An entry in the resolver's Sbelt table.
+               Rows may be created or deleted at any time by the DNS
+               resolver and by SNMP SET requests.  Whether the values
+               changed via SNMP are saved in stable storage across
+               `reset' operations is implementation-specific."
+       INDEX     { dnsResConfigSbeltAddr,
+                   dnsResConfigSbeltSubTree,
+                   dnsResConfigSbeltClass }
+       ::= { dnsResConfigSbeltTable 1 }
+
+   DnsResConfigSbeltEntry ::=
+       SEQUENCE {
+           dnsResConfigSbeltAddr
+               IpAddress,
+           dnsResConfigSbeltName
+               DnsName,
+           dnsResConfigSbeltRecursion
+               INTEGER,
+           dnsResConfigSbeltPref
+               INTEGER,
+           dnsResConfigSbeltSubTree
+
+
+
+Austein & Saperia                                               [Page 7]
+
+RFC 1612                    DNS Resolver MIB                    May 1994
+
+
+               DnsNameAsIndex,
+           dnsResConfigSbeltClass
+               DnsClass,
+           dnsResConfigSbeltStatus
+               RowStatus
+       }
+
+   dnsResConfigSbeltAddr OBJECT-TYPE
+       SYNTAX      IpAddress
+       MAX-ACCESS  not-accessible
+       STATUS      current
+       DESCRIPTION
+               "The IP address of the Sbelt name server identified by
+               this row of the table."
+       ::= { dnsResConfigSbeltEntry 1 }
+
+   dnsResConfigSbeltName OBJECT-TYPE
+       SYNTAX      DnsName
+       MAX-ACCESS  read-create
+       STATUS      current
+       DESCRIPTION
+               "The DNS name of a Sbelt nameserver identified by this
+               row of the table.  A zero-length string indicates that
+               the name is not known by the resolver."
+       ::= { dnsResConfigSbeltEntry 2 }
+
+   dnsResConfigSbeltRecursion OBJECT-TYPE
+       SYNTAX      INTEGER { iterative(1),
+                             recursive(2),
+                             recursiveAndIterative(3) }
+       MAX-ACCESS  read-create
+       STATUS      current
+       DESCRIPTION
+               "Kind of queries resolver will be sending to the name
+               server identified in this row of the table:
+
+               iterative(1) indicates that resolver will be directing
+               iterative queries to this name server (RD bit turned
+               off).
+
+               recursive(2) indicates that resolver will be directing
+               recursive queries to this name server (RD bit turned
+               on).
+
+               recursiveAndIterative(3) indicates that the resolver
+               will be directing both recursive and iterative queries
+               to the server identified in this row of the table."
+        ::= { dnsResConfigSbeltEntry 3 }
+
+
+
+Austein & Saperia                                               [Page 8]
+
+RFC 1612                    DNS Resolver MIB                    May 1994
+
+
+   dnsResConfigSbeltPref OBJECT-TYPE
+       SYNTAX      INTEGER (0..2147483647)
+       MAX-ACCESS  read-create
+       STATUS      current
+       DESCRIPTION
+               "This value identifies the preference for the name server
+               identified in this row of the table.  The lower the
+               value, the more desirable the resolver considers this
+               server."
+        ::= { dnsResConfigSbeltEntry 4 }
+
+   dnsResConfigSbeltSubTree OBJECT-TYPE
+       SYNTAX      DnsNameAsIndex
+       MAX-ACCESS  not-accessible
+       STATUS      current
+       DESCRIPTION
+               "Queries sent to the name server identified by this row
+               of the table are limited to those for names in the name
+               subtree identified by this variable.  If no such
+               limitation applies, the value of this variable is the
+               name of the root domain (a DNS name consisting of a
+               single zero octet)."
+       ::= { dnsResConfigSbeltEntry 5 }
+
+   dnsResConfigSbeltClass OBJECT-TYPE
+       SYNTAX      DnsClass
+       MAX-ACCESS  not-accessible
+       STATUS      current
+       DESCRIPTION
+               "The class of DNS queries that will be sent to the server
+               identified by this row of the table."
+       ::= { dnsResConfigSbeltEntry 6 }
+
+   dnsResConfigSbeltStatus OBJECT-TYPE
+       SYNTAX      RowStatus
+       MAX-ACCESS  read-create
+       STATUS      current
+       DESCRIPTION
+               "Row status column for this row of the Sbelt table."
+       ::= { dnsResConfigSbeltEntry 7 }
+
+   dnsResConfigUpTime OBJECT-TYPE
+       SYNTAX      DnsTime
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "If the resolver has a persistent state (e.g., a
+               process), this value will be the time elapsed since it
+
+
+
+Austein & Saperia                                               [Page 9]
+
+RFC 1612                    DNS Resolver MIB                    May 1994
+
+
+               started.  For software without persistant state, this
+               value will be 0."
+       ::= { dnsResConfig 5 }
+
+   dnsResConfigResetTime OBJECT-TYPE
+       SYNTAX      DnsTime
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "If the resolver has a persistent state (e.g., a process)
+               and supports a `reset' operation (e.g., can be told to
+               re-read configuration files), this value will be the
+               time elapsed since the last time the resolver was
+               `reset.'  For software that does not have persistence or
+               does not support a `reset' operation, this value will be
+               zero."
+       ::= { dnsResConfig 6 }
+
+   dnsResConfigReset OBJECT-TYPE
+       SYNTAX      INTEGER { other(1),
+                             reset(2),
+                             initializing(3),
+                             running(4) }
+       MAX-ACCESS  read-write
+       STATUS      current
+       DESCRIPTION
+               "Status/action object to reinitialize any persistant
+               resolver state.  When set to reset(2), any persistant
+               resolver state (such as a process) is reinitialized as if
+               the resolver had just been started.  This value will
+               never be returned by a read operation.  When read, one of
+               the following values will be returned:
+                   other(1) - resolver in some unknown state;
+                   initializing(3) - resolver (re)initializing;
+                   running(4) - resolver currently running."
+       ::= { dnsResConfig 7 }
+
+
+   -- Resolver Counters Group
+
+   -- Resolver Counter Table
+
+   dnsResCounterByOpcodeTable OBJECT-TYPE
+       SYNTAX      SEQUENCE OF DnsResCounterByOpcodeEntry
+       MAX-ACCESS  not-accessible
+       STATUS      current
+       DESCRIPTION
+               "Table of the current count of resolver queries and
+
+
+
+Austein & Saperia                                              [Page 10]
+
+RFC 1612                    DNS Resolver MIB                    May 1994
+
+
+               answers."
+       ::= { dnsResCounter 3 }
+
+   dnsResCounterByOpcodeEntry OBJECT-TYPE
+       SYNTAX      DnsResCounterByOpcodeEntry
+       MAX-ACCESS  not-accessible
+       STATUS      current
+       DESCRIPTION
+               "Entry in the resolver counter table.  Entries are
+               indexed by DNS OpCode."
+       INDEX     { dnsResCounterByOpcodeCode }
+       ::= { dnsResCounterByOpcodeTable 1 }
+
+   DnsResCounterByOpcodeEntry ::=
+       SEQUENCE {
+           dnsResCounterByOpcodeCode
+               DnsOpCode,
+           dnsResCounterByOpcodeQueries
+               Counter32,
+           dnsResCounterByOpcodeResponses
+               Counter32
+       }
+
+   dnsResCounterByOpcodeCode OBJECT-TYPE
+       SYNTAX      DnsOpCode
+       MAX-ACCESS  not-accessible
+       STATUS      current
+       DESCRIPTION
+               "The index to this table.  The OpCodes that have already
+               been defined are found in RFC-1035."
+       REFERENCE
+               "RFC-1035 section 4.1.1."
+       ::= { dnsResCounterByOpcodeEntry 1 }
+
+   dnsResCounterByOpcodeQueries OBJECT-TYPE
+       SYNTAX      Counter32
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "Total number of queries that have sent out by the
+               resolver since initialization for the OpCode which is
+               the index to this row of the table."
+       ::= { dnsResCounterByOpcodeEntry 2 }
+
+   dnsResCounterByOpcodeResponses OBJECT-TYPE
+       SYNTAX      Counter32
+       MAX-ACCESS  read-only
+       STATUS      current
+
+
+
+Austein & Saperia                                              [Page 11]
+
+RFC 1612                    DNS Resolver MIB                    May 1994
+
+
+       DESCRIPTION
+               "Total number of responses that have been received by the
+               resolver since initialization for the OpCode which is
+               the index to this row of the table."
+       ::= { dnsResCounterByOpcodeEntry 3 }
+
+   -- Resolver Response Code Counter Table
+
+   dnsResCounterByRcodeTable OBJECT-TYPE
+       SYNTAX      SEQUENCE OF DnsResCounterByRcodeEntry
+       MAX-ACCESS  not-accessible
+       STATUS      current
+       DESCRIPTION
+               "Table of the current count of responses to resolver
+               queries."
+       ::= { dnsResCounter 4 }
+
+   dnsResCounterByRcodeEntry OBJECT-TYPE
+       SYNTAX      DnsResCounterByRcodeEntry
+       MAX-ACCESS  not-accessible
+       STATUS      current
+       DESCRIPTION
+               "Entry in the resolver response table.  Entries are
+               indexed by DNS response code."
+       INDEX     { dnsResCounterByRcodeCode }
+       ::= { dnsResCounterByRcodeTable 1 }
+
+   DnsResCounterByRcodeEntry ::=
+       SEQUENCE {
+           dnsResCounterByRcodeCode
+               DnsRespCode,
+           dnsResCounterByRcodeResponses
+               Counter32
+       }
+
+   dnsResCounterByRcodeCode OBJECT-TYPE
+       SYNTAX      DnsRespCode
+       MAX-ACCESS  not-accessible
+       STATUS      current
+       DESCRIPTION
+               "The index to this table.  The Response Codes that have
+               already been defined are found in RFC-1035."
+       REFERENCE
+               "RFC-1035 section 4.1.1."
+       ::= { dnsResCounterByRcodeEntry 1 }
+
+
+
+
+
+
+Austein & Saperia                                              [Page 12]
+
+RFC 1612                    DNS Resolver MIB                    May 1994
+
+
+   dnsResCounterByRcodeResponses OBJECT-TYPE
+       SYNTAX      Counter32
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "Number of responses the resolver has received for the
+               response code value which identifies this row of the
+               table."
+       ::= { dnsResCounterByRcodeEntry 2 }
+
+   -- Additional DNS Resolver Counter Objects
+
+   dnsResCounterNonAuthDataResps OBJECT-TYPE
+       SYNTAX      Counter32
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "Number of requests made by the resolver for which a
+               non-authoritative answer (cached data) was received."
+       ::= { dnsResCounter 5 }
+
+   dnsResCounterNonAuthNoDataResps OBJECT-TYPE
+       SYNTAX      Counter32
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "Number of requests made by the resolver for which a
+               non-authoritative answer - no such data response (empty
+               answer) was received."
+       ::= { dnsResCounter 6 }
+
+   dnsResCounterMartians OBJECT-TYPE
+       SYNTAX      Counter32
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "Number of responses received which were received from
+               servers that the resolver does not think it asked."
+       ::= { dnsResCounter 7 }
+
+   dnsResCounterRecdResponses OBJECT-TYPE
+       SYNTAX      Counter32
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "Number of responses received to all queries."
+       ::= { dnsResCounter 8 }
+
+
+
+
+Austein & Saperia                                              [Page 13]
+
+RFC 1612                    DNS Resolver MIB                    May 1994
+
+
+   dnsResCounterUnparseResps OBJECT-TYPE
+       SYNTAX      Counter32
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "Number of responses received which were unparseable."
+       ::= { dnsResCounter 9 }
+
+   dnsResCounterFallbacks OBJECT-TYPE
+       SYNTAX      Counter32
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "Number of times the resolver had to fall back to its
+               seat belt information."
+       ::= { dnsResCounter 10 }
+
+
+   -- Lame Delegation Group
+
+   dnsResLameDelegationOverflows OBJECT-TYPE
+       SYNTAX      Counter32
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "Number of times the resolver attempted to add an entry
+               to the Lame Delegation table but was unable to for some
+               reason such as space constraints."
+       ::= { dnsResLameDelegation 1 }
+
+   -- Lame Delegation Table
+
+   dnsResLameDelegationTable OBJECT-TYPE
+       SYNTAX      SEQUENCE OF DnsResLameDelegationEntry
+       MAX-ACCESS  not-accessible
+       STATUS      current
+       DESCRIPTION
+               "Table of name servers returning lame delegations.
+
+               A lame delegation has occured when a parent zone
+               delegates authority for a child zone to a server that
+               appears not to think that it is authoritative for the
+               child zone in question."
+       ::= { dnsResLameDelegation 2 }
+
+   dnsResLameDelegationEntry OBJECT-TYPE
+       SYNTAX      DnsResLameDelegationEntry
+       MAX-ACCESS  not-accessible
+
+
+
+Austein & Saperia                                              [Page 14]
+
+RFC 1612                    DNS Resolver MIB                    May 1994
+
+
+       STATUS      current
+       DESCRIPTION
+               "Entry in lame delegation table.  Only the resolver may
+               create rows in this table.  SNMP SET requests may be used
+               to delete rows."
+       INDEX     { dnsResLameDelegationSource,
+                   dnsResLameDelegationName,
+                   dnsResLameDelegationClass }
+       ::= { dnsResLameDelegationTable 1 }
+
+   DnsResLameDelegationEntry ::=
+       SEQUENCE {
+           dnsResLameDelegationSource
+               IpAddress,
+           dnsResLameDelegationName
+               DnsNameAsIndex,
+           dnsResLameDelegationClass
+               DnsClass,
+           dnsResLameDelegationCounts
+               Counter32,
+           dnsResLameDelegationStatus
+               RowStatus
+       }
+
+   dnsResLameDelegationSource OBJECT-TYPE
+       SYNTAX      IpAddress
+       MAX-ACCESS  not-accessible
+       STATUS      current
+       DESCRIPTION
+               "Source of lame delegation."
+       ::= { dnsResLameDelegationEntry 1 }
+
+   dnsResLameDelegationName OBJECT-TYPE
+       SYNTAX      DnsNameAsIndex
+       MAX-ACCESS  not-accessible
+       STATUS      current
+       DESCRIPTION
+               "DNS name for which lame delegation was received."
+       ::= { dnsResLameDelegationEntry 2 }
+
+   dnsResLameDelegationClass OBJECT-TYPE
+       SYNTAX      DnsClass
+       MAX-ACCESS  not-accessible
+       STATUS      current
+       DESCRIPTION
+               "DNS class of received lame delegation."
+       ::= { dnsResLameDelegationEntry 3 }
+
+
+
+
+Austein & Saperia                                              [Page 15]
+
+RFC 1612                    DNS Resolver MIB                    May 1994
+
+
+   dnsResLameDelegationCounts OBJECT-TYPE
+       SYNTAX      Counter32
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "How many times this lame delegation has been received."
+       ::= { dnsResLameDelegationEntry 4 }
+
+   dnsResLameDelegationStatus OBJECT-TYPE
+       SYNTAX      RowStatus
+       MAX-ACCESS  read-write
+       STATUS      current
+       DESCRIPTION
+               "Status column for the lame delegation table.  Since only
+               the agent (DNS resolver) creates rows in this table, the
+               only values that a manager may write to this variable
+               are active(1) and destroy(6)."
+       ::= { dnsResLameDelegationEntry 5 }
+
+
+   -- Resolver Cache Group
+
+   dnsResCacheStatus OBJECT-TYPE
+       SYNTAX      INTEGER { enabled(1), disabled(2), clear(3) }
+       MAX-ACCESS  read-write
+       STATUS      current
+       DESCRIPTION
+               "Status/action for the resolver's cache.
+
+               enabled(1) means that the use of the cache is allowed.
+               Query operations can return this state.
+
+               disabled(2) means that the cache is not being used.
+               Query operations can return this state.
+
+               Setting this variable to clear(3) deletes the entire
+               contents of the resolver's cache, but does not otherwise
+               change the resolver's state.  The status will retain its
+               previous value from before the clear operation (i.e.,
+               enabled(1) or disabled(2)).  The value of clear(3) can
+               NOT be returned by a query operation."
+       ::= { dnsResCache 1 }
+
+   dnsResCacheMaxTTL OBJECT-TYPE
+       SYNTAX      DnsTime
+       MAX-ACCESS  read-write
+       STATUS      current
+       DESCRIPTION
+
+
+
+Austein & Saperia                                              [Page 16]
+
+RFC 1612                    DNS Resolver MIB                    May 1994
+
+
+               "Maximum Time-To-Live for RRs in this cache.  If the
+               resolver does not implement a TTL ceiling, the value of
+               this field should be zero."
+       ::= { dnsResCache 2 }
+
+   dnsResCacheGoodCaches OBJECT-TYPE
+       SYNTAX      Counter32
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "Number of RRs the resolver has cached successfully."
+       ::= { dnsResCache 3 }
+
+   dnsResCacheBadCaches OBJECT-TYPE
+       SYNTAX      Counter32
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "Number of RRs the resolver has refused to cache because
+               they appear to be dangerous or irrelevant.  E.g., RRs
+               with suspiciously high TTLs, unsolicited root
+               information, or that just don't appear to be relevant to
+               the question the resolver asked."
+       ::= { dnsResCache 4 }
+
+   -- Resolver Cache Table
+
+   dnsResCacheRRTable OBJECT-TYPE
+       SYNTAX      SEQUENCE OF DnsResCacheRREntry
+       MAX-ACCESS  not-accessible
+       STATUS      current
+       DESCRIPTION
+               "This table contains information about all the resource
+               records currently in the resolver's cache."
+       ::= { dnsResCache 5 }
+
+   dnsResCacheRREntry OBJECT-TYPE
+       SYNTAX      DnsResCacheRREntry
+       MAX-ACCESS  not-accessible
+       STATUS      current
+       DESCRIPTION
+               "An entry in the resolvers's cache.  Rows may be created
+               only by the resolver.  SNMP SET requests may be used to
+               delete rows."
+       INDEX     { dnsResCacheRRName,
+                   dnsResCacheRRClass,
+                   dnsResCacheRRType,
+                   dnsResCacheRRIndex }
+
+
+
+Austein & Saperia                                              [Page 17]
+
+RFC 1612                    DNS Resolver MIB                    May 1994
+
+
+       ::= { dnsResCacheRRTable 1 }
+
+   DnsResCacheRREntry ::=
+       SEQUENCE {
+           dnsResCacheRRName
+               DnsNameAsIndex,
+           dnsResCacheRRClass
+               DnsClass,
+           dnsResCacheRRType
+               DnsType,
+           dnsResCacheRRTTL
+               DnsTime,
+           dnsResCacheRRElapsedTTL
+               DnsTime,
+           dnsResCacheRRSource
+               IpAddress,
+           dnsResCacheRRData
+               OCTET STRING,
+           dnsResCacheRRStatus
+               RowStatus,
+           dnsResCacheRRIndex
+               Integer32,
+           dnsResCacheRRPrettyName
+               DnsName
+       }
+
+   dnsResCacheRRName OBJECT-TYPE
+       SYNTAX      DnsNameAsIndex
+       MAX-ACCESS  not-accessible
+       STATUS      current
+       DESCRIPTION
+               "Owner name of the Resource Record in the cache which is
+               identified in this row of the table.  As described in
+               RFC-1034, the owner of the record is the domain name
+               were the RR is found."
+       REFERENCE
+               "RFC-1034 section 3.6."
+       ::= { dnsResCacheRREntry 1 }
+
+   dnsResCacheRRClass OBJECT-TYPE
+       SYNTAX      DnsClass
+       MAX-ACCESS  not-accessible
+       STATUS      current
+       DESCRIPTION
+               "DNS class of the Resource Record in the cache which is
+               identified in this row of the table."
+       ::= { dnsResCacheRREntry 2 }
+
+
+
+
+Austein & Saperia                                              [Page 18]
+
+RFC 1612                    DNS Resolver MIB                    May 1994
+
+
+   dnsResCacheRRType OBJECT-TYPE
+       SYNTAX      DnsType
+       MAX-ACCESS  not-accessible
+       STATUS      current
+       DESCRIPTION
+               "DNS type of the Resource Record in the cache which is
+               identified in this row of the table."
+       ::= { dnsResCacheRREntry 3 }
+
+   dnsResCacheRRTTL OBJECT-TYPE
+       SYNTAX      DnsTime
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "Time-To-Live of RR in DNS cache.  This is the initial
+               TTL value which was received with the RR when it was
+               originally received."
+       ::= { dnsResCacheRREntry 4 }
+
+   dnsResCacheRRElapsedTTL OBJECT-TYPE
+       SYNTAX      DnsTime
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "Elapsed seconds since RR was received."
+       ::= { dnsResCacheRREntry 5 }
+
+   dnsResCacheRRSource OBJECT-TYPE
+       SYNTAX      IpAddress
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "Host from which RR was received, 0.0.0.0 if unknown."
+       ::= { dnsResCacheRREntry 6 }
+
+   dnsResCacheRRData OBJECT-TYPE
+       SYNTAX      OCTET STRING
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "RDATA portion of a cached RR.  The value is in the
+               format defined for the particular DNS class and type of
+               the resource record."
+       REFERENCE
+               "RFC-1035 section 3.2.1."
+       ::= { dnsResCacheRREntry 7 }
+
+
+
+
+
+Austein & Saperia                                              [Page 19]
+
+RFC 1612                    DNS Resolver MIB                    May 1994
+
+
+   dnsResCacheRRStatus OBJECT-TYPE
+       SYNTAX      RowStatus
+       MAX-ACCESS  read-write
+       STATUS      current
+       DESCRIPTION
+               "Status column for the resolver cache table.  Since only
+               the agent (DNS resolver) creates rows in this table, the
+               only values that a manager may write to this variable
+               are active(1) and destroy(6)."
+       ::= { dnsResCacheRREntry 8 }
+
+   dnsResCacheRRIndex OBJECT-TYPE
+       SYNTAX      Integer32
+       MAX-ACCESS  not-accessible
+       STATUS      current
+       DESCRIPTION
+               "A value which makes entries in the table unique when the
+               other index values (dnsResCacheRRName,
+               dnsResCacheRRClass, and dnsResCacheRRType) do not
+               provide a unique index."
+       ::= { dnsResCacheRREntry 9 }
+
+   dnsResCacheRRPrettyName OBJECT-TYPE
+       SYNTAX      DnsName
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "Name of the RR at this row in the table.  This is
+               identical to the dnsResCacheRRName variable, except that
+               character case is preserved in this variable, per DNS
+               conventions."
+       REFERENCE
+               "RFC-1035 section 2.3.3."
+       ::= { dnsResCacheRREntry 10 }
+
+   -- Resolver Negative Cache Group
+
+   dnsResNCacheStatus OBJECT-TYPE
+       SYNTAX      INTEGER { enabled(1), disabled(2), clear(3) }
+       MAX-ACCESS  read-write
+       STATUS      current
+       DESCRIPTION
+               "Status/action for the resolver's negative response
+               cache.
+
+               enabled(1) means that the use of the negative response
+               cache is allowed.  Query operations can return this
+               state.
+
+
+
+Austein & Saperia                                              [Page 20]
+
+RFC 1612                    DNS Resolver MIB                    May 1994
+
+
+               disabled(2) means that the negative response cache is
+               not being used.  Query operations can return this state.
+
+               Setting this variable to clear(3) deletes the entire
+               contents of the resolver's negative response cache.  The
+               status will retain its previous value from before the
+               clear operation (i.e., enabled(1) or disabled(2)).  The
+               value of clear(3) can NOT be returned by a query
+               operation."
+       ::= { dnsResNCache 1 }
+
+   dnsResNCacheMaxTTL OBJECT-TYPE
+       SYNTAX      DnsTime
+       MAX-ACCESS  read-write
+       STATUS      current
+       DESCRIPTION
+               "Maximum Time-To-Live for cached authoritative errors.
+               If the resolver does not implement a TTL ceiling, the
+               value of this field should be zero."
+       ::= { dnsResNCache 2 }
+
+   dnsResNCacheGoodNCaches OBJECT-TYPE
+       SYNTAX      Counter32
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "Number of authoritative errors the resolver has cached
+               successfully."
+       ::= { dnsResNCache 3 }
+
+   dnsResNCacheBadNCaches OBJECT-TYPE
+       SYNTAX      Counter32
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "Number of authoritative errors the resolver would have
+               liked to cache but was unable to because the appropriate
+               SOA RR was not supplied or looked suspicious."
+       REFERENCE
+               "RFC-1034 section 4.3.4."
+       ::= { dnsResNCache 4 }
+
+   -- Resolver Negative Cache Table
+
+   dnsResNCacheErrTable OBJECT-TYPE
+       SYNTAX      SEQUENCE OF DnsResNCacheErrEntry
+       MAX-ACCESS  not-accessible
+       STATUS      current
+
+
+
+Austein & Saperia                                              [Page 21]
+
+RFC 1612                    DNS Resolver MIB                    May 1994
+
+
+       DESCRIPTION
+               "The resolver's negative response cache.  This table
+               contains information about authoritative errors that
+               have been cached by the resolver."
+       ::= { dnsResNCache 5 }
+
+   dnsResNCacheErrEntry OBJECT-TYPE
+       SYNTAX      DnsResNCacheErrEntry
+       MAX-ACCESS  not-accessible
+       STATUS      current
+       DESCRIPTION
+               "An entry in the resolver's negative response cache
+               table.  Only the resolver can create rows.  SNMP SET
+               requests may be used to delete rows."
+       INDEX     { dnsResNCacheErrQName,
+                   dnsResNCacheErrQClass,
+                   dnsResNCacheErrQType,
+                   dnsResNCacheErrIndex }
+       ::= { dnsResNCacheErrTable 1 }
+
+   DnsResNCacheErrEntry ::=
+       SEQUENCE {
+           dnsResNCacheErrQName
+               DnsNameAsIndex,
+           dnsResNCacheErrQClass
+               DnsQClass,
+           dnsResNCacheErrQType
+               DnsQType,
+           dnsResNCacheErrTTL
+               DnsTime,
+           dnsResNCacheErrElapsedTTL
+               DnsTime,
+           dnsResNCacheErrSource
+               IpAddress,
+           dnsResNCacheErrCode
+               INTEGER,
+           dnsResNCacheErrStatus
+               RowStatus,
+           dnsResNCacheErrIndex
+               Integer32,
+           dnsResNCacheErrPrettyName
+               DnsName
+       }
+
+   dnsResNCacheErrQName OBJECT-TYPE
+       SYNTAX      DnsNameAsIndex
+       MAX-ACCESS  not-accessible
+       STATUS      current
+
+
+
+Austein & Saperia                                              [Page 22]
+
+RFC 1612                    DNS Resolver MIB                    May 1994
+
+
+       DESCRIPTION
+               "QNAME associated with a cached authoritative error."
+       REFERENCE
+               "RFC-1034 section 3.7.1."
+       ::= { dnsResNCacheErrEntry 1 }
+
+   dnsResNCacheErrQClass OBJECT-TYPE
+       SYNTAX      DnsQClass
+       MAX-ACCESS  not-accessible
+       STATUS      current
+       DESCRIPTION
+               "DNS QCLASS associated with a cached authoritative
+               error."
+       ::= { dnsResNCacheErrEntry 2 }
+
+   dnsResNCacheErrQType OBJECT-TYPE
+       SYNTAX      DnsQType
+       MAX-ACCESS  not-accessible
+       STATUS      current
+       DESCRIPTION
+               "DNS QTYPE associated with a cached authoritative error."
+       ::= { dnsResNCacheErrEntry 3 }
+
+   dnsResNCacheErrTTL OBJECT-TYPE
+       SYNTAX      DnsTime
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "Time-To-Live of a cached authoritative error at the time
+               of the error, it should not be decremented by the number
+               of seconds since it was received.  This should be the
+               TTL as copied from the MINIMUM field of the SOA that
+               accompanied the authoritative error, or a smaller value
+               if the resolver implements a ceiling on negative
+               response cache TTLs."
+       REFERENCE
+               "RFC-1034 section 4.3.4."
+       ::= { dnsResNCacheErrEntry 4 }
+
+   dnsResNCacheErrElapsedTTL OBJECT-TYPE
+       SYNTAX      DnsTime
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "Elapsed seconds since authoritative error was received."
+       ::= { dnsResNCacheErrEntry 5 }
+
+
+
+
+
+Austein & Saperia                                              [Page 23]
+
+RFC 1612                    DNS Resolver MIB                    May 1994
+
+
+   dnsResNCacheErrSource OBJECT-TYPE
+       SYNTAX      IpAddress
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "Host which sent the authoritative error, 0.0.0.0 if
+               unknown."
+       ::= { dnsResNCacheErrEntry 6 }
+
+   dnsResNCacheErrCode OBJECT-TYPE
+       SYNTAX      INTEGER { nonexistantName(1), noData(2), other(3) }
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "The authoritative error that has been cached:
+
+               nonexistantName(1) indicates an authoritative name error
+               (RCODE = 3).
+
+               noData(2) indicates an authoritative response with no
+               error (RCODE = 0) and no relevant data.
+
+               other(3) indicates some other cached authoritative
+               error.  At present, no such errors are known to exist."
+       ::= { dnsResNCacheErrEntry 7 }
+
+   dnsResNCacheErrStatus OBJECT-TYPE
+       SYNTAX      RowStatus
+       MAX-ACCESS  read-write
+       STATUS      current
+       DESCRIPTION
+               "Status column for the resolver negative response cache
+               table.  Since only the agent (DNS resolver) creates rows
+               in this table, the only values that a manager may write
+               to this variable are active(1) and destroy(6)."
+       ::= { dnsResNCacheErrEntry 8 }
+
+   dnsResNCacheErrIndex OBJECT-TYPE
+       SYNTAX      Integer32
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "A value which makes entries in the table unique when the
+               other index values (dnsResNCacheErrQName,
+               dnsResNCacheErrQClass, and dnsResNCacheErrQType) do not
+               provide a unique index."
+       ::= { dnsResNCacheErrEntry 9 }
+
+
+
+
+Austein & Saperia                                              [Page 24]
+
+RFC 1612                    DNS Resolver MIB                    May 1994
+
+
+   dnsResNCacheErrPrettyName OBJECT-TYPE
+       SYNTAX      DnsName
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "QNAME associated with this row in the table.  This is
+               identical to the dnsResNCacheErrQName variable, except
+               that character case is preserved in this variable, per
+               DNS conventions."
+       REFERENCE
+               "RFC-1035 section 2.3.3."
+       ::= { dnsResNCacheErrEntry 10 }
+
+
+   -- Resolver Optional Counters Group
+
+   dnsResOptCounterReferals OBJECT-TYPE
+       SYNTAX      Counter32
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "Number of responses which were received from servers
+               redirecting query to another server."
+       ::= { dnsResOptCounter 1 }
+
+   dnsResOptCounterRetrans OBJECT-TYPE
+       SYNTAX      Counter32
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "Number requests retransmitted for all reasons."
+       ::= { dnsResOptCounter 2 }
+
+   dnsResOptCounterNoResponses OBJECT-TYPE
+       SYNTAX      Counter32
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "Number of queries that were retransmitted because of no
+               response."
+       ::= { dnsResOptCounter 3 }
+
+   dnsResOptCounterRootRetrans OBJECT-TYPE
+       SYNTAX      Counter32
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "Number of queries that were retransmitted that were to
+
+
+
+Austein & Saperia                                              [Page 25]
+
+RFC 1612                    DNS Resolver MIB                    May 1994
+
+
+               root servers."
+       ::= { dnsResOptCounter 4 }
+
+   dnsResOptCounterInternals OBJECT-TYPE
+       SYNTAX      Counter32
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "Number of requests internally generated by the
+               resolver."
+       ::= { dnsResOptCounter 5 }
+
+   dnsResOptCounterInternalTimeOuts OBJECT-TYPE
+       SYNTAX      Counter32
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "Number of requests internally generated which timed
+               out."
+       ::= { dnsResOptCounter 6 }
+
+
+   -- SNMPv2 groups.
+
+   dnsResMIBGroups         OBJECT IDENTIFIER ::= { dnsResMIB 2 }
+
+   dnsResConfigGroup OBJECT-GROUP
+       OBJECTS   { dnsResConfigImplementIdent,
+                   dnsResConfigService,
+                   dnsResConfigMaxCnames,
+                   dnsResConfigSbeltAddr,
+                   dnsResConfigSbeltName,
+                   dnsResConfigSbeltRecursion,
+                   dnsResConfigSbeltPref,
+                   dnsResConfigSbeltSubTree,
+                   dnsResConfigSbeltClass,
+                   dnsResConfigSbeltStatus,
+                   dnsResConfigUpTime,
+                   dnsResConfigResetTime }
+       STATUS      current
+       DESCRIPTION
+               "A collection of objects providing basic configuration
+               information for a DNS resolver implementation."
+       ::= { dnsResMIBGroups 1 }
+
+   dnsResCounterGroup OBJECT-GROUP
+       OBJECTS   { dnsResCounterByOpcodeCode,
+                   dnsResCounterByOpcodeQueries,
+
+
+
+Austein & Saperia                                              [Page 26]
+
+RFC 1612                    DNS Resolver MIB                    May 1994
+
+
+                   dnsResCounterByOpcodeResponses,
+                   dnsResCounterByRcodeCode,
+                   dnsResCounterByRcodeResponses,
+                   dnsResCounterNonAuthDataResps,
+                   dnsResCounterNonAuthNoDataResps,
+                   dnsResCounterMartians,
+                   dnsResCounterRecdResponses,
+                   dnsResCounterUnparseResps,
+                   dnsResCounterFallbacks }
+       STATUS      current
+       DESCRIPTION
+               "A collection of objects providing basic instrumentation
+               of a DNS resolver implementation."
+       ::= { dnsResMIBGroups 2 }
+
+   dnsResLameDelegationGroup OBJECT-GROUP
+       OBJECTS   { dnsResLameDelegationOverflows,
+                   dnsResLameDelegationSource,
+                   dnsResLameDelegationName,
+                   dnsResLameDelegationClass,
+                   dnsResLameDelegationCounts,
+                   dnsResLameDelegationStatus }
+       STATUS      current
+       DESCRIPTION
+               "A collection of objects providing instrumentation of
+               `lame delegation' failures."
+       ::= { dnsResMIBGroups 3 }
+
+
+   dnsResCacheGroup OBJECT-GROUP
+       OBJECTS   { dnsResCacheStatus,
+                   dnsResCacheMaxTTL,
+                   dnsResCacheGoodCaches,
+                   dnsResCacheBadCaches,
+                   dnsResCacheRRName,
+                   dnsResCacheRRClass,
+                   dnsResCacheRRType,
+                   dnsResCacheRRTTL,
+                   dnsResCacheRRElapsedTTL,
+                   dnsResCacheRRSource,
+                   dnsResCacheRRData,
+                   dnsResCacheRRStatus,
+                   dnsResCacheRRIndex,
+                   dnsResCacheRRPrettyName }
+       STATUS      current
+       DESCRIPTION
+               "A collection of objects providing access to and control
+               of a DNS resolver's cache."
+
+
+
+Austein & Saperia                                              [Page 27]
+
+RFC 1612                    DNS Resolver MIB                    May 1994
+
+
+       ::= { dnsResMIBGroups 4 }
+
+   dnsResNCacheGroup OBJECT-GROUP
+       OBJECTS   { dnsResNCacheStatus,
+                   dnsResNCacheMaxTTL,
+                   dnsResNCacheGoodNCaches,
+                   dnsResNCacheBadNCaches,
+                   dnsResNCacheErrQName,
+                   dnsResNCacheErrQClass,
+                   dnsResNCacheErrQType,
+                   dnsResNCacheErrTTL,
+                   dnsResNCacheErrElapsedTTL,
+                   dnsResNCacheErrSource,
+                   dnsResNCacheErrCode,
+                   dnsResNCacheErrStatus,
+                   dnsResNCacheErrIndex,
+                   dnsResNCacheErrPrettyName }
+       STATUS      current
+       DESCRIPTION
+               "A collection of objects providing access to and control
+               of a DNS resolver's negative response cache."
+       ::= { dnsResMIBGroups 5 }
+
+   dnsResOptCounterGroup OBJECT-GROUP
+       OBJECTS   { dnsResOptCounterReferals,
+                   dnsResOptCounterRetrans,
+                   dnsResOptCounterNoResponses,
+                   dnsResOptCounterRootRetrans,
+                   dnsResOptCounterInternals,
+                   dnsResOptCounterInternalTimeOuts }
+       STATUS      current
+       DESCRIPTION
+               "A collection of objects providing further
+               instrumentation applicable to many but not all DNS
+               resolvers."
+       ::= { dnsResMIBGroups 6 }
+
+
+   -- Compliances.
+
+   dnsResMIBCompliances OBJECT IDENTIFIER ::= { dnsResMIB 3 }
+
+   dnsResMIBCompliance MODULE-COMPLIANCE
+       STATUS      current
+       DESCRIPTION
+               "The compliance statement for agents implementing the DNS
+               resolver MIB extensions."
+       MODULE -- This MIB module
+
+
+
+Austein & Saperia                                              [Page 28]
+
+RFC 1612                    DNS Resolver MIB                    May 1994
+
+
+           MANDATORY-GROUPS { dnsResConfigGroup, dnsResCounterGroup }
+           GROUP   dnsResCacheGroup
+           DESCRIPTION
+               "The resolver cache group is mandatory for resolvers that
+               implement a cache."
+           GROUP   dnsResNCacheGroup
+           DESCRIPTION
+               "The resolver negative cache group is mandatory for
+               resolvers that implement a negative response cache."
+           GROUP   dnsResLameDelegationGroup
+           DESCRIPTION
+               "The lame delegation group is unconditionally optional."
+           GROUP   dnsResOptCounterGroup
+           DESCRIPTION
+               "The optional counters group is unconditionally
+               optional."
+           OBJECT  dnsResConfigMaxCnames
+           MIN-ACCESS      read-only
+           DESCRIPTION
+               "This object need not be writable."
+           OBJECT  dnsResConfigSbeltName
+           MIN-ACCESS      read-only
+           DESCRIPTION
+               "This object need not be writable."
+           OBJECT  dnsResConfigSbeltRecursion
+           MIN-ACCESS      read-only
+           DESCRIPTION
+               "This object need not be writable."
+           OBJECT  dnsResConfigSbeltPref
+           MIN-ACCESS      read-only
+           DESCRIPTION
+               "This object need not be writable."
+           OBJECT  dnsResConfigReset
+           MIN-ACCESS      read-only
+           DESCRIPTION
+               "This object need not be writable."
+           OBJECT  dnsResCacheStatus
+           MIN-ACCESS      read-only
+           DESCRIPTION
+               "This object need not be writable."
+           OBJECT  dnsResCacheMaxTTL
+           MIN-ACCESS      read-only
+           DESCRIPTION
+               "This object need not be writable."
+           OBJECT  dnsResNCacheStatus
+           MIN-ACCESS      read-only
+           DESCRIPTION
+               "This object need not be writable."
+
+
+
+Austein & Saperia                                              [Page 29]
+
+RFC 1612                    DNS Resolver MIB                    May 1994
+
+
+           OBJECT  dnsResNCacheMaxTTL
+           MIN-ACCESS      read-only
+           DESCRIPTION
+               "This object need not be writable."
+       ::= { dnsResMIBCompliances 1 }
+
+   END
+
+5.  Acknowledgements
+
+   This document is the result of work undertaken the by DNS working
+   group.  The authors would particularly like to thank the following
+   people for their contributions to this document: Philip Almquist,
+   Frank Kastenholz (FTP Software), Joe Peck (DEC), Dave Perkins
+   (SynOptics), Win Treese (DEC), and Mimi Zohar (IBM).
+
+6.  References
+
+   [1] Mockapetris, P., "Domain Names -- Concepts and Facilities", STD
+       13, RFC 1034, USC/Information Sciences Institute, November 1987.
+
+   [2] Mockapetris, P., "Domain Names -- Implementation and
+       Specification", STD 13, RFC 1035, USC/Information Sciences
+       Institute, November 1987.
+
+   [3] Braden, R., Editor, "Requirements for Internet Hosts --
+       Application and Support, STD 3, RFC 1123, USC/Information
+       Sciences Institute, October 1989.
+
+   [4] Rose, M., and K. McCloghrie, "Structure and Identification of
+       Management Information for TCP/IP-based internets", STD 16, RFC
+       1155, Performance Systems International, Hughes LAN Systems, May
+       1990.
+
+   [5] McCloghrie, K., and M. Rose, "Management Information Base for
+       Network Management of TCP/IP-based internets", RFC 1156, Hughes
+       LAN Systems, Performance Systems International, May 1990.
+
+   [6] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple
+       Network Management Protocol", STD 15, RFC 1157, SNMP Research,
+       Performance Systems International, Performance Systems
+       International, MIT Laboratory for Computer Science, May 1990.
+
+   [7] Rose, M., and K. McCloghrie, Editors, "Concise MIB Definitions",
+       STD 16, RFC 1212, Performance Systems International, Hughes LAN
+       Systems, March 1991.
+
+
+
+
+
+Austein & Saperia                                              [Page 30]
+
+RFC 1612                    DNS Resolver MIB                    May 1994
+
+
+   [8] McCloghrie, K., and M. Rose, "Management Information Base for
+       Network Management of TCP/IP-based internets: MIB-II", STD 17,
+       RFC 1213, Hughes LAN Systems, Performance Systems International,
+       March 1991.
+
+   [9] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Structure
+       of Management Information for version 2 of the Simple Network
+       Management Protocol (SNMPv2)", RFC 1442, SNMP Research, Inc.,
+       Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon
+       University, April 1993.
+
+  [10] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Textual
+       Conventions for version 2 of the the Simple Network Management
+       Protocol (SNMPv2)", RFC 1443, SNMP Research, Inc., Hughes LAN
+       Systems, Dover Beach Consulting, Inc., Carnegie Mellon
+       University, April 1993.
+
+  [11] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser,
+       "Conformance Statements for version 2 of the the Simple Network
+       Management Protocol (SNMPv2)", RFC 1444, SNMP Research, Inc.,
+       Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon
+       University, April 1993.
+
+  [12] Galvin, J., and K. McCloghrie, "Administrative Model for version
+       2 of the Simple Network Management Protocol (SNMPv2)", RFC 1445,
+       Trusted Information Systems, Hughes LAN Systems, April 1993.
+
+  [13] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol
+       Operations for version 2 of the Simple Network Management
+       Protocol (SNMPv2)", RFC 1448, SNMP Research, Inc., Hughes LAN
+       Systems, Dover Beach Consulting, Inc., Carnegie Mellon
+       University, April 1993.
+
+  [14] "Information processing systems - Open Systems Interconnection -
+       Specification of Abstract Syntax Notation One (ASN.1)",
+       International Organization for Standardization, International
+       Standard 8824, December 1987.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Austein & Saperia                                              [Page 31]
+
+RFC 1612                    DNS Resolver MIB                    May 1994
+
+
+7.  Security Considerations
+
+   Security issues are not discussed in this memo.
+
+8.  Authors' Addresses
+
+   Rob Austein
+   Epilogue Technology Corporation
+   268 Main Street, Suite 283
+   North Reading, MA 01864
+   USA
+
+   Phone: +1-617-245-0804
+   Fax:   +1-617-245-8122
+   EMail: sra@epilogue.com
+
+
+   Jon Saperia
+   Digital Equipment Corporation
+   110 Spit Brook Road
+   ZKO1-3/H18
+   Nashua, NH 03062-2698
+   USA
+
+   Phone: +1-603-881-0480
+   Fax:   +1-603-881-0120
+   EMail: saperia@zko.dec.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Austein & Saperia                                              [Page 32]
+
diff --git a/doc/rfc/rfc1706.txt b/doc/rfc/rfc1706.txt
new file mode 100644
index 0000000..5b5d821
--- /dev/null
+++ b/doc/rfc/rfc1706.txt
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+Network Working Group                                         B. Manning
+Request for Comments: 1706                                           ISI
+Obsoletes: 1637, 1348                                         R. Colella
+Category: Informational                                             NIST
+                                                            October 1994
+
+
+                       DNS NSAP Resource Records
+
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  This memo
+   does not specify an Internet standard of any kind.  Distribution of
+   this memo is unlimited.
+
+Abstract
+
+   OSI lower layer protocols, comprising the connectionless network
+   protocol (CLNP) and supporting routing protocols, are deployed in
+   some parts of the global Internet.  Maintenance and debugging of CLNP
+   connectivity is greatly aided by support in the Domain Name System
+   (DNS) for mapping between names and NSAP addresses.
+
+   This document defines the format of one new Resource Record (RR) for
+   the DNS for domain name-to-NSAP mapping. The RR may be used with any
+   NSAP address format.
+
+   NSAP-to-name translation is accomplished through use of the PTR RR
+   (see STD 13, RFC 1035 for a description of the PTR RR). This paper
+   describes how PTR RRs are used to support this translation.
+
+   This document obsoletes RFC 1348 and RFC 1637.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Manning & Colella                                               [Page 1]
+
+RFC 1706                      DNS NSAP RRs                  October 1994
+
+
+1.  Introduction
+
+   OSI lower layer protocols, comprising the connectionless network
+   protocol (CLNP) [5] and supporting routing protocols, are deployed in
+   some parts of the global Internet.  Maintenance and debugging of CLNP
+   connectivity is greatly aided by support in the Domain Name System
+   (DNS) [7] [8] for mapping between names and NSAP (network service
+   access point) addresses [6] [Note: NSAP and NSAP address are used
+   interchangeably throughout this memo].
+
+   This document defines the format of one new Resource Record (RR) for
+   the DNS for domain name-to-NSAP mapping. The RR may be used with any
+   NSAP address format.
+
+   NSAP-to-name translation is accomplished through use of the PTR RR
+   (see RFC 1035 for a description of the PTR RR). This paper describes
+   how PTR RRs are used to support this translation.
+
+   This memo assumes that the reader is familiar with the DNS. Some
+   familiarity with NSAPs is useful; see [1] or Annex A of [6] for
+   additional information.
+
+2.  Background
+
+   The reason for defining DNS mappings for NSAPs is to support the
+   existing CLNP deployment in the Internet.  Debugging with CLNP ping
+   and traceroute has become more difficult with only numeric NSAPs as
+   the scale of deployment has increased. Current debugging is supported
+   by maintaining and exchanging a configuration file with name/NSAP
+   mappings similar in function to hosts.txt. This suffers from the lack
+   of a central coordinator for this file and also from the perspective
+   of scaling.  The former describes the most serious short-term
+   problem. Scaling of a hosts.txt-like solution has well-known long-
+   term scaling difficiencies.
+
+3.  Scope
+
+   The methods defined in this paper are applicable to all NSAP formats.
+
+   As a point of reference, there is a distinction between registration
+   and publication of addresses. For IP addresses, the IANA is the root
+   registration authority and the DNS a publication method. For NSAPs,
+   Annex A of the network service definition, ISO8348 [6], describes the
+   root registration authority and this memo defines how the DNS is used
+   as a publication method.
+
+
+
+
+
+
+Manning & Colella                                               [Page 2]
+
+RFC 1706                      DNS NSAP RRs                  October 1994
+
+
+4.  Structure of NSAPs
+
+   NSAPs are hierarchically structured to allow distributed
+   administration and efficient routing. Distributed administration
+   permits subdelegated addressing authorities to, as allowed by the
+   delegator, further structure the portion of the NSAP space under
+   their delegated control.  Accomodating this distributed authority
+   requires that there be little or no a priori knowledge of the
+   structure of NSAPs built into DNS resolvers and servers.
+
+   For the purposes of this memo, NSAPs can be thought of as a tree of
+   identifiers. The root of the tree is ISO8348 [6], and has as its
+   immediately registered subordinates the one-octet Authority and
+   Format Identifiers (AFIs) defined there. The size of subsequently-
+   defined fields depends on which branch of the tree is taken. The
+   depth of the tree varies according to the authority responsible for
+   defining subsequent fields.
+
+   An example is the authority under which U.S. GOSIP defines NSAPs [2].
+   Under the AFI of 47, NIST (National Institute of Standards and
+   Technology) obtained a value of 0005 (the AFI of 47 defines the next
+   field as being two octets consisting of four BCD digits from the
+   International Code Designator space [3]). NIST defined the subsequent
+   fields in [2], as shown in Figure 1. The field immediately following
+   0005 is a format identifier for the rest of the U.S. GOSIP NSAP
+   structure, with a hex value of 80. Following this is the three-octet
+   field, values for which are allocated to network operators; the
+   registration authority for this field is delegated to GSA (General
+   Services Administration).
+
+   The last octet of the NSAP is the NSelector (NSel). In practice, the
+   NSAP minus the NSel identifies the CLNP protocol machine on a given
+   system, and the NSel identifies the CLNP user. Since there can be
+   more than one CLNP user (meaning multiple NSel values for a given
+   "base" NSAP), the representation of the NSAP should be CLNP-user
+   independent. To achieve this, an NSel value of zero shall be used
+   with all NSAP values stored in the DNS. An NSAP with NSel=0
+   identifies the network layer itself. It is left to the application
+   retrieving the NSAP to determine the appropriate value to use in that
+   instance of communication.
+
+   When CLNP is used to support TCP and UDP services, the NSel value
+   used is the appropriate IP PROTO value as registered with the IANA.
+   For "standard" OSI, the selection of NSel values is left as a matter
+   of local administration. Administrators of systems that support the
+   OSI transport protocol [4] in addition to TCP/UDP must select NSels
+   for use by OSI Transport that do not conflict with the IP PROTO
+   values.
+
+
+
+Manning & Colella                                               [Page 3]
+
+RFC 1706                      DNS NSAP RRs                  October 1994
+
+
+              |--------------|
+              | <-- IDP -->  |
+              |--------------|-------------------------------------|
+              | AFI |  IDI   |            <-- DSP -->              |
+              |-----|--------|-------------------------------------|
+              | 47  |  0005  | DFI | AA |Rsvd | RD |Area | ID |Sel |
+              |-----|--------|-----|----|-----|----|-----|----|----|
+       octets |  1  |   2    |  1  | 3  |  2  | 2  |  2  | 6  | 1  |
+              |-----|--------|-----|----|-----|----|-----|----|----|
+
+                    IDP    Initial Domain Part
+                    AFI    Authority and Format Identifier
+                    IDI    Initial Domain Identifier
+                    DSP    Domain Specific Part
+                    DFI    DSP Format Identifier
+                    AA     Administrative Authority
+                    Rsvd   Reserved
+                    RD     Routing Domain Identifier
+                    Area   Area Identifier
+                    ID     System Identifier
+                    SEL    NSAP Selector
+
+                  Figure 1: GOSIP Version 2 NSAP structure.
+
+
+   In the NSAP RRs in Master Files and in the printed text in this memo,
+   NSAPs are often represented as a string of "."-separated hex values.
+   The values correspond to convenient divisions of the NSAP to make it
+   more readable. For example, the "."-separated fields might correspond
+   to the NSAP fields as defined by the appropriate authority (RARE,
+   U.S. GOSIP, ANSI, etc.). The use of this notation is strictly for
+   readability. The "."s do not appear in DNS packets and DNS servers
+   can ignore them when reading Master Files. For example, a printable
+   representation of the first four fields of a U.S. GOSIP NSAP might
+   look like
+
+                             47.0005.80.005a00
+
+   and a full U.S. GOSIP NSAP might appear as
+
+             47.0005.80.005a00.0000.1000.0020.00800a123456.00.
+
+   Other NSAP formats have different lengths and different
+   administratively defined field widths to accomodate different
+   requirements. For more information on NSAP formats in use see RFC
+   1629 [1].
+
+
+
+
+
+Manning & Colella                                               [Page 4]
+
+RFC 1706                      DNS NSAP RRs                  October 1994
+
+
+5.  The NSAP RR
+
+   The NSAP RR is defined with mnemonic "NSAP" and TYPE code 22
+   (decimal) and is used to map from domain names to NSAPs. Name-to-NSAP
+   mapping in the DNS using the NSAP RR operates analogously to IP
+   address lookup. A query is generated by the resolver requesting an
+   NSAP RR for a provided domain name.
+
+   NSAP RRs conform to the top level RR format and semantics as defined
+   in Section 3.2.1 of RFC 1035.
+
+                                            1  1  1  1  1  1
+              0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
+           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+           |                                               |
+           /                                               /
+           /                        NAME                   /
+           |                                               |
+           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+           |                    TYPE = NSAP                |
+           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+           |                    CLASS = IN                 |
+           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+           |                        TTL                    |
+           |                                               |
+           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+           |                      RDLENGTH                 |
+           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+           /                       RDATA                   /
+           /                                               /
+           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+   where:
+
+   *  NAME: an owner name, i.e., the name of the node to which this
+      resource record pertains.
+
+   *  TYPE: two octets containing the NSAP RR TYPE code of 22 (decimal).
+
+   *  CLASS: two octets containing the RR IN CLASS code of 1.
+
+   *  TTL: a 32 bit signed integer that specifies the time interval in
+      seconds that the resource record may be cached before the source
+      of the information should again be consulted. Zero values are
+      interpreted to mean that the RR can only be used for the
+      transaction in progress, and should not be cached. For example,
+      SOA records are always distributed with a zero TTL to prohibit
+      caching. Zero values can also be used for extremely volatile data.
+
+
+
+Manning & Colella                                               [Page 5]
+
+RFC 1706                      DNS NSAP RRs                  October 1994
+
+
+   *  RDLENGTH: an unsigned 16 bit integer that specifies the length in
+      octets of the RDATA field.
+
+   *  RDATA: a variable length string of octets containing the NSAP.
+      The value is the binary encoding of the NSAP as it would appear in
+      the CLNP source or destination address field. A typical example of
+      such an NSAP (in hex) is shown below. For this NSAP, RDLENGTH is
+      20 (decimal); "."s have been omitted to emphasize that they don't
+      appear in the DNS packets.
+
+                 39840f80005a0000000001e13708002010726e00
+
+   NSAP RRs cause no additional section processing.
+
+6.  NSAP-to-name Mapping Using the PTR RR
+
+   The PTR RR is defined in RFC 1035. This RR is typically used under
+   the "IN-ADDR.ARPA" domain to map from IPv4 addresses to domain names.
+
+   Similarly, the PTR RR is used to map from NSAPs to domain names under
+   the "NSAP.INT" domain. A domain name is generated from the NSAP
+   according to the rules described below. A query is sent by the
+   resolver requesting a PTR RR for the provided domain name.
+
+   A domain name is generated from an NSAP by reversing the hex nibbles
+   of the NSAP, treating each nibble as a separate subdomain, and
+   appending the top-level subdomain name "NSAP.INT" to it. For example,
+   the domain name used in the reverse lookup for the NSAP
+
+             47.0005.80.005a00.0000.0001.e133.ffffff000162.00
+
+   would appear as
+
+     0.0.2.6.1.0.0.0.f.f.f.f.f.f.3.3.1.e.1.0.0.0.0.0.0.0.0.0.a.5.0.0. \
+                         0.8.5.0.0.0.7.4.NSAP.INT.
+
+   [Implementation note: For sanity's sake user interfaces should be
+   designed to allow users to enter NSAPs using their natural order,
+   i.e., as they are typically written on paper. Also, arbitrary "."s
+   should be allowed (and ignored) on input.]
+
+7.  Master File Format
+
+   The format of NSAP RRs (and NSAP-related PTR RRs) in Master Files
+   conforms to Section 5, "Master Files," of RFC 1035. Below are
+   examples of the use of these RRs in Master Files to support name-to-
+   NSAP and NSAP-to-name mapping.
+
+
+
+
+Manning & Colella                                               [Page 6]
+
+RFC 1706                      DNS NSAP RRs                  October 1994
+
+
+   The NSAP RR introduces a new hex string format for the RDATA field.
+   The format is "0x" (i.e., a zero followed by an 'x' character)
+   followed by a variable length string of hex characters (0 to 9, a to
+   f). The hex string is case-insensitive. "."s (i.e., periods) may be
+   inserted in the hex string anywhere after the "0x" for readability.
+   The "."s have no significance other than for readability and are not
+   propagated in the protocol (e.g., queries or zone transfers).
+
+
+   ;;;;;;
+   ;;;;;; Master File for domain nsap.nist.gov.
+   ;;;;;;
+
+
+   @      IN     SOA    emu.ncsl.nist.gov.  root.emu.ncsl.nist.gov. (
+                                     1994041800   ; Serial  - date
+                                     1800         ; Refresh - 30 minutes
+                                     300          ; Retry   - 5 minutes
+                                     604800       ; Expire  - 7 days
+                                     3600 )       ; Minimum - 1 hour
+          IN     NS     emu.ncsl.nist.gov.
+          IN     NS     tuba.nsap.lanl.gov.
+   ;
+   ;
+   $ORIGIN nsap.nist.gov.
+   ;
+   ;     hosts
+   ;
+   bsdi1    IN  NSAP  0x47.0005.80.005a00.0000.0001.e133.ffffff000161.00
+            IN  A     129.6.224.161
+            IN  HINFO PC_486    BSDi1.1
+   ;
+   bsdi2    IN  NSAP  0x47.0005.80.005a00.0000.0001.e133.ffffff000162.00
+            IN  A     129.6.224.162
+            IN  HINFO PC_486    BSDi1.1
+   ;
+   cursive  IN  NSAP  0x47.0005.80.005a00.0000.0001.e133.ffffff000171.00
+            IN  A     129.6.224.171
+            IN  HINFO PC_386    DOS_5.0/NCSA_Telnet(TUBA)
+   ;
+   infidel  IN  NSAP  0x47.0005.80.005a00.0000.0001.e133.ffffff000164.00
+            IN  A     129.6.55.164
+            IN  HINFO PC/486    BSDi1.0(TUBA)
+   ;
+   ;     routers
+   ;
+   cisco1   IN  NSAP  0x47.0005.80.005a00.0000.0001.e133.aaaaaa000151.00
+            IN  A     129.6.224.151
+
+
+
+Manning & Colella                                               [Page 7]
+
+RFC 1706                      DNS NSAP RRs                  October 1994
+
+
+            IN  A     129.6.225.151
+            IN  A     129.6.229.151
+   ;
+   3com1    IN  NSAP  0x47.0005.80.005a00.0000.0001.e133.aaaaaa000111.00
+            IN  A     129.6.224.111
+            IN  A     129.6.225.111
+            IN  A     129.6.228.111
+
+
+
+
+   ;;;;;;
+   ;;;;;; Master File for reverse mapping of NSAPs under the
+   ;;;;;;     NSAP prefix:
+   ;;;;;;
+   ;;;;;;          47.0005.80.005a00.0000.0001.e133
+   ;;;;;;
+
+
+   @      IN     SOA    emu.ncsl.nist.gov.  root.emu.ncsl.nist.gov. (
+                                     1994041800   ; Serial  - date
+                                     1800         ; Refresh - 30 minutes
+                                     300          ; Retry   - 5 minutes
+                                     604800       ; Expire  - 7 days
+                                     3600 )       ; Minimum - 1 hour
+          IN     NS     emu.ncsl.nist.gov.
+          IN     NS     tuba.nsap.lanl.gov.
+   ;
+   ;
+   $ORIGIN 3.3.1.e.1.0.0.0.0.0.0.0.0.0.a.5.0.0.0.8.5.0.0.0.7.4.NSAP.INT.
+   ;
+   0.0.1.6.1.0.0.0.f.f.f.f.f.f  IN    PTR  bsdi1.nsap.nist.gov.
+   ;
+   0.0.2.6.1.0.0.0.f.f.f.f.f.f  IN    PTR  bsdi2.nsap.nist.gov.
+   ;
+   0.0.1.7.1.0.0.0.f.f.f.f.f.f  IN    PTR  cursive.nsap.nist.gov.
+   ;
+   0.0.4.6.1.0.0.0.f.f.f.f.f.f  IN    PTR  infidel.nsap.nist.gov.
+   ;
+   0.0.1.5.1.0.0.0.a.a.a.a.a.a  IN    PTR  cisco1.nsap.nist.gov.
+   ;
+   0.0.1.1.1.0.0.0.a.a.a.a.a.a  IN    PTR  3com1.nsap.nist.gov.
+
+8.  Security Considerations
+
+   Security issues are not discussed in this memo.
+
+
+
+
+
+Manning & Colella                                               [Page 8]
+
+RFC 1706                      DNS NSAP RRs                  October 1994
+
+
+9.  Authors' Addresses
+
+   Bill Manning
+   USC/Information Sciences Institute
+   4676 Admiralty Way
+   Marina del Rey, CA. 90292
+   USA
+
+   Phone: +1.310.822.1511
+   EMail: bmanning@isi.edu
+
+
+   Richard Colella
+   National Institute of Standards and Technology
+   Technology/B217
+   Gaithersburg, MD 20899
+   USA
+
+   Phone: +1 301-975-3627
+   Fax: +1 301 590-0932
+   EMail: colella@nist.gov
+
+10.  References
+
+   [1] Colella, R., Gardner, E., Callon, R., and Y. Rekhter, "Guidelines
+       for OSI NSAP Allocation inh the Internet", RFC 1629, NIST,
+       Wellfleet, Mitre, T.J. Watson Research Center, IBM Corp., May
+       1994.
+
+   [2] GOSIP Advanced Requirements Group.  Government Open Systems
+       Interconnection Profile (GOSIP) Version 2. Federal Information
+       Processing Standard 146-1, U.S. Department of Commerce, National
+       Institute of Standards and Technology, Gaithersburg, MD, April
+       1991.
+
+   [3] ISO/IEC.  Data interchange - structures for the identification of
+       organization.  International Standard 6523, ISO/IEC JTC 1,
+       Switzerland, 1984.
+
+   [4] ISO/IEC. Connection oriented transport protocol specification.
+       International Standard 8073, ISO/IEC JTC 1, Switzerland, 1986.
+
+   [5] ISO/IEC.  Protocol for Providing the Connectionless-mode Network
+       Service.  International Standard 8473, ISO/IEC JTC 1,
+       Switzerland, 1986.
+
+
+
+
+
+
+Manning & Colella                                               [Page 9]
+
+RFC 1706                      DNS NSAP RRs                  October 1994
+
+
+   [6] ISO/IEC. Information Processing Systems -- Data Communications --
+       Network Service Definition.  International Standard 8348, ISO/IEC
+       JTC 1, Switzerland, 1993.
+
+   [7] Mockapetris, P., "Domain Names -- Concepts and Facilities", STD
+       13, RFC 1034, USC/Information Sciences Institute, November 1987.
+
+   [8] Mockapetris, P., "Domain Names -- Implementation and
+       Specification", STD 13, RFC 1035, USC/Information Sciences
+       Institute, November 1987.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Manning & Colella                                              [Page 10]
+
diff --git a/doc/rfc/rfc1712.txt b/doc/rfc/rfc1712.txt
new file mode 100644
index 0000000..40d8857
--- /dev/null
+++ b/doc/rfc/rfc1712.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+Network Working Group                                         C. Farrell
+Request for Comments: 1712                                    M. Schulze
+Category: Experimental                                       S. Pleitner
+                                                              D. Baldoni
+                                         Curtin University of Technology
+                                                           November 1994
+
+
+                 DNS Encoding of Geographical Location
+
+Status of this Memo
+
+   This memo defines an Experimental Protocol for the Internet
+   community.  This memo does not specify an Internet standard of any
+   kind.  Discussion and suggestions for improvement are requested.
+   Distribution of this memo is unlimited.
+
+Abstract
+
+   This document defines the format of a new Resource Record (RR) for
+   the Domain Naming System (DNS), and reserves a corresponding DNS type
+   mnemonic and numerical code.  This definition deals with associating
+   geographical host location mappings to host names within a domain.
+   The data shown in this document is fictitious and does not
+   necessarily reflect the real Internet.
+
+1. Introduction
+
+   It has been a long standing problem to relate IP numbers to
+   geographical locations. The availability of Geographical location
+   information has immediate applications in network management.  Such
+   information can be used to supplement the data already provided by
+   utilities such as whois [Har85], traceroute [VJ89], and nslookup
+   [UCB89].  The usefulness and functionality of these already widely
+   used tools would be greatly enhanced by the provision of reliable
+   geographical location information.
+
+   The ideal way to manage and maintain a database of information, such
+   as geographical location of internet hosts, is to delegate
+   responsibility to local domain administrators. A large distributed
+   database could be implemented with a simple mechanism for updating
+   the local information.  A query mechanism also has to be available
+   for checking local entries, as well as inquiring about data from
+   non-local domains.
+
+
+
+
+
+
+
+Farrell, Schulze, Pleitner & Baldoni                            [Page 1]
+
+RFC 1712         DNS Encoding of Geographical Location     November 1994
+
+
+2. Background
+
+   The Internet continues to grow at an ever increasing rate with IP
+   numbers allocated on a first-come-first-serve basis.  Deciding when
+   and how to setup a database of geographical information about
+   internet hosts presented a number of options.  The uumap project
+   [UU85] was the first serious attempt to collect geographical location
+   data from sites and store it centrally.  This project met with
+   limited success because of the difficulty in maintaining and updating
+   a large central database.  Another problem was the lack of tools for
+   the checking the data supplied, this problem resulted in some
+   erroneous data entering the database.
+
+2.1 SNMP:
+
+   Using an SNMP get request on the sysLocation MIB (Management
+   Information Base) variable was also an option, however this would
+   require the host to be running an appropriate agent with public read
+   access.  It was also felt that MIB data should reflect local
+   management data (e.g., "this" host is on level 5 room 74) rather than
+   a hosts geographical position.  This view is supported in the
+   examples given in literature in this area [ROSE91].
+
+2.2 X500:
+
+   The X.500 Directory service [X.500.88] defined as part of the ISO
+   standards also appears as a potential provider of geographical
+   location data. However due to the limited implementations of this
+   service it was decided to defer this until this service gains wider
+   use and acceptance within the Internet community.
+
+2.3 BIND:
+
+   The DNS [Mock87a][Mock87b] represents an existing system ideally
+   suited to the provision of host specific information. The DNS is a
+   widely used and well-understood mechanism for providing a distributed
+   database of such information and its extensible nature allows it to
+   be used to disseminate virtually any information.  The most commonly
+   used DNS implementation is the Berkeley Internet Name Domain server
+   BIND [UCB89].  The information we wished to make available needed to
+   be updated locally but available globally; a perfect match with the
+   services provided by the DNS. Current DNS servers provide a variety
+   of useful information about hosts in their domain but lack the
+   ability to report a host's geographical location.
+
+
+
+
+
+
+
+Farrell, Schulze, Pleitner & Baldoni                            [Page 2]
+
+RFC 1712         DNS Encoding of Geographical Location     November 1994
+
+
+3. RDATA Format
+
+        MSB                                        LSB
+        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+        /                 LONGITUDE                  /
+        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+        /                  LATITUDE                  /
+        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+        /                  ALTITUDE                  /
+        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+   where:
+
+   LONGITUDE The real number describing the longitude encoded as a
+             printable string. The precision is limited by 256 charcters
+             within the range -90..90 degrees. Positive numbers
+             indicate locations north of the equator.
+
+   LATITUDE The real number describing the latitude encoded as a
+            printable string. The precision is limited by 256 charcters
+            within the range -180..180 degrees. Positive numbers
+            indicate locations east of the prime meridian.
+
+   ALTITUDE The real number describing the altitude (in meters) from
+            mean sea-level encoded as a printable string. The precision
+            is limited by 256 charcters. Positive numbers indicate
+            locations above mean sea-level.
+
+   Latitude/Longitude/Altitude values are encoded as strings as to avoid
+   the precision limitations imposed by encoding as unsigned integers.
+   Although this might not be considered optimal, it allows for a very
+   high degree of precision with an acceptable average encoded record
+   length.
+
+4. The GPOS RR
+
+   The geographical location is defined with the mnemonic GPOS and type
+   code 27.
+
+   GPOS has the following format:
+           <owner> <ttl> <class> GPOS <longitude> <latitude> <altitude>
+
+   A floating point format was chosen to specify geographical locations
+   for reasons of simplicity.  This also guarantees a concise
+   unambiguous description of a location by enforcing three compulsory
+   numerical values to be specified.
+
+
+
+
+
+Farrell, Schulze, Pleitner & Baldoni                            [Page 3]
+
+RFC 1712         DNS Encoding of Geographical Location     November 1994
+
+
+   The owner, ttl, and class fields are optional and default to the last
+   defined value if omitted. The longitude is a floating point number
+   ranging from -90 to 90 with positive values indicating locations
+   north of the equator.  For example Perth, Western Australia is
+   located at 32^ 7` 19" south of the equator which would be specified
+   as -32.68820.  The latitude is a number ranging from -180.0 to 180.0.
+   For example Perth, Western Australia is located at 116^ 2' 25" east
+   of the prime meridian which would be specified as 116.86520.  Curtin
+   University, Perth is also 10 meters above sea-level.
+
+   The valid GPOS record for a host at Curtin University in  Perth
+   Western Australia would therefore be:
+
+                GPOS -32.6882 116.8652 10.0
+
+   There is no limit imposed on the number of decimal places, although
+   the length of the encoded string is limited to 256 characters for
+   each field. It is also suggested that administrators limit their
+   entries to the minimum number of necessary characters in each field.
+
+5. Master File Format
+
+   Each host requires its own GPOS field in the corresponding  DNS RR to
+   explicitly specify its geographical location and altitude.  If the
+   GPOS field is omitted, a DNS enquiry will return no position
+   information for that host.
+
+   Consider the following example:
+
+; Authoritative data for cs.curtin.edu.au.
+;
+@     IN    SOA     marsh.cs.curtin.edu.au. postmaster.cs.curtin.edu.au.
+                (
+                        94070503        ; Serial (yymmddnn)
+                        10800           ; Refresh (3 hours)
+                        3600            ; Retry (1 hour)
+                        3600000         ; Expire (1000 hours)
+                        86400           ; Minimum (24 hours)
+                )
+
+                IN      NS      marsh.cs.curtin.edu.au.
+
+marsh           IN      A       134.7.1.1
+                IN      MX      0       marsh
+                IN      HINFO   SGI-Indigo IRIX-4.0.5F
+                IN      GPOS    -32.6882 116.8652 10.0
+ftp             IN      CNAME   marsh
+
+
+
+
+Farrell, Schulze, Pleitner & Baldoni                            [Page 4]
+
+RFC 1712         DNS Encoding of Geographical Location     November 1994
+
+
+lillee          IN      A       134.7.1.2
+                IN      MX      0       marsh
+                IN      HINFO   SGI-Indigo IRIX-4.0.5F
+                IN      GPOS    -32.6882 116.8652 10.0
+
+hinault         IN      A       134.7.1.23
+                IN      MX      0       marsh
+                IN      HINFO   SUN-IPC SunOS-4.1.3
+                IN      GPOS    -22.6882 116.8652 250.0
+
+merckx          IN      A       134.7.1.24
+                IN      MX      0       marsh
+                IN      HINFO   SUN-IPC SunOS-4.1.1
+
+ambrose         IN      A       134.7.1.99
+                IN      MX      0       marsh
+                IN      HINFO   SGI-CHALLENGE_L IRIX-5.2
+                IN      GPOS    -32.6882 116.8652 10.0
+
+   The hosts marsh, lillee, and ambrose are all at the same geographical
+   location, Perth Western Australia (-32.68820 116.86520). The host
+   hinault is at a different geographical location, 10 degrees north of
+   Perth in the mountains (-22.6882 116.8652 250.0). For security
+   reasons we do not wish to give the location of the host merckx.
+
+   Although the GPOS clause is not a standard entry within BIND
+   configuration files, most vendor implementations seem to ignore
+   whatever is not understood upon startup of the DNS.  Usually this
+   will result in a number of warnings appearing in system log files,
+   but in no way alters naming information or impedes the DNS from
+   performing its normal duties.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Farrell, Schulze, Pleitner & Baldoni                            [Page 5]
+
+RFC 1712         DNS Encoding of Geographical Location     November 1994
+
+
+7. References
+
+   [ROSE91]        Rose M., "The Simple Book: An Introduction to
+                   Management of TCP/IP-based Internets", Prentice-Hall,
+                   Englewood Cliffs, New Jersey, 1991.
+
+   [X.500.88]      CCITT: The Directory - Overview of Concepts, Models
+                   and Services", Recommendations X.500 - X.521.
+
+   [Har82]         Harrenstein K, Stahl M., and E. Feinler,
+                   "NICNAME/WHOIS" RFC 812, SRI NIC, March 1982.
+
+   [Mock87a]       Mockapetris P., "Domain Names - Concepts and
+                   Facilities", STD 13, RFC 1034, USC/Information
+                   Sciences Institute, November 1987.
+
+   [Mock87b]       Mockapetris P., "Domain Names - Implementation and
+                   Specification", STD 13, RFC 1035, USC/Information
+                   Sciences Institute, November 1987.
+
+   [FRB93]         Ford P., Rekhter Y., and H-W. Braun, "Improving the
+                   Routing and Addressing of IP", IEEE Network
+                   Vol.7, No. 3, pp. 11-15, May 1993.
+
+   [VJ89]          Jacobsen V., "The Traceroute(8) Manual Page",
+                   Lawrence Berkeley Laboratory, Berkeley,
+                   CA, February 1989.
+
+   [UCB89]         University of California, "BIND: Berkeley Internet
+                   Name Domain Server", 1989.
+   [UU85]          UUCP Mapping Project, Software available via
+                   anonymous FTP from ftp.uu.net., 1985.
+
+8. Security Considerations
+
+   Once information has been entered into the DNS, it is considered
+   public.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Farrell, Schulze, Pleitner & Baldoni                            [Page 6]
+
+RFC 1712         DNS Encoding of Geographical Location     November 1994
+
+
+9. Authors' Addresses
+
+   Craig Farrell
+   Department of Computer Science
+   Curtin University of technology
+   GPO Box U1987 Perth,
+   Western Australia
+
+   EMail: craig@cs.curtin.edu.au
+
+
+   Mike Schulze
+   Department of Computer Science
+   Curtin University of technology
+   GPO Box U1987 Perth,
+   Western Australia
+
+   EMail: mike@cs.curtin.edu.au
+
+
+   Scott Pleitner
+   Department of Computer Science
+   Curtin University of technology
+   GPO Box U1987 Perth,
+   Western Australia
+
+   EMail: pleitner@cs.curtin.edu.au
+
+
+   Daniel Baldoni
+   Department of Computer Science
+   Curtin University of technology
+   GPO Box U1987 Perth,
+   Western Australia
+
+   EMail: flint@cs.curtin.edu.au
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Farrell, Schulze, Pleitner & Baldoni                            [Page 7]
+
diff --git a/doc/rfc/rfc1750.txt b/doc/rfc/rfc1750.txt
new file mode 100644
index 0000000..56d478c
--- /dev/null
+++ b/doc/rfc/rfc1750.txt
@@ -0,0 +1,1683 @@
+
+
+
+
+
+
+Network Working Group                                   D. Eastlake, 3rd
+Request for Comments: 1750                                           DEC
+Category: Informational                                       S. Crocker
+                                                               Cybercash
+                                                             J. Schiller
+                                                                     MIT
+                                                           December 1994
+
+
+                Randomness Recommendations for Security
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  This memo
+   does not specify an Internet standard of any kind.  Distribution of
+   this memo is unlimited.
+
+Abstract
+
+   Security systems today are built on increasingly strong cryptographic
+   algorithms that foil pattern analysis attempts. However, the security
+   of these systems is dependent on generating secret quantities for
+   passwords, cryptographic keys, and similar quantities.  The use of
+   pseudo-random processes to generate secret quantities can result in
+   pseudo-security.  The sophisticated attacker of these security
+   systems may find it easier to reproduce the environment that produced
+   the secret quantities, searching the resulting small set of
+   possibilities, than to locate the quantities in the whole of the
+   number space.
+
+   Choosing random quantities to foil a resourceful and motivated
+   adversary is surprisingly difficult.  This paper points out many
+   pitfalls in using traditional pseudo-random number generation
+   techniques for choosing such quantities.  It recommends the use of
+   truly random hardware techniques and shows that the existing hardware
+   on many systems can be used for this purpose.  It provides
+   suggestions to ameliorate the problem when a hardware solution is not
+   available.  And it gives examples of how large such quantities need
+   to be for some particular applications.
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake, Crocker & Schiller                                    [Page 1]
+
+RFC 1750        Randomness Recommendations for Security    December 1994
+
+
+Acknowledgements
+
+   Comments on this document that have been incorporated were received
+   from (in alphabetic order) the following:
+
+        David M. Balenson (TIS)
+        Don Coppersmith (IBM)
+        Don T. Davis (consultant)
+        Carl Ellison (Stratus)
+        Marc Horowitz (MIT)
+        Christian Huitema (INRIA)
+        Charlie Kaufman (IRIS)
+        Steve Kent (BBN)
+        Hal Murray (DEC)
+        Neil Haller (Bellcore)
+        Richard Pitkin (DEC)
+        Tim Redmond (TIS)
+        Doug Tygar (CMU)
+
+Table of Contents
+
+   1. Introduction........................................... 3
+   2. Requirements........................................... 4
+   3. Traditional Pseudo-Random Sequences.................... 5
+   4. Unpredictability....................................... 7
+   4.1 Problems with Clocks and Serial Numbers............... 7
+   4.2 Timing and Content of External Events................  8
+   4.3 The Fallacy of Complex Manipulation..................  8
+   4.4 The Fallacy of Selection from a Large Database.......  9
+   5. Hardware for Randomness............................... 10
+   5.1 Volume Required...................................... 10
+   5.2 Sensitivity to Skew.................................. 10
+   5.2.1 Using Stream Parity to De-Skew..................... 11
+   5.2.2 Using Transition Mappings to De-Skew............... 12
+   5.2.3 Using FFT to De-Skew............................... 13
+   5.2.4 Using Compression to De-Skew....................... 13
+   5.3 Existing Hardware Can Be Used For Randomness......... 14
+   5.3.1 Using Existing Sound/Video Input................... 14
+   5.3.2 Using Existing Disk Drives......................... 14
+   6. Recommended Non-Hardware Strategy..................... 14
+   6.1 Mixing Functions..................................... 15
+   6.1.1 A Trivial Mixing Function.......................... 15
+   6.1.2 Stronger Mixing Functions.......................... 16
+   6.1.3 Diff-Hellman as a Mixing Function.................. 17
+   6.1.4 Using a Mixing Function to Stretch Random Bits..... 17
+   6.1.5 Other Factors in Choosing a Mixing Function........ 18
+   6.2 Non-Hardware Sources of Randomness................... 19
+   6.3 Cryptographically Strong Sequences................... 19
+
+
+
+Eastlake, Crocker & Schiller                                    [Page 2]
+
+RFC 1750        Randomness Recommendations for Security    December 1994
+
+
+   6.3.1 Traditional Strong Sequences....................... 20
+   6.3.2 The Blum Blum Shub Sequence Generator.............. 21
+   7. Key Generation Standards.............................. 22
+   7.1 US DoD Recommendations for Password Generation....... 23
+   7.2 X9.17 Key Generation................................. 23
+   8. Examples of Randomness Required....................... 24
+   8.1  Password Generation................................. 24
+   8.2 A Very High Security Cryptographic Key............... 25
+   8.2.1 Effort per Key Trial............................... 25
+   8.2.2 Meet in the Middle Attacks......................... 26
+   8.2.3 Other Considerations............................... 26
+   9. Conclusion............................................ 27
+   10. Security Considerations.............................. 27
+   References............................................... 28
+   Authors' Addresses....................................... 30
+
+1. Introduction
+
+   Software cryptography is coming into wider use.  Systems like
+   Kerberos, PEM, PGP, etc. are maturing and becoming a part of the
+   network landscape [PEM].  These systems provide substantial
+   protection against snooping and spoofing.  However, there is a
+   potential flaw.  At the heart of all cryptographic systems is the
+   generation of secret, unguessable (i.e., random) numbers.
+
+   For the present, the lack of generally available facilities for
+   generating such unpredictable numbers is an open wound in the design
+   of cryptographic software.  For the software developer who wants to
+   build a key or password generation procedure that runs on a wide
+   range of hardware, the only safe strategy so far has been to force
+   the local installation to supply a suitable routine to generate
+   random numbers.  To say the least, this is an awkward, error-prone
+   and unpalatable solution.
+
+   It is important to keep in mind that the requirement is for data that
+   an adversary has a very low probability of guessing or determining.
+   This will fail if pseudo-random data is used which only meets
+   traditional statistical tests for randomness or which is based on
+   limited range sources, such as clocks.  Frequently such random
+   quantities are determinable by an adversary searching through an
+   embarrassingly small space of possibilities.
+
+   This informational document suggests techniques for producing random
+   quantities that will be resistant to such attack.  It recommends that
+   future systems include hardware random number generation or provide
+   access to existing hardware that can be used for this purpose.  It
+   suggests methods for use if such hardware is not available.  And it
+   gives some estimates of the number of random bits required for sample
+
+
+
+Eastlake, Crocker & Schiller                                    [Page 3]
+
+RFC 1750        Randomness Recommendations for Security    December 1994
+
+
+   applications.
+
+2. Requirements
+
+   Probably the most commonly encountered randomness requirement today
+   is the user password. This is usually a simple character string.
+   Obviously, if a password can be guessed, it does not provide
+   security.  (For re-usable passwords, it is desirable that users be
+   able to remember the password.  This may make it advisable to use
+   pronounceable character strings or phrases composed on ordinary
+   words.  But this only affects the format of the password information,
+   not the requirement that the password be very hard to guess.)
+
+   Many other requirements come from the cryptographic arena.
+   Cryptographic techniques can be used to provide a variety of services
+   including confidentiality and authentication.  Such services are
+   based on quantities, traditionally called "keys", that are unknown to
+   and unguessable by an adversary.
+
+   In some cases, such as the use of symmetric encryption with the one
+   time pads [CRYPTO*] or the US Data Encryption Standard [DES], the
+   parties who wish to communicate confidentially and/or with
+   authentication must all know the same secret key.  In other cases,
+   using what are called asymmetric or "public key" cryptographic
+   techniques, keys come in pairs.  One key of the pair is private and
+   must be kept secret by one party, the other is public and can be
+   published to the world.  It is computationally infeasible to
+   determine the private key from the public key [ASYMMETRIC, CRYPTO*].
+
+   The frequency and volume of the requirement for random quantities
+   differs greatly for different cryptographic systems.  Using pure RSA
+   [CRYPTO*], random quantities are required when the key pair is
+   generated, but thereafter any number of messages can be signed
+   without any further need for randomness.  The public key Digital
+   Signature Algorithm that has been proposed by the US National
+   Institute of Standards and Technology (NIST) requires good random
+   numbers for each signature.  And encrypting with a one time pad, in
+   principle the strongest possible encryption technique, requires a
+   volume of randomness equal to all the messages to be processed.
+
+   In most of these cases, an adversary can try to determine the
+   "secret" key by trial and error.  (This is possible as long as the
+   key is enough smaller than the message that the correct key can be
+   uniquely identified.)  The probability of an adversary succeeding at
+   this must be made acceptably low, depending on the particular
+   application.  The size of the space the adversary must search is
+   related to the amount of key "information" present in the information
+   theoretic sense [SHANNON].  This depends on the number of different
+
+
+
+Eastlake, Crocker & Schiller                                    [Page 4]
+
+RFC 1750        Randomness Recommendations for Security    December 1994
+
+
+   secret values possible and the probability of each value as follows:
+
+                      -----
+                       \
+        Bits-of-info =  \  - p   * log  ( p  )
+                        /     i       2    i
+                       /
+                      -----
+
+   where i varies from 1 to the number of possible secret values and p
+   sub i is the probability of the value numbered i.  (Since p sub i is
+   less than one, the log will be negative so each term in the sum will
+   be non-negative.)
+
+   If there are 2^n different values of equal probability, then n bits
+   of information are present and an adversary would, on the average,
+   have to try half of the values, or 2^(n-1) , before guessing the
+   secret quantity.  If the probability of different values is unequal,
+   then there is less information present and fewer guesses will, on
+   average, be required by an adversary.  In particular, any values that
+   the adversary can know are impossible, or are of low probability, can
+   be initially ignored by an adversary, who will search through the
+   more probable values first.
+
+   For example, consider a cryptographic system that uses 56 bit keys.
+   If these 56 bit keys are derived by using a fixed pseudo-random
+   number generator that is seeded with an 8 bit seed, then an adversary
+   needs to search through only 256 keys (by running the pseudo-random
+   number generator with every possible seed), not the 2^56 keys that
+   may at first appear to be the case. Only 8 bits of "information" are
+   in these 56 bit keys.
+
+3. Traditional Pseudo-Random Sequences
+
+   Most traditional sources of random numbers use deterministic sources
+   of "pseudo-random" numbers.  These typically start with a "seed"
+   quantity and use numeric or logical operations to produce a sequence
+   of values.
+
+   [KNUTH] has a classic exposition on pseudo-random numbers.
+   Applications he mentions are simulation of natural phenomena,
+   sampling, numerical analysis, testing computer programs, decision
+   making, and games.  None of these have the same characteristics as
+   the sort of security uses we are talking about.  Only in the last two
+   could there be an adversary trying to find the random quantity.
+   However, in these cases, the adversary normally has only a single
+   chance to use a guessed value.  In guessing passwords or attempting
+   to break an encryption scheme, the adversary normally has many,
+
+
+
+Eastlake, Crocker & Schiller                                    [Page 5]
+
+RFC 1750        Randomness Recommendations for Security    December 1994
+
+
+   perhaps unlimited, chances at guessing the correct value and should
+   be assumed to be aided by a computer.
+
+   For testing the "randomness" of numbers, Knuth suggests a variety of
+   measures including statistical and spectral.  These tests check
+   things like autocorrelation between different parts of a "random"
+   sequence or distribution of its values.  They could be met by a
+   constant stored random sequence, such as the "random" sequence
+   printed in the CRC Standard Mathematical Tables [CRC].
+
+   A typical pseudo-random number generation technique, known as a
+   linear congruence pseudo-random number generator, is modular
+   arithmetic where the N+1th value is calculated from the Nth value by
+
+        V    = ( V  * a + b )(Mod c)
+         N+1      N
+
+   The above technique has a strong relationship to linear shift
+   register pseudo-random number generators, which are well understood
+   cryptographically [SHIFT*].  In such generators bits are introduced
+   at one end of a shift register as the Exclusive Or (binary sum
+   without carry) of bits from selected fixed taps into the register.
+
+   For example:
+
+      +----+     +----+     +----+                      +----+
+      | B  | <-- | B  | <-- | B  | <--  . . . . . . <-- | B  | <-+
+      |  0 |     |  1 |     |  2 |                      |  n |   |
+      +----+     +----+     +----+                      +----+   |
+        |                     |            |                     |
+        |                     |            V                  +-----+
+        |                     V            +----------------> |     |
+        V                     +-----------------------------> | XOR |
+        +---------------------------------------------------> |     |
+                                                              +-----+
+
+
+       V    = ( ( V  * 2 ) + B .xor. B ... )(Mod 2^n)
+        N+1         N         0       2
+
+   The goodness of traditional pseudo-random number generator algorithms
+   is measured by statistical tests on such sequences.  Carefully chosen
+   values of the initial V and a, b, and c or the placement of shift
+   register tap in the above simple processes can produce excellent
+   statistics.
+
+
+
+
+
+
+Eastlake, Crocker & Schiller                                    [Page 6]
+
+RFC 1750        Randomness Recommendations for Security    December 1994
+
+
+   These sequences may be adequate in simulations (Monte Carlo
+   experiments) as long as the sequence is orthogonal to the structure
+   of the space being explored.  Even there, subtle patterns may cause
+   problems.  However, such sequences are clearly bad for use in
+   security applications.  They are fully predictable if the initial
+   state is known.  Depending on the form of the pseudo-random number
+   generator, the sequence may be determinable from observation of a
+   short portion of the sequence [CRYPTO*, STERN].  For example, with
+   the generators above, one can determine V(n+1) given knowledge of
+   V(n).  In fact, it has been shown that with these techniques, even if
+   only one bit of the pseudo-random values is released, the seed can be
+   determined from short sequences.
+
+   Not only have linear congruent generators been broken, but techniques
+   are now known for breaking all polynomial congruent generators
+   [KRAWCZYK].
+
+4. Unpredictability
+
+   Randomness in the traditional sense described in section 3 is NOT the
+   same as the unpredictability required for security use.
+
+   For example, use of a widely available constant sequence, such as
+   that from the CRC tables, is very weak against an adversary. Once
+   they learn of or guess it, they can easily break all security, future
+   and past, based on the sequence [CRC].  Yet the statistical
+   properties of these tables are good.
+
+   The following sections describe the limitations of some randomness
+   generation techniques and sources.
+
+4.1 Problems with Clocks and Serial Numbers
+
+   Computer clocks, or similar operating system or hardware values,
+   provide significantly fewer real bits of unpredictability than might
+   appear from their specifications.
+
+   Tests have been done on clocks on numerous systems and it was found
+   that their behavior can vary widely and in unexpected ways.  One
+   version of an operating system running on one set of hardware may
+   actually provide, say, microsecond resolution in a clock while a
+   different configuration of the "same" system may always provide the
+   same lower bits and only count in the upper bits at much lower
+   resolution.  This means that successive reads on the clock may
+   produce identical values even if enough time has passed that the
+   value "should" change based on the nominal clock resolution. There
+   are also cases where frequently reading a clock can produce
+   artificial sequential values because of extra code that checks for
+
+
+
+Eastlake, Crocker & Schiller                                    [Page 7]
+
+RFC 1750        Randomness Recommendations for Security    December 1994
+
+
+   the clock being unchanged between two reads and increases it by one!
+   Designing portable application code to generate unpredictable numbers
+   based on such system clocks is particularly challenging because the
+   system designer does not always know the properties of the system
+   clocks that the code will execute on.
+
+   Use of a hardware serial number such as an Ethernet address may also
+   provide fewer bits of uniqueness than one would guess.  Such
+   quantities are usually heavily structured and subfields may have only
+   a limited range of possible values or values easily guessable based
+   on approximate date of manufacture or other data.  For example, it is
+   likely that most of the Ethernet cards installed on Digital Equipment
+   Corporation (DEC) hardware within DEC were manufactured by DEC
+   itself, which significantly limits the range of built in addresses.
+
+   Problems such as those described above related to clocks and serial
+   numbers make code to produce unpredictable quantities difficult if
+   the code is to be ported across a variety of computer platforms and
+   systems.
+
+4.2 Timing and Content of External Events
+
+   It is possible to measure the timing and content of mouse movement,
+   key strokes, and similar user events.  This is a reasonable source of
+   unguessable data with some qualifications.  On some machines, inputs
+   such as key strokes are buffered.  Even though the user's inter-
+   keystroke timing may have sufficient variation and unpredictability,
+   there might not be an easy way to access that variation.  Another
+   problem is that no standard method exists to sample timing details.
+   This makes it hard to build standard software intended for
+   distribution to a large range of machines based on this technique.
+
+   The amount of mouse movement or the keys actually hit are usually
+   easier to access than timings but may yield less unpredictability as
+   the user may provide highly repetitive input.
+
+   Other external events, such as network packet arrival times, can also
+   be used with care.  In particular, the possibility of manipulation of
+   such times by an adversary must be considered.
+
+4.3 The Fallacy of Complex Manipulation
+
+   One strategy which may give a misleading appearance of
+   unpredictability is to take a very complex algorithm (or an excellent
+   traditional pseudo-random number generator with good statistical
+   properties) and calculate a cryptographic key by starting with the
+   current value of a computer system clock as the seed.  An adversary
+   who knew roughly when the generator was started would have a
+
+
+
+Eastlake, Crocker & Schiller                                    [Page 8]
+
+RFC 1750        Randomness Recommendations for Security    December 1994
+
+
+   relatively small number of seed values to test as they would know
+   likely values of the system clock.  Large numbers of pseudo-random
+   bits could be generated but the search space an adversary would need
+   to check could be quite small.
+
+   Thus very strong and/or complex manipulation of data will not help if
+   the adversary can learn what the manipulation is and there is not
+   enough unpredictability in the starting seed value.  Even if they can
+   not learn what the manipulation is, they may be able to use the
+   limited number of results stemming from a limited number of seed
+   values to defeat security.
+
+   Another serious strategy error is to assume that a very complex
+   pseudo-random number generation algorithm will produce strong random
+   numbers when there has been no theory behind or analysis of the
+   algorithm.  There is a excellent example of this fallacy right near
+   the beginning of chapter 3 in [KNUTH] where the author describes a
+   complex algorithm.  It was intended that the machine language program
+   corresponding to the algorithm would be so complicated that a person
+   trying to read the code without comments wouldn't know what the
+   program was doing.  Unfortunately, actual use of this algorithm
+   showed that it almost immediately converged to a single repeated
+   value in one case and a small cycle of values in another case.
+
+   Not only does complex manipulation not help you if you have a limited
+   range of seeds but blindly chosen complex manipulation can destroy
+   the randomness in a good seed!
+
+4.4 The Fallacy of Selection from a Large Database
+
+   Another strategy that can give a misleading appearance of
+   unpredictability is selection of a quantity randomly from a database
+   and assume that its strength is related to the total number of bits
+   in the database.  For example, typical USENET servers as of this date
+   process over 35 megabytes of information per day.  Assume a random
+   quantity was selected by fetching 32 bytes of data from a random
+   starting point in this data.  This does not yield 32*8 = 256 bits
+   worth of unguessability.  Even after allowing that much of the data
+   is human language and probably has more like 2 or 3 bits of
+   information per byte, it doesn't yield 32*2.5 = 80 bits of
+   unguessability.  For an adversary with access to the same 35
+   megabytes the unguessability rests only on the starting point of the
+   selection.  That is, at best, about 25 bits of unguessability in this
+   case.
+
+   The same argument applies to selecting sequences from the data on a
+   CD ROM or Audio CD recording or any other large public database.  If
+   the adversary has access to the same database, this "selection from a
+
+
+
+Eastlake, Crocker & Schiller                                    [Page 9]
+
+RFC 1750        Randomness Recommendations for Security    December 1994
+
+
+   large volume of data" step buys very little.  However, if a selection
+   can be made from data to which the adversary has no access, such as
+   system buffers on an active multi-user system, it may be of some
+   help.
+
+5. Hardware for Randomness
+
+   Is there any hope for strong portable randomness in the future?
+   There might be.  All that's needed is a physical source of
+   unpredictable numbers.
+
+   A thermal noise or radioactive decay source and a fast, free-running
+   oscillator would do the trick directly [GIFFORD].  This is a trivial
+   amount of hardware, and could easily be included as a standard part
+   of a computer system's architecture.  Furthermore, any system with a
+   spinning disk or the like has an adequate source of randomness
+   [DAVIS].  All that's needed is the common perception among computer
+   vendors that this small additional hardware and the software to
+   access it is necessary and useful.
+
+5.1 Volume Required
+
+   How much unpredictability is needed?  Is it possible to quantify the
+   requirement in, say, number of random bits per second?
+
+   The answer is not very much is needed.  For DES, the key is 56 bits
+   and, as we show in an example in Section 8, even the highest security
+   system is unlikely to require a keying material of over 200 bits.  If
+   a series of keys are needed, it can be generated from a strong random
+   seed using a cryptographically strong sequence as explained in
+   Section 6.3.  A few hundred random bits generated once a day would be
+   enough using such techniques.  Even if the random bits are generated
+   as slowly as one per second and it is not possible to overlap the
+   generation process, it should be tolerable in high security
+   applications to wait 200 seconds occasionally.
+
+   These numbers are trivial to achieve.  It could be done by a person
+   repeatedly tossing a coin.  Almost any hardware process is likely to
+   be much faster.
+
+5.2 Sensitivity to Skew
+
+   Is there any specific requirement on the shape of the distribution of
+   the random numbers?  The good news is the distribution need not be
+   uniform.  All that is needed is a conservative estimate of how non-
+   uniform it is to bound performance.  Two simple techniques to de-skew
+   the bit stream are given below and stronger techniques are mentioned
+   in Section 6.1.2 below.
+
+
+
+Eastlake, Crocker & Schiller                                   [Page 10]
+
+RFC 1750        Randomness Recommendations for Security    December 1994
+
+
+5.2.1 Using Stream Parity to De-Skew
+
+   Consider taking a sufficiently long string of bits and map the string
+   to "zero" or "one".  The mapping will not yield a perfectly uniform
+   distribution, but it can be as close as desired.  One mapping that
+   serves the purpose is to take the parity of the string.  This has the
+   advantages that it is robust across all degrees of skew up to the
+   estimated maximum skew and is absolutely trivial to implement in
+   hardware.
+
+   The following analysis gives the number of bits that must be sampled:
+
+   Suppose the ratio of ones to zeros is 0.5 + e : 0.5 - e, where e is
+   between 0 and 0.5 and is a measure of the "eccentricity" of the
+   distribution.  Consider the distribution of the parity function of N
+   bit samples.  The probabilities that the parity will be one or zero
+   will be the sum of the odd or even terms in the binomial expansion of
+   (p + q)^N, where p = 0.5 + e, the probability of a one, and q = 0.5 -
+   e, the probability of a zero.
+
+   These sums can be computed easily as
+
+                         N            N
+        1/2 * ( ( p + q )  + ( p - q )  )
+   and
+                         N            N
+        1/2 * ( ( p + q )  - ( p - q )  ).
+
+   (Which one corresponds to the probability the parity will be 1
+   depends on whether N is odd or even.)
+
+   Since p + q = 1 and p - q = 2e, these expressions reduce to
+
+                       N
+        1/2 * [1 + (2e) ]
+   and
+                       N
+        1/2 * [1 - (2e) ].
+
+   Neither of these will ever be exactly 0.5 unless e is zero, but we
+   can bring them arbitrarily close to 0.5.  If we want the
+   probabilities to be within some delta d of 0.5, i.e. then
+
+                            N
+        ( 0.5 + ( 0.5 * (2e)  ) )  <  0.5 + d.
+
+
+
+
+
+
+Eastlake, Crocker & Schiller                                   [Page 11]
+
+RFC 1750        Randomness Recommendations for Security    December 1994
+
+
+   Solving for N yields N > log(2d)/log(2e).  (Note that 2e is less than
+   1, so its log is negative.  Division by a negative number reverses
+   the sense of an inequality.)
+
+   The following table gives the length of the string which must be
+   sampled for various degrees of skew in order to come within 0.001 of
+   a 50/50 distribution.
+
+                       +---------+--------+-------+
+                       | Prob(1) |    e   |    N  |
+                       +---------+--------+-------+
+                       |   0.5   |  0.00  |    1  |
+                       |   0.6   |  0.10  |    4  |
+                       |   0.7   |  0.20  |    7  |
+                       |   0.8   |  0.30  |   13  |
+                       |   0.9   |  0.40  |   28  |
+                       |   0.95  |  0.45  |   59  |
+                       |   0.99  |  0.49  |  308  |
+                       +---------+--------+-------+
+
+   The last entry shows that even if the distribution is skewed 99% in
+   favor of ones, the parity of a string of 308 samples will be within
+   0.001 of a 50/50 distribution.
+
+5.2.2 Using Transition Mappings to De-Skew
+
+   Another technique, originally due to von Neumann [VON NEUMANN], is to
+   examine a bit stream as a sequence of non-overlapping pairs. You
+   could then discard any 00 or 11 pairs found, interpret 01 as a 0 and
+   10 as a 1.  Assume the probability of a 1 is 0.5+e and the
+   probability of a 0 is 0.5-e where e is the eccentricity of the source
+   and described in the previous section.  Then the probability of each
+   pair is as follows:
+
+            +------+-----------------------------------------+
+            | pair |            probability                  |
+            +------+-----------------------------------------+
+            |  00  | (0.5 - e)^2          =  0.25 - e + e^2  |
+            |  01  | (0.5 - e)*(0.5 + e)  =  0.25     - e^2  |
+            |  10  | (0.5 + e)*(0.5 - e)  =  0.25     - e^2  |
+            |  11  | (0.5 + e)^2          =  0.25 + e + e^2  |
+            +------+-----------------------------------------+
+
+   This technique will completely eliminate any bias but at the expense
+   of taking an indeterminate number of input bits for any particular
+   desired number of output bits.  The probability of any particular
+   pair being discarded is 0.5 + 2e^2 so the expected number of input
+   bits to produce X output bits is X/(0.25 - e^2).
+
+
+
+Eastlake, Crocker & Schiller                                   [Page 12]
+
+RFC 1750        Randomness Recommendations for Security    December 1994
+
+
+   This technique assumes that the bits are from a stream where each bit
+   has the same probability of being a 0 or 1 as any other bit in the
+   stream and that bits are not correlated, i.e., that the bits are
+   identical independent distributions.  If alternate bits were from two
+   correlated sources, for example, the above analysis breaks down.
+
+   The above technique also provides another illustration of how a
+   simple statistical analysis can mislead if one is not always on the
+   lookout for patterns that could be exploited by an adversary.  If the
+   algorithm were mis-read slightly so that overlapping successive bits
+   pairs were used instead of non-overlapping pairs, the statistical
+   analysis given is the same; however, instead of provided an unbiased
+   uncorrelated series of random 1's and 0's, it instead produces a
+   totally predictable sequence of exactly alternating 1's and 0's.
+
+5.2.3 Using FFT to De-Skew
+
+   When real world data consists of strongly biased or correlated bits,
+   it may still contain useful amounts of randomness.  This randomness
+   can be extracted through use of the discrete Fourier transform or its
+   optimized variant, the FFT.
+
+   Using the Fourier transform of the data, strong correlations can be
+   discarded.  If adequate data is processed and remaining correlations
+   decay, spectral lines approaching statistical independence and
+   normally distributed randomness can be produced [BRILLINGER].
+
+5.2.4 Using Compression to De-Skew
+
+   Reversible compression techniques also provide a crude method of de-
+   skewing a skewed bit stream.  This follows directly from the
+   definition of reversible compression and the formula in Section 2
+   above for the amount of information in a sequence.  Since the
+   compression is reversible, the same amount of information must be
+   present in the shorter output than was present in the longer input.
+   By the Shannon information equation, this is only possible if, on
+   average, the probabilities of the different shorter sequences are
+   more uniformly distributed than were the probabilities of the longer
+   sequences.  Thus the shorter sequences are de-skewed relative to the
+   input.
+
+   However, many compression techniques add a somewhat predicatable
+   preface to their output stream and may insert such a sequence again
+   periodically in their output or otherwise introduce subtle patterns
+   of their own.  They should be considered only a rough technique
+   compared with those described above or in Section 6.1.2.  At a
+   minimum, the beginning of the compressed sequence should be skipped
+   and only later bits used for applications requiring random bits.
+
+
+
+Eastlake, Crocker & Schiller                                   [Page 13]
+
+RFC 1750        Randomness Recommendations for Security    December 1994
+
+
+5.3 Existing Hardware Can Be Used For Randomness
+
+   As described below, many computers come with hardware that can, with
+   care, be used to generate truly random quantities.
+
+5.3.1 Using Existing Sound/Video Input
+
+   Increasingly computers are being built with inputs that digitize some
+   real world analog source, such as sound from a microphone or video
+   input from a camera.  Under appropriate circumstances, such input can
+   provide reasonably high quality random bits.  The "input" from a
+   sound digitizer with no source plugged in or a camera with the lens
+   cap on, if the system has enough gain to detect anything, is
+   essentially thermal noise.
+
+   For example, on a SPARCstation, one can read from the /dev/audio
+   device with nothing plugged into the microphone jack.  Such data is
+   essentially random noise although it should not be trusted without
+   some checking in case of hardware failure.  It will, in any case,
+   need to be de-skewed as described elsewhere.
+
+   Combining this with compression to de-skew one can, in UNIXese,
+   generate a huge amount of medium quality random data by doing
+
+        cat /dev/audio | compress - >random-bits-file
+
+5.3.2 Using Existing Disk Drives
+
+   Disk drives have small random fluctuations in their rotational speed
+   due to chaotic air turbulence [DAVIS].  By adding low level disk seek
+   time instrumentation to a system, a series of measurements can be
+   obtained that include this randomness. Such data is usually highly
+   correlated so that significant processing is needed, including FFT
+   (see section 5.2.3).  Nevertheless experimentation has shown that,
+   with such processing, disk drives easily produce 100 bits a minute or
+   more of excellent random data.
+
+   Partly offsetting this need for processing is the fact that disk
+   drive failure will normally be rapidly noticed.  Thus, problems with
+   this method of random number generation due to hardware failure are
+   very unlikely.
+
+6. Recommended Non-Hardware Strategy
+
+   What is the best overall strategy for meeting the requirement for
+   unguessable random numbers in the absence of a reliable hardware
+   source?  It is to obtain random input from a large number of
+   uncorrelated sources and to mix them with a strong mixing function.
+
+
+
+Eastlake, Crocker & Schiller                                   [Page 14]
+
+RFC 1750        Randomness Recommendations for Security    December 1994
+
+
+   Such a function will preserve the randomness present in any of the
+   sources even if other quantities being combined are fixed or easily
+   guessable.  This may be advisable even with a good hardware source as
+   hardware can also fail, though this should be weighed against any
+   increase in the chance of overall failure due to added software
+   complexity.
+
+6.1 Mixing Functions
+
+   A strong mixing function is one which combines two or more inputs and
+   produces an output where each output bit is a different complex non-
+   linear function of all the input bits.  On average, changing any
+   input bit will change about half the output bits.  But because the
+   relationship is complex and non-linear, no particular output bit is
+   guaranteed to change when any particular input bit is changed.
+
+   Consider the problem of converting a stream of bits that is skewed
+   towards 0 or 1 to a shorter stream which is more random, as discussed
+   in Section 5.2 above.  This is simply another case where a strong
+   mixing function is desired, mixing the input bits to produce a
+   smaller number of output bits.  The technique given in Section 5.2.1
+   of using the parity of a number of bits is simply the result of
+   successively Exclusive Or'ing them which is examined as a trivial
+   mixing function immediately below.  Use of stronger mixing functions
+   to extract more of the randomness in a stream of skewed bits is
+   examined in Section 6.1.2.
+
+6.1.1 A Trivial Mixing Function
+
+   A trivial example for single bit inputs is the Exclusive Or function,
+   which is equivalent to addition without carry, as show in the table
+   below.  This is a degenerate case in which the one output bit always
+   changes for a change in either input bit.  But, despite its
+   simplicity, it will still provide a useful illustration.
+
+                   +-----------+-----------+----------+
+                   |  input 1  |  input 2  |  output  |
+                   +-----------+-----------+----------+
+                   |     0     |     0     |     0    |
+                   |     0     |     1     |     1    |
+                   |     1     |     0     |     1    |
+                   |     1     |     1     |     0    |
+                   +-----------+-----------+----------+
+
+   If inputs 1 and 2 are uncorrelated and combined in this fashion then
+   the output will be an even better (less skewed) random bit than the
+   inputs.  If we assume an "eccentricity" e as defined in Section 5.2
+   above, then the output eccentricity relates to the input eccentricity
+
+
+
+Eastlake, Crocker & Schiller                                   [Page 15]
+
+RFC 1750        Randomness Recommendations for Security    December 1994
+
+
+   as follows:
+
+        e       = 2 * e        * e
+         output        input 1    input 2
+
+   Since e is never greater than 1/2, the eccentricity is always
+   improved except in the case where at least one input is a totally
+   skewed constant.  This is illustrated in the following table where
+   the top and left side values are the two input eccentricities and the
+   entries are the output eccentricity:
+
+     +--------+--------+--------+--------+--------+--------+--------+
+     |    e   |  0.00  |  0.10  |  0.20  |  0.30  |  0.40  |  0.50  |
+     +--------+--------+--------+--------+--------+--------+--------+
+     |  0.00  |  0.00  |  0.00  |  0.00  |  0.00  |  0.00  |  0.00  |
+     |  0.10  |  0.00  |  0.02  |  0.04  |  0.06  |  0.08  |  0.10  |
+     |  0.20  |  0.00  |  0.04  |  0.08  |  0.12  |  0.16  |  0.20  |
+     |  0.30  |  0.00  |  0.06  |  0.12  |  0.18  |  0.24  |  0.30  |
+     |  0.40  |  0.00  |  0.08  |  0.16  |  0.24  |  0.32  |  0.40  |
+     |  0.50  |  0.00  |  0.10  |  0.20  |  0.30  |  0.40  |  0.50  |
+     +--------+--------+--------+--------+--------+--------+--------+
+
+   However, keep in mind that the above calculations assume that the
+   inputs are not correlated.  If the inputs were, say, the parity of
+   the number of minutes from midnight on two clocks accurate to a few
+   seconds, then each might appear random if sampled at random intervals
+   much longer than a minute.  Yet if they were both sampled and
+   combined with xor, the result would be zero most of the time.
+
+6.1.2 Stronger Mixing Functions
+
+   The US Government Data Encryption Standard [DES] is an example of a
+   strong mixing function for multiple bit quantities.  It takes up to
+   120 bits of input (64 bits of "data" and 56 bits of "key") and
+   produces 64 bits of output each of which is dependent on a complex
+   non-linear function of all input bits.  Other strong encryption
+   functions with this characteristic can also be used by considering
+   them to mix all of their key and data input bits.
+
+   Another good family of mixing functions are the "message digest" or
+   hashing functions such as The US Government Secure Hash Standard
+   [SHS] and the MD2, MD4, MD5 [MD2, MD4, MD5] series.  These functions
+   all take an arbitrary amount of input and produce an output mixing
+   all the input bits. The MD* series produce 128 bits of output and SHS
+   produces 160 bits.
+
+
+
+
+
+
+Eastlake, Crocker & Schiller                                   [Page 16]
+
+RFC 1750        Randomness Recommendations for Security    December 1994
+
+
+   Although the message digest functions are designed for variable
+   amounts of input, DES and other encryption functions can also be used
+   to combine any number of inputs.  If 64 bits of output is adequate,
+   the inputs can be packed into a 64 bit data quantity and successive
+   56 bit keys, padding with zeros if needed, which are then used to
+   successively encrypt using DES in Electronic Codebook Mode [DES
+   MODES].  If more than 64 bits of output are needed, use more complex
+   mixing.  For example, if inputs are packed into three quantities, A,
+   B, and C, use DES to encrypt A with B as a key and then with C as a
+   key to produce the 1st part of the output, then encrypt B with C and
+   then A for more output and, if necessary, encrypt C with A and then B
+   for yet more output.  Still more output can be produced by reversing
+   the order of the keys given above to stretch things. The same can be
+   done with the hash functions by hashing various subsets of the input
+   data to produce multiple outputs.  But keep in mind that it is
+   impossible to get more bits of "randomness" out than are put in.
+
+   An example of using a strong mixing function would be to reconsider
+   the case of a string of 308 bits each of which is biased 99% towards
+   zero.  The parity technique given in Section 5.2.1 above reduced this
+   to one bit with only a 1/1000 deviance from being equally likely a
+   zero or one.  But, applying the equation for information given in
+   Section 2, this 308 bit sequence has 5 bits of information in it.
+   Thus hashing it with SHS or MD5 and taking the bottom 5 bits of the
+   result would yield 5 unbiased random bits as opposed to the single
+   bit given by calculating the parity of the string.
+
+6.1.3 Diffie-Hellman as a Mixing Function
+
+   Diffie-Hellman exponential key exchange is a technique that yields a
+   shared secret between two parties that can be made computationally
+   infeasible for a third party to determine even if they can observe
+   all the messages between the two communicating parties.  This shared
+   secret is a mixture of initial quantities generated by each of them
+   [D-H].  If these initial quantities are random, then the shared
+   secret contains the combined randomness of them both, assuming they
+   are uncorrelated.
+
+6.1.4 Using a Mixing Function to Stretch Random Bits
+
+   While it is not necessary for a mixing function to produce the same
+   or fewer bits than its inputs, mixing bits cannot "stretch" the
+   amount of random unpredictability present in the inputs.  Thus four
+   inputs of 32 bits each where there is 12 bits worth of
+   unpredicatability (such as 4,096 equally probable values) in each
+   input cannot produce more than 48 bits worth of unpredictable output.
+   The output can be expanded to hundreds or thousands of bits by, for
+   example, mixing with successive integers, but the clever adversary's
+
+
+
+Eastlake, Crocker & Schiller                                   [Page 17]
+
+RFC 1750        Randomness Recommendations for Security    December 1994
+
+
+   search space is still 2^48 possibilities.  Furthermore, mixing to
+   fewer bits than are input will tend to strengthen the randomness of
+   the output the way using Exclusive Or to produce one bit from two did
+   above.
+
+   The last table in Section 6.1.1 shows that mixing a random bit with a
+   constant bit with Exclusive Or will produce a random bit.  While this
+   is true, it does not provide a way to "stretch" one random bit into
+   more than one.  If, for example, a random bit is mixed with a 0 and
+   then with a 1, this produces a two bit sequence but it will always be
+   either 01 or 10.  Since there are only two possible values, there is
+   still only the one bit of original randomness.
+
+6.1.5 Other Factors in Choosing a Mixing Function
+
+   For local use, DES has the advantages that it has been widely tested
+   for flaws, is widely documented, and is widely implemented with
+   hardware and software implementations available all over the world
+   including source code available by anonymous FTP.  The SHS and MD*
+   family are younger algorithms which have been less tested but there
+   is no particular reason to believe they are flawed.  Both MD5 and SHS
+   were derived from the earlier MD4 algorithm.  They all have source
+   code available by anonymous FTP [SHS, MD2, MD4, MD5].
+
+   DES and SHS have been vouched for the the US National Security Agency
+   (NSA) on the basis of criteria that primarily remain secret.  While
+   this is the cause of much speculation and doubt, investigation of DES
+   over the years has indicated that NSA involvement in modifications to
+   its design, which originated with IBM, was primarily to strengthen
+   it.  No concealed or special weakness has been found in DES.  It is
+   almost certain that the NSA modification to MD4 to produce the SHS
+   similarly strengthened the algorithm, possibly against threats not
+   yet known in the public cryptographic community.
+
+   DES, SHS, MD4, and MD5 are royalty free for all purposes.  MD2 has
+   been freely licensed only for non-profit use in connection with
+   Privacy Enhanced Mail [PEM].  Between the MD* algorithms, some people
+   believe that, as with "Goldilocks and the Three Bears", MD2 is strong
+   but too slow, MD4 is fast but too weak, and MD5 is just right.
+
+   Another advantage of the MD* or similar hashing algorithms over
+   encryption algorithms is that they are not subject to the same
+   regulations imposed by the US Government prohibiting the unlicensed
+   export or import of encryption/decryption software and hardware.  The
+   same should be true of DES rigged to produce an irreversible hash
+   code but most DES packages are oriented to reversible encryption.
+
+
+
+
+
+Eastlake, Crocker & Schiller                                   [Page 18]
+
+RFC 1750        Randomness Recommendations for Security    December 1994
+
+
+6.2 Non-Hardware Sources of Randomness
+
+   The best source of input for mixing would be a hardware randomness
+   such as disk drive timing affected by air turbulence, audio input
+   with thermal noise, or radioactive decay.  However, if that is not
+   available there are other possibilities.  These include system
+   clocks, system or input/output buffers, user/system/hardware/network
+   serial numbers and/or addresses and timing, and user input.
+   Unfortunately, any of these sources can produce limited or
+   predicatable values under some circumstances.
+
+   Some of the sources listed above would be quite strong on multi-user
+   systems where, in essence, each user of the system is a source of
+   randomness.  However, on a small single user system, such as a
+   typical IBM PC or Apple Macintosh, it might be possible for an
+   adversary to assemble a similar configuration.  This could give the
+   adversary inputs to the mixing process that were sufficiently
+   correlated to those used originally as to make exhaustive search
+   practical.
+
+   The use of multiple random inputs with a strong mixing function is
+   recommended and can overcome weakness in any particular input.  For
+   example, the timing and content of requested "random" user keystrokes
+   can yield hundreds of random bits but conservative assumptions need
+   to be made.  For example, assuming a few bits of randomness if the
+   inter-keystroke interval is unique in the sequence up to that point
+   and a similar assumption if the key hit is unique but assuming that
+   no bits of randomness are present in the initial key value or if the
+   timing or key value duplicate previous values.  The results of mixing
+   these timings and characters typed could be further combined with
+   clock values and other inputs.
+
+   This strategy may make practical portable code to produce good random
+   numbers for security even if some of the inputs are very weak on some
+   of the target systems.  However, it may still fail against a high
+   grade attack on small single user systems, especially if the
+   adversary has ever been able to observe the generation process in the
+   past.  A hardware based random source is still preferable.
+
+6.3 Cryptographically Strong Sequences
+
+   In cases where a series of random quantities must be generated, an
+   adversary may learn some values in the sequence.  In general, they
+   should not be able to predict other values from the ones that they
+   know.
+
+
+
+
+
+
+Eastlake, Crocker & Schiller                                   [Page 19]
+
+RFC 1750        Randomness Recommendations for Security    December 1994
+
+
+   The correct technique is to start with a strong random seed, take
+   cryptographically strong steps from that seed [CRYPTO2, CRYPTO3], and
+   do not reveal the complete state of the generator in the sequence
+   elements.  If each value in the sequence can be calculated in a fixed
+   way from the previous value, then when any value is compromised, all
+   future values can be determined.  This would be the case, for
+   example, if each value were a constant function of the previously
+   used values, even if the function were a very strong, non-invertible
+   message digest function.
+
+   It should be noted that if your technique for generating a sequence
+   of key values is fast enough, it can trivially be used as the basis
+   for a confidentiality system.  If two parties use the same sequence
+   generating technique and start with the same seed material, they will
+   generate identical sequences.  These could, for example, be xor'ed at
+   one end with data being send, encrypting it, and xor'ed with this
+   data as received, decrypting it due to the reversible properties of
+   the xor operation.
+
+6.3.1 Traditional Strong Sequences
+
+   A traditional way to achieve a strong sequence has been to have the
+   values be produced by hashing the quantities produced by
+   concatenating the seed with successive integers or the like and then
+   mask the values obtained so as to limit the amount of generator state
+   available to the adversary.
+
+   It may also be possible to use an "encryption" algorithm with a
+   random key and seed value to encrypt and feedback some or all of the
+   output encrypted value into the value to be encrypted for the next
+   iteration.  Appropriate feedback techniques will usually be
+   recommended with the encryption algorithm.  An example is shown below
+   where shifting and masking are used to combine the cypher output
+   feedback.  This type of feedback is recommended by the US Government
+   in connection with DES [DES MODES].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake, Crocker & Schiller                                   [Page 20]
+
+RFC 1750        Randomness Recommendations for Security    December 1994
+
+
+      +---------------+
+      |       V       |
+      |  |     n      |
+      +--+------------+
+            |      |           +---------+
+            |      +---------> |         |      +-----+
+         +--+                  | Encrypt | <--- | Key |
+         |           +-------- |         |      +-----+
+         |           |         +---------+
+         V           V
+      +------------+--+
+      |      V     |  |
+      |       n+1     |
+      +---------------+
+
+   Note that if a shift of one is used, this is the same as the shift
+   register technique described in Section 3 above but with the all
+   important difference that the feedback is determined by a complex
+   non-linear function of all bits rather than a simple linear or
+   polynomial combination of output from a few bit position taps.
+
+   It has been shown by Donald W. Davies that this sort of shifted
+   partial output feedback significantly weakens an algorithm compared
+   will feeding all of the output bits back as input.  In particular,
+   for DES, repeated encrypting a full 64 bit quantity will give an
+   expected repeat in about 2^63 iterations.  Feeding back anything less
+   than 64 (and more than 0) bits will give an expected repeat in
+   between 2**31 and 2**32 iterations!
+
+   To predict values of a sequence from others when the sequence was
+   generated by these techniques is equivalent to breaking the
+   cryptosystem or inverting the "non-invertible" hashing involved with
+   only partial information available.  The less information revealed
+   each iteration, the harder it will be for an adversary to predict the
+   sequence.  Thus it is best to use only one bit from each value.  It
+   has been shown that in some cases this makes it impossible to break a
+   system even when the cryptographic system is invertible and can be
+   broken if all of each generated value was revealed.
+
+6.3.2 The Blum Blum Shub Sequence Generator
+
+   Currently the generator which has the strongest public proof of
+   strength is called the Blum Blum Shub generator after its inventors
+   [BBS].  It is also very simple and is based on quadratic residues.
+   It's only disadvantage is that is is computationally intensive
+   compared with the traditional techniques give in 6.3.1 above.  This
+   is not a serious draw back if it is used for moderately infrequent
+   purposes, such as generating session keys.
+
+
+
+Eastlake, Crocker & Schiller                                   [Page 21]
+
+RFC 1750        Randomness Recommendations for Security    December 1994
+
+
+   Simply choose two large prime numbers, say p and q, which both have
+   the property that you get a remainder of 3 if you divide them by 4.
+   Let n = p * q.  Then you choose a random number x relatively prime to
+   n.  The initial seed for the generator and the method for calculating
+   subsequent values are then
+
+                   2
+        s    =  ( x  )(Mod n)
+         0
+
+                   2
+        s    = ( s   )(Mod n)
+         i+1      i
+
+   You must be careful to use only a few bits from the bottom of each s.
+   It is always safe to use only the lowest order bit.  If you use no
+   more than the
+
+                  log  ( log  ( s  ) )
+                     2      2    i
+
+   low order bits, then predicting any additional bits from a sequence
+   generated in this manner is provable as hard as factoring n.  As long
+   as the initial x is secret, you can even make n public if you want.
+
+   An intersting characteristic of this generator is that you can
+   directly calculate any of the s values.  In particular
+
+                     i
+               ( ( 2  )(Mod (( p - 1 ) * ( q - 1 )) ) )
+      s  = ( s                                          )(Mod n)
+       i      0
+
+   This means that in applications where many keys are generated in this
+   fashion, it is not necessary to save them all.  Each key can be
+   effectively indexed and recovered from that small index and the
+   initial s and n.
+
+7. Key Generation Standards
+
+   Several public standards are now in place for the generation of keys.
+   Two of these are described below.  Both use DES but any equally
+   strong or stronger mixing function could be substituted.
+
+
+
+
+
+
+
+
+Eastlake, Crocker & Schiller                                   [Page 22]
+
+RFC 1750        Randomness Recommendations for Security    December 1994
+
+
+7.1 US DoD Recommendations for Password Generation
+
+   The United States Department of Defense has specific recommendations
+   for password generation [DoD].  They suggest using the US Data
+   Encryption Standard [DES] in Output Feedback Mode [DES MODES] as
+   follows:
+
+        use an initialization vector determined from
+             the system clock,
+             system ID,
+             user ID, and
+             date and time;
+        use a key determined from
+             system interrupt registers,
+             system status registers, and
+             system counters; and,
+        as plain text, use an external randomly generated 64 bit
+        quantity such as 8 characters typed in by a system
+        administrator.
+
+   The password can then be calculated from the 64 bit "cipher text"
+   generated in 64-bit Output Feedback Mode.  As many bits as are needed
+   can be taken from these 64 bits and expanded into a pronounceable
+   word, phrase, or other format if a human being needs to remember the
+   password.
+
+7.2 X9.17 Key Generation
+
+   The American National Standards Institute has specified a method for
+   generating a sequence of keys as follows:
+
+        s  is the initial 64 bit seed
+         0
+
+        g  is the sequence of generated 64 bit key quantities
+         n
+
+        k is a random key reserved for generating this key sequence
+
+        t is the time at which a key is generated to as fine a resolution
+            as is available (up to 64 bits).
+
+        DES ( K, Q ) is the DES encryption of quantity Q with key K
+
+
+
+
+
+
+
+
+Eastlake, Crocker & Schiller                                   [Page 23]
+
+RFC 1750        Randomness Recommendations for Security    December 1994
+
+
+        g    = DES ( k, DES ( k, t ) .xor. s  )
+         n                                  n
+
+        s    = DES ( k, DES ( k, t ) .xor. g  )
+         n+1                                n
+
+   If g sub n is to be used as a DES key, then every eighth bit should
+   be adjusted for parity for that use but the entire 64 bit unmodified
+   g should be used in calculating the next s.
+
+8. Examples of Randomness Required
+
+   Below are two examples showing rough calculations of needed
+   randomness for security.  The first is for moderate security
+   passwords while the second assumes a need for a very high security
+   cryptographic key.
+
+8.1  Password Generation
+
+   Assume that user passwords change once a year and it is desired that
+   the probability that an adversary could guess the password for a
+   particular account be less than one in a thousand.  Further assume
+   that sending a password to the system is the only way to try a
+   password.  Then the crucial question is how often an adversary can
+   try possibilities.  Assume that delays have been introduced into a
+   system so that, at most, an adversary can make one password try every
+   six seconds.  That's 600 per hour or about 15,000 per day or about
+   5,000,000 tries in a year.  Assuming any sort of monitoring, it is
+   unlikely someone could actually try continuously for a year.  In
+   fact, even if log files are only checked monthly, 500,000 tries is
+   more plausible before the attack is noticed and steps taken to change
+   passwords and make it harder to try more passwords.
+
+   To have a one in a thousand chance of guessing the password in
+   500,000 tries implies a universe of at least 500,000,000 passwords or
+   about 2^29.  Thus 29 bits of randomness are needed. This can probably
+   be achieved using the US DoD recommended inputs for password
+   generation as it has 8 inputs which probably average over 5 bits of
+   randomness each (see section 7.1).  Using a list of 1000 words, the
+   password could be expressed as a three word phrase (1,000,000,000
+   possibilities) or, using case insensitive letters and digits, six
+   would suffice ((26+10)^6 = 2,176,782,336 possibilities).
+
+   For a higher security password, the number of bits required goes up.
+   To decrease the probability by 1,000 requires increasing the universe
+   of passwords by the same factor which adds about 10 bits.  Thus to
+   have only a one in a million chance of a password being guessed under
+   the above scenario would require 39 bits of randomness and a password
+
+
+
+Eastlake, Crocker & Schiller                                   [Page 24]
+
+RFC 1750        Randomness Recommendations for Security    December 1994
+
+
+   that was a four word phrase from a 1000 word list or eight
+   letters/digits.  To go to a one in 10^9 chance, 49 bits of randomness
+   are needed implying a five word phrase or ten letter/digit password.
+
+   In a real system, of course, there are also other factors.  For
+   example, the larger and harder to remember passwords are, the more
+   likely users are to write them down resulting in an additional risk
+   of compromise.
+
+8.2 A Very High Security Cryptographic Key
+
+   Assume that a very high security key is needed for symmetric
+   encryption / decryption between two parties.  Assume an adversary can
+   observe communications and knows the algorithm being used.  Within
+   the field of random possibilities, the adversary can try key values
+   in hopes of finding the one in use.  Assume further that brute force
+   trial of keys is the best the adversary can do.
+
+8.2.1 Effort per Key Trial
+
+   How much effort will it take to try each key?  For very high security
+   applications it is best to assume a low value of effort.  Even if it
+   would clearly take tens of thousands of computer cycles or more to
+   try a single key, there may be some pattern that enables huge blocks
+   of key values to be tested with much less effort per key.  Thus it is
+   probably best to assume no more than a couple hundred cycles per key.
+   (There is no clear lower bound on this as computers operate in
+   parallel on a number of bits and a poor encryption algorithm could
+   allow many keys or even groups of keys to be tested in parallel.
+   However, we need to assume some value and can hope that a reasonably
+   strong algorithm has been chosen for our hypothetical high security
+   task.)
+
+   If the adversary can command a highly parallel processor or a large
+   network of work stations, 2*10^10 cycles per second is probably a
+   minimum assumption for availability today.  Looking forward just a
+   couple years, there should be at least an order of magnitude
+   improvement.  Thus assuming 10^9 keys could be checked per second or
+   3.6*10^11 per hour or 6*10^13 per week or 2.4*10^14 per month is
+   reasonable.  This implies a need for a minimum of 51 bits of
+   randomness in keys to be sure they cannot be found in a month.  Even
+   then it is possible that, a few years from now, a highly determined
+   and resourceful adversary could break the key in 2 weeks (on average
+   they need try only half the keys).
+
+
+
+
+
+
+
+Eastlake, Crocker & Schiller                                   [Page 25]
+
+RFC 1750        Randomness Recommendations for Security    December 1994
+
+
+8.2.2 Meet in the Middle Attacks
+
+   If chosen or known plain text and the resulting encrypted text are
+   available, a "meet in the middle" attack is possible if the structure
+   of the encryption algorithm allows it.  (In a known plain text
+   attack, the adversary knows all or part of the messages being
+   encrypted, possibly some standard header or trailer fields.  In a
+   chosen plain text attack, the adversary can force some chosen plain
+   text to be encrypted, possibly by "leaking" an exciting text that
+   would then be sent by the adversary over an encrypted channel.)
+
+   An oversimplified explanation of the meet in the middle attack is as
+   follows: the adversary can half-encrypt the known or chosen plain
+   text with all possible first half-keys, sort the output, then half-
+   decrypt the encoded text with all the second half-keys.  If a match
+   is found, the full key can be assembled from the halves and used to
+   decrypt other parts of the message or other messages.  At its best,
+   this type of attack can halve the exponent of the work required by
+   the adversary while adding a large but roughly constant factor of
+   effort.  To be assured of safety against this, a doubling of the
+   amount of randomness in the key to a minimum of 102 bits is required.
+
+   The meet in the middle attack assumes that the cryptographic
+   algorithm can be decomposed in this way but we can not rule that out
+   without a deep knowledge of the algorithm.  Even if a basic algorithm
+   is not subject to a meet in the middle attack, an attempt to produce
+   a stronger algorithm by applying the basic algorithm twice (or two
+   different algorithms sequentially) with different keys may gain less
+   added security than would be expected.  Such a composite algorithm
+   would be subject to a meet in the middle attack.
+
+   Enormous resources may be required to mount a meet in the middle
+   attack but they are probably within the range of the national
+   security services of a major nation.  Essentially all nations spy on
+   other nations government traffic and several nations are believed to
+   spy on commercial traffic for economic advantage.
+
+8.2.3 Other Considerations
+
+   Since we have not even considered the possibilities of special
+   purpose code breaking hardware or just how much of a safety margin we
+   want beyond our assumptions above, probably a good minimum for a very
+   high security cryptographic key is 128 bits of randomness which
+   implies a minimum key length of 128 bits.  If the two parties agree
+   on a key by Diffie-Hellman exchange [D-H], then in principle only
+   half of this randomness would have to be supplied by each party.
+   However, there is probably some correlation between their random
+   inputs so it is probably best to assume that each party needs to
+
+
+
+Eastlake, Crocker & Schiller                                   [Page 26]
+
+RFC 1750        Randomness Recommendations for Security    December 1994
+
+
+   provide at least 96 bits worth of randomness for very high security
+   if Diffie-Hellman is used.
+
+   This amount of randomness is beyond the limit of that in the inputs
+   recommended by the US DoD for password generation and could require
+   user typing timing, hardware random number generation, or other
+   sources.
+
+   It should be noted that key length calculations such at those above
+   are controversial and depend on various assumptions about the
+   cryptographic algorithms in use.  In some cases, a professional with
+   a deep knowledge of code breaking techniques and of the strength of
+   the algorithm in use could be satisfied with less than half of the
+   key size derived above.
+
+9. Conclusion
+
+   Generation of unguessable "random" secret quantities for security use
+   is an essential but difficult task.
+
+   We have shown that hardware techniques to produce such randomness
+   would be relatively simple.  In particular, the volume and quality
+   would not need to be high and existing computer hardware, such as
+   disk drives, can be used.  Computational techniques are available to
+   process low quality random quantities from multiple sources or a
+   larger quantity of such low quality input from one source and produce
+   a smaller quantity of higher quality, less predictable key material.
+   In the absence of hardware sources of randomness, a variety of user
+   and software sources can frequently be used instead with care;
+   however, most modern systems already have hardware, such as disk
+   drives or audio input, that could be used to produce high quality
+   randomness.
+
+   Once a sufficient quantity of high quality seed key material (a few
+   hundred bits) is available, strong computational techniques are
+   available to produce cryptographically strong sequences of
+   unpredicatable quantities from this seed material.
+
+10. Security Considerations
+
+   The entirety of this document concerns techniques and recommendations
+   for generating unguessable "random" quantities for use as passwords,
+   cryptographic keys, and similar security uses.
+
+
+
+
+
+
+
+
+Eastlake, Crocker & Schiller                                   [Page 27]
+
+RFC 1750        Randomness Recommendations for Security    December 1994
+
+
+References
+
+   [ASYMMETRIC] - Secure Communications and Asymmetric Cryptosystems,
+   edited by Gustavus J. Simmons, AAAS Selected Symposium 69, Westview
+   Press, Inc.
+
+   [BBS] - A Simple Unpredictable Pseudo-Random Number Generator, SIAM
+   Journal on Computing, v. 15, n. 2, 1986, L. Blum, M. Blum, & M. Shub.
+
+   [BRILLINGER] - Time Series: Data Analysis and Theory, Holden-Day,
+   1981, David Brillinger.
+
+   [CRC] - C.R.C. Standard Mathematical Tables, Chemical Rubber
+   Publishing Company.
+
+   [CRYPTO1] - Cryptography: A Primer, A Wiley-Interscience Publication,
+   John Wiley & Sons, 1981, Alan G. Konheim.
+
+   [CRYPTO2] - Cryptography:  A New Dimension in Computer Data Security,
+   A Wiley-Interscience Publication, John Wiley & Sons, 1982, Carl H.
+   Meyer & Stephen M. Matyas.
+
+   [CRYPTO3] - Applied Cryptography: Protocols, Algorithms, and Source
+   Code in C, John Wiley & Sons, 1994, Bruce Schneier.
+
+   [DAVIS] - Cryptographic Randomness from Air Turbulence in Disk
+   Drives, Advances in Cryptology - Crypto '94, Springer-Verlag Lecture
+   Notes in Computer Science #839, 1984, Don Davis, Ross Ihaka, and
+   Philip Fenstermacher.
+
+   [DES] -  Data Encryption Standard, United States of America,
+   Department of Commerce, National Institute of Standards and
+   Technology, Federal Information Processing Standard (FIPS) 46-1.
+   - Data Encryption Algorithm, American National Standards Institute,
+   ANSI X3.92-1981.
+   (See also FIPS 112, Password Usage, which includes FORTRAN code for
+   performing DES.)
+
+   [DES MODES] - DES Modes of Operation, United States of America,
+   Department of Commerce, National Institute of Standards and
+   Technology, Federal Information Processing Standard (FIPS) 81.
+   - Data Encryption Algorithm - Modes of Operation, American National
+   Standards Institute, ANSI X3.106-1983.
+
+   [D-H] - New Directions in Cryptography, IEEE Transactions on
+   Information Technology, November, 1976, Whitfield Diffie and Martin
+   E. Hellman.
+
+
+
+
+Eastlake, Crocker & Schiller                                   [Page 28]
+
+RFC 1750        Randomness Recommendations for Security    December 1994
+
+
+   [DoD] - Password Management Guideline, United States of America,
+   Department of Defense, Computer Security Center, CSC-STD-002-85.
+   (See also FIPS 112, Password Usage, which incorporates CSC-STD-002-85
+   as one of its appendices.)
+
+   [GIFFORD] - Natural Random Number, MIT/LCS/TM-371, September 1988,
+   David K. Gifford
+
+   [KNUTH] - The Art of Computer Programming, Volume 2: Seminumerical
+   Algorithms, Chapter 3: Random Numbers. Addison Wesley Publishing
+   Company, Second Edition 1982, Donald E. Knuth.
+
+   [KRAWCZYK] - How to Predict Congruential Generators, Journal of
+   Algorithms, V. 13, N. 4, December 1992, H. Krawczyk
+
+   [MD2] - The MD2 Message-Digest Algorithm, RFC1319, April 1992, B.
+   Kaliski
+   [MD4] - The MD4 Message-Digest Algorithm, RFC1320, April 1992, R.
+   Rivest
+   [MD5] - The MD5 Message-Digest Algorithm, RFC1321, April 1992, R.
+   Rivest
+
+   [PEM] - RFCs 1421 through 1424:
+   - RFC 1424, Privacy Enhancement for Internet Electronic Mail: Part
+   IV: Key Certification and Related Services, 02/10/1993, B. Kaliski
+   - RFC 1423, Privacy Enhancement for Internet Electronic Mail: Part
+   III: Algorithms, Modes, and Identifiers, 02/10/1993, D. Balenson
+   - RFC 1422, Privacy Enhancement for Internet Electronic Mail: Part
+   II: Certificate-Based Key Management, 02/10/1993, S. Kent
+   - RFC 1421, Privacy Enhancement for Internet Electronic Mail: Part I:
+   Message Encryption and Authentication Procedures, 02/10/1993, J. Linn
+
+   [SHANNON] - The Mathematical Theory of Communication, University of
+   Illinois Press, 1963, Claude E. Shannon.  (originally from:  Bell
+   System Technical Journal, July and October 1948)
+
+   [SHIFT1] - Shift Register Sequences, Aegean Park Press, Revised
+   Edition 1982, Solomon W. Golomb.
+
+   [SHIFT2] - Cryptanalysis of Shift-Register Generated Stream Cypher
+   Systems, Aegean Park Press, 1984, Wayne G. Barker.
+
+   [SHS] - Secure Hash Standard, United States of American, National
+   Institute of Science and Technology, Federal Information Processing
+   Standard (FIPS) 180, April 1993.
+
+   [STERN] - Secret Linear Congruential Generators are not
+   Cryptograhically Secure, Proceedings of IEEE STOC, 1987, J. Stern.
+
+
+
+Eastlake, Crocker & Schiller                                   [Page 29]
+
+RFC 1750        Randomness Recommendations for Security    December 1994
+
+
+   [VON NEUMANN] - Various techniques used in connection with random
+   digits, von Neumann's Collected Works, Vol. 5, Pergamon Press, 1963,
+   J. von Neumann.
+
+Authors' Addresses
+
+   Donald E. Eastlake 3rd
+   Digital Equipment Corporation
+   550 King Street, LKG2-1/BB3
+   Littleton, MA 01460
+
+   Phone:   +1 508 486 6577(w)  +1 508 287 4877(h)
+   EMail:   dee@lkg.dec.com
+
+
+   Stephen D. Crocker
+   CyberCash Inc.
+   2086 Hunters Crest Way
+   Vienna, VA 22181
+
+   Phone:   +1 703-620-1222(w)  +1 703-391-2651 (fax)
+   EMail:   crocker@cybercash.com
+
+
+   Jeffrey I. Schiller
+   Massachusetts Institute of Technology
+   77 Massachusetts Avenue
+   Cambridge, MA 02139
+
+   Phone:   +1 617 253 0161(w)
+   EMail:   jis@mit.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake, Crocker & Schiller                                   [Page 30]
+
diff --git a/doc/rfc/rfc1876.txt b/doc/rfc/rfc1876.txt
new file mode 100644
index 0000000..a289cff
--- /dev/null
+++ b/doc/rfc/rfc1876.txt
@@ -0,0 +1,1011 @@
+
+
+
+
+
+
+Network Working Group                                           C. Davis
+Request for Comments: 1876                             Kapor Enterprises
+Updates: 1034, 1035                                             P. Vixie
+Category: Experimental                                 Vixie Enterprises
+                                                              T. Goodwin
+                                                            FORE Systems
+                                                            I. Dickinson
+                                                   University of Warwick
+                                                            January 1996
+
+
+ A Means for Expressing Location Information in the Domain Name System
+
+Status of this Memo
+
+   This memo defines an Experimental Protocol for the Internet
+   community.  This memo does not specify an Internet standard of any
+   kind.  Discussion and suggestions for improvement are requested.
+   Distribution of this memo is unlimited.
+
+1. Abstract
+
+   This memo defines a new DNS RR type for experimental purposes.  This
+   RFC describes a mechanism to allow the DNS to carry location
+   information about hosts, networks, and subnets.  Such information for
+   a small subset of hosts is currently contained in the flat-file UUCP
+   maps.  However, just as the DNS replaced the use of HOSTS.TXT to
+   carry host and network address information, it is possible to replace
+   the UUCP maps as carriers of location information.
+
+   This RFC defines the format of a new Resource Record (RR) for the
+   Domain Name System (DNS), and reserves a corresponding DNS type
+   mnemonic (LOC) and numerical code (29).
+
+   This RFC assumes that the reader is familiar with the DNS [RFC 1034,
+   RFC 1035].  The data shown in our examples is for pedagogical use and
+   does not necessarily reflect the real Internet.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Davis, et al                  Experimental                      [Page 1]
+
+RFC 1876            Location Information in the DNS         January 1996
+
+
+2. RDATA Format
+
+       MSB                                           LSB
+       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+      0|        VERSION        |         SIZE          |
+       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+      2|       HORIZ PRE       |       VERT PRE        |
+       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+      4|                   LATITUDE                    |
+       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+      6|                   LATITUDE                    |
+       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+      8|                   LONGITUDE                   |
+       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+     10|                   LONGITUDE                   |
+       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+     12|                   ALTITUDE                    |
+       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+     14|                   ALTITUDE                    |
+       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+   (octet)
+
+where:
+
+VERSION      Version number of the representation.  This must be zero.
+             Implementations are required to check this field and make
+             no assumptions about the format of unrecognized versions.
+
+SIZE         The diameter of a sphere enclosing the described entity, in
+             centimeters, expressed as a pair of four-bit unsigned
+             integers, each ranging from zero to nine, with the most
+             significant four bits representing the base and the second
+             number representing the power of ten by which to multiply
+             the base.  This allows sizes from 0e0 (<1cm) to 9e9
+             (90,000km) to be expressed.  This representation was chosen
+             such that the hexadecimal representation can be read by
+             eye; 0x15 = 1e5.  Four-bit values greater than 9 are
+             undefined, as are values with a base of zero and a non-zero
+             exponent.
+
+             Since 20000000m (represented by the value 0x29) is greater
+             than the equatorial diameter of the WGS 84 ellipsoid
+             (12756274m), it is therefore suitable for use as a
+             "worldwide" size.
+
+HORIZ PRE    The horizontal precision of the data, in centimeters,
+             expressed using the same representation as SIZE.  This is
+             the diameter of the horizontal "circle of error", rather
+
+
+
+Davis, et al                  Experimental                      [Page 2]
+
+RFC 1876            Location Information in the DNS         January 1996
+
+
+             than a "plus or minus" value.  (This was chosen to match
+             the interpretation of SIZE; to get a "plus or minus" value,
+             divide by 2.)
+
+VERT PRE     The vertical precision of the data, in centimeters,
+             expressed using the sane representation as for SIZE.  This
+             is the total potential vertical error, rather than a "plus
+             or minus" value.  (This was chosen to match the
+             interpretation of SIZE; to get a "plus or minus" value,
+             divide by 2.)  Note that if altitude above or below sea
+             level is used as an approximation for altitude relative to
+             the [WGS 84] ellipsoid, the precision value should be
+             adjusted.
+
+LATITUDE     The latitude of the center of the sphere described by the
+             SIZE field, expressed as a 32-bit integer, most significant
+             octet first (network standard byte order), in thousandths
+             of a second of arc.  2^31 represents the equator; numbers
+             above that are north latitude.
+
+LONGITUDE    The longitude of the center of the sphere described by the
+             SIZE field, expressed as a 32-bit integer, most significant
+             octet first (network standard byte order), in thousandths
+             of a second of arc, rounded away from the prime meridian.
+             2^31 represents the prime meridian; numbers above that are
+             east longitude.
+
+ALTITUDE     The altitude of the center of the sphere described by the
+             SIZE field, expressed as a 32-bit integer, most significant
+             octet first (network standard byte order), in centimeters,
+             from a base of 100,000m below the [WGS 84] reference
+             spheroid used by GPS (semimajor axis a=6378137.0,
+             reciprocal flattening rf=298.257223563).  Altitude above
+             (or below) sea level may be used as an approximation of
+             altitude relative to the the [WGS 84] spheroid, though due
+             to the Earth's surface not being a perfect spheroid, there
+             will be differences.  (For example, the geoid (which sea
+             level approximates) for the continental US ranges from 10
+             meters to 50 meters below the [WGS 84] spheroid.
+             Adjustments to ALTITUDE and/or VERT PRE will be necessary
+             in most cases.  The Defense Mapping Agency publishes geoid
+             height values relative to the [WGS 84] ellipsoid.
+
+
+
+
+
+
+
+
+
+Davis, et al                  Experimental                      [Page 3]
+
+RFC 1876            Location Information in the DNS         January 1996
+
+
+3. Master File Format
+
+   The LOC record is expressed in a master file in the following format:
+
+   <owner> <TTL> <class> LOC ( d1 [m1 [s1]] {"N"|"S"} d2 [m2 [s2]]
+                               {"E"|"W"} alt["m"] [siz["m"] [hp["m"]
+                               [vp["m"]]]] )
+
+   (The parentheses are used for multi-line data as specified in [RFC
+   1035] section 5.1.)
+
+   where:
+
+       d1:     [0 .. 90]            (degrees latitude)
+       d2:     [0 .. 180]           (degrees longitude)
+       m1, m2: [0 .. 59]            (minutes latitude/longitude)
+       s1, s2: [0 .. 59.999]        (seconds latitude/longitude)
+       alt:    [-100000.00 .. 42849672.95] BY .01 (altitude in meters)
+       siz, hp, vp: [0 .. 90000000.00] (size/precision in meters)
+
+   If omitted, minutes and seconds default to zero, size defaults to 1m,
+   horizontal precision defaults to 10000m, and vertical precision
+   defaults to 10m.  These defaults are chosen to represent typical
+   ZIP/postal code area sizes, since it is often easy to find
+   approximate geographical location by ZIP/postal code.
+
+4. Example Data
+
+;;;
+;;; note that these data would not all appear in one zone file
+;;;
+
+;; network LOC RR derived from ZIP data.  note use of precision defaults
+cambridge-net.kei.com.        LOC   42 21 54 N 71 06 18 W -24m 30m
+
+;; higher-precision host LOC RR.  note use of vertical precision default
+loiosh.kei.com.               LOC   42 21 43.952 N 71 5 6.344 W
+                                    -24m 1m 200m
+
+pipex.net.                    LOC   52 14 05 N 00 08 50 E 10m
+
+curtin.edu.au.                LOC   32 7 19 S 116 2 25 E 10m
+
+rwy04L.logan-airport.boston.  LOC   42 21 28.764 N 71 00 51.617 W
+                                    -44m 2000m
+
+
+
+
+
+
+Davis, et al                  Experimental                      [Page 4]
+
+RFC 1876            Location Information in the DNS         January 1996
+
+
+5. Application use of the LOC RR
+
+5.1 Suggested Uses
+
+   Some uses for the LOC RR have already been suggested, including the
+   USENET backbone flow maps, a "visual traceroute" application showing
+   the geographical path of an IP packet, and network management
+   applications that could use LOC RRs to generate a map of hosts and
+   routers being managed.
+
+5.2 Search Algorithms
+
+   This section specifies how to use the DNS to translate domain names
+   and/or IP addresses into location information.
+
+   If an application wishes to have a "fallback" behavior, displaying a
+   less precise or larger area when a host does not have an associated
+   LOC RR, it MAY support use of the algorithm in section 5.2.3, as
+   noted in sections 5.2.1 and 5.2.2.  If fallback is desired, this
+   behaviour is the RECOMMENDED default, but in some cases it may need
+   to be modified based on the specific requirements of the application
+   involved.
+
+   This search algorithm is designed to allow network administrators to
+   specify the location of a network or subnet without requiring LOC RR
+   data for each individual host.  For example, a computer lab with 24
+   workstations, all of which are on the same subnet and in basically
+   the same location, would only need a LOC RR for the subnet.
+   (However, if the file server's location has been more precisely
+   measured, a separate LOC RR for it can be placed in the DNS.)
+
+5.2.1 Searching by Name
+
+   If the application is beginning with a name, rather than an IP
+   address (as the USENET backbone flow maps do), it MUST check for a
+   LOC RR associated with that name.  (CNAME records should be followed
+   as for any other RR type.)
+
+   If there is no LOC RR for that name, all A records (if any)
+   associated with the name MAY be checked for network (or subnet) LOC
+   RRs using the "Searching by Network or Subnet" algorithm (5.2.3).  If
+   multiple A records exist and have associated network or subnet LOC
+   RRs, the application may choose to use any, some, or all of the LOC
+   RRs found, possibly in combination.  It is suggested that multi-homed
+   hosts have LOC RRs for their name in the DNS to avoid any ambiguity
+   in these cases.
+
+
+
+
+
+Davis, et al                  Experimental                      [Page 5]
+
+RFC 1876            Location Information in the DNS         January 1996
+
+
+   Note that domain names that do not have associated A records must
+   have a LOC RR associated with their name in order for location
+   information to be accessible.
+
+5.2.2 Searching by Address
+
+   If the application is beginning with an IP address (as a "visual
+   traceroute" application might be) it MUST first map the address to a
+   name using the IN-ADDR.ARPA namespace (see [RFC 1034], section
+   5.2.1), then check for a LOC RR associated with that name.
+
+   If there is no LOC RR for the name, the address MAY be checked for
+   network (or subnet) LOC RRs using the "Searching by Network or
+   Subnet" algorithm (5.2.3).
+
+5.2.3 Searching by Network or Subnet
+
+   Even if a host's name does not have any associated LOC RRs, the
+   network(s) or subnet(s) it is on may.  If the application wishes to
+   search for such less specific data, the following algorithm SHOULD be
+   followed to find a network or subnet LOC RR associated with the IP
+   address.  This algorithm is adapted slightly from that specified in
+   [RFC 1101], sections 4.3 and 4.4.
+
+   Since subnet LOC RRs are (if present) more specific than network LOC
+   RRs, it is best to use them if available.  In order to do so, we
+   build a stack of network and subnet names found while performing the
+   [RFC 1101] search, then work our way down the stack until a LOC RR is
+   found.
+
+   1. create a host-zero address using the network portion of the IP
+      address (one, two, or three bytes for class A, B, or C networks,
+      respectively).  For example, for the host 128.9.2.17, on the class
+      B network 128.9, this would result in the address "128.9.0.0".
+
+   2. Reverse the octets, suffix IN-ADDR.ARPA, and query for PTR and A
+      records.  Retrieve:
+
+               0.0.9.128.IN-ADDR.ARPA.  PTR    isi-net.isi.edu.
+                                        A      255.255.255.0
+
+      Push the name "isi-net.isi.edu" onto the stack of names to be
+      searched for LOC RRs later.
+
+
+
+
+
+
+
+
+Davis, et al                  Experimental                      [Page 6]
+
+RFC 1876            Location Information in the DNS         January 1996
+
+
+   3. Since an A RR was found, repeat using mask from RR
+      (255.255.255.0), constructing a query for 0.2.9.128.IN-ADDR.ARPA.
+      Retrieve:
+
+               0.2.9.128.IN-ADDR.ARPA.  PTR    div2-subnet.isi.edu.
+                                        A      255.255.255.240
+
+      Push the name "div2-subnet.isi.edu" onto the stack of names to be
+      searched for LOC RRs later.
+
+   4. Since another A RR was found, repeat using mask 255.255.255.240
+      (x'FFFFFFF0'), constructing a query for 16.2.9.128.IN-ADDR.ARPA.
+      Retrieve:
+
+               16.2.9.128.IN-ADDR.ARPA. PTR    inc-subsubnet.isi.edu.
+
+      Push the name "inc-subsubnet.isi.edu" onto the stack of names to
+      be searched for LOC RRs later.
+
+   5. Since no A RR is present at 16.2.9.128.IN-ADDR.ARPA., there are no
+      more subnet levels to search.  We now pop the top name from the
+      stack and check for an associated LOC RR.  Repeat until a LOC RR
+      is found.
+
+      In this case, assume that inc-subsubnet.isi.edu does not have an
+      associated LOC RR, but that div2-subnet.isi.edu does.  We will
+      then use div2-subnet.isi.edu's LOC RR as an approximation of this
+      host's location.  (Note that even if isi-net.isi.edu has a LOC RR,
+      it will not be used if a subnet also has a LOC RR.)
+
+5.3 Applicability to non-IN Classes and non-IP Addresses
+
+   The LOC record is defined for all RR classes, and may be used with
+   non-IN classes such as HS and CH.  The semantics of such use are not
+   defined by this memo.
+
+   The search algorithm in section 5.2.3 may be adapted to other
+   addressing schemes by extending [RFC 1101]'s encoding of network
+   names to cover those schemes.  Such extensions are not defined by
+   this memo.
+
+
+
+
+
+
+
+
+
+
+
+Davis, et al                  Experimental                      [Page 7]
+
+RFC 1876            Location Information in the DNS         January 1996
+
+
+6. References
+
+   [RFC 1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
+              STD 13, RFC 1034, USC/Information Sciences Institute,
+              November 1987.
+
+   [RFC 1035] Mockapetris, P., "Domain Names - Implementation and
+              Specification", STD 13, RFC 1035, USC/Information Sciences
+              Institute, November 1987.
+
+   [RFC 1101] Mockapetris, P., "DNS Encoding of Network Names and Other
+              Types", RFC 1101, USC/Information Sciences Institute,
+              April 1989.
+
+   [WGS 84] United States Department of Defense; DoD WGS-1984 - Its
+            Definition and Relationships with Local Geodetic Systems;
+            Washington, D.C.; 1985; Report AD-A188 815 DMA; 6127; 7-R-
+            138-R; CV, KV;
+
+7. Security Considerations
+
+   High-precision LOC RR information could be used to plan a penetration
+   of physical security, leading to potential denial-of-machine attacks.
+   To avoid any appearance of suggesting this method to potential
+   attackers, we declined the opportunity to name this RR "ICBM".
+
+8. Authors' Addresses
+
+   The authors as a group can be reached as <loc@pipex.net>.
+
+   Christopher Davis
+   Kapor Enterprises, Inc.
+   238 Main Street, Suite 400
+   Cambridge, MA 02142
+
+   Phone: +1 617 576 4532
+   EMail: ckd@kei.com
+
+
+   Paul Vixie
+   Vixie Enterprises
+   Star Route Box 159A
+   Woodside, CA 94062
+
+   Phone: +1 415 747 0204
+   EMail: paul@vix.com
+
+
+
+
+
+Davis, et al                  Experimental                      [Page 8]
+
+RFC 1876            Location Information in the DNS         January 1996
+
+
+   Tim Goodwin
+   Public IP Exchange Ltd (PIPEX)
+   216 The Science Park
+   Cambridge CB4 4WA
+   UK
+
+   Phone: +44 1223 250250
+   EMail: tim@pipex.net
+
+
+   Ian Dickinson
+   FORE Systems
+   2475 The Crescent
+   Solihull Parkway
+   Birmingham Business Park
+   B37 7YE
+   UK
+
+   Phone: +44 121 717 4444
+   EMail: idickins@fore.co.uk
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Davis, et al                  Experimental                      [Page 9]
+
+RFC 1876            Location Information in the DNS         January 1996
+
+
+Appendix A: Sample Conversion Routines
+
+/*
+ * routines to convert between on-the-wire RR format and zone file
+ * format.  Does not contain conversion to/from decimal degrees;
+ * divide or multiply by 60*60*1000 for that.
+ */
+
+static unsigned int poweroften[10] = {1, 10, 100, 1000, 10000, 100000,
+                                 1000000,10000000,100000000,1000000000};
+
+/* takes an XeY precision/size value, returns a string representation.*/
+static const char *
+precsize_ntoa(prec)
+        u_int8_t prec;
+{
+        static char retbuf[sizeof("90000000.00")];
+        unsigned long val;
+        int mantissa, exponent;
+
+        mantissa = (int)((prec >> 4) & 0x0f) % 10;
+        exponent = (int)((prec >> 0) & 0x0f) % 10;
+
+        val = mantissa * poweroften[exponent];
+
+        (void) sprintf(retbuf,"%d.%.2d", val/100, val%100);
+        return (retbuf);
+}
+
+/* converts ascii size/precision X * 10**Y(cm) to 0xXY. moves pointer.*/
+static u_int8_t
+precsize_aton(strptr)
+        char **strptr;
+{
+        unsigned int mval = 0, cmval = 0;
+        u_int8_t retval = 0;
+        register char *cp;
+        register int exponent;
+        register int mantissa;
+
+        cp = *strptr;
+
+        while (isdigit(*cp))
+                mval = mval * 10 + (*cp++ - '0');
+
+        if (*cp == '.') {               /* centimeters */
+                cp++;
+                if (isdigit(*cp)) {
+
+
+
+Davis, et al                  Experimental                     [Page 10]
+
+RFC 1876            Location Information in the DNS         January 1996
+
+
+                        cmval = (*cp++ - '0') * 10;
+                        if (isdigit(*cp)) {
+                                cmval += (*cp++ - '0');
+                        }
+                }
+        }
+        cmval = (mval * 100) + cmval;
+
+        for (exponent = 0; exponent < 9; exponent++)
+                if (cmval < poweroften[exponent+1])
+                        break;
+
+        mantissa = cmval / poweroften[exponent];
+        if (mantissa > 9)
+                mantissa = 9;
+
+        retval = (mantissa << 4) | exponent;
+
+        *strptr = cp;
+
+        return (retval);
+}
+
+/* converts ascii lat/lon to unsigned encoded 32-bit number.
+ *  moves pointer. */
+static u_int32_t
+latlon2ul(latlonstrptr,which)
+        char **latlonstrptr;
+        int *which;
+{
+        register char *cp;
+        u_int32_t retval;
+        int deg = 0, min = 0, secs = 0, secsfrac = 0;
+
+        cp = *latlonstrptr;
+
+        while (isdigit(*cp))
+                deg = deg * 10 + (*cp++ - '0');
+
+        while (isspace(*cp))
+                cp++;
+
+        if (!(isdigit(*cp)))
+                goto fndhemi;
+
+        while (isdigit(*cp))
+                min = min * 10 + (*cp++ - '0');
+
+
+
+
+Davis, et al                  Experimental                     [Page 11]
+
+RFC 1876            Location Information in the DNS         January 1996
+
+
+        while (isspace(*cp))
+                cp++;
+
+        if (!(isdigit(*cp)))
+                goto fndhemi;
+
+        while (isdigit(*cp))
+                secs = secs * 10 + (*cp++ - '0');
+
+        if (*cp == '.') {               /* decimal seconds */
+                cp++;
+                if (isdigit(*cp)) {
+                        secsfrac = (*cp++ - '0') * 100;
+                        if (isdigit(*cp)) {
+                                secsfrac += (*cp++ - '0') * 10;
+                                if (isdigit(*cp)) {
+                                        secsfrac += (*cp++ - '0');
+                                }
+                        }
+                }
+        }
+
+        while (!isspace(*cp))   /* if any trailing garbage */
+                cp++;
+
+        while (isspace(*cp))
+                cp++;
+
+ fndhemi:
+        switch (*cp) {
+        case 'N': case 'n':
+        case 'E': case 'e':
+                retval = ((unsigned)1<<31)
+                        + (((((deg * 60) + min) * 60) + secs) * 1000)
+                        + secsfrac;
+                break;
+        case 'S': case 's':
+        case 'W': case 'w':
+                retval = ((unsigned)1<<31)
+                        - (((((deg * 60) + min) * 60) + secs) * 1000)
+                        - secsfrac;
+                break;
+        default:
+                retval = 0;     /* invalid value -- indicates error */
+                break;
+        }
+
+        switch (*cp) {
+
+
+
+Davis, et al                  Experimental                     [Page 12]
+
+RFC 1876            Location Information in the DNS         January 1996
+
+
+        case 'N': case 'n':
+        case 'S': case 's':
+                *which = 1;     /* latitude */
+                break;
+        case 'E': case 'e':
+        case 'W': case 'w':
+                *which = 2;     /* longitude */
+                break;
+        default:
+                *which = 0;     /* error */
+                break;
+        }
+
+        cp++;                   /* skip the hemisphere */
+
+        while (!isspace(*cp))   /* if any trailing garbage */
+                cp++;
+
+        while (isspace(*cp))    /* move to next field */
+                cp++;
+
+        *latlonstrptr = cp;
+
+        return (retval);
+}
+
+/* converts a zone file representation in a string to an RDATA
+ * on-the-wire representation. */
+u_int32_t
+loc_aton(ascii, binary)
+        const char *ascii;
+        u_char *binary;
+{
+        const char *cp, *maxcp;
+        u_char *bcp;
+
+        u_int32_t latit = 0, longit = 0, alt = 0;
+        u_int32_t lltemp1 = 0, lltemp2 = 0;
+        int altmeters = 0, altfrac = 0, altsign = 1;
+        u_int8_t hp = 0x16;    /* default = 1e6 cm = 10000.00m = 10km */
+        u_int8_t vp = 0x13;    /* default = 1e3 cm = 10.00m */
+        u_int8_t siz = 0x12;   /* default = 1e2 cm = 1.00m */
+        int which1 = 0, which2 = 0;
+
+        cp = ascii;
+        maxcp = cp + strlen(ascii);
+
+        lltemp1 = latlon2ul(&cp, &which1);
+
+
+
+Davis, et al                  Experimental                     [Page 13]
+
+RFC 1876            Location Information in the DNS         January 1996
+
+
+        lltemp2 = latlon2ul(&cp, &which2);
+
+        switch (which1 + which2) {
+        case 3:                 /* 1 + 2, the only valid combination */
+                if ((which1 == 1) && (which2 == 2)) { /* normal case */
+                        latit = lltemp1;
+                        longit = lltemp2;
+                } else if ((which1 == 2) && (which2 == 1)) {/*reversed*/
+                        longit = lltemp1;
+                        latit = lltemp2;
+                } else {        /* some kind of brokenness */
+                        return 0;
+                }
+                break;
+        default:                /* we didn't get one of each */
+                return 0;
+        }
+
+        /* altitude */
+        if (*cp == '-') {
+                altsign = -1;
+                cp++;
+        }
+
+        if (*cp == '+')
+                cp++;
+
+        while (isdigit(*cp))
+                altmeters = altmeters * 10 + (*cp++ - '0');
+
+        if (*cp == '.') {               /* decimal meters */
+                cp++;
+                if (isdigit(*cp)) {
+                        altfrac = (*cp++ - '0') * 10;
+                        if (isdigit(*cp)) {
+                                altfrac += (*cp++ - '0');
+                        }
+                }
+        }
+
+        alt = (10000000 + (altsign * (altmeters * 100 + altfrac)));
+
+        while (!isspace(*cp) && (cp < maxcp))
+                                           /* if trailing garbage or m */
+                cp++;
+
+        while (isspace(*cp) && (cp < maxcp))
+                cp++;
+
+
+
+Davis, et al                  Experimental                     [Page 14]
+
+RFC 1876            Location Information in the DNS         January 1996
+
+
+        if (cp >= maxcp)
+                goto defaults;
+
+        siz = precsize_aton(&cp);
+
+        while (!isspace(*cp) && (cp < maxcp))/*if trailing garbage or m*/
+                cp++;
+
+        while (isspace(*cp) && (cp < maxcp))
+                cp++;
+
+        if (cp >= maxcp)
+                goto defaults;
+
+        hp = precsize_aton(&cp);
+
+        while (!isspace(*cp) && (cp < maxcp))/*if trailing garbage or m*/
+                cp++;
+
+        while (isspace(*cp) && (cp < maxcp))
+                cp++;
+
+        if (cp >= maxcp)
+                goto defaults;
+
+        vp = precsize_aton(&cp);
+
+ defaults:
+
+        bcp = binary;
+        *bcp++ = (u_int8_t) 0;  /* version byte */
+        *bcp++ = siz;
+        *bcp++ = hp;
+        *bcp++ = vp;
+        PUTLONG(latit,bcp);
+        PUTLONG(longit,bcp);
+        PUTLONG(alt,bcp);
+
+        return (16);            /* size of RR in octets */
+}
+
+/* takes an on-the-wire LOC RR and prints it in zone file
+ * (human readable) format. */
+char *
+loc_ntoa(binary,ascii)
+        const u_char *binary;
+        char *ascii;
+{
+
+
+
+Davis, et al                  Experimental                     [Page 15]
+
+RFC 1876            Location Information in the DNS         January 1996
+
+
+        static char tmpbuf[255*3];
+
+        register char *cp;
+        register const u_char *rcp;
+
+        int latdeg, latmin, latsec, latsecfrac;
+        int longdeg, longmin, longsec, longsecfrac;
+        char northsouth, eastwest;
+        int altmeters, altfrac, altsign;
+
+        const int referencealt = 100000 * 100;
+
+        int32_t latval, longval, altval;
+        u_int32_t templ;
+        u_int8_t sizeval, hpval, vpval, versionval;
+
+        char *sizestr, *hpstr, *vpstr;
+
+        rcp = binary;
+        if (ascii)
+                cp = ascii;
+        else {
+                cp = tmpbuf;
+        }
+
+        versionval = *rcp++;
+
+        if (versionval) {
+                sprintf(cp,"; error: unknown LOC RR version");
+                return (cp);
+        }
+
+        sizeval = *rcp++;
+
+        hpval = *rcp++;
+        vpval = *rcp++;
+
+        GETLONG(templ,rcp);
+        latval = (templ - ((unsigned)1<<31));
+
+        GETLONG(templ,rcp);
+        longval = (templ - ((unsigned)1<<31));
+
+        GETLONG(templ,rcp);
+        if (templ < referencealt) { /* below WGS 84 spheroid */
+                altval = referencealt - templ;
+                altsign = -1;
+        } else {
+
+
+
+Davis, et al                  Experimental                     [Page 16]
+
+RFC 1876            Location Information in the DNS         January 1996
+
+
+                altval = templ - referencealt;
+                altsign = 1;
+        }
+
+        if (latval < 0) {
+                northsouth = 'S';
+                latval = -latval;
+        }
+        else
+                northsouth = 'N';
+
+        latsecfrac = latval % 1000;
+        latval = latval / 1000;
+        latsec = latval % 60;
+        latval = latval / 60;
+        latmin = latval % 60;
+        latval = latval / 60;
+        latdeg = latval;
+
+        if (longval < 0) {
+                eastwest = 'W';
+                longval = -longval;
+        }
+        else
+                eastwest = 'E';
+
+        longsecfrac = longval % 1000;
+        longval = longval / 1000;
+        longsec = longval % 60;
+        longval = longval / 60;
+        longmin = longval % 60;
+        longval = longval / 60;
+        longdeg = longval;
+
+        altfrac = altval % 100;
+        altmeters = (altval / 100) * altsign;
+
+        sizestr = savestr(precsize_ntoa(sizeval));
+        hpstr = savestr(precsize_ntoa(hpval));
+        vpstr = savestr(precsize_ntoa(vpval));
+
+        sprintf(cp,
+                "%d %.2d %.2d.%.3d %c %d %.2d %.2d.%.3d %c %d.%.2dm
+                %sm %sm %sm",
+                latdeg, latmin, latsec, latsecfrac, northsouth,
+                longdeg, longmin, longsec, longsecfrac, eastwest,
+                altmeters, altfrac, sizestr, hpstr, vpstr);
+
+
+
+
+Davis, et al                  Experimental                     [Page 17]
+
+RFC 1876            Location Information in the DNS         January 1996
+
+
+        free(sizestr);
+        free(hpstr);
+        free(vpstr);
+
+        return (cp);
+}
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Davis, et al                  Experimental                     [Page 18]
+
diff --git a/doc/rfc/rfc1886.txt b/doc/rfc/rfc1886.txt
new file mode 100644
index 0000000..9874fdd
--- /dev/null
+++ b/doc/rfc/rfc1886.txt
@@ -0,0 +1,268 @@
+
+
+
+
+
+
+Network Working Group                                         S. Thomson
+Request for Comments: 1886                                      Bellcore
+Category: Standards Track                                     C. Huitema
+                                                                   INRIA
+                                                           December 1995
+
+
+                DNS Extensions to support IP version 6
+
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+
+Abstract
+
+   This document defines the changes that need to be made to the Domain
+   Name System to support hosts running IP version 6 (IPv6).  The
+   changes include a new resource record type to store an IPv6 address,
+   a new domain to support lookups based on an IPv6 address, and updated
+   definitions of existing query types that return Internet addresses as
+   part of additional section processing.  The extensions are designed
+   to be compatible with existing applications and, in particular, DNS
+   implementations themselves.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Thompson & Huitema          Standards Track                    [Page 1]
+
+RFC 1886                  IPv6 DNS Extensions              December 1995
+
+
+1. INTRODUCTION
+
+   Current support for the storage of Internet addresses in the Domain
+   Name System (DNS)[1,2] cannot easily be extended to support IPv6
+   addresses[3] since applications assume that address queries return
+   32-bit IPv4 addresses only.
+
+   To support the storage of IPv6 addresses we define the following
+   extensions:
+
+      o A new resource record type is defined to map a domain name to an
+        IPv6 address.
+
+      o A new domain is defined to support lookups based on address.
+
+      o Existing queries that perform additional section processing to
+        locate IPv4 addresses are redefined to perform additional
+        section processing on both IPv4 and IPv6 addresses.
+
+   The changes are designed to be compatible with existing software. The
+   existing support for IPv4 addresses is retained. Transition issues
+   related to the co-existence of both IPv4 and IPv6 addresses in DNS
+   are discussed in [4].
+
+
+2. NEW RESOURCE RECORD DEFINITION AND DOMAIN
+
+   A new record type is defined to store a host's IPv6 address. A host
+   that has more than one IPv6 address must have more than one such
+   record.
+
+
+2.1 AAAA record type
+
+   The AAAA resource record type is a new record specific to the
+   Internet class that stores a single IPv6 address.
+
+   The value of the type is 28 (decimal).
+
+
+2.2 AAAA data format
+
+   A 128 bit IPv6 address is encoded in the data portion of an AAAA
+   resource record in network byte order (high-order byte first).
+
+
+
+
+Thompson & Huitema          Standards Track                    [Page 2]
+
+RFC 1886                  IPv6 DNS Extensions              December 1995
+
+
+2.3 AAAA query
+
+   An AAAA query for a specified domain name in the Internet class
+   returns all associated AAAA resource records in the answer section of
+   a response.
+
+   A type AAAA query does not perform additional section processing.
+
+
+2.4 Textual format of AAAA records
+
+   The textual representation of the data portion of the AAAA resource
+   record used in a master database file is the textual representation
+   of a IPv6 address as defined in [3].
+
+
+2.5 IP6.INT Domain
+
+   A special domain is defined to look up a record given an address. The
+   intent of this domain is to provide a way of mapping an IPv6 address
+   to a host name, although it may be used for other purposes as well.
+   The domain is rooted at IP6.INT.
+
+   An IPv6 address is represented as a name in the IP6.INT domain by a
+   sequence of nibbles separated by dots with the suffix ".IP6.INT". The
+   sequence of nibbles is encoded in reverse order, i.e. the low-order
+   nibble is encoded first, followed by the next low-order nibble and so
+   on. Each nibble is represented by a hexadecimal digit. For example,
+   the inverse lookup domain name corresponding to the address
+
+       4321:0:1:2:3:4:567:89ab
+
+   would be
+
+b.a.9.8.7.6.5.0.4.0.0.0.3.0.0.0.2.0.0.0.1.0.0.0.0.0.0.0.1.2.3.4.IP6.INT.
+
+
+
+3. MODIFICATIONS TO EXISTING QUERY TYPES
+
+   All existing query types that perform type A additional section
+   processing, i.e. name server (NS), mail exchange (MX) and mailbox
+   (MB) query types, must be redefined to perform both type A and type
+   AAAA additional section processing. These new definitions mean that a
+   name server must add any relevant IPv4 addresses and any relevant
+
+
+
+Thompson & Huitema          Standards Track                    [Page 3]
+
+RFC 1886                  IPv6 DNS Extensions              December 1995
+
+
+   IPv6 addresses available locally to the additional section of a
+   response when processing any one of the above queries.
+
+
+4. SECURITY CONSIDERATIONS
+
+   Security issues are not discussed in this memo.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Thompson & Huitema          Standards Track                    [Page 4]
+
+RFC 1886                  IPv6 DNS Extensions              December 1995
+
+
+5. REFERENCES
+
+
+   [1]  Mockapetris, P., "Domain Names - Concepts and Facilities", STD
+        13, RFC 1034, USC/Information Sciences Institute, November 1987.
+
+   [2]  Mockapetris, P., "Domain Names - Implementation and Specifica-
+        tion", STD 13, RFC 1035, USC/Information Sciences Institute,
+        November 1987.
+
+   [3]  Hinden, R., and S. Deering, Editors, "IP Version 6 Addressing
+        Architecture", RFC 1884, Ipsilon Networks, Xerox PARC, December
+        1995.
+
+
+   [4]  Gilligan, R., and E. Nordmark, "Transition Mechanisms for IPv6
+        Hosts and Routers", Work in Progress.
+
+
+Authors' Addresses
+
+   Susan Thomson
+   Bellcore
+   MRE 2P343
+   445 South Street
+   Morristown, NJ 07960
+   U.S.A.
+
+   Phone: +1 201-829-4514
+   EMail: set@thumper.bellcore.com
+
+
+   Christian Huitema
+   INRIA, Sophia-Antipolis
+   2004 Route des Lucioles
+   BP 109
+   F-06561 Valbonne Cedex
+   France
+
+   Phone: +33 93 65 77 15
+   EMail: Christian.Huitema@MIRSA.INRIA.FR
+
+
+
+
+
+
+
+Thompson & Huitema          Standards Track                    [Page 5]
+
diff --git a/doc/rfc/rfc1982.txt b/doc/rfc/rfc1982.txt
new file mode 100644
index 0000000..5a34bc4
--- /dev/null
+++ b/doc/rfc/rfc1982.txt
@@ -0,0 +1,394 @@
+
+
+
+
+
+
+Network Working Group                                             R. Elz
+Request for Comments: 1982                       University of Melbourne
+Updates: 1034, 1035                                              R. Bush
+Category: Standards Track                                    RGnet, Inc.
+                                                             August 1996
+
+
+                        Serial Number Arithmetic
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Abstract
+
+   This memo defines serial number arithmetic, as used in the Domain
+   Name System.  The DNS has long relied upon serial number arithmetic,
+   a concept which has never really been defined, certainly not in an
+   IETF document, though which has been widely understood.  This memo
+   supplies the missing definition.  It is intended to update RFC1034
+   and RFC1035.
+
+1. Introduction
+
+   The serial number field of the SOA resource record is defined in
+   RFC1035 as
+
+   SERIAL   The unsigned 32 bit version number of the original copy of
+            the zone.  Zone transfers preserve this value.  This value
+            wraps and should be compared using sequence space
+            arithmetic.
+
+   RFC1034 uses the same terminology when defining secondary server zone
+   consistency procedures.
+
+   Unfortunately the term "sequence space arithmetic" is not defined in
+   either RFC1034 or RFC1035, nor do any of their references provide
+   further information.
+
+   This phrase seems to have been intending to specify arithmetic as
+   used in TCP sequence numbers [RFC793], and defined in [IEN-74].
+
+   Unfortunately, the arithmetic defined in [IEN-74] is not adequate for
+   the purposes of the DNS, as no general comparison operator is
+
+
+
+Elz & Bush                  Standards Track                     [Page 1]
+
+RFC 1982                Serial Number Arithmetic             August 1996
+
+
+   defined.
+
+   To avoid further problems with this simple field, this document
+   defines the field and the operations available upon it.  This
+   definition is intended merely to clarify the intent of RFC1034 and
+   RFC1035, and is believed to generally agree with current
+   implementations.  However, older, superseded, implementations are
+   known to have treated the serial number as a simple unsigned integer,
+   with no attempt to implement any kind of "sequence space arithmetic",
+   however that may have been interpreted, and further, ignoring the
+   requirement that the value wraps.  Nothing can be done with these
+   implementations, beyond extermination.
+
+2. Serial Number Arithmetic
+
+   Serial numbers are formed from non-negative integers from a finite
+   subset of the range of all integer values.  The lowest integer in
+   every subset used for this purpose is zero, the maximum is always one
+   less than a power of two.
+
+   When considered as serial numbers however no value has any particular
+   significance, there is no minimum or maximum serial number, every
+   value has a successor and predecessor.
+
+   To define a serial number to be used in this way, the size of the
+   serial number space must be given.  This value, called "SERIAL_BITS",
+   gives the power of two which results in one larger than the largest
+   integer corresponding to a serial number value.  This also specifies
+   the number of bits required to hold every possible value of a serial
+   number of the defined type.  The operations permitted upon serial
+   numbers are defined in the following section.
+
+3. Operations upon the serial number
+
+   Only two operations are defined upon serial numbers, addition of a
+   positive integer of limited range, and comparison with another serial
+   number.
+
+3.1. Addition
+
+   Serial numbers may be incremented by the addition of a positive
+   integer n, where n is taken from the range of integers
+   [0 .. (2^(SERIAL_BITS - 1) - 1)].  For a sequence number s, the
+   result of such an addition, s', is defined as
+
+                   s' = (s + n) modulo (2 ^ SERIAL_BITS)
+
+
+
+
+
+Elz & Bush                  Standards Track                     [Page 2]
+
+RFC 1982                Serial Number Arithmetic             August 1996
+
+
+   where the addition and modulus operations here act upon values that
+   are non-negative values of unbounded size in the usual ways of
+   integer arithmetic.
+
+   Addition of a value outside the range
+   [0 .. (2^(SERIAL_BITS - 1) - 1)] is undefined.
+
+3.2. Comparison
+
+   Any two serial numbers, s1 and s2, may be compared.  The definition
+   of the result of this comparison is as follows.
+
+   For the purposes of this definition, consider two integers, i1 and
+   i2, from the unbounded set of non-negative integers, such that i1 and
+   s1 have the same numeric value, as do i2 and s2.  Arithmetic and
+   comparisons applied to i1 and i2 use ordinary unbounded integer
+   arithmetic.
+
+   Then, s1 is said to be equal to s2 if and only if i1 is equal to i2,
+   in all other cases, s1 is not equal to s2.
+
+   s1 is said to be less than s2 if, and only if, s1 is not equal to s2,
+   and
+
+        (i1 < i2 and i2 - i1 < 2^(SERIAL_BITS - 1)) or
+        (i1 > i2 and i1 - i2 > 2^(SERIAL_BITS - 1))
+
+   s1 is said to be greater than s2 if, and only if, s1 is not equal to
+   s2, and
+
+        (i1 < i2 and i2 - i1 > 2^(SERIAL_BITS - 1)) or
+        (i1 > i2 and i1 - i2 < 2^(SERIAL_BITS - 1))
+
+   Note that there are some pairs of values s1 and s2 for which s1 is
+   not equal to s2, but for which s1 is neither greater than, nor less
+   than, s2.  An attempt to use these ordering operators on such pairs
+   of values produces an undefined result.
+
+   The reason for this is that those pairs of values are such that any
+   simple definition that were to define s1 to be less than s2 where
+   (s1, s2) is such a pair, would also usually cause s2 to be less than
+   s1, when the pair is (s2, s1).  This would mean that the particular
+   order selected for a test could cause the result to differ, leading
+   to unpredictable implementations.
+
+   While it would be possible to define the test in such a way that the
+   inequality would not have this surprising property, while being
+   defined for all pairs of values, such a definition would be
+
+
+
+Elz & Bush                  Standards Track                     [Page 3]
+
+RFC 1982                Serial Number Arithmetic             August 1996
+
+
+   unnecessarily burdensome to implement, and difficult to understand,
+   and would still allow cases where
+
+        s1 < s2 and (s1 + 1) > (s2 + 1)
+
+   which is just as non-intuitive.
+
+   Thus the problem case is left undefined, implementations are free to
+   return either result, or to flag an error, and users must take care
+   not to depend on any particular outcome.  Usually this will mean
+   avoiding allowing those particular pairs of numbers to co-exist.
+
+   The relationships greater than or equal to, and less than or equal
+   to, follow in the natural way from the above definitions.
+
+4. Corollaries
+
+   These definitions give rise to some results of note.
+
+4.1. Corollary 1
+
+   For any sequence number s and any integer n such that addition of n
+   to s is well defined, (s + n) >= s.  Further (s + n) == s only when
+   n == 0, in all other defined cases, (s + n) > s.
+
+4.2. Corollary 2
+
+   If s' is the result of adding the non-zero integer n to the sequence
+   number s, and m is another integer from the range defined as able to
+   be added to a sequence number, and s" is the result of adding m to
+   s', then it is undefined whether s" is greater than, or less than s,
+   though it is known that s" is not equal to s.
+
+4.3. Corollary 3
+
+   If s" from the previous corollary is further incremented, then there
+   is no longer any known relationship between the result and s.
+
+4.4. Corollary 4
+
+   If in corollary 2 the value (n + m) is such that addition of the sum
+   to sequence number s would produce a defined result, then corollary 1
+   applies, and s" is known to be greater than s.
+
+
+
+
+
+
+
+
+Elz & Bush                  Standards Track                     [Page 4]
+
+RFC 1982                Serial Number Arithmetic             August 1996
+
+
+5. Examples
+
+5.1. A trivial example
+
+   The simplest meaningful serial number space has SERIAL_BITS == 2.  In
+   this space, the integers that make up the serial number space are 0,
+   1, 2, and 3.  That is, 3 == 2^SERIAL_BITS - 1.
+
+   In this space, the largest integer that it is meaningful to add to a
+   sequence number is 2^(SERIAL_BITS - 1) - 1, or 1.
+
+   Then, as defined 0+1 == 1, 1+1 == 2, 2+1 == 3, and 3+1 == 0.
+   Further, 1 > 0, 2 > 1, 3 > 2, and 0 > 3.  It is undefined whether
+   2 > 0 or 0 > 2, and whether 1 > 3 or 3 > 1.
+
+5.2. A slightly larger example
+
+   Consider the case where SERIAL_BITS == 8.  In this space the integers
+   that make up the serial number space are 0, 1, 2, ... 254, 255.
+   255 == 2^SERIAL_BITS - 1.
+
+   In this space, the largest integer that it is meaningful to add to a
+   sequence number is 2^(SERIAL_BITS - 1) - 1, or 127.
+
+   Addition is as expected in this space, for example: 255+1 == 0,
+   100+100 == 200, and 200+100 == 44.
+
+   Comparison is more interesting, 1 > 0, 44 > 0, 100 > 0, 100 > 44,
+   200 > 100, 255 > 200, 0 > 255, 100 > 255, 0 > 200, and 44 > 200.
+
+   Note that 100+100 > 100, but that (100+100)+100 < 100.  Incrementing
+   a serial number can cause it to become "smaller".  Of course,
+   incrementing by a smaller number will allow many more increments to
+   be made before this occurs.  However this is always something to be
+   aware of, it can cause surprising errors, or be useful as it is the
+   only defined way to actually cause a serial number to decrease.
+
+   The pairs of values 0 and 128, 1 and 129, 2 and 130, etc, to 127 and
+   255 are not equal, but in each pair, neither number is defined as
+   being greater than, or less than, the other.
+
+   It could be defined (arbitrarily) that 128 > 0, 129 > 1,
+   130 > 2, ..., 255 > 127, by changing the comparison operator
+   definitions, as mentioned above.  However note that that would cause
+   255 > 127, while (255 + 1) < (127 + 1), as 0 < 128.  Such a
+   definition, apart from being arbitrary, would also be more costly to
+   implement.
+
+
+
+
+Elz & Bush                  Standards Track                     [Page 5]
+
+RFC 1982                Serial Number Arithmetic             August 1996
+
+
+6. Citation
+
+   As this defined arithmetic may be useful for purposes other than for
+   the DNS serial number, it may be referenced as Serial Number
+   Arithmetic from RFC1982.  Any such reference shall be taken as
+   implying that the rules of sections 2 to 5 of this document apply to
+   the stated values.
+
+7. The DNS SOA serial number
+
+   The serial number in the DNS SOA Resource Record is a Serial Number
+   as defined above, with SERIAL_BITS being 32.  That is, the serial
+   number is a non negative integer with values taken from the range
+   [0 .. 4294967295].  That is, a 32 bit unsigned integer.
+
+   The maximum defined increment is 2147483647 (2^31 - 1).
+
+   Care should be taken that the serial number not be incremented, in
+   one or more steps, by more than this maximum within the period given
+   by the value of SOA.expire.  Doing so may leave some secondary
+   servers with out of date copies of the zone, but with a serial number
+   "greater" than that of the primary server.  Of course, special
+   circumstances may require this rule be set aside, for example, when
+   the serial number needs to be set lower for some reason.  If this
+   must be done, then take special care to verify that ALL servers have
+   correctly succeeded in following the primary server's serial number
+   changes, at each step.
+
+   Note that each, and every, increment to the serial number must be
+   treated as the start of a new sequence of increments for this
+   purpose, as well as being the continuation of all previous sequences
+   started within the period specified by SOA.expire.
+
+   Caution should also be exercised before causing the serial number to
+   be set to the value zero.  While this value is not in any way special
+   in serial number arithmetic, or to the DNS SOA serial number, many
+   DNS implementations have incorrectly treated zero as a special case,
+   with special properties, and unusual behaviour may be expected if
+   zero is used as a DNS SOA serial number.
+
+
+
+
+
+
+
+
+
+
+
+
+Elz & Bush                  Standards Track                     [Page 6]
+
+RFC 1982                Serial Number Arithmetic             August 1996
+
+
+8. Document Updates
+
+   RFC1034 and RFC1035 are to be treated as if the references to
+   "sequence space arithmetic" therein are replaced by references to
+   serial number arithmetic, as defined in this document.
+
+9. Security Considerations
+
+   This document does not consider security.
+
+   It is not believed that anything in this document adds to any
+   security issues that may exist with the DNS, nor does it do anything
+   to lessen them.
+
+References
+
+   [RFC1034]   Domain Names - Concepts and Facilities,
+               P. Mockapetris, STD 13, ISI, November 1987.
+
+   [RFC1035]   Domain Names - Implementation and Specification
+               P. Mockapetris, STD 13, ISI, November 1987
+
+   [RFC793]    Transmission Control protocol
+               Information Sciences Institute, STD 7, USC, September 1981
+
+   [IEN-74]    Sequence Number Arithmetic
+               William W. Plummer, BB&N Inc, September 1978
+
+Acknowledgements
+
+   Thanks to Rob Austein for suggesting clarification of the undefined
+   comparison operators, and to Michael Patton for attempting to locate
+   another reference for this procedure.  Thanks also to members of the
+   IETF DNSIND working group of 1995-6, in particular, Paul Mockapetris.
+
+Authors' Addresses
+
+   Robert Elz                     Randy Bush
+   Computer Science               RGnet, Inc.
+   University of Melbourne        10361 NE Sasquatch Lane
+   Parkville, Vic,  3052          Bainbridge Island, Washington,  98110
+   Australia.                     United States.
+
+   EMail: kre@munnari.OZ.AU       EMail: randy@psg.com
+
+
+
+
+
+
+
+Elz & Bush                  Standards Track                     [Page 7]
diff --git a/doc/rfc/rfc1995.txt b/doc/rfc/rfc1995.txt
new file mode 100644
index 0000000..b50bdc6
--- /dev/null
+++ b/doc/rfc/rfc1995.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+Network Working Group                                            M. Ohta
+Request for Comments: 1995                 Tokyo Institute of Technology
+Updates: 1035                                                August 1996
+Category: Standards Track
+
+
+                    Incremental Zone Transfer in DNS
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Abstract
+
+   This document proposes extensions to the DNS protocols to provide an
+   incremental zone transfer (IXFR) mechanism.
+
+1. Introduction
+
+   For rapid propagation of changes to a DNS database [STD13], it is
+   necessary to reduce latency by actively notifying servers of the
+   change.  This is accomplished by the NOTIFY extension of the DNS
+   [NOTIFY].
+
+   The current full zone transfer mechanism (AXFR) is not an efficient
+   means to propagate changes to a small part of a zone, as it transfers
+   the entire zone file.
+
+   Incremental transfer (IXFR) as proposed is a more efficient
+   mechanism, as it transfers only the changed portion(s) of a zone.
+
+   In this document, a secondary name server which requests IXFR is
+   called an IXFR client and a primary or secondary name server which
+   responds to the request is called an IXFR server.
+
+2. Brief Description of the Protocol
+
+   If an IXFR client, which likely has an older version of a zone,
+   thinks it needs new information about the zone (typically through SOA
+   refresh timeout or the NOTIFY mechanism), it sends an IXFR message
+   containing the SOA serial number of its, presumably outdated, copy of
+   the zone.
+
+
+
+
+
+Ohta                        Standards Track                     [Page 1]
+
+RFC 1995            Incremental Zone Transfer in DNS         August 1996
+
+
+   An IXFR server should keep record of the newest version of the zone
+   and the differences between that copy and several older versions.
+   When an IXFR request with an older version number is received, the
+   IXFR server needs to send only the differences required to make that
+   version current.  Alternatively, the server may choose to transfer
+   the entire zone just as in a normal full zone transfer.
+
+   When a zone has been updated, it should be saved in stable storage
+   before the new version is used to respond to IXFR (or AXFR) queries.
+   Otherwise, if the server crashes, data which is no longer available
+   may have been distributed to secondary servers, which can cause
+   persistent database inconsistencies.
+
+   If an IXFR query with the same or newer version number than that of
+   the server is received, it is replied to with a single SOA record of
+   the server's current version, just as in AXFR.
+
+   Transport of a query may be by either UDP or TCP.  If an IXFR query
+   is via UDP, the IXFR server may attempt to reply using UDP if the
+   entire response can be contained in a single DNS packet.  If the UDP
+   reply does not fit, the query is responded to with a single SOA
+   record of the server's current version to inform the client that a
+   TCP query should be initiated.
+
+   Thus, a client should first make an IXFR query using UDP.  If the
+   query type is not recognized by the server, an AXFR (preceded by a
+   UDP SOA query) should be tried, ensuring backward compatibility.  If
+   the query response is a single packet with the entire new zone, or if
+   the server does not have a newer version than the client, everything
+   is done.  Otherwise, a TCP IXFR query should be tried.
+
+   To ensure integrity, servers should use UDP checksums for all UDP
+   responses.  A cautious client which receives a UDP packet with a
+   checksum value of zero should ignore the result and try a TCP IXFR
+   instead.
+
+   The query type value of IXFR assigned by IANA is 251.
+
+3. Query Format
+
+   The IXFR query packet format is the same as that of a normal DNS
+   query, but with the query type being IXFR and the authority section
+   containing the SOA record of client's version of the zone.
+
+
+
+
+
+
+
+
+Ohta                        Standards Track                     [Page 2]
+
+RFC 1995            Incremental Zone Transfer in DNS         August 1996
+
+
+4. Response Format
+
+   If incremental zone transfer is not available, the entire zone is
+   returned.  The first and the last RR of the response is the SOA
+   record of the zone.  I.e. the behavior is the same as an AXFR
+   response except the query type is IXFR.
+
+   If incremental zone transfer is available, one or more difference
+   sequences is returned.  The list of difference sequences is preceded
+   and followed by a copy of the server's current version of the SOA.
+
+   Each difference sequence represents one update to the zone (one SOA
+   serial change) consisting of deleted RRs and added RRs.  The first RR
+   of the deleted RRs is the older SOA RR and the first RR of the added
+   RRs is the newer SOA RR.
+
+   Modification of an RR is performed first by removing the original RR
+   and then adding the modified one.
+
+   The sequences of differential information are ordered oldest first
+   newest last.  Thus, the differential sequences are the history of
+   changes made since the version known by the IXFR client up to the
+   server's current version.
+
+   RRs in the incremental transfer messages may be partial.  That is, if
+   a single RR of multiple RRs of the same RR type changes, only the
+   changed RR is transferred.
+
+   An IXFR client, should only replace an older version with a newer
+   version after all the differences have been successfully processed.
+
+   An incremental response is different from that of a non-incremental
+   response in that it begins with two SOA RRs, the server's current SOA
+   followed by the SOA of the client's version which is about to be
+   replaced.
+
+   5. Purging Strategy
+
+   An IXFR server can not be required to hold all previous versions
+   forever and may delete them anytime. In general, there is a trade-off
+   between the size of storage space and the possibility of using IXFR.
+
+   Information about older versions should be purged if the total length
+   of an IXFR response would be longer than that of an AXFR response.
+   Given that the purpose of IXFR is to reduce AXFR overhead, this
+   strategy is quite reasonable.  The strategy assures that the amount
+   of storage required is at most twice that of the current zone
+   information.
+
+
+
+Ohta                        Standards Track                     [Page 3]
+
+RFC 1995            Incremental Zone Transfer in DNS         August 1996
+
+
+   Information older than the SOA expire period may also be purged.
+
+6. Optional Condensation of Multiple Versions
+
+   An IXFR server may optionally condense multiple difference sequences
+   into a single difference sequence, thus, dropping information on
+   intermediate versions.
+
+   This may be beneficial if a lot of versions, not all of which are
+   useful, are generated. For example, if multiple ftp servers share a
+   single DNS name and the IP address associated with the name is
+   changed once a minute to balance load between the ftp servers, it is
+   not so important to keep track of all the history of changes.
+
+   But, this feature may not be so useful if an IXFR client has access
+   to two IXFR servers: A and B, with inconsistent condensation results.
+   The current version of the IXFR client, received from server A, may
+   be unknown to server B. In such a case, server B can not provide
+   incremental data from the unknown version and a full zone transfer is
+   necessary.
+
+   Condensation is completely optional. Clients can't detect from the
+   response whether the server has condensed the reply or not.
+
+   For interoperability, IXFR servers, including those without the
+   condensation feature, should not flag an error even if it receives a
+   client's IXFR request with a unknown version number and should,
+   instead, attempt to perform a full zone transfer.
+
+7. Example
+
+   Given the following three generations of data with the current serial
+   number of 3,
+
+      JAIN.AD.JP.         IN SOA NS.JAIN.AD.JP. mohta.jain.ad.jp. (
+                                        1 600 600 3600000 604800)
+                          IN NS  NS.JAIN.AD.JP.
+      NS.JAIN.AD.JP.      IN A   133.69.136.1
+      NEZU.JAIN.AD.JP.    IN A   133.69.136.5
+
+   NEZU.JAIN.AD.JP. is removed and JAIN-BB.JAIN.AD.JP. is added.
+
+      jain.ad.jp.         IN SOA ns.jain.ad.jp. mohta.jain.ad.jp. (
+                                        2 600 600 3600000 604800)
+                          IN NS  NS.JAIN.AD.JP.
+      NS.JAIN.AD.JP.      IN A   133.69.136.1
+      JAIN-BB.JAIN.AD.JP. IN A   133.69.136.4
+                          IN A   192.41.197.2
+
+
+
+Ohta                        Standards Track                     [Page 4]
+
+RFC 1995            Incremental Zone Transfer in DNS         August 1996
+
+
+   One of the IP addresses of JAIN-BB.JAIN.AD.JP. is changed.
+
+      JAIN.AD.JP.         IN SOA ns.jain.ad.jp. mohta.jain.ad.jp. (
+                                        3 600 600 3600000 604800)
+                          IN NS  NS.JAIN.AD.JP.
+      NS.JAIN.AD.JP.      IN A   133.69.136.1
+      JAIN-BB.JAIN.AD.JP. IN A   133.69.136.3
+                          IN A   192.41.197.2
+
+   The following IXFR query
+
+                 +---------------------------------------------------+
+      Header     | OPCODE=SQUERY                                     |
+                 +---------------------------------------------------+
+      Question   | QNAME=JAIN.AD.JP., QCLASS=IN, QTYPE=IXFR          |
+                 +---------------------------------------------------+
+      Answer     | <empty>                                           |
+                 +---------------------------------------------------+
+      Authority  | JAIN.AD.JP.         IN SOA serial=1               |
+                 +---------------------------------------------------+
+      Additional | <empty>                                           |
+                 +---------------------------------------------------+
+
+   could be replied to with the following full zone transfer message:
+
+                 +---------------------------------------------------+
+      Header     | OPCODE=SQUERY, RESPONSE                           |
+                 +---------------------------------------------------+
+      Question   | QNAME=JAIN.AD.JP., QCLASS=IN, QTYPE=IXFR          |
+                 +---------------------------------------------------+
+      Answer     | JAIN.AD.JP.         IN SOA serial=3               |
+                 | JAIN.AD.JP.         IN NS  NS.JAIN.AD.JP.         |
+                 | NS.JAIN.AD.JP.      IN A   133.69.136.1           |
+                 | JAIN-BB.JAIN.AD.JP. IN A   133.69.136.3           |
+                 | JAIN-BB.JAIN.AD.JP. IN A   192.41.197.2           |
+                 | JAIN.AD.JP.         IN SOA serial=3               |
+                 +---------------------------------------------------+
+      Authority  | <empty>                                           |
+                 +---------------------------------------------------+
+      Additional | <empty>                                           |
+                 +---------------------------------------------------+
+
+
+
+
+
+
+
+
+
+
+Ohta                        Standards Track                     [Page 5]
+
+RFC 1995            Incremental Zone Transfer in DNS         August 1996
+
+
+   or with the following incremental message:
+
+                 +---------------------------------------------------+
+      Header     | OPCODE=SQUERY, RESPONSE                           |
+                 +---------------------------------------------------+
+      Question   | QNAME=JAIN.AD.JP., QCLASS=IN, QTYPE=IXFR          |
+                 +---------------------------------------------------+
+      Answer     | JAIN.AD.JP.         IN SOA serial=3               |
+                 | JAIN.AD.JP.         IN SOA serial=1               |
+                 | NEZU.JAIN.AD.JP.    IN A   133.69.136.5           |
+                 | JAIN.AD.JP.         IN SOA serial=2               |
+                 | JAIN-BB.JAIN.AD.JP. IN A   133.69.136.4           |
+                 | JAIN-BB.JAIN.AD.JP. IN A   192.41.197.2           |
+                 | JAIN.AD.JP.         IN SOA serial=2               |
+                 | JAIN-BB.JAIN.AD.JP. IN A   133.69.136.4           |
+                 | JAIN.AD.JP.         IN SOA serial=3               |
+                 | JAIN-BB.JAIN.AD.JP. IN A   133.69.136.3           |
+                 | JAIN.AD.JP.         IN SOA serial=3               |
+                 +---------------------------------------------------+
+      Authority  | <empty>                                           |
+                 +---------------------------------------------------+
+      Additional | <empty>                                           |
+                 +---------------------------------------------------+
+
+   or with the following condensed incremental message:
+
+                 +---------------------------------------------------+
+      Header     | OPCODE=SQUERY, RESPONSE                           |
+                 +---------------------------------------------------+
+      Question   | QNAME=JAIN.AD.JP., QCLASS=IN, QTYPE=IXFR          |
+                 +---------------------------------------------------+
+      Answer     | JAIN.AD.JP.         IN SOA serial=3               |
+                 | JAIN.AD.JP.         IN SOA serial=1               |
+                 | NEZU.JAIN.AD.JP.    IN A   133.69.136.5           |
+                 | JAIN.AD.JP.         IN SOA serial=3               |
+                 | JAIN-BB.JAIN.AD.JP. IN A   133.69.136.3           |
+                 | JAIN-BB.JAIN.AD.JP. IN A   192.41.197.2           |
+                 | JAIN.AD.JP.         IN SOA serial=3               |
+                 +---------------------------------------------------+
+      Authority  | <empty>                                           |
+                 +---------------------------------------------------+
+      Additional | <empty>                                           |
+                 +---------------------------------------------------+
+
+
+
+
+
+
+
+
+Ohta                        Standards Track                     [Page 6]
+
+RFC 1995            Incremental Zone Transfer in DNS         August 1996
+
+
+   or, if UDP packet overflow occurs, with the following message:
+
+                 +---------------------------------------------------+
+      Header     | OPCODE=SQUERY, RESPONSE                           |
+                 +---------------------------------------------------+
+      Question   | QNAME=JAIN.AD.JP., QCLASS=IN, QTYPE=IXFR          |
+                 +---------------------------------------------------+
+      Answer     | JAIN.AD.JP.         IN SOA serial=3               |
+                 +---------------------------------------------------+
+      Authority  | <empty>                                           |
+                 +---------------------------------------------------+
+      Additional | <empty>                                           |
+                 +---------------------------------------------------+
+
+8. Acknowledgements
+
+   The original idea of IXFR was conceived by Anant Kumar, Steve Hotz
+   and Jon Postel.
+
+   For the refinement of the protocol and documentation, many people
+   have contributed including, but not limited to, Anant Kumar, Robert
+   Austein, Paul Vixie, Randy Bush, Mark Andrews, Robert Elz and the
+   members of the IETF DNSIND working group.
+
+9. References
+
+   [NOTIFY] Vixie, P., "DNS NOTIFY: A Mechanism for Prompt
+   Notification of Zone Changes", RFC 1996, August 1996.
+
+   [STD13] Mockapetris, P., "Domain Name System", STD 13, RFC 1034 and
+   RFC 1035), November 1987.
+
+10. Security Considerations
+
+   Though DNS is related to several security problems, no attempt is
+   made to fix them in this document.
+
+   This document is believed to introduce no additional security
+   problems to the current DNS protocol.
+
+
+
+
+
+
+
+
+
+
+
+
+Ohta                        Standards Track                     [Page 7]
+
+RFC 1995            Incremental Zone Transfer in DNS         August 1996
+
+
+11. Author's Address
+
+   Masataka Ohta
+   Computer Center
+   Tokyo Institute of Technology
+   2-12-1, O-okayama, Meguro-ku, Tokyo 152, JAPAN
+
+   Phone: +81-3-5734-3299
+   Fax: +81-3-5734-3415
+   EMail: mohta@necom830.hpcl.titech.ac.jp
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ohta                        Standards Track                     [Page 8]
+
diff --git a/doc/rfc/rfc1996.txt b/doc/rfc/rfc1996.txt
new file mode 100644
index 0000000..b08f200
--- /dev/null
+++ b/doc/rfc/rfc1996.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+Network Working Group                                           P. Vixie
+Request for Comments: 1996                                           ISC
+Updates: 1035                                                August 1996
+Category: Standards Track
+
+
+    A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Abstract
+
+   This memo describes the NOTIFY opcode for DNS, by which a master
+   server advises a set of slave servers that the master's data has been
+   changed and that a query should be initiated to discover the new
+   data.
+
+1. Rationale and Scope
+
+   1.1. Slow propagation of new and changed data in a DNS zone can be
+   due to a zone's relatively long refresh times.  Longer refresh times
+   are beneficial in that they reduce load on the master servers, but
+   that benefit comes at the cost of long intervals of incoherence among
+   authority servers whenever the zone is updated.
+
+   1.2. The DNS NOTIFY transaction allows master servers to inform slave
+   servers when the zone has changed -- an interrupt as opposed to poll
+   model -- which it is hoped will reduce propagation delay while not
+   unduly increasing the masters' load.  This specification only allows
+   slaves to be notified of SOA RR changes, but the architechture of
+   NOTIFY is intended to be extensible to other RR types.
+
+   1.3. This document intentionally gives more definition to the roles
+   of "Master," "Slave" and "Stealth" servers, their enumeration in NS
+   RRs, and the SOA MNAME field.  In that sense, this document can be
+   considered an addendum to [RFC1035].
+
+
+
+
+
+
+
+
+
+Vixie                       Standards Track                     [Page 1]
+
+RFC 1996                       DNS NOTIFY                    August 1996
+
+
+2. Definitions and Invariants
+
+   2.1. The following definitions are used in this document:
+
+   Slave           an authoritative server which uses zone transfer to
+                   retrieve the zone.  All slave servers are named in
+                   the NS RRs for the zone.
+
+   Master          any authoritative server configured to be the source
+                   of zone transfer for one or more slave servers.
+
+   Primary Master  master server at the root of the zone transfer
+                   dependency graph.  The primary master is named in the
+                   zone's SOA MNAME field and optionally by an NS RR.
+                   There is by definition only one primary master server
+                   per zone.
+
+   Stealth         like a slave server except not listed in an NS RR for
+                   the zone.  A stealth server, unless explicitly
+                   configured to do otherwise, will set the AA bit in
+                   responses and be capable of acting as a master.  A
+                   stealth server will only be known by other servers if
+                   they are given static configuration data indicating
+                   its existence.
+
+   Notify Set      set of servers to be notified of changes to some
+                   zone.  Default is all servers named in the NS RRset,
+                   except for any server also named in the SOA MNAME.
+                   Some implementations will permit the name server
+                   administrator to override this set or add elements to
+                   it (such as, for example, stealth servers).
+
+   2.2. The zone's servers must be organized into a dependency graph
+   such that there is a primary master, and all other servers must use
+   AXFR or IXFR either from the primary master or from some slave which
+   is also a master.  No loops are permitted in the AXFR dependency
+   graph.
+
+3. NOTIFY Message
+
+   3.1. When a master has updated one or more RRs in which slave servers
+   may be interested, the master may send the changed RR's name, class,
+   type, and optionally, new RDATA(s), to each known slave server using
+   a best efforts protocol based on the NOTIFY opcode.
+
+   3.2. NOTIFY uses the DNS Message Format, although it uses only a
+   subset of the available fields.  Fields not otherwise described
+   herein are to be filled with binary zero (0), and implementations
+
+
+
+Vixie                       Standards Track                     [Page 2]
+
+RFC 1996                       DNS NOTIFY                    August 1996
+
+
+   must ignore all messages for which this is not the case.
+
+   3.3. NOTIFY is similar to QUERY in that it has a request message with
+   the header QR flag "clear" and a response message with QR "set".  The
+   response message contains no useful information, but its reception by
+   the master is an indication that the slave has received the NOTIFY
+   and that the master can remove the slave from any retry queue for
+   this NOTIFY event.
+
+   3.4. The transport protocol used for a NOTIFY transaction will be UDP
+   unless the master has reason to believe that TCP is necessary; for
+   example, if a firewall has been installed between master and slave,
+   and only TCP has been allowed; or, if the changed RR is too large to
+   fit in a UDP/DNS datagram.
+
+   3.5. If TCP is used, both master and slave must continue to offer
+   name service during the transaction, even when the TCP transaction is
+   not making progress.  The NOTIFY request is sent once, and a
+   "timeout" is said to have occurred if no NOTIFY response is received
+   within a reasonable interval.
+
+   3.6. If UDP is used, a master periodically sends a NOTIFY request to
+   a slave until either too many copies have been sent (a "timeout"), an
+   ICMP message indicating that the port is unreachable, or until a
+   NOTIFY response is received from the slave with a matching query ID,
+   QNAME, IP source address, and UDP source port number.
+
+   Note:
+      The interval between transmissions, and the total number of
+      retransmissions, should be operational parameters specifiable by
+      the name server administrator, perhaps on a per-zone basis.
+      Reasonable defaults are a 60 second interval (or timeout if
+      using TCP), and a maximum of 5 retransmissions (for UDP).  It is
+      considered reasonable to use additive or exponential backoff for
+      the retry interval.
+
+   3.7. A NOTIFY request has QDCOUNT>0, ANCOUNT>=0, AUCOUNT>=0,
+   ADCOUNT>=0.  If ANCOUNT>0, then the answer section represents an
+   unsecure hint at the new RRset for this <QNAME,QCLASS,QTYPE>.  A
+   slave receiving such a hint is free to treat equivilence of this
+   answer section with its local data as a "no further work needs to be
+   done" indication.  If ANCOUNT=0, or ANCOUNT>0 and the answer section
+   differs from the slave's local data, then the slave should query its
+   known masters to retrieve the new data.
+
+   3.8. In no case shall the answer section of a NOTIFY request be used
+   to update a slave's local data, or to indicate that a zone transfer
+   needs to be undertaken, or to change the slave's zone refresh timers.
+
+
+
+Vixie                       Standards Track                     [Page 3]
+
+RFC 1996                       DNS NOTIFY                    August 1996
+
+
+   Only a "data present; data same" condition can lead a slave to act
+   differently if ANCOUNT>0 than it would if ANCOUNT=0.
+
+   3.9. This version of the NOTIFY specification makes no use of the
+   authority or additional data sections, and so conforming
+   implementations should set AUCOUNT=0 and ADCOUNT=0 when transmitting
+   requests.  Since a future revision of this specification may define a
+   backwards compatible use for either or both of these sections,
+   current implementations must ignore these sections, but not the
+   entire message, if AUCOUNT>0 and/or ADCOUNT>0.
+
+   3.10. If a slave receives a NOTIFY request from a host that is not a
+   known master for the zone containing the QNAME, it should ignore the
+   request and produce an error message in its operations log.
+
+   Note:
+      This implies that slaves of a multihomed master must either know
+      their master by the "closest" of the master's interface
+      addresses, or must know all of the master's interface addresses.
+      Otherwise, a valid NOTIFY request might come from an address
+      that is not on the slave's state list of masters for the zone,
+      which would be an error.
+
+   3.11. The only defined NOTIFY event at this time is that the SOA RR
+   has changed.  Upon completion of a NOTIFY transaction for QTYPE=SOA,
+   the slave should behave as though the zone given in the QNAME had
+   reached its REFRESH interval (see [RFC1035]), i.e., it should query
+   its masters for the SOA of the zone given in the NOTIFY QNAME, and
+   check the answer to see if the SOA SERIAL has been incremented since
+   the last time the zone was fetched.  If so, a zone transfer (either
+   AXFR or IXFR) should be initiated.
+
+   Note:
+      Because a deep server dependency graph may have multiple paths
+      from the primary master to any given slave, it is possible that
+      a slave will receive a NOTIFY from one of its known masters even
+      though the rest of its known masters have not yet updated their
+      copies of the zone.  Therefore, when issuing a QUERY for the
+      zone's SOA, the query should be directed at the known master who
+      was the source of the NOTIFY event, and not at any of the other
+      known masters.  This represents a departure from [RFC1035],
+      which specifies that upon expiry of the SOA REFRESH interval,
+      all known masters should be queried in turn.
+
+   3.12. If a NOTIFY request is received by a slave who does not
+   implement the NOTIFY opcode, it will respond with a NOTIMP
+   (unimplemented feature error) message.  A master server who receives
+   such a NOTIMP should consider the NOTIFY transaction complete for
+
+
+
+Vixie                       Standards Track                     [Page 4]
+
+RFC 1996                       DNS NOTIFY                    August 1996
+
+
+   that slave.
+
+4. Details and Examples
+
+   4.1. Retaining query state information across host reboots is
+   optional, but it is reasonable to simply execute an SOA NOTIFY
+   transaction on each authority zone when a server first starts.
+
+   4.2. Each slave is likely to receive several copies of the same
+   NOTIFY request:  One from the primary master, and one from each other
+   slave as that slave transfers the new zone and notifies its potential
+   peers.  The NOTIFY protocol supports this multiplicity by requiring
+   that NOTIFY be sent by a slave/master only AFTER it has updated the
+   SOA RR or has determined that no update is necessary, which in
+   practice means after a successful zone transfer.  Thus, barring
+   delivery reordering, the last NOTIFY any slave receives will be the
+   one indicating the latest change.  Since a slave always requests SOAs
+   and AXFR/IXFRs only from its known masters, it will have an
+   opportunity to retry its QUERY for the SOA after each of its masters
+   have completed each zone update.
+
+   4.3. If a master server seeks to avoid causing a large number of
+   simultaneous outbound zone transfers, it may delay for an arbitrary
+   length of time before sending a NOTIFY message to any given slave.
+   It is expected that the time will be chosen at random, so that each
+   slave will begin its transfer at a unique time.  The delay shall not
+   in any case be longer than the SOA REFRESH time.
+
+   Note:
+      This delay should be a parameter that each primary master name
+      server can specify, perhaps on a per-zone basis.  Random delays
+      of between 30 and 60 seconds would seem adequate if the servers
+      share a LAN and the zones are of moderate size.
+
+   4.4. A slave which receives a valid NOTIFY should defer action on any
+   subsequent NOTIFY with the same <QNAME,QCLASS,QTYPE> until it has
+   completed the transaction begun by the first NOTIFY.  This duplicate
+   rejection is necessary to avoid having multiple notifications lead to
+   pummeling the master server.
+
+
+
+
+
+
+
+
+
+
+
+
+Vixie                       Standards Track                     [Page 5]
+
+RFC 1996                       DNS NOTIFY                    August 1996
+
+
+   4.5 Zone has Updated on Primary Master
+
+   Primary master sends a NOTIFY request to all servers named in Notify
+   Set.  The NOTIFY request has the following characteristics:
+
+      query ID:   (new)
+      op:         NOTIFY (4)
+      resp:       NOERROR
+      flags:      AA
+      qcount:     1
+      qname:      (zone name)
+      qclass:     (zone class)
+      qtype:      T_SOA
+
+   4.6 Zone has Updated on a Slave that is also a Master
+
+   As above in 4.5, except that this server's Notify Set may be
+   different from the Primary Master's due to optional static
+   specification of local stealth servers.
+
+   4.7 Slave Receives a NOTIFY Request from a Master
+
+   When a slave server receives a NOTIFY request from one of its locally
+   designated masters for the zone enclosing the given QNAME, with
+   QTYPE=SOA and QR=0, it should enter the state it would if the zone's
+   refresh timer had expired.  It will also send a NOTIFY response back
+   to the NOTIFY request's source, with the following characteristics:
+
+      query ID:   (same)
+      op:         NOTIFY (4)
+      resp:       NOERROR
+      flags:      QR AA
+      qcount:     1
+      qname:      (zone name)
+      qclass:     (zone class)
+      qtype:      T_SOA
+
+   This is intended to be identical to the NOTIFY request, except that
+   the QR bit is also set.  The query ID of the response must be the
+   same as was received in the request.
+
+   4.8 Master Receives a NOTIFY Response from Slave
+
+   When a master server receives a NOTIFY response, it deletes this
+   query from the retry queue, thus completing the "notification
+   process" of "this" RRset change to "that" server.
+
+
+
+
+
+Vixie                       Standards Track                     [Page 6]
+
+RFC 1996                       DNS NOTIFY                    August 1996
+
+
+5. Security Considerations
+
+   We believe that the NOTIFY operation's only security considerations
+   are:
+
+   1. That a NOTIFY request with a forged IP/UDP source address can
+      cause a slave to send spurious SOA queries to its masters,
+      leading to a benign denial of service attack if the forged
+      requests are sent very often.
+
+   2. That TCP spoofing could be used against a slave server given
+      NOTIFY as a means of synchronizing an SOA query and UDP/DNS
+      spoofing as a means of forcing a zone transfer.
+
+6. References
+
+   [RFC1035]
+      Mockapetris, P., "Domain Names - Implementation and
+      Specification", STD 13, RFC 1035, November 1987.
+
+   [IXFR]
+      Ohta, M., "Incremental Zone Transfer", RFC 1995, August 1996.
+
+7. Author's Address
+
+   Paul Vixie
+   Internet Software Consortium
+   Star Route Box 159A
+   Woodside, CA 94062
+
+   Phone: +1 415 747 0204
+   EMail: paul@vix.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Vixie                       Standards Track                     [Page 7]
+
diff --git a/doc/rfc/rfc2052.txt b/doc/rfc/rfc2052.txt
new file mode 100644
index 0000000..46ba362
--- /dev/null
+++ b/doc/rfc/rfc2052.txt
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+Network Working Group                                     A. Gulbrandsen
+Request for Comments: 2052                            Troll Technologies
+Updates: 1035, 1183                                             P. Vixie
+Category: Experimental                                 Vixie Enterprises
+                                                            October 1996
+
+
+       A DNS RR for specifying the location of services (DNS SRV)
+
+Status of this Memo
+
+   This memo defines an Experimental Protocol for the Internet
+   community.  This memo does not specify an Internet standard of any
+   kind.  Discussion and suggestions for improvement are requested.
+   Distribution of this memo is unlimited.
+
+Abstract
+
+   This document describes a DNS RR which specifies the location of the
+   server(s) for a specific protocol and domain (like a more general
+   form of MX).
+
+Overview and rationale
+
+   Currently, one must either know the exact address of a server to
+   contact it, or broadcast a question.  This has led to, for example,
+   ftp.whatever.com aliases, the SMTP-specific MX RR, and using MAC-
+   level broadcasts to locate servers.
+
+   The SRV RR allows administrators to use several servers for a single
+   domain, to move services from host to host with little fuss, and to
+   designate some hosts as primary servers for a service and others as
+   backups.
+
+   Clients ask for a specific service/protocol for a specific domain
+   (the word domain is used here in the strict RFC 1034 sense), and get
+   back the names of any available servers.
+
+Introductory example
+
+   When a SRV-cognizant web-browser wants to retrieve
+
+      http://www.asdf.com/
+
+   it does a lookup of
+
+      http.tcp.www.asdf.com
+
+
+
+
+Gulbrandsen & Vixie           Experimental                      [Page 1]
+
+RFC 2052                       DNS SRV RR                   October 1996
+
+
+   and retrieves the document from one of the servers in the reply.  The
+   example zone file near the end of the memo contains answering RRs for
+   this query.
+
+The format of the SRV RR
+
+   Here is the format of the SRV RR, whose DNS type code is 33:
+
+        Service.Proto.Name TTL Class SRV Priority Weight Port Target
+
+        (There is an example near the end of this document.)
+
+   Service
+        The symbolic name of the desired service, as defined in Assigned
+        Numbers or locally.
+
+        Some widely used services, notably POP, don't have a single
+        universal name.  If Assigned Numbers names the service
+        indicated, that name is the only name which is legal for SRV
+        lookups.  Only locally defined services may be named locally.
+        The Service is case insensitive.
+
+   Proto
+        TCP and UDP are at present the most useful values
+        for this field, though any name defined by Assigned Numbers or
+        locally may be used (as for Service).  The Proto is case
+        insensitive.
+
+   Name
+        The domain this RR refers to.  The SRV RR is unique in that the
+        name one searches for is not this name; the example near the end
+        shows this clearly.
+
+   TTL
+        Standard DNS meaning.
+
+   Class
+        Standard DNS meaning.
+
+   Priority
+        As for MX, the priority of this target host.  A client MUST
+        attempt to contact the target host with the lowest-numbered
+        priority it can reach; target hosts with the same priority
+        SHOULD be tried in pseudorandom order.  The range is 0-65535.
+
+
+
+
+
+
+
+Gulbrandsen & Vixie           Experimental                      [Page 2]
+
+RFC 2052                       DNS SRV RR                   October 1996
+
+
+   Weight
+        Load balancing mechanism.  When selecting a target host among
+        the those that have the same priority, the chance of trying this
+        one first SHOULD be proportional to its weight.  The range of
+        this number is 1-65535.  Domain administrators are urged to use
+        Weight 0 when there isn't any load balancing to do, to make the
+        RR easier to read for humans (less noisy).
+
+   Port
+        The port on this target host of this service.  The range is
+        0-65535.  This is often as specified in Assigned Numbers but
+        need not be.
+
+   Target
+        As for MX, the domain name of the target host.  There MUST be
+        one or more A records for this name. Implementors are urged, but
+        not required, to return the A record(s) in the Additional Data
+        section.  Name compression is to be used for this field.
+
+        A Target of "." means that the service is decidedly not
+        available at this domain.
+
+Domain administrator advice
+
+   Asking everyone to update their telnet (for example) clients when the
+   first internet site adds a SRV RR for Telnet/TCP is futile (even if
+   desirable).  Therefore SRV will have to coexist with A record lookups
+   for a long time, and DNS administrators should try to provide A
+   records to support old clients:
+
+      - Where the services for a single domain are spread over several
+        hosts, it seems advisable to have a list of A RRs at the same
+        DNS node as the SRV RR, listing reasonable (if perhaps
+        suboptimal) fallback hosts for Telnet, NNTP and other protocols
+        likely to be used with this name.  Note that some programs only
+        try the first address they get back from e.g. gethostbyname(),
+        and we don't know how widespread this behaviour is.
+
+      - Where one service is provided by several hosts, one can either
+        provide A records for all the hosts (in which case the round-
+        robin mechanism, where available, will share the load equally)
+        or just for one (presumably the fastest).
+
+      - If a host is intended to provide a service only when the main
+        server(s) is/are down, it probably shouldn't be listed in A
+        records.
+
+
+
+
+
+Gulbrandsen & Vixie           Experimental                      [Page 3]
+
+RFC 2052                       DNS SRV RR                   October 1996
+
+
+      - Hosts that are referenced by backup A records must use the port
+        number specified in Assigned Numbers for the service.
+
+   Currently there's a practical limit of 512 bytes for DNS replies.
+   Until all resolvers can handle larger responses, domain
+   administrators are strongly advised to keep their SRV replies below
+   512 bytes.
+
+   All round numbers, wrote Dr. Johnson, are false, and these numbers
+   are very round: A reply packet has a 30-byte overhead plus the name
+   of the service ("telnet.tcp.asdf.com" for instance); each SRV RR adds
+   20 bytes plus the name of the target host; each NS RR in the NS
+   section is 15 bytes plus the name of the name server host; and
+   finally each A RR in the additional data section is 20 bytes or so,
+   and there are A's for each SRV and NS RR mentioned in the answer.
+   This size estimate is extremely crude, but shouldn't underestimate
+   the actual answer size by much.  If an answer may be close to the
+   limit, using e.g. "dig" to look at the actual answer is a good idea.
+
+The "Weight" field
+
+   Weight, the load balancing field, is not quite satisfactory, but the
+   actual load on typical servers changes much too quickly to be kept
+   around in DNS caches.  It seems to the authors that offering
+   administrators a way to say "this machine is three times as fast as
+   that one" is the best that can practically be done.
+
+   The only way the authors can see of getting a "better" load figure is
+   asking a separate server when the client selects a server and
+   contacts it.  For short-lived services like SMTP an extra step in the
+   connection establishment seems too expensive, and for long-lived
+   services like telnet, the load figure may well be thrown off a minute
+   after the connection is established when someone else starts or
+   finishes a heavy job.
+
+The Port number
+
+   Currently, the translation from service name to port number happens
+   at the client, often using a file such as /etc/services.
+
+   Moving this information to the DNS makes it less necessary to update
+   these files on every single computer of the net every time a new
+   service is added, and makes it possible to move standard services out
+   of the "root-only" port range on unix
+
+
+
+
+
+
+
+Gulbrandsen & Vixie           Experimental                      [Page 4]
+
+RFC 2052                       DNS SRV RR                   October 1996
+
+
+Usage rules
+
+   A SRV-cognizant client SHOULD use this procedure to locate a list of
+   servers and connect to the preferred one:
+
+        Do a lookup for QNAME=service.protocol.target, QCLASS=IN,
+        QTYPE=SRV.
+
+        If the reply is NOERROR, ANCOUNT>0 and there is at least one SRV
+        RR which specifies the requested Service and Protocol in the
+        reply:
+
+             If there is precisely one SRV RR, and its Target is "."
+             (the root domain), abort.
+
+             Else, for all such RR's, build a list of (Priority, Weight,
+             Target) tuples
+
+             Sort the list by priority (lowest number first)
+
+             Create a new empty list
+
+             For each distinct priority level
+                  While there are still elements left at this priority
+                  level
+                       Select an element randomly, with probability
+                       Weight, and move it to the tail of the new list
+
+             For each element in the new list
+
+                  query the DNS for A RR's for the Target or use any
+                  RR's found in the Additional Data secion of the
+                  earlier SRV query.
+
+                  for each A RR found, try to connect to the (protocol,
+                  address, service).
+
+        else if the service desired is SMTP
+
+             skip to RFC 974 (MX).
+
+        else
+
+             Do a lookup for QNAME=target, QCLASS=IN, QTYPE=A
+
+             for each A RR found, try to connect to the (protocol,
+             address, service)
+
+
+
+
+Gulbrandsen & Vixie           Experimental                      [Page 5]
+
+RFC 2052                       DNS SRV RR                   October 1996
+
+
+   Notes:
+
+      - Port numbers SHOULD NOT be used in place of the symbolic service
+        or protocol names (for the same reason why variant names cannot
+        be allowed: Applications would have to do two or more lookups).
+
+      - If a truncated response comes back from an SRV query, and the
+        Additional Data section has at least one complete RR in it, the
+        answer MUST be considered complete and the client resolver
+        SHOULD NOT retry the query using TCP, but use normal UDP queries
+        for A RR's missing from the Additional Data section.
+
+      - A client MAY use means other than Weight to choose among target
+        hosts with equal Priority.
+
+      - A client MUST parse all of the RR's in the reply.
+
+      - If the Additional Data section doesn't contain A RR's for all
+        the SRV RR's and the client may want to connect to the target
+        host(s) involved, the client MUST look up the A RR(s).  (This
+        happens quite often when the A RR has shorter TTL than the SRV
+        or NS RR's.)
+
+      - A future standard could specify that a SRV RR whose Protocol was
+        TCP and whose Service was SMTP would override RFC 974's rules
+        with regard to the use of an MX RR.  This would allow firewalled
+        organizations with several SMTP relays to control the load
+        distribution using the Weight field.
+
+      - Future protocols could be designed to use SRV RR lookups as the
+        means by which clients locate their servers.
+
+Fictional example
+
+   This is (part of) the zone file for asdf.com, a still-unused domain:
+
+        $ORIGIN asdf.com.
+        @               SOA server.asdf.com. root.asdf.com. (
+                            1995032001 3600 3600 604800 86400 )
+                        NS  server.asdf.com.
+                        NS  ns1.ip-provider.net.
+                        NS  ns2.ip-provider.net.
+        ftp.tcp         SRV 0 0 21 server.asdf.com.
+        finger.tcp      SRV 0 0 79 server.asdf.com.
+        ; telnet - use old-slow-box or new-fast-box if either is
+        ; available, make three quarters of the logins go to
+        ; new-fast-box.
+        telnet.tcp      SRV 0 1 23 old-slow-box.asdf.com.
+
+
+
+Gulbrandsen & Vixie           Experimental                      [Page 6]
+
+RFC 2052                       DNS SRV RR                   October 1996
+
+
+                        SRV 0 3 23 new-fast-box.asdf.com.
+        ; if neither old-slow-box or new-fast-box is up, switch to
+        ; using the sysdmin's box and the server
+                        SRV 1 0 23 sysadmins-box.asdf.com.
+                        SRV 1 0 23 server.asdf.com.
+        ; HTTP - server is the main server, new-fast-box is the backup
+        ; (On new-fast-box, the HTTP daemon runs on port 8000)
+        http.tcp        SRV 0 0 80 server.asdf.com.
+                        SRV 10 0 8000 new-fast-box.asdf.com.
+        ; since we want to support both http://asdf.com/ and
+        ; http://www.asdf.com/ we need the next two RRs as well
+        http.tcp.www    SRV 0 0 80 server.asdf.com.
+                        SRV 10 0 8000 new-fast-box.asdf.com.
+        ; SMTP - mail goes to the server, and to the IP provider if
+        ; the net is down
+        smtp.tcp        SRV 0 0 25 server.asdf.com.
+                        SRV 1 0 25 mailhost.ip-provider.net.
+        @               MX  0 server.asdf.com.
+                        MX  1 mailhost.ip-provider.net.
+        ; NNTP - use the IP providers's NNTP server
+        nntp.tcp        SRV 0 0 119 nntphost.ip-provider.net.
+        ; IDB is an locally defined protocol
+        idb.tcp         SRV  0 0 2025 new-fast-box.asdf.com.
+        ; addresses
+        server          A   172.30.79.10
+        old-slow-box    A   172.30.79.11
+        sysadmins-box   A   172.30.79.12
+        new-fast-box    A   172.30.79.13
+        ; backup A records - new-fast-box and old-slow-box are
+        ; included, naturally, and server is too, but might go
+        ; if the load got too bad
+        @               A   172.30.79.10
+                        A   172.30.79.11
+                        A   172.30.79.13
+        ; backup A RR for www.asdf.com
+        www             A       172.30.79.10
+        ; NO other services are supported
+        *.tcp           SRV  0 0 0 .
+        *.udp           SRV  0 0 0 .
+
+   In this example, a telnet connection to "asdf.com." needs an SRV
+   lookup of "telnet.tcp.asdf.com." and possibly A lookups of "new-
+   fast-box.asdf.com." and/or the other hosts named.  The size of the
+   SRV reply is approximately 365 bytes:
+
+      30 bytes general overhead
+      20 bytes for the query string, "telnet.tcp.asdf.com."
+      130 bytes for 4 SRV RR's, 20 bytes each plus the lengths of "new-
+
+
+
+Gulbrandsen & Vixie           Experimental                      [Page 7]
+
+RFC 2052                       DNS SRV RR                   October 1996
+
+
+        fast-box", "old-slow-box", "server" and "sysadmins-box" -
+        "asdf.com" in the query section is quoted here and doesn't
+        need to be counted again.
+      75 bytes for 3 NS RRs, 15 bytes each plus the lengths of
+        "server", "ns1.ip-provider.net." and "ns2" - again, "ip-
+        provider.net." is quoted and only needs to be counted once.
+      120 bytes for the 6 A RR's mentioned by the SRV and NS RR's.
+
+Refererences
+
+   RFC 1918: Rekhter, Y., Moskowitz, R., Karrenberg, D., de Groot, G.,
+        and E.  Lear, "Address Allocation for Private Internets",
+        RFC 1918, February 1996.
+
+   RFC 1916 Berkowitz, H., Ferguson, P, Leland, W. and P. Nesser,
+        "Enterprise Renumbering: Experience and Information
+        Solicitation", RFC 1916, February 1996.
+
+   RFC 1912 Barr, D., "Common DNS Operational and Configuration
+        Errors", RFC 1912, February 1996.
+
+   RFC 1900: Carpenter, B., and Y. Rekhter, "Renumbering Needs Work",
+        RFC 1900, February 1996.
+
+   RFC 1920: Postel, J., "INTERNET OFFICIAL PROTOCOL STANDARDS",
+        STD 1, RFC 1920, March 1996.
+
+   RFC 1814: Gerich, E., "Unique Addresses are Good", RFC 1814, June
+             1995.
+
+   RFC 1794: Brisco, T., "DNS Support for Load Balancing", April 1995.
+
+   RFC 1713: Romao, A., "Tools for DNS debugging", November 1994.
+
+   RFC 1712: Farrell, C., Schulze, M., Pleitner, S., and D. Baldoni,
+        "DNS Encoding of Geographical Location", RFC 1712, November
+        1994.
+
+   RFC 1706: Manning, B. and R. Colella, "DNS NSAP Resource Records",
+        RFC 1706, October 1994.
+
+   RFC 1700: Reynolds, J., and J. Postel, "ASSIGNED NUMBERS",
+        STD 2, RFC 1700, October 1994.
+
+   RFC 1183: Ullmann, R., Mockapetris, P., Mamakos, L., and
+        C. Everhart, "New DNS RR Definitions", RFC 1183, November
+        1990.
+
+
+
+
+Gulbrandsen & Vixie           Experimental                      [Page 8]
+
+RFC 2052                       DNS SRV RR                   October 1996
+
+
+   RFC 1101: Mockapetris, P., "DNS encoding of network names and other
+        types", RFC 1101, April 1989.
+
+   RFC 1035: Mockapetris, P., "Domain names - implementation and
+        specification", STD 13, RFC 1035, November 1987.
+
+   RFC 1034: Mockapetris, P., "Domain names - concepts and
+        facilities", STD 13, RFC 1034, November 1987.
+
+   RFC 1033: Lottor, M., "Domain administrators operations guide",
+        RFC 1033, November 1987.
+
+   RFC 1032: Stahl, M., "Domain administrators guide", RFC 1032,
+        November 1987.
+
+   RFC 974: Partridge, C., "Mail routing and the domain system",
+        STD 14, RFC 974, January 1986.
+
+Security Considerations
+
+   The authors believes this RR to not cause any new security problems.
+   Some problems become more visible, though.
+
+      - The ability to specify ports on a fine-grained basis obviously
+        changes how a router can filter packets.  It becomes impossible
+        to block internal clients from accessing specific external
+        services, slightly harder to block internal users from running
+        unautorised services, and more important for the router
+        operations and DNS operations personnel to cooperate.
+
+      - There is no way a site can keep its hosts from being referenced
+        as servers (as, indeed, some sites become unwilling secondary
+        MXes today).  This could lead to denial of service.
+
+      - With SRV, DNS spoofers can supply false port numbers, as well as
+        host names and addresses.  The authors do not see any practical
+        effect of this.
+
+   We assume that as the DNS-security people invent new features, DNS
+   servers will return the relevant RRs in the Additional Data section
+   when answering an SRV query.
+
+
+
+
+
+
+
+
+
+
+Gulbrandsen & Vixie           Experimental                      [Page 9]
+
+RFC 2052                       DNS SRV RR                   October 1996
+
+
+Authors' Addresses
+
+   Arnt Gulbrandsen
+   Troll Tech
+   Postboks 6133 Etterstad
+   N-0602 Oslo
+   Norway
+
+   Phone: +47 22646966
+   EMail: agulbra@troll.no
+
+
+   Paul Vixie
+   Vixie Enterprises
+   Star Route 159A
+   Woodside, CA  94062
+
+   Phone: (415) 747-0204
+   EMail: paul@vix.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gulbrandsen & Vixie           Experimental                     [Page 10]
+
diff --git a/doc/rfc/rfc2104.txt b/doc/rfc/rfc2104.txt
new file mode 100644
index 0000000..a205103
--- /dev/null
+++ b/doc/rfc/rfc2104.txt
@@ -0,0 +1,620 @@
+
+
+
+
+
+
+Network Working Group                                       H. Krawczyk
+Request for Comments: 2104                                          IBM
+Category: Informational                                      M. Bellare
+                                                                   UCSD
+                                                             R. Canetti
+                                                                    IBM
+                                                          February 1997
+
+
+             HMAC: Keyed-Hashing for Message Authentication
+
+Status of This Memo
+
+   This memo provides information for the Internet community.  This memo
+   does not specify an Internet standard of any kind.  Distribution of
+   this memo is unlimited.
+
+Abstract
+
+   This document describes HMAC, a mechanism for message authentication
+   using cryptographic hash functions. HMAC can be used with any
+   iterative cryptographic hash function, e.g., MD5, SHA-1, in
+   combination with a secret shared key.  The cryptographic strength of
+   HMAC depends on the properties of the underlying hash function.
+
+1. Introduction
+
+   Providing a way to check the integrity of information transmitted
+   over or stored in an unreliable medium is a prime necessity in the
+   world of open computing and communications. Mechanisms that provide
+   such integrity check based on a secret key are usually called
+   "message authentication codes" (MAC). Typically, message
+   authentication codes are used between two parties that share a secret
+   key in order to validate information transmitted between these
+   parties. In this document we present such a MAC mechanism based on
+   cryptographic hash functions. This mechanism, called HMAC, is based
+   on work by the authors [BCK1] where the construction is presented and
+   cryptographically analyzed. We refer to that work for the details on
+   the rationale and security analysis of HMAC, and its comparison to
+   other keyed-hash methods.
+
+
+
+
+
+
+
+
+
+
+
+Krawczyk, et. al.            Informational                      [Page 1]
+
+RFC 2104                          HMAC                     February 1997
+
+
+   HMAC can be used in combination with any iterated cryptographic hash
+   function. MD5 and SHA-1 are examples of such hash functions. HMAC
+   also uses a secret key for calculation and verification of the
+   message authentication values. The main goals behind this
+   construction are
+
+   * To use, without modifications, available hash functions.
+     In particular, hash functions that perform well in software,
+     and for which code is freely and widely available.
+
+   * To preserve the original performance of the hash function without
+     incurring a significant degradation.
+
+   * To use and handle keys in a simple way.
+
+   * To have a well understood cryptographic analysis of the strength of
+     the authentication mechanism based on reasonable assumptions on the
+     underlying hash function.
+
+   * To allow for easy replaceability of the underlying hash function in
+     case that faster or more secure hash functions are found or
+     required.
+
+   This document specifies HMAC using a generic cryptographic hash
+   function (denoted by H). Specific instantiations of HMAC need to
+   define a particular hash function. Current candidates for such hash
+   functions include SHA-1 [SHA], MD5 [MD5], RIPEMD-128/160 [RIPEMD].
+   These different realizations of HMAC will be denoted by HMAC-SHA1,
+   HMAC-MD5, HMAC-RIPEMD, etc.
+
+   Note: To the date of writing of this document MD5 and SHA-1 are the
+   most widely used cryptographic hash functions. MD5 has been recently
+   shown to be vulnerable to collision search attacks [Dobb].  This
+   attack and other currently known weaknesses of MD5 do not compromise
+   the use of MD5 within HMAC as specified in this document (see
+   [Dobb]); however, SHA-1 appears to be a cryptographically stronger
+   function. To this date, MD5 can be considered for use in HMAC for
+   applications where the superior performance of MD5 is critical.   In
+   any case, implementers and users need to be aware of possible
+   cryptanalytic developments regarding any of these cryptographic hash
+   functions, and the eventual need to replace the underlying hash
+   function. (See section 6 for more information on the security of
+   HMAC.)
+
+
+
+
+
+
+
+
+Krawczyk, et. al.            Informational                      [Page 2]
+
+RFC 2104                          HMAC                     February 1997
+
+
+2. Definition of HMAC
+
+   The definition of HMAC requires a cryptographic hash function, which
+   we denote by H, and a secret key K. We assume H to be a cryptographic
+   hash function where data is hashed by iterating a basic compression
+   function on blocks of data.   We denote by B the byte-length of such
+   blocks (B=64 for all the above mentioned examples of hash functions),
+   and by L the byte-length of hash outputs (L=16 for MD5, L=20 for
+   SHA-1).  The authentication key K can be of any length up to B, the
+   block length of the hash function.  Applications that use keys longer
+   than B bytes will first hash the key using H and then use the
+   resultant L byte string as the actual key to HMAC. In any case the
+   minimal recommended length for K is L bytes (as the hash output
+   length). See section 3 for more information on keys.
+
+   We define two fixed and different strings ipad and opad as follows
+   (the 'i' and 'o' are mnemonics for inner and outer):
+
+                   ipad = the byte 0x36 repeated B times
+                  opad = the byte 0x5C repeated B times.
+
+   To compute HMAC over the data `text' we perform
+
+                    H(K XOR opad, H(K XOR ipad, text))
+
+   Namely,
+
+    (1) append zeros to the end of K to create a B byte string
+        (e.g., if K is of length 20 bytes and B=64, then K will be
+         appended with 44 zero bytes 0x00)
+    (2) XOR (bitwise exclusive-OR) the B byte string computed in step
+        (1) with ipad
+    (3) append the stream of data 'text' to the B byte string resulting
+        from step (2)
+    (4) apply H to the stream generated in step (3)
+    (5) XOR (bitwise exclusive-OR) the B byte string computed in
+        step (1) with opad
+    (6) append the H result from step (4) to the B byte string
+        resulting from step (5)
+    (7) apply H to the stream generated in step (6) and output
+        the result
+
+   For illustration purposes, sample code based on MD5 is provided as an
+   appendix.
+
+
+
+
+
+
+
+Krawczyk, et. al.            Informational                      [Page 3]
+
+RFC 2104                          HMAC                     February 1997
+
+
+3. Keys
+
+   The key for HMAC can be of any length (keys longer than B bytes are
+   first hashed using H).  However, less than L bytes is strongly
+   discouraged as it would decrease the security strength of the
+   function.  Keys longer than L bytes are acceptable but the extra
+   length would not significantly increase the function strength. (A
+   longer key may be advisable if the randomness of the key is
+   considered weak.)
+
+   Keys need to be chosen at random (or using a cryptographically strong
+   pseudo-random generator seeded with a random seed), and periodically
+   refreshed.  (Current attacks do not indicate a specific recommended
+   frequency for key changes as these attacks are practically
+   infeasible.  However, periodic key refreshment is a fundamental
+   security practice that helps against potential weaknesses of the
+   function and keys, and limits the damage of an exposed key.)
+
+4. Implementation Note
+
+   HMAC is defined in such a way that the underlying hash function H can
+   be used with no modification to its code. In particular, it uses the
+   function H with the pre-defined initial value IV (a fixed value
+   specified by each iterative hash function to initialize its
+   compression function).  However, if desired, a performance
+   improvement can be achieved at the cost of (possibly) modifying the
+   code of H to support variable IVs.
+
+   The idea is that the intermediate results of the compression function
+   on the B-byte blocks (K XOR ipad) and (K XOR opad) can be precomputed
+   only once at the time of generation of the key K, or before its first
+   use. These intermediate results are stored and then used to
+   initialize the IV of H each time that a message needs to be
+   authenticated.  This method saves, for each authenticated message,
+   the application of the compression function of H on two B-byte blocks
+   (i.e., on (K XOR ipad) and (K XOR opad)). Such a savings may be
+   significant when authenticating short streams of data.  We stress
+   that the stored intermediate values need to be treated and protected
+   the same as secret keys.
+
+   Choosing to implement HMAC in the above way is a decision of the
+   local implementation and has no effect on inter-operability.
+
+
+
+
+
+
+
+
+
+Krawczyk, et. al.            Informational                      [Page 4]
+
+RFC 2104                          HMAC                     February 1997
+
+
+5. Truncated output
+
+   A well-known practice with message authentication codes is to
+   truncate the output of the MAC and output only part of the bits
+   (e.g., [MM, ANSI]).  Preneel and van Oorschot [PV] show some
+   analytical advantages of truncating the output of hash-based MAC
+   functions. The results in this area are not absolute as for the
+   overall security advantages of truncation. It has advantages (less
+   information on the hash result available to an attacker) and
+   disadvantages (less bits to predict for the attacker).  Applications
+   of HMAC can choose to truncate the output of HMAC by outputting the t
+   leftmost bits of the HMAC computation for some parameter t (namely,
+   the computation is carried in the normal way as defined in section 2
+   above but the end result is truncated to t bits). We recommend that
+   the output length t be not less than half the length of the hash
+   output (to match the birthday attack bound) and not less than 80 bits
+   (a suitable lower bound on the number of bits that need to be
+   predicted by an attacker).  We propose denoting a realization of HMAC
+   that uses a hash function H with t bits of output as HMAC-H-t. For
+   example, HMAC-SHA1-80 denotes HMAC computed using the SHA-1 function
+   and with the output truncated to 80 bits.  (If the parameter t is not
+   specified, e.g. HMAC-MD5, then it is assumed that all the bits of the
+   hash are output.)
+
+6. Security
+
+   The security of the message authentication mechanism presented here
+   depends on cryptographic properties of the hash function H: the
+   resistance to collision finding (limited to the case where the
+   initial value is secret and random, and where the output of the
+   function is not explicitly available to the attacker), and the
+   message authentication property of the compression function of H when
+   applied to single blocks (in HMAC these blocks are partially unknown
+   to an attacker as they contain the result of the inner H computation
+   and, in particular, cannot be fully chosen by the attacker).
+
+   These properties, and actually stronger ones, are commonly assumed
+   for hash functions of the kind used with HMAC. In particular, a hash
+   function for which the above properties do not hold would become
+   unsuitable for most (probably, all) cryptographic applications,
+   including alternative message authentication schemes based on such
+   functions.  (For a complete analysis and rationale of the HMAC
+   function the reader is referred to [BCK1].)
+
+
+
+
+
+
+
+
+Krawczyk, et. al.            Informational                      [Page 5]
+
+RFC 2104                          HMAC                     February 1997
+
+
+   Given the limited confidence gained so far as for the cryptographic
+   strength of candidate hash functions, it is important to observe the
+   following two properties of the HMAC construction and its secure use
+   for message authentication:
+
+   1. The construction is independent of the details of the particular
+   hash function H in use and then the latter can be replaced by any
+   other secure (iterative) cryptographic hash function.
+
+   2. Message authentication, as opposed to encryption, has a
+   "transient" effect. A published breaking of a message authentication
+   scheme would lead to the replacement of that scheme, but would have
+   no adversarial effect on information authenticated in the past.  This
+   is in sharp contrast with encryption, where information encrypted
+   today may suffer from exposure in the future if, and when, the
+   encryption algorithm is broken.
+
+   The strongest attack known against HMAC is based on the frequency of
+   collisions for the hash function H ("birthday attack") [PV,BCK2], and
+   is totally impractical for minimally reasonable hash functions.
+
+   As an example, if we consider a hash function like MD5 where the
+   output length equals L=16 bytes (128 bits) the attacker needs to
+   acquire the correct message authentication tags computed (with the
+   _same_ secret key K!) on about 2**64 known plaintexts.  This would
+   require the processing of at least 2**64 blocks under H, an
+   impossible task in any realistic scenario (for a block length of 64
+   bytes this would take 250,000 years in a continuous 1Gbps link, and
+   without changing the secret key K during all this time).  This attack
+   could become realistic only if serious flaws in the collision
+   behavior of the function H are discovered (e.g.  collisions found
+   after 2**30 messages). Such a discovery would determine the immediate
+   replacement of the function H (the effects of such failure would be
+   far more severe for the traditional uses of H in the context of
+   digital signatures, public key certificates, etc.).
+
+   Note: this attack needs to be strongly contrasted with regular
+   collision attacks on cryptographic hash functions where no secret key
+   is involved and where 2**64 off-line parallelizable (!) operations
+   suffice to find collisions.  The latter attack is approaching
+   feasibility [VW] while the birthday attack on HMAC is totally
+   impractical.  (In the above examples, if one uses a hash function
+   with, say, 160 bit of output then 2**64 should be replaced by 2**80.)
+
+
+
+
+
+
+
+
+Krawczyk, et. al.            Informational                      [Page 6]
+
+RFC 2104                          HMAC                     February 1997
+
+
+   A correct implementation of the above construction, the choice of
+   random (or cryptographically pseudorandom) keys, a secure key
+   exchange mechanism, frequent key refreshments, and good secrecy
+   protection of keys are all essential ingredients for the security of
+   the integrity verification mechanism provided by HMAC.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Krawczyk, et. al.            Informational                      [Page 7]
+
+RFC 2104                          HMAC                     February 1997
+
+
+Appendix -- Sample Code
+
+   For the sake of illustration we provide the following sample code for
+   the implementation of HMAC-MD5 as well as some corresponding test
+   vectors (the code is based on MD5 code as described in [MD5]).
+
+/*
+** Function: hmac_md5
+*/
+
+void
+hmac_md5(text, text_len, key, key_len, digest)
+unsigned char*  text;                /* pointer to data stream */
+int             text_len;            /* length of data stream */
+unsigned char*  key;                 /* pointer to authentication key */
+int             key_len;             /* length of authentication key */
+caddr_t         digest;              /* caller digest to be filled in */
+
+{
+        MD5_CTX context;
+        unsigned char k_ipad[65];    /* inner padding -
+                                      * key XORd with ipad
+                                      */
+        unsigned char k_opad[65];    /* outer padding -
+                                      * key XORd with opad
+                                      */
+        unsigned char tk[16];
+        int i;
+        /* if key is longer than 64 bytes reset it to key=MD5(key) */
+        if (key_len > 64) {
+
+                MD5_CTX      tctx;
+
+                MD5Init(&tctx);
+                MD5Update(&tctx, key, key_len);
+                MD5Final(tk, &tctx);
+
+                key = tk;
+                key_len = 16;
+        }
+
+        /*
+         * the HMAC_MD5 transform looks like:
+         *
+         * MD5(K XOR opad, MD5(K XOR ipad, text))
+         *
+         * where K is an n byte key
+         * ipad is the byte 0x36 repeated 64 times
+
+
+
+Krawczyk, et. al.            Informational                      [Page 8]
+
+RFC 2104                          HMAC                     February 1997
+
+
+         * opad is the byte 0x5c repeated 64 times
+         * and text is the data being protected
+         */
+
+        /* start out by storing key in pads */
+        bzero( k_ipad, sizeof k_ipad);
+        bzero( k_opad, sizeof k_opad);
+        bcopy( key, k_ipad, key_len);
+        bcopy( key, k_opad, key_len);
+
+        /* XOR key with ipad and opad values */
+        for (i=0; i<64; i++) {
+                k_ipad[i] ^= 0x36;
+                k_opad[i] ^= 0x5c;
+        }
+        /*
+         * perform inner MD5
+         */
+        MD5Init(&context);                   /* init context for 1st
+                                              * pass */
+        MD5Update(&context, k_ipad, 64)      /* start with inner pad */
+        MD5Update(&context, text, text_len); /* then text of datagram */
+        MD5Final(digest, &context);          /* finish up 1st pass */
+        /*
+         * perform outer MD5
+         */
+        MD5Init(&context);                   /* init context for 2nd
+                                              * pass */
+        MD5Update(&context, k_opad, 64);     /* start with outer pad */
+        MD5Update(&context, digest, 16);     /* then results of 1st
+                                              * hash */
+        MD5Final(digest, &context);          /* finish up 2nd pass */
+}
+
+Test Vectors (Trailing '\0' of a character string not included in test):
+
+  key =         0x0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b
+  key_len =     16 bytes
+  data =        "Hi There"
+  data_len =    8  bytes
+  digest =      0x9294727a3638bb1c13f48ef8158bfc9d
+
+  key =         "Jefe"
+  data =        "what do ya want for nothing?"
+  data_len =    28 bytes
+  digest =      0x750c783e6ab0b503eaa86e310a5db738
+
+  key =         0xAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
+
+
+
+Krawczyk, et. al.            Informational                      [Page 9]
+
+RFC 2104                          HMAC                     February 1997
+
+
+  key_len       16 bytes
+  data =        0xDDDDDDDDDDDDDDDDDDDD...
+                ..DDDDDDDDDDDDDDDDDDDD...
+                ..DDDDDDDDDDDDDDDDDDDD...
+                ..DDDDDDDDDDDDDDDDDDDD...
+                ..DDDDDDDDDDDDDDDDDDDD
+  data_len =    50 bytes
+  digest =      0x56be34521d144c88dbb8c733f0e8b3f6
+
+Acknowledgments
+
+   Pau-Chen Cheng, Jeff Kraemer, and Michael Oehler, have provided
+   useful comments on early drafts, and ran the first interoperability
+   tests of this specification. Jeff and Pau-Chen kindly provided the
+   sample code and test vectors that appear in the appendix.  Burt
+   Kaliski, Bart Preneel, Matt Robshaw, Adi Shamir, and Paul van
+   Oorschot have provided useful comments and suggestions during the
+   investigation of the HMAC construction.
+
+References
+
+   [ANSI]  ANSI X9.9, "American National Standard for Financial
+           Institution Message Authentication (Wholesale)," American
+           Bankers Association, 1981.   Revised 1986.
+
+   [Atk]   Atkinson, R., "IP Authentication Header", RFC 1826, August
+           1995.
+
+   [BCK1]  M. Bellare, R. Canetti, and H. Krawczyk,
+           "Keyed Hash Functions and Message Authentication",
+           Proceedings of Crypto'96, LNCS 1109, pp. 1-15.
+           (http://www.research.ibm.com/security/keyed-md5.html)
+
+   [BCK2]  M. Bellare, R. Canetti, and H. Krawczyk,
+           "Pseudorandom Functions Revisited: The Cascade Construction",
+           Proceedings of FOCS'96.
+
+   [Dobb]  H. Dobbertin, "The Status of MD5  After a Recent Attack",
+           RSA Labs' CryptoBytes, Vol. 2 No. 2, Summer 1996.
+           http://www.rsa.com/rsalabs/pubs/cryptobytes.html
+
+   [PV]    B. Preneel and P. van Oorschot, "Building fast MACs from hash
+           functions", Advances in Cryptology -- CRYPTO'95 Proceedings,
+           Lecture Notes in Computer Science, Springer-Verlag Vol.963,
+           1995, pp. 1-14.
+
+   [MD5]   Rivest, R., "The MD5 Message-Digest Algorithm",
+           RFC 1321, April 1992.
+
+
+
+Krawczyk, et. al.            Informational                     [Page 10]
+
+RFC 2104                          HMAC                     February 1997
+
+
+   [MM]    Meyer, S. and Matyas, S.M., Cryptography, New York Wiley,
+           1982.
+
+   [RIPEMD] H. Dobbertin, A. Bosselaers, and B. Preneel, "RIPEMD-160: A
+            strengthened version of RIPEMD", Fast Software Encryption,
+            LNCS Vol 1039, pp. 71-82.
+            ftp://ftp.esat.kuleuven.ac.be/pub/COSIC/bosselae/ripemd/.
+
+   [SHA]   NIST, FIPS PUB 180-1: Secure Hash Standard, April 1995.
+
+   [Tsu]   G. Tsudik, "Message authentication with one-way hash
+           functions", In Proceedings of Infocom'92, May 1992.
+           (Also in "Access Control and Policy Enforcement in
+            Internetworks", Ph.D. Dissertation, Computer Science
+            Department, University of Southern California, April 1991.)
+
+   [VW]    P. van Oorschot and M. Wiener, "Parallel Collision
+           Search with Applications to Hash Functions and Discrete
+           Logarithms", Proceedings of the 2nd ACM Conf. Computer and
+           Communications Security, Fairfax, VA, November 1994.
+
+Authors' Addresses
+
+   Hugo Krawczyk
+   IBM T.J. Watson Research Center
+   P.O.Box 704
+   Yorktown Heights, NY 10598
+
+   EMail: hugo@watson.ibm.com
+
+   Mihir Bellare
+   Dept of Computer Science and Engineering
+   Mail Code 0114
+   University of California at San Diego
+   9500 Gilman Drive
+   La Jolla, CA 92093
+
+   EMail: mihir@cs.ucsd.edu
+
+   Ran Canetti
+   IBM T.J. Watson Research Center
+   P.O.Box 704
+   Yorktown Heights, NY 10598
+
+   EMail: canetti@watson.ibm.com
+
+
+
+
+
+
+Krawczyk, et. al.            Informational                     [Page 11]
+
+
diff --git a/doc/rfc/rfc2119.txt b/doc/rfc/rfc2119.txt
new file mode 100644
index 0000000..e31fae4
--- /dev/null
+++ b/doc/rfc/rfc2119.txt
@@ -0,0 +1,171 @@
+
+
+
+
+
+
+Network Working Group                                         S. Bradner
+Request for Comments: 2119                            Harvard University
+BCP: 14                                                       March 1997
+Category: Best Current Practice
+
+
+        Key words for use in RFCs to Indicate Requirement Levels
+
+Status of this Memo
+
+   This document specifies an Internet Best Current Practices for the
+   Internet Community, and requests discussion and suggestions for
+   improvements.  Distribution of this memo is unlimited.
+
+Abstract
+
+   In many standards track documents several words are used to signify
+   the requirements in the specification.  These words are often
+   capitalized.  This document defines these words as they should be
+   interpreted in IETF documents.  Authors who follow these guidelines
+   should incorporate this phrase near the beginning of their document:
+
+      The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
+      NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and
+      "OPTIONAL" in this document are to be interpreted as described in
+      RFC 2119.
+
+   Note that the force of these words is modified by the requirement
+   level of the document in which they are used.
+
+1. MUST   This word, or the terms "REQUIRED" or "SHALL", mean that the
+   definition is an absolute requirement of the specification.
+
+2. MUST NOT   This phrase, or the phrase "SHALL NOT", mean that the
+   definition is an absolute prohibition of the specification.
+
+3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
+   may exist valid reasons in particular circumstances to ignore a
+   particular item, but the full implications must be understood and
+   carefully weighed before choosing a different course.
+
+4. SHOULD NOT   This phrase, or the phrase "NOT RECOMMENDED" mean that
+   there may exist valid reasons in particular circumstances when the
+   particular behavior is acceptable or even useful, but the full
+   implications should be understood and the case carefully weighed
+   before implementing any behavior described with this label.
+
+
+
+
+
+Bradner                  Best Current Practice                  [Page 1]
+
+RFC 2119                     RFC Key Words                    March 1997
+
+
+5. MAY   This word, or the adjective "OPTIONAL", mean that an item is
+   truly optional.  One vendor may choose to include the item because a
+   particular marketplace requires it or because the vendor feels that
+   it enhances the product while another vendor may omit the same item.
+   An implementation which does not include a particular option MUST be
+   prepared to interoperate with another implementation which does
+   include the option, though perhaps with reduced functionality. In the
+   same vein an implementation which does include a particular option
+   MUST be prepared to interoperate with another implementation which
+   does not include the option (except, of course, for the feature the
+   option provides.)
+
+6. Guidance in the use of these Imperatives
+
+   Imperatives of the type defined in this memo must be used with care
+   and sparingly.  In particular, they MUST only be used where it is
+   actually required for interoperation or to limit behavior which has
+   potential for causing harm (e.g., limiting retransmisssions)  For
+   example, they must not be used to try to impose a particular method
+   on implementors where the method is not required for
+   interoperability.
+
+7. Security Considerations
+
+   These terms are frequently used to specify behavior with security
+   implications.  The effects on security of not implementing a MUST or
+   SHOULD, or doing something the specification says MUST NOT or SHOULD
+   NOT be done may be very subtle. Document authors should take the time
+   to elaborate the security implications of not following
+   recommendations or requirements as most implementors will not have
+   had the benefit of the experience and discussion that produced the
+   specification.
+
+8. Acknowledgments
+
+   The definitions of these terms are an amalgam of definitions taken
+   from a number of RFCs.  In addition, suggestions have been
+   incorporated from a number of people including Robert Ullmann, Thomas
+   Narten, Neal McBurnett, and Robert Elz.
+
+
+
+
+
+
+
+
+
+
+
+
+Bradner                  Best Current Practice                  [Page 2]
+
+RFC 2119                     RFC Key Words                    March 1997
+
+
+9. Author's Address
+
+      Scott Bradner
+      Harvard University
+      1350 Mass. Ave.
+      Cambridge, MA 02138
+
+      phone - +1 617 495 3864
+
+      email - sob@harvard.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bradner                  Best Current Practice                  [Page 3]
+
diff --git a/doc/rfc/rfc2133.txt b/doc/rfc/rfc2133.txt
new file mode 100644
index 0000000..ea66cf0
--- /dev/null
+++ b/doc/rfc/rfc2133.txt
@@ -0,0 +1,1795 @@
+
+
+
+
+
+
+Network Working Group                                        R. Gilligan
+Request for Comments: 2133                                      Freegate
+Category: Informational                                       S. Thomson
+                                                                Bellcore
+                                                                J. Bound
+                                                                 Digital
+                                                              W. Stevens
+                                                              Consultant
+                                                              April 1997
+
+               Basic Socket Interface Extensions for IPv6
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  This memo
+   does not specify an Internet standard of any kind.  Distribution of
+   this memo is unlimited.
+
+Abstract
+
+   The de facto standard application program interface (API) for TCP/IP
+   applications is the "sockets" interface.  Although this API was
+   developed for Unix in the early 1980s it has also been implemented on
+   a wide variety of non-Unix systems.  TCP/IP applications written
+   using the sockets API have in the past enjoyed a high degree of
+   portability and we would like the same portability with IPv6
+   applications.  But changes are required to the sockets API to support
+   IPv6 and this memo describes these changes.  These include a new
+   socket address structure to carry IPv6 addresses, new address
+   conversion functions, and some new socket options.  These extensions
+   are designed to provide access to the basic IPv6 features required by
+   TCP and UDP applications, including multicasting, while introducing a
+   minimum of change into the system and providing complete
+   compatibility for existing IPv4 applications.  Additional extensions
+   for advanced IPv6 features (raw sockets and access to the IPv6
+   extension headers) are defined in another document [5].
+
+Table of Contents
+
+   1.  Introduction ................................................  2
+   2.  Design Considerations .......................................  3
+   2.1.  What Needs to be Changed ..................................  3
+   2.2.  Data Types ................................................  5
+   2.3.  Headers ...................................................  5
+   2.4.  Structures ................................................  5
+   3.  Socket Interface ............................................  5
+   3.1.  IPv6 Address Family and Protocol Family ...................  5
+   3.2.  IPv6 Address Structure ....................................  6
+
+
+
+Gilligan, et. al.            Informational                      [Page 1]
+
+RFC 2133            IPv6 Socket Interface Extensions          April 1997
+
+
+   3.3.  Socket Address Structure for 4.3BSD-Based Systems .........  6
+   3.4.  Socket Address Structure for 4.4BSD-Based Systems .........  7
+   3.5.  The Socket Functions ......................................  8
+   3.6.  Compatibility with IPv4 Applications ......................  9
+   3.7.  Compatibility with IPv4 Nodes .............................  9
+   3.8.  IPv6 Wildcard Address ..................................... 10
+   3.9.  IPv6 Loopback Address ..................................... 11
+   4.  Interface Identification .................................... 12
+   4.1.  Name-to-Index ............................................. 13
+   4.2.  Index-to-Name ............................................. 13
+   4.3.  Return All Interface Names and Indexes .................... 14
+   4.4.  Free Memory ............................................... 14
+   5.  Socket Options .............................................. 14
+   5.1.  Changing Socket Type ...................................... 15
+   5.2.  Unicast Hop Limit ......................................... 16
+   5.3.  Sending and Receiving Multicast Packets ................... 17
+   6.  Library Functions ........................................... 19
+   6.1.  Hostname-to-Address Translation ........................... 19
+   6.2.  Address To Hostname Translation ........................... 22
+   6.3.  Protocol-Independent Hostname and Service Name Translation  22
+   6.4.  Socket Address Structure to Hostname and Service Name ..... 25
+   6.5.  Address Conversion Functions .............................. 27
+   6.6.  Address Testing Macros .................................... 28
+   7.  Summary of New Definitions .................................. 29
+   8.  Security Considerations ..................................... 31
+   9.  Acknowledgments ............................................. 31
+   10.  References ................................................. 31
+   11.  Authors' Addresses ......................................... 32
+
+1.  Introduction
+
+   While IPv4 addresses are 32 bits long, IPv6 interfaces are identified
+   by 128-bit addresses.  The socket interface make the size of an IP
+   address quite visible to an application; virtually all TCP/IP
+   applications for BSD-based systems have knowledge of the size of an
+   IP address.  Those parts of the API that expose the addresses must be
+   changed to accommodate the larger IPv6 address size.  IPv6 also
+   introduces new features (e.g., flow label and priority), some of
+   which must be made visible to applications via the API.  This memo
+   defines a set of extensions to the socket interface to support the
+   larger address size and new features of IPv6.
+
+
+
+
+
+
+
+
+
+
+Gilligan, et. al.            Informational                      [Page 2]
+
+RFC 2133            IPv6 Socket Interface Extensions          April 1997
+
+
+2.  Design Considerations
+
+   There are a number of important considerations in designing changes
+   to this well-worn API:
+
+   -  The API changes should provide both source and binary
+       compatibility for programs written to the original API.  That is,
+       existing program binaries should continue to operate when run on
+       a system supporting the new API.  In addition, existing
+       applications that are re-compiled and run on a system supporting
+       the new API should continue to operate.  Simply put, the API
+       changes for IPv6 should not break existing programs.
+
+   -  The changes to the API should be as small as possible in order to
+       simplify the task of converting existing IPv4 applications to
+       IPv6.
+
+   -  Where possible, applications should be able to use this API to
+       interoperate with both IPv6 and IPv4 hosts.  Applications should
+       not need to know which type of host they are communicating with.
+
+   -  IPv6 addresses carried in data structures should be 64-bit
+       aligned.  This is necessary in order to obtain optimum
+       performance on 64-bit machine architectures.
+
+   Because of the importance of providing IPv4 compatibility in the API,
+   these extensions are explicitly designed to operate on machines that
+   provide complete support for both IPv4 and IPv6.  A subset of this
+   API could probably be designed for operation on systems that support
+   only IPv6.  However, this is not addressed in this memo.
+
+2.1.  What Needs to be Changed
+
+   The socket interface API consists of a few distinct components:
+
+    -  Core socket functions.
+
+    -  Address data structures.
+
+    -  Name-to-address translation functions.
+
+    -  Address conversion functions.
+
+    The core socket functions -- those functions that deal with such
+    things as setting up and tearing down TCP connections, and sending
+    and receiving UDP packets -- were designed to be transport
+    independent.  Where protocol addresses are passed as function
+    arguments, they are carried via opaque pointers.  A protocol-specific
+
+
+
+Gilligan, et. al.            Informational                      [Page 3]
+
+RFC 2133            IPv6 Socket Interface Extensions          April 1997
+
+
+    address data structure is defined for each protocol that the socket
+    functions support.  Applications must cast pointers to these
+    protocol-specific address structures into pointers to the generic
+    "sockaddr" address structure when using the socket functions.  These
+    functions need not change for IPv6, but a new IPv6-specific address
+    data structure is needed.
+
+    The "sockaddr_in" structure is the protocol-specific data structure
+    for IPv4.  This data structure actually includes 8-octets of unused
+    space, and it is tempting to try to use this space to adapt the
+    sockaddr_in structure to IPv6.  Unfortunately, the sockaddr_in
+    structure is not large enough to hold the 16-octet IPv6 address as
+    well as the other information (address family and port number) that
+    is needed.  So a new address data structure must be defined for IPv6.
+
+    The name-to-address translation functions in the socket interface are
+    gethostbyname() and gethostbyaddr().  These must be modified to
+    support IPv6 and the semantics defined must provide 100% backward
+    compatibility for all existing IPv4 applications, along with IPv6
+    support for new applications.  Additionally, the POSIX 1003.g work in
+    progress [4] specifies a new hostname-to-address translation function
+    which is protocol independent.  This function can also be used with
+    IPv6.
+
+    The address conversion functions -- inet_ntoa() and inet_addr() --
+    convert IPv4 addresses between binary and printable form.  These
+    functions are quite specific to 32-bit IPv4 addresses.  We have
+    designed two analogous functions that convert both IPv4 and IPv6
+    addresses, and carry an address type parameter so that they can be
+    extended to other protocol families as well.
+
+    Finally, a few miscellaneous features are needed to support IPv6.
+    New interfaces are needed to support the IPv6 flow label, priority,
+    and hop limit header fields.  New socket options are needed to
+    control the sending and receiving of IPv6 multicast packets.
+
+    The socket interface will be enhanced in the future to provide access
+    to other IPv6 features.  These extensions are described in [5].
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gilligan, et. al.            Informational                      [Page 4]
+
+RFC 2133            IPv6 Socket Interface Extensions          April 1997
+
+
+2.2.  Data Types
+
+   The data types of the structure elements given in this memo are
+   intended to be examples, not absolute requirements.  Whenever
+   possible, POSIX 1003.1g data types are used:  u_intN_t means an
+   unsigned integer of exactly N bits (e.g., u_int16_t) and u_intNm_t
+   means an unsigned integer of at least N bits (e.g., u_int32m_t).  We
+   also assume the argument data types from 1003.1g when possible (e.g.,
+    the final argument to setsockopt() is a size_t value).  Whenever
+   buffer sizes are specified, the POSIX 1003.1 size_t data type is used
+   (e.g., the two length arguments to getnameinfo()).
+
+2.3.  Headers
+
+   When function prototypes and structures are shown we show the headers
+   that must be #included to cause that item to be defined.
+
+2.4.  Structures
+
+   When structures are described the members shown are the ones that
+   must appear in an implementation.  Additional, nonstandard members
+   may also be defined by an implementation.
+
+   The ordering shown for the members of a structure is the recommended
+   ordering, given alignment considerations of multibyte members, but an
+   implementation may order the members differently.
+
+3.  Socket Interface
+
+   This section specifies the socket interface changes for IPv6.
+
+3.1.  IPv6 Address Family and Protocol Family
+
+   A new address family name, AF_INET6, is defined in <sys/socket.h>.
+   The AF_INET6 definition distinguishes between the original
+   sockaddr_in address data structure, and the new sockaddr_in6 data
+   structure.
+
+   A new protocol family name, PF_INET6, is defined in <sys/socket.h>.
+   Like most of the other protocol family names, this will usually be
+   defined to have the same value as the corresponding address family
+   name:
+
+       #define PF_INET6        AF_INET6
+
+   The PF_INET6 is used in the first argument to the socket() function
+   to indicate that an IPv6 socket is being created.
+
+
+
+
+Gilligan, et. al.            Informational                      [Page 5]
+
+RFC 2133            IPv6 Socket Interface Extensions          April 1997
+
+
+3.2.  IPv6 Address Structure
+
+   A new data structure to hold a single IPv6 address is defined as
+    follows:
+
+       #include <netinet/in.h>
+
+       struct in6_addr {
+           u_int8_t  s6_addr[16];      /* IPv6 address */
+       }
+
+   This data structure contains an array of sixteen 8-bit elements,
+   which make up one 128-bit IPv6 address.  The IPv6 address is stored
+   in network byte order.
+
+3.3.  Socket Address Structure for 4.3BSD-Based Systems
+
+   In the socket interface, a different protocol-specific data structure
+   is defined to carry the addresses for each protocol suite.  Each
+   protocol-specific data structure is designed so it can be cast into a
+   protocol-independent data structure -- the "sockaddr" structure.
+   Each has a "family" field that overlays the "sa_family" of the
+   sockaddr data structure.  This field identifies the type of the data
+   structure.
+
+   The sockaddr_in structure is the protocol-specific address data
+   structure for IPv4.  It is used to pass addresses between
+   applications and the system in the socket functions.  The following
+   structure is defined to carry IPv6 addresses:
+
+       #include <netinet/in.h>
+
+       struct sockaddr_in6 {
+           u_int16m_t      sin6_family;    /* AF_INET6 */
+           u_int16m_t      sin6_port;      /* transport layer port # */
+           u_int32m_t      sin6_flowinfo;  /* IPv6 flow information */
+           struct in6_addr sin6_addr;      /* IPv6 address */
+       };
+
+   This structure is designed to be compatible with the sockaddr data
+   structure used in the 4.3BSD release.
+
+   The sin6_family field identifies this as a sockaddr_in6 structure.
+   This field overlays the sa_family field when the buffer is cast to a
+   sockaddr data structure.  The value of this field must be AF_INET6.
+
+
+
+
+
+
+Gilligan, et. al.            Informational                      [Page 6]
+
+RFC 2133            IPv6 Socket Interface Extensions          April 1997
+
+
+   The sin6_port field contains the 16-bit UDP or TCP port number.  This
+   field is used in the same way as the sin_port field of the
+   sockaddr_in structure.  The port number is stored in network byte
+   order.
+
+   The sin6_flowinfo field is a 32-bit field that contains two pieces of
+   information: the 24-bit IPv6 flow label and the 4-bit priority field.
+   The contents and interpretation of this member is unspecified at this
+   time.
+
+   The sin6_addr field is a single in6_addr structure (defined in the
+   previous section).  This field holds one 128-bit IPv6 address.  The
+   address is stored in network byte order.
+
+   The ordering of elements in this structure is specifically designed
+   so that the sin6_addr field will be aligned on a 64-bit boundary.
+   This is done for optimum performance on 64-bit architectures.
+
+   Notice that the sockaddr_in6 structure will normally be larger than
+   the generic sockaddr structure.  On many existing implementations the
+   sizeof(struct sockaddr_in) equals sizeof(struct sockaddr), with both
+   being 16 bytes.  Any existing code that makes this assumption needs
+   to be examined carefully when converting to IPv6.
+
+3.4.  Socket Address Structure for 4.4BSD-Based Systems
+
+   The 4.4BSD release includes a small, but incompatible change to the
+   socket interface.  The "sa_family" field of the sockaddr data
+   structure was changed from a 16-bit value to an 8-bit value, and the
+   space saved used to hold a length field, named "sa_len".  The
+   sockaddr_in6 data structure given in the previous section cannot be
+   correctly cast into the newer sockaddr data structure.  For this
+   reason, the following alternative IPv6 address data structure is
+   provided to be used on systems based on 4.4BSD:
+
+       #include <netinet/in.h>
+
+       #define SIN6_LEN
+
+       struct sockaddr_in6 {
+           u_char          sin6_len;       /* length of this struct */
+           u_char          sin6_family;    /* AF_INET6 */
+           u_int16m_t      sin6_port;      /* transport layer port # */
+           u_int32m_t      sin6_flowinfo;  /* IPv6 flow information */
+           struct in6_addr sin6_addr;      /* IPv6 address */
+       };
+
+
+
+
+
+Gilligan, et. al.            Informational                      [Page 7]
+
+RFC 2133            IPv6 Socket Interface Extensions          April 1997
+
+
+   The only differences between this data structure and the 4.3BSD
+   variant are the inclusion of the length field, and the change of the
+   family field to a 8-bit data type.  The definitions of all the other
+   fields are identical to the structure defined in the previous
+   section.
+
+   Systems that provide this version of the sockaddr_in6 data structure
+   must also declare SIN6_LEN as a result of including the
+   <netinet/in.h> header.  This macro allows applications to determine
+   whether they are being built on a system that supports the 4.3BSD or
+   4.4BSD variants of the data structure.
+
+3.5.  The Socket Functions
+
+   Applications call the socket() function to create a socket descriptor
+   that represents a communication endpoint.  The arguments to the
+   socket() function tell the system which protocol to use, and what
+   format address structure will be used in subsequent functions.  For
+   example, to create an IPv4/TCP socket, applications make the call:
+
+       s = socket(PF_INET, SOCK_STREAM, 0);
+
+   To create an IPv4/UDP socket, applications make the call:
+
+       s = socket(PF_INET, SOCK_DGRAM, 0);
+
+   Applications may create IPv6/TCP and IPv6/UDP sockets by simply using
+   the constant PF_INET6 instead of PF_INET in the first argument.  For
+   example, to create an IPv6/TCP socket, applications make the call:
+
+       s = socket(PF_INET6, SOCK_STREAM, 0);
+
+   To create an IPv6/UDP socket, applications make the call:
+
+       s = socket(PF_INET6, SOCK_DGRAM, 0);
+
+   Once the application has created a PF_INET6 socket, it must use the
+   sockaddr_in6 address structure when passing addresses in to the
+   system.  The functions that the application uses to pass addresses
+   into the system are:
+
+       bind()
+       connect()
+       sendmsg()
+       sendto()
+
+
+
+
+
+
+Gilligan, et. al.            Informational                      [Page 8]
+
+RFC 2133            IPv6 Socket Interface Extensions          April 1997
+
+
+   The system will use the sockaddr_in6 address structure to return
+   addresses to applications that are using PF_INET6 sockets.  The
+   functions that return an address from the system to an application
+   are:
+
+          accept()
+          recvfrom()
+          recvmsg()
+          getpeername()
+          getsockname()
+
+   No changes to the syntax of the socket functions are needed to
+   support IPv6, since all of the "address carrying" functions use an
+   opaque address pointer, and carry an address length as a function
+   argument.
+
+3.6.  Compatibility with IPv4 Applications
+
+   In order to support the large base of applications using the original
+   API, system implementations must provide complete source and binary
+   compatibility with the original API.  This means that systems must
+   continue to support PF_INET sockets and the sockaddr_in address
+   structure.  Applications must be able to create IPv4/TCP and IPv4/UDP
+   sockets using the PF_INET constant in the socket() function, as
+   described in the previous section.  Applications should be able to
+   hold a combination of IPv4/TCP, IPv4/UDP, IPv6/TCP and IPv6/UDP
+   sockets simultaneously within the same process.
+
+   Applications using the original API should continue to operate as
+   they did on systems supporting only IPv4.  That is, they should
+   continue to interoperate with IPv4 nodes.
+
+3.7.  Compatibility with IPv4 Nodes
+
+   The API also provides a different type of compatibility: the ability
+   for IPv6 applications to interoperate with IPv4 applications.  This
+   feature uses the IPv4-mapped IPv6 address format defined in the IPv6
+   addressing architecture specification [2].  This address format
+   allows the IPv4 address of an IPv4 node to be represented as an IPv6
+   address.  The IPv4 address is encoded into the low-order 32 bits of
+   the IPv6 address, and the high-order 96 bits hold the fixed prefix
+   0:0:0:0:0:FFFF.  IPv4-mapped addresses are written as follows:
+
+       ::FFFF:<IPv4-address>
+
+   These addresses are often generated automatically by the
+   gethostbyname() function when the specified host has only IPv4
+   addresses (as described in Section 6.1).
+
+
+
+Gilligan, et. al.            Informational                      [Page 9]
+
+RFC 2133            IPv6 Socket Interface Extensions          April 1997
+
+
+   Applications may use PF_INET6 sockets to open TCP connections to IPv4
+   nodes, or send UDP packets to IPv4 nodes, by simply encoding the
+   destination's IPv4 address as an IPv4-mapped IPv6 address, and
+   passing that address, within a sockaddr_in6 structure, in the
+   connect() or sendto() call.  When applications use PF_INET6 sockets
+   to accept TCP connections from IPv4 nodes, or receive UDP packets
+   from IPv4 nodes, the system returns the peer's address to the
+   application in the accept(), recvfrom(), or getpeername() call using
+   a sockaddr_in6 structure encoded this way.
+
+   Few applications will likely need to know which type of node they are
+   interoperating with.  However, for those applications that do need to
+   know, the IN6_IS_ADDR_V4MAPPED() macro, defined in Section 6.6, is
+   provided.
+
+3.8.  IPv6 Wildcard Address
+
+   While the bind() function allows applications to select the source IP
+   address of UDP packets and TCP connections, applications often want
+   the system to select the source address for them.  With IPv4, one
+   specifies the address as the symbolic constant INADDR_ANY (called the
+   "wildcard" address) in the bind() call, or simply omits the bind()
+   entirely.
+
+   Since the IPv6 address type is a structure (struct in6_addr), a
+   symbolic constant can be used to initialize an IPv6 address variable,
+   but cannot be used in an assignment.  Therefore systems provide the
+   IPv6 wildcard address in two forms.
+
+   The first version is a global variable named "in6addr_any" that is an
+   in6_addr structure.  The extern declaration for this variable is
+   defined in <netinet/in.h>:
+
+       extern const struct in6_addr in6addr_any;
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gilligan, et. al.            Informational                     [Page 10]
+
+RFC 2133            IPv6 Socket Interface Extensions          April 1997
+
+
+   Applications use in6addr_any similarly to the way they use INADDR_ANY
+   in IPv4.  For example, to bind a socket to port number 23, but let
+   the system select the source address, an application could use the
+   following code:
+
+       struct sockaddr_in6 sin6;
+        . . .
+       sin6.sin6_family = AF_INET6;
+       sin6.sin6_flowinfo = 0;
+       sin6.sin6_port = htons(23);
+       sin6.sin6_addr = in6addr_any;  /* structure assignment */
+        . . .
+       if (bind(s, (struct sockaddr *) &sin6, sizeof(sin6)) == -1)
+               . . .
+
+   The other version is a symbolic constant named IN6ADDR_ANY_INIT and
+   is defined in <netinet/in.h>.  This constant can be used to
+   initialize an in6_addr structure:
+
+       struct in6_addr anyaddr = IN6ADDR_ANY_INIT;
+
+   Note that this constant can be used ONLY at declaration time.  It can
+   not be used to assign a previously declared in6_addr structure.  For
+   example, the following code will not work:
+
+       /* This is the WRONG way to assign an unspecified address */
+       struct sockaddr_in6 sin6;
+        . . .
+       sin6.sin6_addr = IN6ADDR_ANY_INIT; /* will NOT compile */
+
+   Be aware that the IPv4 INADDR_xxx constants are all defined in host
+   byte order but the IPv6 IN6ADDR_xxx constants and the IPv6
+   in6addr_xxx externals are defined in network byte order.
+
+3.9.  IPv6 Loopback Address
+
+   Applications may need to send UDP packets to, or originate TCP
+   connections to, services residing on the local node.  In IPv4, they
+   can do this by using the constant IPv4 address INADDR_LOOPBACK in
+   their connect(), sendto(), or sendmsg() call.
+
+   IPv6 also provides a loopback address to contact local TCP and UDP
+   services.  Like the unspecified address, the IPv6 loopback address is
+   provided in two forms -- a global variable and a symbolic constant.
+
+
+
+
+
+
+
+Gilligan, et. al.            Informational                     [Page 11]
+
+RFC 2133            IPv6 Socket Interface Extensions          April 1997
+
+
+   The global variable is an in6_addr structure named
+   "in6addr_loopback."  The extern declaration for this variable is
+   defined in <netinet/in.h>:
+
+       extern const struct in6_addr in6addr_loopback;
+
+   Applications use in6addr_loopback as they would use INADDR_LOOPBACK
+   in IPv4 applications (but beware of the byte ordering difference
+   mentioned at the end of the previous section).  For example, to open
+   a TCP connection to the local telnet server, an application could use
+   the following code:
+
+       struct sockaddr_in6 sin6;
+        . . .
+       sin6.sin6_family = AF_INET6;
+       sin6.sin6_flowinfo = 0;
+       sin6.sin6_port = htons(23);
+       sin6.sin6_addr = in6addr_loopback;  /* structure assignment */
+        . . .
+       if (connect(s, (struct sockaddr *) &sin6, sizeof(sin6)) == -1)
+               . . .
+
+   The symbolic constant is named IN6ADDR_LOOPBACK_INIT and is defined
+   in <netinet/in.h>.  It can be used at declaration time ONLY; for
+   example:
+
+       struct in6_addr loopbackaddr = IN6ADDR_LOOPBACK_INIT;
+
+   Like IN6ADDR_ANY_INIT, this constant cannot be used in an assignment
+   to a previously declared IPv6 address variable.
+
+4.  Interface Identification
+
+   This API uses an interface index (a small positive integer) to
+   identify the local interface on which a multicast group is joined
+   (Section 5.3).  Additionally, the advanced API [5] uses these same
+   interface indexes to identify the interface on which a datagram is
+   received, or to specify the interface on which a datagram is to be
+   sent.
+
+   Interfaces are normally known by names such as "le0", "sl1", "ppp2",
+   and the like.  On Berkeley-derived implementations, when an interface
+   is made known to the system, the kernel assigns a unique positive
+   integer value (called the interface index) to that interface.  These
+   are small positive integers that start at 1.  (Note that 0 is never
+   used for an interface index.)  There may be gaps so that there is no
+   current interface for a particular positive interface index.
+
+
+
+
+Gilligan, et. al.            Informational                     [Page 12]
+
+RFC 2133            IPv6 Socket Interface Extensions          April 1997
+
+
+   This API defines two functions that map between an interface name and
+   index, a third function that returns all the interface names and
+   indexes, and a fourth function to return the dynamic memory allocated
+   by the previous function.  How these functions are implemented is
+   left up to the implementation.  4.4BSD implementations can implement
+   these functions using the existing sysctl() function with the
+   NET_RT_LIST command.  Other implementations may wish to use ioctl()
+   for this purpose.
+
+4.1.  Name-to-Index
+
+   The first function maps an interface name into its corresponding
+   index.
+
+       #include <net/if.h>
+
+       unsigned int  if_nametoindex(const char *ifname);
+
+   If the specified interface does not exist, the return value is 0.
+
+4.2.  Index-to-Name
+
+   The second function maps an interface index into its corresponding
+   name.
+
+       #include <net/if.h>
+
+       char  *if_indextoname(unsigned int ifindex, char *ifname);
+
+   The ifname argument must point to a buffer of at least IFNAMSIZ bytes
+   into which the interface name corresponding to the specified index is
+   returned.  (IFNAMSIZ is also defined in <net/if.h> and its value
+   includes a terminating null byte at the end of the interface name.)
+   This pointer is also the return value of the function.  If there is
+   no interface corresponding to the specified index, NULL is returned.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gilligan, et. al.            Informational                     [Page 13]
+
+RFC 2133            IPv6 Socket Interface Extensions          April 1997
+
+
+4.3.  Return All Interface Names and Indexes
+
+   The final function returns an array of if_nameindex structures, one
+   structure per interface.
+
+       #include <net/if.h>
+
+       struct if_nameindex {
+         unsigned int   if_index;  /* 1, 2, ... */
+         char          *if_name;   /* null terminated name: "le0", ... */
+       };
+
+       struct if_nameindex  *if_nameindex(void);
+
+   The end of the array of structures is indicated by a structure with
+   an if_index of 0 and an if_name of NULL.  The function returns a NULL
+   pointer upon an error.
+
+   The memory used for this array of structures along with the interface
+   names pointed to by the if_name members is obtained dynamically.
+   This memory is freed by the next function.
+
+4.4.  Free Memory
+
+   The following function frees the dynamic memory that was allocated by
+   if_nameindex().
+
+       #include <net/if.h>
+
+       void  if_freenameindex(struct if_nameindex *ptr);
+
+   The argument to this function must be a pointer that was returned by
+   if_nameindex().
+
+5.  Socket Options
+
+   A number of new socket options are defined for IPv6.  All of these
+   new options are at the IPPROTO_IPV6 level.  That is, the "level"
+   parameter in the getsockopt() and setsockopt() calls is IPPROTO_IPV6
+   when using these options.  The constant name prefix IPV6_ is used in
+   all of the new socket options.  This serves to clearly identify these
+   options as applying to IPv6.
+
+   The declaration for IPPROTO_IPV6, the new IPv6 socket options, and
+   related constants defined in this section are obtained by including
+   the header <netinet/in.h>.
+
+
+
+
+
+Gilligan, et. al.            Informational                     [Page 14]
+
+RFC 2133            IPv6 Socket Interface Extensions          April 1997
+
+
+5.1.  Changing Socket Type
+
+   Unix allows open sockets to be passed between processes via the
+   exec() call and other means.  It is a relatively common application
+   practice to pass open sockets across exec() calls.  Thus it is
+   possible for an application using the original API to pass an open
+   PF_INET socket to an application that is expecting to receive a
+   PF_INET6 socket.  Similarly, it is possible for an application using
+   the extended API to pass an open PF_INET6 socket to an application
+   using the original API, which would be equipped only to deal with
+   PF_INET sockets.  Either of these cases could cause problems, because
+   the application that is passed the open socket might not know how to
+   decode the address structures returned in subsequent socket
+   functions.
+
+   To remedy this problem, a new setsockopt() option is defined that
+   allows an application to "convert" a PF_INET6 socket into a PF_INET
+   socket and vice versa.
+
+   An IPv6 application that is passed an open socket from an unknown
+   process may use the IPV6_ADDRFORM setsockopt() option to "convert"
+   the socket to PF_INET6.  Once that has been done, the system will
+   return sockaddr_in6 address structures in subsequent socket
+   functions.
+
+   An IPv6 application that is about to pass an open PF_INET6 socket to
+   a program that is not be IPv6 capable can "downgrade" the socket to
+   PF_INET before calling exec().  After that, the system will return
+   sockaddr_in address structures to the application that was exec()'ed.
+   Be aware that you cannot downgrade an IPv6 socket to an IPv4 socket
+   unless all nonwildcard addresses already associated with the IPv6
+   socket are IPv4-mapped IPv6 addresses.
+
+   The IPV6_ADDRFORM option is valid at both the IPPROTO_IP and
+   IPPROTO_IPV6 levels.  The only valid option values are PF_INET6 and
+   PF_INET.  For example, to convert a PF_INET6 socket to PF_INET, a
+   program would call:
+
+       int  addrform = PF_INET;
+
+       if (setsockopt(s, IPPROTO_IPV6, IPV6_ADDRFORM,
+                      (char *) &addrform, sizeof(addrform)) == -1)
+           perror("setsockopt IPV6_ADDRFORM");
+
+
+
+
+
+
+
+
+Gilligan, et. al.            Informational                     [Page 15]
+
+RFC 2133            IPv6 Socket Interface Extensions          April 1997
+
+
+   An application may use IPV6_ADDRFORM with getsockopt() to learn
+   whether an open socket is a PF_INET of PF_INET6 socket.  For example:
+
+       int  addrform;
+       size_t  len = sizeof(addrform);
+
+       if (getsockopt(s, IPPROTO_IPV6, IPV6_ADDRFORM,
+                      (char *) &addrform, &len) == -1)
+           perror("getsockopt IPV6_ADDRFORM");
+       else if (addrform == PF_INET)
+           printf("This is an IPv4 socket.\n");
+       else if (addrform == PF_INET6)
+           printf("This is an IPv6 socket.\n");
+       else
+           printf("This system is broken.\n");
+
+5.2.  Unicast Hop Limit
+
+   A new setsockopt() option controls the hop limit used in outgoing
+   unicast IPv6 packets.  The name of this option is IPV6_UNICAST_HOPS,
+   and it is used at the IPPROTO_IPV6 layer.  The following example
+   illustrates how it is used:
+
+       int  hoplimit = 10;
+
+       if (setsockopt(s, IPPROTO_IPV6, IPV6_UNICAST_HOPS,
+                      (char *) &hoplimit, sizeof(hoplimit)) == -1)
+           perror("setsockopt IPV6_UNICAST_HOPS");
+
+   When the IPV6_UNICAST_HOPS option is set with setsockopt(), the
+   option value given is used as the hop limit for all subsequent
+   unicast packets sent via that socket.  If the option is not set, the
+   system selects a default value.  The integer hop limit value (called
+   x) is interpreted as follows:
+
+       x < -1:        return an error of EINVAL
+       x == -1:       use kernel default
+       0 <= x <= 255: use x
+       x >= 256:      return an error of EINVAL
+
+
+
+
+
+
+
+
+
+
+
+
+Gilligan, et. al.            Informational                     [Page 16]
+
+RFC 2133            IPv6 Socket Interface Extensions          April 1997
+
+
+   The IPV6_UNICAST_HOPS option may be used with getsockopt() to
+   determine the hop limit value that the system will use for subsequent
+   unicast packets sent via that socket.  For example:
+
+       int  hoplimit;
+       size_t  len = sizeof(hoplimit);
+
+       if (getsockopt(s, IPPROTO_IPV6, IPV6_UNICAST_HOPS,
+                      (char *) &hoplimit, &len) == -1)
+           perror("getsockopt IPV6_UNICAST_HOPS");
+       else
+           printf("Using %d for hop limit.\n", hoplimit);
+
+5.3.  Sending and Receiving Multicast Packets
+
+   IPv6 applications may send UDP multicast packets by simply specifying
+   an IPv6 multicast address in the address argument of the sendto()
+   function.
+
+   Three socket options at the IPPROTO_IPV6 layer control some of the
+   parameters for sending multicast packets.  Setting these options is
+   not required:  applications may send multicast packets without using
+   these options.  The setsockopt() options for controlling the sending
+   of multicast packets are summarized below:
+
+       IPV6_MULTICAST_IF
+
+           Set the interface to use for outgoing multicast packets.  The
+           argument is the index of the interface to use.
+
+           Argument type: unsigned int
+
+       IPV6_MULTICAST_HOPS
+
+           Set the hop limit to use for outgoing multicast packets.
+           (Note a separate option - IPV6_UNICAST_HOPS - is provided to
+           set the hop limit to use for outgoing unicast packets.)  The
+           interpretation of the argument is the same as for the
+           IPV6_UNICAST_HOPS option:
+
+               x < -1:        return an error of EINVAL
+               x == -1:       use kernel default
+               0 <= x <= 255: use x
+               x >= 256:      return an error of EINVAL
+
+           Argument type: int
+
+
+
+
+
+Gilligan, et. al.            Informational                     [Page 17]
+
+RFC 2133            IPv6 Socket Interface Extensions          April 1997
+
+
+       IPV6_MULTICAST_LOOP
+
+           Controls whether outgoing multicast packets  sent  should  be
+           delivered  back  to the local application.  A toggle.  If the
+           option is set to 1, multicast packets are looped back.  If it
+           is set to 0, they are not.
+
+           Argument type: unsigned int
+
+   The reception of multicast packets is controlled by the two
+   setsockopt() options summarized below:
+
+       IPV6_ADD_MEMBERSHIP
+
+           Join a multicast group on a specified local interface.  If
+           the interface index is specified as 0, the kernel chooses the
+           local interface.  For example, some kernels look up the
+           multicast group in the normal IPv6 routing table and using
+           the resulting interface.
+
+           Argument type: struct ipv6_mreq
+
+       IPV6_DROP_MEMBERSHIP
+
+           Leave a multicast group on a specified interface.
+
+           Argument type: struct ipv6_mreq
+
+   The argument type of both of these options is the ipv6_mreq
+   structure, defined as:
+
+       #include <netinet/in.h>
+
+       struct ipv6_mreq {
+           struct in6_addr ipv6mr_multiaddr; /* IPv6 multicast addr */
+           unsigned int    ipv6mr_interface; /* interface index */
+       };
+
+   Note that to receive multicast datagrams a process must join the
+   multicast group and bind the UDP port to which datagrams will be
+   sent.  Some processes also bind the multicast group address to the
+   socket, in addition to the port, to prevent other datagrams destined
+   to that same port from being delivered to the socket.
+
+
+
+
+
+
+
+
+Gilligan, et. al.            Informational                     [Page 18]
+
+RFC 2133            IPv6 Socket Interface Extensions          April 1997
+
+
+6.  Library Functions
+
+   New library functions are needed to perform a variety of operations
+   with IPv6 addresses.  Functions are needed to lookup IPv6 addresses
+   in the Domain Name System (DNS).  Both forward lookup (hostname-to-
+   address translation) and reverse lookup (address-to-hostname
+   translation) need to be supported.  Functions are also needed to
+   convert IPv6 addresses between their binary and textual form.
+
+6.1.  Hostname-to-Address Translation
+
+   The commonly used function gethostbyname() remains unchanged as does
+   the hostent structure to which it returns a pointer.  Existing
+   applications that call this function continue to receive only IPv4
+   addresses that are the result of a query in the DNS for A records.
+   (We assume the DNS is being used; some environments may be using a
+   hosts file or some other name resolution system, either of which may
+   impede renumbering.  We also assume that the RES_USE_INET6 resolver
+   option is not set, which we describe in more detail shortly.)
+
+   Two new changes are made to support IPv6 addresses.  First, the
+   following function is new:
+
+       #include <sys/socket.h>
+       #include <netdb.h>
+
+       struct hostent *gethostbyname2(const char *name, int af);
+
+   The af argument specifies the address family.  The default operation
+   of this function is simple:
+
+    -  If the af argument is AF_INET, then a query is made for A
+       records.  If successful, IPv4 addresses are returned and the
+       h_length member of the hostent structure will be 4, else the
+       function returns a NULL pointer.
+
+    -  If the af argument is AF_INET6, then a query is made for AAAA
+       records.  If successful, IPv6 addresses are returned and the
+       h_length member of the hostent structure will be 16, else the
+       function returns a NULL pointer.
+
+
+
+
+
+
+
+
+
+
+
+Gilligan, et. al.            Informational                     [Page 19]
+
+RFC 2133            IPv6 Socket Interface Extensions          April 1997
+
+
+   The second change, that provides additional functionality, is a new
+   resolver option RES_USE_INET6, which is defined as a result of
+   including the <resolv.h> header.  (This option is provided starting
+   with the BIND 4.9.4 release.)  There are three ways to set this
+   option.
+
+    -  The first way is
+
+           res_init();
+           _res.options |= RES_USE_INET6;
+
+       and then call either gethostbyname() or gethostbyname2().  This
+       option then affects only the process that is calling the
+       resolver.
+
+    -  The second way to set this option is to set the environment
+       variable RES_OPTIONS, as in RES_OPTIONS=inet6.  (This example is
+       for the Bourne and Korn shells.)  This method affects any
+       processes that see this environment variable.
+
+    -  The third way is to set this option in the resolver configuration
+       file (normally /etc/resolv.conf) and the option then affects all
+       applications on the host.  This final method should not be done
+       until all applications on the host are capable of dealing with
+       IPv6 addresses.
+
+   There is no priority among these three methods.  When the
+   RES_USE_INET6 option is set, two changes occur:
+
+    -  gethostbyname(host) first calls gethostbyname2(host, AF_INET6)
+       looking for AAAA records, and if this fails it then calls
+       gethostbyname2(host, AF_INET) looking for A records.
+
+    -  gethostbyname2(host, AF_INET) always returns IPv4-mapped IPv6
+       addresses with the h_length member of the hostent structure set
+       to 16.
+
+   An application must not enable the RES_USE_INET6 option until it is
+   prepared to deal with 16-byte addresses in the returned hostent
+   structure.
+
+
+
+
+
+
+
+
+
+
+
+Gilligan, et. al.            Informational                     [Page 20]
+
+RFC 2133            IPv6 Socket Interface Extensions          April 1997
+
+
+   The following table summarizes the operation of the existing
+   gethostbyname() function, the new function gethostbyname2(), along
+   with the new resolver option RES_USE_INET6.
+
++------------------+---------------------------------------------------+
+|                  |              RES_USE_INET6 option                 |
+|                  +-------------------------+-------------------------+
+|                  |          off            |           on            |
++------------------+-------------------------+-------------------------+
+|                  |Search for A records.    |Search for AAAA records. |
+| gethostbyname    | If found, return IPv4   | If found, return IPv6   |
+| (host)           | addresses (h_length=4). | addresses (h_length=16).|
+|                  | Else error.             | Else search for A       |
+|                  |                         | records.  If found,     |
+|                  |Provides backward        | return IPv4-mapped IPv6 |
+|                  | compatibility with all  | addresses (h_length=16).|
+|                  | existing IPv4 appls.    | Else error.             |
++------------------+-------------------------+-------------------------+
+|                  |Search for A records.    |Search for A records.    |
+| gethostbyname2   | If found, return IPv4   | If found, return        |
+| (host, AF_INET)  | addresses (h_length=4). | IPv4-mapped IPv6        |
+|                  | Else error.             | addresses (h_length=16).|
+|                  |                         | Else error.             |
++------------------+-------------------------+-------------------------+
+|                  |Search for AAAA records. |Search for AAAA records. |
+| gethostbyname2   | If found, return IPv6   | If found, return IPv6   |
+| (host, AF_INET6) | addresses (h_length=16).| addresses (h_length=16).|
+|                  | Else error.             | Else error.             |
++------------------+-------------------------+-------------------------+
+
+   It is expected that when a typical naive application that calls
+   gethostbyname() today is modified to use IPv6, it simply changes the
+   program to use IPv6 sockets and then enables the RES_USE_INET6
+   resolver option before calling gethostbyname().  This application
+   will then work with either IPv4 or IPv6 peers.
+
+   Note that gethostbyname() and gethostbyname2() are not thread-safe,
+   since both return a pointer to a static hostent structure.  But
+   several vendors have defined a thread-safe gethostbyname_r() function
+   that requires four additional arguments.  We expect these vendors to
+   also define a gethostbyname2_r() function.
+
+
+
+
+
+
+
+
+
+
+Gilligan, et. al.            Informational                     [Page 21]
+
+RFC 2133            IPv6 Socket Interface Extensions          April 1997
+
+
+6.2.  Address To Hostname Translation
+
+   The existing gethostbyaddr() function already requires an address
+   family argument and can therefore work with IPv6 addresses:
+
+       #include <sys/socket.h>
+       #include <netdb.h>
+
+       struct hostent *gethostbyaddr(const char *src, int len, int af);
+
+   One possible source of confusion is the handling of IPv4-mapped IPv6
+   addresses and IPv4-compatible IPv6 addresses.  This is addressed in
+   [6] and involves the following logic:
+
+    1.  If af is AF_INET6, and if len equals 16, and if the IPv6 address
+        is an IPv4-mapped IPv6 address or an IPv4-compatible IPv6
+        address, then skip over the first 12 bytes of the IPv6 address,
+        set af to AF_INET, and set len to 4.
+
+    2.  If af is AF_INET, then query for a PTR record in the in-
+        addr.arpa domain.
+
+    3.  If af is AF_INET6, then query for a PTR record in the ip6.int
+        domain.
+
+    4.  If the function is returning success, and if af equals AF_INET,
+        and if the RES_USE_INET6 option was set, then the single address
+        that is returned in the hostent structure (a copy of the first
+        argument to the function) is returned as an IPv4-mapped IPv6
+        address and the h_length member is set to 16.
+
+   All four steps listed are performed, in order.  The same caveats
+   regarding a thread-safe version of gethostbyname() that were made at
+   the end of the previous section apply here as well.
+
+6.3.  Protocol-Independent Hostname and Service Name Translation
+
+   Hostname-to-address translation is done in a protocol-independent
+   fashion using the getaddrinfo() function that is taken from the
+   Institute of Electrical and Electronic Engineers (IEEE) POSIX 1003.1g
+   (Protocol Independent Interfaces) work in progress specification [4].
+
+   The official specification for this function will be the final POSIX
+   standard.  We are providing this independent description of the
+   function because POSIX standards are not freely available (as are
+   IETF documents).  Should there be any discrepancies between this
+   description and the POSIX description, the POSIX description takes
+   precedence.
+
+
+
+Gilligan, et. al.            Informational                     [Page 22]
+
+RFC 2133            IPv6 Socket Interface Extensions          April 1997
+
+
+       #include <sys/socket.h>
+       #include <netdb.h>
+
+       int getaddrinfo(const char *hostname, const char *servname,
+                       const struct addrinfo *hints,
+                       struct addrinfo **res);
+
+   The addrinfo structure is defined as:
+
+       #include <sys/socket.h>
+       #include <netdb.h>
+
+       struct addrinfo {
+         int     ai_flags;     /* AI_PASSIVE, AI_CANONNAME */
+         int     ai_family;    /* PF_xxx */
+         int     ai_socktype;  /* SOCK_xxx */
+         int     ai_protocol;  /* 0 or IPPROTO_xxx for IPv4 and IPv6 */
+         size_t  ai_addrlen;   /* length of ai_addr */
+         char   *ai_canonname; /* canonical name for hostname */
+         struct sockaddr  *ai_addr; /* binary address */
+         struct addrinfo  *ai_next; /* next structure in linked list */
+       };
+
+   The return value from the function is 0 upon success or a nonzero
+   error code.  The following names are the nonzero error codes from
+   getaddrinfo(), and are defined in <netdb.h>:
+
+       EAI_ADDRFAMILY  address family for hostname not supported
+       EAI_AGAIN       temporary failure in name resolution
+       EAI_BADFLAGS    invalid value for ai_flags
+       EAI_FAIL        non-recoverable failure in name resolution
+       EAI_FAMILY      ai_family not supported
+       EAI_MEMORY      memory allocation failure
+       EAI_NODATA      no address associated with hostname
+       EAI_NONAME      hostname nor servname provided, or not known
+       EAI_SERVICE     servname not supported for ai_socktype
+       EAI_SOCKTYPE    ai_socktype not supported
+       EAI_SYSTEM      system error returned in errno
+
+   The hostname and servname arguments are pointers to null-terminated
+   strings or NULL.  One or both of these two arguments must be a non-
+   NULL pointer.  In the normal client scenario, both the hostname and
+   servname are specified.  In the normal server scenario, only the
+   servname is specified.  A non-NULL hostname string can be either a
+   host name or a numeric host address string (i.e., a dotted-decimal
+   IPv4 address or an IPv6 hex address).  A non-NULL servname string can
+   be either a service name or a decimal port number.
+
+
+
+
+Gilligan, et. al.            Informational                     [Page 23]
+
+RFC 2133            IPv6 Socket Interface Extensions          April 1997
+
+
+   The caller can optionally pass an addrinfo structure, pointed to by
+   the third argument, to provide hints concerning the type of socket
+   that the caller supports.  In this hints structure all members other
+   than ai_flags, ai_family, ai_socktype, and ai_protocol must be zero
+   or a NULL pointer.  A value of PF_UNSPEC for ai_family means the
+   caller will accept any protocol family.  A value of 0 for ai_socktype
+   means the caller will accept any socket type.  A value of 0 for
+   ai_protocol means the caller will accept any protocol.  For example,
+   if the caller handles only TCP and not UDP, then the ai_socktype
+   member of the hints structure should be set to SOCK_STREAM when
+   getaddrinfo() is called.  If the caller handles only IPv4 and not
+   IPv6, then the ai_family member of the hints structure should be set
+   to PF_INET when getaddrinfo() is called.  If the third argument to
+   getaddrinfo() is a NULL pointer, this is the same as if the caller
+   had filled in an addrinfo structure initialized to zero with
+   ai_family set to PF_UNSPEC.
+
+   Upon successful return a pointer to a linked list of one or more
+   addrinfo structures is returned through the final argument.  The
+   caller can process each addrinfo structure in this list by following
+   the ai_next pointer, until a NULL pointer is encountered.  In each
+   returned addrinfo structure the three members ai_family, ai_socktype,
+   and ai_protocol are the corresponding arguments for a call to the
+   socket() function.  In each addrinfo structure the ai_addr member
+   points to a filled-in socket address structure whose length is
+   specified by the ai_addrlen member.
+
+   If the AI_PASSIVE bit is set in the ai_flags member of the hints
+   structure, then the caller plans to use the returned socket address
+   structure in a call to bind().  In this case, if the hostname
+   argument is a NULL pointer, then the IP address portion of the socket
+   address structure will be set to INADDR_ANY for an IPv4 address or
+   IN6ADDR_ANY_INIT for an IPv6 address.
+
+   If the AI_PASSIVE bit is not set in the ai_flags member of the hints
+   structure, then the returned socket address structure will be ready
+   for a call to connect() (for a connection-oriented protocol) or
+   either connect(), sendto(), or sendmsg() (for a connectionless
+   protocol).  In this case, if the hostname argument is a NULL pointer,
+   then the IP address portion of the socket address structure will be
+   set to the loopback address.
+
+   If the AI_CANONNAME bit is set in the ai_flags member of the hints
+   structure, then upon successful return the ai_canonname member of the
+   first addrinfo structure in the linked list will point to a null-
+   terminated string containing the canonical name of the specified
+   hostname.
+
+
+
+
+Gilligan, et. al.            Informational                     [Page 24]
+
+RFC 2133            IPv6 Socket Interface Extensions          April 1997
+
+
+   All of the information returned by getaddrinfo() is dynamically
+   allocated: the addrinfo structures, and the socket address structures
+   and canonical host name strings pointed to by the addrinfo
+   structures.  To return this information to the system the function
+   freeaddrinfo() is called:
+
+       #include <sys/socket.h>
+       #include <netdb.h>
+
+       void freeaddrinfo(struct addrinfo *ai);
+
+   The addrinfo structure pointed to by the ai argument is freed, along
+   with any dynamic storage pointed to by the structure.  This operation
+   is repeated until a NULL ai_next pointer is encountered.
+
+   To aid applications in printing error messages based on the EAI_xxx
+   codes returned by getaddrinfo(), the following function is defined.
+
+       #include <sys/socket.h>
+       #include <netdb.h>
+
+       char *gai_strerror(int ecode);
+
+   The argument is one of the EAI_xxx values defined earlier and the
+   eturn value points to a string describing the error.  If the argument
+   is not one of the EAI_xxx values, the function still returns a
+   pointer to a string whose contents indicate an unknown error.
+
+6.4.  Socket Address Structure to Hostname and Service Name
+
+   The POSIX 1003.1g specification includes no function to perform the
+   reverse conversion from getaddrinfo():  to look up a hostname and
+   service name, given the binary address and port.  Therefore, we
+   define the following function:
+
+       #include <sys/socket.h>
+       #include <netdb.h>
+
+       int getnameinfo(const struct sockaddr *sa, size_t salen,
+                       char *host, size_t hostlen,
+                       char *serv, size_t servlen,
+                       int flags);
+
+   This function looks up an IP address and port number provided by the
+   caller in the DNS and system-specific database, and returns text
+   strings for both in buffers provided by the caller.  The function
+   indicates successful completion by a zero return value; a non-zero
+   return value indicates failure.
+
+
+
+Gilligan, et. al.            Informational                     [Page 25]
+
+RFC 2133            IPv6 Socket Interface Extensions          April 1997
+
+
+   The first argument, sa, points to either a sockaddr_in structure (for
+   IPv4) or a sockaddr_in6 structure (for IPv6) that holds the IP
+   address and port number.  The salen argument gives the length of the
+   sockaddr_in or sockaddr_in6 structure.
+
+   The function returns the hostname associated with the IP address in
+   the buffer pointed to by the host argument.  The caller provides the
+   size of this buffer via the hostlen argument.  The service name
+   associated with the port number is returned in the buffer pointed to
+   by serv, and the servlen argument gives the length of this buffer.
+   The caller specifies not to return either string by providing a zero
+   value for the hostlen or servlen arguments.  Otherwise, the caller
+   must provide buffers large enough to hold the hostname and the
+   service name, including the terminating null characters.
+
+   Unfortunately most systems do not provide constants that specify the
+   maximum size of either a fully-qualified domain name or a service
+   name.  Therefore to aid the application in allocating buffers for
+   these two returned strings the following constants are defined in
+   <netdb.h>:
+
+       #define NI_MAXHOST  1025
+       #define NI_MAXSERV    32
+
+   The first value is actually defined as the constant MAXDNAME in
+   recent versions of BIND's <arpa/nameser.h> header (older versions of
+   BIND define this constant to be 256) and the second is a guess based
+   on the services listed in the current Assigned Numbers RFC.
+
+   The final argument is a flag that changes the default actions of this
+   function.  By default the fully-qualified domain name (FQDN) for the
+   host is looked up in the DNS and returned.  If the flag bit NI_NOFQDN
+   is set, only the hostname portion of the FQDN is returned for local
+   hosts.
+
+   If the flag bit NI_NUMERICHOST is set, or if the host's name cannot
+   be located in the DNS, the numeric form of the host's address is
+   returned instead of its name (e.g., by calling inet_ntop() instead of
+   gethostbyaddr()).  If the flag bit NI_NAMEREQD is set, an error is
+   returned if the host's name cannot be located in the DNS.
+
+   If the flag bit NI_NUMERICSERV is set, the numeric form of the
+   service address is returned (e.g., its port number) instead of its
+   name.  The two NI_NUMERICxxx flags are required to support the "-n"
+   flag that many commands provide.
+
+
+
+
+
+
+Gilligan, et. al.            Informational                     [Page 26]
+
+RFC 2133            IPv6 Socket Interface Extensions          April 1997
+
+
+   A fifth flag bit, NI_DGRAM, specifies that the service is a datagram
+   service, and causes getservbyport() to be called with a second
+   argument of "udp" instead of its default of "tcp".  This is required
+   for the few ports (512-514) that have different services for UDP and
+   TCP.
+
+   These NI_xxx flags are defined in <netdb.h> along with the AI_xxx
+   flags already defined for getaddrinfo().
+
+6.5.  Address Conversion Functions
+
+   The two functions inet_addr() and inet_ntoa() convert an IPv4 address
+   between binary and text form.  IPv6 applications need similar
+   functions.  The following two functions convert both IPv6 and IPv4
+   addresses:
+
+       #include <sys/socket.h>
+       #include <arpa/inet.h>
+
+       int inet_pton(int af, const char *src, void *dst);
+
+       const char *inet_ntop(int af, const void *src,
+                             char *dst, size_t size);
+
+   The inet_pton() function converts an address in its standard text
+   presentation form into its numeric binary form.  The af argument
+   specifies the family of the address.  Currently the AF_INET and
+   AF_INET6 address families are supported.  The src argument points to
+   the string being passed in.  The dst argument points to a buffer into
+   which the function stores the numeric address.  The address is
+   returned in network byte order.  Inet_pton() returns 1 if the
+   conversion succeeds, 0 if the input is not a valid IPv4 dotted-
+   decimal string or a valid IPv6 address string, or -1 with errno set
+   to EAFNOSUPPORT if the af argument is unknown.  The calling
+   application must ensure that the buffer referred to by dst is large
+   enough to hold the numeric address (e.g., 4 bytes for AF_INET or 16
+   bytes for AF_INET6).
+
+   If the af argument is AF_INET, the function accepts a string in the
+   standard IPv4 dotted-decimal form:
+
+       ddd.ddd.ddd.ddd
+
+   where ddd is a one to three digit decimal number between 0 and 255.
+   Note that many implementations of the existing inet_addr() and
+   inet_aton() functions accept nonstandard input:  octal numbers,
+   hexadecimal numbers, and fewer than four numbers.  inet_pton() does
+   not accept these formats.
+
+
+
+Gilligan, et. al.            Informational                     [Page 27]
+
+RFC 2133            IPv6 Socket Interface Extensions          April 1997
+
+
+   If the af argument is AF_INET6, then the function accepts a string in
+   one of the standard IPv6 text forms defined in Section 2.2 of the
+   addressing architecture specification [2].
+
+   The inet_ntop() function converts a numeric address into a text
+   string suitable for presentation.  The af argument specifies the
+   family of the address.  This can be AF_INET or AF_INET6.  The src
+   argument points to a buffer holding an IPv4 address if the af
+   argument is AF_INET, or an IPv6 address if the af argument is
+   AF_INET6.  The dst argument points to a buffer where the function
+   will store the resulting text string.  The size argument specifies
+   the size of this buffer.  The application must specify a non-NULL dst
+   argument.  For IPv6 addresses, the buffer must be at least 46-octets.
+   For IPv4 addresses, the buffer must be at least 16-octets.  In order
+   to allow applications to easily declare buffers of the proper size to
+   store IPv4 and IPv6 addresses in string form, the following two
+   constants are defined in <netinet/in.h>:
+
+       #define INET_ADDRSTRLEN    16
+       #define INET6_ADDRSTRLEN   46
+
+   The inet_ntop() function returns a pointer to the buffer containing
+   the text string if the conversion succeeds, and NULL otherwise.  Upon
+   failure, errno is set to EAFNOSUPPORT if the af argument is invalid
+   or ENOSPC if the size of the result buffer is inadequate.
+
+6.6.  Address Testing Macros
+
+   The following macros can be used to test for special IPv6 addresses.
+
+       #include <netinet/in.h>
+
+       int  IN6_IS_ADDR_UNSPECIFIED (const struct in6_addr *);
+       int  IN6_IS_ADDR_LOOPBACK    (const struct in6_addr *);
+       int  IN6_IS_ADDR_MULTICAST   (const struct in6_addr *);
+       int  IN6_IS_ADDR_LINKLOCAL   (const struct in6_addr *);
+       int  IN6_IS_ADDR_SITELOCAL   (const struct in6_addr *);
+       int  IN6_IS_ADDR_V4MAPPED    (const struct in6_addr *);
+       int  IN6_IS_ADDR_V4COMPAT    (const struct in6_addr *);
+
+       int  IN6_IS_ADDR_MC_NODELOCAL(const struct in6_addr *);
+       int  IN6_IS_ADDR_MC_LINKLOCAL(const struct in6_addr *);
+       int  IN6_IS_ADDR_MC_SITELOCAL(const struct in6_addr *);
+       int  IN6_IS_ADDR_MC_ORGLOCAL (const struct in6_addr *);
+       int  IN6_IS_ADDR_MC_GLOBAL   (const struct in6_addr *);
+
+
+
+
+
+
+Gilligan, et. al.            Informational                     [Page 28]
+
+RFC 2133            IPv6 Socket Interface Extensions          April 1997
+
+
+   The first seven macros return true if the address is of the specified
+   type, or false otherwise.  The last five test the scope of a
+   multicast address and return true if the address is a multicast
+   address of the specified scope or false if the address is either not
+   a multicast address or not of the specified scope.
+
+7.  Summary of New Definitions
+
+   The following list summarizes the constants, structure, and extern
+   definitions discussed in this memo, sorted by header.
+
+     <net/if.h>      IFNAMSIZ
+     <net/if.h>      struct if_nameindex{};
+
+     <netdb.h>       AI_CANONNAME
+     <netdb.h>       AI_PASSIVE
+     <netdb.h>       EAI_ADDRFAMILY
+     <netdb.h>       EAI_AGAIN
+     <netdb.h>       EAI_BADFLAGS
+     <netdb.h>       EAI_FAIL
+     <netdb.h>       EAI_FAMILY
+     <netdb.h>       EAI_MEMORY
+     <netdb.h>       EAI_NODATA
+     <netdb.h>       EAI_NONAME
+     <netdb.h>       EAI_SERVICE
+     <netdb.h>       EAI_SOCKTYPE
+     <netdb.h>       EAI_SYSTEM
+     <netdb.h>       NI_DGRAM
+     <netdb.h>       NI_MAXHOST
+     <netdb.h>       NI_MAXSERV
+     <netdb.h>       NI_NAMEREQD
+     <netdb.h>       NI_NOFQDN
+     <netdb.h>       NI_NUMERICHOST
+     <netdb.h>       NI_NUMERICSERV
+     <netdb.h>       struct addrinfo{};
+
+     <netinet/in.h>  IN6ADDR_ANY_INIT
+     <netinet/in.h>  IN6ADDR_LOOPBACK_INIT
+     <netinet/in.h>  INET6_ADDRSTRLEN
+     <netinet/in.h>  INET_ADDRSTRLEN
+     <netinet/in.h>  IPPROTO_IPV6
+     <netinet/in.h>  IPV6_ADDRFORM
+     <netinet/in.h>  IPV6_ADD_MEMBERSHIP
+     <netinet/in.h>  IPV6_DROP_MEMBERSHIP
+     <netinet/in.h>  IPV6_MULTICAST_HOPS
+     <netinet/in.h>  IPV6_MULTICAST_IF
+     <netinet/in.h>  IPV6_MULTICAST_LOOP
+     <netinet/in.h>  IPV6_UNICAST_HOPS
+
+
+
+Gilligan, et. al.            Informational                     [Page 29]
+
+RFC 2133            IPv6 Socket Interface Extensions          April 1997
+
+
+     <netinet/in.h>  SIN6_LEN
+     <netinet/in.h>  extern const struct in6_addr in6addr_any;
+     <netinet/in.h>  extern const struct in6_addr in6addr_loopback;
+     <netinet/in.h>  struct in6_addr{};
+     <netinet/in.h>  struct ipv6_mreq{};
+     <netinet/in.h>  struct sockaddr_in6{};
+
+     <resolv.h>      RES_USE_INET6
+
+     <sys/socket.h>  AF_INET6
+     <sys/socket.h>  PF_INET6
+
+
+   The following list summarizes the function and macro prototypes
+   discussed in this memo, sorted by header.
+
+<arpa/inet.h>   int inet_pton(int, const char *, void *);
+<arpa/inet.h>   const char *inet_ntop(int, const void *,
+                                      char *, size_t);
+
+<net/if.h>      char *if_indextoname(unsigned int, char *);
+<net/if.h>      unsigned int if_nametoindex(const char *);
+<net/if.h>      void if_freenameindex(struct if_nameindex *);
+<net/if.h>      struct if_nameindex *if_nameindex(void);
+
+<netdb.h>       int getaddrinfo(const char *, const char *,
+                                const struct addrinfo *,
+                                struct addrinfo **);
+<netdb.h>       int getnameinfo(const struct sockaddr *, size_t,
+                                char *, size_t, char *, size_t, int);
+<netdb.h>       void freeaddrinfo(struct addrinfo *);
+<netdb.h>       char *gai_strerror(int);
+<netdb.h>       struct hostent *gethostbyname(const char *);
+<netdb.h>       struct hostent *gethostbyaddr(const char *, int, int);
+<netdb.h>       struct hostent *gethostbyname2(const char *, int);
+
+<netinet/in.h>  int IN6_IS_ADDR_LINKLOCAL(const struct in6_addr *);
+<netinet/in.h>  int IN6_IS_ADDR_LOOPBACK(const struct in6_addr *);
+<netinet/in.h>  int IN6_IS_ADDR_MC_GLOBAL(const struct in6_addr *);
+<netinet/in.h>  int IN6_IS_ADDR_MC_LINKLOCAL(const struct in6_addr *);
+<netinet/in.h>  int IN6_IS_ADDR_MC_NODELOCAL(const struct in6_addr *);
+<netinet/in.h>  int IN6_IS_ADDR_MC_ORGLOCAL(const struct in6_addr *);
+<netinet/in.h>  int IN6_IS_ADDR_MC_SITELOCAL(const struct in6_addr *);
+<netinet/in.h>  int IN6_IS_ADDR_MULTICAST(const struct in6_addr *);
+<netinet/in.h>  int IN6_IS_ADDR_SITELOCAL(const struct in6_addr *);
+<netinet/in.h>  int IN6_IS_ADDR_UNSPECIFIED(const struct in6_addr *);
+<netinet/in.h>  int IN6_IS_ADDR_V4COMPAT(const struct in6_addr *);
+<netinet/in.h>  int IN6_IS_ADDR_V4MAPPED(const struct in6_addr *);
+
+
+
+Gilligan, et. al.            Informational                     [Page 30]
+
+RFC 2133            IPv6 Socket Interface Extensions          April 1997
+
+
+8.  Security Considerations
+
+   IPv6 provides a number of new security mechanisms, many of which need
+   to be accessible to applications.  A companion memo detailing the
+   extensions to the socket interfaces to support IPv6 security is being
+   written [3].
+
+9.  Acknowledgments
+
+   Thanks to the many people who made suggestions and provided feedback
+   to to the numerous revisions of this document, including: Werner
+   Almesberger, Ran Atkinson, Fred Baker, Dave Borman, Andrew Cherenson,
+   Alex Conta, Alan Cox, Steve Deering, Richard Draves, Francis Dupont,
+   Robert Elz, Marc Hasson, Tim Hartrick, Tom Herbert, Bob Hinden, Wan-
+   Yen Hsu, Christian Huitema, Koji Imada, Markus Jork, Ron Lee, Alan
+   Lloyd, Charles Lynn, Jack McCann, Dan McDonald, Dave Mitton, Thomas
+   Narten, Erik Nordmark, Josh Osborne, Craig Partridge, Jean-Luc
+   Richier, Erik Scoredos, Keith Sklower, Matt Thomas, Harvey Thompson,
+   Dean D. Throop, Karen Tracey, Glenn Trewitt, Paul Vixie, David
+   Waitzman, Carl Williams, and Kazuhiko Yamamoto,
+
+   The getaddrinfo() and getnameinfo() functions are taken from an
+   earlier Work in Progress by Keith Sklower.  As noted in that
+   document, William Durst, Steven Wise, Michael Karels, and Eric Allman
+   provided many useful discussions on the subject of protocol-
+   independent name-to-address translation, and reviewed early versions
+   of Keith Sklower's original proposal.  Eric Allman implemented the
+   first prototype of getaddrinfo().  The observation that specifying
+   the pair of name and service would suffice for connecting to a
+   service independent of protocol details was made by Marshall Rose in
+   a proposal to X/Open for a "Uniform Network Interface".
+
+   Craig Metz made many contributions to this document.  Ramesh Govindan
+   made a number of contributions and co-authored an earlier version of
+   this memo.
+
+10.  References
+
+   [1] Deering, S., and R. Hinden, "Internet Protocol, Version 6 (IPv6)
+       Specification", RFC 1883, December 1995.
+
+   [2] Hinden, R., and S. Deering, "IP Version 6 Addressing Architecture",
+       RFC 1884, December 1995.
+
+   [3] McDonald, D., "A Simple IP Security API Extension to BSD Sockets",
+       Work in Progress.
+
+
+
+
+
+Gilligan, et. al.            Informational                     [Page 31]
+
+RFC 2133            IPv6 Socket Interface Extensions          April 1997
+
+
+   [4] IEEE, "Protocol Independent Interfaces", IEEE Std 1003.1g, DRAFT
+       6.3, November 1995.
+
+   [5] Stevens, W., and M. Thomas, "Advanced Sockets API for IPv6",
+       Work in Progress.
+
+   [6] Vixie, P., "Reverse Name Lookups of Encapsulated IPv4 Addresses in
+       IPv6", Work in Progress.
+
+11.  Authors' Addresses
+
+    Robert E. Gilligan
+    Freegate Corporation
+    710 Lakeway Dr.  STE 230
+    Sunnyvale, CA 94086
+
+    Phone: +1 408 524 4804
+    EMail: gilligan@freegate.net
+
+
+    Susan Thomson
+    Bell Communications Research
+    MRE 2P-343, 445 South Street
+    Morristown, NJ 07960
+
+    Phone: +1 201 829 4514
+    EMail: set@thumper.bellcore.com
+
+
+    Jim Bound
+    Digital Equipment Corporation
+    110 Spitbrook Road ZK3-3/U14
+    Nashua, NH 03062-2698
+
+    Phone: +1 603 881 0400
+    Email: bound@zk3.dec.com
+
+
+    W. Richard Stevens
+    1202 E. Paseo del Zorro
+    Tucson, AZ 85718-2826
+
+    Phone: +1 520 297 9416
+    EMail: rstevens@kohala.com
+
+
+
+
+
+
+
+Gilligan, et. al.            Informational                     [Page 32]
+
diff --git a/doc/rfc/rfc2136.txt b/doc/rfc/rfc2136.txt
new file mode 100644
index 0000000..4d62702
--- /dev/null
+++ b/doc/rfc/rfc2136.txt
@@ -0,0 +1,1460 @@
+
+
+
+
+
+
+Network Working Group                                  P. Vixie, Editor
+Request for Comments: 2136                                          ISC
+Updates: 1035                                                S. Thomson
+Category: Standards Track                                      Bellcore
+                                                             Y. Rekhter
+                                                                  Cisco
+                                                               J. Bound
+                                                                    DEC
+                                                             April 1997
+
+         Dynamic Updates in the Domain Name System (DNS UPDATE)
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Abstract
+
+   The Domain Name System was originally designed to support queries of
+   a statically configured database.  While the data was expected to
+   change, the frequency of those changes was expected to be fairly low,
+   and all updates were made as external edits to a zone's Master File.
+
+   Using this specification of the UPDATE opcode, it is possible to add
+   or delete RRs or RRsets from a specified zone.  Prerequisites are
+   specified separately from update operations, and can specify a
+   dependency upon either the previous existence or nonexistence of an
+   RRset, or the existence of a single RR.
+
+   UPDATE is atomic, i.e., all prerequisites must be satisfied or else
+   no update operations will take place.  There are no data dependent
+   error conditions defined after the prerequisites have been met.
+
+1 - Definitions
+
+   This document intentionally gives more definition to the roles of
+   "Master," "Slave," and "Primary Master" servers, and their
+   enumeration in NS RRs, and the SOA MNAME field.  In that sense, the
+   following server type definitions can be considered an addendum to
+   [RFC1035], and are intended to be consistent with [RFC1996]:
+
+      Slave           an authoritative server that uses AXFR or IXFR to
+                      retrieve the zone and is named in the zone's NS
+                      RRset.
+
+
+
+Vixie, et. al.              Standards Track                     [Page 1]
+
+RFC 2136                       DNS Update                     April 1997
+
+
+      Master          an authoritative server configured to be the
+                      source of AXFR or IXFR data for one or more slave
+                      servers.
+
+      Primary Master  master server at the root of the AXFR/IXFR
+                      dependency graph.  The primary master is named in
+                      the zone's SOA MNAME field and optionally by an NS
+                      RR.  There is by definition only one primary master
+                      server per zone.
+
+   A domain name identifies a node within the domain name space tree
+   structure.  Each node has a set (possibly empty) of Resource Records
+   (RRs).  All RRs having the same NAME, CLASS and TYPE are called a
+   Resource Record Set (RRset).
+
+   The pseudocode used in this document is for example purposes only.
+   If it is found to disagree with the text, the text shall be
+   considered authoritative.  If the text is found to be ambiguous, the
+   pseudocode can be used to help resolve the ambiguity.
+
+   1.1 - Comparison Rules
+
+   1.1.1. Two RRs are considered equal if their NAME, CLASS, TYPE,
+   RDLENGTH and RDATA fields are equal.  Note that the time-to-live
+   (TTL) field is explicitly excluded from the comparison.
+
+   1.1.2. The rules for comparison of character strings in names are
+   specified in [RFC1035 2.3.3].
+
+   1.1.3. Wildcarding is disabled.  That is, a wildcard ("*") in an
+   update only matches a wildcard ("*") in the zone, and vice versa.
+
+   1.1.4. Aliasing is disabled: A CNAME in the zone matches a CNAME in
+   the update, and will not otherwise be followed.  All UPDATE
+   operations are done on the basis of canonical names.
+
+   1.1.5. The following RR types cannot be appended to an RRset.  If the
+   following comparison rules are met, then an attempt to add the new RR
+   will result in the replacement of the previous RR:
+
+      SOA    compare only NAME, CLASS and TYPE -- it is not possible to
+             have more than one SOA per zone, even if any of the data
+             fields differ.
+
+      WKS    compare only NAME, CLASS, TYPE, ADDRESS, and PROTOCOL
+             -- only one WKS RR is possible for this tuple, even if the
+             services masks differ.
+
+
+
+
+Vixie, et. al.              Standards Track                     [Page 2]
+
+RFC 2136                       DNS Update                     April 1997
+
+
+      CNAME  compare only NAME, CLASS, and TYPE -- it is not possible
+             to have more than one CNAME RR, even if their data fields
+             differ.
+
+   1.2 - Glue RRs
+
+   For the purpose of determining whether a domain name used in the
+   UPDATE protocol is contained within a specified zone, a domain name
+   is "in" a zone if it is owned by that zone's domain name.  See
+   section 7.18 for details.
+
+   1.3 - New Assigned Numbers
+
+      CLASS = NONE (254)
+      RCODE = YXDOMAIN (6)
+      RCODE = YXRRSET (7)
+      RCODE = NXRRSET (8)
+      RCODE = NOTAUTH (9)
+      RCODE = NOTZONE (10)
+      Opcode = UPDATE (5)
+
+2 - Update Message Format
+
+   The DNS Message Format is defined by [RFC1035 4.1].  Some extensions
+   are necessary (for example, more error codes are possible under
+   UPDATE than under QUERY) and some fields must be overloaded (see
+   description of CLASS fields below).
+
+   The overall format of an UPDATE message is, following [ibid]:
+
+      +---------------------+
+      |        Header       |
+      +---------------------+
+      |         Zone        | specifies the zone to be updated
+      +---------------------+
+      |     Prerequisite    | RRs or RRsets which must (not) preexist
+      +---------------------+
+      |        Update       | RRs or RRsets to be added or deleted
+      +---------------------+
+      |   Additional Data   | additional data
+      +---------------------+
+
+
+
+
+
+
+
+
+
+
+Vixie, et. al.              Standards Track                     [Page 3]
+
+RFC 2136                       DNS Update                     April 1997
+
+
+   The Header Section specifies that this message is an UPDATE, and
+   describes the size of the other sections.  The Zone Section names the
+   zone that is to be updated by this message.  The Prerequisite Section
+   specifies the starting invariants (in terms of zone content) required
+   for this update.  The Update Section contains the edits to be made,
+   and the Additional Data Section contains data which may be necessary
+   to complete, but is not part of, this update.
+
+   2.1 - Transport Issues
+
+   An update transaction may be carried in a UDP datagram, if the
+   request fits, or in a TCP connection (at the discretion of the
+   requestor).  When TCP is used, the message is in the format described
+   in [RFC1035 4.2.2].
+
+   2.2 - Message Header
+
+   The header of the DNS Message Format is defined by [RFC 1035 4.1].
+   Not all opcodes define the same set of flag bits, though as a
+   practical matter most of the bits defined for QUERY (in [ibid]) are
+   identically defined by the other opcodes.  UPDATE uses only one flag
+   bit (QR).
+
+   The DNS Message Format specifies record counts for its four sections
+   (Question, Answer, Authority, and Additional).  UPDATE uses the same
+   fields, and the same section formats, but the naming and use of these
+   sections differs as shown in the following modified header, after
+   [RFC1035 4.1.1]:
+
+                                      1  1  1  1  1  1
+        0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
+      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+      |                      ID                       |
+      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+      |QR|   Opcode  |          Z         |   RCODE   |
+      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+      |                    ZOCOUNT                    |
+      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+      |                    PRCOUNT                    |
+      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+      |                    UPCOUNT                    |
+      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+      |                    ADCOUNT                    |
+      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+
+
+
+
+
+
+Vixie, et. al.              Standards Track                     [Page 4]
+
+RFC 2136                       DNS Update                     April 1997
+
+
+   These fields are used as follows:
+
+   ID      A 16-bit identifier assigned by the entity that generates any
+           kind of request.  This identifier is copied in the
+           corresponding reply and can be used by the requestor to match
+           replies to outstanding requests, or by the server to detect
+           duplicated requests from some requestor.
+
+   QR      A one bit field that specifies whether this message is a
+           request (0), or a response (1).
+
+   Opcode  A four bit field that specifies the kind of request in this
+           message.  This value is set by the originator of a request
+           and copied into the response.  The Opcode value that
+           identifies an UPDATE message is five (5).
+
+   Z       Reserved for future use.  Should be zero (0) in all requests
+           and responses.  A non-zero Z field should be ignored by
+           implementations of this specification.
+
+   RCODE   Response code - this four bit field is undefined in requests
+           and set in responses.  The values and meanings of this field
+           within responses are as follows:
+
+              Mneumonic   Value   Description
+              ------------------------------------------------------------
+              NOERROR     0       No error condition.
+              FORMERR     1       The name server was unable to interpret
+                                  the request due to a format error.
+              SERVFAIL    2       The name server encountered an internal
+                                  failure while processing this request,
+                                  for example an operating system error
+                                  or a forwarding timeout.
+              NXDOMAIN    3       Some name that ought to exist,
+                                  does not exist.
+              NOTIMP      4       The name server does not support
+                                  the specified Opcode.
+              REFUSED     5       The name server refuses to perform the
+                                  specified operation for policy or
+                                  security reasons.
+              YXDOMAIN    6       Some name that ought not to exist,
+                                  does exist.
+              YXRRSET     7       Some RRset that ought not to exist,
+                                  does exist.
+              NXRRSET     8       Some RRset that ought to exist,
+                                  does not exist.
+
+
+
+
+
+Vixie, et. al.              Standards Track                     [Page 5]
+
+RFC 2136                       DNS Update                     April 1997
+
+
+              NOTAUTH     9       The server is not authoritative for
+                                  the zone named in the Zone Section.
+              NOTZONE     10      A name used in the Prerequisite or
+                                  Update Section is not within the
+                                  zone denoted by the Zone Section.
+
+   ZOCOUNT The number of RRs in the Zone Section.
+
+   PRCOUNT The number of RRs in the Prerequisite Section.
+
+   UPCOUNT The number of RRs in the Update Section.
+
+   ADCOUNT The number of RRs in the Additional Data Section.
+
+   2.3 - Zone Section
+
+   The Zone Section has the same format as that specified in [RFC1035
+   4.1.2], with the fields redefined as follows:
+
+                                      1  1  1  1  1  1
+        0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
+      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+      |                                               |
+      /                     ZNAME                     /
+      /                                               /
+      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+      |                     ZTYPE                     |
+      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+      |                     ZCLASS                    |
+      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+   UPDATE uses this section to denote the zone of the records being
+   updated.  All records to be updated must be in the same zone, and
+   therefore the Zone Section is allowed to contain exactly one record.
+   The ZNAME is the zone name, the ZTYPE must be SOA, and the ZCLASS is
+   the zone's class.
+
+   2.4 - Prerequisite Section
+
+   This section contains a set of RRset prerequisites which must be
+   satisfied at the time the UPDATE packet is received by the primary
+   master server.  The format of this section is as specified by
+   [RFC1035 4.1.3].  There are five possible sets of semantics that can
+   be expressed here, summarized as follows and then explained below.
+
+      (1)  RRset exists (value independent).  At least one RR with a
+           specified NAME and TYPE (in the zone and class specified by
+           the Zone Section) must exist.
+
+
+
+Vixie, et. al.              Standards Track                     [Page 6]
+
+RFC 2136                       DNS Update                     April 1997
+
+
+      (2)  RRset exists (value dependent).  A set of RRs with a
+           specified NAME and TYPE exists and has the same members
+           with the same RDATAs as the RRset specified here in this
+           Section.
+
+      (3)  RRset does not exist.  No RRs with a specified NAME and TYPE
+          (in the zone and class denoted by the Zone Section) can exist.
+
+      (4)  Name is in use.  At least one RR with a specified NAME (in
+           the zone and class specified by the Zone Section) must exist.
+           Note that this prerequisite is NOT satisfied by empty
+           nonterminals.
+
+      (5)  Name is not in use.  No RR of any type is owned by a
+           specified NAME.  Note that this prerequisite IS satisfied by
+           empty nonterminals.
+
+   The syntax of these is as follows:
+
+   2.4.1 - RRset Exists (Value Independent)
+
+   At least one RR with a specified NAME and TYPE (in the zone and class
+   specified in the Zone Section) must exist.
+
+   For this prerequisite, a requestor adds to the section a single RR
+   whose NAME and TYPE are equal to that of the zone RRset whose
+   existence is required.  RDLENGTH is zero and RDATA is therefore
+   empty.  CLASS must be specified as ANY to differentiate this
+   condition from that of an actual RR whose RDLENGTH is naturally zero
+   (0) (e.g., NULL).  TTL is specified as zero (0).
+
+   2.4.2 - RRset Exists (Value Dependent)
+
+   A set of RRs with a specified NAME and TYPE exists and has the same
+   members with the same RDATAs as the RRset specified here in this
+   section.  While RRset ordering is undefined and therefore not
+   significant to this comparison, the sets be identical in their
+   extent.
+
+   For this prerequisite, a requestor adds to the section an entire
+   RRset whose preexistence is required.  NAME and TYPE are that of the
+   RRset being denoted.  CLASS is that of the zone.  TTL must be
+   specified as zero (0) and is ignored when comparing RRsets for
+   identity.
+
+
+
+
+
+
+
+Vixie, et. al.              Standards Track                     [Page 7]
+
+RFC 2136                       DNS Update                     April 1997
+
+
+   2.4.3 - RRset Does Not Exist
+
+   No RRs with a specified NAME and TYPE (in the zone and class denoted
+   by the Zone Section) can exist.
+
+   For this prerequisite, a requestor adds to the section a single RR
+   whose NAME and TYPE are equal to that of the RRset whose nonexistence
+   is required.  The RDLENGTH of this record is zero (0), and RDATA
+   field is therefore empty.  CLASS must be specified as NONE in order
+   to distinguish this condition from a valid RR whose RDLENGTH is
+   naturally zero (0) (for example, the NULL RR).  TTL must be specified
+   as zero (0).
+
+   2.4.4 - Name Is In Use
+
+   Name is in use.  At least one RR with a specified NAME (in the zone
+   and class specified by the Zone Section) must exist.  Note that this
+   prerequisite is NOT satisfied by empty nonterminals.
+
+   For this prerequisite, a requestor adds to the section a single RR
+   whose NAME is equal to that of the name whose ownership of an RR is
+   required.  RDLENGTH is zero and RDATA is therefore empty.  CLASS must
+   be specified as ANY to differentiate this condition from that of an
+   actual RR whose RDLENGTH is naturally zero (0) (e.g., NULL).  TYPE
+   must be specified as ANY to differentiate this case from that of an
+   RRset existence test.  TTL is specified as zero (0).
+
+   2.4.5 - Name Is Not In Use
+
+   Name is not in use.  No RR of any type is owned by a specified NAME.
+   Note that this prerequisite IS satisfied by empty nonterminals.
+
+   For this prerequisite, a requestor adds to the section a single RR
+   whose NAME is equal to that of the name whose nonownership of any RRs
+   is required.  RDLENGTH is zero and RDATA is therefore empty.  CLASS
+   must be specified as NONE.  TYPE must be specified as ANY.  TTL must
+   be specified as zero (0).
+
+   2.5 - Update Section
+
+   This section contains RRs to be added to or deleted from the zone.
+   The format of this section is as specified by [RFC1035 4.1.3].  There
+   are four possible sets of semantics, summarized below and with
+   details to follow.
+
+
+
+
+
+
+
+Vixie, et. al.              Standards Track                     [Page 8]
+
+RFC 2136                       DNS Update                     April 1997
+
+
+      (1) Add RRs to an RRset.
+      (2) Delete an RRset.
+      (3) Delete all RRsets from a name.
+      (4) Delete an RR from an RRset.
+
+   The syntax of these is as follows:
+
+   2.5.1 - Add To An RRset
+
+   RRs are added to the Update Section whose NAME, TYPE, TTL, RDLENGTH
+   and RDATA are those being added, and CLASS is the same as the zone
+   class.  Any duplicate RRs will be silently ignored by the primary
+   master.
+
+   2.5.2 - Delete An RRset
+
+   One RR is added to the Update Section whose NAME and TYPE are those
+   of the RRset to be deleted.  TTL must be specified as zero (0) and is
+   otherwise not used by the primary master.  CLASS must be specified as
+   ANY.  RDLENGTH must be zero (0) and RDATA must therefore be empty.
+   If no such RRset exists, then this Update RR will be silently ignored
+   by the primary master.
+
+   2.5.3 - Delete All RRsets From A Name
+
+   One RR is added to the Update Section whose NAME is that of the name
+   to be cleansed of RRsets.  TYPE must be specified as ANY.  TTL must
+   be specified as zero (0) and is otherwise not used by the primary
+   master.  CLASS must be specified as ANY.  RDLENGTH must be zero (0)
+   and RDATA must therefore be empty.  If no such RRsets exist, then
+   this Update RR will be silently ignored by the primary master.
+
+   2.5.4 - Delete An RR From An RRset
+
+   RRs to be deleted are added to the Update Section.  The NAME, TYPE,
+   RDLENGTH and RDATA must match the RR being deleted.  TTL must be
+   specified as zero (0) and will otherwise be ignored by the primary
+   master.  CLASS must be specified as NONE to distinguish this from an
+   RR addition.  If no such RRs exist, then this Update RR will be
+   silently ignored by the primary master.
+
+
+
+
+
+
+
+
+
+
+
+Vixie, et. al.              Standards Track                     [Page 9]
+
+RFC 2136                       DNS Update                     April 1997
+
+
+   2.6 - Additional Data Section
+
+   This section contains RRs which are related to the update itself, or
+   to new RRs being added by the update.  For example, out of zone glue
+   (A RRs referred to by new NS RRs) should be presented here.  The
+   server can use or ignore out of zone glue, at the discretion of the
+   server implementor.  The format of this section is as specified by
+   [RFC1035 4.1.3].
+
+3 - Server Behavior
+
+   A server, upon receiving an UPDATE request, will signal NOTIMP to the
+   requestor if the UPDATE opcode is not recognized or if it is
+   recognized but has not been implemented.  Otherwise, processing
+   continues as follows.
+
+   3.1 - Process Zone Section
+
+   3.1.1. The Zone Section is checked to see that there is exactly one
+   RR therein and that the RR's ZTYPE is SOA, else signal FORMERR to the
+   requestor.  Next, the ZNAME and ZCLASS are checked to see if the zone
+   so named is one of this server's authority zones, else signal NOTAUTH
+   to the requestor.  If the server is a zone slave, the request will be
+   forwarded toward the primary master.
+
+   3.1.2 - Pseudocode For Zone Section Processing
+
+      if (zcount != 1 || ztype != SOA)
+           return (FORMERR)
+      if (zone_type(zname, zclass) == SLAVE)
+           return forward()
+      if (zone_type(zname, zclass) == MASTER)
+           return update()
+      return (NOTAUTH)
+
+   Sections 3.2 through 3.8 describe the primary master's behaviour,
+   whereas Section 6 describes a forwarder's behaviour.
+
+   3.2 - Process Prerequisite Section
+
+   Next, the Prerequisite Section is checked to see that all
+   prerequisites are satisfied by the current state of the zone.  Using
+   the definitions expressed in Section 1.2, if any RR's NAME is not
+   within the zone specified in the Zone Section, signal NOTZONE to the
+   requestor.
+
+
+
+
+
+
+Vixie, et. al.              Standards Track                    [Page 10]
+
+RFC 2136                       DNS Update                     April 1997
+
+
+   3.2.1. For RRs in this section whose CLASS is ANY, test to see that
+   TTL and RDLENGTH are both zero (0), else signal FORMERR to the
+   requestor.  If TYPE is ANY, test to see that there is at least one RR
+   in the zone whose NAME is the same as that of the Prerequisite RR,
+   else signal NXDOMAIN to the requestor.  If TYPE is not ANY, test to
+   see that there is at least one RR in the zone whose NAME and TYPE are
+   the same as that of the Prerequisite RR, else signal NXRRSET to the
+   requestor.
+
+   3.2.2. For RRs in this section whose CLASS is NONE, test to see that
+   the TTL and RDLENGTH are both zero (0), else signal FORMERR to the
+   requestor.  If the TYPE is ANY, test to see that there are no RRs in
+   the zone whose NAME is the same as that of the Prerequisite RR, else
+   signal YXDOMAIN to the requestor.  If the TYPE is not ANY, test to
+   see that there are no RRs in the zone whose NAME and TYPE are the
+   same as that of the Prerequisite RR, else signal YXRRSET to the
+   requestor.
+
+   3.2.3. For RRs in this section whose CLASS is the same as the ZCLASS,
+   test to see that the TTL is zero (0), else signal FORMERR to the
+   requestor.  Then, build an RRset for each unique <NAME,TYPE> and
+   compare each resulting RRset for set equality (same members, no more,
+   no less) with RRsets in the zone.  If any Prerequisite RRset is not
+   entirely and exactly matched by a zone RRset, signal NXRRSET to the
+   requestor.  If any RR in this section has a CLASS other than ZCLASS
+   or NONE or ANY, signal FORMERR to the requestor.
+
+   3.2.4 - Table Of Metavalues Used In Prerequisite Section
+
+   CLASS    TYPE     RDATA    Meaning
+   ------------------------------------------------------------
+   ANY      ANY      empty    Name is in use
+   ANY      rrset    empty    RRset exists (value independent)
+   NONE     ANY      empty    Name is not in use
+   NONE     rrset    empty    RRset does not exist
+   zone     rrset    rr       RRset exists (value dependent)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Vixie, et. al.              Standards Track                    [Page 11]
+
+RFC 2136                       DNS Update                     April 1997
+
+
+   3.2.5 - Pseudocode for Prerequisite Section Processing
+
+      for rr in prerequisites
+           if (rr.ttl != 0)
+                return (FORMERR)
+           if (zone_of(rr.name) != ZNAME)
+                return (NOTZONE);
+           if (rr.class == ANY)
+                if (rr.rdlength != 0)
+                     return (FORMERR)
+                if (rr.type == ANY)
+                     if (!zone_name<rr.name>)
+                          return (NXDOMAIN)
+                else
+                     if (!zone_rrset<rr.name, rr.type>)
+                          return (NXRRSET)
+           if (rr.class == NONE)
+                if (rr.rdlength != 0)
+                     return (FORMERR)
+                if (rr.type == ANY)
+                     if (zone_name<rr.name>)
+                          return (YXDOMAIN)
+                else
+                     if (zone_rrset<rr.name, rr.type>)
+                          return (YXRRSET)
+           if (rr.class == zclass)
+                temp<rr.name, rr.type> += rr
+           else
+                return (FORMERR)
+
+      for rrset in temp
+           if (zone_rrset<rrset.name, rrset.type> != rrset)
+                return (NXRRSET)
+
+   3.3 - Check Requestor's Permissions
+
+   3.3.1. Next, the requestor's permission to update the RRs named in
+   the Update Section may be tested in an implementation dependent
+   fashion or using mechanisms specified in a subsequent Secure DNS
+   Update protocol.  If the requestor does not have permission to
+   perform these updates, the server may write a warning message in its
+   operations log, and may either signal REFUSED to the requestor, or
+   ignore the permission problem and proceed with the update.
+
+
+
+
+
+
+
+
+Vixie, et. al.              Standards Track                    [Page 12]
+
+RFC 2136                       DNS Update                     April 1997
+
+
+   3.3.2. While the exact processing is implementation defined, if these
+   verification activities are to be performed, this is the point in the
+   server's processing where such performance should take place, since
+   if a REFUSED condition is encountered after an update has been
+   partially applied, it will be necessary to undo the partial update
+   and restore the zone to its original state before answering the
+   requestor.
+
+   3.3.3 - Pseudocode for Permission Checking
+
+      if (security policy exists)
+           if (this update is not permitted)
+                if (local option)
+                     log a message about permission problem
+                if (local option)
+                     return (REFUSED)
+
+   3.4 - Process Update Section
+
+   Next, the Update Section is processed as follows.
+
+   3.4.1 - Prescan
+
+   The Update Section is parsed into RRs and each RR's CLASS is checked
+   to see if it is ANY, NONE, or the same as the Zone Class, else signal
+   a FORMERR to the requestor.  Using the definitions in Section 1.2,
+   each RR's NAME must be in the zone specified by the Zone Section,
+   else signal NOTZONE to the requestor.
+
+   3.4.1.2. For RRs whose CLASS is not ANY, check the TYPE and if it is
+   ANY, AXFR, MAILA, MAILB, or any other QUERY metatype, or any
+   unrecognized type, then signal FORMERR to the requestor.  For RRs
+   whose CLASS is ANY or NONE, check the TTL to see that it is zero (0),
+   else signal a FORMERR to the requestor.  For any RR whose CLASS is
+   ANY, check the RDLENGTH to make sure that it is zero (0) (that is,
+   the RDATA field is empty), and that the TYPE is not AXFR, MAILA,
+   MAILB, or any other QUERY metatype besides ANY, or any unrecognized
+   type, else signal FORMERR to the requestor.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Vixie, et. al.              Standards Track                    [Page 13]
+
+RFC 2136                       DNS Update                     April 1997
+
+
+   3.4.1.3 - Pseudocode For Update Section Prescan
+
+      [rr] for rr in updates
+           if (zone_of(rr.name) != ZNAME)
+                return (NOTZONE);
+           if (rr.class == zclass)
+                if (rr.type & ANY|AXFR|MAILA|MAILB)
+                     return (FORMERR)
+           elsif (rr.class == ANY)
+                if (rr.ttl != 0 || rr.rdlength != 0
+                    || rr.type & AXFR|MAILA|MAILB)
+                     return (FORMERR)
+           elsif (rr.class == NONE)
+                if (rr.ttl != 0 || rr.type & ANY|AXFR|MAILA|MAILB)
+                     return (FORMERR)
+           else
+                return (FORMERR)
+
+   3.4.2 - Update
+
+   The Update Section is parsed into RRs and these RRs are processed in
+   order.
+
+   3.4.2.1. If any system failure (such as an out of memory condition,
+   or a hardware error in persistent storage) occurs during the
+   processing of this section, signal SERVFAIL to the requestor and undo
+   all updates applied to the zone during this transaction.
+
+   3.4.2.2. Any Update RR whose CLASS is the same as ZCLASS is added to
+   the zone.  In case of duplicate RDATAs (which for SOA RRs is always
+   the case, and for WKS RRs is the case if the ADDRESS and PROTOCOL
+   fields both match), the Zone RR is replaced by Update RR.  If the
+   TYPE is SOA and there is no Zone SOA RR, or the new SOA.SERIAL is
+   lower (according to [RFC1982]) than or equal to the current Zone SOA
+   RR's SOA.SERIAL, the Update RR is ignored.  In the case of a CNAME
+   Update RR and a non-CNAME Zone RRset or vice versa, ignore the CNAME
+   Update RR, otherwise replace the CNAME Zone RR with the CNAME Update
+   RR.
+
+   3.4.2.3. For any Update RR whose CLASS is ANY and whose TYPE is ANY,
+   all Zone RRs with the same NAME are deleted, unless the NAME is the
+   same as ZNAME in which case only those RRs whose TYPE is other than
+   SOA or NS are deleted.  For any Update RR whose CLASS is ANY and
+   whose TYPE is not ANY all Zone RRs with the same NAME and TYPE are
+   deleted, unless the NAME is the same as ZNAME in which case neither
+   SOA or NS RRs will be deleted.
+
+
+
+
+
+Vixie, et. al.              Standards Track                    [Page 14]
+
+RFC 2136                       DNS Update                     April 1997
+
+
+   3.4.2.4. For any Update RR whose class is NONE, any Zone RR whose
+   NAME, TYPE, RDATA and RDLENGTH are equal to the Update RR is deleted,
+   unless the NAME is the same as ZNAME and either the TYPE is SOA or
+   the TYPE is NS and the matching Zone RR is the only NS remaining in
+   the RRset, in which case this Update RR is ignored.
+
+   3.4.2.5. Signal NOERROR to the requestor.
+
+   3.4.2.6 - Table Of Metavalues Used In Update Section
+
+   CLASS    TYPE     RDATA    Meaning
+   ---------------------------------------------------------
+   ANY      ANY      empty    Delete all RRsets from a name
+   ANY      rrset    empty    Delete an RRset
+   NONE     rrset    rr       Delete an RR from an RRset
+   zone     rrset    rr       Add to an RRset
+
+   3.4.2.7 - Pseudocode For Update Section Processing
+
+      [rr] for rr in updates
+           if (rr.class == zclass)
+                if (rr.type == CNAME)
+                     if (zone_rrset<rr.name, ~CNAME>)
+                          next [rr]
+                elsif (zone_rrset<rr.name, CNAME>)
+                     next [rr]
+                if (rr.type == SOA)
+                     if (!zone_rrset<rr.name, SOA> ||
+                         zone_rr<rr.name, SOA>.serial > rr.soa.serial)
+                          next [rr]
+                for zrr in zone_rrset<rr.name, rr.type>
+                     if (rr.type == CNAME || rr.type == SOA ||
+                         (rr.type == WKS && rr.proto == zrr.proto &&
+                          rr.address == zrr.address) ||
+                         rr.rdata == zrr.rdata)
+                          zrr = rr
+                          next [rr]
+                zone_rrset<rr.name, rr.type> += rr
+           elsif (rr.class == ANY)
+                if (rr.type == ANY)
+                     if (rr.name == zname)
+                          zone_rrset<rr.name, ~(SOA|NS)> = Nil
+                     else
+                          zone_rrset<rr.name, *> = Nil
+                elsif (rr.name == zname &&
+                       (rr.type == SOA || rr.type == NS))
+                     next [rr]
+                else
+
+
+
+Vixie, et. al.              Standards Track                    [Page 15]
+
+RFC 2136                       DNS Update                     April 1997
+
+
+                     zone_rrset<rr.name, rr.type> = Nil
+           elsif (rr.class == NONE)
+                if (rr.type == SOA)
+                     next [rr]
+                if (rr.type == NS && zone_rrset<rr.name, NS> == rr)
+                     next [rr]
+                zone_rr<rr.name, rr.type, rr.data> = Nil
+      return (NOERROR)
+
+   3.5 - Stability
+
+   When a zone is modified by an UPDATE operation, the server must
+   commit the change to nonvolatile storage before sending a response to
+   the requestor or answering any queries or transfers for the modified
+   zone.  It is reasonable for a server to store only the update records
+   as long as a system reboot or power failure will cause these update
+   records to be incorporated into the zone the next time the server is
+   started.  It is also reasonable for the server to copy the entire
+   modified zone to nonvolatile storage after each update operation,
+   though this would have suboptimal performance for large zones.
+
+   3.6 - Zone Identity
+
+   If the zone's SOA SERIAL is changed by an update operation, that
+   change must be in a positive direction (using modulo 2**32 arithmetic
+   as specified by [RFC1982]).  Attempts to replace an SOA with one
+   whose SERIAL is less than the current one will be silently ignored by
+   the primary master server.
+
+   If the zone's SOA's SERIAL is not changed as a result of an update
+   operation, then the server shall increment it automatically before
+   the SOA or any changed name or RR or RRset is included in any
+   response or transfer.  The primary master server's implementor might
+   choose to autoincrement the SOA SERIAL if any of the following events
+   occurs:
+
+   (1)  Each update operation.
+
+   (2)  A name, RR or RRset in the zone has changed and has subsequently
+        been visible to a DNS client since the unincremented SOA was
+        visible to a DNS client, and the SOA is about to become visible
+        to a DNS client.
+
+   (3)  A configurable period of time has elapsed since the last update
+        operation.  This period shall be less than or equal to one third
+        of the zone refresh time, and the default shall be the lesser of
+        that maximum and 300 seconds.
+
+
+
+
+Vixie, et. al.              Standards Track                    [Page 16]
+
+RFC 2136                       DNS Update                     April 1997
+
+
+   (4)  A configurable number of updates has been applied since the last
+        SOA change.  The default value for this configuration parameter
+        shall be one hundred (100).
+
+   It is imperative that the zone's contents and the SOA's SERIAL be
+   tightly synchronized.  If the zone appears to change, the SOA must
+   appear to change as well.
+
+   3.7 - Atomicity
+
+   During the processing of an UPDATE transaction, the server must
+   ensure atomicity with respect to other (concurrent) UPDATE or QUERY
+   transactions.  No two transactions can be processed concurrently if
+   either depends on the final results of the other; in particular, a
+   QUERY should not be able to retrieve RRsets which have been partially
+   modified by a concurrent UPDATE, and an UPDATE should not be able to
+   start from prerequisites that might not still hold at the completion
+   of some other concurrent UPDATE.  Finally, if two UPDATE transactions
+   would modify the same names, RRs or RRsets, then such UPDATE
+   transactions must be serialized.
+
+   3.8 - Response
+
+   At the end of UPDATE processing, a response code will be known.  A
+   response message is generated by copying the ID and Opcode fields
+   from the request, and either copying the ZOCOUNT, PRCOUNT, UPCOUNT,
+   and ADCOUNT fields and associated sections, or placing zeros (0) in
+   the these "count" fields and not including any part of the original
+   update.  The QR bit is set to one (1), and the response is sent back
+   to the requestor.  If the requestor used UDP, then the response will
+   be sent to the requestor's source UDP port.  If the requestor used
+   TCP, then the response will be sent back on the requestor's open TCP
+   connection.
+
+4 - Requestor Behaviour
+
+   4.1. From a requestor's point of view, any authoritative server for
+   the zone can appear to be able to process update requests, even
+   though only the primary master server is actually able to modify the
+   zone's master file.  Requestors are expected to know the name of the
+   zone they intend to update and to know or be able to determine the
+   name servers for that zone.
+
+
+
+
+
+
+
+
+
+Vixie, et. al.              Standards Track                    [Page 17]
+
+RFC 2136                       DNS Update                     April 1997
+
+
+   4.2. If update ordering is desired, the requestor will need to know
+   the value of the existing SOA RR.  Requestors who update the SOA RR
+   must update the SOA SERIAL field in a positive direction (as defined
+   by [RFC1982]) and also preserve the other SOA fields unless the
+   requestor's explicit intent is to change them.  The SOA SERIAL field
+   must never be set to zero (0).
+
+   4.3. If the requestor has reasonable cause to believe that all of a
+   zone's servers will be equally reachable, then it should arrange to
+   try the primary master server (as given by the SOA MNAME field if
+   matched by some NS NSDNAME) first to avoid unnecessary forwarding
+   inside the slave servers.  (Note that the primary master will in some
+   cases not be reachable by all requestors, due to firewalls or network
+   partitioning.)
+
+   4.4. Once the zone's name servers been found and possibly sorted so
+   that the ones more likely to be reachable and/or support the UPDATE
+   opcode are listed first, the requestor composes an UPDATE message of
+   the following form and sends it to the first name server on its list:
+
+      ID:                        (new)
+      Opcode:                    UPDATE
+      Zone zcount:               1
+      Zone zname:                (zone name)
+      Zone zclass:               (zone class)
+      Zone ztype:                T_SOA
+      Prerequisite Section:      (see previous text)
+      Update Section:            (see previous text)
+      Additional Data Section:   (empty)
+
+   4.5. If the requestor receives a response, and the response has an
+   RCODE other than SERVFAIL or NOTIMP, then the requestor returns an
+   appropriate response to its caller.
+
+   4.6. If a response is received whose RCODE is SERVFAIL or NOTIMP, or
+   if no response is received within an implementation dependent timeout
+   period, or if an ICMP error is received indicating that the server's
+   port is unreachable, then the requestor will delete the unusable
+   server from its internal name server list and try the next one,
+   repeating until the name server list is empty.  If the requestor runs
+   out of servers to try, an appropriate error will be returned to the
+   requestor's caller.
+
+
+
+
+
+
+
+
+
+Vixie, et. al.              Standards Track                    [Page 18]
+
+RFC 2136                       DNS Update                     April 1997
+
+
+5 - Duplicate Detection, Ordering and Mutual Exclusion
+
+   5.1. For correct operation, mechanisms may be needed to ensure
+   idempotence, order UPDATE requests and provide mutual exclusion.  An
+   UPDATE message or response might be delivered zero times, one time,
+   or multiple times.  Datagram duplication is of particular interest
+   since it covers the case of the so-called "replay attack" where a
+   correct request is duplicated maliciously by an intruder.
+
+   5.2. Multiple UPDATE requests or responses in transit might be
+   delivered in any order, due to network topology changes or load
+   balancing, or to multipath forwarding graphs wherein several slave
+   servers all forward to the primary master.  In some cases, it might
+   be required that the earlier update not be applied after the later
+   update, where "earlier" and "later" are defined by an external time
+   base visible to some set of requestors, rather than by the order of
+   request receipt at the primary master.
+
+   5.3. A requestor can ensure transaction idempotence by explicitly
+   deleting some "marker RR" (rather than deleting the RRset of which it
+   is a part) and then adding a new "marker RR" with a different RDATA
+   field.  The Prerequisite Section should specify that the original
+   "marker RR" must be present in order for this UPDATE message to be
+   accepted by the server.
+
+   5.4. If the request is duplicated by a network error, all duplicate
+   requests will fail since only the first will find the original
+   "marker RR" present and having its known previous value.  The
+   decisions of whether to use such a "marker RR" and what RR to use are
+   left up to the application programmer, though one obvious choice is
+   the zone's SOA RR as described below.
+
+   5.5. Requestors can ensure update ordering by externally
+   synchronizing their use of successive values of the "marker RR."
+   Mutual exclusion can be addressed as a degenerate case, in that a
+   single succession of the "marker RR" is all that is needed.
+
+   5.6. A special case where update ordering and datagram duplication
+   intersect is when an RR validly changes to some new value and then
+   back to its previous value.  Without a "marker RR" as described
+   above, this sequence of updates can leave the zone in an undefined
+   state if datagrams are duplicated.
+
+   5.7. To achieve an atomic multitransaction "read-modify-write" cycle,
+   a requestor could first retrieve the SOA RR, and build an UPDATE
+   message one of whose prerequisites was the old SOA RR.  It would then
+   specify updates that would delete this SOA RR and add a new one with
+   an incremented SOA SERIAL, along with whatever actual prerequisites
+
+
+
+Vixie, et. al.              Standards Track                    [Page 19]
+
+RFC 2136                       DNS Update                     April 1997
+
+
+   and updates were the object of the transaction.  If the transaction
+   succeeds, the requestor knows that the RRs being changed were not
+   otherwise altered by any other requestor.
+
+6 - Forwarding
+
+   When a zone slave forwards an UPDATE message upward toward the zone's
+   primary master server, it must allocate a new ID and prepare to enter
+   the role of "forwarding server," which is a requestor with respect to
+   the forward server.
+
+   6.1. The set of forward servers will be same as the set of servers
+   this zone slave would use as the source of AXFR or IXFR data.  So,
+   while the original requestor might have used the zone's NS RRset to
+   locate its update server, a forwarder always forwards toward its
+   designated zone master servers.
+
+   6.2. If the original requestor used TCP, then the TCP connection from
+   the requestor is still open and the forwarder must use TCP to forward
+   the message.  If the original requestor used UDP, the forwarder may
+   use either UDP or TCP to forward the message, at the whim of the
+   implementor.
+
+   6.3. It is reasonable for forward servers to be forwarders
+   themselves, if the AXFR dependency graph being followed is a deep one
+   involving firewalls and multiple connectivity realms.  In most cases
+   the AXFR dependency graph will be shallow and the forward server will
+   be the primary master server.
+
+   6.4. The forwarder will not respond to its requestor until it
+   receives a response from its forward server.  UPDATE transactions
+   involving forwarders are therefore time synchronized with respect to
+   the original requestor and the primary master server.
+
+   6.5. When there are multiple possible sources of AXFR data and
+   therefore multiple possible forward servers, a forwarder will use the
+   same fallback strategy with respect to connectivity or timeout errors
+   that it would use when performing an AXFR.  This is implementation
+   dependent.
+
+   6.6. When a forwarder receives a response from a forward server, it
+   copies this response into a new response message, assigns its
+   requestor's ID to that message, and sends the response back to the
+   requestor.
+
+
+
+
+
+
+
+Vixie, et. al.              Standards Track                    [Page 20]
+
+RFC 2136                       DNS Update                     April 1997
+
+
+7 - Design, Implementation, Operation, and Protocol Notes
+
+   Some of the principles which guided the design of this UPDATE
+   specification are as follows.  Note that these are not part of the
+   formal specification and any disagreement between this section and
+   any other section of this document should be resolved in favour of
+   the other section.
+
+   7.1. Using metavalues for CLASS is possible only because all RRs in
+   the packet are assumed to be in the same zone, and CLASS is an
+   attribute of a zone rather than of an RRset.  (It is for this reason
+   that the Zone Section is not optional.)
+
+   7.2. Since there are no data-present or data-absent errors possible
+   from processing the Update Section, any necessary data-present and
+   data- absent dependencies should be specified in the Prerequisite
+   Section.
+
+   7.3. The Additional Data Section can be used to supply a server with
+   out of zone glue that will be needed in referrals.  For example, if
+   adding a new NS RR to HOME.VIX.COM specifying a nameserver called
+   NS.AU.OZ, the A RR for NS.AU.OZ can be included in the Additional
+   Data Section.  Servers can use this information or ignore it, at the
+   discretion of the implementor.  We discourage caching this
+   information for use in subsequent DNS responses.
+
+   7.4. The Additional Data Section might be used if some of the RRs
+   later needed for Secure DNS Update are not actually zone updates, but
+   rather ancillary keys or signatures not intended to be stored in the
+   zone (as an update would be), yet necessary for validating the update
+   operation.
+
+   7.5. It is expected that in the absence of Secure DNS Update, a
+   server will only accept updates if they come from a source address
+   that has been statically configured in the server's description of a
+   primary master zone.  DHCP servers would be likely candidates for
+   inclusion in this statically configured list.
+
+   7.6. It is not possible to create a zone using this protocol, since
+   there is no provision for a slave server to be told who its master
+   servers are.  It is expected that this protocol will be extended in
+   the future to cover this case.  Therefore, at this time, the addition
+   of SOA RRs is unsupported.  For similar reasons, deletion of SOA RRs
+   is also unsupported.
+
+
+
+
+
+
+
+Vixie, et. al.              Standards Track                    [Page 21]
+
+RFC 2136                       DNS Update                     April 1997
+
+
+   7.7. The prerequisite for specifying that a name own at least one RR
+   differs semantically from QUERY, in that QUERY would return
+   <NOERROR,ANCOUNT=0> rather than NXDOMAIN if queried for an RRset at
+   this name, while UPDATE's prerequisite condition [Section 2.4.4]
+   would NOT be satisfied.
+
+   7.8. It is possible for a UDP response to be lost in transit and for
+   a request to be retried due to a timeout condition.  In this case an
+   UPDATE that was successful the first time it was received by the
+   primary master might ultimately appear to have failed when the
+   response to a duplicate request is finally received by the requestor.
+   (This is because the original prerequisites may no longer be
+   satisfied after the update has been applied.)  For this reason,
+   requestors who require an accurate response code must use TCP.
+
+   7.9. Because a requestor who requires an accurate response code will
+   initiate their UPDATE transaction using TCP, a forwarder who receives
+   a request via TCP must forward it using TCP.
+
+   7.10. Deferral of SOA SERIAL autoincrements is made possible so that
+   serial numbers can be conserved and wraparound at 2**32 can be made
+   an infrequent occurance.  Visible (to DNS clients) SOA SERIALs need
+   to differ if the zone differs.  Note that the Authority Section SOA
+   in a QUERY response is a form of visibility, for the purposes of this
+   prerequisite.
+
+   7.11. A zone's SOA SERIAL should never be set to zero (0) due to
+   interoperability problems with some older but widely installed
+   implementations of DNS.  When incrementing an SOA SERIAL, if the
+   result of the increment is zero (0) (as will be true when wrapping
+   around 2**32), it is necessary to increment it again or set it to one
+   (1).  See [RFC1982] for more detail on this subject.
+
+   7.12. Due to the TTL minimalization necessary when caching an RRset,
+   it is recommended that all TTLs in an RRset be set to the same value.
+   While the DNS Message Format permits variant TTLs to exist in the
+   same RRset, and this variance can exist inside a zone, such variance
+   will have counterintuitive results and its use is discouraged.
+
+   7.13. Zone cut management presents some obscure corner cases to the
+   add and delete operations in the Update Section.  It is possible to
+   delete an NS RR as long as it is not the last NS RR at the root of a
+   zone.  If deleting all RRs from a name, SOA and NS RRs at the root of
+   a zone are unaffected.  If deleting RRsets, it is not possible to
+   delete either SOA or NS RRsets at the top of a zone.  An attempt to
+   add an SOA will be treated as a replace operation if an SOA already
+   exists, or as a no-op if the SOA would be new.
+
+
+
+
+Vixie, et. al.              Standards Track                    [Page 22]
+
+RFC 2136                       DNS Update                     April 1997
+
+
+   7.14. No semantic checking is required in the primary master server
+   when adding new RRs.  Therefore a requestor can cause CNAME or NS or
+   any other kind of RR to be added even if their target name does not
+   exist or does not have the proper RRsets to make the original RR
+   useful.  Primary master servers that DO implement this kind of
+   checking should take great care to avoid out-of-zone dependencies
+   (whose veracity cannot be authoritatively checked) and should
+   implement all such checking during the prescan phase.
+
+   7.15. Nonterminal or wildcard CNAMEs are not well specified by
+   [RFC1035] and their use will probably lead to unpredictable results.
+   Their use is discouraged.
+
+   7.16. Empty nonterminals (nodes with children but no RRs of their
+   own) will cause <NOERROR,ANCOUNT=0> responses to be sent in response
+   to a query of any type for that name.  There is no provision for
+   empty terminal nodes -- so if all RRs of a terminal node are deleted,
+   the name is no longer in use, and queries of any type for that name
+   will result in an NXDOMAIN response.
+
+   7.17. In a deep AXFR dependency graph, it has not historically been
+   an error for slaves to depend mutually upon each other.  This
+   configuration has been used to enable a zone to flow from the primary
+   master to all slaves even though not all slaves have continuous
+   connectivity to the primary master.  UPDATE's use of the AXFR
+   dependency graph for forwarding prohibits this kind of dependency
+   loop, since UPDATE forwarding has no loop detection analagous to the
+   SOA SERIAL pretest used by AXFR.
+
+   7.18. Previously existing names which are occluded by a new zone cut
+   are still considered part of the parent zone, for the purposes of
+   zone transfers, even though queries for such names will be referred
+   to the new subzone's servers.  If a zone cut is removed, all parent
+   zone names that were occluded by it will again become visible to
+   queries.  (This is a clarification of [RFC1034].)
+
+   7.19. If a server is authoritative for both a zone and its child,
+   then queries for names at the zone cut between them will be answered
+   authoritatively using only data from the child zone.  (This is a
+   clarification of [RFC1034].)
+
+
+
+
+
+
+
+
+
+
+
+Vixie, et. al.              Standards Track                    [Page 23]
+
+RFC 2136                       DNS Update                     April 1997
+
+
+   7.20. Update ordering using the SOA RR is problematic since there is
+   no way to know which of a zone's NS RRs represents the primary
+   master, and the zone slaves can be out of date if their SOA.REFRESH
+   timers have not elapsed since the last time the zone was changed on
+   the primary master.  We recommend that a zone needing ordered updates
+   use only servers which implement NOTIFY (see [RFC1996]) and IXFR (see
+   [RFC1995]), and that a client receiving a prerequisite error while
+   attempting an ordered update simply retry after a random delay period
+   to allow the zone to settle.
+
+8 - Security Considerations
+
+   8.1. In the absence of [RFC2137] or equivilent technology, the
+   protocol described by this document makes it possible for anyone who
+   can reach an authoritative name server to alter the contents of any
+   zones on that server.  This is a serious increase in vulnerability
+   from the current technology.  Therefore it is very strongly
+   recommended that the protocols described in this document not be used
+   without [RFC2137] or other equivalently strong security measures,
+   e.g. IPsec.
+
+   8.2. A denial of service attack can be launched by flooding an update
+   forwarder with TCP sessions containing updates that the primary
+   master server will ultimately refuse due to permission problems.
+   This arises due to the requirement that an update forwarder receiving
+   a request via TCP use a synchronous TCP session for its forwarding
+   operation.  The connection management mechanisms of [RFC1035 4.2.2]
+   are sufficient to prevent large scale damage from such an attack, but
+   not to prevent some queries from going unanswered during the attack.
+
+Acknowledgements
+
+   We would like to thank the IETF DNSIND working group for their input
+   and assistance, in particular, Rob Austein, Randy Bush, Donald
+   Eastlake, Masataka Ohta, Mark Andrews, and Robert Elz.  Special
+   thanks to Bill Simpson, Ken Wallich and Bob Halley for reviewing this
+   document.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Vixie, et. al.              Standards Track                    [Page 24]
+
+RFC 2136                       DNS Update                     April 1997
+
+
+References
+
+   [RFC1035]
+      Mockapetris, P., "Domain Names - Implementation and
+      Specification", STD 13, RFC 1035, USC/Information Sciences
+      Institute, November 1987.
+
+   [RFC1982]
+      Elz, R., "Serial Number Arithmetic", RFC 1982, University of
+      Melbourne, August 1996.
+
+   [RFC1995]
+      Ohta, M., "Incremental Zone Transfer", RFC 1995, Tokyo Institute
+      of Technology, August 1996.
+
+   [RFC1996]
+      Vixie, P., "A Mechanism for Prompt Notification of Zone Changes",
+      RFC 1996, Internet Software Consortium, August 1996.
+
+   [RFC2065]
+      Eastlake, D., and C. Kaufman, "Domain Name System Protocol
+      Security Extensions", RFC 2065, January 1997.
+
+   [RFC2137]
+      Eastlake, D., "Secure Domain Name System Dynamic Update", RFC
+      2137, April 1997.
+
+Authors' Addresses
+
+   Yakov Rekhter
+   Cisco Systems
+   170 West Tasman Drive
+   San Jose, CA 95134-1706
+
+   Phone: +1 914 528 0090
+   EMail: yakov@cisco.com
+
+
+   Susan Thomson
+   Bellcore
+   445 South Street
+   Morristown, NJ 07960
+
+   Phone: +1 201 829 4514
+   EMail: set@thumper.bellcore.com
+
+
+
+
+
+
+Vixie, et. al.              Standards Track                    [Page 25]
+
+RFC 2136                       DNS Update                     April 1997
+
+
+   Jim Bound
+   Digital Equipment Corp.
+   110 Spitbrook Rd ZK3-3/U14
+   Nashua, NH 03062-2698
+
+   Phone: +1 603 881 0400
+   EMail: bound@zk3.dec.com
+
+
+   Paul Vixie
+   Internet Software Consortium
+   Star Route Box 159A
+   Woodside, CA 94062
+
+   Phone: +1 415 747 0204
+   EMail: paul@vix.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Vixie, et. al.              Standards Track                    [Page 26]
+
+
diff --git a/doc/rfc/rfc2137.txt b/doc/rfc/rfc2137.txt
new file mode 100644
index 0000000..ceb3613
--- /dev/null
+++ b/doc/rfc/rfc2137.txt
@@ -0,0 +1,619 @@
+
+
+
+
+
+
+Network Working Group                                    D. Eastlake 3rd
+Request for Comments: 2137                               CyberCash, Inc.
+Updates: 1035                                                 April 1997
+Category: Standards Track
+
+
+                Secure Domain Name System Dynamic Update
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Abstract
+
+   Domain Name System (DNS) protocol extensions have been defined to
+   authenticate the data in DNS and provide key distribution services
+   [RFC2065].  DNS Dynamic Update operations have also been defined
+   [RFC2136], but without a detailed description of security for the
+   update operation.  This memo describes how to use DNSSEC digital
+   signatures covering requests and data to secure updates and restrict
+   updates to those authorized to perform them as indicated by the
+   updater's possession of cryptographic keys.
+
+Acknowledgements
+
+   The contributions of the following persons (who are listed in
+   alphabetic order) to this memo are gratefully acknowledged:
+
+         Olafur Gudmundsson (ogud@tis.com>
+         Charlie Kaufman <Charlie_Kaufman@iris.com>
+         Stuart Kwan <skwan@microsoft.com>
+         Edward Lewis <lewis@tis.com>
+
+Table of Contents
+
+      1. Introduction............................................2
+      1.1 Overview of DNS Dynamic Update.........................2
+      1.2 Overview of DNS Security...............................2
+      2. Two Basic Modes.........................................3
+      3. Keys....................................................5
+      3.1 Update Keys............................................6
+      3.1.1 Update Key Name Scope................................6
+      3.1.2 Update Key Class Scope...............................6
+      3.1.3 Update Key Signatory Field...........................6
+
+
+
+Eastlake                    Standards Track                     [Page 1]
+
+RFC 2137                         SDNSDU                       April 1997
+
+
+      3.2 Zone Keys and Update Modes.............................8
+      3.3 Wildcard Key Punch Through.............................9
+      4. Update Signatures.......................................9
+      4.1 Update Request Signatures..............................9
+      4.2 Update Data Signatures................................10
+      5. Security Considerations................................10
+      References................................................10
+      Author's Address..........................................11
+
+1. Introduction
+
+   Dynamic update operations have been defined for the Domain Name
+   System (DNS) in RFC 2136, but without a detailed description of
+   security for those updates.  Means of securing the DNS and using it
+   for key distribution have been defined in RFC 2065.
+
+   This memo proposes techniques based on the defined DNS security
+   mechanisms to authenticate DNS updates.
+
+   Familiarity with the DNS system [RFC 1034, 1035] is assumed.
+   Familiarity with the DNS security and dynamic update proposals will
+   be helpful.
+
+1.1 Overview of DNS Dynamic Update
+
+   DNS dynamic update defines a new DNS opcode, new DNS request and
+   response structure if that opcode is used, and new error codes.  An
+   update can specify complex combinations of deletion and insertion
+   (with or without pre-existence testing) of resource records (RRs)
+   with one or more owner names; however, all testing and changes for
+   any particular DNS update request are restricted to a single zone.
+   Updates occur at the primary server for a zone.
+
+   The primary server for a secure dynamic zone must increment the zone
+   SOA serial number when an update occurs or the next time the SOA is
+   retrieved if one or more updates have occurred since the previous SOA
+   retrieval and the updates themselves did not update the SOA.
+
+1.2 Overview of DNS Security
+
+   DNS security authenticates data in the DNS by also storing digital
+   signatures in the DNS as SIG resource records (RRs).  A SIG RR
+   provides a digital signature on the set of all RRs with the same
+   owner name and class as the SIG and whose type is the type covered by
+   the SIG.  The SIG RR cryptographically binds the covered RR set to
+   the signer, time signed, signature expiration date, etc.  There are
+   one or more keys associated with every secure zone and all data in
+   the secure zone is signed either by a zone key or by a dynamic update
+
+
+
+Eastlake                    Standards Track                     [Page 2]
+
+RFC 2137                         SDNSDU                       April 1997
+
+
+   key tracing its authority to a zone key.
+
+   DNS security also defines transaction SIGs and request SIGs.
+   Transaction SIGs appear at the end of a response.  Transaction SIGs
+   authenticate the response and bind it to the corresponding request
+   with the key of the host where the responding DNS server is.  Request
+   SIGs appear at the end of a request and authenticate the request with
+   the key of the submitting entity.
+
+   Request SIGs are the primary means of authenticating update requests.
+
+   DNS security also permits the storage of public keys in the DNS via
+   KEY RRs.  These KEY RRs are also, of course, authenticated by SIG
+   RRs.  KEY RRs for zones are stored in their superzone and subzone
+   servers, if any, so that the secure DNS tree of zones can be
+   traversed by a security aware resolver.
+
+2. Two Basic Modes
+
+   A dynamic secure zone is any secure DNS zone containing one or more
+   KEY RRs that can authorize dynamic updates, i.e., entity or user KEY
+   RRs with the signatory field non-zero, and whose zone KEY RR
+   signatory field indicates that updates are implemented. There are two
+   basic modes of dynamic secure zone which relate to the update
+   strategy, mode A and mode B.  A summary comparison table is given
+   below and then each mode is described.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake                    Standards Track                     [Page 3]
+
+RFC 2137                         SDNSDU                       April 1997
+
+
+                   SUMMARY OF DYNAMIC SECURE ZONE MODES
+
+   CRITERIA:                |   MODE A           |   MODE B
+   =========================+====================+===================
+   Definition:              | Zone Key Off line  | Zone Key On line
+   =========================+====================+===================
+   Server Workload          |   Low              |   High
+   -------------------------+--------------------+-------------------
+   Static Data Security     |   Very High        |   Medium-High
+   -------------------------+--------------------+-------------------
+   Dynamic Data Security    |   Medium           |   Medium-High
+   -------------------------+--------------------+-------------------
+   Key Restrictions         |   Fine grain       |   Coarse grain
+   -------------------------+--------------------+-------------------
+   Dynamic Data Temporality |   Transient        |   Permanent
+   -------------------------+--------------------+-------------------
+   Dynamic Key Rollover     |   No               |   Yes
+   -------------------------+--------------------+-------------------
+
+   For mode A, the zone owner key and static zone master file are always
+   kept off-line for maximum security of the static zone contents.
+
+   As a consequence, any dynamicly added or changed RRs are signed in
+   the secure zone by their authorizing dynamic update key and they are
+   backed up, along with this SIG RR, in a separate online dynamic
+   master file.  In this type of zone, server computation is minimized
+   since the server need only check signatures on the update data and
+   request, which have already been signed by the updater, generally a
+   much faster operation than signing data.  However, the AXFR SIG and
+   NXT RRs which covers the zone under the zone key will not cover
+   dynamically added data.  Thus, for type A dynamic secure zones, zone
+   transfer security is not automatically provided for dynamically added
+   RRs, where they could be omitted, and authentication is not provided
+   for the server denial of the existence of a dynamically added type.
+   Because the dynamicly added RRs retain their update KEY signed SIG,
+   finer grained control of updates can be implemented via bits in the
+   KEY RR signatory field.  Because dynamic data is only stored in the
+   online dynamic master file and only authenticated by dynamic keys
+   which expire, updates are transient in nature.  Key rollover for an
+   entity that can authorize dynamic updates is more cumbersome since
+   the authority of their key must be traceable to a zone key and so, in
+   general, they must securely communicate a new key to the zone
+   authority for manual transfer to the off line static master file.
+   NOTE: for this mode the zone SOA must be signed by a dynamic update
+   key and that private key must be kept on line so that the SOA can be
+   changed for updates.
+
+
+
+
+
+Eastlake                    Standards Track                     [Page 4]
+
+RFC 2137                         SDNSDU                       April 1997
+
+
+   For mode B, the zone owner key and master file are kept on-line at
+   the zone primary server. When authenticated updates succeed, SIGs
+   under the zone key for the resulting data (including the possible NXT
+   type bit map changes) are calculated and these SIG (and possible NXT)
+   changes are entered into the zone and the unified on-line master
+   file.  (The zone transfer AXFR SIG may be recalculated for each
+   update or on demand when a zone transfer is requested and it is out
+   of date.)
+
+   As a consequence, this mode requires considerably more computational
+   effort on the part of the server as the public/private keys are
+   generally arranged so that signing (calculating a SIG) is more effort
+   than verifying a signature.  The security of static data in the zone
+   is decreased because the ultimate state of the static data being
+   served and the ultimate zone authority private key are all on-line on
+   the net.  This means that if the primary server is subverted, false
+   data could be authenticated to secondaries and other
+   servers/resolvers.  On the other hand, this mode of operation means
+   that data added dynamically is more secure than in mode A.  Dynamic
+   data will be covered by the AXFR SIG and thus always protected during
+   zone transfers and will be included in NXT RRs so that it can be
+   falsely denied by a server only to the same extent that static data
+   can (i.e., if it is within a wild card scope). Because the zone key
+   is used to sign all the zone data, the information as to who
+   originated the current state of dynamic RR sets is lost, making
+   unavailable the effects of some of the update control bits in the KEY
+   RR signatory field.  In addition, the incorporation of the updates
+   into the primary master file and their authentication by the zone key
+   makes then permanent in nature.  Maintaining the zone key on-line
+   also means that dynamic update keys which are signed by the zone key
+   can be dynamically updated since the zone key is available to
+   dynamically sign new values.
+
+   NOTE:  The Mode A / Mode B distinction only effects the validation
+   and performance of update requests.  It has no effect on retrievals.
+   One reasonable operational scheme may be to keep a mostly static main
+   zone operating in Mode A and have one or more dynamic subzones
+   operating in Mode B.
+
+3. Keys
+
+   Dynamic update requests depend on update keys as described in section
+   3.1 below.  In addition, the zone secure dynamic update mode and
+   availability of some options is indicated in the zone key.  Finally,
+   a special rule is used in searching for KEYs to validate updates as
+   described in section 3.3.
+
+
+
+
+
+Eastlake                    Standards Track                     [Page 5]
+
+RFC 2137                         SDNSDU                       April 1997
+
+
+3.1 Update Keys
+
+   All update requests to a secure zone must include signatures by one
+   or more key(s) that together can authorize that update.  In order for
+   the Domain Name System (DNS) server receiving the request to confirm
+   this, the key or keys must be available to and authenticated by that
+   server as a specially flagged KEY Resource Record.
+
+   The scope of authority of such keys is indicated by their KEY RR
+   owner name, class, and signatory field flags as described below. In
+   addition, such KEY RRs must be entity or user keys and not have the
+   authentication use prohibited bit on.  All parts of the actual update
+   must be within the scope of at least one of the keys used for a
+   request SIG on the update request as described in section 4.
+
+3.1.1 Update Key Name Scope
+
+   The owner name of any update authorizing KEY RR must (1) be the same
+   as the owner name of any RRs being added or deleted or (2) a wildcard
+   name including within its extended scope (see section 3.3) the name
+   of any RRs being added or deleted and those RRs must be in the same
+   zone.
+
+3.1.2 Update Key Class Scope
+
+   The class of any update authorizing KEY RR must be the same as the
+   class of any RR's being added or deleted.
+
+3.1.3 Update Key Signatory Field
+
+   The four bit "signatory field" (see RFC 2065) of any update
+   authorizing KEY RR must be non-zero.  The bits have the meanings
+   described below for non-zone keys (see section 3.2 for zone type
+   keys).
+
+                    UPDATE KEY RR SIGNATORY FIELD BITS
+
+         0           1           2           3
+   +-----------+-----------+-----------+-----------+
+   |   zone    |  strong   |  unique   |  general  |
+   +-----------+-----------+-----------+-----------+
+
+   Bit 0, zone control - If nonzero, this key is authorized to attach,
+        detach, and move zones by creating and deleting NS, glue A, and
+        zone KEY RR(s).  If zero, the key can not authorize any update
+        that would effect such RRs.  This bit is meaningful for both
+        type A and type B dynamic secure zones.
+
+
+
+
+Eastlake                    Standards Track                     [Page 6]
+
+RFC 2137                         SDNSDU                       April 1997
+
+
+        NOTE:  do not confuse the "zone" signatory field bit with the
+        "zone" key type bit.
+
+   Bit 1, strong update - If nonzero, this key is authorized to add and
+        delete RRs even if there are other RRs with the same owner name
+        and class that are authenticated by a SIG signed with a
+        different dynamic update KEY. If zero, the key can only
+        authorize updates where any existing RRs of the same owner and
+        class are authenticated by a SIG using the same key.  This bit
+        is meaningful only for type A dynamic zones and is ignored in
+        type B dynamic zones.
+
+        Keeping this bit zero on multiple KEY RRs with the same or
+        nested wild card owner names permits multiple entities to exist
+        that can create and delete names but can not effect RRs with
+        different owner names from any they created.  In effect, this
+        creates two levels of dynamic update key, strong and weak, where
+        weak keys are limited in interfering with each other but a
+        strong key can interfere with any weak keys or other strong
+        keys.
+
+   Bit 2, unique name update - If nonzero, this key is authorized to add
+        and update RRs for only a single owner name.  If there already
+        exist RRs with one or more names signed by this key, they may be
+        updated but no new name created until the number of existing
+        names is reduced to zero.  This bit is meaningful only for mode
+        A dynamic zones and is ignored in mode B dynamic zones. This bit
+        is meaningful only if the owner name is a wildcard.  (Any
+        dynamic update KEY with a non-wildcard name is, in effect, a
+        unique name update key.)
+
+        This bit can be used to restrict a KEY from flooding a zone with
+        new names.  In conjunction with a local administratively imposed
+        limit on the number of dynamic RRs with a particular name, it
+        can completely restrict a KEY from flooding a zone with RRs.
+
+   Bit 3, general update - The general update signatory field bit has no
+        special meaning.  If the other three bits are all zero, it must
+        be one so that the field is non-zero to designate that the key
+        is an update key.  The meaning of all values of the signatory
+        field with the general bit and one or more other signatory field
+        bits on is reserved.
+
+   All the signatory bit update authorizations described above only
+   apply if the update is within the name and class scope as per
+   sections 3.1.1 and 3.1.2.
+
+
+
+
+
+Eastlake                    Standards Track                     [Page 7]
+
+RFC 2137                         SDNSDU                       April 1997
+
+
+3.2 Zone Keys and Update Modes
+
+   Zone type keys are automatically authorized to sign anything in their
+   zone, of course, regardless of the value of their signatory field.
+   For zone keys, the signatory field bits have different means than
+   they they do for update keys, as shown below.  The signatory field
+   MUST be zero if dynamic update is not supported for a zone and MUST
+   be non-zero if it is.
+
+                     ZONE KEY RR SIGNATORY FIELD BITS
+
+                  0           1           2           3
+            +-----------+-----------+-----------+-----------+
+            |   mode    |  strong   |  unique   |  general  |
+            +-----------+-----------+-----------+-----------+
+
+   Bit 0, mode - This bit indicates the update mode for this zone.  Zero
+        indicates mode A while a one indicates mode B.
+
+   Bit 1, strong update - If nonzero, this indicates that the "strong"
+        key feature described in section 3.1.3 above is implemented and
+        enabled for this secure zone.  If zero, the feature is not
+        available.  Has no effect if the zone is a mode B secure update
+        zone.
+
+   Bit 2, unique name update - If nonzero, this indicates that the
+        "unique name" feature described in section 3.1.3 above is
+        implemented and enabled for this secure zone.  If zero, this
+        feature is not available.  Has no effect if the zone is a mode B
+        secure update zone.
+
+   Bit 3, general - This bit has no special meeting.  If dynamic update
+        for a zone is supported and the other bits in the zone key
+        signatory field are zero, it must be a one.  The meaning of zone
+        keys where the signatory field has the general bit and one or
+        more other bits on is reserved.
+
+   If there are multiple dynamic update KEY RRs for a zone and zone
+   policy is in transition, they might have different non-zero signatory
+   fields.  In that case, strong and unique name restrictions must be
+   enforced as long as there is a non-expired zone key being advertised
+   that indicates mode A with the strong or unique name bit on
+   respectively.  Mode B updates MUST be supported as long as there is a
+   non-expired zone key that indicates mode B.  Mode A updates may be
+   treated as mode B updates at server option if non-expired zone keys
+   indicate that both are supported.
+
+
+
+
+
+Eastlake                    Standards Track                     [Page 8]
+
+RFC 2137                         SDNSDU                       April 1997
+
+
+   A server that will be executing update operations on a zone, that is,
+   the primary master server, MUST not advertize a zone key that will
+   attract requests for a mode or features that it can not support.
+
+3.3 Wildcard Key Punch Through
+
+   Just as a zone key is valid throughout the entire zone, update keys
+   with wildcard names are valid throughout their extended scope, within
+   the zone. That is, they remain valid for any name that would match
+   them, even existing specific names within their apparent scope.
+
+   If this were not so, then whenever a name within a wildcard scope was
+   created by dynamic update, it would be necessary to first create a
+   copy of the KEY RR with this name, because otherwise the existence of
+   the more specific name would hide the authorizing KEY RR and would
+   make later updates impossible.  An updater could create such a KEY RR
+   but could not zone sign it with their authorizing signer.  They would
+   have to sign it with the same key using the wildcard name as signer.
+   Thus in creating, for example, one hundred type A RRs authorized by a
+   *.1.1.1.in-addr.arpa. KEY RR, without key punch through 100 As, 100
+   KEYs, and 200 SIGs would have to be created as opposed to merely 100
+   As and 100 SIGs with key punch through.
+
+4. Update Signatures
+
+   Two kinds of signatures can appear in updates.  Request signatures,
+   which are always required, cover the entire request and authenticate
+   the DNS header, including opcode, counts, etc., as well as the data.
+   Data signatures, on the other hand, appear only among the RRs to be
+   added and are only required for mode A operation.  These two types of
+   signatures are described further below.
+
+4.1 Update Request Signatures
+
+   An update can effect multiple owner names in a zone.  It may be that
+   these different names are covered by different dynamic update keys.
+   For every owner name effected, the updater must know a private key
+   valid for that name (and the zone's class) and must prove this by
+   appending request SIG RRs under each such key.
+
+   As specified in RFC 2065, a request signature is a SIG RR occurring
+   at the end of a request with a type covered field of zero.  For an
+   update, request signatures occur in the Additional information
+   section.  Each request SIG signs the entire request, including DNS
+   header, but excluding any other request SIG(s) and with the ARCOUNT
+   in the DNS header set to what it wold be without the request SIGs.
+
+
+
+
+
+Eastlake                    Standards Track                     [Page 9]
+
+RFC 2137                         SDNSDU                       April 1997
+
+
+4.2 Update Data Signatures
+
+   Mode A dynamic secure zones require that the update requester provide
+   SIG RRs that will authenticate the after update state of all RR sets
+   that are changed by the update and are non-empty after the update.
+   These SIG RRs appear in the request as RRs to be added and the
+   request must delete any previous data SIG RRs that are invalidated by
+   the request.
+
+   In Mode B dynamic secure zones, all zone data is authenticated by
+   zone key SIG RRs.  In this case, data signatures need not be included
+   with the update.  A resolver can determine which mode an updatable
+   secure zone is using by examining the signatory field bits of the
+   zone KEY RR (see section 3.2).
+
+5. Security Considerations
+
+   Any zone permitting dynamic updates is inherently less secure than a
+   static secure zone maintained off line as recommended in RFC 2065. If
+   nothing else, secure dynamic update requires on line change to and
+   re-signing of the zone SOA resource record (RR) to increase the SOA
+   serial number.  This means that compromise of the primary server host
+   could lead to arbitrary serial number changes.
+
+   Isolation of dynamic RRs to separate zones from those holding most
+   static RRs can limit the damage that could occur from breach of a
+   dynamic zone's security.
+
+References
+
+   [RFC2065] Eastlake, D., and C. Kaufman, "Domain Name System Security
+   Extensions", RFC 2065, CyberCash, Iris, January 1997.
+
+   [RFC2136] Vixie, P., Editor, Thomson, T., Rekhter, Y., and J. Bound,
+   "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136,
+   April 1997.
+
+   [RFC1035] Mockapetris, P., "Domain Names - Implementation and
+   Specifications", STD 13, RFC 1035, November 1987.
+
+   [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
+   STD 13, RFC 1034, November 1987.
+
+
+
+
+
+
+
+
+
+Eastlake                    Standards Track                    [Page 10]
+
+RFC 2137                         SDNSDU                       April 1997
+
+
+Author's Address
+
+   Donald E. Eastlake, 3rd
+   CyberCash, Inc.
+   318 Acton Street
+   Carlisle, MA 01741 USA
+
+   Phone:   +1 508-287-4877
+            +1 508-371-7148 (fax)
+            +1 703-620-4200 (main office, Reston, Virginia, USA)
+   EMail:   dee@cybercash.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake                    Standards Track                    [Page 11]
+
diff --git a/doc/rfc/rfc2163.txt b/doc/rfc/rfc2163.txt
new file mode 100644
index 0000000..00fcee7
--- /dev/null
+++ b/doc/rfc/rfc2163.txt
@@ -0,0 +1,1459 @@
+
+
+
+
+
+
+Network Working Group                                       C. Allocchio
+Request for Comments: 2163                                    GARR-Italy
+Obsoletes: 1664                                             January 1998
+Category: Standards Track
+
+
+                  Using the Internet DNS to Distribute
+            MIXER Conformant Global Address Mapping (MCGAM)
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (1998).  All Rights Reserved.
+
+Abstract
+
+   This memo is the complete technical specification to store in the
+   Internet Domain Name System (DNS) the mapping information (MCGAM)
+   needed by MIXER conformant e-mail gateways and other tools to map
+   RFC822 domain names into X.400 O/R names and vice versa.  Mapping
+   information can be managed in a distributed rather than a centralised
+   way. Organizations can publish their MIXER mapping or preferred
+   gateway routing information using just local resources (their local
+   DNS server), avoiding the need for a strong coordination with any
+   centralised organization. MIXER conformant gateways and tools located
+   on Internet hosts can retrieve the mapping information querying the
+   DNS instead of having fixed tables which need to be centrally updated
+   and distributed.
+
+   This memo obsoletes RFC1664. It includes the changes introduced by
+   MIXER specification with respect to RFC1327: the new 'gate1' (O/R
+   addresses to domain) table is fully supported. Full backward
+   compatibility with RFC1664 specification is mantained, too.
+
+   RFC1664 was a joint effort of IETF X400 operation working group
+   (x400ops) and TERENA (formely named "RARE") Mail and Messaging
+   working group (WG-MSG). This update was performed by the IETF MIXER
+   working group.
+
+
+
+
+
+
+Allocchio                   Standards Track                     [Page 1]
+
+RFC 2163                      MIXER MCGAM                   January 1998
+
+
+1. Introduction
+
+   The connectivity between the Internet SMTP mail and other mail
+   services, including the Internet X.400 mail and the commercial X.400
+   service providers, is assured by the Mail eXchanger (MX) record
+   information distributed via the Internet Domain Name System (DNS). A
+   number of documents then specify in details how to convert or encode
+   addresses from/to RFC822 style to the other mail system syntax.
+   However, only conversion methods provide, via some algorithm or a set
+   of mapping rules, a smooth translation, resulting in addresses
+   indistinguishable from the native ones in both RFC822 and foreign
+   world.
+
+   MIXER describes a set of mappings (MIXER Conformant Global Address
+   Mapping - MCGAM) which will enable interworking between systems
+   operating the CCITT X.400 (1984/88/92) Recommendations and systems
+   using using the RFC822 mail protocol, or protocols derived from
+   RFC822. That document addresses conversion of services, addresses,
+   message envelopes, and message bodies between the two mail systems.
+   This document is concerned with one aspect of MIXER: the mechanism
+   for mapping between X.400 O/R addresses and RFC822 domain names. As
+   described in Appendix F of MIXER, implementation of the mappings
+   requires a database which maps between X.400 O/R addresses and domain
+   names; in RFC1327 this database was statically defined.
+
+   The original approach in RFC1327 required many efforts to maintain
+   the correct mapping: all the gateways needed to get coherent tables
+   to apply the same mappings, the conversion tables had to be
+   distributed among all the operational gateways, and also every update
+   needed to be distributed.
+
+   The concept of mapping rules distribution and use has been revised in
+   the new MIXER specification, introducing the concept of MIXER
+   Conformant Global Address Mapping (MCGAM). A MCGAM does not need to
+   be globally installed by any MIXER conformant gateway in the world
+   any more. However MIXER requires now efficient methods to publish its
+   MCGAM.
+
+   Static tables are one of the possible methods to publish MCGAM.
+   However this static mechanism requires quite a long time to be spent
+   modifying and distributing the information, putting heavy constraints
+   on the time schedule of every update.  In fact it does not appear
+   efficient compared to the Internet Domain Name Service (DNS).  More
+   over it does not look feasible to distribute the database to a large
+   number of other useful applications, like local address converters,
+   e-mail User Agents or any other tool requiring the mapping rules to
+   produce correct results.
+
+
+
+
+Allocchio                   Standards Track                     [Page 2]
+
+RFC 2163                      MIXER MCGAM                   January 1998
+
+
+   Two much more efficient methods are proposed by MIXER for publication
+   of MCGAM: the Internet DNS and X.500. This memo is the complete
+   technical specification for publishing MCGAM via Internet DNS.
+
+   A first proposal to use the Internet DNS to store, retrieve and
+   maintain those mappings was introduced by two of the authors of
+   RFC1664 (B. Cole and R. Hagens) adopting two new DNS resource record
+   (RR)  types: TO-X400 and TO-822. This proposal now adopts a more
+   complete strategy, and requires one new RR only. The distribution of
+   MCGAMs via DNS is in fact an important service for the whole Internet
+   community: it completes the information given by MX resource record
+   and it allows to produce clean addresses when messages are exchanged
+   among the Internet RFC822 world and the X.400 one (both Internet and
+   Public X.400 service providers).
+
+   A first experiment in using the DNS without expanding the current set
+   of RR and using available ones was deployed by some of the authors of
+   RFC1664 at the time of its development. The existing PTR resource
+   records were used to store the mapping rules, and a new DNS tree was
+   created under the ".it" top level domain. The result of the
+   experiment was positive, and a few test applications ran under this
+   provisional set up. This test was also very useful in order to define
+   a possible migration strategy during the deployment of the new DNS
+   containing the new RR. The Internet DNS nameservers wishing to
+   provide this mapping information need in fact to be modified to
+   support the new RR type, and in the real Internet, due to the large
+   number of different implementations, this takes some time.
+
+   The basic idea is to adopt a new DNS RR to store the mapping
+   information. The RFC822 to X.400 mapping rules (including the so
+   called 'gate2' rules) will be stored in the ordinary DNS tree, while
+   the definition of a new branch of the name space defined under each
+   national top level domain is envisaged in order to contain the X.400
+   to RFC822 mappings ('table1' and 'gate1'). A "two-way" mapping
+   resolution schema is thus fully implemented.
+
+   The creation of the new domain name space representing the X.400 O/R
+   names structure also provides the chance to use the DNS to distribute
+   dynamically other X.400 related information, thus solving other
+   efficiency problems currently affecting the X.400 MHS service.
+
+   In this paper we will adopt the MCGAM syntax, showing how it can be
+   stored into the Internet DNS.
+
+
+
+
+
+
+
+
+Allocchio                   Standards Track                     [Page 3]
+
+RFC 2163                      MIXER MCGAM                   January 1998
+
+
+1.1 Definitions syntax
+
+   The definitions in this document is given in BNF-like syntax, using
+   the following conventions:
+
+      |   means choice
+      \   is used for continuation of a definition over several lines
+      []  means optional
+      {}  means repeated one or more times
+
+   The definitions, however, are detailed only until a certain level,
+   and below it self-explaining character text strings will be used.
+
+2. Motivation
+
+   Implementations of MIXER gateways require that a database store
+   address mapping information for X.400 and RFC822. This information
+   must be made available (published) to all MIXER gateways. In the
+   Internet community, the DNS has proven to be a practical mean for
+   providing a distributed name service. Advantages of using a DNS based
+   system over a table based approach for mapping between O/R addresses
+   and domain names are:
+
+     - It avoids fetching and storing of entire mapping tables by every
+       host that wishes to implement MIXER gateways and/or tools
+
+     - Modifications to the DNS based mapping information can be made
+       available in a more timely manner than with a table driven
+       approach.
+
+     - It allows full authority delegation, in agreement with the
+       Internet regionalization process.
+
+     - Table management is not necessarily required for DNS-based
+       MIXER gateways.
+
+     - One can determine the mappings in use by a remote gateway by
+       querying the DNS (remote debugging).
+
+   Also many other tools, like address converters and User Agents can
+   take advantage of the real-time availability of MIXER tables,
+   allowing a much easier maintenance of the information.
+
+3. The domain space for X.400 O/R name addresses
+
+   Usual domain names (the ones normally used as the global part of an
+   RFC822 e-mail address) and their associated information, i.e., host
+   IP addresses, mail exchanger names, etc., are stored in the DNS as a
+
+
+
+Allocchio                   Standards Track                     [Page 4]
+
+RFC 2163                      MIXER MCGAM                   January 1998
+
+
+   distributed database under a number of top-level domains. Some top-
+   level domains are used for traditional categories or international
+   organisations (EDU, COM, NET, ORG, INT, MIL...). On the other hand
+   any country has its own two letter ISO country code as top-level
+   domain (FR, DE, GB, IT, RU, ...), including "US" for USA.  The
+   special top-level/second-level couple IN-ADDR.ARPA is used to store
+   the IP address to domain name relationship. This memo defines in the
+   above structure the appropriate way to locate the X.400 O/R name
+   space, thus enabling to store in DNS the MIXER mappings (MCGAMs).
+
+   The MIXER mapping information is composed by four tables:
+
+    - 'table1' and 'gate1' gives the translation from X.400 to RFC822;
+    - 'table2' and 'gate2' tables map RFC822 into X.400.
+
+   Each mapping table is composed by mapping rules, and a single mapping
+   rule is composed by a keyword (the argument of the mapping function
+   derived from the address to be translated) and a translator (the
+   mapping function parameter):
+
+                            keyword#translator#
+
+   the '#' sign is a delimiter enclosing the translator. An example:
+
+                 foo.bar.us#PRMD$foo\.bar.ADMD$intx.C$us#
+
+   Local mappings are not intended for use outside their restricted
+   environment, thus they should not be included in DNS. If local
+   mappings are used, they should be stored using static local tables,
+   exactly as local static host tables can be used with DNS.
+
+   The keyword of a 'table2' and 'gate2' table entry is a valid RFC822
+   domain; thus the usual domain name space can be used without problems
+   to store these entries.
+   On the other hand, the keyword of a 'table1' and 'gate1' entry
+   belongs to the X.400 O/R name space. The X.400 O/R name space does
+   not usually fit into the usual domain name space, although there are
+   a number of similarities; a new name structure is thus needed to
+   represent it. This new name structure contains the X.400 mail
+   domains.
+
+   To ensure the correct functioning of the DNS system, the new X.400
+   name structure must be hooked to the existing domain name space in a
+   way which respects the existing name hierarchy.
+
+   A possible solution was to create another special branch, starting
+   from the root of the DNS tree, somehow similar to the in-addr.arpa
+   tree. This idea would have required to establish a central authority
+
+
+
+Allocchio                   Standards Track                     [Page 5]
+
+RFC 2163                      MIXER MCGAM                   January 1998
+
+
+   to coordinate at international level the management of each national
+   X.400 name tree, including the X.400 public service providers. This
+   coordination problem is a heavy burden if approached globally. More
+   over the X.400 name structure is very 'country oriented': thus while
+   it requires a coordination at national level, it does not have
+   concepts like the international root. In fact the X.400 international
+   service is based  on a large number of bilateral agreements, and only
+   within some communities an international coordination service exists.
+
+   The X.400 two letter ISO country codes, however, are the same used
+   for the RFC822 country top-level domains and this gives us an
+   appropriate hook to insert the new branches. The proposal is, in
+   fact, to create under each national top level ISO country code a new
+   branch in the name space. This branch represents exactly the X.400
+   O/R name structure as defined in each single country, following the
+   ADMD, PRMD, O, OU hierarchy. A unique reserved label 'X42D' is placed
+   under each country top-level domain, and hence the national X.400
+   name space derives its own structure:
+
+                                    . (root)
+                                    |
+      +-----------------+-----------+--------+-----------------+...
+      |                 |                    |                 |
+     edu                it                   us                fr
+      |                 |                    |                 |
+  +---+---+...    +-----+-----+...     +-----+-----+...     +--+---+...
+  |       |       |     |     |        |     |     |        |      |
+ ...     ...     cnr   X42D  infn      va    ca   X42D     X42D  inria
+                        |                    |     |        |
+           +------------+------------+...   ...   ...  +----+-------+...
+           |            |            |                 |            |
+    ADMD-PtPostel  ADMD-garr  ADMD-Master400        ADMD-atlas  ADMD-red
+                        |            |                 |            |
+             +----------+----+...   ...        +-------+------+... ...
+             |               |                 |              |
+         PRMD-infn       PRMD-STET        PRMD-Telecom   PRMD-Renault
+             |               |                 |              |
+            ...             ...               ...            ...
+
+
+   The creation of the X.400 new name tree at national level solves the
+   problem of the international coordination. Actually the coordination
+   problem is just moved at national level, but it thus becomes easier
+   to solve. The coordination at national level between the X.400
+   communities and the Internet world is already a requirement for the
+   creation of the national static MIXER mapping tables; the use of the
+   Internet DNS gives further motivations for this coordination.
+
+
+
+
+Allocchio                   Standards Track                     [Page 6]
+
+RFC 2163                      MIXER MCGAM                   January 1998
+
+
+   The coordination at national level also fits in the new concept of
+   MCGAM pubblication. The DNS in fact allows a step by step authority
+   distribution, up to a final complete delegation: thus organizations
+   whishing to publish their MCGAM just need to receive delegation also
+   for their branch of the new X.400 name space. A further advantage of
+   the national based solution is to allow each country to set up its
+   own X.400 name structure in DNS and to deploy its own authority
+   delegation according to its local time scale and requirements, with
+   no loss of global service in the mean time. And last, placing the new
+   X.400 name tree and coordination process at national level fits into
+   the Internet regionalization and internationalisation process, as it
+   requires local bodies to take care of local coordination problems.
+
+   The DNS name space thus contains completely the information required
+   by an e-mail gateway or tool to perform the X.400-RFC822 mapping: a
+   simple query to the nearest nameserver provides it. Moreover there is
+   no more any need to store, maintain and distribute manually any
+   mapping table. The new X.400 name space can also contain further
+   information about the X.400 community, as DNS allows for it a
+   complete set of resource records, and thus it allows further
+   developments. This set of RRs in the new X.400 name space must be
+   considered 'reserved' and thus not used until further specifications.
+
+   The construction of the new domain space trees will follow the same
+   procedures used when organising at first the already existing DNS
+   space: at first the information will be stored in a quite centralised
+   way, and distribution of authority will be gradually achieved. A
+   separate document will describe the implementation phase and the
+   methods to assure a smooth introduction of the new service.
+
+4. The new DNS resource record for MIXER mapping rules: PX
+
+   The specification of the Internet DNS (RFC1035) provides a number of
+   specific resource records (RRs) to contain specific pieces of
+   information. In particular they contain the Mail eXchanger (MX) RR
+   and the host Address (A) records which are used by the Internet SMTP
+   mailers. As we will store the RFC822 to X.400 mapping information in
+   the already existing DNS name tree, we need to define a new DNS RR in
+   order to avoid any possible clash or misuse of already existing data
+   structures. The same new RR will also be used to store the mappings
+   from X.400 to RFC822. More over the mapping information, i.e., the
+   MCGAMs, has a specific format and syntax which require an appropriate
+   data structure and processing. A further advantage of defining a new
+   RR is the ability to include flexibility for some eventual future
+   development.
+
+
+
+
+
+
+Allocchio                   Standards Track                     [Page 7]
+
+RFC 2163                      MIXER MCGAM                   January 1998
+
+
+   The definition of the new 'PX' DNS resource record is:
+
+      class:        IN   (Internet)
+
+      name:         PX   (pointer to X.400/RFC822 mapping information)
+
+      value:        26
+
+   The PX RDATA format is:
+
+          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+          |                  PREFERENCE                   |
+          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+          /                    MAP822                     /
+          /                                               /
+          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+          /                    MAPX400                    /
+          /                                               /
+          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+   where:
+
+   PREFERENCE   A 16 bit integer which specifies the preference given to
+                this RR among others at the same owner.  Lower values
+                are preferred;
+
+   MAP822       A <domain-name> element containing <rfc822-domain>, the
+                RFC822 part of the MCGAM;
+
+   MAPX400      A <domain-name> element containing the value of
+                <x400-in-domain-syntax> derived from the X.400 part of
+                the MCGAM (see sect. 4.2);
+
+   PX records cause no additional section processing. The PX RR format
+   is the usual one:
+
+             <name> [<class>] [<TTL>] <type> <RDATA>
+
+   When we store in DNS a 'table1' or a 'gate1' entry, then <name> will
+   be an X.400 mail domain name in DNS syntax (see sect. 4.2). When we
+   store a 'table2' or a 'gate2' table entry, <name> will be an RFC822
+   mail domain name, including both fully qualified DNS domains and mail
+   only domains (MX-only domains). All normal DNS conventions, like
+   default values, wildcards, abbreviations and message compression,
+   apply also for all the components of the PX RR. In particular <name>,
+   MAP822 and MAPX400, as <domain-name> elements, must have the final
+   "." (root) when they are fully qualified.
+
+
+
+
+Allocchio                   Standards Track                     [Page 8]
+
+RFC 2163                      MIXER MCGAM                   January 1998
+
+
+4.1 Additional features of the PX resource record
+
+   The definition of the RDATA for the PX resource record, and the fact
+   that DNS allows a distinction between an exact value and a wildcard
+   match for the <name> parameter, represent an extension of the MIXER
+   specification for mapping rules. In fact, any MCGAM entry is an
+   implicit wildcard entry, i.e., the rule
+
+      net2.it#PRMD$net2.ADMD$p400.C$it#
+
+   covers any RFC822 domain ending with 'net2.it', unless more detailed
+   rules for some subdomain in 'net2.it' are present. Thus there is no
+   possibility to specify explicitly a MCGAM as an exact match only
+   rule. In DNS an entry like
+
+      *.net2.it.   IN  PX  10   net2.it.  PRMD-net2.ADMD-p400.C-it.
+
+   specify the usual wildcard match as for MIXER tables. However an
+   entry like
+
+      ab.net2.it.  IN  PX  10   ab.net2.it.  O-ab.PRMD-net2.ADMDb.C-it.
+
+   is valid only for an exact match of 'ab.net2.it' RFC822 domain.
+
+   Note also that in DNS syntax there is no '#' delimiter around MAP822
+   and MAPX400 fields: the syntax defined in sect. 4.2 in fact does not
+   allow the <blank> (ASCII decimal 32) character within these fields,
+   making unneeded the use of an explicit delimiter as required in the
+   MIXER original syntax.
+
+   Another extension to the MIXER specifications is the PREFERENCE value
+   defined as part of the PX RDATA section. This numeric value has
+   exactly the same meaning than the similar one used for the MX RR. It
+   is thus possible to specify more than one single mapping for a domain
+   (both from RFC822 to X.400 and vice versa), giving as the preference
+   order. In MIXER static tables, however, you cannot specify more than
+   one mapping per each RFC822 domain, and the same restriction apply
+   for any X.400 domain mapping to an RFC822 one.
+
+   More over, in the X.400 recommendations a note suggests than an
+   ADMD=<blank> should be reserved for some special cases. Various
+   national functional profile specifications for an X.400 MHS states
+   that if an X.400 PRMD is reachable via any of its national ADMDs,
+   independently of its actual single or multiple connectivity with
+   them, it should use ADMD=<blank> to advertise this fact. Again, if a
+   PRMD has no connections to any ADMD it should use ADMD=0 to notify
+   its status, etc. However, in most of the current real situations, the
+   ADMD service providers do not accept messages coming from their
+
+
+
+Allocchio                   Standards Track                     [Page 9]
+
+RFC 2163                      MIXER MCGAM                   January 1998
+
+
+   subscribers if they have a blank ADMD, forcing them to have their own
+   ADMD value. In such a situation there are problems in indicating
+   properly the actually working mappings for domains with multiple
+   connectivity. The PX RDATA 'PREFERENCE' extension was introduced to
+   take in consideration these problems.
+
+   However, as these extensions are not available with MIXER static
+   tables, it is strongly discouraged to use them when interworking with
+   any table based gateway or application. The extensions were in fact
+   introduced just to add more flexibility, like the PREFERENCE value,
+    or they were already implicit in the DNS mechanism, like the
+   wildcard specification. They should be used very carefully or just
+   considered 'reserved for future use'. In particular, for current use,
+   the PREFERENCE value in the PX record specification should be fixed
+   to a value of 50, and only wildcard specifications should be used
+   when specifying <name> values.
+
+4.2 The DNS syntax for an X.400 'domain'
+
+   The syntax definition of the MCGAM rules is defined in appendix F of
+   that document. However that syntax is not very human oriented and
+   contains a number of characters which have a special meaning in other
+   fields of the Internet DNS. Thus in order to avoid any possible
+   problem, especially due to some old DNS implementations still being
+   used in the Internet, we define a syntax for the X.400 part of any
+   MCGAM rules (and hence for any X.400 O/R name) which makes it
+   compatible with a <domain-name> element, i.e.,
+
+   <domain-name>    ::= <subdomain> | " "
+   <subdomain>      ::= <label> | <label> "." <subdomain>
+   <label>          ::= <alphanum>|
+                        <alphanum> {<alphanumhyphen>} <alphanum>
+   <alphanum>       ::= "0".."9" | "A".."Z" | "a".."z"
+   <alphanumhyphen> ::= "0".."9" | "A".."Z" | "a".."z" | "-"
+
+   (see RFC1035, section 2.3.1, page 8).  The legal character set for
+   <label> does not correspond to the IA5 Printablestring one used in
+   MIXER to define MCGAM rules. However a very simple "escape mechanism"
+   can be applied in order to bypass the problem. We can in fact simply
+   describe the X.400 part of a MCGAM rule format as:
+
+     <map-rule>   ::= <map-elem> | <map-elem> { "." <map-elem> }
+     <map-elem>   ::= <attr-label> "$" <attr-value>
+     <attr-label> ::= "C" | "ADMD" | "PRMD" | "O" | "OU"
+     <attr-value> ::= " " | "@" | IA5-Printablestring
+
+
+
+
+
+
+Allocchio                   Standards Track                    [Page 10]
+
+RFC 2163                      MIXER MCGAM                   January 1998
+
+
+   As you can notice <domain-name> and <map-rule> look similar, and also
+   <label> and <map-elem> look the same. If we define the correct method
+   to transform a <map-elem> into a <label> and vice versa the problem
+   to write a MCGAM rule in <domain-name> syntax is solved.
+
+   The RFC822 domain part of any MCGAM rule is of course already in
+   <domain-name> syntax, and thus remains unchanged.
+
+   In particular, in a 'table1' or 'gate1' mapping rule the 'keyword'
+   value must be converted into <x400-in-domain-syntax> (X.400 mail DNS
+   mail domain), while the 'translator' value is already a valid RFC822
+   domain.  Vice versa in a 'table2' or 'gate2' mapping rule, the
+   'translator' must be converted into <x400-in-domain-syntax>, while
+   the 'keyword' is already a valid RFC822 domain.
+
+4.2.1 IA5-Printablestring to <alphanumhyphen> mappings
+
+   The problem of unmatching IA5-Printablestring and <label> character
+   set definition is solved by a simple character mapping rule: whenever
+   an IA5 character does not belong to <alphanumhyphen>, then it is
+   mapped using its 3 digit decimal ASCII code, enclosed in hyphens. A
+   small set of special rules is also defined for the most frequent
+   cases. Moreover some frequent characters combinations used in MIXER
+   rules are also mapped as special cases.
+
+   Let's then define the following simple rules:
+
+    MCGAM rule            DNS store translation    conditions
+    -----------------------------------------------------------------
+    <attr-label>$@        <attr-label>             missing attribute
+    <attr-label>$<blank>  <attr-label>"b"          blank attribute
+    <attr-label>$xxx      <attr-label>-xxx         elsewhere
+
+   Non <alphanumhyphen> characters in <attr-value>:
+
+    MCGAM rule            DNS store translation    conditions
+    -----------------------------------------------------------------
+    -                     -h-                      hyphen
+    \.                    -d-                      quoted dot
+    <blank>               -b-                      blank
+    <non A/N character>   -<3digit-decimal>-       elsewhere
+
+   If the DNS store translation of <attr-value> happens to end with an
+   hyphen, then this last hyphen is omitted.
+
+   Let's now have some examples:
+
+
+
+
+
+Allocchio                   Standards Track                    [Page 11]
+
+RFC 2163                      MIXER MCGAM                   January 1998
+
+
+    MCGAM rule            DNS store translation    conditions
+    -----------------------------------------------------------------
+    PRMD$@                PRMD                     missing attribute
+    ADMD$<blank>          ADMDb                    blank attribute
+    ADMD$400-net          ADMD-400-h-net           hyphen mapping
+    PRMD$UK\.BD           PRMD-UK-d-BD             quoted dot mapping
+    O$ACME Inc\.          O-ACME-b-Inc-d           blank & final hyphen
+    PRMD$main-400-a       PRMD-main-h-400-h-a      hyphen mapping
+    O$-123-b              O--h-123-h-b             hyphen mapping
+    OU$123-x              OU-123-h-x               hyphen mapping
+    PRMD$Adis+co          PRMD-Adis-043-co         3digit mapping
+
+   Thus, an X.400 part from a MCGAM like
+
+     OU$uuu.O$@.PRMD$ppp\.rrr.ADMD$aaa ddd-mmm.C$cc
+
+   translates to
+
+     OU-uuu.O.PRMD-ppp-d-rrr.ADMD-aaa-b-ddd-h-mmm.C-cc
+
+   Another example:
+
+     OU$sales dept\..O$@.PRMD$ACME.ADMD$ .C$GB
+
+   translates to
+
+     OU-sales-b-dept-d.O.PRMD-ACME.ADMDb.C-GB
+
+4.2.2 Flow chart
+
+   In order to achieve the proper DNS store translations of the X.400
+   part of a MCGAM or any other X.400 O/R name, some software tools will
+   be used. It is in fact evident that the above rules for converting
+   mapping table from MIXER to DNS format (and vice versa) are not user
+   friendly enough to think of a human made conversion.
+
+   To help in designing such tools, we describe hereunder a small flow
+   chart. The fundamental rule to be applied during translation is,
+   however, the following:
+
+      "A string must be parsed from left to right, moving appropriately
+      the pointer in order not to consider again the already translated
+      left section of the string in subsequent analysis."
+
+
+
+
+
+
+
+
+Allocchio                   Standards Track                    [Page 12]
+
+RFC 2163                      MIXER MCGAM                   January 1998
+
+
+   Flow chart 1 - Translation from MIXER to DNS format:
+
+                 parse  single attribute
+              (enclosed in "." separators)
+                           |
+            (yes)  ---  <label>$@ ?  ---  (no)
+              |                             |
+        map to <label>        (no)  <label>$<blank> ?  (yes)
+              |                 |                        |
+              |           map to <label>-        map to <label>"b"
+              |                 |                        |
+              |           map "\." to -d-                |
+              |                 |                        |
+              |           map "-" to -h-                 |
+              |                 |                        |
+              |    map non A/N char to -<3digit>-        |
+  restart     |                 |                        |
+     ^        |      remove (if any) last "-"            |
+     |        |                 |                        |
+     |        \------->     add a  "."    <--------------/
+     |                          |
+     \----------  take  next  attribute  (if  any)
+
+
+   Flow chart 2 - Translation from DNS to MIXER format:
+
+
+                parse single attribute
+            (enclosed in "." separators)
+                          |
+            (yes) ---- <label> ? ---- (no)
+              |                          |
+      map to <label>$@        (no) <label>"b" ? (yes)
+              |                 |                 |
+              |           map to <label>$    map to <label>$<blank>
+              |                 |                 |
+              |           map -d- to "\."         |
+              |                 |                 |
+              |           map -h- to "-"          |
+              |                 |                 |
+              |           map -b- to " "          |
+  restart     |                 |                 |
+     ^        |   map -<3digit>- to non A/N char  |
+     |        |                 |                 |
+     |        \-------->   add a "."   <----------/
+     |                         |
+     \------------- take next attribute (if any)
+
+
+
+
+Allocchio                   Standards Track                    [Page 13]
+
+RFC 2163                      MIXER MCGAM                   January 1998
+
+
+   Note that the above flow charts deal with the translation of the
+   attributes syntax, only.
+
+4.2.3 The Country Code convention in the <name> value.
+
+   The RFC822 domain space and the X.400 O/R address space, as said in
+   section 3, have one specific common feature: the X.400 ISO country
+   codes are the same as the RFC822 ISO top level domains for countries.
+   In the previous sections we have also defined a method to write in
+   <domain-name> syntax any X.400 domain, while in section 3 we
+   described the new name space starting at each country top level
+   domain under the X42D.cc (where 'cc' is then two letter ISO country
+   code).
+
+   The <name> value for a 'table1' or 'gate1' entry in DNS should thus
+   be derived from the X.400 domain value, translated to <domain-name>
+   syntax, adding the 'X42D.cc.' post-fix to it, i.e.,
+
+     ADMD$acme.C$fr
+
+   produces in <domain-name> syntax the key:
+
+     ADMD-acme.C-fr
+
+   which is post-fixed by 'X42D.fr.' resulting in:
+
+     ADMD-acme.C-fr.X42D.fr.
+
+   However, due to the identical encoding for X.400 country codes and
+   RFC822 country top level domains, the string 'C-fr.X42D.fr.' is
+   clearly redundant.
+
+   We thus define the 'Country Code convention' for the <name> key,
+   i.e.,
+
+     "The C-cc section of an X.400 domain in <domain-name> syntax must
+     be omitted when creating a <name> key, as it is identical to the
+     top level country code used to identify the DNS zone where the
+     information is stored".
+
+   Thus we obtain the following <name> key examples:
+
+   X.400 domain                       DNS <name> key
+   --------------------------------------------------------------------
+   ADMD$acme.C$fr                     ADMD-acme.X42D.fr.
+   PRMD$ux\.av.ADMD$ .C$gb            PRMD-ux-d-av.ADMDb.X42D.gb.
+   PRMD$ppb.ADMD$Dat 400.C$de         PRMD-ppb.ADMD-Dat-b-400.X42D.de.
+
+
+
+
+Allocchio                   Standards Track                    [Page 14]
+
+RFC 2163                      MIXER MCGAM                   January 1998
+
+
+4.3 Creating the appropriate DNS files
+
+   Using MIXER's assumption of an asymmetric mapping between X.400 and
+   RFC822 addresses, two separate relations are required to store the
+   mapping database: MIXER 'table1' and MIXER 'table2'; thus also in DNS
+   we will maintain the two different sections, even if they will both
+   use the PX resource record. More over MIXER also specify two
+   additional tables: MIXER 'gate1' and 'gate2' tables. These additional
+   tables, however, have the same syntax rules than MIXER 'table1' and
+   'table2' respectively, and thus the same translation procedure as
+   'table1' and 'table2' will be applied; some details about the MIXER
+   'gate1' and 'gate2' tables are discussed in section 4.4.
+
+   Let's now check how to create, from an MCGAM entry, the appropriate
+   DNS entry in a DNS data file. We can again define an MCGAM entry as
+   defined in appendix F of that document as:
+
+     <x400-domain>#<rfc822-domain>#  (case A: 'table1' and 'gate1'
+     entry)
+
+   and
+
+     <rfc822-domain>#<x400-domain>#  (case B: 'table2' and 'gate2'
+     entry)
+
+   The two cases must be considered separately. Let's consider case A.
+
+    - take <x400-domain> and translate it into <domain-name> syntax,
+     obtaining <x400-in-domain-syntax>;
+    - create the <name> key from <x400-in-domain-syntax> i.e., apply
+     the Country Code convention described in sect. 4.2.3;
+    - construct the DNS PX record as:
+
+      *.<name>  IN  PX  50  <rfc822-domain>  <x400-in-domain-syntax>
+
+   Please note that within PX RDATA the <rfc822-domain> precedes the
+   <x400-in-domain-syntax> also for a 'table1' and 'gate1' entry.
+
+   an example: from the 'table1' rule
+
+     PRMD$ab.ADMD$ac.C$fr#ab.fr#
+
+   we obtain
+
+     *.PRMD-ab.ADMD-ac.X42D.fr. IN PX 50  ab.fr.  PRMD-ab.ADMD-ac.C-fr.
+
+   Note that <name>, <rfc822-domain> and <x400-in-domain-syntax> are
+   fully qualified <domain-name> elements, thus ending with a ".".
+
+
+
+Allocchio                   Standards Track                    [Page 15]
+
+RFC 2163                      MIXER MCGAM                   January 1998
+
+
+   Let's now consider case B.
+
+    - take <rfc822-domain> as <name> key;
+    - translate <x400-domain> into <x400-in-domain-syntax>;
+    - construct the DNS PX record as:
+
+     *.<name>  IN  PX  50  <rfc822-domain>  <x400-in-domain-syntax>
+
+   an example: from the 'table2' rule
+
+     ab.fr#PRMD$ab.ADMD$ac.C$fr#
+
+   we obtain
+
+     *.ab.fr.  IN  PX  50  ab.fr.  PRMD-ab.ADMD-ac.C-fr.
+
+   Again note the fully qualified <domain-name> elements.
+
+   A file containing the MIXER mapping rules and MIXER 'gate1' and
+   'gate2' table written in DNS format will look like the following
+   fictious example:
+
+     !
+     ! MIXER table 1: X.400 --> RFC822
+     !
+     *.ADMD-acme.X42D.it.               IN  PX  50  it. ADMD-acme.C-it.
+     *.PRMD-accred.ADMD-tx400.X42D.it.  IN  PX  50   \
+                                accred.it. PRMD-accred.ADMD-tx400.C-it.
+     *.O-u-h-newcity.PRMD-x4net.ADMDb.X42D.it.  IN  PX  50   \
+                       cs.ncty.it. O-u-h-newcity.PRMD-x4net.ADMDb.C-it.
+     !
+     ! MIXER table 2: RFC822 --> X.400
+     !
+     *.nrc.it.    IN  PX  50   nrc.it. PRMD-nrc.ADMD-acme.C-it.
+     *.ninp.it.   IN  PX  50   ninp.it. O.PRMD-ninp.ADMD-acme.C-it.
+     *.bd.it.     IN  PX  50   bd.it. PRMD-uk-d-bd.ADMDb.C-it.
+     !
+     ! MIXER Gate 1 Table
+     !
+     *.ADMD-XKW-h-Mail.X42D.it.         IN  PX  50   \
+                            XKW-gateway.it. ADMD-XKW-h-Mail.C-it.G.
+     *.PRMD-Super-b-Inc.ADMDb.X42D.it.  IN  PX  50   \
+                            GlobalGw.it. PRMD-Super-b-Inc.ADMDb.C-it.G.
+     !
+     ! MIXER Gate 2 Table
+     !
+     my.it.  IN PX 50  my.it. OU-int-h-gw.O.PRMD-ninp.ADMD-acme.C-it.G.
+     co.it.  IN PX 50  co.it. O-mhs-h-relay.PRMD-x4net.ADMDb.C-it.G.
+
+
+
+Allocchio                   Standards Track                    [Page 16]
+
+RFC 2163                      MIXER MCGAM                   January 1998
+
+
+   (here the "\" indicates continuation on the same line, as wrapping is
+   done only due to typographical reasons).
+
+   Note the special suffix ".G." on the right side of the 'gate1' and
+   'gate2' Tables section whose aim is described in section 4.4. The
+   corresponding MIXER tables are:
+
+     #
+     # MIXER table 1: X.400 --> RFC822
+     #
+     ADMD$acme.C$it#it#
+     PRMD$accred.ADMD$tx400.C$it#accred.it#
+     O$u-newcity.PRMD$x4net.ADMD$ .C$it#cs.ncty.it#
+     #
+     # MIXER table 2: RFC822 --> X.400
+     #
+     nrc.it#PRMD$nrc.ADMD$acme.C$it#
+     ninp.it#O.PRMD$ninp.ADMD$acme.C$it#
+     bd.it#PRMD$uk\.bd.ADMD$ .C$it#
+     #
+     # MIXER Gate 1 Table
+     #
+     ADMD$XKW-Mail.C$it#XKW-gateway.it#
+     PRMD$Super Inc.ADMD$ .C$it#GlobalGw.it#
+     #
+     # MIXER Gate 2 Table
+     #
+     my.it#OU$int-gw.O$@.PRMD$ninp.ADMD$acme.C$it#
+     co.it#O$mhs-relay.PRMD$x4net.ADMD$ .C$t#
+
+4.4 Storing the MIXER 'gate1' and 'gate2' tables
+
+   Section 4.3.4 of MIXER also specify how an address should be
+   converted between RFC822 and X.400 in case a complete mapping is
+   impossible. To allow the use of DDAs for non mappable domains, the
+   MIXER 'gate2' table is thus introduced.
+
+   In a totally similar way, when an X.400 address cannot be completely
+   converted in RFC822, section 4.3.5 of MIXER specifies how to encode
+   (LHS encoding) the address itself, pointing then to the appropriate
+   MIXER conformant gateway, indicated in the MIXER 'gate1' table.
+
+   DNS must store and distribute also these 'gate1' and 'gate2' data.
+
+   One of the major features of the DNS is the ability to distribute the
+   authority: a certain site runs the "primary" nameserver for one
+   determined sub-tree and thus it is also the only place allowed to
+   update information regarding that sub-tree. This fact allows, in our
+
+
+
+Allocchio                   Standards Track                    [Page 17]
+
+RFC 2163                      MIXER MCGAM                   January 1998
+
+
+   case, a further additional feature to the table based approach. In
+   fact we can avoid one possible ambiguity about the use of the 'gate1'
+   and 'gate2' tables (and thus of LHS and DDAs encoding).
+
+   The authority maintaining a DNS entry in the usual RFC822 domain
+   space is the only one allowed to decide if its domain should be
+   mapped using Standard Attributes (SA) syntax or Domain Defined
+   Attributes (DDA) one. If the authority decides that its RFC822 domain
+   should be mapped using SA, then the PX RDATA will be a 'table2'
+   entry, otherwise it will be a 'gate2' table entry. Thus for an RFC822
+   domain we cannot have any more two possible entries, one from 'table2
+   and another one from 'gate2' table, and the action for a gateway
+   results clearly stated.
+
+   Similarly, the authority mantaining a DNS entry in the new X.400 name
+   space is the only one allowed to decide if its X.400 domain should be
+   mapped using SA syntax or Left Hand Side (LHS) encoding. If the
+   authority decides that its X.400 domain should be mapped using SA,
+   then the PX RDATA will be a 'table1' entry, otherwise it will be a
+   'gate1' table entry. Thus also for an X.400 domain we cannot have any
+   more two possible entries, one from 'table1' and another one from
+   'gate1' table, and the action for a gateway results clearly stated.
+
+   The MIXER 'gate1' table syntax is actually identical to MIXER
+   'table1', and 'gate2' table syntax is identical to MIXER 'table2'.
+   Thus the same syntax translation rules from MIXER to DNS format can
+   be applied in both cases. However a gateway or any other application
+   must know if the answer it got from DNS contains some 'table1',
+   'table2' or some 'gate1', 'gate2' table information. This is easily
+   obtained flagging with an additional ".G." post-fix the PX RDATA
+   value when it contains a 'gate1' or 'gate2' table entry. The example
+   in section 4.3 shows clearly the result. As any X.400 O/R domain must
+   end with a country code ("C-xx" in our DNS syntax) the additional
+   ".G." creates no conflicts or ambiguities at all. This postfix must
+   obviously be removed before using the MIXER 'gate1' or 'gate2' table
+   data.
+
+5. Finding MIXER mapping information from DNS
+
+   The MIXER mapping information is stored in DNS both in the normal
+   RFC822 domain name space, and in the newly defined X.400 name space.
+   The information, stored in PX resource records, does not represent a
+   full RFC822 or X.400 O/R address: it is a template which specifies
+   the fields of the domain that are used by the mapping algorithm.
+
+   When mapping information is stored in the DNS, queries to the DNS are
+   issued whenever an iterative search through the mapping table would
+   be performed (MIXER: section 4.3.4, State I; section 4.3.5, mapping
+
+
+
+Allocchio                   Standards Track                    [Page 18]
+
+RFC 2163                      MIXER MCGAM                   January 1998
+
+
+   B). Due to the DNS search mechanism, DNS by itself returns the
+   longest possible match in the stored mapping rule with a single
+   query, thus no iteration and/or multiple queries are needed. As
+   specified in MIXER, a search of the mapping table will result in
+   either success (mapping found) or failure (query failed, mapping not
+   found).
+
+   When a DNS query is issued, a third possible result is timeout. If
+   the result is timeout, the gateway operation is delayed and then
+   retried at a later time. A result of success or failure is processed
+   according to the algorithms specified in MIXER. If a DNS error code
+   is returned, an error message should be logged and the gateway
+   operation is delayed as for timeout. These pathological situations,
+   however, should be avoided with a careful duplication and chaching
+   mechanism which DNS itself provides.
+
+   Searching the nameserver which can authoritatively solve the query is
+   automatically performed by the DNS distributed name service.
+
+5.1 A DNS query example
+
+   An MIXER mail-gateway located in the Internet, when translating
+   addresses from RFC822 to X.400, can get information about the MCGAM
+   rule asking the DNS. As an example, when translating the address
+   SUN.CCE.NRC.IT, the gateway will just query DNS for the associated PX
+   resource record. The DNS should contain a PX record like this:
+
+   *.cce.nrc.it.  IN PX 50   cce.nrc.it.  O-cce.PRMD-nrc.ADMD-acme.C-it.
+
+   The first query will return immediately the appropriate mapping rule
+   in DNS store format.
+
+   There is no ".G." at the end of the obtained PX RDATA value, thus
+   applying the syntax translation specified in paragraph 4.2 the MIXER
+   Table 2 mapping rule will be obtained.
+
+   Let's now take another example where a 'gate2' table rule is
+   returned.  If we are looking for an RFC822 domain ending with top
+   level domain "MW", and the DNS contains a PX record like this,
+
+      *.mw.   IN  PX  50  mw.  O-cce.PRMD-nrc.ADMD-acme.C-it.G.
+
+   DNS will return 'mw.' and 'O-cce.PRMD-nrc.ADMD-acme.C-it.G.', i.e., a
+   'gate2' table entry in DNS store format. Dropping the final ".G." and
+   applying the syntax translation specified in paragraph 4.2 the
+   original rule will be available. More over, the ".G." flag also tells
+   the gateway to use DDA encoding for the inquired RFC822 domain.
+
+
+
+
+Allocchio                   Standards Track                    [Page 19]
+
+RFC 2163                      MIXER MCGAM                   January 1998
+
+
+   On the other hand, translating from X.400 to RFC822 the address
+
+      C=de; ADMD=pkz; PRMD=nfc; O=top;
+
+   the mail gateway should convert the syntax according to paragraph
+   4.2, apply the 'Country code convention' described in 4.2.3 to derive
+   the appropriate DNS translation of the X.400 O/R name and then query
+   DNS for the corresponding PX resource record. The obtained record for
+   which the PX record must be queried is thus:
+
+      O-top.PRMD-nfc.ADMD-pkz.X42D.de.
+
+   The DNS could contain:
+
+      *.ADMD-pkz.X42D.de.  IN  PX  50  pkz.de.  ADMD-pkz.C-de.
+
+   Assuming that there are not more specific records in DNS, the
+   wildcard mechanism will return the MIXER 'table1' rule in encoded
+   format.
+
+   Finally, an example where a 'gate1' rule is involved. If we are
+   looking for an X.400 domain ending with ADMD=PWT400; C=US; , and the
+   DNS contains a PX record like this,
+
+      *.ADMD-PWT400.X42D.us.  IN  PX  50  intGw.com. ADMD-PWT400.C-us.G.
+
+   DNS will return 'intGw.com.' and 'ADMD-PWT400.C-us.G.', i.e., a
+   'gate1' table entry in DNS store format. Dropping the final ".G." and
+   applying the syntax translation specified in paragraph 4.2 the
+   original rule will be available. More over, the ".G." flag also tells
+   the gateway to use LHS encoding for the inquired X.400 domain.
+
+6. Administration of mapping information
+
+   The DNS, using the PX RR, is able to distribute the MCGAM rules to
+   all MIXER gateways located on the Internet. However, not all MIXER
+   gateways will be able to use the Internet DNS. It is expected that
+   some gateways in a particular management domain will conform to one
+   of the following models:
+
+     (a) Table-based, (b) DNS-based, (c) X.500-based
+
+   Table-based management domains will continue to publish their MCGAM
+   rules and retrieve the mapping tables via the International Mapping
+   Table coordinator, manually or via some automated procedures. Their
+   MCGAM information can be made available also in DNS by the
+   appropriate DNS authorities, using the same mechanism already in
+   place for MX records: if a branch has not yet in place its own DNS
+
+
+
+Allocchio                   Standards Track                    [Page 20]
+
+RFC 2163                      MIXER MCGAM                   January 1998
+
+
+   server, some higher authority in the DNS tree will provide the
+   service for it. A transition procedure similar to the one used to
+   migrate from the 'hosts.txt' tables to DNS can be applied also to the
+   deployment phase of this specification. An informational document
+   describing the implementation phase and the detailed coordination
+   procedures is expected.
+
+   Another distributed directory service which can distribute the MCGAM
+   information is X.500. Coordination with table-based domains can be
+   obtained in an identical way as for the DNS case.
+
+   Coordination of MCGAM information between DNS and X.500 is more
+   complex, as it requies some kind of uploading information between the
+   two systems. The ideal solution is a dynamic alignment mechanism
+   which transparently makes the DNS mapping information available in
+   X.500 and vice versa. Some work in this specific field is already
+   being done [see Costa] which can result in a global transparent
+   directory service, where the information is stored in DNS or in
+   X.500, but is visible completely by any of the two systems.
+
+   However we must remind that MIXER concept of MCGAM rules publication
+   is different from the old RFC1327 concept of globally distributed,
+   coordinated and unique mapping rules. In fact MIXER does not requires
+   any more for any conformant gateway or tool to know the complete set
+   of MCGAM: it only requires to use some set (eventually empty) of
+   valid MCGAM rules, published either by Tables, DNS or X.500
+   mechanisms or any combination of these methods. More over MIXER
+   specifies that also incomplete sets of MCGAM can be used, and
+   supplementary local unpublished (but valid) MCGAM can also be used.
+   As a consequence, the problem of coordination between the three
+   systems proposed by MIXER for MCGAM publication is non essential, and
+   important only for efficient operational matters. It does not in fact
+   affect the correct behaviour of MIXER conformant gateways and tools.
+
+7. Conclusion
+
+   The introduction of the new PX resource record and the definition of
+   the X.400 O/R name space in the DNS structure provide a good
+   repository for MCGAM information. The mapping information is stored
+   in the DNS tree structure so that it can be easily obtained using the
+   DNS distributed name service. At the same time the definition of the
+   appropriate DNS space for X.400 O/R names provide a repository where
+   to store and distribute some other X.400 MHS information. The use of
+   the DNS has many known advantages in storing, managing and updating
+   the information. A successful number of tests were been performed
+   under the provisional top level domain "X400.IT" when RFC1664 was
+   developed, and their results confirmed the advantages of the method.
+   Operational exeprience for over 2 years with RFC1664 specification
+
+
+
+Allocchio                   Standards Track                    [Page 21]
+
+RFC 2163                      MIXER MCGAM                   January 1998
+
+
+   confirmed the feasibility of the method, and helped identifying some
+   operational procedures to deploy the insertion of MCGAM into DNS.
+
+   Software to query the DNS and then to convert between the textual
+   representation of DNS resource records and the address format defined
+   in MIXER was developed with RFC1664. This software also allows a
+   smooth implementation and deployment period, eventually taking care
+   of the transition phase. This software can be easily used (with
+   little or null modification) also for this updated specification,
+   supporting the new 'gate1' MIXER table. DNS software implementations
+   supporting RFC1664 also supports with no modification this memo new
+   specification.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Allocchio                   Standards Track                    [Page 22]
+
+RFC 2163                      MIXER MCGAM                   January 1998
+
+
+   A further informational document describing operational and
+   implementation of the service is expected.
+
+8. Acknowledgements
+
+   We wish to thanks all those who contributed to the discussion and
+   revision of this document: many of their ideas and suggestions
+   constitute essential parts of this work. In particular thanks to Jon
+   Postel, Paul Mockapetris, Rob Austin and the whole IETF x400ops,
+   TERENA wg-msg and IETF namedroppers groups. A special mention to
+   Christian Huitema for his fundamental contribution to this work.
+
+   This document is a revision of RFC1664, edited by one of its authors
+   on behalf of the IETF MIXER working group. The current editor wishes
+   to thank here also the authors of RFC1664:
+
+     Antonio Blasco Bonito     RFC822: bonito@cnuce.cnr.it
+     CNUCE - CNR               X.400:  C=it;A=garr;P=cnr;
+     Reparto infr. reti                O=cnuce;S=bonito;
+     Viale S. Maria 36
+     I 56126 Pisa
+     Italy
+
+
+     Bruce Cole                RFC822: bcole@cisco.com
+     Cisco Systems Inc.        X.400:  C=us;A= ;P=Internet;
+     P.O. Box 3075                     DD.rfc-822=bcole(a)cisco.com;
+     1525 O'Brien Drive
+     Menlo Park, CA 94026
+     U.S.A.
+
+
+     Silvia Giordano           RFC822: giordano@cscs.ch
+     Centro Svizzero di        X.400:  C=ch;A=arcom;P=switch;O=cscs;
+     Calcolo Scientifico               S=giordano;
+     Via Cantonale
+     CH 6928 Manno
+     Switzerland
+
+
+     Robert Hagens                   RFC822: hagens@ans.net
+     Advanced Network and Services   X.400:  C=us;A= ;P=Internet;
+     1875 Campus Commons Drive               DD.rfc-822=hagens(a)ans.net;
+     Reston, VA 22091
+     U.S.A.
+
+
+
+
+
+
+Allocchio                   Standards Track                    [Page 23]
+
+RFC 2163                      MIXER MCGAM                   January 1998
+
+
+9. References
+
+   [CCITT] CCITT SG 5/VII, "Recommendation X.400, Message Handling
+       Systems: System Model - Service Elements", October 1988.
+
+   [RFC 1327] Kille, S., "Mapping between X.400(1988)/ISO 10021 and RFC
+       822", RFC 1327, March 1992.
+
+   [RFC 1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
+       STD 13, RFC 1034, USC/Information Sciences Institute, November
+       1987.
+
+   [RFC 1035] Mockapetris, P., "Domain names - Implementation and
+       Specification", STD 13, RFC 1035, USC/Information Sciences
+       Institute, November 1987.
+
+   [RFC 1033] Lottor, M., "Domain Administrators Operation Guide", RFC
+       1033, SRI International, November 1987.
+
+   [RFC 2156] Kille, S. E., " MIXER (Mime Internet X.400 Enhanced
+       Relay): Mapping between X.400 and RFC 822/MIME", RFC 2156,
+       January 1998.
+
+   [Costa] Costa, A., Macedo, J., and V. Freitas, "Accessing and
+       Managing DNS Information in the X.500 Directory", Proceeding of
+       the 4th Joint European Networking Conference, Trondheim, NO, May
+       1993.
+
+10. Security Considerations
+
+   This document specifies a means by which DNS "PX" records can direct
+   the translation between X.400 and Internet mail addresses.
+
+   This can indirectly affect the routing of mail across an gateway
+   between X.400 and Internet Mail.  A succesful attack on this service
+   could cause incorrect translation of an originator address (thus
+   "forging" the originator address), or incorrect translation of a
+   recipient address (thus directing the mail to an unauthorized
+   recipient, or making it appear to an authorized recipient, that the
+   message was intended for recipients other than those chosen by the
+   originator) or could force the mail path via some particular gateway
+   or message transfer agent where mail security can be affected by
+   compromised software.
+
+
+
+
+
+
+
+
+Allocchio                   Standards Track                    [Page 24]
+
+RFC 2163                      MIXER MCGAM                   January 1998
+
+
+   There are several means by which an attacker might be able to deliver
+   incorrect PX records to a client.  These include: (a) compromise of a
+   DNS server,  (b) generating a counterfeit response to a client's DNS
+   query, (c) returning incorrect "additional information" in response
+   to an unrelated query.
+
+   Clients using PX records SHOULD ensure that routing and address
+   translations are based only on authoritative answers.  Once DNS
+   Security mechanisms [RFC 2065] become more widely deployed, clients
+   SHOULD employ those mechanisms to verify the authenticity and
+   integrity of PX records.
+
+11. Author's Address
+
+   Claudio Allocchio
+   Sincrotrone Trieste
+   SS 14 Km 163.5 Basovizza
+   I 34012 Trieste
+   Italy
+
+   RFC822: Claudio.Allocchio@elettra.trieste.it
+   X.400:  C=it;A=garr;P=Trieste;O=Elettra;
+   S=Allocchio;G=Claudio;
+   Phone:  +39 40 3758523
+   Fax:    +39 40 3758565
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Allocchio                   Standards Track                    [Page 25]
+
+RFC 2163                      MIXER MCGAM                   January 1998
+
+
+12.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (1998).  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 Standards process must be
+   followed, or as required to translate it into 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Allocchio                   Standards Track                    [Page 26]
+
diff --git a/doc/rfc/rfc2168.txt b/doc/rfc/rfc2168.txt
new file mode 100644
index 0000000..3eed1bd
--- /dev/null
+++ b/doc/rfc/rfc2168.txt
@@ -0,0 +1,1123 @@
+
+
+
+
+
+
+Network Working Group                                       R. Daniel
+Request for Comments: 2168             Los Alamos National Laboratory
+Category: Experimental                                    M. Mealling
+                                              Network Solutions, Inc.
+                                                            June 1997
+
+
+               Resolution of Uniform Resource Identifiers
+                      using the Domain Name System
+
+Status of this Memo
+===================
+
+   This memo defines an Experimental Protocol for the Internet
+   community.  This memo does not specify an Internet standard of any
+   kind.  Discussion and suggestions for improvement are requested.
+   Distribution of this memo is unlimited.
+
+Abstract:
+=========
+
+   Uniform Resource Locators (URLs) are the foundation of the World Wide
+   Web, and are a vital Internet technology. However, they have proven
+   to be brittle in practice. The basic problem is that URLs typically
+   identify a particular path to a file on a particular host. There is
+   no graceful way of changing the path or host once the URL has been
+   assigned. Neither is there a graceful way of replicating the resource
+   located by the URL to achieve better network utilization and/or fault
+   tolerance. Uniform Resource Names (URNs) have been hypothesized as a
+   adjunct to URLs that would overcome such problems. URNs and URLs are
+   both instances of a broader class of identifiers known as Uniform
+   Resource Identifiers (URIs).
+
+   The requirements document for URN resolution systems[15] defines the
+   concept of a "resolver discovery service". This document describes
+   the first, experimental, RDS. It is implemented by a new DNS Resource
+   Record, NAPTR (Naming Authority PoinTeR), that provides rules for
+   mapping parts of URIs to domain names.  By changing the mapping
+   rules, we can change the host that is contacted to resolve a URI.
+   This will allow a more graceful handling of URLs over long time
+   periods, and forms the foundation for a new proposal for Uniform
+   Resource Names.
+
+
+
+
+
+
+
+
+
+Daniel & Mealling             Experimental                      [Page 1]
+
+RFC 2168            Resolution of URIs Using the DNS           June 1997
+
+
+   In addition to locating resolvers, the NAPTR provides for other
+   naming systems to be grandfathered into the URN world, provides
+   independence between the name assignment system and the resolution
+   protocol system, and allows multiple services (Name to Location, Name
+   to Description, Name to Resource, ...) to be offered.  In conjunction
+   with the SRV RR, the NAPTR record allows those services to be
+   replicated for the purposes of fault tolerance and load balancing.
+
+Introduction:
+=============
+
+   Uniform Resource Locators have been a significant advance in
+   retrieving Internet-accessible resources. However, their  brittle
+   nature over time has been recognized for several years. The Uniform
+   Resource Identifier working group proposed the development of Uniform
+   Resource Names to serve as persistent, location-independent
+   identifiers for Internet resources in order to overcome most of the
+   problems with URLs. RFC-1737 [1] sets forth requirements on URNs.
+
+   During the lifetime of the URI-WG, a number of URN proposals were
+   generated. The developers of several of those proposals met in a
+   series of meetings, resulting in a compromise known as the Knoxville
+   framework.  The major principle behind the Knoxville framework is
+   that the resolution system must be separate from the way names are
+   assigned. This is in marked contrast to most URLs, which identify the
+   host to contact and the protocol to use. Readers are referred to [2]
+   for background on the Knoxville framework and for additional
+   information on the context and purpose of this proposal.
+
+   Separating the way names are resolved from the way they are
+   constructed provides several benefits. It allows multiple naming
+   approaches and resolution approaches to compete, as it allows
+   different protocols and resolvers to be used. There is just one
+   problem with such a separation - how do we resolve a name when it
+   can't give us directions to its resolver?
+
+   For the short term, DNS is the obvious candidate for the resolution
+   framework, since it is widely deployed and understood. However, it is
+   not appropriate to use DNS to maintain information on a per-resource
+   basis. First of all, DNS was never intended to handle that many
+   records. Second, the limited record size is inappropriate for catalog
+   information. Third, domain names are not appropriate as URNs.
+
+   Therefore our approach is to use DNS to locate "resolvers" that can
+   provide information on individual resources, potentially including
+   the resource itself. To accomplish this, we "rewrite" the URI into a
+   domain name following the rules provided in NAPTR records. Rewrite
+   rules provide considerable power, which is important when trying to
+
+
+
+Daniel & Mealling             Experimental                      [Page 2]
+
+RFC 2168            Resolution of URIs Using the DNS           June 1997
+
+
+   meet the goals listed above. However, collections of rules can become
+   difficult to understand. To lessen this problem, the NAPTR rules are
+   *always* applied to the original URI, *never* to the output of
+   previous rules.
+
+   Locating a resolver through the rewrite procedure may take multiple
+   steps, but the beginning is always the same. The start of the URI is
+   scanned to extract its colon-delimited prefix. (For URNs, the prefix
+   is always "urn:" and we extract the following colon-delimited
+   namespace identifier [3]). NAPTR resolution begins by taking the
+   extracted string, appending the well-known suffix ".urn.net", and
+   querying the DNS for NAPTR records at that domain name.  Based on the
+   results of this query, zero or more additional DNS queries may be
+   needed to locate resolvers for the URI. The details of the
+   conversation between the client and the resolver thus located are
+   outside the bounds of this draft. Three brief examples of this
+   procedure are given in the next section.
+
+   The NAPTR RR provides the level of indirection needed to keep the
+   naming system independent of the resolution system, its protocols,
+   and services.  Coupled with the new SRV resource record proposal[4]
+   there is also the potential for replicating the resolver on multiple
+   hosts, overcoming some of the most significant problems of URLs. This
+   is an important and subtle point. Not only do the NAPTR and SRV
+   records allow us to replicate the resource, we can replicate the
+   resolvers that know about the replicated resource. Preventing a
+   single point of failure at the resolver level is a significant
+   benefit. Separating the resolution procedure from the way names are
+   constructed has additional benefits.  Different resolution procedures
+   can be used over time, and resolution procedures that are determined
+   to be useful can be extended to deal with additional namespaces.
+
+Caveats
+=======
+
+   The NAPTR proposal is the first resolution procedure to be considered
+   by the URN-WG. There are several concerns about the proposal which
+   have motivated the group to recommend it for publication as an
+   Experimental rather than a standards-track RFC.
+
+   First, URN resolution is new to the IETF and we wish to gain
+   operational experience before recommending any procedure for the
+   standards track. Second, the NAPTR proposal is based on DNS and
+   consequently inherits concerns about security and administration. The
+   recent advancement of the DNSSEC and secure update drafts to Proposed
+   Standard reduce these concerns, but we wish to experiment with those
+   new capabilities in the context of URN administration.  A third area
+   of concern is the potential for a noticeable impact on the DNS.  We
+
+
+
+Daniel & Mealling             Experimental                      [Page 3]
+
+RFC 2168            Resolution of URIs Using the DNS           June 1997
+
+
+   believe that the proposal makes appropriate use of caching and
+   additional information, but it is best to go slow where the potential
+   for impact on a core system like the DNS is concerned. Fourth, the
+   rewrite rules in the NAPTR proposal are based on regular expressions.
+   Since regular expressions are difficult for humans to construct
+   correctly, concerns exist about the usability and maintainability of
+   the rules. This is especially true where international character sets
+   are concerned. Finally, the URN-WG is developing a requirements
+   document for URN Resolution Services[15], but that document is not
+   complete. That document needs to precede any resolution service
+   proposals on the standards track.
+
+Terminology
+===========
+
+   "Must" or "Shall" - Software that does not behave in the manner that
+              this document says it must is not conformant to this
+              document.
+   "Should" - Software that does not follow the behavior that this
+              document says it should may still be conformant, but is
+              probably broken in some fundamental way.
+   "May" -    Implementations may or may not provide the described
+              behavior, while still remaining conformant to this
+              document.
+
+Brief overview and examples of the NAPTR RR:
+============================================
+
+   A detailed description of the NAPTR RR will be given later, but to
+   give a flavor for the proposal we first give a simple description of
+   the record and three examples of its use.
+
+   The key fields in the NAPTR RR are order, preference, service, flags,
+   regexp, and replacement:
+
+   * The order field specifies the order in which records MUST be
+     processed when multiple NAPTR records are returned in response to a
+     single query.  A naming authority may have delegated a portion of
+     its namespace to another agency. Evaluating the NAPTR records in
+     the correct order is necessary for delegation to work properly.
+
+   * The preference field specifies the order in which records SHOULD be
+     processed when multiple NAPTR records have the same value of
+     "order".  This field lets a service provider specify the order in
+     which resolvers are contacted, so that more capable machines are
+     contacted in preference to less capable ones.
+
+
+
+
+
+Daniel & Mealling             Experimental                      [Page 4]
+
+RFC 2168            Resolution of URIs Using the DNS           June 1997
+
+
+   * The service field specifies the resolution protocol and resolution
+     service(s) that will be available if the rewrite specified by the
+     regexp or replacement fields is applied. Resolution protocols are
+     the protocols used to talk with a resolver. They will be specified
+     in other documents, such as [5]. Resolution services are operations
+     such as N2R (URN to Resource), N2L (URN to URL), N2C (URN to URC),
+     etc.  These will be discussed in the URN Resolution Services
+     document[6], and their behavior in a particular resolution protocol
+     will be given in the specification for that protocol (see [5] for a
+     concrete example).
+
+   * The flags field contains modifiers that affect what happens in the
+     next DNS lookup, typically for optimizing the process. Flags may
+     also affect the interpretation of the other fields in the record,
+     therefore, clients MUST skip NAPTR records which contain an unknown
+     flag value.
+
+   * The regexp field is one of two fields used for the rewrite rules,
+     and is the core concept of the NAPTR record. The regexp field is a
+     String containing a sed-like substitution expression. (The actual
+     grammar for the substitution expressions is given later in this
+     draft). The substitution expression is applied to the original URN
+     to determine the next domain name to be queried. The regexp field
+     should be used when the domain name to be generated is conditional
+     on information in the URI. If the next domain name is always known,
+     which is anticipated to be a common occurrence, the replacement
+     field should be used instead.
+
+   * The replacement field is the other field that may be used for the
+     rewrite rule. It is an optimization of the rewrite process for the
+     case where the next domain name is fixed instead of being
+     conditional on the content of the URI. The replacement field is a
+     domain name (subject to compression if a DNS sender knows that a
+     given recipient is able to decompress names in this RR type's RDATA
+     field). If the rewrite is more complex than a simple substitution
+     of a domain name, the replacement field should be set to . and the
+     regexp field used.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Daniel & Mealling             Experimental                      [Page 5]
+
+RFC 2168            Resolution of URIs Using the DNS           June 1997
+
+
+   Note that the client applies all the substitutions and performs all
+   lookups, they are not performed in the DNS servers. Note also that it
+   is the belief of the developers of this document that regexps should
+   rarely be used. The replacement field seems adequate for the vast
+   majority of situations. Regexps are only necessary when portions of a
+   namespace are to be delegated to different resolvers. Finally, note
+   that the regexp and replacement fields are, at present, mutually
+   exclusive. However, developers of client software should be aware
+   that a new flag might be defined which requires values in both
+   fields.
+
+Example 1
+---------
+
+   Consider a URN that uses the hypothetical DUNS namespace. DUNS
+   numbers are identifiers for approximately 30 million registered
+   businesses around the world, assigned and maintained by Dunn and
+   Bradstreet. The URN might look like:
+
+                   urn:duns:002372413:annual-report-1997
+
+   The first step in the resolution process is to find out about the
+   DUNS namespace. The namespace identifier, "duns", is extracted from
+   the URN, prepended to urn.net, and the NAPTRs for duns.urn.net looked
+   up. It might return records of the form:
+
+duns.urn.net
+;;      order pref flags service          regexp        replacement
+ IN NAPTR 100  10  "s" "dunslink+N2L+N2C" ""  dunslink.udp.isi.dandb.com
+ IN NAPTR 100  20  "s" "rcds+N2C"         ""  rcds.udp.isi.dandb.com
+ IN NAPTR 100  30  "s" "http+N2L+N2C+N2R" ""  http.tcp.isi.dandb.com
+
+   The order field contains equal values, indicating that no name
+   delegation order has to be followed. The preference field indicates
+   that the provider would like clients to use the special dunslink
+   protocol, followed by the RCDS protocol, and that HTTP is offered as
+   a last resort. All the records specify the "s" flag, which will be
+   explained momentarily.  The service fields say that if we speak
+   dunslink, we will be able to issue either the N2L or N2C requests to
+   obtain a URL or a URC (description) of the resource. The Resource
+   Cataloging and Distribution Service (RCDS)[7] could be used to get a
+   URC for the resource, while HTTP could be used to get a URL, URC, or
+   the resource itself.  All the records supply the next domain name to
+   query, none of them need to be rewritten with the aid of regular
+   expressions.
+
+
+
+
+
+
+Daniel & Mealling             Experimental                      [Page 6]
+
+RFC 2168            Resolution of URIs Using the DNS           June 1997
+
+
+   The general case might require multiple NAPTR rewrites to locate a
+   resolver, but eventually we will come to the "terminal NAPTR". Once
+   we have the terminal NAPTR, our next probe into the DNS will be for a
+   SRV or A record instead of another NAPTR. Rather than probing for a
+   non-existent NAPTR record to terminate the loop, the flags field is
+   used to indicate a terminal lookup. If it has a value of "s", the
+   next lookup should be for SRV RRs, "a" denotes that A records should
+   sought.  A "p" flag is also provided to indicate that the next action
+   is Protocol-specific, but that looking up another NAPTR will not be
+   part of it.
+
+   Since our example RR specified the "s" flag, it was terminal.
+   Assuming our client does not know the dunslink protocol, our next
+   action is to lookup SRV RRs for rcds.udp.isi.dandb.com, which will
+   tell us hosts that can provide the necessary resolution service. That
+   lookup might return:
+
+    ;;                          Pref Weight Port Target
+    rcds.udp.isi.dandb.com IN SRV 0    0    1000 defduns.isi.dandb.com
+                           IN SRV 0    0    1000 dbmirror.com.au
+                           IN SRV 0    0    1000 ukmirror.com.uk
+
+   telling us three hosts that could actually do the resolution, and
+   giving us the port we should use to talk to their RCDS server.  (The
+   reader is referred to the SRV proposal [4] for the interpretation of
+   the fields above).
+
+   There is opportunity for significant optimization here. We can return
+   the SRV records as additional information for terminal NAPTRs (and
+   the A records as additional information for those SRVs). While this
+   recursive provision of additional information is not explicitly
+   blessed in the DNS specifications, it is not forbidden, and BIND does
+   take advantage of it [8]. This is a significant optimization. In
+   conjunction with a long TTL for *.urn.net records, the average number
+   of probes to DNS for resolving DUNS URNs would approach one.
+   Therefore, DNS server implementors SHOULD provide additional
+   information with NAPTR responses. The additional information will be
+   either SRV or A records.  If SRV records are available, their A
+   records should be provided as recursive additional information.
+
+   Note that the example NAPTR records above are intended to represent
+   the reply the client will see. They are not quite identical to what
+   the domain administrator would put into the zone files. For one
+   thing, the administrator should supply the trailing '.' character on
+   any FQDNs.
+
+
+
+
+
+
+Daniel & Mealling             Experimental                      [Page 7]
+
+RFC 2168            Resolution of URIs Using the DNS           June 1997
+
+
+Example 2
+---------
+
+   Consider a URN namespace based on MIME Content-Ids. The URN might
+   look like this:
+
+                 urn:cid:199606121851.1@mordred.gatech.edu
+
+   (Note that this example is chosen for pedagogical purposes, and does
+   not conform to the recently-approved CID URL scheme.)
+
+   The first step in the resolution process is to find out about the CID
+   namespace. The namespace identifier, cid, is extracted from the URN,
+   prepended to urn.net, and the NAPTR for cid.urn.net looked up. It
+   might return records of the form:
+
+ cid.urn.net
+  ;;       order pref flags service        regexp           replacement
+   IN NAPTR 100   10   ""  ""  "/urn:cid:.+@([^\.]+\.)(.*)$/\2/i"    .
+
+   We have only one NAPTR response, so ordering the responses is not a
+   problem.  The replacement field is empty, so we check the regexp
+   field and use the pattern provided there. We apply that regexp to the
+   entire URN to see if it matches, which it does.  The \2 part of the
+   substitution expression returns the string "gatech.edu". Since the
+   flags field does not contain "s" or "a", the lookup is not terminal
+   and our next probe to DNS is for more NAPTR records:
+   lookup(query=NAPTR, "gatech.edu").
+
+   Note that the rule does not extract the full domain name from the
+   CID, instead it assumes the CID comes from a host and extracts its
+   domain.  While all hosts, such as mordred, could have their very own
+   NAPTR, maintaining those records for all the machines at a site as
+   large as Georgia Tech would be an intolerable burden. Wildcards are
+   not appropriate here since they only return results when there is no
+   exactly matching names already in the system.
+
+   The record returned from the query on "gatech.edu" might look like:
+
+gatech.edu IN NAPTR
+;;       order pref flags service           regexp  replacement
+  IN NAPTR 100  50  "s"  "z3950+N2L+N2C"     ""    z3950.tcp.gatech.edu
+  IN NAPTR 100  50  "s"  "rcds+N2C"          ""    rcds.udp.gatech.edu
+  IN NAPTR 100  50  "s"  "http+N2L+N2C+N2R"  ""    http.tcp.gatech.edu
+
+
+
+
+
+
+
+Daniel & Mealling             Experimental                      [Page 8]
+
+RFC 2168            Resolution of URIs Using the DNS           June 1997
+
+
+   Continuing with our example, we note that the values of the order and
+   preference fields are equal in all records, so the client is free to
+   pick any record. The flags field tells us that these are the last
+   NAPTR patterns we should see, and after the rewrite (a simple
+   replacement in this case) we should look up SRV records to get
+   information on the hosts that can provide the necessary service.
+
+   Assuming we prefer the Z39.50 protocol, our lookup might return:
+
+   ;;                        Pref Weight   Port Target
+   z3950.tcp.gatech.edu IN SRV 0    0      1000 z3950.gatech.edu
+                        IN SRV 0    0      1000 z3950.cc.gatech.edu
+                        IN SRV 0    0      1000 z3950.uga.edu
+
+   telling us three hosts that could actually do the resolution, and
+   giving us the port we should use to talk to their Z39.50 server.
+
+   Recall that the regular expression used \2 to extract a domain name
+   from the CID, and \. for matching the literal '.' characters
+   seperating the domain name components. Since '\' is the escape
+   character, literal occurances of a backslash must be escaped by
+   another backslash. For the case of the cid.urn.net record above, the
+   regular expression entered into the zone file should be
+   "/urn:cid:.+@([^\\.]+\\.)(.*)$/\\2/i".  When the client code actually
+   receives the record, the pattern will have been converted to
+   "/urn:cid:.+@([^.]+\.)(.*)$/\2/i".
+
+Example 3
+---------
+
+   Even if URN systems were in place now, there would still be a
+   tremendous number of URLs.  It should be possible to develop a URN
+   resolution system that can also provide location independence for
+   those URLs.  This is related to the requirement in [1] to be able to
+   grandfather in names from other naming systems, such as ISO Formal
+   Public Identifiers, Library of Congress Call Numbers, ISBNs, ISSNs,
+   etc.
+
+   The NAPTR RR could also be used for URLs that have already been
+   assigned.  Assume we have the URL for a very popular piece of
+   software that the publisher wishes to mirror at multiple sites around
+   the world:
+
+        http://www.foo.com/software/latest-beta.exe
+
+
+
+
+
+
+
+Daniel & Mealling             Experimental                      [Page 9]
+
+RFC 2168            Resolution of URIs Using the DNS           June 1997
+
+
+   We extract the prefix, "http", and lookup NAPTR records for
+   http.urn.net. This might return a record of the form
+
+   http.urn.net IN NAPTR
+   ;;  order   pref flags service      regexp             replacement
+        100     90   ""      ""   "!http://([^/:]+)!\1!i"       .
+
+   This expression returns everything after the first double slash and
+   before the next slash or colon. (We use the '!' character to delimit
+   the parts of the substitution expression. Otherwise we would have to
+   use backslashes to escape the forward slashes, and would have a
+   regexp in the zone file that looked like
+   "/http:\\/\\/([^\\/:]+)/\\1/i".).
+
+   Applying this pattern to the URL extracts "www.foo.com". Looking up
+   NAPTR records for that might return:
+
+   www.foo.com
+   ;;       order pref flags   service  regexp     replacement
+    IN NAPTR 100  100  "s"   "http+L2R"   ""    http.tcp.foo.com
+    IN NAPTR 100  100  "s"   "ftp+L2R"    ""    ftp.tcp.foo.com
+
+   Looking up SRV records for http.tcp.foo.com would return information
+   on the hosts that foo.com has designated to be its mirror sites. The
+   client can then pick one for the user.
+
+NAPTR RR Format
+===============
+
+   The format of the NAPTR RR is given below. The DNS type code for
+   NAPTR is 35.
+
+       Domain TTL Class Order Preference Flags Service Regexp
+       Replacement
+
+   where:
+
+   Domain
+          The domain name this resource record refers to.
+   TTL
+          Standard DNS Time To Live field
+   Class
+          Standard DNS meaning
+
+
+
+
+
+
+
+
+Daniel & Mealling             Experimental                     [Page 10]
+
+RFC 2168            Resolution of URIs Using the DNS           June 1997
+
+
+   Order
+          A 16-bit integer specifying the order in which the NAPTR
+          records MUST be processed to ensure correct delegation of
+          portions of the namespace over time. Low numbers are processed
+          before high numbers, and once a NAPTR is found that "matches"
+          a URN, the client MUST NOT consider any NAPTRs with a higher
+          value for order.
+
+   Preference
+          A 16-bit integer which specifies the order in which NAPTR
+          records with equal "order" values SHOULD be processed, low
+          numbers being processed before high numbers.  This is similar
+          to the preference field in an MX record, and is used so domain
+          administrators can direct clients towards more capable hosts
+          or lighter weight protocols.
+
+   Flags
+          A String giving flags to control aspects of the rewriting and
+          interpretation of the fields in the record. Flags are single
+          characters from the set [A-Z0-9]. The case of the alphabetic
+          characters is not significant.
+
+          At this time only three flags, "S", "A", and "P", are defined.
+          "S" means that the next lookup should be for SRV records
+          instead of NAPTR records. "A" means that the next lookup
+          should be for A records. The "P" flag says that the remainder
+          of the resolution shall be carried out in a Protocol-specific
+          fashion, and we should not do any more DNS queries.
+
+          The remaining alphabetic flags are reserved. The numeric flags
+          may be used for local experimentation. The S, A, and P flags
+          are all mutually exclusive, and resolution libraries MAY
+          signal an error if more than one is given. (Experimental code
+          and code for assisting in the creation of NAPTRs would be more
+          likely to signal such an error than a client such as a
+          browser). We anticipate that multiple flags will be allowed in
+          the future, so implementers MUST NOT assume that the flags
+          field can only contain 0 or 1 characters. Finally, if a client
+          encounters a record with an unknown flag, it MUST ignore it
+          and move to the next record. This test takes precedence even
+          over the "order" field. Since flags can control the
+          interpretation placed on fields, a novel flag might change the
+          interpretation of the regexp and/or replacement fields such
+          that it is impossible to determine if a record matched a URN.
+
+
+
+
+
+
+
+Daniel & Mealling             Experimental                     [Page 11]
+
+RFC 2168            Resolution of URIs Using the DNS           June 1997
+
+
+   Service
+          Specifies the resolution service(s) available down this
+          rewrite path. It may also specify the particular protocol that
+          is used to talk with a resolver. A protocol MUST be specified
+          if the flags field states that the NAPTR is terminal. If a
+          protocol is specified, but the flags field does not state that
+          the NAPTR is terminal, the next lookup MUST be for a NAPTR.
+          The client MAY choose not to perform the next lookup if the
+          protocol is unknown, but that behavior MUST NOT be relied
+          upon.
+
+          The service field may take any of the values below (using the
+          Augmented BNF of RFC 822[9]):
+
+           service_field = [ [protocol] *("+" rs)]
+           protocol      = ALPHA *31ALPHANUM
+           rs            = ALPHA *31ALPHANUM
+        // The protocol and rs fields are limited to 32
+        // characters and must start with an alphabetic.
+        // The current set of "known" strings are:
+        // protocol      = "rcds" / "thttp" / "hdl" / "rwhois" / "z3950"
+        // rs            = "N2L" / "N2Ls" / "N2R" / "N2Rs" / "N2C"
+        //               / "N2Ns" / "L2R" / "L2Ns" / "L2Ls" / "L2C"
+
+          i.e. an optional protocol specification followed by 0 or more
+          resolution services. Each resolution service is indicated by
+          an initial '+' character.
+
+          Note that the empty string is also a valid service field. This
+          will typically be seen at the top levels of a namespace, when
+          it is impossible to know what services and protocols will be
+          offered by a particular publisher within that name space.
+
+          At this time the known protocols are rcds[7], hdl[10] (binary,
+          UDP-based protocols),  thttp[5] (a textual, TCP-based
+          protocol), rwhois[11] (textual, UDP or TCP based), and
+          Z39.50[12] (binary, TCP-based). More will be allowed later.
+          The names of the protocols must be formed from the characters
+          [a-Z0-9]. Case of the characters is not significant.
+
+          The service requests currently allowed will be described in
+          more detail in [6], but in brief they are:
+                N2L  - Given a URN, return a URL
+                N2Ls - Given a URN, return a set of URLs
+                N2R  - Given a URN, return an instance of the resource.
+                N2Rs - Given a URN, return multiple instances of the
+                       resource, typically encoded using
+                       multipart/alternative.
+
+
+
+Daniel & Mealling             Experimental                     [Page 12]
+
+RFC 2168            Resolution of URIs Using the DNS           June 1997
+
+
+                N2C  - Given a URN, return a collection of meta-
+                       information on the named resource. The format of
+                       this response is the subject of another document.
+                N2Ns - Given a URN, return all URNs that are also
+                       identifers for the resource.
+                L2R  - Given a URL, return the resource.
+                L2Ns - Given a URL, return all the URNs that are
+                       identifiers for the resource.
+                L2Ls - Given a URL, return all the URLs for instances of
+                       of the same resource.
+                L2C  - Given a URL, return a description of the
+                       resource.
+
+          The actual format of the service request and response will be
+          determined by the resolution protocol, and is the subject for
+          other documents (e.g. [5]). Protocols need not offer all
+          services. The labels for service requests shall be formed from
+          the set of characters [A-Z0-9]. The case of the alphabetic
+          characters is not significant.
+
+   Regexp
+          A STRING containing a substitution expression that is applied
+          to the original URI in order to construct the next domain name
+          to lookup. The grammar of the substitution expression is given
+          in the next section.
+
+   Replacement
+          The next NAME to query for NAPTR, SRV, or A records depending
+          on the value of the flags field. As mentioned above, this may
+          be compressed.
+
+Substitution Expression Grammar:
+================================
+
+   The content of the regexp field is a substitution expression. True
+   sed(1) substitution expressions are not appropriate for use in this
+   application for a variety of reasons, therefore the contents of the
+   regexp field MUST follow the grammar below:
+
+subst_expr   = delim-char  ere  delim-char  repl  delim-char  *flags
+delim-char   = "/" / "!" / ... (Any non-digit or non-flag character other
+               than backslash '\'. All occurances of a delim_char in a
+               subst_expr must be the same character.)
+ere          = POSIX Extended Regular Expression (see [13], section
+               2.8.4)
+repl         = dns_str /  backref / repl dns_str  / repl backref
+dns_str      = 1*DNS_CHAR
+backref      = "\" 1POS_DIGIT
+
+
+
+Daniel & Mealling             Experimental                     [Page 13]
+
+RFC 2168            Resolution of URIs Using the DNS           June 1997
+
+
+flags        = "i"
+DNS_CHAR     = "-" / "0" / ... / "9" / "a" / ... / "z" / "A" / ... / "Z"
+POS_DIGIT    = "1" / "2" / ... / "9"  ; 0 is not an allowed backref
+value domain name (see RFC-1123 [14]).
+
+   The result of applying the substitution expression to the original
+   URI MUST result in a string that obeys the syntax for DNS host names
+   [14]. Since it is possible for the regexp field to be improperly
+   specified, such that a non-conforming host name can be constructed,
+   client software SHOULD verify that the result is a legal host name
+   before making queries on it.
+
+   Backref expressions in the repl portion of the substitution
+   expression are replaced by the (possibly empty) string of characters
+   enclosed by '(' and ')' in the ERE portion of the substitution
+   expression. N is a single digit from 1 through 9, inclusive. It
+   specifies the N'th backref expression, the one that begins with the
+   N'th '(' and continues to the matching ')'.  For example, the ERE
+                      (A(B(C)DE)(F)G)
+   has backref expressions:
+                      \1  = ABCDEFG
+                      \2  = BCDE
+                      \3  = C
+                      \4  = F
+                 \5..\9  = error - no matching subexpression
+
+   The "i" flag indicates that the ERE matching SHALL be performed in a
+   case-insensitive fashion. Furthermore, any backref replacements MAY
+   be normalized to lower case when the "i" flag is given.
+
+   The first character in the substitution expression shall be used as
+   the character that delimits the components of the substitution
+   expression.  There must be exactly three non-escaped occurrences of
+   the delimiter character in a substitution expression. Since escaped
+   occurrences of the delimiter character will be interpreted as
+   occurrences of that character, digits MUST NOT be used as delimiters.
+   Backrefs would be confused with literal digits were this allowed.
+   Similarly, if flags are specified in the substitution expression, the
+   delimiter character must not also be a flag character.
+
+
+
+
+
+
+
+
+
+
+
+
+Daniel & Mealling             Experimental                     [Page 14]
+
+RFC 2168            Resolution of URIs Using the DNS           June 1997
+
+
+Advice to domain administrators:
+================================
+
+   Beware of regular expressions. Not only are they a pain to get
+   correct on their own, but there is the previously mentioned
+   interaction with DNS. Any backslashes in a regexp must be entered
+   twice in a zone file in order to appear once in a query response.
+   More seriously, the need for double backslashes has probably not been
+   tested by all implementors of DNS servers. We anticipate that urn.net
+   will be the heaviest user of regexps. Only when delegating portions
+   of namespaces should the typical domain administrator need to use
+   regexps.
+
+   On a related note, beware of interactions with the shell when
+   manipulating regexps from the command line. Since '\' is a common
+   escape character in shells, there is a good chance that when you
+   think you are saying "\\" you are actually saying "\".  Similar
+   caveats apply to characters such as
+
+   The "a" flag allows the next lookup to be for A records rather than
+   SRV records. Since there is no place for a port specification in the
+   NAPTR record, when the "A" flag is used the specified protocol must
+   be running on its default port.
+
+   The URN Sytnax draft defines a canonical form for each URN, which
+   requires %encoding characters outside a limited repertoire. The
+   regular expressions MUST be written to operate on that canonical
+   form. Since international character sets will end up with extensive
+   use of %encoded characters, regular expressions operating on them
+   will be essentially impossible to read or write by hand.
+
+Usage
+=====
+
+   For the edification of implementers, pseudocode for a client routine
+   using NAPTRs is given below. This code is provided merely as a
+   convience, it does not have any weight as a standard way to process
+   NAPTR records. Also, as is the case with pseudocode, it has never
+   been executed and may contain logical errors. You have been warned.
+
+    //
+    // findResolver(URN)
+    // Given a URN, find a host that can resolve it.
+    //
+    findResolver(string URN) {
+      // prepend prefix to urn.net
+      sprintf(key, "%s.urn.net", extractNS(URN));
+      do {
+
+
+
+Daniel & Mealling             Experimental                     [Page 15]
+
+RFC 2168            Resolution of URIs Using the DNS           June 1997
+
+
+        rewrite_flag = false;
+        terminal = false;
+        if (key has been seen) {
+          quit with a loop detected error
+        }
+        add key to list of "seens"
+        records = lookup(type=NAPTR, key); // get all NAPTR RRs for 'key'
+
+        discard any records with an unknown value in the "flags" field.
+        sort NAPTR records by "order" field and "preference" field
+            (with "order" being more significant than "preference").
+        n_naptrs = number of NAPTR records in response.
+        curr_order = records[0].order;
+        max_order = records[n_naptrs-1].order;
+
+        // Process current batch of NAPTRs according to "order" field.
+        for (j=0; j < n_naptrs && records[j].order <= max_order; j++) {
+          if (unknown_flag) // skip this record and go to next one
+             continue;
+          newkey = rewrite(URN, naptr[j].replacement, naptr[j].regexp);
+          if (!newkey) // Skip to next record if the rewrite didn't
+             match continue;
+          // We did do a rewrite, shrink max_order to current value
+          // so that delegation works properly
+          max_order = naptr[j].order;
+          // Will we know what to do with the protocol and services
+          // specified in the NAPTR? If not, try next record.
+          if(!isKnownProto(naptr[j].services)) {
+            continue;
+          }
+          if(!isKnownService(naptr[j].services)) {
+            continue;
+          }
+
+          // At this point we have a successful rewrite and we will
+          // know how to speak the protocol and request a known
+          // resolution service. Before we do the next lookup, check
+          // some optimization possibilities.
+
+          if (strcasecmp(flags, "S")
+           || strcasecmp(flags, "P"))
+           || strcasecmp(flags, "A")) {
+             terminal = true;
+             services = naptr[j].services;
+             addnl = any SRV and/or A records returned as additional
+                     info for naptr[j].
+          }
+          key = newkey;
+
+
+
+Daniel & Mealling             Experimental                     [Page 16]
+
+RFC 2168            Resolution of URIs Using the DNS           June 1997
+
+
+          rewriteflag = true;
+          break;
+        }
+      } while (rewriteflag && !terminal);
+
+      // Did we not find our way to a resolver?
+      if (!rewrite_flag) {
+         report an error
+         return NULL;
+      }
+
+
+      // Leave rest to another protocol?
+      if (strcasecmp(flags, "P")) {
+         return key as host to talk to;
+      }
+
+      // If not, keep plugging
+      if (!addnl) { // No SRVs came in as additional info, look them up
+        srvs = lookup(type=SRV, key);
+      }
+
+      sort SRV records by preference, weight, ...
+      foreach (SRV record) { // in order of preference
+        try contacting srv[j].target using the protocol and one of the
+            resolution service requests from the "services" field of the
+            last NAPTR record.
+        if (successful)
+          return (target, protocol, service);
+          // Actually we would probably return a result, but this
+          // code was supposed to just tell us a good host to talk to.
+      }
+      die with an "unable to find a host" error;
+    }
+
+Notes:
+======
+
+     -  A client MUST process multiple NAPTR records in the order
+        specified by the "order" field, it MUST NOT simply use the first
+        record that provides a known protocol and service combination.
+
+
+
+
+
+
+
+
+
+
+Daniel & Mealling             Experimental                     [Page 17]
+
+RFC 2168            Resolution of URIs Using the DNS           June 1997
+
+
+     -  If a record at a particular order matches the URI, but the
+        client doesn't know the specified protocol and service, the
+        client SHOULD continue to examine records that have the same
+        order. The client MUST NOT consider records with a higher value
+        of order. This is necessary to make delegation of portions of
+        the namespace work.  The order field is what lets site
+        administrators say "all requests for URIs matching pattern x go
+        to server 1, all others go to server 2".
+        (A match is defined as:
+          1)  The NAPTR provides a replacement domain name
+          or
+          2) The regular expression matches the URN
+           )
+
+     -  When multiple RRs have the same "order", the client should use
+        the value of the preference field to select the next NAPTR to
+        consider. However, because of preferred protocols or services,
+        estimates of network distance and bandwidth, etc. clients may
+        use different criteria to sort the records.
+     -  If the lookup after a rewrite fails, clients are strongly
+        encouraged to report a failure, rather than backing up to pursue
+        other rewrite paths.
+     -  When a namespace is to be delegated among a set of resolvers,
+        regexps must be used. Each regexp appears in a separate NAPTR
+        RR.  Administrators should do as little delegation as possible,
+        because of limitations on the size of DNS responses.
+     -  Note that SRV RRs impose additional requirements on clients.
+
+Acknowledgments:
+=================
+
+   The editors would like to thank Keith Moore for all his consultations
+   during the development of this draft. We would also like to thank
+   Paul Vixie for his assistance in debugging our implementation, and
+   his answers on our questions. Finally, we would like to acknowledge
+   our enormous intellectual debt to the participants in the Knoxville
+   series of meetings, as well as to the participants in the URI and URN
+   working groups.
+
+References:
+===========
+
+   [1]  Sollins, Karen and Larry Masinter, "Functional Requirements
+        for Uniform Resource Names", RFC-1737, Dec. 1994.
+
+   [2]  The URN Implementors, Uniform Resource Names: A Progress Report,
+        http://www.dlib.org/dlib/february96/02arms.html, D-Lib Magazine,
+        February 1996.
+
+
+
+Daniel & Mealling             Experimental                     [Page 18]
+
+RFC 2168            Resolution of URIs Using the DNS           June 1997
+
+
+   [3]  Moats, Ryan, "URN Syntax", RFC-2141, May 1997.
+
+   [4]  Gulbrandsen, A. and P. Vixie, "A DNS RR for specifying
+        the location of services (DNS SRV)", RFC-2052, October 1996.
+
+   [5]  Daniel, Jr., Ron, "A Trivial Convention for using HTTP in URN
+        Resolution", RFC-2169, June 1997.
+
+   [6]  URN-WG, "URN Resolution Services", Work in Progress.
+
+   [7]  Moore, Keith,  Shirley Browne, Jason Cox, and Jonathan Gettler,
+        Resource Cataloging and Distribution System, Technical Report
+        CS-97-346, University of Tennessee, Knoxville, December 1996
+
+   [8]  Paul Vixie, personal communication.
+
+   [9]  Crocker, Dave H. "Standard for the Format of ARPA Internet Text
+        Messages", RFC-822, August 1982.
+
+   [10] Orth, Charles and Bill Arms; Handle Resolution Protocol
+        Specification, http://www.handle.net/docs/client_spec.html
+
+   [11] Williamson, S., M. Kosters, D. Blacka, J. Singh, K. Zeilstra,
+        "Referral Whois Protocol (RWhois)", RFC-2167, June 1997.
+
+   [12] Information Retrieval (Z39.50): Application Service Definition
+        and Protocol Specification, ANSI/NISO Z39.50-1995, July 1995.
+
+   [13] IEEE Standard for Information Technology - Portable Operating
+        System Interface (POSIX) - Part 2: Shell and Utilities (Vol. 1);
+        IEEE Std 1003.2-1992; The Institute of Electrical and
+        Electronics Engineers; New York; 1993. ISBN:1-55937-255-9
+
+   [14] Braden, R., "Requirements for Internet Hosts - Application and
+        and Support", RFC-1123, Oct. 1989.
+
+   [15] Sollins, Karen, "Requirements and a Framework for URN Resolution
+        Systems", November 1996, Work in Progress.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Daniel & Mealling             Experimental                     [Page 19]
+
+RFC 2168            Resolution of URIs Using the DNS           June 1997
+
+
+Security Considerations
+=======================
+
+   The use of "urn.net" as the registry for URN namespaces is subject to
+   denial of service attacks, as well as other DNS spoofing attacks. The
+   interactions with DNSSEC are currently being studied. It is expected
+   that NAPTR records will be signed with SIG records once the DNSSEC
+   work is deployed.
+
+   The rewrite rules make identifiers from other namespaces subject to
+   the same attacks as normal domain names. Since they have not been
+   easily resolvable before, this may or may not be considered a
+   problem.
+
+   Regular expressions should be checked for sanity, not blindly passed
+   to something like PERL.
+
+   This document has discussed a way of locating a resolver, but has not
+   discussed any detail of how the communication with the resolver takes
+   place. There are significant security considerations attached to the
+   communication with a resolver. Those considerations are outside the
+   scope of this document, and must be addressed by the specifications
+   for particular resolver communication protocols.
+
+Author Contact Information:
+===========================
+
+   Ron Daniel
+   Los Alamos National Laboratory
+   MS B287
+   Los Alamos, NM, USA, 87545
+   voice:  +1 505 665 0597
+   fax:    +1 505 665 4939
+   email:  rdaniel@lanl.gov
+
+
+   Michael Mealling
+   Network Solutions
+   505 Huntmar Park Drive
+   Herndon, VA  22070
+   voice: (703) 742-0400
+   fax: (703) 742-9552
+   email: michaelm@internic.net
+   URL: http://www.netsol.com/
+
+
+
+
+
+
+
+Daniel & Mealling             Experimental                     [Page 20]
+
diff --git a/doc/rfc/rfc2181.txt b/doc/rfc/rfc2181.txt
new file mode 100644
index 0000000..7899e1c
--- /dev/null
+++ b/doc/rfc/rfc2181.txt
@@ -0,0 +1,842 @@
+
+
+
+
+
+
+Network Working Group                                             R. Elz
+Request for Comments: 2181                       University of Melbourne
+Updates: 1034, 1035, 1123                                        R. Bush
+Category: Standards Track                                    RGnet, Inc.
+                                                               July 1997
+
+
+                Clarifications to the DNS Specification
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+1. Abstract
+
+   This document considers some areas that have been identified as
+   problems with the specification of the Domain Name System, and
+   proposes remedies for the defects identified.  Eight separate issues
+   are considered:
+
+     + IP packet header address usage from multi-homed servers,
+     + TTLs in sets of records with the same name, class, and type,
+     + correct handling of zone cuts,
+     + three minor issues concerning SOA records and their use,
+     + the precise definition of the Time to Live (TTL)
+     + Use of the TC (truncated) header bit
+     + the issue of what is an authoritative, or canonical, name,
+     + and the issue of what makes a valid DNS label.
+
+   The first six of these are areas where the correct behaviour has been
+   somewhat unclear, we seek to rectify that.  The other two are already
+   adequately specified, however the specifications seem to be sometimes
+   ignored.  We seek to reinforce the existing specifications.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Elz & Bush                  Standards Track                     [Page 1]
+
+RFC 2181        Clarifications to the DNS Specification        July 1997
+
+
+
+
+Contents
+
+    1  Abstract  ...................................................   1
+    2  Introduction  ...............................................   2
+    3  Terminology  ................................................   3
+    4  Server Reply Source Address Selection  ......................   3
+    5  Resource Record Sets  .......................................   4
+    6  Zone Cuts  ..................................................   8
+    7  SOA RRs  ....................................................  10
+    8  Time to Live (TTL)  .........................................  10
+    9  The TC (truncated) header bit  ..............................  11
+   10  Naming issues  ..............................................  11
+   11  Name syntax  ................................................  13
+   12  Security Considerations  ....................................  14
+   13  References  .................................................  14
+   14  Acknowledgements  ...........................................  15
+   15  Authors' Addresses  .........................................  15
+
+
+
+
+2. Introduction
+
+   Several problem areas in the Domain Name System specification
+   [RFC1034, RFC1035] have been noted through the years [RFC1123].  This
+   document addresses several additional problem areas.  The issues here
+   are independent.  Those issues are the question of which source
+   address a multi-homed DNS server should use when replying to a query,
+   the issue of differing TTLs for DNS records with the same label,
+   class and type, and the issue of canonical names, what they are, how
+   CNAME records relate, what names are legal in what parts of the DNS,
+   and what is the valid syntax of a DNS name.
+
+   Clarifications to the DNS specification to avoid these problems are
+   made in this memo.  A minor ambiguity in RFC1034 concerned with SOA
+   records is also corrected, as is one in the definition of the TTL
+   (Time To Live) and some possible confusion in use of the TC bit.
+
+
+
+
+
+
+
+
+
+
+
+
+Elz & Bush                  Standards Track                     [Page 2]
+
+RFC 2181        Clarifications to the DNS Specification        July 1997
+
+
+3. Terminology
+
+   This memo does not use the oft used expressions MUST, SHOULD, MAY, or
+   their negative forms.  In some sections it may seem that a
+   specification is worded mildly, and hence some may infer that the
+   specification is optional.  That is not correct.  Anywhere that this
+   memo suggests that some action should be carried out, or must be
+   carried out, or that some behaviour is acceptable, or not, that is to
+   be considered as a fundamental aspect of this specification,
+   regardless of the specific words used.  If some behaviour or action
+   is truly optional, that will be clearly specified by the text.
+
+4. Server Reply Source Address Selection
+
+   Most, if not all, DNS clients, expect the address from which a reply
+   is received to be the same address as that to which the query
+   eliciting the reply was sent.  This is true for servers acting as
+   clients for the purposes of recursive query resolution, as well as
+   simple resolver clients.  The address, along with the identifier (ID)
+   in the reply is used for disambiguating replies, and filtering
+   spurious responses.  This may, or may not, have been intended when
+   the DNS was designed, but is now a fact of life.
+
+   Some multi-homed hosts running DNS servers generate a reply using a
+   source address that is not the same as the destination address from
+   the client's request packet.  Such replies will be discarded by the
+   client because the source address of the reply does not match that of
+   a host to which the client sent the original request.  That is, it
+   appears to be an unsolicited response.
+
+4.1. UDP Source Address Selection
+
+   To avoid these problems, servers when responding to queries using UDP
+   must cause the reply to be sent with the source address field in the
+   IP header set to the address that was in the destination address
+   field of the IP header of the packet containing the query causing the
+   response.  If this would cause the response to be sent from an IP
+   address that is not permitted for this purpose, then the response may
+   be sent from any legal IP address allocated to the server.  That
+   address should be chosen to maximise the possibility that the client
+   will be able to use it for further queries.  Servers configured in
+   such a way that not all their addresses are equally reachable from
+   all potential clients need take particular care when responding to
+   queries sent to anycast, multicast, or similar, addresses.
+
+
+
+
+
+
+
+Elz & Bush                  Standards Track                     [Page 3]
+
+RFC 2181        Clarifications to the DNS Specification        July 1997
+
+
+4.2. Port Number Selection
+
+   Replies to all queries must be directed to the port from which they
+   were sent.  When queries are received via TCP this is an inherent
+   part of the transport protocol.  For queries received by UDP the
+   server must take note of the source port and use that as the
+   destination port in the response.  Replies should always be sent from
+   the port to which they were directed.  Except in extraordinary
+   circumstances, this will be the well known port assigned for DNS
+   queries [RFC1700].
+
+5. Resource Record Sets
+
+   Each DNS Resource Record (RR) has a label, class, type, and data.  It
+   is meaningless for two records to ever have label, class, type and
+   data all equal - servers should suppress such duplicates if
+   encountered.  It is however possible for most record types to exist
+   with the same label, class and type, but with different data.  Such a
+   group of records is hereby defined to be a Resource Record Set
+   (RRSet).
+
+5.1. Sending RRs from an RRSet
+
+   A query for a specific (or non-specific) label, class, and type, will
+   always return all records in the associated RRSet - whether that be
+   one or more RRs.  The response must be marked as "truncated" if the
+   entire RRSet will not fit in the response.
+
+5.2. TTLs of RRs in an RRSet
+
+   Resource Records also have a time to live (TTL).  It is possible for
+   the RRs in an RRSet to have different TTLs.  No uses for this have
+   been found that cannot be better accomplished in other ways.  This
+   can, however, cause partial replies (not marked "truncated") from a
+   caching server, where the TTLs for some but not all the RRs in the
+   RRSet have expired.
+
+   Consequently the use of differing TTLs in an RRSet is hereby
+   deprecated, the TTLs of all RRs in an RRSet must be the same.
+
+   Should a client receive a response containing RRs from an RRSet with
+   differing TTLs, it should treat this as an error.  If the RRSet
+   concerned is from a non-authoritative source for this data, the
+   client should simply ignore the RRSet, and if the values were
+   required, seek to acquire them from an authoritative source.  Clients
+   that are configured to send all queries to one, or more, particular
+   servers should treat those servers as authoritative for this purpose.
+   Should an authoritative source send such a malformed RRSet, the
+
+
+
+Elz & Bush                  Standards Track                     [Page 4]
+
+RFC 2181        Clarifications to the DNS Specification        July 1997
+
+
+   client should treat the RRs for all purposes as if all TTLs in the
+   RRSet had been set to the value of the lowest TTL in the RRSet.  In
+   no case may a server send an RRSet with TTLs not all equal.
+
+5.3. DNSSEC Special Cases
+
+   Two of the record types added by DNS Security (DNSSEC) [RFC2065]
+   require special attention when considering the formation of Resource
+   Record Sets.  Those are the SIG and NXT records.  It should be noted
+   that DNS Security is still very new, and there is, as yet, little
+   experience with it.  Readers should be prepared for the information
+   related to DNSSEC contained in this document to become outdated as
+   the DNS Security specification matures.
+
+5.3.1. SIG records and RRSets
+
+   A SIG record provides signature (validation) data for another RRSet
+   in the DNS.  Where a zone has been signed, every RRSet in the zone
+   will have had a SIG record associated with it.  The data type of the
+   RRSet is included in the data of the SIG RR, to indicate with which
+   particular RRSet this SIG record is associated.  Were the rules above
+   applied, whenever a SIG record was included with a response to
+   validate that response, the SIG records for all other RRSets
+   associated with the appropriate node would also need to be included.
+   In some cases, this could be a very large number of records, not
+   helped by their being rather large RRs.
+
+   Thus, it is specifically permitted for the authority section to
+   contain only those SIG RRs with the "type covered" field equal to the
+   type field of an answer being returned.  However, where SIG records
+   are being returned in the answer section, in response to a query for
+   SIG records, or a query for all records associated with a name
+   (type=ANY) the entire SIG RRSet must be included, as for any other RR
+   type.
+
+   Servers that receive responses containing SIG records in the
+   authority section, or (probably incorrectly) as additional data, must
+   understand that the entire RRSet has almost certainly not been
+   included.  Thus, they must not cache that SIG record in a way that
+   would permit it to be returned should a query for SIG records be
+   received at that server.  RFC2065 actually requires that SIG queries
+   be directed only to authoritative servers to avoid the problems that
+   could be caused here, and while servers exist that do not understand
+   the special properties of SIG records, this will remain necessary.
+   However, careful design of SIG record processing in new
+   implementations should permit this restriction to be relaxed in the
+   future, so resolvers do not need to treat SIG record queries
+   specially.
+
+
+
+Elz & Bush                  Standards Track                     [Page 5]
+
+RFC 2181        Clarifications to the DNS Specification        July 1997
+
+
+   It has been occasionally stated that a received request for a SIG
+   record should be forwarded to an authoritative server, rather than
+   being answered from data in the cache.  This is not necessary - a
+   server that has the knowledge of SIG as a special case for processing
+   this way would be better to correctly cache SIG records, taking into
+   account their characteristics.  Then the server can determine when it
+   is safe to reply from the cache, and when the answer is not available
+   and the query must be forwarded.
+
+5.3.2. NXT RRs
+
+   Next Resource Records (NXT) are even more peculiar.  There will only
+   ever be one NXT record in a zone for a particular label, so
+   superficially, the RRSet problem is trivial.  However, at a zone cut,
+   both the parent zone, and the child zone (superzone and subzone in
+   RFC2065 terminology) will have NXT records for the same name.  Those
+   two NXT records do not form an RRSet, even where both zones are
+   housed at the same server.  NXT RRSets always contain just a single
+   RR.  Where both NXT records are visible, two RRSets exist.  However,
+   servers are not required to treat this as a special case when
+   receiving NXT records in a response.  They may elect to notice the
+   existence of two different NXT RRSets, and treat that as they would
+   two different RRSets of any other type.  That is, cache one, and
+   ignore the other.  Security aware servers will need to correctly
+   process the NXT record in the received response though.
+
+5.4. Receiving RRSets
+
+   Servers must never merge RRs from a response with RRs in their cache
+   to form an RRSet.  If a response contains data that would form an
+   RRSet with data in a server's cache the server must either ignore the
+   RRs in the response, or discard the entire RRSet currently in the
+   cache, as appropriate.  Consequently the issue of TTLs varying
+   between the cache and a response does not cause concern, one will be
+   ignored.  That is, one of the data sets is always incorrect if the
+   data from an answer differs from the data in the cache.  The
+   challenge for the server is to determine which of the data sets is
+   correct, if one is, and retain that, while ignoring the other.  Note
+   that if a server receives an answer containing an RRSet that is
+   identical to that in its cache, with the possible exception of the
+   TTL value, it may, optionally, update the TTL in its cache with the
+   TTL of the received answer.  It should do this if the received answer
+   would be considered more authoritative (as discussed in the next
+   section) than the previously cached answer.
+
+
+
+
+
+
+
+Elz & Bush                  Standards Track                     [Page 6]
+
+RFC 2181        Clarifications to the DNS Specification        July 1997
+
+
+5.4.1. Ranking data
+
+   When considering whether to accept an RRSet in a reply, or retain an
+   RRSet already in its cache instead, a server should consider the
+   relative likely trustworthiness of the various data.  An
+   authoritative answer from a reply should replace cached data that had
+   been obtained from additional information in an earlier reply.
+   However additional information from a reply will be ignored if the
+   cache contains data from an authoritative answer or a zone file.
+
+   The accuracy of data available is assumed from its source.
+   Trustworthiness shall be, in order from most to least:
+
+     + Data from a primary zone file, other than glue data,
+     + Data from a zone transfer, other than glue,
+     + The authoritative data included in the answer section of an
+       authoritative reply.
+     + Data from the authority section of an authoritative answer,
+     + Glue from a primary zone, or glue from a zone transfer,
+     + Data from the answer section of a non-authoritative answer, and
+       non-authoritative data from the answer section of authoritative
+       answers,
+     + Additional information from an authoritative answer,
+       Data from the authority section of a non-authoritative answer,
+       Additional information from non-authoritative answers.
+
+   Note that the answer section of an authoritative answer normally
+   contains only authoritative data.  However when the name sought is an
+   alias (see section 10.1.1) only the record describing that alias is
+   necessarily authoritative.  Clients should assume that other records
+   may have come from the server's cache.  Where authoritative answers
+   are required, the client should query again, using the canonical name
+   associated with the alias.
+
+   Unauthenticated RRs received and cached from the least trustworthy of
+   those groupings, that is data from the additional data section, and
+   data from the authority section of a non-authoritative answer, should
+   not be cached in such a way that they would ever be returned as
+   answers to a received query.  They may be returned as additional
+   information where appropriate.  Ignoring this would allow the
+   trustworthiness of relatively untrustworthy data to be increased
+   without cause or excuse.
+
+   When DNS security [RFC2065] is in use, and an authenticated reply has
+   been received and verified, the data thus authenticated shall be
+   considered more trustworthy than unauthenticated data of the same
+   type.  Note that throughout this document, "authoritative" means a
+   reply with the AA bit set.  DNSSEC uses trusted chains of SIG and KEY
+
+
+
+Elz & Bush                  Standards Track                     [Page 7]
+
+RFC 2181        Clarifications to the DNS Specification        July 1997
+
+
+   records to determine the authenticity of data, the AA bit is almost
+   irrelevant.  However DNSSEC aware servers must still correctly set
+   the AA bit in responses to enable correct operation with servers that
+   are not security aware (almost all currently).
+
+   Note that, glue excluded, it is impossible for data from two
+   correctly configured primary zone files, two correctly configured
+   secondary zones (data from zone transfers) or data from correctly
+   configured primary and secondary zones to ever conflict.  Where glue
+   for the same name exists in multiple zones, and differs in value, the
+   nameserver should select data from a primary zone file in preference
+   to secondary, but otherwise may choose any single set of such data.
+   Choosing that which appears to come from a source nearer the
+   authoritative data source may make sense where that can be
+   determined.  Choosing primary data over secondary allows the source
+   of incorrect glue data to be discovered more readily, when a problem
+   with such data exists.  Where a server can detect from two zone files
+   that one or more are incorrectly configured, so as to create
+   conflicts, it should refuse to load the zones determined to be
+   erroneous, and issue suitable diagnostics.
+
+   "Glue" above includes any record in a zone file that is not properly
+   part of that zone, including nameserver records of delegated sub-
+   zones (NS records), address records that accompany those NS records
+   (A, AAAA, etc), and any other stray data that might appear.
+
+5.5. Sending RRSets (reprise)
+
+   A Resource Record Set should only be included once in any DNS reply.
+   It may occur in any of the Answer, Authority, or Additional
+   Information sections, as required.  However it should not be repeated
+   in the same, or any other, section, except where explicitly required
+   by a specification.  For example, an AXFR response requires the SOA
+   record (always an RRSet containing a single RR) be both the first and
+   last record of the reply.  Where duplicates are required this way,
+   the TTL transmitted in each case must be the same.
+
+6. Zone Cuts
+
+   The DNS tree is divided into "zones", which are collections of
+   domains that are treated as a unit for certain management purposes.
+   Zones are delimited by "zone cuts".  Each zone cut separates a
+   "child" zone (below the cut) from a "parent" zone (above the cut).
+   The domain name that appears at the top of a zone (just below the cut
+   that separates the zone from its parent) is called the zone's
+   "origin".  The name of the zone is the same as the name of the domain
+   at the zone's origin.  Each zone comprises that subset of the DNS
+   tree that is at or below the zone's origin, and that is above the
+
+
+
+Elz & Bush                  Standards Track                     [Page 8]
+
+RFC 2181        Clarifications to the DNS Specification        July 1997
+
+
+   cuts that separate the zone from its children (if any).  The
+   existence of a zone cut is indicated in the parent zone by the
+   existence of NS records specifying the origin of the child zone.  A
+   child zone does not contain any explicit reference to its parent.
+
+6.1. Zone authority
+
+   The authoritative servers for a zone are enumerated in the NS records
+   for the origin of the zone, which, along with a Start of Authority
+   (SOA) record are the mandatory records in every zone.  Such a server
+   is authoritative for all resource records in a zone that are not in
+   another zone.  The NS records that indicate a zone cut are the
+   property of the child zone created, as are any other records for the
+   origin of that child zone, or any sub-domains of it.  A server for a
+   zone should not return authoritative answers for queries related to
+   names in another zone, which includes the NS, and perhaps A, records
+   at a zone cut, unless it also happens to be a server for the other
+   zone.
+
+   Other than the DNSSEC cases mentioned immediately below, servers
+   should ignore data other than NS records, and necessary A records to
+   locate the servers listed in the NS records, that may happen to be
+   configured in a zone at a zone cut.
+
+6.2. DNSSEC issues
+
+   The DNS security mechanisms [RFC2065] complicate this somewhat, as
+   some of the new resource record types added are very unusual when
+   compared with other DNS RRs.  In particular the NXT ("next") RR type
+   contains information about which names exist in a zone, and hence
+   which do not, and thus must necessarily relate to the zone in which
+   it exists.  The same domain name may have different NXT records in
+   the parent zone and the child zone, and both are valid, and are not
+   an RRSet.  See also section 5.3.2.
+
+   Since NXT records are intended to be automatically generated, rather
+   than configured by DNS operators, servers may, but are not required
+   to, retain all differing NXT records they receive regardless of the
+   rules in section 5.4.
+
+   For a secure parent zone to securely indicate that a subzone is
+   insecure, DNSSEC requires that a KEY RR indicating that the subzone
+   is insecure, and the parent zone's authenticating SIG RR(s) be
+   present in the parent zone, as they by definition cannot be in the
+   subzone.  Where a subzone is secure, the KEY and SIG records will be
+   present, and authoritative, in that zone, but should also always be
+   present in the parent zone (if secure).
+
+
+
+
+Elz & Bush                  Standards Track                     [Page 9]
+
+RFC 2181        Clarifications to the DNS Specification        July 1997
+
+
+   Note that in none of these cases should a server for the parent zone,
+   not also being a server for the subzone, set the AA bit in any
+   response for a label at a zone cut.
+
+7. SOA RRs
+
+   Three minor issues concerning the Start of Zone of Authority (SOA)
+   Resource Record need some clarification.
+
+7.1. Placement of SOA RRs in authoritative answers
+
+   RFC1034, in section 3.7, indicates that the authority section of an
+   authoritative answer may contain the SOA record for the zone from
+   which the answer was obtained.  When discussing negative caching,
+   RFC1034 section 4.3.4 refers to this technique but mentions the
+   additional section of the response.  The former is correct, as is
+   implied by the example shown in section 6.2.5 of RFC1034.  SOA
+   records, if added, are to be placed in the authority section.
+
+7.2. TTLs on SOA RRs
+
+   It may be observed that in section 3.2.1 of RFC1035, which defines
+   the format of a Resource Record, that the definition of the TTL field
+   contains a throw away line which states that the TTL of an SOA record
+   should always be sent as zero to prevent caching.  This is mentioned
+   nowhere else, and has not generally been implemented.
+   Implementations should not assume that SOA records will have a TTL of
+   zero, nor are they required to send SOA records with a TTL of zero.
+
+7.3. The SOA.MNAME field
+
+   It is quite clear in the specifications, yet seems to have been
+   widely ignored, that the MNAME field of the SOA record should contain
+   the name of the primary (master) server for the zone identified by
+   the SOA.  It should not contain the name of the zone itself.  That
+   information would be useless, as to discover it, one needs to start
+   with the domain name of the SOA record - that is the name of the
+   zone.
+
+8. Time to Live (TTL)
+
+   The definition of values appropriate to the TTL field in STD 13 is
+   not as clear as it could be, with respect to how many significant
+   bits exist, and whether the value is signed or unsigned.  It is
+   hereby specified that a TTL value is an unsigned number, with a
+   minimum value of 0, and a maximum value of 2147483647.  That is, a
+   maximum of 2^31 - 1.  When transmitted, this value shall be encoded
+   in the less significant 31 bits of the 32 bit TTL field, with the
+
+
+
+Elz & Bush                  Standards Track                    [Page 10]
+
+RFC 2181        Clarifications to the DNS Specification        July 1997
+
+
+   most significant, or sign, bit set to zero.
+
+   Implementations should treat TTL values received with the most
+   significant bit set as if the entire value received was zero.
+
+   Implementations are always free to place an upper bound on any TTL
+   received, and treat any larger values as if they were that upper
+   bound.  The TTL specifies a maximum time to live, not a mandatory
+   time to live.
+
+9. The TC (truncated) header bit
+
+   The TC bit should be set in responses only when an RRSet is required
+   as a part of the response, but could not be included in its entirety.
+   The TC bit should not be set merely because some extra information
+   could have been included, but there was insufficient room.  This
+   includes the results of additional section processing.  In such cases
+   the entire RRSet that will not fit in the response should be omitted,
+   and the reply sent as is, with the TC bit clear.  If the recipient of
+   the reply needs the omitted data, it can construct a query for that
+   data and send that separately.
+
+   Where TC is set, the partial RRSet that would not completely fit may
+   be left in the response.  When a DNS client receives a reply with TC
+   set, it should ignore that response, and query again, using a
+   mechanism, such as a TCP connection, that will permit larger replies.
+
+10. Naming issues
+
+   It has sometimes been inferred from some sections of the DNS
+   specification [RFC1034, RFC1035] that a host, or perhaps an interface
+   of a host, is permitted exactly one authoritative, or official, name,
+   called the canonical name.  There is no such requirement in the DNS.
+
+10.1. CNAME resource records
+
+   The DNS CNAME ("canonical name") record exists to provide the
+   canonical name associated with an alias name.  There may be only one
+   such canonical name for any one alias.  That name should generally be
+   a name that exists elsewhere in the DNS, though there are some rare
+   applications for aliases with the accompanying canonical name
+   undefined in the DNS.  An alias name (label of a CNAME record) may,
+   if DNSSEC is in use, have SIG, NXT, and KEY RRs, but may have no
+   other data.  That is, for any label in the DNS (any domain name)
+   exactly one of the following is true:
+
+
+
+
+
+
+Elz & Bush                  Standards Track                    [Page 11]
+
+RFC 2181        Clarifications to the DNS Specification        July 1997
+
+
+     + one CNAME record exists, optionally accompanied by SIG, NXT, and
+       KEY RRs,
+     + one or more records exist, none being CNAME records,
+     + the name exists, but has no associated RRs of any type,
+     + the name does not exist at all.
+
+10.1.1. CNAME terminology
+
+   It has been traditional to refer to the label of a CNAME record as "a
+   CNAME".  This is unfortunate, as "CNAME" is an abbreviation of
+   "canonical name", and the label of a CNAME record is most certainly
+   not a canonical name.  It is, however, an entrenched usage.  Care
+   must therefore be taken to be very clear whether the label, or the
+   value (the canonical name) of a CNAME resource record is intended.
+   In this document, the label of a CNAME resource record will always be
+   referred to as an alias.
+
+10.2. PTR records
+
+   Confusion about canonical names has lead to a belief that a PTR
+   record should have exactly one RR in its RRSet.  This is incorrect,
+   the relevant section of RFC1034 (section 3.6.2) indicates that the
+   value of a PTR record should be a canonical name.  That is, it should
+   not be an alias.  There is no implication in that section that only
+   one PTR record is permitted for a name.  No such restriction should
+   be inferred.
+
+   Note that while the value of a PTR record must not be an alias, there
+   is no requirement that the process of resolving a PTR record not
+   encounter any aliases.  The label that is being looked up for a PTR
+   value might have a CNAME record.  That is, it might be an alias.  The
+   value of that CNAME RR, if not another alias, which it should not be,
+   will give the location where the PTR record is found.  That record
+   gives the result of the PTR type lookup.  This final result, the
+   value of the PTR RR, is the label which must not be an alias.
+
+10.3. MX and NS records
+
+   The domain name used as the value of a NS resource record, or part of
+   the value of a MX resource record must not be an alias.  Not only is
+   the specification clear on this point, but using an alias in either
+   of these positions neither works as well as might be hoped, nor well
+   fulfills the ambition that may have led to this approach.  This
+   domain name must have as its value one or more address records.
+   Currently those will be A records, however in the future other record
+   types giving addressing information may be acceptable.  It can also
+   have other RRs, but never a CNAME RR.
+
+
+
+
+Elz & Bush                  Standards Track                    [Page 12]
+
+RFC 2181        Clarifications to the DNS Specification        July 1997
+
+
+   Searching for either NS or MX records causes "additional section
+   processing" in which address records associated with the value of the
+   record sought are appended to the answer.  This helps avoid needless
+   extra queries that are easily anticipated when the first was made.
+
+   Additional section processing does not include CNAME records, let
+   alone the address records that may be associated with the canonical
+   name derived from the alias.  Thus, if an alias is used as the value
+   of an NS or MX record, no address will be returned with the NS or MX
+   value.  This can cause extra queries, and extra network burden, on
+   every query.  It is trivial for the DNS administrator to avoid this
+   by resolving the alias and placing the canonical name directly in the
+   affected record just once when it is updated or installed.  In some
+   particular hard cases the lack of the additional section address
+   records in the results of a NS lookup can cause the request to fail.
+
+11. Name syntax
+
+   Occasionally it is assumed that the Domain Name System serves only
+   the purpose of mapping Internet host names to data, and mapping
+   Internet addresses to host names.  This is not correct, the DNS is a
+   general (if somewhat limited) hierarchical database, and can store
+   almost any kind of data, for almost any purpose.
+
+   The DNS itself places only one restriction on the particular labels
+   that can be used to identify resource records.  That one restriction
+   relates to the length of the label and the full name.  The length of
+   any one label is limited to between 1 and 63 octets.  A full domain
+   name is limited to 255 octets (including the separators).  The zero
+   length full name is defined as representing the root of the DNS tree,
+   and is typically written and displayed as ".".  Those restrictions
+   aside, any binary string whatever can be used as the label of any
+   resource record.  Similarly, any binary string can serve as the value
+   of any record that includes a domain name as some or all of its value
+   (SOA, NS, MX, PTR, CNAME, and any others that may be added).
+   Implementations of the DNS protocols must not place any restrictions
+   on the labels that can be used.  In particular, DNS servers must not
+   refuse to serve a zone because it contains labels that might not be
+   acceptable to some DNS client programs.  A DNS server may be
+   configurable to issue warnings when loading, or even to refuse to
+   load, a primary zone containing labels that might be considered
+   questionable, however this should not happen by default.
+
+   Note however, that the various applications that make use of DNS data
+   can have restrictions imposed on what particular values are
+   acceptable in their environment.  For example, that any binary label
+   can have an MX record does not imply that any binary name can be used
+   as the host part of an e-mail address.  Clients of the DNS can impose
+
+
+
+Elz & Bush                  Standards Track                    [Page 13]
+
+RFC 2181        Clarifications to the DNS Specification        July 1997
+
+
+   whatever restrictions are appropriate to their circumstances on the
+   values they use as keys for DNS lookup requests, and on the values
+   returned by the DNS.  If the client has such restrictions, it is
+   solely responsible for validating the data from the DNS to ensure
+   that it conforms before it makes any use of that data.
+
+   See also [RFC1123] section 6.1.3.5.
+
+12. Security Considerations
+
+   This document does not consider security.
+
+   In particular, nothing in section 4 is any way related to, or useful
+   for, any security related purposes.
+
+   Section 5.4.1 is also not related to security.  Security of DNS data
+   will be obtained by the Secure DNS [RFC2065], which is mostly
+   orthogonal to this memo.
+
+   It is not believed that anything in this document adds to any
+   security issues that may exist with the DNS, nor does it do anything
+   to that will necessarily lessen them.  Correct implementation of the
+   clarifications in this document might play some small part in
+   limiting the spread of non-malicious bad data in the DNS, but only
+   DNSSEC can help with deliberate attempts to subvert DNS data.
+
+13. References
+
+   [RFC1034]   Mockapetris, P., "Domain Names - Concepts and Facilities",
+               STD 13, RFC 1034, November 1987.
+
+   [RFC1035]   Mockapetris, P., "Domain Names - Implementation and
+               Specification", STD 13, RFC 1035, November 1987.
+
+   [RFC1123]   Braden, R., "Requirements for Internet Hosts - application
+               and support", STD 3, RFC 1123, January 1989.
+
+   [RFC1700]   Reynolds, J., Postel, J., "Assigned Numbers",
+               STD 2, RFC 1700, October 1994.
+
+   [RFC2065]   Eastlake, D., Kaufman, C., "Domain Name System Security
+               Extensions", RFC 2065, January 1997.
+
+
+
+
+
+
+
+
+
+Elz & Bush                  Standards Track                    [Page 14]
+
+RFC 2181        Clarifications to the DNS Specification        July 1997
+
+
+14. Acknowledgements
+
+   This memo arose from discussions in the DNSIND working group of the
+   IETF in 1995 and 1996, the members of that working group are largely
+   responsible for the ideas captured herein.  Particular thanks to
+   Donald E. Eastlake, 3rd, and Olafur Gudmundsson, for help with the
+   DNSSEC issues in this document, and to John Gilmore for pointing out
+   where the clarifications were not necessarily clarifying.  Bob Halley
+   suggested clarifying the placement of SOA records in authoritative
+   answers, and provided the references.  Michael Patton, as usual, and
+   Mark Andrews, Alan Barrett and Stan Barber provided much assistance
+   with many details.  Josh Littlefield helped make sure that the
+   clarifications didn't cause problems in some irritating corner cases.
+
+15. Authors' Addresses
+
+   Robert Elz
+   Computer Science
+   University of Melbourne
+   Parkville, Victoria, 3052
+   Australia.
+
+   EMail: kre@munnari.OZ.AU
+
+
+   Randy Bush
+   RGnet, Inc.
+   5147 Crystal Springs Drive NE
+   Bainbridge Island, Washington,  98110
+   United States.
+
+   EMail: randy@psg.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Elz & Bush                  Standards Track                    [Page 15]
diff --git a/doc/rfc/rfc2230.txt b/doc/rfc/rfc2230.txt
new file mode 100644
index 0000000..03995fe
--- /dev/null
+++ b/doc/rfc/rfc2230.txt
@@ -0,0 +1,619 @@
+
+
+
+
+
+
+Network Working Group                                         R. Atkinson
+Request for Comments: 2230                                            NRL
+Category: Informational                                     November 1997
+
+
+               Key Exchange Delegation Record for the DNS
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (1997).  All Rights Reserved.
+
+ABSTRACT
+
+   This note describes a mechanism whereby authorisation for one node to
+   act as key exchanger for a second node is delegated and made
+   available via the Secure DNS.  This mechanism is intended to be used
+   only with the Secure DNS.  It can be used with several security
+   services.  For example, a system seeking to use IP Security [RFC-
+   1825, RFC-1826, RFC-1827] to protect IP packets for a given
+   destination can use this mechanism to determine the set of authorised
+   remote key exchanger systems for that destination.
+
+1. INTRODUCTION
+
+
+   The Domain Name System (DNS) is the standard way that Internet nodes
+   locate information about addresses, mail exchangers, and other data
+   relating to remote Internet nodes. [RFC-1035, RFC-1034] More
+   recently, Eastlake and Kaufman have defined standards-track security
+   extensions to the DNS. [RFC-2065] These security extensions can be
+   used to authenticate signed DNS data records and can also be used to
+   store signed public keys in the DNS.
+
+   The KX record is useful in providing an authenticatible method of
+   delegating authorisation for one node to provide key exchange
+   services on behalf of one or more, possibly different, nodes.  This
+   note specifies the syntax and semantics of the KX record, which is
+   currently in limited deployment in certain IP-based networks.  The
+
+
+
+
+
+
+
+Atkinson                     Informational                      [Page 1]
+
+RFC 2230           DNS Key Exchange Delegation Record      November 1997
+
+
+   reader is assumed to be familiar with the basics of DNS, including
+   familiarity with [RFC-1035, RFC-1034].  This document is not on the
+   IETF standards-track and does not specify any level of standard.
+   This document merely provides information for the Internet community.
+
+1.1 Identity Terminology
+
+   This document relies upon the concept of "identity domination".  This
+   concept might be new to the reader and so is explained in this
+   section.  The subject of endpoint naming for security associations
+   has historically been somewhat contentious.  This document takes no
+   position on what forms of identity should be used.  In a network,
+   there are several forms of identity that are possible.
+
+   For example, IP Security has defined notions of identity that
+   include: IP Address, IP Address Range, Connection ID, Fully-Qualified
+   Domain Name (FQDN), and User with Fully Qualified Domain Name (USER
+   FQDN).
+
+   A USER FQDN identity dominates a FQDN identity.  A FQDN identity in
+   turn dominates an IP Address identity.  Similarly, a Connection ID
+   dominates an IP Address identity.  An IP Address Range dominates each
+   IP Address identity for each IP address within that IP address range.
+   Also, for completeness, an IP Address identity is considered to
+   dominate itself.
+
+2. APPROACH
+
+   This document specifies a new kind of DNS Resource Record (RR), known
+   as the Key Exchanger (KX) record.  A Key Exchanger Record has the
+   mnemonic "KX" and the type code of 36.  Each KX record is associated
+   with a fully-qualified domain name.  The KX record is modeled on the
+   MX record described in [Part86]. Any given domain, subdomain, or host
+   entry in the DNS might have a KX record.
+
+2.1 IPsec Examples
+
+   In these two examples, let S be the originating node and let D be the
+   destination node.  S2 is another node on the same subnet as S.  D2 is
+   another node on the same subnet as D.  R1 and R2 are IPsec-capable
+   routers.  The path from S to D goes via first R1 and later R2.  The
+   return path from D to S goes via first R2 and later R1.
+
+   IETF-standard IP Security uses unidirectional Security Associations
+   [RFC-1825].  Therefore, a typical IP session will use a pair of
+   related Security Associations, one in each direction.  The examples
+   below talk about how to setup an example Security Association, but in
+   practice a pair of matched Security Associations will normally be
+
+
+
+Atkinson                     Informational                      [Page 2]
+
+RFC 2230           DNS Key Exchange Delegation Record      November 1997
+
+
+   used.
+
+2.1.1 Subnet-to-Subnet Example
+
+   If neither S nor D implements IPsec, security can still be provided
+   between R1 and R2 by building a secure tunnel.  This can use either
+   AH or ESP.
+
+       S ---+                                          +----D
+            |                                          |
+            +- R1 -----[zero or more routers]-------R2-+
+            |                                          |
+       S2---+                                          +----D2
+
+       Figure 1:  Network Diagram for Subnet-to-Subnet Example
+
+   In this example, R1 makes the policy decision to provide the IPsec
+   service for traffic from R1 destined for R2.  Once R1 has decided
+   that the packet from S to D should be protected, it performs a secure
+   DNS lookup for the records associated with domain D.  If R1 only
+   knows the IP address for D, then a secure reverse DNS lookup will be
+   necessary to determine the domain D, before that forward secure DNS
+   lookup for records associated with domain D.  If these DNS records of
+   domain D include a KX record for the IPsec service, then R1 knows
+   which set of nodes are authorised key exchanger nodes for the
+   destination D.
+
+   In this example, let there be at least one KX record for D and let
+   the most preferred KX record for D point at R2.  R1 then selects a
+   key exchanger (in this example, R2) for D from the list obtained from
+   the secure DNS.  Then R1 initiates a key management session with that
+   key exchanger (in this example, R2) to setup an IPsec Security
+   Association between R1 and D.  In this example, R1 knows (either by
+   seeing an outbound packet arriving from S destined to D or via other
+   methods) that S will be sending traffic to D.  In this example R1's
+   policy requires that traffic from S to D should be segregated at
+   least on a host-to-host basis, so R1 desires an IPsec Security
+   Association with source identity that dominates S, proxy identity
+   that dominates R1, and destination identity that dominates R2.
+
+   In turn, R2 is able to authenticate the delegation of Key Exchanger
+   authorisation for target S to R1 by making an authenticated forward
+   DNS lookup for KX records associated with S and verifying that at
+   least one such record points to R1.  The identity S is typically
+   given to R2 as part of the key management process between R1 and R2.
+
+
+
+
+
+
+Atkinson                     Informational                      [Page 3]
+
+RFC 2230           DNS Key Exchange Delegation Record      November 1997
+
+
+   If D initially only knows the IP address of S, then it will need to
+   perform a secure reverse DNS lookup to obtain the fully-qualified
+   domain name for S prior to that secure forward DNS lookup.
+
+   If R2 does not receive an authenticated DNS response indicating that
+   R1 is an authorised key exchanger for S, then D will not accept the
+   SA negotiation from R1 on behalf of identity S.
+
+   If the proposed IPsec Security Association is acceptable to both R1
+   and R2, each of which might have separate policies, then they create
+   that IPsec Security Association via Key Management.
+
+   Note that for unicast traffic, Key Management will typically also
+   setup a separate (but related) IPsec Security Association for the
+   return traffic.  That return IPsec Security Association will have
+   equivalent identities.  In this example, that return IPsec Security
+   Association will have a source identity that dominates D, a proxy
+   identity that dominates R2, and a destination identity that dominates
+   R1.
+
+   Once the IPsec Security Association has been created, then R1 uses it
+   to protect traffic from S destined for D via a secure tunnel that
+   originates at R1 and terminates at R2.  For the case of unicast, R2
+   will use the return IPsec Security Association to protect traffic
+   from D destined for S via a secure tunnel that originates at R2 and
+   terminates at R1.
+
+2.1.2 Subnet-to-Host Example
+
+   Consider the case where D and R1 implement IPsec, but S does not
+   implement IPsec, which is an interesting variation on the previous
+   example.  This example is shown in Figure 2 below.
+
+       S ---+
+            |
+            +- R1 -----[zero or more routers]-------D
+            |
+       S2---+
+
+       Figure 2:  Network Diagram for Subnet-to-Host Example
+
+   In this example, R1 makes the policy decision that IP Security is
+   needed for the packet travelling from S to D.  Then, R1 performs the
+   secure DNS lookup for D and determines that D is its own key
+   exchanger, either from the existence of a KX record for D pointing to
+   D or from an authenticated DNS response indicating that no KX record
+   exists for D.  If R1 does not initially know the domain name of D,
+   then prior to the above forward secure DNS lookup, R1 performs a
+
+
+
+Atkinson                     Informational                      [Page 4]
+
+RFC 2230           DNS Key Exchange Delegation Record      November 1997
+
+
+   secure reverse DNS lookup on the IP address of D to determine the
+   fully-qualified domain name for that IP address.  R1 then initiates
+   key management with D to create an IPsec Security Association on
+   behalf of S.
+
+   In turn, D can verify that R1 is authorised to create an IPsec
+   Security Association on behalf of S by performing a DNS KX record
+   lookup for target S.  R1 usually provides identity S to D via key
+   management.  If D only has the IP address of S, then D will need to
+   perform a secure reverse lookup on the IP address of S to determine
+   domain name S prior to the secure forward DNS lookup on S to locate
+   the KX records for S.
+
+   If D does not receive an authenticated DNS response indicating that
+   R1 is an authorised key exchanger for S, then D will not accept the
+   SA negotiation from R1 on behalf of identity S.
+
+   If the IPsec Security Association is successfully established between
+   R1 and D, that IPsec Security Association has a source identity that
+   dominates S's IP address, a proxy identity that dominates R1's IP
+   address, and a destination identity that dominates D's IP address.
+
+   Finally, R1 begins providing the security service for packets from S
+   that transit R1 destined for D.  When D receives such packets, D
+   examines the SA information during IPsec input processing and sees
+   that R1's address is listed as valid proxy address for that SA and
+   that S is the source address for that SA.  Hence, D knows at input
+   processing time that R1 is authorised to provide security on behalf
+   of S.  Therefore packets coming from R1 with valid IP security that
+   claim to be from S are trusted by D to have really come from S.
+
+2.1.3 Host to Subnet Example
+
+   Now consider the above case from D's perspective (i.e. where D is
+   sending IP packets to S).  This variant is sometimes known as the
+   Mobile Host or "roadwarrier" case. The same basic concepts apply, but
+   the details are covered here in hope of improved clarity.
+
+       S ---+
+            |
+            +- R1 -----[zero or more routers]-------D
+            |
+       S2---+
+
+       Figure 3:  Network Diagram for Host-to-Subnet Example
+
+
+
+
+
+
+Atkinson                     Informational                      [Page 5]
+
+RFC 2230           DNS Key Exchange Delegation Record      November 1997
+
+
+   In this example, D makes the policy decision that IP Security is
+   needed for the packets from D to S.  Then D performs the secure DNS
+   lookup for S and discovers that a KX record for S exists and points
+   at R1.  If D only has the IP address of S, then it performs a secure
+   reverse DNS lookup on the IP address of S prior to the forward secure
+   DNS lookup for S.
+
+   D then initiates key management with R1, where R1 is acting on behalf
+   of S, to create an appropriate Security Association.  Because D is
+   acting as its own key exchanger, R1 does not need to perform a secure
+   DNS lookup for KX records associated with D.
+
+   D and R1 then create an appropriate IPsec Security Security
+   Association.  This IPsec Security Association is setup as a secure
+   tunnel with a source identity that dominates D's IP Address and a
+   destination identity that dominates R1's IP Address.  Because D
+   performs IPsec for itself, no proxy identity is needed in this IPsec
+   Security Association.  If the proxy identity is non-null in this
+   situation, then the proxy identity must dominate D's IP Address.
+
+   Finally, D sends secured IP packets to R1.  R1 receives those
+   packets, provides IPsec input processing (including appropriate
+   inner/outer IP address validation), and forwards valid packets along
+   to S.
+
+2.2 Other Examples
+
+   This mechanism can be extended for use with other services as well.
+   To give some insight into other possible uses, this section discusses
+   use of KX records in environments using a Key Distribution Center
+   (KDC), such as Kerberos [KN93], and a possible use of KX records in
+   conjunction with mobile nodes accessing the network via a dialup
+   service.
+
+2.2.1 KDC Examples
+
+   This example considers the situation of a destination node
+   implementing IPsec that can only obtain its Security Association
+   information from a Key Distribution Center (KDC).  Let the KDC
+   implement both the KDC protocol and also a non-KDC key management
+   protocol (e.g. ISAKMP).  In such a case, each client node of the KDC
+   might have its own KX record pointing at the KDC so that nodes not
+   implementing the KDC protocol can still create Security Associations
+   with each of the client nodes of the KDC.
+
+   In the event the session initiator were not using the KDC but the
+   session target was an IPsec node that only used the KDC, the
+   initiator would find the KX record for the target pointing at the
+
+
+
+Atkinson                     Informational                      [Page 6]
+
+RFC 2230           DNS Key Exchange Delegation Record      November 1997
+
+
+   KDC.  Then, the external key management exchange (e.g. ISAKMP) would
+   be between the initiator and the KDC.  Then the KDC would distribute
+   the IPsec SA to the KDC-only IPsec node using the KDC.  The IPsec
+   traffic itself could travel directly between the initiator and the
+   destination node.
+
+   In the event the initiator node could only use the KDC and the target
+   were not using the KDC, the initiator would send its request for a
+   key to the KDC.  The KDC would then initiate an external key
+   management exchange (e.g. ISAKMP) with a node that the target's KX
+   record(s) pointed to, on behalf of the initiator node.
+
+   The target node could verify that the KDC were allowed to proxy for
+   the initiator node by looking up the KX records for the initiator
+   node and finding a KX record for the initiator that listed the KDC.
+
+   Then the external key exchange would be performed between the KDC and
+   the target node.  Then the KDC would distribute the resulting IPsec
+   Security Association to the initiator.  Again, IPsec traffic itself
+   could travel directly between the initiator and the destination.
+
+2.2.2 Dial-Up Host Example
+
+   This example outlines a possible use of KX records with mobile hosts
+   that dial into the network via PPP and are dynamically assigned an IP
+   address and domain-name at dial-in time.
+
+   Consider the situation where each mobile node is dynamically assigned
+   both a domain name and an IP address at the time that node dials into
+   the network.  Let the policy require that each mobile node act as its
+   own Key Exchanger.  In this case, it is important that dial-in nodes
+   use addresses from one or more well known IP subnets or address pools
+   dedicated to dial-in access.  If that is true, then no KX record or
+   other action is needed to ensure that each node will act as its own
+   Key Exchanger because lack of a KX record indicates that the node is
+   its own Key Exchanger.
+
+   Consider the situation where the mobile node's domain name remains
+   constant but its IP address changes.  Let the policy require that
+   each mobile node act as its own Key Exchanger.  In this case, there
+   might be operational problems when another node attempts to perform a
+   secure reverse DNS lookup on the IP address to determine the
+   corresponding domain name.  The authenticated DNS binding (in the
+   form of a PTR record) between the mobile node's currently assigned IP
+   address and its permanent domain name will need to be securely
+   updated each time the node is assigned a new IP address.  There are
+   no mechanisms for accomplishing this that are both IETF-standard and
+   widely deployed as of the time this note was written.  Use of Dynamic
+
+
+
+Atkinson                     Informational                      [Page 7]
+
+RFC 2230           DNS Key Exchange Delegation Record      November 1997
+
+
+   DNS Update without authentication is a significant security risk and
+   hence is not recommended for this situation.
+
+3. SYNTAX OF KX RECORD
+
+   A KX record has the DNS TYPE of "KX" and a numeric value of 36.  A KX
+   record is a member of the Internet ("IN") CLASS in the DNS.  Each KX
+   record is associated with a <domain-name> entry in the DNS.  A KX
+   record has the following textual syntax:
+
+        <domain-name>  IN  KX  <preference> <domain-name>
+
+   For this description, let the <domain-name> item to the left of the
+   "KX" string be called <domain-name 1> and the <domain-name> item to
+   the right of the "KX" string be called <domain-name 2>.  <preference>
+   is a non-negative integer.
+
+   Internet nodes about to initiate a key exchange with <domain-name 1>
+   should instead contact <domain-name 2> to initiate the key exchange
+   for a security service between the initiator and <domain-name 2>.  If
+   more than one KX record exists for <domain-name 1>, then the
+   <preference> field is used to indicate preference among the systems
+   delegated to.  Lower values are preferred over higher values.  The
+   <domain-name 2> is authorised to provide key exchange services on
+   behalf of <domain-name 1>.  The <domain-name 2> MUST have a CNAME
+   record, an A record, or an AAAA record associated with it.
+
+3.1 KX RDATA format
+
+   The KX DNS record has the following RDATA format:
+
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    |                  PREFERENCE                   |
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    /                   EXCHANGER                   /
+    /                                               /
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+   where:
+
+   PREFERENCE      A 16 bit non-negative integer which specifies the
+                   preference given to this RR among other KX records
+                   at the same owner.  Lower values are preferred.
+
+   EXCHANGER       A <domain-name> which specifies a host willing to
+                   act as a mail exchange for the owner name.
+
+
+
+
+
+Atkinson                     Informational                      [Page 8]
+
+RFC 2230           DNS Key Exchange Delegation Record      November 1997
+
+
+   KX records MUST cause type A additional section processing for the
+   host specified by EXCHANGER.  In the event that the host processing
+   the DNS transaction supports IPv6, KX records MUST also cause type
+   AAAA additional section processing.
+
+   The KX RDATA field MUST NOT be compressed.
+
+4. SECURITY CONSIDERATIONS
+
+   KX records MUST always be signed using the method(s) defined by the
+   DNS Security extensions specified in [RFC-2065].  All unsigned KX
+   records MUST be ignored because of the security vulnerability caused
+   by assuming that unsigned records are valid.  All signed KX records
+   whose signatures do not correctly validate MUST be ignored because of
+   the potential security vulnerability in trusting an invalid KX
+   record.
+
+   KX records MUST be ignored by systems not implementing Secure DNS
+   because such systems have no mechanism to authenticate the KX record.
+
+   If a node does not have a permanent DNS entry and some form of
+   Dynamic DNS Update is in use, then those dynamic DNS updates MUST be
+   fully authenticated to prevent an adversary from injecting false DNS
+   records (especially the KX, A, and PTR records) into the Domain Name
+   System.  If false records were inserted into the DNS without being
+   signed by the Secure DNS mechanisms, then a denial-of-service attack
+   results.  If false records were inserted into the DNS and were
+   (erroneously) signed by the signing authority, then an active attack
+   results.
+
+   Myriad serious security vulnerabilities can arise if the restrictions
+   throuhout this document are not strictly adhered to.  Implementers
+   should carefully consider the openly published issues relating to DNS
+   security [Bell95,Vixie95] as they build their implementations.
+   Readers should also consider the security considerations discussed in
+   the DNS Security Extensions document [RFC-2065].
+
+5. REFERENCES
+
+
+   [RFC-1825]  Atkinson, R., "IP Authentication Header", RFC 1826,
+               August 1995.
+
+   [RFC-1827]  Atkinson, R., "IP Encapsulating Security Payload",
+               RFC 1827, August 1995.
+
+
+
+
+
+
+Atkinson                     Informational                      [Page 9]
+
+RFC 2230           DNS Key Exchange Delegation Record      November 1997
+
+
+   [Bell95] Bellovin, S., "Using the Domain Name System for System
+            Break-ins", Proceedings of 5th USENIX UNIX Security
+            Symposium, USENIX Association, Berkeley, CA, June 1995.
+            ftp://ftp.research.att.com/dist/smb/dnshack.ps
+
+   [RFC-2065]  Eastlake, D., and C. Kaufman, "Domain Name System
+               Security Extensions", RFC 2065, January 1997.
+
+   [RFC-1510]  Kohl J., and C. Neuman, "The Kerberos Network
+               Authentication Service", RFC 1510, September 1993.
+
+   [RFC-1035]  Mockapetris, P., "Domain names - implementation and
+               specification", STD 13, RFC 1035, November 1987.
+
+   [RFC-1034]  Mockapetris, P., "Domain names - concepts and
+               facilities", STD 13, RFC 1034, November 1987.
+
+   [Vixie95] P. Vixie, "DNS and BIND Security Issues", Proceedings of
+             the 5th USENIX UNIX Security Symposium, USENIX
+             Association, Berkeley, CA, June 1995.
+             ftp://ftp.vix.com/pri/vixie/bindsec.psf
+
+ACKNOWLEDGEMENTS
+
+   Development of this DNS record was primarily performed during 1993
+   through 1995.  The author's work on this was sponsored jointly by the
+   Computing Systems Technology Office (CSTO) of the Advanced Research
+   Projects Agency (ARPA) and by the Information Security Program Office
+   (PD71E), Space & Naval Warface Systems Command (SPAWAR).  In that
+   era, Dave Mihelcic and others provided detailed review and
+   constructive feedback.  More recently, Bob Moscowitz and Todd Welch
+   provided detailed review and constructive feedback of a work in
+   progress version of this document.
+
+AUTHOR'S ADDRESS
+
+   Randall Atkinson
+   Code 5544
+   Naval Research Laboratory
+   4555 Overlook Avenue, SW
+   Washington, DC 20375-5337
+
+   Phone: (DSN) 354-8590
+   EMail: atkinson@itd.nrl.navy.mil
+
+
+
+
+
+
+
+Atkinson                     Informational                     [Page 10]
+
+RFC 2230           DNS Key Exchange Delegation Record      November 1997
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (1997).  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 implmentation may be prepared, copied, published
+   andand 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 Standards process must be
+   followed, or as required to translate it into 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Atkinson                     Informational                     [Page 11]
+
diff --git a/doc/rfc/rfc2308.txt b/doc/rfc/rfc2308.txt
new file mode 100644
index 0000000..9123a95
--- /dev/null
+++ b/doc/rfc/rfc2308.txt
@@ -0,0 +1,1067 @@
+
+
+
+
+
+
+Network Working Group                                          M. Andrews
+Request for Comments: 2308                                          CSIRO
+Updates: 1034, 1035                                            March 1998
+Category: Standards Track
+
+
+              Negative Caching of DNS Queries (DNS NCACHE)
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (1998).  All Rights Reserved.
+
+Abstract
+
+   [RFC1034] provided a description of how to cache negative responses.
+   It however had a fundamental flaw in that it did not allow a name
+   server to hand out those cached responses to other resolvers, thereby
+   greatly reducing the effect of the caching.  This document addresses
+   issues raise in the light of experience and replaces [RFC1034 Section
+   4.3.4].
+
+   Negative caching was an optional part of the DNS specification and
+   deals with the caching of the non-existence of an RRset [RFC2181] or
+   domain name.
+
+   Negative caching is useful as it reduces the response time for
+   negative answers.  It also reduces the number of messages that have
+   to be sent between resolvers and name servers hence overall network
+   traffic.  A large proportion of DNS traffic on the Internet could be
+   eliminated if all resolvers implemented negative caching.  With this
+   in mind negative caching should no longer be seen as an optional part
+   of a DNS resolver.
+
+
+
+
+
+
+
+
+
+
+
+Andrews                     Standards Track                     [Page 1]
+
+RFC 2308                       DNS NCACHE                     March 1998
+
+
+1 - Terminology
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC2119].
+
+   "Negative caching" - the storage of knowledge that something does not
+   exist.  We can store the knowledge that a record has a particular
+   value.  We can also do the reverse, that is, to store the knowledge
+   that a record does not exist.  It is the storage of knowledge that
+   something does not exist, cannot or does not give an answer that we
+   call negative caching.
+
+   "QNAME" - the name in the query section of an answer, or where this
+   resolves to a CNAME, or CNAME chain, the data field of the last
+   CNAME.  The last CNAME in this sense is that which contains a value
+   which does not resolve to another CNAME.  Implementations should note
+   that including CNAME records in responses in order, so that the first
+   has the label from the query section, and then each in sequence has
+   the label from the data section of the previous (where more than one
+   CNAME is needed) allows the sequence to be processed in one pass, and
+   considerably eases the task of the receiver.  Other relevant records
+   (such as SIG RRs [RFC2065]) can be interspersed amongst the CNAMEs.
+
+   "NXDOMAIN" - an alternate expression for the "Name Error" RCODE as
+   described in [RFC1035 Section 4.1.1] and the two terms are used
+   interchangeably in this document.
+
+   "NODATA" - a pseudo RCODE which indicates that the name is valid, for
+   the given class, but are no records of the given type.  A NODATA
+   response has to be inferred from the answer.
+
+   "FORWARDER" - a nameserver used to resolve queries instead of
+   directly using the authoritative nameserver chain.  The forwarder
+   typically either has better access to the internet, or maintains a
+   bigger cache which may be shared amongst many resolvers.  How a
+   server is identified as a FORWARDER, or knows it is a FORWARDER is
+   outside the scope of this document.  However if you are being used as
+   a forwarder the query will have the recursion desired flag set.
+
+   An understanding of [RFC1034], [RFC1035] and [RFC2065] is expected
+   when reading this document.
+
+
+
+
+
+
+
+
+
+Andrews                     Standards Track                     [Page 2]
+
+RFC 2308                       DNS NCACHE                     March 1998
+
+
+2 - Negative Responses
+
+   The most common negative responses indicate that a particular RRset
+   does not exist in the DNS.  The first sections of this document deal
+   with this case.  Other negative responses can indicate failures of a
+   nameserver, those are dealt with in section 7 (Other Negative
+   Responses).
+
+   A negative response is indicated by one of the following conditions:
+
+2.1 - Name Error
+
+   Name errors (NXDOMAIN) are indicated by the presence of "Name Error"
+   in the RCODE field.  In this case the domain referred to by the QNAME
+   does not exist.  Note: the answer section may have SIG and CNAME RRs
+   and the authority section may have SOA, NXT [RFC2065] and SIG RRsets.
+
+   It is possible to distinguish between a referral and a NXDOMAIN
+   response by the presense of NXDOMAIN in the RCODE regardless of the
+   presence of NS or SOA records in the authority section.
+
+   NXDOMAIN responses can be categorised into four types by the contents
+   of the authority section.  These are shown below along with a
+   referral for comparison.  Fields not mentioned are not important in
+   terms of the examples.
+
+           NXDOMAIN RESPONSE: TYPE 1.
+
+           Header:
+               RDCODE=NXDOMAIN
+           Query:
+               AN.EXAMPLE. A
+           Answer:
+               AN.EXAMPLE. CNAME TRIPPLE.XX.
+           Authority:
+               XX. SOA NS1.XX. HOSTMASTER.NS1.XX. ....
+               XX. NS NS1.XX.
+               XX. NS NS2.XX.
+           Additional:
+               NS1.XX. A 127.0.0.2
+               NS2.XX. A 127.0.0.3
+
+           NXDOMAIN RESPONSE: TYPE 2.
+
+           Header:
+               RDCODE=NXDOMAIN
+           Query:
+               AN.EXAMPLE. A
+
+
+
+Andrews                     Standards Track                     [Page 3]
+
+RFC 2308                       DNS NCACHE                     March 1998
+
+
+           Answer:
+               AN.EXAMPLE. CNAME TRIPPLE.XX.
+           Authority:
+               XX. SOA NS1.XX. HOSTMASTER.NS1.XX. ....
+           Additional:
+               <empty>
+
+           NXDOMAIN RESPONSE: TYPE 3.
+
+           Header:
+               RDCODE=NXDOMAIN
+           Query:
+               AN.EXAMPLE. A
+           Answer:
+               AN.EXAMPLE. CNAME TRIPPLE.XX.
+           Authority:
+               <empty>
+           Additional:
+               <empty>
+
+           NXDOMAIN RESPONSE: TYPE 4
+
+           Header:
+               RDCODE=NXDOMAIN
+           Query:
+               AN.EXAMPLE. A
+           Answer:
+               AN.EXAMPLE. CNAME TRIPPLE.XX.
+           Authority:
+               XX. NS NS1.XX.
+               XX. NS NS2.XX.
+           Additional:
+               NS1.XX. A 127.0.0.2
+               NS2.XX. A 127.0.0.3
+
+           REFERRAL RESPONSE.
+
+           Header:
+               RDCODE=NOERROR
+           Query:
+               AN.EXAMPLE. A
+           Answer:
+               AN.EXAMPLE. CNAME TRIPPLE.XX.
+           Authority:
+               XX. NS NS1.XX.
+               XX. NS NS2.XX.
+           Additional:
+               NS1.XX. A 127.0.0.2
+
+
+
+Andrews                     Standards Track                     [Page 4]
+
+RFC 2308                       DNS NCACHE                     March 1998
+
+
+               NS2.XX. A 127.0.0.3
+
+   Note, in the four examples of NXDOMAIN responses, it is known that
+   the name "AN.EXAMPLE." exists, and has as its value a CNAME record.
+   The NXDOMAIN refers to "TRIPPLE.XX", which is then known not to
+   exist.  On the other hand, in the referral example, it is shown that
+   "AN.EXAMPLE" exists, and has a CNAME RR as its value, but nothing is
+   known one way or the other about the existence of "TRIPPLE.XX", other
+   than that "NS1.XX" or "NS2.XX" can be consulted as the next step in
+   obtaining information about it.
+
+   Where no CNAME records appear, the NXDOMAIN response refers to the
+   name in the label of the RR in the question section.
+
+2.1.1 Special Handling of Name Error
+
+   This section deals with errors encountered when implementing negative
+   caching of NXDOMAIN responses.
+
+   There are a large number of resolvers currently in existence that
+   fail to correctly detect and process all forms of NXDOMAIN response.
+   Some resolvers treat a TYPE 1 NXDOMAIN response as a referral.  To
+   alleviate this problem it is recommended that servers that are
+   authoritative for the NXDOMAIN response only send TYPE 2 NXDOMAIN
+   responses, that is the authority section contains a SOA record and no
+   NS records.  If a non- authoritative server sends a type 1 NXDOMAIN
+   response to one of these old resolvers, the result will be an
+   unnecessary query to an authoritative server.  This is undesirable,
+   but not fatal except when the server is being used a FORWARDER.  If
+   however the resolver is using the server as a FORWARDER to such a
+   resolver it will be necessary to disable the sending of TYPE 1
+   NXDOMAIN response to it, use TYPE 2 NXDOMAIN instead.
+
+   Some resolvers incorrectly continue processing if the authoritative
+   answer flag is not set, looping until the query retry threshold is
+   exceeded and then returning SERVFAIL.  This is a problem when your
+   nameserver is listed as a FORWARDER for such resolvers.  If the
+   nameserver is used as a FORWARDER by such resolver, the authority
+   flag will have to be forced on for NXDOMAIN responses to these
+   resolvers.  In practice this causes no problems even if turned on
+   always, and has been the default behaviour in BIND from 4.9.3
+   onwards.
+
+2.2 - No Data
+
+   NODATA is indicated by an answer with the RCODE set to NOERROR and no
+   relevant answers in the answer section.  The authority section will
+   contain an SOA record, or there will be no NS records there.
+
+
+
+Andrews                     Standards Track                     [Page 5]
+
+RFC 2308                       DNS NCACHE                     March 1998
+
+
+   NODATA responses have to be algorithmically determined from the
+   response's contents as there is no RCODE value to indicate NODATA.
+   In some cases to determine with certainty that NODATA is the correct
+   response it can be necessary to send another query.
+
+   The authority section may contain NXT and SIG RRsets in addition to
+   NS and SOA records.  CNAME and SIG records may exist in the answer
+   section.
+
+   It is possible to distinguish between a NODATA and a referral
+   response by the presence of a SOA record in the authority section or
+   the absence of NS records in the authority section.
+
+   NODATA responses can be categorised into three types by the contents
+   of the authority section.  These are shown below along with a
+   referral for comparison.  Fields not mentioned are not important in
+   terms of the examples.
+
+           NODATA RESPONSE: TYPE 1.
+
+           Header:
+               RDCODE=NOERROR
+           Query:
+               ANOTHER.EXAMPLE. A
+           Answer:
+               <empty>
+           Authority:
+               EXAMPLE. SOA NS1.XX. HOSTMASTER.NS1.XX. ....
+               EXAMPLE. NS NS1.XX.
+               EXAMPLE. NS NS2.XX.
+           Additional:
+               NS1.XX. A 127.0.0.2
+               NS2.XX. A 127.0.0.3
+
+           NO DATA RESPONSE: TYPE 2.
+
+           Header:
+               RDCODE=NOERROR
+           Query:
+               ANOTHER.EXAMPLE. A
+           Answer:
+               <empty>
+           Authority:
+               EXAMPLE. SOA NS1.XX. HOSTMASTER.NS1.XX. ....
+           Additional:
+               <empty>
+
+
+
+
+
+Andrews                     Standards Track                     [Page 6]
+
+RFC 2308                       DNS NCACHE                     March 1998
+
+
+           NO DATA RESPONSE: TYPE 3.
+
+           Header:
+               RDCODE=NOERROR
+           Query:
+               ANOTHER.EXAMPLE. A
+           Answer:
+               <empty>
+           Authority:
+               <empty>
+           Additional:
+               <empty>
+
+           REFERRAL RESPONSE.
+
+           Header:
+               RDCODE=NOERROR
+           Query:
+               ANOTHER.EXAMPLE. A
+           Answer:
+               <empty>
+           Authority:
+               EXAMPLE. NS NS1.XX.
+               EXAMPLE. NS NS2.XX.
+           Additional:
+               NS1.XX. A 127.0.0.2
+               NS2.XX. A 127.0.0.3
+
+
+   These examples, unlike the NXDOMAIN examples above, have no CNAME
+   records, however they could, in just the same way that the NXDOMAIN
+   examples did, in which case it would be the value of the last CNAME
+   (the QNAME) for which NODATA would be concluded.
+
+2.2.1 - Special Handling of No Data
+
+   There are a large number of resolvers currently in existence that
+   fail to correctly detect and process all forms of NODATA response.
+   Some resolvers treat a TYPE 1 NODATA response as a referral.  To
+   alleviate this problem it is recommended that servers that are
+   authoritative for the NODATA response only send TYPE 2 NODATA
+   responses, that is the authority section contains a SOA record and no
+   NS records.  Sending a TYPE 1 NODATA response from a non-
+   authoritative server to one of these resolvers will only result in an
+   unnecessary query.  If a server is listed as a FORWARDER for another
+   resolver it may also be necessary to disable the sending of TYPE 1
+   NODATA response for non-authoritative NODATA responses.
+
+
+
+
+Andrews                     Standards Track                     [Page 7]
+
+RFC 2308                       DNS NCACHE                     March 1998
+
+
+   Some name servers fail to set the RCODE to NXDOMAIN in the presence
+   of CNAMEs in the answer section.  If a definitive NXDOMAIN / NODATA
+   answer is required in this case the resolver must query again using
+   the QNAME as the query label.
+
+3 - Negative Answers from Authoritative Servers
+
+   Name servers authoritative for a zone MUST include the SOA record of
+   the zone in the authority section of the response when reporting an
+   NXDOMAIN or indicating that no data of the requested type exists.
+   This is required so that the response may be cached.  The TTL of this
+   record is set from the minimum of the MINIMUM field of the SOA record
+   and the TTL of the SOA itself, and indicates how long a resolver may
+   cache the negative answer.  The TTL SIG record associated with the
+   SOA record should also be trimmed in line with the SOA's TTL.
+
+   If the containing zone is signed [RFC2065] the SOA and appropriate
+   NXT and SIG records MUST be added.
+
+4 - SOA Minimum Field
+
+   The SOA minimum field has been overloaded in the past to have three
+   different meanings, the minimum TTL value of all RRs in a zone, the
+   default TTL of RRs which did not contain a TTL value and the TTL of
+   negative responses.
+
+   Despite being the original defined meaning, the first of these, the
+   minimum TTL value of all RRs in a zone, has never in practice been
+   used and is hereby deprecated.
+
+   The second, the default TTL of RRs which contain no explicit TTL in
+   the master zone file, is relevant only at the primary server.  After
+   a zone transfer all RRs have explicit TTLs and it is impossible to
+   determine whether the TTL for a record was explicitly set or derived
+   from the default after a zone transfer.  Where a server does not
+   require RRs to include the TTL value explicitly, it should provide a
+   mechanism, not being the value of the MINIMUM field of the SOA
+   record, from which the missing TTL values are obtained.  How this is
+   done is implementation dependent.
+
+   The Master File format [RFC 1035 Section 5] is extended to include
+   the following directive:
+
+                           $TTL <TTL> [comment]
+
+
+
+
+
+
+
+Andrews                     Standards Track                     [Page 8]
+
+RFC 2308                       DNS NCACHE                     March 1998
+
+
+   All resource records appearing after the directive, and which do not
+   explicitly include a TTL value, have their TTL set to the TTL given
+   in the $TTL directive.  SIG records without a explicit TTL get their
+   TTL from the "original TTL" of the SIG record [RFC 2065 Section 4.5].
+
+   The remaining of the current meanings, of being the TTL to be used
+   for negative responses, is the new defined meaning of the SOA minimum
+   field.
+
+5 - Caching Negative Answers
+
+   Like normal answers negative answers have a time to live (TTL).  As
+   there is no record in the answer section to which this TTL can be
+   applied, the TTL must be carried by another method.  This is done by
+   including the SOA record from the zone in the authority section of
+   the reply.  When the authoritative server creates this record its TTL
+   is taken from the minimum of the SOA.MINIMUM field and SOA's TTL.
+   This TTL decrements in a similar manner to a normal cached answer and
+   upon reaching zero (0) indicates the cached negative answer MUST NOT
+   be used again.
+
+   A negative answer that resulted from a name error (NXDOMAIN) should
+   be cached such that it can be retrieved and returned in response to
+   another query for the same <QNAME, QCLASS> that resulted in the
+   cached negative response.
+
+   A negative answer that resulted from a no data error (NODATA) should
+   be cached such that it can be retrieved and returned in response to
+   another query for the same <QNAME, QTYPE, QCLASS> that resulted in
+   the cached negative response.
+
+   The NXT record, if it exists in the authority section of a negative
+   answer received, MUST be stored such that it can be be located and
+   returned with SOA record in the authority section, as should any SIG
+   records in the authority section.  For NXDOMAIN answers there is no
+   "necessary" obvious relationship between the NXT records and the
+   QNAME.  The NXT record MUST have the same owner name as the query
+   name for NODATA responses.
+
+   Negative responses without SOA records SHOULD NOT be cached as there
+   is no way to prevent the negative responses looping forever between a
+   pair of servers even with a short TTL.
+
+   Despite the DNS forming a tree of servers, with various mis-
+   configurations it is possible to form a loop in the query graph, e.g.
+   two servers listing each other as forwarders, various lame server
+   configurations.  Without a TTL count down a cache negative response
+
+
+
+
+Andrews                     Standards Track                     [Page 9]
+
+RFC 2308                       DNS NCACHE                     March 1998
+
+
+   when received by the next server would have its TTL reset.  This
+   negative indication could then live forever circulating between the
+   servers involved.
+
+   As with caching positive responses it is sensible for a resolver to
+   limit for how long it will cache a negative response as the protocol
+   supports caching for up to 68 years.  Such a limit should not be
+   greater than that applied to positive answers and preferably be
+   tunable.  Values of one to three hours have been found to work well
+   and would make sensible a default.  Values exceeding one day have
+   been found to be problematic.
+
+6 - Negative answers from the cache
+
+   When a server, in answering a query, encounters a cached negative
+   response it MUST add the cached SOA record to the authority section
+   of the response with the TTL decremented by the amount of time it was
+   stored in the cache.  This allows the NXDOMAIN / NODATA response to
+   time out correctly.
+
+   If a NXT record was cached along with SOA record it MUST be added to
+   the authority section.  If a SIG record was cached along with a NXT
+   record it SHOULD be added to the authority section.
+
+   As with all answers coming from the cache, negative answers SHOULD
+   have an implicit referral built into the answer.  This enables the
+   resolver to locate an authoritative source.  An implicit referral is
+   characterised by NS records in the authority section referring the
+   resolver towards a authoritative source.  NXDOMAIN types 1 and 4
+   responses contain implicit referrals as does NODATA type 1 response.
+
+7 - Other Negative Responses
+
+   Caching of other negative responses is not covered by any existing
+   RFC.  There is no way to indicate a desired TTL in these responses.
+   Care needs to be taken to ensure that there are not forwarding loops.
+
+7.1 Server Failure (OPTIONAL)
+
+   Server failures fall into two major classes.  The first is where a
+   server can determine that it has been misconfigured for a zone.  This
+   may be where it has been listed as a server, but not configured to be
+   a server for the zone, or where it has been configured to be a server
+   for the zone, but cannot obtain the zone data for some reason.  This
+   can occur either because the zone file does not exist or contains
+   errors, or because another server from which the zone should have
+   been available either did not respond or was unable or unwilling to
+   supply the zone.
+
+
+
+Andrews                     Standards Track                    [Page 10]
+
+RFC 2308                       DNS NCACHE                     March 1998
+
+
+   The second class is where the server needs to obtain an answer from
+   elsewhere, but is unable to do so, due to network failures, other
+   servers that don't reply, or return server failure errors, or
+   similar.
+
+   In either case a resolver MAY cache a server failure response.  If it
+   does so it MUST NOT cache it for longer than five (5) minutes, and it
+   MUST be cached against the specific query tuple <query name, type,
+   class, server IP address>.
+
+7.2 Dead / Unreachable Server (OPTIONAL)
+
+   Dead / Unreachable servers are servers that fail to respond in any
+   way to a query or where the transport layer has provided an
+   indication that the server does not exist or is unreachable.  A
+   server may be deemed to be dead or unreachable if it has not
+   responded to an outstanding query within 120 seconds.
+
+   Examples of transport layer indications are:
+
+      ICMP error messages indicating host, net or port unreachable.
+      TCP resets
+      IP stack error messages providing similar indications to those above.
+
+   A server MAY cache a dead server indication.  If it does so it MUST
+   NOT be deemed dead for longer than five (5) minutes.  The indication
+   MUST be stored against query tuple <query name, type, class, server
+   IP address> unless there was a transport layer indication that the
+   server does not exist, in which case it applies to all queries to
+   that specific IP address.
+
+8 - Changes from RFC 1034
+
+   Negative caching in resolvers is no-longer optional, if a resolver
+   caches anything it must also cache negative answers.
+
+   Non-authoritative negative answers MAY be cached.
+
+   The SOA record from the authority section MUST be cached.  Name error
+   indications must be cached against the tuple <query name, QCLASS>.
+   No data indications must be cached against <query name, QTYPE,
+   QCLASS> tuple.
+
+   A cached SOA record must be added to the response.  This was
+   explicitly not allowed because previously the distinction between a
+   normal cached SOA record, and the SOA cached as a result of a
+   negative response was not made, and simply extracting a normal cached
+   SOA and adding that to a cached negative response causes problems.
+
+
+
+Andrews                     Standards Track                    [Page 11]
+
+RFC 2308                       DNS NCACHE                     March 1998
+
+
+   The $TTL TTL directive was added to the master file format.
+
+9 - History of Negative Caching
+
+   This section presents a potted history of negative caching in the DNS
+   and forms no part of the technical specification of negative caching.
+
+   It is interesting to note that the same concepts were re-invented in
+   both the CHIVES and BIND servers.
+
+   The history of the early CHIVES work (Section 9.1) was supplied by
+   Rob Austein <sra@epilogue.com> and is reproduced here in the form in
+   which he supplied it [MPA].
+
+   Sometime around the spring of 1985, I mentioned to Paul Mockapetris
+   that our experience with his JEEVES DNS resolver had pointed out the
+   need for some kind of negative caching scheme.  Paul suggested that
+   we simply cache authoritative errors, using the SOA MINIMUM value for
+   the zone that would have contained the target RRs.  I'm pretty sure
+   that this conversation took place before RFC-973 was written, but it
+   was never clear to me whether this idea was something that Paul came
+   up with on the spot in response to my question or something he'd
+   already been planning to put into the document that became RFC-973.
+   In any case, neither of us was entirely sure that the SOA MINIMUM
+   value was really the right metric to use, but it was available and
+   was under the control of the administrator of the target zone, both
+   of which seemed to us at the time to be important feature.
+
+   Late in 1987, I released the initial beta-test version of CHIVES, the
+   DNS resolver I'd written to replace Paul's JEEVES resolver.  CHIVES
+   included a search path mechanism that was used pretty heavily at
+   several sites (including my own), so CHIVES also included a negative
+   caching mechanism based on SOA MINIMUM values.  The basic strategy
+   was to cache authoritative error codes keyed by the exact query
+   parameters (QNAME, QCLASS, and QTYPE), with a cache TTL equal to the
+   SOA MINIMUM value.  CHIVES did not attempt to track down SOA RRs if
+   they weren't supplied in the authoritative response, so it never
+   managed to completely eliminate the gratuitous DNS error message
+   traffic, but it did help considerably.  Keep in mind that this was
+   happening at about the same time as the near-collapse of the ARPANET
+   due to congestion caused by exponential growth and the the "old"
+   (pre-VJ) TCP retransmission algorithm, so negative caching resulted
+   in drasticly better DNS response time for our users, mailer daemons,
+   etcetera.
+
+
+
+
+
+
+
+Andrews                     Standards Track                    [Page 12]
+
+RFC 2308                       DNS NCACHE                     March 1998
+
+
+   As far as I know, CHIVES was the first resolver to implement negative
+   caching.  CHIVES was developed during the twilight years of TOPS-20,
+   so it never ran on very many machines, but the few machines that it
+   did run on were the ones that were too critical to shut down quickly
+   no matter how much it cost to keep them running.  So what few users
+   we did have tended to drive CHIVES pretty hard.  Several interesting
+   bits of DNS technology resulted from that, but the one that's
+   relevant here is the MAXTTL configuration parameter.
+
+   Experience with JEEVES had already shown that RRs often showed up
+   with ridiculously long TTLs (99999999 was particularly popular for
+   many years, due to bugs in the code and documentation of several
+   early versions of BIND), and that robust software that blindly
+   believed such TTLs could create so many strange failures that it was
+   often necessary to reboot the resolver frequently just to clear this
+   garbage out of the cache.  So CHIVES had a configuration parameter
+   "MAXTTL", which specified the maximum "reasonable" TTL in a received
+   RR.  RRs with TTLs greater than MAXTTL would either have their TTLs
+   reduced to MAXTTL or would be discarded entirely, depending on the
+   setting of another configuration parameter.
+
+   When we started getting field experience with CHIVES's negative
+   caching code, it became clear that the SOA MINIMUM value was often
+   large enough to cause the same kinds of problems for negative caching
+   as the huge TTLs in RRs had for normal caching (again, this was in
+   part due to a bug in several early versions of BIND, where a
+   secondary server would authoritatively deny all knowledge of its
+   zones if it couldn't contact the primaries on reboot).  So we started
+   running the negative cache TTLs through the MAXTTL check too, and
+   continued to experiment.
+
+   The configuration that seemed to work best on WSMR-SIMTEL20.ARMY.MIL
+   (last of the major Internet TOPS-20 machines to be shut down, thus
+   the last major user of CHIVES, thus the place where we had the
+   longest experimental baseline) was to set MAXTTL to about three days.
+   Most of the traffic initiated by SIMTEL20 in its last years was
+   mail-related, and the mail queue timeout was set to one week, so this
+   gave a "stuck" message several tries at complete DNS resolution,
+   without bogging down the system with a lot of useless queries.  Since
+   (for reasons that now escape me) we only had the single MAXTTL
+   parameter rather than separate ones for positive and negative
+   caching, it's not clear how much effect this setting of MAXTTL had on
+   the negative caching code.
+
+   CHIVES also included a second, somewhat controversial mechanism which
+   took the place of negative caching in some cases.  The CHIVES
+   resolver daemon could be configured to load DNS master files, giving
+   it the ability to act as what today would be called a "stealth
+
+
+
+Andrews                     Standards Track                    [Page 13]
+
+RFC 2308                       DNS NCACHE                     March 1998
+
+
+   secondary".  That is, when configured in this way, the resolver had
+   direct access to authoritative information for heavily-used zones.
+   The search path mechanisms in CHIVES reflected this: there were
+   actually two separate search paths, one of which only searched local
+   authoritative zone data, and one which could generate normal
+   iterative queries.  This cut down on the need for negative caching in
+   cases where usage was predictably heavy (e.g., the resolver on
+   XX.LCS.MIT.EDU always loaded the zone files for both LCS.MIT.EDU and
+   AI.MIT.EDU and put both of these suffixes into the "local" search
+   path, since between them the hosts in these two zones accounted for
+   the bulk of the DNS traffic).  Not all sites running CHIVES chose to
+   use this feature; C.CS.CMU.EDU, for example, chose to use the
+   "remote" search path for everything because there were too many
+   different sub-zones at CMU for zone shadowing to be practical for
+   them, so they relied pretty heavily on negative caching even for
+   local traffic.
+
+   Overall, I still think the basic design we used for negative caching
+   was pretty reasonable: the zone administrator specified how long to
+   cache negative answers, and the resolver configuration chose the
+   actual cache time from the range between zero and the period
+   specified by the zone administrator.  There are a lot of details I'd
+   do differently now (like using a new SOA field instead of overloading
+   the MINIMUM field), but after more than a decade, I'd be more worried
+   if we couldn't think of at least a few improvements.
+
+9.2 BIND
+
+   While not the first attempt to get negative caching into BIND, in
+   July 1993, BIND 4.9.2 ALPHA, Anant Kumar of ISI supplied code that
+   implemented, validation and negative caching (NCACHE).  This code had
+   a 10 minute TTL for negative caching and only cached the indication
+   that there was a negative response, NXDOMAIN or NOERROR_NODATA. This
+   is the origin of the NODATA pseudo response code mentioned above.
+
+   Mark Andrews of CSIRO added code (RETURNSOA) that stored the SOA
+   record such that it could be retrieved by a similar query.  UUnet
+   complained that they were getting old answers after loading a new
+   zone, and the option was turned off, BIND 4.9.3-alpha5, April 1994.
+   In reality this indicated that the named needed to purge the space
+   the zone would occupy.  Functionality to do this was added in BIND
+   4.9.3 BETA11 patch2, December 1994.
+
+   RETURNSOA was re-enabled by default, BIND 4.9.5-T1A, August 1996.
+
+
+
+
+
+
+
+Andrews                     Standards Track                    [Page 14]
+
+RFC 2308                       DNS NCACHE                     March 1998
+
+
+10 Example
+
+   The following example is based on a signed zone that is empty apart
+   from the nameservers.  We will query for WWW.XX.EXAMPLE showing
+   initial response and again 10 minutes later.  Note 1: during the
+   intervening 10 minutes the NS records for XX.EXAMPLE have expired.
+   Note 2: the TTL of the SIG records are not explicitly set in the zone
+   file and are hence the TTL of the RRset they are the signature for.
+
+        Zone File:
+
+        $TTL 86400
+        $ORIGIN XX.EXAMPLE.
+        @       IN      SOA     NS1.XX.EXAMPLE. HOSTMATER.XX.EXAMPLE. (
+                                1997102000      ; serial
+                                1800    ; refresh (30 mins)
+                                900     ; retry (15 mins)
+                                604800  ; expire (7 days)
+                                1200 ) ; minimum (20 mins)
+                IN      SIG     SOA ...
+          1200  IN      NXT     NS1.XX.EXAMPLE. A NXT SIG SOA NS KEY
+                IN      SIG     NXT ... XX.EXAMPLE. ...
+           300  IN      NS      NS1.XX.EXAMPLE.
+           300  IN      NS      NS2.XX.EXAMPLE.
+                IN      SIG     NS ... XX.EXAMPLE. ...
+                IN      KEY     0x4100 1 1 ...
+                IN      SIG     KEY ... XX.EXAMPLE. ...
+                IN      SIG     KEY ... EXAMPLE. ...
+        NS1     IN      A       10.0.0.1
+                IN      SIG     A ... XX.EXAMPLE. ...
+          1200  IN      NXT     NS2.XX.EXAMPLE. A NXT SIG
+                IN      SIG     NXT ...
+        NS2     IN      A       10.0.0.2
+                IN      SIG     A ... XX.EXAMPLE. ...
+          1200  IN      NXT     XX.EXAMPLE. A NXT SIG
+                IN      SIG     NXT ... XX.EXAMPLE. ...
+
+        Initial Response:
+
+        Header:
+            RDCODE=NXDOMAIN, AA=1, QR=1, TC=0
+        Query:
+            WWW.XX.EXAMPLE. IN A
+        Answer:
+            <empty>
+        Authority:
+            XX.EXAMPLE.      1200 IN SOA NS1.XX.EXAMPLE. ...
+            XX.EXAMPLE.      1200 IN SIG SOA ... XX.EXAMPLE. ...
+
+
+
+Andrews                     Standards Track                    [Page 15]
+
+RFC 2308                       DNS NCACHE                     March 1998
+
+
+            NS2.XX.EXAMPLE.  1200 IN NXT XX.EXAMPLE. NXT A NXT SIG
+            NS2.XX.EXAMPLE.  1200 IN SIG NXT ... XX.EXAMPLE. ...
+            XX.EXAMPLE.     86400 IN NS  NS1.XX.EXAMPLE.
+            XX.EXAMPLE.     86400 IN NS  NS2.XX.EXAMPLE.
+            XX.EXAMPLE.     86400 IN SIG NS ... XX.EXAMPLE. ...
+        Additional
+            XX.EXAMPLE.     86400 IN KEY 0x4100 1 1 ...
+            XX.EXAMPLE.     86400 IN SIG KEY ... EXAMPLE. ...
+            NS1.XX.EXAMPLE. 86400 IN A   10.0.0.1
+            NS1.XX.EXAMPLE. 86400 IN SIG A ... XX.EXAMPLE. ...
+            NS2.XX.EXAMPLE. 86400 IN A   10.0.0.2
+            NS3.XX.EXAMPLE. 86400 IN SIG A ... XX.EXAMPLE. ...
+
+         After 10 Minutes:
+
+         Header:
+             RDCODE=NXDOMAIN, AA=0, QR=1, TC=0
+         Query:
+             WWW.XX.EXAMPLE. IN A
+         Answer:
+             <empty>
+         Authority:
+             XX.EXAMPLE.       600 IN SOA NS1.XX.EXAMPLE. ...
+             XX.EXAMPLE.       600 IN SIG SOA ... XX.EXAMPLE. ...
+             NS2.XX.EXAMPLE.   600 IN NXT XX.EXAMPLE. NXT A NXT SIG
+             NS2.XX.EXAMPLE.   600 IN SIG NXT ... XX.EXAMPLE. ...
+             EXAMPLE.        65799 IN NS  NS1.YY.EXAMPLE.
+             EXAMPLE.        65799 IN NS  NS2.YY.EXAMPLE.
+             EXAMPLE.        65799 IN SIG NS ... XX.EXAMPLE. ...
+         Additional
+             XX.EXAMPLE.     65800 IN KEY 0x4100 1 1 ...
+             XX.EXAMPLE.     65800 IN SIG KEY ... EXAMPLE. ...
+             NS1.YY.EXAMPLE. 65799 IN A   10.100.0.1
+             NS1.YY.EXAMPLE. 65799 IN SIG A ... EXAMPLE. ...
+             NS2.YY.EXAMPLE. 65799 IN A   10.100.0.2
+             NS3.YY.EXAMPLE. 65799 IN SIG A ... EXAMPLE. ...
+             EXAMPLE.        65799 IN KEY 0x4100 1 1 ...
+             EXAMPLE.        65799 IN SIG KEY ... . ...
+
+
+11 Security Considerations
+
+   It is believed that this document does not introduce any significant
+   additional security threats other that those that already exist when
+   using data from the DNS.
+
+
+
+
+
+
+Andrews                     Standards Track                    [Page 16]
+
+RFC 2308                       DNS NCACHE                     March 1998
+
+
+   With negative caching it might be possible to propagate a denial of
+   service attack by spreading a NXDOMAIN message with a very high TTL.
+   Without negative caching that would be much harder.  A similar effect
+   could be achieved previously by spreading a bad A record, so that the
+   server could not be reached - which is almost the same.  It has the
+   same effect as far as what the end user is able to do, but with a
+   different psychological effect.  With the bad A, I feel "damn the
+   network is broken again" and try again tomorrow.  With the "NXDOMAIN"
+   I feel "Oh, they've turned off the server and it doesn't exist any
+   more" and probably never bother trying this server again.
+
+   A practical example of this is a SMTP server where this behaviour is
+   encoded.  With a NXDOMAIN attack the mail message would bounce
+   immediately, where as with a bad A attack the mail would be queued
+   and could potentially get through after the attack was suspended.
+
+   For such an attack to be successful, the NXDOMAIN indiction must be
+   injected into a parent server (or a busy caching resolver).  One way
+   this might be done by the use of a CNAME which results in the parent
+   server querying an attackers server.  Resolvers that wish to prevent
+   such attacks can query again the final QNAME ignoring any NS data in
+   the query responses it has received for this query.
+
+   Implementing TTL sanity checking will reduce the effectiveness of
+   such an attack, because a successful attack would require re-
+   injection of the bogus data at more frequent intervals.
+
+   DNS Security [RFC2065] provides a mechanism to verify whether a
+   negative response is valid or not, through the use of NXT and SIG
+   records.  This document supports the use of that mechanism by
+   promoting the transmission of the relevant security records even in a
+   non security aware server.
+
+Acknowledgments
+
+   I would like to thank Rob Austein for his history of the CHIVES
+   nameserver. The DNSIND working group, in particular Robert Elz for
+   his valuable technical and editorial contributions to this document.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Andrews                     Standards Track                    [Page 17]
+
+RFC 2308                       DNS NCACHE                     March 1998
+
+
+References
+
+   [RFC1034]
+           Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES,"
+           STD 13, RFC 1034, November 1987.
+
+   [RFC1035]
+           Mockapetris, P., "DOMAIN NAMES - IMPLEMENTATION AND
+           SPECIFICATION," STD 13, RFC 1035, November 1987.
+
+   [RFC2065]
+           Eastlake, D., and C. Kaufman, "Domain Name System Security
+           Extensions," RFC 2065, January 1997.
+
+   [RFC2119]
+           Bradner, S., "Key words for use in RFCs to Indicate
+           Requirement Levels," BCP 14, RFC 2119, March 1997.
+
+   [RFC2181]
+           Elz, R., and R. Bush, "Clarifications to the DNS
+           Specification," RFC 2181, July 1997.
+
+Author's Address
+
+   Mark Andrews
+   CSIRO - Mathematical and Information Sciences
+   Locked Bag 17
+   North Ryde NSW 2113
+   AUSTRALIA
+
+   Phone: +61 2 9325 3148
+   EMail: Mark.Andrews@cmis.csiro.au
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Andrews                     Standards Track                    [Page 18]
+
+RFC 2308                       DNS NCACHE                     March 1998
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (1998).  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 Standards process must be
+   followed, or as required to translate it into 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Andrews                     Standards Track                    [Page 19]
+
diff --git a/doc/rfc/rfc2317.txt b/doc/rfc/rfc2317.txt
new file mode 100644
index 0000000..c17bb41
--- /dev/null
+++ b/doc/rfc/rfc2317.txt
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+Network Working Group                                         H. Eidnes
+Request for Comments: 2317                                 SINTEF RUNIT
+BCP: 20                                                     G. de Groot
+Category: Best Current Practice          Berkeley Software Design, Inc.
+                                                               P. Vixie
+                                           Internet Software Consortium
+                                                             March 1998
+
+
+                   Classless IN-ADDR.ARPA delegation
+
+Status of this Memo
+
+   This document specifies an Internet Best Current Practices for the
+   Internet Community, and requests discussion and suggestions for
+   improvements.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (1998).  All Rights Reserved.
+
+2. Introduction
+
+   This document describes a way to do IN-ADDR.ARPA delegation on non-
+   octet boundaries for address spaces covering fewer than 256
+   addresses.  The proposed method should thus remove one of the
+   objections to subnet on non-octet boundaries but perhaps more
+   significantly, make it possible to assign IP address space in smaller
+   chunks than 24-bit prefixes, without losing the ability to delegate
+   authority for the corresponding IN-ADDR.ARPA mappings.  The proposed
+   method is fully compatible with the original DNS lookup mechanisms
+   specified in [1], i.e. there is no need to modify the lookup
+   algorithm used, and there should be no need to modify any software
+   which does DNS lookups.
+
+   The document also discusses some operational considerations to
+   provide some guidance in implementing this method.
+
+3. Motivation
+
+   With the proliferation of classless routing technology, it has become
+   feasible to assign address space on non-octet boundaries.  In case of
+   a very small organization with only a few hosts, assigning a full
+   24-bit prefix (what was traditionally referred to as a "class C
+   network number") often leads to inefficient address space
+   utilization.
+
+
+
+
+
+Eidnes, et. al.          Best Current Practice                  [Page 1]
+
+RFC 2317           Classless IN-ADDR.ARPA delegation          March 1998
+
+
+   One of the problems encountered when assigning a longer prefix (less
+   address space) is that it seems impossible for such an organization
+   to maintain its own reverse ("IN-ADDR.ARPA") zone autonomously.  By
+   use of the reverse delegation method described below, the most
+   important objection to assignment of longer prefixes to unrelated
+   organizations can be removed.
+
+   Let us assume we have assigned the address spaces to three different
+   parties as follows:
+
+           192.0.2.0/25   to organization A
+           192.0.2.128/26 to organization B
+           192.0.2.192/26 to organization C
+
+   In the classical approach, this would lead to a single zone like
+   this:
+
+   $ORIGIN 2.0.192.in-addr.arpa.
+   ;
+   1               PTR     host1.A.domain.
+   2               PTR     host2.A.domain.
+   3               PTR     host3.A.domain.
+   ;
+   129             PTR     host1.B.domain.
+   130             PTR     host2.B.domain.
+   131             PTR     host3.B.domain.
+   ;
+   193             PTR     host1.C.domain.
+   194             PTR     host2.C.domain.
+   195             PTR     host3.C.domain.
+
+   The administration of this zone is problematic.  Authority for this
+   zone can only be delegated once, and this usually translates into
+   "this zone can only be administered by one organization."  The other
+   organizations with address space that corresponds to entries in this
+   zone would thus have to depend on another organization for their
+   address to name translation.  With the proposed method, this
+   potential problem can be avoided.
+
+4. Classless IN-ADDR.ARPA delegation
+
+   Since a single zone can only be delegated once, we need more points
+   to do delegation on to solve the problem above.  These extra points
+   of delegation can be introduced by extending the IN-ADDR.ARPA tree
+   downwards, e.g. by using the first address or the first address and
+   the network mask length (as shown below) in the corresponding address
+
+
+
+
+
+Eidnes, et. al.          Best Current Practice                  [Page 2]
+
+RFC 2317           Classless IN-ADDR.ARPA delegation          March 1998
+
+
+   space to form the the first component in the name for the zones.  The
+   following four zone files show how the problem in the motivation
+   section could be solved using this method.
+
+   $ORIGIN 2.0.192.in-addr.arpa.
+   @       IN      SOA     my-ns.my.domain. hostmaster.my.domain. (...)
+   ;...
+   ;  <<0-127>> /25
+   0/25            NS      ns.A.domain.
+   0/25            NS      some.other.name.server.
+   ;
+   1               CNAME   1.0/25.2.0.192.in-addr.arpa.
+   2               CNAME   2.0/25.2.0.192.in-addr.arpa.
+   3               CNAME   3.0/25.2.0.192.in-addr.arpa.
+   ;
+   ;  <<128-191>> /26
+   128/26          NS      ns.B.domain.
+   128/26          NS      some.other.name.server.too.
+   ;
+   129             CNAME   129.128/26.2.0.192.in-addr.arpa.
+   130             CNAME   130.128/26.2.0.192.in-addr.arpa.
+   131             CNAME   131.128/26.2.0.192.in-addr.arpa.
+   ;
+   ;  <<192-255>> /26
+   192/26          NS      ns.C.domain.
+   192/26          NS      some.other.third.name.server.
+   ;
+   193             CNAME   193.192/26.2.0.192.in-addr.arpa.
+   194             CNAME   194.192/26.2.0.192.in-addr.arpa.
+   195             CNAME   195.192/26.2.0.192.in-addr.arpa.
+
+   $ORIGIN 0/25.2.0.192.in-addr.arpa.
+   @       IN      SOA     ns.A.domain. hostmaster.A.domain. (...)
+   @               NS      ns.A.domain.
+   @               NS      some.other.name.server.
+   ;
+   1               PTR     host1.A.domain.
+   2               PTR     host2.A.domain.
+   3               PTR     host3.A.domain.
+
+
+
+
+
+
+
+
+
+
+
+
+Eidnes, et. al.          Best Current Practice                  [Page 3]
+
+RFC 2317           Classless IN-ADDR.ARPA delegation          March 1998
+
+
+   $ORIGIN 128/26.2.0.192.in-addr.arpa.
+   @       IN      SOA     ns.B.domain. hostmaster.B.domain. (...)
+   @               NS      ns.B.domain.
+   @               NS      some.other.name.server.too.
+   ;
+   129             PTR     host1.B.domain.
+   130             PTR     host2.B.domain.
+   131             PTR     host3.B.domain.
+
+
+   $ORIGIN 192/26.2.0.192.in-addr.arpa.
+   @       IN      SOA     ns.C.domain. hostmaster.C.domain. (...)
+   @               NS      ns.C.domain.
+   @               NS      some.other.third.name.server.
+   ;
+   193             PTR     host1.C.domain.
+   194             PTR     host2.C.domain.
+   195             PTR     host3.C.domain.
+
+   For each size-256 chunk split up using this method, there is a need
+   to install close to 256 CNAME records in the parent zone.  Some
+   people might view this as ugly; we will not argue that particular
+   point.  It is however quite easy to automatically generate the CNAME
+   resource records in the parent zone once and for all, if the way the
+   address space is partitioned is known.
+
+   The advantage of this approach over the other proposed approaches for
+   dealing with this problem is that there should be no need to modify
+   any already-deployed software.  In particular, the lookup mechanism
+   in the DNS does not have to be modified to accommodate this splitting
+   of the responsibility for the IPv4 address to name translation on
+   "non-dot" boundaries.  Furthermore, this technique has been in use
+   for several years in many installations, apparently with no ill
+   effects.
+
+   As usual, a resource record like
+
+   $ORIGIN 2.0.192.in-addr.arpa.
+   129             CNAME   129.128/26.2.0.192.in-addr.arpa.
+
+   can be convienently abbreviated to
+
+   $ORIGIN 2.0.192.in-addr.arpa.
+   129             CNAME   129.128/26
+
+
+
+
+
+
+
+Eidnes, et. al.          Best Current Practice                  [Page 4]
+
+RFC 2317           Classless IN-ADDR.ARPA delegation          March 1998
+
+
+   Some DNS implementations are not kind to special characters in domain
+   names, e.g. the "/" used in the above examples.  As [3] makes clear,
+   these are legal, though some might feel unsightly.  Because these are
+   not host names the restriction of [2] does not apply.  Modern clients
+   and servers have an option to act in the liberal and correct fashion.
+
+   The examples here use "/" because it was felt to be more visible and
+   pedantic reviewers felt that the 'these are not hostnames' argument
+   needed to be repeated.  We advise you not to be so pedantic, and to
+   not precisely copy the above examples, e.g.  substitute a more
+   conservative character, such as hyphen, for "/".
+
+5. Operational considerations
+
+   This technique is intended to be used for delegating address spaces
+   covering fewer than 256 addresses.  For delegations covering larger
+   blocks of addresses the traditional methods (multiple delegations)
+   can be used instead.
+
+5.1 Recommended secondary name service
+
+   Some older versions of name server software will make no effort to
+   find and return the pointed-to name in CNAME records if the pointed-
+   to name is not already known locally as cached or as authoritative
+   data.  This can cause some confusion in resolvers, as only the CNAME
+   record will be returned in the response.  To avoid this problem it is
+   recommended that the authoritative name servers for the delegating
+   zone (the zone containing all the CNAME records) all run as slave
+   (secondary) name servers for the "child" zones delegated and pointed
+   into via the CNAME records.
+
+5.2 Alternative naming conventions
+
+   As a result of this method, the location of the zone containing the
+   actual PTR records is no longer predefined.  This gives flexibility
+   and some examples will be presented here.
+
+   An alternative to using the first address, or the first address and
+   the network mask length in the corresponding address space, to name
+   the new zones is to use some other (non-numeric) name.  Thus it is
+   also possible to point to an entirely different part of the DNS tree
+   (i.e. outside of the IN-ADDR.ARPA tree).  It would be necessary to
+   use one of these alternate methods if two organizations somehow
+   shared the same physical subnet (and corresponding IP address space)
+   with no "neat" alignment of the addresses, but still wanted to
+   administrate their own IN-ADDR.ARPA mappings.
+
+
+
+
+
+Eidnes, et. al.          Best Current Practice                  [Page 5]
+
+RFC 2317           Classless IN-ADDR.ARPA delegation          March 1998
+
+
+   The following short example shows how you can point out of the IN-
+   ADDR.ARPA tree:
+
+   $ORIGIN 2.0.192.in-addr.arpa.
+   @       IN      SOA     my-ns.my.domain. hostmaster.my.domain. (...)
+   ; ...
+   1               CNAME   1.A.domain.
+   2               CNAME   2.A.domain.
+   ; ...
+   129             CNAME   129.B.domain.
+   130             CNAME   130.B.domain.
+   ;
+
+
+   $ORIGIN A.domain.
+   @       IN      SOA     my-ns.A.domain. hostmaster.A.domain. (...)
+   ; ...
+   ;
+   host1           A       192.0.2.1
+   1               PTR     host1
+   ;
+   host2           A       192.0.2.2
+   2               PTR     host2
+   ;
+
+   etc.
+
+   This way you can actually end up with the name->address and the
+   (pointed-to) address->name mapping data in the same zone file - some
+   may view this as an added bonus as no separate set of secondaries for
+   the reverse zone is required.  Do however note that the traversal via
+   the IN-ADDR.ARPA tree will still be done, so the CNAME records
+   inserted there need to point in the right direction for this to work.
+
+   Sketched below is an alternative approach using the same solution:
+
+   $ORIGIN 2.0.192.in-addr.arpa.
+   @                  SOA     my-ns.my.domain. hostmaster.my.domain. (...)
+   ; ...
+   1                  CNAME   1.2.0.192.in-addr.A.domain.
+   2                  CNAME   2.2.0.192.in-addr.A.domain.
+
+   $ORIGIN A.domain.
+   @                  SOA     my-ns.A.domain. hostmaster.A.domain. (...)
+   ; ...
+   ;
+   host1              A       192.0.2.1
+   1.2.0.192.in-addr  PTR     host1
+
+
+
+Eidnes, et. al.          Best Current Practice                  [Page 6]
+
+RFC 2317           Classless IN-ADDR.ARPA delegation          March 1998
+
+
+   host2              A       192.0.2.2
+   2.2.0.192.in-addr  PTR     host2
+
+   It is clear that many possibilities exist which can be adapted to the
+   specific requirements of the situation at hand.
+
+5.3 Other operational issues
+
+   Note that one cannot provide CNAME referrals twice for the same
+   address space, i.e. you cannot allocate a /25 prefix to one
+   organisation, and run IN-ADDR.ARPA this way, and then have the
+   organisation subnet the /25 into longer prefixes, and attempt to
+   employ the same technique to give each subnet control of its own
+   number space. This would result in a CNAME record pointing to a CNAME
+   record, which may be less robust overall.
+
+   Unfortunately, some old beta releases of the popular DNS name server
+   implementation BIND 4.9.3 had a bug which caused problems if a CNAME
+   record was encountered when a reverse lookup was made.  The beta
+   releases involved have since been obsoleted, and this issue is
+   resolved in the released code.  Some software manufacturers have
+   included the defective beta code in their product. In the few cases
+   we know of, patches from the manufacturers are available or planned
+   to replace the obsolete beta code involved.
+
+6. Security Considerations
+
+   With this scheme, the "leaf sites" will need to rely on one more site
+   running their DNS name service correctly than they would be if they
+   had a /24 allocation of their own, and this may add an extra
+   component which will need to work for reliable name resolution.
+
+   Other than that, the authors are not aware of any additional security
+   issues introduced by this mechanism.
+
+7. Conclusion
+
+   The suggested scheme gives more flexibility in delegating authority
+   in the IN-ADDR.ARPA domain, thus making it possible to assign address
+   space more efficiently without losing the ability to delegate the DNS
+   authority over the corresponding address to name mappings.
+
+8. Acknowledgments
+
+   Glen A. Herrmannsfeldt described this trick on comp.protocols.tcp-
+   ip.domains some time ago.  Alan Barrett and Sam Wilson provided
+   valuable comments on the newsgroup.
+
+
+
+
+Eidnes, et. al.          Best Current Practice                  [Page 7]
+
+RFC 2317           Classless IN-ADDR.ARPA delegation          March 1998
+
+
+   We would like to thank Rob Austein, Randy Bush, Matt Crawford, Robert
+   Elz, Glen A. Herrmannsfeldt, Daniel Karrenberg, David Kessens, Tony
+   Li, Paul Mockapetris, Eric Wassenaar, Michael Patton, Hans Maurer,
+   and Peter Koch for their review and constructive comments.
+
+9. References
+
+   [1]  Mockapetris, P., "Domain Names - Concepts and Facilities",
+        STD 13, RFC 1034, November 1987.
+
+   [2]  Harrenstien, K., Stahl, M., and E. Feinler, "DoD Internet Host
+        Table Specification", RFC 952, October 1985.
+
+   [3]  Elz, R., and R. Bush, "Clarifications to the DNS
+        Specification", RFC 2181, July 1997.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eidnes, et. al.          Best Current Practice                  [Page 8]
+
+RFC 2317           Classless IN-ADDR.ARPA delegation          March 1998
+
+
+10. Authors' Addresses
+
+   Havard Eidnes
+   SINTEF RUNIT
+   N-7034 Trondheim
+   Norway
+
+   Phone: +47 73 59 44 68
+   Fax: +47 73 59 17 00
+   EMail: Havard.Eidnes@runit.sintef.no
+
+
+   Geert Jan de Groot
+   Berkeley Software Design, Inc. (BSDI)
+   Hendrik Staetslaan 69
+   5622 HM Eindhoven
+   The Netherlands
+
+   Phone: +31 40 2960509
+   Fax:   +31 40 2960309
+   EMail: GeertJan.deGroot@bsdi.com
+
+
+   Paul Vixie
+   Internet Software Consortium
+   Star Route Box 159A
+   Woodside, CA 94062
+   USA
+
+   Phone: +1 415 747 0204
+   EMail: paul@vix.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eidnes, et. al.          Best Current Practice                  [Page 9]
+
+RFC 2317           Classless IN-ADDR.ARPA delegation          March 1998
+
+
+11.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (1998).  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 Standards process must be
+   followed, or as required to translate it into 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eidnes, et. al.          Best Current Practice                 [Page 10]
+
diff --git a/doc/rfc/rfc2373.txt b/doc/rfc/rfc2373.txt
new file mode 100644
index 0000000..59fcff8
--- /dev/null
+++ b/doc/rfc/rfc2373.txt
@@ -0,0 +1,1459 @@
+
+
+
+
+
+
+Network Working Group                                        R. Hinden
+Request for Comments: 2373                                       Nokia
+Obsoletes: 1884                                             S. Deering
+Category: Standards Track                                Cisco Systems
+							     July 1998
+
+                  IP Version 6 Addressing Architecture
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (1998).  All Rights Reserved.
+
+Abstract
+
+   This specification defines the addressing architecture of the IP
+   Version 6 protocol [IPV6].  The document includes the IPv6 addressing
+   model, text representations of IPv6 addresses, definition of IPv6
+   unicast addresses, anycast addresses, and multicast addresses, and an
+   IPv6 node's required addresses.
+
+Table of Contents
+
+   1. Introduction.................................................2
+   2. IPv6 Addressing..............................................2
+      2.1 Addressing Model.........................................3
+      2.2 Text Representation of Addresses.........................3
+      2.3 Text Representation of Address Prefixes..................5
+      2.4 Address Type Representation..............................6
+      2.5 Unicast Addresses........................................7
+        2.5.1 Interface Identifiers................................8
+        2.5.2 The Unspecified Address..............................9
+        2.5.3 The Loopback Address.................................9
+        2.5.4 IPv6 Addresses with Embedded IPv4 Addresses.........10
+        2.5.5 NSAP Addresses......................................10
+        2.5.6 IPX Addresses.......................................10
+        2.5.7 Aggregatable Global Unicast Addresses...............11
+        2.5.8 Local-use IPv6 Unicast Addresses....................11
+      2.6 Anycast Addresses.......................................12
+        2.6.1 Required Anycast Address............................13
+      2.7 Multicast Addresses.....................................14
+
+
+
+Hinden & Deering            Standards Track                     [Page 1]
+
+RFC 2373              IPv6 Addressing Architecture             July 1998
+
+
+        2.7.1 Pre-Defined Multicast Addresses.....................15
+        2.7.2 Assignment of New IPv6 Multicast Addresses..........17
+      2.8 A Node's Required Addresses.............................17
+   3. Security Considerations.....................................18
+   APPENDIX A: Creating EUI-64 based Interface Identifiers........19
+   APPENDIX B: ABNF Description of Text Representations...........22
+   APPENDIX C: CHANGES FROM RFC-1884..............................23
+   REFERENCES.....................................................24
+   AUTHORS' ADDRESSES.............................................25
+   FULL COPYRIGHT STATEMENT.......................................26
+
+
+1.0 INTRODUCTION
+
+   This specification defines the addressing architecture of the IP
+   Version 6 protocol.  It includes a detailed description of the
+   currently defined address formats for IPv6 [IPV6].
+
+   The authors would like to acknowledge the contributions of Paul
+   Francis, Scott Bradner, Jim Bound, Brian Carpenter, Matt Crawford,
+   Deborah Estrin, Roger Fajman, Bob Fink, Peter Ford, Bob Gilligan,
+   Dimitry Haskin, Tom Harsch, Christian Huitema, Tony Li, Greg
+   Minshall, Thomas Narten, Erik Nordmark, Yakov Rekhter, Bill Simpson,
+   and Sue Thomson.
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC 2119].
+
+2.0 IPv6 ADDRESSING
+
+   IPv6 addresses are 128-bit identifiers for interfaces and sets of
+   interfaces.  There are three types of addresses:
+
+     Unicast:   An identifier for a single interface.  A packet sent to
+                a unicast address is delivered to the interface
+                identified by that address.
+
+     Anycast:   An identifier for a set of interfaces (typically
+                belonging to different nodes).  A packet sent to an
+                anycast address is delivered to one of the interfaces
+                identified by that address (the "nearest" one, according
+                to the routing protocols' measure of distance).
+
+     Multicast: An identifier for a set of interfaces (typically
+                belonging to different nodes).  A packet sent to a
+                multicast address is delivered to all interfaces
+                identified by that address.
+
+
+
+Hinden & Deering            Standards Track                     [Page 2]
+
+RFC 2373              IPv6 Addressing Architecture             July 1998
+
+
+   There are no broadcast addresses in IPv6, their function being
+   superseded by multicast addresses.
+
+   In this document, fields in addresses are given a specific name, for
+   example "subscriber".  When this name is used with the term "ID" for
+   identifier after the name (e.g., "subscriber ID"), it refers to the
+   contents of the named field.  When it is used with the term "prefix"
+   (e.g.  "subscriber prefix") it refers to all of the address up to and
+   including this field.
+
+   In IPv6, all zeros and all ones are legal values for any field,
+   unless specifically excluded.  Specifically, prefixes may contain
+   zero-valued fields or end in zeros.
+
+2.1 Addressing Model
+
+   IPv6 addresses of all types are assigned to interfaces, not nodes.
+   An IPv6 unicast address refers to a single interface.  Since each
+   interface belongs to a single node, any of that node's interfaces'
+   unicast addresses may be used as an identifier for the node.
+
+   All interfaces are required to have at least one link-local unicast
+   address (see section 2.8 for additional required addresses).  A
+   single interface may also be assigned multiple IPv6 addresses of any
+   type (unicast, anycast, and multicast) or scope.  Unicast addresses
+   with scope greater than link-scope are not needed for interfaces that
+   are not used as the origin or destination of any IPv6 packets to or
+   from non-neighbors.  This is sometimes convenient for point-to-point
+   interfaces.  There is one exception to this addressing model:
+
+     An unicast address or a set of unicast addresses may be assigned to
+     multiple physical interfaces if the implementation treats the
+     multiple physical interfaces as one interface when presenting it to
+     the internet layer.  This is useful for load-sharing over multiple
+     physical interfaces.
+
+   Currently IPv6 continues the IPv4 model that a subnet prefix is
+   associated with one link.  Multiple subnet prefixes may be assigned
+   to the same link.
+
+2.2 Text Representation of Addresses
+
+   There are three conventional forms for representing IPv6 addresses as
+   text strings:
+
+   1. The preferred form is x:x:x:x:x:x:x:x, where the 'x's are the
+      hexadecimal values of the eight 16-bit pieces of the address.
+      Examples:
+
+
+
+Hinden & Deering            Standards Track                     [Page 3]
+
+RFC 2373              IPv6 Addressing Architecture             July 1998
+
+
+         FEDC:BA98:7654:3210:FEDC:BA98:7654:3210
+
+         1080:0:0:0:8:800:200C:417A
+
+      Note that it is not necessary to write the leading zeros in an
+      individual field, but there must be at least one numeral in every
+      field (except for the case described in 2.).
+
+   2. Due to some methods of allocating certain styles of IPv6
+      addresses, it will be common for addresses to contain long strings
+      of zero bits.  In order to make writing addresses containing zero
+      bits easier a special syntax is available to compress the zeros.
+      The use of "::" indicates multiple groups of 16-bits of zeros.
+      The "::" can only appear once in an address.  The "::" can also be
+      used to compress the leading and/or trailing zeros in an address.
+
+      For example the following addresses:
+
+         1080:0:0:0:8:800:200C:417A  a unicast address
+         FF01:0:0:0:0:0:0:101        a multicast address
+         0:0:0:0:0:0:0:1             the loopback address
+         0:0:0:0:0:0:0:0             the unspecified addresses
+
+      may be represented as:
+
+         1080::8:800:200C:417A       a unicast address
+         FF01::101                   a multicast address
+         ::1                         the loopback address
+         ::                          the unspecified addresses
+
+   3. An alternative form that is sometimes more convenient when dealing
+      with a mixed environment of IPv4 and IPv6 nodes is
+      x:x:x:x:x:x:d.d.d.d, where the 'x's are the hexadecimal values of
+      the six high-order 16-bit pieces of the address, and the 'd's are
+      the decimal values of the four low-order 8-bit pieces of the
+      address (standard IPv4 representation).  Examples:
+
+         0:0:0:0:0:0:13.1.68.3
+
+         0:0:0:0:0:FFFF:129.144.52.38
+
+      or in compressed form:
+
+         ::13.1.68.3
+
+         ::FFFF:129.144.52.38
+
+
+
+
+
+Hinden & Deering            Standards Track                     [Page 4]
+
+RFC 2373              IPv6 Addressing Architecture             July 1998
+
+
+2.3 Text Representation of Address Prefixes
+
+   The text representation of IPv6 address prefixes is similar to the
+   way IPv4 addresses prefixes are written in CIDR notation.  An IPv6
+   address prefix is represented by the notation:
+
+      ipv6-address/prefix-length
+
+   where
+
+      ipv6-address    is an IPv6 address in any of the notations listed
+                      in section 2.2.
+
+      prefix-length   is a decimal value specifying how many of the
+                      leftmost contiguous bits of the address comprise
+                      the prefix.
+
+   For example, the following are legal representations of the 60-bit
+   prefix 12AB00000000CD3 (hexadecimal):
+
+      12AB:0000:0000:CD30:0000:0000:0000:0000/60
+      12AB::CD30:0:0:0:0/60
+      12AB:0:0:CD30::/60
+
+   The following are NOT legal representations of the above prefix:
+
+      12AB:0:0:CD3/60   may drop leading zeros, but not trailing zeros,
+                        within any 16-bit chunk of the address
+
+      12AB::CD30/60     address to left of "/" expands to
+                        12AB:0000:0000:0000:0000:000:0000:CD30
+
+      12AB::CD3/60      address to left of "/" expands to
+                        12AB:0000:0000:0000:0000:000:0000:0CD3
+
+   When writing both a node address and a prefix of that node address
+   (e.g., the node's subnet prefix), the two can combined as follows:
+
+      the node address      12AB:0:0:CD30:123:4567:89AB:CDEF
+      and its subnet number 12AB:0:0:CD30::/60
+
+      can be abbreviated as 12AB:0:0:CD30:123:4567:89AB:CDEF/60
+
+
+
+
+
+
+
+
+
+Hinden & Deering            Standards Track                     [Page 5]
+
+RFC 2373              IPv6 Addressing Architecture             July 1998
+
+
+2.4 Address Type Representation
+
+   The specific type of an IPv6 address is indicated by the leading bits
+   in the address.  The variable-length field comprising these leading
+   bits is called the Format Prefix (FP).  The initial allocation of
+   these prefixes is as follows:
+
+    Allocation                            Prefix         Fraction of
+                                          (binary)       Address Space
+    -----------------------------------   --------       -------------
+    Reserved                              0000 0000      1/256
+    Unassigned                            0000 0001      1/256
+
+    Reserved for NSAP Allocation          0000 001       1/128
+    Reserved for IPX Allocation           0000 010       1/128
+
+    Unassigned                            0000 011       1/128
+    Unassigned                            0000 1         1/32
+    Unassigned                            0001           1/16
+
+    Aggregatable Global Unicast Addresses 001            1/8
+    Unassigned                            010            1/8
+    Unassigned                            011            1/8
+    Unassigned                            100            1/8
+    Unassigned                            101            1/8
+    Unassigned                            110            1/8
+
+    Unassigned                            1110           1/16
+    Unassigned                            1111 0         1/32
+    Unassigned                            1111 10        1/64
+    Unassigned                            1111 110       1/128
+    Unassigned                            1111 1110 0    1/512
+
+    Link-Local Unicast Addresses          1111 1110 10   1/1024
+    Site-Local Unicast Addresses          1111 1110 11   1/1024
+
+    Multicast Addresses                   1111 1111      1/256
+
+    Notes:
+
+      (1) The "unspecified address" (see section 2.5.2), the loopback
+          address (see section 2.5.3), and the IPv6 Addresses with
+          Embedded IPv4 Addresses (see section 2.5.4), are assigned out
+          of the 0000 0000 format prefix space.
+
+
+
+
+
+
+
+Hinden & Deering            Standards Track                     [Page 6]
+
+RFC 2373              IPv6 Addressing Architecture             July 1998
+
+
+      (2) The format prefixes 001 through 111, except for Multicast
+          Addresses (1111 1111), are all required to have to have 64-bit
+          interface identifiers in EUI-64 format.  See section 2.5.1 for
+          definitions.
+
+   This allocation supports the direct allocation of aggregation
+   addresses, local use addresses, and multicast addresses.  Space is
+   reserved for NSAP addresses and IPX addresses.  The remainder of the
+   address space is unassigned for future use.  This can be used for
+   expansion of existing use (e.g., additional aggregatable addresses,
+   etc.) or new uses (e.g., separate locators and identifiers).  Fifteen
+   percent of the address space is initially allocated.  The remaining
+   85% is reserved for future use.
+
+   Unicast addresses are distinguished from multicast addresses by the
+   value of the high-order octet of the addresses: a value of FF
+   (11111111) identifies an address as a multicast address; any other
+   value identifies an address as a unicast address.  Anycast addresses
+   are taken from the unicast address space, and are not syntactically
+   distinguishable from unicast addresses.
+
+2.5 Unicast Addresses
+
+   IPv6 unicast addresses are aggregatable with contiguous bit-wise
+   masks similar to IPv4 addresses under Class-less Interdomain Routing
+   [CIDR].
+
+   There are several forms of unicast address assignment in IPv6,
+   including the global aggregatable global unicast address, the NSAP
+   address, the IPX hierarchical address, the site-local address, the
+   link-local address, and the IPv4-capable host address.  Additional
+   address types can be defined in the future.
+
+   IPv6 nodes may have considerable or little knowledge of the internal
+   structure of the IPv6 address, depending on the role the node plays
+   (for instance, host versus router).  At a minimum, a node may
+   consider that unicast addresses (including its own) have no internal
+   structure:
+
+   |                           128 bits                              |
+   +-----------------------------------------------------------------+
+   |                          node address                           |
+   +-----------------------------------------------------------------+
+
+   A slightly sophisticated host (but still rather simple) may
+   additionally be aware of subnet prefix(es) for the link(s) it is
+   attached to, where different addresses may have different values for
+   n:
+
+
+
+Hinden & Deering            Standards Track                     [Page 7]
+
+RFC 2373              IPv6 Addressing Architecture             July 1998
+
+
+   |                         n bits                 |   128-n bits   |
+   +------------------------------------------------+----------------+
+   |                   subnet prefix                | interface ID   |
+   +------------------------------------------------+----------------+
+
+   Still more sophisticated hosts may be aware of other hierarchical
+   boundaries in the unicast address.  Though a very simple router may
+   have no knowledge of the internal structure of IPv6 unicast
+   addresses, routers will more generally have knowledge of one or more
+   of the hierarchical boundaries for the operation of routing
+   protocols.  The known boundaries will differ from router to router,
+   depending on what positions the router holds in the routing
+   hierarchy.
+
+2.5.1 Interface Identifiers
+
+   Interface identifiers in IPv6 unicast addresses are used to identify
+   interfaces on a link.  They are required to be unique on that link.
+   They may also be unique over a broader scope.  In many cases an
+   interface's identifier will be the same as that interface's link-
+   layer address.  The same interface identifier may be used on multiple
+   interfaces on a single node.
+
+   Note that the use of the same interface identifier on multiple
+   interfaces of a single node does not affect the interface
+   identifier's global uniqueness or each IPv6 addresses global
+   uniqueness created using that interface identifier.
+
+   In a number of the format prefixes (see section 2.4) Interface IDs
+   are required to be 64 bits long and to be constructed in IEEE EUI-64
+   format [EUI64].  EUI-64 based Interface identifiers may have global
+   scope when a global token is available (e.g., IEEE 48bit MAC) or may
+   have local scope where a global token is not available (e.g., serial
+   links, tunnel end-points, etc.).  It is required that the "u" bit
+   (universal/local bit in IEEE EUI-64 terminology) be inverted when
+   forming the interface identifier from the EUI-64.  The "u" bit is set
+   to one (1) to indicate global scope, and it is set to zero (0) to
+   indicate local scope.  The first three octets in binary of an EUI-64
+   identifier are as follows:
+
+       0       0 0       1 1       2
+      |0       7 8       5 6       3|
+      +----+----+----+----+----+----+
+      |cccc|ccug|cccc|cccc|cccc|cccc|
+      +----+----+----+----+----+----+
+
+
+
+
+
+
+Hinden & Deering            Standards Track                     [Page 8]
+
+RFC 2373              IPv6 Addressing Architecture             July 1998
+
+
+   written in Internet standard bit-order , where "u" is the
+   universal/local bit, "g" is the individual/group bit, and "c" are the
+   bits of the company_id.  Appendix A: "Creating EUI-64 based Interface
+   Identifiers" provides examples on the creation of different EUI-64
+   based interface identifiers.
+
+   The motivation for inverting the "u" bit when forming the interface
+   identifier is to make it easy for system administrators to hand
+   configure local scope identifiers when hardware tokens are not
+   available.  This is expected to be case for serial links, tunnel end-
+   points, etc.  The alternative would have been for these to be of the
+   form 0200:0:0:1, 0200:0:0:2, etc., instead of the much simpler ::1,
+   ::2, etc.
+
+   The use of the universal/local bit in the IEEE EUI-64 identifier is
+   to allow development of future technology that can take advantage of
+   interface identifiers with global scope.
+
+   The details of forming interface identifiers are defined in the
+   appropriate "IPv6 over <link>" specification such as "IPv6 over
+   Ethernet" [ETHER], "IPv6 over FDDI" [FDDI], etc.
+
+2.5.2 The Unspecified Address
+
+   The address 0:0:0:0:0:0:0:0 is called the unspecified address.  It
+   must never be assigned to any node.  It indicates the absence of an
+   address.  One example of its use is in the Source Address field of
+   any IPv6 packets sent by an initializing host before it has learned
+   its own address.
+
+   The unspecified address must not be used as the destination address
+   of IPv6 packets or in IPv6 Routing Headers.
+
+2.5.3 The Loopback Address
+
+   The unicast address 0:0:0:0:0:0:0:1 is called the loopback address.
+   It may be used by a node to send an IPv6 packet to itself.  It may
+   never be assigned to any physical interface.  It may be thought of as
+   being associated with a virtual interface (e.g., the loopback
+   interface).
+
+   The loopback address must not be used as the source address in IPv6
+   packets that are sent outside of a single node.  An IPv6 packet with
+   a destination address of loopback must never be sent outside of a
+   single node and must never be forwarded by an IPv6 router.
+
+
+
+
+
+
+Hinden & Deering            Standards Track                     [Page 9]
+
+RFC 2373              IPv6 Addressing Architecture             July 1998
+
+
+2.5.4 IPv6 Addresses with Embedded IPv4 Addresses
+
+   The IPv6 transition mechanisms [TRAN] include a technique for hosts
+   and routers to dynamically tunnel IPv6 packets over IPv4 routing
+   infrastructure.  IPv6 nodes that utilize this technique are assigned
+   special IPv6 unicast addresses that carry an IPv4 address in the low-
+   order 32-bits.  This type of address is termed an "IPv4-compatible
+   IPv6 address" and has the format:
+
+   |                80 bits               | 16 |      32 bits        |
+   +--------------------------------------+--------------------------+
+   |0000..............................0000|0000|    IPv4 address     |
+   +--------------------------------------+----+---------------------+
+
+   A second type of IPv6 address which holds an embedded IPv4 address is
+   also defined.  This address is used to represent the addresses of
+   IPv4-only nodes (those that *do not* support IPv6) as IPv6 addresses.
+   This type of address is termed an "IPv4-mapped IPv6 address" and has
+   the format:
+
+   |                80 bits               | 16 |      32 bits        |
+   +--------------------------------------+--------------------------+
+   |0000..............................0000|FFFF|    IPv4 address     |
+   +--------------------------------------+----+---------------------+
+
+2.5.5 NSAP Addresses
+
+   This mapping of NSAP address into IPv6 addresses is defined in
+   [NSAP].  This document recommends that network implementors who have
+   planned or deployed an OSI NSAP addressing plan, and who wish to
+   deploy or transition to IPv6, should redesign a native IPv6
+   addressing plan to meet their needs.  However, it also defines a set
+   of mechanisms for the support of OSI NSAP addressing in an IPv6
+   network.  These mechanisms are the ones that must be used if such
+   support is required.  This document also defines a mapping of IPv6
+   addresses within the OSI address format, should this be required.
+
+2.5.6 IPX Addresses
+
+   This mapping of IPX address into IPv6 addresses is as follows:
+
+   |   7   |                   121 bits                              |
+   +-------+---------------------------------------------------------+
+   |0000010|                 to be defined                           |
+   +-------+---------------------------------------------------------+
+
+   The draft definition, motivation, and usage are under study.
+
+
+
+
+Hinden & Deering            Standards Track                    [Page 10]
+
+RFC 2373              IPv6 Addressing Architecture             July 1998
+
+
+2.5.7 Aggregatable Global Unicast Addresses
+
+   The global aggregatable global unicast address is defined in [AGGR].
+   This address format is designed to support both the current provider
+   based aggregation and a new type of aggregation called exchanges.
+   The combination will allow efficient routing aggregation for both
+   sites which connect directly to providers and who connect to
+   exchanges.  Sites will have the choice to connect to either type of
+   aggregation point.
+
+   The IPv6 aggregatable global unicast address format is as follows:
+
+   | 3|  13 | 8 |   24   |   16   |          64 bits               |
+   +--+-----+---+--------+--------+--------------------------------+
+   |FP| TLA |RES|  NLA   |  SLA   |         Interface ID           |
+   |  | ID  |   |  ID    |  ID    |                                |
+   +--+-----+---+--------+--------+--------------------------------+
+
+   Where
+
+      001          Format Prefix (3 bit) for Aggregatable Global
+                   Unicast Addresses
+      TLA ID       Top-Level Aggregation Identifier
+      RES          Reserved for future use
+      NLA ID       Next-Level Aggregation Identifier
+      SLA ID       Site-Level Aggregation Identifier
+      INTERFACE ID Interface Identifier
+
+   The contents, field sizes, and assignment rules are defined in
+   [AGGR].
+
+2.5.8 Local-Use IPv6 Unicast Addresses
+
+   There are two types of local-use unicast addresses defined.  These
+   are Link-Local and Site-Local.  The Link-Local is for use on a single
+   link and the Site-Local is for use in a single site.  Link-Local
+   addresses have the following format:
+
+   |   10     |
+   |  bits    |        54 bits          |          64 bits           |
+   +----------+-------------------------+----------------------------+
+   |1111111010|           0             |       interface ID         |
+   +----------+-------------------------+----------------------------+
+
+   Link-Local addresses are designed to be used for addressing on a
+   single link for purposes such as auto-address configuration, neighbor
+   discovery, or when no routers are present.
+
+
+
+
+Hinden & Deering            Standards Track                    [Page 11]
+
+RFC 2373              IPv6 Addressing Architecture             July 1998
+
+
+   Routers must not forward any packets with link-local source or
+   destination addresses to other links.
+
+   Site-Local addresses have the following format:
+
+   |   10     |
+   |  bits    |   38 bits   |  16 bits  |         64 bits            |
+   +----------+-------------+-----------+----------------------------+
+   |1111111011|    0        | subnet ID |       interface ID         |
+   +----------+-------------+-----------+----------------------------+
+
+   Site-Local addresses are designed to be used for addressing inside of
+   a site without the need for a global prefix.
+
+   Routers must not forward any packets with site-local source or
+   destination addresses outside of the site.
+
+2.6 Anycast Addresses
+
+   An IPv6 anycast address is an address that is assigned to more than
+   one interface (typically belonging to different nodes), with the
+   property that a packet sent to an anycast address is routed to the
+   "nearest" interface having that address, according to the routing
+   protocols' measure of distance.
+
+   Anycast addresses are allocated from the unicast address space, using
+   any of the defined unicast address formats.  Thus, anycast addresses
+   are syntactically indistinguishable from unicast addresses.  When a
+   unicast address is assigned to more than one interface, thus turning
+   it into an anycast address, the nodes to which the address is
+   assigned must be explicitly configured to know that it is an anycast
+   address.
+
+   For any assigned anycast address, there is a longest address prefix P
+   that identifies the topological region in which all interfaces
+   belonging to that anycast address reside.  Within the region
+   identified by P, each member of the anycast set must be advertised as
+   a separate entry in the routing system (commonly referred to as a
+   "host route"); outside the region identified by P, the anycast
+   address may be aggregated into the routing advertisement for prefix
+   P.
+
+   Note that in, the worst case, the prefix P of an anycast set may be
+   the null prefix, i.e., the members of the set may have no topological
+   locality.  In that case, the anycast address must be advertised as a
+   separate routing entry throughout the entire internet, which presents
+
+
+
+
+
+Hinden & Deering            Standards Track                    [Page 12]
+
+RFC 2373              IPv6 Addressing Architecture             July 1998
+
+
+   a severe scaling limit on how many such "global" anycast sets may be
+   supported.  Therefore, it is expected that support for global anycast
+   sets may be unavailable or very restricted.
+
+   One expected use of anycast addresses is to identify the set of
+   routers belonging to an organization providing internet service.
+   Such addresses could be used as intermediate addresses in an IPv6
+   Routing header, to cause a packet to be delivered via a particular
+   aggregation or sequence of aggregations.  Some other possible uses
+   are to identify the set of routers attached to a particular subnet,
+   or the set of routers providing entry into a particular routing
+   domain.
+
+   There is little experience with widespread, arbitrary use of internet
+   anycast addresses, and some known complications and hazards when
+   using them in their full generality [ANYCST].  Until more experience
+   has been gained and solutions agreed upon for those problems, the
+   following restrictions are imposed on IPv6 anycast addresses:
+
+      o An anycast address must not be used as the source address of an
+        IPv6 packet.
+
+      o An anycast address must not be assigned to an IPv6 host, that
+        is, it may be assigned to an IPv6 router only.
+
+2.6.1 Required Anycast Address
+
+   The Subnet-Router anycast address is predefined.  Its format is as
+   follows:
+
+   |                         n bits                 |   128-n bits   |
+   +------------------------------------------------+----------------+
+   |                   subnet prefix                | 00000000000000 |
+   +------------------------------------------------+----------------+
+
+   The "subnet prefix" in an anycast address is the prefix which
+   identifies a specific link.  This anycast address is syntactically
+   the same as a unicast address for an interface on the link with the
+   interface identifier set to zero.
+
+   Packets sent to the Subnet-Router anycast address will be delivered
+   to one router on the subnet.  All routers are required to support the
+   Subnet-Router anycast addresses for the subnets which they have
+   interfaces.
+
+
+
+
+
+
+
+Hinden & Deering            Standards Track                    [Page 13]
+
+RFC 2373              IPv6 Addressing Architecture             July 1998
+
+
+   The subnet-router anycast address is intended to be used for
+   applications where a node needs to communicate with one of a set of
+   routers on a remote subnet.  For example when a mobile host needs to
+   communicate with one of the mobile agents on its "home" subnet.
+
+2.7 Multicast Addresses
+
+   An IPv6 multicast address is an identifier for a group of nodes.  A
+   node may belong to any number of multicast groups.  Multicast
+   addresses have the following format:
+
+   |   8    |  4 |  4 |                  112 bits                   |
+   +------ -+----+----+---------------------------------------------+
+   |11111111|flgs|scop|                  group ID                   |
+   +--------+----+----+---------------------------------------------+
+
+      11111111 at the start of the address identifies the address as
+      being a multicast address.
+
+                                    +-+-+-+-+
+      flgs is a set of 4 flags:     |0|0|0|T|
+                                    +-+-+-+-+
+
+         The high-order 3 flags are reserved, and must be initialized to
+         0.
+
+         T = 0 indicates a permanently-assigned ("well-known") multicast
+         address, assigned by the global internet numbering authority.
+
+         T = 1 indicates a non-permanently-assigned ("transient")
+         multicast address.
+
+      scop is a 4-bit multicast scope value used to limit the scope of
+      the multicast group.  The values are:
+
+         0  reserved
+         1  node-local scope
+         2  link-local scope
+         3  (unassigned)
+         4  (unassigned)
+         5  site-local scope
+         6  (unassigned)
+         7  (unassigned)
+         8  organization-local scope
+         9  (unassigned)
+         A  (unassigned)
+         B  (unassigned)
+         C  (unassigned)
+
+
+
+Hinden & Deering            Standards Track                    [Page 14]
+
+RFC 2373              IPv6 Addressing Architecture             July 1998
+
+
+         D  (unassigned)
+         E  global scope
+         F  reserved
+
+      group ID identifies the multicast group, either permanent or
+      transient, within the given scope.
+
+   The "meaning" of a permanently-assigned multicast address is
+   independent of the scope value.  For example, if the "NTP servers
+   group" is assigned a permanent multicast address with a group ID of
+   101 (hex), then:
+
+      FF01:0:0:0:0:0:0:101 means all NTP servers on the same node as the
+      sender.
+
+      FF02:0:0:0:0:0:0:101 means all NTP servers on the same link as the
+      sender.
+
+      FF05:0:0:0:0:0:0:101 means all NTP servers at the same site as the
+      sender.
+
+      FF0E:0:0:0:0:0:0:101 means all NTP servers in the internet.
+
+   Non-permanently-assigned multicast addresses are meaningful only
+   within a given scope.  For example, a group identified by the non-
+   permanent, site-local multicast address FF15:0:0:0:0:0:0:101 at one
+   site bears no relationship to a group using the same address at a
+   different site, nor to a non-permanent group using the same group ID
+   with different scope, nor to a permanent group with the same group
+   ID.
+
+   Multicast addresses must not be used as source addresses in IPv6
+   packets or appear in any routing header.
+
+2.7.1 Pre-Defined Multicast Addresses
+
+   The following well-known multicast addresses are pre-defined:
+
+      Reserved Multicast Addresses:   FF00:0:0:0:0:0:0:0
+                                      FF01:0:0:0:0:0:0:0
+                                      FF02:0:0:0:0:0:0:0
+                                      FF03:0:0:0:0:0:0:0
+                                      FF04:0:0:0:0:0:0:0
+                                      FF05:0:0:0:0:0:0:0
+                                      FF06:0:0:0:0:0:0:0
+                                      FF07:0:0:0:0:0:0:0
+                                      FF08:0:0:0:0:0:0:0
+                                      FF09:0:0:0:0:0:0:0
+
+
+
+Hinden & Deering            Standards Track                    [Page 15]
+
+RFC 2373              IPv6 Addressing Architecture             July 1998
+
+
+                                      FF0A:0:0:0:0:0:0:0
+                                      FF0B:0:0:0:0:0:0:0
+                                      FF0C:0:0:0:0:0:0:0
+                                      FF0D:0:0:0:0:0:0:0
+                                      FF0E:0:0:0:0:0:0:0
+                                      FF0F:0:0:0:0:0:0:0
+
+   The above multicast addresses are reserved and shall never be
+   assigned to any multicast group.
+
+      All Nodes Addresses:    FF01:0:0:0:0:0:0:1
+                              FF02:0:0:0:0:0:0:1
+
+   The above multicast addresses identify the group of all IPv6 nodes,
+   within scope 1 (node-local) or 2 (link-local).
+
+      All Routers Addresses:   FF01:0:0:0:0:0:0:2
+                               FF02:0:0:0:0:0:0:2
+                               FF05:0:0:0:0:0:0:2
+
+   The above multicast addresses identify the group of all IPv6 routers,
+   within scope 1 (node-local), 2 (link-local), or 5 (site-local).
+
+      Solicited-Node Address:  FF02:0:0:0:0:1:FFXX:XXXX
+
+   The above multicast address is computed as a function of a node's
+   unicast and anycast addresses.  The solicited-node multicast address
+   is formed by taking the low-order 24 bits of the address (unicast or
+   anycast) and appending those bits to the prefix
+   FF02:0:0:0:0:1:FF00::/104 resulting in a multicast address in the
+   range
+
+      FF02:0:0:0:0:1:FF00:0000
+
+   to
+
+      FF02:0:0:0:0:1:FFFF:FFFF
+
+   For example, the solicited node multicast address corresponding to
+   the IPv6 address 4037::01:800:200E:8C6C is FF02::1:FF0E:8C6C.  IPv6
+   addresses that differ only in the high-order bits, e.g. due to
+   multiple high-order prefixes associated with different aggregations,
+   will map to the same solicited-node address thereby reducing the
+   number of multicast addresses a node must join.
+
+   A node is required to compute and join the associated Solicited-Node
+   multicast addresses for every unicast and anycast address it is
+   assigned.
+
+
+
+Hinden & Deering            Standards Track                    [Page 16]
+
+RFC 2373              IPv6 Addressing Architecture             July 1998
+
+
+2.7.2 Assignment of New IPv6 Multicast Addresses
+
+   The current approach [ETHER] to map IPv6 multicast addresses into
+   IEEE 802 MAC addresses takes the low order 32 bits of the IPv6
+   multicast address and uses it to create a MAC address.  Note that
+   Token Ring networks are handled differently.  This is defined in
+   [TOKEN].  Group ID's less than or equal to 32 bits will generate
+   unique MAC addresses.  Due to this new IPv6 multicast addresses
+   should be assigned so that the group identifier is always in the low
+   order 32 bits as shown in the following:
+
+   |   8    |  4 |  4 |          80 bits          |     32 bits     |
+   +------ -+----+----+---------------------------+-----------------+
+   |11111111|flgs|scop|   reserved must be zero   |    group ID     |
+   +--------+----+----+---------------------------+-----------------+
+
+   While this limits the number of permanent IPv6 multicast groups to
+   2^32 this is unlikely to be a limitation in the future.  If it
+   becomes necessary to exceed this limit in the future multicast will
+   still work but the processing will be sightly slower.
+
+   Additional IPv6 multicast addresses are defined and registered by the
+   IANA [MASGN].
+
+2.8 A Node's Required Addresses
+
+   A host is required to recognize the following addresses as
+   identifying itself:
+
+      o Its Link-Local Address for each interface
+      o Assigned Unicast Addresses
+      o Loopback Address
+      o All-Nodes Multicast Addresses
+      o Solicited-Node Multicast Address for each of its assigned
+        unicast and anycast addresses
+      o Multicast Addresses of all other groups to which the host
+        belongs.
+
+   A router is required to recognize all addresses that a host is
+   required to recognize, plus the following addresses as identifying
+   itself:
+
+      o The Subnet-Router anycast addresses for the interfaces it is
+        configured to act as a router on.
+      o All other Anycast addresses with which the router has been
+        configured.
+      o All-Routers Multicast Addresses
+
+
+
+
+Hinden & Deering            Standards Track                    [Page 17]
+
+RFC 2373              IPv6 Addressing Architecture             July 1998
+
+
+      o Multicast Addresses of all other groups to which the router
+        belongs.
+
+   The only address prefixes which should be predefined in an
+   implementation are the:
+
+      o Unspecified Address
+      o Loopback Address
+      o Multicast Prefix (FF)
+      o Local-Use Prefixes (Link-Local and Site-Local)
+      o Pre-Defined Multicast Addresses
+      o IPv4-Compatible Prefixes
+
+   Implementations should assume all other addresses are unicast unless
+   specifically configured (e.g., anycast addresses).
+
+3. Security Considerations
+
+   IPv6 addressing documents do not have any direct impact on Internet
+   infrastructure security.  Authentication of IPv6 packets is defined
+   in [AUTH].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hinden & Deering            Standards Track                    [Page 18]
+
+RFC 2373              IPv6 Addressing Architecture             July 1998
+
+
+APPENDIX A : Creating EUI-64 based Interface Identifiers
+--------------------------------------------------------
+
+   Depending on the characteristics of a specific link or node there are
+   a number of approaches for creating EUI-64 based interface
+   identifiers.  This appendix describes some of these approaches.
+
+Links or Nodes with EUI-64 Identifiers
+
+   The only change needed to transform an EUI-64 identifier to an
+   interface identifier is to invert the "u" (universal/local) bit.  For
+   example, a globally unique EUI-64 identifier of the form:
+
+   |0              1|1              3|3              4|4              6|
+   |0              5|6              1|2              7|8              3|
+   +----------------+----------------+----------------+----------------+
+   |cccccc0gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm|mmmmmmmmmmmmmmmm|
+   +----------------+----------------+----------------+----------------+
+
+   where "c" are the bits of the assigned company_id, "0" is the value
+   of the universal/local bit to indicate global scope, "g" is
+   individual/group bit, and "m" are the bits of the manufacturer-
+   selected extension identifier.  The IPv6 interface identifier would
+   be of the form:
+
+   |0              1|1              3|3              4|4              6|
+   |0              5|6              1|2              7|8              3|
+   +----------------+----------------+----------------+----------------+
+   |cccccc1gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm|mmmmmmmmmmmmmmmm|
+   +----------------+----------------+----------------+----------------+
+
+   The only change is inverting the value of the universal/local bit.
+
+Links or Nodes with IEEE 802 48 bit MAC's
+
+   [EUI64] defines a method to create a EUI-64 identifier from an IEEE
+   48bit MAC identifier.  This is to insert two octets, with hexadecimal
+   values of 0xFF and 0xFE, in the middle of the 48 bit MAC (between the
+   company_id and vendor supplied id).  For example the 48 bit MAC with
+   global scope:
+
+   |0              1|1              3|3              4|
+   |0              5|6              1|2              7|
+   +----------------+----------------+----------------+
+   |cccccc0gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm|
+   +----------------+----------------+----------------+
+
+
+
+
+
+Hinden & Deering            Standards Track                    [Page 19]
+
+RFC 2373              IPv6 Addressing Architecture             July 1998
+
+
+   where "c" are the bits of the assigned company_id, "0" is the value
+   of the universal/local bit to indicate global scope, "g" is
+   individual/group bit, and "m" are the bits of the manufacturer-
+   selected extension identifier.  The interface identifier would be of
+   the form:
+
+   |0              1|1              3|3              4|4              6|
+   |0              5|6              1|2              7|8              3|
+   +----------------+----------------+----------------+----------------+
+   |cccccc1gcccccccc|cccccccc11111111|11111110mmmmmmmm|mmmmmmmmmmmmmmmm|
+   +----------------+----------------+----------------+----------------+
+
+   When IEEE 802 48bit MAC addresses are available (on an interface or a
+   node), an implementation should use them to create interface
+   identifiers due to their availability and uniqueness properties.
+
+Links with Non-Global Identifiers
+
+   There are a number of types of links that, while multi-access, do not
+   have globally unique link identifiers.  Examples include LocalTalk
+   and Arcnet.  The method to create an EUI-64 formatted identifier is
+   to take the link identifier (e.g., the LocalTalk 8 bit node
+   identifier) and zero fill it to the left.  For example a LocalTalk 8
+   bit node identifier of hexadecimal value 0x4F results in the
+   following interface identifier:
+
+   |0              1|1              3|3              4|4              6|
+   |0              5|6              1|2              7|8              3|
+   +----------------+----------------+----------------+----------------+
+   |0000000000000000|0000000000000000|0000000000000000|0000000001001111|
+   +----------------+----------------+----------------+----------------+
+
+   Note that this results in the universal/local bit set to "0" to
+   indicate local scope.
+
+Links without Identifiers
+
+   There are a number of links that do not have any type of built-in
+   identifier.  The most common of these are serial links and configured
+   tunnels.  Interface identifiers must be chosen that are unique for
+   the link.
+
+   When no built-in identifier is available on a link the preferred
+   approach is to use a global interface identifier from another
+   interface or one which is assigned to the node itself.  To use this
+   approach no other interface connecting the same node to the same link
+   may use the same identifier.
+
+
+
+
+Hinden & Deering            Standards Track                    [Page 20]
+
+RFC 2373              IPv6 Addressing Architecture             July 1998
+
+
+   If there is no global interface identifier available for use on the
+   link the implementation needs to create a local scope interface
+   identifier.  The only requirement is that it be unique on the link.
+   There are many possible approaches to select a link-unique interface
+   identifier.  They include:
+
+      Manual Configuration
+      Generated Random Number
+      Node Serial Number (or other node-specific token)
+
+   The link-unique interface identifier should be generated in a manner
+   that it does not change after a reboot of a node or if interfaces are
+   added or deleted from the node.
+
+   The selection of the appropriate algorithm is link and implementation
+   dependent.  The details on forming interface identifiers are defined
+   in the appropriate "IPv6 over <link>" specification.  It is strongly
+   recommended that a collision detection algorithm be implemented as
+   part of any automatic algorithm.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hinden & Deering            Standards Track                    [Page 21]
+
+RFC 2373              IPv6 Addressing Architecture             July 1998
+
+
+APPENDIX B: ABNF Description of Text Representations
+----------------------------------------------------
+
+   This appendix defines the text representation of IPv6 addresses and
+   prefixes in Augmented BNF [ABNF] for reference purposes.
+
+      IPv6address = hexpart [ ":" IPv4address ]
+      IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT
+
+      IPv6prefix  = hexpart "/" 1*2DIGIT
+
+      hexpart = hexseq | hexseq "::" [ hexseq ] | "::" [ hexseq ]
+      hexseq  = hex4 *( ":" hex4)
+      hex4    = 1*4HEXDIG
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hinden & Deering            Standards Track                    [Page 22]
+
+RFC 2373              IPv6 Addressing Architecture             July 1998
+
+
+APPENDIX C: CHANGES FROM RFC-1884
+---------------------------------
+
+   The following changes were made from RFC-1884 "IP Version 6
+   Addressing Architecture":
+
+      - Added an appendix providing a ABNF description of text
+        representations.
+      - Clarification that link unique identifiers not change after
+        reboot or other interface reconfigurations.
+      - Clarification of Address Model based on comments.
+      - Changed aggregation format terminology to be consistent with
+        aggregation draft.
+      - Added text to allow interface identifier to be used on more than
+        one interface on same node.
+      - Added rules for defining new multicast addresses.
+      - Added appendix describing procedures for creating EUI-64 based
+        interface ID's.
+      - Added notation for defining IPv6 prefixes.
+      - Changed solicited node multicast definition to use a longer
+        prefix.
+      - Added site scope all routers multicast address.
+      - Defined Aggregatable Global Unicast Addresses to use "001" Format
+        Prefix.
+      - Changed "010" (Provider-Based Unicast) and "100" (Reserved for
+        Geographic) Format Prefixes to Unassigned.
+      - Added section on Interface ID definition for unicast addresses.
+        Requires use of EUI-64 in range of format prefixes and rules for
+        setting global/local scope bit in EUI-64.
+      - Updated NSAP text to reflect working in RFC1888.
+      - Removed protocol specific IPv6 multicast addresses (e.g., DHCP)
+        and referenced the IANA definitions.
+      - Removed section "Unicast Address Example".  Had become OBE.
+      - Added new and updated references.
+      - Minor text clarifications and improvements.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hinden & Deering            Standards Track                    [Page 23]
+
+RFC 2373              IPv6 Addressing Architecture             July 1998
+
+
+REFERENCES
+
+   [ABNF]    Crocker, D., and P. Overell, "Augmented BNF for
+             Syntax Specifications: ABNF", RFC 2234, November 1997.
+
+   [AGGR]    Hinden, R., O'Dell, M., and S. Deering, "An
+             Aggregatable Global Unicast Address Format", RFC 2374, July
+             1998.
+
+   [AUTH]    Atkinson, R., "IP Authentication Header", RFC 1826, August
+             1995.
+
+   [ANYCST]  Partridge, C., Mendez, T., and W. Milliken, "Host
+             Anycasting Service", RFC 1546, November 1993.
+
+   [CIDR]    Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless
+             Inter-Domain Routing (CIDR): An Address Assignment and
+             Aggregation Strategy", RFC 1519, September 1993.
+
+   [ETHER]   Crawford, M., "Transmission of IPv6 Pacekts over Ethernet
+             Networks", Work in Progress.
+
+   [EUI64]   IEEE, "Guidelines for 64-bit Global Identifier (EUI-64)
+             Registration Authority",
+             http://standards.ieee.org/db/oui/tutorials/EUI64.html,
+             March 1997.
+
+   [FDDI]    Crawford, M., "Transmission of IPv6 Packets over FDDI
+             Networks", Work in Progress.
+
+   [IPV6]    Deering, S., and R. Hinden, Editors, "Internet Protocol,
+             Version 6 (IPv6) Specification", RFC 1883, December 1995.
+
+   [MASGN]   Hinden, R., and S. Deering, "IPv6 Multicast Address
+             Assignments", RFC 2375, July 1998.
+
+   [NSAP]    Bound, J., Carpenter, B., Harrington, D., Houldsworth, J.,
+             and A. Lloyd, "OSI NSAPs and IPv6", RFC 1888, August 1996.
+
+   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+             Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [TOKEN]   Thomas, S., "Transmission of IPv6 Packets over Token Ring
+             Networks", Work in Progress.
+
+   [TRAN]    Gilligan, R., and E. Nordmark, "Transition Mechanisms for
+             IPv6 Hosts and Routers", RFC 1993, April 1996.
+
+
+
+
+Hinden & Deering            Standards Track                    [Page 24]
+
+RFC 2373              IPv6 Addressing Architecture             July 1998
+
+
+AUTHORS' ADDRESSES
+
+   Robert M. Hinden
+   Nokia
+   232 Java Drive
+   Sunnyvale, CA 94089
+   USA
+
+   Phone: +1 408 990-2004
+   Fax:   +1 408 743-5677
+   EMail: hinden@iprg.nokia.com
+
+
+   Stephen E. Deering
+   Cisco Systems, Inc.
+   170 West Tasman Drive
+   San Jose, CA 95134-1706
+   USA
+
+   Phone: +1 408 527-8213
+   Fax:   +1 408 527-8254
+   EMail: deering@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hinden & Deering            Standards Track                    [Page 25]
+
+RFC 2373              IPv6 Addressing Architecture             July 1998
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (1998).  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 Standards process must be
+   followed, or as required to translate it into 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hinden & Deering            Standards Track                    [Page 26]
+
diff --git a/doc/rfc/rfc2374.txt b/doc/rfc/rfc2374.txt
new file mode 100644
index 0000000..e3c7f0d
--- /dev/null
+++ b/doc/rfc/rfc2374.txt
@@ -0,0 +1,675 @@
+
+
+
+
+
+
+Network Working Group                                        R. Hinden
+Request for Comments: 2374                                       Nokia
+Obsoletes: 2073                                              M. O'Dell
+Category: Standards Track                                        UUNET
+                                                            S. Deering
+                                                                 Cisco
+                                                             July 1998
+
+
+           An IPv6 Aggregatable Global Unicast Address Format
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (1998).  All Rights Reserved.
+
+1.0 Introduction
+
+   This document defines an IPv6 aggregatable global unicast address
+   format for use in the Internet.  The address format defined in this
+   document is consistent with the IPv6 Protocol [IPV6] and the "IPv6
+   Addressing Architecture" [ARCH].  It is designed to facilitate
+   scalable Internet routing.
+
+   This documented replaces RFC 2073, "An IPv6 Provider-Based Unicast
+   Address Format".  RFC 2073 will become historic.  The Aggregatable
+   Global Unicast Address Format is an improvement over RFC 2073 in a
+   number of areas.  The major changes include removal of the registry
+   bits because they are not needed for route aggregation, support of
+   EUI-64 based interface identifiers, support of provider and exchange
+   based aggregation, separation of public and site topology, and new
+   aggregation based terminology.
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC 2119].
+
+
+
+
+
+
+
+
+Hinden, et. al.             Standards Track                     [Page 1]
+
+RFC 2374           IPv6 Global Unicast Address Format          July 1998
+
+
+2.0 Overview of the IPv6 Address
+
+   IPv6 addresses are 128-bit identifiers for interfaces and sets of
+   interfaces.  There are three types of addresses: Unicast, Anycast,
+   and Multicast.  This document defines a specific type of Unicast
+   address.
+
+   In this document, fields in addresses are given specific names, for
+   example "subnet".  When this name is used with the term "ID" (for
+   "identifier") after the name (e.g., "subnet ID"), it refers to the
+   contents of the named field.  When it is used with the term "prefix"
+   (e.g.  "subnet prefix") it refers to all of the addressing bits to
+   the left of and including this field.
+
+   IPv6 unicast addresses are designed assuming that the Internet
+   routing system makes forwarding decisions based on a "longest prefix
+   match" algorithm on arbitrary bit boundaries and does not have any
+   knowledge of the internal structure of IPv6 addresses.  The structure
+   in IPv6 addresses is for assignment and allocation.  The only
+   exception to this is the distinction made between unicast and
+   multicast addresses.
+
+   The specific type of an IPv6 address is indicated by the leading bits
+   in the address.  The variable-length field comprising these leading
+   bits is called the Format Prefix (FP).
+
+   This document defines an address format for the 001 (binary) Format
+   Prefix for Aggregatable Global Unicast addresses. The same address
+   format could be used for other Format Prefixes, as long as these
+   Format Prefixes also identify IPv6 unicast addresses.  Only the "001"
+   Format Prefix is defined here.
+
+3.0 IPv6 Aggregatable Global Unicast Address Format
+
+   This document defines an address format for the IPv6 aggregatable
+   global unicast address assignment.  The authors believe that this
+   address format will be widely used for IPv6 nodes connected to the
+   Internet.  This address format is designed to support both the
+   current provider-based aggregation and a new type of exchange-based
+   aggregation.  The combination will allow efficient routing
+   aggregation for sites that connect directly to providers and for
+   sites that connect to exchanges.  Sites will have the choice to
+   connect to either type of aggregation entity.
+
+
+
+
+
+
+
+
+Hinden, et. al.             Standards Track                     [Page 2]
+
+RFC 2374           IPv6 Global Unicast Address Format          July 1998
+
+
+   While this address format is designed to support exchange-based
+   aggregation (in addition to current provider-based aggregation) it is
+   not dependent on exchanges for it's overall route aggregation
+   properties.  It will provide efficient route aggregation with only
+   provider-based aggregation.
+
+   Aggregatable addresses are organized into a three level hierarchy:
+
+      - Public Topology
+      - Site Topology
+      - Interface Identifier
+
+   Public topology is the collection of providers and exchanges who
+   provide public Internet transit services.  Site topology is local to
+   a specific site or organization which does not provide public transit
+   service to nodes outside of the site.  Interface identifiers identify
+   interfaces on links.
+
+        ______________                  ______________
+    --+/              \+--------------+/              \+----------
+      (       P1       )    +----+    (       P3       )  +----+
+      +\______________/     |    |----+\______________/+--|    |--
+      |                  +--| X1 |                       +| X2 |
+      | ______________  /   |    |-+    ______________  / |    |--
+      +/              \+    +-+--+  \  /              \+  +----+
+      (       P2       )     / \     +(      P4        )
+    --+\______________/     /   \      \______________/
+           |               /     \           |      |
+           |              /       |          |      |
+           |             /        |          |      |
+          _|_          _/_       _|_        _|_    _|_
+         /   \        /   \     /   \      /   \  /   \
+        ( S.A )      ( S.B )   ( P5  )    ( P6  )( S.C )
+         \___/        \___/     \___/      \___/  \___/
+                                  |          / \
+                                 _|_       _/_  \   ___
+                                /   \     /   \  +-/   \
+                               ( S.D )   ( S.E )  ( S.F )
+                                \___/     \___/    \___/
+
+   As shown in the figure above, the aggregatable address format is
+   designed to support long-haul providers (shown as P1, P2, P3, and
+   P4), exchanges (shown as X1 and X2), multiple levels of providers
+   (shown at P5 and P6), and subscribers (shown as S.x) Exchanges
+   (unlike current NAPs, FIXes, etc.) will allocate IPv6 addresses.
+   Organizations who connect to these exchanges will also subscribe
+   (directly, indirectly via the exchange, etc.) for long-haul service
+   from one or more long-haul providers.  Doing so, they will achieve
+
+
+
+Hinden, et. al.             Standards Track                     [Page 3]
+
+RFC 2374           IPv6 Global Unicast Address Format          July 1998
+
+
+   addressing independence from long-haul transit providers.  They will
+   be able to change long-haul providers without having to renumber
+   their organization.  They can also be multihomed via the exchange to
+   more than one long-haul provider without having to have address
+   prefixes from each long-haul provider.  Note that the mechanisms used
+   for this type of provider selection and portability are not discussed
+   in the document.
+
+3.1 Aggregatable Global Unicast Address Structure
+
+   The aggregatable global unicast address format is as follows:
+
+     | 3|  13 | 8 |   24   |   16   |          64 bits               |
+     +--+-----+---+--------+--------+--------------------------------+
+     |FP| TLA |RES|  NLA   |  SLA   |         Interface ID           |
+     |  | ID  |   |  ID    |  ID    |                                |
+     +--+-----+---+--------+--------+--------------------------------+
+
+     <--Public Topology--->   Site
+                           <-------->
+                            Topology
+                                     <------Interface Identifier----->
+
+   Where
+
+      FP           Format Prefix (001)
+      TLA ID       Top-Level Aggregation Identifier
+      RES          Reserved for future use
+      NLA ID       Next-Level Aggregation Identifier
+      SLA ID       Site-Level Aggregation Identifier
+      INTERFACE ID Interface Identifier
+
+   The following sections specify each part of the IPv6 Aggregatable
+   Global Unicast address format.
+
+3.2 Top-Level Aggregation ID
+
+   Top-Level Aggregation Identifiers (TLA ID) are the top level in the
+   routing hierarchy.  Default-free routers must have a routing table
+   entry for every active TLA ID and will probably have additional
+   entries providing routing information for the TLA ID in which they
+   are located.  They may have additional entries in order to optimize
+   routing for their specific topology, but the routing topology at all
+   levels must be designed to minimize the number of additional entries
+   fed into the default free routing tables.
+
+
+
+
+
+
+Hinden, et. al.             Standards Track                     [Page 4]
+
+RFC 2374           IPv6 Global Unicast Address Format          July 1998
+
+
+   This addressing format supports 8,192 (2^13) TLA ID's.  Additional
+   TLA ID's may be added by either growing the TLA field to the right
+   into the reserved field or by using this format for additional format
+   prefixes.
+
+   The issues relating to TLA ID assignment are beyond the scope of this
+   document.  They will be described in a document under preparation.
+
+3.3 Reserved
+
+   The Reserved field is reserved for future use and must be set to
+   zero.
+
+   The Reserved field allows for future growth of the TLA and NLA fields
+   as appropriate.  See section 4.0 for a discussion.
+
+3.4 Next-Level Aggregation Identifier
+
+   Next-Level Aggregation Identifier's are used by organizations
+   assigned a TLA ID to create an addressing hierarchy and to identify
+   sites.  The organization can assign the top part of the NLA ID in a
+   manner to create an addressing hierarchy appropriate to its network.
+   It can use the remainder of the bits in the field to identify sites
+   it wishes to serve.  This is shown as follows:
+
+      |  n  |      24-n bits     |   16   |    64 bits      |
+      +-----+--------------------+--------+-----------------+
+      |NLA1 |      Site ID       | SLA ID | Interface ID    |
+      +-----+--------------------+--------+-----------------+
+
+   Each organization assigned a TLA ID receives 24 bits of NLA ID space.
+   This NLA ID space allows each organization to provide service to
+   approximately as many organizations as the current IPv4 Internet can
+   support total networks.
+
+   Organizations assigned TLA ID's may also support NLA ID's in their
+   own Site ID space.  This allows the organization assigned a TLA ID to
+   provide service to organizations providing public transit service and
+   to organizations who do not provide public transit service.  These
+   organizations receiving an NLA ID may also choose to use their Site
+   ID space to support other NLA ID's.  This is shown as follows:
+
+
+
+
+
+
+
+
+
+
+Hinden, et. al.             Standards Track                     [Page 5]
+
+RFC 2374           IPv6 Global Unicast Address Format          July 1998
+
+
+   |  n  |      24-n bits     |   16   |    64 bits      |
+   +-----+--------------------+--------+-----------------+
+   |NLA1 |      Site ID       | SLA ID | Interface ID    |
+   +-----+--------------------+--------+-----------------+
+
+         |  m  |    24-n-m    |   16   |    64 bits      |
+         +-----+--------------+--------+-----------------+
+         |NLA2 |   Site ID    | SLA ID | Interface ID    |
+         +-----+--------------+--------+-----------------+
+
+               |  o  |24-n-m-o|   16   |    64 bits      |
+               +-----+--------+--------+-----------------+
+               |NLA3 | Site ID| SLA ID | Interface ID    |
+               +-----+--------+--------+-----------------+
+
+   The design of the bit layout of the NLA ID space for a specific TLA
+   ID is left to the organization responsible for that TLA ID.  Likewise
+   the design of the bit layout of the next level NLA ID is the
+   responsibility of the previous level NLA ID.  It is recommended that
+   organizations assigning NLA address space use "slow start" allocation
+   procedures similar to [RFC2050].
+
+   The design of an NLA ID allocation plan is a tradeoff between routing
+   aggregation efficiency and flexibility.  Creating hierarchies allows
+   for greater amount of aggregation and results in smaller routing
+   tables.  Flat NLA ID assignment provides for easier allocation and
+   attachment flexibility, but results in larger routing tables.
+
+3.5 Site-Level Aggregation Identifier
+
+   The SLA ID field is used by an individual organization to create its
+   own local addressing hierarchy and to identify subnets.  This is
+   analogous to subnets in IPv4 except that each organization has a much
+   greater number of subnets.  The 16 bit SLA ID field support 65,535
+   individual subnets.
+
+   Organizations may choose to either route their SLA ID "flat" (e.g.,
+   not create any logical relationship between the SLA identifiers that
+   results in larger routing tables), or to create a two or more level
+   hierarchy (that results in smaller routing tables) in the SLA ID
+   field.  The latter is shown as follows:
+
+
+
+
+
+
+
+
+
+
+Hinden, et. al.             Standards Track                     [Page 6]
+
+RFC 2374           IPv6 Global Unicast Address Format          July 1998
+
+
+   |  n  |   16-n     |              64 bits                |
+   +-----+------------+-------------------------------------+
+   |SLA1 |   Subnet   |            Interface ID             |
+   +-----+------------+-------------------------------------+
+
+         | m  |16-n-m |              64 bits                |
+         +----+-------+-------------------------------------+
+         |SLA2|Subnet |            Interface ID             |
+         +----+-------+-------------------------------------+
+
+   The approach chosen for structuring an SLA ID field is the
+   responsibility of the individual organization.
+
+   The number of subnets supported in this address format should be
+   sufficient for all but the largest of organizations.  Organizations
+   which need additional subnets can arrange with the organization they
+   are obtaining Internet service from to obtain additional site
+   identifiers and use this to create additional subnets.
+
+3.6 Interface ID
+
+   Interface identifiers are used to identify interfaces on a link.
+   They are required to be unique on that link.  They may also be unique
+   over a broader scope.  In many cases an interfaces identifier will be
+   the same or be based on the interface's link-layer address.
+   Interface IDs used in the aggregatable global unicast address format
+   are required to be 64 bits long and to be constructed in IEEE EUI-64
+   format [EUI-64].  These identifiers may have global scope when a
+   global token (e.g., IEEE 48bit MAC) is available or may have local
+   scope where a global token is not available (e.g., serial links,
+   tunnel end-points, etc.).  The "u" bit (universal/local bit in IEEE
+   EUI-64 terminology) in the EUI-64 identifier must be set correctly,
+   as defined in [ARCH], to indicate global or local scope.
+
+   The procedures for creating EUI-64 based Interface Identifiers is
+   defined in [ARCH].  The details on forming interface identifiers is
+   defined in the appropriate "IPv6 over <link>" specification such as
+   "IPv6 over Ethernet" [ETHER], "IPv6 over FDDI" [FDDI], etc.
+
+4.0 Technical Motivation
+
+   The design choices for the size of the fields in the aggregatable
+   address format were based on the need to meet a number of technical
+   requirements.  These are described in the following paragraphs.
+
+   The size of the Top-Level Aggregation Identifier is 13 bits.  This
+   allows for 8,192 TLA ID's.  This size was chosen to insure that the
+   default-free routing table in top level routers in the Internet is
+
+
+
+Hinden, et. al.             Standards Track                     [Page 7]
+
+RFC 2374           IPv6 Global Unicast Address Format          July 1998
+
+
+   kept within the limits, with a reasonable margin, of the current
+   routing technology.  The margin is important because default-free
+   routers will also carry a significant number of longer (i.e., more-
+   specific) prefixes for optimizing paths internal to a TLA and between
+   TLAs.
+
+   The important issue is not only the size of the default-free routing
+   table, but the complexity of the topology that determines the number
+   of copies of the default-free routes that a router must examine while
+   computing a forwarding table.  Current practice with IPv4 it is
+   common to see a prefix announced fifteen times via different paths.
+
+   The complexity of Internet topology is very likely to increase in the
+   future.  It is important that IPv6 default-free routing support
+   additional complexity as well as a considerably larger internet.
+
+   It should be noted for comparison that at the time of this writing
+   (spring, 1998) the IPv4 default-free routing table contains
+   approximately 50,000 prefixes.  While this shows that it is possible
+   to support more routes than 8,192 it is matter of debate if the
+   number of prefixes supported today in IPv4 is already too high for
+   current routing technology.  There are serious issues of route
+   stability as well as cases of providers not supporting all top level
+   prefixes.  The technical requirement was to pick a TLA ID size that
+   was below, with a reasonable margin, what was being done with IPv4.
+
+   The choice of 13 bits for the TLA field was an engineering
+   compromise.  Fewer bits would have been too small by not supporting
+   enough top level organizations.  More bits would have exceeded what
+   can be reasonably accommodated, with a reasonable margin, with
+   current routing technology in order to deal with the issues described
+   in the previous paragraphs.
+
+   If in the future, routing technology improves to support a larger
+   number of top level routes in the default-free routing tables there
+   are two choices on how to increase the number TLA identifiers.  The
+   first is to expand the TLA ID field into the reserved field.  This
+   would increase the number of TLA ID's to approximately 2 million.
+   The second approach is to allocate another format prefix (FP) for use
+   with this address format.  Either or a combination of these
+   approaches allows the number of TLA ID's to increase significantly.
+
+   The size of the Reserved field is 8 bits.  This size was chosen to
+   allow significant growth of either the TLA ID and/or the NLA ID
+   fields.
+
+   The size of the Next-Level Aggregation Identifier field is 24 bits.
+
+
+
+
+Hinden, et. al.             Standards Track                     [Page 8]
+
+RFC 2374           IPv6 Global Unicast Address Format          July 1998
+
+
+   This allows for approximately sixteen million NLA ID's if used in a
+   flat manner.  Used hierarchically it allows for a complexity roughly
+   equivalent to the IPv4 address space (assuming an average network
+   size of 254 interfaces).  If in the future additional room for
+   complexity is needed in the NLA ID, this may be accommodated by
+   extending the NLA ID into the Reserved field.
+
+   The size of the Site-Level Aggregation Identifier field is 16 bits.
+   This supports 65,535 individual subnets per site.  The design goal
+   for the size of this field was to be sufficient for all but the
+   largest of organizations.  Organizations which need additional
+   subnets can arrange with the organization they are obtaining Internet
+   service from to obtain additional site identifiers and use this to
+   create additional subnets.
+
+   The Site-Level Aggregation Identifier field was given a fixed size in
+   order to force the length of all prefixes identifying a particular
+   site to be the same length (i.e., 48 bits).  This facilitates
+   movement of sites in the topology (e.g., changing service providers
+   and multi-homing to multiple service providers).
+
+   The Interface ID Interface Identifier field is 64 bits.  This size
+   was chosen to meet the requirement specified in [ARCH] to support
+   EUI-64 based Interface Identifiers.
+
+5.0 Acknowledgments
+
+   The authors would like to express our thanks to Thomas Narten, Bob
+   Fink, Matt Crawford, Allison Mankin, Jim Bound, Christian Huitema,
+   Scott Bradner, Brian Carpenter, John Stewart, and Daniel Karrenberg
+   for their review and constructive comments.
+
+6.0 References
+
+   [ALLOC]   IAB and IESG, "IPv6 Address Allocation Management",
+             RFC 1881, December 1995.
+
+   [ARCH]    Hinden, R., "IP Version 6 Addressing Architecture",
+             RFC 2373, July 1998.
+
+   [AUTH]    Atkinson, R., "IP Authentication Header", RFC 1826, August
+             1995.
+
+   [AUTO]    Thompson, S., and T. Narten., "IPv6 Stateless Address
+             Autoconfiguration", RFC 1971, August 1996.
+
+   [ETHER]   Crawford, M., "Transmission of IPv6 Packets over Ethernet
+             Networks", Work in Progress.
+
+
+
+Hinden, et. al.             Standards Track                     [Page 9]
+
+RFC 2374           IPv6 Global Unicast Address Format          July 1998
+
+
+   [EUI64]   IEEE, "Guidelines for 64-bit Global Identifier (EUI-64)
+             Registration Authority",
+             http://standards.ieee.org/db/oui/tutorials/EUI64.html,
+             March 1997.
+
+   [FDDI]    Crawford, M., "Transmission of IPv6 Packets over FDDI
+             Networks", Work in Progress.
+
+   [IPV6]    Deering, S., and R. Hinden, "Internet Protocol, Version 6
+             (IPv6) Specification", RFC 1883, December 1995.
+
+   [RFC2050] Hubbard, K., Kosters, M., Conrad, D., Karrenberg, D.,
+             and J. Postel, "Internet Registry IP Allocation
+             Guidelines", BCP 12, RFC 1466, November 1996.
+
+   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+             Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+7.0 Security Considerations
+
+   IPv6 addressing documents do not have any direct impact on Internet
+   infrastructure security.  Authentication of IPv6 packets is defined
+   in [AUTH].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hinden, et. al.             Standards Track                    [Page 10]
+
+RFC 2374           IPv6 Global Unicast Address Format          July 1998
+
+
+8.0 Authors' Addresses
+
+   Robert M. Hinden
+   Nokia
+   232 Java Drive
+   Sunnyvale, CA 94089
+   USA
+
+   Phone: 1 408 990-2004
+   EMail: hinden@iprg.nokia.com
+
+
+   Mike O'Dell
+   UUNET Technologies, Inc.
+   3060 Williams Drive
+   Fairfax, VA 22030
+   USA
+
+   Phone: 1 703 206-5890
+   EMail: mo@uunet.uu.net
+
+
+   Stephen E. Deering
+   Cisco Systems, Inc.
+   170 West Tasman Drive
+   San Jose, CA 95134-1706
+   USA
+
+   Phone: 1 408 527-8213
+   EMail: deering@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hinden, et. al.             Standards Track                    [Page 11]
+
+RFC 2374           IPv6 Global Unicast Address Format          July 1998
+
+
+9.0  Full Copyright Statement
+
+   Copyright (C) The Internet Society (1998).  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 Standards process must be
+   followed, or as required to translate it into 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hinden, et. al.             Standards Track                    [Page 12]
+
diff --git a/doc/rfc/rfc2375.txt b/doc/rfc/rfc2375.txt
new file mode 100644
index 0000000..a1fe8b9
--- /dev/null
+++ b/doc/rfc/rfc2375.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+Network Working Group                                         R. Hinden
+Request for Comments: 2375                             Ipsilon Networks
+Category: Informational                                      S. Deering
+                                                                  Cisco
+                                                              July 1998
+
+
+                   IPv6 Multicast Address Assignments
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (1998).  All Rights Reserved.
+
+1.0 Introduction
+
+   This document defines the initial assignment of IPv6 multicast
+   addresses.  It is based on the "IP Version 6 Addressing Architecture"
+   [ADDARCH] and current IPv4 multicast address assignment found in
+   <ftp://venera.isi.edu/in-notes/iana/assignments/multicast-addresses>.
+   It adapts the IPv4 assignments that are relevant to IPv6 assignments.
+   IPv4 assignments that were not relevant were not converted into IPv6
+   assignments.  Comments are solicited on this conversion.
+
+   All other IPv6 multicast addresses are reserved.
+
+   Sections 2 and 3 specify reserved and preassigned IPv6 multicast
+   addresses.
+
+   [ADDRARCH] defines rules for assigning new IPv6 multicast addresses.
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC 2119].
+
+2. Fixed Scope Multicast Addresses
+
+   These permanently assigned multicast addresses are valid over a
+   specified scope value.
+
+
+
+
+
+
+
+Hinden & Deering             Informational                      [Page 1]
+
+RFC 2375           IPv6 Multicast Address Assignments          July 1998
+
+
+2.1 Node-Local Scope
+
+   FF01:0:0:0:0:0:0:1     All Nodes Address                  [ADDARCH]
+   FF01:0:0:0:0:0:0:2     All Routers Address                [ADDARCH]
+
+2.2 Link-Local Scope
+
+   FF02:0:0:0:0:0:0:1     All Nodes Address                  [ADDARCH]
+   FF02:0:0:0:0:0:0:2     All Routers Address                [ADDARCH]
+   FF02:0:0:0:0:0:0:3     Unassigned                             [JBP]
+   FF02:0:0:0:0:0:0:4     DVMRP Routers                  [RFC1075,JBP]
+   FF02:0:0:0:0:0:0:5     OSPFIGP                        [RFC2328,Moy]
+   FF02:0:0:0:0:0:0:6     OSPFIGP Designated Routers     [RFC2328,Moy]
+   FF02:0:0:0:0:0:0:7     ST Routers                    [RFC1190,KS14]
+   FF02:0:0:0:0:0:0:8     ST Hosts                      [RFC1190,KS14]
+   FF02:0:0:0:0:0:0:9     RIP Routers                        [RFC2080]
+   FF02:0:0:0:0:0:0:A     EIGRP Routers                    [Farinacci]
+   FF02:0:0:0:0:0:0:B     Mobile-Agents                 [Bill Simpson]
+
+   FF02:0:0:0:0:0:0:D     All PIM Routers                  [Farinacci]
+   FF02:0:0:0:0:0:0:E     RSVP-ENCAPSULATION                  [Braden]
+
+   FF02:0:0:0:0:0:1:1     Link Name                       [Harrington]
+   FF02:0:0:0:0:0:1:2     All-dhcp-agents              [Bound,Perkins]
+
+   FF02:0:0:0:0:1:FFXX:XXXX     Solicited-Node Address       [ADDARCH]
+
+2.3 Site-Local Scope
+
+   FF05:0:0:0:0:0:0:2       All Routers Address              [ADDARCH]
+
+   FF05:0:0:0:0:0:1:3       All-dhcp-servers           [Bound,Perkins]
+   FF05:0:0:0:0:0:1:4       All-dhcp-relays            [Bound,Perkins]
+   FF05:0:0:0:0:0:1:1000    Service Location                 [RFC2165]
+    -FF05:0:0:0:0:0:1:13FF
+
+3.0 All Scope Multicast Addresses
+
+   These permanently assigned multicast addresses are valid over all
+   scope ranges.  This is shown by an "X" in the scope field of the
+   address that means any legal scope value.
+
+   Note that, as defined in [ADDARCH], IPv6 multicast addresses which
+   are only different in scope represent different groups.  Nodes must
+   join each group individually.
+
+   The IPv6 multicast addresses with variable scope are as follows:
+
+
+
+
+Hinden & Deering             Informational                      [Page 2]
+
+RFC 2375           IPv6 Multicast Address Assignments          July 1998
+
+
+   FF0X:0:0:0:0:0:0:0     Reserved Multicast Address         [ADDARCH]
+
+   FF0X:0:0:0:0:0:0:100   VMTP Managers Group           [RFC1045,DRC3]
+   FF0X:0:0:0:0:0:0:101   Network Time Protocol (NTP)   [RFC1119,DLM1]
+   FF0X:0:0:0:0:0:0:102   SGI-Dogfight                           [AXC]
+   FF0X:0:0:0:0:0:0:103   Rwhod                                  [SXD]
+   FF0X:0:0:0:0:0:0:104   VNP                                   [DRC3]
+   FF0X:0:0:0:0:0:0:105   Artificial Horizons - Aviator          [BXF]
+   FF0X:0:0:0:0:0:0:106   NSS - Name Service Server             [BXS2]
+   FF0X:0:0:0:0:0:0:107   AUDIONEWS - Audio News Multicast      [MXF2]
+   FF0X:0:0:0:0:0:0:108   SUN NIS+ Information Service          [CXM3]
+   FF0X:0:0:0:0:0:0:109   MTP Multicast Transport Protocol       [SXA]
+   FF0X:0:0:0:0:0:0:10A   IETF-1-LOW-AUDIO                       [SC3]
+   FF0X:0:0:0:0:0:0:10B   IETF-1-AUDIO                           [SC3]
+   FF0X:0:0:0:0:0:0:10C   IETF-1-VIDEO                           [SC3]
+   FF0X:0:0:0:0:0:0:10D   IETF-2-LOW-AUDIO                       [SC3]
+   FF0X:0:0:0:0:0:0:10E   IETF-2-AUDIO                           [SC3]
+   FF0X:0:0:0:0:0:0:10F   IETF-2-VIDEO                           [SC3]
+
+   FF0X:0:0:0:0:0:0:110   MUSIC-SERVICE             [Guido van Rossum]
+   FF0X:0:0:0:0:0:0:111   SEANET-TELEMETRY             [Andrew Maffei]
+   FF0X:0:0:0:0:0:0:112   SEANET-IMAGE                 [Andrew Maffei]
+   FF0X:0:0:0:0:0:0:113   MLOADD                              [Braden]
+   FF0X:0:0:0:0:0:0:114   any private experiment                 [JBP]
+   FF0X:0:0:0:0:0:0:115   DVMRP on MOSPF                         [Moy]
+   FF0X:0:0:0:0:0:0:116   SVRLOC                            [Veizades]
+   FF0X:0:0:0:0:0:0:117   XINGTV                      <hgxing@aol.com>
+   FF0X:0:0:0:0:0:0:118   microsoft-ds         <arnoldm@microsoft.com>
+   FF0X:0:0:0:0:0:0:119   nbc-pro           <bloomer@birch.crd.ge.com>
+   FF0X:0:0:0:0:0:0:11A   nbc-pfn           <bloomer@birch.crd.ge.com>
+   FF0X:0:0:0:0:0:0:11B   lmsc-calren-1                         [Uang]
+   FF0X:0:0:0:0:0:0:11C   lmsc-calren-2                         [Uang]
+   FF0X:0:0:0:0:0:0:11D   lmsc-calren-3                         [Uang]
+   FF0X:0:0:0:0:0:0:11E   lmsc-calren-4                         [Uang]
+   FF0X:0:0:0:0:0:0:11F   ampr-info                          [Janssen]
+
+   FF0X:0:0:0:0:0:0:120   mtrace                              [Casner]
+   FF0X:0:0:0:0:0:0:121   RSVP-encap-1                        [Braden]
+   FF0X:0:0:0:0:0:0:122   RSVP-encap-2                        [Braden]
+   FF0X:0:0:0:0:0:0:123   SVRLOC-DA                         [Veizades]
+   FF0X:0:0:0:0:0:0:124   rln-server                            [Kean]
+   FF0X:0:0:0:0:0:0:125   proshare-mc                          [Lewis]
+   FF0X:0:0:0:0:0:0:126   dantz                               [Yackle]
+   FF0X:0:0:0:0:0:0:127   cisco-rp-announce                [Farinacci]
+   FF0X:0:0:0:0:0:0:128   cisco-rp-discovery               [Farinacci]
+   FF0X:0:0:0:0:0:0:129   gatekeeper                            [Toga]
+   FF0X:0:0:0:0:0:0:12A   iberiagames                        [Marocho]
+
+
+
+
+Hinden & Deering             Informational                      [Page 3]
+
+RFC 2375           IPv6 Multicast Address Assignments          July 1998
+
+
+   FF0X:0:0:0:0:0:0:201  "rwho" Group (BSD) (unofficial)         [JBP]
+   FF0X:0:0:0:0:0:0:202   SUN RPC PMAPPROC_CALLIT               [BXE1]
+
+   FF0X:0:0:0:0:0:2:0000
+    -FF0X:0:0:0:0:0:2:7FFD  Multimedia Conference Calls          [SC3]
+   FF0X:0:0:0:0:0:2:7FFE    SAPv1 Announcements                  [SC3]
+   FF0X:0:0:0:0:0:2:7FFF    SAPv0 Announcements (deprecated)     [SC3]
+   FF0X:0:0:0:0:0:2:8000
+    -FF0X:0:0:0:0:0:2:FFFF  SAP Dynamic Assignments              [SC3]
+
+5.0 References
+
+   [ADDARCH] Hinden, R., and S. Deering, "IP Version 6 Addressing
+             Architecture", RFC 2373, July 1998.
+
+   [AUTORFC] Thompson, S., and T. Narten, "IPv6 Stateless Address
+             Autoconfiguration", RFC 1971, August 1996.
+
+   [ETHER]   Crawford, M., "Transmission of IPv6 Packets over Ethernet
+             Networks", Work in Progress.
+
+   [RFC1045] Cheriton, D., "VMTP: Versatile Message Transaction Protocol
+             Specification", RFC 1045, February 1988.
+
+   [RFC1075] Waitzman, D., Partridge, C., and S. Deering, "Distance
+             Vector Multicast Routing Protocol", RFC 1075, November
+             1988.
+
+   [RFC1112] Deering, S., "Host Extensions for IP Multicasting", STD 5,
+             RFC 1112, Stanford University, August 1989.
+
+   [RFC1119] Mills, D., "Network Time Protocol (Version 1),
+             Specification and Implementation", STD 12, RFC 1119, July
+             1988.
+
+   [RFC1190] Topolcic, C., Editor, "Experimental Internet Stream
+             Protocol, Version 2 (ST-II)", RFC 1190, October 1990.
+
+   [RFC2080] Malkin, G., and R. Minnear, "RIPng for IPv6", RFC 2080,
+             January 1997.
+
+   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+             Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2165] Veizades, J., Guttman, E., Perkins, C., and S. Kaplan
+             "Service Location Protocol", RFC 2165 June 1997.
+
+   [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
+
+
+
+Hinden & Deering             Informational                      [Page 4]
+
+RFC 2375           IPv6 Multicast Address Assignments          July 1998
+
+
+6. People
+
+   <arnoldm@microsoft.com>
+
+   [AXC] Andrew Cherenson <arc@SGI.COM>
+
+   [Braden] Bob Braden, <braden@isi.edu>, April 1996.
+
+   [Bob Brenner]
+
+   [Bressler] David J. Bressler, <bressler@tss.com>, April 1996.
+
+   <bloomer@birch.crd.ge.com>
+
+   [Bound] Jim Bound <bound@zk3.dec.com>
+
+   [BXE1] Brendan Eic <brendan@illyria.wpd.sgi.com>
+
+   [BXF] Bruce Factor <ahi!bigapple!bruce@uunet.UU.NET>
+
+   [BXS2] Bill Schilit <schilit@parc.xerox.com>
+
+   [Casner] Steve Casner, <casner@isi.edu>, January 1995.
+
+   [CXM3] Chuck McManis <cmcmanis@sun.com>
+
+   [Tim Clark]
+
+   [DLM1] David Mills <Mills@HUEY.UDEL.EDU>
+
+   [DRC3] Dave Cheriton <cheriton@PESCADERO.STANFORD.EDU>
+
+   [DXS3] Daniel Steinber <Daniel.Steinberg@Eng.Sun.COM>
+
+   [Farinacci] Dino Farinacci, <dino@cisco.com>
+
+   [GSM11] Gary S. Malkin <GMALKIN@XYLOGICS.COM>
+
+   [Harrington] Dan Harrington, <dan@lucent.com>, July 1996.
+
+   <hgxing@aol.com>
+
+   [IANA] IANA <iana@iana.org>
+
+   [Janssen] Rob Janssen, <rob@pe1chl.ampr.org>, January 1995.
+
+   [JBP] Jon Postel <postel@isi.edu>
+
+
+
+
+Hinden & Deering             Informational                      [Page 5]
+
+RFC 2375           IPv6 Multicast Address Assignments          July 1998
+
+
+   [JXM1] Jim Miner <miner@star.com>
+
+   [Kean] Brian Kean, <bkean@dca.com>, August 1995.
+
+   [KS14] <mystery contact>
+
+   [Lee] Choon Lee, <cwl@nsd.3com.com>, April 1996.
+
+   [Lewis] Mark Lewis, <Mark_Lewis@ccm.jf.intel.com>, October 1995.
+
+   [Malamud] Carl Malamud, <carl@radio.com>, January 1996.
+
+   [Andrew Maffei]
+
+   [Marohco] Jose Luis Marocho, <73374.313@compuserve.com>, July 1996.
+
+   [Moy] John Moy <jmoy@casc.com>
+
+   [MXF2] Martin Forssen <maf@dtek.chalmers.se>
+
+   [Perkins] Charlie Perkins, <cperkins@corp.sun.com>
+
+   [Guido van Rossum]
+
+   [SC3] Steve Casner <casner@isi.edu>
+
+   [Simpson] Bill Simpson <bill.simpson@um.cc.umich.edu> November 1994.
+
+   [Joel Snyder]
+
+   [SXA] Susie Armstrong <Armstrong.wbst128@XEROX.COM>
+
+   [SXD] Steve Deering <deering@PARC.XEROX.COM>
+
+   [tynan] Dermot Tynan, <dtynan@claddagh.ie>, August 1995.
+
+   [Toga] Jim Toga, <jtoga@ibeam.jf.intel.com>, May 1996.
+
+   [Uang] Yea Uang <uang@force.decnet.lockheed.com> November 1994.
+
+   [Veizades] John Veizades,  <veizades@tgv.com>, May 1995.
+
+   [Yackle] Dotty Yackle, <ditty_yackle@dantz.com>, February 1996.
+
+
+
+
+
+
+
+
+Hinden & Deering             Informational                      [Page 6]
+
+RFC 2375           IPv6 Multicast Address Assignments          July 1998
+
+
+7.0 Security Considerations
+
+   This document defines the initial assignment of IPv6 multicast
+   addresses.  As such it does not directly impact the security of the
+   Internet infrastructure or its applications.
+
+8.0 Authors' Addresses
+
+   Robert M. Hinden
+   Ipsilon Networks, Inc.
+   232 Java Drive
+   Sunnyvale, CA 94089
+   USA
+
+   Phone: +1 415 990 2004
+   EMail: hinden@ipsilon.com
+
+
+   Stephen E. Deering
+   Cisco Systems, Inc.
+   170 West Tasman Drive
+   San Jose, CA 95134-1706
+   USA
+
+   Phone: +1 408 527-8213
+   EMail: deering@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hinden & Deering             Informational                      [Page 7]
+
+RFC 2375           IPv6 Multicast Address Assignments          July 1998
+
+
+9.0  Full Copyright Statement
+
+   Copyright (C) The Internet Society (1998).  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 Standards process must be
+   followed, or as required to translate it into 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hinden & Deering             Informational                      [Page 8]
+
diff --git a/doc/rfc/rfc2418.txt b/doc/rfc/rfc2418.txt
new file mode 100644
index 0000000..9bdb2c5
--- /dev/null
+++ b/doc/rfc/rfc2418.txt
@@ -0,0 +1,1459 @@
+
+
+
+
+
+
+Network Working Group                                         S. Bradner
+Request for Comments: 2418                                        Editor
+Obsoletes: 1603                                       Harvard University
+BCP: 25                                                   September 1998
+Category: Best Current Practice
+
+
+                           IETF Working Group
+                       Guidelines and Procedures
+
+Status of this Memo
+
+   This document specifies an Internet Best Current Practices for the
+   Internet Community, and requests discussion and suggestions for
+   improvements.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (1998).  All Rights Reserved.
+
+Abstract
+
+   The Internet Engineering Task Force (IETF) has responsibility for
+   developing and reviewing specifications intended as Internet
+   Standards. IETF activities are organized into working groups (WGs).
+   This document describes the guidelines and procedures for formation
+   and operation of IETF working groups. It also describes the formal
+   relationship between IETF participants WG and the Internet
+   Engineering Steering Group (IESG) and the basic duties of IETF
+   participants, including WG Chairs, WG participants, and IETF Area
+   Directors.
+
+Table of Contents
+
+   Abstract .........................................................  1
+   1. Introduction ..................................................  2
+     1.1. IETF approach to standardization ..........................  4
+     1.2. Roles within a Working Group ..............................  4
+   2. Working group formation .......................................  4
+     2.1. Criteria for formation ....................................  4
+     2.2. Charter ...................................................  6
+     2.3. Charter review & approval .................................  8
+     2.4. Birds of a feather (BOF) ..................................  9
+   3. Working Group Operation ....................................... 10
+     3.1. Session planning .......................................... 11
+     3.2. Session venue ............................................. 11
+     3.3. Session management ........................................ 13
+     3.4. Contention and appeals .................................... 15
+
+
+
+Bradner                  Best Current Practice                  [Page 1]
+
+RFC 2418                Working Group Guidelines          September 1998
+
+
+   4. Working Group Termination ..................................... 15
+   5. Rechartering a Working Group .................................. 15
+   6. Staff Roles ................................................... 16
+     6.1. WG Chair .................................................. 16
+     6.2. WG Secretary .............................................. 18
+     6.3. Document Editor ........................................... 18
+     6.4. WG Facilitator ............................................ 18
+     6.5. Design teams .............................................. 19
+     6.6. Working Group Consultant .................................. 19
+     6.7. Area Director ............................................. 19
+   7. Working Group Documents ....................................... 19
+     7.1. Session documents ......................................... 19
+     7.2. Internet-Drafts (I-D) ..................................... 19
+     7.3. Request For Comments (RFC) ................................ 20
+     7.4. Working Group Last-Call ................................... 20
+     7.5. Submission of documents ................................... 21
+   8. Review of documents ........................................... 21
+   9. Security Considerations ....................................... 22
+   10. Acknowledgments .............................................. 23
+   11. References ................................................... 23
+   12. Editor's Address ............................................. 23
+   Appendix:  Sample Working Group Charter .......................... 24
+   Full Copyright Statement ......................................... 26
+
+1. Introduction
+
+   The Internet, a loosely-organized international collaboration of
+   autonomous, interconnected networks, supports host-to-host
+   communication through voluntary adherence to open protocols and
+   procedures defined by Internet Standards.  There are also many
+   isolated interconnected networks, which are not connected to the
+   global Internet but use the Internet Standards. Internet Standards
+   are developed in the Internet Engineering Task Force (IETF).  This
+   document defines guidelines and procedures for IETF working groups.
+   The Internet Standards Process of the IETF is defined in [1]. The
+   organizations involved in the IETF Standards Process are described in
+   [2] as are the roles of specific individuals.
+
+   The IETF is a large, open community of network designers, operators,
+   vendors, users, and researchers concerned with the Internet and the
+   technology used on it. The primary activities of the IETF are
+   performed by committees known as working groups. There are currently
+   more than 100 working groups. (See the IETF web page for an up-to-
+   date list of IETF Working Groups - http://www.ietf.org.) Working
+   groups tend to have a narrow focus and a lifetime bounded by the
+   completion of a specific set of tasks, although there are exceptions.
+
+
+
+
+
+Bradner                  Best Current Practice                  [Page 2]
+
+RFC 2418                Working Group Guidelines          September 1998
+
+
+   For management purposes, the IETF working groups are collected
+   together into areas, with each area having a separate focus.  For
+   example, the security area deals with the development of security-
+   related technology.  Each IETF area is managed by one or two Area
+   Directors (ADs).  There are currently 8 areas in the IETF but the
+   number changes from time to time.  (See the IETF web page for a list
+   of the current areas, the Area Directors for each area, and a list of
+   which working groups are assigned to each area.)
+
+   In many areas, the Area Directors have formed an advisory group or
+   directorate.  These comprise experienced members of the IETF and the
+   technical community represented by the area.  The specific name and
+   the details of the role for each group differ from area to area, but
+   the primary intent is that these groups assist the Area Director(s),
+   e.g., with the review of specifications produced in the area.
+
+   The IETF area directors are selected by a nominating committee, which
+   also selects an overall chair for the IETF.  The nominations process
+   is described in [3].
+
+   The area directors sitting as a body, along with the IETF Chair,
+   comprise the Internet Engineering Steering Group (IESG). The IETF
+   Executive Director is an ex-officio participant of the IESG, as are
+   the IAB Chair and a designated Internet Architecture Board (IAB)
+   liaison.  The IESG approves IETF Standards and approves the
+   publication of other IETF documents.  (See [1].)
+
+   A small IETF Secretariat provides staff and administrative support
+   for the operation of the IETF.
+
+   There is no formal membership in the IETF.  Participation is open to
+   all.  This participation may be by on-line contribution, attendance
+   at face-to-face sessions, or both.  Anyone from the Internet
+   community who has the time and interest is urged to participate in
+   IETF meetings and any of its on-line working group discussions.
+   Participation is by individual technical contributors, rather than by
+   formal representatives of organizations.
+
+   This document defines procedures and guidelines for the formation and
+   operation of working groups in the IETF. It defines the relations of
+   working groups to other bodies within the IETF. The duties of working
+   group Chairs and Area Directors with respect to the operation of the
+   working group are also defined.  When used in this document the key
+   words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
+   "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be
+   interpreted as described in RFC 2119 [6].  RFC 2119 defines the use
+   of these key words to help make the intent of standards track
+   documents as clear as possible.  The same key words are used in this
+
+
+
+Bradner                  Best Current Practice                  [Page 3]
+
+RFC 2418                Working Group Guidelines          September 1998
+
+
+   document to help smooth WG operation and reduce the chance for
+   confusion about the processes.
+
+1.1. IETF approach to standardization
+
+   Familiarity with The Internet Standards Process [1] is essential for
+   a complete understanding of the philosophy, procedures and guidelines
+   described in this document.
+
+1.2. Roles within a Working Group
+
+   The document, "Organizations Involved in the IETF Standards Process"
+   [2] describes the roles of a number of individuals within a working
+   group, including the working group chair and the document editor.
+   These descriptions are expanded later in this document.
+
+2. Working group formation
+
+   IETF working groups (WGs) are the primary mechanism for development
+   of IETF specifications and guidelines, many of which are intended to
+   be standards or recommendations. A working group may be established
+   at the initiative of an Area Director or it may be initiated by an
+   individual or group of individuals. Anyone interested in creating an
+   IETF working group MUST obtain the advice and consent of the IETF
+   Area Director(s) in whose area the working group would fall and MUST
+   proceed through the formal steps detailed in this section.
+
+   Working groups are typically created to address a specific problem or
+   to produce one or more specific deliverables (a guideline, standards
+   specification, etc.).  Working groups are generally expected to be
+   short-lived in nature.  Upon completion of its goals and achievement
+   of its objectives, the working group is terminated. A working group
+   may also be terminated for other reasons (see section 4).
+   Alternatively, with the concurrence of the IESG, Area Director, the
+   WG Chair, and the WG participants, the objectives or assignment of
+   the working group may be extended by modifying the working group's
+   charter through a rechartering process (see section 5).
+
+2.1. Criteria for formation
+
+   When determining whether it is appropriate to create a working group,
+   the Area Director(s) and the IESG will consider several issues:
+
+    - Are the issues that the working group plans to address clear and
+      relevant to the Internet community?
+
+    - Are the goals specific and reasonably achievable, and achievable
+      within a reasonable time frame?
+
+
+
+Bradner                  Best Current Practice                  [Page 4]
+
+RFC 2418                Working Group Guidelines          September 1998
+
+
+    - What are the risks and urgency of the work, to determine the level
+      of effort required?
+
+    - Do the working group's activities overlap with those of another
+      working group?  If so, it may still be appropriate to create the
+      working group, but this question must be considered carefully by
+      the Area Directors as subdividing efforts often dilutes the
+      available technical expertise.
+
+    - Is there sufficient interest within the IETF in the working
+      group's topic with enough people willing to expend the effort to
+      produce the desired result (e.g., a protocol specification)?
+      Working groups require considerable effort, including management
+      of the working group process, editing of working group documents,
+      and contributing to the document text.  IETF experience suggests
+      that these roles typically cannot all be handled by one person; a
+      minimum of four or five active participants in the management
+      positions are typically required in addition to a minimum of one
+      or two dozen people that will attend the working group meetings
+      and contribute on the mailing list.  NOTE: The interest must be
+      broad enough that a working group would not be seen as merely the
+      activity of a single vendor.
+
+    - Is there enough expertise within the IETF in the working group's
+      topic, and are those people interested in contributing in the
+      working group?
+
+    - Does a base of interested consumers (end-users) appear to exist
+      for the planned work?  Consumer interest can be measured by
+      participation of end-users within the IETF process, as well as by
+      less direct means.
+
+    - Does the IETF have a reasonable role to play in the determination
+      of the technology?  There are many Internet-related technologies
+      that may be interesting to IETF members but in some cases the IETF
+      may not be in a position to effect the course of the technology in
+      the "real world".  This can happen, for example, if the technology
+      is being developed by another standards body or an industry
+      consortium.
+
+    - Are all known intellectual property rights relevant to the
+      proposed working group's efforts issues understood?
+
+    - Is the proposed work plan an open IETF effort or is it an attempt
+      to "bless" non-IETF technology where the effect of input from IETF
+      participants may be limited?
+
+
+
+
+
+Bradner                  Best Current Practice                  [Page 5]
+
+RFC 2418                Working Group Guidelines          September 1998
+
+
+    - Is there a good understanding of any existing work that is
+      relevant to the topics that the proposed working group is to
+      pursue?  This includes work within the IETF and elsewhere.
+
+    - Do the working group's goals overlap with known work in another
+      standards body, and if so is adequate liaison in place?
+
+   Considering the above criteria, the Area Director(s), using his or
+   her best judgement, will decide whether to pursue the formation of
+   the group through the chartering process.
+
+2.2. Charter
+
+   The formation of a working group requires a charter which is
+   primarily negotiated between a prospective working group Chair and
+   the relevant Area Director(s), although final approval is made by the
+   IESG with advice from the Internet Architecture Board (IAB).  A
+   charter is a contract between a working group and the IETF to perform
+   a set of tasks.  A charter:
+
+   1. Lists relevant administrative information for the working group;
+   2. Specifies the direction or objectives of the working group and
+      describes the approach that will be taken to achieve the goals;
+      and
+   3. Enumerates a set of milestones together with time frames for their
+      completion.
+
+   When the prospective Chair(s), the Area Director and the IETF
+   Secretariat are satisfied with the charter form and content, it
+   becomes the basis for forming a working group. Note that an Area
+   Director MAY require holding an exploratory Birds of a Feather (BOF)
+   meeting, as described below, to gage the level of support for a
+   working group before submitting the charter to the IESG and IAB for
+   approval.
+
+   Charters may be renegotiated periodically to reflect the current
+   status, organization or goals of the working group (see section 5).
+   Hence, a charter is a contract between the IETF and the working group
+   which is committing to meet explicit milestones and delivering
+   specific "products".
+
+   Specifically, each charter consists of the following sections:
+
+   Working group name
+      A working group name should be reasonably descriptive or
+      identifiable. Additionally, the group shall define an acronym
+      (maximum 8 printable ASCII characters) to reference the group in
+      the IETF directories, mailing lists, and general documents.
+
+
+
+Bradner                  Best Current Practice                  [Page 6]
+
+RFC 2418                Working Group Guidelines          September 1998
+
+
+   Chair(s)
+      The working group may have one or more Chairs to perform the
+      administrative functions of the group. The email address(es) of
+      the Chair(s) shall be included.  Generally, a working group is
+      limited to two chairs.
+
+   Area and Area Director(s)
+      The name of the IETF area with which the working group is
+      affiliated and the name and electronic mail address of the
+      associated Area Director(s).
+
+   Responsible Area Director
+      The Area Director who acts as the primary IESG contact for the
+      working group.
+
+   Mailing list
+      An IETF working group MUST have a general Internet mailing list.
+      Most of the work of an IETF working group will be conducted on the
+      mailing list. The working group charter MUST include:
+
+      1. The address to which a participant sends a subscription request
+         and the procedures to follow when subscribing,
+
+      2. The address to which a participant sends submissions and
+         special procedures, if any, and
+
+      3. The location of the mailing list archive. A message archive
+         MUST be maintained in a public place which can be accessed via
+         FTP or via the web.
+
+         As a service to the community, the IETF Secretariat operates a
+         mailing list archive for working group mailing lists. In order
+         to take advantage of this service, working group mailing lists
+         MUST include the address "wg_acronym-archive@lists.ietf.org"
+         (where "wg_acronym" is the working group acronym) in the
+         mailing list in order that a copy of all mailing list messages
+         be recorded in the Secretariat's archive.  Those archives are
+         located at ftp://ftp.ietf.org/ietf-mail-archive.  For
+         robustness, WGs SHOULD maintain an additional archive separate
+         from that maintained by the Secretariat.
+
+   Description of working group
+      The focus and intent of the group shall be set forth briefly. By
+      reading this section alone, an individual should be able to decide
+      whether this group is relevant to their own work. The first
+      paragraph must give a brief summary of the problem area, basis,
+      goal(s) and approach(es) planned for the working group.  This
+      paragraph can be used as an overview of the working group's
+
+
+
+Bradner                  Best Current Practice                  [Page 7]
+
+RFC 2418                Working Group Guidelines          September 1998
+
+
+      effort.
+
+      To facilitate evaluation of the intended work and to provide on-
+      going guidance to the working group, the charter must describe the
+      problem being solved and should discuss objectives and expected
+      impact with respect to:
+
+         - Architecture
+         - Operations
+         - Security
+         - Network management
+         - Scaling
+         - Transition (where applicable)
+
+   Goals and milestones
+      The working group charter MUST establish a timetable for specific
+      work items.  While this may be renegotiated over time, the list of
+      milestones and dates facilitates the Area Director's tracking of
+      working group progress and status, and it is indispensable to
+      potential participants identifying the critical moments for input.
+      Milestones shall consist of deliverables that can be qualified as
+      showing specific achievement; e.g., "Internet-Draft finished" is
+      fine, but "discuss via email" is not. It is helpful to specify
+      milestones for every 3-6 months, so that progress can be gauged
+      easily.  This milestone list is expected to be updated
+      periodically (see section 5).
+
+      An example of a WG charter is included as Appendix A.
+
+2.3. Charter review & approval
+
+   Proposed working groups often comprise technically competent
+   participants who are not familiar with the history of Internet
+   architecture or IETF processes.  This can, unfortunately, lead to
+   good working group consensus about a bad design.  To facilitate
+   working group efforts, an Area Director may assign a Consultant from
+   among the ranks of senior IETF participants.  (Consultants are
+   described in section 6.)  At the discretion of the Area Director,
+   approval of a new WG may be withheld in the absence of sufficient
+   consultant resources.
+
+   Once the Area Director (and the Area Directorate, as the Area
+   Director deems appropriate) has approved the working group charter,
+   the charter is submitted for review by the IAB and approval by the
+   IESG.  After a review period of at least a week the proposed charter
+   is posted to the IETF-announce mailing list as a public notice that
+   the formation of the working group is being considered.  At the same
+   time the proposed charter is also posted to the "new-work" mailing
+
+
+
+Bradner                  Best Current Practice                  [Page 8]
+
+RFC 2418                Working Group Guidelines          September 1998
+
+
+   list.  This mailing list has been created to let qualified
+   representatives from other standards organizations know about pending
+   IETF working groups.  After another review period lasting at least a
+   week the IESG MAY approve the charter as-is, it MAY request that
+   changes be made in the charter, or MAY decline to approve chartering
+   of the working group
+
+   If the IESG approves the formation of the working group it remands
+   the approved charter to the IETF Secretariat who records and enters
+   the information into the IETF tracking database.  The working group
+   is announced to the IETF-announce a by the IETF Secretariat.
+
+2.4. Birds of a Feather (BOF)
+
+   Often it is not clear whether an issue merits the formation of a
+   working group.  To facilitate exploration of the issues the IETF
+   offers the possibility of a Birds of a Feather (BOF) session, as well
+   as the early formation of an email list for preliminary discussion.
+   In addition, a BOF may serve as a forum for a single presentation or
+   discussion, without any intent to form a working group.
+
+   A BOF is a session at an IETF meeting which permits "market research"
+   and technical "brainstorming".  Any individual may request permission
+   to hold a BOF on a subject. The request MUST be filed with a relevant
+   Area Director who must approve a BOF before it can be scheduled. The
+   person who requests the BOF may be asked to serve as Chair of the
+   BOF.
+
+   The Chair of the BOF is also responsible for providing a report on
+   the outcome of the BOF.  If the Area Director approves, the BOF is
+   then scheduled by submitting a request to agenda@ietf.org with copies
+   to the Area Director(s). A BOF description and agenda are required
+   before a BOF can be scheduled.
+
+   Available time for BOFs is limited, and BOFs are held at the
+   discretion of the ADs for an area.  The AD(s) may require additional
+   assurances before authorizing a BOF.  For example,
+
+    - The Area Director MAY require the establishment of an open email
+      list prior to authorizing a BOF.  This permits initial exchanges
+      and sharing of framework, vocabulary and approaches, in order to
+      make the time spent in the BOF more productive.
+
+    - The Area Director MAY require that a BOF be held, prior to
+      establishing a working group (see section 2.2).
+
+    - The Area Director MAY require that there be a draft of the WG
+      charter prior to holding a BOF.
+
+
+
+Bradner                  Best Current Practice                  [Page 9]
+
+RFC 2418                Working Group Guidelines          September 1998
+
+
+    - The Area Director MAY require that a BOF not be held until an
+      Internet-Draft describing the proposed technology has been
+      published so it can be used as a basis for discussion in the BOF.
+
+   In general, a BOF on a particular topic is held only once (ONE slot
+   at one IETF Plenary meeting). Under unusual circumstances Area
+   Directors may, at their discretion, allow a BOF to meet for a second
+   time. BOFs are not permitted to meet three times.  Note that all
+   other things being equal, WGs will be given priority for meeting
+   space over BOFs.  Also, occasionally BOFs may be held for other
+   purposes than to discuss formation of a working group.
+
+   Usually the outcome of a BOF will be one of the following:
+
+    - There was enough interest and focus in the subject to warrant the
+      formation of a WG;
+
+    - While there was a reasonable level of interest expressed in the
+      BOF some other criteria for working group formation was not met
+      (see section 2.1).
+
+    - The discussion came to a fruitful conclusion, with results to be
+      written down and published, however there is no need to establish
+      a WG; or
+
+    - There was not enough interest in the subject to warrant the
+      formation of a WG.
+
+3.  Working Group Operation
+
+   The IETF has basic requirements for open and fair participation and
+   for thorough consideration of technical alternatives.  Within those
+   constraints, working groups are autonomous and each determines most
+   of the details of its own operation with respect to session
+   participation, reaching closure, etc. The core rule for operation is
+   that acceptance or agreement is achieved via working group "rough
+   consensus".  WG participants should specifically note the
+   requirements for disclosure of conflicts of interest in [2].
+
+   A number of procedural questions and issues will arise over time, and
+   it is the function of the Working Group Chair(s) to manage the group
+   process, keeping in mind that the overall purpose of the group is to
+   make progress towards reaching rough consensus in realizing the
+   working group's goals and objectives.
+
+   There are few hard and fast rules on organizing or conducting working
+   group activities, but a set of guidelines and practices has evolved
+   over time that have proven successful. These are listed here, with
+
+
+
+Bradner                  Best Current Practice                 [Page 10]
+
+RFC 2418                Working Group Guidelines          September 1998
+
+
+   actual choices typically determined by the working group participants
+   and the Chair(s).
+
+3.1. Session planning
+
+   For coordinated, structured WG interactions, the Chair(s) MUST
+   publish a draft agenda well in advance of the actual session. The
+   agenda should contain at least:
+
+   - The items for discussion;
+   - The estimated time necessary per item; and
+   - A clear indication of what documents the participants will need to
+     read before the session in order to be well prepared.
+
+   Publication of the working group agenda shall include sending a copy
+   of the agenda to the working group mailing list and to
+   agenda@ietf.org.
+
+   All working group actions shall be taken in a public forum, and wide
+   participation is encouraged. A working group will conduct much of its
+   business via electronic mail distribution lists but may meet
+   periodically to discuss and review task status and progress, to
+   resolve specific issues and to direct future activities.  IETF
+   Plenary meetings are the primary venue for these face-to-face working
+   group sessions, and it is common (though not required) that active
+   "interim" face-to-face meetings, telephone conferences, or video
+   conferences may also be held.  Interim meetings are subject to the
+   same rules for advance notification, reporting, open participation,
+   and process, which apply to other working group meetings.
+
+   All working group sessions (including those held outside of the IETF
+   meetings) shall be reported by making minutes available.  These
+   minutes should include the agenda for the session, an account of the
+   discussion including any decisions made, and a list of attendees. The
+   Working Group Chair is responsible for insuring that session minutes
+   are written and distributed, though the actual task may be performed
+   by someone designated by the Working Group Chair. The minutes shall
+   be submitted in printable ASCII text for publication in the IETF
+   Proceedings, and for posting in the IETF Directories and are to be
+   sent to: minutes@ietf.org
+
+3.2. Session venue
+
+   Each working group will determine the balance of email and face-to-
+   face sessions that is appropriate for achieving its milestones.
+   Electronic mail permits the widest participation; face-to-face
+   meetings often permit better focus and therefore can be more
+   efficient for reaching a consensus among a core of the working group
+
+
+
+Bradner                  Best Current Practice                 [Page 11]
+
+RFC 2418                Working Group Guidelines          September 1998
+
+
+   participants.  In determining the balance, the WG must ensure that
+   its process does not serve to exclude contribution by email-only
+   participants.  Decisions reached during a face-to-face meeting about
+   topics or issues which have not been discussed on the mailing list,
+   or are significantly different from previously arrived mailing list
+   consensus MUST be reviewed on the mailing list.
+
+   IETF Meetings
+   If a WG needs a session at an IETF meeting, the Chair must apply for
+   time-slots as soon as the first announcement of that IETF meeting is
+   made by the IETF Secretariat to the WG-chairs list.  Session time is
+   a scarce resource at IETF meetings, so placing requests early will
+   facilitate schedule coordination for WGs requiring the same set of
+   experts.
+
+   The application for a WG session at an IETF meeting MUST be made to
+   the IETF Secretariat at the address agenda@ietf.org.  Some Area
+   Directors may want to coordinate WG sessions in their area and
+   request that time slots be coordinated through them.  If this is the
+   case it will be noted in the IETF meeting announcement. A WG
+   scheduling request MUST contain:
+
+   - The working group name and full title;
+   - The amount of time requested;
+   - The rough outline of the WG agenda that is expected to be covered;
+   - The estimated number of people that will attend the WG session;
+   - Related WGs that should not be scheduled for the same time slot(s);
+     and
+   - Optionally a request can be added for the WG session to be
+     transmitted over the Internet in audio and video.
+
+   NOTE: While open discussion and contribution is essential to working
+   group success, the Chair is responsible for ensuring forward
+   progress.  When acceptable to the WG, the Chair may call for
+   restricted participation (but not restricted attendance!) at IETF
+   working group sessions for the purpose of achieving progress. The
+   Working Group Chair then has the authority to refuse to grant the
+   floor to any individual who is unprepared or otherwise covering
+   inappropriate material, or who, in the opinion of the Chair is
+   disrupting the WG process.  The Chair should consult with the Area
+   Director(s) if the individual persists in disruptive behavior.
+
+   On-line
+   It can be quite useful to conduct email exchanges in the same manner
+   as a face-to-face session, with published schedule and agenda, as
+   well as on-going summarization and consensus polling.
+
+
+
+
+
+Bradner                  Best Current Practice                 [Page 12]
+
+RFC 2418                Working Group Guidelines          September 1998
+
+
+   Many working group participants hold that mailing list discussion is
+   the best place to consider and resolve issues and make decisions. The
+   choice of operational style is made by the working group itself.  It
+   is important to note, however, that Internet email discussion is
+   possible for a much wider base of interested persons than is
+   attendance at IETF meetings, due to the time and expense required to
+   attend.
+
+   As with face-to-face sessions occasionally one or more individuals
+   may engage in behavior on a mailing list which disrupts the WG's
+   progress.  In these cases the Chair should attempt to discourage the
+   behavior by communication directly with the offending individual
+   rather than on the open mailing list.  If the behavior persists then
+   the Chair must involve the Area Director in the issue.  As a last
+   resort and after explicit warnings, the Area Director, with the
+   approval of the IESG, may request that the mailing list maintainer
+   block the ability of the offending individual to post to the mailing
+   list. (If the mailing list software permits this type of operation.)
+   Even if this is done, the individual must not be prevented from
+   receiving messages posted to the list.  Other methods of mailing list
+   control may be considered but must be approved by the AD(s) and the
+   IESG.
+
+3.3. Session management
+
+   Working groups make decisions through a "rough consensus" process.
+   IETF consensus does not require that all participants agree although
+   this is, of course, preferred.  In general, the dominant view of the
+   working group shall prevail.  (However, it must be noted that
+   "dominance" is not to be determined on the basis of volume or
+   persistence, but rather a more general sense of agreement.) Consensus
+   can be determined by a show of hands, humming, or any other means on
+   which the WG agrees (by rough consensus, of course).  Note that 51%
+   of the working group does not qualify as "rough consensus" and 99% is
+   better than rough.  It is up to the Chair to determine if rough
+   consensus has been reached.
+
+   It can be particularly challenging to gauge the level of consensus on
+   a mailing list.  There are two different cases where a working group
+   may be trying to understand the level of consensus via a mailing list
+   discussion. But in both cases the volume of messages on a topic is
+   not, by itself, a good indicator of consensus since one or two
+   individuals may be generating much of the traffic.
+
+   In the case where a consensus which has been reached during a face-
+   to-face meeting is being verified on a mailing list the people who
+   were in the meeting and expressed agreement must be taken into
+   account.  If there were 100 people in a meeting and only a few people
+
+
+
+Bradner                  Best Current Practice                 [Page 13]
+
+RFC 2418                Working Group Guidelines          September 1998
+
+
+   on the mailing list disagree with the consensus of the meeting then
+   the consensus should be seen as being verified.  Note that enough
+   time should be given to the verification process for the mailing list
+   readers to understand and consider any objections that may be raised
+   on the list.  The normal two week last-call period should be
+   sufficient for this.
+
+   The other case is where the discussion has been held entirely over
+   the mailing list.  The determination of the level of consensus may be
+   harder to do in this case since most people subscribed to mailing
+   lists do not actively participate in discussions on the list. It is
+   left to the discretion of the working group chair how to evaluate the
+   level of consensus.  The most common method used is for the working
+   group chair to state what he or she believes to be the consensus view
+   and. at the same time, requests comments from the list about the
+   stated conclusion.
+
+   The challenge to managing working group sessions is to balance the
+   need for open and fair consideration of the issues against the need
+   to make forward progress.  The working group, as a whole, has the
+   final responsibility for striking this balance.  The Chair has the
+   responsibility for overseeing the process but may delegate direct
+   process management to a formally-designated Facilitator.
+
+   It is occasionally appropriate to revisit a topic, to re-evaluate
+   alternatives or to improve the group's understanding of a relevant
+   decision.  However, unnecessary repeated discussions on issues can be
+   avoided if the Chair makes sure that the main arguments in the
+   discussion (and the outcome) are summarized and archived after a
+   discussion has come to conclusion. It is also good practice to note
+   important decisions/consensus reached by email in the minutes of the
+   next 'live' session, and to summarize briefly the decision-making
+   history in the final documents the WG produces.
+
+   To facilitate making forward progress, a Working Group Chair may wish
+   to decide to reject or defer the input from a member, based upon the
+   following criteria:
+
+   Old
+   The input pertains to a topic that already has been resolved and is
+   redundant with information previously available;
+
+   Minor
+   The input is new and pertains to a topic that has already been
+   resolved, but it is felt to be of minor import to the existing
+   decision;
+
+
+
+
+
+Bradner                  Best Current Practice                 [Page 14]
+
+RFC 2418                Working Group Guidelines          September 1998
+
+
+   Timing
+   The input pertains to a topic that the working group has not yet
+   opened for discussion; or
+
+   Scope
+   The input is outside of the scope of the working group charter.
+
+3.4. Contention and appeals
+
+   Disputes are possible at various stages during the IETF process. As
+   much as possible the process is designed so that compromises can be
+   made, and genuine consensus achieved; however, there are times when
+   even the most reasonable and knowledgeable people are unable to
+   agree.  To achieve the goals of openness and fairness, such conflicts
+   must be resolved by a process of open review and discussion.
+
+   Formal procedures for requesting a review of WG, Chair, Area Director
+   or IESG actions and conducting appeals are documented in The Internet
+   Standards Process [1].
+
+4. Working Group Termination
+
+   Working groups are typically chartered to accomplish a specific task
+   or tasks.  After the tasks are complete, the group will be disbanded.
+   However, if a WG produces a Proposed or Draft Standard, the WG will
+   frequently become dormant rather than disband (i.e., the WG will no
+   longer conduct formal activities, but the mailing list will remain
+   available to review the work as it moves to Draft Standard and
+   Standard status.)
+
+   If, at some point, it becomes evident that a working group is unable
+   to complete the work outlined in the charter, or if the assumptions
+   which that work was based have been modified in discussion or by
+   experience, the Area Director, in consultation with the working group
+   can either:
+
+   1. Recharter to refocus its tasks,
+   2. Choose new Chair(s), or
+   3. Disband.
+
+   If the working group disagrees with the Area Director's choice, it
+   may appeal to the IESG (see section 3.4).
+
+5. Rechartering a Working Group
+
+   Updated milestones are renegotiated with the Area Director and the
+   IESG, as needed, and then are submitted to the IESG Secretariat:
+   iesg-secretary@ietf.org.
+
+
+
+Bradner                  Best Current Practice                 [Page 15]
+
+RFC 2418                Working Group Guidelines          September 1998
+
+
+   Rechartering (other than revising milestones) a working group follows
+   the same procedures that the initial chartering does (see section 2).
+   The revised charter must be submitted to the IESG and IAB for
+   approval.  As with the initial chartering, the IESG may approve new
+   charter as-is, it may request that changes be made in the new charter
+   (including having the Working Group continue to use the old charter),
+   or it may decline to approve the rechartered working group.  In the
+   latter case, the working group is disbanded.
+
+6. Staff Roles
+
+   Working groups require considerable care and feeding.  In addition to
+   general participation, successful working groups benefit from the
+   efforts of participants filling specific functional roles.  The Area
+   Director must agree to the specific people performing the WG Chair,
+   and Working Group Consultant roles, and they serve at the discretion
+   of the Area Director.
+
+6.1. WG Chair
+
+   The Working Group Chair is concerned with making forward progress
+   through a fair and open process, and has wide discretion in the
+   conduct of WG business.  The Chair must ensure that a number of tasks
+   are performed, either directly or by others assigned to the tasks.
+
+   The Chair has the responsibility and the authority to make decisions,
+   on behalf of the working group, regarding all matters of working
+   group process and staffing, in conformance with the rules of the
+   IETF.  The AD has the authority and the responsibility to assist in
+   making those decisions at the request of the Chair or when
+   circumstances warrant such an intervention.
+
+   The Chair's responsibility encompasses at least the following:
+
+   Ensure WG process and content management
+
+      The Chair has ultimate responsibility for ensuring that a working
+      group achieves forward progress and meets its milestones.  The
+      Chair is also responsible to ensure that the working group
+      operates in an open and fair manner.  For some working groups,
+      this can be accomplished by having the Chair perform all
+      management-related activities.  In other working groups --
+      particularly those with large or divisive participation -- it is
+      helpful to allocate process and/or secretarial functions to other
+      participants.  Process management pertains strictly to the style
+      of working group interaction and not to its content. It ensures
+      fairness and detects redundancy.  The secretarial function
+      encompasses document editing.  It is quite common for a working
+
+
+
+Bradner                  Best Current Practice                 [Page 16]
+
+RFC 2418                Working Group Guidelines          September 1998
+
+
+      group to assign the task of specification Editor to one or two
+      participants.  Sometimes, they also are part of the design team,
+      described below.
+
+   Moderate the WG email list
+
+      The Chair should attempt to ensure that the discussions on this
+      list are relevant and that they converge to consensus agreements.
+      The Chair should make sure that discussions on the list are
+      summarized and that the outcome is well documented (to avoid
+      repetition).  The Chair also may choose to schedule organized on-
+      line "sessions" with agenda and deliverables.  These can be
+      structured as true meetings, conducted over the course of several
+      days (to allow participation across the Internet).
+
+      Organize, prepare and chair face-to-face and on-line formal
+      sessions.
+
+   Plan WG Sessions
+
+      The Chair must plan and announce all WG sessions well in advance
+      (see section 3.1).
+
+   Communicate results of sessions
+
+      The Chair and/or Secretary must ensure that minutes of a session
+      are taken and that an attendance list is circulated (see section
+      3.1).
+
+      Immediately after a session, the WG Chair MUST provide the Area
+      Director with a very short report (approximately one paragraph,
+      via email) on the session.
+
+   Distribute the workload
+
+      Of course, each WG will have participants who may not be able (or
+      want) to do any work at all. Most of the time the bulk of the work
+      is done by a few dedicated participants. It is the task of the
+      Chair to motivate enough experts to allow for a fair distribution
+      of the workload.
+
+   Document development
+
+      Working groups produce documents and documents need authors. The
+      Chair must make sure that authors of WG documents incorporate
+      changes as agreed to by the WG (see section 6.3).
+
+
+
+
+
+Bradner                  Best Current Practice                 [Page 17]
+
+RFC 2418                Working Group Guidelines          September 1998
+
+
+   Document publication
+
+      The Chair and/or Document Editor will work with the RFC Editor to
+      ensure document conformance with RFC publication requirements [5]
+      and to coordinate any editorial changes suggested by the RFC
+      Editor.  A particular concern is that all participants are working
+      from the same version of a document at the same time.
+
+   Document implementations
+
+      Under the procedures described in [1], the Chair is responsible
+      for documenting the specific implementations which qualify the
+      specification for Draft or Internet Standard status along with
+      documentation about testing of the interoperation of these
+      implementations.
+
+6.2. WG Secretary
+
+   Taking minutes and editing working group documents often is performed
+   by a specifically-designated participant or set of participants.  In
+   this role, the Secretary's job is to record WG decisions, rather than
+   to perform basic specification.
+
+6.3. Document Editor
+
+   Most IETF working groups focus their efforts on a document, or set of
+   documents, that capture the results of the group's work.  A working
+   group generally designates a person or persons to serve as the Editor
+   for a particular document.  The Document Editor is responsible for
+   ensuring that the contents of the document accurately reflect the
+   decisions that have been made by the working group.
+
+   As a general practice, the Working Group Chair and Document Editor
+   positions are filled by different individuals to help ensure that the
+   resulting documents accurately reflect the consensus of the working
+   group and that all processes are followed.
+
+6.4. WG Facilitator
+
+   When meetings tend to become distracted or divisive, it often is
+   helpful to assign the task of "process management" to one
+   participant.  Their job is to oversee the nature, rather than the
+   content, of participant interactions.  That is, they attend to the
+   style of the discussion and to the schedule of the agenda, rather
+   than making direct technical contributions themselves.
+
+
+
+
+
+
+Bradner                  Best Current Practice                 [Page 18]
+
+RFC 2418                Working Group Guidelines          September 1998
+
+
+6.5. Design teams
+
+   It is often useful, and perhaps inevitable, for a sub-group of a
+   working group to develop a proposal to solve a particular problem.
+   Such a sub-group is called a design team.  In order for a design team
+   to remain small and agile, it is acceptable to have closed membership
+   and private meetings.  Design teams may range from an informal chat
+   between people in a hallway to a formal set of expert volunteers that
+   the WG chair or AD appoints to attack a controversial problem.  The
+   output of a design team is always subject to approval, rejection or
+   modification by the WG as a whole.
+
+6.6. Working Group Consultant
+
+   At the discretion of the Area Director, a Consultant may be assigned
+   to a working group.  Consultants have specific technical background
+   appropriate to the WG and experience in Internet architecture and
+   IETF process.
+
+6.7. Area Director
+
+   Area Directors are responsible for ensuring that working groups in
+   their area produce coherent, coordinated, architecturally consistent
+   and timely output as a contribution to the overall results of the
+   IETF.
+
+7.  Working Group Documents
+
+7.1. Session documents
+
+   All relevant documents to be discussed at a session should be
+   published and available as Internet-Drafts at least two weeks before
+   a session starts.  Any document which does not meet this publication
+   deadline can only be discussed in a working group session with the
+   specific approval of the working group chair(s).  Since it is
+   important that working group members have adequate time to review all
+   documents, granting such an exception should only be done under
+   unusual conditions.  The final session agenda should be posted to the
+   working group mailing list at least two weeks before the session and
+   sent at that time to agenda@ietf.org for publication on the IETF web
+   site.
+
+7.2. Internet-Drafts (I-D)
+
+   The Internet-Drafts directory is provided to working groups as a
+   resource for posting and disseminating in-process copies of working
+   group documents. This repository is replicated at various locations
+   around the Internet. It is encouraged that draft documents be posted
+
+
+
+Bradner                  Best Current Practice                 [Page 19]
+
+RFC 2418                Working Group Guidelines          September 1998
+
+
+   as soon as they become reasonably stable.
+
+   It is stressed here that Internet-Drafts are working documents and
+   have no official standards status whatsoever. They may, eventually,
+   turn into a standards-track document or they may sink from sight.
+   Internet-Drafts are submitted to: internet-drafts@ietf.org
+
+   The format of an Internet-Draft must be the same as for an RFC [2].
+   Further, an I-D must contain:
+
+   - Beginning, standard, boilerplate text which is provided by the
+     Secretariat on their web site and in the ftp directory;
+   - The I-D filename; and
+   - The expiration date for the I-D.
+
+   Complete specification of requirements for an Internet-Draft are
+   found in the file "1id-guidelines.txt" in the Internet-Drafts
+   directory at an Internet Repository site.  The organization of the
+   Internet-Drafts directory is found in the file "1id-organization" in
+   the Internet-Drafts directory at an Internet Repository site.  This
+   file also contains the rules for naming Internet-Drafts.  (See [1]
+   for more information about Internet-Drafts.)
+
+7.3. Request For Comments (RFC)
+
+   The work of an IETF working group often results in publication of one
+   or more documents, as part of the Request For Comments (RFCs) [1]
+   series. This series is the archival publication record for the
+   Internet community. A document can be written by an individual in a
+   working group, by a group as a whole with a designated Editor, or by
+   others not involved with the IETF.
+
+   NOTE: The RFC series is a publication mechanism only and publication
+   does not determine the IETF status of a document.  Status is
+   determined through separate, explicit status labels assigned by the
+   IESG on behalf of the IETF.  In other words, the reader is reminded
+   that all Internet Standards are published as RFCs, but NOT all RFCs
+   specify standards [4].
+
+7.4. Working Group Last-Call
+
+   When a WG decides that a document is ready for publication it may be
+   submitted to the IESG for consideration. In most cases the
+   determination that a WG feels that a document is ready for
+   publication is done by the WG Chair issuing a working group Last-
+   Call.  The decision to issue a working group Last-Call is at the
+   discretion of the WG Chair working with the Area Director.  A working
+   group Last-Call serves the same purpose within a working group that
+
+
+
+Bradner                  Best Current Practice                 [Page 20]
+
+RFC 2418                Working Group Guidelines          September 1998
+
+
+   an IESG Last-Call does in the broader IETF community (see [1]).
+
+7.5. Submission of documents
+
+   Once that a WG has determined at least rough consensus exists within
+   the WG for the advancement of a document the following must be done:
+
+   - The version of the relevant document exactly as agreed to by the WG
+     MUST be in the Internet-Drafts directory.
+
+   - The relevant document MUST be formatted according to section 7.3.
+
+   - The WG Chair MUST send email to the relevant Area Director.  A copy
+     of the request MUST be also sent to the IESG Secretariat.  The mail
+     MUST contain the reference to the document's ID filename, and the
+     action requested.  The copy of the message to the IESG Secretariat
+     is to ensure that the request gets recorded by the Secretariat so
+     that they can monitor the progress of the document through the
+     process.
+
+   Unless returned by the IESG to the WG for further development,
+   progressing of the document is then the responsibility of the IESG.
+   After IESG approval, responsibility for final disposition is the
+   joint responsibility of the RFC Editor, the WG Chair and the Document
+   Editor.
+
+8. Review of documents
+
+   The IESG reviews all documents submitted for publication as RFCs.
+   Usually minimal IESG review is necessary in the case of a submission
+   from a WG intended as an Informational or Experimental RFC. More
+   extensive review is undertaken in the case of standards-track
+   documents.
+
+   Prior to the IESG beginning their deliberations on standards-track
+   documents, IETF Secretariat will issue a "Last-Call" to the IETF
+   mailing list (see [1]). This Last Call will announce the intention of
+   the IESG to consider the document, and it will solicit final comments
+   from the IETF within a period of two weeks.  It is important to note
+   that a Last-Call is intended as a brief, final check with the
+   Internet community, to make sure that no important concerns have been
+   missed or misunderstood. The Last-Call should not serve as a more
+   general, in-depth review.
+
+   The IESG review takes into account responses to the Last-Call and
+   will lead to one of these possible conclusions:
+
+
+
+
+
+Bradner                  Best Current Practice                 [Page 21]
+
+RFC 2418                Working Group Guidelines          September 1998
+
+
+   1. The document is accepted as is for the status requested.
+      This fact will be announced by the IETF Secretariat to the IETF
+      mailing list and to the RFC Editor.
+
+   2. The document is accepted as-is but not for the status requested.
+      This fact will be announced by the IETF Secretariat to the IETF
+      mailing list and to the RFC Editor (see [1] for more details).
+
+   3. Changes regarding content are suggested to the author(s)/WG.
+      Suggestions from the IESG must be clear and direct, so as to
+      facilitate working group and author correction of the
+      specification.  If the author(s)/WG can explain to the
+      satisfaction of the IESG why the changes are not necessary, the
+      document will be accepted for publication as under point 1, above.
+      If the changes are made the revised document may be resubmitted
+      for IESG review.
+
+   4. Changes are suggested by the IESG and a change in status is
+      recommended.
+      The process described above for 3 and 2 are followed in that
+      order.
+
+   5. The document is rejected.
+      Any document rejection will be accompanied by specific and
+      thorough arguments from the IESG. Although the IETF and working
+      group process is structured such that this alternative is not
+      likely to arise for documents coming from a working group, the
+      IESG has the right and responsibility to reject documents that the
+      IESG feels are fatally flawed in some way.
+
+      If any individual or group of individuals feels that the review
+      treatment has been unfair, there is the opportunity to make a
+      procedural complaint. The mechanism for this type of complaints is
+      described in [1].
+
+9. Security Considerations
+
+   Documents describing IETF processes, such as this one, do not have an
+   impact on the security of the network infrastructure or of Internet
+   applications.
+
+   It should be noted that all IETF working groups are required to
+   examine and understand the security implications of any technology
+   they develop.  This analysis must be included in any resulting RFCs
+   in a Security Considerations section.  Note that merely noting a
+   significant security hole is no longer sufficient.  IETF developed
+   technologies should not add insecurity to the environment in which
+   they are run.
+
+
+
+Bradner                  Best Current Practice                 [Page 22]
+
+RFC 2418                Working Group Guidelines          September 1998
+
+
+10. Acknowledgments
+
+   This revision of this document relies heavily on the previous version
+   (RFC 1603) which was edited by Erik Huizer and Dave Crocker.  It has
+   been reviewed by the Poisson Working Group.
+
+11. References
+
+   [1] Bradner, S., Editor, "The Internet Standards Process -- Revision
+       3", BCP 9, RFC 2026, October 1996.
+
+   [2] Hovey, R., and S. Bradner, "The Organizations involved in the
+       IETF Standards Process", BCP 11, RFC 2028, October 1996.
+
+   [3] Gavin, J., "IAB and IESG Selection, Confirmation, and Recall
+       Process: Operation of the Nominating and Recall Committees", BCP
+       10, RFC 2282, February 1998.
+
+   [4] Huitema, C., J. Postel, S. Crocker, "Not all RFCs are Standards",
+       RFC 1796, April 1995.
+
+   [5] Postel, J., and J. Reynolds, "Instructions to RFC Authors", RFC
+       2223, October 1997.
+
+   [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+       Level", BCP 14, RFC 2119, March 1997.
+
+
+12. Editor's Address
+
+   Scott Bradner
+   Harvard University
+   1350 Mass Ave.
+   Cambridge MA
+   02138
+   USA
+
+   Phone +1 617 495 3864
+   EMail: sob@harvard.edu
+
+
+
+
+
+
+
+
+
+
+
+
+Bradner                  Best Current Practice                 [Page 23]
+
+RFC 2418                Working Group Guidelines          September 1998
+
+
+   Appendix:  Sample Working Group Charter
+
+   Working Group Name:
+        IP Telephony (iptel)
+
+   IETF Area:
+        Transport Area
+
+   Chair(s):
+        Jonathan Rosenberg <jdrosen@bell-labs.com>
+
+   Transport Area Director(s):
+        Scott Bradner <sob@harvard.edu>
+        Allyn Romanow <allyn@mci.net>
+
+   Responsible Area Director:
+        Allyn Romanow <allyn@mci.net>
+
+   Mailing Lists:
+        General Discussion:iptel@lists.research.bell-labs.com
+        To Subscribe: iptel-request@lists.research.bell-labs.com
+        Archive: http://www.bell-labs.com/mailing-lists/siptel
+
+   Description of Working Group:
+
+   Before Internet telephony can become a widely deployed service, a
+   number of protocols must be deployed. These include signaling and
+   capabilities exchange, but also include a number of "peripheral"
+   protocols for providing related services.
+
+   The primary purpose of this working group is to develop two such
+   supportive protocols and a frameword document. They are:
+
+   1. Call Processing Syntax. When a call is setup between two
+   endpoints, the signaling will generally pass through several servers
+   (such as an H.323 gatekeeper) which are responsible for forwarding,
+   redirecting, or proxying the signaling messages. For example, a user
+   may make a call to j.doe@bigcompany.com. The signaling message to
+   initiate the call will arrive at some server at bigcompany. This
+   server can inform the caller that the callee is busy, forward the
+   call initiation request to another server closer to the user, or drop
+   the call completely (among other possibilities). It is very desirable
+   to allow the callee to provide input to this process, guiding the
+   server in its decision on how to act. This can enable a wide variety
+   of advanced personal mobility and call agent services.
+
+
+
+
+
+
+Bradner                  Best Current Practice                 [Page 24]
+
+RFC 2418                Working Group Guidelines          September 1998
+
+
+   Such preferences can be expressed in a call processing syntax, which
+   can be authored by the user (or generated automatically by some
+   tool), and then uploaded to the server. The group will develop this
+   syntax, and specify means of securely transporting and extending it.
+   The result will be a single standards track RFC.
+
+   2. In addition, the group will write a service model document, which
+   describes the services that are enabled by the call processing
+   syntax, and discusses how the syntax can be used. This document will
+   result in a single RFC.
+
+   3. Gateway Attribute Distribution Protocol. When making a call
+   between an IP host and a PSTN user, a telephony gateway must be used.
+   The selection of such gateways can be based on many criteria,
+   including client expressed preferences, service provider preferences,
+   and availability of gateways, in addition to destination telephone
+   number.  Since gateways outside of the hosts' administrative domain
+   might be used, a protocol is required to allow gateways in remote
+   domains to distribute their attributes (such as PSTN connectivity,
+   supported codecs, etc.) to entities in other domains which must make
+   a selection of a gateway. The protocol must allow for scalable,
+   bandwidth efficient, and very secure transmission of these
+   attributes. The group will investigate and design a protocol for this
+   purpose, generate an Internet Draft, and advance it to RFC as
+   appropriate.
+
+   Goals and Milestones:
+
+   May 98    Issue first Internet-Draft on service framework
+   Jul 98    Submit framework ID to IESG for publication as an RFC.
+   Aug 98    Issue first Internet-Draft on Call Processing Syntax
+   Oct 98    Submit Call processing syntax to IESG for consideration
+             as a Proposed Standard.
+   Dec 98    Achieve consensus on basics of gateway attribute
+             distribution protocol
+   Jan 99    Submit Gateway Attribute Distribution protocol to IESG
+             for consideration as a RFC (info, exp, stds track TB
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bradner                  Best Current Practice                 [Page 25]
+
+RFC 2418                Working Group Guidelines          September 1998
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (1998).  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 Standards process must be
+   followed, or as required to translate it into 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bradner                  Best Current Practice                 [Page 26]
+
diff --git a/doc/rfc/rfc2535.txt b/doc/rfc/rfc2535.txt
new file mode 100644
index 0000000..fe0b3d0
--- /dev/null
+++ b/doc/rfc/rfc2535.txt
@@ -0,0 +1,2635 @@
+
+
+
+
+
+
+Network Working Group                                         D. Eastlake
+Request for Comments: 2535                                            IBM
+Obsoletes: 2065                                                March 1999
+Updates: 2181, 1035, 1034
+Category: Standards Track
+
+                 Domain Name System Security Extensions
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (1999).  All Rights Reserved.
+
+Abstract
+
+   Extensions to the Domain Name System (DNS) are described that provide
+   data integrity and authentication to security aware resolvers and
+   applications through the use of cryptographic digital signatures.
+   These digital signatures are included in secured zones as resource
+   records.  Security can also be provided through non-security aware
+   DNS servers in some cases.
+
+   The extensions provide for the storage of authenticated public keys
+   in the DNS.  This storage of keys can support general public key
+   distribution services as well as DNS security.  The stored keys
+   enable security aware resolvers to learn the authenticating key of
+   zones in addition to those for which they are initially configured.
+   Keys associated with DNS names can be retrieved to support other
+   protocols.  Provision is made for a variety of key types and
+   algorithms.
+
+   In addition, the security extensions provide for the optional
+   authentication of DNS protocol transactions and requests.
+
+   This document incorporates feedback on RFC 2065 from early
+   implementers and potential users.
+
+
+
+
+
+
+
+
+Eastlake                    Standards Track                     [Page 1]
+
+RFC 2535                DNS Security Extensions               March 1999
+
+
+Acknowledgments
+
+   The significant contributions and suggestions of the following
+   persons (in alphabetic order) to DNS security are gratefully
+   acknowledged:
+
+      James M. Galvin
+      John Gilmore
+      Olafur Gudmundsson
+      Charlie Kaufman
+      Edward Lewis
+      Thomas Narten
+      Radia J. Perlman
+      Jeffrey I. Schiller
+      Steven (Xunhua) Wang
+      Brian Wellington
+
+Table of Contents
+
+   Abstract...................................................1
+   Acknowledgments............................................2
+   1. Overview of Contents....................................4
+   2. Overview of the DNS Extensions..........................5
+   2.1 Services Not Provided..................................5
+   2.2 Key Distribution.......................................5
+   2.3 Data Origin Authentication and Integrity...............6
+   2.3.1 The SIG Resource Record..............................7
+   2.3.2 Authenticating Name and Type Non-existence...........7
+   2.3.3 Special Considerations With Time-to-Live.............7
+   2.3.4 Special Considerations at Delegation Points..........8
+   2.3.5 Special Considerations with CNAME....................8
+   2.3.6 Signers Other Than The Zone..........................9
+   2.4 DNS Transaction and Request Authentication.............9
+   3. The KEY Resource Record................................10
+   3.1 KEY RDATA format......................................10
+   3.1.1 Object Types, DNS Names, and Keys...................11
+   3.1.2 The KEY RR Flag Field...............................11
+   3.1.3 The Protocol Octet..................................13
+   3.2 The KEY Algorithm Number Specification................14
+   3.3 Interaction of Flags, Algorithm, and Protocol Bytes...15
+   3.4 Determination of Zone Secure/Unsecured Status.........15
+   3.5 KEY RRs in the Construction of Responses..............17
+   4. The SIG Resource Record................................17
+   4.1 SIG RDATA Format......................................17
+   4.1.1 Type Covered Field..................................18
+   4.1.2 Algorithm Number Field..............................18
+   4.1.3 Labels Field........................................18
+   4.1.4 Original TTL Field..................................19
+
+
+
+Eastlake                    Standards Track                     [Page 2]
+
+RFC 2535                DNS Security Extensions               March 1999
+
+
+   4.1.5 Signature Expiration and Inception Fields...........19
+   4.1.6 Key Tag Field.......................................20
+   4.1.7 Signer's Name Field.................................20
+   4.1.8 Signature Field.....................................20
+   4.1.8.1 Calculating Transaction and Request SIGs..........21
+   4.2 SIG RRs in the Construction of Responses..............21
+   4.3 Processing Responses and SIG RRs......................22
+   4.4 Signature Lifetime, Expiration, TTLs, and Validity....23
+   5. Non-existent Names and Types...........................24
+   5.1 The NXT Resource Record...............................24
+   5.2 NXT RDATA Format......................................25
+   5.3 Additional Complexity Due to Wildcards................26
+   5.4 Example...............................................26
+   5.5 Special Considerations at Delegation Points...........27
+   5.6 Zone Transfers........................................27
+   5.6.1 Full Zone Transfers.................................28
+   5.6.2 Incremental Zone Transfers..........................28
+   6. How to Resolve Securely and the AD and CD Bits.........29
+   6.1 The AD and CD Header Bits.............................29
+   6.2 Staticly Configured Keys..............................31
+   6.3 Chaining Through The DNS..............................31
+   6.3.1 Chaining Through KEYs...............................31
+   6.3.2 Conflicting Data....................................33
+   6.4 Secure Time...........................................33
+   7. ASCII Representation of Security RRs...................34
+   7.1 Presentation of KEY RRs...............................34
+   7.2 Presentation of SIG RRs...............................35
+   7.3 Presentation of NXT RRs...............................36
+   8. Canonical Form and Order of Resource Records...........36
+   8.1 Canonical RR Form.....................................36
+   8.2 Canonical DNS Name Order..............................37
+   8.3 Canonical RR Ordering Within An RRset.................37
+   8.4 Canonical Ordering of RR Types........................37
+   9. Conformance............................................37
+   9.1 Server Conformance....................................37
+   9.2 Resolver Conformance..................................38
+   10. Security Considerations...............................38
+   11. IANA Considerations...................................39
+   References................................................39
+   Author's Address..........................................41
+   Appendix A: Base 64 Encoding..............................42
+   Appendix B: Changes from RFC 2065.........................44
+   Appendix C: Key Tag Calculation...........................46
+   Full Copyright Statement..................................47
+
+
+
+
+
+
+
+Eastlake                    Standards Track                     [Page 3]
+
+RFC 2535                DNS Security Extensions               March 1999
+
+
+1. Overview of Contents
+
+   This document standardizes extensions of the Domain Name System (DNS)
+   protocol to support DNS security and public key distribution. It
+   assumes that the reader is familiar with the Domain Name System,
+   particularly as described in RFCs 1033, 1034, 1035 and later RFCs. An
+   earlier version of these extensions appears in RFC 2065.  This
+   replacement for that RFC incorporates early implementation experience
+   and requests from  potential users.
+
+   Section 2 provides an overview of the extensions and the key
+   distribution, data origin authentication, and transaction and request
+   security they provide.
+
+   Section 3 discusses the KEY resource record, its structure, and use
+   in DNS responses.  These resource records represent the public keys
+   of entities named in the DNS and are used for key distribution.
+
+   Section 4 discusses the SIG digital signature resource record, its
+   structure, and use in DNS responses.  These resource records are used
+   to authenticate other resource records in the DNS and optionally to
+   authenticate DNS transactions and requests.
+
+   Section 5 discusses the NXT resource record (RR) and its use in DNS
+   responses including full and incremental zone transfers.  The NXT RR
+   permits authenticated denial of the existence of a name or of an RR
+   type for an existing name.
+
+   Section 6 discusses how a resolver can be configured with a starting
+   key or keys and proceed to securely resolve DNS requests.
+   Interactions between resolvers and servers are discussed for various
+   combinations of security aware and security non-aware.  Two
+   additional DNS header bits are defined for signaling between
+   resolvers and servers.
+
+   Section 7 describes the ASCII representation of the security resource
+   records for use in master files and elsewhere.
+
+   Section 8 defines the canonical form and order of RRs for DNS
+   security purposes.
+
+   Section 9 defines levels of conformance for resolvers and servers.
+
+   Section 10 provides a few paragraphs on overall security
+   considerations.
+
+   Section 11 specified IANA considerations for allocation of additional
+   values of paramters defined in this document.
+
+
+
+Eastlake                    Standards Track                     [Page 4]
+
+RFC 2535                DNS Security Extensions               March 1999
+
+
+   Appendix A gives details of base 64 encoding which is used in the
+   file representation of some RRs defined in this document.
+
+   Appendix B summarizes changes between this memo and RFC 2065.
+
+   Appendix C specified how to calculate the simple checksum used as a
+   key tag in most SIG RRs.
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC2119].
+
+2. Overview of the DNS Extensions
+
+   The Domain Name System (DNS) protocol security extensions provide
+   three distinct services: key distribution as described in Section 2.2
+   below, data origin authentication as described in Section 2.3 below,
+   and transaction and request authentication, described in Section 2.4
+   below.
+
+   Special considerations related to "time to live", CNAMEs, and
+   delegation points are also discussed in Section 2.3.
+
+2.1 Services Not Provided
+
+   It is part of the design philosophy of the DNS that the data in it is
+   public and that the DNS gives the same answers to all inquirers.
+   Following this philosophy, no attempt has been made to include any
+   sort of access control lists or other means to differentiate
+   inquirers.
+
+   No effort has been made to provide for any confidentiality for
+   queries or responses.  (This service may be available via IPSEC [RFC
+   2401], TLS, or other security protocols.)
+
+   Protection is not provided against denial of service.
+
+2.2 Key Distribution
+
+   A resource record format is defined to associate keys with DNS names.
+   This permits the DNS to be used as a public key distribution
+   mechanism in support of DNS security itself and other protocols.
+
+   The syntax of a KEY resource record (RR) is described in Section 3.
+   It includes an algorithm identifier, the actual public key
+   parameter(s), and a variety of flags including those indicating the
+   type of entity the key is associated with and/or asserting that there
+   is no key associated with that entity.
+
+
+
+Eastlake                    Standards Track                     [Page 5]
+
+RFC 2535                DNS Security Extensions               March 1999
+
+
+   Under conditions described in Section 3.5, security aware DNS servers
+   will automatically attempt to return KEY resources as additional
+   information, along with those resource records actually requested, to
+   minimize the number of queries needed.
+
+2.3 Data Origin Authentication and Integrity
+
+   Authentication is provided by associating with resource record sets
+   (RRsets [RFC 2181]) in the DNS cryptographically generated digital
+   signatures. Commonly, there will be a single private key that
+   authenticates an entire zone but there might be multiple keys for
+   different algorithms, signers, etc. If a security aware resolver
+   reliably learns a public key of the zone, it can authenticate, for
+   signed data read from that zone, that it is properly authorized.  The
+   most secure implementation is for the zone private key(s) to be kept
+   off-line and used to re-sign all of the records in the zone
+   periodically.  However, there are cases, for example dynamic update
+   [RFCs 2136, 2137], where DNS private keys need to be on-line [RFC
+   2541].
+
+   The data origin authentication key(s) are associated with the zone
+   and not with the servers that store copies of the data.  That means
+   compromise of a secondary server or, if the key(s) are kept off line,
+   even the primary server for a zone, will not necessarily affect the
+   degree of assurance that a resolver has that it can determine whether
+   data is genuine.
+
+   A resolver could learn a public key of a zone either by reading it
+   from the DNS or by having it staticly configured.  To reliably learn
+   a public key by reading it from the DNS, the key itself must be
+   signed with a key the resolver trusts. The resolver must be
+   configured with at least a public key which authenticates one zone as
+   a starting point. From there, it can securely read public keys of
+   other zones, if the intervening zones in the DNS tree are secure and
+   their signed keys accessible.
+
+   Adding data origin authentication and integrity requires no change to
+   the "on-the-wire" DNS protocol beyond the addition of the signature
+   resource type and the key resource type needed for key distribution.
+   (Data non-existence authentication also requires the NXT RR as
+   described in 2.3.2.)  This service can be supported by existing
+   resolver and caching server implementations so long as they can
+   support the additional resource types (see Section 9). The one
+   exception is that CNAME referrals in a secure zone can not be
+   authenticated if they are from non-security aware servers (see
+   Section 2.3.5).
+
+
+
+
+
+Eastlake                    Standards Track                     [Page 6]
+
+RFC 2535                DNS Security Extensions               March 1999
+
+
+   If signatures are separately retrieved and verified when retrieving
+   the information they authenticate, there will be more trips to the
+   server and performance will suffer.  Security aware servers mitigate
+   that degradation by attempting to send the signature(s) needed (see
+   Section 4.2).
+
+2.3.1 The SIG Resource Record
+
+   The syntax of a SIG resource record (signature) is described in
+   Section 4.  It cryptographicly binds the RRset being signed to the
+   signer and a validity interval.
+
+   Every name in a secured zone will have associated with it at least
+   one SIG resource record for each resource type under that name except
+   for glue address RRs and delegation point NS RRs.  A security aware
+   server will attempt to return, with RRs retrieved, the corresponding
+   SIGs.  If a server is not security aware, the resolver must retrieve
+   all the SIG records for a name and select the one or ones that sign
+   the resource record set(s) that resolver is interested in.
+
+2.3.2 Authenticating Name and Type Non-existence
+
+   The above security mechanism only provides a way to sign existing
+   RRsets in a zone.  "Data origin" authentication is not obviously
+   provided for the non-existence of a domain name in a zone or the
+   non-existence of a type for an existing name.  This gap is filled by
+   the NXT RR which authenticatably asserts a range of non-existent
+   names in a zone and the non-existence of types for the existing name
+   just before that range.
+
+   Section 5 below covers the NXT RR.
+
+2.3.3 Special Considerations With Time-to-Live
+
+   A digital signature will fail to verify if any change has occurred to
+   the data between the time it was originally signed and the time the
+   signature is verified.  This conflicts with our desire to have the
+   time-to-live (TTL) field of resource records tick down while they are
+   cached.
+
+   This could be avoided by leaving the time-to-live out of the digital
+   signature, but that would allow unscrupulous servers to set
+   arbitrarily long TTL values undetected.  Instead, we include the
+   "original" TTL in the signature and communicate that data along with
+   the current TTL. Unscrupulous servers under this scheme can
+   manipulate the TTL but a security aware resolver will bound the TTL
+   value it uses at the original signed value.  Separately, signatures
+   include a signature inception time and a signature expiration time. A
+
+
+
+Eastlake                    Standards Track                     [Page 7]
+
+RFC 2535                DNS Security Extensions               March 1999
+
+
+   resolver that knows the absolute time can determine securely whether
+   a signature is in effect.  It is not possible to rely solely on the
+   signature expiration as a substitute for the TTL, however, since the
+   TTL is primarily a database consistency mechanism and non-security
+   aware servers that depend on TTL must still be supported.
+
+2.3.4 Special Considerations at Delegation Points
+
+   DNS security would like to view each zone as a unit of data
+   completely under the control of the zone owner with each entry
+   (RRset) signed by a special private key held by the zone manager.
+   But the DNS protocol views the leaf nodes in a zone, which are also
+   the apex nodes of a subzone (i.e., delegation points), as "really"
+   belonging to the subzone.  These nodes occur in two master files and
+   might have RRs signed by both the upper and lower zone's keys. A
+   retrieval could get a mixture of these RRs and SIGs, especially since
+   one server could be serving both the zone above and below a
+   delegation point. [RFC 2181]
+
+   There MUST be a zone KEY RR, signed by its superzone, for every
+   subzone if the superzone is secure. This will normally appear in the
+   subzone and may also be included in the superzone.  But, in the case
+   of an unsecured subzone which can not or will not be modified to add
+   any security RRs, a KEY declaring the subzone to be unsecured MUST
+   appear with the superzone signature in the superzone, if the
+   superzone is secure. For all but one other RR type the data from the
+   subzone is more authoritative so only the subzone KEY RR should be
+   signed in the superzone if it appears there. The NS and any glue
+   address RRs SHOULD only be signed in the subzone. The SOA and any
+   other RRs that have the zone name as owner should appear only in the
+   subzone and thus are signed only there. The NXT RR type is the
+   exceptional case that will always appear differently and
+   authoritatively in both the superzone and subzone, if both are
+   secure, as described in Section 5.
+
+2.3.5 Special Considerations with CNAME
+
+   There is a problem when security related RRs with the same owner name
+   as a CNAME RR are retrieved from a non-security-aware server. In
+   particular, an initial retrieval for the CNAME or any other type may
+   not retrieve any associated SIG, KEY, or NXT RR. For retrieved types
+   other than CNAME, it will retrieve that type at the target name of
+   the CNAME (or chain of CNAMEs) and will also return the CNAME.  In
+   particular, a specific retrieval for type SIG will not get the SIG,
+   if any, at the original CNAME domain name but rather a SIG at the
+   target name.
+
+
+
+
+
+Eastlake                    Standards Track                     [Page 8]
+
+RFC 2535                DNS Security Extensions               March 1999
+
+
+   Security aware servers must be used to securely CNAME in DNS.
+   Security aware servers MUST (1) allow KEY, SIG, and NXT RRs along
+   with CNAME RRs, (2) suppress CNAME processing on retrieval of these
+   types as well as on retrieval of the type CNAME, and (3)
+   automatically return SIG RRs authenticating the CNAME or CNAMEs
+   encountered in resolving a query.  This is a change from the previous
+   DNS standard [RFCs 1034/1035] which prohibited any other RR type at a
+   node where a CNAME RR was present.
+
+2.3.6 Signers Other Than The Zone
+
+   There are cases where the signer in a SIG resource record is other
+   than one of the private key(s) used to authenticate a zone.
+
+   One is for support of dynamic update [RFC 2136] (or future requests
+   which require secure authentication) where an entity is permitted to
+   authenticate/update its records [RFC 2137] and the zone is operating
+   in a mode where the zone key is not on line. The public key of the
+   entity must be present in the DNS and be signed by a zone level key
+   but the other RR(s) may be signed with the entity's key.
+
+   A second case is support of transaction and request authentication as
+   described in Section 2.4.
+
+   In additions, signatures can be included on resource records within
+   the DNS for use by applications other than DNS. DNS related
+   signatures authenticate that data originated with the authority of a
+   zone owner or that a request or transaction originated with the
+   relevant entity. Other signatures can provide other types of
+   assurances.
+
+2.4 DNS Transaction and Request Authentication
+
+   The data origin authentication service described above protects
+   retrieved resource records and the non-existence of resource records
+   but provides no protection for DNS requests or for message headers.
+
+   If header bits are falsely set by a bad server, there is little that
+   can be done.  However, it is possible to add transaction
+   authentication.  Such authentication means that a resolver can be
+   sure it is at least getting messages from the server it thinks it
+   queried and that the response is from the query it sent (i.e., that
+   these messages have not been diddled in transit).  This is
+   accomplished by optionally adding a special SIG resource record at
+   the end of the reply which digitally signs the concatenation of the
+   server's response and the resolver's query.
+
+
+
+
+
+Eastlake                    Standards Track                     [Page 9]
+
+RFC 2535                DNS Security Extensions               March 1999
+
+
+   Requests can also be authenticated by including a special SIG RR at
+   the end of the request.  Authenticating requests serves no function
+   in older DNS servers and requests with a non-empty additional
+   information section produce error returns or may even be ignored by
+   many of them. However, this syntax for signing requests is defined as
+   a way of authenticating secure dynamic update requests [RFC 2137] or
+   future requests requiring authentication.
+
+   The private keys used in transaction security belong to the entity
+   composing the reply, not to the zone involved.  Request
+   authentication may also involve the private key of the host or other
+   entity composing the request or other private keys depending on the
+   request authority it is sought to establish. The corresponding public
+   key(s) are normally stored in and retrieved from the DNS for
+   verification.
+
+   Because requests and replies are highly variable, message
+   authentication SIGs can not be pre-calculated.  Thus it will be
+   necessary to keep the private key on-line, for example in software or
+   in a directly connected piece of hardware.
+
+3. The KEY Resource Record
+
+   The KEY resource record (RR) is used to store a public key that is
+   associated with a Domain Name System (DNS) name.  This can be the
+   public key of a zone, a user, or a host or other end entity. Security
+   aware DNS implementations MUST be designed to handle at least two
+   simultaneously valid keys of the same type associated with the same
+   name.
+
+   The type number for the KEY RR is 25.
+
+   A KEY RR is, like any other RR, authenticated by a SIG RR.  KEY RRs
+   must be signed by a zone level key.
+
+3.1 KEY RDATA format
+
+   The RDATA for a KEY RR consists of flags, a protocol octet, the
+   algorithm number octet, and the public key itself.  The format is as
+   follows:
+
+
+
+
+
+
+
+
+
+
+
+Eastlake                    Standards Track                    [Page 10]
+
+RFC 2535                DNS Security Extensions               March 1999
+
+
+                        1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |             flags             |    protocol   |   algorithm   |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                                                               /
+   /                          public key                           /
+   /                                                               /
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
+
+   The KEY RR is not intended for storage of certificates and a separate
+   certificate RR has been developed for that purpose, defined in [RFC
+   2538].
+
+   The meaning of the KEY RR owner name, flags, and protocol octet are
+   described in Sections 3.1.1 through 3.1.5 below.  The flags and
+   algorithm must be examined before any data following the algorithm
+   octet as they control the existence and format of any following data.
+   The algorithm and public key fields are described in Section 3.2.
+   The format of the public key is algorithm dependent.
+
+   KEY RRs do not specify their validity period but their authenticating
+   SIG RR(s) do as described in Section 4 below.
+
+3.1.1 Object Types, DNS Names, and Keys
+
+   The public key in a KEY RR is for the object named in the owner name.
+
+   A DNS name may refer to three different categories of things.  For
+   example, foo.host.example could be (1) a zone, (2) a host or other
+   end entity , or (3) the mapping into a DNS name of the user or
+   account foo@host.example.  Thus, there are flag bits, as described
+   below, in the KEY RR to indicate with which of these roles the owner
+   name and public key are associated.  Note that an appropriate zone
+   KEY RR MUST occur at the apex node of a secure zone and zone KEY RRs
+   occur only at delegation points.
+
+3.1.2 The KEY RR Flag Field
+
+   In the "flags" field:
+
+     0   1   2   3   4   5   6   7   8   9   0   1   2   3   4   5
+   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+   |  A/C  | Z | XT| Z | Z | NAMTYP| Z | Z | Z | Z |      SIG      |
+   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+
+   Bit 0 and 1 are the key "type" bits whose values have the following
+   meanings:
+
+
+
+Eastlake                    Standards Track                    [Page 11]
+
+RFC 2535                DNS Security Extensions               March 1999
+
+
+           10: Use of the key is prohibited for authentication.
+           01: Use of the key is prohibited for confidentiality.
+           00: Use of the key for authentication and/or confidentiality
+               is permitted. Note that DNS security makes use of keys
+               for authentication only. Confidentiality use flagging is
+               provided for use of keys in other protocols.
+               Implementations not intended to support key distribution
+               for confidentiality MAY require that the confidentiality
+               use prohibited bit be on for keys they serve.
+           11: If both bits are one, the "no key" value, there is no key
+               information and the RR stops after the algorithm octet.
+               By the use of this "no key" value, a signed KEY RR can
+               authenticatably assert that, for example, a zone is not
+               secured.  See section 3.4 below.
+
+   Bits 2 is reserved and must be zero.
+
+   Bits 3 is reserved as a flag extension bit.  If it is a one, a second
+          16 bit flag field is added after the algorithm octet and
+          before the key data.  This bit MUST NOT be set unless one or
+          more such additional bits have been defined and are non-zero.
+
+   Bits 4-5 are reserved and must be zero.
+
+   Bits 6 and 7 form a field that encodes the name type. Field values
+   have the following meanings:
+
+           00: indicates that this is a key associated with a "user" or
+               "account" at an end entity, usually a host.  The coding
+               of the owner name is that used for the responsible
+               individual mailbox in the SOA and RP RRs: The owner name
+               is the user name as the name of a node under the entity
+               name.  For example, "j_random_user" on
+               host.subdomain.example could have a public key associated
+               through a KEY RR with name
+               j_random_user.host.subdomain.example.  It could be used
+               in a security protocol where authentication of a user was
+               desired.  This key might be useful in IP or other
+               security for a user level service such a telnet, ftp,
+               rlogin, etc.
+           01: indicates that this is a zone key for the zone whose name
+               is the KEY RR owner name.  This is the public key used
+               for the primary DNS security feature of data origin
+               authentication.  Zone KEY RRs occur only at delegation
+               points.
+           10: indicates that this is a key associated with the non-zone
+               "entity" whose name is the RR owner name.  This will
+               commonly be a host but could, in some parts of the DNS
+
+
+
+Eastlake                    Standards Track                    [Page 12]
+
+RFC 2535                DNS Security Extensions               March 1999
+
+
+               tree, be some other type of entity such as a telephone
+               number [RFC 1530] or numeric IP address.  This is the
+               public key used in connection with DNS request and
+               transaction authentication services.  It could also be
+               used in an IP-security protocol where authentication at
+               the host, rather than user, level was desired, such as
+               routing, NTP, etc.
+           11: reserved.
+
+   Bits 8-11 are reserved and must be zero.
+
+   Bits 12-15 are the "signatory" field.  If non-zero, they indicate
+              that the key can validly sign things as specified in DNS
+              dynamic update [RFC 2137].  Note that zone keys (see bits
+              6 and 7 above) always have authority to sign any RRs in
+              the zone regardless of the value of the signatory field.
+
+3.1.3 The Protocol Octet
+
+   It is anticipated that keys stored in DNS will be used in conjunction
+   with a variety of Internet protocols.  It is intended that the
+   protocol octet and possibly some of the currently unused (must be
+   zero) bits in the KEY RR flags as specified in the future will be
+   used to indicate a key's validity for different protocols.
+
+   The following values of the Protocol Octet are reserved as indicated:
+
+        VALUE   Protocol
+
+          0      -reserved
+          1     TLS
+          2     email
+          3     dnssec
+          4     IPSEC
+         5-254   - available for assignment by IANA
+        255     All
+
+   In more detail:
+        1 is reserved for use in connection with TLS.
+        2 is reserved for use in connection with email.
+        3 is used for DNS security.  The protocol field SHOULD be set to
+          this value for zone keys and other keys used in DNS security.
+          Implementations that can determine that a key is a DNS
+          security key by the fact that flags label it a zone key or the
+          signatory flag field is non-zero are NOT REQUIRED to check the
+          protocol field.
+        4 is reserved to refer to the Oakley/IPSEC [RFC 2401] protocol
+          and indicates that this key is valid for use in conjunction
+
+
+
+Eastlake                    Standards Track                    [Page 13]
+
+RFC 2535                DNS Security Extensions               March 1999
+
+
+          with that security standard.  This key could be used in
+          connection with secured communication on behalf of an end
+          entity or user whose name is the owner name of the KEY RR if
+          the entity or user flag bits are set.  The presence of a KEY
+          resource with this protocol value is an assertion that the
+          host speaks Oakley/IPSEC.
+        255 indicates that the key can be used in connection with any
+          protocol for which KEY RR protocol octet values have been
+          defined.  The use of this value is discouraged and the use of
+          different keys for different protocols is encouraged.
+
+3.2 The KEY Algorithm Number Specification
+
+   This octet is the key algorithm parallel to the same field for the
+   SIG resource as described in Section 4.1.  The following values are
+   assigned:
+
+   VALUE   Algorithm
+
+     0      - reserved, see Section 11
+     1     RSA/MD5 [RFC 2537] - recommended
+     2     Diffie-Hellman [RFC 2539] - optional, key only
+     3     DSA [RFC 2536] - MANDATORY
+     4     reserved for elliptic curve crypto
+   5-251    - available, see Section 11
+   252     reserved for indirect keys
+   253     private - domain name (see below)
+   254     private - OID (see below)
+   255      - reserved, see Section 11
+
+   Algorithm specific formats and procedures are given in separate
+   documents.  The mandatory to implement for interoperability algorithm
+   is number 3, DSA.  It is recommended that the RSA/MD5 algorithm,
+   number 1, also be implemented.  Algorithm 2 is used to indicate
+   Diffie-Hellman keys and algorithm 4 is reserved for elliptic curve.
+
+   Algorithm number 252 indicates an indirect key format where the
+   actual key material is elsewhere.  This format is to be defined in a
+   separate document.
+
+   Algorithm numbers 253 and 254 are reserved for private use and will
+   never be assigned a specific algorithm.  For number 253, the public
+   key area and the signature begin with a wire encoded domain name.
+   Only local domain name compression is permitted.  The domain name
+   indicates the private algorithm to use and the remainder of the
+   public key area is whatever is required by that algorithm.  For
+   number 254, the public key area for the KEY RR and the signature
+   begin with an unsigned length byte followed by a BER encoded Object
+
+
+
+Eastlake                    Standards Track                    [Page 14]
+
+RFC 2535                DNS Security Extensions               March 1999
+
+
+   Identifier (ISO OID) of that length.  The OID indicates the private
+   algorithm in use and the remainder of the area is whatever is
+   required by that algorithm.  Entities should only use domain names
+   and OIDs they control to designate their private algorithms.
+
+   Values 0 and 255 are reserved but the value 0 is used in the
+   algorithm field when that field is not used.  An example is in a KEY
+   RR with the top two flag bits on, the "no-key" value, where no key is
+   present.
+
+3.3 Interaction of Flags, Algorithm, and Protocol Bytes
+
+   Various combinations of the no-key type flags, algorithm byte,
+   protocol byte, and any future assigned protocol indicating flags are
+   possible.  The meaning of these combinations is indicated below:
+
+   NK = no key type (flags bits 0 and 1 on)
+   AL = algorithm byte
+   PR = protocols indicated by protocol byte or future assigned flags
+
+   x represents any valid non-zero value(s).
+
+    AL  PR   NK  Meaning
+     0   0   0   Illegal, claims key but has bad algorithm field.
+     0   0   1   Specifies total lack of security for owner zone.
+     0   x   0   Illegal, claims key but has bad algorithm field.
+     0   x   1   Specified protocols unsecured, others may be secure.
+     x   0   0   Gives key but no protocols to use it.
+     x   0   1   Denies key for specific algorithm.
+     x   x   0   Specifies key for protocols.
+     x   x   1   Algorithm not understood for protocol.
+
+3.4 Determination of Zone Secure/Unsecured Status
+
+   A zone KEY RR with the "no-key" type field value (both key type flag
+   bits 0 and 1 on) indicates that the zone named is unsecured while a
+   zone KEY RR with a key present indicates that the zone named is
+   secure.  The secured versus unsecured status of a zone may vary with
+   different cryptographic algorithms.  Even for the same algorithm,
+   conflicting zone KEY RRs may be present.
+
+   Zone KEY RRs, like all RRs, are only trusted if they are
+   authenticated by a SIG RR whose signer field is a signer for which
+   the resolver has a public key they trust and where resolver policy
+   permits that signer to sign for the KEY owner name.  Untrusted zone
+   KEY RRs MUST be ignored in determining the security status of the
+   zone.  However, there can be multiple sets of trusted zone KEY RRs
+   for a zone with different algorithms, signers, etc.
+
+
+
+Eastlake                    Standards Track                    [Page 15]
+
+RFC 2535                DNS Security Extensions               March 1999
+
+
+   For any particular algorithm, zones can be (1) secure, indicating
+   that any retrieved RR must be authenticated by a SIG RR or it will be
+   discarded as bogus, (2) unsecured, indicating that SIG RRs are not
+   expected or required for RRs retrieved from the zone, or (3)
+   experimentally secure, which indicates that SIG RRs might or might
+   not be present but must be checked if found.  The status of a zone is
+   determined as follows:
+
+   1. If, for a zone and algorithm, every trusted zone KEY RR for the
+      zone says there is no key for that zone, it is unsecured for that
+      algorithm.
+
+   2. If, there is at least one trusted no-key zone KEY RR and one
+      trusted key specifying zone KEY RR, then that zone is only
+      experimentally secure for the algorithm.  Both authenticated and
+      non-authenticated RRs for it should be accepted by the resolver.
+
+   3. If every trusted zone KEY RR that the zone and algorithm has is
+      key specifying, then it is secure for that algorithm and only
+      authenticated RRs from it will be accepted.
+
+   Examples:
+
+   (1)  A resolver initially trusts only signatures by the superzone of
+   zone Z within the DNS hierarchy.  Thus it will look only at the KEY
+   RRs that are signed by the superzone.  If it finds only no-key KEY
+   RRs, it will assume the zone is not secure.  If it finds only key
+   specifying KEY RRs, it will assume the zone is secure and reject any
+   unsigned responses.  If it finds both, it will assume the zone is
+   experimentally secure
+
+   (2)  A resolver trusts the superzone of zone Z (to which it got
+   securely from its local zone) and a third party, cert-auth.example.
+   When considering data from zone Z, it may be signed by the superzone
+   of Z, by cert-auth.example, by both, or by neither.  The following
+   table indicates whether zone Z will be considered secure,
+   experimentally secure, or unsecured, depending on the signed zone KEY
+   RRs for Z;
+
+                      c e r t - a u t h . e x a m p l e
+
+        KEY RRs|   None    |  NoKeys   |  Mixed   |   Keys   |
+     S       --+-----------+-----------+----------+----------+
+     u  None   | illegal   | unsecured | experim. | secure   |
+     p       --+-----------+-----------+----------+----------+
+     e  NoKeys | unsecured | unsecured | experim. | secure   |
+     r       --+-----------+-----------+----------+----------+
+     Z  Mixed  | experim.  | experim.  | experim. | secure   |
+
+
+
+Eastlake                    Standards Track                    [Page 16]
+
+RFC 2535                DNS Security Extensions               March 1999
+
+
+     o       --+-----------+-----------+----------+----------+
+     n  Keys   | secure    | secure    | secure   | secure   |
+     e         +-----------+-----------+----------+----------+
+
+3.5 KEY RRs in the Construction of Responses
+
+   An explicit request for KEY RRs does not cause any special additional
+   information processing except, of course, for the corresponding SIG
+   RR from a security aware server (see Section 4.2).
+
+   Security aware DNS servers include KEY RRs as additional information
+   in responses, where a KEY is available, in the following cases:
+
+   (1) On the retrieval of SOA or NS RRs, the KEY RRset with the same
+   name (perhaps just a zone key) SHOULD be included as additional
+   information if space is available. If not all additional information
+   will fit, type A and AAAA glue RRs have higher priority than KEY
+   RR(s).
+
+   (2) On retrieval of type A or AAAA RRs, the KEY RRset with the same
+   name (usually just a host RR and NOT the zone key (which usually
+   would have a different name)) SHOULD be included if space is
+   available.  On inclusion of A or AAAA RRs as additional information,
+   the KEY RRset with the same name should also be included but with
+   lower priority than the A or AAAA RRs.
+
+4. The SIG Resource Record
+
+   The SIG or "signature" resource record (RR) is the fundamental way
+   that data is authenticated in the secure Domain Name System (DNS). As
+   such it is the heart of the security provided.
+
+   The SIG RR unforgably authenticates an RRset [RFC 2181] of a
+   particular type, class, and name and binds it to a time interval and
+   the signer's domain name.  This is done using cryptographic
+   techniques and the signer's private key.  The signer is frequently
+   the owner of the zone from which the RR originated.
+
+   The type number for the SIG RR type is 24.
+
+4.1 SIG RDATA Format
+
+   The RDATA portion of a SIG RR is as shown below.  The integrity of
+   the RDATA information is protected by the signature field.
+
+
+
+
+
+
+
+Eastlake                    Standards Track                    [Page 17]
+
+RFC 2535                DNS Security Extensions               March 1999
+
+
+                           1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
+       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |        type covered           |  algorithm    |     labels    |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                         original TTL                          |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                      signature expiration                     |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                      signature inception                      |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |            key  tag           |                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+         signer's name         +
+      |                                                               /
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-/
+      /                                                               /
+      /                            signature                          /
+      /                                                               /
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+4.1.1 Type Covered Field
+
+   The "type covered" is the type of the other RRs covered by this SIG.
+
+4.1.2 Algorithm Number Field
+
+   This octet is as described in section 3.2.
+
+4.1.3 Labels Field
+
+   The "labels" octet is an unsigned count of how many labels there are
+   in the original SIG RR owner name not counting the null label for
+   root and not counting any initial "*" for a wildcard.  If a secured
+   retrieval is the result of wild card substitution, it is necessary
+   for the resolver to use the original form of the name in verifying
+   the digital signature.  This field makes it easy to determine the
+   original form.
+
+   If, on retrieval, the RR appears to have a longer name than indicated
+   by "labels", the resolver can tell it is the result of wildcard
+   substitution.  If the RR owner name appears to be shorter than the
+   labels count, the SIG RR must be considered corrupt and ignored.  The
+   maximum number of labels allowed in the current DNS is 127 but the
+   entire octet is reserved and would be required should DNS names ever
+   be expanded to 255 labels.  The following table gives some examples.
+   The value of "labels" is at the top, the retrieved owner name on the
+   left, and the table entry is the name to use in signature
+   verification except that "bad" means the RR is corrupt.
+
+
+
+Eastlake                    Standards Track                    [Page 18]
+
+RFC 2535                DNS Security Extensions               March 1999
+
+
+   labels= |  0  |   1  |    2   |      3   |      4   |
+   --------+-----+------+--------+----------+----------+
+          .|   . | bad  |  bad   |    bad   |    bad   |
+         d.|  *. |   d. |  bad   |    bad   |    bad   |
+       c.d.|  *. | *.d. |   c.d. |    bad   |    bad   |
+     b.c.d.|  *. | *.d. | *.c.d. |   b.c.d. |    bad   |
+   a.b.c.d.|  *. | *.d. | *.c.d. | *.b.c.d. | a.b.c.d. |
+
+4.1.4 Original TTL Field
+
+   The "original TTL" field is included in the RDATA portion to avoid
+   (1) authentication problems that caching servers would otherwise
+   cause by decrementing the real TTL field and (2) security problems
+   that unscrupulous servers could otherwise cause by manipulating the
+   real TTL field.  This original TTL is protected by the signature
+   while the current TTL field is not.
+
+   NOTE:  The "original TTL" must be restored into the covered RRs when
+   the signature is verified (see Section 8).  This generaly implies
+   that all RRs for a particular type, name, and class, that is, all the
+   RRs in any particular RRset, must have the same TTL to start with.
+
+4.1.5 Signature Expiration and Inception Fields
+
+   The SIG is valid from the "signature inception" time until the
+   "signature expiration" time.  Both are unsigned numbers of seconds
+   since the start of 1 January 1970, GMT, ignoring leap seconds.  (See
+   also Section 4.4.)  Ring arithmetic is used as for DNS SOA serial
+   numbers [RFC 1982] which means that these times can never be more
+   than about 68 years in the past or the future.  This means that these
+   times are ambiguous modulo ~136.09 years.  However there is no
+   security flaw because keys are required to be changed to new random
+   keys by [RFC 2541] at least every five years.  This means that the
+   probability that the same key is in use N*136.09 years later should
+   be the same as the probability that a random guess will work.
+
+   A SIG RR may have an expiration time numerically less than the
+   inception time if the expiration time is near the 32 bit wrap around
+   point and/or the signature is long lived.
+
+   (To prevent misordering of network requests to update a zone
+   dynamically, monotonically increasing "signature inception" times may
+   be necessary.)
+
+   A secure zone must be considered changed for SOA serial number
+   purposes not only when its data is updated but also when new SIG RRs
+   are inserted (ie, the zone or any part of it is re-signed).
+
+
+
+
+Eastlake                    Standards Track                    [Page 19]
+
+RFC 2535                DNS Security Extensions               March 1999
+
+
+4.1.6 Key Tag Field
+
+   The "key Tag" is a two octet quantity that is used to efficiently
+   select between multiple keys which may be applicable and thus check
+   that a public key about to be used for the computationally expensive
+   effort to check the signature is possibly valid.  For algorithm 1
+   (MD5/RSA) as defined in [RFC 2537], it is the next to the bottom two
+   octets of the public key modulus needed to decode the signature
+   field.  That is to say, the most significant 16 of the least
+   significant 24 bits of the modulus in network (big endian) order. For
+   all other algorithms, including private algorithms, it is calculated
+   as a simple checksum of the KEY RR as described in Appendix C.
+
+4.1.7 Signer's Name Field
+
+   The "signer's name" field is the domain name of the signer generating
+   the SIG RR.  This is the owner name of the public KEY RR that can be
+   used to verify the signature.  It is frequently the zone which
+   contained the RRset being authenticated.  Which signers should be
+   authorized to sign what is a significant resolver policy question as
+   discussed in Section 6. The signer's name may be compressed with
+   standard DNS name compression when being transmitted over the
+   network.
+
+4.1.8 Signature Field
+
+   The actual signature portion of the SIG RR binds the other RDATA
+   fields to the RRset of the "type covered" RRs with that owner name
+   and class.  This covered RRset is thereby authenticated.  To
+   accomplish this, a data sequence is constructed as follows:
+
+         data = RDATA | RR(s)...
+
+   where "|" is concatenation,
+
+   RDATA is the wire format of all the RDATA fields in the SIG RR itself
+   (including the canonical form of the signer's name) before but not
+   including the signature, and
+
+   RR(s) is the RRset of the RR(s) of the type covered with the same
+   owner name and class as the SIG RR in canonical form and order as
+   defined in Section 8.
+
+   How this data sequence is processed into the signature is algorithm
+   dependent.  These algorithm dependent formats and procedures are
+   described in separate documents (Section 3.2).
+
+
+
+
+
+Eastlake                    Standards Track                    [Page 20]
+
+RFC 2535                DNS Security Extensions               March 1999
+
+
+   SIGs SHOULD NOT be included in a zone for any "meta-type" such as
+   ANY, AXFR, etc. (but see section 5.6.2 with regard to IXFR).
+
+4.1.8.1 Calculating Transaction and Request SIGs
+
+   A response message from a security aware server may optionally
+   contain a special SIG at the end of the additional information
+   section to authenticate the transaction.
+
+   This SIG has a "type covered" field of zero, which is not a valid RR
+   type.  It is calculated by using a "data" (see Section 4.1.8) of the
+   entire preceding DNS reply message, including DNS header but not the
+   IP header and before the reply RR counts have been adjusted for the
+   inclusion of any transaction SIG, concatenated with the entire DNS
+   query message that produced this response, including the query's DNS
+   header and any request SIGs but not its IP header.  That is
+
+      data = full response (less transaction SIG) | full query
+
+   Verification of the transaction SIG (which is signed by the server
+   host key, not the zone key) by the requesting resolver shows that the
+   query and response were not tampered with in transit, that the
+   response corresponds to the intended query, and that the response
+   comes from the queried server.
+
+   A DNS request may be optionally signed by including one or more SIGs
+   at the end of the query. Such SIGs are identified by having a "type
+   covered" field of zero. They sign the preceding DNS request message
+   including DNS header but not including the IP header or any request
+   SIGs at the end and before the request RR counts have been adjusted
+   for the inclusions of any request SIG(s).
+
+   WARNING: Request SIGs are unnecessary for any currently defined
+   request other than update [RFC 2136, 2137] and will cause some old
+   DNS servers to give an error return or ignore a query.  However, such
+   SIGs may in the future be needed for other requests.
+
+   Except where needed to authenticate an update or similar privileged
+   request, servers are not required to check request SIGs.
+
+4.2 SIG RRs in the Construction of Responses
+
+   Security aware DNS servers SHOULD, for every authenticated RRset the
+   query will return, attempt to send the available SIG RRs which
+   authenticate the requested RRset.  The following rules apply to the
+   inclusion of SIG RRs in responses:
+
+
+
+
+
+Eastlake                    Standards Track                    [Page 21]
+
+RFC 2535                DNS Security Extensions               March 1999
+
+
+     1. when an RRset is placed in a response, its SIG RR has a higher
+        priority for inclusion than additional RRs that may need to be
+        included.  If space does not permit its inclusion, the response
+        MUST be considered truncated except as provided in 2 below.
+
+     2. When a SIG RR is present in the zone for an additional
+        information section RR, the response MUST NOT be considered
+        truncated merely because space does not permit the inclusion of
+        the SIG RR with the additional information.
+
+     3. SIGs to authenticate glue records and NS RRs for subzones at a
+        delegation point are unnecessary and MUST NOT be sent.
+
+     4. If a SIG covers any RR that would be in the answer section of
+        the response, its automatic inclusion MUST be in the answer
+        section.  If it covers an RR that would appear in the authority
+        section, its automatic inclusion MUST be in the authority
+        section.  If it covers an RR that would appear in the additional
+        information section it MUST appear in the additional information
+        section.  This is a change in the existing standard [RFCs 1034,
+        1035] which contemplates only NS and SOA RRs in the authority
+        section.
+
+     5. Optionally, DNS transactions may be authenticated by a SIG RR at
+        the end of the response in the additional information section
+        (Section 4.1.8.1).  Such SIG RRs are signed by the DNS server
+        originating the response.  Although the signer field MUST be a
+        name of the originating server host, the owner name, class, TTL,
+        and original TTL, are meaningless.  The class and TTL fields
+        SHOULD be zero.  To conserve space, the owner name SHOULD be
+        root (a single zero octet).  If transaction authentication is
+        desired, that SIG RR must be considered the highest priority for
+        inclusion.
+
+4.3 Processing Responses and SIG RRs
+
+   The following rules apply to the processing of SIG RRs included in a
+   response:
+
+     1. A security aware resolver that receives a response from a
+        security aware server via a secure communication with the AD bit
+        (see Section 6.1) set, MAY choose to accept the RRs as received
+        without verifying the zone SIG RRs.
+
+     2. In other cases, a security aware resolver SHOULD verify the SIG
+        RRs for the RRs of interest.  This may involve initiating
+        additional queries for SIG or KEY RRs, especially in the case of
+
+
+
+
+Eastlake                    Standards Track                    [Page 22]
+
+RFC 2535                DNS Security Extensions               March 1999
+
+
+        getting a response from a server that does not implement
+        security.  (As explained in 2.3.5 above, it will not be possible
+        to secure CNAMEs being served up by non-secure resolvers.)
+
+        NOTE: Implementers might expect the above SHOULD to be a MUST.
+        However, local policy or the calling application may not require
+        the security services.
+
+     3. If SIG RRs are received in response to a user query explicitly
+        specifying the SIG type, no special processing is required.
+
+   If the message does not pass integrity checks or the SIG does not
+   check against the signed RRs, the SIG RR is invalid and should be
+   ignored.  If all of the SIG RR(s) purporting to authenticate an RRset
+   are invalid, then the RRset is not authenticated.
+
+   If the SIG RR is the last RR in a response in the additional
+   information section and has a type covered of zero, it is a
+   transaction signature of the response and the query that produced the
+   response.  It MAY be optionally checked and the message rejected if
+   the checks fail.  But even if the checks succeed, such a transaction
+   authentication SIG does NOT directly authenticate any RRs in the
+   message.  Only a proper SIG RR signed by the zone or a key tracing
+   its authority to the zone or to static resolver configuration can
+   directly authenticate RRs, depending on resolver policy (see Section
+   6).  If a resolver does not implement transaction and/or request
+   SIGs, it MUST ignore them without error.
+
+   If all checks indicate that the SIG RR is valid then RRs verified by
+   it should be considered authenticated.
+
+4.4 Signature Lifetime, Expiration, TTLs, and Validity
+
+   Security aware servers MUST NOT consider SIG RRs to authenticate
+   anything before their signature inception or after its expiration
+   time (see also Section 6).  Security aware servers MUST NOT consider
+   any RR to be authenticated after all its signatures have expired.
+   When a secure server caches authenticated data, if the TTL would
+   expire at a time further in the future than the authentication
+   expiration time, the server SHOULD trim the TTL in the cache entry
+   not to extent beyond the authentication expiration time.  Within
+   these constraints, servers should continue to follow DNS TTL aging.
+   Thus authoritative servers should continue to follow the zone refresh
+   and expire parameters and a non-authoritative server should count
+   down the TTL and discard RRs when the TTL is zero (even for a SIG
+   that has not yet reached its authentication expiration time).  In
+   addition, when RRs are transmitted in a query response, the TTL
+
+
+
+
+Eastlake                    Standards Track                    [Page 23]
+
+RFC 2535                DNS Security Extensions               March 1999
+
+
+   should be trimmed so that current time plus the TTL does not extend
+   beyond the authentication expiration time.  Thus, in general, the TTL
+   on a transmitted RR would be
+
+      min(authExpTim,max(zoneMinTTL,min(originalTTL,currentTTL)))
+
+   When signatures are generated, signature expiration times should be
+   set far enough in the future that it is quite certain that new
+   signatures can be generated before the old ones expire.  However,
+   setting expiration too far into the future could mean a long time to
+   flush any bad data or signatures that may have been generated.
+
+   It is recommended that signature lifetime be a small multiple of the
+   TTL (ie, 4 to 16 times the TTL) but not less than a reasonable
+   maximum re-signing interval and not less than the zone expiry time.
+
+5. Non-existent Names and Types
+
+   The SIG RR mechanism described in Section 4 above provides strong
+   authentication of RRs that exist in a zone.  But it is not clear
+   above how to verifiably deny the existence of a name in a zone or a
+   type for an existent name.
+
+   The nonexistence of a name in a zone is indicated by the NXT ("next")
+   RR for a name interval containing the nonexistent name. An NXT RR or
+   RRs and its or their SIG(s) are returned in the authority section,
+   along with the error, if the server is security aware.  The same is
+   true for a non-existent type under an existing name except that there
+   is no error indication other than an empty answer section
+   accompanying the NXT(s). This is a change in the existing standard
+   [RFCs 1034/1035] which contemplates only NS and SOA RRs in the
+   authority section. NXT RRs will also be returned if an explicit query
+   is made for the NXT type.
+
+   The existence of a complete set of NXT records in a zone means that
+   any query for any name and any type to a security aware server
+   serving the zone will result in an reply containing at least one
+   signed RR unless it is a query for delegation point NS or glue A or
+   AAAA RRs.
+
+5.1 The NXT Resource Record
+
+   The NXT resource record is used to securely indicate that RRs with an
+   owner name in a certain name interval do not exist in a zone and to
+   indicate what RR types are present for an existing name.
+
+
+
+
+
+
+Eastlake                    Standards Track                    [Page 24]
+
+RFC 2535                DNS Security Extensions               March 1999
+
+
+   The owner name of the NXT RR is an existing name in the zone.  It's
+   RDATA is a "next" name and a type bit map. Thus the NXT RRs in a zone
+   create a chain of all of the literal owner names in that zone,
+   including unexpanded wildcards but omitting the owner name of glue
+   address records unless they would otherwise be included. This implies
+   a canonical ordering of all domain names in a zone as described in
+   Section 8. The presence of the NXT RR means that no name between its
+   owner name and the name in its RDATA area exists and that no other
+   types exist under its owner name.
+
+   There is a potential problem with the last NXT in a zone as it wants
+   to have an owner name which is the last existing name in canonical
+   order, which is easy, but it is not obvious what name to put in its
+   RDATA to indicate the entire remainder of the name space.  This is
+   handled by treating the name space as circular and putting the zone
+   name in the RDATA of the last NXT in a zone.
+
+   The NXT RRs for a zone SHOULD be automatically calculated and added
+   to the zone when SIGs are added.  The NXT RR's TTL SHOULD NOT exceed
+   the zone minimum TTL.
+
+   The type number for the NXT RR is 30.
+
+   NXT RRs are only signed by zone level keys.
+
+5.2 NXT RDATA Format
+
+   The RDATA for an NXT RR consists simply of a domain name followed by
+   a bit map, as shown below.
+
+                        1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                  next domain name                             /
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                    type bit map                               /
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   The NXT RR type bit map format currently defined is one bit per RR
+   type present for the owner name.  A one bit indicates that at least
+   one RR of that type is present for the owner name.  A zero indicates
+   that no such RR is present.  All bits not specified because they are
+   beyond the end of the bit map are assumed to be zero.  Note that bit
+   30, for NXT, will always be on so the minimum bit map length is
+   actually four octets. Trailing zero octets are prohibited in this
+   format.  The first bit represents RR type zero (an illegal type which
+   can not be present) and so will be zero in this format.  This format
+   is not used if there exists an RR with a type number greater than
+
+
+
+Eastlake                    Standards Track                    [Page 25]
+
+RFC 2535                DNS Security Extensions               March 1999
+
+
+   127.  If the zero bit of the type bit map is a one, it indicates that
+   a different format is being used which will always be the case if a
+   type number greater than 127 is present.
+
+   The domain name may be compressed with standard DNS name compression
+   when being transmitted over the network.  The size of the bit map can
+   be inferred from the RDLENGTH and the length of the next domain name.
+
+5.3 Additional Complexity Due to Wildcards
+
+   Proving that a non-existent name response is correct or that a
+   wildcard expansion response is correct makes things a little more
+   complex.
+
+   In particular, when a non-existent name response is returned, an NXT
+   must be returned showing that the exact name queried did not exist
+   and, in general, one or more additional NXT's need to be returned to
+   also prove that there wasn't a wildcard whose expansion should have
+   been returned. (There is no need to return multiple copies of the
+   same NXT.) These NXTs, if any, are returned in the authority section
+   of the response.
+
+   Furthermore, if a wildcard expansion is returned in a response, in
+   general one or more NXTs needs to also be returned in the authority
+   section to prove that no more specific name (including possibly more
+   specific wildcards in the zone) existed on which the response should
+   have been based.
+
+5.4 Example
+
+   Assume zone foo.nil has entries for
+
+          big.foo.nil,
+          medium.foo.nil.
+          small.foo.nil.
+          tiny.foo.nil.
+
+   Then a query to a security aware server for huge.foo.nil would
+   produce an error reply with an RCODE of NXDOMAIN and the authority
+   section data including something like the following:
+
+
+
+
+
+
+
+
+
+
+
+Eastlake                    Standards Track                    [Page 26]
+
+RFC 2535                DNS Security Extensions               March 1999
+
+
+   foo.nil.    NXT big.foo.nil NS KEY SOA NXT ;prove no *.foo.nil
+   foo.nil.    SIG NXT 1 2 ( ;type-cov=NXT, alg=1, labels=2
+                    19970102030405 ;signature expiration
+                    19961211100908 ;signature inception
+                    2143           ;key identifier
+                    foo.nil.       ;signer
+   AIYADP8d3zYNyQwW2EM4wXVFdslEJcUx/fxkfBeH1El4ixPFhpfHFElxbvKoWmvjDTCm
+   fiYy2X+8XpFjwICHc398kzWsTMKlxovpz2FnCTM= ;signature (640 bits)
+                          )
+   big.foo.nil. NXT medium.foo.nil. A MX SIG NXT ;prove no huge.foo.nil
+   big.foo.nil. SIG NXT 1 3 ( ;type-cov=NXT, alg=1, labels=3
+                    19970102030405 ;signature expiration
+                    19961211100908 ;signature inception
+                    2143           ;key identifier
+                    foo.nil.       ;signer
+    MxFcby9k/yvedMfQgKzhH5er0Mu/vILz45IkskceFGgiWCn/GxHhai6VAuHAoNUz4YoU
+    1tVfSCSqQYn6//11U6Nld80jEeC8aTrO+KKmCaY= ;signature (640 bits)
+                             )
+   Note that this response implies that big.foo.nil is an existing name
+   in the zone and thus has other RR types associated with it than NXT.
+   However, only the NXT (and its SIG) RR appear in the response to this
+   query for huge.foo.nil, which is a non-existent name.
+
+5.5 Special Considerations at Delegation Points
+
+   A name (other than root) which is the head of a zone also appears as
+   the leaf in a superzone.  If both are secure, there will always be
+   two different NXT RRs with the same name.  They can be easily
+   distinguished by their signers, the next domain name fields, the
+   presence of the SOA type bit, etc.  Security aware servers should
+   return the correct NXT automatically when required to authenticate
+   the non-existence of a name and both NXTs, if available, on explicit
+   query for type NXT.
+
+   Non-security aware servers will never automatically return an NXT and
+   some old implementations may only return the NXT from the subzone on
+   explicit queries.
+
+5.6 Zone Transfers
+
+   The subsections below describe how full and incremental zone
+   transfers are secured.
+
+   SIG RRs secure all authoritative RRs transferred for both full and
+   incremental [RFC 1995] zone transfers.  NXT RRs are an essential
+   element in secure zone transfers and assure that every authoritative
+   name and type will be present; however, if there are multiple SIGs
+   with the same name and type covered, a subset of the SIGs could be
+
+
+
+Eastlake                    Standards Track                    [Page 27]
+
+RFC 2535                DNS Security Extensions               March 1999
+
+
+   sent as long as at least one is present and, in the case of unsigned
+   delegation point NS or glue A or AAAA RRs a subset of these RRs or
+   simply a modified set could be sent as long as at least one of each
+   type is included.
+
+   When an incremental or full zone transfer request is received with
+   the same or newer version number than that of the server's copy of
+   the zone, it is replied to with just the SOA RR of the server's
+   current version and the SIG RRset verifying that SOA RR.
+
+   The complete NXT chains specified in this document enable a resolver
+   to obtain, by successive queries chaining through NXTs, all of the
+   names in a zone even if zone transfers are prohibited.  Different
+   format NXTs may be specified in the future to avoid this.
+
+5.6.1 Full Zone Transfers
+
+   To provide server authentication that a complete transfer has
+   occurred, transaction authentication SHOULD be used on full zone
+   transfers.  This provides strong server based protection for the
+   entire zone in transit.
+
+5.6.2 Incremental Zone Transfers
+
+   Individual RRs in an incremental (IXFR) transfer [RFC 1995] can be
+   verified in the same way as for a full zone transfer and the
+   integrity of the NXT name chain and correctness of the NXT type bits
+   for the zone after the incremental RR deletes and adds can check each
+   disjoint area of the zone updated.  But the completeness of an
+   incremental transfer can not be confirmed because usually neither the
+   deleted RR section nor the added RR section has a compete zone NXT
+   chain.  As a result, a server which securely supports IXFR must
+   handle IXFR SIG RRs for each incremental transfer set that it
+   maintains.
+
+   The IXFR SIG is calculated over the incremental zone update
+   collection of RRs in the order in which it is transmitted: old SOA,
+   then deleted RRs, then new SOA and added RRs.  Within each section,
+   RRs must be ordered as specified in Section 8.  If condensation of
+   adjacent incremental update sets is done by the zone owner, the
+   original IXFR SIG for each set included in the condensation must be
+   discarded and a new on IXFR SIG calculated to cover the resulting
+   condensed set.
+
+   The IXFR SIG really belongs to the zone as a whole, not to the zone
+   name.  Although it SHOULD be correct for the zone name, the labels
+   field of an IXFR SIG is otherwise meaningless.  The IXFR SIG is only
+   sent as part of an incremental zone transfer.  After validation of
+
+
+
+Eastlake                    Standards Track                    [Page 28]
+
+RFC 2535                DNS Security Extensions               March 1999
+
+
+   the IXFR SIG, the transferred RRs MAY be considered valid without
+   verification of the internal SIGs if such trust in the server
+   conforms to local policy.
+
+6. How to Resolve Securely and the AD and CD Bits
+
+   Retrieving or resolving secure data from the Domain Name System (DNS)
+   involves starting with one or more trusted public keys that have been
+   staticly configured at the resolver.  With starting trusted keys, a
+   resolver willing to perform cryptography can progress securely
+   through the secure DNS structure to the zone of interest as described
+   in Section 6.3. Such trusted public keys would normally be configured
+   in a manner similar to that described in Section 6.2.  However, as a
+   practical matter, a security aware resolver would still gain some
+   confidence in the results it returns even if it was not configured
+   with any keys but trusted what it got from a local well known server
+   as if it were staticly configured.
+
+   Data stored at a security aware server needs to be internally
+   categorized as Authenticated, Pending, or Insecure. There is also a
+   fourth transient state of Bad which indicates that all SIG checks
+   have explicitly failed on the data. Such Bad data is not retained at
+   a security aware server. Authenticated means that the data has a
+   valid SIG under a KEY traceable via a chain of zero or more SIG and
+   KEY RRs allowed by the resolvers policies to a KEY staticly
+   configured at the resolver. Pending data has no authenticated SIGs
+   and at least one additional SIG the resolver is still trying to
+   authenticate.  Insecure data is data which it is known can never be
+   either Authenticated or found Bad in the zone where it was found
+   because it is in or has been reached via a unsecured zone or because
+   it is unsigned glue address or delegation point NS data. Behavior in
+   terms of control of and flagging based on such data labels is
+   described in Section 6.1.
+
+   The proper validation of signatures requires a reasonably secure
+   shared opinion of the absolute time between resolvers and servers as
+   described in Section 6.4.
+
+6.1 The AD and CD Header Bits
+
+   Two previously unused bits are allocated out of the DNS
+   query/response format header. The AD (authentic data) bit indicates
+   in a response that all the data included in the answer and authority
+   portion of the response has been authenticated by the server
+   according to the policies of that server. The CD (checking disabled)
+   bit indicates in a query that Pending (non-authenticated) data is
+   acceptable to the resolver sending the query.
+
+
+
+
+Eastlake                    Standards Track                    [Page 29]
+
+RFC 2535                DNS Security Extensions               March 1999
+
+
+   These bits are allocated from the previously must-be-zero Z field as
+   follows:
+
+                                           1  1  1  1  1  1
+             0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
+            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+            |                      ID                       |
+            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+            |QR|   Opcode  |AA|TC|RD|RA| Z|AD|CD|   RCODE   |
+            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+            |                    QDCOUNT                    |
+            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+            |                    ANCOUNT                    |
+            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+            |                    NSCOUNT                    |
+            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+            |                    ARCOUNT                    |
+            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+   These bits are zero in old servers and resolvers.  Thus the responses
+   of old servers are not flagged as authenticated to security aware
+   resolvers and queries from non-security aware resolvers do not assert
+   the checking disabled bit and thus will be answered by security aware
+   servers only with Authenticated or Insecure data. Security aware
+   resolvers MUST NOT trust the AD bit unless they trust the server they
+   are talking to and either have a secure path to it or use DNS
+   transaction security.
+
+   Any security aware resolver willing to do cryptography SHOULD assert
+   the CD bit on all queries to permit it to impose its own policies and
+   to reduce DNS latency time by allowing security aware servers to
+   answer with Pending data.
+
+   Security aware servers MUST NOT return Bad data.  For non-security
+   aware resolvers or security aware resolvers requesting service by
+   having the CD bit clear, security aware servers MUST return only
+   Authenticated or Insecure data in the answer and authority sections
+   with the AD bit set in the response. Security aware servers SHOULD
+   return Pending data, with the AD bit clear in the response, to
+   security aware resolvers requesting this service by asserting the CD
+   bit in their request.  The AD bit MUST NOT be set on a response
+   unless all of the RRs in the answer and authority sections of the
+   response are either Authenticated or Insecure.  The AD bit does not
+   cover the additional information section.
+
+
+
+
+
+
+
+Eastlake                    Standards Track                    [Page 30]
+
+RFC 2535                DNS Security Extensions               March 1999
+
+
+6.2 Staticly Configured Keys
+
+   The public key to authenticate a zone SHOULD be defined in local
+   configuration files before that zone is loaded at the primary server
+   so the zone can be authenticated.
+
+   While it might seem logical for everyone to start with a public key
+   associated with the root zone and staticly configure this in every
+   resolver, this has problems.  The logistics of updating every DNS
+   resolver in the world should this key ever change would be severe.
+   Furthermore, many organizations will explicitly wish their "interior"
+   DNS implementations to completely trust only their own DNS servers.
+   Interior resolvers of such organizations can then go through the
+   organization's zone servers to access data outside the organization's
+   domain and need not be configured with keys above the organization's
+   DNS apex.
+
+   Host resolvers that are not part of a larger organization may be
+   configured with a key for the domain of their local ISP whose
+   recursive secure DNS caching server they use.
+
+6.3 Chaining Through The DNS
+
+   Starting with one or more trusted keys for any zone, it should be
+   possible to retrieve signed keys for that zone's subzones which have
+   a key. A secure sub-zone is indicated by a KEY RR with non-null key
+   information appearing with the NS RRs in the sub-zone and which may
+   also be present in the parent.  These make it possible to descend
+   within the tree of zones.
+
+6.3.1 Chaining Through KEYs
+
+   In general, some RRset that you wish to validate in the secure DNS
+   will be signed by one or more SIG RRs.  Each of these SIG RRs has a
+   signer under whose name is stored the public KEY to use in
+   authenticating the SIG.  Each of those KEYs will, generally, also be
+   signed with a SIG.  And those SIGs will have signer names also
+   referring to KEYs.  And so on. As a result, authentication leads to
+   chains of alternating SIG and KEY RRs with the first SIG signing the
+   original data whose authenticity is to be shown and the final KEY
+   being some trusted key staticly configured at the resolver performing
+   the authentication.
+
+   In testing such a chain, the validity periods of the SIGs encountered
+   must be intersected to determine the validity period of the
+   authentication of the data, a purely algorithmic process. In
+   addition, the validation of each SIG over the data with reference to
+   a KEY must meet the objective cryptographic test implied by the
+
+
+
+Eastlake                    Standards Track                    [Page 31]
+
+RFC 2535                DNS Security Extensions               March 1999
+
+
+   cryptographic algorithm used (although even here the resolver may
+   have policies as to trusted algorithms and key lengths).  Finally,
+   the judgement that a SIG with a particular signer name can
+   authenticate data (possibly a KEY RRset) with a particular owner
+   name, is primarily a policy question.  Ultimately, this is a policy
+   local to the resolver and any clients that depend on that resolver's
+   decisions.  It is, however, recommended, that the policy below be
+   adopted:
+
+        Let A < B mean that A is a shorter domain name than B formed by
+        dropping one or more whole labels from the left end of B, i.e.,
+        A is a direct or indirect superdomain of B.  Let A = B mean that
+        A and B are the same domain name (i.e., are identical after
+        letter case canonicalization).  Let A > B mean that A is a
+        longer domain name than B formed by adding one or more whole
+        labels on the left end of B, i.e., A is a direct or indirect
+        subdomain of B
+
+        Let Static be the owner names of the set of staticly configured
+        trusted keys at a resolver.
+
+        Then Signer is a valid signer name for a SIG authenticating an
+        RRset (possibly a KEY RRset) with owner name Owner at the
+        resolver if any of the following three rules apply:
+
+        (1) Owner > or = Signer (except that if Signer is root, Owner
+        must be root or a top level domain name).  That is, Owner is the
+        same as or a subdomain of Signer.
+
+        (2) ( Owner < Signer ) and ( Signer > or = some Static ).  That
+        is, Owner is a superdomain of Signer and Signer is staticly
+        configured or a subdomain of a staticly configured key.
+
+        (3) Signer = some Static.  That is, the signer is exactly some
+        staticly configured key.
+
+   Rule 1 is the rule for descending the DNS tree and includes a special
+   prohibition on the root zone key due to the restriction that the root
+   zone be only one label deep.  This is the most fundamental rule.
+
+   Rule 2 is the rule for ascending the DNS tree from one or more
+   staticly configured keys.  Rule 2 has no effect if only root zone
+   keys are staticly configured.
+
+   Rule 3 is a rule permitting direct cross certification.  Rule 3 has
+   no effect if only root zone keys are staticly configured.
+
+
+
+
+
+Eastlake                    Standards Track                    [Page 32]
+
+RFC 2535                DNS Security Extensions               March 1999
+
+
+   Great care should be taken that the consequences have been fully
+   considered before making any local policy adjustments to these rules
+   (other than dispensing with rules 2 and 3 if only root zone keys are
+   staticly configured).
+
+6.3.2 Conflicting Data
+
+   It is possible that there will be multiple SIG-KEY chains that appear
+   to authenticate conflicting RRset answers to the same query.  A
+   resolver should choose only the most reliable answer to return and
+   discard other data.  This choice of most reliable is a matter of
+   local policy which could take into account differing trust in
+   algorithms, key sizes, staticly configured keys, zones traversed,
+   etc.  The technique given below is recommended for taking into
+   account SIG-KEY chain length.
+
+   A resolver should keep track of the number of successive secure zones
+   traversed from a staticly configured key starting point to any secure
+   zone it can reach.  In general, the lower such a distance number is,
+   the greater the confidence in the data.  Staticly configured data
+   should be given a distance number of zero.  If a query encounters
+   different Authenticated data for the same query with different
+   distance values, that with a larger value should be ignored unless
+   some other local policy covers the case.
+
+   A security conscious resolver should completely refuse to step from a
+   secure zone into a unsecured zone unless the unsecured zone is
+   certified to be non-secure by the presence of an authenticated KEY RR
+   for the unsecured zone with the no-key type value.  Otherwise the
+   resolver is getting bogus or spoofed data.
+
+   If legitimate unsecured zones are encountered in traversing the DNS
+   tree, then no zone can be trusted as secure that can be reached only
+   via information from such non-secure zones. Since the unsecured zone
+   data could have been spoofed, the "secure" zone reached via it could
+   be counterfeit.  The "distance" to data in such zones or zones
+   reached via such zones could be set to 256 or more as this exceeds
+   the largest possible distance through secure zones in the DNS.
+
+6.4 Secure Time
+
+   Coordinated interpretation of the time fields in SIG RRs requires
+   that reasonably consistent time be available to the hosts
+   implementing the DNS security extensions.
+
+   A variety of time synchronization protocols exist including the
+   Network Time Protocol (NTP [RFC 1305, 2030]).  If such protocols are
+   used, they MUST be used securely so that time can not be spoofed.
+
+
+
+Eastlake                    Standards Track                    [Page 33]
+
+RFC 2535                DNS Security Extensions               March 1999
+
+
+   Otherwise, for example, a host could get its clock turned back and
+   might then believe old SIG RRs, and the data they authenticate, which
+   were valid but are no longer.
+
+7. ASCII Representation of Security RRs
+
+   This section discusses the format for master file and other ASCII
+   presentation of the three DNS security resource records.
+
+   The algorithm field in KEY and SIG RRs can be represented as either
+   an unsigned integer or symbolicly.  The following initial symbols are
+   defined as indicated:
+
+        Value  Symbol
+
+        001    RSAMD5
+        002    DH
+        003    DSA
+        004    ECC
+        252    INDIRECT
+        253    PRIVATEDNS
+        254    PRIVATEOID
+
+7.1 Presentation of KEY RRs
+
+   KEY RRs may appear as single logical lines in a zone data master file
+   [RFC 1033].
+
+   The flag field is represented as an unsigned integer or a sequence of
+   mnemonics as follows separated by instances of the verticle bar ("|")
+   character:
+
+     BIT  Mnemonic  Explanation
+    0-1           key type
+        NOCONF    =1 confidentiality use prohibited
+        NOAUTH    =2 authentication use prohibited
+        NOKEY     =3 no key present
+    2   FLAG2     - reserved
+    3   EXTEND    flags extension
+    4   FLAG4     - reserved
+    5   FLAG5     - reserved
+    6-7           name type
+        USER      =0 (default, may be omitted)
+        ZONE      =1
+        HOST      =2 (host or other end entity)
+        NTYP3     - reserved
+    8   FLAG8     - reserved
+    9   FLAG9     - reserved
+
+
+
+Eastlake                    Standards Track                    [Page 34]
+
+RFC 2535                DNS Security Extensions               March 1999
+
+
+   10   FLAG10    - reserved
+   11   FLAG11    - reserved
+   12-15          signatory field, values 0 to 15
+            can be represented by SIG0, SIG1, ... SIG15
+
+   No flag mnemonic need be present if the bit or field it represents is
+   zero.
+
+   The protocol octet can be represented as either an unsigned integer
+   or symbolicly.  The following initial symbols are defined:
+
+        000    NONE
+        001    TLS
+        002    EMAIL
+        003    DNSSEC
+        004    IPSEC
+        255    ALL
+
+   Note that if the type flags field has the NOKEY value, nothing
+   appears after the algorithm octet.
+
+   The remaining public key portion is represented in base 64 (see
+   Appendix A) and may be divided up into any number of white space
+   separated substrings, down to single base 64 digits, which are
+   concatenated to obtain the full signature.  These substrings can span
+   lines using the standard parenthesis.
+
+   Note that the public key may have internal sub-fields but these do
+   not appear in the master file representation.  For example, with
+   algorithm 1 there is a public exponent size, then a public exponent,
+   and then a modulus.  With algorithm 254, there will be an OID size,
+   an OID, and algorithm dependent information. But in both cases only a
+   single logical base 64 string will appear in the master file.
+
+7.2 Presentation of SIG RRs
+
+   A data SIG RR may be represented as a single logical line in a zone
+   data file [RFC 1033] but there are some special considerations as
+   described below.  (It does not make sense to include a transaction or
+   request authenticating SIG RR in a file as they are a transient
+   authentication that covers data including an ephemeral transaction
+   number and so must be calculated in real time.)
+
+   There is no particular problem with the signer, covered type, and
+   times.  The time fields appears in the form YYYYMMDDHHMMSS where YYYY
+   is the year, the first MM is the month number (01-12), DD is the day
+   of the month (01-31), HH is the hour in 24 hours notation (00-23),
+   the second MM is the minute (00-59), and SS is the second (00-59).
+
+
+
+Eastlake                    Standards Track                    [Page 35]
+
+RFC 2535                DNS Security Extensions               March 1999
+
+
+   The original TTL field appears as an unsigned integer.
+
+   If the original TTL, which applies to the type signed, is the same as
+   the TTL of the SIG RR itself, it may be omitted.  The date field
+   which follows it is larger than the maximum possible TTL so there is
+   no ambiguity.
+
+   The "labels" field appears as an unsigned integer.
+
+   The key tag appears as an unsigned number.
+
+   However, the signature itself can be very long.  It is the last data
+   field and is represented in base 64 (see Appendix A) and may be
+   divided up into any number of white space separated substrings, down
+   to single base 64 digits, which are concatenated to obtain the full
+   signature.  These substrings can be split between lines using the
+   standard parenthesis.
+
+7.3 Presentation of NXT RRs
+
+   NXT RRs do not appear in original unsigned zone master files since
+   they should be derived from the zone as it is being signed.  If a
+   signed file with NXTs added is printed or NXTs are printed by
+   debugging code, they appear as the next domain name followed by the
+   RR type present bits as an unsigned interger or sequence of RR
+   mnemonics.
+
+8. Canonical Form and Order of Resource Records
+
+   This section specifies, for purposes of domain name system (DNS)
+   security, the canonical form of resource records (RRs), their name
+   order, and their overall order.  A canonical name order is necessary
+   to construct the NXT name chain.  A canonical form and ordering
+   within an RRset is necessary in consistently constructing and
+   verifying SIG RRs.  A canonical ordering of types within a name is
+   required in connection with incremental transfer (Section 5.6.2).
+
+8.1 Canonical RR Form
+
+   For purposes of DNS security, the canonical form for an RR is the
+   wire format of the RR with domain names (1) fully expanded (no name
+   compression via pointers), (2) all domain name letters set to lower
+   case, (3) owner name wild cards in master file form (no substitution
+   made for *), and (4) the original TTL substituted for the current
+   TTL.
+
+
+
+
+
+
+Eastlake                    Standards Track                    [Page 36]
+
+RFC 2535                DNS Security Extensions               March 1999
+
+
+8.2 Canonical DNS Name Order
+
+   For purposes of DNS security, the canonical ordering of owner names
+   is to sort individual labels as unsigned left justified octet strings
+   where the absence of a octet sorts before a zero value octet and
+   upper case letters are treated as lower case letters.  Names in a
+   zone are sorted by sorting on the highest level label and then,
+   within those names with the same highest level label by the next
+   lower label, etc. down to leaf node labels.  Within a zone, the zone
+   name itself always exists and all other names are the zone name with
+   some prefix of lower level labels.  Thus the zone name itself always
+   sorts first.
+
+   Example:
+          foo.example
+          a.foo.example
+          yljkjljk.a.foo.example
+          Z.a.foo.example
+          zABC.a.FOO.EXAMPLE
+          z.foo.example
+          *.z.foo.example
+          \200.z.foo.example
+
+8.3 Canonical RR Ordering Within An RRset
+
+   Within any particular owner name and type, RRs are sorted by RDATA as
+   a left justified unsigned octet sequence where the absence of an
+   octet sorts before the zero octet.
+
+8.4 Canonical Ordering of RR Types
+
+   When RRs of the same name but different types must be ordered, they
+   are ordered by type, considering the type to be an unsigned integer,
+   except that SIG RRs are placed immediately after the type they cover.
+   Thus, for example, an A record would be put before an MX record
+   because A is type 1 and MX is type 15 but if both were signed, the
+   order would be A < SIG(A) < MX < SIG(MX).
+
+9. Conformance
+
+   Levels of server and resolver conformance are defined below.
+
+9.1 Server Conformance
+
+   Two levels of server conformance for DNS security are defined as
+   follows:
+
+
+
+
+
+Eastlake                    Standards Track                    [Page 37]
+
+RFC 2535                DNS Security Extensions               March 1999
+
+
+   BASIC:  Basic server compliance is the ability to store and retrieve
+   (including zone transfer) SIG, KEY, and NXT RRs.  Any secondary or
+   caching server for a secure zone MUST have at least basic compliance
+   and even then some things, such as secure CNAMEs, will not work
+   without full compliance.
+
+   FULL:  Full server compliance adds the following to basic compliance:
+   (1) ability to read SIG, KEY, and NXT RRs in zone files and (2)
+   ability, given a zone file and private key, to add appropriate SIG
+   and NXT RRs, possibly via a separate application, (3) proper
+   automatic inclusion of SIG, KEY, and NXT RRs in responses, (4)
+   suppression of CNAME following on retrieval of the security type RRs,
+   (5) recognize the CD query header bit and set the AD query header
+   bit, as appropriate, and (6) proper handling of the two NXT RRs at
+   delegation points.  Primary servers for secure zones MUST be fully
+   compliant and for complete secure operation, all secondary, caching,
+   and other servers handling the zone SHOULD be fully compliant as
+   well.
+
+9.2 Resolver Conformance
+
+   Two levels of resolver compliance (including the resolver portion of
+   a server) are defined for DNS Security:
+
+   BASIC: A basic compliance resolver can handle SIG, KEY, and NXT RRs
+   when they are explicitly requested.
+
+   FULL: A fully compliant resolver (1) understands KEY, SIG, and NXT
+   RRs including verification of SIGs at least for the mandatory
+   algorithm, (2) maintains appropriate information in its local caches
+   and database to indicate which RRs have been authenticated and to
+   what extent they have been authenticated, (3) performs additional
+   queries as necessary to attempt to obtain KEY, SIG, or NXT RRs when
+   needed, (4) normally sets the CD query header bit on its queries.
+
+10. Security Considerations
+
+   This document specifies extensions to the Domain Name System (DNS)
+   protocol to provide data integrity and data origin authentication,
+   public key distribution, and optional transaction and request
+   security.
+
+   It should be noted that, at most, these extensions guarantee the
+   validity of resource records, including KEY resource records,
+   retrieved from the DNS.  They do not magically solve other security
+   problems.  For example, using secure DNS you can have high confidence
+   in the IP address you retrieve for a host name; however, this does
+   not stop someone for substituting an unauthorized host at that
+
+
+
+Eastlake                    Standards Track                    [Page 38]
+
+RFC 2535                DNS Security Extensions               March 1999
+
+
+   address or capturing packets sent to that address and falsely
+   responding with packets apparently from that address.  Any reasonably
+   complete security system will require the protection of many
+   additional facets of the Internet beyond DNS.
+
+   The implementation of NXT RRs as described herein enables a resolver
+   to determine all the names in a zone even if zone transfers are
+   prohibited (section 5.6).  This is an active area of work and may
+   change.
+
+   A number of precautions in DNS implementation have evolved over the
+   years to harden the insecure DNS against spoofing.  These precautions
+   should not be abandoned but should be considered to provide
+   additional protection in case of key compromise in secure DNS.
+
+11. IANA Considerations
+
+   KEY RR flag bits 2 and 8-11 and all flag extension field bits can be
+   assigned by IETF consensus as defined in RFC 2434.  The remaining
+   values of the NAMTYP flag field and flag bits 4 and 5 (which could
+   conceivably become an extension of the NAMTYP field) can only be
+   assigned by an IETF Standards Action [RFC 2434].
+
+   Algorithm numbers 5 through 251 are available for assignment should
+   sufficient reason arise.  However, the designation of a new algorithm
+   could have a major impact on interoperability and requires an IETF
+   Standards Action [RFC 2434].  The existence of the private algorithm
+   types 253 and 254 should satify most needs for private or proprietary
+   algorithms.
+
+   Additional values of the Protocol Octet (5-254) can be assigned by
+   IETF Consensus [RFC 2434].
+
+   The meaning of the first bit of the NXT RR "type bit map" being a one
+   can only be assigned by a standards action.
+
+References
+
+   [RFC 1033]  Lottor, M., "Domain Administrators Operations Guide", RFC
+               1033, November 1987.
+
+   [RFC 1034]  Mockapetris, P., "Domain Names - Concepts and
+               Facilities", STD 13, RFC 1034, November 1987.
+
+   [RFC 1035]  Mockapetris, P., "Domain Names - Implementation and
+               Specifications", STD 13, RFC 1035, November 1987.
+
+
+
+
+
+Eastlake                    Standards Track                    [Page 39]
+
+RFC 2535                DNS Security Extensions               March 1999
+
+
+   [RFC 1305]  Mills, D., "Network Time Protocol (v3)", RFC 1305, March
+               1992.
+
+   [RFC 1530]  Malamud, C. and M. Rose, "Principles of Operation for the
+               TPC.INT Subdomain: General Principles and Policy", RFC
+               1530, October 1993.
+
+   [RFC 2401]  Kent, S. and R. Atkinson, "Security Architecture for the
+               Internet Protocol", RFC 2401, November 1998.
+
+   [RFC 1982]  Elz, R. and R. Bush, "Serial Number Arithmetic", RFC
+               1982, September 1996.
+
+   [RFC 1995]  Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,
+               August 1996.
+
+   [RFC 2030]  Mills, D., "Simple Network Time Protocol (SNTP) Version 4
+               for IPv4, IPv6 and OSI", RFC 2030, October 1996.
+
+   [RFC 2045]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+               Extensions (MIME) Part One: Format of Internet Message
+               Bodies", RFC 2045, November 1996.
+
+   [RFC 2065]  Eastlake, D. and C. Kaufman, "Domain Name System Security
+               Extensions", RFC 2065, January 1997.
+
+   [RFC 2119]  Bradner, S., "Key words for use in RFCs to Indicate
+               Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC 2136]  Vixie, P., Thomson, S., Rekhter, Y. and J. Bound,
+               "Dynamic Updates in the Domain Name System (DNS UPDATE)",
+               RFC 2136, April 1997.
+
+   [RFC 2137]  Eastlake, D., "Secure Domain Name System Dynamic Update",
+               RFC 2137, April 1997.
+
+   [RFC 2181]  Elz, R. and R. Bush, "Clarifications to the DNS
+               Specification", RFC 2181, July 1997.
+
+   [RFC 2434]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
+               IANA Considerations Section in RFCs", BCP 26, RFC 2434,
+               October 1998.
+
+   [RFC 2537]  Eastlake, D., "RSA/MD5 KEYs and SIGs in the Domain Name
+               System (DNS)", RFC 2537, March 1999.
+
+   [RFC 2539]  Eastlake, D., "Storage of Diffie-Hellman Keys in the
+               Domain Name System (DNS)", RFC 2539, March 1999.
+
+
+
+Eastlake                    Standards Track                    [Page 40]
+
+RFC 2535                DNS Security Extensions               March 1999
+
+
+   [RFC 2536]  Eastlake, D., "DSA KEYs and SIGs in the Domain Name
+               System (DNS)", RFC 2536, March 1999.
+
+   [RFC 2538]  Eastlake, D. and O. Gudmundsson, "Storing Certificates in
+               the Domain Name System", RFC 2538, March 1999.
+
+   [RFC 2541]  Eastlake, D., "DNS Operational Security Considerations",
+               RFC 2541, March 1999.
+
+   [RSA FAQ] - RSADSI Frequently Asked Questions periodic posting.
+
+Author's Address
+
+   Donald E. Eastlake 3rd
+   IBM
+   65 Shindegan Hill Road
+   RR #1
+   Carmel, NY 10512
+
+   Phone:   +1-914-784-7913 (w)
+            +1-914-276-2668 (h)
+   Fax:     +1-914-784-3833 (w-fax)
+   EMail:   dee3@us.ibm.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake                    Standards Track                    [Page 41]
+
+RFC 2535                DNS Security Extensions               March 1999
+
+
+Appendix A: Base 64 Encoding
+
+   The following encoding technique is taken from [RFC 2045] by N.
+   Borenstein and N. Freed.  It is reproduced here in an edited form for
+   convenience.
+
+   A 65-character subset of US-ASCII is used, enabling 6 bits to be
+   represented per printable character. (The extra 65th character, "=",
+   is used to signify a special processing function.)
+
+   The encoding process represents 24-bit groups of input bits as output
+   strings of 4 encoded characters. Proceeding from left to right, a
+   24-bit input group is formed by concatenating 3 8-bit input groups.
+   These 24 bits are then treated as 4 concatenated 6-bit groups, each
+   of which is translated into a single digit in the base 64 alphabet.
+
+   Each 6-bit group is used as an index into an array of 64 printable
+   characters. The character referenced by the index is placed in the
+   output string.
+
+                         Table 1: The Base 64 Alphabet
+
+      Value Encoding  Value Encoding  Value Encoding  Value Encoding
+          0 A            17 R            34 i            51 z
+          1 B            18 S            35 j            52 0
+          2 C            19 T            36 k            53 1
+          3 D            20 U            37 l            54 2
+          4 E            21 V            38 m            55 3
+          5 F            22 W            39 n            56 4
+          6 G            23 X            40 o            57 5
+          7 H            24 Y            41 p            58 6
+          8 I            25 Z            42 q            59 7
+          9 J            26 a            43 r            60 8
+         10 K            27 b            44 s            61 9
+         11 L            28 c            45 t            62 +
+         12 M            29 d            46 u            63 /
+         13 N            30 e            47 v
+         14 O            31 f            48 w         (pad) =
+         15 P            32 g            49 x
+         16 Q            33 h            50 y
+
+   Special processing is performed if fewer than 24 bits are available
+   at the end of the data being encoded.  A full encoding quantum is
+   always completed at the end of a quantity.  When fewer than 24 input
+   bits are available in an input group, zero bits are added (on the
+   right) to form an integral number of 6-bit groups.  Padding at the
+   end of the data is performed using the '=' character.  Since all base
+   64 input is an integral number of octets, only the following cases
+
+
+
+Eastlake                    Standards Track                    [Page 42]
+
+RFC 2535                DNS Security Extensions               March 1999
+
+
+   can arise: (1) the final quantum of encoding input is an integral
+   multiple of 24 bits; here, the final unit of encoded output will be
+   an integral multiple of 4 characters with no "=" padding, (2) the
+   final quantum of encoding input is exactly 8 bits; here, the final
+   unit of encoded output will be two characters followed by two "="
+   padding characters, or (3) the final quantum of encoding input is
+   exactly 16 bits; here, the final unit of encoded output will be three
+   characters followed by one "=" padding character.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake                    Standards Track                    [Page 43]
+
+RFC 2535                DNS Security Extensions               March 1999
+
+
+Appendix B: Changes from RFC 2065
+
+   This section summarizes the most important changes that have been
+   made since RFC 2065.
+
+   1. Most of Section 7 of [RFC 2065] called "Operational
+      Considerations", has been removed and may be made into a separate
+      document [RFC 2541].
+
+   2. The KEY RR has been changed by (2a) eliminating the "experimental"
+      flag as unnecessary, (2b) reserving a flag  bit for flags
+      expansion, (2c) more compactly encoding a number of bit fields in
+      such a way as to leave unchanged bits actually used by the limited
+      code currently deployed, (2d) eliminating the IPSEC and email flag
+      bits which are replaced by values of the protocol field and adding
+      a protocol field value for DNS security itself, (2e) adding
+      material to indicate that zone KEY RRs occur only at delegation
+      points, and (2f) removing the description of the RSA/MD5 algorithm
+      to a separate document [RFC 2537].  Section 3.4 describing the
+      meaning of various combinations of "no-key" and key present KEY
+      RRs has been added and the secure / unsecure status of a zone has
+      been clarified as being per algorithm.
+
+   3. The SIG RR has been changed by (3a) renaming the "time signed"
+      field to be the "signature inception" field, (3b) clarifying that
+      signature expiration and inception use serial number ring
+      arithmetic, (3c) changing the definition of the key footprint/tag
+      for algorithms other than 1 and adding Appendix C to specify its
+      calculation.  In addition, the SIG covering type AXFR has been
+      eliminated while one covering IXFR [RFC 1995] has been added (see
+      section 5.6).
+
+   4. Algorithm 3, the DSA algorithm, is now designated as the mandatory
+      to implement algorithm.  Algorithm 1, the RSA/MD5 algorithm, is
+      now a recommended option.  Algorithm 2 and 4 are designated as the
+      Diffie-Hellman key and elliptic cryptography algorithms
+      respectively, all to be defined in separate documents. Algorithm
+      code point 252 is designated to indicate "indirect" keys, to be
+      defined in a separate document, where the actual key is elsewhere.
+      Both the KEY and SIG RR definitions have been simplified by
+      eliminating the "null" algorithm 253 as defined in [RFC 2065].
+      That algorithm had been included because at the time it was
+      thought it might be useful in DNS dynamic update [RFC 2136]. It
+      was in fact not so used and it is dropped to simplify DNS
+      security.  Howver, that algorithm number has been re-used to
+      indicate private algorithms where a domain name specifies the
+      algorithm.
+
+
+
+
+Eastlake                    Standards Track                    [Page 44]
+
+RFC 2535                DNS Security Extensions               March 1999
+
+
+   5. The NXT RR has been changed so that (5a) the NXT RRs in a zone
+      cover all names, including wildcards as literal names without
+      expansion, except for glue address records whose names would not
+      otherwise appear, (5b) all NXT bit map areas whose first octet has
+      bit zero set have been reserved for future definition, (5c) the
+      number of and circumstances under which an NXT must be returned in
+      connection with wildcard names has been extended, and (5d) in
+      connection with the bit map, references to the WKS RR have been
+      removed and verticle bars ("|") have been added between the RR
+      type mnemonics in the ASCII representation.
+
+   6. Information on the canonical form and ordering of RRs has been
+      moved into a separate Section 8.
+
+   7. A subsection covering incremental and full zone transfer has been
+      added in Section 5.
+
+   8. Concerning DNS chaining: Further specification and policy
+      recommendations on secure resolution have been added, primarily in
+      Section 6.3.1.  It is now clearly stated that authenticated data
+      has a validity period of the intersection of the validity periods
+      of the SIG RRs in its authentication chain.  The requirement to
+      staticly configure a superzone's key signed by a zone in all of
+      the zone's authoritative servers has been removed.  The
+      recommendation to continue DNS security checks in a secure island
+      of DNS data that is separated from other parts of the DNS tree by
+      insecure zones and does not contain a zone for which a key has
+      been staticly configured was dropped.
+
+   9. It was clarified that the presence of the AD bit in a response
+      does not apply to the additional information section or to glue
+      address or delegation point NS RRs.  The AD bit only indicates
+      that the answer and authority sections of the response are
+      authoritative.
+
+   10. It is now required that KEY RRs and NXT RRs be signed only with
+       zone-level keys.
+
+   11.  Add IANA Considerations section and references to RFC 2434.
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake                    Standards Track                    [Page 45]
+
+RFC 2535                DNS Security Extensions               March 1999
+
+
+Appendix C: Key Tag Calculation
+
+   The key tag field in the SIG RR is just a means of more efficiently
+   selecting the correct KEY RR to use when there is more than one KEY
+   RR candidate available, for example, in verifying a signature.  It is
+   possible for more than one candidate key to have the same tag, in
+   which case each must be tried until one works or all fail.  The
+   following reference implementation of how to calculate the Key Tag,
+   for all algorithms other than algorithm 1, is in ANSI C.  It is coded
+   for clarity, not efficiency.  (See section 4.1.6 for how to determine
+   the Key Tag of an algorithm 1 key.)
+
+   /* assumes int is at least 16 bits
+      first byte of the key tag is the most significant byte of return
+      value
+      second byte of the key tag is the least significant byte of
+      return value
+      */
+
+   int keytag (
+
+           unsigned char key[],  /* the RDATA part of the KEY RR */
+           unsigned int keysize, /* the RDLENGTH */
+           )
+   {
+   long int    ac;    /* assumed to be 32 bits or larger */
+
+   for ( ac = 0, i = 0; i < keysize; ++i )
+       ac += (i&1) ? key[i] : key[i]<<8;
+   ac += (ac>>16) & 0xFFFF;
+   return ac & 0xFFFF;
+   }
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake                    Standards Track                    [Page 46]
+
+RFC 2535                DNS Security Extensions               March 1999
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (1999).  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 Standards process must be
+   followed, or as required to translate it into 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake                    Standards Track                    [Page 47]
+
diff --git a/doc/rfc/rfc2536.txt b/doc/rfc/rfc2536.txt
new file mode 100644
index 0000000..88be242
--- /dev/null
+++ b/doc/rfc/rfc2536.txt
@@ -0,0 +1,339 @@
+
+
+
+
+
+
+Network Working Group                                        D. EastLake
+Request for Comments: 2536                                           IBM
+Category: Standards Track                                     March 1999
+
+
+           DSA KEYs and SIGs in the Domain Name System (DNS)
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (1999).  All Rights Reserved.
+
+Abstract
+
+   A standard method for storing US Government Digital Signature
+   Algorithm keys and signatures in the Domain Name System is described
+   which utilizes DNS KEY and SIG resource records.
+
+Table of Contents
+
+   Abstract...................................................1
+   1. Introduction............................................1
+   2. DSA KEY Resource Records................................2
+   3. DSA SIG Resource Records................................3
+   4. Performance Considerations..............................3
+   5. Security Considerations.................................4
+   6. IANA Considerations.....................................4
+   References.................................................5
+   Author's Address...........................................5
+   Full Copyright Statement...................................6
+
+1. Introduction
+
+   The Domain Name System (DNS) is the global hierarchical replicated
+   distributed database system for Internet addressing, mail proxy, and
+   other information. The DNS has been extended to include digital
+   signatures and cryptographic keys as described in [RFC 2535].  Thus
+   the DNS can now be secured and can be used for secure key
+   distribution.
+
+
+
+
+
+Eastlake                    Standards Track                     [Page 1]
+
+RFC 2536                     DSA in the DNS                   March 1999
+
+
+   This document describes how to store US Government Digital Signature
+   Algorithm (DSA) keys and signatures in the DNS.  Familiarity with the
+   US Digital Signature Algorithm is assumed [Schneier].  Implementation
+   of DSA is mandatory for DNS security.
+
+2. DSA KEY Resource Records
+
+   DSA public keys are stored in the DNS as KEY RRs using algorithm
+   number 3 [RFC 2535].  The structure of the algorithm specific portion
+   of the RDATA part of this RR is as shown below.  These fields, from Q
+   through Y are the "public key" part of the DSA KEY RR.
+
+   The period of key validity is not in the KEY RR but is indicated by
+   the SIG RR(s) which signs and authenticates the KEY RR(s) at that
+   domain name.
+
+           Field     Size
+           -----     ----
+            T         1  octet
+            Q        20  octets
+            P        64 + T*8  octets
+            G        64 + T*8  octets
+            Y        64 + T*8  octets
+
+   As described in [FIPS 186] and [Schneier]: T is a key size parameter
+   chosen such that 0 <= T <= 8.  (The meaning for algorithm 3 if the T
+   octet is greater than 8 is reserved and the remainder of the RDATA
+   portion may have a different format in that case.)  Q is a prime
+   number selected at key generation time such that 2**159 < Q < 2**160
+   so Q is always 20 octets long and, as with all other fields, is
+   stored in "big-endian" network order.  P, G, and Y are calculated as
+   directed by the FIPS 186 key generation algorithm [Schneier].  P is
+   in the range 2**(511+64T) < P < 2**(512+64T) and so is 64 + 8*T
+   octets long.  G and Y are quantities modulus P and so can be up to
+   the same length as P and are allocated fixed size fields with the
+   same number of octets as P.
+
+   During the key generation process, a random number X must be
+   generated such that 1 <= X <= Q-1.  X is the private key and is used
+   in the final step of public key generation where Y is computed as
+
+             Y = G**X mod P
+
+
+
+
+
+
+
+
+
+Eastlake                    Standards Track                     [Page 2]
+
+RFC 2536                     DSA in the DNS                   March 1999
+
+
+3. DSA SIG Resource Records
+
+   The signature portion of the SIG RR RDATA area, when using the US
+   Digital Signature Algorithm, is shown below with fields in the order
+   they occur.  See [RFC 2535] for fields in the SIG RR RDATA which
+   precede the signature itself.
+
+           Field     Size
+           -----     ----
+            T         1 octet
+            R        20 octets
+            S        20 octets
+
+   The data signed is determined as specified in [RFC 2535].  Then the
+   following steps are taken, as specified in [FIPS 186], where Q, P, G,
+   and Y are as specified in the public key [Schneier]:
+
+           hash = SHA-1 ( data )
+
+           Generate a random K such that 0 < K < Q.
+
+           R = ( G**K mod P ) mod Q
+
+           S = ( K**(-1) * (hash + X*R) ) mod Q
+
+   Since Q is 160 bits long, R and S can not be larger than 20 octets,
+   which is the space allocated.
+
+   T is copied from the public key.  It is not logically necessary in
+   the SIG but is present so that values of T > 8 can more conveniently
+   be used as an escape for extended versions of DSA or other algorithms
+   as later specified.
+
+4. Performance Considerations
+
+   General signature generation speeds are roughly the same for RSA [RFC
+   2537] and DSA.  With sufficient pre-computation, signature generation
+   with DSA is faster than RSA.  Key generation is also faster for DSA.
+   However, signature verification is an order of magnitude slower than
+   RSA when the RSA public exponent is chosen to be small as is
+   recommended for KEY RRs used in domain name system (DNS) data
+   authentication.
+
+   Current DNS implementations are optimized for small transfers,
+   typically less than 512 bytes including overhead.  While larger
+   transfers will perform correctly and work is underway to make larger
+   transfers more efficient, it is still advisable at this time to make
+   reasonable efforts to minimize the size of KEY RR sets stored within
+
+
+
+Eastlake                    Standards Track                     [Page 3]
+
+RFC 2536                     DSA in the DNS                   March 1999
+
+
+   the DNS consistent with adequate security.  Keep in mind that in a
+   secure zone, at least one authenticating SIG RR will also be
+   returned.
+
+5. Security Considerations
+
+   Many of the general security consideration in [RFC 2535] apply.  Keys
+   retrieved from the DNS should not be trusted unless (1) they have
+   been securely obtained from a secure resolver or independently
+   verified by the user and (2) this secure resolver and secure
+   obtainment or independent verification conform to security policies
+   acceptable to the user.  As with all cryptographic algorithms,
+   evaluating the necessary strength of the key is essential and
+   dependent on local policy.
+
+   The key size limitation of a maximum of 1024 bits ( T = 8 ) in the
+   current DSA standard may limit the security of DSA.  For particularly
+   critical applications, implementors are encouraged to consider the
+   range of available algorithms and key sizes.
+
+   DSA assumes the ability to frequently generate high quality random
+   numbers.  See [RFC 1750] for guidance.  DSA is designed so that if
+   manipulated rather than random numbers are used, very high bandwidth
+   covert channels are possible.  See [Schneier] and more recent
+   research.  The leakage of an entire DSA private key in only two DSA
+   signatures has been demonstrated.  DSA provides security only if
+   trusted implementations, including trusted random number generation,
+   are used.
+
+6. IANA Considerations
+
+   Allocation of meaning to values of the T parameter that are not
+   defined herein requires an IETF standards actions.  It is intended
+   that values unallocated herein be used to cover future extensions of
+   the DSS standard.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake                    Standards Track                     [Page 4]
+
+RFC 2536                     DSA in the DNS                   March 1999
+
+
+References
+
+   [FIPS 186]   U.S. Federal Information Processing Standard: Digital
+                Signature Standard.
+
+   [RFC 1034]   Mockapetris, P., "Domain Names - Concepts and
+                Facilities", STD 13, RFC 1034, November 1987.
+
+   [RFC 1035]   Mockapetris, P., "Domain Names - Implementation and
+                Specification", STD 13, RFC 1035, November 1987.
+
+   [RFC 1750]   Eastlake, D., Crocker, S. and J. Schiller, "Randomness
+                Recommendations for Security", RFC 1750, December 1994.
+
+   [RFC 2535]   Eastlake, D., "Domain Name System Security Extensions",
+                RFC 2535, March 1999.
+
+   [RFC 2537]   Eastlake, D., "RSA/MD5 KEYs and SIGs in the Domain Name
+                System (DNS)", RFC 2537, March 1999.
+
+   [Schneier]   Schneier, B., "Applied Cryptography Second Edition:
+                protocols, algorithms, and source code in C", 1996.
+
+Author's Address
+
+   Donald E. Eastlake 3rd
+   IBM
+   65 Shindegan Hill Road, RR #1
+   Carmel, NY 10512
+
+   Phone:   +1-914-276-2668(h)
+            +1-914-784-7913(w)
+   Fax:     +1-914-784-3833(w)
+   EMail:   dee3@us.ibm.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake                    Standards Track                     [Page 5]
+
+RFC 2536                     DSA in the DNS                   March 1999
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (1999).  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 Standards process must be
+   followed, or as required to translate it into 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake                    Standards Track                     [Page 6]
+
diff --git a/doc/rfc/rfc2537.txt b/doc/rfc/rfc2537.txt
new file mode 100644
index 0000000..cb75cf5
--- /dev/null
+++ b/doc/rfc/rfc2537.txt
@@ -0,0 +1,339 @@
+
+
+
+
+
+
+Network Working Group                                        D. Eastlake
+Request for Comments: 2537                                           IBM
+Category: Standards Track                                     March 1999
+
+
+         RSA/MD5 KEYs and SIGs in the Domain Name System (DNS)
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (1999).  All Rights Reserved.
+
+Abstract
+
+   A standard method for storing RSA keys and and RSA/MD5 based
+   signatures in the Domain Name System is described which utilizes DNS
+   KEY and SIG resource records.
+
+Table of Contents
+
+   Abstract...................................................1
+   1. Introduction............................................1
+   2. RSA Public KEY Resource Records.........................2
+   3. RSA/MD5 SIG Resource Records............................2
+   4. Performance Considerations..............................3
+   5. Security Considerations.................................4
+   References.................................................4
+   Author's Address...........................................5
+   Full Copyright Statement...................................6
+
+1. Introduction
+
+   The Domain Name System (DNS) is the global hierarchical replicated
+   distributed database system for Internet addressing, mail proxy, and
+   other information. The DNS has been extended to include digital
+   signatures and cryptographic keys as described in [RFC 2535].  Thus
+   the DNS can now be secured and used for secure key distribution.
+
+
+
+
+
+
+
+Eastlake                    Standards Track                     [Page 1]
+
+RFC 2537            RSA/MD5 KEYs and SIGs in the DNS          March 1999
+
+
+   This document describes how to store RSA keys and and RSA/MD5 based
+   signatures in the DNS.  Familiarity with the RSA algorithm is assumed
+   [Schneier].  Implementation of the RSA algorithm in DNS is
+   recommended.
+
+   The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY"
+   in this document are to be interpreted as described in RFC 2119.
+
+2. RSA Public KEY Resource Records
+
+   RSA public keys are stored in the DNS as KEY RRs using algorithm
+   number 1 [RFC 2535].  The structure of the algorithm specific portion
+   of the RDATA part of such RRs is as shown below.
+
+           Field             Size
+           -----             ----
+           exponent length   1 or 3 octets (see text)
+           exponent          as specified by length field
+           modulus           remaining space
+
+   For interoperability, the exponent and modulus are each currently
+   limited to 4096 bits in length.  The public key exponent is a
+   variable length unsigned integer.  Its length in octets is
+   represented as one octet if it is in the range of 1 to 255 and by a
+   zero octet followed by a two octet unsigned length if it is longer
+   than 255 bytes.  The public key modulus field is a multiprecision
+   unsigned integer.  The length of the modulus can be determined from
+   the RDLENGTH and the preceding RDATA fields including the exponent.
+   Leading zero octets are prohibited in the exponent and modulus.
+
+3. RSA/MD5 SIG Resource Records
+
+   The signature portion of the SIG RR RDATA area, when using the
+   RSA/MD5 algorithm, is calculated as shown below.  The data signed is
+   determined as specified in [RFC 2535].  See [RFC 2535] for fields in
+   the SIG RR RDATA which precede the signature itself.
+
+
+     hash = MD5 ( data )
+
+     signature = ( 00 | 01 | FF* | 00 | prefix | hash ) ** e (mod n)
+
+
+
+
+
+
+
+
+
+
+Eastlake                    Standards Track                     [Page 2]
+
+RFC 2537            RSA/MD5 KEYs and SIGs in the DNS          March 1999
+
+
+   where MD5 is the message digest algorithm documented in [RFC 1321],
+   "|" is concatenation, "e" is the private key exponent of the signer,
+   and "n" is the modulus of the signer's public key.  01, FF, and 00
+   are fixed octets of the corresponding hexadecimal value. "prefix" is
+   the ASN.1 BER MD5 algorithm designator prefix specified in [RFC
+   2437], that is,
+
+      hex 3020300c06082a864886f70d020505000410 [NETSEC].
+
+   This prefix is included to make it easier to use RSAREF (or similar
+   packages such as EuroRef).  The FF octet MUST be repeated the maximum
+   number of times such that the value of the quantity being
+   exponentiated is the same length in octets as the value of n.
+
+   (The above specifications are identical to the corresponding part of
+   Public Key Cryptographic Standard #1 [RFC 2437].)
+
+   The size of n, including most and least significant bits (which will
+   be 1) MUST be not less than 512 bits and not more than 4096 bits.  n
+   and e SHOULD be chosen such that the public exponent is small.
+
+   Leading zero bytes are permitted in the RSA/MD5 algorithm signature.
+
+   A public exponent of 3 minimizes the effort needed to verify a
+   signature.  Use of 3 as the public exponent is weak for
+   confidentiality uses since, if the same data can be collected
+   encrypted under three different keys with an exponent of 3 then,
+   using the Chinese Remainder Theorem [NETSEC], the original plain text
+   can be easily recovered.  This weakness is not significant for DNS
+   security because we seek only authentication, not confidentiality.
+
+4. Performance Considerations
+
+   General signature generation speeds are roughly the same for RSA and
+   DSA [RFC 2536].  With sufficient pre-computation, signature
+   generation with DSA is faster than RSA.  Key generation is also
+   faster for DSA.  However, signature verification is an order of
+   magnitude slower with DSA when the RSA public exponent is chosen to
+   be small as is recommended for KEY RRs used in domain name system
+   (DNS) data authentication.
+
+   Current DNS implementations are optimized for small transfers,
+   typically less than 512 bytes including overhead.  While larger
+   transfers will perform correctly and work is underway to make larger
+
+
+
+
+
+
+
+Eastlake                    Standards Track                     [Page 3]
+
+RFC 2537            RSA/MD5 KEYs and SIGs in the DNS          March 1999
+
+
+   transfers more efficient, it is still advisable at this time to make
+   reasonable efforts to minimize the size of KEY RR sets stored within
+   the DNS consistent with adequate security.  Keep in mind that in a
+   secure zone, at least one authenticating SIG RR will also be
+   returned.
+
+5. Security Considerations
+
+   Many of the general security consideration in [RFC 2535] apply.  Keys
+   retrieved from the DNS should not be trusted unless (1) they have
+   been securely obtained from a secure resolver or independently
+   verified by the user and (2) this secure resolver and secure
+   obtainment or independent verification conform to security policies
+   acceptable to the user.  As with all cryptographic algorithms,
+   evaluating the necessary strength of the key is essential and
+   dependent on local policy.
+
+   For interoperability, the RSA key size is limited to 4096 bits.  For
+   particularly critical applications, implementors are encouraged to
+   consider the range of available algorithms and key sizes.
+
+References
+
+   [NETSEC]     Kaufman, C., Perlman, R. and M. Speciner, "Network
+                Security: PRIVATE Communications in a PUBLIC World",
+                Series in Computer Networking and Distributed
+                Communications, 1995.
+
+   [RFC 2437]   Kaliski, B. and J. Staddon, "PKCS #1: RSA Cryptography
+                Specifications Version 2.0", RFC 2437, October 1998.
+
+   [RFC 1034]   Mockapetris, P., "Domain Names - Concepts and
+                Facilities", STD 13, RFC 1034, November 1987.
+
+   [RFC 1035]   Mockapetris, P., "Domain Names - Implementation and
+                Specification", STD 13, RFC 1035, November 1987.
+
+   [RFC 1321]   Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321
+                April 1992.
+
+   [RFC 2535]   Eastlake, D., "Domain Name System Security Extensions",
+                RFC 2535, March 1999.
+
+   [RFC 2536]   EastLake, D., "DSA KEYs and SIGs in the Domain Name
+                System (DNS)", RFC 2536, March 1999.
+
+
+
+
+
+
+Eastlake                    Standards Track                     [Page 4]
+
+RFC 2537            RSA/MD5 KEYs and SIGs in the DNS          March 1999
+
+
+   [Schneier]   Bruce Schneier, "Applied Cryptography Second Edition:
+                protocols, algorithms, and source code in C", 1996, John
+                Wiley and Sons, ISBN 0-471-11709-9.
+
+Author's Address
+
+   Donald E. Eastlake 3rd
+   IBM
+   65 Shindegan Hill Road, RR #1
+   Carmel, NY 10512
+
+   Phone:   +1-914-276-2668(h)
+            +1-914-784-7913(w)
+   Fax:     +1-914-784-3833(w)
+   EMail:   dee3@us.ibm.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake                    Standards Track                     [Page 5]
+
+RFC 2537            RSA/MD5 KEYs and SIGs in the DNS          March 1999
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (1999).  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 Standards process must be
+   followed, or as required to translate it into 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake                    Standards Track                     [Page 6]
+
diff --git a/doc/rfc/rfc2538.txt b/doc/rfc/rfc2538.txt
new file mode 100644
index 0000000..c53e3ef
--- /dev/null
+++ b/doc/rfc/rfc2538.txt
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+Network Working Group                                        D. Eastlake
+Request for Comments: 2538                                           IBM
+Category: Standards Track                                 O. Gudmundsson
+                                                                TIS Labs
+                                                              March 1999
+
+
+          Storing Certificates in the Domain Name System (DNS)
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (1999).  All Rights Reserved.
+
+Abstract
+
+   Cryptographic public key are frequently published and their
+   authenticity demonstrated by certificates.  A CERT resource record
+   (RR) is defined so that such certificates and related certificate
+   revocation lists can be stored in the Domain Name System (DNS).
+
+Table of Contents
+
+   Abstract...................................................1
+   1. Introduction............................................2
+   2. The CERT Resource Record................................2
+   2.1 Certificate Type Values................................3
+   2.2 Text Representation of CERT RRs........................4
+   2.3 X.509 OIDs.............................................4
+   3. Appropriate Owner Names for CERT RRs....................5
+   3.1 X.509 CERT RR Names....................................5
+   3.2 PGP CERT RR Names......................................6
+   4. Performance Considerations..............................6
+   5. IANA Considerations.....................................7
+   6. Security Considerations.................................7
+   References.................................................8
+   Authors' Addresses.........................................9
+   Full Copyright Notice.....................................10
+
+
+
+
+
+
+Eastlake & Gudmundsson      Standards Track                     [Page 1]
+
+RFC 2538            Storing Certificates in the DNS           March 1999
+
+
+1. Introduction
+
+   Public keys are frequently published in the form of a certificate and
+   their authenticity is commonly demonstrated by certificates and
+   related certificate revocation lists (CRLs).  A certificate is a
+   binding, through a cryptographic digital signature, of a public key,
+   a validity interval and/or conditions, and identity, authorization,
+   or other information. A certificate revocation list is a list of
+   certificates that are revoked, and incidental information, all signed
+   by the signer (issuer) of the revoked certificates. Examples are
+   X.509 certificates/CRLs in the X.500 directory system or PGP
+   certificates/revocations used by PGP software.
+
+   Section 2 below specifies a CERT resource record (RR) for the storage
+   of certificates in the Domain Name System.
+
+   Section 3 discusses appropriate owner names for CERT RRs.
+
+   Sections 4, 5, and 6 below cover performance, IANA, and security
+   considerations, respectively.
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC2119].
+
+2. The CERT Resource Record
+
+   The CERT resource record (RR) has the structure given below.  Its RR
+   type code is 37.
+
+                         1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
+     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |             type              |             key tag           |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |   algorithm   |                                               /
+    +---------------+            certificate or CRL                 /
+    /                                                               /
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
+
+   The type field is the certificate type as define in section 2.1
+   below.
+
+   The algorithm field has the same meaning as the algorithm field in
+   KEY and SIG RRs [RFC 2535] except that a zero algorithm field
+   indicates the algorithm is unknown to a secure DNS, which may simply
+   be the result of the algorithm not having been standardized for
+   secure DNS.
+
+
+
+Eastlake & Gudmundsson      Standards Track                     [Page 2]
+
+RFC 2538            Storing Certificates in the DNS           March 1999
+
+
+   The key tag field is the 16 bit value computed for the key embedded
+   in the certificate as specified in the DNSSEC Standard [RFC 2535].
+   This field is used as an efficiency measure to pick which CERT RRs
+   may be applicable to a particular key.  The key tag can be calculated
+   for the key in question and then only CERT RRs with the same key tag
+   need be examined. However, the key must always be transformed to the
+   format it would have as the public key portion of a KEY RR before the
+   key tag is computed.  This is only possible if the key is applicable
+   to an algorithm (and limits such as key size limits) defined for DNS
+   security.  If it is not, the algorithm field MUST BE zero and the tag
+   field is meaningless and SHOULD BE zero.
+
+2.1 Certificate Type Values
+
+   The following values are defined or reserved:
+
+    Value  Mnemonic  Certificate Type
+    -----  --------  ----------- ----
+        0            reserved
+        1   PKIX     X.509 as per PKIX
+        2   SPKI     SPKI cert
+        3   PGP      PGP cert
+    4-252            available for IANA assignment
+      253   URI      URI private
+      254   OID      OID private
+    255-65534        available for IANA assignment
+    65535            reserved
+
+   The PKIX type is reserved to indicate an X.509 certificate conforming
+   to the profile being defined by the IETF PKIX working group.  The
+   certificate section will start with a one byte unsigned OID length
+   and then an X.500 OID indicating the nature of the remainder of the
+   certificate section (see 2.3 below).  (NOTE: X.509 certificates do
+   not include their X.500 directory type designating OID as a prefix.)
+
+   The SPKI type is reserved to indicate a certificate formated as to be
+   specified by the IETF SPKI working group.
+
+   The PGP type indicates a Pretty Good Privacy certificate as described
+   in RFC 2440 and its extensions and successors.
+
+   The URI private type indicates a certificate format defined by an
+   absolute URI.  The certificate portion of the CERT RR MUST begin with
+   a null terminated URI [RFC 2396] and the data after the null is the
+   private format certificate itself.  The URI SHOULD be such that a
+   retrieval from it will lead to documentation on the format of the
+   certificate.  Recognition of private certificate types need not be
+   based on URI equality but can use various forms of pattern matching
+
+
+
+Eastlake & Gudmundsson      Standards Track                     [Page 3]
+
+RFC 2538            Storing Certificates in the DNS           March 1999
+
+
+   so that, for example, subtype or version information can also be
+   encoded into the URI.
+
+   The OID private type indicates a private format certificate specified
+   by a an ISO OID prefix.  The certificate section will start with a
+   one byte unsigned OID length and then a BER encoded OID indicating
+   the nature of the remainder of the certificate section.  This can be
+   an X.509 certificate format or some other format.  X.509 certificates
+   that conform to the IETF PKIX profile SHOULD be indicated by the PKIX
+   type, not the OID private type.  Recognition of private certificate
+   types need not be based on OID equality but can use various forms of
+   pattern matching such as OID prefix.
+
+2.2 Text Representation of CERT RRs
+
+   The RDATA portion of a CERT RR has the type field as an unsigned
+   integer or as a mnemonic symbol as listed in section 2.1 above.
+
+   The key tag field is represented as an unsigned integer.
+
+   The algorithm field is represented as an unsigned integer or a
+   mnemonic symbol as listed in [RFC 2535].
+
+   The certificate / CRL portion is represented in base 64 and may be
+   divided up into any number of white space separated substrings, down
+   to single base 64 digits, which are concatenated to obtain the full
+   signature.  These substrings can span lines using the standard
+   parenthesis.
+
+   Note that the certificate / CRL portion may have internal sub-fields
+   but these do not appear in the master file representation.  For
+   example, with type 254, there will be an OID size, an OID, and then
+   the certificate / CRL proper. But only a single logical base 64
+   string will appear in the text representation.
+
+2.3 X.509 OIDs
+
+   OIDs have been defined in connection with the X.500 directory for
+   user certificates, certification authority certificates, revocations
+   of certification authority, and revocations of user certificates.
+   The following table lists the OIDs, their BER encoding, and their
+   length prefixed hex format for use in CERT RRs:
+
+
+
+
+
+
+
+
+
+Eastlake & Gudmundsson      Standards Track                     [Page 4]
+
+RFC 2538            Storing Certificates in the DNS           March 1999
+
+
+    id-at-userCertificate
+        = { joint-iso-ccitt(2) ds(5) at(4) 36 }
+           == 0x 03 55 04 24
+    id-at-cACertificate
+        = { joint-iso-ccitt(2) ds(5) at(4) 37 }
+           == 0x 03 55 04 25
+    id-at-authorityRevocationList
+        = { joint-iso-ccitt(2) ds(5) at(4) 38 }
+           == 0x 03 55 04 26
+    id-at-certificateRevocationList
+        = { joint-iso-ccitt(2) ds(5) at(4) 39 }
+           == 0x 03 55 04 27
+
+3. Appropriate Owner Names for CERT RRs
+
+   It is recommended that certificate CERT RRs be stored under a domain
+   name related to their subject, i.e., the name of the entity intended
+   to control the private key corresponding to the public key being
+   certified.  It is recommended that certificate revocation list CERT
+   RRs be stored under a domain name related to their issuer.
+
+   Following some of the guidelines below may result in the use in DNS
+   names of characters that require DNS quoting which is to use a
+   backslash followed by the octal representation of the ASCII code for
+   the character such as \000 for NULL.
+
+3.1 X.509 CERT RR Names
+
+   Some X.509 versions permit multiple names to be associated with
+   subjects and issuers under "Subject Alternate Name" and "Issuer
+   Alternate Name".  For example, x.509v3 has such Alternate Names with
+   an ASN.1 specification as follows:
+
+         GeneralName ::= CHOICE {
+            otherName                  [0] INSTANCE OF OTHER-NAME,
+            rfc822Name                 [1] IA5String,
+            dNSName                    [2] IA5String,
+            x400Address                [3] EXPLICIT OR-ADDRESS.&Type,
+            directoryName              [4] EXPLICIT Name,
+            ediPartyName               [5] EDIPartyName,
+            uniformResourceIdentifier  [6] IA5String,
+            iPAddress                  [7] OCTET STRING,
+            registeredID               [8] OBJECT IDENTIFIER
+         }
+
+   The recommended locations of CERT storage are as follows, in priority
+   order:
+
+
+
+
+Eastlake & Gudmundsson      Standards Track                     [Page 5]
+
+RFC 2538            Storing Certificates in the DNS           March 1999
+
+
+   (1) If a domain name is included in the identification in the
+       certificate or CRL, that should be used.
+   (2) If a domain name is not included but an IP address is included,
+       then the translation of that IP address into the appropriate
+       inverse domain name should be used.
+   (3) If neither of the above it used but a URI containing a domain
+       name is present, that domain name should be used.
+   (4) If none of the above is included but a character string name is
+       included, then it should be treated as described for PGP names in
+       3.2 below.
+   (5) If none of the above apply, then the distinguished name (DN)
+       should be mapped into a domain name as specified in RFC 2247.
+
+   Example 1: Assume that an X.509v3 certificate is issued to /CN=John
+   Doe/DC=Doe/DC=com/DC=xy/O=Doe Inc/C=XY/ with Subject Alternative
+   names of (a) string "John (the Man) Doe", (b) domain name john-
+   doe.com, and (c) uri <https://www.secure.john-doe.com:8080/>.  Then
+   the storage locations recommended, in priority order, would be
+       (1) john-doe.com,
+       (2) www.secure.john-doe.com, and
+       (3) Doe.com.xy.
+
+   Example 2:  Assume that an X.509v3 certificate is issued to /CN=James
+   Hacker/L=Basingstoke/O=Widget Inc/C=GB/ with Subject Alternate names
+   of (a) domain name widget.foo.example, (b) IPv4 address
+   10.251.13.201, and (c) string "James Hacker
+   <hacker@mail.widget.foo.example>".  Then the storage locations
+   recommended, in priority order, would be
+        (1) widget.foo.example,
+        (2) 201.13.251.10.in-addr.arpa, and
+        (3) hacker.mail.widget.foo.example.
+
+3.2 PGP CERT RR Names
+
+   PGP signed keys (certificates) use a general character string User ID
+   [RFC 2440]. However, it is recommended by PGP that such names include
+   the RFC 822 email address of the party, as in "Leslie Example
+   <Leslie@host.example>".  If such a format is used, the CERT should be
+   under the standard translation of the email address into a domain
+   name, which would be leslie.host.example in this case.  If no RFC 822
+   name can be extracted from the string name no specific domain name is
+   recommended.
+
+4. Performance Considerations
+
+   Current Domain Name System (DNS) implementations are optimized for
+   small transfers, typically not more than 512 bytes including
+   overhead.  While larger transfers will perform correctly and work is
+
+
+
+Eastlake & Gudmundsson      Standards Track                     [Page 6]
+
+RFC 2538            Storing Certificates in the DNS           March 1999
+
+
+   underway to make larger transfers more efficient, it is still
+   advisable at this time to make every reasonable effort to minimize
+   the size of certificates stored within the DNS.  Steps that can be
+   taken may include using the fewest possible optional or extensions
+   fields and using short field values for variable length fields that
+   must be included.
+
+5. IANA Considerations
+
+   Certificate types 0x0000 through 0x00FF and 0xFF00 through 0xFFFF can
+   only be assigned by an IETF standards action [RFC 2434] (and this
+   document assigns 0x0001 through 0x0003 and 0x00FD and 0x00FE).
+   Certificate types 0x0100 through 0xFEFF are assigned through IETF
+   Consensus [RFC 2434] based on RFC documentation of the certificate
+   type.  The availability of private types under 0x00FD and 0x00FE
+   should satisfy most requirements for proprietary or private types.
+
+6. Security Considerations
+
+   By definition, certificates contain their own authenticating
+   signature.  Thus it is reasonable to store certificates in non-secure
+   DNS zones or to retrieve certificates from DNS with DNS security
+   checking not implemented or deferred for efficiency.  The results MAY
+   be trusted if the certificate chain is verified back to a known
+   trusted key and this conforms with the user's security policy.
+
+   Alternatively, if certificates are retrieved from a secure DNS zone
+   with DNS security checking enabled and are verified by DNS security,
+   the key within the retrieved certificate MAY be trusted without
+   verifying the certificate chain if this conforms with the user's
+   security policy.
+
+   CERT RRs are not used in connection with securing the DNS security
+   additions so there are no security considerations related to CERT RRs
+   and securing the DNS itself.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake & Gudmundsson      Standards Track                     [Page 7]
+
+RFC 2538            Storing Certificates in the DNS           March 1999
+
+
+References
+
+   RFC 1034   Mockapetris, P., "Domain Names - Concepts and Facilities",
+              STD 13, RFC 1034, November 1987.
+
+   RFC 1035   Mockapetris, P., "Domain Names - Implementation and
+              Specifications", STD 13, RFC 1035, November 1987.
+
+   RFC 2119   Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   RFC 2247   Kille, S., Wahl, M., Grimstad, A., Huber, R. and S.
+              Sataluri, "Using Domains in LDAP/X.500 Distinguished
+              Names", RFC 2247, January 1998.
+
+   RFC 2396   Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
+              Resource Identifiers (URI): Generic Syntax", RFC 2396,
+              August 1998.
+
+   RFC 2440   Callas, J., Donnerhacke, L., Finney, H. and R.  Thayer,
+              "OpenPGP Message Format", RFC 2240, November 1998.
+
+   RFC 2434   Narten, T. and H. Alvestrand, "Guidelines for Writing an
+              IANA Considerations Section in RFCs", BCP 26, RFC 2434,
+              October 1998.
+
+   RFC 2535   Eastlake, D., "Domain Name System (DNS) Security
+              Extensions", RFC 2535, March 1999.
+
+   RFC 2459   Housley, R., Ford, W., Polk, W. and D. Solo, "Internet
+              X.509 Public Key Infrastructure Certificate and CRL
+              Profile", RFC 2459, January 1999.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake & Gudmundsson      Standards Track                     [Page 8]
+
+RFC 2538            Storing Certificates in the DNS           March 1999
+
+
+Authors' Addresses
+
+   Donald E. Eastlake 3rd
+   IBM
+   65 Shindegan Hill Road
+   RR#1
+   Carmel, NY 10512 USA
+
+   Phone:   +1-914-784-7913 (w)
+            +1-914-276-2668 (h)
+   Fax:     +1-914-784-3833 (w-fax)
+   EMail:   dee3@us.ibm.com
+
+
+   Olafur Gudmundsson
+   TIS Labs at Network Associates
+   3060 Washington Rd, Route 97
+   Glenwood MD 21738
+
+   Phone: +1 443-259-2389
+   EMail: ogud@tislabs.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake & Gudmundsson      Standards Track                     [Page 9]
+
+RFC 2538            Storing Certificates in the DNS           March 1999
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (1999).  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 Standards process must be
+   followed, or as required to translate it into 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake & Gudmundsson      Standards Track                    [Page 10]
+
diff --git a/doc/rfc/rfc2539.txt b/doc/rfc/rfc2539.txt
new file mode 100644
index 0000000..cf32523
--- /dev/null
+++ b/doc/rfc/rfc2539.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+Network Working Group                                        D. Eastlake
+Request for Comments: 2539                                           IBM
+Category: Standards Track                                     March 1999
+
+
+     Storage of Diffie-Hellman Keys in the Domain Name System (DNS)
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (1999).  All Rights Reserved.
+
+Abstract
+
+   A standard method for storing Diffie-Hellman keys in the Domain Name
+   System is described which utilizes DNS KEY resource records.
+
+Acknowledgements
+
+   Part of the format for Diffie-Hellman keys and the description
+   thereof was taken from a work in progress by:
+
+      Ashar Aziz <ashar.aziz@eng.sun.com>
+      Tom Markson <markson@incog.com>
+      Hemma Prafullchandra <hemma@eng.sun.com>
+
+   In addition, the following person provided useful comments that have
+   been incorporated:
+
+      Ran Atkinson <rja@inet.org>
+      Thomas Narten <narten@raleigh.ibm.com>
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake                    Standards Track                     [Page 1]
+
+RFC 2539             Diffie-Hellman Keys in the DNS           March 1999
+
+
+Table of Contents
+
+   Abstract...................................................1
+   Acknowledgements...........................................1
+   1. Introduction............................................2
+   1.1 About This Document....................................2
+   1.2 About Diffie-Hellman...................................2
+   2. Diffie-Hellman KEY Resource Records.....................3
+   3. Performance Considerations..............................4
+   4. IANA Considerations.....................................4
+   5. Security Considerations.................................4
+   References.................................................5
+   Author's Address...........................................5
+   Appendix A: Well known prime/generator pairs...............6
+   A.1. Well-Known Group 1:  A 768 bit prime..................6
+   A.2. Well-Known Group 2:  A 1024 bit prime.................6
+   Full Copyright Notice......................................7
+
+1. Introduction
+
+   The Domain Name System (DNS) is the current global hierarchical
+   replicated distributed database system for Internet addressing, mail
+   proxy, and similar information. The DNS has been extended to include
+   digital signatures and cryptographic keys as described in [RFC 2535].
+   Thus the DNS can now be used for secure key distribution.
+
+1.1 About This Document
+
+   This document describes how to store Diffie-Hellman keys in the DNS.
+   Familiarity with the Diffie-Hellman key exchange algorithm is assumed
+   [Schneier].
+
+1.2 About Diffie-Hellman
+
+   Diffie-Hellman requires two parties to interact to derive keying
+   information which can then be used for authentication.  Since DNS SIG
+   RRs are primarily used as stored authenticators of zone information
+   for many different resolvers, no Diffie-Hellman algorithm SIG RR is
+   defined. For example, assume that two parties have local secrets "i"
+   and "j".  Assume they each respectively calculate X and Y as follows:
+
+                X = g**i ( mod p ) Y = g**j ( mod p )
+
+   They exchange these quantities and then each calculates a Z as
+   follows:
+
+                Zi = Y**i ( mod p ) Zj = X**j ( mod p )
+
+
+
+
+Eastlake                    Standards Track                     [Page 2]
+
+RFC 2539             Diffie-Hellman Keys in the DNS           March 1999
+
+
+   shared secret between the two parties that an adversary who does not
+   know i or j will not be able to learn from the exchanged messages
+   (unless the adversary can derive i or j by performing a discrete
+   logarithm mod p which is hard for strong p and g).
+
+   The private key for each party is their secret i (or j).  The public
+   key is the pair p and g, which must be the same for the parties, and
+   their individual X (or Y).
+
+2. Diffie-Hellman KEY Resource Records
+
+   Diffie-Hellman keys are stored in the DNS as KEY RRs using algorithm
+   number 2.  The structure of the RDATA portion of this RR is as shown
+   below.  The first 4 octets, including the flags, protocol, and
+   algorithm fields are common to all KEY RRs as described in [RFC
+   2535].  The remainder, from prime length through public value is the
+   "public key" part of the KEY RR. The period of key validity is not in
+   the KEY RR but is indicated by the SIG RR(s) which signs and
+   authenticates the KEY RR(s) at that domain name.
+
+                         1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
+     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |           KEY flags           |    protocol   |  algorithm=2  |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |     prime length (or flag)    |  prime (p) (or special)       /
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    /  prime (p)  (variable length) |       generator length        |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    | generator (g) (variable length)                               |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |     public value length       | public value (variable length)/
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    /  public value (g^i mod p)    (variable length)                |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Prime length is length of the Diffie-Hellman prime (p) in bytes if it
+   is 16 or greater.  Prime contains the binary representation of the
+   Diffie-Hellman prime with most significant byte first (i.e., in
+   network order). If "prime length" field is 1 or 2, then the "prime"
+   field is actually an unsigned index into a table of 65,536
+   prime/generator pairs and the generator length SHOULD be zero.  See
+   Appedix A for defined table entries and Section 4 for information on
+   allocating additional table entries.  The meaning of a zero or 3
+   through 15 value for "prime length" is reserved.
+
+
+
+
+
+
+Eastlake                    Standards Track                     [Page 3]
+
+RFC 2539             Diffie-Hellman Keys in the DNS           March 1999
+
+
+   Generator length is the length of the generator (g) in bytes.
+   Generator is the binary representation of generator with most
+   significant byte first.  PublicValueLen is the Length of the Public
+   Value (g**i (mod p)) in bytes.  PublicValue is the binary
+   representation of the DH public value with most significant byte
+   first.
+
+   The corresponding algorithm=2 SIG resource record is not used so no
+   format for it is defined.
+
+3. Performance Considerations
+
+   Current DNS implementations are optimized for small transfers,
+   typically less than 512 bytes including overhead.  While larger
+   transfers will perform correctly and work is underway to make larger
+   transfers more efficient, it is still advisable to make reasonable
+   efforts to minimize the size of KEY RR sets stored within the DNS
+   consistent with adequate security.  Keep in mind that in a secure
+   zone, an authenticating SIG RR will also be returned.
+
+4. IANA Considerations
+
+   Assignment of meaning to Prime Lengths of 0 and 3 through 15 requires
+   an IETF consensus.
+
+   Well known prime/generator pairs number 0x0000 through 0x07FF can
+   only be assigned by an IETF standards action and this Proposed
+   Standard assigns 0x0001 through 0x0002. Pairs number 0s0800 through
+   0xBFFF can be assigned based on RFC documentation.  Pairs number
+   0xC000 through 0xFFFF are available for private use and are not
+   centrally coordinated. Use of such private pairs outside of a closed
+   environment may result in conflicts.
+
+5. Security Considerations
+
+   Many of the general security consideration in [RFC 2535] apply.  Keys
+   retrieved from the DNS should not be trusted unless (1) they have
+   been securely obtained from a secure resolver or independently
+   verified by the user and (2) this secure resolver and secure
+   obtainment or independent verification conform to security policies
+   acceptable to the user.  As with all cryptographic algorithms,
+   evaluating the necessary strength of the key is important and
+   dependent on local policy.
+
+   In addition, the usual Diffie-Hellman key strength considerations
+   apply. (p-1)/2 should also be prime, g should be primitive mod p, p
+   should be "large", etc.  [Schneier]
+
+
+
+
+Eastlake                    Standards Track                     [Page 4]
+
+RFC 2539             Diffie-Hellman Keys in the DNS           March 1999
+
+
+References
+
+   [RFC 1034]   Mockapetris, P., "Domain Names - Concepts and
+                Facilities", STD 13, RFC 1034, November 1987.
+
+   [RFC 1035]   Mockapetris, P., "Domain Names - Implementation and
+                Specification", STD 13, RFC 1035, November 1987.
+
+   [RFC 2535]   Eastlake, D., "Domain Name System Security Extensions",
+                RFC 2535, March 1999.
+
+   [Schneier]   Bruce Schneier, "Applied Cryptography: Protocols,
+                Algorithms, and Source Code in C", 1996, John Wiley and
+                Sons
+
+Author's Address
+
+   Donald E. Eastlake 3rd
+   IBM
+   65 Shindegan Hill Road, RR #1
+   Carmel, NY 10512
+
+   Phone:   +1-914-276-2668(h)
+            +1-914-784-7913(w)
+   Fax:     +1-914-784-3833(w)
+   EMail:   dee3@us.ibm.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake                    Standards Track                     [Page 5]
+
+RFC 2539             Diffie-Hellman Keys in the DNS           March 1999
+
+
+Appendix A: Well known prime/generator pairs
+
+   These numbers are copied from the IPSEC effort where the derivation
+   of these values is more fully explained and additional information is
+   available.  Richard Schroeppel performed all the mathematical and
+   computational work for this appendix.
+
+A.1. Well-Known Group 1:  A 768 bit prime
+
+   The prime is 2^768 - 2^704 - 1 + 2^64 * { [2^638 pi] + 149686 }.  Its
+   decimal value is
+          155251809230070893513091813125848175563133404943451431320235
+          119490296623994910210725866945387659164244291000768028886422
+          915080371891804634263272761303128298374438082089019628850917
+          0691316593175367469551763119843371637221007210577919
+
+   Prime modulus: Length (32 bit words): 24, Data (hex):
+            FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
+            29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
+            EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
+            E485B576 625E7EC6 F44C42E9 A63A3620 FFFFFFFF FFFFFFFF
+
+   Generator: Length (32 bit words): 1, Data (hex): 2
+
+A.2. Well-Known Group 2:  A 1024 bit prime
+
+   The prime is 2^1024 - 2^960 - 1 + 2^64 * { [2^894 pi] + 129093 }.
+   Its decimal value is
+         179769313486231590770839156793787453197860296048756011706444
+         423684197180216158519368947833795864925541502180565485980503
+         646440548199239100050792877003355816639229553136239076508735
+         759914822574862575007425302077447712589550957937778424442426
+         617334727629299387668709205606050270810842907692932019128194
+         467627007
+
+   Prime modulus:  Length (32 bit words): 32, Data (hex):
+            FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
+            29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
+            EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
+            E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
+            EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381
+            FFFFFFFF FFFFFFFF
+
+   Generator: Length (32 bit words):  1, Data (hex): 2
+
+
+
+
+
+
+
+Eastlake                    Standards Track                     [Page 6]
+
+RFC 2539             Diffie-Hellman Keys in the DNS           March 1999
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (1999).  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 Standards process must be
+   followed, or as required to translate it into 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake                    Standards Track                     [Page 7]
+
diff --git a/doc/rfc/rfc2540.txt b/doc/rfc/rfc2540.txt
new file mode 100644
index 0000000..6314806
--- /dev/null
+++ b/doc/rfc/rfc2540.txt
@@ -0,0 +1,339 @@
+
+
+
+
+
+
+Network Working Group                                        D. Eastlake
+Request for Comments: 2540                                           IBM
+Category: Experimental                                        March 1999
+
+
+             Detached Domain Name System (DNS) Information
+
+Status of this Memo
+
+   This memo defines an Experimental Protocol for the Internet
+   community.  It does not specify an Internet standard of any kind.
+   Discussion and suggestions for improvement are requested.
+   Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (1999).  All Rights Reserved.
+
+Abstract
+
+   A standard format is defined for representing detached DNS
+   information.  This is anticipated to be of use for storing
+   information retrieved from the Domain Name System (DNS), including
+   security information, in archival contexts or contexts not connected
+   to the Internet.
+
+Table of Contents
+
+   Abstract...................................................1
+   1. Introduction............................................1
+   2. General Format..........................................2
+   2.1 Binary Format..........................................3
+   2.2. Text Format...........................................4
+   3. Usage Example...........................................4
+   4. IANA Considerations.....................................4
+   5. Security Considerations.................................4
+   References.................................................5
+   Author's Address...........................................5
+   Full Copyright Statement...................................6
+
+1. Introduction
+
+   The Domain Name System (DNS) is a replicated hierarchical distributed
+   database system [RFC 1034, 1035] that can provide highly available
+   service.  It provides the operational basis for Internet host name to
+   address translation, automatic SMTP mail routing, and other basic
+   Internet functions.  The DNS has been extended as described in [RFC
+   2535] to permit the general storage of public cryptographic keys in
+
+
+
+Eastlake                      Experimental                      [Page 1]
+
+RFC 2540                Detached DNS Information              March 1999
+
+
+   the DNS and to enable the authentication of information retrieved
+   from the DNS though digital signatures.
+
+   The DNS was not originally designed for storage of information
+   outside of the active zones and authoritative master files that are
+   part of the connected DNS.  However there may be cases where this is
+   useful, particularly in connection with archived security
+   information.
+
+2. General Format
+
+   The formats used for detached Domain Name System (DNS) information
+   are similar to those used for connected DNS information. The primary
+   difference is that elements of the connected DNS system (unless they
+   are an authoritative server for the zone containing the information)
+   are required to count down the Time To Live (TTL) associated with
+   each DNS Resource Record (RR) and discard them (possibly fetching a
+   fresh copy) when the TTL reaches zero.  In contrast to this, detached
+   information may be stored in a off-line file, where it can not be
+   updated, and perhaps used to authenticate historic data or it might
+   be received via non-DNS protocols long after it was retrieved from
+   the DNS.  Therefore, it is not practical to count down detached DNS
+   information TTL and it may be necessary to keep the data beyond the
+   point where the TTL (which is defined as an unsigned field) would
+   underflow.  To preserve information as to the freshness of this
+   detached data, it is accompanied by its retrieval time.
+
+   Whatever retrieves the information from the DNS must associate this
+   retrieval time with it.  The retrieval time remains fixed thereafter.
+   When the current time minus the retrieval time exceeds the TTL for
+   any particular detached RR, it is no longer a valid copy within the
+   normal connected DNS scheme.  This may make it invalid in context for
+   some detached purposes as well.  If the RR is a SIG (signature) RR it
+   also has an expiration time.  Regardless of the TTL, it and any RRs
+   it signs can not be considered authenticated after the signature
+   expiration time.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake                      Experimental                      [Page 2]
+
+RFC 2540                Detached DNS Information              March 1999
+
+
+2.1 Binary Format
+
+   The standard binary format for detached DNS information is as
+   follows:
+
+                         1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
+     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |                      first retrieval time                     |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |          RR count             |                               |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     Resource Records (RRs)    |
+    /                                                               /
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
+    |                       next retrieval time                     |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |          RR count             |                               |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     Resource Records (RRs)    |
+    /                                                               /
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    /                              ...                              /
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |     hex 20    |
+    +-+-+-+-+-+-+-+-+
+
+   Retrieval time - the time that the immediately following information
+       was obtained from the connected DNS system.  It is an unsigned
+       number of seconds since the start of 1 January 1970, GMT,
+       ignoring leap seconds, in network (big-endian) order.  Note that
+       this time can not be before the initial proposal of this
+       standard.  Therefore, the initial byte of an actual retrieval
+       time, considered as a 32 bit unsigned quantity, would always be
+       larger than 20 hex.  The end of detached DNS information is
+       indicated by a "retrieval time" field initial byte equal to 0x20.
+       Use of a "retrieval time" field with a leading unsigned byte of
+       zero indicates a 64 bit (actually 8 leading zero bits plus a 56
+       bit quantity).  This 64 bit format will be required when
+       retrieval time is larger than 0xFFFFFFFF, which is some time in
+       the year 2106.  The meaning of retrieval times with an initial
+       byte between 0x01 and 0x1F is reserved (see section 5).
+       Retrieval times will not generally be 32 bit aligned with respect
+       to each other due to the variable length nature of RRs.
+
+   RR count - an unsigned integer number (with bytes in network order)
+       of following resource records retrieved at the preceding
+       retrieval time.
+
+
+
+
+
+Eastlake                      Experimental                      [Page 3]
+
+RFC 2540                Detached DNS Information              March 1999
+
+
+   Resource Records - the actual data which is in the same format as if
+       it were being transmitted in a DNS response.  In particular, name
+       compression via pointers is permitted with the origin at the
+       beginning of the particular detached information data section,
+       just after the RR count.
+
+2.2. Text Format
+
+   The standard text format for detached DNS information is as
+   prescribed for zone master files [RFC 1035] except that the $INCLUDE
+   control entry is prohibited and the new $DATE entry is required
+   (unless the information set is empty). $DATE is followed by the date
+   and time that the following information was obtained from the DNS
+   system as described for retrieval time in section 2.1 above.  It is
+   in the text format YYYYMMDDHHMMSS where YYYY is the year (which may
+   be more than four digits to cover years after 9999), the first MM is
+   the month number (01-12), DD is the day of the month (01-31), HH is
+   the hour in 24 hours notation (00-23), the second MM is the minute
+   (00-59), and SS is the second (00-59).  Thus a $DATE must appear
+   before the first RR and at every change in retrieval time through the
+   detached information.
+
+3. Usage Example
+
+   A document might be authenticated by a key retrieved from the DNS in
+   a KEY resource record (RR).  To later prove the authenticity of this
+   document, it would be desirable to preserve the KEY RR for that
+   public key, the SIG RR signing that KEY RR, the KEY RR for the key
+   used to authenticate that SIG, and so on through SIG and KEY RRs
+   until a well known trusted key is reached, perhaps the key for the
+   DNS root or some third party authentication service. (In some cases
+   these KEY RRs will actually be sets of KEY RRs with the same owner
+   and class because SIGs actually sign such record sets.)
+
+   This information could be preserved as a set of detached DNS
+   information blocks.
+
+4. IANA Considerations
+
+   Allocation of meanings to retrieval time fields with a initial byte
+   of between 0x01 and 0x1F requires an IETF consensus.
+
+5. Security Considerations
+
+   The entirety of this document concerns a means to represent detached
+   DNS information.  Such detached resource records may be security
+   relevant and/or secured information as described in [RFC 2535].  The
+   detached format provides no overall security for sets of detached
+
+
+
+Eastlake                      Experimental                      [Page 4]
+
+RFC 2540                Detached DNS Information              March 1999
+
+
+   information or for the association between retrieval time and
+   information.  This can be provided by wrapping the detached
+   information format with some other form of signature.  However, if
+   the detached information is accompanied by SIG RRs, its validity
+   period is indicated in those SIG RRs so the retrieval time might be
+   of secondary importance.
+
+References
+
+   [RFC 1034]   Mockapetris, P., "Domain Names - Concepts and
+                Facilities", STD 13, RFC 1034, November 1987.
+
+   [RFC 1035]   Mockapetris, P., " Domain Names - Implementation and
+                Specifications", STD 13, RFC 1035, November 1987.
+
+   [RFC 2535]   Eastlake, D., "Domain Name System Security Extensions",
+                RFC 2535, March 1999.
+
+Author's Address
+
+   Donald E. Eastlake 3rd
+   IBM
+   65 Shindegan Hill Road, RR #1
+   Carmel, NY 10512
+
+   Phone:   +1-914-276-2668(h)
+            +1-914-784-7913(w)
+   Fax:     +1-914-784-3833(w)
+   EMail:   dee3@us.ibm.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake                      Experimental                      [Page 5]
+
+RFC 2540                Detached DNS Information              March 1999
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (1999).  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 Standards process must be
+   followed, or as required to translate it into 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake                      Experimental                      [Page 6]
+
diff --git a/doc/rfc/rfc2541.txt b/doc/rfc/rfc2541.txt
new file mode 100644
index 0000000..a62ed2b
--- /dev/null
+++ b/doc/rfc/rfc2541.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+Network Working Group                                        D. Eastlake
+Request for Comments: 2541                                           IBM
+Category: Informational                                       March 1999
+
+
+                DNS Security Operational Considerations
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (1999).  All Rights Reserved.
+
+Abstract
+
+   Secure DNS is based on cryptographic techniques.  A necessary part of
+   the strength of these techniques is careful attention to the
+   operational aspects of key and signature generation, lifetime, size,
+   and storage.  In addition, special attention must be paid to the
+   security of the high level zones, particularly the root zone.  This
+   document discusses these operational aspects for keys and signatures
+   used in connection with the KEY and SIG DNS resource records.
+
+Acknowledgments
+
+   The contributions and suggestions of the following persons (in
+   alphabetic order) are gratefully acknowledged:
+
+         John Gilmore
+         Olafur Gudmundsson
+         Charlie Kaufman
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake                     Informational                      [Page 1]
+
+RFC 2541        DNS Security Operational Considerations       March 1999
+
+
+Table of Contents
+
+   Abstract...................................................1
+   Acknowledgments............................................1
+   1. Introduction............................................2
+   2. Public/Private Key Generation...........................2
+   3. Public/Private Key Lifetimes............................2
+   4. Public/Private Key Size Considerations..................3
+   4.1 RSA Key Sizes..........................................3
+   4.2 DSS Key Sizes..........................................4
+   5. Private Key Storage.....................................4
+   6. High Level Zones, The Root Zone, and The Meta-Root Key..5
+   7. Security Considerations.................................5
+   References.................................................6
+   Author's Address...........................................6
+   Full Copyright Statement...................................7
+
+1. Introduction
+
+   This document describes operational considerations for the
+   generation, lifetime, size, and storage of DNS cryptographic keys and
+   signatures for use in the KEY and SIG resource records [RFC 2535].
+   Particular attention is paid to high level zones and the root zone.
+
+2. Public/Private Key Generation
+
+   Careful generation of all keys is a sometimes overlooked but
+   absolutely essential element in any cryptographically secure system.
+   The strongest algorithms used with the longest keys are still of no
+   use if an adversary can guess enough to lower the size of the likely
+   key space so that it can be exhaustively searched.  Technical
+   suggestions for the generation of random keys will be found in [RFC
+   1750].
+
+   Long term keys are particularly sensitive as they will represent a
+   more valuable target and be subject to attack for a longer time than
+   short period keys.  It is strongly recommended that long term key
+   generation occur off-line in a manner isolated from the network via
+   an air gap or, at a minimum, high level secure hardware.
+
+3. Public/Private Key Lifetimes
+
+   No key should be used forever.  The longer a key is in use, the
+   greater the probability that it will have been compromised through
+   carelessness, accident, espionage, or cryptanalysis.  Furthermore, if
+
+
+
+
+
+
+Eastlake                     Informational                      [Page 2]
+
+RFC 2541        DNS Security Operational Considerations       March 1999
+
+
+   key rollover is a rare event, there is an increased risk that, when
+   the time does come to change the key, no one at the site will
+   remember how to do it or operational problems will have developed in
+   the key rollover procedures.
+
+   While public key lifetime is a matter of local policy, these
+   considerations imply that, unless there are extraordinary
+   circumstances, no long term key should have a lifetime significantly
+   over four years.  In fact, a reasonable guideline for long term keys
+   that are kept off-line and carefully guarded is a 13 month lifetime
+   with the intent that they be replaced every year.  A reasonable
+   maximum lifetime for keys that are used for transaction security or
+   the like and are kept on line is 36 days with the intent that they be
+   replaced monthly or more often.  In many cases, a key lifetime of
+   somewhat over a day may be reasonable.
+
+   On the other hand, public keys with too short a lifetime can lead to
+   excessive resource consumption in re-signing data and retrieving
+   fresh information because cached information becomes stale.  In the
+   Internet environment, almost all public keys should have lifetimes no
+   shorter than three minutes, which is a reasonable estimate of maximum
+   packet delay even in unusual circumstances.
+
+4. Public/Private Key Size Considerations
+
+   There are a number of factors that effect public key size choice for
+   use in the DNS security extension.  Unfortunately, these factors
+   usually do not all point in the same direction.  Choice of zone key
+   size should generally be made by the zone administrator depending on
+   their local conditions.
+
+   For most schemes, larger keys are more secure but slower.  In
+   addition, larger keys increase the size of the KEY and SIG RRs.  This
+   increases the chance of DNS UDP packet overflow and the possible
+   necessity for using higher overhead TCP in responses.
+
+4.1 RSA Key Sizes
+
+   Given a small public exponent, verification (the most common
+   operation) for the MD5/RSA algorithm will vary roughly with the
+   square of the modulus length, signing will vary with the cube of the
+   modulus length, and key generation (the least common operation) will
+   vary with the fourth power of the modulus length.  The current best
+   algorithms for factoring a modulus and breaking RSA security vary
+   roughly with the 1.6 power of the modulus itself.  Thus going from a
+   640 bit modulus to a 1280 bit modulus only increases the verification
+   time by a factor of 4 but may increase the work factor of breaking
+   the key by over 2^900.
+
+
+
+Eastlake                     Informational                      [Page 3]
+
+RFC 2541        DNS Security Operational Considerations       March 1999
+
+
+   The recommended minimum RSA algorithm modulus size is 704 bits which
+   is believed by the author to be secure at this time.  But high level
+   zones in the DNS tree may wish to set a higher minimum, perhaps 1000
+   bits, for security reasons.  (Since the United States National
+   Security Agency generally permits export of encryption systems using
+   an RSA modulus of up to 512 bits, use of that small a modulus, i.e.
+   n, must be considered weak.)
+
+   For an RSA key used only to secure data and not to secure other keys,
+   704 bits should be adequate at this time.
+
+4.2 DSS Key Sizes
+
+   DSS keys are probably roughly as strong as an RSA key of the same
+   length but DSS signatures are significantly smaller.
+
+5. Private Key Storage
+
+   It is recommended that, where possible, zone private keys and the
+   zone file master copy be kept and used in off-line, non-network
+   connected, physically secure machines only.  Periodically an
+   application can be run to add authentication to a zone by adding SIG
+   and NXT RRs and adding no-key type KEY RRs for subzones/algorithms
+   where a real KEY RR for the subzone with that algorithm is not
+   provided. Then the augmented file can be transferred, perhaps by
+   sneaker-net, to the networked zone primary server machine.
+
+   The idea is to have a one way information flow to the network to
+   avoid the possibility of tampering from the network.  Keeping the
+   zone master file on-line on the network and simply cycling it through
+   an off-line signer does not do this.  The on-line version could still
+   be tampered with if the host it resides on is compromised.  For
+   maximum security, the master copy of the zone file should be off net
+   and should not be updated based on an unsecured network mediated
+   communication.
+
+   This is not possible if the zone is to be dynamically updated
+   securely [RFC 2137]. At least a private key capable of updating the
+   SOA and NXT chain must be on line in that case.
+
+   Secure resolvers must be configured with some trusted on-line public
+   key information (or a secure path to such a resolver) or they will be
+   unable to authenticate.  Although on line, this public key
+   information must be protected or it could be altered so that spoofed
+   DNS data would appear authentic.
+
+
+
+
+
+
+Eastlake                     Informational                      [Page 4]
+
+RFC 2541        DNS Security Operational Considerations       March 1999
+
+
+   Non-zone private keys, such as host or user keys, generally have to
+   be kept on line to be used for real-time purposes such as DNS
+   transaction security.
+
+6. High Level Zones, The Root Zone, and The Meta-Root Key
+
+   Higher level zones are generally more sensitive than lower level
+   zones.  Anyone controlling or breaking the security of a zone thereby
+   obtains authority over all of its subdomains (except in the case of
+   resolvers that have locally configured the public key of a
+   subdomain).  Therefore, extra care should be taken with high level
+   zones and strong keys used.
+
+   The root zone is the most critical of all zones.  Someone controlling
+   or compromising the security of the root zone would control the
+   entire DNS name space of all resolvers using that root zone (except
+   in the case of resolvers that have locally configured the public key
+   of a subdomain). Therefore, the utmost care must be taken in the
+   securing of the root zone. The strongest and most carefully handled
+   keys should be used.  The root zone private key should always be kept
+   off line.
+
+   Many resolvers will start at a root server for their access to and
+   authentication of DNS data.  Securely updating an enormous population
+   of resolvers around the world will be extremely difficult.  Yet the
+   guidelines in section 3 above would imply that the root zone private
+   key be changed annually or more often and if it were staticly
+   configured at all these resolvers, it would have to be updated when
+   changed.
+
+   To permit relatively frequent change to the root zone key yet
+   minimize exposure of the ultimate key of the DNS tree, there will be
+   a "meta-root" key used very rarely and then only to sign a sequence
+   of regular root key RRsets with overlapping time validity periods
+   that are to be rolled out. The root zone contains the meta-root and
+   current regular root KEY RR(s) signed by SIG RRs under both the
+   meta-root and other root private key(s) themselves.
+
+   The utmost security in the storage and use of the meta-root key is
+   essential.  The exact techniques are precautions to be used are
+   beyond the scope of this document.  Because of its special position,
+   it may be best to continue with the same meta-root key for an
+   extended period of time such as ten to fifteen years.
+
+7. Security Considerations
+
+   The entirety of this document is concerned with operational
+   considerations of public/private key pair DNS Security.
+
+
+
+Eastlake                     Informational                      [Page 5]
+
+RFC 2541        DNS Security Operational Considerations       March 1999
+
+
+References
+
+   [RFC 1034]   Mockapetris, P., "Domain Names - Concepts and
+                Facilities", STD 13, RFC 1034, November 1987.
+
+   [RFC 1035]   Mockapetris, P., "Domain Names - Implementation and
+                Specifications", STD 13, RFC 1035, November 1987.
+
+   [RFC 1750]   Eastlake, D., Crocker, S. and J. Schiller, "Randomness
+                Requirements for Security", RFC 1750, December 1994.
+
+   [RFC 2065]   Eastlake, D. and C. Kaufman, "Domain Name System
+                Security Extensions", RFC 2065, January 1997.
+
+   [RFC 2137]   Eastlake, D., "Secure Domain Name System Dynamic
+                Update", RFC 2137, April 1997.
+
+   [RFC 2535]   Eastlake, D., "Domain Name System Security Extensions",
+                RFC 2535, March 1999.
+
+   [RSA FAQ]    RSADSI Frequently Asked Questions periodic posting.
+
+Author's Address
+
+   Donald E. Eastlake 3rd
+   IBM
+   65 Shindegan Hill Road, RR #1
+   Carmel, NY 10512
+
+   Phone:   +1-914-276-2668(h)
+            +1-914-784-7913(w)
+   Fax:     +1-914-784-3833(w)
+   EMail:   dee3@us.ibm.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake                     Informational                      [Page 6]
+
+RFC 2541        DNS Security Operational Considerations       March 1999
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (1999).  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 Standards process must be
+   followed, or as required to translate it into 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake                     Informational                      [Page 7]
+
diff --git a/doc/rfc/rfc2553.txt b/doc/rfc/rfc2553.txt
new file mode 100644
index 0000000..6989bf3
--- /dev/null
+++ b/doc/rfc/rfc2553.txt
@@ -0,0 +1,2299 @@
+
+
+
+
+
+
+Network Working Group                                        R. Gilligan
+Request for Comments: 2553                                      FreeGate
+Obsoletes: 2133                                               S. Thomson
+Category: Informational                                         Bellcore
+                                                                J. Bound
+                                                                  Compaq
+                                                              W. Stevens
+                                                              Consultant
+                                                              March 1999
+
+
+               Basic Socket Interface Extensions for IPv6
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (1999).  All Rights Reserved.
+
+Abstract
+
+   The de facto standard application program interface (API) for TCP/IP
+   applications is the "sockets" interface.  Although this API was
+   developed for Unix in the early 1980s it has also been implemented on
+   a wide variety of non-Unix systems.  TCP/IP applications written
+   using the sockets API have in the past enjoyed a high degree of
+   portability and we would like the same portability with IPv6
+   applications.  But changes are required to the sockets API to support
+   IPv6 and this memo describes these changes.  These include a new
+   socket address structure to carry IPv6 addresses, new address
+   conversion functions, and some new socket options.  These extensions
+   are designed to provide access to the basic IPv6 features required by
+   TCP and UDP applications, including multicasting, while introducing a
+   minimum of change into the system and providing complete
+   compatibility for existing IPv4 applications.  Additional extensions
+   for advanced IPv6 features (raw sockets and access to the IPv6
+   extension headers) are defined in another document [4].
+
+
+
+
+
+
+
+
+
+
+Gilligan, et. al.            Informational                      [Page 1]
+
+RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
+
+
+Table of Contents
+
+   1. Introduction.................................................3
+   2. Design Considerations........................................3
+   2.1 What Needs to be Changed....................................4
+   2.2 Data Types..................................................5
+   2.3 Headers.....................................................5
+   2.4 Structures..................................................5
+   3. Socket Interface.............................................6
+   3.1 IPv6 Address Family and Protocol Family.....................6
+   3.2 IPv6 Address Structure......................................6
+   3.3 Socket Address Structure for 4.3BSD-Based Systems...........7
+   3.4 Socket Address Structure for 4.4BSD-Based Systems...........8
+   3.5 The Socket Functions........................................9
+   3.6 Compatibility with IPv4 Applications.......................10
+   3.7 Compatibility with IPv4 Nodes..............................10
+   3.8 IPv6 Wildcard Address......................................11
+   3.9 IPv6 Loopback Address......................................12
+   3.10 Portability Additions.....................................13
+   4. Interface Identification....................................16
+   4.1 Name-to-Index..............................................16
+   4.2 Index-to-Name..............................................17
+   4.3 Return All Interface Names and Indexes.....................17
+   4.4 Free Memory................................................18
+   5. Socket Options..............................................18
+   5.1 Unicast Hop Limit..........................................18
+   5.2 Sending and Receiving Multicast Packets....................19
+   6. Library Functions...........................................21
+   6.1 Nodename-to-Address Translation............................21
+   6.2 Address-To-Nodename Translation............................24
+   6.3 Freeing memory for getipnodebyname and getipnodebyaddr.....26
+   6.4 Protocol-Independent Nodename and Service Name Translation.26
+   6.5 Socket Address Structure to Nodename and Service Name......29
+   6.6 Address Conversion Functions...............................31
+   6.7 Address Testing Macros.....................................32
+   7. Summary of New Definitions..................................33
+   8. Security Considerations.....................................35
+   9. Year 2000 Considerations....................................35
+   Changes From RFC 2133..........................................35
+   Acknowledgments................................................38
+   References.....................................................39
+   Authors' Addresses.............................................40
+   Full Copyright Statement.......................................41
+
+
+
+
+
+
+
+
+Gilligan, et. al.            Informational                      [Page 2]
+
+RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
+
+
+1. Introduction
+
+   While IPv4 addresses are 32 bits long, IPv6 interfaces are identified
+   by 128-bit addresses.  The socket interface makes the size of an IP
+   address quite visible to an application; virtually all TCP/IP
+   applications for BSD-based systems have knowledge of the size of an
+   IP address.  Those parts of the API that expose the addresses must be
+   changed to accommodate the larger IPv6 address size.  IPv6 also
+   introduces new features (e.g., traffic class and flowlabel), some of
+   which must be made visible to applications via the API.  This memo
+   defines a set of extensions to the socket interface to support the
+   larger address size and new features of IPv6.
+
+2. Design Considerations
+
+   There are a number of important considerations in designing changes
+   to this well-worn API:
+
+      - The API changes should provide both source and binary
+        compatibility for programs written to the original API.  That
+        is, existing program binaries should continue to operate when
+        run on a system supporting the new API.  In addition, existing
+        applications that are re-compiled and run on a system supporting
+        the new API should continue to operate.  Simply put, the API
+        changes for IPv6 should not break existing programs.  An
+        additonal mechanism for implementations to verify this is to
+        verify the new symbols are protected by Feature Test Macros as
+        described in IEEE Std 1003.1.  (Such Feature Test Macros are not
+        defined by this RFC.)
+
+      - The changes to the API should be as small as possible in order
+        to simplify the task of converting existing IPv4 applications to
+        IPv6.
+
+      - Where possible, applications should be able to use this API to
+        interoperate with both IPv6 and IPv4 hosts.  Applications should
+        not need to know which type of host they are communicating with.
+
+      - IPv6 addresses carried in data structures should be 64-bit
+        aligned.  This is necessary in order to obtain optimum
+        performance on 64-bit machine architectures.
+
+   Because of the importance of providing IPv4 compatibility in the API,
+   these extensions are explicitly designed to operate on machines that
+   provide complete support for both IPv4 and IPv6.  A subset of this
+   API could probably be designed for operation on systems that support
+   only IPv6.  However, this is not addressed in this memo.
+
+
+
+
+Gilligan, et. al.            Informational                      [Page 3]
+
+RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
+
+
+2.1 What Needs to be Changed
+
+   The socket interface API consists of a few distinct components:
+
+      -  Core socket functions.
+
+      -  Address data structures.
+
+      -  Name-to-address translation functions.
+
+      -  Address conversion functions.
+
+   The core socket functions -- those functions that deal with such
+   things as setting up and tearing down TCP connections, and sending
+   and receiving UDP packets -- were designed to be transport
+   independent.  Where protocol addresses are passed as function
+   arguments, they are carried via opaque pointers.  A protocol-specific
+   address data structure is defined for each protocol that the socket
+   functions support.  Applications must cast pointers to these
+   protocol-specific address structures into pointers to the generic
+   "sockaddr" address structure when using the socket functions.  These
+   functions need not change for IPv6, but a new IPv6-specific address
+   data structure is needed.
+
+   The "sockaddr_in" structure is the protocol-specific data structure
+   for IPv4.  This data structure actually includes 8-octets of unused
+   space, and it is tempting to try to use this space to adapt the
+   sockaddr_in structure to IPv6.  Unfortunately, the sockaddr_in
+   structure is not large enough to hold the 16-octet IPv6 address as
+   well as the other information (address family and port number) that
+   is needed.  So a new address data structure must be defined for IPv6.
+
+   IPv6 addresses are scoped [2] so they could be link-local, site,
+   organization, global, or other scopes at this time undefined.  To
+   support applications that want to be able to identify a set of
+   interfaces for a specific scope, the IPv6 sockaddr_in structure must
+   support a field that can be used by an implementation to identify a
+   set of interfaces identifying the scope for an IPv6 address.
+
+   The name-to-address translation functions in the socket interface are
+   gethostbyname() and gethostbyaddr().  These are left as is and new
+   functions are defined to support IPv4 and IPv6.  Additionally, the
+   POSIX 1003.g draft [3] specifies a new nodename-to-address
+   translation function which is protocol independent.  This function
+   can also be used with IPv4 and IPv6.
+
+
+
+
+
+
+Gilligan, et. al.            Informational                      [Page 4]
+
+RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
+
+
+   The address conversion functions -- inet_ntoa() and inet_addr() --
+   convert IPv4 addresses between binary and printable form.  These
+   functions are quite specific to 32-bit IPv4 addresses.  We have
+   designed two analogous functions that convert both IPv4 and IPv6
+   addresses, and carry an address type parameter so that they can be
+   extended to other protocol families as well.
+
+   Finally, a few miscellaneous features are needed to support IPv6.
+   New interfaces are needed to support the IPv6 traffic class, flow
+   label, and hop limit header fields.  New socket options are needed to
+   control the sending and receiving of IPv6 multicast packets.
+
+   The socket interface will be enhanced in the future to provide access
+   to other IPv6 features.  These extensions are described in [4].
+
+2.2 Data Types
+
+   The data types of the structure elements given in this memo are
+   intended to be examples, not absolute requirements.  Whenever
+   possible, data types from Draft 6.6 (March 1997) of POSIX 1003.1g are
+   used: uintN_t means an unsigned integer of exactly N bits (e.g.,
+   uint16_t).  We also assume the argument data types from 1003.1g when
+   possible (e.g., the final argument to setsockopt() is a size_t
+   value).  Whenever buffer sizes are specified, the POSIX 1003.1 size_t
+   data type is used (e.g., the two length arguments to getnameinfo()).
+
+2.3 Headers
+
+   When function prototypes and structures are shown we show the headers
+   that must be #included to cause that item to be defined.
+
+2.4 Structures
+
+   When structures are described the members shown are the ones that
+   must appear in an implementation.  Additional, nonstandard members
+   may also be defined by an implementation.  As an additional
+   precaution nonstandard members could be verified by Feature Test
+   Macros as described in IEEE Std 1003.1.  (Such Feature Test Macros
+   are not defined by this RFC.)
+
+   The ordering shown for the members of a structure is the recommended
+   ordering, given alignment considerations of multibyte members, but an
+   implementation may order the members differently.
+
+
+
+
+
+
+
+
+Gilligan, et. al.            Informational                      [Page 5]
+
+RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
+
+
+3. Socket Interface
+
+   This section specifies the socket interface changes for IPv6.
+
+3.1 IPv6 Address Family and Protocol Family
+
+   A new address family name, AF_INET6, is defined in <sys/socket.h>.
+   The AF_INET6 definition distinguishes between the original
+   sockaddr_in address data structure, and the new sockaddr_in6 data
+   structure.
+
+   A new protocol family name, PF_INET6, is defined in <sys/socket.h>.
+   Like most of the other protocol family names, this will usually be
+   defined to have the same value as the corresponding address family
+   name:
+
+      #define PF_INET6        AF_INET6
+
+   The PF_INET6 is used in the first argument to the socket() function
+   to indicate that an IPv6 socket is being created.
+
+3.2 IPv6 Address Structure
+
+   A new in6_addr structure holds a single IPv6 address and is defined
+   as a result of including <netinet/in.h>:
+
+      struct in6_addr {
+          uint8_t  s6_addr[16];      /* IPv6 address */
+      };
+
+   This data structure contains an array of sixteen 8-bit elements,
+   which make up one 128-bit IPv6 address.  The IPv6 address is stored
+   in network byte order.
+
+   The structure in6_addr above is usually implemented with an embedded
+   union with extra fields that force the desired alignment level in a
+   manner similar to BSD implementations of "struct in_addr". Those
+   additional implementation details are omitted here for simplicity.
+
+   An example is as follows:
+
+
+
+
+
+
+
+
+
+
+
+Gilligan, et. al.            Informational                      [Page 6]
+
+RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
+
+
+   struct in6_addr {
+        union {
+            uint8_t  _S6_u8[16];
+            uint32_t _S6_u32[4];
+            uint64_t _S6_u64[2];
+        } _S6_un;
+   };
+   #define s6_addr _S6_un._S6_u8
+
+3.3 Socket Address Structure for 4.3BSD-Based Systems
+
+   In the socket interface, a different protocol-specific data structure
+   is defined to carry the addresses for each protocol suite.  Each
+   protocol- specific data structure is designed so it can be cast into a
+   protocol- independent data structure -- the "sockaddr" structure.
+   Each has a "family" field that overlays the "sa_family" of the
+   sockaddr data structure.  This field identifies the type of the data
+   structure.
+
+   The sockaddr_in structure is the protocol-specific address data
+   structure for IPv4.  It is used to pass addresses between applications
+   and the system in the socket functions.  The following sockaddr_in6
+   structure holds IPv6 addresses and is defined as a result of including
+   the <netinet/in.h> header:
+
+struct sockaddr_in6 {
+    sa_family_t     sin6_family;    /* AF_INET6 */
+    in_port_t       sin6_port;      /* transport layer port # */
+    uint32_t        sin6_flowinfo;  /* IPv6 traffic class & flow info */
+    struct in6_addr sin6_addr;      /* IPv6 address */
+    uint32_t        sin6_scope_id;  /* set of interfaces for a scope */
+};
+
+   This structure is designed to be compatible with the sockaddr data
+   structure used in the 4.3BSD release.
+
+   The sin6_family field identifies this as a sockaddr_in6 structure.
+   This field overlays the sa_family field when the buffer is cast to a
+   sockaddr data structure.  The value of this field must be AF_INET6.
+
+   The sin6_port field contains the 16-bit UDP or TCP port number.  This
+   field is used in the same way as the sin_port field of the
+   sockaddr_in structure.  The port number is stored in network byte
+   order.
+
+
+
+
+
+
+
+Gilligan, et. al.            Informational                      [Page 7]
+
+RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
+
+
+   The sin6_flowinfo field is a 32-bit field that contains two pieces of
+   information: the traffic class and the flow label.  The contents and
+   interpretation of this member is specified in [1].  The sin6_flowinfo
+   field SHOULD be set to zero by an implementation prior to using the
+   sockaddr_in6 structure by an application on receive operations.
+
+   The sin6_addr field is a single in6_addr structure (defined in the
+   previous section).  This field holds one 128-bit IPv6 address.  The
+   address is stored in network byte order.
+
+   The ordering of elements in this structure is specifically designed
+   so that when sin6_addr field is aligned on a 64-bit boundary, the
+   start of the structure will also be aligned on a 64-bit boundary.
+   This is done for optimum performance on 64-bit architectures.
+
+   The sin6_scope_id field is a 32-bit integer that identifies a set of
+   interfaces as appropriate for the scope of the address carried in the
+   sin6_addr field.  For a link scope sin6_addr sin6_scope_id would be
+   an interface index.  For a site scope sin6_addr, sin6_scope_id would
+   be a site identifier.  The mapping of sin6_scope_id to an interface
+   or set of interfaces is left to implementation and future
+   specifications on the subject of site identifiers.
+
+   Notice that the sockaddr_in6 structure will normally be larger than
+   the generic sockaddr structure.  On many existing implementations the
+   sizeof(struct sockaddr_in) equals sizeof(struct sockaddr), with both
+   being 16 bytes.  Any existing code that makes this assumption needs
+   to be examined carefully when converting to IPv6.
+
+3.4 Socket Address Structure for 4.4BSD-Based Systems
+
+   The 4.4BSD release includes a small, but incompatible change to the
+   socket interface.  The "sa_family" field of the sockaddr data
+   structure was changed from a 16-bit value to an 8-bit value, and the
+   space saved used to hold a length field, named "sa_len".  The
+   sockaddr_in6 data structure given in the previous section cannot be
+   correctly cast into the newer sockaddr data structure.  For this
+   reason, the following alternative IPv6 address data structure is
+   provided to be used on systems based on 4.4BSD.  It is defined as a
+   result of including the <netinet/in.h> header.
+
+
+
+
+
+
+
+
+
+
+
+Gilligan, et. al.            Informational                      [Page 8]
+
+RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
+
+
+struct sockaddr_in6 {
+    uint8_t         sin6_len;       /* length of this struct */
+    sa_family_t     sin6_family;    /* AF_INET6 */
+    in_port_t       sin6_port;      /* transport layer port # */
+    uint32_t        sin6_flowinfo;  /* IPv6 flow information */
+    struct in6_addr sin6_addr;      /* IPv6 address */
+    uint32_t        sin6_scope_id;  /* set of interfaces for a scope */
+};
+
+   The only differences between this data structure and the 4.3BSD
+   variant are the inclusion of the length field, and the change of the
+   family field to a 8-bit data type.  The definitions of all the other
+   fields are identical to the structure defined in the previous
+   section.
+
+   Systems that provide this version of the sockaddr_in6 data structure
+   must also declare SIN6_LEN as a result of including the
+   <netinet/in.h> header.  This macro allows applications to determine
+   whether they are being built on a system that supports the 4.3BSD or
+   4.4BSD variants of the data structure.
+
+3.5 The Socket Functions
+
+   Applications call the socket() function to create a socket descriptor
+   that represents a communication endpoint.  The arguments to the
+   socket() function tell the system which protocol to use, and what
+   format address structure will be used in subsequent functions.  For
+   example, to create an IPv4/TCP socket, applications make the call:
+
+      s = socket(PF_INET, SOCK_STREAM, 0);
+
+   To create an IPv4/UDP socket, applications make the call:
+
+      s = socket(PF_INET, SOCK_DGRAM, 0);
+
+   Applications may create IPv6/TCP and IPv6/UDP sockets by simply using
+   the constant PF_INET6 instead of PF_INET in the first argument.  For
+   example, to create an IPv6/TCP socket, applications make the call:
+
+      s = socket(PF_INET6, SOCK_STREAM, 0);
+
+   To create an IPv6/UDP socket, applications make the call:
+
+      s = socket(PF_INET6, SOCK_DGRAM, 0);
+
+
+
+
+
+
+
+Gilligan, et. al.            Informational                      [Page 9]
+
+RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
+
+
+   Once the application has created a PF_INET6 socket, it must use the
+   sockaddr_in6 address structure when passing addresses in to the
+   system.  The functions that the application uses to pass addresses
+   into the system are:
+
+      bind()
+      connect()
+      sendmsg()
+      sendto()
+
+   The system will use the sockaddr_in6 address structure to return
+   addresses to applications that are using PF_INET6 sockets.  The
+   functions that return an address from the system to an application
+   are:
+
+      accept()
+      recvfrom()
+      recvmsg()
+      getpeername()
+      getsockname()
+
+   No changes to the syntax of the socket functions are needed to
+   support IPv6, since all of the "address carrying" functions use an
+   opaque address pointer, and carry an address length as a function
+   argument.
+
+3.6 Compatibility with IPv4 Applications
+
+   In order to support the large base of applications using the original
+   API, system implementations must provide complete source and binary
+   compatibility with the original API.  This means that systems must
+   continue to support PF_INET sockets and the sockaddr_in address
+   structure.  Applications must be able to create IPv4/TCP and IPv4/UDP
+   sockets using the PF_INET constant in the socket() function, as
+   described in the previous section.  Applications should be able to
+   hold a combination of IPv4/TCP, IPv4/UDP, IPv6/TCP and IPv6/UDP
+   sockets simultaneously within the same process.
+
+   Applications using the original API should continue to operate as
+   they did on systems supporting only IPv4.  That is, they should
+   continue to interoperate with IPv4 nodes.
+
+3.7 Compatibility with IPv4 Nodes
+
+   The API also provides a different type of compatibility: the ability
+   for IPv6 applications to interoperate with IPv4 applications.  This
+   feature uses the IPv4-mapped IPv6 address format defined in the IPv6
+   addressing architecture specification [2].  This address format
+
+
+
+Gilligan, et. al.            Informational                     [Page 10]
+
+RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
+
+
+   allows the IPv4 address of an IPv4 node to be represented as an IPv6
+   address.  The IPv4 address is encoded into the low-order 32 bits of
+   the IPv6 address, and the high-order 96 bits hold the fixed prefix
+   0:0:0:0:0:FFFF.  IPv4- mapped addresses are written as follows:
+
+      ::FFFF:<IPv4-address>
+
+   These addresses can be generated automatically by the
+   getipnodebyname() function when the specified host has only IPv4
+   addresses (as described in Section 6.1).
+
+   Applications may use PF_INET6 sockets to open TCP connections to IPv4
+   nodes, or send UDP packets to IPv4 nodes, by simply encoding the
+   destination's IPv4 address as an IPv4-mapped IPv6 address, and
+   passing that address, within a sockaddr_in6 structure, in the
+   connect() or sendto() call.  When applications use PF_INET6 sockets
+   to accept TCP connections from IPv4 nodes, or receive UDP packets
+   from IPv4 nodes, the system returns the peer's address to the
+   application in the accept(), recvfrom(), or getpeername() call using
+   a sockaddr_in6 structure encoded this way.
+
+   Few applications will likely need to know which type of node they are
+   interoperating with.  However, for those applications that do need to
+   know, the IN6_IS_ADDR_V4MAPPED() macro, defined in Section 6.7, is
+   provided.
+
+3.8 IPv6 Wildcard Address
+
+   While the bind() function allows applications to select the source IP
+   address of UDP packets and TCP connections, applications often want
+   the system to select the source address for them.  With IPv4, one
+   specifies the address as the symbolic constant INADDR_ANY (called the
+   "wildcard" address) in the bind() call, or simply omits the bind()
+   entirely.
+
+   Since the IPv6 address type is a structure (struct in6_addr), a
+   symbolic constant can be used to initialize an IPv6 address variable,
+   but cannot be used in an assignment.  Therefore systems provide the
+   IPv6 wildcard address in two forms.
+
+   The first version is a global variable named "in6addr_any" that is an
+   in6_addr structure.  The extern declaration for this variable is
+   defined in <netinet/in.h>:
+
+      extern const struct in6_addr in6addr_any;
+
+
+
+
+
+
+Gilligan, et. al.            Informational                     [Page 11]
+
+RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
+
+
+   Applications use in6addr_any similarly to the way they use INADDR_ANY
+   in IPv4.  For example, to bind a socket to port number 23, but let
+   the system select the source address, an application could use the
+   following code:
+
+      struct sockaddr_in6 sin6;
+       . . .
+      sin6.sin6_family = AF_INET6;
+      sin6.sin6_flowinfo = 0;
+      sin6.sin6_port = htons(23);
+      sin6.sin6_addr = in6addr_any;  /* structure assignment */
+       . . .
+      if (bind(s, (struct sockaddr *) &sin6, sizeof(sin6)) == -1)
+              . . .
+
+   The other version is a symbolic constant named IN6ADDR_ANY_INIT and
+   is defined in <netinet/in.h>.  This constant can be used to
+   initialize an in6_addr structure:
+
+      struct in6_addr anyaddr = IN6ADDR_ANY_INIT;
+
+   Note that this constant can be used ONLY at declaration time.  It can
+   not be used to assign a previously declared in6_addr structure.  For
+   example, the following code will not work:
+
+      /* This is the WRONG way to assign an unspecified address */
+      struct sockaddr_in6 sin6;
+       . . .
+      sin6.sin6_addr = IN6ADDR_ANY_INIT; /* will NOT compile */
+
+   Be aware that the IPv4 INADDR_xxx constants are all defined in host
+   byte order but the IPv6 IN6ADDR_xxx constants and the IPv6
+   in6addr_xxx externals are defined in network byte order.
+
+3.9 IPv6 Loopback Address
+
+   Applications may need to send UDP packets to, or originate TCP
+   connections to, services residing on the local node.  In IPv4, they
+   can do this by using the constant IPv4 address INADDR_LOOPBACK in
+   their connect(), sendto(), or sendmsg() call.
+
+   IPv6 also provides a loopback address to contact local TCP and UDP
+   services.  Like the unspecified address, the IPv6 loopback address is
+   provided in two forms -- a global variable and a symbolic constant.
+
+
+
+
+
+
+
+Gilligan, et. al.            Informational                     [Page 12]
+
+RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
+
+
+   The global variable is an in6_addr structure named
+   "in6addr_loopback."  The extern declaration for this variable is
+   defined in <netinet/in.h>:
+
+      extern const struct in6_addr in6addr_loopback;
+
+   Applications use in6addr_loopback as they would use INADDR_LOOPBACK
+   in IPv4 applications (but beware of the byte ordering difference
+   mentioned at the end of the previous section).  For example, to open
+   a TCP connection to the local telnet server, an application could use
+   the following code:
+
+      struct sockaddr_in6 sin6;
+       . . .
+      sin6.sin6_family = AF_INET6;
+      sin6.sin6_flowinfo = 0;
+      sin6.sin6_port = htons(23);
+      sin6.sin6_addr = in6addr_loopback;  /* structure assignment */
+       . . .
+      if (connect(s, (struct sockaddr *) &sin6, sizeof(sin6)) == -1)
+              . . .
+
+   The symbolic constant is named IN6ADDR_LOOPBACK_INIT and is defined
+   in <netinet/in.h>.  It can be used at declaration time ONLY; for
+   example:
+
+      struct in6_addr loopbackaddr = IN6ADDR_LOOPBACK_INIT;
+
+   Like IN6ADDR_ANY_INIT, this constant cannot be used in an assignment
+   to a previously declared IPv6 address variable.
+
+3.10 Portability Additions
+
+   One simple addition to the sockets API that can help application
+   writers is the "struct sockaddr_storage". This data structure can
+   simplify writing code portable across multiple address families and
+   platforms.  This data structure is designed with the following goals.
+
+      - It has a large enough implementation specific maximum size to
+        store the desired set of protocol specific socket address data
+        structures. Specifically, it is at least large enough to
+        accommodate sockaddr_in and sockaddr_in6 and possibly other
+        protocol specific socket addresses too.
+      - It is aligned at an appropriate boundary so protocol specific
+        socket address data structure pointers can be cast to it and
+        access their fields without alignment problems. (e.g. pointers
+        to sockaddr_in6 and/or sockaddr_in can be cast to it and access
+        fields without alignment problems).
+
+
+
+Gilligan, et. al.            Informational                     [Page 13]
+
+RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
+
+
+      - It has the initial field(s) isomorphic to the fields of the
+        "struct sockaddr" data structure on that implementation which
+        can be used as a discriminants for deriving the protocol in use.
+        These initial field(s) would on most implementations either be a
+        single field of type "sa_family_t" (isomorphic to sa_family
+        field, 16 bits) or two fields of type uint8_t and sa_family_t
+        respectively, (isomorphic to sa_len and sa_family_t, 8 bits
+        each).
+
+   An example implementation design of such a data structure would be as
+   follows.
+
+/*
+ * Desired design of maximum size and alignment
+ */
+#define _SS_MAXSIZE    128  /* Implementation specific max size */
+#define _SS_ALIGNSIZE  (sizeof (int64_t))
+                         /* Implementation specific desired alignment */
+/*
+ * Definitions used for sockaddr_storage structure paddings design.
+ */
+#define _SS_PAD1SIZE   (_SS_ALIGNSIZE - sizeof (sa_family_t))
+#define _SS_PAD2SIZE   (_SS_MAXSIZE - (sizeof (sa_family_t)+
+                              _SS_PAD1SIZE + _SS_ALIGNSIZE))
+struct sockaddr_storage {
+    sa_family_t  __ss_family;     /* address family */
+    /* Following fields are implementation specific */
+    char      __ss_pad1[_SS_PAD1SIZE];
+              /* 6 byte pad, this is to make implementation
+              /* specific pad up to alignment field that */
+              /* follows explicit in the data structure */
+    int64_t   __ss_align;     /* field to force desired structure */
+               /* storage alignment */
+    char      __ss_pad2[_SS_PAD2SIZE];
+              /* 112 byte pad to achieve desired size, */
+              /* _SS_MAXSIZE value minus size of ss_family */
+              /* __ss_pad1, __ss_align fields is 112 */
+};
+
+   On implementations where sockaddr data structure includes a "sa_len",
+   field this data structure would look like this:
+
+/*
+ * Definitions used for sockaddr_storage structure paddings design.
+ */
+#define _SS_PAD1SIZE (_SS_ALIGNSIZE -
+                            (sizeof (uint8_t) + sizeof (sa_family_t))
+#define _SS_PAD2SIZE (_SS_MAXSIZE - (sizeof (sa_family_t)+
+
+
+
+Gilligan, et. al.            Informational                     [Page 14]
+
+RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
+
+
+                              _SS_PAD1SIZE + _SS_ALIGNSIZE))
+struct sockaddr_storage {
+    uint8_t      __ss_len;        /* address length */
+    sa_family_t  __ss_family;     /* address family */
+    /* Following fields are implementation specific */
+    char         __ss_pad1[_SS_PAD1SIZE];
+                  /* 6 byte pad, this is to make implementation
+                  /* specific pad up to alignment field that */
+                  /* follows explicit in the data structure */
+    int64_t      __ss_align;  /* field to force desired structure */
+                  /* storage alignment */
+    char         __ss_pad2[_SS_PAD2SIZE];
+                  /* 112 byte pad to achieve desired size, */
+                  /* _SS_MAXSIZE value minus size of ss_len, */
+                  /* __ss_family, __ss_pad1, __ss_align fields is 112 */
+};
+
+   The above example implementation illustrates a data structure which
+   will align on a 64 bit boundary. An implementation specific field
+   "__ss_align" along "__ss_pad1" is used to force a 64-bit alignment
+   which covers proper alignment good enough for needs of sockaddr_in6
+   (IPv6), sockaddr_in (IPv4) address data structures.  The size of
+   padding fields __ss_pad1 depends on the chosen alignment boundary.
+   The size of padding field __ss_pad2 depends on the value of overall
+   size chosen for the total size of the structure. This size and
+   alignment are represented in the above example by implementation
+   specific (not required) constants _SS_MAXSIZE (chosen value 128) and
+   _SS_ALIGNMENT (with chosen value 8).  Constants _SS_PAD1SIZE (derived
+   value 6) and _SS_PAD2SIZE (derived value 112) are also for
+   illustration and not required.  The implementation specific
+   definitions and structure field names above start with an underscore
+   to denote implementation private namespace.  Portable code is not
+   expected to access or reference those fields or constants.
+
+   The sockaddr_storage structure solves the problem of declaring
+   storage for automatic variables which is large enough and aligned
+   enough for storing socket address data structure of any family. For
+   example, code with a file descriptor and without the context of the
+   address family can pass a pointer to a variable of this type where a
+   pointer to a socket address structure is expected in calls such as
+   getpeername() and determine the address family by accessing the
+   received content after the call.
+
+   The sockaddr_storage structure may also be useful and applied to
+   certain other interfaces where a generic socket address large enough
+   and aligned for use with multiple address families may be needed. A
+   discussion of those interfaces is outside the scope of this document.
+
+
+
+
+Gilligan, et. al.            Informational                     [Page 15]
+
+RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
+
+
+   Also, much existing code assumes that any socket address structure
+   can fit in a generic sockaddr structure.  While this has been true
+   for IPv4 socket address structures, it has always been false for Unix
+   domain socket address structures (but in practice this has not been a
+   problem) and it is also false for IPv6 socket address structures
+   (which can be a problem).
+
+   So now an application can do the following:
+
+      struct sockaddr_storage __ss;
+      struct sockaddr_in6 *sin6;
+      sin6 = (struct sockaddr_in6 *) &__ss;
+
+4. Interface Identification
+
+   This API uses an interface index (a small positive integer) to
+   identify the local interface on which a multicast group is joined
+   (Section 5.3).  Additionally, the advanced API [4] uses these same
+   interface indexes to identify the interface on which a datagram is
+   received, or to specify the interface on which a datagram is to be
+   sent.
+
+   Interfaces are normally known by names such as "le0", "sl1", "ppp2",
+   and the like.  On Berkeley-derived implementations, when an interface
+   is made known to the system, the kernel assigns a unique positive
+   integer value (called the interface index) to that interface.  These
+   are small positive integers that start at 1.  (Note that 0 is never
+   used for an interface index.) There may be gaps so that there is no
+   current interface for a particular positive interface index.
+
+   This API defines two functions that map between an interface name and
+   index, a third function that returns all the interface names and
+   indexes, and a fourth function to return the dynamic memory allocated
+   by the previous function.  How these functions are implemented is
+   left up to the implementation.  4.4BSD implementations can implement
+   these functions using the existing sysctl() function with the
+   NET_RT_IFLIST command.  Other implementations may wish to use ioctl()
+   for this purpose.
+
+4.1 Name-to-Index
+
+   The first function maps an interface name into its corresponding
+   index.
+
+      #include <net/if.h>
+
+      unsigned int  if_nametoindex(const char *ifname);
+
+
+
+
+Gilligan, et. al.            Informational                     [Page 16]
+
+RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
+
+
+   If the specified interface name does not exist, the return value is
+   0, and errno is set to ENXIO.  If there was a system error (such as
+   running out of memory), the return value is 0 and errno is set to the
+   proper value (e.g., ENOMEM).
+
+4.2 Index-to-Name
+
+   The second function maps an interface index into its corresponding
+   name.
+
+      #include <net/if.h>
+
+      char  *if_indextoname(unsigned int ifindex, char *ifname);
+
+   The ifname argument must point to a buffer of at least IF_NAMESIZE
+   bytes into which the interface name corresponding to the specified
+   index is returned.  (IF_NAMESIZE is also defined in <net/if.h> and
+   its value includes a terminating null byte at the end of the
+   interface name.) This pointer is also the return value of the
+   function.  If there is no interface corresponding to the specified
+   index, NULL is returned, and errno is set to ENXIO, if there was a
+   system error (such as running out of memory), if_indextoname returns
+   NULL and errno would be set to the proper value (e.g., ENOMEM).
+
+4.3 Return All Interface Names and Indexes
+
+   The if_nameindex structure holds the information about a single
+   interface and is defined as a result of including the <net/if.h>
+   header.
+
+      struct if_nameindex {
+        unsigned int   if_index;  /* 1, 2, ... */
+        char          *if_name;   /* null terminated name: "le0", ... */
+      };
+
+   The final function returns an array of if_nameindex structures, one
+   structure per interface.
+
+      struct if_nameindex  *if_nameindex(void);
+
+   The end of the array of structures is indicated by a structure with
+   an if_index of 0 and an if_name of NULL.  The function returns a NULL
+   pointer upon an error, and would set errno to the appropriate value.
+
+   The memory used for this array of structures along with the interface
+   names pointed to by the if_name members is obtained dynamically.
+   This memory is freed by the next function.
+
+
+
+
+Gilligan, et. al.            Informational                     [Page 17]
+
+RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
+
+
+4.4 Free Memory
+
+   The following function frees the dynamic memory that was allocated by
+   if_nameindex().
+
+      #include <net/if.h>
+
+      void  if_freenameindex(struct if_nameindex *ptr);
+
+   The argument to this function must be a pointer that was returned by
+   if_nameindex().
+
+   Currently net/if.h doesn't have prototype definitions for functions
+   and it is recommended that these definitions be defined in net/if.h
+   as well and the struct if_nameindex{}.
+
+5. Socket Options
+
+   A number of new socket options are defined for IPv6.  All of these
+   new options are at the IPPROTO_IPV6 level.  That is, the "level"
+   parameter in the getsockopt() and setsockopt() calls is IPPROTO_IPV6
+   when using these options.  The constant name prefix IPV6_ is used in
+   all of the new socket options.  This serves to clearly identify these
+   options as applying to IPv6.
+
+   The declaration for IPPROTO_IPV6, the new IPv6 socket options, and
+   related constants defined in this section are obtained by including
+   the header <netinet/in.h>.
+
+5.1 Unicast Hop Limit
+
+   A new setsockopt() option controls the hop limit used in outgoing
+   unicast IPv6 packets.  The name of this option is IPV6_UNICAST_HOPS,
+   and it is used at the IPPROTO_IPV6 layer.  The following example
+   illustrates how it is used:
+
+      int  hoplimit = 10;
+
+      if (setsockopt(s, IPPROTO_IPV6, IPV6_UNICAST_HOPS,
+                     (char *) &hoplimit, sizeof(hoplimit)) == -1)
+          perror("setsockopt IPV6_UNICAST_HOPS");
+
+   When the IPV6_UNICAST_HOPS option is set with setsockopt(), the
+   option value given is used as the hop limit for all subsequent
+   unicast packets sent via that socket.  If the option is not set, the
+   system selects a default value.  The integer hop limit value (called
+   x) is interpreted as follows:
+
+
+
+
+Gilligan, et. al.            Informational                     [Page 18]
+
+RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
+
+
+      x < -1:        return an error of EINVAL
+      x == -1:       use kernel default
+      0 <= x <= 255: use x
+      x >= 256:      return an error of EINVAL
+
+   The IPV6_UNICAST_HOPS option may be used with getsockopt() to
+   determine the hop limit value that the system will use for subsequent
+   unicast packets sent via that socket.  For example:
+
+      int  hoplimit;
+      size_t  len = sizeof(hoplimit);
+
+      if (getsockopt(s, IPPROTO_IPV6, IPV6_UNICAST_HOPS,
+                     (char *) &hoplimit, &len) == -1)
+          perror("getsockopt IPV6_UNICAST_HOPS");
+      else
+          printf("Using %d for hop limit.\n", hoplimit);
+
+5.2 Sending and Receiving Multicast Packets
+
+   IPv6 applications may send UDP multicast packets by simply specifying
+   an IPv6 multicast address in the address argument of the sendto()
+   function.
+
+   Three socket options at the IPPROTO_IPV6 layer control some of the
+   parameters for sending multicast packets.  Setting these options is
+   not required: applications may send multicast packets without using
+   these options.  The setsockopt() options for controlling the sending
+   of multicast packets are summarized below.  These three options can
+   also be used with getsockopt().
+
+      IPV6_MULTICAST_IF
+
+         Set the interface to use for outgoing multicast packets.  The
+         argument is the index of the interface to use.
+
+         Argument type: unsigned int
+
+      IPV6_MULTICAST_HOPS
+
+         Set the hop limit to use for outgoing multicast packets.  (Note
+         a separate option - IPV6_UNICAST_HOPS - is provided to set the
+         hop limit to use for outgoing unicast packets.)
+
+         The interpretation of the argument is the same as for the
+         IPV6_UNICAST_HOPS option:
+
+
+
+
+
+Gilligan, et. al.            Informational                     [Page 19]
+
+RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
+
+
+           x < -1:        return an error of EINVAL
+           x == -1:       use kernel default
+           0 <= x <= 255: use x
+           x >= 256:      return an error of EINVAL
+
+           If IPV6_MULTICAST_HOPS is not set, the default is 1
+           (same as IPv4 today)
+
+         Argument type: int
+
+      IPV6_MULTICAST_LOOP
+
+         If a multicast datagram is sent to a group to which the sending
+         host itself belongs (on the outgoing interface), a copy of the
+         datagram is looped back by the IP layer for local delivery if
+         this option is set to 1.  If this option is set to 0 a copy
+         is not looped back.  Other option values return an error of
+         EINVAL.
+
+         If IPV6_MULTICAST_LOOP is not set, the default is 1 (loopback;
+         same as IPv4 today).
+
+         Argument type: unsigned int
+
+   The reception of multicast packets is controlled by the two
+   setsockopt() options summarized below.  An error of EOPNOTSUPP is
+   returned if these two options are used with getsockopt().
+
+      IPV6_JOIN_GROUP
+
+         Join a multicast group on a specified local interface.  If the
+         interface index is specified as 0, the kernel chooses the local
+         interface.  For example, some kernels look up the multicast
+         group in the normal IPv6 routing table and using the resulting
+         interface.
+
+         Argument type: struct ipv6_mreq
+
+      IPV6_LEAVE_GROUP
+
+         Leave a multicast group on a specified interface.
+
+         Argument type: struct ipv6_mreq
+
+   The argument type of both of these options is the ipv6_mreq structure,
+   defined as a result of including the <netinet/in.h> header;
+
+
+
+
+
+Gilligan, et. al.            Informational                     [Page 20]
+
+RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
+
+
+   struct ipv6_mreq {
+       struct in6_addr ipv6mr_multiaddr; /* IPv6 multicast addr */
+       unsigned int    ipv6mr_interface; /* interface index */
+   };
+
+   Note that to receive multicast datagrams a process must join the
+   multicast group and bind the UDP port to which datagrams will be
+   sent.  Some processes also bind the multicast group address to the
+   socket, in addition to the port, to prevent other datagrams destined
+   to that same port from being delivered to the socket.
+
+6. Library Functions
+
+   New library functions are needed to perform a variety of operations
+   with IPv6 addresses.  Functions are needed to lookup IPv6 addresses
+   in the Domain Name System (DNS).  Both forward lookup (nodename-to-
+   address translation) and reverse lookup (address-to-nodename
+   translation) need to be supported.  Functions are also needed to
+   convert IPv6 addresses between their binary and textual form.
+
+   We note that the two existing functions, gethostbyname() and
+   gethostbyaddr(), are left as-is.  New functions are defined to handle
+   both IPv4 and IPv6 addresses.
+
+6.1 Nodename-to-Address Translation
+
+   The commonly used function gethostbyname() is inadequate for many
+   applications, first because it provides no way for the caller to
+   specify anything about the types of addresses desired (IPv4 only,
+   IPv6 only, IPv4-mapped IPv6 are OK, etc.), and second because many
+   implementations of this function are not thread safe.  RFC 2133
+   defined a function named gethostbyname2() but this function was also
+   inadequate, first because its use required setting a global option
+   (RES_USE_INET6) when IPv6 addresses were required, and second because
+   a flag argument is needed to provide the caller with additional
+   control over the types of addresses required.
+
+   The following function is new and must be thread safe:
+
+   #include <sys/socket.h>
+   #include <netdb.h>
+
+   struct hostent *getipnodebyname(const char *name, int af, int flags
+                                       int *error_num);
+
+   The name argument can be either a node name or a numeric address
+   string (i.e., a dotted-decimal IPv4 address or an IPv6 hex address).
+   The af argument specifies the address family, either AF_INET or
+
+
+
+Gilligan, et. al.            Informational                     [Page 21]
+
+RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
+
+
+   AF_INET6. The error_num value is returned to the caller, via a
+   pointer, with the appropriate error code in error_num, to support
+   thread safe error code returns.  error_num will be set to one of the
+   following values:
+
+      HOST_NOT_FOUND
+
+         No such host is known.
+
+      NO_ADDRESS
+
+         The server recognised the request and the name but no address is
+         available.  Another type of request to the name server for the
+         domain might return an answer.
+
+      NO_RECOVERY
+
+         An unexpected server failure occurred which cannot be recovered.
+
+      TRY_AGAIN
+
+         A temporary and possibly transient error occurred, such as a
+         failure of a server to respond.
+
+   The flags argument specifies the types of addresses that are searched
+   for, and the types of addresses that are returned.  We note that a
+   special flags value of AI_DEFAULT (defined below) should handle most
+   applications.
+
+   That is, porting simple applications to use IPv6 replaces the call
+
+      hptr = gethostbyname(name);
+
+   with
+
+      hptr = getipnodebyname(name, AF_INET6, AI_DEFAULT, &error_num);
+
+   and changes any subsequent error diagnosis code to use error_num
+   instead of externally declared variables, such as h_errno.
+
+   Applications desiring finer control over the types of addresses
+   searched for and returned, can specify other combinations of the
+   flags argument.
+
+
+
+
+
+
+
+
+Gilligan, et. al.            Informational                     [Page 22]
+
+RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
+
+
+   A flags of 0 implies a strict interpretation of the af argument:
+
+      - If flags is 0 and af is AF_INET, then the caller wants only
+        IPv4 addresses.  A query is made for A records.  If successful,
+        the IPv4 addresses are returned and the h_length member of the
+        hostent structure will be 4, else the function returns a NULL
+        pointer.
+
+      -  If flags is 0 and if af is AF_INET6, then the caller wants only
+        IPv6 addresses.  A query is made for AAAA records.  If
+        successful, the IPv6 addresses are returned and the h_length
+        member of the hostent structure will be 16, else the function
+        returns a NULL pointer.
+
+   Other constants can be logically-ORed into the flags argument, to
+   modify the behavior of the function.
+
+      - If the AI_V4MAPPED flag is specified along with an af of
+        AF_INET6, then the caller will accept IPv4-mapped IPv6
+        addresses.  That is, if no AAAA records are found then a query
+        is made for A records and any found are returned as IPv4-mapped
+        IPv6 addresses (h_length will be 16).  The AI_V4MAPPED flag is
+        ignored unless af equals AF_INET6.
+
+      - The AI_ALL flag is used in conjunction with the AI_V4MAPPED
+        flag, and is only used with the IPv6 address family.  When AI_ALL
+        is logically or'd with AI_V4MAPPED flag then the caller wants
+        all addresses: IPv6 and IPv4-mapped IPv6.  A query is first made
+        for AAAA records and if successful, the IPv6 addresses are
+        returned. Another query is then made for A records and any found
+        are returned as IPv4-mapped IPv6 addresses. h_length will be 16.
+        Only if both queries fail does the function return a NULL pointer.
+        This flag is ignored unless af equals AF_INET6.
+
+      - The AI_ADDRCONFIG flag specifies that a query for AAAA records
+        should occur only if the node has at least one IPv6 source
+        address configured and a query for A records should occur only
+        if the node has at least one IPv4 source address configured.
+
+        For example, if the node has no IPv6 source addresses
+        configured, and af equals AF_INET6, and the node name being
+        looked up has both AAAA and A records, then:
+
+            (a) if only AI_ADDRCONFIG is specified, the function
+                returns a NULL pointer;
+            (b) if AI_ADDRCONFIG | AI_V4MAPPED is specified, the A
+                records are returned as IPv4-mapped IPv6 addresses;
+
+
+
+
+Gilligan, et. al.            Informational                     [Page 23]
+
+RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
+
+
+   The special flags value of AI_DEFAULT is defined as
+
+      #define  AI_DEFAULT  (AI_V4MAPPED | AI_ADDRCONFIG)
+
+   We noted that the getipnodebyname() function must allow the name
+   argument to be either a node name or a literal address string (i.e.,
+   a dotted-decimal IPv4 address or an IPv6 hex address).  This saves
+   applications from having to call inet_pton() to handle literal
+   address strings.
+
+   There are four scenarios based on the type of literal address string
+   and the value of the af argument.
+
+   The two simple cases are:
+
+   When name is a dotted-decimal IPv4 address and af equals AF_INET, or
+   when name is an IPv6 hex address and af equals AF_INET6.  The members
+   of the returned hostent structure are: h_name points to a copy of the
+   name argument, h_aliases is a NULL pointer, h_addrtype is a copy of
+   the af argument, h_length is either 4 (for AF_INET) or 16 (for
+   AF_INET6), h_addr_list[0] is a pointer to the 4-byte or 16-byte
+   binary address, and h_addr_list[1] is a NULL pointer.
+
+   When name is a dotted-decimal IPv4 address and af equals AF_INET6,
+   and flags equals AI_V4MAPPED, an IPv4-mapped IPv6 address is
+   returned:  h_name points to an IPv6 hex address containing the IPv4-
+   mapped IPv6 address, h_aliases is a NULL pointer, h_addrtype is
+   AF_INET6, h_length is 16, h_addr_list[0] is a pointer to the 16-byte
+   binary address, and h_addr_list[1] is a NULL pointer.  If AI_V4MAPPED
+   is set (with or without AI_ALL) return IPv4-mapped otherwise return
+   NULL.
+
+   It is an error when name is an IPv6 hex address and af equals
+   AF_INET.  The function's return value is a NULL pointer and error_num
+   equals HOST_NOT_FOUND.
+
+6.2 Address-To-Nodename Translation
+
+   The following function has the same arguments as the existing
+   gethostbyaddr() function, but adds an error number.
+
+      #include <sys/socket.h> #include <netdb.h>
+
+      struct hostent *getipnodebyaddr(const void *src, size_t len,
+                                          int af, int *error_num);
+
+
+
+
+
+
+Gilligan, et. al.            Informational                     [Page 24]
+
+RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
+
+
+   As with getipnodebyname(), getipnodebyaddr() must be thread safe.
+   The error_num value is returned to the caller with the appropriate
+   error code, to support thread safe error code returns.  The following
+   error conditions may be returned for error_num:
+
+      HOST_NOT_FOUND
+
+         No such host is known.
+
+      NO_ADDRESS
+
+         The server recognized the request and the name but no address
+         is available.  Another type of request to the name server for
+         the domain might return an answer.
+
+      NO_RECOVERY
+
+         An unexpected server failure occurred which cannot be
+         recovered.
+
+      TRY_AGAIN
+
+         A temporary and possibly transient error occurred, such as a
+         failure of a server to respond.
+
+   One possible source of confusion is the handling of IPv4-mapped IPv6
+   addresses and IPv4-compatible IPv6 addresses, but the following logic
+   should apply.
+
+      1.  If af is AF_INET6, and if len equals 16, and if the IPv6
+          address is an IPv4-mapped IPv6 address or an IPv4-compatible
+          IPv6 address, then skip over the first 12 bytes of the IPv6
+          address, set af to AF_INET, and set len to 4.
+
+      2.  If af is AF_INET, lookup the name for the given IPv4 address
+          (e.g., query for a PTR record in the in-addr.arpa domain).
+
+      3.  If af is AF_INET6, lookup the name for the given IPv6 address
+          (e.g., query for a PTR record in the ip6.int domain).
+
+      4.  If the function is returning success, then the single address
+          that is returned in the hostent structure is a copy of the
+          first argument to the function with the same address family
+          that was passed as an argument to this function.
+
+
+
+
+
+
+
+Gilligan, et. al.            Informational                     [Page 25]
+
+RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
+
+
+   All four steps listed are performed, in order.  Also note that the
+   IPv6 hex addresses "::" and "::1" MUST NOT be treated as IPv4-
+   compatible addresses, and if the address is "::", HOST_NOT_FOUND MUST
+   be returned and a query of the address not performed.
+
+   Also for the macro in section 6.7 IN6_IS_ADDR_V4COMPAT MUST return
+   false for "::" and "::1".
+
+6.3 Freeing memory for getipnodebyname and getipnodebyaddr
+
+   The hostent structure does not change from its existing definition.
+   This structure, and the information pointed to by this structure, are
+   dynamically allocated by getipnodebyname and getipnodebyaddr.  The
+   following function frees this memory:
+
+      #include <netdb.h>
+
+      void freehostent(struct hostent *ptr);
+
+6.4 Protocol-Independent Nodename and Service Name Translation
+
+   Nodename-to-address translation is done in a protocol-independent
+   fashion using the getaddrinfo() function that is taken from the
+   Institute of Electrical and Electronic Engineers (IEEE) POSIX 1003.1g
+   (Protocol Independent Interfaces) draft specification [3].
+
+   The official specification for this function will be the final POSIX
+   standard, with the following additional requirements:
+
+      -  getaddrinfo() (along with the getnameinfo() function described
+         in the next section) must be thread safe.
+
+      -  The AI_NUMERICHOST is new with this document.
+
+      -  All fields in socket address structures returned by
+         getaddrinfo() that are not filled in through an explicit
+         argument (e.g., sin6_flowinfo and sin_zero) must be set to 0.
+         (This makes it easier to compare socket address structures.)
+
+      -  getaddrinfo() must fill in the length field of a socket address
+         structure (e.g., sin6_len) on systems that support this field.
+
+   We are providing this independent description of the function because
+   POSIX standards are not freely available (as are IETF documents).
+
+      #include <sys/socket.h>
+      #include <netdb.h>
+
+
+
+
+Gilligan, et. al.            Informational                     [Page 26]
+
+RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
+
+
+      int getaddrinfo(const char *nodename, const char *servname,
+                      const struct addrinfo *hints,
+                      struct addrinfo **res);
+
+   The addrinfo structure is defined as a result of including the
+   <netdb.h> header.
+
+  struct addrinfo {
+    int     ai_flags;     /* AI_PASSIVE, AI_CANONNAME, AI_NUMERICHOST */
+    int     ai_family;    /* PF_xxx */
+    int     ai_socktype;  /* SOCK_xxx */
+    int     ai_protocol;  /* 0 or IPPROTO_xxx for IPv4 and IPv6 */
+    size_t  ai_addrlen;   /* length of ai_addr */
+    char   *ai_canonname; /* canonical name for nodename */
+    struct sockaddr  *ai_addr; /* binary address */
+    struct addrinfo  *ai_next; /* next structure in linked list */
+  };
+
+   The return value from the function is 0 upon success or a nonzero
+   error code.  The following names are the nonzero error codes from
+   getaddrinfo(), and are defined in <netdb.h>:
+
+      EAI_ADDRFAMILY  address family for nodename not supported
+      EAI_AGAIN       temporary failure in name resolution
+      EAI_BADFLAGS    invalid value for ai_flags
+      EAI_FAIL        non-recoverable failure in name resolution
+      EAI_FAMILY      ai_family not supported
+      EAI_MEMORY      memory allocation failure
+      EAI_NODATA      no address associated with nodename
+      EAI_NONAME      nodename nor servname provided, or not known
+      EAI_SERVICE     servname not supported for ai_socktype
+      EAI_SOCKTYPE    ai_socktype not supported
+      EAI_SYSTEM      system error returned in errno
+
+   The nodename and servname arguments are pointers to null-terminated
+   strings or NULL.  One or both of these two arguments must be a non-
+   NULL pointer.  In the normal client scenario, both the nodename and
+   servname are specified.  In the normal server scenario, only the
+   servname is specified.  A non-NULL nodename string can be either a
+   node name or a numeric host address string (i.e., a dotted-decimal
+   IPv4 address or an IPv6 hex address).  A non-NULL servname string can
+   be either a service name or a decimal port number.
+
+   The caller can optionally pass an addrinfo structure, pointed to by
+   the third argument, to provide hints concerning the type of socket
+   that the caller supports.  In this hints structure all members other
+   than ai_flags, ai_family, ai_socktype, and ai_protocol must be zero
+   or a NULL pointer.  A value of PF_UNSPEC for ai_family means the
+
+
+
+Gilligan, et. al.            Informational                     [Page 27]
+
+RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
+
+
+   caller will accept any protocol family.  A value of 0 for ai_socktype
+   means the caller will accept any socket type.  A value of 0 for
+   ai_protocol means the caller will accept any protocol.  For example,
+   if the caller handles only TCP and not UDP, then the ai_socktype
+   member of the hints structure should be set to SOCK_STREAM when
+   getaddrinfo() is called.  If the caller handles only IPv4 and not
+   IPv6, then the ai_family member of the hints structure should be set
+   to PF_INET when getaddrinfo() is called.  If the third argument to
+   getaddrinfo() is a NULL pointer, this is the same as if the caller
+   had filled in an addrinfo structure initialized to zero with
+   ai_family set to PF_UNSPEC.
+
+   Upon successful return a pointer to a linked list of one or more
+   addrinfo structures is returned through the final argument.  The
+   caller can process each addrinfo structure in this list by following
+   the ai_next pointer, until a NULL pointer is encountered.  In each
+   returned addrinfo structure the three members ai_family, ai_socktype,
+   and ai_protocol are the corresponding arguments for a call to the
+   socket() function.  In each addrinfo structure the ai_addr member
+   points to a filled-in socket address structure whose length is
+   specified by the ai_addrlen member.
+
+   If the AI_PASSIVE bit is set in the ai_flags member of the hints
+   structure, then the caller plans to use the returned socket address
+   structure in a call to bind().  In this case, if the nodename
+   argument is a NULL pointer, then the IP address portion of the socket
+   address structure will be set to INADDR_ANY for an IPv4 address or
+   IN6ADDR_ANY_INIT for an IPv6 address.
+
+   If the AI_PASSIVE bit is not set in the ai_flags member of the hints
+   structure, then the returned socket address structure will be ready
+   for a call to connect() (for a connection-oriented protocol) or
+   either connect(), sendto(), or sendmsg() (for a connectionless
+   protocol).  In this case, if the nodename argument is a NULL pointer,
+   then the IP address portion of the socket address structure will be
+   set to the loopback address.
+
+   If the AI_CANONNAME bit is set in the ai_flags member of the hints
+   structure, then upon successful return the ai_canonname member of the
+   first addrinfo structure in the linked list will point to a null-
+   terminated string containing the canonical name of the specified
+   nodename.
+
+   If the AI_NUMERICHOST bit is set in the ai_flags member of the hints
+   structure, then a non-NULL nodename string must be a numeric host
+   address string.  Otherwise an error of EAI_NONAME is returned.  This
+   flag prevents any type of name resolution service (e.g., the DNS)
+   from being called.
+
+
+
+Gilligan, et. al.            Informational                     [Page 28]
+
+RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
+
+
+   All of the information returned by getaddrinfo() is dynamically
+   allocated: the addrinfo structures, and the socket address structures
+   and canonical node name strings pointed to by the addrinfo
+   structures.  To return this information to the system the function
+   freeaddrinfo() is called:
+
+      #include <sys/socket.h> #include <netdb.h>
+
+      void freeaddrinfo(struct addrinfo *ai);
+
+   The addrinfo structure pointed to by the ai argument is freed, along
+   with any dynamic storage pointed to by the structure.  This operation
+   is repeated until a NULL ai_next pointer is encountered.
+
+   To aid applications in printing error messages based on the EAI_xxx
+   codes returned by getaddrinfo(), the following function is defined.
+
+      #include <sys/socket.h> #include <netdb.h>
+
+      char *gai_strerror(int ecode);
+
+   The argument is one of the EAI_xxx values defined earlier and the
+   return value points to a string describing the error.  If the
+   argument is not one of the EAI_xxx values, the function still returns
+   a pointer to a string whose contents indicate an unknown error.
+
+6.5 Socket Address Structure to Nodename and Service Name
+
+   The POSIX 1003.1g specification includes no function to perform the
+   reverse conversion from getaddrinfo(): to look up a nodename and
+   service name, given the binary address and port.  Therefore, we
+   define the following function:
+
+      #include <sys/socket.h>
+      #include <netdb.h>
+
+      int getnameinfo(const struct sockaddr *sa, socklen_t salen,
+                      char *host, size_t hostlen,
+                      char *serv, size_t servlen,
+                      int flags);
+
+   This function looks up an IP address and port number provided by the
+   caller in the DNS and system-specific database, and returns text
+   strings for both in buffers provided by the caller.  The function
+   indicates successful completion by a zero return value; a non-zero
+   return value indicates failure.
+
+
+
+
+
+Gilligan, et. al.            Informational                     [Page 29]
+
+RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
+
+
+   The first argument, sa, points to either a sockaddr_in structure (for
+   IPv4) or a sockaddr_in6 structure (for IPv6) that holds the IP
+   address and port number.  The salen argument gives the length of the
+   sockaddr_in or sockaddr_in6 structure.
+
+   The function returns the nodename associated with the IP address in
+   the buffer pointed to by the host argument.  The caller provides the
+   size of this buffer via the hostlen argument.  The service name
+   associated with the port number is returned in the buffer pointed to
+   by serv, and the servlen argument gives the length of this buffer.
+   The caller specifies not to return either string by providing a zero
+   value for the hostlen or servlen arguments.  Otherwise, the caller
+   must provide buffers large enough to hold the nodename and the
+   service name, including the terminating null characters.
+
+   Unfortunately most systems do not provide constants that specify the
+   maximum size of either a fully-qualified domain name or a service
+   name.  Therefore to aid the application in allocating buffers for
+   these two returned strings the following constants are defined in
+   <netdb.h>:
+
+      #define NI_MAXHOST  1025
+      #define NI_MAXSERV    32
+
+   The first value is actually defined as the constant MAXDNAME in recent
+   versions of BIND's <arpa/nameser.h> header (older versions of BIND
+   define this constant to be 256) and the second is a guess based on the
+   services listed in the current Assigned Numbers RFC.
+
+   The final argument is a flag that changes the default actions of this
+   function.  By default the fully-qualified domain name (FQDN) for the
+   host is looked up in the DNS and returned.  If the flag bit NI_NOFQDN
+   is set, only the nodename portion of the FQDN is returned for local
+   hosts.
+
+   If the flag bit NI_NUMERICHOST is set, or if the host's name cannot be
+   located in the DNS, the numeric form of the host's address is returned
+   instead of its name (e.g., by calling inet_ntop() instead of
+   getipnodebyaddr()).  If the flag bit NI_NAMEREQD is set, an error is
+   returned if the host's name cannot be located in the DNS.
+
+   If the flag bit NI_NUMERICSERV is set, the numeric form of the service
+   address is returned (e.g., its port number) instead of its name.  The
+   two NI_NUMERICxxx flags are required to support the "-n" flag that
+   many commands provide.
+
+
+
+
+
+
+Gilligan, et. al.            Informational                     [Page 30]
+
+RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
+
+
+   A fifth flag bit, NI_DGRAM, specifies that the service is a datagram
+   service, and causes getservbyport() to be called with a second
+   argument of "udp" instead of its default of "tcp".  This is required
+   for the few ports (e.g. 512-514) that have different services for UDP
+   and TCP.
+
+   These NI_xxx flags are defined in <netdb.h> along with the AI_xxx
+   flags already defined for getaddrinfo().
+
+6.6 Address Conversion Functions
+
+   The two functions inet_addr() and inet_ntoa() convert an IPv4 address
+   between binary and text form.  IPv6 applications need similar
+   functions.  The following two functions convert both IPv6 and IPv4
+   addresses:
+
+      #include <sys/socket.h>
+      #include <arpa/inet.h>
+
+      int inet_pton(int af, const char *src, void *dst);
+
+      const char *inet_ntop(int af, const void *src,
+                            char *dst, size_t size);
+
+   The inet_pton() function converts an address in its standard text
+   presentation form into its numeric binary form.  The af argument
+   specifies the family of the address.  Currently the AF_INET and
+   AF_INET6 address families are supported.  The src argument points to
+   the string being passed in.  The dst argument points to a buffer into
+   which the function stores the numeric address.  The address is
+   returned in network byte order.  Inet_pton() returns 1 if the
+   conversion succeeds, 0 if the input is not a valid IPv4 dotted-
+   decimal string or a valid IPv6 address string, or -1 with errno set
+   to EAFNOSUPPORT if the af argument is unknown.  The calling
+   application must ensure that the buffer referred to by dst is large
+   enough to hold the numeric address (e.g., 4 bytes for AF_INET or 16
+   bytes for AF_INET6).
+
+   If the af argument is AF_INET, the function accepts a string in the
+   standard IPv4 dotted-decimal form:
+
+      ddd.ddd.ddd.ddd
+
+   where ddd is a one to three digit decimal number between 0 and 255.
+   Note that many implementations of the existing inet_addr() and
+   inet_aton() functions accept nonstandard input: octal numbers,
+   hexadecimal numbers, and fewer than four numbers.  inet_pton() does
+   not accept these formats.
+
+
+
+Gilligan, et. al.            Informational                     [Page 31]
+
+RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
+
+
+   If the af argument is AF_INET6, then the function accepts a string in
+   one of the standard IPv6 text forms defined in Section 2.2 of the
+   addressing architecture specification [2].
+
+   The inet_ntop() function converts a numeric address into a text
+   string suitable for presentation.  The af argument specifies the
+   family of the address.  This can be AF_INET or AF_INET6.  The src
+   argument points to a buffer holding an IPv4 address if the af
+   argument is AF_INET, or an IPv6 address if the af argument is
+   AF_INET6, the address must be in network byte order.  The dst
+   argument points to a buffer where the function will store the
+   resulting text string.  The size argument specifies the size of this
+   buffer.  The application must specify a non-NULL dst argument.  For
+   IPv6 addresses, the buffer must be at least 46-octets.  For IPv4
+   addresses, the buffer must be at least 16-octets.  In order to allow
+   applications to easily declare buffers of the proper size to store
+   IPv4 and IPv6 addresses in string form, the following two constants
+   are defined in <netinet/in.h>:
+
+      #define INET_ADDRSTRLEN    16
+      #define INET6_ADDRSTRLEN   46
+
+   The inet_ntop() function returns a pointer to the buffer containing
+   the text string if the conversion succeeds, and NULL otherwise.  Upon
+   failure, errno is set to EAFNOSUPPORT if the af argument is invalid or
+   ENOSPC if the size of the result buffer is inadequate.
+
+6.7 Address Testing Macros
+
+   The following macros can be used to test for special IPv6 addresses.
+
+      #include <netinet/in.h>
+
+      int  IN6_IS_ADDR_UNSPECIFIED (const struct in6_addr *);
+      int  IN6_IS_ADDR_LOOPBACK    (const struct in6_addr *);
+      int  IN6_IS_ADDR_MULTICAST   (const struct in6_addr *);
+      int  IN6_IS_ADDR_LINKLOCAL   (const struct in6_addr *);
+      int  IN6_IS_ADDR_SITELOCAL   (const struct in6_addr *);
+      int  IN6_IS_ADDR_V4MAPPED    (const struct in6_addr *);
+      int  IN6_IS_ADDR_V4COMPAT    (const struct in6_addr *);
+
+      int  IN6_IS_ADDR_MC_NODELOCAL(const struct in6_addr *);
+      int  IN6_IS_ADDR_MC_LINKLOCAL(const struct in6_addr *);
+      int  IN6_IS_ADDR_MC_SITELOCAL(const struct in6_addr *);
+      int  IN6_IS_ADDR_MC_ORGLOCAL (const struct in6_addr *);
+      int  IN6_IS_ADDR_MC_GLOBAL   (const struct in6_addr *);
+
+
+
+
+
+Gilligan, et. al.            Informational                     [Page 32]
+
+RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
+
+
+   The first seven macros return true if the address is of the specified
+   type, or false otherwise.  The last five test the scope of a
+   multicast address and return true if the address is a multicast
+   address of the specified scope or false if the address is either not
+   a multicast address or not of the specified scope.  Note that
+   IN6_IS_ADDR_LINKLOCAL and IN6_IS_ADDR_SITELOCAL return true only for
+   the two local-use IPv6 unicast addresses.  These two macros do not
+   return true for IPv6 multicast addresses of either link-local scope
+   or site-local scope.
+
+7. Summary of New Definitions
+
+   The following list summarizes the constants, structure, and extern
+   definitions discussed in this memo, sorted by header.
+
+      <net/if.h>      IF_NAMESIZE
+      <net/if.h>      struct if_nameindex{};
+
+      <netdb.h>       AI_ADDRCONFIG
+      <netdb.h>       AI_DEFAULT
+      <netdb.h>       AI_ALL
+      <netdb.h>       AI_CANONNAME
+      <netdb.h>       AI_NUMERICHOST
+      <netdb.h>       AI_PASSIVE
+      <netdb.h>       AI_V4MAPPED
+      <netdb.h>       EAI_ADDRFAMILY
+      <netdb.h>       EAI_AGAIN
+      <netdb.h>       EAI_BADFLAGS
+      <netdb.h>       EAI_FAIL
+      <netdb.h>       EAI_FAMILY
+      <netdb.h>       EAI_MEMORY
+      <netdb.h>       EAI_NODATA
+      <netdb.h>       EAI_NONAME
+      <netdb.h>       EAI_SERVICE
+      <netdb.h>       EAI_SOCKTYPE
+      <netdb.h>       EAI_SYSTEM
+      <netdb.h>       NI_DGRAM
+      <netdb.h>       NI_MAXHOST
+      <netdb.h>       NI_MAXSERV
+      <netdb.h>       NI_NAMEREQD
+      <netdb.h>       NI_NOFQDN
+      <netdb.h>       NI_NUMERICHOST
+      <netdb.h>       NI_NUMERICSERV
+      <netdb.h>       struct addrinfo{};
+
+      <netinet/in.h>  IN6ADDR_ANY_INIT
+      <netinet/in.h>  IN6ADDR_LOOPBACK_INIT
+      <netinet/in.h>  INET6_ADDRSTRLEN
+
+
+
+Gilligan, et. al.            Informational                     [Page 33]
+
+RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
+
+
+      <netinet/in.h>  INET_ADDRSTRLEN
+      <netinet/in.h>  IPPROTO_IPV6
+      <netinet/in.h>  IPV6_JOIN_GROUP
+      <netinet/in.h>  IPV6_LEAVE_GROUP
+      <netinet/in.h>  IPV6_MULTICAST_HOPS
+      <netinet/in.h>  IPV6_MULTICAST_IF
+      <netinet/in.h>  IPV6_MULTICAST_LOOP
+      <netinet/in.h>  IPV6_UNICAST_HOPS
+      <netinet/in.h>  SIN6_LEN
+      <netinet/in.h>  extern const struct in6_addr in6addr_any;
+      <netinet/in.h>  extern const struct in6_addr in6addr_loopback;
+      <netinet/in.h>  struct in6_addr{};
+      <netinet/in.h>  struct ipv6_mreq{};
+      <netinet/in.h>  struct sockaddr_in6{};
+
+      <sys/socket.h>  AF_INET6
+      <sys/socket.h>  PF_INET6
+      <sys/socket.h>  struct sockaddr_storage;
+
+   The following list summarizes the function and macro prototypes
+   discussed in this memo, sorted by header.
+
+<arpa/inet.h>   int inet_pton(int, const char *, void *);
+<arpa/inet.h>   const char *inet_ntop(int, const void *,
+                                      char *, size_t);
+
+<net/if.h>      char *if_indextoname(unsigned int, char *);
+<net/if.h>      unsigned int if_nametoindex(const char *);
+<net/if.h>      void if_freenameindex(struct if_nameindex *);
+<net/if.h>      struct if_nameindex *if_nameindex(void);
+
+<netdb.h>       int getaddrinfo(const char *, const char *,
+                                const struct addrinfo *,
+                                struct addrinfo **);
+<netdb.h>       int getnameinfo(const struct sockaddr *, socklen_t,
+                                char *, size_t, char *, size_t, int);
+<netdb.h>       void freeaddrinfo(struct addrinfo *);
+<netdb.h>       char *gai_strerror(int);
+<netdb.h>       struct hostent *getipnodebyname(const char *, int, int,
+                                       int *);
+<netdb.h>       struct hostent *getipnodebyaddr(const void *, size_t,
+                                       int, int *);
+<netdb.h>       void freehostent(struct hostent *);
+
+<netinet/in.h>  int IN6_IS_ADDR_LINKLOCAL(const struct in6_addr *);
+<netinet/in.h>  int IN6_IS_ADDR_LOOPBACK(const struct in6_addr *);
+<netinet/in.h>  int IN6_IS_ADDR_MC_GLOBAL(const struct in6_addr *);
+<netinet/in.h>  int IN6_IS_ADDR_MC_LINKLOCAL(const struct in6_addr *);
+
+
+
+Gilligan, et. al.            Informational                     [Page 34]
+
+RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
+
+
+<netinet/in.h>  int IN6_IS_ADDR_MC_NODELOCAL(const struct in6_addr *);
+<netinet/in.h>  int IN6_IS_ADDR_MC_ORGLOCAL(const struct in6_addr *);
+<netinet/in.h>  int IN6_IS_ADDR_MC_SITELOCAL(const struct in6_addr *);
+<netinet/in.h>  int IN6_IS_ADDR_MULTICAST(const struct in6_addr *);
+<netinet/in.h>  int IN6_IS_ADDR_SITELOCAL(const struct in6_addr *);
+<netinet/in.h>  int IN6_IS_ADDR_UNSPECIFIED(const struct in6_addr *);
+<netinet/in.h>  int IN6_IS_ADDR_V4COMPAT(const struct in6_addr *);
+<netinet/in.h>  int IN6_IS_ADDR_V4MAPPED(const struct in6_addr *);
+
+8. Security Considerations
+
+   IPv6 provides a number of new security mechanisms, many of which need
+   to be accessible to applications.  Companion memos detailing the
+   extensions to the socket interfaces to support IPv6 security are
+   being written.
+
+9. Year 2000 Considerations
+
+   There are no issues for this memo concerning the Year 2000 issue
+   regarding the use of dates.
+
+Changes From RFC 2133
+
+   Changes made in the March 1998 Edition (-01 draft):
+
+      Changed all "hostname" to "nodename" for consistency with other
+      IPv6 documents.
+
+      Section 3.3: changed comment for sin6_flowinfo to be "traffic
+      class & flow info" and updated corresponding text description to
+      current definition of these two fields.
+
+      Section 3.10 ("Portability Additions") is new.
+
+      Section 6: a new paragraph was added reiterating that the existing
+      gethostbyname() and gethostbyaddr() are not changed.
+
+      Section 6.1: change gethostbyname3() to getnodebyname().  Add
+      AI_DEFAULT to handle majority of applications.  Renamed
+      AI_V6ADDRCONFIG to AI_ADDRCONFIG and define it for A records and
+      IPv4 addresses too.  Defined exactly what getnodebyname() must
+      return if the name argument is a numeric address string.
+
+      Section 6.2: change gethostbyaddr() to getnodebyaddr().  Reword
+      items 2 and 3 in the description of how to handle IPv4-mapped and
+      IPv4- compatible addresses to "lookup a name" for a given address,
+      instead of specifying what type of DNS query to issue.
+
+
+
+
+Gilligan, et. al.            Informational                     [Page 35]
+
+RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
+
+
+      Section 6.3: added two more requirements to getaddrinfo().
+
+      Section 7: added the following constants to the list for
+      <netdb.h>:  AI_ADDRCONFIG, AI_ALL, and AI_V4MAPPED.  Add union
+      sockaddr_union and SA_LEN to the lists for <sys/socket.h>.
+
+      Updated references.
+
+   Changes made in the November 1997 Edition (-00 draft):
+
+      The data types have been changed to conform with Draft 6.6 of the
+      Posix 1003.1g standard.
+
+      Section 3.2: data type of s6_addr changed to "uint8_t".
+
+      Section 3.3: data type of sin6_family changed to "sa_family_t".
+      data type of sin6_port changed to "in_port_t", data type of
+      sin6_flowinfo changed to "uint32_t".
+
+      Section 3.4: same as Section 3.3, plus data type of sin6_len
+      changed to "uint8_t".
+
+      Section 6.2: first argument of gethostbyaddr() changed from "const
+      char *" to "const void *" and second argument changed from "int"
+      to "size_t".
+
+      Section 6.4: second argument of getnameinfo() changed from
+      "size_t" to "socklen_t".
+
+      The wording was changed when new structures were defined, to be
+      more explicit as to which header must be included to define the
+      structure:
+
+      Section 3.2 (in6_addr{}), Section 3.3 (sockaddr_in6{}), Section
+      3.4 (sockaddr_in6{}), Section 4.3 (if_nameindex{}), Section 5.3
+      (ipv6_mreq{}), and Section 6.3 (addrinfo{}).
+
+      Section 4: NET_RT_LIST changed to NET_RT_IFLIST.
+
+      Section 5.1: The IPV6_ADDRFORM socket option was removed.
+
+      Section 5.3: Added a note that an option value other than 0 or 1
+      for IPV6_MULTICAST_LOOP returns an error.  Added a note that
+      IPV6_MULTICAST_IF, IPV6_MULTICAST_HOPS, and IPV6_MULTICAST_LOOP
+      can also be used with getsockopt(), but IPV6_ADD_MEMBERSHIP and
+      IPV6_DROP_MEMBERSHIP cannot be used with getsockopt().
+
+
+
+
+
+Gilligan, et. al.            Informational                     [Page 36]
+
+RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
+
+
+      Section 6.1: Removed the description of gethostbyname2() and its
+      associated RES_USE_INET6 option, replacing it with
+      gethostbyname3().
+
+      Section 6.2: Added requirement that gethostbyaddr() be thread
+      safe.  Reworded step 4 to avoid using the RES_USE_INET6 option.
+
+      Section 6.3: Added the requirement that getaddrinfo() and
+      getnameinfo() be thread safe.  Added the AI_NUMERICHOST flag.
+
+      Section 6.6: Added clarification about IN6_IS_ADDR_LINKLOCAL and
+      IN6_IS_ADDR_SITELOCAL macros.
+
+   Changes made to the draft -01 specification Sept 98
+
+      Changed priority to traffic class in the spec.
+
+      Added the need for scope identification in section 2.1.
+
+      Added sin6_scope_id to struct sockaddr_in6 in sections 3.3 and
+      3.4.
+
+      Changed 3.10 to use generic storage structure to support holding
+      IPv6 addresses and removed the SA_LEN macro.
+
+      Distinguished between invalid input parameters and system failures
+      for Interface Identification in Section 4.1 and 4.2.
+
+      Added defaults for multicast operations in section 5.2 and changed
+      the names from ADD to JOIN and DROP to LEAVE to be consistent with
+      IPv6 multicast terminology.
+
+      Changed getnodebyname to getipnodebyname, getnodebyaddr to
+      getipnodebyaddr, and added MT safe error code to function
+      parameters in section 6.
+
+      Moved freehostent to its own sub-section after getipnodebyaddr now
+      6.3 (so this bumps all remaining sections in section 6.
+
+      Clarified the use of AI_ALL and AI_V4MAPPED that these are
+      dependent on the AF parameter and must be used as a conjunction in
+      section 6.1.
+
+      Removed the restriction that literal addresses cannot be used with
+      a flags argument in section 6.1.
+
+      Added Year 2000 Section to the draft
+
+
+
+
+Gilligan, et. al.            Informational                     [Page 37]
+
+RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
+
+
+      Deleted Reference to the following because the attached is deleted
+      from the ID directory and has expired.  But the logic from the
+      aforementioned draft still applies, so that was kept in Section
+      6.2 bullets after 3rd paragraph.
+
+      [7]  P. Vixie, "Reverse Name Lookups of Encapsulated IPv4
+           Addresses in IPv6", Internet-Draft, <draft-vixie-ipng-
+           ipv4ptr-00.txt>, May 1996.
+
+      Deleted the following reference as it is no longer referenced.
+      And the draft has expired.
+
+      [3]  D. McDonald, "A Simple IP Security API Extension to BSD
+           Sockets", Internet-Draft, <draft-mcdonald-simple-ipsec-api-
+           01.txt>, March 1997.
+
+      Deleted the following reference as it is no longer referenced.
+
+      [4]  C. Metz, "Network Security API for Sockets",
+           Internet-Draft, <draft-metz-net-security-api-01.txt>, January
+           1998.
+
+      Update current references to current status.
+
+      Added alignment notes for in6_addr and sin6_addr.
+
+      Clarified further that AI_V4MAPPED must be used with a dotted IPv4
+      literal address for getipnodebyname(), when address family is
+      AF_INET6.
+
+      Added text to clarify "::" and "::1" when used by
+      getipnodebyaddr().
+
+Acknowledgments
+
+   Thanks to the many people who made suggestions and provided feedback
+   to this document, including: Werner Almesberger, Ran Atkinson, Fred
+   Baker, Dave Borman, Andrew Cherenson, Alex Conta, Alan Cox, Steve
+   Deering, Richard Draves, Francis Dupont, Robert Elz, Marc Hasson, Tom
+   Herbert, Bob Hinden, Wan-Yen Hsu, Christian Huitema, Koji Imada,
+   Markus Jork, Ron Lee, Alan Lloyd, Charles Lynn, Dan McDonald, Dave
+   Mitton, Thomas Narten, Josh Osborne, Craig Partridge, Jean-Luc
+   Richier, Erik Scoredos, Keith Sklower, Matt Thomas, Harvey Thompson,
+   Dean D. Throop, Karen Tracey, Glenn Trewitt, Paul Vixie, David
+   Waitzman, Carl Williams, and Kazu Yamamoto,
+
+
+
+
+
+
+Gilligan, et. al.            Informational                     [Page 38]
+
+RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
+
+
+   The getaddrinfo() and getnameinfo() functions are taken from an
+   earlier Internet Draft by Keith Sklower.  As noted in that draft,
+   William Durst, Steven Wise, Michael Karels, and Eric Allman provided
+   many useful discussions on the subject of protocol-independent name-
+   to-address translation, and reviewed early versions of Keith
+   Sklower's original proposal.  Eric Allman implemented the first
+   prototype of getaddrinfo().  The observation that specifying the pair
+   of name and service would suffice for connecting to a service
+   independent of protocol details was made by Marshall Rose in a
+   proposal to X/Open for a "Uniform Network Interface".
+
+   Craig Metz, Jack McCann, Erik Nordmark, Tim Hartrick, and Mukesh
+   Kacker made many contributions to this document.  Ramesh Govindan
+   made a number of contributions and co-authored an earlier version of
+   this memo.
+
+References
+
+   [1]  Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
+        Specification", RFC 2460, December 1998.
+
+   [2]  Hinden, R. and S. Deering, "IP Version 6 Addressing
+        Architecture", RFC 2373, July 1998.
+
+   [3]  IEEE, "Protocol Independent Interfaces", IEEE Std 1003.1g, DRAFT
+        6.6, March 1997.
+
+   [4]  Stevens, W. and M. Thomas, "Advanced Sockets API for IPv6", RFC
+        2292, February 1998.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gilligan, et. al.            Informational                     [Page 39]
+
+RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
+
+
+Authors' Addresses
+
+   Robert E. Gilligan
+   FreeGate Corporation
+   1208 E. Arques Ave.
+   Sunnyvale, CA 94086
+
+   Phone: +1 408 617 1004
+   EMail: gilligan@freegate.com
+
+
+   Susan Thomson
+   Bell Communications Research
+   MRE 2P-343, 445 South Street
+   Morristown, NJ 07960
+
+   Phone: +1 201 829 4514
+   EMail: set@thumper.bellcore.com
+
+
+   Jim Bound
+   Compaq Computer Corporation
+   110 Spitbrook Road ZK3-3/U14
+   Nashua, NH 03062-2698
+
+   Phone: +1 603 884 0400
+   EMail: bound@zk3.dec.com
+
+
+   W. Richard Stevens
+   1202 E. Paseo del Zorro
+   Tucson, AZ 85718-2826
+
+   Phone: +1 520 297 9416
+   EMail: rstevens@kohala.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gilligan, et. al.            Informational                     [Page 40]
+
+RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (1999).  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 Standards process must be
+   followed, or as required to translate it into 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gilligan, et. al.            Informational                     [Page 41]
+
diff --git a/doc/rfc/rfc2671.txt b/doc/rfc/rfc2671.txt
new file mode 100644
index 0000000..ec05f80
--- /dev/null
+++ b/doc/rfc/rfc2671.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+Network Working Group                                            P. Vixie
+Request for Comments: 2671                                            ISC
+Category: Standards Track                                     August 1999
+
+
+                  Extension Mechanisms for DNS (EDNS0)
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (1999).  All Rights Reserved.
+
+Abstract
+
+   The Domain Name System's wire protocol includes a number of fixed
+   fields whose range has been or soon will be exhausted and does not
+   allow clients to advertise their capabilities to servers.  This
+   document describes backward compatible mechanisms for allowing the
+   protocol to grow.
+
+1 - Rationale and Scope
+
+1.1. DNS (see [RFC1035]) specifies a Message Format and within such
+     messages there are standard formats for encoding options, errors,
+     and name compression.  The maximum allowable size of a DNS Message
+     is fixed.  Many of DNS's protocol limits are too small for uses
+     which are or which are desired to become common.  There is no way
+     for implementations to advertise their capabilities.
+
+1.2. Existing clients will not know how to interpret the protocol
+     extensions detailed here.  In practice, these clients will be
+     upgraded when they have need of a new feature, and only new
+     features will make use of the extensions.  We must however take
+     account of client behaviour in the face of extra fields, and design
+     a fallback scheme for interoperability with these clients.
+
+
+
+
+
+
+
+
+
+Vixie                       Standards Track                     [Page 1]
+
+RFC 2671          Extension Mechanisms for DNS (EDNS0)       August 1999
+
+
+2 - Affected Protocol Elements
+
+2.1. The DNS Message Header's (see [RFC1035 4.1.1]) second full 16-bit
+     word is divided into a 4-bit OPCODE, a 4-bit RCODE, and a number of
+     1-bit flags.  The original reserved Z bits have been allocated to
+     various purposes, and most of the RCODE values are now in use.
+     More flags and more possible RCODEs are needed.
+
+2.2. The first two bits of a wire format domain label are used to denote
+     the type of the label.  [RFC1035 4.1.4] allocates two of the four
+     possible types and reserves the other two.  Proposals for use of
+     the remaining types far outnumber those available.  More label
+     types are needed.
+
+2.3. DNS Messages are limited to 512 octets in size when sent over UDP.
+     While the minimum maximum reassembly buffer size still allows a
+     limit of 512 octets of UDP payload, most of the hosts now connected
+     to the Internet are able to reassemble larger datagrams.  Some
+     mechanism must be created to allow requestors to advertise larger
+     buffer sizes to responders.
+
+3 - Extended Label Types
+
+3.1. The "0 1" label type will now indicate an extended label type,
+     whose value is encoded in the lower six bits of the first octet of
+     a label.  All subsequently developed label types should be encoded
+     using an extended label type.
+
+3.2. The "1 1 1 1 1 1" extended label type will be reserved for future
+     expansion of the extended label type code space.
+
+4 - OPT pseudo-RR
+
+4.1. One OPT pseudo-RR can be added to the additional data section of
+     either a request or a response.  An OPT is called a pseudo-RR
+     because it pertains to a particular transport level message and not
+     to any actual DNS data.  OPT RRs shall never be cached, forwarded,
+     or stored in or loaded from master files.  The quantity of OPT
+     pseudo-RRs per message shall be either zero or one, but not
+     greater.
+
+4.2. An OPT RR has a fixed part and a variable set of options expressed
+     as {attribute, value} pairs.  The fixed part holds some DNS meta
+     data and also a small collection of new protocol elements which we
+     expect to be so popular that it would be a waste of wire space to
+     encode them as {attribute, value} pairs.
+
+
+
+
+
+Vixie                       Standards Track                     [Page 2]
+
+RFC 2671          Extension Mechanisms for DNS (EDNS0)       August 1999
+
+
+4.3. The fixed part of an OPT RR is structured as follows:
+
+     Field Name   Field Type     Description
+     ------------------------------------------------------
+     NAME         domain name    empty (root domain)
+     TYPE         u_int16_t      OPT
+     CLASS        u_int16_t      sender's UDP payload size
+     TTL          u_int32_t      extended RCODE and flags
+     RDLEN        u_int16_t      describes RDATA
+     RDATA        octet stream   {attribute,value} pairs
+
+4.4. The variable part of an OPT RR is encoded in its RDATA and is
+     structured as zero or more of the following:
+
+                +0 (MSB)                            +1 (LSB)
+     +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+  0: |                          OPTION-CODE                          |
+     +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+  2: |                         OPTION-LENGTH                         |
+     +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+  4: |                                                               |
+     /                          OPTION-DATA                          /
+     /                                                               /
+     +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+
+   OPTION-CODE    (Assigned by IANA.)
+
+   OPTION-LENGTH  Size (in octets) of OPTION-DATA.
+
+   OPTION-DATA    Varies per OPTION-CODE.
+
+4.5. The sender's UDP payload size (which OPT stores in the RR CLASS
+     field) is the number of octets of the largest UDP payload that can
+     be reassembled and delivered in the sender's network stack.  Note
+     that path MTU, with or without fragmentation, may be smaller than
+     this.
+
+4.5.1. Note that a 512-octet UDP payload requires a 576-octet IP
+       reassembly buffer.  Choosing 1280 on an Ethernet connected
+       requestor would be reasonable.  The consequence of choosing too
+       large a value may be an ICMP message from an intermediate
+       gateway, or even a silent drop of the response message.
+
+4.5.2. Both requestors and responders are advised to take account of the
+       path's discovered MTU (if already known) when considering message
+       sizes.
+
+
+
+
+
+Vixie                       Standards Track                     [Page 3]
+
+RFC 2671          Extension Mechanisms for DNS (EDNS0)       August 1999
+
+
+4.5.3. The requestor's maximum payload size can change over time, and
+       should therefore not be cached for use beyond the transaction in
+       which it is advertised.
+
+4.5.4. The responder's maximum payload size can change over time, but
+       can be reasonably expected to remain constant between two
+       sequential transactions; for example, a meaningless QUERY to
+       discover a responder's maximum UDP payload size, followed
+       immediately by an UPDATE which takes advantage of this size.
+       (This is considered preferrable to the outright use of TCP for
+       oversized requests, if there is any reason to suspect that the
+       responder implements EDNS, and if a request will not fit in the
+       default 512 payload size limit.)
+
+4.5.5. Due to transaction overhead, it is unwise to advertise an
+       architectural limit as a maximum UDP payload size.  Just because
+       your stack can reassemble 64KB datagrams, don't assume that you
+       want to spend more than about 4KB of state memory per ongoing
+       transaction.
+
+4.6. The extended RCODE and flags (which OPT stores in the RR TTL field)
+     are structured as follows:
+
+                 +0 (MSB)                            +1 (LSB)
+      +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+   0: |         EXTENDED-RCODE        |            VERSION            |
+      +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+   2: |                               Z                               |
+      +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+
+   EXTENDED-RCODE  Forms upper 8 bits of extended 12-bit RCODE.  Note
+                   that EXTENDED-RCODE value "0" indicates that an
+                   unextended RCODE is in use (values "0" through "15").
+
+   VERSION         Indicates the implementation level of whoever sets
+                   it.  Full conformance with this specification is
+                   indicated by version "0."  Requestors are encouraged
+                   to set this to the lowest implemented level capable
+                   of expressing a transaction, to minimize the
+                   responder and network load of discovering the
+                   greatest common implementation level between
+                   requestor and responder.  A requestor's version
+                   numbering strategy should ideally be a run time
+                   configuration option.
+
+                   If a responder does not implement the VERSION level
+                   of the request, then it answers with RCODE=BADVERS.
+                   All responses will be limited in format to the
+
+
+
+Vixie                       Standards Track                     [Page 4]
+
+RFC 2671          Extension Mechanisms for DNS (EDNS0)       August 1999
+
+
+                   VERSION level of the request, but the VERSION of each
+                   response will be the highest implementation level of
+                   the responder.  In this way a requestor will learn
+                   the implementation level of a responder as a side
+                   effect of every response, including error responses,
+                   including RCODE=BADVERS.
+
+   Z               Set to zero by senders and ignored by receivers,
+                   unless modified in a subsequent specification.
+
+5 - Transport Considerations
+
+5.1. The presence of an OPT pseudo-RR in a request should be taken as an
+     indication that the requestor fully implements the given version of
+     EDNS, and can correctly understand any response that conforms to
+     that feature's specification.
+
+5.2. Lack of use of these features in a request must be taken as an
+     indication that the requestor does not implement any part of this
+     specification and that the responder may make no use of any
+     protocol extension described here in its response.
+
+5.3. Responders who do not understand these protocol extensions are
+     expected to send a response with RCODE NOTIMPL, FORMERR, or
+     SERVFAIL.  Therefore use of extensions should be "probed" such that
+     a responder who isn't known to support them be allowed a retry with
+     no extensions if it responds with such an RCODE.  If a responder's
+     capability level is cached by a requestor, a new probe should be
+     sent periodically to test for changes to responder capability.
+
+6 - Security Considerations
+
+     Requestor-side specification of the maximum buffer size may open a
+     new DNS denial of service attack if responders can be made to send
+     messages which are too large for intermediate gateways to forward,
+     thus leading to potential ICMP storms between gateways and
+     responders.
+
+7 - IANA Considerations
+
+     The IANA has assigned RR type code 41 for OPT.
+
+     It is the recommendation of this document and its working group
+     that IANA create a registry for EDNS Extended Label Types, for EDNS
+     Option Codes, and for EDNS Version Numbers.
+
+     This document assigns label type 0b01xxxxxx as "EDNS Extended Label
+     Type."  We request that IANA record this assignment.
+
+
+
+Vixie                       Standards Track                     [Page 5]
+
+RFC 2671          Extension Mechanisms for DNS (EDNS0)       August 1999
+
+
+     This document assigns extended label type 0bxx111111 as "Reserved
+     for future extended label types."  We request that IANA record this
+     assignment.
+
+     This document assigns option code 65535 to "Reserved for future
+     expansion."
+
+     This document expands the RCODE space from 4 bits to 12 bits.  This
+     will allow IANA to assign more than the 16 distinct RCODE values
+     allowed in [RFC1035].
+
+     This document assigns EDNS Extended RCODE "16" to "BADVERS".
+
+     IESG approval should be required to create new entries in the EDNS
+     Extended Label Type or EDNS Version Number registries, while any
+     published RFC (including Informational, Experimental, or BCP)
+     should be grounds for allocation of an EDNS Option Code.
+
+8 - Acknowledgements
+
+     Paul Mockapetris, Mark Andrews, Robert Elz, Don Lewis, Bob Halley,
+     Donald Eastlake, Rob Austein, Matt Crawford, Randy Bush, and Thomas
+     Narten were each instrumental in creating and refining this
+     specification.
+
+9 - References
+
+    [RFC1035]  Mockapetris, P., "Domain Names - Implementation and
+               Specification", STD 13, RFC 1035, November 1987.
+
+10 - Author's Address
+
+   Paul Vixie
+   Internet Software Consortium
+   950 Charter Street
+   Redwood City, CA 94063
+
+   Phone: +1 650 779 7001
+   EMail: vixie@isc.org
+
+
+
+
+
+
+
+
+
+
+
+
+Vixie                       Standards Track                     [Page 6]
+
+RFC 2671          Extension Mechanisms for DNS (EDNS0)       August 1999
+
+
+11 - Full Copyright Statement
+
+   Copyright (C) The Internet Society (1999).  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 Standards process must be
+   followed, or as required to translate it into 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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Vixie                       Standards Track                     [Page 7]
+
diff --git a/doc/rfc/rfc2672.txt b/doc/rfc/rfc2672.txt
new file mode 100644
index 0000000..1103016
--- /dev/null
+++ b/doc/rfc/rfc2672.txt
@@ -0,0 +1,507 @@
+
+
+
+
+
+
+Network Working Group                                        M. Crawford
+Request for Comments: 2672                                      Fermilab
+Category: Standards Track                                    August 1999
+
+
+                   Non-Terminal DNS Name Redirection
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (1999).  All Rights Reserved.
+
+1.  Introduction
+
+   This document defines a new DNS Resource Record called "DNAME", which
+   provides the capability to map an entire subtree of the DNS name
+   space to another domain.  It differs from the CNAME record which maps
+   a single node of the name space.
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [KWORD].
+
+2.  Motivation
+
+   This Resource Record and its processing rules were conceived as a
+   solution to the problem of maintaining address-to-name mappings in a
+   context of network renumbering.  Without the DNAME mechanism, an
+   authoritative DNS server for the address-to-name mappings of some
+   network must be reconfigured when that network is renumbered.  With
+   DNAME, the zone can be constructed so that it needs no modification
+   when renumbered.  DNAME can also be useful in other situations, such
+   as when an organizational unit is renamed.
+
+3. The DNAME Resource Record
+
+   The DNAME RR has mnemonic DNAME and type code 39 (decimal).
+
+
+
+
+
+
+
+Crawford                    Standards Track                     [Page 1]
+
+RFC 2672           Non-Terminal DNS Name Redirection         August 1999
+
+
+   DNAME has the following format:
+
+      <owner> <ttl> <class> DNAME <target>
+
+   The format is not class-sensitive.  All fields are required.  The
+   RDATA field <target> is a <domain-name> [DNSIS].
+
+   The DNAME RR causes type NS additional section processing.
+
+   The effect of the DNAME record is the substitution of the record's
+   <target> for its <owner> as a suffix of a domain name.  A "no-
+   descendants" limitation governs the use of DNAMEs in a zone file:
+
+      If a DNAME RR is present at a node N, there may be other data at N
+      (except a CNAME or another DNAME), but there MUST be no data at
+      any descendant of N.  This restriction applies only to records of
+      the same class as the DNAME record.
+
+   This rule assures predictable results when a DNAME record is cached
+   by a server which is not authoritative for the record's zone.  It
+   MUST be enforced when authoritative zone data is loaded.  Together
+   with the rules for DNS zone authority [DNSCLR] it implies that DNAME
+   and NS records can only coexist at the top of a zone which has only
+   one node.
+
+   The compression scheme of [DNSIS] MUST NOT be applied to the RDATA
+   portion of a DNAME record unless the sending server has some way of
+   knowing that the receiver understands the DNAME record format.
+   Signalling such understanding is expected to be the subject of future
+   DNS Extensions.
+
+   Naming loops can be created with DNAME records or a combination of
+   DNAME and CNAME records, just as they can with CNAME records alone.
+   Resolvers, including resolvers embedded in DNS servers, MUST limit
+   the resources they devote to any query.  Implementors should note,
+   however, that fairly lengthy chains of DNAME records may be valid.
+
+4.  Query Processing
+
+   To exploit the DNAME mechanism the name resolution algorithms [DNSCF]
+   must be modified slightly for both servers and resolvers.
+
+   Both modified algorithms incorporate the operation of making a
+   substitution on a name (either QNAME or SNAME) under control of a
+   DNAME record.  This operation will be referred to as "the DNAME
+   substitution".
+
+
+
+
+
+Crawford                    Standards Track                     [Page 2]
+
+RFC 2672           Non-Terminal DNS Name Redirection         August 1999
+
+
+4.1.  Processing by Servers
+
+   For a server performing non-recursive service steps 3.c and 4 of
+   section 4.3.2 [DNSCF] are changed to check for a DNAME record before
+   checking for a wildcard ("*") label, and to return certain DNAME
+   records from zone data and the cache.
+
+   DNS clients sending Extended DNS [EDNS0] queries with Version 0 or
+   non-extended queries are presumed not to understand the semantics of
+   the DNAME record, so a server which implements this specification,
+   when answering a non-extended query, SHOULD synthesize a CNAME record
+   for each DNAME record encountered during query processing to help the
+   client reach the correct DNS data.  The behavior of clients and
+   servers under Extended DNS versions greater than 0 will be specified
+   when those versions are defined.
+
+   The synthesized CNAME RR, if provided, MUST have
+
+      The same CLASS as the QCLASS of the query,
+
+      TTL equal to zero,
+
+      An <owner> equal to the QNAME in effect at the moment the DNAME RR
+      was encountered, and
+
+      An RDATA field containing the new QNAME formed by the action of
+      the DNAME substitution.
+
+   If the server has the appropriate key on-line [DNSSEC, SECDYN], it
+   MAY generate and return a SIG RR for the synthesized CNAME RR.
+
+   The revised server algorithm is:
+
+   1. Set or clear the value of recursion available in the response
+      depending on whether the name server is willing to provide
+      recursive service.  If recursive service is available and
+      requested via the RD bit in the query, go to step 5, otherwise
+      step 2.
+
+   2. Search the available zones for the zone which is the nearest
+      ancestor to QNAME.  If such a zone is found, go to step 3,
+      otherwise step 4.
+
+   3. Start matching down, label by label, in the zone.  The matching
+      process can terminate several ways:
+
+
+
+
+
+
+Crawford                    Standards Track                     [Page 3]
+
+RFC 2672           Non-Terminal DNS Name Redirection         August 1999
+
+
+      a. If the whole of QNAME is matched, we have found the node.
+
+         If the data at the node is a CNAME, and QTYPE doesn't match
+         CNAME, copy the CNAME RR into the answer section of the
+         response, change QNAME to the canonical name in the CNAME RR,
+         and go back to step 1.
+
+         Otherwise, copy all RRs which match QTYPE into the answer
+         section and go to step 6.
+
+      b. If a match would take us out of the authoritative data, we have
+         a referral.  This happens when we encounter a node with NS RRs
+         marking cuts along the bottom of a zone.
+
+         Copy the NS RRs for the subzone into the authority section of
+         the reply.  Put whatever addresses are available into the
+         additional section, using glue RRs if the addresses are not
+         available from authoritative data or the cache.  Go to step 4.
+
+      c. If at some label, a match is impossible (i.e., the
+         corresponding label does not exist), look to see whether the
+         last label matched has a DNAME record.
+
+         If a DNAME record exists at that point, copy that record into
+         the answer section.  If substitution of its <target> for its
+         <owner> in QNAME would overflow the legal size for a <domain-
+         name>, set RCODE to YXDOMAIN [DNSUPD] and exit; otherwise
+         perform the substitution and continue.  If the query was not
+         extended [EDNS0] with a Version indicating understanding of the
+         DNAME record, the server SHOULD synthesize a CNAME record as
+         described above and include it in the answer section.  Go back
+         to step 1.
+
+         If there was no DNAME record, look to see if the "*" label
+         exists.
+
+         If the "*" label does not exist, check whether the name we are
+         looking for is the original QNAME in the query or a name we
+         have followed due to a CNAME.  If the name is original, set an
+         authoritative name error in the response and exit.  Otherwise
+         just exit.
+
+         If the "*" label does exist, match RRs at that node against
+         QTYPE.  If any match, copy them into the answer section, but
+         set the owner of the RR to be QNAME, and not the node with the
+         "*" label.  Go to step 6.
+
+
+
+
+
+Crawford                    Standards Track                     [Page 4]
+
+RFC 2672           Non-Terminal DNS Name Redirection         August 1999
+
+
+   4. Start matching down in the cache.  If QNAME is found in the cache,
+      copy all RRs attached to it that match QTYPE into the answer
+      section.  If QNAME is not found in the cache but a DNAME record is
+      present at an ancestor of QNAME, copy that DNAME record into the
+      answer section.  If there was no delegation from authoritative
+      data, look for the best one from the cache, and put it in the
+      authority section.  Go to step 6.
+
+   5. Use the local resolver or a copy of its algorithm (see resolver
+      section of this memo) to answer the query.  Store the results,
+      including any intermediate CNAMEs and DNAMEs, in the answer
+      section of the response.
+
+   6. Using local data only, attempt to add other RRs which may be
+      useful to the additional section of the query.  Exit.
+
+   Note that there will be at most one ancestor with a DNAME as
+   described in step 4 unless some zone's data is in violation of the
+   no-descendants limitation in section 3.  An implementation might take
+   advantage of this limitation by stopping the search of step 3c or
+   step 4 when a DNAME record is encountered.
+
+4.2.  Processing by Resolvers
+
+   A resolver or a server providing recursive service must be modified
+   to treat a DNAME as somewhat analogous to a CNAME.  The resolver
+   algorithm of [DNSCF] section 5.3.3 is modified to renumber step 4.d
+   as 4.e and insert a new 4.d.  The complete algorithm becomes:
+
+   1. See if the answer is in local information, and if so return it to
+      the client.
+
+   2. Find the best servers to ask.
+
+   3. Send them queries until one returns a response.
+
+   4. Analyze the response, either:
+
+      a. if the response answers the question or contains a name error,
+         cache the data as well as returning it back to the client.
+
+      b. if the response contains a better delegation to other servers,
+         cache the delegation information, and go to step 2.
+
+      c. if the response shows a CNAME and that is not the answer
+         itself, cache the CNAME, change the SNAME to the canonical name
+         in the CNAME RR and go to step 1.
+
+
+
+
+Crawford                    Standards Track                     [Page 5]
+
+RFC 2672           Non-Terminal DNS Name Redirection         August 1999
+
+
+      d. if the response shows a DNAME and that is not the answer
+         itself, cache the DNAME.  If substitution of the DNAME's
+         <target> for its <owner> in the SNAME would overflow the legal
+         size for a <domain-name>, return an implementation-dependent
+         error to the application; otherwise perform the substitution
+         and go to step 1.
+
+      e. if the response shows a server failure or other bizarre
+         contents, delete the server from the SLIST and go back to step
+         3.
+
+   A resolver or recursive server which understands DNAME records but
+   sends non-extended queries MUST augment step 4.c by deleting from the
+   reply any CNAME records which have an <owner> which is a subdomain of
+   the <owner> of any DNAME record in the response.
+
+5.  Examples of Use
+
+5.1.  Organizational Renaming
+
+   If an organization with domain name FROBOZZ.EXAMPLE became part of an
+   organization with domain name ACME.EXAMPLE, it might ease transition
+   by placing information such as this in its old zone.
+
+       frobozz.example.  DNAME    frobozz-division.acme.example.
+                         MX       10       mailhub.acme.example.
+
+   The response to an extended recursive query for www.frobozz.example
+   would contain, in the answer section, the DNAME record shown above
+   and the relevant RRs for www.frobozz-division.acme.example.
+
+5.2.  Classless Delegation of Shorter Prefixes
+
+   The classless scheme for in-addr.arpa delegation [INADDR] can be
+   extended to prefixes shorter than 24 bits by use of the DNAME record.
+   For example, the prefix 192.0.8.0/22 can be delegated by the
+   following records.
+
+       $ORIGIN 0.192.in-addr.arpa.
+       8/22    NS       ns.slash-22-holder.example.
+       8       DNAME    8.8/22
+       9       DNAME    9.8/22
+       10      DNAME    10.8/22
+       11      DNAME    11.8/22
+
+
+
+
+
+
+
+Crawford                    Standards Track                     [Page 6]
+
+RFC 2672           Non-Terminal DNS Name Redirection         August 1999
+
+
+   A typical entry in the resulting reverse zone for some host with
+   address 192.0.9.33 might be
+
+       $ORIGIN 8/22.0.192.in-addr.arpa.
+       33.9    PTR     somehost.slash-22-holder.example.
+
+   The same advisory remarks concerning the choice of the "/" character
+   apply here as in [INADDR].
+
+5.3.  Network Renumbering Support
+
+   If IPv4 network renumbering were common, maintenance of address space
+   delegation could be simplified by using DNAME records instead of NS
+   records to delegate.
+
+      $ORIGIN new-style.in-addr.arpa.
+      189.190           DNAME    in-addr.example.net.
+
+      $ORIGIN in-addr.example.net.
+      188               DNAME    in-addr.customer.example.
+
+      $ORIGIN in-addr.customer.example.
+      1                 PTR      www.customer.example.
+      2                 PTR      mailhub.customer.example.
+      ; etc ...
+
+   This would allow the address space 190.189.0.0/16 assigned to the ISP
+   "example.net" to be changed without the necessity of altering the
+   zone files describing the use of that space by the ISP and its
+   customers.
+
+   Renumbering IPv4 networks is currently so arduous a task that
+   updating the DNS is only a small part of the labor, so this scheme
+   may have a low value.  But it is hoped that in IPv6 the renumbering
+   task will be quite different and the DNAME mechanism may play a
+   useful part.
+
+6.  IANA Considerations
+
+   This document defines a new DNS Resource Record type with the
+   mnemonic DNAME and type code 39 (decimal).  The naming/numbering
+   space is defined in [DNSIS].  This name and number have already been
+   registered with the IANA.
+
+
+
+
+
+
+
+
+Crawford                    Standards Track                     [Page 7]
+
+RFC 2672           Non-Terminal DNS Name Redirection         August 1999
+
+
+7.  Security Considerations
+
+   The DNAME record is similar to the CNAME record with regard to the
+   consequences of insertion of a spoofed record into a DNS server or
+   resolver, differing in that the DNAME's effect covers a whole subtree
+   of the name space.  The facilities of [DNSSEC] are available to
+   authenticate this record type.
+
+8.  References
+
+   [DNSCF]  Mockapetris, P., "Domain names - concepts and facilities",
+            STD 13, RFC 1034, November 1987.
+
+   [DNSCLR] Elz, R. and R. Bush, "Clarifications to the DNS
+            Specification", RFC 2181, July 1997.
+
+   [DNSIS]  Mockapetris, P., "Domain names - implementation and
+            specification", STD 13, RFC 1035, November 1987.
+
+   [DNSSEC] Eastlake, 3rd, D. and C. Kaufman, "Domain Name System
+            Security Extensions", RFC 2065, January 1997.
+
+   [DNSUPD] Vixie, P., Ed., Thomson, S., Rekhter, Y. and J. Bound,
+            "Dynamic Updates in the Domain Name System", RFC 2136, April
+            1997.
+
+   [EDNS0]  Vixie, P., "Extensions mechanisms for DNS (EDNS0)", RFC
+            2671, August 1999.
+
+   [INADDR] Eidnes, H., de Groot, G. and P. Vixie, "Classless IN-
+            ADDR.ARPA delegation", RFC 2317, March 1998.
+
+   [KWORD]  Bradner, S., "Key words for use in RFCs to Indicate
+            Requirement Levels," BCP 14, RFC 2119, March 1997.
+
+   [SECDYN] D. Eastlake, 3rd, "Secure Domain Name System Dynamic
+            Update", RFC 2137, April 1997.
+
+9.  Author's Address
+
+   Matt Crawford
+   Fermilab MS 368
+   PO Box 500
+   Batavia, IL 60510
+   USA
+
+   Phone: +1 630 840-3461
+   EMail: crawdad@fnal.gov
+
+
+
+Crawford                    Standards Track                     [Page 8]
+
+RFC 2672           Non-Terminal DNS Name Redirection         August 1999
+
+
+10.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (1999).  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 Standards process must be
+   followed, or as required to translate it into 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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Crawford                    Standards Track                     [Page 9]
+
diff --git a/doc/rfc/rfc2673.txt b/doc/rfc/rfc2673.txt
new file mode 100644
index 0000000..19d272e
--- /dev/null
+++ b/doc/rfc/rfc2673.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+Network Working Group                                        M. Crawford
+Request for Comments: 2673                                      Fermilab
+Category: Standards Track                                    August 1999
+
+
+                Binary Labels in the Domain Name System
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (1999).  All Rights Reserved.
+
+1.  Introduction and Terminology
+
+   This document defines a "Bit-String Label" which may appear within
+   domain names.  This new label type compactly represents a sequence of
+   "One-Bit Labels" and enables resource records to be stored at any
+   bit-boundary in a binary-named section of the domain name tree.
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [KWORD].
+
+2.  Motivation
+
+   Binary labels are intended to efficiently solve the problem of
+   storing data and delegating authority on arbitrary boundaries when
+   the structure of underlying name space is most naturally represented
+   in binary.
+
+3.  Label Format
+
+   Up to 256 One-Bit Labels can be grouped into a single Bit-String
+   Label.  Within a Bit-String Label the most significant or "highest
+   level" bit appears first.  This is unlike the ordering of DNS labels
+   themselves, which has the least significant or "lowest level" label
+   first.  Nonetheless, this ordering seems to be the most natural and
+   efficient for representing binary labels.
+
+
+
+
+
+
+Crawford                    Standards Track                     [Page 1]
+
+RFC 2673        Binary Labels in the Domain Name System      August 1999
+
+
+   Among consecutive Bit-String Labels, the bits in the first-appearing
+   label are less significant or "at a lower level" than the bits in
+   subsequent Bit-String Labels, just as ASCII labels are ordered.
+
+3.1.  Encoding
+
+      0                   1                   2
+      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2     . . .
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-//+-+-+-+-+-+-+
+     |0 1|    ELT    |     Count     |           Label ...         |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+//-+-+-+-+-+-+-+
+
+   (Each tic mark represents one bit.)
+
+
+   ELT       000001 binary, the six-bit extended label type [EDNS0]
+             assigned to the Bit-String Label.
+
+   Count     The number of significant bits in the Label field.  A Count
+             value of zero indicates that 256 bits are significant.
+             (Thus the null label representing the DNS root cannot be
+             represented as a Bit String Label.)
+
+   Label     The bit string representing a sequence of One-Bit Labels,
+             with the most significant bit first.  That is, the One-Bit
+             Label in position 17 in the diagram above represents a
+             subdomain of the domain represented by the One-Bit Label in
+             position 16, and so on.
+
+             The Label field is padded on the right with zero to seven
+             pad bits to make the entire field occupy an integral number
+             of octets.  These pad bits MUST be zero on transmission and
+             ignored on reception.
+
+   A sequence of bits may be split into two or more Bit-String Labels,
+   but the division points have no significance and need not be
+   preserved.  An excessively clever server implementation might split
+   Bit-String Labels so as to maximize the effectiveness of message
+   compression [DNSIS].  A simpler server might divide Bit-String Labels
+   at zone boundaries, if any zone boundaries happen to fall between
+   One-Bit Labels.
+
+3.2.  Textual Representation
+
+   A Bit-String Label is represented in text -- in a zone file, for
+   example -- as a <bit-spec> surrounded by the delimiters "\[" and "]".
+   The <bit-spec> is either a dotted quad or a base indicator and a
+   sequence of digits appropriate to that base, optionally followed by a
+
+
+
+Crawford                    Standards Track                     [Page 2]
+
+RFC 2673        Binary Labels in the Domain Name System      August 1999
+
+
+   slash and a length.  The base indicators are "b", "o" and "x",
+   denoting base 2, 8 and 16 respectively.  The length counts the
+   significant bits and MUST be between 1 and 32, inclusive, after a
+   dotted quad, or between 1 and 256, inclusive, after one of the other
+   forms.  If the length is omitted, the implicit length is 32 for a
+   dotted quad or 1, 3 or 4 times the number of binary, octal or
+   hexadecimal digits supplied, respectively, for the other forms.
+
+   In augmented Backus-Naur form [ABNF],
+
+     bit-string-label =  "\[" bit-spec "]"
+
+     bit-spec         =  bit-data [ "/" length ]
+                       / dotted-quad [ "/" slength ]
+
+     bit-data         =  "x" 1*64HEXDIG
+                       / "o" 1*86OCTDIG
+                       / "b" 1*256BIT
+
+     dotted-quad      =  decbyte "." decbyte "." decbyte "." decbyte
+
+     decbyte          =  1*3DIGIT
+
+     length           =  NZDIGIT *2DIGIT
+
+     slength          =  NZDIGIT [ DIGIT ]
+
+     OCTDIG           =  %x30-37
+
+     NZDIGIT          =  %x31-39
+
+   If a <length> is present, the number of digits in the <bit-data> MUST
+   be just sufficient to contain the number of bits specified by the
+   <length>.  If there are insignificant bits in a final hexadecimal or
+   octal digit, they MUST be zero.  A <dotted-quad> always has all four
+   parts even if the associated <slength> is less than 24, but, like the
+   other forms, insignificant bits MUST be zero.
+
+   Each number represented by a <decbyte> must be between 0 and 255,
+   inclusive.
+
+   The number represented by <length> must be between 1 and 256
+   inclusive.
+
+   The number represented by <slength> must be between 1 and 32
+   inclusive.
+
+
+
+
+
+Crawford                    Standards Track                     [Page 3]
+
+RFC 2673        Binary Labels in the Domain Name System      August 1999
+
+
+   When the textual form of a Bit-String Label is generated by machine,
+   the length SHOULD be explicit, not implicit.
+
+3.2.1.  Examples
+
+   The following four textual forms represent the same Bit-String Label.
+
+                             \[b11010000011101]
+                             \[o64072/14]
+                             \[xd074/14]
+                             \[208.116.0.0/14]
+
+   The following represents two consecutive Bit-String Labels which
+   denote the same relative point in the DNS tree as any of the above
+   single Bit-String Labels.
+
+                             \[b11101].\[o640]
+
+3.3.  Canonical Representation and Sort Order
+
+   Both the wire form and the text form of binary labels have a degree
+   of flexibility in their grouping into multiple consecutive Bit-String
+   Labels.  For generating and checking DNS signature records [DNSSEC]
+   binary labels must be in a predictable form.  This canonical form is
+   defined as the form which has the fewest possible Bit-String Labels
+   and in which all except possibly the first (least significant) label
+   in any sequence of consecutive Bit-String Labels is of maximum
+   length.
+
+   For example, the canonical form of any sequence of up to 256 One-Bit
+   Labels has a single Bit-String Label, and the canonical form of a
+   sequence of 513 to 768 One-Bit Labels has three Bit-String Labels of
+   which the second and third contain 256 label bits.
+
+   The canonical sort order of domain names [DNSSEC] is extended to
+   encompass binary labels as follows.  Sorting is still label-by-label,
+   from most to least significant, where a label may now be a One-Bit
+   Label or a standard (code 00) label.  Any One-Bit Label sorts before
+   any standard label, and a 0 bit sorts before a 1 bit.  The absence of
+   a label sorts before any label, as specified in [DNSSEC].
+
+
+
+
+
+
+
+
+
+
+
+Crawford                    Standards Track                     [Page 4]
+
+RFC 2673        Binary Labels in the Domain Name System      August 1999
+
+
+   For example, the following domain names are correctly sorted.
+
+                         foo.example
+                         \[b1].foo.example
+                         \[b100].foo.example
+                         \[b101].foo.example
+                         bravo.\[b10].foo.example
+                         alpha.foo.example
+
+4.  Processing Rules
+
+   A One-Bit Label never matches any other kind of label.  In
+   particular, the DNS labels represented by the single ASCII characters
+   "0" and "1" do not match One-Bit Labels represented by the bit values
+   0 and 1.
+
+5.  Discussion
+
+   A Count of zero in the wire-form represents a 256-bit sequence, not
+   to optimize that particular case, but to make it completely
+   impossible to have a zero-bit label.
+
+6.  IANA Considerations
+
+   This document defines one Extended Label Type, termed the Bit-String
+   Label, and requests registration of the code point 000001 binary in
+   the space defined by [EDNS0].
+
+7.  Security Considerations
+
+   All security considerations which apply to traditional ASCII DNS
+   labels apply equally to binary labels.  he canonicalization and
+   sorting rules of section 3.3 allow these to be addressed by DNS
+   Security [DNSSEC].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Crawford                    Standards Track                     [Page 5]
+
+RFC 2673        Binary Labels in the Domain Name System      August 1999
+
+
+8.  References
+
+   [ABNF]   Crocker, D. and P. Overell, "Augmented BNF for Syntax
+            Specifications: ABNF", RFC 2234, November 1997.
+
+   [DNSIS]  Mockapetris, P., "Domain names - implementation and
+            specification", STD 13, RFC 1035, November 1987.
+
+   [DNSSEC] Eastlake, D., 3rd, C. Kaufman, "Domain Name System Security
+            Extensions", RFC 2065, January 1997
+
+   [EDNS0]  Vixie, P., "Extension mechanisms for DNS (EDNS0)", RFC 2671,
+            August 1999.
+
+   [KWORD]  Bradner, S., "Key words for use in RFCs to Indicate
+            Requirement Levels," BCP 14, RFC 2119, March 1997.
+
+9.  Author's Address
+
+   Matt Crawford
+   Fermilab MS 368
+   PO Box 500
+   Batavia, IL 60510
+   USA
+
+   Phone: +1 630 840-3461
+   EMail: crawdad@fnal.gov
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Crawford                    Standards Track                     [Page 6]
+
+RFC 2673        Binary Labels in the Domain Name System      August 1999
+
+
+10.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (1999).  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 Standards process must be
+   followed, or as required to translate it into 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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Crawford                    Standards Track                     [Page 7]
+
diff --git a/doc/rfc/rfc2782.txt b/doc/rfc/rfc2782.txt
new file mode 100644
index 0000000..1827f10
--- /dev/null
+++ b/doc/rfc/rfc2782.txt
@@ -0,0 +1,675 @@
+
+
+
+
+
+
+Network Working Group                                     A. Gulbrandsen
+Request for Comments: 2782                            Troll Technologies
+Obsoletes: 2052                                                 P. Vixie
+Category: Standards Track                   Internet Software Consortium
+                                                               L. Esibov
+                                                         Microsoft Corp.
+                                                           February 2000
+
+
+       A DNS RR for specifying the location of services (DNS SRV)
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2000).  All Rights Reserved.
+
+Abstract
+
+   This document describes a DNS RR which specifies the location of the
+   server(s) for a specific protocol and domain.
+
+Overview and rationale
+
+   Currently, one must either know the exact address of a server to
+   contact it, or broadcast a question.
+
+   The SRV RR allows administrators to use several servers for a single
+   domain, to move services from host to host with little fuss, and to
+   designate some hosts as primary servers for a service and others as
+   backups.
+
+   Clients ask for a specific service/protocol for a specific domain
+   (the word domain is used here in the strict RFC 1034 sense), and get
+   back the names of any available servers.
+
+   Note that where this document refers to "address records", it means A
+   RR's, AAAA RR's, or their most modern equivalent.
+
+
+
+
+
+
+
+Gulbrandsen, et al.         Standards Track                     [Page 1]
+
+RFC 2782                       DNS SRV RR                  February 2000
+
+
+Definitions
+
+   The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT" and "MAY"
+   used in this document are to be interpreted as specified in [BCP 14].
+   Other terms used in this document are defined in the DNS
+   specification, RFC 1034.
+
+Applicability Statement
+
+   In general, it is expected that SRV records will be used by clients
+   for applications where the relevant protocol specification indicates
+   that clients should use the SRV record. Such specification MUST
+   define the symbolic name to be used in the Service field of the SRV
+   record as described below. It also MUST include security
+   considerations. Service SRV records SHOULD NOT be used in the absence
+   of such specification.
+
+Introductory example
+
+   If a SRV-cognizant LDAP client wants to discover a LDAP server that
+   supports TCP protocol and provides LDAP service for the domain
+   example.com., it does a lookup of
+
+      _ldap._tcp.example.com
+
+   as described in [ARM].  The example zone file near the end of this
+   memo contains answering RRs for an SRV query.
+
+   Note: LDAP is chosen as an example for illustrative purposes only,
+   and the LDAP examples used in this document should not be considered
+   a definitive statement on the recommended way for LDAP to use SRV
+   records. As described in the earlier applicability section, consult
+   the appropriate LDAP documents for the recommended procedures.
+
+The format of the SRV RR
+
+   Here is the format of the SRV RR, whose DNS type code is 33:
+
+        _Service._Proto.Name TTL Class SRV Priority Weight Port Target
+
+        (There is an example near the end of this document.)
+
+   Service
+        The symbolic name of the desired service, as defined in Assigned
+        Numbers [STD 2] or locally.  An underscore (_) is prepended to
+        the service identifier to avoid collisions with DNS labels that
+        occur in nature.
+
+
+
+
+Gulbrandsen, et al.         Standards Track                     [Page 2]
+
+RFC 2782                       DNS SRV RR                  February 2000
+
+
+        Some widely used services, notably POP, don't have a single
+        universal name.  If Assigned Numbers names the service
+        indicated, that name is the only name which is legal for SRV
+        lookups.  The Service is case insensitive.
+
+   Proto
+        The symbolic name of the desired protocol, with an underscore
+        (_) prepended to prevent collisions with DNS labels that occur
+        in nature.  _TCP and _UDP are at present the most useful values
+        for this field, though any name defined by Assigned Numbers or
+        locally may be used (as for Service).  The Proto is case
+        insensitive.
+
+   Name
+        The domain this RR refers to.  The SRV RR is unique in that the
+        name one searches for is not this name; the example near the end
+        shows this clearly.
+
+   TTL
+        Standard DNS meaning [RFC 1035].
+
+   Class
+        Standard DNS meaning [RFC 1035].   SRV records occur in the IN
+        Class.
+
+   Priority
+        The priority of this target host.  A client MUST attempt to
+        contact the target host with the lowest-numbered priority it can
+        reach; target hosts with the same priority SHOULD be tried in an
+        order defined by the weight field.  The range is 0-65535.  This
+        is a 16 bit unsigned integer in network byte order.
+
+   Weight
+        A server selection mechanism.  The weight field specifies a
+        relative weight for entries with the same priority. Larger
+        weights SHOULD be given a proportionately higher probability of
+        being selected. The range of this number is 0-65535.  This is a
+        16 bit unsigned integer in network byte order.  Domain
+        administrators SHOULD use Weight 0 when there isn't any server
+        selection to do, to make the RR easier to read for humans (less
+        noisy).  In the presence of records containing weights greater
+        than 0, records with weight 0 should have a very small chance of
+        being selected.
+
+        In the absence of a protocol whose specification calls for the
+        use of other weighting information, a client arranges the SRV
+        RRs of the same Priority in the order in which target hosts,
+
+
+
+
+Gulbrandsen, et al.         Standards Track                     [Page 3]
+
+RFC 2782                       DNS SRV RR                  February 2000
+
+
+        specified by the SRV RRs, will be contacted. The following
+        algorithm SHOULD be used to order the SRV RRs of the same
+        priority:
+
+        To select a target to be contacted next, arrange all SRV RRs
+        (that have not been ordered yet) in any order, except that all
+        those with weight 0 are placed at the beginning of the list.
+
+        Compute the sum of the weights of those RRs, and with each RR
+        associate the running sum in the selected order. Then choose a
+        uniform random number between 0 and the sum computed
+        (inclusive), and select the RR whose running sum value is the
+        first in the selected order which is greater than or equal to
+        the random number selected. The target host specified in the
+        selected SRV RR is the next one to be contacted by the client.
+        Remove this SRV RR from the set of the unordered SRV RRs and
+        apply the described algorithm to the unordered SRV RRs to select
+        the next target host.  Continue the ordering process until there
+        are no unordered SRV RRs.  This process is repeated for each
+        Priority.
+
+   Port
+        The port on this target host of this service.  The range is 0-
+        65535.  This is a 16 bit unsigned integer in network byte order.
+        This is often as specified in Assigned Numbers but need not be.
+
+   Target
+        The domain name of the target host.  There MUST be one or more
+        address records for this name, the name MUST NOT be an alias (in
+        the sense of RFC 1034 or RFC 2181).  Implementors are urged, but
+        not required, to return the address record(s) in the Additional
+        Data section.  Unless and until permitted by future standards
+        action, name compression is not to be used for this field.
+
+        A Target of "." means that the service is decidedly not
+        available at this domain.
+
+Domain administrator advice
+
+   Expecting everyone to update their client applications when the first
+   server publishes a SRV RR is futile (even if desirable).  Therefore
+   SRV would have to coexist with address record lookups for existing
+   protocols, and DNS administrators should try to provide address
+   records to support old clients:
+
+      - Where the services for a single domain are spread over several
+        hosts, it seems advisable to have a list of address records at
+        the same DNS node as the SRV RR, listing reasonable (if perhaps
+
+
+
+Gulbrandsen, et al.         Standards Track                     [Page 4]
+
+RFC 2782                       DNS SRV RR                  February 2000
+
+
+        suboptimal) fallback hosts for Telnet, NNTP and other protocols
+        likely to be used with this name.  Note that some programs only
+        try the first address they get back from e.g. gethostbyname(),
+        and we don't know how widespread this behavior is.
+
+      - Where one service is provided by several hosts, one can either
+        provide address records for all the hosts (in which case the
+        round-robin mechanism, where available, will share the load
+        equally) or just for one (presumably the fastest).
+
+      - If a host is intended to provide a service only when the main
+        server(s) is/are down, it probably shouldn't be listed in
+        address records.
+
+      - Hosts that are referenced by backup address records must use the
+        port number specified in Assigned Numbers for the service.
+
+      - Designers of future protocols for which "secondary servers" is
+        not useful (or meaningful) may choose to not use SRV's support
+        for secondary servers.  Clients for such protocols may use or
+        ignore SRV RRs with Priority higher than the RR with the lowest
+        Priority for a domain.
+
+   Currently there's a practical limit of 512 bytes for DNS replies.
+   Until all resolvers can handle larger responses, domain
+   administrators are strongly advised to keep their SRV replies below
+   512 bytes.
+
+   All round numbers, wrote Dr. Johnson, are false, and these numbers
+   are very round: A reply packet has a 30-byte overhead plus the name
+   of the service ("_ldap._tcp.example.com" for instance); each SRV RR
+   adds 20 bytes plus the name of the target host; each NS RR in the NS
+   section is 15 bytes plus the name of the name server host; and
+   finally each A RR in the additional data section is 20 bytes or so,
+   and there are A's for each SRV and NS RR mentioned in the answer.
+   This size estimate is extremely crude, but shouldn't underestimate
+   the actual answer size by much.  If an answer may be close to the
+   limit, using a DNS query tool (e.g. "dig") to look at the actual
+   answer is a good idea.
+
+The "Weight" field
+
+   Weight, the server selection field, is not quite satisfactory, but
+   the actual load on typical servers changes much too quickly to be
+   kept around in DNS caches.  It seems to the authors that offering
+   administrators a way to say "this machine is three times as fast as
+   that one" is the best that can practically be done.
+
+
+
+
+Gulbrandsen, et al.         Standards Track                     [Page 5]
+
+RFC 2782                       DNS SRV RR                  February 2000
+
+
+   The only way the authors can see of getting a "better" load figure is
+   asking a separate server when the client selects a server and
+   contacts it.  For short-lived services an extra step in the
+   connection establishment seems too expensive, and for long-lived
+   services, the load figure may well be thrown off a minute after the
+   connection is established when someone else starts or finishes a
+   heavy job.
+
+   Note: There are currently various experiments at providing relative
+   network proximity estimation, available bandwidth estimation, and
+   similar services.  Use of the SRV record with such facilities, and in
+   particular the interpretation of the Weight field when these
+   facilities are used, is for further study.  Weight is only intended
+   for static, not dynamic, server selection.  Using SRV weight for
+   dynamic server selection would require assigning unreasonably short
+   TTLs to the SRV RRs, which would limit the usefulness of the DNS
+   caching mechanism, thus increasing overall network load and
+   decreasing overall reliability.  Server selection via SRV is only
+   intended to express static information such as "this server has a
+   faster CPU than that one" or "this server has a much better network
+   connection than that one".
+
+The Port number
+
+   Currently, the translation from service name to port number happens
+   at the client, often using a file such as /etc/services.
+
+   Moving this information to the DNS makes it less necessary to update
+   these files on every single computer of the net every time a new
+   service is added, and makes it possible to move standard services out
+   of the "root-only" port range on unix.
+
+Usage rules
+
+   A SRV-cognizant client SHOULD use this procedure to locate a list of
+   servers and connect to the preferred one:
+
+        Do a lookup for QNAME=_service._protocol.target, QCLASS=IN,
+        QTYPE=SRV.
+
+        If the reply is NOERROR, ANCOUNT>0 and there is at least one
+        SRV RR which specifies the requested Service and Protocol in
+        the reply:
+
+            If there is precisely one SRV RR, and its Target is "."
+            (the root domain), abort.
+
+
+
+
+
+Gulbrandsen, et al.         Standards Track                     [Page 6]
+
+RFC 2782                       DNS SRV RR                  February 2000
+
+
+            Else, for all such RR's, build a list of (Priority, Weight,
+            Target) tuples
+
+            Sort the list by priority (lowest number first)
+
+            Create a new empty list
+
+            For each distinct priority level
+                While there are still elements left at this priority
+                level
+
+                    Select an element as specified above, in the
+                    description of Weight in "The format of the SRV
+                    RR" Section, and move it to the tail of the new
+                    list
+
+            For each element in the new list
+
+                query the DNS for address records for the Target or
+                use any such records found in the Additional Data
+                section of the earlier SRV response.
+
+                for each address record found, try to connect to the
+               (protocol, address, service).
+
+        else
+
+            Do a lookup for QNAME=target, QCLASS=IN, QTYPE=A
+
+            for each address record found, try to connect to the
+           (protocol, address, service)
+
+Notes:
+
+   - Port numbers SHOULD NOT be used in place of the symbolic service
+     or protocol names (for the same reason why variant names cannot
+     be allowed: Applications would have to do two or more lookups).
+
+   - If a truncated response comes back from an SRV query, the rules
+     described in [RFC 2181] shall apply.
+
+   - A client MUST parse all of the RR's in the reply.
+
+   - If the Additional Data section doesn't contain address records
+     for all the SRV RR's and the client may want to connect to the
+     target host(s) involved, the client MUST look up the address
+     record(s).  (This happens quite often when the address record
+     has shorter TTL than the SRV or NS RR's.)
+
+
+
+Gulbrandsen, et al.         Standards Track                     [Page 7]
+
+RFC 2782                       DNS SRV RR                  February 2000
+
+
+   - Future protocols could be designed to use SRV RR lookups as the
+     means by which clients locate their servers.
+
+Fictional example
+
+   This example uses fictional service "foobar" as an aid in
+   understanding SRV records. If ever service "foobar" is implemented,
+   it is not intended that it will necessarily use SRV records.  This is
+   (part of) the zone file for example.com, a still-unused domain:
+
+      $ORIGIN example.com.
+      @               SOA server.example.com. root.example.com. (
+                          1995032001 3600 3600 604800 86400 )
+                      NS  server.example.com.
+                      NS  ns1.ip-provider.net.
+                      NS  ns2.ip-provider.net.
+      ; foobar - use old-slow-box or new-fast-box if either is
+      ; available, make three quarters of the logins go to
+      ; new-fast-box.
+      _foobar._tcp    SRV 0 1 9 old-slow-box.example.com.
+                       SRV 0 3 9 new-fast-box.example.com.
+      ; if neither old-slow-box or new-fast-box is up, switch to
+      ; using the sysdmin's box and the server
+                       SRV 1 0 9 sysadmins-box.example.com.
+                       SRV 1 0 9 server.example.com.
+      server           A   172.30.79.10
+      old-slow-box     A   172.30.79.11
+      sysadmins-box    A   172.30.79.12
+      new-fast-box     A   172.30.79.13
+      ; NO other services are supported
+      *._tcp          SRV  0 0 0 .
+      *._udp          SRV  0 0 0 .
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gulbrandsen, et al.         Standards Track                     [Page 8]
+
+RFC 2782                       DNS SRV RR                  February 2000
+
+
+   In this example, a client of the "foobar" service in the
+   "example.com." domain needs an SRV lookup of
+   "_foobar._tcp.example.com." and possibly A lookups of "new-fast-
+   box.example.com." and/or the other hosts named.  The size of the SRV
+   reply is approximately 365 bytes:
+
+      30 bytes general overhead
+      20 bytes for the query string, "_foobar._tcp.example.com."
+      130 bytes for 4 SRV RR's, 20 bytes each plus the lengths of "new-
+        fast-box", "old-slow-box", "server" and "sysadmins-box" -
+        "example.com" in the query section is quoted here and doesn't
+        need to be counted again.
+      75 bytes for 3 NS RRs, 15 bytes each plus the lengths of "server",
+        "ns1.ip-provider.net." and "ns2" - again, "ip-provider.net." is
+        quoted and only needs to be counted once.
+      120 bytes for the 6 address records (assuming IPv4 only) mentioned
+        by the SRV and NS RR's.
+
+IANA Considerations
+
+   The IANA has assigned RR type value 33 to the SRV RR.  No other IANA
+   services are required by this document.
+
+Changes from RFC 2052
+
+   This document obsoletes RFC 2052.   The major change from that
+   previous, experimental, version of this specification is that now the
+   protocol and service labels are prepended with an underscore, to
+   lower the probability of an accidental clash with a similar name used
+   for unrelated purposes.  Aside from that, changes are only intended
+   to increase the clarity and completeness of the document. This
+   document especially clarifies the use of the Weight field of the SRV
+   records.
+
+Security Considerations
+
+   The authors believe this RR to not cause any new security problems.
+   Some problems become more visible, though.
+
+   - The ability to specify ports on a fine-grained basis obviously
+     changes how a router can filter packets.  It becomes impossible
+     to block internal clients from accessing specific external
+     services, slightly harder to block internal users from running
+     unauthorized services, and more important for the router
+     operations and DNS operations personnel to cooperate.
+
+   - There is no way a site can keep its hosts from being referenced
+     as servers.  This could lead to denial of service.
+
+
+
+Gulbrandsen, et al.         Standards Track                     [Page 9]
+
+RFC 2782                       DNS SRV RR                  February 2000
+
+
+   - With SRV, DNS spoofers can supply false port numbers, as well as
+     host names and addresses.   Because this vulnerability exists
+     already, with names and addresses, this is not a new
+     vulnerability, merely a slightly extended one, with little
+     practical effect.
+
+References
+
+   STD 2:    Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC
+             1700, October 1994.
+
+   RFC 1034: Mockapetris, P., "Domain names - concepts and facilities",
+             STD 13, RFC 1034, November 1987.
+
+   RFC 1035: Mockapetris, P., "Domain names - Implementation and
+             Specification", STD 13, RFC 1035, November 1987.
+
+   RFC 974:  Partridge, C., "Mail routing and the domain system", STD
+             14, RFC 974, January 1986.
+
+   BCP 14:   Bradner, S., "Key words for use in RFCs to Indicate
+             Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   RFC 2181: Elz, R. and R. Bush, "Clarifications to the DNS
+             Specification", RFC 2181, July 1997.
+
+   RFC 2219: Hamilton, M. and R. Wright, "Use of DNS Aliases for Network
+             Services", BCP 17, RFC 2219, October 1997.
+
+   BCP 14:   Bradner, S., "Key words for use in RFCs to Indicate
+             Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   ARM:      Armijo, M., Esibov, L. and P. Leach, "Discovering LDAP
+             Services with DNS", Work in Progress.
+
+   KDC-DNS:  Hornstein, K. and J. Altman, "Distributing Kerberos KDC and
+             Realm Information with DNS", Work in Progress.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gulbrandsen, et al.         Standards Track                    [Page 10]
+
+RFC 2782                       DNS SRV RR                  February 2000
+
+
+Acknowledgements
+
+   The algorithm used to select from the weighted SRV RRs of equal
+   priority is adapted from one supplied by Dan Bernstein.
+
+Authors' Addresses
+
+   Arnt Gulbrandsen
+   Troll Tech
+   Waldemar Thranes gate 98B
+   N-0175 Oslo, Norway
+
+   Fax:   +47 22806380
+   Phone: +47 22806390
+   EMail: arnt@troll.no
+
+
+   Paul Vixie
+   Internet Software Consortium
+   950 Charter Street
+   Redwood City, CA 94063
+
+   Phone: +1 650 779 7001
+
+
+   Levon Esibov
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA 98052
+
+   EMail: levone@microsoft.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gulbrandsen, et al.         Standards Track                    [Page 11]
+
+RFC 2782                       DNS SRV RR                  February 2000
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2000).  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 Standards process must be
+   followed, or as required to translate it into 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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gulbrandsen, et al.         Standards Track                    [Page 12]
+
diff --git a/doc/rfc/rfc2825.txt b/doc/rfc/rfc2825.txt
new file mode 100644
index 0000000..fd8ef7c
--- /dev/null
+++ b/doc/rfc/rfc2825.txt
@@ -0,0 +1,395 @@
+

+

+

+

+

+

+Network Working Group                  Internet Architecture Board (IAB)

+Request for Comments: 2825                             L. Daigle, Editor

+Category: Informational                                         May 2000

+

+

+         A Tangled Web: Issues of I18N, Domain Names, and the

+                        Other Internet protocols

+

+Status of this Memo

+

+   This memo provides information for the Internet community.  It does

+   not specify an Internet standard of any kind.  Distribution of this

+   memo is unlimited.

+

+Copyright Notice

+

+   Copyright (C) The Internet Society (2000).  All Rights Reserved.

+

+Abstract

+

+   The goals of the work to "internationalize" Internet protocols

+   include providing all users of the Internet with the capability of

+   using their own language and its standard character set to express

+   themselves, write names, and to navigate the network. This impacts

+   the domain names visible in e-mail addresses and so many of today's

+   URLs used to locate information on the World Wide Web, etc.  However,

+   domain names are used by Internet protocols that are used across

+   national boundaries. These services must interoperate worldwide, or

+   we risk isolating components of the network from each other along

+   locale boundaries.  This type of isolation could impede not only

+   communications among people, but opportunities of the areas involved

+   to participate effectively in e-commerce, distance learning, and

+   other activities at an international scale, thereby retarding

+   economic development.

+

+   There are several proposals for internationalizing domain names,

+   however it it is still to be determined whether any of them will

+   ensure this interoperability and global reach while addressing

+   visible-name representation.  Some of them obviously do not. This

+   document does not attempt to review any specific proposals, as that

+   is the work of the Internationalized Domain Name (IDN) Working Group

+   of the IETF, which is tasked with evaluating them in consideration of

+   the continued global network interoperation that is the deserved

+   expectation of all Internet users.

+

+

+

+

+

+

+

+IAB                          Informational                      [Page 1]

+

+RFC 2825   Issues: I18N, Domain Names, and Internet Protocols   May 2000

+

+

+   This document is a statement by the Internet Architecture Board. It

+   is not a protocol specification, but an attempt to clarify the range

+   of architectural issues that the internationalization of domain names

+   faces.

+

+1. A Definition of Success

+

+   The Internationalized Domain Names (IDN) Working Group is one

+   component of the IETF's continuing comprehensive effort to

+   internationalize language representation facilities in the protocols

+   that support the global functioning of the Internet.

+

+   In keeping with the principles of rough consensus, running code,

+   architectural integrity, and in the interest of ensuring the global

+   stability of the Internet, the IAB emphasizes that all solutions

+   proposed to the (IDN) Working Group will have to be evaluated not

+   only on their individual technical features, but also in terms of

+   impact on existing standards and operations of the Internet and the

+   total effect for end-users: solutions must not cause users to become

+   more isolated from their global neighbors even if they appear to

+   solve a local problem.  In some cases, existing protocols have

+   limitations on allowable characters, and in other cases

+   implementations of protocols used in the core of the Internet (beyond

+   individual organizations) have in practice not implemented all the

+   requisite options of the standards.

+

+2. Technical Challenges within the Domain Name System (DNS)

+

+   In many technical respects, the IDN work is not different from any

+   other effort to enable multiple character set representations in

+   textual elements that were traditionally restricted to English

+   language characters.

+

+   One aspect of the challenge is to decide how to represent the names

+   users want in the DNS in a way that is clear, technically feasible,

+   and ensures that a name always means the same thing.  Several

+   proposals have been suggested to address these issues.

+

+   These issues are being outlined in more detail in the IDN WG's

+   evolving draft requirements document; further discussion is deferred

+   to the WG and its documents.

+

+3. Integrating with Current Realities

+

+   Nevertheless, issues faced by the IDN working group are complex and

+   intricately intertwined with other operational components of the

+   Internet.  A key challenge in evaluating any proposed solution is the

+   analysis of the impact on existing critical operational standards

+

+

+

+IAB                          Informational                      [Page 2]

+

+RFC 2825   Issues: I18N, Domain Names, and Internet Protocols   May 2000

+

+

+   which use fully-qualified domain names [RFC1034], or simply host

+   names [RFC1123].  Standards-changes can be effected, but the best

+   path forward is one that takes into account current realities and

+   (re)deployment latencies. In the Internet's global context, it is not

+   enough to update a few isolated systems, or even most of the systems

+   in a country or region.  Deployment must be nearly universal in order

+   to avoid the creation of "islands" of interoperation that provide

+   users with less access to and connection from the rest of the world.

+

+   These are not esoteric or ephemeral concerns.  Some specific issues

+   have already been identified as part of the IDN WG's efforts.  These

+   include (but are not limited to) the following examples.

+

+3.1 Domain Names and E-mail

+

+   As indicated in the IDN WG's draft requirements document, the issue

+   goes beyond standardization of DNS usage.  Electronic mail has long

+   been one of the most-used and most important applications of the

+   Internet.  Internet e-mail is also used as the bridge that permits

+   the users of a variety of local and proprietary mail systems to

+   communicate. The standard protocols that define its use (e.g., SMTP

+   [RFC821, RFC822] and MIME [RFC2045]) do not permit the full range of

+   characters allowed in the DNS specification. Certain characters are

+   not allowed in e-mail address domain portions of these

+   specifications.  Some mailers, built to adhere to these

+   specifications, are known to fail when on mail having non-ASCII

+   domain names in its address -- by discarding, misrouting or damaging

+   the mail.  Thus, it's not possible to simply switch to

+   internationalized domain names and expect global e-mail to continue

+   to work until most of the servers in the world are upgraded.

+

+3.2 Domain Names and Routing

+

+   At a lower level, the Routing Policy Specification Language (RPLS)

+   [RFC2622] makes use of "named objects" -- and inherits object naming

+   restrictions from older standards ([RFC822] for the same e-mail

+   address restrictions, [RFC1034] for hostnames).  This means that

+   until routing registries and their protocols are updated, it is not

+   possible to enter or retrieve network descriptions utilizing

+   internationalized domain names.

+

+3.3 Domain Names and Network Management

+

+   Also, the Simple Network Management Protocol (SNMP) uses the textual

+   representation defined in [RFC2579].  While that specification does

+   allow for UTF-8-based domain names, an informal survey of deployed

+   implementations of software libraries being used to build SNMP-

+   compliant software uncovered the fact that few (if any) implement it.

+

+

+

+IAB                          Informational                      [Page 3]

+

+RFC 2825   Issues: I18N, Domain Names, and Internet Protocols   May 2000

+

+

+   This may cause inability to enter or display correct data in network

+   management tools, if such names are internationalized domain names.

+

+3.4 Domain Names and Security

+

+   Critical components of Internet public key technologies (PKIX,

+   [RFC2459], IKE [RFC2409]) rely heavily on identification of servers

+   (hostnames, or fully qualified domain names) and users (e-mail

+   addresses).  Failure to respect the character restrictions in these

+   protocols will impact security tools built to use them -- Transport

+   Layer Security protocol (TLS, [RFC2246]), and IPsec [RFC2401] to name

+   two.

+

+   Failure may not be obvious.  For example, in TLS, it is common usage

+   for a server to display a certificate containing a domain name

+   purporting to be the domain name of the server, which the client can

+   then match with the server name he thought he used to reach the

+   service.

+

+   Unless comparison of domain names is properly defined, the client may

+   either fail to match the domain name of a legitimate server, or match

+   incorrectly the domain name of a server performing a man-in-the-

+   middle attack.  Either failure could enable attacks on systems that

+   are now impossible or at least far more difficult.

+

+4. Conclusion

+

+   It is therefore clear that, although there are many possible ways to

+   assign internationalized names that are compatible with today's DNS

+   (or a version that is easily-deployable in the near future), not all

+   of them are compatible with the full range of necessary networking

+   tools.  When designing a solution for internationalization of domain

+   names, the effects on the current Internet must be carefully

+   evaluated. Some types of solutions proposed would, if put into effect

+   immediately, cause Internet communications to fail in ways that would

+   be hard to detect by and pose problems for those who deploy the new

+   services, but also for those who do not; this would have the effect

+   of cutting those who deploy them off from effective use of the

+   Internet.

+

+   The IDN WG has been identified as the appropriate forum for

+   identifying and discussing solutions for such potential

+   interoperability issues.

+

+   Experience with deployment of other protocols has indicated that it

+   will take years before a new protocol or enhancement is used all over

+   the Internet.  So far, the IDN WG has benefited from proposed

+   solutions from all quarters, including organizations hoping to

+

+

+

+IAB                          Informational                      [Page 4]

+

+RFC 2825   Issues: I18N, Domain Names, and Internet Protocols   May 2000

+

+

+   provide services that address visible-name representation and

+   registration -- continuing this process with the aim of getting a

+   single, scalable and deployable solution to this problem is the only

+   way to ensure the continued global interoperation that is the

+   deserved expectation of all Internet users.

+

+5. Security Considerations

+

+   In general, assignment and use of names does not raise any special

+   security problems.  However, as noted above, some existing security

+   mechanisms are reliant on the current specification of domain names

+   and may not be expected to work, as is, with Internationalized domain

+   names.  Additionally, deployment of non-standard systems (e.g., in

+   response to current pressures to address national or regional

+   characterset representation) might result in name strings that are

+   not globally unique, thereby opening up the possibility of "spoofing"

+   hosts from one domain in another, as described in [RFC2826].

+

+6. Acknowledgements

+

+   This document is the outcome of the joint effort of the members of

+   the IAB.  Additionally, valuable remarks were provided by Randy Bush,

+   Patrik Faltstrom, Ted Hardie, Paul Hoffman, and Mark Kosters.

+

+7. References

+

+   [RFC821]  Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC

+             821, August 1982.

+

+   [RFC822]  Crocker, D., "Standard for the Format of ARPA Internet Text

+             Messages", STD 11, RFC 822, August 1982.

+

+   [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities",

+             STD 13, RFC 1034, November 1987.

+

+   [RFC1123] Braden, R., "Requirements for Internet Hosts -- Application

+             and Support", STD 3, RFC 1123, November 1989.

+

+   [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the

+             Internet Protocol", RFC 2401, November 1998.

+

+   [RFC2409] Harkins, D and D. Carrel, "The Internet Key Exchange

+             (IKE)", RFC 2409, November 1998.

+

+   [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail

+             Extensions (MIME) Part One:  Format of Internet Message

+             Bodies", RFC 2045, November 1996.

+

+

+

+

+IAB                          Informational                      [Page 5]

+

+RFC 2825   Issues: I18N, Domain Names, and Internet Protocols   May 2000

+

+

+   [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",

+             RFC 2246, January 1999.

+

+   [RFC2459] Housley, R., Ford, W., Polk, W. and D. Solo, "Internet

+             X.509 Public Key Infrastructure Certificate and CRL

+             Profile", RFC 2459, January 1999.

+

+   [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.

+             and M. Rose, "Textual Conventions for SMIv2", RFC 2579,

+             April 1999.

+

+   [RFC2622] Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D.,

+             Meyer, D., Bates, T., Karrenberg, D. and M. Terpstra,

+             "Routing Policy Specification Language (RPSL)", RFC 2622,

+             June 1999.

+

+   [RFC2826] IAB, "IAB Technical Comment on the Unique DNS Root", RFC

+             2826, May 2000.

+

+8. Author's Address

+

+   Internet Architecture Board

+

+   EMail:  iab@iab.org

+

+

+   Membership at time this document was completed:

+

+      Harald Alvestrand

+      Ran Atkinson

+      Rob Austein

+      Brian Carpenter

+      Steve Bellovin

+      Jon Crowcroft

+      Leslie Daigle

+      Steve Deering

+      Tony Hain

+      Geoff Huston

+      John Klensin

+      Henning Schulzrinne

+

+

+

+

+

+

+

+

+

+

+

+IAB                          Informational                      [Page 6]

+

+RFC 2825   Issues: I18N, Domain Names, and Internet Protocols   May 2000

+

+

+9. Full Copyright Statement

+

+   Copyright (C) The Internet Society (2000).  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 Standards process must be

+   followed, or as required to translate it into 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.

+

+Acknowledgement

+

+   Funding for the RFC Editor function is currently provided by the

+   Internet Society.

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+IAB                          Informational                      [Page 7]

+

diff --git a/doc/rfc/rfc2826.txt b/doc/rfc/rfc2826.txt
new file mode 100644
index 0000000..b4d8869
--- /dev/null
+++ b/doc/rfc/rfc2826.txt
@@ -0,0 +1,339 @@
+

+

+

+

+

+

+Network Working Group                        Internet Architecture Board

+Request for Comments: 2826                                      May 2000

+Category: Informational

+

+

+              IAB Technical Comment on the Unique DNS Root

+

+Status of this Memo

+

+   This memo provides information for the Internet community.  It does

+   not specify an Internet standard of any kind.  Distribution of this

+   memo is unlimited.

+

+Copyright Notice

+

+   Copyright (C) The Internet Society (2000).  All Rights Reserved.

+

+Summary

+

+   To remain a global network, the Internet requires the existence of a

+   globally unique public name space.  The DNS name space is a

+   hierarchical name space derived from a single, globally unique root.

+   This is a technical constraint inherent in the design of the DNS.

+   Therefore it is not technically feasible for there to be more than

+   one root in the public DNS.  That one root must be supported by a set

+   of coordinated root servers administered by a unique naming

+   authority.

+

+   Put simply, deploying multiple public DNS roots would raise a very

+   strong possibility that users of different ISPs who click on the same

+   link on a web page could end up at different destinations, against

+   the will of the web page designers.

+

+   This does not preclude private networks from operating their own

+   private name spaces, but if they wish to make use of names uniquely

+   defined for the global Internet, they have to fetch that information

+   from the global DNS naming hierarchy, and in particular from the

+   coordinated root servers of the global DNS naming hierarchy.

+

+1.  Detailed Explanation

+

+   There are several distinct reasons why the DNS requires a single root

+   in order to operate properly.

+

+1.1.  Maintenance of a Common Symbol Set

+

+   Effective communications between two parties requires two essential

+   preconditions:

+

+

+

+IAB                          Informational                      [Page 1]

+

+RFC 2826      IAB Technical Comment on the Unique DNS Root      May 2000

+

+

+   -  The existence of a common symbol set, and

+

+   -  The existence of a common semantic interpretation of these

+      symbols.

+

+   Failure to meet the first condition implies a failure to communicate

+   at all, while failure to meet the second implies that the meaning of

+   the communication is lost.

+

+   In the case of a public communications system this condition of a

+   common symbol set with a common semantic interpretation must be

+   further strengthened to that of a unique symbol set with a unique

+   semantic interpretation.  This condition of uniqueness allows any

+   party to initiate a communication that can be received and understood

+   by any other party.  Such a condition rules out the ability to define

+   a symbol within some bounded context.  In such a case, once the

+   communication moves out of the context of interpretation in which it

+   was defined, the meaning of the symbol becomes lost.

+

+   Within public digital communications networks such as the Internet

+   this requirement for a uniquely defined symbol set with a uniquely

+   defined meaning exists at many levels, commencing with the binary

+   encoding scheme, extending to packet headers and payload formats and

+   the protocol that an application uses to interact.  In each case a

+   variation of the symbol set or a difference of interpretation of the

+   symbols being used within the interaction causes a protocol failure,

+   and the communication fails.  The property of uniqueness allows a

+   symbol to be used unambiguously in any context, allowing the symbol

+   to be passed on, referred to, and reused, while still preserving the

+   meaning of the original use.

+

+   The DNS fulfills an essential role within the Internet protocol

+   environment, allowing network locations to be referred to using a

+   label other than a protocol address.  As with any other such symbol

+   set, DNS names are designed to be globally unique, that is, for any

+   one DNS name at any one time there must be a single set of DNS

+   records uniquely describing protocol addresses, network resources and

+   services associated with that DNS name.  All of the applications

+   deployed on the Internet which use the DNS assume this, and Internet

+   users expect such behavior from DNS names.  Names are then constant

+   symbols, whose interpretation does not specifically require knowledge

+   of the context of any individual party.  A DNS name can be passed

+   from one party to another without altering the semantic intent of the

+   name.

+

+   Since the DNS is hierarchically structured into domains, the

+   uniqueness requirement for DNS names in their entirety implies that

+   each of the names (sub-domains) defined within a domain has a unique

+

+

+

+IAB                          Informational                      [Page 2]

+

+RFC 2826      IAB Technical Comment on the Unique DNS Root      May 2000

+

+

+   meaning (i.e., set of DNS records) within that domain.  This is as

+   true for the root domain as for any other DNS domain.  The

+   requirement for uniqueness within a domain further implies that there

+   be some mechanism to prevent name conflicts within a domain.  In DNS

+   this is accomplished by assigning a single owner or maintainer to

+   every domain, including the root domain, who is responsible for

+   ensuring that each sub-domain of that domain has the proper records

+   associated with it.  This is a technical requirement, not a policy

+   choice.

+

+1.2.  Coordination of Updates

+

+   Both the design and implementations of the DNS protocol are heavily

+   based on the assumption that there is a single owner or maintainer

+   for every domain, and that any set of resources records associated

+   with a domain is modified in a single-copy serializable fashion.

+   That is, even assuming that a single domain could somehow be "shared"

+   by uncooperating parties, there is no means within the DNS protocol

+   by which a user or client could discover, and choose between,

+   conflicting definitions of a DNS name made by different parties.  The

+   client will simply return the first set of resource records that it

+   finds that matches the requested domain, and assume that these are

+   valid.  This protocol is embedded in the operating software of

+   hundreds of millions of computer systems, and is not easily updated

+   to support a shared domain scenario.

+

+   Moreover, even supposing that some other means of resolving

+   conflicting definitions could be provided in the future, it would

+   have to be based on objective rules established in advance.  For

+   example, zone A.B could declare that naming authority Y had been

+   delegated all subdomains of A.B with an odd number of characters, and

+   that naming authority Z had been delegated authority to define

+   subdomains of A.B with an even number of characters.  Thus, a single

+   set of rules would have to be agreed to prevent Y and Z from making

+   conflicting assignments, and with this train of actions a single

+   unique space has been created in any case.  Even this would not allow

+   multiple non-cooperating authorities to assign arbitrary sub-domains

+   within a single domain.

+

+   It seems that a degree of cooperation and agreed technical rules are

+   required in order to guarantee the uniqueness of names.  In the DNS,

+   these rules are established independently for each part of the naming

+   hierarchy, and the root domain is no exception.  Thus, there must be

+   a generally agreed single set of rules for the root.

+

+

+

+

+

+

+

+IAB                          Informational                      [Page 3]

+

+RFC 2826      IAB Technical Comment on the Unique DNS Root      May 2000

+

+

+1.3.  Difficulty of Relocating the Root Zone

+

+   There is one specific technical respect in which the root zone

+   differs from all other DNS zones: the addresses of the name servers

+   for the root zone come primarily from out-of-band information.  This

+   out-of-band information is often poorly maintained and, unlike all

+   other data in the DNS, the out-of-band information has no automatic

+   timeout mechanism.  It is not uncommon for this information to be

+   years out of date at many sites.

+

+   Like any other zone, the root zone contains a set of "name server"

+   resource records listing its servers, but a resolver with no valid

+   addresses for the current set of root servers will never be able to

+   obtain these records.  More insidiously, a resolver that has a mixed

+   set of partially valid and partially stale out-of-band configuration

+   information will not be able to tell which are the "real" root

+   servers if it gets back conflicting answers; thus, it is very

+   difficult to revoke the status of a malicious root server, or even to

+   route around a buggy root server.

+

+   In effect, every full-service resolver in the world "delegates" the

+   root of the public tree to the public root server(s) of its choice.

+

+   As a direct consequence, any change to the list of IP addresses that

+   specify the public root zone is significantly more difficult than

+   changing any other aspect of the DNS delegation chain.   Thus,

+   stability of the system calls for extremely conservative and cautious

+   management of the public root zone: the frequency of updates to the

+   root zone must be kept low, and the servers for the root zone must be

+   closely coordinated.

+

+   These problems can be ameliorated to some extent by the DNS Security

+   Extensions [DNSSEC], but a similar out-of-band configuration problem

+   exists for the cryptographic signature key to the root zone, so the

+   root zone still requires tight coupling and coordinated management

+   even in the presence of DNSSEC.

+

+2.  Conclusion

+

+   The DNS type of unique naming and name-mapping system may not be

+   ideal for a number of purposes for which it was never designed, such

+   a locating information when the user doesn't precisely know the

+   correct names.  As the Internet continues to expand, we would expect

+   directory systems to evolve which can assist the user in dealing with

+   vague or ambiguous references.  To preserve the many important

+   features of the DNS and its multiple record types -- including the

+   Internet's equivalent of telephone number portability -- we would

+   expect the result of directory lookups and identification of the

+

+

+

+IAB                          Informational                      [Page 4]

+

+RFC 2826      IAB Technical Comment on the Unique DNS Root      May 2000

+

+

+   correct names for a particular purpose to be unique DNS names that

+   are then resolved normally, rather than having directory systems

+   "replace" the DNS.

+

+   There is no getting away from the unique root of the public DNS.

+

+3.  Security Considerations

+

+   This memo does not introduce any new security issues, but it does

+   attempt to identify some of the problems inherent in a family of

+   recurring technically naive proposals.

+

+4.  IANA Considerations

+

+   This memo is not intended to create any new issues for IANA.

+

+5.  References

+

+   [DNS-CONCEPTS]        Mockapetris, P., "Domain Names - Concepts and

+                         Facilities", STD 13, RFC 1034, November 1987.

+

+   [DNS-IMPLEMENTATION]  Mockapetris, P., "Domain Names - Implementation

+                         and Specification", STD 13, RFC 1035, November

+                         1987.

+

+   [DNSSEC]              Eastlake, D., "Domain Name System Security

+                         Extensions", RFC 2535, March 1999.

+

+6.  Author's Address

+

+   Internet Architecture Board

+

+   EMail: iab@iab.org

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+IAB                          Informational                      [Page 5]

+

+RFC 2826      IAB Technical Comment on the Unique DNS Root      May 2000

+

+

+7.  Full Copyright Statement

+

+   Copyright (C) The Internet Society (2000).  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 Standards process must be

+   followed, or as required to translate it into 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.

+

+Acknowledgement

+

+   Funding for the RFC Editor function is currently provided by the

+   Internet Society.

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+IAB                          Informational                      [Page 6]

+

diff --git a/doc/rfc/rfc2845.txt b/doc/rfc/rfc2845.txt
new file mode 100644
index 0000000..aa9f385
--- /dev/null
+++ b/doc/rfc/rfc2845.txt
@@ -0,0 +1,843 @@
+
+
+
+
+
+
+Network Working Group                                             P. Vixie
+Request for Comments: 2845                                             ISC
+Category: Standards Track                                   O. Gudmundsson
+Updates: 1035                                                     NAI Labs
+                                                           D. Eastlake 3rd
+                                                                  Motorola
+                                                             B. Wellington
+                                                                   Nominum
+                                                                  May 2000
+
+
+          Secret Key Transaction Authentication for DNS (TSIG)
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2000).  All Rights Reserved.
+
+Abstract
+
+   This protocol allows for transaction level authentication using
+   shared secrets and one way hashing.  It can be used to authenticate
+   dynamic updates as coming from an approved client, or to authenticate
+   responses as coming from an approved recursive name server.
+
+   No provision has been made here for distributing the shared secrets;
+   it is expected that a network administrator will statically configure
+   name servers and clients using some out of band mechanism such as
+   sneaker-net until a secure automated mechanism for key distribution
+   is available.
+
+1 - Introduction
+
+   1.1. The Domain Name System (DNS) [RFC1034, RFC1035] is a replicated
+   hierarchical distributed database system that provides information
+   fundamental to Internet operations, such as name <=> address
+   translation and mail handling information.  DNS has recently been
+   extended [RFC2535] to provide for data origin authentication, and
+   public key distribution, all based on public key cryptography and
+   public key based digital signatures.  To be practical, this form of
+
+
+
+
+Vixie, et al.               Standards Track                     [Page 1]
+
+RFC 2845                        DNS TSIG                        May 2000
+
+
+   security generally requires extensive local caching of keys and
+   tracing of authentication through multiple keys and signatures to a
+   pre-trusted locally configured key.
+
+   1.2. One difficulty with the [RFC2535] scheme is that common DNS
+   implementations include simple "stub" resolvers which do not have
+   caches.  Such resolvers typically rely on a caching DNS server on
+   another host.  It is impractical for these stub resolvers to perform
+   general [RFC2535] authentication and they would naturally depend on
+   their caching DNS server to perform such services for them.  To do so
+   securely requires secure communication of queries and responses.
+   [RFC2535] provides public key transaction signatures to support this,
+   but such signatures are very expensive computationally to generate.
+   In general, these require the same complex public key logic that is
+   impractical for stubs.  This document specifies use of a message
+   authentication code (MAC), specifically HMAC-MD5 (a keyed hash
+   function), to provide an efficient means of point-to-point
+   authentication and integrity checking for transactions.
+
+   1.3. A second area where use of straight [RFC2535] public key based
+   mechanisms may be impractical is authenticating dynamic update
+   [RFC2136] requests.  [RFC2535] provides for request signatures but
+   with [RFC2535] they, like transaction signatures, require
+   computationally expensive public key cryptography and complex
+   authentication logic.  Secure Domain Name System Dynamic Update
+   ([RFC2137]) describes how different keys are used in dynamically
+   updated zones.  This document's secret key based MACs can be used to
+   authenticate DNS update requests as well as transaction responses,
+   providing a lightweight alternative to the protocol described by
+   [RFC2137].
+
+   1.4. A further use of this mechanism is to protect zone transfers.
+   In this case the data covered would be the whole zone transfer
+   including any glue records sent.  The protocol described by [RFC2535]
+   does not protect glue records and unsigned records unless SIG(0)
+   (transaction signature) is used.
+
+   1.5. The authentication mechanism proposed in this document uses
+   shared secret keys to establish a trust relationship between two
+   entities.  Such keys must be protected in a fashion similar to
+   private keys, lest a third party masquerade as one of the intended
+   parties (forge MACs).  There is an urgent need to provide simple and
+   efficient authentication between clients and local servers and this
+   proposal addresses that need.  This proposal is unsuitable for
+   general server to server authentication for servers which speak with
+   many other servers, since key management would become unwieldy with
+
+
+
+
+
+Vixie, et al.               Standards Track                     [Page 2]
+
+RFC 2845                        DNS TSIG                        May 2000
+
+
+   the number of shared keys going up quadratically.  But it is suitable
+   for many resolvers on hosts that only talk to a few recursive
+   servers.
+
+   1.6. A server acting as an indirect caching resolver -- a "forwarder"
+   in common usage -- might use transaction-based authentication when
+   communicating with its small number of preconfigured "upstream"
+   servers.  Other uses of DNS secret key authentication and possible
+   systems for automatic secret key distribution may be proposed in
+   separate future documents.
+
+   1.7. New Assigned Numbers
+
+      RRTYPE = TSIG (250)
+      ERROR = 0..15 (a DNS RCODE)
+      ERROR = 16 (BADSIG)
+      ERROR = 17 (BADKEY)
+      ERROR = 18 (BADTIME)
+
+   1.8. The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED",  and
+   "MAY" in this document are to be interpreted as described in [RFC
+   2119].
+
+2 - TSIG RR Format
+
+   2.1 TSIG RR Type
+
+   To provide secret key authentication, we use a new RR type whose
+   mnemonic is TSIG and whose type code is 250.  TSIG is a meta-RR and
+   MUST not be cached.  TSIG RRs are used for authentication between DNS
+   entities that have established a shared secret key.  TSIG RRs are
+   dynamically computed to cover a particular DNS transaction and are
+   not DNS RRs in the usual sense.
+
+   2.2 TSIG Calculation
+
+   As the TSIG RRs are related to one DNS request/response, there is no
+   value in storing or retransmitting them, thus the TSIG RR is
+   discarded once it has been used to authenticate a DNS message.  The
+   only message digest algorithm specified in this document is "HMAC-
+   MD5" (see [RFC1321], [RFC2104]).  The "HMAC-MD5" algorithm is
+   mandatory to implement for interoperability.  Other algorithms can be
+   specified at a later date.  Names and definitions of new algorithms
+   MUST be registered with IANA.  All multi-octet integers in the TSIG
+   record are sent in network byte order (see [RFC1035 2.3.2]).
+
+
+
+
+
+
+Vixie, et al.               Standards Track                     [Page 3]
+
+RFC 2845                        DNS TSIG                        May 2000
+
+
+   2.3. Record Format
+
+    NAME The name of the key used in domain name syntax.  The name
+         should reflect the names of the hosts and uniquely identify
+         the key among a set of keys these two hosts may share at any
+         given time.  If hosts A.site.example and B.example.net share a
+         key, possibilities for the key name include
+         <id>.A.site.example, <id>.B.example.net, and
+         <id>.A.site.example.B.example.net.  It should be possible for
+         more than one key to be in simultaneous use among a set of
+         interacting hosts.  The name only needs to be meaningful to
+         the communicating hosts but a meaningful mnemonic name as
+         above is strongly recommended.
+
+         The name may be used as a local index to the key involved and
+         it is recommended that it be globally unique.  Where a key is
+         just shared between two hosts, its name actually only need
+         only be meaningful to them but it is recommended that the key
+         name be mnemonic and incorporate the resolver and server host
+         names in that order.
+
+    TYPE TSIG (250: Transaction SIGnature)
+
+    CLASS ANY
+
+    TTL  0
+
+    RdLen (variable)
+
+    RDATA
+
+      Field Name       Data Type      Notes
+      --------------------------------------------------------------
+      Algorithm Name   domain-name    Name of the algorithm
+                                      in domain name syntax.
+      Time Signed      u_int48_t      seconds since 1-Jan-70 UTC.
+      Fudge            u_int16_t      seconds of error permitted
+                                      in Time Signed.
+      MAC Size         u_int16_t      number of octets in MAC.
+      MAC              octet stream   defined by Algorithm Name.
+      Original ID      u_int16_t      original message ID
+      Error            u_int16_t      expanded RCODE covering
+                                      TSIG processing.
+      Other Len        u_int16_t      length, in octets, of
+                                      Other Data.
+      Other Data       octet stream   empty unless Error == BADTIME
+
+
+
+
+
+Vixie, et al.               Standards Track                     [Page 4]
+
+RFC 2845                        DNS TSIG                        May 2000
+
+
+   2.4. Example
+
+      NAME   HOST.EXAMPLE.
+
+      TYPE   TSIG
+
+      CLASS  ANY
+
+      TTL    0
+
+      RdLen  as appropriate
+
+      RDATA
+
+         Field Name       Contents
+         -------------------------------------
+         Algorithm Name   SAMPLE-ALG.EXAMPLE.
+         Time Signed      853804800
+         Fudge            300
+         MAC Size         as appropriate
+         MAC              as appropriate
+         Original ID      as appropriate
+         Error            0 (NOERROR)
+         Other Len        0
+         Other Data       empty
+
+3 - Protocol Operation
+
+   3.1. Effects of adding TSIG to outgoing message
+
+   Once the outgoing message has been constructed, the keyed message
+   digest operation can be performed.  The resulting message digest will
+   then be stored in a TSIG which is appended to the additional data
+   section (the ARCOUNT is incremented to reflect this).  If the TSIG
+   record cannot be added without causing the message to be truncated,
+   the server MUST alter the response so that a TSIG can be included.
+   This response consists of only the question and a TSIG record, and
+   has the TC bit set and RCODE 0 (NOERROR).  The client SHOULD at this
+   point retry the request using TCP (per [RFC1035 4.2.2]).
+
+   3.2. TSIG processing on incoming messages
+
+   If an incoming message contains a TSIG record, it MUST be the last
+   record in the additional section.  Multiple TSIG records are not
+   allowed.  If a TSIG record is present in any other position, the
+   packet is dropped and a response with RCODE 1 (FORMERR) MUST be
+   returned.  Upon receipt of a message with a correctly placed TSIG RR,
+   the TSIG RR is copied to a safe location, removed from the DNS
+
+
+
+Vixie, et al.               Standards Track                     [Page 5]
+
+RFC 2845                        DNS TSIG                        May 2000
+
+
+   Message, and decremented out of the DNS message header's ARCOUNT.  At
+   this point the keyed message digest operation is performed.  If the
+   algorithm name or key name is unknown to the recipient, or if the
+   message digests do not match, the whole DNS message MUST be
+   discarded.  If the message is a query, a response with RCODE 9
+   (NOTAUTH) MUST be sent back to the originator with TSIG ERROR 17
+   (BADKEY) or TSIG ERROR 16 (BADSIG).  If no key is available to sign
+   this message it MUST be sent unsigned (MAC size == 0 and empty MAC).
+   A message to the system operations log SHOULD be generated, to warn
+   the operations staff of a possible security incident in progress.
+   Care should be taken to ensure that logging of this type of event
+   does not open the system to a denial of service attack.
+
+   3.3. Time values used in TSIG calculations
+
+   The data digested includes the two timer values in the TSIG header in
+   order to defend against replay attacks.  If this were not done, an
+   attacker could replay old messages but update the "Time Signed" and
+   "Fudge" fields to make the message look new.  This data is named
+   "TSIG Timers", and for the purpose of digest calculation they are
+   invoked in their "on the wire" format, in the following order: first
+   Time Signed, then Fudge.  For example:
+
+Field Name    Value       Wire Format         Meaning
+----------------------------------------------------------------------
+Time Signed   853804800   00 00 32 e4 07 00   Tue Jan 21 00:00:00 1997
+Fudge         300         01 2C               5 minutes
+
+   3.4. TSIG Variables and Coverage
+
+   When generating or verifying the contents of a TSIG record, the
+   following data are digested, in network byte order or wire format, as
+   appropriate:
+
+   3.4.1. DNS Message
+
+   A whole and complete DNS message in wire format, before the TSIG RR
+   has been added to the additional data section and before the DNS
+   Message Header's ARCOUNT field has been incremented to contain the
+   TSIG RR.  If the message ID differs from the original message ID, the
+   original message ID is substituted for the message ID.  This could
+   happen when forwarding a dynamic update request, for example.
+
+
+
+
+
+
+
+
+
+Vixie, et al.               Standards Track                     [Page 6]
+
+RFC 2845                        DNS TSIG                        May 2000
+
+
+   3.4.2. TSIG Variables
+
+Source       Field Name       Notes
+-----------------------------------------------------------------------
+TSIG RR      NAME             Key name, in canonical wire format
+TSIG RR      CLASS            (Always ANY in the current specification)
+TSIG RR      TTL              (Always 0 in the current specification)
+TSIG RDATA   Algorithm Name   in canonical wire format
+TSIG RDATA   Time Signed      in network byte order
+TSIG RDATA   Fudge            in network byte order
+TSIG RDATA   Error            in network byte order
+TSIG RDATA   Other Len        in network byte order
+TSIG RDATA   Other Data       exactly as transmitted
+
+   The RR RDLEN and RDATA MAC Length are not included in the hash since
+   they are not guaranteed to be knowable before the MAC is generated.
+
+   The Original ID field is not included in this section, as it has
+   already been substituted for the message ID in the DNS header and
+   hashed.
+
+   For each label type, there must be a defined "Canonical wire format"
+   that specifies how to express a label in an unambiguous way.  For
+   label type 00, this is defined in [RFC2535], for label type 01, this
+   is defined in [RFC2673].  The use of label types other than 00 and 01
+   is not defined for this specification.
+
+   3.4.3. Request MAC
+
+   When generating the MAC to be included in a response, the request MAC
+   must be included in the digest.  The request's MAC is digested in
+   wire format, including the following fields:
+
+   Field        Type           Description
+   ---------------------------------------------------
+   MAC Length   u_int16_t      in network byte order
+   MAC Data     octet stream   exactly as transmitted
+
+   3.5. Padding
+
+   Digested components are fed into the hashing function as a continuous
+   octet stream with no interfield padding.
+
+
+
+
+
+
+
+
+
+Vixie, et al.               Standards Track                     [Page 7]
+
+RFC 2845                        DNS TSIG                        May 2000
+
+
+4 - Protocol Details
+
+   4.1. TSIG generation on requests
+
+   Client performs the message digest operation and appends a TSIG
+   record to the additional data section and transmits the request to
+   the server.  The client MUST store the message digest from the
+   request while awaiting an answer.  The digest components for a
+   request are:
+
+      DNS Message (request)
+      TSIG Variables (request)
+
+   Note that some older name servers will not accept requests with a
+   nonempty additional data section.  Clients SHOULD only attempt signed
+   transactions with servers who are known to support TSIG and share
+   some secret key with the client -- so, this is not a problem in
+   practice.
+
+   4.2. TSIG on Answers
+
+   When a server has generated a response to a signed request, it signs
+   the response using the same algorithm and key.  The server MUST not
+   generate a signed response to an unsigned request.  The digest
+   components are:
+
+      Request MAC
+      DNS Message (response)
+      TSIG Variables (response)
+
+   4.3. TSIG on TSIG Error returns
+
+   When a server detects an error relating to the key or MAC, the server
+   SHOULD send back an unsigned error message (MAC size == 0 and empty
+   MAC).  If an error is detected relating to the TSIG validity period,
+   the server SHOULD send back a signed error message.  The digest
+   components are:
+
+      Request MAC (if the request MAC validated)
+      DNS Message (response)
+      TSIG Variables (response)
+
+   The reason that the request is not included in this digest in some
+   cases is to make it possible for the client to verify the error.  If
+   the error is not a TSIG error the response MUST be generated as
+   specified in [4.2].
+
+
+
+
+
+Vixie, et al.               Standards Track                     [Page 8]
+
+RFC 2845                        DNS TSIG                        May 2000
+
+
+   4.4. TSIG on TCP connection
+
+   A DNS TCP session can include multiple DNS envelopes.  This is, for
+   example, commonly used by zone transfer.  Using TSIG on such a
+   connection can protect the connection from hijacking and provide data
+   integrity.  The TSIG MUST be included on the first and last DNS
+   envelopes.  It can be optionally placed on any intermediary
+   envelopes.  It is expensive to include it on every envelopes, but it
+   MUST be placed on at least every 100'th envelope.  The first envelope
+   is processed as a standard answer, and subsequent messages have the
+   following digest components:
+
+      Prior Digest (running)
+      DNS Messages (any unsigned messages since the last TSIG)
+      TSIG Timers (current message)
+
+   This allows the client to rapidly detect when the session has been
+   altered; at which point it can close the connection and retry.  If a
+   client TSIG verification fails, the client MUST close the connection.
+   If the client does not receive TSIG records frequently enough (as
+   specified above) it SHOULD assume the connection has been hijacked
+   and it SHOULD close the connection.  The client SHOULD treat this the
+   same way as they would any other interrupted transfer (although the
+   exact behavior is not specified).
+
+   4.5. Server TSIG checks
+
+   Upon receipt of a message, server will check if there is a TSIG RR.
+   If one exists, the server is REQUIRED to return a TSIG RR in the
+   response.  The server MUST perform the following checks in the
+   following order, check KEY, check TIME values, check MAC.
+
+   4.5.1. KEY check and error handling
+
+   If a non-forwarding server does not recognize the key used by the
+   client, the server MUST generate an error response with RCODE 9
+   (NOTAUTH) and TSIG ERROR 17 (BADKEY).  This response MUST be unsigned
+   as specified in [4.3].  The server SHOULD log the error.
+
+   4.5.2. TIME check and error handling
+
+   If the server time is outside the time interval specified by the
+   request (which is: Time Signed, plus/minus Fudge), the server MUST
+   generate an error response with RCODE 9 (NOTAUTH) and TSIG ERROR 18
+   (BADTIME).  The server SHOULD also cache the most recent time signed
+   value in a message generated by a key, and SHOULD return BADTIME if a
+   message received later has an earlier time signed value.  A response
+   indicating a BADTIME error MUST be signed by the same key as the
+
+
+
+Vixie, et al.               Standards Track                     [Page 9]
+
+RFC 2845                        DNS TSIG                        May 2000
+
+
+   request.  It MUST include the client's current time in the time
+   signed field, the server's current time (a u_int48_t) in the other
+   data field, and 6 in the other data length field.  This is done so
+   that the client can verify a message with a BADTIME error without the
+   verification failing due to another BADTIME error.  The data signed
+   is specified in [4.3].  The server SHOULD log the error.
+
+   4.5.3. MAC check and error handling
+
+   If a TSIG fails to verify, the server MUST generate an error response
+   as specified in [4.3] with RCODE 9 (NOTAUTH) and TSIG ERROR 16
+   (BADSIG).  This response MUST be unsigned as specified in [4.3].  The
+   server SHOULD log the error.
+
+   4.6. Client processing of answer
+
+   When a client receives a response from a server and expects to see a
+   TSIG, it first checks if the TSIG RR is present in the response.
+   Otherwise, the response is treated as having a format error and
+   discarded.  The client then extracts the TSIG, adjusts the ARCOUNT,
+   and calculates the keyed digest in the same way as the server.  If
+   the TSIG does not validate, that response MUST be discarded, unless
+   the RCODE is 9 (NOTAUTH), in which case the client SHOULD attempt to
+   verify the response as if it were a TSIG Error response, as specified
+   in [4.3].  A message containing an unsigned TSIG record or a TSIG
+   record which fails verification SHOULD not be considered an
+   acceptable response; the client SHOULD log an error and continue to
+   wait for a signed response until the request times out.
+
+   4.6.1. Key error handling
+
+   If an RCODE on a response is 9 (NOTAUTH), and the response TSIG
+   validates, and the TSIG key is different from the key used on the
+   request, then this is a KEY error.  The client MAY retry the request
+   using the key specified by the server.  This should never occur, as a
+   server MUST NOT sign a response with a different key than signed the
+   request.
+
+   4.6.2. Time error handling
+
+   If the response RCODE is 9 (NOTAUTH) and the TSIG ERROR is 18
+   (BADTIME), or the current time does not fall in the range specified
+   in the TSIG record, then this is a TIME error.  This is an indication
+   that the client and server clocks are not synchronized.  In this case
+   the client SHOULD log the event.  DNS resolvers MUST NOT adjust any
+   clocks in the client based on BADTIME errors, but the server's time
+   in the other data field SHOULD be logged.
+
+
+
+
+Vixie, et al.               Standards Track                    [Page 10]
+
+RFC 2845                        DNS TSIG                        May 2000
+
+
+   4.6.3. MAC error handling
+
+   If the response RCODE is 9 (NOTAUTH) and TSIG ERROR is 16 (BADSIG),
+   this is a MAC error, and client MAY retry the request with a new
+   request ID but it would be better to try a different shared key if
+   one is available.  Client SHOULD keep track of how many MAC errors
+   are associated with each key.  Clients SHOULD log this event.
+
+   4.7. Special considerations for forwarding servers
+
+   A server acting as a forwarding server of a DNS message SHOULD check
+   for the existence of a TSIG record.  If the name on the TSIG is not
+   of a secret that the server shares with the originator the server
+   MUST forward the message unchanged including the TSIG.  If the name
+   of the TSIG is of a key this server shares with the originator, it
+   MUST process the TSIG.  If the TSIG passes all checks, the forwarding
+   server MUST, if possible, include a TSIG of his own, to the
+   destination or the next forwarder.  If no transaction security is
+   available to the destination and the response has the AD flag (see
+   [RFC2535]), the forwarder MUST unset the AD flag before adding the
+   TSIG to the answer.
+
+5 - Shared Secrets
+
+   5.1. Secret keys are very sensitive information and all available
+   steps should be taken to protect them on every host on which they are
+   stored.  Generally such hosts need to be physically protected.  If
+   they are multi-user machines, great care should be taken that
+   unprivileged users have no access to keying material.  Resolvers
+   often run unprivileged, which means all users of a host would be able
+   to see whatever configuration data is used by the resolver.
+
+   5.2. A name server usually runs privileged, which means its
+   configuration data need not be visible to all users of the host.  For
+   this reason, a host that implements transaction-based authentication
+   should probably be configured with a "stub resolver" and a local
+   caching and forwarding name server.  This presents a special problem
+   for [RFC2136] which otherwise depends on clients to communicate only
+   with a zone's authoritative name servers.
+
+   5.3. Use of strong random shared secrets is essential to the security
+   of TSIG.  See [RFC1750] for a discussion of this issue.  The secret
+   should be at least as long as the keyed message digest, i.e. 16 bytes
+   for HMAC-MD5 or 20 bytes for HMAC-SHA1.
+
+
+
+
+
+
+
+Vixie, et al.               Standards Track                    [Page 11]
+
+RFC 2845                        DNS TSIG                        May 2000
+
+
+6 - Security Considerations
+
+   6.1. The approach specified here is computationally much less
+   expensive than the signatures specified in [RFC2535].  As long as the
+   shared secret key is not compromised, strong authentication is
+   provided for the last hop from a local name server to the user
+   resolver.
+
+   6.2. Secret keys should be changed periodically.  If the client host
+   has been compromised, the server should suspend the use of all
+   secrets known to that client.  If possible, secrets should be stored
+   in encrypted form.  Secrets should never be transmitted in the clear
+   over any network.  This document does not address the issue on how to
+   distribute secrets. Secrets should never be shared by more than two
+   entities.
+
+   6.3. This mechanism does not authenticate source data, only its
+   transmission between two parties who share some secret.  The original
+   source data can come from a compromised zone master or can be
+   corrupted during transit from an authentic zone master to some
+   "caching forwarder."  However, if the server is faithfully performing
+   the full [RFC2535] security checks, then only security checked data
+   will be available to the client.
+
+   6.4. A fudge value that is too large may leave the server open to
+   replay attacks.  A fudge value that is too small may cause failures
+   if machines are not time synchronized or there are unexpected network
+   delays.  The recommended value in most situation is 300 seconds.
+
+7 - IANA Considerations
+
+   IANA is expected to create and maintain a registry of algorithm names
+   to be used as "Algorithm Names" as defined in Section 2.3.  The
+   initial value should be "HMAC-MD5.SIG-ALG.REG.INT".  Algorithm names
+   are text strings encoded using the syntax of a domain name.  There is
+   no structure required other than names for different algorithms must
+   be unique when compared as DNS names, i.e., comparison is case
+   insensitive.  Note that the initial value mentioned above is not a
+   domain name, and therefore need not be a registered name within the
+   DNS.  New algorithms are assigned using the IETF Consensus policy
+   defined in RFC 2434. The algorithm name HMAC-MD5.SIG-ALG.REG.INT
+   looks like a FQDN for historical reasons; future algorithm names are
+   expected to be simple (i.e., single-component) names.
+
+
+
+
+
+
+
+
+Vixie, et al.               Standards Track                    [Page 12]
+
+RFC 2845                        DNS TSIG                        May 2000
+
+
+   IANA is expected to create and maintain a registry of "TSIG Error
+   values" to be used for "Error" values as defined in section 2.3.
+   Initial values should be those defined in section 1.7.  New TSIG
+   error codes for the TSIG error field are assigned using the IETF
+   Consensus policy defined in RFC 2434.
+
+8 - References
+
+   [RFC1034]  Mockapetris, P., "Domain Names - Concepts and Facilities",
+              STD 13, RFC 1034, November 1987.
+
+   [RFC1035]  Mockapetris, P., "Domain Names - Implementation and
+              Specification", STD 13, RFC 1034, November 1987.
+
+   [RFC1321]  Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
+              April 1992.
+
+   [RFC1750]  Eastlake, D., Crocker, S. and J. Schiller, "Randomness
+              Recommendations for Security", RFC 1750, December 1995.
+
+   [RFC2104]  Krawczyk, H., Bellare, M. and R. Canetti, "HMAC-MD5:
+              Keyed-MD5 for Message Authentication", RFC 2104, February
+              1997.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2136]  Vixie, P., Thomson, S., Rekhter, Y. and J. Bound "Dynamic
+              Updates in the Domain Name System", RFC 2136, April 1997.
+
+   [RFC2137]  Eastlake 3rd, D., "Secure Domain Name System Dynamic
+              Update", RFC 2137, April 1997.
+
+   [RFC2535]  Eastlake, D., "Domain Name System Security Extensions",
+              RFC 2535, March 1999.
+
+   [RFC2673]  Crawford, M., "Binary Labels in the Domain Name System",
+              RFC 2673, August 1999.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Vixie, et al.               Standards Track                    [Page 13]
+
+RFC 2845                        DNS TSIG                        May 2000
+
+
+9 - Authors' Addresses
+
+   Paul Vixie
+   Internet Software Consortium
+   950 Charter Street
+   Redwood City, CA 94063
+
+   Phone: +1 650 779 7001
+   EMail: vixie@isc.org
+
+
+   Olafur Gudmundsson
+   NAI Labs
+   3060 Washington Road, Route 97
+   Glenwood, MD 21738
+
+   Phone: +1 443 259 2389
+   EMail: ogud@tislabs.com
+
+
+   Donald E. Eastlake 3rd
+   Motorola
+   140 Forest Avenue
+   Hudson, MA 01749 USA
+
+   Phone: +1 508 261 5434
+   EMail: dee3@torque.pothole.com
+
+
+   Brian Wellington
+   Nominum, Inc.
+   950 Charter Street
+   Redwood City, CA 94063
+
+   Phone: +1 650 779 6022
+   EMail: Brian.Wellington@nominum.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Vixie, et al.               Standards Track                    [Page 14]
+
+RFC 2845                        DNS TSIG                        May 2000
+
+
+10  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2000).  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 Standards process must be
+   followed, or as required to translate it into 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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Vixie, et al.               Standards Track                    [Page 15]
+
diff --git a/doc/rfc/rfc2874.txt b/doc/rfc/rfc2874.txt
new file mode 100644
index 0000000..915c104
--- /dev/null
+++ b/doc/rfc/rfc2874.txt
@@ -0,0 +1,1123 @@
+
+
+
+
+
+
+Network Working Group                                        M. Crawford
+Request for Comments: 2874                                      Fermilab
+Category: Standards Track                                     C. Huitema
+                                                   Microsoft Corporation
+                                                               July 2000
+
+
+   DNS Extensions to Support IPv6 Address Aggregation and Renumbering
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2000).  All Rights Reserved.
+
+Abstract
+
+   This document defines changes to the Domain Name System to support
+   renumberable and aggregatable IPv6 addressing.  The changes include a
+   new resource record type to store an IPv6 address in a manner which
+   expedites network renumbering and updated definitions of existing
+   query types that return Internet addresses as part of additional
+   section processing.
+
+   For lookups keyed on IPv6 addresses (often called reverse lookups),
+   this document defines a new zone structure which allows a zone to be
+   used without modification for parallel copies of an address space (as
+   for a multihomed provider or site) and across network renumbering
+   events.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Crawford, et al.            Standards Track                     [Page 1]
+
+RFC 2874                        IPv6 DNS                       July 2000
+
+
+Table of Contents
+
+   1.  Introduction ...............................................  2
+   2.  Overview ...................................................  3
+       2.1.  Name-to-Address Lookup ...............................  4
+       2.2.  Underlying Mechanisms for Reverse Lookups ............  4
+           2.2.1.  Delegation on Arbitrary Boundaries .............  4
+           2.2.2.  Reusable Zones .................................  5
+   3.  Specifications .............................................  5
+       3.1.  The A6 Record Type ...................................  5
+           3.1.1.  Format .........................................  6
+           3.1.2.  Processing .....................................  6
+           3.1.3.  Textual Representation .........................  7
+           3.1.4.  Name Resolution Procedure ......................  7
+       3.2.  Zone Structure for Reverse Lookups ...................  7
+   4.  Modifications to Existing Query Types ......................  8
+   5.  Usage Illustrations ........................................  8
+       5.1.  A6 Record Chains .....................................  9
+           5.1.1.  Authoritative Data .............................  9
+           5.1.2.  Glue ........................................... 10
+           5.1.3.  Variations ..................................... 12
+       5.2.  Reverse Mapping Zones ................................ 13
+           5.2.1.  The TLA level .................................. 13
+           5.2.2.  The ISP level .................................. 13
+           5.2.3.  The Site Level ................................. 13
+       5.3.  Lookups .............................................. 14
+       5.4.  Operational Note ..................................... 15
+   6.  Transition from RFC 1886 and Deployment Notes .............. 15
+       6.1.  Transition from AAAA and Coexistence with A Records .. 16
+       6.2.  Transition from Nibble Labels to Binary Labels ....... 17
+   7.  Security Considerations .................................... 17
+   8.  IANA Considerations ........................................ 17
+   9.  Acknowledgments ............................................ 18
+   10.  References ................................................ 18
+   11.  Authors' Addresses ........................................ 19
+   12.  Full Copyright Statement .................................. 20
+
+1.  Introduction
+
+   Maintenance of address information in the DNS is one of several
+   obstacles which have prevented site and provider renumbering from
+   being feasible in IP version 4.  Arguments about the importance of
+   network renumbering for the preservation of a stable routing system
+   and for other purposes may be read in [RENUM1, RENUM2, RENUM3].  To
+   support the storage of IPv6 addresses without impeding renumbering we
+   define the following extensions.
+
+
+
+
+
+Crawford, et al.            Standards Track                     [Page 2]
+
+RFC 2874                        IPv6 DNS                       July 2000
+
+
+   o  A new resource record type, "A6", is defined to map a domain name
+      to an IPv6 address, with a provision for indirection for leading
+      "prefix" bits.
+
+   o  Existing queries that perform additional section processing to
+      locate IPv4 addresses are redefined to do that processing for both
+      IPv4 and IPv6 addresses.
+
+   o  A new domain, IP6.ARPA, is defined to support lookups based on
+      IPv6 address.
+
+   o  A new prefix-delegation method is defined, relying on new DNS
+      features [BITLBL, DNAME].
+
+   The changes are designed to be compatible with existing application
+   programming interfaces.  The existing support for IPv4 addresses is
+   retained.  Transition issues related to the coexistence of both IPv4
+   and IPv6 addresses in DNS are discussed in [TRANS].
+
+   This memo proposes a replacement for the specification in RFC 1886
+   [AAAA] and a departure from current implementation practices.  The
+   changes are designed to facilitate network renumbering and
+   multihoming.  Domains employing the A6 record for IPv6 addresses can
+   insert automatically-generated AAAA records in zone files to ease
+   transition.  It is expected that after a reasonable period, RFC 1886
+   will become Historic.
+
+   The next three major sections of this document are an overview of the
+   facilities defined or employed by this specification, the
+   specification itself, and examples of use.
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [KWORD].  The key word
+   "SUGGESTED" signifies a strength between MAY and SHOULD: it is
+   believed that compliance with the suggestion has tangible benefits in
+   most instances.
+
+2.  Overview
+
+   This section provides an overview of the DNS facilities for storage
+   of IPv6 addresses and for lookups based on IPv6 address, including
+   those defined here and elsewhere.
+
+
+
+
+
+
+
+
+Crawford, et al.            Standards Track                     [Page 3]
+
+RFC 2874                        IPv6 DNS                       July 2000
+
+
+2.1.  Name-to-Address Lookup
+
+   IPv6 addresses are stored in one or more A6 resource records.  A
+   single A6 record may include a complete IPv6 address, or a contiguous
+   portion of an address and information leading to one or more
+   prefixes.  Prefix information comprises a prefix length and a DNS
+   name which is in turn the owner of one or more A6 records defining
+   the prefix or prefixes which are needed to form one or more complete
+   IPv6 addresses.  When the prefix length is zero, no DNS name is
+   present and all the leading bits of the address are significant.
+   There may be multiple levels of indirection and the existence of
+   multiple A6 records at any level multiplies the number of IPv6
+   addresses which are formed.
+
+   An application looking up an IPv6 address will generally cause the
+   DNS resolver to access several A6 records, and multiple IPv6
+   addresses may be returned even if the queried name was the owner of
+   only one A6 record.  The authenticity of the returned address(es)
+   cannot be directly verified by DNS Security [DNSSEC].  The A6 records
+   which contributed to the address(es) may of course be verified if
+   signed.
+
+   Implementers are reminded of the necessity to limit the amount of
+   work a resolver will perform in response to a client request.  This
+   principle MUST be extended to also limit the generation of DNS
+   requests in response to one name-to-address (or address-to-name)
+   lookup request.
+
+2.2.  Underlying Mechanisms for Reverse Lookups
+
+   This section describes the new DNS features which this document
+   exploits.  This section is an overview, not a specification of those
+   features.  The reader is directed to the referenced documents for
+   more details on each.
+
+2.2.1.  Delegation on Arbitrary Boundaries
+
+   This new scheme for reverse lookups relies on a new type of DNS label
+   called the "bit-string label" [BITLBL].  This label compactly
+   represents an arbitrary string of bits which is treated as a
+   hierarchical sequence of one-bit domain labels.  Resource records can
+   thereby be stored at arbitrary bit-boundaries.
+
+   Examples in section 5 will employ the following textual
+   representation for bit-string labels, which is a subset of the syntax
+   defined in [BITLBL].  A base indicator "x" for hexadecimal and a
+   sequence of hexadecimal digits is enclosed between "\[" and "]".  The
+   bits denoted by the digits represent a sequence of one-bit domain
+
+
+
+Crawford, et al.            Standards Track                     [Page 4]
+
+RFC 2874                        IPv6 DNS                       July 2000
+
+
+   labels ordered from most to least significant.  (This is the opposite
+   of the order they would appear if listed one bit at a time, but it
+   appears to be a convenient notation.)  The digit string may be
+   followed by a slash ("/") and a decimal count.  If omitted, the
+   implicit count is equal to four times the number of hexadecimal
+   digits.
+
+   Consecutive bit-string labels are equivalent (up to the limit imposed
+   by the size of the bit count field) to a single bit-string label
+   containing all the bits of the consecutive labels in the proper
+   order.  As an example, either of the following domain names could be
+   used in a QCLASS=IN, QTYPE=PTR query to find the name of the node
+   with IPv6 address 3ffe:7c0:40:9:a00:20ff:fe81:2b32.
+
+    \[x3FFE07C0004000090A0020FFFE812B32/128].IP6.ARPA.
+
+    \[x0A0020FFFE812B32/64].\[x0009/16].\[x3FFE07C00040/48].IP6.ARPA.
+
+2.2.2.  Reusable Zones
+
+   DNS address space delegation is implemented not by zone cuts and NS
+   records, but by a new analogue to the CNAME record, called the DNAME
+   resource record [DNAME].  The DNAME record provides alternate naming
+   to an entire subtree of the domain name space, rather than to a
+   single node.  It causes some suffix of a queried name to be
+   substituted with a name from the DNAME record's RDATA.
+
+   For example, a resolver or server providing recursion, while looking
+   up a QNAME a.b.c.d.e.f may encounter a DNAME record
+
+                        d.e.f.     DNAME     w.xy.
+
+   which will cause it to look for a.b.c.w.xy.
+
+3.  Specifications
+
+3.1.  The A6 Record Type
+
+   The A6 record type is specific to the IN (Internet) class and has
+   type number 38 (decimal).
+
+
+
+
+
+
+
+
+
+
+
+Crawford, et al.            Standards Track                     [Page 5]
+
+RFC 2874                        IPv6 DNS                       July 2000
+
+
+3.1.1.  Format
+
+   The RDATA portion of the A6 record contains two or three fields.
+
+           +-----------+------------------+-------------------+
+           |Prefix len.|  Address suffix  |    Prefix name    |
+           | (1 octet) |  (0..16 octets)  |  (0..255 octets)  |
+           +-----------+------------------+-------------------+
+
+   o  A prefix length, encoded as an eight-bit unsigned integer with
+      value between 0 and 128 inclusive.
+
+   o  An IPv6 address suffix, encoded in network order (high-order octet
+      first).  There MUST be exactly enough octets in this field to
+      contain a number of bits equal to 128 minus prefix length, with 0
+      to 7 leading pad bits to make this field an integral number of
+      octets.  Pad bits, if present, MUST be set to zero when loading a
+      zone file and ignored (other than for SIG [DNSSEC] verification)
+      on reception.
+
+   o  The name of the prefix, encoded as a domain name.  By the rules of
+      [DNSIS], this name MUST NOT be compressed.
+
+   The domain name component SHALL NOT be present if the prefix length
+   is zero.  The address suffix component SHALL NOT be present if the
+   prefix length is 128.
+
+   It is SUGGESTED that an A6 record intended for use as a prefix for
+   other A6 records have all the insignificant trailing bits in its
+   address suffix field set to zero.
+
+3.1.2.  Processing
+
+   A query with QTYPE=A6 causes type A6 and type NS additional section
+   processing for the prefix names, if any, in the RDATA field of the A6
+   records in the answer section.  This processing SHOULD be recursively
+   applied to the prefix names of A6 records included as additional
+   data.  When space in the reply packet is a limit, inclusion of
+   additional A6 records takes priority over NS records.
+
+   It is an error for an A6 record with prefix length L1 > 0 to refer to
+   a domain name which owns an A6 record with a prefix length L2 > L1.
+   If such a situation is encountered by a resolver, the A6 record with
+   the offending (larger) prefix length MUST be ignored.  Robustness
+   precludes signaling an error if addresses can still be formed from
+   valid A6 records, but it is SUGGESTED that zone maintainers from time
+   to time check all the A6 records their zones reference.
+
+
+
+
+Crawford, et al.            Standards Track                     [Page 6]
+
+RFC 2874                        IPv6 DNS                       July 2000
+
+
+3.1.3.  Textual Representation
+
+   The textual representation of the RDATA portion of the A6 resource
+   record in a zone file comprises two or three fields separated by
+   whitespace.
+
+   o  A prefix length, represented as a decimal number between 0 and 128
+      inclusive,
+
+   o  the textual representation of an IPv6 address as defined in
+      [AARCH] (although some leading and/or trailing bits may not be
+      significant),
+
+   o  a domain name, if the prefix length is not zero.
+
+   The domain name MUST be absent if the prefix length is zero.  The
+   IPv6 address MAY be be absent if the prefix length is 128.  A number
+   of leading address bits equal to the prefix length SHOULD be zero,
+   either implicitly (through the :: notation) or explicitly, as
+   specified in section 3.1.1.
+
+3.1.4.  Name Resolution Procedure
+
+   To obtain the IPv6 address or addresses which belong to a given name,
+   a DNS client MUST obtain one or more complete chains of A6 records,
+   each chain beginning with a record owned by the given name and
+   including a record owned by the prefix name in that record, and so on
+   recursively, ending with an A6 record with a prefix length of zero.
+   One IPv6 address is formed from one such chain by taking the value of
+   each bit position from the earliest A6 record in the chain which
+   validly covers that position, as indicated by the prefix length.  The
+   set of all IPv6 addresses for the given name comprises the addresses
+   formed from all complete chains of A6 records beginning at that name,
+   discarding records which have invalid prefix lengths as defined in
+   section 3.1.2.
+
+   If some A6 queries fail and others succeed, a client might obtain a
+   non-empty but incomplete set of IPv6 addresses for a host.  In many
+   situations this may be acceptable.  The completeness of a set of A6
+   records may always be determined by inspection.
+
+3.2.  Zone Structure for Reverse Lookups
+
+   Very little of the new scheme's data actually appears under IP6.ARPA;
+   only the first level of delegation needs to be under that domain.
+   More levels of delegation could be placed under IP6.ARPA if some
+   top-level delegations were done via NS records instead of DNAME
+   records, but this would incur some cost in renumbering ease at the
+
+
+
+Crawford, et al.            Standards Track                     [Page 7]
+
+RFC 2874                        IPv6 DNS                       July 2000
+
+
+   level of TLAs [AGGR].  Therefore, it is declared here that all
+   address space delegations SHOULD be done by the DNAME mechanism
+   rather than NS.
+
+   In addition, since uniformity in deployment will simplify maintenance
+   of address delegations, it is SUGGESTED that address and prefix
+   information be stored immediately below a DNS label "IP6".  Stated
+   another way, conformance with this suggestion would mean that "IP6"
+   is the first label in the RDATA field of DNAME records which support
+   IPv6 reverse lookups.
+
+   When any "reserved" or "must be zero" bits are adjacent to a
+   delegation boundary, the higher-level entity MUST retain those bits
+   in its own control and delegate only the bits over which the lower-
+   level entity has authority.
+
+   To find the name of a node given its IPv6 address, a DNS client MUST
+   perform a query with QCLASS=IN, QTYPE=PTR on the name formed from the
+   128 bit address as one or more bit-string labels [BITLBL], followed
+   by the two standard labels "IP6.ARPA".  If recursive service was not
+   obtained from a server and the desired PTR record was not returned,
+   the resolver MUST handle returned DNAME records as specified in
+   [DNAME], and NS records as specified in [DNSCF], and iterate.
+
+4.  Modifications to Existing Query Types
+
+   All existing query types that perform type A additional section
+   processing, i.e. the name server (NS), mail exchange (MX), and
+   mailbox (MB) query types, and the experimental AFS data base (AFSDB)
+   and route through (RT) types, must be redefined to perform type A, A6
+   and AAAA additional section processing, with type A having the
+   highest priority for inclusion and type AAAA the lowest.  This
+   redefinition means that a name server may add any relevant IPv4 and
+   IPv6 address information available locally to the additional section
+   of a response when processing any one of the above queries.  The
+   recursive inclusion of A6 records referenced by A6 records already
+   included in the additional section is OPTIONAL.
+
+5.  Usage Illustrations
+
+   This section provides examples of use of the mechanisms defined in
+   the previous section.  All addresses and domains mentioned here are
+   intended to be fictitious and for illustrative purposes only.
+   Example delegations will be on 4-bit boundaries solely for
+   readability; this specification is indifferent to bit alignment.
+
+   Use of the IPv6 aggregatable address format [AGGR] is assumed in the
+   examples.
+
+
+
+Crawford, et al.            Standards Track                     [Page 8]
+
+RFC 2874                        IPv6 DNS                       July 2000
+
+
+5.1.  A6 Record Chains
+
+   Let's take the example of a site X that is multi-homed to two
+   "intermediate" providers A and B.  The provider A is itself multi-
+   homed to two "transit" providers, C and D.  The provider B gets its
+   transit service from a single provider, E.  For simplicity suppose
+   that C, D and E all belong to the same top-level aggregate (TLA) with
+   identifier (including format prefix) '2345', and the TLA authority at
+   ALPHA-TLA.ORG assigns to C, D and E respectively the next level
+   aggregate (NLA) prefixes 2345:00C0::/28, 2345:00D0::/28 and
+   2345:000E::/32.
+
+   C assigns the NLA prefix 2345:00C1:CA00::/40 to A, D assigns the
+   prefix 2345:00D2:DA00::/40 to A and E assigns 2345:000E:EB00::/40 to
+   B.
+
+   A assigns to X the subscriber identification '11' and B assigns the
+   subscriber identification '22'.  As a result, the site X inherits
+   three address prefixes:
+
+   o  2345:00C1:CA11::/48 from A, for routes through C.
+   o  2345:00D2:DA11::/48 from A, for routes through D.
+   o  2345:000E:EB22::/48 from B, for routes through E.
+
+   Let us suppose that N is a node in the site X, that it is assigned to
+   subnet number 1 in this site, and that it uses the interface
+   identifier '1234:5678:9ABC:DEF0'.  In our configuration, this node
+   will have three addresses:
+
+   o  2345:00C1:CA11:0001:1234:5678:9ABC:DEF0
+   o  2345:00D2:DA11:0001:1234:5678:9ABC:DEF0
+   o  2345:000E:EB22:0001:1234:5678:9ABC:DEF0
+
+5.1.1.  Authoritative Data
+
+   We will assume that the site X is represented in the DNS by the
+   domain name X.EXAMPLE, while A, B, C, D and E are represented by
+   A.NET, B.NET, C.NET, D.NET and E.NET.  In each of these domains, we
+   assume a subdomain "IP6" that will hold the corresponding prefixes.
+   The node N is identified by the domain name N.X.EXAMPLE.  The
+   following records would then appear in X's DNS.
+
+          $ORIGIN X.EXAMPLE.
+          N            A6 64 ::1234:5678:9ABC:DEF0 SUBNET-1.IP6
+          SUBNET-1.IP6 A6 48 0:0:0:1::  IP6
+          IP6          A6 48 0::0       SUBSCRIBER-X.IP6.A.NET.
+          IP6          A6 48 0::0       SUBSCRIBER-X.IP6.B.NET.
+
+
+
+
+Crawford, et al.            Standards Track                     [Page 9]
+
+RFC 2874                        IPv6 DNS                       July 2000
+
+
+   And elsewhere there would appear
+
+        SUBSCRIBER-X.IP6.A.NET. A6 40 0:0:0011:: A.NET.IP6.C.NET.
+        SUBSCRIBER-X.IP6.A.NET. A6 40 0:0:0011:: A.NET.IP6.D.NET.
+
+        SUBSCRIBER-X.IP6.B.NET. A6 40 0:0:0022:: B-NET.IP6.E.NET.
+
+        A.NET.IP6.C.NET. A6 28 0:0001:CA00:: C.NET.ALPHA-TLA.ORG.
+
+        A.NET.IP6.D.NET. A6 28 0:0002:DA00:: D.NET.ALPHA-TLA.ORG.
+
+        B-NET.IP6.E.NET. A6 32 0:0:EB00::    E.NET.ALPHA-TLA.ORG.
+
+        C.NET.ALPHA-TLA.ORG. A6 0 2345:00C0::
+        D.NET.ALPHA-TLA.ORG. A6 0 2345:00D0::
+        E.NET.ALPHA-TLA.ORG. A6 0 2345:000E::
+
+5.1.2.  Glue
+
+   When, as is common, some or all DNS servers for X.EXAMPLE are within
+   the X.EXAMPLE zone itself, the top-level zone EXAMPLE must carry
+   enough "glue" information to enable DNS clients to reach those
+   nameservers.  This is true in IPv6 just as in IPv4.  However, the A6
+   record affords the DNS administrator some choices.  The glue could be
+   any of
+
+   o  a minimal set of A6 records duplicated from the X.EXAMPLE zone,
+
+   o  a (possibly smaller) set of records which collapse the structure
+      of that minimal set,
+
+   o  or a set of A6 records with prefix length zero, giving the entire
+      global addresses of the servers.
+
+   The trade-off is ease of maintenance against robustness.  The best
+   and worst of both may be had together by implementing either the
+   first or second option together with the third.  To illustrate the
+   glue options, suppose that X.EXAMPLE is served by two nameservers
+   NS1.X.EXAMPLE and NS2.X.EXAMPLE, having interface identifiers
+   ::1:11:111:1111 and ::2:22:222:2222 on subnets 1 and 2 respectively.
+   Then the top-level zone EXAMPLE would include one (or more) of the
+   following sets of A6 records as glue.
+
+
+
+
+
+
+
+
+
+Crawford, et al.            Standards Track                    [Page 10]
+
+RFC 2874                        IPv6 DNS                       July 2000
+
+
+   $ORIGIN EXAMPLE.            ; first option
+   X               NS NS1.X
+                   NS NS2.X
+   NS1.X           A6 64 ::1:11:111:1111 SUBNET-1.IP6.X
+   NS2.X           A6 64 ::2:22:222:2222 SUBNET-2.IP6.X
+   SUBNET-1.IP6.X  A6 48 0:0:0:1::       IP6.X
+   SUBNET-2.IP6.X  A6 48 0:0:0:2::       IP6.X
+   IP6.X           A6 48 0::0            SUBSCRIBER-X.IP6.A.NET.
+   IP6.X           A6 48 0::0            SUBSCRIBER-X.IP6.B.NET.
+
+
+   $ORIGIN EXAMPLE.            ; second option
+   X               NS NS1.X
+                   NS NS2.X
+   NS1.X           A6 48 ::1:1:11:111:1111 SUBSCRIBER-X.IP6.A.NET.
+                   A6 48 ::1:1:11:111:1111 SUBSCRIBER-X.IP6.B.NET.
+   NS2.X           A6 48 ::2:2:22:222:2222 SUBSCRIBER-X.IP6.A.NET.
+                   A6 48 ::2:2:22:222:2222 SUBSCRIBER-X.IP6.B.NET.
+
+
+   $ORIGIN EXAMPLE.            ; third option
+   X               NS NS1.X
+                   NS NS2.X
+   NS1.X           A6 0  2345:00C1:CA11:1:1:11:111:1111
+                   A6 0  2345:00D2:DA11:1:1:11:111:1111
+                   A6 0  2345:000E:EB22:1:1:11:111:1111
+   NS2.X           A6 0  2345:00C1:CA11:2:2:22:222:2222
+                   A6 0  2345:00D2:DA11:2:2:22:222:2222
+                   A6 0  2345:000E:EB22:2:2:22:222:2222
+
+   The first and second glue options are robust against renumbering of
+   X.EXAMPLE's prefixes by providers A.NET and B.NET, but will fail if
+   those providers' own DNS is unreachable.  The glue records of the
+   third option are robust against DNS failures elsewhere than the zones
+   EXAMPLE and X.EXAMPLE themselves, but must be updated when X's
+   address space is renumbered.
+
+   If the EXAMPLE zone includes redundant glue, for instance the union
+   of the A6 records of the first and third options, then under normal
+   circumstances duplicate IPv6 addresses will be derived by DNS
+   clients.  But if provider DNS fails, addresses will still be obtained
+   from the zero-prefix-length records, while if the EXAMPLE zone lags
+   behind a renumbering of X.EXAMPLE, half of the addresses obtained by
+   DNS clients will still be up-to-date.
+
+   The zero-prefix-length glue records can of course be automatically
+   generated and/or checked in practice.
+
+
+
+
+Crawford, et al.            Standards Track                    [Page 11]
+
+RFC 2874                        IPv6 DNS                       July 2000
+
+
+5.1.3.  Variations
+
+   Several more-or-less arbitrary assumptions are reflected in the above
+   structure.  All of the following choices could have been made
+   differently, according to someone's notion of convenience or an
+   agreement between two parties.
+
+      First, that site X has chosen to put subnet information in a
+      separate A6 record rather than incorporate it into each node's A6
+      records.
+
+      Second, that site X is referred to as "SUBSCRIBER-X" by both of
+      its providers A and B.
+
+      Third, that site X chose to indirect its provider information
+      through A6 records at IP6.X.EXAMPLE containing no significant
+      bits.  An alternative would have been to replicate each subnet
+      record for each provider.
+
+      Fourth, B and E used a slightly different prefix naming convention
+      between themselves than did A, C and D.  Each hierarchical pair of
+      network entities must arrange this naming between themselves.
+
+      Fifth, that the upward prefix referral chain topped out at ALPHA-
+      TLA.ORG.  There could have been another level which assigned the
+      TLA values and holds A6 records containing those bits.
+
+   Finally, the above structure reflects an assumption that address
+   fields assigned by a given entity are recorded only in A6 records
+   held by that entity.  Those bits could be entered into A6 records in
+   the lower-level entity's zone instead, thus:
+
+                IP6.X.EXAMPLE. A6 40 0:0:11::   IP6.A.NET.
+                IP6.X.EXAMPLE. A6 40 0:0:22::   IP6.B.NET.
+
+                IP6.A.NET.     A6 28 0:1:CA00:: IP6.C.NET.
+                and so on.
+
+   Or the higher-level entities could hold both sorts of A6 records
+   (with different DNS owner names) and allow the lower-level entities
+   to choose either mode of A6 chaining.  But the general principle of
+   avoiding data duplication suggests that the proper place to store
+   assigned values is with the entity that assigned them.
+
+   It is possible, but not necessarily recommended, for a zone
+   maintainer to forego the renumbering support afforded by the chaining
+   of A6 records and to record entire IPv6 addresses within one zone
+   file.
+
+
+
+Crawford, et al.            Standards Track                    [Page 12]
+
+RFC 2874                        IPv6 DNS                       July 2000
+
+
+5.2.  Reverse Mapping Zones
+
+   Supposing that address space assignments in the TLAs with Format
+   Prefix (001) binary and IDs 0345, 0678 and 09AB were maintained in
+   zones called ALPHA-TLA.ORG, BRAVO-TLA.ORG and CHARLIE-TLA.XY, then
+   the IP6.ARPA zone would include
+
+               $ORIGIN IP6.ARPA.
+               \[x234500/24]   DNAME   IP6.ALPHA-TLA.ORG.
+               \[x267800/24]   DNAME   IP6.BRAVO-TLA.ORG.
+               \[x29AB00/24]   DNAME   IP6.CHARLIE-TLA.XY.
+
+   Eight trailing zero bits have been included in each TLA ID to reflect
+   the eight reserved bits in the current aggregatable global unicast
+   addresses format [AGGR].
+
+5.2.1.  The TLA level
+
+   ALPHA-TLA's assignments to network providers C, D and E are reflected
+   in the reverse data as follows.
+
+              \[xC/4].IP6.ALPHA-TLA.ORG.   DNAME  IP6.C.NET.
+              \[xD/4].IP6.ALPHA-TLA.ORG.   DNAME  IP6.D.NET.
+              \[x0E/8].IP6.ALPHA-TLA.ORG.  DNAME  IP6.E.NET.
+
+5.2.2.  The ISP level
+
+   The providers A through E carry the following delegation information
+   in their zone files.
+
+               \[x1CA/12].IP6.C.NET.  DNAME  IP6.A.NET.
+               \[x2DA/12].IP6.D.NET.  DNAME  IP6.A.NET.
+               \[xEB/8].IP6.E.NET.    DNAME  IP6.B.NET.
+               \[x11/8].IP6.A.NET.    DNAME  IP6.X.EXAMPLE.
+               \[x22/8].IP6.B.NET.    DNAME  IP6.X.EXAMPLE.
+
+   Note that some domain names appear in the RDATA of more than one
+   DNAME record.  In those cases, one zone is being used to map multiple
+   prefixes.
+
+5.2.3.  The Site Level
+
+   Consider the customer X.EXAMPLE using IP6.X.EXAMPLE for address-to-
+   name translations.  This domain is now referenced by two different
+   DNAME records held by two different providers.
+
+
+
+
+
+
+Crawford, et al.            Standards Track                    [Page 13]
+
+RFC 2874                        IPv6 DNS                       July 2000
+
+
+           $ORIGIN IP6.X.EXAMPLE.
+           \[x0001/16]                    DNAME   SUBNET-1
+           \[x123456789ABCDEF0].SUBNET-1  PTR     N.X.EXAMPLE.
+           and so on.
+
+   SUBNET-1 need not have been named in a DNAME record; the subnet bits
+   could have been joined with the interface identifier.  But if subnets
+   are treated alike in both the A6 records and in the reverse zone, it
+   will always be possible to keep the forward and reverse definition
+   data for each prefix in one zone.
+
+5.3.  Lookups
+
+   A DNS resolver looking for a hostname for the address
+   2345:00C1:CA11:0001:1234:5678:9ABC:DEF0 would acquire certain of the
+   DNAME records shown above and would form new queries.  Assuming that
+   it began the process knowing servers for IP6.ARPA, but that no server
+   it consulted provided recursion and none had other useful additional
+   information cached, the sequence of queried names and responses would
+   be (all with QCLASS=IN, QTYPE=PTR):
+
+   To a server for IP6.ARPA:
+   QNAME=\[x234500C1CA110001123456789ABCDEF0/128].IP6.ARPA.
+
+        Answer:
+        \[x234500/24].IP6.ARPA. DNAME IP6.ALPHA-TLA.ORG.
+
+   To a server for IP6.ALPHA-TLA.ORG:
+   QNAME=\[xC1CA110001123456789ABCDEF0/104].IP6.ALPHA-TLA.ORG.
+
+        Answer:
+        \[xC/4].IP6.ALPHA-TLA.ORG. DNAME IP6.C.NET.
+
+   To a server for IP6.C.NET.:
+   QNAME=\[x1CA110001123456789ABCDEF0/100].IP6.C.NET.
+
+        Answer:
+        \[x1CA/12].IP6.C.NET. DNAME IP6.A.NET.
+
+   To a server for IP6.A.NET.:
+   QNAME=\[x110001123456789ABCDEF0/88].IP6.A.NET.
+
+        Answer:
+        \[x11/8].IP6.A.NET. DNAME IP6.X.EXAMPLE.
+
+   To a server for IP6.X.EXAMPLE.:
+   QNAME=\[x0001123456789ABCDEF0/80].IP6.X.EXAMPLE.
+
+
+
+
+Crawford, et al.            Standards Track                    [Page 14]
+
+RFC 2874                        IPv6 DNS                       July 2000
+
+
+        Answer:
+        \[x0001/16].IP6.X.EXAMPLE. DNAME SUBNET-1.IP6.X.EXAMPLE.
+        \[x123456789ABCDEF0/64].SUBNET-1.X.EXAMPLE. PTR N.X.EXAMPLE.
+
+   All the DNAME (and NS) records acquired along the way can be cached
+   to expedite resolution of addresses topologically near to this
+   address.  And if another global address of N.X.EXAMPLE were resolved
+   within the TTL of the final PTR record, that record would not have to
+   be fetched again.
+
+5.4.  Operational Note
+
+   In the illustrations in section 5.1, hierarchically adjacent
+   entities, such as a network provider and a customer, must agree on a
+   DNS name which will own the definition of the delegated prefix(es).
+   One simple convention would be to use a bit-string label representing
+   exactly the bits which are assigned to the lower-level entity by the
+   higher.  For example, "SUBSCRIBER-X" could be replaced by "\[x11/8]".
+   This would place the A6 record(s) defining the delegated prefix at
+   exactly the same point in the DNS tree as the DNAME record associated
+   with that delegation.  The cost of this simplification is that the
+   lower-level zone must update its upward-pointing A6 records when it
+   is renumbered.  This cost may be found quite acceptable in practice.
+
+6.  Transition from RFC 1886 and Deployment Notes
+
+   When prefixes have been "delegated upward" with A6 records, the
+   number of DNS resource records required to establish a single IPv6
+   address increases by some non-trivial factor.  Those records will
+   typically, but not necessarily, come from different DNS zones (which
+   can independently suffer failures for all the usual reasons).  When
+   obtaining multiple IPv6 addresses together, this increase in RR count
+   will be proportionally less -- and the total size of a DNS reply
+   might even decrease -- if the addresses are topologically clustered.
+   But the records could still easily exceed the space available in a
+   UDP response which returns a large RRset [DNSCLAR] to an MX, NS, or
+   SRV query, for example.  The possibilities for overall degradation of
+   performance and reliability of DNS lookups are numerous, and increase
+   with the number of prefix delegations involved, especially when those
+   delegations point to records in other zones.
+
+   DNS Security [DNSSEC] addresses the trustworthiness of cached data,
+   which is a problem intrinsic to DNS, but the cost of applying this to
+   an IPv6 address is multiplied by a factor which may be greater than
+   the number of prefix delegations involved if different signature
+   chains must be verified for different A6 records.  If a trusted
+   centralized caching server (as in [TSIG], for example) is used, this
+   cost might be amortized to acceptable levels.  One new phenomenon is
+
+
+
+Crawford, et al.            Standards Track                    [Page 15]
+
+RFC 2874                        IPv6 DNS                       July 2000
+
+
+   the possibility that IPv6 addresses may be formed from a A6 records
+   from a combination of secure and unsecured zones.
+
+   Until more deployment experience is gained with the A6 record, it is
+   recommended that prefix delegations be limited to one or two levels.
+   A reasonable phasing-in mechanism would be to start with no prefix
+   delegations (all A6 records having prefix length 0) and then to move
+   to the use of a single level of delegation within a single zone.  (If
+   the TTL of the "prefix" A6 records is kept to an appropriate duration
+   the capability for rapid renumbering is not lost.)  More aggressively
+   flexible delegation could be introduced for a subset of hosts for
+   experimentation.
+
+6.1.  Transition from AAAA and Coexistence with A Records
+
+   Administrators of zones which contain A6 records can easily
+   accommodate deployed resolvers which understand AAAA records but not
+   A6 records.  Such administrators can do automatic generation of AAAA
+   records for all of a zone's names which own A6 records by a process
+   which mimics the resolution of a hostname to an IPv6 address (see
+   section 3.1.4).  Attention must be paid to the TTL assigned to a
+   generated AAAA record, which MUST be no more than the minimum of the
+   TTLs of the A6 records that were used to form the IPv6 address in
+   that record.  For full robustness, those A6 records which were in
+   different zones should be monitored for changes (in TTL or RDATA)
+   even when there are no changes to zone for which AAAA records are
+   being generated.  If the zone is secure [DNSSEC], the generated AAAA
+   records MUST be signed along with the rest of the zone data.
+
+   A zone-specific heuristic MAY be used to avoid generation of AAAA
+   records for A6 records which record prefixes, although such
+   superfluous records would be relatively few in number and harmless.
+   Examples of such heuristics include omitting A6 records with a prefix
+   length less than the largest value found in the zone file, or records
+   with an address suffix field with a certain number of trailing zero
+   bits.
+
+   On the client side, when looking up and IPv6 address, the order of A6
+   and AAAA queries MAY be configurable to be one of: A6, then AAAA;
+   AAAA, then A6; A6 only; or both in parallel.  The default order (or
+   only order, if not configurable) MUST be to try A6 first, then AAAA.
+   If and when the AAAA becomes deprecated a new document will change
+   the default.
+
+   The guidelines and options for precedence between IPv4 and IPv6
+   addresses are specified in [TRANS].  All mentions of AAAA records in
+   that document are henceforth to be interpreted as meaning A6 and/or
+   AAAA records in the order specified in the previous paragraph.
+
+
+
+Crawford, et al.            Standards Track                    [Page 16]
+
+RFC 2874                        IPv6 DNS                       July 2000
+
+
+6.2.  Transition from Nibble Labels to Binary Labels
+
+   Implementations conforming to RFC 1886 [AAAA] perform reverse lookups
+   as follows:
+
+      An IPv6 address is represented as a name in the IP6.INT domain by
+      a sequence of nibbles separated by dots with the suffix
+      ".IP6.INT". The sequence of nibbles is encoded in reverse order,
+      i.e. the low-order nibble is encoded first, followed by the next
+      low-order nibble and so on. Each nibble is represented by a
+      hexadecimal digit. For example, a name for the address
+      2345:00C1:CA11:0001:1234:5678:9ABC:DEF0 of the example in section
+      5.3 would be sought at the DNS name "0.f.e.d.c.b.a.9.-
+      8.7.6.5.4.3.2.1.1.0.0.0.1.1.a.c.1.c.0.0.5.4.3.2.ip6.int."
+
+   Implementations conforming to this specification will perform a
+   lookup of a binary label in IP6.ARPA as specified in Section 3.2.  It
+   is RECOMMENDED that for a transition period implementations first
+   lookup the binary label in IP6.ARPA and if this fails try to lookup
+   the 'nibble' label in IP6.INT.
+
+7.  Security Considerations
+
+   The signing authority [DNSSEC] for the A6 records which determine an
+   IPv6 address is distributed among several entities, reflecting the
+   delegation path of the address space which that address occupies.
+   DNS Security is fully applicable to bit-string labels and DNAME
+   records.  And just as in IPv4, verification of name-to-address
+   mappings is logically independent of verification of address-to-name
+   mappings.
+
+   With or without DNSSEC, the incomplete but non-empty address set
+   scenario of section 3.1.4 could be caused by selective interference
+   with DNS lookups.  If in some situation this would be more harmful
+   than complete DNS failure, it might be mitigated on the client side
+   by refusing to act on an incomplete set, or on the server side by
+   listing all addresses in A6 records with prefix length 0.
+
+8.  IANA Considerations
+
+   The A6 resource record has been assigned a Type value of 38.
+
+
+
+
+
+
+
+
+
+
+Crawford, et al.            Standards Track                    [Page 17]
+
+RFC 2874                        IPv6 DNS                       July 2000
+
+
+9.  Acknowledgments
+
+   The authors would like to thank the following persons for valuable
+   discussions and reviews:  Mark Andrews, Rob Austein, Jim Bound, Randy
+   Bush, Brian Carpenter, David Conrad, Steve Deering, Francis Dupont,
+   Robert Elz, Bob Fink, Olafur Gudmundsson, Bob Halley, Bob Hinden,
+   Edward Lewis, Bill Manning, Keith Moore, Thomas Narten, Erik
+   Nordmark, Mike O'Dell, Michael Patton and Ken Powell.
+
+10.  References
+
+   [AAAA]    Thomson, S. and C. Huitema, "DNS Extensions to support IP
+             version 6, RFC 1886, December 1995.
+
+   [AARCH]   Hinden, R. and S. Deering, "IP Version 6 Addressing
+             Architecture", RFC 2373, July 1998.
+
+   [AGGR]    Hinden, R., O'Dell, M. and S. Deering, "An IPv6
+             Aggregatable Global Unicast Address Format", RFC 2374, July
+             1998.
+
+   [BITLBL]  Crawford, M., "Binary Labels in the Domain Name System",
+             RFC 2673, August 1999.
+
+   [DNAME]   Crawford, M., "Non-Terminal DNS Name Redirection", RFC
+             2672, August 1999.
+
+   [DNSCLAR] Elz, R. and R. Bush, "Clarifications to the DNS
+             Specification", RFC 2181, July 1997.
+
+   [DNSIS]   Mockapetris, P., "Domain names - implementation and
+             specification", STD 13, RFC 1035, November 1987.
+
+   [DNSSEC]  Eastlake, D. 3rd and C. Kaufman, "Domain Name System
+             Security Extensions", RFC 2535, March 1999.
+
+   [KWORD]   Bradner, S., "Key words for use in RFCs to Indicate
+             Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RENUM1]  Carpenter, B. and Y. Rekhter, "Renumbering Needs Work", RFC
+             1900, February 1996.
+
+   [RENUM2]  Ferguson, P. and H. Berkowitz, "Network Renumbering
+             Overview:  Why would I want it and what is it anyway?", RFC
+             2071, January 1997.
+
+   [RENUM3]  Carpenter, B., Crowcroft, J. and Y. Rekhter, "IPv4 Address
+             Behaviour Today", RFC 2101, February 1997.
+
+
+
+Crawford, et al.            Standards Track                    [Page 18]
+
+RFC 2874                        IPv6 DNS                       July 2000
+
+
+   [TRANS]   Gilligan, R. and E. Nordmark, "Transition Mechanisms for
+             IPv6 Hosts and Routers", RFC 1933, April 1996.
+
+   [TSIG]    Vixie, P., Gudmundsson, O., Eastlake, D. 3rd and B.
+             Wellington, "Secret Key Transaction Authentication for DNS
+             (TSIG)", RFC 2845, May 2000.
+
+11.  Authors' Addresses
+
+   Matt Crawford
+   Fermilab
+   MS 368
+   PO Box 500
+   Batavia, IL 60510
+   USA
+
+   Phone: +1 630 840-3461
+   EMail: crawdad@fnal.gov
+
+
+   Christian Huitema
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA 98052-6399
+
+   EMail: huitema@microsoft.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Crawford, et al.            Standards Track                    [Page 19]
+
+RFC 2874                        IPv6 DNS                       July 2000
+
+
+12.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2000).  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 Standards process must be
+   followed, or as required to translate it into 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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Crawford, et al.            Standards Track                    [Page 20]
+
diff --git a/doc/rfc/rfc2915.txt b/doc/rfc/rfc2915.txt
new file mode 100644
index 0000000..2022ba1
--- /dev/null
+++ b/doc/rfc/rfc2915.txt
@@ -0,0 +1,1011 @@
+
+
+
+
+
+
+Network Working Group                                         M. Mealling
+Request for Comments: 2915                        Network Solutions, Inc.
+Updates: 2168                                                   R. Daniel
+Category: Standards Track                                DATAFUSION, Inc.
+                                                           September 2000
+
+
+        The Naming Authority Pointer (NAPTR) DNS Resource Record
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2000). All Rights Reserved.
+
+Abstract
+
+   This document describes a Domain Name System (DNS) resource record
+   which specifies a regular expression based rewrite rule that, when
+   applied to an existing string, will produce a new domain label or
+   Uniform Resource Identifier (URI).  Depending on the value of the
+   flags field of the resource record, the resulting domain label or URI
+   may be used in subsequent queries for the Naming Authority Pointer
+   (NAPTR) resource records (to delegate the name lookup) or as the
+   output of the entire process for which this system is used (a
+   resolution server for URI resolution, a service URI for ENUM style
+   e.164 number to URI mapping, etc).
+
+   This allows the DNS to be used to lookup services for a wide variety
+   of resource names (including URIs) which are not in domain name
+   syntax.  Reasons for doing this range from URN Resource Discovery
+   Systems to moving out-of-date services to new domains.
+
+   This document updates the portions of RFC 2168 specifically dealing
+   with the definition of the NAPTR records and how other, non-URI
+   specific applications, might use NAPTR.
+
+
+
+
+
+
+
+
+
+Mealling & Daniel           Standards Track                     [Page 1]
+
+RFC 2915                      NAPTR DNS RR                September 2000
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . .   2
+   2.  NAPTR RR Format  . . . . . . . . . . . . . . . . . . . . . .   3
+   3.  Substitution Expression Grammar  . . . . . . . . . . . . . .   7
+   4.  The Basic NAPTR Algorithm  . . . . . . . . . . . . . . . . .   8
+   5.  Concerning How NAPTR Uses SRV Records  . . . . . . . . . . .   9
+   6.  Application Specifications . . . . . . . . . . . . . . . . .  10
+   7.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . .  10
+   7.1 Example 1  . . . . . . . . . . . . . . . . . . . . . . . . .  10
+   7.2 Example 2  . . . . . . . . . . . . . . . . . . . . . . . . .  12
+   7.3 Example 3  . . . . . . . . . . . . . . . . . . . . . . . . .  13
+   8.  DNS Packet Format  . . . . . . . . . . . . . . . . . . . . .  13
+   9.  Master File Format . . . . . . . . . . . . . . . . . . . . .  14
+   10. Advice for DNS Administrators  . . . . . . . . . . . . . . .  14
+   11. Notes  . . . . . . . . . . . . . . . . . . . . . . . . . . .  15
+   12. IANA Considerations  . . . . . . . . . . . . . . . . . . . .  15
+   13. Security Considerations  . . . . . . . . . . . . . . . . . .  15
+   14. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . .  16
+       References . . . . . . . . . . . . . . . . . . . . . . . . .  16
+       Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  17
+       Full Copyright Statement . . . . . . . . . . . . . . . . . .  18
+
+1. Introduction
+
+   This RR was originally produced by the URN Working Group [3] as a way
+   to encode rule-sets in DNS so that the delegated sections of a URI
+   could be decomposed in such a way that they could be changed and re-
+   delegated over time.  The result was a Resource Record that included
+   a regular expression that would be used by a client program to
+   rewrite a string into a domain name.  Regular expressions were chosen
+   for their compactness to expressivity ratio allowing for a great deal
+   of information to be encoded in a rather small DNS packet.
+
+   The function of rewriting a string according to the rules in a record
+   has usefulness in several different applications.  This document
+   defines the basic assumptions to which all of those applications must
+   adhere to.  It does not define the reasons the rewrite is used, what
+   the expected outcomes are, or what they are used for.  Those are
+   specified by applications that define how they use the NAPTR record
+   and algorithms within their contexts.
+
+   Flags and other fields are also specified in the RR to control the
+   rewrite procedure in various ways or to provide information on how to
+   communicate with the host at the domain name that was the result of
+   the rewrite.
+
+
+
+
+
+Mealling & Daniel           Standards Track                     [Page 2]
+
+RFC 2915                      NAPTR DNS RR                September 2000
+
+
+   The final result is a RR that has several fields that interact in a
+   non-trivial but implementable way.  This document specifies those
+   fields and their values.
+
+   This document does not define applications that utilizes this rewrite
+   functionality. Instead it specifies just the mechanics of how it is
+   done.  Why its done, what the rules concerning the inputs, and the
+   types of rules used are reserved for other documents that fully
+   specify a particular application.  This separation is due to several
+   different applications all wanting to take advantage of the rewrite
+   rule lookup process.  Each one has vastly different reasons for why
+   and how it uses the service, thus requiring that the definition of
+   the service be generic.
+
+      The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
+      NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
+      in this document are to be interpreted as described in RFC 2119.
+
+      All references to Uniform Resource Identifiers in this document
+      adhere to the 'absoluteURI' production of the "Collected ABNF"
+      found in RFC 2396 [9].  Specifically, the semantics of URI
+      References do not apply since the concept of a Base makes no sense
+      here.
+
+2. NAPTR RR Format
+
+   The format of the NAPTR RR is given below.  The DNS type code [1] for
+   NAPTR is 35.
+
+   Domain TTL Class Type Order Preference Flags Service Regexp
+   Replacement
+
+   Domain
+      The domain name to which this resource record refers.  This is the
+      'key' for this entry in the rule database.  This value will either
+      be the first well known key (<something>.uri.arpa for example) or
+      a new key that is the output of a replacement or regexp rewrite.
+      Beyond this, it has the standard DNS requirements [1].
+
+   TTL
+      Standard DNS meaning [1].
+
+   Class
+      Standard DNS meaning [1].
+
+   Type
+      The Type Code [1] for NAPTR is 35.
+
+
+
+
+Mealling & Daniel           Standards Track                     [Page 3]
+
+RFC 2915                      NAPTR DNS RR                September 2000
+
+
+   Order
+      A 16-bit unsigned integer specifying the order in which the NAPTR
+      records MUST be processed to ensure the correct ordering of
+      rules.  Low numbers are processed before high numbers, and once a
+      NAPTR is found whose rule "matches" the target, the client MUST
+      NOT consider any NAPTRs with a higher value for order (except as
+      noted below for the Flags field).
+
+   Preference
+      A 16-bit unsigned integer that specifies the order in which NAPTR
+      records with equal "order" values SHOULD be processed, low
+      numbers being processed before high numbers.  This is similar to
+      the preference field in an MX record, and is used so domain
+      administrators can direct clients towards more capable hosts or
+      lighter weight protocols.  A client MAY look at records with
+      higher preference values if it has a good reason to do so such as
+      not understanding the preferred protocol or service.
+
+      The important difference between Order and Preference is that
+      once a match is found the client MUST NOT consider records with a
+      different Order but they MAY process records with the same Order
+      but different Preferences.  I.e., Preference is used to give weight
+      to rules that are considered the same from an authority
+      standpoint but not from a simple load balancing standpoint.
+
+   Flags
+      A <character-string> containing flags to control aspects of the
+      rewriting and interpretation of the fields in the record.  Flags
+      are single characters from the set [A-Z0-9].  The case of the
+      alphabetic characters is not significant.
+
+      At this time only four flags, "S", "A", "U", and "P", are
+      defined.  The "S", "A" and "U" flags denote a terminal lookup.
+      This means that this NAPTR record is the last one and that the
+      flag determines what the next stage should be.  The "S" flag
+      means that the next lookup should be for SRV records [4].  See
+      Section 5 for additional information on how NAPTR uses the SRV
+      record type.  "A" means that the next lookup should be for either
+      an A, AAAA, or A6 record.  The "U" flag means that the next step
+      is not a DNS lookup but that the output of the Regexp field is an
+      URI that adheres to the 'absoluteURI' production found in the
+      ABNF of RFC 2396 [9].  Since there may be applications that use
+      NAPTR to also lookup aspects of URIs, implementors should be
+      aware that this may cause loop conditions and should act
+      accordingly.
+
+
+
+
+
+
+Mealling & Daniel           Standards Track                     [Page 4]
+
+RFC 2915                      NAPTR DNS RR                September 2000
+
+
+      The "P" flag says that the remainder of the application side
+      algorithm shall be carried out in a Protocol-specific fashion.
+      The new set of rules is identified by the Protocol specified in
+      the Services field.  The record that contains the 'P' flag is the
+      last record that is interpreted by the rules specified in this
+      document.  The new rules are dependent on the application for
+      which they are being used and the protocol specified.  For
+      example, if the application is a URI RDS and the protocol is WIRE
+      then the new set of rules are governed by the algorithms
+      surrounding the WIRE HTTP specification and not this document.
+
+      The remaining alphabetic flags are reserved for future versions
+      of the NAPTR specification.  The numeric flags may be used for
+      local experimentation.  The S, A, U and P flags are all mutually
+      exclusive, and resolution libraries MAY signal an error if more
+      than one is given.  (Experimental code and code for assisting in
+      the creation of NAPTRs would be more likely to signal such an
+      error than a client such as a browser).  It is anticipated that
+      multiple flags will be allowed in the future, so implementers
+      MUST NOT assume that the flags field can only contain 0 or 1
+      characters.  Finally, if a client encounters a record with an
+      unknown flag, it MUST ignore it and move to the next record.  This
+      test takes precedence even over the "order" field.  Since flags
+      can control the interpretation placed on fields, a novel flag
+      might change the interpretation of the regexp and/or replacement
+      fields such that it is impossible to determine if a record
+      matched a given target.
+
+      The "S", "A", and "U"  flags are called 'terminal' flags since
+      they halt the looping rewrite algorithm.  If those flags are not
+      present, clients may assume that another NAPTR RR exists at the
+      domain name produced by the current rewrite rule.  Since the "P"
+      flag specifies a new algorithm, it may or may not be 'terminal'.
+      Thus, the client cannot assume that another NAPTR exists since
+      this case is determined elsewhere.
+
+      DNS servers MAY interpret these flags and values and use that
+      information to include appropriate SRV and A,AAAA, or A6 records
+      in the additional information portion of the DNS packet.  Clients
+      are encouraged to check for additional information but are not
+      required to do so.
+
+   Service
+      Specifies the service(s) available down this rewrite path.  It may
+      also specify the particular protocol that is used to talk with a
+      service.  A protocol MUST be specified if the flags field states
+      that the NAPTR is terminal.  If a protocol is specified, but the
+      flags field does not state that the NAPTR is terminal, the next
+
+
+
+Mealling & Daniel           Standards Track                     [Page 5]
+
+RFC 2915                      NAPTR DNS RR                September 2000
+
+
+      lookup MUST be for a NAPTR.  The client MAY choose not to perform
+      the next lookup if the protocol is unknown, but that behavior
+      MUST NOT be relied upon.
+
+      The service field may take any of the values below (using the
+      Augmented BNF of RFC 2234 [5]):
+
+                 service_field = [ [protocol] *("+" rs)]
+                 protocol      = ALPHA *31ALPHANUM
+                 rs            = ALPHA *31ALPHANUM
+                 ; The protocol and rs fields are limited to 32
+                 ; characters and must start with an alphabetic.
+
+      For example, an optional protocol specification followed by 0 or
+      more resolution services.  Each resolution service is indicated by
+      an initial '+' character.
+
+      Note that the empty string is also a valid service field.  This
+      will typically be seen at the beginning of a series of rules,
+      when it is impossible to know what services and protocols will be
+      offered by a particular service.
+
+      The actual format of the service request and response will be
+      determined by the resolution protocol, and is the subject for
+      other documents.  Protocols need not offer all services.  The
+      labels for service requests shall be formed from the set of
+      characters [A-Z0-9].  The case of the alphabetic characters is
+      not significant.
+
+      The list of "valid" protocols for any given NAPTR record is any
+      protocol that implements some or all of the services defined for
+      a NAPTR application.  Currently, THTTP [6] is the only protocol
+      that is known to make that claim at the time of publication.  Any
+      other protocol that is to be used must have documentation
+      specifying:
+
+      *  how it implements the services of the application
+
+      *  how it is to appear in the NAPTR record (i.e., the string id
+         of the protocol)
+
+      The list of valid Resolution Services is defined by the documents
+      that specify individual NAPTR based applications.
+
+      It is worth noting that the interpretation of this field is
+      subject to being changed by new flags, and that the current
+      specification is oriented towards telling clients how to talk
+      with a URN resolver.
+
+
+
+Mealling & Daniel           Standards Track                     [Page 6]
+
+RFC 2915                      NAPTR DNS RR                September 2000
+
+
+   Regexp
+      A STRING containing a substitution expression that is applied to
+      the original string held by the client in order to construct the
+      next domain name to lookup.  The grammar of the substitution
+      expression is given in the next section.
+
+      The regular expressions MUST NOT be used in a cumulative fashion,
+      that is, they should only be applied to the original string held
+      by the client, never to the domain name produced by a previous
+      NAPTR rewrite.  The latter is tempting in some applications but
+      experience has shown such use to be extremely fault sensitive,
+      very error prone, and extremely difficult to debug.
+
+   Replacement
+      The next NAME to query for NAPTR, SRV, or address records
+      depending on the value of the flags field.  This MUST be a fully
+      qualified domain-name. Unless and until permitted by future
+      standards action, name compression is not to be used for this
+      field.
+
+3. Substitution Expression Grammar
+
+   The content of the regexp field is a substitution expression.  True
+   sed(1) and Perl style substitution expressions are not appropriate
+   for use in this application for a variety of reasons stemming from
+   internationalization requirements and backref limitations, therefore
+   the contents of the regexp field MUST follow the grammar below:
+
+subst_expr   = delim-char  ere  delim-char  repl  delim-char  *flags
+delim-char   = "/" / "!" / ... <Any non-digit or non-flag character
+               other than backslash '\'. All occurances of a delim_char
+               in a subst_expr must be the same character.>
+ere          = POSIX Extended Regular Expression
+repl         = 1 * ( OCTET /  backref )
+backref      = "\" 1POS_DIGIT
+flags        = "i"
+POS_DIGIT    = %x31-39                 ; 0 is not an allowed backref
+
+   The definition of a POSIX Extended Regular Expression can be found in
+   [8], section 2.8.4.
+
+   The result of applying the substitution expression to the original
+   URI MUST result in either a string that obeys the syntax for DNS
+   domain-names [1] or a URI [9] if the Flags field contains a 'u'.
+   Since it is possible for the regexp field to be improperly specified,
+   such that a non-conforming domain-name can be constructed, client
+   software SHOULD verify that the result is a legal DNS domain-name
+   before making queries on it.
+
+
+
+Mealling & Daniel           Standards Track                     [Page 7]
+
+RFC 2915                      NAPTR DNS RR                September 2000
+
+
+   Backref expressions in the repl portion of the substitution
+   expression are replaced by the (possibly empty) string of characters
+   enclosed by '(' and ')' in the ERE portion of the substitution
+   expression. N is a single digit from 1 through 9, inclusive.  It
+   specifies the N'th backref expression, the one that begins with the
+   N'th '(' and continues to the matching ')'.  For example, the ERE
+
+                            (A(B(C)DE)(F)G)
+
+         has backref expressions:
+
+                            \1  = ABCDEFG
+                            \2  = BCDE
+                            \3  = C
+                            \4  = F
+                            \5..\9  = error - no matching subexpression
+
+   The "i" flag indicates that the ERE matching SHALL be performed in a
+   case-insensitive fashion. Furthermore, any backref replacements MAY
+   be normalized to lower case when the "i" flag is given.
+
+   The first character in the substitution expression shall be used as
+   the character that delimits the components of the substitution
+   expression.  There must be exactly three non-escaped occurrences of
+   the delimiter character in a substitution expression.  Since escaped
+   occurrences of the delimiter character will be interpreted as
+   occurrences of that character, digits MUST NOT be used as delimiters.
+   Backrefs would be confused with literal digits were this allowed.
+   Similarly, if flags are specified in the substitution expression, the
+   delimiter character must not also be a flag character.
+
+4. The Basic NAPTR Algorithm
+
+   The behavior and meaning of the flags and services assume an
+   algorithm where the output of one rewrite is a new key that points to
+   another rule.  This looping algorithm allows NAPTR records to
+   incrementally specify a complete rule.  These incremental rules can
+   be delegated which allows other entities to specify rules so that one
+   entity does not need to understand _all_ rules.
+
+   The algorithm starts with a string and some known key (domain).
+   NAPTR records for this key are retrieved, those with unknown Flags or
+   inappropriate Services are discarded and the remaining records are
+   sorted by their Order field.  Within each value of Order, the records
+   are further sorted by the Preferences field.
+
+   The records are examined in sorted order until a matching record is
+   found.  A record is considered a match iff:
+
+
+
+Mealling & Daniel           Standards Track                     [Page 8]
+
+RFC 2915                      NAPTR DNS RR                September 2000
+
+
+   o  it has a Replacement field value instead of a Regexp field value.
+
+   o  or the Regexp field matches the string held by the client.
+
+   The first match MUST be the match that is used.  Once a match is
+   found, the Services field is examined for whether or not this rule
+   advances toward the desired result.  If so, the rule is applied to
+   the target string.  If not, the process halts.  The domain that
+   results from the regular expression is then used as the domain of the
+   next loop through the NAPTR algorithm.  Note that the same target
+   string is used throughout the algorithm.
+
+   This looping is extremely important since it is the method by which
+   complex rules are broken down into manageable delegated chunks.  The
+   flags fields simply determine at which point the looping should stop
+   (or other specialized behavior).
+
+   Since flags are valid at any level of the algorithm, the degenerative
+   case is to never loop but to look up the NAPTR and then stop.  In
+   many specialized cases this is all that is needed.  Implementors
+   should be aware that the degenerative case should not become the
+   common case.
+
+5. Concerning How NAPTR Uses SRV Records
+
+   When the SRV record type was originally specified it assumed that the
+   client did not know the specific domain-name before hand.  The client
+   would construct a domain-name more in the form of a question than the
+   usual case of knowing ahead of time that the domain-name should
+   exist.  I.e., if the client wants to know if there is a TCP based
+   HTTP server running at a particular domain, the client would
+   construct the domain-name _http._tcp.somedomain.com and ask the DNS
+   if that records exists. The underscores are used to avoid collisions
+   with potentially 'real' domain-names.
+
+   In the case of NAPTR, the actual domain-name is specified by the
+   various fields in the NAPTR record.  In this case the client isn't
+   asking a question but is instead attempting to get at information
+   that it has been told exists in an SRV record at that particular
+   domain-name.  While this usage of SRV is slightly different than the
+   SRV authors originally intended it does not break any of the
+   assumptions concerning what SRV contains.  Also, since the NAPTR
+   explicitly spells out the domain-name for which an SRV exists, that
+   domain-name MUST be used in SRV queries with NO transformations.  Any
+   given NAPTR record may result in a domain-name to be used for SRV
+   queries that may or may not contain the SRV standardized underscore
+
+
+
+
+
+Mealling & Daniel           Standards Track                     [Page 9]
+
+RFC 2915                      NAPTR DNS RR                September 2000
+
+
+   characters.  NAPTR applications that make use of SRV MUST NOT attempt
+   to understand these domains or use them according to how the SRV
+   specification structures its query domains.
+
+6. Application Specifications
+
+   It should be noted that the NAPTR algorithm is the basic assumption
+   about how NAPTR works.  The reasons for the rewrite and the expected
+   output and its use are specified by documents that define what
+   applications the NAPTR record and algorithm are used for.  Any
+   document that defines such an application must define the following:
+
+   o  The first known domain-name or how to build it
+
+   o  The valid Services and Protocols
+
+   o  What the expected use is for the output of the last rewrite
+
+   o  The validity and/or behavior of any 'P' flag protocols.
+
+   o  The general semantics surrounding why and how NAPTR and its
+      algorithm are being used.
+
+7. Examples
+
+   NOTE: These are examples only.  They are taken from ongoing work and
+   may not represent the end result of that work. They are here for
+   pedagogical reasons only.
+
+7.1 Example 1
+
+   NAPTR was originally specified for use with the a Uniform Resource
+   Name Resolver Discovery System.  This example details how a
+   particular URN would use the NAPTR record to find a resolver service.
+
+   Consider a URN namespace based on MIME Content-Ids.  The URN might
+   look like this:
+
+      urn:cid:39CB83F7.A8450130@fake.gatech.edu
+
+   (Note that this example is chosen for pedagogical purposes, and does
+   not conform to the CID URL scheme.)
+
+   The first step in the resolution process is to find out about the CID
+   namespace.  The namespace identifier [3], 'cid', is extracted from
+   the URN, prepended to urn.arpa. 'cid.urn.arpa' then becomes the first
+   'known' key in the NAPTR algorithm.  The NAPTR records for
+   cid.urn.arpa looked up and return a single record:
+
+
+
+Mealling & Daniel           Standards Track                    [Page 10]
+
+RFC 2915                      NAPTR DNS RR                September 2000
+
+
+   cid.urn.arpa.
+   ;;       order pref flags service        regexp           replacement
+   IN NAPTR 100   10   ""  ""  "/urn:cid:.+@([^\.]+\.)(.*)$/\2/i"    .
+
+   There is only one NAPTR response, so ordering the responses is not a
+   problem.  The replacement field is empty, so the pattern provided in
+   the regexp field is used.  We apply that regexp to the entire URN to
+   see if it matches, which it does.  The \2 part of the substitution
+   expression returns the string "gatech.edu".  Since the flags field
+   does not contain "s" or "a", the lookup is not terminal and our next
+   probe to DNS is for more NAPTR records where the new domain is '
+   gatech.edu' and the string is the same string as before.
+
+   Note that the rule does not extract the full domain name from the
+   CID, instead it assumes the CID comes from a host and extracts its
+   domain.  While all hosts, such as mordred, could have their very own
+   NAPTR, maintaining those records for all the machines at a site as
+   large as Georgia Tech would be an intolerable burden.  Wildcards are
+   not appropriate here since they only return results when there is no
+   exactly matching names already in the system.
+
+   The record returned from the query on "gatech.edu" might look like:
+
+;;       order pref flags service           regexp  replacement
+ IN NAPTR 100  50  "s"  "z3950+I2L+I2C"     ""  _z3950._tcp.gatech.edu.
+ IN NAPTR 100  50  "s"  "rcds+I2C"          ""  _rcds._udp.gatech.edu.
+ IN NAPTR 100  50  "s"  "http+I2L+I2C+I2R"  ""  _http._tcp.gatech.edu.
+
+   Continuing with the example, note that the values of the order and
+   preference fields are equal in all records, so the client is free to
+   pick any record.  The flags field tells us that these are the last
+   NAPTR patterns we should see, and after the rewrite (a simple
+   replacement in this case) we should look up SRV records to get
+   information on the hosts that can provide the necessary service.
+
+   Assuming we prefer the Z39.50 protocol, our lookup might return:
+
+ ;;                        Pref Weight   Port Target
+ _z3950._tcp.gatech.edu. IN SRV 0    0      1000 z3950.gatech.edu.
+                         IN SRV 0    0      1000 z3950.cc.gatech.edu.
+                         IN SRV 0    0      1000 z3950.uga.edu.
+
+   telling us three hosts that could actually do the resolution, and
+   giving us the port we should use to talk to their Z39.50 server.
+
+   Recall that the regular expression used \2 to extract a domain name
+   from the CID, and \. for matching the literal '.' characters
+   separating the domain name components. Since '\' is the escape
+
+
+
+Mealling & Daniel           Standards Track                    [Page 11]
+
+RFC 2915                      NAPTR DNS RR                September 2000
+
+
+   character, literal occurances of a backslash must be escaped by
+   another backslash.  For the case of the cid.urn.arpa record above,
+   the regular expression entered into the master file should be
+   "/urn:cid:.+@([^\\.]+\\.)(.*)$/\\2/i".  When the client code actually
+   receives the record, the pattern will have been converted to
+   "/urn:cid:.+@([^\.]+\.)(.*)$/\2/i".
+
+7.2 Example 2
+
+   Even if URN systems were in place now, there would still be a
+   tremendous number of URLs.  It should be possible to develop a URN
+   resolution system that can also provide location independence for
+   those URLs.  This is related to the requirement that URNs be able to
+   grandfather in names from other naming systems, such as ISO Formal
+   Public Identifiers, Library of Congress Call Numbers, ISBNs, ISSNs,
+   etc.
+
+   The NAPTR RR could also be used for URLs that have already been
+   assigned.  Assume we have the URL for a very popular piece of
+   software that the publisher wishes to mirror at multiple sites around
+   the world:
+
+   Using the rules specified for this application we extract the prefix,
+   "http", and lookup NAPTR records for http.uri.arpa.  This might
+   return a record of the form
+
+     http.uri.arpa. IN NAPTR
+     ;;  order   pref flags service      regexp             replacement
+          100     90   ""      ""   "!http://([^/:]+)!\1!i"       .
+
+   This expression returns everything after the first double slash and
+   before the next slash or colon.  (We use the '!' character to delimit
+   the parts of the substitution expression.  Otherwise we would have to
+   use backslashes to escape the forward slashes and would have a regexp
+   in the zone file that looked like "/http:\\/\\/([^\\/:]+)/\\1/i".).
+
+   Applying this pattern to the URL extracts "www.foo.com".  Looking up
+   NAPTR records for that might return:
+
+     www.foo.com.
+     ;;       order pref flags   service  regexp     replacement
+      IN NAPTR 100  100  "s"   "http+I2R"   ""    _http._tcp.foo.com.
+      IN NAPTR 100  100  "s"   "ftp+I2R"    ""    _ftp._tcp.foo.com.
+
+   Looking up SRV records for http.tcp.foo.com would return information
+   on the hosts that foo.com has designated to be its mirror sites.  The
+   client can then pick one for the user.
+
+
+
+
+Mealling & Daniel           Standards Track                    [Page 12]
+
+RFC 2915                      NAPTR DNS RR                September 2000
+
+
+7.3 Example 3
+
+   A non-URI example is the ENUM application which uses a NAPTR record
+   to map an e.164 telephone number to a URI.  In order to convert the
+   phone number to a domain name for the first iteration all characters
+   other than digits are removed from the the telephone number, the
+   entire number is inverted, periods are put between each digit and the
+   string ".e164.arpa" is put on the left-hand side.  For example, the
+   E.164 phone number "+1-770-555-1212" converted to a domain-name it
+   would be "2.1.2.1.5.5.5.0.7.7.1.e164.arpa."
+
+   For this example telephone number we might get back the following
+   NAPTR records:
+
+$ORIGIN 2.1.2.1.5.5.5.0.7.7.1.e164.arpa.
+ IN NAPTR 100 10 "u" "sip+E2U"  "!^.*$!sip:information@tele2.se!"     .
+ IN NAPTR 102 10 "u" "mailto+E2U" "!^.*$!mailto:information@tele2.se!"  .
+
+   This application uses the same 'u' flag as the URI Resolution
+   application. This flag states that the Rule is terminal and that the
+   output is a URI which contains the information needed to contact that
+   telephone service.  ENUM also uses the same format for its Service
+   field except that it defines the 'E2U' service instead of the 'I2*'
+   services that URI resolution uses.  The example above states that the
+   available protocols used to access that telephone's service are
+   either the Session Initiation Protocol or SMTP mail.
+
+8. DNS Packet Format
+
+         The packet format for the NAPTR record is:
+
+                                          1  1  1  1  1  1
+            0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
+          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+          |                     ORDER                     |
+          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+          |                   PREFERENCE                  |
+          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+          /                     FLAGS                     /
+          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+          /                   SERVICES                    /
+          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+          /                    REGEXP                     /
+          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+          /                  REPLACEMENT                  /
+          /                                               /
+          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+
+
+
+Mealling & Daniel           Standards Track                    [Page 13]
+
+RFC 2915                      NAPTR DNS RR                September 2000
+
+
+    where:
+
+   FLAGS A <character-string> which contains various flags.
+
+   SERVICES A <character-string> which contains protocol and service
+      identifiers.
+
+   REGEXP A <character-string> which contains a regular expression.
+
+   REPLACEMENT A <domain-name> which specifies the new value in the
+      case where the regular expression is a simple replacement
+      operation.
+
+   <character-string> and <domain-name> as used here are defined in
+   RFC1035 [1].
+
+9. Master File Format
+
+   The master file format follows the standard rules in RFC-1035 [1].
+   Order and preference, being 16-bit unsigned integers, shall be an
+   integer between 0 and 65535.  The Flags and Services and Regexp
+   fields are all quoted <character-string>s.  Since the Regexp field
+   can contain numerous backslashes and thus should be treated with
+   care.  See Section 10 for how to correctly enter and escape the
+   regular expression.
+
+10. Advice for DNS Administrators
+
+   Beware of regular expressions.  Not only are they difficult to get
+   correct on their own, but there is the previously mentioned
+   interaction with DNS.  Any backslashes in a regexp must be entered
+   twice in a zone file in order to appear once in a query response.
+   More seriously, the need for double backslashes has probably not been
+   tested by all implementors of DNS servers.
+
+   The "a" flag allows the next lookup to be for address records (A,
+   AAAA, A6) rather than SRV records.  Since there is no place for a
+   port specification in the NAPTR record, when the "A" flag is used the
+   specified protocol must be running on its default port.
+
+   The URN Syntax draft defines a canonical form for each URN, which
+   requires %encoding characters outside a limited repertoire.  The
+   regular expressions MUST be written to operate on that canonical
+   form.  Since international character sets will end up with extensive
+   use of %encoded characters, regular expressions operating on them
+   will be essentially impossible to read or write by hand.
+
+
+
+
+
+Mealling & Daniel           Standards Track                    [Page 14]
+
+RFC 2915                      NAPTR DNS RR                September 2000
+
+
+11. Notes
+
+   o  A client MUST process multiple NAPTR records in the order
+      specified by the "order" field, it MUST NOT simply use the first
+      record that provides a known protocol and service combination.
+
+   o  When multiple RRs have the same "order" and all other criteria
+      being equal, the client should use the value of the preference
+      field to select the next NAPTR to consider.  However, because it
+      will often be the case where preferred protocols or services
+      exist, clients may use this additional criteria to sort
+      the records.
+
+   o  If the lookup after a rewrite fails, clients are strongly
+      encouraged to report a failure, rather than backing up to pursue
+      other rewrite paths.
+
+   o  Note that SRV RRs impose additional requirements on clients.
+
+12. IANA Considerations
+
+   The only registration function that impacts the IANA is for the
+   values that are standardized for the Services and Flags fields.  To
+   extend the valid values of the Flags field beyond what is specified
+   in this document requires a published specification that is approved
+   by the IESG.
+
+   The values for the Services field will be determined by the
+   application that makes use of the NAPTR record.  Those values must be
+   specified in a published specification and approved by the IESG.
+
+13. Security Considerations
+
+   The interactions with DNSSEC are currently being studied.  It is
+   expected that NAPTR records will be signed with SIG records once the
+   DNSSEC work is deployed.
+
+   The rewrite rules make identifiers from other namespaces subject to
+   the same attacks as normal domain names.  Since they have not been
+   easily resolvable before, this may or may not be considered a
+   problem.
+
+   Regular expressions should be checked for sanity, not blindly passed
+   to something like PERL.
+
+   This document has discussed a way of locating a service, but has not
+   discussed any detail of how the communication with that service takes
+   place.  There are significant security considerations attached to the
+
+
+
+Mealling & Daniel           Standards Track                    [Page 15]
+
+RFC 2915                      NAPTR DNS RR                September 2000
+
+
+   communication with a service.  Those considerations are outside the
+   scope of this document, and must be addressed by the specifications
+   for particular communication protocols.
+
+14. Acknowledgments
+
+   The editors would like to thank Keith Moore for all his consultations
+   during the development of this memo.  We would also like to thank
+   Paul Vixie for his assistance in debugging our implementation, and
+   his answers on our questions.  Finally, we would like to acknowledge
+   our enormous intellectual debt to the participants in the Knoxville
+   series of meetings, as well as to the participants in the URI and URN
+   working groups.
+
+References
+
+   [1]  Mockapetris, P., "Domain names - implementation and
+        specification", STD 13, RFC 1035, November 1987.
+
+   [2]  Mockapetris, P., "Domain names - concepts and facilities", STD
+        13, RFC 1034, November 1987.
+
+   [3]  Moats, R., "URN Syntax", RFC 2141, May 1997.
+
+   [4]  Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for
+        specifying the location of services (DNS SRV)", RFC 2782,
+        February 2000.
+
+   [5]  Crocker, D., "Augmented BNF for Syntax Specifications: ABNF",
+        RFC 2234, November 1997.
+
+   [6]  Daniel, R., "A Trivial Convention for using HTTP in URN
+        Resolution", RFC 2169, June 1997.
+
+   [7]  Daniel, R. and M. Mealling, "Resolution of Uniform Resource
+        Identifiers using the Domain Name System", RFC 2168, June 1997.
+
+   [8]  IEEE, "IEEE Standard for Information Technology - Portable
+        Operating System Interface (POSIX) - Part 2: Shell and Utilities
+        (Vol. 1)", IEEE Std 1003.2-1992, January 1993.
+
+   [9]  Berners-Lee, T., Fielding, R.T. and L. Masinter, "Uniform
+        Resource Identifiers (URI): Generic Syntax", RFC 2396, August
+        1998.
+
+
+
+
+
+
+
+Mealling & Daniel           Standards Track                    [Page 16]
+
+RFC 2915                      NAPTR DNS RR                September 2000
+
+
+Authors' Addresses
+
+   Michael Mealling
+   Network Solutions, Inc.
+   505 Huntmar Park Drive
+   Herndon, VA  22070
+   US
+
+   Phone: +1 770 921 2251
+   EMail: michaelm@netsol.com
+   URI:   http://www.netsol.com
+
+
+   Ron Daniel
+   DATAFUSION, Inc.
+   139 Townsend Street, Ste. 100
+   San Francisco, CA  94107
+   US
+
+   Phone: +1 415 222 0100
+   EMail: rdaniel@datafusion.net
+   URI:   http://www.datafusion.net
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mealling & Daniel           Standards Track                    [Page 17]
+
+RFC 2915                      NAPTR DNS RR                September 2000
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2000).  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 Standards process must be
+   followed, or as required to translate it into 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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mealling & Daniel           Standards Track                    [Page 18]
+
diff --git a/doc/rfc/rfc2929.txt b/doc/rfc/rfc2929.txt
new file mode 100644
index 0000000..f055968
--- /dev/null
+++ b/doc/rfc/rfc2929.txt
@@ -0,0 +1,675 @@
+
+
+
+
+
+
+Network Working Group                                   D. Eastlake, 3rd
+Request for Comments: 2929                                      Motorola
+BCP: 42                                              E. Brunner-Williams
+Category: Best Current Practice                                   Engage
+                                                              B. Manning
+                                                                     ISI
+                                                          September 2000
+
+              Domain Name System (DNS) IANA Considerations
+
+Status of this Memo
+
+   This document specifies an Internet Best Current Practices for the
+   Internet Community, and requests discussion and suggestions for
+   improvements.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2000).  All Rights Reserved.
+
+Abstract
+
+   Internet Assigned Number Authority (IANA) parameter assignment
+   considerations are given for the allocation of Domain Name System
+   (DNS) classes, Resource Record (RR) types, operation codes, error
+   codes, etc.
+
+Table of Contents
+
+   1. Introduction.................................................  2
+   2. DNS Query/Response Headers...................................  2
+   2.1 One Spare Bit?..............................................  3
+   2.2 Opcode Assignment...........................................  3
+   2.3 RCODE Assignment............................................  4
+   3. DNS Resource Records.........................................  5
+   3.1 RR TYPE IANA Considerations.................................  6
+   3.1.1 Special Note on the OPT RR................................  7
+   3.2 RR CLASS IANA Considerations................................  7
+   3.3 RR NAME Considerations......................................  8
+   4. Security Considerations......................................  9
+   References......................................................  9
+   Authors' Addresses.............................................. 11
+   Full Copyright Statement........................................ 12
+
+
+
+
+
+
+
+
+Eastlake, et al.         Best Current Practice                  [Page 1]
+
+RFC 2929                DNS IANA Considerations           September 2000
+
+
+1. Introduction
+
+   The Domain Name System (DNS) provides replicated distributed secure
+   hierarchical databases which hierarchically store "resource records"
+   (RRs) under domain names.
+
+   This data is structured into CLASSes and zones which can be
+   independently maintained.  See [RFC 1034, 1035, 2136, 2181, 2535]
+   familiarity with which is assumed.
+
+   This document covers, either directly or by reference, general IANA
+   parameter assignment considerations applying across DNS query and
+   response headers and all RRs.  There may be additional IANA
+   considerations that apply to only a particular RR type or
+   query/response opcode.  See the specific RFC defining that RR type or
+   query/response opcode for such considerations if they have been
+   defined.
+
+   IANA currently maintains a web page of DNS parameters.  See
+   <http://www.iana.org/numbers.htm>.
+
+   "IETF Standards Action", "IETF Consensus", "Specification Required",
+   and "Private Use" are as defined in [RFC 2434].
+
+2. DNS Query/Response Headers
+
+   The header for DNS queries and responses contains field/bits in the
+   following diagram taken from [RFC 2136, 2535]:
+
+                                           1  1  1  1  1  1
+             0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
+            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+            |                      ID                       |
+            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+            |QR|   Opcode  |AA|TC|RD|RA| Z|AD|CD|   RCODE   |
+            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+            |                QDCOUNT/ZOCOUNT                |
+            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+            |                ANCOUNT/PRCOUNT                |
+            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+            |                NSCOUNT/UPCOUNT                |
+            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+            |                    ARCOUNT                    |
+            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+   The ID field identifies the query and is echoed in the response so
+   they can be matched.
+
+
+
+
+Eastlake, et al.         Best Current Practice                  [Page 2]
+
+RFC 2929                DNS IANA Considerations           September 2000
+
+
+   The QR bit indicates whether the header is for a query or a response.
+
+   The AA, TC, RD, RA, AD, and CD bits are each theoretically meaningful
+   only in queries or only in responses, depending on the bit.  However,
+   many DNS implementations copy the query header as the initial value
+   of the response header without clearing bits.  Thus any attempt to
+   use a "query" bit with a different meaning in a response or to define
+   a query meaning for a "response" bit is dangerous given existing
+   implementation.  Such meanings may only be assigned by an IETF
+   Standards Action.
+
+   The unsigned fields query count (QDCOUNT), answer count (ANCOUNT),
+   authority count (NSCOUNT), and additional information count (ARCOUNT)
+   express the number of records in each section for all opcodes except
+   Update.  These fields have the same structure and data type for
+   Update but are instead the counts for the zone (ZOCOUNT),
+   prerequisite (PRCOUNT), update (UPCOUNT), and additional information
+   (ARCOUNT) sections.
+
+2.1 One Spare Bit?
+
+   There have been ancient DNS implementations for which the Z bit being
+   on in a query meant that only a response from the primary server for
+   a zone is acceptable.  It is believed that current DNS
+   implementations ignore this bit.
+
+   Assigning a meaning to the Z bit requires an IETF Standards Action.
+
+2.2 Opcode Assignment
+
+   New OpCode assignments require an IETF Standards Action.
+
+   Currently DNS OpCodes are assigned as follows:
+
+       OpCode Name                      Reference
+
+        0     Query                     [RFC 1035]
+        1     IQuery  (Inverse Query)   [RFC 1035]
+        2     Status                    [RFC 1035]
+        3     available for assignment
+        4     Notify                    [RFC 1996]
+        5     Update                    [RFC 2136]
+       6-15   available for assignment
+
+
+
+
+
+
+
+
+Eastlake, et al.         Best Current Practice                  [Page 3]
+
+RFC 2929                DNS IANA Considerations           September 2000
+
+
+2.3 RCODE Assignment
+
+   It would appear from the DNS header above that only four bits of
+   RCODE, or response/error code are available.  However, RCODEs can
+   appear not only at the top level of a DNS response but also inside
+   OPT RRs [RFC 2671], TSIG RRs [RFC 2845], and TKEY RRs [RFC 2930].
+   The OPT RR provides an eight bit extension resulting in a 12 bit
+   RCODE field and the TSIG and TKEY RRs have a 16 bit RCODE field.
+
+   Error codes appearing in the DNS header and in these three RR types
+   all refer to the same error code space with the single exception of
+   error code 16 which has a different meaning in the OPT RR from its
+   meaning in other contexts.  See table below.
+
+   RCODE   Name    Description                        Reference
+   Decimal
+     Hexadecimal
+    0    NoError   No Error                           [RFC 1035]
+    1    FormErr   Format Error                       [RFC 1035]
+    2    ServFail  Server Failure                     [RFC 1035]
+    3    NXDomain  Non-Existent Domain                [RFC 1035]
+    4    NotImp    Not Implemented                    [RFC 1035]
+    5    Refused   Query Refused                      [RFC 1035]
+    6    YXDomain  Name Exists when it should not     [RFC 2136]
+    7    YXRRSet   RR Set Exists when it should not   [RFC 2136]
+    8    NXRRSet   RR Set that should exist does not  [RFC 2136]
+    9    NotAuth   Server Not Authoritative for zone  [RFC 2136]
+   10    NotZone   Name not contained in zone         [RFC 2136]
+   11-15           available for assignment
+   16    BADVERS   Bad OPT Version                    [RFC 2671]
+   16    BADSIG    TSIG Signature Failure             [RFC 2845]
+   17    BADKEY    Key not recognized                 [RFC 2845]
+   18    BADTIME   Signature out of time window       [RFC 2845]
+   19    BADMODE   Bad TKEY Mode                      [RFC 2930]
+   20    BADNAME   Duplicate key name                 [RFC 2930]
+   21    BADALG    Algorithm not supported            [RFC 2930]
+   22-3840         available for assignment
+     0x0016-0x0F00
+   3841-4095       Private Use
+     0x0F01-0x0FFF
+   4096-65535      available for assignment
+     0x1000-0xFFFF
+
+   Since it is important that RCODEs be understood for interoperability,
+   assignment of new RCODE listed above as "available for assignment"
+   requires an IETF Consensus.
+
+
+
+
+
+Eastlake, et al.         Best Current Practice                  [Page 4]
+
+RFC 2929                DNS IANA Considerations           September 2000
+
+
+3. DNS Resource Records
+
+   All RRs have the same top level format shown in the figure below
+   taken from [RFC 1035]:
+
+                                         1  1  1  1  1  1
+           0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
+         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+         |                                               |
+         /                                               /
+         /                      NAME                     /
+         |                                               |
+         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+         |                      TYPE                     |
+         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+         |                     CLASS                     |
+         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+         |                      TTL                      |
+         |                                               |
+         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+         |                   RDLENGTH                    |
+         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--|
+         /                     RDATA                     /
+         /                                               /
+         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+   NAME is an owner name, i.e., the name of the node to which this
+   resource record pertains.  NAMEs are specific to a CLASS as described
+   in section 3.2.  NAMEs consist of an ordered sequence of one or more
+   labels each of which has a label type [RFC 1035, 2671].
+
+   TYPE is a two octet unsigned integer containing one of the RR TYPE
+   codes.  See section 3.1.
+
+   CLASS is a two octet unsigned integer containing one of the RR CLASS
+   codes.  See section 3.2.
+
+   TTL is a four octet (32 bit) bit unsigned integer that specifies the
+   number of seconds that the resource record may be cached before the
+   source of the information should again be consulted.  Zero is
+   interpreted to mean that the RR can only be used for the transaction
+   in progress.
+
+   RDLENGTH is an unsigned 16 bit integer that specifies the length in
+   octets of the RDATA field.
+
+
+
+
+
+
+Eastlake, et al.         Best Current Practice                  [Page 5]
+
+RFC 2929                DNS IANA Considerations           September 2000
+
+
+   RDATA is a variable length string of octets that constitutes the
+   resource.  The format of this information varies according to the
+   TYPE and in some cases the CLASS of the resource record.
+
+3.1 RR TYPE IANA Considerations
+
+   There are three subcategories of RR TYPE numbers: data TYPEs, QTYPEs,
+   and MetaTYPEs.
+
+   Data TYPEs are the primary means of storing data.  QTYPES can only be
+   used in queries.  Meta-TYPEs designate transient data associated with
+   an particular DNS message and in some cases can also be used in
+   queries.  Thus far, data TYPEs have been assigned from 1 upwards plus
+   the block from 100 through 103 while Q and Meta Types have been
+   assigned from 255 downwards (except for the OPT Meta-RR which is
+   assigned TYPE 41).  There have been DNS implementations which made
+   caching decisions based on the top bit of the bottom byte of the RR
+   TYPE.
+
+   There are currently three Meta-TYPEs assigned: OPT [RFC 2671], TSIG
+   [RFC 2845], and TKEY [RFC 2930].
+
+   There are currently five QTYPEs assigned: * (all), MAILA, MAILB,
+   AXFR, and IXFR.
+
+   Considerations for the allocation of new RR TYPEs are as follows:
+
+     Decimal
+   Hexadecimal
+
+     0
+   0x0000 - TYPE zero is used as a special indicator for the SIG RR [RFC
+          2535] and in other circumstances and must never be allocated
+          for ordinary use.
+
+     1 - 127
+   0x0001 - 0x007F - remaining TYPEs in this range are assigned for data
+          TYPEs by IETF Consensus.
+
+     128 - 255
+   0x0080 - 0x00FF - remaining TYPEs in this rage are assigned for Q and
+          Meta TYPEs by IETF Consensus.
+
+     256 - 32767
+   0x0100 - 0x7FFF - assigned for data, Q, or Meta TYPE use by IETF
+          Consensus.
+
+
+
+
+
+Eastlake, et al.         Best Current Practice                  [Page 6]
+
+RFC 2929                DNS IANA Considerations           September 2000
+
+
+     32768 - 65279
+   0x8000 - 0xFEFF - Specification Required as defined in [RFC 2434].
+
+     65280 - 65535
+   0xFF00 - 0xFFFF - Private Use.
+
+3.1.1 Special Note on the OPT RR
+
+   The OPT (OPTion) RR, number 41, is specified in [RFC 2671].  Its
+   primary purpose is to extend the effective field size of various DNS
+   fields including RCODE, label type, flag bits, and RDATA size.  In
+   particular, for resolvers and servers that recognize it, it extends
+   the RCODE field from 4 to 12 bits.
+
+3.2 RR CLASS IANA Considerations
+
+   DNS CLASSes have been little used but constitute another dimension of
+   the DNS distributed database.  In particular, there is no necessary
+   relationship between the name space or root servers for one CLASS and
+   those for another CLASS.  The same name can have completely different
+   meanings in different CLASSes although the label types are the same
+   and the null label is usable only as root in every CLASS.  However,
+   as global networking and DNS have evolved, the IN, or Internet, CLASS
+   has dominated DNS use.
+
+   There are two subcategories of DNS CLASSes: normal data containing
+   classes and QCLASSes that are only meaningful in queries or updates.
+
+   The current CLASS assignments and considerations for future
+   assignments are as follows:
+
+     Decimal
+   Hexadecimal
+
+     0
+   0x0000 - assignment requires an IETF Standards Action.
+
+     1
+   0x0001 - Internet (IN).
+
+     2
+   0x0002 - available for assignment by IETF Consensus as a data CLASS.
+
+     3
+   0x0003 - Chaos (CH) [Moon 1981].
+
+     4
+   0x0004 - Hesiod (HS) [Dyer 1987].
+
+
+
+Eastlake, et al.         Best Current Practice                  [Page 7]
+
+RFC 2929                DNS IANA Considerations           September 2000
+
+
+     5 - 127
+   0x0005 - 0x007F - available for assignment by IETF Consensus as data
+          CLASSes only.
+
+     128 - 253
+   0x0080 - 0x00FD - available for assignment by IETF Consensus as
+          QCLASSes only.
+
+     254
+   0x00FE - QCLASS None [RFC 2136].
+
+     255
+   0x00FF - QCLASS Any [RFC 1035].
+
+     256 - 32767
+   0x0100 - 0x7FFF - assigned by IETF Consensus.
+
+     32768 - 65280
+   0x8000 - 0xFEFF - assigned based on Specification Required as defined
+          in [RFC 2434].
+
+     65280 - 65534
+   0xFF00 - 0xFFFE - Private Use.
+
+     65535
+   0xFFFF - can only be assigned by an IETF Standards Action.
+
+3.3 RR NAME Considerations
+
+   DNS NAMEs are sequences of labels [RFC 1035].  The last label in each
+   NAME is "ROOT" which is the zero length label.  By definition, the
+   null or ROOT label can not be used for any other NAME purpose.
+
+   At the present time, there are two categories of label types, data
+   labels and compression labels.  Compression labels are pointers to
+   data labels elsewhere within an RR or DNS message and are intended to
+   shorten the wire encoding of NAMEs.  The two existing data label
+   types are sometimes referred to as Text and Binary.  Text labels can,
+   in fact, include any octet value including zero octets but most
+   current uses involve only [US-ASCII].  For retrieval, Text labels are
+   defined to treat ASCII upper and lower case letter codes as matching.
+   Binary labels are bit sequences [RFC 2673].
+
+   IANA considerations for label types are given in [RFC 2671].
+
+
+
+
+
+
+
+Eastlake, et al.         Best Current Practice                  [Page 8]
+
+RFC 2929                DNS IANA Considerations           September 2000
+
+
+   NAMEs are local to a CLASS.  The Hesiod [Dyer 1987] and Chaos [Moon
+   1981] CLASSes are essentially for local use.  The IN or Internet
+   CLASS is thus the only DNS CLASS in global use on the Internet at
+   this time.
+
+   A somewhat dated description of name allocation in the IN Class is
+   given in [RFC 1591].  Some information on reserved top level domain
+   names is in Best Current Practice 32 [RFC 2606].
+
+4. Security Considerations
+
+   This document addresses IANA considerations in the allocation of
+   general DNS parameters, not security.  See [RFC 2535] for secure DNS
+   considerations.
+
+References
+
+   [Dyer 1987] Dyer, S., and F. Hsu, "Hesiod", Project Athena Technical
+               Plan - Name Service, April 1987,
+
+   [Moon 1981] D. Moon, "Chaosnet", A.I. Memo 628, Massachusetts
+               Institute of Technology Artificial Intelligence
+               Laboratory, June 1981.
+
+   [RFC 1034]  Mockapetris, P., "Domain Names - Concepts and
+               Facilities", STD 13, RFC 1034, November 1987.
+
+   [RFC 1035]  Mockapetris, P., "Domain Names - Implementation and
+               Specifications", STD 13, RFC 1035, November 1987.
+
+   [RFC 1591]  Postel, J., "Domain Name System Structure and
+               Delegation", RFC 1591, March 1994.
+
+   [RFC 1996]  Vixie, P., "A Mechanism for Prompt Notification of Zone
+               Changes (DNS NOTIFY)", RFC 1996, August 1996.
+
+   [RFC 2136]  Vixie, P., Thomson, S., Rekhter, Y. and J. Bound,
+               "Dynamic Updates in the Domain Name System (DNS UPDATE)",
+               RFC 2136, April 1997.
+
+   [RFC 2181]  Elz, R. and R. Bush, "Clarifications to the DNS
+               Specification", RFC 2181, July 1997.
+
+   [RFC 2434]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
+               IANA Considerations Section in RFCs", BCP 26, RFC 2434,
+               October 1998.
+
+
+
+
+
+Eastlake, et al.         Best Current Practice                  [Page 9]
+
+RFC 2929                DNS IANA Considerations           September 2000
+
+
+   [RFC 2535]  Eastlake, D., "Domain Name System Security Extensions",
+               RFC 2535, March 1999.
+
+   [RFC 2606]  Eastlake, D. and A. Panitz, "Reserved Top Level DNS
+               Names", RFC 2606, June 1999.
+
+   [RFC 2671]  Vixie, P., "Extension mechanisms for DNS (EDNS0)", RFC
+               2671, August 1999.
+
+   [RFC 2672]  Crawford, M., "Non-Terminal DNS Name Redirection", RFC
+               2672, August 1999.
+
+   [RFC 2673]  Crawford, M., "Binary Labels in the Domain Name System",
+               RFC 2673, August 1999.
+
+   [RFC 2845]  Vixie, P., Gudmundsson, O., Eastlake, D. and B.
+               Wellington, "Secret Key Transaction Authentication for
+               DNS (TSIG)", RFC 2845, May 2000.
+
+   [RFC 2930]  Eastlake, D., "Secret Key Establishment for DNS (TKEY
+               RR)", RFC 2930, September 2000.
+
+   [US-ASCII]  ANSI, "USA Standard Code for Information Interchange",
+               X3.4, American National Standards Institute: New York,
+               1968.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake, et al.         Best Current Practice                 [Page 10]
+
+RFC 2929                DNS IANA Considerations           September 2000
+
+
+Authors' Addresses
+
+   Donald E. Eastlake 3rd
+   Motorola
+   140 Forest Avenue
+   Hudson, MA 01749 USA
+
+   Phone: +1-978-562-2827 (h)
+          +1-508-261-5434 (w)
+   Fax:   +1-508-261-4447 (w)
+   EMail: Donald.Eastlake@motorola.com
+
+
+   Eric Brunner-Williams
+   Engage
+   100 Brickstone Square, 2nd Floor
+   Andover, MA 01810
+
+   Phone: +1-207-797-0525 (h)
+          +1-978-684-7796 (w)
+   Fax:   +1-978-684-3118
+   EMail: brunner@engage.com
+
+
+   Bill Manning
+   USC/ISI
+   4676 Admiralty Way, #1001
+   Marina del Rey, CA 90292 USA
+
+   Phone: +1-310-822-1511
+   EMail: bmanning@isi.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake, et al.         Best Current Practice                 [Page 11]
+
+RFC 2929                DNS IANA Considerations           September 2000
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2000).  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 Standards process must be
+   followed, or as required to translate it into 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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake, et al.         Best Current Practice                 [Page 12]
+
diff --git a/doc/rfc/rfc2930.txt b/doc/rfc/rfc2930.txt
new file mode 100644
index 0000000..f99573d
--- /dev/null
+++ b/doc/rfc/rfc2930.txt
@@ -0,0 +1,899 @@
+
+
+
+
+
+
+Network Working Group                                   D. Eastlake, 3rd
+Request for Comments: 2930                                      Motorola
+Category: Standards Track                                 September 2000
+
+
+               Secret Key Establishment for DNS (TKEY RR)
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2000).  All Rights Reserved.
+
+Abstract
+
+   [RFC 2845] provides a means of authenticating Domain Name System
+   (DNS) queries and responses using shared secret keys via the
+   Transaction Signature (TSIG) resource record (RR).  However, it
+   provides no mechanism for setting up such keys other than manual
+   exchange. This document describes a Transaction Key (TKEY) RR that
+   can be used in a number of different modes to establish shared secret
+   keys between a DNS resolver and server.
+
+Acknowledgments
+
+   The comments and ideas of the following persons (listed in alphabetic
+   order) have been incorporated herein and are gratefully acknowledged:
+
+         Olafur Gudmundsson (TIS)
+
+         Stuart Kwan (Microsoft)
+
+         Ed Lewis (TIS)
+
+         Erik Nordmark (SUN)
+
+         Brian Wellington (Nominum)
+
+
+
+
+
+
+
+
+Eastlake                    Standards Track                     [Page 1]
+
+RFC 2930                    The DNS TKEY RR               September 2000
+
+
+Table of Contents
+
+   1. Introduction...............................................  2
+   1.1 Overview of Contents......................................  3
+   2. The TKEY Resource Record...................................  4
+   2.1 The Name Field............................................  4
+   2.2 The TTL Field.............................................  5
+   2.3 The Algorithm Field.......................................  5
+   2.4 The Inception and Expiration Fields.......................  5
+   2.5 The Mode Field............................................  5
+   2.6 The Error Field...........................................  6
+   2.7 The Key Size and Data Fields..............................  6
+   2.8 The Other Size and Data Fields............................  6
+   3. General TKEY Considerations................................  7
+   4. Exchange via Resolver Query................................  8
+   4.1 Query for Diffie-Hellman Exchanged Keying.................  8
+   4.2 Query for TKEY Deletion...................................  9
+   4.3 Query for GSS-API Establishment........................... 10
+   4.4 Query for Server Assigned Keying.......................... 10
+   4.5 Query for Resolver Assigned Keying........................ 11
+   5. Spontaneous Server Inclusion............................... 12
+   5.1 Spontaneous Server Key Deletion........................... 12
+   6. Methods of Encryption...................................... 12
+   7. IANA Considerations........................................ 13
+   8. Security Considerations.................................... 13
+   References.................................................... 14
+   Author's Address.............................................. 15
+   Full Copyright Statement...................................... 16
+
+1. Introduction
+
+   The Domain Name System (DNS) is a hierarchical, distributed, highly
+   available database used for bi-directional mapping between domain
+   names and addresses, for email routing, and for other information
+   [RFC 1034, 1035].  It has been extended to provide for public key
+   security and dynamic update [RFC 2535, RFC 2136].  Familiarity with
+   these RFCs is assumed.
+
+   [RFC 2845] provides a means of efficiently authenticating DNS
+   messages using shared secret keys via the TSIG resource record (RR)
+   but provides no mechanism for setting up such keys other than manual
+   exchange. This document specifies a TKEY RR that can be used in a
+   number of different modes to establish and delete such shared secret
+   keys between a DNS resolver and server.
+
+
+
+
+
+
+
+Eastlake                    Standards Track                     [Page 2]
+
+RFC 2930                    The DNS TKEY RR               September 2000
+
+
+   Note that TKEY established keying material and TSIGs that use it are
+   associated with DNS servers or resolvers.  They are not associated
+   with zones.  They may be used to authenticate queries and responses
+   but they do not provide zone based DNS data origin or denial
+   authentication [RFC 2535].
+
+   Certain modes of TKEY perform encryption which may affect their
+   export or import status for some countries.  The affected modes
+   specified in this document are the server assigned mode and the
+   resolver assigned mode.
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC 2119].
+
+   In all cases herein, the term "resolver" includes that part of a
+   server which may make full and incremental [RFC 1995] zone transfer
+   queries, forwards recursive queries, etc.
+
+1.1 Overview of Contents
+
+   Section 2 below specifies the TKEY RR and provides a description of
+   and considerations for its constituent fields.
+
+   Section 3 describes general principles of operations with TKEY.
+
+   Section 4 discusses key agreement and deletion via DNS requests with
+   the Query opcode for RR type TKEY.  This method is applicable to all
+   currently defined TKEY modes, although in some cases it is not what
+   would intuitively be called a "query".
+
+   Section 5 discusses spontaneous inclusion of TKEY RRs in responses by
+   servers which is currently used only for key deletion.
+
+   Section 6 describes encryption methods for transmitting secret key
+   information. In this document these are used only for the server
+   assigned mode and the resolver assigned mode.
+
+   Section 7 covers IANA considerations in assignment of TKEY modes.
+
+   Finally, Section 8 provides the required security considerations
+   section.
+
+
+
+
+
+
+
+
+
+Eastlake                    Standards Track                     [Page 3]
+
+RFC 2930                    The DNS TKEY RR               September 2000
+
+
+2. The TKEY Resource Record
+
+   The TKEY resource record (RR) has the structure given below.  Its RR
+   type code is 249.
+
+      Field       Type         Comment
+      -----       ----         -------
+
+      NAME         domain      see description below
+      TTYPE        u_int16_t   TKEY = 249
+      CLASS        u_int16_t   ignored, SHOULD be 255 (ANY)
+      TTL          u_int32_t   ignored, SHOULD be zero
+      RDLEN        u_int16_t   size of RDATA
+      RDATA:
+       Algorithm:   domain
+       Inception:   u_int32_t
+       Expiration:  u_int32_t
+       Mode:        u_int16_t
+       Error:       u_int16_t
+       Key Size:    u_int16_t
+       Key Data:    octet-stream
+       Other Size:  u_int16_t
+       Other Data:  octet-stream  undefined by this specification
+
+2.1 The Name Field
+
+   The Name field relates to naming keys.  Its meaning differs somewhat
+   with mode and context as explained in subsequent sections.
+
+   At any DNS server or resolver only one octet string of keying
+   material may be in place for any particular key name.  An attempt to
+   establish another set of keying material at a server for an existing
+   name returns a BADNAME error.
+
+   For a TKEY with a non-root name appearing in a query, the TKEY RR
+   name SHOULD be a domain locally unique at the resolver, less than 128
+   octets long in wire encoding, and meaningful to the resolver to
+   assist in distinguishing keys and/or key agreement sessions.   For
+   TKEY(s) appearing in a response to a query, the TKEY RR name SHOULD
+   be a globally unique server assigned domain.
+
+   A reasonable key naming strategy is as follows:
+
+      If the key is generated as the result of a query with root as its
+      owner name, then the server SHOULD create a globally unique domain
+      name, to be the key name, by suffixing a pseudo-random [RFC 1750]
+      label with a domain name of the server.  For example
+      89n3mDgX072pp.server1.example.com.  If generation of a new
+
+
+
+Eastlake                    Standards Track                     [Page 4]
+
+RFC 2930                    The DNS TKEY RR               September 2000
+
+
+      pseudo-random name in each case is an excessive computation load
+      or entropy drain, a serial number prefix can be added to a fixed
+      pseudo-random name generated an DNS server start time, such as
+      1001.89n3mDgX072pp.server1.example.com.
+
+      If the key is generated as the result of a query with a non-root
+      name, say 789.resolver.example.net, then use the concatenation of
+      that with a name of the server.  For example
+      789.resolver.example.net.server1.example.com.
+
+2.2 The TTL Field
+
+   The TTL field is meaningless in TKEY RRs. It SHOULD always be zero to
+   be sure that older DNS implementations do not cache TKEY RRs.
+
+2.3 The Algorithm Field
+
+   The algorithm name is in the form of a domain name with the same
+   meaning as in [RFC 2845].  The algorithm determines how the secret
+   keying material agreed to using the TKEY RR is actually used to
+   derive the algorithm specific key.
+
+2.4 The Inception and Expiration Fields
+
+   The inception time and expiration times are in number of seconds
+   since the beginning of 1 January 1970 GMT ignoring leap seconds
+   treated as modulo 2**32 using ring arithmetic [RFC 1982]. In messages
+   between a DNS resolver and a DNS server where these fields are
+   meaningful, they are either the requested validity interval for the
+   keying material asked for or specify the validity interval of keying
+   material provided.
+
+   To avoid different interpretations of the inception and expiration
+   times in TKEY RRs, resolvers and servers exchanging them must have
+   the same idea of what time it is.  One way of doing this is with the
+   NTP protocol [RFC 2030] but that or any other time synchronization
+   used for this purpose MUST be done securely.
+
+2.5 The Mode Field
+
+   The mode field specifies the general scheme for key agreement or the
+   purpose of the TKEY DNS message.  Servers and resolvers supporting
+   this specification MUST implement the Diffie-Hellman key agreement
+   mode and the key deletion mode for queries.  All other modes are
+   OPTIONAL.  A server supporting TKEY that receives a TKEY request with
+   a mode it does not support returns the BADMODE error.  The following
+   values of the Mode octet are defined, available, or reserved:
+
+
+
+
+Eastlake                    Standards Track                     [Page 5]
+
+RFC 2930                    The DNS TKEY RR               September 2000
+
+
+         Value    Description
+         -----    -----------
+          0        - reserved, see section 7
+          1       server assignment
+          2       Diffie-Hellman exchange
+          3       GSS-API negotiation
+          4       resolver assignment
+          5       key deletion
+         6-65534   - available, see section 7
+         65535     - reserved, see section 7
+
+2.6 The Error Field
+
+   The error code field is an extended RCODE.  The following values are
+   defined:
+
+         Value   Description
+         -----   -----------
+          0       - no error
+          1-15   a non-extended RCODE
+          16     BADSIG   (TSIG)
+          17     BADKEY   (TSIG)
+          18     BADTIME  (TSIG)
+          19     BADMODE
+          20     BADNAME
+          21     BADALG
+
+   When the TKEY Error Field is non-zero in a response to a TKEY query,
+   the DNS header RCODE field indicates no error. However, it is
+   possible if a TKEY is spontaneously included in a response the TKEY
+   RR and DNS header error field could have unrelated non-zero error
+   codes.
+
+2.7 The Key Size and Data Fields
+
+   The key data size field is an unsigned 16 bit integer in network
+   order which specifies the size of the key exchange data field in
+   octets. The meaning of this data depends on the mode.
+
+2.8 The Other Size and Data Fields
+
+   The Other Size and Other Data fields are not used in this
+   specification but may be used in future extensions.  The RDLEN field
+   MUST equal the length of the RDATA section through the end of Other
+   Data or the RR is to be considered malformed and rejected.
+
+
+
+
+
+
+Eastlake                    Standards Track                     [Page 6]
+
+RFC 2930                    The DNS TKEY RR               September 2000
+
+
+3. General TKEY Considerations
+
+   TKEY is a meta-RR that is not stored or cached in the DNS and does
+   not appear in zone files.  It supports a variety of modes for the
+   establishment and deletion of shared secret keys information between
+   DNS resolvers and servers.  The establishment of such a shared key
+   requires that state be maintained at both ends and the allocation of
+   the resources to maintain such state may require mutual agreement. In
+   the absence of willingness to provide such state, servers MUST return
+   errors such as NOTIMP or REFUSED for an attempt to use TKEY and
+   resolvers are free to ignore any TKEY RRs they receive.
+
+   The shared secret keying material developed by using TKEY is a plain
+   octet sequence.  The means by which this shared secret keying
+   material, exchanged via TKEY, is actually used in any particular TSIG
+   algorithm is algorithm dependent and is defined in connection with
+   that algorithm.  For example, see [RFC 2104] for how TKEY agreed
+   shared secret keying material is used in the HMAC-MD5 algorithm or
+   other HMAC algorithms.
+
+   There MUST NOT be more than one TKEY RR in a DNS query or response.
+
+   Except for GSS-API mode, TKEY responses MUST always have DNS
+   transaction authentication to protect the integrity of any keying
+   data, error codes, etc.  This authentication MUST use a previously
+   established secret (TSIG) or public (SIG(0) [RFC 2931]) key and MUST
+   NOT use any key that the response to be verified is itself providing.
+
+   TKEY queries MUST be authenticated for all modes except GSS-API and,
+   under some circumstances, server assignment mode.  In particular, if
+   the query for a server assigned key is for a key to assert some
+   privilege, such as update authority, then the query must be
+   authenticated to avoid spoofing.  However, if the key is just to be
+   used for transaction security, then spoofing will lead at worst to
+   denial of service.  Query authentication SHOULD use an established
+   secret (TSIG) key authenticator if available.  Otherwise, it must use
+   a public (SIG(0)) key signature.  It MUST NOT use any key that the
+   query is itself providing.
+
+   In the absence of required TKEY authentication, a NOTAUTH error MUST
+   be returned.
+
+   To avoid replay attacks, it is necessary that a TKEY response or
+   query not be valid if replayed on the order of 2**32 second (about
+   136 years), or a multiple thereof, later.  To accomplish this, the
+   keying material used in any TSIG or SIG(0) RR that authenticates a
+   TKEY message MUST NOT have a lifetime of more then 2**31 - 1 seconds
+
+
+
+
+Eastlake                    Standards Track                     [Page 7]
+
+RFC 2930                    The DNS TKEY RR               September 2000
+
+
+   (about 68 years).  Thus, on attempted replay, the authenticating TSIG
+   or SIG(0) RR will not be verifiable due to key expiration and the
+   replay will fail.
+
+4. Exchange via Resolver Query
+
+   One method for a resolver and a server to agree about shared secret
+   keying material for use in TSIG is through DNS requests from the
+   resolver which are syntactically DNS queries for type TKEY.  Such
+   queries MUST be accompanied by a TKEY RR in the additional
+   information section to indicate the mode in use and accompanied by
+   other information where required.
+
+   Type TKEY queries SHOULD NOT be flagged as recursive and servers MAY
+   ignore the recursive header bit in TKEY queries they receive.
+
+4.1 Query for Diffie-Hellman Exchanged Keying
+
+   Diffie-Hellman (DH) key exchange is a means whereby two parties can
+   derive some shared secret information without requiring any secrecy
+   of the messages they exchange [Schneier].  Provisions have been made
+   for the storage of DH public keys in the DNS [RFC 2539].
+
+   A resolver sends a query for type TKEY accompanied by a TKEY RR in
+   the additional information section specifying the Diffie-Hellman mode
+   and accompanied by a KEY RR also in the additional information
+   section specifying a resolver Diffie-Hellman key.  The TKEY RR
+   algorithm field is set to the authentication algorithm the resolver
+   plans to use. The "key data" provided in the TKEY is used as a random
+   [RFC 1750] nonce to avoid always deriving the same keying material
+   for the same pair of DH KEYs.
+
+   The server response contains a TKEY in its answer section with the
+   Diffie-Hellman mode. The "key data" provided in this TKEY is used as
+   an additional nonce to avoid always deriving the same keying material
+   for the same pair of DH KEYs. If the TKEY error field is non-zero,
+   the query failed for the reason given. FORMERR is given if the query
+   included no DH KEY and BADKEY is given if the query included an
+   incompatible DH KEY.
+
+   If the TKEY error field is zero, the resolver supplied Diffie-Hellman
+   KEY RR SHOULD be echoed in the additional information section and a
+   server Diffie-Hellman KEY RR will also be present in the answer
+   section of the response.  Both parties can then calculate the same
+   shared secret quantity from the pair of Diffie-Hellman (DH) keys used
+   [Schneier] (provided these DH keys use the same generator and
+   modulus) and the data in the TKEY RRs.  The TKEY RR data is mixed
+   with the DH result as follows:
+
+
+
+Eastlake                    Standards Track                     [Page 8]
+
+RFC 2930                    The DNS TKEY RR               September 2000
+
+
+      keying material =
+           XOR ( DH value, MD5 ( query data | DH value ) |
+                           MD5 ( server data | DH value ) )
+
+   Where XOR is an exclusive-OR operation and "|" is byte-stream
+   concatenation.  The shorter of the two operands to XOR is byte-wise
+   left justified and padded with zero-valued bytes to match the length
+   of the other operand.  "DH value" is the Diffie-Hellman value derived
+   from the KEY RRs. Query data and server data are the values sent in
+   the TKEY RR data fields.  These "query data" and "server data" nonces
+   are suffixed by the DH value, digested by MD5, the results
+   concatenated, and then XORed with the DH value.
+
+   The inception and expiry times in the query TKEY RR are those
+   requested for the keying material.  The inception and expiry times in
+   the response TKEY RR are the maximum period the server will consider
+   the keying material valid.  Servers may pre-expire keys so this is
+   not a guarantee.
+
+4.2 Query for TKEY Deletion
+
+   Keys established via TKEY can be treated as soft state.  Since DNS
+   transactions are originated by the resolver, the resolver can simply
+   toss keys, although it may have to go through another key exchange if
+   it later needs one.  Similarly, the server can discard keys although
+   that will result in an error on receiving a query with a TSIG using
+   the discarded key.
+
+   To avoid attempted reliance in requests on keys no longer in effect,
+   servers MUST implement key deletion whereby the server "discards" a
+   key on receipt from a resolver of an authenticated delete request for
+   a TKEY RR with the key's name.  If the server has no record of a key
+   with that name, it returns BADNAME.
+
+   Key deletion TKEY queries MUST be authenticated.  This authentication
+   MAY be a TSIG RR using the key to be deleted.
+
+   For querier assigned and Diffie-Hellman keys, the server MUST truly
+   "discard" all active state associated with the key.  For server
+   assigned keys, the server MAY simply mark the key as no longer
+   retained by the client and may re-send it in response to a future
+   query for server assigned keying material.
+
+
+
+
+
+
+
+
+
+Eastlake                    Standards Track                     [Page 9]
+
+RFC 2930                    The DNS TKEY RR               September 2000
+
+
+4.3 Query for GSS-API Establishment
+
+   This mode is described in a separate document under preparation which
+   should be seen for the full description.  Basically the resolver and
+   server can exchange queries and responses for type TKEY with a TKEY
+   RR specifying the GSS-API mode in the additional information section
+   and a GSS-API token in the key data portion of the TKEY RR.
+
+   Any issues of possible encryption of parts the GSS-API token data
+   being transmitted are handled by the GSS-API level.  In addition, the
+   GSS-API level provides its own authentication so that this mode of
+   TKEY query and response MAY be, but do not need to be, authenticated
+   with TSIG RR or SIG(0) RR [RFC 2931].
+
+   The inception and expiry times in a GSS-API mode TKEY RR are ignored.
+
+4.4 Query for Server Assigned Keying
+
+   Optionally, the server can assign keying for the resolver.  It is
+   sent to the resolver encrypted under a resolver public key.  See
+   section 6 for description of encryption methods.
+
+   A resolver sends a query for type TKEY accompanied by a TKEY RR
+   specifying the "server assignment" mode and a resolver KEY RR to be
+   used in encrypting the response, both in the additional information
+   section. The TKEY algorithm field is set to the authentication
+   algorithm the resolver plans to use.  It is RECOMMENDED that any "key
+   data" provided in the query TKEY RR by the resolver be strongly mixed
+   by the server with server generated randomness [RFC 1750] to derive
+   the keying material to be used.  The KEY RR that appears in the query
+   need not be accompanied by a SIG(KEY) RR.  If the query is
+   authenticated by the resolver with a TSIG RR [RFC 2845] or SIG(0) RR
+   and that authentication is verified, then any SIG(KEY) provided in
+   the query SHOULD be ignored.  The KEY RR in such a query SHOULD have
+   a name that corresponds to the resolver but it is only essential that
+   it be a public key for which the resolver has the corresponding
+   private key so it can decrypt the response data.
+
+   The server response contains a TKEY RR in its answer section with the
+   server assigned mode and echoes the KEY RR provided in the query in
+   its additional information section.
+
+   If the response TKEY error field is zero, the key data portion of the
+   response TKEY RR will be the server assigned keying data encrypted
+   under the public key in the resolver provided KEY RR.  In this case,
+   the owner name of the answer TKEY RR will be the server assigned name
+   of the key.
+
+
+
+
+Eastlake                    Standards Track                    [Page 10]
+
+RFC 2930                    The DNS TKEY RR               September 2000
+
+
+   If the error field of the response TKEY is non-zero, the query failed
+   for the reason given.  FORMERR is given if the query specified no
+   encryption key.
+
+   The inception and expiry times in the query TKEY RR are those
+   requested for the keying material.  The inception and expiry times in
+   the response TKEY are the maximum period the server will consider the
+   keying material valid.  Servers may pre-expire keys so this is not a
+   guarantee.
+
+   The resolver KEY RR MUST be authenticated, through the authentication
+   of this query with a TSIG or SIG(0) or the signing of the resolver
+   KEY with a SIG(KEY).  Otherwise, an attacker can forge a resolver KEY
+   for which they know the private key, and thereby the attacker could
+   obtain a valid shared secret key from the server.
+
+4.5 Query for Resolver Assigned Keying
+
+   Optionally, a server can accept resolver assigned keys.  The keying
+   material MUST be encrypted under a server key for protection in
+   transmission as described in Section 6.
+
+   The resolver sends a TKEY query with a TKEY RR that specifies the
+   encrypted keying material and a KEY RR specifying the server public
+   key used to encrypt the data, both in the additional information
+   section.  The name of the key and the keying data are completely
+   controlled by the sending resolver so a globally unique key name
+   SHOULD be used.  The KEY RR used MUST be one for which the server has
+   the corresponding private key, or it will not be able to decrypt the
+   keying material and will return a FORMERR. It is also important that
+   no untrusted party (preferably no other party than the server) has
+   the private key corresponding to the KEY RR because, if they do, they
+   can capture the messages to the server, learn the shared secret, and
+   spoof valid TSIGs.
+
+   The query TKEY RR inception and expiry give the time period the
+   querier intends to consider the keying material valid.  The server
+   can return a lesser time interval to advise that it will not maintain
+   state for that long and can pre-expire keys in any case.
+
+   This mode of query MUST be authenticated with a TSIG or SIG(0).
+   Otherwise, an attacker can forge a resolver assigned TKEY query, and
+   thereby the attacker could specify a shared secret key that would be
+   accepted, used, and honored by the server.
+
+
+
+
+
+
+
+Eastlake                    Standards Track                    [Page 11]
+
+RFC 2930                    The DNS TKEY RR               September 2000
+
+
+5. Spontaneous Server Inclusion
+
+   A DNS server may include a TKEY RR spontaneously as additional
+   information in responses.  This SHOULD only be done if the server
+   knows the querier understands TKEY and has this option implemented.
+   This technique can be used to delete a key and may be specified for
+   modes defined in the future.  A disadvantage of this technique is
+   that there is no way for the server to get any error or success
+   indication back and, in the case of UDP, no way to even know if the
+   DNS response reached the resolver.
+
+5.1 Spontaneous Server Key Deletion
+
+   A server can optionally tell a client that it has deleted a secret
+   key by spontaneously including a TKEY RR in the additional
+   information section of a response with the key's name and specifying
+   the key deletion mode.  Such a response SHOULD be authenticated.  If
+   authenticated, it "deletes" the key with the given name.  The
+   inception and expiry times of the delete TKEY RR are ignored. Failure
+   by a client to receive or properly process such additional
+   information in a response would mean that the client might use a key
+   that the server had discarded and would then get an error indication.
+
+   For server assigned and Diffie-Hellman keys, the client MUST
+   "discard" active state associated with the key.  For querier assigned
+   keys, the querier MAY simply mark the key as no longer retained by
+   the server and may re-send it in a future query specifying querier
+   assigned keying material.
+
+6. Methods of Encryption
+
+   For the server assigned and resolver assigned key agreement modes,
+   the keying material is sent within the key data field of a TKEY RR
+   encrypted under the public key in an accompanying KEY RR [RFC 2535].
+   This KEY RR MUST be for a public key algorithm where the public and
+   private keys can be used for encryption and the corresponding
+   decryption which recovers the originally encrypted data.  The KEY RR
+   SHOULD correspond to a name for the decrypting resolver/server such
+   that the decrypting process has access to the corresponding private
+   key to decrypt the data.  The secret keying material being sent will
+   generally be fairly short, usually less than 256 bits, because that
+   is adequate for very strong protection with modern keyed hash or
+   symmetric algorithms.
+
+   If the KEY RR specifies the RSA algorithm, then the keying material
+   is encrypted as per the description of RSAES-PKCS1-v1_5 encryption in
+   PKCS#1 [RFC 2437].  (Note, the secret keying material being sent is
+   directly RSA encrypted in PKCS#1 format. It is not "enveloped" under
+
+
+
+Eastlake                    Standards Track                    [Page 12]
+
+RFC 2930                    The DNS TKEY RR               September 2000
+
+
+   some other symmetric algorithm.)  In the unlikely event that the
+   keying material will not fit within one RSA modulus of the chosen
+   public key, additional RSA encryption blocks are included.  The
+   length of each block is clear from the public RSA key specified and
+   the RSAES-PKCS1-v1_5 padding makes it clear what part of the
+   encrypted data is actually keying material and what part is
+   formatting or the required at least eight bytes of random [RFC 1750]
+   padding.
+
+7. IANA Considerations
+
+   This section is to be interpreted as provided in [RFC 2434].
+
+   Mode field values 0x0000 and 0xFFFF are reserved.
+
+   Mode field values 0x0001 through 0x00FF, and 0XFF00 through 0XFFFE
+   can only be assigned by an IETF Standards Action.
+
+   Mode field values 0x0100 through 0x0FFF and 0xF0000 through 0xFEFF
+   are allocated by IESG approval or IETF consensus.
+
+   Mode field values 0x1000 through 0xEFFF are allocated based on
+   Specification Required as defined in [RFC 2434].
+
+   Mode values should not be changed when the status of their use
+   changes.  For example, a mode value assigned based just on providing
+   a specification should not be changed later just because that use's
+   status is changed to standards track.
+
+   The following assignments are documented herein:
+
+      RR Type 249 for TKEY.
+
+      TKEY Modes 1 through 5 as listed in section 2.5.
+
+      Extended RCODE Error values of 19, 20, and 21 as listed in section
+      2.6.
+
+8. Security Considerations
+
+   The entirety of this specification is concerned with the secure
+   establishment of a shared secret between DNS clients and servers in
+   support of TSIG [RFC 2845].
+
+   Protection against denial of service via the use of TKEY is not
+   provided.
+
+
+
+
+
+Eastlake                    Standards Track                    [Page 13]
+
+RFC 2930                    The DNS TKEY RR               September 2000
+
+
+References
+
+   [Schneier] Bruce Schneier, "Applied Cryptography: Protocols,
+              Algorithms, and Source Code in C", 1996, John Wiley and
+              Sons
+
+   [RFC 1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
+              STD 13, RFC 1034, November 1987.
+
+   [RFC 1035] Mockapetris, P., "Domain Names - Implementation and
+              Specifications", STD 13, RFC 1035, November 1987.
+
+   [RFC 1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness
+              Recommendations for Security", RFC 1750, December 1994.
+
+   [RFC 1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
+              September 1996.
+
+   [RFC 1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,
+              August 1996.
+
+   [RFC 2030] Mills, D., "Simple Network Time Protocol (SNTP) Version 4
+              for IPv4, IPv6 and OSI", RFC 2030, October 1996.
+
+   [RFC 2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC:  Keyed-
+              Hashing for Message Authentication", RFC 2104, February
+              1997.
+
+   [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC 2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic
+              Updates in the Domain Name System (DNS UPDATE)", RFC 2136,
+              April 1997.
+
+   [RFC 2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
+              IANA Considerations Section in RFCs", BCP 26, RFC 2434,
+              October 1998.
+
+   [RFC 2437] Kaliski, B. and J. Staddon, "PKCS #1: RSA Cryptography
+              Specifications Version 2.0", RFC 2437, October 1998.
+
+   [RFC 2535] Eastlake, D., "Domain Name System Security Extensions",
+              RFC 2535, March 1999.
+
+   [RFC 2539] Eastlake, D., "Storage of Diffie-Hellman Keys in the
+              Domain Name System (DNS)", RFC 2539, March 1999.
+
+
+
+
+Eastlake                    Standards Track                    [Page 14]
+
+RFC 2930                    The DNS TKEY RR               September 2000
+
+
+   [RFC 2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B.
+              Wellington, "Secret Key Transaction Authentication for DNS
+              (TSIG)", RFC 2845, May 2000.
+
+   [RFC 2931] Eastlake, D., "DNS Request and Transaction Signatures
+              (SIG(0)s )", RFC 2931, September 2000.
+
+Author's Address
+
+   Donald E. Eastlake 3rd
+   Motorola
+   140 Forest Avenue
+   Hudson, MA 01749 USA
+
+   Phone: +1 978-562-2827 (h)
+          +1 508-261-5434 (w)
+   Fax:   +1 508-261-4447 (w)
+   EMail: Donald.Eastlake@motorola.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake                    Standards Track                    [Page 15]
+
+RFC 2930                    The DNS TKEY RR               September 2000
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2000).  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 Standards process must be
+   followed, or as required to translate it into 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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake                    Standards Track                    [Page 16]
+
diff --git a/doc/rfc/rfc2931.txt b/doc/rfc/rfc2931.txt
new file mode 100644
index 0000000..84cc97e
--- /dev/null
+++ b/doc/rfc/rfc2931.txt
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+Network Working Group                                    D. Eastlake 3rd
+Request for Comments: 2931                                      Motorola
+Updates: 2535                                             September 2000
+Category: Standards Track
+
+
+           DNS Request and Transaction Signatures ( SIG(0)s )
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2000).  All Rights Reserved.
+
+Abstract
+
+   Extensions to the Domain Name System (DNS) are described in [RFC
+   2535] that can provide data origin and transaction integrity and
+   authentication to security aware resolvers and applications through
+   the use of cryptographic digital signatures.
+
+   Implementation experience has indicated the need for minor but non-
+   interoperable changes in Request and Transaction signature resource
+   records ( SIG(0)s ).  These changes are documented herein.
+
+Acknowledgments
+
+   The contributions and suggestions of the following persons (in
+   alphabetic order) to this memo are gratefully acknowledged:
+
+         Olafur Gudmundsson
+
+         Ed Lewis
+
+         Erik Nordmark
+
+         Brian Wellington
+
+
+
+
+
+
+
+
+Eastlake                    Standards Track                     [Page 1]
+
+RFC 2931                       DNS SIG(0)                 September 2000
+
+
+Table of Contents
+
+   1. Introduction.................................................  2
+   2. SIG(0) Design Rationale......................................  3
+   2.1 Transaction Authentication..................................  3
+   2.2 Request Authentication......................................  3
+   2.3 Keying......................................................  3
+   2.4 Differences Between TSIG and SIG(0).........................  4
+   3. The SIG(0) Resource Record...................................  4
+   3.1 Calculating Request and Transaction SIGs....................  5
+   3.2 Processing Responses and SIG(0) RRs.........................  6
+   3.3 SIG(0) Lifetime and Expiration..............................  7
+   4. Security Considerations......................................  7
+   5. IANA Considerations..........................................  7
+   References......................................................  7
+   Author's Address................................................  8
+   Appendix: SIG(0) Changes from RFC 2535..........................  9
+   Full Copyright Statement........................................ 10
+
+1. Introduction
+
+   This document makes minor but non-interoperable changes to part of
+   [RFC 2535], familiarity with which is assumed, and includes
+   additional explanatory text.  These changes concern SIG Resource
+   Records (RRs) that are used to digitally sign DNS requests and
+   transactions / responses.  Such a resource record, because it has a
+   type covered field of zero, is frequently called a SIG(0). The
+   changes are based on implementation and attempted implementation
+   experience with TSIG [RFC 2845] and the [RFC 2535] specification for
+   SIG(0).
+
+   Sections of [RFC 2535] updated are all of 4.1.8.1 and parts of 4.2
+   and 4.3.  No changes are made herein related to the KEY or NXT RRs or
+   to the processing involved with data origin and denial authentication
+   for DNS data.
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC 2119].
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake                    Standards Track                     [Page 2]
+
+RFC 2931                       DNS SIG(0)                 September 2000
+
+
+2. SIG(0) Design Rationale
+
+   SIG(0) provides protection for DNS transactions and requests that is
+   not provided by the regular SIG, KEY, and NXT RRs specified in [RFC
+   2535].  The authenticated data origin services of secure DNS either
+   provide protected data resource records (RRs) or authenticatably deny
+   their nonexistence.  These services provide no protection for glue
+   records, DNS requests, no protection for message headers on requests
+   or responses, and no protection of the overall integrity of a
+   response.
+
+2.1 Transaction Authentication
+
+   Transaction authentication means that a requester can be sure it is
+   at least getting the messages from the server it queried and that the
+   received messages are in response to the query it sent.  This is
+   accomplished by optionally adding either a TSIG RR [RFC 2845] or, as
+   described herein, a SIG(0) resource record at the end of the response
+   which digitally signs the concatenation of the server's response and
+   the corresponding resolver query.
+
+2.2 Request Authentication
+
+   Requests can also be authenticated by including a TSIG or, as
+   described herein, a special SIG(0) RR at the end of the request.
+   Authenticating requests serves no function in DNS servers that
+   predate the specification of dynamic update.  Requests with a non-
+   empty additional information section produce error returns or may
+   even be ignored by a few such older DNS servers. However, this syntax
+   for signing requests is defined for authenticating dynamic update
+   requests [RFC 2136], TKEY requests [RFC 2930], or future requests
+   requiring authentication.
+
+2.3 Keying
+
+   The private keys used in transaction security belong to the host
+   composing the DNS response message, not to the zone involved.
+   Request authentication may also involve the private key of the host
+   or other entity composing the request or of a zone to be affected by
+   the request or other private keys depending on the request authority
+   it is sought to establish. The corresponding public key(s) are
+   normally stored in and retrieved from the DNS for verification as KEY
+   RRs with a protocol byte of 3 (DNSSEC) or 255 (ANY).
+
+   Because requests and replies are highly variable, message
+   authentication SIGs can not be pre-calculated.  Thus it will be
+   necessary to keep the private key on-line, for example in software or
+   in a directly connected piece of hardware.
+
+
+
+Eastlake                    Standards Track                     [Page 3]
+
+RFC 2931                       DNS SIG(0)                 September 2000
+
+
+2.4 Differences Between TSIG and SIG(0)
+
+   There are significant differences between TSIG and SIG(0).
+
+   Because TSIG involves secret keys installed at both the requester and
+   server the presence of such a key implies that the other party
+   understands TSIG and very likely has the same key installed.
+   Furthermore, TSIG uses keyed hash authentication codes which are
+   relatively inexpensive to compute.  Thus it is common to authenticate
+   requests with TSIG and responses are authenticated with TSIG if the
+   corresponding request is authenticated.
+
+   SIG(0) on the other hand, uses public key authentication, where the
+   public keys are stored in DNS as KEY RRs and a private key is stored
+   at the signer.  Existence of such a KEY RR does not necessarily imply
+   implementation of SIG(0).  In addition, SIG(0) involves relatively
+   expensive public key cryptographic operations that should be
+   minimized and the verification of a SIG(0) involves obtaining and
+   verifying the corresponding KEY which can be an expensive and lengthy
+   operation.  Indeed, a policy of using SIG(0) on all requests and
+   verifying it before responding would, for some configurations, lead
+   to a deadly embrace with the attempt to obtain and verify the KEY
+   needed to authenticate the request SIG(0) resulting in additional
+   requests accompanied by a SIG(0) leading to further requests
+   accompanied by a SIG(0), etc.  Furthermore, omitting SIG(0)s when not
+   required on requests halves the number of public key operations
+   required by the transaction.
+
+   For these reasons, SIG(0)s SHOULD only be used on requests when
+   necessary to authenticate that the requester has some required
+   privilege or identity.  SIG(0)s on replies are defined in such a way
+   as to not require a SIG(0) on the corresponding request and still
+   provide transaction protection.  For other replies, whether they are
+   authenticated by the server or required to be authenticated by the
+   requester SHOULD be a local configuration option.
+
+3. The SIG(0) Resource Record
+
+   The structure of and type number of SIG resource records (RRs) is
+   given in [RFC 2535] Section 4.1.  However all of Section 4.1.8.1 and
+   the parts of Sections 4.2 and 4.3 related to SIG(0) should be
+   considered replaced by the material below.  Any conflict between [RFC
+   2535] and this document concerning SIG(0) RRs should be resolved in
+   favor of this document.
+
+   For all transaction SIG(0)s, the signer field MUST be a name of the
+   originating host and there MUST be a KEY RR at that name with the
+   public key corresponding to the private key used to calculate the
+
+
+
+Eastlake                    Standards Track                     [Page 4]
+
+RFC 2931                       DNS SIG(0)                 September 2000
+
+
+   signature.  (The host domain name used may be the inverse IP address
+   mapping name for an IP address of the host if the relevant KEY is
+   stored there.)
+
+   For all SIG(0) RRs, the owner name, class, TTL, and original TTL, are
+   meaningless.  The TTL fields SHOULD be zero and the CLASS field
+   SHOULD be ANY.  To conserve space, the owner name SHOULD be root (a
+   single zero octet).  When SIG(0) authentication on a response is
+   desired, that SIG RR MUST be considered the highest priority of any
+   additional information for inclusion in the response. If the SIG(0)
+   RR cannot be added without causing the message to be truncated, the
+   server MUST alter the response so that a SIG(0) can be included.
+   This response consists of only the question and a SIG(0) record, and
+   has the TC bit set and RCODE 0 (NOERROR).  The client should at this
+   point retry the request using TCP.
+
+3.1 Calculating Request and Transaction SIGs
+
+   A DNS request may be optionally signed by including one SIG(0)s at
+   the end of the query additional information section.  Such a SIG is
+   identified by having a "type covered" field of zero. It signs the
+   preceding DNS request message including DNS header but not including
+   the UDP/IP header and before the request RR counts have been adjusted
+   for the inclusions of the request SIG(0).
+
+   It is calculated by using a "data" (see [RFC 2535], Section 4.1.8) of
+   (1) the SIG's RDATA section entirely omitting (not just zeroing) the
+   signature subfield itself, (2) the DNS query messages, including DNS
+   header, but not the UDP/IP header and before the reply RR counts have
+   been adjusted for the inclusion of the SIG(0).  That is
+
+      data = RDATA | request - SIG(0)
+
+   where "|" is concatenation and RDATA is the RDATA of the SIG(0) being
+   calculated less the signature itself.
+
+   Similarly, a SIG(0) can be used to secure a response and the request
+   that produced it.  Such transaction signatures are calculated by
+   using a "data" of (1) the SIG's RDATA section omitting the signature
+   itself, (2) the entire DNS query message that produced this response,
+   including the query's DNS header but not its UDP/IP header, and (3)
+   the entire DNS response message, including DNS header but not the
+   UDP/IP header and before the response RR counts have been adjusted
+   for the inclusion of the SIG(0).
+
+
+
+
+
+
+
+Eastlake                    Standards Track                     [Page 5]
+
+RFC 2931                       DNS SIG(0)                 September 2000
+
+
+   That is
+
+      data = RDATA | full query | response - SIG(0)
+
+   where "|" is concatenation and RDATA is the RDATA of the SIG(0) being
+   calculated less the signature itself.
+
+   Verification of a response SIG(0) (which is signed by the server host
+   key, not the zone key) by the requesting resolver shows that the
+   query and response were not tampered with in transit, that the
+   response corresponds to the intended query, and that the response
+   comes from the queried server.
+
+   In the case of a DNS message via TCP, a SIG(0) on the first data
+   packet is calculated with "data" as above and for each subsequent
+   packet, it is calculated as follows:
+
+      data = RDATA | DNS payload - SIG(0) | previous packet
+
+   where "|" is concatenations, RDATA is as above, and previous packet
+   is the previous DNS payload including DNS header and the SIG(0) but
+   not the TCP/IP header.  Support of SIG(0) for TCP is OPTIONAL.  As an
+   alternative, TSIG may be used after, if necessary, setting up a key
+   with TKEY [RFC 2930].
+
+   Except where needed to authenticate an update, TKEY, or similar
+   privileged request, servers are not required to check a request
+   SIG(0).
+
+   Note: requests and responses can either have a single TSIG or one
+   SIG(0) but not both a TSIG and a SIG(0).
+
+3.2 Processing Responses and SIG(0) RRs
+
+   If a SIG RR is at the end of the additional information section of a
+   response and has a type covered of zero, it is a transaction
+   signature covering the response and the query that produced the
+   response.  For TKEY responses, it MUST be checked and the message
+   rejected if the checks fail unless otherwise specified for the TKEY
+   mode in use.  For all other responses, it MAY be checked and the
+   message rejected if the checks fail.
+
+   If a response's SIG(0) check succeed, such a transaction
+   authentication SIG does NOT directly authenticate the validity any
+   data-RRs in the message.  However, it authenticates that they were
+   sent by the queried server and have not been diddled.  (Only a proper
+   SIG(0) RR signed by the zone or a key tracing its authority to the
+   zone or to static resolver configuration can directly authenticate
+
+
+
+Eastlake                    Standards Track                     [Page 6]
+
+RFC 2931                       DNS SIG(0)                 September 2000
+
+
+   data-RRs, depending on resolver policy.) If a resolver or server does
+   not implement transaction and/or request SIGs, it MUST ignore them
+   without error where they are optional and treat them as failing where
+   they are required.
+
+3.3 SIG(0) Lifetime and Expiration
+
+   The inception and expiration times in SIG(0)s are for the purpose of
+   resisting replay attacks.  They should be set to form a time bracket
+   such that messages outside that bracket can be ignored.  In IP
+   networks, this time bracket should not normally extend further than 5
+   minutes into the past and 5 minutes into the future.
+
+4. Security Considerations
+
+   No additional considerations beyond those in [RFC 2535].
+
+   The inclusion of the SIG(0) inception and expiration time under the
+   signature improves resistance to replay attacks.
+
+5. IANA Considerations
+
+   No new parameters are created or parameter values assigned by this
+   document.
+
+References
+
+   [RFC 1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
+              September 1996.
+
+   [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC 2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic
+              Updates in the Domain Name System (DNS UPDATE)", RFC 2136,
+              April 1997.
+
+   [RFC 2535] Eastlake, D., "Domain Name System Security Extensions",
+              RFC 2535, March 1999.
+
+   [RFC 2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B.
+              Wellington, "Secret Key Transaction Signatures for DNS
+              (TSIG)", RFC 2845, May 2000.
+
+   [RFC 2930] Eastlake, D., "Secret Key Establishment for DNS (RR)", RFC
+              2930, September 2000.
+
+
+
+
+
+Eastlake                    Standards Track                     [Page 7]
+
+RFC 2931                       DNS SIG(0)                 September 2000
+
+
+Author's Address
+
+   Donald E. Eastlake 3rd
+   Motorola
+   140 Forest Avenue
+   Hudson, MA 01749 USA
+
+   Phone: +1-978-562-2827(h)
+          +1-508-261-5434(w)
+   Fax:   +1 978-567-7941(h)
+          +1-508-261-4447(w)
+   EMail: Donald.Eastlake@motorola.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake                    Standards Track                     [Page 8]
+
+RFC 2931                       DNS SIG(0)                 September 2000
+
+
+Appendix: SIG(0) Changes from RFC 2535
+
+   Add explanatory text concerning the differences between TSIG and
+   SIG(0).
+
+   Change the data over which SIG(0) is calculated to include the SIG(0)
+   RDATA other than the signature itself so as to secure the signature
+   inception and expiration times and resist replay attacks.  Specify
+   SIG(0) for TCP.
+
+   Add discussion of appropriate inception and expiration times for
+   SIG(0).
+
+   Add wording to indicate that either a TSIG or one or more SIG(0)s may
+   be present but not both.
+
+   Reword some areas for clarity.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake                    Standards Track                     [Page 9]
+
+RFC 2931                       DNS SIG(0)                 September 2000
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2000).  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 Standards process must be
+   followed, or as required to translate it into 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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake                    Standards Track                    [Page 10]
+
diff --git a/doc/rfc/rfc3007.txt b/doc/rfc/rfc3007.txt
new file mode 100644
index 0000000..1697475
--- /dev/null
+++ b/doc/rfc/rfc3007.txt
@@ -0,0 +1,507 @@
+
+
+
+
+
+
+Network Working Group                                      B. Wellington
+Request for Comments: 3007                                       Nominum
+Updates: 2535, 2136                                        November 2000
+Obsoletes: 2137
+Category: Standards Track
+
+
+             Secure Domain Name System (DNS) Dynamic Update
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2000).  All Rights Reserved.
+
+Abstract
+
+   This document proposes a method for performing secure Domain Name
+   System (DNS) dynamic updates.  The method described here is intended
+   to be flexible and useful while requiring as few changes to the
+   protocol as possible.  The authentication of the dynamic update
+   message is separate from later DNSSEC validation of the data.  Secure
+   communication based on authenticated requests and transactions is
+   used to provide authorization.
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [RFC2119].
+
+1 - Introduction
+
+   This document defines a means to secure dynamic updates of the Domain
+   Name System (DNS), allowing only authorized sources to make changes
+   to a zone's contents.  The existing unsecured dynamic update
+   operations form the basis for this work.
+
+   Familiarity with the DNS system [RFC1034, RFC1035] and dynamic update
+   [RFC2136] is helpful and is assumed by this document.  In addition,
+   knowledge of DNS security extensions [RFC2535], SIG(0) transaction
+   security [RFC2535, RFC2931], and TSIG transaction security [RFC2845]
+   is recommended.
+
+
+
+
+Wellington                  Standards Track                     [Page 1]
+
+RFC 3007                 Secure Dynamic Update             November 2000
+
+
+   This document updates portions of RFC 2535, in particular section
+   3.1.2, and RFC 2136.  This document obsoletes RFC 2137, an alternate
+   proposal for secure dynamic update, due to implementation experience.
+
+1.1 - Overview of DNS Dynamic Update
+
+   DNS dynamic update defines a new DNS opcode and a new interpretation
+   of the DNS message if that opcode is used.  An update can specify
+   insertions or deletions of data, along with prerequisites necessary
+   for the updates to occur.  All tests and changes for a DNS update
+   request are restricted to a single zone, and are performed at the
+   primary server for the zone.  The primary server for a dynamic zone
+   must increment the zone SOA serial number when an update occurs or
+   before the next retrieval of the SOA.
+
+1.2 - Overview of DNS Transaction Security
+
+   Exchanges of DNS messages which include TSIG [RFC2845] or SIG(0)
+   [RFC2535, RFC2931] records allow two DNS entities to authenticate DNS
+   requests and responses sent between them.  A TSIG MAC (message
+   authentication code) is derived from a shared secret, and a SIG(0) is
+   generated from a private key whose public counterpart is stored in
+   DNS.  In both cases, a record containing the message signature/MAC is
+   included as the final resource record in a DNS message.  Keyed
+   hashes, used in TSIG, are inexpensive to calculate and verify.
+   Public key encryption, as used in SIG(0), is more scalable as the
+   public keys are stored in DNS.
+
+1.3 - Comparison of data authentication and message authentication
+
+   Message based authentication, using TSIG or SIG(0), provides
+   protection for the entire message with a single signing and single
+   verification which, in the case of TSIG, is a relatively inexpensive
+   MAC creation and check.  For update requests, this signature can
+   establish, based on policy or key negotiation, the authority to make
+   the request.
+
+   DNSSEC SIG records can be used to protect the integrity of individual
+   RRs or RRsets in a DNS message with the authority of the zone owner.
+   However, this cannot sufficiently protect the dynamic update request.
+
+   Using SIG records to secure RRsets in an update request is
+   incompatible with the design of update, as described below, and would
+   in any case require multiple expensive public key signatures and
+   verifications.
+
+
+
+
+
+
+Wellington                  Standards Track                     [Page 2]
+
+RFC 3007                 Secure Dynamic Update             November 2000
+
+
+   SIG records do not cover the message header, which includes record
+   counts.  Therefore, it is possible to maliciously insert or remove
+   RRsets in an update request without causing a verification failure.
+
+   If SIG records were used to protect the prerequisite section, it
+   would be impossible to determine whether the SIGs themselves were a
+   prerequisite or simply used for validation.
+
+   In the update section of an update request, signing requests to add
+   an RRset is straightforward, and this signature could be permanently
+   used to protect the data, as specified in [RFC2535].  However, if an
+   RRset is deleted, there is no data for a SIG to cover.
+
+1.4 - Data and message signatures
+
+   As specified in [RFC3008], the DNSSEC validation process performed by
+   a resolver MUST NOT process any non-zone keys unless local policy
+   dictates otherwise.  When performing secure dynamic update, all zone
+   data modified in a signed zone MUST be signed by a relevant zone key.
+   This completely disassociates authentication of an update request
+   from authentication of the data itself.
+
+   The primary usefulness of host and user keys, with respect to DNSSEC,
+   is to authenticate messages, including dynamic updates.  Thus, host
+   and user keys MAY be used to generate SIG(0) records to authenticate
+   updates and MAY be used in the TKEY [RFC2930] process to generate
+   TSIG shared secrets.  In both cases, no SIG records generated by
+   non-zone keys will be used in a DNSSEC validation process unless
+   local policy dictates.
+
+   Authentication of data, once it is present in DNS, only involves
+   DNSSEC zone keys and signatures generated by them.
+
+1.5 - Signatory strength
+
+   [RFC2535, section 3.1.2] defines the signatory field of a key as the
+   final 4 bits of the flags field, but does not define its value.  This
+   proposal leaves this field undefined.  Updating [RFC2535], this field
+   SHOULD be set to 0 in KEY records, and MUST be ignored.
+
+2 - Authentication
+
+   TSIG or SIG(0) records MUST be included in all secure dynamic update
+   messages.  This allows the server to verifiably determine the
+   originator of a message.  If the message contains authentication in
+   the form of a SIG(0), the identity of the sender (that is, the
+   principal) is the owner of the KEY RR that generated the SIG(0).  If
+   the message contains a TSIG generated by a statically configured
+
+
+
+Wellington                  Standards Track                     [Page 3]
+
+RFC 3007                 Secure Dynamic Update             November 2000
+
+
+   shared secret, the principal is the same as or derived from the
+   shared secret name.  If the message contains a TSIG generated by a
+   dynamically configured shared secret, the principal is the same as
+   the one that authenticated the TKEY process; if the TKEY process was
+   unauthenticated, no information is known about the principal, and the
+   associated TSIG shared secret MUST NOT be used for secure dynamic
+   update.
+
+   SIG(0) signatures SHOULD NOT be generated by zone keys, since
+   transactions are initiated by a host or user, not a zone.
+
+   DNSSEC SIG records (other than SIG(0)) MAY be included in an update
+   message, but MUST NOT be used to authenticate the update request.
+
+   If an update fails because it is signed with an unauthorized key, the
+   server MUST indicate failure by returning a message with RCODE
+   REFUSED.  Other TSIG, SIG(0), or dynamic update errors are returned
+   as specified in the appropriate protocol description.
+
+3 - Policy
+
+   All policy is configured by the zone administrator and enforced by
+   the zone's primary name server.  Policy dictates the authorized
+   actions that an authenticated principal can take.  Policy checks are
+   based on the principal and the desired action, where the principal is
+   derived from the message signing key and applied to dynamic update
+   messages signed with that key.
+
+   The server's policy defines criteria which determine if the key used
+   to sign the update is permitted to perform the requested updates.  By
+   default, a principal MUST NOT be permitted to make any changes to
+   zone data; any permissions MUST be enabled though configuration.
+
+   The policy is fully implemented in the primary zone server's
+   configuration for several reasons.  This removes limitations imposed
+   by encoding policy into a fixed number of bits (such as the KEY RR's
+   signatory field).  Policy is only relevant in the server applying it,
+   so there is no reason to expose it.  Finally, a change in policy or a
+   new type of policy should not affect the DNS protocol or data format,
+   and should not cause interoperability failures.
+
+3.1 - Standard policies
+
+   Implementations SHOULD allow access control policies to use the
+   principal as an authorization token, and MAY also allow policies to
+   grant permission to a signed message regardless of principal.
+
+
+
+
+
+Wellington                  Standards Track                     [Page 4]
+
+RFC 3007                 Secure Dynamic Update             November 2000
+
+
+   A common practice would be to restrict the permissions of a principal
+   by domain name.  That is, a principal could be permitted to add,
+   delete, or modify entries corresponding to one or more domain names.
+   Implementations SHOULD allow per-name access control, and SHOULD
+   provide a concise representation of the principal's own name, its
+   subdomains, and all names in the zone.
+
+   Additionally, a server SHOULD allow restricting updates by RR type,
+   so that a principal could add, delete, or modify specific record
+   types at certain names.  Implementations SHOULD allow per-type access
+   control, and SHOULD provide concise representations of all types and
+   all "user" types, where a user type is defined as one that does not
+   affect the operation of DNS itself.
+
+3.1.1 - User types
+
+   User types include all data types except SOA, NS, SIG, and NXT.  SOA
+   and NS records SHOULD NOT be modified by normal users, since these
+   types create or modify delegation points.  The addition of SIG
+   records can lead to attacks resulting in additional workload for
+   resolvers, and the deletion of SIG records could lead to extra work
+   for the server if the zone SIG was deleted.  Note that these records
+   are not forbidden, but not recommended for normal users.
+
+   NXT records MUST NOT be created, modified, or deleted by dynamic
+   update, as their update may cause instability in the protocol.  This
+   is an update to RFC 2136.
+
+   Issues concerning updates of KEY records are discussed in the
+   Security Considerations section.
+
+3.2 - Additional policies
+
+   Users are free to implement any policies.  Policies may be as
+   specific or general as desired, and as complex as desired.  They may
+   depend on the principal or any other characteristics of the signed
+   message.
+
+4 - Interaction with DNSSEC
+
+   Although this protocol does not change the way updates to secure
+   zones are processed, there are a number of issues that should be
+   clarified.
+
+
+
+
+
+
+
+
+Wellington                  Standards Track                     [Page 5]
+
+RFC 3007                 Secure Dynamic Update             November 2000
+
+
+4.1 - Adding SIGs
+
+   An authorized update request MAY include SIG records with each RRset.
+   Since SIG records (except SIG(0) records) MUST NOT be used for
+   authentication of the update message, they are not required.
+
+   If a principal is authorized to update SIG records and there are SIG
+   records in the update, the SIG records are added without
+   verification.  The server MAY examine SIG records and drop SIGs with
+   a temporal validity period in the past.
+
+4.2 - Deleting SIGs
+
+   If a principal is authorized to update SIG records and the update
+   specifies the deletion of SIG records, the server MAY choose to
+   override the authority and refuse the update.  For example, the
+   server may allow all SIG records not generated by a zone key to be
+   deleted.
+
+4.3 - Non-explicit updates to SIGs
+
+   If the updated zone is secured, the RRset affected by an update
+   operation MUST, at the completion of the update, be signed in
+   accordance with the zone's signing policy.  This will usually require
+   one or more SIG records to be generated by one or more zone keys
+   whose private components MUST be online [RFC3008].
+
+   When the contents of an RRset are updated, the server MAY delete all
+   associated SIG records, since they will no longer be valid.
+
+4.4 - Effects on the zone
+
+   If any changes are made, the server MUST, if necessary, generate a
+   new SOA record and new NXT records, and sign these with the
+   appropriate zone keys.  Changes to NXT records by secure dynamic
+   update are explicitly forbidden.  SOA updates are allowed, since the
+   maintenance of SOA parameters is outside of the scope of the DNS
+   protocol.
+
+5 - Security Considerations
+
+   This document requires that a zone key and possibly other
+   cryptographic secret material be held in an on-line, network-
+   connected host, most likely a name server.  This material is at the
+   mercy of host security to remain a secret.  Exposing this secret puts
+   DNS data at risk of masquerade attacks.  The data at risk is that in
+   both zones served by the machine and delegated from this machine.
+
+
+
+
+Wellington                  Standards Track                     [Page 6]
+
+RFC 3007                 Secure Dynamic Update             November 2000
+
+
+   Allowing updates of KEY records may lead to undesirable results,
+   since a principal may be allowed to insert a public key without
+   holding the private key, and possibly masquerade as the key owner.
+
+6 - Acknowledgements
+
+   The author would like to thank the following people for review and
+   informative comments (in alphabetical order):
+
+   Harald Alvestrand
+   Donald Eastlake
+   Olafur Gudmundsson
+   Andreas Gustafsson
+   Bob Halley
+   Stuart Kwan
+   Ed Lewis
+
+7 - References
+
+   [RFC1034]  Mockapetris, P., "Domain Names - Concepts and Facilities",
+              STD 13, RFC 1034, November 1987.
+
+   [RFC1035]  Mockapetris, P., "Domain Names - Implementation and
+              Specification", STD 13, RFC 1035, November 1987.
+
+   [RFC2136]  Vixie (Ed.), P., Thomson, S., Rekhter, Y. and J. Bound,
+              "Dynamic Updates in the Domain Name System", RFC 2136,
+              April 1997.
+
+   [RFC2137]  Eastlake, D., "Secure Domain Name System Dynamic Update",
+              RFC 2137, April 1997.
+
+   [RFC2535]  Eastlake, G., "Domain Name System Security Extensions",
+              RFC 2535, March 1999.
+
+   [RFC2845]  Vixie, P., Gudmundsson, O., Eastlake, D. and B.
+              Wellington, "Secret Key Transaction Signatures for DNS
+              (TSIG)", RFC 2845, May 2000.
+
+   [RFC2930]  Eastlake, D., "Secret Key Establishment for DNS (TKEY
+              RR)", RFC 2930, September 2000.
+
+   [RFC2931]  Eastlake, D., "DNS Request and Transaction Signatures
+              (SIG(0)s)", RFC 2931, September 2000.
+
+   [RFC3008]  Wellington, B., "Domain Name System Security (DNSSEC)
+              Signing Authority", RFC 3008, November 2000.
+
+
+
+
+Wellington                  Standards Track                     [Page 7]
+
+RFC 3007                 Secure Dynamic Update             November 2000
+
+
+8 - Author's Address
+
+   Brian Wellington
+   Nominum, Inc.
+   950 Charter Street
+   Redwood City, CA 94063
+
+   Phone: +1 650 381 6022
+   EMail: Brian.Wellington@nominum.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wellington                  Standards Track                     [Page 8]
+
+RFC 3007                 Secure Dynamic Update             November 2000
+
+
+9.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2000).  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 Standards process must be
+   followed, or as required to translate it into 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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wellington                  Standards Track                     [Page 9]
+
diff --git a/doc/rfc/rfc3008.txt b/doc/rfc/rfc3008.txt
new file mode 100644
index 0000000..08a4a8f
--- /dev/null
+++ b/doc/rfc/rfc3008.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+Network Working Group                                      B. Wellington
+Request for Comments: 3008                                       Nominum
+Updates: 2535                                              November 2000
+Category: Standards Track
+
+
+         Domain Name System Security (DNSSEC) Signing Authority
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2000).  All Rights Reserved.
+
+Abstract
+
+   This document proposes a revised model of Domain Name System Security
+   (DNSSEC) Signing Authority.  The revised model is designed to clarify
+   earlier documents and add additional restrictions to simplify the
+   secure resolution process.  Specifically, this affects the
+   authorization of keys to sign sets of records.
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [RFC2119].
+
+1 - Introduction
+
+   This document defines additional restrictions on DNSSEC signatures
+   (SIG) records relating to their authority to sign associated data.
+   The intent is to establish a standard policy followed by a secure
+   resolver; this policy can be augmented by local rules.  This builds
+   upon [RFC2535], updating section 2.3.6 of that document.
+
+   The most significant change is that in a secure zone, zone data is
+   required to be signed by the zone key.
+
+   Familiarity with the DNS system [RFC1034, RFC1035] and the DNS
+   security extensions [RFC2535] is assumed.
+
+
+
+
+
+
+Wellington                  Standards Track                     [Page 1]
+
+RFC 3008                DNSSEC Signing Authority           November 2000
+
+
+2 - The SIG Record
+
+   A SIG record is normally associated with an RRset, and "covers" (that
+   is, demonstrates the authenticity and integrity of) the RRset.  This
+   is referred to as a "data SIG".  Note that there can be multiple SIG
+   records covering an RRset, and the same validation process should be
+   repeated for each of them.  Some data SIGs are considered "material",
+   that is, relevant to a DNSSEC capable resolver, and some are
+   "immaterial" or "extra-DNSSEC", as they are not relevant to DNSSEC
+   validation.  Immaterial SIGs may have application defined roles.  SIG
+   records may exist which are not bound to any RRset; these are also
+   considered immaterial.  The validation process determines which SIGs
+   are material; once a SIG is shown to be immaterial, no other
+   validation is necessary.
+
+   SIGs may also be used for transaction security.  In this case, a SIG
+   record with a type covered field of 0 is attached to a message, and
+   is used to protect message integrity.  This is referred to as a
+   SIG(0) [RFC2535, RFC2931].
+
+   The following sections define requirements for all of the fields of a
+   SIG record.  These requirements MUST be met in order for a DNSSEC
+   capable resolver to process this signature.  If any of these
+   requirements are not met, the SIG cannot be further processed.
+   Additionally, once a KEY has been identified as having generated this
+   SIG, there are requirements that it MUST meet.
+
+2.1 - Type Covered
+
+   For a data SIG, the type covered MUST be the same as the type of data
+   in the associated RRset.  For a SIG(0), the type covered MUST be 0.
+
+2.2 - Algorithm Number
+
+   The algorithm specified in a SIG MUST be recognized by the client,
+   and it MUST be an algorithm that has a defined SIG rdata format.
+
+2.3 - Labels
+
+   The labels count MUST be less than or equal to the number of labels
+   in the SIG owner name, as specified in [RFC2535, section 4.1.3].
+
+2.4 - Original TTL
+
+   The original TTL MUST be greater than or equal to the TTL of the SIG
+   record itself, since the TTL cannot be increased by intermediate
+   servers.  This field can be ignored for SIG(0) records.
+
+
+
+
+Wellington                  Standards Track                     [Page 2]
+
+RFC 3008                DNSSEC Signing Authority           November 2000
+
+
+2.5 - Signature Expiration and Inception
+
+   The current time at the time of validation MUST lie within the
+   validity period bounded by the inception and expiration times.
+
+2.6 - Key Tag
+
+   There are no restrictions on the Key Tag field, although it is
+   possible that future algorithms will impose constraints.
+
+2.7 - Signer's Name
+
+   The signer's name field of a data SIG MUST contain the name of the
+   zone to which the data and signature belong.  The combination of
+   signer's name, key tag, and algorithm MUST identify a zone key if the
+   SIG is to be considered material.  The only exception that the
+   signer's name field in a SIG KEY at a zone apex SHOULD contain the
+   parent zone's name, unless the KEY set is self-signed.  This document
+   defines a standard policy for DNSSEC validation; local policy may
+   override the standard policy.
+
+   There are no restrictions on the signer field of a SIG(0) record.
+   The combination of signer's name, key tag, and algorithm MUST
+   identify a key if this SIG(0) is to be processed.
+
+2.8 - Signature
+
+   There are no restrictions on the signature field.  The signature will
+   be verified at some point, but does not need to be examined prior to
+   verification unless a future algorithm imposes constraints.
+
+3 - The Signing KEY Record
+
+   Once a signature has been examined and its fields validated (but
+   before the signature has been verified), the resolver attempts to
+   locate a KEY that matches the signer name, key tag, and algorithm
+   fields in the SIG.  If one is not found, the SIG cannot be verified
+   and is considered immaterial.  If KEYs are found, several fields of
+   the KEY record MUST have specific values if the SIG is to be
+   considered material and authorized.  If there are multiple KEYs, the
+   following checks are performed on all of them, as there is no way to
+   determine which one generated the signature until the verification is
+   performed.
+
+
+
+
+
+
+
+
+Wellington                  Standards Track                     [Page 3]
+
+RFC 3008                DNSSEC Signing Authority           November 2000
+
+
+3.1 - Type Flags
+
+   The signing KEY record MUST have a flags value of 00 or 01
+   (authentication allowed, confidentiality optional) [RFC2535, 3.1.2].
+   A DNSSEC resolver MUST only trust signatures generated by keys that
+   are permitted to authenticate data.
+
+3.2 - Name Flags
+
+   The interpretation of this field is considerably different for data
+   SIGs and SIG(0) records.
+
+3.2.1 - Data SIG
+
+   If the SIG record covers an RRset, the name type of the associated
+   KEY MUST be 01 (zone) [RFC2535, 3.1.2].  This updates RFC 2535,
+   section 2.3.6.  The DNSSEC validation process performed by a resolver
+   MUST ignore all keys that are not zone keys unless local policy
+   dictates otherwise.
+
+   The primary reason that RFC 2535 allows host and user keys to
+   generate material DNSSEC signatures is to allow dynamic update
+   without online zone keys; that is, avoid storing private keys in an
+   online server.  The desire to avoid online signing keys cannot be
+   achieved, though, because they are necessary to sign NXT and SOA sets
+   [RFC3007].  These online zone keys can sign any incoming data.
+   Removing the goal of having no online keys removes the reason to
+   allow host and user keys to generate material signatures.
+
+   Limiting material signatures to zone keys simplifies the validation
+   process.  The length of the verification chain is bounded by the
+   name's label depth.  The authority of a key is clearly defined; a
+   resolver does not need to make a potentially complicated decision to
+   determine whether a key has the proper authority to sign data.
+
+   Finally, there is no additional flexibility granted by allowing
+   host/user key generated material signatures.  As long as users and
+   hosts have the ability to authenticate update requests to the primary
+   zone server, signatures by zone keys are sufficient to protect the
+   integrity of the data to the world at large.
+
+3.2.2 - SIG(0)
+
+   If the SIG record is a SIG(0) protecting a message, the name type of
+   the associated KEY SHOULD be 00 (user) or 10 (host/entity).
+   Transactions are initiated by a host or user, not a zone, so zone
+   keys SHOULD not generate SIG(0) records.
+
+
+
+
+Wellington                  Standards Track                     [Page 4]
+
+RFC 3008                DNSSEC Signing Authority           November 2000
+
+
+   A client is either explicitly executed by a user or on behalf of a
+   host, therefore the name type of a SIG(0) generated by a client
+   SHOULD be either user or host.  A nameserver is associated with a
+   host, and its use of SIG(0) is not associated with a particular zone,
+   so the name type of a SIG(0) generated by a nameserver SHOULD be
+   host.
+
+3.3 - Signatory Flags
+
+   This document does not assign any values to the signatory field, nor
+   require any values to be present.
+
+3.4 - Protocol
+
+   The signing KEY record MUST have a protocol value of 3 (DNSSEC) or
+   255 (ALL).  If a key is not specified for use with DNSSEC, a DNSSEC
+   resolver MUST NOT trust any signature that it generates.
+
+3.5 - Algorithm Number
+
+   The algorithm field MUST be identical to that of the generated SIG
+   record, and MUST meet all requirements for an algorithm value in a
+   SIG record.
+
+4 - Security Considerations
+
+   This document defines a standard baseline for a DNSSEC capable
+   resolver.  This is necessary for a thorough security analysis of
+   DNSSEC, if one is to be done.
+
+   Specifically, this document places additional restrictions on SIG
+   records that a resolver must validate before the signature can be
+   considered worthy of DNSSEC trust.  This simplifies the protocol,
+   making it more robust and able to withstand scrutiny by the security
+   community.
+
+5 - Acknowledgements
+
+   The author would like to thank the following people for review and
+   informative comments (in alphabetical order):
+
+   Olafur Gudmundsson
+   Ed Lewis
+
+
+
+
+
+
+
+
+Wellington                  Standards Track                     [Page 5]
+
+RFC 3008                DNSSEC Signing Authority           November 2000
+
+
+6 - References
+
+   [RFC1034]  Mockapetris, P., "Domain Names - Concepts and Facilities",
+              STD 13, RFC 1034, November 1987.
+
+   [RFC1035]  Mockapetris, P., "Domain Names - Implementation and
+              Specification", STD 13, RFC 1035, November 1987.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2136]  Vixie (Ed.), P., Thomson, S., Rekhter, Y. and J. Bound,
+              "Dynamic Updates in the Domain Name System", RFC 2136,
+              April 1997.
+
+   [RFC2535]  Eastlake, D., "Domain Name System Security Extensions",
+              RFC 2535, March 1999.
+
+   [RFC2931]  Eastlake, D., "DNS Request and Transaction Signatures
+              (SIG(0)s )", RFC 2931, September 2000.
+
+   [RFC3007]      Wellington, B., "Simple Secure Domain Name System
+              (DNS) Dynamic Update", RFC 3007, November 2000.
+
+7 - Author's Address
+
+   Brian Wellington
+   Nominum, Inc.
+   950 Charter Street
+   Redwood City, CA 94063
+
+   Phone: +1 650 381 6022
+   EMail: Brian.Wellington@nominum.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wellington                  Standards Track                     [Page 6]
+
+RFC 3008                DNSSEC Signing Authority           November 2000
+
+
+8  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2000).  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 Standards process must be
+   followed, or as required to translate it into 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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wellington                  Standards Track                     [Page 7]
+
diff --git a/doc/rfc/rfc3071.txt b/doc/rfc/rfc3071.txt
new file mode 100644
index 0000000..2c4d52f
--- /dev/null
+++ b/doc/rfc/rfc3071.txt
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+Network Working Group                                         J. Klensin
+Request for Comments: 3071                                 February 2001
+Category: Informational
+
+
+      Reflections on the DNS, RFC 1591, and Categories of Domains
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2001).  All Rights Reserved.
+
+Abstract
+
+   RFC 1591, "Domain Name System Structure and Delegation", laid out the
+   basic administrative design and principles for the allocation and
+   administration of domains, from the top level down.  It was written
+   before the introduction of the world wide web (WWW) and rapid growth
+   of the Internet put significant market, social, and political
+   pressure on domain name allocations.  In recent years, 1591 has been
+   cited by all sides in various debates, and attempts have been made by
+   various bodies to update it or adjust its provisions, sometimes under
+   pressures that have arguably produced policies that are less well
+   thought out than the original.  Some of those efforts have begun from
+   misconceptions about the provisions of 1591 or the motivation for
+   those provisions.  The current directions of the Internet Corporation
+   for Assigned Names and Numbers (ICANN) and other groups who now
+   determine the Domain Name System (DNS) policy directions appear to be
+   drifting away from the policies and philosophy of 1591.  This
+   document is being published primarily for historical context and
+   comparative purposes, essentially to document some thoughts about how
+   1591 might have been interpreted and adjusted by the Internet
+   Assigned Numbers Authority (IANA) and ICANN to better reflect today's
+   world while retaining characteristics and policies that have proven
+   to be effective in supporting Internet growth and stability.  An
+   earlier variation of this memo was submitted to ICANN as a comment on
+   its evolving Top-level Domain (TLD) policies.
+
+
+
+
+
+
+
+
+
+Klensin                      Informational                      [Page 1]
+
+RFC 3071          Reflections on the DNS and RFC 1591      February 2001
+
+
+1.  Introduction
+
+   RFC 1591 [1] has been heavily discussed and referenced in the last
+   year or two, especially in discussions within ICANN and its
+   predecessors about the creation, delegation, and management of top-
+   level domains.  In particular, the ICANN Domain Name Supporting
+   Organization (DNSO), and especially its ccTLD constituency, have been
+   the home of many discussions in which 1591 and interpretations of it
+   have been cited in support of a variety of sometimes-contradictory
+   positions.  During that period, other discussions have gone on to try
+   to reconstruct the thinking that went into RFC 1591.  Those in turn
+   have led me and others to muse on how that original thinking might
+   relate to some of the issues being raised.  1591 is, I believe, one
+   of Jon Postel's masterpieces, drawing together very different
+   philosophies (e.g., his traditional view that people are basically
+   reasonable and will do the right thing if told what it is with some
+   stronger mechanisms when that model is not successful) into a single
+   whole.
+
+   RFC 1591 was written in the context of the assumption that what it
+   described as generic TLDs would be bound to policies and categories
+   of registration (see the "This domain is intended..."  text in
+   section 2) while ccTLDs were expected to be used primarily to support
+   users and uses within and for a country and its residents.  The
+   notion that different domains would be run in different ways --albeit
+   within the broad contexts of "public service on behalf of the
+   Internet community" and "trustee... for the global Internet
+   community"-- was considered a design feature and a safeguard against
+   a variety of potential abuses.  Obviously the world has changed in
+   many ways in the seven or eight years since 1591 was written.  In
+   particular, the Internet has become more heavily used and, because
+   the design of the world wide web has put domain names in front of
+   users, top-level domain names and registrations in them have been
+   heavily in demand: not only has the number of hosts increased
+   dramatically during that time, but the ratio between registered
+   domain names and physical hosts has increased very significantly.
+
+   The issues 1591 attempted to address when it was written and those we
+   face today have not changed significantly in principle.  But one
+   alternative to present trends would be to take a step back to refine
+   it into a model that can function effectively today.  Therefore, it
+   may be useful to try to reconstruct 1591's principles and think about
+   their applicability today as a model that could continue to be
+   applied: not because it is historically significant, but because many
+   of its elements have proven to work reasonably well, even in
+   difficult situations.  In particular, for many domains (some in
+   1591's "generic" list and others in its "country code" category) the
+   notion of "public service" --expected then to imply being carried out
+
+
+
+Klensin                      Informational                      [Page 2]
+
+RFC 3071          Reflections on the DNS and RFC 1591      February 2001
+
+
+   at no or minimal cost to the users, not merely on a non-profit
+   basis-- has yielded to profitability calculations.  And, in most of
+   the rest, considerations of at least calculating and recovering costs
+   have crept in.  While many of us feel some nostalgia for the old
+   system, it is clear that its days are waning if not gone: perhaps the
+   public service notions as understood when 1591 was written just don't
+   scale to rapid internet growth and very large numbers of
+   yregistrations.
+
+   In particular, some ccTLDs have advertised for registrations outside
+   the designated countries (or other entities), while others have made
+   clear decisions to allow registrations by non-nationals.  These
+   decisions and others have produced protests from many sides,
+   suggesting, in turn, that a recategorization is in order.  For
+   example, we have heard concerns by governments and managers of
+   traditional, "public service", in-country, ccTLDs about excessive
+   ICANN interference and fears of being forced to conform to
+   internationally-set policies for dispute resolution when their
+   domestic ones are considered more appropriate.  We have also heard
+   concerns from registrars and operators of externally-marketed ccTLDs
+   about unreasonable government interference and from gTLD registrars
+   and registries about unreasonable competition from aggressively
+   marketed ccTLDs.  The appropriate distinction is no longer between
+   what RFC 1591 described as "generic" TLDs (but which were really
+   intended to be "purpose-specific", a term I will use again below) and
+   ccTLDs but among:
+
+      (i) true "generic" TLDs, in which any registration is acceptable
+      and, ordinarily, registrations from all sources are actively
+      promoted.  This list currently includes (the formerly purpose-
+      specific) COM, NET, and ORG, and some ccTLDs.  There have been
+      proposals from time to time for additional TLDs of this variety in
+      which, as with COM (and, more recently, NET and ORG) anyone
+      (generally subject only to name conflicts and national law) could
+      register who could pay the fees.
+
+      (ii) purpose-specific TLDs, in which registration is accepted only
+      from organizations or individuals meeting particular
+      qualifications, but where those qualifications are not tied to
+      national boundaries.  This list currently includes INT, EDU, the
+      infrastructure domain ARPA, and, arguably, the specialized US
+      Government TLDs MIL and GOV.  There have been proposals from time
+      to time for other international TLDs of this variety, e.g., for
+      medical entities such as physicians and hospitals and for museums.
+      ICANN has recently approved several TLDs of this type and
+      describes them as "sponsored" TLDs.
+
+
+
+
+
+Klensin                      Informational                      [Page 3]
+
+RFC 3071          Reflections on the DNS and RFC 1591      February 2001
+
+
+      (iii) Country domains, operated according to the original
+      underlying assumptions of 1591, i.e., registrants are largely
+      expected to be people or other entities within the country.  While
+      external registrations might be accepted by some of these, the
+      country does not aggressively advertise for such registrations,
+      nor does anyone expect to derive significant fee revenue from
+      them.  All current domains in this category are ccTLDs, but not
+      all ccTLDs are in this category.
+
+   These categories are clearly orthogonal to the association between
+   the use of the IS 3166-1 registered code list [2] and two-letter
+   "country" domain names.  If that relationship is to be maintained
+   (and I believe it is desirable), the only inherent requirement is
+   that no two-letter TLDs be created except from that list (in order to
+   avoid future conflicts).  ICANN should control the allocation and
+   delegation of TLDs using these, and other, criteria, but only
+   registered 3166-1 two letter codes should be used as two-letter TLDs.
+
+2. Implications of the Categories
+
+   If we had adopted this type of three-way categorization and could
+   make it work, I believe it would have presented several opportunities
+   for ICANN and the community more generally to reduce controversies
+   and move forward.  Of course, there will be cases where the
+   categorization of a particular domain and its operating style will
+   not be completely clear-cut (see section 3, below).  But having ICANN
+   work out procedures for dealing with those (probably few) situations
+   appears preferable to strategies that would tend to propel ICANN into
+   areas that are beyond its competence or that might require
+   significant expansion of its mandate.
+
+   First, the internally-operated ccTLDs (category iii above) should not
+   be required to have much interaction with ICANN or vice versa.  Once
+   a domain of this sort is established and delegated, and assuming that
+   the "admin contact in the country" rule is strictly observed, the
+   domain should be able to function effectively without ICANN
+   intervention or oversight.  In particular, while a country might
+   choose to adopt the general ICANN policies about dispute resolution
+   or name management, issues that arise in these areas might equally
+   well be dealt with exclusively under applicable national laws.  If a
+   domain chooses to use ICANN services that cost resources to provide,
+   it should contribute to ICANN's support, but, if it does not, ICANN
+   should not presume to charge it for other than a reasonable fraction
+   of the costs to ICANN of operating the root, root servers, and any
+   directory systems that are generally agreed upon to be necessary and
+   in which the domain participates.
+
+
+
+
+
+Klensin                      Informational                      [Page 4]
+
+RFC 3071          Reflections on the DNS and RFC 1591      February 2001
+
+
+   By contrast, ccTLDs operated as generic domains ought to be treated
+   as generic domains.  ICANN dispute resolution and name management
+   policies and any special rules developed to protect the Internet
+   public in multiple registrar or registry situations should reasonably
+   apply.
+
+3.  Telling TLD types apart
+
+   If appropriate policies are adopted, ccTLDs operated as generic
+   domains (category (i) above) and those operated as country domains
+   (category (iii) above) ought to be able to be self-identified.  There
+   are several criteria that could be applied to make this
+   determination.  For example, either a domain is aggressively seeking
+   outside registrations or it is not and either the vast majority of
+   registrants in a domain are in-country or they are not.  One could
+   also think of this as the issue of having some tangible level of
+   presence in the jurisdiction - e.g., is the administrative contact
+   subject, in practical terms, to the in-country laws, or are the
+   registration rules such that it is reasonably likely that a court in
+   the jurisdiction of the country associated with the domain can
+   exercise jurisdiction and enforce a judgment against the registrant.
+
+   One (fairly non-intrusive) rule ICANN might well impose on all top-
+   level domains is that they identify and publish the policies they
+   intend to use.  E.g., registrants in a domain that will use the laws
+   of one particular country to resolve disputes should have a
+   reasonable opportunity to understand those policies prior to
+   registration and to make other arrangements (e.g., to register
+   elsewhere) if that mechanism for dispute resolution is not
+   acceptable.  Giving IANA (as the root registrar) incorrect
+   information about the purpose and use of a domain should be subject
+   to challenge, and should be grounds for reviewing the appropriateness
+   of the domain delegation, just as not acting consistently and
+   equitably provides such grounds under the original provisions of RFC
+   1591.
+
+   In order to ensure the availability of accurate and up-to-date
+   registration information the criteria must be consistent, and
+   consistent with more traditional gTLDs, for all nominally country
+   code domains operating as generic TLDs.
+
+4. The role of ICANN in country domains
+
+   ICANN (and IANA) should, as described above, have as little
+   involvement as possible in the direction of true country [code]
+   domains (i.e., category (iii)).  There is no particular reason why
+
+
+
+
+
+Klensin                      Informational                      [Page 5]
+
+RFC 3071          Reflections on the DNS and RFC 1591      February 2001
+
+
+   these domains should be subject to ICANN regulation beyond the basic
+   principles of 1591 and associated arrangements needed to ensure
+   Internet interoperability and stability.
+
+   ICANN's avoiding such involvement strengthens it: the desirability of
+   avoiding collisions with national sovereignty, determinations about
+   government legitimacy, and the authority of someone purportedly
+   writing on behalf of a government, is as important today as it was
+   when 1591 was written.  The alternatives take us quickly from
+   "administration" into "internet governance" or, in the case of
+   determining which claimant is the legitimate government of a country,
+   "international relations", and the reasons for not moving in that
+   particular direction are legion.
+
+5. The role of governments
+
+   The history of IANA strategy in handling ccTLDs included three major
+   "things to avoid" considerations:
+
+      * Never get involved in determining which entities were countries
+        and which ones were not.
+
+      * Never get involved in determining who was, or was not, the
+        legitimate government of a country.  And, more generally, avoid
+        deciding what entity --government, religion, commercial,
+        academic, etc.-- has what legitimacy or rights.
+
+      * If possible, never become involved in in-country disputes.
+        Instead, very strongly encourage internal parties to work
+        problems out among themselves.  At most, adopt a role as
+        mediator and educator, rather than judge, unless abuses are very
+        clear and clearly will not be settled by any internal mechanism.
+
+   All three considerations were obviously intended to avoid IANA's
+   being dragged into a political morass in which it had (and, I
+   suggest, has) no competence to resolve the issues and could only get
+   bogged down.  The first consideration was the most visible (and the
+   easiest) and was implemented by strict and careful adherence (see
+   below) to the ISO 3166 registered Country Code list.  If an entity
+   had a code, it was eligible to be registered with a TLD (although
+   IANA was free to apply additional criteria-most of them stated in
+   1591).  If it did not, there were no exceptions: the applicant's only
+   recourse was a discussion with the 3166 Registration Authority (now
+   Maintenance Agency, often known just as "3166/MA") or the UN
+   Statistical Office (now Statistics Bureau), not with IANA.
+
+
+
+
+
+
+Klensin                      Informational                      [Page 6]
+
+RFC 3071          Reflections on the DNS and RFC 1591      February 2001
+
+
+   There are actually five ccTLD exceptions to the strict rules.  One,
+   "UK", is historical: it predates the adoption of ISO 3166 for this
+   purpose.  The others --Ascension Island, Guernsey, Isle of Man, and
+   Jersey --are arguably, at least in retrospect, just mistakes.
+   Regardless of the historical reasons (about which there has been much
+   speculation), it is almost certainly the case that the right way to
+   handle mistakes of this sort is to acknowledge them and move on,
+   rather than trying to use them as precedents to justify more
+   mistakes.
+
+   This, obviously, is also the argument against use of the "reserved"
+   list (technically internal to the 3166 maintenance activity, and not
+   part of the Standard): since IANA (or ICANN) can ask that a name be
+   placed on that list, there is no rule of an absolute determination by
+   an external organization.  Purported countries can come to ICANN,
+   insist on having delegations made and persuade ICANN to ask that the
+   names be reserved.  Then, since the reserved name would exist, they
+   could insist that the domain be delegated.  Worse, someone could use
+   another organization to request reservation of the name by 3166/MA;
+   once it was reserved, ICANN might be hard-pressed not to do the
+   delegation.  Of course, ICANN could (and probably would be forced to)
+   adopt additional criteria other than appearance on the "reserved
+   list" in order to delegate such domains.  But those criteria would
+   almost certainly be nearly equivalent to determining which applicants
+   were legitimate and stable enough to be considered a country, the
+   exact decision process that 1591 strove to avoid.
+
+   The other two considerations were more subtle and not always
+   successful: from time to time, both before and after the formal
+   policy shifted toward "governments could have their way", IANA
+   received letters from people purporting to be competent government
+   authorities asking for changes.  Some of them turned out later to not
+   have that authority or appropriate qualifications.  The assumption of
+   1591 itself was that, if the "administrative contact in country" rule
+   was strictly observed, as was the rule that delegation changes
+   requested by the administrative contact would be honored, then, if a
+   government _really_ wanted to assert itself, it could pressure the
+   administrative contact into requesting the changes it wanted, using
+   whatever would pass for due process in that country.  And the ability
+   to apply that process and pressure would effectively determine who
+   was the government and who wasn't, and would do so far more
+   effectively than any IANA evaluation of, e.g., whether the letterhead
+   on a request looked authentic (and far more safely for ICANN than
+   asking the opinion of any particular other government or selection of
+   governments).
+
+
+
+
+
+
+Klensin                      Informational                      [Page 7]
+
+RFC 3071          Reflections on the DNS and RFC 1591      February 2001
+
+
+   Specific language in 1591 permitted IANA to adopt a "work it out
+   yourselves; if we have to decide, we will strive for a solution that
+   is not satisfactory to any party" stance.  That approach was used
+   successfully, along with large doses of education, on many occasions
+   over the years, to avoid IANA's having to assume the role of judge
+   between conflicting parties.
+
+   Similar principles could be applied to the boundary between country-
+   code-based generic TLDs and country domains.  Different countries,
+   under different circumstances, might prefer to operate the ccTLD
+   either as a national service or as a profit center where the
+   "customers" were largely external.  Whatever decisions were made
+   historically, general Internet stability argues that changes should
+   not be made lightly.  At the same time, if a government wishes to
+   make a change, the best mechanism for doing so is not to involve
+   ICANN in a potential determination of legitimacy (or even to have
+   ICANN's Government Advisory Committee (GAC) try to formally make that
+   decision for individual countries) but for the relevant government to
+   use its own procedures to persuade the administrative contact to
+   request the change and for IANA to promptly and efficiently carry out
+   requests made by administrative contacts.
+
+6. Implications for the current ICANN DNSO structure.
+
+   The arguments by some of the ccTLD administrators that they are
+   different from the rest of the ICANN and DNSO structures are (in this
+   model) correct: they are different.  The ccTLDs that are operating as
+   generic TLDs should be separated from the ccTLD constituency and
+   joined to the gTLD constituency.  The country ccTLDs should be
+   separated from ICANN's immediate Supporting Organization structure,
+   and operate in a parallel and advisory capacity to ICANN, similar to
+   the arrangements used with the GAC.  The DNSO and country TLDs should
+   not be required to interact with each other except on a mutually
+   voluntary basis and, if ICANN needs interaction or advice from some
+   of all of those TLDs, it would be more appropriate to get it in the
+   form of an advisory body like the GAC rather than as DNSO
+   constituency.
+
+7. References
+
+   [1] Postel, J., "Domain Name System Structure and Delegation", RFC
+       1591, March 1994.
+
+   [2] ISO 3166. ISO 3166-1. Codes for the representation of names of
+       countries and their subdivisions - Part 1: Country codes (1997).
+
+
+
+
+
+
+Klensin                      Informational                      [Page 8]
+
+RFC 3071          Reflections on the DNS and RFC 1591      February 2001
+
+
+8. Acknowledgements and disclaimer
+
+   These reflections have been prepared in my individual capacity and do
+   not necessarily reflect the views of my past or present employers.
+   Several people, including Randy Bush, Theresa Swinehart, Zita Wenzel,
+   Geoff Huston, Havard Eidnes, and several anonymous reviewers, made
+   suggestions or offered editorial comments about earlier versions of
+   this document.  Cord Wischhoefer, of the ISO 3166/MA, was also kind
+   enough to look at the draft and supplied some useful details.  Those
+   comments contributed significantly to whatever clarity the document
+   has, but the author bears responsibility for the selection of
+   comments which were ultimately incorporated and the way in which the
+   conclusions were presented.
+
+9.  Security Considerations
+
+   This memo addresses the context for a set of administrative decisions
+   and procedures, and does not raise or address security issues.
+
+10. Author's Address
+
+   John C. Klensin
+   1770 Massachusetts Ave, Suite 322
+   Cambridge, MA 02140, USA
+
+   EMail: klensin@jck.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Klensin                      Informational                      [Page 9]
+
+RFC 3071          Reflections on the DNS and RFC 1591      February 2001
+
+
+11. Full Copyright Statement
+
+   Copyright (C) The Internet Society 2001. All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others provided that the above copyright notice and this paragraph
+   are included on all such copies.  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 required to translate it into 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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Klensin                      Informational                     [Page 10]
+
diff --git a/doc/rfc/rfc3090.txt b/doc/rfc/rfc3090.txt
new file mode 100644
index 0000000..08008f7
--- /dev/null
+++ b/doc/rfc/rfc3090.txt
@@ -0,0 +1,619 @@
+
+
+
+
+
+
+Network Working Group                                           E. Lewis
+Request for Comments: 3090                                      NAI Labs
+Category: Standards Track                                     March 2001
+
+
+          DNS Security Extension Clarification on Zone Status
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2001).  All Rights Reserved.
+
+Abstract
+
+   The definition of a secured zone is presented, clarifying and
+   updating sections of RFC 2535.  RFC 2535 defines a zone to be secured
+   based on a per algorithm basis, e.g., a zone can be secured with RSA
+   keys, and not secured with DSA keys.  This document changes this to
+   define a zone to be secured or not secured regardless of the key
+   algorithm used (or not used).  To further simplify the determination
+   of a zone's status, "experimentally secure" status is deprecated.
+
+1 Introduction
+
+   Whether a DNS zone is "secured" or not is a question asked in at
+   least four contexts.  A zone administrator asks the question when
+   configuring a zone to use DNSSEC.  A dynamic update server asks the
+   question when an update request arrives, which may require DNSSEC
+   processing.  A delegating zone asks the question of a child zone when
+   the parent enters data indicating the status the child.  A resolver
+   asks the question upon receipt of data belonging to the zone.
+
+1.1 When a Zone's Status is Important
+
+   A zone administrator needs to be able to determine what steps are
+   needed to make the zone as secure as it can be.  Realizing that due
+   to the distributed nature of DNS and its administration, any single
+   zone is at the mercy of other zones when it comes to the appearance
+   of security.  This document will define what makes a zone qualify as
+   secure.
+
+
+
+
+Lewis                       Standards Track                     [Page 1]
+
+RFC 3090         DNS Security Extension on Zone Status        March 2001
+
+
+   A name server performing dynamic updates needs to know whether a zone
+   being updated is to have signatures added to the updated data, NXT
+   records applied, and other required processing.  In this case, it is
+   conceivable that the name server is configured with the knowledge,
+   but being able to determine the status of a zone by examining the
+   data is a desirable alternative to configuration parameters.
+
+   A delegating zone is required to indicate whether a child zone is
+   secured.  The reason for this requirement lies in the way in which a
+   resolver makes its own determination about a zone (next paragraph).
+   To shorten a long story, a parent needs to know whether a child
+   should be considered secured.  This is a two part question.  Under
+   what circumstances does a parent consider a child zone to be secure,
+   and how does a parent know if the child conforms?
+
+   A resolver needs to know if a zone is secured when the resolver is
+   processing data from the zone.  Ultimately, a resolver needs to know
+   whether or not to expect a usable signature covering the data.  How
+   this determination is done is out of the scope of this document,
+   except that, in some cases, the resolver will need to contact the
+   parent of the zone to see if the parent states that the child is
+   secured.
+
+1.2 Islands of Security
+
+   The goal of DNSSEC is to have each zone secured, from the root zone
+   and the top-level domains down the hierarchy to the leaf zones.
+   Transitioning from an unsecured DNS, as we have now, to a fully
+   secured - or "as much as will be secured" - tree will take some time.
+   During this time, DNSSEC will be applied in various locations in the
+   tree, not necessarily "top down."
+
+   For example, at a particular instant, the root zone and the "test."
+   TLD might be secured, but region1.test. might not be.  (For
+   reference, let's assume that region2.test. is secured.)  However,
+   subarea1.region1.test. may have gone through the process of becoming
+   secured, along with its delegations.  The dilemma here is that
+   subarea1 cannot get its zone keys properly signed as its parent zone,
+   region1, is not secured.
+
+   The colloquial phrase describing the collection of contiguous secured
+   zones at or below subarea1.region1.test. is an "island of security."
+   The only way in which a DNSSEC resolver will come to trust any data
+   from this island is if the resolver is pre-configured with the zone
+   key(s) for subarea1.region1.test., i.e., the root of the island of
+   security.  Other resolvers (not so configured) will recognize this
+   island as unsecured.
+
+
+
+
+Lewis                       Standards Track                     [Page 2]
+
+RFC 3090         DNS Security Extension on Zone Status        March 2001
+
+
+   An island of security begins with one zone whose public key is pre-
+   configured in resolvers.  Within this island are subzones which are
+   also secured.  The "bottom" of the island is defined by delegations
+   to unsecured zones.  One island may also be on top of another -
+   meaning that there is at least one unsecured zone between the bottom
+   of the upper island and the root of the lower secured island.
+
+   Although both subarea1.region1.test. and region2.test. have both been
+   properly brought to a secured state by the administering staff, only
+   the latter of the two is actually "globally" secured - in the sense
+   that all DNSSEC resolvers can and will verify its data.  The former,
+   subarea1, will be seen as secured by a subset of those resolvers,
+   just those appropriately configured.  This document refers to such
+   zones as being "locally" secured.
+
+   In RFC 2535, there is a provision for "certification authorities,"
+   entities that will sign public keys for zones such as subarea1.
+   There is another document, [RFC3008], that restricts this activity.
+   Regardless of the other document, resolvers would still need proper
+   configuration to be able to use the certification authority to verify
+   the data for the subarea1 island.
+
+1.2.1 Determining the closest security root
+
+   Given a domain, in order to determine whether it is secure or not,
+   the first step is to determine the closest security root.  The
+   closest security root is the top of an island of security whose name
+   has the most matching (in order from the root) right-most labels to
+   the given domain.
+
+   For example, given a name "sub.domain.testing.signed.exp.test.", and
+   given the secure roots "exp.test.", "testing.signed.exp.test." and
+   "not-the-same.xy.", the middle one is the closest.  The first secure
+   root shares 2 labels, the middle 4, and the last 0.
+
+   The reason why the closest is desired is to eliminate false senses of
+   insecurity because of a NULL key.  Continuing with the example, the
+   reason both "testing..." and "exp.test." are listed as secure root is
+   presumably because "signed.exp.test." is unsecured (has a NULL key).
+   If we started to descend from "exp.test." to our given domain
+   (sub...), we would encounter a NULL key and conclude that sub... was
+   unsigned.  However, if we descend from "testing..." and find keys
+   "domain...." then we can conclude that "sub..." is secured.
+
+   Note that this example assumes one-label deep zones, and assumes that
+   we do not configure overlapping islands of security.  To be clear,
+   the definition given should exclude "short.xy.test." from being a
+   closest security root for "short.xy." even though 2 labels match.
+
+
+
+Lewis                       Standards Track                     [Page 3]
+
+RFC 3090         DNS Security Extension on Zone Status        March 2001
+
+
+   Overlapping islands of security introduce no conceptually interesting
+   ideas and do not impact the protocol in anyway.  However, protocol
+   implementers are advised to make sure their code is not thrown for a
+   loop by overlaps.  Overlaps are sure to be configuration problems as
+   islands of security grow to encompass larger regions of the name
+   space.
+
+1.3 Parent Statement of Child Security
+
+   In 1.1 of this document, there is the comment "the parent states that
+   the child is secured."  This has caused quite a bit of confusion.
+
+   The need to have the parent "state" the status of a child is derived
+   from the following observation.  If you are looking to see if an
+   answer is secured, that it comes from an "island of security" and is
+   properly signed, you must begin at the (appropriate) root of the
+   island of security.
+
+   To find the answer you are inspecting, you may have to descend
+   through zones within the island of security.  Beginning with the
+   trusted root of the island, you descend into the next zone down.  As
+   you trust the upper zone, you need to get data from it about the next
+   zone down, otherwise there is a vulnerable point in which a zone can
+   be hijacked. When or if you reach a point of traversing from a
+   secured zone to an unsecured zone, you have left the island of
+   security and should conclude that the answer is unsecured.
+
+   However, in RFC 2535, section 2.3.4, these words seem to conflict
+   with the need to have the parent "state" something about a child:
+
+      There MUST be a zone KEY RR, signed by its superzone, for every
+      subzone if the superzone is secure.  This will normally appear in
+      the subzone and may also be included in the superzone.  But, in
+      the case of an unsecured subzone which can not or will not be
+      modified to add any security RRs, a KEY declaring the subzone to
+      be unsecured MUST appear with the superzone signature in the
+      superzone, if the superzone is secure.
+
+   The confusion here is that in RFC 2535, a secured parent states that
+   a child is secured by SAYING NOTHING ("may also be" as opposed to
+   "MUST also be").  This is counter intuitive, the fact that an absence
+   of data means something is "secured."  This notion, while acceptable
+   in a theoretic setting has met with some discomfort in an operation
+   setting.  However, the use of "silence" to state something does
+   indeed work in this case, so there hasn't been sufficient need
+   demonstrated to change the definition.
+
+
+
+
+
+Lewis                       Standards Track                     [Page 4]
+
+RFC 3090         DNS Security Extension on Zone Status        March 2001
+
+
+1.4 Impact on RFC 2535
+
+   This document updates sections of RFC 2535.  The definition of a
+   secured zone is an update to section 3.4 of the RFC.  Section 3.4 is
+   updated to eliminate the definition of experimental keys and
+   illustrate a way to still achieve the functionality they were
+   designed to provide.  Section 3.1.3 is updated by the specifying the
+   value of the protocol octet in a zone key.
+
+1.5 "MUST" and other key words
+
+   The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY"
+   in this document are to be interpreted as described in [RFC 2119].
+   Currently, only "MUST" is used in this document.
+
+2 Status of a Zone
+
+   In this section, rules governing a zone's DNSSEC status are
+   presented.  There are three levels of security defined: global,
+   local, and unsecured.  A zone is globally secure when it complies
+   with the strictest set of DNSSEC processing rules.  A zone is locally
+   secured when it is configured in such a way that only resolvers that
+   are appropriately configured see the zone as secured.  All other
+   zones are unsecured.
+
+   Note: there currently is no document completely defining DNSSEC
+   verification rules.  For the purposes of this document, the strictest
+   rules are assumed to state that the verification chain of zone keys
+   parallels the delegation tree up to the root zone.  (See 2.b below.)
+   This is not intended to disallow alternate verification paths, just
+   to establish a baseline definition.
+
+   To avoid repetition in the rules below, the following terms are
+   defined.
+
+   2.a Zone signing KEY RR - A KEY RR whose flag field has the value 01
+   for name type (indicating a zone key) and either value 00 or value 01
+   for key type (indicating a key permitted to authenticate data).  (See
+   RFC 2535, section 3.1.2).  The KEY RR also has a protocol octet value
+   of DNSSEC (3) or ALL (255).
+
+   The definition updates RFC 2535's definition of a zone key.  The
+   requirement that the protocol field be either DNSSEC or ALL is a new
+   requirement (a change to section 3.1.3.)
+
+   2.b On-tree Validation - The authorization model in which only the
+   parent zone is recognized to supply a DNSSEC-meaningful signature
+   that is used by a resolver to build a chain of trust from the child's
+
+
+
+Lewis                       Standards Track                     [Page 5]
+
+RFC 3090         DNS Security Extension on Zone Status        March 2001
+
+
+   keys to a recognized root of security.  The term "on-tree" refers to
+   following the DNS domain hierarchy (upwards) to reach a trusted key,
+   presumably the root key if no other key is available.  The term
+   "validation" refers to the digital signature by the parent to prove
+   the integrity, authentication and authorization of the child's key to
+   sign the child's zone data.
+
+   2.c Off-tree Validation - Any authorization model that permits domain
+   names other than the parent's to provide a signature over a child's
+   zone keys that will enable a resolver to trust the keys.
+
+2.1 Globally Secured
+
+   A globally secured zone, in a nutshell, is a zone that uses only
+   mandatory to implement algorithms (RFC 2535, section 3.2) and relies
+   on a key certification chain that parallels the delegation tree (on-
+   tree validation).  Globally secured zones are defined by the
+   following rules.
+
+   2.1.a. The zone's apex MUST have a KEY RR set.  There MUST be at
+   least one zone signing KEY RR (2.a) of a mandatory to implement
+   algorithm in the set.
+
+   2.1.b. The zone's apex KEY RR set MUST be signed by a private key
+   belonging to the parent zone.  The private key's public companion
+   MUST be a zone signing KEY RR (2.a) of a mandatory to implement
+   algorithm and owned by the parent's apex.
+
+   If a zone cannot get a conforming signature from the parent zone, the
+   child zone cannot be considered globally secured.  The only exception
+   to this is the root zone, for which there is no parent zone.
+
+   2.1.c. NXT records MUST be deployed throughout the zone.  (Clarifies
+   RFC 2535, section 2.3.2.)  Note: there is some operational discomfort
+   with the current NXT record.  This requirement is open to
+   modification when two things happen.  First, an alternate mechanism
+   to the NXT is defined and second, a means by which a zone can
+   indicate that it is using an alternate method.
+
+   2.1.d. Each RR set that qualifies for zone membership MUST be signed
+   by a key that is in the apex's KEY RR set and is a zone signing KEY
+   RR (2.a) of a mandatory to implement algorithm.  (Updates 2535,
+   section 2.3.1.)
+
+   Mentioned earlier, the root zone is a special case.  The root zone
+   will be considered to be globally secured provided that if conforms
+   to the rules for locally secured, with the exception that rule 2.1.a.
+   be also met (mandatory to implement requirement).
+
+
+
+Lewis                       Standards Track                     [Page 6]
+
+RFC 3090         DNS Security Extension on Zone Status        March 2001
+
+
+2.2 Locally Secured
+
+   The term "locally" stems from the likely hood that the only resolvers
+   to be configured for a particular zone will be resolvers "local" to
+   an organization.
+
+   A locally secured zone is a zone that complies with rules like those
+   for a globally secured zone with the following exceptions.  The
+   signing keys may be of an algorithm that is not mandatory to
+   implement and/or the verification of the zone keys in use may rely on
+   a verification chain that is not parallel to the delegation tree
+   (off-tree validation).
+
+   2.2.a. The zone's apex MUST have a KEY RR set.  There MUST be at
+   least one zone signing KEY RR (2.a) in the set.
+
+   2.2.b. The zone's apex KEY RR set MUST be signed by a private key and
+   one of the following two subclauses MUST hold true.
+
+   2.2.b.1 The private key's public companion MUST be pre-configured in
+   all the resolvers of interest.
+
+   2.2.b.2 The private key's public companion MUST be a zone signing KEY
+   RR (2.a) authorized to provide validation of the zone's apex KEY RR
+   set, as recognized by resolvers of interest.
+
+   The previous sentence is trying to convey the notion of using a
+   trusted third party to provide validation of keys.  If the domain
+   name owning the validating key is not the parent zone, the domain
+   name must represent someone the resolver trusts to provide
+   validation.
+
+   2.2.c. NXT records MUST be deployed throughout the zone.  Note: see
+   the discussion following 2.1.c.
+
+   2.2.d. Each RR set that qualifies for zone membership MUST be signed
+   by a key that is in the apex's KEY RR set and is a zone signing KEY
+   RR (2.a).  (Updates 2535, section 2.3.1.)
+
+2.3 Unsecured
+
+   All other zones qualify as unsecured.  This includes zones that are
+   designed to be experimentally secure, as defined in a later section
+   on that topic.
+
+
+
+
+
+
+
+Lewis                       Standards Track                     [Page 7]
+
+RFC 3090         DNS Security Extension on Zone Status        March 2001
+
+
+2.4 Wrap up
+
+   The designation of globally secured, locally secured, and unsecured
+   are merely labels to apply to zones, based on their contents.
+   Resolvers, when determining whether a signature is expected or not,
+   will only see a zone as secured or unsecured.
+
+   Resolvers that follow the most restrictive DNSSEC verification rules
+   will only see globally secured zones as secured, and all others as
+   unsecured, including zones which are locally secured.  Resolvers that
+   are not as restrictive, such as those that implement algorithms in
+   addition to the mandatory to implement algorithms, will see some
+   locally secured zones as secured.
+
+   The intent of the labels "global" and "local" is to identify the
+   specific attributes of a zone.  The words are chosen to assist in the
+   writing of a document recommending the actions a zone administrator
+   take in making use of the DNS security extensions.  The words are
+   explicitly not intended to convey a state of compliance with DNS
+   security standards.
+
+3 Experimental Status
+
+   The purpose of an experimentally secured zone is to facilitate the
+   migration from an unsecured zone to a secured zone.  This distinction
+   is dropped.
+
+   The objective of facilitating the migration can be achieved without a
+   special designation of an experimentally secure status.
+   Experimentally secured is a special case of locally secured.  A zone
+   administrator can achieve this by publishing a zone with signatures
+   and configuring a set of test resolvers with the corresponding public
+   keys.  Even if the public key is published in a KEY RR, as long as
+   there is no parent signature, the resolvers will need some pre-
+   configuration to know to process the signatures.  This allows a zone
+   to be secured with in the sphere of the experiment, yet still be
+   registered as unsecured in the general Internet.
+
+4 IANA Considerations
+
+   This document does not request any action from an assigned number
+   authority nor recommends any actions.
+
+
+
+
+
+
+
+
+
+Lewis                       Standards Track                     [Page 8]
+
+RFC 3090         DNS Security Extension on Zone Status        March 2001
+
+
+5 Security Considerations
+
+   Without a means to enforce compliance with specified protocols or
+   recommended actions, declaring a DNS zone to be "completely" secured
+   is impossible.  Even if, assuming an omnipotent view of DNS, one can
+   declare a zone to be properly configured for security, and all of the
+   zones up to the root too, a misbehaving resolver could be duped into
+   believing bad data.  If a zone and resolver comply, a non-compliant
+   or subverted parent could interrupt operations.  The best that can be
+   hoped for is that all parties are prepared to be judged secure and
+   that security incidents can be traced to the cause in short order.
+
+6 Acknowledgements
+
+   The need to refine the definition of a secured zone has become
+   apparent through the efforts of the participants at two DNSSEC
+   workshops, sponsored by the NIC-SE (.se registrar), CAIRN (a DARPA-
+   funded research network), and other workshops.  Further discussions
+   leading to the document include Olafur Gudmundsson, Russ Mundy,
+   Robert Watson, and Brian Wellington.  Roy Arends, Ted Lindgreen and
+   others have contributed significant input via the namedroppers
+   mailing list.
+
+7 References
+
+   [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
+             STD 13, RFC 1034, November 1987.
+
+   [RFC1035] Mockapetris, P., "Domain Names - Implementation and
+             Specification", STD 13, RFC 1035, November 1987.
+
+   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+             Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2136] Vixie, P., (Ed.), Thomson, S., Rekhter, Y. and J. Bound,
+             "Dynamic Updates in the Domain Name System", RFC 2136,
+             April 1997.
+
+   [RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC
+             2535, March 1999.
+
+   [RFC3007] Wellington, B., "Simple Secure Domain Name System (DNS)
+             Dynamic Update", RFC 3007, November 2000.
+
+   [RFC3008] Wellington, B., "Domain Name System Security (DNSSEC)
+             Signing Authority", RFC 3008, November 2000.
+
+
+
+
+
+Lewis                       Standards Track                     [Page 9]
+
+RFC 3090         DNS Security Extension on Zone Status        March 2001
+
+
+10 Author's Address
+
+   Edward Lewis
+   NAI Labs
+   3060 Washington Road Glenwood
+   MD 21738
+
+   Phone: +1 443 259 2352
+   EMail: lewis@tislabs.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lewis                       Standards Track                    [Page 10]
+
+RFC 3090         DNS Security Extension on Zone Status        March 2001
+
+
+11 Full Copyright Statement
+
+   Copyright (C) The Internet Society (2001).  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 Standards process must be
+   followed, or as required to translate it into 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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lewis                       Standards Track                    [Page 11]
+
diff --git a/doc/rfc/rfc3110.txt b/doc/rfc/rfc3110.txt
new file mode 100644
index 0000000..7646948
--- /dev/null
+++ b/doc/rfc/rfc3110.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+Network Working Group                                    D. Eastlake 3rd
+Request for Comments: 3110                                      Motorola
+Obsoletes: 2537                                                 May 2001
+Category: Standards Track
+
+
+      RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS)
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2001).  All Rights Reserved.
+
+Abstract
+
+   This document describes how to produce RSA/SHA1 SIG resource records
+   (RRs) in Section 3 and, so as to completely replace RFC 2537,
+   describes how to produce RSA KEY RRs in Section 2.
+
+   Since the adoption of a Proposed Standard for RSA signatures in the
+   DNS (Domain Name Space), advances in hashing have been made.  A new
+   DNS signature algorithm is defined to make these advances available
+   in SIG RRs.  The use of the previously specified weaker mechanism is
+   deprecated.  The algorithm number of the RSA KEY RR is changed to
+   correspond to this new SIG algorithm.  No other changes are made to
+   DNS security.
+
+Acknowledgements
+
+   Material and comments from the following have been incorporated and
+   are gratefully acknowledged:
+
+      Olafur Gudmundsson
+
+      The IESG
+
+      Charlie Kaufman
+
+      Steve Wang
+
+
+
+
+
+D. Eastlake 3rd             Standards Track                     [Page 1]
+
+RFC 3110              RSA SIGs and KEYs in the DNS              May 2001
+
+
+Table of Contents
+
+   1. Introduction................................................... 2
+   2. RSA Public KEY Resource Records................................ 3
+   3. RSA/SHA1 SIG Resource Records.................................. 3
+   4. Performance Considerations..................................... 4
+   5. IANA Considerations............................................ 5
+   6. Security Considerations........................................ 5
+   References........................................................ 5
+   Author's Address.................................................. 6
+   Full Copyright Statement.......................................... 7
+
+1. Introduction
+
+   The Domain Name System (DNS) is the global hierarchical replicated
+   distributed database system for Internet addressing, mail proxy, and
+   other information [RFC1034, 1035, etc.].  The DNS has been extended
+   to include digital signatures and cryptographic keys as described in
+   [RFC2535].  Thus the DNS can now be secured and used for secure key
+   distribution.
+
+   Familiarity with the RSA and SHA-1 algorithms is assumed [Schneier,
+   FIP180] in this document.
+
+   RFC 2537 described how to store RSA keys and RSA/MD5 based signatures
+   in the DNS.  However, since the adoption of RFC 2537, continued
+   cryptographic research has revealed hints of weakness in the MD5
+   [RFC1321] algorithm used in RFC 2537.  The SHA1 Secure Hash Algorithm
+   [FIP180], which produces a larger hash, has been developed.  By now
+   there has been sufficient experience with SHA1 that it is generally
+   acknowledged to be stronger than MD5.  While this stronger hash is
+   probably not needed today in most secure DNS zones, critical zones
+   such a root, most top level domains, and some second and third level
+   domains, are sufficiently valuable targets that it would be negligent
+   not to provide what are generally agreed to be stronger mechanisms.
+   Furthermore, future advances in cryptanalysis and/or computer speeds
+   may require a stronger hash everywhere.  In addition, the additional
+   computation required by SHA1 above that required by MD5 is
+   insignificant compared with the computational effort required by the
+   RSA modular exponentiation.
+
+   This document describes how to produce RSA/SHA1 SIG RRs in Section 3
+   and, so as to completely replace RFC 2537, describes how to produce
+   RSA KEY RRs in Section 2.
+
+   Implementation of the RSA algorithm in DNS with SHA1 is MANDATORY for
+   DNSSEC.  The generation of RSA/MD5 SIG RRs as described in RFC 2537
+   is NOT RECOMMENDED.
+
+
+
+D. Eastlake 3rd             Standards Track                     [Page 2]
+
+RFC 3110              RSA SIGs and KEYs in the DNS              May 2001
+
+
+   The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", "NOT
+   RECOMMENDED", and "MAY" in this document are to be interpreted as
+   described in RFC 2119.
+
+2. RSA Public KEY Resource Records
+
+   RSA public keys are stored in the DNS as KEY RRs using algorithm
+   number 5 [RFC2535].  The structure of the algorithm specific portion
+   of the RDATA part of such RRs is as shown below.
+
+         Field             Size
+         -----             ----
+         exponent length   1 or 3 octets (see text)
+         exponent          as specified by length field
+         modulus           remaining space
+
+   For interoperability, the exponent and modulus are each limited to
+   4096 bits in length.  The public key exponent is a variable length
+   unsigned integer.  Its length in octets is represented as one octet
+   if it is in the range of 1 to 255 and by a zero octet followed by a
+   two octet unsigned length if it is longer than 255 bytes.  The public
+   key modulus field is a multiprecision unsigned integer.  The length
+   of the modulus can be determined from the RDLENGTH and the preceding
+   RDATA fields including the exponent.  Leading zero octets are
+   prohibited in the exponent and modulus.
+
+   Note: KEY RRs for use with RSA/SHA1 DNS signatures MUST use this
+   algorithm number (rather than the algorithm number specified in the
+   obsoleted RFC 2537).
+
+   Note: This changes the algorithm number for RSA KEY RRs to be the
+   same as the new algorithm number for RSA/SHA1 SIGs.
+
+3. RSA/SHA1 SIG Resource Records
+
+   RSA/SHA1 signatures are stored in the DNS using SIG resource records
+   (RRs) with algorithm number 5.
+
+   The signature portion of the SIG RR RDATA area, when using the
+   RSA/SHA1 algorithm, is calculated as shown below.  The data signed is
+   determined as specified in RFC 2535.  See RFC 2535 for fields in the
+   SIG RR RDATA which precede the signature itself.
+
+         hash = SHA1 ( data )
+
+         signature = ( 01 | FF* | 00 | prefix | hash ) ** e (mod n)
+
+
+
+
+
+D. Eastlake 3rd             Standards Track                     [Page 3]
+
+RFC 3110              RSA SIGs and KEYs in the DNS              May 2001
+
+
+   where SHA1 is the message digest algorithm documented in [FIP180],
+   "|" is concatenation, "e" is the private key exponent of the signer,
+   and "n" is the modulus of the signer's public key.  01, FF, and 00
+   are fixed octets of the corresponding hexadecimal value.  "prefix" is
+   the ASN.1 BER SHA1 algorithm designator prefix required in PKCS1
+   [RFC2437], that is,
+
+         hex 30 21 30 09 06 05 2B 0E 03 02 1A 05 00 04 14
+
+   This prefix is included to make it easier to use standard
+   cryptographic libraries.  The FF octet MUST be repeated the maximum
+   number of times such that the value of the quantity being
+   exponentiated is one octet shorter than the value of n.
+
+   (The above specifications are identical to the corresponding parts of
+   Public Key Cryptographic Standard #1 [RFC2437].)
+
+   The size of "n", including most and least significant bits (which
+   will be 1) MUST be not less than 512 bits and not more than 4096
+   bits.  "n" and "e" SHOULD be chosen such that the public exponent is
+   small.  These are protocol limits.  For a discussion of key size see
+   RFC 2541.
+
+   Leading zero bytes are permitted in the RSA/SHA1 algorithm signature.
+
+4. Performance Considerations
+
+   General signature generation speeds are roughly the same for RSA and
+   DSA [RFC2536].  With sufficient pre-computation, signature generation
+   with DSA is faster than RSA.  Key generation is also faster for DSA.
+   However, signature verification is an order of magnitude slower with
+   DSA when the RSA public exponent is chosen to be small as is
+   recommended for KEY RRs used in domain name system (DNS) data
+   authentication.
+
+   A public exponent of 3 minimizes the effort needed to verify a
+   signature.  Use of 3 as the public exponent is weak for
+   confidentiality uses since, if the same data can be collected
+   encrypted under three different keys with an exponent of 3 then,
+   using the Chinese Remainder Theorem [NETSEC], the original plain text
+   can be easily recovered.  If a key is known to be used only for
+   authentication, as is the case with DNSSEC, then an exponent of 3 is
+   acceptable.  However other applications in the future may wish to
+   leverage DNS distributed keys for applications that do require
+   confidentiality.  For keys which might have such other uses, a more
+   conservative choice would be 65537 (F4, the fourth fermat number).
+
+
+
+
+
+D. Eastlake 3rd             Standards Track                     [Page 4]
+
+RFC 3110              RSA SIGs and KEYs in the DNS              May 2001
+
+
+   Current DNS implementations are optimized for small transfers,
+   typically less than 512 bytes including DNS overhead.  Larger
+   transfers will perform correctly and extensions have been
+   standardized [RFC2671] to make larger transfers more efficient, it is
+   still advisable at this time to make reasonable efforts to minimize
+   the size of KEY RR sets stored within the DNS consistent with
+   adequate security.  Keep in mind that in a secure zone, at least one
+   authenticating SIG RR will also be returned.
+
+5. IANA Considerations
+
+   The DNSSEC algorithm number 5 is allocated for RSA/SHA1 SIG RRs and
+   RSA KEY RRs.
+
+6. Security Considerations
+
+   Many of the general security considerations in RFC 2535 apply.  Keys
+   retrieved from the DNS should not be trusted unless (1) they have
+   been securely obtained from a secure resolver or independently
+   verified by the user and (2) this secure resolver and secure
+   obtainment or independent verification conform to security policies
+   acceptable to the user.  As with all cryptographic algorithms,
+   evaluating the necessary strength of the key is essential and
+   dependent on local policy.  For particularly critical applications,
+   implementers are encouraged to consider the range of available
+   algorithms and key sizes.  See also RFC 2541, "DNS Security
+   Operational Considerations".
+
+References
+
+   [FIP180]   U.S. Department of Commerce, "Secure Hash Standard", FIPS
+              PUB 180-1, 17 Apr 1995.
+
+   [NETSEC]   Network Security: PRIVATE Communications in a PUBLIC
+              World, Charlie Kaufman, Radia Perlman, & Mike Speciner,
+              Prentice Hall Series in Computer Networking and
+              Distributed Communications, 1995.
+
+   [RFC1034]  Mockapetris, P., "Domain Names - Concepts and Facilities",
+              STD 13, RFC 1034, November 1987.
+
+   [RFC1035]  Mockapetris, P., "Domain Names - Implementation and
+              Specification", STD 13, RFC 1035, November 1987.
+
+   [RFC1321]  Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
+              April 1992.
+
+
+
+
+
+D. Eastlake 3rd             Standards Track                     [Page 5]
+
+RFC 3110              RSA SIGs and KEYs in the DNS              May 2001
+
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2437]  Kaliski, B. and J. Staddon, "PKCS #1: RSA Cryptography
+              Specifications Version 2.0", RFC 2437, October 1998.
+
+   [RFC2535]  Eastlake, D., "Domain Name System Security Extensions",
+              RFC 2535, March 1999.
+
+   [RFC2536]  Eastlake, D., "DSA KEYs and SIGs in the Domain Name System
+              (DNS)", RFC 2536, March 1999.
+
+   [RFC2537]  Eastlake, D., "RSA/MD5 KEYs and SIGs in the Domain Name
+              System (DNS)", RFC 2537, March 1999.
+
+   [RFC2541]  Eastlake, D., "DNS Security Operational Considerations",
+              RFC 2541, March 1999.
+
+   [RFC2671]  Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
+              2671, August 1999.
+
+   [Schneier] Bruce Schneier, "Applied Cryptography Second Edition:
+              protocols, algorithms, and source code in C", 1996, John
+              Wiley and Sons, ISBN 0-471-11709-9.
+
+Author's Address
+
+   Donald E. Eastlake 3rd
+   Motorola
+   155 Beaver Street
+   Milford, MA 01757 USA
+
+   Phone:   +1-508-261-5434 (w)
+            +1-508-634-2066 (h)
+   Fax      +1-508-261-4777 (w)
+   EMail:   Donald.Eastlake@motorola.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+D. Eastlake 3rd             Standards Track                     [Page 6]
+
+RFC 3110              RSA SIGs and KEYs in the DNS              May 2001
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2001).  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 Standards process must be
+   followed, or as required to translate it into 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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+D. Eastlake 3rd             Standards Track                     [Page 7]
+
diff --git a/doc/rfc/rfc3123.txt b/doc/rfc/rfc3123.txt
new file mode 100644
index 0000000..3b2fe00
--- /dev/null
+++ b/doc/rfc/rfc3123.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+Network Working Group                                            P. Koch
+Request for Comments: 3123                        Universitaet Bielefeld
+Category: Experimental                                         June 2001
+
+
+          A DNS RR Type for Lists of Address Prefixes (APL RR)
+
+Status of this Memo
+
+   This memo defines an Experimental Protocol for the Internet
+   community.  It does not specify an Internet standard of any kind.
+   Discussion and suggestions for improvement are requested.
+   Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2001).  All Rights Reserved.
+
+Abstract
+
+   The Domain Name System (DNS) is primarily used to translate domain
+   names into IPv4 addresses using A RRs (Resource Records).  Several
+   approaches exist to describe networks or address ranges.  This
+   document specifies a new DNS RR type "APL" for address prefix lists.
+
+1. Conventions used in this document
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC2119].
+
+   Domain names herein are for explanatory purposes only and should not
+   be expected to lead to useful information in real life [RFC2606].
+
+2. Background
+
+   The Domain Name System [RFC1034], [RFC1035] provides a mechanism to
+   associate addresses and other Internet infrastructure elements with
+   hierarchically built domain names.  Various types of resource records
+   have been defined, especially those for IPv4 and IPv6 [RFC2874]
+   addresses.  In [RFC1101] a method is described to publish information
+   about the address space allocated to an organisation.  In older BIND
+   versions, a weak form of controlling access to zone data was
+   implemented using TXT RRs describing address ranges.
+
+   This document specifies a new RR type for address prefix lists.
+
+
+
+
+
+Koch                          Experimental                      [Page 1]
+
+RFC 3123                       DNS APL RR                      June 2001
+
+
+3. APL RR Type
+
+   An APL record has the DNS type of "APL" and a numeric value of 42
+   [IANA].  The APL RR is defined in the IN class only.  APL RRs cause
+   no additional section processing.
+
+4. APL RDATA format
+
+   The RDATA section consists of zero or more items (<apitem>) of the
+   form
+
+      +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+      |                          ADDRESSFAMILY                        |
+      +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+      |             PREFIX            | N |         AFDLENGTH         |
+      +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+      /                            AFDPART                            /
+      |                                                               |
+      +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+
+      ADDRESSFAMILY     16 bit unsigned value as assigned by IANA
+                        (see IANA Considerations)
+      PREFIX            8 bit unsigned binary coded prefix length.
+                        Upper and lower bounds and interpretation of
+                        this value are address family specific.
+      N                 negation flag, indicates the presence of the
+                        "!" character in the textual format.  It has
+                        the value "1" if the "!" was given, "0" else.
+      AFDLENGTH         length in octets of the following address
+                        family dependent part (7 bit unsigned).
+      AFDPART           address family dependent part.  See below.
+
+   This document defines the AFDPARTs for address families 1 (IPv4) and
+   2 (IPv6).  Future revisions may deal with additional address
+   families.
+
+4.1. AFDPART for IPv4
+
+   The encoding of an IPv4 address (address family 1) follows the
+   encoding specified for the A RR by [RFC1035], section 3.4.1.
+
+   PREFIX specifies the number of bits of the IPv4 address starting at
+   the most significant bit.  Legal values range from 0 to 32.
+
+   Trailing zero octets do not bear any information (e.g., there is no
+   semantic difference between 10.0.0.0/16 and 10/16) in an address
+   prefix, so the shortest possible AFDLENGTH can be used to encode it.
+   However, for DNSSEC [RFC2535] a single wire encoding must be used by
+
+
+
+Koch                          Experimental                      [Page 2]
+
+RFC 3123                       DNS APL RR                      June 2001
+
+
+   all.  Therefore the sender MUST NOT include trailing zero octets in
+   the AFDPART regardless of the value of PREFIX.  This includes cases
+   in which AFDLENGTH times 8 results in a value less than PREFIX.  The
+   AFDPART is padded with zero bits to match a full octet boundary.
+
+   An IPv4 AFDPART has a variable length of 0 to 4 octets.
+
+4.2. AFDPART for IPv6
+
+   The 128 bit IPv6 address (address family 2) is encoded in network
+   byte order (high-order byte first).
+
+   PREFIX specifies the number of bits of the IPv6 address starting at
+   the most significant bit.  Legal values range from 0 to 128.
+
+   With the same reasoning as in 4.1 above, the sender MUST NOT include
+   trailing zero octets in the AFDPART regardless of the value of
+   PREFIX.  This includes cases in which AFDLENGTH times 8 results in a
+   value less than PREFIX.  The AFDPART is padded with zero bits to
+   match a full octet boundary.
+
+   An IPv6 AFDPART has a variable length of 0 to 16 octets.
+
+5. Zone File Syntax
+
+   The textual representation of an APL RR in a DNS zone file is as
+   follows:
+
+   <owner>   IN   <TTL>   APL   {[!]afi:address/prefix}*
+
+   The data consists of zero or more strings of the address family
+   indicator <afi>, immediately followed by a colon ":", an address,
+   immediately followed by the "/" character, immediately followed by a
+   decimal numeric value for the prefix length.  Any such string may be
+   preceded by a "!" character.  The strings are separated by
+   whitespace.  The <afi> is the decimal numeric value of that
+   particular address family.
+
+5.1. Textual Representation of IPv4 Addresses
+
+   An IPv4 address in the <address> part of an <apitem> is in dotted
+   quad notation, just as in an A RR.  The <prefix> has values from the
+   interval 0..32 (decimal).
+
+
+
+
+
+
+
+
+Koch                          Experimental                      [Page 3]
+
+RFC 3123                       DNS APL RR                      June 2001
+
+
+5.2. Textual Representation of IPv6 Addresses
+
+   The representation of an IPv6 address in the <address> part of an
+   <apitem> follows [RFC2373], section 2.2.  Legal values for <prefix>
+   are from the interval 0..128 (decimal).
+
+6. APL RR usage
+
+   An APL RR with empty RDATA is valid and implements an empty list.
+   Multiple occurrences of the same <apitem> in a single APL RR are
+   allowed and MUST NOT be merged by a DNS server or resolver.
+   <apitems> MUST be kept in order and MUST NOT be rearranged or
+   aggregated.
+
+   A single APL RR may contain <apitems> belonging to different address
+   families.  The maximum number of <apitems> is upper bounded by the
+   available RDATA space.
+
+   RRSets consisting of more than one APL RR are legal but the
+   interpretation is left to the particular application.
+
+7. Applicability Statement
+
+   The APL RR defines a framework without specifying any particular
+   meaning for the list of prefixes.  It is expected that APL RRs will
+   be used in different application scenarios which have to be
+   documented separately.  Those scenarios may be distinguished by
+   characteristic prefixes placed in front of the DNS owner name.
+
+   An APL application specification MUST include information on
+
+   o  the characteristic prefix, if any
+
+   o  how to interpret APL RRSets consisting of more than one RR
+
+   o  how to interpret an empty APL RR
+
+   o  which address families are expected to appear in the APL RRs for
+      that application
+
+   o  how to deal with APL RR list elements which belong to other
+      address families, including those not yet defined
+
+   o  the exact semantics of list elements negated by the "!" character
+
+
+
+
+
+
+
+Koch                          Experimental                      [Page 4]
+
+RFC 3123                       DNS APL RR                      June 2001
+
+
+   Possible applications include the publication of address ranges
+   similar to [RFC1101], description of zones built following [RFC2317]
+   and in-band access control to limit general access or zone transfer
+   (AXFR) availability for zone data held in DNS servers.
+
+   The specification of particular application scenarios is out of the
+   scope of this document.
+
+8. Examples
+
+   The following examples only illustrate some of the possible usages
+   outlined in the previous section.  None of those applications are
+   hereby specified nor is it implied that any particular APL RR based
+   application does exist now or will exist in the future.
+
+  ; RFC 1101-like announcement of address ranges for foo.example
+  foo.example.             IN APL 1:192.168.32.0/21 !1:192.168.38.0/28
+
+  ; CIDR blocks covered by classless delegation
+  42.168.192.IN-ADDR.ARPA. IN APL ( 1:192.168.42.0/26 1:192.168.42.64/26
+                                  1:192.168.42.128/25 )
+
+  ; Zone transfer restriction
+  _axfr.sbo.example.       IN APL 1:127.0.0.1/32 1:172.16.64.0/22
+
+  ; List of address ranges for multicast
+  multicast.example.       IN APL 1:224.0.0.0/4  2:FF00:0:0:0:0:0:0:0/8
+
+   Note that since trailing zeroes are ignored in the first APL RR the
+   AFDLENGTH of both <apitems> is three.
+
+9. Security Considerations
+
+   Any information obtained from the DNS should be regarded as unsafe
+   unless techniques specified in [RFC2535] or [RFC2845] were used.  The
+   definition of a new RR type does not introduce security problems into
+   the DNS, but usage of information made available by APL RRs may
+   compromise security.  This includes disclosure of network topology
+   information and in particular the use of APL RRs to construct access
+   control lists.
+
+
+
+
+
+
+
+
+
+
+
+Koch                          Experimental                      [Page 5]
+
+RFC 3123                       DNS APL RR                      June 2001
+
+
+10. IANA Considerations
+
+   This section is to be interpreted as following [RFC2434].
+
+   This document does not define any new namespaces.  It uses the 16 bit
+   identifiers for address families maintained by IANA in
+   http://www.iana.org/numbers.html.
+
+   The IANA assigned numeric RR type value 42 for APL [IANA].
+
+11. Acknowledgements
+
+   The author would like to thank Mark Andrews, Olafur Gudmundsson, Ed
+   Lewis, Thomas Narten, Erik Nordmark, and Paul Vixie for their review
+   and constructive comments.
+
+12. References
+
+   [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
+             STD 13, RFC 1034, November 1987.
+
+   [RFC1035] Mockapetris, P., "Domain Names - Implementation and
+             Specification", STD 13, RFC 1035, November 1987.
+
+   [RFC1101] Mockapetris, P., "DNS Encoding of Network Names and Other
+             Types", RFC 1101, April 1989.
+
+   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+             Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
+             Specification", RFC 2181, July 1997.
+
+   [RFC2317] Eidnes, H., de Groot, G. and P. Vixie, "Classless IN-
+             ADDR.ARPA delegation", BCP 20, RFC 2317, March 1998.
+
+   [RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing
+             Architecture", RFC 2373, July 1998.
+
+   [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
+             IANA Considerations Section in RFCs", BCP 26, RFC 2434,
+             October 1998.
+
+   [RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC
+             2535, March 1999.
+
+   [RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS Names",
+             BCP 32, RFC 2606, June 1999.
+
+
+
+Koch                          Experimental                      [Page 6]
+
+RFC 3123                       DNS APL RR                      June 2001
+
+
+   [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington,
+             "Secret Key Transaction Authentication for DNS (TSIG)", RFC
+             2845, May 2000.
+
+   [RFC2874] Crawford, M. and C. Huitema, "DNS Extensions to Support
+             IPv6 Address Aggregation and Renumbering", RFC 2874, July
+             2000.
+
+   [IANA]    http://www.iana.org/assignments/dns-parameters
+
+13. Author's Address
+
+   Peter Koch
+   Universitaet Bielefeld
+   Technische Fakultaet
+   D-33594 Bielefeld
+   Germany
+
+   Phone: +49 521 106 2902
+   EMail: pk@TechFak.Uni-Bielefeld.DE
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Koch                          Experimental                      [Page 7]
+
+RFC 3123                       DNS APL RR                      June 2001
+
+
+14. Full Copyright Statement
+
+   Copyright (C) The Internet Society (2001).  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 Standards process must be
+   followed, or as required to translate it into 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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Koch                          Experimental                      [Page 8]
+
diff --git a/doc/rfc/rfc3152.txt b/doc/rfc/rfc3152.txt
new file mode 100644
index 0000000..b226ce6
--- /dev/null
+++ b/doc/rfc/rfc3152.txt
@@ -0,0 +1,227 @@
+
+
+
+
+
+
+Network Working Group                                            R. Bush
+Request for Comments: 3152                                         RGnet
+BCP: 49                                                      August 2001
+Updates: 2874, 2772, 2766, 2553, 1886
+Category: Best Current Practice
+
+
+                         Delegation of IP6.ARPA
+
+Status of this Memo
+
+   This document specifies an Internet Best Current Practices for the
+   Internet Community, and requests discussion and suggestions for
+   improvements.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2001).  All Rights Reserved.
+
+Abstract
+
+   This document discusses the need for delegation of the IP6.ARPA DNS
+   zone, and specifies a plan for the technical operation thereof.
+
+1. Why IP6.ARPA?
+
+   In the IPv6 address space, there is a need for 'reverse mapping' of
+   addresses to DNS names analogous to that provided by the IN-ADDR.ARPA
+   zone for IPv4.
+
+   The IAB recommended that the ARPA top level domain (the name is now
+   considered an acronym for "Address and Routing Parameters Area") be
+   used for technical infrastructure sub-domains when possible.  It is
+   already in use for IPv4 reverse mapping and has been established as
+   the location for E.164 numbering on the Internet [RFC2916 RFC3026].
+
+   IETF consensus was reached that the IP6.ARPA domain be used for
+   address to DNS name mapping for the IPv6 address space [RFC2874].
+
+2. Obsoleted Usage
+
+   This document deprecates references to IP6.INT in [RFC1886] section
+   2.5, [RFC2553] section 6.2.3, [RFC2766] section 4.1, [RFC2772]
+   section 7.1.c, and [RFC2874] section 2.5.
+
+   In this context, 'deprecate' means that the old usage is not
+   appropriate for new implementations, and IP6.INT will likely be
+   phased out in an orderly fashion.
+
+
+
+Bush                     Best Current Practice                  [Page 1]
+
+RFC 3152                 Delegation of IP6.ARPA              August 2001
+
+
+3. IANA Considerations
+
+   This memo requests that the IANA delegate the IP6.ARPA domain
+   following instructions to be provided by the IAB.  Names within this
+   zone are to be further delegated to the regional IP registries in
+   accordance with the delegation of IPv6 address space to those
+   registries.  The names allocated should be hierarchic in accordance
+   with the address space assignment.
+
+4. Security Considerations
+
+   While DNS spoofing of address to name mapping has been exploited in
+   IPv4, delegation of the IP6.ARPA zone creates no new threats to the
+   security of the internet.
+
+5. References
+
+   [RFC1886]   Thomson, S. and C. Huitema, "DNS Extensions to support IP
+               version 6", RFC 1886, December 1995.
+
+   [RFC2553]   Gilligan, R., Thomson, S., Bound, J. and W. Stevens,
+               "Basic Socket Interface Extensions for IPv6", RFC 2553,
+               March 1999.
+
+   [RFC2766]   Tsirtsis, G. and P. Srisuresh, "Network Address
+               Translation - Protocol Translation (NAT-PT)", RFC 2766,
+               February 2000.
+
+   [RFC2772]   Rockell, R. and R. Fink, "6Bone Backbone Routing
+               Guidelines", RFC 2772, February 2000.
+
+   [RFC2874]   Crawford, M. and C. Huitema, "DNS Extensions to Support
+               IPv6 Address Aggregation and Renumbering", RFC 2874, July
+               2001.
+
+   [RFC2916]   Faltstrom, P., "E.164 number and DNS", RFC 2916,
+               September 2000.
+
+   [RFC3026]   Blane, R., "Liaison to IETF/ISOC on ENUM", RFC 3026,
+               January 2001.
+
+
+
+
+
+
+
+
+
+
+
+Bush                     Best Current Practice                  [Page 2]
+
+RFC 3152                 Delegation of IP6.ARPA              August 2001
+
+
+6. Author's Address
+
+   Randy Bush
+   5147 Crystal Springs
+   Bainbridge Island, WA US-98110
+
+   Phone: +1 206 780 0431
+   EMail: randy@psg.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bush                     Best Current Practice                  [Page 3]
+
+RFC 3152                 Delegation of IP6.ARPA              August 2001
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2001).  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 Standards process must be
+   followed, or as required to translate it into 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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bush                     Best Current Practice                  [Page 4]
+
diff --git a/doc/rfc/rfc3197.txt b/doc/rfc/rfc3197.txt
new file mode 100644
index 0000000..94cefa4
--- /dev/null
+++ b/doc/rfc/rfc3197.txt
@@ -0,0 +1,283 @@
+
+
+
+
+
+
+Network Working Group                                         R. Austein
+Request for Comments: 3197                                 InterNetShare
+Category: Informational                                    November 2001
+
+
+             Applicability Statement for DNS MIB Extensions
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2001).  All Rights Reserved.
+
+Abstract
+
+   This document explains why, after more than six years as proposed
+   standards, the DNS Server and Resolver MIB extensions were never
+   deployed, and recommends retiring these MIB extensions by moving them
+   to Historical status.
+
+1. History
+
+   The road to the DNS MIB extensions was paved with good intentions.
+
+   In retrospect, it's obvious that the working group never had much
+   agreement on what belonged in the MIB extensions, just that we should
+   have some.  This happened during the height of the craze for MIB
+   extensions in virtually every protocol that the IETF was working on
+   at the time, so the question of why we were doing this in the first
+   place never got a lot of scrutiny.  Very late in the development
+   cycle we discovered that much of the support for writing the MIB
+   extensions in the first place had come from people who wanted to use
+   SNMP SET operations to update DNS zones on the fly.  Examination of
+   the security model involved, however, led us to conclude that this
+   was not a good way to do dynamic update and that a separate DNS
+   Dynamic Update protocol would be necessary.
+
+   The MIB extensions started out being fairly specific to one
+   particular DNS implementation (BIND-4.8.3); as work progressed, the
+   BIND-specific portions were rewritten to be as implementation-neutral
+   as we knew how to make them, but somehow every revision of the MIB
+   extensions managed to create new counters that just happened to
+   closely match statistics kept by some version of BIND.  As a result,
+   the MIB extensions ended up being much too big, which raised a number
+
+
+
+Austein                      Informational                      [Page 1]
+
+RFC 3197      Applicability Statement - DNS MIB Extensions November 2001
+
+
+   of concerns with the network management directorate, but the WG
+   resisted every attempt to remove any of these variables.  In the end,
+   large portions of the MIB extensions were moved into optional groups
+   in an attempt to get the required subset down to a manageable size.
+
+   The DNS Server and Resolver MIB extensions were one of the first
+   attempts to write MIB extensions for a protocol usually considered to
+   be at the application layer.  Fairly early on it became clear that,
+   while it was certainly possible to write MIB extensions for DNS, the
+   SMI was not really designed with this sort of thing in mind.  A case
+   in point was the attempt to provide direct indexing into the caches
+   in the resolver MIB extensions: while arguably the only sane way to
+   do this for a large cache, this required much more complex indexing
+   clauses than is usual, and ended up running into known length limits
+   for object identifiers in some SNMP implementations.
+
+   Furthermore, the lack of either real proxy MIB support in SNMP
+   managers or a standard subagent protocol meant that there was no
+   reasonable way to implement the MIB extensions in the dominant
+   implementation (BIND).  When the AgentX subagent protocol was
+   developed a few years later, we initially hoped that this would
+   finally clear the way for an implementation of the DNS MIB
+   extensions, but by the time AgentX was a viable protocol it had
+   become clear that nobody really wanted to implement these MIB
+   extensions.
+
+   Finally, the MIB extensions took much too long to produce.  In
+   retrospect, this should have been a clear warning sign, particularly
+   when the WG had clearly become so tired of the project that the
+   authors found it impossible to elicit any comments whatsoever on the
+   documents.
+
+2. Lessons
+
+   Observations based on the preceding list of mistakes, for the benefit
+   of anyone else who ever attempts to write DNS MIB extensions again:
+
+   -  Define a clear set of goals before writing any MIB extensions.
+      Know who the constituency is and make sure that what you write
+      solves their problem.
+
+   -  Keep the MIB extensions short, and don't add variables just
+      because somebody in the WG thinks they'd be a cool thing to
+      measure.
+
+   -  If some portion of the task seems to be very hard to do within the
+      SMI, that's a strong hint that SNMP is not the right tool for
+      whatever it is that you're trying to do.
+
+
+
+Austein                      Informational                      [Page 2]
+
+RFC 3197      Applicability Statement - DNS MIB Extensions November 2001
+
+
+   -  If the entire project is taking too long, perhaps that's a hint
+      too.
+
+3. Recommendation
+
+   In view of the community's apparent total lack of interest in
+   deploying these MIB extensions, we recommend that RFCs 1611 and 1612
+   be reclassified as Historical documents.
+
+4. Security Considerations
+
+   Re-classifying an existing MIB document from Proposed Standard to
+   Historic should not have any negative impact on security for the
+   Internet.
+
+5. IANA Considerations
+
+   Getting rid of the DNS MIB extensions should not impose any new work
+   on IANA.
+
+6. Acknowledgments
+
+   The author would like to thank all the people who were involved in
+   this project over the years for their optimism and patience,
+   misguided though it may have been.
+
+7. References
+
+   [DNS-SERVER-MIB]     Austein, R. and J. Saperia, "DNS Server MIB
+                        Extensions", RFC 1611, May 1994.
+
+   [DNS-RESOLVER-MIB]   Austein, R. and J. Saperia, "DNS Resolver MIB
+                        Extensions", RFC 1612, May 1994.
+
+   [DNS-DYNAMIC-UPDATE] Vixie, P., Thomson, S., Rekhter, Y. and J.
+                        Bound, "Dynamic Updates in the Domain Name
+                        System (DNS UPDATE)", RFC 2136, April 1997.
+
+   [AGENTX]             Daniele, M., Wijnen, B., Ellison, M., and D.
+                        Francisco, "Agent Extensibility (AgentX)
+                        Protocol Version 1", RFC 2741, January 2000.
+
+
+
+
+
+
+
+
+
+
+Austein                      Informational                      [Page 3]
+
+RFC 3197      Applicability Statement - DNS MIB Extensions November 2001
+
+
+8. Author's Address
+
+   Rob Austein
+   InterNetShare, Incorporated
+   325M Sharon Park Drive, Suite 308
+   Menlo Park, CA  94025
+   USA
+
+   EMail: sra@hactrn.net
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Austein                      Informational                      [Page 4]
+
+RFC 3197      Applicability Statement - DNS MIB Extensions November 2001
+
+
+9. Full Copyright Statement
+
+   Copyright (C) The Internet Society (2001).  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 Standards process must be
+   followed, or as required to translate it into 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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Austein                      Informational                      [Page 5]
+
diff --git a/doc/rfc/rfc3225.txt b/doc/rfc/rfc3225.txt
new file mode 100644
index 0000000..13e6768
--- /dev/null
+++ b/doc/rfc/rfc3225.txt
@@ -0,0 +1,339 @@
+
+
+
+
+
+
+Network Working Group                                          D. Conrad
+Request for Comments: 3225                                 Nominum, Inc.
+Category: Standards Track                                  December 2001
+
+
+                 Indicating Resolver Support of DNSSEC
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2001).  All Rights Reserved.
+
+Abstract
+
+   In order to deploy DNSSEC (Domain Name System Security Extensions)
+   operationally, DNSSEC aware servers should only perform automatic
+   inclusion of DNSSEC RRs when there is an explicit indication that the
+   resolver can understand those RRs.  This document proposes the use of
+   a bit in the EDNS0 header to provide that explicit indication and
+   describes the necessary protocol changes to implement that
+   notification.
+
+1. Introduction
+
+   DNSSEC [RFC2535] has been specified to provide data integrity and
+   authentication to security aware resolvers and applications through
+   the use of cryptographic digital signatures.  However, as DNSSEC is
+   deployed, non-DNSSEC-aware clients will likely query DNSSEC-aware
+   servers.  In such situations, the DNSSEC-aware server (responding to
+   a request for data in a signed zone) will respond with SIG, KEY,
+   and/or NXT records.  For reasons described in the subsequent section,
+   such responses can have significant negative operational impacts for
+   the DNS infrastructure.
+
+   This document discusses a method to avoid these negative impacts,
+   namely DNSSEC-aware servers should only respond with SIG, KEY, and/or
+   NXT RRs when there is an explicit indication from the resolver that
+   it can understand those RRs.
+
+   For the purposes of this document, "DNSSEC security RRs" are
+   considered RRs of type SIG, KEY, or NXT.
+
+
+
+Conrad                      Standards Track                     [Page 1]
+
+RFC 3225         Indicating Resolver Support of DNSSEC     December 2001
+
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC2119].
+
+2. Rationale
+
+   Initially, as DNSSEC is deployed, the vast majority of queries will
+   be from resolvers that are not DNSSEC aware and thus do not
+   understand or support the DNSSEC security RRs.  When a query from
+   such a resolver is received for a DNSSEC signed zone, the DNSSEC
+   specification indicates the nameserver must respond with the
+   appropriate DNSSEC security RRs.  As DNS UDP datagrams are limited to
+   512 bytes [RFC1035], responses including DNSSEC security RRs have a
+   high probability of resulting in a truncated response being returned
+   and the resolver retrying the query using TCP.
+
+   TCP DNS queries result in significant overhead due to connection
+   setup and teardown.  Operationally, the impact of these TCP queries
+   will likely be quite detrimental in terms of increased network
+   traffic (typically five packets for a single query/response instead
+   of two), increased latency resulting from the additional round trip
+   times, increased incidences of queries failing due to timeouts, and
+   significantly increased load on nameservers.
+
+   In addition, in preliminary and experimental deployment of DNSSEC,
+   there have been reports of non-DNSSEC aware resolvers being unable to
+   handle responses which contain DNSSEC security RRs, resulting in the
+   resolver failing (in the worst case) or entire responses being
+   ignored (in the better case).
+
+   Given these operational implications, explicitly notifying the
+   nameserver that the client is prepared to receive (if not understand)
+   DNSSEC security RRs would be prudent.
+
+   Client-side support of DNSSEC is assumed to be binary -- either the
+   client is willing to receive all DNSSEC security RRs or it is not
+   willing to accept any.  As such, a single bit is sufficient to
+   indicate client-side DNSSEC support.  As effective use of DNSSEC
+   implies the need of EDNS0 [RFC2671], bits in the "classic" (non-EDNS
+   enhanced DNS header) are scarce, and there may be situations in which
+   non-compliant caching or forwarding servers inappropriately copy data
+   from classic headers as queries are passed on to authoritative
+   servers, the use of a bit from the EDNS0 header is proposed.
+
+   An alternative approach would be to use the existence of an EDNS0
+   header as an implicit indication of client-side support of DNSSEC.
+   This approach was not chosen as there may be applications in which
+   EDNS0 is supported but in which the use of DNSSEC is inappropriate.
+
+
+
+Conrad                      Standards Track                     [Page 2]
+
+RFC 3225         Indicating Resolver Support of DNSSEC     December 2001
+
+
+3. Protocol Changes
+
+   The mechanism chosen for the explicit notification of the ability of
+   the client to accept (if not understand) DNSSEC security RRs is using
+   the most significant bit of the Z field on the EDNS0 OPT header in
+   the query.  This bit is referred to as the "DNSSEC OK" (DO) bit.  In
+   the context of the EDNS0 OPT meta-RR, the DO bit is the first bit of
+   the third and fourth bytes of the "extended RCODE and flags" portion
+   of the EDNS0 OPT meta-RR, structured as follows:
+
+                +0 (MSB)                +1 (LSB)
+         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+      0: |   EXTENDED-RCODE      |       VERSION         |
+         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+      2: |DO|                    Z                       |
+         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+   Setting the DO bit to one in a query indicates to the server that the
+   resolver is able to accept DNSSEC security RRs.  The DO bit cleared
+   (set to zero) indicates the resolver is unprepared to handle DNSSEC
+   security RRs and those RRs MUST NOT be returned in the response
+   (unless DNSSEC security RRs are explicitly queried for).  The DO bit
+   of the query MUST be copied in the response.
+
+   More explicitly, DNSSEC-aware nameservers MUST NOT insert SIG, KEY,
+   or NXT RRs to authenticate a response as specified in [RFC2535]
+   unless the DO bit was set on the request.  Security records that
+   match an explicit SIG, KEY, NXT, or ANY query, or are part of the
+   zone data for an AXFR or IXFR query, are included whether or not the
+   DO bit was set.
+
+   A recursive DNSSEC-aware server MUST set the DO bit on recursive
+   requests, regardless of the status of the DO bit on the initiating
+   resolver request.  If the initiating resolver request does not have
+   the DO bit set, the recursive DNSSEC-aware server MUST remove DNSSEC
+   security RRs before returning the data to the client, however cached
+   data MUST NOT be modified.
+
+   In the event a server returns a NOTIMP, FORMERR or SERVFAIL response
+   to a query that has the DO bit set, the resolver SHOULD NOT expect
+   DNSSEC security RRs and SHOULD retry the query without EDNS0 in
+   accordance with section 5.3 of [RFC2671].
+
+
+
+
+
+
+
+
+
+Conrad                      Standards Track                     [Page 3]
+
+RFC 3225         Indicating Resolver Support of DNSSEC     December 2001
+
+
+Security Considerations
+
+   The absence of DNSSEC data in response to a query with the DO bit set
+   MUST NOT be taken to mean no security information is available for
+   that zone as the response may be forged or a non-forged response of
+   an altered (DO bit cleared) query.
+
+IANA Considerations
+
+   EDNS0 [RFC2671] defines 16 bits as extended flags in the OPT record,
+   these bits are encoded into the TTL field of the OPT record (RFC2671
+   section 4.6).
+
+   This document reserves one of these bits as the OK bit.  It is
+   requested that the left most bit be allocated.  Thus the USE of the
+   OPT record TTL field would look like
+
+                +0 (MSB)                +1 (LSB)
+         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+      0: |   EXTENDED-RCODE      |       VERSION         |
+         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+      2: |DO|                    Z                       |
+         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+Acknowledgements
+
+   This document is based on a rough draft by Bob Halley with input from
+   Olafur Gudmundsson, Andreas Gustafsson, Brian Wellington, Randy Bush,
+   Rob Austein, Steve Bellovin, and Erik Nordmark.
+
+References
+
+   [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
+             STD 13, RFC 1034, November 1987.
+
+   [RFC1035] Mockapetris, P., "Domain Names - Implementation and
+             Specifications", STD 13, RFC 1035, November 1987.
+
+   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+             Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC
+             2535, March 1999.
+
+   [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
+             2671, August 1999.
+
+
+
+
+
+Conrad                      Standards Track                     [Page 4]
+
+RFC 3225         Indicating Resolver Support of DNSSEC     December 2001
+
+
+Author's Address
+
+   David Conrad
+   Nominum Inc.
+   950 Charter Street
+   Redwood City, CA 94063
+   USA
+
+   Phone: +1 650 381 6003
+   EMail: david.conrad@nominum.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Conrad                      Standards Track                     [Page 5]
+
+RFC 3225         Indicating Resolver Support of DNSSEC     December 2001
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2001).  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 Standards process must be
+   followed, or as required to translate it into 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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Conrad                      Standards Track                     [Page 6]
+
diff --git a/doc/rfc/rfc3226.txt b/doc/rfc/rfc3226.txt
new file mode 100644
index 0000000..dac0e11
--- /dev/null
+++ b/doc/rfc/rfc3226.txt
@@ -0,0 +1,339 @@
+
+
+
+
+
+
+Network Working Group                                     O. Gudmundsson
+Request for Comments: 3226                                 December 2001
+Updates: 2874, 2535
+Category: Standards Track
+
+
+   DNSSEC and IPv6 A6 aware server/resolver message size requirements
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2001).  All Rights Reserved.
+
+Abstract
+
+   This document mandates support for EDNS0 (Extension Mechanisms for
+   DNS) in DNS entities claiming to support either DNS Security
+   Extensions or A6 records.  This requirement is necessary because
+   these new features increase the size of DNS messages.  If EDNS0 is
+   not supported fall back to TCP will happen, having a detrimental
+   impact on query latency and DNS server load.  This document updates
+   RFC 2535 and RFC 2874, by adding new requirements.
+
+1.  Introduction
+
+   Familiarity with the DNS [RFC1034, RFC1035], DNS Security Extensions
+   [RFC2535], EDNS0 [RFC2671] and A6 [RFC2874] is helpful.
+
+   STD 13, RFC 1035 Section 2.3.4 requires that DNS messages over UDP
+   have a data payload of 512 octets or less.  Most DNS software today
+   will not accept larger UDP datagrams.  Any answer that requires more
+   than 512 octets, results in a partial and sometimes useless reply
+   with the Truncation Bit set; in most cases the requester will then
+   retry using TCP.  Furthermore, server delivery of truncated responses
+   varies widely and resolver handling of these responses also varies,
+   leading to additional inefficiencies in handling truncation.
+
+   Compared to UDP, TCP is an expensive protocol to use for a simple
+   transaction like DNS: a TCP connection requires 5 packets for setup
+   and tear down, excluding data packets, thus requiring at least 3
+   round trips on top of the one for the original UDP query.  The DNS
+
+
+
+Gudmundsson                 Standards Track                     [Page 1]
+
+RFC 3226            DNSSEC and IPv6 A6 requirements        December 2001
+
+
+   server also needs to keep a state of the connection during this
+   transaction.  Many DNS servers answer thousands of queries per
+   second, requiring them to use TCP will cause significant overhead and
+   delays.
+
+1.1.  Requirements
+
+   The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY"
+   in this document are to be interpreted as described in RFC 2119.
+
+2.  Motivating factors
+
+2.1.  DNSSEC motivations
+
+   DNSSEC [RFC2535] secures DNS by adding a Public Key signature on each
+   RR set.  These signatures range in size from about 80 octets to 800
+   octets, most are going to be in the range of 80 to 200 octets.  The
+   addition of signatures on each or most RR sets in an answer
+   significantly increases the size of DNS answers from secure zones.
+
+   For performance reasons and to reduce load on DNS servers, it is
+   important that security aware servers and resolvers get all the data
+   in Answer and Authority section in one query without truncation.
+   Sending Additional Data in the same query is helpful when the server
+   is authoritative for the data, and this reduces round trips.
+
+   DNSSEC OK[OK] specifies how a client can, using EDNS0, indicate that
+   it is interested in receiving DNSSEC records.  The OK bit does not
+   eliminate the need for large answers for DNSSEC capable clients.
+
+2.1.1.  Message authentication or TSIG motivation
+
+   TSIG [RFC2845] allows for the light weight authentication of DNS
+   messages, but increases the size of the messages by at least 70
+   octets.  DNSSEC specifies for computationally expensive message
+   authentication SIG(0) using a standard public key signature.  As only
+   one TSIG or SIG(0) can be attached to each DNS answer the size
+   increase of message authentication is not significant, but may still
+   lead to a truncation.
+
+2.2.  IPv6 Motivations
+
+   IPv6 addresses [RFC2874] are 128 bits and can be represented in the
+   DNS by multiple A6 records, each consisting of a domain name and a
+   bit field.  The domain name refers to an address prefix that may
+   require additional A6 RRs to be included in the answer.  Answers
+   where the queried name has multiple A6 addresses may overflow a 512-
+   octet UDP packet size.
+
+
+
+Gudmundsson                 Standards Track                     [Page 2]
+
+RFC 3226            DNSSEC and IPv6 A6 requirements        December 2001
+
+
+2.3.  Root server and TLD server motivations
+
+   The current number of root servers is limited to 13 as that is the
+   maximum number of name servers and their address records that fit in
+   one 512-octet answer for a SOA record.  If root servers start
+   advertising A6 or KEY records then the answer for the root NS records
+   will not fit in a single 512-octet DNS message, resulting in a large
+   number of TCP query connections to the root servers.  Even if all
+   client resolver query their local name server for information, there
+   are millions of these servers.  Each name server must periodically
+   update its information about the high level servers.
+
+   For redundancy, latency and load balancing reasons, large numbers of
+   DNS servers are required for some zones.  Since the root zone is used
+   by the entire net, it is important to have as many servers as
+   possible.  Large TLDs (and many high-visibility SLDs) often have
+   enough servers that either A6 or KEY records would cause the NS
+   response to overflow the 512 byte limit.  Note that these zones with
+   large numbers of servers are often exactly those zones that are
+   critical to network operation and that already sustain fairly high
+   loads.
+
+2.4.  UDP vs TCP for DNS messages
+
+   Given all these factors, it is essential that any implementation that
+   supports DNSSEC and or A6 be able to use larger DNS messages than 512
+   octets.
+
+   The original 512 restriction was put in place to reduce the
+   probability of fragmentation of DNS responses.  A fragmented UDP
+   message that suffers a loss of one of the fragments renders the
+   answer useless and the query must be retried.  A TCP connection
+   requires a larger number of round trips for establishment, data
+   transfer and tear down, but only the lost data segments are
+   retransmitted.
+
+   In the early days a number of IP implementations did not handle
+   fragmentation well, but all modern operating systems have overcome
+   that issue thus sending fragmented messages is fine from that
+   standpoint.  The open issue is the effect of losses on fragmented
+   messages.  If connection has high loss ratio only TCP will allow
+   reliable transfer of DNS data, most links have low loss ratios thus
+   sending fragmented UDP packet in one round trip is better than
+   establishing a TCP connection to transfer a few thousand octets.
+
+
+
+
+
+
+
+Gudmundsson                 Standards Track                     [Page 3]
+
+RFC 3226            DNSSEC and IPv6 A6 requirements        December 2001
+
+
+2.5.  EDNS0 and large UDP messages
+
+   EDNS0 [RFC2671] allows clients to declare the maximum size of UDP
+   message they are willing to handle.  Thus, if the expected answer is
+   between 512 octets and the maximum size that the client can accept,
+   the additional overhead of a TCP connection can be avoided.
+
+3.  Protocol changes:
+
+   This document updates RFC 2535 and RFC 2874, by adding new
+   requirements.
+
+   All RFC 2535 compliant servers and resolvers MUST support EDNS0 and
+   advertise message size of at least 1220 octets, but SHOULD advertise
+   message size of 4000.  This value might be too low to get full
+   answers for high level servers and successor of this document may
+   require a larger value.
+
+   All RFC 2874 compliant servers and resolver MUST support EDNS0 and
+   advertise message size of at least 1024 octets, but SHOULD advertise
+   message size of 2048.  The IPv6 datagrams should be 1024 octets,
+   unless the MTU of the path is known.  (Note that this is smaller than
+   the minimum IPv6 MTU to allow for some extension headers and/or
+   encapsulation without exceeding the minimum MTU.)
+
+   All RFC 2535 and RFC 2874 compliant entities MUST be able to handle
+   fragmented IPv4 and IPv6 UDP packets.
+
+   All hosts supporting both RFC 2535 and RFC 2874 MUST use the larger
+   required value in EDNS0 advertisements.
+
+4.  Acknowledgments
+
+   Harald Alvestrand, Rob Austein, Randy Bush, David Conrad, Andreas
+   Gustafsson, Jun-ichiro itojun Hagino, Bob Halley, Edward Lewis
+   Michael Patton and Kazu Yamamoto were instrumental in motivating and
+   shaping this document.
+
+5.  Security Considerations:
+
+   There are no additional security considerations other than those in
+   RFC 2671.
+
+6.  IANA Considerations:
+
+   None
+
+
+
+
+
+Gudmundsson                 Standards Track                     [Page 4]
+
+RFC 3226            DNSSEC and IPv6 A6 requirements        December 2001
+
+
+7.  References
+
+   [RFC1034]  Mockapetris, P., "Domain Names - Concepts and Facilities",
+              STD 13, RFC 1034, November 1987.
+
+   [RFC1035]  Mockapetris, P., "Domain Names - Implementation and
+              Specification", STD 13, RFC 1035, November 1987.
+
+   [RFC2535]  Eastlake, D. "Domain Name System Security Extensions", RFC
+              2535, March 1999.
+
+   [RFC2671]  Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
+              2671, August 1999.
+
+   [RFC2845]  Vixie, P., Gudmundsson, O., Eastlake, D. and B.
+              Wellington, "Secret Key Transaction Authentication for DNS
+              (TSIG)", RFC 2845, May 2000.
+
+   [RFC2874]  Crawford, M. and C. Huitema, "DNS Extensions to Support
+              IPv6 Address Aggregation and Renumbering", RFC 2874, July
+              2000.
+
+   [RFC3225]  Conrad, D., "Indicating Resolver Support of DNSSEC", RFC
+              3225, December 2001.
+
+8.  Author Address
+
+   Olafur Gudmundsson
+   3826 Legation Street, NW
+   Washington, DC 20015
+   USA
+
+   EMail: ogud@ogud.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gudmundsson                 Standards Track                     [Page 5]
+
+RFC 3226            DNSSEC and IPv6 A6 requirements        December 2001
+
+
+9.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2001).  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 Standards process must be
+   followed, or as required to translate it into 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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gudmundsson                 Standards Track                     [Page 6]
+
diff --git a/doc/rfc/rfc3258.txt b/doc/rfc/rfc3258.txt
new file mode 100644
index 0000000..dcd4b34
--- /dev/null
+++ b/doc/rfc/rfc3258.txt
@@ -0,0 +1,619 @@
+
+
+
+
+
+
+Network Working Group                                          T. Hardie
+Request for Comments: 3258                                 Nominum, Inc.
+Category: Informational                                       April 2002
+
+
+  Distributing Authoritative Name Servers via Shared Unicast Addresses
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2002).  All Rights Reserved.
+
+Abstract
+
+   This memo describes a set of practices intended to enable an
+   authoritative name server operator to provide access to a single
+   named server in multiple locations.  The primary motivation for the
+   development and deployment of these practices is to increase the
+   distribution of Domain Name System (DNS) servers to previously
+   under-served areas of the network topology and to reduce the latency
+   for DNS  query responses in those areas.
+
+1.  Introduction
+
+   This memo describes a set of practices intended to enable an
+   authoritative name server operator to provide access to a single
+   named server in multiple locations.  The primary motivation for the
+   development and deployment of these practices is to increase the
+   distribution of DNS servers to previously under-served areas of the
+   network topology and to reduce the latency for DNS query responses in
+   those areas.  This document presumes a one-to-one mapping between
+   named authoritative servers and administrative entities (operators).
+   This document contains no guidelines or recommendations for caching
+   name servers.  The shared unicast system described here is specific
+   to IPv4; applicability to IPv6 is an area for further study.  It
+   should also be noted that the system described here is related to
+   that described in [ANYCAST], but it does not require dedicated
+   address space, routing changes, or the other elements of a full
+   anycast infrastructure which that document describes.
+
+
+
+
+
+
+
+Hardie                       Informational                      [Page 1]
+
+RFC 3258        Distributing Authoritative Name Servers       April 2002
+
+
+2.  Architecture
+
+2.1 Server Requirements
+
+   Operators of authoritative name servers may wish to refer to
+   [SECONDARY] and [ROOT] for general guidance on appropriate practice
+   for authoritative name servers.  In addition to proper configuration
+   as a standard authoritative name server, each of the hosts
+   participating in a shared-unicast system should be configured with
+   two network interfaces.  These interfaces may be either two physical
+   interfaces or one physical interface mapped to two logical
+   interfaces.  One of the network interfaces should use the IPv4 shared
+   unicast address associated with the authoritative name server.  The
+   other interface, referred to as the administrative interface below,
+   should use a distinct IPv4 address specific to that host.  The host
+   should respond to DNS queries only on the shared-unicast interface.
+   In order to provide the most consistent set of responses from the
+   mesh of anycast hosts, it is good practice to limit responses on that
+   interface to zones for which the host is authoritative.
+
+2.2 Zone file delivery
+
+   In order to minimize the risk of man-in-the-middle attacks, zone
+   files should be delivered to the administrative interface of the
+   servers participating in the mesh.  Secure file transfer methods and
+   strong authentication should be used for all transfers.  If the hosts
+   in the mesh make their zones available for zone transfer, the
+   administrative interfaces should be used for those transfers as well,
+   in order to avoid the problems with potential routing changes for TCP
+   traffic noted in section 2.5 below.
+
+2.3 Synchronization
+
+   Authoritative name servers may be loosely or tightly synchronized,
+   depending on the practices set by the operating organization.  As
+   noted below in section 4.1.2, lack of synchronization among servers
+   using the same shared unicast address could create problems for some
+   users of this service.  In order to minimize that risk, switch-overs
+   from one data set to another data set should be coordinated as much
+   as possible.  The use of synchronized clocks on the participating
+   hosts and set times for switch-overs provides a basic level of
+   coordination.  A more complete coordination process would involve:
+
+      a) receipt of zones at a distribution host
+      b) confirmation of the integrity of zones received
+      c) distribution of the zones to all of the servers in the mesh
+      d) confirmation of the integrity of the zones at each server
+
+
+
+
+Hardie                       Informational                      [Page 2]
+
+RFC 3258        Distributing Authoritative Name Servers       April 2002
+
+
+      e) coordination of the switchover times for the servers in the
+         mesh
+      f) institution of a failure process to ensure that servers that
+         did not receive correct data or could not switchover to the new
+         data ceased to respond to incoming queries until the problem
+         could be resolved.
+
+   Depending on the size of the mesh, the distribution host may also be
+   a participant; for authoritative servers, it may also be the host on
+   which zones are generated.
+
+   This document presumes that the usual DNS failover methods are the
+   only ones used to ensure reachability of the data for clients.  It
+   does not advise that the routes be withdrawn in the case of failure;
+   it advises instead that the DNS process shutdown so that servers on
+   other addresses are queried.  This recommendation reflects a choice
+   between performance and operational complexity.  While it would be
+   possible to have some process withdraw the route for a specific
+   server instance when it is not available, there is considerable
+   operational complexity involved in ensuring that this occurs
+   reliably.  Given the existing DNS failover methods, the marginal
+   improvement in performance will not be sufficient to justify the
+   additional complexity for most uses.
+
+2.4 Server Placement
+
+   Though the geographic diversity of server placement helps reduce the
+   effects of service disruptions due to local problems, it is diversity
+   of placement in the network topology which is the driving force
+   behind these distribution practices.  Server placement should
+   emphasize that diversity.  Ideally, servers should be placed
+   topologically near the points at which the operator exchanges routes
+   and traffic with other networks.
+
+2.5 Routing
+
+   The organization administering the mesh of servers sharing a unicast
+   address must have an autonomous system number and speak BGP to its
+   peers.  To those peers, the organization announces a route to the
+   network containing the shared-unicast address of the name server.
+   The organization's border routers must then deliver the traffic
+   destined for the name server to the nearest instantiation.  Routing
+   to the administrative interfaces for the servers can use the normal
+   routing methods for the administering organization.
+
+   One potential problem with using shared unicast addresses is that
+   routers forwarding traffic to them may have more than one available
+   route, and those routes may, in fact, reach different instances of
+
+
+
+Hardie                       Informational                      [Page 3]
+
+RFC 3258        Distributing Authoritative Name Servers       April 2002
+
+
+   the shared unicast address.  Applications like the DNS, whose
+   communication typically consists of independent request-response
+   messages each fitting in a single UDP packet present no problem.
+   Other applications, in which multiple packets must reach the same
+   endpoint (e.g., TCP) may fail or present unworkable performance
+   characteristics in some circumstances.  Split-destination failures
+   may occur when a router does per-packet (or round-robin) load
+   sharing, a topology change occurs that changes the relative metrics
+   of two paths to the same anycast destination, etc.
+
+   Four things mitigate the severity of this problem.  The first is that
+   UDP is a fairly high proportion of the query traffic to name servers.
+   The second is that the aim of this proposal is to diversify
+   topological placement; for most users, this means that the
+   coordination of placement will ensure that new instances of a name
+   server will be at a significantly different cost metric from existing
+   instances.  Some set of users may end up in the middle, but that
+   should be relatively rare.  The third is that per packet load sharing
+   is only one of the possible load sharing mechanisms, and other
+   mechanisms are increasing in popularity.
+
+   Lastly, in the case where the traffic is TCP, per packet load sharing
+   is used, and equal cost routes to different instances of a name
+   server are available, any DNS implementation which measures the
+   performance of servers to select a preferred server will quickly
+   prefer a server for which this problem does not occur.  For the DNS
+   failover mechanisms to reliably avoid this problem, however, those
+   using shared unicast distribution mechanisms must take care that all
+   of the servers for a specific zone are not participants in the same
+   shared-unicast mesh.  To guard even against the case where multiple
+   meshes have a set of users affected by per packet load sharing along
+   equal cost routes, organizations implementing these practices should
+   always provide at least one authoritative server which is not a
+   participant in any shared unicast mesh.  Those deploying shared-
+   unicast meshes should note that any specific host may become
+   unreachable to a client should a server fail, a path fail, or the
+   route to that host be withdrawn.  These error conditions are,
+   however, not specific to shared-unicast distributions, but would
+   occur for standard unicast hosts.
+
+   Since ICMP response packets might go to a different member of the
+   mesh than that sending a packet, packets sent with a shared unicast
+   source address should also avoid using path MTU discovery.
+
+   Appendix A. contains an ASCII diagram of an example of a simple
+   implementation of this system.  In it, the odd numbered routers
+   deliver traffic to the shared-unicast interface network and filter
+   traffic from the administrative network; the even numbered routers
+
+
+
+Hardie                       Informational                      [Page 4]
+
+RFC 3258        Distributing Authoritative Name Servers       April 2002
+
+
+   deliver traffic to the administrative network and filter traffic from
+   the shared-unicast network.  These are depicted as separate routers
+   for the ease this gives in explanation, but they could easily be
+   separate interfaces on the same router.  Similarly, a local NTP
+   source is depicted for synchronization, but the level of
+   synchronization needed would not require that source to be either
+   local or a stratum one NTP server.
+
+3. Administration
+
+3.1 Points of Contact
+
+   A single point of contact for reporting problems is crucial to the
+   correct administration of this system.  If an external user of the
+   system needs to report a problem related to the service, there must
+   be no ambiguity about whom to contact.  If internal monitoring does
+   not indicate a problem, the contact may, of course, need to work with
+   the external user to identify which server generated the error.
+
+4. Security Considerations
+
+   As a core piece of Internet infrastructure, authoritative name
+   servers are common targets of attack.  The practices outlined here
+   increase the risk of certain kinds of attacks and reduce the risk of
+   others.
+
+4.1 Increased Risks
+
+4.1.1 Increase in physical servers
+
+   The architecture outlined in this document increases the number of
+   physical servers, which could increase the possibility that a server
+   mis-configuration will occur which allows for a security breach.  In
+   general, the entity administering a mesh should ensure that patches
+   and security mechanisms applied to a single member of the mesh are
+   appropriate for and applied to all of the members of a mesh.
+   "Genetic diversity" (code from different code bases) can be a useful
+   security measure in avoiding attacks based on vulnerabilities in a
+   specific code base; in order to ensure consistency of responses from
+   a single named server, however, that diversity should be applied to
+   different shared-unicast meshes or between a mesh and a related
+   unicast authoritative server.
+
+4.1.2 Data synchronization problems
+
+   The level of systemic synchronization described above should be
+   augmented by synchronization of the data present at each of the
+   servers.  While the DNS itself is a loosely coupled system, debugging
+
+
+
+Hardie                       Informational                      [Page 5]
+
+RFC 3258        Distributing Authoritative Name Servers       April 2002
+
+
+   problems with data in specific zones would be far more difficult if
+   two different servers sharing a single unicast address might return
+   different responses to the same query.  For example, if the data
+   associated with www.example.com has changed and the administrators of
+   the domain are testing for the changes at the example.com
+   authoritative name servers, they should not need to check each
+   instance of a named authoritative server.  The use of NTP to provide
+   a synchronized time for switch-over eliminates some aspects of this
+   problem, but mechanisms to handle failure during the switchover are
+   required.  In particular, a server which cannot make the switchover
+   must not roll-back to a previous version; it must cease to respond to
+   queries so that other servers are queried.
+
+4.1.3 Distribution risks
+
+   If the mechanism used to distribute zone files among the servers is
+   not well secured, a man-in-the-middle attack could result in the
+   injection of false information.  Digital signatures will alleviate
+   this risk, but encrypted transport and tight access lists are a
+   necessary adjunct to them.  Since zone files will be distributed to
+   the administrative interfaces of meshed servers, the access control
+   list for distribution of the zone files should include the
+   administrative interface of the server or servers, rather than their
+   shared unicast addresses.
+
+4.2 Decreased Risks
+
+   The increase in number of physical servers reduces the likelihood
+   that a denial-of-service attack will take out a significant portion
+   of the DNS infrastructure.  The increase in servers also reduces the
+   effect of machine crashes, fiber cuts, and localized disasters by
+   reducing the number of users dependent on a specific machine.
+
+5. Acknowledgments
+
+   Masataka Ohta, Bill Manning, Randy Bush, Chris Yarnell, Ray Plzak,
+   Mark Andrews, Robert Elz, Geoff Huston, Bill Norton, Akira Kato,
+   Suzanne Woolf, Bernard Aboba, Casey Ajalat, and Gunnar Lindberg all
+   provided input and commentary on this work.  The editor wishes to
+   remember in particular the contribution of the late Scott Tucker,
+   whose extensive systems experience and plain common sense both
+   contributed greatly to the editor's own deployment experience and are
+   missed by all who knew him.
+
+
+
+
+
+
+
+
+Hardie                       Informational                      [Page 6]
+
+RFC 3258        Distributing Authoritative Name Servers       April 2002
+
+
+6. References
+
+   [SECONDARY] Elz, R., Bush, R., Bradner, S. and M. Patton, "Selection
+               and Operation of Secondary DNS Servers", BCP 16, RFC
+               2182, July 1997.
+
+   [ROOT]      Bush, R., Karrenberg, D., Kosters, M. and R. Plzak, "Root
+               Name Server Operational Requirements", BCP 40, RFC 2870,
+               June 2000.
+
+   [ANYCAST]   Patridge, C., Mendez, T. and W. Milliken, "Host
+               Anycasting Service", RFC 1546, November 1993.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hardie                       Informational                      [Page 7]
+
+RFC 3258        Distributing Authoritative Name Servers       April 2002
+
+
+Appendix A.
+
+       __________________
+Peer 1-|                |
+Peer 2-|                |
+Peer 3-|     Switch     |
+Transit|                |  _________                   _________
+etc    |                |--|Router1|---|----|----------|Router2|---WAN-|
+       |                |  ---------   |    |          ---------       |
+       |                |              |    |                          |
+       |                |              |    |                          |
+       ------------------            [NTP] [DNS]                       |
+                                                                       |
+                                                                       |
+                                                                       |
+                                                                       |
+       __________________                                              |
+Peer 1-|                |                                              |
+Peer 2-|                |                                              |
+Peer 3-|     Switch     |                                              |
+Transit|                |  _________                   _________       |
+etc    |                |--|Router3|---|----|----------|Router4|---WAN-|
+       |                |  ---------   |    |          ---------       |
+       |                |              |    |                          |
+       |                |              |    |                          |
+       ------------------            [NTP] [DNS]                       |
+                                                                       |
+                                                                       |
+                                                                       |
+                                                                       |
+       __________________                                              |
+Peer 1-|                |                                              |
+Peer 2-|                |                                              |
+Peer 3-|     Switch     |                                              |
+Transit|                |  _________                   _________       |
+etc    |                |--|Router5|---|----|----------|Router6|---WAN-|
+       |                |  ---------   |    |          ---------       |
+       |                |              |    |                          |
+       |                |              |    |                          |
+       ------------------            [NTP] [DNS]                       |
+                                                                       |
+                                                                       |
+                                                                       |
+
+
+
+
+
+
+
+
+Hardie                       Informational                      [Page 8]
+
+RFC 3258        Distributing Authoritative Name Servers       April 2002
+
+
+                                                                       |
+       __________________                                              |
+Peer 1-|                |                                              |
+Peer 2-|                |                                              |
+Peer 3-|     Switch     |                                              |
+Transit|                |  _________                   _________       |
+etc    |                |--|Router7|---|----|----------|Router8|---WAN-|
+       |                |  ---------   |    |          ---------
+       |                |              |    |
+       |                |              |    |
+       ------------------            [NTP] [DNS]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hardie                       Informational                      [Page 9]
+
+RFC 3258        Distributing Authoritative Name Servers       April 2002
+
+
+7. Editor's Address
+
+   Ted Hardie
+   Nominum, Inc.
+   2385 Bay Road.
+   Redwood City, CA 94063
+
+   Phone: 1.650.381.6226
+   EMail: Ted.Hardie@nominum.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hardie                       Informational                     [Page 10]
+
+RFC 3258        Distributing Authoritative Name Servers       April 2002
+
+
+8.  Full Copyright Statement
+
+   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 Standards process must be
+   followed, or as required to translate it into 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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hardie                       Informational                     [Page 11]
+
diff --git a/doc/rfc/rfc3363.txt b/doc/rfc/rfc3363.txt
new file mode 100644
index 0000000..9d7a39c
--- /dev/null
+++ b/doc/rfc/rfc3363.txt
@@ -0,0 +1,339 @@
+
+
+
+
+
+
+Network Working Group                                            R. Bush
+Request for Comments: 3363                                     A. Durand
+Updates: 2673, 2874                                              B. Fink
+Category: Informational                                   O. Gudmundsson
+                                                                 T. Hain
+                                                                 Editors
+                                                             August 2002
+
+
+            Representing Internet Protocol version 6 (IPv6)
+               Addresses in the Domain Name System (DNS)
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2002).  All Rights Reserved.
+
+Abstract
+
+   This document clarifies and updates the standards status of RFCs that
+   define direct and reverse map of IPv6 addresses in DNS.  This
+   document moves the A6 and Bit label specifications to experimental
+   status.
+
+1.  Introduction
+
+   The IETF had begun the process of standardizing two different address
+   formats for IPv6 addresses AAAA [RFC1886] and A6 [RFC2874] and both
+   are at proposed standard.  This had led to confusion and conflicts on
+   which one to deploy.  It is important for deployment that any
+   confusion in this area be cleared up, as there is a feeling in the
+   community that having more than one choice will lead to delays in the
+   deployment of IPv6.  The goal of this document is to clarify the
+   situation.
+
+   This document also discusses issues relating to the usage of Binary
+   Labels [RFC 2673] to support the reverse mapping of IPv6 addresses.
+
+   This document is based on extensive technical discussion on various
+   relevant working groups mailing lists and a joint DNSEXT and NGTRANS
+   meeting at the 51st IETF in August 2001.  This document attempts to
+   capture the sense of the discussions and reflect them in this
+   document to represent the consensus of the community.
+
+
+
+Bush, et. al.                Informational                      [Page 1]
+
+RFC 3363        Representation of IPv6 Addresses in DNS      August 2002
+
+
+   The main arguments and the issues are covered in a separate document
+   [RFC3364] that reflects the current understanding of the issues.
+   This document summarizes the outcome of these discussions.
+
+   The issue of the root of reverse IPv6 address map is outside the
+   scope of this document and is covered in a different document
+   [RFC3152].
+
+1.1 Standards Action Taken
+
+   This document changes the status of RFCs 2673 and 2874 from Proposed
+   Standard to Experimental.
+
+2.  IPv6 Addresses: AAAA RR vs A6 RR
+
+   Working group consensus as perceived by the chairs of the DNSEXT and
+   NGTRANS working groups is that:
+
+   a) AAAA records are preferable at the moment for production
+      deployment of IPv6, and
+
+   b) that A6 records have interesting properties that need to be better
+      understood before deployment.
+
+   c) It is not known if the benefits of A6 outweigh the costs and
+      risks.
+
+2.1 Rationale
+
+   There are several potential issues with A6 RRs that stem directly
+   from the feature that makes them different from AAAA RRs: the ability
+   to build up addresses via chaining.
+
+   Resolving a chain of A6 RRs involves resolving a series of what are
+   nearly-independent queries.  Each of these sub-queries takes some
+   non-zero amount of time, unless the answer happens to be in the
+   resolver's local cache already.  Other things being equal, we expect
+   that the time it takes to resolve an N-link chain of A6 RRs will be
+   roughly proportional to N.  What data we have suggests that users are
+   already impatient with the length of time it takes to resolve A RRs
+   in the IPv4 Internet, which suggests that users are not likely to be
+   patient with significantly longer delays in the IPv6 Internet, but
+   terminating queries prematurely is both a waste of resources and
+   another source of user frustration.  Thus, we are forced to conclude
+   that indiscriminate use of long A6 chains is likely to lead to
+   increased user frustration.
+
+
+
+
+
+Bush, et. al.                Informational                      [Page 2]
+
+RFC 3363        Representation of IPv6 Addresses in DNS      August 2002
+
+
+   The probability of failure during the process of resolving an N-link
+   A6 chain also appears to be roughly proportional to N, since each of
+   the queries involved in resolving an A6 chain has roughly the same
+   probability of failure as a single AAAA query.
+
+   Last, several of the most interesting potential applications for A6
+   RRs involve situations where the prefix name field in the A6 RR
+   points to a target that is not only outside the DNS zone containing
+   the A6 RR, but is administered by a different organization entirely.
+   While pointers out of zone are not a problem per se, experience both
+   with glue RRs and with PTR RRs in the IN-ADDR.ARPA tree suggests that
+   pointers to other organizations are often not maintained properly,
+   perhaps because they're less susceptible to automation than pointers
+   within a single organization would be.
+
+2.2 Recommended Standard Action
+
+   Based on the perceived consensus, this document recommends that RFC
+   1886 stay on standards track and be advanced, while moving RFC 2874
+   to Experimental status.
+
+3.  Bitlabels in the Reverse DNS Tree
+
+   RFC 2673 defines a new DNS label type.  This was the first new type
+   defined since RFC 1035 [RFC1035].  Since the development of 2673 it
+   has been learned that deployment of a new type is difficult since DNS
+   servers that do not support bitlabels reject queries containing bit
+   labels as being malformed.  The community has also indicated that
+   this new label type is not needed for mapping reverse addresses.
+
+3.1 Rationale
+
+   The hexadecimal text representation of IPv6 addresses appears to be
+   capable of expressing all of the delegation schemes that we expect to
+   be used in the DNS reverse tree.
+
+3.2 Recommended Standard Action
+
+   RFC 2673 standard status is to be changed from Proposed to
+   Experimental.  Future standardization of these documents is to be
+   done by the DNSEXT working group or its successor.
+
+
+
+
+
+
+
+
+
+
+Bush, et. al.                Informational                      [Page 3]
+
+RFC 3363        Representation of IPv6 Addresses in DNS      August 2002
+
+
+4.  DNAME in IPv6 Reverse Tree
+
+   The issues for DNAME in the reverse mapping tree appears to be
+   closely tied to the need to use fragmented A6 in the main tree: if
+   one is necessary, so is the other, and if one isn't necessary, the
+   other isn't either.  Therefore, in moving RFC 2874 to experimental,
+   the intent of this document is that use of DNAME RRs in the reverse
+   tree be deprecated.
+
+5.  Acknowledgments
+
+   This document is based on input from many members of the various IETF
+   working groups involved in this issues.  Special thanks go to the
+   people that prepared reading material for the joint DNSEXT and
+   NGTRANS working group meeting at the 51st IETF in London, Rob
+   Austein, Dan Bernstein, Matt Crawford, Jun-ichiro itojun Hagino,
+   Christian Huitema.  Number of other people have made number of
+   comments on mailing lists about this issue including Andrew W.
+   Barclay, Robert Elz, Johan Ihren, Edward Lewis, Bill Manning, Pekka
+   Savola, Paul Vixie.
+
+6.  Security Considerations
+
+   As this document specifies a course of action, there are no direct
+   security considerations.  There is an indirect security impact of the
+   choice, in that the relationship between A6 and DNSSEC is not well
+   understood throughout the community, while the choice of AAAA does
+   leads to a model for use of DNSSEC in IPv6 networks which parallels
+   current IPv4 practice.
+
+7.  IANA Considerations
+
+   None.
+
+Normative References
+
+   [RFC1035]  Mockapetris, P., "Domain Names - Implementation and
+              Specification", STD 13, RFC 1035, November 1987.
+
+   [RFC1886]  Thompson, S. and C. Huitema, "DNS Extensions to support IP
+              version 6", RFC 1886, December 1995.
+
+   [RFC2673]  Crawford, M., "Binary Labels in the Domain Name System",
+              RFC 2673, August 1999.
+
+   [RFC2874]  Crawford, M. and C. Huitema, "DNS Extensions to Support
+              IPv6 Address Aggregation and Renumbering", RFC 2874, July
+              2000.
+
+
+
+Bush, et. al.                Informational                      [Page 4]
+
+RFC 3363        Representation of IPv6 Addresses in DNS      August 2002
+
+
+   [RFC3152]  Bush, R., "Delegation of IP6.ARPA", BCP 49, RFC 3152
+              August 2001.
+
+Informative References
+
+   [RFC3364]  Austein, R., "Tradeoffs in Domain Name System (DNS)
+              Support for Internet Protocol version 6 (IPv6)", RFC 3364,
+              August 2002.
+
+Editors' Addresses
+
+   Randy Bush
+   EMail: randy@psg.com
+
+
+   Alain Durand
+   EMail: alain.durand@sun.com
+
+
+   Bob Fink
+   EMail: fink@es.net
+
+
+   Olafur Gudmundsson
+   EMail: ogud@ogud.com
+
+
+   Tony Hain
+   EMail: hain@tndh.net
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bush, et. al.                Informational                      [Page 5]
+
+RFC 3363        Representation of IPv6 Addresses in DNS      August 2002
+
+
+Full Copyright Statement
+
+   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 Standards process must be
+   followed, or as required to translate it into 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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bush, et. al.                Informational                      [Page 6]
+
diff --git a/doc/rfc/rfc3364.txt b/doc/rfc/rfc3364.txt
new file mode 100644
index 0000000..189c0d2
--- /dev/null
+++ b/doc/rfc/rfc3364.txt
@@ -0,0 +1,619 @@
+
+
+
+
+
+
+Network Working Group                                         R. Austein
+Request for Comments: 3364                           Bourgeois Dilettant
+Updates: 2673, 2874                                          August 2002
+Category: Informational
+
+
+             Tradeoffs in Domain Name System (DNS) Support
+                 for Internet Protocol version 6 (IPv6)
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2002).  All Rights Reserved.
+
+Abstract
+
+   The IETF has two different proposals on the table for how to do DNS
+   support for IPv6, and has thus far failed to reach a clear consensus
+   on which approach is better.  This note attempts to examine the pros
+   and cons of each approach, in the hope of clarifying the debate so
+   that we can reach closure and move on.
+
+Introduction
+
+   RFC 1886 [RFC1886] specified straightforward mechanisms to support
+   IPv6 addresses in the DNS.  These mechanisms closely resemble the
+   mechanisms used to support IPv4, with a minor improvement to the
+   reverse mapping mechanism based on experience with CIDR.  RFC 1886 is
+   currently listed as a Proposed Standard.
+
+   RFC 2874 [RFC2874] specified enhanced mechanisms to support IPv6
+   addresses in the DNS.  These mechanisms provide new features that
+   make it possible for an IPv6 address stored in the DNS to be broken
+   up into multiple DNS resource records in ways that can reflect the
+   network topology underlying the address, thus making it possible for
+   the data stored in the DNS to reflect certain kinds of network
+   topology changes or routing architectures that are either impossible
+   or more difficult to represent without these mechanisms.  RFC 2874 is
+   also currently listed as a Proposed Standard.
+
+
+
+
+
+
+
+Austein                      Informational                      [Page 1]
+
+RFC 3364           Tradeoffs in DNS Support for IPv6         August 2002
+
+
+   Both of these Proposed Standards were the output of the IPNG Working
+   Group.  Both have been implemented, although implementation of
+   [RFC1886] is more widespread, both because it was specified earlier
+   and because it's simpler to implement.
+
+   There's little question that the mechanisms proposed in [RFC2874] are
+   more general than the mechanisms proposed in [RFC1886], and that
+   these enhanced mechanisms might be valuable if IPv6's evolution goes
+   in certain directions.  The questions are whether we really need the
+   more general mechanism, what new usage problems might come along with
+   the enhanced mechanisms, and what effect all this will have on IPv6
+   deployment.
+
+   The one thing on which there does seem to be widespread agreement is
+   that we should make up our minds about all this Real Soon Now.
+
+Main Advantages of Going with A6
+
+   While the A6 RR proposed in [RFC2874] is very general and provides a
+   superset of the functionality provided by the AAAA RR in [RFC1886],
+   many of the features of A6 can also be implemented with AAAA RRs via
+   preprocessing during zone file generation.
+
+   There is one specific area where A6 RRs provide something that cannot
+   be provided using AAAA RRs: A6 RRs can represent addresses in which a
+   prefix portion of the address can change without any action (or
+   perhaps even knowledge) by the parties controlling the DNS zone
+   containing the terminal portion (least significant bits) of the
+   address.  This includes both so-called "rapid renumbering" scenarios
+   (where an entire network's prefix may change very quickly) and
+   routing architectures such as the former "GSE" proposal [GSE] (where
+   the "routing goop" portion of an address may be subject to change
+   without warning).  A6 RRs do not completely remove the need to update
+   leaf zones during all renumbering events (for example, changing ISPs
+   would usually require a change to the upward delegation pointer), but
+   careful use of A6 RRs could keep the number of RRs that need to
+   change during such an event to a minimum.
+
+   Note that constructing AAAA RRs via preprocessing during zone file
+   generation requires exactly the sort of information that A6 RRs store
+   in the DNS.  This begs the question of where the hypothetical
+   preprocessor obtains that information if it's not getting it from the
+   DNS.
+
+   Note also that the A6 RR, when restricted to its zero-length-prefix
+   form ("A6 0"), is semantically equivalent to an AAAA RR (with one
+   "wasted" octet in the wire representation), so anything that can be
+   done with an AAAA RR can also be done with an A6 RR.
+
+
+
+Austein                      Informational                      [Page 2]
+
+RFC 3364           Tradeoffs in DNS Support for IPv6         August 2002
+
+
+Main Advantages of Going with AAAA
+
+   The AAAA RR proposed in [RFC1886], while providing only a subset of
+   the functionality provided by the A6 RR proposed in [RFC2874], has
+   two main points to recommend it:
+
+   - AAAA RRs are essentially identical (other than their length) to
+     IPv4's A RRs, so we have more than 15 years of experience to help
+     us predict the usage patterns, failure scenarios and so forth
+     associated with AAAA RRs.
+
+   - The AAAA RR is "optimized for read", in the sense that, by storing
+     a complete address rather than making the resolver fetch the
+     address in pieces, it minimizes the effort involved in fetching
+     addresses from the DNS (at the expense of increasing the effort
+     involved in injecting new data into the DNS).
+
+Less Compelling Arguments in Favor of A6
+
+   Since the A6 RR allows a zone administrator to write zone files whose
+   description of addresses maps to the underlying network topology, A6
+   RRs can be construed as a "better" way of representing addresses than
+   AAAA.  This may well be a useful capability, but in and of itself
+   it's more of an argument for better tools for zone administrators to
+   use when constructing zone files than a justification for changing
+   the resolution protocol used on the wire.
+
+Less Compelling Arguments in Favor of AAAA
+
+   Some of the pressure to go with AAAA instead of A6 appears to be
+   based on the wider deployment of AAAA.  Since it is possible to
+   construct transition tools (see discussion of AAAA synthesis, later
+   in this note), this does not appear to be a compelling argument if A6
+   provides features that we really need.
+
+   Another argument in favor of AAAA RRs over A6 RRs appears to be that
+   the A6 RR's advanced capabilities increase the number of ways in
+   which a zone administrator could build a non-working configuration.
+   While operational issues are certainly important, this is more of
+   argument that we need better tools for zone administrators than it is
+   a justification for turning away from A6 if A6 provides features that
+   we really need.
+
+
+
+
+
+
+
+
+
+Austein                      Informational                      [Page 3]
+
+RFC 3364           Tradeoffs in DNS Support for IPv6         August 2002
+
+
+Potential Problems with A6
+
+   The enhanced capabilities of the A6 RR, while interesting, are not in
+   themselves justification for choosing A6 if we don't really need
+   those capabilities.  The A6 RR is "optimized for write", in the sense
+   that, by making it possible to store fragmented IPv6 addresses in the
+   DNS, it makes it possible to reduce the effort that it takes to
+   inject new data into the DNS (at the expense of increasing the effort
+   involved in fetching data from the DNS).  This may be justified if we
+   expect the effort involved in maintaining AAAA-style DNS entries to
+   be prohibitive, but in general, we expect the DNS data to be read
+   more frequently than it is written, so we need to evaluate this
+   particular tradeoff very carefully.
+
+   There are also several potential issues with A6 RRs that stem
+   directly from the feature that makes them different from AAAA RRs:
+   the ability to build up address via chaining.
+
+   Resolving a chain of A6 RRs involves resolving a series of what are
+   almost independent queries, but not quite.  Each of these sub-queries
+   takes some non-zero amount of time, unless the answer happens to be
+   in the resolver's local cache already.  Assuming that resolving an
+   AAAA RR takes time T as a baseline, we can guess that, on the
+   average, it will take something approaching time N*T to resolve an
+   N-link chain of A6 RRs, although we would expect to see a fairly good
+   caching factor for the A6 fragments representing the more significant
+   bits of an address.  This leaves us with two choices, neither of
+   which is very good:  we can decrease the amount of time that the
+   resolver is willing to wait for each fragment, or we can increase the
+   amount of time that a resolver is willing to wait before returning
+   failure to a client.  What little data we have on this subject
+   suggests that users are already impatient with the length of time it
+   takes to resolve A RRs in the IPv4 Internet, which suggests that they
+   are not likely to be patient with significantly longer delays in the
+   IPv6 Internet.  At the same time, terminating queries prematurely is
+   both a waste of resources and another source of user frustration.
+   Thus, we are forced to conclude that indiscriminate use of long A6
+   chains is likely to lead to problems.
+
+   To make matters worse, the places where A6 RRs are likely to be most
+   critical for rapid renumbering or GSE-like routing are situations
+   where the prefix name field in the A6 RR points to a target that is
+   not only outside the DNS zone containing the A6 RR, but is
+   administered by a different organization (for example, in the case of
+   an end user's site, the prefix name will most likely point to a name
+   belonging to an ISP that provides connectivity for the site).  While
+   pointers out of zone are not a problem per se, pointers to other
+   organizations are somewhat more difficult to maintain and less
+
+
+
+Austein                      Informational                      [Page 4]
+
+RFC 3364           Tradeoffs in DNS Support for IPv6         August 2002
+
+
+   susceptible to automation than pointers within a single organization
+   would be.  Experience both with glue RRs and with PTR RRs in the IN-
+   ADDR.ARPA tree suggests that many zone administrators do not really
+   understand how to set up and maintain these pointers properly, and we
+   have no particular reason to believe that these zone administrators
+   will do a better job with A6 chains than they do today.  To be fair,
+   however, the alternative case of building AAAA RRs via preprocessing
+   before loading zones has many of the same problems; at best, one can
+   claim that using AAAA RRs for this purpose would allow DNS clients to
+   get the wrong answer somewhat more efficiently than with A6 RRs.
+
+   Finally, assuming near total ignorance of how likely a query is to
+   fail, the probability of failure with an N-link A6 chain would appear
+   to be roughly proportional to N, since each of the queries involved
+   in resolving an A6 chain would have the same probability of failure
+   as a single AAAA query.  Note again that this comment applies to
+   failures in the the process of resolving a query, not to the data
+   obtained via that process.  Arguably, in an ideal world, A6 RRs would
+   increase the probability of the answer a client (finally) gets being
+   right, assuming that nothing goes wrong in the query process, but we
+   have no real idea how to quantify that assumption at this point even
+   to the hand-wavey extent used elsewhere in this note.
+
+   One potential problem that has been raised in the past regarding A6
+   RRs turns out not to be a serious issue.  The A6 design includes the
+   possibility of there being more than one A6 RR matching the prefix
+   name portion of a leaf A6 RR.  That is, an A6 chain may not be a
+   simple linked list, it may in fact be a tree, where each branch
+   represents a possible prefix.  Some critics of A6 have been concerned
+   that this will lead to a wild expansion of queries, but this turns
+   out not to be a problem if a resolver simply follows the "bounded
+   work per query" rule described in RFC 1034 (page 35).  That rule
+   applies to all work resulting from attempts to process a query,
+   regardless of whether it's a simple query, a CNAME chain, an A6 tree,
+   or an infinite loop.  The client may not get back a useful answer in
+   cases where the zone has been configured badly, but a proper
+   implementation should not produce a query explosion as a result of
+   processing even the most perverse A6 tree, chain, or loop.
+
+Interactions with DNSSEC
+
+   One of the areas where AAAA and A6 RRs differ is in the precise
+   details of how they interact with DNSSEC.  The following comments
+   apply only to non-zero-prefix A6 RRs (A6 0 RRs, once again, are
+   semantically equivalent to AAAA RRs).
+
+
+
+
+
+
+Austein                      Informational                      [Page 5]
+
+RFC 3364           Tradeoffs in DNS Support for IPv6         August 2002
+
+
+   Other things being equal, the time it takes to re-sign all of the
+   addresses in a zone after a renumbering event is longer with AAAA RRs
+   than with A6 RRs (because each address record has to be re-signed
+   rather than just signing a common prefix A6 RR and a few A6 0 RRs
+   associated with the zone's name servers).  Note, however, that in
+   general this does not present a serious scaling problem, because the
+   re-signing is performed in the leaf zones.
+
+   Other things being equal, there's more work involved in verifying the
+   signatures received back for A6 RRs, because each address fragment
+   has a separate associated signature.  Similarly, a DNS message
+   containing a set of A6 address fragments and their associated
+   signatures will be larger than the equivalent packet with a single
+   AAAA (or A6 0) and a single associated signature.
+
+   Since AAAA RRs cannot really represent rapid renumbering or GSE-style
+   routing scenarios very well, it should not be surprising that DNSSEC
+   signatures of AAAA RRs are also somewhat problematic.  In cases where
+   the AAAA RRs would have to be changing very quickly to keep up with
+   prefix changes, the time required to re-sign the AAAA RRs may be
+   prohibitive.
+
+   Empirical testing by Bill Sommerfeld [Sommerfeld] suggests that
+   333MHz Celeron laptop with 128KB L2 cache and 64MB RAM running the
+   BIND-9 dnssec-signzone program under NetBSD can generate roughly 40
+   1024-bit RSA signatures per second.  Extrapolating from this,
+   assuming one A RR, one AAAA RR, and one NXT RR per host, this
+   suggests that it would take this laptop a few hours to sign a zone
+   listing 10**5 hosts, or about a day to sign a zone listing 10**6
+   hosts using AAAA RRs.
+
+   This suggests that the additional effort of re-signing a large zone
+   full of AAAA RRs during a re-numbering event, while noticeable, is
+   only likely to be prohibitive in the rapid renumbering case where
+   AAAA RRs don't work well anyway.
+
+Interactions with Dynamic Update
+
+   DNS dynamic update appears to work equally well for AAAA or A6 RRs,
+   with one minor exception: with A6 RRs, the dynamic update client
+   needs to know the prefix length and prefix name.  At present, no
+   mechanism exists to inform a dynamic update client of these values,
+   but presumably such a mechanism could be provided via an extension to
+   DHCP, or some other equivalent could be devised.
+
+
+
+
+
+
+
+Austein                      Informational                      [Page 6]
+
+RFC 3364           Tradeoffs in DNS Support for IPv6         August 2002
+
+
+Transition from AAAA to A6 Via AAAA Synthesis
+
+   While AAAA is at present more widely deployed than A6, it is possible
+   to transition from AAAA-aware DNS software to A6-aware DNS software.
+   A rough plan for this was presented at IETF-50 in Minneapolis and has
+   been discussed on the ipng mailing list.  So if the IETF concludes
+   that A6's enhanced capabilities are necessary, it should be possible
+   to transition from AAAA to A6.
+
+   The details of this transition have been left to a separate document,
+   but the general idea is that the resolver that is performing
+   iterative resolution on behalf of a DNS client program could
+   synthesize AAAA RRs representing the result of performing the
+   equivalent A6 queries.  Note that in this case it is not possible to
+   generate an equivalent DNSSEC signature for the AAAA RR, so clients
+   that care about performing DNSSEC validation for themselves would
+   have to issue A6 queries directly rather than relying on AAAA
+   synthesis.
+
+Bitlabels
+
+   While the differences between AAAA and A6 RRs have generated most of
+   the discussion to date, there are also two proposed mechanisms for
+   building the reverse mapping tree (the IPv6 equivalent of IPv4's IN-
+   ADDR.ARPA tree).
+
+   [RFC1886] proposes a mechanism very similar to the IN-ADDR.ARPA
+   mechanism used for IPv4 addresses: the RR name is the hexadecimal
+   representation of the IPv6 address, reversed and concatenated with a
+   well-known suffix, broken up with a dot between each hexadecimal
+   digit.  The resulting DNS names are somewhat tedious for humans to
+   type, but are very easy for programs to generate.  Making each
+   hexadecimal digit a separate label means that delegation on arbitrary
+   bit boundaries will result in a maximum of 16 NS RRsets per label
+   level; again, the mechanism is somewhat tedious for humans, but is
+   very easy to program.  As with IPv4's IN-ADDR.ARPA tree, the one
+   place where this scheme is weak is in handling delegations in the
+   least significant label; however, since there appears to be no real
+   need to delegate the least significant four bits of an IPv6 address,
+   this does not appear to be a serious restriction.
+
+   [RFC2874] proposed a radically different way of naming entries in the
+   reverse mapping tree: rather than using textual representations of
+   addresses, it proposes to use a new kind of DNS label (a "bit label")
+   to represent binary addresses directly in the DNS.  This has the
+   advantage of being significantly more compact than the textual
+   representation, and arguably might have been a better solution for
+   DNS to use for this purpose if it had been designed into the protocol
+
+
+
+Austein                      Informational                      [Page 7]
+
+RFC 3364           Tradeoffs in DNS Support for IPv6         August 2002
+
+
+   from the outset.  Unfortunately, experience to date suggests that
+   deploying a new DNS label type is very hard: all of the DNS name
+   servers that are authoritative for any portion of the name in
+   question must be upgraded before the new label type can be used, as
+   must any resolvers involved in the resolution process.  Any name
+   server that has not been upgraded to understand the new label type
+   will reject the query as being malformed.
+
+   Since the main benefit of the bit label approach appears to be an
+   ability that we don't really need (delegation in the least
+   significant four bits of an IPv6 address), and since the upgrade
+   problem is likely to render bit labels unusable until a significant
+   portion of the DNS code base has been upgraded, it is difficult to
+   escape the conclusion that the textual solution is good enough.
+
+DNAME RRs
+
+   [RFC2874] also proposes using DNAME RRs as a way of providing the
+   equivalent of A6's fragmented addresses in the reverse mapping tree.
+   That is, by using DNAME RRs, one can write zone files for the reverse
+   mapping tree that have the same ability to cope with rapid
+   renumbering or GSE-style routing that the A6 RR offers in the main
+   portion of the DNS tree.  Consequently, the need to use DNAME in the
+   reverse mapping tree appears to be closely tied to the need to use
+   fragmented A6 in the main tree: if one is necessary, so is the other,
+   and if one isn't necessary, the other isn't either.
+
+   Other uses have also been proposed for the DNAME RR, but since they
+   are outside the scope of the IPv6 address discussion, they will not
+   be addressed here.
+
+Recommendation
+
+   Distilling the above feature comparisons down to their key elements,
+   the important questions appear to be:
+
+   (a) Is IPv6 going to do rapid renumbering or GSE-like routing?
+
+   (b) Is the reverse mapping tree for IPv6 going to require delegation
+       in the least significant four bits of the address?
+
+   Question (a) appears to be the key to the debate.  This is really a
+   decision for the IPv6 community to make, not the DNS community.
+
+   Question (b) is also for the IPv6 community to make, but it seems
+   fairly obvious that the answer is "no".
+
+
+
+
+
+Austein                      Informational                      [Page 8]
+
+RFC 3364           Tradeoffs in DNS Support for IPv6         August 2002
+
+
+   Recommendations based on these questions:
+
+   (1) If the IPv6 working groups seriously intend to specify and deploy
+       rapid renumbering or GSE-like routing, we should transition to
+       using the A6 RR in the main tree and to using DNAME RRs as
+       necessary in the reverse tree.
+
+   (2) Otherwise, we should keep the simpler AAAA solution in the main
+       tree and should not use DNAME RRs in the reverse tree.
+
+   (3) In either case, the reverse tree should use the textual
+       representation described in [RFC1886] rather than the bit label
+       representation described in [RFC2874].
+
+   (4) If we do go to using A6 RRs in the main tree and to using DNAME
+       RRs in the reverse tree, we should write applicability statements
+       and implementation guidelines designed to discourage excessively
+       complex uses of these features; in general, any network that can
+       be described adequately using A6 0 RRs and without using DNAME
+       RRs should be described that way, and the enhanced features
+       should be used only when absolutely necessary, at least until we
+       have much more experience with them and have a better
+       understanding of their failure modes.
+
+Security Considerations
+
+   This note compares two mechanisms with similar security
+   characteristics, but there are a few security implications to the
+   choice between these two mechanisms:
+
+   (1) The two mechanisms have similar but not identical interactions
+       with DNSSEC.  Please see the section entitled "Interactions with
+       DNSSEC" (above) for a discussion of these issues.
+
+   (2) To the extent that operational complexity is the enemy of
+       security, the tradeoffs in operational complexity discussed
+       throughout this note have an impact on security.
+
+   (3) To the extent that protocol complexity is the enemy of security,
+       the additional protocol complexity of [RFC2874] as compared to
+       [RFC1886] has some impact on security.
+
+IANA Considerations
+
+   None, since all of these RR types have already been allocated.
+
+
+
+
+
+
+Austein                      Informational                      [Page 9]
+
+RFC 3364           Tradeoffs in DNS Support for IPv6         August 2002
+
+
+Acknowledgments
+
+   This note is based on a number of discussions both public and private
+   over a period of (at least) eight years, but particular thanks go to
+   Alain Durand, Bill Sommerfeld, Christian Huitema, Jun-ichiro itojun
+   Hagino, Mark Andrews, Matt Crawford, Olafur Gudmundsson, Randy Bush,
+   and Sue Thomson, none of whom are responsible for what the author did
+   with their ideas.
+
+References
+
+   [RFC1886]    Thomson, S. and C. Huitema, "DNS Extensions to support
+                IP version 6", RFC 1886, December 1995.
+
+   [RFC2874]    Crawford, M. and C. Huitema, "DNS Extensions to Support
+                IPv6 Address Aggregation and Renumbering", RFC 2874,
+                July 2000.
+
+   [Sommerfeld] Private message to the author from Bill Sommerfeld dated
+                21 March 2001, summarizing the result of experiments he
+                performed on a copy of the MIT.EDU zone.
+
+   [GSE]       "GSE" was an evolution of the so-called "8+8" proposal
+                discussed by the IPng working group in 1996 and 1997.
+                The GSE proposal itself was written up as an Internet-
+                Draft, which has long since expired.  Readers interested
+                in the details and history of GSE should review the IPng
+                working group's mailing list archives and minutes from
+                that period.
+
+Author's Address
+
+   Rob Austein
+
+   EMail: sra@hactrn.net
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Austein                      Informational                     [Page 10]
+
+RFC 3364           Tradeoffs in DNS Support for IPv6         August 2002
+
+
+Full Copyright Statement
+
+   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 Standards process must be
+   followed, or as required to translate it into 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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Austein                      Informational                     [Page 11]
+
diff --git a/doc/rfc/rfc3425.txt b/doc/rfc/rfc3425.txt
new file mode 100644
index 0000000..707cafd
--- /dev/null
+++ b/doc/rfc/rfc3425.txt
@@ -0,0 +1,283 @@
+
+
+
+
+
+
+Network Working Group                                        D. Lawrence
+Request for Comments: 3425                                       Nominum
+Updates: 1035                                              November 2002
+Category: Standards Track
+
+
+                           Obsoleting IQUERY
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2002).  All Rights Reserved.
+
+Abstract
+
+   The IQUERY method of performing inverse DNS lookups, specified in RFC
+   1035, has not been generally implemented and has usually been
+   operationally disabled where it has been implemented.  Both reflect a
+   general view in the community that the concept was unwise and that
+   the widely-used alternate approach of using pointer (PTR) queries and
+   reverse-mapping records is preferable.  Consequently, this document
+   deprecates the IQUERY operation, declaring it entirely obsolete.
+   This document updates RFC 1035.
+
+1 - Introduction
+
+   As specified in RFC 1035 (section 6.4), the IQUERY operation for DNS
+   queries is used to look up the name(s) which are associated with the
+   given value.  The value being sought is provided in the query's
+   answer section and the response fills in the question section with
+   one or more 3-tuples of type, name and class.
+
+   As noted in [RFC1035], section 6.4.3, inverse query processing can
+   put quite an arduous burden on a server.  A server would need to
+   perform either an exhaustive search of its database or maintain a
+   separate database that is keyed by the values of the primary
+   database.  Both of these approaches could strain system resource use,
+   particularly for servers that are authoritative for millions of
+   names.
+
+
+
+
+
+Lawrence                    Standards Track                     [Page 1]
+
+RFC 3425                   Obsoleting IQUERY               November 2002
+
+
+   Response packets from these megaservers could be exceptionally large,
+   and easily run into megabyte sizes.  For example, using IQUERY to
+   find every domain that is delegated to one of the nameservers of a
+   large ISP could return tens of thousands of 3-tuples in the question
+   section.  This could easily be used to launch denial of service
+   attacks.
+
+   Operators of servers that do support IQUERY in some form (such as
+   very old BIND 4 servers) generally opt to disable it.  This is
+   largely due to bugs in insufficiently-exercised code, or concerns
+   about exposure of large blocks of names in their zones by probes such
+   as inverse MX queries.
+
+   IQUERY is also somewhat inherently crippled by being unable to tell a
+   requester where it needs to go to get the information that was
+   requested.  The answer is very specific to the single server that was
+   queried.  This is sometimes a handy diagnostic tool, but apparently
+   not enough so that server operators like to enable it, or request
+   implementation where it is lacking.
+
+   No known clients use IQUERY to provide any meaningful service.  The
+   only common reverse mapping support on the Internet, mapping address
+   records to names, is provided through the use of pointer (PTR)
+   records in the in-addr.arpa tree and has served the community well
+   for many years.
+
+   Based on all of these factors, this document recommends that the
+   IQUERY operation for DNS servers be officially obsoleted.
+
+2 - Requirements
+
+   The key word "SHOULD" in this document is to be interpreted as
+   described in BCP 14, RFC 2119, namely that there may exist valid
+   reasons to ignore a particular item, but the full implications must
+   be understood and carefully weighed before choosing a different
+   course.
+
+3 - Effect on RFC 1035
+
+   The effect of this document is to change the definition of opcode 1
+   from that originally defined in section 4.1.1 of RFC 1035, and to
+   entirely supersede section 6.4 (including subsections) of RFC 1035.
+
+   The definition of opcode 1 is hereby changed to:
+
+      "1               an inverse query (IQUERY) (obsolete)"
+
+
+
+
+
+Lawrence                    Standards Track                     [Page 2]
+
+RFC 3425                   Obsoleting IQUERY               November 2002
+
+
+   The text in section 6.4 of RFC 1035 is now considered obsolete.  The
+   following is an applicability statement regarding the IQUERY opcode:
+
+   Inverse queries using the IQUERY opcode were originally described as
+   the ability to look up the names that are associated with a
+   particular Resource Record (RR).  Their implementation was optional
+   and never achieved widespread use.  Therefore IQUERY is now obsolete,
+   and name servers SHOULD return a "Not Implemented" error when an
+   IQUERY request is received.
+
+4 - Security Considerations
+
+   Since this document obsoletes an operation that was once available,
+   it is conceivable that someone was using it as the basis of a
+   security policy.  However, since the most logical course for such a
+   policy to take in the face of a lack of positive response from a
+   server is to deny authentication/authorization, it is highly unlikely
+   that removing support for IQUERY will open any new security holes.
+
+   Note that if IQUERY is not obsoleted, securing the responses with DNS
+   Security (DNSSEC) is extremely difficult without out-on-the-fly
+   digital signing.
+
+5 - IANA Considerations
+
+   The IQUERY opcode of 1 should be permanently retired, not to be
+   assigned to any future opcode.
+
+6 - Acknowledgments
+
+   Olafur Gudmundsson instigated this action.  Matt Crawford, John
+   Klensin, Erik Nordmark and Keith Moore contributed some improved
+   wording in how to handle obsoleting functionality described by an
+   Internet Standard.
+
+7 - References
+
+   [RFC1035]  Mockapetris, P., "Domain Names - Implementation and
+              Specification", STD 13, RFC 1035, November 1987.
+
+   [RFC2026]  Bradner, S., "The Internet Standards Process -- Revision
+              3", BCP 9, RFC 2026, October 1996.
+
+   [RFC2119]  Bradner, S., "Key Words for Use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+
+
+
+
+
+Lawrence                    Standards Track                     [Page 3]
+
+RFC 3425                   Obsoleting IQUERY               November 2002
+
+
+8 - Author's Address
+
+   David C Lawrence
+   Nominum, Inc.
+   2385 Bay Rd
+   Redwood City CA 94063
+   USA
+
+   Phone: +1.650.779.6042
+   EMail: tale@nominum.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lawrence                    Standards Track                     [Page 4]
+
+RFC 3425                   Obsoleting IQUERY               November 2002
+
+
+9 - Full Copyright Statement
+
+   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 Standards process must be
+   followed, or as required to translate it into 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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lawrence                    Standards Track                     [Page 5]
+
diff --git a/doc/rfc/rfc3445.txt b/doc/rfc/rfc3445.txt
new file mode 100644
index 0000000..67f9b2d
--- /dev/null
+++ b/doc/rfc/rfc3445.txt
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+Network Working Group                                          D. Massey
+Request for Comments: 3445                                       USC/ISI
+Updates: 2535                                                    S. Rose
+Category: Standards Track                                           NIST
+                                                           December 2002
+
+
+           Limiting the Scope of the KEY Resource Record (RR)
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2002).  All Rights Reserved.
+
+Abstract
+
+   This document limits the Domain Name System (DNS) KEY Resource Record
+   (RR) to only keys used by the Domain Name System Security Extensions
+   (DNSSEC).  The original KEY RR used sub-typing to store both DNSSEC
+   keys and arbitrary application keys.  Storing both DNSSEC and
+   application keys with the same record type is a mistake.  This
+   document removes application keys from the KEY record by redefining
+   the Protocol Octet field in the KEY RR Data.  As a result of removing
+   application keys, all but one of the flags in the KEY record become
+   unnecessary and are redefined.  Three existing application key sub-
+   types are changed to reserved, but the format of the KEY record is
+   not changed.  This document updates RFC 2535.
+
+1. Introduction
+
+   This document limits the scope of the KEY Resource Record (RR).  The
+   KEY RR was defined in [3] and used resource record sub-typing to hold
+   arbitrary public keys such as Email, IPSEC, DNSSEC, and TLS keys.
+   This document eliminates the existing Email, IPSEC, and TLS sub-types
+   and prohibits the introduction of new sub-types.  DNSSEC will be the
+   only allowable sub-type for the KEY RR (hence sub-typing is
+   essentially eliminated) and all but one of the KEY RR flags are also
+   eliminated.
+
+
+
+
+
+
+Massey & Rose               Standards Track                     [Page 1]
+
+RFC 3445         Limiting the KEY Resource Record (RR)     December 2002
+
+
+   Section 2 presents the motivation for restricting the KEY record and
+   Section 3 defines the revised KEY RR.  Sections 4 and 5 summarize the
+   changes from RFC 2535 and discuss backwards compatibility.  It is
+   important to note that this document restricts the use of the KEY RR
+   and simplifies the flags, but does not change the definition or use
+   of DNSSEC keys.
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [1].
+
+2. Motivation for Restricting the KEY RR
+
+   The KEY RR RDATA [3] consists of Flags, a Protocol Octet, an
+   Algorithm type, and a Public Key.  The Protocol Octet identifies the
+   KEY RR sub-type.  DNSSEC public keys are stored in the KEY RR using a
+   Protocol Octet value of 3.  Email, IPSEC, and TLS keys were also
+   stored in the KEY RR and used Protocol Octet values of 1,2, and 4
+   (respectively).  Protocol Octet values 5-254 were available for
+   assignment by IANA and values were requested (but not assigned) for
+   applications such as SSH.
+
+   Any use of sub-typing has inherent limitations.  A resolver can not
+   specify the desired sub-type in a DNS query and most DNS operations
+   apply only to resource records sets.  For example, a resolver can not
+   directly request the DNSSEC subtype KEY RRs.  Instead, the resolver
+   has to request all KEY RRs associated with a DNS name and then search
+   the set for the desired DNSSEC sub-type.  DNSSEC signatures also
+   apply to the set of all KEY RRs associated with the DNS name,
+   regardless of sub-type.
+
+   In the case of the KEY RR, the inherent sub-type limitations are
+   exacerbated since the sub-type is used to distinguish between DNSSEC
+   keys and application keys.  DNSSEC keys and application keys differ
+   in virtually every respect and Section 2.1 discusses these
+   differences in more detail.  Combining these very different types of
+   keys into a single sub-typed resource record adds unnecessary
+   complexity and increases the potential for implementation and
+   deployment errors.  Limited experimental deployment has shown that
+   application keys stored in KEY RRs are problematic.
+
+   This document addresses these issues by removing all application keys
+   from the KEY RR.  Note that the scope of this document is strictly
+   limited to the KEY RR and this document does not endorse or restrict
+   the storage of application keys in other, yet undefined, resource
+   records.
+
+
+
+
+
+Massey & Rose               Standards Track                     [Page 2]
+
+RFC 3445         Limiting the KEY Resource Record (RR)     December 2002
+
+
+2.1 Differences Between DNSSEC and Application Keys
+
+   DNSSEC keys are an essential part of the DNSSEC protocol and are used
+   by both name servers and resolvers in order to perform DNS tasks.  A
+   DNS zone key, used to sign and authenticate RR sets, is the most
+   common example of a DNSSEC key.  SIG(0) [4] and TKEY [3]  also use
+   DNSSEC keys.
+
+   Application keys such as Email keys, IPSEC keys, and TLS keys are
+   simply another type of data.  These keys have no special meaning to a
+   name server or resolver.
+
+   The following table summarizes some of the differences between DNSSEC
+   keys and application keys:
+
+      1.  They serve different purposes.
+
+      2.  They are managed by different administrators.
+
+      3.  They are authenticated according to different rules.
+
+      4.  Nameservers use different rules when including them in
+          responses.
+
+      5.  Resolvers process them in different ways.
+
+      6.  Faults/key compromises have different consequences.
+
+   1.  The purpose of a DNSSEC key is to sign resource records
+   associated with a DNS zone (or generate DNS transaction signatures in
+   the case of SIG(0)/TKEY).  But the purpose of an application key is
+   specific to the application.  Application keys, such as PGP/email,
+   IPSEC, TLS, and SSH keys, are not a mandatory part of any zone and
+   the purpose and proper use of application keys is outside the scope
+   of DNS.
+
+   2.  DNSSEC keys are managed by DNS administrators, but application
+   keys are managed by application administrators.  The DNS zone
+   administrator determines the key lifetime, handles any suspected key
+   compromises, and manages any DNSSEC key changes.  Likewise, the
+   application administrator is responsible for the same functions for
+   the application keys related to the application.  For example, a user
+   typically manages her own PGP key and a server manages its own TLS
+   key.  Application key management tasks are outside the scope of DNS
+   administration.
+
+
+
+
+
+
+Massey & Rose               Standards Track                     [Page 3]
+
+RFC 3445         Limiting the KEY Resource Record (RR)     December 2002
+
+
+   3.  DNSSEC zone keys are used to authenticate application keys, but
+   by definition, application keys are not allowed to authenticate DNS
+   zone keys.  A DNS zone key is either configured as a trusted key or
+   authenticated by constructing a chain of trust in the DNS hierarchy.
+   To participate in the chain of trust, a DNS zone needs to exchange
+   zone key information with its parent zone [3].  Application keys are
+   not configured as trusted keys in the DNS and are never part of any
+   DNS chain of trust.  Application key data is not needed by the parent
+   and does not need to be exchanged with the parent zone for secure DNS
+   resolution to work.  A resolver considers an application key RRset as
+   authenticated DNS information if it has a valid signature from the
+   local DNS zone keys, but applications could impose additional
+   security requirements before the application key is accepted as
+   authentic for use with the application.
+
+   4.  It may be useful for nameservers to include DNS zone keys in the
+   additional section of a response, but application keys are typically
+   not useful unless they have been specifically requested.  For
+   example, it could be useful to include the example.com zone key along
+   with a response that contains the www.example.com A record and SIG
+   record.  A secure resolver will need the example.com zone key in
+   order to check the SIG and authenticate the www.example.com A record.
+   It is typically not useful to include the IPSEC, email, and TLS keys
+   along with the A record.  Note that by placing application keys in
+   the KEY record, a resolver would need the IPSEC, email, TLS, and
+   other key associated with example.com if the resolver intends to
+   authenticate the example.com zone key (since signatures only apply to
+   the entire KEY RR set).  Depending on the number of protocols
+   involved, the KEY RR set could grow unwieldy for resolvers, and DNS
+   administrators to manage.
+
+   5.  DNS zone keys require special handling by resolvers, but
+   application keys are treated the same as any other type of DNS data.
+   The DNSSEC keys are of no value to end applications, unless the
+   applications plan to do their own DNS authentication.  By definition,
+   secure resolvers are not allowed to use application keys as part of
+   the authentication process.  Application keys have no unique meaning
+   to resolvers and are only useful to the application requesting the
+   key.  Note that if sub-types are used to identify the application
+   key, then either the interface to the resolver needs to specify the
+   sub-type or the application needs to be able to accept all KEY RRs
+   and pick out the desired sub-type.
+
+   6.  A fault or compromise of a DNS zone key can lead to invalid or
+   forged DNS data, but a fault or compromise of an application key
+   should have no impact on other DNS data.  Incorrectly adding or
+   changing a DNS zone key can invalidate all of the DNS data in the
+   zone and in all of its subzones.  By using a compromised key, an
+
+
+
+Massey & Rose               Standards Track                     [Page 4]
+
+RFC 3445         Limiting the KEY Resource Record (RR)     December 2002
+
+
+   attacker can forge data from the effected zone and for any of its
+   sub-zones.  A fault or compromise of an application key has
+   implications for that application, but it should not have an impact
+   on the DNS.  Note that application key faults and key compromises can
+   have an impact on the entire DNS if the application key and DNS zone
+   keys are both stored in the KEY RR.
+
+   In summary, DNSSEC keys and application keys differ in most every
+   respect.  DNSSEC keys are an essential part of the DNS infrastructure
+   and require special handling by DNS administrators and DNS resolvers.
+   Application keys are simply another type of data and have no special
+   meaning to DNS administrators or resolvers.  These two different
+   types of data do not belong in the same resource record.
+
+3. Definition of the KEY RR
+
+   The KEY RR uses type 25 and is used as resource record for storing
+   DNSSEC keys.  The RDATA for a KEY RR consists of flags, a protocol
+   octet, the algorithm number octet, and the public key itself.  The
+   format is as follows:
+
+   ---------------------------------------------------------------------
+
+
+                        1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |              flags            |   protocol    |   algorithm   |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                                                               /
+   /                        public key                             /
+   /                                                               /
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                             KEY RR Format
+
+   ---------------------------------------------------------------------
+
+   In the flags field, all bits except bit 7 are reserved and MUST be
+   zero.  If Bit 7 (Zone bit) is set to 1, then the KEY is a DNS Zone
+   key.  If Bit 7 is set to 0, the KEY is not a zone key.  SIG(0)/TKEY
+   are examples of DNSSEC keys that are not zone keys.
+
+   The protocol field MUST be set to 3.
+
+   The algorithm and public key fields are not changed.
+
+
+
+
+
+Massey & Rose               Standards Track                     [Page 5]
+
+RFC 3445         Limiting the KEY Resource Record (RR)     December 2002
+
+
+4. Changes from RFC 2535 KEY RR
+
+   The KEY RDATA format is not changed.
+
+   All flags except for the zone key flag are eliminated:
+
+      The A/C bits (bits 0 and 1) are eliminated.  They MUST be set to 0
+      and MUST be ignored by the receiver.
+
+      The extended flags bit (bit 3) is eliminated.  It MUST be set to 0
+      and MUST be ignored by the receiver.
+
+      The host/user bit (bit 6) is eliminated.  It MUST be set to 0 and
+      MUST be ignored by the receiver.
+
+      The zone bit (bit 7) remains unchanged.
+
+      The signatory field (bits 12-15) are eliminated by [5].  They MUST
+      be set to 0 and MUST be ignored by the receiver.
+
+      Bits 2,4,5,8,9,10,11 remain unchanged.  They are reserved, MUST be
+      set to zero and MUST be ignored by the receiver.
+
+   Assignment of any future KEY RR Flag values requires a standards
+   action.
+
+   All Protocol Octet values except DNSSEC (3) are eliminated:
+
+      Value 1 (Email) is renamed to RESERVED.
+
+      Value 2 (IPSEC) is renamed to RESERVED.
+
+      Value 3 (DNSSEC) is unchanged.
+
+      Value 4 (TLS) is renamed to RESERVED.
+
+      Value 5-254 remains unchanged (reserved).
+
+      Value 255 (ANY) is renamed to RESERVED.
+
+   The authoritative data for a zone MUST NOT include any KEY records
+   with a protocol octet other than 3.  The registry maintained by IANA
+   for protocol values is closed for new assignments.
+
+   Name servers and resolvers SHOULD accept KEY RR sets that contain KEY
+   RRs with a value other than 3.  If out of date DNS zones contain
+   deprecated KEY RRs with a protocol octet value other than 3, then
+   simply dropping the deprecated KEY RRs from the KEY RR set would
+
+
+
+Massey & Rose               Standards Track                     [Page 6]
+
+RFC 3445         Limiting the KEY Resource Record (RR)     December 2002
+
+
+   invalidate any associated SIG record(s) and could create caching
+   consistency problems.  Note that KEY RRs with a protocol octet value
+   other than 3 MUST NOT be used to authenticate DNS data.
+
+   The algorithm and public key fields are not changed.
+
+5. Backward Compatibility
+
+   DNSSEC zone KEY RRs are not changed and remain backwards compatible.
+   A properly formatted RFC 2535 zone KEY would have all flag bits,
+   other than the Zone Bit (Bit 7), set to 0 and would have the Protocol
+   Octet set to 3.  This remains true under the restricted KEY.
+
+   DNSSEC non-zone KEY RRs (SIG(0)/TKEY keys) are backwards compatible,
+   but the distinction between host and user keys (flag bit 6) is lost.
+
+   No backwards compatibility is provided for application keys.  Any
+   Email, IPSEC, or TLS keys are now deprecated.  Storing application
+   keys in the KEY RR created problems such as keys at the apex and
+   large RR sets and some change in the definition and/or usage of the
+   KEY RR would have been required even if the approach described here
+   were not adopted.
+
+   Overall, existing nameservers and resolvers will continue to
+   correctly process KEY RRs with a sub-type of DNSSEC keys.
+
+6. Storing Application Keys in the DNS
+
+   The scope of this document is strictly limited to the KEY record.
+   This document prohibits storing application keys in the KEY record,
+   but it does not endorse or restrict the storing application keys in
+   other record types.  Other documents can describe how DNS handles
+   application keys.
+
+7. IANA Considerations
+
+   RFC 2535 created an IANA registry for DNS KEY RR Protocol Octet
+   values.  Values 1, 2, 3, 4, and 255 were assigned by RFC 2535 and
+   values 5-254 were made available for assignment by IANA.  This
+   document makes two sets of changes to this registry.
+
+   First, this document re-assigns DNS KEY RR Protocol Octet values 1,
+   2, 4, and 255 to "reserved".  DNS Key RR Protocol Octet Value 3
+   remains unchanged as "DNSSEC".
+
+
+
+
+
+
+
+Massey & Rose               Standards Track                     [Page 7]
+
+RFC 3445         Limiting the KEY Resource Record (RR)     December 2002
+
+
+   Second, new values are no longer available for assignment by IANA and
+   this document closes the IANA registry for DNS KEY RR Protocol Octet
+   Values.  Assignment of any future KEY RR Protocol Octet values
+   requires a standards action.
+
+8. Security Considerations
+
+   This document eliminates potential security problems that could arise
+   due to the coupling of DNS zone keys and application keys.  Prior to
+   the change described in this document, a correctly authenticated KEY
+   set could include both application keys and DNSSEC keys.  This
+   document restricts the KEY RR to DNS security usage only.  This is an
+   attempt to simplify the security model and make it less user-error
+   prone.  If one of the application keys is compromised, it could be
+   used as a false zone key to create false DNS signatures (SIG
+   records).  Resolvers that do not carefully check the KEY sub-type
+   could believe these false signatures and incorrectly authenticate DNS
+   data.  With this change, application keys cannot appear in an
+   authenticated KEY set and this vulnerability is eliminated.
+
+   The format and correct usage of DNSSEC keys is not changed by this
+   document and no new security considerations are introduced.
+
+9. Normative References
+
+   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
+        Levels", BCP 14, RFC 2119, March 1997.
+
+   [2]  Eastlake, D., "Domain Name System Security Extensions", RFC
+        2535, March 1999.
+
+   [3]  Eastlake, D., "Secret Key Establishment for DNS (TKEY RR)", RFC
+        2930, September 2000.
+
+   [4]  Eastlake, D., "DNS Request and Transaction Signatures
+        (SIG(0)s)", RFC 2931, September 2000.
+
+   [5]  Wellington, B., "Secure Domain Name System (DNS) Dynamic
+        Update", RFC 3007, November 2000.
+
+
+
+
+
+
+
+
+
+
+
+
+Massey & Rose               Standards Track                     [Page 8]
+
+RFC 3445         Limiting the KEY Resource Record (RR)     December 2002
+
+
+10. Authors' Addresses
+
+   Dan Massey
+   USC Information Sciences Institute
+   3811 N. Fairfax Drive
+   Arlington, VA  22203
+   USA
+
+   EMail: masseyd@isi.edu
+
+
+   Scott Rose
+   National Institute for Standards and Technology
+   100 Bureau Drive
+   Gaithersburg, MD  20899-3460
+   USA
+
+   EMail: scott.rose@nist.gov
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Massey & Rose               Standards Track                     [Page 9]
+
+RFC 3445         Limiting the KEY Resource Record (RR)     December 2002
+
+
+11.  Full Copyright Statement
+
+   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 Standards process must be
+   followed, or as required to translate it into 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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Massey & Rose               Standards Track                    [Page 10]
+
diff --git a/doc/rfc/rfc3467.txt b/doc/rfc/rfc3467.txt
new file mode 100644
index 0000000..37ac7ec
--- /dev/null
+++ b/doc/rfc/rfc3467.txt
@@ -0,0 +1,1739 @@
+
+
+
+
+
+
+Network Working Group                                         J. Klensin
+Request for Comments: 3467                                 February 2003
+Category: Informational
+
+
+                  Role of the Domain Name System (DNS)
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2003).  All Rights Reserved.
+
+Abstract
+
+   This document reviews the original function and purpose of the domain
+   name system (DNS).  It contrasts that history with some of the
+   purposes for which the DNS has recently been applied and some of the
+   newer demands being placed upon it or suggested for it.  A framework
+   for an alternative to placing these additional stresses on the DNS is
+   then outlined.  This document and that framework are not a proposed
+   solution, only a strong suggestion that the time has come to begin
+   thinking more broadly about the problems we are encountering and
+   possible approaches to solving them.
+
+Table of Contents
+
+   1.  Introduction and History .....................................  2
+      1.1 Context for DNS Development ...............................  3
+      1.2 Review of the DNS and Its Role as Designed ................  4
+      1.3 The Web and User-visible Domain Names .....................  6
+      1.4 Internet Applications Protocols and Their Evolution .......  7
+   2.  Signs of DNS Overloading .....................................  8
+   3.  Searching, Directories, and the DNS .......................... 12
+      3.1 Overview  ................................................. 12
+      3.2 Some Details and Comments ................................. 14
+   4.  Internationalization ......................................... 15
+      4.1 ASCII Isn't Just Because of English ....................... 16
+      4.2 The "ASCII Encoding" Approaches ........................... 17
+      4.3 "Stringprep" and Its Complexities ......................... 17
+      4.4 The Unicode Stability Problem ............................. 19
+      4.5 Audiences, End Users, and the User Interface Problem ...... 20
+      4.6 Business Cards and Other Natural Uses of Natural Languages. 22
+      4.7 ASCII Encodings and the Roman Keyboard Assumption ......... 22
+
+
+
+Klensin                      Informational                      [Page 1]
+
+RFC 3467          Role of the Domain Name System (DNS)     February 2003
+
+
+      4.8 Intra-DNS Approaches for "Multilingual Names" ............. 23
+   5.  Search-based Systems: The Key Controversies .................. 23
+   6.  Security Considerations ...................................... 24
+   7.  References ................................................... 25
+      7.1 Normative References ...................................... 25
+      7.2 Explanatory and Informative References .................... 25
+   8.  Acknowledgements ............................................. 30
+   9.  Author's Address ............................................. 30
+   10. Full Copyright Statement ..................................... 31
+
+1. Introduction and History
+
+   The DNS was designed as a replacement for the older "host table"
+   system.  Both were intended to provide names for network resources at
+   a more abstract level than network (IP) addresses (see, e.g.,
+   [RFC625], [RFC811], [RFC819], [RFC830], [RFC882]).  In recent years,
+   the DNS has become a database of convenience for the Internet, with
+   many proposals to add new features.  Only some of these proposals
+   have been successful.  Often the main (or only) motivation for using
+   the DNS is because it exists and is widely deployed, not because its
+   existing structure, facilities, and content are appropriate for the
+   particular application of data involved.  This document reviews the
+   history of the DNS, including examination of some of those newer
+   applications.  It then argues that the overloading process is often
+   inappropriate.  Instead, it suggests that the DNS should be
+   supplemented by systems better matched to the intended applications
+   and outlines a framework and rationale for one such system.
+
+   Several of the comments that follow are somewhat revisionist.  Good
+   design and engineering often requires a level of intuition by the
+   designers about things that will be necessary in the future; the
+   reasons for some of these design decisions are not made explicit at
+   the time because no one is able to articulate them.  The discussion
+   below reconstructs some of the decisions about the Internet's primary
+   namespace (the "Class=IN" DNS) in the light of subsequent development
+   and experience.  In addition, the historical reasons for particular
+   decisions about the Internet were often severely underdocumented
+   contemporaneously and, not surprisingly, different participants have
+   different recollections about what happened and what was considered
+   important.  Consequently, the quasi-historical story below is just
+   one story.  There may be (indeed, almost certainly are) other stories
+   about how the DNS evolved to its present state, but those variants do
+   not invalidate the inferences and conclusions.
+
+   This document presumes a general understanding of the terminology of
+   RFC 1034 [RFC1034] or of any good DNS tutorial (see, e.g., [Albitz]).
+
+
+
+
+
+Klensin                      Informational                      [Page 2]
+
+RFC 3467          Role of the Domain Name System (DNS)     February 2003
+
+
+1.1  Context for DNS Development
+
+   During the entire post-startup-period life of the ARPANET and nearly
+   the first decade or so of operation of the Internet, the list of host
+   names and their mapping to and from addresses was maintained in a
+   frequently-updated "host table" [RFC625], [RFC811], [RFC952].  The
+   names themselves were restricted to a subset of ASCII [ASCII] chosen
+   to avoid ambiguities in printed form, to permit interoperation with
+   systems using other character codings (notably EBCDIC), and to avoid
+   the "national use" code positions of ISO 646 [IS646].  These
+   restrictions later became collectively known as the "LDH" rules for
+   "letter-digit-hyphen", the permitted characters.  The table was just
+   a list with a common format that was eventually agreed upon; sites
+   were expected to frequently obtain copies of, and install, new
+   versions.  The host tables themselves were introduced to:
+
+   o  Eliminate the requirement for people to remember host numbers
+      (addresses).  Despite apparent experience to the contrary in the
+      conventional telephone system, numeric numbering systems,
+      including the numeric host number strategy, did not (and do not)
+      work well for more than a (large) handful of hosts.
+
+   o  Provide stability when addresses changed.  Since addresses -- to
+      some degree in the ARPANET and more importantly in the
+      contemporary Internet -- are a function of network topology and
+      routing, they often had to be changed when connectivity or
+      topology changed.  The names could be kept stable even as
+      addresses changed.
+
+   o  Provide the capability to have multiple addresses associated with
+      a given host to reflect different types of connectivity and
+      topology.  Use of names, rather than explicit addresses, avoided
+      the requirement that would otherwise exist for users and other
+      hosts to track these multiple host numbers and addresses and the
+      topological considerations for selecting one over others.
+
+   After several years of using the host table approach, the community
+   concluded that model did not scale adequately and that it would not
+   adequately support new service variations.  A number of discussions
+   and meetings were held which drew several ideas and incomplete
+   proposals together.  The DNS was the result of that effort.  It
+   continued to evolve during the design and initial implementation
+   period, with a number of documents recording the changes (see
+   [RFC819], [RFC830], and [RFC1034]).
+
+
+
+
+
+
+
+Klensin                      Informational                      [Page 3]
+
+RFC 3467          Role of the Domain Name System (DNS)     February 2003
+
+
+   The goals for the DNS included:
+
+   o  Preservation of the capabilities of the host table arrangements
+      (especially unique, unambiguous, host names),
+
+   o  Provision for addition of additional services (e.g., the special
+      record types for electronic mail routing which quickly followed
+      introduction of the DNS), and
+
+   o  Creation of a robust, hierarchical, distributed, name lookup
+      system to accomplish the other goals.
+
+   The DNS design also permitted distribution of name administration,
+   rather than requiring that each host be entered into a single,
+   central, table by a central administration.
+
+1.2 Review of the DNS and Its Role as Designed
+
+   The DNS was designed to identify network resources.  Although there
+   was speculation about including, e.g., personal names and email
+   addresses, it was not designed primarily to identify people, brands,
+   etc.  At the same time, the system was designed with the flexibility
+   to accommodate new data types and structures, both through the
+   addition of new record types to the initial "INternet" class, and,
+   potentially, through the introduction of new classes.  Since the
+   appropriate identifiers and content of those future extensions could
+   not be anticipated, the design provided that these fields could
+   contain any (binary) information, not just the restricted text forms
+   of the host table.
+
+   However, the DNS, as it is actually used, is intimately tied to the
+   applications and application protocols that utilize it, often at a
+   fairly low level.
+
+   In particular, despite the ability of the protocols and data
+   structures themselves to accommodate any binary representation, DNS
+   names as used were historically not even unrestricted ASCII, but a
+   very restricted subset of it, a subset that derives from the original
+   host table naming rules.  Selection of that subset was driven in part
+   by human factors considerations, including a desire to eliminate
+   possible ambiguities in an international context.  Hence character
+   codes that had international variations in interpretation were
+   excluded, the underscore character and case distinctions were
+   eliminated as being confusing (in the underscore's case, with the
+   hyphen character) when written or read by people, and so on.  These
+   considerations appear to be very similar to those that resulted in
+   similarly restricted character sets being used as protocol elements
+   in many ITU and ISO protocols (cf. [X29]).
+
+
+
+Klensin                      Informational                      [Page 4]
+
+RFC 3467          Role of the Domain Name System (DNS)     February 2003
+
+
+   Another assumption was that there would be a high ratio of physical
+   hosts to second level domains and, more generally, that the system
+   would be deeply hierarchical, with most systems (and names) at the
+   third level or below and a very large percentage of the total names
+   representing physical hosts.  There are domains that follow this
+   model: many university and corporate domains use fairly deep
+   hierarchies, as do a few country-oriented top level domains
+   ("ccTLDs").  Historically, the "US." domain has been an excellent
+   example of the deeply hierarchical approach.  However, by 1998,
+   comparison of several efforts to survey the DNS showed a count of SOA
+   records that approached (and may have passed) the number of distinct
+   hosts.  Looked at differently, we appear to be moving toward a
+   situation in which the number of delegated domains on the Internet is
+   approaching or exceeding the number of hosts, or at least the number
+   of hosts able to provide services to others on the network.  This
+   presumably results from synonyms or aliases that map a great many
+   names onto a smaller number of hosts.  While experience up to this
+   time has shown that the DNS is robust enough -- given contemporary
+   machines as servers and current bandwidth norms -- to be able to
+   continue to operate reasonably well when those historical assumptions
+   are not met (e.g., with a flat, structure under ".COM" containing
+   well over ten million delegated subdomains [COMSIZE]), it is still
+   useful to remember that the system could have been designed to work
+   optimally with a flat structure (and very large zones) rather than a
+   deeply hierarchical one, and was not.
+
+   Similarly, despite some early speculation about entering people's
+   names and email addresses into the DNS directly (e.g., see
+   [RFC1034]), electronic mail addresses in the Internet have preserved
+   the original, pre-DNS, "user (or mailbox) at location" conceptual
+   format rather than a flatter or strictly dot-separated one.
+   Location, in that instance, is a reference to a host. The sole
+   exception, at least in the "IN" class, has been one field of the SOA
+   record.
+
+   Both the DNS architecture itself and the two-level (host name and
+   mailbox name) provisions for email and similar functions (e.g., see
+   the finger protocol [FINGER]), also anticipated a relatively high
+   ratio of users to actual hosts.  Despite the observation in RFC 1034
+   that the DNS was expected to grow to be proportional to the number of
+   users (section 2.3), it has never been clear that the DNS was
+   seriously designed for, or could, scale to the order of magnitude of
+   number of users (or, more recently, products or document objects),
+   rather than that of physical hosts.
+
+   Just as was the case for the host table before it, the DNS provided
+   critical uniqueness for names, and universal accessibility to them,
+   as part of overall "single internet" and "end to end" models (cf.
+
+
+
+Klensin                      Informational                      [Page 5]
+
+RFC 3467          Role of the Domain Name System (DNS)     February 2003
+
+
+   [RFC2826]).  However, there are many signs that, as new uses evolved
+   and original assumptions were abused (if not violated outright), the
+   system was being stretched to, or beyond, its practical limits.
+
+   The original design effort that led to the DNS included examination
+   of the directory technologies available at the time.  The design
+   group concluded that the DNS design, with its simplifying assumptions
+   and restricted capabilities, would be feasible to deploy and make
+   adequately robust, which the more comprehensive directory approaches
+   were not.  At the same time, some of the participants feared that the
+   limitations might cause future problems; this document essentially
+   takes the position that they were probably correct.  On the other
+   hand, directory technology and implementations have evolved
+   significantly in the ensuing years: it may be time to revisit the
+   assumptions, either in the context of the two- (or more) level
+   mechanism contemplated by the rest of this document or, even more
+   radically, as a path toward a DNS replacement.
+
+1.3 The Web and User-visible Domain Names
+
+   From the standpoint of the integrity of the domain name system -- and
+   scaling of the Internet, including optimal accessibility to content
+   -- the web design decision to use "A record" domain names directly in
+   URLs, rather than some system of indirection, has proven to be a
+   serious mistake in several respects.  Convenience of typing, and the
+   desire to make domain names out of easily-remembered product names,
+   has led to a flattening of the DNS, with many people now perceiving
+   that second-level names under COM (or in some countries, second- or
+   third-level names under the relevant ccTLD) are all that is
+   meaningful.  This perception has been reinforced by some domain name
+   registrars [REGISTRAR] who have been anxious to "sell" additional
+   names.  And, of course, the perception that one needed a second-level
+   (or even top-level) domain per product, rather than having names
+   associated with a (usually organizational) collection of network
+   resources, has led to a rapid acceleration in the number of names
+   being registered.  That acceleration has, in turn, clearly benefited
+   registrars charging on a per-name basis, "cybersquatters", and others
+   in the business of "selling" names, but it has not obviously
+   benefited the Internet as a whole.
+
+   This emphasis on second-level domain names has also created a problem
+   for the trademark community.  Since the Internet is international,
+   and names are being populated in a flat and unqualified space,
+   similarly-named entities are in conflict even if there would
+   ordinarily be no chance of confusing them in the marketplace.  The
+   problem appears to be unsolvable except by a choice between draconian
+   measures.  These might include significant changes to the legislation
+   and conventions that govern disputes over "names" and "marks".  Or
+
+
+
+Klensin                      Informational                      [Page 6]
+
+RFC 3467          Role of the Domain Name System (DNS)     February 2003
+
+
+   they might result in a situation in which the "rights" to a name are
+   typically not settled using the subtle and traditional product (or
+   industry) type and geopolitical scope rules of the trademark system.
+   Instead they have depended largely on political or economic power,
+   e.g., the organization with the greatest resources to invest in
+   defending (or attacking) names will ultimately win out.  The latter
+   raises not only important issues of equity, but also the risk of
+   backlash as the numerous small players are forced to relinquish names
+   they find attractive and to adopt less-desirable naming conventions.
+
+   Independent of these sociopolitical problems, content distribution
+   issues have made it clear that it should be possible for an
+   organization to have copies of data it wishes to make available
+   distributed around the network, with a user who asks for the
+   information by name getting the topologically-closest copy.  This is
+   not possible with simple, as-designed, use of the DNS: DNS names
+   identify target resources or, in the case of email "MX" records, a
+   preferentially-ordered list of resources "closest" to a target (not
+   to the source/user).  Several technologies (and, in some cases,
+   corresponding business models) have arisen to work around these
+   problems, including intercepting and altering DNS requests so as to
+   point to other locations.
+
+   Additional implications are still being discovered and evaluated.
+
+   Approaches that involve interception of DNS queries and rewriting of
+   DNS names (or otherwise altering the resolution process based on the
+   topological location of the user) seem, however, to risk disrupting
+   end-to-end applications in the general case and raise many of the
+   issues discussed by the IAB in [IAB-OPES].  These problems occur even
+   if the rewriting machinery is accompanied by additional workarounds
+   for particular applications.  For example, security associations and
+   applications that need to identify "the same host" often run into
+   problems if DNS names or other references are changed in the network
+   without participation of the applications that are trying to invoke
+   the associated services.
+
+1.4 Internet Applications Protocols and Their Evolution
+
+   At the applications level, few of the protocols in active,
+   widespread, use on the Internet reflect either contemporary knowledge
+   in computer science or human factors or experience accumulated
+   through deployment and use.  Instead, protocols tend to be deployed
+   at a just-past-prototype level, typically including the types of
+   expedient compromises typical with prototypes.  If they prove useful,
+   the nature of the network permits very rapid dissemination (i.e.,
+   they fill a vacuum, even if a vacuum that no one previously knew
+   existed).  But, once the vacuum is filled, the installed base
+
+
+
+Klensin                      Informational                      [Page 7]
+
+RFC 3467          Role of the Domain Name System (DNS)     February 2003
+
+
+   provides its own inertia: unless the design is so seriously faulty as
+   to prevent effective use (or there is a widely-perceived sense of
+   impending disaster unless the protocol is replaced), future
+   developments must maintain backward compatibility and workarounds for
+   problematic characteristics rather than benefiting from redesign in
+   the light of experience.  Applications that are "almost good enough"
+   prevent development and deployment of high-quality replacements.
+
+   The DNS is both an illustration of, and an exception to, parts of
+   this pessimistic interpretation. It was a second-generation
+   development, with the host table system being seen as at the end of
+   its useful life.  There was a serious attempt made to reflect the
+   computing state of the art at the time.  However, deployment was much
+   slower than expected (and very painful for many sites) and some fixed
+   (although relaxed several times) deadlines from a central network
+   administration were necessary for deployment to occur at all.
+   Replacing it now, in order to add functionality, while it continues
+   to perform its core functions at least reasonably well, would
+   presumably be extremely difficult.
+
+   There are many, perhaps obvious, examples of this.  Despite many
+   known deficiencies and weaknesses of definition, the "finger" and
+   "whois" [WHOIS] protocols have not been replaced (despite many
+   efforts to update or replace the latter [WHOIS-UPDATE]).  The Telnet
+   protocol and its many options drove out the SUPDUP [RFC734] one,
+   which was arguably much better designed for a diverse collection of
+   network hosts.  A number of efforts to replace the email or file
+   transfer protocols with models which their advocates considered much
+   better have failed.  And, more recently and below the applications
+   level, there is some reason to believe that this resistance to change
+   has been one of the factors impeding IPv6 deployment.
+
+2. Signs of DNS Overloading
+
+   Parts of the historical discussion above identify areas in which the
+   DNS has become overloaded (semantically if not in the mechanical
+   ability to resolve names).  Despite this overloading, it appears that
+   DNS performance and reliability are still within an acceptable range:
+   there is little evidence of serious performance degradation.  Recent
+   proposals and mechanisms to better respond to overloading and scaling
+   issues have all focused on patching or working around limitations
+   that develop when the DNS is utilized for out-of-design functions,
+   rather than on dramatic rethinking of either DNS design or those
+   uses.  The number of these issues that have arisen at much the same
+   time may argue for just that type of rethinking, and not just for
+   adding complexity and attempting to incrementally alter the design
+   (see, for example, the discussion of simplicity in section 2 of
+   [RFC3439]).
+
+
+
+Klensin                      Informational                      [Page 8]
+
+RFC 3467          Role of the Domain Name System (DNS)     February 2003
+
+
+   For example:
+
+   o  While technical approaches such as larger and higher-powered
+      servers and more bandwidth, and legal/political mechanisms such as
+      dispute resolution policies, have arguably kept the problems from
+      becoming critical, the DNS has not proven adequately responsive to
+      business and individual needs to describe or identify things (such
+      as product names and names of individuals) other than strict
+      network resources.
+
+   o  While stacks have been modified to better handle multiple
+      addresses on a physical interface and some protocols have been
+      extended to include DNS names for determining context, the DNS
+      does not deal especially well with many names associated with a
+      given host (e.g., web hosting facilities with multiple domains on
+      a server).
+
+   o  Efforts to add names deriving from languages or character sets
+      based on other than simple ASCII and English-like names (see
+      below), or even to utilize complex company or product names
+      without the use of hierarchy, have created apparent requirements
+      for names (labels) that are over 63 octets long.  This requirement
+      will undoubtedly increase over time; while there are workarounds
+      to accommodate longer names, they impose their own restrictions
+      and cause their own problems.
+
+   o  Increasing commercialization of the Internet, and visibility of
+      domain names that are assumed to match names of companies or
+      products, has turned the DNS and DNS names into a trademark
+      battleground.  The traditional trademark system in (at least) most
+      countries makes careful distinctions about fields of
+      applicability.  When the space is flattened, without
+      differentiation by either geography or industry sector, not only
+      are there likely conflicts between "Joe's Pizza" (of Boston) and
+      "Joe's Pizza" (of San Francisco) but between both and "Joe's Auto
+      Repair" (of Los Angeles).  All three would like to control
+      "Joes.com" (and would prefer, if it were permitted by DNS naming
+      rules, to also spell it as "Joe's.com" and have both resolve the
+      same way) and may claim trademark rights to do so, even though
+      conflict or confusion would not occur with traditional trademark
+      principles.
+
+   o  Many organizations wish to have different web sites under the same
+      URL and domain name.  Sometimes this is to create local variations
+      -- the Widget Company might want to present different material to
+      a UK user relative to a US one -- and sometimes it is to provide
+      higher performance by supplying information from the server
+      topologically closest to the user.  If the name resolution
+
+
+
+Klensin                      Informational                      [Page 9]
+
+RFC 3467          Role of the Domain Name System (DNS)     February 2003
+
+
+      mechanism is expected to provide this functionality, there are
+      three possible models (which might be combined):
+
+      -  supply information about multiple sites (or locations or
+         references).  Those sites would, in turn, provide information
+         associated with the name and sufficient site-specific
+         attributes to permit the application to make a sensible choice
+         of destination, or
+
+      -  accept client-site attributes and utilize them in the search
+         process, or
+
+      -  return different answers based on the location or identity of
+         the requestor.
+
+   While there are some tricks that can provide partial simulations of
+   these types of function, DNS responses cannot be reliably conditioned
+   in this way.
+
+   These, and similar, issues of performance or content choices can, of
+   course, be thought of as not involving the DNS at all.  For example,
+   the commonly-cited alternate approach of coupling these issues to
+   HTTP content negotiation (cf. [RFC2295]), requires that an HTTP
+   connection first be opened to some "common" or "primary" host so that
+   preferences can be negotiated and then the client redirected or sent
+   alternate data.  At least from the standpoint of improving
+   performance by accessing a "closer" location, both initially and
+   thereafter, this approach sacrifices the desired result before the
+   client initiates any action.  It could even be argued that some of
+   the characteristics of common content negotiation approaches are
+   workarounds for the non-optimal use of the DNS in web URLs.
+
+   o  Many existing and proposed systems for "finding things on the
+      Internet" require a true search capability in which near matches
+      can be reported to the user (or to some user agent with an
+      appropriate rule-set) and to which queries may be ambiguous or
+      fuzzy.  The DNS, by contrast, can accommodate only one set of
+      (quite rigid) matching rules.  Proposals to permit different rules
+      in different localities (e.g., matching rules that are TLD- or
+      zone-specific) help to identify the problem.  But they cannot be
+      applied directly to the DNS without either abandoning the desired
+      level of flexibility or isolating different parts of the Internet
+      from each other (or both).  Fuzzy or ambiguous searches are
+      desirable for resolution of names that might have spelling
+      variations and for names that can be resolved into different sets
+      of glyphs depending on context.  Especially when
+      internationalization is considered, variant name problems go
+      beyond simple differences in representation of a character or
+
+
+
+Klensin                      Informational                     [Page 10]
+
+RFC 3467          Role of the Domain Name System (DNS)     February 2003
+
+
+      ordering of a string.  Instead, avoiding user astonishment and
+      confusion requires consideration of relationships such as
+      languages that can be written with different alphabets, Kanji-
+      Hiragana relationships, Simplified and Traditional Chinese, etc.
+      See [Seng] for a discussion and suggestions for addressing a
+      subset of these issues in the context of characters based on
+      Chinese ones.  But that document essentially illustrates the
+      difficulty of providing the type of flexible matching that would
+      be anticipated by users; instead, it tries to protect against the
+      worst types of confusion (and opportunities for fraud).
+
+   o  The historical DNS, and applications that make assumptions about
+      how it works, impose significant risk (or forces technical kludges
+      and consequent odd restrictions), when one considers adding
+      mechanisms for use with various multi-character-set and
+      multilingual "internationalization" systems.  See the IAB's
+      discussion of some of these issues [RFC2825] for more information.
+
+   o  In order to provide proper functionality to the Internet, the DNS
+      must have a single unique root (the IAB provides more discussion
+      of this issue [RFC2826]).  There are many desires for local
+      treatment of names or character sets that cannot be accommodated
+      without either multiple roots (e.g., a separate root for
+      multilingual names, proposed at various times by MINC [MINC] and
+      others), or mechanisms that would have similar effects in terms of
+      Internet fragmentation and isolation.
+
+   o  For some purposes, it is desirable to be able to search not only
+      an index entry (labels or fully-qualified names in the DNS case),
+      but their values or targets (DNS data).  One might, for example,
+      want to locate all of the host (and virtual host) names which
+      cause mail to be directed to a given server via MX records.  The
+      DNS does not support this capability (see the discussion in
+      [IQUERY]) and it can be simulated only by extracting all of the
+      relevant records (perhaps by zone transfer if the source permits
+      doing so, but that permission is becoming less frequently
+      available) and then searching a file built from those records.
+
+   o  Finally, as additional types of personal or identifying
+      information are added to the DNS, issues arise with protection of
+      that information.  There are increasing calls to make different
+      information available based on the credentials and authorization
+      of the source of the inquiry.  As with information keyed to site
+      locations or proximity (as discussed above), the DNS protocols
+      make providing these differentiated services quite difficult if
+      not impossible.
+
+
+
+
+
+Klensin                      Informational                     [Page 11]
+
+RFC 3467          Role of the Domain Name System (DNS)     February 2003
+
+
+   In each of these cases, it is, or might be, possible to devise ways
+   to trick the DNS system into supporting mechanisms that were not
+   designed into it.  Several ingenious solutions have been proposed in
+   many of these areas already, and some have been deployed into the
+   marketplace with some success.  But the price of each of these
+   changes is added complexity and, with it, added risk of unexpected
+   and destabilizing problems.
+
+   Several of the above problems are addressed well by a good directory
+   system (supported by the LDAP protocol or some protocol more
+   precisely suited to these specific applications) or searching
+   environment (such as common web search engines) although not by the
+   DNS.  Given the difficulty of deploying new applications discussed
+   above, an important question is whether the tricks and kludges are
+   bad enough, or will become bad enough as usage grows, that new
+   solutions are needed and can be deployed.
+
+3. Searching, Directories, and the DNS
+
+3.1 Overview
+
+   The constraints of the DNS and the discussion above suggest the
+   introduction of an intermediate protocol mechanism, referred to below
+   as a "search layer" or "searchable system".  The terms "directory"
+   and "directory system" are used interchangeably with "searchable
+   system" in this document, although the latter is far more precise.
+   Search layer proposals would use a two (or more) stage lookup, not
+   unlike several of the proposals for internationalized names in the
+   DNS (see section 4), but all operations but the final one would
+   involve searching other systems, rather than looking up identifiers
+   in the DNS itself.  As explained below, this would permit relaxation
+   of several constraints, leading to a more capable and comprehensive
+   overall system.
+
+   Ultimately, many of the issues with domain names arise as the result
+   of efforts to use the DNS as a directory.  While, at the time this
+   document was written, sufficient pressure or demand had not occurred
+   to justify a change, it was already quite clear that, as a directory
+   system, the DNS is a good deal less than ideal.  This document
+   suggests that there actually is a requirement for a directory system,
+   and that the right solution to a searchable system requirement is a
+   searchable system, not a series of DNS patches, kludges, or
+   workarounds.
+
+
+
+
+
+
+
+
+Klensin                      Informational                     [Page 12]
+
+RFC 3467          Role of the Domain Name System (DNS)     February 2003
+
+
+   The following points illustrate particular aspects of this
+   conclusion.
+
+   o  A directory system would not require imposition of particular
+      length limits on names.
+
+   o  A directory system could permit explicit association of
+      attributes, e.g., language and country, with a name, without
+      having to utilize trick encodings to incorporate that information
+      in DNS labels (or creating artificial hierarchy for doing so).
+
+   o  There is considerable experience (albeit not much of it very
+      successful) in doing fuzzy and "sonex" (similar-sounding) matching
+      in directory systems.  Moreover, it is plausible to think about
+      different matching rules for different areas and sets of names so
+      that these can be adapted to local cultural requirements.
+      Specifically, it might be possible to have a single form of a name
+      in a directory, but to have great flexibility about what queries
+      matched that name (and even have different variations in different
+      areas).  Of course, the more flexibility that a system provides,
+      the greater the possibility of real or imagined trademark
+      conflicts.  But the opportunity would exist to design a directory
+      structure that dealt with those issues in an intelligent way,
+      while DNS constraints almost certainly make a general and
+      equitable DNS-only solution impossible.
+
+   o  If a directory system is used to translate to DNS names, and then
+      DNS names are looked up in the normal fashion, it may be possible
+      to relax several of the constraints that have been traditional
+      (and perhaps necessary) with the DNS.  For example, reverse-
+      mapping of addresses to directory names may not be a requirement
+      even if mapping of addresses to DNS names continues to be, since
+      the DNS name(s) would (continue to) uniquely identify the host.
+
+   o  Solutions to multilingual transcription problems that are common
+      in "normal life" (e.g., two-sided business cards to be sure that
+      recipients trying to contact a person can access romanized
+      spellings and numbers if the original language is not
+      comprehensible to them) can be easily handled in a directory
+      system by inserting both sets of entries.
+
+   o  A directory system could be designed that would return, not a
+      single name, but a set of names paired with network-locational
+      information or other context-establishing attributes.  This type
+      of information might be of considerable use in resolving the
+      "nearest (or best) server for a particular named resource"
+
+
+
+
+
+Klensin                      Informational                     [Page 13]
+
+RFC 3467          Role of the Domain Name System (DNS)     February 2003
+
+
+      problems that are a significant concern for organizations hosting
+      web and other sites that are accessed from a wide range of
+      locations and subnets.
+
+   o  Names bound to countries and languages might help to manage
+      trademark realities, while, as discussed in section 1.3 above, use
+      of the DNS in trademark-significant contexts tends to require
+      worldwide "flattening" of the trademark system.
+
+   Many of these issues are a consequence of another property of the
+   DNS:  names must be unique across the Internet.  The need to have a
+   system of unique identifiers is fairly obvious (see [RFC2826]).
+   However, if that requirement were to be eliminated in a search or
+   directory system that was visible to users instead of the DNS, many
+   difficult problems -- of both an engineering and a policy nature --
+   would be likely to vanish.
+
+3.2 Some Details and Comments
+
+   Almost any internationalization proposal for names that are in, or
+   map into, the DNS will require changing DNS resolver API calls
+   ("gethostbyname" or equivalent), or adding some pre-resolution
+   preparation mechanism, in almost all Internet applications -- whether
+   to cause the API to take a different character set (no matter how it
+   is then mapped into the bits used in the DNS or another system), to
+   accept or return more arguments with qualifying or identifying
+   information, or otherwise.  Once applications must be opened to make
+   such changes, it is a relatively small matter to switch from calling
+   into the DNS to calling a directory service and then the DNS (in many
+   situations, both actions could be accomplished in a single API call).
+
+   A directory approach can be consistent both with "flat" models and
+   multi-attribute ones.  The DNS requires strict hierarchies, limiting
+   its ability to differentiate among names by their properties.  By
+   contrast, modern directories can utilize independently-searched
+   attributes and other structured schema to provide flexibilities not
+   present in a strictly hierarchical system.
+
+   There is a strong historical argument for a single directory
+   structure (implying a need for mechanisms for registration,
+   delegation, etc.).  But a single structure is not a strict
+   requirement, especially if in-depth case analysis and design work
+   leads to the conclusion that reverse-mapping to directory names is
+   not a requirement (see section 5).  If a single structure is not
+   needed, then, unlike the DNS, there would be no requirement for a
+   global organization to authorize or delegate operation of portions of
+   the structure.
+
+
+
+
+Klensin                      Informational                     [Page 14]
+
+RFC 3467          Role of the Domain Name System (DNS)     February 2003
+
+
+   The "no single structure" concept could be taken further by moving
+   away from simple "names" in favor of, e.g., multiattribute,
+   multihierarchical, faceted systems in which most of the facets use
+   restricted vocabularies.  (These terms are fairly standard in the
+   information retrieval and classification system literature, see,
+   e.g., [IS5127].)  Such systems could be designed to avoid the need
+   for procedures to ensure uniqueness across, or even within, providers
+   and databases of the faceted entities for which the search is to be
+   performed.  (See [DNS-Search] for further discussion.)
+
+   While the discussion above includes very general comments about
+   attributes, it appears that only a very small number of attributes
+   would be needed.  The list would almost certainly include country and
+   language for internationalization purposes.  It might require
+   "charset" if we cannot agree on a character set and encoding,
+   although there are strong arguments for simply using ISO 10646 (also
+   known as Unicode or "UCS" (for Universal Character Set) [UNICODE],
+   [IS10646] coding in interchange.  Trademark issues might motivate
+   "commercial" and "non-commercial" (or other) attributes if they would
+   be helpful in bypassing trademark problems.  And applications to
+   resource location, such as those contemplated for Uniform Resource
+   Identifiers (URIs) [RFC2396, RFC3305] or the Service Location
+   Protocol [RFC2608], might argue for a few other attributes (as
+   outlined above).
+
+4.  Internationalization
+
+   Much of the thinking underlying this document was driven by
+   considerations of internationalizing the DNS or, more specifically,
+   providing access to the functions of the DNS from languages and
+   naming systems that cannot be accurately expressed in the traditional
+   DNS subset of ASCII.  Much of the relevant work was done in the
+   IETF's "Internationalized Domain Names" Working Group (IDN-WG),
+   although this document also draws on extensive parallel discussions
+   in other forums.  This section contains an evaluation of what was
+   learned as an "internationalized DNS" or "multilingual DNS" was
+   explored and suggests future steps based on that evaluation.
+
+   When the IDN-WG was initiated, it was obvious to several of the
+   participants that its first important task was an undocumented one:
+   to increase the understanding of the complexities of the problem
+   sufficiently that naive solutions could be rejected and people could
+   go to work on the harder problems.  The IDN-WG clearly accomplished
+   that task. The beliefs that the problems were simple, and in the
+   corresponding simplistic approaches and their promises of quick and
+   painless deployment, effectively disappeared as the WG's efforts
+   matured.
+
+
+
+
+Klensin                      Informational                     [Page 15]
+
+RFC 3467          Role of the Domain Name System (DNS)     February 2003
+
+
+   Some of the lessons learned from increased understanding and the
+   dissipation of naive beliefs should be taken as cautions by the wider
+   community: the problems are not simple. Specifically, extracting
+   small elements for solution rather than looking at whole systems, may
+   result in obscuring the problems but not solving any problem that is
+   worth the trouble.
+
+4.1 ASCII Isn't Just Because of English
+
+   The hostname rules chosen in the mid-70s weren't just "ASCII because
+   English uses ASCII", although that was a starting point.  We have
+   discovered that almost every other script (and even ASCII if we
+   permit the rest of the characters specified in the ISO 646
+   International Reference Version) is more complex than hostname-
+   restricted-ASCII (the "LDH" form, see section 1.1).  And ASCII isn't
+   sufficient to completely represent English -- there are several words
+   in the language that are correctly spelled only with characters or
+   diacritical marks that do not appear in ASCII.  With a broader
+   selection of scripts, in some examples, case mapping works from one
+   case to the other but is not reversible.  In others, there are
+   conventions about alternate ways to represent characters (in the
+   language, not [only] in character coding) that work most of the time,
+   but not always.  And there are issues in coding, with Unicode/10646
+   providing different ways to represent the same character
+   ("character", rather than "glyph", is used deliberately here).  And,
+   in still others, there are questions as to whether two glyphs
+   "match", which may be a distance-function question, not one with a
+   binary answer.  The IETF approach to these problems is to require
+   pre-matching canonicalization (see the "stringprep" discussion
+   below).
+
+   The IETF has resisted the temptations to either try to specify an
+   entirely new coded character set, or to pick and choose Unicode/10646
+   characters on a per-character basis rather than by using well-defined
+   blocks.  While it may appear that a character set designed to meet
+   Internet-specific needs would be very attractive, the IETF has never
+   had the expertise, resources, and representation from critically-
+   important communities to actually take on that job.  Perhaps more
+   important, a new effort might have chosen to make some of the many
+   complex tradeoffs differently than the Unicode committee did,
+   producing a code with somewhat different characteristics.  But there
+   is no evidence that doing so would produce a code with fewer problems
+   and side-effects.  It is much more likely that making tradeoffs
+   differently would simply result in a different set of problems, which
+   would be equally or more difficult.
+
+
+
+
+
+
+Klensin                      Informational                     [Page 16]
+
+RFC 3467          Role of the Domain Name System (DNS)     February 2003
+
+
+4.2 The "ASCII Encoding" Approaches
+
+   While the DNS can handle arbitrary binary strings without known
+   internal problems (see [RFC2181]), some restrictions are imposed by
+   the requirement that text be interpreted in a case-independent way
+   ([RFC1034], [RFC1035]).  More important, most internet applications
+   assume the hostname-restricted "LDH" syntax that is specified in the
+   host table RFCs and as "prudent" in RFC 1035.  If those assumptions
+   are not met, many conforming implementations of those applications
+   may exhibit behavior that would surprise implementors and users.  To
+   avoid these potential problems, IETF internationalization work has
+   focused on "ASCII-Compatible Encodings" (ACE).  These encodings
+   preserve the LDH conventions in the DNS itself.  Implementations of
+   applications that have not been upgraded utilize the encoded forms,
+   while newer ones can be written to recognize the special codings and
+   map them into non-ASCII characters. These approaches are, however,
+   not problem-free even if human interface issues are ignored.  Among
+   other issues, they rely on what is ultimately a heuristic to
+   determine whether a DNS label is to be considered as an
+   internationalized name (i.e., encoded Unicode) or interpreted as an
+   actual LDH name in its own right.  And, while all determinations of
+   whether a particular query matches a stored object are traditionally
+   made by DNS servers, the ACE systems, when combined with the
+   complexities of international scripts and names, require that much of
+   the matching work be separated into a separate, client-side,
+   canonicalization or "preparation" process before the DNS matching
+   mechanisms are invoked [STRINGPREP].
+
+4.3 "Stringprep" and Its Complexities
+
+   As outlined above, the model for avoiding problems associated with
+   putting non-ASCII names in the DNS and elsewhere evolved into the
+   principle that strings are to be placed into the DNS only after being
+   passed through a string preparation function that eliminates or
+   rejects spurious character codes, maps some characters onto others,
+   performs some sequence canonicalization, and generally creates forms
+   that can be accurately compared.  The impact of this process on
+   hostname-restricted ASCII (i.e., "LDH") strings is trivial and
+   essentially adds only overhead.  For other scripts, the impact is, of
+   necessity, quite significant.
+
+   Although the general notion underlying stringprep is simple, the many
+   details are quite subtle and the associated tradeoffs are complex. A
+   design team worked on it for months, with considerable effort placed
+   into clarifying and fine-tuning the protocol and tables.  Despite
+   general agreement that the IETF would avoid getting into the business
+   of defining character sets, character codings, and the associated
+   conventions, the group several times considered and rejected special
+
+
+
+Klensin                      Informational                     [Page 17]
+
+RFC 3467          Role of the Domain Name System (DNS)     February 2003
+
+
+   treatment of code positions to more nearly match the distinctions
+   made by Unicode with user perceptions about similarities and
+   differences between characters.  But there were intense temptations
+   (and pressures) to incorporate language-specific or country-specific
+   rules.  Those temptations, even when resisted, were indicative of
+   parts of the ongoing controversy or of the basic unsuitability of the
+   DNS for fully internationalized names that are visible,
+   comprehensible, and predictable for end users.
+
+   There have also been controversies about how far one should go in
+   these processes of preparation and transformation and, ultimately,
+   about the validity of various analogies.  For example, each of the
+   following operations has been claimed to be similar to case-mapping
+   in ASCII:
+
+   o  stripping of vowels in Arabic or Hebrew
+
+   o  matching of "look-alike" characters such as upper-case Alpha in
+      Greek and upper-case A in Roman-based alphabets
+
+   o  matching of Traditional and Simplified Chinese characters that
+      represent the same words,
+
+   o  matching of Serbo-Croatian words whether written in Roman-derived
+      or Cyrillic characters
+
+   A decision to support any of these operations would have implications
+   for other scripts or languages and would increase the overall
+   complexity of the process.  For example, unless language-specific
+   information is somehow available, performing matching between
+   Traditional and Simplified Chinese has impacts on Japanese and Korean
+   uses of the same "traditional" characters (e.g., it would not be
+   appropriate to map Kanji into Simplified Chinese).
+
+   Even were the IDN-WG's other work to have been abandoned completely
+   or if it were to fail in the marketplace, the stringprep and nameprep
+   work will continue to be extremely useful, both in identifying issues
+   and problem code points and in providing a reasonable set of basic
+   rules.  Where problems remain, they are arguably not with nameprep,
+   but with the DNS-imposed requirement that its results, as with all
+   other parts of the matching and comparison process, yield a binary
+   "match or no match" answer, rather than, e.g., a value on a
+   similarity scale that can be evaluated by the user or by user-driven
+   heuristic functions.
+
+
+
+
+
+
+
+Klensin                      Informational                     [Page 18]
+
+RFC 3467          Role of the Domain Name System (DNS)     February 2003
+
+
+4.4 The Unicode Stability Problem
+
+   ISO 10646 basically defines only code points, and not rules for using
+   or comparing the characters.  This is part of a long-standing
+   tradition with the work of what is now ISO/IEC JTC1/SC2: they have
+   performed code point assignments and have typically treated the ways
+   in which characters are used as beyond their scope.  Consequently,
+   they have not dealt effectively with the broader range of
+   internationalization issues.  By contrast, the Unicode Technical
+   Committee (UTC) has defined, in annexes and technical reports (see,
+   e.g., [UTR15]), some additional rules for canonicalization and
+   comparison.  Many of those rules and conventions have been factored
+   into the "stringprep" and "nameprep" work, but it is not
+   straightforward to make or define them in a fashion that is
+   sufficiently precise and permanent to be relied on by the DNS.
+
+   Perhaps more important, the discussions leading to nameprep also
+   identified several areas in which the UTC definitions are inadequate,
+   at least without additional information, to make matching precise and
+   unambiguous.  In some of these cases, the Unicode Standard permits
+   several alternate approaches, none of which are an exact and obvious
+   match to DNS needs.  That has left these sensitive choices up to
+   IETF, which lacks sufficient in-depth expertise, much less any
+   mechanism for deciding to optimize one language at the expense of
+   another.
+
+   For example, it is tempting to define some rules on the basis of
+   membership in particular scripts, or for punctuation characters, but
+   there is no precise definition of what characters belong to which
+   script or which ones are, or are not, punctuation.  The existence of
+   these areas of vagueness raises two issues: whether trying to do
+   precise matching at the character set level is actually possible
+   (addressed below) and whether driving toward more precision could
+   create issues that cause instability in the implementation and
+   resolution models for the DNS.
+
+   The Unicode definition also evolves.  Version 3.2 appeared shortly
+   after work on this document was initiated.  It added some characters
+   and functionality and included a few minor incompatible code point
+   changes.  IETF has secured an agreement about constraints on future
+   changes, but it remains to be seen how that agreement will work out
+   in practice.  The prognosis actually appears poor at this stage,
+   since UTC chose to ballot a recent possible change which should have
+   been prohibited by the agreement (the outcome of the ballot is not
+   relevant, only that the ballot was issued rather than having the
+   result be a foregone conclusion).  However, some members of the
+   community consider some of the changes between Unicode 3.0 and 3.1
+   and between 3.1 and 3.2, as well as this recent ballot, to be
+
+
+
+Klensin                      Informational                     [Page 19]
+
+RFC 3467          Role of the Domain Name System (DNS)     February 2003
+
+
+   evidence of instability and that these instabilities are better
+   handled in a system that can be more flexible about handling of
+   characters, scripts, and ancillary information than the DNS.
+
+   In addition, because the systems implications of internationalization
+   are considered out of scope in SC2, ISO/IEC JTC1 has assigned some of
+   those issues to its SC22/WG20 (the Internationalization working group
+   within the subcommittee that deals with programming languages,
+   systems, and environments).  WG20 has historically dealt with
+   internationalization issues thoughtfully and in depth, but its status
+   has several times been in doubt in recent years.  However, assignment
+   of these matters to WG20 increases the risk of eventual ISO
+   internationalization standards that specify different behavior than
+   the UTC specifications.
+
+4.5 Audiences, End Users, and the User Interface Problem
+
+   Part of what has "caused" the DNS internationalization problem, as
+   well as the DNS trademark problem and several others, is that we have
+   stopped thinking about "identifiers for objects" -- which normal
+   people are not expected to see -- and started thinking about "names"
+   -- strings that are expected not only to be readable, but to have
+   linguistically-sensible and culturally-dependent meaning to non-
+   specialist users.
+
+   Within the IETF, the IDN-WG, and sometimes other groups, avoided
+   addressing the implications of that transition by taking "outside our
+   scope -- someone else's problem" approaches or by suggesting that
+   people will just become accustomed to whatever conventions are
+   adopted.  The realities of user and vendor behavior suggest that
+   these approaches will not serve the Internet community well in the
+   long term:
+
+   o  If we want to make it a problem in a different part of the user
+      interface structure, we need to figure out where it goes in order
+      to have proof of concept of our solution.  Unlike vendors whose
+      sole [business] model is the selling or registering of names, the
+      IETF must produce solutions that actually work, in the
+      applications context as seen by the end user.
+
+   o  The principle that "they will get used to our conventions and
+      adapt" is fine if we are writing rules for programming languages
+      or an API.  But the conventions under discussion are not part of a
+      semi-mathematical system, they are deeply ingrained in culture.
+      No matter how often an English-speaking American is told that the
+      Internet requires that the correct spelling of "colour" be used,
+      he or she isn't going to be convinced. Getting a French-speaker in
+      Lyon to use exactly the same lexical conventions as a French-
+
+
+
+Klensin                      Informational                     [Page 20]
+
+RFC 3467          Role of the Domain Name System (DNS)     February 2003
+
+
+      speaker in Quebec in order to accommodate the decisions of the
+      IETF or of a registrar or registry is just not likely.  "Montreal"
+      is either a misspelling or an anglicization of a similar word with
+      an acute accent mark over the "e" (i.e., using the Unicode
+      character U+00E9 or one of its equivalents). But global agreement
+      on a rule that will determine whether the two forms should match
+      -- and that won't astonish end users and speakers of one language
+      or the other -- is as unlikely as agreement on whether
+      "misspelling" or "anglicization" is the greater travesty.
+
+   More generally, it is not clear that the outcome of any conceivable
+   nameprep-like process is going to be good enough for practical,
+   user-level, use.  In the use of human languages by humans, there are
+   many cases in which things that do not match are nonetheless
+   interpreted as matching.  The Norwegian/Danish character that appears
+   in U+00F8 (visually, a lower case 'o' overstruck with a forward
+   slash) and the "o-umlaut" German character that appears in U+00F6
+   (visually, a lower case 'o' with diaeresis (or umlaut)) are clearly
+   different and no matching program should yield an "equal" comparison.
+   But they are more similar to each other than either of them is to,
+   e.g., "e".  Humans are able to mentally make the correction in
+   context, and do so easily, and they can be surprised if computers
+   cannot do so.  Worse, there is a Swedish character whose appearance
+   is identical to the German o-umlaut, and which shares code point
+   U+00F6, but that, if the languages are known and the sounds of the
+   letters or meanings of words including the character are considered,
+   actually should match the Norwegian/Danish use of U+00F8.
+
+   This text uses examples in Roman scripts because it is being written
+   in English and those examples are relatively easy to render.  But one
+   of the important lessons of the discussions about domain name
+   internationalization in recent years is that problems similar to
+   those described above exist in almost every language and script.
+   Each one has its idiosyncrasies, and each set of idiosyncracies is
+   tied to common usage and cultural issues that are very familiar in
+   the relevant group, and often deeply held as cultural values.  As
+   long as a schoolchild in the US can get a bad grade on a spelling
+   test for using a perfectly valid British spelling, or one in France
+   or Germany can get a poor grade for leaving off a diacritical mark,
+   there are issues with the relevant language.  Similarly, if children
+   in Egypt or Israel are taught that it is acceptable to write a word
+   with or without vowels or stress marks, but that, if those marks are
+   included, they must be the correct ones, or a user in Korea is
+   potentially offended or astonished by out-of-order sequences of Jamo,
+   systems based on character-at-a-time processing and simplistic
+   matching, with no contextual information, are not going to satisfy
+   user needs.
+
+
+
+
+Klensin                      Informational                     [Page 21]
+
+RFC 3467          Role of the Domain Name System (DNS)     February 2003
+
+
+   Users are demanding solutions that deal with language and culture.
+   Systems of identifier symbol-strings that serve specialists or
+   computers are, at best, a solution to a rather different (and, at the
+   time this document was written, somewhat ill-defined), problem.  The
+   recent efforts have made it ever more clear that, if we ignore the
+   distinction between the user requirements and narrowly-defined
+   identifiers, we are solving an insufficient problem.  And,
+   conversely, the approaches that have been proposed to approximate
+   solutions to the user requirement may be far more complex than simple
+   identifiers require.
+
+4.6 Business Cards and Other Natural Uses of Natural Languages
+
+   Over the last few centuries, local conventions have been established
+   in various parts of the world for dealing with multilingual
+   situations.  It may be helpful to examine some of these.  For
+   example, if one visits a country where the language is different from
+   ones own, business cards are often printed on two sides, one side in
+   each language.  The conventions are not completely consistent and the
+   technique assumes that recipients will be tolerant. Translations of
+   names or places are attempted in some situations and transliterations
+   in others.  Since it is widely understood that exact translations or
+   transliterations are often not possible, people typically smile at
+   errors, appreciate the effort, and move on.
+
+   The DNS situation differs from these practices in at least two ways.
+   Since a global solution is required, the business card would need a
+   number of sides approximating the number of languages in the world,
+   which is probably impossible without violating laws of physics.  More
+   important, the opportunities for tolerance don't exist:  the DNS
+   requires a exact match or the lookup fails.
+
+4.7 ASCII Encodings and the Roman Keyboard Assumption
+
+   Part of the argument for ACE-based solutions is that they provide an
+   escape for multilingual environments when applications have not been
+   upgraded.  When an older application encounters an ACE-based name,
+   the assumption is that the (admittedly ugly) ASCII-coded string will
+   be displayed and can be typed in.  This argument is reasonable from
+   the standpoint of mixtures of Roman-based alphabets, but may not be
+   relevant if user-level systems and devices are involved that do not
+   support the entry of Roman-based characters or which cannot
+   conveniently render such characters.  Such systems are few in the
+   world today, but the number can reasonably be expected to rise as the
+   Internet is increasingly used by populations whose primary concern is
+   with local issues, local information, and local languages.  It is,
+
+
+
+
+
+Klensin                      Informational                     [Page 22]
+
+RFC 3467          Role of the Domain Name System (DNS)     February 2003
+
+
+   for example, fairly easy to imagine populations who use Arabic or
+   Thai scripts and who do not have routine access to scripts or input
+   devices based on Roman-derived alphabets.
+
+4.8 Intra-DNS Approaches for "Multilingual Names"
+
+   It appears, from the cases above and others, that none of the intra-
+   DNS-based solutions for "multilingual names" are workable.  They rest
+   on too many assumptions that do not appear to be feasible -- that
+   people will adapt deeply-entrenched language habits to conventions
+   laid down to make the lives of computers easy; that we can make
+   "freeze it now, no need for changes in these areas" decisions about
+   Unicode and nameprep; that ACE will smooth over applications
+   problems, even in environments without the ability to key or render
+   Roman-based glyphs (or where user experience is such that such glyphs
+   cannot easily be distinguished from each other); that the Unicode
+   Consortium will never decide to repair an error in a way that creates
+   a risk of DNS incompatibility; that we can either deploy EDNS
+   [RFC2671] or that long names are not really important; that Japanese
+   and Chinese computer users (and others) will either give up their
+   local or IS 2022-based character coding solutions (for which addition
+   of a large fraction of a million new code points to Unicode is almost
+   certainly a necessary, but probably not sufficient, condition) or
+   build leakproof and completely accurate boundary conversion
+   mechanisms; that out of band or contextual information will always be
+   sufficient for the "map glyph onto script" problem; and so on.  In
+   each case, it is likely that about 80% or 90% of cases will work
+   satisfactorily, but it is unlikely that such partial solutions will
+   be good enough.  For example, suppose someone can spell her name 90%
+   correctly, or a company name is matched correctly 80% of the time but
+   the other 20% of attempts identify a competitor: are either likely to
+   be considered adequate?
+
+5. Search-based Systems: The Key Controversies
+
+   For many years, a common response to requirements to locate people or
+   resources on the Internet has been to invoke the term "directory".
+   While an in-depth analysis of the reasons would require a separate
+   document, the history of failure of these invocations has given
+   "directory" efforts a bad reputation.  The effort proposed here is
+   different from those predecessors for several reasons, perhaps the
+   most important of which is that it focuses on a fairly-well-
+   understood set of problems and needs, rather than on finding uses for
+   a particular technology.
+
+   As suggested in some of the text above, it is an open question as to
+   whether the needs of the community would be best served by a single
+   (even if functionally, and perhaps administratively, distributed)
+
+
+
+Klensin                      Informational                     [Page 23]
+
+RFC 3467          Role of the Domain Name System (DNS)     February 2003
+
+
+   directory with universal applicability, a single directory that
+   supports locally-tailored search (and, most important, matching)
+   functions, or multiple, locally-determined, directories.  Each has
+   its attractions.  Any but the first would essentially prevent
+   reverse-mapping (determination of the user-visible name of the host
+   or resource from target information such as an address or DNS name).
+   But reverse mapping has become less useful over the years --at least
+   to users -- as more and more names have been associated with many
+   host addresses and as CIDR [CIDR] has proven problematic for mapping
+   smaller address blocks to meaningful names.
+
+   Locally-tailored searches and mappings would permit national
+   variations on interpretation of which strings matched which other
+   ones, an arrangement that is especially important when different
+   localities apply different rules to, e.g., matching of characters
+   with and without diacriticals.  But, of course, this implies that a
+   URL may evaluate properly or not depending on either settings on a
+   client machine or the network connectivity of the user.  That is not,
+   in general, a desirable situation, since it implies that users could
+   not, in the general case, share URLs (or other host references) and
+   that a particular user might not be able to carry references from one
+   host or location to another.
+
+   And, of course, completely separate directories would permit
+   translation and transliteration functions to be embedded in the
+   directory, giving much of the Internet a different appearance
+   depending on which directory was chosen.  The attractions of this are
+   obvious, but, unless things were very carefully designed to preserve
+   uniqueness and precise identities at the right points (which may or
+   may not be possible), such a system would have many of the
+   difficulties associated with multiple DNS roots.
+
+   Finally, a system of separate directories and databases, if coupled
+   with removal of the DNS-imposed requirement for unique names, would
+   largely eliminate the need for a single worldwide authority to manage
+   the top of the naming hierarchy.
+
+6.  Security Considerations
+
+   The set of proposals implied by this document suggests an interesting
+   set of security issues (i.e., nothing important is ever easy).  A
+   directory system used for locating network resources would presumably
+   need to be as carefully protected against unauthorized changes as the
+   DNS itself.  There also might be new opportunities for problems in an
+   arrangement involving two or more (sub)layers, especially if such a
+   system were designed without central authority or uniqueness of
+   names.  It is uncertain how much greater those risks would be as
+   compared to a DNS lookup sequence that involved looking up one name,
+
+
+
+Klensin                      Informational                     [Page 24]
+
+RFC 3467          Role of the Domain Name System (DNS)     February 2003
+
+
+   getting back information, and then doing additional lookups
+   potentially in different subtrees.  That multistage lookup will often
+   be the case with, e.g., NAPTR records [RFC 2915] unless additional
+   restrictions are imposed.  But additional steps, systems, and
+   databases almost certainly involve some additional risks of
+   compromise.
+
+7.  References
+
+7.1 Normative References
+
+   None
+
+7.2 Explanatory and Informative References
+
+   [Albitz]       Any of the editions of Albitz, P. and C. Liu, DNS and
+                  BIND, O'Reilly and Associates, 1992, 1997, 1998, 2001.
+
+   [ASCII]        American National Standards Institute (formerly United
+                  States of America Standards Institute), X3.4, 1968,
+                  "USA Code for Information Interchange". ANSI X3.4-1968
+                  has been replaced by newer versions with slight
+                  modifications, but the 1968 version remains definitive
+                  for the Internet.  Some time after ASCII was first
+                  formulated as a standard, ISO adopted international
+                  standard 646, which uses ASCII as a base.  IS 646
+                  actually contained two code tables: an "International
+                  Reference Version" (often referenced as ISO 646-IRV)
+                  which was essentially identical to the ASCII of the
+                  time, and a "Basic Version" (ISO 646-BV), which
+                  designates a number of character positions for
+                  national use.
+
+   [CIDR]         Fuller, V., Li, T., Yu, J. and K. Varadhan, "Classless
+                  Inter-Domain Routing (CIDR): an Address Assignment and
+                  Aggregation Strategy", RFC 1519, September 1993.
+
+                  Eidnes, H., de Groot, G. and P. Vixie, "Classless IN-
+                  ADDR.ARPA delegation", RFC 2317, March 1998.
+
+   [COM-SIZE]     Size information supplied by Verisign Global Registry
+                  Services (the zone administrator, or "registry
+                  operator", for COM, see [REGISTRAR], below) to ICANN,
+                  third quarter 2002.
+
+   [DNS-Search]   Klensin, J., "A Search-based access model for the
+                  DNS", Work in Progress.
+
+
+
+
+Klensin                      Informational                     [Page 25]
+
+RFC 3467          Role of the Domain Name System (DNS)     February 2003
+
+
+   [FINGER]       Zimmerman, D., "The Finger User Information Protocol",
+                  RFC 1288, December 1991.
+
+                  Harrenstien, K., "NAME/FINGER Protocol", RFC 742,
+                  December 1977.
+
+   [IAB-OPES]     Floyd, S. and L. Daigle, "IAB Architectural and Policy
+                  Considerations for Open Pluggable Edge Services", RFC
+                  3238, January 2002.
+
+   [IQUERY]       Lawrence, D., "Obsoleting IQUERY", RFC 3425, November
+                  2002.
+
+   [IS646]        ISO/IEC 646:1991 Information technology -- ISO 7-bit
+                  coded character set for information interchange
+
+   [IS10646]      ISO/IEC 10646-1:2000 Information technology --
+                  Universal Multiple-Octet Coded Character Set (UCS) --
+                  Part 1: Architecture and Basic Multilingual Plane and
+                  ISO/IEC 10646-2:2001 Information technology --
+                  Universal Multiple-Octet Coded Character Set (UCS) --
+                  Part 2: Supplementary Planes
+
+   [MINC]         The Multilingual Internet Names Consortium,
+                  http://www.minc.org/ has been an early advocate for
+                  the importance of expansion of DNS names to
+                  accommodate non-ASCII characters.  Some of their
+                  specific proposals, while helping people to understand
+                  the problems better, were not compatible with the
+                  design of the DNS.
+
+   [NAPTR]        Mealling, M. and R. Daniel, "The Naming Authority
+                  Pointer (NAPTR) DNS Resource Record", RFC 2915,
+                  September 2000.
+
+                  Mealling, M., "Dynamic Delegation Discovery System
+                  (DDDS) Part One: The Comprehensive DDDS", RFC 3401,
+                  October 2002.
+
+                  Mealling, M., "Dynamic Delegation Discovery System
+                  (DDDS) Part Two: The Algorithm", RFC 3402, October
+                  2002.
+
+                  Mealling, M., "Dynamic Delegation Discovery System
+                  (DDDS) Part Three: The Domain Name System (DNS)
+                  Database", RFC 3403, October 2002.
+
+
+
+
+
+Klensin                      Informational                     [Page 26]
+
+RFC 3467          Role of the Domain Name System (DNS)     February 2003
+
+
+   [REGISTRAR]    In an early stage of the process that created the
+                  Internet Corporation for Assigned Names and Numbers
+                  (ICANN), a "Green Paper" was released by the US
+                  Government.   That paper introduced new terminology
+                  and some concepts not needed by traditional DNS
+                  operations.  The term "registry" was applied to the
+                  actual operator and database holder of a domain
+                  (typically at the top level, since the Green Paper was
+                  little concerned with anything else), while
+                  organizations that marketed names and made them
+                  available to "registrants" were known as "registrars".
+                  In the classic DNS model, the function of "zone
+                  administrator" encompassed both registry and registrar
+                  roles, although that model did not anticipate a
+                  commercial market in names.
+
+   [RFC625]       Kudlick, M. and E. Feinler, "On-line hostnames
+                  service", RFC 625, March 1974.
+
+   [RFC734]       Crispin, M., "SUPDUP Protocol", RFC 734, October 1977.
+
+   [RFC811]       Harrenstien, K., White, V. and E. Feinler, "Hostnames
+                  Server", RFC 811, March 1982.
+
+   [RFC819]       Su, Z. and J. Postel, "Domain naming convention for
+                  Internet user applications", RFC 819, August 1982.
+
+   [RFC830]       Su, Z., "Distributed system for Internet name
+                  service", RFC 830, October 1982.
+
+   [RFC882]       Mockapetris, P., "Domain names: Concepts and
+                  facilities", RFC 882, November 1983.
+
+   [RFC883]       Mockapetris, P., "Domain names: Implementation
+                  specification", RFC 883, November 1983.
+
+   [RFC952]       Harrenstien, K, Stahl, M. and E. Feinler, "DoD
+                  Internet host table specification", RFC 952, October
+                  1985.
+
+   [RFC953]       Harrenstien, K., Stahl, M. and E. Feinler, "HOSTNAME
+                  SERVER", RFC 953, October 1985.
+
+   [RFC1034]      Mockapetris, P., "Domain names, Concepts and
+                  facilities", STD 13, RFC 1034, November 1987.
+
+
+
+
+
+
+Klensin                      Informational                     [Page 27]
+
+RFC 3467          Role of the Domain Name System (DNS)     February 2003
+
+
+   [RFC1035]      Mockapetris, P., "Domain names - implementation and
+                  specification", STD 13, RFC 1035, November 1987.
+
+   [RFC1591]      Postel, J., "Domain Name System Structure and
+                  Delegation", RFC 1591, March 1994.
+
+   [RFC2181]      Elz, R. and  R. Bush, "Clarifications to the DNS
+                  Specification", RFC 2181, July 1997.
+
+   [RFC2295]      Holtman, K. and A. Mutz, "Transparent Content
+                  Negotiation in HTTP", RFC 2295, March 1998
+
+   [RFC2396]      Berners-Lee, T., Fielding, R. and L. Masinter,
+                  "Uniform Resource Identifiers (URI): Generic Syntax",
+                  RFC 2396, August 1998.
+
+   [RFC2608]      Guttman, E., Perkins, C., Veizades, J. and M. Day,
+                  "Service Location Protocol, Version 2", RFC 2608, June
+                  1999.
+
+   [RFC2671]      Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
+                  2671, August 1999.
+
+   [RFC2825]      IAB, Daigle, L., Ed., "A Tangled Web: Issues of I18N,
+                  Domain Names, and the Other Internet protocols", RFC
+                  2825, May 2000.
+
+   [RFC2826]      IAB, "IAB Technical Comment on the Unique DNS Root",
+                  RFC 2826, May 2000.
+
+   [RFC2972]      Popp, N., Mealling, M., Masinter, L. and K. Sollins,
+                  "Context and Goals for Common Name Resolution", RFC
+                  2972, October 2000.
+
+   [RFC3305]      Mealling, M. and R. Denenberg, Eds., "Report from the
+                  Joint W3C/IETF URI Planning Interest Group: Uniform
+                  Resource Identifiers (URIs), URLs, and Uniform
+                  Resource Names (URNs):  Clarifications and
+                  Recommendations", RFC 3305, August 2002.
+
+   [RFC3439]      Bush, R. and D. Meyer, "Some Internet Architectural
+                  Guidelines and Philosophy", RFC 3439, December 2002.
+
+   [Seng]         Seng, J., et al., Eds., "Internationalized Domain
+                  Names:  Registration and Administration Guideline for
+                  Chinese, Japanese, and Korean", Work in Progress.
+
+
+
+
+
+Klensin                      Informational                     [Page 28]
+
+RFC 3467          Role of the Domain Name System (DNS)     February 2003
+
+
+   [STRINGPREP]   Hoffman, P. and M. Blanchet, "Preparation of
+                  Internationalized Strings (stringprep)", RFC 3454,
+                  December 2002.
+
+                  The particular profile used for placing
+                  internationalized strings in the DNS is called
+                  "nameprep", described in Hoffman, P. and M. Blanchet,
+                  "Nameprep: A Stringprep Profile for Internationalized
+                  Domain Names", Work in Progress.
+
+   [TELNET]       Postel, J. and J. Reynolds, "Telnet Protocol
+                  Specification", STD 8, RFC 854, May 1983.
+
+                  Postel, J. and J. Reynolds, "Telnet Option
+                  Specifications", STD 8, RFC 855, May 1983.
+
+   [UNICODE]      The Unicode Consortium, The Unicode Standard, Version
+                  3.0, Addison-Wesley: Reading, MA, 2000.  Update to
+                  version 3.1, 2001.  Update to version 3.2, 2002.
+
+   [UTR15]        Davis, M. and M. Duerst, "Unicode Standard Annex #15:
+                  Unicode Normalization Forms", Unicode Consortium,
+                  March 2002.  An integral part of The Unicode Standard,
+                  Version 3.1.1.  Available at
+                  (http://www.unicode.org/reports/tr15/tr15-21.html).
+
+   [WHOIS]        Harrenstien, K, Stahl, M. and E. Feinler,
+                  "NICNAME/WHOIS", RFC 954, October 1985.
+
+   [WHOIS-UPDATE] Gargano, J. and K. Weiss, "Whois and Network
+                  Information Lookup Service, Whois++", RFC 1834, August
+                  1995.
+
+                  Weider, C., Fullton, J. and S. Spero, "Architecture of
+                  the Whois++ Index Service", RFC 1913, February 1996.
+
+                  Williamson, S., Kosters, M., Blacka, D., Singh, J. and
+                  K. Zeilstra, "Referral Whois (RWhois) Protocol V1.5",
+                  RFC 2167, June 1997;
+
+                  Daigle, L. and P. Faltstrom, "The
+                  application/whoispp-query Content-Type", RFC 2957,
+                  October 2000.
+
+                  Daigle, L. and P. Falstrom, "The application/whoispp-
+                  response Content-type", RFC 2958, October 2000.
+
+
+
+
+
+Klensin                      Informational                     [Page 29]
+
+RFC 3467          Role of the Domain Name System (DNS)     February 2003
+
+
+   [X29]          International Telecommuncations Union, "Recommendation
+                  X.29: Procedures for the exchange of control
+                  information and user data between a Packet
+                  Assembly/Disassembly (PAD) facility and a packet mode
+                  DTE or another PAD", December 1997.
+
+8. Acknowledgements
+
+   Many people have contributed to versions of this document or the
+   thinking that went into it.  The author would particularly like to
+   thank Harald Alvestrand, Rob Austein, Bob Braden, Vinton Cerf, Matt
+   Crawford, Leslie Daigle, Patrik Faltstrom, Eric A. Hall, Ted Hardie,
+   Paul Hoffman, Erik Nordmark, and Zita Wenzel for making specific
+   suggestions and/or challenging the assumptions and presentation of
+   earlier versions and suggesting ways to improve them.
+
+9. Author's Address
+
+   John C. Klensin
+   1770 Massachusetts Ave, #322
+   Cambridge, MA 02140
+
+   EMail: klensin+srch@jck.com
+
+   A mailing list has been initiated for discussion of the topics
+   discussed in this document, and closely-related issues, at
+   ietf-irnss@lists.elistx.com.  See http://lists.elistx.com/archives/
+   for subscription and archival information.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Klensin                      Informational                     [Page 30]
+
+RFC 3467          Role of the Domain Name System (DNS)     February 2003
+
+
+10. Full Copyright Statement
+
+   Copyright (C) The Internet Society (2003).  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 Standards process must be
+   followed, or as required to translate it into 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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Klensin                      Informational                     [Page 31]
+
diff --git a/doc/rfc/rfc3490.txt b/doc/rfc/rfc3490.txt
new file mode 100644
index 0000000..d2e0b3b
--- /dev/null
+++ b/doc/rfc/rfc3490.txt
@@ -0,0 +1,1235 @@
+
+
+
+
+
+
+Network Working Group                                       P. Faltstrom
+Request for Comments: 3490                                         Cisco
+Category: Standards Track                                     P. Hoffman
+                                                              IMC & VPNC
+                                                             A. Costello
+                                                             UC Berkeley
+                                                              March 2003
+
+
+         Internationalizing Domain Names in Applications (IDNA)
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2003).  All Rights Reserved.
+
+Abstract
+
+   Until now, there has been no standard method for domain names to use
+   characters outside the ASCII repertoire.  This document defines
+   internationalized domain names (IDNs) and a mechanism called
+   Internationalizing Domain Names in Applications (IDNA) for handling
+   them in a standard fashion.  IDNs use characters drawn from a large
+   repertoire (Unicode), but IDNA allows the non-ASCII characters to be
+   represented using only the ASCII characters already allowed in so-
+   called host names today.  This backward-compatible representation is
+   required in existing protocols like DNS, so that IDNs can be
+   introduced with no changes to the existing infrastructure.  IDNA is
+   only meant for processing domain names, not free text.
+
+Table of Contents
+
+   1. Introduction..................................................  2
+      1.1 Problem Statement.........................................  3
+      1.2 Limitations of IDNA.......................................  3
+      1.3 Brief overview for application developers.................  4
+   2. Terminology...................................................  5
+   3. Requirements and applicability................................  7
+      3.1 Requirements..............................................  7
+      3.2 Applicability.............................................  8
+         3.2.1. DNS resource records................................  8
+
+
+
+Faltstrom, et al.           Standards Track                     [Page 1]
+
+RFC 3490                          IDNA                        March 2003
+
+
+         3.2.2. Non-domain-name data types stored in domain names...  9
+   4. Conversion operations.........................................  9
+      4.1 ToASCII................................................... 10
+      4.2 ToUnicode................................................. 11
+   5. ACE prefix.................................................... 12
+   6. Implications for typical applications using DNS............... 13
+      6.1 Entry and display in applications......................... 14
+      6.2 Applications and resolver libraries....................... 15
+      6.3 DNS servers............................................... 15
+      6.4 Avoiding exposing users to the raw ACE encoding........... 16
+      6.5  DNSSEC authentication of IDN domain names................ 16
+   7. Name server considerations.................................... 17
+   8. Root server considerations.................................... 17
+   9. References.................................................... 18
+      9.1 Normative References...................................... 18
+      9.2 Informative References.................................... 18
+   10. Security Considerations...................................... 19
+   11. IANA Considerations.......................................... 20
+   12. Authors' Addresses........................................... 21
+   13. Full Copyright Statement..................................... 22
+
+1. Introduction
+
+   IDNA works by allowing applications to use certain ASCII name labels
+   (beginning with a special prefix) to represent non-ASCII name labels.
+   Lower-layer protocols need not be aware of this; therefore IDNA does
+   not depend on changes to any infrastructure.  In particular, IDNA
+   does not depend on any changes to DNS servers, resolvers, or protocol
+   elements, because the ASCII name service provided by the existing DNS
+   is entirely sufficient for IDNA.
+
+   This document does not require any applications to conform to IDNA,
+   but applications can elect to use IDNA in order to support IDN while
+   maintaining interoperability with existing infrastructure.  If an
+   application wants to use non-ASCII characters in domain names, IDNA
+   is the only currently-defined option.  Adding IDNA support to an
+   existing application entails changes to the application only, and
+   leaves room for flexibility in the user interface.
+
+   A great deal of the discussion of IDN solutions has focused on
+   transition issues and how IDN will work in a world where not all of
+   the components have been updated.  Proposals that were not chosen by
+   the IDN Working Group would depend on user applications, resolvers,
+   and DNS servers being updated in order for a user to use an
+   internationalized domain name.  Rather than rely on widespread
+   updating of all components, IDNA depends on updates to user
+   applications only; no changes are needed to the DNS protocol or any
+   DNS servers or the resolvers on user's computers.
+
+
+
+Faltstrom, et al.           Standards Track                     [Page 2]
+
+RFC 3490                          IDNA                        March 2003
+
+
+1.1 Problem Statement
+
+   The IDNA specification solves the problem of extending the repertoire
+   of characters that can be used in domain names to include the Unicode
+   repertoire (with some restrictions).
+
+   IDNA does not extend the service offered by DNS to the applications.
+   Instead, the applications (and, by implication, the users) continue
+   to see an exact-match lookup service.  Either there is a single
+   exactly-matching name or there is no match.  This model has served
+   the existing applications well, but it requires, with or without
+   internationalized domain names, that users know the exact spelling of
+   the domain names that the users type into applications such as web
+   browsers and mail user agents.  The introduction of the larger
+   repertoire of characters potentially makes the set of misspellings
+   larger, especially given that in some cases the same appearance, for
+   example on a business card, might visually match several Unicode code
+   points or several sequences of code points.
+
+   IDNA allows the graceful introduction of IDNs not only by avoiding
+   upgrades to existing infrastructure (such as DNS servers and mail
+   transport agents), but also by allowing some rudimentary use of IDNs
+   in applications by using the ASCII representation of the non-ASCII
+   name labels.  While such names are very user-unfriendly to read and
+   type, and hence are not suitable for user input, they allow (for
+   instance) replying to email and clicking on URLs even though the
+   domain name displayed is incomprehensible to the user.  In order to
+   allow user-friendly input and output of the IDNs, the applications
+   need to be modified to conform to this specification.
+
+   IDNA uses the Unicode character repertoire, which avoids the
+   significant delays that would be inherent in waiting for a different
+   and specific character set be defined for IDN purposes by some other
+   standards developing organization.
+
+1.2 Limitations of IDNA
+
+   The IDNA protocol does not solve all linguistic issues with users
+   inputting names in different scripts.  Many important language-based
+   and script-based mappings are not covered in IDNA and need to be
+   handled outside the protocol.  For example, names that are entered in
+   a mix of traditional and simplified Chinese characters will not be
+   mapped to a single canonical name.  Another example is Scandinavian
+   names that are entered with U+00F6 (LATIN SMALL LETTER O WITH
+   DIAERESIS) will not be mapped to U+00F8 (LATIN SMALL LETTER O WITH
+   STROKE).
+
+
+
+
+
+Faltstrom, et al.           Standards Track                     [Page 3]
+
+RFC 3490                          IDNA                        March 2003
+
+
+   An example of an important issue that is not considered in detail in
+   IDNA is how to provide a high probability that a user who is entering
+   a domain name based on visual information (such as from a business
+   card or billboard) or aural information (such as from a telephone or
+   radio) would correctly enter the IDN.  Similar issues exist for ASCII
+   domain names, for example the possible visual confusion between the
+   letter 'O' and the digit zero, but the introduction of the larger
+   repertoire of characters creates more opportunities of similar
+   looking and similar sounding names.  Note that this is a complex
+   issue relating to languages, input methods on computers, and so on.
+   Furthermore, the kind of matching and searching necessary for a high
+   probability of success would not fit the role of the DNS and its
+   exact matching function.
+
+1.3 Brief overview for application developers
+
+   Applications can use IDNA to support internationalized domain names
+   anywhere that ASCII domain names are already supported, including DNS
+   master files and resolver interfaces.  (Applications can also define
+   protocols and interfaces that support IDNs directly using non-ASCII
+   representations.  IDNA does not prescribe any particular
+   representation for new protocols, but it still defines which names
+   are valid and how they are compared.)
+
+   The IDNA protocol is contained completely within applications.  It is
+   not a client-server or peer-to-peer protocol: everything is done
+   inside the application itself.  When used with a DNS resolver
+   library, IDNA is inserted as a "shim" between the application and the
+   resolver library.  When used for writing names into a DNS zone, IDNA
+   is used just before the name is committed to the zone.
+
+   There are two operations described in section 4 of this document:
+
+   -  The ToASCII operation is used before sending an IDN to something
+      that expects ASCII names (such as a resolver) or writing an IDN
+      into a place that expects ASCII names (such as a DNS master file).
+
+   -  The ToUnicode operation is used when displaying names to users,
+      for example names obtained from a DNS zone.
+
+   It is important to note that the ToASCII operation can fail.  If it
+   fails when processing a domain name, that domain name cannot be used
+   as an internationalized domain name and the application has to have
+   some method of dealing with this failure.
+
+   IDNA requires that implementations process input strings with
+   Nameprep [NAMEPREP], which is a profile of Stringprep [STRINGPREP],
+   and then with Punycode [PUNYCODE].  Implementations of IDNA MUST
+
+
+
+Faltstrom, et al.           Standards Track                     [Page 4]
+
+RFC 3490                          IDNA                        March 2003
+
+
+   fully implement Nameprep and Punycode; neither Nameprep nor Punycode
+   are optional.
+
+2. Terminology
+
+   The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED",
+   and "MAY" in this document are to be interpreted as described in BCP
+   14, RFC 2119 [RFC2119].
+
+   A code point is an integer value associated with a character in a
+   coded character set.
+
+   Unicode [UNICODE] is a coded character set containing tens of
+   thousands of characters.  A single Unicode code point is denoted by
+   "U+" followed by four to six hexadecimal digits, while a range of
+   Unicode code points is denoted by two hexadecimal numbers separated
+   by "..", with no prefixes.
+
+   ASCII means US-ASCII [USASCII], a coded character set containing 128
+   characters associated with code points in the range 0..7F.  Unicode
+   is an extension of ASCII: it includes all the ASCII characters and
+   associates them with the same code points.
+
+   The term "LDH code points" is defined in this document to mean the
+   code points associated with ASCII letters, digits, and the hyphen-
+   minus; that is, U+002D, 30..39, 41..5A, and 61..7A. "LDH" is an
+   abbreviation for "letters, digits, hyphen".
+
+   [STD13] talks about "domain names" and "host names", but many people
+   use the terms interchangeably.  Further, because [STD13] was not
+   terribly clear, many people who are sure they know the exact
+   definitions of each of these terms disagree on the definitions.  In
+   this document the term "domain name" is used in general.  This
+   document explicitly cites [STD3] whenever referring to the host name
+   syntax restrictions defined therein.
+
+   A label is an individual part of a domain name.  Labels are usually
+   shown separated by dots; for example, the domain name
+   "www.example.com" is composed of three labels: "www", "example", and
+   "com".  (The zero-length root label described in [STD13], which can
+   be explicit as in "www.example.com." or implicit as in
+   "www.example.com", is not considered a label in this specification.)
+   IDNA extends the set of usable characters in labels that are text.
+   For the rest of this document, the term "label" is shorthand for
+   "text label", and "every label" means "every text label".
+
+
+
+
+
+
+Faltstrom, et al.           Standards Track                     [Page 5]
+
+RFC 3490                          IDNA                        March 2003
+
+
+   An "internationalized label" is a label to which the ToASCII
+   operation (see section 4) can be applied without failing (with the
+   UseSTD3ASCIIRules flag unset).  This implies that every ASCII label
+   that satisfies the [STD13] length restriction is an internationalized
+   label.  Therefore the term "internationalized label" is a
+   generalization, embracing both old ASCII labels and new non-ASCII
+   labels.  Although most Unicode characters can appear in
+   internationalized labels, ToASCII will fail for some input strings,
+   and such strings are not valid internationalized labels.
+
+   An "internationalized domain name" (IDN) is a domain name in which
+   every label is an internationalized label.  This implies that every
+   ASCII domain name is an IDN (which implies that it is possible for a
+   name to be an IDN without it containing any non-ASCII characters).
+   This document does not attempt to define an "internationalized host
+   name".  Just as has been the case with ASCII names, some DNS zone
+   administrators may impose restrictions, beyond those imposed by DNS
+   or IDNA, on the characters or strings that may be registered as
+   labels in their zones.  Such restrictions have no impact on the
+   syntax or semantics of DNS protocol messages; a query for a name that
+   matches no records will yield the same response regardless of the
+   reason why it is not in the zone.  Clients issuing queries or
+   interpreting responses cannot be assumed to have any knowledge of
+   zone-specific restrictions or conventions.
+
+   In IDNA, equivalence of labels is defined in terms of the ToASCII
+   operation, which constructs an ASCII form for a given label, whether
+   or not the label was already an ASCII label.  Labels are defined to
+   be equivalent if and only if their ASCII forms produced by ToASCII
+   match using a case-insensitive ASCII comparison.  ASCII labels
+   already have a notion of equivalence: upper case and lower case are
+   considered equivalent.  The IDNA notion of equivalence is an
+   extension of that older notion.  Equivalent labels in IDNA are
+   treated as alternate forms of the same label, just as "foo" and "Foo"
+   are treated as alternate forms of the same label.
+
+   To allow internationalized labels to be handled by existing
+   applications, IDNA uses an "ACE label" (ACE stands for ASCII
+   Compatible Encoding).  An ACE label is an internationalized label
+   that can be rendered in ASCII and is equivalent to an
+   internationalized label that cannot be rendered in ASCII.  Given any
+   internationalized label that cannot be rendered in ASCII, the ToASCII
+   operation will convert it to an equivalent ACE label (whereas an
+   ASCII label will be left unaltered by ToASCII).  ACE labels are
+   unsuitable for display to users.  The ToUnicode operation will
+   convert any label to an equivalent non-ACE label.  In fact, an ACE
+   label is formally defined to be any label that the ToUnicode
+   operation would alter (whereas non-ACE labels are left unaltered by
+
+
+
+Faltstrom, et al.           Standards Track                     [Page 6]
+
+RFC 3490                          IDNA                        March 2003
+
+
+   ToUnicode).  Every ACE label begins with the ACE prefix specified in
+   section 5.  The ToASCII and ToUnicode operations are specified in
+   section 4.
+
+   The "ACE prefix" is defined in this document to be a string of ASCII
+   characters that appears at the beginning of every ACE label.  It is
+   specified in section 5.
+
+   A "domain name slot" is defined in this document to be a protocol
+   element or a function argument or a return value (and so on)
+   explicitly designated for carrying a domain name.  Examples of domain
+   name slots include: the QNAME field of a DNS query; the name argument
+   of the gethostbyname() library function; the part of an email address
+   following the at-sign (@) in the From: field of an email message
+   header; and the host portion of the URI in the src attribute of an
+   HTML <IMG> tag.  General text that just happens to contain a domain
+   name is not a domain name slot; for example, a domain name appearing
+   in the plain text body of an email message is not occupying a domain
+   name slot.
+
+   An "IDN-aware domain name slot" is defined in this document to be a
+   domain name slot explicitly designated for carrying an
+   internationalized domain name as defined in this document.  The
+   designation may be static (for example, in the specification of the
+   protocol or interface) or dynamic (for example, as a result of
+   negotiation in an interactive session).
+
+   An "IDN-unaware domain name slot" is defined in this document to be
+   any domain name slot that is not an IDN-aware domain name slot.
+   Obviously, this includes any domain name slot whose specification
+   predates IDNA.
+
+3. Requirements and applicability
+
+3.1 Requirements
+
+   IDNA conformance means adherence to the following four requirements:
+
+   1) Whenever dots are used as label separators, the following
+      characters MUST be recognized as dots: U+002E (full stop), U+3002
+      (ideographic full stop), U+FF0E (fullwidth full stop), U+FF61
+      (halfwidth ideographic full stop).
+
+   2) Whenever a domain name is put into an IDN-unaware domain name slot
+      (see section 2), it MUST contain only ASCII characters.  Given an
+      internationalized domain name (IDN), an equivalent domain name
+      satisfying this requirement can be obtained by applying the
+
+
+
+
+Faltstrom, et al.           Standards Track                     [Page 7]
+
+RFC 3490                          IDNA                        March 2003
+
+
+      ToASCII operation (see section 4) to each label and, if dots are
+      used as label separators, changing all the label separators to
+      U+002E.
+
+   3) ACE labels obtained from domain name slots SHOULD be hidden from
+      users when it is known that the environment can handle the non-ACE
+      form, except when the ACE form is explicitly requested.  When it
+      is not known whether or not the environment can handle the non-ACE
+      form, the application MAY use the non-ACE form (which might fail,
+      such as by not being displayed properly), or it MAY use the ACE
+      form (which will look unintelligle to the user).  Given an
+      internationalized domain name, an equivalent domain name
+      containing no ACE labels can be obtained by applying the ToUnicode
+      operation (see section 4) to each label.  When requirements 2 and
+      3 both apply, requirement 2 takes precedence.
+
+   4) Whenever two labels are compared, they MUST be considered to match
+      if and only if they are equivalent, that is, their ASCII forms
+      (obtained by applying ToASCII) match using a case-insensitive
+      ASCII comparison.  Whenever two names are compared, they MUST be
+      considered to match if and only if their corresponding labels
+      match, regardless of whether the names use the same forms of label
+      separators.
+
+3.2 Applicability
+
+   IDNA is applicable to all domain names in all domain name slots
+   except where it is explicitly excluded.
+
+   This implies that IDNA is applicable to many protocols that predate
+   IDNA.  Note that IDNs occupying domain name slots in those protocols
+   MUST be in ASCII form (see section 3.1, requirement 2).
+
+3.2.1. DNS resource records
+
+   IDNA does not apply to domain names in the NAME and RDATA fields of
+   DNS resource records whose CLASS is not IN.  This exclusion applies
+   to every non-IN class, present and future, except where future
+   standards override this exclusion by explicitly inviting the use of
+   IDNA.
+
+   There are currently no other exclusions on the applicability of IDNA
+   to DNS resource records; it depends entirely on the CLASS, and not on
+   the TYPE.  This will remain true, even as new types are defined,
+   unless there is a compelling reason for a new type to complicate
+   matters by imposing type-specific rules.
+
+
+
+
+
+Faltstrom, et al.           Standards Track                     [Page 8]
+
+RFC 3490                          IDNA                        March 2003
+
+
+3.2.2. Non-domain-name data types stored in domain names
+
+   Although IDNA enables the representation of non-ASCII characters in
+   domain names, that does not imply that IDNA enables the
+   representation of non-ASCII characters in other data types that are
+   stored in domain names.  For example, an email address local part is
+   sometimes stored in a domain label (hostmaster@example.com would be
+   represented as hostmaster.example.com in the RDATA field of an SOA
+   record).  IDNA does not update the existing email standards, which
+   allow only ASCII characters in local parts.  Therefore, unless the
+   email standards are revised to invite the use of IDNA for local
+   parts, a domain label that holds the local part of an email address
+   SHOULD NOT begin with the ACE prefix, and even if it does, it is to
+   be interpreted literally as a local part that happens to begin with
+   the ACE prefix.
+
+4. Conversion operations
+
+   An application converts a domain name put into an IDN-unaware slot or
+   displayed to a user.  This section specifies the steps to perform in
+   the conversion, and the ToASCII and ToUnicode operations.
+
+   The input to ToASCII or ToUnicode is a single label that is a
+   sequence of Unicode code points (remember that all ASCII code points
+   are also Unicode code points).  If a domain name is represented using
+   a character set other than Unicode or US-ASCII, it will first need to
+   be transcoded to Unicode.
+
+   Starting from a whole domain name, the steps that an application
+   takes to do the conversions are:
+
+   1) Decide whether the domain name is a "stored string" or a "query
+      string" as described in [STRINGPREP].  If this conversion follows
+      the "queries" rule from [STRINGPREP], set the flag called
+      "AllowUnassigned".
+
+   2) Split the domain name into individual labels as described in
+      section 3.1.  The labels do not include the separator.
+
+   3) For each label, decide whether or not to enforce the restrictions
+      on ASCII characters in host names [STD3].  (Applications already
+      faced this choice before the introduction of IDNA, and can
+      continue to make the decision the same way they always have; IDNA
+      makes no new recommendations regarding this choice.)  If the
+      restrictions are to be enforced, set the flag called
+      "UseSTD3ASCIIRules" for that label.
+
+
+
+
+
+Faltstrom, et al.           Standards Track                     [Page 9]
+
+RFC 3490                          IDNA                        March 2003
+
+
+   4) Process each label with either the ToASCII or the ToUnicode
+      operation as appropriate.  Typically, you use the ToASCII
+      operation if you are about to put the name into an IDN-unaware
+      slot, and you use the ToUnicode operation if you are displaying
+      the name to a user; section 3.1 gives greater detail on the
+      applicable requirements.
+
+   5) If ToASCII was applied in step 4 and dots are used as label
+      separators, change all the label separators to U+002E (full stop).
+
+   The following two subsections define the ToASCII and ToUnicode
+   operations that are used in step 4.
+
+   This description of the protocol uses specific procedure names, names
+   of flags, and so on, in order to facilitate the specification of the
+   protocol.  These names, as well as the actual steps of the
+   procedures, are not required of an implementation.  In fact, any
+   implementation which has the same external behavior as specified in
+   this document conforms to this specification.
+
+4.1 ToASCII
+
+   The ToASCII operation takes a sequence of Unicode code points that
+   make up one label and transforms it into a sequence of code points in
+   the ASCII range (0..7F).  If ToASCII succeeds, the original sequence
+   and the resulting sequence are equivalent labels.
+
+   It is important to note that the ToASCII operation can fail.  ToASCII
+   fails if any step of it fails.  If any step of the ToASCII operation
+   fails on any label in a domain name, that domain name MUST NOT be
+   used as an internationalized domain name.  The method for dealing
+   with this failure is application-specific.
+
+   The inputs to ToASCII are a sequence of code points, the
+   AllowUnassigned flag, and the UseSTD3ASCIIRules flag.  The output of
+   ToASCII is either a sequence of ASCII code points or a failure
+   condition.
+
+   ToASCII never alters a sequence of code points that are all in the
+   ASCII range to begin with (although it could fail).  Applying the
+   ToASCII operation multiple times has exactly the same effect as
+   applying it just once.
+
+   ToASCII consists of the following steps:
+
+   1. If the sequence contains any code points outside the ASCII range
+      (0..7F) then proceed to step 2, otherwise skip to step 3.
+
+
+
+
+Faltstrom, et al.           Standards Track                    [Page 10]
+
+RFC 3490                          IDNA                        March 2003
+
+
+   2. Perform the steps specified in [NAMEPREP] and fail if there is an
+      error.  The AllowUnassigned flag is used in [NAMEPREP].
+
+   3. If the UseSTD3ASCIIRules flag is set, then perform these checks:
+
+     (a) Verify the absence of non-LDH ASCII code points; that is, the
+         absence of 0..2C, 2E..2F, 3A..40, 5B..60, and 7B..7F.
+
+     (b) Verify the absence of leading and trailing hyphen-minus; that
+         is, the absence of U+002D at the beginning and end of the
+         sequence.
+
+   4. If the sequence contains any code points outside the ASCII range
+      (0..7F) then proceed to step 5, otherwise skip to step 8.
+
+   5. Verify that the sequence does NOT begin with the ACE prefix.
+
+   6. Encode the sequence using the encoding algorithm in [PUNYCODE] and
+      fail if there is an error.
+
+   7. Prepend the ACE prefix.
+
+   8. Verify that the number of code points is in the range 1 to 63
+      inclusive.
+
+4.2 ToUnicode
+
+   The ToUnicode operation takes a sequence of Unicode code points that
+   make up one label and returns a sequence of Unicode code points.  If
+   the input sequence is a label in ACE form, then the result is an
+   equivalent internationalized label that is not in ACE form, otherwise
+   the original sequence is returned unaltered.
+
+   ToUnicode never fails.  If any step fails, then the original input
+   sequence is returned immediately in that step.
+
+   The ToUnicode output never contains more code points than its input.
+   Note that the number of octets needed to represent a sequence of code
+   points depends on the particular character encoding used.
+
+   The inputs to ToUnicode are a sequence of code points, the
+   AllowUnassigned flag, and the UseSTD3ASCIIRules flag.  The output of
+   ToUnicode is always a sequence of Unicode code points.
+
+   1. If all code points in the sequence are in the ASCII range (0..7F)
+      then skip to step 3.
+
+
+
+
+
+Faltstrom, et al.           Standards Track                    [Page 11]
+
+RFC 3490                          IDNA                        March 2003
+
+
+   2. Perform the steps specified in [NAMEPREP] and fail if there is an
+      error.  (If step 3 of ToASCII is also performed here, it will not
+      affect the overall behavior of ToUnicode, but it is not
+      necessary.)  The AllowUnassigned flag is used in [NAMEPREP].
+
+   3. Verify that the sequence begins with the ACE prefix, and save a
+      copy of the sequence.
+
+   4. Remove the ACE prefix.
+
+   5. Decode the sequence using the decoding algorithm in [PUNYCODE] and
+      fail if there is an error.  Save a copy of the result of this
+      step.
+
+   6. Apply ToASCII.
+
+   7. Verify that the result of step 6 matches the saved copy from step
+      3, using a case-insensitive ASCII comparison.
+
+   8. Return the saved copy from step 5.
+
+5. ACE prefix
+
+   The ACE prefix, used in the conversion operations (section 4), is two
+   alphanumeric ASCII characters followed by two hyphen-minuses.  It
+   cannot be any of the prefixes already used in earlier documents,
+   which includes the following: "bl--", "bq--", "dq--", "lq--", "mq--",
+   "ra--", "wq--" and "zq--".  The ToASCII and ToUnicode operations MUST
+   recognize the ACE prefix in a case-insensitive manner.
+
+   The ACE prefix for IDNA is "xn--" or any capitalization thereof.
+
+   This means that an ACE label might be "xn--de-jg4avhby1noc0d", where
+   "de-jg4avhby1noc0d" is the part of the ACE label that is generated by
+   the encoding steps in [PUNYCODE].
+
+   While all ACE labels begin with the ACE prefix, not all labels
+   beginning with the ACE prefix are necessarily ACE labels.  Non-ACE
+   labels that begin with the ACE prefix will confuse users and SHOULD
+   NOT be allowed in DNS zones.
+
+
+
+
+
+
+
+
+
+
+
+Faltstrom, et al.           Standards Track                    [Page 12]
+
+RFC 3490                          IDNA                        March 2003
+
+
+6. Implications for typical applications using DNS
+
+   In IDNA, applications perform the processing needed to input
+   internationalized domain names from users, display internationalized
+   domain names to users, and process the inputs and outputs from DNS
+   and other protocols that carry domain names.
+
+   The components and interfaces between them can be represented
+   pictorially as:
+
+                    +------+
+                    | User |
+                    +------+
+                       ^
+                       | Input and display: local interface methods
+                       | (pen, keyboard, glowing phosphorus, ...)
+   +-------------------|-------------------------------+
+   |                   v                               |
+   |          +-----------------------------+          |
+   |          |        Application          |          |
+   |          |   (ToASCII and ToUnicode    |          |
+   |          |      operations may be      |          |
+   |          |        called here)         |          |
+   |          +-----------------------------+          |
+   |                   ^        ^                      | End system
+   |                   |        |                      |
+   | Call to resolver: |        | Application-specific |
+   |              ACE  |        | protocol:            |
+   |                   v        | ACE unless the       |
+   |           +----------+     | protocol is updated  |
+   |           | Resolver |     | to handle other      |
+   |           +----------+     | encodings            |
+   |                 ^          |                      |
+   +-----------------|----------|----------------------+
+       DNS protocol: |          |
+                 ACE |          |
+                     v          v
+          +-------------+    +---------------------+
+          | DNS servers |    | Application servers |
+          +-------------+    +---------------------+
+
+   The box labeled "Application" is where the application splits a
+   domain name into labels, sets the appropriate flags, and performs the
+   ToASCII and ToUnicode operations.  This is described in section 4.
+
+
+
+
+
+
+
+Faltstrom, et al.           Standards Track                    [Page 13]
+
+RFC 3490                          IDNA                        March 2003
+
+
+6.1 Entry and display in applications
+
+   Applications can accept domain names using any character set or sets
+   desired by the application developer, and can display domain names in
+   any charset.  That is, the IDNA protocol does not affect the
+   interface between users and applications.
+
+   An IDNA-aware application can accept and display internationalized
+   domain names in two formats: the internationalized character set(s)
+   supported by the application, and as an ACE label.  ACE labels that
+   are displayed or input MUST always include the ACE prefix.
+   Applications MAY allow input and display of ACE labels, but are not
+   encouraged to do so except as an interface for special purposes,
+   possibly for debugging, or to cope with display limitations as
+   described in section 6.4..  ACE encoding is opaque and ugly, and
+   should thus only be exposed to users who absolutely need it.  Because
+   name labels encoded as ACE name labels can be rendered either as the
+   encoded ASCII characters or the proper decoded characters, the
+   application MAY have an option for the user to select the preferred
+   method of display; if it does, rendering the ACE SHOULD NOT be the
+   default.
+
+   Domain names are often stored and transported in many places.  For
+   example, they are part of documents such as mail messages and web
+   pages.  They are transported in many parts of many protocols, such as
+   both the control commands and the RFC 2822 body parts of SMTP, and
+   the headers and the body content in HTTP.  It is important to
+   remember that domain names appear both in domain name slots and in
+   the content that is passed over protocols.
+
+   In protocols and document formats that define how to handle
+   specification or negotiation of charsets, labels can be encoded in
+   any charset allowed by the protocol or document format.  If a
+   protocol or document format only allows one charset, the labels MUST
+   be given in that charset.
+
+   In any place where a protocol or document format allows transmission
+   of the characters in internationalized labels, internationalized
+   labels SHOULD be transmitted using whatever character encoding and
+   escape mechanism that the protocol or document format uses at that
+   place.
+
+   All protocols that use domain name slots already have the capacity
+   for handling domain names in the ASCII charset.  Thus, ACE labels
+   (internationalized labels that have been processed with the ToASCII
+   operation) can inherently be handled by those protocols.
+
+
+
+
+
+Faltstrom, et al.           Standards Track                    [Page 14]
+
+RFC 3490                          IDNA                        March 2003
+
+
+6.2 Applications and resolver libraries
+
+   Applications normally use functions in the operating system when they
+   resolve DNS queries.  Those functions in the operating system are
+   often called "the resolver library", and the applications communicate
+   with the resolver libraries through a programming interface (API).
+
+   Because these resolver libraries today expect only domain names in
+   ASCII, applications MUST prepare labels that are passed to the
+   resolver library using the ToASCII operation.  Labels received from
+   the resolver library contain only ASCII characters; internationalized
+   labels that cannot be represented directly in ASCII use the ACE form.
+   ACE labels always include the ACE prefix.
+
+   An operating system might have a set of libraries for performing the
+   ToASCII operation.  The input to such a library might be in one or
+   more charsets that are used in applications (UTF-8 and UTF-16 are
+   likely candidates for almost any operating system, and script-
+   specific charsets are likely for localized operating systems).
+
+   IDNA-aware applications MUST be able to work with both non-
+   internationalized labels (those that conform to [STD13] and [STD3])
+   and internationalized labels.
+
+   It is expected that new versions of the resolver libraries in the
+   future will be able to accept domain names in other charsets than
+   ASCII, and application developers might one day pass not only domain
+   names in Unicode, but also in local script to a new API for the
+   resolver libraries in the operating system.  Thus the ToASCII and
+   ToUnicode operations might be performed inside these new versions of
+   the resolver libraries.
+
+   Domain names passed to resolvers or put into the question section of
+   DNS requests follow the rules for "queries" from [STRINGPREP].
+
+6.3 DNS servers
+
+   Domain names stored in zones follow the rules for "stored strings"
+   from [STRINGPREP].
+
+   For internationalized labels that cannot be represented directly in
+   ASCII, DNS servers MUST use the ACE form produced by the ToASCII
+   operation.  All IDNs served by DNS servers MUST contain only ASCII
+   characters.
+
+   If a signaling system which makes negotiation possible between old
+   and new DNS clients and servers is standardized in the future, the
+   encoding of the query in the DNS protocol itself can be changed from
+
+
+
+Faltstrom, et al.           Standards Track                    [Page 15]
+
+RFC 3490                          IDNA                        March 2003
+
+
+   ACE to something else, such as UTF-8.  The question whether or not
+   this should be used is, however, a separate problem and is not
+   discussed in this memo.
+
+6.4 Avoiding exposing users to the raw ACE encoding
+
+   Any application that might show the user a domain name obtained from
+   a domain name slot, such as from gethostbyaddr or part of a mail
+   header, will need to be updated if it is to prevent users from seeing
+   the ACE.
+
+   If an application decodes an ACE name using ToUnicode but cannot show
+   all of the characters in the decoded name, such as if the name
+   contains characters that the output system cannot display, the
+   application SHOULD show the name in ACE format (which always includes
+   the ACE prefix) instead of displaying the name with the replacement
+   character (U+FFFD).  This is to make it easier for the user to
+   transfer the name correctly to other programs.  Programs that by
+   default show the ACE form when they cannot show all the characters in
+   a name label SHOULD also have a mechanism to show the name that is
+   produced by the ToUnicode operation with as many characters as
+   possible and replacement characters in the positions where characters
+   cannot be displayed.
+
+   The ToUnicode operation does not alter labels that are not valid ACE
+   labels, even if they begin with the ACE prefix.  After ToUnicode has
+   been applied, if a label still begins with the ACE prefix, then it is
+   not a valid ACE label, and is not equivalent to any of the
+   intermediate Unicode strings constructed by ToUnicode.
+
+6.5  DNSSEC authentication of IDN domain names
+
+   DNS Security [RFC2535] is a method for supplying cryptographic
+   verification information along with DNS messages.  Public Key
+   Cryptography is used in conjunction with digital signatures to
+   provide a means for a requester of domain information to authenticate
+   the source of the data.  This ensures that it can be traced back to a
+   trusted source, either directly, or via a chain of trust linking the
+   source of the information to the top of the DNS hierarchy.
+
+   IDNA specifies that all internationalized domain names served by DNS
+   servers that cannot be represented directly in ASCII must use the ACE
+   form produced by the ToASCII operation.  This operation must be
+   performed prior to a zone being signed by the private key for that
+   zone.  Because of this ordering, it is important to recognize that
+   DNSSEC authenticates the ASCII domain name, not the Unicode form or
+
+
+
+
+
+Faltstrom, et al.           Standards Track                    [Page 16]
+
+RFC 3490                          IDNA                        March 2003
+
+
+   the mapping between the Unicode form and the ASCII form.  In the
+   presence of DNSSEC, this is the name that MUST be signed in the zone
+   and MUST be validated against.
+
+   One consequence of this for sites deploying IDNA in the presence of
+   DNSSEC is that any special purpose proxies or forwarders used to
+   transform user input into IDNs must be earlier in the resolution flow
+   than DNSSEC authenticating nameservers for DNSSEC to work.
+
+7. Name server considerations
+
+   Existing DNS servers do not know the IDNA rules for handling non-
+   ASCII forms of IDNs, and therefore need to be shielded from them.
+   All existing channels through which names can enter a DNS server
+   database (for example, master files [STD13] and DNS update messages
+   [RFC2136]) are IDN-unaware because they predate IDNA, and therefore
+   requirement 2 of section 3.1 of this document provides the needed
+   shielding, by ensuring that internationalized domain names entering
+   DNS server databases through such channels have already been
+   converted to their equivalent ASCII forms.
+
+   It is imperative that there be only one ASCII encoding for a
+   particular domain name.  Because of the design of the ToASCII and
+   ToUnicode operations, there are no ACE labels that decode to ASCII
+   labels, and therefore name servers cannot contain multiple ASCII
+   encodings of the same domain name.
+
+   [RFC2181] explicitly allows domain labels to contain octets beyond
+   the ASCII range (0..7F), and this document does not change that.
+   Note, however, that there is no defined interpretation of octets
+   80..FF as characters.  If labels containing these octets are returned
+   to applications, unpredictable behavior could result.  The ASCII form
+   defined by ToASCII is the only standard representation for
+   internationalized labels in the current DNS protocol.
+
+8. Root server considerations
+
+   IDNs are likely to be somewhat longer than current domain names, so
+   the bandwidth needed by the root servers is likely to go up by a
+   small amount.  Also, queries and responses for IDNs will probably be
+   somewhat longer than typical queries today, so more queries and
+   responses may be forced to go to TCP instead of UDP.
+
+
+
+
+
+
+
+
+
+Faltstrom, et al.           Standards Track                    [Page 17]
+
+RFC 3490                          IDNA                        March 2003
+
+
+9. References
+
+9.1 Normative References
+
+   [RFC2119]    Bradner, S., "Key words for use in RFCs to Indicate
+                Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [STRINGPREP] Hoffman, P. and M. Blanchet, "Preparation of
+                Internationalized Strings ("stringprep")", RFC 3454,
+                December 2002.
+
+   [NAMEPREP]   Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep
+                Profile for Internationalized Domain Names (IDN)", RFC
+                3491, March 2003.
+
+   [PUNYCODE]   Costello, A., "Punycode: A Bootstring encoding of
+                Unicode for use with Internationalized Domain Names in
+                Applications (IDNA)", RFC 3492, March 2003.
+
+   [STD3]       Braden, R., "Requirements for Internet Hosts --
+                Communication Layers", STD 3, RFC 1122, and
+                "Requirements for Internet Hosts -- Application and
+                Support", STD 3, RFC 1123, October 1989.
+
+   [STD13]      Mockapetris, P., "Domain names - concepts and
+                facilities", STD 13, RFC 1034 and "Domain names -
+                implementation and specification", STD 13, RFC 1035,
+                November 1987.
+
+9.2 Informative References
+
+   [RFC2535]    Eastlake, D., "Domain Name System Security Extensions",
+                RFC 2535, March 1999.
+
+   [RFC2181]    Elz, R. and R. Bush, "Clarifications to the DNS
+                Specification", RFC 2181, July 1997.
+
+   [UAX9]       Unicode Standard Annex #9, The Bidirectional Algorithm,
+                <http://www.unicode.org/unicode/reports/tr9/>.
+
+   [UNICODE]    The Unicode Consortium. The Unicode Standard, Version
+                3.2.0 is defined by The Unicode Standard, Version 3.0
+                (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5),
+                as amended by the Unicode Standard Annex #27: Unicode
+                3.1 (http://www.unicode.org/reports/tr27/) and by the
+                Unicode Standard Annex #28: Unicode 3.2
+                (http://www.unicode.org/reports/tr28/).
+
+
+
+
+Faltstrom, et al.           Standards Track                    [Page 18]
+
+RFC 3490                          IDNA                        March 2003
+
+
+   [USASCII]    Cerf, V., "ASCII format for Network Interchange", RFC
+                20, October 1969.
+
+10. Security Considerations
+
+   Security on the Internet partly relies on the DNS.  Thus, any change
+   to the characteristics of the DNS can change the security of much of
+   the Internet.
+
+   This memo describes an algorithm which encodes characters that are
+   not valid according to STD3 and STD13 into octet values that are
+   valid.  No security issues such as string length increases or new
+   allowed values are introduced by the encoding process or the use of
+   these encoded values, apart from those introduced by the ACE encoding
+   itself.
+
+   Domain names are used by users to identify and connect to Internet
+   servers.  The security of the Internet is compromised if a user
+   entering a single internationalized name is connected to different
+   servers based on different interpretations of the internationalized
+   domain name.
+
+   When systems use local character sets other than ASCII and Unicode,
+   this specification leaves the the problem of transcoding between the
+   local character set and Unicode up to the application.  If different
+   applications (or different versions of one application) implement
+   different transcoding rules, they could interpret the same name
+   differently and contact different servers.  This problem is not
+   solved by security protocols like TLS that do not take local
+   character sets into account.
+
+   Because this document normatively refers to [NAMEPREP], [PUNYCODE],
+   and [STRINGPREP], it includes the security considerations from those
+   documents as well.
+
+   If or when this specification is updated to use a more recent Unicode
+   normalization table, the new normalization table will need to be
+   compared with the old to spot backwards incompatible changes.  If
+   there are such changes, they will need to be handled somehow, or
+   there will be security as well as operational implications.  Methods
+   to handle the conflicts could include keeping the old normalization,
+   or taking care of the conflicting characters by operational means, or
+   some other method.
+
+   Implementations MUST NOT use more recent normalization tables than
+   the one referenced from this document, even though more recent tables
+   may be provided by operating systems.  If an application is unsure of
+   which version of the normalization tables are in the operating
+
+
+
+Faltstrom, et al.           Standards Track                    [Page 19]
+
+RFC 3490                          IDNA                        March 2003
+
+
+   system, the application needs to include the normalization tables
+   itself.  Using normalization tables other than the one referenced
+   from this specification could have security and operational
+   implications.
+
+   To help prevent confusion between characters that are visually
+   similar, it is suggested that implementations provide visual
+   indications where a domain name contains multiple scripts.  Such
+   mechanisms can also be used to show when a name contains a mixture of
+   simplified and traditional Chinese characters, or to distinguish zero
+   and one from O and l.  DNS zone adminstrators may impose restrictions
+   (subject to the limitations in section 2) that try to minimize
+   homographs.
+
+   Domain names (or portions of them) are sometimes compared against a
+   set of privileged or anti-privileged domains.  In such situations it
+   is especially important that the comparisons be done properly, as
+   specified in section 3.1 requirement 4.  For labels already in ASCII
+   form, the proper comparison reduces to the same case-insensitive
+   ASCII comparison that has always been used for ASCII labels.
+
+   The introduction of IDNA means that any existing labels that start
+   with the ACE prefix and would be altered by ToUnicode will
+   automatically be ACE labels, and will be considered equivalent to
+   non-ASCII labels, whether or not that was the intent of the zone
+   adminstrator or registrant.
+
+11. IANA Considerations
+
+   IANA has assigned the ACE prefix in consultation with the IESG.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Faltstrom, et al.           Standards Track                    [Page 20]
+
+RFC 3490                          IDNA                        March 2003
+
+
+12. Authors' Addresses
+
+   Patrik Faltstrom
+   Cisco Systems
+   Arstaangsvagen 31 J
+   S-117 43 Stockholm  Sweden
+
+   EMail: paf@cisco.com
+
+
+   Paul Hoffman
+   Internet Mail Consortium and VPN Consortium
+   127 Segre Place
+   Santa Cruz, CA  95060  USA
+
+   EMail: phoffman@imc.org
+
+
+   Adam M. Costello
+   University of California, Berkeley
+
+   URL: http://www.nicemice.net/amc/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Faltstrom, et al.           Standards Track                    [Page 21]
+
+RFC 3490                          IDNA                        March 2003
+
+
+13. Full Copyright Statement
+
+   Copyright (C) The Internet Society (2003).  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 Standards process must be
+   followed, or as required to translate it into 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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Faltstrom, et al.           Standards Track                    [Page 22]
+
diff --git a/doc/rfc/rfc3491.txt b/doc/rfc/rfc3491.txt
new file mode 100644
index 0000000..dbc86c7
--- /dev/null
+++ b/doc/rfc/rfc3491.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+Network Working Group                                         P. Hoffman
+Request for Comments: 3491                                    IMC & VPNC
+Category: Standards Track                                    M. Blanchet
+                                                                Viagenie
+                                                              March 2003
+
+
+                   Nameprep: A Stringprep Profile for
+                  Internationalized Domain Names (IDN)
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2003).  All Rights Reserved.
+
+Abstract
+
+   This document describes how to prepare internationalized domain name
+   (IDN) labels in order to increase the likelihood that name input and
+   name comparison work in ways that make sense for typical users
+   throughout the world.  This profile of the stringprep protocol is
+   used as part of a suite of on-the-wire protocols for
+   internationalizing the Domain Name System (DNS).
+
+1. Introduction
+
+   This document specifies processing rules that will allow users to
+   enter internationalized domain names (IDNs) into applications and
+   have the highest chance of getting the content of the strings
+   correct.  It is a profile of stringprep [STRINGPREP].  These
+   processing rules are only intended for internationalized domain
+   names, not for arbitrary text.
+
+   This profile defines the following, as required by [STRINGPREP].
+
+   -  The intended applicability of the profile: internationalized
+      domain names processed by IDNA.
+
+   -  The character repertoire that is the input and output to
+      stringprep:  Unicode 3.2, specified in section 2.
+
+
+
+
+Hoffman & Blanchet          Standards Track                     [Page 1]
+
+RFC 3491                      IDN Nameprep                    March 2003
+
+
+   -  The mappings used: specified in section 3.
+
+   -  The Unicode normalization used: specified in section 4.
+
+   -  The characters that are prohibited as output: specified in section
+      5.
+
+   -  Bidirectional character handling: specified in section 6.
+
+1.1 Interaction of protocol parts
+
+   Nameprep is used by the IDNA [IDNA] protocol for preparing domain
+   names; it is not designed for any other purpose.  It is explicitly
+   not designed for processing arbitrary free text and SHOULD NOT be
+   used for that purpose.  Nameprep is a profile of Stringprep
+   [STRINGPREP].  Implementations of Nameprep MUST fully implement
+   Stringprep.
+
+   Nameprep is used to process domain name labels, not domain names.
+   IDNA calls nameprep for each label in a domain name, not for the
+   whole domain name.
+
+1.2 Terminology
+
+   The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
+   in this document are to be interpreted as described in BCP 14, RFC
+   2119 [RFC2119].
+
+2. Character Repertoire
+
+   This profile uses Unicode 3.2, as defined in [STRINGPREP] Appendix A.
+
+3. Mapping
+
+   This profile specifies mapping using the following tables from
+   [STRINGPREP]:
+
+   Table B.1
+   Table B.2
+
+4. Normalization
+
+   This profile specifies using Unicode normalization form KC, as
+   described in [STRINGPREP].
+
+
+
+
+
+
+
+Hoffman & Blanchet          Standards Track                     [Page 2]
+
+RFC 3491                      IDN Nameprep                    March 2003
+
+
+5. Prohibited Output
+
+   This profile specifies prohibiting using the following tables from
+   [STRINGPREP]:
+
+   Table C.1.2
+   Table C.2.2
+   Table C.3
+   Table C.4
+   Table C.5
+   Table C.6
+   Table C.7
+   Table C.8
+   Table C.9
+
+   IMPORTANT NOTE: This profile MUST be used with the IDNA protocol.
+   The IDNA protocol has additional prohibitions that are checked
+   outside of this profile.
+
+6. Bidirectional characters
+
+   This profile specifies checking bidirectional strings as described in
+   [STRINGPREP] section 6.
+
+7. Unassigned Code Points in Internationalized Domain Names
+
+   If the processing in [IDNA] specifies that a list of unassigned code
+   points be used, the system uses table A.1 from [STRINGPREP] as its
+   list of unassigned code points.
+
+8. References
+
+8.1 Normative References
+
+   [RFC2119]    Bradner, S., "Key words for use in RFCs to Indicate
+                Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [STRINGPREP] Hoffman, P. and M. Blanchet, "Preparation of
+                Internationalized Strings ("stringprep")", RFC 3454,
+                December 2002.
+
+   [IDNA]       Faltstrom, P., Hoffman, P. and A. Costello,
+                "Internationalizing Domain Names in Applications
+                (IDNA)", RFC 3490, March 2003.
+
+
+
+
+
+
+
+Hoffman & Blanchet          Standards Track                     [Page 3]
+
+RFC 3491                      IDN Nameprep                    March 2003
+
+
+8.2 Informative references
+
+   [STD13]      Mockapetris, P., "Domain names - concepts and
+                facilities", STD 13, RFC 1034, and "Domain names -
+                implementation and specification", STD 13, RFC 1035,
+                November 1987.
+
+9. Security Considerations
+
+   The Unicode and ISO/IEC 10646 repertoires have many characters that
+   look similar.  In many cases, users of security protocols might do
+   visual matching, such as when comparing the names of trusted third
+   parties.  Because it is impossible to map similar-looking characters
+   without a great deal of context such as knowing the fonts used,
+   stringprep does nothing to map similar-looking characters together
+   nor to prohibit some characters because they look like others.
+
+   Security on the Internet partly relies on the DNS.  Thus, any change
+   to the characteristics of the DNS can change the security of much of
+   the Internet.
+
+   Domain names are used by users to connect to Internet servers.  The
+   security of the Internet would be compromised if a user entering a
+   single internationalized name could be connected to different servers
+   based on different interpretations of the internationalized domain
+   name.
+
+   Current applications might assume that the characters allowed in
+   domain names will always be the same as they are in [STD13].  This
+   document vastly increases the number of characters available in
+   domain names.  Every program that uses "special" characters in
+   conjunction with domain names may be vulnerable to attack based on
+   the new characters allowed by this specification.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hoffman & Blanchet          Standards Track                     [Page 4]
+
+RFC 3491                      IDN Nameprep                    March 2003
+
+
+10. IANA Considerations
+
+   This is a profile of stringprep.  It has been registered by the IANA
+   in the stringprep profile registry
+   (www.iana.org/assignments/stringprep-profiles).
+
+      Name of this profile:
+         Nameprep
+
+      RFC in which the profile is defined:
+         This document.
+
+      Indicator whether or not this is the newest version of the
+      profile:
+         This is the first version of Nameprep.
+
+11. Acknowledgements
+
+   Many people from the IETF IDN Working Group and the Unicode Technical
+   Committee contributed ideas that went into this document.
+
+   The IDN Nameprep design team made many useful changes to the
+   document.  That team and its advisors include:
+
+      Asmus Freytag
+      Cathy Wissink
+      Francois Yergeau
+      James Seng
+      Marc Blanchet
+      Mark Davis
+      Martin Duerst
+      Patrik Faltstrom
+      Paul Hoffman
+
+   Additional significant improvements were proposed by:
+
+      Jonathan Rosenne
+      Kent Karlsson
+      Scott Hollenbeck
+      Dave Crocker
+      Erik Nordmark
+      Matitiahu Allouche
+
+
+
+
+
+
+
+
+
+Hoffman & Blanchet          Standards Track                     [Page 5]
+
+RFC 3491                      IDN Nameprep                    March 2003
+
+
+12. Authors' Addresses
+
+   Paul Hoffman
+   Internet Mail Consortium and VPN Consortium
+   127 Segre Place
+   Santa Cruz, CA  95060 USA
+
+   EMail: paul.hoffman@imc.org and paul.hoffman@vpnc.org
+
+
+   Marc Blanchet
+   Viagenie inc.
+   2875 boul. Laurier, bur. 300
+   Ste-Foy, Quebec, Canada, G1V 2M2
+
+   EMail: Marc.Blanchet@viagenie.qc.ca
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hoffman & Blanchet          Standards Track                     [Page 6]
+
+RFC 3491                      IDN Nameprep                    March 2003
+
+
+13.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2003).  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 Standards process must be
+   followed, or as required to translate it into 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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hoffman & Blanchet          Standards Track                     [Page 7]
+
diff --git a/doc/rfc/rfc3492.txt b/doc/rfc/rfc3492.txt
new file mode 100644
index 0000000..e72ad81
--- /dev/null
+++ b/doc/rfc/rfc3492.txt
@@ -0,0 +1,1963 @@
+
+
+
+
+
+
+Network Working Group                                        A. Costello
+Request for Comments: 3492                 Univ. of California, Berkeley
+Category: Standards Track                                     March 2003
+
+
+              Punycode: A Bootstring encoding of Unicode
+       for Internationalized Domain Names in Applications (IDNA)
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2003).  All Rights Reserved.
+
+Abstract
+
+   Punycode is a simple and efficient transfer encoding syntax designed
+   for use with Internationalized Domain Names in Applications (IDNA).
+   It uniquely and reversibly transforms a Unicode string into an ASCII
+   string.  ASCII characters in the Unicode string are represented
+   literally, and non-ASCII characters are represented by ASCII
+   characters that are allowed in host name labels (letters, digits, and
+   hyphens).  This document defines a general algorithm called
+   Bootstring that allows a string of basic code points to uniquely
+   represent any string of code points drawn from a larger set.
+   Punycode is an instance of Bootstring that uses particular parameter
+   values specified by this document, appropriate for IDNA.
+
+Table of Contents
+
+   1. Introduction...............................................2
+       1.1 Features..............................................2
+       1.2 Interaction of protocol parts.........................3
+   2. Terminology................................................3
+   3. Bootstring description.....................................4
+       3.1 Basic code point segregation..........................4
+       3.2 Insertion unsort coding...............................4
+       3.3 Generalized variable-length integers..................5
+       3.4 Bias adaptation.......................................7
+   4. Bootstring parameters......................................8
+   5. Parameter values for Punycode..............................8
+   6. Bootstring algorithms......................................9
+
+
+
+Costello                    Standards Track                     [Page 1]
+
+RFC 3492                     IDNA Punycode                    March 2003
+
+
+       6.1 Bias adaptation function.............................10
+       6.2 Decoding procedure...................................11
+       6.3 Encoding procedure...................................12
+       6.4 Overflow handling....................................13
+   7. Punycode examples.........................................14
+       7.1 Sample strings.......................................14
+       7.2 Decoding traces......................................17
+       7.3 Encoding traces......................................19
+   8. Security Considerations...................................20
+   9. References................................................21
+       9.1 Normative References.................................21
+       9.2 Informative References...............................21
+   A. Mixed-case annotation.....................................22
+   B. Disclaimer and license....................................22
+   C. Punycode sample implementation............................23
+   Author's Address.............................................34
+   Full Copyright Statement.....................................35
+
+1. Introduction
+
+   [IDNA] describes an architecture for supporting internationalized
+   domain names.  Labels containing non-ASCII characters can be
+   represented by ACE labels, which begin with a special ACE prefix and
+   contain only ASCII characters.  The remainder of the label after the
+   prefix is a Punycode encoding of a Unicode string satisfying certain
+   constraints.  For the details of the prefix and constraints, see
+   [IDNA] and [NAMEPREP].
+
+   Punycode is an instance of a more general algorithm called
+   Bootstring, which allows strings composed from a small set of "basic"
+   code points to uniquely represent any string of code points drawn
+   from a larger set.  Punycode is Bootstring with particular parameter
+   values appropriate for IDNA.
+
+1.1 Features
+
+   Bootstring has been designed to have the following features:
+
+   *  Completeness:  Every extended string (sequence of arbitrary code
+      points) can be represented by a basic string (sequence of basic
+      code points).  Restrictions on what strings are allowed, and on
+      length, can be imposed by higher layers.
+
+   *  Uniqueness:  There is at most one basic string that represents a
+      given extended string.
+
+   *  Reversibility:  Any extended string mapped to a basic string can
+      be recovered from that basic string.
+
+
+
+Costello                    Standards Track                     [Page 2]
+
+RFC 3492                     IDNA Punycode                    March 2003
+
+
+   *  Efficient encoding:  The ratio of basic string length to extended
+      string length is small.  This is important in the context of
+      domain names because RFC 1034 [RFC1034] restricts the length of a
+      domain label to 63 characters.
+
+   *  Simplicity:  The encoding and decoding algorithms are reasonably
+      simple to implement.  The goals of efficiency and simplicity are
+      at odds; Bootstring aims at a good balance between them.
+
+   *  Readability:  Basic code points appearing in the extended string
+      are represented as themselves in the basic string (although the
+      main purpose is to improve efficiency, not readability).
+
+   Punycode can also support an additional feature that is not used by
+   the ToASCII and ToUnicode operations of [IDNA].  When extended
+   strings are case-folded prior to encoding, the basic string can use
+   mixed case to tell how to convert the folded string into a mixed-case
+   string.  See appendix A "Mixed-case annotation".
+
+1.2 Interaction of protocol parts
+
+   Punycode is used by the IDNA protocol [IDNA] for converting domain
+   labels into ASCII; it is not designed for any other purpose.  It is
+   explicitly not designed for processing arbitrary free text.
+
+2. Terminology
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in BCP 14, RFC 2119
+   [RFC2119].
+
+   A code point is an integral value associated with a character in a
+   coded character set.
+
+   As in the Unicode Standard [UNICODE], Unicode code points are denoted
+   by "U+" followed by four to six hexadecimal digits, while a range of
+   code points is denoted by two hexadecimal numbers separated by "..",
+   with no prefixes.
+
+   The operators div and mod perform integer division; (x div y) is the
+   quotient of x divided by y, discarding the remainder, and (x mod y)
+   is the remainder, so (x div y) * y + (x mod y) == x.  Bootstring uses
+   these operators only with nonnegative operands, so the quotient and
+   remainder are always nonnegative.
+
+   The break statement jumps out of the innermost loop (as in C).
+
+
+
+
+Costello                    Standards Track                     [Page 3]
+
+RFC 3492                     IDNA Punycode                    March 2003
+
+
+   An overflow is an attempt to compute a value that exceeds the maximum
+   value of an integer variable.
+
+3. Bootstring description
+
+   Bootstring represents an arbitrary sequence of code points (the
+   "extended string") as a sequence of basic code points (the "basic
+   string").  This section describes the representation.  Section 6
+   "Bootstring algorithms" presents the algorithms as pseudocode.
+   Sections 7.1 "Decoding traces" and 7.2 "Encoding traces" trace the
+   algorithms for sample inputs.
+
+   The following sections describe the four techniques used in
+   Bootstring.  "Basic code point segregation" is a very simple and
+   efficient encoding for basic code points occurring in the extended
+   string: they are simply copied all at once.  "Insertion unsort
+   coding" encodes the non-basic code points as deltas, and processes
+   the code points in numerical order rather than in order of
+   appearance, which typically results in smaller deltas.  The deltas
+   are represented as "generalized variable-length integers", which use
+   basic code points to represent nonnegative integers.  The parameters
+   of this integer representation are dynamically adjusted using "bias
+   adaptation", to improve efficiency when consecutive deltas have
+   similar magnitudes.
+
+3.1 Basic code point segregation
+
+   All basic code points appearing in the extended string are
+   represented literally at the beginning of the basic string, in their
+   original order, followed by a delimiter if (and only if) the number
+   of basic code points is nonzero.  The delimiter is a particular basic
+   code point, which never appears in the remainder of the basic string.
+   The decoder can therefore find the end of the literal portion (if
+   there is one) by scanning for the last delimiter.
+
+3.2 Insertion unsort coding
+
+   The remainder of the basic string (after the last delimiter if there
+   is one) represents a sequence of nonnegative integral deltas as
+   generalized variable-length integers, described in section 3.3.  The
+   meaning of the deltas is best understood in terms of the decoder.
+
+   The decoder builds the extended string incrementally.  Initially, the
+   extended string is a copy of the literal portion of the basic string
+   (excluding the last delimiter).  The decoder inserts non-basic code
+   points, one for each delta, into the extended string, ultimately
+   arriving at the final decoded string.
+
+
+
+
+Costello                    Standards Track                     [Page 4]
+
+RFC 3492                     IDNA Punycode                    March 2003
+
+
+   At the heart of this process is a state machine with two state
+   variables: an index i and a counter n.  The index i refers to a
+   position in the extended string; it ranges from 0 (the first
+   position) to the current length of the extended string (which refers
+   to a potential position beyond the current end).  If the current
+   state is <n,i>, the next state is <n,i+1> if i is less than the
+   length of the extended string, or <n+1,0> if i equals the length of
+   the extended string.  In other words, each state change causes i to
+   increment, wrapping around to zero if necessary, and n counts the
+   number of wrap-arounds.
+
+   Notice that the state always advances monotonically (there is no way
+   for the decoder to return to an earlier state).  At each state, an
+   insertion is either performed or not performed.  At most one
+   insertion is performed in a given state.  An insertion inserts the
+   value of n at position i in the extended string.  The deltas are a
+   run-length encoding of this sequence of events: they are the lengths
+   of the runs of non-insertion states preceeding the insertion states.
+   Hence, for each delta, the decoder performs delta state changes, then
+   an insertion, and then one more state change.  (An implementation
+   need not perform each state change individually, but can instead use
+   division and remainder calculations to compute the next insertion
+   state directly.)  It is an error if the inserted code point is a
+   basic code point (because basic code points were supposed to be
+   segregated as described in section 3.1).
+
+   The encoder's main task is to derive the sequence of deltas that will
+   cause the decoder to construct the desired string.  It can do this by
+   repeatedly scanning the extended string for the next code point that
+   the decoder would need to insert, and counting the number of state
+   changes the decoder would need to perform, mindful of the fact that
+   the decoder's extended string will include only those code points
+   that have already been inserted.  Section 6.3 "Encoding procedure"
+   gives a precise algorithm.
+
+3.3 Generalized variable-length integers
+
+   In a conventional integer representation the base is the number of
+   distinct symbols for digits, whose values are 0 through base-1.  Let
+   digit_0 denote the least significant digit, digit_1 the next least
+   significant, and so on.  The value represented is the sum over j of
+   digit_j * w(j), where w(j) = base^j is the weight (scale factor) for
+   position j.  For example, in the base 8 integer 437, the digits are
+   7, 3, and 4, and the weights are 1, 8, and 64, so the value is 7 +
+   3*8 + 4*64 = 287.  This representation has two disadvantages:  First,
+   there are multiple encodings of each value (because there can be
+   extra zeros in the most significant positions), which is inconvenient
+
+
+
+
+Costello                    Standards Track                     [Page 5]
+
+RFC 3492                     IDNA Punycode                    March 2003
+
+
+   when unique encodings are needed.  Second, the integer is not self-
+   delimiting, so if multiple integers are concatenated the boundaries
+   between them are lost.
+
+   The generalized variable-length representation solves these two
+   problems.  The digit values are still 0 through base-1, but now the
+   integer is self-delimiting by means of thresholds t(j), each of which
+   is in the range 0 through base-1.  Exactly one digit, the most
+   significant, satisfies digit_j < t(j).  Therefore, if several
+   integers are concatenated, it is easy to separate them, starting with
+   the first if they are little-endian (least significant digit first),
+   or starting with the last if they are big-endian (most significant
+   digit first).  As before, the value is the sum over j of digit_j *
+   w(j), but the weights are different:
+
+      w(0) = 1
+      w(j) = w(j-1) * (base - t(j-1)) for j > 0
+
+   For example, consider the little-endian sequence of base 8 digits
+   734251...  Suppose the thresholds are 2, 3, 5, 5, 5, 5...  This
+   implies that the weights are 1, 1*(8-2) = 6, 6*(8-3) = 30, 30*(8-5) =
+   90, 90*(8-5) = 270, and so on.  7 is not less than 2, and 3 is not
+   less than 3, but 4 is less than 5, so 4 is the last digit.  The value
+   of 734 is 7*1 + 3*6 + 4*30 = 145.  The next integer is 251, with
+   value 2*1 + 5*6 + 1*30 = 62.  Decoding this representation is very
+   similar to decoding a conventional integer:  Start with a current
+   value of N = 0 and a weight w = 1.  Fetch the next digit d and
+   increase N by d * w.  If d is less than the current threshold (t)
+   then stop, otherwise increase w by a factor of (base - t), update t
+   for the next position, and repeat.
+
+   Encoding this representation is similar to encoding a conventional
+   integer:  If N < t then output one digit for N and stop, otherwise
+   output the digit for t + ((N - t) mod (base - t)), then replace N
+   with (N - t) div (base - t), update t for the next position, and
+   repeat.
+
+   For any particular set of values of t(j), there is exactly one
+   generalized variable-length representation of each nonnegative
+   integral value.
+
+   Bootstring uses little-endian ordering so that the deltas can be
+   separated starting with the first.  The t(j) values are defined in
+   terms of the constants base, tmin, and tmax, and a state variable
+   called bias:
+
+      t(j) = base * (j + 1) - bias,
+      clamped to the range tmin through tmax
+
+
+
+Costello                    Standards Track                     [Page 6]
+
+RFC 3492                     IDNA Punycode                    March 2003
+
+
+   The clamping means that if the formula yields a value less than tmin
+   or greater than tmax, then t(j) = tmin or tmax, respectively.  (In
+   the pseudocode in section 6 "Bootstring algorithms", the expression
+   base * (j + 1) is denoted by k for performance reasons.)  These t(j)
+   values cause the representation to favor integers within a particular
+   range determined by the bias.
+
+3.4 Bias adaptation
+
+   After each delta is encoded or decoded, bias is set for the next
+   delta as follows:
+
+   1. Delta is scaled in order to avoid overflow in the next step:
+
+         let delta = delta div 2
+
+      But when this is the very first delta, the divisor is not 2, but
+      instead a constant called damp.  This compensates for the fact
+      that the second delta is usually much smaller than the first.
+
+   2. Delta is increased to compensate for the fact that the next delta
+      will be inserting into a longer string:
+
+         let delta = delta + (delta div numpoints)
+
+      numpoints is the total number of code points encoded/decoded so
+      far (including the one corresponding to this delta itself, and
+      including the basic code points).
+
+   3. Delta is repeatedly divided until it falls within a threshold, to
+      predict the minimum number of digits needed to represent the next
+      delta:
+
+         while delta > ((base - tmin) * tmax) div 2
+         do let delta = delta div (base - tmin)
+
+   4. The bias is set:
+
+         let bias =
+           (base * the number of divisions performed in step 3) +
+           (((base - tmin + 1) * delta) div (delta + skew))
+
+      The motivation for this procedure is that the current delta
+      provides a hint about the likely size of the next delta, and so
+      t(j) is set to tmax for the more significant digits starting with
+      the one expected to be last, tmin for the less significant digits
+      up through the one expected to be third-last, and somewhere
+      between tmin and tmax for the digit expected to be second-last
+
+
+
+Costello                    Standards Track                     [Page 7]
+
+RFC 3492                     IDNA Punycode                    March 2003
+
+
+      (balancing the hope of the expected-last digit being unnecessary
+      against the danger of it being insufficient).
+
+4. Bootstring parameters
+
+   Given a set of basic code points, one needs to be designated as the
+   delimiter.  The base cannot be greater than the number of
+   distinguishable basic code points remaining.  The digit-values in the
+   range 0 through base-1 need to be associated with distinct non-
+   delimiter basic code points.  In some cases multiple code points need
+   to have the same digit-value; for example, uppercase and lowercase
+   versions of the same letter need to be equivalent if basic strings
+   are case-insensitive.
+
+   The initial value of n cannot be greater than the minimum non-basic
+   code point that could appear in extended strings.
+
+   The remaining five parameters (tmin, tmax, skew, damp, and the
+   initial value of bias) need to satisfy the following constraints:
+
+      0 <= tmin <= tmax <= base-1
+      skew >= 1
+      damp >= 2
+      initial_bias mod base <= base - tmin
+
+   Provided the constraints are satisfied, these five parameters affect
+   efficiency but not correctness.  They are best chosen empirically.
+
+   If support for mixed-case annotation is desired (see appendix A),
+   make sure that the code points corresponding to 0 through tmax-1 all
+   have both uppercase and lowercase forms.
+
+5. Parameter values for Punycode
+
+   Punycode uses the following Bootstring parameter values:
+
+      base         = 36
+      tmin         = 1
+      tmax         = 26
+      skew         = 38
+      damp         = 700
+      initial_bias = 72
+      initial_n    = 128 = 0x80
+
+   Although the only restriction Punycode imposes on the input integers
+   is that they be nonnegative, these parameters are especially designed
+   to work well with Unicode [UNICODE] code points, which are integers
+   in the range 0..10FFFF (but not D800..DFFF, which are reserved for
+
+
+
+Costello                    Standards Track                     [Page 8]
+
+RFC 3492                     IDNA Punycode                    March 2003
+
+
+   use by the UTF-16 encoding of Unicode).  The basic code points are
+   the ASCII [ASCII] code points (0..7F), of which U+002D (-) is the
+   delimiter, and some of the others have digit-values as follows:
+
+      code points    digit-values
+      ------------   ----------------------
+      41..5A (A-Z) =  0 to 25, respectively
+      61..7A (a-z) =  0 to 25, respectively
+      30..39 (0-9) = 26 to 35, respectively
+
+   Using hyphen-minus as the delimiter implies that the encoded string
+   can end with a hyphen-minus only if the Unicode string consists
+   entirely of basic code points, but IDNA forbids such strings from
+   being encoded.  The encoded string can begin with a hyphen-minus, but
+   IDNA prepends a prefix.  Therefore IDNA using Punycode conforms to
+   the RFC 952 rule that host name labels neither begin nor end with a
+   hyphen-minus [RFC952].
+
+   A decoder MUST recognize the letters in both uppercase and lowercase
+   forms (including mixtures of both forms).  An encoder SHOULD output
+   only uppercase forms or only lowercase forms, unless it uses mixed-
+   case annotation (see appendix A).
+
+   Presumably most users will not manually write or type encoded strings
+   (as opposed to cutting and pasting them), but those who do will need
+   to be alert to the potential visual ambiguity between the following
+   sets of characters:
+
+      G 6
+      I l 1
+      O 0
+      S 5
+      U V
+      Z 2
+
+   Such ambiguities are usually resolved by context, but in a Punycode
+   encoded string there is no context apparent to humans.
+
+6. Bootstring algorithms
+
+   Some parts of the pseudocode can be omitted if the parameters satisfy
+   certain conditions (for which Punycode qualifies).  These parts are
+   enclosed in {braces}, and notes immediately following the pseudocode
+   explain the conditions under which they can be omitted.
+
+
+
+
+
+
+
+Costello                    Standards Track                     [Page 9]
+
+RFC 3492                     IDNA Punycode                    March 2003
+
+
+   Formally, code points are integers, and hence the pseudocode assumes
+   that arithmetic operations can be performed directly on code points.
+   In some programming languages, explicit conversion between code
+   points and integers might be necessary.
+
+6.1 Bias adaptation function
+
+   function adapt(delta,numpoints,firsttime):
+     if firsttime then let delta = delta div damp
+     else let delta = delta div 2
+     let delta = delta + (delta div numpoints)
+     let k = 0
+     while delta > ((base - tmin) * tmax) div 2 do begin
+       let delta = delta div (base - tmin)
+       let k = k + base
+     end
+     return k + (((base - tmin + 1) * delta) div (delta + skew))
+
+   It does not matter whether the modifications to delta and k inside
+   adapt() affect variables of the same name inside the
+   encoding/decoding procedures, because after calling adapt() the
+   caller does not read those variables before overwriting them.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Costello                    Standards Track                    [Page 10]
+
+RFC 3492                     IDNA Punycode                    March 2003
+
+
+6.2 Decoding procedure
+
+   let n = initial_n
+   let i = 0
+   let bias = initial_bias
+   let output = an empty string indexed from 0
+   consume all code points before the last delimiter (if there is one)
+     and copy them to output, fail on any non-basic code point
+   if more than zero code points were consumed then consume one more
+     (which will be the last delimiter)
+   while the input is not exhausted do begin
+     let oldi = i
+     let w = 1
+     for k = base to infinity in steps of base do begin
+       consume a code point, or fail if there was none to consume
+       let digit = the code point's digit-value, fail if it has none
+       let i = i + digit * w, fail on overflow
+       let t = tmin if k <= bias {+ tmin}, or
+               tmax if k >= bias + tmax, or k - bias otherwise
+       if digit < t then break
+       let w = w * (base - t), fail on overflow
+     end
+     let bias = adapt(i - oldi, length(output) + 1, test oldi is 0?)
+     let n = n + i div (length(output) + 1), fail on overflow
+     let i = i mod (length(output) + 1)
+     {if n is a basic code point then fail}
+     insert n into output at position i
+     increment i
+   end
+
+   The full statement enclosed in braces (checking whether n is a basic
+   code point) can be omitted if initial_n exceeds all basic code points
+   (which is true for Punycode), because n is never less than initial_n.
+
+   In the assignment of t, where t is clamped to the range tmin through
+   tmax, "+ tmin" can always be omitted.  This makes the clamping
+   calculation incorrect when bias < k < bias + tmin, but that cannot
+   happen because of the way bias is computed and because of the
+   constraints on the parameters.
+
+   Because the decoder state can only advance monotonically, and there
+   is only one representation of any delta, there is therefore only one
+   encoded string that can represent a given sequence of integers.  The
+   only error conditions are invalid code points, unexpected end-of-
+   input, overflow, and basic code points encoded using deltas instead
+   of appearing literally.  If the decoder fails on these errors as
+   shown above, then it cannot produce the same output for two distinct
+   inputs.  Without this property it would have been necessary to re-
+
+
+
+Costello                    Standards Track                    [Page 11]
+
+RFC 3492                     IDNA Punycode                    March 2003
+
+
+   encode the output and verify that it matches the input in order to
+   guarantee the uniqueness of the encoding.
+
+6.3 Encoding procedure
+
+   let n = initial_n
+   let delta = 0
+   let bias = initial_bias
+   let h = b = the number of basic code points in the input
+   copy them to the output in order, followed by a delimiter if b > 0
+   {if the input contains a non-basic code point < n then fail}
+   while h < length(input) do begin
+     let m = the minimum {non-basic} code point >= n in the input
+     let delta = delta + (m - n) * (h + 1), fail on overflow
+     let n = m
+     for each code point c in the input (in order) do begin
+       if c < n {or c is basic} then increment delta, fail on overflow
+       if c == n then begin
+         let q = delta
+         for k = base to infinity in steps of base do begin
+           let t = tmin if k <= bias {+ tmin}, or
+                   tmax if k >= bias + tmax, or k - bias otherwise
+           if q < t then break
+           output the code point for digit t + ((q - t) mod (base - t))
+           let q = (q - t) div (base - t)
+         end
+         output the code point for digit q
+         let bias = adapt(delta, h + 1, test h equals b?)
+         let delta = 0
+         increment h
+       end
+     end
+     increment delta and n
+   end
+
+   The full statement enclosed in braces (checking whether the input
+   contains a non-basic code point less than n) can be omitted if all
+   code points less than initial_n are basic code points (which is true
+   for Punycode if code points are unsigned).
+
+   The brace-enclosed conditions "non-basic" and "or c is basic" can be
+   omitted if initial_n exceeds all basic code points (which is true for
+   Punycode), because the code point being tested is never less than
+   initial_n.
+
+   In the assignment of t, where t is clamped to the range tmin through
+   tmax, "+ tmin" can always be omitted.  This makes the clamping
+   calculation incorrect when bias < k < bias + tmin, but that cannot
+
+
+
+Costello                    Standards Track                    [Page 12]
+
+RFC 3492                     IDNA Punycode                    March 2003
+
+
+   happen because of the way bias is computed and because of the
+   constraints on the parameters.
+
+   The checks for overflow are necessary to avoid producing invalid
+   output when the input contains very large values or is very long.
+
+   The increment of delta at the bottom of the outer loop cannot
+   overflow because delta < length(input) before the increment, and
+   length(input) is already assumed to be representable.  The increment
+   of n could overflow, but only if h == length(input), in which case
+   the procedure is finished anyway.
+
+6.4 Overflow handling
+
+   For IDNA, 26-bit unsigned integers are sufficient to handle all valid
+   IDNA labels without overflow, because any string that needed a 27-bit
+   delta would have to exceed either the code point limit (0..10FFFF) or
+   the label length limit (63 characters).  However, overflow handling
+   is necessary because the inputs are not necessarily valid IDNA
+   labels.
+
+   If the programming language does not provide overflow detection, the
+   following technique can be used.  Suppose A, B, and C are
+   representable nonnegative integers and C is nonzero.  Then A + B
+   overflows if and only if B > maxint - A, and A + (B * C) overflows if
+   and only if B > (maxint - A) div C, where maxint is the greatest
+   integer for which maxint + 1 cannot be represented.  Refer to
+   appendix C "Punycode sample implementation" for demonstrations of
+   this technique in the C language.
+
+   The decoding and encoding algorithms shown in sections 6.2 and 6.3
+   handle overflow by detecting it whenever it happens.  Another
+   approach is to enforce limits on the inputs that prevent overflow
+   from happening.  For example, if the encoder were to verify that no
+   input code points exceed M and that the input length does not exceed
+   L, then no delta could ever exceed (M - initial_n) * (L + 1), and
+   hence no overflow could occur if integer variables were capable of
+   representing values that large.  This prevention approach would
+   impose more restrictions on the input than the detection approach
+   does, but might be considered simpler in some programming languages.
+
+   In theory, the decoder could use an analogous approach, limiting the
+   number of digits in a variable-length integer (that is, limiting the
+   number of iterations in the innermost loop).  However, the number of
+   digits that suffice to represent a given delta can sometimes
+   represent much larger deltas (because of the adaptation), and hence
+   this approach would probably need integers wider than 32 bits.
+
+
+
+
+Costello                    Standards Track                    [Page 13]
+
+RFC 3492                     IDNA Punycode                    March 2003
+
+
+   Yet another approach for the decoder is to allow overflow to occur,
+   but to check the final output string by re-encoding it and comparing
+   to the decoder input.  If and only if they do not match (using a
+   case-insensitive ASCII comparison) overflow has occurred.  This
+   delayed-detection approach would not impose any more restrictions on
+   the input than the immediate-detection approach does, and might be
+   considered simpler in some programming languages.
+
+   In fact, if the decoder is used only inside the IDNA ToUnicode
+   operation [IDNA], then it need not check for overflow at all, because
+   ToUnicode performs a higher level re-encoding and comparison, and a
+   mismatch has the same consequence as if the Punycode decoder had
+   failed.
+
+7. Punycode examples
+
+7.1 Sample strings
+
+   In the Punycode encodings below, the ACE prefix is not shown.
+   Backslashes show where line breaks have been inserted in strings too
+   long for one line.
+
+   The first several examples are all translations of the sentence "Why
+   can't they just speak in <language>?" (courtesy of Michael Kaplan's
+   "provincial" page [PROVINCIAL]).  Word breaks and punctuation have
+   been removed, as is often done in domain names.
+
+   (A) Arabic (Egyptian):
+       u+0644 u+064A u+0647 u+0645 u+0627 u+0628 u+062A u+0643 u+0644
+       u+0645 u+0648 u+0634 u+0639 u+0631 u+0628 u+064A u+061F
+       Punycode: egbpdaj6bu4bxfgehfvwxn
+
+   (B) Chinese (simplified):
+       u+4ED6 u+4EEC u+4E3A u+4EC0 u+4E48 u+4E0D u+8BF4 u+4E2D u+6587
+       Punycode: ihqwcrb4cv8a8dqg056pqjye
+
+   (C) Chinese (traditional):
+       u+4ED6 u+5011 u+7232 u+4EC0 u+9EBD u+4E0D u+8AAA u+4E2D u+6587
+       Punycode: ihqwctvzc91f659drss3x8bo0yb
+
+   (D) Czech: Pro<ccaron>prost<ecaron>nemluv<iacute><ccaron>esky
+       U+0050 u+0072 u+006F u+010D u+0070 u+0072 u+006F u+0073 u+0074
+       u+011B u+006E u+0065 u+006D u+006C u+0075 u+0076 u+00ED u+010D
+       u+0065 u+0073 u+006B u+0079
+       Punycode: Proprostnemluvesky-uyb24dma41a
+
+
+
+
+
+
+Costello                    Standards Track                    [Page 14]
+
+RFC 3492                     IDNA Punycode                    March 2003
+
+
+   (E) Hebrew:
+       u+05DC u+05DE u+05D4 u+05D4 u+05DD u+05E4 u+05E9 u+05D5 u+05D8
+       u+05DC u+05D0 u+05DE u+05D3 u+05D1 u+05E8 u+05D9 u+05DD u+05E2
+       u+05D1 u+05E8 u+05D9 u+05EA
+       Punycode: 4dbcagdahymbxekheh6e0a7fei0b
+
+   (F) Hindi (Devanagari):
+       u+092F u+0939 u+0932 u+094B u+0917 u+0939 u+093F u+0928 u+094D
+       u+0926 u+0940 u+0915 u+094D u+092F u+094B u+0902 u+0928 u+0939
+       u+0940 u+0902 u+092C u+094B u+0932 u+0938 u+0915 u+0924 u+0947
+       u+0939 u+0948 u+0902
+       Punycode: i1baa7eci9glrd9b2ae1bj0hfcgg6iyaf8o0a1dig0cd
+
+   (G) Japanese (kanji and hiragana):
+       u+306A u+305C u+307F u+3093 u+306A u+65E5 u+672C u+8A9E u+3092
+       u+8A71 u+3057 u+3066 u+304F u+308C u+306A u+3044 u+306E u+304B
+       Punycode: n8jok5ay5dzabd5bym9f0cm5685rrjetr6pdxa
+
+   (H) Korean (Hangul syllables):
+       u+C138 u+ACC4 u+C758 u+BAA8 u+B4E0 u+C0AC u+B78C u+B4E4 u+C774
+       u+D55C u+AD6D u+C5B4 u+B97C u+C774 u+D574 u+D55C u+B2E4 u+BA74
+       u+C5BC u+B9C8 u+B098 u+C88B u+C744 u+AE4C
+       Punycode: 989aomsvi5e83db1d2a355cv1e0vak1dwrv93d5xbh15a0dt30a5j\
+                 psd879ccm6fea98c
+
+   (I) Russian (Cyrillic):
+       U+043F u+043E u+0447 u+0435 u+043C u+0443 u+0436 u+0435 u+043E
+       u+043D u+0438 u+043D u+0435 u+0433 u+043E u+0432 u+043E u+0440
+       u+044F u+0442 u+043F u+043E u+0440 u+0443 u+0441 u+0441 u+043A
+       u+0438
+       Punycode: b1abfaaepdrnnbgefbaDotcwatmq2g4l
+
+   (J) Spanish: Porqu<eacute>nopuedensimplementehablarenEspa<ntilde>ol
+       U+0050 u+006F u+0072 u+0071 u+0075 u+00E9 u+006E u+006F u+0070
+       u+0075 u+0065 u+0064 u+0065 u+006E u+0073 u+0069 u+006D u+0070
+       u+006C u+0065 u+006D u+0065 u+006E u+0074 u+0065 u+0068 u+0061
+       u+0062 u+006C u+0061 u+0072 u+0065 u+006E U+0045 u+0073 u+0070
+       u+0061 u+00F1 u+006F u+006C
+       Punycode: PorqunopuedensimplementehablarenEspaol-fmd56a
+
+   (K) Vietnamese:
+       T<adotbelow>isaoh<odotbelow>kh<ocirc>ngth<ecirchookabove>ch\
+       <ihookabove>n<oacute>iti<ecircacute>ngVi<ecircdotbelow>t
+       U+0054 u+1EA1 u+0069 u+0073 u+0061 u+006F u+0068 u+1ECD u+006B
+       u+0068 u+00F4 u+006E u+0067 u+0074 u+0068 u+1EC3 u+0063 u+0068
+       u+1EC9 u+006E u+00F3 u+0069 u+0074 u+0069 u+1EBF u+006E u+0067
+       U+0056 u+0069 u+1EC7 u+0074
+       Punycode: TisaohkhngthchnitingVit-kjcr8268qyxafd2f1b9g
+
+
+
+Costello                    Standards Track                    [Page 15]
+
+RFC 3492                     IDNA Punycode                    March 2003
+
+
+   The next several examples are all names of Japanese music artists,
+   song titles, and TV programs, just because the author happens to have
+   them handy (but Japanese is useful for providing examples of single-
+   row text, two-row text, ideographic text, and various mixtures
+   thereof).
+
+   (L) 3<nen>B<gumi><kinpachi><sensei>
+       u+0033 u+5E74 U+0042 u+7D44 u+91D1 u+516B u+5148 u+751F
+       Punycode: 3B-ww4c5e180e575a65lsy2b
+
+   (M) <amuro><namie>-with-SUPER-MONKEYS
+       u+5B89 u+5BA4 u+5948 u+7F8E u+6075 u+002D u+0077 u+0069 u+0074
+       u+0068 u+002D U+0053 U+0055 U+0050 U+0045 U+0052 u+002D U+004D
+       U+004F U+004E U+004B U+0045 U+0059 U+0053
+       Punycode: -with-SUPER-MONKEYS-pc58ag80a8qai00g7n9n
+
+   (N) Hello-Another-Way-<sorezore><no><basho>
+       U+0048 u+0065 u+006C u+006C u+006F u+002D U+0041 u+006E u+006F
+       u+0074 u+0068 u+0065 u+0072 u+002D U+0057 u+0061 u+0079 u+002D
+       u+305D u+308C u+305E u+308C u+306E u+5834 u+6240
+       Punycode: Hello-Another-Way--fc4qua05auwb3674vfr0b
+
+   (O) <hitotsu><yane><no><shita>2
+       u+3072 u+3068 u+3064 u+5C4B u+6839 u+306E u+4E0B u+0032
+       Punycode: 2-u9tlzr9756bt3uc0v
+
+   (P) Maji<de>Koi<suru>5<byou><mae>
+       U+004D u+0061 u+006A u+0069 u+3067 U+004B u+006F u+0069 u+3059
+       u+308B u+0035 u+79D2 u+524D
+       Punycode: MajiKoi5-783gue6qz075azm5e
+
+   (Q) <pafii>de<runba>
+       u+30D1 u+30D5 u+30A3 u+30FC u+0064 u+0065 u+30EB u+30F3 u+30D0
+       Punycode: de-jg4avhby1noc0d
+
+   (R) <sono><supiido><de>
+       u+305D u+306E u+30B9 u+30D4 u+30FC u+30C9 u+3067
+       Punycode: d9juau41awczczp
+
+   The last example is an ASCII string that breaks the existing rules
+   for host name labels.  (It is not a realistic example for IDNA,
+   because IDNA never encodes pure ASCII labels.)
+
+   (S) -> $1.00 <-
+       u+002D u+003E u+0020 u+0024 u+0031 u+002E u+0030 u+0030 u+0020
+       u+003C u+002D
+       Punycode: -> $1.00 <--
+
+
+
+
+Costello                    Standards Track                    [Page 16]
+
+RFC 3492                     IDNA Punycode                    March 2003
+
+
+7.2 Decoding traces
+
+   In the following traces, the evolving state of the decoder is shown
+   as a sequence of hexadecimal values, representing the code points in
+   the extended string.  An asterisk appears just after the most
+   recently inserted code point, indicating both n (the value preceeding
+   the asterisk) and i (the position of the value just after the
+   asterisk).  Other numerical values are decimal.
+
+   Decoding trace of example B from section 7.1:
+
+   n is 128, i is 0, bias is 72
+   input is "ihqwcrb4cv8a8dqg056pqjye"
+   there is no delimiter, so extended string starts empty
+   delta "ihq" decodes to 19853
+   bias becomes 21
+   4E0D *
+   delta "wc" decodes to 64
+   bias becomes 20
+   4E0D 4E2D *
+   delta "rb" decodes to 37
+   bias becomes 13
+   4E3A * 4E0D 4E2D
+   delta "4c" decodes to 56
+   bias becomes 17
+   4E3A 4E48 * 4E0D 4E2D
+   delta "v8a" decodes to 599
+   bias becomes 32
+   4E3A 4EC0 * 4E48 4E0D 4E2D
+   delta "8d" decodes to 130
+   bias becomes 23
+   4ED6 * 4E3A 4EC0 4E48 4E0D 4E2D
+   delta "qg" decodes to 154
+   bias becomes 25
+   4ED6 4EEC * 4E3A 4EC0 4E48 4E0D 4E2D
+   delta "056p" decodes to 46301
+   bias becomes 84
+   4ED6 4EEC 4E3A 4EC0 4E48 4E0D 4E2D 6587 *
+   delta "qjye" decodes to 88531
+   bias becomes 90
+   4ED6 4EEC 4E3A 4EC0 4E48 4E0D 8BF4 * 4E2D 6587
+
+
+
+
+
+
+
+
+
+
+Costello                    Standards Track                    [Page 17]
+
+RFC 3492                     IDNA Punycode                    March 2003
+
+
+   Decoding trace of example L from section 7.1:
+
+   n is 128, i is 0, bias is 72
+   input is "3B-ww4c5e180e575a65lsy2b"
+   literal portion is "3B-", so extended string starts as:
+   0033 0042
+   delta "ww4c" decodes to 62042
+   bias becomes 27
+   0033 0042 5148 *
+   delta "5e" decodes to 139
+   bias becomes 24
+   0033 0042 516B * 5148
+   delta "180e" decodes to 16683
+   bias becomes 67
+   0033 5E74 * 0042 516B 5148
+   delta "575a" decodes to 34821
+   bias becomes 82
+   0033 5E74 0042 516B 5148 751F *
+   delta "65l" decodes to 14592
+   bias becomes 67
+   0033 5E74 0042 7D44 * 516B 5148 751F
+   delta "sy2b" decodes to 42088
+   bias becomes 84
+   0033 5E74 0042 7D44 91D1 * 516B 5148 751F
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Costello                    Standards Track                    [Page 18]
+
+RFC 3492                     IDNA Punycode                    March 2003
+
+
+7.3 Encoding traces
+
+   In the following traces, code point values are hexadecimal, while
+   other numerical values are decimal.
+
+   Encoding trace of example B from section 7.1:
+
+   bias is 72
+   input is:
+   4ED6 4EEC 4E3A 4EC0 4E48 4E0D 8BF4 4E2D 6587
+   there are no basic code points, so no literal portion
+   next code point to insert is 4E0D
+   needed delta is 19853, encodes as "ihq"
+   bias becomes 21
+   next code point to insert is 4E2D
+   needed delta is 64, encodes as "wc"
+   bias becomes 20
+   next code point to insert is 4E3A
+   needed delta is 37, encodes as "rb"
+   bias becomes 13
+   next code point to insert is 4E48
+   needed delta is 56, encodes as "4c"
+   bias becomes 17
+   next code point to insert is 4EC0
+   needed delta is 599, encodes as "v8a"
+   bias becomes 32
+   next code point to insert is 4ED6
+   needed delta is 130, encodes as "8d"
+   bias becomes 23
+   next code point to insert is 4EEC
+   needed delta is 154, encodes as "qg"
+   bias becomes 25
+   next code point to insert is 6587
+   needed delta is 46301, encodes as "056p"
+   bias becomes 84
+   next code point to insert is 8BF4
+   needed delta is 88531, encodes as "qjye"
+   bias becomes 90
+   output is "ihqwcrb4cv8a8dqg056pqjye"
+
+
+
+
+
+
+
+
+
+
+
+
+Costello                    Standards Track                    [Page 19]
+
+RFC 3492                     IDNA Punycode                    March 2003
+
+
+   Encoding trace of example L from section 7.1:
+
+   bias is 72
+   input is:
+   0033 5E74 0042 7D44 91D1 516B 5148 751F
+   basic code points (0033, 0042) are copied to literal portion: "3B-"
+   next code point to insert is 5148
+   needed delta is 62042, encodes as "ww4c"
+   bias becomes 27
+   next code point to insert is 516B
+   needed delta is 139, encodes as "5e"
+   bias becomes 24
+   next code point to insert is 5E74
+   needed delta is 16683, encodes as "180e"
+   bias becomes 67
+   next code point to insert is 751F
+   needed delta is 34821, encodes as "575a"
+   bias becomes 82
+   next code point to insert is 7D44
+   needed delta is 14592, encodes as "65l"
+   bias becomes 67
+   next code point to insert is 91D1
+   needed delta is 42088, encodes as "sy2b"
+   bias becomes 84
+   output is "3B-ww4c5e180e575a65lsy2b"
+
+8. Security Considerations
+
+   Users expect each domain name in DNS to be controlled by a single
+   authority.  If a Unicode string intended for use as a domain label
+   could map to multiple ACE labels, then an internationalized domain
+   name could map to multiple ASCII domain names, each controlled by a
+   different authority, some of which could be spoofs that hijack
+   service requests intended for another.  Therefore Punycode is
+   designed so that each Unicode string has a unique encoding.
+
+   However, there can still be multiple Unicode representations of the
+   "same" text, for various definitions of "same".  This problem is
+   addressed to some extent by the Unicode standard under the topic of
+   canonicalization, and this work is leveraged for domain names by
+   Nameprep [NAMEPREP].
+
+
+
+
+
+
+
+
+
+
+Costello                    Standards Track                    [Page 20]
+
+RFC 3492                     IDNA Punycode                    March 2003
+
+
+9. References
+
+9.1 Normative References
+
+   [RFC2119]    Bradner, S., "Key words for use in RFCs to Indicate
+                Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+9.2 Informative References
+
+   [RFC952]     Harrenstien, K., Stahl, M. and E. Feinler, "DOD Internet
+                Host Table Specification", RFC 952, October 1985.
+
+   [RFC1034]    Mockapetris, P., "Domain Names - Concepts and
+                Facilities", STD 13, RFC 1034, November 1987.
+
+   [IDNA]       Faltstrom, P., Hoffman, P. and A. Costello,
+                "Internationalizing Domain Names in Applications
+                (IDNA)", RFC 3490, March 2003.
+
+   [NAMEPREP]   Hoffman, P. and  M. Blanchet, "Nameprep: A Stringprep
+                Profile for Internationalized Domain Names (IDN)", RFC
+                3491, March 2003.
+
+   [ASCII]      Cerf, V., "ASCII format for Network Interchange", RFC
+                20, October 1969.
+
+   [PROVINCIAL] Kaplan, M., "The 'anyone can be provincial!' page",
+                http://www.trigeminal.com/samples/provincial.html.
+
+   [UNICODE]    The Unicode Consortium, "The Unicode Standard",
+                http://www.unicode.org/unicode/standard/standard.html.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Costello                    Standards Track                    [Page 21]
+
+RFC 3492                     IDNA Punycode                    March 2003
+
+
+A. Mixed-case annotation
+
+   In order to use Punycode to represent case-insensitive strings,
+   higher layers need to case-fold the strings prior to Punycode
+   encoding.  The encoded string can use mixed case as an annotation
+   telling how to convert the folded string into a mixed-case string for
+   display purposes.  Note, however, that mixed-case annotation is not
+   used by the ToASCII and ToUnicode operations specified in [IDNA], and
+   therefore implementors of IDNA can disregard this appendix.
+
+   Basic code points can use mixed case directly, because the decoder
+   copies them verbatim, leaving lowercase code points lowercase, and
+   leaving uppercase code points uppercase.  Each non-basic code point
+   is represented by a delta, which is represented by a sequence of
+   basic code points, the last of which provides the annotation.  If it
+   is uppercase, it is a suggestion to map the non-basic code point to
+   uppercase (if possible); if it is lowercase, it is a suggestion to
+   map the non-basic code point to lowercase (if possible).
+
+   These annotations do not alter the code points returned by decoders;
+   the annotations are returned separately, for the caller to use or
+   ignore.  Encoders can accept annotations in addition to code points,
+   but the annotations do not alter the output, except to influence the
+   uppercase/lowercase form of ASCII letters.
+
+   Punycode encoders and decoders need not support these annotations,
+   and higher layers need not use them.
+
+B. Disclaimer and license
+
+   Regarding this entire document or any portion of it (including the
+   pseudocode and C code), the author makes no guarantees and is not
+   responsible for any damage resulting from its use.  The author grants
+   irrevocable permission to anyone to use, modify, and distribute it in
+   any way that does not diminish the rights of anyone else to use,
+   modify, and distribute it, provided that redistributed derivative
+   works do not contain misleading author or version information.
+   Derivative works need not be licensed under similar terms.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Costello                    Standards Track                    [Page 22]
+
+RFC 3492                     IDNA Punycode                    March 2003
+
+
+C. Punycode sample implementation
+
+/*
+punycode.c from RFC 3492
+http://www.nicemice.net/idn/
+Adam M. Costello
+http://www.nicemice.net/amc/
+
+This is ANSI C code (C89) implementing Punycode (RFC 3492).
+
+*/
+
+
+/************************************************************/
+/* Public interface (would normally go in its own .h file): */
+
+#include <limits.h>
+
+enum punycode_status {
+  punycode_success,
+  punycode_bad_input,   /* Input is invalid.                       */
+  punycode_big_output,  /* Output would exceed the space provided. */
+  punycode_overflow     /* Input needs wider integers to process.  */
+};
+
+#if UINT_MAX >= (1 << 26) - 1
+typedef unsigned int punycode_uint;
+#else
+typedef unsigned long punycode_uint;
+#endif
+
+enum punycode_status punycode_encode(
+  punycode_uint input_length,
+  const punycode_uint input[],
+  const unsigned char case_flags[],
+  punycode_uint *output_length,
+  char output[] );
+
+    /* punycode_encode() converts Unicode to Punycode.  The input     */
+    /* is represented as an array of Unicode code points (not code    */
+    /* units; surrogate pairs are not allowed), and the output        */
+    /* will be represented as an array of ASCII code points.  The     */
+    /* output string is *not* null-terminated; it will contain        */
+    /* zeros if and only if the input contains zeros.  (Of course     */
+    /* the caller can leave room for a terminator and add one if      */
+    /* needed.)  The input_length is the number of code points in     */
+    /* the input.  The output_length is an in/out argument: the       */
+    /* caller passes in the maximum number of code points that it     */
+
+
+
+Costello                    Standards Track                    [Page 23]
+
+RFC 3492                     IDNA Punycode                    March 2003
+
+
+    /* can receive, and on successful return it will contain the      */
+    /* number of code points actually output.  The case_flags array   */
+    /* holds input_length boolean values, where nonzero suggests that */
+    /* the corresponding Unicode character be forced to uppercase     */
+    /* after being decoded (if possible), and zero suggests that      */
+    /* it be forced to lowercase (if possible).  ASCII code points    */
+    /* are encoded literally, except that ASCII letters are forced    */
+    /* to uppercase or lowercase according to the corresponding       */
+    /* uppercase flags.  If case_flags is a null pointer then ASCII   */
+    /* letters are left as they are, and other code points are        */
+    /* treated as if their uppercase flags were zero.  The return     */
+    /* value can be any of the punycode_status values defined above   */
+    /* except punycode_bad_input; if not punycode_success, then       */
+    /* output_size and output might contain garbage.                  */
+
+enum punycode_status punycode_decode(
+  punycode_uint input_length,
+  const char input[],
+  punycode_uint *output_length,
+  punycode_uint output[],
+  unsigned char case_flags[] );
+
+    /* punycode_decode() converts Punycode to Unicode.  The input is  */
+    /* represented as an array of ASCII code points, and the output   */
+    /* will be represented as an array of Unicode code points.  The   */
+    /* input_length is the number of code points in the input.  The   */
+    /* output_length is an in/out argument: the caller passes in      */
+    /* the maximum number of code points that it can receive, and     */
+    /* on successful return it will contain the actual number of      */
+    /* code points output.  The case_flags array needs room for at    */
+    /* least output_length values, or it can be a null pointer if the */
+    /* case information is not needed.  A nonzero flag suggests that  */
+    /* the corresponding Unicode character be forced to uppercase     */
+    /* by the caller (if possible), while zero suggests that it be    */
+    /* forced to lowercase (if possible).  ASCII code points are      */
+    /* output already in the proper case, but their flags will be set */
+    /* appropriately so that applying the flags would be harmless.    */
+    /* The return value can be any of the punycode_status values      */
+    /* defined above; if not punycode_success, then output_length,    */
+    /* output, and case_flags might contain garbage.  On success, the */
+    /* decoder will never need to write an output_length greater than */
+    /* input_length, because of how the encoding is defined.          */
+
+/**********************************************************/
+/* Implementation (would normally go in its own .c file): */
+
+#include <string.h>
+
+
+
+
+Costello                    Standards Track                    [Page 24]
+
+RFC 3492                     IDNA Punycode                    March 2003
+
+
+/*** Bootstring parameters for Punycode ***/
+
+enum { base = 36, tmin = 1, tmax = 26, skew = 38, damp = 700,
+       initial_bias = 72, initial_n = 0x80, delimiter = 0x2D };
+
+/* basic(cp) tests whether cp is a basic code point: */
+#define basic(cp) ((punycode_uint)(cp) < 0x80)
+
+/* delim(cp) tests whether cp is a delimiter: */
+#define delim(cp) ((cp) == delimiter)
+
+/* decode_digit(cp) returns the numeric value of a basic code */
+/* point (for use in representing integers) in the range 0 to */
+/* base-1, or base if cp is does not represent a value.       */
+
+static punycode_uint decode_digit(punycode_uint cp)
+{
+  return  cp - 48 < 10 ? cp - 22 :  cp - 65 < 26 ? cp - 65 :
+          cp - 97 < 26 ? cp - 97 :  base;
+}
+
+/* encode_digit(d,flag) returns the basic code point whose value      */
+/* (when used for representing integers) is d, which needs to be in   */
+/* the range 0 to base-1.  The lowercase form is used unless flag is  */
+/* nonzero, in which case the uppercase form is used.  The behavior   */
+/* is undefined if flag is nonzero and digit d has no uppercase form. */
+
+static char encode_digit(punycode_uint d, int flag)
+{
+  return d + 22 + 75 * (d < 26) - ((flag != 0) << 5);
+  /*  0..25 map to ASCII a..z or A..Z */
+  /* 26..35 map to ASCII 0..9         */
+}
+
+/* flagged(bcp) tests whether a basic code point is flagged */
+/* (uppercase).  The behavior is undefined if bcp is not a  */
+/* basic code point.                                        */
+
+#define flagged(bcp) ((punycode_uint)(bcp) - 65 < 26)
+
+/* encode_basic(bcp,flag) forces a basic code point to lowercase */
+/* if flag is zero, uppercase if flag is nonzero, and returns    */
+/* the resulting code point.  The code point is unchanged if it  */
+/* is caseless.  The behavior is undefined if bcp is not a basic */
+/* code point.                                                   */
+
+static char encode_basic(punycode_uint bcp, int flag)
+{
+
+
+
+Costello                    Standards Track                    [Page 25]
+
+RFC 3492                     IDNA Punycode                    March 2003
+
+
+  bcp -= (bcp - 97 < 26) << 5;
+  return bcp + ((!flag && (bcp - 65 < 26)) << 5);
+}
+
+/*** Platform-specific constants ***/
+
+/* maxint is the maximum value of a punycode_uint variable: */
+static const punycode_uint maxint = -1;
+/* Because maxint is unsigned, -1 becomes the maximum value. */
+
+/*** Bias adaptation function ***/
+
+static punycode_uint adapt(
+  punycode_uint delta, punycode_uint numpoints, int firsttime )
+{
+  punycode_uint k;
+
+  delta = firsttime ? delta / damp : delta >> 1;
+  /* delta >> 1 is a faster way of doing delta / 2 */
+  delta += delta / numpoints;
+
+  for (k = 0;  delta > ((base - tmin) * tmax) / 2;  k += base) {
+    delta /= base - tmin;
+  }
+
+  return k + (base - tmin + 1) * delta / (delta + skew);
+}
+
+/*** Main encode function ***/
+
+enum punycode_status punycode_encode(
+  punycode_uint input_length,
+  const punycode_uint input[],
+  const unsigned char case_flags[],
+  punycode_uint *output_length,
+  char output[] )
+{
+  punycode_uint n, delta, h, b, out, max_out, bias, j, m, q, k, t;
+
+  /* Initialize the state: */
+
+  n = initial_n;
+  delta = out = 0;
+  max_out = *output_length;
+  bias = initial_bias;
+
+  /* Handle the basic code points: */
+
+
+
+
+Costello                    Standards Track                    [Page 26]
+
+RFC 3492                     IDNA Punycode                    March 2003
+
+
+  for (j = 0;  j < input_length;  ++j) {
+    if (basic(input[j])) {
+      if (max_out - out < 2) return punycode_big_output;
+      output[out++] =
+        case_flags ?  encode_basic(input[j], case_flags[j]) : input[j];
+    }
+    /* else if (input[j] < n) return punycode_bad_input; */
+    /* (not needed for Punycode with unsigned code points) */
+  }
+
+  h = b = out;
+
+  /* h is the number of code points that have been handled, b is the  */
+  /* number of basic code points, and out is the number of characters */
+  /* that have been output.                                           */
+
+  if (b > 0) output[out++] = delimiter;
+
+  /* Main encoding loop: */
+
+  while (h < input_length) {
+    /* All non-basic code points < n have been     */
+    /* handled already.  Find the next larger one: */
+
+    for (m = maxint, j = 0;  j < input_length;  ++j) {
+      /* if (basic(input[j])) continue; */
+      /* (not needed for Punycode) */
+      if (input[j] >= n && input[j] < m) m = input[j];
+    }
+
+    /* Increase delta enough to advance the decoder's    */
+    /* <n,i> state to <m,0>, but guard against overflow: */
+
+    if (m - n > (maxint - delta) / (h + 1)) return punycode_overflow;
+    delta += (m - n) * (h + 1);
+    n = m;
+
+    for (j = 0;  j < input_length;  ++j) {
+      /* Punycode does not need to check whether input[j] is basic: */
+      if (input[j] < n /* || basic(input[j]) */ ) {
+        if (++delta == 0) return punycode_overflow;
+      }
+
+      if (input[j] == n) {
+        /* Represent delta as a generalized variable-length integer: */
+
+        for (q = delta, k = base;  ;  k += base) {
+          if (out >= max_out) return punycode_big_output;
+
+
+
+Costello                    Standards Track                    [Page 27]
+
+RFC 3492                     IDNA Punycode                    March 2003
+
+
+          t = k <= bias /* + tmin */ ? tmin :     /* +tmin not needed */
+              k >= bias + tmax ? tmax : k - bias;
+          if (q < t) break;
+          output[out++] = encode_digit(t + (q - t) % (base - t), 0);
+          q = (q - t) / (base - t);
+        }
+
+        output[out++] = encode_digit(q, case_flags && case_flags[j]);
+        bias = adapt(delta, h + 1, h == b);
+        delta = 0;
+        ++h;
+      }
+    }
+
+    ++delta, ++n;
+  }
+
+  *output_length = out;
+  return punycode_success;
+}
+
+/*** Main decode function ***/
+
+enum punycode_status punycode_decode(
+  punycode_uint input_length,
+  const char input[],
+  punycode_uint *output_length,
+  punycode_uint output[],
+  unsigned char case_flags[] )
+{
+  punycode_uint n, out, i, max_out, bias,
+                 b, j, in, oldi, w, k, digit, t;
+
+  /* Initialize the state: */
+
+  n = initial_n;
+  out = i = 0;
+  max_out = *output_length;
+  bias = initial_bias;
+
+  /* Handle the basic code points:  Let b be the number of input code */
+  /* points before the last delimiter, or 0 if there is none, then    */
+  /* copy the first b code points to the output.                      */
+
+  for (b = j = 0;  j < input_length;  ++j) if (delim(input[j])) b = j;
+  if (b > max_out) return punycode_big_output;
+
+  for (j = 0;  j < b;  ++j) {
+
+
+
+Costello                    Standards Track                    [Page 28]
+
+RFC 3492                     IDNA Punycode                    March 2003
+
+
+    if (case_flags) case_flags[out] = flagged(input[j]);
+    if (!basic(input[j])) return punycode_bad_input;
+    output[out++] = input[j];
+  }
+
+  /* Main decoding loop:  Start just after the last delimiter if any  */
+  /* basic code points were copied; start at the beginning otherwise. */
+
+  for (in = b > 0 ? b + 1 : 0;  in < input_length;  ++out) {
+
+    /* in is the index of the next character to be consumed, and */
+    /* out is the number of code points in the output array.     */
+
+    /* Decode a generalized variable-length integer into delta,  */
+    /* which gets added to i.  The overflow checking is easier   */
+    /* if we increase i as we go, then subtract off its starting */
+    /* value at the end to obtain delta.                         */
+
+    for (oldi = i, w = 1, k = base;  ;  k += base) {
+      if (in >= input_length) return punycode_bad_input;
+      digit = decode_digit(input[in++]);
+      if (digit >= base) return punycode_bad_input;
+      if (digit > (maxint - i) / w) return punycode_overflow;
+      i += digit * w;
+      t = k <= bias /* + tmin */ ? tmin :     /* +tmin not needed */
+          k >= bias + tmax ? tmax : k - bias;
+      if (digit < t) break;
+      if (w > maxint / (base - t)) return punycode_overflow;
+      w *= (base - t);
+    }
+
+    bias = adapt(i - oldi, out + 1, oldi == 0);
+
+    /* i was supposed to wrap around from out+1 to 0,   */
+    /* incrementing n each time, so we'll fix that now: */
+
+    if (i / (out + 1) > maxint - n) return punycode_overflow;
+    n += i / (out + 1);
+    i %= (out + 1);
+
+    /* Insert n at position i of the output: */
+
+    /* not needed for Punycode: */
+    /* if (decode_digit(n) <= base) return punycode_invalid_input; */
+    if (out >= max_out) return punycode_big_output;
+
+    if (case_flags) {
+      memmove(case_flags + i + 1, case_flags + i, out - i);
+
+
+
+Costello                    Standards Track                    [Page 29]
+
+RFC 3492                     IDNA Punycode                    March 2003
+
+
+      /* Case of last character determines uppercase flag: */
+      case_flags[i] = flagged(input[in - 1]);
+    }
+
+    memmove(output + i + 1, output + i, (out - i) * sizeof *output);
+    output[i++] = n;
+  }
+
+  *output_length = out;
+  return punycode_success;
+}
+
+/******************************************************************/
+/* Wrapper for testing (would normally go in a separate .c file): */
+
+#include <assert.h>
+#include <stdio.h>
+#include <stdlib.h>
+#include <string.h>
+
+/* For testing, we'll just set some compile-time limits rather than */
+/* use malloc(), and set a compile-time option rather than using a  */
+/* command-line option.                                             */
+
+enum {
+  unicode_max_length = 256,
+  ace_max_length = 256
+};
+
+static void usage(char **argv)
+{
+  fprintf(stderr,
+    "\n"
+    "%s -e reads code points and writes a Punycode string.\n"
+    "%s -d reads a Punycode string and writes code points.\n"
+    "\n"
+    "Input and output are plain text in the native character set.\n"
+    "Code points are in the form u+hex separated by whitespace.\n"
+    "Although the specification allows Punycode strings to contain\n"
+    "any characters from the ASCII repertoire, this test code\n"
+    "supports only the printable characters, and needs the Punycode\n"
+    "string to be followed by a newline.\n"
+    "The case of the u in u+hex is the force-to-uppercase flag.\n"
+    , argv[0], argv[0]);
+  exit(EXIT_FAILURE);
+}
+
+static void fail(const char *msg)
+
+
+
+Costello                    Standards Track                    [Page 30]
+
+RFC 3492                     IDNA Punycode                    March 2003
+
+
+{
+  fputs(msg,stderr);
+  exit(EXIT_FAILURE);
+}
+
+static const char too_big[] =
+  "input or output is too large, recompile with larger limits\n";
+static const char invalid_input[] = "invalid input\n";
+static const char overflow[] = "arithmetic overflow\n";
+static const char io_error[] = "I/O error\n";
+
+/* The following string is used to convert printable */
+/* characters between ASCII and the native charset:  */
+
+static const char print_ascii[] =
+  "\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n"
+  "\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n"
+  " !\"#$%&'()*+,-./"
+  "0123456789:;<=>?"
+  "@ABCDEFGHIJKLMNO"
+  "PQRSTUVWXYZ[\\]^_"
+  "`abcdefghijklmno"
+  "pqrstuvwxyz{|}~\n";
+
+int main(int argc, char **argv)
+{
+  enum punycode_status status;
+  int r;
+  unsigned int input_length, output_length, j;
+  unsigned char case_flags[unicode_max_length];
+
+  if (argc != 2) usage(argv);
+  if (argv[1][0] != '-') usage(argv);
+  if (argv[1][2] != 0) usage(argv);
+
+  if (argv[1][1] == 'e') {
+    punycode_uint input[unicode_max_length];
+    unsigned long codept;
+    char output[ace_max_length+1], uplus[3];
+    int c;
+
+    /* Read the input code points: */
+
+    input_length = 0;
+
+    for (;;) {
+      r = scanf("%2s%lx", uplus, &codept);
+      if (ferror(stdin)) fail(io_error);
+
+
+
+Costello                    Standards Track                    [Page 31]
+
+RFC 3492                     IDNA Punycode                    March 2003
+
+
+      if (r == EOF || r == 0) break;
+
+      if (r != 2 || uplus[1] != '+' || codept > (punycode_uint)-1) {
+        fail(invalid_input);
+      }
+
+      if (input_length == unicode_max_length) fail(too_big);
+
+      if (uplus[0] == 'u') case_flags[input_length] = 0;
+      else if (uplus[0] == 'U') case_flags[input_length] = 1;
+      else fail(invalid_input);
+
+      input[input_length++] = codept;
+    }
+
+    /* Encode: */
+
+    output_length = ace_max_length;
+    status = punycode_encode(input_length, input, case_flags,
+                             &output_length, output);
+    if (status == punycode_bad_input) fail(invalid_input);
+    if (status == punycode_big_output) fail(too_big);
+    if (status == punycode_overflow) fail(overflow);
+    assert(status == punycode_success);
+
+    /* Convert to native charset and output: */
+
+    for (j = 0;  j < output_length;  ++j) {
+      c = output[j];
+      assert(c >= 0 && c <= 127);
+      if (print_ascii[c] == 0) fail(invalid_input);
+      output[j] = print_ascii[c];
+    }
+
+    output[j] = 0;
+    r = puts(output);
+    if (r == EOF) fail(io_error);
+    return EXIT_SUCCESS;
+  }
+
+  if (argv[1][1] == 'd') {
+    char input[ace_max_length+2], *p, *pp;
+    punycode_uint output[unicode_max_length];
+
+    /* Read the Punycode input string and convert to ASCII: */
+
+    fgets(input, ace_max_length+2, stdin);
+    if (ferror(stdin)) fail(io_error);
+
+
+
+Costello                    Standards Track                    [Page 32]
+
+RFC 3492                     IDNA Punycode                    March 2003
+
+
+    if (feof(stdin)) fail(invalid_input);
+    input_length = strlen(input) - 1;
+    if (input[input_length] != '\n') fail(too_big);
+    input[input_length] = 0;
+
+    for (p = input;  *p != 0;  ++p) {
+      pp = strchr(print_ascii, *p);
+      if (pp == 0) fail(invalid_input);
+      *p = pp - print_ascii;
+    }
+
+    /* Decode: */
+
+    output_length = unicode_max_length;
+    status = punycode_decode(input_length, input, &output_length,
+                             output, case_flags);
+    if (status == punycode_bad_input) fail(invalid_input);
+    if (status == punycode_big_output) fail(too_big);
+    if (status == punycode_overflow) fail(overflow);
+    assert(status == punycode_success);
+
+    /* Output the result: */
+
+    for (j = 0;  j < output_length;  ++j) {
+      r = printf("%s+%04lX\n",
+                 case_flags[j] ? "U" : "u",
+                 (unsigned long) output[j] );
+      if (r < 0) fail(io_error);
+    }
+
+    return EXIT_SUCCESS;
+  }
+
+  usage(argv);
+  return EXIT_SUCCESS;  /* not reached, but quiets compiler warning */
+}
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Costello                    Standards Track                    [Page 33]
+
+RFC 3492                     IDNA Punycode                    March 2003
+
+
+Author's Address
+
+   Adam M. Costello
+   University of California, Berkeley
+   http://www.nicemice.net/amc/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Costello                    Standards Track                    [Page 34]
+
+RFC 3492                     IDNA Punycode                    March 2003
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2003).  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 Standards process must be
+   followed, or as required to translate it into 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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Costello                    Standards Track                    [Page 35]
+
diff --git a/doc/rfc/rfc3493.txt b/doc/rfc/rfc3493.txt
new file mode 100644
index 0000000..5fea6c1
--- /dev/null
+++ b/doc/rfc/rfc3493.txt
@@ -0,0 +1,2187 @@
+
+
+
+
+
+
+Network Working Group                                        R. Gilligan
+Request for Comments: 3493                                Intransa, Inc.
+Obsoletes: 2553                                               S. Thomson
+Category: Informational                                            Cisco
+                                                                J. Bound
+                                                               J. McCann
+                                                         Hewlett-Packard
+                                                              W. Stevens
+                                                           February 2003
+
+
+               Basic Socket Interface Extensions for IPv6
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2003).  All Rights Reserved.
+
+Abstract
+
+   The de facto standard Application Program Interface (API) for TCP/IP
+   applications is the "sockets" interface.  Although this API was
+   developed for Unix in the early 1980s it has also been implemented on
+   a wide variety of non-Unix systems.  TCP/IP applications written
+   using the sockets API have in the past enjoyed a high degree of
+   portability and we would like the same portability with IPv6
+   applications.  But changes are required to the sockets API to support
+   IPv6 and this memo describes these changes.  These include a new
+   socket address structure to carry IPv6 addresses, new address
+   conversion functions, and some new socket options.  These extensions
+   are designed to provide access to the basic IPv6 features required by
+   TCP and UDP applications, including multicasting, while introducing a
+   minimum of change into the system and providing complete
+   compatibility for existing IPv4 applications.  Additional extensions
+   for advanced IPv6 features (raw sockets and access to the IPv6
+   extension headers) are defined in another document.
+
+
+
+
+
+
+
+
+
+
+Gilligan, et al.             Informational                      [Page 1]
+
+RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
+
+
+Table of Contents
+
+   1.  Introduction................................................3
+   2.  Design Considerations.......................................4
+       2.1  What Needs to be Changed...............................4
+       2.2  Data Types.............................................6
+       2.3  Headers................................................6
+       2.4  Structures.............................................6
+   3.  Socket Interface............................................6
+       3.1  IPv6 Address Family and Protocol Family................6
+       3.2  IPv6 Address Structure.................................7
+       3.3  Socket Address Structure for 4.3BSD-Based Systems......7
+       3.4  Socket Address Structure for 4.4BSD-Based Systems......9
+       3.5  The Socket Functions...................................9
+       3.6  Compatibility with IPv4 Applications..................10
+       3.7  Compatibility with IPv4 Nodes.........................11
+       3.8  IPv6 Wildcard Address.................................11
+       3.9  IPv6 Loopback Address.................................13
+       3.10 Portability Additions.................................14
+   4.  Interface Identification...................................16
+       4.1  Name-to-Index.........................................17
+       4.2  Index-to-Name.........................................17
+       4.3  Return All Interface Names and Indexes................18
+       4.4  Free Memory...........................................18
+   5.  Socket Options.............................................18
+       5.1  Unicast Hop Limit.....................................19
+       5.2  Sending and Receiving Multicast Packets...............19
+       5.3  IPV6_V6ONLY option for AF_INET6 Sockets...............22
+   6.  Library Functions..........................................22
+       6.1  Protocol-Independent Nodename and
+            Service Name Translation..............................23
+       6.2  Socket Address Structure to Node Name
+            and Service Name......................................28
+       6.3  Address Conversion Functions..........................31
+       6.4  Address Testing Macros................................33
+   7.  Summary of New Definitions.................................33
+   8.  Security Considerations....................................35
+   9.  Changes from RFC 2553......................................35
+   10. Acknowledgments............................................36
+   11. References.................................................37
+   12. Authors' Addresses.........................................38
+   13. Full Copyright Statement...................................39
+
+
+
+
+
+
+
+
+
+Gilligan, et al.             Informational                      [Page 2]
+
+RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
+
+
+1. Introduction
+
+   While IPv4 addresses are 32 bits long, IPv6 addresses are 128 bits
+   long.  The socket interface makes the size of an IP address quite
+   visible to an application; virtually all TCP/IP applications for
+   BSD-based systems have knowledge of the size of an IP address.  Those
+   parts of the API that expose the addresses must be changed to
+   accommodate the larger IPv6 address size.  IPv6 also introduces new
+   features, some of which must be made visible to applications via the
+   API.  This memo defines a set of extensions to the socket interface
+   to support the larger address size and new features of IPv6.  It
+   defines "basic" extensions that are of use to a broad range of
+   applications.  A companion document, the "advanced" API [4], covers
+   extensions that are of use to more specialized applications, examples
+   of which include routing daemons, and the "ping" and "traceroute"
+   utilities.
+
+   The development of this API was started in 1994 in the IETF IPng
+   working group.  The API has evolved over the years, published first
+   in RFC 2133, then again in RFC 2553, and reaching its final form in
+   this document.
+
+   As the API matured and stabilized, it was incorporated into the Open
+   Group's Networking Services (XNS) specification, issue 5.2, which was
+   subsequently incorporated into a joint Open Group/IEEE/ISO standard
+   [3].
+
+   Effort has been made to ensure that this document and [3] contain the
+   same information with regard to the API definitions.  However, the
+   reader should note that this document is for informational purposes
+   only, and that the official standard specification of the sockets API
+   is [3].
+
+   It is expected that any future standardization work on this API would
+   be done by the Open Group Base Working Group [6].
+
+   It should also be noted that this document describes only those
+   portions of the API needed for IPv4 and IPv6 communications.  Other
+   potential uses of the API, for example the use of getaddrinfo() and
+   getnameinfo() with the AF_UNIX address family, are beyond the scope
+   of this document.
+
+
+
+
+
+
+
+
+
+
+Gilligan, et al.             Informational                      [Page 3]
+
+RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
+
+
+2. Design Considerations
+
+   There are a number of important considerations in designing changes
+   to this well-worn API:
+
+   -  The API changes should provide both source and binary
+      compatibility for programs written to the original API.  That is,
+      existing program binaries should continue to operate when run on a
+      system supporting the new API.  In addition, existing applications
+      that are re-compiled and run on a system supporting the new API
+      should continue to operate.  Simply put, the API changes for IPv6
+      should not break existing programs.  An additional mechanism for
+      implementations to verify this is to verify the new symbols are
+      protected by Feature Test Macros as described in [3].  (Such
+      Feature Test Macros are not defined by this RFC.)
+
+   -  The changes to the API should be as small as possible in order to
+      simplify the task of converting existing IPv4 applications to
+      IPv6.
+
+   -  Where possible, applications should be able to use this API to
+      interoperate with both IPv6 and IPv4 hosts.  Applications should
+      not need to know which type of host they are communicating with.
+
+   -  IPv6 addresses carried in data structures should be 64-bit
+      aligned.  This is necessary in order to obtain optimum performance
+      on 64-bit machine architectures.
+
+   Because of the importance of providing IPv4 compatibility in the API,
+   these extensions are explicitly designed to operate on machines that
+   provide complete support for both IPv4 and IPv6.  A subset of this
+   API could probably be designed for operation on systems that support
+   only IPv6.  However, this is not addressed in this memo.
+
+2.1 What Needs to be Changed
+
+   The socket interface API consists of a few distinct components:
+
+   -  Core socket functions.
+
+   -  Address data structures.
+
+   -  Name-to-address translation functions.
+
+   -  Address conversion functions.
+
+
+
+
+
+
+Gilligan, et al.             Informational                      [Page 4]
+
+RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
+
+
+   The core socket functions -- those functions that deal with such
+   things as setting up and tearing down TCP connections, and sending
+   and receiving UDP packets -- were designed to be transport
+   independent.  Where protocol addresses are passed as function
+   arguments, they are carried via opaque pointers.  A protocol-specific
+   address data structure is defined for each protocol that the socket
+   functions support.  Applications must cast pointers to these
+   protocol-specific address structures into pointers to the generic
+   "sockaddr" address structure when using the socket functions.  These
+   functions need not change for IPv6, but a new IPv6-specific address
+   data structure is needed.
+
+   The "sockaddr_in" structure is the protocol-specific data structure
+   for IPv4.  This data structure actually includes 8-octets of unused
+   space, and it is tempting to try to use this space to adapt the
+   sockaddr_in structure to IPv6.  Unfortunately, the sockaddr_in
+   structure is not large enough to hold the 16-octet IPv6 address as
+   well as the other information (address family and port number) that
+   is needed.  So a new address data structure must be defined for IPv6.
+
+   IPv6 addresses are scoped [2] so they could be link-local, site,
+   organization, global, or other scopes at this time undefined.  To
+   support applications that want to be able to identify a set of
+   interfaces for a specific scope, the IPv6 sockaddr_in structure must
+   support a field that can be used by an implementation to identify a
+   set of interfaces identifying the scope for an IPv6 address.
+
+   The IPv4 name-to-address translation functions in the socket
+   interface are gethostbyname() and gethostbyaddr().  These are left as
+   is, and new functions are defined which support both IPv4 and IPv6.
+
+   The IPv4 address conversion functions -- inet_ntoa() and inet_addr()
+   -- convert IPv4 addresses between binary and printable form.  These
+   functions are quite specific to 32-bit IPv4 addresses.  We have
+   designed two analogous functions that convert both IPv4 and IPv6
+   addresses, and carry an address type parameter so that they can be
+   extended to other protocol families as well.
+
+   Finally, a few miscellaneous features are needed to support IPv6.  A
+   new interface is needed to support the IPv6 hop limit header field.
+   New socket options are needed to control the sending and receiving of
+   IPv6 multicast packets.
+
+   The socket interface will be enhanced in the future to provide access
+   to other IPv6 features.  Some of these extensions are described in
+   [4].
+
+
+
+
+
+Gilligan, et al.             Informational                      [Page 5]
+
+RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
+
+
+2.2 Data Types
+
+   The data types of the structure elements given in this memo are
+   intended to track the relevant standards.  uintN_t means an unsigned
+   integer of exactly N bits (e.g., uint16_t).  The sa_family_t and
+   in_port_t types are defined in [3].
+
+2.3 Headers
+
+   When function prototypes and structures are shown we show the headers
+   that must be #included to cause that item to be defined.
+
+2.4 Structures
+
+   When structures are described the members shown are the ones that
+   must appear in an implementation.  Additional, nonstandard members
+   may also be defined by an implementation.  As an additional
+   precaution nonstandard members could be verified by Feature Test
+   Macros as described in [3].  (Such Feature Test Macros are not
+   defined by this RFC.)
+
+   The ordering shown for the members of a structure is the recommended
+   ordering, given alignment considerations of multibyte members, but an
+   implementation may order the members differently.
+
+3. Socket Interface
+
+   This section specifies the socket interface changes for IPv6.
+
+3.1 IPv6 Address Family and Protocol Family
+
+   A new address family name, AF_INET6, is defined in <sys/socket.h>.
+   The AF_INET6 definition distinguishes between the original
+   sockaddr_in address data structure, and the new sockaddr_in6 data
+   structure.
+
+   A new protocol family name, PF_INET6, is defined in <sys/socket.h>.
+   Like most of the other protocol family names, this will usually be
+   defined to have the same value as the corresponding address family
+   name:
+
+      #define PF_INET6        AF_INET6
+
+   The AF_INET6 is used in the first argument to the socket() function
+   to indicate that an IPv6 socket is being created.
+
+
+
+
+
+
+Gilligan, et al.             Informational                      [Page 6]
+
+RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
+
+
+3.2 IPv6 Address Structure
+
+   A new in6_addr structure holds a single IPv6 address and is defined
+   as a result of including <netinet/in.h>:
+
+      struct in6_addr {
+          uint8_t  s6_addr[16];      /* IPv6 address */
+      };
+
+   This data structure contains an array of sixteen 8-bit elements,
+   which make up one 128-bit IPv6 address.  The IPv6 address is stored
+   in network byte order.
+
+   The structure in6_addr above is usually implemented with an embedded
+   union with extra fields that force the desired alignment level in a
+   manner similar to BSD implementations of "struct in_addr".  Those
+   additional implementation details are omitted here for simplicity.
+
+   An example is as follows:
+
+   struct in6_addr {
+        union {
+            uint8_t  _S6_u8[16];
+            uint32_t _S6_u32[4];
+            uint64_t _S6_u64[2];
+        } _S6_un;
+   };
+   #define s6_addr _S6_un._S6_u8
+
+3.3 Socket Address Structure for 4.3BSD-Based Systems
+
+   In the socket interface, a different protocol-specific data structure
+   is defined to carry the addresses for each protocol suite.  Each
+   protocol-specific data structure is designed so it can be cast into a
+   protocol-independent data structure -- the "sockaddr" structure.
+   Each has a "family" field that overlays the "sa_family" of the
+   sockaddr data structure.  This field identifies the type of the data
+   structure.
+
+   The sockaddr_in structure is the protocol-specific address data
+   structure for IPv4.  It is used to pass addresses between
+   applications and the system in the socket functions.  The following
+   sockaddr_in6 structure holds IPv6 addresses and is defined as a
+   result of including the <netinet/in.h> header:
+
+
+
+
+
+
+
+Gilligan, et al.             Informational                      [Page 7]
+
+RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
+
+
+struct sockaddr_in6 {
+    sa_family_t     sin6_family;    /* AF_INET6 */
+    in_port_t       sin6_port;      /* transport layer port # */
+    uint32_t        sin6_flowinfo;  /* IPv6 flow information */
+    struct in6_addr sin6_addr;      /* IPv6 address */
+    uint32_t        sin6_scope_id;  /* set of interfaces for a scope */
+};
+
+   This structure is designed to be compatible with the sockaddr data
+   structure used in the 4.3BSD release.
+
+   The sin6_family field identifies this as a sockaddr_in6 structure.
+   This field overlays the sa_family field when the buffer is cast to a
+   sockaddr data structure.  The value of this field must be AF_INET6.
+
+   The sin6_port field contains the 16-bit UDP or TCP port number.  This
+   field is used in the same way as the sin_port field of the
+   sockaddr_in structure.  The port number is stored in network byte
+   order.
+
+   The sin6_flowinfo field is a 32-bit field intended to contain flow-
+   related information.  The exact way this field is mapped to or from a
+   packet is not currently specified.  Until such time as its use is
+   specified, applications should set this field to zero when
+   constructing a sockaddr_in6, and ignore this field in a sockaddr_in6
+   structure constructed by the system.
+
+   The sin6_addr field is a single in6_addr structure (defined in the
+   previous section).  This field holds one 128-bit IPv6 address.  The
+   address is stored in network byte order.
+
+   The ordering of elements in this structure is specifically designed
+   so that when sin6_addr field is aligned on a 64-bit boundary, the
+   start of the structure will also be aligned on a 64-bit boundary.
+   This is done for optimum performance on 64-bit architectures.
+
+   The sin6_scope_id field is a 32-bit integer that identifies a set of
+   interfaces as appropriate for the scope [2] of the address carried in
+   the sin6_addr field.  The mapping of sin6_scope_id to an interface or
+   set of interfaces is left to implementation and future specifications
+   on the subject of scoped addresses.
+
+   Notice that the sockaddr_in6 structure will normally be larger than
+   the generic sockaddr structure.  On many existing implementations the
+   sizeof(struct sockaddr_in) equals sizeof(struct sockaddr), with both
+   being 16 bytes.  Any existing code that makes this assumption needs
+   to be examined carefully when converting to IPv6.
+
+
+
+
+Gilligan, et al.             Informational                      [Page 8]
+
+RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
+
+
+3.4 Socket Address Structure for 4.4BSD-Based Systems
+
+   The 4.4BSD release includes a small, but incompatible change to the
+   socket interface.  The "sa_family" field of the sockaddr data
+   structure was changed from a 16-bit value to an 8-bit value, and the
+   space saved used to hold a length field, named "sa_len".  The
+   sockaddr_in6 data structure given in the previous section cannot be
+   correctly cast into the newer sockaddr data structure.  For this
+   reason, the following alternative IPv6 address data structure is
+   provided to be used on systems based on 4.4BSD.  It is defined as a
+   result of including the <netinet/in.h> header.
+
+struct sockaddr_in6 {
+    uint8_t         sin6_len;       /* length of this struct */
+    sa_family_t     sin6_family;    /* AF_INET6 */
+    in_port_t       sin6_port;      /* transport layer port # */
+    uint32_t        sin6_flowinfo;  /* IPv6 flow information */
+    struct in6_addr sin6_addr;      /* IPv6 address */
+    uint32_t        sin6_scope_id;  /* set of interfaces for a scope */
+};
+
+   The only differences between this data structure and the 4.3BSD
+   variant are the inclusion of the length field, and the change of the
+   family field to a 8-bit data type.  The definitions of all the other
+   fields are identical to the structure defined in the previous
+   section.
+
+   Systems that provide this version of the sockaddr_in6 data structure
+   must also declare SIN6_LEN as a result of including the
+   <netinet/in.h> header.  This macro allows applications to determine
+   whether they are being built on a system that supports the 4.3BSD or
+   4.4BSD variants of the data structure.
+
+3.5 The Socket Functions
+
+   Applications call the socket() function to create a socket descriptor
+   that represents a communication endpoint.  The arguments to the
+   socket() function tell the system which protocol to use, and what
+   format address structure will be used in subsequent functions.  For
+   example, to create an IPv4/TCP socket, applications make the call:
+
+      s = socket(AF_INET, SOCK_STREAM, 0);
+
+   To create an IPv4/UDP socket, applications make the call:
+
+      s = socket(AF_INET, SOCK_DGRAM, 0);
+
+
+
+
+
+Gilligan, et al.             Informational                      [Page 9]
+
+RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
+
+
+   Applications may create IPv6/TCP and IPv6/UDP sockets (which may also
+   handle IPv4 communication as described in section 3.7) by simply
+   using the constant AF_INET6 instead of AF_INET in the first argument.
+   For example, to create an IPv6/TCP socket, applications make the
+   call:
+
+      s = socket(AF_INET6, SOCK_STREAM, 0);
+
+   To create an IPv6/UDP socket, applications make the call:
+
+      s = socket(AF_INET6, SOCK_DGRAM, 0);
+
+   Once the application has created a AF_INET6 socket, it must use the
+   sockaddr_in6 address structure when passing addresses in to the
+   system.  The functions that the application uses to pass addresses
+   into the system are:
+
+      bind()
+      connect()
+      sendmsg()
+      sendto()
+
+   The system will use the sockaddr_in6 address structure to return
+   addresses to applications that are using AF_INET6 sockets.  The
+   functions that return an address from the system to an application
+   are:
+
+      accept()
+      recvfrom()
+      recvmsg()
+      getpeername()
+      getsockname()
+
+   No changes to the syntax of the socket functions are needed to
+   support IPv6, since all of the "address carrying" functions use an
+   opaque address pointer, and carry an address length as a function
+   argument.
+
+3.6 Compatibility with IPv4 Applications
+
+   In order to support the large base of applications using the original
+   API, system implementations must provide complete source and binary
+   compatibility with the original API.  This means that systems must
+   continue to support AF_INET sockets and the sockaddr_in address
+   structure.  Applications must be able to create IPv4/TCP and IPv4/UDP
+   sockets using the AF_INET constant in the socket() function, as
+
+
+
+
+
+Gilligan, et al.             Informational                     [Page 10]
+
+RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
+
+
+   described in the previous section.  Applications should be able to
+   hold a combination of IPv4/TCP, IPv4/UDP, IPv6/TCP and IPv6/UDP
+   sockets simultaneously within the same process.
+
+   Applications using the original API should continue to operate as
+   they did on systems supporting only IPv4.  That is, they should
+   continue to interoperate with IPv4 nodes.
+
+3.7 Compatibility with IPv4 Nodes
+
+   The API also provides a different type of compatibility: the ability
+   for IPv6 applications to interoperate with IPv4 applications.  This
+   feature uses the IPv4-mapped IPv6 address format defined in the IPv6
+   addressing architecture specification [2].  This address format
+   allows the IPv4 address of an IPv4 node to be represented as an IPv6
+   address.  The IPv4 address is encoded into the low-order 32 bits of
+   the IPv6 address, and the high-order 96 bits hold the fixed prefix
+   0:0:0:0:0:FFFF.  IPv4-mapped addresses are written as follows:
+
+      ::FFFF:<IPv4-address>
+
+   These addresses can be generated automatically by the getaddrinfo()
+   function, as described in Section 6.1.
+
+   Applications may use AF_INET6 sockets to open TCP connections to IPv4
+   nodes, or send UDP packets to IPv4 nodes, by simply encoding the
+   destination's IPv4 address as an IPv4-mapped IPv6 address, and
+   passing that address, within a sockaddr_in6 structure, in the
+   connect() or sendto() call.  When applications use AF_INET6 sockets
+   to accept TCP connections from IPv4 nodes, or receive UDP packets
+   from IPv4 nodes, the system returns the peer's address to the
+   application in the accept(), recvfrom(), or getpeername() call using
+   a sockaddr_in6 structure encoded this way.
+
+   Few applications will likely need to know which type of node they are
+   interoperating with.  However, for those applications that do need to
+   know, the IN6_IS_ADDR_V4MAPPED() macro, defined in Section 6.4, is
+   provided.
+
+3.8 IPv6 Wildcard Address
+
+   While the bind() function allows applications to select the source IP
+   address of UDP packets and TCP connections, applications often want
+   the system to select the source address for them.  With IPv4, one
+   specifies the address as the symbolic constant INADDR_ANY (called the
+   "wildcard" address) in the bind() call, or simply omits the bind()
+   entirely.
+
+
+
+
+Gilligan, et al.             Informational                     [Page 11]
+
+RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
+
+
+   Since the IPv6 address type is a structure (struct in6_addr), a
+   symbolic constant can be used to initialize an IPv6 address variable,
+   but cannot be used in an assignment.  Therefore systems provide the
+   IPv6 wildcard address in two forms.
+
+   The first version is a global variable named "in6addr_any" that is an
+   in6_addr structure.  The extern declaration for this variable is
+   defined in <netinet/in.h>:
+
+      extern const struct in6_addr in6addr_any;
+
+   Applications use in6addr_any similarly to the way they use INADDR_ANY
+   in IPv4.  For example, to bind a socket to port number 23, but let
+   the system select the source address, an application could use the
+   following code:
+
+      struct sockaddr_in6 sin6;
+       . . .
+      sin6.sin6_family = AF_INET6;
+      sin6.sin6_flowinfo = 0;
+      sin6.sin6_port = htons(23);
+      sin6.sin6_addr = in6addr_any;  /* structure assignment */
+       . . .
+      if (bind(s, (struct sockaddr *) &sin6, sizeof(sin6)) == -1)
+              . . .
+
+   The other version is a symbolic constant named IN6ADDR_ANY_INIT and
+   is defined in <netinet/in.h>.  This constant can be used to
+   initialize an in6_addr structure:
+
+      struct in6_addr anyaddr = IN6ADDR_ANY_INIT;
+
+   Note that this constant can be used ONLY at declaration time.  It can
+   not be used to assign a previously declared in6_addr structure.  For
+   example, the following code will not work:
+
+      /* This is the WRONG way to assign an unspecified address */
+      struct sockaddr_in6 sin6;
+       . . .
+      sin6.sin6_addr = IN6ADDR_ANY_INIT; /* will NOT compile */
+
+   Be aware that the IPv4 INADDR_xxx constants are all defined in host
+   byte order but the IPv6 IN6ADDR_xxx constants and the IPv6
+   in6addr_xxx externals are defined in network byte order.
+
+
+
+
+
+
+
+Gilligan, et al.             Informational                     [Page 12]
+
+RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
+
+
+3.9 IPv6 Loopback Address
+
+   Applications may need to send UDP packets to, or originate TCP
+   connections to, services residing on the local node.  In IPv4, they
+   can do this by using the constant IPv4 address INADDR_LOOPBACK in
+   their connect(), sendto(), or sendmsg() call.
+
+   IPv6 also provides a loopback address to contact local TCP and UDP
+   services.  Like the unspecified address, the IPv6 loopback address is
+   provided in two forms -- a global variable and a symbolic constant.
+
+   The global variable is an in6_addr structure named
+   "in6addr_loopback."  The extern declaration for this variable is
+   defined in <netinet/in.h>:
+
+      extern const struct in6_addr in6addr_loopback;
+
+   Applications use in6addr_loopback as they would use INADDR_LOOPBACK
+   in IPv4 applications (but beware of the byte ordering difference
+   mentioned at the end of the previous section).  For example, to open
+   a TCP connection to the local telnet server, an application could use
+   the following code:
+
+   struct sockaddr_in6 sin6;
+    . . .
+   sin6.sin6_family = AF_INET6;
+   sin6.sin6_flowinfo = 0;
+   sin6.sin6_port = htons(23);
+   sin6.sin6_addr = in6addr_loopback;  /* structure assignment */
+    . . .
+   if (connect(s, (struct sockaddr *) &sin6, sizeof(sin6)) == -1)
+           . . .
+
+   The symbolic constant is named IN6ADDR_LOOPBACK_INIT and is defined
+   in <netinet/in.h>.  It can be used at declaration time ONLY; for
+   example:
+
+      struct in6_addr loopbackaddr = IN6ADDR_LOOPBACK_INIT;
+
+   Like IN6ADDR_ANY_INIT, this constant cannot be used in an assignment
+   to a previously declared IPv6 address variable.
+
+
+
+
+
+
+
+
+
+
+Gilligan, et al.             Informational                     [Page 13]
+
+RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
+
+
+3.10 Portability Additions
+
+   One simple addition to the sockets API that can help application
+   writers is the "struct sockaddr_storage".  This data structure can
+   simplify writing code that is portable across multiple address
+   families and platforms.  This data structure is designed with the
+   following goals.
+
+   - Large enough to accommodate all supported protocol-specific address
+      structures.
+
+   - Aligned at an appropriate boundary so that pointers to it can be
+      cast as pointers to protocol specific address structures and used
+      to access the fields of those structures without alignment
+      problems.
+
+   The sockaddr_storage structure contains field ss_family which is of
+   type sa_family_t.  When a sockaddr_storage structure is cast to a
+   sockaddr structure, the ss_family field of the sockaddr_storage
+   structure maps onto the sa_family field of the sockaddr structure.
+   When a sockaddr_storage structure is cast as a protocol specific
+   address structure, the ss_family field maps onto a field of that
+   structure that is of type sa_family_t and that identifies the
+   protocol's address family.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gilligan, et al.             Informational                     [Page 14]
+
+RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
+
+
+   An example implementation design of such a data structure would be as
+   follows.
+
+/*
+ * Desired design of maximum size and alignment
+ */
+#define _SS_MAXSIZE    128  /* Implementation specific max size */
+#define _SS_ALIGNSIZE  (sizeof (int64_t))
+                         /* Implementation specific desired alignment */
+/*
+ * Definitions used for sockaddr_storage structure paddings design.
+ */
+#define _SS_PAD1SIZE   (_SS_ALIGNSIZE - sizeof (sa_family_t))
+#define _SS_PAD2SIZE   (_SS_MAXSIZE - (sizeof (sa_family_t) +
+                              _SS_PAD1SIZE + _SS_ALIGNSIZE))
+struct sockaddr_storage {
+    sa_family_t  ss_family;     /* address family */
+    /* Following fields are implementation specific */
+    char      __ss_pad1[_SS_PAD1SIZE];
+              /* 6 byte pad, this is to make implementation
+              /* specific pad up to alignment field that */
+              /* follows explicit in the data structure */
+    int64_t   __ss_align;     /* field to force desired structure */
+               /* storage alignment */
+    char      __ss_pad2[_SS_PAD2SIZE];
+              /* 112 byte pad to achieve desired size, */
+              /* _SS_MAXSIZE value minus size of ss_family */
+              /* __ss_pad1, __ss_align fields is 112 */
+};
+
+   The above example implementation illustrates a data structure which
+   will align on a 64-bit boundary.  An implementation-specific field
+   "__ss_align" along with "__ss_pad1" is used to force a 64-bit
+   alignment which covers proper alignment good enough for the needs of
+   sockaddr_in6 (IPv6), sockaddr_in (IPv4) address data structures.  The
+   size of padding field __ss_pad1 depends on the chosen alignment
+   boundary.  The size of padding field __ss_pad2 depends on the value
+   of overall size chosen for the total size of the structure.  This
+   size and alignment are represented in the above example by
+   implementation specific (not required) constants _SS_MAXSIZE (chosen
+   value 128) and _SS_ALIGNSIZE (with chosen value 8).  Constants
+   _SS_PAD1SIZE (derived value 6) and _SS_PAD2SIZE (derived value 112)
+   are also for illustration and not required.  The derived values
+   assume sa_family_t is 2 bytes.  The implementation specific
+   definitions and structure field names above start with an underscore
+   to denote implementation private namespace.  Portable code is not
+   expected to access or reference those fields or constants.
+
+
+
+
+Gilligan, et al.             Informational                     [Page 15]
+
+RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
+
+
+   On implementations where the sockaddr data structure includes a
+   "sa_len" field this data structure would look like this:
+
+/*
+ * Definitions used for sockaddr_storage structure paddings design.
+ */
+#define _SS_PAD1SIZE (_SS_ALIGNSIZE -
+                            (sizeof (uint8_t) + sizeof (sa_family_t))
+#define _SS_PAD2SIZE (_SS_MAXSIZE -
+                            (sizeof (uint8_t) + sizeof (sa_family_t) +
+                             _SS_PAD1SIZE + _SS_ALIGNSIZE))
+struct sockaddr_storage {
+    uint8_t      ss_len;        /* address length */
+    sa_family_t  ss_family;     /* address family */
+    /* Following fields are implementation specific */
+    char         __ss_pad1[_SS_PAD1SIZE];
+                  /* 6 byte pad, this is to make implementation
+                  /* specific pad up to alignment field that */
+                  /* follows explicit in the data structure */
+    int64_t      __ss_align;  /* field to force desired structure */
+                  /* storage alignment */
+    char         __ss_pad2[_SS_PAD2SIZE];
+                  /* 112 byte pad to achieve desired size, */
+                  /* _SS_MAXSIZE value minus size of ss_len, */
+                  /* __ss_family, __ss_pad1, __ss_align fields is 112 */
+};
+
+4. Interface Identification
+
+   This API uses an interface index (a small positive integer) to
+   identify the local interface on which a multicast group is joined
+   (Section 5.2).  Additionally, the advanced API [4] uses these same
+   interface indexes to identify the interface on which a datagram is
+   received, or to specify the interface on which a datagram is to be
+   sent.
+
+   Interfaces are normally known by names such as "le0", "sl1", "ppp2",
+   and the like.  On Berkeley-derived implementations, when an interface
+   is made known to the system, the kernel assigns a unique positive
+   integer value (called the interface index) to that interface.  These
+   are small positive integers that start at 1.  (Note that 0 is never
+   used for an interface index.)  There may be gaps so that there is no
+   current interface for a particular positive interface index.
+
+   This API defines two functions that map between an interface name and
+   index, a third function that returns all the interface names and
+   indexes, and a fourth function to return the dynamic memory allocated
+   by the previous function.  How these functions are implemented is
+
+
+
+Gilligan, et al.             Informational                     [Page 16]
+
+RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
+
+
+   left up to the implementation.  4.4BSD implementations can implement
+   these functions using the existing sysctl() function with the
+   NET_RT_IFLIST command.  Other implementations may wish to use ioctl()
+   for this purpose.
+
+4.1 Name-to-Index
+
+   The first function maps an interface name into its corresponding
+   index.
+
+      #include <net/if.h>
+
+      unsigned int  if_nametoindex(const char *ifname);
+
+   If ifname is the name of an interface, the if_nametoindex() function
+   shall return the interface index corresponding to name ifname;
+   otherwise, it shall return zero.  No errors are defined.
+
+4.2 Index-to-Name
+
+   The second function maps an interface index into its corresponding
+   name.
+
+      #include <net/if.h>
+
+      char  *if_indextoname(unsigned int ifindex, char *ifname);
+
+   When this function is called, the ifname argument shall point to a
+   buffer of at least IF_NAMESIZE bytes.  The function shall place in
+   this buffer the name of the interface with index ifindex.
+   (IF_NAMESIZE is also defined in <net/if.h> and its value includes a
+   terminating null byte at the end of the interface name.)  If ifindex
+   is an interface index, then the function shall return the value
+   supplied in ifname, which points to a buffer now containing the
+   interface name.  Otherwise, the function shall return a NULL pointer
+   and set errno to indicate the error.  If there is no interface
+   corresponding to the specified index, errno is set to ENXIO.  If
+   there was a system error (such as running out of memory), errno would
+   be set to the proper value (e.g., ENOMEM).
+
+
+
+
+
+
+
+
+
+
+
+
+Gilligan, et al.             Informational                     [Page 17]
+
+RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
+
+
+4.3 Return All Interface Names and Indexes
+
+   The if_nameindex structure holds the information about a single
+   interface and is defined as a result of including the <net/if.h>
+   header.
+
+   struct if_nameindex {
+     unsigned int   if_index;  /* 1, 2, ... */
+     char          *if_name;   /* null terminated name: "le0", ... */
+   };
+
+   The final function returns an array of if_nameindex structures, one
+   structure per interface.
+
+      #include <net/if.h>
+
+      struct if_nameindex  *if_nameindex(void);
+
+   The end of the array of structures is indicated by a structure with
+   an if_index of 0 and an if_name of NULL.  The function returns a NULL
+   pointer upon an error, and would set errno to the appropriate value.
+
+   The memory used for this array of structures along with the interface
+   names pointed to by the if_name members is obtained dynamically.
+   This memory is freed by the next function.
+
+4.4 Free Memory
+
+   The following function frees the dynamic memory that was allocated by
+   if_nameindex().
+
+      #include <net/if.h>
+
+      void  if_freenameindex(struct if_nameindex *ptr);
+
+   The ptr argument shall be a pointer that was returned by
+   if_nameindex().  After if_freenameindex() has been called, the
+   application shall not use the array of which ptr is the address.
+
+5. Socket Options
+
+   A number of new socket options are defined for IPv6.  All of these
+   new options are at the IPPROTO_IPV6 level.  That is, the "level"
+   parameter in the getsockopt() and setsockopt() calls is IPPROTO_IPV6
+   when using these options.  The constant name prefix IPV6_ is used in
+   all of the new socket options.  This serves to clearly identify these
+   options as applying to IPv6.
+
+
+
+
+Gilligan, et al.             Informational                     [Page 18]
+
+RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
+
+
+   The declaration for IPPROTO_IPV6, the new IPv6 socket options, and
+   related constants defined in this section are obtained by including
+   the header <netinet/in.h>.
+
+5.1 Unicast Hop Limit
+
+   A new setsockopt() option controls the hop limit used in outgoing
+   unicast IPv6 packets.  The name of this option is IPV6_UNICAST_HOPS,
+   and it is used at the IPPROTO_IPV6 layer.  The following example
+   illustrates how it is used:
+
+   int  hoplimit = 10;
+
+   if (setsockopt(s, IPPROTO_IPV6, IPV6_UNICAST_HOPS,
+                  (char *) &hoplimit, sizeof(hoplimit)) == -1)
+       perror("setsockopt IPV6_UNICAST_HOPS");
+
+   When the IPV6_UNICAST_HOPS option is set with setsockopt(), the
+   option value given is used as the hop limit for all subsequent
+   unicast packets sent via that socket.  If the option is not set, the
+   system selects a default value.  The integer hop limit value (called
+   x) is interpreted as follows:
+
+      x < -1:        return an error of EINVAL
+      x == -1:       use kernel default
+      0 <= x <= 255: use x
+      x >= 256:      return an error of EINVAL
+
+   The IPV6_UNICAST_HOPS option may be used with getsockopt() to
+   determine the hop limit value that the system will use for subsequent
+   unicast packets sent via that socket.  For example:
+
+      int  hoplimit;
+      socklen_t  len = sizeof(hoplimit);
+
+      if (getsockopt(s, IPPROTO_IPV6, IPV6_UNICAST_HOPS,
+                     (char *) &hoplimit, &len) == -1)
+          perror("getsockopt IPV6_UNICAST_HOPS");
+      else
+          printf("Using %d for hop limit.\n", hoplimit);
+
+5.2 Sending and Receiving Multicast Packets
+
+   IPv6 applications may send multicast packets by simply specifying an
+   IPv6 multicast address as the destination address, for example in the
+   destination address argument of the sendto() function.
+
+
+
+
+
+Gilligan, et al.             Informational                     [Page 19]
+
+RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
+
+
+   Three socket options at the IPPROTO_IPV6 layer control some of the
+   parameters for sending multicast packets.  Setting these options is
+   not required: applications may send multicast packets without using
+   these options.  The setsockopt() options for controlling the sending
+   of multicast packets are summarized below.  These three options can
+   also be used with getsockopt().
+
+      IPV6_MULTICAST_IF
+
+         Set the interface to use for outgoing multicast packets.  The
+         argument is the index of the interface to use.  If the
+         interface index is specified as zero, the system selects the
+         interface (for example, by looking up the address in a routing
+         table and using the resulting interface).
+
+         Argument type: unsigned int
+
+      IPV6_MULTICAST_HOPS
+
+         Set the hop limit to use for outgoing multicast packets.  (Note
+         a separate option - IPV6_UNICAST_HOPS - is provided to set the
+         hop limit to use for outgoing unicast packets.)
+
+         The interpretation of the argument is the same as for the
+         IPV6_UNICAST_HOPS option:
+
+            x < -1:        return an error of EINVAL
+            x == -1:       use kernel default
+            0 <= x <= 255: use x
+            x >= 256:      return an error of EINVAL
+
+            If IPV6_MULTICAST_HOPS is not set, the default is 1
+            (same as IPv4 today)
+
+         Argument type: int
+
+      IPV6_MULTICAST_LOOP
+
+         If a multicast datagram is sent to a group to which the sending
+         host itself belongs (on the outgoing interface), a copy of the
+         datagram is looped back by the IP layer for local delivery if
+         this option is set to 1.  If this option is set to 0 a copy is
+         not looped back.  Other option values return an error of
+         EINVAL.
+
+
+
+
+
+
+
+Gilligan, et al.             Informational                     [Page 20]
+
+RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
+
+
+         If IPV6_MULTICAST_LOOP is not set, the default is 1 (loopback;
+         same as IPv4 today).
+
+         Argument type: unsigned int
+
+   The reception of multicast packets is controlled by the two
+   setsockopt() options summarized below.  An error of EOPNOTSUPP is
+   returned if these two options are used with getsockopt().
+
+      IPV6_JOIN_GROUP
+
+         Join a multicast group on a specified local interface.
+         If the interface index is specified as 0,
+         the kernel chooses the local interface.
+         For example, some kernels look up the multicast group
+         in the normal IPv6 routing table and use the resulting
+         interface.
+
+         Argument type: struct ipv6_mreq
+
+      IPV6_LEAVE_GROUP
+
+         Leave a multicast group on a specified interface.
+         If the interface index is specified as 0, the system
+         may choose a multicast group membership to drop by
+         matching the multicast address only.
+
+         Argument type: struct ipv6_mreq
+
+   The argument type of both of these options is the ipv6_mreq
+   structure, defined as a result of including the <netinet/in.h>
+   header;
+
+   struct ipv6_mreq {
+       struct in6_addr ipv6mr_multiaddr; /* IPv6 multicast addr */
+       unsigned int    ipv6mr_interface; /* interface index */
+   };
+
+   Note that to receive multicast datagrams a process must join the
+   multicast group to which datagrams will be sent.  UDP applications
+   must also bind the UDP port to which datagrams will be sent.  Some
+   processes also bind the multicast group address to the socket, in
+   addition to the port, to prevent other datagrams destined to that
+   same port from being delivered to the socket.
+
+
+
+
+
+
+
+Gilligan, et al.             Informational                     [Page 21]
+
+RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
+
+
+5.3 IPV6_V6ONLY option for AF_INET6 Sockets
+
+   This socket option restricts AF_INET6 sockets to IPv6 communications
+   only.  As stated in section <3.7 Compatibility with IPv4 Nodes>,
+   AF_INET6 sockets may be used for both IPv4 and IPv6 communications.
+   Some applications may want to restrict their use of an AF_INET6
+   socket to IPv6 communications only.  For these applications the
+   IPV6_V6ONLY socket option is defined.  When this option is turned on,
+   the socket can be used to send and receive IPv6 packets only.  This
+   is an IPPROTO_IPV6 level option.  This option takes an int value.
+   This is a boolean option.  By default this option is turned off.
+
+   Here is an example of setting this option:
+
+      int on = 1;
+
+      if (setsockopt(s, IPPROTO_IPV6, IPV6_V6ONLY,
+                     (char *)&on, sizeof(on)) == -1)
+          perror("setsockopt IPV6_V6ONLY");
+      else
+          printf("IPV6_V6ONLY set\n");
+
+   Note - This option has no effect on the use of IPv4 Mapped addresses
+   which enter a node as a valid IPv6 addresses for IPv6 communications
+   as defined by Stateless IP/ICMP Translation Algorithm (SIIT) [5].
+
+   An example use of this option is to allow two versions of the same
+   server process to run on the same port, one providing service over
+   IPv6, the other providing the same service over IPv4.
+
+6. Library Functions
+
+   New library functions are needed to perform a variety of operations
+   with IPv6 addresses.  Functions are needed to lookup IPv6 addresses
+   in the Domain Name System (DNS).  Both forward lookup (nodename-to-
+   address translation) and reverse lookup (address-to-nodename
+   translation) need to be supported.  Functions are also needed to
+   convert IPv6 addresses between their binary and textual form.
+
+   We note that the two existing functions, gethostbyname() and
+   gethostbyaddr(), are left as-is.  New functions are defined to handle
+   both IPv4 and IPv6 addresses.
+
+   The commonly used function gethostbyname() is inadequate for many
+   applications, first because it provides no way for the caller to
+   specify anything about the types of addresses desired (IPv4 only,
+   IPv6 only, IPv4-mapped IPv6 are OK, etc.), and second because many
+   implementations of this function are not thread safe.  RFC 2133
+
+
+
+Gilligan, et al.             Informational                     [Page 22]
+
+RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
+
+
+   defined a function named gethostbyname2() but this function was also
+   inadequate, first because its use required setting a global option
+   (RES_USE_INET6) when IPv6 addresses were required, and second because
+   a flag argument is needed to provide the caller with additional
+   control over the types of addresses required.  The gethostbyname2()
+   function was deprecated in RFC 2553 and is no longer part of the
+   basic API.
+
+6.1 Protocol-Independent Nodename and Service Name Translation
+
+   Nodename-to-address translation is done in a protocol-independent
+   fashion using the getaddrinfo() function.
+
+#include <sys/socket.h>
+#include <netdb.h>
+
+
+int getaddrinfo(const char *nodename, const char *servname,
+                const struct addrinfo *hints, struct addrinfo **res);
+
+void freeaddrinfo(struct addrinfo *ai);
+
+struct addrinfo {
+  int     ai_flags;     /* AI_PASSIVE, AI_CANONNAME,
+                           AI_NUMERICHOST, .. */
+  int     ai_family;    /* AF_xxx */
+  int     ai_socktype;  /* SOCK_xxx */
+  int     ai_protocol;  /* 0 or IPPROTO_xxx for IPv4 and IPv6 */
+  socklen_t  ai_addrlen;   /* length of ai_addr */
+  char   *ai_canonname; /* canonical name for nodename */
+  struct sockaddr  *ai_addr; /* binary address */
+  struct addrinfo  *ai_next; /* next structure in linked list */
+};
+
+   The getaddrinfo() function translates the name of a service location
+   (for example, a host name) and/or a service name and returns a set of
+   socket addresses and associated information to be used in creating a
+   socket with which to address the specified service.
+
+   The nodename and servname arguments are either null pointers or
+   pointers to null-terminated strings.  One or both of these two
+   arguments must be a non-null pointer.
+
+   The format of a valid name depends on the address family or families.
+   If a specific family is not given and the name could be interpreted
+   as valid within multiple supported families, the implementation will
+   attempt to resolve the name in all supported families and, in absence
+   of errors, one or more results shall be returned.
+
+
+
+Gilligan, et al.             Informational                     [Page 23]
+
+RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
+
+
+   If the nodename argument is not null, it can be a descriptive name or
+   can be an address string.  If the specified address family is
+   AF_INET, AF_INET6, or AF_UNSPEC, valid descriptive names include host
+   names. If the specified address family is AF_INET or AF_UNSPEC,
+   address strings using Internet standard dot notation as specified in
+   inet_addr() are valid.  If the specified address family is AF_INET6
+   or AF_UNSPEC, standard IPv6 text forms described in inet_pton() are
+   valid.
+
+   If nodename is not null, the requested service location is named by
+   nodename; otherwise, the requested service location is local to the
+   caller.
+
+   If servname is null, the call shall return network-level addresses
+   for the specified nodename.  If servname is not null, it is a null-
+   terminated character string identifying the requested service.  This
+   can be either a descriptive name or a numeric representation suitable
+   for use with the address family or families.  If the specified
+   address family is AF_INET, AF_INET6 or AF_UNSPEC, the service can be
+   specified as a string specifying a decimal port number.
+
+   If the argument hints is not null, it refers to a structure
+   containing input values that may direct the operation by providing
+   options and by limiting the returned information to a specific socket
+   type, address family and/or protocol.  In this hints structure every
+   member other than ai_flags, ai_family, ai_socktype and ai_protocol
+   shall be set to zero or a null pointer.  A value of AF_UNSPEC for
+   ai_family means that the caller shall accept any address family.  A
+   value of zero for ai_socktype means that the caller shall accept any
+   socket type.  A value of zero for ai_protocol means that the caller
+   shall accept any protocol.  If hints is a null pointer, the behavior
+   shall be as if it referred to a structure containing the value zero
+   for the ai_flags, ai_socktype and ai_protocol fields, and AF_UNSPEC
+   for the ai_family field.
+
+   Note:
+
+   1. If the caller handles only TCP and not UDP, for example, then the
+      ai_protocol member of the hints structure should be set to
+      IPPROTO_TCP when getaddrinfo() is called.
+
+   2. If the caller handles only IPv4 and not IPv6, then the ai_family
+      member of the hints structure should be set to AF_INET when
+      getaddrinfo() is called.
+
+
+
+
+
+
+
+Gilligan, et al.             Informational                     [Page 24]
+
+RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
+
+
+   The ai_flags field to which hints parameter points shall be set to
+   zero or be the bitwise-inclusive OR of one or more of the values
+   AI_PASSIVE, AI_CANONNAME, AI_NUMERICHOST, AI_NUMERICSERV,
+   AI_V4MAPPED, AI_ALL, and AI_ADDRCONFIG.
+
+   If the AI_PASSIVE flag is specified, the returned address information
+   shall be suitable for use in binding a socket for accepting incoming
+   connections for the specified service (i.e., a call to bind()).  In
+   this case, if the nodename argument is null, then the IP address
+   portion of the socket address structure shall be set to INADDR_ANY
+   for an IPv4 address or IN6ADDR_ANY_INIT for an IPv6 address.  If the
+   AI_PASSIVE flag is not specified, the returned address information
+   shall be suitable for a call to connect() (for a connection-mode
+   protocol) or for a call to connect(), sendto() or sendmsg() (for a
+   connectionless protocol).  In this case, if the nodename argument is
+   null, then the IP address portion of the socket address structure
+   shall be set to the loopback address.  This flag is ignored if the
+   nodename argument is not null.
+
+   If the AI_CANONNAME flag is specified and the nodename argument is
+   not null, the function shall attempt to determine the canonical name
+   corresponding to nodename (for example, if nodename is an alias or
+   shorthand notation for a complete name).
+
+   If the AI_NUMERICHOST flag is specified, then a non-null nodename
+   string supplied shall be a numeric host address string.  Otherwise,
+   an [EAI_NONAME] error is returned.  This flag shall prevent any type
+   of name resolution service (for example, the DNS) from being invoked.
+
+   If the AI_NUMERICSERV flag is specified, then a non-null servname
+   string supplied shall be a numeric port string.  Otherwise, an
+   [EAI_NONAME] error shall be returned.  This flag shall prevent any
+   type of name resolution service (for example, NIS+) from being
+   invoked.
+
+   If the AI_V4MAPPED flag is specified along with an ai_family of
+   AF_INET6, then getaddrinfo() shall return IPv4-mapped IPv6 addresses
+   on finding no matching IPv6 addresses (ai_addrlen shall be 16).
+
+      For example, when using the DNS, if no AAAA records are found then
+      a query is made for A records and any found are returned as IPv4-
+      mapped IPv6 addresses.
+
+   The AI_V4MAPPED flag shall be ignored unless ai_family equals
+   AF_INET6.
+
+   If the AI_ALL flag is used with the AI_V4MAPPED flag, then
+   getaddrinfo() shall return all matching IPv6 and IPv4 addresses.
+
+
+
+Gilligan, et al.             Informational                     [Page 25]
+
+RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
+
+
+      For example, when using the DNS, queries are made for both AAAA
+      records and A records, and getaddrinfo() returns the combined
+      results of both queries.  Any IPv4 addresses found are returned as
+      IPv4-mapped IPv6 addresses.
+
+   The AI_ALL flag without the AI_V4MAPPED flag is ignored.
+
+      Note:
+
+      When ai_family is not specified (AF_UNSPEC), AI_V4MAPPED and
+      AI_ALL flags will only be used if AF_INET6 is supported.
+
+   If the AI_ADDRCONFIG flag is specified, IPv4 addresses shall be
+   returned only if an IPv4 address is configured on the local system,
+   and IPv6 addresses shall be returned only if an IPv6 address is
+   configured on the local system.  The loopback address is not
+   considered for this case as valid as a configured address.
+
+      For example, when using the DNS, a query for AAAA records should
+      occur only if the node has at least one IPv6 address configured
+      (other than IPv6 loopback) and a query for A records should occur
+      only if the node has at least one IPv4 address configured (other
+      than the IPv4 loopback).
+
+   The ai_socktype field to which argument hints points specifies the
+   socket type for the service, as defined for socket().  If a specific
+   socket type is not given (for example, a value of zero) and the
+   service name could be interpreted as valid with multiple supported
+   socket types, the implementation shall attempt to resolve the service
+   name for all supported socket types and, in the absence of errors,
+   all possible results shall be returned.  A non-zero socket type value
+   shall limit the returned information to values with the specified
+   socket type.
+
+   If the ai_family field to which hints points has the value AF_UNSPEC,
+   addresses shall be returned for use with any address family that can
+   be used with the specified nodename and/or servname.  Otherwise,
+   addresses shall be returned for use only with the specified address
+   family.  If ai_family is not AF_UNSPEC and ai_protocol is not zero,
+   then addresses are returned for use only with the specified address
+   family and protocol; the value of ai_protocol shall be interpreted as
+   in a call to the socket() function with the corresponding values of
+   ai_family and ai_protocol.
+
+   The freeaddrinfo() function frees one or more addrinfo structures
+   returned by getaddrinfo(), along with any additional storage
+   associated with those structures (for example, storage pointed to by
+   the ai_canonname and ai_addr fields; an application must not
+
+
+
+Gilligan, et al.             Informational                     [Page 26]
+
+RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
+
+
+   reference this storage after the associated addrinfo structure has
+   been freed).  If the ai_next field of the structure is not null, the
+   entire list of structures is freed.  The freeaddrinfo() function must
+   support the freeing of arbitrary sublists of an addrinfo list
+   originally returned by getaddrinfo().
+
+   Functions getaddrinfo() and freeaddrinfo() must be thread-safe.
+
+   A zero return value for getaddrinfo() indicates successful
+   completion; a non-zero return value indicates failure.  The possible
+   values for the failures are listed below under Error Return Values.
+
+   Upon successful return of getaddrinfo(), the location to which res
+   points shall refer to a linked list of addrinfo structures, each of
+   which shall specify a socket address and information for use in
+   creating a socket with which to use that socket address.  The list
+   shall include at least one addrinfo structure.  The ai_next field of
+   each structure contains a pointer to the next structure on the list,
+   or a null pointer if it is the last structure on the list.  Each
+   structure on the list shall include values for use with a call to the
+   socket() function, and a socket address for use with the connect()
+   function or, if the AI_PASSIVE flag was specified, for use with the
+   bind() function.  The fields ai_family, ai_socktype, and ai_protocol
+   shall be usable as the arguments to the socket() function to create a
+   socket suitable for use with the returned address.  The fields
+   ai_addr and ai_addrlen are usable as the arguments to the connect()
+   or bind() functions with such a socket, according to the AI_PASSIVE
+   flag.
+
+   If nodename is not null, and if requested by the AI_CANONNAME flag,
+   the ai_canonname field of the first returned addrinfo structure shall
+   point to a null-terminated string containing the canonical name
+   corresponding to the input nodename; if the canonical name is not
+   available, then ai_canonname shall refer to the nodename argument or
+   a string with the same contents.  The contents of the ai_flags field
+   of the returned structures are undefined.
+
+   All fields in socket address structures returned by getaddrinfo()
+   that are not filled in through an explicit argument (for example,
+   sin6_flowinfo) shall be set to zero.
+
+   Note: This makes it easier to compare socket address structures.
+
+
+
+
+
+
+
+
+
+Gilligan, et al.             Informational                     [Page 27]
+
+RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
+
+
+   Error Return Values:
+
+   The getaddrinfo() function shall fail and return the corresponding
+   value if:
+
+   [EAI_AGAIN]     The name could not be resolved at this time.  Future
+                   attempts may succeed.
+
+   [EAI_BADFLAGS]  The flags parameter had an invalid value.
+
+   [EAI_FAIL]      A non-recoverable error occurred when attempting to
+                   resolve the name.
+
+   [EAI_FAMILY]    The address family was not recognized.
+
+   [EAI_MEMORY]    There was a memory allocation failure when trying to
+                   allocate storage for the return value.
+
+   [EAI_NONAME]    The name does not resolve for the supplied
+                   parameters.  Neither nodename nor servname were
+                   supplied.  At least one of these must be supplied.
+
+   [EAI_SERVICE]   The service passed was not recognized for the
+                   specified socket type.
+
+   [EAI_SOCKTYPE]  The intended socket type was not recognized.
+
+   [EAI_SYSTEM]    A system error occurred; the error code can be found
+                   in errno.
+
+   The gai_strerror() function provides a descriptive text string
+   corresponding to an EAI_xxx error value.
+
+      #include <netdb.h>
+
+      const char *gai_strerror(int ecode);
+
+   The argument is one of the EAI_xxx values defined for the
+   getaddrinfo() and getnameinfo() functions.  The return value points
+   to a string describing the error.  If the argument is not one of the
+   EAI_xxx values, the function still returns a pointer to a string
+   whose contents indicate an unknown error.
+
+6.2 Socket Address Structure to Node Name and Service Name
+
+   The getnameinfo() function is used to translate the contents of a
+   socket address structure to a node name and/or service name.
+
+
+
+
+Gilligan, et al.             Informational                     [Page 28]
+
+RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
+
+
+   #include <sys/socket.h>
+   #include <netdb.h>
+
+   int getnameinfo(const struct sockaddr *sa, socklen_t salen,
+                       char *node, socklen_t nodelen,
+                       char *service, socklen_t servicelen,
+                         int flags);
+
+   The getnameinfo() function shall translate a socket address to a node
+   name and service location, all of which are defined as in
+   getaddrinfo().
+
+   The sa argument points to a socket address structure to be
+   translated.
+
+   The salen argument holds the size of the socket address structure
+   pointed to by sa.
+
+   If the socket address structure contains an IPv4-mapped IPv6 address
+   or an IPv4-compatible IPv6 address, the implementation shall extract
+   the embedded IPv4 address and lookup the node name for that IPv4
+   address.
+
+      Note: The IPv6 unspecified address ("::") and the IPv6 loopback
+      address ("::1") are not IPv4-compatible addresses.  If the address
+      is the IPv6 unspecified address ("::"), a lookup is not performed,
+      and the [EAI_NONAME] error is returned.
+
+   If the node argument is non-NULL and the nodelen argument is nonzero,
+   then the node argument points to a buffer able to contain up to
+   nodelen characters that receives the node name as a null-terminated
+   string.  If the node argument is NULL or the nodelen argument is
+   zero, the node name shall not be returned.  If the node's name cannot
+   be located, the numeric form of the node's address is returned
+   instead of its name.
+
+   If the service argument is non-NULL and the servicelen argument is
+   non-zero, then the service argument points to a buffer able to
+   contain up to servicelen bytes that receives the service name as a
+   null-terminated string.  If the service argument is NULL or the
+   servicelen argument is zero, the service name shall not be returned.
+   If the service's name cannot be located, the numeric form of the
+   service address (for example, its port number) shall be returned
+   instead of its name.
+
+   The arguments node and service cannot both be NULL.
+
+
+
+
+
+Gilligan, et al.             Informational                     [Page 29]
+
+RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
+
+
+   The flags argument is a flag that changes the default actions of the
+   function.  By default the fully-qualified domain name (FQDN) for the
+   host shall be returned, but:
+
+   -  If the flag bit NI_NOFQDN is set, only the node name portion of
+      the FQDN shall be returned for local hosts.
+
+   -  If the flag bit NI_NUMERICHOST is set, the numeric form of the
+      host's address shall be returned instead of its name, under all
+      circumstances.
+
+   -  If the flag bit NI_NAMEREQD is set, an error shall be returned if
+      the host's name cannot be located.
+
+   -  If the flag bit NI_NUMERICSERV is set, the numeric form of the
+      service address shall be returned (for example, its port number)
+      instead of its name, under all circumstances.
+
+   -  If the flag bit NI_DGRAM is set, this indicates that the service
+      is a datagram service (SOCK_DGRAM).  The default behavior shall
+      assume that the service is a stream service (SOCK_STREAM).
+
+   Note:
+
+   1. The NI_NUMERICxxx flags are required to support the "-n" flags
+      that many commands provide.
+
+   2. The NI_DGRAM flag is required for the few AF_INET and AF_INET6
+      port numbers (for example, [512,514]) that represent different
+      services for UDP and TCP.
+
+   The getnameinfo() function shall be thread safe.
+
+   A zero return value for getnameinfo() indicates successful
+   completion; a non-zero return value indicates failure.
+
+   Upon successful completion, getnameinfo() shall return the node and
+   service names, if requested, in the buffers provided.  The returned
+   names are always null-terminated strings.
+
+
+
+
+
+
+
+
+
+
+
+
+Gilligan, et al.             Informational                     [Page 30]
+
+RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
+
+
+   Error Return Values:
+
+   The getnameinfo() function shall fail and return the corresponding
+   value if:
+
+   [EAI_AGAIN]    The name could not be resolved at this time.
+                  Future attempts may succeed.
+
+   [EAI_BADFLAGS] The flags had an invalid value.
+
+   [EAI_FAIL]     A non-recoverable error occurred.
+
+   [EAI_FAMILY]   The address family was not recognized or the address
+                  length was invalid for the specified family.
+
+   [EAI_MEMORY]   There was a memory allocation failure.
+
+   [EAI_NONAME]   The name does not resolve for the supplied parameters.
+                  NI_NAMEREQD is set and the host's name cannot be
+                  located, or both nodename and servname were null.
+
+   [EAI_OVERFLOW] An argument buffer overflowed.
+
+   [EAI_SYSTEM]   A system error occurred.  The error code can be found
+                  in errno.
+
+6.3 Address Conversion Functions
+
+   The two IPv4 functions inet_addr() and inet_ntoa() convert an IPv4
+   address between binary and text form.  IPv6 applications need similar
+   functions.  The following two functions convert both IPv6 and IPv4
+   addresses:
+
+   #include <arpa/inet.h>
+
+   int inet_pton(int af, const char *src, void *dst);
+
+   const char *inet_ntop(int af, const void *src,
+                            char *dst, socklen_t size);
+
+   The inet_pton() function shall convert an address in its standard
+   text presentation form into its numeric binary form.  The af argument
+   shall specify the family of the address.  The AF_INET and AF_INET6
+   address families shall be supported.  The src argument points to the
+   string being passed in.  The dst argument points to a buffer into
+   which the function stores the numeric address; this shall be large
+   enough to hold the numeric address (32 bits for AF_INET, 128 bits for
+   AF_INET6).  The inet_pton() function shall return 1 if the conversion
+
+
+
+Gilligan, et al.             Informational                     [Page 31]
+
+RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
+
+
+   succeeds, with the address pointed to by dst in network byte order.
+   It shall return 0 if the input is not a valid IPv4 dotted-decimal
+   string or a valid IPv6 address string, or -1 with errno set to
+   EAFNOSUPPORT if the af argument is unknown.
+
+   If the af argument of inet_pton() is AF_INET, the src string shall be
+   in the standard IPv4 dotted-decimal form:
+
+      ddd.ddd.ddd.ddd
+
+   where "ddd" is a one to three digit decimal number between 0 and 255.
+   The inet_pton() function does not accept other formats (such as the
+   octal numbers, hexadecimal numbers, and fewer than four numbers that
+   inet_addr() accepts).
+
+   If the af argument of inet_pton() is AF_INET6, the src string shall
+   be in one of the standard IPv6 text forms defined in Section 2.2 of
+   the addressing architecture specification [2].
+
+   The inet_ntop() function shall convert a numeric address into a text
+   string suitable for presentation.  The af argument shall specify the
+   family of the address.  This can be AF_INET or AF_INET6.  The src
+   argument points to a buffer holding an IPv4 address if the af
+   argument is AF_INET, or an IPv6 address if the af argument is
+   AF_INET6; the address must be in network byte order.  The dst
+   argument points to a buffer where the function stores the resulting
+   text string; it shall not be NULL.  The size argument specifies the
+   size of this buffer, which shall be large enough to hold the text
+   string (INET_ADDRSTRLEN characters for IPv4, INET6_ADDRSTRLEN
+   characters for IPv6).
+
+   In order to allow applications to easily declare buffers of the
+   proper size to store IPv4 and IPv6 addresses in string form, the
+   following two constants are defined in <netinet/in.h>:
+
+      #define INET_ADDRSTRLEN    16
+      #define INET6_ADDRSTRLEN   46
+
+   The inet_ntop() function shall return a pointer to the buffer
+   containing the text string if the conversion succeeds, and NULL
+   otherwise.  Upon failure, errno is set to EAFNOSUPPORT if the af
+   argument is invalid or ENOSPC if the size of the result buffer is
+   inadequate.
+
+
+
+
+
+
+
+
+Gilligan, et al.             Informational                     [Page 32]
+
+RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
+
+
+6.4 Address Testing Macros
+
+   The following macros can be used to test for special IPv6 addresses.
+
+   #include <netinet/in.h>
+
+   int  IN6_IS_ADDR_UNSPECIFIED (const struct in6_addr *);
+   int  IN6_IS_ADDR_LOOPBACK    (const struct in6_addr *);
+   int  IN6_IS_ADDR_MULTICAST   (const struct in6_addr *);
+   int  IN6_IS_ADDR_LINKLOCAL   (const struct in6_addr *);
+   int  IN6_IS_ADDR_SITELOCAL   (const struct in6_addr *);
+   int  IN6_IS_ADDR_V4MAPPED    (const struct in6_addr *);
+   int  IN6_IS_ADDR_V4COMPAT    (const struct in6_addr *);
+
+   int  IN6_IS_ADDR_MC_NODELOCAL(const struct in6_addr *);
+   int  IN6_IS_ADDR_MC_LINKLOCAL(const struct in6_addr *);
+   int  IN6_IS_ADDR_MC_SITELOCAL(const struct in6_addr *);
+   int  IN6_IS_ADDR_MC_ORGLOCAL (const struct in6_addr *);
+   int  IN6_IS_ADDR_MC_GLOBAL   (const struct in6_addr *);
+
+   The first seven macros return true if the address is of the specified
+   type, or false otherwise.  The last five test the scope of a
+   multicast address and return true if the address is a multicast
+   address of the specified scope or false if the address is either not
+   a multicast address or not of the specified scope.
+
+   Note that IN6_IS_ADDR_LINKLOCAL and IN6_IS_ADDR_SITELOCAL return true
+   only for the two types of local-use IPv6 unicast addresses (Link-
+   Local and Site-Local) defined in [2], and that by this definition,
+   the IN6_IS_ADDR_LINKLOCAL macro returns false for the IPv6 loopback
+   address (::1).  These two macros do not return true for IPv6
+   multicast addresses of either link-local scope or site-local scope.
+
+7. Summary of New Definitions
+
+   The following list summarizes the constants, structure, and extern
+   definitions discussed in this memo, sorted by header.
+
+<net/if.h>      IF_NAMESIZE
+<net/if.h>      struct if_nameindex{};
+
+<netdb.h>       AI_ADDRCONFIG
+<netdb.h>       AI_ALL
+<netdb.h>       AI_CANONNAME
+<netdb.h>       AI_NUMERICHOST
+<netdb.h>       AI_NUMERICSERV
+<netdb.h>       AI_PASSIVE
+<netdb.h>       AI_V4MAPPED
+
+
+
+Gilligan, et al.             Informational                     [Page 33]
+
+RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
+
+
+<netdb.h>       EAI_AGAIN
+<netdb.h>       EAI_BADFLAGS
+<netdb.h>       EAI_FAIL
+<netdb.h>       EAI_FAMILY
+<netdb.h>       EAI_MEMORY
+<netdb.h>       EAI_NONAME
+<netdb.h>       EAI_OVERFLOW
+<netdb.h>       EAI_SERVICE
+<netdb.h>       EAI_SOCKTYPE
+<netdb.h>       EAI_SYSTEM
+<netdb.h>       NI_DGRAM
+<netdb.h>       NI_NAMEREQD
+<netdb.h>       NI_NOFQDN
+<netdb.h>       NI_NUMERICHOST
+<netdb.h>       NI_NUMERICSERV
+<netdb.h>       struct addrinfo{};
+
+<netinet/in.h>  IN6ADDR_ANY_INIT
+<netinet/in.h>  IN6ADDR_LOOPBACK_INIT
+<netinet/in.h>  INET6_ADDRSTRLEN
+<netinet/in.h>  INET_ADDRSTRLEN
+<netinet/in.h>  IPPROTO_IPV6
+<netinet/in.h>  IPV6_JOIN_GROUP
+<netinet/in.h>  IPV6_LEAVE_GROUP
+<netinet/in.h>  IPV6_MULTICAST_HOPS
+<netinet/in.h>  IPV6_MULTICAST_IF
+<netinet/in.h>  IPV6_MULTICAST_LOOP
+<netinet/in.h>  IPV6_UNICAST_HOPS
+<netinet/in.h>  IPV6_V6ONLY
+<netinet/in.h>  SIN6_LEN
+<netinet/in.h>  extern const struct in6_addr in6addr_any;
+<netinet/in.h>  extern const struct in6_addr in6addr_loopback;
+<netinet/in.h>  struct in6_addr{};
+<netinet/in.h>  struct ipv6_mreq{};
+<netinet/in.h>  struct sockaddr_in6{};
+
+<sys/socket.h>  AF_INET6
+<sys/socket.h>  PF_INET6
+<sys/socket.h>  struct sockaddr_storage;
+
+   The following list summarizes the function and macro prototypes
+   discussed in this memo, sorted by header.
+
+<arpa/inet.h>   int inet_pton(int, const char *, void *);
+<arpa/inet.h>   const char *inet_ntop(int, const void *,
+                               char *, socklen_t);
+
+
+
+
+
+Gilligan, et al.             Informational                     [Page 34]
+
+RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
+
+
+<net/if.h>      char *if_indextoname(unsigned int, char *);
+<net/if.h>      unsigned int if_nametoindex(const char *);
+<net/if.h>      void if_freenameindex(struct if_nameindex *);
+<net/if.h>      struct if_nameindex *if_nameindex(void);
+
+<netdb.h>       int getaddrinfo(const char *, const char *,
+                                const struct addrinfo *,
+                                struct addrinfo **);
+<netdb.h>       int getnameinfo(const struct sockaddr *, socklen_t,
+                  char *, socklen_t, char *, socklen_t, int);
+<netdb.h>       void freeaddrinfo(struct addrinfo *);
+<netdb.h>       const char *gai_strerror(int);
+
+<netinet/in.h>  int IN6_IS_ADDR_LINKLOCAL(const struct in6_addr *);
+<netinet/in.h>  int IN6_IS_ADDR_LOOPBACK(const struct in6_addr *);
+<netinet/in.h>  int IN6_IS_ADDR_MC_GLOBAL(const struct in6_addr *);
+<netinet/in.h>  int IN6_IS_ADDR_MC_LINKLOCAL(const struct in6_addr *);
+<netinet/in.h>  int IN6_IS_ADDR_MC_NODELOCAL(const struct in6_addr *);
+<netinet/in.h>  int IN6_IS_ADDR_MC_ORGLOCAL(const struct in6_addr *);
+<netinet/in.h>  int IN6_IS_ADDR_MC_SITELOCAL(const struct in6_addr *);
+<netinet/in.h>  int IN6_IS_ADDR_MULTICAST(const struct in6_addr *);
+<netinet/in.h>  int IN6_IS_ADDR_SITELOCAL(const struct in6_addr *);
+<netinet/in.h>  int IN6_IS_ADDR_UNSPECIFIED(const struct in6_addr *);
+<netinet/in.h>  int IN6_IS_ADDR_V4COMPAT(const struct in6_addr *);
+<netinet/in.h>  int IN6_IS_ADDR_V4MAPPED(const struct in6_addr *);
+
+8. Security Considerations
+
+   IPv6 provides a number of new security mechanisms, many of which need
+   to be accessible to applications.  Companion memos detailing the
+   extensions to the socket interfaces to support IPv6 security are
+   being written.
+
+9. Changes from RFC 2553
+
+   1. Add brief description of the history of this API and its relation
+      to the Open Group/IEEE/ISO standards.
+
+   2. Alignments with [3].
+
+   3. Removed all references to getipnodebyname() and getipnodebyaddr(),
+      which are deprecated in favor of getaddrinfo() and getnameinfo().
+
+   4. Added IPV6_V6ONLY IP level socket option to permit nodes to not
+      process IPv4 packets as IPv4 Mapped addresses in implementations.
+
+   5. Added SIIT to references and added new contributors.
+
+
+
+
+Gilligan, et al.             Informational                     [Page 35]
+
+RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
+
+
+   6. In previous versions of this specification, the sin6_flowinfo
+      field was associated with the IPv6 traffic class and flow label,
+      but its usage was not completely specified.  The complete
+      definition of the sin6_flowinfo field, including its association
+      with the traffic class or flow label, is now deferred to a future
+      specification.
+
+10. Acknowledgments
+
+   This specification's evolution and completeness were significantly
+   influenced by the efforts of Richard Stevens, who has passed on.
+   Richard's wisdom and talent made the specification what it is today.
+   The co-authors will long think of Richard with great respect.
+
+   Thanks to the many people who made suggestions and provided feedback
+   to this document, including:
+
+   Werner Almesberger, Ran Atkinson, Fred Baker, Dave Borman, Andrew
+   Cherenson, Alex Conta, Alan Cox, Steve Deering, Richard Draves,
+   Francis Dupont, Robert Elz, Brian Haberman, Jun-ichiro itojun Hagino,
+   Marc Hasson, Tom Herbert, Bob Hinden, Wan-Yen Hsu, Christian Huitema,
+   Koji Imada, Markus Jork, Ron Lee, Alan Lloyd, Charles Lynn, Dan
+   McDonald, Dave Mitton, Finnbarr Murphy, Thomas Narten, Josh Osborne,
+   Craig Partridge, Jean-Luc Richier, Bill Sommerfield, Erik Scoredos,
+   Keith Sklower, JINMEI Tatuya, Dave Thaler, Matt Thomas, Harvey
+   Thompson, Dean D. Throop, Karen Tracey, Glenn Trewitt, Paul Vixie,
+   David Waitzman, Carl Williams, Kazu Yamamoto, Vlad Yasevich, Stig
+   Venaas, and Brian Zill.
+
+   The getaddrinfo() and getnameinfo() functions are taken from an
+   earlier document by Keith Sklower.  As noted in that document,
+   William Durst, Steven Wise, Michael Karels, and Eric Allman provided
+   many useful discussions on the subject of protocol-independent name-
+   to-address translation, and reviewed early versions of Keith
+   Sklower's original proposal.  Eric Allman implemented the first
+   prototype of getaddrinfo().  The observation that specifying the pair
+   of name and service would suffice for connecting to a service
+   independent of protocol details was made by Marshall Rose in a
+   proposal to X/Open for a "Uniform Network Interface".
+
+   Craig Metz, Jack McCann, Erik Nordmark, Tim Hartrick, and Mukesh
+   Kacker made many contributions to this document.  Ramesh Govindan
+   made a number of contributions and co-authored an earlier version of
+   this memo.
+
+
+
+
+
+
+
+Gilligan, et al.             Informational                     [Page 36]
+
+RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
+
+
+11. References
+
+   [1]  Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
+        Specification", RFC 2460, December 1998.
+
+   [2]  Hinden, R. and S. Deering, "IP Version 6 Addressing
+        Architecture", RFC 2373, July 1998.
+
+   [3]  IEEE Std. 1003.1-2001 Standard for Information Technology --
+        Portable Operating System Interface (POSIX). Open Group
+        Technical Standard: Base Specifications, Issue 6, December 2001.
+        ISO/IEC 9945:2002.  http://www.opengroup.org/austin
+
+   [4]  Stevens, W. and M. Thomas, "Advanced Sockets API for IPv6", RFC
+        2292, February 1998.
+
+   [5]  Nordmark, E., "Stateless IP/ICMP Translation Algorithm (SIIT)",
+        RFC 2765, February 2000.
+
+   [6]  The Open Group Base Working Group
+        http://www.opengroup.org/platform/base.html
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gilligan, et al.             Informational                     [Page 37]
+
+RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
+
+
+12. Authors' Addresses
+
+   Bob Gilligan
+   Intransa, Inc.
+   2870 Zanker Rd.
+   San Jose, CA 95134
+
+   Phone: 408-678-8647
+   EMail: gilligan@intransa.com
+
+
+   Susan Thomson
+   Cisco Systems
+   499 Thornall Street, 8th floor
+   Edison, NJ 08837
+
+   Phone: 732-635-3086
+   EMail:  sethomso@cisco.com
+
+
+   Jim Bound
+   Hewlett-Packard Company
+   110 Spitbrook Road ZKO3-3/W20
+   Nashua, NH 03062
+
+   Phone: 603-884-0062
+   EMail: Jim.Bound@hp.com
+
+
+   Jack McCann
+   Hewlett-Packard Company
+   110 Spitbrook Road ZKO3-3/W20
+   Nashua, NH 03062
+
+   Phone: 603-884-2608
+   EMail: Jack.McCann@hp.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gilligan, et al.             Informational                     [Page 38]
+
+RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
+
+
+13. Full Copyright Statement
+
+   Copyright (C) The Internet Society (2003).  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 Standards process must be
+   followed, or as required to translate it into 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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gilligan, et al.             Informational                     [Page 39]
+
diff --git a/doc/rfc/rfc3513.txt b/doc/rfc/rfc3513.txt
new file mode 100644
index 0000000..49c0fa4
--- /dev/null
+++ b/doc/rfc/rfc3513.txt
@@ -0,0 +1,1459 @@
+
+
+
+
+
+
+Network Working Group                                          R. Hinden
+Request for Comments: 3513                                         Nokia
+Obsoletes: 2373                                               S. Deering
+Category: Standards Track                                  Cisco Systems
+                                                              April 2003
+
+
+       Internet Protocol Version 6 (IPv6) Addressing Architecture
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2003).  All Rights Reserved.
+
+Abstract
+
+   This specification defines the addressing architecture of the IP
+   Version 6 (IPv6) protocol.  The document includes the IPv6 addressing
+   model, text representations of IPv6 addresses, definition of IPv6
+   unicast addresses, anycast addresses, and multicast addresses, and an
+   IPv6 node's required addresses.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hinden & Deering            Standards Track                     [Page 1]
+
+RFC 3513              IPv6 Addressing Architecture            April 2003
+
+
+Table of Contents
+
+   1. Introduction.................................................3
+   2. IPv6 Addressing..............................................3
+      2.1 Addressing Model.........................................4
+      2.2 Text Representation of Addresses.........................4
+      2.3 Text Representation of Address Prefixes..................5
+      2.4 Address Type Identification..............................6
+      2.5 Unicast Addresses........................................7
+          2.5.1 Interface Identifiers..............................8
+          2.5.2 The Unspecified Address............................9
+          2.5.3 The Loopback Address...............................9
+          2.5.4 Global Unicast Addresses..........................10
+          2.5.5 IPv6 Addresses with Embedded IPv4 Addresses.......10
+          2.5.6 Local-use IPv6 Unicast Addresses..................11
+      2.6 Anycast Addresses.......................................12
+          2.6.1 Required Anycast Address..........................13
+      2.7 Multicast Addresses.....................................13
+          2.7.1 Pre-Defined Multicast Addresses...................15
+      2.8 A Node's Required Addresses.............................17
+   3. Security Considerations.....................................17
+   4. IANA Considerations.........................................18
+   5. References..................................................19
+      5.1 Normative References....................................19
+      5.2 Informative References..................................19
+   APPENDIX A: Creating Modified EUI-64 format Interface IDs......21
+   APPENDIX B: Changes from RFC-2373..............................24
+   Authors' Addresses.............................................25
+   Full Copyright Statement.......................................26
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hinden & Deering            Standards Track                     [Page 2]
+
+RFC 3513              IPv6 Addressing Architecture            April 2003
+
+
+1.  Introduction
+
+   This specification defines the addressing architecture of the IP
+   Version 6 (IPv6) protocol.  It includes the basic formats for the
+   various types of IPv6 addresses (unicast, anycast, and multicast).
+
+   The authors would like to acknowledge the contributions of Paul
+   Francis, Scott Bradner, Jim Bound, Brian Carpenter, Matt Crawford,
+   Deborah Estrin, Roger Fajman, Bob Fink, Peter Ford, Bob Gilligan,
+   Dimitry Haskin, Tom Harsch, Christian Huitema, Tony Li, Greg
+   Minshall, Thomas Narten, Erik Nordmark, Yakov Rekhter, Bill Simpson,
+   Sue Thomson, Markku Savela, and Larry Masinter.
+
+2. IPv6 Addressing
+
+   IPv6 addresses are 128-bit identifiers for interfaces and sets of
+   interfaces (where "interface" is as defined in section 2 of [IPV6]).
+   There are three types of addresses:
+
+   Unicast:   An identifier for a single interface.  A packet sent to a
+              unicast address is delivered to the interface identified
+              by that address.
+
+   Anycast:   An identifier for a set of interfaces (typically belonging
+              to different nodes).  A packet sent to an anycast address
+              is delivered to one of the interfaces identified by that
+              address (the "nearest" one, according to the routing
+              protocols' measure of distance).
+
+   Multicast: An identifier for a set of interfaces (typically belonging
+              to different nodes).  A packet sent to a multicast address
+              is delivered to all interfaces identified by that address.
+
+   There are no broadcast addresses in IPv6, their function being
+   superseded by multicast addresses.
+
+   In this document, fields in addresses are given a specific name, for
+   example "subnet".  When this name is used with the term "ID" for
+   identifier after the name (e.g., "subnet ID"), it refers to the
+   contents of the named field.  When it is used with the term "prefix"
+   (e.g., "subnet prefix") it refers to all of the address from the left
+   up to and including this field.
+
+   In IPv6, all zeros and all ones are legal values for any field,
+   unless specifically excluded.  Specifically, prefixes may contain, or
+   end with, zero-valued fields.
+
+
+
+
+
+Hinden & Deering            Standards Track                     [Page 3]
+
+RFC 3513              IPv6 Addressing Architecture            April 2003
+
+
+2.1 Addressing Model
+
+   IPv6 addresses of all types are assigned to interfaces, not nodes.
+   An IPv6 unicast address refers to a single interface.  Since each
+   interface belongs to a single node, any of that node's interfaces'
+   unicast addresses may be used as an identifier for the node.
+
+   All interfaces are required to have at least one link-local unicast
+   address (see section 2.8 for additional required addresses).  A
+   single interface may also have multiple IPv6 addresses of any type
+   (unicast, anycast, and multicast) or scope.  Unicast addresses with
+   scope greater than link-scope are not needed for interfaces that are
+   not used as the origin or destination of any IPv6 packets to or from
+   non-neighbors.  This is sometimes convenient for point-to-point
+   interfaces.  There is one exception to this addressing model:
+
+      A unicast address or a set of unicast addresses may be assigned to
+      multiple physical interfaces if the implementation treats the
+      multiple physical interfaces as one interface when presenting it
+      to the internet layer.  This is useful for load-sharing over
+      multiple physical interfaces.
+
+   Currently IPv6 continues the IPv4 model that a subnet prefix is
+   associated with one link.  Multiple subnet prefixes may be assigned
+   to the same link.
+
+2.2 Text Representation of Addresses
+
+   There are three conventional forms for representing IPv6 addresses as
+   text strings:
+
+   1. The preferred form is x:x:x:x:x:x:x:x, where the 'x's are the
+      hexadecimal values of the eight 16-bit pieces of the address.
+
+      Examples:
+
+         FEDC:BA98:7654:3210:FEDC:BA98:7654:3210
+
+         1080:0:0:0:8:800:200C:417A
+
+      Note that it is not necessary to write the leading zeros in an
+      individual field, but there must be at least one numeral in every
+      field (except for the case described in 2.).
+
+   2. Due to some methods of allocating certain styles of IPv6
+      addresses, it will be common for addresses to contain long strings
+      of zero bits.  In order to make writing addresses containing zero
+      bits easier a special syntax is available to compress the zeros.
+
+
+
+Hinden & Deering            Standards Track                     [Page 4]
+
+RFC 3513              IPv6 Addressing Architecture            April 2003
+
+
+      The use of "::" indicates one or more groups of 16 bits of zeros.
+      The "::" can only appear once in an address.  The "::" can also be
+      used to compress leading or trailing zeros in an address.
+
+      For example, the following addresses:
+
+         1080:0:0:0:8:800:200C:417A  a unicast address
+         FF01:0:0:0:0:0:0:101        a multicast address
+         0:0:0:0:0:0:0:1             the loopback address
+         0:0:0:0:0:0:0:0             the unspecified addresses
+
+      may be represented as:
+
+         1080::8:800:200C:417A       a unicast address
+         FF01::101                   a multicast address
+         ::1                         the loopback address
+         ::                          the unspecified addresses
+
+   3. An alternative form that is sometimes more convenient when dealing
+      with a mixed environment of IPv4 and IPv6 nodes is
+      x:x:x:x:x:x:d.d.d.d, where the 'x's are the hexadecimal values of
+      the six high-order 16-bit pieces of the address, and the 'd's are
+      the decimal values of the four low-order 8-bit pieces of the
+      address (standard IPv4 representation).  Examples:
+
+         0:0:0:0:0:0:13.1.68.3
+
+         0:0:0:0:0:FFFF:129.144.52.38
+
+      or in compressed form:
+
+         ::13.1.68.3
+
+         ::FFFF:129.144.52.38
+
+2.3 Text Representation of Address Prefixes
+
+   The text representation of IPv6 address prefixes is similar to the
+   way IPv4 addresses prefixes are written in CIDR notation [CIDR].  An
+   IPv6 address prefix is represented by the notation:
+
+      ipv6-address/prefix-length
+
+   where
+
+      ipv6-address    is an IPv6 address in any of the notations listed
+                      in section 2.2.
+
+
+
+
+Hinden & Deering            Standards Track                     [Page 5]
+
+RFC 3513              IPv6 Addressing Architecture            April 2003
+
+
+      prefix-length   is a decimal value specifying how many of the
+                      leftmost contiguous bits of the address comprise
+                      the prefix.
+
+   For example, the following are legal representations of the 60-bit
+   prefix 12AB00000000CD3 (hexadecimal):
+
+      12AB:0000:0000:CD30:0000:0000:0000:0000/60
+      12AB::CD30:0:0:0:0/60
+      12AB:0:0:CD30::/60
+
+   The following are NOT legal representations of the above prefix:
+
+      12AB:0:0:CD3/60   may drop leading zeros, but not trailing zeros,
+                        within any 16-bit chunk of the address
+
+      12AB::CD30/60     address to left of "/" expands to
+                        12AB:0000:0000:0000:0000:000:0000:CD30
+
+      12AB::CD3/60      address to left of "/" expands to
+                        12AB:0000:0000:0000:0000:000:0000:0CD3
+
+   When writing both a node address and a prefix of that node address
+   (e.g., the node's subnet prefix), the two can combined as follows:
+
+      the node address      12AB:0:0:CD30:123:4567:89AB:CDEF
+      and its subnet number 12AB:0:0:CD30::/60
+
+      can be abbreviated as 12AB:0:0:CD30:123:4567:89AB:CDEF/60
+
+2.4 Address Type Identification
+
+   The type of an IPv6 address is identified by the high-order bits of
+   the address, as follows:
+
+   Address type         Binary prefix        IPv6 notation   Section
+   ------------         -------------        -------------   -------
+   Unspecified          00...0  (128 bits)   ::/128          2.5.2
+   Loopback             00...1  (128 bits)   ::1/128         2.5.3
+   Multicast            11111111             FF00::/8        2.7
+   Link-local unicast   1111111010           FE80::/10       2.5.6
+   Site-local unicast   1111111011           FEC0::/10       2.5.6
+   Global unicast       (everything else)
+
+   Anycast addresses are taken from the unicast address spaces (of any
+   scope) and are not syntactically distinguishable from unicast
+   addresses.
+
+
+
+
+Hinden & Deering            Standards Track                     [Page 6]
+
+RFC 3513              IPv6 Addressing Architecture            April 2003
+
+
+   The general format of global unicast addresses is described in
+   section 2.5.4.  Some special-purpose subtypes of global unicast
+   addresses which contain embedded IPv4 addresses (for the purposes of
+   IPv4-IPv6 interoperation) are described in section 2.5.5.
+
+   Future specifications may redefine one or more sub-ranges of the
+   global unicast space for other purposes, but unless and until that
+   happens, implementations must treat all addresses that do not start
+   with any of the above-listed prefixes as global unicast addresses.
+
+2.5 Unicast Addresses
+
+   IPv6 unicast addresses are aggregable with prefixes of arbitrary
+   bit-length similar to IPv4 addresses under Classless Interdomain
+   Routing.
+
+   There are several types of unicast addresses in IPv6, in particular
+   global unicast, site-local unicast, and link-local unicast.  There
+   are also some special-purpose subtypes of global unicast, such as
+   IPv6 addresses with embedded IPv4 addresses or encoded NSAP
+   addresses.  Additional address types or subtypes can be defined in
+   the future.
+
+   IPv6 nodes may have considerable or little knowledge of the internal
+   structure of the IPv6 address, depending on the role the node plays
+   (for instance, host versus router).  At a minimum, a node may
+   consider that unicast addresses (including its own) have no internal
+   structure:
+
+   |                           128 bits                              |
+   +-----------------------------------------------------------------+
+   |                          node address                           |
+   +-----------------------------------------------------------------+
+
+   A slightly sophisticated host (but still rather simple) may
+   additionally be aware of subnet prefix(es) for the link(s) it is
+   attached to, where different addresses may have different values for
+   n:
+
+   |                         n bits                 |   128-n bits   |
+   +------------------------------------------------+----------------+
+   |                   subnet prefix                | interface ID   |
+   +------------------------------------------------+----------------+
+
+   Though a very simple router may have no knowledge of the internal
+   structure of IPv6 unicast addresses, routers will more generally have
+   knowledge of one or more of the hierarchical boundaries for the
+   operation of routing protocols.  The known boundaries will differ
+
+
+
+Hinden & Deering            Standards Track                     [Page 7]
+
+RFC 3513              IPv6 Addressing Architecture            April 2003
+
+
+   from router to router, depending on what positions the router holds
+   in the routing hierarchy.
+
+2.5.1 Interface Identifiers
+
+   Interface identifiers in IPv6 unicast addresses are used to identify
+   interfaces on a link.  They are required to be unique within a subnet
+   prefix.  It is recommended that the same interface identifier not be
+   assigned to different nodes on a link.  They may also be unique over
+   a broader scope.  In some cases an interface's identifier will be
+   derived directly from that interface's link-layer address.  The same
+   interface identifier may be used on multiple interfaces on a single
+   node, as long as they are attached to different subnets.
+
+   Note that the uniqueness of interface identifiers is independent of
+   the uniqueness of IPv6 addresses.  For example, a global unicast
+   address may be created with a non-global scope interface identifier
+   and a site-local address may be created with a global scope interface
+   identifier.
+
+   For all unicast addresses, except those that start with binary value
+   000, Interface IDs are required to be 64 bits long and to be
+   constructed in Modified EUI-64 format.
+
+   Modified EUI-64 format based Interface identifiers may have global
+   scope when derived from a global token (e.g., IEEE 802 48-bit MAC or
+   IEEE EUI-64 identifiers [EUI64]) or may have local scope where a
+   global token is not available (e.g., serial links, tunnel end-points,
+   etc.) or where global tokens are undesirable (e.g., temporary tokens
+   for privacy [PRIV]).
+
+   Modified EUI-64 format interface identifiers are formed by inverting
+   the "u" bit (universal/local bit in IEEE EUI-64 terminology) when
+   forming the interface identifier from IEEE EUI-64 identifiers.  In
+   the resulting Modified EUI-64 format the "u" bit is set to one (1) to
+   indicate global scope, and it is set to zero (0) to indicate local
+   scope.  The first three octets in binary of an IEEE EUI-64 identifier
+   are as follows:
+
+       0       0 0       1 1       2
+      |0       7 8       5 6       3|
+      +----+----+----+----+----+----+
+      |cccc|ccug|cccc|cccc|cccc|cccc|
+      +----+----+----+----+----+----+
+
+   written in Internet standard bit-order , where "u" is the
+   universal/local bit, "g" is the individual/group bit, and "c" are the
+   bits of the company_id.  Appendix A: "Creating Modified EUI-64 format
+
+
+
+Hinden & Deering            Standards Track                     [Page 8]
+
+RFC 3513              IPv6 Addressing Architecture            April 2003
+
+
+   Interface Identifiers" provides examples on the creation of Modified
+   EUI-64 format based interface identifiers.
+
+   The motivation for inverting the "u" bit when forming an interface
+   identifier is to make it easy for system administrators to hand
+   configure non-global identifiers when hardware tokens are not
+   available.  This is expected to be case for serial links, tunnel end-
+   points, etc.  The alternative would have been for these to be of the
+   form 0200:0:0:1, 0200:0:0:2, etc., instead of the much simpler 1, 2,
+   etc.
+
+   The use of the universal/local bit in the Modified EUI-64 format
+   identifier is to allow development of future technology that can take
+   advantage of interface identifiers with global scope.
+
+   The details of forming interface identifiers are defined in the
+   appropriate "IPv6 over <link>" specification such as "IPv6 over
+   Ethernet" [ETHER], "IPv6 over FDDI" [FDDI], etc.
+
+2.5.2 The Unspecified Address
+
+   The address 0:0:0:0:0:0:0:0 is called the unspecified address.  It
+   must never be assigned to any node.  It indicates the absence of an
+   address.  One example of its use is in the Source Address field of
+   any IPv6 packets sent by an initializing host before it has learned
+   its own address.
+
+   The unspecified address must not be used as the destination address
+   of IPv6 packets or in IPv6 Routing Headers.  An IPv6 packet with a
+   source address of unspecified must never be forwarded by an IPv6
+   router.
+
+2.5.3 The Loopback Address
+
+   The unicast address 0:0:0:0:0:0:0:1 is called the loopback address.
+   It may be used by a node to send an IPv6 packet to itself.  It may
+   never be assigned to any physical interface.   It is treated as
+   having link-local scope, and may be thought of as the link-local
+   unicast address of a virtual interface (typically called "the
+   loopback interface") to an imaginary link that goes nowhere.
+
+   The loopback address must not be used as the source address in IPv6
+   packets that are sent outside of a single node.  An IPv6 packet with
+   a destination address of loopback must never be sent outside of a
+   single node and must never be forwarded by an IPv6 router.  A packet
+   received on an interface with destination address of loopback must be
+   dropped.
+
+
+
+
+Hinden & Deering            Standards Track                     [Page 9]
+
+RFC 3513              IPv6 Addressing Architecture            April 2003
+
+
+2.5.4 Global Unicast Addresses
+
+   The general format for IPv6 global unicast addresses is as follows:
+
+   |         n bits         |   m bits  |       128-n-m bits         |
+   +------------------------+-----------+----------------------------+
+   | global routing prefix  | subnet ID |       interface ID         |
+   +------------------------+-----------+----------------------------+
+
+   where the global routing prefix is a (typically hierarchically-
+   structured) value assigned to a site (a cluster of subnets/links),
+   the subnet ID is an identifier of a link within the site, and the
+   interface ID is as defined in section 2.5.1.
+
+   All global unicast addresses other than those that start with binary
+   000 have a 64-bit interface ID field (i.e., n + m = 64), formatted as
+   described in section 2.5.1.  Global unicast addresses that start with
+   binary 000 have no such constraint on the size or structure of the
+   interface ID field.
+
+   Examples of global unicast addresses that start with binary 000 are
+   the IPv6 address with embedded IPv4 addresses described in section
+   2.5.5 and the IPv6 address containing encoded NSAP addresses
+   specified in [NSAP].  An example of global addresses starting with a
+   binary value other than 000 (and therefore having a 64-bit interface
+   ID field) can be found in [AGGR].
+
+2.5.5 IPv6 Addresses with Embedded IPv4 Addresses
+
+   The IPv6 transition mechanisms [TRAN] include a technique for hosts
+   and routers to dynamically tunnel IPv6 packets over IPv4 routing
+   infrastructure.  IPv6 nodes that use this technique are assigned
+   special IPv6 unicast addresses that carry a global IPv4 address in
+   the low-order 32 bits.  This type of address is termed an "IPv4-
+   compatible IPv6 address" and has the format:
+
+   |                80 bits               | 16 |      32 bits        |
+   +--------------------------------------+--------------------------+
+   |0000..............................0000|0000|    IPv4 address     |
+   +--------------------------------------+----+---------------------+
+
+   Note: The IPv4 address used in the "IPv4-compatible IPv6 address"
+   must be a globally-unique IPv4 unicast address.
+
+   A second type of IPv6 address which holds an embedded IPv4 address is
+   also defined.  This address type is used to represent the addresses
+   of IPv4 nodes as IPv6 addresses.  This type of address is termed an
+   "IPv4-mapped IPv6 address" and has the format:
+
+
+
+Hinden & Deering            Standards Track                    [Page 10]
+
+RFC 3513              IPv6 Addressing Architecture            April 2003
+
+
+   |                80 bits               | 16 |      32 bits        |
+   +--------------------------------------+--------------------------+
+   |0000..............................0000|FFFF|    IPv4 address     |
+   +--------------------------------------+----+---------------------+
+
+2.5.6 Local-Use IPv6 Unicast Addresses
+
+   There are two types of local-use unicast addresses defined.  These
+   are Link-Local and Site-Local.  The Link-Local is for use on a single
+   link and the Site-Local is for use in a single site.  Link-Local
+   addresses have the following format:
+
+   |   10     |
+   |  bits    |         54 bits         |          64 bits           |
+   +----------+-------------------------+----------------------------+
+   |1111111010|           0             |       interface ID         |
+   +----------+-------------------------+----------------------------+
+
+   Link-Local addresses are designed to be used for addressing on a
+   single link for purposes such as automatic address configuration,
+   neighbor discovery, or when no routers are present.
+
+   Routers must not forward any packets with link-local source or
+   destination addresses to other links.
+
+   Site-Local addresses have the following format:
+
+   |   10     |
+   |  bits    |         54 bits         |         64 bits            |
+   +----------+-------------------------+----------------------------+
+   |1111111011|        subnet ID        |       interface ID         |
+   +----------+-------------------------+----------------------------+
+
+   Site-local addresses are designed to be used for addressing inside of
+   a site without the need for a global prefix.  Although a subnet ID
+   may be up to 54-bits long, it is expected that globally-connected
+   sites will use the same subnet IDs for site-local and global
+   prefixes.
+
+   Routers must not forward any packets with site-local source or
+   destination addresses outside of the site.
+
+
+
+
+
+
+
+
+
+
+Hinden & Deering            Standards Track                    [Page 11]
+
+RFC 3513              IPv6 Addressing Architecture            April 2003
+
+
+2.6 Anycast Addresses
+
+   An IPv6 anycast address is an address that is assigned to more than
+   one interface (typically belonging to different nodes), with the
+   property that a packet sent to an anycast address is routed to the
+   "nearest" interface having that address, according to the routing
+   protocols' measure of distance.
+
+   Anycast addresses are allocated from the unicast address space, using
+   any of the defined unicast address formats.  Thus, anycast addresses
+   are syntactically indistinguishable from unicast addresses.  When a
+   unicast address is assigned to more than one interface, thus turning
+   it into an anycast address, the nodes to which the address is
+   assigned must be explicitly configured to know that it is an anycast
+   address.
+
+   For any assigned anycast address, there is a longest prefix P of that
+   address that identifies the topological region in which all
+   interfaces belonging to that anycast address reside.  Within the
+   region identified by P, the anycast address must be maintained as a
+   separate entry in the routing system (commonly referred to as a "host
+   route"); outside the region identified by P, the anycast address may
+   be aggregated into the routing entry for prefix P.
+
+   Note that in the worst case, the prefix P of an anycast set may be
+   the null prefix, i.e., the members of the set may have no topological
+   locality.  In that case, the anycast address must be maintained as a
+   separate routing entry throughout the entire internet, which presents
+   a severe scaling limit on how many such "global" anycast sets may be
+   supported.  Therefore, it is expected that support for global anycast
+   sets may be unavailable or very restricted.
+
+   One expected use of anycast addresses is to identify the set of
+   routers belonging to an organization providing internet service.
+   Such addresses could be used as intermediate addresses in an IPv6
+   Routing header, to cause a packet to be delivered via a particular
+   service provider or sequence of service providers.
+
+   Some other possible uses are to identify the set of routers attached
+   to a particular subnet, or the set of routers providing entry into a
+   particular routing domain.
+
+   There is little experience with widespread, arbitrary use of internet
+   anycast addresses, and some known complications and hazards when
+   using them in their full generality [ANYCST].  Until more experience
+   has been gained and solutions are specified, the following
+   restrictions are imposed on IPv6 anycast addresses:
+
+
+
+
+Hinden & Deering            Standards Track                    [Page 12]
+
+RFC 3513              IPv6 Addressing Architecture            April 2003
+
+
+   o  An anycast address must not be used as the source address of an
+      IPv6 packet.
+
+   o  An anycast address must not be assigned to an IPv6 host, that is,
+      it may be assigned to an IPv6 router only.
+
+2.6.1 Required Anycast Address
+
+   The Subnet-Router anycast address is predefined.  Its format is as
+   follows:
+
+   |                         n bits                 |   128-n bits   |
+   +------------------------------------------------+----------------+
+   |                   subnet prefix                | 00000000000000 |
+   +------------------------------------------------+----------------+
+
+   The "subnet prefix" in an anycast address is the prefix which
+   identifies a specific link.  This anycast address is syntactically
+   the same as a unicast address for an interface on the link with the
+   interface identifier set to zero.
+
+   Packets sent to the Subnet-Router anycast address will be delivered
+   to one router on the subnet.  All routers are required to support the
+   Subnet-Router anycast addresses for the subnets to which they have
+   interfaces.
+
+   The subnet-router anycast address is intended to be used for
+   applications where a node needs to communicate with any one of the
+   set of routers.
+
+2.7 Multicast Addresses
+
+   An IPv6 multicast address is an identifier for a group of interfaces
+   (typically on different nodes).  An interface may belong to any
+   number of multicast groups.  Multicast addresses have the following
+   format:
+
+   |   8    |  4 |  4 |                  112 bits                   |
+   +------ -+----+----+---------------------------------------------+
+   |11111111|flgs|scop|                  group ID                   |
+   +--------+----+----+---------------------------------------------+
+
+         binary 11111111 at the start of the address identifies the
+         address as being a multicast address.
+
+                                       +-+-+-+-+
+         flgs is a set of 4 flags:     |0|0|0|T|
+                                       +-+-+-+-+
+
+
+
+Hinden & Deering            Standards Track                    [Page 13]
+
+RFC 3513              IPv6 Addressing Architecture            April 2003
+
+
+            The high-order 3 flags are reserved, and must be initialized
+            to 0.
+
+            T = 0 indicates a permanently-assigned ("well-known")
+            multicast address, assigned by the Internet Assigned Number
+            Authority (IANA).
+
+            T = 1 indicates a non-permanently-assigned ("transient")
+            multicast address.
+
+         scop is a 4-bit multicast scope value used to limit the scope
+         of the multicast group.  The values are:
+
+            0  reserved
+            1  interface-local scope
+            2  link-local scope
+            3  reserved
+            4  admin-local scope
+            5  site-local scope
+            6  (unassigned)
+            7  (unassigned)
+            8  organization-local scope
+            9  (unassigned)
+            A  (unassigned)
+            B  (unassigned)
+            C  (unassigned)
+            D  (unassigned)
+            E  global scope
+            F  reserved
+
+            interface-local scope spans only a single interface on a
+            node, and is useful only for loopback transmission of
+            multicast.
+
+            link-local and site-local multicast scopes span the same
+            topological regions as the corresponding unicast scopes.
+
+            admin-local scope is the smallest scope that must be
+            administratively configured, i.e., not automatically derived
+            from physical connectivity or other, non- multicast-related
+            configuration.
+
+            organization-local scope is intended to span multiple sites
+            belonging to a single organization.
+
+            scopes labeled "(unassigned)" are available for
+            administrators to define additional multicast regions.
+
+
+
+
+Hinden & Deering            Standards Track                    [Page 14]
+
+RFC 3513              IPv6 Addressing Architecture            April 2003
+
+
+         group ID identifies the multicast group, either permanent or
+         transient, within the given scope.
+
+   The "meaning" of a permanently-assigned multicast address is
+   independent of the scope value.  For example, if the "NTP servers
+   group" is assigned a permanent multicast address with a group ID of
+   101 (hex), then:
+
+      FF01:0:0:0:0:0:0:101 means all NTP servers on the same interface
+      (i.e., the same node) as the sender.
+
+      FF02:0:0:0:0:0:0:101 means all NTP servers on the same link as the
+      sender.
+
+      FF05:0:0:0:0:0:0:101 means all NTP servers in the same site as the
+      sender.
+
+      FF0E:0:0:0:0:0:0:101 means all NTP servers in the internet.
+
+   Non-permanently-assigned multicast addresses are meaningful only
+   within a given scope.  For example, a group identified by the non-
+   permanent, site-local multicast address FF15:0:0:0:0:0:0:101 at one
+   site bears no relationship to a group using the same address at a
+   different site, nor to a non-permanent group using the same group ID
+   with different scope, nor to a permanent group with the same group
+   ID.
+
+   Multicast addresses must not be used as source addresses in IPv6
+   packets or appear in any Routing header.
+
+   Routers must not forward any multicast packets beyond of the scope
+   indicated by the scop field in the destination multicast address.
+
+   Nodes must not originate a packet to a multicast address whose scop
+   field contains the reserved value 0; if such a packet is received, it
+   must be silently dropped.  Nodes should not originate a packet to a
+   multicast address whose scop field contains the reserved value F; if
+   such a packet is sent or received, it must be treated the same as
+   packets destined to a global (scop E) multicast address.
+
+2.7.1 Pre-Defined Multicast Addresses
+
+   The following well-known multicast addresses are pre-defined.  The
+   group ID's defined in this section are defined for explicit scope
+   values.
+
+   Use of these group IDs for any other scope values, with the T flag
+   equal to 0, is not allowed.
+
+
+
+Hinden & Deering            Standards Track                    [Page 15]
+
+RFC 3513              IPv6 Addressing Architecture            April 2003
+
+
+      Reserved Multicast Addresses:   FF00:0:0:0:0:0:0:0
+                                      FF01:0:0:0:0:0:0:0
+                                      FF02:0:0:0:0:0:0:0
+                                      FF03:0:0:0:0:0:0:0
+                                      FF04:0:0:0:0:0:0:0
+                                      FF05:0:0:0:0:0:0:0
+                                      FF06:0:0:0:0:0:0:0
+                                      FF07:0:0:0:0:0:0:0
+                                      FF08:0:0:0:0:0:0:0
+                                      FF09:0:0:0:0:0:0:0
+                                      FF0A:0:0:0:0:0:0:0
+                                      FF0B:0:0:0:0:0:0:0
+                                      FF0C:0:0:0:0:0:0:0
+                                      FF0D:0:0:0:0:0:0:0
+                                      FF0E:0:0:0:0:0:0:0
+                                      FF0F:0:0:0:0:0:0:0
+
+   The above multicast addresses are reserved and shall never be
+   assigned to any multicast group.
+
+      All Nodes Addresses:    FF01:0:0:0:0:0:0:1
+                              FF02:0:0:0:0:0:0:1
+
+   The above multicast addresses identify the group of all IPv6 nodes,
+   within scope 1 (interface-local) or 2 (link-local).
+
+      All Routers Addresses:   FF01:0:0:0:0:0:0:2
+                               FF02:0:0:0:0:0:0:2
+                               FF05:0:0:0:0:0:0:2
+
+   The above multicast addresses identify the group of all IPv6 routers,
+   within scope 1 (interface-local), 2 (link-local), or 5 (site-local).
+
+      Solicited-Node Address:  FF02:0:0:0:0:1:FFXX:XXXX
+
+   Solicited-node multicast address are computed as a function of a
+   node's unicast and anycast addresses.  A solicited-node multicast
+   address is formed by taking the low-order 24 bits of an address
+   (unicast or anycast) and appending those bits to the prefix
+   FF02:0:0:0:0:1:FF00::/104 resulting in a multicast address in the
+   range
+
+      FF02:0:0:0:0:1:FF00:0000
+
+   to
+
+      FF02:0:0:0:0:1:FFFF:FFFF
+
+
+
+
+Hinden & Deering            Standards Track                    [Page 16]
+
+RFC 3513              IPv6 Addressing Architecture            April 2003
+
+
+   For example, the solicited node multicast address corresponding to
+   the IPv6 address 4037::01:800:200E:8C6C is FF02::1:FF0E:8C6C.  IPv6
+   addresses that differ only in the high-order bits, e.g., due to
+   multiple high-order prefixes associated with different aggregations,
+   will map to the same solicited-node address thereby, reducing the
+   number of multicast addresses a node must join.
+
+   A node is required to compute and join (on the appropriate interface)
+   the associated Solicited-Node multicast addresses for every unicast
+   and anycast address it is assigned.
+
+2.8 A Node's Required Addresses
+
+   A host is required to recognize the following addresses as
+   identifying itself:
+
+      o  Its required Link-Local Address for each interface.
+      o  Any additional Unicast and Anycast Addresses that have been
+         configured for the node's interfaces (manually or
+         automatically).
+      o  The loopback address.
+      o  The All-Nodes Multicast Addresses defined in section 2.7.1.
+      o  The Solicited-Node Multicast Address for each of its unicast
+         and anycast addresses.
+      o  Multicast Addresses of all other groups to which the node
+         belongs.
+
+   A router is required to recognize all addresses that a host is
+   required to recognize, plus the following addresses as identifying
+   itself:
+
+      o  The Subnet-Router Anycast Addresses for all interfaces for
+         which it is configured to act as a router.
+      o  All other Anycast Addresses with which the router has been
+         configured.
+      o  The All-Routers Multicast Addresses defined in section 2.7.1.
+
+3. Security Considerations
+
+   IPv6 addressing documents do not have any direct impact on Internet
+   infrastructure security.  Authentication of IPv6 packets is defined
+   in [AUTH].
+
+
+
+
+
+
+
+
+
+Hinden & Deering            Standards Track                    [Page 17]
+
+RFC 3513              IPv6 Addressing Architecture            April 2003
+
+
+4. IANA Considerations
+
+   The table and notes at http://www.isi.edu/in-
+   notes/iana/assignments/ipv6-address-space.txt should be replaced with
+   the following:
+
+   INTERNET PROTOCOL VERSION 6 ADDRESS SPACE
+
+   The initial assignment of IPv6 address space is as follows:
+
+   Allocation                            Prefix         Fraction of
+                                         (binary)       Address Space
+   -----------------------------------   --------       -------------
+   Unassigned (see Note 1 below)         0000 0000      1/256
+   Unassigned                            0000 0001      1/256
+   Reserved for NSAP Allocation          0000 001       1/128 [RFC1888]
+   Unassigned                            0000 01        1/64
+   Unassigned                            0000 1         1/32
+   Unassigned                            0001           1/16
+   Global Unicast                        001            1/8   [RFC2374]
+   Unassigned                            010            1/8
+   Unassigned                            011            1/8
+   Unassigned                            100            1/8
+   Unassigned                            101            1/8
+   Unassigned                            110            1/8
+   Unassigned                            1110           1/16
+   Unassigned                            1111 0         1/32
+   Unassigned                            1111 10        1/64
+   Unassigned                            1111 110       1/128
+   Unassigned                            1111 1110 0    1/512
+   Link-Local Unicast Addresses          1111 1110 10   1/1024
+   Site-Local Unicast Addresses          1111 1110 11   1/1024
+   Multicast Addresses                   1111 1111      1/256
+
+   Notes:
+
+   1. The "unspecified address", the "loopback address", and the IPv6
+      Addresses with Embedded IPv4 Addresses are assigned out of the
+      0000 0000 binary prefix space.
+
+   2. For now, IANA should limit its allocation of IPv6 unicast address
+      space to the range of addresses that start with binary value 001.
+      The rest of the global unicast address space (approximately 85% of
+      the IPv6 address space) is reserved for future definition and use,
+      and is not to be assigned by IANA at this time.
+
+
+
+
+
+
+Hinden & Deering            Standards Track                    [Page 18]
+
+RFC 3513              IPv6 Addressing Architecture            April 2003
+
+
+5.  References
+
+5.1  Normative References
+
+   [IPV6]    Deering, S. and R. Hinden, "Internet Protocol, Version 6
+             (IPv6) Specification", RFC 2460, December 1998.
+
+   [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
+             3", BCP 9 , RFC 2026, October 1996.
+
+5.2  Informative References
+
+   [ANYCST]  Partridge, C., Mendez, T. and W. Milliken, "Host Anycasting
+             Service", RFC 1546, November 1993.
+
+   [AUTH]    Kent, S. and R. Atkinson, "IP Authentication Header", RFC
+             2402, November 1998.
+
+   [AGGR]    Hinden, R., O'Dell, M. and S. Deering, "An Aggregatable
+             Global Unicast Address Format", RFC 2374, July 1998.
+
+   [CIDR]    Fuller, V., Li, T., Yu, J. and K. Varadhan, "Classless
+             Inter-Domain Routing (CIDR): An Address Assignment and
+             Aggregation Strategy", RFC 1519, September 1993.
+
+   [ETHER]   Crawford, M., "Transmission of IPv6 Packets over Ethernet
+             Networks", RFC 2464, December 1998.
+
+   [EUI64]   IEEE, "Guidelines for 64-bit Global Identifier (EUI-64)
+             Registration Authority",
+             http://standards.ieee.org/regauth/oui/tutorials/EUI64.html,
+             March 1997.
+
+   [FDDI]    Crawford, M., "Transmission of IPv6 Packets over FDDI
+             Networks", RFC 2467, December 1998.
+
+   [MASGN]   Hinden, R. and S. Deering, "IPv6 Multicast Address
+             Assignments", RFC 2375, July 1998.
+
+   [NSAP]    Bound, J., Carpenter, B., Harrington, D., Houldsworth, J.
+             and A. Lloyd, "OSI NSAPs and IPv6", RFC 1888, August 1996.
+
+   [PRIV]    Narten, T. and R. Draves, "Privacy Extensions for Stateless
+             Address Autoconfiguration in IPv6", RFC 3041, January 2001.
+
+   [TOKEN]   Crawford, M., Narten, T. and S. Thomas, "Transmission of
+             IPv6 Packets over Token Ring Networks", RFC 2470, December
+             1998.
+
+
+
+Hinden & Deering            Standards Track                    [Page 19]
+
+RFC 3513              IPv6 Addressing Architecture            April 2003
+
+
+   [TRAN]    Gilligan, R. and E. Nordmark, "Transition Mechanisms for
+             IPv6 Hosts and Routers", RFC 2893, August 2000.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hinden & Deering            Standards Track                    [Page 20]
+
+RFC 3513              IPv6 Addressing Architecture            April 2003
+
+
+APPENDIX A: Creating Modified EUI-64 format Interface Identifiers
+
+   Depending on the characteristics of a specific link or node there are
+   a number of approaches for creating Modified EUI-64 format interface
+   identifiers.  This appendix describes some of these approaches.
+
+Links or Nodes with IEEE EUI-64 Identifiers
+
+   The only change needed to transform an IEEE EUI-64 identifier to an
+   interface identifier is to invert the "u" (universal/local) bit.  For
+   example, a globally unique IEEE EUI-64 identifier of the form:
+
+   |0              1|1              3|3              4|4              6|
+   |0              5|6              1|2              7|8              3|
+   +----------------+----------------+----------------+----------------+
+   |cccccc0gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm|mmmmmmmmmmmmmmmm|
+   +----------------+----------------+----------------+----------------+
+
+   where "c" are the bits of the assigned company_id, "0" is the value
+   of the universal/local bit to indicate global scope, "g" is
+   individual/group bit, and "m" are the bits of the manufacturer-
+   selected extension identifier.  The IPv6 interface identifier would
+   be of the form:
+
+   |0              1|1              3|3              4|4              6|
+   |0              5|6              1|2              7|8              3|
+   +----------------+----------------+----------------+----------------+
+   |cccccc1gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm|mmmmmmmmmmmmmmmm|
+   +----------------+----------------+----------------+----------------+
+
+   The only change is inverting the value of the universal/local bit.
+
+Links or Nodes with IEEE 802 48 bit MAC's
+
+   [EUI64] defines a method to create a IEEE EUI-64 identifier from an
+   IEEE 48bit MAC identifier.  This is to insert two octets, with
+   hexadecimal values of 0xFF and 0xFE, in the middle of the 48 bit MAC
+   (between the company_id and vendor supplied id).  For example, the 48
+   bit IEEE MAC with global scope:
+
+
+
+
+
+
+
+
+
+
+
+
+Hinden & Deering            Standards Track                    [Page 21]
+
+RFC 3513              IPv6 Addressing Architecture            April 2003
+
+
+   |0              1|1              3|3              4|
+   |0              5|6              1|2              7|
+   +----------------+----------------+----------------+
+   |cccccc0gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm|
+   +----------------+----------------+----------------+
+
+   where "c" are the bits of the assigned company_id, "0" is the value
+   of the universal/local bit to indicate global scope, "g" is
+   individual/group bit, and "m" are the bits of the manufacturer-
+   selected extension identifier.  The interface identifier would be of
+   the form:
+
+   |0              1|1              3|3              4|4              6|
+   |0              5|6              1|2              7|8              3|
+   +----------------+----------------+----------------+----------------+
+   |cccccc1gcccccccc|cccccccc11111111|11111110mmmmmmmm|mmmmmmmmmmmmmmmm|
+   +----------------+----------------+----------------+----------------+
+
+   When IEEE 802 48bit MAC addresses are available (on an interface or a
+   node), an implementation may use them to create interface identifiers
+   due to their availability and uniqueness properties.
+
+Links with Other Kinds of Identifiers
+
+   There are a number of types of links that have link-layer interface
+   identifiers other than IEEE EIU-64 or IEEE 802 48-bit MACs.  Examples
+   include LocalTalk and Arcnet.  The method to create an Modified EUI-
+   64 format identifier is to take the link identifier (e.g., the
+   LocalTalk 8 bit node identifier) and zero fill it to the left.  For
+   example, a LocalTalk 8 bit node identifier of hexadecimal value 0x4F
+   results in the following interface identifier:
+
+   |0              1|1              3|3              4|4              6|
+   |0              5|6              1|2              7|8              3|
+   +----------------+----------------+----------------+----------------+
+   |0000000000000000|0000000000000000|0000000000000000|0000000001001111|
+   +----------------+----------------+----------------+----------------+
+
+   Note that this results in the universal/local bit set to "0" to
+   indicate local scope.
+
+Links without Identifiers
+
+   There are a number of links that do not have any type of built-in
+   identifier.  The most common of these are serial links and configured
+   tunnels.  Interface identifiers must be chosen that are unique within
+   a subnet-prefix.
+
+
+
+
+Hinden & Deering            Standards Track                    [Page 22]
+
+RFC 3513              IPv6 Addressing Architecture            April 2003
+
+
+   When no built-in identifier is available on a link the preferred
+   approach is to use a global interface identifier from another
+   interface or one which is assigned to the node itself.  When using
+   this approach no other interface connecting the same node to the same
+   subnet-prefix may use the same identifier.
+
+   If there is no global interface identifier available for use on the
+   link the implementation needs to create a local-scope interface
+   identifier.  The only requirement is that it be unique within a
+   subnet prefix.  There are many possible approaches to select a
+   subnet-prefix-unique interface identifier.  These include:
+
+      Manual Configuration
+      Node Serial Number
+      Other node-specific token
+
+   The subnet-prefix-unique interface identifier should be generated in
+   a manner that it does not change after a reboot of a node or if
+   interfaces are added or deleted from the node.
+
+   The selection of the appropriate algorithm is link and implementation
+   dependent.  The details on forming interface identifiers are defined
+   in the appropriate "IPv6 over <link>" specification.  It is strongly
+   recommended that a collision detection algorithm be implemented as
+   part of any automatic algorithm.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hinden & Deering            Standards Track                    [Page 23]
+
+RFC 3513              IPv6 Addressing Architecture            April 2003
+
+
+APPENDIX B: Changes from RFC-2373
+
+   The following changes were made from RFC-2373 "IP Version 6
+   Addressing Architecture":
+
+   -  Clarified text in section 2.2 to allow "::" to represent one or
+      more groups of 16 bits of zeros.
+   -  Changed uniqueness requirement of Interface Identifiers from
+      unique on a link to unique within a subnet prefix.  Also added a
+      recommendation that the same interface identifier not be assigned
+      to different machines on a link.
+   -  Change site-local format to make the subnet ID field 54-bit long
+      and remove the 38-bit zero's field.
+   -  Added description of multicast scop values and rules to handle the
+      reserved scop value 0.
+   -  Revised sections 2.4 and 2.5.6 to simplify and clarify how
+      different address types  are identified.  This was done to insure
+      that implementations do not build in any knowledge about global
+      unicast format prefixes.  Changes include:
+         o  Removed Format Prefix (FP) terminology
+         o  Revised list of address types to only include exceptions to
+            global unicast and a singe entry that identifies everything
+            else as Global Unicast.
+         o  Removed list of defined prefix exceptions from section 2.5.6
+            as it is now the main part of section 2.4.
+   -  Clarified text relating to EUI-64 identifiers to distinguish
+      between IPv6's "Modified EUI-64 format" identifiers and IEEE EUI-
+      64 identifiers.
+   -  Combined the sections on the Global Unicast Addresses and NSAP
+      Addresses into a single section on Global Unicast Addresses,
+      generalized the Global Unicast format, and cited [AGGR] and [NSAP]
+      as examples.
+   -  Reordered sections 2.5.4 and 2.5.5.
+   -  Removed section 2.7.2 Assignment of New IPv6 Multicast Addresses
+      because this is being redefined elsewhere.
+   -  Added an IANA considerations section that updates the IANA IPv6
+      address allocations and documents the NSAP and AGGR allocations.
+   -  Added clarification that the "IPv4-compatible IPv6 address" must
+      use global IPv4 unicast addresses.
+   -  Divided references in to normative and non-normative sections.
+   -  Added reference to [PRIV] in section 2.5.1
+   -  Added clarification that routers must not forward multicast
+      packets outside of the scope indicated in the multicast address.
+   -  Added clarification that routers must not forward packets with
+       source address of the unspecified address.
+   -  Added clarification that routers must drop packets received on an
+      interface with destination address of loopback.
+   -  Clarified the definition of IPv4-mapped addresses.
+
+
+
+Hinden & Deering            Standards Track                    [Page 24]
+
+RFC 3513              IPv6 Addressing Architecture            April 2003
+
+
+   -  Removed the ABNF Description of Text Representations Appendix.
+   -  Removed the address block reserved for IPX addresses.
+   -  Multicast scope changes:
+         o  Changed name of scope value 1 from "node-local" to
+            "interface-local"
+         o  Defined scope value 4 as "admin-local"
+   -  Corrected reference to RFC1933 and updated references.
+   -  Many small changes to clarify and make the text more consistent.
+
+Authors' Addresses
+
+   Robert M. Hinden
+   Nokia
+   313 Fairchild Drive
+   Mountain View, CA 94043
+   USA
+
+   Phone: +1 650 625-2004
+   EMail: hinden@iprg.nokia.com
+
+
+   Stephen E. Deering
+   Cisco Systems, Inc.
+   170 West Tasman Drive
+   San Jose, CA 95134-1706
+   USA
+
+   Phone: +1 408 527-8213
+   EMail: deering@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hinden & Deering            Standards Track                    [Page 25]
+
+RFC 3513              IPv6 Addressing Architecture            April 2003
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2003).  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 Standards process must be
+   followed, or as required to translate it into 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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hinden & Deering            Standards Track                    [Page 26]
+
diff --git a/doc/rfc/rfc3596.txt b/doc/rfc/rfc3596.txt
new file mode 100644
index 0000000..f65690c
--- /dev/null
+++ b/doc/rfc/rfc3596.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+Network Working Group                                         S. Thomson
+Request for Comments: 3596                                         Cisco
+Obsoletes: 3152, 1886                                         C. Huitema
+Category: Standards Track                                      Microsoft
+                                                              V. Ksinant
+                                                                   6WIND
+                                                              M. Souissi
+                                                                   AFNIC
+                                                            October 2003
+
+
+                 DNS Extensions to Support IP Version 6
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2003).  All Rights Reserved.
+
+Abstract
+
+   This document defines the changes that need to be made to the Domain
+   Name System (DNS) to support hosts running IP version 6 (IPv6).  The
+   changes include a resource record type to store an IPv6 address, a
+   domain to support lookups based on an IPv6 address, and updated
+   definitions of existing query types that return Internet addresses as
+   part of additional section processing.  The extensions are designed
+   to be compatible with existing applications and, in particular, DNS
+   implementations themselves.
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
+   2.  New resource record definition and domain. . . . . . . . . . .  2
+       2.1.  AAAA record type . . . . . . . . . . . . . . . . . . . .  3
+       2.2.  AAAA data format . . . . . . . . . . . . . . . . . . . .  3
+       2.3.  AAAA query . . . . . . . . . . . . . . . . . . . . . . .  3
+       2.4.  Textual format of AAAA records . . . . . . . . . . . . .  3
+       2.5.  IP6.ARPA domain. . . . . . . . . . . . . . . . . . . . .  3
+   3.  Modifications to existing query types. . . . . . . . . . . . .  4
+   4.  Security Considerations. . . . . . . . . . . . . . . . . . . .  4
+   5.  IANA Considerations. . . . . . . . . . . . . . . . . . . . . .  4
+
+
+
+Thomson, et al.             Standards Track                     [Page 1]
+
+RFC 3596             DNS Extensions to Support IPv6         October 2003
+
+
+   6.  Intellectual Property Statement. . . . . . . . . . . . . . . .  4
+   Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . . .  5
+   Appendix A: Changes from RFC 1886. . . . . . . . . . . . . . . . .  6
+   Normative References . . . . . . . . . . . . . . . . . . . . . . .  6
+   Informative References . . . . . . . . . . . . . . . . . . . . . .  6
+   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . .  7
+   Full Copyright Statement . . . . . . . . . . . . . . . . . . . . .  8
+
+1. Introduction
+
+   Current support for the storage of Internet addresses in the Domain
+   Name System (DNS) [1,2] cannot easily be extended to support IPv6
+   addresses [3] since applications assume that address queries return
+   32-bit IPv4 addresses only.
+
+   To support the storage of IPv6 addresses in the DNS, this document
+   defines the following extensions:
+
+      o A resource record type is defined to map a domain name to an
+        IPv6 address.
+
+      o A domain is defined to support lookups based on address.
+
+      o Existing queries that perform additional section processing to
+        locate IPv4 addresses are redefined to perform additional
+        section processing on both IPv4 and IPv6 addresses.
+
+   The changes are designed to be compatible with existing software.
+   The existing support for IPv4 addresses is retained.  Transition
+   issues related to the co-existence of both IPv4 and IPv6 addresses in
+   the DNS are discussed in [4].
+
+   The IP protocol version used for querying resource records is
+   independent of the protocol version of the resource records; e.g.,
+   IPv4 transport can be used to query IPv6 records and vice versa.
+
+   This document combines RFC 1886 [5] and changes to RFC 1886 made by
+   RFC 3152 [6], obsoleting both.  Changes mainly consist in replacing
+   the IP6.INT domain by IP6.ARPA as defined in RFC 3152.
+
+2. New resource record definition and domain
+
+   A record type is defined to store a host's IPv6 address.  A host that
+   has more than one IPv6 address must have more than one such record.
+
+
+
+
+
+
+
+Thomson, et al.             Standards Track                     [Page 2]
+
+RFC 3596             DNS Extensions to Support IPv6         October 2003
+
+
+2.1 AAAA record type
+
+   The AAAA resource record type is a record specific to the Internet
+   class that stores a single IPv6 address.
+
+   The IANA assigned value of the type is 28 (decimal).
+
+2.2 AAAA data format
+
+   A 128 bit IPv6 address is encoded in the data portion of an AAAA
+   resource record in network byte order (high-order byte first).
+
+2.3 AAAA query
+
+   An AAAA query for a specified domain name in the Internet class
+   returns all associated AAAA resource records in the answer section of
+   a response.
+
+   A type AAAA query does not trigger additional section processing.
+
+2.4 Textual format of AAAA records
+
+   The textual representation of the data portion of the AAAA resource
+   record used in a master database file is the textual representation
+   of an IPv6 address as defined in [3].
+
+2.5 IP6.ARPA Domain
+
+   A special domain is defined to look up a record given an IPv6
+   address.  The intent of this domain is to provide a way of mapping an
+   IPv6 address to a host name, although it may be used for other
+   purposes as well.  The domain is rooted at IP6.ARPA.
+
+   An IPv6 address is represented as a name in the IP6.ARPA domain by a
+   sequence of nibbles separated by dots with the suffix ".IP6.ARPA".
+   The sequence of nibbles is encoded in reverse order, i.e., the
+   low-order nibble is encoded first, followed by the next low-order
+   nibble and so on.  Each nibble is represented by a hexadecimal digit.
+   For example, the reverse lookup domain name corresponding to the
+   address
+
+       4321:0:1:2:3:4:567:89ab
+
+   would be
+
+   b.a.9.8.7.6.5.0.4.0.0.0.3.0.0.0.2.0.0.0.1.0.0.0.0.0.0.0.1.2.3.4.IP6.
+                                                                  ARPA.
+
+
+
+
+Thomson, et al.             Standards Track                     [Page 3]
+
+RFC 3596             DNS Extensions to Support IPv6         October 2003
+
+
+3. Modifications to existing query types
+
+   All existing query types that perform type A additional section
+   processing, i.e., name server (NS), location of services (SRV) and
+   mail exchange (MX) query types, must be redefined to perform both
+   type A and type AAAA additional section processing.  These
+   definitions mean that a name server must add any relevant IPv4
+   addresses and any relevant IPv6 addresses available locally to the
+   additional section of a response when processing any one of the above
+   queries.
+
+4. Security Considerations
+
+   Any information obtained from the DNS must be regarded as unsafe
+   unless techniques specified in [7] or [8] are used.  The definitions
+   of the AAAA record type and of the IP6.ARPA domain do not change the
+   model for use of these techniques.
+
+   So, this specification is not believed to cause any new security
+   problems, nor to solve any existing ones.
+
+5. IANA Considerations
+
+   There are no IANA assignments to be performed.
+
+6. Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   intellectual property or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; neither does it represent that it
+   has made any effort to identify any such rights.  Information on the
+   IETF's procedures with respect to rights in standards-track and
+   standards-related documentation can be found in BCP-11.  Copies of
+   claims of rights made available for publication and any assurances of
+   licenses to be made available, or the result of an attempt made to
+   obtain a general license or permission for the use of such
+   proprietary rights by implementors or users of this specification can
+   be obtained from the IETF Secretariat.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights which may cover technology that may be required to practice
+   this standard.  Please address the information to the IETF Executive
+   Director.
+
+
+
+
+
+Thomson, et al.             Standards Track                     [Page 4]
+
+RFC 3596             DNS Extensions to Support IPv6         October 2003
+
+
+Acknowledgments
+
+   Vladimir Ksinant and Mohsen Souissi would like to thank Sebastien
+   Barbin (IRISA), Luc Beloeil (France Telecom R&D), Jean-Mickael Guerin
+   (6WIND), Vincent Levigneron (AFNIC), Alain Ritoux (6WIND), Frederic
+   Roudaut (IRISA) and G6 group for their help during the RFC 1886
+   Interop tests sessions.
+
+   Many thanks to Alain Durand and Olafur Gudmundsson for their support.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Thomson, et al.             Standards Track                     [Page 5]
+
+RFC 3596             DNS Extensions to Support IPv6         October 2003
+
+
+Appendix A: Changes from RFC 1886
+
+   The following changes were made from RFC 1886 "DNS Extensions to
+   support IP version 6":
+
+   - Replaced the "IP6.INT" domain by "IP6.ARPA".
+   - Mentioned SRV query types in section 3 "MODIFICATIONS TO
+     EXISTING QUERY TYPES"
+   - Added security considerations.
+   - Updated references :
+     * From RFC 1884 to RFC 3513 (IP Version 6 Addressing
+       Architecture).
+     * From "work in progress" to RFC 2893 (Transition Mechanisms for
+       IPv6 Hosts and Routers).
+     * Added reference to RFC 1886, RFC 3152, RFC 2535 and RFC 2845.
+   - Updated document abstract
+   - Added table of contents
+   - Added full copyright statement
+   - Added IANA considerations section
+   - Added Intellectual Property Statement
+
+Normative References
+
+   [1]  Mockapetris, P., "Domain Names - Concepts and Facilities", STD
+        13, RFC 1034, November 1987.
+
+   [2]  Mockapetris, P., "Domain Names - Implementation and
+        Specification", STD 13, RFC 1035, November 1987.
+
+   [3]  Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6)
+        Addressing Architecture", RFC 3513, April 2003.
+
+Informative References
+
+   [4]  Gilligan, R. and E. Nordmark, "Transition Mechanisms for IPv6
+        Hosts and Routers", RFC 2893, August 2000.
+
+   [5]  Thomson, S. and C. Huitema, "DNS Extensions to support IP
+        version 6", RFC 1886, December 1995.
+
+   [6]  Bush, R., "Delegation of IP6.ARPA", BCP 49, RFC 3152, August
+        2001.
+
+   [7]  Eastlake, D., "Domain Name System Security Extensions", RFC
+        2535, March 1999
+
+
+
+
+
+
+Thomson, et al.             Standards Track                     [Page 6]
+
+RFC 3596             DNS Extensions to Support IPv6         October 2003
+
+
+   [8]  Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington,
+        "Secret Key Transaction Authentication for DNS (TSIG)", RFC
+        2845, May 2000.
+
+Authors' Addresses
+
+   Susan Thomson
+   Cisco Systems
+   499 Thornall Street, 8th floor
+   Edison, NJ 08837
+
+   Phone: +1 732-635-3086
+   EMail:  sethomso@cisco.com
+
+
+   Christian Huitema
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA 98052-6399
+
+   EMail: huitema@microsoft.com
+
+
+   Vladimir Ksinant
+   6WIND S.A.
+   Immeuble Central Gare - Bat.C
+   1, place Charles de Gaulle
+   78180, Montigny-Le-Bretonneux - France
+
+   Phone: +33 1 39 30 92 36
+   EMail: vladimir.ksinant@6wind.com
+
+
+   Mohsen Souissi
+   AFNIC
+   Immeuble International
+   2, rue Stephenson,
+   78181, Saint-Quentin en Yvelines Cedex - France
+
+   Phone: +33 1 39 30 83 40
+   EMail: Mohsen.Souissi@nic.fr
+
+
+
+
+
+
+
+
+
+
+Thomson, et al.             Standards Track                     [Page 7]
+
+RFC 3596             DNS Extensions to Support IPv6         October 2003
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2003).  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 Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assignees.
+
+   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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Thomson, et al.             Standards Track                     [Page 8]
+
diff --git a/doc/rfc/rfc3597.txt b/doc/rfc/rfc3597.txt
new file mode 100644
index 0000000..19e9a55
--- /dev/null
+++ b/doc/rfc/rfc3597.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+Network Working Group                                      A. Gustafsson
+Request for Comments: 3597                                  Nominum Inc.
+Category: Standards Track                                 September 2003
+
+
+           Handling of Unknown DNS Resource Record (RR) Types
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2003).  All Rights Reserved.
+
+Abstract
+
+   Extending the Domain Name System (DNS) with new Resource Record (RR)
+   types currently requires changes to name server software.  This
+   document specifies the changes necessary to allow future DNS
+   implementations to handle new RR types transparently.
+
+1.  Introduction
+
+   The DNS is designed to be extensible to support new services through
+   the introduction of new resource record (RR) types.  In practice,
+   deploying a new RR type currently requires changes to the name server
+   software not only at the authoritative DNS server that is providing
+   the new information and the client making use of it, but also at all
+   slave servers for the zone containing it, and in some cases also at
+   caching name servers and forwarders used by the client.
+
+   Because the deployment of new server software is slow and expensive,
+   the potential of the DNS in supporting new services has never been
+   fully realized.  This memo proposes changes to name servers and to
+   procedures for defining new RR types aimed at simplifying the future
+   deployment of new RR types.
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC 2119].
+
+
+
+
+
+
+Gustafsson                  Standards Track                     [Page 1]
+
+RFC 3597            Handling of Unknown DNS RR Types      September 2003
+
+
+2.  Definition
+
+   An "RR of unknown type" is an RR whose RDATA format is not known to
+   the DNS implementation at hand, and whose type is not an assigned
+   QTYPE or Meta-TYPE as specified in [RFC 2929] (section 3.1) nor
+   within the range reserved in that section for assignment only to
+   QTYPEs and Meta-TYPEs.  Such an RR cannot be converted to a type-
+   specific text format, compressed, or otherwise handled in a type-
+   specific way.
+
+   In the case of a type whose RDATA format is class specific, an RR is
+   considered to be of unknown type when the RDATA format for that
+   combination of type and class is not known.
+
+3.  Transparency
+
+   To enable new RR types to be deployed without server changes, name
+   servers and resolvers MUST handle RRs of unknown type transparently.
+   That is, they must treat the RDATA section of such RRs as
+   unstructured binary data, storing and transmitting it without change
+   [RFC1123].
+
+   To ensure the correct operation of equality comparison (section 6)
+   and of the DNSSEC canonical form (section 7) when an RR type is known
+   to some but not all of the servers involved, servers MUST also
+   exactly preserve the RDATA of RRs of known type, except for changes
+   due to compression or decompression where allowed by section 4 of
+   this memo.  In particular, the character case of domain names that
+   are not subject to compression MUST be preserved.
+
+4.  Domain Name Compression
+
+   RRs containing compression pointers in the RDATA part cannot be
+   treated transparently, as the compression pointers are only
+   meaningful within the context of a DNS message.  Transparently
+   copying the RDATA into a new DNS message would cause the compression
+   pointers to point at the corresponding location in the new message,
+   which now contains unrelated data.  This would cause the compressed
+   name to be corrupted.
+
+   To avoid such corruption, servers MUST NOT compress domain names
+   embedded in the RDATA of types that are class-specific or not well-
+   known.  This requirement was stated in [RFC1123] without defining the
+   term "well-known"; it is hereby specified that only the RR types
+   defined in [RFC1035] are to be considered "well-known".
+
+
+
+
+
+
+Gustafsson                  Standards Track                     [Page 2]
+
+RFC 3597            Handling of Unknown DNS RR Types      September 2003
+
+
+   The specifications of a few existing RR types have explicitly allowed
+   compression contrary to this specification: [RFC2163] specified that
+   compression applies to the PX RR, and [RFC2535] allowed compression
+   in SIG RRs and NXT RRs records.  Since this specification disallows
+   compression in these cases, it is an update to [RFC2163] (section 4)
+   and [RFC2535] (sections 4.1.7 and 5.2).
+
+   Receiving servers MUST decompress domain names in RRs of well-known
+   type, and SHOULD also decompress RRs of type RP, AFSDB, RT, SIG, PX,
+   NXT, NAPTR, and SRV (although the current specification of the SRV RR
+   in [RFC2782] prohibits compression, [RFC2052] mandated it, and some
+   servers following that earlier specification are still in use).
+
+   Future specifications for new RR types that contain domain names
+   within their RDATA MUST NOT allow the use of name compression for
+   those names, and SHOULD explicitly state that the embedded domain
+   names MUST NOT be compressed.
+
+   As noted in [RFC1123], the owner name of an RR is always eligible for
+   compression.
+
+5.  Text Representation
+
+   In the "type" field of a master file line, an unknown RR type is
+   represented by the word "TYPE" immediately followed by the decimal RR
+   type number, with no intervening whitespace.  In the "class" field,
+   an unknown class is similarly represented as the word "CLASS"
+   immediately followed by the decimal class number.
+
+   This convention allows types and classes to be distinguished from
+   each other and from TTL values, allowing the "[<TTL>] [<class>]
+   <type> <RDATA>" and "[<class>] [<TTL>] <type> <RDATA>" forms of
+   [RFC1035] to both be unambiguously parsed.
+
+   The RDATA section of an RR of unknown type is represented as a
+   sequence of white space separated words as follows:
+
+      The special token \# (a backslash immediately followed by a hash
+      sign), which identifies the RDATA as having the generic encoding
+      defined herein rather than a traditional type-specific encoding.
+
+      An unsigned decimal integer specifying the RDATA length in octets.
+
+      Zero or more words of hexadecimal data encoding the actual RDATA
+      field, each containing an even number of hexadecimal digits.
+
+   If the RDATA is of zero length, the text representation contains only
+   the \# token and the single zero representing the length.
+
+
+
+Gustafsson                  Standards Track                     [Page 3]
+
+RFC 3597            Handling of Unknown DNS RR Types      September 2003
+
+
+   An implementation MAY also choose to represent some RRs of known type
+   using the above generic representations for the type, class and/or
+   RDATA, which carries the benefit of making the resulting master file
+   portable to servers where these types are unknown.  Using the generic
+   representation for the RDATA of an RR of known type can also be
+   useful in the case of an RR type where the text format varies
+   depending on a version, protocol, or similar field (or several)
+   embedded in the RDATA when such a field has a value for which no text
+   format is known, e.g., a LOC RR [RFC1876] with a VERSION other than
+   0.
+
+   Even though an RR of known type represented in the \# format is
+   effectively treated as an unknown type for the purpose of parsing the
+   RDATA text representation, all further processing by the server MUST
+   treat it as a known type and take into account any applicable type-
+   specific rules regarding compression, canonicalization, etc.
+
+   The following are examples of RRs represented in this manner,
+   illustrating various combinations of generic and type-specific
+   encodings for the different fields of the master file format:
+
+      a.example.   CLASS32     TYPE731         \# 6 abcd (
+                                               ef 01 23 45 )
+      b.example.   HS          TYPE62347       \# 0
+      e.example.   IN          A               \# 4 0A000001
+      e.example.   CLASS1      TYPE1           10.0.0.2
+
+6.  Equality Comparison
+
+   Certain DNS protocols, notably Dynamic Update [RFC2136], require RRs
+   to be compared for equality.  Two RRs of the same unknown type are
+   considered equal when their RDATA is bitwise equal.  To ensure that
+   the outcome of the comparison is identical whether the RR is known to
+   the server or not, specifications for new RR types MUST NOT specify
+   type-specific comparison rules.
+
+   This implies that embedded domain names, being included in the
+   overall bitwise comparison, are compared in a case-sensitive manner.
+
+   As a result, when a new RR type contains one or more embedded domain
+   names, it is possible to have multiple RRs owned by the same name
+   that differ only in the character case of the embedded domain
+   name(s).  This is similar to the existing possibility of multiple TXT
+   records differing only in character case, and not expected to cause
+   any problems in practice.
+
+
+
+
+
+
+Gustafsson                  Standards Track                     [Page 4]
+
+RFC 3597            Handling of Unknown DNS RR Types      September 2003
+
+
+7.  DNSSEC Canonical Form and Ordering
+
+   DNSSEC defines a canonical form and ordering for RRs [RFC2535]
+   (section 8.1).  In that canonical form, domain names embedded in the
+   RDATA are converted to lower case.
+
+   The downcasing is necessary to ensure the correctness of DNSSEC
+   signatures when case distinctions in domain names are lost due to
+   compression, but since it requires knowledge of the presence and
+   position of embedded domain names, it cannot be applied to unknown
+   types.
+
+   To ensure continued consistency of the canonical form of RR types
+   where compression is allowed, and for continued interoperability with
+   existing implementations that already implement the [RFC2535]
+   canonical form and apply it to their known RR types, the canonical
+   form remains unchanged for all RR types whose whose initial
+   publication as an RFC was prior to the initial publication of this
+   specification as an RFC (RFC 3597).
+
+   As a courtesy to implementors, it is hereby noted that the complete
+   set of such previously published RR types that contain embedded
+   domain names, and whose DNSSEC canonical form therefore involves
+   downcasing according to the DNS rules for character comparisons,
+   consists of the RR types NS, MD, MF, CNAME, SOA, MB, MG, MR, PTR,
+   HINFO, MINFO, MX, HINFO, RP, AFSDB, RT, SIG, PX, NXT, NAPTR, KX, SRV,
+   DNAME, and A6.
+
+   This document specifies that for all other RR types (whether treated
+   as unknown types or treated as known types according to an RR type
+   definition RFC more recent than RFC 3597), the canonical form is such
+   that no downcasing of embedded domain names takes place, and
+   otherwise identical to the canonical form specified in [RFC2535]
+   section 8.1.
+
+   Note that the owner name is always set to lower case according to the
+   DNS rules for character comparisons, regardless of the RR type.
+
+   The DNSSEC canonical RR ordering is as specified in [RFC2535] section
+   8.3, where the octet sequence is the canonical form as revised by
+   this specification.
+
+8.  Additional Section Processing
+
+   Unknown RR types cause no additional section processing.  Future RR
+   type specifications MAY specify type-specific additional section
+   processing rules, but any such processing MUST be optional as it can
+   only be performed by servers for which the RR type in case is known.
+
+
+
+Gustafsson                  Standards Track                     [Page 5]
+
+RFC 3597            Handling of Unknown DNS RR Types      September 2003
+
+
+9.  IANA Considerations
+
+   This document does not require any IANA actions.
+
+10.  Security Considerations
+
+   This specification is not believed to cause any new security
+   problems, nor to solve any existing ones.
+
+11.  Normative References
+
+   [RFC1034]   Mockapetris, P., "Domain Names - Concepts and
+               Facilities", STD 13, RFC 1034, November 1987.
+
+   [RFC1035]   Mockapetris, P., "Domain Names - Implementation and
+               Specifications", STD 13, RFC 1035, November 1987.
+
+   [RFC1123]   Braden, R., Ed., "Requirements for Internet Hosts --
+               Application and Support", STD 3, RFC 1123, October 1989.
+
+   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
+               Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2535]   Eastlake, D., "Domain Name System Security Extensions",
+               RFC 2535, March 1999.
+
+   [RFC2163]   Allocchio, C., "Using the Internet DNS to Distribute
+               MIXER Conformant Global Address Mapping (MCGAM)", RFC
+               2163, January 1998.
+
+   [RFC2929]   Eastlake, D., Brunner-Williams, E. and B. Manning,
+               "Domain Name System (DNS) IANA Considerations", BCP 42,
+               RFC 2929, September 2000.
+
+12.  Informative References
+
+   [RFC1876]   Davis, C., Vixie, P., Goodwin, T. and I. Dickinson, "A
+               Means for Expressing Location Information in the Domain
+               Name System", RFC 1876, January 1996.
+
+   [RFC2052]   Gulbrandsen, A. and P. Vixie, "A DNS RR for specifying
+               the location of services (DNS SRV)", RFC 2052, October
+               1996.
+
+   [RFC2136]   Vixie, P., Ed., Thomson, S., Rekhter, Y. and J. Bound,
+               "Dynamic Updates in the Domain Name System (DNS UPDATE)",
+               RFC 2136, April 1997.
+
+
+
+
+Gustafsson                  Standards Track                     [Page 6]
+
+RFC 3597            Handling of Unknown DNS RR Types      September 2003
+
+
+   [RFC2782]   Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for
+               specifying the location of services (DNS SRV)", RFC 2782,
+               February 2000.
+
+13.  Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   intellectual property or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; neither does it represent that it
+   has made any effort to identify any such rights.  Information on the
+   IETF's procedures with respect to rights in standards-track and
+   standards-related documentation can be found in BCP-11.  Copies of
+   claims of rights made available for publication and any assurances of
+   licenses to be made available, or the result of an attempt made to
+   obtain a general license or permission for the use of such
+   proprietary rights by implementors or users of this specification can
+   be obtained from the IETF Secretariat.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights which may cover technology that may be required to practice
+   this standard.  Please address the information to the IETF Executive
+   Director.
+
+14.  Author's Address
+
+   Andreas Gustafsson
+   Nominum, Inc.
+   2385 Bay Rd
+   Redwood City, CA 94063
+   USA
+
+   Phone: +1 650 381 6004
+   EMail: gson@nominum.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gustafsson                  Standards Track                     [Page 7]
+
+RFC 3597            Handling of Unknown DNS RR Types      September 2003
+
+
+15.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2003).  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 Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assignees.
+
+   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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gustafsson                  Standards Track                     [Page 8]
+
diff --git a/doc/rfc/rfc3645.txt b/doc/rfc/rfc3645.txt
new file mode 100644
index 0000000..6126678
--- /dev/null
+++ b/doc/rfc/rfc3645.txt
@@ -0,0 +1,1459 @@
+
+
+
+
+
+
+Network Working Group                                            S. Kwan
+Request for Comments: 3645                                       P. Garg
+Updates: 2845                                                  J. Gilroy
+Category: Standards Track                                      L. Esibov
+                                                             J. Westhead
+                                                         Microsoft Corp.
+                                                                 R. Hall
+                                                     Lucent Technologies
+                                                            October 2003
+
+
+                 Generic Security Service Algorithm for
+        Secret Key Transaction Authentication for DNS (GSS-TSIG)
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2003).  All Rights Reserved.
+
+Abstract
+
+   The Secret Key Transaction Authentication for DNS (TSIG) protocol
+   provides transaction level authentication for DNS.  TSIG is
+   extensible through the definition of new algorithms.  This document
+   specifies an algorithm based on the Generic Security Service
+   Application Program Interface (GSS-API) (RFC2743).  This document
+   updates RFC 2845.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kwan, et al.                Standards Track                     [Page 1]
+
+RFC 3645                        GSS-TSIG                    October 2003
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
+   2.  Algorithm Overview . . . . . . . . . . . . . . . . . . . . . .  3
+       2.1.  GSS Details. . . . . . . . . . . . . . . . . . . . . . .  4
+       2.2.  Modifications to the TSIG protocol (RFC 2845). . . . . .  4
+   3.  Client Protocol Details. . . . . . . . . . . . . . . . . . . .  5
+       3.1.  Negotiating Context. . . . . . . . . . . . . . . . . . .  5
+           3.1.1.  Call GSS_Init_sec_context. . . . . . . . . . . . .  6
+           3.1.2.  Send TKEY Query to Server. . . . . . . . . . . . .  8
+           3.1.3.  Receive TKEY Query-Response from Server. . . . . .  8
+       3.2.  Context Established. . . . . . . . . . . . . . . . . . . 11
+           3.2.1.  Terminating a Context. . . . . . . . . . . . . . . 11
+   4.  Server Protocol Details. . . . . . . . . . . . . . . . . . . . 12
+       4.1.  Negotiating Context. . . . . . . . . . . . . . . . . . . 12
+           4.1.1.  Receive TKEY Query from Client . . . . . . . . . . 12
+           4.1.2.  Call GSS_Accept_sec_context. . . . . . . . . . . . 12
+           4.1.3.  Send TKEY Query-Response to Client . . . . . . . . 13
+       4.2.  Context Established. . . . . . . . . . . . . . . . . . . 15
+           4.2.1.  Terminating a Context. . . . . . . . . . . . . . . 15
+   5.  Sending and Verifying Signed Messages. . . . . . . . . . . . . 15
+       5.1.  Sending a Signed Message - Call GSS_GetMIC . . . . . . . 15
+       5.2.  Verifying a Signed Message - Call GSS_VerifyMIC. . . . . 16
+   6.  Example usage of GSS-TSIG algorithm. . . . . . . . . . . . . . 18
+   7.  Security Considerations. . . . . . . . . . . . . . . . . . . . 22
+   8.  IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 22
+   9.  Conformance. . . . . . . . . . . . . . . . . . . . . . . . . . 22
+   10. Intellectual Property Statement. . . . . . . . . . . . . . . . 23
+   11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23
+   12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
+       12.1.  Normative References. . . . . . . . . . . . . . . . . . 24
+       12.2.  Informative References. . . . . . . . . . . . . . . . . 24
+   13. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 25
+   14. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 26
+
+1.  Introduction
+
+   The Secret Key Transaction Authentication for DNS (TSIG) [RFC2845]
+   protocol was developed to provide a lightweight authentication and
+   integrity of messages between two DNS entities, such as client and
+   server or server and server.  TSIG can be used to protect dynamic
+   update messages, authenticate regular message or to off-load
+   complicated DNSSEC [RFC2535] processing from a client to a server and
+   still allow the client to be assured of the integrity of the answers.
+
+
+
+
+
+
+
+Kwan, et al.                Standards Track                     [Page 2]
+
+RFC 3645                        GSS-TSIG                    October 2003
+
+
+   The TSIG protocol [RFC2845] is extensible through the definition of
+   new algorithms.  This document specifies an algorithm based on the
+   Generic Security Service Application Program Interface (GSS-API)
+   [RFC2743].  GSS-API is a framework that provides an abstraction of
+   security to the application protocol developer.  The security
+   services offered can include authentication, integrity, and
+   confidentiality.
+
+   The GSS-API framework has several benefits:
+
+   *  Mechanism and protocol independence.  The underlying mechanisms
+      that realize the security services can be negotiated on the fly
+      and varied over time.  For example, a client and server MAY use
+      Kerberos [RFC1964] for one transaction, whereas that same server
+      MAY use SPKM [RFC2025] with a different client.
+
+   *  The protocol developer is removed from the responsibility of
+      creating and managing a security infrastructure.  For example, the
+      developer does not need to create new key distribution or key
+      management systems.  Instead the developer relies on the security
+      service mechanism to manage this on its behalf.
+
+   The scope of this document is limited to the description of an
+   authentication mechanism only.  It does not discuss and/or propose an
+   authorization mechanism.  Readers that are unfamiliar with GSS-API
+   concepts are encouraged to read the characteristics and concepts
+   section of [RFC2743] before examining this protocol in detail.  It is
+   also assumed that the reader is familiar with [RFC2845], [RFC2930],
+   [RFC1034] and [RFC1035].
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT",
+   "RECOMMENDED", and "MAY" in this document are to be interpreted as
+   described in BCP 14, RFC 2119 [RFC2119].
+
+2.  Algorithm Overview
+
+   In GSS, client and server interact to create a "security context".
+   The security context can be used to create and verify transaction
+   signatures on messages between the two parties.  A unique security
+   context is required for each unique connection between client and
+   server.
+
+   Creating a security context involves a negotiation between client and
+   server.  Once a context has been established, it has a finite
+   lifetime for which it can be used to secure messages.  Thus there are
+   three states of a context associated with a connection:
+
+
+
+
+
+Kwan, et al.                Standards Track                     [Page 3]
+
+RFC 3645                        GSS-TSIG                    October 2003
+
+
+                              +----------+
+                              |          |
+                              V          |
+                      +---------------+  |
+                      | Uninitialized |  |
+                      |               |  |
+                      +---------------+  |
+                              |          |
+                              V          |
+                      +---------------+  |
+                      | Negotiating   |  |
+                      | Context       |  |
+                      +---------------+  |
+                              |          |
+                              V          |
+                      +---------------+  |
+                      | Context       |  |
+                      | Established   |  |
+                      +---------------+  |
+                              |          |
+                              +----------+
+
+   Every connection begins in the uninitialized state.
+
+2.1.  GSS Details
+
+   Client and server MUST be locally authenticated and have acquired
+   default credentials before using this protocol as specified in
+   Section 1.1.1 "Credentials" in RFC 2743 [RFC2743].
+
+   The GSS-TSIG algorithm consists of two stages:
+
+   I.  Establish security context.  The Client and Server use the
+       GSS_Init_sec_context and GSS_Accept_sec_context APIs to generate
+       the tokens that they pass to each other using [RFC2930] as a
+       transport mechanism.
+
+   II. Once the security context is established it is used to generate
+       and verify signatures using GSS_GetMIC and GSS_VerifyMIC APIs.
+       These signatures are exchanged by the Client and Server as a part
+       of the TSIG records exchanged in DNS messages sent between the
+       Client and Server, as described in [RFC2845].
+
+2.2.  Modifications to the TSIG protocol (RFC 2845)
+
+   Modification to RFC 2845 allows use of TSIG through signing server's
+   response in an explicitly specified place in multi message exchange
+   between two DNS entities even if client's request wasn't signed.
+
+
+
+Kwan, et al.                Standards Track                     [Page 4]
+
+RFC 3645                        GSS-TSIG                    October 2003
+
+
+   Specifically, Section 4.2 of RFC 2845 MUST be modified as follows:
+
+   Replace:
+      "The server MUST not generate a signed response to an unsigned
+      request."
+
+   With:
+      "The server MUST not generate a signed response to an unsigned
+      request, except in case of response to client's unsigned TKEY
+      query if secret key is established on server side after server
+      processed client's query.  Signing responses to unsigned TKEY
+      queries MUST be explicitly specified in the description of an
+      individual secret key establishment algorithm."
+
+3.  Client Protocol Details
+
+   A unique context is required for each server to which the client
+   sends secure messages.  A context is identified by a context handle.
+   A client maintains a mapping of servers to handles:
+
+      (target_name, key_name, context_handle)
+
+   The value key_name also identifies a context handle.  The key_name is
+   the owner name of the TKEY and TSIG records sent between a client and
+   a server to indicate to each other which context MUST be used to
+   process the current request.
+
+   DNS client and server MAY use various underlying security mechanisms
+   to establish security context as described in sections 3 and 4.  At
+   the same time, in order to guarantee interoperability between DNS
+   clients and servers that support GSS-TSIG it is REQUIRED that
+   security mechanism used by client enables use of Kerberos v5 (see
+   Section 9 for more information).
+
+3.1.  Negotiating Context
+
+   In GSS, establishing a security context involves the passing of
+   opaque tokens between the client and the server.  The client
+   generates the initial token and sends it to the server.  The server
+   processes the token and if necessary, returns a subsequent token to
+   the client.  The client processes this token, and so on, until the
+   negotiation is complete.  The number of times the client and server
+   exchange tokens depends on the underlying security mechanism.  A
+   completed negotiation results in a context handle.
+
+
+
+
+
+
+
+Kwan, et al.                Standards Track                     [Page 5]
+
+RFC 3645                        GSS-TSIG                    October 2003
+
+
+   The TKEY resource record [RFC2930] is used as the vehicle to transfer
+   tokens between client and server.  The TKEY record is a general
+   mechanism for establishing secret keys for use with TSIG.  For more
+   information, see [RFC2930].
+
+3.1.1.  Call GSS_Init_sec_context
+
+   To obtain the first token to be sent to a server, a client MUST call
+   GSS_Init_sec_context API.
+
+   The following input parameters MUST be used.  The outcome of the call
+   is indicated with the output values below.  Consult Sections 2.2.1,
+   "GSS_Init_sec_context call", of [RFC2743] for syntax definitions.
+
+   INPUTS
+     CREDENTIAL HANDLE claimant_cred_handle = NULL (NULL specifies "use
+         default").  Client MAY instead specify some other valid
+         handle to its credentials.
+     CONTEXT HANDLE input_context_handle  = 0
+     INTERNAL NAME  targ_name             = "DNS@<target_server_name>"
+     OBJECT IDENTIFIER mech_type          = Underlying security
+         mechanism chosen by implementers.  To guarantee
+         interoperability of the implementations of the GSS-TSIG
+         mechanism client MUST specify a valid underlying security
+         mechanism that enables use of Kerberos v5 (see Section 9 for
+         more information).
+     OCTET STRING   input_token           = NULL
+     BOOLEAN        replay_det_req_flag   = TRUE
+     BOOLEAN        mutual_req_flag       = TRUE
+     BOOLEAN        deleg_req_flag        = TRUE
+     BOOLEAN        sequence_req_flag     = TRUE
+     BOOLEAN        anon_req_flag         = FALSE
+     BOOLEAN        integ_req_flag        = TRUE
+     INTEGER        lifetime_req          = 0 (0 requests a default
+         value).  Client MAY instead specify another upper bound for the
+         lifetime of the context to be established in seconds.
+     OCTET STRING   chan_bindings         = Any valid channel bindings
+         as specified in Section 1.1.6 "Channel Bindings" in [RFC2743]
+
+   OUTPUTS
+     INTEGER        major_status
+     CONTEXT HANDLE output_context_handle
+     OCTET STRING   output_token
+     BOOLEAN        replay_det_state
+     BOOLEAN        mutual_state
+     INTEGER        minor_status
+     OBJECT IDENTIFIER mech_type
+     BOOLEAN        deleg_state
+
+
+
+Kwan, et al.                Standards Track                     [Page 6]
+
+RFC 3645                        GSS-TSIG                    October 2003
+
+
+     BOOLEAN        sequence_state
+     BOOLEAN        anon_state
+     BOOLEAN        trans_state
+     BOOLEAN        prot_ready_state
+     BOOLEAN        conf_avail
+     BOOLEAN        integ_avail
+     INTEGER        lifetime_rec
+
+   If returned major_status is set to one of the following errors:
+
+     GSS_S_DEFECTIVE_TOKEN
+     GSS_S_DEFECTIVE_CREDENTIAL
+     GSS_S_BAD_SIG (GSS_S_BAD_MIC)
+     GSS_S_NO_CRED
+     GSS_S_CREDENTIALS_EXPIRED
+     GSS_S_BAD_BINDINGS
+     GSS_S_OLD_TOKEN
+     GSS_S_DUPLICATE_TOKEN
+     GSS_S_NO_CONTEXT
+     GSS_S_BAD_NAMETYPE
+     GSS_S_BAD_NAME
+     GSS_S_BAD_MECH
+     GSS_S_FAILURE
+
+   then the client MUST abandon the algorithm and MUST NOT use the GSS-
+   TSIG algorithm to establish this security context.  This document
+   does not prescribe which other mechanism could be used to establish a
+   security context.  Next time when this client needs to establish
+   security context, the client MAY use GSS-TSIG algorithm.
+
+   Success values of major_status are GSS_S_CONTINUE_NEEDED and
+   GSS_S_COMPLETE.  The exact success code is important during later
+   processing.
+
+   The values of replay_det_state and mutual_state indicate if the
+   security package provides replay detection and mutual authentication,
+   respectively.  If returned major_status is GSS_S_COMPLETE AND one or
+   both of these values are FALSE, the client MUST abandon this
+   algorithm.
+
+   Client's behavior MAY depend on other OUTPUT parameters according to
+   the policy local to the client.
+
+   The handle output_context_handle is unique to this negotiation and is
+   stored in the client's mapping table as the context_handle that maps
+   to target_name.
+
+
+
+
+
+Kwan, et al.                Standards Track                     [Page 7]
+
+RFC 3645                        GSS-TSIG                    October 2003
+
+
+3.1.2.  Send TKEY Query to Server
+
+   An opaque output_token returned by GSS_Init_sec_context is
+   transmitted to the server in a query request with QTYPE=TKEY.  The
+   token itself will be placed in a Key Data field of the RDATA field in
+   the TKEY resource record in the additional records section of the
+   query.  The owner name of the TKEY resource record set queried for
+   and the owner name of the supplied TKEY resource record in the
+   additional records section MUST be the same.  This name uniquely
+   identifies the security context to both the client and server, and
+   thus the client SHOULD use a value which is globally unique as
+   described in [RFC2930].  To achieve global uniqueness, the name MAY
+   contain a UUID/GUID [ISO11578].
+
+      TKEY Record
+        NAME = client-generated globally unique domain name string
+               (as described in [RFC2930])
+        RDATA
+           Algorithm Name      = gss-tsig
+           Mode                = 3 (GSS-API negotiation - per [RFC2930])
+           Key Size            = size of output_token in octets
+           Key Data            = output_token
+
+   The remaining fields in the TKEY RDATA, i.e., Inception, Expiration,
+   Error, Other Size and Data Fields, MUST be set according to
+   [RFC2930].
+
+   The query is transmitted to the server.
+
+   Note: if the original client call to GSS_Init_sec_context returned
+   any major_status other than GSS_S_CONTINUE_NEEDED or GSS_S_COMPLETE,
+   then the client MUST NOT send TKEY query.  Client's behavior in this
+   case is described above in Section 3.1.1.
+
+3.1.3.  Receive TKEY Query-Response from Server
+
+   Upon the reception of the TKEY query the DNS server MUST respond
+   according to the description in Section 4.  This section specifies
+   the behavior of the client after it receives the matching response to
+   its query.
+
+   The next processing step depends on the value of major_status from
+   the most recent call that client performed to GSS_Init_sec_context:
+   either GSS_S_COMPLETE or GSS_S_CONTINUE.
+
+
+
+
+
+
+
+Kwan, et al.                Standards Track                     [Page 8]
+
+RFC 3645                        GSS-TSIG                    October 2003
+
+
+3.1.3.1.  Value of major_status == GSS_S_COMPLETE
+
+   If the last call to GSS_Init_sec_context yielded a major_status value
+   of GSS_S_COMPLETE and a non-NULL output_token was sent to the server,
+   then the client side component of the negotiation is complete and the
+   client is awaiting confirmation from the server.
+
+   Confirmation is in the form of a query response with RCODE=NOERROR
+   and with the last client supplied TKEY record in the answer section
+   of the query.  The response MUST be signed with a TSIG record.  Note
+   that the server is allowed to sign a response to unsigned client's
+   query due to modification to the RFC 2845 specified in Section 2.2
+   above.  The signature in the TSIG record MUST be verified using the
+   procedure detailed in section 5, Sending and Verifying Signed
+   Messages.  If the response is not signed, OR if the response is
+   signed but the signature is invalid, then an attacker has tampered
+   with the message in transit or has attempted to send the client a
+   false response.  In this case, the client MAY continue waiting for a
+   response to its last TKEY query until the time period since the
+   client sent last TKEY query expires.  Such a time period is specified
+   by the policy local to the client.  This is a new option that allows
+   the DNS client to accept multiple answers for one query ID and select
+   one (not necessarily the first one) based on some criteria.
+
+   If the signature is verified, the context state is advanced to
+   Context Established.  Proceed to section 3.2 for usage of the
+   security context.
+
+3.1.3.2.  Value of major_status == GSS_S_CONTINUE_NEEDED
+
+   If the last call to GSS_Init_sec_context yielded a major_status value
+   of GSS_S_CONTINUE_NEEDED, then the negotiation is not yet complete.
+   The server will return to the client a query response with a TKEY
+   record in the Answer section.  If the DNS message error is not
+   NO_ERROR or error field in the TKEY record is not 0 (i.e., no error),
+   then the client MUST abandon this negotiation sequence.  The client
+   MUST delete an active context by calling GSS_Delete_sec_context
+   providing the associated context_handle.  The client MAY repeat the
+   negotiation sequence starting with the uninitialized state as
+   described in section 3.1.  To prevent infinite looping the number of
+   attempts to establish a security context MUST be limited to ten or
+   less.
+
+   If the DNS message error is NO_ERROR and the error field in the TKEY
+   record is 0 (i.e., no error), then the client MUST pass a token
+   specified in the Key Data field in the TKEY resource record to
+
+
+
+
+
+Kwan, et al.                Standards Track                     [Page 9]
+
+RFC 3645                        GSS-TSIG                    October 2003
+
+
+   GSS_Init_sec_context using the same parameters values as in previous
+   call except values for CONTEXT HANDLE input_context_handle and OCTET
+   STRING input_token as described below:
+
+   INPUTS
+     CONTEXT HANDLE input_context_handle  = context_handle (this is the
+          context_handle corresponding to the key_name which is the
+          owner name of the TKEY record in the answer section in the
+          TKEY query response)
+
+     OCTET STRING   input_token           = token from Key field of
+                                            TKEY record
+
+   Depending on the following OUTPUT values of GSS_Init_sec_context
+
+        INTEGER        major_status
+        OCTET STRING   output_token
+
+   the client MUST take one of the following actions:
+
+   If OUTPUT major_status is set to one of the following values:
+
+        GSS_S_DEFECTIVE_TOKEN
+        GSS_S_DEFECTIVE_CREDENTIAL
+        GSS_S_BAD_SIG (GSS_S_BAD_MIC)
+        GSS_S_NO_CRED
+        GSS_S_CREDENTIALS_EXPIRED
+        GSS_S_BAD_BINDINGS
+        GSS_S_OLD_TOKEN
+        GSS_S_DUPLICATE_TOKEN
+        GSS_S_NO_CONTEXT
+        GSS_S_BAD_NAMETYPE
+        GSS_S_BAD_NAME
+        GSS_S_BAD_MECH
+        GSS_S_FAILURE
+
+   the client MUST abandon this negotiation sequence.  This means that
+   the client MUST delete an active context by calling
+   GSS_Delete_sec_context providing the associated context_handle.  The
+   client MAY repeat the negotiation sequence starting with the
+   uninitialized state as described in section 3.1.  To prevent infinite
+   looping the number of attempts to establish a security context MUST
+   be limited to ten or less.
+
+   If OUTPUT major_status is GSS_S_CONTINUE_NEEDED OR GSS_S_COMPLETE
+   then client MUST act as described below.
+
+
+
+
+
+Kwan, et al.                Standards Track                    [Page 10]
+
+RFC 3645                        GSS-TSIG                    October 2003
+
+
+   If the response from the server was signed, and the OUTPUT
+   major_status is GSS_S_COMPLETE,then the signature in the TSIG record
+   MUST be verified using the procedure detailed in section 5, Sending
+   and Verifying Signed Messages.  If the signature is invalid, then the
+   client MUST abandon this negotiation sequence.  This means that the
+   client MUST delete an active context by calling
+   GSS_Delete_sec_context providing the associated context_handle.  The
+   client MAY repeat the negotiation sequence starting with the
+   uninitialized state as described in section 3.1.  To prevent infinite
+   looping the number of attempts to establish a security context MUST
+   be limited to ten or less.
+
+   If major_status is GSS_S_CONTINUE_NEEDED the negotiation is not yet
+   finished.  The token output_token MUST be passed to the server in a
+   TKEY record by repeating the negotiation sequence beginning with
+   section 3.1.2.  The client MUST place a limit on the number of
+   continuations in a context negotiation to prevent endless looping.
+   Such limit SHOULD NOT exceed value of 10.
+
+   If major_status is GSS_S_COMPLETE and output_token is non-NULL, the
+   client-side component of the negotiation is complete but the token
+   output_token MUST be passed to the server by repeating the
+   negotiation sequence beginning with section 3.1.2.
+
+   If major_status is GSS_S_COMPLETE and output_token is NULL, context
+   negotiation is complete.  The context state is advanced to Context
+   Established.  Proceed to section 3.2 for usage of the security
+   context.
+
+3.2.  Context Established
+
+   When context negotiation is complete, the handle context_handle MUST
+   be used for the generation and verification of transaction
+   signatures.
+
+   The procedures for sending and receiving signed messages are
+   described in section 5, Sending and Verifying Signed Messages.
+
+3.2.1.  Terminating a Context
+
+   When the client is not intended to continue using the established
+   security context, the client SHOULD delete an active context by
+   calling GSS_Delete_sec_context providing the associated
+   context_handle, AND client SHOULD delete the established context on
+   the DNS server by using TKEY RR with the Mode field set to 5, i.e.,
+   "key deletion" [RFC2930].
+
+
+
+
+
+Kwan, et al.                Standards Track                    [Page 11]
+
+RFC 3645                        GSS-TSIG                    October 2003
+
+
+4.  Server Protocol Details
+
+   As on the client-side, the result of a successful context negotiation
+   is a context handle used in future generation and verification of the
+   transaction signatures.
+
+   A server MAY be managing several contexts with several clients.
+   Clients identify their contexts by providing a key name in their
+   request.  The server maintains a mapping of key names to handles:
+
+      (key_name, context_handle)
+
+4.1.  Negotiating Context
+
+   A server MUST recognize TKEY queries as security context negotiation
+   messages.
+
+4.1.1.  Receive TKEY Query from Client
+
+   Upon receiving a query with QTYPE = TKEY, the server MUST examine
+   whether the Mode and Algorithm Name fields of the TKEY record in the
+   additional records section of the message contain values of 3 and
+   gss-tsig, respectively.  If they do, then the (key_name,
+   context_handle) mapping table is searched for the key_name matching
+   the owner name of the TKEY record in the additional records section
+   of the query.  If the name is found in the table and the security
+   context for this name is established and not expired, then the server
+   MUST respond to the query with BADNAME error in the TKEY error field.
+   If the name is found in the table and the security context is not
+   established, the corresponding context_handle is used in subsequent
+   GSS operations.  If the name is found but the security context is
+   expired, then the server deletes this security context, as described
+   in Section 4.2.1, and interprets this query as a start of new
+   security context negotiation and performs operations described in
+   Section 4.1.2 and 4.1.3.  If the name is not found, then the server
+   interprets this query as a start of new security context negotiation
+   and performs operations described in Section 4.1.2 and 4.1.3.
+
+4.1.2.  Call GSS_Accept_sec_context
+
+   The server performs its side of a context negotiation by calling
+   GSS_Accept_sec_context.  The following input parameters MUST be used.
+   The outcome of the call is indicated with the output values below.
+   Consult Sections 2.2.2 "GSS_Accept_sec_context call" of the RFC 2743
+   [RFC2743] for syntax definitions.
+
+
+
+
+
+
+Kwan, et al.                Standards Track                    [Page 12]
+
+RFC 3645                        GSS-TSIG                    October 2003
+
+
+   INPUTS
+     CONTEXT HANDLE input_context_handle  = 0 if new negotiation,
+                                            context_handle matching
+                                         key_name if ongoing negotiation
+     OCTET STRING   input_token           = token specified in the Key
+           field from TKEY RR (from Additional records Section of
+           the client's query)
+
+     CREDENTIAL HANDLE acceptor_cred_handle = NULL (NULL specifies "use
+           default").  Server MAY instead specify some other valid
+           handle to its credentials.
+     OCTET STRING   chan_bindings          = Any valid channel bindings
+           as specified in Section 1.1.6 "Channel Bindings" in [RFC2743]
+
+   OUTPUTS
+     INTEGER        major_status
+     CONTEXT_HANDLE output_context_handle
+     OCTET STRING   output_token
+     INTEGER        minor_status
+     INTERNAL NAME  src_name
+     OBJECT IDENTIFIER  mech_type
+     BOOLEAN        deleg_state
+     BOOLEAN        mutual_state
+     BOOLEAN        replay_det_state
+     BOOLEAN        sequence_state
+     BOOLEAN        anon_state
+     BOOLEAN        trans_state
+     BOOLEAN        prot_ready_state
+     BOOLEAN        conf_avail
+     BOOLEAN        integ_avail
+     INTEGER        lifetime_rec
+     CONTEXT_HANDLE delegated_cred_handle
+
+   If this is the first call to GSS_Accept_sec_context in a new
+   negotiation, then output_context_handle is stored in the server's
+   key-mapping table as the context_handle that maps to the name of the
+   TKEY record.
+
+4.1.3.  Send TKEY Query-Response to Client
+
+   The server MUST respond to the client with a TKEY query response with
+   RCODE = NOERROR, that contains a TKEY record in the answer section.
+
+   If OUTPUT major_status is one of the following errors the error field
+   in the TKEY record set to BADKEY.
+
+
+
+
+
+
+Kwan, et al.                Standards Track                    [Page 13]
+
+RFC 3645                        GSS-TSIG                    October 2003
+
+
+        GSS_S_DEFECTIVE_TOKEN
+        GSS_S_DEFECTIVE_CREDENTIAL
+        GSS_S_BAD_SIG (GSS_S_BAD_MIC)
+        GSS_S_DUPLICATE_TOKEN
+        GSS_S_OLD_TOKEN
+        GSS_S_NO_CRED
+        GSS_S_CREDENTIALS_EXPIRED
+        GSS_S_BAD_BINDINGS
+        GSS_S_NO_CONTEXT
+        GSS_S_BAD_MECH
+        GSS_S_FAILURE
+
+   If OUTPUT major_status is set to  GSS_S_COMPLETE or
+   GSS_S_CONTINUE_NEEDED then server MUST act as described below.
+
+   If major_status is GSS_S_COMPLETE the server component of the
+   negotiation is finished.  If output_token is non-NULL, then it MUST
+   be returned to the client in a Key Data field of the RDATA in TKEY.
+   The error field in the TKEY record is set to NOERROR.  The message
+   MUST be signed with a TSIG record as described in section 5, Sending
+   and Verifying Signed Messages.  Note that server is allowed to sign a
+   response to unsigned client's query due to modification to the RFC
+   2845 specified in Section 2.2 above.  The context state is advanced
+   to Context Established.  Section 4.2 discusses the usage of the
+   security context.
+
+   If major_status is GSS_S_COMPLETE and output_token is NULL, then the
+   TKEY record received from the client MUST be returned in the Answer
+   section of the response.  The message MUST be signed with a TSIG
+   record as described in section 5, Sending and Verifying Signed
+   Messages.  Note that server is allowed to sign a response to unsigned
+   client's query due to modification to the RFC 2845 specified in
+   section 2.2 above.  The context state is advanced to Context
+   Established.  Section 4.2 discusses the usage of the security
+   context.
+
+   If major_status is GSS_S_CONTINUE_NEEDED, the server component of the
+   negotiation is not yet finished.  The server responds to the TKEY
+   query with a standard query response, placing in the answer section a
+   TKEY record containing output_token in the Key Data RDATA field.  The
+   error field in the TKEY record is set to NOERROR.  The server MUST
+   limit the number of times that a given context is allowed to repeat,
+   to prevent endless looping.  Such limit SHOULD NOT exceed value of
+   10.
+
+
+
+
+
+
+
+Kwan, et al.                Standards Track                    [Page 14]
+
+RFC 3645                        GSS-TSIG                    October 2003
+
+
+   In all cases, except if major_status is GSS_S_COMPLETE and
+   output_token is NULL, other TKEY record fields MUST contain the
+   following values:
+
+        NAME = key_name
+        RDATA
+           Algorithm Name      = gss-tsig
+           Mode                = 3 (GSS-API negotiation - per [RFC2930])
+           Key Size            = size of output_token in octets
+
+   The remaining fields in the TKEY RDATA, i.e., Inception, Expiration,
+   Error, Other Size and Data Fields, MUST be set according to
+   [RFC2930].
+
+4.2.  Context Established
+
+   When context negotiation is complete, the handle context_handle is
+   used for the generation and verification of transaction signatures.
+   The handle is valid for a finite amount of time determined by the
+   underlying security mechanism.  A server MAY unilaterally terminate a
+   context at any time (see section 4.2.1).
+
+   Server SHOULD limit the amount of memory used to cache established
+   contexts.
+
+   The procedures for sending and receiving signed messages are given in
+   section 5, Sending and Verifying Signed Messages.
+
+4.2.1.  Terminating a Context
+
+   A server can terminate any established context at any time.  The
+   server MAY hint to the client that the context is being deleted by
+   including a TKEY RR in a response with the Mode field set to 5, i.e.,
+   "key deletion" [RFC2930].  An active context is deleted by calling
+   GSS_Delete_sec_context providing the associated context_handle.
+
+5.  Sending and Verifying Signed Messages
+
+5.1.  Sending a Signed Message - Call GSS_GetMIC
+
+   The procedure for sending a signature-protected message is specified
+   in [RFC2845].  The data to be passed to the signature routine
+   includes the whole DNS message with specific TSIG variables appended.
+   For the exact format, see [RFC2845].  For this protocol, use the
+   following TSIG variable values:
+
+
+
+
+
+
+Kwan, et al.                Standards Track                    [Page 15]
+
+RFC 3645                        GSS-TSIG                    October 2003
+
+
+      TSIG Record
+        NAME = key_name that identifies this context
+        RDATA
+           Algorithm Name = gss-tsig
+
+   Assign the remaining fields in the TSIG RDATA appropriate values as
+   described in [RFC2845].
+
+   The signature is generated by calling GSS_GetMIC.  The following
+   input parameters MUST be used.  The outcome of the call is indicated
+   with the output values specified below.  Consult Sections 2.3.1
+   "GSS_GetMIC call" of the RFC 2743[RFC2743] for syntax definitions.
+
+   INPUTS
+     CONTEXT HANDLE context_handle = context_handle for key_name
+     OCTET STRING   message        = outgoing message plus TSIG
+                                     variables (per [RFC2845])
+     INTEGER qop_req               = 0 (0 requests a default
+         value).  Caller MAY instead specify other valid value (for
+         details see Section 1.2.4 in [RFC2743])
+
+   OUTPUTS
+     INTEGER        major_status
+     INTEGER        minor_status
+     OCTET STRING   per_msg_token
+
+   If major_status is GSS_S_COMPLETE, then signature generation
+   succeeded.  The signature in per_msg_token is inserted into the
+   Signature field of the TSIG RR and the message is transmitted.
+
+   If major_status is GSS_S_CONTEXT_EXPIRED, GSS_S_CREDENTIALS_EXPIRED
+   or GSS_S_FAILURE the caller MUST delete the security context, return
+   to the uninitialized state and SHOULD negotiate a new security
+   context, as described above in Section 3.1
+
+   If major_status is GSS_S_NO_CONTEXT, the caller MUST remove the entry
+   for key_name from the (target_ name, key_name, context_handle)
+   mapping table, return to the uninitialized state and SHOULD negotiate
+   a new security context, as described above in Section 3.1
+
+   If major_status is GSS_S_BAD_QOP, the caller SHOULD repeat the
+   GSS_GetMIC call with allowed QOP value.  The number of such
+   repetitions MUST be limited to prevent infinite loops.
+
+5.2.  Verifying a Signed Message - Call GSS_VerifyMIC
+
+   The procedure for verifying a signature-protected message is
+   specified in [RFC2845].
+
+
+
+Kwan, et al.                Standards Track                    [Page 16]
+
+RFC 3645                        GSS-TSIG                    October 2003
+
+
+   The NAME of the TSIG record determines which context_handle maps to
+   the context that MUST be used to verify the signature.  If the NAME
+   does not map to an established context, the server MUST send a
+   standard TSIG error response to the client indicating BADKEY in the
+   TSIG error field (as described in [RFC2845]).
+
+   For the GSS algorithm, a signature is verified by using
+   GSS_VerifyMIC:
+
+   INPUTS
+     CONTEXT HANDLE context_handle = context_handle for key_name
+     OCTET STRING   message        = incoming message plus TSIG
+                                     variables (per [RFC2845])
+     OCTET STRING   per_msg_token  = Signature field from TSIG RR
+
+   OUTPUTS
+     INTEGER        major_status
+     INTEGER        minor_status
+     INTEGER        qop_state
+
+   If major_status is GSS_S_COMPLETE, the signature is authentic and the
+   message was delivered intact.  Per [RFC2845], the timer values of the
+   TSIG record MUST also be valid before considering the message to be
+   authentic.  The caller MUST not act on the request or response in the
+   message until these checks are verified.
+
+   When a server is processing a client request, the server MUST send a
+   standard TSIG error response to the client indicating BADKEY in the
+   TSIG error field as described in [RFC2845], if major_status is set to
+   one of the following values
+
+        GSS_S_DEFECTIVE_TOKEN
+        GSS_S_BAD_SIG (GSS_S_BAD_MIC)
+        GSS_S_DUPLICATE_TOKEN
+        GSS_S_OLD_TOKEN
+        GSS_S_UNSEQ_TOKEN
+        GSS_S_GAP_TOKEN
+        GSS_S_CONTEXT_EXPIRED
+        GSS_S_NO_CONTEXT
+        GSS_S_FAILURE
+
+   If the timer values of the TSIG record are invalid, the message MUST
+   NOT be considered authentic.  If this error checking fails when a
+   server is processing a client request, the appropriate error response
+   MUST be sent to the client according to [RFC2845].
+
+
+
+
+
+
+Kwan, et al.                Standards Track                    [Page 17]
+
+RFC 3645                        GSS-TSIG                    October 2003
+
+
+6.  Example usage of GSS-TSIG algorithm
+
+   This Section describes an example where a Client, client.example.com,
+   and a Server, server.example.com, establish a security context
+   according to the algorithm described above.
+
+  I.  Client initializes security context negotiation
+
+  To establish a security context with a server, server.example.com, the
+  Client calls GSS_Init_sec_context with the following parameters.
+  (Note that some INPUT and OUTPUT parameters not critical for this
+  algorithm are not described in this example.)
+
+     CONTEXT HANDLE input_context_handle  = 0
+     INTERNAL NAME  targ_name             = "DNS@server.example.com"
+     OCTET STRING   input_token           = NULL
+     BOOLEAN        replay_det_req_flag   = TRUE
+     BOOLEAN        mutual_req_flag       = TRUE
+
+  The OUTPUTS parameters returned by GSS_Init_sec_context include
+     INTEGER        major_status = GSS_S_CONTINUE_NEEDED
+     CONTEXT HANDLE output_context_handle context_handle
+     OCTET STRING   output_token output_token
+     BOOLEAN        replay_det_state = TRUE
+     BOOLEAN        mutual_state = TRUE
+
+  Client verifies that replay_det_state and mutual_state values are
+  TRUE.  Since the major_status is GSS_S_CONTINUE_NEEDED, which is a
+  success OUTPUT major_status value, client stores context_handle that
+  maps to "DNS@server.example.com" and proceeds to the next step.
+
+  II.  Client sends a query with QTYPE = TKEY to server
+
+  Client sends a query with QTYPE = TKEY for a client-generated globally
+  unique domain name string, 789.client.example.com.server.example.com.
+  Query contains a TKEY record in its Additional records section with
+  the following fields.  (Note that some fields not specific to this
+  algorithm are not specified.)
+
+     NAME = 789.client.example.com.server.example.com.
+     RDATA
+        Algorithm Name      = gss-tsig
+        Mode                = 3 (GSS-API negotiation - per [RFC2930])
+        Key Size            = size of output_token in octets
+        Key Data            = output_token
+
+
+
+
+
+
+Kwan, et al.                Standards Track                    [Page 18]
+
+RFC 3645                        GSS-TSIG                    October 2003
+
+
+  After the key_name 789.client.example.com.server.example.com.
+  is generated it is stored in the client's (target_name, key_name,
+  context_handle) mapping table.
+
+  III.  Server receives a query with QTYPE = TKEY
+
+  When server receives a query with QTYPE = TKEY, the server verifies
+  that Mode and Algorithm fields in the TKEY record in the Additional
+  records section of the query are set to 3 and "gss-tsig" respectively.
+  It finds that the key_name 789.client.example.com.server.example.com.
+  is not listed in its (key_name, context_handle) mapping table.
+
+  IV.  Server calls GSS_Accept_sec_context
+
+  To continue security context negotiation server calls
+  GSS_Accept_sec_context with the following parameters.  (Note that
+  some INPUT and OUTPUT parameters not critical for this algorithm
+  are not described in this example.)
+
+   INPUTS
+     CONTEXT HANDLE input_context_handle  = 0
+     OCTET STRING   input_token           = token specified in the Key
+                              field from TKEY RR (from Additional
+                              records section of the client's query)
+
+  The OUTPUTS parameters returned by GSS_Accept_sec_context include
+     INTEGER        major_status = GSS_S_CONTINUE_NEEDED
+     CONTEXT_HANDLE output_context_handle context_handle
+     OCTET STRING   output_token output_token
+
+  Server stores the mapping of the
+  789.client.example.com.server.example.com. to OUTPUT context_handle
+  in its (key_name, context_handle) mapping table.
+
+  V.  Server responds to the TKEY query
+
+  Since the major_status = GSS_S_CONTINUE_NEEDED in the last server's
+  call to GSS_Accept_sec_context, the server responds to the TKEY query
+  placing in the answer section a TKEY record containing output_token in
+  the Key Data RDATA field.  The error field in the TKEY record is set
+  to 0.  The RCODE in the query response is set to NOERROR.
+
+  VI.  Client processes token returned by server
+
+  When the client receives the TKEY query response from the server, the
+  client calls GSS_Init_sec_context with the following parameters.
+  (Note that some INPUT and OUTPUT parameters not critical for this
+  algorithm are not described in this example.)
+
+
+
+Kwan, et al.                Standards Track                    [Page 19]
+
+RFC 3645                        GSS-TSIG                    October 2003
+
+
+     CONTEXT HANDLE input_context_handle  = the context_handle stored
+          in the client's mapping table entry (DNS@server.example.com.,
+          789.client.example.com.server.example.com., context_handle)
+     INTERNAL NAME  targ_name             = "DNS@server.example.com"
+     OCTET STRING   input_token           = token from Key field of TKEY
+          record from the Answer section of the server's response
+     BOOLEAN        replay_det_req_flag   = TRUE
+     BOOLEAN        mutual_req_flag       = TRUE
+
+  The OUTPUTS parameters returned by GSS_Init_sec_context include
+     INTEGER        major_status = GSS_S_COMPLETE
+     CONTEXT HANDLE output_context_handle = context_handle
+     OCTET STRING   output_token = output_token
+     BOOLEAN        replay_det_state = TRUE
+     BOOLEAN        mutual_state = TRUE
+
+  Since the major_status is set to GSS_S_COMPLETE the client side
+  security context is established, but since the output_token is not
+  NULL client MUST send a TKEY query to the server as described below.
+
+  VII.  Client sends a query with QTYPE = TKEY to server
+
+  Client sends to the server a TKEY query for the
+  789.client.example.com.server.example.com. name.  Query contains a
+  TKEY record in its Additional records section with the following
+  fields.  (Note that some INPUT and OUTPUT parameters not critical to
+  this algorithm are not described in this example.)
+
+     NAME = 789.client.example.com.server.example.com.
+     RDATA
+        Algorithm Name      = gss-tsig
+        Mode                = 3 (GSS-API negotiation - per [RFC2930])
+        Key Size            = size of output_token in octets
+        Key Data            = output_token
+
+  VIII.  Server receives a TKEY query
+
+  When the server receives a TKEY query, the server verifies that Mode
+  and Algorithm fields in the TKEY record in the Additional records
+  section of the query are set to 3 and gss-tsig, respectively.  It
+  finds that the key_name 789.client.example.com.server.example.com. is
+  listed in its (key_name, context_handle) mapping table.
+
+
+
+
+
+
+
+
+
+Kwan, et al.                Standards Track                    [Page 20]
+
+RFC 3645                        GSS-TSIG                    October 2003
+
+
+  IX.  Server calls GSS_Accept_sec_context
+
+  To continue security context negotiation server calls
+  GSS_Accept_sec_context with the following parameters (Note that some
+  INPUT and OUTPUT parameters not critical for this algorithm are not
+  described in this example)
+
+   INPUTS
+     CONTEXT HANDLE input_context_handle  = context_handle from the
+           (789.client.example.com.server.example.com., context_handle)
+           entry in the server's mapping table
+     OCTET STRING   input_token           = token specified in the Key
+           field of TKEY RR (from Additional records Section of
+           the client's query)
+
+  The OUTPUTS parameters returned by GSS_Accept_sec_context include
+     INTEGER        major_status = GSS_S_COMPLETE
+     CONTEXT_HANDLE output_context_handle = context_handle
+     OCTET STRING   output_token = NULL
+
+  Since major_status = GSS_S_COMPLETE, the security context on the
+  server side is established, but the server still needs to respond to
+  the client's TKEY query, as described below.  The security context
+  state is advanced to Context Established.
+
+  X.  Server responds to the TKEY query
+
+  Since the major_status = GSS_S_COMPLETE in the last server's call to
+  GSS_Accept_sec_context and the output_token is NULL, the server
+  responds to the TKEY query placing in the answer section a TKEY record
+  that was sent by the client in the Additional records section of the
+  client's latest TKEY query.  In addition, this server places a
+  TSIG record in additional records section of its response.  Server
+  calls GSS_GetMIC to generate a signature to include it in the TSIG
+  record.  The server specifies the following GSS_GetMIC INPUT
+  parameters:
+
+     CONTEXT HANDLE context_handle = context_handle from the
+           (789.client.example.com.server.example.com., context_handle)
+           entry in the server's mapping table
+     OCTET STRING   message        = outgoing message plus TSIG
+                                   variables (as described in [RFC2845])
+
+  The OUTPUTS parameters returned by GSS_GetMIC include
+     INTEGER        major_status = GSS_S_COMPLETE
+     OCTET STRING   per_msg_token
+
+  Signature field in the TSIG record is set to per_msg_token.
+
+
+
+Kwan, et al.                Standards Track                    [Page 21]
+
+RFC 3645                        GSS-TSIG                    October 2003
+
+
+  XI.  Client processes token returned by server
+
+  Client receives the TKEY query response from the server.  Since the
+  major_status was GSS_S_COMPLETE in the last client's call to
+  GSS_Init_sec_context, the client verifies that the server's response
+  is signed.  To validate the signature, the client calls
+  GSS_VerifyMIC with the following parameters:
+
+   INPUTS
+     CONTEXT HANDLE context_handle = context_handle for
+                  789.client.example.com.server.example.com. key_name
+     OCTET STRING   message        = incoming message plus TSIG
+                                  variables (as described in [RFC2845])
+     OCTET STRING   per_msg_token  = Signature field from TSIG RR
+                  included in the server's query response
+
+  Since the OUTPUTS parameter major_status = GSS_S_COMPLETE, the
+  signature is validated, security negotiation is complete and the
+  security context state is advanced to Context Established.  These
+  client and server will use the established security context to sign
+  and validate the signatures when they exchange packets with each
+  other until the context expires.
+
+7.  Security Considerations
+
+   This document describes a protocol for DNS security using GSS-API.
+   The security provided by this protocol is only as effective as the
+   security provided by the underlying GSS mechanisms.
+
+   All the security considerations from RFC 2845, RFC 2930 and RFC 2743
+   apply to the protocol described in this document.
+
+8.  IANA Considerations
+
+   The IANA has reserved the TSIG Algorithm name gss-tsig for the use in
+   the Algorithm fields of TKEY and TSIG resource records.  This
+   Algorithm name refers to the algorithm described in this document.
+   The requirement to have this name registered with IANA is specified
+   in RFC 2845.
+
+9.  Conformance
+
+   The GSS API using SPNEGO [RFC2478] provides maximum flexibility to
+   choose the underlying security mechanisms that enables security
+   context negotiation.  GSS API using SPNEGO [RFC2478] enables client
+   and server to negotiate and choose such underlying security
+   mechanisms on the fly.  To support such flexibility, DNS clients and
+   servers SHOULD specify SPNEGO mech_type in their GSS API calls.  At
+
+
+
+Kwan, et al.                Standards Track                    [Page 22]
+
+RFC 3645                        GSS-TSIG                    October 2003
+
+
+   the same time, in order to guarantee interoperability between DNS
+   clients and servers that support GSS-TSIG it is required that
+
+   -  DNS servers specify SPNEGO mech_type
+   -  GSS APIs called by DNS client support Kerberos v5
+   -  GSS APIs called by DNS server support SPNEGO [RFC2478] and
+      Kerberos v5.
+
+   In addition to these, GSS APIs used by DNS client and server MAY also
+   support other underlying security mechanisms.
+
+10.  Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   intellectual property or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; neither does it represent that it
+   has made any effort to identify any such rights.  Information on the
+   IETF's procedures with respect to rights in standards-track and
+   standards-related documentation can be found in BCP-11.  Copies of
+   claims of rights made available for publication and any assurances of
+   licenses to be made available, or the result of an attempt made to
+   obtain a general license or permission for the use of such
+   proprietary rights by implementors or users of this specification can
+   be obtained from the IETF Secretariat.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights which may cover technology that may be required to practice
+   this standard.  Please address the information to the IETF Executive
+   Director.
+
+11.  Acknowledgements
+
+   The authors of this document would like to thank the following people
+   for their contribution to this specification:  Chuck Chan, Mike
+   Swift, Ram Viswanathan, Olafur Gudmundsson, Donald E. Eastlake, 3rd
+   and Erik Nordmark.
+
+
+
+
+
+
+
+
+
+
+
+
+Kwan, et al.                Standards Track                    [Page 23]
+
+RFC 3645                        GSS-TSIG                    October 2003
+
+
+12.  References
+
+12.1.  Normative References
+
+   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+             Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2478] Baize, E. and D. Pinkas, "The Simple and Protected GSS-API
+             Negotiation Mechanism", RFC 2478, December 1998.
+
+   [RFC2743] Linn, J., "Generic Security Service Application Program
+             Interface, Version 2 , Update 1", RFC 2743, January 2000.
+
+   [RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D. and B.
+             Wellington, "Secret Key Transaction Authentication for DNS
+             (TSIG)", RFC 2845, May 2000.
+
+   [RFC2930] Eastlake 3rd, D., "Secret Key Establishment for DNS (TKEY
+             RR)", RFC 2930, September 2000.
+
+12.2.  Informative References
+
+
+   [ISO11578] "Information technology", "Open Systems Interconnection",
+              "Remote Procedure Call", ISO/IEC 11578:1996,
+              http://www.iso.ch/cate/d2229.html.
+
+   [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
+             STD 13, RFC 1034, November 1987.
+
+   [RFC1035] Mockapetris, P., "Domain Names - Implementation and
+             Specification", STD 13, RFC 1034, November 1987.
+
+   [RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC
+             1964, June 1996.
+
+   [RFC2025] Adams, C., "The Simple Public-Key GSS-API Mechanism
+             (SPKM)", RFC 2025, October 1996.
+
+   [RFC2137] Eastlake 3rd, D., "Secure Domain Name System Dynamic
+             Update", RFC 2137, April 1997.
+
+   [RFC2535] Eastlake 3rd, D., "Domain Name System Security Extensions",
+             RFC 2535, March 1999.
+
+
+
+
+
+
+
+Kwan, et al.                Standards Track                    [Page 24]
+
+RFC 3645                        GSS-TSIG                    October 2003
+
+
+13.  Authors' Addresses
+
+   Stuart Kwan
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   USA
+   EMail: skwan@microsoft.com
+
+   Praerit Garg
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   USA
+   EMail: praeritg@microsoft.com
+
+   James Gilroy
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   USA
+   EMail: jamesg@microsoft.com
+
+   Levon Esibov
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   USA
+   EMail: levone@microsoft.com
+
+   Randy Hall
+   Lucent Technologies
+   400 Lapp Road
+   Malvern PA 19355
+   USA
+   EMail: randyhall@lucent.com
+
+   Jeff Westhead
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   USA
+   EMail: jwesth@microsoft.com
+
+
+
+
+
+
+
+
+Kwan, et al.                Standards Track                    [Page 25]
+
+RFC 3645                        GSS-TSIG                    October 2003
+
+
+14.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2003).  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 Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assignees.
+
+   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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kwan, et al.                Standards Track                    [Page 26]
+
diff --git a/doc/rfc/rfc3655.txt b/doc/rfc/rfc3655.txt
new file mode 100644
index 0000000..13e586b
--- /dev/null
+++ b/doc/rfc/rfc3655.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+Network Working Group                                      B. Wellington
+Request for Comments: 3655                                O. Gudmundsson
+Updates: 2535                                              November 2003
+Category: Standards Track
+
+
+            Redefinition of DNS Authenticated Data (AD) bit
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2003).  All Rights Reserved.
+
+Abstract
+
+   This document alters the specification defined in RFC 2535.  Based on
+   implementation experience, the Authenticated Data (AD) bit in the DNS
+   header is not useful.  This document redefines the AD bit such that
+   it is only set if all answers or records proving that no answers
+   exist in the response has been cryptographically verified or
+   otherwise meets the server's local security policy.
+
+1.  Introduction
+
+   Familiarity with the DNS system [RFC1035] and DNS security extensions
+   [RFC2535] is helpful but not necessary.
+
+   As specified in RFC 2535 (section 6.1), the AD (Authenticated Data)
+   bit indicates in a response that all data included in the answer and
+   authority sections of the response have been authenticated by the
+   server according to the policies of that server.  This is not
+   especially useful in practice, since a conformant server SHOULD never
+   reply with data that failed its security policy.
+
+   This document redefines the AD bit such that it is only set if all
+   data in the response has been cryptographically verified or otherwise
+   meets the server's local security policy.  Thus, neither a response
+   containing properly delegated insecure data, nor a server configured
+   without DNSSEC keys, will have the AD set.  As before, data that
+   failed to verify will not be returned.  An application running on a
+   host that has a trust relationship with the server performing the
+
+
+
+Wellington & Gudmundsson    Standards Track                     [Page 1]
+
+RFC 3655               Redefinition of DNS AD bit          November 2003
+
+
+   recursive query can now use the value of the AD bit to determine
+   whether the data is secure.
+
+1.1.  Motivation
+
+   A full DNSSEC capable resolver called directly from an application
+   can return to the application the security status of the RRsets in
+   the answer.  However, most applications use a limited stub resolver
+   that relies on an external recursive name server which incorporates a
+   full resolver.  The recursive nameserver can use the AD bit in a
+   response to indicate the security status of the data in the answer,
+   and the local resolver can pass this information to the application.
+   The application in this context can be either a human using a DNS
+   tool or a software application.
+
+   The AD bit SHOULD be used by the local resolver if and only if it has
+   been explicitly configured to trust the remote resolver.  The AD bit
+   SHOULD be ignored when the recursive name server is not trusted.
+
+   An alternate solution would be to embed a full DNSSEC resolver into
+   every application, but this has several disadvantages.
+
+   -  DNSSEC validation is both CPU and network intensive, and caching
+      SHOULD be used whenever possible.
+
+   -  DNSSEC requires non-trivial configuration - the root key must be
+      configured, as well as keys for any "islands of security" that
+      will exist until DNSSEC is fully deployed.  The number of
+      configuration points should be minimized.
+
+1.2.  Requirements
+
+   The key words "MAY", "MAY NOT" "MUST", "MUST NOT", "SHOULD", "SHOULD
+   NOT", "RECOMMENDED", in this document are to be interpreted as
+   described in BCP 14, RFC 2119 [RFC2119].
+
+1.3.  Updated documents and sections
+
+   The definition of the AD bit in RFC 2535, Section 6.1, is changed.
+
+2.  Setting of AD bit
+
+   The presence of the CD (Checking Disabled) bit in a query does not
+   affect the setting of the AD bit in the response.  If the CD bit is
+   set, the server will not perform checking, but SHOULD still set the
+   AD bit if the data has already been cryptographically verified or
+
+
+
+
+
+Wellington & Gudmundsson    Standards Track                     [Page 2]
+
+RFC 3655               Redefinition of DNS AD bit          November 2003
+
+
+   complies with local policy.  The AD bit MUST only be set if DNSSEC
+   records have been requested via the DO bit [RFC3225] and relevant SIG
+   records are returned.
+
+2.1.  Setting of AD bit by recursive servers
+
+   Section 6.1 of RFC 2535 says:
+
+   "The AD bit MUST NOT be set on a response unless all of the RRs in
+   the answer and authority sections of the response are either
+   Authenticated or Insecure."
+
+   The replacement text reads:
+
+   "The AD bit MUST NOT be set on a response unless all of the RRsets in
+   the answer and authority sections of the response are Authenticated."
+
+   "The AD bit SHOULD be set if and only if all RRs in the answer
+   section and any relevant negative response RRs in the authority
+   section are Authenticated."
+
+   A recursive DNS server following this modified specification will
+   only set the AD bit when it has cryptographically verified the data
+   in the answer.
+
+2.2.  Setting of AD bit by authoritative servers
+
+   A primary server for a secure zone MAY have the policy of treating
+   authoritative secure zones as Authenticated.  Secondary servers MAY
+   have the same policy, but SHOULD NOT consider zone data Authenticated
+   unless the zone was transferred securely and/or the data was
+   verified.  An authoritative server MUST only set the AD bit for
+   authoritative answers from a secure zone if it has been explicitly
+   configured to do so.  The default for this behavior SHOULD be off.
+
+   Note that having the AD bit clear on an authoritative answer is
+   normal and expected behavior.
+
+2.2.1.  Justification for setting AD bit w/o verifying data
+
+   The setting of the AD bit by authoritative servers affects only the
+   small set of resolvers that are configured to directly query and
+   trust authoritative servers.  This only affects servers that function
+   as both recursive and authoritative.  Iterative resolvers SHOULD
+   ignore the AD bit.
+
+   The cost of verifying all signatures on load by an authoritative
+   server can be high and increases the delay before it can begin
+
+
+
+Wellington & Gudmundsson    Standards Track                     [Page 3]
+
+RFC 3655               Redefinition of DNS AD bit          November 2003
+
+
+   answering queries.  Verifying signatures at query time is also
+   expensive and could lead to resolvers timing out on many queries
+   after the server reloads zones.
+
+   Organizations requiring that all DNS responses contain
+   cryptographically verified data will need to separate the
+   authoritative name server and signature verification functions, since
+   name servers are not required to validate signatures of data for
+   which they are authoritative.
+
+3.  Interpretation of the AD bit
+
+   A response containing data marked Insecure in the answer or authority
+   section MUST never have the AD bit set.  In this case, the resolver
+   SHOULD treat the data as Insecure whether or not SIG records are
+   present.
+
+   A resolver MUST NOT blindly trust the AD bit unless it communicates
+   with a recursive nameserver over a secure transport mechanism or
+   using a message authentication such as TSIG [RFC2845] or SIG(0)
+   [RFC2931] and is explicitly configured to trust this recursive name
+   server.
+
+4.  Applicability statement
+
+   The AD bit is intended to allow the transmission of the indication
+   that a resolver has verified the DNSSEC signatures accompanying the
+   records in the Answer and Authority section.  The AD bit MUST only be
+   trusted when the end consumer of the DNS data has confidence that the
+   intermediary resolver setting the AD bit is trustworthy.  This can
+   only be accomplished via an out of band mechanism such as:
+
+   -  Fiat: An organization that can dictate whether it is OK to trust
+      certain DNS servers.
+
+   -  Personal: Because of a personal relationship or the reputation of
+      a recursive nameserver operator, a DNS consumer can decide to
+      trust that recursive nameserver.
+
+   -  Knowledge: If a recursive nameserver operator posts the configured
+      policy of a recursive nameserver, a consumer can decide that
+      recursive nameserver is trustworthy.
+
+   In the absence of one or more of these factors AD bit from a
+   recursive name server SHOULD NOT be trusted.  For example, home users
+   frequently depend on their ISP to provide recursive DNS service; it
+
+
+
+
+
+Wellington & Gudmundsson    Standards Track                     [Page 4]
+
+RFC 3655               Redefinition of DNS AD bit          November 2003
+
+
+   is not advisable to trust these recursive nameservers.  A
+   roaming/traveling host SHOULD not use recursive DNS servers offered
+   by DHCP when looking up information where security status matters.
+
+   In the latter two cases, the end consumer must also completely trust
+   the path to the trusted recursive name servers, or a secure transport
+   must be employed to protect the traffic.
+
+   When faced with a situation where there are no satisfactory recursive
+   nameservers available, running one locally is RECOMMENDED.  This has
+   the advantage that it can be trusted, and the AD bit can still be
+   used to allow applications to use stub resolvers.
+
+5.  Security Considerations
+
+   This document redefines a bit in the DNS header.  If a resolver
+   trusts the value of the AD bit, it must be sure that the responder is
+   using the updated definition, which is any DNS server/resolver
+   supporting the DO bit [RFC3225].
+
+   Authoritative servers can be explicitly configured to set the AD bit
+   on answers without doing cryptographic checks.  This behavior MUST be
+   off by default.  The only affected resolvers are those that directly
+   query and trust the authoritative server, and this functionality
+   SHOULD only be used on servers that act both as authoritative and
+   recursive name servers.
+
+   Resolvers (full or stub) that blindly trust the AD bit without
+   knowing the security policy of the server generating the answer can
+   not be considered security aware.
+
+   A resolver MUST NOT blindly trust the AD bit unless it communicates
+   such as IPsec, or using message authentication such as TSIG [RFC2845]
+   or SIG(0) [RFC2931].  In addition, the resolver must have been
+   explicitly configured to trust this recursive name server.
+
+6.  IANA Considerations
+
+   None.
+
+7.  Internationalization Considerations
+
+   None.  This document does not change any textual data in any
+   protocol.
+
+
+
+
+
+
+
+Wellington & Gudmundsson    Standards Track                     [Page 5]
+
+RFC 3655               Redefinition of DNS AD bit          November 2003
+
+
+8.  Intellectual Property Rights Notice
+
+   The IETF takes no position regarding the validity or scope of any
+   intellectual property or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; neither does it represent that it
+   has made any effort to identify any such rights.  Information on the
+   IETF's procedures with respect to rights in standards-track and
+   standards-related documentation can be found in BCP-11.  Copies of
+   claims of rights made available for publication and any assurances of
+   licenses to be made available, or the result of an attempt made to
+   obtain a general license or permission for the use of such
+   proprietary rights by implementors or users of this specification can
+   be obtained from the IETF Secretariat.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights which may cover technology that may be required to practice
+   this standard.  Please address the information to the IETF Executive
+   Director.
+
+9.  Acknowledgments
+
+   The following people have provided input on this document: Robert
+   Elz, Andreas Gustafsson, Bob Halley, Steven Jacob, Erik Nordmark,
+   Edward Lewis, Jakob Schlyter, Roy Arends, Ted Lindgreen.
+
+10.  Normative References
+
+   [RFC1035] Mockapetris, P., "Domain Names - Implementation and
+             Specification", STD 13, RFC 1035, November 1987.
+
+   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+             Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC
+             2535, March 1999.
+
+   [RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D. and B.
+             Wellington, "Secret Key Transaction Authentication for DNS
+             (TSIG)", RFC 2845, May 2000.
+
+   [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures
+             (SIG(0))", RFC 2931, September 2000.
+
+   [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC
+             3225, December 2001.
+
+
+
+Wellington & Gudmundsson    Standards Track                     [Page 6]
+
+RFC 3655               Redefinition of DNS AD bit          November 2003
+
+
+11.  Authors' Addresses
+
+   Brian Wellington
+   Nominum Inc.
+   2385 Bay Road
+   Redwood City, CA, 94063
+   USA
+
+   EMail: Brian.Wellington@nominum.com
+
+
+   Olafur Gudmundsson
+   3821 Village Park Drive
+   Chevy Chase, MD, 20815
+   USA
+
+   EMail: ogud@ogud.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wellington & Gudmundsson    Standards Track                     [Page 7]
+
+RFC 3655               Redefinition of DNS AD bit          November 2003
+
+
+12.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2003).  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 Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assignees.
+
+   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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wellington & Gudmundsson    Standards Track                     [Page 8]
+
diff --git a/doc/rfc/rfc3658.txt b/doc/rfc/rfc3658.txt
new file mode 100644
index 0000000..88cfb5a
--- /dev/null
+++ b/doc/rfc/rfc3658.txt
@@ -0,0 +1,1067 @@
+
+
+
+
+
+
+Network Working Group                                     O. Gudmundsson
+Request for Comments: 3658                                 December 2003
+Updates: 3090, 3008, 2535, 1035
+Category: Standards Track
+
+
+              Delegation Signer (DS) Resource Record (RR)
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2003).  All Rights Reserved.
+
+Abstract
+
+   The delegation signer (DS) resource record (RR) is inserted at a zone
+   cut (i.e., a delegation point) to indicate that the delegated zone is
+   digitally signed and that the delegated zone recognizes the indicated
+   key as a valid zone key for the delegated zone.  The DS RR is a
+   modification to the DNS Security Extensions definition, motivated by
+   operational considerations.  The intent is to use this resource
+   record as an explicit statement about the delegation, rather than
+   relying on inference.
+
+   This document defines the DS RR, gives examples of how it is used and
+   describes the implications on resolvers.  This change is not
+   backwards compatible with RFC 2535.  This document updates RFC 1035,
+   RFC 2535, RFC 3008 and RFC 3090.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gudmundsson                 Standards Track                     [Page 1]
+
+RFC 3658      Delegation Signer (DS) Resource Record (RR)  December 2003
+
+
+Table of Contents
+
+   1.  Introduction. . . . . . . . . . . . . . . . . . . . . . . . .   3
+       1.2.  Reserved Words. . . . . . . . . . . . . . . . . . . . .   4
+   2.  Specification of the Delegation key Signer. . . . . . . . . .   4
+       2.1.  Delegation Signer Record Model. . . . . . . . . . . . .   4
+       2.2.  Protocol Change . . . . . . . . . . . . . . . . . . . .   5
+             2.2.1.  RFC 2535 2.3.4 and 3.4: Special Considerations
+                     at Delegation Points  . . . . . . . . . . . . .   6
+                     2.2.1.1. Special processing for DS queries. . .   6
+                     2.2.1.2. Special processing when child and an
+                              ancestor share nameserver. . . . . . .   7
+                     2.2.1.3. Modification on use of KEY RR in the
+                              construction of Responses. . . . . . .   8
+             2.2.2.  Signer's Name (replaces RFC3008 section 2.7). .   9
+             2.2.3.  Changes to RFC 3090 . . . . . . . . . . . . . .   9
+                     2.2.3.1. RFC 3090: Updates to section 1:
+                              Introduction . . . . . . . . . . . . .   9
+                     2.2.3.2. RFC 3090 section 2.1: Globally
+                              Secured. . . . . . . . . . . . . . . .  10
+                     2.2.3.3. RFC 3090 section 3: Experimental
+                              Status . . . . . . . . . . . . . . . .  10
+             2.2.4.  NULL KEY elimination. . . . . . . . . . . . . .  10
+       2.3.  Comments on Protocol Changes. . . . . . . . . . . . . .  10
+       2.4.  Wire Format of the DS record. . . . . . . . . . . . . .  11
+             2.4.1.  Justifications for Fields . . . . . . . . . . .  12
+       2.5.  Presentation Format of the DS Record. . . . . . . . . .  12
+       2.6.  Transition Issues for Installed Base. . . . . . . . . .  12
+             2.6.1.  Backwards compatibility with RFC 2535 and
+                     RFC 1035. . . . . . . . . . . . . . . . . . . .  12
+       2.7.  KEY and corresponding DS record example . . . . . . . .  13
+   3.  Resolver. . . . . . . . . . . . . . . . . . . . . . . . . . .  14
+       3.1.  DS Example" . . . . . . . . . . . . . . . . . . . . . .  14
+       3.2.  Resolver Cost Estimates for DS Records" . . . . . . . .  15
+   4.  Security Considerations . . . . . . . . . . . . . . . . . . .  15
+   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  16
+   6.  Intellectual Property Statement . . . . . . . . . . . . . . .  16
+   7.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  17
+   8.  References. . . . . . . . . . . . . . . . . . . . . . . . . .  17
+       8.1.  Normative References. . . . . . . . . . . . . . . . . .  17
+       8.2.  Informational References. . . . . . . . . . . . . . . .  17
+   9.  Author's Address. . . . . . . . . . . . . . . . . . . . . . .  18
+   10. Full Copyright Statement. . . . . . . . . . . . . . . . . . .  19
+
+
+
+
+
+
+
+
+Gudmundsson                 Standards Track                     [Page 2]
+
+RFC 3658      Delegation Signer (DS) Resource Record (RR)  December 2003
+
+
+1.  Introduction
+
+   Familiarity with the DNS system [RFC1035], DNS security extensions
+   [RFC2535], and DNSSEC terminology [RFC3090] is important.
+
+   Experience shows that when the same data can reside in two
+   administratively different DNS zones, the data frequently gets out of
+   sync.  The presence of an NS RRset in a zone anywhere other than at
+   the apex indicates a zone cut or delegation.  The RDATA of the NS
+   RRset specifies the authoritative nameservers for the delegated or
+   "child" zone.  Based on actual measurements, 10-30% of all
+   delegations on the Internet have differing NS RRsets at parent and
+   child.  There are a number of reasons for this, including a lack of
+   communication between parent and child and bogus name servers being
+   listed to meet registry requirements.
+
+   DNSSEC [RFC2535, RFC3008, RFC3090] specifies that a child zone needs
+   to have its KEY RRset signed by its parent to create a verifiable
+   chain of KEYs.  There has been some debate on where the signed KEY
+   RRset should reside, whether at the child [RFC2535] or at the parent.
+   If the KEY RRset resides at the child, maintaining the signed KEY
+   RRset in the child requires frequent two-way communication between
+   the two parties.  First, the child transmits the KEY RRset to the
+   parent and then the parent sends the signature(s) to the child.
+   Storing the KEY RRset at the parent was thought to simplify the
+   communication.
+
+   DNSSEC [RFC2535] requires that the parent store a NULL KEY record for
+   an unsecure child zone to indicate that the child is unsecure.  A
+   NULL KEY record is a waste: an entire signed RRset is used to
+   communicate effectively one bit of information - that the child is
+   unsecure. Chasing down NULL KEY RRsets complicates the resolution
+   process in many cases, because nameservers for both parent and child
+   need to be queried for the KEY RRset if the child nameserver does not
+   return it.  Storing the KEY RRset only in the parent zone simplifies
+   this and would allow the elimination of the NULL KEY RRsets entirely.
+   For large delegation zones, the cost of NULL keys is a significant
+   barrier to deployment.
+
+   Prior to the restrictions imposed by RFC 3445 [RFC3445], another
+   implication of the DNSSEC key model is that the KEY record could be
+   used to store public keys for other protocols in addition to DNSSEC
+   keys.  There are a number of potential problems with this, including:
+
+   1. The KEY RRset can become quite large if many applications and
+      protocols store their keys at the zone apex.  Possible protocols
+      are IPSEC, HTTP, SMTP, SSH and others that use public key
+      cryptography.
+
+
+
+Gudmundsson                 Standards Track                     [Page 3]
+
+RFC 3658      Delegation Signer (DS) Resource Record (RR)  December 2003
+
+
+   2. The KEY RRset may require frequent updates.
+
+   3. The probability of compromised or lost keys, which trigger
+      emergency key roll-over procedures, increases.
+
+   4. The parent may refuse to sign KEY RRsets with non-DNSSEC zone
+      keys.
+
+   5. The parent may not meet the child's expectations of turnaround
+      time for resigning the KEY RRset.
+
+   Given these reasons, SIG@parent isn't any better than SIG/KEY@Child.
+
+1.2.  Reserved Words
+
+   The key words "MAY", "MAY NOT", "MUST", "MUST NOT", "REQUIRED",
+   "RECOMMENDED", "SHOULD", and "SHOULD NOT" in this document are to be
+   interpreted as described in BCP 14, RFC 2119 [RFC2119].
+
+2.  Specification of the Delegation key Signer
+
+   This section defines the Delegation Signer (DS) RR type (type code
+   43) and the changes to DNS to accommodate it.
+
+2.1.  Delegation Signer Record Model
+
+   This document presents a replacement for the DNSSEC KEY record chain
+   of trust [RFC2535] that uses a new RR that resides only at the
+   parent.  This record identifies the key(s) that the child uses to
+   self-sign its own KEY RRset.
+
+   Even though DS identifies two roles for KEYs, Key Signing Key (KSK)
+   and Zone Signing Key (ZSK), there is no requirement that zone uses
+   two different keys for these roles.  It is expected that many small
+   zones will only use one key, while larger zones will be more likely
+   to use multiple keys.
+
+   The chain of trust is now established by verifying the parent KEY
+   RRset, the DS RRset from the parent and the KEY RRset at the child.
+   This is cryptographically equivalent to using just KEY records.
+
+   Communication between the parent and child is greatly reduced, since
+   the child only needs to notify the parent about changes in keys that
+   sign its apex KEY RRset.  The parent is ignorant of all other keys in
+   the child's apex KEY RRset.  Furthermore, the child maintains full
+   control over the apex KEY RRset and its content.  The child can
+   maintain any policies regarding its KEY usage for DNSSEC with minimal
+   impact on the parent.  Thus, if the child wants to have frequent key
+
+
+
+Gudmundsson                 Standards Track                     [Page 4]
+
+RFC 3658      Delegation Signer (DS) Resource Record (RR)  December 2003
+
+
+   roll-over for its DNS zone keys, the parent does not need to be aware
+   of it.  The child can use one key to sign only its apex KEY RRset and
+   a different key to sign the other RRsets in the zone.
+
+   This model fits well with a slow roll out of DNSSEC and the islands
+   of security model.  In this model, someone who trusts "good.example."
+   can preconfigure a key from "good.example." as a trusted key, and
+   from then on trusts any data signed by that key or that has a chain
+   of trust to that key.  If "example." starts advertising DS records,
+   "good.example." does not have to change operations by suspending
+   self-signing.  DS records can be used in configuration files to
+   identify trusted keys instead of KEY records.  Another significant
+   advantage is that the amount of information stored in large
+   delegation zones is reduced: rather than the NULL KEY record at every
+   unsecure delegation demanded by RFC 2535, only secure delegations
+   require additional information in the form of a signed DS RRset.
+
+   The main disadvantage of this approach is that verifying a zone's KEY
+   RRset requires two signature verification operations instead of the
+   one in RFC 2535 chain of trust.  There is no impact on the number of
+   signatures verified for other types of RRsets.
+
+2.2.  Protocol Change
+
+   All DNS servers and resolvers that support DS MUST support the OK bit
+   [RFC3225] and a larger message size [RFC3226].  In order for a
+   delegation to be considered secure the delegation MUST contain a DS
+   RRset.  If a query contains the OK bit, a nameserver returning a
+   referral for the delegation MUST include the following RRsets in the
+   authority section in this order:
+
+   If DS RRset is present:
+      parent's copy of child's NS RRset
+      DS and SIG(DS)
+
+   If no DS RRset is present:
+      parent's copy of child's NS RRset
+      parent's zone NXT and SIG(NXT)
+
+   This increases the size of referral messages, possibly causing some
+   or all glue to be omitted.  If the DS or NXT RRsets with signatures
+   do not fit in the DNS message, the TC bit MUST be set.  Additional
+   section processing is not changed.
+
+   A DS RRset accompanying a NS RRset indicates that the child zone is
+   secure.  If a NS RRset exists without a DS RRset, the child zone is
+   unsecure (from the parents point of view).  DS RRsets MUST NOT appear
+   at non-delegation points or at a zone's apex.
+
+
+
+Gudmundsson                 Standards Track                     [Page 5]
+
+RFC 3658      Delegation Signer (DS) Resource Record (RR)  December 2003
+
+
+   Section 2.2.1 defines special considerations related to authoritative
+   nameservers responding to DS queries and replaces RFC 2535 sections
+   2.3.4 and 3.4.  Section 2.2.2 replaces RFC 3008 section 2.7, and
+   section 2.2.3 updates RFC 3090.
+
+2.2.1.  RFC 2535 2.3.4 and 3.4: Special Considerations at Delegation
+        Points
+
+   DNS security views each zone as a unit of data completely under the
+   control of the zone owner with each entry (RRset) signed by a special
+   private key held by the zone manager.  But the DNS protocol views the
+   leaf nodes in a zone that are also the apex nodes of a child zone
+   (i.e., delegation points) as "really" belonging to the child zone.
+   The corresponding domain names appear in two master files and might
+   have RRsets signed by both the parent and child zones' keys.  A
+   retrieval could get a mixture of these RRsets and SIGs, especially
+   since one nameserver could be serving both the zone above and below a
+   delegation point [RFC2181].
+
+   Each DS RRset stored in the parent zone MUST be signed by at least
+   one of the parent zone's private keys.  The parent zone MUST NOT
+   contain a KEY RRset at any delegation point.  Delegations in the
+   parent MAY contain only the following RR types: NS, DS, NXT and SIG.
+   The NS RRset MUST NOT be signed.  The NXT RRset is the exceptional
+   case: it will always appear differently and authoritatively in both
+   the parent and child zones, if both are secure.
+
+   A secure zone MUST contain a self-signed KEY RRset at its apex.  Upon
+   verifying the DS RRset from the parent, a resolver MAY trust any KEY
+   identified in the DS RRset as a valid signer of the child's apex KEY
+   RRset.  Resolvers configured to trust one of the keys signing the KEY
+   RRset MAY now treat any data signed by the zone keys in the KEY RRset
+   as secure.  In all other cases, resolvers MUST consider the zone
+   unsecure.
+
+   An authoritative nameserver queried for type DS MUST return the DS
+   RRset in the answer section.
+
+2.2.1.1.  Special processing for DS queries
+
+   When a nameserver is authoritative for the parent zone at a
+   delegation point and receives a query for the DS record at that name,
+   it MUST answer based on data in the parent zone, return DS or
+   negative answer.  This is true whether or not it is also
+   authoritative for the child zone.
+
+
+
+
+
+
+Gudmundsson                 Standards Track                     [Page 6]
+
+RFC 3658      Delegation Signer (DS) Resource Record (RR)  December 2003
+
+
+   When the nameserver is authoritative for the child zone at a
+   delegation point but not the parent zone, there is no natural
+   response, since the child zone is not authoritative for the DS record
+   at the zone's apex.  As these queries are only expected to originate
+   from recursive nameservers which are not DS-aware, the authoritative
+   nameserver MUST answer with:
+
+      RCODE:             NOERROR
+      AA bit:            set
+      Answer Section:    Empty
+      Authority Section: SOA [+ SIG(SOA) + NXT + SIG(NXT)]
+
+   That is, it answers as if it is authoritative and the DS record does
+   not exist.  DS-aware recursive nameservers will query the parent zone
+   at delegation points, so will not be affected by this.
+
+   A nameserver authoritative for only the child zone, that is also a
+   caching server MAY (if the RD bit is set in the query) perform
+   recursion to find the DS record at the delegation point, or MAY
+   return the DS record from its cache.  In this case, the AA bit MUST
+   NOT be set in the response.
+
+2.2.1.2.  Special processing when child and an ancestor share
+          nameserver
+
+   Special rules are needed to permit DS RR aware nameservers to
+   gracefully interact with older caches which otherwise might falsely
+   label a nameserver as lame because of the placement of the DS RR set.
+
+   Such a situation might arise when a nameserver is authoritative for
+   both a zone and it's grandparent, but not the parent.  This sounds
+   like an obscure example, but it is very real.  The root zone is
+   currently served on 13 machines, and "root-servers.net." is served on
+   4 of the 13, but "net." is severed on different nameservers.
+
+   When a nameserver receives a query for (<QNAME>, DS, <QCLASS>), the
+   response MUST be determined from reading these rules in order:
+
+   1) If the nameserver is authoritative for the zone that holds the DS
+      RR set (i.e., the zone that delegates <QNAME>, a.k.a. the "parent"
+      zone), the response contains the DS RR set as an authoritative
+      answer.
+
+   2) If the nameserver is offering recursive service and the RD bit is
+      set in the query, the nameserver performs the query itself
+      (according to the rules for resolvers described below) and returns
+      its findings.
+
+
+
+
+Gudmundsson                 Standards Track                     [Page 7]
+
+RFC 3658      Delegation Signer (DS) Resource Record (RR)  December 2003
+
+
+   3) If the nameserver is authoritative for the zone that holds the
+      <QNAME>'s SOA RR set, the response is an authoritative negative
+      answer as described in 2.2.1.1.
+
+   4) If the nameserver is authoritative for a zone or zones above the
+      QNAME, a referral to the most enclosing (deepest match) zone's
+      servers is made.
+
+   5) If the nameserver is not authoritative for any part of the QNAME,
+      a response indicating a lame nameserver for QNAME is given.
+
+   Using these rules will require some special processing on the part of
+   a DS RR aware resolver.  To illustrate this, an example is used.
+
+   Assuming a nameserver is authoritative for roots.example.net. and for
+   the root zone but not the intervening two zones (or the intervening
+   two label deep zone).  Assume that QNAME=roots.example.net.,
+   QTYPE=DS, and QCLASS=IN.
+
+   The resolver will issue this request (assuming no cached data)
+   expecting a referral to a nameserver for .net.  Instead, rule number
+   3 above applies and a negative answer is returned by the nameserver.
+   The reaction by the resolver is not to accept this answer as final,
+   as it can determine from the SOA RR in the negative answer the
+   context within which the nameserver has answered.
+
+   A solution would be to instruct the resolver to hunt for the
+   authoritative zone of the data in a brute force manner.
+
+   This can be accomplished by taking the owner name of the returned SOA
+   RR and striping off enough left-hand labels until a successful NS
+   response is obtained.  A successful response here means that the
+   answer has NS records in it.  (Entertaining the possibility that a
+   cut point can be two labels down in a zone.)
+
+   Returning to the example, the response will include a negative answer
+   with either the SOA RR for "roots.example.net." or "example.net."
+   depending on whether roots.example.net is a delegated domain.  In
+   either case, removing the left most label of the SOA owner name will
+   lead to the location of the desired data.
+
+2.2.1.3.  Modification on use of KEY RR in the construction of Responses
+
+   This section updates RFC 2535 section 3.5 by replacing it with the
+   following:
+
+
+
+
+
+
+Gudmundsson                 Standards Track                     [Page 8]
+
+RFC 3658      Delegation Signer (DS) Resource Record (RR)  December 2003
+
+
+   A query for KEY RR MUST NOT trigger any additional section
+   processing.  Security aware resolvers will include corresponding SIG
+   records in the answer section.
+
+   KEY records SHOULD NOT be added to the additional records section in
+   response to any query.
+
+   RFC 2535 specified that KEY records be added to the additional
+   section when SOA or NS records were included in an answer.  This was
+   done to reduce round trips (in the case of SOA) and to force out NULL
+   KEYs (in the NS case).  As this document obsoletes NULL keys, there
+   is no need for the inclusion of KEYs with NSs.  Furthermore, as SOAs
+   are included in the authority section of negative answers, including
+   the KEYs each time will cause redundant transfers of KEYs.
+
+   RFC 2535 section 3.5 also included a rule for adding the KEY RRset to
+   the response for a query for A and AAAA types.  As Restrict KEY
+   [RFC3445] eliminated use of KEY RR by all applications, this rule is
+   no longer needed.
+
+2.2.2.  Signer's Name (replaces RFC 3008 section 2.7)
+
+   The signer's name field of a SIG RR MUST contain the name of the zone
+   to which the data and signature belong.  The combination of signer's
+   name, key tag, and algorithm MUST identify a zone key if the SIG is
+   to be considered material.  This document defines a standard policy
+   for DNSSEC validation; local policy MAY override the standard policy.
+
+   There are no restrictions on the signer field of a SIG(0) record. The
+   combination of signer's name, key tag, and algorithm MUST identify a
+   key if this SIG(0) is to be processed.
+
+2.2.3.  Changes to RFC 3090
+
+   A number of sections in RFC 3090 need to be updated to reflect the DS
+   record.
+
+2.2.3.1.  RFC 3090: Updates to section 1: Introduction
+
+   Most of the text is still relevant but the words "NULL key" are to be
+   replaced with "missing DS RRset".  In section 1.3, the last three
+   paragraphs discuss the confusion in sections of RFC 2535 that are
+   replaced in section 2.2.1 above.  Therefore, these paragraphs are now
+   obsolete.
+
+
+
+
+
+
+
+Gudmundsson                 Standards Track                     [Page 9]
+
+RFC 3658      Delegation Signer (DS) Resource Record (RR)  December 2003
+
+
+2.2.3.2.  RFC 3090 section 2.1: Globally Secured
+
+   Rule 2.1.b is replaced by the following rule:
+
+   2.1.b. The KEY RRset at a zone's apex MUST be self-signed by a
+   private key whose public counterpart MUST appear in a zone signing
+   KEY RR (2.a) owned by the zone's apex and specifying a mandatory-to-
+   implement algorithm.  This KEY RR MUST be identified by a DS RR in a
+   signed DS RRset in the parent zone.
+
+   If a zone cannot get its parent to advertise a DS record for it, the
+   child zone cannot be considered globally secured.  The only exception
+   to this is the root zone, for which there is no parent zone.
+
+2.2.3.3.  RFC 3090 section 3: Experimental Status.
+
+   The only difference between experimental status and globally secured
+   is the missing DS RRset in the parent zone.  All locally secured
+   zones are experimental.
+
+2.2.4.  NULL KEY elimination
+
+   RFC 3445 section 3 eliminates the top two bits in the flags field of
+   KEY RR.  These two bits were used to indicate NULL KEY or NO KEY. RFC
+   3090 defines that zone as either secure or not and these rules
+   eliminate the need to put NULL keys in the zone apex to indicate that
+   the zone is not secured for a algorithm.  Along with this document,
+   these other two eliminate all uses for the NULL KEY.  This document
+   obsoletes NULL KEY.
+
+2.3.  Comments on Protocol Changes
+
+   Over the years, there have been various discussions surrounding the
+   DNS delegation model, declaring it to be broken because there is no
+   good way to assert if a delegation exists.  In the RFC 2535 version
+   of DNSSEC, the presence of the NS bit in the NXT bit map proves there
+   is a delegation at this name.  Something more explicit is required
+   and the DS record addresses this need for secure delegations.
+
+   The DS record is a major change to DNS: it is the first resource
+   record that can appear only on the upper side of a delegation.
+   Adding it will cause interoperability problems and requires a flag
+   day for DNSSEC.  Many old nameservers and resolvers MUST be upgraded
+   to take advantage of DS.  Some old nameservers will be able to be
+   authoritative for zones with DS records but will not add the NXT or
+   DS records to the authority section.  The same is true for caching
+   nameservers; in fact, some might even refuse to pass on the DS or NXT
+   records.
+
+
+
+Gudmundsson                 Standards Track                    [Page 10]
+
+RFC 3658      Delegation Signer (DS) Resource Record (RR)  December 2003
+
+
+2.4.  Wire Format of the DS record
+
+   The DS (type=43) record contains these fields: key tag, algorithm,
+   digest type, and the digest of a public key KEY record that is
+   allowed and/or used to sign the child's apex KEY RRset.  Other keys
+   MAY sign the child's apex KEY RRset.
+
+                        1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |           key tag             |  algorithm    |  Digest type  |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                digest  (length depends on type)               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                (SHA-1 digest is 20 bytes)                     |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
+   |                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
+   |                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   The key tag is calculated as specified in RFC 2535.  Algorithm MUST
+   be allowed to sign DNS data.  The digest type is an identifier for
+   the digest algorithm used.  The digest is calculated over the
+   canonical name of the delegated domain name followed by the whole
+   RDATA of the KEY record (all four fields).
+
+      digest = hash( canonical FQDN on KEY RR | KEY_RR_rdata)
+
+      KEY_RR_rdata = Flags | Protocol | Algorithm | Public Key
+
+   Digest type value 0 is reserved, value 1 is SHA-1, and reserving
+   other types requires IETF standards action.  For interoperability
+   reasons, keeping number of digest algorithms low is strongly
+   RECOMMENDED.  The only reason to reserve additional digest types is
+   to increase security.
+
+   DS records MUST point to zone KEY records that are allowed to
+   authenticate DNS data.  The indicated KEY records protocol field MUST
+   be set to 3; flag field bit 7 MUST be set to 1.  The value of other
+   flag bits is not significant for the purposes of this document.
+
+   The size of the DS RDATA for type 1 (SHA-1) is 24 bytes, regardless
+   of key size.  New digest types probably will have larger digests.
+
+
+
+
+
+Gudmundsson                 Standards Track                    [Page 11]
+
+RFC 3658      Delegation Signer (DS) Resource Record (RR)  December 2003
+
+
+2.4.1.  Justifications for Fields
+
+   The algorithm and key tag fields are present to allow resolvers to
+   quickly identify the candidate KEY records to examine.  SHA-1 is a
+   strong cryptographic checksum: it is computationally infeasible for
+   an attacker to generate a KEY record that has the same SHA-1 digest.
+   Combining the name of the key and the key rdata as input to the
+   digest provides stronger assurance of the binding.  Having the key
+   tag in the DS record adds greater assurance than the SHA-1 digest
+   alone, as there are now two different mapping functions.
+
+   This format allows concise representation of the keys that the child
+   will use, thus keeping down the size of the answer for the
+   delegation, reducing the probability of DNS message overflow.  The
+   SHA-1 hash is strong enough to uniquely identify the key and is
+   similar to the PGP key footprint.  The digest type field is present
+   for possible future expansion.
+
+   The DS record is well suited to listing trusted keys for islands of
+   security in configuration files.
+
+2.5.  Presentation Format of the DS Record
+
+   The presentation format of the DS record consists of three numbers
+   (key tag, algorithm, and digest type) followed by the digest itself
+   presented in hex:
+
+      example.   DS  12345 3 1 123456789abcdef67890123456789abcdef67890
+
+2.6.  Transition Issues for Installed Base
+
+   No backwards compatibility with RFC 2535 is provided.
+
+   RFC 2535-compliant resolvers will assume that all DS-secured
+   delegations are locally secure.  This is bad, but the DNSEXT Working
+   Group has determined that rather than dealing with both RFC 2535-
+   secured zones and DS-secured zones, a rapid adoption of DS is
+   preferable.  Thus, the only option for early adopters is to upgrade
+   to DS as soon as possible.
+
+2.6.1.  Backwards compatibility with RFC 2535 and RFC 1035
+
+   This section documents how a resolver determines the type of
+   delegation.
+
+
+
+
+
+
+
+Gudmundsson                 Standards Track                    [Page 12]
+
+RFC 3658      Delegation Signer (DS) Resource Record (RR)  December 2003
+
+
+   RFC 1035 delegation (in parent) has:
+
+   RFC 1035           NS
+
+   RFC 2535 adds the following two cases:
+
+   Secure RFC 2535:   NS + NXT + SIG(NXT)
+                      NXT bit map contains: NS SIG NXT
+   Unsecure RFC 2535: NS + KEY + SIG(KEY) + NXT + SIG(NXT)
+                      NXT bit map contains: NS SIG KEY NXT
+                      KEY must be a NULL key.
+
+   DNSSEC with DS has the following two states:
+
+   Secure DS:         NS + DS + SIG(DS)
+                      NXT bit map contains: NS SIG NXT DS
+   Unsecure DS:       NS + NXT + SIG(NXT)
+                      NXT bit map contains: NS SIG NXT
+
+   It is difficult for a resolver to determine if a delegation is secure
+   RFC 2535 or unsecure DS.  This could be overcome by adding a flag to
+   the NXT bit map, but only upgraded resolvers would understand this
+   flag, anyway.  Having both parent and child signatures for a KEY
+   RRset might allow old resolvers to accept a zone as secure, but the
+   cost of doing this for a long time is much higher than just
+   prohibiting RFC 2535-style signatures at child zone apexes and
+   forcing rapid deployment of DS-enabled nameservers and resolvers.
+
+   RFC 2535 and DS can, in theory, be deployed in parallel, but this
+   would require resolvers to deal with RFC 2535 configurations forever.
+   This document obsoletes the NULL KEY in parent zones, which is a
+   difficult enough change that to cause a flag day.
+
+2.7.  KEY and corresponding DS record example
+
+   This is an example of a KEY record and the corresponding DS record.
+
+   dskey.example. KEY  256 3 1 (
+                  AQPwHb4UL1U9RHaU8qP+Ts5bVOU1s7fYbj2b3CCbzNdj
+                  4+/ECd18yKiyUQqKqQFWW5T3iVc8SJOKnueJHt/Jb/wt
+                  ) ; key id = 28668
+             DS   28668 1  1  49FD46E6C4B45C55D4AC69CBD3CD34AC1AFE51DE
+
+
+
+
+
+
+
+
+
+Gudmundsson                 Standards Track                    [Page 13]
+
+RFC 3658      Delegation Signer (DS) Resource Record (RR)  December 2003
+
+
+3.  Resolver
+
+3.1.  DS Example
+
+   To create a chain of trust, a resolver goes from trusted KEY to DS to
+   KEY.
+
+      Assume the key for domain "example." is trusted.  Zone "example."
+      contains at least the following records:
+      example.          SOA     <soa stuff>
+      example.          NS       ns.example.
+      example.          KEY     <stuff>
+      example.          NXT      secure.example. NS SOA KEY SIG NXT
+      example.          SIG(SOA)
+      example.          SIG(NS)
+      example.          SIG(NXT)
+      example.          SIG(KEY)
+      secure.example.   NS      ns1.secure.example.
+      secure.example.   DS      tag=12345 alg=3 digest_type=1 <foofoo>
+      secure.example.   NXT     unsecure.example. NS SIG NXT DS
+      secure.example.   SIG(NXT)
+      secure.example.   SIG(DS)
+      unsecure.example  NS      ns1.unsecure.example.
+      unsecure.example. NXT     example. NS SIG NXT
+      unsecure.example. SIG(NXT)
+
+      In zone "secure.example." following records exist:
+      secure.example.   SOA      <soa stuff>
+      secure.example.   NS       ns1.secure.example.
+      secure.example.   KEY      <tag=12345 alg=3>
+      secure.example.   KEY      <tag=54321 alg=5>
+      secure.example.   NXT      <nxt stuff>
+      secure.example.   SIG(KEY) <key-tag=12345 alg=3>
+      secure.example.   SIG(SOA) <key-tag=54321 alg=5>
+      secure.example.   SIG(NS)  <key-tag=54321 alg=5>
+      secure.example.   SIG(NXT) <key-tag=54321 alg=5>
+
+   In this example, the private key for "example." signs the DS record
+   for "secure.example.", making that a secure delegation.  The DS
+   record states which key is expected to sign the KEY RRset at
+   "secure.example.".  Here "secure.example." signs its KEY RRset with
+   the KEY identified in the DS RRset, thus the KEY RRset is validated
+   and trusted.
+
+   This example has only one DS record for the child, but parents MUST
+   allow multiple DS records to facilitate key roll-over and multiple
+   KEY algorithms.
+
+
+
+
+Gudmundsson                 Standards Track                    [Page 14]
+
+RFC 3658      Delegation Signer (DS) Resource Record (RR)  December 2003
+
+
+   The resolver determines the security status of "unsecure.example." by
+   examining the parent zone's NXT record for this name.  The absence of
+   the DS bit indicates an unsecure delegation.  Note the NXT record
+   SHOULD only be examined after verifying the corresponding signature.
+
+3.2.  Resolver Cost Estimates for DS Records
+
+   From a RFC 2535 recursive resolver point of view, for each delegation
+   followed to chase down an answer, one KEY RRset has to be verified.
+   Additional RRsets might also need to be verified based on local
+   policy (e.g., the contents of the NS RRset).  Once the resolver gets
+   to the appropriate delegation, validating the answer might require
+   verifying one or more signatures.  A simple A record lookup requires
+   at least N delegations to be verified and one RRset.  For a DS-
+   enabled recursive resolver, the cost is 2N+1.  For an MX record,
+   where the target of the MX record is in the same zone as the MX
+   record, the costs are N+2 and 2N+2, for RFC 2535 and DS,
+   respectively.  In the case of a negative answer, the same ratios hold
+   true.
+
+   The recursive resolver has to do an extra query to get the DS record,
+   which will increase the overall cost of resolving this question, but
+   it will never be worse than chasing down NULL KEY records from the
+   parent in RFC 2535 DNSSEC.
+
+   DS adds processing overhead on resolvers and increases the size of
+   delegation answers, but much less than storing signatures in the
+   parent zone.
+
+4.  Security Considerations
+
+   This document proposes a change to the validation chain of KEY
+   records in DNSSEC.  The change is not believed to reduce security in
+   the overall system.  In RFC 2535 DNSSEC, the child zone has to
+   communicate keys to its parent and prudent parents will require some
+   authentication with that transaction.  The modified protocol will
+   require the same authentication, but allows the child to exert more
+   local control over its own KEY RRset.
+
+   There is a remote possibility that an attacker could generate a valid
+   KEY that matches all the DS fields, of a specific DS set, and thus
+   forge data from the child.  This possibility is considered
+   impractical, as on average more than
+
+      2 ^ (160 - <Number of keys in DS set>)
+
+   keys would have to be generated before a match would be found.
+
+
+
+
+Gudmundsson                 Standards Track                    [Page 15]
+
+RFC 3658      Delegation Signer (DS) Resource Record (RR)  December 2003
+
+
+   An attacker that wants to match any DS record will have to generate
+   on average at least 2^80 keys.
+
+   The DS record represents a change to the DNSSEC protocol and there is
+   an installed base of implementations, as well as textbooks on how to
+   set up secure delegations.  Implementations that do not understand
+   the DS record will not be able to follow the KEY to DS to KEY chain
+   and will consider all zones secured that way as unsecure.
+
+5.  IANA Considerations
+
+   IANA has allocated an RR type code for DS from the standard RR type
+   space (type 43).
+
+   IANA has established a new registry for the DS RR type for digest
+   algorithms.  Defined types are:
+
+      0 is Reserved,
+      1 is SHA-1.
+
+   Adding new reservations requires IETF standards action.
+
+6.  Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   intellectual property or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; neither does it represent that it
+   has made any effort to identify any such rights.  Information on the
+   IETF's procedures with respect to rights in standards-track and
+   standards-related documentation can be found in BCP-11.  Copies of
+   claims of rights made available for publication and any assurances of
+   licenses to be made available, or the result of an attempt made to
+   obtain a general license or permission for the use of such
+   proprietary rights by implementors or users of this specification can
+   be obtained from the IETF Secretariat.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights which may cover technology that may be required to practice
+   this standard.  Please address the information to the IETF Executive
+   Director.
+
+
+
+
+
+
+
+
+Gudmundsson                 Standards Track                    [Page 16]
+
+RFC 3658      Delegation Signer (DS) Resource Record (RR)  December 2003
+
+
+7.  Acknowledgments
+
+   Over the last few years a number of people have contributed ideas
+   that are captured in this document.  The core idea of using one key
+   to sign only the KEY RRset comes from discussions with Bill Manning
+   and Perry Metzger on how to put in a single root key in all
+   resolvers. Alexis Yushin, Brian Wellington, Sam Weiler, Paul Vixie,
+   Jakob Schlyter, Scott Rose, Edward Lewis, Lars-Johan Liman, Matt
+   Larson, Mark Kosters, Dan Massey, Olaf Kolman, Phillip Hallam-Baker,
+   Miek Gieben, Havard Eidnes, Donald Eastlake 3rd., Randy Bush, David
+   Blacka, Steve Bellovin, Rob Austein, Derek Atkins, Roy Arends, Mark
+   Andrews, Harald Alvestrand, and others have provided useful comments.
+
+8.  References
+
+8.1.  Normative References
+
+   [RFC1035]  Mockapetris, P., "Domain Names - Implementation and
+              Specification", STD 13, RFC 1035, November 1987.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2535]  Eastlake, D., "Domain Name System Security Extensions",
+              RFC 2535, March 1999.
+
+   [RFC3008]  Wellington, B., "Domain Name System Security (DNSSEC)
+              Signing Authority", RFC 3008, November 2000.
+
+   [RFC3090]  Lewis, E., "DNS Security Extension Clarification on Zone
+              Status", RFC 3090, March 2001.
+
+   [RFC3225]  Conrad, D., "Indicating Resolver Support of DNSSEC", RFC
+              3225, December 2001.
+
+   [RFC3445]  Massey, D. and S. Rose, "Limiting the scope of the KEY
+              Resource Record (RR)", RFC 3445, December 2002.
+
+8.2.  Informational References
+
+   [RFC2181]  Elz, R. and R. Bush, "Clarifications to the DNS
+              Specification", RFC 2181, July 1997.
+
+   [RFC3226]  Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver
+              message size requirements", RFC 3226, December 2001.
+
+
+
+
+
+
+Gudmundsson                 Standards Track                    [Page 17]
+
+RFC 3658      Delegation Signer (DS) Resource Record (RR)  December 2003
+
+
+9.  Author's Address
+
+   Olafur Gudmundsson
+   3821 Village Park Drive
+   Chevy Chase, MD,  20815
+
+   EMail: ds-rfc@ogud.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gudmundsson                 Standards Track                    [Page 18]
+
+RFC 3658      Delegation Signer (DS) Resource Record (RR)  December 2003
+
+
+10.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2003).  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 Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assignees.
+
+   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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gudmundsson                 Standards Track                    [Page 19]
+
diff --git a/doc/rfc/rfc3757.txt b/doc/rfc/rfc3757.txt
new file mode 100644
index 0000000..31890a4
--- /dev/null
+++ b/doc/rfc/rfc3757.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+Network Working Group                                         O. Kolkman
+Request for Comments: 3757                                      RIPE NCC
+Updates: 3755, 2535                                          J. Schlyter
+Category: Standards Track                                         NIC-SE
+                                                                E. Lewis
+                                                                    ARIN
+                                                              April 2004
+
+
+         Domain Name System KEY (DNSKEY) Resource Record (RR)
+                     Secure Entry Point (SEP) Flag
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2004).  All Rights Reserved.
+
+Abstract
+
+   With the Delegation Signer (DS) resource record (RR), the concept of
+   a public key acting as a secure entry point (SEP) has been
+   introduced.  During exchanges of public keys with the parent there is
+   a need to differentiate SEP keys from other public keys in the Domain
+   Name System KEY (DNSKEY) resource record set.  A flag bit in the
+   DNSKEY RR is defined to indicate that DNSKEY is to be used as a SEP.
+   The flag bit is intended to assist in operational procedures to
+   correctly generate DS resource records, or to indicate what DNSKEYs
+   are intended for static configuration.  The flag bit is not to be
+   used in the DNS verification protocol.  This document updates RFC
+   2535 and RFC 3755.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kolkman, et al.              Standard Track                     [Page 1]
+
+RFC 3757                   DNSKEY RR SEP Flag                 April 2004
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
+   2.  The Secure Entry Point (SEP) Flag. . . . . . . . . . . . . . .  4
+   3.  DNSSEC Protocol Changes. . . . . . . . . . . . . . . . . . . .  4
+   4.  Operational Guidelines . . . . . . . . . . . . . . . . . . . .  4
+   5.  Security Considerations. . . . . . . . . . . . . . . . . . . .  5
+   6.  IANA Considerations. . . . . . . . . . . . . . . . . . . . . .  6
+   7.  Internationalization Considerations. . . . . . . . . . . . . .  6
+   8.  Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . .  6
+   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  6
+       9.1.  Normative References . . . . . . . . . . . . . . . . . .  6
+       9.2.  Informative References . . . . . . . . . . . . . . . . .  6
+   10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . .  7
+   11. Full Copyright Statement . . . . . . . . . . . . . . . . . . .  8
+
+1.  Introduction
+
+   "All keys are equal but some keys are more equal than others" [6].
+
+   With the definition of the Delegation Signer Resource Record (DS RR)
+   [5], it has become important to differentiate between the keys in the
+   DNSKEY RR set that are (to be) pointed to by parental DS RRs and the
+   other keys in the DNSKEY RR set.  We refer to these public keys as
+   Secure Entry Point (SEP) keys.  A SEP key either used to generate a
+   DS RR or is distributed to resolvers that use the key as the root of
+   a trusted subtree [3].
+
+   In early deployment tests, the use of two (kinds of) key pairs for
+   each zone has been prevalent.  For one kind of key pair the private
+   key is used to sign just the zone's DNSKEY resource record (RR) set.
+   Its public key is intended to be referenced by a DS RR at the parent
+   or configured statically in a resolver.  The private key of the other
+   kind of key pair is used to sign the rest of the zone's data sets.
+   The former key pair is called a key-signing key (KSK) and the latter
+   is called a zone-signing key (ZSK).  In practice there have been
+   usually one of each kind of key pair, but there will be multiples of
+   each at times.
+
+   It should be noted that division of keys pairs into KSK's and ZSK's
+   is not mandatory in any definition of DNSSEC, not even with the
+   introduction of the DS RR.  But, in testing, this distinction has
+   been helpful when designing key roll over (key super-cession)
+   schemes.  Given that the distinction has proven helpful, the labels
+   KSK and ZSK have begun to stick.
+
+
+
+
+
+
+Kolkman, et al.              Standard Track                     [Page 2]
+
+RFC 3757                   DNSKEY RR SEP Flag                 April 2004
+
+
+   There is a need to differentiate the public keys for the key pairs
+   that are used for key signing from keys that are not used key signing
+   (KSKs vs ZSKs).  This need is driven by knowing which DNSKEYs are to
+   be sent for generating DS RRs, which DNSKEYs are to be distributed to
+   resolvers, and which keys are fed to the signer application at the
+   appropriate time.
+
+   In other words, the SEP bit provides an in-band method to communicate
+   a DNSKEY RR's intended use to third parties.  As an example we
+   present 3 use cases in which the bit is useful:
+
+      The parent is a registry, the parent and the child use secured DNS
+      queries and responses, with a preexisting trust-relation, or plain
+      DNS over a secured channel to exchange the child's DNSKEY RR sets.
+      Since a DNSKEY RR set will contain a complete DNSKEY RRset the SEP
+      bit can be used to isolate the DNSKEYs for which a DS RR needs to
+      be created.
+
+      An administrator has configured a DNSKEY as root for a trusted
+      subtree into security aware resolver.  Using a special purpose
+      tool that queries for the KEY RRs from that domain's apex, the
+      administrator will be able to notice the roll over of the trusted
+      anchor by a change of the subset of KEY RRs with the DS flag set.
+
+      A signer might use the SEP bit on the public key to determine
+      which private key to use to exclusively sign the DNSKEY RRset and
+      which private key to use to sign the other RRsets in the zone.
+
+   As demonstrated in the above examples it is important to be able to
+   differentiate the SEP keys from the other keys in a DNSKEY RR set in
+   the flow between signer and (parental) key-collector and in the flow
+   between the signer and the resolver configuration.  The SEP flag is
+   to be of no interest to the flow between the verifier and the
+   authoritative data store.
+
+   The reason for the term "SEP" is a result of the observation that the
+   distinction between KSK and ZSK key pairs is made by the signer, a
+   key pair could be used as both a KSK and a ZSK at the same time.  To
+   be clear, the term SEP was coined to lessen the confusion caused by
+   the overlap.  (Once this label was applied, it had the side effect of
+   removing the temptation to have both a KSK flag bit and a ZSK flag
+   bit.)
+
+   The key words "MAY","MAY NOT", "MUST", "MUST NOT", "REQUIRED",
+   "RECOMMENDED", "SHOULD", and "SHOULD NOT" in this document are to be
+   interpreted as described in BCP 14, RFC 2119 [1].
+
+
+
+
+
+Kolkman, et al.              Standard Track                     [Page 3]
+
+RFC 3757                   DNSKEY RR SEP Flag                 April 2004
+
+
+2.  The Secure Entry Point (SEP) Flag
+
+                        1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |              flags          |S|   protocol    |   algorithm   |
+   |                             |E|               |               |
+   |                             |P|               |               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                                                               /
+   /                        public key                             /
+   /                                                               /
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                          DNSKEY RR Format
+   This document assigns the 15th bit in the flags field as the secure
+   entry point (SEP) bit.  If the bit is set to 1 the key is intended to
+   be used as secure entry point key.  One SHOULD NOT assign special
+   meaning to the key if the bit is set to 0.  Operators can recognize
+   the secure entry point key by the even or odd-ness of the decimal
+   representation of the flag field.
+
+3.  DNSSEC Protocol Changes
+
+   The bit MUST NOT be used during the resolving and verification
+   process.  The SEP flag is only used to provide a hint about the
+   different administrative properties of the key and therefore the use
+   of the SEP flag does not change the DNS resolution protocol or the
+   resolution process.
+
+4.  Operational Guidelines
+
+   The SEP bit is set by the key-pair-generator and MAY be used by the
+   zone signer to decide whether the public part of the key pair is to
+   be prepared for input to a DS RR generation function.  The SEP bit is
+   recommended to be set (to 1) whenever the public key of the key pair
+   will be distributed to the parent zone to build the authentication
+   chain or if the public key is to be distributed for static
+   configuration in verifiers.
+
+   When a key pair is created, the operator needs to indicate whether
+   the SEP bit is to be set in the DNSKEY RR.  As the SEP bit is within
+   the data that is used to compute the 'key tag field' in the SIG RR,
+   changing the SEP bit will change the identity of the key within DNS.
+   In other words, once a key is used to generate signatures, the
+   setting of the SEP bit is to remain constant.  If not, a verifier
+   will not be able to find the relevant KEY RR.
+
+
+
+
+Kolkman, et al.              Standard Track                     [Page 4]
+
+RFC 3757                   DNSKEY RR SEP Flag                 April 2004
+
+
+   When signing a zone, it is intended that the key(s) with the SEP bit
+   set (if such keys exist) are used to sign the KEY RR set of the zone.
+   The same key can be used to sign the rest of the zone data too.  It
+   is conceivable that not all keys with a SEP bit set will sign the
+   DNSKEY RR set, such keys might be pending retirement or not yet in
+   use.
+
+   When verifying a RR set, the SEP bit is not intended to play a role.
+   How the key is used by the verifier is not intended to be a
+   consideration at key creation time.
+
+   Although the SEP flag provides a hint on which public key is to be
+   used as trusted root, administrators can choose to ignore the fact
+   that a DNSKEY has its SEP bit set or not when configuring a trusted
+   root for their resolvers.
+
+   Using the SEP flag a key roll over can be automated.  The parent can
+   use an existing trust relation to verify DNSKEY RR sets in which a
+   new DNSKEY RR with the SEP flag appears.
+
+5.  Security Considerations
+
+   As stated in Section 3 the flag is not to be used in the resolution
+   protocol or to determine the security status of a key.  The flag is
+   to be used for administrative purposes only.
+
+   No trust in a key should be inferred from this flag - trust MUST be
+   inferred from an existing chain of trust or an out-of-band exchange.
+
+   Since this flag might be used for automating public key exchanges, we
+   think the following consideration is in place.
+
+   Automated mechanisms for roll over of the DS RR might be vulnerable
+   to a class of replay attacks.  This might happen after a public key
+   exchange where a DNSKEY RR set, containing two DNSKEY RRs with the
+   SEP flag set, is sent to the parent.  The parent verifies the DNSKEY
+   RR set with the existing trust relation and creates the new DS RR
+   from the DNSKEY RR that the current DS RR is not pointing to.  This
+   key exchange might be replayed.  Parents are encouraged to implement
+   a replay defense.  A simple defense can be based on a registry of
+   keys that have been used to generate DS RRs during the most recent
+   roll over.  These same considerations apply to entities that
+   configure keys in resolvers.
+
+
+
+
+
+
+
+
+Kolkman, et al.              Standard Track                     [Page 5]
+
+RFC 3757                   DNSKEY RR SEP Flag                 April 2004
+
+
+6.  IANA Considerations
+
+   IANA has assigned the 15th bit in the DNSKEY Flags Registry (see
+   Section 4.3 of [4]) as the Secure Entry Point (SEP) bit.
+
+7.  Internationalization Considerations
+
+   Although SEP is a popular acronym in many different languages, there
+   are no internationalization considerations.
+
+8.  Acknowledgments
+
+   The ideas documented in this document are inspired by communications
+   we had with numerous people and ideas published by other folk.  Among
+   others Mark Andrews, Rob Austein, Miek Gieben, Olafur Gudmundsson,
+   Daniel Karrenberg, Dan Massey, Scott Rose, Marcos Sanz and Sam Weiler
+   have contributed ideas and provided feedback.
+
+   This document saw the light during a workshop on DNSSEC operations
+   hosted by USC/ISI in August 2002.
+
+9.  References
+
+9.1.  Normative References
+
+   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
+        Levels", BCP 14, RFC 2119, March 1997.
+
+   [2]  Eastlake, D., "Domain Name System Security Extensions", RFC
+        2535, March 1999.
+
+   [3]  Lewis, E., "DNS Security Extension Clarification on Zone
+        Status", RFC 3090, March 2001.
+
+   [4]  Weiler, S., "Legacy Resolver Compatibility for Delegation Signer
+        (DS)", RFC 3755, April 2004.
+
+9.2.  Informative References
+
+   [5]  Gudmundsson, O., "Delegation Signer (DS) Resource Record (RR)",
+        RFC 3658, December 2003.
+
+   [6]  Orwell, G. and R. Steadman (illustrator), "Animal Farm; a Fairy
+        Story", ISBN 0151002177 (50th anniversary edition), April 1996.
+
+
+
+
+
+
+
+Kolkman, et al.              Standard Track                     [Page 6]
+
+RFC 3757                   DNSKEY RR SEP Flag                 April 2004
+
+
+10.  Authors' Addresses
+
+   Olaf M. Kolkman
+   RIPE NCC
+   Singel 256
+   Amsterdam  1016 AB
+   NL
+
+   Phone: +31 20 535 4444
+   EMail: olaf@ripe.net
+   URI:   http://www.ripe.net/
+
+
+   Jakob Schlyter
+   NIC-SE
+   Box 5774
+   SE-114 87 Stockholm
+   Sweden
+
+   EMail: jakob@nic.se
+   URI:   http://www.nic.se/
+
+
+   Edward P. Lewis
+   ARIN
+   3635 Concorde Parkway Suite 200
+   Chantilly, VA  20151
+   US
+
+   Phone: +1 703 227 9854
+   EMail: edlewis@arin.net
+   URI:   http://www.arin.net/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kolkman, et al.              Standard Track                     [Page 7]
+
+RFC 3757                   DNSKEY RR SEP Flag                 April 2004
+
+
+11.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2004).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78 and
+   except as set forth therein, the authors retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
+   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
+   INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed
+   to pertain to the implementation or use of the technology
+   described in this document or the extent to which any license
+   under such rights might or might not be available; nor does it
+   represent that it has made any independent effort to identify any
+   such rights.  Information on the procedures with respect to
+   rights in RFC documents can be found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use
+   of such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository
+   at http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention
+   any copyrights, patents or patent applications, or other
+   proprietary rights that may cover technology that may be required
+   to implement this standard.  Please address the information to the
+   IETF at ietf-ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+Kolkman, et al.              Standard Track                     [Page 8]
+
diff --git a/doc/rfc/rfc3833.txt b/doc/rfc/rfc3833.txt
new file mode 100644
index 0000000..8ce4d34
--- /dev/null
+++ b/doc/rfc/rfc3833.txt
@@ -0,0 +1,899 @@
+
+
+
+
+
+
+Network Working Group                                          D. Atkins
+Request for Comments: 3833                              IHTFP Consulting
+Category: Informational                                       R. Austein
+                                                                     ISC
+                                                             August 2004
+
+
+            Threat Analysis of the Domain Name System (DNS)
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2004).
+
+Abstract
+
+   Although the DNS Security Extensions (DNSSEC) have been under
+   development for most of the last decade, the IETF has never written
+   down the specific set of threats against which DNSSEC is designed to
+   protect.  Among other drawbacks, this cart-before-the-horse situation
+   has made it difficult to determine whether DNSSEC meets its design
+   goals, since its design goals are not well specified.  This note
+   attempts to document some of the known threats to the DNS, and, in
+   doing so, attempts to measure to what extent (if any) DNSSEC is a
+   useful tool in defending against these threats.
+
+1. Introduction
+
+   The earliest organized work on DNSSEC within the IETF was an open
+   design team meeting organized by members of the DNS working group in
+   November 1993 at the 28th IETF meeting in Houston.  The broad
+   outlines of DNSSEC as we know it today are already clear in Jim
+   Galvin's summary of the results of that meeting [Galvin93]:
+
+   - While some participants in the meeting were interested in
+     protecting against disclosure of DNS data to unauthorized parties,
+     the design team made an explicit decision that "DNS data is
+     `public'", and ruled all threats of data disclosure explicitly out
+     of scope for DNSSEC.
+
+   - While some participants in the meeting were interested in
+     authentication of DNS clients and servers as a basis for access
+     control, this work was also ruled out of scope for DNSSEC per se.
+
+
+
+Atkins & Austein             Informational                      [Page 1]
+
+RFC 3833                  DNS Threat Analysis                August 2004
+
+
+   - Backwards compatibility and co-existence with "insecure DNS" was
+     listed as an explicit requirement.
+
+   - The resulting list of desired security services was
+     1) data integrity, and
+     2) data origin authentication.
+
+   - The design team noted that a digital signature mechanism would
+     support the desired services.
+
+   While a number of detail decisions were yet to be made (and in some
+   cases remade after implementation experience) over the subsequent
+   decade, the basic model and design goals have remained fixed.
+
+   Nowhere, however, does any of the DNSSEC work attempt to specify in
+   any detail the sorts of attacks against which DNSSEC is intended to
+   protect, or the reasons behind the list of desired security services
+   that came out of the Houston meeting.  For that, we have to go back
+   to a paper originally written by Steve Bellovin in 1990 but not
+   published until 1995, for reasons that Bellovin explained in the
+   paper's epilogue [Bellovin95].
+
+   While it may seem a bit strange to publish the threat analysis a
+   decade after starting work on the protocol designed to defend against
+   it, that is, nevertheless, what this note attempts to do.  Better
+   late than never.
+
+   This note assumes that the reader is familiar with both the DNS and
+   with DNSSEC, and does not attempt to provide a tutorial on either.
+   The DNS documents most relevant to the subject of this note are:
+   [RFC1034], [RFC1035], section 6.1 of [RFC1123], [RFC2181], [RFC2308],
+   [RFC2671], [RFC2845], [RFC2930], [RFC3007], and [RFC2535].
+
+   For purposes of discussion, this note uses the term "DNSSEC" to refer
+   to the core hierarchical public key and signature mechanism specified
+   in the DNSSEC documents, and refers to TKEY and TSIG as separate
+   mechanisms, even though channel security mechanisms such as TKEY and
+   TSIG are also part of the larger problem of "securing DNS" and thus
+   are often considered part of the overall set of "DNS security
+   extensions".  This is an arbitrary distinction that in part reflects
+   the way in which the protocol has evolved (introduction of a
+   putatively simpler channel security model for certain operations such
+   as zone transfers and dynamic update requests), and perhaps should be
+   changed in a future revision of this note.
+
+
+
+
+
+
+
+Atkins & Austein             Informational                      [Page 2]
+
+RFC 3833                  DNS Threat Analysis                August 2004
+
+
+2.  Known Threats
+
+   There are several distinct classes of threats to the DNS, most of
+   which are DNS-related instances of more general problems, but a few
+   of which are specific to peculiarities of the DNS protocol.
+
+2.1.  Packet Interception
+
+   Some of the simplest threats against DNS are various forms of packet
+   interception: monkey-in-the-middle attacks, eavesdropping on requests
+   combined with spoofed responses that beat the real response back to
+   the resolver, and so forth.  In any of these scenarios, the attacker
+   can simply tell either party (usually the resolver) whatever it wants
+   that party to believe.  While packet interception attacks are far
+   from unique to DNS, DNS's usual behavior of sending an entire query
+   or response in a single unsigned, unencrypted UDP packet makes these
+   attacks particularly easy for any bad guy with the ability to
+   intercept packets on a shared or transit network.
+
+   To further complicate things, the DNS query the attacker intercepts
+   may just be a means to an end for the attacker: the attacker might
+   even choose to return the correct result in the answer section of a
+   reply message while using other parts of the message to set the stage
+   for something more complicated, for example, a name chaining attack
+   (see section 2.3).
+
+   While it certainly would be possible to sign DNS messages using a
+   channel security mechanism such as TSIG or IPsec, or even to encrypt
+   them using IPsec, this would not be a very good solution for
+   interception attacks.  First, this approach would impose a fairly
+   high processing cost per DNS message, as well as a very high cost
+   associated with establishing and maintaining bilateral trust
+   relationships between all the parties that might be involved in
+   resolving any particular query.  For heavily used name servers (such
+   as the servers for the root zone), this cost would almost certainly
+   be prohibitively high.  Even more important, however, is that the
+   underlying trust model in such a design would be wrong, since at best
+   it would only provide a hop-by-hop integrity check on DNS messages
+   and would not provide any sort of end-to-end integrity check between
+   the producer of DNS data (the zone administrator) and the consumer of
+   DNS data (the application that triggered the query).
+
+   By contrast, DNSSEC (when used properly) does provide an end-to-end
+   data integrity check, and is thus a much better solution for this
+   class of problems during basic DNS lookup operations.
+
+
+
+
+
+
+Atkins & Austein             Informational                      [Page 3]
+
+RFC 3833                  DNS Threat Analysis                August 2004
+
+
+   TSIG does have its place in corners of the DNS protocol where there's
+   a specific trust relationship between a particular client and a
+   particular server, such as zone transfer, dynamic update, or a
+   resolver (stub or otherwise) that is not going to check all the
+   DNSSEC signatures itself.
+
+   Note that DNSSEC does not provide any protection against modification
+   of the DNS message header, so any properly paranoid resolver must:
+
+   - Perform all of the DNSSEC signature checking on its own,
+
+   - Use TSIG (or some equivalent mechanism) to ensure the integrity of
+     its communication with whatever name servers it chooses to trust,
+     or
+
+   - Resign itself to the possibility of being attacked via packet
+     interception (and via other techniques discussed below).
+
+2.2.  ID Guessing and Query Prediction
+
+   Since DNS is for the most part used over UDP/IP, it is relatively
+   easy for an attacker to generate packets which will match the
+   transport protocol parameters.  The ID field in the DNS header is
+   only a 16-bit field and the server UDP port associated with DNS is a
+   well-known value, so there are only 2**32 possible combinations of ID
+   and client UDP port for a given client and server.  This is not a
+   particularly large range, and is not sufficient to protect against a
+   brute force search; furthermore, in practice both the client UDP port
+   and the ID can often be predicted from previous traffic, and it is
+   not uncommon for the client port to be a known fixed value as well
+   (due to firewalls or other restrictions), thus frequently reducing
+   the search space to a range smaller than 2**16.
+
+   By itself, ID guessing is not enough to allow an attacker to inject
+   bogus data, but combined with knowledge (or guesses) about QNAMEs and
+   QTYPEs for which a resolver might be querying, this leaves the
+   resolver only weakly defended against injection of bogus responses.
+
+   Since this attack relies on predicting a resolver's behavior, it's
+   most likely to be successful when the victim is in a known state,
+   whether because the victim rebooted recently, or because the victim's
+   behavior has been influenced by some other action by the attacker, or
+   because the victim is responding (in a predictable way) to some third
+   party action known to the attacker.
+
+
+
+
+
+
+
+Atkins & Austein             Informational                      [Page 4]
+
+RFC 3833                  DNS Threat Analysis                August 2004
+
+
+   This attack is both more and less difficult for the attacker than the
+   simple interception attack described above: more difficult, because
+   the attack only works when the attacker guesses correctly; less
+   difficult, because the attacker doesn't need to be on a transit or
+   shared network.
+
+   In most other respects, this attack is similar to a packet
+   interception attack.  A resolver that checks DNSSEC signatures will
+   be able to detect the forged response; resolvers that do not perform
+   DNSSEC signature checking themselves should use TSIG or some
+   equivalent mechanism to ensure the integrity of their communication
+   with a recursive name server that does perform DNSSEC signature
+   checking.
+
+2.3.  Name Chaining
+
+   Perhaps the most interesting class of DNS-specific threats are the
+   name chaining attacks.  These are a subset of a larger class of
+   name-based attacks, sometimes called "cache poisoning" attacks.  Most
+   name-based attacks can be partially mitigated by the long-standing
+   defense of checking RRs in response messages for relevance to the
+   original query, but such defenses do not catch name chaining attacks.
+   There are several variations on the basic attack, but what they all
+   have in common is that they all involve DNS RRs whose RDATA portion
+   (right hand side) includes a DNS name (or, in a few cases, something
+   that is not a DNS name but which directly maps to a DNS name).  Any
+   such RR is, at least in principle, a hook that lets an attacker feed
+   bad data into a victim's cache, thus potentially subverting
+   subsequent decisions based on DNS names.
+
+   The worst examples in this class of RRs are CNAME, NS, and DNAME RRs
+   because they can redirect a victim's query to a location of the
+   attacker's choosing.  RRs like MX and SRV are somewhat less
+   dangerous, but in principle they can also be used to trigger further
+   lookups at a location of the attacker's choosing.  Address RR types
+   such as A or AAAA don't have DNS names in their RDATA, but since the
+   IN-ADDR.ARPA and IP6.ARPA trees are indexed using a DNS encoding of
+   IPv4 and IPv6 addresses, these record types can also be used in a
+   name chaining attack.
+
+   The general form of a name chaining attack is something like this:
+
+   - Victim issues a query, perhaps at the instigation of the attacker
+     or some third party; in some cases the query itself may be
+     unrelated to the name under attack (that is, the attacker is just
+     using this query as a means to inject false information about some
+     other name).
+
+
+
+
+Atkins & Austein             Informational                      [Page 5]
+
+RFC 3833                  DNS Threat Analysis                August 2004
+
+
+   - Attacker injects response, whether via packet interception, query
+     guessing, or by being a legitimate name server that's involved at
+     some point in the process of answering the query that the victim
+     issued.
+
+   - Attacker's response includes one or more RRs with DNS names in
+     their RDATA; depending on which particular form this attack takes,
+     the object may be to inject false data associated with those names
+     into the victim's cache via the Additional section of this
+     response, or may be to redirect the next stage of the query to a
+     server of the attacker's choosing (in order to inject more complex
+     lies into the victim's cache than will fit easily into a single
+     response, or in order to place the lies in the Authority or Answer
+     section of a response where they will have a better chance of
+     sneaking past a resolver's defenses).
+
+   Any attacker who can insert resource records into a victim's cache
+   can almost certainly do some kind of damage, so there are cache
+   poisoning attacks which are not name chaining attacks in the sense
+   discussed here.  However, in the case of name chaining attacks, the
+   cause and effect relationship between the initial attack and the
+   eventual result may be significantly more complex than in the other
+   forms of cache poisoning, so name chaining attacks merit special
+   attention.
+
+   The common thread in all of the name chaining attacks is that
+   response messages allow the attacker to introduce arbitrary DNS names
+   of the attacker's choosing and provide further information that the
+   attacker claims is associated with those names; unless the victim has
+   better knowledge of the data associated with those names, the victim
+   is going to have a hard time defending against this class of attacks.
+
+   This class of attack is particularly insidious given that it's quite
+   easy for an attacker to provoke a victim into querying for a
+   particular name of the attacker's choosing, for example, by embedding
+   a link to a 1x1-pixel "web bug" graphic in a piece of Text/HTML mail
+   to the victim.  If the victim's mail reading program attempts to
+   follow such a link, the result will be a DNS query for a name chosen
+   by the attacker.
+
+   DNSSEC should provide a good defense against most (all?) variations
+   on this class of attack.  By checking signatures, a resolver can
+   determine whether the data associated with a name really was inserted
+   by the delegated authority for that portion of the DNS name space.
+   More precisely, a resolver can determine whether the entity that
+   injected the data had access to an allegedly secret key whose
+
+
+
+
+
+Atkins & Austein             Informational                      [Page 6]
+
+RFC 3833                  DNS Threat Analysis                August 2004
+
+
+   corresponding public key appears at an expected location in the DNS
+   name space with an expected chain of parental signatures that start
+   with a public key of which the resolver has prior knowledge.
+
+   DNSSEC signatures do not cover glue records, so there's still a
+   possibility of a name chaining attack involving glue, but with DNSSEC
+   it is possible to detect the attack by temporarily accepting the glue
+   in order to fetch the signed authoritative version of the same data,
+   then checking the signatures on the authoritative version.
+
+2.4.  Betrayal By Trusted Server
+
+   Another variation on the packet interception attack is the trusted
+   server that turns out not to be so trustworthy, whether by accident
+   or by intent.  Many client machines are only configured with stub
+   resolvers, and use trusted servers to perform all of their DNS
+   queries on their behalf.  In many cases the trusted server is
+   furnished by the user's ISP and advertised to the client via DHCP or
+   PPP options.  Besides accidental betrayal of this trust relationship
+   (via server bugs, successful server break-ins, etc), the server
+   itself may be configured to give back answers that are not what the
+   user would expect, whether in an honest attempt to help the user or
+   to promote some other goal such as furthering a business partnership
+   between the ISP and some third party.
+
+   This problem is particularly acute for frequent travelers who carry
+   their own equipment and expect it to work in much the same way
+   wherever they go.  Such travelers need trustworthy DNS service
+   without regard to who operates the network into which their equipment
+   is currently plugged or what brand of middle boxes the local
+   infrastructure might use.
+
+   While the obvious solution to this problem would be for the client to
+   choose a more trustworthy server, in practice this may not be an
+   option for the client.  In many network environments a client machine
+   has only a limited set of recursive name servers from which to
+   choose, and none of them may be particularly trustworthy.  In extreme
+   cases, port filtering or other forms of packet interception may
+   prevent the client host from being able to run an iterative resolver
+   even if the owner of the client machine is willing and able to do so.
+   Thus, while the initial source of this problem is not a DNS protocol
+   attack per se, this sort of betrayal is a threat to DNS clients, and
+   simply switching to a different recursive name server is not an
+   adequate defense.
+
+   Viewed strictly from the DNS protocol standpoint, the only difference
+   between this sort of betrayal and a packet interception attack is
+   that in this case the client has voluntarily sent its request to the
+
+
+
+Atkins & Austein             Informational                      [Page 7]
+
+RFC 3833                  DNS Threat Analysis                August 2004
+
+
+   attacker.  The defense against this is the same as with a packet
+   interception attack: the resolver must either check DNSSEC signatures
+   itself or use TSIG (or equivalent) to authenticate the server that it
+   has chosen to trust.  Note that use of TSIG does not by itself
+   guarantee that a name server is at all trustworthy: all TSIG can do
+   is help a resolver protect its communication with a name server that
+   it has already decided to trust for other reasons.  Protecting a
+   resolver's communication with a server that's giving out bogus
+   answers is not particularly useful.
+
+   Also note that if the stub resolver does not trust the name server
+   that is doing work on its behalf and wants to check the DNSSEC
+   signatures itself, the resolver really does need to have independent
+   knowledge of the DNSSEC public key(s) it needs in order to perform
+   the check.  Usually the public key for the root zone is enough, but
+   in some cases knowledge of additional keys may also be appropriate.
+
+   It is difficult to escape the conclusion that a properly paranoid
+   resolver must always perform its own signature checking, and that
+   this rule even applies to stub resolvers.
+
+2.5.  Denial of Service
+
+   As with any network service (or, indeed, almost any service of any
+   kind in any domain of discourse), DNS is vulnerable to denial of
+   service attacks.  DNSSEC does not help this, and may in fact make the
+   problem worse for resolvers that check signatures, since checking
+   signatures both increases the processing cost per DNS message and in
+   some cases can also increase the number of messages needed to answer
+   a query.  TSIG (and similar mechanisms) have equivalent problems.
+
+   DNS servers are also at risk of being used as denial of service
+   amplifiers, since DNS response packets tend to be significantly
+   longer than DNS query packets.  Unsurprisingly, DNSSEC doesn't help
+   here either.
+
+2.6.  Authenticated Denial of Domain Names
+
+   Much discussion has taken place over the question of authenticated
+   denial of domain names.  The particular question is whether there is
+   a requirement for authenticating the non-existence of a name.  The
+   issue is whether the resolver should be able to detect when an
+   attacker removes RRs from a response.
+
+   General paranoia aside, the existence of RR types whose absence
+   causes an action other than immediate failure (such as missing MX and
+   SRV RRs, which fail over to A RRs) constitutes a real threat.
+   Arguably, in some cases, even the absence of an RR might be
+
+
+
+Atkins & Austein             Informational                      [Page 8]
+
+RFC 3833                  DNS Threat Analysis                August 2004
+
+
+   considered a problem.  The question remains: how serious is this
+   threat?  Clearly the threat does exist; general paranoia says that
+   some day it'll be on the front page of some major newspaper, even if
+   we cannot conceive of a plausible scenario involving this attack
+   today.  This implies that some mitigation of this risk is required.
+
+   Note that it's necessary to prove the non-existence of applicable
+   wildcard RRs as part of the authenticated denial mechanism, and that,
+   in a zone that is more than one label deep, such a proof may require
+   proving the non-existence of multiple discrete sets of wildcard RRs.
+
+   DNSSEC does include mechanisms which make it possible to determine
+   which authoritative names exist in a zone, and which authoritative
+   resource record types exist at those names.  The DNSSEC protections
+   do not cover non-authoritative data such as glue records.
+
+2.7.  Wildcards
+
+   Much discussion has taken place over whether and how to provide data
+   integrity and data origin authentication for "wildcard" DNS names.
+   Conceptually, RRs with wildcard names are patterns for synthesizing
+   RRs on the fly according to the matching rules described in section
+   4.3.2 of RFC 1034.  While the rules that control the behavior of
+   wildcard names have a few quirks that can make them a trap for the
+   unwary zone administrator, it's clear that a number of sites make
+   heavy use of wildcard RRs, particularly wildcard MX RRs.
+
+   In order to provide the desired services for wildcard RRs, we need to
+   do two things:
+
+   - We need a way to attest to the existence of the wildcard RR itself
+     (that is, we need to show that the synthesis rule exists), and
+
+   - We need a way to attest to the non-existence of any RRs which, if
+     they existed, would make the wildcard RR irrelevant according to
+     the synthesis rules that govern the way in which wildcard RRs are
+     used (that is, we need to show that the synthesis rule is
+     applicable).
+
+   Note that this makes the wildcard mechanisms dependent upon the
+   authenticated denial mechanism described in the previous section.
+
+   DNSSEC includes mechanisms along the lines described above, which
+   make it possible for a resolver to verify that a name server applied
+   the wildcard expansion rules correctly when generating an answer.
+
+
+
+
+
+
+Atkins & Austein             Informational                      [Page 9]
+
+RFC 3833                  DNS Threat Analysis                August 2004
+
+
+3.  Weaknesses of DNSSEC
+
+   DNSSEC has some problems of its own:
+
+   - DNSSEC is complex to implement and includes some nasty edge cases
+     at the zone cuts that require very careful coding.  Testbed
+     experience to date suggests that trivial zone configuration errors
+     or expired keys can cause serious problems for a DNSSEC-aware
+     resolver, and that the current protocol's error reporting
+     capabilities may leave something to be desired.
+
+   - DNSSEC significantly increases the size of DNS response packets;
+     among other issues, this makes DNSSEC-aware DNS servers even more
+     effective as denial of service amplifiers.
+
+   - DNSSEC answer validation increases the resolver's work load, since
+     a DNSSEC-aware resolver will need to perform signature validation
+     and in some cases will also need to issue further queries.  This
+     increased workload will also increase the time it takes to get an
+     answer back to the original DNS client, which is likely to trigger
+     both timeouts and re-queries in some cases.  Arguably, many current
+     DNS clients are already too impatient even before taking the
+     further delays that DNSSEC will impose into account, but that topic
+     is beyond the scope of this note.
+
+   - Like DNS itself, DNSSEC's trust model is almost totally
+     hierarchical.  While DNSSEC does allow resolvers to have special
+     additional knowledge of public keys beyond those for the root, in
+     the general case the root key is the one that matters.  Thus any
+     compromise in any of the zones between the root and a particular
+     target name can damage DNSSEC's ability to protect the integrity of
+     data owned by that target name.  This is not a change, since
+     insecure DNS has the same model.
+
+   - Key rollover at the root is really hard.  Work to date has not even
+     come close to adequately specifying how the root key rolls over, or
+     even how it's configured in the first place.
+
+   - DNSSEC creates a requirement of loose time synchronization between
+     the validating resolver and the entity creating the DNSSEC
+     signatures.  Prior to DNSSEC, all time-related actions in DNS could
+     be performed by a machine that only knew about "elapsed" or
+     "relative" time.  Because the validity period of a DNSSEC signature
+     is based on "absolute" time, a validating resolver must have the
+     same concept of absolute time as the zone signer in order to
+     determine whether the signature is within its validity period or
+     has expired.  An attacker that can change a resolver's opinion of
+     the current absolute time can fool the resolver using expired
+
+
+
+Atkins & Austein             Informational                     [Page 10]
+
+RFC 3833                  DNS Threat Analysis                August 2004
+
+
+     signatures.  An attacker that can change the zone signer's opinion
+     of the current absolute time can fool the zone signer into
+     generating signatures whose validity period does not match what the
+     signer intended.
+
+   - The possible existence of wildcard RRs in a zone complicates the
+     authenticated denial mechanism considerably.  For most of the
+     decade that DNSSEC has been under development these issues were
+     poorly understood.  At various times there have been questions as
+     to whether the authenticated denial mechanism is completely
+     airtight and whether it would be worthwhile to optimize the
+     authenticated denial mechanism for the common case in which
+     wildcards are not present in a zone.  However, the main problem is
+     just the inherent complexity of the wildcard mechanism itself.
+     This complexity probably makes the code for generating and checking
+     authenticated denial attestations somewhat fragile, but since the
+     alternative of giving up wildcards entirely is not practical due to
+     widespread use, we are going to have to live with wildcards. The
+     question just becomes one of whether or not the proposed
+     optimizations would make DNSSEC's mechanisms more or less fragile.
+
+   - Even with DNSSEC, the class of attacks discussed in section 2.4 is
+     not easy to defeat.  In order for DNSSEC to be effective in this
+     case, it must be possible to configure the resolver to expect
+     certain categories of DNS records to be signed.  This may require
+     manual configuration of the resolver, especially during the initial
+     DNSSEC rollout period when the resolver cannot reasonably expect
+     the root and TLD zones to be signed.
+
+4.  Topics for Future Work
+
+   This section lists a few subjects not covered above which probably
+   need additional study, additional mechanisms, or both.
+
+4.1.  Interactions With Other Protocols
+
+   The above discussion has concentrated exclusively on attacks within
+   the boundaries of the DNS protocol itself, since those are (some of)
+   the problems against which DNSSEC was intended to protect.  There
+   are, however, other potential problems at the boundaries where DNS
+   interacts with other protocols.
+
+4.2.  Securing DNS Dynamic Update
+
+   DNS dynamic update opens a number of potential problems when combined
+   with DNSSEC.  Dynamic update of a non-secure zone can use TSIG to
+   authenticate the updating client to the server.  While TSIG does not
+   scale very well (it requires manual configuration of shared keys
+
+
+
+Atkins & Austein             Informational                     [Page 11]
+
+RFC 3833                  DNS Threat Analysis                August 2004
+
+
+   between the DNS name server and each TSIG client), it works well in a
+   limited or closed environment such as a DHCP server updating a local
+   DNS name server.
+
+   Major issues arise when trying to use dynamic update on a secure
+   zone.  TSIG can similarly be used in a limited fashion to
+   authenticate the client to the server, but TSIG only protects DNS
+   transactions, not the actual data, and the TSIG is not inserted into
+   the DNS zone, so resolvers cannot use the TSIG as a way of verifying
+   the changes to the zone.  This means that either:
+
+   a) The updating client must have access to a zone-signing key in
+      order to sign the update before sending it to the server, or
+
+   b) The DNS name server must have access to an online zone-signing key
+      in order to sign the update.
+
+   In either case, a zone-signing key must be available to create signed
+   RRsets to place in the updated zone.  The fact that this key must be
+   online (or at least available) is a potential security risk.
+
+   Dynamic update also requires an update to the SERIAL field of the
+   zone's SOA RR.  In theory, this could also be handled via either of
+   the above options, but in practice (a) would almost certainly be
+   extremely fragile, so (b) is the only workable mechanism.
+
+   There are other threats in terms of describing the policy of who can
+   make what changes to which RRsets in the zone.  The current access
+   control scheme in Secure Dynamic Update is fairly limited.  There is
+   no way to give fine-grained access to updating DNS zone information
+   to multiple entities, each of whom may require different kinds of
+   access.  For example, Alice may need to be able to add new nodes to
+   the zone or change existing nodes, but not remove them; Bob may need
+   to be able to remove zones but not add them; Carol may need to be
+   able to add, remove, or modify nodes, but only A records.
+
+   Scaling properties of the key management problem here are a
+   particular concern that needs more study.
+
+4.3.  Securing DNS Zone Replication
+
+   As discussed in previous sections, DNSSEC per se attempts to provide
+   data integrity and data origin authentication services on top of the
+   normal DNS query protocol.  Using the terminology discussed in
+   [RFC3552], DNSSEC provides "object security" for the normal DNS query
+   protocol.  For purposes of replicating entire DNS zones, however,
+   DNSSEC does not provide object security, because zones include
+   unsigned NS RRs and glue at delegation points.  Use of TSIG to
+
+
+
+Atkins & Austein             Informational                     [Page 12]
+
+RFC 3833                  DNS Threat Analysis                August 2004
+
+
+   protect zone transfer (AXFR or IXFR) operations provides "channel
+   security", but still does not provide object security for complete
+   zones. The trust relationships involved in zone transfer are still
+   very much a hop-by-hop matter of name server operators trusting other
+   name server operators rather than an end-to-end matter of name server
+   operators trusting zone administrators.
+
+   Zone object security was not an explicit design goal of DNSSEC, so
+   failure to provide this service should not be a surprise.
+   Nevertheless, there are some zone replication scenarios for which
+   this would be a very useful additional service, so this seems like a
+   useful area for future work.  In theory it should not be difficult to
+   add zone object security as a backwards compatible enhancement to the
+   existing DNSSEC model, but the DNSEXT WG has not yet discussed either
+   the desirability of or the requirements for such an enhancement.
+
+5.  Conclusion
+
+   Based on the above analysis, the DNSSEC extensions do appear to solve
+   a set of problems that do need to be solved, and are worth deploying.
+
+Security Considerations
+
+   This entire document is about security considerations of the DNS.
+   The authors believe that deploying DNSSEC will help to address some,
+   but not all, of the known threats to the DNS.
+
+Acknowledgments
+
+   This note is based both on previous published works by others and on
+   a number of discussions both public and private over a period of many
+   years, but particular thanks go to
+
+   Jaap Akkerhuis,
+   Steve Bellovin,
+   Dan Bernstein,
+   Randy Bush,
+   Steve Crocker,
+   Olafur Gudmundsson,
+   Russ Housley,
+   Rip Loomis,
+   Allison Mankin,
+   Paul Mockapetris,
+   Thomas Narten
+   Mans Nilsson,
+   Pekka Savola,
+   Paul Vixie,
+   Xunhua Wang,
+
+
+
+Atkins & Austein             Informational                     [Page 13]
+
+RFC 3833                  DNS Threat Analysis                August 2004
+
+
+   and any other members of the DNS, DNSSEC, DNSIND, and DNSEXT working
+   groups whose names and contributions the authors have forgotten, none
+   of whom are responsible for what the authors did with their ideas.
+
+   As with any work of this nature, the authors of this note acknowledge
+   that we are standing on the toes of those who have gone before us.
+   Readers interested in this subject may also wish to read
+   [Bellovin95], [Schuba93], and [Vixie95].
+
+Normative References
+
+   [RFC1034]    Mockapetris, P., "Domain names - concepts and
+                facilities", STD 13, RFC 1034, November 1987.
+
+   [RFC1035]    Mockapetris, P., "Domain names - implementation and
+                specification", STD 13, RFC 1035, November 1987.
+
+   [RFC1123]    Braden, R., "Requirements for Internet Hosts -
+                Application and Support", STD 3, RFC 1123, October 1989.
+
+   [RFC2181]    Elz, R. and R. Bush, "Clarifications to the DNS
+                Specification", RFC 2181, July 1997.
+
+   [RFC2308]    Andrews, M., "Negative Caching of DNS Queries (DNS
+                NCACHE)", RFC 2308, March 1998.
+
+   [RFC2671]    Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
+                2671, August 1999.
+
+   [RFC2845]    Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.
+                Wellington, "Secret Key Transaction Authentication for
+                DNS (TSIG)", RFC 2845, May 2000.
+
+   [RFC2930]    Eastlake 3rd, D., "Secret Key Establishment for DNS
+                (TKEY RR)", RFC 2930, September 2000.
+
+   [RFC3007]    Wellington, B., "Secure Domain Name System (DNS) Dynamic
+                Update", RFC 3007, November 2000.
+
+   [RFC2535]    Eastlake 3rd, D., "Domain Name System Security
+                Extensions", RFC 2535, March 1999.
+
+
+
+
+
+
+
+
+
+
+Atkins & Austein             Informational                     [Page 14]
+
+RFC 3833                  DNS Threat Analysis                August 2004
+
+
+Informative References
+
+   [RFC3552]    Rescorla, E. and B. Korver, "Guidelines for Writing RFC
+                Text on Security Considerations", BCP 72, RFC 3552, July
+                2003.
+
+   [Bellovin95] Bellovin, S., "Using the Domain Name System for System
+                Break-Ins", Proceedings of the Fifth Usenix Unix
+                Security Symposium, June 1995.
+
+   [Galvin93]   Design team meeting summary message posted to dns-
+                security@tis.com mailing list by Jim Galvin on 19
+                November 1993.
+
+   [Schuba93]   Schuba, C., "Addressing Weaknesses in the Domain Name
+                System Protocol", Master's thesis, Purdue University
+                Department of Computer Sciences,  August 1993.
+
+   [Vixie95]    Vixie, P, "DNS and BIND Security Issues", Proceedings of
+                the Fifth Usenix Unix Security Symposium, June 1995.
+
+Authors' Addresses
+
+   Derek Atkins
+   IHTFP Consulting, Inc.
+   6 Farragut Ave
+   Somerville, MA  02144
+   USA
+
+   EMail: derek@ihtfp.com
+
+
+   Rob Austein
+   Internet Systems Consortium
+   950 Charter Street
+   Redwood City, CA 94063
+   USA
+
+   EMail: sra@isc.org
+
+
+
+
+
+
+
+
+
+
+
+
+Atkins & Austein             Informational                     [Page 15]
+
+RFC 3833                  DNS Threat Analysis                August 2004
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2004).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at ietf-
+   ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+Atkins & Austein             Informational                     [Page 16]
+
diff --git a/doc/rfc/rfc3845.txt b/doc/rfc/rfc3845.txt
new file mode 100644
index 0000000..9887a20
--- /dev/null
+++ b/doc/rfc/rfc3845.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+Network Working Group                                   J. Schlyter, Ed.
+Request for Comments: 3845                                   August 2004
+Updates: 3755, 2535
+Category: Standards Track
+
+
+          DNS Security (DNSSEC) NextSECure (NSEC) RDATA Format
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2004).
+
+Abstract
+
+   This document redefines the wire format of the "Type Bit Map" field
+   in the DNS NextSECure (NSEC) resource record RDATA format to cover
+   the full resource record (RR) type space.
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
+   2.  The NSEC Resource Record . . . . . . . . . . . . . . . . . . .  2
+       2.1.  NSEC RDATA Wire Format . . . . . . . . . . . . . . . . .  3
+             2.1.1.  The Next Domain Name Field . . . . . . . . . . .  3
+             2.1.2.  The List of Type Bit Map(s) Field  . . . . . . .  3
+             2.1.3.  Inclusion of Wildcard Names in NSEC RDATA  . . .  4
+       2.2.  The NSEC RR Presentation Format  . . . . . . . . . . . .  4
+       2.3.  NSEC RR Example  . . . . . . . . . . . . . . . . . . . .  5
+   3.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  5
+   4.  Security Considerations  . . . . . . . . . . . . . . . . . . .  5
+   5.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  6
+       5.1.  Normative References . . . . . . . . . . . . . . . . . .  6
+       5.2.  Informative References . . . . . . . . . . . . . . . . .  6
+   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  6
+   7.  Author's Address . . . . . . . . . . . . . . . . . . . . . . .  6
+   8.  Full Copyright Statement . . . . . . . . . . . . . . . . . . .  7
+
+
+
+
+
+
+
+Schlyter, Ed.               Standards Track                     [Page 1]
+
+RFC 3845                DNSSEC NSEC RDATA Format             August 2004
+
+
+1.  Introduction
+
+   The DNS [6][7] NSEC [5] Resource Record (RR) is used for
+   authenticated proof of the non-existence of DNS owner names and
+   types.  The NSEC RR is based on the NXT RR as described in RFC 2535
+   [2], and is similar except for the name and typecode.  The RDATA
+   format for the NXT RR has the limitation in that the RDATA could only
+   carry information about the existence of the first 127 types.  RFC
+   2535 did reserve a bit to specify an extension mechanism, but the
+   mechanism was never actually defined.
+
+   In order to avoid needing to develop an extension mechanism into a
+   deployed base of DNSSEC aware servers and resolvers once the first
+   127 type codes are allocated, this document redefines the wire format
+   of the "Type Bit Map" field in the NSEC RDATA to cover the full RR
+   type space.
+
+   This document introduces a new format for the type bit map.  The
+   properties of the type bit map format are that it can cover the full
+   possible range of typecodes, that it is relatively economical in the
+   amount of space it uses for the common case of a few types with an
+   owner name, that it can represent owner names with all possible types
+   present in packets of approximately 8.5 kilobytes, and that the
+   representation is simple to implement.  Efficient searching of the
+   type bitmap for the presence of certain types is not a requirement.
+
+   For convenience and completeness, this document presents the syntax
+   and semantics for the NSEC RR based on the specification in RFC 2535
+   [2] and as updated by RFC 3755 [5], thereby not introducing changes
+   except for the syntax of the type bit map.
+
+   This document updates RFC 2535 [2] and RFC 3755 [5].
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in BCP 14, RFC 2119 [1].
+
+2.  The NSEC Resource Record
+
+   The NSEC resource record lists two separate things: the owner name of
+   the next RRset in the canonical ordering of the zone, and the set of
+   RR types present at the NSEC RR's owner name.  The complete set of
+   NSEC RRs in a zone indicate which RRsets exist in a zone, and form a
+   chain of owner names in the zone.  This information is used to
+   provide authenticated denial of existence for DNS data, as described
+   in RFC 2535 [2].
+
+   The type value for the NSEC RR is 47.
+
+
+
+Schlyter, Ed.               Standards Track                     [Page 2]
+
+RFC 3845                DNSSEC NSEC RDATA Format             August 2004
+
+
+   The NSEC RR RDATA format is class independent and defined for all
+   classes.
+
+   The NSEC RR SHOULD have the same TTL value as the SOA minimum TTL
+   field.  This is in the spirit of negative caching [8].
+
+2.1.  NSEC RDATA Wire Format
+
+   The RDATA of the NSEC RR is as shown below:
+
+                         1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
+     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    /                      Next Domain Name                         /
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    /                   List of Type Bit Map(s)                     /
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+2.1.1.  The Next Domain Name Field
+
+   The Next Domain Name field contains the owner name of the next RR in
+   the canonical ordering of the zone.  The value of the Next Domain
+   Name field in the last NSEC record in the zone is the name of the
+   zone apex (the owner name of the zone's SOA RR).
+
+   A sender MUST NOT use DNS name compression on the Next Domain Name
+   field when transmitting an NSEC RR.
+
+   Owner names of RRsets that are not authoritative for the given zone
+   (such as glue records) MUST NOT be listed in the Next Domain Name
+   unless at least one authoritative RRset exists at the same owner
+   name.
+
+2.1.2.  The List of Type Bit Map(s) Field
+
+   The RR type space is split into 256 window blocks, each representing
+   the low-order 8 bits of the 16-bit RR type space.  Each block that
+   has at least one active RR type is encoded using a single octet
+   window number (from 0 to 255), a single octet bitmap length (from 1
+   to 32) indicating the number of octets used for the window block's
+   bitmap, and up to 32 octets (256 bits) of bitmap.
+
+   Window blocks are present in the NSEC RR RDATA in increasing
+   numerical order.
+
+   "|" denotes concatenation
+
+   Type Bit Map(s) Field = ( Window Block # | Bitmap Length | Bitmap ) +
+
+
+
+Schlyter, Ed.               Standards Track                     [Page 3]
+
+RFC 3845                DNSSEC NSEC RDATA Format             August 2004
+
+
+   Each bitmap encodes the low-order 8 bits of RR types within the
+   window block, in network bit order.  The first bit is bit 0.  For
+   window block 0, bit 1 corresponds to RR type 1 (A), bit 2 corresponds
+   to RR type 2 (NS), and so forth.  For window block 1, bit 1
+   corresponds to RR type 257, and bit 2 to RR type 258.  If a bit is
+   set to 1, it indicates that an RRset of that type is present for the
+   NSEC RR's owner name.  If a bit is set to 0, it indicates that no
+   RRset of that type is present for the NSEC RR's owner name.
+
+   Since bit 0 in window block 0 refers to the non-existing RR type 0,
+   it MUST be set to 0.  After verification, the validator MUST ignore
+   the value of bit 0 in window block 0.
+
+   Bits representing Meta-TYPEs or QTYPEs, as specified in RFC 2929 [3]
+   (section 3.1), or within the range reserved for assignment only to
+   QTYPEs and Meta-TYPEs MUST be set to 0, since they do not appear in
+   zone data.  If encountered, they must be ignored upon reading.
+
+   Blocks with no types present MUST NOT be included.  Trailing zero
+   octets in the bitmap MUST be omitted.  The length of each block's
+   bitmap is determined by the type code with the largest numerical
+   value within that block, among the set of RR types present at the
+   NSEC RR's owner name.  Trailing zero octets not specified MUST be
+   interpreted as zero octets.
+
+2.1.3.  Inclusion of Wildcard Names in NSEC RDATA
+
+   If a wildcard owner name appears in a zone, the wildcard label ("*")
+   is treated as a literal symbol and is treated the same as any other
+   owner name for purposes of generating NSEC RRs.  Wildcard owner names
+   appear in the Next Domain Name field without any wildcard expansion.
+   RFC 2535 [2] describes the impact of wildcards on authenticated
+   denial of existence.
+
+2.2.  The NSEC RR Presentation Format
+
+   The presentation format of the RDATA portion is as follows:
+
+   The Next Domain Name field is represented as a domain name.
+
+   The List of Type Bit Map(s) Field is represented as a sequence of RR
+   type mnemonics.  When the mnemonic is not known, the TYPE
+   representation as described in RFC 3597 [4] (section 5) MUST be used.
+
+
+
+
+
+
+
+
+Schlyter, Ed.               Standards Track                     [Page 4]
+
+RFC 3845                DNSSEC NSEC RDATA Format             August 2004
+
+
+2.3.  NSEC RR Example
+
+   The following NSEC RR identifies the RRsets associated with
+   alfa.example.com. and the next authoritative name after
+   alfa.example.com.
+
+   alfa.example.com. 86400 IN NSEC host.example.com. A MX RRSIG NSEC
+   TYPE1234
+
+   The first four text fields specify the name, TTL, Class, and RR type
+   (NSEC).  The entry host.example.com. is the next authoritative name
+   after alfa.example.com. in canonical order.  The A, MX, RRSIG, NSEC,
+   and TYPE1234 mnemonics indicate there are A, MX, RRSIG, NSEC, and
+   TYPE1234 RRsets associated with the name alfa.example.com.
+
+   The RDATA section of the NSEC RR above would be encoded as:
+
+      0x04 'h'  'o'  's'  't'
+      0x07 'e'  'x'  'a'  'm'  'p'  'l'  'e'
+      0x03 'c'  'o'  'm'  0x00
+      0x00 0x06 0x40 0x01 0x00 0x00 0x00 0x03
+      0x04 0x1b 0x00 0x00 0x00 0x00 0x00 0x00
+      0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
+      0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
+      0x00 0x00 0x00 0x00 0x20
+
+   Assuming that the resolver can authenticate this NSEC record, it
+   could be used to prove that beta.example.com does not exist, or could
+   be used to prove that there is no AAAA record associated with
+   alfa.example.com.  Authenticated denial of existence is discussed in
+   RFC 2535 [2].
+
+3.  IANA Considerations
+
+   This document introduces no new IANA considerations, because all of
+   the protocol parameters used in this document have already been
+   assigned by RFC 3755 [5].
+
+4.  Security Considerations
+
+   The update of the RDATA format and encoding does not affect the
+   security of the use of NSEC RRs.
+
+
+
+
+
+
+
+
+
+Schlyter, Ed.               Standards Track                     [Page 5]
+
+RFC 3845                DNSSEC NSEC RDATA Format             August 2004
+
+
+5.  References
+
+5.1.  Normative References
+
+   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
+        Levels", BCP 14, RFC 2119, March 1997.
+
+   [2]  Eastlake 3rd, D., "Domain Name System Security Extensions", RFC
+        2535, March 1999.
+
+   [3]  Eastlake 3rd, D., Brunner-Williams, E., and B. Manning, "Domain
+        Name System (DNS) IANA Considerations", BCP 42, RFC 2929,
+        September 2000.
+
+   [4]  Gustafsson, A., "Handling of Unknown DNS Resource Record (RR)
+        Types", RFC 3597, September 2003.
+
+   [5]  Weiler, S., "Legacy Resolver Compatibility for Delegation Signer
+        (DS)", RFC 3755, May 2004.
+
+5.2.  Informative References
+
+   [6]  Mockapetris, P., "Domain names - concepts and facilities", STD
+        13, RFC 1034, November 1987.
+
+   [7]  Mockapetris, P., "Domain names - implementation and
+        specification", STD 13, RFC 1035, November 1987.
+
+   [8]  Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC
+        2308, March 1998.
+
+6.  Acknowledgements
+
+   The encoding described in this document was initially proposed by
+   Mark Andrews.  Other encodings where proposed by David Blacka and
+   Michael Graff.
+
+7.  Author's Address
+
+   Jakob Schlyter (editor)
+   NIC-SE
+   Box 5774
+   Stockholm  SE-114 87
+   Sweden
+
+   EMail: jakob@nic.se
+   URI: http://www.nic.se/
+
+
+
+
+Schlyter, Ed.               Standards Track                     [Page 6]
+
+RFC 3845                DNSSEC NSEC RDATA Format             August 2004
+
+
+8.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2004).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/S HE
+   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
+   INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the IETF's procedures with respect to rights in IETF Documents can
+   be found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at ietf-
+   ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+Schlyter, Ed.               Standards Track                     [Page 7]
+
diff --git a/doc/rfc/rfc3901.txt b/doc/rfc/rfc3901.txt
new file mode 100644
index 0000000..43b7356
--- /dev/null
+++ b/doc/rfc/rfc3901.txt
@@ -0,0 +1,283 @@
+
+
+
+
+
+
+Network Working Group                                          A. Durand
+Request for Comments: 3901                        SUN Microsystems, Inc.
+BCP: 91                                                         J. Ihren
+Category: Best Current Practice                               Autonomica
+                                                          September 2004
+
+
+               DNS IPv6 Transport Operational Guidelines
+
+Status of this Memo
+
+   This document specifies an Internet Best Current Practices for the
+   Internet Community, and requests discussion and suggestions for
+   improvements.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2004).
+
+Abstract
+
+   This memo provides guidelines and Best Current Practice for operating
+   DNS in a world where queries and responses are carried in a mixed
+   environment of IPv4 and IPv6 networks.
+
+1.  Introduction to the Problem of Name Space Fragmentation:
+    following the referral chain
+
+   A resolver that tries to look up a name starts out at the root, and
+   follows referrals until it is referred to a name server that is
+   authoritative for the name.  If somewhere down the chain of referrals
+   it is referred to a name server that is only accessible over a
+   transport which the resolver cannot use, the resolver is unable to
+   finish the task.
+
+   When the Internet moves from IPv4 to a mixture of IPv4 and IPv6 it is
+   only a matter of time until this starts to happen.  The complete DNS
+   hierarchy then starts to fragment into a graph where authoritative
+   name servers for certain nodes are only accessible over a certain
+   transport.  The concern is that a resolver using only a particular
+   version of IP and querying information about another node using the
+   same version of IP can not do it because somewhere in the chain of
+   servers accessed during the resolution process, one or more of them
+   will only be accessible with the other version of IP.
+
+   With all DNS data only available over IPv4 transport everything is
+   simple.  IPv4 resolvers can use the intended mechanism of following
+   referrals from the root and down while IPv6 resolvers have to work
+
+
+
+Durand & Ihren           Best Current Practice                  [Page 1]
+
+RFC 3901             DNS IPv6 Transport Guidelines        September 2004
+
+
+   through a "translator", i.e., they have to use a recursive name
+   server on a so-called "dual stack" host as a "forwarder" since they
+   cannot access the DNS data directly.
+
+   With all DNS data only available over IPv6 transport everything would
+   be equally simple, with the exception of IPv4 recursive name servers
+   having to switch to a forwarding configuration.
+
+   However, the second situation will not arise in the foreseeable
+   future.  Instead, the transition will be from IPv4 only to a mixture
+   of IPv4 and IPv6, with three categories of DNS data depending on
+   whether the information is available only over IPv4 transport, only
+   over IPv6 or both.
+
+   Having DNS data available on both transports is the best situation.
+   The major question is how to ensure that it becomes the norm as
+   quickly as possible.  However, while it is obvious that some DNS data
+   will only be available over v4 transport for a long time it is also
+   obvious that it is important to avoid fragmenting the name space
+   available to IPv4 only hosts.  For example, during transition it is
+   not acceptable to break the name space that we presently have
+   available for IPv4-only hosts.
+
+2.  Terminology
+
+   The phrase "IPv4 name server" indicates a name server available over
+   IPv4 transport.  It does not imply anything about what DNS [1,2] data
+   is served.  Likewise, "IPv6 [4,5,6] name server" indicates a name
+   server available over IPv6 transport.  The phrase "dual-stack name
+   server" indicates a name server that is actually configured to run
+   both protocols, IPv4 and IPv6, and not merely a server running on a
+   system capable of running both but actually configured to run only
+   one.
+
+3.  Policy Based Avoidance of Name Space Fragmentation
+
+   Today there are only a few DNS "zones" on the public Internet that
+   are available over IPv6 transport, and most of them can be regarded
+   as "experimental".  However, as soon as the root and top level
+   domains are available over IPv6 transport, it is reasonable to expect
+   that it will become more common to have zones served by IPv6 servers.
+
+   Having those zones served only by IPv6-only name server would not be
+   a good development, since this will fragment the previously
+   unfragmented IPv4 name space and there are strong reasons to find a
+   mechanism to avoid it.
+
+
+
+
+
+Durand & Ihren           Best Current Practice                  [Page 2]
+
+RFC 3901             DNS IPv6 Transport Guidelines        September 2004
+
+
+   The recommended approach to maintain name space continuity is to use
+   administrative policies, as described in the next section.
+
+4.  DNS IPv6 Transport recommended Guidelines
+
+   In order to preserve name space continuity, the following
+   administrative policies are recommended:
+
+      - every recursive name server SHOULD be either IPv4-only or dual
+        stack,
+
+         This rules out IPv6-only recursive servers.  However, one might
+         design configurations where a chain of IPv6-only name server
+         forward queries to a set of dual stack recursive name server
+         actually performing those recursive queries.
+
+      - every DNS zone SHOULD be served by at least one IPv4-reachable
+        authoritative name server.
+
+         This rules out DNS zones served only by IPv6-only authoritative
+         name servers.
+
+   Note: zone validation processes SHOULD ensure that there is at least
+   one IPv4 address record available for the name servers of any child
+   delegations within the zone.
+
+5.  Security Considerations
+
+   The guidelines described in this memo introduce no new security
+   considerations into the DNS protocol or associated operational
+   scenarios.
+
+6.  Acknowledgment
+
+   This document is the result of many conversations that happened in
+   the DNS community at IETF and elsewhere since 2001.  During that
+   period of time, a number of Internet drafts have been published to
+   clarify various aspects of the issues at stake.  This document
+   focuses on the conclusion of those discussions.
+
+   The authors would like to acknowledge the role of Pekka Savola in his
+   thorough review of the document.
+
+
+
+
+
+
+
+
+
+Durand & Ihren           Best Current Practice                  [Page 3]
+
+RFC 3901             DNS IPv6 Transport Guidelines        September 2004
+
+
+7.  Normative References
+
+   [1]  Mockapetris, P., "Domain names - concepts and facilities", STD
+        13, RFC 1034, November 1987.
+
+   [2]  Mockapetris, P., "Domain names - implementation and
+        specification", STD 13, RFC 1035, November 1987.
+
+   [3]  Bradner, S., "The Internet Standards Process -- Revision 3", BCP
+        9, RFC 2026, October 1996.
+
+   [4]  Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
+        Specification", RFC 2460, December 1998.
+
+   [5]  Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6)
+        Addressing Architecture", RFC 3513, April 2003.
+
+   [6]  Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, "DNS
+        Extensions to Support IP Version 6", RFC 3596, October 2003.
+
+8.  Authors' Addresses
+
+   Alain Durand
+   SUN Microsystems, Inc
+   17 Network circle UMPK17-202
+   Menlo Park, CA, 94025
+   USA
+
+   EMail: Alain.Durand@sun.com
+
+
+   Johan Ihren
+   Autonomica
+   Bellmansgatan 30
+   SE-118 47 Stockholm
+   Sweden
+
+   EMail: johani@autonomica.se
+
+
+
+
+
+
+
+
+
+
+
+
+
+Durand & Ihren           Best Current Practice                  [Page 4]
+
+RFC 3901             DNS IPv6 Transport Guidelines        September 2004
+
+
+9.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2004).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/S HE
+   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
+   INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the IETF's procedures with respect to rights in IETF Documents can
+   be found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at ietf-
+   ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+Durand & Ihren           Best Current Practice                  [Page 5]
+
diff --git a/doc/rfc/rfc4025.txt b/doc/rfc/rfc4025.txt
new file mode 100644
index 0000000..92e7f40
--- /dev/null
+++ b/doc/rfc/rfc4025.txt
@@ -0,0 +1,675 @@
+
+
+
+
+
+
+Network Working Group                                      M. Richardson
+Request for Comments: 4025                                           SSW
+Category: Standards Track                                   February 2005
+
+
+           A Method for Storing IPsec Keying Material in DNS
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).
+
+Abstract
+
+   This document describes a new resource record for the Domain Name
+   System (DNS).  This record may be used to store public keys for use
+   in IP security (IPsec) systems.  The record also includes provisions
+   for indicating what system should be contacted when an IPsec tunnel
+   is established with the entity in question.
+
+   This record replaces the functionality of the sub-type #4 of the KEY
+   Resource Record, which has been obsoleted by RFC 3445.
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
+       1.1.  Overview . . . . . . . . . . . . . . . . . . . . . . . .  2
+       1.2.  Use of DNS Address-to-Name Maps (IN-ADDR.ARPA and
+             IP6.ARPA)  . . . . . . . . . . . . . . . . . . . . . . .  3
+       1.3.  Usage Criteria . . . . . . . . . . . . . . . . . . . . .  3
+   2.  Storage Formats  . . . . . . . . . . . . . . . . . . . . . . .  3
+       2.1.  IPSECKEY RDATA Format  . . . . . . . . . . . . . . . . .  3
+       2.2.  RDATA Format - Precedence  . . . . . . . . . . . . . . .  4
+       2.3.  RDATA Format - Gateway Type  . . . . . . . . . . . . . .  4
+       2.4.  RDATA Format - Algorithm Type  . . . . . . . . . . . . .  4
+       2.5.  RDATA Format - Gateway . . . . . . . . . . . . . . . . .  5
+       2.6.  RDATA Format - Public Keys . . . . . . . . . . . . . . .  5
+   3.  Presentation Formats . . . . . . . . . . . . . . . . . . . . .  6
+       3.1.  Representation of IPSECKEY RRs . . . . . . . . . . . . .  6
+       3.2.  Examples . . . . . . . . . . . . . . . . . . . . . . . .  6
+   4.  Security Considerations  . . . . . . . . . . . . . . . . . . .  7
+
+
+
+Richardson                  Standards Track                     [Page 1]
+
+RFC 4025          Storing IPsec Keying Material in DNS     February 2005
+
+
+       4.1.  Active Attacks Against Unsecured IPSECKEY Resource
+             Records  . . . . . . . . . . . . . . . . . . . . . . . .  8
+             4.1.1.  Active Attacks Against IPSECKEY Keying
+                     Materials. . . . . . . . . . . . . . . . . . . .  8
+             4.1.2.  Active Attacks Against IPSECKEY Gateway
+                     Material. . . . . . . . . . . . . . . . . . . .   8
+   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
+   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
+   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
+       7.1.  Normative References . . . . . . . . . . . . . . . . . . 10
+       7.2.  Informative References . . . . . . . . . . . . . . . . . 10
+   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11
+   Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 12
+
+1.  Introduction
+
+   Suppose a host wishes (or is required by policy) to establish an
+   IPsec tunnel with some remote entity on the network prior to allowing
+   normal communication to take place.  In many cases, this end system
+   will be able to determine the DNS name for the remote entity (either
+   by having the DNS name given explicitly, by performing a DNS PTR
+   query for a particular IP address, or through some other means, e.g.,
+   by extracting the DNS portion of a "user@FQDN" name for a remote
+   entity).  In these cases, the host will need to obtain a public key
+   to authenticate the remote entity, and may also need some guidance
+   about whether it should contact the entity directly or use another
+   node as a gateway to the target entity.  The IPSECKEY RR provides a
+   mechanism for storing such information.
+
+   The type number for the IPSECKEY RR is 45.
+
+   This record replaces the functionality of the sub-type #4 of the KEY
+   Resource Record, which has been obsoleted by RFC 3445 [11].
+
+1.1.  Overview
+
+   The IPSECKEY resource record (RR) is used to publish a public key
+   that is to be associated with a Domain Name System (DNS) [1] name for
+   use with the IPsec protocol suite.  This can be the public key of a
+   host, network, or application (in the case of per-port keying).
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [3].
+
+
+
+
+
+
+
+Richardson                  Standards Track                     [Page 2]
+
+RFC 4025          Storing IPsec Keying Material in DNS     February 2005
+
+
+1.2.  Use of DNS Address-to-Name Maps (IN-ADDR.ARPA and IP6.ARPA)
+
+   Often a security gateway will only have access to the IP address of
+   the node with which communication is desired and will not know any
+   other name for the target node.  Because of this, frequently the best
+   way of looking up IPSECKEY RRs will be by using the IP address as an
+   index into one of the reverse mapping trees (IN-ADDR.ARPA for IPv4 or
+   IP6.ARPA for IPv6).
+
+   The lookup is done in the fashion usual for PTR records.  The IP
+   address' octets (IPv4) or nibbles (IPv6) are reversed and looked up
+   with the appropriate suffix.  Any CNAMEs or DNAMEs found MUST be
+   followed.
+
+   Note: even when the IPsec function is contained in the end-host,
+   often only the application will know the forward name used.  Although
+   the case where the application knows the forward name is common, the
+   user could easily have typed in a literal IP address.  This storage
+   mechanism does not preclude using the forward name when it is
+   available but does not require it.
+
+1.3.  Usage Criteria
+
+   An IPSECKEY resource record SHOULD be used in combination with DNSSEC
+   [8] unless some other means of authenticating the IPSECKEY resource
+   record is available.
+
+   It is expected that there will often be multiple IPSECKEY resource
+   records at the same name.  This will be due to the presence of
+   multiple gateways and a need to roll over keys.
+
+   This resource record is class independent.
+
+2.  Storage Formats
+
+2.1.  IPSECKEY RDATA Format
+
+   The RDATA for an IPSECKEY RR consists of a precedence value, a
+   gateway type, a public key, algorithm type, and an optional gateway
+   address.
+
+
+
+
+
+
+
+
+
+
+
+Richardson                  Standards Track                     [Page 3]
+
+RFC 4025          Storing IPsec Keying Material in DNS     February 2005
+
+
+       0                   1                   2                   3
+       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |  precedence   | gateway type  |  algorithm  |     gateway     |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------+                 +
+      ~                            gateway                            ~
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                                                               /
+      /                          public key                           /
+      /                                                               /
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
+
+2.2.  RDATA Format - Precedence
+
+   This is an 8-bit precedence for this record.  It is interpreted in
+   the same way as the PREFERENCE field described in section 3.3.9 of
+   RFC 1035 [2].
+
+   Gateways listed in IPSECKEY records with lower precedence are to be
+   attempted first.  Where there is a tie in precedence, the order
+   should be non-deterministic.
+
+2.3.  RDATA Format - Gateway Type
+
+   The gateway type field indicates the format of the information that
+   is stored in the gateway field.
+
+   The following values are defined:
+   0  No gateway is present.
+   1  A 4-byte IPv4 address is present.
+   2  A 16-byte IPv6 address is present.
+   3  A wire-encoded domain name is present.  The wire-encoded format is
+      self-describing, so the length is implicit.  The domain name MUST
+      NOT be compressed.  (See Section 3.3 of RFC 1035 [2].)
+
+2.4.  RDATA Format - Algorithm Type
+
+   The algorithm type field identifies the public key's cryptographic
+   algorithm and determines the format of the public key field.
+
+   A value of 0 indicates that no key is present.
+
+   The following values are defined:
+   1  A DSA key is present, in the format defined in RFC 2536 [9].
+   2  A RSA key is present, in the format defined in RFC 3110 [10].
+
+
+
+
+
+
+Richardson                  Standards Track                     [Page 4]
+
+RFC 4025          Storing IPsec Keying Material in DNS     February 2005
+
+
+2.5.  RDATA Format - Gateway
+
+   The gateway field indicates a gateway to which an IPsec tunnel may be
+   created in order to reach the entity named by this resource record.
+
+   There are three formats:
+
+   A 32-bit IPv4 address is present in the gateway field.  The data
+   portion is an IPv4 address as described in section 3.4.1 of RFC 1035
+   [2].  This is a 32-bit number in network byte order.
+
+   A 128-bit IPv6 address is present in the gateway field.  The data
+   portion is an IPv6 address as described in section 2.2 of RFC 3596
+   [12].  This is a 128-bit number in network byte order.
+
+   The gateway field is a normal wire-encoded domain name, as described
+   in section 3.3 of RFC 1035 [2].  Compression MUST NOT be used.
+
+2.6.  RDATA Format - Public Keys
+
+   Both the public key types defined in this document (RSA and DSA)
+   inherit their public key formats from the corresponding KEY RR
+   formats.  Specifically, the public key field contains the
+   algorithm-specific portion of the KEY RR RDATA, which is all the KEY
+   RR DATA after the first four octets.  This is the same portion of the
+   KEY RR that must be specified by documents that define a DNSSEC
+   algorithm.  Those documents also specify a message digest to be used
+   for generation of SIG RRs; that specification is not relevant for
+   IPSECKEY RRs.
+
+   Future algorithms, if they are to be used by both DNSSEC (in the KEY
+   RR) and IPSECKEY, are likely to use the same public key encodings in
+   both records.  Unless otherwise specified, the IPSECKEY public key
+   field will contain the algorithm-specific portion of the KEY RR RDATA
+   for the corresponding algorithm.  The algorithm must still be
+   designated for use by IPSECKEY, and an IPSECKEY algorithm type number
+   (which might be different from the DNSSEC algorithm number) must be
+   assigned to it.
+
+   The DSA key format is defined in RFC 2536 [9]
+
+   The RSA key format is defined in RFC 3110 [10], with the following
+   changes:
+
+   The earlier definition of RSA/MD5 in RFC 2065 [4] limited the
+   exponent and modulus to 2552 bits in length.  RFC 3110 extended that
+   limit to 4096 bits for RSA/SHA1 keys.  The IPSECKEY RR imposes no
+   length limit on RSA public keys, other than the 65535 octet limit
+
+
+
+Richardson                  Standards Track                     [Page 5]
+
+RFC 4025          Storing IPsec Keying Material in DNS     February 2005
+
+
+   imposed by the two-octet length encoding.  This length extension is
+   applicable only to IPSECKEY; it is not applicable to KEY RRs.
+
+3.  Presentation Formats
+
+3.1.  Representation of IPSECKEY RRs
+
+   IPSECKEY RRs may appear in a zone data master file.  The precedence,
+   gateway type, algorithm, and gateway fields are REQUIRED.  The base64
+   encoded public key block is OPTIONAL; if it is not present, the
+   public key field of the resource record MUST be construed to be zero
+   octets in length.
+
+   The algorithm field is an unsigned integer.  No mnemonics are
+   defined.
+
+   If no gateway is to be indicated, then the gateway type field MUST be
+   zero, and the gateway field MUST be "."
+
+   The Public Key field is represented as a Base64 encoding of the
+   Public Key.  Whitespace is allowed within the Base64 text.  For a
+   definition of Base64 encoding, see RFC 3548 [6], Section 5.2.
+
+   The general presentation for the record is as follows:
+
+   IN     IPSECKEY ( precedence gateway-type algorithm
+                     gateway base64-encoded-public-key )
+
+3.2.  Examples
+
+   An example of a node, 192.0.2.38, that will accept IPsec tunnels on
+   its own behalf.
+
+   38.2.0.192.in-addr.arpa. 7200 IN     IPSECKEY ( 10 1 2
+                    192.0.2.38
+                    AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== )
+
+   An example of a node, 192.0.2.38, that has published its key only.
+
+   38.2.0.192.in-addr.arpa. 7200 IN     IPSECKEY ( 10 0 2
+                    .
+                    AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== )
+
+
+
+
+
+
+
+
+
+Richardson                  Standards Track                     [Page 6]
+
+RFC 4025          Storing IPsec Keying Material in DNS     February 2005
+
+
+   An example of a node, 192.0.2.38, that has delegated authority to the
+   node 192.0.2.3.
+
+   38.2.0.192.in-addr.arpa. 7200 IN     IPSECKEY ( 10 1 2
+                    192.0.2.3
+                    AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== )
+
+   An example of a node, 192.0.1.38 that has delegated authority to the
+   node with the identity "mygateway.example.com".
+
+   38.1.0.192.in-addr.arpa. 7200 IN     IPSECKEY ( 10 3 2
+                    mygateway.example.com.
+                    AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== )
+
+   An example of a node, 2001:0DB8:0200:1:210:f3ff:fe03:4d0, that has
+   delegated authority to the node 2001:0DB8:c000:0200:2::1
+
+   $ORIGIN 1.0.0.0.0.0.2.8.B.D.0.1.0.0.2.ip6.arpa.
+   0.d.4.0.3.0.e.f.f.f.3.f.0.1.2.0 7200 IN     IPSECKEY ( 10 2 2
+                    2001:0DB8:0:8002::2000:1
+                    AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== )
+
+4.  Security Considerations
+
+   This entire memo pertains to the provision of public keying material
+   for use by key management protocols such as ISAKMP/IKE (RFC 2407)
+   [7].
+
+   The IPSECKEY resource record contains information that SHOULD be
+   communicated to the end client in an integral fashion; i.e., free
+   from modification.  The form of this channel is up to the consumer of
+   the data; there must be a trust relationship between the end consumer
+   of this resource record and the server.  This relationship may be
+   end-to-end DNSSEC validation, a TSIG or SIG(0) channel to another
+   secure source, a secure local channel on the host, or some
+   combination of the above.
+
+   The keying material provided by the IPSECKEY resource record is not
+   sensitive to passive attacks.  The keying material may be freely
+   disclosed to any party without any impact on the security properties
+   of the resulting IPsec session.  IPsec and IKE provide defense
+   against both active and passive attacks.
+
+   Any derivative specification that makes use of this resource record
+   MUST carefully document its trust model and why the trust model of
+   DNSSEC is appropriate, if that is the secure channel used.
+
+
+
+
+
+Richardson                  Standards Track                     [Page 7]
+
+RFC 4025          Storing IPsec Keying Material in DNS     February 2005
+
+
+   An active attack on the DNS that caused the wrong IP address to be
+   retrieved (via forged address), and therefore the wrong QNAME to be
+   queried, would also result in a man-in-the-middle attack.  This
+   situation is independent of whether the IPSECKEY RR is used.
+
+4.1.  Active Attacks Against Unsecured IPSECKEY Resource Records
+
+   This section deals with active attacks against the DNS.  These
+   attacks require that DNS requests and responses be intercepted and
+   changed.  DNSSEC is designed to defend against attacks of this kind.
+   This section deals with the situation in which DNSSEC is not
+   available.  This is not the recommended deployment scenario.
+
+4.1.1.  Active Attacks Against IPSECKEY Keying Materials
+
+   The first kind of active attack is when the attacker replaces the
+   keying material with either a key under its control or with garbage.
+
+   The gateway field is either untouched or is null.  The IKE
+   negotiation will therefore occur with the original end-system.  For
+   this attack to succeed, the attacker must perform a man-in-the-middle
+   attack on the IKE negotiation.  This attack requires that the
+   attacker be able to intercept and modify packets on the forwarding
+   path for the IKE and data packets.
+
+   If the attacker is not able to perform this man-in-the-middle attack
+   on the IKE negotiation, then a denial of service will result, as the
+   IKE negotiation will fail.
+
+   If the attacker is not only able to mount active attacks against DNS
+   but also in a position to perform a man-in-the-middle attack on IKE
+   and IPsec negotiations, then the attacker will be able to compromise
+   the resulting IPsec channel.  Note that an attacker must be able to
+   perform active DNS attacks on both sides of the IKE negotiation for
+   this to succeed.
+
+4.1.2.  Active Attacks Against IPSECKEY Gateway Material
+
+   The second kind of active attack is one in which the attacker
+   replaces the gateway address to point to a node under the attacker's
+   control.  The attacker then either replaces the public key or removes
+   it.  If the public key were removed, then the attacker could provide
+   an accurate public key of its own in a second record.
+
+   This second form creates a simple man-in-the-middle attacks since the
+   attacker can then create a second tunnel to the real destination.
+   Note that, as before, this requires that the attacker also mount an
+   active attack against the responder.
+
+
+
+Richardson                  Standards Track                     [Page 8]
+
+RFC 4025          Storing IPsec Keying Material in DNS     February 2005
+
+
+   Note that the man-in-the-middle cannot just forward cleartext packets
+   to the original destination.  While the destination may be willing to
+   speak in the clear, replying to the original sender, the sender will
+   already have created a policy expecting ciphertext.  Thus, the
+   attacker will need to intercept traffic in both directions.  In some
+   cases, the attacker may be able to accomplish the full intercept by
+   use of Network Address/Port Translation (NAT/NAPT) technology.
+
+   This attack is easier than the first one because the attacker does
+   NOT need to be on the end-to-end forwarding path.  The attacker need
+   only be able to modify DNS replies.  This can be done by packet
+   modification, by various kinds of race attacks, or through methods
+   that pollute DNS caches.
+
+   If the end-to-end integrity of the IPSECKEY RR is suspect, the end
+   client MUST restrict its use of the IPSECKEY RR to cases where the RR
+   owner name matches the content of the gateway field.  As the RR owner
+   name is assumed when the gateway field is null, a null gateway field
+   is considered a match.
+
+   Thus, any records obtained under unverified conditions (e.g., no
+   DNSSEC or trusted path to source) that have a non-null gateway field
+   MUST be ignored.
+
+   This restriction eliminates attacks against the gateway field, which
+   are considered much easier, as the attack does not need to be on the
+   forwarding path.
+
+   In the case of an IPSECKEY RR with a value of three in its gateway
+   type field, the gateway field contains a domain name.  The subsequent
+   query required to translate that name into an IP address or IPSECKEY
+   RR will also be subject to man-in-the-middle attacks.  If the
+   end-to-end integrity of this second query is suspect, then the
+   provisions above also apply.  The IPSECKEY RR MUST be ignored
+   whenever the resulting gateway does not match the QNAME of the
+   original IPSECKEY RR query.
+
+5.  IANA Considerations
+
+   This document updates the IANA Registry for DNS Resource Record Types
+   by assigning type 45 to the IPSECKEY record.
+
+   This document creates two new IANA registries, both specific to the
+   IPSECKEY Resource Record:
+
+   This document creates an IANA registry for the algorithm type field.
+
+
+
+
+
+Richardson                  Standards Track                     [Page 9]
+
+RFC 4025          Storing IPsec Keying Material in DNS     February 2005
+
+
+   Values 0, 1, and 2 are defined in Section 2.4.  Algorithm numbers 3
+   through 255 can be assigned by IETF Consensus (see RFC 2434 [5]).
+
+   This document creates an IANA registry for the gateway type field.
+
+   Values 0, 1, 2, and 3 are defined in Section 2.3.  Gateway type
+   numbers 4 through 255 can be assigned by Standards Action (see RFC
+   2434 [5]).
+
+6.  Acknowledgements
+
+   My thanks to Paul Hoffman, Sam Weiler, Jean-Jacques Puig, Rob
+   Austein, and Olafur Gudmundsson, who reviewed this document
+   carefully.  Additional thanks to Olafur Gurmundsson for a reference
+   implementation.
+
+7.  References
+
+7.1.  Normative References
+
+   [1]  Mockapetris, P., "Domain names - concepts and facilities", STD
+        13, RFC 1034, November 1987.
+
+   [2]  Mockapetris, P., "Domain names - implementation and
+        specification", STD 13, RFC 1035, November 1987.
+
+   [3]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
+        Levels", BCP 14, RFC 2119, March 1997.
+
+   [4]  Eastlake 3rd, D. and C. Kaufman, "Domain Name System Security
+        Extensions", RFC 2065, January 1997.
+
+   [5]  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
+        Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
+
+   [6]  Josefsson, S., "The Base16, Base32, and Base64 Data Encodings",
+        RFC 3548, July 2003.
+
+7.2.  Informative References
+
+   [7]  Piper, D., "The Internet IP Security Domain of Interpretation
+        for ISAKMP", RFC 2407, November 1998.
+
+   [8]  Eastlake 3rd, D., "Domain Name System Security Extensions", RFC
+        2535, March 1999.
+
+   [9]  Eastlake 3rd, D., "DSA KEYs and SIGs in the Domain Name System
+        (DNS)", RFC 2536, March 1999.
+
+
+
+Richardson                  Standards Track                    [Page 10]
+
+RFC 4025          Storing IPsec Keying Material in DNS     February 2005
+
+
+   [10] Eastlake 3rd, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain
+        Name System (DNS)", RFC 3110, May 2001.
+
+   [11] Massey, D. and S. Rose, "Limiting the Scope of the KEY Resource
+        Record (RR)", RFC 3445, December 2002.
+
+   [12] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, "DNS
+        Extensions to Support IP Version 6", RFC 3596, October 2003.
+
+Author's Address
+
+   Michael C. Richardson
+   Sandelman Software Works
+   470 Dawson Avenue
+   Ottawa, ON  K1Z 5V7
+   CA
+
+   EMail: mcr@sandelman.ottawa.on.ca
+   URI:   http://www.sandelman.ottawa.on.ca/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Richardson                  Standards Track                    [Page 11]
+
+RFC 4025          Storing IPsec Keying Material in DNS     February 2005
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2005).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the IETF's procedures with respect to rights in IETF Documents can
+   be found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at ietf-
+   ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+Richardson                  Standards Track                    [Page 12]
+
diff --git a/doc/rfc/rfc4033.txt b/doc/rfc/rfc4033.txt
new file mode 100644
index 0000000..7f0a464
--- /dev/null
+++ b/doc/rfc/rfc4033.txt
@@ -0,0 +1,1179 @@
+
+
+
+
+
+
+Network Working Group                                          R. Arends
+Request for Comments: 4033                          Telematica Instituut
+Obsoletes: 2535, 3008, 3090, 3445, 3655, 3658,                R. Austein
+           3755, 3757, 3845                                          ISC
+Updates: 1034, 1035, 2136, 2181, 2308, 3225,                   M. Larson
+         3007, 3597, 3226                                       VeriSign
+Category: Standards Track                                      D. Massey
+                                               Colorado State University
+                                                                 S. Rose
+                                                                    NIST
+                                                              March 2005
+
+
+               DNS Security Introduction and Requirements
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).
+
+Abstract
+
+   The Domain Name System Security Extensions (DNSSEC) add data origin
+   authentication and data integrity to the Domain Name System.  This
+   document introduces these extensions and describes their capabilities
+   and limitations.  This document also discusses the services that the
+   DNS security extensions do and do not provide.  Last, this document
+   describes the interrelationships between the documents that
+   collectively describe DNSSEC.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al.              Standards Track                     [Page 1]
+
+RFC 4033       DNS Security Introduction and Requirements     March 2005
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . .   2
+   2.  Definitions of Important DNSSEC Terms  . . . . . . . . . . .   3
+   3.  Services Provided by DNS Security  . . . . . . . . . . . . .   7
+       3.1.  Data Origin Authentication and Data Integrity  . . . .   7
+       3.2.  Authenticating Name and Type Non-Existence . . . . . .   9
+   4.  Services Not Provided by DNS Security  . . . . . . . . . . .   9
+   5.  Scope of the DNSSEC Document Set and Last Hop Issues . . . .   9
+   6.  Resolver Considerations  . . . . . . . . . . . . . . . . . .  10
+   7.  Stub Resolver Considerations . . . . . . . . . . . . . . . .  11
+   8.  Zone Considerations  . . . . . . . . . . . . . . . . . . . .  12
+       8.1.  TTL Values vs. RRSIG Validity Period . . . . . . . . .  13
+       8.2.  New Temporal Dependency Issues for Zones . . . . . . .  13
+   9.  Name Server Considerations . . . . . . . . . . . . . . . . .  13
+   10. DNS Security Document Family . . . . . . . . . . . . . . . .  14
+   11. IANA Considerations  . . . . . . . . . . . . . . . . . . . .  15
+   12. Security Considerations  . . . . . . . . . . . . . . . . . .  15
+   13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . .  17
+   14. References . . . . . . . . . . . . . . . . . . . . . . . . .  17
+       14.1. Normative References . . . . . . . . . . . . . . . . .  17
+       14.2. Informative References . . . . . . . . . . . . . . . .  18
+   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . .  20
+   Full Copyright Statement . . . . . . . . . . . . . . . . . . . .  21
+
+1.  Introduction
+
+   This document introduces the Domain Name System Security Extensions
+   (DNSSEC).  This document and its two companion documents ([RFC4034]
+   and [RFC4035]) update, clarify, and refine the security extensions
+   defined in [RFC2535] and its predecessors.  These security extensions
+   consist of a set of new resource record types and modifications to
+   the existing DNS protocol ([RFC1035]).  The new records and protocol
+   modifications are not fully described in this document, but are
+   described in a family of documents outlined in Section 10.  Sections
+   3 and 4 describe the capabilities and limitations of the security
+   extensions in greater detail.  Section 5 discusses the scope of the
+   document set.  Sections 6, 7, 8, and 9 discuss the effect that these
+   security extensions will have on resolvers, stub resolvers, zones,
+   and name servers.
+
+   This document and its two companions obsolete [RFC2535], [RFC3008],
+   [RFC3090], [RFC3445], [RFC3655], [RFC3658], [RFC3755], [RFC3757], and
+   [RFC3845].  This document set also updates but does not obsolete
+   [RFC1034], [RFC1035], [RFC2136], [RFC2181], [RFC2308], [RFC3225],
+   [RFC3007], [RFC3597], and the portions of [RFC3226] that deal with
+   DNSSEC.
+
+
+
+
+Arends, et al.              Standards Track                     [Page 2]
+
+RFC 4033       DNS Security Introduction and Requirements     March 2005
+
+
+   The DNS security extensions provide origin authentication and
+   integrity protection for DNS data, as well as a means of public key
+   distribution.  These extensions do not provide confidentiality.
+
+2.  Definitions of Important DNSSEC Terms
+
+   This section defines a number of terms used in this document set.
+   Because this is intended to be useful as a reference while reading
+   the rest of the document set, first-time readers may wish to skim
+   this section quickly, read the rest of this document, and then come
+   back to this section.
+
+   Authentication Chain: An alternating sequence of DNS public key
+      (DNSKEY) RRsets and Delegation Signer (DS) RRsets forms a chain of
+      signed data, with each link in the chain vouching for the next.  A
+      DNSKEY RR is used to verify the signature covering a DS RR and
+      allows the DS RR to be authenticated.  The DS RR contains a hash
+      of another DNSKEY RR and this new DNSKEY RR is authenticated by
+      matching the hash in the DS RR.  This new DNSKEY RR in turn
+      authenticates another DNSKEY RRset and, in turn, some DNSKEY RR in
+      this set may be used to authenticate another DS RR, and so forth
+      until the chain finally ends with a DNSKEY RR whose corresponding
+      private key signs the desired DNS data.  For example, the root
+      DNSKEY RRset can be used to authenticate the DS RRset for
+      "example."  The "example." DS RRset contains a hash that matches
+      some "example." DNSKEY, and this DNSKEY's corresponding private
+      key signs the "example." DNSKEY RRset.  Private key counterparts
+      of the "example." DNSKEY RRset sign data records such as
+      "www.example." and DS RRs for delegations such as
+      "subzone.example."
+
+   Authentication Key: A public key that a security-aware resolver has
+      verified and can therefore use to authenticate data.  A
+      security-aware resolver can obtain authentication keys in three
+      ways.  First, the resolver is generally configured to know about
+      at least one public key; this configured data is usually either
+      the public key itself or a hash of the public key as found in the
+      DS RR (see "trust anchor").  Second, the resolver may use an
+      authenticated public key to verify a DS RR and the DNSKEY RR to
+      which the DS RR refers.  Third, the resolver may be able to
+      determine that a new public key has been signed by the private key
+      corresponding to another public key that the resolver has
+      verified.  Note that the resolver must always be guided by local
+      policy when deciding whether to authenticate a new public key,
+      even if the local policy is simply to authenticate any new public
+      key for which the resolver is able verify the signature.
+
+
+
+
+
+Arends, et al.              Standards Track                     [Page 3]
+
+RFC 4033       DNS Security Introduction and Requirements     March 2005
+
+
+   Authoritative RRset: Within the context of a particular zone, an
+      RRset is "authoritative" if and only if the owner name of the
+      RRset lies within the subset of the name space that is at or below
+      the zone apex and at or above the cuts that separate the zone from
+      its children, if any.  All RRsets at the zone apex are
+      authoritative, except for certain RRsets at this domain name that,
+      if present, belong to this zone's parent.  These RRset could
+      include a DS RRset, the NSEC RRset referencing this DS RRset (the
+      "parental NSEC"), and RRSIG RRs associated with these RRsets, all
+      of which are authoritative in the parent zone.  Similarly, if this
+      zone contains any delegation points, only the parental NSEC RRset,
+      DS RRsets, and any RRSIG RRs associated with these RRsets are
+      authoritative for this zone.
+
+   Delegation Point: Term used to describe the name at the parental side
+      of a zone cut.  That is, the delegation point for "foo.example"
+      would be the foo.example node in the "example" zone (as opposed to
+      the zone apex of the "foo.example" zone).  See also zone apex.
+
+   Island of Security: Term used to describe a signed, delegated zone
+      that does not have an authentication chain from its delegating
+      parent.  That is, there is no DS RR containing a hash of a DNSKEY
+      RR for the island in its delegating parent zone (see [RFC4034]).
+      An island of security is served by security-aware name servers and
+      may provide authentication chains to any delegated child zones.
+      Responses from an island of security or its descendents can only
+      be authenticated if its authentication keys can be authenticated
+      by some trusted means out of band from the DNS protocol.
+
+   Key Signing Key (KSK): An authentication key that corresponds to a
+      private key used to sign one or more other authentication keys for
+      a given zone.  Typically, the private key corresponding to a key
+      signing key will sign a zone signing key, which in turn has a
+      corresponding private key that will sign other zone data.  Local
+      policy may require that the zone signing key be changed
+      frequently, while the key signing key may have a longer validity
+      period in order to provide a more stable secure entry point into
+      the zone.  Designating an authentication key as a key signing key
+      is purely an operational issue: DNSSEC validation does not
+      distinguish between key signing keys and other DNSSEC
+      authentication keys, and it is possible to use a single key as
+      both a key signing key and a zone signing key.  Key signing keys
+      are discussed in more detail in [RFC3757].  Also see zone signing
+      key.
+
+
+
+
+
+
+
+Arends, et al.              Standards Track                     [Page 4]
+
+RFC 4033       DNS Security Introduction and Requirements     March 2005
+
+
+   Non-Validating Security-Aware Stub Resolver: A security-aware stub
+      resolver that trusts one or more security-aware recursive name
+      servers to perform most of the tasks discussed in this document
+      set on its behalf.  In particular, a non-validating security-aware
+      stub resolver is an entity that sends DNS queries, receives DNS
+      responses, and is capable of establishing an appropriately secured
+      channel to a security-aware recursive name server that will
+      provide these services on behalf of the security-aware stub
+      resolver.  See also security-aware stub resolver, validating
+      security-aware stub resolver.
+
+   Non-Validating Stub Resolver: A less tedious term for a
+      non-validating security-aware stub resolver.
+
+   Security-Aware Name Server: An entity acting in the role of a name
+      server (defined in section 2.4 of [RFC1034]) that understands the
+      DNS security extensions defined in this document set.  In
+      particular, a security-aware name server is an entity that
+      receives DNS queries, sends DNS responses, supports the EDNS0
+      ([RFC2671]) message size extension and the DO bit ([RFC3225]), and
+      supports the RR types and message header bits defined in this
+      document set.
+
+   Security-Aware Recursive Name Server: An entity that acts in both the
+      security-aware name server and security-aware resolver roles.  A
+      more cumbersome but equivalent phrase would be "a security-aware
+      name server that offers recursive service".
+
+   Security-Aware Resolver: An entity acting in the role of a resolver
+      (defined in section 2.4 of [RFC1034]) that understands the DNS
+      security extensions defined in this document set.  In particular,
+      a security-aware resolver is an entity that sends DNS queries,
+      receives DNS responses, supports the EDNS0 ([RFC2671]) message
+      size extension and the DO bit ([RFC3225]), and is capable of using
+      the RR types and message header bits defined in this document set
+      to provide DNSSEC services.
+
+   Security-Aware Stub Resolver: An entity acting in the role of a stub
+      resolver (defined in section 5.3.1 of [RFC1034]) that has enough
+      of an understanding the DNS security extensions defined in this
+      document set to provide additional services not available from a
+      security-oblivious stub resolver.  Security-aware stub resolvers
+      may be either "validating" or "non-validating", depending on
+      whether the stub resolver attempts to verify DNSSEC signatures on
+      its own or trusts a friendly security-aware name server to do so.
+      See also validating stub resolver, non-validating stub resolver.
+
+
+
+
+
+Arends, et al.              Standards Track                     [Page 5]
+
+RFC 4033       DNS Security Introduction and Requirements     March 2005
+
+
+   Security-Oblivious <anything>: An <anything> that is not
+      "security-aware".
+
+   Signed Zone: A zone whose RRsets are signed and that contains
+      properly constructed DNSKEY, Resource Record Signature (RRSIG),
+      Next Secure (NSEC), and (optionally) DS records.
+
+   Trust Anchor: A configured DNSKEY RR or DS RR hash of a DNSKEY RR.  A
+      validating security-aware resolver uses this public key or hash as
+      a starting point for building the authentication chain to a signed
+      DNS response.  In general, a validating resolver will have to
+      obtain the initial values of its trust anchors via some secure or
+      trusted means outside the DNS protocol.  Presence of a trust
+      anchor also implies that the resolver should expect the zone to
+      which the trust anchor points to be signed.
+
+   Unsigned Zone: A zone that is not signed.
+
+   Validating Security-Aware Stub Resolver: A security-aware resolver
+      that sends queries in recursive mode but that performs signature
+      validation on its own rather than just blindly trusting an
+      upstream security-aware recursive name server.  See also
+      security-aware stub resolver, non-validating security-aware stub
+      resolver.
+
+   Validating Stub Resolver: A less tedious term for a validating
+      security-aware stub resolver.
+
+   Zone Apex: Term used to describe the name at the child's side of a
+      zone cut.  See also delegation point.
+
+   Zone Signing Key (ZSK): An authentication key that corresponds to a
+      private key used to sign a zone.  Typically, a zone signing key
+      will be part of the same DNSKEY RRset as the key signing key whose
+      corresponding private key signs this DNSKEY RRset, but the zone
+      signing key is used for a slightly different purpose and may
+      differ from the key signing key in other ways, such as validity
+      lifetime.  Designating an authentication key as a zone signing key
+      is purely an operational issue; DNSSEC validation does not
+      distinguish between zone signing keys and other DNSSEC
+      authentication keys, and it is possible to use a single key as
+      both a key signing key and a zone signing key.  See also key
+      signing key.
+
+
+
+
+
+
+
+
+Arends, et al.              Standards Track                     [Page 6]
+
+RFC 4033       DNS Security Introduction and Requirements     March 2005
+
+
+3.  Services Provided by DNS Security
+
+   The Domain Name System (DNS) security extensions provide origin
+   authentication and integrity assurance services for DNS data,
+   including mechanisms for authenticated denial of existence of DNS
+   data.  These mechanisms are described below.
+
+   These mechanisms require changes to the DNS protocol.  DNSSEC adds
+   four new resource record types: Resource Record Signature (RRSIG),
+   DNS Public Key (DNSKEY), Delegation Signer (DS), and Next Secure
+   (NSEC).  It also adds two new message header bits: Checking Disabled
+   (CD) and Authenticated Data (AD).  In order to support the larger DNS
+   message sizes that result from adding the DNSSEC RRs, DNSSEC also
+   requires EDNS0 support ([RFC2671]).  Finally, DNSSEC requires support
+   for the DNSSEC OK (DO) EDNS header bit ([RFC3225]) so that a
+   security-aware resolver can indicate in its queries that it wishes to
+   receive DNSSEC RRs in response messages.
+
+   These services protect against most of the threats to the Domain Name
+   System described in [RFC3833].  Please see Section 12 for a
+   discussion of the limitations of these extensions.
+
+3.1.  Data Origin Authentication and Data Integrity
+
+   DNSSEC provides authentication by associating cryptographically
+   generated digital signatures with DNS RRsets.  These digital
+   signatures are stored in a new resource record, the RRSIG record.
+   Typically, there will be a single private key that signs a zone's
+   data, but multiple keys are possible.  For example, there may be keys
+   for each of several different digital signature algorithms.  If a
+   security-aware resolver reliably learns a zone's public key, it can
+   authenticate that zone's signed data.  An important DNSSEC concept is
+   that the key that signs a zone's data is associated with the zone
+   itself and not with the zone's authoritative name servers.  (Public
+   keys for DNS transaction authentication mechanisms may also appear in
+   zones, as described in [RFC2931], but DNSSEC itself is concerned with
+   object security of DNS data, not channel security of DNS
+   transactions.  The keys associated with transaction security may be
+   stored in different RR types.  See [RFC3755] for details.)
+
+   A security-aware resolver can learn a zone's public key either by
+   having a trust anchor configured into the resolver or by normal DNS
+   resolution.  To allow the latter, public keys are stored in a new
+   type of resource record, the DNSKEY RR.  Note that the private keys
+   used to sign zone data must be kept secure and should be stored
+   offline when practical.  To discover a public key reliably via DNS
+   resolution, the target key itself has to be signed by either a
+   configured authentication key or another key that has been
+
+
+
+Arends, et al.              Standards Track                     [Page 7]
+
+RFC 4033       DNS Security Introduction and Requirements     March 2005
+
+
+   authenticated previously.  Security-aware resolvers authenticate zone
+   information by forming an authentication chain from a newly learned
+   public key back to a previously known authentication public key,
+   which in turn either has been configured into the resolver or must
+   have been learned and verified previously.  Therefore, the resolver
+   must be configured with at least one trust anchor.
+
+   If the configured trust anchor is a zone signing key, then it will
+   authenticate the associated zone; if the configured key is a key
+   signing key, it will authenticate a zone signing key.  If the
+   configured trust anchor is the hash of a key rather than the key
+   itself, the resolver may have to obtain the key via a DNS query.  To
+   help security-aware resolvers establish this authentication chain,
+   security-aware name servers attempt to send the signature(s) needed
+   to authenticate a zone's public key(s) in the DNS reply message along
+   with the public key itself, provided that there is space available in
+   the message.
+
+   The Delegation Signer (DS) RR type simplifies some of the
+   administrative tasks involved in signing delegations across
+   organizational boundaries.  The DS RRset resides at a delegation
+   point in a parent zone and indicates the public key(s) corresponding
+   to the private key(s) used to self-sign the DNSKEY RRset at the
+   delegated child zone's apex.  The administrator of the child zone, in
+   turn, uses the private key(s) corresponding to one or more of the
+   public keys in this DNSKEY RRset to sign the child zone's data.  The
+   typical authentication chain is therefore
+   DNSKEY->[DS->DNSKEY]*->RRset, where "*" denotes zero or more
+   DS->DNSKEY subchains.  DNSSEC permits more complex authentication
+   chains, such as additional layers of DNSKEY RRs signing other DNSKEY
+   RRs within a zone.
+
+   A security-aware resolver normally constructs this authentication
+   chain from the root of the DNS hierarchy down to the leaf zones based
+   on configured knowledge of the public key for the root.  Local
+   policy, however, may also allow a security-aware resolver to use one
+   or more configured public keys (or hashes of public keys) other than
+   the root public key, may not provide configured knowledge of the root
+   public key, or may prevent the resolver from using particular public
+   keys for arbitrary reasons, even if those public keys are properly
+   signed with verifiable signatures.  DNSSEC provides mechanisms by
+   which a security-aware resolver can determine whether an RRset's
+   signature is "valid" within the meaning of DNSSEC.  In the final
+   analysis, however, authenticating both DNS keys and data is a matter
+   of local policy, which may extend or even override the protocol
+   extensions defined in this document set.  See Section 5 for further
+   discussion.
+
+
+
+
+Arends, et al.              Standards Track                     [Page 8]
+
+RFC 4033       DNS Security Introduction and Requirements     March 2005
+
+
+3.2.  Authenticating Name and Type Non-Existence
+
+   The security mechanism described in Section 3.1 only provides a way
+   to sign existing RRsets in a zone.  The problem of providing negative
+   responses with the same level of authentication and integrity
+   requires the use of another new resource record type, the NSEC
+   record.  The NSEC record allows a security-aware resolver to
+   authenticate a negative reply for either name or type non-existence
+   with the same mechanisms used to authenticate other DNS replies.  Use
+   of NSEC records requires a canonical representation and ordering for
+   domain names in zones.  Chains of NSEC records explicitly describe
+   the gaps, or "empty space", between domain names in a zone and list
+   the types of RRsets present at existing names.  Each NSEC record is
+   signed and authenticated using the mechanisms described in Section
+   3.1.
+
+4.  Services Not Provided by DNS Security
+
+   DNS was originally designed with the assumptions that the DNS will
+   return the same answer to any given query regardless of who may have
+   issued the query, and that all data in the DNS is thus visible.
+   Accordingly, DNSSEC is not designed to provide confidentiality,
+   access control lists, or other means of differentiating between
+   inquirers.
+
+   DNSSEC provides no protection against denial of service attacks.
+   Security-aware resolvers and security-aware name servers are
+   vulnerable to an additional class of denial of service attacks based
+   on cryptographic operations.  Please see Section 12 for details.
+
+   The DNS security extensions provide data and origin authentication
+   for DNS data.  The mechanisms outlined above are not designed to
+   protect operations such as zone transfers and dynamic update
+   ([RFC2136], [RFC3007]).  Message authentication schemes described in
+   [RFC2845] and [RFC2931] address security operations that pertain to
+   these transactions.
+
+5.  Scope of the DNSSEC Document Set and Last Hop Issues
+
+   The specification in this document set defines the behavior for zone
+   signers and security-aware name servers and resolvers in such a way
+   that the validating entities can unambiguously determine the state of
+   the data.
+
+   A validating resolver can determine the following 4 states:
+
+   Secure: The validating resolver has a trust anchor, has a chain of
+      trust, and is able to verify all the signatures in the response.
+
+
+
+Arends, et al.              Standards Track                     [Page 9]
+
+RFC 4033       DNS Security Introduction and Requirements     March 2005
+
+
+   Insecure: The validating resolver has a trust anchor, a chain of
+      trust, and, at some delegation point, signed proof of the
+      non-existence of a DS record.  This indicates that subsequent
+      branches in the tree are provably insecure.  A validating resolver
+      may have a local policy to mark parts of the domain space as
+      insecure.
+
+   Bogus: The validating resolver has a trust anchor and a secure
+      delegation indicating that subsidiary data is signed, but the
+      response fails to validate for some reason: missing signatures,
+      expired signatures, signatures with unsupported algorithms, data
+      missing that the relevant NSEC RR says should be present, and so
+      forth.
+
+   Indeterminate: There is no trust anchor that would indicate that a
+      specific portion of the tree is secure.  This is the default
+      operation mode.
+
+   This specification only defines how security-aware name servers can
+   signal non-validating stub resolvers that data was found to be bogus
+   (using RCODE=2, "Server Failure"; see [RFC4035]).
+
+   There is a mechanism for security-aware name servers to signal
+   security-aware stub resolvers that data was found to be secure (using
+   the AD bit; see [RFC4035]).
+
+   This specification does not define a format for communicating why
+   responses were found to be bogus or marked as insecure.  The current
+   signaling mechanism does not distinguish between indeterminate and
+   insecure states.
+
+   A method for signaling advanced error codes and policy between a
+   security-aware stub resolver and security-aware recursive nameservers
+   is a topic for future work, as is the interface between a security-
+   aware resolver and the applications that use it.  Note, however, that
+   the lack of the specification of such communication does not prohibit
+   deployment of signed zones or the deployment of security aware
+   recursive name servers that prohibit propagation of bogus data to the
+   applications.
+
+6.  Resolver Considerations
+
+   A security-aware resolver has to be able to perform cryptographic
+   functions necessary to verify digital signatures using at least the
+   mandatory-to-implement algorithm(s).  Security-aware resolvers must
+   also be capable of forming an authentication chain from a newly
+   learned zone back to an authentication key, as described above.  This
+   process might require additional queries to intermediate DNS zones to
+
+
+
+Arends, et al.              Standards Track                    [Page 10]
+
+RFC 4033       DNS Security Introduction and Requirements     March 2005
+
+
+   obtain necessary DNSKEY, DS, and RRSIG records.  A security-aware
+   resolver should be configured with at least one trust anchor as the
+   starting point from which it will attempt to establish authentication
+   chains.
+
+   If a security-aware resolver is separated from the relevant
+   authoritative name servers by a recursive name server or by any sort
+   of intermediary device that acts as a proxy for DNS, and if the
+   recursive name server or intermediary device is not security-aware,
+   the security-aware resolver may not be capable of operating in a
+   secure mode.  For example, if a security-aware resolver's packets are
+   routed through a network address translation (NAT) device that
+   includes a DNS proxy that is not security-aware, the security-aware
+   resolver may find it difficult or impossible to obtain or validate
+   signed DNS data.  The security-aware resolver may have a particularly
+   difficult time obtaining DS RRs in such a case, as DS RRs do not
+   follow the usual DNS rules for ownership of RRs at zone cuts.  Note
+   that this problem is not specific to NATs: any security-oblivious DNS
+   software of any kind between the security-aware resolver and the
+   authoritative name servers will interfere with DNSSEC.
+
+   If a security-aware resolver must rely on an unsigned zone or a name
+   server that is not security aware, the resolver may not be able to
+   validate DNS responses and will need a local policy on whether to
+   accept unverified responses.
+
+   A security-aware resolver should take a signature's validation period
+   into consideration when determining the TTL of data in its cache, to
+   avoid caching signed data beyond the validity period of the
+   signature.  However, it should also allow for the possibility that
+   the security-aware resolver's own clock is wrong.  Thus, a
+   security-aware resolver that is part of a security-aware recursive
+   name server will have to pay careful attention to the DNSSEC
+   "checking disabled" (CD) bit ([RFC4034]).  This is in order to avoid
+   blocking valid signatures from getting through to other
+   security-aware resolvers that are clients of this recursive name
+   server.  See [RFC4035] for how a secure recursive server handles
+   queries with the CD bit set.
+
+7.  Stub Resolver Considerations
+
+   Although not strictly required to do so by the protocol, most DNS
+   queries originate from stub resolvers.  Stub resolvers, by
+   definition, are minimal DNS resolvers that use recursive query mode
+   to offload most of the work of DNS resolution to a recursive name
+   server.  Given the widespread use of stub resolvers, the DNSSEC
+
+
+
+
+
+Arends, et al.              Standards Track                    [Page 11]
+
+RFC 4033       DNS Security Introduction and Requirements     March 2005
+
+
+   architecture has to take stub resolvers into account, but the
+   security features needed in a stub resolver differ in some respects
+   from those needed in a security-aware iterative resolver.
+
+   Even a security-oblivious stub resolver may benefit from DNSSEC if
+   the recursive name servers it uses are security-aware, but for the
+   stub resolver to place any real reliance on DNSSEC services, the stub
+   resolver must trust both the recursive name servers in question and
+   the communication channels between itself and those name servers.
+   The first of these issues is a local policy issue: in essence, a
+   security-oblivious stub resolver has no choice but to place itself at
+   the mercy of the recursive name servers that it uses, as it does not
+   perform DNSSEC validity checks on its own.  The second issue requires
+   some kind of channel security mechanism; proper use of DNS
+   transaction authentication mechanisms such as SIG(0) ([RFC2931]) or
+   TSIG ([RFC2845]) would suffice, as would appropriate use of IPsec.
+   Particular implementations may have other choices available, such as
+   operating system specific interprocess communication mechanisms.
+   Confidentiality is not needed for this channel, but data integrity
+   and message authentication are.
+
+   A security-aware stub resolver that does trust both its recursive
+   name servers and its communication channel to them may choose to
+   examine the setting of the Authenticated Data (AD) bit in the message
+   header of the response messages it receives.  The stub resolver can
+   use this flag bit as a hint to find out whether the recursive name
+   server was able to validate signatures for all of the data in the
+   Answer and Authority sections of the response.
+
+   There is one more step that a security-aware stub resolver can take
+   if, for whatever reason, it is not able to establish a useful trust
+   relationship with the recursive name servers that it uses: it can
+   perform its own signature validation by setting the Checking Disabled
+   (CD) bit in its query messages.  A validating stub resolver is thus
+   able to treat the DNSSEC signatures as trust relationships between
+   the zone administrators and the stub resolver itself.
+
+8.  Zone Considerations
+
+   There are several differences between signed and unsigned zones.  A
+   signed zone will contain additional security-related records (RRSIG,
+   DNSKEY, DS, and NSEC records).  RRSIG and NSEC records may be
+   generated by a signing process prior to serving the zone.  The RRSIG
+   records that accompany zone data have defined inception and
+   expiration times that establish a validity period for the signatures
+   and the zone data the signatures cover.
+
+
+
+
+
+Arends, et al.              Standards Track                    [Page 12]
+
+RFC 4033       DNS Security Introduction and Requirements     March 2005
+
+
+8.1.  TTL Values vs. RRSIG Validity Period
+
+   It is important to note the distinction between a RRset's TTL value
+   and the signature validity period specified by the RRSIG RR covering
+   that RRset.  DNSSEC does not change the definition or function of the
+   TTL value, which is intended to maintain database coherency in
+   caches.  A caching resolver purges RRsets from its cache no later
+   than the end of the time period specified by the TTL fields of those
+   RRsets, regardless of whether the resolver is security-aware.
+
+   The inception and expiration fields in the RRSIG RR ([RFC4034]), on
+   the other hand, specify the time period during which the signature
+   can be used to validate the covered RRset.  The signatures associated
+   with signed zone data are only valid for the time period specified by
+   these fields in the RRSIG RRs in question.  TTL values cannot extend
+   the validity period of signed RRsets in a resolver's cache, but the
+   resolver may use the time remaining before expiration of the
+   signature validity period of a signed RRset as an upper bound for the
+   TTL of the signed RRset and its associated RRSIG RR in the resolver's
+   cache.
+
+8.2.  New Temporal Dependency Issues for Zones
+
+   Information in a signed zone has a temporal dependency that did not
+   exist in the original DNS protocol.  A signed zone requires regular
+   maintenance to ensure that each RRset in the zone has a current valid
+   RRSIG RR.  The signature validity period of an RRSIG RR is an
+   interval during which the signature for one particular signed RRset
+   can be considered valid, and the signatures of different RRsets in a
+   zone may expire at different times.  Re-signing one or more RRsets in
+   a zone will change one or more RRSIG RRs, which will in turn require
+   incrementing the zone's SOA serial number to indicate that a zone
+   change has occurred and re-signing the SOA RRset itself.  Thus,
+   re-signing any RRset in a zone may also trigger DNS NOTIFY messages
+   and zone transfer operations.
+
+9.  Name Server Considerations
+
+   A security-aware name server should include the appropriate DNSSEC
+   records (RRSIG, DNSKEY, DS, and NSEC) in all responses to queries
+   from resolvers that have signaled their willingness to receive such
+   records via use of the DO bit in the EDNS header, subject to message
+   size limitations.  Because inclusion of these DNSSEC RRs could easily
+   cause UDP message truncation and fallback to TCP, a security-aware
+   name server must also support the EDNS "sender's UDP payload"
+   mechanism.
+
+
+
+
+
+Arends, et al.              Standards Track                    [Page 13]
+
+RFC 4033       DNS Security Introduction and Requirements     March 2005
+
+
+   If possible, the private half of each DNSSEC key pair should be kept
+   offline, but this will not be possible for a zone for which DNS
+   dynamic update has been enabled.  In the dynamic update case, the
+   primary master server for the zone will have to re-sign the zone when
+   it is updated, so the private key corresponding to the zone signing
+   key will have to be kept online.  This is an example of a situation
+   in which the ability to separate the zone's DNSKEY RRset into zone
+   signing key(s) and key signing key(s) may be useful, as the key
+   signing key(s) in such a case can still be kept offline and may have
+   a longer useful lifetime than the zone signing key(s).
+
+   By itself, DNSSEC is not enough to protect the integrity of an entire
+   zone during zone transfer operations, as even a signed zone contains
+   some unsigned, nonauthoritative data if the zone has any children.
+   Therefore, zone maintenance operations will require some additional
+   mechanisms (most likely some form of channel security, such as TSIG,
+   SIG(0), or IPsec).
+
+10.  DNS Security Document Family
+
+   The DNSSEC document set can be partitioned into several main groups,
+   under the larger umbrella of the DNS base protocol documents.
+
+   The "DNSSEC protocol document set" refers to the three documents that
+   form the core of the DNS security extensions:
+
+   1.  DNS Security Introduction and Requirements (this document)
+
+   2.  Resource Records for DNS Security Extensions [RFC4034]
+
+   3.  Protocol Modifications for the DNS Security Extensions [RFC4035]
+
+   Additionally, any document that would add to or change the core DNS
+   Security extensions would fall into this category.  This includes any
+   future work on the communication between security-aware stub
+   resolvers and upstream security-aware recursive name servers.
+
+   The "Digital Signature Algorithm Specification" document set refers
+   to the group of documents that describe how specific digital
+   signature algorithms should be implemented to fit the DNSSEC resource
+   record format.  Each document in this set deals with a specific
+   digital signature algorithm.  Please see the appendix on "DNSSEC
+   Algorithm and Digest Types" in [RFC4034] for a list of the algorithms
+   that were defined when this core specification was written.
+
+   The "Transaction Authentication Protocol" document set refers to the
+   group of documents that deal with DNS message authentication,
+   including secret key establishment and verification.  Although not
+
+
+
+Arends, et al.              Standards Track                    [Page 14]
+
+RFC 4033       DNS Security Introduction and Requirements     March 2005
+
+
+   strictly part of the DNSSEC specification as defined in this set of
+   documents, this group is noted because of its relationship to DNSSEC.
+
+   The final document set, "New Security Uses", refers to documents that
+   seek to use proposed DNS Security extensions for other security
+   related purposes.  DNSSEC does not provide any direct security for
+   these new uses but may be used to support them.  Documents that fall
+   in this category include those describing the use of DNS in the
+   storage and distribution of certificates ([RFC2538]).
+
+11.  IANA Considerations
+
+   This overview document introduces no new IANA considerations.  Please
+   see [RFC4034] for a complete review of the IANA considerations
+   introduced by DNSSEC.
+
+12.  Security Considerations
+
+   This document introduces DNS security extensions and describes the
+   document set that contains the new security records and DNS protocol
+   modifications.  The extensions provide data origin authentication and
+   data integrity using digital signatures over resource record sets.
+   This section discusses the limitations of these extensions.
+
+   In order for a security-aware resolver to validate a DNS response,
+   all zones along the path from the trusted starting point to the zone
+   containing the response zones must be signed, and all name servers
+   and resolvers involved in the resolution process must be
+   security-aware, as defined in this document set.  A security-aware
+   resolver cannot verify responses originating from an unsigned zone,
+   from a zone not served by a security-aware name server, or for any
+   DNS data that the resolver is only able to obtain through a recursive
+   name server that is not security-aware.  If there is a break in the
+   authentication chain such that a security-aware resolver cannot
+   obtain and validate the authentication keys it needs, then the
+   security-aware resolver cannot validate the affected DNS data.
+
+   This document briefly discusses other methods of adding security to a
+   DNS query, such as using a channel secured by IPsec or using a DNS
+   transaction authentication mechanism such as TSIG ([RFC2845]) or
+   SIG(0) ([RFC2931]), but transaction security is not part of DNSSEC
+   per se.
+
+   A non-validating security-aware stub resolver, by definition, does
+   not perform DNSSEC signature validation on its own and thus is
+   vulnerable both to attacks on (and by) the security-aware recursive
+   name servers that perform these checks on its behalf and to attacks
+   on its communication with those security-aware recursive name
+
+
+
+Arends, et al.              Standards Track                    [Page 15]
+
+RFC 4033       DNS Security Introduction and Requirements     March 2005
+
+
+   servers.  Non-validating security-aware stub resolvers should use
+   some form of channel security to defend against the latter threat.
+   The only known defense against the former threat would be for the
+   security-aware stub resolver to perform its own signature validation,
+   at which point, again by definition, it would no longer be a
+   non-validating security-aware stub resolver.
+
+   DNSSEC does not protect against denial of service attacks.  DNSSEC
+   makes DNS vulnerable to a new class of denial of service attacks
+   based on cryptographic operations against security-aware resolvers
+   and security-aware name servers, as an attacker can attempt to use
+   DNSSEC mechanisms to consume a victim's resources.  This class of
+   attacks takes at least two forms.  An attacker may be able to consume
+   resources in a security-aware resolver's signature validation code by
+   tampering with RRSIG RRs in response messages or by constructing
+   needlessly complex signature chains.  An attacker may also be able to
+   consume resources in a security-aware name server that supports DNS
+   dynamic update, by sending a stream of update messages that force the
+   security-aware name server to re-sign some RRsets in the zone more
+   frequently than would otherwise be necessary.
+
+   Due to a deliberate design choice, DNSSEC does not provide
+   confidentiality.
+
+   DNSSEC introduces the ability for a hostile party to enumerate all
+   the names in a zone by following the NSEC chain.  NSEC RRs assert
+   which names do not exist in a zone by linking from existing name to
+   existing name along a canonical ordering of all the names within a
+   zone.  Thus, an attacker can query these NSEC RRs in sequence to
+   obtain all the names in a zone.  Although this is not an attack on
+   the DNS itself, it could allow an attacker to map network hosts or
+   other resources by enumerating the contents of a zone.
+
+   DNSSEC introduces significant additional complexity to the DNS and
+   thus introduces many new opportunities for implementation bugs and
+   misconfigured zones.  In particular, enabling DNSSEC signature
+   validation in a resolver may cause entire legitimate zones to become
+   effectively unreachable due to DNSSEC configuration errors or bugs.
+
+   DNSSEC does not protect against tampering with unsigned zone data.
+   Non-authoritative data at zone cuts (glue and NS RRs in the parent
+   zone) are not signed.  This does not pose a problem when validating
+   the authentication chain, but it does mean that the non-authoritative
+   data itself is vulnerable to tampering during zone transfer
+   operations.  Thus, while DNSSEC can provide data origin
+   authentication and data integrity for RRsets, it cannot do so for
+   zones, and other mechanisms (such as TSIG, SIG(0), or IPsec) must be
+   used to protect zone transfer operations.
+
+
+
+Arends, et al.              Standards Track                    [Page 16]
+
+RFC 4033       DNS Security Introduction and Requirements     March 2005
+
+
+   Please see [RFC4034] and [RFC4035] for additional security
+   considerations.
+
+13.  Acknowledgements
+
+   This document was created from the input and ideas of the members of
+   the DNS Extensions Working Group.  Although explicitly listing
+   everyone who has contributed during the decade in which DNSSEC has
+   been under development would be impossible, the editors would
+   particularly like to thank the following people for their
+   contributions to and comments on this document set: Jaap Akkerhuis,
+   Mark Andrews, Derek Atkins, Roy Badami, Alan Barrett, Dan Bernstein,
+   David Blacka, Len Budney, Randy Bush, Francis Dupont, Donald
+   Eastlake, Robert Elz, Miek Gieben, Michael Graff, Olafur Gudmundsson,
+   Gilles Guette, Andreas Gustafsson, Jun-ichiro Itojun Hagino, Phillip
+   Hallam-Baker, Bob Halley, Ted Hardie, Walter Howard, Greg Hudson,
+   Christian Huitema, Johan Ihren, Stephen Jacob, Jelte Jansen, Simon
+   Josefsson, Andris Kalnozols, Peter Koch, Olaf Kolkman, Mark Kosters,
+   Suresh Krishnaswamy, Ben Laurie, David Lawrence, Ted Lemon, Ed Lewis,
+   Ted Lindgreen, Josh Littlefield, Rip Loomis, Bill Manning, Russ
+   Mundy, Thomas Narten, Mans Nilsson, Masataka Ohta, Mike Patton, Rob
+   Payne, Jim Reid, Michael Richardson, Erik Rozendaal, Marcos Sanz,
+   Pekka Savola, Jakob Schlyter, Mike StJohns, Paul Vixie, Sam Weiler,
+   Brian Wellington, and Suzanne Woolf.
+
+   No doubt the above list is incomplete.  We apologize to anyone we
+   left out.
+
+14.  References
+
+14.1.  Normative References
+
+   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
+              STD 13, RFC 1034, November 1987.
+
+   [RFC1035]  Mockapetris, P., "Domain names - implementation and
+              specification", STD 13, RFC 1035, November 1987.
+
+   [RFC2535]  Eastlake 3rd, D., "Domain Name System Security
+              Extensions", RFC 2535, March 1999.
+
+   [RFC2671]  Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
+              2671, August 1999.
+
+   [RFC3225]  Conrad, D., "Indicating Resolver Support of DNSSEC", RFC
+              3225, December 2001.
+
+
+
+
+
+Arends, et al.              Standards Track                    [Page 17]
+
+RFC 4033       DNS Security Introduction and Requirements     March 2005
+
+
+   [RFC3226]  Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver
+              message size requirements", RFC 3226, December 2001.
+
+   [RFC3445]  Massey, D. and S. Rose, "Limiting the Scope of the KEY
+              Resource Record (RR)", RFC 3445, December 2002.
+
+   [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
+              Rose, "Resource Records for DNS Security Extensions", RFC
+              4034, March 2005.
+
+   [RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
+              Rose, "Protocol Modifications for the DNS Security
+              Extensions", RFC 4035, March 2005.
+
+14.2.  Informative References
+
+   [RFC2136]  Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
+              "Dynamic Updates in the Domain Name System (DNS UPDATE)",
+              RFC 2136, April 1997.
+
+   [RFC2181]  Elz, R. and R. Bush, "Clarifications to the DNS
+              Specification", RFC 2181, July 1997.
+
+   [RFC2308]  Andrews, M., "Negative Caching of DNS Queries (DNS
+              NCACHE)", RFC 2308, March 1998.
+
+   [RFC2538]  Eastlake 3rd, D. and O. Gudmundsson, "Storing Certificates
+              in the Domain Name System (DNS)", RFC 2538, March 1999.
+
+   [RFC2845]  Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.
+              Wellington, "Secret Key Transaction Authentication for DNS
+              (TSIG)", RFC 2845, May 2000.
+
+   [RFC2931]  Eastlake 3rd, D., "DNS Request and Transaction Signatures
+              ( SIG(0)s )", RFC 2931, September 2000.
+
+   [RFC3007]  Wellington, B., "Secure Domain Name System (DNS) Dynamic
+              Update", RFC 3007, November 2000.
+
+   [RFC3008]  Wellington, B., "Domain Name System Security (DNSSEC)
+              Signing Authority", RFC 3008, November 2000.
+
+   [RFC3090]  Lewis, E., "DNS Security Extension Clarification on Zone
+              Status", RFC 3090, March 2001.
+
+   [RFC3597]  Gustafsson, A., "Handling of Unknown DNS Resource Record
+              (RR) Types", RFC 3597, September 2003.
+
+
+
+
+Arends, et al.              Standards Track                    [Page 18]
+
+RFC 4033       DNS Security Introduction and Requirements     March 2005
+
+
+   [RFC3655]  Wellington, B. and O. Gudmundsson, "Redefinition of DNS
+              Authenticated Data (AD) bit", RFC 3655, November 2003.
+
+   [RFC3658]  Gudmundsson, O., "Delegation Signer (DS) Resource Record
+              (RR)", RFC 3658, December 2003.
+
+   [RFC3755]  Weiler, S., "Legacy Resolver Compatibility for Delegation
+              Signer (DS)", RFC 3755, May 2004.
+
+   [RFC3757]  Kolkman, O., Schlyter, J., and E. Lewis, "Domain Name
+              System KEY (DNSKEY) Resource Record (RR) Secure Entry
+              Point (SEP) Flag", RFC 3757, April 2004.
+
+   [RFC3833]  Atkins, D. and R. Austein, "Threat Analysis of the Domain
+              Name System (DNS)", RFC 3833, August 2004.
+
+   [RFC3845]  Schlyter, J., "DNS Security (DNSSEC) NextSECure (NSEC)
+              RDATA Format", RFC 3845, August 2004.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al.              Standards Track                    [Page 19]
+
+RFC 4033       DNS Security Introduction and Requirements     March 2005
+
+
+Authors' Addresses
+
+   Roy Arends
+   Telematica Instituut
+   Brouwerijstraat 1
+   7523 XC  Enschede
+   NL
+
+   EMail: roy.arends@telin.nl
+
+
+   Rob Austein
+   Internet Systems Consortium
+   950 Charter Street
+   Redwood City, CA  94063
+   USA
+
+   EMail: sra@isc.org
+
+
+   Matt Larson
+   VeriSign, Inc.
+   21345 Ridgetop Circle
+   Dulles, VA  20166-6503
+   USA
+
+   EMail: mlarson@verisign.com
+
+
+   Dan Massey
+   Colorado State University
+   Department of Computer Science
+   Fort Collins, CO 80523-1873
+
+   EMail: massey@cs.colostate.edu
+
+
+   Scott Rose
+   National Institute for Standards and Technology
+   100 Bureau Drive
+   Gaithersburg, MD  20899-8920
+   USA
+
+   EMail: scott.rose@nist.gov
+
+
+
+
+
+
+
+Arends, et al.              Standards Track                    [Page 20]
+
+RFC 4033       DNS Security Introduction and Requirements     March 2005
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2005).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at ietf-
+   ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+Arends, et al.              Standards Track                    [Page 21]
+
diff --git a/doc/rfc/rfc4034.txt b/doc/rfc/rfc4034.txt
new file mode 100644
index 0000000..6a12c6b
--- /dev/null
+++ b/doc/rfc/rfc4034.txt
@@ -0,0 +1,1627 @@
+
+
+
+
+
+
+Network Working Group                                          R. Arends
+Request for Comments: 4034                          Telematica Instituut
+Obsoletes: 2535, 3008, 3090, 3445, 3655, 3658,                R. Austein
+           3755, 3757, 3845                                          ISC
+Updates: 1034, 1035, 2136, 2181, 2308, 3225,                   M. Larson
+         3007, 3597, 3226                                       VeriSign
+Category: Standards Track                                      D. Massey
+                                               Colorado State University
+                                                                 S. Rose
+                                                                    NIST
+                                                              March 2005
+
+
+            Resource Records for the DNS Security Extensions
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).
+
+Abstract
+
+   This document is part of a family of documents that describe the DNS
+   Security Extensions (DNSSEC).  The DNS Security Extensions are a
+   collection of resource records and protocol modifications that
+   provide source authentication for the DNS.  This document defines the
+   public key (DNSKEY), delegation signer (DS), resource record digital
+   signature (RRSIG), and authenticated denial of existence (NSEC)
+   resource records.  The purpose and format of each resource record is
+   described in detail, and an example of each resource record is given.
+
+   This document obsoletes RFC 2535 and incorporates changes from all
+   updates to RFC 2535.
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al.              Standards Track                     [Page 1]
+
+RFC 4034                DNSSEC Resource Records               March 2005
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . .  3
+       1.1.  Background and Related Documents . . . . . . . . . . .  3
+       1.2.  Reserved Words . . . . . . . . . . . . . . . . . . . .  3
+   2.  The DNSKEY Resource Record . . . . . . . . . . . . . . . . .  4
+       2.1.  DNSKEY RDATA Wire Format . . . . . . . . . . . . . . .  4
+             2.1.1.  The Flags Field. . . . . . . . . . . . . . . .  4
+             2.1.2.  The Protocol Field . . . . . . . . . . . . . .  5
+             2.1.3.  The Algorithm Field. . . . . . . . . . . . . .  5
+             2.1.4.  The Public Key Field . . . . . . . . . . . . .  5
+             2.1.5.  Notes on DNSKEY RDATA Design . . . . . . . . .  5
+       2.2.  The DNSKEY RR Presentation Format. . . . . . . . . . .  5
+       2.3.  DNSKEY RR Example  . . . . . . . . . . . . . . . . . .  6
+   3.  The RRSIG Resource Record  . . . . . . . . . . . . . . . . .  6
+       3.1.  RRSIG RDATA Wire Format. . . . . . . . . . . . . . . .  7
+             3.1.1.  The Type Covered Field . . . . . . . . . . . .  7
+             3.1.2.  The Algorithm Number Field . . . . . . . . . .  8
+             3.1.3.  The Labels Field . . . . . . . . . . . . . . .  8
+             3.1.4.  Original TTL Field . . . . . . . . . . . . . .  8
+             3.1.5.  Signature Expiration and Inception Fields. . .  9
+             3.1.6.  The Key Tag Field. . . . . . . . . . . . . . .  9
+             3.1.7.  The Signer's Name Field. . . . . . . . . . . .  9
+             3.1.8.  The Signature Field. . . . . . . . . . . . . .  9
+       3.2.  The RRSIG RR Presentation Format . . . . . . . . . . . 10
+       3.3.  RRSIG RR Example . . . . . . . . . . . . . . . . . . . 11
+   4.  The NSEC Resource Record . . . . . . . . . . . . . . . . . . 12
+       4.1.  NSEC RDATA Wire Format . . . . . . . . . . . . . . . . 13
+             4.1.1.  The Next Domain Name Field . . . . . . . . . . 13
+             4.1.2.  The Type Bit Maps Field. . . . . . . . . . . . 13
+             4.1.3.  Inclusion of Wildcard Names in NSEC RDATA. . . 14
+       4.2.  The NSEC RR Presentation Format. . . . . . . . . . . . 14
+       4.3.  NSEC RR Example. . . . . . . . . . . . . . . . . . . . 15
+   5.  The DS Resource Record . . . . . . . . . . . . . . . . . . . 15
+       5.1.  DS RDATA Wire Format . . . . . . . . . . . . . . . . . 16
+             5.1.1.  The Key Tag Field. . . . . . . . . . . . . . . 16
+             5.1.2.  The Algorithm Field. . . . . . . . . . . . . . 16
+             5.1.3.  The Digest Type Field. . . . . . . . . . . . . 17
+             5.1.4.  The Digest Field . . . . . . . . . . . . . . . 17
+       5.2.  Processing of DS RRs When Validating Responses . . . . 17
+       5.3.  The DS RR Presentation Format. . . . . . . . . . . . . 17
+       5.4.  DS RR Example. . . . . . . . . . . . . . . . . . . . . 18
+   6.  Canonical Form and Order of Resource Records . . . . . . . . 18
+       6.1.  Canonical DNS Name Order . . . . . . . . . . . . . . . 18
+       6.2.  Canonical RR Form. . . . . . . . . . . . . . . . . . . 19
+       6.3.  Canonical RR Ordering within an RRset. . . . . . . . . 20
+   7.  IANA Considerations. . . . . . . . . . . . . . . . . . . . . 20
+   8.  Security Considerations. . . . . . . . . . . . . . . . . . . 21
+
+
+
+Arends, et al.              Standards Track                     [Page 2]
+
+RFC 4034                DNSSEC Resource Records               March 2005
+
+
+   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22
+   10. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
+       10.1. Normative References . . . . . . . . . . . . . . . . . 22
+       10.2. Informative References . . . . . . . . . . . . . . . . 23
+   A.  DNSSEC Algorithm and Digest Types. . . . . . . . . . . . . . 24
+       A.1.  DNSSEC Algorithm Types . . . . . . . . . . . . . . . . 24
+             A.1.1.  Private Algorithm Types. . . . . . . . . . . . 25
+       A.2.  DNSSEC Digest Types. . . . . . . . . . . . . . . . . . 25
+   B.  Key Tag Calculation. . . . . . . . . . . . . . . . . . . . . 25
+       B.1.  Key Tag for Algorithm 1 (RSA/MD5). . . . . . . . . . . 27
+   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
+   Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 29
+
+1.  Introduction
+
+   The DNS Security Extensions (DNSSEC) introduce four new DNS resource
+   record types: DNS Public Key (DNSKEY), Resource Record Signature
+   (RRSIG), Next Secure (NSEC), and Delegation Signer (DS).  This
+   document defines the purpose of each resource record (RR), the RR's
+   RDATA format, and its presentation format (ASCII representation).
+
+1.1.  Background and Related Documents
+
+   This document is part of a family of documents defining DNSSEC, which
+   should be read together as a set.
+
+   [RFC4033] contains an introduction to DNSSEC and definition of common
+   terms; the reader is assumed to be familiar with this document.
+   [RFC4033] also contains a list of other documents updated by and
+   obsoleted by this document set.
+
+   [RFC4035] defines the DNSSEC protocol operations.
+
+   The reader is also assumed to be familiar with the basic DNS concepts
+   described in [RFC1034], [RFC1035], and the subsequent documents that
+   update them, particularly [RFC2181] and [RFC2308].
+
+   This document defines the DNSSEC resource records.  All numeric DNS
+   type codes given in this document are decimal integers.
+
+1.2.  Reserved Words
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC2119].
+
+
+
+
+
+
+Arends, et al.              Standards Track                     [Page 3]
+
+RFC 4034                DNSSEC Resource Records               March 2005
+
+
+2.  The DNSKEY Resource Record
+
+   DNSSEC uses public key cryptography to sign and authenticate DNS
+   resource record sets (RRsets).  The public keys are stored in DNSKEY
+   resource records and are used in the DNSSEC authentication process
+   described in [RFC4035]: A zone signs its authoritative RRsets by
+   using a private key and stores the corresponding public key in a
+   DNSKEY RR.  A resolver can then use the public key to validate
+   signatures covering the RRsets in the zone, and thus to authenticate
+   them.
+
+   The DNSKEY RR is not intended as a record for storing arbitrary
+   public keys and MUST NOT be used to store certificates or public keys
+   that do not directly relate to the DNS infrastructure.
+
+   The Type value for the DNSKEY RR type is 48.
+
+   The DNSKEY RR is class independent.
+
+   The DNSKEY RR has no special TTL requirements.
+
+2.1.  DNSKEY RDATA Wire Format
+
+   The RDATA for a DNSKEY RR consists of a 2 octet Flags Field, a 1
+   octet Protocol Field, a 1 octet Algorithm Field, and the Public Key
+   Field.
+
+                        1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |              Flags            |    Protocol   |   Algorithm   |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   /                                                               /
+   /                            Public Key                         /
+   /                                                               /
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+2.1.1.  The Flags Field
+
+   Bit 7 of the Flags field is the Zone Key flag.  If bit 7 has value 1,
+   then the DNSKEY record holds a DNS zone key, and the DNSKEY RR's
+   owner name MUST be the name of a zone.  If bit 7 has value 0, then
+   the DNSKEY record holds some other type of DNS public key and MUST
+   NOT be used to verify RRSIGs that cover RRsets.
+
+   Bit 15 of the Flags field is the Secure Entry Point flag, described
+   in [RFC3757].  If bit 15 has value 1, then the DNSKEY record holds a
+   key intended for use as a secure entry point.  This flag is only
+
+
+
+Arends, et al.              Standards Track                     [Page 4]
+
+RFC 4034                DNSSEC Resource Records               March 2005
+
+
+   intended to be a hint to zone signing or debugging software as to the
+   intended use of this DNSKEY record; validators MUST NOT alter their
+   behavior during the signature validation process in any way based on
+   the setting of this bit.  This also means that a DNSKEY RR with the
+   SEP bit set would also need the Zone Key flag set in order to be able
+   to generate signatures legally.  A DNSKEY RR with the SEP set and the
+   Zone Key flag not set MUST NOT be used to verify RRSIGs that cover
+   RRsets.
+
+   Bits 0-6 and 8-14 are reserved: these bits MUST have value 0 upon
+   creation of the DNSKEY RR and MUST be ignored upon receipt.
+
+2.1.2.  The Protocol Field
+
+   The Protocol Field MUST have value 3, and the DNSKEY RR MUST be
+   treated as invalid during signature verification if it is found to be
+   some value other than 3.
+
+2.1.3.  The Algorithm Field
+
+   The Algorithm field identifies the public key's cryptographic
+   algorithm and determines the format of the Public Key field.  A list
+   of DNSSEC algorithm types can be found in Appendix A.1
+
+2.1.4.  The Public Key Field
+
+   The Public Key Field holds the public key material.  The format
+   depends on the algorithm of the key being stored and is described in
+   separate documents.
+
+2.1.5.  Notes on DNSKEY RDATA Design
+
+   Although the Protocol Field always has value 3, it is retained for
+   backward compatibility with early versions of the KEY record.
+
+2.2.  The DNSKEY RR Presentation Format
+
+   The presentation format of the RDATA portion is as follows:
+
+   The Flag field MUST be represented as an unsigned decimal integer.
+   Given the currently defined flags, the possible values are: 0, 256,
+   and 257.
+
+   The Protocol Field MUST be represented as an unsigned decimal integer
+   with a value of 3.
+
+   The Algorithm field MUST be represented either as an unsigned decimal
+   integer or as an algorithm mnemonic as specified in Appendix A.1.
+
+
+
+Arends, et al.              Standards Track                     [Page 5]
+
+RFC 4034                DNSSEC Resource Records               March 2005
+
+
+   The Public Key field MUST be represented as a Base64 encoding of the
+   Public Key.  Whitespace is allowed within the Base64 text.  For a
+   definition of Base64 encoding, see [RFC3548].
+
+2.3.  DNSKEY RR Example
+
+   The following DNSKEY RR stores a DNS zone key for example.com.
+
+   example.com. 86400 IN DNSKEY 256 3 5 ( AQPSKmynfzW4kyBv015MUG2DeIQ3
+                                          Cbl+BBZH4b/0PY1kxkmvHjcZc8no
+                                          kfzj31GajIQKY+5CptLr3buXA10h
+                                          WqTkF7H6RfoRqXQeogmMHfpftf6z
+                                          Mv1LyBUgia7za6ZEzOJBOztyvhjL
+                                          742iU/TpPSEDhm2SNKLijfUppn1U
+                                          aNvv4w==  )
+
+   The first four text fields specify the owner name, TTL, Class, and RR
+   type (DNSKEY).  Value 256 indicates that the Zone Key bit (bit 7) in
+   the Flags field has value 1.  Value 3 is the fixed Protocol value.
+   Value 5 indicates the public key algorithm.  Appendix A.1 identifies
+   algorithm type 5 as RSA/SHA1 and indicates that the format of the
+   RSA/SHA1 public key field is defined in [RFC3110].  The remaining
+   text is a Base64 encoding of the public key.
+
+3.  The RRSIG Resource Record
+
+   DNSSEC uses public key cryptography to sign and authenticate DNS
+   resource record sets (RRsets).  Digital signatures are stored in
+   RRSIG resource records and are used in the DNSSEC authentication
+   process described in [RFC4035].  A validator can use these RRSIG RRs
+   to authenticate RRsets from the zone.  The RRSIG RR MUST only be used
+   to carry verification material (digital signatures) used to secure
+   DNS operations.
+
+   An RRSIG record contains the signature for an RRset with a particular
+   name, class, and type.  The RRSIG RR specifies a validity interval
+   for the signature and uses the Algorithm, the Signer's Name, and the
+   Key Tag to identify the DNSKEY RR containing the public key that a
+   validator can use to verify the signature.
+
+   Because every authoritative RRset in a zone must be protected by a
+   digital signature, RRSIG RRs must be present for names containing a
+   CNAME RR.  This is a change to the traditional DNS specification
+   [RFC1034], which stated that if a CNAME is present for a name, it is
+   the only type allowed at that name.  A RRSIG and NSEC (see Section 4)
+   MUST exist for the same name as a CNAME resource record in a signed
+   zone.
+
+
+
+
+Arends, et al.              Standards Track                     [Page 6]
+
+RFC 4034                DNSSEC Resource Records               March 2005
+
+
+   The Type value for the RRSIG RR type is 46.
+
+   The RRSIG RR is class independent.
+
+   An RRSIG RR MUST have the same class as the RRset it covers.
+
+   The TTL value of an RRSIG RR MUST match the TTL value of the RRset it
+   covers.  This is an exception to the [RFC2181] rules for TTL values
+   of individual RRs within a RRset: individual RRSIG RRs with the same
+   owner name will have different TTL values if the RRsets they cover
+   have different TTL values.
+
+3.1.  RRSIG RDATA Wire Format
+
+   The RDATA for an RRSIG RR consists of a 2 octet Type Covered field, a
+   1 octet Algorithm field, a 1 octet Labels field, a 4 octet Original
+   TTL field, a 4 octet Signature Expiration field, a 4 octet Signature
+   Inception field, a 2 octet Key tag, the Signer's Name field, and the
+   Signature field.
+
+                        1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |        Type Covered           |  Algorithm    |     Labels    |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                         Original TTL                          |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                      Signature Expiration                     |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                      Signature Inception                      |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |            Key Tag            |                               /
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+         Signer's Name         /
+   /                                                               /
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   /                                                               /
+   /                            Signature                          /
+   /                                                               /
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+3.1.1.  The Type Covered Field
+
+   The Type Covered field identifies the type of the RRset that is
+   covered by this RRSIG record.
+
+
+
+
+
+
+
+Arends, et al.              Standards Track                     [Page 7]
+
+RFC 4034                DNSSEC Resource Records               March 2005
+
+
+3.1.2.  The Algorithm Number Field
+
+   The Algorithm Number field identifies the cryptographic algorithm
+   used to create the signature.  A list of DNSSEC algorithm types can
+   be found in Appendix A.1
+
+3.1.3.  The Labels Field
+
+   The Labels field specifies the number of labels in the original RRSIG
+   RR owner name.  The significance of this field is that a validator
+   uses it to determine whether the answer was synthesized from a
+   wildcard.  If so, it can be used to determine what owner name was
+   used in generating the signature.
+
+   To validate a signature, the validator needs the original owner name
+   that was used to create the signature.  If the original owner name
+   contains a wildcard label ("*"), the owner name may have been
+   expanded by the server during the response process, in which case the
+   validator will have to reconstruct the original owner name in order
+   to validate the signature.  [RFC4035] describes how to use the Labels
+   field to reconstruct the original owner name.
+
+   The value of the Labels field MUST NOT count either the null (root)
+   label that terminates the owner name or the wildcard label (if
+   present).  The value of the Labels field MUST be less than or equal
+   to the number of labels in the RRSIG owner name.  For example,
+   "www.example.com." has a Labels field value of 3, and
+   "*.example.com." has a Labels field value of 2.  Root (".") has a
+   Labels field value of 0.
+
+   Although the wildcard label is not included in the count stored in
+   the Labels field of the RRSIG RR, the wildcard label is part of the
+   RRset's owner name when the signature is generated or verified.
+
+3.1.4.  Original TTL Field
+
+   The Original TTL field specifies the TTL of the covered RRset as it
+   appears in the authoritative zone.
+
+   The Original TTL field is necessary because a caching resolver
+   decrements the TTL value of a cached RRset.  In order to validate a
+   signature, a validator requires the original TTL.  [RFC4035]
+   describes how to use the Original TTL field value to reconstruct the
+   original TTL.
+
+
+
+
+
+
+
+Arends, et al.              Standards Track                     [Page 8]
+
+RFC 4034                DNSSEC Resource Records               March 2005
+
+
+3.1.5.  Signature Expiration and Inception Fields
+
+   The Signature Expiration and Inception fields specify a validity
+   period for the signature.  The RRSIG record MUST NOT be used for
+   authentication prior to the inception date and MUST NOT be used for
+   authentication after the expiration date.
+
+   The Signature Expiration and Inception field values specify a date
+   and time in the form of a 32-bit unsigned number of seconds elapsed
+   since 1 January 1970 00:00:00 UTC, ignoring leap seconds, in network
+   byte order.  The longest interval that can be expressed by this
+   format without wrapping is approximately 136 years.  An RRSIG RR can
+   have an Expiration field value that is numerically smaller than the
+   Inception field value if the expiration field value is near the
+   32-bit wrap-around point or if the signature is long lived.  Because
+   of this, all comparisons involving these fields MUST use "Serial
+   number arithmetic", as defined in [RFC1982].  As a direct
+   consequence, the values contained in these fields cannot refer to
+   dates more than 68 years in either the past or the future.
+
+3.1.6.  The Key Tag Field
+
+   The Key Tag field contains the key tag value of the DNSKEY RR that
+   validates this signature, in network byte order.  Appendix B explains
+   how to calculate Key Tag values.
+
+3.1.7.  The Signer's Name Field
+
+   The Signer's Name field value identifies the owner name of the DNSKEY
+   RR that a validator is supposed to use to validate this signature.
+   The Signer's Name field MUST contain the name of the zone of the
+   covered RRset.  A sender MUST NOT use DNS name compression on the
+   Signer's Name field when transmitting a RRSIG RR.
+
+3.1.8.  The Signature Field
+
+   The Signature field contains the cryptographic signature that covers
+   the RRSIG RDATA (excluding the Signature field) and the RRset
+   specified by the RRSIG owner name, RRSIG class, and RRSIG Type
+   Covered field.  The format of this field depends on the algorithm in
+   use, and these formats are described in separate companion documents.
+
+3.1.8.1.  Signature Calculation
+
+   A signature covers the RRSIG RDATA (excluding the Signature Field)
+   and covers the data RRset specified by the RRSIG owner name, RRSIG
+   class, and RRSIG Type Covered fields.  The RRset is in canonical form
+   (see Section 6), and the set RR(1),...RR(n) is signed as follows:
+
+
+
+Arends, et al.              Standards Track                     [Page 9]
+
+RFC 4034                DNSSEC Resource Records               March 2005
+
+
+         signature = sign(RRSIG_RDATA | RR(1) | RR(2)... ) where
+
+            "|" denotes concatenation;
+
+            RRSIG_RDATA is the wire format of the RRSIG RDATA fields
+               with the Signer's Name field in canonical form and
+               the Signature field excluded;
+
+            RR(i) = owner | type | class | TTL | RDATA length | RDATA
+
+               "owner" is the fully qualified owner name of the RRset in
+               canonical form (for RRs with wildcard owner names, the
+               wildcard label is included in the owner name);
+
+               Each RR MUST have the same owner name as the RRSIG RR;
+
+               Each RR MUST have the same class as the RRSIG RR;
+
+               Each RR in the RRset MUST have the RR type listed in the
+               RRSIG RR's Type Covered field;
+
+               Each RR in the RRset MUST have the TTL listed in the
+               RRSIG Original TTL Field;
+
+               Any DNS names in the RDATA field of each RR MUST be in
+               canonical form; and
+
+               The RRset MUST be sorted in canonical order.
+
+   See Sections 6.2 and 6.3 for details on canonical form and ordering
+   of RRsets.
+
+3.2.  The RRSIG RR Presentation Format
+
+   The presentation format of the RDATA portion is as follows:
+
+   The Type Covered field is represented as an RR type mnemonic.  When
+   the mnemonic is not known, the TYPE representation as described in
+   [RFC3597], Section 5, MUST be used.
+
+   The Algorithm field value MUST be represented either as an unsigned
+   decimal integer or as an algorithm mnemonic, as specified in Appendix
+   A.1.
+
+   The Labels field value MUST be represented as an unsigned decimal
+   integer.
+
+
+
+
+
+Arends, et al.              Standards Track                    [Page 10]
+
+RFC 4034                DNSSEC Resource Records               March 2005
+
+
+   The Original TTL field value MUST be represented as an unsigned
+   decimal integer.
+
+   The Signature Expiration Time and Inception Time field values MUST be
+   represented either as an unsigned decimal integer indicating seconds
+   since 1 January 1970 00:00:00 UTC, or in the form YYYYMMDDHHmmSS in
+   UTC, where:
+
+      YYYY is the year (0001-9999, but see Section 3.1.5);
+      MM is the month number (01-12);
+      DD is the day of the month (01-31);
+      HH is the hour, in 24 hour notation (00-23);
+      mm is the minute (00-59); and
+      SS is the second (00-59).
+
+   Note that it is always possible to distinguish between these two
+   formats because the YYYYMMDDHHmmSS format will always be exactly 14
+   digits, while the decimal representation of a 32-bit unsigned integer
+   can never be longer than 10 digits.
+
+   The Key Tag field MUST be represented as an unsigned decimal integer.
+
+   The Signer's Name field value MUST be represented as a domain name.
+
+   The Signature field is represented as a Base64 encoding of the
+   signature.  Whitespace is allowed within the Base64 text.  See
+   Section 2.2.
+
+3.3.  RRSIG RR Example
+
+   The following RRSIG RR stores the signature for the A RRset of
+   host.example.com:
+
+   host.example.com. 86400 IN RRSIG A 5 3 86400 20030322173103 (
+                                  20030220173103 2642 example.com.
+                                  oJB1W6WNGv+ldvQ3WDG0MQkg5IEhjRip8WTr
+                                  PYGv07h108dUKGMeDPKijVCHX3DDKdfb+v6o
+                                  B9wfuh3DTJXUAfI/M0zmO/zz8bW0Rznl8O3t
+                                  GNazPwQKkRN20XPXV6nwwfoXmJQbsLNrLfkG
+                                  J5D6fwFm8nN+6pBzeDQfsS3Ap3o= )
+
+   The first four fields specify the owner name, TTL, Class, and RR type
+   (RRSIG).  The "A" represents the Type Covered field.  The value 5
+   identifies the algorithm used (RSA/SHA1) to create the signature.
+   The value 3 is the number of Labels in the original owner name.  The
+   value 86400 in the RRSIG RDATA is the Original TTL for the covered A
+   RRset.  20030322173103 and 20030220173103 are the expiration and
+
+
+
+
+Arends, et al.              Standards Track                    [Page 11]
+
+RFC 4034                DNSSEC Resource Records               March 2005
+
+
+   inception dates, respectively.  2642 is the Key Tag, and example.com.
+   is the Signer's Name.  The remaining text is a Base64 encoding of the
+   signature.
+
+   Note that combination of RRSIG RR owner name, class, and Type Covered
+   indicates that this RRSIG covers the "host.example.com" A RRset.  The
+   Label value of 3 indicates that no wildcard expansion was used.  The
+   Algorithm, Signer's Name, and Key Tag indicate that this signature
+   can be authenticated using an example.com zone DNSKEY RR whose
+   algorithm is 5 and whose key tag is 2642.
+
+4.  The NSEC Resource Record
+
+   The NSEC resource record lists two separate things: the next owner
+   name (in the canonical ordering of the zone) that contains
+   authoritative data or a delegation point NS RRset, and the set of RR
+   types present at the NSEC RR's owner name [RFC3845].  The complete
+   set of NSEC RRs in a zone indicates which authoritative RRsets exist
+   in a zone and also form a chain of authoritative owner names in the
+   zone.  This information is used to provide authenticated denial of
+   existence for DNS data, as described in [RFC4035].
+
+   Because every authoritative name in a zone must be part of the NSEC
+   chain, NSEC RRs must be present for names containing a CNAME RR.
+   This is a change to the traditional DNS specification [RFC1034],
+   which stated that if a CNAME is present for a name, it is the only
+   type allowed at that name.  An RRSIG (see Section 3) and NSEC MUST
+   exist for the same name as does a CNAME resource record in a signed
+   zone.
+
+   See [RFC4035] for discussion of how a zone signer determines
+   precisely which NSEC RRs it has to include in a zone.
+
+   The type value for the NSEC RR is 47.
+
+   The NSEC RR is class independent.
+
+   The NSEC RR SHOULD have the same TTL value as the SOA minimum TTL
+   field.  This is in the spirit of negative caching ([RFC2308]).
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al.              Standards Track                    [Page 12]
+
+RFC 4034                DNSSEC Resource Records               March 2005
+
+
+4.1.  NSEC RDATA Wire Format
+
+   The RDATA of the NSEC RR is as shown below:
+
+                        1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   /                      Next Domain Name                         /
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   /                       Type Bit Maps                           /
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+4.1.1.  The Next Domain Name Field
+
+   The Next Domain field contains the next owner name (in the canonical
+   ordering of the zone) that has authoritative data or contains a
+   delegation point NS RRset; see Section 6.1 for an explanation of
+   canonical ordering.  The value of the Next Domain Name field in the
+   last NSEC record in the zone is the name of the zone apex (the owner
+   name of the zone's SOA RR).  This indicates that the owner name of
+   the NSEC RR is the last name in the canonical ordering of the zone.
+
+   A sender MUST NOT use DNS name compression on the Next Domain Name
+   field when transmitting an NSEC RR.
+
+   Owner names of RRsets for which the given zone is not authoritative
+   (such as glue records) MUST NOT be listed in the Next Domain Name
+   unless at least one authoritative RRset exists at the same owner
+   name.
+
+4.1.2.  The Type Bit Maps Field
+
+   The Type Bit Maps field identifies the RRset types that exist at the
+   NSEC RR's owner name.
+
+   The RR type space is split into 256 window blocks, each representing
+   the low-order 8 bits of the 16-bit RR type space.  Each block that
+   has at least one active RR type is encoded using a single octet
+   window number (from 0 to 255), a single octet bitmap length (from 1
+   to 32) indicating the number of octets used for the window block's
+   bitmap, and up to 32 octets (256 bits) of bitmap.
+
+   Blocks are present in the NSEC RR RDATA in increasing numerical
+   order.
+
+      Type Bit Maps Field = ( Window Block # | Bitmap Length | Bitmap )+
+
+      where "|" denotes concatenation.
+
+
+
+Arends, et al.              Standards Track                    [Page 13]
+
+RFC 4034                DNSSEC Resource Records               March 2005
+
+
+   Each bitmap encodes the low-order 8 bits of RR types within the
+   window block, in network bit order.  The first bit is bit 0.  For
+   window block 0, bit 1 corresponds to RR type 1 (A), bit 2 corresponds
+   to RR type 2 (NS), and so forth.  For window block 1, bit 1
+   corresponds to RR type 257, and bit 2 to RR type 258.  If a bit is
+   set, it indicates that an RRset of that type is present for the NSEC
+   RR's owner name.  If a bit is clear, it indicates that no RRset of
+   that type is present for the NSEC RR's owner name.
+
+   Bits representing pseudo-types MUST be clear, as they do not appear
+   in zone data.  If encountered, they MUST be ignored upon being read.
+
+   Blocks with no types present MUST NOT be included.  Trailing zero
+   octets in the bitmap MUST be omitted.  The length of each block's
+   bitmap is determined by the type code with the largest numerical
+   value, within that block, among the set of RR types present at the
+   NSEC RR's owner name.  Trailing zero octets not specified MUST be
+   interpreted as zero octets.
+
+   The bitmap for the NSEC RR at a delegation point requires special
+   attention.  Bits corresponding to the delegation NS RRset and the RR
+   types for which the parent zone has authoritative data MUST be set;
+   bits corresponding to any non-NS RRset for which the parent is not
+   authoritative MUST be clear.
+
+   A zone MUST NOT include an NSEC RR for any domain name that only
+   holds glue records.
+
+4.1.3.  Inclusion of Wildcard Names in NSEC RDATA
+
+   If a wildcard owner name appears in a zone, the wildcard label ("*")
+   is treated as a literal symbol and is treated the same as any other
+   owner name for the purposes of generating NSEC RRs.  Wildcard owner
+   names appear in the Next Domain Name field without any wildcard
+   expansion.  [RFC4035] describes the impact of wildcards on
+   authenticated denial of existence.
+
+4.2.  The NSEC RR Presentation Format
+
+   The presentation format of the RDATA portion is as follows:
+
+   The Next Domain Name field is represented as a domain name.
+
+   The Type Bit Maps field is represented as a sequence of RR type
+   mnemonics.  When the mnemonic is not known, the TYPE representation
+   described in [RFC3597], Section 5, MUST be used.
+
+
+
+
+
+Arends, et al.              Standards Track                    [Page 14]
+
+RFC 4034                DNSSEC Resource Records               March 2005
+
+
+4.3.  NSEC RR Example
+
+   The following NSEC RR identifies the RRsets associated with
+   alfa.example.com. and identifies the next authoritative name after
+   alfa.example.com.
+
+   alfa.example.com. 86400 IN NSEC host.example.com. (
+                                   A MX RRSIG NSEC TYPE1234 )
+
+   The first four text fields specify the name, TTL, Class, and RR type
+   (NSEC).  The entry host.example.com. is the next authoritative name
+   after alfa.example.com. in canonical order.  The A, MX, RRSIG, NSEC,
+   and TYPE1234 mnemonics indicate that there are A, MX, RRSIG, NSEC,
+   and TYPE1234 RRsets associated with the name alfa.example.com.
+
+   The RDATA section of the NSEC RR above would be encoded as:
+
+            0x04 'h'  'o'  's'  't'
+            0x07 'e'  'x'  'a'  'm'  'p'  'l'  'e'
+            0x03 'c'  'o'  'm'  0x00
+            0x00 0x06 0x40 0x01 0x00 0x00 0x00 0x03
+            0x04 0x1b 0x00 0x00 0x00 0x00 0x00 0x00
+            0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
+            0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
+            0x00 0x00 0x00 0x00 0x20
+
+   Assuming that the validator can authenticate this NSEC record, it
+   could be used to prove that beta.example.com does not exist, or to
+   prove that there is no AAAA record associated with alfa.example.com.
+   Authenticated denial of existence is discussed in [RFC4035].
+
+5.  The DS Resource Record
+
+   The DS Resource Record refers to a DNSKEY RR and is used in the DNS
+   DNSKEY authentication process.  A DS RR refers to a DNSKEY RR by
+   storing the key tag, algorithm number, and a digest of the DNSKEY RR.
+   Note that while the digest should be sufficient to identify the
+   public key, storing the key tag and key algorithm helps make the
+   identification process more efficient.  By authenticating the DS
+   record, a resolver can authenticate the DNSKEY RR to which the DS
+   record points.  The key authentication process is described in
+   [RFC4035].
+
+   The DS RR and its corresponding DNSKEY RR have the same owner name,
+   but they are stored in different locations.  The DS RR appears only
+   on the upper (parental) side of a delegation, and is authoritative
+   data in the parent zone.  For example, the DS RR for "example.com" is
+   stored in the "com" zone (the parent zone) rather than in the
+
+
+
+Arends, et al.              Standards Track                    [Page 15]
+
+RFC 4034                DNSSEC Resource Records               March 2005
+
+
+   "example.com" zone (the child zone).  The corresponding DNSKEY RR is
+   stored in the "example.com" zone (the child zone).  This simplifies
+   DNS zone management and zone signing but introduces special response
+   processing requirements for the DS RR; these are described in
+   [RFC4035].
+
+   The type number for the DS record is 43.
+
+   The DS resource record is class independent.
+
+   The DS RR has no special TTL requirements.
+
+5.1.  DS RDATA Wire Format
+
+   The RDATA for a DS RR consists of a 2 octet Key Tag field, a 1 octet
+   Algorithm field, a 1 octet Digest Type field, and a Digest field.
+
+                        1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |           Key Tag             |  Algorithm    |  Digest Type  |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   /                                                               /
+   /                            Digest                             /
+   /                                                               /
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+5.1.1.  The Key Tag Field
+
+   The Key Tag field lists the key tag of the DNSKEY RR referred to by
+   the DS record, in network byte order.
+
+   The Key Tag used by the DS RR is identical to the Key Tag used by
+   RRSIG RRs.  Appendix B describes how to compute a Key Tag.
+
+5.1.2.  The Algorithm Field
+
+   The Algorithm field lists the algorithm number of the DNSKEY RR
+   referred to by the DS record.
+
+   The algorithm number used by the DS RR is identical to the algorithm
+   number used by RRSIG and DNSKEY RRs.  Appendix A.1 lists the
+   algorithm number types.
+
+
+
+
+
+
+
+
+Arends, et al.              Standards Track                    [Page 16]
+
+RFC 4034                DNSSEC Resource Records               March 2005
+
+
+5.1.3.  The Digest Type Field
+
+   The DS RR refers to a DNSKEY RR by including a digest of that DNSKEY
+   RR.  The Digest Type field identifies the algorithm used to construct
+   the digest.  Appendix A.2 lists the possible digest algorithm types.
+
+5.1.4.  The Digest Field
+
+   The DS record refers to a DNSKEY RR by including a digest of that
+   DNSKEY RR.
+
+   The digest is calculated by concatenating the canonical form of the
+   fully qualified owner name of the DNSKEY RR with the DNSKEY RDATA,
+   and then applying the digest algorithm.
+
+     digest = digest_algorithm( DNSKEY owner name | DNSKEY RDATA);
+
+      "|" denotes concatenation
+
+     DNSKEY RDATA = Flags | Protocol | Algorithm | Public Key.
+
+   The size of the digest may vary depending on the digest algorithm and
+   DNSKEY RR size.  As of the time of this writing, the only defined
+   digest algorithm is SHA-1, which produces a 20 octet digest.
+
+5.2.  Processing of DS RRs When Validating Responses
+
+   The DS RR links the authentication chain across zone boundaries, so
+   the DS RR requires extra care in processing.  The DNSKEY RR referred
+   to in the DS RR MUST be a DNSSEC zone key.  The DNSKEY RR Flags MUST
+   have Flags bit 7 set.  If the DNSKEY flags do not indicate a DNSSEC
+   zone key, the DS RR (and the DNSKEY RR it references) MUST NOT be
+   used in the validation process.
+
+5.3.  The DS RR Presentation Format
+
+   The presentation format of the RDATA portion is as follows:
+
+   The Key Tag field MUST be represented as an unsigned decimal integer.
+
+   The Algorithm field MUST be represented either as an unsigned decimal
+   integer or as an algorithm mnemonic specified in Appendix A.1.
+
+   The Digest Type field MUST be represented as an unsigned decimal
+   integer.
+
+
+
+
+
+
+Arends, et al.              Standards Track                    [Page 17]
+
+RFC 4034                DNSSEC Resource Records               March 2005
+
+
+   The Digest MUST be represented as a sequence of case-insensitive
+   hexadecimal digits.  Whitespace is allowed within the hexadecimal
+   text.
+
+5.4.  DS RR Example
+
+   The following example shows a DNSKEY RR and its corresponding DS RR.
+
+   dskey.example.com. 86400 IN DNSKEY 256 3 5 ( AQOeiiR0GOMYkDshWoSKz9Xz
+                                             fwJr1AYtsmx3TGkJaNXVbfi/
+                                             2pHm822aJ5iI9BMzNXxeYCmZ
+                                             DRD99WYwYqUSdjMmmAphXdvx
+                                             egXd/M5+X7OrzKBaMbCVdFLU
+                                             Uh6DhweJBjEVv5f2wwjM9Xzc
+                                             nOf+EPbtG9DMBmADjFDc2w/r
+                                             ljwvFw==
+                                             ) ;  key id = 60485
+
+   dskey.example.com. 86400 IN DS 60485 5 1 ( 2BB183AF5F22588179A53B0A
+                                              98631FAD1A292118 )
+
+   The first four text fields specify the name, TTL, Class, and RR type
+   (DS).  Value 60485 is the key tag for the corresponding
+   "dskey.example.com." DNSKEY RR, and value 5 denotes the algorithm
+   used by this "dskey.example.com." DNSKEY RR.  The value 1 is the
+   algorithm used to construct the digest, and the rest of the RDATA
+   text is the digest in hexadecimal.
+
+6.  Canonical Form and Order of Resource Records
+
+   This section defines a canonical form for resource records, a
+   canonical ordering of DNS names, and a canonical ordering of resource
+   records within an RRset.  A canonical name order is required to
+   construct the NSEC name chain.  A canonical RR form and ordering
+   within an RRset are required in order to construct and verify RRSIG
+   RRs.
+
+6.1.  Canonical DNS Name Order
+
+   For the purposes of DNS security, owner names are ordered by treating
+   individual labels as unsigned left-justified octet strings.  The
+   absence of a octet sorts before a zero value octet, and uppercase
+   US-ASCII letters are treated as if they were lowercase US-ASCII
+   letters.
+
+
+
+
+
+
+
+Arends, et al.              Standards Track                    [Page 18]
+
+RFC 4034                DNSSEC Resource Records               March 2005
+
+
+   To compute the canonical ordering of a set of DNS names, start by
+   sorting the names according to their most significant (rightmost)
+   labels.  For names in which the most significant label is identical,
+   continue sorting according to their next most significant label, and
+   so forth.
+
+   For example, the following names are sorted in canonical DNS name
+   order.  The most significant label is "example".  At this level,
+   "example" sorts first, followed by names ending in "a.example", then
+   by names ending "z.example".  The names within each level are sorted
+   in the same way.
+
+             example
+             a.example
+             yljkjljk.a.example
+             Z.a.example
+             zABC.a.EXAMPLE
+             z.example
+             \001.z.example
+             *.z.example
+             \200.z.example
+
+6.2.  Canonical RR Form
+
+   For the purposes of DNS security, the canonical form of an RR is the
+   wire format of the RR where:
+
+   1.  every domain name in the RR is fully expanded (no DNS name
+       compression) and fully qualified;
+
+   2.  all uppercase US-ASCII letters in the owner name of the RR are
+       replaced by the corresponding lowercase US-ASCII letters;
+
+   3.  if the type of the RR is NS, MD, MF, CNAME, SOA, MB, MG, MR, PTR,
+       HINFO, MINFO, MX, HINFO, RP, AFSDB, RT, SIG, PX, NXT, NAPTR, KX,
+       SRV, DNAME, A6, RRSIG, or NSEC, all uppercase US-ASCII letters in
+       the DNS names contained within the RDATA are replaced by the
+       corresponding lowercase US-ASCII letters;
+
+   4.  if the owner name of the RR is a wildcard name, the owner name is
+       in its original unexpanded form, including the "*" label (no
+       wildcard substitution); and
+
+   5.  the RR's TTL is set to its original value as it appears in the
+       originating authoritative zone or the Original TTL field of the
+       covering RRSIG RR.
+
+
+
+
+
+Arends, et al.              Standards Track                    [Page 19]
+
+RFC 4034                DNSSEC Resource Records               March 2005
+
+
+6.3.  Canonical RR Ordering within an RRset
+
+   For the purposes of DNS security, RRs with the same owner name,
+   class, and type are sorted by treating the RDATA portion of the
+   canonical form of each RR as a left-justified unsigned octet sequence
+   in which the absence of an octet sorts before a zero octet.
+
+   [RFC2181] specifies that an RRset is not allowed to contain duplicate
+   records (multiple RRs with the same owner name, class, type, and
+   RDATA).  Therefore, if an implementation detects duplicate RRs when
+   putting the RRset in canonical form, it MUST treat this as a protocol
+   error.  If the implementation chooses to handle this protocol error
+   in the spirit of the robustness principle (being liberal in what it
+   accepts), it MUST remove all but one of the duplicate RR(s) for the
+   purposes of calculating the canonical form of the RRset.
+
+7.  IANA Considerations
+
+   This document introduces no new IANA considerations, as all of the
+   protocol parameters used in this document have already been assigned
+   by previous specifications.  However, since the evolution of DNSSEC
+   has been long and somewhat convoluted, this section attempts to
+   describe the current state of the IANA registries and other protocol
+   parameters that are (or once were) related to DNSSEC.
+
+   Please refer to [RFC4035] for additional IANA considerations.
+
+   DNS Resource Record Types: [RFC2535] assigned types 24, 25, and 30 to
+      the SIG, KEY, and NXT RRs, respectively.  [RFC3658] assigned DNS
+      Resource Record Type 43 to DS.  [RFC3755] assigned types 46, 47,
+      and 48 to the RRSIG, NSEC, and DNSKEY RRs, respectively.
+      [RFC3755] also marked type 30 (NXT) as Obsolete and restricted use
+      of types 24 (SIG) and 25 (KEY) to the "SIG(0)" transaction
+      security protocol described in [RFC2931] and to the transaction
+      KEY Resource Record described in [RFC2930].
+
+   DNS Security Algorithm Numbers: [RFC2535] created an IANA registry
+      for DNSSEC Resource Record Algorithm field numbers and assigned
+      values 1-4 and 252-255.  [RFC3110] assigned value 5.  [RFC3755]
+      altered this registry to include flags for each entry regarding
+      its use with the DNS security extensions.  Each algorithm entry
+      could refer to an algorithm that can be used for zone signing,
+      transaction security (see [RFC2931]), or both.  Values 6-251 are
+      available for assignment by IETF standards action ([RFC3755]).
+      See Appendix A for a full listing of the DNS Security Algorithm
+      Numbers entries at the time of this writing and their status for
+      use in DNSSEC.
+
+
+
+
+Arends, et al.              Standards Track                    [Page 20]
+
+RFC 4034                DNSSEC Resource Records               March 2005
+
+
+      [RFC3658] created an IANA registry for DNSSEC DS Digest Types and
+      assigned value 0 to reserved and value 1 to SHA-1.
+
+   KEY Protocol Values: [RFC2535] created an IANA Registry for KEY
+      Protocol Values, but [RFC3445] reassigned all values other than 3
+      to reserved and closed this IANA registry.  The registry remains
+      closed, and all KEY and DNSKEY records are required to have a
+      Protocol Octet value of 3.
+
+   Flag bits in the KEY and DNSKEY RRs: [RFC3755] created an IANA
+      registry for the DNSSEC KEY and DNSKEY RR flag bits.  Initially,
+      this registry only contains assignments for bit 7 (the ZONE bit)
+      and bit 15 (the Secure Entry Point flag (SEP) bit; see [RFC3757]).
+      As stated in [RFC3755], bits 0-6 and 8-14 are available for
+      assignment by IETF Standards Action.
+
+8.  Security Considerations
+
+   This document describes the format of four DNS resource records used
+   by the DNS security extensions and presents an algorithm for
+   calculating a key tag for a public key.  Other than the items
+   described below, the resource records themselves introduce no
+   security considerations.  Please see [RFC4033] and [RFC4035] for
+   additional security considerations related to the use of these
+   records.
+
+   The DS record points to a DNSKEY RR by using a cryptographic digest,
+   the key algorithm type, and a key tag.  The DS record is intended to
+   identify an existing DNSKEY RR, but it is theoretically possible for
+   an attacker to generate a DNSKEY that matches all the DS fields.  The
+   probability of constructing a matching DNSKEY depends on the type of
+   digest algorithm in use.  The only currently defined digest algorithm
+   is SHA-1, and the working group believes that constructing a public
+   key that would match the algorithm, key tag, and SHA-1 digest given
+   in a DS record would be a sufficiently difficult problem that such an
+   attack is not a serious threat at this time.
+
+   The key tag is used to help select DNSKEY resource records
+   efficiently, but it does not uniquely identify a single DNSKEY
+   resource record.  It is possible for two distinct DNSKEY RRs to have
+   the same owner name, the same algorithm type, and the same key tag.
+   An implementation that uses only the key tag to select a DNSKEY RR
+   might select the wrong public key in some circumstances.  Please see
+   Appendix B for further details.
+
+
+
+
+
+
+
+Arends, et al.              Standards Track                    [Page 21]
+
+RFC 4034                DNSSEC Resource Records               March 2005
+
+
+   The table of algorithms in Appendix A and the key tag calculation
+   algorithms in Appendix B include the RSA/MD5 algorithm for
+   completeness, but the RSA/MD5 algorithm is NOT RECOMMENDED, as
+   explained in [RFC3110].
+
+9.  Acknowledgements
+
+   This document was created from the input and ideas of the members of
+   the DNS Extensions Working Group and working group mailing list.  The
+   editors would like to express their thanks for the comments and
+   suggestions received during the revision of these security extension
+   specifications.  Although explicitly listing everyone who has
+   contributed during the decade in which DNSSEC has been under
+   development would be impossible, [RFC4033] includes a list of some of
+   the participants who were kind enough to comment on these documents.
+
+10.  References
+
+10.1.  Normative References
+
+   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
+              STD 13, RFC 1034, November 1987.
+
+   [RFC1035]  Mockapetris, P., "Domain names - implementation and
+              specification", STD 13, RFC 1035, November 1987.
+
+   [RFC1982]  Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
+              August 1996.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2181]  Elz, R. and R. Bush, "Clarifications to the DNS
+              Specification", RFC 2181, July 1997.
+
+   [RFC2308]  Andrews, M., "Negative Caching of DNS Queries (DNS
+              NCACHE)", RFC 2308, March 1998.
+
+   [RFC2536]  Eastlake 3rd, D., "DSA KEYs and SIGs in the Domain Name
+              System (DNS)", RFC 2536, March 1999.
+
+   [RFC2931]  Eastlake 3rd, D., "DNS Request and Transaction Signatures
+              ( SIG(0)s )", RFC 2931, September 2000.
+
+   [RFC3110]  Eastlake 3rd, D., "RSA/SHA-1 SIGs and RSA KEYs in the
+              Domain Name System (DNS)", RFC 3110, May 2001.
+
+
+
+
+
+Arends, et al.              Standards Track                    [Page 22]
+
+RFC 4034                DNSSEC Resource Records               March 2005
+
+
+   [RFC3445]  Massey, D. and S. Rose, "Limiting the Scope of the KEY
+              Resource Record (RR)", RFC 3445, December 2002.
+
+   [RFC3548]  Josefsson, S., "The Base16, Base32, and Base64 Data
+              Encodings", RFC 3548, July 2003.
+
+   [RFC3597]  Gustafsson, A., "Handling of Unknown DNS Resource Record
+              (RR) Types", RFC 3597, September 2003.
+
+   [RFC3658]  Gudmundsson, O., "Delegation Signer (DS) Resource Record
+              (RR)", RFC 3658, December 2003.
+
+   [RFC3755]  Weiler, S., "Legacy Resolver Compatibility for Delegation
+              Signer (DS)", RFC 3755, May 2004.
+
+   [RFC3757]  Kolkman, O., Schlyter, J., and E. Lewis, "Domain Name
+              System KEY (DNSKEY) Resource Record (RR) Secure Entry
+              Point (SEP) Flag", RFC 3757, April 2004.
+
+   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
+              Rose, "DNS Security Introduction and Requirements", RFC
+              4033, March 2005.
+
+   [RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
+              Rose, "Protocol Modifications for the DNS Security
+              Extensions", RFC 4035, March 2005.
+
+10.2.  Informative References
+
+   [RFC2535]  Eastlake 3rd, D., "Domain Name System Security
+              Extensions", RFC 2535, March 1999.
+
+   [RFC2537]  Eastlake 3rd, D., "RSA/MD5 KEYs and SIGs in the Domain
+              Name System (DNS)", RFC 2537, March 1999.
+
+   [RFC2539]  Eastlake 3rd, D., "Storage of Diffie-Hellman Keys in the
+              Domain Name System (DNS)", RFC 2539, March 1999.
+
+   [RFC2930]  Eastlake 3rd, D., "Secret Key Establishment for DNS (TKEY
+              RR)", RFC 2930, September 2000.
+
+   [RFC3845]  Schlyter, J., "DNS Security (DNSSEC) NextSECure (NSEC)
+              RDATA Format", RFC 3845, August 2004.
+
+
+
+
+
+
+
+
+Arends, et al.              Standards Track                    [Page 23]
+
+RFC 4034                DNSSEC Resource Records               March 2005
+
+
+Appendix A.  DNSSEC Algorithm and Digest Types
+
+   The DNS security extensions are designed to be independent of the
+   underlying cryptographic algorithms.  The DNSKEY, RRSIG, and DS
+   resource records all use a DNSSEC Algorithm Number to identify the
+   cryptographic algorithm in use by the resource record.  The DS
+   resource record also specifies a Digest Algorithm Number to identify
+   the digest algorithm used to construct the DS record.  The currently
+   defined Algorithm and Digest Types are listed below.  Additional
+   Algorithm or Digest Types could be added as advances in cryptography
+   warrant them.
+
+   A DNSSEC aware resolver or name server MUST implement all MANDATORY
+   algorithms.
+
+A.1.  DNSSEC Algorithm Types
+
+   The DNSKEY, RRSIG, and DS RRs use an 8-bit number to identify the
+   security algorithm being used.  These values are stored in the
+   "Algorithm number" field in the resource record RDATA.
+
+   Some algorithms are usable only for zone signing (DNSSEC), some only
+   for transaction security mechanisms (SIG(0) and TSIG), and some for
+   both.  Those usable for zone signing may appear in DNSKEY, RRSIG, and
+   DS RRs.  Those usable for transaction security would be present in
+   SIG(0) and KEY RRs, as described in [RFC2931].
+
+                                Zone
+   Value Algorithm [Mnemonic]  Signing  References   Status
+   ----- -------------------- --------- ----------  ---------
+     0   reserved
+     1   RSA/MD5 [RSAMD5]         n      [RFC2537]  NOT RECOMMENDED
+     2   Diffie-Hellman [DH]      n      [RFC2539]   -
+     3   DSA/SHA-1 [DSA]          y      [RFC2536]  OPTIONAL
+     4   Elliptic Curve [ECC]              TBA       -
+     5   RSA/SHA-1 [RSASHA1]      y      [RFC3110]  MANDATORY
+   252   Indirect [INDIRECT]      n                  -
+   253   Private [PRIVATEDNS]     y      see below  OPTIONAL
+   254   Private [PRIVATEOID]     y      see below  OPTIONAL
+   255   reserved
+
+   6 - 251  Available for assignment by IETF Standards Action.
+
+
+
+
+
+
+
+
+
+Arends, et al.              Standards Track                    [Page 24]
+
+RFC 4034                DNSSEC Resource Records               March 2005
+
+
+A.1.1.  Private Algorithm Types
+
+   Algorithm number 253 is reserved for private use and will never be
+   assigned to a specific algorithm.  The public key area in the DNSKEY
+   RR and the signature area in the RRSIG RR begin with a wire encoded
+   domain name, which MUST NOT be compressed.  The domain name indicates
+   the private algorithm to use, and the remainder of the public key
+   area is determined by that algorithm.  Entities should only use
+   domain names they control to designate their private algorithms.
+
+   Algorithm number 254 is reserved for private use and will never be
+   assigned to a specific algorithm.  The public key area in the DNSKEY
+   RR and the signature area in the RRSIG RR begin with an unsigned
+   length byte followed by a BER encoded Object Identifier (ISO OID) of
+   that length.  The OID indicates the private algorithm in use, and the
+   remainder of the area is whatever is required by that algorithm.
+   Entities should only use OIDs they control to designate their private
+   algorithms.
+
+A.2.  DNSSEC Digest Types
+
+   A "Digest Type" field in the DS resource record types identifies the
+   cryptographic digest algorithm used by the resource record.  The
+   following table lists the currently defined digest algorithm types.
+
+              VALUE   Algorithm                 STATUS
+                0      Reserved                   -
+                1      SHA-1                   MANDATORY
+              2-255    Unassigned                 -
+
+Appendix B.  Key Tag Calculation
+
+   The Key Tag field in the RRSIG and DS resource record types provides
+   a mechanism for selecting a public key efficiently.  In most cases, a
+   combination of owner name, algorithm, and key tag can efficiently
+   identify a DNSKEY record.  Both the RRSIG and DS resource records
+   have corresponding DNSKEY records.  The Key Tag field in the RRSIG
+   and DS records can be used to help select the corresponding DNSKEY RR
+   efficiently when more than one candidate DNSKEY RR is available.
+
+   However, it is essential to note that the key tag is not a unique
+   identifier.  It is theoretically possible for two distinct DNSKEY RRs
+   to have the same owner name, the same algorithm, and the same key
+   tag.  The key tag is used to limit the possible candidate keys, but
+   it does not uniquely identify a DNSKEY record.  Implementations MUST
+   NOT assume that the key tag uniquely identifies a DNSKEY RR.
+
+
+
+
+
+Arends, et al.              Standards Track                    [Page 25]
+
+RFC 4034                DNSSEC Resource Records               March 2005
+
+
+   The key tag is the same for all DNSKEY algorithm types except
+   algorithm 1 (please see Appendix B.1 for the definition of the key
+   tag for algorithm 1).  The key tag algorithm is the sum of the wire
+   format of the DNSKEY RDATA broken into 2 octet groups.  First, the
+   RDATA (in wire format) is treated as a series of 2 octet groups.
+   These groups are then added together, ignoring any carry bits.
+
+   A reference implementation of the key tag algorithm is as an ANSI C
+   function is given below, with the RDATA portion of the DNSKEY RR is
+   used as input.  It is not necessary to use the following reference
+   code verbatim, but the numerical value of the Key Tag MUST be
+   identical to what the reference implementation would generate for the
+   same input.
+
+   Please note that the algorithm for calculating the Key Tag is almost
+   but not completely identical to the familiar ones-complement checksum
+   used in many other Internet protocols.  Key Tags MUST be calculated
+   using the algorithm described here rather than the ones complement
+   checksum.
+
+   The following ANSI C reference implementation calculates the value of
+   a Key Tag.  This reference implementation applies to all algorithm
+   types except algorithm 1 (see Appendix B.1).  The input is the wire
+   format of the RDATA portion of the DNSKEY RR.  The code is written
+   for clarity, not efficiency.
+
+   /*
+    * Assumes that int is at least 16 bits.
+    * First octet of the key tag is the most significant 8 bits of the
+    * return value;
+    * Second octet of the key tag is the least significant 8 bits of the
+    * return value.
+    */
+
+   unsigned int
+   keytag (
+           unsigned char key[],  /* the RDATA part of the DNSKEY RR */
+           unsigned int keysize  /* the RDLENGTH */
+          )
+   {
+           unsigned long ac;     /* assumed to be 32 bits or larger */
+           int i;                /* loop index */
+
+           for ( ac = 0, i = 0; i < keysize; ++i )
+                   ac += (i & 1) ? key[i] : key[i] << 8;
+           ac += (ac >> 16) & 0xFFFF;
+           return ac & 0xFFFF;
+   }
+
+
+
+Arends, et al.              Standards Track                    [Page 26]
+
+RFC 4034                DNSSEC Resource Records               March 2005
+
+
+B.1.  Key Tag for Algorithm 1 (RSA/MD5)
+
+   The key tag for algorithm 1 (RSA/MD5) is defined differently from the
+   key tag for all other algorithms, for historical reasons.  For a
+   DNSKEY RR with algorithm 1, the key tag is defined to be the most
+   significant 16 bits of the least significant 24 bits in the public
+   key modulus (in other words, the 4th to last and 3rd to last octets
+   of the public key modulus).
+
+   Please note that Algorithm 1 is NOT RECOMMENDED.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al.              Standards Track                    [Page 27]
+
+RFC 4034                DNSSEC Resource Records               March 2005
+
+
+Authors' Addresses
+
+   Roy Arends
+   Telematica Instituut
+   Brouwerijstraat 1
+   7523 XC  Enschede
+   NL
+
+   EMail: roy.arends@telin.nl
+
+
+   Rob Austein
+   Internet Systems Consortium
+   950 Charter Street
+   Redwood City, CA  94063
+   USA
+
+   EMail: sra@isc.org
+
+
+   Matt Larson
+   VeriSign, Inc.
+   21345 Ridgetop Circle
+   Dulles, VA  20166-6503
+   USA
+
+   EMail: mlarson@verisign.com
+
+
+   Dan Massey
+   Colorado State University
+   Department of Computer Science
+   Fort Collins, CO 80523-1873
+
+   EMail: massey@cs.colostate.edu
+
+
+   Scott Rose
+   National Institute for Standards and Technology
+   100 Bureau Drive
+   Gaithersburg, MD  20899-8920
+   USA
+
+   EMail: scott.rose@nist.gov
+
+
+
+
+
+
+
+Arends, et al.              Standards Track                    [Page 28]
+
+RFC 4034                DNSSEC Resource Records               March 2005
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2005).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at ietf-
+   ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+Arends, et al.              Standards Track                    [Page 29]
+
diff --git a/doc/rfc/rfc4035.txt b/doc/rfc/rfc4035.txt
new file mode 100644
index 0000000..b701cd2
--- /dev/null
+++ b/doc/rfc/rfc4035.txt
@@ -0,0 +1,2971 @@
+
+
+
+
+
+
+Network Working Group                                          R. Arends
+Request for Comments: 4035                          Telematica Instituut
+Obsoletes: 2535, 3008, 3090, 3445, 3655, 3658,                R. Austein
+           3755, 3757, 3845                                          ISC
+Updates: 1034, 1035, 2136, 2181, 2308, 3225,                   M. Larson
+         3007, 3597, 3226                                       VeriSign
+Category: Standards Track                                      D. Massey
+                                               Colorado State University
+                                                                 S. Rose
+                                                                    NIST
+                                                              March 2005
+
+
+         Protocol Modifications for the DNS Security Extensions
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).
+
+Abstract
+
+   This document is part of a family of documents that describe the DNS
+   Security Extensions (DNSSEC).  The DNS Security Extensions are a
+   collection of new resource records and protocol modifications that
+   add data origin authentication and data integrity to the DNS.  This
+   document describes the DNSSEC protocol modifications.  This document
+   defines the concept of a signed zone, along with the requirements for
+   serving and resolving by using DNSSEC.  These techniques allow a
+   security-aware resolver to authenticate both DNS resource records and
+   authoritative DNS error indications.
+
+   This document obsoletes RFC 2535 and incorporates changes from all
+   updates to RFC 2535.
+
+
+
+
+
+
+
+
+
+
+Arends, et al.              Standards Track                     [Page 1]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+       1.1.  Background and Related Documents . . . . . . . . . . . .  4
+       1.2.  Reserved Words . . . . . . . . . . . . . . . . . . . . .  4
+   2.  Zone Signing . . . . . . . . . . . . . . . . . . . . . . . . .  4
+       2.1.  Including DNSKEY RRs in a Zone . . . . . . . . . . . . .  5
+       2.2.  Including RRSIG RRs in a Zone  . . . . . . . . . . . . .  5
+       2.3.  Including NSEC RRs in a Zone . . . . . . . . . . . . . .  6
+       2.4.  Including DS RRs in a Zone . . . . . . . . . . . . . . .  7
+       2.5.  Changes to the CNAME Resource Record.  . . . . . . . . .  7
+       2.6.  DNSSEC RR Types Appearing at Zone Cuts.  . . . . . . . .  8
+       2.7.  Example of a Secure Zone . . . . . . . . . . . . . . . .  8
+   3.  Serving  . . . . . . . . . . . . . . . . . . . . . . . . . . .  8
+       3.1.  Authoritative Name Servers . . . . . . . . . . . . . . .  9
+             3.1.1.  Including RRSIG RRs in a Response  . . . . . . . 10
+             3.1.2.  Including DNSKEY RRs in a Response . . . . . . . 11
+             3.1.3.  Including NSEC RRs in a Response . . . . . . . . 11
+             3.1.4.  Including DS RRs in a Response . . . . . . . . . 14
+             3.1.5.  Responding to Queries for Type AXFR or IXFR  . . 15
+             3.1.6.  The AD and CD Bits in an Authoritative Response. 16
+       3.2.  Recursive Name Servers . . . . . . . . . . . . . . . . . 17
+             3.2.1.  The DO Bit . . . . . . . . . . . . . . . . . . . 17
+             3.2.2.  The CD Bit . . . . . . . . . . . . . . . . . . . 17
+             3.2.3.  The AD Bit . . . . . . . . . . . . . . . . . . . 18
+       3.3.  Example DNSSEC Responses . . . . . . . . . . . . . . . . 19
+   4.  Resolving  . . . . . . . . . . . . . . . . . . . . . . . . . . 19
+       4.1.  EDNS Support . . . . . . . . . . . . . . . . . . . . . . 19
+       4.2.  Signature Verification Support . . . . . . . . . . . . . 19
+       4.3.  Determining Security Status of Data  . . . . . . . . . . 20
+       4.4.  Configured Trust Anchors . . . . . . . . . . . . . . . . 21
+       4.5.  Response Caching . . . . . . . . . . . . . . . . . . . . 21
+       4.6.  Handling of the CD and AD Bits . . . . . . . . . . . . . 22
+       4.7.  Caching BAD Data . . . . . . . . . . . . . . . . . . . . 22
+       4.8.  Synthesized CNAMEs . . . . . . . . . . . . . . . . . . . 23
+       4.9.  Stub Resolvers . . . . . . . . . . . . . . . . . . . . . 23
+             4.9.1.  Handling of the DO Bit . . . . . . . . . . . . . 24
+             4.9.2.  Handling of the CD Bit . . . . . . . . . . . . . 24
+             4.9.3.  Handling of the AD Bit . . . . . . . . . . . . . 24
+   5.  Authenticating DNS Responses . . . . . . . . . . . . . . . . . 25
+       5.1.  Special Considerations for Islands of Security . . . . . 26
+       5.2.  Authenticating Referrals . . . . . . . . . . . . . . . . 26
+       5.3.  Authenticating an RRset with an RRSIG RR . . . . . . . . 28
+             5.3.1.  Checking the RRSIG RR Validity . . . . . . . . . 28
+             5.3.2.  Reconstructing the Signed Data . . . . . . . . . 29
+             5.3.3.  Checking the Signature . . . . . . . . . . . . . 31
+             5.3.4.  Authenticating a Wildcard Expanded RRset
+                     Positive Response. . . . . . . . . . . . . . . . 32
+
+
+
+Arends, et al.              Standards Track                     [Page 2]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+       5.4.  Authenticated Denial of Existence  . . . . . . . . . . . 32
+       5.5.  Resolver Behavior When Signatures Do Not Validate  . . . 33
+       5.6.  Authentication Example . . . . . . . . . . . . . . . . . 33
+   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 33
+   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 33
+   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34
+   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 34
+       9.1.  Normative References . . . . . . . . . . . . . . . . . . 34
+       9.2.  Informative References . . . . . . . . . . . . . . . . . 35
+   A.  Signed Zone Example  . . . . . . . . . . . . . . . . . . . . . 36
+   B.  Example Responses  . . . . . . . . . . . . . . . . . . . . . . 41
+       B.1.  Answer . . . . . . . . . . . . . . . . . . . . . . . . . 41
+       B.2.  Name Error . . . . . . . . . . . . . . . . . . . . . . . 43
+       B.3.  No Data Error  . . . . . . . . . . . . . . . . . . . . . 44
+       B.4.  Referral to Signed Zone  . . . . . . . . . . . . . . . . 44
+       B.5.  Referral to Unsigned Zone  . . . . . . . . . . . . . . . 45
+       B.6.  Wildcard Expansion . . . . . . . . . . . . . . . . . . . 46
+       B.7.  Wildcard No Data Error . . . . . . . . . . . . . . . . . 47
+       B.8.  DS Child Zone No Data Error  . . . . . . . . . . . . . . 48
+   C.  Authentication Examples  . . . . . . . . . . . . . . . . . . . 49
+       C.1.  Authenticating an Answer . . . . . . . . . . . . . . . . 49
+             C.1.1.  Authenticating the Example DNSKEY RR . . . . . . 49
+       C.2.  Name Error . . . . . . . . . . . . . . . . . . . . . . . 50
+       C.3.  No Data Error  . . . . . . . . . . . . . . . . . . . . . 50
+       C.4.  Referral to Signed Zone  . . . . . . . . . . . . . . . . 50
+       C.5.  Referral to Unsigned Zone  . . . . . . . . . . . . . . . 51
+       C.6.  Wildcard Expansion . . . . . . . . . . . . . . . . . . . 51
+       C.7.  Wildcard No Data Error . . . . . . . . . . . . . . . . . 51
+       C.8.  DS Child Zone No Data Error  . . . . . . . . . . . . . . 51
+   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 52
+   Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 53
+
+1.  Introduction
+
+   The DNS Security Extensions (DNSSEC) are a collection of new resource
+   records and protocol modifications that add data origin
+   authentication and data integrity to the DNS.  This document defines
+   the DNSSEC protocol modifications.  Section 2 of this document
+   defines the concept of a signed zone and lists the requirements for
+   zone signing.  Section 3 describes the modifications to authoritative
+   name server behavior necessary for handling signed zones.  Section 4
+   describes the behavior of entities that include security-aware
+   resolver functions.  Finally, Section 5 defines how to use DNSSEC RRs
+   to authenticate a response.
+
+
+
+
+
+
+
+Arends, et al.              Standards Track                     [Page 3]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+1.1.  Background and Related Documents
+
+   This document is part of a family of documents defining DNSSEC that
+   should be read together as a set.
+
+   [RFC4033] contains an introduction to DNSSEC and definitions of
+   common terms; the reader is assumed to be familiar with this
+   document.  [RFC4033] also contains a list of other documents updated
+   by and obsoleted by this document set.
+
+   [RFC4034] defines the DNSSEC resource records.
+
+   The reader is also assumed to be familiar with the basic DNS concepts
+   described in [RFC1034], [RFC1035], and the subsequent documents that
+   update them; particularly, [RFC2181] and [RFC2308].
+
+   This document defines the DNSSEC protocol operations.
+
+1.2.  Reserved Words
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC2119].
+
+2.  Zone Signing
+
+   DNSSEC introduces the concept of signed zones.  A signed zone
+   includes DNS Public Key (DNSKEY), Resource Record Signature (RRSIG),
+   Next Secure (NSEC), and (optionally) Delegation Signer (DS) records
+   according to the rules specified in Sections 2.1, 2.2, 2.3, and 2.4,
+   respectively.  A zone that does not include these records according
+   to the rules in this section is an unsigned zone.
+
+   DNSSEC requires a change to the definition of the CNAME resource
+   record ([RFC1035]).  Section 2.5 changes the CNAME RR to allow RRSIG
+   and NSEC RRs to appear at the same owner name as does a CNAME RR.
+
+   DNSSEC specifies the placement of two new RR types, NSEC and DS,
+   which can be placed at the parental side of a zone cut (that is, at a
+   delegation point).  This is an exception to the general prohibition
+   against putting data in the parent zone at a zone cut.  Section 2.6
+   describes this change.
+
+
+
+
+
+
+
+
+
+Arends, et al.              Standards Track                     [Page 4]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+2.1.  Including DNSKEY RRs in a Zone
+
+   To sign a zone, the zone's administrator generates one or more
+   public/private key pairs and uses the private key(s) to sign
+   authoritative RRsets in the zone.  For each private key used to
+   create RRSIG RRs in a zone, the zone SHOULD include a zone DNSKEY RR
+   containing the corresponding public key.  A zone key DNSKEY RR MUST
+   have the Zone Key bit of the flags RDATA field set (see Section 2.1.1
+   of [RFC4034]).  Public keys associated with other DNS operations MAY
+   be stored in DNSKEY RRs that are not marked as zone keys but MUST NOT
+   be used to verify RRSIGs.
+
+   If the zone administrator intends a signed zone to be usable other
+   than as an island of security, the zone apex MUST contain at least
+   one DNSKEY RR to act as a secure entry point into the zone.  This
+   secure entry point could then be used as the target of a secure
+   delegation via a corresponding DS RR in the parent zone (see
+   [RFC4034]).
+
+2.2.  Including RRSIG RRs in a Zone
+
+   For each authoritative RRset in a signed zone, there MUST be at least
+   one RRSIG record that meets the following requirements:
+
+   o  The RRSIG owner name is equal to the RRset owner name.
+
+   o  The RRSIG class is equal to the RRset class.
+
+   o  The RRSIG Type Covered field is equal to the RRset type.
+
+   o  The RRSIG Original TTL field is equal to the TTL of the RRset.
+
+   o  The RRSIG RR's TTL is equal to the TTL of the RRset.
+
+   o  The RRSIG Labels field is equal to the number of labels in the
+      RRset owner name, not counting the null root label and not
+      counting the leftmost label if it is a wildcard.
+
+   o  The RRSIG Signer's Name field is equal to the name of the zone
+      containing the RRset.
+
+   o  The RRSIG Algorithm, Signer's Name, and Key Tag fields identify a
+      zone key DNSKEY record at the zone apex.
+
+   The process for constructing the RRSIG RR for a given RRset is
+   described in [RFC4034].  An RRset MAY have multiple RRSIG RRs
+   associated with it.  Note that as RRSIG RRs are closely tied to the
+   RRsets whose signatures they contain, RRSIG RRs, unlike all other DNS
+
+
+
+Arends, et al.              Standards Track                     [Page 5]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+   RR types, do not form RRsets.  In particular, the TTL values among
+   RRSIG RRs with a common owner name do not follow the RRset rules
+   described in [RFC2181].
+
+   An RRSIG RR itself MUST NOT be signed, as signing an RRSIG RR would
+   add no value and would create an infinite loop in the signing
+   process.
+
+   The NS RRset that appears at the zone apex name MUST be signed, but
+   the NS RRsets that appear at delegation points (that is, the NS
+   RRsets in the parent zone that delegate the name to the child zone's
+   name servers) MUST NOT be signed.  Glue address RRsets associated
+   with delegations MUST NOT be signed.
+
+   There MUST be an RRSIG for each RRset using at least one DNSKEY of
+   each algorithm in the zone apex DNSKEY RRset.  The apex DNSKEY RRset
+   itself MUST be signed by each algorithm appearing in the DS RRset
+   located at the delegating parent (if any).
+
+2.3.  Including NSEC RRs in a Zone
+
+   Each owner name in the zone that has authoritative data or a
+   delegation point NS RRset MUST have an NSEC resource record.  The
+   format of NSEC RRs and the process for constructing the NSEC RR for a
+   given name is described in [RFC4034].
+
+   The TTL value for any NSEC RR SHOULD be the same as the minimum TTL
+   value field in the zone SOA RR.
+
+   An NSEC record (and its associated RRSIG RRset) MUST NOT be the only
+   RRset at any particular owner name.  That is, the signing process
+   MUST NOT create NSEC or RRSIG RRs for owner name nodes that were not
+   the owner name of any RRset before the zone was signed.  The main
+   reasons for this are a desire for namespace consistency between
+   signed and unsigned versions of the same zone and a desire to reduce
+   the risk of response inconsistency in security oblivious recursive
+   name servers.
+
+   The type bitmap of every NSEC resource record in a signed zone MUST
+   indicate the presence of both the NSEC record itself and its
+   corresponding RRSIG record.
+
+   The difference between the set of owner names that require RRSIG
+   records and the set of owner names that require NSEC records is
+   subtle and worth highlighting.  RRSIG records are present at the
+   owner names of all authoritative RRsets.  NSEC records are present at
+   the owner names of all names for which the signed zone is
+   authoritative and also at the owner names of delegations from the
+
+
+
+Arends, et al.              Standards Track                     [Page 6]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+   signed zone to its children.  Neither NSEC nor RRSIG records are
+   present (in the parent zone) at the owner names of glue address
+   RRsets.  Note, however, that this distinction is for the most part
+   visible only during the zone signing process, as NSEC RRsets are
+   authoritative data and are therefore signed.  Thus, any owner name
+   that has an NSEC RRset will have RRSIG RRs as well in the signed
+   zone.
+
+   The bitmap for the NSEC RR at a delegation point requires special
+   attention.  Bits corresponding to the delegation NS RRset and any
+   RRsets for which the parent zone has authoritative data MUST be set;
+   bits corresponding to any non-NS RRset for which the parent is not
+   authoritative MUST be clear.
+
+2.4.  Including DS RRs in a Zone
+
+   The DS resource record establishes authentication chains between DNS
+   zones.  A DS RRset SHOULD be present at a delegation point when the
+   child zone is signed.  The DS RRset MAY contain multiple records,
+   each referencing a public key in the child zone used to verify the
+   RRSIGs in that zone.  All DS RRsets in a zone MUST be signed, and DS
+   RRsets MUST NOT appear at a zone's apex.
+
+   A DS RR SHOULD point to a DNSKEY RR that is present in the child's
+   apex DNSKEY RRset, and the child's apex DNSKEY RRset SHOULD be signed
+   by the corresponding private key.  DS RRs that fail to meet these
+   conditions are not useful for validation, but because the DS RR and
+   its corresponding DNSKEY RR are in different zones, and because the
+   DNS is only loosely consistent, temporary mismatches can occur.
+
+   The TTL of a DS RRset SHOULD match the TTL of the delegating NS RRset
+   (that is, the NS RRset from the same zone containing the DS RRset).
+
+   Construction of a DS RR requires knowledge of the corresponding
+   DNSKEY RR in the child zone, which implies communication between the
+   child and parent zones.  This communication is an operational matter
+   not covered by this document.
+
+2.5.  Changes to the CNAME Resource Record
+
+   If a CNAME RRset is present at a name in a signed zone, appropriate
+   RRSIG and NSEC RRsets are REQUIRED at that name.  A KEY RRset at that
+   name for secure dynamic update purposes is also allowed ([RFC3007]).
+   Other types MUST NOT be present at that name.
+
+   This is a modification to the original CNAME definition given in
+   [RFC1034].  The original definition of the CNAME RR did not allow any
+   other types to coexist with a CNAME record, but a signed zone
+
+
+
+Arends, et al.              Standards Track                     [Page 7]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+   requires NSEC and RRSIG RRs for every authoritative name.  To resolve
+   this conflict, this specification modifies the definition of the
+   CNAME resource record to allow it to coexist with NSEC and RRSIG RRs.
+
+2.6.  DNSSEC RR Types Appearing at Zone Cuts
+
+   DNSSEC introduced two new RR types that are unusual in that they can
+   appear at the parental side of a zone cut.  At the parental side of a
+   zone cut (that is, at a delegation point), NSEC RRs are REQUIRED at
+   the owner name.  A DS RR could also be present if the zone being
+   delegated is signed and seeks to have a chain of authentication to
+   the parent zone.  This is an exception to the original DNS
+   specification ([RFC1034]), which states that only NS RRsets could
+   appear at the parental side of a zone cut.
+
+   This specification updates the original DNS specification to allow
+   NSEC and DS RR types at the parent side of a zone cut.  These RRsets
+   are authoritative for the parent when they appear at the parent side
+   of a zone cut.
+
+2.7.  Example of a Secure Zone
+
+   Appendix A shows a complete example of a small signed zone.
+
+3.  Serving
+
+   This section describes the behavior of entities that include
+   security-aware name server functions.  In many cases such functions
+   will be part of a security-aware recursive name server, but a
+   security-aware authoritative name server has some of the same
+   requirements.  Functions specific to security-aware recursive name
+   servers are described in Section 3.2; functions specific to
+   authoritative servers are described in Section 3.1.
+
+   In the following discussion, the terms "SNAME", "SCLASS", and "STYPE"
+   are as used in [RFC1034].
+
+   A security-aware name server MUST support the EDNS0 ([RFC2671])
+   message size extension, MUST support a message size of at least 1220
+   octets, and SHOULD support a message size of 4000 octets.  As IPv6
+   packets can only be fragmented by the source host, a security aware
+   name server SHOULD take steps to ensure that UDP datagrams it
+   transmits over IPv6 are fragmented, if necessary, at the minimum IPv6
+   MTU, unless the path MTU is known.  Please see [RFC1122], [RFC2460],
+   and [RFC3226] for further discussion of packet size and fragmentation
+   issues.
+
+
+
+
+
+Arends, et al.              Standards Track                     [Page 8]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+   A security-aware name server that receives a DNS query that does not
+   include the EDNS OPT pseudo-RR or that has the DO bit clear MUST
+   treat the RRSIG, DNSKEY, and NSEC RRs as it would any other RRset and
+   MUST NOT perform any of the additional processing described below.
+   Because the DS RR type has the peculiar property of only existing in
+   the parent zone at delegation points, DS RRs always require some
+   special processing, as described in Section 3.1.4.1.
+
+   Security aware name servers that receive explicit queries for
+   security RR types that match the content of more than one zone that
+   it serves (for example, NSEC and RRSIG RRs above and below a
+   delegation point where the server is authoritative for both zones)
+   should behave self-consistently.  As long as the response is always
+   consistent for each query to the name server, the name server MAY
+   return one of the following:
+
+   o  The above-delegation RRsets.
+   o  The below-delegation RRsets.
+   o  Both above and below-delegation RRsets.
+   o  Empty answer section (no records).
+   o  Some other response.
+   o  An error.
+
+   DNSSEC allocates two new bits in the DNS message header: the CD
+   (Checking Disabled) bit and the AD (Authentic Data) bit.  The CD bit
+   is controlled by resolvers; a security-aware name server MUST copy
+   the CD bit from a query into the corresponding response.  The AD bit
+   is controlled by name servers; a security-aware name server MUST
+   ignore the setting of the AD bit in queries.  See Sections 3.1.6,
+   3.2.2, 3.2.3, 4, and 4.9 for details on the behavior of these bits.
+
+   A security aware name server that synthesizes CNAME RRs from DNAME
+   RRs as described in [RFC2672] SHOULD NOT generate signatures for the
+   synthesized CNAME RRs.
+
+3.1.  Authoritative Name Servers
+
+   Upon receiving a relevant query that has the EDNS ([RFC2671]) OPT
+   pseudo-RR DO bit ([RFC3225]) set, a security-aware authoritative name
+   server for a signed zone MUST include additional RRSIG, NSEC, and DS
+   RRs, according to the following rules:
+
+   o  RRSIG RRs that can be used to authenticate a response MUST be
+      included in the response according to the rules in Section 3.1.1.
+
+
+
+
+
+
+
+Arends, et al.              Standards Track                     [Page 9]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+   o  NSEC RRs that can be used to provide authenticated denial of
+      existence MUST be included in the response automatically according
+      to the rules in Section 3.1.3.
+
+   o  Either a DS RRset or an NSEC RR proving that no DS RRs exist MUST
+      be included in referrals automatically according to the rules in
+      Section 3.1.4.
+
+   These rules only apply to responses where the semantics convey
+   information about the presence or absence of resource records.  That
+   is, these rules are not intended to rule out responses such as RCODE
+   4 ("Not Implemented") or RCODE 5 ("Refused").
+
+   DNSSEC does not change the DNS zone transfer protocol.  Section 3.1.5
+   discusses zone transfer requirements.
+
+3.1.1.  Including RRSIG RRs in a Response
+
+   When responding to a query that has the DO bit set, a security-aware
+   authoritative name server SHOULD attempt to send RRSIG RRs that a
+   security-aware resolver can use to authenticate the RRsets in the
+   response.  A name server SHOULD make every attempt to keep the RRset
+   and its associated RRSIG(s) together in a response.  Inclusion of
+   RRSIG RRs in a response is subject to the following rules:
+
+   o  When placing a signed RRset in the Answer section, the name server
+      MUST also place its RRSIG RRs in the Answer section.  The RRSIG
+      RRs have a higher priority for inclusion than any other RRsets
+      that may have to be included.  If space does not permit inclusion
+      of these RRSIG RRs, the name server MUST set the TC bit.
+
+   o  When placing a signed RRset in the Authority section, the name
+      server MUST also place its RRSIG RRs in the Authority section.
+      The RRSIG RRs have a higher priority for inclusion than any other
+      RRsets that may have to be included.  If space does not permit
+      inclusion of these RRSIG RRs, the name server MUST set the TC bit.
+
+   o  When placing a signed RRset in the Additional section, the name
+      server MUST also place its RRSIG RRs in the Additional section.
+      If space does not permit inclusion of both the RRset and its
+      associated RRSIG RRs, the name server MAY retain the RRset while
+      dropping the RRSIG RRs.  If this happens, the name server MUST NOT
+      set the TC bit solely because these RRSIG RRs didn't fit.
+
+
+
+
+
+
+
+
+Arends, et al.              Standards Track                    [Page 10]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+3.1.2.  Including DNSKEY RRs in a Response
+
+   When responding to a query that has the DO bit set and that requests
+   the SOA or NS RRs at the apex of a signed zone, a security-aware
+   authoritative name server for that zone MAY return the zone apex
+   DNSKEY RRset in the Additional section.  In this situation, the
+   DNSKEY RRset and associated RRSIG RRs have lower priority than does
+   any other information that would be placed in the additional section.
+   The name server SHOULD NOT include the DNSKEY RRset unless there is
+   enough space in the response message for both the DNSKEY RRset and
+   its associated RRSIG RR(s).  If there is not enough space to include
+   these DNSKEY and RRSIG RRs, the name server MUST omit them and MUST
+   NOT set the TC bit solely because these RRs didn't fit (see Section
+   3.1.1).
+
+3.1.3.  Including NSEC RRs in a Response
+
+   When responding to a query that has the DO bit set, a security-aware
+   authoritative name server for a signed zone MUST include NSEC RRs in
+   each of the following cases:
+
+   No Data: The zone contains RRsets that exactly match <SNAME, SCLASS>
+      but does not contain any RRsets that exactly match <SNAME, SCLASS,
+      STYPE>.
+
+   Name Error: The zone does not contain any RRsets that match <SNAME,
+      SCLASS> either exactly or via wildcard name expansion.
+
+   Wildcard Answer: The zone does not contain any RRsets that exactly
+      match <SNAME, SCLASS> but does contain an RRset that matches
+      <SNAME, SCLASS, STYPE> via wildcard name expansion.
+
+   Wildcard No Data: The zone does not contain any RRsets that exactly
+      match <SNAME, SCLASS> and does contain one or more RRsets that
+      match <SNAME, SCLASS> via wildcard name expansion, but does not
+      contain any RRsets that match <SNAME, SCLASS, STYPE> via wildcard
+      name expansion.
+
+   In each of these cases, the name server includes NSEC RRs in the
+   response to prove that an exact match for <SNAME, SCLASS, STYPE> was
+   not present in the zone and that the response that the name server is
+   returning is correct given the data in the zone.
+
+
+
+
+
+
+
+
+
+Arends, et al.              Standards Track                    [Page 11]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+3.1.3.1.  Including NSEC RRs: No Data Response
+
+   If the zone contains RRsets matching <SNAME, SCLASS> but contains no
+   RRset matching <SNAME, SCLASS, STYPE>, then the name server MUST
+   include the NSEC RR for <SNAME, SCLASS> along with its associated
+   RRSIG RR(s) in the Authority section of the response (see Section
+   3.1.1).  If space does not permit inclusion of the NSEC RR or its
+   associated RRSIG RR(s), the name server MUST set the TC bit (see
+   Section 3.1.1).
+
+   Since the search name exists, wildcard name expansion does not apply
+   to this query, and a single signed NSEC RR suffices to prove that the
+   requested RR type does not exist.
+
+3.1.3.2.  Including NSEC RRs: Name Error Response
+
+   If the zone does not contain any RRsets matching <SNAME, SCLASS>
+   either exactly or via wildcard name expansion, then the name server
+   MUST include the following NSEC RRs in the Authority section, along
+   with their associated RRSIG RRs:
+
+   o  An NSEC RR proving that there is no exact match for <SNAME,
+      SCLASS>.
+
+   o  An NSEC RR proving that the zone contains no RRsets that would
+      match <SNAME, SCLASS> via wildcard name expansion.
+
+   In some cases, a single NSEC RR may prove both of these points.  If
+   it does, the name server SHOULD only include the NSEC RR and its
+   RRSIG RR(s) once in the Authority section.
+
+   If space does not permit inclusion of these NSEC and RRSIG RRs, the
+   name server MUST set the TC bit (see Section 3.1.1).
+
+   The owner names of these NSEC and RRSIG RRs are not subject to
+   wildcard name expansion when these RRs are included in the Authority
+   section of the response.
+
+   Note that this form of response includes cases in which SNAME
+   corresponds to an empty non-terminal name within the zone (a name
+   that is not the owner name for any RRset but that is the parent name
+   of one or more RRsets).
+
+3.1.3.3.  Including NSEC RRs: Wildcard Answer Response
+
+   If the zone does not contain any RRsets that exactly match <SNAME,
+   SCLASS> but does contain an RRset that matches <SNAME, SCLASS, STYPE>
+   via wildcard name expansion, the name server MUST include the
+
+
+
+Arends, et al.              Standards Track                    [Page 12]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+   wildcard-expanded answer and the corresponding wildcard-expanded
+   RRSIG RRs in the Answer section and MUST include in the Authority
+   section an NSEC RR and associated RRSIG RR(s) proving that the zone
+   does not contain a closer match for <SNAME, SCLASS>.  If space does
+   not permit inclusion of the answer, NSEC and RRSIG RRs, the name
+   server MUST set the TC bit (see Section 3.1.1).
+
+3.1.3.4.  Including NSEC RRs: Wildcard No Data Response
+
+   This case is a combination of the previous cases.  The zone does not
+   contain an exact match for <SNAME, SCLASS>, and although the zone
+   does contain RRsets that match <SNAME, SCLASS> via wildcard
+   expansion, none of those RRsets matches STYPE.  The name server MUST
+   include the following NSEC RRs in the Authority section, along with
+   their associated RRSIG RRs:
+
+   o  An NSEC RR proving that there are no RRsets matching STYPE at the
+      wildcard owner name that matched <SNAME, SCLASS> via wildcard
+      expansion.
+
+   o  An NSEC RR proving that there are no RRsets in the zone that would
+      have been a closer match for <SNAME, SCLASS>.
+
+   In some cases, a single NSEC RR may prove both of these points.  If
+   it does, the name server SHOULD only include the NSEC RR and its
+   RRSIG RR(s) once in the Authority section.
+
+   The owner names of these NSEC and RRSIG RRs are not subject to
+   wildcard name expansion when these RRs are included in the Authority
+   section of the response.
+
+   If space does not permit inclusion of these NSEC and RRSIG RRs, the
+   name server MUST set the TC bit (see Section 3.1.1).
+
+3.1.3.5.  Finding the Right NSEC RRs
+
+   As explained above, there are several situations in which a
+   security-aware authoritative name server has to locate an NSEC RR
+   that proves that no RRsets matching a particular SNAME exist.
+   Locating such an NSEC RR within an authoritative zone is relatively
+   simple, at least in concept.  The following discussion assumes that
+   the name server is authoritative for the zone that would have held
+   the non-existent RRsets matching SNAME.  The algorithm below is
+   written for clarity, not for efficiency.
+
+   To find the NSEC that proves that no RRsets matching name N exist in
+   the zone Z that would have held them, construct a sequence, S,
+   consisting of the owner names of every RRset in Z, sorted into
+
+
+
+Arends, et al.              Standards Track                    [Page 13]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+   canonical order ([RFC4034]), with no duplicate names.  Find the name
+   M that would have immediately preceded N in S if any RRsets with
+   owner name N had existed.  M is the owner name of the NSEC RR that
+   proves that no RRsets exist with owner name N.
+
+   The algorithm for finding the NSEC RR that proves that a given name
+   is not covered by any applicable wildcard is similar but requires an
+   extra step.  More precisely, the algorithm for finding the NSEC
+   proving that no RRsets exist with the applicable wildcard name is
+   precisely the same as the algorithm for finding the NSEC RR that
+   proves that RRsets with any other owner name do not exist.  The part
+   that's missing is a method of determining the name of the non-
+   existent applicable wildcard.  In practice, this is easy, because the
+   authoritative name server has already checked for the presence of
+   precisely this wildcard name as part of step (1)(c) of the normal
+   lookup algorithm described in Section 4.3.2 of [RFC1034].
+
+3.1.4.  Including DS RRs in a Response
+
+   When responding to a query that has the DO bit set, a security-aware
+   authoritative name server returning a referral includes DNSSEC data
+   along with the NS RRset.
+
+   If a DS RRset is present at the delegation point, the name server
+   MUST return both the DS RRset and its associated RRSIG RR(s) in the
+   Authority section along with the NS RRset.
+
+   If no DS RRset is present at the delegation point, the name server
+   MUST return both the NSEC RR that proves that the DS RRset is not
+   present and the NSEC RR's associated RRSIG RR(s) along with the NS
+   RRset.  The name server MUST place the NS RRset before the NSEC RRset
+   and its associated RRSIG RR(s).
+
+   Including these DS, NSEC, and RRSIG RRs increases the size of
+   referral messages and may cause some or all glue RRs to be omitted.
+   If space does not permit inclusion of the DS or NSEC RRset and
+   associated RRSIG RRs, the name server MUST set the TC bit (see
+   Section 3.1.1).
+
+3.1.4.1.  Responding to Queries for DS RRs
+
+   The DS resource record type is unusual in that it appears only on the
+   parent zone's side of a zone cut.  For example, the DS RRset for the
+   delegation of "foo.example" is stored in the "example" zone rather
+   than in the "foo.example" zone.  This requires special processing
+   rules for both name servers and resolvers, as the name server for the
+   child zone is authoritative for the name at the zone cut by the
+   normal DNS rules but the child zone does not contain the DS RRset.
+
+
+
+Arends, et al.              Standards Track                    [Page 14]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+   A security-aware resolver sends queries to the parent zone when
+   looking for a needed DS RR at a delegation point (see Section 4.2).
+   However, special rules are necessary to avoid confusing
+   security-oblivious resolvers which might become involved in
+   processing such a query (for example, in a network configuration that
+   forces a security-aware resolver to channel its queries through a
+   security-oblivious recursive name server).  The rest of this section
+   describes how a security-aware name server processes DS queries in
+   order to avoid this problem.
+
+   The need for special processing by a security-aware name server only
+   arises when all the following conditions are met:
+
+   o  The name server has received a query for the DS RRset at a zone
+      cut.
+
+   o  The name server is authoritative for the child zone.
+
+   o  The name server is not authoritative for the parent zone.
+
+   o  The name server does not offer recursion.
+
+   In all other cases, the name server either has some way of obtaining
+   the DS RRset or could not have been expected to have the DS RRset
+   even by the pre-DNSSEC processing rules, so the name server can
+   return either the DS RRset or an error response according to the
+   normal processing rules.
+
+   If all the above conditions are met, however, the name server is
+   authoritative for SNAME but cannot supply the requested RRset.  In
+   this case, the name server MUST return an authoritative "no data"
+   response showing that the DS RRset does not exist in the child zone's
+   apex.  See Appendix B.8 for an example of such a response.
+
+3.1.5.  Responding to Queries for Type AXFR or IXFR
+
+   DNSSEC does not change the DNS zone transfer process.  A signed zone
+   will contain RRSIG, DNSKEY, NSEC, and DS resource records, but these
+   records have no special meaning with respect to a zone transfer
+   operation.
+
+   An authoritative name server is not required to verify that a zone is
+   properly signed before sending or accepting a zone transfer.
+   However, an authoritative name server MAY choose to reject the entire
+   zone transfer if the zone fails to meet any of the signing
+   requirements described in Section 2.  The primary objective of a zone
+   transfer is to ensure that all authoritative name servers have
+   identical copies of the zone.  An authoritative name server that
+
+
+
+Arends, et al.              Standards Track                    [Page 15]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+   chooses to perform its own zone validation MUST NOT selectively
+   reject some RRs and accept others.
+
+   DS RRsets appear only on the parental side of a zone cut and are
+   authoritative data in the parent zone.  As with any other
+   authoritative RRset, the DS RRset MUST be included in zone transfers
+   of the zone in which the RRset is authoritative data.  In the case of
+   the DS RRset, this is the parent zone.
+
+   NSEC RRs appear in both the parent and child zones at a zone cut and
+   are authoritative data in both the parent and child zones.  The
+   parental and child NSEC RRs at a zone cut are never identical to each
+   other, as the NSEC RR in the child zone's apex will always indicate
+   the presence of the child zone's SOA RR whereas the parental NSEC RR
+   at the zone cut will never indicate the presence of an SOA RR.  As
+   with any other authoritative RRs, NSEC RRs MUST be included in zone
+   transfers of the zone in which they are authoritative data.  The
+   parental NSEC RR at a zone cut MUST be included in zone transfers of
+   the parent zone, and the NSEC at the zone apex of the child zone MUST
+   be included in zone transfers of the child zone.
+
+   RRSIG RRs appear in both the parent and child zones at a zone cut and
+   are authoritative in whichever zone contains the authoritative RRset
+   for which the RRSIG RR provides the signature.  That is, the RRSIG RR
+   for a DS RRset or a parental NSEC RR at a zone cut will be
+   authoritative in the parent zone, and the RRSIG for any RRset in the
+   child zone's apex will be authoritative in the child zone.  Parental
+   and child RRSIG RRs at a zone cut will never be identical to each
+   other, as the Signer's Name field of an RRSIG RR in the child zone's
+   apex will indicate a DNSKEY RR in the child zone's apex whereas the
+   same field of a parental RRSIG RR at the zone cut will indicate a
+   DNSKEY RR in the parent zone's apex.  As with any other authoritative
+   RRs, RRSIG RRs MUST be included in zone transfers of the zone in
+   which they are authoritative data.
+
+3.1.6.  The AD and CD Bits in an Authoritative Response
+
+   The CD and AD bits are designed for use in communication between
+   security-aware resolvers and security-aware recursive name servers.
+   These bits are for the most part not relevant to query processing by
+   security-aware authoritative name servers.
+
+   A security-aware name server does not perform signature validation
+   for authoritative data during query processing, even when the CD bit
+   is clear.  A security-aware name server SHOULD clear the CD bit when
+   composing an authoritative response.
+
+
+
+
+
+Arends, et al.              Standards Track                    [Page 16]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+   A security-aware name server MUST NOT set the AD bit in a response
+   unless the name server considers all RRsets in the Answer and
+   Authority sections of the response to be authentic.  A security-aware
+   name server's local policy MAY consider data from an authoritative
+   zone to be authentic without further validation.  However, the name
+   server MUST NOT do so unless the name server obtained the
+   authoritative zone via secure means (such as a secure zone transfer
+   mechanism) and MUST NOT do so unless this behavior has been
+   configured explicitly.
+
+   A security-aware name server that supports recursion MUST follow the
+   rules for the CD and AD bits given in Section 3.2 when generating a
+   response that involves data obtained via recursion.
+
+3.2.  Recursive Name Servers
+
+   As explained in [RFC4033], a security-aware recursive name server is
+   an entity that acts in both the security-aware name server and
+   security-aware resolver roles.  This section uses the terms "name
+   server side" and "resolver side" to refer to the code within a
+   security-aware recursive name server that implements the
+   security-aware name server role and the code that implements the
+   security-aware resolver role, respectively.
+
+   The resolver side follows the usual rules for caching and negative
+   caching that would apply to any security-aware resolver.
+
+3.2.1.  The DO Bit
+
+   The resolver side of a security-aware recursive name server MUST set
+   the DO bit when sending requests, regardless of the state of the DO
+   bit in the initiating request received by the name server side.  If
+   the DO bit in an initiating query is not set, the name server side
+   MUST strip any authenticating DNSSEC RRs from the response but MUST
+   NOT strip any DNSSEC RR types that the initiating query explicitly
+   requested.
+
+3.2.2.  The CD Bit
+
+   The CD bit exists in order to allow a security-aware resolver to
+   disable signature validation in a security-aware name server's
+   processing of a particular query.
+
+   The name server side MUST copy the setting of the CD bit from a query
+   to the corresponding response.
+
+   The name server side of a security-aware recursive name server MUST
+   pass the state of the CD bit to the resolver side along with the rest
+
+
+
+Arends, et al.              Standards Track                    [Page 17]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+   of an initiating query, so that the resolver side will know whether
+   it is required to verify the response data it returns to the name
+   server side.  If the CD bit is set, it indicates that the originating
+   resolver is willing to perform whatever authentication its local
+   policy requires.  Thus, the resolver side of the recursive name
+   server need not perform authentication on the RRsets in the response.
+   When the CD bit is set, the recursive name server SHOULD, if
+   possible, return the requested data to the originating resolver, even
+   if the recursive name server's local authentication policy would
+   reject the records in question.  That is, by setting the CD bit, the
+   originating resolver has indicated that it takes responsibility for
+   performing its own authentication, and the recursive name server
+   should not interfere.
+
+   If the resolver side implements a BAD cache (see Section 4.7) and the
+   name server side receives a query that matches an entry in the
+   resolver side's BAD cache, the name server side's response depends on
+   the state of the CD bit in the original query.  If the CD bit is set,
+   the name server side SHOULD return the data from the BAD cache; if
+   the CD bit is not set, the name server side MUST return RCODE 2
+   (server failure).
+
+   The intent of the above rule is to provide the raw data to clients
+   that are capable of performing their own signature verification
+   checks while protecting clients that depend on the resolver side of a
+   security-aware recursive name server to perform such checks.  Several
+   of the possible reasons why signature validation might fail involve
+   conditions that may not apply equally to the recursive name server
+   and the client that invoked it.  For example, the recursive name
+   server's clock may be set incorrectly, or the client may have
+   knowledge of a relevant island of security that the recursive name
+   server does not share.  In such cases, "protecting" a client that is
+   capable of performing its own signature validation from ever seeing
+   the "bad" data does not help the client.
+
+3.2.3.  The AD Bit
+
+   The name server side of a security-aware recursive name server MUST
+   NOT set the AD bit in a response unless the name server considers all
+   RRsets in the Answer and Authority sections of the response to be
+   authentic.  The name server side SHOULD set the AD bit if and only if
+   the resolver side considers all RRsets in the Answer section and any
+   relevant negative response RRs in the Authority section to be
+   authentic.  The resolver side MUST follow the procedure described in
+   Section 5 to determine whether the RRs in question are authentic.
+   However, for backward compatibility, a recursive name server MAY set
+   the AD bit when a response includes unsigned CNAME RRs if those CNAME
+
+
+
+
+Arends, et al.              Standards Track                    [Page 18]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+   RRs demonstrably could have been synthesized from an authentic DNAME
+   RR that is also included in the response according to the synthesis
+   rules described in [RFC2672].
+
+3.3.  Example DNSSEC Responses
+
+   See Appendix B for example response packets.
+
+4.  Resolving
+
+   This section describes the behavior of entities that include
+   security-aware resolver functions.  In many cases such functions will
+   be part of a security-aware recursive name server, but a stand-alone
+   security-aware resolver has many of the same requirements.  Functions
+   specific to security-aware recursive name servers are described in
+   Section 3.2.
+
+4.1.  EDNS Support
+
+   A security-aware resolver MUST include an EDNS ([RFC2671]) OPT
+   pseudo-RR with the DO ([RFC3225]) bit set when sending queries.
+
+   A security-aware resolver MUST support a message size of at least
+   1220 octets, SHOULD support a message size of 4000 octets, and MUST
+   use the "sender's UDP payload size" field in the EDNS OPT pseudo-RR
+   to advertise the message size that it is willing to accept.  A
+   security-aware resolver's IP layer MUST handle fragmented UDP packets
+   correctly regardless of whether any such fragmented packets were
+   received via IPv4 or IPv6.  Please see [RFC1122], [RFC2460], and
+   [RFC3226] for discussion of these requirements.
+
+4.2.  Signature Verification Support
+
+   A security-aware resolver MUST support the signature verification
+   mechanisms described in Section 5 and SHOULD apply them to every
+   received response, except when:
+
+   o  the security-aware resolver is part of a security-aware recursive
+      name server, and the response is the result of recursion on behalf
+      of a query received with the CD bit set;
+
+   o  the response is the result of a query generated directly via some
+      form of application interface that instructed the security-aware
+      resolver not to perform validation for this query; or
+
+   o  validation for this query has been disabled by local policy.
+
+
+
+
+
+Arends, et al.              Standards Track                    [Page 19]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+   A security-aware resolver's support for signature verification MUST
+   include support for verification of wildcard owner names.
+
+   Security-aware resolvers MAY query for missing security RRs in an
+   attempt to perform validation; implementations that choose to do so
+   must be aware that the answers received may not be sufficient to
+   validate the original response.  For example, a zone update may have
+   changed (or deleted) the desired information between the original and
+   follow-up queries.
+
+   When attempting to retrieve missing NSEC RRs that reside on the
+   parental side at a zone cut, a security-aware iterative-mode resolver
+   MUST query the name servers for the parent zone, not the child zone.
+
+   When attempting to retrieve a missing DS, a security-aware
+   iterative-mode resolver MUST query the name servers for the parent
+   zone, not the child zone.  As explained in Section 3.1.4.1,
+   security-aware name servers need to apply special processing rules to
+   handle the DS RR, and in some situations the resolver may also need
+   to apply special rules to locate the name servers for the parent zone
+   if the resolver does not already have the parent's NS RRset.  To
+   locate the parent NS RRset, the resolver can start with the
+   delegation name, strip off the leftmost label, and query for an NS
+   RRset by that name.  If no NS RRset is present at that name, the
+   resolver then strips off the leftmost remaining label and retries the
+   query for that name, repeating this process of walking up the tree
+   until it either finds the NS RRset or runs out of labels.
+
+4.3.  Determining Security Status of Data
+
+   A security-aware resolver MUST be able to determine whether it should
+   expect a particular RRset to be signed.  More precisely, a
+   security-aware resolver must be able to distinguish between four
+   cases:
+
+   Secure: An RRset for which the resolver is able to build a chain of
+      signed DNSKEY and DS RRs from a trusted security anchor to the
+      RRset.  In this case, the RRset should be signed and is subject to
+      signature validation, as described above.
+
+   Insecure: An RRset for which the resolver knows that it has no chain
+      of signed DNSKEY and DS RRs from any trusted starting point to the
+      RRset.  This can occur when the target RRset lies in an unsigned
+      zone or in a descendent of an unsigned zone.  In this case, the
+      RRset may or may not be signed, but the resolver will not be able
+      to verify the signature.
+
+
+
+
+
+Arends, et al.              Standards Track                    [Page 20]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+   Bogus: An RRset for which the resolver believes that it ought to be
+      able to establish a chain of trust but for which it is unable to
+      do so, either due to signatures that for some reason fail to
+      validate or due to missing data that the relevant DNSSEC RRs
+      indicate should be present.  This case may indicate an attack but
+      may also indicate a configuration error or some form of data
+      corruption.
+
+   Indeterminate: An RRset for which the resolver is not able to
+      determine whether the RRset should be signed, as the resolver is
+      not able to obtain the necessary DNSSEC RRs.  This can occur when
+      the security-aware resolver is not able to contact security-aware
+      name servers for the relevant zones.
+
+4.4.  Configured Trust Anchors
+
+   A security-aware resolver MUST be capable of being configured with at
+   least one trusted public key or DS RR and SHOULD be capable of being
+   configured with multiple trusted public keys or DS RRs.  Since a
+   security-aware resolver will not be able to validate signatures
+   without such a configured trust anchor, the resolver SHOULD have some
+   reasonably robust mechanism for obtaining such keys when it boots;
+   examples of such a mechanism would be some form of non-volatile
+   storage (such as a disk drive) or some form of trusted local network
+   configuration mechanism.
+
+   Note that trust anchors also cover key material that is updated in a
+   secure manner.  This secure manner could be through physical media, a
+   key exchange protocol, or some other out-of-band means.
+
+4.5.  Response Caching
+
+   A security-aware resolver SHOULD cache each response as a single
+   atomic entry containing the entire answer, including the named RRset
+   and any associated DNSSEC RRs.  The resolver SHOULD discard the
+   entire atomic entry when any of the RRs contained in it expire.  In
+   most cases the appropriate cache index for the atomic entry will be
+   the triple <QNAME, QTYPE, QCLASS>, but in cases such as the response
+   form described in Section 3.1.3.2 the appropriate cache index will be
+   the double <QNAME,QCLASS>.
+
+   The reason for these recommendations is that, between the initial
+   query and the expiration of the data from the cache, the
+   authoritative data might have been changed (for example, via dynamic
+   update).
+
+
+
+
+
+
+Arends, et al.              Standards Track                    [Page 21]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+   There are two situations for which this is relevant:
+
+   1.  By using the RRSIG record, it is possible to deduce that an
+       answer was synthesized from a wildcard.  A security-aware
+       recursive name server could store this wildcard data and use it
+       to generate positive responses to queries other than the name for
+       which the original answer was first received.
+
+   2.  NSEC RRs received to prove the non-existence of a name could be
+       reused by a security-aware resolver to prove the non-existence of
+       any name in the name range it spans.
+
+   In theory, a resolver could use wildcards or NSEC RRs to generate
+   positive and negative responses (respectively) until the TTL or
+   signatures on the records in question expire.  However, it seems
+   prudent for resolvers to avoid blocking new authoritative data or
+   synthesizing new data on their own.  Resolvers that follow this
+   recommendation will have a more consistent view of the namespace.
+
+4.6.  Handling of the CD and AD Bits
+
+   A security-aware resolver MAY set a query's CD bit in order to
+   indicate that the resolver takes responsibility for performing
+   whatever authentication its local policy requires on the RRsets in
+   the response.  See Section 3.2 for the effect this bit has on the
+   behavior of security-aware recursive name servers.
+
+   A security-aware resolver MUST clear the AD bit when composing query
+   messages to protect against buggy name servers that blindly copy
+   header bits that they do not understand from the query message to the
+   response message.
+
+   A resolver MUST disregard the meaning of the CD and AD bits in a
+   response unless the response was obtained by using a secure channel
+   or the resolver was specifically configured to regard the message
+   header bits without using a secure channel.
+
+4.7.  Caching BAD Data
+
+   While many validation errors will be transient, some are likely to be
+   more persistent, such as those caused by administrative error
+   (failure to re-sign a zone, clock skew, and so forth).  Since
+   requerying will not help in these cases, validating resolvers might
+   generate a significant amount of unnecessary DNS traffic as a result
+   of repeated queries for RRsets with persistent validation failures.
+
+   To prevent such unnecessary DNS traffic, security-aware resolvers MAY
+   cache data with invalid signatures, with some restrictions.
+
+
+
+Arends, et al.              Standards Track                    [Page 22]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+   Conceptually, caching such data is similar to negative caching
+   ([RFC2308]), except that instead of caching a valid negative
+   response, the resolver is caching the fact that a particular answer
+   failed to validate.  This document refers to a cache of data with
+   invalid signatures as a "BAD cache".
+
+   Resolvers that implement a BAD cache MUST take steps to prevent the
+   cache from being useful as a denial-of-service attack amplifier,
+   particularly the following:
+
+   o  Since RRsets that fail to validate do not have trustworthy TTLs,
+      the implementation MUST assign a TTL.  This TTL SHOULD be small,
+      in order to mitigate the effect of caching the results of an
+      attack.
+
+   o  In order to prevent caching of a transient validation failure
+      (which might be the result of an attack), resolvers SHOULD track
+      queries that result in validation failures and SHOULD only answer
+      from the BAD cache after the number of times that responses to
+      queries for that particular <QNAME, QTYPE, QCLASS> have failed to
+      validate exceeds a threshold value.
+
+   Resolvers MUST NOT return RRsets from the BAD cache unless the
+   resolver is not required to validate the signatures of the RRsets in
+   question under the rules given in Section 4.2 of this document.  See
+   Section 3.2.2 for discussion of how the responses returned by a
+   security-aware recursive name server interact with a BAD cache.
+
+4.8.  Synthesized CNAMEs
+
+   A validating security-aware resolver MUST treat the signature of a
+   valid signed DNAME RR as also covering unsigned CNAME RRs that could
+   have been synthesized from the DNAME RR, as described in [RFC2672],
+   at least to the extent of not rejecting a response message solely
+   because it contains such CNAME RRs.  The resolver MAY retain such
+   CNAME RRs in its cache or in the answers it hands back, but is not
+   required to do so.
+
+4.9.  Stub Resolvers
+
+   A security-aware stub resolver MUST support the DNSSEC RR types, at
+   least to the extent of not mishandling responses just because they
+   contain DNSSEC RRs.
+
+
+
+
+
+
+
+
+Arends, et al.              Standards Track                    [Page 23]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+4.9.1.  Handling of the DO Bit
+
+   A non-validating security-aware stub resolver MAY include the DNSSEC
+   RRs returned by a security-aware recursive name server as part of the
+   data that the stub resolver hands back to the application that
+   invoked it, but is not required to do so.  A non-validating stub
+   resolver that seeks to do this will need to set the DO bit in order
+   to receive DNSSEC RRs from the recursive name server.
+
+   A validating security-aware stub resolver MUST set the DO bit,
+   because otherwise it will not receive the DNSSEC RRs it needs to
+   perform signature validation.
+
+4.9.2.  Handling of the CD Bit
+
+   A non-validating security-aware stub resolver SHOULD NOT set the CD
+   bit when sending queries unless it is requested by the application
+   layer, as by definition, a non-validating stub resolver depends on
+   the security-aware recursive name server to perform validation on its
+   behalf.
+
+   A validating security-aware stub resolver SHOULD set the CD bit,
+   because otherwise the security-aware recursive name server will
+   answer the query using the name server's local policy, which may
+   prevent the stub resolver from receiving data that would be
+   acceptable to the stub resolver's local policy.
+
+4.9.3.  Handling of the AD Bit
+
+   A non-validating security-aware stub resolver MAY chose to examine
+   the setting of the AD bit in response messages that it receives in
+   order to determine whether the security-aware recursive name server
+   that sent the response claims to have cryptographically verified the
+   data in the Answer and Authority sections of the response message.
+   Note, however, that the responses received by a security-aware stub
+   resolver are heavily dependent on the local policy of the
+   security-aware recursive name server.  Therefore, there may be little
+   practical value in checking the status of the AD bit, except perhaps
+   as a debugging aid.  In any case, a security-aware stub resolver MUST
+   NOT place any reliance on signature validation allegedly performed on
+   its behalf, except when the security-aware stub resolver obtained the
+   data in question from a trusted security-aware recursive name server
+   via a secure channel.
+
+   A validating security-aware stub resolver SHOULD NOT examine the
+   setting of the AD bit in response messages, as, by definition, the
+   stub resolver performs its own signature validation regardless of the
+   setting of the AD bit.
+
+
+
+Arends, et al.              Standards Track                    [Page 24]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+5.  Authenticating DNS Responses
+
+   To use DNSSEC RRs for authentication, a security-aware resolver
+   requires configured knowledge of at least one authenticated DNSKEY or
+   DS RR.  The process for obtaining and authenticating this initial
+   trust anchor is achieved via some external mechanism.  For example, a
+   resolver could use some off-line authenticated exchange to obtain a
+   zone's DNSKEY RR or to obtain a DS RR that identifies and
+   authenticates a zone's DNSKEY RR.  The remainder of this section
+   assumes that the resolver has somehow obtained an initial set of
+   trust anchors.
+
+   An initial DNSKEY RR can be used to authenticate a zone's apex DNSKEY
+   RRset.  To authenticate an apex DNSKEY RRset by using an initial key,
+   the resolver MUST:
+
+   1.  verify that the initial DNSKEY RR appears in the apex DNSKEY
+       RRset, and that the DNSKEY RR has the Zone Key Flag (DNSKEY RDATA
+       bit 7) set; and
+
+   2.  verify that there is some RRSIG RR that covers the apex DNSKEY
+       RRset, and that the combination of the RRSIG RR and the initial
+       DNSKEY RR authenticates the DNSKEY RRset.  The process for using
+       an RRSIG RR to authenticate an RRset is described in Section 5.3.
+
+   Once the resolver has authenticated the apex DNSKEY RRset by using an
+   initial DNSKEY RR, delegations from that zone can be authenticated by
+   using DS RRs.  This allows a resolver to start from an initial key
+   and use DS RRsets to proceed recursively down the DNS tree, obtaining
+   other apex DNSKEY RRsets.  If the resolver were configured with a
+   root DNSKEY RR, and if every delegation had a DS RR associated with
+   it, then the resolver could obtain and validate any apex DNSKEY
+   RRset.  The process of using DS RRs to authenticate referrals is
+   described in Section 5.2.
+
+   Section 5.3 shows how the resolver can use DNSKEY RRs in the apex
+   DNSKEY RRset and RRSIG RRs from the zone to authenticate any other
+   RRsets in the zone once the resolver has authenticated a zone's apex
+   DNSKEY RRset.  Section 5.4 shows how the resolver can use
+   authenticated NSEC RRsets from the zone to prove that an RRset is not
+   present in the zone.
+
+   When a resolver indicates support for DNSSEC (by setting the DO bit),
+   a security-aware name server should attempt to provide the necessary
+   DNSKEY, RRSIG, NSEC, and DS RRsets in a response (see Section 3).
+   However, a security-aware resolver may still receive a response that
+   lacks the appropriate DNSSEC RRs, whether due to configuration issues
+   such as an upstream security-oblivious recursive name server that
+
+
+
+Arends, et al.              Standards Track                    [Page 25]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+   accidentally interferes with DNSSEC RRs or due to a deliberate attack
+   in which an adversary forges a response, strips DNSSEC RRs from a
+   response, or modifies a query so that DNSSEC RRs appear not to be
+   requested.  The absence of DNSSEC data in a response MUST NOT by
+   itself be taken as an indication that no authentication information
+   exists.
+
+   A resolver SHOULD expect authentication information from signed
+   zones.  A resolver SHOULD believe that a zone is signed if the
+   resolver has been configured with public key information for the
+   zone, or if the zone's parent is signed and the delegation from the
+   parent contains a DS RRset.
+
+5.1.  Special Considerations for Islands of Security
+
+   Islands of security (see [RFC4033]) are signed zones for which it is
+   not possible to construct an authentication chain to the zone from
+   its parent.  Validating signatures within an island of security
+   requires that the validator have some other means of obtaining an
+   initial authenticated zone key for the island.  If a validator cannot
+   obtain such a key, it SHOULD switch to operating as if the zones in
+   the island of security are unsigned.
+
+   All the normal processes for validating responses apply to islands of
+   security.  The only difference between normal validation and
+   validation within an island of security is in how the validator
+   obtains a trust anchor for the authentication chain.
+
+5.2.  Authenticating Referrals
+
+   Once the apex DNSKEY RRset for a signed parent zone has been
+   authenticated, DS RRsets can be used to authenticate the delegation
+   to a signed child zone.  A DS RR identifies a DNSKEY RR in the child
+   zone's apex DNSKEY RRset and contains a cryptographic digest of the
+   child zone's DNSKEY RR.  Use of a strong cryptographic digest
+   algorithm ensures that it is computationally infeasible for an
+   adversary to generate a DNSKEY RR that matches the digest.  Thus,
+   authenticating the digest allows a resolver to authenticate the
+   matching DNSKEY RR.  The resolver can then use this child DNSKEY RR
+   to authenticate the entire child apex DNSKEY RRset.
+
+   Given a DS RR for a delegation, the child zone's apex DNSKEY RRset
+   can be authenticated if all of the following hold:
+
+   o  The DS RR has been authenticated using some DNSKEY RR in the
+      parent's apex DNSKEY RRset (see Section 5.3).
+
+
+
+
+
+Arends, et al.              Standards Track                    [Page 26]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+   o  The Algorithm and Key Tag in the DS RR match the Algorithm field
+      and the key tag of a DNSKEY RR in the child zone's apex DNSKEY
+      RRset, and, when the DNSKEY RR's owner name and RDATA are hashed
+      using the digest algorithm specified in the DS RR's Digest Type
+      field, the resulting digest value matches the Digest field of the
+      DS RR.
+
+   o  The matching DNSKEY RR in the child zone has the Zone Flag bit
+      set, the corresponding private key has signed the child zone's
+      apex DNSKEY RRset, and the resulting RRSIG RR authenticates the
+      child zone's apex DNSKEY RRset.
+
+   If the referral from the parent zone did not contain a DS RRset, the
+   response should have included a signed NSEC RRset proving that no DS
+   RRset exists for the delegated name (see Section 3.1.4).  A
+   security-aware resolver MUST query the name servers for the parent
+   zone for the DS RRset if the referral includes neither a DS RRset nor
+   a NSEC RRset proving that the DS RRset does not exist (see Section
+   4).
+
+   If the validator authenticates an NSEC RRset that proves that no DS
+   RRset is present for this zone, then there is no authentication path
+   leading from the parent to the child.  If the resolver has an initial
+   DNSKEY or DS RR that belongs to the child zone or to any delegation
+   below the child zone, this initial DNSKEY or DS RR MAY be used to
+   re-establish an authentication path.  If no such initial DNSKEY or DS
+   RR exists, the validator cannot authenticate RRsets in or below the
+   child zone.
+
+   If the validator does not support any of the algorithms listed in an
+   authenticated DS RRset, then the resolver has no supported
+   authentication path leading from the parent to the child.  The
+   resolver should treat this case as it would the case of an
+   authenticated NSEC RRset proving that no DS RRset exists, as
+   described above.
+
+   Note that, for a signed delegation, there are two NSEC RRs associated
+   with the delegated name.  One NSEC RR resides in the parent zone and
+   can be used to prove whether a DS RRset exists for the delegated
+   name.  The second NSEC RR resides in the child zone and identifies
+   which RRsets are present at the apex of the child zone.  The parent
+   NSEC RR and child NSEC RR can always be distinguished because the SOA
+   bit will be set in the child NSEC RR and clear in the parent NSEC RR.
+   A security-aware resolver MUST use the parent NSEC RR when attempting
+   to prove that a DS RRset does not exist.
+
+
+
+
+
+
+Arends, et al.              Standards Track                    [Page 27]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+   If the resolver does not support any of the algorithms listed in an
+   authenticated DS RRset, then the resolver will not be able to verify
+   the authentication path to the child zone.  In this case, the
+   resolver SHOULD treat the child zone as if it were unsigned.
+
+5.3.  Authenticating an RRset with an RRSIG RR
+
+   A validator can use an RRSIG RR and its corresponding DNSKEY RR to
+   attempt to authenticate RRsets.  The validator first checks the RRSIG
+   RR to verify that it covers the RRset, has a valid time interval, and
+   identifies a valid DNSKEY RR.  The validator then constructs the
+   canonical form of the signed data by appending the RRSIG RDATA
+   (excluding the Signature Field) with the canonical form of the
+   covered RRset.  Finally, the validator uses the public key and
+   signature to authenticate the signed data.  Sections 5.3.1, 5.3.2,
+   and 5.3.3 describe each step in detail.
+
+5.3.1.  Checking the RRSIG RR Validity
+
+   A security-aware resolver can use an RRSIG RR to authenticate an
+   RRset if all of the following conditions hold:
+
+   o  The RRSIG RR and the RRset MUST have the same owner name and the
+      same class.
+
+   o  The RRSIG RR's Signer's Name field MUST be the name of the zone
+      that contains the RRset.
+
+   o  The RRSIG RR's Type Covered field MUST equal the RRset's type.
+
+   o  The number of labels in the RRset owner name MUST be greater than
+      or equal to the value in the RRSIG RR's Labels field.
+
+   o  The validator's notion of the current time MUST be less than or
+      equal to the time listed in the RRSIG RR's Expiration field.
+
+   o  The validator's notion of the current time MUST be greater than or
+      equal to the time listed in the RRSIG RR's Inception field.
+
+   o  The RRSIG RR's Signer's Name, Algorithm, and Key Tag fields MUST
+      match the owner name, algorithm, and key tag for some DNSKEY RR in
+      the zone's apex DNSKEY RRset.
+
+   o  The matching DNSKEY RR MUST be present in the zone's apex DNSKEY
+      RRset, and MUST have the Zone Flag bit (DNSKEY RDATA Flag bit 7)
+      set.
+
+
+
+
+
+Arends, et al.              Standards Track                    [Page 28]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+   It is possible for more than one DNSKEY RR to match the conditions
+   above.  In this case, the validator cannot predetermine which DNSKEY
+   RR to use to authenticate the signature, and it MUST try each
+   matching DNSKEY RR until either the signature is validated or the
+   validator has run out of matching public keys to try.
+
+   Note that this authentication process is only meaningful if the
+   validator authenticates the DNSKEY RR before using it to validate
+   signatures.  The matching DNSKEY RR is considered to be authentic if:
+
+   o  the apex DNSKEY RRset containing the DNSKEY RR is considered
+      authentic; or
+
+   o  the RRset covered by the RRSIG RR is the apex DNSKEY RRset itself,
+      and the DNSKEY RR either matches an authenticated DS RR from the
+      parent zone or matches a trust anchor.
+
+5.3.2.  Reconstructing the Signed Data
+
+   Once the RRSIG RR has met the validity requirements described in
+   Section 5.3.1, the validator has to reconstruct the original signed
+   data.  The original signed data includes RRSIG RDATA (excluding the
+   Signature field) and the canonical form of the RRset.  Aside from
+   being ordered, the canonical form of the RRset might also differ from
+   the received RRset due to DNS name compression, decremented TTLs, or
+   wildcard expansion.  The validator should use the following to
+   reconstruct the original signed data:
+
+         signed_data = RRSIG_RDATA | RR(1) | RR(2)...  where
+
+            "|" denotes concatenation
+
+            RRSIG_RDATA is the wire format of the RRSIG RDATA fields
+               with the Signature field excluded and the Signer's Name
+               in canonical form.
+
+            RR(i) = name | type | class | OrigTTL | RDATA length | RDATA
+
+               name is calculated according to the function below
+
+               class is the RRset's class
+
+               type is the RRset type and all RRs in the class
+
+               OrigTTL is the value from the RRSIG Original TTL field
+
+               All names in the RDATA field are in canonical form
+
+
+
+
+Arends, et al.              Standards Track                    [Page 29]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+               The set of all RR(i) is sorted into canonical order.
+
+            To calculate the name:
+               let rrsig_labels = the value of the RRSIG Labels field
+
+               let fqdn = RRset's fully qualified domain name in
+                               canonical form
+
+               let fqdn_labels = Label count of the fqdn above.
+
+               if rrsig_labels = fqdn_labels,
+                   name = fqdn
+
+               if rrsig_labels < fqdn_labels,
+                  name = "*." | the rightmost rrsig_label labels of the
+                                fqdn
+
+               if rrsig_labels > fqdn_labels
+                  the RRSIG RR did not pass the necessary validation
+                  checks and MUST NOT be used to authenticate this
+                  RRset.
+
+   The canonical forms for names and RRsets are defined in [RFC4034].
+
+   NSEC RRsets at a delegation boundary require special processing.
+   There are two distinct NSEC RRsets associated with a signed delegated
+   name.  One NSEC RRset resides in the parent zone, and specifies which
+   RRsets are present at the parent zone.  The second NSEC RRset resides
+   at the child zone and identifies which RRsets are present at the apex
+   in the child zone.  The parent NSEC RRset and child NSEC RRset can
+   always be distinguished as only a child NSEC RR will indicate that an
+   SOA RRset exists at the name.  When reconstructing the original NSEC
+   RRset for the delegation from the parent zone, the NSEC RRs MUST NOT
+   be combined with NSEC RRs from the child zone.  When reconstructing
+   the original NSEC RRset for the apex of the child zone, the NSEC RRs
+   MUST NOT be combined with NSEC RRs from the parent zone.
+
+   Note that each of the two NSEC RRsets at a delegation point has a
+   corresponding RRSIG RR with an owner name matching the delegated
+   name, and each of these RRSIG RRs is authoritative data associated
+   with the same zone that contains the corresponding NSEC RRset.  If
+   necessary, a resolver can tell these RRSIG RRs apart by checking the
+   Signer's Name field.
+
+
+
+
+
+
+
+
+Arends, et al.              Standards Track                    [Page 30]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+5.3.3.  Checking the Signature
+
+   Once the resolver has validated the RRSIG RR as described in Section
+   5.3.1 and reconstructed the original signed data as described in
+   Section 5.3.2, the validator can attempt to use the cryptographic
+   signature to authenticate the signed data, and thus (finally!)
+   authenticate the RRset.
+
+   The Algorithm field in the RRSIG RR identifies the cryptographic
+   algorithm used to generate the signature.  The signature itself is
+   contained in the Signature field of the RRSIG RDATA, and the public
+   key used to verify the signature is contained in the Public Key field
+   of the matching DNSKEY RR(s) (found in Section 5.3.1).  [RFC4034]
+   provides a list of algorithm types and provides pointers to the
+   documents that define each algorithm's use.
+
+   Note that it is possible for more than one DNSKEY RR to match the
+   conditions in Section 5.3.1.  In this case, the validator can only
+   determine which DNSKEY RR is correct by trying each matching public
+   key until the validator either succeeds in validating the signature
+   or runs out of keys to try.
+
+   If the Labels field of the RRSIG RR is not equal to the number of
+   labels in the RRset's fully qualified owner name, then the RRset is
+   either invalid or the result of wildcard expansion.  The resolver
+   MUST verify that wildcard expansion was applied properly before
+   considering the RRset to be authentic.  Section 5.3.4 describes how
+   to determine whether a wildcard was applied properly.
+
+   If other RRSIG RRs also cover this RRset, the local resolver security
+   policy determines whether the resolver also has to test these RRSIG
+   RRs and how to resolve conflicts if these RRSIG RRs lead to differing
+   results.
+
+   If the resolver accepts the RRset as authentic, the validator MUST
+   set the TTL of the RRSIG RR and each RR in the authenticated RRset to
+   a value no greater than the minimum of:
+
+   o  the RRset's TTL as received in the response;
+
+   o  the RRSIG RR's TTL as received in the response;
+
+   o  the value in the RRSIG RR's Original TTL field; and
+
+   o  the difference of the RRSIG RR's Signature Expiration time and the
+      current time.
+
+
+
+
+
+Arends, et al.              Standards Track                    [Page 31]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+5.3.4.  Authenticating a Wildcard Expanded RRset Positive Response
+
+   If the number of labels in an RRset's owner name is greater than the
+   Labels field of the covering RRSIG RR, then the RRset and its
+   covering RRSIG RR were created as a result of wildcard expansion.
+   Once the validator has verified the signature, as described in
+   Section 5.3, it must take additional steps to verify the non-
+   existence of an exact match or closer wildcard match for the query.
+   Section 5.4 discusses these steps.
+
+   Note that the response received by the resolver should include all
+   NSEC RRs needed to authenticate the response (see Section 3.1.3).
+
+5.4.  Authenticated Denial of Existence
+
+   A resolver can use authenticated NSEC RRs to prove that an RRset is
+   not present in a signed zone.  Security-aware name servers should
+   automatically include any necessary NSEC RRs for signed zones in
+   their responses to security-aware resolvers.
+
+   Denial of existence is determined by the following rules:
+
+   o  If the requested RR name matches the owner name of an
+      authenticated NSEC RR, then the NSEC RR's type bit map field lists
+      all RR types present at that owner name, and a resolver can prove
+      that the requested RR type does not exist by checking for the RR
+      type in the bit map.  If the number of labels in an authenticated
+      NSEC RR's owner name equals the Labels field of the covering RRSIG
+      RR, then the existence of the NSEC RR proves that wildcard
+      expansion could not have been used to match the request.
+
+   o  If the requested RR name would appear after an authenticated NSEC
+      RR's owner name and before the name listed in that NSEC RR's Next
+      Domain Name field according to the canonical DNS name order
+      defined in [RFC4034], then no RRsets with the requested name exist
+      in the zone.  However, it is possible that a wildcard could be
+      used to match the requested RR owner name and type, so proving
+      that the requested RRset does not exist also requires proving that
+      no possible wildcard RRset exists that could have been used to
+      generate a positive response.
+
+   In addition, security-aware resolvers MUST authenticate the NSEC
+   RRsets that comprise the non-existence proof as described in Section
+   5.3.
+
+   To prove the non-existence of an RRset, the resolver must be able to
+   verify both that the queried RRset does not exist and that no
+   relevant wildcard RRset exists.  Proving this may require more than
+
+
+
+Arends, et al.              Standards Track                    [Page 32]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+   one NSEC RRset from the zone.  If the complete set of necessary NSEC
+   RRsets is not present in a response (perhaps due to message
+   truncation), then a security-aware resolver MUST resend the query in
+   order to attempt to obtain the full collection of NSEC RRs necessary
+   to verify the non-existence of the requested RRset.  As with all DNS
+   operations, however, the resolver MUST bound the work it puts into
+   answering any particular query.
+
+   Since a validated NSEC RR proves the existence of both itself and its
+   corresponding RRSIG RR, a validator MUST ignore the settings of the
+   NSEC and RRSIG bits in an NSEC RR.
+
+5.5.  Resolver Behavior When Signatures Do Not Validate
+
+   If for whatever reason none of the RRSIGs can be validated, the
+   response SHOULD be considered BAD.  If the validation was being done
+   to service a recursive query, the name server MUST return RCODE 2 to
+   the originating client.  However, it MUST return the full response if
+   and only if the original query had the CD bit set.  Also see Section
+   4.7 on caching responses that do not validate.
+
+5.6.  Authentication Example
+
+   Appendix C shows an example of the authentication process.
+
+6.  IANA Considerations
+
+   [RFC4034] contains a review of the IANA considerations introduced by
+   DNSSEC.  The following are additional IANA considerations discussed
+   in this document:
+
+   [RFC2535] reserved the CD and AD bits in the message header.  The
+   meaning of the AD bit was redefined in [RFC3655], and the meaning of
+   both the CD and AD bit are restated in this document.  No new bits in
+   the DNS message header are defined in this document.
+
+   [RFC2671] introduced EDNS, and [RFC3225] reserved the DNSSEC OK bit
+   and defined its use.  The use is restated but not altered in this
+   document.
+
+7.  Security Considerations
+
+   This document describes how the DNS security extensions use public
+   key cryptography to sign and authenticate DNS resource record sets.
+   Please see [RFC4033] for terminology and general security
+   considerations related to DNSSEC; see [RFC4034] for considerations
+   specific to the DNSSEC resource record types.
+
+
+
+
+Arends, et al.              Standards Track                    [Page 33]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+   An active attacker who can set the CD bit in a DNS query message or
+   the AD bit in a DNS response message can use these bits to defeat the
+   protection that DNSSEC attempts to provide to security-oblivious
+   recursive-mode resolvers.  For this reason, use of these control bits
+   by a security-aware recursive-mode resolver requires a secure
+   channel.  See Sections 3.2.2 and 4.9 for further discussion.
+
+   The protocol described in this document attempts to extend the
+   benefits of DNSSEC to security-oblivious stub resolvers.  However, as
+   recovery from validation failures is likely to be specific to
+   particular applications, the facilities that DNSSEC provides for stub
+   resolvers may prove inadequate.  Operators of security-aware
+   recursive name servers will have to pay close attention to the
+   behavior of the applications that use their services when choosing a
+   local validation policy; failure to do so could easily result in the
+   recursive name server accidentally denying service to the clients it
+   is intended to support.
+
+8.  Acknowledgements
+
+   This document was created from the input and ideas of the members of
+   the DNS Extensions Working Group and working group mailing list.  The
+   editors would like to express their thanks for the comments and
+   suggestions received during the revision of these security extension
+   specifications.  Although explicitly listing everyone who has
+   contributed during the decade in which DNSSEC has been under
+   development would be impossible, [RFC4033] includes a list of some of
+   the participants who were kind enough to comment on these documents.
+
+9.  References
+
+9.1.  Normative References
+
+   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
+              STD 13, RFC 1034, November 1987.
+
+   [RFC1035]  Mockapetris, P., "Domain names - implementation and
+              specification", STD 13, RFC 1035, November 1987.
+
+   [RFC1122]  Braden, R., "Requirements for Internet Hosts -
+              Communication Layers", STD 3, RFC 1122, October 1989.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2181]  Elz, R. and R. Bush, "Clarifications to the DNS
+              Specification", RFC 2181, July 1997.
+
+
+
+
+Arends, et al.              Standards Track                    [Page 34]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
+              (IPv6) Specification", RFC 2460, December 1998.
+
+   [RFC2671]  Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
+              2671, August 1999.
+
+   [RFC2672]  Crawford, M., "Non-Terminal DNS Name Redirection", RFC
+              2672, August 1999.
+
+   [RFC3225]  Conrad, D., "Indicating Resolver Support of DNSSEC", RFC
+              3225, December 2001.
+
+   [RFC3226]  Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver
+              message size requirements", RFC 3226, December 2001.
+
+   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
+              Rose, "DNS Security Introduction and Requirements", RFC
+              4033, March 2005.
+
+   [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
+              Rose, "Resource Records for DNS Security Extensions", RFC
+              4034, March 2005.
+
+9.2.  Informative References
+
+   [RFC2308]  Andrews, M., "Negative Caching of DNS Queries (DNS
+              NCACHE)", RFC 2308, March 1998.
+
+   [RFC2535]  Eastlake 3rd, D., "Domain Name System Security
+              Extensions", RFC 2535, March 1999.
+
+   [RFC3007]  Wellington, B., "Secure Domain Name System (DNS) Dynamic
+              Update", RFC 3007, November 2000.
+
+   [RFC3655]  Wellington, B. and O. Gudmundsson, "Redefinition of DNS
+              Authenticated Data (AD) bit", RFC 3655, November 2003.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al.              Standards Track                    [Page 35]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+Appendix A.  Signed Zone Example
+
+   The following example shows a (small) complete signed zone.
+
+   example.       3600 IN SOA ns1.example. bugs.x.w.example. (
+                              1081539377
+                              3600
+                              300
+                              3600000
+                              3600
+                              )
+                  3600 RRSIG  SOA 5 1 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h
+                              7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF
+                              vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW
+                              DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB
+                              jV7j86HyQgM5e7+miRAz8V01b0I= )
+                  3600 NS     ns1.example.
+                  3600 NS     ns2.example.
+                  3600 RRSIG  NS 5 1 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              gl13F00f2U0R+SWiXXLHwsMY+qStYy5k6zfd
+                              EuivWc+wd1fmbNCyql0Tk7lHTX6UOxc8AgNf
+                              4ISFve8XqF4q+o9qlnqIzmppU3LiNeKT4FZ8
+                              RO5urFOvoMRTbQxW3U0hXWuggE4g3ZpsHv48
+                              0HjMeRaZB/FRPGfJPajngcq6Kwg= )
+                  3600 MX     1 xx.example.
+                  3600 RRSIG  MX 5 1 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              HyDHYVT5KHSZ7HtO/vypumPmSZQrcOP3tzWB
+                              2qaKkHVPfau/DgLgS/IKENkYOGL95G4N+NzE
+                              VyNU8dcTOckT+ChPcGeVjguQ7a3Ao9Z/ZkUO
+                              6gmmUW4b89rz1PUxW4jzUxj66PTwoVtUU/iM
+                              W6OISukd1EQt7a0kygkg+PEDxdI= )
+                  3600 NSEC   a.example. NS SOA MX RRSIG NSEC DNSKEY
+                  3600 RRSIG  NSEC 5 1 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              O0k558jHhyrC97ISHnislm4kLMW48C7U7cBm
+                              FTfhke5iVqNRVTB1STLMpgpbDIC9hcryoO0V
+                              Z9ME5xPzUEhbvGnHd5sfzgFVeGxr5Nyyq4tW
+                              SDBgIBiLQUv1ivy29vhXy7WgR62dPrZ0PWvm
+                              jfFJ5arXf4nPxp/kEowGgBRzY/U= )
+                  3600 DNSKEY 256 3 5 (
+                              AQOy1bZVvpPqhg4j7EJoM9rI3ZmyEx2OzDBV
+                              rZy/lvI5CQePxXHZS4i8dANH4DX3tbHol61e
+                              k8EFMcsGXxKciJFHyhl94C+NwILQdzsUlSFo
+                              vBZsyl/NX6yEbtw/xN9ZNcrbYvgjjZ/UVPZI
+
+
+
+Arends, et al.              Standards Track                    [Page 36]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+                              ySFNsgEYvh0z2542lzMKR4Dh8uZffQ==
+                              )
+                  3600 DNSKEY 257 3 5 (
+                              AQOeX7+baTmvpVHb2CcLnL1dMRWbuscRvHXl
+                              LnXwDzvqp4tZVKp1sZMepFb8MvxhhW3y/0QZ
+                              syCjczGJ1qk8vJe52iOhInKROVLRwxGpMfzP
+                              RLMlGybr51bOV/1se0ODacj3DomyB4QB5gKT
+                              Yot/K9alk5/j8vfd4jWCWD+E1Sze0Q==
+                              )
+                  3600 RRSIG  DNSKEY 5 1 3600 20040509183619 (
+                              20040409183619 9465 example.
+                              ZxgauAuIj+k1YoVEOSlZfx41fcmKzTFHoweZ
+                              xYnz99JVQZJ33wFS0Q0jcP7VXKkaElXk9nYJ
+                              XevO/7nAbo88iWsMkSpSR6jWzYYKwfrBI/L9
+                              hjYmyVO9m6FjQ7uwM4dCP/bIuV/DKqOAK9NY
+                              NC3AHfvCV1Tp4VKDqxqG7R5tTVM= )
+                  3600 RRSIG  DNSKEY 5 1 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              eGL0s90glUqcOmloo/2y+bSzyEfKVOQViD9Z
+                              DNhLz/Yn9CQZlDVRJffACQDAUhXpU/oP34ri
+                              bKBpysRXosczFrKqS5Oa0bzMOfXCXup9qHAp
+                              eFIku28Vqfr8Nt7cigZLxjK+u0Ws/4lIRjKk
+                              7z5OXogYVaFzHKillDt3HRxHIZM= )
+   a.example.     3600 IN NS  ns1.a.example.
+                  3600 IN NS  ns2.a.example.
+                  3600 DS     57855 5 1 (
+                              B6DCD485719ADCA18E5F3D48A2331627FDD3
+                              636B )
+                  3600 RRSIG  DS 5 2 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              oXIKit/QtdG64J/CB+Gi8dOvnwRvqrto1AdQ
+                              oRkAN15FP3iZ7suB7gvTBmXzCjL7XUgQVcoH
+                              kdhyCuzp8W9qJHgRUSwKKkczSyuL64nhgjuD
+                              EML8l9wlWVsl7PR2VnZduM9bLyBhaaPmRKX/
+                              Fm+v6ccF2EGNLRiY08kdkz+XHHo= )
+                  3600 NSEC   ai.example. NS DS RRSIG NSEC
+                  3600 RRSIG  NSEC 5 2 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              cOlYgqJLqlRqmBQ3iap2SyIsK4O5aqpKSoba
+                              U9fQ5SMApZmHfq3AgLflkrkXRXvgxTQSKkG2
+                              039/cRUs6Jk/25+fi7Xr5nOVJsb0lq4zsB3I
+                              BBdjyGDAHE0F5ROJj87996vJupdm1fbH481g
+                              sdkOW6Zyqtz3Zos8N0BBkEx+2G4= )
+   ns1.a.example. 3600 IN A   192.0.2.5
+   ns2.a.example. 3600 IN A   192.0.2.6
+   ai.example.    3600 IN A   192.0.2.9
+                  3600 RRSIG  A 5 2 3600 20040509183619 (
+                              20040409183619 38519 example.
+
+
+
+Arends, et al.              Standards Track                    [Page 37]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+                              pAOtzLP2MU0tDJUwHOKE5FPIIHmdYsCgTb5B
+                              ERGgpnJluA9ixOyf6xxVCgrEJW0WNZSsJicd
+                              hBHXfDmAGKUajUUlYSAH8tS4ZnrhyymIvk3u
+                              ArDu2wfT130e9UHnumaHHMpUTosKe22PblOy
+                              6zrTpg9FkS0XGVmYRvOTNYx2HvQ= )
+                  3600 HINFO  "KLH-10" "ITS"
+                  3600 RRSIG  HINFO 5 2 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              Iq/RGCbBdKzcYzlGE4ovbr5YcB+ezxbZ9W0l
+                              e/7WqyvhOO9J16HxhhL7VY/IKmTUY0GGdcfh
+                              ZEOCkf4lEykZF9NPok1/R/fWrtzNp8jobuY7
+                              AZEcZadp1WdDF3jc2/ndCa5XZhLKD3JzOsBw
+                              FvL8sqlS5QS6FY/ijFEDnI4RkZA= )
+                  3600 AAAA   2001:db8::f00:baa9
+                  3600 RRSIG  AAAA 5 2 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              nLcpFuXdT35AcE+EoafOUkl69KB+/e56XmFK
+                              kewXG2IadYLKAOBIoR5+VoQV3XgTcofTJNsh
+                              1rnF6Eav2zpZB3byI6yo2bwY8MNkr4A7cL9T
+                              cMmDwV/hWFKsbGBsj8xSCN/caEL2CWY/5XP2
+                              sZM6QjBBLmukH30+w1z3h8PUP2o= )
+                  3600 NSEC   b.example. A HINFO AAAA RRSIG NSEC
+                  3600 RRSIG  NSEC 5 2 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              QoshyPevLcJ/xcRpEtMft1uoIrcrieVcc9pG
+                              CScIn5Glnib40T6ayVOimXwdSTZ/8ISXGj4p
+                              P8Sh0PlA6olZQ84L453/BUqB8BpdOGky4hsN
+                              3AGcLEv1Gr0QMvirQaFcjzOECfnGyBm+wpFL
+                              AhS+JOVfDI/79QtyTI0SaDWcg8U= )
+   b.example.     3600 IN NS  ns1.b.example.
+                  3600 IN NS  ns2.b.example.
+                  3600 NSEC   ns1.example. NS RRSIG NSEC
+                  3600 RRSIG  NSEC 5 2 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              GNuxHn844wfmUhPzGWKJCPY5ttEX/RfjDoOx
+                              9ueK1PtYkOWKOOdiJ/PJKCYB3hYX+858dDWS
+                              xb2qnV/LSTCNVBnkm6owOpysY97MVj5VQEWs
+                              0lm9tFoqjcptQkmQKYPrwUnCSNwvvclSF1xZ
+                              vhRXgWT7OuFXldoCG6TfVFMs9xE= )
+   ns1.b.example. 3600 IN A   192.0.2.7
+   ns2.b.example. 3600 IN A   192.0.2.8
+   ns1.example.   3600 IN A   192.0.2.1
+                  3600 RRSIG  A 5 2 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              F1C9HVhIcs10cZU09G5yIVfKJy5yRQQ3qVet
+                              5pGhp82pzhAOMZ3K22JnmK4c+IjUeFp/to06
+                              im5FVpHtbFisdjyPq84bhTv8vrXt5AB1wNB+
+                              +iAqvIfdgW4sFNC6oADb1hK8QNauw9VePJhK
+
+
+
+Arends, et al.              Standards Track                    [Page 38]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+                              v/iVXSYC0b7mPSU+EOlknFpVECs= )
+                  3600 NSEC   ns2.example. A RRSIG NSEC
+                  3600 RRSIG  NSEC 5 2 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              I4hj+Kt6+8rCcHcUdolks2S+Wzri9h3fHas8
+                              1rGN/eILdJHN7JpV6lLGPIh/8fIBkfvdyWnB
+                              jjf1q3O7JgYO1UdI7FvBNWqaaEPJK3UkddBq
+                              ZIaLi8Qr2XHkjq38BeQsbp8X0+6h4ETWSGT8
+                              IZaIGBLryQWGLw6Y6X8dqhlnxJM= )
+   ns2.example.   3600 IN A   192.0.2.2
+                  3600 RRSIG  A 5 2 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              V7cQRw1TR+knlaL1z/psxlS1PcD37JJDaCMq
+                              Qo6/u1qFQu6x+wuDHRH22Ap9ulJPQjFwMKOu
+                              yfPGQPC8KzGdE3vt5snFEAoE1Vn3mQqtu7SO
+                              6amIjk13Kj/jyJ4nGmdRIc/3cM3ipXFhNTKq
+                              rdhx8SZ0yy4ObIRzIzvBFLiSS8o= )
+                  3600 NSEC   *.w.example. A RRSIG NSEC
+                  3600 RRSIG  NSEC 5 2 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              N0QzHvaJf5NRw1rE9uxS1Ltb2LZ73Qb9bKGE
+                              VyaISkqzGpP3jYJXZJPVTq4UVEsgT3CgeHvb
+                              3QbeJ5Dfb2V9NGCHj/OvF/LBxFFWwhLwzngH
+                              l+bQAgAcMsLu/nL3nDi1y/JSQjAcdZNDl4bw
+                              Ymx28EtgIpo9A0qmP08rMBqs1Jw= )
+   *.w.example.   3600 IN MX  1 ai.example.
+                  3600 RRSIG  MX 5 2 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              OMK8rAZlepfzLWW75Dxd63jy2wswESzxDKG2
+                              f9AMN1CytCd10cYISAxfAdvXSZ7xujKAtPbc
+                              tvOQ2ofO7AZJ+d01EeeQTVBPq4/6KCWhqe2X
+                              TjnkVLNvvhnc0u28aoSsG0+4InvkkOHknKxw
+                              4kX18MMR34i8lC36SR5xBni8vHI= )
+                  3600 NSEC   x.w.example. MX RRSIG NSEC
+                  3600 RRSIG  NSEC 5 2 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              r/mZnRC3I/VIcrelgIcteSxDhtsdlTDt8ng9
+                              HSBlABOlzLxQtfgTnn8f+aOwJIAFe1Ee5RvU
+                              5cVhQJNP5XpXMJHfyps8tVvfxSAXfahpYqtx
+                              91gsmcV/1V9/bZAG55CefP9cM4Z9Y9NT9XQ8
+                              s1InQ2UoIv6tJEaaKkP701j8OLA= )
+   x.w.example.   3600 IN MX  1 xx.example.
+                  3600 RRSIG  MX 5 3 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              Il2WTZ+Bkv+OytBx4LItNW5mjB4RCwhOO8y1
+                              XzPHZmZUTVYL7LaA63f6T9ysVBzJRI3KRjAP
+                              H3U1qaYnDoN1DrWqmi9RJe4FoObkbcdm7P3I
+                              kx70ePCoFgRz1Yq+bVVXCvGuAU4xALv3W/Y1
+
+
+
+Arends, et al.              Standards Track                    [Page 39]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+                              jNSlwZ2mSWKHfxFQxPtLj8s32+k= )
+                  3600 NSEC   x.y.w.example. MX RRSIG NSEC
+                  3600 RRSIG  NSEC 5 3 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              aRbpHftxggzgMXdDlym9SsADqMZovZZl2QWK
+                              vw8J0tZEUNQByH5Qfnf5N1FqH/pS46UA7A4E
+                              mcWBN9PUA1pdPY6RVeaRlZlCr1IkVctvbtaI
+                              NJuBba/VHm+pebTbKcAPIvL9tBOoh+to1h6e
+                              IjgiM8PXkBQtxPq37wDKALkyn7Q= )
+   x.y.w.example. 3600 IN MX  1 xx.example.
+                  3600 RRSIG  MX 5 4 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              k2bJHbwP5LH5qN4is39UiPzjAWYmJA38Hhia
+                              t7i9t7nbX/e0FPnvDSQXzcK7UL+zrVA+3MDj
+                              q1ub4q3SZgcbLMgexxIW3Va//LVrxkP6Xupq
+                              GtOB9prkK54QTl/qZTXfMQpW480YOvVknhvb
+                              +gLcMZBnHJ326nb/TOOmrqNmQQE= )
+                  3600 NSEC   xx.example. MX RRSIG NSEC
+                  3600 RRSIG  NSEC 5 4 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              OvE6WUzN2ziieJcvKPWbCAyXyP6ef8cr6Csp
+                              ArVSTzKSquNwbezZmkU7E34o5lmb6CWSSSpg
+                              xw098kNUFnHcQf/LzY2zqRomubrNQhJTiDTX
+                              a0ArunJQCzPjOYq5t0SLjm6qp6McJI1AP5Vr
+                              QoKqJDCLnoAlcPOPKAm/jJkn3jk= )
+   xx.example.    3600 IN A   192.0.2.10
+                  3600 RRSIG  A 5 2 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              kBF4YxMGWF0D8r0cztL+2fWWOvN1U/GYSpYP
+                              7SoKoNQ4fZKyk+weWGlKLIUM+uE1zjVTPXoa
+                              0Z6WG0oZp46rkl1EzMcdMgoaeUzzAJ2BMq+Y
+                              VdxG9IK1yZkYGY9AgbTOGPoAgbJyO9EPULsx
+                              kbIDV6GPPSZVusnZU6OMgdgzHV4= )
+                  3600 HINFO  "KLH-10" "TOPS-20"
+                  3600 RRSIG  HINFO 5 2 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              GY2PLSXmMHkWHfLdggiox8+chWpeMNJLkML0
+                              t+U/SXSUsoUdR91KNdNUkTDWamwcF8oFRjhq
+                              BcPZ6EqrF+vl5v5oGuvSF7U52epfVTC+wWF8
+                              3yCUeUw8YklhLWlvk8gQ15YKth0ITQy8/wI+
+                              RgNvuwbioFSEuv2pNlkq0goYxNY= )
+                  3600 AAAA   2001:db8::f00:baaa
+                  3600 RRSIG  AAAA 5 2 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              Zzj0yodDxcBLnnOIwDsuKo5WqiaK24DlKg9C
+                              aGaxDFiKgKobUj2jilYQHpGFn2poFRetZd4z
+                              ulyQkssz2QHrVrPuTMS22knudCiwP4LWpVTr
+                              U4zfeA+rDz9stmSBP/4PekH/x2IoAYnwctd/
+
+
+
+Arends, et al.              Standards Track                    [Page 40]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+                              xS9cL2QgW7FChw16mzlkH6/vsfs= )
+                  3600 NSEC   example. A HINFO AAAA RRSIG NSEC
+                  3600 RRSIG  NSEC 5 2 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              ZFWUln6Avc8bmGl5GFjD3BwT530DUZKHNuoY
+                              9A8lgXYyrxu+pqgFiRVbyZRQvVB5pccEOT3k
+                              mvHgEa/HzbDB4PIYY79W+VHrgOxzdQGGCZzi
+                              asXrpSGOWwSOElghPnMIi8xdF7qtCntr382W
+                              GghLahumFIpg4MO3LS/prgzVVWo= )
+
+   The apex DNSKEY set includes two DNSKEY RRs, and the DNSKEY RDATA
+   Flags indicate that each of these DNSKEY RRs is a zone key.  One of
+   these DNSKEY RRs also has the SEP flag set and has been used to sign
+   the apex DNSKEY RRset; this is the key that should be hashed to
+   generate a DS record to be inserted into the parent zone.  The other
+   DNSKEY is used to sign all the other RRsets in the zone.
+
+   The zone includes a wildcard entry, "*.w.example".  Note that the
+   name "*.w.example" is used in constructing NSEC chains, and that the
+   RRSIG covering the "*.w.example" MX RRset has a label count of 2.
+
+   The zone also includes two delegations.  The delegation to
+   "b.example" includes an NS RRset, glue address records, and an NSEC
+   RR; note that only the NSEC RRset is signed.  The delegation to
+   "a.example" provides a DS RR; note that only the NSEC and DS RRsets
+   are signed.
+
+Appendix B.  Example Responses
+
+   The examples in this section show response messages using the signed
+   zone example in Appendix A.
+
+B.1.  Answer
+
+   A successful query to an authoritative server.
+
+   ;; Header: QR AA DO RCODE=0
+   ;;
+   ;; Question
+   x.w.example.        IN MX
+
+   ;; Answer
+   x.w.example.   3600 IN MX  1 xx.example.
+   x.w.example.   3600 RRSIG  MX 5 3 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              Il2WTZ+Bkv+OytBx4LItNW5mjB4RCwhOO8y1
+                              XzPHZmZUTVYL7LaA63f6T9ysVBzJRI3KRjAP
+                              H3U1qaYnDoN1DrWqmi9RJe4FoObkbcdm7P3I
+
+
+
+Arends, et al.              Standards Track                    [Page 41]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+                              kx70ePCoFgRz1Yq+bVVXCvGuAU4xALv3W/Y1
+                              jNSlwZ2mSWKHfxFQxPtLj8s32+k= )
+
+   ;; Authority
+   example.       3600 NS     ns1.example.
+   example.       3600 NS     ns2.example.
+   example.       3600 RRSIG  NS 5 1 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              gl13F00f2U0R+SWiXXLHwsMY+qStYy5k6zfd
+                              EuivWc+wd1fmbNCyql0Tk7lHTX6UOxc8AgNf
+                              4ISFve8XqF4q+o9qlnqIzmppU3LiNeKT4FZ8
+                              RO5urFOvoMRTbQxW3U0hXWuggE4g3ZpsHv48
+                              0HjMeRaZB/FRPGfJPajngcq6Kwg= )
+
+   ;; Additional
+   xx.example.    3600 IN A   192.0.2.10
+   xx.example.    3600 RRSIG  A 5 2 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              kBF4YxMGWF0D8r0cztL+2fWWOvN1U/GYSpYP
+                              7SoKoNQ4fZKyk+weWGlKLIUM+uE1zjVTPXoa
+                              0Z6WG0oZp46rkl1EzMcdMgoaeUzzAJ2BMq+Y
+                              VdxG9IK1yZkYGY9AgbTOGPoAgbJyO9EPULsx
+                              kbIDV6GPPSZVusnZU6OMgdgzHV4= )
+   xx.example.    3600 AAAA   2001:db8::f00:baaa
+   xx.example.    3600 RRSIG  AAAA 5 2 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              Zzj0yodDxcBLnnOIwDsuKo5WqiaK24DlKg9C
+                              aGaxDFiKgKobUj2jilYQHpGFn2poFRetZd4z
+                              ulyQkssz2QHrVrPuTMS22knudCiwP4LWpVTr
+                              U4zfeA+rDz9stmSBP/4PekH/x2IoAYnwctd/
+                              xS9cL2QgW7FChw16mzlkH6/vsfs= )
+   ns1.example.   3600 IN A   192.0.2.1
+   ns1.example.   3600 RRSIG  A 5 2 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              F1C9HVhIcs10cZU09G5yIVfKJy5yRQQ3qVet
+                              5pGhp82pzhAOMZ3K22JnmK4c+IjUeFp/to06
+                              im5FVpHtbFisdjyPq84bhTv8vrXt5AB1wNB+
+                              +iAqvIfdgW4sFNC6oADb1hK8QNauw9VePJhK
+                              v/iVXSYC0b7mPSU+EOlknFpVECs= )
+   ns2.example.   3600 IN A   192.0.2.2
+   ns2.example.   3600 RRSIG  A 5 2 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              V7cQRw1TR+knlaL1z/psxlS1PcD37JJDaCMq
+                              Qo6/u1qFQu6x+wuDHRH22Ap9ulJPQjFwMKOu
+                              yfPGQPC8KzGdE3vt5snFEAoE1Vn3mQqtu7SO
+                              6amIjk13Kj/jyJ4nGmdRIc/3cM3ipXFhNTKq
+                              rdhx8SZ0yy4ObIRzIzvBFLiSS8o= )
+
+
+
+
+Arends, et al.              Standards Track                    [Page 42]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+B.2.  Name Error
+
+   An authoritative name error.  The NSEC RRs prove that the name does
+   not exist and that no covering wildcard exists.
+
+   ;; Header: QR AA DO RCODE=3
+   ;;
+   ;; Question
+   ml.example.         IN A
+
+   ;; Answer
+   ;; (empty)
+
+   ;; Authority
+   example.       3600 IN SOA ns1.example. bugs.x.w.example. (
+                              1081539377
+                              3600
+                              300
+                              3600000
+                              3600
+                              )
+   example.       3600 RRSIG  SOA 5 1 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h
+                              7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF
+                              vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW
+                              DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB
+                              jV7j86HyQgM5e7+miRAz8V01b0I= )
+   b.example.     3600 NSEC   ns1.example. NS RRSIG NSEC
+   b.example.     3600 RRSIG  NSEC 5 2 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              GNuxHn844wfmUhPzGWKJCPY5ttEX/RfjDoOx
+                              9ueK1PtYkOWKOOdiJ/PJKCYB3hYX+858dDWS
+                              xb2qnV/LSTCNVBnkm6owOpysY97MVj5VQEWs
+                              0lm9tFoqjcptQkmQKYPrwUnCSNwvvclSF1xZ
+                              vhRXgWT7OuFXldoCG6TfVFMs9xE= )
+   example.       3600 NSEC   a.example. NS SOA MX RRSIG NSEC DNSKEY
+   example.       3600 RRSIG  NSEC 5 1 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              O0k558jHhyrC97ISHnislm4kLMW48C7U7cBm
+                              FTfhke5iVqNRVTB1STLMpgpbDIC9hcryoO0V
+                              Z9ME5xPzUEhbvGnHd5sfzgFVeGxr5Nyyq4tW
+                              SDBgIBiLQUv1ivy29vhXy7WgR62dPrZ0PWvm
+                              jfFJ5arXf4nPxp/kEowGgBRzY/U= )
+
+   ;; Additional
+   ;; (empty)
+
+
+
+
+Arends, et al.              Standards Track                    [Page 43]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+B.3.  No Data Error
+
+   A "no data" response.  The NSEC RR proves that the name exists and
+   that the requested RR type does not.
+
+   ;; Header: QR AA DO RCODE=0
+   ;;
+   ;; Question
+   ns1.example.        IN MX
+
+   ;; Answer
+   ;; (empty)
+
+   ;; Authority
+   example.       3600 IN SOA ns1.example. bugs.x.w.example. (
+                              1081539377
+                              3600
+                              300
+                              3600000
+                              3600
+                              )
+   example.       3600 RRSIG  SOA 5 1 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h
+                              7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF
+                              vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW
+                              DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB
+                              jV7j86HyQgM5e7+miRAz8V01b0I= )
+   ns1.example.   3600 NSEC   ns2.example. A RRSIG NSEC
+   ns1.example.   3600 RRSIG  NSEC 5 2 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              I4hj+Kt6+8rCcHcUdolks2S+Wzri9h3fHas8
+                              1rGN/eILdJHN7JpV6lLGPIh/8fIBkfvdyWnB
+                              jjf1q3O7JgYO1UdI7FvBNWqaaEPJK3UkddBq
+                              ZIaLi8Qr2XHkjq38BeQsbp8X0+6h4ETWSGT8
+                              IZaIGBLryQWGLw6Y6X8dqhlnxJM= )
+
+   ;; Additional
+   ;; (empty)
+
+B.4.  Referral to Signed Zone
+
+   Referral to a signed zone.  The DS RR contains the data which the
+   resolver will need to validate the corresponding DNSKEY RR in the
+   child zone's apex.
+
+   ;; Header: QR DO RCODE=0
+   ;;
+
+
+
+Arends, et al.              Standards Track                    [Page 44]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+   ;; Question
+   mc.a.example.       IN MX
+
+   ;; Answer
+   ;; (empty)
+
+   ;; Authority
+   a.example.     3600 IN NS  ns1.a.example.
+   a.example.     3600 IN NS  ns2.a.example.
+   a.example.     3600 DS     57855 5 1 (
+                              B6DCD485719ADCA18E5F3D48A2331627FDD3
+                              636B )
+   a.example.     3600 RRSIG  DS 5 2 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              oXIKit/QtdG64J/CB+Gi8dOvnwRvqrto1AdQ
+                              oRkAN15FP3iZ7suB7gvTBmXzCjL7XUgQVcoH
+                              kdhyCuzp8W9qJHgRUSwKKkczSyuL64nhgjuD
+                              EML8l9wlWVsl7PR2VnZduM9bLyBhaaPmRKX/
+                              Fm+v6ccF2EGNLRiY08kdkz+XHHo= )
+
+   ;; Additional
+   ns1.a.example. 3600 IN A   192.0.2.5
+   ns2.a.example. 3600 IN A   192.0.2.6
+
+B.5.  Referral to Unsigned Zone
+
+   Referral to an unsigned zone.  The NSEC RR proves that no DS RR for
+   this delegation exists in the parent zone.
+
+   ;; Header: QR DO RCODE=0
+   ;;
+   ;; Question
+   mc.b.example.       IN MX
+
+   ;; Answer
+   ;; (empty)
+
+   ;; Authority
+   b.example.     3600 IN NS  ns1.b.example.
+   b.example.     3600 IN NS  ns2.b.example.
+   b.example.     3600 NSEC   ns1.example. NS RRSIG NSEC
+   b.example.     3600 RRSIG  NSEC 5 2 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              GNuxHn844wfmUhPzGWKJCPY5ttEX/RfjDoOx
+                              9ueK1PtYkOWKOOdiJ/PJKCYB3hYX+858dDWS
+                              xb2qnV/LSTCNVBnkm6owOpysY97MVj5VQEWs
+                              0lm9tFoqjcptQkmQKYPrwUnCSNwvvclSF1xZ
+                              vhRXgWT7OuFXldoCG6TfVFMs9xE= )
+
+
+
+Arends, et al.              Standards Track                    [Page 45]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+   ;; Additional
+   ns1.b.example. 3600 IN A   192.0.2.7
+   ns2.b.example. 3600 IN A   192.0.2.8
+
+B.6.  Wildcard Expansion
+
+   A successful query that was answered via wildcard expansion.  The
+   label count in the answer's RRSIG RR indicates that a wildcard RRset
+   was expanded to produce this response, and the NSEC RR proves that no
+   closer match exists in the zone.
+
+   ;; Header: QR AA DO RCODE=0
+   ;;
+   ;; Question
+   a.z.w.example.      IN MX
+
+   ;; Answer
+   a.z.w.example. 3600 IN MX  1 ai.example.
+   a.z.w.example. 3600 RRSIG  MX 5 2 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              OMK8rAZlepfzLWW75Dxd63jy2wswESzxDKG2
+                              f9AMN1CytCd10cYISAxfAdvXSZ7xujKAtPbc
+                              tvOQ2ofO7AZJ+d01EeeQTVBPq4/6KCWhqe2X
+                              TjnkVLNvvhnc0u28aoSsG0+4InvkkOHknKxw
+                              4kX18MMR34i8lC36SR5xBni8vHI= )
+
+   ;; Authority
+   example.       3600 NS     ns1.example.
+   example.       3600 NS     ns2.example.
+   example.       3600 RRSIG  NS 5 1 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              gl13F00f2U0R+SWiXXLHwsMY+qStYy5k6zfd
+                              EuivWc+wd1fmbNCyql0Tk7lHTX6UOxc8AgNf
+                              4ISFve8XqF4q+o9qlnqIzmppU3LiNeKT4FZ8
+                              RO5urFOvoMRTbQxW3U0hXWuggE4g3ZpsHv48
+                              0HjMeRaZB/FRPGfJPajngcq6Kwg= )
+   x.y.w.example. 3600 NSEC   xx.example. MX RRSIG NSEC
+   x.y.w.example. 3600 RRSIG  NSEC 5 4 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              OvE6WUzN2ziieJcvKPWbCAyXyP6ef8cr6Csp
+                              ArVSTzKSquNwbezZmkU7E34o5lmb6CWSSSpg
+                              xw098kNUFnHcQf/LzY2zqRomubrNQhJTiDTX
+                              a0ArunJQCzPjOYq5t0SLjm6qp6McJI1AP5Vr
+                              QoKqJDCLnoAlcPOPKAm/jJkn3jk= )
+
+   ;; Additional
+   ai.example.    3600 IN A   192.0.2.9
+   ai.example.    3600 RRSIG  A 5 2 3600 20040509183619 (
+
+
+
+Arends, et al.              Standards Track                    [Page 46]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+                              20040409183619 38519 example.
+                              pAOtzLP2MU0tDJUwHOKE5FPIIHmdYsCgTb5B
+                              ERGgpnJluA9ixOyf6xxVCgrEJW0WNZSsJicd
+                              hBHXfDmAGKUajUUlYSAH8tS4ZnrhyymIvk3u
+                              ArDu2wfT130e9UHnumaHHMpUTosKe22PblOy
+                              6zrTpg9FkS0XGVmYRvOTNYx2HvQ= )
+   ai.example.    3600 AAAA   2001:db8::f00:baa9
+   ai.example.    3600 RRSIG  AAAA 5 2 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              nLcpFuXdT35AcE+EoafOUkl69KB+/e56XmFK
+                              kewXG2IadYLKAOBIoR5+VoQV3XgTcofTJNsh
+                              1rnF6Eav2zpZB3byI6yo2bwY8MNkr4A7cL9T
+                              cMmDwV/hWFKsbGBsj8xSCN/caEL2CWY/5XP2
+                              sZM6QjBBLmukH30+w1z3h8PUP2o= )
+
+B.7.  Wildcard No Data Error
+
+   A "no data" response for a name covered by a wildcard.  The NSEC RRs
+   prove that the matching wildcard name does not have any RRs of the
+   requested type and that no closer match exists in the zone.
+
+   ;; Header: QR AA DO RCODE=0
+   ;;
+   ;; Question
+   a.z.w.example.      IN AAAA
+
+   ;; Answer
+   ;; (empty)
+
+   ;; Authority
+   example.       3600 IN SOA ns1.example. bugs.x.w.example. (
+                              1081539377
+                              3600
+                              300
+                              3600000
+                              3600
+                              )
+   example.       3600 RRSIG  SOA 5 1 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h
+                              7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF
+                              vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW
+                              DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB
+                              jV7j86HyQgM5e7+miRAz8V01b0I= )
+   x.y.w.example. 3600 NSEC   xx.example. MX RRSIG NSEC
+   x.y.w.example. 3600 RRSIG  NSEC 5 4 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              OvE6WUzN2ziieJcvKPWbCAyXyP6ef8cr6Csp
+
+
+
+Arends, et al.              Standards Track                    [Page 47]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+                              ArVSTzKSquNwbezZmkU7E34o5lmb6CWSSSpg
+                              xw098kNUFnHcQf/LzY2zqRomubrNQhJTiDTX
+                              a0ArunJQCzPjOYq5t0SLjm6qp6McJI1AP5Vr
+                              QoKqJDCLnoAlcPOPKAm/jJkn3jk= )
+   *.w.example.   3600 NSEC   x.w.example. MX RRSIG NSEC
+   *.w.example.   3600 RRSIG  NSEC 5 2 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              r/mZnRC3I/VIcrelgIcteSxDhtsdlTDt8ng9
+                              HSBlABOlzLxQtfgTnn8f+aOwJIAFe1Ee5RvU
+                              5cVhQJNP5XpXMJHfyps8tVvfxSAXfahpYqtx
+                              91gsmcV/1V9/bZAG55CefP9cM4Z9Y9NT9XQ8
+                              s1InQ2UoIv6tJEaaKkP701j8OLA= )
+
+   ;; Additional
+   ;; (empty)
+
+B.8.  DS Child Zone No Data Error
+
+   A "no data" response for a QTYPE=DS query that was mistakenly sent to
+   a name server for the child zone.
+
+   ;; Header: QR AA DO RCODE=0
+   ;;
+   ;; Question
+   example.            IN DS
+
+   ;; Answer
+   ;; (empty)
+
+   ;; Authority
+   example.       3600 IN SOA ns1.example. bugs.x.w.example. (
+                              1081539377
+                              3600
+                              300
+                              3600000
+                              3600
+                              )
+   example.       3600 RRSIG  SOA 5 1 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h
+                              7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF
+                              vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW
+                              DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB
+                              jV7j86HyQgM5e7+miRAz8V01b0I= )
+   example.       3600 NSEC   a.example. NS SOA MX RRSIG NSEC DNSKEY
+   example.       3600 RRSIG  NSEC 5 1 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              O0k558jHhyrC97ISHnislm4kLMW48C7U7cBm
+
+
+
+Arends, et al.              Standards Track                    [Page 48]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+                              FTfhke5iVqNRVTB1STLMpgpbDIC9hcryoO0V
+                              Z9ME5xPzUEhbvGnHd5sfzgFVeGxr5Nyyq4tW
+                              SDBgIBiLQUv1ivy29vhXy7WgR62dPrZ0PWvm
+                              jfFJ5arXf4nPxp/kEowGgBRzY/U= )
+
+   ;; Additional
+   ;; (empty)
+
+Appendix C.  Authentication Examples
+
+   The examples in this section show how the response messages in
+   Appendix B are authenticated.
+
+C.1.  Authenticating an Answer
+
+   The query in Appendix B.1 returned an MX RRset for "x.w.example.com".
+   The corresponding RRSIG indicates that the MX RRset was signed by an
+   "example" DNSKEY with algorithm 5 and key tag 38519.  The resolver
+   needs the corresponding DNSKEY RR in order to authenticate this
+   answer.  The discussion below describes how a resolver might obtain
+   this DNSKEY RR.
+
+   The RRSIG indicates the original TTL of the MX RRset was 3600, and,
+   for the purpose of authentication, the current TTL is replaced by
+   3600.  The RRSIG labels field value of 3 indicates that the answer
+   was not the result of wildcard expansion.  The "x.w.example.com" MX
+   RRset is placed in canonical form, and, assuming the current time
+   falls between the signature inception and expiration dates, the
+   signature is authenticated.
+
+C.1.1.  Authenticating the Example DNSKEY RR
+
+   This example shows the logical authentication process that starts
+   from the a configured root DNSKEY (or DS RR) and moves down the tree
+   to authenticate the desired "example" DNSKEY RR.  Note that the
+   logical order is presented for clarity.  An implementation may choose
+   to construct the authentication as referrals are received or to
+   construct the authentication chain only after all RRsets have been
+   obtained, or in any other combination it sees fit.  The example here
+   demonstrates only the logical process and does not dictate any
+   implementation rules.
+
+   We assume the resolver starts with a configured DNSKEY RR for the
+   root zone (or a configured DS RR for the root zone).  The resolver
+   checks whether this configured DNSKEY RR is present in the root
+   DNSKEY RRset (or whether the DS RR matches some DNSKEY in the root
+   DNSKEY RRset), whether this DNSKEY RR has signed the root DNSKEY
+   RRset, and whether the signature lifetime is valid.  If all these
+
+
+
+Arends, et al.              Standards Track                    [Page 49]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+   conditions are met, all keys in the DNSKEY RRset are considered
+   authenticated.  The resolver then uses one (or more) of the root
+   DNSKEY RRs to authenticate the "example" DS RRset.  Note that the
+   resolver may have to query the root zone to obtain the root DNSKEY
+   RRset or "example" DS RRset.
+
+   Once the DS RRset has been authenticated using the root DNSKEY, the
+   resolver checks the "example" DNSKEY RRset for some "example" DNSKEY
+   RR that matches one of the authenticated "example" DS RRs.  If such a
+   matching "example" DNSKEY is found, the resolver checks whether this
+   DNSKEY RR has signed the "example" DNSKEY RRset and the signature
+   lifetime is valid.  If these conditions are met, all keys in the
+   "example" DNSKEY RRset are considered authenticated.
+
+   Finally, the resolver checks that some DNSKEY RR in the "example"
+   DNSKEY RRset uses algorithm 5 and has a key tag of 38519.  This
+   DNSKEY is used to authenticate the RRSIG included in the response.
+   If multiple "example" DNSKEY RRs match this algorithm and key tag,
+   then each DNSKEY RR is tried, and the answer is authenticated if any
+   of the matching DNSKEY RRs validate the signature as described above.
+
+C.2.  Name Error
+
+   The query in Appendix B.2 returned NSEC RRs that prove that the
+   requested data does not exist and no wildcard applies.  The negative
+   reply is authenticated by verifying both NSEC RRs.  The NSEC RRs are
+   authenticated in a manner identical to that of the MX RRset discussed
+   above.
+
+C.3.  No Data Error
+
+   The query in Appendix B.3 returned an NSEC RR that proves that the
+   requested name exists, but the requested RR type does not exist.  The
+   negative reply is authenticated by verifying the NSEC RR.  The NSEC
+   RR is authenticated in a manner identical to that of the MX RRset
+   discussed above.
+
+C.4.  Referral to Signed Zone
+
+   The query in Appendix B.4 returned a referral to the signed
+   "a.example." zone.  The DS RR is authenticated in a manner identical
+   to that of the MX RRset discussed above.  This DS RR is used to
+   authenticate the "a.example" DNSKEY RRset.
+
+   Once the "a.example" DS RRset has been authenticated using the
+   "example" DNSKEY, the resolver checks the "a.example" DNSKEY RRset
+   for some "a.example" DNSKEY RR that matches the DS RR.  If such a
+   matching "a.example" DNSKEY is found, the resolver checks whether
+
+
+
+Arends, et al.              Standards Track                    [Page 50]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+   this DNSKEY RR has signed the "a.example" DNSKEY RRset and whether
+   the signature lifetime is valid.  If all these conditions are met,
+   all keys in the "a.example" DNSKEY RRset are considered
+   authenticated.
+
+C.5.  Referral to Unsigned Zone
+
+   The query in Appendix B.5 returned a referral to an unsigned
+   "b.example." zone.  The NSEC proves that no authentication leads from
+   "example" to "b.example", and the NSEC RR is authenticated in a
+   manner identical to that of the MX RRset discussed above.
+
+C.6.  Wildcard Expansion
+
+   The query in Appendix B.6 returned an answer that was produced as a
+   result of wildcard expansion.  The answer section contains a wildcard
+   RRset expanded as it would be in a traditional DNS response, and the
+   corresponding RRSIG indicates that the expanded wildcard MX RRset was
+   signed by an "example" DNSKEY with algorithm 5 and key tag 38519.
+   The RRSIG indicates that the original TTL of the MX RRset was 3600,
+   and, for the purpose of authentication, the current TTL is replaced
+   by 3600.  The RRSIG labels field value of 2 indicates that the answer
+   is the result of wildcard expansion, as the "a.z.w.example" name
+   contains 4 labels.  The name "a.z.w.w.example" is replaced by
+   "*.w.example", the MX RRset is placed in canonical form, and,
+   assuming that the current time falls between the signature inception
+   and expiration dates, the signature is authenticated.
+
+   The NSEC proves that no closer match (exact or closer wildcard) could
+   have been used to answer this query, and the NSEC RR must also be
+   authenticated before the answer is considered valid.
+
+C.7.  Wildcard No Data Error
+
+   The query in Appendix B.7 returned NSEC RRs that prove that the
+   requested data does not exist and no wildcard applies.  The negative
+   reply is authenticated by verifying both NSEC RRs.
+
+C.8.  DS Child Zone No Data Error
+
+   The query in Appendix B.8 returned NSEC RRs that shows the requested
+   was answered by a child server ("example" server).  The NSEC RR
+   indicates the presence of an SOA RR, showing that the answer is from
+   the child .  Queries for the "example" DS RRset should be sent to the
+   parent servers ("root" servers).
+
+
+
+
+
+
+Arends, et al.              Standards Track                    [Page 51]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+Authors' Addresses
+
+   Roy Arends
+   Telematica Instituut
+   Brouwerijstraat 1
+   7523 XC  Enschede
+   NL
+
+   EMail: roy.arends@telin.nl
+
+
+   Rob Austein
+   Internet Systems Consortium
+   950 Charter Street
+   Redwood City, CA  94063
+   USA
+
+   EMail: sra@isc.org
+
+
+   Matt Larson
+   VeriSign, Inc.
+   21345 Ridgetop Circle
+   Dulles, VA  20166-6503
+   USA
+
+   EMail: mlarson@verisign.com
+
+
+   Dan Massey
+   Colorado State University
+   Department of Computer Science
+   Fort Collins, CO 80523-1873
+
+   EMail: massey@cs.colostate.edu
+
+
+   Scott Rose
+   National Institute for Standards and Technology
+   100 Bureau Drive
+   Gaithersburg, MD  20899-8920
+   USA
+
+   EMail: scott.rose@nist.gov
+
+
+
+
+
+
+
+Arends, et al.              Standards Track                    [Page 52]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2005).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at ietf-
+   ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+Arends, et al.              Standards Track                    [Page 53]
+
diff --git a/doc/rfc/rfc4074.txt b/doc/rfc/rfc4074.txt
new file mode 100644
index 0000000..d9252b3
--- /dev/null
+++ b/doc/rfc/rfc4074.txt
@@ -0,0 +1,339 @@
+
+
+
+
+
+
+Network Working Group                                       Y. Morishita
+Request for Comments: 4074                                          JPRS
+Category: Informational                                        T. Jinmei
+                                                                 Toshiba
+                                                                May 2005
+
+
+       Common Misbehavior Against DNS Queries for IPv6 Addresses
+
+Status of This Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).
+
+Abstract
+
+   There is some known misbehavior of DNS authoritative servers when
+   they are queried for AAAA resource records.  Such behavior can block
+   IPv4 communication that should actually be available, cause a
+   significant delay in name resolution, or even make a denial of
+   service attack.  This memo describes details of known cases and
+   discusses their effects.
+
+1.  Introduction
+
+   Many existing DNS clients (resolvers) that support IPv6 first search
+   for AAAA Resource Records (RRs) of a target host name, and then for A
+   RRs of the same name.  This fallback mechanism is based on the DNS
+   specifications, which if not obeyed by authoritative servers, can
+   produce unpleasant results.  In some cases, for example, a web
+   browser fails to connect to a web server it could otherwise reach.
+   In the following sections, this memo describes some typical cases of
+   such misbehavior and its (bad) effects.
+
+   Note that the misbehavior is not specific to AAAA RRs.  In fact, all
+   known examples also apply to the cases of queries for MX, NS, and SOA
+   RRs.  The authors believe this can be generalized for all types of
+   queries other than those for A RRs.  In this memo, however, we
+   concentrate on the case for AAAA queries, since the problem is
+   particularly severe for resolvers that support IPv6, which thus
+   affects many end users.  Resolvers at end users normally send A
+   and/or AAAA queries only, so the problem for the other cases is
+   relatively minor.
+
+
+
+Morishita & Jinmei           Informational                      [Page 1]
+
+RFC 4074         Common Misbehavior Against DNS Queries         May 2005
+
+
+2.  Network Model
+
+   In this memo, we assume a typical network model of name resolution
+   environment using DNS.  It consists of three components: stub
+   resolvers, caching servers, and authoritative servers.  A stub
+   resolver issues a recursive query to a caching server, which then
+   handles the entire name resolution procedure recursively.  The
+   caching server caches the result of the query and sends the result to
+   the stub resolver.  The authoritative servers respond to queries for
+   names for which they have the authority, normally in a non-recursive
+   manner.
+
+3.  Expected Behavior
+
+   Suppose that an authoritative server has an A RR but has no AAAA RR
+   for a host name.  Then, the server should return a response to a
+   query for an AAAA RR of the name with the response code (RCODE) being
+   0 (indicating no error) and with an empty answer section (see
+   Sections 4.3.2 and 6.2.4 of [1]).  Such a response indicates that
+   there is at least one RR of a different type than AAAA for the
+   queried name, and the stub resolver can then look for A RRs.
+
+   This way, the caching server can cache the fact that the queried name
+   has no AAAA RR (but may have other types of RRs), and thus improve
+   the response time to further queries for an AAAA RR of the name.
+
+4.  Problematic Behaviors
+
+   There are some known cases at authoritative servers that do not
+   conform to the expected behavior.  This section describes those
+   problematic cases.
+
+4.1.  Ignore Queries for AAAA
+
+   Some authoritative servers seem to ignore queries for an AAAA RR,
+   causing a delay at the stub resolver to fall back to a query for an A
+   RR.  This behavior may cause a fatal timeout at the resolver or at
+   the application that calls the resolver.  Even if the resolver
+   eventually falls back, the result can be an unacceptable delay for
+   the application user, especially with interactive applications like
+   web browsing.
+
+4.2.  Return "Name Error"
+
+   This type of server returns a response with RCODE 3 ("Name Error") to
+   a query for an AAAA RR, indicating that it does not have any RRs of
+   any type for the queried name.
+
+
+
+
+Morishita & Jinmei           Informational                      [Page 2]
+
+RFC 4074         Common Misbehavior Against DNS Queries         May 2005
+
+
+   With this response, the stub resolver may immediately give up and
+   never fall back.  Even if the resolver retries with a query for an A
+   RR, the negative response for the name has been cached in the caching
+   server, and the caching server will simply return the negative
+   response.  As a result, the stub resolver considers this to be a
+   fatal error in name resolution.
+
+   Several examples of this behavior are known to the authors.  As of
+   this writing, all have been fixed.
+
+4.3.  Return Other Erroneous Codes
+
+   Other authoritative servers return a response with erroneous response
+   codes other than RCODE 3 ("Name Error").  One such RCODE is 4 ("Not
+   Implemented"), indicating that the servers do not support the
+   requested type of query.
+
+   These cases are less harmful than the previous one; if the stub
+   resolver falls back to querying for an A RR, the caching server will
+   process the query correctly and return an appropriate response.
+
+   However, these can still cause a serious effect.  There was an
+   authoritative server implementation that returned RCODE 2 ("Server
+   failure") to queries for AAAA RRs.  One widely deployed mail server
+   implementation with a certain type of resolver library interpreted
+   this result as an indication of retry and did not fall back to
+   queries for A RRs, causing message delivery failure.
+
+   If the caching server receives a response with these response codes,
+   it does not cache the fact that the queried name has no AAAA RR,
+   resulting in redundant queries for AAAA RRs in the future.  The
+   behavior will waste network bandwidth and increase the load of the
+   authoritative server.
+
+   Using RCODE 1 ("Format error") would cause a similar effect, though
+   the authors have not seen such implementations yet.
+
+4.4.  Return a Broken Response
+
+   Another type of authoritative servers returns broken responses to
+   AAAA queries.  Returning a response whose RR type is AAAA with the
+   length of the RDATA being 4 bytes is a known behavior of this
+   category.  The 4-byte data looks like the IPv4 address of the queried
+   host name.
+
+
+
+
+
+
+
+Morishita & Jinmei           Informational                      [Page 3]
+
+RFC 4074         Common Misbehavior Against DNS Queries         May 2005
+
+
+   That is, the RR in the answer section would be described as follows:
+
+     www.bad.example. 600 IN AAAA 192.0.2.1
+
+   which is, of course, bogus (or at least meaningless).
+
+   A widely deployed caching server implementation transparently returns
+   the broken response (and caches it) to the stub resolver.  Another
+   known server implementation parses the response by itself, and sends
+   a separate response with RCODE 2 ("Server failure").
+
+   In either case, the broken response does not affect queries for an A
+   RR of the same name.  If the stub resolver falls back to A queries,
+   it will get an appropriate response.
+
+   The latter case, however, causes the same bad effect as that
+   described in the previous section: redundant queries for AAAA RRs.
+
+4.5.  Make Lame Delegation
+
+   Some authoritative servers respond to AAAA queries in a way that
+   causes lame delegation.  In this case, the parent zone specifies that
+   the authoritative server should have the authority of a zone, but the
+   server should not return an authoritative response for AAAA queries
+   within the zone (i.e., the AA bit in the response is not set).  On
+   the other hand, the authoritative server returns an authoritative
+   response for A queries.
+
+   When a caching server asks the server for AAAA RRs in the zone, it
+   recognizes the delegation is lame, and returns a response with RCODE
+   2 ("Server failure") to the stub resolver.
+
+   Furthermore, some caching servers record the authoritative server as
+   lame for the zone and will not use it for a certain period of time.
+   With this type of caching server, even if the stub resolver falls
+   back to querying for an A RR, the caching server will simply return a
+   response with RCODE 2, since all the servers are known to be "lame."
+
+   There is also an implementation that relaxes the behavior a little
+   bit.  It tries to avoid using the lame server, but continues to try
+   it as a last resort.  With this type of caching server, the stub
+   resolver will get a correct response if it falls back after Server
+   failure.  However, this still causes redundant AAAA queries, as
+   explained in the previous sections.
+
+
+
+
+
+
+
+Morishita & Jinmei           Informational                      [Page 4]
+
+RFC 4074         Common Misbehavior Against DNS Queries         May 2005
+
+
+5.  Security Considerations
+
+   The CERT/CC pointed out that the response with RCODE 3 ("Name
+   Error"), described in Section 4.2, can be used for a denial of
+   service attack [2].  The same argument applies to the case of "lame
+   delegation", described in Section 4.5, with a certain type of caching
+   server.
+
+6.  Acknowledgements
+
+   Erik Nordmark encouraged the authors to publish this document as an
+   RFC.  Akira Kato and Paul Vixie reviewed a preliminary version of
+   this document.  Pekka Savola carefully reviewed a previous version
+   and provided detailed comments.  Bill Fenner, Scott Hollenbeck,
+   Thomas Narten, and Alex Zinin reviewed and helped improve the
+   document at the last stage for publication.
+
+7.  Informative References
+
+   [1]  Mockapetris, P., "Domain names - concepts and facilities", STD
+        13, RFC 1034, November 1987.
+
+   [2]  The CERT Coordination Center, "Incorrect NXDOMAIN responses from
+        AAAA queries could cause denial-of-service conditions",
+        March 2003, <http://www.kb.cert.org/vuls/id/714121>.
+
+Authors' Addresses
+
+   MORISHITA Orange Yasuhiro
+   Research and Development Department, Japan Registry Services Co.,Ltd.
+   Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda
+   Chiyoda-ku, Tokyo  101-0065
+   Japan
+
+   EMail: yasuhiro@jprs.co.jp
+
+
+   JINMEI Tatuya
+   Corporate Research & Development Center, Toshiba Corporation
+   1 Komukai Toshiba-cho, Saiwai-ku
+   Kawasaki-shi, Kanagawa  212-8582
+   Japan
+
+   EMail: jinmei@isl.rdc.toshiba.co.jp
+
+
+
+
+
+
+
+Morishita & Jinmei           Informational                      [Page 5]
+
+RFC 4074         Common Misbehavior Against DNS Queries         May 2005
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2005).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at ietf-
+   ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+Morishita & Jinmei           Informational                      [Page 6]
+
diff --git a/doc/rfc/rfc4159.txt b/doc/rfc/rfc4159.txt
new file mode 100644
index 0000000..1ab4bd1
--- /dev/null
+++ b/doc/rfc/rfc4159.txt
@@ -0,0 +1,171 @@
+
+
+
+
+
+
+Network Working Group                                          G. Huston
+Request for Comments: 4159                                         APNIC
+BCP: 109                                                     August 2005
+Category: Best Current Practice
+
+
+                        Deprecation of "ip6.int"
+
+Status of This Memo
+
+   This document specifies an Internet Best Current Practices for the
+   Internet Community, and requests discussion and suggestions for
+   improvements.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).
+
+Abstract
+
+   This document advises of the deprecation of the use of "ip6.int" for
+   Standards Conformant IPv6 implementations.
+
+1.  IPv6 Standards Action
+
+   In August 2001 the IETF published [RFC3152], which advised that the
+   use of "ip6.int" as the domain for reverse-mapping of IPv6 addresses
+   to DNS names was deprecated.  The document noted that the use of
+   "ip6.int" would be phased out in an orderly fashion.
+
+   As of 1 September 2005, the IETF advises the community that the DNS
+   domain "ip6.int" should no longer be used to perform reverse mapping
+   of IPv6 addresses to domain names, and that the domain "ip6.arpa"
+   should be used henceforth, in accordance with the IANA Considerations
+   described in [RFC3596].  The domain "ip6.int" is deprecated, and its
+   use in IPv6 implementations that conform to the IPv6 Internet
+   Standards is discontinued.
+
+   The Regional Internet Registries (RIRs) are advised that maintenance
+   of delegation of entries in "ip6.int" is no longer required as part
+   of infrastructure services in support of Internet Standards
+   Conformant IPv6 implementations as of 1 September 2005.  The RIRs are
+   requested to work with their communities to adopt a schedule
+   regarding the cessation of support of registration services for the
+   "ip6.int" domain.
+
+
+
+
+
+
+Huston                   Best Current Practice                  [Page 1]
+
+RFC 4159                        ip6.int                      August 2005
+
+
+2.  IANA Considerations
+
+   IANA is advised that the "ip6.int" domain for reverse mapping of IPv6
+   addresses to domain names is no longer part of Internet Standards
+   Conformant support of IPv6 as of 1 September 2005.
+
+3.  Security Considerations
+
+   While DNS spoofing of address to name mapping has been exploited in
+   IPv4, removal of the "ip6.int" zone from the standard IPv6
+   specification creates no new threats to the security of the internet.
+
+4.  Acknowledgements
+
+   The document was prepared with the assistance of Kurt Lindqvist,
+   Thomas Narten, Paul Wilson, David Kessens, Bob Hinden, Brian
+   Haberman, and Bill Manning.
+
+5.  Normative References
+
+   [RFC3152] Bush, R., "Delegation of IP6.ARPA", BCP 49, RFC 3152,
+             August 2001.
+
+   [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, "DNS
+             Extensions to Support IP Version 6", RFC 3596, October
+             2003.
+
+Author's Address
+
+   Geoff Huston
+   APNIC
+
+   EMail: gih@apnic.net
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Huston                   Best Current Practice                  [Page 2]
+
+RFC 4159                        ip6.int                      August 2005
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2005).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at ietf-
+   ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+Huston                   Best Current Practice                  [Page 3]
+
diff --git a/doc/rfc/rfc4193.txt b/doc/rfc/rfc4193.txt
new file mode 100644
index 0000000..17e2c0b
--- /dev/null
+++ b/doc/rfc/rfc4193.txt
@@ -0,0 +1,899 @@
+
+
+
+
+
+
+Network Working Group                                          R. Hinden
+Request for Comments: 4193                                         Nokia
+Category: Standards Track                                    B. Haberman
+                                                                 JHU-APL
+                                                            October 2005
+
+
+                  Unique Local IPv6 Unicast Addresses
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).
+
+Abstract
+
+   This document defines an IPv6 unicast address format that is globally
+   unique and is intended for local communications, usually inside of a
+   site.  These addresses are not expected to be routable on the global
+   Internet.
+
+Table of Contents
+
+   1. Introduction ....................................................2
+   2. Acknowledgements ................................................3
+   3. Local IPv6 Unicast Addresses ....................................3
+      3.1. Format .....................................................3
+           3.1.1. Background ..........................................4
+      3.2. Global ID ..................................................4
+           3.2.1. Locally Assigned Global IDs .........................5
+           3.2.2. Sample Code for Pseudo-Random Global ID Algorithm ...5
+           3.2.3. Analysis of the Uniqueness of Global IDs ............6
+      3.3. Scope Definition ...........................................6
+   4. Operational Guidelines ..........................................7
+      4.1. Routing ....................................................7
+      4.2. Renumbering and Site Merging ...............................7
+      4.3. Site Border Router and Firewall Packet Filtering ...........8
+      4.4. DNS Issues .................................................8
+      4.5. Application and Higher Level Protocol Issues ...............9
+      4.6. Use of Local IPv6 Addresses for Local Communication ........9
+      4.7. Use of Local IPv6 Addresses with VPNs .....................10
+
+
+
+Hinden & Haberman           Standards Track                     [Page 1]
+
+RFC 4193          Unique Local IPv6 Unicast Addresses       October 2005
+
+
+   5. Global Routing Considerations ..................................11
+      5.1. From the Standpoint of the Internet .......................11
+      5.2. From the Standpoint of a Site .............................11
+   6. Advantages and Disadvantages ...................................12
+      6.1. Advantages ................................................12
+      6.2. Disadvantages .............................................13
+   7. Security Considerations ........................................13
+   8. IANA Considerations ............................................13
+   9. References .....................................................13
+      9.1. Normative References ......................................13
+      9.2. Informative References ....................................14
+
+1.  Introduction
+
+   This document defines an IPv6 unicast address format that is globally
+   unique and is intended for local communications [IPV6].  These
+   addresses are called Unique Local IPv6 Unicast Addresses and are
+   abbreviated in this document as Local IPv6 addresses.  They are not
+   expected to be routable on the global Internet.  They are routable
+   inside of a more limited area such as a site.  They may also be
+   routed between a limited set of sites.
+
+   Local IPv6 unicast addresses have the following characteristics:
+
+      - Globally unique prefix (with high probability of uniqueness).
+
+      - Well-known prefix to allow for easy filtering at site
+        boundaries.
+
+      - Allow sites to be combined or privately interconnected without
+        creating any address conflicts or requiring renumbering of
+        interfaces that use these prefixes.
+
+      - Internet Service Provider independent and can be used for
+        communications inside of a site without having any permanent or
+        intermittent Internet connectivity.
+
+      - If accidentally leaked outside of a site via routing or DNS,
+        there is no conflict with any other addresses.
+
+      - In practice, applications may treat these addresses like global
+        scoped addresses.
+
+   This document defines the format of Local IPv6 addresses, how to
+   allocate them, and usage considerations including routing, site
+   border routers, DNS, application support, VPN usage, and guidelines
+   for how to use for local communication inside a site.
+
+
+
+
+Hinden & Haberman           Standards Track                     [Page 2]
+
+RFC 4193          Unique Local IPv6 Unicast Addresses       October 2005
+
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC2119].
+
+2.  Acknowledgements
+
+   The underlying idea of creating Local IPv6 addresses described in
+   this document has been proposed a number of times by a variety of
+   people.  The authors of this document do not claim exclusive credit.
+   Credit goes to Brian Carpenter, Christian Huitema, Aidan Williams,
+   Andrew White, Charlie Perkins, and many others.  The authors would
+   also like to thank Brian Carpenter, Charlie Perkins, Harald
+   Alvestrand, Keith Moore, Margaret Wasserman, Shannon Behrens, Alan
+   Beard, Hans Kruse, Geoff Huston, Pekka Savola, Christian Huitema, Tim
+   Chown, Steve Bellovin, Alex Zinin, Tony Hain, Bill Fenner, Sam
+   Hartman, and Elwyn Davies for their comments and suggestions on this
+   document.
+
+3.  Local IPv6 Unicast Addresses
+
+3.1.  Format
+
+   The Local IPv6 addresses are created using a pseudo-randomly
+   allocated global ID.  They have the following format:
+
+      | 7 bits |1|  40 bits   |  16 bits  |          64 bits           |
+      +--------+-+------------+-----------+----------------------------+
+      | Prefix |L| Global ID  | Subnet ID |        Interface ID        |
+      +--------+-+------------+-----------+----------------------------+
+
+   Where:
+
+      Prefix            FC00::/7 prefix to identify Local IPv6 unicast
+                        addresses.
+
+      L                 Set to 1 if the prefix is locally assigned.
+                        Set to 0 may be defined in the future.  See
+                        Section 3.2 for additional information.
+
+      Global ID         40-bit global identifier used to create a
+                        globally unique prefix.  See Section 3.2 for
+                        additional information.
+
+      Subnet ID         16-bit Subnet ID is an identifier of a subnet
+                        within the site.
+
+      Interface ID      64-bit Interface ID as defined in [ADDARCH].
+
+
+
+
+Hinden & Haberman           Standards Track                     [Page 3]
+
+RFC 4193          Unique Local IPv6 Unicast Addresses       October 2005
+
+
+3.1.1.  Background
+
+   There were a range of choices available when choosing the size of the
+   prefix and Global ID field length.  There is a direct tradeoff
+   between having a Global ID field large enough to support foreseeable
+   future growth and not using too much of the IPv6 address space
+   needlessly.  A reasonable way of evaluating a specific field length
+   is to compare it to a projected 2050 world population of 9.3 billion
+   [POPUL] and the number of resulting /48 prefixes per person.  A range
+   of prefix choices is shown in the following table:
+
+    Prefix  Global ID     Number of          Prefixes    % of IPv6
+            Length        /48 Prefixes       per Person  Address Space
+
+    /11       37           137,438,953,472     15         0.049%
+    /10       38           274,877,906,944     30         0.098%
+    /9        39           549,755,813,888     59         0.195%
+    /8        40         1,099,511,627,776    118         0.391%
+    /7        41         2,199,023,255,552    236         0.781%
+    /6        42         4,398,046,511,104    473         1.563%
+
+   A very high utilization ratio of these allocations can be assumed
+   because the Global ID field does not require internal structure, and
+   there is no reason to be able to aggregate the prefixes.
+
+   The authors believe that a /7 prefix resulting in a 41-bit Global ID
+   space (including the L bit) is a good choice.  It provides for a
+   large number of assignments (i.e., 2.2 trillion) and at the same time
+   uses less than .8% of the total IPv6 address space.  It is unlikely
+   that this space will be exhausted.  If more than this were to be
+   needed, then additional IPv6 address space could be allocated for
+   this purpose.
+
+3.2.  Global ID
+
+   The allocation of Global IDs is pseudo-random [RANDOM].  They MUST
+   NOT be assigned sequentially or with well-known numbers.  This is to
+   ensure that there is not any relationship between allocations and to
+   help clarify that these prefixes are not intended to be routed
+   globally.  Specifically, these prefixes are not designed to
+   aggregate.
+
+   This document defines a specific local method to allocate Global IDs,
+   indicated by setting the L bit to 1.  Another method, indicated by
+   clearing the L bit, may be defined later.  Apart from the allocation
+   method, all Local IPv6 addresses behave and are treated identically.
+
+
+
+
+
+Hinden & Haberman           Standards Track                     [Page 4]
+
+RFC 4193          Unique Local IPv6 Unicast Addresses       October 2005
+
+
+   The local assignments are self-generated and do not need any central
+   coordination or assignment, but have an extremely high probability of
+   being unique.
+
+3.2.1.  Locally Assigned Global IDs
+
+   Locally assigned Global IDs MUST be generated with a pseudo-random
+   algorithm consistent with [RANDOM].  Section 3.2.2 describes a
+   suggested algorithm.  It is important that all sites generating
+   Global IDs use a functionally similar algorithm to ensure there is a
+   high probability of uniqueness.
+
+   The use of a pseudo-random algorithm to generate Global IDs in the
+   locally assigned prefix gives an assurance that any network numbered
+   using such a prefix is highly unlikely to have that address space
+   clash with any other network that has another locally assigned prefix
+   allocated to it.  This is a particularly useful property when
+   considering a number of scenarios including networks that merge,
+   overlapping VPN address space, or hosts mobile between such networks.
+
+3.2.2.  Sample Code for Pseudo-Random Global ID Algorithm
+
+   The algorithm described below is intended to be used for locally
+   assigned Global IDs.  In each case the resulting global ID will be
+   used in the appropriate prefix as defined in Section 3.2.
+
+     1) Obtain the current time of day in 64-bit NTP format [NTP].
+
+     2) Obtain an EUI-64 identifier from the system running this
+        algorithm.  If an EUI-64 does not exist, one can be created from
+        a 48-bit MAC address as specified in [ADDARCH].  If an EUI-64
+        cannot be obtained or created, a suitably unique identifier,
+        local to the node, should be used (e.g., system serial number).
+
+     3) Concatenate the time of day with the system-specific identifier
+        in order to create a key.
+
+     4) Compute an SHA-1 digest on the key as specified in [FIPS, SHA1];
+        the resulting value is 160 bits.
+
+     5) Use the least significant 40 bits as the Global ID.
+
+     6) Concatenate FC00::/7, the L bit set to 1, and the 40-bit Global
+        ID to create a Local IPv6 address prefix.
+
+   This algorithm will result in a Global ID that is reasonably unique
+   and can be used to create a locally assigned Local IPv6 address
+   prefix.
+
+
+
+Hinden & Haberman           Standards Track                     [Page 5]
+
+RFC 4193          Unique Local IPv6 Unicast Addresses       October 2005
+
+
+3.2.3.  Analysis of the Uniqueness of Global IDs
+
+   The selection of a pseudo random Global ID is similar to the
+   selection of an SSRC identifier in RTP/RTCP defined in Section 8.1 of
+   [RTP].  This analysis is adapted from that document.
+
+   Since Global IDs are chosen randomly (and independently), it is
+   possible that separate networks have chosen the same Global ID.  For
+   any given network, with one or more random Global IDs, that has
+   inter-connections to other such networks, having a total of N such
+   IDs, the probability that two or more of these IDs will collide can
+   be approximated using the formula:
+
+      P = 1 - exp(-N**2 / 2**(L+1))
+
+   where P is the probability of collision, N is the number of
+   interconnected Global IDs, and L is the length of the Global ID.
+
+   The following table shows the probability of a collision for a range
+   of connections using a 40-bit Global ID field.
+
+      Connections      Probability of Collision
+
+          2                1.81*10^-12
+         10                4.54*10^-11
+        100                4.54*10^-09
+       1000                4.54*10^-07
+      10000                4.54*10^-05
+
+   Based on this analysis, the uniqueness of locally generated Global
+   IDs is adequate for sites planning a small to moderate amount of
+   inter-site communication using locally generated Global IDs.
+
+3.3.  Scope Definition
+
+   By default, the scope of these addresses is global.  That is, they
+   are not limited by ambiguity like the site-local addresses defined in
+   [ADDARCH].  Rather, these prefixes are globally unique, and as such,
+   their applicability is greater than site-local addresses.  Their
+   limitation is in the routability of the prefixes, which is limited to
+   a site and any explicit routing agreements with other sites to
+   propagate them (also see Section 4.1).  Also, unlike site-locals, a
+   site may have more than one of these prefixes and use them at the
+   same time.
+
+
+
+
+
+
+
+Hinden & Haberman           Standards Track                     [Page 6]
+
+RFC 4193          Unique Local IPv6 Unicast Addresses       October 2005
+
+
+4.  Operational Guidelines
+
+   The guidelines in this section do not require any change to the
+   normal routing and forwarding functionality in an IPv6 host or
+   router.  These are configuration and operational usage guidelines.
+
+4.1.  Routing
+
+   Local IPv6 addresses are designed to be routed inside of a site in
+   the same manner as other types of unicast addresses.  They can be
+   carried in any IPv6 routing protocol without any change.
+
+   It is expected that they would share the same Subnet IDs with
+   provider-based global unicast addresses, if they were being used
+   concurrently [GLOBAL].
+
+   The default behavior of exterior routing protocol sessions between
+   administrative routing regions must be to ignore receipt of and not
+   advertise prefixes in the FC00::/7 block.  A network operator may
+   specifically configure prefixes longer than FC00::/7 for inter-site
+   communication.
+
+   If BGP is being used at the site border with an ISP, the default BGP
+   configuration must filter out any Local IPv6 address prefixes, both
+   incoming and outgoing.  It must be set both to keep any Local IPv6
+   address prefixes from being advertised outside of the site as well as
+   to keep these prefixes from being learned from another site.  The
+   exception to this is if there are specific /48 or longer routes
+   created for one or more Local IPv6 prefixes.
+
+   For link-state IGPs, it is suggested that a site utilizing IPv6 local
+   address prefixes be contained within one IGP domain or area.  By
+   containing an IPv6 local address prefix to a single link-state area
+   or domain, the distribution of prefixes can be controlled.
+
+4.2.  Renumbering and Site Merging
+
+   The use of Local IPv6 addresses in a site results in making
+   communication that uses these addresses independent of renumbering a
+   site's provider-based global addresses.
+
+   When merging multiple sites, the addresses created with these
+   prefixes are unlikely to need to be renumbered because all of the
+   addresses have a high probability of being unique.  Routes for each
+   specific prefix would have to be configured to allow routing to work
+   correctly between the formerly separate sites.
+
+
+
+
+
+Hinden & Haberman           Standards Track                     [Page 7]
+
+RFC 4193          Unique Local IPv6 Unicast Addresses       October 2005
+
+
+4.3.  Site Border Router and Firewall Packet Filtering
+
+   While no serious harm will be done if packets with these addresses
+   are sent outside of a site via a default route, it is recommended
+   that routers be configured by default to keep any packets with Local
+   IPv6 addresses from leaking outside of the site and to keep any site
+   prefixes from being advertised outside of their site.
+
+   Site border routers and firewalls should be configured to not forward
+   any packets with Local IPv6 source or destination addresses outside
+   of the site, unless they have been explicitly configured with routing
+   information about specific /48 or longer Local IPv6 prefixes.  This
+   will ensure that packets with Local IPv6 destination addresses will
+   not be forwarded outside of the site via a default route.  The
+   default behavior of these devices should be to install a "reject"
+   route for these prefixes.  Site border routers should respond with
+   the appropriate ICMPv6 Destination Unreachable message to inform the
+   source that the packet was not forwarded. [ICMPV6].  This feedback is
+   important to avoid transport protocol timeouts.
+
+   Routers that maintain peering arrangements between Autonomous Systems
+   throughout the Internet should obey the recommendations for site
+   border routers, unless configured otherwise.
+
+4.4.  DNS Issues
+
+   At the present time, AAAA and PTR records for locally assigned local
+   IPv6 addresses are not recommended to be installed in the global DNS.
+
+   For background on this recommendation, one of the concerns about
+   adding AAAA and PTR records to the global DNS for locally assigned
+   Local IPv6 addresses stems from the lack of complete assurance that
+   the prefixes are unique.  There is a small possibility that the same
+   locally assigned IPv6 Local addresses will be used by two different
+   organizations both claiming to be authoritative with different
+   contents.  In this scenario, it is likely there will be a connection
+   attempt to the closest host with the corresponding locally assigned
+   IPv6 Local address.  This may result in connection timeouts,
+   connection failures indicated by ICMP Destination Unreachable
+   messages, or successful connections to the wrong host.  Due to this
+   concern, adding AAAA records for these addresses to the global DNS is
+   thought to be unwise.
+
+   Reverse (address-to-name) queries for locally assigned IPv6 Local
+   addresses MUST NOT be sent to name servers for the global DNS, due to
+   the load that such queries would create for the authoritative name
+   servers for the ip6.arpa zone.  This form of query load is not
+   specific to locally assigned Local IPv6 addresses; any current form
+
+
+
+Hinden & Haberman           Standards Track                     [Page 8]
+
+RFC 4193          Unique Local IPv6 Unicast Addresses       October 2005
+
+
+   of local addressing creates additional load of this kind, due to
+   reverse queries leaking out of the site.  However, since allowing
+   such queries to escape from the site serves no useful purpose, there
+   is no good reason to make the existing load problems worse.
+
+   The recommended way to avoid sending such queries to nameservers for
+   the global DNS is for recursive name server implementations to act as
+   if they were authoritative for an empty d.f.ip6.arpa zone and return
+   RCODE 3 for any such query.  Implementations that choose this
+   strategy should allow it to be overridden, but returning an RCODE 3
+   response for such queries should be the default, both because this
+   will reduce the query load problem and also because, if the site
+   administrator has not set up the reverse tree corresponding to the
+   locally assigned IPv6 Local addresses in use, returning RCODE 3 is in
+   fact the correct answer.
+
+4.5.  Application and Higher Level Protocol Issues
+
+   Application and other higher level protocols can treat Local IPv6
+   addresses in the same manner as other types of global unicast
+   addresses.  No special handling is required.  This type of address
+   may not be reachable, but that is no different from other types of
+   IPv6 global unicast address.  Applications need to be able to handle
+   multiple addresses that may or may not be reachable at any point in
+   time.  In most cases, this complexity should be hidden in APIs.
+
+   From a host's perspective, the difference between Local IPv6 and
+   other types of global unicast addresses shows up as different
+   reachability and could be handled by default in that way.  In some
+   cases, it is better for nodes and applications to treat them
+   differently from global unicast addresses.  A starting point might be
+   to give them preference over global unicast, but fall back to global
+   unicast if a particular destination is found to be unreachable.  Much
+   of this behavior can be controlled by how they are allocated to nodes
+   and put into the DNS.  However, it is useful if a host can have both
+   types of addresses and use them appropriately.
+
+   Note that the address selection mechanisms of [ADDSEL], and in
+   particular the policy override mechanism replacing default address
+   selection, are expected to be used on a site where Local IPv6
+   addresses are configured.
+
+4.6.  Use of Local IPv6 Addresses for Local Communication
+
+   Local IPv6 addresses, like global scope unicast addresses, are only
+   assigned to nodes if their use has been enabled (via IPv6 address
+   autoconfiguration [ADDAUTO], DHCPv6 [DHCP6], or manually).  They are
+
+
+
+
+Hinden & Haberman           Standards Track                     [Page 9]
+
+RFC 4193          Unique Local IPv6 Unicast Addresses       October 2005
+
+
+   not created automatically in the way that IPv6 link-local addresses
+   are and will not appear or be used unless they are purposely
+   configured.
+
+   In order for hosts to autoconfigure Local IPv6 addresses, routers
+   have to be configured to advertise Local IPv6 /64 prefixes in router
+   advertisements, or a DHCPv6 server must have been configured to
+   assign them.  In order for a node to learn the Local IPv6 address of
+   another node, the Local IPv6 address must have been installed in a
+   naming system (e.g., DNS, proprietary naming system, etc.)  For these
+   reasons, controlling their usage in a site is straightforward.
+
+   To limit the use of Local IPv6 addresses the following guidelines
+   apply:
+
+      - Nodes that are to only be reachable inside of a site:  The local
+        DNS should be configured to only include the Local IPv6
+        addresses of these nodes.  Nodes with only Local IPv6 addresses
+        must not be installed in the global DNS.
+
+      - Nodes that are to be limited to only communicate with other
+        nodes in the site:  These nodes should be set to only
+        autoconfigure Local IPv6 addresses via [ADDAUTO] or to only
+        receive Local IPv6 addresses via [DHCP6].  Note: For the case
+        where both global and Local IPv6 prefixes are being advertised
+        on a subnet, this will require a switch in the devices to only
+        autoconfigure Local IPv6 addresses.
+
+      - Nodes that are to be reachable from inside of the site and from
+        outside of the site:  The DNS should be configured to include
+        the global addresses of these nodes.  The local DNS may be
+        configured to also include the Local IPv6 addresses of these
+        nodes.
+
+      - Nodes that can communicate with other nodes inside of the site
+        and outside of the site: These nodes should autoconfigure global
+        addresses via [ADDAUTO] or receive global address via [DHCP6].
+        They may also obtain Local IPv6 addresses via the same
+        mechanisms.
+
+4.7.  Use of Local IPv6 Addresses with VPNs
+
+   Local IPv6 addresses can be used for inter-site Virtual Private
+   Networks (VPN) if appropriate routes are set up.  Because the
+   addresses are unique, these VPNs will work reliably and without the
+   need for translation.  They have the additional property that they
+   will continue to work if the individual sites are renumbered or
+   merged.
+
+
+
+Hinden & Haberman           Standards Track                    [Page 10]
+
+RFC 4193          Unique Local IPv6 Unicast Addresses       October 2005
+
+
+5.  Global Routing Considerations
+
+   Section 4.1 provides operational guidelines that forbid default
+   routing of local addresses between sites.  Concerns were raised to
+   the IPv6 working group and to the IETF as a whole that sites may
+   attempt to use local addresses as globally routed provider-
+   independent addresses.  This section describes why using local
+   addresses as globally-routed provider-independent addresses is
+   unadvisable.
+
+5.1.  From the Standpoint of the Internet
+
+   There is a mismatch between the structure of IPv6 local addresses and
+   the normal IPv6 wide area routing model.  The /48 prefix of an IPv6
+   local addresses fits nowhere in the normal hierarchy of IPv6 unicast
+   addresses.  Normal IPv6 unicast addresses can be routed
+   hierarchically down to physical subnet (link) level and only have to
+   be flat-routed on the physical subnet.  IPv6 local addresses would
+   have to be flat-routed even over the wide area Internet.
+
+   Thus, packets whose destination address is an IPv6 local address
+   could be routed over the wide area only if the corresponding /48
+   prefix were carried by the wide area routing protocol in use, such as
+   BGP.  This contravenes the operational assumption that long prefixes
+   will be aggregated into many fewer short prefixes, to limit the table
+   size and convergence time of the routing protocol.  If a network uses
+   both normal IPv6 addresses [ADDARCH] and IPv6 local addresses, these
+   types of addresses will certainly not aggregate with each other,
+   since they differ from the most significant bit onwards.  Neither
+   will IPv6 local addresses aggregate with each other, due to their
+   random bit patterns.  This means that there would be a very
+   significant operational penalty for attempting to use IPv6 local
+   address prefixes generically with currently known wide area routing
+   technology.
+
+5.2.  From the Standpoint of a Site
+
+   There are a number of design factors in IPv6 local addresses that
+   reduce the likelihood that IPv6 local addresses will be used as
+   arbitrary global unicast addresses.  These include:
+
+      - The default rules to filter packets and routes make it very
+        difficult to use IPv6 local addresses for arbitrary use across
+        the Internet.  For a site to use them as general purpose unicast
+        addresses, it would have to make sure that the default rules
+        were not being used by all other sites and intermediate ISPs
+        used for their current and future communication.
+
+
+
+
+Hinden & Haberman           Standards Track                    [Page 11]
+
+RFC 4193          Unique Local IPv6 Unicast Addresses       October 2005
+
+
+      - They are not mathematically guaranteed to be unique and are not
+        registered in public databases.  Collisions, while highly
+        unlikely, are possible and a collision can compromise the
+        integrity of the communications.  The lack of public
+        registration creates operational problems.
+
+      - The addresses are allocated randomly.  If a site had multiple
+        prefixes that it wanted to be used globally, the cost of
+        advertising them would be very high because they could not be
+        aggregated.
+
+      - They have a long prefix (i.e., /48) so a single local address
+        prefix doesn't provide enough address space to be used
+        exclusively by the largest organizations.
+
+6.  Advantages and Disadvantages
+
+6.1.  Advantages
+
+   This approach has the following advantages:
+
+      - Provides Local IPv6 prefixes that can be used independently of
+        any provider-based IPv6 unicast address allocations.  This is
+        useful for sites not always connected to the Internet or sites
+        that wish to have a distinct prefix that can be used to localize
+        traffic inside of the site.
+
+      - Applications can treat these addresses in an identical manner as
+        any other type of global IPv6 unicast addresses.
+
+      - Sites can be merged without any renumbering of the Local IPv6
+        addresses.
+
+      - Sites can change their provider-based IPv6 unicast address
+        without disrupting any communication that uses Local IPv6
+        addresses.
+
+      - Well-known prefix that allows for easy filtering at site
+        boundary.
+
+      - Can be used for inter-site VPNs.
+
+      - If accidently leaked outside of a site via routing or DNS, there
+        is no conflict with any other addresses.
+
+
+
+
+
+
+
+Hinden & Haberman           Standards Track                    [Page 12]
+
+RFC 4193          Unique Local IPv6 Unicast Addresses       October 2005
+
+
+6.2.  Disadvantages
+
+   This approach has the following disadvantages:
+
+      - Not possible to route Local IPv6 prefixes on the global Internet
+        with current routing technology.  Consequentially, it is
+        necessary to have the default behavior of site border routers to
+        filter these addresses.
+
+      - There is a very low probability of non-unique locally assigned
+        Global IDs being generated by the algorithm in Section 3.2.3.
+        This risk can be ignored for all practical purposes, but it
+        leads to a theoretical risk of clashing address prefixes.
+
+7.  Security Considerations
+
+   Local IPv6 addresses do not provide any inherent security to the
+   nodes that use them.  They may be used with filters at site
+   boundaries to keep Local IPv6 traffic inside of the site, but this is
+   no more or less secure than filtering any other type of global IPv6
+   unicast addresses.
+
+   Local IPv6 addresses do allow for address-based security mechanisms,
+   including IPsec, across end to end VPN connections.
+
+8.  IANA Considerations
+
+   The IANA has assigned the FC00::/7 prefix to "Unique Local Unicast".
+
+9.  References
+
+9.1.  Normative References
+
+   [ADDARCH]  Hinden, R. and S. Deering, "Internet Protocol Version 6
+             (IPv6) Addressing Architecture", RFC 3513, April 2003.
+
+   [FIPS]    "Federal Information Processing Standards Publication",
+             (FIPS PUB) 180-1, Secure Hash Standard, 17 April 1995.
+
+   [GLOBAL]  Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global
+             Unicast Address Format", RFC 3587, August 2003.
+
+   [ICMPV6]  Conta, A. and S. Deering, "Internet Control Message
+             Protocol (ICMPv6) for the Internet Protocol Version 6
+             (IPv6) Specification", RFC 2463, December 1998.
+
+
+
+
+
+
+Hinden & Haberman           Standards Track                    [Page 13]
+
+RFC 4193          Unique Local IPv6 Unicast Addresses       October 2005
+
+
+   [IPV6]    Deering, S. and R. Hinden, "Internet Protocol, Version 6
+             (IPv6) Specification", RFC 2460, December 1998.
+
+   [NTP]     Mills, D., "Network Time Protocol (Version 3)
+             Specification, Implementation and Analysis", RFC 1305,
+             March 1992.
+
+   [RANDOM]  Eastlake, D., 3rd, Schiller, J., and S. Crocker,
+             "Randomness Requirements for Security", BCP 106, RFC 4086,
+             June 2005.
+
+   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+             Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [SHA1]    Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm 1
+             (SHA1)", RFC 3174, September 2001.
+
+9.2.  Informative References
+
+   [ADDAUTO] Thomson, S. and T. Narten, "IPv6 Stateless Address
+             Autoconfiguration", RFC 2462, December 1998.
+
+   [ADDSEL]  Draves, R., "Default Address Selection for Internet
+             Protocol version 6 (IPv6)", RFC 3484, February 2003.
+
+   [DHCP6]   Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and
+             M. Carney, "Dynamic Host Configuration Protocol for IPv6
+             (DHCPv6)", RFC 3315, July 2003.
+
+   [POPUL]   Population Reference Bureau, "World Population Data Sheet
+             of the Population Reference Bureau 2002",  August 2002.
+
+   [RTP]     Schulzrinne, H.,  Casner, S., Frederick, R., and V.
+             Jacobson, "RTP: A Transport Protocol for Real-Time
+             Applications", STD 64, RFC 3550, July 2003.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hinden & Haberman           Standards Track                    [Page 14]
+
+RFC 4193          Unique Local IPv6 Unicast Addresses       October 2005
+
+
+Authors' Addresses
+
+   Robert M. Hinden
+   Nokia
+   313 Fairchild Drive
+   Mountain View, CA 94043
+   USA
+
+   Phone: +1 650 625-2004
+   EMail: bob.hinden@nokia.com
+
+
+   Brian Haberman
+   Johns Hopkins University
+   Applied Physics Lab
+   11100 Johns Hopkins Road
+   Laurel, MD 20723
+   USA
+
+   Phone: +1 443 778 1319
+   EMail: brian@innovationslab.net
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hinden & Haberman           Standards Track                    [Page 15]
+
+RFC 4193          Unique Local IPv6 Unicast Addresses       October 2005
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2005).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at ietf-
+   ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+Hinden & Haberman           Standards Track                    [Page 16]
+
diff --git a/doc/rfc/rfc4255.txt b/doc/rfc/rfc4255.txt
new file mode 100644
index 0000000..f350b7a
--- /dev/null
+++ b/doc/rfc/rfc4255.txt
@@ -0,0 +1,507 @@
+
+
+
+
+
+
+Network Working Group                                        J. Schlyter
+Request for Comments: 4255                                       OpenSSH
+Category: Standards Track                                     W. Griffin
+                                                                  SPARTA
+                                                            January 2006
+
+
+   Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   This document describes a method of verifying Secure Shell (SSH) host
+   keys using Domain Name System Security (DNSSEC).  The document
+   defines a new DNS resource record that contains a standard SSH key
+   fingerprint.
+
+Table of Contents
+
+   1. Introduction ....................................................2
+   2. SSH Host Key Verification .......................................2
+      2.1. Method .....................................................2
+      2.2. Implementation Notes .......................................2
+      2.3. Fingerprint Matching .......................................3
+      2.4. Authentication .............................................3
+   3. The SSHFP Resource Record .......................................3
+      3.1. The SSHFP RDATA Format .....................................4
+           3.1.1. Algorithm Number Specification ......................4
+           3.1.2. Fingerprint Type Specification ......................4
+           3.1.3. Fingerprint .........................................5
+      3.2. Presentation Format of the SSHFP RR ........................5
+   4. Security Considerations .........................................5
+   5. IANA Considerations .............................................6
+   6. Normative References ............................................7
+   7. Informational References ........................................7
+   8. Acknowledgements ................................................8
+
+
+
+
+Schlyter & Griffin          Standards Track                     [Page 1]
+
+RFC 4255                DNS and SSH Fingerprints            January 2006
+
+
+1.  Introduction
+
+   The SSH [6] protocol provides secure remote login and other secure
+   network services over an insecure network.  The security of the
+   connection relies on the server authenticating itself to the client
+   as well as the user authenticating itself to the server.
+
+   If a connection is established to a server whose public key is not
+   already known to the client, a fingerprint of the key is presented to
+   the user for verification.  If the user decides that the fingerprint
+   is correct and accepts the key, the key is saved locally and used for
+   verification for all following connections.  While some security-
+   conscious users verify the fingerprint out-of-band before accepting
+   the key, many users blindly accept the presented key.
+
+   The method described here can provide out-of-band verification by
+   looking up a fingerprint of the server public key in the DNS [1][2]
+   and using DNSSEC [5] to verify the lookup.
+
+   In order to distribute the fingerprint using DNS, this document
+   defines a new DNS resource record, "SSHFP", to carry the fingerprint.
+
+   Basic understanding of the DNS system [1][2] and the DNS security
+   extensions [5] is assumed by this document.
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [3].
+
+2.  SSH Host Key Verification
+
+2.1.  Method
+
+   Upon connection to an SSH server, the SSH client MAY look up the
+   SSHFP resource record(s) for the host it is connecting to.  If the
+   algorithm and fingerprint of the key received from the SSH server
+   match the algorithm and fingerprint of one of the SSHFP resource
+   record(s) returned from DNS, the client MAY accept the identity of
+   the server.
+
+2.2.  Implementation Notes
+
+   Client implementors SHOULD provide a configurable policy used to
+   select the order of methods used to verify a host key.  This document
+   defines one method: Fingerprint storage in DNS.  Another method
+   defined in the SSH Architecture [6] uses local files to store keys
+   for comparison.  Other methods that could be defined in the future
+   might include storing fingerprints in LDAP or other databases.  A
+
+
+
+Schlyter & Griffin          Standards Track                     [Page 2]
+
+RFC 4255                DNS and SSH Fingerprints            January 2006
+
+
+   configurable policy will allow administrators to determine which
+   methods they want to use and in what order the methods should be
+   prioritized.  This will allow administrators to determine how much
+   trust they want to place in the different methods.
+
+   One specific scenario for having a configurable policy is where
+   clients do not use fully qualified host names to connect to servers.
+   In this scenario, the implementation SHOULD verify the host key
+   against a local database before verifying the key via the fingerprint
+   returned from DNS.  This would help prevent an attacker from
+   injecting a DNS search path into the local resolver and forcing the
+   client to connect to a different host.
+
+2.3.  Fingerprint Matching
+
+   The public key and the SSHFP resource record are matched together by
+   comparing algorithm number and fingerprint.
+
+      The public key algorithm and the SSHFP algorithm number MUST
+      match.
+
+      A message digest of the public key, using the message digest
+      algorithm specified in the SSHFP fingerprint type, MUST match the
+      SSHFP fingerprint.
+
+2.4.  Authentication
+
+   A public key verified using this method MUST NOT be trusted if the
+   SSHFP resource record (RR) used for verification was not
+   authenticated by a trusted SIG RR.
+
+   Clients that do validate the DNSSEC signatures themselves SHOULD use
+   standard DNSSEC validation procedures.
+
+   Clients that do not validate the DNSSEC signatures themselves MUST
+   use a secure transport (e.g., TSIG [9], SIG(0) [10], or IPsec [8])
+   between themselves and the entity performing the signature
+   validation.
+
+3.  The SSHFP Resource Record
+
+   The SSHFP resource record (RR) is used to store a fingerprint of an
+   SSH public host key that is associated with a Domain Name System
+   (DNS) name.
+
+   The RR type code for the SSHFP RR is 44.
+
+
+
+
+
+Schlyter & Griffin          Standards Track                     [Page 3]
+
+RFC 4255                DNS and SSH Fingerprints            January 2006
+
+
+3.1.  The SSHFP RDATA Format
+
+   The RDATA for a SSHFP RR consists of an algorithm number, fingerprint
+   type and the fingerprint of the public host key.
+
+       1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
+       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       |   algorithm   |    fp type    |                               /
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               /
+       /                                                               /
+       /                          fingerprint                          /
+       /                                                               /
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+3.1.1.  Algorithm Number Specification
+
+   This algorithm number octet describes the algorithm of the public
+   key.  The following values are assigned:
+
+          Value    Algorithm name
+          -----    --------------
+          0        reserved
+          1        RSA
+          2        DSS
+
+   Reserving other types requires IETF consensus [4].
+
+3.1.2.  Fingerprint Type Specification
+
+   The fingerprint type octet describes the message-digest algorithm
+   used to calculate the fingerprint of the public key.  The following
+   values are assigned:
+
+          Value    Fingerprint type
+          -----    ----------------
+          0        reserved
+          1        SHA-1
+
+   Reserving other types requires IETF consensus [4].
+
+   For interoperability reasons, as few fingerprint types as possible
+   should be reserved.  The only reason to reserve additional types is
+   to increase security.
+
+
+
+
+
+
+
+Schlyter & Griffin          Standards Track                     [Page 4]
+
+RFC 4255                DNS and SSH Fingerprints            January 2006
+
+
+3.1.3.  Fingerprint
+
+   The fingerprint is calculated over the public key blob as described
+   in [7].
+
+   The message-digest algorithm is presumed to produce an opaque octet
+   string output, which is placed as-is in the RDATA fingerprint field.
+
+3.2.  Presentation Format of the SSHFP RR
+
+   The RDATA of the presentation format of the SSHFP resource record
+   consists of two numbers (algorithm and fingerprint type) followed by
+   the fingerprint itself, presented in hex, e.g.:
+
+       host.example.  SSHFP 2 1 123456789abcdef67890123456789abcdef67890
+
+   The use of mnemonics instead of numbers is not allowed.
+
+4.  Security Considerations
+
+   Currently, the amount of trust a user can realistically place in a
+   server key is proportional to the amount of attention paid to
+   verifying that the public key presented actually corresponds to the
+   private key of the server.  If a user accepts a key without verifying
+   the fingerprint with something learned through a secured channel, the
+   connection is vulnerable to a man-in-the-middle attack.
+
+   The overall security of using SSHFP for SSH host key verification is
+   dependent on the security policies of the SSH host administrator and
+   DNS zone administrator (in transferring the fingerprint), detailed
+   aspects of how verification is done in the SSH implementation, and in
+   the client's diligence in accessing the DNS in a secure manner.
+
+   One such aspect is in which order fingerprints are looked up (e.g.,
+   first checking local file and then SSHFP).  We note that, in addition
+   to protecting the first-time transfer of host keys, SSHFP can
+   optionally be used for stronger host key protection.
+
+      If SSHFP is checked first, new SSH host keys may be distributed by
+      replacing the corresponding SSHFP in DNS.
+
+      If SSH host key verification can be configured to require SSHFP,
+      SSH host key revocation can be implemented by removing the
+      corresponding SSHFP from DNS.
+
+
+
+
+
+
+
+Schlyter & Griffin          Standards Track                     [Page 5]
+
+RFC 4255                DNS and SSH Fingerprints            January 2006
+
+
+   As stated in Section 2.2, we recommend that SSH implementors provide
+   a policy mechanism to control the order of methods used for host key
+   verification.  One specific scenario for having a configurable policy
+   is where clients use unqualified host names to connect to servers.
+   In this case, we recommend that SSH implementations check the host
+   key against a local database before verifying the key via the
+   fingerprint returned from DNS.  This would help prevent an attacker
+   from injecting a DNS search path into the local resolver and forcing
+   the client to connect to a different host.
+
+   A different approach to solve the DNS search path issue would be for
+   clients to use a trusted DNS search path, i.e., one not acquired
+   through DHCP or other autoconfiguration mechanisms.  Since there is
+   no way with current DNS lookup APIs to tell whether a search path is
+   from a trusted source, the entire client system would need to be
+   configured with this trusted DNS search path.
+
+   Another dependency is on the implementation of DNSSEC itself.  As
+   stated in Section 2.4, we mandate the use of secure methods for
+   lookup and that SSHFP RRs are authenticated by trusted SIG RRs.  This
+   is especially important if SSHFP is to be used as a basis for host
+   key rollover and/or revocation, as described above.
+
+   Since DNSSEC only protects the integrity of the host key fingerprint
+   after it is signed by the DNS zone administrator, the fingerprint
+   must be transferred securely from the SSH host administrator to the
+   DNS zone administrator.  This could be done manually between the
+   administrators or automatically using secure DNS dynamic update [11]
+   between the SSH server and the nameserver.  We note that this is no
+   different from other key enrollment situations, e.g., a client
+   sending a certificate request to a certificate authority for signing.
+
+5.  IANA Considerations
+
+   IANA has allocated the RR type code 44 for SSHFP from the standard RR
+   type space.
+
+   IANA has opened a new registry for the SSHFP RR type for public key
+   algorithms.  The defined types are:
+
+      0 is reserved
+      1 is RSA
+      2 is DSA
+
+   Adding new reservations requires IETF consensus [4].
+
+
+
+
+
+
+Schlyter & Griffin          Standards Track                     [Page 6]
+
+RFC 4255                DNS and SSH Fingerprints            January 2006
+
+
+   IANA has opened a new registry for the SSHFP RR type for fingerprint
+   types.  The defined types are:
+
+      0 is reserved
+      1 is SHA-1
+
+   Adding new reservations requires IETF consensus [4].
+
+6.  Normative References
+
+   [1]   Mockapetris, P., "Domain names - concepts and facilities", STD
+         13, RFC 1034, November 1987.
+
+   [2]   Mockapetris, P., "Domain names - implementation and
+         specification", STD 13, RFC 1035, November 1987.
+
+   [3]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
+         Levels", BCP 14, RFC 2119, March 1997.
+
+   [4]   Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
+         Considerations Section in RFCs", BCP 26, RFC 2434, October
+         1998.
+
+   [5]   Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+         "DNS Security Introduction and Requirements", RFC 4033, March
+         2005.
+
+         Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+         "Resource Records for the DNS Security Extensions", RFC 4034,
+         March 2005.
+
+         Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+         "Protocol Modifications for the DNS Security Extensions", RFC
+         4035, March 2005.
+
+   [6]   Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
+         Protocol Architecture", RFC 4251, January 2006.
+
+   [7]   Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
+         Transport Layer Protocol", RFC 4253, January 2006.
+
+7.  Informational References
+
+   [8]   Thayer, R., Doraswamy, N., and R. Glenn, "IP Security Document
+         Roadmap", RFC 2411, November 1998.
+
+
+
+
+
+
+Schlyter & Griffin          Standards Track                     [Page 7]
+
+RFC 4255                DNS and SSH Fingerprints            January 2006
+
+
+   [9]   Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.
+         Wellington, "Secret Key Transaction Authentication for DNS
+         (TSIG)", RFC 2845, May 2000.
+
+   [10]  Eastlake 3rd, D., "DNS Request and Transaction Signatures
+         ( SIG(0)s )", RFC 2931, September 2000.
+
+   [11]  Wellington, B., "Secure Domain Name System (DNS) Dynamic
+         Update", RFC 3007, November 2000.
+
+8.  Acknowledgements
+
+   The authors gratefully acknowledge, in no particular order, the
+   contributions of the following persons:
+
+      Martin Fredriksson
+
+      Olafur Gudmundsson
+
+      Edward Lewis
+
+      Bill Sommerfeld
+
+Authors' Addresses
+
+   Jakob Schlyter
+   OpenSSH
+   812 23rd Avenue SE
+   Calgary, Alberta  T2G 1N8
+   Canada
+
+   EMail: jakob@openssh.com
+   URI:   http://www.openssh.com/
+
+
+   Wesley Griffin
+   SPARTA
+   7075 Samuel Morse Drive
+   Columbia, MD  21046
+   USA
+
+   EMail: wgriffin@sparta.com
+   URI:   http://www.sparta.com/
+
+
+
+
+
+
+
+
+Schlyter & Griffin          Standards Track                     [Page 8]
+
+RFC 4255                DNS and SSH Fingerprints            January 2006
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2006).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Schlyter & Griffin          Standards Track                     [Page 9]
+
diff --git a/doc/rfc/rfc4343.txt b/doc/rfc/rfc4343.txt
new file mode 100644
index 0000000..621420a
--- /dev/null
+++ b/doc/rfc/rfc4343.txt
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+Network Working Group                                    D. Eastlake 3rd
+Request for Comments: 4343                         Motorola Laboratories
+Updates: 1034, 1035, 2181                                   January 2006
+Category: Standards Track
+
+
+       Domain Name System (DNS) Case Insensitivity Clarification
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   Domain Name System (DNS) names are "case insensitive".  This document
+   explains exactly what that means and provides a clear specification
+   of the rules.  This clarification updates RFCs 1034, 1035, and 2181.
+
+Table of Contents
+
+   1. Introduction ....................................................2
+   2. Case Insensitivity of DNS Labels ................................2
+      2.1. Escaping Unusual DNS Label Octets ..........................2
+      2.2. Example Labels with Escapes ................................3
+   3. Name Lookup, Label Types, and CLASS .............................3
+      3.1. Original DNS Label Types ...................................4
+      3.2. Extended Label Type Case Insensitivity Considerations ......4
+      3.3. CLASS Case Insensitivity Considerations ....................4
+   4. Case on Input and Output ........................................5
+      4.1. DNS Output Case Preservation ...............................5
+      4.2. DNS Input Case Preservation ................................5
+   5. Internationalized Domain Names ..................................6
+   6. Security Considerations .........................................6
+   7. Acknowledgements ................................................7
+   Normative References................................................7
+   Informative References..............................................8
+
+
+
+
+
+
+
+Eastlake 3rd                Standards Track                     [Page 1]
+
+RFC 4343          DNS Case Insensitivity Clarification      January 2006
+
+
+1.  Introduction
+
+   The Domain Name System (DNS) is the global hierarchical replicated
+   distributed database system for Internet addressing, mail proxy, and
+   other information.  Each node in the DNS tree has a name consisting
+   of zero or more labels [STD13, RFC1591, RFC2606] that are treated in
+   a case insensitive fashion.  This document clarifies the meaning of
+   "case insensitive" for the DNS.  This clarification updates RFCs
+   1034, 1035 [STD13], and [RFC2181].
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC2119].
+
+2.  Case Insensitivity of DNS Labels
+
+   DNS was specified in the era of [ASCII].  DNS names were expected to
+   look like most host names or Internet email address right halves (the
+   part after the at-sign, "@") or to be numeric, as in the in-addr.arpa
+   part of the DNS name space.  For example,
+
+       foo.example.net.
+       aol.com.
+       www.gnu.ai.mit.edu.
+   or  69.2.0.192.in-addr.arpa.
+
+   Case-varied alternatives to the above [RFC3092] would be DNS names
+   like
+
+       Foo.ExamplE.net.
+       AOL.COM.
+       WWW.gnu.AI.mit.EDU.
+   or  69.2.0.192.in-ADDR.ARPA.
+
+   However, the individual octets of which DNS names consist are not
+   limited to valid ASCII character codes.  They are 8-bit bytes, and
+   all values are allowed.  Many applications, however, interpret them
+   as ASCII characters.
+
+2.1.  Escaping Unusual DNS Label Octets
+
+   In Master Files [STD13] and other human-readable and -writable ASCII
+   contexts, an escape is needed for the byte value for period (0x2E,
+   ".") and all octet values outside of the inclusive range from 0x21
+   ("!") to 0x7E ("~").  That is to say, 0x2E and all octet values in
+   the two inclusive ranges from 0x00 to 0x20 and from 0x7F to 0xFF.
+
+
+
+
+
+Eastlake 3rd                Standards Track                     [Page 2]
+
+RFC 4343          DNS Case Insensitivity Clarification      January 2006
+
+
+   One typographic convention for octets that do not correspond to an
+   ASCII printing graphic is to use a back-slash followed by the value
+   of the octet as an unsigned integer represented by exactly three
+   decimal digits.
+
+   The same convention can be used for printing ASCII characters so that
+   they will be treated as a normal label character.  This includes the
+   back-slash character used in this convention itself, which can be
+   expressed as \092 or \\, and the special label separator period
+   ("."), which can be expressed as and \046 or \.  It is advisable to
+   avoid using a backslash to quote an immediately following non-
+   printing ASCII character code to avoid implementation difficulties.
+
+   A back-slash followed by only one or two decimal digits is undefined.
+   A back-slash followed by four decimal digits produces two octets, the
+   first octet having the value of the first three digits considered as
+   a decimal number, and the second octet being the character code for
+   the fourth decimal digit.
+
+2.2.  Example Labels with Escapes
+
+   The first example below shows embedded spaces and a period (".")
+   within a label.  The second one shows a 5-octet label where the
+   second octet has all bits zero, the third is a backslash, and the
+   fourth octet has all bits one.
+
+         Donald\032E\.\032Eastlake\0323rd.example.
+   and   a\000\\\255z.example.
+
+3.  Name Lookup, Label Types, and CLASS
+
+   According to the original DNS design decision, comparisons on name
+   lookup for DNS queries should be case insensitive [STD13].  That is
+   to say, a lookup string octet with a value in the inclusive range
+   from 0x41 to 0x5A, the uppercase ASCII letters, MUST match the
+   identical value and also match the corresponding value in the
+   inclusive range from 0x61 to 0x7A, the lowercase ASCII letters.  A
+   lookup string octet with a lowercase ASCII letter value MUST
+   similarly match the identical value and also match the corresponding
+   value in the uppercase ASCII letter range.
+
+   (Historical note: The terms "uppercase" and "lowercase" were invented
+   after movable type.  The terms originally referred to the two font
+   trays for storing, in partitioned areas, the different physical type
+   elements.  Before movable type, the nearest equivalent terms were
+   "majuscule" and "minuscule".)
+
+
+
+
+
+Eastlake 3rd                Standards Track                     [Page 3]
+
+RFC 4343          DNS Case Insensitivity Clarification      January 2006
+
+
+   One way to implement this rule would be to subtract 0x20 from all
+   octets in the inclusive range from 0x61 to 0x7A before comparing
+   octets.  Such an operation is commonly known as "case folding", but
+   implementation via case folding is not required.  Note that the DNS
+   case insensitivity does NOT correspond to the case folding specified
+   in [ISO-8859-1] or [ISO-8859-2].  For example, the octets 0xDD (\221)
+   and 0xFD (\253) do NOT match, although in other contexts, where they
+   are interpreted as the upper- and lower-case version of "Y" with an
+   acute accent, they might.
+
+3.1.  Original DNS Label Types
+
+   DNS labels in wire-encoded names have a type associated with them.
+   The original DNS standard [STD13] had only two types: ASCII labels,
+   with a length from zero to 63 octets, and indirect (or compression)
+   labels, which consist of an offset pointer to a name location
+   elsewhere in the wire encoding on a DNS message.  (The ASCII label of
+   length zero is reserved for use as the name of the root node of the
+   name tree.)  ASCII labels follow the ASCII case conventions described
+   herein and, as stated above, can actually contain arbitrary byte
+   values.  Indirect labels are, in effect, replaced by the name to
+   which they point, which is then treated with the case insensitivity
+   rules in this document.
+
+3.2.  Extended Label Type Case Insensitivity Considerations
+
+   DNS was extended by [RFC2671] so that additional label type numbers
+   would be available.  (The only such type defined so far is the BINARY
+   type [RFC2673], which is now Experimental [RFC3363].)
+
+   The ASCII case insensitivity conventions only apply to ASCII labels;
+   that is to say, label type 0x0, whether appearing directly or invoked
+   by indirect labels.
+
+3.3.  CLASS Case Insensitivity Considerations
+
+   As described in [STD13] and [RFC2929], DNS has an additional axis for
+   data location called CLASS.  The only CLASS in global use at this
+   time is the "IN" (Internet) CLASS.
+
+   The handling of DNS label case is not CLASS dependent.  With the
+   original design of DNS, it was intended that a recursive DNS resolver
+   be able to handle new CLASSes that were unknown at the time of its
+   implementation.  This requires uniform handling of label case
+   insensitivity.  Should it become desirable, for example, to allocate
+   a CLASS with "case sensitive ASCII labels", it would be necessary to
+   allocate a new label type for these labels.
+
+
+
+
+Eastlake 3rd                Standards Track                     [Page 4]
+
+RFC 4343          DNS Case Insensitivity Clarification      January 2006
+
+
+4.  Case on Input and Output
+
+   While ASCII label comparisons are case insensitive, [STD13] says case
+   MUST be preserved on output and preserved when convenient on input.
+   However, this means less than it would appear, since the preservation
+   of case on output is NOT required when output is optimized by the use
+   of indirect labels, as explained below.
+
+4.1.  DNS Output Case Preservation
+
+   [STD13] views the DNS namespace as a node tree.  ASCII output is as
+   if a name were marshaled by taking the label on the node whose name
+   is to be output, converting it to a typographically encoded ASCII
+   string, walking up the tree outputting each label encountered, and
+   preceding all labels but the first with a period (".").  Wire output
+   follows the same sequence, but each label is wire encoded, and no
+   periods are inserted.  No "case conversion" or "case folding" is done
+   during such output operations, thus "preserving" case.  However, to
+   optimize output, indirect labels may be used to point to names
+   elsewhere in the DNS answer.  In determining whether the name to be
+   pointed to (for example, the QNAME) is the "same" as the remainder of
+   the name being optimized, the case insensitive comparison specified
+   above is done.  Thus, such optimization may easily destroy the output
+   preservation of case.  This type of optimization is commonly called
+   "name compression".
+
+4.2.  DNS Input Case Preservation
+
+   Originally, DNS data came from an ASCII Master File as defined in
+   [STD13] or a zone transfer.  DNS Dynamic update and incremental zone
+   transfers [RFC1995] have been added as a source of DNS data [RFC2136,
+   RFC3007].  When a node in the DNS name tree is created by any of such
+   inputs, no case conversion is done.  Thus, the case of ASCII labels
+   is preserved if they are for nodes being created.  However, when a
+   name label is input for a node that already exists in DNS data being
+   held, the situation is more complex.  Implementations are free to
+   retain the case first loaded for such a label, to allow new input to
+   override the old case, or even to maintain separate copies preserving
+   the input case.
+
+   For example, if data with owner name "foo.bar.example" [RFC3092] is
+   loaded and then later data with owner name "xyz.BAR.example" is
+   input, the name of the label on the "bar.example" node (i.e., "bar")
+   might or might not be changed to "BAR" in the DNS stored data.  Thus,
+   later retrieval of data stored under "xyz.bar.example" in this case
+   can use "xyz.BAR.example" in all returned data, use "xyz.bar.example"
+   in all returned data, or even, when more than one RR is being
+   returned, use a mixture of these two capitalizations.  This last case
+
+
+
+Eastlake 3rd                Standards Track                     [Page 5]
+
+RFC 4343          DNS Case Insensitivity Clarification      January 2006
+
+
+   is unlikely, as optimization of answer length through indirect labels
+   tends to cause only one copy of the name tail ("bar.example" or
+   "BAR.example") to be used for all returned RRs.  Note that none of
+   this has any effect on the number or completeness of the RR set
+   returned, only on the case of the names in the RR set returned.
+
+   The same considerations apply when inputting multiple data records
+   with owner names differing only in case.  For example, if an "A"
+   record is the first resource record stored under owner name
+   "xyz.BAR.example" and then a second "A" record is stored under
+   "XYZ.BAR.example", the second MAY be stored with the first (lower
+   case initial label) name, the second MAY override the first so that
+   only an uppercase initial label is retained, or both capitalizations
+   MAY be kept in the DNS stored data.  In any case, a retrieval with
+   either capitalization will retrieve all RRs with either
+   capitalization.
+
+   Note that the order of insertion into a server database of the DNS
+   name tree nodes that appear in a Master File is not defined so that
+   the results of inconsistent capitalization in a Master File are
+   unpredictable output capitalization.
+
+5.  Internationalized Domain Names
+
+   A scheme has been adopted for "internationalized domain names" and
+   "internationalized labels" as described in [RFC3490, RFC3454,
+   RFC3491, and RFC3492].  It makes most of [UNICODE] available through
+   a separate application level transformation from internationalized
+   domain name to DNS domain name and from DNS domain name to
+   internationalized domain name.  Any case insensitivity that
+   internationalized domain names and labels have varies depending on
+   the script and is handled entirely as part of the transformation
+   described in [RFC3454] and [RFC3491], which should be seen for
+   further details.  This is not a part of the DNS as standardized in
+   STD 13.
+
+6.  Security Considerations
+
+   The equivalence of certain DNS label types with case differences, as
+   clarified in this document, can lead to security problems.  For
+   example, a user could be confused by believing that two domain names
+   differing only in case were actually different names.
+
+   Furthermore, a domain name may be used in contexts other than the
+   DNS.  It could be used as a case sensitive index into some database
+   or file system.  Or it could be interpreted as binary data by some
+   integrity or authentication code system.  These problems can usually
+   be handled by using a standardized or "canonical" form of the DNS
+
+
+
+Eastlake 3rd                Standards Track                     [Page 6]
+
+RFC 4343          DNS Case Insensitivity Clarification      January 2006
+
+
+   ASCII type labels; that is, always mapping the ASCII letter value
+   octets in ASCII labels to some specific pre-chosen case, either
+   uppercase or lower case.  An example of a canonical form for domain
+   names (and also a canonical ordering for them) appears in Section 6
+   of [RFC4034].  See also [RFC3597].
+
+   Finally, a non-DNS name may be stored into DNS with the false
+   expectation that case will always be preserved.  For example,
+   although this would be quite rare, on a system with case sensitive
+   email address local parts, an attempt to store two Responsible Person
+   (RP) [RFC1183] records that differed only in case would probably
+   produce unexpected results that might have security implications.
+   That is because the entire email address, including the possibly case
+   sensitive local or left-hand part, is encoded into a DNS name in a
+   readable fashion where the case of some letters might be changed on
+   output as described above.
+
+7.  Acknowledgements
+
+   The contributions to this document by Rob Austein, Olafur
+   Gudmundsson, Daniel J. Anderson, Alan Barrett, Marc Blanchet, Dana,
+   Andreas Gustafsson, Andrew Main, Thomas Narten, and Scott Seligman
+   are gratefully acknowledged.
+
+Normative References
+
+   [ASCII]      ANSI, "USA Standard Code for Information Interchange",
+                X3.4, American National Standards Institute: New York,
+                1968.
+
+   [RFC1995]    Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,
+                August 1996.
+
+   [RFC2119]    Bradner, S., "Key words for use in RFCs to Indicate
+                Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2136]    Vixie, P., Thomson,  S., Rekhter, Y., and J. Bound,
+                "Dynamic Updates in the Domain Name System (DNS
+                UPDATE)", RFC 2136, April 1997.
+
+   [RFC2181]     Elz, R. and R. Bush, "Clarifications to the DNS
+                Specification", RFC 2181, July 1997.
+
+   [RFC3007]    Wellington, B., "Secure Domain Name System (DNS) Dynamic
+                Update", RFC 3007, November 2000.
+
+
+
+
+
+
+Eastlake 3rd                Standards Track                     [Page 7]
+
+RFC 4343          DNS Case Insensitivity Clarification      January 2006
+
+
+   [RFC3597]    Gustafsson, A., "Handling of Unknown DNS Resource Record
+                (RR) Types", RFC 3597, September 2003.
+
+   [RFC4034]    Arends, R., Austein, R., Larson, M., Massey, D., and S.
+                Rose, "Resource Records for the DNS Security
+                Extensions", RFC 4034, March 2005.
+
+   [STD13]      Mockapetris, P., "Domain names - concepts and
+                facilities", STD 13, RFC 1034, November 1987.
+
+                Mockapetris, P., "Domain names - implementation and
+                specification", STD 13, RFC 1035, November 1987.
+
+Informative References
+
+   [ISO-8859-1] International Standards Organization, Standard for
+                Character Encodings, Latin-1.
+
+   [ISO-8859-2] International Standards Organization, Standard for
+                Character Encodings, Latin-2.
+
+   [RFC1183]    Everhart, C., Mamakos, L., Ullmann, R., and P.
+                Mockapetris, "New DNS RR Definitions", RFC 1183, October
+                1990.
+
+   [RFC1591]    Postel, J., "Domain Name System Structure and
+                Delegation", RFC 1591, March 1994.
+
+   [RFC2606]    Eastlake 3rd, D. and A. Panitz, "Reserved Top Level DNS
+                Names", BCP 32, RFC 2606, June 1999.
+
+   [RFC2929]    Eastlake 3rd, D., Brunner-Williams, E., and B. Manning,
+                "Domain Name System (DNS) IANA Considerations", BCP 42,
+                RFC 2929, September 2000.
+
+   [RFC2671]    Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
+                2671, August 1999.
+
+   [RFC2673]    Crawford, M., "Binary Labels in the Domain Name System",
+                RFC 2673, August 1999.
+
+   [RFC3092]    Eastlake 3rd, D., Manros, C., and E. Raymond, "Etymology
+                of "Foo"", RFC 3092, 1 April 2001.
+
+   [RFC3363]    Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T.
+                Hain, "Representing Internet Protocol version 6 (IPv6)
+                Addresses in the Domain Name System (DNS)", RFC 3363,
+                August 2002.
+
+
+
+Eastlake 3rd                Standards Track                     [Page 8]
+
+RFC 4343          DNS Case Insensitivity Clarification      January 2006
+
+
+   [RFC3454]    Hoffman, P. and M. Blanchet, "Preparation of
+                Internationalized Strings ("stringprep")", RFC 3454,
+                December 2002.
+
+   [RFC3490]    Faltstrom, P., Hoffman, P., and A. Costello,
+                "Internationalizing Domain Names in Applications
+                (IDNA)", RFC 3490, March 2003.
+
+   [RFC3491]    Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep
+                Profile for Internationalized Domain Names (IDN)", RFC
+                3491, March 2003.
+
+   [RFC3492]    Costello, A., "Punycode: A Bootstring encoding of
+                Unicode for Internationalized Domain Names in
+                Applications (IDNA)", RFC 3492, March 2003.
+
+   [UNICODE]    The Unicode Consortium, "The Unicode Standard",
+                <http://www.unicode.org/unicode/standard/standard.html>.
+
+Author's Address
+
+   Donald E. Eastlake 3rd
+   Motorola Laboratories
+   155 Beaver Street
+   Milford, MA 01757 USA
+
+   Phone: +1 508-786-7554 (w)
+   EMail: Donald.Eastlake@motorola.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake 3rd                Standards Track                     [Page 9]
+
+RFC 4343          DNS Case Insensitivity Clarification      January 2006
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2006).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Eastlake 3rd                Standards Track                    [Page 10]
+
diff --git a/doc/rfc/rfc4367.txt b/doc/rfc/rfc4367.txt
new file mode 100644
index 0000000..f066b64
--- /dev/null
+++ b/doc/rfc/rfc4367.txt
@@ -0,0 +1,955 @@
+
+
+
+
+
+
+Network Working Group                                  J. Rosenberg, Ed.
+Request for Comments: 4367                                           IAB
+Category: Informational                                    February 2006
+
+
+          What's in a Name: False Assumptions about DNS Names
+
+Status of This Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   The Domain Name System (DNS) provides an essential service on the
+   Internet, mapping structured names to a variety of data, usually IP
+   addresses.  These names appear in email addresses, Uniform Resource
+   Identifiers (URIs), and other application-layer identifiers that are
+   often rendered to human users.  Because of this, there has been a
+   strong demand to acquire names that have significance to people,
+   through equivalence to registered trademarks, company names, types of
+   services, and so on.  There is a danger in this trend; the humans and
+   automata that consume and use such names will associate specific
+   semantics with some names and thereby make assumptions about the
+   services that are, or should be, provided by the hosts associated
+   with the names.  Those assumptions can often be false, resulting in a
+   variety of failure conditions.  This document discusses this problem
+   in more detail and makes recommendations on how it can be avoided.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rosenberg                    Informational                      [Page 1]
+
+RFC 4367                    Name Assumptions               February 2006
+
+
+Table of Contents
+
+   1. Introduction ....................................................2
+   2. Target Audience .................................................4
+   3. Modeling Usage of the DNS .......................................4
+   4. Possible Assumptions ............................................5
+      4.1. By the User ................................................5
+      4.2. By the Client ..............................................6
+      4.3. By the Server ..............................................7
+   5. Consequences of False Assumptions ...............................8
+   6. Reasons Why the Assumptions Can Be False ........................9
+      6.1. Evolution ..................................................9
+      6.2. Leakage ...................................................10
+      6.3. Sub-Delegation ............................................10
+      6.4. Mobility ..................................................12
+      6.5. Human Error ...............................................12
+   7. Recommendations ................................................12
+   8. A Note on RFC 2219 and RFC 2782 ................................13
+   9. Security Considerations ........................................14
+   10. Acknowledgements ..............................................14
+   11. IAB Members ...................................................14
+   12. Informative References ........................................15
+
+1.  Introduction
+
+   The Domain Name System (DNS) [1] provides an essential service on the
+   Internet, mapping structured names to a variety of different types of
+   data.  Most often it is used to obtain the IP address of a host
+   associated with that name [2] [1] [3].  However, it can be used to
+   obtain other information, and proposals have been made for nearly
+   everything, including geographic information [4].
+
+   Domain names are most often used in identifiers used by application
+   protocols.  The most well known include email addresses and URIs,
+   such as the HTTP URL [5], Real Time Streaming Protocol (RTSP) URL
+   [6], and SIP URI [7].  These identifiers are ubiquitous, appearing on
+   business cards, web pages, street signs, and so on.  Because of this,
+   there has been a strong demand to acquire domain names that have
+   significance to people through equivalence to registered trademarks,
+   company names, types of services, and so on.  Such identifiers serve
+   many business purposes, including extension of brand, advertising,
+   and so on.
+
+   People often make assumptions about the type of service that is or
+   should be provided by a host associated with that name, based on
+   their expectations and understanding of what the name implies.  This,
+   in turn, triggers attempts by organizations to register domain names
+   based on that presumed user expectation.  Examples of this are the
+
+
+
+Rosenberg                    Informational                      [Page 2]
+
+RFC 4367                    Name Assumptions               February 2006
+
+
+   various proposals for a Top-Level Domain (TLD) that could be
+   associated with adult content [8], the requests for creation of TLDs
+   associated with mobile devices and services, and even phishing
+   attacks.
+
+   When these assumptions are codified into the behavior of an
+   automaton, such as an application client or server, as a result of
+   implementor choice, management directive, or domain owner policy, the
+   overall system can fail in various ways.  This document describes a
+   number of typical ways in which these assumptions can be codified,
+   how they can be wrong, the consequences of those mistakes, and the
+   recommended ways in which they can be avoided.
+
+   Section 4 describes some of the possible assumptions that clients,
+   servers, and people can make about a domain name.  In this context,
+   an "assumption" is defined as any behavior that is expected when
+   accessing a service at a domain name, even though the behavior is not
+   explicitly codified in protocol specifications.  Frequently, these
+   assumptions involve ignoring parts of a specification based on an
+   assumption that the client or server is deployed in an environment
+   that is more rigid than the specification allows.  Section 5
+   overviews some of the consequences of these false assumptions.
+   Generally speaking, these consequences can include a variety of
+   different interoperability failures, user experience failures, and
+   system failures.  Section 6 discusses why these assumptions can be
+   false from the very beginning or become false at some point in the
+   future.  Most commonly, they become false because the environment
+   changes in unexpected ways over time, and what was a valid assumption
+   before, no longer is.  Other times, the assumptions prove wrong
+   because they were based on the belief that a specific community of
+   clients and servers was participating, and an element outside of that
+   community began participating.
+
+   Section 7 then provides some recommendations.  These recommendations
+   encapsulate some of the engineering mantras that have been at the
+   root of Internet protocol design for decades.  These include:
+
+      Follow the specifications.
+
+      Use the capability negotiation techniques provided in the
+      protocols.
+
+      Be liberal in what you accept, and conservative in what you send.
+      [18]
+
+   Overall, automata should not change their behavior within a protocol
+   based on the domain name, or some component of the domain name, of
+   the host they are communicating with.
+
+
+
+Rosenberg                    Informational                      [Page 3]
+
+RFC 4367                    Name Assumptions               February 2006
+
+
+2.  Target Audience
+
+   This document has several audiences.  Firstly, it is aimed at
+   implementors who ultimately develop the software that make the false
+   assumptions that are the subject of this document.  The
+   recommendations described here are meant to reinforce the engineering
+   guidelines that are often understood by implementors, but frequently
+   forgotten as deadlines near and pressures mount.
+
+   The document is also aimed at technology managers, who often develop
+   the requirements that lead to these false assumptions.  For them,
+   this document serves as a vehicle for emphasizing the importance of
+   not taking shortcuts in the scope of applicability of a project.
+
+   Finally, this document is aimed at domain name policy makers and
+   administrators.  For them, it points out the perils in establishing
+   domain policies that get codified into the operation of applications
+   running within that domain.
+
+3.  Modeling Usage of the DNS
+
+
+                       +--------+
+                       |        |
+                       |        |
+                       |  DNS   |
+                       |Service |
+                       |        |
+                       +--------+
+                         ^   |
+                         |   |
+                         |   |
+                         |   |
+          /--\           |   |
+         |    |          |   V
+         |    |        +--------+                     +--------+
+          \--/         |        |                     |        |
+            |          |        |                     |        |
+         ---+---       | Client |-------------------->| Server |
+            |          |        |                     |        |
+            |          |        |                     |        |
+           /\          +--------+                     +--------+
+          /  \
+         /    \
+
+         User
+                                 Figure 1
+
+
+
+
+Rosenberg                    Informational                      [Page 4]
+
+RFC 4367                    Name Assumptions               February 2006
+
+
+   Figure 1 shows a simple conceptual model of how the DNS is used by
+   applications.  A user of the application obtains an identifier for
+   particular content or service it wishes to obtain.  This identifier
+   is often a URL or URI that contains a domain name.  The user enters
+   this identifier into its client application (for example, by typing
+   in the URL in a web browser window).  The client is the automaton (a
+   software and/or hardware system) that contacts a server for that
+   application in order to provide service to the user.  To do that, it
+   contacts a DNS server to resolve the domain name in the identifier to
+   an IP address.  It then contacts the server at that IP address.  This
+   simple model applies to application protocols such as HTTP [5], SIP
+   [7], RTSP [6], and SMTP [9].
+
+   >From this model, it is clear that three entities in the system can
+   potentially make false assumptions about the service provided by the
+   server.  The human user may form expectations relating to the content
+   of the service based on a parsing of the host name from which the
+   content originated.  The server might assume that the client
+   connecting to it supports protocols that it does not, can process
+   content that it cannot, or has capabilities that it does not.
+   Similarly, the client might assume that the server supports
+   protocols, content, or capabilities that it does not.  Furthermore,
+   applications can potentially contain a multiplicity of humans,
+   clients, and servers, all of which can independently make these false
+   assumptions.
+
+4.  Possible Assumptions
+
+   For each of the three elements, there are many types of false
+   assumptions that can be made.
+
+4.1.  By the User
+
+   The set of possible assumptions here is nearly boundless.  Users
+   might assume that an HTTP URL that looks like a company name maps to
+   a server run by that company.  They might assume that an email from a
+   email address in the .gov TLD is actually from a government employee.
+   They might assume that the content obtained from a web server within
+   a TLD labeled as containing adult materials (for example, .sex)
+   actually contains adult content [8].  These assumptions are
+   unavoidable, may all be false, and are not the focus of this
+   document.
+
+
+
+
+
+
+
+
+
+Rosenberg                    Informational                      [Page 5]
+
+RFC 4367                    Name Assumptions               February 2006
+
+
+4.2.  By the Client
+
+   Even though the client is an automaton, it can make some of the same
+   assumptions that a human user might make.  For example, many clients
+   assume that any host with a hostname that begins with "www" is a web
+   server, even though this assumption may be false.
+
+   In addition, the client concerns itself with the protocols needed to
+   communicate with the server.  As a result, it might make assumptions
+   about the operation of the protocols for communicating with the
+   server.  These assumptions manifest themselves in an implementation
+   when a standardized protocol negotiation technique defined by the
+   protocol is ignored, and instead, some kind of rule is coded into the
+   software that comes to its own conclusion about what the negotiation
+   would have determined.  The result is often a loss of
+   interoperability, degradation in reliability, and worsening of user
+   experience.
+
+   Authentication Algorithm: Though a protocol might support a
+      multiplicity of authentication techniques, a client might assume
+      that a server always supports one that is only optional according
+      to the protocol.  For example, a SIP client contacting a SIP
+      server in a domain that is apparently used to identify mobile
+      devices (for example, www.example.cellular) might assume that the
+      server supports the optional Authentication and Key Agreement
+      (AKA) digest technique [10], just because of the domain name that
+      was used to access the server.  As another example, a web client
+      might assume that a server with the name https.example.com
+      supports HTTP over Transport Layer Security (TLS) [16].
+
+   Data Formats: Though a protocol might allow a multiplicity of data
+      formats to be sent from the server to the client, the client might
+      assume a specific one, rather than using the content labeling and
+      negotiation capabilities of the underlying protocol.  For example,
+      an RTSP client might assume that all audio content delivered to it
+      from media.example.cellular uses a low-bandwidth codec.  As
+      another example, a mail client might assume that the contents of
+      messages it retrieves from a mail server at mail.example.cellular
+      are always text, instead of checking the MIME headers [11] in the
+      message in order to determine the actual content type.
+
+   Protocol Extensions: A client may attempt an operation on the server
+      that requires the server to support an optional protocol
+      extension.  However, rather than implementing the necessary
+      fallback logic, the client may falsely assume that the extension
+      is supported.  As an example, a SIP client that requires reliable
+      provisional responses to its request (RFC 3262 [17]) might assume
+      that this extension is supported on servers in the domain
+
+
+
+Rosenberg                    Informational                      [Page 6]
+
+RFC 4367                    Name Assumptions               February 2006
+
+
+      sip.example.telecom.  Furthermore, the client would not implement
+      the fallback behavior defined in RFC 3262, since it would assume
+      that all servers it will communicate with are in this domain and
+      that all therefore support this extension.  However, if the
+      assumptions prove wrong, the client is unable to make any phone
+      calls.
+
+   Languages: A client may support facilities for processing text
+      content differently depending on the language of the text.  Rather
+      than determining the language from markers in the message from the
+      server, the client might assume a language based on the domain
+      name.  This assumption can easily be wrong.  For example, a client
+      might assume that any text in a web page retrieved from a server
+      within the .de country code TLD (ccTLD) is in German, and attempt
+      a translation to Finnish.  This would fail dramatically if the
+      text was actually in French.  Unfortunately, this client behavior
+      is sometimes exhibited because the server has not properly labeled
+      the language of the content in the first place, often because the
+      server assumed such a labeling was not needed.  This is an example
+      of how these false assumptions can create vicious cycles.
+
+4.3.  By the Server
+
+   The server, like the client, is an automaton.  Let us consider one
+   servicing a particular domain -- www.company.cellular, for example.
+   It might assume that all clients connecting to this domain support
+   particular capabilities, rather than using the underlying protocol to
+   make this determination.  Some examples include:
+
+   Authentication Algorithm: The server can assume that a client
+      supports a particular, optional, authentication technique, and it
+      therefore does not support the mandatory one.
+
+   Language: The server can serve content in a particular language,
+      based on an assumption that clients accessing the domain speak a
+      particular language, or based on an assumption that clients coming
+      from a particular IP address speak a certain language.
+
+   Data Formats: The server can assume that the client supports a
+      particular set of MIME types and is only capable of sending ones
+      within that set.  When it generates content in a protocol
+      response, it ignores any content negotiation headers that were
+      present in the request.  For example, a web server might ignore
+      the Accept HTTP header field and send a specific image format.
+
+
+
+
+
+
+
+Rosenberg                    Informational                      [Page 7]
+
+RFC 4367                    Name Assumptions               February 2006
+
+
+   Protocol Extensions: The server might assume that the client supports
+      a particular optional protocol extension, and so it does not
+      support the fallback behavior necessary in the case where the
+      client does not.
+
+   Client Characteristics: The server might assume certain things about
+      the physical characteristics of its clients, such as memory
+      footprint, processing power, screen sizes, screen colors, pointing
+      devices, and so on.  Based on these assumptions, it might choose
+      specific behaviors when processing a request.  For example, a web
+      server might always assume that clients connect through cell
+      phones, and therefore return content that lacks images and is
+      tuned for such devices.
+
+5.  Consequences of False Assumptions
+
+   There are numerous negative outcomes that can arise from the various
+   false assumptions that users, servers, and clients can make.  These
+   include:
+
+   Interoperability Failure: In these cases, the client or server
+      assumed some kind of protocol operation, and this assumption was
+      wrong.  The result is that the two are unable to communicate, and
+      the user receives some kind of an error.  This represents a total
+      interoperability failure, manifesting itself as a lack of service
+      to users of the system.  Unfortunately, this kind of failure
+      persists.  Repeated attempts over time by the client to access the
+      service will fail.  Only a change in the server or client software
+      can fix this problem.
+
+   System Failure: In these cases, the client or server misinterpreted a
+      protocol operation, and this misinterpretation was serious enough
+      to uncover a bug in the implementation.  The bug causes a system
+      crash or some kind of outage, either transient or permanent (until
+      user reset).  If this failure occurs in a server, not only will
+      the connecting client lose service, but other clients attempting
+      to connect will not get service.  As an example, if a web server
+      assumes that content passed to it from a client (created, for
+      example, by a digital camera) is of a particular content type, and
+      it always passes image content to a codec for decompression prior
+      to storage, the codec might crash when it unexpectedly receives an
+      image compressed in a different format.  Of course, it might crash
+      even if the Content-Type was correct, but the compressed bitstream
+      was invalid.  False assumptions merely introduce additional
+      failure cases.
+
+
+
+
+
+
+Rosenberg                    Informational                      [Page 8]
+
+RFC 4367                    Name Assumptions               February 2006
+
+
+   Poor User Experience: In these cases, the client and server
+      communicate, but the user receives a diminished user experience.
+      For example, if a client on a PC connects to a web site that
+      provides content for mobile devices, the content may be
+      underwhelming when viewed on the PC.  Or, a client accessing a
+      streaming media service may receive content of very low bitrate,
+      even though the client supported better codecs.  Indeed, if a user
+      wishes to access content from both a cellular device and a PC
+      using a shared address book (that is, an address book shared
+      across multiple devices), the user would need two entries in that
+      address book, and would need to use the right one from the right
+      device.  This is a poor user experience.
+
+   Degraded Security: In these cases, a weaker security mechanism is
+      used than the one that ought to have been used.  As an example, a
+      server in a domain might assume that it is only contacted by
+      clients with a limited set of authentication algorithms, even
+      though the clients have been recently upgraded to support a
+      stronger set.
+
+6.  Reasons Why the Assumptions Can Be False
+
+   Assumptions made by clients and servers about the operation of
+   protocols when contacting a particular domain are brittle, and can be
+   wrong for many reasons.  On the server side, many of the assumptions
+   are based on the notion that a domain name will only be given to, or
+   used by, a restricted set of clients.  If the holder of the domain
+   name assumes something about those clients, and can assume that only
+   those clients use the domain name, then it can configure or program
+   the server to operate specifically for those clients.  Both parts of
+   this assumption can be wrong, as discussed in more detail below.
+
+   On the client side, the notion is similar, being based on the
+   assumption that a server within a particular domain will provide a
+   specific type of service.  Sub-delegation and evolution, both
+   discussed below, can make these assumptions wrong.
+
+6.1.  Evolution
+
+   The Internet and the devices that access it are constantly evolving,
+   often at a rapid pace.  Unfortunately, there is a tendency to build
+   for the here and now, and then worry about the future at a later
+   time.  Many of the assumptions above are predicated on
+   characteristics of today's clients and servers.  Support for specific
+   protocols, authentication techniques, or content are based on today's
+   standards and today's devices.  Even though they may, for the most
+   part, be true, they won't always be.  An excellent example is mobile
+   devices.  A server servicing a domain accessed by mobile devices
+
+
+
+Rosenberg                    Informational                      [Page 9]
+
+RFC 4367                    Name Assumptions               February 2006
+
+
+   might try to make assumptions about the protocols, protocol
+   extensions, security mechanisms, screen sizes, or processor power of
+   such devices.  However, all of these characteristics can and will
+   change over time.
+
+   When they do change, the change is usually evolutionary.  The result
+   is that the assumptions remain valid in some cases, but not in
+   others.  It is difficult to fix such systems, since it requires the
+   server to detect what type of client is connecting, and what its
+   capabilities are.  Unless the system is built and deployed with these
+   capability negotiation techniques built in to begin with, such
+   detection can be extremely difficult.  In fact, fixing it will often
+   require the addition of such capability negotiation features that, if
+   they had been in place and used to begin with, would have avoided the
+   problem altogether.
+
+6.2.  Leakage
+
+   Servers also make assumptions because of the belief that they will
+   only be accessed by specific clients, and in particular, those that
+   are configured or provisioned to use the domain name.  In essence,
+   there is an assumption of community -- that a specific community
+   knows and uses the domain name, while others outside of the community
+   do not.
+
+   The problem is that this notion of community is a false one.  The
+   Internet is global.  The DNS is global.  There is no technical
+   barrier that separates those inside of the community from those
+   outside.  The ease with which information propagates across the
+   Internet makes it extremely likely that such domain names will
+   eventually find their way into clients outside of the presumed
+   community.  The ubiquitous presence of domain names in various URI
+   formats, coupled with the ease of conveyance of URIs, makes such
+   leakage merely a matter of time.  Furthermore, since the DNS is
+   global, and since it can only have one root [12], it becomes possible
+   for clients outside of the community to search and find and use such
+   "special" domain names.
+
+   Indeed, this leakage is a strength of the Internet architecture, not
+   a weakness.  It enables global access to services from any client
+   with a connection to the Internet.  That, in turn, allows for rapid
+   growth in the number of customers for any particular service.
+
+6.3.  Sub-Delegation
+
+   Clients and users make assumptions about domains because of the
+   notion that there is some kind of centralized control that can
+   enforce those assumptions.  However, the DNS is not centralized; it
+
+
+
+Rosenberg                    Informational                     [Page 10]
+
+RFC 4367                    Name Assumptions               February 2006
+
+
+   is distributed.  If a domain doesn't delegate its sub-domains and has
+   its records within a single zone, it is possible to maintain a
+   centralized policy about operation of its domain.  However, once a
+   domain gets sufficiently large that the domain administrators begin
+   to delegate sub-domains to other authorities, it becomes increasingly
+   difficult to maintain any kind of central control on the nature of
+   the service provided in each sub-domain.
+
+   Similarly, the usage of domain names with human semantic connotation
+   tends to lead to a registration of multiple domains in which a
+   particular service is to run.  As an example, a service provider with
+   the name "example" might register and set up its services in
+   "example.com", "example.net", and generally example.foo for each foo
+   that is a valid TLD.  This, like sub-delegation, results in a growth
+   in the number of domains over which it is difficult to maintain
+   centralized control.
+
+   Not that it is not possible, since there are many examples of
+   successful administration of policies across sub-domains many levels
+   deep.  However, it takes an increasing amount of effort to ensure
+   this result, as it requires human intervention and the creation of
+   process and procedure.  Automated validation of adherence to policies
+   is very difficult to do, as there is no way to automatically verify
+   many policies that might be put into place.
+
+   A less costly process for providing centralized management of
+   policies is to just hope that any centralized policies are being
+   followed, and then wait for complaints or perform random audits.
+   Those approaches have many problems.
+
+   The invalidation of assumptions due to sub-delegation is discussed in
+   further detail in Section 4.1.3 of [8] and in Section 3.3 of [20].
+
+   As a result of the fragility of policy continuity across sub-
+   delegations, if a client or user assumes some kind of property
+   associated with a TLD (such as ".wifi"), it becomes increasingly more
+   likely with the number of sub-domains that this property will not
+   exist in a server identified by a particular name.  For example, in
+   "store.chain.company.provider.wifi", there may be four levels of
+   delegation from ".wifi", making it quite likely that, unless the
+   holder of ".wifi" is working diligently, the properties that the
+   holder of ".wifi" wishes to enforce are not present.  These
+   properties may not be present due to human error or due to a willful
+   decision not to adhere to them.
+
+
+
+
+
+
+
+Rosenberg                    Informational                     [Page 11]
+
+RFC 4367                    Name Assumptions               February 2006
+
+
+6.4.  Mobility
+
+   One of the primary value propositions of a hostname as an identifier
+   is its persistence.  A client can change IP addresses, yet still
+   retain a persistent identifier used by other hosts to reach it.
+   Because their value derives from their persistence, hostnames tend to
+   move with a host not just as it changes IP addresses, but as it
+   changes access network providers and technologies.  For this reason,
+   assumptions made about a host based on the presumed access network
+   corresponding to that hostname tend to be wrong over time.  As an
+   example, a PC might normally be connected to its broadband provider,
+   and through dynamic DNS have a hostname within the domain of that
+   provider.  However, one cannot assume that any host within that
+   network has access over a broadband link; the user could connect
+   their PC over a low-bandwidth wireless access network and still
+   retain its domain name.
+
+6.5.  Human Error
+
+   Of course, human error can be the source of errors in any system, and
+   the same is true here.  There are many examples relevant to the
+   problem under discussion.
+
+   A client implementation may make the assumption that, just because a
+   DNS SRV record exists for a particular protocol in a particular
+   domain, indicating that the service is available on some port, that
+   the service is, in fact, running there.  This assumption could be
+   wrong because the SRV records haven't been updated by the system
+   administrators to reflect the services currently running.  As another
+   example, a client might assume that a particular domain policy
+   applies to all sub-domains.  However, a system administrator might
+   have omitted to apply the policy to servers running in one of those
+   sub-domains.
+
+7.  Recommendations
+
+   Based on these problems, the clear conclusion is that clients,
+   servers, and users should not make assumptions on the nature of the
+   service provided to, or by, a domain.  More specifically, however,
+   the following can be said:
+
+   Follow the specifications: When specifications define mandatory
+      baseline procedures and formats, those should be implemented and
+      supported, even if the expectation is that optional procedures
+      will most often be used.  For example, if a specification mandates
+      a particular baseline authentication technique, but allows others
+      to be negotiated and used, implementations need to implement the
+      baseline authentication algorithm even if the other ones are used
+
+
+
+Rosenberg                    Informational                     [Page 12]
+
+RFC 4367                    Name Assumptions               February 2006
+
+
+      most of the time.  Put more simply, the behavior of the protocol
+      machinery should never change based on the domain name of the
+      host.
+
+   Use capability negotiation: Many protocols are engineered with
+      capability negotiation mechanisms.  For example, a content
+      negotiation framework has been defined for protocols using MIME
+      content [13] [14] [15].  SIP allows for clients to negotiate the
+      media types used in the multimedia session, as well as protocol
+      parameters.  HTTP allows for clients to negotiate the media types
+      returned in requests for content.  When such features are
+      available in a protocol, client and servers should make use of
+      them rather than making assumptions about supported capabilities.
+      A corollary is that protocol designers should include such
+      mechanisms when evolution is expected in the usage of the
+      protocol.
+
+   "Be liberal in what you accept, and conservative in what you send"
+      [18]:  This axiom of Internet protocol design is applicable here
+      as well.  Implementations should be prepared for the full breadth
+      of what a protocol allows another entity to send, rather than be
+      limiting in what it is willing to receive.
+
+   To summarize -- there is never a need to make assumptions.  Rather
+   than doing so, utilize the specifications and the negotiation
+   capabilities they provide, and the overall system will be robust and
+   interoperable.
+
+8.  A Note on RFC 2219 and RFC 2782
+
+   Based on the definition of an assumption given here, the behavior
+   hinted at by records in the DNS also represents an assumption.  RFC
+   2219 [19] defines well-known aliases that can be used to construct
+   domain names for reaching various well-known services in a domain.
+   This approach was later followed by the definition of a new resource
+   record, the SRV record [2], which specifies that a particular service
+   is running on a server in a domain.  Although both of these
+   mechanisms are useful as a hint that a particular service is running
+   in a domain, both of them represent assumptions that may be false.
+   However, they differ in the set of reasons why those assumptions
+   might be false.
+
+   A client that assumes that "ftp.example.com" is an FTP server may be
+   wrong because the presumed naming convention in RFC 2219 was not
+   known by, or not followed by, the owner of domain.com.  With RFC
+   2782, an SRV record for a particular service would be present only by
+   explicit choice of the domain administrator, and thus a client that
+
+
+
+
+Rosenberg                    Informational                     [Page 13]
+
+RFC 4367                    Name Assumptions               February 2006
+
+
+   assumes that the corresponding host provides this service would be
+   wrong only because of human error in configuration.  In this case,
+   the assumption is less likely to be wrong, but it certainly can be.
+
+   The only way to determine with certainty that a service is running on
+   a host is to initiate a connection to the port for that service, and
+   check.  Implementations need to be careful not to codify any
+   behaviors that cause failures should the information provided in the
+   record actually be false.  This borders on common sense for robust
+   implementations, but it is valuable to raise this point explicitly.
+
+9.  Security Considerations
+
+   One of the assumptions that can be made by clients or servers is the
+   availability and usage (or lack thereof) of certain security
+   protocols and algorithms.  For example, a client accessing a service
+   in a particular domain might assume a specific authentication
+   algorithm or hash function in the application protocol.  It is
+   possible that, over time, weaknesses are found in such a technique,
+   requiring usage of a different mechanism.  Similarly, a system might
+   start with an insecure mechanism, and then decide later on to use a
+   secure one.  In either case, assumptions made on security properties
+   can result in interoperability failures, or worse yet, providing
+   service in an insecure way, even though the client asked for, and
+   thought it would get, secure service.  These kinds of assumptions are
+   fundamentally unsound even if the records themselves are secured with
+   DNSSEC.
+
+10.  Acknowledgements
+
+   The IAB would like to thank John Klensin, Keith Moore and Peter Koch
+   for their comments.
+
+11.  IAB Members
+
+   Internet Architecture Board members at the time of writing of this
+   document are:
+
+      Bernard Aboba
+
+      Loa Andersson
+
+      Brian Carpenter
+
+      Leslie Daigle
+
+      Patrik Faltstrom
+
+
+
+
+Rosenberg                    Informational                     [Page 14]
+
+RFC 4367                    Name Assumptions               February 2006
+
+
+      Bob Hinden
+
+      Kurtis Lindqvist
+
+      David Meyer
+
+      Pekka Nikander
+
+      Eric Rescorla
+
+      Pete Resnick
+
+      Jonathan Rosenberg
+
+12.  Informative References
+
+   [1]   Mockapetris, P., "Domain names - concepts and facilities",
+         STD 13, RFC 1034, November 1987.
+
+   [2]   Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
+         specifying the location of services (DNS SRV)", RFC 2782,
+         February 2000.
+
+   [3]   Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
+         Three: The Domain Name System (DNS) Database", RFC 3403,
+         October 2002.
+
+   [4]   Davis, C., Vixie, P., Goodwin, T., and I. Dickinson, "A Means
+         for Expressing Location Information in the Domain Name System",
+         RFC 1876, January 1996.
+
+   [5]   Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
+         Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol --
+         HTTP/1.1", RFC 2616, June 1999.
+
+   [6]   Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming
+         Protocol (RTSP)", RFC 2326, April 1998.
+
+   [7]   Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
+         Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
+         Session Initiation Protocol", RFC 3261, June 2002.
+
+   [8]   Eastlake, D., ".sex Considered Dangerous", RFC 3675,
+         February 2004.
+
+   [9]   Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
+         April 2001.
+
+
+
+
+Rosenberg                    Informational                     [Page 15]
+
+RFC 4367                    Name Assumptions               February 2006
+
+
+   [10]  Niemi, A., Arkko, J., and V. Torvinen, "Hypertext Transfer
+         Protocol (HTTP) Digest Authentication Using Authentication and
+         Key Agreement (AKA)", RFC 3310, September 2002.
+
+   [11]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+         Extensions (MIME) Part One: Format of Internet Message Bodies",
+         RFC 2045, November 1996.
+
+   [12]  Internet Architecture Board, "IAB Technical Comment on the
+         Unique DNS Root", RFC 2826, May 2000.
+
+   [13]  Klyne, G., "Indicating Media Features for MIME Content",
+         RFC 2912, September 2000.
+
+   [14]  Klyne, G., "A Syntax for Describing Media Feature Sets",
+         RFC 2533, March 1999.
+
+   [15]  Klyne, G., "Protocol-independent Content Negotiation
+         Framework", RFC 2703, September 1999.
+
+   [16]  Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
+
+   [17]  Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional
+         Responses in Session Initiation Protocol (SIP)", RFC 3262,
+         June 2002.
+
+   [18]  Braden, R., "Requirements for Internet Hosts - Communication
+         Layers", STD 3, RFC 1122, October 1989.
+
+   [19]  Hamilton, M. and R. Wright, "Use of DNS Aliases for Network
+         Services", BCP 17, RFC 2219, October 1997.
+
+   [20]  Faltstrom, P., "Design Choices When Expanding DNS", Work in
+         Progress, June 2005.
+
+Author's Address
+
+   Jonathan Rosenberg, Editor
+   IAB
+   600 Lanidex Plaza
+   Parsippany, NJ  07054
+   US
+
+   Phone: +1 973 952-5000
+   EMail: jdrosen@cisco.com
+   URI:   http://www.jdrosen.net
+
+
+
+
+
+Rosenberg                    Informational                     [Page 16]
+
+RFC 4367                    Name Assumptions               February 2006
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2006).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Rosenberg                    Informational                     [Page 17]
+
diff --git a/doc/rfc/rfc4398.txt b/doc/rfc/rfc4398.txt
new file mode 100644
index 0000000..6437436
--- /dev/null
+++ b/doc/rfc/rfc4398.txt
@@ -0,0 +1,955 @@
+
+
+
+
+
+
+Network Working Group                                       S. Josefsson
+Request for Comments: 4398                                    March 2006
+Obsoletes: 2538
+Category: Standards Track
+
+
+          Storing Certificates in the Domain Name System (DNS)
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   Cryptographic public keys are frequently published, and their
+   authenticity is demonstrated by certificates.  A CERT resource record
+   (RR) is defined so that such certificates and related certificate
+   revocation lists can be stored in the Domain Name System (DNS).
+
+   This document obsoletes RFC 2538.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Josefsson                   Standards Track                     [Page 1]
+
+RFC 4398            Storing Certificates in the DNS        February 2006
+
+
+Table of Contents
+
+   1. Introduction ....................................................3
+   2. The CERT Resource Record ........................................3
+      2.1. Certificate Type Values ....................................4
+      2.2. Text Representation of CERT RRs ............................6
+      2.3. X.509 OIDs .................................................6
+   3. Appropriate Owner Names for CERT RRs ............................7
+      3.1. Content-Based X.509 CERT RR Names ..........................8
+      3.2. Purpose-Based X.509 CERT RR Names ..........................9
+      3.3. Content-Based OpenPGP CERT RR Names ........................9
+      3.4. Purpose-Based OpenPGP CERT RR Names .......................10
+      3.5. Owner Names for IPKIX, ISPKI, IPGP, and IACPKIX ...........10
+   4. Performance Considerations .....................................11
+   5. Contributors ...................................................11
+   6. Acknowledgements ...............................................11
+   7. Security Considerations ........................................12
+   8. IANA Considerations ............................................12
+   9. Changes since RFC 2538 .........................................13
+   10. References ....................................................14
+      10.1. Normative References .....................................14
+      10.2. Informative References ...................................15
+   Appendix A.  Copying Conditions ...................................16
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Josefsson                   Standards Track                     [Page 2]
+
+RFC 4398            Storing Certificates in the DNS        February 2006
+
+
+1.  Introduction
+
+   Public keys are frequently published in the form of a certificate,
+   and their authenticity is commonly demonstrated by certificates and
+   related certificate revocation lists (CRLs).  A certificate is a
+   binding, through a cryptographic digital signature, of a public key,
+   a validity interval and/or conditions, and identity, authorization,
+   or other information.  A certificate revocation list is a list of
+   certificates that are revoked, and of incidental information, all
+   signed by the signer (issuer) of the revoked certificates.  Examples
+   are X.509 certificates/CRLs in the X.500 directory system or OpenPGP
+   certificates/revocations used by OpenPGP software.
+
+   Section 2 specifies a CERT resource record (RR) for the storage of
+   certificates in the Domain Name System [1] [2].
+
+   Section 3 discusses appropriate owner names for CERT RRs.
+
+   Sections 4, 7, and 8 cover performance, security, and IANA
+   considerations, respectively.
+
+   Section 9 explains the changes in this document compared to RFC 2538.
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [3].
+
+2.  The CERT Resource Record
+
+   The CERT resource record (RR) has the structure given below.  Its RR
+   type code is 37.
+
+                       1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
+   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |             type              |             key tag           |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |   algorithm   |                                               /
+   +---------------+            certificate or CRL                 /
+   /                                                               /
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
+
+   The type field is the certificate type as defined in Section 2.1
+   below.
+
+   The key tag field is the 16-bit value computed for the key embedded
+   in the certificate, using the RRSIG Key Tag algorithm described in
+   Appendix B of [12].  This field is used as an efficiency measure to
+
+
+
+Josefsson                   Standards Track                     [Page 3]
+
+RFC 4398            Storing Certificates in the DNS        February 2006
+
+
+   pick which CERT RRs may be applicable to a particular key.  The key
+   tag can be calculated for the key in question, and then only CERT RRs
+   with the same key tag need to be examined.  Note that two different
+   keys can have the same key tag.  However, the key MUST be transformed
+   to the format it would have as the public key portion of a DNSKEY RR
+   before the key tag is computed.  This is only possible if the key is
+   applicable to an algorithm and complies to limits (such as key size)
+   defined for DNS security.  If it is not, the algorithm field MUST be
+   zero and the tag field is meaningless and SHOULD be zero.
+
+   The algorithm field has the same meaning as the algorithm field in
+   DNSKEY and RRSIG RRs [12], except that a zero algorithm field
+   indicates that the algorithm is unknown to a secure DNS, which may
+   simply be the result of the algorithm not having been standardized
+   for DNSSEC [11].
+
+2.1.  Certificate Type Values
+
+   The following values are defined or reserved:
+
+         Value  Mnemonic  Certificate Type
+         -----  --------  ----------------
+             0            Reserved
+             1  PKIX      X.509 as per PKIX
+             2  SPKI      SPKI certificate
+             3  PGP       OpenPGP packet
+             4  IPKIX     The URL of an X.509 data object
+             5  ISPKI     The URL of an SPKI certificate
+             6  IPGP      The fingerprint and URL of an OpenPGP packet
+             7  ACPKIX    Attribute Certificate
+             8  IACPKIX   The URL of an Attribute Certificate
+         9-252            Available for IANA assignment
+           253  URI       URI private
+           254  OID       OID private
+           255            Reserved
+     256-65279            Available for IANA assignment
+   65280-65534            Experimental
+         65535            Reserved
+
+   These values represent the initial content of the IANA registry; see
+   Section 8.
+
+   The PKIX type is reserved to indicate an X.509 certificate conforming
+   to the profile defined by the IETF PKIX working group [8].  The
+   certificate section will start with a one-octet unsigned OID length
+   and then an X.500 OID indicating the nature of the remainder of the
+
+
+
+
+
+Josefsson                   Standards Track                     [Page 4]
+
+RFC 4398            Storing Certificates in the DNS        February 2006
+
+
+   certificate section (see Section 2.3, below).  (NOTE: X.509
+   certificates do not include their X.500 directory-type-designating
+   OID as a prefix.)
+
+   The SPKI and ISPKI types are reserved to indicate the SPKI
+   certificate format [15], for use when the SPKI documents are moved
+   from experimental status.  The format for these two CERT RR types
+   will need to be specified later.
+
+   The PGP type indicates an OpenPGP packet as described in [5] and its
+   extensions and successors.  This is used to transfer public key
+   material and revocation signatures.  The data is binary and MUST NOT
+   be encoded into an ASCII armor.  An implementation SHOULD process
+   transferable public keys as described in Section 10.1 of [5], but it
+   MAY handle additional OpenPGP packets.
+
+   The ACPKIX type indicates an Attribute Certificate format [9].
+
+   The IPKIX and IACPKIX types indicate a URL that will serve the
+   content that would have been in the "certificate, CRL, or URL" field
+   of the corresponding type (PKIX or ACPKIX, respectively).
+
+   The IPGP type contains both an OpenPGP fingerprint for the key in
+   question, as well as a URL.  The certificate portion of the IPGP CERT
+   RR is defined as a one-octet fingerprint length, followed by the
+   OpenPGP fingerprint, followed by the URL.  The OpenPGP fingerprint is
+   calculated as defined in RFC 2440 [5].  A zero-length fingerprint or
+   a zero-length URL are legal, and indicate URL-only IPGP data or
+   fingerprint-only IPGP data, respectively.  A zero-length fingerprint
+   and a zero-length URL are meaningless and invalid.
+
+   The IPKIX, ISPKI, IPGP, and IACPKIX types are known as "indirect".
+   These types MUST be used when the content is too large to fit in the
+   CERT RR and MAY be used at the implementer's discretion.  They SHOULD
+   NOT be used where the DNS message is 512 octets or smaller and could
+   thus be expected to fit a UDP packet.
+
+   The URI private type indicates a certificate format defined by an
+   absolute URI.  The certificate portion of the CERT RR MUST begin with
+   a null-terminated URI [10], and the data after the null is the
+   private format certificate itself.  The URI SHOULD be such that a
+   retrieval from it will lead to documentation on the format of the
+   certificate.  Recognition of private certificate types need not be
+   based on URI equality but can use various forms of pattern matching
+   so that, for example, subtype or version information can also be
+   encoded into the URI.
+
+
+
+
+
+Josefsson                   Standards Track                     [Page 5]
+
+RFC 4398            Storing Certificates in the DNS        February 2006
+
+
+   The OID private type indicates a private format certificate specified
+   by an ISO OID prefix.  The certificate section will start with a
+   one-octet unsigned OID length and then a BER-encoded OID indicating
+   the nature of the remainder of the certificate section.  This can be
+   an X.509 certificate format or some other format.  X.509 certificates
+   that conform to the IETF PKIX profile SHOULD be indicated by the PKIX
+   type, not the OID private type.  Recognition of private certificate
+   types need not be based on OID equality but can use various forms of
+   pattern matching such as OID prefix.
+
+2.2.  Text Representation of CERT RRs
+
+   The RDATA portion of a CERT RR has the type field as an unsigned
+   decimal integer or as a mnemonic symbol as listed in Section 2.1,
+   above.
+
+   The key tag field is represented as an unsigned decimal integer.
+
+   The algorithm field is represented as an unsigned decimal integer or
+   a mnemonic symbol as listed in [12].
+
+   The certificate/CRL portion is represented in base 64 [16] and may be
+   divided into any number of white-space-separated substrings, down to
+   single base-64 digits, which are concatenated to obtain the full
+   signature.  These substrings can span lines using the standard
+   parenthesis.
+
+   Note that the certificate/CRL portion may have internal sub-fields,
+   but these do not appear in the master file representation.  For
+   example, with type 254, there will be an OID size, an OID, and then
+   the certificate/CRL proper.  However, only a single logical base-64
+   string will appear in the text representation.
+
+2.3.  X.509 OIDs
+
+   OIDs have been defined in connection with the X.500 directory for
+   user certificates, certification authority certificates, revocations
+   of certification authority, and revocations of user certificates.
+   The following table lists the OIDs, their BER encoding, and their
+   length-prefixed hex format for use in CERT RRs:
+
+
+
+
+
+
+
+
+
+
+
+Josefsson                   Standards Track                     [Page 6]
+
+RFC 4398            Storing Certificates in the DNS        February 2006
+
+
+       id-at-userCertificate
+           = { joint-iso-ccitt(2) ds(5) at(4) 36 }
+              == 0x 03 55 04 24
+       id-at-cACertificate
+           = { joint-iso-ccitt(2) ds(5) at(4) 37 }
+              == 0x 03 55 04 25
+       id-at-authorityRevocationList
+           = { joint-iso-ccitt(2) ds(5) at(4) 38 }
+              == 0x 03 55 04 26
+       id-at-certificateRevocationList
+           = { joint-iso-ccitt(2) ds(5) at(4) 39 }
+              == 0x 03 55 04 27
+
+3.  Appropriate Owner Names for CERT RRs
+
+   It is recommended that certificate CERT RRs be stored under a domain
+   name related to their subject, i.e., the name of the entity intended
+   to control the private key corresponding to the public key being
+   certified.  It is recommended that certificate revocation list CERT
+   RRs be stored under a domain name related to their issuer.
+
+   Following some of the guidelines below may result in DNS names with
+   characters that require DNS quoting as per Section 5.1 of RFC 1035
+   [2].
+
+   The choice of name under which CERT RRs are stored is important to
+   clients that perform CERT queries.  In some situations, the clients
+   may not know all information about the CERT RR object it wishes to
+   retrieve.  For example, a client may not know the subject name of an
+   X.509 certificate, or the email address of the owner of an OpenPGP
+   key.  Further, the client might only know the hostname of a service
+   that uses X.509 certificates or the Key ID of an OpenPGP key.
+
+   Therefore, two owner name guidelines are defined: content-based owner
+   names and purpose-based owner names.  A content-based owner name is
+   derived from the content of the CERT RR data; for example, the
+   Subject field in an X.509 certificate or the User ID field in OpenPGP
+   keys.  A purpose-based owner name is a name that a client retrieving
+   CERT RRs ought to know already; for example, the host name of an
+   X.509 protected service or the Key ID of an OpenPGP key.  The
+   content-based and purpose-based owner name may be the same; for
+   example, when a client looks up a key based on the From: address of
+   an incoming email.
+
+   Implementations SHOULD use the purpose-based owner name guidelines
+   described in this document and MAY use CNAME RRs at content-based
+   owner names (or other names), pointing to the purpose-based owner
+   name.
+
+
+
+Josefsson                   Standards Track                     [Page 7]
+
+RFC 4398            Storing Certificates in the DNS        February 2006
+
+
+   Note that this section describes an application-based mapping from
+   the name space used in a certificate to the name space used by DNS.
+   The DNS does not infer any relationship amongst CERT resource records
+   based on similarities or differences of the DNS owner name(s) of CERT
+   resource records.  For example, if multiple labels are used when
+   mapping from a CERT identifier to a domain name, then care must be
+   taken in understanding wildcard record synthesis.
+
+3.1.  Content-Based X.509 CERT RR Names
+
+   Some X.509 versions, such as the PKIX profile of X.509 [8], permit
+   multiple names to be associated with subjects and issuers under
+   "Subject Alternative Name" and "Issuer Alternative Name".  For
+   example, the PKIX profile has such Alternate Names with an ASN.1
+   specification as follows:
+
+      GeneralName ::= CHOICE {
+           otherName                       [0]     OtherName,
+           rfc822Name                      [1]     IA5String,
+           dNSName                         [2]     IA5String,
+           x400Address                     [3]     ORAddress,
+           directoryName                   [4]     Name,
+           ediPartyName                    [5]     EDIPartyName,
+           uniformResourceIdentifier       [6]     IA5String,
+           iPAddress                       [7]     OCTET STRING,
+           registeredID                    [8]     OBJECT IDENTIFIER }
+
+   The recommended locations of CERT storage are as follows, in priority
+   order:
+
+   1.  If a domain name is included in the identification in the
+       certificate or CRL, that ought to be used.
+   2.  If a domain name is not included but an IP address is included,
+       then the translation of that IP address into the appropriate
+       inverse domain name ought to be used.
+   3.  If neither of the above is used, but a URI containing a domain
+       name is present, that domain name ought to be used.
+   4.  If none of the above is included but a character string name is
+       included, then it ought to be treated as described below for
+       OpenPGP names.
+   5.  If none of the above apply, then the distinguished name (DN)
+       ought to be mapped into a domain name as specified in [4].
+
+   Example 1: An X.509v3 certificate is issued to /CN=John Doe /DC=Doe/
+   DC=com/DC=xy/O=Doe Inc/C=XY/ with Subject Alternative Names of (a)
+   string "John (the Man) Doe", (b) domain name john-doe.com, and (c)
+   URI <https://www.secure.john-doe.com:8080/>.  The storage locations
+   recommended, in priority order, would be
+
+
+
+Josefsson                   Standards Track                     [Page 8]
+
+RFC 4398            Storing Certificates in the DNS        February 2006
+
+
+   1.  john-doe.com,
+   2.  www.secure.john-doe.com, and
+   3.  Doe.com.xy.
+
+   Example 2: An X.509v3 certificate is issued to /CN=James Hacker/
+   L=Basingstoke/O=Widget Inc/C=GB/ with Subject Alternate names of (a)
+   domain name widget.foo.example, (b) IPv4 address 10.251.13.201, and
+   (c) string "James Hacker <hacker@mail.widget.foo.example>".  The
+   storage locations recommended, in priority order, would be
+
+   1.  widget.foo.example,
+   2.  201.13.251.10.in-addr.arpa, and
+   3.  hacker.mail.widget.foo.example.
+
+3.2.  Purpose-Based X.509 CERT RR Names
+
+   Due to the difficulty for clients that do not already possess a
+   certificate to reconstruct the content-based owner name,
+   purpose-based owner names are recommended in this section.
+   Recommendations for purpose-based owner names vary per scenario.  The
+   following table summarizes the purpose-based X.509 CERT RR owner name
+   guidelines for use with S/MIME [17], SSL/TLS [13], and IPsec [14]:
+
+    Scenario             Owner name
+    ------------------   ----------------------------------------------
+    S/MIME Certificate   Standard translation of an RFC 2822 email
+                         address.  Example: An S/MIME certificate for
+                         "postmaster@example.org" will use a standard
+                         hostname translation of the owner name,
+                         "postmaster.example.org".
+
+    TLS Certificate      Hostname of the TLS server.
+
+    IPsec Certificate    Hostname of the IPsec machine and/or, for IPv4
+                         or IPv6 addresses, the fully qualified domain
+                         name in the appropriate reverse domain.
+
+   An alternate approach for IPsec is to store raw public keys [18].
+
+3.3.  Content-Based OpenPGP CERT RR Names
+
+   OpenPGP signed keys (certificates) use a general character string
+   User ID [5].  However, it is recommended by OpenPGP that such names
+   include the RFC 2822 [7] email address of the party, as in "Leslie
+   Example <Leslie@host.example>".  If such a format is used, the CERT
+   ought to be under the standard translation of the email address into
+
+
+
+
+
+Josefsson                   Standards Track                     [Page 9]
+
+RFC 4398            Storing Certificates in the DNS        February 2006
+
+
+   a domain name, which would be leslie.host.example in this case.  If
+   no RFC 2822 name can be extracted from the string name, no specific
+   domain name is recommended.
+
+   If a user has more than one email address, the CNAME type can be used
+   to reduce the amount of data stored in the DNS.  For example:
+
+      $ORIGIN example.org.
+      smith        IN CERT PGP 0 0 <OpenPGP binary>
+      john.smith   IN CNAME smith
+      js           IN CNAME smith
+
+3.4.  Purpose-Based OpenPGP CERT RR Names
+
+   Applications that receive an OpenPGP packet containing encrypted or
+   signed data but do not know the email address of the sender will have
+   difficulties constructing the correct owner name and cannot use the
+   content-based owner name guidelines.  However, these clients commonly
+   know the key fingerprint or the Key ID.  The key ID is found in
+   OpenPGP packets, and the key fingerprint is commonly found in
+   auxiliary data that may be available.  In this case, use of an owner
+   name identical to the key fingerprint and the key ID expressed in
+   hexadecimal [16] is recommended.  For example:
+
+      $ORIGIN example.org.
+      0424D4EE81A0E3D119C6F835EDA21E94B565716F IN CERT PGP ...
+      F835EDA21E94B565716F                     IN CERT PGP ...
+      B565716F                                 IN CERT PGP ...
+
+   If the same key material is stored for several owner names, the use
+   of CNAME may help avoid data duplication.  Note that CNAME is not
+   always applicable, because it maps one owner name to the other for
+   all purposes, which may be sub-optimal when two keys with the same
+   Key ID are stored.
+
+3.5.  Owner Names for IPKIX, ISPKI, IPGP, and IACPKIX
+
+   These types are stored under the same owner names, both purpose- and
+   content-based, as the PKIX, SPKI, PGP, and ACPKIX types.
+
+
+
+
+
+
+
+
+
+
+
+
+Josefsson                   Standards Track                    [Page 10]
+
+RFC 4398            Storing Certificates in the DNS        February 2006
+
+
+4.  Performance Considerations
+
+   The Domain Name System (DNS) protocol was designed for small
+   transfers, typically below 512 octets.  While larger transfers will
+   perform correctly and work is underway to make larger transfers more
+   efficient, it is still advisable at this time that every reasonable
+   effort be made to minimize the size of certificates stored within the
+   DNS.  Steps that can be taken may include using the fewest possible
+   optional or extension fields and using short field values for
+   necessary variable-length fields.
+
+   The RDATA field in the DNS protocol may only hold data of size 65535
+   octets (64kb) or less.  This means that each CERT RR MUST NOT contain
+   more than 64kb of payload, even if the corresponding certificate or
+   certificate revocation list is larger.  This document addresses this
+   by defining "indirect" data types for each normal type.
+
+   Deploying CERT RRs to support digitally signed email changes the
+   access patterns of DNS lookups from per-domain to per-user.  If
+   digitally signed email and a key/certificate lookup based on CERT RRs
+   are deployed on a wide scale, this may lead to an increased DNS load,
+   with potential performance and cache effectiveness consequences.
+   Whether or not this load increase will be noticeable is not known.
+
+5.  Contributors
+
+   The majority of this document is copied verbatim from RFC 2538, by
+   Donald Eastlake 3rd and Olafur Gudmundsson.
+
+6.  Acknowledgements
+
+   Thanks to David Shaw and Michael Graff for their contributions to
+   earlier works that motivated, and served as inspiration for, this
+   document.
+
+   This document was improved by suggestions and comments from Olivier
+   Dubuisson, Scott Hollenbeck, Russ Housley, Peter Koch, Olaf M.
+   Kolkman, Ben Laurie, Edward Lewis, John Loughney, Allison Mankin,
+   Douglas Otis, Marcos Sanz, Pekka Savola, Jason Sloderbeck, Samuel
+   Weiler, and Florian Weimer.  No doubt the list is incomplete.  We
+   apologize to anyone we left out.
+
+
+
+
+
+
+
+
+
+
+Josefsson                   Standards Track                    [Page 11]
+
+RFC 4398            Storing Certificates in the DNS        February 2006
+
+
+7.  Security Considerations
+
+   By definition, certificates contain their own authenticating
+   signatures.  Thus, it is reasonable to store certificates in
+   non-secure DNS zones or to retrieve certificates from DNS with DNS
+   security checking not implemented or deferred for efficiency.  The
+   results may be trusted if the certificate chain is verified back to a
+   known trusted key and this conforms with the user's security policy.
+
+   Alternatively, if certificates are retrieved from a secure DNS zone
+   with DNS security checking enabled and are verified by DNS security,
+   the key within the retrieved certificate may be trusted without
+   verifying the certificate chain if this conforms with the user's
+   security policy.
+
+   If an organization chooses to issue certificates for its employees,
+   placing CERT RRs in the DNS by owner name, and if DNSSEC (with NSEC)
+   is in use, it is possible for someone to enumerate all employees of
+   the organization.  This is usually not considered desirable, for the
+   same reason that enterprise phone listings are not often publicly
+   published and are even marked confidential.
+
+   Using the URI type introduces another level of indirection that may
+   open a new vulnerability.  One method of securing that indirection is
+   to include a hash of the certificate in the URI itself.
+
+   If DNSSEC is used, then the non-existence of a CERT RR and,
+   consequently, certificates or revocation lists can be securely
+   asserted.  Without DNSSEC, this is not possible.
+
+8.  IANA Considerations
+
+   The IANA has created a new registry for CERT RR: certificate types.
+   The initial contents of this registry is:
+
+       Decimal   Type     Meaning                           Reference
+       -------   ----     -------                           ---------
+             0            Reserved                          RFC 4398
+             1   PKIX     X.509 as per PKIX                 RFC 4398
+             2   SPKI     SPKI certificate                  RFC 4398
+             3   PGP      OpenPGP packet                    RFC 4398
+             4   IPKIX    The URL of an X.509 data object   RFC 4398
+             5   ISPKI    The URL of an SPKI certificate    RFC 4398
+             6   IPGP     The fingerprint and URL           RFC 4398
+                          of an OpenPGP packet
+             7   ACPKIX   Attribute Certificate             RFC 4398
+             8   IACPKIX  The URL of an Attribute           RFC 4398
+                             Certificate
+
+
+
+Josefsson                   Standards Track                    [Page 12]
+
+RFC 4398            Storing Certificates in the DNS        February 2006
+
+
+         9-252            Available for IANA assignment
+                             by IETF Standards action
+           253   URI      URI private                       RFC 4398
+           254   OID      OID private                       RFC 4398
+           255            Reserved                          RFC 4398
+     256-65279            Available for IANA assignment
+                          by IETF Consensus
+   65280-65534            Experimental                      RFC 4398
+         65535            Reserved                          RFC 4398
+
+   Certificate types 0x0000 through 0x00FF and 0xFF00 through 0xFFFF can
+   only be assigned by an IETF standards action [6].  This document
+   assigns 0x0001 through 0x0008 and 0x00FD and 0x00FE.  Certificate
+   types 0x0100 through 0xFEFF are assigned through IETF Consensus [6]
+   based on RFC documentation of the certificate type.  The availability
+   of private types under 0x00FD and 0x00FE ought to satisfy most
+   requirements for proprietary or private types.
+
+   The CERT RR reuses the DNS Security Algorithm Numbers registry.  In
+   particular, the CERT RR requires that algorithm number 0 remain
+   reserved, as described in Section 2.  The IANA will reference the
+   CERT RR as a user of this registry and value 0, in particular.
+
+9.  Changes since RFC 2538
+
+   1.   Editorial changes to conform with new document requirements,
+        including splitting reference section into two parts and
+        updating the references to point at latest versions, and to add
+        some additional references.
+   2.   Improve terminology.  For example replace "PGP" with "OpenPGP",
+        to align with RFC 2440.
+   3.   In Section 2.1, clarify that OpenPGP public key data are binary,
+        not the ASCII armored format, and reference 10.1 in RFC 2440 on
+        how to deal with OpenPGP keys, and acknowledge that
+        implementations may handle additional packet types.
+   4.   Clarify that integers in the representation format are decimal.
+   5.   Replace KEY/SIG with DNSKEY/RRSIG etc, to align with DNSSECbis
+        terminology.  Improve reference for Key Tag Algorithm
+        calculations.
+   6.   Add examples that suggest use of CNAME to reduce bandwidth.
+   7.   In Section 3, appended the last paragraphs that discuss
+        "content-based" vs "purpose-based" owner names.  Add Section 3.2
+        for purpose-based X.509 CERT owner names, and Section 3.4 for
+        purpose-based OpenPGP CERT owner names.
+   8.   Added size considerations.
+   9.   The SPKI types has been reserved, until RFC 2692/2693 is moved
+        from the experimental status.
+   10.  Added indirect types IPKIX, ISPKI, IPGP, and IACPKIX.
+
+
+
+Josefsson                   Standards Track                    [Page 13]
+
+RFC 4398            Storing Certificates in the DNS        February 2006
+
+
+   11.  An IANA registry of CERT type values was created.
+
+10.  References
+
+10.1.  Normative References
+
+   [1]   Mockapetris, P., "Domain names - concepts and facilities",
+         STD 13, RFC 1034, November 1987.
+
+   [2]   Mockapetris, P., "Domain names - implementation and
+         specification", STD 13, RFC 1035, November 1987.
+
+   [3]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
+         Levels", BCP 14, RFC 2119, March 1997.
+
+   [4]   Kille, S., Wahl, M., Grimstad, A., Huber, R., and S. Sataluri,
+         "Using Domains in LDAP/X.500 Distinguished Names", RFC 2247,
+         January 1998.
+
+   [5]   Callas, J., Donnerhacke, L., Finney, H., and R. Thayer,
+         "OpenPGP Message Format", RFC 2440, November 1998.
+
+   [6]   Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
+         Considerations Section in RFCs", BCP 26, RFC 2434,
+         October 1998.
+
+   [7]   Resnick, P., "Internet Message Format", RFC 2822, April 2001.
+
+   [8]   Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509
+         Public Key Infrastructure Certificate and Certificate
+         Revocation List (CRL) Profile", RFC 3280, April 2002.
+
+   [9]   Farrell, S. and R. Housley, "An Internet Attribute Certificate
+         Profile for Authorization", RFC 3281, April 2002.
+
+   [10]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
+         Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986,
+         January 2005.
+
+   [11]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+         "DNS Security Introduction and Requirements", RFC 4033,
+         March 2005.
+
+   [12]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+         "Resource Records for the DNS Security Extensions", RFC 4034,
+         March 2005.
+
+
+
+
+
+Josefsson                   Standards Track                    [Page 14]
+
+RFC 4398            Storing Certificates in the DNS        February 2006
+
+
+10.2.  Informative References
+
+   [13]  Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
+         RFC 2246, January 1999.
+
+   [14]  Kent, S. and K. Seo, "Security Architecture for the Internet
+         Protocol", RFC 4301, December 2005.
+
+   [15]  Ellison, C., Frantz, B., Lampson, B., Rivest, R., Thomas, B.,
+         and T. Ylonen, "SPKI Certificate Theory", RFC 2693,
+         September 1999.
+
+   [16]  Josefsson, S., "The Base16, Base32, and Base64 Data Encodings",
+         RFC 3548, July 2003.
+
+   [17]  Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions
+         (S/MIME) Version 3.1 Message Specification", RFC 3851,
+         July 2004.
+
+   [18]  Richardson, M., "A Method for Storing IPsec Keying Material in
+         DNS", RFC 4025, March 2005.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Josefsson                   Standards Track                    [Page 15]
+
+RFC 4398            Storing Certificates in the DNS        February 2006
+
+
+Appendix A.  Copying Conditions
+
+   Regarding the portion of this document that was written by Simon
+   Josefsson ("the author", for the remainder of this section), the
+   author makes no guarantees and is not responsible for any damage
+   resulting from its use.  The author grants irrevocable permission to
+   anyone to use, modify, and distribute it in any way that does not
+   diminish the rights of anyone else to use, modify, and distribute it,
+   provided that redistributed derivative works do not contain
+   misleading author or version information.  Derivative works need not
+   be licensed under similar terms.
+
+Author's Address
+
+   Simon Josefsson
+
+   EMail: simon@josefsson.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Josefsson                   Standards Track                    [Page 16]
+
+RFC 4398            Storing Certificates in the DNS        February 2006
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2006).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Josefsson                   Standards Track                    [Page 17]
+
diff --git a/doc/rfc/rfc4408.txt b/doc/rfc/rfc4408.txt
new file mode 100644
index 0000000..bc1b3f5
--- /dev/null
+++ b/doc/rfc/rfc4408.txt
@@ -0,0 +1,2691 @@
+
+
+
+
+
+
+Network Working Group                                            M. Wong
+Request for Comments: 4408                                    W. Schlitt
+Category: Experimental                                        April 2006
+
+
+                   Sender Policy Framework (SPF) for
+            Authorizing Use of Domains in E-Mail, Version 1
+
+Status of This Memo
+
+   This memo defines an Experimental Protocol for the Internet
+   community.  It does not specify an Internet standard of any kind.
+   Discussion and suggestions for improvement are requested.
+   Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+IESG Note
+
+   The following documents  (RFC 4405, RFC 4406, RFC 4407, and RFC 4408)
+   are published simultaneously as Experimental RFCs, although there is
+   no general technical consensus and efforts to reconcile the two
+   approaches have failed.  As such, these documents have not received
+   full IETF review and are published "AS-IS" to document the different
+   approaches as they were considered in the MARID working group.
+
+   The IESG takes no position about which approach is to be preferred
+   and cautions the reader that there are serious open issues for each
+   approach and concerns about using them in tandem.  The IESG believes
+   that documenting the different approaches does less harm than not
+   documenting them.
+
+   Note that the Sender ID experiment may use DNS records that may have
+   been created for the current SPF experiment or earlier versions in
+   this set of experiments.  Depending on the content of the record,
+   this may mean that Sender-ID heuristics would be applied incorrectly
+   to a message.  Depending on the actions associated by the recipient
+   with those heuristics, the message may not be delivered or may be
+   discarded on receipt.
+
+   Participants relying on Sender ID experiment DNS records are warned
+   that they may lose valid messages in this set of circumstances.
+   aParticipants publishing SPF experiment DNS records should consider
+   the advice given in section 3.4 of RFC 4406 and may wish to publish
+   both v=spf1 and spf2.0 records to avoid the conflict.
+
+
+
+
+Wong & Schlitt                Experimental                      [Page 1]
+
+RFC 4408             Sender Policy Framework (SPF)            April 2006
+
+
+   Participants in the Sender-ID experiment need to be aware that the
+   way Resent-* header fields are used will result in failure to receive
+   legitimate email when interacting with standards-compliant systems
+   (specifically automatic forwarders which comply with the standards by
+   not adding Resent-* headers, and systems which comply with RFC 822
+   but have not yet implemented RFC 2822 Resent-* semantics).  It would
+   be inappropriate to advance Sender-ID on the standards track without
+   resolving this interoperability problem.
+
+   The community is invited to observe the success or failure of the two
+   approaches during the two years following publication, in order that
+   a community consensus can be reached in the future.
+
+Abstract
+
+   E-mail on the Internet can be forged in a number of ways.  In
+   particular, existing protocols place no restriction on what a sending
+   host can use as the reverse-path of a message or the domain given on
+   the SMTP HELO/EHLO commands.  This document describes version 1 of
+   the Sender Policy Framework (SPF) protocol, whereby a domain may
+   explicitly authorize the hosts that are allowed to use its domain
+   name, and a receiving host may check such authorization.
+
+Table of Contents
+
+   1. Introduction ....................................................4
+      1.1. Protocol Status ............................................4
+      1.2. Terminology ................................................5
+   2. Operation .......................................................5
+      2.1. The HELO Identity ..........................................5
+      2.2. The MAIL FROM Identity .....................................5
+      2.3. Publishing Authorization ...................................6
+      2.4. Checking Authorization .....................................6
+      2.5. Interpreting the Result ....................................7
+           2.5.1. None ................................................8
+           2.5.2. Neutral .............................................8
+           2.5.3. Pass ................................................8
+           2.5.4. Fail ................................................8
+           2.5.5. SoftFail ............................................9
+           2.5.6. TempError ...........................................9
+           2.5.7. PermError ...........................................9
+   3. SPF Records .....................................................9
+      3.1. Publishing ................................................10
+           3.1.1. DNS Resource Record Types ..........................10
+           3.1.2. Multiple DNS Records ...............................11
+           3.1.3. Multiple Strings in a Single DNS record ............11
+           3.1.4. Record Size ........................................11
+           3.1.5. Wildcard Records ...................................11
+
+
+
+Wong & Schlitt                Experimental                      [Page 2]
+
+RFC 4408             Sender Policy Framework (SPF)            April 2006
+
+
+   4. The check_host() Function ......................................12
+      4.1. Arguments .................................................12
+      4.2. Results ...................................................13
+      4.3. Initial Processing ........................................13
+      4.4. Record Lookup .............................................13
+      4.5. Selecting Records .........................................13
+      4.6. Record Evaluation .........................................14
+           4.6.1. Term Evaluation ....................................14
+           4.6.2. Mechanisms .........................................15
+           4.6.3. Modifiers ..........................................15
+      4.7. Default Result ............................................16
+      4.8. Domain Specification ......................................16
+   5. Mechanism Definitions ..........................................16
+      5.1. "all" .....................................................17
+      5.2. "include" .................................................18
+      5.3. "a" .......................................................19
+      5.4. "mx" ......................................................20
+      5.5. "ptr" .....................................................20
+      5.6. "ip4" and "ip6" ...........................................21
+      5.7. "exists" ..................................................22
+   6. Modifier Definitions ...........................................22
+      6.1. redirect: Redirected Query ................................23
+      6.2. exp: Explanation ..........................................23
+   7. The Received-SPF Header Field ..................................25
+   8. Macros .........................................................27
+      8.1. Macro Definitions .........................................27
+      8.2. Expansion Examples ........................................30
+   9. Implications ...................................................31
+      9.1. Sending Domains ...........................................31
+      9.2. Mailing Lists .............................................32
+      9.3. Forwarding Services and Aliases ...........................32
+      9.4. Mail Services .............................................34
+      9.5. MTA Relays ................................................34
+   10. Security Considerations .......................................35
+      10.1. Processing Limits ........................................35
+      10.2. SPF-Authorized E-Mail May Contain Other False
+            Identities ...............................................37
+      10.3. Spoofed DNS and IP Data ..................................37
+      10.4. Cross-User Forgery .......................................37
+      10.5. Untrusted Information Sources ............................38
+      10.6. Privacy Exposure .........................................38
+   11. Contributors and Acknowledgements .............................38
+   12. IANA Considerations ...........................................39
+      12.1. The SPF DNS Record Type ..................................39
+      12.2. The Received-SPF Mail Header Field .......................39
+   13. References ....................................................39
+      13.1. Normative References .....................................39
+      13.2. Informative References ...................................40
+
+
+
+Wong & Schlitt                Experimental                      [Page 3]
+
+RFC 4408             Sender Policy Framework (SPF)            April 2006
+
+
+   Appendix A.  Collected ABNF .......................................42
+   Appendix B.  Extended Examples ....................................44
+      B.1.  Simple Examples ..........................................44
+      B.2.  Multiple Domain Example ..................................45
+      B.3.  DNSBL Style Example ......................................46
+      B.4.  Multiple Requirements Example ............................46
+
+1.  Introduction
+
+   The current E-Mail infrastructure has the property that any host
+   injecting mail into the mail system can identify itself as any domain
+   name it wants.  Hosts can do this at a variety of levels: in
+   particular, the session, the envelope, and the mail headers.
+   Although this feature is desirable in some circumstances, it is a
+   major obstacle to reducing Unsolicited Bulk E-Mail (UBE, aka spam).
+   Furthermore, many domain name holders are understandably concerned
+   about the ease with which other entities may make use of their domain
+   names, often with malicious intent.
+
+   This document defines a protocol by which domain owners may authorize
+   hosts to use their domain name in the "MAIL FROM" or "HELO" identity.
+   Compliant domain holders publish Sender Policy Framework (SPF)
+   records specifying which hosts are permitted to use their names, and
+   compliant mail receivers use the published SPF records to test the
+   authorization of sending Mail Transfer Agents (MTAs) using a given
+   "HELO" or "MAIL FROM" identity during a mail transaction.
+
+   An additional benefit to mail receivers is that after the use of an
+   identity is verified, local policy decisions about the mail can be
+   made based on the sender's domain, rather than the host's IP address.
+   This is advantageous because reputation of domain names is likely to
+   be more accurate than reputation of host IP addresses.  Furthermore,
+   if a claimed identity fails verification, local policy can take
+   stronger action against such E-Mail, such as rejecting it.
+
+1.1.  Protocol Status
+
+   SPF has been in development since the summer of 2003 and has seen
+   deployment beyond the developers beginning in December 2003.  The
+   design of SPF slowly evolved until the spring of 2004 and has since
+   stabilized.  There have been quite a number of forms of SPF, some
+   written up as documents, some submitted as Internet Drafts, and many
+   discussed and debated in development forums.
+
+   The goal of this document is to clearly document the protocol defined
+   by earlier draft specifications of SPF as used in existing
+   implementations.  This conception of SPF is sometimes called "SPF
+   Classic".  It is understood that particular implementations and
+
+
+
+Wong & Schlitt                Experimental                      [Page 4]
+
+RFC 4408             Sender Policy Framework (SPF)            April 2006
+
+
+   deployments may differ from, and build upon, this work.  It is hoped
+   that we have nonetheless captured the common understanding of SPF
+   version 1.
+
+1.2.  Terminology
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC2119].
+
+   This document is concerned with the portion of a mail message
+   commonly called "envelope sender", "return path", "reverse path",
+   "bounce address", "2821 FROM", or "MAIL FROM".  Since these terms are
+   either not well defined or often used casually, this document defines
+   the "MAIL FROM" identity in Section 2.2.  Note that other terms that
+   may superficially look like the common terms, such as "reverse-path",
+   are used only with the defined meanings from normative documents.
+
+2.  Operation
+
+2.1.  The HELO Identity
+
+   The "HELO" identity derives from either the SMTP HELO or EHLO command
+   (see [RFC2821]).  These commands supply the SMTP client (sending
+   host) for the SMTP session.  Note that requirements for the domain
+   presented in the EHLO or HELO command are not always clear to the
+   sending party, and SPF clients must be prepared for the "HELO"
+   identity to be malformed or an IP address literal.  At the time of
+   this writing, many legitimate E-Mails are delivered with invalid HELO
+   domains.
+
+   It is RECOMMENDED that SPF clients not only check the "MAIL FROM"
+   identity, but also separately check the "HELO" identity by applying
+   the check_host() function (Section 4) to the "HELO" identity as the
+   <sender>.
+
+2.2.  The MAIL FROM Identity
+
+   The "MAIL FROM" identity derives from the SMTP MAIL command (see
+   [RFC2821]).  This command supplies the "reverse-path" for a message,
+   which generally consists of the sender mailbox, and is the mailbox to
+   which notification messages are to be sent if there are problems
+   delivering the message.
+
+   [RFC2821] allows the reverse-path to be null (see Section 4.5.5 in
+   RFC 2821).  In this case, there is no explicit sender mailbox, and
+   such a message can be assumed to be a notification message from the
+   mail system itself.  When the reverse-path is null, this document
+
+
+
+Wong & Schlitt                Experimental                      [Page 5]
+
+RFC 4408             Sender Policy Framework (SPF)            April 2006
+
+
+   defines the "MAIL FROM" identity to be the mailbox composed of the
+   localpart "postmaster" and the "HELO" identity (which may or may not
+   have been checked separately before).
+
+   SPF clients MUST check the "MAIL FROM" identity.  SPF clients check
+   the "MAIL FROM" identity by applying the check_host() function to the
+   "MAIL FROM" identity as the <sender>.
+
+2.3.  Publishing Authorization
+
+   An SPF-compliant domain MUST publish a valid SPF record as described
+   in Section 3.  This record authorizes the use of the domain name in
+   the "HELO" and "MAIL FROM" identities by the MTAs it specifies.
+
+   If domain owners choose to publish SPF records, it is RECOMMENDED
+   that they end in "-all", or redirect to other records that do, so
+   that a definitive determination of authorization can be made.
+
+   Domain holders may publish SPF records that explicitly authorize no
+   hosts if mail should never originate using that domain.
+
+   When changing SPF records, care must be taken to ensure that there is
+   a transition period so that the old policy remains valid until all
+   legitimate E-Mail has been checked.
+
+2.4.  Checking Authorization
+
+   A mail receiver can perform a set of SPF checks for each mail message
+   it receives.  An SPF check tests the authorization of a client host
+   to emit mail with a given identity.  Typically, such checks are done
+   by a receiving MTA, but can be performed elsewhere in the mail
+   processing chain so long as the required information is available and
+   reliable.  At least the "MAIL FROM" identity MUST be checked, but it
+   is RECOMMENDED that the "HELO" identity also be checked beforehand.
+
+   Without explicit approval of the domain owner, checking other
+   identities against SPF version 1 records is NOT RECOMMENDED because
+   there are cases that are known to give incorrect results.  For
+   example, almost all mailing lists rewrite the "MAIL FROM" identity
+   (see Section 9.2), but some do not change any other identities in the
+   message.  The scenario described in Section 9.3, sub-section 1.2, is
+   another example.  Documents that define other identities should
+   define the method for explicit approval.
+
+   It is possible that mail receivers will use the SPF check as part of
+   a larger set of tests on incoming mail.  The results of other tests
+   may influence whether or not a particular SPF check is performed.
+   For example, finding the sending host's IP address on a local white
+
+
+
+Wong & Schlitt                Experimental                      [Page 6]
+
+RFC 4408             Sender Policy Framework (SPF)            April 2006
+
+
+   list may cause all other tests to be skipped and all mail from that
+   host to be accepted.
+
+   When a mail receiver decides to perform an SPF check, it MUST use a
+   correctly-implemented check_host() function (Section 4) evaluated
+   with the correct parameters.  Although the test as a whole is
+   optional, once it has been decided to perform a test it must be
+   performed as specified so that the correct semantics are preserved
+   between publisher and receiver.
+
+   To make the test, the mail receiver MUST evaluate the check_host()
+   function with the arguments set as follows:
+
+   <ip>     - the IP address of the SMTP client that is emitting the
+              mail, either IPv4 or IPv6.
+
+   <domain> - the domain portion of the "MAIL FROM" or "HELO" identity.
+
+   <sender> - the "MAIL FROM" or "HELO" identity.
+
+   Note that the <domain> argument may not be a well-formed domain name.
+   For example, if the reverse-path was null, then the EHLO/HELO domain
+   is used, with its associated problems (see Section 2.1).  In these
+   cases, check_host() is defined in Section 4.3 to return a "None"
+   result.
+
+   Although invalid, malformed, or non-existent domains cause SPF checks
+   to return "None" because no SPF record can be found, it has long been
+   the policy of many MTAs to reject E-Mail from such domains,
+   especially in the case of invalid "MAIL FROM".  In order to prevent
+   the circumvention of SPF records, rejecting E-Mail from invalid
+   domains should be considered.
+
+   Implementations must take care to correctly extract the <domain> from
+   the data given with the SMTP MAIL FROM command as many MTAs will
+   still accept such things as source routes (see [RFC2821], Appendix
+   C), the %-hack (see [RFC1123]), and bang paths (see [RFC1983]).
+   These archaic features have been maliciously used to bypass security
+   systems.
+
+2.5.  Interpreting the Result
+
+   This section describes how software that performs the authorization
+   should interpret the results of the check_host() function.  The
+   authorization check SHOULD be performed during the processing of the
+   SMTP transaction that sends the mail.  This allows errors to be
+   returned directly to the sending MTA by way of SMTP replies.
+
+
+
+
+Wong & Schlitt                Experimental                      [Page 7]
+
+RFC 4408             Sender Policy Framework (SPF)            April 2006
+
+
+   Performing the authorization after the SMTP transaction has finished
+   may cause problems, such as the following: (1) It may be difficult to
+   accurately extract the required information from potentially
+   deceptive headers; (2) legitimate E-Mail may fail because the
+   sender's policy may have since changed.
+
+   Generating non-delivery notifications to forged identities that have
+   failed the authorization check is generally abusive and against the
+   explicit wishes of the identity owner.
+
+2.5.1.  None
+
+   A result of "None" means that no records were published by the domain
+   or that no checkable sender domain could be determined from the given
+   identity.  The checking software cannot ascertain whether or not the
+   client host is authorized.
+
+2.5.2.  Neutral
+
+   The domain owner has explicitly stated that he cannot or does not
+   want to assert whether or not the IP address is authorized.  A
+   "Neutral" result MUST be treated exactly like the "None" result; the
+   distinction exists only for informational purposes.  Treating
+   "Neutral" more harshly than "None" would discourage domain owners
+   from testing the use of SPF records (see Section 9.1).
+
+2.5.3.  Pass
+
+   A "Pass" result means that the client is authorized to inject mail
+   with the given identity.  The domain can now, in the sense of
+   reputation, be considered responsible for sending the message.
+   Further policy checks can now proceed with confidence in the
+   legitimate use of the identity.
+
+2.5.4.  Fail
+
+   A "Fail" result is an explicit statement that the client is not
+   authorized to use the domain in the given identity.  The checking
+   software can choose to mark the mail based on this or to reject the
+   mail outright.
+
+   If the checking software chooses to reject the mail during the SMTP
+   transaction, then it SHOULD use an SMTP reply code of 550 (see
+   [RFC2821]) and, if supported, the 5.7.1 Delivery Status Notification
+   (DSN) code (see [RFC3464]), in addition to an appropriate reply text.
+   The check_host() function may return either a default explanation
+   string or one from the domain that published the SPF records (see
+   Section 6.2).  If the information does not originate with the
+
+
+
+Wong & Schlitt                Experimental                      [Page 8]
+
+RFC 4408             Sender Policy Framework (SPF)            April 2006
+
+
+   checking software, it should be made clear that the text is provided
+   by the sender's domain.  For example:
+
+       550-5.7.1 SPF MAIL FROM check failed:
+       550-5.7.1 The domain example.com explains:
+       550 5.7.1 Please see http://www.example.com/mailpolicy.html
+
+2.5.5.  SoftFail
+
+   A "SoftFail" result should be treated as somewhere between a "Fail"
+   and a "Neutral".  The domain believes the host is not authorized but
+   is not willing to make that strong of a statement.  Receiving
+   software SHOULD NOT reject the message based solely on this result,
+   but MAY subject the message to closer scrutiny than normal.
+
+   The domain owner wants to discourage the use of this host and thus
+   desires limited feedback when a "SoftFail" result occurs.  For
+   example, the recipient's Mail User Agent (MUA) could highlight the
+   "SoftFail" status, or the receiving MTA could give the sender a
+   message using a technique called "greylisting" whereby the MTA can
+   issue an SMTP reply code of 451 (4.3.0 DSN code) with a note the
+   first time the message is received, but accept it the second time.
+
+2.5.6.  TempError
+
+   A "TempError" result means that the SPF client encountered a
+   transient error while performing the check.  Checking software can
+   choose to accept or temporarily reject the message.  If the message
+   is rejected during the SMTP transaction for this reason, the software
+   SHOULD use an SMTP reply code of 451 and, if supported, the 4.4.3 DSN
+   code.
+
+2.5.7.  PermError
+
+   A "PermError" result means that the domain's published records could
+   not be correctly interpreted.  This signals an error condition that
+   requires manual intervention to be resolved, as opposed to the
+   TempError result.  Be aware that if the domain owner uses macros
+   (Section 8), it is possible that this result is due to the checked
+   identities having an unexpected format.
+
+3.  SPF Records
+
+   An SPF record is a DNS Resource Record (RR) that declares which hosts
+   are, and are not, authorized to use a domain name for the "HELO" and
+   "MAIL FROM" identities.  Loosely, the record partitions all hosts
+   into permitted and not-permitted sets (though some hosts might fall
+   into neither category).
+
+
+
+Wong & Schlitt                Experimental                      [Page 9]
+
+RFC 4408             Sender Policy Framework (SPF)            April 2006
+
+
+   The SPF record is a single string of text.  An example record is the
+   following:
+
+      v=spf1 +mx a:colo.example.com/28 -all
+
+   This record has a version of "spf1" and three directives: "+mx",
+   "a:colo.example.com/28" (the + is implied), and "-all".
+
+3.1.  Publishing
+
+   Domain owners wishing to be SPF compliant must publish SPF records
+   for the hosts that are used in the "MAIL FROM" and "HELO" identities.
+   The SPF records are placed in the DNS tree at the host name it
+   pertains to, not a subdomain under it, such as is done with SRV
+   records.  This is the same whether the TXT or SPF RR type (see
+   Section 3.1.1) is used.
+
+   The example above in Section 3 might be published via these lines in
+   a domain zone file:
+
+      example.com.          TXT "v=spf1 +mx a:colo.example.com/28 -all"
+      smtp-out.example.com. TXT "v=spf1 a -all"
+
+   When publishing via TXT records, beware of other TXT records
+   published there for other purposes.  They may cause problems with
+   size limits (see Section 3.1.4).
+
+3.1.1.  DNS Resource Record Types
+
+   This document defines a new DNS RR of type SPF, code 99.  The format
+   of this type is identical to the TXT RR [RFC1035].  For either type,
+   the character content of the record is encoded as [US-ASCII].
+
+   It is recognized that the current practice (using a TXT record) is
+   not optimal, but it is necessary because there are a number of DNS
+   server and resolver implementations in common use that cannot handle
+   the new RR type.  The two-record-type scheme provides a forward path
+   to the better solution of using an RR type reserved for this purpose.
+
+   An SPF-compliant domain name SHOULD have SPF records of both RR
+   types.  A compliant domain name MUST have a record of at least one
+   type.  If a domain has records of both types, they MUST have
+   identical content.  For example, instead of publishing just one
+   record as in Section 3.1 above, it is better to publish:
+
+      example.com. IN TXT "v=spf1 +mx a:colo.example.com/28 -all"
+      example.com. IN SPF "v=spf1 +mx a:colo.example.com/28 -all"
+
+
+
+
+Wong & Schlitt                Experimental                     [Page 10]
+
+RFC 4408             Sender Policy Framework (SPF)            April 2006
+
+
+   Example RRs in this document are shown with the TXT record type;
+   however, they could be published with the SPF type or with both
+   types.
+
+3.1.2.  Multiple DNS Records
+
+   A domain name MUST NOT have multiple records that would cause an
+   authorization check to select more than one record.  See Section 4.5
+   for the selection rules.
+
+3.1.3.  Multiple Strings in a Single DNS record
+
+   As defined in [RFC1035] sections 3.3.14 and 3.3, a single text DNS
+   record (either TXT or SPF RR types) can be composed of more than one
+   string.  If a published record contains multiple strings, then the
+   record MUST be treated as if those strings are concatenated together
+   without adding spaces.  For example:
+
+      IN TXT "v=spf1 .... first" "second string..."
+
+   MUST be treated as equivalent to
+
+      IN TXT "v=spf1 .... firstsecond string..."
+
+   SPF or TXT records containing multiple strings are useful in
+   constructing records that would exceed the 255-byte maximum length of
+   a string within a single TXT or SPF RR record.
+
+3.1.4.  Record Size
+
+   The published SPF record for a given domain name SHOULD remain small
+   enough that the results of a query for it will fit within 512 octets.
+   This will keep even older DNS implementations from falling over to
+   TCP.  Since the answer size is dependent on many things outside the
+   scope of this document, it is only possible to give this guideline:
+   If the combined length of the DNS name and the text of all the
+   records of a given type (TXT or SPF) is under 450 characters, then
+   DNS answers should fit in UDP packets.  Note that when computing the
+   sizes for queries of the TXT format, one must take into account any
+   other TXT records published at the domain name.  Records that are too
+   long to fit in a single UDP packet MAY be silently ignored by SPF
+   clients.
+
+3.1.5.  Wildcard Records
+
+   Use of wildcard records for publishing is not recommended.  Care must
+   be taken if wildcard records are used.  If a domain publishes
+   wildcard MX records, it may want to publish wildcard declarations,
+
+
+
+Wong & Schlitt                Experimental                     [Page 11]
+
+RFC 4408             Sender Policy Framework (SPF)            April 2006
+
+
+   subject to the same requirements and problems.  In particular, the
+   declaration must be repeated for any host that has any RR records at
+   all, and for subdomains thereof.  For example, the example given in
+   [RFC1034], Section 4.3.3, could be extended with the following:
+
+       X.COM.          MX      10      A.X.COM
+       X.COM.          TXT     "v=spf1 a:A.X.COM -all"
+
+       *.X.COM.        MX      10      A.X.COM
+       *.X.COM.        TXT     "v=spf1 a:A.X.COM -all"
+
+       A.X.COM.        A       1.2.3.4
+       A.X.COM.        MX      10      A.X.COM
+       A.X.COM.        TXT     "v=spf1 a:A.X.COM -all"
+
+       *.A.X.COM.      MX      10      A.X.COM
+       *.A.X.COM.      TXT     "v=spf1 a:A.X.COM -all"
+
+   Notice that SPF records must be repeated twice for every name within
+   the domain: once for the name, and once with a wildcard to cover the
+   tree under the name.
+
+   Use of wildcards is discouraged in general as they cause every name
+   under the domain to exist and queries against arbitrary names will
+   never return RCODE 3 (Name Error).
+
+4.  The check_host() Function
+
+   The check_host() function fetches SPF records, parses them, and
+   interprets them to determine whether a particular host is or is not
+   permitted to send mail with a given identity.  Mail receivers that
+   perform this check MUST correctly evaluate the check_host() function
+   as described here.
+
+   Implementations MAY use a different algorithm than the canonical
+   algorithm defined here, so long as the results are the same in all
+   cases.
+
+4.1.  Arguments
+
+   The check_host() function takes these arguments:
+
+   <ip>     - the IP address of the SMTP client that is emitting the
+              mail, either IPv4 or IPv6.
+
+   <domain> - the domain that provides the sought-after authorization
+              information; initially, the domain portion of the "MAIL
+              FROM" or "HELO" identity.
+
+
+
+Wong & Schlitt                Experimental                     [Page 12]
+
+RFC 4408             Sender Policy Framework (SPF)            April 2006
+
+
+   <sender> - the "MAIL FROM" or "HELO" identity.
+
+   The domain portion of <sender> will usually be the same as the
+   <domain> argument when check_host() is initially evaluated.  However,
+   this will generally not be true for recursive evaluations (see
+   Section 5.2 below).
+
+   Actual implementations of the check_host() function may need
+   additional arguments.
+
+4.2.  Results
+
+   The function check_host() can return one of several results described
+   in Section 2.5.  Based on the result, the action to be taken is
+   determined by the local policies of the receiver.
+
+4.3.  Initial Processing
+
+   If the <domain> is malformed (label longer than 63 characters, zero-
+   length label not at the end, etc.) or is not a fully qualified domain
+   name, or if the DNS lookup returns "domain does not exist" (RCODE 3),
+   check_host() immediately returns the result "None".
+
+   If the <sender> has no localpart, substitute the string "postmaster"
+   for the localpart.
+
+4.4.  Record Lookup
+
+   In accordance with how the records are published (see Section 3.1
+   above), a DNS query needs to be made for the <domain> name, querying
+   for either RR type TXT, SPF, or both.  If both SPF and TXT RRs are
+   looked up, the queries MAY be done in parallel.
+
+   If all DNS lookups that are made return a server failure (RCODE 2),
+   or other error (RCODE other than 0 or 3), or time out, then
+   check_host() exits immediately with the result "TempError".
+
+4.5.  Selecting Records
+
+   Records begin with a version section:
+
+   record           = version terms *SP
+   version          = "v=spf1"
+
+   Starting with the set of records that were returned by the lookup,
+   record selection proceeds in two steps:
+
+
+
+
+
+Wong & Schlitt                Experimental                     [Page 13]
+
+RFC 4408             Sender Policy Framework (SPF)            April 2006
+
+
+   1. Records that do not begin with a version section of exactly
+      "v=spf1" are discarded.  Note that the version section is
+      terminated either by an SP character or the end of the record.  A
+      record with a version section of "v=spf10" does not match and must
+      be discarded.
+
+   2. If any records of type SPF are in the set, then all records of
+      type TXT are discarded.
+
+   After the above steps, there should be exactly one record remaining
+   and evaluation can proceed.  If there are two or more records
+   remaining, then check_host() exits immediately with the result of
+   "PermError".
+
+   If no matching records are returned, an SPF client MUST assume that
+   the domain makes no SPF declarations.  SPF processing MUST stop and
+   return "None".
+
+4.6.  Record Evaluation
+
+   After one SPF record has been selected, the check_host() function
+   parses and interprets it to find a result for the current test.  If
+   there are any syntax errors, check_host() returns immediately with
+   the result "PermError".
+
+   Implementations MAY choose to parse the entire record first and
+   return "PermError" if the record is not syntactically well formed.
+   However, in all cases, any syntax errors anywhere in the record MUST
+   be detected.
+
+4.6.1.  Term Evaluation
+
+   There are two types of terms: mechanisms and modifiers.  A record
+   contains an ordered list of these as specified in the following
+   Augmented Backus-Naur Form (ABNF).
+
+   terms            = *( 1*SP ( directive / modifier ) )
+
+   directive        = [ qualifier ] mechanism
+   qualifier        = "+" / "-" / "?" / "~"
+   mechanism        = ( all / include
+                      / A / MX / PTR / IP4 / IP6 / exists )
+   modifier         = redirect / explanation / unknown-modifier
+   unknown-modifier = name "=" macro-string
+
+   name             = ALPHA *( ALPHA / DIGIT / "-" / "_" / "." )
+
+   Most mechanisms allow a ":" or "/" character after the name.
+
+
+
+Wong & Schlitt                Experimental                     [Page 14]
+
+RFC 4408             Sender Policy Framework (SPF)            April 2006
+
+
+   Modifiers always contain an equals ('=') character immediately after
+   the name, and before any ":" or "/" characters that may be part of
+   the macro-string.
+
+   Terms that do not contain any of "=", ":", or "/" are mechanisms, as
+   defined in Section 5.
+
+   As per the definition of the ABNF notation in [RFC4234], mechanism
+   and modifier names are case-insensitive.
+
+4.6.2.  Mechanisms
+
+   Each mechanism is considered in turn from left to right.  If there
+   are no more mechanisms, the result is specified in Section 4.7.
+
+   When a mechanism is evaluated, one of three things can happen: it can
+   match, not match, or throw an exception.
+
+   If it matches, processing ends and the qualifier value is returned as
+   the result of that record.  If it does not match, processing
+   continues with the next mechanism.  If it throws an exception,
+   mechanism processing ends and the exception value is returned.
+
+   The possible qualifiers, and the results they return are as follows:
+
+      "+" Pass
+      "-" Fail
+      "~" SoftFail
+      "?" Neutral
+
+   The qualifier is optional and defaults to "+".
+
+   When a mechanism matches and the qualifier is "-", then a "Fail"
+   result is returned and the explanation string is computed as
+   described in Section 6.2.
+
+   The specific mechanisms are described in Section 5.
+
+4.6.3.  Modifiers
+
+   Modifiers are not mechanisms: they do not return match or not-match.
+   Instead they provide additional information.  Although modifiers do
+   not directly affect the evaluation of the record, the "redirect"
+   modifier has an effect after all the mechanisms have been evaluated.
+
+
+
+
+
+
+
+Wong & Schlitt                Experimental                     [Page 15]
+
+RFC 4408             Sender Policy Framework (SPF)            April 2006
+
+
+4.7.  Default Result
+
+   If none of the mechanisms match and there is no "redirect" modifier,
+   then the check_host() returns a result of "Neutral", just as if
+   "?all" were specified as the last directive.  If there is a
+   "redirect" modifier, check_host() proceeds as defined in Section 6.1.
+
+   Note that records SHOULD always use either a "redirect" modifier or
+   an "all" mechanism to explicitly terminate processing.
+
+   For example:
+
+      v=spf1 +mx -all
+   or
+      v=spf1 +mx redirect=_spf.example.com
+
+4.8.  Domain Specification
+
+   Several of these mechanisms and modifiers have a <domain-spec>
+   section.  The <domain-spec> string is macro expanded (see Section 8).
+   The resulting string is the common presentation form of a fully-
+   qualified DNS name: a series of labels separated by periods.  This
+   domain is called the <target-name> in the rest of this document.
+
+   Note: The result of the macro expansion is not subject to any further
+   escaping.  Hence, this facility cannot produce all characters that
+   are legal in a DNS label (e.g., the control characters).  However,
+   this facility is powerful enough to express legal host names and
+   common utility labels (such as "_spf") that are used in DNS.
+
+   For several mechanisms, the <domain-spec> is optional.  If it is not
+   provided, the <domain> is used as the <target-name>.
+
+5.  Mechanism Definitions
+
+   This section defines two types of mechanisms.
+
+   Basic mechanisms contribute to the language framework.  They do not
+   specify a particular type of authorization scheme.
+
+      all
+      include
+
+   Designated sender mechanisms are used to designate a set of <ip>
+   addresses as being permitted or not permitted to use the <domain> for
+   sending mail.
+
+
+
+
+
+Wong & Schlitt                Experimental                     [Page 16]
+
+RFC 4408             Sender Policy Framework (SPF)            April 2006
+
+
+      a
+      mx
+      ptr
+      ip4
+      ip6
+      exists
+
+   The following conventions apply to all mechanisms that perform a
+   comparison between <ip> and an IP address at any point:
+
+   If no CIDR-length is given in the directive, then <ip> and the IP
+   address are compared for equality. (Here, CIDR is Classless Inter-
+   Domain Routing.)
+
+   If a CIDR-length is specified, then only the specified number of
+   high-order bits of <ip> and the IP address are compared for equality.
+
+   When any mechanism fetches host addresses to compare with <ip>, when
+   <ip> is an IPv4 address, A records are fetched, when <ip> is an IPv6
+   address, AAAA records are fetched.  Even if the SMTP connection is
+   via IPv6, an IPv4-mapped IPv6 IP address (see [RFC3513], Section
+   2.5.5) MUST still be considered an IPv4 address.
+
+   Several mechanisms rely on information fetched from DNS.  For these
+   DNS queries, except where noted, if the DNS server returns an error
+   (RCODE other than 0 or 3) or the query times out, the mechanism
+   throws the exception "TempError".  If the server returns "domain does
+   not exist" (RCODE 3), then evaluation of the mechanism continues as
+   if the server returned no error (RCODE 0) and zero answer records.
+
+5.1.  "all"
+
+   all              = "all"
+
+   The "all" mechanism is a test that always matches.  It is used as the
+   rightmost mechanism in a record to provide an explicit default.
+
+   For example:
+
+      v=spf1 a mx -all
+
+   Mechanisms after "all" will never be tested.  Any "redirect" modifier
+   (Section 6.1) has no effect when there is an "all" mechanism.
+
+
+
+
+
+
+
+
+Wong & Schlitt                Experimental                     [Page 17]
+
+RFC 4408             Sender Policy Framework (SPF)            April 2006
+
+
+5.2.  "include"
+
+      include          = "include"  ":" domain-spec
+
+   The "include" mechanism triggers a recursive evaluation of
+   check_host().  The domain-spec is expanded as per Section 8.  Then
+   check_host() is evaluated with the resulting string as the <domain>.
+   The <ip> and <sender> arguments remain the same as in the current
+   evaluation of check_host().
+
+   In hindsight, the name "include" was poorly chosen.  Only the
+   evaluated result of the referenced SPF record is used, rather than
+   acting as if the referenced SPF record was literally included in the
+   first.  For example, evaluating a "-all" directive in the referenced
+   record does not terminate the overall processing and does not
+   necessarily result in an overall "Fail".  (Better names for this
+   mechanism would have been "if-pass", "on-pass", etc.)
+
+   The "include" mechanism makes it possible for one domain to designate
+   multiple administratively-independent domains.  For example, a vanity
+   domain "example.net" might send mail using the servers of
+   administratively-independent domains example.com and example.org.
+
+   Example.net could say
+
+      IN TXT "v=spf1 include:example.com include:example.org -all"
+
+   This would direct check_host() to, in effect, check the records of
+   example.com and example.org for a "Pass" result.  Only if the host
+   were not permitted for either of those domains would the result be
+   "Fail".
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wong & Schlitt                Experimental                     [Page 18]
+
+RFC 4408             Sender Policy Framework (SPF)            April 2006
+
+
+   Whether this mechanism matches, does not match, or throws an
+   exception depends on the result of the recursive evaluation of
+   check_host():
+
+   +---------------------------------+---------------------------------+
+   | A recursive check_host() result | Causes the "include" mechanism  |
+   | of:                             | to:                             |
+   +---------------------------------+---------------------------------+
+   | Pass                            | match                           |
+   |                                 |                                 |
+   | Fail                            | not match                       |
+   |                                 |                                 |
+   | SoftFail                        | not match                       |
+   |                                 |                                 |
+   | Neutral                         | not match                       |
+   |                                 |                                 |
+   | TempError                       | throw TempError                 |
+   |                                 |                                 |
+   | PermError                       | throw PermError                 |
+   |                                 |                                 |
+   | None                            | throw PermError                 |
+   +---------------------------------+---------------------------------+
+
+   The "include" mechanism is intended for crossing administrative
+   boundaries.  Although it is possible to use includes to consolidate
+   multiple domains that share the same set of designated hosts, domains
+   are encouraged to use redirects where possible, and to minimize the
+   number of includes within a single administrative domain.  For
+   example, if example.com and example.org were managed by the same
+   entity, and if the permitted set of hosts for both domains was
+   "mx:example.com", it would be possible for example.org to specify
+   "include:example.com", but it would be preferable to specify
+   "redirect=example.com" or even "mx:example.com".
+
+5.3.  "a"
+
+   This mechanism matches if <ip> is one of the <target-name>'s IP
+   addresses.
+
+   A                = "a"      [ ":" domain-spec ] [ dual-cidr-length ]
+
+   An address lookup is done on the <target-name>.  The <ip> is compared
+   to the returned address(es).  If any address matches, the mechanism
+   matches.
+
+
+
+
+
+
+
+Wong & Schlitt                Experimental                     [Page 19]
+
+RFC 4408             Sender Policy Framework (SPF)            April 2006
+
+
+5.4.  "mx"
+
+   This mechanism matches if <ip> is one of the MX hosts for a domain
+   name.
+
+   MX               = "mx"     [ ":" domain-spec ] [ dual-cidr-length ]
+
+   check_host() first performs an MX lookup on the <target-name>.  Then
+   it performs an address lookup on each MX name returned.  The <ip> is
+   compared to each returned IP address.  To prevent Denial of Service
+   (DoS) attacks, more than 10 MX names MUST NOT be looked up during the
+   evaluation of an "mx" mechanism (see Section 10).  If any address
+   matches, the mechanism matches.
+
+   Note regarding implicit MXs: If the <target-name> has no MX records,
+   check_host() MUST NOT pretend the target is its single MX, and MUST
+   NOT default to an A lookup on the <target-name> directly.  This
+   behavior breaks with the legacy "implicit MX" rule.  See [RFC2821],
+   Section 5.  If such behavior is desired, the publisher should specify
+   an "a" directive.
+
+5.5.  "ptr"
+
+   This mechanism tests whether the DNS reverse-mapping for <ip> exists
+   and correctly points to a domain name within a particular domain.
+
+   PTR              = "ptr"    [ ":" domain-spec ]
+
+   First, the <ip>'s name is looked up using this procedure: perform a
+   DNS reverse-mapping for <ip>, looking up the corresponding PTR record
+   in "in-addr.arpa." if the address is an IPv4 one and in "ip6.arpa."
+   if it is an IPv6 address.  For each record returned, validate the
+   domain name by looking up its IP address.  To prevent DoS attacks,
+   more than 10 PTR names MUST NOT be looked up during the evaluation of
+   a "ptr" mechanism (see Section 10).  If <ip> is among the returned IP
+   addresses, then that domain name is validated.  In pseudocode:
+
+   sending-domain_names := ptr_lookup(sending-host_IP); if more than 10
+   sending-domain_names are found, use at most 10.  for each name in
+   (sending-domain_names) {
+     IP_addresses := a_lookup(name);
+     if the sending-domain_IP is one of the IP_addresses {
+       validated-sending-domain_names += name;
+     } }
+
+   Check all validated domain names to see if they end in the
+   <target-name> domain.  If any do, this mechanism matches.  If no
+   validated domain name can be found, or if none of the validated
+
+
+
+Wong & Schlitt                Experimental                     [Page 20]
+
+RFC 4408             Sender Policy Framework (SPF)            April 2006
+
+
+   domain names end in the <target-name>, this mechanism fails to match.
+   If a DNS error occurs while doing the PTR RR lookup, then this
+   mechanism fails to match.  If a DNS error occurs while doing an A RR
+   lookup, then that domain name is skipped and the search continues.
+
+   Pseudocode:
+
+   for each name in (validated-sending-domain_names) {
+     if name ends in <domain-spec>, return match.
+     if name is <domain-spec>, return match.
+   }
+   return no-match.
+
+   This mechanism matches if the <target-name> is either an ancestor of
+   a validated domain name or if the <target-name> and a validated
+   domain name are the same.  For example: "mail.example.com" is within
+   the domain "example.com", but "mail.bad-example.com" is not.
+
+   Note: Use of this mechanism is discouraged because it is slow, it is
+   not as reliable as other mechanisms in cases of DNS errors, and it
+   places a large burden on the arpa name servers.  If used, proper PTR
+   records must be in place for the domain's hosts and the "ptr"
+   mechanism should be one of the last mechanisms checked.
+
+5.6.  "ip4" and "ip6"
+
+   These mechanisms test whether <ip> is contained within a given IP
+   network.
+
+   IP4              = "ip4"      ":" ip4-network   [ ip4-cidr-length ]
+   IP6              = "ip6"      ":" ip6-network   [ ip6-cidr-length ]
+
+   ip4-cidr-length  = "/" 1*DIGIT
+   ip6-cidr-length  = "/" 1*DIGIT
+   dual-cidr-length = [ ip4-cidr-length ] [ "/" ip6-cidr-length ]
+
+   ip4-network      = qnum "." qnum "." qnum "." qnum
+   qnum             = DIGIT                 ; 0-9
+                      / %x31-39 DIGIT       ; 10-99
+                      / "1" 2DIGIT          ; 100-199
+                      / "2" %x30-34 DIGIT   ; 200-249
+                      / "25" %x30-35        ; 250-255
+            ; as per conventional dotted quad notation.  e.g., 192.0.2.0
+   ip6-network      = <as per [RFC 3513], section 2.2>
+            ; e.g., 2001:DB8::CD30
+
+   The <ip> is compared to the given network.  If CIDR-length high-order
+   bits match, the mechanism matches.
+
+
+
+Wong & Schlitt                Experimental                     [Page 21]
+
+RFC 4408             Sender Policy Framework (SPF)            April 2006
+
+
+   If ip4-cidr-length is omitted, it is taken to be "/32".  If
+   ip6-cidr-length is omitted, it is taken to be "/128".  It is not
+   permitted to omit parts of the IP address instead of using CIDR
+   notations.  That is, use 192.0.2.0/24 instead of 192.0.2.
+
+5.7.  "exists"
+
+   This mechanism is used to construct an arbitrary domain name that is
+   used for a DNS A record query.  It allows for complicated schemes
+   involving arbitrary parts of the mail envelope to determine what is
+   permitted.
+
+   exists           = "exists"   ":" domain-spec
+
+   The domain-spec is expanded as per Section 8.  The resulting domain
+   name is used for a DNS A RR lookup.  If any A record is returned,
+   this mechanism matches.  The lookup type is A even when the
+   connection type is IPv6.
+
+   Domains can use this mechanism to specify arbitrarily complex
+   queries.  For example, suppose example.com publishes the record:
+
+      v=spf1 exists:%{ir}.%{l1r+-}._spf.%{d} -all
+
+   The <target-name> might expand to
+   "1.2.0.192.someuser._spf.example.com".  This makes fine-grained
+   decisions possible at the level of the user and client IP address.
+
+   This mechanism enables queries that mimic the style of tests that
+   existing anti-spam DNS blacklists (DNSBL) use.
+
+6.  Modifier Definitions
+
+   Modifiers are name/value pairs that provide additional information.
+   Modifiers always have an "=" separating the name and the value.
+
+   The modifiers defined in this document ("redirect" and "exp") MAY
+   appear anywhere in the record, but SHOULD appear at the end, after
+   all mechanisms.  Ordering of these two modifiers does not matter.
+   These two modifiers MUST NOT appear in a record more than once each.
+   If they do, then check_host() exits with a result of "PermError".
+
+   Unrecognized modifiers MUST be ignored no matter where in a record,
+   or how often.  This allows implementations of this document to
+   gracefully handle records with modifiers that are defined in other
+   specifications.
+
+
+
+
+
+Wong & Schlitt                Experimental                     [Page 22]
+
+RFC 4408             Sender Policy Framework (SPF)            April 2006
+
+
+6.1.  redirect: Redirected Query
+
+   If all mechanisms fail to match, and a "redirect" modifier is
+   present, then processing proceeds as follows:
+
+   redirect         = "redirect" "=" domain-spec
+
+   The domain-spec portion of the redirect section is expanded as per
+   the macro rules in Section 8.  Then check_host() is evaluated with
+   the resulting string as the <domain>.  The <ip> and <sender>
+   arguments remain the same as current evaluation of check_host().
+
+   The result of this new evaluation of check_host() is then considered
+   the result of the current evaluation with the exception that if no
+   SPF record is found, or if the target-name is malformed, the result
+   is a "PermError" rather than "None".
+
+   Note that the newly-queried domain may itself specify redirect
+   processing.
+
+   This facility is intended for use by organizations that wish to apply
+   the same record to multiple domains.  For example:
+
+     la.example.com. TXT "v=spf1 redirect=_spf.example.com"
+     ny.example.com. TXT "v=spf1 redirect=_spf.example.com"
+     sf.example.com. TXT "v=spf1 redirect=_spf.example.com"
+   _spf.example.com. TXT "v=spf1 mx:example.com -all"
+
+   In this example, mail from any of the three domains is described by
+   the same record.  This can be an administrative advantage.
+
+   Note: In general, the domain "A" cannot reliably use a redirect to
+   another domain "B" not under the same administrative control.  Since
+   the <sender> stays the same, there is no guarantee that the record at
+   domain "B" will correctly work for mailboxes in domain "A",
+   especially if domain "B" uses mechanisms involving localparts.  An
+   "include" directive may be more appropriate.
+
+   For clarity, it is RECOMMENDED that any "redirect" modifier appear as
+   the very last term in a record.
+
+6.2.  exp: Explanation
+
+   explanation      = "exp" "=" domain-spec
+
+   If check_host() results in a "Fail" due to a mechanism match (such as
+   "-all"), and the "exp" modifier is present, then the explanation
+   string returned is computed as described below.  If no "exp" modifier
+
+
+
+Wong & Schlitt                Experimental                     [Page 23]
+
+RFC 4408             Sender Policy Framework (SPF)            April 2006
+
+
+   is present, then either a default explanation string or an empty
+   explanation string may be returned.
+
+   The <domain-spec> is macro expanded (see Section 8) and becomes the
+   <target-name>.  The DNS TXT record for the <target-name> is fetched.
+
+   If <domain-spec> is empty, or there are any DNS processing errors
+   (any RCODE other than 0), or if no records are returned, or if more
+   than one record is returned, or if there are syntax errors in the
+   explanation string, then proceed as if no exp modifier was given.
+
+   The fetched TXT record's strings are concatenated with no spaces, and
+   then treated as an <explain-string>, which is macro-expanded.  This
+   final result is the explanation string.  Implementations MAY limit
+   the length of the resulting explanation string to allow for other
+   protocol constraints and/or reasonable processing limits.  Since the
+   explanation string is intended for an SMTP response and [RFC2821]
+   Section 2.4 says that responses are in [US-ASCII], the explanation
+   string is also limited to US-ASCII.
+
+   Software evaluating check_host() can use this string to communicate
+   information from the publishing domain in the form of a short message
+   or URL.  Software SHOULD make it clear that the explanation string
+   comes from a third party.  For example, it can prepend the macro
+   string "%{o} explains: " to the explanation, such as shown in Section
+   2.5.4.
+
+   Suppose example.com has this record:
+
+      v=spf1 mx -all exp=explain._spf.%{d}
+
+   Here are some examples of possible explanation TXT records at
+   explain._spf.example.com:
+
+      "Mail from example.com should only be sent by its own servers."
+         -- a simple, constant message
+
+      "%{i} is not one of %{d}'s designated mail servers."
+         -- a message with a little more information, including the IP
+            address that failed the check
+
+      "See http://%{d}/why.html?s=%{S}&i=%{I}"
+         -- a complicated example that constructs a URL with the
+            arguments to check_host() so that a web page can be
+            generated with detailed, custom instructions
+
+   Note: During recursion into an "include" mechanism, an exp= modifier
+   from the <target-name> MUST NOT be used.  In contrast, when executing
+
+
+
+Wong & Schlitt                Experimental                     [Page 24]
+
+RFC 4408             Sender Policy Framework (SPF)            April 2006
+
+
+   a "redirect" modifier, an exp= modifier from the original domain MUST
+   NOT be used.
+
+7.  The Received-SPF Header Field
+
+   It is RECOMMENDED that SMTP receivers record the result of SPF
+   processing in the message header.  If an SMTP receiver chooses to do
+   so, it SHOULD use the "Received-SPF" header field defined here for
+   each identity that was checked.  This information is intended for the
+   recipient.  (Information intended for the sender is described in
+   Section 6.2, Explanation.)
+
+   The Received-SPF header field is a trace field (see [RFC2822] Section
+   3.6.7) and SHOULD be prepended to the existing header, above the
+   Received: field that is generated by the SMTP receiver.  It MUST
+   appear above all other Received-SPF fields in the message.  The
+   header field has the following format:
+
+   header-field     = "Received-SPF:" [CFWS] result FWS [comment FWS]
+                      [ key-value-list ] CRLF
+
+   result           = "Pass" / "Fail" / "SoftFail" / "Neutral" /
+                      "None" / "TempError" / "PermError"
+
+   key-value-list   = key-value-pair *( ";" [CFWS] key-value-pair )
+                      [";"]
+
+   key-value-pair   = key [CFWS] "=" ( dot-atom / quoted-string )
+
+   key              = "client-ip" / "envelope-from" / "helo" /
+                      "problem" / "receiver" / "identity" /
+                       mechanism / "x-" name / name
+
+   identity         = "mailfrom"   ; for the "MAIL FROM" identity
+                      / "helo"     ; for the "HELO" identity
+                      / name       ; other identities
+
+   dot-atom         = <unquoted word as per [RFC2822]>
+   quoted-string    = <quoted string as per [RFC2822]>
+   comment          = <comment string as per [RFC2822]>
+   CFWS             = <comment or folding white space as per [RFC2822]>
+   FWS              = <folding white space as per [RFC2822]>
+   CRLF             = <standard end-of-line token as per [RFC2822]>
+
+   The header field SHOULD include a "(...)" style <comment> after the
+   result, conveying supporting information for the result, such as
+   <ip>, <sender>, and <domain>.
+
+
+
+
+Wong & Schlitt                Experimental                     [Page 25]
+
+RFC 4408             Sender Policy Framework (SPF)            April 2006
+
+
+   The following key-value pairs are designed for later machine parsing.
+   SPF clients SHOULD give enough information so that the SPF results
+   can be verified.  That is, at least "client-ip", "helo", and, if the
+   "MAIL FROM" identity was checked, "envelope-from".
+
+   client-ip      the IP address of the SMTP client
+
+   envelope-from  the envelope sender mailbox
+
+   helo           the host name given in the HELO or EHLO command
+
+   mechanism      the mechanism that matched (if no mechanisms matched,
+                  substitute the word "default")
+
+   problem        if an error was returned, details about the error
+
+   receiver       the host name of the SPF client
+
+   identity       the identity that was checked; see the <identity> ABNF
+                  rule
+
+   Other keys may be defined by SPF clients.  Until a new key name
+   becomes widely accepted, new key names should start with "x-".
+
+   SPF clients MUST make sure that the Received-SPF header field does
+   not contain invalid characters, is not excessively long, and does not
+   contain malicious data that has been provided by the sender.
+
+   Examples of various header styles that could be generated are the
+   following:
+
+   Received-SPF: Pass (mybox.example.org: domain of
+    myname@example.com designates 192.0.2.1 as permitted sender)
+       receiver=mybox.example.org; client-ip=192.0.2.1;
+       envelope-from=<myname@example.com>; helo=foo.example.com;
+
+   Received-SPF: Fail (mybox.example.org: domain of
+                     myname@example.com does not designate
+                     192.0.2.1 as permitted sender)
+                     identity=mailfrom; client-ip=192.0.2.1;
+                     envelope-from=<myname@example.com>;
+
+
+
+
+
+
+
+
+
+
+Wong & Schlitt                Experimental                     [Page 26]
+
+RFC 4408             Sender Policy Framework (SPF)            April 2006
+
+
+8.  Macros
+
+8.1.  Macro Definitions
+
+   Many mechanisms and modifiers perform macro expansion on part of the
+   term.
+
+   domain-spec      = macro-string domain-end
+   domain-end       = ( "." toplabel [ "." ] ) / macro-expand
+
+   toplabel         = ( *alphanum ALPHA *alphanum ) /
+                      ( 1*alphanum "-" *( alphanum / "-" ) alphanum )
+                      ; LDH rule plus additional TLD restrictions
+                      ; (see [RFC3696], Section 2)
+   alphanum         = ALPHA / DIGIT
+
+   explain-string   = *( macro-string / SP )
+
+   macro-string     = *( macro-expand / macro-literal )
+   macro-expand     = ( "%{" macro-letter transformers *delimiter "}" )
+                      / "%%" / "%_" / "%-"
+   macro-literal    = %x21-24 / %x26-7E
+                      ; visible characters except "%"
+   macro-letter     = "s" / "l" / "o" / "d" / "i" / "p" / "h" /
+                      "c" / "r" / "t"
+   transformers     = *DIGIT [ "r" ]
+   delimiter        = "." / "-" / "+" / "," / "/" / "_" / "="
+
+   A literal "%" is expressed by "%%".
+
+      "%_" expands to a single " " space.
+      "%-" expands to a URL-encoded space, viz., "%20".
+
+   The following macro letters are expanded in term arguments:
+
+      s = <sender>
+      l = local-part of <sender>
+      o = domain of <sender>
+      d = <domain>
+      i = <ip>
+      p = the validated domain name of <ip>
+      v = the string "in-addr" if <ip> is ipv4, or "ip6" if <ip> is ipv6
+      h = HELO/EHLO domain
+
+
+
+
+
+
+
+
+Wong & Schlitt                Experimental                     [Page 27]
+
+RFC 4408             Sender Policy Framework (SPF)            April 2006
+
+
+   The following macro letters are allowed only in "exp" text:
+
+      c = SMTP client IP (easily readable format)
+      r = domain name of host performing the check
+      t = current timestamp
+
+   A '%' character not followed by a '{', '%', '-', or '_' character is
+   a syntax error.  So
+
+      -exists:%(ir).sbl.spamhaus.example.org
+
+   is incorrect and will cause check_host() to return a "PermError".
+   Instead, say
+
+      -exists:%{ir}.sbl.spamhaus.example.org
+
+   Optional transformers are the following:
+
+      *DIGIT = zero or more digits
+      'r'    = reverse value, splitting on dots by default
+
+   If transformers or delimiters are provided, the replacement value for
+   a macro letter is split into parts.  After performing any reversal
+   operation and/or removal of left-hand parts, the parts are rejoined
+   using "." and not the original splitting characters.
+
+   By default, strings are split on "." (dots).  Note that no special
+   treatment is given to leading, trailing, or consecutive delimiters,
+   and so the list of parts may contain empty strings.  Older
+   implementations of SPF prohibit trailing dots in domain names, so
+   trailing dots should not be published by domain owners, although they
+   must be accepted by implementations conforming to this document.
+   Macros may specify delimiter characters that are used instead of ".".
+
+   The 'r' transformer indicates a reversal operation: if the client IP
+   address were 192.0.2.1, the macro %{i} would expand to "192.0.2.1"
+   and the macro %{ir} would expand to "1.2.0.192".
+
+   The DIGIT transformer indicates the number of right-hand parts to
+   use, after optional reversal.  If a DIGIT is specified, the value
+   MUST be nonzero.  If no DIGITs are specified, or if the value
+   specifies more parts than are available, all the available parts are
+   used.  If the DIGIT was 5, and only 3 parts were available, the macro
+   interpreter would pretend the DIGIT was 3.  Implementations MUST
+   support at least a value of 128, as that is the maximum number of
+   labels in a domain name.
+
+
+
+
+
+Wong & Schlitt                Experimental                     [Page 28]
+
+RFC 4408             Sender Policy Framework (SPF)            April 2006
+
+
+   The "s" macro expands to the <sender> argument.  It is an E-Mail
+   address with a localpart, an "@" character, and a domain.  The "l"
+   macro expands to just the localpart.  The "o" macro expands to just
+   the domain part.  Note that these values remain the same during
+   recursive and chained evaluations due to "include" and/or "redirect".
+   Note also that if the original <sender> had no localpart, the
+   localpart was set to "postmaster" in initial processing (see Section
+   4.3).
+
+   For IPv4 addresses, both the "i" and "c" macros expand to the
+   standard dotted-quad format.
+
+   For IPv6 addresses, the "i" macro expands to a dot-format address; it
+   is intended for use in %{ir}.  The "c" macro may expand to any of the
+   hexadecimal colon-format addresses specified in [RFC3513], Section
+   2.2.  It is intended for humans to read.
+
+   The "p" macro expands to the validated domain name of <ip>.  The
+   procedure for finding the validated domain name is defined in Section
+   5.5.  If the <domain> is present in the list of validated domains, it
+   SHOULD be used.  Otherwise, if a subdomain of the <domain> is
+   present, it SHOULD be used.  Otherwise, any name from the list may be
+   used.  If there are no validated domain names or if a DNS error
+   occurs, the string "unknown" is used.
+
+   The "r" macro expands to the name of the receiving MTA.  This SHOULD
+   be a fully qualified domain name, but if one does not exist (as when
+   the checking is done by a MUA) or if policy restrictions dictate
+   otherwise, the word "unknown" SHOULD be substituted.  The domain name
+   may be different from the name found in the MX record that the client
+   MTA used to locate the receiving MTA.
+
+   The "t" macro expands to the decimal representation of the
+   approximate number of seconds since the Epoch (Midnight, January 1,
+   1970, UTC).  This is the same value as is returned by the POSIX
+   time() function in most standards-compliant libraries.
+
+   When the result of macro expansion is used in a domain name query, if
+   the expanded domain name exceeds 253 characters (the maximum length
+   of a domain name), the left side is truncated to fit, by removing
+   successive domain labels until the total length does not exceed 253
+   characters.
+
+   Uppercased macros expand exactly as their lowercased equivalents, and
+   are then URL escaped.  URL escaping must be performed for characters
+   not in the "uric" set, which is defined in [RFC3986].
+
+
+
+
+
+Wong & Schlitt                Experimental                     [Page 29]
+
+RFC 4408             Sender Policy Framework (SPF)            April 2006
+
+
+   Note: Care must be taken so that macro expansion for legitimate
+   E-Mail does not exceed the 63-character limit on DNS labels.  The
+   localpart of E-Mail addresses, in particular, can have more than 63
+   characters between dots.
+
+   Note: Domains should avoid using the "s", "l", "o", or "h" macros in
+   conjunction with any mechanism directive.  Although these macros are
+   powerful and allow per-user records to be published, they severely
+   limit the ability of implementations to cache results of check_host()
+   and they reduce the effectiveness of DNS caches.
+
+   Implementations should be aware that if no directive processed during
+   the evaluation of check_host() contains an "s", "l", "o", or "h"
+   macro, then the results of the evaluation can be cached on the basis
+   of <domain> and <ip> alone for as long as the shortest Time To Live
+   (TTL) of all the DNS records involved.
+
+8.2.  Expansion Examples
+
+      The <sender> is strong-bad@email.example.com.
+      The IPv4 SMTP client IP is 192.0.2.3.
+      The IPv6 SMTP client IP is 2001:DB8::CB01.
+      The PTR domain name of the client IP is mx.example.org.
+
+   macro                       expansion
+   -------  ----------------------------
+   %{s}     strong-bad@email.example.com
+   %{o}                email.example.com
+   %{d}                email.example.com
+   %{d4}               email.example.com
+   %{d3}               email.example.com
+   %{d2}                     example.com
+   %{d1}                             com
+   %{dr}               com.example.email
+   %{d2r}                  example.email
+   %{l}                       strong-bad
+   %{l-}                      strong.bad
+   %{lr}                      strong-bad
+   %{lr-}                     bad.strong
+   %{l1r-}                        strong
+
+
+
+
+
+
+
+
+
+
+
+Wong & Schlitt                Experimental                     [Page 30]
+
+RFC 4408             Sender Policy Framework (SPF)            April 2006
+
+
+   macro-string                                               expansion
+   --------------------------------------------------------------------
+   %{ir}.%{v}._spf.%{d2}             3.2.0.192.in-addr._spf.example.com
+   %{lr-}.lp._spf.%{d2}                  bad.strong.lp._spf.example.com
+
+   %{lr-}.lp.%{ir}.%{v}._spf.%{d2}
+                       bad.strong.lp.3.2.0.192.in-addr._spf.example.com
+
+   %{ir}.%{v}.%{l1r-}.lp._spf.%{d2}
+                           3.2.0.192.in-addr.strong.lp._spf.example.com
+
+   %{d2}.trusted-domains.example.net
+                                example.com.trusted-domains.example.net
+
+   IPv6:
+   %{ir}.%{v}._spf.%{d2}                               1.0.B.C.0.0.0.0.
+   0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.B.D.0.1.0.0.2.ip6._spf.example.com
+
+9.  Implications
+
+   This section outlines the major implications that adoption of this
+   document will have on various entities involved in Internet E-Mail.
+   It is intended to make clear to the reader where this document
+   knowingly affects the operation of such entities.  This section is
+   not a "how-to" manual, or a "best practices" document, and it is not
+   a comprehensive list of what such entities should do in light of this
+   document.
+
+   This section is non-normative.
+
+9.1.  Sending Domains
+
+   Domains that wish to be compliant with this specification will need
+   to determine the list of hosts that they allow to use their domain
+   name in the "HELO" and "MAIL FROM" identities.  It is recognized that
+   forming such a list is not just a simple technical exercise, but
+   involves policy decisions with both technical and administrative
+   considerations.
+
+   It can be helpful to publish records that include a "tracking
+   exists:" mechanism.  By looking at the name server logs, a rough list
+   may then be generated.  For example:
+
+      v=spf1 exists:_h.%{h}._l.%{l}._o.%{o}._i.%{i}._spf.%{d} ?all
+
+
+
+
+
+
+
+Wong & Schlitt                Experimental                     [Page 31]
+
+RFC 4408             Sender Policy Framework (SPF)            April 2006
+
+
+9.2.  Mailing Lists
+
+   Mailing lists must be aware of how they re-inject mail that is sent
+   to the list.  Mailing lists MUST comply with the requirements in
+   [RFC2821], Section 3.10, and [RFC1123], Section 5.3.6, that say that
+   the reverse-path MUST be changed to be the mailbox of a person or
+   other entity who administers the list.  Whereas the reasons for
+   changing the reverse-path are many and long-standing, SPF adds
+   enforcement to this requirement.
+
+   In practice, almost all mailing list software in use already complies
+   with this requirement.  Mailing lists that do not comply may or may
+   not encounter problems depending on how access to the list is
+   restricted.  Such lists that are entirely internal to a domain (only
+   people in the domain can send to or receive from the list) are not
+   affected.
+
+9.3.  Forwarding Services and Aliases
+
+   Forwarding services take mail that is received at a mailbox and
+   direct it to some external mailbox.  At the time of this writing, the
+   near-universal practice of such services is to use the original "MAIL
+   FROM" of a message when re-injecting it for delivery to the external
+   mailbox.  [RFC1123] and [RFC2821] describe this action as an "alias"
+   rather than a "mail list".  This means that the external mailbox's
+   MTA sees all such mail in a connection from a host of the forwarding
+   service, and so the "MAIL FROM" identity will not, in general, pass
+   authorization.
+
+   There are three places that techniques can be used to ameliorate this
+   problem.
+
+   1. The beginning, when E-Mail is first sent.
+
+       1. "Neutral" results could be given for IP addresses that may be
+          forwarders, instead of "Fail" results.  For example:
+
+             "v=spf1 mx -exists:%{ir}.sbl.spamhaus.example.org ?all"
+
+          This would cause a lookup on an anti-spam DNS blacklist
+          (DNSBL) and cause a result of "Fail" only for E-Mail coming
+          from listed sources.  All other E-Mail, including E-Mail sent
+          through forwarders, would receive a "Neutral" result.  By
+          checking the DNSBL after the known good sources, problems with
+          incorrect listing on the DNSBL are greatly reduced.
+
+
+
+
+
+
+Wong & Schlitt                Experimental                     [Page 32]
+
+RFC 4408             Sender Policy Framework (SPF)            April 2006
+
+
+       2. The "MAIL FROM" identity could have additional information in
+          the localpart that cryptographically identifies the mail as
+          coming from an authorized source.  In this case, such an SPF
+          record could be used:
+
+             "v=spf1 mx exists:%{l}._spf_verify.%{d} -all"
+
+          Then, a specialized DNS server can be set up to serve the
+          _spf_verify subdomain that validates the localpart.  Although
+          this requires an extra DNS lookup, this happens only when the
+          E-Mail would otherwise be rejected as not coming from a known
+          good source.
+
+          Note that due to the 63-character limit for domain labels,
+          this approach only works reliably if the localpart signature
+          scheme is guaranteed either to only produce localparts with a
+          maximum of 63 characters or to gracefully handle truncated
+          localparts.
+
+       3. Similarly, a specialized DNS server could be set up that will
+          rate-limit the E-Mail coming from unexpected IP addresses.
+
+             "v=spf1 mx exists:%{ir}._spf_rate.%{d} -all"
+
+       4. SPF allows the creation of per-user policies for special
+          cases.  For example, the following SPF record and appropriate
+          wildcard DNS records can be used:
+
+                 "v=spf1 mx redirect=%{l1r+}._at_.%{o}._spf.%{d}"
+
+   2.  The middle, when E-Mail is forwarded.
+
+       1. Forwarding services can solve the problem by rewriting the
+          "MAIL FROM" to be in their own domain.  This means that mail
+          bounced from the external mailbox will have to be re-bounced
+          by the forwarding service.  Various schemes to do this exist
+          though they vary widely in complexity and resource
+          requirements on the part of the forwarding service.
+
+       2. Several popular MTAs can be forced from "alias" semantics to
+          "mailing list" semantics by configuring an additional alias
+          with "owner-" prepended to the original alias name (e.g., an
+          alias of "friends: george@example.com, fred@example.org" would
+          need another alias of the form "owner-friends:  localowner").
+
+
+
+
+
+
+
+Wong & Schlitt                Experimental                     [Page 33]
+
+RFC 4408             Sender Policy Framework (SPF)            April 2006
+
+
+   3. The end, when E-Mail is received.
+
+       1. If the owner of the external mailbox wishes to trust the
+          forwarding service, he can direct the external mailbox's MTA
+          to skip SPF tests when the client host belongs to the
+          forwarding service.
+
+       2. Tests against other identities, such as the "HELO" identity,
+          may be used to override a failed test against the "MAIL FROM"
+          identity.
+
+       3. For larger domains, it may not be possible to have a complete
+          or accurate list of forwarding services used by the owners of
+          the domain's mailboxes.  In such cases, whitelists of
+          generally-recognized forwarding services could be employed.
+
+9.4.  Mail Services
+
+   Service providers that offer mail services to third-party domains,
+   such as sending of bulk mail, may want to adjust their setup in light
+   of the authorization check described in this document.  If the "MAIL
+   FROM" identity used for such E-Mail uses the domain of the service
+   provider, then the provider needs only to ensure that its sending
+   host is authorized by its own SPF record, if any.
+
+   If the "MAIL FROM" identity does not use the mail service provider's
+   domain, then extra care must be taken.  The SPF record format has
+   several options for the third-party domain to authorize the service
+   provider's MTAs to send mail on its behalf.  For mail service
+   providers, such as ISPs, that have a wide variety of customers using
+   the same MTA, steps should be taken to prevent cross-customer forgery
+   (see Section 10.4).
+
+9.5.  MTA Relays
+
+   The authorization check generally precludes the use of arbitrary MTA
+   relays between sender and receiver of an E-Mail message.
+
+   Within an organization, MTA relays can be effectively deployed.
+   However, for purposes of this document, such relays are effectively
+   transparent.  The SPF authorization check is a check between border
+   MTAs of different domains.
+
+   For mail senders, this means that published SPF records must
+   authorize any MTAs that actually send across the Internet.  Usually,
+   these are just the border MTAs as internal MTAs simply forward mail
+   to these MTAs for delivery.
+
+
+
+
+Wong & Schlitt                Experimental                     [Page 34]
+
+RFC 4408             Sender Policy Framework (SPF)            April 2006
+
+
+   Mail receivers will generally want to perform the authorization check
+   at the border MTAs, specifically including all secondary MXs.  This
+   allows mail that fails to be rejected during the SMTP session rather
+   than bounced.  Internal MTAs then do not perform the authorization
+   test.  To perform the authorization test other than at the border,
+   the host that first transferred the message to the organization must
+   be determined, which can be difficult to extract from the message
+   header.  Testing other than at the border is not recommended.
+
+10.  Security Considerations
+
+10.1.  Processing Limits
+
+   As with most aspects of E-Mail, there are a number of ways that
+   malicious parties could use the protocol as an avenue for a
+   Denial-of-Service (DoS) attack.  The processing limits outlined here
+   are designed to prevent attacks such as the following:
+
+   o  A malicious party could create an SPF record with many references
+      to a victim's domain and send many E-Mails to different SPF
+      clients; those SPF clients would then create a DoS attack.  In
+      effect, the SPF clients are being used to amplify the attacker's
+      bandwidth by using fewer bytes in the SMTP session than are used
+      by the DNS queries.  Using SPF clients also allows the attacker to
+      hide the true source of the attack.
+
+   o  Whereas implementations of check_host() are supposed to limit the
+      number of DNS lookups, malicious domains could publish records
+      that exceed these limits in an attempt to waste computation effort
+      at their targets when they send them mail.  Malicious domains
+      could also design SPF records that cause particular
+      implementations to use excessive memory or CPU usage, or to
+      trigger bugs.
+
+   o  Malicious parties could send a large volume of mail purporting to
+      come from the intended target to a wide variety of legitimate mail
+      hosts.  These legitimate machines would then present a DNS load on
+      the target as they fetched the relevant records.
+
+   Of these, the case of a third party referenced in the SPF record is
+   the easiest for a DoS attack to effectively exploit.  As a result,
+   limits that may seem reasonable for an individual mail server can
+   still allow an unreasonable amount of bandwidth amplification.
+   Therefore, the processing limits need to be quite low.
+
+   SPF implementations MUST limit the number of mechanisms and modifiers
+   that do DNS lookups to at most 10 per SPF check, including any
+   lookups caused by the use of the "include" mechanism or the
+
+
+
+Wong & Schlitt                Experimental                     [Page 35]
+
+RFC 4408             Sender Policy Framework (SPF)            April 2006
+
+
+   "redirect" modifier.  If this number is exceeded during a check, a
+   PermError MUST be returned.  The "include", "a", "mx", "ptr", and
+   "exists" mechanisms as well as the "redirect" modifier do count
+   against this limit.  The "all", "ip4", and "ip6" mechanisms do not
+   require DNS lookups and therefore do not count against this limit.
+   The "exp" modifier does not count against this limit because the DNS
+   lookup to fetch the explanation string occurs after the SPF record
+   has been evaluated.
+
+   When evaluating the "mx" and "ptr" mechanisms, or the %{p} macro,
+   there MUST be a limit of no more than 10 MX or PTR RRs looked up and
+   checked.
+
+   SPF implementations SHOULD limit the total amount of data obtained
+   from the DNS queries.  For example, when DNS over TCP or EDNS0 are
+   available, there may need to be an explicit limit to how much data
+   will be accepted to prevent excessive bandwidth usage or memory usage
+   and DoS attacks.
+
+   MTAs or other processors MAY also impose a limit on the maximum
+   amount of elapsed time to evaluate check_host().  Such a limit SHOULD
+   allow at least 20 seconds.  If such a limit is exceeded, the result
+   of authorization SHOULD be "TempError".
+
+   Domains publishing records SHOULD try to keep the number of "include"
+   mechanisms and chained "redirect" modifiers to a minimum.  Domains
+   SHOULD also try to minimize the amount of other DNS information
+   needed to evaluate a record.  This can be done by choosing directives
+   that require less DNS information and placing lower-cost mechanisms
+   earlier in the SPF record.
+
+   For example, consider a domain set up as follows:
+
+   example.com.      IN MX   10 mx.example.com.
+   mx.example.com.   IN A    192.0.2.1
+   a.example.com.    IN TXT  "v=spf1 mx:example.com -all"
+   b.example.com.    IN TXT  "v=spf1 a:mx.example.com -all"
+   c.example.com.    IN TXT  "v=spf1 ip4:192.0.2.1 -all"
+
+   Evaluating check_host() for the domain "a.example.com" requires the
+   MX records for "example.com", and then the A records for the listed
+   hosts.  Evaluating for "b.example.com" requires only the A records.
+   Evaluating for "c.example.com" requires none.
+
+   However, there may be administrative considerations: using "a" over
+   "ip4" allows hosts to be renumbered easily.  Using "mx" over "a"
+   allows the set of mail hosts to be changed easily.
+
+
+
+
+Wong & Schlitt                Experimental                     [Page 36]
+
+RFC 4408             Sender Policy Framework (SPF)            April 2006
+
+
+10.2.  SPF-Authorized E-Mail May Contain Other False Identities
+
+   The "MAIL FROM" and "HELO" identity authorizations must not be
+   construed to provide more assurance than they do.  It is entirely
+   possible for a malicious sender to inject a message using his own
+   domain in the identities used by SPF, to have that domain's SPF
+   record authorize the sending host, and yet the message can easily
+   list other identities in its header.  Unless the user or the MUA
+   takes care to note that the authorized identity does not match the
+   other more commonly-presented identities (such as the From:  header
+   field), the user may be lulled into a false sense of security.
+
+10.3.  Spoofed DNS and IP Data
+
+   There are two aspects of this protocol that malicious parties could
+   exploit to undermine the validity of the check_host() function:
+
+   o  The evaluation of check_host() relies heavily on DNS.  A malicious
+      attacker could attack the DNS infrastructure and cause
+      check_host() to see spoofed DNS data, and then return incorrect
+      results.  This could include returning "Pass" for an <ip> value
+      where the actual domain's record would evaluate to "Fail".  See
+      [RFC3833] for a description of DNS weaknesses.
+
+   o  The client IP address, <ip>, is assumed to be correct.  A
+      malicious attacker could spoof TCP sequence numbers to make mail
+      appear to come from a permitted host for a domain that the
+      attacker is impersonating.
+
+10.4.  Cross-User Forgery
+
+   By definition, SPF policies just map domain names to sets of
+   authorized MTAs, not whole E-Mail addresses to sets of authorized
+   users.  Although the "l" macro (Section 8) provides a limited way to
+   define individual sets of authorized MTAs for specific E-Mail
+   addresses, it is generally impossible to verify, through SPF, the use
+   of specific E-Mail addresses by individual users of the same MTA.
+
+   It is up to mail services and their MTAs to directly prevent
+   cross-user forgery: based on SMTP AUTH ([RFC2554]), users should be
+   restricted to using only those E-Mail addresses that are actually
+   under their control (see [RFC4409], Section 6.1).  Another means to
+   verify the identity of individual users is message cryptography such
+   as PGP ([RFC2440]) or S/MIME ([RFC3851]).
+
+
+
+
+
+
+
+Wong & Schlitt                Experimental                     [Page 37]
+
+RFC 4408             Sender Policy Framework (SPF)            April 2006
+
+
+10.5.  Untrusted Information Sources
+
+   SPF uses information supplied by third parties, such as the "HELO"
+   domain name, the "MAIL FROM" address, and SPF records.  This
+   information is then passed to the receiver in the Received-SPF: trace
+   fields and possibly returned to the client MTA in the form of an SMTP
+   rejection message.  This information must be checked for invalid
+   characters and excessively long lines.
+
+   When the authorization check fails, an explanation string may be
+   included in the reject response.  Both the sender and the rejecting
+   receiver need to be aware that the explanation was determined by the
+   publisher of the SPF record checked and, in general, not the
+   receiver.  The explanation may contain malicious URLs, or it may be
+   offensive or misleading.
+
+   This is probably less of a concern than it may initially seem since
+   such messages are returned to the sender, and the explanation strings
+   come from the sender policy published by the domain in the identity
+   claimed by that very sender.  As long as the DSN is not redirected to
+   someone other than the actual sender, the only people who see
+   malicious explanation strings are people whose messages claim to be
+   from domains that publish such strings in their SPF records.  In
+   practice, DSNs can be misdirected, such as when an MTA accepts an
+   E-Mail and then later generates a DSN to a forged address, or when an
+   E-Mail forwarder does not direct the DSN back to the original sender.
+
+10.6.  Privacy Exposure
+
+   Checking SPF records causes DNS queries to be sent to the domain
+   owner.  These DNS queries, especially if they are caused by the
+   "exists" mechanism, can contain information about who is sending
+   E-Mail and likely to which MTA the E-Mail is being sent.  This can
+   introduce some privacy concerns, which may be more or less of an
+   issue depending on local laws and the relationship between the domain
+   owner and the person sending the E-Mail.
+
+11.  Contributors and Acknowledgements
+
+   This document is largely based on the work of Meng Weng Wong and Mark
+   Lentczner.  Although, as this section acknowledges, many people have
+   contributed to this document, a very large portion of the writing and
+   editing are due to Meng and Mark.
+
+   This design owes a debt of parentage to [RMX] by Hadmut Danisch and
+   to [DMP] by Gordon Fecyk.  The idea of using a DNS record to check
+   the legitimacy of an E-Mail address traces its ancestry further back
+   through messages on the namedroppers mailing list by Paul Vixie
+
+
+
+Wong & Schlitt                Experimental                     [Page 38]
+
+RFC 4408             Sender Policy Framework (SPF)            April 2006
+
+
+   [Vixie] (based on suggestion by Jim Miller) and by David Green
+   [Green].
+
+   Philip Gladstone contributed the concept of macros to the
+   specification, multiplying the expressiveness of the language and
+   making per-user and per-IP lookups possible.
+
+   The authors would also like to thank the literally hundreds of
+   individuals who have participated in the development of this design.
+   They are far too numerous to name, but they include the following:
+
+      The folks on the spf-discuss mailing list.
+      The folks on the SPAM-L mailing list.
+      The folks on the IRTF ASRG mailing list.
+      The folks on the IETF MARID mailing list.
+      The folks on #perl.
+
+12.  IANA Considerations
+
+12.1.  The SPF DNS Record Type
+
+   The IANA has assigned a new Resource Record Type and Qtype from the
+   DNS Parameters Registry for the SPF RR type with code 99.
+
+12.2.  The Received-SPF Mail Header Field
+
+   Per [RFC3864], the "Received-SPF:" header field is added to the IANA
+   Permanent Message Header Field Registry.  The following is the
+   registration template:
+
+      Header field name: Received-SPF
+      Applicable protocol: mail ([RFC2822])
+      Status: Experimental
+      Author/Change controller: IETF
+      Specification document(s): RFC 4408
+      Related information:
+      Requesting SPF Council review of any proposed changes and
+      additions to this field are recommended.  For information about
+      the SPF Council see http://www.openspf.org/Council
+
+13.  References
+
+13.1.  Normative References
+
+   [RFC1035]  Mockapetris, P., "Domain names - implementation and
+              specification", STD 13, RFC 1035, November 1987.
+
+
+
+
+
+Wong & Schlitt                Experimental                     [Page 39]
+
+RFC 4408             Sender Policy Framework (SPF)            April 2006
+
+
+   [RFC1123]  Braden, R., "Requirements for Internet Hosts - Application
+              and Support", STD 3, RFC 1123, October 1989.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2821]  Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
+              April 2001.
+
+   [RFC2822]  Resnick, P., "Internet Message Format", RFC 2822, April
+              2001.
+
+   [RFC3464]  Moore, K. and G. Vaudreuil, "An Extensible Message Format
+              for Delivery Status Notifications", RFC 3464, January
+              2003.
+
+   [RFC3513]  Hinden, R. and S. Deering, "Internet Protocol Version 6
+              (IPv6) Addressing Architecture", RFC 3513, April 2003.
+
+   [RFC3864]  Klyne, G., Nottingham, M., and J. Mogul, "Registration
+              Procedures for Message Header Fields", BCP 90, RFC 3864,
+              September 2004.
+
+   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
+              Resource Identifier (URI): Generic Syntax", STD 66, RFC
+              3986, January 2005.
+
+   [RFC4234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
+              Specifications: ABNF", RFC 4234, October 2005.
+
+   [US-ASCII] American National Standards Institute (formerly United
+              States of America Standards Institute), "USA Code for
+              Information Interchange, X3.4", 1968.
+
+   ANSI X3.4-1968 has been replaced by newer versions with slight
+              modifications, but the 1968 version remains definitive for
+              the Internet.
+
+13.2  Informative References
+
+   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
+              STD 13, RFC 1034, November 1987.
+
+   [RFC1983]  Malkin, G., "Internet Users' Glossary", RFC 1983, August
+              1996.
+
+   [RFC2440]  Callas, J., Donnerhacke, L., Finney, H., and R. Thayer,
+              "OpenPGP Message Format", RFC 2440, November 1998.
+
+
+
+Wong & Schlitt                Experimental                     [Page 40]
+
+RFC 4408             Sender Policy Framework (SPF)            April 2006
+
+
+   [RFC2554]  Myers, J., "SMTP Service Extension for Authentication",
+              RFC 2554, March 1999.
+
+   [RFC3696]  Klensin, J., "Application Techniques for Checking and
+              Transformation of Names", RFC 3696, February 2004.
+
+   [RFC3833]  Atkins, D. and R. Austein, "Threat Analysis of the Domain
+              Name System (DNS)", RFC 3833, August 2004.
+
+   [RFC3851]  Ramsdell, B., "Secure/Multipurpose Internet Mail
+              Extensions (S/MIME) Version 3.1 Message Specification",
+              RFC 3851, July 2004.
+
+   [RFC4409]  Gellens, R. and J. Klensin, "Message Submission for Mail",
+              RFC 4409, April 2006.
+
+   [RMX]      Danish, H., "The RMX DNS RR Type for light weight sender
+              authentication", Work In Progress
+
+   [DMP]      Fecyk, G., "Designated Mailers Protocol", Work In Progress
+
+   [Vixie]    Vixie, P., "Repudiating MAIL FROM", 2002.
+
+   [Green]    Green, D., "Domain-Authorized SMTP Mail", 2002.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wong & Schlitt                Experimental                     [Page 41]
+
+RFC 4408             Sender Policy Framework (SPF)            April 2006
+
+
+Appendix A.  Collected ABNF
+
+   This section is normative and any discrepancies with the ABNF
+   fragments in the preceding text are to be resolved in favor of this
+   grammar.
+
+   See [RFC4234] for ABNF notation.  Please note that as per this ABNF
+   definition, literal text strings (those in quotes) are case-
+   insensitive.  Hence, "mx" matches "mx", "MX", "mX", and "Mx".
+
+   record           = version terms *SP
+   version          = "v=spf1"
+
+   terms            = *( 1*SP ( directive / modifier ) )
+
+   directive        = [ qualifier ] mechanism
+   qualifier        = "+" / "-" / "?" / "~"
+   mechanism        = ( all / include
+                      / A / MX / PTR / IP4 / IP6 / exists )
+
+   all              = "all"
+   include          = "include"  ":" domain-spec
+   A                = "a"      [ ":" domain-spec ] [ dual-cidr-length ]
+   MX               = "mx"     [ ":" domain-spec ] [ dual-cidr-length ]
+   PTR              = "ptr"    [ ":" domain-spec ]
+   IP4              = "ip4"      ":" ip4-network   [ ip4-cidr-length ]
+   IP6              = "ip6"      ":" ip6-network   [ ip6-cidr-length ]
+   exists           = "exists"   ":" domain-spec
+
+   modifier         = redirect / explanation / unknown-modifier
+   redirect         = "redirect" "=" domain-spec
+   explanation      = "exp" "=" domain-spec
+   unknown-modifier = name "=" macro-string
+
+   ip4-cidr-length  = "/" 1*DIGIT
+   ip6-cidr-length  = "/" 1*DIGIT
+   dual-cidr-length = [ ip4-cidr-length ] [ "/" ip6-cidr-length ]
+
+   ip4-network      = qnum "." qnum "." qnum "." qnum
+   qnum             = DIGIT                 ; 0-9
+                      / %x31-39 DIGIT       ; 10-99
+                      / "1" 2DIGIT          ; 100-199
+                      / "2" %x30-34 DIGIT   ; 200-249
+                      / "25" %x30-35        ; 250-255
+             ; conventional dotted quad notation.  e.g., 192.0.2.0
+   ip6-network      = <as per [RFC 3513], section 2.2>
+             ; e.g., 2001:DB8::CD30
+
+
+
+
+Wong & Schlitt                Experimental                     [Page 42]
+
+RFC 4408             Sender Policy Framework (SPF)            April 2006
+
+
+   domain-spec      = macro-string domain-end
+   domain-end       = ( "." toplabel [ "." ] ) / macro-expand
+   toplabel         = ( *alphanum ALPHA *alphanum ) /
+                      ( 1*alphanum "-" *( alphanum / "-" ) alphanum )
+                      ; LDH rule plus additional TLD restrictions
+                      ; (see [RFC3696], Section 2)
+
+   alphanum         = ALPHA / DIGIT
+
+   explain-string   = *( macro-string / SP )
+
+   macro-string     = *( macro-expand / macro-literal )
+   macro-expand     = ( "%{" macro-letter transformers *delimiter "}" )
+                      / "%%" / "%_" / "%-"
+   macro-literal    = %x21-24 / %x26-7E
+                      ; visible characters except "%"
+   macro-letter     = "s" / "l" / "o" / "d" / "i" / "p" / "h" /
+                      "c" / "r" / "t"
+   transformers     = *DIGIT [ "r" ]
+   delimiter        = "." / "-" / "+" / "," / "/" / "_" / "="
+
+   name             = ALPHA *( ALPHA / DIGIT / "-" / "_" / "." )
+
+   header-field     = "Received-SPF:" [CFWS] result FWS [comment FWS]
+                      [ key-value-list ] CRLF
+
+   result           = "Pass" / "Fail" / "SoftFail" / "Neutral" /
+                      "None" / "TempError" / "PermError"
+
+   key-value-list   = key-value-pair *( ";" [CFWS] key-value-pair )
+                      [";"]
+
+   key-value-pair   = key [CFWS] "=" ( dot-atom / quoted-string )
+
+   key              = "client-ip" / "envelope-from" / "helo" /
+                      "problem" / "receiver" / "identity" /
+                       mechanism / "x-" name / name
+
+   identity         = "mailfrom"   ; for the "MAIL FROM" identity
+                      / "helo"     ; for the "HELO" identity
+                      / name       ; other identities
+
+   dot-atom         = <unquoted word as per [RFC2822]>
+   quoted-string    = <quoted string as per [RFC2822]>
+   comment          = <comment string as per [RFC2822]>
+   CFWS             = <comment or folding white space as per [RFC2822]>
+   FWS              = <folding white space as per [RFC2822]>
+   CRLF             = <standard end-of-line token as per [RFC2822]>
+
+
+
+Wong & Schlitt                Experimental                     [Page 43]
+
+RFC 4408             Sender Policy Framework (SPF)            April 2006
+
+
+Appendix B.  Extended Examples
+
+   These examples are based on the following DNS setup:
+
+   ; A domain with two mail servers, two hosts
+   ; and two servers at the domain name
+   $ORIGIN example.com.
+   @           MX  10 mail-a
+               MX  20 mail-b
+               A   192.0.2.10
+               A   192.0.2.11
+   amy         A   192.0.2.65
+   bob         A   192.0.2.66
+   mail-a      A   192.0.2.129
+   mail-b      A   192.0.2.130
+   www         CNAME example.com.
+
+   ; A related domain
+   $ORIGIN example.org.
+   @           MX  10 mail-c
+   mail-c      A   192.0.2.140
+
+   ; The reverse IP for those addresses
+   $ORIGIN 2.0.192.in-addr.arpa.
+   10          PTR example.com.
+   11          PTR example.com.
+   65          PTR amy.example.com.
+   66          PTR bob.example.com.
+   129         PTR mail-a.example.com.
+   130         PTR mail-b.example.com.
+   140         PTR mail-c.example.org.
+
+   ; A rogue reverse IP domain that claims to be
+   ; something it's not
+   $ORIGIN 0.0.10.in-addr.arpa.
+   4           PTR bob.example.com.
+
+B.1.  Simple Examples
+
+   These examples show various possible published records for
+   example.com and which values if <ip> would cause check_host() to
+   return "Pass".  Note that <domain> is "example.com".
+
+   v=spf1 +all
+      -- any <ip> passes
+
+   v=spf1 a -all
+      -- hosts 192.0.2.10 and 192.0.2.11 pass
+
+
+
+Wong & Schlitt                Experimental                     [Page 44]
+
+RFC 4408             Sender Policy Framework (SPF)            April 2006
+
+
+   v=spf1 a:example.org -all
+      -- no sending hosts pass since example.org has no A records
+
+   v=spf1 mx -all
+      -- sending hosts 192.0.2.129 and 192.0.2.130 pass
+
+   v=spf1 mx:example.org -all
+      -- sending host 192.0.2.140 passes
+
+   v=spf1 mx mx:example.org -all
+      -- sending hosts 192.0.2.129, 192.0.2.130, and 192.0.2.140 pass
+
+   v=spf1 mx/30 mx:example.org/30 -all
+      -- any sending host in 192.0.2.128/30 or 192.0.2.140/30 passes
+
+   v=spf1 ptr -all
+      -- sending host 192.0.2.65 passes (reverse DNS is valid and is in
+         example.com)
+      -- sending host 192.0.2.140 fails (reverse DNS is valid, but not
+         in example.com)
+      -- sending host 10.0.0.4 fails (reverse IP is not valid)
+
+   v=spf1 ip4:192.0.2.128/28 -all
+      -- sending host 192.0.2.65 fails
+      -- sending host 192.0.2.129 passes
+
+B.2.  Multiple Domain Example
+
+   These examples show the effect of related records:
+
+      example.org: "v=spf1 include:example.com include:example.net -all"
+
+   This record would be used if mail from example.org actually came
+   through servers at example.com and example.net.  Example.org's
+   designated servers are the union of example.com's and example.net's
+   designated servers.
+
+      la.example.org: "v=spf1 redirect=example.org"
+      ny.example.org: "v=spf1 redirect=example.org"
+      sf.example.org: "v=spf1 redirect=example.org"
+
+   These records allow a set of domains that all use the same mail
+   system to make use of that mail system's record.  In this way, only
+   the mail system's record needs to be updated when the mail setup
+   changes.  These domains' records never have to change.
+
+
+
+
+
+
+Wong & Schlitt                Experimental                     [Page 45]
+
+RFC 4408             Sender Policy Framework (SPF)            April 2006
+
+
+B.3.  DNSBL Style Example
+
+   Imagine that, in addition to the domain records listed above, there
+   are these:
+
+   $ORIGIN _spf.example.com.  mary.mobile-users                   A
+   127.0.0.2 fred.mobile-users                   A 127.0.0.2
+   15.15.168.192.joel.remote-users     A 127.0.0.2
+   16.15.168.192.joel.remote-users     A 127.0.0.2
+
+   The following records describe users at example.com who mail from
+   arbitrary servers, or who mail from personal servers.
+
+   example.com:
+
+   v=spf1 mx
+          include:mobile-users._spf.%{d}
+          include:remote-users._spf.%{d}
+          -all
+
+   mobile-users._spf.example.com:
+
+   v=spf1 exists:%{l1r+}.%{d}
+
+   remote-users._spf.example.com:
+
+   v=spf1 exists:%{ir}.%{l1r+}.%{d}
+
+B.4.  Multiple Requirements Example
+
+   Say that your sender policy requires both that the IP address is
+   within a certain range and that the reverse DNS for the IP matches.
+   This can be done several ways, including the following:
+
+   example.com.           SPF  ( "v=spf1 "
+                                 "-include:ip4._spf.%{d} "
+                                 "-include:ptr._spf.%{d} "
+                                 "+all" )
+   ip4._spf.example.com.  SPF  "v=spf1 -ip4:192.0.2.0/24 +all"
+   ptr._spf.example.com.  SPF  "v=spf1 -ptr +all"
+
+   This example shows how the "-include" mechanism can be useful, how an
+   SPF record that ends in "+all" can be very restrictive, and the use
+   of De Morgan's Law.
+
+
+
+
+
+
+
+Wong & Schlitt                Experimental                     [Page 46]
+
+RFC 4408             Sender Policy Framework (SPF)            April 2006
+
+
+Authors' Addresses
+
+   Meng Weng Wong
+   Singapore
+
+   EMail: mengwong+spf@pobox.com
+
+
+   Wayne Schlitt
+   4615 Meredeth #9
+   Lincoln Nebraska, NE  68506
+   United States of America
+
+   EMail: wayne@schlitt.net
+   URI:   http://www.schlitt.net/spf/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wong & Schlitt                Experimental                     [Page 47]
+
+RFC 4408             Sender Policy Framework (SPF)            April 2006
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2006).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Wong & Schlitt                Experimental                     [Page 48]
+
diff --git a/doc/rfc/rfc4431.txt b/doc/rfc/rfc4431.txt
new file mode 100644
index 0000000..8b38872
--- /dev/null
+++ b/doc/rfc/rfc4431.txt
@@ -0,0 +1,227 @@
+
+
+
+
+
+
+Network Working Group                                         M. Andrews
+Request for Comments: 4431                   Internet Systems Consortium
+Category: Informational                                        S. Weiler
+                                                            SPARTA, Inc.
+                                                           February 2006
+
+
+       The DNSSEC Lookaside Validation (DLV) DNS Resource Record
+
+Status of This Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   This document defines a new DNS resource record, called the DNSSEC
+   Lookaside Validation (DLV) RR, for publishing DNSSEC trust anchors
+   outside of the DNS delegation chain.
+
+1.  Introduction
+
+   DNSSEC [1] [2] [3] authenticates DNS data by building public-key
+   signature chains along the DNS delegation chain from a trust anchor,
+   ideally a trust anchor for the DNS root.
+
+   This document defines a new resource record for publishing such trust
+   anchors outside of the DNS's normal delegation chain.  Use of these
+   records by DNSSEC validators is outside the scope of this document,
+   but it is expected that these records will help resolvers validate
+   DNSSEC-signed data from zones whose ancestors either aren't signed or
+   refuse to publish delegation signer (DS) records for their children.
+
+2.  DLV Resource Record
+
+   The DLV resource record has exactly the same wire and presentation
+   formats as the DS resource record, defined in RFC 4034, Section 5.
+   It uses the same IANA-assigned values in the algorithm and digest
+   type fields as the DS record.  (Those IANA registries are known as
+   the "DNS Security Algorithm Numbers" and "DS RR Type Algorithm
+   Numbers" registries.)
+
+
+
+
+
+Andrews & Weiler             Informational                      [Page 1]
+
+RFC 4431                  DLV Resource Record              February 2006
+
+
+   The DLV record is a normal DNS record type without any special
+   processing requirements.  In particular, the DLV record does not
+   inherit any of the special processing or handling requirements of the
+   DS record type (described in Section 3.1.4.1 of RFC 4035).  Unlike
+   the DS record, the DLV record may not appear on the parent's side of
+   a zone cut.  A DLV record may, however, appear at the apex of a zone.
+
+3.  Security Considerations
+
+   For authoritative servers and resolvers that do not attempt to use
+   DLV RRs as part of DNSSEC validation, there are no particular
+   security concerns -- DLV RRs are just like any other DNS data.
+
+   Software using DLV RRs as part of DNSSEC validation will almost
+   certainly want to impose constraints on their use, but those
+   constraints are best left to be described by the documents that more
+   fully describe the particulars of how the records are used.  At a
+   minimum, it would be unwise to use the records without some sort of
+   cryptographic authentication.  More likely than not, DNSSEC itself
+   will be used to authenticate the DLV RRs.  Depending on how a DLV RR
+   is used, failure to properly authenticate it could lead to
+   significant additional security problems including failure to detect
+   spoofed DNS data.
+
+   RFC 4034, Section 8, describes security considerations specific to
+   the DS RR.  Those considerations are equally applicable to DLV RRs.
+   Of particular note, the key tag field is used to help select DNSKEY
+   RRs efficiently, but it does not uniquely identify a single DNSKEY
+   RR.  It is possible for two distinct DNSKEY RRs to have the same
+   owner name, the same algorithm type, and the same key tag.  An
+   implementation that uses only the key tag to select a DNSKEY RR might
+   select the wrong public key in some circumstances.
+
+   For further discussion of the security implications of DNSSEC, see
+   RFC 4033, RFC 4034, and RFC 4035.
+
+4.  IANA Considerations
+
+   IANA has assigned DNS type code 32769 to the DLV resource record from
+   the Specification Required portion of the DNS Resource Record Type
+   registry, as defined in [4].
+
+   The DLV resource record reuses the same algorithm and digest type
+   registries already used for the DS resource record, currently known
+   as the "DNS Security Algorithm Numbers" and "DS RR Type Algorithm
+   Numbers" registries.
+
+
+
+
+
+Andrews & Weiler             Informational                      [Page 2]
+
+RFC 4431                  DLV Resource Record              February 2006
+
+
+5.  Normative References
+
+   [1]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+        "DNS Security Introduction and Requirements", RFC 4033,
+        March 2005.
+
+   [2]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+        "Resource Records for the DNS Security Extensions", RFC 4034,
+        March 2005.
+
+   [3]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+        "Protocol Modifications for the DNS Security Extensions",
+        RFC 4035, March 2005.
+
+   [4]  Eastlake, D., Brunner-Williams, E., and B. Manning, "Domain Name
+        System (DNS) IANA Considerations", BCP 42, RFC 2929,
+        September 2000.
+
+Authors' Addresses
+
+   Mark Andrews
+   Internet Systems Consortium
+   950 Charter St.
+   Redwood City, CA  94063
+   US
+
+   EMail: Mark_Andrews@isc.org
+
+
+   Samuel Weiler
+   SPARTA, Inc.
+   7075 Samuel Morse Drive
+   Columbia, Maryland  21046
+   US
+
+   EMail: weiler@tislabs.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Andrews & Weiler             Informational                      [Page 3]
+
+RFC 4431                  DLV Resource Record              February 2006
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2006).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Andrews & Weiler             Informational                      [Page 4]
+
diff --git a/doc/rfc/rfc4470.txt b/doc/rfc/rfc4470.txt
new file mode 100644
index 0000000..ac12d65
--- /dev/null
+++ b/doc/rfc/rfc4470.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+Network Working Group                                          S. Weiler
+Request for Comments: 4470                                  SPARTA, Inc.
+Updates: 4035, 4034                                             J. Ihren
+Category: Standards Track                                  Autonomica AB
+                                                              April 2006
+
+
+       Minimally Covering NSEC Records and DNSSEC On-line Signing
+
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   This document describes how to construct DNSSEC NSEC resource records
+   that cover a smaller range of names than called for by RFC 4034.  By
+   generating and signing these records on demand, authoritative name
+   servers can effectively stop the disclosure of zone contents
+   otherwise made possible by walking the chain of NSEC records in a
+   signed zone.
+
+Table of Contents
+
+   1. Introduction ....................................................1
+   2. Applicability of This Technique .................................2
+   3. Minimally Covering NSEC Records .................................2
+   4. Better Epsilon Functions ........................................4
+   5. Security Considerations .........................................5
+   6. Acknowledgements ................................................6
+   7. Normative References ............................................6
+
+1.  Introduction
+
+   With DNSSEC [1], an NSEC record lists the next instantiated name in
+   its zone, proving that no names exist in the "span" between the
+   NSEC's owner name and the name in the "next name" field.  In this
+   document, an NSEC record is said to "cover" the names between its
+   owner name and next name.
+
+
+
+Weiler & Ihren              Standards Track                     [Page 1]
+
+RFC 4470                      NSEC Epsilon                    April 2006
+
+
+   Through repeated queries that return NSEC records, it is possible to
+   retrieve all of the names in the zone, a process commonly called
+   "walking" the zone.  Some zone owners have policies forbidding zone
+   transfers by arbitrary clients; this side effect of the NSEC
+   architecture subverts those policies.
+
+   This document presents a way to prevent zone walking by constructing
+   NSEC records that cover fewer names.  These records can make zone
+   walking take approximately as many queries as simply asking for all
+   possible names in a zone, making zone walking impractical.  Some of
+   these records must be created and signed on demand, which requires
+   on-line private keys.  Anyone contemplating use of this technique is
+   strongly encouraged to review the discussion of the risks of on-line
+   signing in Section 5.
+
+1.2.  Keywords
+
+   The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [4].
+
+2.  Applicability of This Technique
+
+   The technique presented here may be useful to a zone owner that wants
+   to use DNSSEC, is concerned about exposure of its zone contents via
+   zone walking, and is willing to bear the costs of on-line signing.
+
+   As discussed in Section 5, on-line signing has several security
+   risks, including an increased likelihood of private keys being
+   disclosed and an increased risk of denial of service attack.  Anyone
+   contemplating use of this technique is strongly encouraged to review
+   the discussion of the risks of on-line signing in Section 5.
+
+   Furthermore, at the time this document was published, the DNSEXT
+   working group was actively working on a mechanism to prevent zone
+   walking that does not require on-line signing (tentatively called
+   NSEC3).  The new mechanism is likely to expose slightly more
+   information about the zone than this technique (e.g., the number of
+   instantiated names), but it may be preferable to this technique.
+
+3.  Minimally Covering NSEC Records
+
+   This mechanism involves changes to NSEC records for instantiated
+   names, which can still be generated and signed in advance, as well as
+   the on-demand generation and signing of new NSEC records whenever a
+   name must be proven not to exist.
+
+
+
+
+
+Weiler & Ihren              Standards Track                     [Page 2]
+
+RFC 4470                      NSEC Epsilon                    April 2006
+
+
+   In the "next name" field of instantiated names' NSEC records, rather
+   than list the next instantiated name in the zone, list any name that
+   falls lexically after the NSEC's owner name and before the next
+   instantiated name in the zone, according to the ordering function in
+   RFC 4034 [2] Section 6.1.  This relaxes the requirement in Section
+   4.1.1 of RFC 4034 that the "next name" field contains the next owner
+   name in the zone.  This change is expected to be fully compatible
+   with all existing DNSSEC validators.  These NSEC records are returned
+   whenever proving something specifically about the owner name (e.g.,
+   that no resource records of a given type appear at that name).
+
+   Whenever an NSEC record is needed to prove the non-existence of a
+   name, a new NSEC record is dynamically produced and signed.  The new
+   NSEC record has an owner name lexically before the QNAME but
+   lexically following any existing name and a "next name" lexically
+   following the QNAME but before any existing name.
+
+   The generated NSEC record's type bitmap MUST have the RRSIG and NSEC
+   bits set and SHOULD NOT have any other bits set.  This relaxes the
+   requirement in Section 2.3 of RFC4035 that NSEC RRs not appear at
+   names that did not exist before the zone was signed.
+
+   The functions to generate the lexically following and proceeding
+   names need not be perfect or consistent, but the generated NSEC
+   records must not cover any existing names.  Furthermore, this
+   technique works best when the generated NSEC records cover as few
+   names as possible.  In this document, the functions that generate the
+   nearby names are called "epsilon" functions, a reference to the
+   mathematical convention of using the greek letter epsilon to
+   represent small deviations.
+
+   An NSEC record denying the existence of a wildcard may be generated
+   in the same way.  Since the NSEC record covering a non-existent
+   wildcard is likely to be used in response to many queries,
+   authoritative name servers using the techniques described here may
+   want to pregenerate or cache that record and its corresponding RRSIG.
+
+   For example, a query for an A record at the non-instantiated name
+   example.com might produce the following two NSEC records, the first
+   denying the existence of the name example.com and the second denying
+   the existence of a wildcard:
+
+          exampld.com 3600 IN NSEC example-.com ( RRSIG NSEC )
+
+          \).com 3600 IN NSEC +.com ( RRSIG NSEC )
+
+
+
+
+
+
+Weiler & Ihren              Standards Track                     [Page 3]
+
+RFC 4470                      NSEC Epsilon                    April 2006
+
+
+   Before answering a query with these records, an authoritative server
+   must test for the existence of names between these endpoints.  If the
+   generated NSEC would cover existing names (e.g., exampldd.com or
+   *bizarre.example.com), a better epsilon function may be used or the
+   covered name closest to the QNAME could be used as the NSEC owner
+   name or next name, as appropriate.  If an existing name is used as
+   the NSEC owner name, that name's real NSEC record MUST be returned.
+   Using the same example, assuming an exampldd.com delegation exists,
+   this record might be returned from the parent:
+
+          exampldd.com 3600 IN NSEC example-.com ( NS DS RRSIG NSEC )
+
+   Like every authoritative record in the zone, each generated NSEC
+   record MUST have corresponding RRSIGs generated using each algorithm
+   (but not necessarily each DNSKEY) in the zone's DNSKEY RRset, as
+   described in RFC 4035 [3] Section 2.2.  To minimize the number of
+   signatures that must be generated, a zone may wish to limit the
+   number of algorithms in its DNSKEY RRset.
+
+4.  Better Epsilon Functions
+
+   Section 6.1 of RFC 4034 defines a strict ordering of DNS names.
+   Working backward from that definition, it should be possible to
+   define epsilon functions that generate the immediately following and
+   preceding names, respectively.  This document does not define such
+   functions.  Instead, this section presents functions that come
+   reasonably close to the perfect ones.  As described above, an
+   authoritative server should still ensure than no generated NSEC
+   covers any existing name.
+
+   To increment a name, add a leading label with a single null (zero-
+   value) octet.
+
+   To decrement a name, decrement the last character of the leftmost
+   label, then fill that label to a length of 63 octets with octets of
+   value 255.  To decrement a null (zero-value) octet, remove the octet
+   -- if an empty label is left, remove the label.  Defining this
+   function numerically: fill the leftmost label to its maximum length
+   with zeros (numeric, not ASCII zeros) and subtract one.
+
+   In response to a query for the non-existent name foo.example.com,
+   these functions produce NSEC records of the following:
+
+
+
+
+
+
+
+
+
+Weiler & Ihren              Standards Track                     [Page 4]
+
+RFC 4470                      NSEC Epsilon                    April 2006
+
+
+     fon\255\255\255\255\255\255\255\255\255\255\255\255\255\255
+     \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
+     \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
+     \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
+     \255.example.com 3600 IN NSEC \000.foo.example.com ( NSEC RRSIG )
+
+     \)\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
+     \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
+     \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
+     \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
+     \255\255.example.com 3600 IN NSEC \000.*.example.com ( NSEC RRSIG )
+
+   The first of these NSEC RRs proves that no exact match for
+   foo.example.com exists, and the second proves that there is no
+   wildcard in example.com.
+
+   Both of these functions are imperfect: they do not take into account
+   constraints on number of labels in a name nor total length of a name.
+   As noted in the previous section, though, this technique does not
+   depend on the use of perfect epsilon functions: it is sufficient to
+   test whether any instantiated names fall into the span covered by the
+   generated NSEC and, if so, substitute those instantiated owner names
+   for the NSEC owner name or next name, as appropriate.
+
+5.  Security Considerations
+
+   This approach requires on-demand generation of RRSIG records.  This
+   creates several new vulnerabilities.
+
+   First, on-demand signing requires that a zone's authoritative servers
+   have access to its private keys.  Storing private keys on well-known
+   Internet-accessible servers may make them more vulnerable to
+   unintended disclosure.
+
+   Second, since generation of digital signatures tends to be
+   computationally demanding, the requirement for on-demand signing
+   makes authoritative servers vulnerable to a denial of service attack.
+
+   Last, if the epsilon functions are predictable, on-demand signing may
+   enable a chosen-plaintext attack on a zone's private keys.  Zones
+   using this approach should attempt to use cryptographic algorithms
+   that are resistant to chosen-plaintext attacks.  It is worth noting
+   that although DNSSEC has a "mandatory to implement" algorithm, that
+   is a requirement on resolvers and validators -- there is no
+   requirement that a zone be signed with any given algorithm.
+
+   The success of using minimally covering NSEC records to prevent zone
+   walking depends greatly on the quality of the epsilon functions
+
+
+
+Weiler & Ihren              Standards Track                     [Page 5]
+
+RFC 4470                      NSEC Epsilon                    April 2006
+
+
+   chosen.  An increment function that chooses a name obviously derived
+   from the next instantiated name may be easily reverse engineered,
+   destroying the value of this technique.  An increment function that
+   always returns a name close to the next instantiated name is likewise
+   a poor choice.  Good choices of epsilon functions are the ones that
+   produce the immediately following and preceding names, respectively,
+   though zone administrators may wish to use less perfect functions
+   that return more human-friendly names than the functions described in
+   Section 4 above.
+
+   Another obvious but misguided concern is the danger from synthesized
+   NSEC records being replayed.  It is possible for an attacker to
+   replay an old but still validly signed NSEC record after a new name
+   has been added in the span covered by that NSEC, incorrectly proving
+   that there is no record at that name.  This danger exists with DNSSEC
+   as defined in [3].  The techniques described here actually decrease
+   the danger, since the span covered by any NSEC record is smaller than
+   before.  Choosing better epsilon functions will further reduce this
+   danger.
+
+6.  Acknowledgements
+
+   Many individuals contributed to this design.  They include, in
+   addition to the authors of this document, Olaf Kolkman, Ed Lewis,
+   Peter Koch, Matt Larson, David Blacka, Suzanne Woolf, Jaap Akkerhuis,
+   Jakob Schlyter, Bill Manning, and Joao Damas.
+
+   In addition, the editors would like to thank Ed Lewis, Scott Rose,
+   and David Blacka for their careful review of the document.
+
+7.  Normative References
+
+   [1]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+        "DNS Security Introduction and Requirements", RFC 4033, March
+        2005.
+
+   [2]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+        "Resource Records for the DNS Security Extensions", RFC 4034,
+        March 2005.
+
+   [3]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+        "Protocol Modifications for the DNS Security Extensions", RFC
+        4035, March 2005.
+
+   [4]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
+        Levels", BCP 14, RFC 2119, March 1997.
+
+
+
+
+
+Weiler & Ihren              Standards Track                     [Page 6]
+
+RFC 4470                      NSEC Epsilon                    April 2006
+
+
+Authors' Addresses
+
+   Samuel Weiler
+   SPARTA, Inc.
+   7075 Samuel Morse Drive
+   Columbia, Maryland  21046
+   US
+
+   EMail: weiler@tislabs.com
+
+
+   Johan Ihren
+   Autonomica AB
+   Bellmansgatan 30
+   Stockholm  SE-118 47
+   Sweden
+
+   EMail: johani@autonomica.se
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Weiler & Ihren              Standards Track                     [Page 7]
+
+RFC 4470                      NSEC Epsilon                    April 2006
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2006).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Weiler & Ihren              Standards Track                     [Page 8]
+
diff --git a/doc/rfc/rfc4634.txt b/doc/rfc/rfc4634.txt
new file mode 100644
index 0000000..b672df8
--- /dev/null
+++ b/doc/rfc/rfc4634.txt
@@ -0,0 +1,6051 @@
+
+
+
+
+
+
+Network Working Group                                    D. Eastlake 3rd
+Request for Comments: 4634                                 Motorola Labs
+Updates: 3174                                                  T. Hansen
+Category: Informational                                        AT&T Labs
+                                                               July 2006
+
+
+              US Secure Hash Algorithms (SHA and HMAC-SHA)
+
+Status of This Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   The United States of America has adopted a suite of Secure Hash
+   Algorithms (SHAs), including four beyond SHA-1, as part of a Federal
+   Information Processing Standard (FIPS), specifically SHA-224 (RFC
+   3874), SHA-256, SHA-384, and SHA-512.  The purpose of this document
+   is to make source code performing these hash functions conveniently
+   available to the Internet community.  The sample code supports input
+   strings of arbitrary bit length.  SHA-1's sample code from RFC 3174
+   has also been updated to handle input strings of arbitrary bit
+   length.  Most of the text herein was adapted by the authors from FIPS
+   180-2.
+
+   Code to perform SHA-based HMACs, with arbitrary bit length text, is
+   also included.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake 3rd & Hansen        Informational                      [Page 1]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+Table of Contents
+
+   1. Overview of Contents ............................................3
+      1.1. License ....................................................4
+   2. Notation for Bit Strings and Integers ...........................4
+   3. Operations on Words .............................................5
+   4. Message Padding and Parsing .....................................6
+      4.1. SHA-224 and SHA-256 ........................................7
+      4.2. SHA-384 and SHA-512 ........................................8
+   5. Functions and Constants Used ....................................9
+      5.1. SHA-224 and SHA-256 ........................................9
+      5.2. SHA-384 and SHA-512 .......................................10
+   6. Computing the Message Digest ...................................11
+      6.1. SHA-224 and SHA-256 Initialization ........................11
+      6.2. SHA-224 and SHA-256 Processing ............................11
+      6.3. SHA-384 and SHA-512 Initialization ........................13
+      6.4. SHA-384 and SHA-512 Processing ............................14
+   7. SHA-Based HMACs ................................................15
+   8. C Code for SHAs ................................................15
+      8.1. The .h File ...............................................18
+      8.2. The SHA Code ..............................................24
+           8.2.1. sha1.c .............................................24
+           8.2.2. sha224-256.c .......................................33
+           8.2.3. sha384-512.c .......................................45
+           8.2.4. usha.c .............................................67
+           8.2.5. sha-private.h ......................................72
+      8.3. The HMAC Code .............................................73
+      8.4. The Test Driver ...........................................78
+   9. Security Considerations .......................................106
+   10. Normative References .........................................106
+   11. Informative References .......................................106
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake 3rd & Hansen        Informational                      [Page 2]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+1.  Overview of Contents
+
+   NOTE: Much of the text below is taken from [FIPS180-2] and assertions
+   therein of the security of the algorithms described are made by the
+   US Government, the author of [FIPS180-2], and not by the authors of
+   this document.
+
+   The text below specifies Secure Hash Algorithms, SHA-224 [RFC3874],
+   SHA-256, SHA-384, and SHA-512, for computing a condensed
+   representation of a message or a data file. (SHA-1 is specified in
+   [RFC3174].)  When a message of any length < 2^64 bits (for SHA-224
+   and SHA-256) or < 2^128 bits (for SHA-384 and SHA-512) is input to
+   one of these algorithms, the result is an output called a message
+   digest.  The message digests range in length from 224 to 512 bits,
+   depending on the algorithm.  Secure hash algorithms are typically
+   used with other cryptographic algorithms, such as digital signature
+   algorithms and keyed hash authentication codes, or in the generation
+   of random numbers [RFC4086].
+
+   The four algorithms specified in this document are called secure
+   because it is computationally infeasible to (1) find a message that
+   corresponds to a given message digest, or (2) find two different
+   messages that produce the same message digest.  Any change to a
+   message in transit will, with very high probability, result in a
+   different message digest.  This will result in a verification failure
+   when the secure hash algorithm is used with a digital signature
+   algorithm or a keyed-hash message authentication algorithm.
+
+   The code provided herein supports input strings of arbitrary bit
+   length.  SHA-1's sample code from [RFC3174] has also been updated to
+   handle input strings of arbitrary bit length.  See Section 1.1 for
+   license information for this code.
+
+   Section 2 below defines the terminology and functions used as
+   building blocks to form these algorithms.  Section 3 describes the
+   fundamental operations on words from which these algorithms are
+   built.  Section 4 describes how messages are padded up to an integral
+   multiple of the required block size and then parsed into blocks.
+   Section 5 defines the constants and the composite functions used to
+   specify these algorithms.  Section 6 gives the actual specification
+   for the SHA-224, SHA-256, SHA-384, and SHA-512 functions.  Section 7
+   provides pointers to the specification of HMAC keyed message
+   authentication codes based on the SHA algorithms.  Section 8 gives
+   sample code for the SHA algorithms and Section 9 code for SHA-based
+   HMACs.  The SHA-based HMACs will accept arbitrary bit length text.
+
+
+
+
+
+
+Eastlake 3rd & Hansen        Informational                      [Page 3]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+1.1.  License
+
+   Permission is granted for all uses, commercial and non-commercial, of
+   the sample code found in Section 8.  Royalty free license to use,
+   copy, modify and distribute the software found in Section 8 is
+   granted, provided that this document is identified in all material
+   mentioning or referencing this software, and provided that
+   redistributed derivative works do not contain misleading author or
+   version information.
+
+   The authors make no representations concerning either the
+   merchantability of this software or the suitability of this software
+   for any particular purpose.  It is provided "as is" without express
+   or implied warranty of any kind.
+
+2.  Notation for Bit Strings and Integers
+
+   The following terminology related to bit strings and integers will be
+   used:
+
+    a.  A hex digit is an element of the set {0, 1, ... , 9, A, ... ,
+        F}.  A hex digit is the representation of a 4-bit string.
+        Examples: 7 = 0111, A = 1010.
+
+    b.  A word equals a 32-bit or 64-bit string, which may be
+        represented as a sequence of 8 or 16 hex digits, respectively.
+        To convert a word to hex digits, each 4-bit string is converted
+        to its hex equivalent as described in (a) above.  Example:
+
+        1010 0001 0000 0011 1111 1110 0010 0011 = A103FE23.
+
+        Throughout this document, the "big-endian" convention is used
+        when expressing both 32-bit and 64-bit words, so that within
+        each word the most significant bit is shown in the left-most bit
+        position.
+
+    c.  An integer may be represented as a word or pair of words.
+
+        An integer between 0 and 2^32 - 1 inclusive may be represented
+        as a 32-bit word.  The least significant four bits of the
+        integer are represented by the right-most hex digit of the word
+        representation.  Example: the integer 291 = 2^8+2^5+2^1+2^0 =
+        256+32+2+1 is represented by the hex word 00000123.
+
+        The same holds true for an integer between 0 and 2^64-1
+        inclusive, which may be represented as a 64-bit word.
+
+
+
+
+
+Eastlake 3rd & Hansen        Informational                      [Page 4]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+        If Z is an integer, 0 <= z < 2^64, then z = (2^32)x + y where 0
+        <= x < 2^32 and 0 <= y < 2^32.  Since x and y can be represented
+        as words X and Y, respectively, z can be represented as the pair
+        of words (X,Y).
+
+    d.  block = 512-bit or 1024-bit string.  A block (e.g., B) may be
+        represented as a sequence of 32-bit or 64-bit words.
+
+3.  Operations on Words
+
+   The following logical operators will be applied to words in all four
+   hash operations specified herein.  SHA-224 and SHA-256 operate on
+   32-bit words, while SHA-384 and SHA-512 operate on 64-bit words.
+
+   In the operations below, x<<n is obtained as follows: discard the
+   left-most n bits of x and then pad the result with n zeroed bits on
+   the right (the result will still be the same number of bits).
+
+    a.  Bitwise logical word operations
+
+        X AND Y  =  bitwise logical "and" of  X and Y.
+
+        X OR Y   =  bitwise logical "inclusive-or" of X and Y.
+
+        X XOR Y  =  bitwise logical "exclusive-or" of X and Y.
+
+        NOT X    =  bitwise logical "complement" of X.
+
+        Example:
+                 01101100101110011101001001111011
+           XOR   01100101110000010110100110110111
+                 --------------------------------
+             =   00001001011110001011101111001100
+
+    b.  The operation X + Y is defined as follows: words X and Y
+        represent w-bit integers x and y, where 0 <= x < 2^w and
+        0 <= y < 2^w.  For positive integers n and m, let
+
+             n mod m
+
+        be the remainder upon dividing n by m.  Compute
+
+             z  =  (x + y) mod 2^w.
+
+        Then 0 <= z < 2^w.  Convert z to a word, Z, and define Z = X +
+        Y.
+
+
+
+
+
+Eastlake 3rd & Hansen        Informational                      [Page 5]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+    c.  The right shift operation SHR^n(x), where x is a w-bit word and
+        n is an integer with 0 <= n < w, is defined by
+
+             SHR^n(x) = x>>n
+
+    d.  The rotate right (circular right shift) operation ROTR^n(x),
+        where x is a w-bit word and n is an integer with 0 <= n < w, is
+        defined by
+
+             ROTR^n(x) = (x>>n) OR (x<<(w-n))
+
+    e.  The rotate left (circular left shift) operation ROTL^n(x), where
+        x is a w-bit word and n is an integer with 0 <= n < w, is
+        defined by
+
+             ROTL^n(X)  =  (x<<n) OR (x>>w-n)
+
+        Note the following equivalence relationships, where w is fixed
+        in each relationship:
+
+             ROTL^n(x) = ROTR^(w-x)(x)
+
+             ROTR^n(x) = ROTL^(w-n)(x)
+
+4.  Message Padding and Parsing
+
+   The hash functions specified herein are used to compute a message
+   digest for a message or data file that is provided as input.  The
+   message or data file should be considered to be a bit string.  The
+   length of the message is the number of bits in the message (the empty
+   message has length 0).  If the number of bits in a message is a
+   multiple of 8, for compactness we can represent the message in hex.
+   The purpose of message padding is to make the total length of a
+   padded message a multiple of 512 for SHA-224 and SHA-256 or a
+   multiple of 1024 for SHA-384 and SHA-512.
+
+   The following specifies how this padding shall be performed.  As a
+   summary, a "1" followed by a number of "0"s followed by a 64-bit or
+   128-bit integer are appended to the end of the message to produce a
+   padded message of length 512*n or 1024*n.  The minimum number of "0"s
+   necessary to meet this criterion is used.  The appended integer is
+   the length of the original message.  The padded message is then
+   processed by the hash function as n 512-bit or 1024-bit blocks.
+
+
+
+
+
+
+
+
+Eastlake 3rd & Hansen        Informational                      [Page 6]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+4.1.  SHA-224 and SHA-256
+
+   Suppose a message has length L < 2^64.  Before it is input to the
+   hash function, the message is padded on the right as follows:
+
+    a.  "1" is appended.  Example: if the original message is
+        "01010000", this is padded to "010100001".
+
+    b.  K "0"s are appended where K is the smallest, non-negative
+        solution to the equation
+
+             L + 1 + K = 448 (mod 512)
+
+    c.  Then append the 64-bit block that is L in binary representation.
+        After appending this block, the length of the message will be a
+        multiple of 512 bits.
+
+        Example:  Suppose the original message is the bit string
+
+             01100001 01100010 01100011 01100100 01100101
+
+        After step (a), this gives
+
+             01100001 01100010 01100011 01100100 01100101 1
+
+        Since L = 40, the number of bits in the above is 41 and K = 407
+        "0"s are appended, making the total now 448.  This gives the
+        following in hex:
+
+             61626364 65800000 00000000 00000000
+             00000000 00000000 00000000 00000000
+             00000000 00000000 00000000 00000000
+             00000000 00000000
+
+        The 64-bit representation of L = 40 is hex 00000000 00000028.
+        Hence the final padded message is the following hex:
+
+             61626364 65800000 00000000 00000000
+             00000000 00000000 00000000 00000000
+             00000000 00000000 00000000 00000000
+             00000000 00000000 00000000 00000028
+
+
+
+
+
+
+
+
+
+
+Eastlake 3rd & Hansen        Informational                      [Page 7]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+4.2.  SHA-384 and SHA-512
+
+   Suppose a message has length L < 2^128.  Before it is input to the
+   hash function, the message is padded on the right as follows:
+
+    a.  "1" is appended.  Example: if the original message is
+        "01010000", this is padded to "010100001".
+
+    b.  K "0"s are appended where K is the smallest, non-negative
+        solution to the equation
+
+             L + 1 + K = 896 (mod 1024)
+
+    c.  Then append the 128-bit block that is L in binary
+        representation.  After appending this block, the length of the
+        message will be a multiple of 1024 bits.
+
+        Example:  Suppose the original message is the bit string
+
+             01100001 01100010 01100011 01100100 01100101
+
+        After step (a) this gives
+
+             01100001 01100010 01100011 01100100 01100101 1
+
+        Since L = 40, the number of bits in the above is 41 and K = 855
+        "0"s are appended, making the total now 896.  This gives the
+        following in hex:
+
+             61626364 65800000 00000000 00000000
+             00000000 00000000 00000000 00000000
+             00000000 00000000 00000000 00000000
+             00000000 00000000 00000000 00000000
+             00000000 00000000 00000000 00000000
+             00000000 00000000 00000000 00000000
+             00000000 00000000 00000000 00000000
+
+        The 128-bit representation of L = 40 is hex 00000000 00000000
+        00000000 00000028.  Hence the final padded message is the
+        following hex:
+
+             61626364 65800000 00000000 00000000
+             00000000 00000000 00000000 00000000
+             00000000 00000000 00000000 00000000
+             00000000 00000000 00000000 00000000
+             00000000 00000000 00000000 00000000
+
+
+
+
+
+Eastlake 3rd & Hansen        Informational                      [Page 8]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+             00000000 00000000 00000000 00000000
+             00000000 00000000 00000000 00000000
+             00000000 00000000 00000000 00000028
+
+5.  Functions and Constants Used
+
+   The following subsections give the six logical functions and the
+   table of constants used in each of the hash functions.
+
+5.1.  SHA-224 and SHA-256
+
+   SHA-224 and SHA-256 use six logical functions, where each function
+   operates on 32-bit words, which are represented as x, y, and z.  The
+   result of each function is a new 32-bit word.
+
+        CH( x, y, z) = (x AND y) XOR ( (NOT x) AND z)
+
+        MAJ( x, y, z) = (x AND y) XOR (x AND z) XOR (y AND z)
+
+        BSIG0(x) = ROTR^2(x) XOR ROTR^13(x) XOR ROTR^22(x)
+
+        BSIG1(x) = ROTR^6(x) XOR ROTR^11(x) XOR ROTR^25(x)
+
+        SSIG0(x) = ROTR^7(x) XOR ROTR^18(x) XOR SHR^3(x)
+
+        SSIG1(x) = ROTR^17(x) XOR ROTR^19(x) XOR SHR^10(x)
+
+   SHA-224 and SHA-256 use the same sequence of sixty-four constant
+   32-bit words, K0, K1, ..., K63.  These words represent the first
+   thirty-two bits of the fractional parts of the cube roots of the
+   first sixty-four prime numbers.  In hex, these constant words are as
+   follows (from left to right):
+
+        428a2f98 71374491 b5c0fbcf e9b5dba5
+        3956c25b 59f111f1 923f82a4 ab1c5ed5
+        d807aa98 12835b01 243185be 550c7dc3
+        72be5d74 80deb1fe 9bdc06a7 c19bf174
+        e49b69c1 efbe4786 0fc19dc6 240ca1cc
+        2de92c6f 4a7484aa 5cb0a9dc 76f988da
+        983e5152 a831c66d b00327c8 bf597fc7
+        c6e00bf3 d5a79147 06ca6351 14292967
+        27b70a85 2e1b2138 4d2c6dfc 53380d13
+        650a7354 766a0abb 81c2c92e 92722c85
+        a2bfe8a1 a81a664b c24b8b70 c76c51a3
+        d192e819 d6990624 f40e3585 106aa070
+        19a4c116 1e376c08 2748774c 34b0bcb5
+
+
+
+
+
+Eastlake 3rd & Hansen        Informational                      [Page 9]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+        391c0cb3 4ed8aa4a 5b9cca4f 682e6ff3
+        748f82ee 78a5636f 84c87814 8cc70208
+        90befffa a4506ceb bef9a3f7 c67178f2
+
+5.2.  SHA-384 and SHA-512
+
+   SHA-384 and SHA-512 each use six logical functions, where each
+   function operates on 64-bit words, which are represented as x, y, and
+   z.  The result of each function is a new 64-bit word.
+
+        CH( x, y, z) = (x AND y) XOR ( (NOT x) AND z)
+
+        MAJ( x, y, z) = (x AND y) XOR (x AND z) XOR (y AND z)
+
+        BSIG0(x) = ROTR^28(x) XOR ROTR^34(x) XOR ROTR^39(x)
+
+        BSIG1(x) = ROTR^14(x) XOR ROTR^18(x) XOR ROTR^41(x)
+
+        SSIG0(x) = ROTR^1(x) XOR ROTR^8(x) XOR SHR^7(x)
+
+        SSIG1(x) = ROTR^19(x) XOR ROTR^61(x) XOR SHR^6(x)
+
+   SHA-384 and SHA-512 use the same sequence of eighty constant 64-bit
+   words, K0, K1, ... K79.  These words represent the first sixty-four
+   bits of the fractional parts of the cube roots of the first eighty
+   prime numbers.  In hex, these constant words are as follows (from
+   left to right):
+
+   428a2f98d728ae22 7137449123ef65cd b5c0fbcfec4d3b2f e9b5dba58189dbbc
+   3956c25bf348b538 59f111f1b605d019 923f82a4af194f9b ab1c5ed5da6d8118
+   d807aa98a3030242 12835b0145706fbe 243185be4ee4b28c 550c7dc3d5ffb4e2
+   72be5d74f27b896f 80deb1fe3b1696b1 9bdc06a725c71235 c19bf174cf692694
+   e49b69c19ef14ad2 efbe4786384f25e3 0fc19dc68b8cd5b5 240ca1cc77ac9c65
+   2de92c6f592b0275 4a7484aa6ea6e483 5cb0a9dcbd41fbd4 76f988da831153b5
+   983e5152ee66dfab a831c66d2db43210 b00327c898fb213f bf597fc7beef0ee4
+   c6e00bf33da88fc2 d5a79147930aa725 06ca6351e003826f 142929670a0e6e70
+   27b70a8546d22ffc 2e1b21385c26c926 4d2c6dfc5ac42aed 53380d139d95b3df
+   650a73548baf63de 766a0abb3c77b2a8 81c2c92e47edaee6 92722c851482353b
+   a2bfe8a14cf10364 a81a664bbc423001 c24b8b70d0f89791 c76c51a30654be30
+   d192e819d6ef5218 d69906245565a910 f40e35855771202a 106aa07032bbd1b8
+   19a4c116b8d2d0c8 1e376c085141ab53 2748774cdf8eeb99 34b0bcb5e19b48a8
+   391c0cb3c5c95a63 4ed8aa4ae3418acb 5b9cca4f7763e373 682e6ff3d6b2b8a3
+   748f82ee5defb2fc 78a5636f43172f60 84c87814a1f0ab72 8cc702081a6439ec
+   90befffa23631e28 a4506cebde82bde9 bef9a3f7b2c67915 c67178f2e372532b
+   ca273eceea26619c d186b8c721c0c207 eada7dd6cde0eb1e f57d4f7fee6ed178
+   06f067aa72176fba 0a637dc5a2c898a6 113f9804bef90dae 1b710b35131c471b
+   28db77f523047d84 32caab7b40c72493 3c9ebe0a15c9bebc 431d67c49c100d4c
+   4cc5d4becb3e42b6 597f299cfc657e2a 5fcb6fab3ad6faec 6c44198c4a475817
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 10]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+6.  Computing the Message Digest
+
+   The output of each of the secure hash functions, after being applied
+   to a message of N blocks, is the hash quantity H(N).  For SHA-224 and
+   SHA-256, H(i) can be considered to be eight 32-bit words, H(i)0,
+   H(i)1, ... H(i)7.  For SHA-384 and SHA-512, it can be considered to
+   be eight 64-bit words, H(i)0, H(i)1, ..., H(i)7.
+
+   As described below, the hash words are initialized, modified as each
+   message block is processed, and finally concatenated after processing
+   the last block to yield the output.  For SHA-256 and SHA-512, all of
+   the H(N) variables are concatenated while the SHA-224 and SHA-384
+   hashes are produced by omitting some from the final concatenation.
+
+6.1.  SHA-224 and SHA-256 Initialization
+
+   For SHA-224, the initial hash value, H(0), consists of the following
+   32-bit words in hex:
+
+        H(0)0 = c1059ed8
+        H(0)1 = 367cd507
+        H(0)2 = 3070dd17
+        H(0)3 = f70e5939
+        H(0)4 = ffc00b31
+        H(0)5 = 68581511
+        H(0)6 = 64f98fa7
+        H(0)7 = befa4fa4
+
+   For SHA-256, the initial hash value, H(0), consists of the following
+   eight 32-bit words, in hex.  These words were obtained by taking the
+   first thirty-two bits of the fractional parts of the square roots of
+   the first eight prime numbers.
+
+        H(0)0 = 6a09e667
+        H(0)1 = bb67ae85
+        H(0)2 = 3c6ef372
+        H(0)3 = a54ff53a
+        H(0)4 = 510e527f
+        H(0)5 = 9b05688c
+        H(0)6 = 1f83d9ab
+        H(0)7 = 5be0cd19
+
+6.2.  SHA-224 and SHA-256 Processing
+
+   SHA-224 and SHA-256 perform identical processing on messages blocks
+   and differ only in how H(0) is initialized and how they produce their
+   final output.  They may be used to hash a message, M, having a length
+   of L bits, where 0 <= L < 2^64.  The algorithm uses (1) a message
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 11]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+   schedule of sixty-four 32-bit words, (2) eight working variables of
+   32 bits each, and (3) a hash value of eight 32-bit words.
+
+   The words of the message schedule are labeled W0, W1, ..., W63.  The
+   eight working variables are labeled a, b, c, d, e, f, g, and h.  The
+   words of the hash value are labeled H(i)0, H(i)1, ..., H(i)7, which
+   will hold the initial hash value, H(0), replaced by each successive
+   intermediate hash value (after each message block is processed),
+   H(i), and ending with the final hash value, H(N), after all N blocks
+   are processed.  They also use two temporary words, T1 and T2.
+
+   The input message is padded as described in Section 4.1 above then
+   parsed into 512-bit blocks, which are considered to be composed of 16
+   32-bit words M(i)0, M(i)1, ..., M(i)15.  The following computations
+   are then performed for each of the N message blocks.  All addition is
+   performed modulo 2^32.
+
+   For i = 1 to N
+
+      1. Prepare the message schedule W:
+         For t = 0 to 15
+            Wt = M(i)t
+         For t = 16 to 63
+            Wt = SSIG1(W(t-2)) + W(t-7) + SSIG0(t-15) + W(t-16)
+
+      2. Initialize the working variables:
+         a = H(i-1)0
+         b = H(i-1)1
+         c = H(i-1)2
+         d = H(i-1)3
+         e = H(i-1)4
+         f = H(i-1)5
+         g = H(i-1)6
+         h = H(i-1)7
+
+      3. Perform the main hash computation:
+         For t = 0 to 63
+            T1 = h + BSIG1(e) + CH(e,f,g) + Kt + Wt
+            T2 = BSIG0(a) + MAJ(a,b,c)
+            h = g
+            g = f
+            f = e
+            e = d + T1
+            d = c
+            c = b
+            b = a
+            a = T1 + T2
+
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 12]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+      4. Compute the intermediate hash value H(i):
+         H(i)0 = a + H(i-1)0
+         H(i)1 = b + H(i-1)1
+         H(i)2 = c + H(i-1)2
+         H(i)3 = d + H(i-1)3
+         H(i)4 = e + H(i-1)4
+         H(i)5 = f + H(i-1)5
+         H(i)6 = g + H(i-1)6
+         H(i)7 = h + H(i-1)7
+
+   After the above computations have been sequentially performed for all
+   of the blocks in the message, the final output is calculated.  For
+   SHA-256, this is the concatenation of all of H(N)0, H(N)1, through
+   H(N)7.  For SHA-224, this is the concatenation of H(N)0, H(N)1,
+   through H(N)6.
+
+6.3.  SHA-384 and SHA-512 Initialization
+
+   For SHA-384, the initial hash value, H(0), consists of the following
+   eight 64-bit words, in hex.  These words were obtained by taking the
+   first sixty-four bits of the fractional parts of the square roots of
+   the ninth through sixteenth prime numbers.
+
+        H(0)0 = cbbb9d5dc1059ed8
+        H(0)1 = 629a292a367cd507
+        H(0)2 = 9159015a3070dd17
+        H(0)3 = 152fecd8f70e5939
+        H(0)4 = 67332667ffc00b31
+        H(0)5 = 8eb44a8768581511
+        H(0)6 = db0c2e0d64f98fa7
+        H(0)7 = 47b5481dbefa4fa4
+
+   For SHA-512, the initial hash value, H(0), consists of the following
+   eight 64-bit words, in hex.  These words were obtained by taking the
+   first sixty-four bits of the fractional parts of the square roots of
+   the first eight prime numbers.
+
+        H(0)0 = 6a09e667f3bcc908
+        H(0)1 = bb67ae8584caa73b
+        H(0)2 = 3c6ef372fe94f82b
+        H(0)3 = a54ff53a5f1d36f1
+        H(0)4 = 510e527fade682d1
+        H(0)5 = 9b05688c2b3e6c1f
+        H(0)6 = 1f83d9abfb41bd6b
+        H(0)7 = 5be0cd19137e2179
+
+
+
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 13]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+6.4.  SHA-384 and SHA-512 Processing
+
+   SHA-384 and SHA-512 perform identical processing on message blocks
+   and differ only in how H(0) is initialized and how they produce their
+   final output.  They may be used to hash a message, M, having a length
+   of L bits, where 0 <= L < 2^128.  The algorithm uses (1) a message
+   schedule of eighty 64-bit words, (2) eight working variables of 64
+   bits each, and (3) a hash value of eight 64-bit words.
+
+   The words of the message schedule are labeled W0, W1, ..., W79.  The
+   eight working variables are labeled a, b, c, d, e, f, g, and h.  The
+   words of the hash value are labeled H(i)0, H(i)1, ..., H(i)7, which
+   will hold the initial hash value, H(0), replaced by each successive
+   intermediate hash value (after each message block is processed),
+   H(i), and ending with the final hash value, H(N) after all N blocks
+   are processed.
+
+   The input message is padded as described in Section 4.2 above, then
+   parsed into 1024-bit blocks, which are considered to be composed of
+   16 64-bit words M(i)0, M(i)1, ..., M(i)15.  The following
+   computations are then performed for each of the N message blocks.
+   All addition is performed modulo 2^64.
+
+   For i = 1 to N
+
+      1. Prepare the message schedule W:
+         For t = 0 to 15
+            Wt = M(i)t
+         For t = 16 to 79
+            Wt = SSIG1(W(t-2)) + W(t-7) + SSIG0(t-15) + W(t-16)
+
+      2. Initialize the working variables:
+         a = H(i-1)0
+         b = H(i-1)1
+         c = H(i-1)2
+         d = H(i-1)3
+         e = H(i-1)4
+         f = H(i-1)5
+         g = H(i-1)6
+         h = H(i-1)7
+
+      3. Perform the main hash computation:
+         For t = 0 to 79
+            T1 = h + BSIG1(e) + CH(e,f,g) + Kt + Wt
+            T2 = BSIG0(a) + MAJ(a,b,c)
+            h = g
+            g = f
+            f = e
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 14]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+            e = d + T1
+            d = c
+            c = b
+            b = a
+            a = T1 + T2
+
+      4. Compute the intermediate hash value H(i):
+         H(i)0 = a + H(i-1)0
+         H(i)1 = b + H(i-1)1
+         H(i)2 = c + H(i-1)2
+         H(i)3 = d + H(i-1)3
+         H(i)4 = e + H(i-1)4
+         H(i)5 = f + H(i-1)5
+         H(i)6 = g + H(i-1)6
+         H(i)7 = h + H(i-1)7
+
+   After the above computations have been sequentially performed for all
+   of the blocks in the message, the final output is calculated.  For
+   SHA-512, this is the concatenation of all of H(N)0, H(N)1, through
+   H(N)7.  For SHA-384, this is the concatenation of H(N)0, H(N)1,
+   through H(N)5.
+
+7.  SHA-Based HMACs
+
+   HMAC is a method for computing a keyed MAC (message authentication
+   code) using a hash function as described in [RFC2104].  It uses a key
+   to mix in with the input text to produce the final hash.
+
+   Sample code is also provided, in Section 8.3 below, to perform HMAC
+   based on any of the SHA algorithms described herein.  The sample code
+   found in [RFC2104] was written in terms of a specified text size.
+   Since SHA is defined in terms of an arbitrary number of bits, the
+   sample HMAC code has been written to allow the text input to HMAC to
+   have an arbitrary number of octets and bits.  A fixed-length
+   interface is also provided.
+
+8.  C Code for SHAs
+
+   Below is a demonstration implementation of these secure hash
+   functions in C.  Section 8.1 contains the header file sha.h, which
+   declares all constants, structures, and functions used by the sha and
+   hmac functions.  Section 8.2 contains the C code for sha1.c,
+   sha224-256.c, sha384-512.c, and usha.c along with sha-private.h,
+   which provides some declarations common to all the sha functions.
+   Section 8.3 contains the C code for the hmac functions.  Section 8.4
+   contains a test driver to exercise the code.
+
+
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 15]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+   For each of the digest length $$$, there is the following set of
+   constants, a structure, and functions:
+
+   Constants:
+      SHA$$$HashSize      number of octets in the hash
+      SHA$$$HashSizeBits  number of bits in the hash
+      SHA$$$_Message_Block_Size
+                          number of octets used in the intermediate
+                          message blocks
+      shaSuccess = 0      constant returned by each function on success
+      shaNull = 1         constant returned by each function when
+                          presented with a null pointer parameter
+      shaInputTooLong = 2  constant returned by each function when the
+                          input data is too long
+      shaStateError       constant returned by each function when
+                          SHA$$$Input is called after SHA$$$FinalBits or
+                          SHA$$$Result.
+
+   Structure:
+      typedef SHA$$$Context
+                          an opaque structure holding the complete state
+                          for producing the hash
+
+   Functions:
+                  int SHA$$$Reset(SHA$$$Context *);
+            Reset the hash context state
+      int SHA$$$Input(SHA$$$Context *, const uint8_t *octets,
+                  unsigned int bytecount);
+            Incorporate bytecount octets into the hash.
+      int SHA$$$FinalBits(SHA$$$Context *, const uint8_t octet,
+                  unsigned int bitcount);
+            Incorporate bitcount bits into the hash.  The bits are in
+            the upper portion of the octet.  SHA$$$Input() cannot be
+            called after this.
+      int SHA$$$Result(SHA$$$Context *,
+                  uint8_t Message_Digest[SHA$$$HashSize]);
+            Do the final calculations on the hash and copy the value
+            into Message_Digest.
+
+   In addition, functions with the prefix USHA are provided that take a
+   SHAversion value (SHA$$$) to select the SHA function suite.  They add
+   the following constants, structure, and functions:
+
+   Constants:
+      shaBadParam         constant returned by USHA functions when
+                          presented with a bad SHAversion (SHA$$$)
+                          parameter
+
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 16]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+      SHA$$$              SHAversion enumeration values, used by usha
+                          and hmac functions to select the SHA function
+                          suite
+
+   Structure:
+      typedef USHAContext
+                          an opaque structure holding the complete state
+                          for producing the hash
+
+   Functions:
+      int USHAReset(USHAContext *, SHAversion whichSha);
+            Reset the hash context state.
+      int USHAInput(USHAContext *,
+                  const uint8_t *bytes, unsigned int bytecount);
+            Incorporate bytecount octets into the hash.
+      int USHAFinalBits(USHAContext *,
+                  const uint8_t bits, unsigned int bitcount);
+                  Incorporate bitcount bits into the hash.
+      int USHAResult(USHAContext *,
+                  uint8_t Message_Digest[USHAMaxHashSize]);
+            Do the final calculations on the hash and copy the value
+            into Message_Digest.  Octets in Message_Digest beyond
+      USHAHashSize(whichSha) are left untouched.
+                  int USHAHashSize(enum SHAversion whichSha);
+            The number of octets in the given hash.
+      int USHAHashSizeBits(enum SHAversion whichSha);
+            The number of bits in the given hash.
+      int USHABlockSize(enum SHAversion whichSha);
+            The internal block size for the given hash.
+
+   The hmac functions follow the same pattern to allow any length of
+   text input to be used.
+
+   Structure:
+      typedef HMACContext an opaque structure holding the complete state
+                          for producing the hash
+
+   Functions:
+      int hmacReset(HMACContext *ctx, enum SHAversion whichSha,
+                  const unsigned char *key, int key_len);
+            Reset the hash context state.
+      int hmacInput(HMACContext *ctx, const unsigned char *text,
+                  int text_len);
+            Incorporate text_len octets into the hash.
+      int hmacFinalBits(HMACContext *ctx, const uint8_t bits,
+                  unsigned int bitcount);
+            Incorporate bitcount bits into the hash.
+
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 17]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+      int hmacResult(HMACContext *ctx,
+                  uint8_t Message_Digest[USHAMaxHashSize]);
+            Do the final calculations on the hash and copy the value
+            into Message_Digest.  Octets in Message_Digest beyond
+            USHAHashSize(whichSha) are left untouched.
+
+   In addition, a combined interface is provided, similar to that shown
+   in RFC 2104, that allows a fixed-length text input to be used.
+
+      int hmac(SHAversion whichSha,
+                  const unsigned char *text, int text_len,
+                  const unsigned char *key, int key_len,
+                  uint8_t Message_Digest[USHAMaxHashSize]);
+            Calculate the given digest for the given text and key, and
+            return the resulting hash.  Octets in Message_Digest beyond
+            USHAHashSize(whichSha) are left untouched.
+
+8.1.  The .h File
+
+/**************************** sha.h ****************************/
+/******************* See RFC 4634 for details ******************/
+#ifndef _SHA_H_
+#define _SHA_H_
+
+/*
+ *  Description:
+ *      This file implements the Secure Hash Signature Standard
+ *      algorithms as defined in the National Institute of Standards
+ *      and Technology Federal Information Processing Standards
+ *      Publication (FIPS PUB) 180-1 published on April 17, 1995, 180-2
+ *      published on August 1, 2002, and the FIPS PUB 180-2 Change
+ *      Notice published on February 28, 2004.
+ *
+ *      A combined document showing all algorithms is available at
+ *              http://csrc.nist.gov/publications/fips/
+ *              fips180-2/fips180-2withchangenotice.pdf
+ *
+ *      The five hashes are defined in these sizes:
+ *              SHA-1           20 byte / 160 bit
+ *              SHA-224         28 byte / 224 bit
+ *              SHA-256         32 byte / 256 bit
+ *              SHA-384         48 byte / 384 bit
+ *              SHA-512         64 byte / 512 bit
+ */
+
+#include <stdint.h>
+/*
+ * If you do not have the ISO standard stdint.h header file, then you
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 18]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+ * must typedef the following:
+ *    name              meaning
+ *  uint64_t         unsigned 64 bit integer
+ *  uint32_t         unsigned 32 bit integer
+ *  uint8_t          unsigned 8 bit integer (i.e., unsigned char)
+ *  int_least16_t    integer of >= 16 bits
+ *
+ */
+
+#ifndef _SHA_enum_
+#define _SHA_enum_
+/*
+ *  All SHA functions return one of these values.
+ */
+enum {
+    shaSuccess = 0,
+    shaNull,            /* Null pointer parameter */
+    shaInputTooLong,    /* input data too long */
+    shaStateError,      /* called Input after FinalBits or Result */
+    shaBadParam         /* passed a bad parameter */
+};
+#endif /* _SHA_enum_ */
+
+/*
+ *  These constants hold size information for each of the SHA
+ *  hashing operations
+ */
+enum {
+    SHA1_Message_Block_Size = 64, SHA224_Message_Block_Size = 64,
+    SHA256_Message_Block_Size = 64, SHA384_Message_Block_Size = 128,
+    SHA512_Message_Block_Size = 128,
+    USHA_Max_Message_Block_Size = SHA512_Message_Block_Size,
+
+    SHA1HashSize = 20, SHA224HashSize = 28, SHA256HashSize = 32,
+    SHA384HashSize = 48, SHA512HashSize = 64,
+    USHAMaxHashSize = SHA512HashSize,
+
+    SHA1HashSizeBits = 160, SHA224HashSizeBits = 224,
+    SHA256HashSizeBits = 256, SHA384HashSizeBits = 384,
+    SHA512HashSizeBits = 512, USHAMaxHashSizeBits = SHA512HashSizeBits
+};
+
+/*
+ *  These constants are used in the USHA (unified sha) functions.
+ */
+typedef enum SHAversion {
+    SHA1, SHA224, SHA256, SHA384, SHA512
+} SHAversion;
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 19]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+/*
+ *  This structure will hold context information for the SHA-1
+ *  hashing operation.
+ */
+typedef struct SHA1Context {
+    uint32_t Intermediate_Hash[SHA1HashSize/4]; /* Message Digest */
+
+    uint32_t Length_Low;                /* Message length in bits */
+    uint32_t Length_High;               /* Message length in bits */
+
+    int_least16_t Message_Block_Index;  /* Message_Block array index */
+                                        /* 512-bit message blocks */
+    uint8_t Message_Block[SHA1_Message_Block_Size];
+
+    int Computed;                       /* Is the digest computed? */
+    int Corrupted;                      /* Is the digest corrupted? */
+} SHA1Context;
+
+/*
+ *  This structure will hold context information for the SHA-256
+ *  hashing operation.
+ */
+typedef struct SHA256Context {
+    uint32_t Intermediate_Hash[SHA256HashSize/4]; /* Message Digest */
+
+    uint32_t Length_Low;                /* Message length in bits */
+    uint32_t Length_High;               /* Message length in bits */
+
+    int_least16_t Message_Block_Index;  /* Message_Block array index */
+                                        /* 512-bit message blocks */
+    uint8_t Message_Block[SHA256_Message_Block_Size];
+
+    int Computed;                       /* Is the digest computed? */
+    int Corrupted;                      /* Is the digest corrupted? */
+} SHA256Context;
+
+/*
+ *  This structure will hold context information for the SHA-512
+ *  hashing operation.
+ */
+typedef struct SHA512Context {
+#ifdef USE_32BIT_ONLY
+    uint32_t Intermediate_Hash[SHA512HashSize/4]; /* Message Digest  */
+    uint32_t Length[4];                 /* Message length in bits */
+#else /* !USE_32BIT_ONLY */
+    uint64_t Intermediate_Hash[SHA512HashSize/8]; /* Message Digest */
+    uint64_t Length_Low, Length_High;   /* Message length in bits */
+#endif /* USE_32BIT_ONLY */
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 20]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+    int_least16_t Message_Block_Index;  /* Message_Block array index */
+                                        /* 1024-bit message blocks */
+    uint8_t Message_Block[SHA512_Message_Block_Size];
+
+    int Computed;                       /* Is the digest computed?*/
+    int Corrupted;                      /* Is the digest corrupted? */
+} SHA512Context;
+
+/*
+ *  This structure will hold context information for the SHA-224
+ *  hashing operation. It uses the SHA-256 structure for computation.
+ */
+typedef struct SHA256Context SHA224Context;
+
+/*
+ *  This structure will hold context information for the SHA-384
+ *  hashing operation. It uses the SHA-512 structure for computation.
+ */
+typedef struct SHA512Context SHA384Context;
+
+/*
+ *  This structure holds context information for all SHA
+ *  hashing operations.
+ */
+typedef struct USHAContext {
+    int whichSha;               /* which SHA is being used */
+    union {
+      SHA1Context sha1Context;
+      SHA224Context sha224Context; SHA256Context sha256Context;
+      SHA384Context sha384Context; SHA512Context sha512Context;
+    } ctx;
+} USHAContext;
+
+/*
+ *  This structure will hold context information for the HMAC
+ *  keyed hashing operation.
+ */
+typedef struct HMACContext {
+    int whichSha;               /* which SHA is being used */
+    int hashSize;               /* hash size of SHA being used */
+    int blockSize;              /* block size of SHA being used */
+    USHAContext shaContext;     /* SHA context */
+    unsigned char k_opad[USHA_Max_Message_Block_Size];
+                        /* outer padding - key XORd with opad */
+} HMACContext;
+
+
+
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 21]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+/*
+ *  Function Prototypes
+ */
+
+/* SHA-1 */
+extern int SHA1Reset(SHA1Context *);
+extern int SHA1Input(SHA1Context *, const uint8_t *bytes,
+                     unsigned int bytecount);
+extern int SHA1FinalBits(SHA1Context *, const uint8_t bits,
+                         unsigned int bitcount);
+extern int SHA1Result(SHA1Context *,
+                      uint8_t Message_Digest[SHA1HashSize]);
+
+/* SHA-224 */
+extern int SHA224Reset(SHA224Context *);
+extern int SHA224Input(SHA224Context *, const uint8_t *bytes,
+                       unsigned int bytecount);
+extern int SHA224FinalBits(SHA224Context *, const uint8_t bits,
+                           unsigned int bitcount);
+extern int SHA224Result(SHA224Context *,
+                        uint8_t Message_Digest[SHA224HashSize]);
+
+/* SHA-256 */
+extern int SHA256Reset(SHA256Context *);
+extern int SHA256Input(SHA256Context *, const uint8_t *bytes,
+                       unsigned int bytecount);
+extern int SHA256FinalBits(SHA256Context *, const uint8_t bits,
+                           unsigned int bitcount);
+extern int SHA256Result(SHA256Context *,
+                        uint8_t Message_Digest[SHA256HashSize]);
+
+/* SHA-384 */
+extern int SHA384Reset(SHA384Context *);
+extern int SHA384Input(SHA384Context *, const uint8_t *bytes,
+                       unsigned int bytecount);
+extern int SHA384FinalBits(SHA384Context *, const uint8_t bits,
+                           unsigned int bitcount);
+extern int SHA384Result(SHA384Context *,
+                        uint8_t Message_Digest[SHA384HashSize]);
+
+/* SHA-512 */
+extern int SHA512Reset(SHA512Context *);
+extern int SHA512Input(SHA512Context *, const uint8_t *bytes,
+                       unsigned int bytecount);
+extern int SHA512FinalBits(SHA512Context *, const uint8_t bits,
+                           unsigned int bitcount);
+extern int SHA512Result(SHA512Context *,
+                        uint8_t Message_Digest[SHA512HashSize]);
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 22]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+/* Unified SHA functions, chosen by whichSha */
+extern int USHAReset(USHAContext *, SHAversion whichSha);
+extern int USHAInput(USHAContext *,
+                     const uint8_t *bytes, unsigned int bytecount);
+extern int USHAFinalBits(USHAContext *,
+                         const uint8_t bits, unsigned int bitcount);
+extern int USHAResult(USHAContext *,
+                      uint8_t Message_Digest[USHAMaxHashSize]);
+extern int USHABlockSize(enum SHAversion whichSha);
+extern int USHAHashSize(enum SHAversion whichSha);
+extern int USHAHashSizeBits(enum SHAversion whichSha);
+
+/*
+ * HMAC Keyed-Hashing for Message Authentication, RFC2104,
+ * for all SHAs.
+ * This interface allows a fixed-length text input to be used.
+ */
+extern int hmac(SHAversion whichSha, /* which SHA algorithm to use */
+    const unsigned char *text,     /* pointer to data stream */
+    int text_len,                  /* length of data stream */
+    const unsigned char *key,      /* pointer to authentication key */
+    int key_len,                   /* length of authentication key */
+    uint8_t digest[USHAMaxHashSize]); /* caller digest to fill in */
+
+/*
+ * HMAC Keyed-Hashing for Message Authentication, RFC2104,
+ * for all SHAs.
+ * This interface allows any length of text input to be used.
+ */
+extern int hmacReset(HMACContext *ctx, enum SHAversion whichSha,
+                     const unsigned char *key, int key_len);
+extern int hmacInput(HMACContext *ctx, const unsigned char *text,
+                     int text_len);
+
+extern int hmacFinalBits(HMACContext *ctx, const uint8_t bits,
+                         unsigned int bitcount);
+extern int hmacResult(HMACContext *ctx,
+                      uint8_t digest[USHAMaxHashSize]);
+
+#endif /* _SHA_H_ */
+
+
+
+
+
+
+
+
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 23]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+8.2.  The SHA Code
+
+   This code is primarily intended as expository and could be optimized
+   further.  For example, the assignment rotations through the variables
+   a, b, ..., h could be treated as a cycle and the loop unrolled,
+   rather than doing the explicit copying.
+
+   Note that there are alternative representations of the Ch() and Maj()
+   functions controlled by an ifdef.
+
+8.2.1.  sha1.c
+
+/**************************** sha1.c ****************************/
+/******************** See RFC 4634 for details ******************/
+/*
+ *  Description:
+ *      This file implements the Secure Hash Signature Standard
+ *      algorithms as defined in the National Institute of Standards
+ *      and Technology Federal Information Processing Standards
+ *      Publication (FIPS PUB) 180-1 published on April 17, 1995, 180-2
+ *      published on August 1, 2002, and the FIPS PUB 180-2 Change
+ *      Notice published on February 28, 2004.
+ *
+ *      A combined document showing all algorithms is available at
+ *              http://csrc.nist.gov/publications/fips/
+ *              fips180-2/fips180-2withchangenotice.pdf
+ *
+ *      The SHA-1 algorithm produces a 160-bit message digest for a
+ *      given data stream.  It should take about 2**n steps to find a
+ *      message with the same digest as a given message and
+ *      2**(n/2) to find any two messages with the same digest,
+ *      when n is the digest size in bits.  Therefore, this
+ *      algorithm can serve as a means of providing a
+ *      "fingerprint" for a message.
+ *
+ *  Portability Issues:
+ *      SHA-1 is defined in terms of 32-bit "words".  This code
+ *      uses <stdint.h> (included via "sha.h") to define 32 and 8
+ *      bit unsigned integer types.  If your C compiler does not
+ *      support 32 bit unsigned integers, this code is not
+ *      appropriate.
+ *
+ *  Caveats:
+ *      SHA-1 is designed to work with messages less than 2^64 bits
+ *      long. This implementation uses SHA1Input() to hash the bits
+ *      that are a multiple of the size of an 8-bit character, and then
+ *      uses SHA1FinalBits() to hash the final few bits of the input.
+ */
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 24]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+#include "sha.h"
+#include "sha-private.h"
+
+/*
+ *  Define the SHA1 circular left shift macro
+ */
+#define SHA1_ROTL(bits,word) \
+                (((word) << (bits)) | ((word) >> (32-(bits))))
+
+/*
+ * add "length" to the length
+ */
+static uint32_t addTemp;
+#define SHA1AddLength(context, length)                     \
+    (addTemp = (context)->Length_Low,                      \
+     (context)->Corrupted =                                \
+        (((context)->Length_Low += (length)) < addTemp) && \
+        (++(context)->Length_High == 0) ? 1 : 0)
+
+/* Local Function Prototypes */
+static void SHA1Finalize(SHA1Context *context, uint8_t Pad_Byte);
+static void SHA1PadMessage(SHA1Context *, uint8_t Pad_Byte);
+static void SHA1ProcessMessageBlock(SHA1Context *);
+
+/*
+ *  SHA1Reset
+ *
+ *  Description:
+ *      This function will initialize the SHA1Context in preparation
+ *      for computing a new SHA1 message digest.
+ *
+ *  Parameters:
+ *      context: [in/out]
+ *          The context to reset.
+ *
+ *  Returns:
+ *      sha Error Code.
+ *
+ */
+int SHA1Reset(SHA1Context *context)
+{
+    if (!context)
+        return shaNull;
+
+    context->Length_Low             = 0;
+    context->Length_High            = 0;
+    context->Message_Block_Index    = 0;
+
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 25]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+    /* Initial Hash Values: FIPS-180-2 section 5.3.1 */
+    context->Intermediate_Hash[0]   = 0x67452301;
+    context->Intermediate_Hash[1]   = 0xEFCDAB89;
+    context->Intermediate_Hash[2]   = 0x98BADCFE;
+    context->Intermediate_Hash[3]   = 0x10325476;
+    context->Intermediate_Hash[4]   = 0xC3D2E1F0;
+
+    context->Computed   = 0;
+    context->Corrupted  = 0;
+
+    return shaSuccess;
+}
+
+/*
+ *  SHA1Input
+ *
+ *  Description:
+ *      This function accepts an array of octets as the next portion
+ *      of the message.
+ *
+ *  Parameters:
+ *      context: [in/out]
+ *          The SHA context to update
+ *      message_array: [in]
+ *          An array of characters representing the next portion of
+ *          the message.
+ *      length: [in]
+ *          The length of the message in message_array
+ *
+ *  Returns:
+ *      sha Error Code.
+ *
+ */
+int SHA1Input(SHA1Context *context,
+    const uint8_t *message_array, unsigned length)
+{
+  if (!length)
+    return shaSuccess;
+
+  if (!context || !message_array)
+    return shaNull;
+
+  if (context->Computed) {
+    context->Corrupted = shaStateError;
+    return shaStateError;
+  }
+
+  if (context->Corrupted)
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 26]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+     return context->Corrupted;
+
+  while (length-- && !context->Corrupted) {
+    context->Message_Block[context->Message_Block_Index++] =
+      (*message_array & 0xFF);
+
+    if (!SHA1AddLength(context, 8) &&
+      (context->Message_Block_Index == SHA1_Message_Block_Size))
+      SHA1ProcessMessageBlock(context);
+
+    message_array++;
+  }
+
+  return shaSuccess;
+}
+
+/*
+ * SHA1FinalBits
+ *
+ * Description:
+ *   This function will add in any final bits of the message.
+ *
+ * Parameters:
+ *   context: [in/out]
+ *     The SHA context to update
+ *   message_bits: [in]
+ *     The final bits of the message, in the upper portion of the
+ *     byte. (Use 0b###00000 instead of 0b00000### to input the
+ *     three bits ###.)
+ *   length: [in]
+ *     The number of bits in message_bits, between 1 and 7.
+ *
+ * Returns:
+ *   sha Error Code.
+ */
+int SHA1FinalBits(SHA1Context *context, const uint8_t message_bits,
+    unsigned int length)
+{
+  uint8_t masks[8] = {
+      /* 0 0b00000000 */ 0x00, /* 1 0b10000000 */ 0x80,
+      /* 2 0b11000000 */ 0xC0, /* 3 0b11100000 */ 0xE0,
+      /* 4 0b11110000 */ 0xF0, /* 5 0b11111000 */ 0xF8,
+      /* 6 0b11111100 */ 0xFC, /* 7 0b11111110 */ 0xFE
+  };
+  uint8_t markbit[8] = {
+      /* 0 0b10000000 */ 0x80, /* 1 0b01000000 */ 0x40,
+      /* 2 0b00100000 */ 0x20, /* 3 0b00010000 */ 0x10,
+      /* 4 0b00001000 */ 0x08, /* 5 0b00000100 */ 0x04,
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 27]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+      /* 6 0b00000010 */ 0x02, /* 7 0b00000001 */ 0x01
+  };
+
+  if (!length)
+    return shaSuccess;
+
+  if (!context)
+    return shaNull;
+
+  if (context->Computed || (length >= 8) || (length == 0)) {
+    context->Corrupted = shaStateError;
+    return shaStateError;
+  }
+
+  if (context->Corrupted)
+     return context->Corrupted;
+
+  SHA1AddLength(context, length);
+  SHA1Finalize(context,
+    (uint8_t) ((message_bits & masks[length]) | markbit[length]));
+
+  return shaSuccess;
+}
+
+/*
+ * SHA1Result
+ *
+ * Description:
+ *   This function will return the 160-bit message digest into the
+ *   Message_Digest array provided by the caller.
+ *   NOTE: The first octet of hash is stored in the 0th element,
+ *      the last octet of hash in the 19th element.
+ *
+ * Parameters:
+ *   context: [in/out]
+ *     The context to use to calculate the SHA-1 hash.
+ *   Message_Digest: [out]
+ *     Where the digest is returned.
+ *
+ * Returns:
+ *   sha Error Code.
+ *
+ */
+int SHA1Result(SHA1Context *context,
+    uint8_t Message_Digest[SHA1HashSize])
+{
+  int i;
+
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 28]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+  if (!context || !Message_Digest)
+    return shaNull;
+
+  if (context->Corrupted)
+    return context->Corrupted;
+
+  if (!context->Computed)
+    SHA1Finalize(context, 0x80);
+
+  for (i = 0; i < SHA1HashSize; ++i)
+    Message_Digest[i] = (uint8_t) (context->Intermediate_Hash[i>>2]
+              >> 8 * ( 3 - ( i & 0x03 ) ));
+
+  return shaSuccess;
+}
+
+/*
+ * SHA1Finalize
+ *
+ * Description:
+ *   This helper function finishes off the digest calculations.
+ *
+ * Parameters:
+ *   context: [in/out]
+ *     The SHA context to update
+ *   Pad_Byte: [in]
+ *     The last byte to add to the digest before the 0-padding
+ *     and length. This will contain the last bits of the message
+ *     followed by another single bit. If the message was an
+ *     exact multiple of 8-bits long, Pad_Byte will be 0x80.
+ *
+ * Returns:
+ *   sha Error Code.
+ *
+ */
+static void SHA1Finalize(SHA1Context *context, uint8_t Pad_Byte)
+{
+  int i;
+  SHA1PadMessage(context, Pad_Byte);
+  /* message may be sensitive, clear it out */
+  for (i = 0; i < SHA1_Message_Block_Size; ++i)
+    context->Message_Block[i] = 0;
+  context->Length_Low = 0;  /* and clear length */
+  context->Length_High = 0;
+  context->Computed = 1;
+}
+
+/*
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 29]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+ * SHA1PadMessage
+ *
+ * Description:
+ *   According to the standard, the message must be padded to an
+ *   even 512 bits. The first padding bit must be a '1'. The last
+ *   64 bits represent the length of the original message. All bits
+ *   in between should be 0. This helper function will pad the
+ *   message according to those rules by filling the Message_Block
+ *   array accordingly. When it returns, it can be assumed that the
+ *   message digest has been computed.
+ *
+ * Parameters:
+ *   context: [in/out]
+ *     The context to pad
+ *   Pad_Byte: [in]
+ *     The last byte to add to the digest before the 0-padding
+ *     and length. This will contain the last bits of the message
+ *     followed by another single bit. If the message was an
+ *     exact multiple of 8-bits long, Pad_Byte will be 0x80.
+ *
+ * Returns:
+ *   Nothing.
+ */
+static void SHA1PadMessage(SHA1Context *context, uint8_t Pad_Byte)
+{
+  /*
+   * Check to see if the current message block is too small to hold
+   * the initial padding bits and length. If so, we will pad the
+   * block, process it, and then continue padding into a second
+   * block.
+   */
+  if (context->Message_Block_Index >= (SHA1_Message_Block_Size - 8)) {
+    context->Message_Block[context->Message_Block_Index++] = Pad_Byte;
+    while (context->Message_Block_Index < SHA1_Message_Block_Size)
+      context->Message_Block[context->Message_Block_Index++] = 0;
+
+    SHA1ProcessMessageBlock(context);
+  } else
+    context->Message_Block[context->Message_Block_Index++] = Pad_Byte;
+
+  while (context->Message_Block_Index < (SHA1_Message_Block_Size - 8))
+    context->Message_Block[context->Message_Block_Index++] = 0;
+
+  /*
+   * Store the message length as the last 8 octets
+   */
+  context->Message_Block[56] = (uint8_t) (context->Length_High >> 24);
+  context->Message_Block[57] = (uint8_t) (context->Length_High >> 16);
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 30]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+  context->Message_Block[58] = (uint8_t) (context->Length_High >> 8);
+  context->Message_Block[59] = (uint8_t) (context->Length_High);
+  context->Message_Block[60] = (uint8_t) (context->Length_Low >> 24);
+  context->Message_Block[61] = (uint8_t) (context->Length_Low >> 16);
+  context->Message_Block[62] = (uint8_t) (context->Length_Low >> 8);
+  context->Message_Block[63] = (uint8_t) (context->Length_Low);
+
+  SHA1ProcessMessageBlock(context);
+}
+
+/*
+ * SHA1ProcessMessageBlock
+ *
+ * Description:
+ *   This helper function will process the next 512 bits of the
+ *   message stored in the Message_Block array.
+ *
+ * Parameters:
+ *   None.
+ *
+ * Returns:
+ *   Nothing.
+ *
+ * Comments:
+ *   Many of the variable names in this code, especially the
+ *   single character names, were used because those were the
+ *   names used in the publication.
+ */
+static void SHA1ProcessMessageBlock(SHA1Context *context)
+{
+  /* Constants defined in FIPS-180-2, section 4.2.1 */
+  const uint32_t K[4] = {
+      0x5A827999, 0x6ED9EBA1, 0x8F1BBCDC, 0xCA62C1D6
+  };
+  int        t;               /* Loop counter */
+  uint32_t   temp;            /* Temporary word value */
+  uint32_t   W[80];           /* Word sequence */
+  uint32_t   A, B, C, D, E;   /* Word buffers */
+
+  /*
+   * Initialize the first 16 words in the array W
+   */
+  for (t = 0; t < 16; t++) {
+    W[t]  = ((uint32_t)context->Message_Block[t * 4]) << 24;
+    W[t] |= ((uint32_t)context->Message_Block[t * 4 + 1]) << 16;
+    W[t] |= ((uint32_t)context->Message_Block[t * 4 + 2]) << 8;
+    W[t] |= ((uint32_t)context->Message_Block[t * 4 + 3]);
+  }
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 31]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+  for (t = 16; t < 80; t++)
+    W[t] = SHA1_ROTL(1, W[t-3] ^ W[t-8] ^ W[t-14] ^ W[t-16]);
+
+  A = context->Intermediate_Hash[0];
+  B = context->Intermediate_Hash[1];
+  C = context->Intermediate_Hash[2];
+  D = context->Intermediate_Hash[3];
+  E = context->Intermediate_Hash[4];
+
+  for (t = 0; t < 20; t++) {
+    temp = SHA1_ROTL(5,A) + SHA_Ch(B, C, D) + E + W[t] + K[0];
+    E = D;
+    D = C;
+    C = SHA1_ROTL(30,B);
+    B = A;
+    A = temp;
+  }
+
+  for (t = 20; t < 40; t++) {
+    temp = SHA1_ROTL(5,A) + SHA_Parity(B, C, D) + E + W[t] + K[1];
+    E = D;
+    D = C;
+    C = SHA1_ROTL(30,B);
+    B = A;
+    A = temp;
+  }
+
+  for (t = 40; t < 60; t++) {
+    temp = SHA1_ROTL(5,A) + SHA_Maj(B, C, D) + E + W[t] + K[2];
+    E = D;
+    D = C;
+    C = SHA1_ROTL(30,B);
+    B = A;
+    A = temp;
+  }
+
+  for (t = 60; t < 80; t++) {
+    temp = SHA1_ROTL(5,A) + SHA_Parity(B, C, D) + E + W[t] + K[3];
+    E = D;
+    D = C;
+    C = SHA1_ROTL(30,B);
+    B = A;
+    A = temp;
+  }
+
+  context->Intermediate_Hash[0] += A;
+  context->Intermediate_Hash[1] += B;
+  context->Intermediate_Hash[2] += C;
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 32]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+  context->Intermediate_Hash[3] += D;
+  context->Intermediate_Hash[4] += E;
+
+  context->Message_Block_Index = 0;
+}
+
+8.2.2.  sha224-256.c
+
+/*************************** sha224-256.c ***************************/
+/********************* See RFC 4634 for details *********************/
+/*
+ * Description:
+ *   This file implements the Secure Hash Signature Standard
+ *   algorithms as defined in the National Institute of Standards
+ *   and Technology Federal Information Processing Standards
+ *   Publication (FIPS PUB) 180-1 published on April 17, 1995, 180-2
+ *   published on August 1, 2002, and the FIPS PUB 180-2 Change
+ *   Notice published on February 28, 2004.
+ *
+ *   A combined document showing all algorithms is available at
+ *       http://csrc.nist.gov/publications/fips/
+ *       fips180-2/fips180-2withchangenotice.pdf
+ *
+ *   The SHA-224 and SHA-256 algorithms produce 224-bit and 256-bit
+ *   message digests for a given data stream. It should take about
+ *   2**n steps to find a message with the same digest as a given
+ *   message and 2**(n/2) to find any two messages with the same
+ *   digest, when n is the digest size in bits. Therefore, this
+ *   algorithm can serve as a means of providing a
+ *   "fingerprint" for a message.
+ *
+ * Portability Issues:
+ *   SHA-224 and SHA-256 are defined in terms of 32-bit "words".
+ *   This code uses <stdint.h> (included via "sha.h") to define 32
+ *   and 8 bit unsigned integer types. If your C compiler does not
+ *   support 32 bit unsigned integers, this code is not
+ *   appropriate.
+ *
+ * Caveats:
+ *   SHA-224 and SHA-256 are designed to work with messages less
+ *   than 2^64 bits long. This implementation uses SHA224/256Input()
+ *   to hash the bits that are a multiple of the size of an 8-bit
+ *   character, and then uses SHA224/256FinalBits() to hash the
+ *   final few bits of the input.
+ */
+
+#include "sha.h"
+#include "sha-private.h"
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 33]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+/* Define the SHA shift, rotate left and rotate right macro */
+#define SHA256_SHR(bits,word)      ((word) >> (bits))
+#define SHA256_ROTL(bits,word)                         \
+  (((word) << (bits)) | ((word) >> (32-(bits))))
+#define SHA256_ROTR(bits,word)                         \
+  (((word) >> (bits)) | ((word) << (32-(bits))))
+
+/* Define the SHA SIGMA and sigma macros */
+#define SHA256_SIGMA0(word)   \
+  (SHA256_ROTR( 2,word) ^ SHA256_ROTR(13,word) ^ SHA256_ROTR(22,word))
+#define SHA256_SIGMA1(word)   \
+  (SHA256_ROTR( 6,word) ^ SHA256_ROTR(11,word) ^ SHA256_ROTR(25,word))
+#define SHA256_sigma0(word)   \
+  (SHA256_ROTR( 7,word) ^ SHA256_ROTR(18,word) ^ SHA256_SHR( 3,word))
+#define SHA256_sigma1(word)   \
+  (SHA256_ROTR(17,word) ^ SHA256_ROTR(19,word) ^ SHA256_SHR(10,word))
+
+/*
+ * add "length" to the length
+ */
+static uint32_t addTemp;
+#define SHA224_256AddLength(context, length)               \
+  (addTemp = (context)->Length_Low, (context)->Corrupted = \
+    (((context)->Length_Low += (length)) < addTemp) &&     \
+    (++(context)->Length_High == 0) ? 1 : 0)
+
+/* Local Function Prototypes */
+static void SHA224_256Finalize(SHA256Context *context,
+  uint8_t Pad_Byte);
+static void SHA224_256PadMessage(SHA256Context *context,
+  uint8_t Pad_Byte);
+static void SHA224_256ProcessMessageBlock(SHA256Context *context);
+static int SHA224_256Reset(SHA256Context *context, uint32_t *H0);
+static int SHA224_256ResultN(SHA256Context *context,
+  uint8_t Message_Digest[], int HashSize);
+
+/* Initial Hash Values: FIPS-180-2 Change Notice 1 */
+static uint32_t SHA224_H0[SHA256HashSize/4] = {
+    0xC1059ED8, 0x367CD507, 0x3070DD17, 0xF70E5939,
+    0xFFC00B31, 0x68581511, 0x64F98FA7, 0xBEFA4FA4
+};
+
+/* Initial Hash Values: FIPS-180-2 section 5.3.2 */
+static uint32_t SHA256_H0[SHA256HashSize/4] = {
+  0x6A09E667, 0xBB67AE85, 0x3C6EF372, 0xA54FF53A,
+  0x510E527F, 0x9B05688C, 0x1F83D9AB, 0x5BE0CD19
+};
+
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 34]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+/*
+ * SHA224Reset
+ *
+ * Description:
+ *   This function will initialize the SHA384Context in preparation
+ *   for computing a new SHA224 message digest.
+ *
+ * Parameters:
+ *   context: [in/out]
+ *     The context to reset.
+ *
+ * Returns:
+ *   sha Error Code.
+ */
+int SHA224Reset(SHA224Context *context)
+{
+  return SHA224_256Reset(context, SHA224_H0);
+}
+
+/*
+ * SHA224Input
+ *
+ * Description:
+ *   This function accepts an array of octets as the next portion
+ *   of the message.
+ *
+ * Parameters:
+ *   context: [in/out]
+ *     The SHA context to update
+ *   message_array: [in]
+ *     An array of characters representing the next portion of
+ *     the message.
+ *   length: [in]
+ *     The length of the message in message_array
+ *
+ * Returns:
+ *   sha Error Code.
+ *
+ */
+int SHA224Input(SHA224Context *context, const uint8_t *message_array,
+    unsigned int length)
+{
+  return SHA256Input(context, message_array, length);
+}
+
+/*
+ * SHA224FinalBits
+ *
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 35]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+ * Description:
+ *   This function will add in any final bits of the message.
+ *
+ * Parameters:
+ *   context: [in/out]
+ *     The SHA context to update
+ *   message_bits: [in]
+ *     The final bits of the message, in the upper portion of the
+ *     byte. (Use 0b###00000 instead of 0b00000### to input the
+ *     three bits ###.)
+ *   length: [in]
+ *     The number of bits in message_bits, between 1 and 7.
+ *
+ * Returns:
+ *   sha Error Code.
+ */
+int SHA224FinalBits( SHA224Context *context,
+    const uint8_t message_bits, unsigned int length)
+{
+  return SHA256FinalBits(context, message_bits, length);
+}
+
+/*
+ * SHA224Result
+ *
+ * Description:
+ *   This function will return the 224-bit message
+ *   digest into the Message_Digest array provided by the caller.
+ *   NOTE: The first octet of hash is stored in the 0th element,
+ *      the last octet of hash in the 28th element.
+ *
+ * Parameters:
+ *   context: [in/out]
+ *     The context to use to calculate the SHA hash.
+ *   Message_Digest: [out]
+ *     Where the digest is returned.
+ *
+ * Returns:
+ *   sha Error Code.
+ */
+int SHA224Result(SHA224Context *context,
+    uint8_t Message_Digest[SHA224HashSize])
+{
+  return SHA224_256ResultN(context, Message_Digest, SHA224HashSize);
+}
+
+/*
+ * SHA256Reset
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 36]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+ *
+ * Description:
+ *   This function will initialize the SHA256Context in preparation
+ *   for computing a new SHA256 message digest.
+ *
+ * Parameters:
+ *   context: [in/out]
+ *     The context to reset.
+ *
+ * Returns:
+ *   sha Error Code.
+ */
+int SHA256Reset(SHA256Context *context)
+{
+  return SHA224_256Reset(context, SHA256_H0);
+}
+
+/*
+ * SHA256Input
+ *
+ * Description:
+ *   This function accepts an array of octets as the next portion
+ *   of the message.
+ *
+ * Parameters:
+ *   context: [in/out]
+ *     The SHA context to update
+ *   message_array: [in]
+ *     An array of characters representing the next portion of
+ *     the message.
+ *   length: [in]
+ *     The length of the message in message_array
+ *
+ * Returns:
+ *   sha Error Code.
+ */
+int SHA256Input(SHA256Context *context, const uint8_t *message_array,
+    unsigned int length)
+{
+  if (!length)
+    return shaSuccess;
+
+  if (!context || !message_array)
+    return shaNull;
+
+  if (context->Computed) {
+    context->Corrupted = shaStateError;
+    return shaStateError;
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 37]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+  }
+
+  if (context->Corrupted)
+     return context->Corrupted;
+
+  while (length-- && !context->Corrupted) {
+    context->Message_Block[context->Message_Block_Index++] =
+            (*message_array & 0xFF);
+
+    if (!SHA224_256AddLength(context, 8) &&
+      (context->Message_Block_Index == SHA256_Message_Block_Size))
+      SHA224_256ProcessMessageBlock(context);
+
+    message_array++;
+  }
+
+  return shaSuccess;
+
+}
+
+/*
+ * SHA256FinalBits
+ *
+ * Description:
+ *   This function will add in any final bits of the message.
+ *
+ * Parameters:
+ *   context: [in/out]
+ *     The SHA context to update
+ *   message_bits: [in]
+ *     The final bits of the message, in the upper portion of the
+ *     byte. (Use 0b###00000 instead of 0b00000### to input the
+ *     three bits ###.)
+ *   length: [in]
+ *     The number of bits in message_bits, between 1 and 7.
+ *
+ * Returns:
+ *   sha Error Code.
+ */
+int SHA256FinalBits(SHA256Context *context,
+    const uint8_t message_bits, unsigned int length)
+{
+  uint8_t masks[8] = {
+      /* 0 0b00000000 */ 0x00, /* 1 0b10000000 */ 0x80,
+      /* 2 0b11000000 */ 0xC0, /* 3 0b11100000 */ 0xE0,
+      /* 4 0b11110000 */ 0xF0, /* 5 0b11111000 */ 0xF8,
+      /* 6 0b11111100 */ 0xFC, /* 7 0b11111110 */ 0xFE
+  };
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 38]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+  uint8_t markbit[8] = {
+      /* 0 0b10000000 */ 0x80, /* 1 0b01000000 */ 0x40,
+      /* 2 0b00100000 */ 0x20, /* 3 0b00010000 */ 0x10,
+      /* 4 0b00001000 */ 0x08, /* 5 0b00000100 */ 0x04,
+      /* 6 0b00000010 */ 0x02, /* 7 0b00000001 */ 0x01
+  };
+
+  if (!length)
+    return shaSuccess;
+
+  if (!context)
+    return shaNull;
+
+  if ((context->Computed) || (length >= 8) || (length == 0)) {
+    context->Corrupted = shaStateError;
+    return shaStateError;
+  }
+
+  if (context->Corrupted)
+    return context->Corrupted;
+
+  SHA224_256AddLength(context, length);
+  SHA224_256Finalize(context, (uint8_t)
+    ((message_bits & masks[length]) | markbit[length]));
+
+  return shaSuccess;
+}
+
+/*
+ * SHA256Result
+ *
+ * Description:
+ *   This function will return the 256-bit message
+ *   digest into the Message_Digest array provided by the caller.
+ *   NOTE: The first octet of hash is stored in the 0th element,
+ *      the last octet of hash in the 32nd element.
+ *
+ * Parameters:
+ *   context: [in/out]
+ *     The context to use to calculate the SHA hash.
+ *   Message_Digest: [out]
+ *     Where the digest is returned.
+ *
+ * Returns:
+ *   sha Error Code.
+ */
+int SHA256Result(SHA256Context *context, uint8_t Message_Digest[])
+{
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 39]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+  return SHA224_256ResultN(context, Message_Digest, SHA256HashSize);
+}
+
+/*
+ * SHA224_256Finalize
+ *
+ * Description:
+ *   This helper function finishes off the digest calculations.
+ *
+ * Parameters:
+ *   context: [in/out]
+ *     The SHA context to update
+ *   Pad_Byte: [in]
+ *     The last byte to add to the digest before the 0-padding
+ *     and length. This will contain the last bits of the message
+ *     followed by another single bit. If the message was an
+ *     exact multiple of 8-bits long, Pad_Byte will be 0x80.
+ *
+ * Returns:
+ *   sha Error Code.
+ */
+static void SHA224_256Finalize(SHA256Context *context,
+    uint8_t Pad_Byte)
+{
+  int i;
+  SHA224_256PadMessage(context, Pad_Byte);
+  /* message may be sensitive, so clear it out */
+  for (i = 0; i < SHA256_Message_Block_Size; ++i)
+    context->Message_Block[i] = 0;
+  context->Length_Low = 0;  /* and clear length */
+  context->Length_High = 0;
+  context->Computed = 1;
+}
+
+/*
+ * SHA224_256PadMessage
+ *
+ * Description:
+ *   According to the standard, the message must be padded to an
+ *   even 512 bits. The first padding bit must be a '1'. The
+ *   last 64 bits represent the length of the original message.
+ *   All bits in between should be 0. This helper function will pad
+ *   the message according to those rules by filling the
+ *   Message_Block array accordingly. When it returns, it can be
+ *   assumed that the message digest has been computed.
+ *
+ * Parameters:
+ *   context: [in/out]
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 40]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+ *     The context to pad
+ *   Pad_Byte: [in]
+ *     The last byte to add to the digest before the 0-padding
+ *     and length. This will contain the last bits of the message
+ *     followed by another single bit. If the message was an
+ *     exact multiple of 8-bits long, Pad_Byte will be 0x80.
+ *
+ * Returns:
+ *   Nothing.
+ */
+static void SHA224_256PadMessage(SHA256Context *context,
+    uint8_t Pad_Byte)
+{
+  /*
+   * Check to see if the current message block is too small to hold
+   * the initial padding bits and length. If so, we will pad the
+   * block, process it, and then continue padding into a second
+   * block.
+   */
+  if (context->Message_Block_Index >= (SHA256_Message_Block_Size-8)) {
+    context->Message_Block[context->Message_Block_Index++] = Pad_Byte;
+    while (context->Message_Block_Index < SHA256_Message_Block_Size)
+      context->Message_Block[context->Message_Block_Index++] = 0;
+    SHA224_256ProcessMessageBlock(context);
+  } else
+    context->Message_Block[context->Message_Block_Index++] = Pad_Byte;
+
+  while (context->Message_Block_Index < (SHA256_Message_Block_Size-8))
+    context->Message_Block[context->Message_Block_Index++] = 0;
+
+  /*
+   * Store the message length as the last 8 octets
+   */
+  context->Message_Block[56] = (uint8_t)(context->Length_High >> 24);
+  context->Message_Block[57] = (uint8_t)(context->Length_High >> 16);
+  context->Message_Block[58] = (uint8_t)(context->Length_High >> 8);
+  context->Message_Block[59] = (uint8_t)(context->Length_High);
+  context->Message_Block[60] = (uint8_t)(context->Length_Low >> 24);
+  context->Message_Block[61] = (uint8_t)(context->Length_Low >> 16);
+  context->Message_Block[62] = (uint8_t)(context->Length_Low >> 8);
+  context->Message_Block[63] = (uint8_t)(context->Length_Low);
+
+  SHA224_256ProcessMessageBlock(context);
+}
+
+/*
+ * SHA224_256ProcessMessageBlock
+ *
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 41]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+ * Description:
+ *   This function will process the next 512 bits of the message
+ *   stored in the Message_Block array.
+ *
+ * Parameters:
+ *   context: [in/out]
+ *     The SHA context to update
+ *
+ * Returns:
+ *   Nothing.
+ *
+ * Comments:
+ *   Many of the variable names in this code, especially the
+ *   single character names, were used because those were the
+ *   names used in the publication.
+ */
+static void SHA224_256ProcessMessageBlock(SHA256Context *context)
+{
+  /* Constants defined in FIPS-180-2, section 4.2.2 */
+  static const uint32_t K[64] = {
+      0x428a2f98, 0x71374491, 0xb5c0fbcf, 0xe9b5dba5, 0x3956c25b,
+      0x59f111f1, 0x923f82a4, 0xab1c5ed5, 0xd807aa98, 0x12835b01,
+      0x243185be, 0x550c7dc3, 0x72be5d74, 0x80deb1fe, 0x9bdc06a7,
+      0xc19bf174, 0xe49b69c1, 0xefbe4786, 0x0fc19dc6, 0x240ca1cc,
+      0x2de92c6f, 0x4a7484aa, 0x5cb0a9dc, 0x76f988da, 0x983e5152,
+      0xa831c66d, 0xb00327c8, 0xbf597fc7, 0xc6e00bf3, 0xd5a79147,
+      0x06ca6351, 0x14292967, 0x27b70a85, 0x2e1b2138, 0x4d2c6dfc,
+      0x53380d13, 0x650a7354, 0x766a0abb, 0x81c2c92e, 0x92722c85,
+      0xa2bfe8a1, 0xa81a664b, 0xc24b8b70, 0xc76c51a3, 0xd192e819,
+      0xd6990624, 0xf40e3585, 0x106aa070, 0x19a4c116, 0x1e376c08,
+      0x2748774c, 0x34b0bcb5, 0x391c0cb3, 0x4ed8aa4a, 0x5b9cca4f,
+      0x682e6ff3, 0x748f82ee, 0x78a5636f, 0x84c87814, 0x8cc70208,
+      0x90befffa, 0xa4506ceb, 0xbef9a3f7, 0xc67178f2
+  };
+  int        t, t4;                   /* Loop counter */
+  uint32_t   temp1, temp2;            /* Temporary word value */
+  uint32_t   W[64];                   /* Word sequence */
+  uint32_t   A, B, C, D, E, F, G, H;  /* Word buffers */
+
+  /*
+   * Initialize the first 16 words in the array W
+   */
+  for (t = t4 = 0; t < 16; t++, t4 += 4)
+    W[t] = (((uint32_t)context->Message_Block[t4]) << 24) |
+           (((uint32_t)context->Message_Block[t4 + 1]) << 16) |
+           (((uint32_t)context->Message_Block[t4 + 2]) << 8) |
+           (((uint32_t)context->Message_Block[t4 + 3]));
+
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 42]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+  for (t = 16; t < 64; t++)
+    W[t] = SHA256_sigma1(W[t-2]) + W[t-7] +
+        SHA256_sigma0(W[t-15]) + W[t-16];
+
+  A = context->Intermediate_Hash[0];
+  B = context->Intermediate_Hash[1];
+  C = context->Intermediate_Hash[2];
+  D = context->Intermediate_Hash[3];
+  E = context->Intermediate_Hash[4];
+  F = context->Intermediate_Hash[5];
+  G = context->Intermediate_Hash[6];
+  H = context->Intermediate_Hash[7];
+
+  for (t = 0; t < 64; t++) {
+    temp1 = H + SHA256_SIGMA1(E) + SHA_Ch(E,F,G) + K[t] + W[t];
+    temp2 = SHA256_SIGMA0(A) + SHA_Maj(A,B,C);
+    H = G;
+    G = F;
+    F = E;
+    E = D + temp1;
+    D = C;
+    C = B;
+    B = A;
+    A = temp1 + temp2;
+  }
+
+  context->Intermediate_Hash[0] += A;
+  context->Intermediate_Hash[1] += B;
+  context->Intermediate_Hash[2] += C;
+  context->Intermediate_Hash[3] += D;
+  context->Intermediate_Hash[4] += E;
+  context->Intermediate_Hash[5] += F;
+  context->Intermediate_Hash[6] += G;
+  context->Intermediate_Hash[7] += H;
+
+  context->Message_Block_Index = 0;
+}
+
+/*
+ * SHA224_256Reset
+ *
+ * Description:
+ *   This helper function will initialize the SHA256Context in
+ *   preparation for computing a new SHA256 message digest.
+ *
+ * Parameters:
+ *   context: [in/out]
+ *     The context to reset.
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 43]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+ *   H0
+ *     The initial hash value to use.
+ *
+ * Returns:
+ *   sha Error Code.
+ */
+static int SHA224_256Reset(SHA256Context *context, uint32_t *H0)
+{
+  if (!context)
+    return shaNull;
+
+  context->Length_Low           = 0;
+  context->Length_High          = 0;
+  context->Message_Block_Index  = 0;
+
+  context->Intermediate_Hash[0] = H0[0];
+  context->Intermediate_Hash[1] = H0[1];
+  context->Intermediate_Hash[2] = H0[2];
+  context->Intermediate_Hash[3] = H0[3];
+  context->Intermediate_Hash[4] = H0[4];
+  context->Intermediate_Hash[5] = H0[5];
+  context->Intermediate_Hash[6] = H0[6];
+  context->Intermediate_Hash[7] = H0[7];
+
+  context->Computed  = 0;
+  context->Corrupted = 0;
+
+  return shaSuccess;
+}
+
+/*
+ * SHA224_256ResultN
+ *
+ * Description:
+ *   This helper function will return the 224-bit or 256-bit message
+ *   digest into the Message_Digest array provided by the caller.
+ *   NOTE: The first octet of hash is stored in the 0th element,
+ *      the last octet of hash in the 28th/32nd element.
+ *
+ * Parameters:
+ *   context: [in/out]
+ *     The context to use to calculate the SHA hash.
+ *   Message_Digest: [out]
+ *     Where the digest is returned.
+ *   HashSize: [in]
+ *     The size of the hash, either 28 or 32.
+ *
+ * Returns:
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 44]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+ *   sha Error Code.
+ */
+static int SHA224_256ResultN(SHA256Context *context,
+    uint8_t Message_Digest[], int HashSize)
+{
+  int i;
+
+  if (!context || !Message_Digest)
+    return shaNull;
+
+  if (context->Corrupted)
+    return context->Corrupted;
+
+  if (!context->Computed)
+    SHA224_256Finalize(context, 0x80);
+
+  for (i = 0; i < HashSize; ++i)
+    Message_Digest[i] = (uint8_t)
+      (context->Intermediate_Hash[i>>2] >> 8 * ( 3 - ( i & 0x03 ) ));
+
+  return shaSuccess;
+}
+
+8.2.3.  sha384-512.c
+
+/*************************** sha384-512.c ***************************/
+/********************* See RFC 4634 for details *********************/
+/*
+ * Description:
+ *   This file implements the Secure Hash Signature Standard
+ *   algorithms as defined in the National Institute of Standards
+ *   and Technology Federal Information Processing Standards
+ *   Publication (FIPS PUB) 180-1 published on April 17, 1995, 180-2
+ *   published on August 1, 2002, and the FIPS PUB 180-2 Change
+ *   Notice published on February 28, 2004.
+ *
+ *   A combined document showing all algorithms is available at
+ *       http://csrc.nist.gov/publications/fips/
+ *       fips180-2/fips180-2withchangenotice.pdf
+ *
+ *   The SHA-384 and SHA-512 algorithms produce 384-bit and 512-bit
+ *   message digests for a given data stream. It should take about
+ *   2**n steps to find a message with the same digest as a given
+ *   message and 2**(n/2) to find any two messages with the same
+ *   digest, when n is the digest size in bits. Therefore, this
+ *   algorithm can serve as a means of providing a
+ *   "fingerprint" for a message.
+ *
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 45]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+ * Portability Issues:
+ *   SHA-384 and SHA-512 are defined in terms of 64-bit "words",
+ *   but if USE_32BIT_ONLY is #defined, this code is implemented in
+ *   terms of 32-bit "words". This code uses <stdint.h> (included
+ *   via "sha.h") to define the 64, 32 and 8 bit unsigned integer
+ *   types. If your C compiler does not support 64 bit unsigned
+ *   integers, and you do not #define USE_32BIT_ONLY, this code is
+ *   not appropriate.
+ *
+ * Caveats:
+ *   SHA-384 and SHA-512 are designed to work with messages less
+ *   than 2^128 bits long. This implementation uses
+ *   SHA384/512Input() to hash the bits that are a multiple of the
+ *   size of an 8-bit character, and then uses SHA384/256FinalBits()
+ *   to hash the final few bits of the input.
+ *
+ */
+
+#include "sha.h"
+#include "sha-private.h"
+
+#ifdef USE_32BIT_ONLY
+/*
+ * Define 64-bit arithmetic in terms of 32-bit arithmetic.
+ * Each 64-bit number is represented in a 2-word array.
+ * All macros are defined such that the result is the last parameter.
+ */
+
+/*
+ * Define shift, rotate left and rotate right functions
+ */
+#define SHA512_SHR(bits, word, ret) (                          \
+    /* (((uint64_t)((word))) >> (bits)) */                     \
+    (ret)[0] = (((bits) < 32) && ((bits) >= 0)) ?              \
+      ((word)[0] >> (bits)) : 0,                               \
+    (ret)[1] = ((bits) > 32) ? ((word)[0] >> ((bits) - 32)) :  \
+      ((bits) == 32) ? (word)[0] :                             \
+      ((bits) >= 0) ?                                          \
+        (((word)[0] << (32 - (bits))) |                        \
+        ((word)[1] >> (bits))) : 0 )
+
+#define SHA512_SHL(bits, word, ret) (                          \
+    /* (((uint64_t)(word)) << (bits)) */                       \
+    (ret)[0] = ((bits) > 32) ? ((word)[1] << ((bits) - 32)) :  \
+         ((bits) == 32) ? (word)[1] :                          \
+         ((bits) >= 0) ?                                       \
+           (((word)[0] << (bits)) |                            \
+           ((word)[1] >> (32 - (bits)))) :                     \
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 46]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+         0,                                                    \
+    (ret)[1] = (((bits) < 32) && ((bits) >= 0)) ?              \
+        ((word)[1] << (bits)) : 0 )
+
+/*
+ * Define 64-bit OR
+ */
+#define SHA512_OR(word1, word2, ret) (                         \
+    (ret)[0] = (word1)[0] | (word2)[0],                        \
+    (ret)[1] = (word1)[1] | (word2)[1] )
+
+/*
+ * Define 64-bit XOR
+ */
+#define SHA512_XOR(word1, word2, ret) (                        \
+    (ret)[0] = (word1)[0] ^ (word2)[0],                        \
+    (ret)[1] = (word1)[1] ^ (word2)[1] )
+
+/*
+ * Define 64-bit AND
+ */
+#define SHA512_AND(word1, word2, ret) (                        \
+    (ret)[0] = (word1)[0] & (word2)[0],                        \
+    (ret)[1] = (word1)[1] & (word2)[1] )
+
+/*
+ * Define 64-bit TILDA
+ */
+#define SHA512_TILDA(word, ret)                                \
+  ( (ret)[0] = ~(word)[0], (ret)[1] = ~(word)[1] )
+
+/*
+ * Define 64-bit ADD
+ */
+#define SHA512_ADD(word1, word2, ret) (                        \
+    (ret)[1] = (word1)[1], (ret)[1] += (word2)[1],             \
+    (ret)[0] = (word1)[0] + (word2)[0] + ((ret)[1] < (word1)[1]) )
+
+/*
+ * Add the 4word value in word2 to word1.
+ */
+static uint32_t ADDTO4_temp, ADDTO4_temp2;
+#define SHA512_ADDTO4(word1, word2) (                          \
+    ADDTO4_temp = (word1)[3],                                  \
+    (word1)[3] += (word2)[3],                                  \
+    ADDTO4_temp2 = (word1)[2],                                 \
+    (word1)[2] += (word2)[2] + ((word1)[3] < ADDTO4_temp),     \
+    ADDTO4_temp = (word1)[1],                                  \
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 47]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+    (word1)[1] += (word2)[1] + ((word1)[2] < ADDTO4_temp2),    \
+    (word1)[0] += (word2)[0] + ((word1)[1] < ADDTO4_temp) )
+
+/*
+ * Add the 2word value in word2 to word1.
+ */
+static uint32_t ADDTO2_temp;
+#define SHA512_ADDTO2(word1, word2) (                          \
+    ADDTO2_temp = (word1)[1],                                  \
+    (word1)[1] += (word2)[1],                                  \
+    (word1)[0] += (word2)[0] + ((word1)[1] < ADDTO2_temp) )
+
+/*
+ * SHA rotate   ((word >> bits) | (word << (64-bits)))
+ */
+static uint32_t ROTR_temp1[2], ROTR_temp2[2];
+#define SHA512_ROTR(bits, word, ret) (                         \
+    SHA512_SHR((bits), (word), ROTR_temp1),                    \
+    SHA512_SHL(64-(bits), (word), ROTR_temp2),                 \
+    SHA512_OR(ROTR_temp1, ROTR_temp2, (ret)) )
+
+/*
+ * Define the SHA SIGMA and sigma macros
+ *  SHA512_ROTR(28,word) ^ SHA512_ROTR(34,word) ^ SHA512_ROTR(39,word)
+ */
+static uint32_t SIGMA0_temp1[2], SIGMA0_temp2[2],
+  SIGMA0_temp3[2], SIGMA0_temp4[2];
+#define SHA512_SIGMA0(word, ret) (                             \
+    SHA512_ROTR(28, (word), SIGMA0_temp1),                     \
+    SHA512_ROTR(34, (word), SIGMA0_temp2),                     \
+    SHA512_ROTR(39, (word), SIGMA0_temp3),                     \
+    SHA512_XOR(SIGMA0_temp2, SIGMA0_temp3, SIGMA0_temp4),      \
+    SHA512_XOR(SIGMA0_temp1, SIGMA0_temp4, (ret)) )
+
+/*
+ * SHA512_ROTR(14,word) ^ SHA512_ROTR(18,word) ^ SHA512_ROTR(41,word)
+ */
+static uint32_t SIGMA1_temp1[2], SIGMA1_temp2[2],
+  SIGMA1_temp3[2], SIGMA1_temp4[2];
+#define SHA512_SIGMA1(word, ret) (                             \
+    SHA512_ROTR(14, (word), SIGMA1_temp1),                     \
+    SHA512_ROTR(18, (word), SIGMA1_temp2),                     \
+    SHA512_ROTR(41, (word), SIGMA1_temp3),                     \
+    SHA512_XOR(SIGMA1_temp2, SIGMA1_temp3, SIGMA1_temp4),      \
+    SHA512_XOR(SIGMA1_temp1, SIGMA1_temp4, (ret)) )
+
+/*
+ * (SHA512_ROTR( 1,word) ^ SHA512_ROTR( 8,word) ^ SHA512_SHR( 7,word))
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 48]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+ */
+static uint32_t sigma0_temp1[2], sigma0_temp2[2],
+  sigma0_temp3[2], sigma0_temp4[2];
+#define SHA512_sigma0(word, ret) (                             \
+    SHA512_ROTR( 1, (word), sigma0_temp1),                     \
+    SHA512_ROTR( 8, (word), sigma0_temp2),                     \
+    SHA512_SHR( 7, (word), sigma0_temp3),                      \
+    SHA512_XOR(sigma0_temp2, sigma0_temp3, sigma0_temp4),      \
+    SHA512_XOR(sigma0_temp1, sigma0_temp4, (ret)) )
+
+/*
+ * (SHA512_ROTR(19,word) ^ SHA512_ROTR(61,word) ^ SHA512_SHR( 6,word))
+ */
+static uint32_t sigma1_temp1[2], sigma1_temp2[2],
+  sigma1_temp3[2], sigma1_temp4[2];
+#define SHA512_sigma1(word, ret) (                             \
+    SHA512_ROTR(19, (word), sigma1_temp1),                     \
+    SHA512_ROTR(61, (word), sigma1_temp2),                     \
+    SHA512_SHR( 6, (word), sigma1_temp3),                      \
+    SHA512_XOR(sigma1_temp2, sigma1_temp3, sigma1_temp4),      \
+    SHA512_XOR(sigma1_temp1, sigma1_temp4, (ret)) )
+
+#undef SHA_Ch
+#undef SHA_Maj
+
+#ifndef USE_MODIFIED_MACROS
+/*
+ * These definitions are the ones used in FIPS-180-2, section 4.1.3
+ *  Ch(x,y,z)   ((x & y) ^ (~x & z))
+ */
+static uint32_t Ch_temp1[2], Ch_temp2[2], Ch_temp3[2];
+#define SHA_Ch(x, y, z, ret) (                                 \
+    SHA512_AND(x, y, Ch_temp1),                                \
+    SHA512_TILDA(x, Ch_temp2),                                 \
+    SHA512_AND(Ch_temp2, z, Ch_temp3),                         \
+    SHA512_XOR(Ch_temp1, Ch_temp3, (ret)) )
+/*
+ *  Maj(x,y,z)  (((x)&(y)) ^ ((x)&(z)) ^ ((y)&(z)))
+ */
+static uint32_t Maj_temp1[2], Maj_temp2[2],
+  Maj_temp3[2], Maj_temp4[2];
+#define SHA_Maj(x, y, z, ret) (                                \
+    SHA512_AND(x, y, Maj_temp1),                               \
+    SHA512_AND(x, z, Maj_temp2),                               \
+    SHA512_AND(y, z, Maj_temp3),                               \
+    SHA512_XOR(Maj_temp2, Maj_temp3, Maj_temp4),               \
+    SHA512_XOR(Maj_temp1, Maj_temp4, (ret)) )
+
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 49]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+#else /* !USE_32BIT_ONLY */
+/*
+ * These definitions are potentially faster equivalents for the ones
+ * used in FIPS-180-2, section 4.1.3.
+ *   ((x & y) ^ (~x & z)) becomes
+ *   ((x & (y ^ z)) ^ z)
+ */
+#define SHA_Ch(x, y, z, ret) (                                 \
+   (ret)[0] = (((x)[0] & ((y)[0] ^ (z)[0])) ^ (z)[0]),         \
+   (ret)[1] = (((x)[1] & ((y)[1] ^ (z)[1])) ^ (z)[1]) )
+
+/*
+ *   ((x & y) ^ (x & z) ^ (y & z)) becomes
+ *   ((x & (y | z)) | (y & z))
+ */
+#define SHA_Maj(x, y, z, ret) (                                 \
+   ret[0] = (((x)[0] & ((y)[0] | (z)[0])) | ((y)[0] & (z)[0])), \
+   ret[1] = (((x)[1] & ((y)[1] | (z)[1])) | ((y)[1] & (z)[1])) )
+#endif /* USE_MODIFIED_MACROS */
+
+/*
+ * add "length" to the length
+ */
+static uint32_t addTemp[4] = { 0, 0, 0, 0 };
+#define SHA384_512AddLength(context, length) (                        \
+    addTemp[3] = (length), SHA512_ADDTO4((context)->Length, addTemp), \
+    (context)->Corrupted = (((context)->Length[3] == 0) &&            \
+       ((context)->Length[2] == 0) && ((context)->Length[1] == 0) &&  \
+       ((context)->Length[0] < 8)) ? 1 : 0 )
+
+/* Local Function Prototypes */
+static void SHA384_512Finalize(SHA512Context *context,
+  uint8_t Pad_Byte);
+static void SHA384_512PadMessage(SHA512Context *context,
+  uint8_t Pad_Byte);
+static void SHA384_512ProcessMessageBlock(SHA512Context *context);
+static int SHA384_512Reset(SHA512Context *context, uint32_t H0[]);
+static int SHA384_512ResultN( SHA512Context *context,
+  uint8_t Message_Digest[], int HashSize);
+
+/* Initial Hash Values: FIPS-180-2 sections 5.3.3 and 5.3.4 */
+static uint32_t SHA384_H0[SHA512HashSize/4] = {
+    0xCBBB9D5D, 0xC1059ED8, 0x629A292A, 0x367CD507, 0x9159015A,
+    0x3070DD17, 0x152FECD8, 0xF70E5939, 0x67332667, 0xFFC00B31,
+    0x8EB44A87, 0x68581511, 0xDB0C2E0D, 0x64F98FA7, 0x47B5481D,
+    0xBEFA4FA4
+};
+
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 50]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+static uint32_t SHA512_H0[SHA512HashSize/4] = {
+    0x6A09E667, 0xF3BCC908, 0xBB67AE85, 0x84CAA73B, 0x3C6EF372,
+    0xFE94F82B, 0xA54FF53A, 0x5F1D36F1, 0x510E527F, 0xADE682D1,
+    0x9B05688C, 0x2B3E6C1F, 0x1F83D9AB, 0xFB41BD6B, 0x5BE0CD19,
+    0x137E2179
+};
+
+#else /* !USE_32BIT_ONLY */
+
+/* Define the SHA shift, rotate left and rotate right macro */
+#define SHA512_SHR(bits,word)  (((uint64_t)(word)) >> (bits))
+#define SHA512_ROTR(bits,word) ((((uint64_t)(word)) >> (bits)) | \
+                                (((uint64_t)(word)) << (64-(bits))))
+
+/* Define the SHA SIGMA and sigma macros */
+#define SHA512_SIGMA0(word)   \
+ (SHA512_ROTR(28,word) ^ SHA512_ROTR(34,word) ^ SHA512_ROTR(39,word))
+#define SHA512_SIGMA1(word)   \
+ (SHA512_ROTR(14,word) ^ SHA512_ROTR(18,word) ^ SHA512_ROTR(41,word))
+#define SHA512_sigma0(word)   \
+ (SHA512_ROTR( 1,word) ^ SHA512_ROTR( 8,word) ^ SHA512_SHR( 7,word))
+#define SHA512_sigma1(word)   \
+ (SHA512_ROTR(19,word) ^ SHA512_ROTR(61,word) ^ SHA512_SHR( 6,word))
+
+/*
+ * add "length" to the length
+ */
+static uint64_t addTemp;
+#define SHA384_512AddLength(context, length)                   \
+   (addTemp = context->Length_Low, context->Corrupted =        \
+    ((context->Length_Low += length) < addTemp) &&             \
+    (++context->Length_High == 0) ? 1 : 0)
+
+/* Local Function Prototypes */
+static void SHA384_512Finalize(SHA512Context *context,
+  uint8_t Pad_Byte);
+static void SHA384_512PadMessage(SHA512Context *context,
+  uint8_t Pad_Byte);
+static void SHA384_512ProcessMessageBlock(SHA512Context *context);
+static int SHA384_512Reset(SHA512Context *context, uint64_t H0[]);
+static int SHA384_512ResultN(SHA512Context *context,
+  uint8_t Message_Digest[], int HashSize);
+
+/* Initial Hash Values: FIPS-180-2 sections 5.3.3 and 5.3.4 */
+static uint64_t SHA384_H0[] = {
+    0xCBBB9D5DC1059ED8ll, 0x629A292A367CD507ll, 0x9159015A3070DD17ll,
+    0x152FECD8F70E5939ll, 0x67332667FFC00B31ll, 0x8EB44A8768581511ll,
+    0xDB0C2E0D64F98FA7ll, 0x47B5481DBEFA4FA4ll
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 51]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+};
+static uint64_t SHA512_H0[] = {
+    0x6A09E667F3BCC908ll, 0xBB67AE8584CAA73Bll, 0x3C6EF372FE94F82Bll,
+    0xA54FF53A5F1D36F1ll, 0x510E527FADE682D1ll, 0x9B05688C2B3E6C1Fll,
+    0x1F83D9ABFB41BD6Bll, 0x5BE0CD19137E2179ll
+};
+
+#endif /* USE_32BIT_ONLY */
+
+/*
+ * SHA384Reset
+ *
+ * Description:
+ *   This function will initialize the SHA384Context in preparation
+ *   for computing a new SHA384 message digest.
+ *
+ * Parameters:
+ *   context: [in/out]
+ *     The context to reset.
+ *
+ * Returns:
+ *   sha Error Code.
+ *
+ */
+int SHA384Reset(SHA384Context *context)
+{
+  return SHA384_512Reset(context, SHA384_H0);
+}
+
+/*
+ * SHA384Input
+ *
+ * Description:
+ *   This function accepts an array of octets as the next portion
+ *   of the message.
+ *
+ * Parameters:
+ *   context: [in/out]
+ *     The SHA context to update
+ *   message_array: [in]
+ *     An array of characters representing the next portion of
+ *     the message.
+ *   length: [in]
+ *     The length of the message in message_array
+ *
+ * Returns:
+ *   sha Error Code.
+ *
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 52]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+ */
+int SHA384Input(SHA384Context *context,
+    const uint8_t *message_array, unsigned int length)
+{
+  return SHA512Input(context, message_array, length);
+}
+
+/*
+ * SHA384FinalBits
+ *
+ * Description:
+ *   This function will add in any final bits of the message.
+ *
+ * Parameters:
+ *   context: [in/out]
+ *     The SHA context to update
+ *   message_bits: [in]
+ *     The final bits of the message, in the upper portion of the
+ *     byte. (Use 0b###00000 instead of 0b00000### to input the
+ *     three bits ###.)
+ *   length: [in]
+ *     The number of bits in message_bits, between 1 and 7.
+ *
+ * Returns:
+ *   sha Error Code.
+ *
+ */
+int SHA384FinalBits(SHA384Context *context,
+    const uint8_t message_bits, unsigned int length)
+{
+  return SHA512FinalBits(context, message_bits, length);
+}
+
+/*
+ * SHA384Result
+ *
+ * Description:
+ *   This function will return the 384-bit message
+ *   digest into the Message_Digest array provided by the caller.
+ *   NOTE: The first octet of hash is stored in the 0th element,
+ *      the last octet of hash in the 48th element.
+ *
+ * Parameters:
+ *   context: [in/out]
+ *     The context to use to calculate the SHA hash.
+ *   Message_Digest: [out]
+ *     Where the digest is returned.
+ *
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 53]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+ * Returns:
+ *   sha Error Code.
+ *
+ */
+int SHA384Result(SHA384Context *context,
+    uint8_t Message_Digest[SHA384HashSize])
+{
+  return SHA384_512ResultN(context, Message_Digest, SHA384HashSize);
+}
+
+/*
+ * SHA512Reset
+ *
+ * Description:
+ *   This function will initialize the SHA512Context in preparation
+ *   for computing a new SHA512 message digest.
+ *
+ * Parameters:
+ *   context: [in/out]
+ *     The context to reset.
+ *
+ * Returns:
+ *   sha Error Code.
+ *
+ */
+int SHA512Reset(SHA512Context *context)
+{
+  return SHA384_512Reset(context, SHA512_H0);
+}
+
+/*
+ * SHA512Input
+ *
+ * Description:
+ *   This function accepts an array of octets as the next portion
+ *   of the message.
+ *
+ * Parameters:
+ *   context: [in/out]
+ *     The SHA context to update
+ *   message_array: [in]
+ *     An array of characters representing the next portion of
+ *     the message.
+ *   length: [in]
+ *     The length of the message in message_array
+ *
+ * Returns:
+ *   sha Error Code.
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 54]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+ *
+ */
+int SHA512Input(SHA512Context *context,
+        const uint8_t *message_array,
+        unsigned int length)
+{
+  if (!length)
+    return shaSuccess;
+
+  if (!context || !message_array)
+    return shaNull;
+
+  if (context->Computed) {
+    context->Corrupted = shaStateError;
+    return shaStateError;
+  }
+
+  if (context->Corrupted)
+     return context->Corrupted;
+
+  while (length-- && !context->Corrupted) {
+    context->Message_Block[context->Message_Block_Index++] =
+            (*message_array & 0xFF);
+
+    if (!SHA384_512AddLength(context, 8) &&
+      (context->Message_Block_Index == SHA512_Message_Block_Size))
+      SHA384_512ProcessMessageBlock(context);
+
+    message_array++;
+  }
+
+  return shaSuccess;
+}
+
+/*
+ * SHA512FinalBits
+ *
+ * Description:
+ *   This function will add in any final bits of the message.
+ *
+ * Parameters:
+ *   context: [in/out]
+ *     The SHA context to update
+ *   message_bits: [in]
+ *     The final bits of the message, in the upper portion of the
+ *     byte. (Use 0b###00000 instead of 0b00000### to input the
+ *     three bits ###.)
+ *   length: [in]
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 55]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+ *     The number of bits in message_bits, between 1 and 7.
+ *
+ * Returns:
+ *   sha Error Code.
+ *
+ */
+int SHA512FinalBits(SHA512Context *context,
+    const uint8_t message_bits, unsigned int length)
+{
+  uint8_t masks[8] = {
+      /* 0 0b00000000 */ 0x00, /* 1 0b10000000 */ 0x80,
+      /* 2 0b11000000 */ 0xC0, /* 3 0b11100000 */ 0xE0,
+      /* 4 0b11110000 */ 0xF0, /* 5 0b11111000 */ 0xF8,
+      /* 6 0b11111100 */ 0xFC, /* 7 0b11111110 */ 0xFE
+  };
+  uint8_t markbit[8] = {
+      /* 0 0b10000000 */ 0x80, /* 1 0b01000000 */ 0x40,
+      /* 2 0b00100000 */ 0x20, /* 3 0b00010000 */ 0x10,
+      /* 4 0b00001000 */ 0x08, /* 5 0b00000100 */ 0x04,
+      /* 6 0b00000010 */ 0x02, /* 7 0b00000001 */ 0x01
+  };
+
+  if (!length)
+    return shaSuccess;
+
+  if (!context)
+    return shaNull;
+
+  if ((context->Computed) || (length >= 8) || (length == 0)) {
+    context->Corrupted = shaStateError;
+    return shaStateError;
+  }
+
+  if (context->Corrupted)
+     return context->Corrupted;
+
+  SHA384_512AddLength(context, length);
+  SHA384_512Finalize(context, (uint8_t)
+    ((message_bits & masks[length]) | markbit[length]));
+
+  return shaSuccess;
+}
+
+/*
+ * SHA384_512Finalize
+ *
+ * Description:
+ *   This helper function finishes off the digest calculations.
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 56]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+ *
+ * Parameters:
+ *   context: [in/out]
+ *     The SHA context to update
+ *   Pad_Byte: [in]
+ *     The last byte to add to the digest before the 0-padding
+ *     and length. This will contain the last bits of the message
+ *     followed by another single bit. If the message was an
+ *     exact multiple of 8-bits long, Pad_Byte will be 0x80.
+ *
+ * Returns:
+ *   sha Error Code.
+ *
+ */
+static void SHA384_512Finalize(SHA512Context *context,
+    uint8_t Pad_Byte)
+{
+  int_least16_t i;
+  SHA384_512PadMessage(context, Pad_Byte);
+  /* message may be sensitive, clear it out */
+  for (i = 0; i < SHA512_Message_Block_Size; ++i)
+    context->Message_Block[i] = 0;
+#ifdef USE_32BIT_ONLY    /* and clear length */
+  context->Length[0] = context->Length[1] = 0;
+  context->Length[2] = context->Length[3] = 0;
+#else /* !USE_32BIT_ONLY */
+  context->Length_Low = 0;
+  context->Length_High = 0;
+#endif /* USE_32BIT_ONLY */
+  context->Computed = 1;
+}
+
+/*
+ * SHA512Result
+ *
+ * Description:
+ *   This function will return the 512-bit message
+ *   digest into the Message_Digest array provided by the caller.
+ *   NOTE: The first octet of hash is stored in the 0th element,
+ *      the last octet of hash in the 64th element.
+ *
+ * Parameters:
+ *   context: [in/out]
+ *     The context to use to calculate the SHA hash.
+ *   Message_Digest: [out]
+ *     Where the digest is returned.
+ *
+ * Returns:
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 57]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+ *   sha Error Code.
+ *
+ */
+int SHA512Result(SHA512Context *context,
+    uint8_t Message_Digest[SHA512HashSize])
+{
+  return SHA384_512ResultN(context, Message_Digest, SHA512HashSize);
+}
+
+/*
+ * SHA384_512PadMessage
+ *
+ * Description:
+ *   According to the standard, the message must be padded to an
+ *   even 1024 bits. The first padding bit must be a '1'. The
+ *   last 128 bits represent the length of the original message.
+ *   All bits in between should be 0. This helper function will
+ *   pad the message according to those rules by filling the
+ *   Message_Block array accordingly. When it returns, it can be
+ *   assumed that the message digest has been computed.
+ *
+ * Parameters:
+ *   context: [in/out]
+ *     The context to pad
+ *   Pad_Byte: [in]
+ *     The last byte to add to the digest before the 0-padding
+ *     and length. This will contain the last bits of the message
+ *     followed by another single bit. If the message was an
+ *     exact multiple of 8-bits long, Pad_Byte will be 0x80.
+ *
+ * Returns:
+ *   Nothing.
+ *
+ */
+static void SHA384_512PadMessage(SHA512Context *context,
+    uint8_t Pad_Byte)
+{
+  /*
+   * Check to see if the current message block is too small to hold
+   * the initial padding bits and length. If so, we will pad the
+   * block, process it, and then continue padding into a second
+   * block.
+   */
+  if (context->Message_Block_Index >= (SHA512_Message_Block_Size-16)) {
+    context->Message_Block[context->Message_Block_Index++] = Pad_Byte;
+    while (context->Message_Block_Index < SHA512_Message_Block_Size)
+      context->Message_Block[context->Message_Block_Index++] = 0;
+
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 58]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+    SHA384_512ProcessMessageBlock(context);
+  } else
+    context->Message_Block[context->Message_Block_Index++] = Pad_Byte;
+
+  while (context->Message_Block_Index < (SHA512_Message_Block_Size-16))
+    context->Message_Block[context->Message_Block_Index++] = 0;
+
+  /*
+   * Store the message length as the last 16 octets
+   */
+#ifdef USE_32BIT_ONLY
+  context->Message_Block[112] = (uint8_t)(context->Length[0] >> 24);
+  context->Message_Block[113] = (uint8_t)(context->Length[0] >> 16);
+  context->Message_Block[114] = (uint8_t)(context->Length[0] >> 8);
+  context->Message_Block[115] = (uint8_t)(context->Length[0]);
+  context->Message_Block[116] = (uint8_t)(context->Length[1] >> 24);
+  context->Message_Block[117] = (uint8_t)(context->Length[1] >> 16);
+  context->Message_Block[118] = (uint8_t)(context->Length[1] >> 8);
+  context->Message_Block[119] = (uint8_t)(context->Length[1]);
+
+  context->Message_Block[120] = (uint8_t)(context->Length[2] >> 24);
+  context->Message_Block[121] = (uint8_t)(context->Length[2] >> 16);
+  context->Message_Block[122] = (uint8_t)(context->Length[2] >> 8);
+  context->Message_Block[123] = (uint8_t)(context->Length[2]);
+  context->Message_Block[124] = (uint8_t)(context->Length[3] >> 24);
+  context->Message_Block[125] = (uint8_t)(context->Length[3] >> 16);
+  context->Message_Block[126] = (uint8_t)(context->Length[3] >> 8);
+  context->Message_Block[127] = (uint8_t)(context->Length[3]);
+#else /* !USE_32BIT_ONLY */
+  context->Message_Block[112] = (uint8_t)(context->Length_High >> 56);
+  context->Message_Block[113] = (uint8_t)(context->Length_High >> 48);
+  context->Message_Block[114] = (uint8_t)(context->Length_High >> 40);
+  context->Message_Block[115] = (uint8_t)(context->Length_High >> 32);
+  context->Message_Block[116] = (uint8_t)(context->Length_High >> 24);
+  context->Message_Block[117] = (uint8_t)(context->Length_High >> 16);
+  context->Message_Block[118] = (uint8_t)(context->Length_High >> 8);
+  context->Message_Block[119] = (uint8_t)(context->Length_High);
+
+  context->Message_Block[120] = (uint8_t)(context->Length_Low >> 56);
+  context->Message_Block[121] = (uint8_t)(context->Length_Low >> 48);
+  context->Message_Block[122] = (uint8_t)(context->Length_Low >> 40);
+  context->Message_Block[123] = (uint8_t)(context->Length_Low >> 32);
+  context->Message_Block[124] = (uint8_t)(context->Length_Low >> 24);
+  context->Message_Block[125] = (uint8_t)(context->Length_Low >> 16);
+  context->Message_Block[126] = (uint8_t)(context->Length_Low >> 8);
+  context->Message_Block[127] = (uint8_t)(context->Length_Low);
+#endif /* USE_32BIT_ONLY */
+
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 59]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+  SHA384_512ProcessMessageBlock(context);
+}
+
+/*
+ * SHA384_512ProcessMessageBlock
+ *
+ * Description:
+ *   This helper function will process the next 1024 bits of the
+ *   message stored in the Message_Block array.
+ *
+ * Parameters:
+ *   context: [in/out]
+ *     The SHA context to update
+ *
+ * Returns:
+ *   Nothing.
+ *
+ * Comments:
+ *   Many of the variable names in this code, especially the
+ *   single character names, were used because those were the
+ *   names used in the publication.
+ *
+ *
+ */
+static void SHA384_512ProcessMessageBlock(SHA512Context *context)
+{
+  /* Constants defined in FIPS-180-2, section 4.2.3 */
+#ifdef USE_32BIT_ONLY
+  static const uint32_t K[80*2] = {
+      0x428A2F98, 0xD728AE22, 0x71374491, 0x23EF65CD, 0xB5C0FBCF,
+      0xEC4D3B2F, 0xE9B5DBA5, 0x8189DBBC, 0x3956C25B, 0xF348B538,
+      0x59F111F1, 0xB605D019, 0x923F82A4, 0xAF194F9B, 0xAB1C5ED5,
+      0xDA6D8118, 0xD807AA98, 0xA3030242, 0x12835B01, 0x45706FBE,
+      0x243185BE, 0x4EE4B28C, 0x550C7DC3, 0xD5FFB4E2, 0x72BE5D74,
+      0xF27B896F, 0x80DEB1FE, 0x3B1696B1, 0x9BDC06A7, 0x25C71235,
+      0xC19BF174, 0xCF692694, 0xE49B69C1, 0x9EF14AD2, 0xEFBE4786,
+      0x384F25E3, 0x0FC19DC6, 0x8B8CD5B5, 0x240CA1CC, 0x77AC9C65,
+      0x2DE92C6F, 0x592B0275, 0x4A7484AA, 0x6EA6E483, 0x5CB0A9DC,
+      0xBD41FBD4, 0x76F988DA, 0x831153B5, 0x983E5152, 0xEE66DFAB,
+      0xA831C66D, 0x2DB43210, 0xB00327C8, 0x98FB213F, 0xBF597FC7,
+      0xBEEF0EE4, 0xC6E00BF3, 0x3DA88FC2, 0xD5A79147, 0x930AA725,
+      0x06CA6351, 0xE003826F, 0x14292967, 0x0A0E6E70, 0x27B70A85,
+      0x46D22FFC, 0x2E1B2138, 0x5C26C926, 0x4D2C6DFC, 0x5AC42AED,
+      0x53380D13, 0x9D95B3DF, 0x650A7354, 0x8BAF63DE, 0x766A0ABB,
+      0x3C77B2A8, 0x81C2C92E, 0x47EDAEE6, 0x92722C85, 0x1482353B,
+      0xA2BFE8A1, 0x4CF10364, 0xA81A664B, 0xBC423001, 0xC24B8B70,
+      0xD0F89791, 0xC76C51A3, 0x0654BE30, 0xD192E819, 0xD6EF5218,
+      0xD6990624, 0x5565A910, 0xF40E3585, 0x5771202A, 0x106AA070,
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 60]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+      0x32BBD1B8, 0x19A4C116, 0xB8D2D0C8, 0x1E376C08, 0x5141AB53,
+      0x2748774C, 0xDF8EEB99, 0x34B0BCB5, 0xE19B48A8, 0x391C0CB3,
+      0xC5C95A63, 0x4ED8AA4A, 0xE3418ACB, 0x5B9CCA4F, 0x7763E373,
+      0x682E6FF3, 0xD6B2B8A3, 0x748F82EE, 0x5DEFB2FC, 0x78A5636F,
+      0x43172F60, 0x84C87814, 0xA1F0AB72, 0x8CC70208, 0x1A6439EC,
+      0x90BEFFFA, 0x23631E28, 0xA4506CEB, 0xDE82BDE9, 0xBEF9A3F7,
+      0xB2C67915, 0xC67178F2, 0xE372532B, 0xCA273ECE, 0xEA26619C,
+      0xD186B8C7, 0x21C0C207, 0xEADA7DD6, 0xCDE0EB1E, 0xF57D4F7F,
+      0xEE6ED178, 0x06F067AA, 0x72176FBA, 0x0A637DC5, 0xA2C898A6,
+      0x113F9804, 0xBEF90DAE, 0x1B710B35, 0x131C471B, 0x28DB77F5,
+      0x23047D84, 0x32CAAB7B, 0x40C72493, 0x3C9EBE0A, 0x15C9BEBC,
+      0x431D67C4, 0x9C100D4C, 0x4CC5D4BE, 0xCB3E42B6, 0x597F299C,
+      0xFC657E2A, 0x5FCB6FAB, 0x3AD6FAEC, 0x6C44198C, 0x4A475817
+  };
+  int     t, t2, t8;                  /* Loop counter */
+  uint32_t  temp1[2], temp2[2],       /* Temporary word values */
+        temp3[2], temp4[2], temp5[2];
+  uint32_t  W[2*80];                  /* Word sequence */
+  uint32_t  A[2], B[2], C[2], D[2],   /* Word buffers */
+        E[2], F[2], G[2], H[2];
+
+  /* Initialize the first 16 words in the array W */
+  for (t = t2 = t8 = 0; t < 16; t++, t8 += 8) {
+    W[t2++] = ((((uint32_t)context->Message_Block[t8    ])) << 24) |
+              ((((uint32_t)context->Message_Block[t8 + 1])) << 16) |
+              ((((uint32_t)context->Message_Block[t8 + 2])) << 8) |
+              ((((uint32_t)context->Message_Block[t8 + 3])));
+    W[t2++] = ((((uint32_t)context->Message_Block[t8 + 4])) << 24) |
+              ((((uint32_t)context->Message_Block[t8 + 5])) << 16) |
+              ((((uint32_t)context->Message_Block[t8 + 6])) << 8) |
+              ((((uint32_t)context->Message_Block[t8 + 7])));
+  }
+
+  for (t = 16; t < 80; t++, t2 += 2) {
+    /* W[t] = SHA512_sigma1(W[t-2]) + W[t-7] +
+      SHA512_sigma0(W[t-15]) + W[t-16]; */
+    uint32_t *Wt2 = &W[t2-2*2];
+    uint32_t *Wt7 = &W[t2-7*2];
+    uint32_t *Wt15 = &W[t2-15*2];
+    uint32_t *Wt16 = &W[t2-16*2];
+    SHA512_sigma1(Wt2, temp1);
+    SHA512_ADD(temp1, Wt7, temp2);
+    SHA512_sigma0(Wt15, temp1);
+    SHA512_ADD(temp1, Wt16, temp3);
+    SHA512_ADD(temp2, temp3, &W[t2]);
+  }
+
+  A[0] = context->Intermediate_Hash[0];
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 61]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+  A[1] = context->Intermediate_Hash[1];
+  B[0] = context->Intermediate_Hash[2];
+  B[1] = context->Intermediate_Hash[3];
+  C[0] = context->Intermediate_Hash[4];
+  C[1] = context->Intermediate_Hash[5];
+  D[0] = context->Intermediate_Hash[6];
+  D[1] = context->Intermediate_Hash[7];
+  E[0] = context->Intermediate_Hash[8];
+  E[1] = context->Intermediate_Hash[9];
+  F[0] = context->Intermediate_Hash[10];
+  F[1] = context->Intermediate_Hash[11];
+  G[0] = context->Intermediate_Hash[12];
+  G[1] = context->Intermediate_Hash[13];
+  H[0] = context->Intermediate_Hash[14];
+  H[1] = context->Intermediate_Hash[15];
+
+  for (t = t2 = 0; t < 80; t++, t2 += 2) {
+    /*
+     * temp1 = H + SHA512_SIGMA1(E) + SHA_Ch(E,F,G) + K[t] + W[t];
+     */
+    SHA512_SIGMA1(E,temp1);
+    SHA512_ADD(H, temp1, temp2);
+    SHA_Ch(E,F,G,temp3);
+    SHA512_ADD(temp2, temp3, temp4);
+    SHA512_ADD(&K[t2], &W[t2], temp5);
+    SHA512_ADD(temp4, temp5, temp1);
+    /*
+     * temp2 = SHA512_SIGMA0(A) + SHA_Maj(A,B,C);
+     */
+    SHA512_SIGMA0(A,temp3);
+    SHA_Maj(A,B,C,temp4);
+    SHA512_ADD(temp3, temp4, temp2);
+    H[0] = G[0]; H[1] = G[1];
+    G[0] = F[0]; G[1] = F[1];
+    F[0] = E[0]; F[1] = E[1];
+    SHA512_ADD(D, temp1, E);
+    D[0] = C[0]; D[1] = C[1];
+    C[0] = B[0]; C[1] = B[1];
+    B[0] = A[0]; B[1] = A[1];
+    SHA512_ADD(temp1, temp2, A);
+  }
+
+  SHA512_ADDTO2(&context->Intermediate_Hash[0], A);
+  SHA512_ADDTO2(&context->Intermediate_Hash[2], B);
+  SHA512_ADDTO2(&context->Intermediate_Hash[4], C);
+  SHA512_ADDTO2(&context->Intermediate_Hash[6], D);
+  SHA512_ADDTO2(&context->Intermediate_Hash[8], E);
+  SHA512_ADDTO2(&context->Intermediate_Hash[10], F);
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 62]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+  SHA512_ADDTO2(&context->Intermediate_Hash[12], G);
+  SHA512_ADDTO2(&context->Intermediate_Hash[14], H);
+
+#else /* !USE_32BIT_ONLY */
+  static const uint64_t K[80] = {
+      0x428A2F98D728AE22ll, 0x7137449123EF65CDll, 0xB5C0FBCFEC4D3B2Fll,
+      0xE9B5DBA58189DBBCll, 0x3956C25BF348B538ll, 0x59F111F1B605D019ll,
+      0x923F82A4AF194F9Bll, 0xAB1C5ED5DA6D8118ll, 0xD807AA98A3030242ll,
+      0x12835B0145706FBEll, 0x243185BE4EE4B28Cll, 0x550C7DC3D5FFB4E2ll,
+      0x72BE5D74F27B896Fll, 0x80DEB1FE3B1696B1ll, 0x9BDC06A725C71235ll,
+      0xC19BF174CF692694ll, 0xE49B69C19EF14AD2ll, 0xEFBE4786384F25E3ll,
+      0x0FC19DC68B8CD5B5ll, 0x240CA1CC77AC9C65ll, 0x2DE92C6F592B0275ll,
+      0x4A7484AA6EA6E483ll, 0x5CB0A9DCBD41FBD4ll, 0x76F988DA831153B5ll,
+      0x983E5152EE66DFABll, 0xA831C66D2DB43210ll, 0xB00327C898FB213Fll,
+      0xBF597FC7BEEF0EE4ll, 0xC6E00BF33DA88FC2ll, 0xD5A79147930AA725ll,
+      0x06CA6351E003826Fll, 0x142929670A0E6E70ll, 0x27B70A8546D22FFCll,
+      0x2E1B21385C26C926ll, 0x4D2C6DFC5AC42AEDll, 0x53380D139D95B3DFll,
+      0x650A73548BAF63DEll, 0x766A0ABB3C77B2A8ll, 0x81C2C92E47EDAEE6ll,
+      0x92722C851482353Bll, 0xA2BFE8A14CF10364ll, 0xA81A664BBC423001ll,
+      0xC24B8B70D0F89791ll, 0xC76C51A30654BE30ll, 0xD192E819D6EF5218ll,
+      0xD69906245565A910ll, 0xF40E35855771202All, 0x106AA07032BBD1B8ll,
+      0x19A4C116B8D2D0C8ll, 0x1E376C085141AB53ll, 0x2748774CDF8EEB99ll,
+      0x34B0BCB5E19B48A8ll, 0x391C0CB3C5C95A63ll, 0x4ED8AA4AE3418ACBll,
+      0x5B9CCA4F7763E373ll, 0x682E6FF3D6B2B8A3ll, 0x748F82EE5DEFB2FCll,
+      0x78A5636F43172F60ll, 0x84C87814A1F0AB72ll, 0x8CC702081A6439ECll,
+      0x90BEFFFA23631E28ll, 0xA4506CEBDE82BDE9ll, 0xBEF9A3F7B2C67915ll,
+      0xC67178F2E372532Bll, 0xCA273ECEEA26619Cll, 0xD186B8C721C0C207ll,
+      0xEADA7DD6CDE0EB1Ell, 0xF57D4F7FEE6ED178ll, 0x06F067AA72176FBAll,
+      0x0A637DC5A2C898A6ll, 0x113F9804BEF90DAEll, 0x1B710B35131C471Bll,
+      0x28DB77F523047D84ll, 0x32CAAB7B40C72493ll, 0x3C9EBE0A15C9BEBCll,
+      0x431D67C49C100D4Cll, 0x4CC5D4BECB3E42B6ll, 0x597F299CFC657E2All,
+      0x5FCB6FAB3AD6FAECll, 0x6C44198C4A475817ll
+  };
+  int        t, t8;                   /* Loop counter */
+  uint64_t   temp1, temp2;            /* Temporary word value */
+  uint64_t   W[80];                   /* Word sequence */
+  uint64_t   A, B, C, D, E, F, G, H;  /* Word buffers */
+
+  /*
+   * Initialize the first 16 words in the array W
+   */
+  for (t = t8 = 0; t < 16; t++, t8 += 8)
+    W[t] = ((uint64_t)(context->Message_Block[t8  ]) << 56) |
+           ((uint64_t)(context->Message_Block[t8 + 1]) << 48) |
+           ((uint64_t)(context->Message_Block[t8 + 2]) << 40) |
+           ((uint64_t)(context->Message_Block[t8 + 3]) << 32) |
+           ((uint64_t)(context->Message_Block[t8 + 4]) << 24) |
+           ((uint64_t)(context->Message_Block[t8 + 5]) << 16) |
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 63]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+           ((uint64_t)(context->Message_Block[t8 + 6]) << 8) |
+           ((uint64_t)(context->Message_Block[t8 + 7]));
+
+  for (t = 16; t < 80; t++)
+    W[t] = SHA512_sigma1(W[t-2]) + W[t-7] +
+        SHA512_sigma0(W[t-15]) + W[t-16];
+
+  A = context->Intermediate_Hash[0];
+  B = context->Intermediate_Hash[1];
+  C = context->Intermediate_Hash[2];
+  D = context->Intermediate_Hash[3];
+  E = context->Intermediate_Hash[4];
+  F = context->Intermediate_Hash[5];
+  G = context->Intermediate_Hash[6];
+  H = context->Intermediate_Hash[7];
+
+  for (t = 0; t < 80; t++) {
+    temp1 = H + SHA512_SIGMA1(E) + SHA_Ch(E,F,G) + K[t] + W[t];
+    temp2 = SHA512_SIGMA0(A) + SHA_Maj(A,B,C);
+    H = G;
+    G = F;
+    F = E;
+    E = D + temp1;
+    D = C;
+    C = B;
+    B = A;
+    A = temp1 + temp2;
+  }
+
+  context->Intermediate_Hash[0] += A;
+  context->Intermediate_Hash[1] += B;
+  context->Intermediate_Hash[2] += C;
+  context->Intermediate_Hash[3] += D;
+  context->Intermediate_Hash[4] += E;
+  context->Intermediate_Hash[5] += F;
+  context->Intermediate_Hash[6] += G;
+  context->Intermediate_Hash[7] += H;
+#endif /* USE_32BIT_ONLY */
+
+  context->Message_Block_Index = 0;
+}
+
+/*
+ * SHA384_512Reset
+ *
+ * Description:
+ *   This helper function will initialize the SHA512Context in
+ *   preparation for computing a new SHA384 or SHA512 message
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 64]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+ *   digest.
+ *
+ * Parameters:
+ *   context: [in/out]
+ *     The context to reset.
+ *   H0
+ *     The initial hash value to use.
+ *
+ * Returns:
+ *   sha Error Code.
+ *
+ */
+#ifdef USE_32BIT_ONLY
+static int SHA384_512Reset(SHA512Context *context, uint32_t H0[])
+#else /* !USE_32BIT_ONLY */
+static int SHA384_512Reset(SHA512Context *context, uint64_t H0[])
+#endif /* USE_32BIT_ONLY */
+{
+  int i;
+  if (!context)
+    return shaNull;
+
+  context->Message_Block_Index = 0;
+
+#ifdef USE_32BIT_ONLY
+  context->Length[0] = context->Length[1] = 0;
+  context->Length[2] = context->Length[3] = 0;
+
+  for (i = 0; i < SHA512HashSize/4; i++)
+    context->Intermediate_Hash[i] = H0[i];
+#else /* !USE_32BIT_ONLY */
+  context->Length_High = context->Length_Low = 0;
+
+  for (i = 0; i < SHA512HashSize/8; i++)
+    context->Intermediate_Hash[i] = H0[i];
+#endif /* USE_32BIT_ONLY */
+
+  context->Computed = 0;
+  context->Corrupted = 0;
+
+  return shaSuccess;
+}
+
+/*
+ * SHA384_512ResultN
+ *
+ * Description:
+ *   This helper function will return the 384-bit or 512-bit message
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 65]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+ *   digest into the Message_Digest array provided by the caller.
+ *   NOTE: The first octet of hash is stored in the 0th element,
+ *      the last octet of hash in the 48th/64th element.
+ *
+ * Parameters:
+ *   context: [in/out]
+ *     The context to use to calculate the SHA hash.
+ *   Message_Digest: [out]
+ *     Where the digest is returned.
+ *   HashSize: [in]
+ *     The size of the hash, either 48 or 64.
+ *
+ * Returns:
+ *   sha Error Code.
+ *
+ */
+static int SHA384_512ResultN(SHA512Context *context,
+    uint8_t Message_Digest[], int HashSize)
+{
+  int i;
+
+#ifdef USE_32BIT_ONLY
+  int i2;
+#endif /* USE_32BIT_ONLY */
+
+  if (!context || !Message_Digest)
+    return shaNull;
+
+  if (context->Corrupted)
+    return context->Corrupted;
+
+  if (!context->Computed)
+    SHA384_512Finalize(context, 0x80);
+
+#ifdef USE_32BIT_ONLY
+  for (i = i2 = 0; i < HashSize; ) {
+    Message_Digest[i++]=(uint8_t)(context->Intermediate_Hash[i2]>>24);
+    Message_Digest[i++]=(uint8_t)(context->Intermediate_Hash[i2]>>16);
+    Message_Digest[i++]=(uint8_t)(context->Intermediate_Hash[i2]>>8);
+    Message_Digest[i++]=(uint8_t)(context->Intermediate_Hash[i2++]);
+    Message_Digest[i++]=(uint8_t)(context->Intermediate_Hash[i2]>>24);
+    Message_Digest[i++]=(uint8_t)(context->Intermediate_Hash[i2]>>16);
+    Message_Digest[i++]=(uint8_t)(context->Intermediate_Hash[i2]>>8);
+    Message_Digest[i++]=(uint8_t)(context->Intermediate_Hash[i2++]);
+  }
+#else /* !USE_32BIT_ONLY */
+  for (i = 0; i < HashSize; ++i)
+    Message_Digest[i] = (uint8_t)
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 66]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+      (context->Intermediate_Hash[i>>3] >> 8 * ( 7 - ( i % 8 ) ));
+#endif /* USE_32BIT_ONLY */
+
+  return shaSuccess;
+}
+
+8.2.4.  usha.c
+
+/**************************** usha.c ****************************/
+/******************** See RFC 4634 for details ******************/
+/*
+ *  Description:
+ *     This file implements a unified interface to the SHA algorithms.
+ */
+
+#include "sha.h"
+
+/*
+ *  USHAReset
+ *
+ *  Description:
+ *      This function will initialize the SHA Context in preparation
+ *      for computing a new SHA message digest.
+ *
+ *  Parameters:
+ *      context: [in/out]
+ *          The context to reset.
+ *      whichSha: [in]
+ *          Selects which SHA reset to call
+ *
+ *  Returns:
+ *      sha Error Code.
+ *
+ */
+int USHAReset(USHAContext *ctx, enum SHAversion whichSha)
+{
+  if (ctx) {
+    ctx->whichSha = whichSha;
+    switch (whichSha) {
+      case SHA1:   return SHA1Reset((SHA1Context*)&ctx->ctx);
+      case SHA224: return SHA224Reset((SHA224Context*)&ctx->ctx);
+      case SHA256: return SHA256Reset((SHA256Context*)&ctx->ctx);
+      case SHA384: return SHA384Reset((SHA384Context*)&ctx->ctx);
+      case SHA512: return SHA512Reset((SHA512Context*)&ctx->ctx);
+      default: return shaBadParam;
+    }
+  } else {
+    return shaNull;
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 67]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+  }
+}
+
+/*
+ *  USHAInput
+ *
+ *  Description:
+ *      This function accepts an array of octets as the next portion
+ *      of the message.
+ *
+ *  Parameters:
+ *      context: [in/out]
+ *          The SHA context to update
+ *      message_array: [in]
+ *          An array of characters representing the next portion of
+ *          the message.
+ *      length: [in]
+ *          The length of the message in message_array
+ *
+ *  Returns:
+ *      sha Error Code.
+ *
+ */
+int USHAInput(USHAContext *ctx,
+              const uint8_t *bytes, unsigned int bytecount)
+{
+  if (ctx) {
+    switch (ctx->whichSha) {
+      case SHA1:
+        return SHA1Input((SHA1Context*)&ctx->ctx, bytes, bytecount);
+      case SHA224:
+        return SHA224Input((SHA224Context*)&ctx->ctx, bytes,
+            bytecount);
+      case SHA256:
+        return SHA256Input((SHA256Context*)&ctx->ctx, bytes,
+            bytecount);
+      case SHA384:
+        return SHA384Input((SHA384Context*)&ctx->ctx, bytes,
+            bytecount);
+      case SHA512:
+        return SHA512Input((SHA512Context*)&ctx->ctx, bytes,
+            bytecount);
+      default: return shaBadParam;
+    }
+  } else {
+    return shaNull;
+  }
+}
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 68]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+/*
+ * USHAFinalBits
+ *
+ * Description:
+ *   This function will add in any final bits of the message.
+ *
+ * Parameters:
+ *   context: [in/out]
+ *     The SHA context to update
+ *   message_bits: [in]
+ *     The final bits of the message, in the upper portion of the
+ *     byte. (Use 0b###00000 instead of 0b00000### to input the
+ *     three bits ###.)
+ *   length: [in]
+ *     The number of bits in message_bits, between 1 and 7.
+ *
+ * Returns:
+ *   sha Error Code.
+ */
+int USHAFinalBits(USHAContext *ctx,
+                  const uint8_t bits, unsigned int bitcount)
+{
+  if (ctx) {
+    switch (ctx->whichSha) {
+      case SHA1:
+        return SHA1FinalBits((SHA1Context*)&ctx->ctx, bits, bitcount);
+      case SHA224:
+        return SHA224FinalBits((SHA224Context*)&ctx->ctx, bits,
+            bitcount);
+      case SHA256:
+        return SHA256FinalBits((SHA256Context*)&ctx->ctx, bits,
+            bitcount);
+      case SHA384:
+        return SHA384FinalBits((SHA384Context*)&ctx->ctx, bits,
+            bitcount);
+      case SHA512:
+        return SHA512FinalBits((SHA512Context*)&ctx->ctx, bits,
+            bitcount);
+      default: return shaBadParam;
+    }
+  } else {
+    return shaNull;
+  }
+}
+
+/*
+ * USHAResult
+ *
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 69]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+ * Description:
+ *   This function will return the 160-bit message digest into the
+ *   Message_Digest array provided by the caller.
+ *   NOTE: The first octet of hash is stored in the 0th element,
+ *      the last octet of hash in the 19th element.
+ *
+ * Parameters:
+ *   context: [in/out]
+ *     The context to use to calculate the SHA-1 hash.
+ *   Message_Digest: [out]
+ *     Where the digest is returned.
+ *
+ * Returns:
+ *   sha Error Code.
+ *
+ */
+int USHAResult(USHAContext *ctx,
+               uint8_t Message_Digest[USHAMaxHashSize])
+{
+  if (ctx) {
+    switch (ctx->whichSha) {
+      case SHA1:
+        return SHA1Result((SHA1Context*)&ctx->ctx, Message_Digest);
+      case SHA224:
+        return SHA224Result((SHA224Context*)&ctx->ctx, Message_Digest);
+      case SHA256:
+        return SHA256Result((SHA256Context*)&ctx->ctx, Message_Digest);
+      case SHA384:
+        return SHA384Result((SHA384Context*)&ctx->ctx, Message_Digest);
+      case SHA512:
+        return SHA512Result((SHA512Context*)&ctx->ctx, Message_Digest);
+      default: return shaBadParam;
+    }
+  } else {
+    return shaNull;
+  }
+}
+
+/*
+ * USHABlockSize
+ *
+ * Description:
+ *   This function will return the blocksize for the given SHA
+ *   algorithm.
+ *
+ * Parameters:
+ *   whichSha:
+ *     which SHA algorithm to query
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 70]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+ *
+ * Returns:
+ *   block size
+ *
+ */
+int USHABlockSize(enum SHAversion whichSha)
+{
+  switch (whichSha) {
+    case SHA1:   return SHA1_Message_Block_Size;
+    case SHA224: return SHA224_Message_Block_Size;
+    case SHA256: return SHA256_Message_Block_Size;
+    case SHA384: return SHA384_Message_Block_Size;
+    default:
+    case SHA512: return SHA512_Message_Block_Size;
+  }
+}
+
+/*
+ * USHAHashSize
+ *
+ * Description:
+ *   This function will return the hashsize for the given SHA
+ *   algorithm.
+ *
+ * Parameters:
+ *   whichSha:
+ *     which SHA algorithm to query
+ *
+ * Returns:
+ *   hash size
+ *
+ */
+int USHAHashSize(enum SHAversion whichSha)
+{
+  switch (whichSha) {
+    case SHA1:   return SHA1HashSize;
+    case SHA224: return SHA224HashSize;
+    case SHA256: return SHA256HashSize;
+    case SHA384: return SHA384HashSize;
+    default:
+    case SHA512: return SHA512HashSize;
+  }
+}
+
+/*
+ * USHAHashSizeBits
+ *
+ * Description:
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 71]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+ *   This function will return the hashsize for the given SHA
+ *   algorithm, expressed in bits.
+ *
+ * Parameters:
+ *   whichSha:
+ *     which SHA algorithm to query
+ *
+ * Returns:
+ *   hash size in bits
+ *
+ */
+int USHAHashSizeBits(enum SHAversion whichSha)
+{
+  switch (whichSha) {
+    case SHA1:   return SHA1HashSizeBits;
+    case SHA224: return SHA224HashSizeBits;
+    case SHA256: return SHA256HashSizeBits;
+    case SHA384: return SHA384HashSizeBits;
+    default:
+    case SHA512: return SHA512HashSizeBits;
+  }
+}
+
+8.2.5.  sha-private.h
+
+/*************************** sha-private.h ***************************/
+/********************** See RFC 4634 for details *********************/
+#ifndef _SHA_PRIVATE__H
+#define _SHA_PRIVATE__H
+/*
+ * These definitions are defined in FIPS-180-2, section 4.1.
+ * Ch() and Maj() are defined identically in sections 4.1.1,
+ * 4.1.2 and 4.1.3.
+ *
+ * The definitions used in FIPS-180-2 are as follows:
+ */
+
+#ifndef USE_MODIFIED_MACROS
+#define SHA_Ch(x,y,z)        (((x) & (y)) ^ ((~(x)) & (z)))
+#define SHA_Maj(x,y,z)       (((x) & (y)) ^ ((x) & (z)) ^ ((y) & (z)))
+
+#else /* USE_MODIFIED_MACROS */
+/*
+ * The following definitions are equivalent and potentially faster.
+ */
+
+#define SHA_Ch(x, y, z)      (((x) & ((y) ^ (z))) ^ (z))
+#define SHA_Maj(x, y, z)     (((x) & ((y) | (z))) | ((y) & (z)))
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 72]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+#endif /* USE_MODIFIED_MACROS */
+
+#define SHA_Parity(x, y, z)  ((x) ^ (y) ^ (z))
+
+#endif /* _SHA_PRIVATE__H */
+
+8.3 The HMAC Code
+
+/**************************** hmac.c ****************************/
+/******************** See RFC 4634 for details ******************/
+/*
+ *  Description:
+ *      This file implements the HMAC algorithm (Keyed-Hashing for
+ *      Message Authentication, RFC2104), expressed in terms of the
+ *      various SHA algorithms.
+ */
+
+#include "sha.h"
+
+/*
+ *  hmac
+ *
+ *  Description:
+ *      This function will compute an HMAC message digest.
+ *
+ *  Parameters:
+ *      whichSha: [in]
+ *          One of SHA1, SHA224, SHA256, SHA384, SHA512
+ *      key: [in]
+ *          The secret shared key.
+ *      key_len: [in]
+ *          The length of the secret shared key.
+ *      message_array: [in]
+ *          An array of characters representing the message.
+ *      length: [in]
+ *          The length of the message in message_array
+ *      digest: [out]
+ *          Where the digest is returned.
+ *          NOTE: The length of the digest is determined by
+ *              the value of whichSha.
+ *
+ *  Returns:
+ *      sha Error Code.
+ *
+ */
+int hmac(SHAversion whichSha, const unsigned char *text, int text_len,
+    const unsigned char *key, int key_len,
+    uint8_t digest[USHAMaxHashSize])
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 73]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+{
+  HMACContext ctx;
+  return hmacReset(&ctx, whichSha, key, key_len) ||
+         hmacInput(&ctx, text, text_len) ||
+         hmacResult(&ctx, digest);
+}
+
+/*
+ *  hmacReset
+ *
+ *  Description:
+ *      This function will initialize the hmacContext in preparation
+ *      for computing a new HMAC message digest.
+ *
+ *  Parameters:
+ *      context: [in/out]
+ *          The context to reset.
+ *      whichSha: [in]
+ *          One of SHA1, SHA224, SHA256, SHA384, SHA512
+ *      key: [in]
+ *          The secret shared key.
+ *      key_len: [in]
+ *          The length of the secret shared key.
+ *
+ *  Returns:
+ *      sha Error Code.
+ *
+ */
+int hmacReset(HMACContext *ctx, enum SHAversion whichSha,
+    const unsigned char *key, int key_len)
+{
+  int i, blocksize, hashsize;
+
+  /* inner padding - key XORd with ipad */
+  unsigned char k_ipad[USHA_Max_Message_Block_Size];
+
+  /* temporary buffer when keylen > blocksize */
+  unsigned char tempkey[USHAMaxHashSize];
+
+  if (!ctx) return shaNull;
+
+  blocksize = ctx->blockSize = USHABlockSize(whichSha);
+  hashsize = ctx->hashSize = USHAHashSize(whichSha);
+
+  ctx->whichSha = whichSha;
+
+  /*
+   * If key is longer than the hash blocksize,
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 74]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+   * reset it to key = HASH(key).
+   */
+  if (key_len > blocksize) {
+    USHAContext tctx;
+    int err = USHAReset(&tctx, whichSha) ||
+              USHAInput(&tctx, key, key_len) ||
+              USHAResult(&tctx, tempkey);
+    if (err != shaSuccess) return err;
+
+    key = tempkey;
+    key_len = hashsize;
+  }
+
+  /*
+   * The HMAC transform looks like:
+   *
+   * SHA(K XOR opad, SHA(K XOR ipad, text))
+   *
+   * where K is an n byte key.
+   * ipad is the byte 0x36 repeated blocksize times
+   * opad is the byte 0x5c repeated blocksize times
+   * and text is the data being protected.
+   */
+
+  /* store key into the pads, XOR'd with ipad and opad values */
+  for (i = 0; i < key_len; i++) {
+    k_ipad[i] = key[i] ^ 0x36;
+    ctx->k_opad[i] = key[i] ^ 0x5c;
+  }
+  /* remaining pad bytes are '\0' XOR'd with ipad and opad values */
+  for ( ; i < blocksize; i++) {
+    k_ipad[i] = 0x36;
+    ctx->k_opad[i] = 0x5c;
+  }
+
+  /* perform inner hash */
+  /* init context for 1st pass */
+  return USHAReset(&ctx->shaContext, whichSha) ||
+         /* and start with inner pad */
+         USHAInput(&ctx->shaContext, k_ipad, blocksize);
+}
+
+/*
+ *  hmacInput
+ *
+ *  Description:
+ *      This function accepts an array of octets as the next portion
+ *      of the message.
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 75]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+ *
+ *  Parameters:
+ *      context: [in/out]
+ *          The HMAC context to update
+ *      message_array: [in]
+ *          An array of characters representing the next portion of
+ *          the message.
+ *      length: [in]
+ *          The length of the message in message_array
+ *
+ *  Returns:
+ *      sha Error Code.
+ *
+ */
+int hmacInput(HMACContext *ctx, const unsigned char *text,
+    int text_len)
+{
+  if (!ctx) return shaNull;
+  /* then text of datagram */
+  return USHAInput(&ctx->shaContext, text, text_len);
+}
+
+/*
+ * HMACFinalBits
+ *
+ * Description:
+ *   This function will add in any final bits of the message.
+ *
+ * Parameters:
+ *   context: [in/out]
+ *     The HMAC context to update
+ *   message_bits: [in]
+ *     The final bits of the message, in the upper portion of the
+ *     byte. (Use 0b###00000 instead of 0b00000### to input the
+ *     three bits ###.)
+ *   length: [in]
+ *     The number of bits in message_bits, between 1 and 7.
+ *
+ * Returns:
+ *   sha Error Code.
+ */
+int hmacFinalBits(HMACContext *ctx,
+    const uint8_t bits,
+    unsigned int bitcount)
+{
+  if (!ctx) return shaNull;
+  /* then final bits of datagram */
+  return USHAFinalBits(&ctx->shaContext, bits, bitcount);
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 76]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+}
+
+/*
+ * HMACResult
+ *
+ * Description:
+ *   This function will return the N-byte message digest into the
+ *   Message_Digest array provided by the caller.
+ *   NOTE: The first octet of hash is stored in the 0th element,
+ *      the last octet of hash in the Nth element.
+ *
+ * Parameters:
+ *   context: [in/out]
+ *     The context to use to calculate the HMAC hash.
+ *   digest: [out]
+ *     Where the digest is returned.
+ *   NOTE 2: The length of the hash is determined by the value of
+ *      whichSha that was passed to hmacReset().
+ *
+ * Returns:
+ *   sha Error Code.
+ *
+ */
+int hmacResult(HMACContext *ctx, uint8_t *digest)
+{
+  if (!ctx) return shaNull;
+
+  /* finish up 1st pass */
+  /* (Use digest here as a temporary buffer.) */
+  return USHAResult(&ctx->shaContext, digest) ||
+
+         /* perform outer SHA */
+         /* init context for 2nd pass */
+         USHAReset(&ctx->shaContext, ctx->whichSha) ||
+
+         /* start with outer pad */
+         USHAInput(&ctx->shaContext, ctx->k_opad, ctx->blockSize) ||
+
+         /* then results of 1st hash */
+         USHAInput(&ctx->shaContext, digest, ctx->hashSize) ||
+
+         /* finish up 2nd pass */
+         USHAResult(&ctx->shaContext, digest);
+}
+
+
+
+
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 77]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+8.4.  The Test Driver
+
+   The following code is a main program test driver to exercise the code
+   in sha1.c, sha224-256.c, and sha384-512.c.  The test driver can also
+   be used as a stand-alone program for generating the hashes.
+
+   See also [RFC2202], [RFC4231], and [SHAVS].
+
+/**************************** shatest.c ****************************/
+/********************* See RFC 4634 for details ********************/
+/*
+ *  Description:
+ *    This file will exercise the SHA code performing
+ *      the three tests documented in FIPS PUB 180-2
+ *        (http://csrc.nist.gov/publications/fips/
+ *         fips180-2/fips180-2withchangenotice.pdf)
+ *      one that calls SHAInput with an exact multiple of 512 bits
+ *      the seven tests documented for each algorithm in
+ *        "The Secure Hash Algorithm Validation System (SHAVS)",
+ *        three of which are bit-level tests
+ *        (http://csrc.nist.gov/cryptval/shs/SHAVS.pdf)
+ *
+ *    This file will exercise the HMAC SHA1 code performing
+ *      the seven tests documented in RFCs 2202 and 4231.
+ *
+ *    To run the tests and just see PASSED/FAILED, use the -p option.
+ *
+ *    Other options exercise:
+ *      hashing an arbitrary string
+ *      hashing a file's contents
+ *      a few error test checks
+ *      printing the results in raw format
+ *
+ *  Portability Issues:
+ *    None.
+ *
+ */
+
+#include <stdint.h>
+#include <stdio.h>
+#include <stdlib.h>
+#include <string.h>
+#include <ctype.h>
+#include "sha.h"
+
+static int xgetopt(int argc, char **argv, const char *optstring);
+extern char *xoptarg;
+static int scasecmp(const char *s1, const char *s2);
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 78]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+/*
+ *  Define patterns for testing
+ */
+#define TEST1    "abc"
+#define TEST2_1  \
+        "abcdbcdecdefdefgefghfghighijhijkijkljklmklmnlmnomnopnopq"
+#define TEST2_2a \
+        "abcdefghbcdefghicdefghijdefghijkefghijklfghijklmghijklmn"
+#define TEST2_2b \
+        "hijklmnoijklmnopjklmnopqklmnopqrlmnopqrsmnopqrstnopqrstu"
+#define TEST2_2  TEST2_2a TEST2_2b
+#define TEST3    "a"                            /* times 1000000 */
+#define TEST4a   "01234567012345670123456701234567"
+#define TEST4b   "01234567012345670123456701234567"
+    /* an exact multiple of 512 bits */
+#define TEST4   TEST4a TEST4b                   /* times 10 */
+
+#define TEST7_1 \
+  "\x49\xb2\xae\xc2\x59\x4b\xbe\x3a\x3b\x11\x75\x42\xd9\x4a\xc8"
+#define TEST8_1 \
+  "\x9a\x7d\xfd\xf1\xec\xea\xd0\x6e\xd6\x46\xaa\x55\xfe\x75\x71\x46"
+#define TEST9_1 \
+  "\x65\xf9\x32\x99\x5b\xa4\xce\x2c\xb1\xb4\xa2\xe7\x1a\xe7\x02\x20" \
+  "\xaa\xce\xc8\x96\x2d\xd4\x49\x9c\xbd\x7c\x88\x7a\x94\xea\xaa\x10" \
+  "\x1e\xa5\xaa\xbc\x52\x9b\x4e\x7e\x43\x66\x5a\x5a\xf2\xcd\x03\xfe" \
+  "\x67\x8e\xa6\xa5\x00\x5b\xba\x3b\x08\x22\x04\xc2\x8b\x91\x09\xf4" \
+  "\x69\xda\xc9\x2a\xaa\xb3\xaa\x7c\x11\xa1\xb3\x2a"
+#define TEST10_1 \
+  "\xf7\x8f\x92\x14\x1b\xcd\x17\x0a\xe8\x9b\x4f\xba\x15\xa1\xd5\x9f" \
+  "\x3f\xd8\x4d\x22\x3c\x92\x51\xbd\xac\xbb\xae\x61\xd0\x5e\xd1\x15" \
+  "\xa0\x6a\x7c\xe1\x17\xb7\xbe\xea\xd2\x44\x21\xde\xd9\xc3\x25\x92" \
+  "\xbd\x57\xed\xea\xe3\x9c\x39\xfa\x1f\xe8\x94\x6a\x84\xd0\xcf\x1f" \
+  "\x7b\xee\xad\x17\x13\xe2\xe0\x95\x98\x97\x34\x7f\x67\xc8\x0b\x04" \
+  "\x00\xc2\x09\x81\x5d\x6b\x10\xa6\x83\x83\x6f\xd5\x56\x2a\x56\xca" \
+  "\xb1\xa2\x8e\x81\xb6\x57\x66\x54\x63\x1c\xf1\x65\x66\xb8\x6e\x3b" \
+  "\x33\xa1\x08\xb0\x53\x07\xc0\x0a\xff\x14\xa7\x68\xed\x73\x50\x60" \
+  "\x6a\x0f\x85\xe6\xa9\x1d\x39\x6f\x5b\x5c\xbe\x57\x7f\x9b\x38\x80" \
+  "\x7c\x7d\x52\x3d\x6d\x79\x2f\x6e\xbc\x24\xa4\xec\xf2\xb3\xa4\x27" \
+  "\xcd\xbb\xfb"
+#define TEST7_224 \
+  "\xf0\x70\x06\xf2\x5a\x0b\xea\x68\xcd\x76\xa2\x95\x87\xc2\x8d"
+#define TEST8_224 \
+  "\x18\x80\x40\x05\xdd\x4f\xbd\x15\x56\x29\x9d\x6f\x9d\x93\xdf\x62"
+#define TEST9_224 \
+  "\xa2\xbe\x6e\x46\x32\x81\x09\x02\x94\xd9\xce\x94\x82\x65\x69\x42" \
+  "\x3a\x3a\x30\x5e\xd5\xe2\x11\x6c\xd4\xa4\xc9\x87\xfc\x06\x57\x00" \
+  "\x64\x91\xb1\x49\xcc\xd4\xb5\x11\x30\xac\x62\xb1\x9d\xc2\x48\xc7" \
+  "\x44\x54\x3d\x20\xcd\x39\x52\xdc\xed\x1f\x06\xcc\x3b\x18\xb9\x1f" \
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 79]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+  "\x3f\x55\x63\x3e\xcc\x30\x85\xf4\x90\x70\x60\xd2"
+#define TEST10_224 \
+  "\x55\xb2\x10\x07\x9c\x61\xb5\x3a\xdd\x52\x06\x22\xd1\xac\x97\xd5" \
+  "\xcd\xbe\x8c\xb3\x3a\xa0\xae\x34\x45\x17\xbe\xe4\xd7\xba\x09\xab" \
+  "\xc8\x53\x3c\x52\x50\x88\x7a\x43\xbe\xbb\xac\x90\x6c\x2e\x18\x37" \
+  "\xf2\x6b\x36\xa5\x9a\xe3\xbe\x78\x14\xd5\x06\x89\x6b\x71\x8b\x2a" \
+  "\x38\x3e\xcd\xac\x16\xb9\x61\x25\x55\x3f\x41\x6f\xf3\x2c\x66\x74" \
+  "\xc7\x45\x99\xa9\x00\x53\x86\xd9\xce\x11\x12\x24\x5f\x48\xee\x47" \
+  "\x0d\x39\x6c\x1e\xd6\x3b\x92\x67\x0c\xa5\x6e\xc8\x4d\xee\xa8\x14" \
+  "\xb6\x13\x5e\xca\x54\x39\x2b\xde\xdb\x94\x89\xbc\x9b\x87\x5a\x8b" \
+  "\xaf\x0d\xc1\xae\x78\x57\x36\x91\x4a\xb7\xda\xa2\x64\xbc\x07\x9d" \
+  "\x26\x9f\x2c\x0d\x7e\xdd\xd8\x10\xa4\x26\x14\x5a\x07\x76\xf6\x7c" \
+  "\x87\x82\x73"
+#define TEST7_256 \
+  "\xbe\x27\x46\xc6\xdb\x52\x76\x5f\xdb\x2f\x88\x70\x0f\x9a\x73"
+#define TEST8_256 \
+  "\xe3\xd7\x25\x70\xdc\xdd\x78\x7c\xe3\x88\x7a\xb2\xcd\x68\x46\x52"
+#define TEST9_256 \
+  "\x3e\x74\x03\x71\xc8\x10\xc2\xb9\x9f\xc0\x4e\x80\x49\x07\xef\x7c" \
+  "\xf2\x6b\xe2\x8b\x57\xcb\x58\xa3\xe2\xf3\xc0\x07\x16\x6e\x49\xc1" \
+  "\x2e\x9b\xa3\x4c\x01\x04\x06\x91\x29\xea\x76\x15\x64\x25\x45\x70" \
+  "\x3a\x2b\xd9\x01\xe1\x6e\xb0\xe0\x5d\xeb\xa0\x14\xeb\xff\x64\x06" \
+  "\xa0\x7d\x54\x36\x4e\xff\x74\x2d\xa7\x79\xb0\xb3"
+#define TEST10_256 \
+  "\x83\x26\x75\x4e\x22\x77\x37\x2f\x4f\xc1\x2b\x20\x52\x7a\xfe\xf0" \
+  "\x4d\x8a\x05\x69\x71\xb1\x1a\xd5\x71\x23\xa7\xc1\x37\x76\x00\x00" \
+  "\xd7\xbe\xf6\xf3\xc1\xf7\xa9\x08\x3a\xa3\x9d\x81\x0d\xb3\x10\x77" \
+  "\x7d\xab\x8b\x1e\x7f\x02\xb8\x4a\x26\xc7\x73\x32\x5f\x8b\x23\x74" \
+  "\xde\x7a\x4b\x5a\x58\xcb\x5c\x5c\xf3\x5b\xce\xe6\xfb\x94\x6e\x5b" \
+  "\xd6\x94\xfa\x59\x3a\x8b\xeb\x3f\x9d\x65\x92\xec\xed\xaa\x66\xca" \
+  "\x82\xa2\x9d\x0c\x51\xbc\xf9\x33\x62\x30\xe5\xd7\x84\xe4\xc0\xa4" \
+  "\x3f\x8d\x79\xa3\x0a\x16\x5c\xba\xbe\x45\x2b\x77\x4b\x9c\x71\x09" \
+  "\xa9\x7d\x13\x8f\x12\x92\x28\x96\x6f\x6c\x0a\xdc\x10\x6a\xad\x5a" \
+  "\x9f\xdd\x30\x82\x57\x69\xb2\xc6\x71\xaf\x67\x59\xdf\x28\xeb\x39" \
+  "\x3d\x54\xd6"
+#define TEST7_384 \
+  "\x8b\xc5\x00\xc7\x7c\xee\xd9\x87\x9d\xa9\x89\x10\x7c\xe0\xaa"
+#define TEST8_384 \
+  "\xa4\x1c\x49\x77\x79\xc0\x37\x5f\xf1\x0a\x7f\x4e\x08\x59\x17\x39"
+#define TEST9_384 \
+  "\x68\xf5\x01\x79\x2d\xea\x97\x96\x76\x70\x22\xd9\x3d\xa7\x16\x79" \
+  "\x30\x99\x20\xfa\x10\x12\xae\xa3\x57\xb2\xb1\x33\x1d\x40\xa1\xd0" \
+  "\x3c\x41\xc2\x40\xb3\xc9\xa7\x5b\x48\x92\xf4\xc0\x72\x4b\x68\xc8" \
+  "\x75\x32\x1a\xb8\xcf\xe5\x02\x3b\xd3\x75\xbc\x0f\x94\xbd\x89\xfe" \
+  "\x04\xf2\x97\x10\x5d\x7b\x82\xff\xc0\x02\x1a\xeb\x1c\xcb\x67\x4f" \
+  "\x52\x44\xea\x34\x97\xde\x26\xa4\x19\x1c\x5f\x62\xe5\xe9\xa2\xd8" \
+  "\x08\x2f\x05\x51\xf4\xa5\x30\x68\x26\xe9\x1c\xc0\x06\xce\x1b\xf6" \
+  "\x0f\xf7\x19\xd4\x2f\xa5\x21\xc8\x71\xcd\x23\x94\xd9\x6e\xf4\x46" \
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 80]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+  "\x8f\x21\x96\x6b\x41\xf2\xba\x80\xc2\x6e\x83\xa9"
+#define TEST10_384 \
+  "\x39\x96\x69\xe2\x8f\x6b\x9c\x6d\xbc\xbb\x69\x12\xec\x10\xff\xcf" \
+  "\x74\x79\x03\x49\xb7\xdc\x8f\xbe\x4a\x8e\x7b\x3b\x56\x21\xdb\x0f" \
+  "\x3e\x7d\xc8\x7f\x82\x32\x64\xbb\xe4\x0d\x18\x11\xc9\xea\x20\x61" \
+  "\xe1\xc8\x4a\xd1\x0a\x23\xfa\xc1\x72\x7e\x72\x02\xfc\x3f\x50\x42" \
+  "\xe6\xbf\x58\xcb\xa8\xa2\x74\x6e\x1f\x64\xf9\xb9\xea\x35\x2c\x71" \
+  "\x15\x07\x05\x3c\xf4\xe5\x33\x9d\x52\x86\x5f\x25\xcc\x22\xb5\xe8" \
+  "\x77\x84\xa1\x2f\xc9\x61\xd6\x6c\xb6\xe8\x95\x73\x19\x9a\x2c\xe6" \
+  "\x56\x5c\xbd\xf1\x3d\xca\x40\x38\x32\xcf\xcb\x0e\x8b\x72\x11\xe8" \
+  "\x3a\xf3\x2a\x11\xac\x17\x92\x9f\xf1\xc0\x73\xa5\x1c\xc0\x27\xaa" \
+  "\xed\xef\xf8\x5a\xad\x7c\x2b\x7c\x5a\x80\x3e\x24\x04\xd9\x6d\x2a" \
+  "\x77\x35\x7b\xda\x1a\x6d\xae\xed\x17\x15\x1c\xb9\xbc\x51\x25\xa4" \
+  "\x22\xe9\x41\xde\x0c\xa0\xfc\x50\x11\xc2\x3e\xcf\xfe\xfd\xd0\x96" \
+  "\x76\x71\x1c\xf3\xdb\x0a\x34\x40\x72\x0e\x16\x15\xc1\xf2\x2f\xbc" \
+  "\x3c\x72\x1d\xe5\x21\xe1\xb9\x9b\xa1\xbd\x55\x77\x40\x86\x42\x14" \
+  "\x7e\xd0\x96"
+#define TEST7_512 \
+  "\x08\xec\xb5\x2e\xba\xe1\xf7\x42\x2d\xb6\x2b\xcd\x54\x26\x70"
+#define TEST8_512 \
+  "\x8d\x4e\x3c\x0e\x38\x89\x19\x14\x91\x81\x6e\x9d\x98\xbf\xf0\xa0"
+#define TEST9_512 \
+  "\x3a\xdd\xec\x85\x59\x32\x16\xd1\x61\x9a\xa0\x2d\x97\x56\x97\x0b" \
+  "\xfc\x70\xac\xe2\x74\x4f\x7c\x6b\x27\x88\x15\x10\x28\xf7\xb6\xa2" \
+  "\x55\x0f\xd7\x4a\x7e\x6e\x69\xc2\xc9\xb4\x5f\xc4\x54\x96\x6d\xc3" \
+  "\x1d\x2e\x10\xda\x1f\x95\xce\x02\xbe\xb4\xbf\x87\x65\x57\x4c\xbd" \
+  "\x6e\x83\x37\xef\x42\x0a\xdc\x98\xc1\x5c\xb6\xd5\xe4\xa0\x24\x1b" \
+  "\xa0\x04\x6d\x25\x0e\x51\x02\x31\xca\xc2\x04\x6c\x99\x16\x06\xab" \
+  "\x4e\xe4\x14\x5b\xee\x2f\xf4\xbb\x12\x3a\xab\x49\x8d\x9d\x44\x79" \
+  "\x4f\x99\xcc\xad\x89\xa9\xa1\x62\x12\x59\xed\xa7\x0a\x5b\x6d\xd4" \
+  "\xbd\xd8\x77\x78\xc9\x04\x3b\x93\x84\xf5\x49\x06"
+#define TEST10_512 \
+  "\xa5\x5f\x20\xc4\x11\xaa\xd1\x32\x80\x7a\x50\x2d\x65\x82\x4e\x31" \
+  "\xa2\x30\x54\x32\xaa\x3d\x06\xd3\xe2\x82\xa8\xd8\x4e\x0d\xe1\xde" \
+  "\x69\x74\xbf\x49\x54\x69\xfc\x7f\x33\x8f\x80\x54\xd5\x8c\x26\xc4" \
+  "\x93\x60\xc3\xe8\x7a\xf5\x65\x23\xac\xf6\xd8\x9d\x03\xe5\x6f\xf2" \
+  "\xf8\x68\x00\x2b\xc3\xe4\x31\xed\xc4\x4d\xf2\xf0\x22\x3d\x4b\xb3" \
+  "\xb2\x43\x58\x6e\x1a\x7d\x92\x49\x36\x69\x4f\xcb\xba\xf8\x8d\x95" \
+  "\x19\xe4\xeb\x50\xa6\x44\xf8\xe4\xf9\x5e\xb0\xea\x95\xbc\x44\x65" \
+  "\xc8\x82\x1a\xac\xd2\xfe\x15\xab\x49\x81\x16\x4b\xbb\x6d\xc3\x2f" \
+  "\x96\x90\x87\xa1\x45\xb0\xd9\xcc\x9c\x67\xc2\x2b\x76\x32\x99\x41" \
+  "\x9c\xc4\x12\x8b\xe9\xa0\x77\xb3\xac\xe6\x34\x06\x4e\x6d\x99\x28" \
+  "\x35\x13\xdc\x06\xe7\x51\x5d\x0d\x73\x13\x2e\x9a\x0d\xc6\xd3\xb1" \
+  "\xf8\xb2\x46\xf1\xa9\x8a\x3f\xc7\x29\x41\xb1\xe3\xbb\x20\x98\xe8" \
+  "\xbf\x16\xf2\x68\xd6\x4f\x0b\x0f\x47\x07\xfe\x1e\xa1\xa1\x79\x1b" \
+  "\xa2\xf3\xc0\xc7\x58\xe5\xf5\x51\x86\x3a\x96\xc9\x49\xad\x47\xd7" \
+  "\xfb\x40\xd2"
+#define SHA1_SEED "\xd0\x56\x9c\xb3\x66\x5a\x8a\x43\xeb\x6e\xa2\x3d" \
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 81]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+  "\x75\xa3\xc4\xd2\x05\x4a\x0d\x7d"
+#define SHA224_SEED "\xd0\x56\x9c\xb3\x66\x5a\x8a\x43\xeb\x6e\xa2" \
+  "\x3d\x75\xa3\xc4\xd2\x05\x4a\x0d\x7d\x66\xa9\xca\x99\xc9\xce\xb0" \
+  "\x27"
+#define SHA256_SEED "\xf4\x1e\xce\x26\x13\xe4\x57\x39\x15\x69\x6b" \
+  "\x5a\xdc\xd5\x1c\xa3\x28\xbe\x3b\xf5\x66\xa9\xca\x99\xc9\xce\xb0" \
+  "\x27\x9c\x1c\xb0\xa7"
+#define SHA384_SEED "\x82\x40\xbc\x51\xe4\xec\x7e\xf7\x6d\x18\xe3" \
+  "\x52\x04\xa1\x9f\x51\xa5\x21\x3a\x73\xa8\x1d\x6f\x94\x46\x80\xd3" \
+  "\x07\x59\x48\xb7\xe4\x63\x80\x4e\xa3\xd2\x6e\x13\xea\x82\x0d\x65" \
+  "\xa4\x84\xbe\x74\x53"
+#define SHA512_SEED "\x47\x3f\xf1\xb9\xb3\xff\xdf\xa1\x26\x69\x9a" \
+  "\xc7\xef\x9e\x8e\x78\x77\x73\x09\x58\x24\xc6\x42\x55\x7c\x13\x99" \
+  "\xd9\x8e\x42\x20\x44\x8d\xc3\x5b\x99\xbf\xdd\x44\x77\x95\x43\x92" \
+  "\x4c\x1c\xe9\x3b\xc5\x94\x15\x38\x89\x5d\xb9\x88\x26\x1b\x00\x77" \
+  "\x4b\x12\x27\x20\x39"
+
+#define TESTCOUNT 10
+#define HASHCOUNT 5
+#define RANDOMCOUNT 4
+#define HMACTESTCOUNT 7
+
+#define PRINTNONE 0
+#define PRINTTEXT 1
+#define PRINTRAW 2
+#define PRINTHEX 3
+#define PRINTBASE64 4
+
+#define PRINTPASSFAIL 1
+#define PRINTFAIL 2
+
+#define length(x) (sizeof(x)-1)
+
+/* Test arrays for hashes. */
+struct hash {
+    const char *name;
+    SHAversion whichSha;
+    int hashsize;
+    struct {
+        const char *testarray;
+        int length;
+        long repeatcount;
+        int extrabits;
+        int numberExtrabits;
+        const char *resultarray;
+    } tests[TESTCOUNT];
+    const char *randomtest;
+    const char *randomresults[RANDOMCOUNT];
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 82]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+} hashes[HASHCOUNT] = {
+  { "SHA1", SHA1, SHA1HashSize,
+    {
+      /* 1 */ { TEST1, length(TEST1), 1, 0, 0,
+        "A9993E364706816ABA3E25717850C26C9CD0D89D" },
+      /* 2 */ { TEST2_1, length(TEST2_1), 1, 0, 0,
+        "84983E441C3BD26EBAAE4AA1F95129E5E54670F1" },
+      /* 3 */ { TEST3, length(TEST3), 1000000, 0, 0,
+        "34AA973CD4C4DAA4F61EEB2BDBAD27316534016F" },
+      /* 4 */ { TEST4, length(TEST4), 10, 0, 0,
+        "DEA356A2CDDD90C7A7ECEDC5EBB563934F460452" },
+      /* 5 */ { "", 0, 0, 0x98, 5,
+        "29826B003B906E660EFF4027CE98AF3531AC75BA" },
+      /* 6 */ { "\x5e", 1, 1, 0, 0,
+        "5E6F80A34A9798CAFC6A5DB96CC57BA4C4DB59C2" },
+      /* 7 */ { TEST7_1, length(TEST7_1), 1, 0x80, 3,
+        "6239781E03729919C01955B3FFA8ACB60B988340" },
+      /* 8 */ { TEST8_1, length(TEST8_1), 1, 0, 0,
+        "82ABFF6605DBE1C17DEF12A394FA22A82B544A35" },
+      /* 9 */ { TEST9_1, length(TEST9_1), 1, 0xE0, 3,
+        "8C5B2A5DDAE5A97FC7F9D85661C672ADBF7933D4" },
+      /* 10 */ { TEST10_1, length(TEST10_1), 1, 0, 0,
+        "CB0082C8F197D260991BA6A460E76E202BAD27B3" }
+    }, SHA1_SEED, { "E216836819477C7F78E0D843FE4FF1B6D6C14CD4",
+        "A2DBC7A5B1C6C0A8BCB7AAA41252A6A7D0690DBC",
+        "DB1F9050BB863DFEF4CE37186044E2EEB17EE013",
+        "127FDEDF43D372A51D5747C48FBFFE38EF6CDF7B"
+     } },
+  { "SHA224", SHA224, SHA224HashSize,
+    {
+      /* 1 */ { TEST1, length(TEST1), 1, 0, 0,
+        "23097D223405D8228642A477BDA255B32AADBCE4BDA0B3F7E36C9DA7" },
+      /* 2 */ { TEST2_1, length(TEST2_1), 1, 0, 0,
+        "75388B16512776CC5DBA5DA1FD890150B0C6455CB4F58B1952522525" },
+      /* 3 */ { TEST3, length(TEST3), 1000000, 0, 0,
+        "20794655980C91D8BBB4C1EA97618A4BF03F42581948B2EE4EE7AD67" },
+      /* 4 */ { TEST4, length(TEST4), 10, 0, 0,
+        "567F69F168CD7844E65259CE658FE7AADFA25216E68ECA0EB7AB8262" },
+      /* 5 */ { "", 0, 0, 0x68, 5,
+        "E3B048552C3C387BCAB37F6EB06BB79B96A4AEE5FF27F51531A9551C" },
+      /* 6 */ { "\x07", 1, 1, 0, 0,
+        "00ECD5F138422B8AD74C9799FD826C531BAD2FCABC7450BEE2AA8C2A" },
+      /* 7 */ { TEST7_224, length(TEST7_224), 1, 0xA0, 3,
+        "1B01DB6CB4A9E43DED1516BEB3DB0B87B6D1EA43187462C608137150" },
+      /* 8 */ { TEST8_224, length(TEST8_224), 1, 0, 0,
+        "DF90D78AA78821C99B40BA4C966921ACCD8FFB1E98AC388E56191DB1" },
+      /* 9 */ { TEST9_224, length(TEST9_224), 1, 0xE0, 3,
+        "54BEA6EAB8195A2EB0A7906A4B4A876666300EEFBD1F3B8474F9CD57" },
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 83]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+      /* 10 */ { TEST10_224, length(TEST10_224), 1, 0, 0,
+        "0B31894EC8937AD9B91BDFBCBA294D9ADEFAA18E09305E9F20D5C3A4" }
+    }, SHA224_SEED, { "100966A5B4FDE0B42E2A6C5953D4D7F41BA7CF79FD"
+        "2DF431416734BE", "1DCA396B0C417715DEFAAE9641E10A2E99D55A"
+        "BCB8A00061EB3BE8BD", "1864E627BDB2319973CD5ED7D68DA71D8B"
+        "F0F983D8D9AB32C34ADB34", "A2406481FC1BCAF24DD08E6752E844"
+        "709563FB916227FED598EB621F"
+     } },
+  { "SHA256", SHA256, SHA256HashSize,
+  {
+      /* 1 */ { TEST1, length(TEST1), 1, 0, 0, "BA7816BF8F01CFEA4141"
+        "40DE5DAE2223B00361A396177A9CB410FF61F20015AD" },
+      /* 2 */ { TEST2_1, length(TEST2_1), 1, 0, 0, "248D6A61D20638B8"
+        "E5C026930C3E6039A33CE45964FF2167F6ECEDD419DB06C1" },
+      /* 3 */ { TEST3, length(TEST3), 1000000, 0, 0, "CDC76E5C9914FB92"
+        "81A1C7E284D73E67F1809A48A497200E046D39CCC7112CD0" },
+      /* 4 */ { TEST4, length(TEST4), 10, 0, 0, "594847328451BDFA"
+        "85056225462CC1D867D877FB388DF0CE35F25AB5562BFBB5" },
+      /* 5 */ { "", 0, 0, 0x68, 5, "D6D3E02A31A84A8CAA9718ED6C2057BE"
+        "09DB45E7823EB5079CE7A573A3760F95" },
+      /* 6 */ { "\x19", 1, 1, 0, 0, "68AA2E2EE5DFF96E3355E6C7EE373E3D"
+        "6A4E17F75F9518D843709C0C9BC3E3D4" },
+      /* 7 */ { TEST7_256, length(TEST7_256), 1, 0x60, 3, "77EC1DC8"
+        "9C821FF2A1279089FA091B35B8CD960BCAF7DE01C6A7680756BEB972" },
+      /* 8 */ { TEST8_256, length(TEST8_256), 1, 0, 0, "175EE69B02BA"
+        "9B58E2B0A5FD13819CEA573F3940A94F825128CF4209BEABB4E8" },
+      /* 9 */ { TEST9_256, length(TEST9_256), 1, 0xA0, 3, "3E9AD646"
+        "8BBBAD2AC3C2CDC292E018BA5FD70B960CF1679777FCE708FDB066E9" },
+      /* 10 */ { TEST10_256, length(TEST10_256), 1, 0, 0, "97DBCA7D"
+        "F46D62C8A422C941DD7E835B8AD3361763F7E9B2D95F4F0DA6E1CCBC" },
+    }, SHA256_SEED, { "83D28614D49C3ADC1D6FC05DB5F48037C056F8D2A4CE44"
+        "EC6457DEA5DD797CD1", "99DBE3127EF2E93DD9322D6A07909EB33B6399"
+        "5E529B3F954B8581621BB74D39", "8D4BE295BB64661CA3C7EFD129A2F7"
+        "25B33072DBDDE32385B9A87B9AF88EA76F", "40AF5D3F9716B040DF9408"
+        "E31536B70FF906EC51B00447CA97D7DD97C12411F4"
+    } },
+  { "SHA384", SHA384, SHA384HashSize,
+    {
+      /* 1 */ { TEST1, length(TEST1), 1, 0, 0,
+        "CB00753F45A35E8BB5A03D699AC65007272C32AB0EDED163"
+        "1A8B605A43FF5BED8086072BA1E7CC2358BAECA134C825A7" },
+      /* 2 */ { TEST2_2, length(TEST2_2), 1, 0, 0,
+        "09330C33F71147E83D192FC782CD1B4753111B173B3B05D2"
+        "2FA08086E3B0F712FCC7C71A557E2DB966C3E9FA91746039" },
+      /* 3 */ { TEST3, length(TEST3), 1000000, 0, 0,
+        "9D0E1809716474CB086E834E310A4A1CED149E9C00F24852"
+        "7972CEC5704C2A5B07B8B3DC38ECC4EBAE97DDD87F3D8985" },
+      /* 4 */ { TEST4, length(TEST4), 10, 0, 0,
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 84]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+        "2FC64A4F500DDB6828F6A3430B8DD72A368EB7F3A8322A70"
+        "BC84275B9C0B3AB00D27A5CC3C2D224AA6B61A0D79FB4596" },
+      /* 5 */ { "", 0, 0, 0x10, 5,
+        "8D17BE79E32B6718E07D8A603EB84BA0478F7FCFD1BB9399"
+        "5F7D1149E09143AC1FFCFC56820E469F3878D957A15A3FE4" },
+      /* 6 */ { "\xb9", 1, 1, 0, 0,
+        "BC8089A19007C0B14195F4ECC74094FEC64F01F90929282C"
+        "2FB392881578208AD466828B1C6C283D2722CF0AD1AB6938" },
+      /* 7 */ { TEST7_384, length(TEST7_384), 1, 0xA0, 3,
+        "D8C43B38E12E7C42A7C9B810299FD6A770BEF30920F17532"
+        "A898DE62C7A07E4293449C0B5FA70109F0783211CFC4BCE3" },
+      /* 8 */ { TEST8_384, length(TEST8_384), 1, 0, 0,
+        "C9A68443A005812256B8EC76B00516F0DBB74FAB26D66591"
+        "3F194B6FFB0E91EA9967566B58109CBC675CC208E4C823F7" },
+      /* 9 */ { TEST9_384, length(TEST9_384), 1, 0xE0, 3,
+        "5860E8DE91C21578BB4174D227898A98E0B45C4C760F0095"
+        "49495614DAEDC0775D92D11D9F8CE9B064EEAC8DAFC3A297" },
+      /* 10 */ { TEST10_384, length(TEST10_384), 1, 0, 0,
+        "4F440DB1E6EDD2899FA335F09515AA025EE177A79F4B4AAF"
+        "38E42B5C4DE660F5DE8FB2A5B2FBD2A3CBFFD20CFF1288C0" }
+    }, SHA384_SEED, { "CE44D7D63AE0C91482998CF662A51EC80BF6FC68661A3C"
+        "57F87566112BD635A743EA904DEB7D7A42AC808CABE697F38F", "F9C6D2"
+        "61881FEE41ACD39E67AA8D0BAD507C7363EB67E2B81F45759F9C0FD7B503"
+        "DF1A0B9E80BDE7BC333D75B804197D", "D96512D8C9F4A7A4967A366C01"
+        "C6FD97384225B58343A88264847C18E4EF8AB7AEE4765FFBC3E30BD485D3"
+        "638A01418F", "0CA76BD0813AF1509E170907A96005938BC985628290B2"
+        "5FEF73CF6FAD68DDBA0AC8920C94E0541607B0915A7B4457F7"
+    } },
+  { "SHA512", SHA512, SHA512HashSize,
+    {
+      /* 1 */ { TEST1, length(TEST1), 1, 0, 0,
+        "DDAF35A193617ABACC417349AE20413112E6FA4E89A97EA2"
+        "0A9EEEE64B55D39A2192992A274FC1A836BA3C23A3FEEBBD"
+        "454D4423643CE80E2A9AC94FA54CA49F" },
+      /* 2 */ { TEST2_2, length(TEST2_2), 1, 0, 0,
+        "8E959B75DAE313DA8CF4F72814FC143F8F7779C6EB9F7FA1"
+        "7299AEADB6889018501D289E4900F7E4331B99DEC4B5433A"
+        "C7D329EEB6DD26545E96E55B874BE909" },
+       /* 3 */ { TEST3, length(TEST3), 1000000, 0, 0,
+        "E718483D0CE769644E2E42C7BC15B4638E1F98B13B204428"
+        "5632A803AFA973EBDE0FF244877EA60A4CB0432CE577C31B"
+        "EB009C5C2C49AA2E4EADB217AD8CC09B" },
+      /* 4 */ { TEST4, length(TEST4), 10, 0, 0,
+        "89D05BA632C699C31231DED4FFC127D5A894DAD412C0E024"
+        "DB872D1ABD2BA8141A0F85072A9BE1E2AA04CF33C765CB51"
+        "0813A39CD5A84C4ACAA64D3F3FB7BAE9" },
+      /* 5 */ { "", 0, 0, 0xB0, 5,
+        "D4EE29A9E90985446B913CF1D1376C836F4BE2C1CF3CADA0"
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 85]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+        "720A6BF4857D886A7ECB3C4E4C0FA8C7F95214E41DC1B0D2"
+        "1B22A84CC03BF8CE4845F34DD5BDBAD4" },
+      /* 6 */ { "\xD0", 1, 1, 0, 0,
+        "9992202938E882E73E20F6B69E68A0A7149090423D93C81B"
+        "AB3F21678D4ACEEEE50E4E8CAFADA4C85A54EA8306826C4A"
+        "D6E74CECE9631BFA8A549B4AB3FBBA15" },
+      /* 7 */ { TEST7_512, length(TEST7_512), 1, 0x80, 3,
+        "ED8DC78E8B01B69750053DBB7A0A9EDA0FB9E9D292B1ED71"
+        "5E80A7FE290A4E16664FD913E85854400C5AF05E6DAD316B"
+        "7359B43E64F8BEC3C1F237119986BBB6" },
+      /* 8 */ { TEST8_512, length(TEST8_512), 1, 0, 0,
+        "CB0B67A4B8712CD73C9AABC0B199E9269B20844AFB75ACBD"
+        "D1C153C9828924C3DDEDAAFE669C5FDD0BC66F630F677398"
+        "8213EB1B16F517AD0DE4B2F0C95C90F8" },
+      /* 9 */ { TEST9_512, length(TEST9_512), 1, 0x80, 3,
+        "32BA76FC30EAA0208AEB50FFB5AF1864FDBF17902A4DC0A6"
+        "82C61FCEA6D92B783267B21080301837F59DE79C6B337DB2"
+        "526F8A0A510E5E53CAFED4355FE7C2F1" },
+      /* 10 */ { TEST10_512, length(TEST10_512), 1, 0, 0,
+        "C665BEFB36DA189D78822D10528CBF3B12B3EEF726039909"
+        "C1A16A270D48719377966B957A878E720584779A62825C18"
+        "DA26415E49A7176A894E7510FD1451F5" }
+    }, SHA512_SEED, { "2FBB1E7E00F746BA514FBC8C421F36792EC0E11FF5EFC3"
+        "78E1AB0C079AA5F0F66A1E3EDBAEB4F9984BE14437123038A452004A5576"
+        "8C1FD8EED49E4A21BEDCD0", "25CBE5A4F2C7B1D7EF07011705D50C62C5"
+        "000594243EAFD1241FC9F3D22B58184AE2FEE38E171CF8129E29459C9BC2"
+        "EF461AF5708887315F15419D8D17FE7949", "5B8B1F2687555CE2D7182B"
+        "92E5C3F6C36547DA1C13DBB9EA4F73EA4CBBAF89411527906D35B1B06C1B"
+        "6A8007D05EC66DF0A406066829EAB618BDE3976515AAFC", "46E36B007D"
+        "19876CDB0B29AD074FE3C08CDD174D42169D6ABE5A1414B6E79707DF5877"
+        "6A98091CF431854147BB6D3C66D43BFBC108FD715BDE6AA127C2B0E79F"
+    }
+  }
+};
+
+/* Test arrays for HMAC. */
+struct hmachash {
+    const char *keyarray[5];
+    int keylength[5];
+    const char *dataarray[5];
+    int datalength[5];
+    const char *resultarray[5];
+    int resultlength[5];
+} hmachashes[HMACTESTCOUNT] = {
+  { /* 1 */ {
+      "\x0b\x0b\x0b\x0b\x0b\x0b\x0b\x0b\x0b\x0b\x0b\x0b\x0b\x0b\x0b"
+      "\x0b\x0b\x0b\x0b\x0b"
+    }, { 20 }, {
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 86]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+      "\x48\x69\x20\x54\x68\x65\x72\x65" /* "Hi There" */
+    }, { 8 }, {
+      /* HMAC-SHA-1 */
+      "B617318655057264E28BC0B6FB378C8EF146BE00",
+      /* HMAC-SHA-224 */
+      "896FB1128ABBDF196832107CD49DF33F47B4B1169912BA4F53684B22",
+      /* HMAC-SHA-256 */
+      "B0344C61D8DB38535CA8AFCEAF0BF12B881DC200C9833DA726E9376C2E32"
+      "CFF7",
+      /* HMAC-SHA-384 */
+      "AFD03944D84895626B0825F4AB46907F15F9DADBE4101EC682AA034C7CEB"
+      "C59CFAEA9EA9076EDE7F4AF152E8B2FA9CB6",
+      /* HMAC-SHA-512 */
+      "87AA7CDEA5EF619D4FF0B4241A1D6CB02379F4E2CE4EC2787AD0B30545E1"
+      "7CDEDAA833B7D6B8A702038B274EAEA3F4E4BE9D914EEB61F1702E696C20"
+      "3A126854"
+    }, { SHA1HashSize, SHA224HashSize, SHA256HashSize,
+      SHA384HashSize, SHA512HashSize }
+  },
+  { /* 2 */ {
+      "\x4a\x65\x66\x65" /* "Jefe" */
+    }, { 4 }, {
+      "\x77\x68\x61\x74\x20\x64\x6f\x20\x79\x61\x20\x77\x61\x6e\x74"
+      "\x20\x66\x6f\x72\x20\x6e\x6f\x74\x68\x69\x6e\x67\x3f"
+      /* "what do ya want for nothing?" */
+    }, { 28 }, {
+      /* HMAC-SHA-1 */
+      "EFFCDF6AE5EB2FA2D27416D5F184DF9C259A7C79",
+      /* HMAC-SHA-224 */
+      "A30E01098BC6DBBF45690F3A7E9E6D0F8BBEA2A39E6148008FD05E44",
+      /* HMAC-SHA-256 */
+      "5BDCC146BF60754E6A042426089575C75A003F089D2739839DEC58B964EC"
+      "3843",
+      /* HMAC-SHA-384 */
+      "AF45D2E376484031617F78D2B58A6B1B9C7EF464F5A01B47E42EC3736322"
+      "445E8E2240CA5E69E2C78B3239ECFAB21649",
+      /* HMAC-SHA-512 */
+      "164B7A7BFCF819E2E395FBE73B56E0A387BD64222E831FD610270CD7EA25"
+      "05549758BF75C05A994A6D034F65F8F0E6FDCAEAB1A34D4A6B4B636E070A"
+      "38BCE737"
+    }, { SHA1HashSize, SHA224HashSize, SHA256HashSize,
+      SHA384HashSize, SHA512HashSize }
+  },
+  { /* 3 */
+    {
+      "\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa"
+      "\xaa\xaa\xaa\xaa\xaa"
+    }, { 20 }, {
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 87]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+      "\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd"
+      "\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd"
+      "\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd"
+      "\xdd\xdd\xdd\xdd\xdd"
+    }, { 50 }, {
+      /* HMAC-SHA-1 */
+      "125D7342B9AC11CD91A39AF48AA17B4F63F175D3",
+      /* HMAC-SHA-224 */
+      "7FB3CB3588C6C1F6FFA9694D7D6AD2649365B0C1F65D69D1EC8333EA",
+      /* HMAC-SHA-256 */
+      "773EA91E36800E46854DB8EBD09181A72959098B3EF8C122D9635514CED5"
+      "65FE",
+      /* HMAC-SHA-384 */
+      "88062608D3E6AD8A0AA2ACE014C8A86F0AA635D947AC9FEBE83EF4E55966"
+      "144B2A5AB39DC13814B94E3AB6E101A34F27",
+      /* HMAC-SHA-512 */
+      "FA73B0089D56A284EFB0F0756C890BE9B1B5DBDD8EE81A3655F83E33B227"
+      "9D39BF3E848279A722C806B485A47E67C807B946A337BEE8942674278859"
+      "E13292FB"
+    }, { SHA1HashSize, SHA224HashSize, SHA256HashSize,
+      SHA384HashSize, SHA512HashSize }
+  },
+  { /* 4 */ {
+      "\x01\x02\x03\x04\x05\x06\x07\x08\x09\x0a\x0b\x0c\x0d\x0e\x0f"
+      "\x10\x11\x12\x13\x14\x15\x16\x17\x18\x19"
+    }, { 25 }, {
+      "\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd"
+      "\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd"
+      "\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd"
+      "\xcd\xcd\xcd\xcd\xcd"
+    }, { 50 }, {
+      /* HMAC-SHA-1 */
+      "4C9007F4026250C6BC8414F9BF50C86C2D7235DA",
+      /* HMAC-SHA-224 */
+      "6C11506874013CAC6A2ABC1BB382627CEC6A90D86EFC012DE7AFEC5A",
+      /* HMAC-SHA-256 */
+      "82558A389A443C0EA4CC819899F2083A85F0FAA3E578F8077A2E3FF46729"
+      "665B",
+      /* HMAC-SHA-384 */
+      "3E8A69B7783C25851933AB6290AF6CA77A9981480850009CC5577C6E1F57"
+      "3B4E6801DD23C4A7D679CCF8A386C674CFFB",
+      /* HMAC-SHA-512 */
+      "B0BA465637458C6990E5A8C5F61D4AF7E576D97FF94B872DE76F8050361E"
+      "E3DBA91CA5C11AA25EB4D679275CC5788063A5F19741120C4F2DE2ADEBEB"
+      "10A298DD"
+    }, { SHA1HashSize, SHA224HashSize, SHA256HashSize,
+      SHA384HashSize, SHA512HashSize }
+  },
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 88]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+  { /* 5 */ {
+      "\x0c\x0c\x0c\x0c\x0c\x0c\x0c\x0c\x0c\x0c\x0c\x0c\x0c\x0c\x0c"
+      "\x0c\x0c\x0c\x0c\x0c"
+    }, { 20 }, {
+      "Test With Truncation"
+    }, { 20 }, {
+      /* HMAC-SHA-1 */
+      "4C1A03424B55E07FE7F27BE1",
+      /* HMAC-SHA-224 */
+      "0E2AEA68A90C8D37C988BCDB9FCA6FA8",
+      /* HMAC-SHA-256 */
+      "A3B6167473100EE06E0C796C2955552B",
+      /* HMAC-SHA-384 */
+      "3ABF34C3503B2A23A46EFC619BAEF897",
+      /* HMAC-SHA-512 */
+      "415FAD6271580A531D4179BC891D87A6"
+    }, { 12, 16, 16, 16, 16 }
+  },
+  { /* 6 */ {
+      "\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa"
+      "\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa"
+      "\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa"
+      "\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa"
+      "\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa"
+      "\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa"
+      "\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa"
+      "\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa"
+      "\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa"
+    }, { 80, 131 }, {
+      "Test Using Larger Than Block-Size Key - Hash Key First"
+    }, { 54 }, {
+      /* HMAC-SHA-1 */
+      "AA4AE5E15272D00E95705637CE8A3B55ED402112",
+      /* HMAC-SHA-224 */
+      "95E9A0DB962095ADAEBE9B2D6F0DBCE2D499F112F2D2B7273FA6870E",
+      /* HMAC-SHA-256 */
+      "60E431591EE0B67F0D8A26AACBF5B77F8E0BC6213728C5140546040F0EE3"
+      "7F54",
+      /* HMAC-SHA-384 */
+      "4ECE084485813E9088D2C63A041BC5B44F9EF1012A2B588F3CD11F05033A"
+      "C4C60C2EF6AB4030FE8296248DF163F44952",
+      /* HMAC-SHA-512 */
+      "80B24263C7C1A3EBB71493C1DD7BE8B49B46D1F41B4AEEC1121B013783F8"
+      "F3526B56D037E05F2598BD0FD2215D6A1E5295E64F73F63F0AEC8B915A98"
+      "5D786598"
+    }, { SHA1HashSize, SHA224HashSize, SHA256HashSize,
+      SHA384HashSize, SHA512HashSize }
+  },
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 89]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+  { /* 7 */ {
+      "\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa"
+      "\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa"
+      "\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa"
+      "\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa"
+      "\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa"
+      "\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa"
+      "\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa"
+      "\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa"
+      "\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa"
+    }, { 80, 131 }, {
+      "Test Using Larger Than Block-Size Key and "
+      "Larger Than One Block-Size Data",
+      "\x54\x68\x69\x73\x20\x69\x73\x20\x61\x20\x74\x65\x73\x74\x20"
+      "\x75\x73\x69\x6e\x67\x20\x61\x20\x6c\x61\x72\x67\x65\x72\x20"
+      "\x74\x68\x61\x6e\x20\x62\x6c\x6f\x63\x6b\x2d\x73\x69\x7a\x65"
+      "\x20\x6b\x65\x79\x20\x61\x6e\x64\x20\x61\x20\x6c\x61\x72\x67"
+      "\x65\x72\x20\x74\x68\x61\x6e\x20\x62\x6c\x6f\x63\x6b\x2d\x73"
+      "\x69\x7a\x65\x20\x64\x61\x74\x61\x2e\x20\x54\x68\x65\x20\x6b"
+      "\x65\x79\x20\x6e\x65\x65\x64\x73\x20\x74\x6f\x20\x62\x65\x20"
+      "\x68\x61\x73\x68\x65\x64\x20\x62\x65\x66\x6f\x72\x65\x20\x62"
+      "\x65\x69\x6e\x67\x20\x75\x73\x65\x64\x20\x62\x79\x20\x74\x68"
+      "\x65\x20\x48\x4d\x41\x43\x20\x61\x6c\x67\x6f\x72\x69\x74\x68"
+      "\x6d\x2e"
+      /* "This is a test using a larger than block-size key and a "
+          "larger than block-size data. The key needs to be hashed "
+          "before being used by the HMAC algorithm." */
+    }, { 73, 152 }, {
+      /* HMAC-SHA-1 */
+      "E8E99D0F45237D786D6BBAA7965C7808BBFF1A91",
+      /* HMAC-SHA-224 */
+      "3A854166AC5D9F023F54D517D0B39DBD946770DB9C2B95C9F6F565D1",
+      /* HMAC-SHA-256 */
+      "9B09FFA71B942FCB27635FBCD5B0E944BFDC63644F0713938A7F51535C3A"
+      "35E2",
+      /* HMAC-SHA-384 */
+      "6617178E941F020D351E2F254E8FD32C602420FEB0B8FB9ADCCEBB82461E"
+      "99C5A678CC31E799176D3860E6110C46523E",
+      /* HMAC-SHA-512 */
+      "E37B6A775DC87DBAA4DFA9F96E5E3FFDDEBD71F8867289865DF5A32D20CD"
+      "C944B6022CAC3C4982B10D5EEB55C3E4DE15134676FB6DE0446065C97440"
+      "FA8C6A58"
+    }, { SHA1HashSize, SHA224HashSize, SHA256HashSize,
+      SHA384HashSize, SHA512HashSize }
+  }
+};
+
+/*
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 90]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+ * Check the hash value against the expected string, expressed in hex
+ */
+static const char hexdigits[] = "0123456789ABCDEF";
+int checkmatch(const unsigned char *hashvalue,
+  const char *hexstr, int hashsize)
+{
+  int i;
+  for (i = 0; i < hashsize; ++i) {
+    if (*hexstr++ != hexdigits[(hashvalue[i] >> 4) & 0xF])
+      return 0;
+    if (*hexstr++ != hexdigits[hashvalue[i] & 0xF]) return 0;
+  }
+  return 1;
+}
+
+/*
+ * Print the string, converting non-printable characters to "."
+ */
+void printstr(const char *str, int len)
+{
+  for ( ; len-- > 0; str++)
+    putchar(isprint((unsigned char)*str) ? *str : '.');
+}
+
+/*
+ * Print the string, converting non-printable characters to hex "## ".
+ */
+void printxstr(const char *str, int len)
+{
+  for ( ; len-- > 0; str++)
+    printf("%c%c ", hexdigits[(*str >> 4) & 0xF],
+      hexdigits[*str & 0xF]);
+}
+
+/*
+ * Print a usage message.
+ */
+void usage(const char *argv0)
+{
+  fprintf(stderr,
+    "Usage:\n"
+    "Common options: [-h hash] [-w|-x] [-H]\n"
+    "Standard tests:\n"
+      "\t%s [-m] [-l loopcount] [-t test#] [-e]\n"
+      "\t\t[-r randomseed] [-R randomloop-count] "
+        "[-p] [-P|-X]\n"
+    "Hash a string:\n"
+      "\t%s [-S expectedresult] -s hashstr [-k key]\n"
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 91]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+    "Hash a file:\n"
+      "\t%s [-S expectedresult] -f file [-k key]\n"
+    "Hash a file, ignoring whitespace:\n"
+      "\t%s [-S expectedresult] -F file [-k key]\n"
+    "Additional bits to add in: [-B bitcount -b bits]\n"
+    "-h\thash to test: "
+      "0|SHA1, 1|SHA224, 2|SHA256, 3|SHA384, 4|SHA512\n"
+    "-m\tperform hmac test\n"
+    "-k\tkey for hmac test\n"
+    "-t\ttest case to run, 1-10\n"
+    "-l\thow many times to run the test\n"
+    "-e\ttest error returns\n"
+    "-p\tdo not print results\n"
+    "-P\tdo not print PASSED/FAILED\n"
+    "-X\tprint FAILED, but not PASSED\n"
+    "-r\tseed for random test\n"
+    "-R\thow many times to run random test\n"
+    "-s\tstring to hash\n"
+    "-S\texpected result of hashed string, in hex\n"
+    "-w\toutput hash in raw format\n"
+    "-x\toutput hash in hex format\n"
+    "-B\t# extra bits to add in after string or file input\n"
+    "-b\textra bits to add (high order bits of #, 0# or 0x#)\n"
+    "-H\tinput hashstr or randomseed is in hex\n"
+    , argv0, argv0, argv0, argv0);
+  exit(1);
+}
+
+/*
+ * Print the results and PASS/FAIL.
+ */
+void printResult(uint8_t *Message_Digest, int hashsize,
+    const char *hashname, const char *testtype, const char *testname,
+    const char *resultarray, int printResults, int printPassFail)
+{
+  int i, k;
+  if (printResults == PRINTTEXT) {
+    putchar('\t');
+    for (i = 0; i < hashsize ; ++i) {
+      putchar(hexdigits[(Message_Digest[i] >> 4) & 0xF]);
+      putchar(hexdigits[Message_Digest[i] & 0xF]);
+      putchar(' ');
+    }
+    putchar('\n');
+  } else if (printResults == PRINTRAW) {
+    fwrite(Message_Digest, 1, hashsize, stdout);
+  } else if (printResults == PRINTHEX) {
+    for (i = 0; i < hashsize ; ++i) {
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 92]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+      putchar(hexdigits[(Message_Digest[i] >> 4) & 0xF]);
+      putchar(hexdigits[Message_Digest[i] & 0xF]);
+    }
+    putchar('\n');
+  }
+
+  if (printResults && resultarray) {
+    printf("    Should match:\n\t");
+    for (i = 0, k = 0; i < hashsize; i++, k += 2) {
+      putchar(resultarray[k]);
+      putchar(resultarray[k+1]);
+      putchar(' ');
+    }
+    putchar('\n');
+  }
+
+  if (printPassFail && resultarray) {
+    int ret = checkmatch(Message_Digest, resultarray, hashsize);
+    if ((printPassFail == PRINTPASSFAIL) || !ret)
+      printf("%s %s %s: %s\n", hashname, testtype, testname,
+        ret ? "PASSED" : "FAILED");
+  }
+}
+
+/*
+ * Exercise a hash series of functions. The input is the testarray,
+ * repeated repeatcount times, followed by the extrabits. If the
+ * result is known, it is in resultarray in uppercase hex.
+ */
+int hash(int testno, int loopno, int hashno,
+  const char *testarray, int length, long repeatcount,
+  int numberExtrabits, int extrabits, const unsigned char *keyarray,
+  int keylen, const char *resultarray, int hashsize, int printResults,
+  int printPassFail)
+{
+  USHAContext sha;
+  HMACContext hmac;
+  int err, i;
+  uint8_t Message_Digest[USHAMaxHashSize];
+  char buf[20];
+
+  if (printResults == PRINTTEXT) {
+    printf("\nTest %d: Iteration %d, Repeat %ld\n\t'", testno+1,
+      loopno, repeatcount);
+    printstr(testarray, length);
+    printf("'\n\t'");
+    printxstr(testarray, length);
+    printf("'\n");
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 93]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+    printf("    Length=%d bytes (%d bits), ", length, length * 8);
+    printf("ExtraBits %d: %2.2x\n", numberExtrabits, extrabits);
+  }
+
+  memset(&sha, '\343', sizeof(sha)); /* force bad data into struct */
+  memset(&hmac, '\343', sizeof(hmac));
+  err = keyarray ? hmacReset(&hmac, hashes[hashno].whichSha,
+                             keyarray, keylen) :
+                   USHAReset(&sha, hashes[hashno].whichSha);
+  if (err != shaSuccess) {
+    fprintf(stderr, "hash(): %sReset Error %d.\n",
+            keyarray ? "hmac" : "sha", err);
+    return err;
+  }
+
+  for (i = 0; i < repeatcount; ++i) {
+    err = keyarray ? hmacInput(&hmac, (const uint8_t *) testarray,
+                               length) :
+                     USHAInput(&sha, (const uint8_t *) testarray,
+                               length);
+    if (err != shaSuccess) {
+      fprintf(stderr, "hash(): %sInput Error %d.\n",
+              keyarray ? "hmac" : "sha", err);
+      return err;
+    }
+  }
+
+  if (numberExtrabits > 0) {
+    err = keyarray ? hmacFinalBits(&hmac, (uint8_t) extrabits,
+                                   numberExtrabits) :
+                     USHAFinalBits(&sha, (uint8_t) extrabits,
+                                   numberExtrabits);
+    if (err != shaSuccess) {
+      fprintf(stderr, "hash(): %sFinalBits Error %d.\n",
+              keyarray ? "hmac" : "sha", err);
+      return err;
+    }
+  }
+
+  err = keyarray ? hmacResult(&hmac, Message_Digest) :
+                   USHAResult(&sha, Message_Digest);
+  if (err != shaSuccess) {
+    fprintf(stderr, "hash(): %s Result Error %d, could not "
+      "compute message digest.\n", keyarray ? "hmac" : "sha", err);
+    return err;
+  }
+
+  sprintf(buf, "%d", testno+1);
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 94]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+  printResult(Message_Digest, hashsize, hashes[hashno].name,
+    keyarray ? "hmac standard test" : "sha standard test", buf,
+    resultarray, printResults, printPassFail);
+
+  return err;
+}
+
+/*
+ * Exercise a hash series of functions. The input is a filename.
+ * If the result is known, it is in resultarray in uppercase hex.
+ */
+int hashfile(int hashno, const char *hashfilename, int bits,
+  int bitcount, int skipSpaces, const unsigned char *keyarray,
+  int keylen, const char *resultarray, int hashsize,
+  int printResults, int printPassFail)
+{
+  USHAContext sha;
+  HMACContext hmac;
+  int err, nread, c;
+  unsigned char buf[4096];
+  uint8_t Message_Digest[USHAMaxHashSize];
+  unsigned char cc;
+  FILE *hashfp = (strcmp(hashfilename, "-") == 0) ? stdin :
+    fopen(hashfilename, "r");
+
+  if (!hashfp) {
+    fprintf(stderr, "cannot open file '%s'\n", hashfilename);
+    return shaStateError;
+  }
+
+  memset(&sha, '\343', sizeof(sha)); /* force bad data into struct */
+  memset(&hmac, '\343', sizeof(hmac));
+  err = keyarray ? hmacReset(&hmac, hashes[hashno].whichSha,
+                             keyarray, keylen) :
+                   USHAReset(&sha, hashes[hashno].whichSha);
+
+  if (err != shaSuccess) {
+    fprintf(stderr, "hashfile(): %sReset Error %d.\n",
+            keyarray ? "hmac" : "sha", err);
+    return err;
+  }
+
+  if (skipSpaces)
+    while ((c = getc(hashfp)) != EOF) {
+      if (!isspace(c)) {
+        cc = (unsigned char)c;
+        err = keyarray ? hmacInput(&hmac, &cc, 1) :
+                         USHAInput(&sha, &cc, 1);
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 95]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+        if (err != shaSuccess) {
+          fprintf(stderr, "hashfile(): %sInput Error %d.\n",
+                  keyarray ? "hmac" : "sha", err);
+          if (hashfp != stdin) fclose(hashfp);
+          return err;
+        }
+      }
+    }
+  else
+    while ((nread = fread(buf, 1, sizeof(buf), hashfp)) > 0) {
+      err = keyarray ? hmacInput(&hmac, buf, nread) :
+                       USHAInput(&sha, buf, nread);
+      if (err != shaSuccess) {
+        fprintf(stderr, "hashfile(): %s Error %d.\n",
+                keyarray ? "hmacInput" : "shaInput", err);
+        if (hashfp != stdin) fclose(hashfp);
+        return err;
+      }
+    }
+
+  if (bitcount > 0)
+    err = keyarray ? hmacFinalBits(&hmac, bits, bitcount) :
+                   USHAFinalBits(&sha, bits, bitcount);
+  if (err != shaSuccess) {
+    fprintf(stderr, "hashfile(): %s Error %d.\n",
+            keyarray ? "hmacResult" : "shaResult", err);
+    if (hashfp != stdin) fclose(hashfp);
+    return err;
+  }
+
+  err = keyarray ? hmacResult(&hmac, Message_Digest) :
+                   USHAResult(&sha, Message_Digest);
+  if (err != shaSuccess) {
+    fprintf(stderr, "hashfile(): %s Error %d.\n",
+            keyarray ? "hmacResult" : "shaResult", err);
+    if (hashfp != stdin) fclose(hashfp);
+    return err;
+  }
+
+  printResult(Message_Digest, hashsize, hashes[hashno].name, "file",
+    hashfilename, resultarray, printResults, printPassFail);
+
+  if (hashfp != stdin) fclose(hashfp);
+  return err;
+}
+
+/*
+ * Exercise a hash series of functions through multiple permutations.
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 96]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+ * The input is an initial seed. That seed is replicated 3 times.
+ * For 1000 rounds, the previous three results are used as the input.
+ * This result is then checked, and used to seed the next cycle.
+ * If the result is known, it is in resultarrays in uppercase hex.
+ */
+void randomtest(int hashno, const char *seed, int hashsize,
+    const char **resultarrays, int randomcount,
+    int printResults, int printPassFail)
+{
+  int i, j; char buf[20];
+  unsigned char SEED[USHAMaxHashSize], MD[1003][USHAMaxHashSize];
+
+  /* INPUT: Seed - A random seed n bits long */
+  memcpy(SEED, seed, hashsize);
+  if (printResults == PRINTTEXT) {
+    printf("%s random test seed= '", hashes[hashno].name);
+    printxstr(seed, hashsize);
+    printf("'\n");
+  }
+
+  for (j = 0; j < randomcount; j++) {
+    /* MD0 = MD1 = MD2 = Seed; */
+    memcpy(MD[0], SEED, hashsize);
+    memcpy(MD[1], SEED, hashsize);
+    memcpy(MD[2], SEED, hashsize);
+    for (i=3; i<1003; i++) {
+      /* Mi = MDi-3 || MDi-2 || MDi-1; */
+      USHAContext Mi;
+      memset(&Mi, '\343', sizeof(Mi)); /* force bad data into struct */
+      USHAReset(&Mi, hashes[hashno].whichSha);
+      USHAInput(&Mi, MD[i-3], hashsize);
+      USHAInput(&Mi, MD[i-2], hashsize);
+      USHAInput(&Mi, MD[i-1], hashsize);
+      /* MDi = SHA(Mi); */
+      USHAResult(&Mi, MD[i]);
+    }
+
+    /* MDj = Seed = MDi; */
+    memcpy(SEED, MD[i-1], hashsize);
+
+    /* OUTPUT: MDj */
+    sprintf(buf, "%d", j);
+    printResult(SEED, hashsize, hashes[hashno].name, "random test",
+      buf, resultarrays ? resultarrays[j] : 0, printResults,
+      (j < RANDOMCOUNT) ? printPassFail : 0);
+  }
+}
+
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 97]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+/*
+ * Look up a hash name.
+ */
+int findhash(const char *argv0, const char *opt)
+{
+  int i;
+  const char *names[HASHCOUNT][2] = {
+    { "0", "sha1" }, { "1", "sha224" }, { "2", "sha256" },
+    { "3", "sha384" }, { "4", "sha512" }
+  };
+
+  for (i = 0; i < HASHCOUNT; i++)
+    if ((strcmp(opt, names[i][0]) == 0) ||
+        (scasecmp(opt, names[i][1]) == 0))
+      return i;
+
+  fprintf(stderr, "%s: Unknown hash name: '%s'\n", argv0, opt);
+  usage(argv0);
+  return 0;
+}
+
+/*
+ * Run some tests that should invoke errors.
+ */
+void testErrors(int hashnolow, int hashnohigh, int printResults,
+    int printPassFail)
+{
+  USHAContext usha;
+  uint8_t Message_Digest[USHAMaxHashSize];
+  int hashno, err;
+
+  for (hashno = hashnolow; hashno <= hashnohigh; hashno++) {
+    memset(&usha, '\343', sizeof(usha)); /* force bad data */
+    USHAReset(&usha, hashno);
+    USHAResult(&usha, Message_Digest);
+    err = USHAInput(&usha, (const unsigned char *)"foo", 3);
+    if (printResults == PRINTTEXT)
+      printf ("\nError %d. Should be %d.\n", err, shaStateError);
+    if ((printPassFail == PRINTPASSFAIL) ||
+        ((printPassFail == PRINTFAIL) && (err != shaStateError)))
+      printf("%s se: %s\n", hashes[hashno].name,
+        (err == shaStateError) ? "PASSED" : "FAILED");
+
+    err = USHAFinalBits(&usha, 0x80, 3);
+    if (printResults == PRINTTEXT)
+      printf ("\nError %d. Should be %d.\n", err, shaStateError);
+    if ((printPassFail == PRINTPASSFAIL) ||
+        ((printPassFail == PRINTFAIL) && (err != shaStateError)))
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 98]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+      printf("%s se: %s\n", hashes[hashno].name,
+        (err == shaStateError) ? "PASSED" : "FAILED");
+
+    err = USHAReset(0, hashes[hashno].whichSha);
+    if (printResults == PRINTTEXT)
+       printf("\nError %d. Should be %d.\n", err, shaNull);
+    if ((printPassFail == PRINTPASSFAIL) ||
+        ((printPassFail == PRINTFAIL) && (err != shaNull)))
+       printf("%s usha null: %s\n", hashes[hashno].name,
+        (err == shaNull) ? "PASSED" : "FAILED");
+
+    switch (hashno) {
+      case SHA1: err = SHA1Reset(0); break;
+      case SHA224: err = SHA224Reset(0); break;
+      case SHA256: err = SHA256Reset(0); break;
+      case SHA384: err = SHA384Reset(0); break;
+      case SHA512: err = SHA512Reset(0); break;
+    }
+    if (printResults == PRINTTEXT)
+       printf("\nError %d. Should be %d.\n", err, shaNull);
+    if ((printPassFail == PRINTPASSFAIL) ||
+        ((printPassFail == PRINTFAIL) && (err != shaNull)))
+       printf("%s sha null: %s\n", hashes[hashno].name,
+        (err == shaNull) ? "PASSED" : "FAILED");
+  }
+}
+
+/* replace a hex string in place with its value */
+int unhexStr(char *hexstr)
+{
+  char *o = hexstr;
+  int len = 0, nibble1 = 0, nibble2 = 0;
+  if (!hexstr) return 0;
+  for ( ; *hexstr; hexstr++) {
+    if (isalpha((int)(unsigned char)(*hexstr))) {
+      nibble1 = tolower(*hexstr) - 'a' + 10;
+    } else if (isdigit((int)(unsigned char)(*hexstr))) {
+      nibble1 = *hexstr - '0';
+    } else {
+      printf("\nError: bad hex character '%c'\n", *hexstr);
+    }
+    if (!*++hexstr) break;
+    if (isalpha((int)(unsigned char)(*hexstr))) {
+      nibble2 = tolower(*hexstr) - 'a' + 10;
+    } else if (isdigit((int)(unsigned char)(*hexstr))) {
+      nibble2 = *hexstr - '0';
+    } else {
+      printf("\nError: bad hex character '%c'\n", *hexstr);
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 99]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+    }
+    *o++ = (char)((nibble1 << 4) | nibble2);
+    len++;
+  }
+  return len;
+}
+
+int main(int argc, char **argv)
+{
+  int i, err;
+  int loopno, loopnohigh = 1;
+  int hashno, hashnolow = 0, hashnohigh = HASHCOUNT - 1;
+  int testno, testnolow = 0, testnohigh;
+  int ntestnohigh = 0;
+  int printResults = PRINTTEXT;
+  int printPassFail = 1;
+  int checkErrors = 0;
+  char *hashstr = 0;
+  int hashlen = 0;
+  const char *resultstr = 0;
+  char *randomseedstr = 0;
+  int runHmacTests = 0;
+  char *hmacKey = 0;
+  int hmaclen = 0;
+  int randomcount = RANDOMCOUNT;
+  const char *hashfilename = 0;
+  const char *hashFilename = 0;
+  int extrabits = 0, numberExtrabits = 0;
+  int strIsHex = 0;
+
+  while ((i = xgetopt(argc, argv, "b:B:ef:F:h:Hk:l:mpPr:R:s:S:t:wxX"))
+         != -1)
+    switch (i) {
+      case 'b': extrabits = strtol(xoptarg, 0, 0); break;
+      case 'B': numberExtrabits = atoi(xoptarg); break;
+      case 'e': checkErrors = 1; break;
+      case 'f': hashfilename = xoptarg; break;
+      case 'F': hashFilename = xoptarg; break;
+      case 'h': hashnolow = hashnohigh = findhash(argv[0], xoptarg);
+        break;
+      case 'H': strIsHex = 1; break;
+      case 'k': hmacKey = xoptarg; hmaclen = strlen(xoptarg); break;
+      case 'l': loopnohigh = atoi(xoptarg); break;
+      case 'm': runHmacTests = 1; break;
+      case 'P': printPassFail = 0; break;
+      case 'p': printResults = PRINTNONE; break;
+      case 'R': randomcount = atoi(xoptarg); break;
+      case 'r': randomseedstr = xoptarg; break;
+
+
+
+Eastlake 3rd & Hansen        Informational                    [Page 100]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+      case 's': hashstr = xoptarg; hashlen = strlen(hashstr); break;
+      case 'S': resultstr = xoptarg; break;
+      case 't': testnolow = ntestnohigh = atoi(xoptarg) - 1; break;
+      case 'w': printResults = PRINTRAW; break;
+      case 'x': printResults = PRINTHEX; break;
+      case 'X': printPassFail = 2; break;
+      default: usage(argv[0]);
+      }
+
+  if (strIsHex) {
+    hashlen = unhexStr(hashstr);
+    unhexStr(randomseedstr);
+    hmaclen = unhexStr(hmacKey);
+  }
+  testnohigh = (ntestnohigh != 0) ? ntestnohigh:
+               runHmacTests ? (HMACTESTCOUNT-1) : (TESTCOUNT-1);
+  if ((testnolow < 0) ||
+      (testnohigh >= (runHmacTests ? HMACTESTCOUNT : TESTCOUNT)) ||
+      (hashnolow < 0) || (hashnohigh >= HASHCOUNT) ||
+      (hashstr && (testnolow == testnohigh)) ||
+      (randomcount < 0) ||
+      (resultstr && (!hashstr && !hashfilename && !hashFilename)) ||
+      ((runHmacTests || hmacKey) && randomseedstr) ||
+      (hashfilename && hashFilename))
+    usage(argv[0]);
+
+  /*
+   *  Perform SHA/HMAC tests
+   */
+  for (hashno = hashnolow; hashno <= hashnohigh; ++hashno) {
+    if (printResults == PRINTTEXT)
+      printf("Hash %s\n", hashes[hashno].name);
+    err = shaSuccess;
+
+    for (loopno = 1; (loopno <= loopnohigh) && (err == shaSuccess);
+         ++loopno) {
+      if (hashstr)
+        err = hash(0, loopno, hashno, hashstr, hashlen, 1,
+          numberExtrabits, extrabits, (const unsigned char *)hmacKey,
+          hmaclen, resultstr, hashes[hashno].hashsize, printResults,
+          printPassFail);
+
+      else if (randomseedstr)
+        randomtest(hashno, randomseedstr, hashes[hashno].hashsize, 0,
+          randomcount, printResults, printPassFail);
+
+      else if (hashfilename)
+        err = hashfile(hashno, hashfilename, extrabits,
+
+
+
+Eastlake 3rd & Hansen        Informational                    [Page 101]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+                       numberExtrabits, 0,
+                       (const unsigned char *)hmacKey, hmaclen,
+                       resultstr, hashes[hashno].hashsize,
+                       printResults, printPassFail);
+
+      else if (hashFilename)
+        err = hashfile(hashno, hashFilename, extrabits,
+                       numberExtrabits, 1,
+                       (const unsigned char *)hmacKey, hmaclen,
+                       resultstr, hashes[hashno].hashsize,
+                       printResults, printPassFail);
+
+      else /* standard tests */ {
+        for (testno = testnolow;
+             (testno <= testnohigh) && (err == shaSuccess); ++testno) {
+          if (runHmacTests) {
+            err = hash(testno, loopno, hashno,
+                       hmachashes[testno].dataarray[hashno] ?
+                       hmachashes[testno].dataarray[hashno] :
+                       hmachashes[testno].dataarray[1] ?
+                       hmachashes[testno].dataarray[1] :
+                       hmachashes[testno].dataarray[0],
+                       hmachashes[testno].datalength[hashno] ?
+                       hmachashes[testno].datalength[hashno] :
+                       hmachashes[testno].datalength[1] ?
+                       hmachashes[testno].datalength[1] :
+                       hmachashes[testno].datalength[0],
+                       1, 0, 0,
+                       (const unsigned char *)(
+                        hmachashes[testno].keyarray[hashno] ?
+                        hmachashes[testno].keyarray[hashno] :
+                        hmachashes[testno].keyarray[1] ?
+                        hmachashes[testno].keyarray[1] :
+                        hmachashes[testno].keyarray[0]),
+                       hmachashes[testno].keylength[hashno] ?
+                       hmachashes[testno].keylength[hashno] :
+                       hmachashes[testno].keylength[1] ?
+                       hmachashes[testno].keylength[1] :
+                       hmachashes[testno].keylength[0],
+                       hmachashes[testno].resultarray[hashno],
+                       hmachashes[testno].resultlength[hashno],
+                       printResults, printPassFail);
+          } else {
+            err = hash(testno, loopno, hashno,
+                       hashes[hashno].tests[testno].testarray,
+                       hashes[hashno].tests[testno].length,
+                       hashes[hashno].tests[testno].repeatcount,
+                       hashes[hashno].tests[testno].numberExtrabits,
+
+
+
+Eastlake 3rd & Hansen        Informational                    [Page 102]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+                       hashes[hashno].tests[testno].extrabits, 0, 0,
+                       hashes[hashno].tests[testno].resultarray,
+                       hashes[hashno].hashsize,
+                       printResults, printPassFail);
+          }
+        }
+
+        if (!runHmacTests) {
+          randomtest(hashno, hashes[hashno].randomtest,
+            hashes[hashno].hashsize, hashes[hashno].randomresults,
+            RANDOMCOUNT, printResults, printPassFail);
+        }
+      }
+    }
+  }
+
+  /* Test some error returns */
+  if (checkErrors) {
+    testErrors(hashnolow, hashnohigh, printResults, printPassFail);
+  }
+
+  return 0;
+}
+
+/*
+ * Compare two strings, case independently.
+ * Equivalent to strcasecmp() found on some systems.
+ */
+int scasecmp(const char *s1, const char *s2)
+{
+  for (;;) {
+    char u1 = tolower(*s1++);
+    char u2 = tolower(*s2++);
+    if (u1 != u2)
+      return u1 - u2;
+    if (u1 == '\0')
+      return 0;
+   }
+}
+
+/*
+ * This is a copy of getopt provided for those systems that do not
+ * have it. The name was changed to xgetopt to not conflict on those
+ * systems that do have it. Similarly, optarg, optind and opterr
+ * were renamed to xoptarg, xoptind and xopterr.
+ *
+ * Copyright 1990, 1991, 1992 by the Massachusetts Institute of
+ * Technology and UniSoft Group Limited.
+
+
+
+Eastlake 3rd & Hansen        Informational                    [Page 103]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+ *
+ * Permission to use, copy, modify, distribute, and sell this software
+ * and its documentation for any purpose is hereby granted without fee,
+ * provided that the above copyright notice appear in all copies and
+ * that both that copyright notice and this permission notice appear in
+ * supporting documentation, and that the names of MIT and UniSoft not
+ * be used in advertising or publicity pertaining to distribution of
+ * the software without specific, written prior permission.  MIT and
+ * UniSoft make no representations about the suitability of this
+ * software for any purpose.  It is provided "as is" without express
+ * or implied warranty.
+ *
+ * $XConsortium: getopt.c,v 1.2 92/07/01 11:59:04 rws Exp $
+ * NB: Reformatted to match above style.
+ */
+
+char    *xoptarg;
+int     xoptind = 1;
+int     xopterr = 1;
+
+static int xgetopt(int argc, char **argv, const char *optstring)
+{
+  static int avplace;
+  char    *ap;
+  char    *cp;
+  int     c;
+
+  if (xoptind >= argc)
+    return EOF;
+
+  ap = argv[xoptind] + avplace;
+
+  /* At beginning of arg but not an option */
+  if (avplace == 0) {
+    if (ap[0] != '-')
+      return EOF;
+    else if (ap[1] == '-') {
+      /* Special end of options option */
+      xoptind++;
+      return EOF;
+    } else if (ap[1] == '\0')
+      return EOF;  /* single '-' is not allowed */
+  }
+
+  /* Get next letter */
+  avplace++;
+  c = *++ap;
+
+
+
+
+Eastlake 3rd & Hansen        Informational                    [Page 104]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+  cp = strchr(optstring, c);
+  if (cp == NULL || c == ':') {
+    if (xopterr)
+      fprintf(stderr, "Unrecognised option -- %c\n", c);
+    return '?';
+  }
+
+  if (cp[1] == ':') {
+    /* There should be an option arg */
+    avplace = 0;
+    if (ap[1] == '\0') {
+      /* It is a separate arg */
+      if (++xoptind >= argc) {
+        if (xopterr)
+          fprintf(stderr, "Option requires an argument\n");
+        return '?';
+      }
+      xoptarg = argv[xoptind++];
+    } else {
+      /* is attached to option letter */
+      xoptarg = ap + 1;
+      ++xoptind;
+    }
+  } else {
+    /* If we are out of letters then go to next arg */
+    if (ap[1] == '\0') {
+      ++xoptind;
+      avplace = 0;
+    }
+
+    xoptarg = NULL;
+  }
+  return c;
+}
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake 3rd & Hansen        Informational                    [Page 105]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+9.  Security Considerations
+
+   This document is intended to provides the Internet community
+   convenient access to source code that implements the United States of
+   America Federal Information Processing Standard Secure Hash
+   Algorithms (SHAs) [FIPS180-2] and HMACs based upon these one-way hash
+   functions.  See license in Section 1.1.  No independent assertion of
+   the security of this hash function by the authors for any particular
+   use is intended.
+
+10.  Normative References
+
+   [FIPS180-2] "Secure Hash Standard", United States of America,
+               National Institute of Standards and Technology, Federal
+               Information Processing Standard (FIPS) 180-2,
+               http://csrc.nist.gov/publications/fips/fips180-2/
+               fips180-2withchangenotice.pdf.
+
+   [RFC2104]   Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
+               Hashing for Message Authentication", RFC 2104, February
+               1997.
+
+11.  Informative References
+
+   [RFC2202]   Cheng, P. and R. Glenn, "Test Cases for HMAC-MD5 and
+               HMAC-SHA-1", RFC 2202, September 1997.
+
+   [RFC3174]   Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm
+               1 (SHA1)", RFC 3174, September 2001.
+
+   [RFC3874]   Housley, R., "A 224-bit One-way Hash Function: SHA-224",
+               RFC 3874, September 2004.
+
+   [RFC4086]   Eastlake, D., 3rd, Schiller, J., and S. Crocker,
+               "Randomness Requirements for Security", BCP 106, RFC
+               4086, June 2005.
+
+   [RFC4231]   Nystrom, M., "Identifiers and Test Vectors for HMAC-SHA-
+               224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512", RFC
+               4231, December 2005.
+
+   [SHAVS]     "The Secure Hash Algorithm Validation System (SHAVS)",
+               http://csrc.nist.gov/cryptval/shs/SHAVS.pdf.
+
+
+
+
+
+
+
+
+Eastlake 3rd & Hansen        Informational                    [Page 106]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+Authors' Addresses
+
+   Donald E. Eastlake, 3rd
+   Motorola Laboratories
+   155 Beaver Street
+   Milford, MA 01757 USA
+
+   Phone: +1-508-786-7554 (w)
+   EMail: donald.eastlake@motorola.com
+
+
+   Tony Hansen
+   AT&T Laboratories
+   200 Laurel Ave.
+   Middletown, NJ 07748 USA
+
+   Phone: +1-732-420-8934 (w)
+   EMail: tony+shs@maillennium.att.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake 3rd & Hansen        Informational                    [Page 107]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2006).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Eastlake 3rd & Hansen        Informational                    [Page 108]
+
diff --git a/doc/rfc/rfc4641.txt b/doc/rfc/rfc4641.txt
new file mode 100644
index 0000000..0a013bc
--- /dev/null
+++ b/doc/rfc/rfc4641.txt
@@ -0,0 +1,1963 @@
+
+
+
+
+
+
+Network Working Group                                         O. Kolkman
+Request for Comments: 4641                                     R. Gieben
+Obsoletes: 2541                                               NLnet Labs
+Category: Informational                                   September 2006
+
+
+                      DNSSEC Operational Practices
+
+Status of This Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   This document describes a set of practices for operating the DNS with
+   security extensions (DNSSEC).  The target audience is zone
+   administrators deploying DNSSEC.
+
+   The document discusses operational aspects of using keys and
+   signatures in the DNS.  It discusses issues of key generation, key
+   storage, signature generation, key rollover, and related policies.
+
+   This document obsoletes RFC 2541, as it covers more operational
+   ground and gives more up-to-date requirements with respect to key
+   sizes and the new DNSSEC specification.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kolkman & Gieben             Informational                      [Page 1]
+
+RFC 4641              DNSSEC Operational Practices        September 2006
+
+
+Table of Contents
+
+   1. Introduction ....................................................3
+      1.1. The Use of the Term 'key' ..................................4
+      1.2. Time Definitions ...........................................4
+   2. Keeping the Chain of Trust Intact ...............................5
+   3. Keys Generation and Storage .....................................6
+      3.1. Zone and Key Signing Keys ..................................6
+           3.1.1. Motivations for the KSK and ZSK Separation ..........6
+           3.1.2. KSKs for High-Level Zones ...........................7
+      3.2. Key Generation .............................................8
+      3.3. Key Effectivity Period .....................................8
+      3.4. Key Algorithm ..............................................9
+      3.5. Key Sizes ..................................................9
+      3.6. Private Key Storage .......................................11
+   4. Signature Generation, Key Rollover, and Related Policies .......12
+      4.1. Time in DNSSEC ............................................12
+           4.1.1. Time Considerations ................................12
+      4.2. Key Rollovers .............................................14
+           4.2.1. Zone Signing Key Rollovers .........................14
+                  4.2.1.1. Pre-Publish Key Rollover ..................15
+                  4.2.1.2. Double Signature Zone Signing Key
+                           Rollover ..................................17
+                  4.2.1.3. Pros and Cons of the Schemes ..............18
+           4.2.2. Key Signing Key Rollovers ..........................18
+           4.2.3. Difference Between ZSK and KSK Rollovers ...........20
+           4.2.4. Automated Key Rollovers ............................21
+      4.3. Planning for Emergency Key Rollover .......................21
+           4.3.1. KSK Compromise .....................................22
+                  4.3.1.1. Keeping the Chain of Trust Intact .........22
+                  4.3.1.2. Breaking the Chain of Trust ...............23
+           4.3.2. ZSK Compromise .....................................23
+           4.3.3. Compromises of Keys Anchored in Resolvers ..........24
+      4.4. Parental Policies .........................................24
+           4.4.1. Initial Key Exchanges and Parental Policies
+                  Considerations .....................................24
+           4.4.2. Storing Keys or Hashes? ............................25
+           4.4.3. Security Lameness ..................................25
+           4.4.4. DS Signature Validity Period .......................26
+   5. Security Considerations ........................................26
+   6. Acknowledgments ................................................26
+   7. References .....................................................27
+      7.1. Normative References ......................................27
+      7.2. Informative References ....................................28
+   Appendix A. Terminology ...........................................30
+   Appendix B. Zone Signing Key Rollover How-To ......................31
+   Appendix C. Typographic Conventions ...............................32
+
+
+
+
+Kolkman & Gieben             Informational                      [Page 2]
+
+RFC 4641              DNSSEC Operational Practices        September 2006
+
+
+1.  Introduction
+
+   This document describes how to run a DNS Security (DNSSEC)-enabled
+   environment.  It is intended for operators who have knowledge of the
+   DNS (see RFC 1034 [1] and RFC 1035 [2]) and want to deploy DNSSEC.
+   See RFC 4033 [4] for an introduction to DNSSEC, RFC 4034 [5] for the
+   newly introduced Resource Records (RRs), and RFC 4035 [6] for the
+   protocol changes.
+
+   During workshops and early operational deployment tests, operators
+   and system administrators have gained experience about operating the
+   DNS with security extensions (DNSSEC).  This document translates
+   these experiences into a set of practices for zone administrators.
+   At the time of writing, there exists very little experience with
+   DNSSEC in production environments; this document should therefore
+   explicitly not be seen as representing 'Best Current Practices'.
+
+   The procedures herein are focused on the maintenance of signed zones
+   (i.e., signing and publishing zones on authoritative servers).  It is
+   intended that maintenance of zones such as re-signing or key
+   rollovers be transparent to any verifying clients on the Internet.
+
+   The structure of this document is as follows.  In Section 2, we
+   discuss the importance of keeping the "chain of trust" intact.
+   Aspects of key generation and storage of private keys are discussed
+   in Section 3; the focus in this section is mainly on the private part
+   of the key(s).  Section 4 describes considerations concerning the
+   public part of the keys.  Since these public keys appear in the DNS
+   one has to take into account all kinds of timing issues, which are
+   discussed in Section 4.1.  Section 4.2 and Section 4.3 deal with the
+   rollover, or supercession, of keys.  Finally, Section 4.4 discusses
+   considerations on how parents deal with their children's public keys
+   in order to maintain chains of trust.
+
+   The typographic conventions used in this document are explained in
+   Appendix C.
+
+   Since this is a document with operational suggestions and there are
+   no protocol specifications, the RFC 2119 [7] language does not apply.
+
+   This document obsoletes RFC 2541 [12] to reflect the evolution of the
+   underlying DNSSEC protocol since then.  Changes in the choice of
+   cryptographic algorithms, DNS record types and type names, and the
+   parent-child key and signature exchange demanded a major rewrite and
+   additional information and explanation.
+
+
+
+
+
+
+Kolkman & Gieben             Informational                      [Page 3]
+
+RFC 4641              DNSSEC Operational Practices        September 2006
+
+
+1.1.  The Use of the Term 'key'
+
+   It is assumed that the reader is familiar with the concept of
+   asymmetric keys on which DNSSEC is based (public key cryptography
+   [17]).  Therefore, this document will use the term 'key' rather
+   loosely.  Where it is written that 'a key is used to sign data' it is
+   assumed that the reader understands that it is the private part of
+   the key pair that is used for signing.  It is also assumed that the
+   reader understands that the public part of the key pair is published
+   in the DNSKEY Resource Record and that it is the public part that is
+   used in key exchanges.
+
+1.2.  Time Definitions
+
+   In this document, we will be using a number of time-related terms.
+   The following definitions apply:
+
+   o  "Signature validity period" The period that a signature is valid.
+      It starts at the time specified in the signature inception field
+      of the RRSIG RR and ends at the time specified in the expiration
+      field of the RRSIG RR.
+
+   o  "Signature publication period" Time after which a signature (made
+      with a specific key) is replaced with a new signature (made with
+      the same key).  This replacement takes place by publishing the
+      relevant RRSIG in the master zone file.  After one stops
+      publishing an RRSIG in a zone, it may take a while before the
+      RRSIG has expired from caches and has actually been removed from
+      the DNS.
+
+   o  "Key effectivity period" The period during which a key pair is
+      expected to be effective.  This period is defined as the time
+      between the first inception time stamp and the last expiration
+      date of any signature made with this key, regardless of any
+      discontinuity in the use of the key.  The key effectivity period
+      can span multiple signature validity periods.
+
+   o  "Maximum/Minimum Zone Time to Live (TTL)" The maximum or minimum
+      value of the TTLs from the complete set of RRs in a zone.  Note
+      that the minimum TTL is not the same as the MINIMUM field in the
+      SOA RR.  See [11] for more information.
+
+
+
+
+
+
+
+
+
+
+Kolkman & Gieben             Informational                      [Page 4]
+
+RFC 4641              DNSSEC Operational Practices        September 2006
+
+
+2.  Keeping the Chain of Trust Intact
+
+   Maintaining a valid chain of trust is important because broken chains
+   of trust will result in data being marked as Bogus (as defined in [4]
+   Section 5), which may cause entire (sub)domains to become invisible
+   to verifying clients.  The administrators of secured zones have to
+   realize that their zone is, to verifying clients, part of a chain of
+   trust.
+
+   As mentioned in the introduction, the procedures herein are intended
+   to ensure that maintenance of zones, such as re-signing or key
+   rollovers, will be transparent to the verifying clients on the
+   Internet.
+
+   Administrators of secured zones will have to keep in mind that data
+   published on an authoritative primary server will not be immediately
+   seen by verifying clients; it may take some time for the data to be
+   transferred to other secondary authoritative nameservers and clients
+   may be fetching data from caching non-authoritative servers.  In this
+   light, note that the time for a zone transfer from master to slave is
+   negligible when using NOTIFY [9] and incremental transfer (IXFR) [8].
+   It increases when full zone transfers (AXFR) are used in combination
+   with NOTIFY.  It increases even more if you rely on full zone
+   transfers based on only the SOA timing parameters for refresh.
+
+   For the verifying clients, it is important that data from secured
+   zones can be used to build chains of trust regardless of whether the
+   data came directly from an authoritative server, a caching
+   nameserver, or some middle box.  Only by carefully using the
+   available timing parameters can a zone administrator ensure that the
+   data necessary for verification can be obtained.
+
+   The responsibility for maintaining the chain of trust is shared by
+   administrators of secured zones in the chain of trust.  This is most
+   obvious in the case of a 'key compromise' when a trade-off between
+   maintaining a valid chain of trust and replacing the compromised keys
+   as soon as possible must be made.  Then zone administrators will have
+   to make a trade-off, between keeping the chain of trust intact --
+   thereby allowing for attacks with the compromised key -- or
+   deliberately breaking the chain of trust and making secured
+   subdomains invisible to security-aware resolvers.  Also see Section
+   4.3.
+
+
+
+
+
+
+
+
+
+Kolkman & Gieben             Informational                      [Page 5]
+
+RFC 4641              DNSSEC Operational Practices        September 2006
+
+
+3.  Keys Generation and Storage
+
+   This section describes a number of considerations with respect to the
+   security of keys.  It deals with the generation, effectivity period,
+   size, and storage of private keys.
+
+3.1.  Zone and Key Signing Keys
+
+   The DNSSEC validation protocol does not distinguish between different
+   types of DNSKEYs.  All DNSKEYs can be used during the validation.  In
+   practice, operators use Key Signing and Zone Signing Keys and use the
+   so-called Secure Entry Point (SEP) [3] flag to distinguish between
+   them during operations.  The dynamics and considerations are
+   discussed below.
+
+   To make zone re-signing and key rollover procedures easier to
+   implement, it is possible to use one or more keys as Key Signing Keys
+   (KSKs).  These keys will only sign the apex DNSKEY RRSet in a zone.
+   Other keys can be used to sign all the RRSets in a zone and are
+   referred to as Zone Signing Keys (ZSKs).  In this document, we assume
+   that KSKs are the subset of keys that are used for key exchanges with
+   the parent and potentially for configuration as trusted anchors --
+   the SEP keys.  In this document, we assume a one-to-one mapping
+   between KSK and SEP keys and we assume the SEP flag to be set on all
+   KSKs.
+
+3.1.1.  Motivations for the KSK and ZSK Separation
+
+   Differentiating between the KSK and ZSK functions has several
+   advantages:
+
+   o  No parent/child interaction is required when ZSKs are updated.
+
+   o  The KSK can be made stronger (i.e., using more bits in the key
+      material).  This has little operational impact since it is only
+      used to sign a small fraction of the zone data.  Also, the KSK is
+      only used to verify the zone's key set, not for other RRSets in
+      the zone.
+
+   o  As the KSK is only used to sign a key set, which is most probably
+      updated less frequently than other data in the zone, it can be
+      stored separately from and in a safer location than the ZSK.
+
+   o  A KSK can have a longer key effectivity period.
+
+   For almost any method of key management and zone signing, the KSK is
+   used less frequently than the ZSK.  Once a key set is signed with the
+   KSK, all the keys in the key set can be used as ZSKs.  If a ZSK is
+
+
+
+Kolkman & Gieben             Informational                      [Page 6]
+
+RFC 4641              DNSSEC Operational Practices        September 2006
+
+
+   compromised, it can be simply dropped from the key set.  The new key
+   set is then re-signed with the KSK.
+
+   Given the assumption that for KSKs the SEP flag is set, the KSK can
+   be distinguished from a ZSK by examining the flag field in the DNSKEY
+   RR.  If the flag field is an odd number it is a KSK.  If it is an
+   even number it is a ZSK.
+
+   The Zone Signing Key can be used to sign all the data in a zone on a
+   regular basis.  When a Zone Signing Key is to be rolled, no
+   interaction with the parent is needed.  This allows for signature
+   validity periods on the order of days.
+
+   The Key Signing Key is only to be used to sign the DNSKEY RRs in a
+   zone.  If a Key Signing Key is to be rolled over, there will be
+   interactions with parties other than the zone administrator.  These
+   can include the registry of the parent zone or administrators of
+   verifying resolvers that have the particular key configured as secure
+   entry points.  Hence, the key effectivity period of these keys can
+   and should be made much longer.  Although, given a long enough key,
+   the key effectivity period can be on the order of years, we suggest
+   planning for a key effectivity on the order of a few months so that a
+   key rollover remains an operational routine.
+
+3.1.2.  KSKs for High-Level Zones
+
+   Higher-level zones are generally more sensitive than lower-level
+   zones.  Anyone controlling or breaking the security of a zone thereby
+   obtains authority over all of its subdomains (except in the case of
+   resolvers that have locally configured the public key of a subdomain,
+   in which case this, and only this, subdomain wouldn't be affected by
+   the compromise of the parent zone).  Therefore, extra care should be
+   taken with high-level zones, and strong keys should be used.
+
+   The root zone is the most critical of all zones.  Someone controlling
+   or compromising the security of the root zone would control the
+   entire DNS namespace of all resolvers using that root zone (except in
+   the case of resolvers that have locally configured the public key of
+   a subdomain).  Therefore, the utmost care must be taken in the
+   securing of the root zone.  The strongest and most carefully handled
+   keys should be used.  The root zone private key should always be kept
+   off-line.
+
+   Many resolvers will start at a root server for their access to and
+   authentication of DNS data.  Securely updating the trust anchors in
+   an enormous population of resolvers around the world will be
+   extremely difficult.
+
+
+
+
+Kolkman & Gieben             Informational                      [Page 7]
+
+RFC 4641              DNSSEC Operational Practices        September 2006
+
+
+3.2.  Key Generation
+
+   Careful generation of all keys is a sometimes overlooked but
+   absolutely essential element in any cryptographically secure system.
+   The strongest algorithms used with the longest keys are still of no
+   use if an adversary can guess enough to lower the size of the likely
+   key space so that it can be exhaustively searched.  Technical
+   suggestions for the generation of random keys will be found in RFC
+   4086 [14].  One should carefully assess if the random number
+   generator used during key generation adheres to these suggestions.
+
+   Keys with a long effectivity period are particularly sensitive as
+   they will represent a more valuable target and be subject to attack
+   for a longer time than short-period keys.  It is strongly recommended
+   that long-term key generation occur off-line in a manner isolated
+   from the network via an air gap or, at a minimum, high-level secure
+   hardware.
+
+3.3.  Key Effectivity Period
+
+   For various reasons, keys in DNSSEC need to be changed once in a
+   while.  The longer a key is in use, the greater the probability that
+   it will have been compromised through carelessness, accident,
+   espionage, or cryptanalysis.  Furthermore, when key rollovers are too
+   rare an event, they will not become part of the operational habit and
+   there is risk that nobody on-site will remember the procedure for
+   rollover when the need is there.
+
+   From a purely operational perspective, a reasonable key effectivity
+   period for Key Signing Keys is 13 months, with the intent to replace
+   them after 12 months.  An intended key effectivity period of a month
+   is reasonable for Zone Signing Keys.
+
+   For key sizes that match these effectivity periods, see Section 3.5.
+
+   As argued in Section 3.1.2, securely updating trust anchors will be
+   extremely difficult.  On the other hand, the "operational habit"
+   argument does also apply to trust anchor reconfiguration.  If a short
+   key effectivity period is used and the trust anchor configuration has
+   to be revisited on a regular basis, the odds that the configuration
+   tends to be forgotten is smaller.  The trade-off is against a system
+   that is so dynamic that administrators of the validating clients will
+   not be able to follow the modifications.
+
+   Key effectivity periods can be made very short, as in a few minutes.
+   But when replacing keys one has to take the considerations from
+   Section 4.1 and Section 4.2 into account.
+
+
+
+
+Kolkman & Gieben             Informational                      [Page 8]
+
+RFC 4641              DNSSEC Operational Practices        September 2006
+
+
+3.4.  Key Algorithm
+
+   There are currently three different types of algorithms that can be
+   used in DNSSEC: RSA, DSA, and elliptic curve cryptography.  The
+   latter is fairly new and has yet to be standardized for usage in
+   DNSSEC.
+
+   RSA has been developed in an open and transparent manner.  As the
+   patent on RSA expired in 2000, its use is now also free.
+
+   DSA has been developed by the National Institute of Standards and
+   Technology (NIST).  The creation of signatures takes roughly the same
+   time as with RSA, but is 10 to 40 times as slow for verification
+   [17].
+
+   We suggest the use of RSA/SHA-1 as the preferred algorithm for the
+   key.  The current known attacks on RSA can be defeated by making your
+   key longer.  As the MD5 hashing algorithm is showing cracks, we
+   recommend the usage of SHA-1.
+
+   At the time of publication, it is known that the SHA-1 hash has
+   cryptanalysis issues.  There is work in progress on addressing these
+   issues.  We recommend the use of public key algorithms based on
+   hashes stronger than SHA-1 (e.g., SHA-256), as soon as these
+   algorithms are available in protocol specifications (see [19] and
+   [20]) and implementations.
+
+3.5.  Key Sizes
+
+   When choosing key sizes, zone administrators will need to take into
+   account how long a key will be used, how much data will be signed
+   during the key publication period (see Section 8.10 of [17]), and,
+   optionally, how large the key size of the parent is.  As the chain of
+   trust really is "a chain", there is not much sense in making one of
+   the keys in the chain several times larger then the others.  As
+   always, it's the weakest link that defines the strength of the entire
+   chain.  Also see Section 3.1.1 for a discussion of how keys serving
+   different roles (ZSK vs. KSK) may need different key sizes.
+
+   Generating a key of the correct size is a difficult problem; RFC 3766
+   [13] tries to deal with that problem.  The first part of the
+   selection procedure in Section 1 of the RFC states:
+
+      1. Determine the attack resistance necessary to satisfy the
+         security requirements of the application.  Do this by
+         estimating the minimum number of computer operations that the
+         attacker will be forced to do in order to compromise the
+
+
+
+
+Kolkman & Gieben             Informational                      [Page 9]
+
+RFC 4641              DNSSEC Operational Practices        September 2006
+
+
+         security of the system and then take the logarithm base two of
+         that number.  Call that logarithm value "n".
+
+         A 1996 report recommended 90 bits as a good all-around choice
+         for system security.  The 90 bit number should be increased by
+         about 2/3 bit/year, or about 96 bits in 2005.
+
+   [13] goes on to explain how this number "n" can be used to calculate
+   the key sizes in public key cryptography.  This culminated in the
+   table given below (slightly modified for our purpose):
+
+      +-------------+-----------+--------------+
+      | System      |           |              |
+      | requirement | Symmetric | RSA or DSA   |
+      | for attack  | key size  | modulus size |
+      | resistance  | (bits)    | (bits)       |
+      | (bits)      |           |              |
+      +-------------+-----------+--------------+
+      |     70      |     70    |      947     |
+      |     80      |     80    |     1228     |
+      |     90      |     90    |     1553     |
+      |    100      |    100    |     1926     |
+      |    150      |    150    |     4575     |
+      |    200      |    200    |     8719     |
+      |    250      |    250    |    14596     |
+      +-------------+-----------+--------------+
+
+   The key sizes given are rather large.  This is because these keys are
+   resilient against a trillionaire attacker.  Assuming this rich
+   attacker will not attack your key and that the key is rolled over
+   once a year, we come to the following recommendations about KSK
+   sizes: 1024 bits for low-value domains, 1300 bits for medium-value
+   domains, and 2048 bits for high-value domains.
+
+   Whether a domain is of low, medium, or high value depends solely on
+   the views of the zone owner.  One could, for instance, view leaf
+   nodes in the DNS as of low value, and top-level domains (TLDs) or the
+   root zone of high value.  The suggested key sizes should be safe for
+   the next 5 years.
+
+   As ZSKs can be rolled over more easily (and thus more often), the key
+   sizes can be made smaller.  But as said in the introduction of this
+   paragraph, making the ZSKs' key sizes too small (in relation to the
+   KSKs' sizes) doesn't make much sense.  Try to limit the difference in
+   size to about 100 bits.
+
+
+
+
+
+
+Kolkman & Gieben             Informational                     [Page 10]
+
+RFC 4641              DNSSEC Operational Practices        September 2006
+
+
+   Note that nobody can see into the future and that these key sizes are
+   only provided here as a guide.  Further information can be found in
+   [16] and Section 7.5 of [17].  It should be noted though that [16] is
+   already considered overly optimistic about what key sizes are
+   considered safe.
+
+   One final note concerning key sizes.  Larger keys will increase the
+   sizes of the RRSIG and DNSKEY records and will therefore increase the
+   chance of DNS UDP packet overflow.  Also, the time it takes to
+   validate and create RRSIGs increases with larger keys, so don't
+   needlessly double your key sizes.
+
+3.6.  Private Key Storage
+
+   It is recommended that, where possible, zone private keys and the
+   zone file master copy that is to be signed be kept and used in off-
+   line, non-network-connected, physically secure machines only.
+   Periodically, an application can be run to add authentication to a
+   zone by adding RRSIG and NSEC RRs.  Then the augmented file can be
+   transferred.
+
+   When relying on dynamic update to manage a signed zone [10], be aware
+   that at least one private key of the zone will have to reside on the
+   master server.  This key is only as secure as the amount of exposure
+   the server receives to unknown clients and the security of the host.
+   Although not mandatory, one could administer the DNS in the following
+   way.  The master that processes the dynamic updates is unavailable
+   from generic hosts on the Internet, it is not listed in the NS RR
+   set, although its name appears in the SOA RRs MNAME field.  The
+   nameservers in the NS RRSet are able to receive zone updates through
+   NOTIFY, IXFR, AXFR, or an out-of-band distribution mechanism.  This
+   approach is known as the "hidden master" setup.
+
+   The ideal situation is to have a one-way information flow to the
+   network to avoid the possibility of tampering from the network.
+   Keeping the zone master file on-line on the network and simply
+   cycling it through an off-line signer does not do this.  The on-line
+   version could still be tampered with if the host it resides on is
+   compromised.  For maximum security, the master copy of the zone file
+   should be off-net and should not be updated based on an unsecured
+   network mediated communication.
+
+   In general, keeping a zone file off-line will not be practical and
+   the machines on which zone files are maintained will be connected to
+   a network.  Operators are advised to take security measures to shield
+   unauthorized access to the master copy.
+
+
+
+
+
+Kolkman & Gieben             Informational                     [Page 11]
+
+RFC 4641              DNSSEC Operational Practices        September 2006
+
+
+   For dynamically updated secured zones [10], both the master copy and
+   the private key that is used to update signatures on updated RRs will
+   need to be on-line.
+
+4.  Signature Generation, Key Rollover, and Related Policies
+
+4.1.  Time in DNSSEC
+
+   Without DNSSEC, all times in the DNS are relative.  The SOA fields
+   REFRESH, RETRY, and EXPIRATION are timers used to determine the time
+   elapsed after a slave server synchronized with a master server.  The
+   Time to Live (TTL) value and the SOA RR minimum TTL parameter [11]
+   are used to determine how long a forwarder should cache data after it
+   has been fetched from an authoritative server.  By using a signature
+   validity period, DNSSEC introduces the notion of an absolute time in
+   the DNS.  Signatures in DNSSEC have an expiration date after which
+   the signature is marked as invalid and the signed data is to be
+   considered Bogus.
+
+4.1.1.  Time Considerations
+
+   Because of the expiration of signatures, one should consider the
+   following:
+
+   o  We suggest the Maximum Zone TTL of your zone data to be a fraction
+      of your signature validity period.
+
+         If the TTL would be of similar order as the signature validity
+         period, then all RRSets fetched during the validity period
+         would be cached until the signature expiration time.  Section
+         7.1 of [4] suggests that "the resolver may use the time
+         remaining before expiration of the signature validity period of
+         a signed RRSet as an upper bound for the TTL".  As a result,
+         query load on authoritative servers would peak at signature
+         expiration time, as this is also the time at which records
+         simultaneously expire from caches.
+
+         To avoid query load peaks, we suggest the TTL on all the RRs in
+         your zone to be at least a few times smaller than your
+         signature validity period.
+
+   o  We suggest the signature publication period to end at least one
+      Maximum Zone TTL duration before the end of the signature validity
+      period.
+
+
+
+
+
+
+
+Kolkman & Gieben             Informational                     [Page 12]
+
+RFC 4641              DNSSEC Operational Practices        September 2006
+
+
+         Re-signing a zone shortly before the end of the signature
+         validity period may cause simultaneous expiration of data from
+         caches.  This in turn may lead to peaks in the load on
+         authoritative servers.
+
+   o  We suggest the Minimum Zone TTL to be long enough to both fetch
+      and verify all the RRs in the trust chain.  In workshop
+      environments, it has been demonstrated [18] that a low TTL (under
+      5 to 10 minutes) caused disruptions because of the following two
+      problems:
+
+         1.  During validation, some data may expire before the
+             validation is complete.  The validator should be able to
+             keep all data until it is completed.  This applies to all
+             RRs needed to complete the chain of trust: DSes, DNSKEYs,
+             RRSIGs, and the final answers, i.e., the RRSet that is
+             returned for the initial query.
+
+         2.  Frequent verification causes load on recursive nameservers.
+             Data at delegation points, DSes, DNSKEYs, and RRSIGs
+             benefit from caching.  The TTL on those should be
+             relatively long.
+
+   o  Slave servers will need to be able to fetch newly signed zones
+      well before the RRSIGs in the zone served by the slave server pass
+      their signature expiration time.
+
+         When a slave server is out of sync with its master and data in
+         a zone is signed by expired signatures, it may be better for
+         the slave server not to give out any answer.
+
+         Normally, a slave server that is not able to contact a master
+         server for an extended period will expire a zone.  When that
+         happens, the server will respond differently to queries for
+         that zone.  Some servers issue SERVFAIL, whereas others turn
+         off the 'AA' bit in the answers.  The time of expiration is set
+         in the SOA record and is relative to the last successful
+         refresh between the master and the slave servers.  There exists
+         no coupling between the signature expiration of RRSIGs in the
+         zone and the expire parameter in the SOA.
+
+         If the server serves a DNSSEC zone, then it may well happen
+         that the signatures expire well before the SOA expiration timer
+         counts down to zero.  It is not possible to completely prevent
+         this from happening by tweaking the SOA parameters.  However,
+         the effects can be minimized where the SOA expiration time is
+         equal to or shorter than the signature validity period.  The
+         consequence of an authoritative server not being able to update
+
+
+
+Kolkman & Gieben             Informational                     [Page 13]
+
+RFC 4641              DNSSEC Operational Practices        September 2006
+
+
+         a zone, whilst that zone includes expired signatures, is that
+         non-secure resolvers will continue to be able to resolve data
+         served by the particular slave servers while security-aware
+         resolvers will experience problems because of answers being
+         marked as Bogus.
+
+         We suggest the SOA expiration timer being approximately one
+         third or one fourth of the signature validity period.  It will
+         allow problems with transfers from the master server to be
+         noticed before the actual signature times out.  We also suggest
+         that operators of nameservers that supply secondary services
+         develop 'watch dogs' to spot upcoming signature expirations in
+         zones they slave, and take appropriate action.
+
+         When determining the value for the expiration parameter one has
+         to take the following into account: What are the chances that
+         all my secondaries expire the zone? How quickly can I reach an
+         administrator of secondary servers to load a valid zone?  These
+         questions are not DNSSEC specific but may influence the choice
+         of your signature validity intervals.
+
+4.2.  Key Rollovers
+
+   A DNSSEC key cannot be used forever (see Section 3.3).  So key
+   rollovers -- or supercessions, as they are sometimes called -- are a
+   fact of life when using DNSSEC.  Zone administrators who are in the
+   process of rolling their keys have to take into account that data
+   published in previous versions of their zone still lives in caches.
+   When deploying DNSSEC, this becomes an important consideration;
+   ignoring data that may be in caches may lead to loss of service for
+   clients.
+
+   The most pressing example of this occurs when zone material signed
+   with an old key is being validated by a resolver that does not have
+   the old zone key cached.  If the old key is no longer present in the
+   current zone, this validation fails, marking the data "Bogus".
+   Alternatively, an attempt could be made to validate data that is
+   signed with a new key against an old key that lives in a local cache,
+   also resulting in data being marked "Bogus".
+
+4.2.1.  Zone Signing Key Rollovers
+
+   For "Zone Signing Key rollovers", there are two ways to make sure
+   that during the rollover data still cached can be verified with the
+   new key sets or newly generated signatures can be verified with the
+   keys still in caches.  One schema, described in Section 4.2.1.2, uses
+
+
+
+
+
+Kolkman & Gieben             Informational                     [Page 14]
+
+RFC 4641              DNSSEC Operational Practices        September 2006
+
+
+   double signatures; the other uses key pre-publication (Section
+   4.2.1.1).  The pros, cons, and recommendations are described in
+   Section 4.2.1.3.
+
+4.2.1.1.  Pre-Publish Key Rollover
+
+   This section shows how to perform a ZSK rollover without the need to
+   sign all the data in a zone twice -- the "pre-publish key rollover".
+   This method has advantages in the case of a key compromise.  If the
+   old key is compromised, the new key has already been distributed in
+   the DNS.  The zone administrator is then able to quickly switch to
+   the new key and remove the compromised key from the zone.  Another
+   major advantage is that the zone size does not double, as is the case
+   with the double signature ZSK rollover.  A small "how-to" for this
+   kind of rollover can be found in Appendix B.
+
+   Pre-publish key rollover involves four stages as follows:
+
+      ----------------------------------------------------------------
+      initial         new DNSKEY       new RRSIGs      DNSKEY removal
+      ----------------------------------------------------------------
+      SOA0            SOA1             SOA2            SOA3
+      RRSIG10(SOA0)   RRSIG10(SOA1)    RRSIG11(SOA2)   RRSIG11(SOA3)
+
+      DNSKEY1         DNSKEY1          DNSKEY1         DNSKEY1
+      DNSKEY10        DNSKEY10         DNSKEY10        DNSKEY11
+      DNSKEY11         DNSKEY11
+      RRSIG1 (DNSKEY) RRSIG1 (DNSKEY)  RRSIG1(DNSKEY)  RRSIG1 (DNSKEY)
+      RRSIG10(DNSKEY) RRSIG10(DNSKEY)  RRSIG11(DNSKEY) RRSIG11(DNSKEY)
+      ----------------------------------------------------------------
+
+                         Pre-Publish Key Rollover
+
+   initial: Initial version of the zone: DNSKEY 1 is the Key Signing
+      Key.  DNSKEY 10 is used to sign all the data of the zone, the Zone
+      Signing Key.
+
+   new DNSKEY: DNSKEY 11 is introduced into the key set.  Note that no
+      signatures are generated with this key yet, but this does not
+      secure against brute force attacks on the public key.  The minimum
+      duration of this pre-roll phase is the time it takes for the data
+      to propagate to the authoritative servers plus TTL value of the
+      key set.
+
+   new RRSIGs: At the "new RRSIGs" stage (SOA serial 2), DNSKEY 11 is
+      used to sign the data in the zone exclusively (i.e., all the
+      signatures from DNSKEY 10 are removed from the zone).  DNSKEY 10
+      remains published in the key set.  This way data that was loaded
+
+
+
+Kolkman & Gieben             Informational                     [Page 15]
+
+RFC 4641              DNSSEC Operational Practices        September 2006
+
+
+      into caches from version 1 of the zone can still be verified with
+      key sets fetched from version 2 of the zone.  The minimum time
+      that the key set including DNSKEY 10 is to be published is the
+      time that it takes for zone data from the previous version of the
+      zone to expire from old caches, i.e., the time it takes for this
+      zone to propagate to all authoritative servers plus the Maximum
+      Zone TTL value of any of the data in the previous version of the
+      zone.
+
+   DNSKEY removal: DNSKEY 10 is removed from the zone.  The key set, now
+      only containing DNSKEY 1 and DNSKEY 11, is re-signed with the
+      DNSKEY 1.
+
+   The above scheme can be simplified by always publishing the "future"
+   key immediately after the rollover.  The scheme would look as follows
+   (we show two rollovers); the future key is introduced in "new DNSKEY"
+   as DNSKEY 12 and again a newer one, numbered 13, in "new DNSKEY
+   (II)":
+
+      ----------------------------------------------------------------
+      initial             new RRSIGs          new DNSKEY
+      ----------------------------------------------------------------
+      SOA0                SOA1                SOA2
+      RRSIG10(SOA0)       RRSIG11(SOA1)       RRSIG11(SOA2)
+
+      DNSKEY1             DNSKEY1             DNSKEY1
+      DNSKEY10            DNSKEY10            DNSKEY11
+      DNSKEY11            DNSKEY11            DNSKEY12
+      RRSIG1(DNSKEY)      RRSIG1 (DNSKEY)     RRSIG1(DNSKEY)
+      RRSIG10(DNSKEY)     RRSIG11(DNSKEY)     RRSIG11(DNSKEY)
+      ----------------------------------------------------------------
+
+      ----------------------------------------------------------------
+      new RRSIGs (II)     new DNSKEY (II)
+      ----------------------------------------------------------------
+      SOA3                SOA4
+      RRSIG12(SOA3)       RRSIG12(SOA4)
+
+      DNSKEY1             DNSKEY1
+      DNSKEY11            DNSKEY12
+      DNSKEY12            DNSKEY13
+      RRSIG1(DNSKEY)      RRSIG1(DNSKEY)
+      RRSIG12(DNSKEY)     RRSIG12(DNSKEY)
+      ----------------------------------------------------------------
+
+              Pre-Publish Key Rollover, Showing Two Rollovers
+
+
+
+
+
+Kolkman & Gieben             Informational                     [Page 16]
+
+RFC 4641              DNSSEC Operational Practices        September 2006
+
+
+   Note that the key introduced in the "new DNSKEY" phase is not used
+   for production yet; the private key can thus be stored in a
+   physically secure manner and does not need to be 'fetched' every time
+   a zone needs to be signed.
+
+4.2.1.2.  Double Signature Zone Signing Key Rollover
+
+   This section shows how to perform a ZSK key rollover using the double
+   zone data signature scheme, aptly named "double signature rollover".
+
+   During the "new DNSKEY" stage the new version of the zone file will
+   need to propagate to all authoritative servers and the data that
+   exists in (distant) caches will need to expire, requiring at least
+   the Maximum Zone TTL.
+
+   Double signature ZSK rollover involves three stages as follows:
+
+      ----------------------------------------------------------------
+      initial             new DNSKEY         DNSKEY removal
+      ----------------------------------------------------------------
+      SOA0                SOA1               SOA2
+      RRSIG10(SOA0)       RRSIG10(SOA1)      RRSIG11(SOA2)
+      RRSIG11(SOA1)
+
+      DNSKEY1             DNSKEY1            DNSKEY1
+      DNSKEY10            DNSKEY10           DNSKEY11
+      DNSKEY11
+      RRSIG1(DNSKEY)      RRSIG1(DNSKEY)     RRSIG1(DNSKEY)
+      RRSIG10(DNSKEY)     RRSIG10(DNSKEY)    RRSIG11(DNSKEY)
+      RRSIG11(DNSKEY)
+      ----------------------------------------------------------------
+
+                Double Signature Zone Signing Key Rollover
+
+   initial: Initial Version of the zone: DNSKEY 1 is the Key Signing
+      Key.  DNSKEY 10 is used to sign all the data of the zone, the Zone
+      Signing Key.
+
+   new DNSKEY: At the "New DNSKEY" stage (SOA serial 1) DNSKEY 11 is
+      introduced into the key set and all the data in the zone is signed
+      with DNSKEY 10 and DNSKEY 11.  The rollover period will need to
+      continue until all data from version 0 of the zone has expired
+      from remote caches.  This will take at least the Maximum Zone TTL
+      of version 0 of the zone.
+
+   DNSKEY removal: DNSKEY 10 is removed from the zone.  All the
+      signatures from DNSKEY 10 are removed from the zone.  The key set,
+      now only containing DNSKEY 11, is re-signed with DNSKEY 1.
+
+
+
+Kolkman & Gieben             Informational                     [Page 17]
+
+RFC 4641              DNSSEC Operational Practices        September 2006
+
+
+   At every instance, RRSIGs from the previous version of the zone can
+   be verified with the DNSKEY RRSet from the current version and the
+   other way around.  The data from the current version can be verified
+   with the data from the previous version of the zone.  The duration of
+   the "new DNSKEY" phase and the period between rollovers should be at
+   least the Maximum Zone TTL.
+
+   Making sure that the "new DNSKEY" phase lasts until the signature
+   expiration time of the data in initial version of the zone is
+   recommended.  This way all caches are cleared of the old signatures.
+   However, this duration could be considerably longer than the Maximum
+   Zone TTL, making the rollover a lengthy procedure.
+
+   Note that in this example we assumed that the zone was not modified
+   during the rollover.  New data can be introduced in the zone as long
+   as it is signed with both keys.
+
+4.2.1.3.  Pros and Cons of the Schemes
+
+   Pre-publish key rollover: This rollover does not involve signing the
+      zone data twice.  Instead, before the actual rollover, the new key
+      is published in the key set and thus is available for
+      cryptanalysis attacks.  A small disadvantage is that this process
+      requires four steps.  Also the pre-publish scheme involves more
+      parental work when used for KSK rollovers as explained in Section
+      4.2.3.
+
+   Double signature ZSK rollover: The drawback of this signing scheme is
+      that during the rollover the number of signatures in your zone
+      doubles; this may be prohibitive if you have very big zones.  An
+      advantage is that it only requires three steps.
+
+4.2.2.  Key Signing Key Rollovers
+
+   For the rollover of a Key Signing Key, the same considerations as for
+   the rollover of a Zone Signing Key apply.  However, we can use a
+   double signature scheme to guarantee that old data (only the apex key
+   set) in caches can be verified with a new key set and vice versa.
+   Since only the key set is signed with a KSK, zone size considerations
+   do not apply.
+
+
+
+
+
+
+
+
+
+
+
+Kolkman & Gieben             Informational                     [Page 18]
+
+RFC 4641              DNSSEC Operational Practices        September 2006
+
+
+   --------------------------------------------------------------------
+       initial        new DNSKEY        DS change       DNSKEY removal
+   --------------------------------------------------------------------
+     Parent:
+       SOA0           -------->         SOA1            -------->
+       RRSIGpar(SOA0) -------->         RRSIGpar(SOA1)  -------->
+       DS1            -------->         DS2             -------->
+       RRSIGpar(DS)   -------->         RRSIGpar(DS)    -------->
+
+
+     Child:
+       SOA0            SOA1             -------->       SOA2
+       RRSIG10(SOA0)   RRSIG10(SOA1)    -------->       RRSIG10(SOA2)
+                                        -------->
+       DNSKEY1         DNSKEY1          -------->       DNSKEY2
+                       DNSKEY2          -------->
+       DNSKEY10        DNSKEY10         -------->       DNSKEY10
+       RRSIG1 (DNSKEY) RRSIG1 (DNSKEY)  -------->       RRSIG2 (DNSKEY)
+                       RRSIG2 (DNSKEY)  -------->
+       RRSIG10(DNSKEY) RRSIG10(DNSKEY)  -------->       RRSIG10(DNSKEY)
+   --------------------------------------------------------------------
+
+   Stages of Deployment for a Double Signature Key Signing Key Rollover
+
+   initial: Initial version of the zone.  The parental DS points to
+      DNSKEY1.  Before the rollover starts, the child will have to
+      verify what the TTL is of the DS RR that points to DNSKEY1 -- it
+      is needed during the rollover and we refer to the value as TTL_DS.
+
+   new DNSKEY: During the "new DNSKEY" phase, the zone administrator
+      generates a second KSK, DNSKEY2.  The key is provided to the
+      parent, and the child will have to wait until a new DS RR has been
+      generated that points to DNSKEY2.  After that DS RR has been
+      published on all servers authoritative for the parent's zone, the
+      zone administrator has to wait at least TTL_DS to make sure that
+      the old DS RR has expired from caches.
+
+   DS change: The parent replaces DS1 with DS2.
+
+   DNSKEY removal: DNSKEY1 has been removed.
+
+   The scenario above puts the responsibility for maintaining a valid
+   chain of trust with the child.  It also is based on the premise that
+   the parent only has one DS RR (per algorithm) per zone.  An
+   alternative mechanism has been considered.  Using an established
+   trust relation, the interaction can be performed in-band, and the
+   removal of the keys by the child can possibly be signaled by the
+   parent.  In this mechanism, there are periods where there are two DS
+
+
+
+Kolkman & Gieben             Informational                     [Page 19]
+
+RFC 4641              DNSSEC Operational Practices        September 2006
+
+
+   RRs at the parent.  Since at the moment of writing the protocol for
+   this interaction has not been developed, further discussion is out of
+   scope for this document.
+
+4.2.3.  Difference Between ZSK and KSK Rollovers
+
+   Note that KSK rollovers and ZSK rollovers are different in the sense
+   that a KSK rollover requires interaction with the parent (and
+   possibly replacing of trust anchors) and the ensuing delay while
+   waiting for it.
+
+   A zone key rollover can be handled in two different ways: pre-publish
+   (Section 4.2.1.1) and double signature (Section 4.2.1.2).
+
+   As the KSK is used to validate the key set and because the KSK is not
+   changed during a ZSK rollover, a cache is able to validate the new
+   key set of the zone.  The pre-publish method would also work for a
+   KSK rollover.  The records that are to be pre-published are the
+   parental DS RRs.  The pre-publish method has some drawbacks for KSKs.
+   We first describe the rollover scheme and then indicate these
+   drawbacks.
+
+   --------------------------------------------------------------------
+     initial         new DS           new DNSKEY      DS/DNSKEY removal
+   --------------------------------------------------------------------
+   Parent:
+     SOA0            SOA1             -------->       SOA2
+     RRSIGpar(SOA0)  RRSIGpar(SOA1)   -------->       RRSIGpar(SOA2)
+     DS1             DS1              -------->       DS2
+                     DS2              -------->
+     RRSIGpar(DS)    RRSIGpar(DS)     -------->       RRSIGpar(DS)
+
+
+   Child:
+     SOA0            -------->        SOA1            SOA1
+     RRSIG10(SOA0)   -------->        RRSIG10(SOA1)   RRSIG10(SOA1)
+                     -------->
+     DNSKEY1         -------->        DNSKEY2         DNSKEY2
+                     -------->
+     DNSKEY10        -------->        DNSKEY10        DNSKEY10
+     RRSIG1 (DNSKEY) -------->        RRSIG2(DNSKEY)  RRSIG2 (DNSKEY)
+     RRSIG10(DNSKEY) -------->        RRSIG10(DNSKEY) RRSIG10(DNSKEY)
+   --------------------------------------------------------------------
+
+      Stages of Deployment for a Pre-Publish Key Signing Key Rollover
+
+
+
+
+
+
+Kolkman & Gieben             Informational                     [Page 20]
+
+RFC 4641              DNSSEC Operational Practices        September 2006
+
+
+   When the child zone wants to roll, it notifies the parent during the
+   "new DS" phase and submits the new key (or the corresponding DS) to
+   the parent.  The parent publishes DS1 and DS2, pointing to DNSKEY1
+   and DNSKEY2, respectively.  During the rollover ("new DNSKEY" phase),
+   which can take place as soon as the new DS set propagated through the
+   DNS, the child replaces DNSKEY1 with DNSKEY2.  Immediately after that
+   ("DS/DNSKEY removal" phase), it can notify the parent that the old DS
+   record can be deleted.
+
+   The drawbacks of this scheme are that during the "new DS" phase the
+   parent cannot verify the match between the DS2 RR and DNSKEY2 using
+   the DNS -- as DNSKEY2 is not yet published.  Besides, we introduce a
+   "security lame" key (see Section 4.4.3).  Finally, the child-parent
+   interaction consists of two steps.  The "double signature" method
+   only needs one interaction.
+
+4.2.4.  Automated Key Rollovers
+
+   As keys must be renewed periodically, there is some motivation to
+   automate the rollover process.  Consider the following:
+
+   o  ZSK rollovers are easy to automate as only the child zone is
+      involved.
+
+   o  A KSK rollover needs interaction between parent and child.  Data
+      exchange is needed to provide the new keys to the parent;
+      consequently, this data must be authenticated and integrity must
+      be guaranteed in order to avoid attacks on the rollover.
+
+4.3.  Planning for Emergency Key Rollover
+
+   This section deals with preparation for a possible key compromise.
+   Our advice is to have a documented procedure ready for when a key
+   compromise is suspected or confirmed.
+
+   When the private material of one of your keys is compromised it can
+   be used for as long as a valid trust chain exists.  A trust chain
+   remains intact for
+
+   o  as long as a signature over the compromised key in the trust chain
+      is valid,
+
+   o  as long as a parental DS RR (and signature) points to the
+      compromised key,
+
+   o  as long as the key is anchored in a resolver and is used as a
+      starting point for validation (this is generally the hardest to
+      update).
+
+
+
+Kolkman & Gieben             Informational                     [Page 21]
+
+RFC 4641              DNSSEC Operational Practices        September 2006
+
+
+   While a trust chain to your compromised key exists, your namespace is
+   vulnerable to abuse by anyone who has obtained illegitimate
+   possession of the key.  Zone operators have to make a trade-off if
+   the abuse of the compromised key is worse than having data in caches
+   that cannot be validated.  If the zone operator chooses to break the
+   trust chain to the compromised key, data in caches signed with this
+   key cannot be validated.  However, if the zone administrator chooses
+   to take the path of a regular rollover, the malicious key holder can
+   spoof data so that it appears to be valid.
+
+4.3.1.  KSK Compromise
+
+   A zone containing a DNSKEY RRSet with a compromised KSK is vulnerable
+   as long as the compromised KSK is configured as trust anchor or a
+   parental DS points to it.
+
+   A compromised KSK can be used to sign the key set of an attacker's
+   zone.  That zone could be used to poison the DNS.
+
+   Therefore, when the KSK has been compromised, the trust anchor or the
+   parental DS should be replaced as soon as possible.  It is local
+   policy whether to break the trust chain during the emergency
+   rollover.  The trust chain would be broken when the compromised KSK
+   is removed from the child's zone while the parent still has a DS
+   pointing to the compromised KSK (the assumption is that there is only
+   one DS at the parent.  If there are multiple DSes this does not apply
+   -- however the chain of trust of this particular key is broken).
+
+   Note that an attacker's zone still uses the compromised KSK and the
+   presence of a parental DS would cause the data in this zone to appear
+   as valid.  Removing the compromised key would cause the attacker's
+   zone to appear as valid and the child's zone as Bogus.  Therefore, we
+   advise not to remove the KSK before the parent has a DS to a new KSK
+   in place.
+
+4.3.1.1.  Keeping the Chain of Trust Intact
+
+   If we follow this advice, the timing of the replacement of the KSK is
+   somewhat critical.  The goal is to remove the compromised KSK as soon
+   as the new DS RR is available at the parent.  And also make sure that
+   the signature made with a new KSK over the key set with the
+   compromised KSK in it expires just after the new DS appears at the
+   parent, thus removing the old cruft in one swoop.
+
+   The procedure is as follows:
+
+   1.  Introduce a new KSK into the key set, keep the compromised KSK in
+       the key set.
+
+
+
+Kolkman & Gieben             Informational                     [Page 22]
+
+RFC 4641              DNSSEC Operational Practices        September 2006
+
+
+   2.  Sign the key set, with a short validity period.  The validity
+       period should expire shortly after the DS is expected to appear
+       in the parent and the old DSes have expired from caches.
+
+   3.  Upload the DS for this new key to the parent.
+
+   4.  Follow the procedure of the regular KSK rollover: Wait for the DS
+       to appear in the authoritative servers and then wait as long as
+       the TTL of the old DS RRs.  If necessary re-sign the DNSKEY RRSet
+       and modify/extend the expiration time.
+
+   5.  Remove the compromised DNSKEY RR from the zone and re-sign the
+       key set using your "normal" validity interval.
+
+   An additional danger of a key compromise is that the compromised key
+   could be used to facilitate a legitimate DNSKEY/DS rollover and/or
+   nameserver changes at the parent.  When that happens, the domain may
+   be in dispute.  An authenticated out-of-band and secure notify
+   mechanism to contact a parent is needed in this case.
+
+   Note that this is only a problem when the DNSKEY and or DS records
+   are used for authentication at the parent.
+
+4.3.1.2.  Breaking the Chain of Trust
+
+   There are two methods to break the chain of trust.  The first method
+   causes the child zone to appear 'Bogus' to validating resolvers.  The
+   other causes the child zone to appear 'insecure'.  These are
+   described below.
+
+   In the method that causes the child zone to appear 'Bogus' to
+   validating resolvers, the child zone replaces the current KSK with a
+   new one and re-signs the key set.  Next it sends the DS of the new
+   key to the parent.  Only after the parent has placed the new DS in
+   the zone is the child's chain of trust repaired.
+
+   An alternative method of breaking the chain of trust is by removing
+   the DS RRs from the parent zone altogether.  As a result, the child
+   zone would become insecure.
+
+4.3.2.  ZSK Compromise
+
+   Primarily because there is no parental interaction required when a
+   ZSK is compromised, the situation is less severe than with a KSK
+   compromise.  The zone must still be re-signed with a new ZSK as soon
+   as possible.  As this is a local operation and requires no
+   communication between the parent and child, this can be achieved
+   fairly quickly.  However, one has to take into account that just as
+
+
+
+Kolkman & Gieben             Informational                     [Page 23]
+
+RFC 4641              DNSSEC Operational Practices        September 2006
+
+
+   with a normal rollover the immediate disappearance of the old
+   compromised key may lead to verification problems.  Also note that as
+   long as the RRSIG over the compromised ZSK is not expired the zone
+   may be still at risk.
+
+4.3.3.  Compromises of Keys Anchored in Resolvers
+
+   A key can also be pre-configured in resolvers.  For instance, if
+   DNSSEC is successfully deployed the root key may be pre-configured in
+   most security aware resolvers.
+
+   If trust-anchor keys are compromised, the resolvers using these keys
+   should be notified of this fact.  Zone administrators may consider
+   setting up a mailing list to communicate the fact that a SEP key is
+   about to be rolled over.  This communication will of course need to
+   be authenticated, e.g., by using digital signatures.
+
+   End-users faced with the task of updating an anchored key should
+   always validate the new key.  New keys should be authenticated out-
+   of-band, for example, through the use of an announcement website that
+   is secured using secure sockets (TLS) [21].
+
+4.4.  Parental Policies
+
+4.4.1.  Initial Key Exchanges and Parental Policies Considerations
+
+   The initial key exchange is always subject to the policies set by the
+   parent.  When designing a key exchange policy one should take into
+   account that the authentication and authorization mechanisms used
+   during a key exchange should be as strong as the authentication and
+   authorization mechanisms used for the exchange of delegation
+   information between parent and child.  That is, there is no implicit
+   need in DNSSEC to make the authentication process stronger than it
+   was in DNS.
+
+   Using the DNS itself as the source for the actual DNSKEY material,
+   with an out-of-band check on the validity of the DNSKEY, has the
+   benefit that it reduces the chances of user error.  A DNSKEY query
+   tool can make use of the SEP bit [3] to select the proper key from a
+   DNSSEC key set, thereby reducing the chance that the wrong DNSKEY is
+   sent.  It can validate the self-signature over a key; thereby
+   verifying the ownership of the private key material.  Fetching the
+   DNSKEY from the DNS ensures that the chain of trust remains intact
+   once the parent publishes the DS RR indicating the child is secure.
+
+   Note: the out-of-band verification is still needed when the key
+   material is fetched via the DNS.  The parent can never be sure
+   whether or not the DNSKEY RRs have been spoofed.
+
+
+
+Kolkman & Gieben             Informational                     [Page 24]
+
+RFC 4641              DNSSEC Operational Practices        September 2006
+
+
+4.4.2.  Storing Keys or Hashes?
+
+   When designing a registry system one should consider which of the
+   DNSKEYs and/or the corresponding DSes to store.  Since a child zone
+   might wish to have a DS published using a message digest algorithm
+   not yet understood by the registry, the registry can't count on being
+   able to generate the DS record from a raw DNSKEY.  Thus, we recommend
+   that registry systems at least support storing DS records.
+
+   It may also be useful to store DNSKEYs, since having them may help
+   during troubleshooting and, as long as the child's chosen message
+   digest is supported, the overhead of generating DS records from them
+   is minimal.  Having an out-of-band mechanism, such as a registry
+   directory (e.g., Whois), to find out which keys are used to generate
+   DS Resource Records for specific owners and/or zones may also help
+   with troubleshooting.
+
+   The storage considerations also relate to the design of the customer
+   interface and the method by which data is transferred between
+   registrant and registry; Will the child zone administrator be able to
+   upload DS RRs with unknown hash algorithms or does the interface only
+   allow DNSKEYs?  In the registry-registrar model, one can use the
+   DNSSEC extensions to the Extensible Provisioning Protocol (EPP) [15],
+   which allows transfer of DS RRs and optionally DNSKEY RRs.
+
+4.4.3.  Security Lameness
+
+   Security lameness is defined as what happens when a parent has a DS
+   RR pointing to a non-existing DNSKEY RR.  When this happens, the
+   child's zone may be marked "Bogus" by verifying DNS clients.
+
+   As part of a comprehensive delegation check, the parent could, at key
+   exchange time, verify that the child's key is actually configured in
+   the DNS.  However, if a parent does not understand the hashing
+   algorithm used by child, the parental checks are limited to only
+   comparing the key id.
+
+   Child zones should be very careful in removing DNSKEY material,
+   specifically SEP keys, for which a DS RR exists.
+
+   Once a zone is "security lame", a fix (e.g., removing a DS RR) will
+   take time to propagate through the DNS.
+
+
+
+
+
+
+
+
+
+Kolkman & Gieben             Informational                     [Page 25]
+
+RFC 4641              DNSSEC Operational Practices        September 2006
+
+
+4.4.4.  DS Signature Validity Period
+
+   Since the DS can be replayed as long as it has a valid signature, a
+   short signature validity period over the DS minimizes the time a
+   child is vulnerable in the case of a compromise of the child's
+   KSK(s).  A signature validity period that is too short introduces the
+   possibility that a zone is marked "Bogus" in case of a configuration
+   error in the signer.  There may not be enough time to fix the
+   problems before signatures expire.  Something as mundane as operator
+   unavailability during weekends shows the need for DS signature
+   validity periods longer than 2 days.  We recommend an absolute
+   minimum for a DS signature validity period of a few days.
+
+   The maximum signature validity period of the DS record depends on how
+   long child zones are willing to be vulnerable after a key compromise.
+   On the other hand, shortening the DS signature validity interval
+   increases the operational risk for the parent.  Therefore, the parent
+   may have policy to use a signature validity interval that is
+   considerably longer than the child would hope for.
+
+   A compromise between the operational constraints of the parent and
+   minimizing damage for the child may result in a DS signature validity
+   period somewhere between a week and months.
+
+   In addition to the signature validity period, which sets a lower
+   bound on the number of times the zone owner will need to sign the
+   zone data and which sets an upper bound to the time a child is
+   vulnerable after key compromise, there is the TTL value on the DS
+   RRs.  Shortening the TTL means that the authoritative servers will
+   see more queries.  But on the other hand, a short TTL lowers the
+   persistence of DS RRSets in caches thereby increasing the speed with
+   which updated DS RRSets propagate through the DNS.
+
+5.  Security Considerations
+
+   DNSSEC adds data integrity to the DNS.  This document tries to assess
+   the operational considerations to maintain a stable and secure DNSSEC
+   service.  Not taking into account the 'data propagation' properties
+   in the DNS will cause validation failures and may make secured zones
+   unavailable to security-aware resolvers.
+
+6.  Acknowledgments
+
+   Most of the ideas in this document were the result of collective
+   efforts during workshops, discussions, and tryouts.
+
+   At the risk of forgetting individuals who were the original
+   contributors of the ideas, we would like to acknowledge people who
+
+
+
+Kolkman & Gieben             Informational                     [Page 26]
+
+RFC 4641              DNSSEC Operational Practices        September 2006
+
+
+   were actively involved in the compilation of this document.  In
+   random order: Rip Loomis, Olafur Gudmundsson, Wesley Griffin, Michael
+   Richardson, Scott Rose, Rick van Rein, Tim McGinnis, Gilles Guette
+   Olivier Courtay, Sam Weiler, Jelte Jansen, Niall O'Reilly, Holger
+   Zuleger, Ed Lewis, Hilarie Orman, Marcos Sanz, and Peter Koch.
+
+   Some material in this document has been copied from RFC 2541 [12].
+
+   Mike StJohns designed the key exchange between parent and child
+   mentioned in the last paragraph of Section 4.2.2
+
+   Section 4.2.4 was supplied by G. Guette and O. Courtay.
+
+   Emma Bretherick, Adrian Bedford, and Lindy Foster corrected many of
+   the spelling and style issues.
+
+   Kolkman and Gieben take the blame for introducing all miscakes (sic).
+
+   While working on this document, Kolkman was employed by the RIPE NCC
+   and Gieben was employed by NLnet Labs.
+
+7.  References
+
+7.1.  Normative References
+
+   [1]   Mockapetris, P., "Domain names - concepts and facilities", STD
+         13, RFC 1034, November 1987.
+
+   [2]   Mockapetris, P., "Domain names - implementation and
+         specification", STD 13, RFC 1035, November 1987.
+
+   [3]   Kolkman, O., Schlyter, J., and E. Lewis, "Domain Name System
+         KEY (DNSKEY) Resource Record (RR) Secure Entry Point (SEP)
+         Flag", RFC 3757, May 2004.
+
+   [4]   Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+         "DNS Security Introduction and Requirements", RFC 4033, March
+         2005.
+
+   [5]   Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+         "Resource Records for the DNS Security Extensions", RFC 4034,
+         March 2005.
+
+   [6]   Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+         "Protocol Modifications for the DNS Security Extensions", RFC
+         4035, March 2005.
+
+
+
+
+
+Kolkman & Gieben             Informational                     [Page 27]
+
+RFC 4641              DNSSEC Operational Practices        September 2006
+
+
+7.2.  Informative References
+
+   [7]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
+         Levels", BCP 14, RFC 2119, March 1997.
+
+   [8]   Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, August
+         1996.
+
+   [9]   Vixie, P., "A Mechanism for Prompt Notification of Zone Changes
+         (DNS NOTIFY)", RFC 1996, August 1996.
+
+   [10]  Wellington, B., "Secure Domain Name System (DNS) Dynamic
+         Update", RFC 3007, November 2000.
+
+   [11]  Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)",
+         RFC 2308, March 1998.
+
+   [12]  Eastlake, D., "DNS Security Operational Considerations", RFC
+         2541, March 1999.
+
+   [13]  Orman, H. and P. Hoffman, "Determining Strengths For Public
+         Keys Used For Exchanging Symmetric Keys", BCP 86, RFC 3766,
+         April 2004.
+
+   [14]  Eastlake, D., Schiller, J., and S. Crocker, "Randomness
+         Requirements for Security", BCP 106, RFC 4086, June 2005.
+
+   [15]  Hollenbeck, S., "Domain Name System (DNS) Security Extensions
+         Mapping for the Extensible Provisioning Protocol (EPP)", RFC
+         4310, December 2005.
+
+   [16]  Lenstra, A. and E. Verheul, "Selecting Cryptographic Key
+         Sizes", The Journal of Cryptology 14 (255-293), 2001.
+
+   [17]  Schneier, B., "Applied Cryptography: Protocols, Algorithms, and
+         Source Code in C", ISBN (hardcover) 0-471-12845-7, ISBN
+         (paperback) 0-471-59756-2, Published by John Wiley & Sons Inc.,
+         1996.
+
+   [18]  Rose, S., "NIST DNSSEC workshop notes", June 2001.
+
+   [19]  Jansen, J., "Use of RSA/SHA-256 DNSKEY and RRSIG Resource
+         Records in DNSSEC", Work in Progress, January 2006.
+
+   [20]  Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer (DS)
+         Resource Records (RRs)", RFC 4509, May 2006.
+
+
+
+
+
+Kolkman & Gieben             Informational                     [Page 28]
+
+RFC 4641              DNSSEC Operational Practices        September 2006
+
+
+   [21]  Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and
+         T. Wright, "Transport Layer Security (TLS) Extensions", RFC
+         4366, April 2006.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kolkman & Gieben             Informational                     [Page 29]
+
+RFC 4641              DNSSEC Operational Practices        September 2006
+
+
+Appendix A.  Terminology
+
+   In this document, there is some jargon used that is defined in other
+   documents.  In most cases, we have not copied the text from the
+   documents defining the terms but have given a more elaborate
+   explanation of the meaning.  Note that these explanations should not
+   be seen as authoritative.
+
+   Anchored key: A DNSKEY configured in resolvers around the globe.
+      This key is hard to update, hence the term anchored.
+
+   Bogus: Also see Section 5 of [4].  An RRSet in DNSSEC is marked
+      "Bogus" when a signature of an RRSet does not validate against a
+      DNSKEY.
+
+   Key Signing Key or KSK: A Key Signing Key (KSK) is a key that is used
+      exclusively for signing the apex key set.  The fact that a key is
+      a KSK is only relevant to the signing tool.
+
+   Key size: The term 'key size' can be substituted by 'modulus size'
+      throughout the document.  It is mathematically more correct to use
+      modulus size, but as this is a document directed at operators we
+      feel more at ease with the term key size.
+
+   Private and public keys: DNSSEC secures the DNS through the use of
+      public key cryptography.  Public key cryptography is based on the
+      existence of two (mathematically related) keys, a public key and a
+      private key.  The public keys are published in the DNS by use of
+      the DNSKEY Resource Record (DNSKEY RR).  Private keys should
+      remain private.
+
+   Key rollover: A key rollover (also called key supercession in some
+      environments) is the act of replacing one key pair with another at
+      the end of a key effectivity period.
+
+   Secure Entry Point (SEP) key: A KSK that has a parental DS record
+      pointing to it or is configured as a trust anchor.  Although not
+      required by the protocol, we recommend that the SEP flag [3] is
+      set on these keys.
+
+   Self-signature: This only applies to signatures over DNSKEYs; a
+      signature made with DNSKEY x, over DNSKEY x is called a self-
+      signature.  Note: without further information, self-signatures
+      convey no trust.  They are useful to check the authenticity of the
+      DNSKEY, i.e., they can be used as a hash.
+
+
+
+
+
+
+Kolkman & Gieben             Informational                     [Page 30]
+
+RFC 4641              DNSSEC Operational Practices        September 2006
+
+
+   Singing the zone file: The term used for the event where an
+      administrator joyfully signs its zone file while producing melodic
+      sound patterns.
+
+   Signer: The system that has access to the private key material and
+      signs the Resource Record sets in a zone.  A signer may be
+      configured to sign only parts of the zone, e.g., only those RRSets
+      for which existing signatures are about to expire.
+
+   Zone Signing Key (ZSK): A key that is used for signing all data in a
+      zone.  The fact that a key is a ZSK is only relevant to the
+      signing tool.
+
+   Zone administrator: The 'role' that is responsible for signing a zone
+      and publishing it on the primary authoritative server.
+
+Appendix B.  Zone Signing Key Rollover How-To
+
+   Using the pre-published signature scheme and the most conservative
+   method to assure oneself that data does not live in caches, here
+   follows the "how-to".
+
+   Step 0: The preparation: Create two keys and publish both in your key
+      set.  Mark one of the keys "active" and the other "published".
+      Use the "active" key for signing your zone data.  Store the
+      private part of the "published" key, preferably off-line.  The
+      protocol does not provide for attributes to mark a key as active
+      or published.  This is something you have to do on your own,
+      through the use of a notebook or key management tool.
+
+   Step 1: Determine expiration: At the beginning of the rollover make a
+      note of the highest expiration time of signatures in your zone
+      file created with the current key marked as active.  Wait until
+      the expiration time marked in Step 1 has passed.
+
+   Step 2: Then start using the key that was marked "published" to sign
+      your data (i.e., mark it "active").  Stop using the key that was
+      marked "active"; mark it "rolled".
+
+   Step 3: It is safe to engage in a new rollover (Step 1) after at
+      least one signature validity period.
+
+
+
+
+
+
+
+
+
+
+Kolkman & Gieben             Informational                     [Page 31]
+
+RFC 4641              DNSSEC Operational Practices        September 2006
+
+
+Appendix C.  Typographic Conventions
+
+   The following typographic conventions are used in this document:
+
+   Key notation: A key is denoted by DNSKEYx, where x is a number or an
+   identifier, x could be thought of as the key id.
+
+   RRSet notations: RRs are only denoted by the type.  All other
+   information -- owner, class, rdata, and TTL--is left out.  Thus:
+   "example.com 3600 IN A 192.0.2.1" is reduced to "A".  RRSets are a
+   list of RRs.  A example of this would be "A1, A2", specifying the
+   RRSet containing two "A" records.  This could again be abbreviated to
+   just "A".
+
+   Signature notation: Signatures are denoted as RRSIGx(RRSet), which
+   means that RRSet is signed with DNSKEYx.
+
+   Zone representation: Using the above notation we have simplified the
+   representation of a signed zone by leaving out all unnecessary
+   details such as the names and by representing all data by "SOAx"
+
+   SOA representation: SOAs are represented as SOAx, where x is the
+   serial number.
+
+   Using this notation the following signed zone:
+
+   example.net.      86400  IN SOA  ns.example.net. bert.example.net. (
+                            2006022100   ; serial
+                            86400        ; refresh (  24 hours)
+                            7200         ; retry   (   2 hours)
+                            3600000      ; expire  (1000 hours)
+                            28800 )      ; minimum (   8 hours)
+                     86400  RRSIG   SOA 5 2 86400 20130522213204 (
+                                  20130422213204 14 example.net.
+                                  cmL62SI6iAX46xGNQAdQ... )
+                     86400  NS      a.iana-servers.net.
+                     86400  NS      b.iana-servers.net.
+                     86400  RRSIG   NS 5 2 86400 20130507213204 (
+                                  20130407213204 14 example.net.
+                                  SO5epiJei19AjXoUpFnQ ... )
+                     86400  DNSKEY  256 3 5 (
+                                  EtRB9MP5/AvOuVO0I8XDxy0... ) ; id = 14
+                     86400  DNSKEY  257 3 5 (
+                                  gsPW/Yy19GzYIY+Gnr8HABU... ) ; id = 15
+                     86400  RRSIG   DNSKEY 5 2 86400 20130522213204 (
+                                  20130422213204 14 example.net.
+                                  J4zCe8QX4tXVGjV4e1r9... )
+
+
+
+
+Kolkman & Gieben             Informational                     [Page 32]
+
+RFC 4641              DNSSEC Operational Practices        September 2006
+
+
+                     86400  RRSIG   DNSKEY 5 2 86400 20130522213204 (
+                                  20130422213204 15 example.net.
+                                  keVDCOpsSeDReyV6O... )
+                     86400  RRSIG   NSEC 5 2 86400 20130507213204 (
+                                  20130407213204 14 example.net.
+                                  obj3HEp1GjnmhRjX... )
+   a.example.net.    86400  IN TXT  "A label"
+                     86400  RRSIG   TXT 5 3 86400 20130507213204 (
+                                  20130407213204 14 example.net.
+                                  IkDMlRdYLmXH7QJnuF3v... )
+                     86400  NSEC    b.example.com. TXT RRSIG NSEC
+                     86400  RRSIG   NSEC 5 3 86400 20130507213204 (
+                                  20130407213204 14 example.net.
+                                  bZMjoZ3bHjnEz0nIsPMM... )
+                     ...
+
+   is reduced to the following representation:
+
+       SOA2006022100
+       RRSIG14(SOA2006022100)
+       DNSKEY14
+       DNSKEY15
+
+       RRSIG14(KEY)
+       RRSIG15(KEY)
+
+   The rest of the zone data has the same signature as the SOA record,
+   i.e., an RRSIG created with DNSKEY 14.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kolkman & Gieben             Informational                     [Page 33]
+
+RFC 4641              DNSSEC Operational Practices        September 2006
+
+
+Authors' Addresses
+
+   Olaf M. Kolkman
+   NLnet Labs
+   Kruislaan 419
+   Amsterdam  1098 VA
+   The Netherlands
+
+   EMail: olaf@nlnetlabs.nl
+   URI:   http://www.nlnetlabs.nl
+
+
+   R. (Miek) Gieben
+
+   EMail: miek@miek.nl
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kolkman & Gieben             Informational                     [Page 34]
+
+RFC 4641              DNSSEC Operational Practices        September 2006
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2006).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Kolkman & Gieben             Informational                     [Page 35]
+
diff --git a/doc/rfc/rfc952.txt b/doc/rfc/rfc952.txt
new file mode 100644
index 0000000..7df339a
--- /dev/null
+++ b/doc/rfc/rfc952.txt
@@ -0,0 +1,340 @@
+Network Working Group                               K. Harrenstien (SRI)
+Request for Comments: 952                                 M. Stahl (SRI)
+                                                        E. Feinler (SRI)
+Obsoletes:  RFC 810, 608                                    October 1985
+
+                 DOD INTERNET HOST TABLE SPECIFICATION
+
+
+STATUS OF THIS MEMO
+
+   This RFC is the official specification of the format of the Internet
+   Host Table.  This edition of the specification includes minor
+   revisions to RFC-810 which brings it up to date. Distribution of this
+   memo is unlimited.
+
+INTRODUCTION
+
+   The DoD Host Table is utilized by the DoD Hostname Server maintained
+   by the DDN Network Information Center (NIC) on behalf of the Defense
+   Communications Agency (DCA) [See RFC-953].
+
+LOCATION OF THE STANDARD DOD ONLINE HOST TABLE
+
+   A machine-translatable ASCII text version of the DoD Host Table is
+   online in the file NETINFO:HOSTS.TXT on the SRI-NIC host.  It can be
+   obtained via FTP from your local host by connecting to host
+   SRI-NIC.ARPA (26.0.0.73 or 10.0.0.51), logging in as user =
+   ANONYMOUS, password = GUEST, and retrieving the file
+   "NETINFO:HOSTS.TXT".  The same table may also be obtained via the NIC
+   Hostname Server, as described in RFC-953.  The latter method is
+   faster and easier, but requires a user program to make the necessary
+   connection to the Name Server.
+
+ASSUMPTIONS
+
+   1. A "name" (Net, Host, Gateway, or Domain name) is a text string up
+   to 24 characters drawn from the alphabet (A-Z), digits (0-9), minus
+   sign (-), and period (.).  Note that periods are only allowed when
+   they serve to delimit components of "domain style names". (See
+   RFC-921, "Domain Name System Implementation Schedule", for
+   background).  No blank or space characters are permitted as part of a
+   name. No distinction is made between upper and lower case.  The first
+   character must be an alpha character.  The last character must not be
+   a minus sign or period.  A host which serves as a GATEWAY should have
+   "-GATEWAY" or "-GW" as part of its name.  Hosts which do not serve as
+   Internet gateways should not use "-GATEWAY" and "-GW" as part of
+   their names. A host which is a TAC should have "-TAC" as the last
+   part of its host name, if it is a DoD host.  Single character names
+   or nicknames are not allowed.
+
+   2. Internet Addresses are 32-bit addresses [See RFC-796].  In the
+
+
+Harrenstien & Stahl & Feinler                                   [Page 1]
+
+
+
+RFC 952                                                     October 1985
+DOD INTERNET HOST TABLE SPECIFICATION
+
+
+   host table described herein each address is represented by four
+   decimal numbers separated by a period.  Each decimal number
+   represents 1 octet.
+
+   3. If the first bit of the first octet of the address is 0 (zero),
+   then the next 7 bits of the first octet indicate the network number
+   (Class A Address).  If the first two bits are 1,0 (one,zero), then
+   the next 14 bits define the net number (Class B Address).  If the
+   first 3 bits are 1,1,0 (one,one,zero), then the next 21 bits define
+   the net number (Class C Address) [See RFC-943].
+
+      This is depicted in the following diagram:
+
+      +-+------------+--------------+--------------+--------------+
+      |0|  NET <-7-> |         LOCAL ADDRESS <-24->               |
+      +-+------------+--------------+--------------+--------------+
+
+      +---+----------+--------------+--------------+--------------+
+      |1 0|      NET  <-14->        |  LOCAL ADDRESS <-16->       |
+      +---+----------+--------------+--------------+--------------+
+
+      +-----+--------+--------------+--------------+--------------+
+      |1 1 0|            NET  <-21->               | LOCAL ADDRESS|
+      +-----+--------+--------------+--------------+--------------+
+
+   4. The LOCAL ADDRESS portion of the internet address identifies a
+   host within the network specified by the NET portion of the address.
+
+   5. The ARPANET and MILNET are both Class A networks.  The NET portion
+   is 10 decimal for ARPANET, 26 decimal for MILNET, and the LOCAL
+   ADDRESS maps as follows: the second octet identifies the physical
+   host, the third octet identifies the logical host, and the fourth
+   identifies the Packet Switching Node (PSN), formerly known as an
+   Interface Message Processor (IMP).
+
+      +-+------------+--------------+--------------+--------------+
+      |0|  10 or 26  |    HOST      | LOGICAL HOST |   PSN (IMP)  |
+      +-+------------+--------------+--------------+--------------+
+
+      (NOTE:  RFC-796 also describes the local address mappings for
+      several other networks.)
+
+   6. It is the responsibility of the users of this host table to
+   translate it into whatever format is needed for their purposes.
+
+   7. Names and addresses for DoD hosts and gateways will be negotiated
+   and registered with the DDN PMO, and subsequently with the NIC,
+
+
+Harrenstien & Stahl & Feinler                                   [Page 2]
+
+
+
+RFC 952                                                     October 1985
+DOD INTERNET HOST TABLE SPECIFICATION
+
+
+   before being used and before traffic is passed by a DoD host.  Names
+   and addresses for domains and networks are to be registered with the
+   DDN Network Information Center (HOSTMASTER@SRI-NIC.ARPA) or
+   800-235-3155.
+
+   The NIC will attempt to keep similar information for non-DoD networks
+   and hosts, if this information is provided, and as long as it is
+   needed, i.e., until intercommunicating network name servers are in
+   place.
+
+EXAMPLE OF HOST TABLE FORMAT
+
+   NET : 10.0.0.0 : ARPANET :
+   NET : 128.10.0.0 : PURDUE-CS-NET :
+   GATEWAY : 10.0.0.77, 18.10.0.4 : MIT-GW.ARPA,MIT-GATEWAY : PDP-11 :
+             MOS : IP/GW,EGP :
+   HOST : 26.0.0.73, 10.0.0.51 : SRI-NIC.ARPA,SRI-NIC,NIC : DEC-2060 :
+          TOPS20 :TCP/TELNET,TCP/SMTP,TCP/TIME,TCP/FTP,TCP/ECHO,ICMP :
+   HOST : 10.2.0.11 : SU-TAC.ARPA,SU-TAC : C/30 : TAC : TCP :
+
+SYNTAX AND CONVENTIONS
+
+   ; (semicolon)   is used to denote the beginning of a comment.
+                   Any text on a given line following a ';' is a
+                   comment, and not part of the host table.
+
+   NET             keyword introducing a network entry
+
+   GATEWAY         keyword introducing a gateway entry
+
+   HOST            keyword introducing a host entry
+
+   DOMAIN          keyword introducing a domain entry
+
+   :(colon)        is used as a field delimiter
+
+   ::(2 colons)    indicates a null field
+
+   ,(comma)        is used as a data element delimiter
+
+   XXX/YYY         indicates protocol information of the type
+                   TRANSPORT/SERVICE.
+
+      where TRANSPORT/SERVICE options are specified as
+
+         "FOO/BAR"       both transport and service known
+
+
+
+Harrenstien & Stahl & Feinler                                   [Page 3]
+
+
+
+RFC 952                                                     October 1985
+DOD INTERNET HOST TABLE SPECIFICATION
+
+
+         "FOO"           transport known; services not known
+
+         "BAR"           service is known, transport not known
+
+         NOTE:  See "Assigned Numbers" for specific options and acronyms
+         for machine types, operating systems, and protocol/services.
+
+   Each host table entry is an ASCII text string comprised of 6 fields,
+   where
+
+      Field 1         KEYWORD indicating whether this entry pertains to
+                      a NET, GATEWAY, HOST, or DOMAIN.  NET entries are
+                      assigned and cannot have alternate addresses or
+                      nicknames.  DOMAIN entries do not use fields 4, 5,
+                      or 6.
+
+      Field 2         Internet Address of Network, Gateway, or Host
+                      followed by alternate addresses.  Addresses for a
+                      Domain are those where a Domain Name Server exists
+                      for that domain.
+
+      Field 3         Official Name of Network, Gateway, Host, or Domain
+                      (with optional nicknames, where permitted).
+
+      Field 4         Machine Type
+
+      Field 5         Operating System
+
+      Field 6         Protocol List
+
+   Fields 4, 5 and 6 are optional.  For a Domain they are not used.
+
+   Fields 3-6, if included, pertain to the first address in Field 2.
+
+   'Blanks' (spaces and tabs) are ignored between data elements or
+   fields, but are disallowed within a data element.
+
+   Each entry ends with a colon.
+
+   The entries in the table are grouped by types in the order Domain,
+   Net, Gateway, and Host.  Within each type the ordering is
+   unspecified.
+
+   Note that although optional nicknames are allowed for hosts, they are
+   discouraged, except in the case where host names have been changed
+
+
+
+
+Harrenstien & Stahl & Feinler                                   [Page 4]
+
+
+
+RFC 952                                                     October 1985
+DOD INTERNET HOST TABLE SPECIFICATION
+
+
+   and both the new and the old names are maintained for a suitable
+   period of time to effect a smooth transition.  Nicknames are not
+   permitted for NET names.
+
+GRAMMATICAL HOST TABLE SPECIFICATION
+
+   A. Parsing grammar
+
+      <entry> ::= <keyword> ":" <addresses> ":" <names> [":" [<cputype>]
+         [":" [<opsys>]  [":" [<protocol list>] ]]] ":"
+      <addresses> ::= <address> *["," <address>]
+      <address> ::= <octet> "." <octet> "." <octet> "." <octet>
+      <octet> ::= <0 to 255 decimal>
+      <names> ::= <netname> | <gatename> | <domainname> *[","
+         <nicknames>]
+         | <official hostname> *["," <nicknames>]
+      <netname>  ::= <name>
+      <gatename> ::= <hname>
+      <domainname> ::= <hname>
+      <official hostname> ::= <hname>
+      <nickname> ::= <hname>
+      <protocol list> ::= <protocol spec> *["," <protocol spec>]
+      <protocol spec> ::= <transport name> "/" <service name>
+         | <raw protocol name>
+
+   B. Lexical grammar
+
+      <entry-field> ::= <entry-text> [<cr><lf> <blank> <entry-field>]
+      <entry-text>  ::= <print-char> *<text>
+      <blank> ::= <space-or-tab> [<blank>]
+      <keyword> ::= NET | GATEWAY | HOST | DOMAIN
+      <hname> ::= <name>*["."<name>]
+      <name>  ::= <let>[*[<let-or-digit-or-hyphen>]<let-or-digit>]
+      <cputype> ::= PDP-11/70 | DEC-1080 | C/30 | CDC-6400...etc.
+      <opsys>   ::= ITS | MULTICS | TOPS20 | UNIX...etc.
+      <transport name> ::= TCP | NCP | UDP | IP...etc.
+      <service name> ::= TELNET | FTP | SMTP | MTP...etc.
+      <raw protocol name> ::= <name>
+      <comment> ::= ";" <text><cr><lf>
+      <text>    ::= *[<print-char> | <blank>]
+      <print-char>  ::= <any printing char (not space or tab)>
+
+   Notes:
+
+      1. Zero or more 'blanks' between separators " , : " are allowed.
+      'Blanks' are spaces and tabs.
+
+
+
+Harrenstien & Stahl & Feinler                                   [Page 5]
+
+
+
+RFC 952                                                     October 1985
+DOD INTERNET HOST TABLE SPECIFICATION
+
+
+      2. Continuation lines are lines that begin with at least one
+      blank.  They may be used anywhere 'blanks' are legal to split an
+      entry across lines.
+
+BIBLIOGRAPHY
+
+   1. Feinler, E., Harrenstien, K., Su, Z. and White, V., "Official DoD
+      Internet Host Table Specification", RFC-810, Network Information
+      Center, SRI International, March 1982.
+
+   2. Harrenstien, K., Stahl, M., and Feinler, E., "Hostname Server",
+      RFC-953, Network Information Center, SRI International, October
+      1985.
+
+   3. Kudlick, M. "Host Names Online", RFC-608, Network Information
+      Center, SRI International, January 1973.
+
+   4. Postel, J., "Internet Protocol", RFC-791, Information Sciences
+      Institute, University of Southern California, Marina del Rey,
+      September 1981.
+
+   5. Postel, J., "Address Mappings", RFC-796, Information Sciences
+      Institute, University of Southern California, Marina del Rey,
+      September 1981.
+
+   6. Postel, J., "Domain Name System Implementation Schedule", RFC-921,
+      Information Sciences Institute, University of Southern California,
+      Marina del Rey, October 1984.
+
+   7. Reynolds, J. and Postel, J., "Assigned Numbers", RFC-943,
+      Information Sciences Institute, University of Southern California,
+      Marina del Rey, April 1985.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Harrenstien & Stahl & Feinler                                   [Page 6]
+